I'm yet to encounter device that would not have any errors with the long run.
Similar, I think that some -
Feb 17 12:31:14 Thinkpad kernel: (da0:umass-sim0:0:0:0): WRITE(10). CDB: 2a
00 1d 51 6f 10 00 00 80 00
Feb 17 12:31:14 Thinkpad kernel: (da0:umass-sim0:0:0:0): CAM status: CCB
request
And it ends with-
STATUS: ID=10842, RX=32339456 bytes/sec, TX=0 bytes/sec, ERR=21, RST=31,
DERR=0
Read & Write, 7200 sec.
--
View this message in context:
It starts with STATUS: ID=63, RX=33467392 bytes/sec, TX=0 bytes/sec, ERR=14,
RST=24, DERR=0
I will get back to you after it ends (7200 sec.).
--
View this message in context:
Adding back "options USB_DEBUG # enable debug msgs"
to my STRIPPED config (as I had it commented out lately) was what
restored the behaviour to GENERIC (working one) (sic!).
Finishing now 4th? dump.
http://pastebin.ca/3766145
--
View this message in context:
I've added to my config options USB_DEBUG
and turned on hw.usb.debug: 1 and hw.usb.umass.debug: 1
This time the dump finished.
DUMP: 95.35% done, finished in 0:03 at Thu Feb 9 23:06:21 2017
DUMP: 99.23% done, finished in 0:00 at Thu Feb 9 23:08:19 2017
DUMP: DUMP: 99117484 tape blocks
Will do, I've found your recommendation in another thread, but only
after I've posted. I will probably leave both drives overnight.
Thanks!
--
View this message in context:
Hello again,
Any more pointers on how to test the devices
thoroughly?
http://pastebin.ca/3765422 touro s
http://pastebin.ca/3765426 samsung
--
View this message in context:
Thanks for a reply.
Currently both of them are empty, usbtest looks promising,
I will look into it. usbdump might be too much for me.
As of now, I've hoped to take a disk dumps via USB, but it
doesn't look possible. Smaller writes (<50 G) are sometimes
ok.
Devices in question-
ugen6.2: at
As of now, I'm rebuilding system with a GENERIC kernel, what
should I do to provide as much as possible useful debug?
I think the problem only manifested itself after I've switched to
much faster internal SSD, that would explain why some mitigate
it by throttling USB speed.
--
View this
To my joy, problem resolved itself after fixes from 4 days ago.
Thanks!
--
View this message in context:
http://freebsd.1045724.n5.nabble.com/9-STABLE-lost-access-to-previously-working-usb-device-tp5852605p5877187.html
Sent from the freebsd-usb mailing list archive at Nabble.com.
Is there anything more I could provide?
--
View this message in context:
http://freebsd.1045724.n5.nabble.com/9-STABLE-lost-access-to-previously-working-usb-device-tp5852605p5874834.html
Sent from the freebsd-usb mailing list archive at Nabble.com.
All X freezes happened directly after/when manipulating
usb ports and not once in the other time.
media player with original firmware:
https://www.dropbox.com/s/xch56ala95aovno/org_firmw
media player with rockbox firmware:
https://www.dropbox.com/s/jv3p8d32by03r7i/rockbox
pendrive
OK, there are also problems with other umass devices.
Debug with Rockboxed device (previously working):
http://pastebin.com/AwbMvK3s
Debug with original firmware:
http://pastebin.com/LYdiqNR4
Debug of not working umass device:
http://pastebin.com/ukEhiR4P
In the end, another unpleasant X
Yes, I'm running FreeBSD 9.2-STABLE #0 r260085 amd64,
Yes Tomek, I've seen your thread and checked other cable
instantly :-).
More typical (pendrive) umass devices seem unaffected
or I didn't stress the port enough. Loosing X is mighty strange
though. Display stalled (slightly broken colours)
Strange, the problem resurfaced, yet I didn't change Rockbox firmware
this time...
Any related work in 9-STABLE?
This time
(probe0:umass-sim0:0:0:0): INQUIRY. CDB: 12 00 00 00 24 00
(probe0:umass-sim0:0:0:0): CAM status: CCB request completed with an error
Could it be caused by unclean
There is certainly something sinister going on with usb, as of today I've
lost X access second (frozen display, system shut down normally) time
already while manipulating USB ports (first time with this Rockboxed
device, second time now when using snd_uaudio soundcard...)
Sorry for being so
...and another stall when using uaudio. Definitely connected with usb.
--
View this message in context:
http://freebsd.1045724.n5.nabble.com/9-STABLE-lost-access-to-previously-working-usb-device-tp5852605p5872634.html
Sent from the freebsd-usb mailing list archive at Nabble.com.
FreeBSD 9.2-STABLE #0 r256650 amd64, device in question is
Sansa Clip+ music player, with Rockbox firmware-
Oct 17 15:52:25 Thinkpad kernel: usbus3: port reset timeout
Oct 17 15:52:25 Thinkpad kernel: usbd_req_re_enumerate: addr=2, port reset
failed, USB_ERR_TIMEOUT
Oct 17 15:52:26 Thinkpad
After re-examination, the problem is confined to case of mounting when
running Rockbox firmware, however I used to do so for a quite long time.
Maybe upgrading Rockbox while on Windows wasn't such a good idea after
all.
--
View this message in context:
Of course even after upgrade transferring files when running Rockbox worked
under Windows, iirc.
There is a hw.usb.ehci.no_hs=1 but that doesn't change anything.
Thanks for a reply, I think I will have to live with reverting to original
fw to manipulate files, or will try downgrading later.
I failed to find threads regarding precisely my situation, closest would be
Bartosz Fabianowski's thread from 2011, however I had Rockbox working
in 2013, and now it's broken.
I will try now to revert to older firmware, as Rockbox tip has the same
issue.
Anyway, thanks for replies, as Rockbox
It's good I confirmed it... but it's actually Rockbox regression.
Once again, thanks for help!
--
View this message in context:
http://freebsd.1045724.n5.nabble.com/9-STABLE-lost-access-to-previously-working-usb-device-tp5852605p5852651.html
Sent from the freebsd-usb mailing list archive at
Just a thought, I don't think that bitperfect=1 now works properly, as I
cannot
play source which is supported by hardware- all is forced to 48/16.
AUDIO: 96000 Hz, 2 ch, s24le, 4608.0 kbit/100.00% (ratio: 576000-576000)
Selected audio codec: [pcm] afm: pcm (Uncompressed PCM)
[AO OSS] Can't set
I'm confused now.
With adaptive and bitperfect-
Opening audio decoder: [pcm] Uncompressed PCM audio decoder
AUDIO: 96000 Hz, 2 ch, s24le, 4608.0 kbit/100.00% (ratio: 576000-576000)
Selected audio codec: [pcm] afm: pcm (Uncompressed PCM)
AO: [oss] 48000Hz 2ch s24le (3 bytes per sample)
And
Adaptive and bitperfect, cannot play 16 bit source,
while this-
http://people.xiph.org/~xiphmont/demo/Pido_O_trollbat.wav
92/24 plays but it's white noise, and it should be silent (and it was
previously).
usbconfig -d X.Y dump_curr_config_desc
http://pastebin.com/vkZu3v3z
usbdump -i usbus4
Which would explain why I now have dev.pcm.0.play.vchanrate: 48000
if bitperfect is set, while previously it was dev.pcm.0.play.vchanrate:
96000 ?
e.g. now if bitperfect is set-
AUDIO: 44100 Hz, 2 ch, s16le, 0.0 kbit/0.00% (ratio: 0-176400)
Selected audio codec: [ffwavpack] afm: ffmpeg (FFmpeg
I've got such adapter with microsd purchase,
http://www.trueaccessories.com/images/MicroSD-USB-Adapter.jpg
it appears to me it's missing come active component to constitute
a proper usb disk, (it's only pin rewire thing) and as such is not
detected at all by FreeBSD. How could I amend this?
I overthinked it, it was a matter of simply loading uhci driver,
and I was used to ehci getting care of all usb drives :)
--
View this message in context:
http://freebsd.1045724.n5.nabble.com/microsd-to-usb-adpater-on-FreeBSD-tp5783672p5783674.html
Sent from the freebsd-usb mailing list
Ah.
But it still needs
devd_enable=YES
to be workable?
--
View this message in context:
http://freebsd.1045724.n5.nabble.com/USB-devices-not-autodetecting-anymore-on-stable-tp5766270p5768832.html
Sent from the freebsd-usb mailing list archive at Nabble.com.
While I had peek in defaults, I was confused by HPS answer, now I'm
just confused why devd does nothing on my system. Or does it?
Will check on next reboot.
Thanks for replies.
--
View this message in context:
...and here I was, not noticing devd at all, and used to manually
loading drivers.
I had no devd_enable in rc.conf though, how come this daemon
is started anyway?
--
View this message in context:
31 matches
Mail list logo
