CPU Lockup with 2.4.21 and 2.4.22-pre
A message that is not in the archive (sent off-list or not yet received): [email protected]
Am Mon, 2003-07-21 um 16.17 schrieb Udo A. Steinberg:
Quoted 15 lines · On Mon, 21 Jul 2003 16:12:26 +0200 Udo A. Steinberg (UAS) wrote:
UAS> We have a Dual-Xeon machine with Hyperthreading which keeps locking up hard,
UAS> so that not even Sysrq works anymore. I have captured such a lockup using the
UAS> NMI oopser. Below you'll find the lockup fed through ksymoops. Note that
UAS> after CPU3 locked up, CPU2 did too. But that lockup couldn't be captured
UAS> anymore. Kernel is a monolithic 2.4.22-pre6. Problem also happened on
UAS> plain 2.4.21. I can provide more information wrt. hardware, config etc.
UAS> on request.
Would be really useful if you do so.
Quoted 3 lines
Sorry, I used the wrong System.map. Below is the fixed decode. Looks like
the lockup is caused by the 3rd party Compushack FDDI driver.
What makes you believe this? There is no matching code sequence like the one from your dump in the driver, to be exact: in a driver compiled with gcc 3.3 and kernel 2.4.21.
Quoted 2 lines
Regards,
-Udo.
Regards,
Michael
On 22 Jul 2003 12:24:24 +0200 Michael Troß (MT) wrote:
UAS> I can provide more information wrt. hardware, config etc. UAS> on request.
MT> Would be really useful if you do so.
I have put the following information at: http://www.wh8.tu-dresden.de/fddi/
* My .config for 2.4.22-pre6
* dmesg output of 2.4.22-pre6 (both 2.4.21 and 2.4.22-pre6 behave the same)
* the ksymoops output of the lockup
* the output of lspci -v
* the fddi patch i used (applies cleanly to 2.4.21 and with fuzz to -pre6)
Note that the fddi patch includes a patch you've previously sent me, which isn't present in the driver on your website.
If you need more information, let me know. Also if you have any tips or patches that would help in debugging the issue, I'm happy to try them.
MT> What makes you believe this? There is no matching code sequence like the MT> one from your dump in the driver, to be exact: in a driver compiled with MT> gcc 3.3 and kernel 2.4.21.
The fact that the backtrace in the decoded oops looks like the lockup happened in the fddi driver led me to the conclusion that this may be the culprit. I have compiled the 2.4.22-pre6 kernel with gcc-3.3 also.
Regards,
-Udo.