Red Hat Bugzilla – Bug 118194
[firewire] kernel crashes when loading firewire
Last modified: 2007-11-30 17:10:38 EST
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6)
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
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
Steps to Reproduce:
1. install the 20040311 rawhide update
Actual Results: System kernel panics on a kernel that had been
Expected Results: System boots.
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]
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
0238ffd8 00000001 023b43a8 0000000a 00000000 02127399 02364f90
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.