From: Toralf F. <tor...@gm...> - 2010-05-27 17:44:20
Attachments:
.config
|
Hello, I bisected it to this : There are only 'skip'ped commits left to test. The first bad commit could be any of: 4677d4a53e0d565742277e8913e91c821453e63e d61931d89be506372d01a90d1755f6d0a9fafe2d 1527bc8b928dd1399c3d3467dd47d9ede210978a c59bd5688299cddb71183e156e7a3c1409b90df2 cb41838bbc4403f7270a94b93a9a0d9fc9c2e7ea We cannot bisect more! The .config file is attached. The script which starts an UML image exits with exit code 143: Locating the bottom of the address space ... 0x1000 Locating the top of the address space ... 0xc0000000 Core dump limits : soft - NONE hard - NONE Checking that ptrace can change system call numbers...OK Checking syscall emulation patch for ptrace...OK Checking advanced syscall emulation patch for ptrace...OK Checking for tmpfs mount on /dev/shm...OK Checking PROT_EXEC mmap in /dev/shm/...OK Checking for the skas3 patch in the host: - /proc/mm...not found: No such file or directory - PTRACE_FAULTINFO...not found - PTRACE_LDT...not found UML running in SKAS0 mode Adding 4325376 bytes to physical memory to account for exec-shield gap Linux version 2.6.34-00633-g1f8caa9 (tfoerste@n22) (gcc version 4.3.4 (Gentoo 4.3.4 p1.1, pie-10.1.5) ) #18 Thu May 27 19:33:37 CEST 2010 Built 1 zonelists in Zone order, mobility grouping on. Total pages: 66071 Kernel command line: ubda=/home/tfoerste/virtual/uml/gentoo_root_fs ubdb=/home/tfoerste/virtual/uml/swap_fs eth0=tuntap,,,192.168.0.253 mem=256M root=98:0 PID hash table entries: 2048 (order: 1, 8192 bytes) Dentry cache hash table entries: 65536 (order: 6, 262144 bytes) Inode-cache hash table entries: 32768 (order: 5, 131072 bytes) Memory: 254512k available Hierarchical RCU implementation. RCU-based detection of stalled CPUs is disabled. Verbose stalled-CPUs detection is disabled. NR_IRQS:15 Calibrating delay loop... 4731.69 BogoMIPS (lpj=23658496) Mount-cache hash table entries: 512 Checking for host processor cmov support...Yes Checking that host ptys support output SIGIO...Yes Checking that host ptys support SIGIO on close...No, enabling workaround Using 2.6 host AIO NET: Registered protocol family 16 bio: create slab <bio-0> at 0 Switching to clocksource itimer NET: Registered protocol family 2 IP route cache hash table entries: 4096 (order: 2, 16384 bytes) TCP established hash table entries: 16384 (order: 5, 131072 bytes) TCP bind hash table entries: 16384 (order: 4, 65536 bytes) TCP: Hash tables configured (established 16384 bind 16384) TCP reno registered UDP hash table entries: 256 (order: 0, 4096 bytes) UDP-Lite hash table entries: 256 (order: 0, 4096 bytes) NET: Registered protocol family 1 RPC: Registered udp transport module. RPC: Registered tcp transport module. RPC: Registered tcp NFSv4.1 backchannel transport module. IRQ 9/mconsole: IRQF_DISABLED is not guaranteed on shared IRQs mconsole (version 2) initialized on /home/tfoerste/.uml/tfoerste/mconsole Checking host MADV_REMOVE support...OK UML Audio Relay (host dsp = /dev/sound/dsp, host mixer = /dev/sound/mixer) Host TLS support detected Detected host type: i386 (GDT indexes 6 to 9) Installing knfsd (copyright (C) 1996 ok...@mo...). msgmni has been set to 497 alg: No test for stdrng (krng) io scheduler noop registered io scheduler cfq registered (default) tun: Universal TUN/TAP device driver, 1.6 tun: (C) 1999-2004 Max Krasnyansky <ma...@qu...> TCP cubic registered NET: Registered protocol family 17 Initialized stdio console driver Console initialized on /dev/tty0 console [tty0] enabled Initializing software serial port version 1 console [mc-1] enabled ubda: unknown partition table ubdb: unknown partition table Choosing a random ethernet address for device eth0 Netdevice 0 (da:45:59:e9:7b:7e) : TUN/TAP backend - IP = 192.168.0.253 IRQ 3/console-write: IRQF_DISABLED is not guaranteed on shared IRQs IRQ 2/console: IRQF_DISABLED is not guaranteed on shared IRQs IRQ 10/winch: IRQF_DISABLED is not guaranteed on shared IRQs EIP: 0073:[<081c77c3>] CPU: 0 Not tainted ESP: 007b:1805ab04 EFLAGS: 00210293 Not tainted EAX: 00000001 EBX: 180cb000 ECX: 00000000 EDX: 00000001 ESI: 181e2930 EDI: 181e2930 EBP: 181e2930 DS: 007b ES: 007b 082fdb34: [<0805a0d9>] _einittext+0x1f96/0x2b55 082fdb70: [<080968cc>] run_posix_cpu_timers+0x1c/0x910 082fdb8c: [<08078afa>] task_tick_fair+0x1a/0xe0 082fdba4: [<08098fbc>] hrtimer_run_pending+0x2c/0xc0 082fdbac: [<080701fd>] set_signals+0x2d/0x40 082fdbc8: [<0805f732>] segv_handler+0x52/0xe0 082fdbd8: [<081c77c3>] cfq_close_cooperator+0x53/0x180 082fdbf0: [<080a2848>] tick_nohz_stop_sched_tick+0xb8/0x410 082fdc00: [<080840d0>] __do_softirq+0xe0/0x130 082fdc40: [<0806e934>] os_waiting_for_events+0x24/0xb0 082fdc50: [<080615bd>] free_irqs+0x5d/0xd0 082fdc70: [<080700d5>] sig_handler_common+0x55/0xa0 082fdcb0: [<081c77c3>] cfq_close_cooperator+0x53/0x180 082fdce8: [<08070272>] sig_handler+0x22/0x40 082fdcf0: [<080704ed>] handle_signal+0x5d/0xa0 082fdd10: [<080728d7>] hard_handler+0x17/0x20 082fdd5c: [<081c77c3>] cfq_close_cooperator+0x53/0x180 Kernel panic - not syncing: Segfault with no mm 082fdb00: [<0827fd7d>] panic+0x4d/0xc6 082fdb18: [<0805f6ca>] segv+0x2aa/0x2c0 082fdb34: [<0805a0d9>] _einittext+0x1f96/0x2b55 082fdb70: [<080968cc>] run_posix_cpu_timers+0x1c/0x910 082fdb8c: [<08078afa>] task_tick_fair+0x1a/0xe0 082fdba4: [<08098fbc>] hrtimer_run_pending+0x2c/0xc0 082fdbac: [<080701fd>] set_signals+0x2d/0x40 082fdbc8: [<0805f732>] segv_handler+0x52/0xe0 082fdbd8: [<081c77c3>] cfq_close_cooperator+0x53/0x180 082fdbf0: [<080a2848>] tick_nohz_stop_sched_tick+0xb8/0x410 082fdc00: [<080840d0>] __do_softirq+0xe0/0x130 082fdc40: [<0806e934>] os_waiting_for_events+0x24/0xb0 082fdc50: [<080615bd>] free_irqs+0x5d/0xd0 082fdc70: [<080700d5>] sig_handler_common+0x55/0xa0 082fdcb0: [<081c77c3>] cfq_close_cooperator+0x53/0x180 082fdce8: [<08070272>] sig_handler+0x22/0x40 082fdcf0: [<080704ed>] handle_signal+0x5d/0xa0 082fdd10: [<080728d7>] hard_handler+0x17/0x20 082fdd5c: [<081c77c3>] cfq_close_cooperator+0x53/0x180 EIP: 0073:[<b7869424>] CPU: 0 Not tainted ESP: 007b:bfef268c EFLAGS: 00200246 Not tainted EAX: 00000000 EBX: 00006783 ECX: 00000013 EDX: 00006783 ESI: 0000677f EDI: 0000003b EBP: bfef2718 DS: 007b ES: 007b 082fdadc: [<08099da4>] notifier_call_chain+0x34/0x70 082fdb00: [<0827fda5>] panic+0x75/0xc6 082fdb18: [<0805f6ca>] segv+0x2aa/0x2c0 082fdb34: [<0805a0d9>] _einittext+0x1f96/0x2b55 082fdb70: [<080968cc>] run_posix_cpu_timers+0x1c/0x910 082fdb8c: [<08078afa>] task_tick_fair+0x1a/0xe0 082fdba4: [<08098fbc>] hrtimer_run_pending+0x2c/0xc0 082fdbac: [<080701fd>] set_signals+0x2d/0x40 082fdbc8: [<0805f732>] segv_handler+0x52/0xe0 082fdbd8: [<081c77c3>] cfq_close_cooperator+0x53/0x180 082fdbf0: [<080a2848>] tick_nohz_stop_sched_tick+0xb8/0x410 082fdc00: [<080840d0>] __do_softirq+0xe0/0x130 082fdc40: [<0806e934>] os_waiting_for_events+0x24/0xb0 082fdc50: [<080615bd>] free_irqs+0x5d/0xd0 082fdc70: [<080700d5>] sig_handler_common+0x55/0xa0 082fdcb0: [<081c77c3>] cfq_close_cooperator+0x53/0x180 082fdce8: [<08070272>] sig_handler+0x22/0x40 082fdcf0: [<080704ed>] handle_signal+0x5d/0xa0 082fdd10: [<080728d7>] hard_handler+0x17/0x20 082fdd5c: [<081c77c3>] cfq_close_cooperator+0x53/0x180 Terminated Bisecting: 4 revisions left to test after this (roughly 2 steps) [cb41838bbc4403f7270a94b93a9a0d9fc9c2e7ea] Merge branch 'core-hweight-for- linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/linux-2.6-tip tfoerste@n22 ~/devel/linux-2.6 $ git bisect run ~/uml_bisect.sh || git bisect bad running /home/tfoerste/uml_bisect.sh scripts/kconfig/conf -o arch/um/Kconfig.x86 # # configuration written to .config # scripts/kconfig/conf -s arch/um/Kconfig.x86 make[1]: `arch/um/sys-i386/user-offsets.s' is up to date. CHK include/linux/version.h CHK include/generated/utsrelease.h UPD include/generated/utsrelease.h CALL scripts/checksyscalls.sh CHK include/generated/compile.h CC init/version.o QUOTE arch/um/kernel/config.tmp LD init/built-in.o QUOTE arch/um/kernel/config.c CC arch/um/kernel/config.o LD arch/um/kernel/built-in.o GZIP kernel/config_data.gz IKCFG kernel/config_data.h CC kernel/configs.o LD kernel/built-in.o LD vmlinux.o MODPOST vmlinux.o GEN .version CHK include/generated/compile.h UPD include/generated/compile.h CC init/version.o LD init/built-in.o LD .tmp_vmlinux1 KSYM .tmp_kallsyms1.S AS .tmp_kallsyms1.o LD .tmp_vmlinux2 KSYM .tmp_kallsyms2.S AS .tmp_kallsyms2.o LD .tmp_vmlinux3 KSYM .tmp_kallsyms3.S AS .tmp_kallsyms3.o LD vmlinux SYSMAP System.map SYSMAP .tmp_System.map LINK linux Locating the bottom of the address space ... 0x1000 Locating the top of the address space ... 0xc0000000 Core dump limits : soft - NONE hard - NONE Checking that ptrace can change system call numbers...OK Checking syscall emulation patch for ptrace...OK Checking advanced syscall emulation patch for ptrace...OK Checking for tmpfs mount on /dev/shm...OK Checking PROT_EXEC mmap in /dev/shm/...OK Checking for the skas3 patch in the host: - /proc/mm...not found: No such file or directory - PTRACE_FAULTINFO...not found - PTRACE_LDT...not found UML running in SKAS0 mode Adding 5992448 bytes to physical memory to account for exec-shield gap Linux version 2.6.34-00628-gcb41838 (tfoerste@n22) (gcc version 4.3.4 (Gentoo 4.3.4 p1.1, pie-10.1.5) ) #19 Thu May 27 19:34:39 CEST 2010 Built 1 zonelists in Zone order, mobility grouping on. Total pages: 66475 Kernel command line: ubda=/home/tfoerste/virtual/uml/gentoo_root_fs ubdb=/home/tfoerste/virtual/uml/swap_fs eth0=tuntap,,,192.168.0.253 mem=256M root=98:0 PID hash table entries: 2048 (order: 1, 8192 bytes) Dentry cache hash table entries: 65536 (order: 6, 262144 bytes) Inode-cache hash table entries: 32768 (order: 5, 131072 bytes) Memory: 254500k available Hierarchical RCU implementation. RCU-based detection of stalled CPUs is disabled. Verbose stalled-CPUs detection is disabled. NR_IRQS:15 Calibrating delay loop... 4731.69 BogoMIPS (lpj=23658496) Mount-cache hash table entries: 512 Checking for host processor cmov support...Yes Checking that host ptys support output SIGIO...Yes Checking that host ptys support SIGIO on close...No, enabling workaround Using 2.6 host AIO NET: Registered protocol family 16 bio: create slab <bio-0> at 0 Switching to clocksource itimer NET: Registered protocol family 2 IP route cache hash table entries: 4096 (order: 2, 16384 bytes) TCP established hash table entries: 16384 (order: 5, 131072 bytes) TCP bind hash table entries: 16384 (order: 4, 65536 bytes) TCP: Hash tables configured (established 16384 bind 16384) TCP reno registered UDP hash table entries: 256 (order: 0, 4096 bytes) UDP-Lite hash table entries: 256 (order: 0, 4096 bytes) NET: Registered protocol family 1 RPC: Registered udp transport module. RPC: Registered tcp transport module. RPC: Registered tcp NFSv4.1 backchannel transport module. IRQ 9/mconsole: IRQF_DISABLED is not guaranteed on shared IRQs mconsole (version 2) initialized on /home/tfoerste/.uml/tfoerste/mconsole Checking host MADV_REMOVE support...OK UML Audio Relay (host dsp = /dev/sound/dsp, host mixer = /dev/sound/mixer) Host TLS support detected Detected host type: i386 (GDT indexes 6 to 9) Installing knfsd (copyright (C) 1996 ok...@mo...). msgmni has been set to 497 alg: No test for stdrng (krng) io scheduler noop registered io scheduler cfq registered (default) tun: Universal TUN/TAP device driver, 1.6 tun: (C) 1999-2004 Max Krasnyansky <ma...@qu...> TCP cubic registered NET: Registered protocol family 17 Initialized stdio console driver Console initialized on /dev/tty0 console [tty0] enabled Initializing software serial port version 1 console [mc-1] enabled ubda: unknown partition table ubdb: unknown partition table Choosing a random ethernet address for device eth0 Netdevice 0 (9e:d2:65:a8:63:d8) : TUN/TAP backend - IP = 192.168.0.253 IRQ 3/console-write: IRQF_DISABLED is not guaranteed on shared IRQs IRQ 2/console: IRQF_DISABLED is not guaranteed on shared IRQs IRQ 10/winch: IRQF_DISABLED is not guaranteed on shared IRQs EIP: 0073:[<081c77c3>] CPU: 0 Not tainted ESP: 007b:1805ab04 EFLAGS: 00210293 Not tainted EAX: 00000001 EBX: 180cb000 ECX: 00000000 EDX: 00000001 ESI: 181e2930 EDI: 181e2930 EBP: 181e2930 DS: 007b ES: 007b 082fdb38: [<08079aa5>] __wake_up+0x45/0x60 082fdb5c: [<080916b9>] __queue_work+0x69/0x70 082fdb7c: [<0809174b>] queue_work_on+0x2b/0x40 082fdb84: [<080d0335>] kmem_cache_free+0x95/0xe0 082fdb94: [<081bc112>] __freed_request+0xb2/0xc0 082fdbc8: [<0805f732>] segv_handler+0x52/0xe0 082fdbd8: [<081c77c3>] cfq_close_cooperator+0x53/0x180 082fdbf4: [<0806a111>] ubd_intr+0x71/0xf0 082fdc14: [<080a816d>] handle_IRQ_event+0x5d/0xf0 082fdc40: [<0806e934>] os_waiting_for_events+0x24/0xb0 082fdc50: [<080615bd>] free_irqs+0x5d/0xd0 082fdc70: [<080700d5>] sig_handler_common+0x55/0xa0 082fdcb0: [<081c77c3>] cfq_close_cooperator+0x53/0x180 082fdce8: [<08070272>] sig_handler+0x22/0x40 082fdcf0: [<080704ed>] handle_signal+0x5d/0xa0 082fdd10: [<080728d7>] hard_handler+0x17/0x20 082fdd5c: [<081c77c3>] cfq_close_cooperator+0x53/0x180 Kernel panic - not syncing: Segfault with no mm 082fdb00: [<0827fd7d>] panic+0x4d/0xc6 082fdb18: [<0805f6ca>] segv+0x2aa/0x2c0 082fdb38: [<08079aa5>] __wake_up+0x45/0x60 082fdb5c: [<080916b9>] __queue_work+0x69/0x70 082fdb7c: [<0809174b>] queue_work_on+0x2b/0x40 082fdb84: [<080d0335>] kmem_cache_free+0x95/0xe0 082fdb94: [<081bc112>] __freed_request+0xb2/0xc0 082fdbc8: [<0805f732>] segv_handler+0x52/0xe0 082fdbd8: [<081c77c3>] cfq_close_cooperator+0x53/0x180 082fdbf4: [<0806a111>] ubd_intr+0x71/0xf0 082fdc14: [<080a816d>] handle_IRQ_event+0x5d/0xf0 082fdc40: [<0806e934>] os_waiting_for_events+0x24/0xb0 082fdc50: [<080615bd>] free_irqs+0x5d/0xd0 082fdc70: [<080700d5>] sig_handler_common+0x55/0xa0 082fdcb0: [<081c77c3>] cfq_close_cooperator+0x53/0x180 082fdce8: [<08070272>] sig_handler+0x22/0x40 082fdcf0: [<080704ed>] handle_signal+0x5d/0xa0 082fdd10: [<080728d7>] hard_handler+0x17/0x20 082fdd5c: [<081c77c3>] cfq_close_cooperator+0x53/0x180 EIP: 0073:[<b77da424>] CPU: 0 Not tainted ESP: 007b:bfc851ac EFLAGS: 00200246 Not tainted EAX: 00000000 EBX: 00006deb ECX: 00000013 EDX: 00006deb ESI: 00006de7 EDI: 0000003b EBP: bfc85238 DS: 007b ES: 007b 082fdadc: [<08099da4>] notifier_call_chain+0x34/0x70 082fdb00: [<0827fda5>] panic+0x75/0xc6 082fdb18: [<0805f6ca>] segv+0x2aa/0x2c0 082fdb38: [<08079aa5>] __wake_up+0x45/0x60 082fdb5c: [<080916b9>] __queue_work+0x69/0x70 082fdb7c: [<0809174b>] queue_work_on+0x2b/0x40 082fdb84: [<080d0335>] kmem_cache_free+0x95/0xe0 082fdb94: [<081bc112>] __freed_request+0xb2/0xc0 082fdbc8: [<0805f732>] segv_handler+0x52/0xe0 082fdbd8: [<081c77c3>] cfq_close_cooperator+0x53/0x180 082fdbf4: [<0806a111>] ubd_intr+0x71/0xf0 082fdc14: [<080a816d>] handle_IRQ_event+0x5d/0xf0 082fdc40: [<0806e934>] os_waiting_for_events+0x24/0xb0 082fdc50: [<080615bd>] free_irqs+0x5d/0xd0 082fdc70: [<080700d5>] sig_handler_common+0x55/0xa0 082fdcb0: [<081c77c3>] cfq_close_cooperator+0x53/0x180 082fdce8: [<08070272>] sig_handler+0x22/0x40 082fdcf0: [<080704ed>] handle_signal+0x5d/0xa0 082fdd10: [<080728d7>] hard_handler+0x17/0x20 082fdd5c: [<081c77c3>] cfq_close_cooperator+0x53/0x180 Terminated -- MfG/Sincerely Toralf Förster pgp finger print: 7B1A 07F4 EC82 0F90 D4C2 8936 872A E508 7DB6 9DA3 |
From: Geert U. <ge...@li...> - 2010-05-30 11:39:22
|
2010/5/27 Toralf Förster <tor...@gm...>: > I bisected it to this : > > There are only 'skip'ped commits left to test. > The first bad commit could be any of: > 4677d4a53e0d565742277e8913e91c821453e63e > d61931d89be506372d01a90d1755f6d0a9fafe2d > 1527bc8b928dd1399c3d3467dd47d9ede210978a > c59bd5688299cddb71183e156e7a3c1409b90df2 > cb41838bbc4403f7270a94b93a9a0d9fc9c2e7ea > We cannot bisect more! For me it crashes even earlier: ayla$ ./linux Core dump limits : soft - 0 hard - NONE Checking that ptrace can change system call numbers...OK Checking syscall emulation patch for ptrace...OK Checking advanced syscall emulation patch for ptrace...OK Checking for tmpfs mount on /dev/shm...OK Checking PROT_EXEC mmap in /dev/shm/...OK Checking for the skas3 patch in the host: - /proc/mm...not found: No such file or directory - PTRACE_FAULTINFO...not found - PTRACE_LDT...not found UML running in SKAS0 mode Adding 21749760 bytes to physical memory to account for exec-shield gap Aborted ayla$ After fixing the missing/superfluous slab inclusion issues, I bisected it further to commit d61931d89be506372d01a90d1755f6d0a9fafe2d Author: Borislav Petkov <bor...@am...> Date: Fri Mar 5 17:34:46 2010 +0100 x86: Add optimized popcnt variants Add support for the hardware version of the Hamming weight function, popcnt, present in CPUs which advertize it under CPUID, Function 0x0000_0001_ECX[23]. On CPUs which don't support it, we fallback to the default lib/hweight.c sw versions. A synthetic benchmark comparing popcnt with __sw_hweight64 showed almost a 3x speedup on a F10h machine. Signed-off-by: Borislav Petkov <bor...@am...> LKML-Reference: <20100318112015.GC11152@aftab> Signed-off-by: H. Peter Anvin <hp...@zy...> I reverted that commit on top of current mainline (and fixed up the conflicts), and now it boots again. CPU is: processor : 0 vendor_id : GenuineIntel cpu family : 6 model : 23 model name : Intel(R) Core(TM)2 Quad CPU Q8200 @ 2.33GHz stepping : 7 cpu MHz : 2003.000 cache size : 2048 KB physical id : 0 siblings : 4 core id : 0 cpu cores : 4 apicid : 0 initial apicid : 0 fpu : yes fpu_exception : yes cpuid level : 10 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx lm constant_tsc arch_perfmon pebs bts rep_good aperfmperf pni dtes64 monitor ds_cpl est tm2 ssse3 cx16 xtpr pdcm sse4_1 lahf_lm bogomips : 4665.87 clflush size : 64 cache_alignment : 64 address sizes : 36 bits physical, 48 bits virtual power management: Gr{oetje,eeting}s, Geert -- Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@li... In personal conversations with technical people, I call myself a hacker. But when I'm talking to journalists I just say "programmer" or something like that. -- Linus Torvalds |
From: Geert U. <ge...@li...> - 2010-05-30 11:57:13
|
On Sun, May 30, 2010 at 13:39, Geert Uytterhoeven <ge...@li...> wrote: > 2010/5/27 Toralf Förster <tor...@gm...>: >> I bisected it to this : > After fixing the missing/superfluous slab inclusion issues, I bisected > it further to > > commit d61931d89be506372d01a90d1755f6d0a9fafe2d > Author: Borislav Petkov <bor...@am...> > Date: Fri Mar 5 17:34:46 2010 +0100 > > x86: Add optimized popcnt variants > > Add support for the hardware version of the Hamming weight function, > popcnt, present in CPUs which advertize it under CPUID, Function > 0x0000_0001_ECX[23]. On CPUs which don't support it, we fallback to the > default lib/hweight.c sw versions. > > A synthetic benchmark comparing popcnt with __sw_hweight64 showed almost > a 3x speedup on a F10h machine. > > Signed-off-by: Borislav Petkov <bor...@am...> > LKML-Reference: <20100318112015.GC11152@aftab> > Signed-off-by: H. Peter Anvin <hp...@zy...> > > I reverted that commit on top of current mainline (and fixed up the > conflicts), and now > it boots again. I tried adding config ARCH_HWEIGHT_CFLAGS string default "-fcall-saved-ecx -fcall-saved-edx" if !64_BIT default "-fcall-saved-rdi -fcall-saved-rsi -fcall-saved-rdx -fcall-saved-rcx -fcall-saved-r8 -fcall-saved-r9 -fcall-saved-r10 -fcall-saved-r11" if 64_BIT to arch/um/Kconfig.x86. Now it got a bit further, but it still crashes: Core dump limits : soft - 0 hard - NONE Checking that ptrace can change system call numbers...OK Checking syscall emulation patch for ptrace...OK Checking advanced syscall emulation patch for ptrace...OK Checking for tmpfs mount on /dev/shm...OK Checking PROT_EXEC mmap in /dev/shm/...OK Checking for the skas3 patch in the host: - /proc/mm...not found: No such file or directory - PTRACE_FAULTINFO...not found - PTRACE_LDT...not found UML running in SKAS0 mode Adding 22290432 bytes to physical memory to account for exec-shield gap Linux version 2.6.34-08406-g52b0ace-dirty (geert@ayla) (gcc version 4.4.3 (Ubuntu 4.4.3-4ubuntu5) ) #41 Sun May 30 13:54:35 CEST 2010 Built 1 zonelists in Zone order, mobility grouping on. Total pages: 70007 Kernel command line: ubd0=/home/uml/rootfs-amd64 eth0=slirp,,slirp-fullbolt mem=256M root=98:0 PID hash table entries: 2048 (order: 2, 16384 bytes) Dentry cache hash table entries: 65536 (order: 7, 524288 bytes) Inode-cache hash table entries: 32768 (order: 6, 262144 bytes) Memory: 250720k available Hierarchical RCU implementation. Verbose stalled-CPUs detection is disabled. NR_IRQS:15 Calibrating delay loop... 419.43 BogoMIPS (lpj=2097152) pid_max: default: 32768 minimum: 301 Mount-cache hash table entries: 256 Checking that host ptys support output SIGIO...Yes Checking that host ptys support SIGIO on close...No, enabling workaround Using 2.6 host AIO NET: Registered protocol family 16 bio: create slab <bio-0> at 0 Switching to clocksource itimer NET: Registered protocol family 2 IP route cache hash table entries: 4096 (order: 3, 32768 bytes) TCP established hash table entries: 16384 (order: 6, 262144 bytes) TCP bind hash table entries: 16384 (order: 5, 131072 bytes) TCP: Hash tables configured (established 16384 bind 16384) TCP reno registered UDP hash table entries: 256 (order: 1, 8192 bytes) UDP-Lite hash table entries: 256 (order: 1, 8192 bytes) NET: Registered protocol family 1 mconsole (version 2) initialized on /home/geert/.uml/z9aGEj/mconsole Checking host MADV_REMOVE support...OK VFS: Disk quotas dquot_6.5.2 Dquot-cache hash table entries: 512 (order 0, 4096 bytes) msgmni has been set to 489 io scheduler noop registered io scheduler deadline registered io scheduler cfq registered (default) TCP cubic registered NET: Registered protocol family 17 Initialized stdio console driver Console initialized on /dev/tty0 console [tty0] enabled Initializing software serial port version 1 Choosing a random ethernet address for device eth0 Netdevice 0 (1e:a2:ad:7c:43:91) : SLIRP backend - command line: 'slirp-fullbolt' console [mc-1] enabled ubda: Modules linked in: Pid: 0, comm: swapper Not tainted 2.6.34-08406-g52b0ace-dirty RIP: 0033:[<0000000060110675>] RSP: 0000000060235810 EFLAGS: 00010297 RAX: 0000000000000000 RBX: 0000000071371800 RCX: 000000000000000a RDX: 00000000ffff8aed RSI: 0000000000000000 RDI: 0000000000000000 RBP: 0000000060235820 R08: 0000000000000000 R09: 000000000000001e R10: 0000000000000001 R11: 00000000602b8c48 R12: 00000000713c4e80 R13: 00000000713c4e80 R14: 0000000071375958 R15: 0000000000000001 Call Trace: 60235308: [<60014a79>] segv+0x70/0x212 60235318: [<60110675>] cfq_close_cooperator+0x39/0x160 602353e8: [<60014c7a>] segv_handler+0x5f/0x65 60235418: [<60021698>] sig_handler_common+0x84/0x98 602354a0: [<60110675>] cfq_close_cooperator+0x39/0x160 60235548: [<600217de>] sig_handler+0x30/0x3b 60235568: [<60021a10>] handle_signal+0x6d/0xa3 602355b8: [<600233c8>] hard_handler+0x10/0x14 60235678: [<60110675>] cfq_close_cooperator+0x39/0x160 60235708: [<60040bb3>] autoremove_wake_function+0x11/0x34 60235728: [<60040bfe>] wake_bit_function+0x28/0x2e 60235738: [<600276db>] __wake_up_common+0x44/0x7a 60235778: [<60075913>] kmem_cache_free+0x54/0x5f 602357b8: [<60057f6e>] mempool_free_slab+0x12/0x14 602357c8: [<6005803c>] mempool_free+0x6f/0x76 602357f8: [<6009ae62>] bio_free+0x4d/0x52 60235808: [<6011066c>] cfq_close_cooperator+0x30/0x160 60235828: [<60110bae>] cfq_completed_request+0x375/0x4db 60235888: [<601053ee>] elv_completed_request+0x4e/0xaf 602358a8: [<601068be>] __blk_put_request+0x37/0xbd 602358d8: [<60106acf>] blk_finish_request+0x18b/0x198 60235918: [<60106d85>] blk_end_bidi_request+0x38/0x4b 60235948: [<60106dca>] blk_end_request+0xb/0xd 60235958: [<6001cf86>] ubd_intr+0x55/0xd7 60235998: [<600527a2>] handle_IRQ_event+0x20/0x9a 602359c8: [<60052889>] __do_IRQ+0x6d/0xb0 602359f8: [<6001217f>] do_IRQ+0x27/0x3f 60235a28: [<6001234f>] sigio_handler+0x4b/0x5f 60235a48: [<60021698>] sig_handler_common+0x84/0x98 60235a68: [<60021745>] real_alarm_handler+0x3c/0x3e 60235af0: [<60095b01>] copy_fs_struct+0xc/0x76 60235b78: [<600217de>] sig_handler+0x30/0x3b 60235b98: [<60021a10>] handle_signal+0x6d/0xa3 60235be8: [<600233c8>] hard_handler+0x10/0x14 Kernel panic - not syncing: Segfault with no mm Call Trace: 60235218: [<6018fadb>] panic+0xe4/0x14f 60235278: [<6004db6b>] is_module_text_address+0x9/0x11 60235288: [<6003ecdc>] __kernel_text_address+0x65/0x6b 60235290: [<600233c8>] hard_handler+0x10/0x14 602352a8: [<60013a12>] show_trace+0x8e/0x95 602352d8: [<60026e34>] show_regs+0x2b/0x2f 60235308: [<60014b03>] segv+0xfa/0x212 60235318: [<60110675>] cfq_close_cooperator+0x39/0x160 602353e8: [<60014c7a>] segv_handler+0x5f/0x65 60235418: [<60021698>] sig_handler_common+0x84/0x98 602354a0: [<60110675>] cfq_close_cooperator+0x39/0x160 60235548: [<600217de>] sig_handler+0x30/0x3b 60235568: [<60021a10>] handle_signal+0x6d/0xa3 602355b8: [<600233c8>] hard_handler+0x10/0x14 60235678: [<60110675>] cfq_close_cooperator+0x39/0x160 60235708: [<60040bb3>] autoremove_wake_function+0x11/0x34 60235728: [<60040bfe>] wake_bit_function+0x28/0x2e 60235738: [<600276db>] __wake_up_common+0x44/0x7a 60235778: [<60075913>] kmem_cache_free+0x54/0x5f 602357b8: [<60057f6e>] mempool_free_slab+0x12/0x14 602357c8: [<6005803c>] mempool_free+0x6f/0x76 602357f8: [<6009ae62>] bio_free+0x4d/0x52 60235808: [<6011066c>] cfq_close_cooperator+0x30/0x160 60235828: [<60110bae>] cfq_completed_request+0x375/0x4db 60235888: [<601053ee>] elv_completed_request+0x4e/0xaf 602358a8: [<601068be>] __blk_put_request+0x37/0xbd 602358d8: [<60106acf>] blk_finish_request+0x18b/0x198 60235918: [<60106d85>] blk_end_bidi_request+0x38/0x4b 60235948: [<60106dca>] blk_end_request+0xb/0xd 60235958: [<6001cf86>] ubd_intr+0x55/0xd7 60235998: [<600527a2>] handle_IRQ_event+0x20/0x9a 602359c8: [<60052889>] __do_IRQ+0x6d/0xb0 602359f8: [<6001217f>] do_IRQ+0x27/0x3f 60235a28: [<6001234f>] sigio_handler+0x4b/0x5f 60235a48: [<60021698>] sig_handler_common+0x84/0x98 60235a68: [<60021745>] real_alarm_handler+0x3c/0x3e 60235af0: [<60095b01>] copy_fs_struct+0xc/0x76 60235b78: [<600217de>] sig_handler+0x30/0x3b 60235b98: [<60021a10>] handle_signal+0x6d/0xa3 60235be8: [<600233c8>] hard_handler+0x10/0x14 Modules linked in: Pid: 0, comm: swapper Not tainted 2.6.34-08406-g52b0ace-dirty RIP: 0000:[<0000000000000000>] RSP: 0000000000000000 EFLAGS: 00000000 RAX: 0000000000000000 RBX: 0000000000000000 RCX: 0000000000000000 RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000000 RBP: 0000000000000000 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000000 R12: 0000000000000000 R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000 Call Trace: 602351a8: [<60014de7>] panic_exit+0x2f/0x45 602351b0: [<600233c8>] hard_handler+0x10/0x14 602351c8: [<600441ea>] notifier_call_chain+0x32/0x5e 60235208: [<60044230>] atomic_notifier_call_chain+0xf/0x11 60235218: [<6018faf6>] panic+0xff/0x14f 60235278: [<6004db6b>] is_module_text_address+0x9/0x11 60235288: [<6003ecdc>] __kernel_text_address+0x65/0x6b 60235290: [<600233c8>] hard_handler+0x10/0x14 602352a8: [<60013a12>] show_trace+0x8e/0x95 602352d8: [<60026e34>] show_regs+0x2b/0x2f 60235308: [<60014b03>] segv+0xfa/0x212 60235318: [<60110675>] cfq_close_cooperator+0x39/0x160 602353e8: [<60014c7a>] segv_handler+0x5f/0x65 60235418: [<60021698>] sig_handler_common+0x84/0x98 602354a0: [<60110675>] cfq_close_cooperator+0x39/0x160 60235548: [<600217de>] sig_handler+0x30/0x3b 60235568: [<60021a10>] handle_signal+0x6d/0xa3 602355b8: [<600233c8>] hard_handler+0x10/0x14 60235678: [<60110675>] cfq_close_cooperator+0x39/0x160 60235708: [<60040bb3>] autoremove_wake_function+0x11/0x34 60235728: [<60040bfe>] wake_bit_function+0x28/0x2e 60235738: [<600276db>] __wake_up_common+0x44/0x7a 60235778: [<60075913>] kmem_cache_free+0x54/0x5f 602357b8: [<60057f6e>] mempool_free_slab+0x12/0x14 602357c8: [<6005803c>] mempool_free+0x6f/0x76 602357f8: [<6009ae62>] bio_free+0x4d/0x52 60235808: [<6011066c>] cfq_close_cooperator+0x30/0x160 60235828: [<60110bae>] cfq_completed_request+0x375/0x4db 60235888: [<601053ee>] elv_completed_request+0x4e/0xaf 602358a8: [<601068be>] __blk_put_request+0x37/0xbd 602358d8: [<60106acf>] blk_finish_request+0x18b/0x198 60235918: [<60106d85>] blk_end_bidi_request+0x38/0x4b 60235948: [<60106dca>] blk_end_request+0xb/0xd 60235958: [<6001cf86>] ubd_intr+0x55/0xd7 60235998: [<600527a2>] handle_IRQ_event+0x20/0x9a 602359c8: [<60052889>] __do_IRQ+0x6d/0xb0 602359f8: [<6001217f>] do_IRQ+0x27/0x3f 60235a28: [<6001234f>] sigio_handler+0x4b/0x5f 60235a48: [<60021698>] sig_handler_common+0x84/0x98 60235a68: [<60021745>] real_alarm_handler+0x3c/0x3e 60235af0: [<60095b01>] copy_fs_struct+0xc/0x76 60235b78: [<600217de>] sig_handler+0x30/0x3b 60235b98: [<60021a10>] handle_signal+0x6d/0xa3 60235be8: [<600233c8>] hard_handler+0x10/0x14 Kernel panic - not syncing: Kernel mode signal 4 Call Trace: 71040128: [<6018fadb>] panic+0xe4/0x14f 71040218: [<600146ee>]Terminated Gr{oetje,eeting}s, Geert -- Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@li... In personal conversations with technical people, I call myself a hacker. But when I'm talking to journalists I just say "programmer" or something like that. -- Linus Torvalds |
From: Borislav P. <bp...@al...> - 2010-05-30 15:21:55
|
From: Geert Uytterhoeven <ge...@li...> Date: Sun, May 30, 2010 at 01:57:05PM +0200 > On Sun, May 30, 2010 at 13:39, Geert Uytterhoeven <ge...@li...> wrote: > > 2010/5/27 Toralf Förster <tor...@gm...>: > >> I bisected it to this : > > > After fixing the missing/superfluous slab inclusion issues, I bisected > > it further to > > > > commit d61931d89be506372d01a90d1755f6d0a9fafe2d > > Author: Borislav Petkov <bor...@am...> > > Date: Fri Mar 5 17:34:46 2010 +0100 > > > > x86: Add optimized popcnt variants > > > > Add support for the hardware version of the Hamming weight function, > > popcnt, present in CPUs which advertize it under CPUID, Function > > 0x0000_0001_ECX[23]. On CPUs which don't support it, we fallback to the > > default lib/hweight.c sw versions. > > > > A synthetic benchmark comparing popcnt with __sw_hweight64 showed almost > > a 3x speedup on a F10h machine. > > > > Signed-off-by: Borislav Petkov <bor...@am...> > > LKML-Reference: <20100318112015.GC11152@aftab> > > Signed-off-by: H. Peter Anvin <hp...@zy...> > > > > I reverted that commit on top of current mainline (and fixed up the > > conflicts), and now > > it boots again. > > I tried adding > > config ARCH_HWEIGHT_CFLAGS > string > default "-fcall-saved-ecx -fcall-saved-edx" if !64_BIT > default "-fcall-saved-rdi -fcall-saved-rsi -fcall-saved-rdx > -fcall-saved-rcx -fcall-saved-r8 -fcall-saved-r9 -fcall-saved-r10 > -fcall-saved-r11" if 64_BIT > > to arch/um/Kconfig.x86. Now it got a bit further, but it still crashes: Ok, this is a kinda stab in the dark but from what I could decypher from the include hell, one possible fix should be if UML didn't include <arch/x86/include/asm/arch_hweight.h> but use the software hweight version only. Can you guys check whether the following fixes the issue? Thanks. -- diff --git a/arch/x86/include/asm/bitops.h b/arch/x86/include/asm/bitops.h index 545776e..c9dad12 100644 --- a/arch/x86/include/asm/bitops.h +++ b/arch/x86/include/asm/bitops.h @@ -444,7 +444,11 @@ static inline int fls(int x) #define ARCH_HAS_FAST_MULTIPLIER 1 +#ifdef CONFIG_UML +#include <asm-generic/bitops/arch_hweight.h> +#else #include <asm/arch_hweight.h> +#endif #include <asm-generic/bitops/const_hweight.h> -- Regards/Gruss, Boris. |
From: Paolo G. <p.g...@gm...> - 2010-06-12 16:02:11
|
On Sat, Jun 12, 2010 at 16:18, Borislav Petkov <bp...@al...> wrote: > From: Paolo Giarrusso <p.g...@gm...> > Date: Sat, Jun 12, 2010 at 03:34:38PM +0200 > > Hi, > >> > That looks better to me, although I'm still wondering why UML can't >> > stomach the register-saving tricks... it is not at all "obvious" why >> > that can't be done. >> Hi all, and sorry for the delay, I hope you still care about this. >> >> First, ARCH_HWEIGHT_CFLAGS should IMHO be shared with UML. I.e., moved >> to arch/x86/Kconfig.cpu (which was born as Kconfig code shared with >> UML), or copied in UML (it's not defined, as far as I can see). >> Otherwise it just can't work. And I think that's it. Just to be sure: by "that's it" I meant "this is the problem". You didn't answer here - did you see it? What do you think? Can you try the one-line fix at some point? Just to make it clear: I've not been actively developing UML (or almost anything in kernel space) for ages (~4 years), so it's unlikely that I'll try fixing this. It just happens that things on the UML front stayed mostly the same, so I thought that my knowledge of the code is still useful. >> Second, I've been looking at arch_hweight.h to try answering as well, >> and my question is: did somebody ever implement ALTERNATIVE support on >> UML? When I worked on it, this thing didn't exist at all. The user >> declared the host CPU, and we enabled features based on that. There's >> barely code for exception tables, and we never used it to implement >> copy_from_user and staff like that (I recall the exception handler was >> set at run-time). >> Indeed, arch/um/kernel/um_arch.c:apply_alternatives() is empty. And I >> mean, implementing it is not so trivial (unlike exception handling), >> simply because it requires making the binary mapping writable, and I'm >> not sure UML does it already. > Which would mean that UML doesn't use alternatives at all and uses the > instructions which are meant to be replaced instead, no? Exactly. > In that case, > fixing this is either by rerouting the includes (easiest, already in > -tip) or adding alternatives support (harder, needs volunteers :)). Well, even doing just nothing should work, if you fix the trivial thing above (which at least for 64bit should work). >> A third note is that UML links with glibc, so it can have a different >> calling convention from the kernel. Say, on x86 32bit regparm doesn't >> work (in fact, -mregparm is set in arch/x86/Makefile and not in >> arch/x86/Makefile_32.cpu). And since popcnt is supported on 32bit, it >> might in theory make a difference for that case. But maybe those flags >> are simply fine, I didn't recheck the possible calling conventions. > If this is also the case, the -fcall-saved-* stuff won't work on UML and > yet another way of doing "call *func" from within asm("...") and making > sure the callee doesn't clobber caller's regs will be needed for UML. Hmpf... anyway, 64bit should be fine since there's just one calling convention, everywhere, and already regparm'ed. Regards -- Paolo Giarrusso - Ph.D. Student http://www.informatik.uni-marburg.de/~pgiarrusso/ |
From: Borislav P. <bp...@al...> - 2010-06-12 16:35:59
|
From: Paolo Giarrusso <p.g...@gm...> Date: Sat, Jun 12, 2010 at 06:01:44PM +0200 > >> First, ARCH_HWEIGHT_CFLAGS should IMHO be shared with UML. I.e., moved > >> to arch/x86/Kconfig.cpu (which was born as Kconfig code shared with > >> UML), or copied in UML (it's not defined, as far as I can see). > >> Otherwise it just can't work. And I think that's it. > > Just to be sure: by "that's it" I meant "this is the problem". > You didn't answer here - did you see it? What do you think? Can you > try the one-line fix at some point? > Just to make it clear: I've not been actively developing UML (or > almost anything in kernel space) for ages (~4 years), so it's unlikely > that I'll try fixing this. It just happens that things on the UML > front stayed mostly the same, so I thought that my knowledge of the > code is still useful. Cool :). However, according to Geert, this doesn't fix it: http://marc.info/?l=linux-kernel&m=127522065202435&w=2 It could be related to the -mregparm being broken on 32-bit UML since Geert's UML "guest" is 32-bit. However, even if we fix this, it won't be used since, as you said, UML doesn't do alternatives. Which means that it doesn't make sense fixing it until there are no alternatives - instead, we should simply fall back to the software hweight* stuff and be done with it. > > In that case, fixing this is either by rerouting the includes > > (easiest, already in -tip) or adding alternatives support (harder, > > needs volunteers :)). > > Well, even doing just nothing should work, if you fix the trivial > thing above (which at least for 64bit should work). See above. > >> A third note is that UML links with glibc, so it can have a different > >> calling convention from the kernel. Say, on x86 32bit regparm doesn't > >> work (in fact, -mregparm is set in arch/x86/Makefile and not in > >> arch/x86/Makefile_32.cpu). And since popcnt is supported on 32bit, it > >> might in theory make a difference for that case. But maybe those flags > >> are simply fine, I didn't recheck the possible calling conventions. > > > If this is also the case, the -fcall-saved-* stuff won't work on UML and > > yet another way of doing "call *func" from within asm("...") and making > > sure the callee doesn't clobber caller's regs will be needed for UML. > > Hmpf... anyway, 64bit should be fine since there's just one calling > convention, everywhere, and already regparm'ed. Right, as I said, this would leave 32-bit broken which doesn't cut it either for a subset of people using UML. Thanks. -- Regards/Gruss, Boris. |
From: Geert U. <ge...@li...> - 2010-05-30 15:18:28
|
On Sun, May 30, 2010 at 17:02, Borislav Petkov <bp...@al...> wrote: > From: Geert Uytterhoeven <ge...@li...> > Date: Sun, May 30, 2010 at 01:57:05PM +0200 > >> On Sun, May 30, 2010 at 13:39, Geert Uytterhoeven <ge...@li...> wrote: >> > 2010/5/27 Toralf Förster <tor...@gm...>: >> >> I bisected it to this : >> >> > After fixing the missing/superfluous slab inclusion issues, I bisected >> > it further to >> > >> > commit d61931d89be506372d01a90d1755f6d0a9fafe2d >> > Author: Borislav Petkov <bor...@am...> >> > Date: Fri Mar 5 17:34:46 2010 +0100 >> > >> > x86: Add optimized popcnt variants >> > >> > Add support for the hardware version of the Hamming weight function, >> > popcnt, present in CPUs which advertize it under CPUID, Function >> > 0x0000_0001_ECX[23]. On CPUs which don't support it, we fallback to the >> > default lib/hweight.c sw versions. >> > >> > A synthetic benchmark comparing popcnt with __sw_hweight64 showed almost >> > a 3x speedup on a F10h machine. >> > >> > Signed-off-by: Borislav Petkov <bor...@am...> >> > LKML-Reference: <20100318112015.GC11152@aftab> >> > Signed-off-by: H. Peter Anvin <hp...@zy...> >> > >> > I reverted that commit on top of current mainline (and fixed up the >> > conflicts), and now >> > it boots again. >> >> I tried adding >> >> config ARCH_HWEIGHT_CFLAGS >> string >> default "-fcall-saved-ecx -fcall-saved-edx" if !64_BIT >> default "-fcall-saved-rdi -fcall-saved-rsi -fcall-saved-rdx >> -fcall-saved-rcx -fcall-saved-r8 -fcall-saved-r9 -fcall-saved-r10 >> -fcall-saved-r11" if 64_BIT >> >> to arch/um/Kconfig.x86. Now it got a bit further, but it still crashes: > > Ok, this is a kinda stab in the dark but from what I could decypher > from the include hell, one possible fix should be if UML didn't include > <arch/x86/include/asm/arch_hweight.h> but use the software hweight > version only. > > Can you guys check whether the following fixes the issue? Works, thanks! BTW, if you want to check yourself: make ARCH=um defconfig make ACH=um ./linux If it panics because it cannot mount the root file system, it works. > diff --git a/arch/x86/include/asm/bitops.h b/arch/x86/include/asm/bitops.h > index 545776e..c9dad12 100644 > --- a/arch/x86/include/asm/bitops.h > +++ b/arch/x86/include/asm/bitops.h > @@ -444,7 +444,11 @@ static inline int fls(int x) > > #define ARCH_HAS_FAST_MULTIPLIER 1 > > +#ifdef CONFIG_UML > +#include <asm-generic/bitops/arch_hweight.h> > +#else > #include <asm/arch_hweight.h> > +#endif > > #include <asm-generic/bitops/const_hweight.h> Gr{oetje,eeting}s, Geert -- Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@li... In personal conversations with technical people, I call myself a hacker. But when I'm talking to journalists I just say "programmer" or something like that. -- Linus Torvalds |
From: Borislav P. <bp...@al...> - 2010-05-30 15:47:09
|
From: Geert Uytterhoeven <ge...@li...> Date: Sun, May 30, 2010 at 05:18:21PM +0200 > Works, thanks! > > BTW, if you want to check yourself: > > make ARCH=um defconfig > make ACH=um > ./linux > > If it panics because it cannot mount the root file system, it works. Cool, thank you both for testing. I'll add your Tested-by:'s. -- Regards/Gruss, Boris. |
From: Toralf F. <tor...@gm...> - 2010-05-30 15:28:35
|
Borislav Petkov wrote at 17:02:14 > Can you guys check whether the following fixes the issue? > > Thanks. > > -- > diff --git a/arch/x86/include/asm/bitops.h b/arch/x86/include/asm/bitops.h > index 545776e..c9dad12 100644 > --- a/arch/x86/include/asm/bitops.h > +++ b/arch/x86/include/asm/bitops.h > @@ -444,7 +444,11 @@ static inline int fls(int x) > > #define ARCH_HAS_FAST_MULTIPLIER 1 > > +#ifdef CONFIG_UML > +#include <asm-generic/bitops/arch_hweight.h> > +#else > #include <asm/arch_hweight.h> > +#endif > > #include <asm-generic/bitops/const_hweight.h> > > > solved reported issue. Thx -- MfG/Sincerely Toralf Förster pgp finger print: 7B1A 07F4 EC82 0F90 D4C2 8936 872A E508 7DB6 9DA3 |
From: Borislav P. <bp...@al...> - 2010-05-30 17:03:58
|
Obviously UML cannot stomach callee reg-saving trickery introduced with d61931d89be506372d01a90d1755f6d0a9fafe2d (x86: Add optimized popcnt variants) and oopses during boot: http://marc.info/?l=linux-kernel&m=127522065202435&w=2 Go ahead and fall back to the software hweight* routines on UML. LKML-Reference: <201...@gm...> Tested-by: Toralf Förster <tor...@gm...> Tested-by: Geert Uytterhoeven <ge...@li...> Signed-off-by: Borislav Petkov <bp...@al...> --- arch/x86/include/asm/bitops.h | 4 ++++ 1 files changed, 4 insertions(+), 0 deletions(-) diff --git a/arch/x86/include/asm/bitops.h b/arch/x86/include/asm/bitops.h index 545776e..c9dad12 100644 --- a/arch/x86/include/asm/bitops.h +++ b/arch/x86/include/asm/bitops.h @@ -444,7 +444,11 @@ static inline int fls(int x) #define ARCH_HAS_FAST_MULTIPLIER 1 +#ifdef CONFIG_UML +#include <asm-generic/bitops/arch_hweight.h> +#else #include <asm/arch_hweight.h> +#endif #include <asm-generic/bitops/const_hweight.h> -- 1.7.1 -- Regards/Gruss, Boris. |
From: H. P. A. <hp...@zy...> - 2010-05-30 19:16:16
|
On 05/30/2010 10:03 AM, Borislav Petkov wrote: > Obviously UML cannot stomach callee reg-saving trickery > introduced with d61931d89be506372d01a90d1755f6d0a9fafe2d (x86: > Add optimized popcnt variants) and oopses during boot: > http://marc.info/?l=linux-kernel&m=127522065202435&w=2 > > Go ahead and fall back to the software hweight* routines on UML. I actually don't understand why UML can't stomach that... it would work exactly the same in userspace as in kernel space. The only thing that I can think of is if UML overrides the CFLAGS including the per-file CFLAGS, but that would seem to cause all kinds of other issues. I would also be a lot happier if this was handled in <asm/arch_hweight.h> than in <asm/bitops.h>. Finally, if UML really can't handle this, then ARCH_HWEIGHT_CFLAGS should be disabled on UML. This bothers me, because it really feels like something is fundamentally broken in UML tryingto track the upstream architecture, and this is just a bandage. -hpa -- H. Peter Anvin, Intel Open Source Technology Center I work for Intel. I don't speak on their behalf. |
From: Geert U. <ge...@li...> - 2010-06-12 18:37:46
|
On Sat, Jun 12, 2010 at 18:34, Borislav Petkov <bp...@al...> wrote: > From: Paolo Giarrusso <p.g...@gm...> > Date: Sat, Jun 12, 2010 at 06:01:44PM +0200 > >> >> First, ARCH_HWEIGHT_CFLAGS should IMHO be shared with UML. I.e., moved >> >> to arch/x86/Kconfig.cpu (which was born as Kconfig code shared with >> >> UML), or copied in UML (it's not defined, as far as I can see). >> >> Otherwise it just can't work. And I think that's it. >> >> Just to be sure: by "that's it" I meant "this is the problem". >> You didn't answer here - did you see it? What do you think? Can you >> try the one-line fix at some point? >> Just to make it clear: I've not been actively developing UML (or >> almost anything in kernel space) for ages (~4 years), so it's unlikely >> that I'll try fixing this. It just happens that things on the UML >> front stayed mostly the same, so I thought that my knowledge of the >> code is still useful. > > Cool :). However, according to Geert, this doesn't fix it: > > http://marc.info/?l=linux-kernel&m=127522065202435&w=2 > > It could be related to the -mregparm being broken on 32-bit UML since > Geert's UML "guest" is 32-bit. However, even if we fix this, it won't No, guest and host are both x86_64. > be used since, as you said, UML doesn't do alternatives. Which means > that it doesn't make sense fixing it until there are no alternatives - > instead, we should simply fall back to the software hweight* stuff and > be done with it. > >> > In that case, fixing this is either by rerouting the includes >> > (easiest, already in -tip) or adding alternatives support (harder, >> > needs volunteers :)). >> >> Well, even doing just nothing should work, if you fix the trivial >> thing above (which at least for 64bit should work). > > See above. > >> >> A third note is that UML links with glibc, so it can have a different >> >> calling convention from the kernel. Say, on x86 32bit regparm doesn't >> >> work (in fact, -mregparm is set in arch/x86/Makefile and not in >> >> arch/x86/Makefile_32.cpu). And since popcnt is supported on 32bit, it >> >> might in theory make a difference for that case. But maybe those flags >> >> are simply fine, I didn't recheck the possible calling conventions. >> >> > If this is also the case, the -fcall-saved-* stuff won't work on UML and >> > yet another way of doing "call *func" from within asm("...") and making >> > sure the callee doesn't clobber caller's regs will be needed for UML. >> >> Hmpf... anyway, 64bit should be fine since there's just one calling >> convention, everywhere, and already regparm'ed. > > Right, as I said, this would leave 32-bit broken which doesn't cut it > either for a subset of people using UML. Gr{oetje,eeting}s, Geert -- Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@li... In personal conversations with technical people, I call myself a hacker. But when I'm talking to journalists I just say "programmer" or something like that. -- Linus Torvalds |
From: Borislav P. <bp...@al...> - 2010-06-13 06:58:49
|
From: Geert Uytterhoeven <ge...@li...> Date: Sat, Jun 12, 2010 at 08:37:39PM +0200 > > Cool :). However, according to Geert, this doesn't fix it: > > > > http://marc.info/?l=linux-kernel&m=127522065202435&w=2 > > > > It could be related to the -mregparm being broken on 32-bit UML since > > Geert's UML "guest" is 32-bit. However, even if we fix this, it won't > > No, guest and host are both x86_64. Ok, maybe I don't understand UML - it's just that all address values in the backtrace are 32-bit (e.g. RDX: 00000000ffff8aed, with the upper 8 bytes zeroed out) and I assumed that this is a 32-bit "guest" on a 64-bit host. -- Regards/Gruss, Boris. |
From: Borislav P. <bp...@al...> - 2010-05-30 19:40:12
|
From: "H. Peter Anvin" <hp...@zy...> Date: Sun, May 30, 2010 at 11:36:16AM -0700 > On 05/30/2010 10:03 AM, Borislav Petkov wrote: > > Obviously UML cannot stomach callee reg-saving trickery > > introduced with d61931d89be506372d01a90d1755f6d0a9fafe2d (x86: > > Add optimized popcnt variants) and oopses during boot: > > http://marc.info/?l=linux-kernel&m=127522065202435&w=2 > > > > Go ahead and fall back to the software hweight* routines on UML. > > I actually don't understand why UML can't stomach that... it would work > exactly the same in userspace as in kernel space. The only thing that I > can think of is if UML overrides the CFLAGS including the per-file > CFLAGS, but that would seem to cause all kinds of other issues. > > I would also be a lot happier if this was handled in > <asm/arch_hweight.h> than in <asm/bitops.h>. Finally, if UML really > can't handle this, then ARCH_HWEIGHT_CFLAGS should be disabled on UML. > > This bothers me, because it really feels like something is fundamentally > broken in UML tryingto track the upstream architecture, and this is just > a bandage. First of all, scratch that patch. It is indeed dumb idea to sprinkle UML special cases in x86 just because they include it. Which begs the question why _is_ UML sucking in x86 stuff and can anyone provide us with some sensible reasons? Because if there aren't any, it is their includes that should be fixed. Let me see what I can do to redirect hweight stuff properly... -- Regards/Gruss, Boris. |
From: Borislav P. <bp...@al...> - 2010-05-30 20:17:50
|
> > This bothers me, because it really feels like something is fundamentally > > broken in UML tryingto track the upstream architecture, and this is just > > a bandage. > > First of all, scratch that patch. It is indeed dumb idea to sprinkle UML > special cases in x86 just because they include it. > > Which begs the question why _is_ UML sucking in x86 stuff and can anyone > provide us with some sensible reasons? Because if there aren't any, it > is their includes that should be fixed. Let me see what I can do to > redirect hweight stuff properly... Ok, AFAICT UML is sucking in the includes of the sub-architecture the UML "guest" is running on. See below¹ for the whole gcc string make executes. Among the switches is "-I/home/boris/kernel/linux-2.6/arch/x86/include" so there will be no untangling today. Instead, we could do another bandaid which is confined to UML include space only and redirect arch_hweight.h includes to the generic ones. Check this out, it seems to work here: -- From: Borislav Petkov <bp...@al...> Date: Sun, 30 May 2010 22:11:32 +0200 Subject: [PATCH] um, hweight: Fix UML boot crash Obviously UML cannot stomach callee reg-saving trickery introduced with d61931d89be506372d01a90d1755f6d0a9fafe2d (x86: Add optimized popcnt variants) and oopses during boot: http://marc.info/?l=linux-kernel&m=127522065202435&w=2 Redirect arch_hweight.h include from the x86 portion to the generic arch_hweight.h which is a fallback to the software hweight routines. LKML-Reference: <201...@gm...> Signed-off-by: Borislav Petkov <bp...@al...> --- arch/um/include/asm/arch_hweight.h | 6 ++++++ 1 files changed, 6 insertions(+), 0 deletions(-) create mode 100644 arch/um/include/asm/arch_hweight.h diff --git a/arch/um/include/asm/arch_hweight.h b/arch/um/include/asm/arch_hweight.h new file mode 100644 index 0000000..c656cf4 --- /dev/null +++ b/arch/um/include/asm/arch_hweight.h @@ -0,0 +1,6 @@ +#ifndef _ASM_UM_HWEIGHT_H +#define _ASM_UM_HWEIGHT_H + +#include <asm-generic/bitops/arch_hweight.h> + +#endif -- 1.7.1 ¹ gcc -Wp,-MD,arch/um/sys-x86_64/.delay.o.d -nostdinc -isystem /usr/lib/gcc/x86_64-linux-gnu/4.4.4/include -I/home/boris/kernel/linux-2.6/arch/um/include -Iinclude -include include/generated/autoconf.h -D__KERNEL__ -I/home/boris/kernel/linux-2.6/arch/um/sys-x86_64 -m64 -I/home/boris/kernel/linux-2.6/arch/x86/include -Wall -Wundef -Wstrict-prototypes -Wno-trigraphs -fno-strict-aliasing -fno-common -Werror-implicit-function-declaration -Wno-format-security -fno-delete-null-pointer-checks -Os -D__arch_um__ -DSUBARCH=\"x86_64\" -I/home/boris/kernel/linux-2.6/arch/um/include/shared -I/home/boris/kernel/linux-2.6/arch/um/sys-x86_64/shared -I/home/boris/kernel/linux-2.6/arch/um/include/shared/skas -Dvmap=kernel_vmap -Din6addr_loopback=kernel_in6addr_loopback -Din6addr_any=kernel_in6addr_any -fno-builtin -m64 -funit-at-a-time -D_LARGEFILE64_SOURCE -Derrno=kernel_errno -Dsigprocmask=kernel_sigprocmask -Dmktime=kernel_mktime -Wframe-larger-than=2048 -fno-stack-protector -fno-omit-frame-pointer -fno-optimize-sibling-calls -g -Wdeclaration-after-statement -Wno-pointer-sign -fno-strict-overflow -fno-dwarf2-cfi-asm -fconserve-stack -D"KBUILD_STR(s)=\#s" -D"KBUILD_BASENAME=KBUILD_STR(delay)" -D"KBUILD_MODNAME=KBUILD_STR(delay)" -c -o arch/um/sys-x86_64/delay.o arch/um/sys-x86_64/delay.c -- Regards/Gruss, Boris. |
From: H. P. A. <hp...@zy...> - 2010-05-30 21:13:20
|
On 05/30/2010 01:17 PM, Borislav Petkov wrote: >>> This bothers me, because it really feels like something is fundamentally >>> broken in UML tryingto track the upstream architecture, and this is just >>> a bandage. >> >> First of all, scratch that patch. It is indeed dumb idea to sprinkle UML >> special cases in x86 just because they include it. >> >> Which begs the question why _is_ UML sucking in x86 stuff and can anyone >> provide us with some sensible reasons? Because if there aren't any, it >> is their includes that should be fixed. Let me see what I can do to >> redirect hweight stuff properly... > > Ok, AFAICT UML is sucking in the includes of the sub-architecture the > UML "guest" is running on. See below¹ for the whole gcc string make > executes. Among the switches is > > "-I/home/boris/kernel/linux-2.6/arch/x86/include" > > so there will be no untangling today. Instead, we could do another > bandaid which is confined to UML include space only and redirect > arch_hweight.h includes to the generic ones. Check this out, it seems to > work here: > That looks better to me, although I'm still wondering why UML can't stomach the register-saving tricks... it is not at all "obvious" why that can't be done. Perhaps we can get Jeff to comment on this? -hpa -- H. Peter Anvin, Intel Open Source Technology Center I work for Intel. I don't speak on their behalf. |
From: Toralf F. <tor...@gm...> - 2010-05-31 13:56:09
|
Borislav Petkov wrote at 22:17:38 > LKML-Reference: <201...@gm...> > Signed-off-by: Borislav Petkov <bp...@al...> > --- > arch/um/include/asm/arch_hweight.h | 6 ++++++ > 1 files changed, 6 insertions(+), 0 deletions(-) > create mode 100644 arch/um/include/asm/arch_hweight.h > > diff --git a/arch/um/include/asm/arch_hweight.h b/arch/um/include/asm/arch_hweight.h > new file mode 100644 > index 0000000..c656cf4 > --- /dev/null > +++ b/arch/um/include/asm/arch_hweight.h > @@ -0,0 +1,6 @@ > +#ifndef _ASM_UM_HWEIGHT_H > +#define _ASM_UM_HWEIGHT_H > + > +#include <asm-generic/bitops/arch_hweight.h> > + > +#endif > This patch does not to solve the reported issue by me. -- MfG/Sincerely Toralf Förster pgp finger print: 7B1A 07F4 EC82 0F90 D4C2 8936 872A E508 7DB6 9DA3 |
From: Boaz H. <bha...@pa...> - 2010-05-31 14:37:54
|
On 05/31/2010 04:55 PM, Toralf Förster wrote: > > Borislav Petkov wrote at 22:17:38 >> LKML-Reference: <201...@gm...> >> Signed-off-by: Borislav Petkov <bp...@al...> >> --- >> arch/um/include/asm/arch_hweight.h | 6 ++++++ >> 1 files changed, 6 insertions(+), 0 deletions(-) >> create mode 100644 arch/um/include/asm/arch_hweight.h >> >> diff --git a/arch/um/include/asm/arch_hweight.h b/arch/um/include/asm/arch_hweight.h >> new file mode 100644 >> index 0000000..c656cf4 >> --- /dev/null >> +++ b/arch/um/include/asm/arch_hweight.h >> @@ -0,0 +1,6 @@ >> +#ifndef _ASM_UM_HWEIGHT_H >> +#define _ASM_UM_HWEIGHT_H >> + >> +#include <asm-generic/bitops/arch_hweight.h> >> + >> +#endif >> > This patch does not to solve the reported issue by me. > Watch out. It did fix it for me but only after a deep clean. (mrproper) Makefile does not pick up this dependency. Also I could not use my 2.6.34 config file. I had to do make defconfig, and then xconfig all my extra stuff. But this is regular for any Kernel upgrade and UML. It does fix my setup. (Wouldn't load before this) Boaz |
From: Jeff D. <jd...@ad...> - 2010-05-31 14:12:18
|
On Sun, May 30, 2010 at 09:39:56PM +0200, Borislav Petkov wrote: > Which begs the question why _is_ UML sucking in x86 stuff and can anyone > provide us with some sensible reasons? Because if there aren't any, it > is their includes that should be fixed. Let me see what I can do to > redirect hweight stuff properly... Generally, UML pulls in the host arch headers because they work. When they are only architecture-dependent (and not, say, depending on the host task struct or something), they're fine. What's the include path from UML to the x86 hweight stuff? Jeff -- Work email - jdike at linux dot intel dot com |
From: Borislav P. <bor...@am...> - 2010-05-31 13:51:35
|
From: Jeff Dike <jd...@ad...> Date: Sun, May 30, 2010 at 10:32:12PM -0400 > On Sun, May 30, 2010 at 09:39:56PM +0200, Borislav Petkov wrote: > > Which begs the question why _is_ UML sucking in x86 stuff and can anyone > > provide us with some sensible reasons? Because if there aren't any, it > > is their includes that should be fixed. Let me see what I can do to > > redirect hweight stuff properly... > > Generally, UML pulls in the host arch headers because they work. When > they are only architecture-dependent (and not, say, depending on the > host task struct or something), they're fine. > > What's the include path from UML to the x86 hweight stuff? <arch/x86/include/asm/bitops.h> includes <asm/arch_hweight.h> which are the optimized variants. I have a patch which with which UML falls back to the defaults: http://marc.info/?l=linux-kernel&m=127525067908139&w=2 but hpa's concern is still valid: UML shouldn't choke on the optimized variants. Anyways, here's the original commit d61931d89be506372d01a90d1755f6d0a9fafe2d - you might be able to find something which interferes with UML in there. Thanks. -- Regards/Gruss, Boris. Operating Systems Research Center Advanced Micro Devices, Inc. |
From: Jeff D. <jd...@ad...> - 2010-05-31 15:57:05
|
On Mon, May 31, 2010 at 03:51:32PM +0200, Borislav Petkov wrote: > <arch/x86/include/asm/bitops.h> includes <asm/arch_hweight.h> which are > the optimized variants. But how does UML get to arch/x86/include/asm/bitops.h in the first place? It must go through an arch/um/include/asm/something.h (where something might be bitops) first, right? Jeff -- Work email - jdike at linux dot intel dot com |
From: Borislav P. <bor...@am...> - 2010-05-31 16:29:44
|
From: Jeff Dike <jd...@ad...> Date: Mon, May 31, 2010 at 11:56:19AM -0400 > On Mon, May 31, 2010 at 03:51:32PM +0200, Borislav Petkov wrote: > > <arch/x86/include/asm/bitops.h> includes <asm/arch_hweight.h> which are > > the optimized variants. > > But how does UML get to arch/x86/include/asm/bitops.h in the first place? > > It must go through an arch/um/include/asm/something.h (where something > might be bitops) first, right? Right, look at one of those dependencies file (for example, arch/um/kernel/.ptrace.o.cmd) for a _very_ long inclusion chain which contains <arch/x86/include/asm/arch_hweight.h> at some point. -- Regards/Gruss, Boris. Operating Systems Research Center Advanced Micro Devices, Inc. |
From: Borislav P. <bor...@am...> - 2010-05-31 14:11:07
|
From: Toralf Förster <tor...@gm...> Date: Mon, May 31, 2010 at 09:55:53AM -0400 > Borislav Petkov wrote at 22:17:38 > > LKML-Reference: <201...@gm...> > > Signed-off-by: Borislav Petkov <bp...@al...> > > --- > > arch/um/include/asm/arch_hweight.h | 6 ++++++ > > 1 files changed, 6 insertions(+), 0 deletions(-) > > create mode 100644 arch/um/include/asm/arch_hweight.h > > > > diff --git a/arch/um/include/asm/arch_hweight.h b/arch/um/include/asm/arch_hweight.h > > new file mode 100644 > > index 0000000..c656cf4 > > --- /dev/null > > +++ b/arch/um/include/asm/arch_hweight.h > > @@ -0,0 +1,6 @@ > > +#ifndef _ASM_UM_HWEIGHT_H > > +#define _ASM_UM_HWEIGHT_H > > + > > +#include <asm-generic/bitops/arch_hweight.h> > > + > > +#endif > > > This patch does not to solve the reported issue by me. Did you do 'make mrproper' before rebuilding UML with it? Also, can you do grep -EriIn 'x86.*hweight\.h' arch/um/ after having applied the patch? You shouldn't be getting any matches. If it still fails then, then it is something else since with this patch, UML includes the standard hweight* routines. -- Regards/Gruss, Boris. Operating Systems Research Center Advanced Micro Devices, Inc. |
From: Toralf F. <tor...@gm...> - 2010-05-31 14:37:06
Attachments:
.config
|
Borislav Petkov wrote at 16:10:58 > Did you do 'make mrproper' before rebuilding UML with it? Yes, I did "make mrproper ARC H= um" and "make mrproper" > Also, can you do > > grep -EriIn 'x86.*hweight\.h' arch/um/ tfoerste@n22 ~/devel/linux-2.6 $ grep -EriIn 'x86.*hweight\.h' arch/um/ tfoerste@n22 ~/devel/linux-2.6 $ And here : tfoerste@n22 ~/devel/linux-2.6 $ tail arch/um/include/asm/arch_hweight.h #ifndef _ASM_UM_HWEIGHT_H #define _ASM_UM_HWEIGHT_H #include <asm-generic/bitops/arch_hweight.h> #endif What I get is this : tfoerste@n22 ~/devel/linux-2.6 $ ./linux Locating the bottom of the address space ... 0x1000 Locating the top of the address space ... 0xc0000000 Core dump limits : soft - NONE hard - NONE Checking that ptrace can change system call numbers...OK Checking syscall emulation patch for ptrace...OK Checking advanced syscall emulation patch for ptrace...OK Checking for tmpfs mount on /dev/shm...OK Checking PROT_EXEC mmap in /dev/shm/...OK Checking for the skas3 patch in the host: - /proc/mm...not found: No such file or directory - PTRACE_FAULTINFO...not found - PTRACE_LDT...not found UML running in SKAS0 mode Adding 20832256 bytes to physical memory to account for exec-shield gap Linux version 2.6.35-rc1 (tfoerste@n22) (gcc version 4.3.4 (Gentoo 4.3.4 p1.1, pie-10.1.5) ) #1 Mon May 31 16:33:40 CEST 2010 Built 1 zonelists in Zone order, mobility grouping on. Total pages: 13174 Kernel command line: root=98:0 PID hash table entries: 256 (order: -2, 1024 bytes) Dentry cache hash table entries: 8192 (order: 3, 32768 bytes) Inode-cache hash table entries: 4096 (order: 2, 16384 bytes) Memory: 28816k available Hierarchical RCU implementation. RCU-based detection of stalled CPUs is disabled. Verbose stalled-CPUs detection is disabled. NR_IRQS:15 Calibrating delay loop... 4679.27 BogoMIPS (lpj=23396352) pid_max: default: 32768 minimum: 301 Mount-cache hash table entries: 512 Checking for host processor cmov support...Yes Checking that host ptys support output SIGIO...Yes Checking that host ptys support SIGIO on close...No, enabling workaround Using 2.6 host AIO NET: Registered protocol family 16 bio: create slab <bio-0> at 0 Switching to clocksource itimer NET: Registered protocol family 2 IP route cache hash table entries: 1024 (order: 0, 4096 bytes) TCP established hash table entries: 2048 (order: 2, 16384 bytes) TCP bind hash table entries: 2048 (order: 1, 8192 bytes) TCP: Hash tables configured (established 2048 bind 2048) TCP reno registered UDP hash table entries: 256 (order: 0, 4096 bytes) UDP-Lite hash table entries: 256 (order: 0, 4096 bytes) NET: Registered protocol family 1 RPC: Registered udp transport module. RPC: Registered tcp transport module. RPC: Registered tcp NFSv4.1 backchannel transport module. mconsole (version 2) initialized on /home/tfoerste/.uml/xpp9B9/mconsole Checking host MADV_REMOVE support...OK UML Audio Relay (host dsp = /dev/sound/dsp, host mixer = /dev/sound/mixer) Host TLS support detected Detected host type: i386 (GDT indexes 6 to 9) Installing knfsd (copyright (C) 1996 ok...@mo...). msgmni has been set to 56 alg: No test for stdrng (krng) io scheduler noop registered io scheduler cfq registered (default) tun: Universal TUN/TAP device driver, 1.6 tun: (C) 1999-2004 Max Krasnyansky <ma...@qu...> TCP cubic registered NET: Registered protocol family 17 Initialized stdio console driver Console initialized on /dev/tty0 console [tty0] enabled Initializing software serial port version 1 console [mc-1] enabled Couldn't stat "root_fs" : err = 2 Failed to initialize ubd device 0 :Couldn't determine size of device's file VFS: Cannot open root device "98:0" or unknown-block(98,0) Please append a correct "root=" boot option; here are the available partitions: Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(98,0) 0ac5af10: [<08286f60>] panic+0x60/0xd9 0ac5af28: [<080499f4>] mount_block_root+0x160/0x286 0ac5af64: [<080e04f7>] sys_mknod+0x27/0x30 0ac5af78: [<08049b75>] mount_root+0x5b/0x60 0ac5af8c: [<08049c8c>] prepare_namespace+0x112/0x185 0ac5afa4: [<080491cc>] kernel_init+0x108/0x12e 0ac5afbc: [<0806ec90>] run_kernel_thread+0x30/0x60 0ac5afd8: [<0806ec7f>] run_kernel_thread+0x1f/0x60 0ac5afe4: [<0805d37b>] new_thread_handler+0x6b/0xa0 0ac5afe8: [<080490c4>] kernel_init+0x0/0x12e EIP: 0073:[<b784e424>] CPU: 0 Not tainted ESP: 007b:bfccdbdc EFLAGS: 00000246 Not tainted EAX: 00000000 EBX: 00004793 ECX: 00000013 EDX: 00004793 ESI: 0000478f EDI: 0000003b EBP: bfccdc68 DS: 007b ES: 007b 0ac5aeec: [<0809a074>] notifier_call_chain+0x34/0x70 0ac5af10: [<08286f88>] panic+0x88/0xd9 0ac5af28: [<080499f4>] mount_block_root+0x160/0x286 0ac5af64: [<080e04f7>] sys_mknod+0x27/0x30 0ac5af78: [<08049b75>] mount_root+0x5b/0x60 0ac5af8c: [<08049c8c>] prepare_namespace+0x112/0x185 0ac5afa4: [<080491cc>] kernel_init+0x108/0x12e 0ac5afbc: [<0806ec90>] run_kernel_thread+0x30/0x60 0ac5afd8: [<0806ec7f>] run_kernel_thread+0x1f/0x60 0ac5afe4: [<0805d37b>] new_thread_handler+0x6b/0xa0 0ac5afe8: [<080490c4>] kernel_init+0x0/0x12e Segmentation fault (core dumped) -- MfG/Sincerely Toralf Förster pgp finger print: 7B1A 07F4 EC82 0F90 D4C2 8936 872A E508 7DB6 9DA3 |
From: Paolo G. <p.g...@gm...> - 2010-06-12 14:02:15
|
On Sun, May 30, 2010 at 23:09, H. Peter Anvin <hp...@zy...> wrote: > On 05/30/2010 01:17 PM, Borislav Petkov wrote: >>>> This bothers me, because it really feels like something is fundamentally >>>> broken in UML tryingto track the upstream architecture, and this is just >>>> a bandage. >>> >>> First of all, scratch that patch. It is indeed dumb idea to sprinkle UML >>> special cases in x86 just because they include it. >>> >>> Which begs the question why _is_ UML sucking in x86 stuff and can anyone >>> provide us with some sensible reasons? Because if there aren't any, it >>> is their includes that should be fixed. Let me see what I can do to >>> redirect hweight stuff properly... >> >> Ok, AFAICT UML is sucking in the includes of the sub-architecture the >> UML "guest" is running on. See below¹ for the whole gcc string make >> executes. Among the switches is >> >> "-I/home/boris/kernel/linux-2.6/arch/x86/include" >> >> so there will be no untangling today. Instead, we could do another >> bandaid which is confined to UML include space only and redirect >> arch_hweight.h includes to the generic ones. Check this out, it seems to >> work here: >> > > That looks better to me, although I'm still wondering why UML can't > stomach the register-saving tricks... it is not at all "obvious" why > that can't be done. Hi all, and sorry for the delay, I hope you still care about this. First, ARCH_HWEIGHT_CFLAGS should IMHO be shared with UML. I.e., moved to arch/x86/Kconfig.cpu (which was born as Kconfig code shared with UML), or copied in UML (it's not defined, as far as I can see). Otherwise it just can't work. And I think that's it. Second, I've been looking at arch_hweight.h to try answering as well, and my question is: did somebody ever implement ALTERNATIVE support on UML? When I worked on it, this thing didn't exist at all. The user declared the host CPU, and we enabled features based on that. There's barely code for exception tables, and we never used it to implement copy_from_user and staff like that (I recall the exception handler was set at run-time). Indeed, arch/um/kernel/um_arch.c:apply_alternatives() is empty. And I mean, implementing it is not so trivial (unlike exception handling), simply because it requires making the binary mapping writable, and I'm not sure UML does it already. A third note is that UML links with glibc, so it can have a different calling convention from the kernel. Say, on x86 32bit regparm doesn't work (in fact, -mregparm is set in arch/x86/Makefile and not in arch/x86/Makefile_32.cpu). And since popcnt is supported on 32bit, it might in theory make a difference for that case. But maybe those flags are simply fine, I didn't recheck the possible calling conventions. Good bye! -- Paolo Giarrusso - Ph.D. Student http://www.informatik.uni-marburg.de/~pgiarrusso/ |