Bug 81649
Summary: | kernel module sbp2.o fails to load and hangs kernel at boot | ||
---|---|---|---|
Product: | [Retired] Red Hat Raw Hide | Reporter: | Need Real Name <f1j1> |
Component: | kernel | Assignee: | Dave Jones <davej> |
Status: | CLOSED WONTFIX | QA Contact: | Brian Brock <bbrock> |
Severity: | medium | Docs Contact: | |
Priority: | medium | ||
Version: | 1.0 | CC: | mgalgoci, mingo, msf, pfrields |
Target Milestone: | --- | ||
Target Release: | --- | ||
Hardware: | i686 | ||
OS: | Linux | ||
Whiteboard: | |||
Fixed In Version: | Doc Type: | Bug Fix | |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 2004-10-30 04:02:38 UTC | Type: | --- |
Regression: | --- | Mount Type: | --- |
Documentation: | --- | CRM: | |
Verified Versions: | Category: | --- | |
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
Cloudforms Team: | --- | Target Upstream Version: | |
Embargoed: | |||
Bug Depends On: | |||
Bug Blocks: | 79579, 100644 |
Description
Need Real Name
2003-01-12 04:05:13 UTC
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 :( |