From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.2) Gecko/20030716 Description of problem: I'm trying to get the a driver disk working on FC2-t3 so it will install to my sii3114 SATA controller, as well as see my 3w-9xxx raid card. I have all of this working on a FC1 install, using the 2.6.4 vanilla kernel. I've created a driver disk with the libata, sata_sil, and the (not yet released) 3w-9xxx drivers (bulilt against the 2.6.5-1.327 and 2.6.5-1.327smp kernels), as well as the necessary other files (rhdd-6.1, modinfo, modules.dep, pcitable). When I boot to the install CD, and run "linux dd", it prompts for the driver disk, and all goes well, it loads the modules with no problem, and the HDDs on the controllers appear as well as the partitions on those disks (from info on VT3 & VT4) Then... nothing. After is reports that is has loaded the drivers, the installer screen just sits there. It's not frozen, as I can still switch VTs and ctrl-alt-delete (but not too much else, since there isn't a shell handy at that point). But the installer doesn't want to continue. I've repeated the process with driver disks with each of the individual drivers as well, and I get the same problem. This could be really bad if all driver disks are broken in the release version of FC2. Version-Release number of selected component (if applicable): How reproducible: Always Steps to Reproduce: 1. boot the install CD to "linux dd" 2. insert the driver disk when prompted 3. watch the drivers load, then nothing else happen... Additional info:
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