From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040217 Galeon/1.3.13 Description of problem: System is fc2t1 + rawhide. I've been running 253 for two days. After updating this afternoon to what is probably yesterdays complete rawhide, I rebooted and my system keeps crashing right after enabling swap and before anything is printed about the firewire. I don't know what changed in the boot sequence but the same kernel worked yesterday and doesn't work today. I tried booting the 242 kernel and it gives the same error. The only way I could get the system back up is to install the FC1 2174 kernel. From what I can remember from the panic, the process was swapper, it was in kernel/time.c:295, and it said "in interrupt handler - not syncing". I know this is not of much use but I was wondering if anything changed in something other than the kernel that could have caused this since the kernel was working yesterday. One other thing is that when it happens, the floppy light comes on like it was probed. Also, I can't see the top of the panic because it scrolls off the screen. If it helps, and is related to the firewire, I do have a SB audigy with a firewire port on it. I only bring up the firewire because when I booted the 2174 kernel, right after enabling swap came the firewire initialization. I know, this is a crappy bug report and if it's needed, I can copy down as much of the panic as I can see tomorrow. Hopefully, todays rawhide will get mirrored and it will just go away. Version-Release number of selected component (if applicable): kernel-2.6.3-2.1.253, kernel-2.6.3-2.1.242, kernel-smp-2.4.22-1.2174.nptl How reproducible: Always Steps to Reproduce: 1. install the 20040311 rawhide update 2. reboot 3. Actual Results: System kernel panics on a kernel that had been working fine. Expected Results: System boots. Additional info: I've got four systems I'm running fc2t1+rawhide on and this is the only one that's had this problem. The dual P3 box, the dual P4 box, and the single P3 laptop all work while this single P4 paniced.
I think I've hit the same bug, this is on a up athlon. It gets triggered by kudzu 1.1.51 (the previous one was fine) on my machine. Here's the oops ------------[ cut here ]------------ kernel BUG at kernel/timer.c:370! invalid operand: 0000 [#1] CPU: 0 EIP: 0060:[<0212ac64>] Not tainted EFLAGS: 00010002 (2.6.4-1.270) EIP is at cascade+0x18/0x39 eax: 02317ad8 ebx: 02317d70 ecx: 02317ad8 edx: 37836a80 esi: 37836a80 edi: 023173a0 ebp: 00000036 esp: 0238ffb8 ds: 007b es: 007b ss: 0068 Process swapper (pid: 0, threadinfo=0238f000 task=02313b40) Stack: 00000000 023b43a8 023173a0 0238ffd0 0212b147 0238ffd0 0238ffd0 0238ffd0 0238ffd8 00000001 023b43a8 0000000a 00000000 02127399 02364f90 00000046 02390000 0210c3c4 Call Trace: [<0212b147>] run_timer_softirq+0xe0/0x32b [<02127399>] __do_softirq+0x35/0x73 [<0210c3c4>] do_softirq+0x46/0x4d ======================= And this is from notes written down manually from an previous one (netconsole didn't catch anything more) Code 0f 0b 72 55 da 2d 02 8b 36 89 f8 e8 6d f6 ff ff 39 de 75 timer.c:295 spin_lock (timer.c:0230e3a0) already locked by timer.c:392 other special features of the box are sata_promise. Bug got triggered with init=/bin/sh, mount /proc, /etc/init.d/kudzu start as well.
No crash after rm -rf of the ieee1394 module dir. And kudzu recently got - minimal port of the ieee1394 sbp2 probe to 2.6 I think we have a winner!
Works for me too. Renaming the ieee directory in the unsupported drivers directory allowed me to boot the 253 kernel too. Thanks for tracking this down Pekka!
*** Bug 118213 has been marked as a duplicate of this bug. ***
*** Bug 118312 has been marked as a duplicate of this bug. ***
A simple fix is to include this in /etc/modprobe.conf: alias ieee1394-controller ohci1394 It will load the module on startup and the system is working with firewire support. kudzu is not forcing the panic anymore.
*** This bug has been marked as a duplicate of 119262 ***
Changed to 'CLOSED' state since 'RESOLVED' has been deprecated.