Hi, Noel Milton Vega wrote: > Hi: > > I gave up attempting to install Solaris10 nv77 on my Dell XPS-720 SATA drives > (see about 6 posts ago for problem there - basically the nv_sata driver > wouldn't > recognize directly connected SATA drives). > > Instead I decided to install Solaris10 nv77 onto 300GB Seagate drives > connected > to my Dell XPS-720 via USB interfaces (plural because I have two of these > drives, > model ST3300631A).
I've gone the opposite direction - moving from USB storage (for backup in my case) to eSATA because USB kept giving transport errors. In my case, also using nv_sata now that it is in but previously in non-native mode, my SATA disks have been happily regognised provided I configure them in the Nvidia RAID BIOS option (as JBODs). > I proceed through the installation menus but when suninstall initiates > mkfs/newfs > during the "Creating filesystems" phase, it hangs on the first slice > (c0t0d0s0). > But it gave no indication as to why. > > So I reboot my machine and direct the menu to take me to a SHELL > prompt. From there I can do an fdisk, format, and newfs, but only > intermittantly... Problem? SCSI transport errors "tran_err" or "timeout". > So it wasn't the installer. > > I attempted newfs on both of these drives, which are connected to different > USB ports. Both fail... newfs starts but immediately hangs due to these > SCSI errors. > > I checked the cabling, and they are secure. The length of the cables > themselves > are the typical lengths (about 4 feet). > > I don't get it. > > I know I installed Solaris (nv49 or something) on these same two disks > before, but that was when they were attached to my laptop. > > Any ideas? Again the problem is SCSI transport errors I guess triggered by > I/O access to these USB attached drives. Thanks in Advance. While others have reported success on usb mass storage, I have a litany of failures. I have used two different Seagate products (one USB, one USB/eSATA), a bus-powered Acomdata USB/Firewire device, another bus-powered generic enclosure on a variety of machines (U40 M2, Tyan Thunder K8W whitebox, Acer Ferrari 4005, Acer Aspire, Gigabyte K8NSLI whitebox) and I've found USB to be extremely patchy and to hang as you describe. Dtrace shows usb bulkonly device resets occuring, sometimes managing to get things going again but not always. I am backing up via zfs send | zfs receive to the external device. USB devices do not work reliably, and using firewire on the one device was worse. So I've switched to eSATA and it's perfect. The usual recommendation is to edit /kernel/drv/scsa2usb.conf and add reduced-cmd-support for your device type. You can use echo "::prtusb" | mdb -k to see the vid,pid of your device and add that, or just do attribute-override-list="vid=* reduced-cmd-support=true"; in scsa2usb.conf, and if it works then get more specific for your particular device. I've tried this with all devices and I've got to say that no combination worked reliably. Of course editing this file for install is going to be a challenge - I'm not sure if there is something you can do via kmdb to force reduced command support for all devices. I did log a bug on this way back around build 55. At the time it was thought that the one drive I had then (a Seagate external USB disk) had dodgy electronics at the USB<->IDE interface. That may be so, but then it seems that would apply to the other devices, too. I've tried every few builds since and sometimes get success for a whole backup, but then at the next try it fails again. More often than not it fails, so I threw in the towel and went to eSATA. I did also dig out some old builds around 45'ish and did get successful backups there, but did not repeat often enough to be confident and also did not have all builds in order to try to narrow the behaviour to a build it was introduced in. Gavin _______________________________________________ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
