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/
-
: 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
