From Bugzilla Helper: User-Agent: Mozilla/4.76 [en] (X11; U; Linux 2.2.17-14 i686) Description of problem: In rare cases, the kernel assigns conflicting SCSI bus numbers, causing SCSI devices not to be accessible. It took me a while but now I have a scenario that reproduces it every time . I use an ATAPI CD (using ide-scsi) and a USB storage device (using usb-storage) but I belive this is repeatable with other scsi drivers as well. Version-Release number of selected component (if applicable): kernel-2.4.9-13 How reproducible: Always Steps to Reproduce: 1. Restart computer with USB storade device unplugged (or turned off). 2. Load the ide-scsi driver. (/sbin/modprobe ide-scsi). 3. Unload the ide-scsi driver. (/sbin/rmmod ide-scsi). 4. Plug-in (or turn on) the USB storage device. /sbin/hotplug will load the usb-storage. 5. Reload the ide-scsi again. 6. The cdrom is not accessible neither via the scd or the sg drivers. Actual Results: Both the usb-storage and the ide-scsi devices were assigned scsi bus numbers 0. As a result, only the first one is accessible. Expected Results: Each driver should have it's own bus number. Both devices accessible when their drivers are loaded. Additional info: It looks like the scsi system tries to perserve the bus numbers even when drivers are unloaded/reloaded. That's why the ide-scsi driver is getting scsi number 0 again when it's reloaded. Right behaviour would probablybe to preserve bus 0 and use the next free number (1) for usb-storage. I could also create the opposite scenario (so the usb-storage became unaccessible) so I guess the problem is not just in these drivers but common to all scsi buss drivers (I mean scsi card and emulation drivers).
Created attachment 36821 [details] Here's a transcript of the scenario that repeats the problem.
If the scsi numbers are host/bus/id/lun then the conflicting numbers are for host, not bus as I wrote in the original report. "Maxtor 9 Model: 1728D8" Is a 17GB IDE disk, connected via a USB-IDE adaptor.
It would be nice if the USB SCSI devices (which are removable) were always assigned later numbers than the permanent devices. This way the permanent devices have a consistent assignment from boot-to-boot.
Actually RedHat pre-loads drivers for scsi cards, assigning the low host numbers. Scsi card drivers are not unloaded unless you explicitely 'rmmod' them. My problem was with 'temporary' hosts. I modprome ide-scsi and sg to use with xcdroast and rmmod them after I finish with xcdroast. usb-storage is loded by hotplug when the device is plugged. After more testing I found that the devices are useful (can be mounted etc) despite the host number conflict but they are not accessible thru sg (so I could not use xcdroast when that happenned. I'm taking this over also to the Linux kernel mailing list.
I've got some fixes in this area lined up for 2.4.9-18 or later, when that becomes available. Currently they are available in RawHide 2.4.16-0.13, so I would appreciate testing, if possible. (ftp.redhat.com /pub/redhat/linux/rawhide/i386/RedHat/RPMS) In parallel, I'll work on reproducing it with 2.4.9-13.
Created attachment 59924 [details] Proposed fix
Itai did the work and went to linux-kernel with the fix, so I figured something was wrong with the way I tried to reproduce it. I found that to reproduce the problem is enough to do "echo /bin/true > /proc/sys/kernel/hotplug". With that, either of two scenarios he mentioned work: scenario 1: insmod A rmmod A insmod A insmod B scenario 2: insmod A rmmod A insmod B insmod A
kernel 2.4.18-5.76