Note: This is a public test instance of Red Hat Bugzilla. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback at bugzilla.redhat.com.
Bug 122952
Summary: | Driver DIsks don't work | ||
---|---|---|---|
Product: | [Fedora] Fedora | Reporter: | Judd Taylor <judd> |
Component: | anaconda | Assignee: | Jeremy Katz <katzj> |
Status: | CLOSED RAWHIDE | QA Contact: | |
Severity: | high | Docs Contact: | |
Priority: | medium | ||
Version: | rawhide | CC: | manojj, paul, tao, trevor |
Target Milestone: | --- | ||
Target Release: | --- | ||
Hardware: | x86_64 | ||
OS: | Linux | ||
Whiteboard: | |||
Fixed In Version: | Doc Type: | Bug Fix | |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 2005-08-15 16:15:06 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: | 133260 |
Description
Judd Taylor
2004-05-10 17:50:35 UTC
Do you have some sort of usb storage device attached? Can you look at the output of various alt-sysrq combinations to see where it's hanging? No USB device is attached. I'm not familiar with "alt-sysrq combinations", can you give me a little info on that? Alt-Sysrq-p will show the current running process information (it'll end up on tty4), and alt-sysrq-t will give a full trace of all tasks on the system. Ok, I saw some of that. alt-sysrq-p shows something like: PID 13 comm: loader not tainted alt-sysrq-t also seems to work, but how can I capture that output to a file somewhere? It scrolls to fast to even see the top of the call trace... I'm working on eliminating some other variables as well, I let you know as soon as I see anything new. I've booted to the boot kernel (2.6.5-1.327), and double-tested that the modules on the driver disks load, so there's no problem there. Also, I did a alt-sysrq-t, and got something like this: (...) linuxrc R (...) loader R (...) scsi_eh_0 S (...) {reparent_to_init+4} (...) {__down_interruptible+430} {default_wake_function+0} (...) {__down_failed_interruptible+53} {:scsi_mod:text.lock.scsi_error+65} (...) {child_rip+8} (...) {:scsi_mod:scsi_error_handler+0} {child_rip+0} Would this mean there's a problem with the scsi_mod modules that's on the install disk? Let me know if you need more detail. It sounds like that's where it's spinning. And there's not any sort of CF reader or anything like that on the motherboard? A lot of those are implemented as "USB". Actually, a quick way to check would be to boot with 'linux nousbstorage'. If you then are fine, then things should be fine as of the kernel Arjan built late on Friday. I tried booting off the CD with "linux nousbstorage dd", and still got the same problem. Also the same call trace (as far as I can tell). The only difference was that prior to loading the driver disk, it faild to load the ohci-hcd modules (where before it was doing that as normally). I talked with 3ware's support on the phone earlier, and they said there is an issue when "probe all SCSI LUNs" is enabled in the kernel, but in the normal .config's this is disabled (usually disabled by default, except for v2.6.5, disabled again by default in 2.6.6). I'm not seeing any other symptoms that were described by 3ware, but perhaps this has something to do with it? (Note, however, I still get the same error & call trace when loading the sata_sil driver, so there probably ins't an issue with this, I just want to let you guys know so you don't turn on probing all SCSI luns in the release kernel which will break the 3ware driver when it gets released in the near future...) Also don't know how I can put scsi_mod on my driver disks either since it is 2.4mb alone (the best compression I can get is a modules.cgz that is 1.9Mb...). Maybe a CD? any ideas? I'm starting to get worried that a fix for this won't make it into the release of FC2. It looks like if it isn't fixed, nobody will be able to use driver disks for their SCSI devices. Is there anything I can do to run any more tests and help get this fixed? Just let me know, and it will happen. I have the same problem with anaconda screen going as good blank exactly as described above in the original post of this bug. Only difference for me is that I am getting this on the fc2 released version with the 2.6.5 kernel and with a custom 2.6.6 kernel in both cases using drivers disks for the hpt374 sata rocketraid and it always does the same. And I have just been in contact with another user that has exactly the same behaviour with an advansys controller, oh and both of our systems are i686 not x86_64. his problem report is at http://listman.redhat.com/archives/anaconda-devel-list/2004-August/msg00051.html I'm the other user referred to in comment #9. I have the exact same problem in FC2 release (i586) with the advansys driver supplied in the standard FC2 i586 kernel RPM when used in a driver disk. The same module used in a customised boot.iso works perfectly. Are these version 0 or version 1 driver disks? It depends what you mean by version 1. The disks I'm trying are of the later format supporting multiple architectures, but the modinfo file still says "Version 0" because I don't think anaconda recognised the disk when it said "Version 1". For a detailed list of the contents of my driver disk, see http://listman.redhat.com/archives/anaconda-devel-list/2004-August/msg00051.html *** Bug 132683 has been marked as a duplicate of this bug. *** I've just tried a home-made advansys driver disk for FC3T2 (i386) and had exactly the same problem - crash out immediately after loading the driver. The call trace is as follows: <4> [<c02fdab5>] __down_interruptible+0x179/0x294 <4> [<c011b8a6>] default_wake_function+0x0/0xc <4> [<c02fdbe3>] __down_failed_interruptible+0x7/0xc <4> [<c88c154e>] .text.lock.scsi_error+0x2d/0x33 [scsi_mod] <4> [<c88c11de>] scsi_error_handler+0x0/0x191 [scsi_mod] <4> [<c01041d5>] kernel_thread_helper+0x5/0xb Fixed in CVS I have now managed to use the driver disk I created for comment #14 to install FC3T3 (same kernel as FC3T2) successfully on my i586 Advansys-SCSI-based machine. Phew! *** Bug 137448 has been marked as a duplicate of this bug. *** Jeremy Katz, Hope it is fixed already ? (comment #15). Is this fix available to us in any new release?. The bug appears to be fixed in FC3T3 (and presumably the release candidates for FC3). Manoq: please don't delete other people's addresses from the Cc: list. I'll delete my own address when I want to do it. I've successfully used my i586 driver disk on both FC3 (release) and FC4 (release). As far as I'm concerned this one's fixed. FC2 will forever be broken but who cares about that now? Paul, Thanks for the status update. I am closing this one now |