So you're saying that generally, everything is working ok now, atleast where RBC is concerned? I wonder if the hotplug issue has been our problem all along. What you are describing sounds an aweful lot like what everyone was describing. The error cases showing the "Unknown" in the dmesg output compared to the original "Disk", which at first glance looked like things weren't being read right from the disk (wrong type, so sd wasn't probing it). So the sd driver doesn't implement something for the driver model to autoload it when it picks up a known type, without /etc/hotplug/scsi.agent entries? Thanks for tracking this Stefan. On Sun, Jul 10, 2005 at 10:13:37PM +0200, Stefan Richter wrote: > James Bottomley wrote: > >On Sun, 2005-07-10 at 19:34 +0200, Stefan Richter wrote: > >>Jul 10 18:30:17 shuttle kernel: Type: Unknown > >>ANSI SCSI revision: 02 > > > >Sorry, that's expected: I had a patch that would identify it as RBC, but > >there was another different one from someone else, and neither got > >applied. Can you try this: > > > >http://sourceforge.net/mailarchive/message.php?msg_id=11828307 > > Yes, the type is logged as Direct-Access-RBC with that addition. > > >>Then silence. > > > >Hmm, it sounds like the driver's not binding. If you do a > > > >ls -l /sys/class/scsi_device/<device>/device/driver > > > >On this, do you see anything (it should be a link to the bound driver). > > "driver" does not exist. But the solution is too simple to be obvious: > # modprobe sd_mod > is followed by > Jul 10 21:45:14 shuttle kernel: SCSI device sda: 585940320 512-byte hdwr > sectors (300001 MB) > Jul 10 21:45:14 shuttle kernel: SCSI device sda: drive cache: write back > Jul 10 21:45:14 shuttle kernel: SCSI device sda: 585940320 512-byte hdwr > sectors (300001 MB) > Jul 10 21:45:14 shuttle kernel: SCSI device sda: drive cache: write back > Jul 10 21:45:14 shuttle kernel: sda: sda1 > Jul 10 21:45:14 shuttle kernel: Attached scsi disk sda at scsi1, channel 0, > id 0, lun 0 > > So I added a mapping from type # 14 to TYPE_RBC and sd_mod to > /etc/hotplug/scsi.agent and it's back to normal. fdisk -l and hdparm -tT > play well. > > And while they access the disk, no log notices come from sbp2 from the > points where conversions occured in the former code. (Only the initial > inquiry before sd_mod's attachment is logged as a former case for > conversion.) > > >If there's nothing there, it sounds like sd.c is missing the RBC > >attachment code, which was this hunk of the patch: > > > > @@ -1533,7 +1551,7 @@ > > int error; > > > > error = -ENODEV; > > - if ((sdp->type != TYPE_DISK) && (sdp->type != TYPE_MOD)) > > + if (sdp->type != TYPE_DISK && sdp->type != TYPE_MOD && sdp->type != > > TYPE_RBC) > > goto out; > > > > SCSI_LOG_HLQUEUE(3, printk("sd_attach: scsi device: > > <%d,%d,%d,%d>\n", > >Could you check that that's in sd.c > > sd.c contains the line with TYPE_RBC. > > Alas, at least two problems remain: > > - Suddenly, the other problem reappeared. When I disconnect the disk, > scsi_eh_0 stays there even though I am running the scsi_device_put > modification in sbp2 (which helped before). This is accompanied by > ieee1394's knodemgrd falling into D state. > > - As written in the other post, one of my 2.5" disks lets the system > reboot shortly after the disk was attached. I have to find a way to > identify the point of failure. > -- > Stefan Richter > -=====-=-=-= -=== -=-=- > http://arcgraph.de/sr/ > -- Debian - http://www.debian.org/ Linux 1394 - http://www.linux1394.org/ Subversion - http://subversion.tigris.org/ SwissDisk - http://www.swissdisk.com/ - : send the line "unsubscribe linux-scsi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
