The behavior of the oops I've experienced has changed with each different kernel. I started with 2.6.8, then moved to 2.6.10 and now 2.6.11. I believe they are related, but have no definitive data to demonstrate this.
2.6.8 & 2.6.10 were similar in the there would be the following displayed to the console (from a 2.6.10 kern.log): May 1 11:05:49 localhost kernel: scheduling while atomic: swapper/0x00000101/0 May 1 11:05:50 localhost kernel: [schedule+1318/1328] schedule+0x526/0x530 May 1 11:05:50 localhost kernel: [default_idle+0/64] default_idle+0x0/0x40 May 1 11:05:50 localhost kernel: [cpu_idle+92/96] cpu_idle+0x5c/0x60 May 1 11:05:50 localhost kernel: [start_kernel+320/368] start_kernel+0x140/0x170 If I recall correctly, the 2.6.8 kernel had different memory offsets, and didn't include the function names. It wasn't until 2.6.10 that I actually saw function names with the memory address offsets. The system would be halted, but as I pressed the <return> on the console keyboard, the above messages would stream repeatedly to the console. If I kept hitting the <return> after the streaming stopped, the machine would ultimately complete shutdown and reboot. Another symptom that have persisted through all 2.6.x kernels has been that, upon reboot, the kernel sometimes freezes after the following messages: May 15 23:41:43 localhost kernel: RocketPort device driver module, version 2.09, 12-June-2003 May 15 23:41:43 localhost kernel: ACPI: PCI Interrupt Link [LNKB] enabled at IRQ 12 May 15 23:41:43 localhost kernel: PCI: setting IRQ 12 as level-triggered May 15 23:41:43 localhost kernel: ACPI: PCI interrupt 0000:00:14.0[A] -> GSI 12 (level, low) -> IRQ 12 successful reboot continues with the following statement: May 15 23:41:43 localhost kernel: Comtrol PCI controller #0 ID 0x5 found in bus:slot:fn 0000:00:14.0 at address ec00, 1 AIOP(s) (RocketPort 8 port w/octa cable) So their appears to be a possible issue resetting\probing the PCI bus (timing issue?) at reboot. .. With the 2.6.11 kernel, I believe I enabled some of the kernel debugging options (or they default to on in the kernel-source package). So now the system halts at the panic and dumps the callstack, etc.. Unfortunately, this datadump isn't written to disk (or I can't figure out how to make it write). It just recurred after ~24 hrs moments ago, and I confirmed that all the callstack addresses and cpu registers were identical to my original post. So I don't know if this current 2.6.11 bug is the same as the "scheduling while atomic" issue I experienced in 2.6.8 and 2.6.10. Rick -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
