Bug 119586 - sbp2 module is broken with latest RHE-3 kernel
Summary: sbp2 module is broken with latest RHE-3 kernel
Alias: None
Product: Red Hat Enterprise Linux 3
Classification: Red Hat
Component: kernel (Show other bugs)
(Show other bugs)
Version: 3.0
Hardware: i686 Linux
Target Milestone: ---
Assignee: Pete Zaitcev
QA Contact:
Depends On:
TreeView+ depends on / blocked
Reported: 2004-03-31 17:25 UTC by susan james
Modified: 2007-11-30 22:07 UTC (History)
3 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2004-08-19 23:42:36 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

Description susan james 2004-03-31 17:25:40 UTC
Description of problem:
firewire support:
unresolved symbols when loading sbp2 firewire module.

Version-Release number of selected component (if applicable):

How reproducible:
every time

Steps to Reproduce:
1.  modprobe ieee1394
2.  modprobe ohci1394
3.  modprobe sbp2
Actual results:
unresolved symbols

Expected results:
loads sbp2 module

Additional info:

Comment 2 Chris Runge 2004-04-01 19:30:53 UTC
this may only be an issue with the SMP kernel... I believe the uniproc
kernel doesn't have this problem

Comment 3 Pete Zaitcev 2004-04-01 21:00:30 UTC
I downloaded kernel-smp-2.4.21-9.0.1.EL and
kernel-smp-unsupported-2.4.21-9.0.1.EL. They both install fine.
Something is fishy here.

It might be possible that "depmod -ae" was not run of haven't
completed for some reason. That's most probable.

Another possibility is that Susan is confised with versions.
The bug is against "Q2 Errata Beta", whereas the 2.4.21-9.0.1.EL
is a E1 kernel. Which is correct?

[root@niphredil zaitcev]# lsmod
Module                  Size  Used by    Not tainted
ymfpci                 47564   1  (autoclean)
uart401                 8484   0  (autoclean) [ymfpci]
sound                  77708   0  (autoclean) [uart401]
ac97_codec             16104   0  (autoclean) [ymfpci]
soundcore               7044   4  (autoclean) [ymfpci sound]
parport_pc             19204   1  (autoclean)
lp                      9252   0  (autoclean)
parport                39072   1  (autoclean) [parport_pc lp]
autofs                 13780   0  (autoclean) (unused)
ds                      8864   1
yenta_socket           13984   1
pcmcia_core            62304   0  [ds yenta_socket]
e100                   59204   1
ipt_REJECT              4632   1  (autoclean)
ipt_state               1080   3  (autoclean)
ip_conntrack           29928   1  (autoclean) [ipt_state]
iptable_filter          2444   1  (autoclean)
ip_tables              16544   3  [ipt_REJECT ipt_state iptable_filter]
sg                     38060   0  (autoclean) (unused)
microcode               5248   0  (autoclean)
keybdev                 2976   0  (unused)
mousedev                5688   1
hid                    22436   0  (unused)
input                   6208   0  [keybdev mousedev hid]
usb-uhci               27532   0  (unused)
usbcore                83168   1  [hid usb-uhci]
ext3                   92360   2
jbd                    57016   2  [ext3]
sbp2                   21036   0  (unused)
ohci1394               29672   0  (unused)
ieee1394               67940   0  [sbp2 ohci1394]
sd_mod                 13744   0  (unused)
scsi_mod              117800   3  [sg sbp2 sd_mod]
[root@niphredil zaitcev]#
[root@niphredil zaitcev]# cat /proc/version
Linux version 2.4.21-9.0.1.ELsmp (bhcompile@bugs.devel.redhat.com)
(gcc version 3.2.3 20030502 (Red Hat Linux 3.2.3-26)) #1 SMP Mon Feb 9
22:26:51 EST 2004
[root@niphredil zaitcev]#
[root@niphredil zaitcev]# rpm -q modutils
[root@niphredil zaitcev]#

Comment 4 Pete Zaitcev 2004-04-01 21:05:58 UTC
"They both install fine" in the above comment was incorrect, I'm
sorry. I meant "they both worked fine in the final reckoning".
In actual fact, mkinitrd attempted to load ieee1394 while
installing kernel-smp, and failed, because ieee1394 was not
present until kernel-smp-unsupported was installed. I installed
kernel-smp-unsupported, commented ohci1394 from /etc/modules.conf,
rerun depmod -ae, rerun mkinitrd, rebooted.

This has little to do with sbp2, but I thought I'd mention it
for the record.

Comment 5 Pete Zaitcev 2004-04-02 17:56:52 UTC
Needinfo-ing while Susan clears the version confusion (U2 Beta
vs. E1) and verifies that depmod -ae cleas / fails to clear the error.

Comment 6 susan james 2004-04-03 01:19:20 UTC
installed RHE-WS update2-beta kernel-2.4.21-12.ELsmp
all firewire modules load properly.
in my case, I attached a Maxtor firewire drive.

> modprobe ieee1394
> modprobe ohci1394
> modprobe sbp2

no errors generated when loading modules.

dmesg tells me that the device is added:

ieee1394: Device added: Node[00:1023]  GUID[0010b9010131a8a7][Maxtor]

> cat /proc/scsi/scsi  doesn't show the firewire drive.

the firewire device file is never created.

> sfdisk -l

shows no firewire device.

> dmesg
ieee1394: Device removed: Node[00:1023]  GUID[0010b9010131a8a7] 
[Maxtor  ]
ieee1394: sbp2: Logged out of SBP-2 device
ieee1394: Host removed: Node[01:1023]  GUID[00303c00000974f7]  [Linux
scsi : 2 hosts left.
ohci1394: $Rev: 896 $ Ben Collins <bcollins@debian.org>
ohci1394_0: Unexpected PCI resource length of 1000!
ohci1394_0: OHCI-1394 1.0 (PCI): IRQ=[22]  MMIO=[e3120000-e31207ff] 
Max Packet=[2048]
ieee1394: Device added: Node[00:1023]  GUID[0010b9010131a8a7]  [Maxtor  ]
ieee1394: Host added: Node[01:1023]  GUID[00303c00000974f7]  [Linux
scsi1 : SCSI emulation for IEEE-1394 SBP-2 Devices
blk: queue f4e92018, I/O limit 4095Mb (mask 0xffffffff)
ieee1394: sbp2: Logged into SBP-2 device
ieee1394: sbp2: Node[00:1023]: Max speed [S400] - Max payload [2048]

this may be a new bug in that all the firewire modules load correctly,
but there is no device file generated.

anyone have ideas?

Comment 7 Pete Zaitcev 2004-04-06 20:53:16 UTC
Well, since the firewire "hotplugs" its pseudo-adapter made
up by the SBP2, you've got to tell the SCSI stack to rescan.
Every iPod user does that. Usually they just run Kurt Garloff's
rescan script:

I think we can close this now. Susan, please close when you
are done with testing.

Comment 8 Pete Zaitcev 2004-08-19 23:42:36 UTC
No update since April - closing

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