I've upgraded a Gentoo amd64 box to the latest gcc (4.1.1) and glibc
(2.4-r3). glibc 2.4 is "nptlonly" (at least on gentoo?)
The result is that all kernels just spin after mounting root:
sysrq-t shows all threads doing the same thing (switch_threads):
[42949405.030000] kjournald S 400029FB 0 720 6
589 (L-TLB)
[42949405.030000] 00000001 00000000 084d77f4 08747a3c 0877d780 0877d780
08747b94 08747a30
[42949405.030000] 08082919 00000000 00000016 00000000 00000000
00000000 08747a00 0000000f
[42949405.030000] 0000000f 08747a90 09898880 00000000 083dd3cc
00000041 0805f29d 00000001 Call Trace:
[42949405.030000] 08747a50: [<08082919>] switch_threads+0x2d/0x4d
[42949405.030000] 08747a88: [<0805f29d>] console_write_chan+0x2e/0x43
[42949405.030000] 08747aa8: [<0805eb18>] uml_console_write+0x34/0x44
[42949405.030000] 08747ac8: [<0808d0cc>] __call_console_drivers+0x39/0x45
[42949405.030000] 08747ae0: [<0805ddb0>] switch_to_skas+0x3c/0x8b
[42949405.030000] 08747afc: [<0805ae7a>] _switch_to+0x3a/0xc7
[42949405.030000] 08747b08: [<0808d5ff>] release_console_sem+0x66/0x9a
[42949405.030000] 08747b1c: [<080890e1>] deactivate_task+0x15/0x21
[42949405.030000] 08747b2c: [<08339bb0>] schedule+0x44a/0x4c7
[42949405.030000] 08747b68: [<0807f9a5>] set_signals+0x18/0x23
[42949405.030000] 08747b98: [<0813555b>] kjournald+0x152/0x1b9
[42949405.030000] 08747bb8: [<0809e917>] autoremove_wake_function+0x0/0x3a
[42949405.030000] 08747bd8: [<0809e917>] autoremove_wake_function+0x0/0x3a
[42949405.030000] 08747be8: [<0807f9a5>] set_signals+0x18/0x23
[42949405.030000] 08747bf8: [<08135409>] kjournald+0x0/0x1b9
[42949405.030000] 08747c00: [<0809e57c>] kthread+0x94/0xba
[42949405.030000] 08747c24: [<0809e4e8>] kthread+0x0/0xba
[42949405.030000] 08747c30: [<0807f164>] run_kernel_thread+0x44/0x50
[42949405.030000] 08747c40: [<0809e4e8>] kthread+0x0/0xba
[42949405.030000] 08747c50: [<0807f142>] run_kernel_thread+0x22/0x50
[42949405.030000] 08747cc0: [<08089454>] schedule_tail+0x24/0xca
[42949405.030000] 08747ce0: [<0805decf>] new_thread_handler+0xd0/0xff
[42949405.030000] 08747ce4: [<0809e4e8>] kthread+0x0/0xba
[42949405.030000] 08747d5c: [<082ed251>] __kill+0x11/0x20
[42949405.030000]
Which is quite strange because the kernel was working fine before and it
has the statically linked option (I guess it isn't entirely static...)
When they do manage to get past the hurdle above (sometimes), the kernel
then fails to run any binaries compiled with nptl support...
Some kernels show: "cannot set up thread-local storage: set_thread_area
failed when setting up thread-local storage" - which is strange (the
host definitely has nptl) but at least explains the guest issues.
But most kernels do not moan - they just silently fails to start anything.
It seems that there are a lot more issues with the ones compiled with
gcc4.1.1
The host is 2.6.17.11 + skas3.
The guests are 2.6.1x running in raw skas0 or skas3/noprocmm skas0.
(tried everything that has nptl from ~2.6.15-bs? to 2.6.18-rc5-mm1)
The exact same images run absolutely fine on x86 hosts with almost
identical settings (same gcc, glibc versions)
I am stumped.
Apart from avoiding gcc4.1.1 for now, what can I do to restore
functionality on this host?
Antoine
PS: there seems to be a tls problem with 2.6.17 guests too: syslog from
slackware 10.2 image loads ok with 2.6.16.27 but not with 2.6.17.11.
PS: btw, highmem is broken (at least in 2.6.18-rc5-mm1) - it fails to
link: 'kpte_clear_flush' not found.
-------------------------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
_______________________________________________
User-mode-linux-user mailing list
User-mode-linux-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/user-mode-linux-user
