Bug 118194 - [firewire] kernel crashes when loading firewire
Summary: [firewire] kernel crashes when loading firewire
Status: CLOSED DUPLICATE of bug 119262
Alias: None
Product: Fedora
Classification: Fedora
Component: kernel
Version: rawhide
Hardware: i686
OS: Linux
Target Milestone: ---
Assignee: Arjan van de Ven
QA Contact: Brian Brock
: 118213 118312 (view as bug list)
Depends On:
Blocks: FC2Blocker
TreeView+ depends on / blocked
Reported: 2004-03-13 03:36 UTC by Thomas J. Baker
Modified: 2007-11-30 22:10 UTC (History)
5 users (show)

Clone Of:
Last Closed: 2006-02-21 19:01:57 UTC

Attachments (Terms of Use)

Description Thomas J. Baker 2004-03-13 03:36:38 UTC
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

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:

Steps to Reproduce:
1. install the 20040311 rawhide update
2. reboot

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.

Comment 1 Pekka Pietikäinen 2004-03-13 21:38:33 UTC
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
       0238ffd8 00000001 023b43a8 0000000a 00000000 02127399 02364f90
       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.

Comment 2 Pekka Pietikäinen 2004-03-13 21:45:37 UTC
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!

Comment 3 Thomas J. Baker 2004-03-13 22:48:39 UTC
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!

Comment 4 Bill Nottingham 2004-03-15 16:36:26 UTC
*** Bug 118213 has been marked as a duplicate of this bug. ***

Comment 5 Bill Nottingham 2004-03-15 19:05:37 UTC
*** Bug 118312 has been marked as a duplicate of this bug. ***

Comment 6 Thomas Woerner 2004-03-23 15:25:05 UTC
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.

Comment 7 Alexandre Oliva 2004-05-16 09:09:15 UTC

*** This bug has been marked as a duplicate of 119262 ***

Comment 8 Red Hat Bugzilla 2006-02-21 19:01:57 UTC
Changed to 'CLOSED' state since 'RESOLVED' has been deprecated.

Note You need to log in before you can comment on or make changes to this bug.