Hi!

On Tue, 1 Jun 2004, Jayme A Howard wrote:

> Just out of curiosity, were they each plugged in at boot time?  I noticed
> that when I hooked my usb enclosure up at boot, it'd attach to sd0 after
> the umass was detected, but if I did it during normal system use, it'd do
> what your Kingston is doing.

No, they were not. The system was running, and I then plugged that
Kingston in. In particular, as I tried to indicate, the Kingston
was detached, and then Transcend was *successfully* attached *right
after* Kingston, ie. no reboot.

There was a thread on current-users last December ("USB Drive Howto"),
that mentioned another possible trick in addition to booting with
the device connected. From that thread I understood that rebooting
might help because then the kernel would have continuous memory
for the scsibus stuff. See eg.

	http://mail-index.netbsd.org/current-users/2003/12/15/0024.html
	http://mail-index.netbsd.org/current-users/2003/12/16/0003.html
	http://mail-index.netbsd.org/current-users/2003/12/16/0004.html
	http://mail-index.netbsd.org/current-users/2003/12/16/0011.html

Since I could access Transcend just fine without rebooting, I'm assuming
that rebooting would not help (of course I could have this all wrong, feel
free to correct me).

However, I just realized that I didn't test that "other trick", so I
connected the Kingston and ran 'scsictl /dev/scsibus0 scan all all',
after which the following appeared:

sd0 at scsibus0 target 0 lun 0: <Kingston, DataTraveler2.0, 4.70> disk removable
sd0: 497 MB, 996 cyl, 128 head, 8 sec, 512 bytes/sect x 1019392 sectors

That scan took something like 1 minute, and 'fdisk /dev/sd0' gives
reasonable numbers, disklabel shows d and e, and all of the commands
take a relatively long time:

# time disklabel /dev/sd0
# /dev/sd0d:
type: SCSI
disk: mydisk
label: fictitious
flags: removable
bytes/sector: 512
sectors/track: 8
tracks/cylinder: 128
sectors/cylinder: 1024
cylinders: 996
total sectors: 1019392
rpm: 3600
interleave: 1
trackskew: 0
cylinderskew: 0
headswitch: 0           # microseconds
track-to-track seek: 0  # microseconds
drivedata: 0

5 partitions:
#        size    offset     fstype [fsize bsize cpg/sgs]
 d:   1019392         0     unused      0     0        # (Cyl.      0 -    995*)
 e:   1019383         8      MSDOS                     # (Cyl.      0*-    995*)
disklabel: boot block size 0
disklabel: super block size 0
0.001u 0.001s 0:44.14 0.0%      0+0k 1+1io 0pf+0w
Exit 2

So, it seems to be a timing issue (?), that is causing the
initial "problem" of sd0 not showing up. So far, the delay seems to
affect scsictl, fdisk, disklabel, and mount (but not umount). Copying a
~160MB file to it took

	"0.032u 6.451s 6:21.88 1.6%      0+0k 11+104io 0pf+0w",

or about ~3.3Mbps.

It would be nice if that Kingston drive would "just work", but I can live
with this little work-around. Thanks for making me take a second look at
it. :)


Artsi
-- 
#######======------  http://www.selonen.org/arto/  --------========########
Everstinkuja 5 B 35                               Don't mind doing it.
FIN-02600 Espoo        arto@selonen.org         Don't mind not doing it.
Finland              tel +358 50 560 4826     Don't know anything about it.