I wrote:
Ben Collins wrote:
So you're saying that generally, everything is working ok now, atleast
where RBC is concerned?
Yes and no. The command and response conversions as they are now done
by scsi seem to work.
After the FX-3A I tried also the IceCube 800 which works too. Could
not try the IceCube 400 yet.
IceCube 400 is OK too, so all the three disks of mine that claim to be
TYPE_RBC work (...WRT the new command and response conversion code
path).
- 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.
...
Jul 10 22:32:26 shuttle kernel: scsi0 : SCSI emulation for IEEE-1394 SBP-2 Devices
Jul 10 22:32:26 shuttle kernel: ieee1394: sbp2: Node 1-00:1023: Using 36byte inquiry workaround
Jul 10 22:32:27 shuttle kernel: ieee1394: sbp2: Logged into SBP-2 device
Jul 10 22:32:27 shuttle kernel: Vendor: Initio Model: IC25N080ATMR04-0 Rev: 2.18
Jul 10 22:32:27 shuttle kernel: Type: Direct-Access ANSI SCSI revision: 02
Jul 10 22:33:28 shuttle syslogd 1.4.1: restart.
Maybe the MODE_SENSE response needs to be mangled for this device as if
it was an RBC device. (But remember, my older 2.5" disk says it's
Direct-Access and it worked without MODE_SENSE response conversion.)
No difference with sbp2's former MODE_SENSE conversion put back into
sbp2_check_sbp2_response().
Can unexpected MODE_SENSE responses lead to a reboot?
Furthermore, I never noticed before that this disk also triggers the 36byte
inquiry workaround. I will try it without the workaround.
As to be expected, no difference without that workaround.
I will try to get nearer the point of failure during the week.
--
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
