After performing a emerge system, my computer randomly restarted when I updated from glibc 2.9_p20081201 to 2.9_p20081201-r1. I updated to the newest kernel and tried again, glibc and gcc compiled with no crashes. I then performed an emerge world and randomly (meaning it never does it at the same place twice) during the emerge of wine, the system spits out a call trace and freezes my computer. This is the output from what I could copy: Pid:0, Comm: swapper Tainted: P M gentoo-linux-2.6.28 #1 Call Trace: <#MC> warn_on_slowpath up release_console_sem smp_call_function_mask printk native_smp_send_stop panic notifier_call_chain mce_log do_machine_check mwait_idle mwait_idle machine_check udp_poll mwait_idle <<EOE>> cpu_idle Reproducible: Always
Created attachment 177420 [details] emerge --info
Did some playing around, and the system freezes occur with every wine package at random places. I tried 1.1.12 again, I then tried 1.1.11, and I tried to reinstall 1.1.10, and it all crashes. To expand on what I mean random: The first freeze occured roughly half way through the compile process. It was on a net library. The second time happened just as it was processing the config for the application dll's. The third time happened while it was running the compiler checks. The fourth time happened right after it was done the config checks and it was making the dependancies for the first library. The fifth time happened a little after that. Each time the computer froze, the stack trace has been the same as mentioned above.
This looks like a hardware issue, possibly overheating.I'd suggestrunning some diagnostics (memtest, cpuburn) to localize the problem.
cpuburn - burnMMX I ran this for 2 hours and exited with a code of 130. Load jumpped to 100% on each of the fours cores heating them up. The temp fluctuated between 47 C when not used and 58 C when under load. The values never left this range. I monitored the temps using gkrellm2 with lm_sensors. No freezes, or problems, enjoyed watching House while it ran. memtest86+ Tests using the Std test, ran for 30 minutes and passed all tests without any errors. I tried watching my temp and processor usage during the compile of wine 1.1.11, the cores were up to about 40% each, temp never hit beyond 51 C for any core. I have successfully compiled a few other packages that use all cores during compile and they went rather smoothly. *shrugs* Think I'm doomed to virtual machines?
dmesg output from the time of the freeze would be most welcome.
Is there a file that saves all of the messages from dmesg? I suppose I could start the computer from a live CD and grab it (so a reboot doesn't overwrite it). Otherwise I'm unsure how to capture a dmesg, as the computer becomes unusable when a freeze occurs.
kernel freezes are bugs in the kernel
If you downgrade glibc, do the crashes go away again?
(In reply to comment #8) > If you downgrade glibc, do the crashes go away again? > Unfortunatelly downgrading glibc is a dangerous step and portage doesnt allow you to do that :( However , somebody suggested me a way to do that . You need to build binaries for the version of glibc you want + the packages that you emerged after you updated your glibc to 2.9 , in a chroot The process is really painfull and the result might not be good So from my point of view, I would suggest, downgrading glibc to be your last solution
It should be safe in this scenario, surely there is a way to force portage to do it? If not, you could just copy the original ebuild to -r2 so that portage thinks it is an upgrade.
I tried method B of the downgrade guide from a cached copy of the gentoo wiki: ---------------------------------------------------------------------- * Get the target version of sys-libs/glibc from Gentoo Binary Packages TinderBox * Put it in /usr/local/glibc/ * Add the following to your /etc/make.conf file LDFLAGS="-L/usr/local/glibc/lib64 -L/usr/local/glibc/usr/lib64 -L/usr/local/glibc/lib32 -L/usr/local/glibc/usr/lib32 $LDFLAGS" CPPFLAGS="-I/usr/local/glibc/usr/include $CPPFLAGS" * Mask all versions newer than the required version in /etc/portage/package.mask * Run emerge -pv sys-libs/glibc and verify the correct version would be built. * Re-emerge your system: emerge --emptytree system ---------------------------------------------------------------------- I didn't do the last step, because from what I gather this is making it so I'm running from the binary glibc. I tried doing wine again, and I still froze.
After an unfortunate accident involving dd and my drives partition table I decided to reinstall, but this time put blocks on ebuilds of glibc and go from there. glibc 2.7-r2 gcc 4.1.2 I have managed to compile wine 1.1.13 with no complaints, slowdowns or problems. My kernel config is exactly the same from the previous installation with the only tweak to enable CIFS support. I don't know what to say about this one, but the problem is resolved in a way.
I am pretty sure that this bug was unrelated to glibc, sounds more like a hardware or memory corruption issue, but who knows...
