From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2.1) Gecko/20021218 Description of problem: Sorry to be the bearer of bad news. Module /lib/modules/2.4.20-2.10/kernel/drivers/ieee1394/sbp2.o fails to load This is also the case with 2.9 and 2.11 kernels Can't even give you an attachment from kernel messages... Totally hangs I have a 2.4.20-2.5custom that works just fine. Version-Release number of selected component (if applicable): How reproducible: Always Steps to Reproduce: 1. Boot kernel 2. Stops at UHCI load statement 3. Actual Results: Hangs kernel boot Expected Results: Boot through to Login Additional info: Can't forward any attachments of the system log since it occurs before anything is written to log. I have success with a custom 2.4.20-2.5 kernel
A fix is in Linux 2.4.21pre3-ac3 o Fix sbp2 build with some config options (Eyal Lebidinsky)
Undoable work around would be to remove the firewire connection to my BUSLINK CD-RW drive. Then the kernel boots. Again this is not a fix.
Failed sbp2.o load from latest kernel-2.4.20-2.13.i686.rpm as well. Also see bug 81788 for more depmod issues
Failed sbp2.o load from latest kernel-2.4.20-2.15.i686
If I unplug the BUSLINK CDRW4848FE (Firewire) drive the kernel 2.4.20-2.15 will boot and load the sbp2.o driver.
*** Bug 81646 has been marked as a duplicate of this bug. ***
Continuing no load of sbp2.o with kernel-2.4.0-2.18.i686
Continuing no load of sbp2.o with kernel-2.4.0-2.21.i686
just a note, kernel-2.4.20-2.21 has the fix from kernel 2.4.21pre3-ac3, so while it is clearly a fix, that clearly isn't the fix for this particular problem.
2.4.20-2.24 seems to do it for me! sbp2.o loads without incident. I'm going to report the kernel oops on the rpm install of 2.4.20-2.24 i686 though seperately, not sure what happened there.
Seem to have about every third boot sbp2.o errors out in same way as before... Strange.. again a timing issue. So 2.4.20-2.24 works marginally well.
Still about every third boot sbp2.o errors out in same way as before... Strange.. again a timing issue. So 2.4.20-2.25 works a little better than 2.4.20-2.24.
Some NPTL-related changes have been going in lately, and they might have something to do with this now working better. Adding Ingo to see if this gives him any ideas.
On a uni-processor system, I get the following message upon firewire initialization: ieee1394: SelfID completion called outside of bus reset! ieee1394: sbp2: Node[01:1023]: Max speed [S400] - Max payload [2048] On SMP, I get a deadlock (usually) When I format a filesyetem on a firewire device, I get the following sort of errors: mke2fs 1.32 (09-Nov-2002) Filesystem label= OS type: Linux Block size=4096 (log=2) Fragment size=4096 (log=2) 30015488 inodes, 30013428 blocks 1500671 blocks (5.00%) reserved for the super user First data block=0 916 block groups 32768 blocks per group, 32768 fragments per group 32768 inodes per group Superblock backups stored on blocks: 32768, 98304, 163840, 229376, 294912, 819200, 884736, 1605632, 2654208, 4096000, 7962624, 11239424, 20480000, 23887872 Writing inode tables: ieee1394: sbp2: sbp2util_allocate_request_packet - no packets available! ieee1394: sbp2: sbp2util_allocate_write_request_packet failed ieee1394: sbp2: aborting sbp2 command Write (10) 00 01 34 1a a7 00 00 08 00 ieee1394: sbp2: sbp2util_allocate_request_packet - no packets available! ieee1394: sbp2: sbp2util_allocate_write_request_packet failed ieee1394: sbp2: aborting sbp2 command Write (10) 00 06 7c 0e af 00 00 48 00 done Creating journal (8192 blocks): done Writing superblocks and filesystem accounting information: done This filesystem will be automatically checked every 31 mounts or 180 days, whichever comes first. Use tune2fs -c or -i to override.
the sbp2.o will not load on my system in kernels 2.4.20-2.27 or 2.4.20-2.28
To the original reporter, f1j1 Is the system in question multi-processor or a single processor system. If its multi-processor, I have seen SMP hangs. If its single cpu, then I am unable to make my system hang or otherwise failt to load sbp2 and the supporting ieee1394 driver stack. Regards, Matt Galgoci
The smp lockup that I had seen appears to be fixed in rawhide. The ieee1394 packet starvation issue was worked around by setting the sbp2 module paramater sbp2_max_outstanding_cmds=64 My external firewire drive has survived tests that would cause deadlock in a matter of seconds previously. I am happy. Not not lockup or bus reset. :-) I dunno about the fellow that can't get sbp2 to load :(