to end this thread:
the problem wasn't caused by the device, but by a problem with certain usb
ports. whether this is a bug in the usb stack or faulty hardware remains
unclear.
alex
___
freebsd-usb@freebsd.org mailing list
hi there. have you had the time to look at this issue? i tested the device
under windows xp and it works without any problems. with a recent head copying
files to the device still fails at some point with `cp` reporting an
input/output error and a lot of failed writes being reported on the
On Friday 07 August 2009 12:14:31 Alexander Best wrote:
hi there. have you had the time to look at this issue? i tested the device
under windows xp and it works without any problems. with a recent head
copying files to the device still fails at some point with `cp` reporting
an input/output
On Wednesday 29 July 2009 22:25:05 Alexander Best wrote:
i have a problem with the following device:
ugen7.2: Meizu Electronics at usbus7
umass0: Meizu Electronics MiniPlayer, class 0/0, rev 2.00/1.00, addr 2
on usbus7
umass0: SCSI over Bulk-Only; quirks = 0x4400
umass0:7:0:-1:
Hans Petter Selasky schrieb am 2009-07-29:
On Wednesday 29 July 2009 22:25:05 Alexander Best wrote:
i have a problem with the following device:
ugen7.2: Meizu Electronics at usbus7
umass0: Meizu Electronics MiniPlayer, class 0/0, rev 2.00/1.00,
addr 2
on usbus7
umass0: SCSI over
seems i need to reboot. since i wasn't able to unmount the device i unplugged
it and tried plugging it in again. but it doesn't get recognised at all. no
attach message or anything like that even after attaching it to a different
usb port.
i'm sure at the end the only option is to trigger the
damn. just say that i overlooked the minus. so instead of setting sysctl
hw.usb.umass.debug=-1 i did in fact do sysctl hw.usb.umass.debug=1. sorry
for that. i'll send you a new output after i'm done blanking and reformatting
the umass device.
alex
Hans Petter Selasky schrieb am 2009-07-29:
On
here are some input/output benchmark measurements i did. don't know why the
device returned the slow result you noticed. but the following values seem
quite reasonable. maybe the previous results turned out so bad, because in the
background the writes which `cp` requested were still being
