problem writing to umass device

Alexander Best alexbestms at math.uni-muenster.de
Wed Jul 29 21:45:13 UTC 2009


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 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: Attached to scbus7
> > da0 at umass-sim0 bus 0 target 0 lun 0
> > da0: <  > Removable Direct Access SCSI-2 device
> > da0: 40.000MB/s transfers
> > da0: 3864MB (7913472 512 byte sectors: 255H 63S/T 492C)

> > i haven't used it for quite a while, but it used to work just fine
> > (yes
> > with usb2). but since then i've updated my kernel a couple of times
> > and now
> > i'm getting these errors. i can mount the device just fine, but if
> > i try to
> > copy files onto it i get the following error messages:

> > Jul 28 11:22:07 otaku kernel:
> > g_vfs_done():da0[WRITE(offset=54083584,
> > length=65536)]error = 5
> > Jul 28 11:22:07 otaku kernel:
> > g_vfs_done():da0[WRITE(offset=54149120,
> > length=65536)]error = 5
> > Jul 28 11:22:07 otaku kernel:
> > g_vfs_done():da0[WRITE(offset=54214656,
> > length=65536)]error = 5
> > Jul 28 11:22:07 otaku kernel:
> > g_vfs_done():da0[WRITE(offset=54280192,
> > length=32768)]error = 5
> > Jul 28 11:22:07 otaku kernel:
> > g_vfs_done():da0[WRITE(offset=54312960,
> > length=16384)]error = 5
> > Jul 28 11:22:07 otaku kernel:
> > g_vfs_done():da0[WRITE(offset=54329344,
> > length=65536)]error = 5
> > Jul 28 11:22:07 otaku kernel:
> > g_vfs_done():da0[WRITE(offset=54394880,
> > length=65536)]error = 5
> > Jul 28 11:22:07 otaku kernel:
> > g_vfs_done():da0[WRITE(offset=54460416,
> > length=65536)]error = 5
> > Jul 28 11:22:07 otaku kernel:
> > g_vfs_done():da0[WRITE(offset=54525952,
> > length=65536)]error = 5
> > Jul 28 11:22:07 otaku kernel:
> > g_vfs_done():da0[WRITE(offset=54591488,
> > length=65536)]error = 5
> > Jul 28 11:22:07 otaku kernel:
> > g_vfs_done():da0[WRITE(offset=54657024,
> > length=16384)]error = 5
> > Jul 28 11:22:07 otaku kernel: g_vfs_done():da0[WRITE(offset=512,
> > length=512)]error = 5
> > Jul 28 11:22:07 otaku kernel: g_vfs_done():da0[WRITE(offset=24576,
> > length=4096)]error = 5
> > Jul 28 11:22:07 otaku kernel: g_vfs_done():da0[WRITE(offset=28672,
> > length=4096)]error = 5
> > Jul 28 11:22:07 otaku kernel:
> > g_vfs_done():da0[WRITE(offset=1024000,
> > length=4096)]error = 5
> > Jul 28 11:22:07 otaku kernel:
> > g_vfs_done():da0[WRITE(offset=1028096,
> > length=4096)]error = 5
> > Jul 28 11:22:07 otaku kernel:
> > g_vfs_done():da0[WRITE(offset=38502400,
> > length=16384)]error = 5
> > Jul 28 11:22:07 otaku kernel:
> > g_vfs_done():da0[WRITE(offset=39370752,
> > length=16384)]error = 5
> > Jul 28 11:22:07 otaku kernel: fsync: giving up on dirty
> > Jul 28 11:22:07 otaku kernel: 0xcc0aa6b8: tag msdosfs, type VREG
> > Jul 28 11:22:07 otaku kernel: usecount 1, writecount 0, refcount 55
> > mountedhere 0
> > Jul 28 11:22:07 otaku kernel: flags ()
> > Jul 28 11:22:07 otaku kernel: v_object 0xc8a81770 ref 0 pages 212
> > Jul 28 11:22:07 otaku kernel: lock type msdosfs: EXCL by thread
> > 0xcc60a240
> > (pid 19448)
> > Jul 28 11:22:07 otaku kernel: #0 0xc05b5ee0 at __lockmgr_args+0xb90
> > Jul 28 11:22:07 otaku kernel: #1 0xc0647898 at vop_stdlock+0x68
> > Jul 28 11:22:07 otaku kernel: #2 0xc0781fb5 at VOP_LOCK1_APV+0xb5
> > Jul 28 11:22:07 otaku kernel: #3 0xc0664008 at _vn_lock+0x78
> > Jul 28 11:22:07 otaku kernel: #4 0xc0658adb at vget+0xbb
> > Jul 28 11:22:07 otaku kernel: #5 0xc055d4ca at msdosfs_sync+0x17a
> > Jul 28 11:22:07 otaku kernel: #6 0xc06520be at dounmount+0x44e
> > Jul 28 11:22:07 otaku kernel: #7 0xc065262f at unmount+0x2bf
> > Jul 28 11:22:07 otaku kernel: #8 0xc076eb26 at syscall+0x2a6
> > Jul 28 11:22:07 otaku kernel: #9 0xc0752ad0 at
> > Xint0x80_syscall+0x20
> > Jul 28 11:22:07 otaku kernel: startcluster 2230, dircluster 2229,
> > diroffset
> > 96, on dev da0
> > Jul 28 11:22:40 otaku kernel:
> > g_vfs_done():da0[WRITE(offset=53805056,
> > length=65536)]error = 5
> > Jul 28 11:22:40 otaku kernel:
> > g_vfs_done():da0[WRITE(offset=53870592,
> > length=65536)]error = 5
> > Jul 28 11:22:40 otaku kernel:
> > g_vfs_done():da0[WRITE(offset=53936128,
> > length=65536)]error = 5
> > Jul 28 11:22:40 otaku kernel:
> > g_vfs_done():da0[WRITE(offset=54001664,
> > length=65536)]error = 5
> > Jul 28 11:22:40 otaku kernel:
> > g_vfs_done():da0[WRITE(offset=54067200,
> > length=65536)]error = 5
> > Jul 28 11:22:40 otaku kernel:
> > g_vfs_done():da0[WRITE(offset=54132736,
> > length=65536)]error = 5
> > Jul 28 11:22:40 otaku kernel:
> > g_vfs_done():da0[WRITE(offset=54198272,
> > length=65536)]error = 5
> > Jul 28 11:22:40 otaku kernel:
> > g_vfs_done():da0[WRITE(offset=54263808,
> > length=65536)]error = 5
> > Jul 28 11:22:40 otaku kernel:
> > g_vfs_done():da0[WRITE(offset=54329344,
> > length=65536)]error = 5
> > Jul 28 11:22:40 otaku kernel:
> > g_vfs_done():da0[WRITE(offset=54394880,
> > length=65536)]error = 5
> > Jul 28 11:22:40 otaku kernel:
> > g_vfs_done():da0[WRITE(offset=54460416,
> > length=65536)]error = 5
> > Jul 28 11:22:40 otaku kernel:
> > g_vfs_done():da0[WRITE(offset=54525952,
> > length=65536)]error = 5

> > might the device's ram be broken? this is the result of `dd
> > if=/dev/da0
> > of=/dev/null`:

> > dd: /dev/da0: Input/output error
> > 1067+0 records in
> > 1067+0 records out
> > 546304 bytes transferred in 235.522107 secs (2320 bytes/sec)
>                                                   ^^ terribly slow
>                                                   disk ?


> > i attached the device to a windows xp box and ran scandisk. that
> > didn't
> > reveal any problems however.


> Hi,

> Try enabling umass debugging:

> sysctl hw.usb.umass.debug=-1

> Not sure if this might be a CAM layer regression.

> --HPS


More information about the freebsd-usb mailing list