Re: OT: Recommend good multi-drive enclosure chipset?

Thanks Stefan,
   1394commander is quite helpful. I had to figure out (well, read
what it was telling me!) to get it to handle both controllers, but it
does seem to work. However I pretty quickly hit a small problem.

1) After booting my and powering up my 3 drives the 3rd drive is sdc:

ieee1394: Node changed: 0-01:1023 -> 0-00:1023
ieee1394: Node changed: 0-00:1023 -> 0-01:1023
scsi2 : SCSI emulation for IEEE-1394 SBP-2 Devices
ieee1394: sbp2: Logged into SBP-2 device
ieee1394: Node 0-00:1023: Max speed [S400] - Max payload [2048]
  Vendor: WDC WD40 Model: 0BB-32CXA0 Rev:
  Type: Direct-Access ANSI SCSI revision: 06
SCSI device sdc: 78165360 512-byte hdwr sectors (40021 MB)
sdc: asking for cache data failed
sdc: assuming drive cache: write through
SCSI device sdc: 78165360 512-byte hdwr sectors (40021 MB)
sdc: asking for cache data failed
sdc: assuming drive cache: write through
 sdc: sdc1
Attached scsi disk sdc at scsi2, channel 0, id 0, lun 0
Attached scsi generic sg2 at scsi2, channel 0, id 0, lun 0, type 0

2) I then tell 1394commander to do a coupl eof bus resets. After the
bus resets sdc has become sdd!

scsi3 : SCSI emulation for IEEE-1394 SBP-2 Devices
ieee1394: sbp2: Logged into SBP-2 device
ieee1394: Node 0-00:1023: Max speed [S400] - Max payload [2048]
  Vendor: WDC WD40 Model: 0BB-32CXA0 Rev:
  Type: Direct-Access ANSI SCSI revision: 06
SCSI device sdd: 78165360 512-byte hdwr sectors (40021 MB)
sdd: asking for cache data failed
sdd: assuming drive cache: write through
SCSI device sdd: 78165360 512-byte hdwr sectors (40021 MB)
sdd: asking for cache data failed
sdd: assuming drive cache: write through
 sdd: sdd1
Attached scsi disk sdd at scsi3, channel 0, id 0, lun 0
Attached scsi generic sg2 at scsi3, channel 0, id 0, lun 0, type 0
[root@Godzilla root]#

Same drive but it's changed scsi names. Why?

This is not a big issue as all my partitions are labeled so I can find
things, but should the SCSI stack look at GUIDs or some oter thing and
then come up consistent?

However, at this point I try to run hdparm -tT /dev/sdd and nothing
much is happening. I'm getting a couple of blinks on the drive but
hdparm is not coming back:

[root@Godzilla root]# hdparm -tT /dev/sdd
 
/dev/sdd:
 

It's stuck! Bad news!

There are no messages in dmesg. Ctrl-C broke it successfully. I can
still run on /dev/sda & sdb. The results are correct, but the first
controller is now completely hosed.

ps aux shows:

root 7125 0.0 0.0 0 0 ? SW 16:22 0:00 [scsi_eh_3]

The system's certainly not happy....

Will continue to look

Cheers,
Mark

On 4/14/05, Stefan Richter <stefanr@s5r6.in-berlin.de> wrote:
> Mark Knecht wrote:
> >>Hi Stefan,
>
> Hi Mark,
> good to read you here again.
>
> >> Anyway, was there possibly some tool that allows us to set gap
> >>count by hand? I cannot remember.
>
> 1394commander is a command line tool that lets you send phy packets,
> reset the bus, and much more. It can be used with its own command line
> interface or you just pass commands through a pipe or from a file.
> Command 'p' sends a phy packet, 'br short' issues a short bus reset,
> 'help' shows available commands.
>
> echo p 0x00450000 | 1394commander # for up to one cable hop
> echo p 0x004a0000 | 1394commander # for up to four cable hops
>
> This is the gap count and a fixed value of 0x40 OR'ed together and
> rolled two bytes to the left. The gap count is reset to its default
> value of 63 after two bus resets or a burst of resets like when a device
> is connected. Therefore the above command should be repeated after each
> bus reset. Furthermore, the spec says a bus reset should be triggered
> immediately after sending such a phy packet _and_ the then broadcast
> selfIDs should be checked if every PHY got the correct gap count. But in
> practice, the reset is not necessary. (Well, Mark knows all that, but
> maybe someone else wants to try this too.)
>
> >> Even a tool that lets me read the Py
> >>registers and see what gap count is set at would be helpful.
> ...
> > So as soon as I sent that previous note I thought of gscanbus which
> > does allow me to see gap count, but it only seems to show me one of
> > the two OHCI controllers in my system. man gscanbus and gscanbus
> > --help return nothing.
>
> There is a patch at the feature tracker at gscanbus' homepage that adds
> a command line parameter to select the controller. Else gscanbus always
> uses controller 0. Maybe one or another Linux distro provides gscanbus
> with the patch already applied, but most don't, probably.
>
> Note that gscanbus does not show the _current_ gap count but rather the
> one from the last bus reset.
> --
> Stefan Richter
> -=====-=-=-= -=-- -====
> http://arcgraph.de/sr/
>
> -------------------------------------------------------
> SF email is sponsored by - The IT Product Guide
> Read honest & candid reviews on hundreds of IT Products from real users.
> Discover which products truly live up to the hype. Start reading now.
> http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
> _______________________________________________
> mailing list Linux1394-user@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/linux1394-user
>

-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_ide95&alloc_id396&op%cck
_______________________________________________
mailing list Linux1394-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux1394-user
Received on Sat Apr 16 01:37:17 2005