webcamd and wacom
Hello, I see that freshports has posted an update to x11-driver/input-wacom. I've been trying to work on that myself, but it's been slow going, and I haven't made much progress. So I was happily surprised to see the update, and wanted to try it as soon as I could. I think I have everything installed and configured properly. I can see the /dev/input/event0 device, but when I start X it logs the following entries: # grep -i wacom /var/log/Xorg.0.log (II) LoadModule: wacom (II) Loading /usr/local/lib/xorg/modules/input/wacom_drv.so (II) Module wacom: vendor=X.Org Foundation (--) stylus: Wacom USB Bamboo tablet maxX=14720 maxY=9200 maxZ=1023 resX=10 resY=10 tilt=disabled (EE) stylus: Wacom X driver can't grab event device (Bad address) (--) eraser: Wacom USB Bamboo tablet maxX=14720 maxY=9200 maxZ=1023 resX=10 resY=10 tilt=disabled (EE) eraser: Wacom X driver can't grab event device (Bad address) (--) cursor: Wacom USB Bamboo tablet maxX=14720 maxY=9200 maxZ=1023 resX=10 resY=10 tilt=disabled (EE) cursor: Wacom X driver can't grab event device (Bad address) (--) pad: Wacom USB Bamboo tablet maxX=14720 maxY=9200 maxZ=1023 resX=10 resY=10 tilt=disabled (EE) pad: Wacom X driver can't grab event device (Bad address) (--) touch: Wacom USB Bamboo tablet maxX=14720 maxY=9200 maxZ=1023 resX=10 resY=10 tilt=disabled (EE) touch: Wacom X driver can't grab event device (Bad address) (II) UnloadModule: wacom (II) UnloadModule: wacom (II) UnloadModule: wacom (II) UnloadModule: wacom (II) UnloadModule: wacom # Does anyone have any idea what I'm missing here? cuse4bsd.ko is loaded, and webcamd is running. I'm not sure what else I can include that will be helpful, but if there is something else, let me know and I will supply it. Hopefully this will turn out to be something simple. Thanks, Denver ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to freebsd-usb-unsubscr...@freebsd.org
Re: wacom and x11 and webcamd
Hello, I discovered this when I saw an update to input-wacom at freshports.org. I've installed cuse4bsd, the new input-wacom, and the latest webcamd: cuse4bsd-kmod-0.1.23 input-wacom-40.0.11.1 webcamd-3.2.0.2 I believe I've followed all the instructions properly, and when I start webcamd, everything seems to be correct: Attached ugen1.2[0] to cuse unit 0 Creating /dev/input/event0 According to dmesg, ugen1.2 is the correct device (I have a Bamboo Pen): ugen1.2: Wacom Co.,Ltd. at usbus1 The /dev/input/event0 node is indeed created. However, when I start X, I get the following: (EE) stylus: Wacom X driver can't grab event device (Bad address) (EE) eraser: Wacom X driver can't grab event device (Bad address) (EE) cursor: Wacom X driver can't grab event device (Bad address) (EE) pad: Wacom X driver can't grab event device (Bad address) (EE) touch: Wacom X driver can't grab event device (Bad address) Protocol not supported by server The last line repeats indefinitely, and X never finishes starting up. The system I'm trying this on is 8.3-PRERELEASE. I had tried this quickly a while ago on 8.2-STABLE with similar results. Does anyone have any ideas about what might be wrong? Regards, Denver ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to freebsd-usb-unsubscr...@freebsd.org
Re: wacom and x11 and webcamd
Hans Petter Selasky wrote: On Saturday 24 March 2012 18:14:41 Denver Hull wrote: Hello, I discovered this when I saw an update to input-wacom at freshports.org. I've installed cuse4bsd, the new input-wacom, and the latest webcamd: cuse4bsd-kmod-0.1.23 input-wacom-40.0.11.1 webcamd-3.2.0.2 I believe I've followed all the instructions properly, and when I start webcamd, everything seems to be correct: Attached ugen1.2[0] to cuse unit 0 Creating /dev/input/event0 According to dmesg, ugen1.2 is the correct device (I have a Bamboo Pen): ugen1.2:Wacom Co.,Ltd. at usbus1 The /dev/input/event0 node is indeed created. However, when I start X, I get the following: (EE) stylus: Wacom X driver can't grab event device (Bad address) (EE) eraser: Wacom X driver can't grab event device (Bad address) (EE) cursor: Wacom X driver can't grab event device (Bad address) (EE) pad: Wacom X driver can't grab event device (Bad address) (EE) touch: Wacom X driver can't grab event device (Bad address) Protocol not supported by server The last line repeats indefinitely, and X never finishes starting up. The system I'm trying this on is 8.3-PRERELEASE. I had tried this quickly a while ago on 8.2-STABLE with similar results. Does anyone have any ideas about what might be wrong? Hi, I think the wacom has two interfaces. So you need to do two instances of webcamd, using -i 0 and -i 1 . Else search google for webcamd-3.4.0.1 --HPS Hi Hans, Thanks for the reply. I did have trouble figuring out how to get webcamd started properly. The start script in /usr/local/etc/rc.d looks like it needs at least two parameters, but it wasn't clear what they should be. When I get a chance I'll look at that again see if I can figure something out. I'll let you know how I do. The Protocol not supported problem was something else, not related to the tablet or webcamd. Thanks again, Denver ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to freebsd-usb-unsubscr...@freebsd.org
Re: wacom and x11 and webcamd
Hans Petter Selasky wrote: On Saturday 24 March 2012 18:14:41 Denver Hull wrote: Hello, I discovered this when I saw an update to input-wacom at freshports.org. I've installed cuse4bsd, the new input-wacom, and the latest webcamd: cuse4bsd-kmod-0.1.23 input-wacom-40.0.11.1 webcamd-3.2.0.2 I believe I've followed all the instructions properly, and when I start webcamd, everything seems to be correct: Attached ugen1.2[0] to cuse unit 0 Creating /dev/input/event0 According to dmesg, ugen1.2 is the correct device (I have a Bamboo Pen): ugen1.2:Wacom Co.,Ltd. at usbus1 The /dev/input/event0 node is indeed created. However, when I start X, I get the following: (EE) stylus: Wacom X driver can't grab event device (Bad address) (EE) eraser: Wacom X driver can't grab event device (Bad address) (EE) cursor: Wacom X driver can't grab event device (Bad address) (EE) pad: Wacom X driver can't grab event device (Bad address) (EE) touch: Wacom X driver can't grab event device (Bad address) Protocol not supported by server The last line repeats indefinitely, and X never finishes starting up. The system I'm trying this on is 8.3-PRERELEASE. I had tried this quickly a while ago on 8.2-STABLE with similar results. Does anyone have any ideas about what might be wrong? Hi, I think the wacom has two interfaces. So you need to do two instances of webcamd, using -i 0 and -i 1 . Else search google for webcamd-3.4.0.1 --HPS My Bamboo Pen is working fine now. I installed your latest version, webcamd-3.4.0.1, and that takes care of getting webcamd started properly. It's still necessary to make sure moused doesn't attach to the tablet. I'm not sure what the best way is to do that, but for now I've adjusted /etc/devd.conf so only the first ums device gets attached. Thanks Hans, this is great. I wish I had one or two other devices I could try. Denver ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to freebsd-usb-unsubscr...@freebsd.org
Re: wacom and x11 and webcamd
Hans Petter Selasky wrote: On Thursday 29 March 2012 23:20:43 Denver Hull wrote: Hans Petter Selasky wrote: On Saturday 24 March 2012 18:14:41 Denver Hull wrote: Hello, I discovered this when I saw an update to input-wacom at freshports.org. I've installed cuse4bsd, the new input-wacom, and the latest webcamd: cuse4bsd-kmod-0.1.23 input-wacom-40.0.11.1 webcamd-3.2.0.2 I believe I've followed all the instructions properly, and when I start webcamd, everything seems to be correct: Attached ugen1.2[0] to cuse unit 0 Creating /dev/input/event0 According to dmesg, ugen1.2 is the correct device (I have a Bamboo Pen): ugen1.2:Wacom Co.,Ltd. at usbus1 The /dev/input/event0 node is indeed created. However, when I start X, I get the following: (EE) stylus: Wacom X driver can't grab event device (Bad address) (EE) eraser: Wacom X driver can't grab event device (Bad address) (EE) cursor: Wacom X driver can't grab event device (Bad address) (EE) pad: Wacom X driver can't grab event device (Bad address) (EE) touch: Wacom X driver can't grab event device (Bad address) Protocol not supported by server The last line repeats indefinitely, and X never finishes starting up. The system I'm trying this on is 8.3-PRERELEASE. I had tried this quickly a while ago on 8.2-STABLE with similar results. Does anyone have any ideas about what might be wrong? Hi, I think the wacom has two interfaces. So you need to do two instances of webcamd, using -i 0 and -i 1 . Else search google for webcamd-3.4.0.1 --HPS My Bamboo Pen is working fine now. I installed your latest version, webcamd-3.4.0.1, and that takes care of getting webcamd started properly. It's still necessary to make sure moused doesn't attach to the tablet. I'm not sure what the best way is to do that, but for now I've adjusted /etc/devd.conf so only the first ums device gets attached. Thanks Hans, this is great. I wish I had one or two other devices I could try. Hi, To avoid ums attach, see usbconfig dump_quirk_names | grep UMS. --HPS I don't get anything with that command on my 8.2-STABLE system. Is that something that will work on 9 but not 8? Thanks, Denver ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to freebsd-usb-unsubscr...@freebsd.org
Re: wacom and x11 and webcamd
Hans Petter Selasky wrote: On Monday 09 April 2012 19:59:17 Denver Hull wrote: Hans Petter Selasky wrote: On Thursday 29 March 2012 23:20:43 Denver Hull wrote: Hans Petter Selasky wrote: On Saturday 24 March 2012 18:14:41 Denver Hull wrote: Hello, I discovered this when I saw an update to input-wacom at freshports.org. I've installed cuse4bsd, the new input-wacom, and the latest webcamd: cuse4bsd-kmod-0.1.23 input-wacom-40.0.11.1 webcamd-3.2.0.2 I believe I've followed all the instructions properly, and when I start webcamd, everything seems to be correct: Attached ugen1.2[0] to cuse unit 0 Creating /dev/input/event0 According to dmesg, ugen1.2 is the correct device (I have a Bamboo Pen): ugen1.2:Wacom Co.,Ltd.at usbus1 The /dev/input/event0 node is indeed created. However, when I start X, I get the following: (EE) stylus: Wacom X driver can't grab event device (Bad address) (EE) eraser: Wacom X driver can't grab event device (Bad address) (EE) cursor: Wacom X driver can't grab event device (Bad address) (EE) pad: Wacom X driver can't grab event device (Bad address) (EE) touch: Wacom X driver can't grab event device (Bad address) Protocol not supported by server The last line repeats indefinitely, and X never finishes starting up. The system I'm trying this on is 8.3-PRERELEASE. I had tried this quickly a while ago on 8.2-STABLE with similar results. Does anyone have any ideas about what might be wrong? Hi, I think the wacom has two interfaces. So you need to do two instances of webcamd, using -i 0 and -i 1 . Else search google for webcamd-3.4.0.1 --HPS My Bamboo Pen is working fine now. I installed your latest version, webcamd-3.4.0.1, and that takes care of getting webcamd started properly. It's still necessary to make sure moused doesn't attach to the tablet. I'm not sure what the best way is to do that, but for now I've adjusted /etc/devd.conf so only the first ums device gets attached. Thanks Hans, this is great. I wish I had one or two other devices I could try. Hi, To avoid ums attach, see usbconfig dump_quirk_names | grep UMS. --HPS I don't get anything with that command on my 8.2-STABLE system. Is that something that will work on 9 but not 8? Did you kldload usb_quirk ? --HPS Well, that reports kldload: can't load usb_quirk: File exists, but usb_quirk isn't listed in kldstat. The man page for usb_quirk(4) doesn't show anything for UMS. However, everything listed in the man page is reported by usbconfig dump_quirk_names. Or at least it looks that way. I didn't do a line by line check. I checked my kernel conf file, and there's no device usb_quirk line, and it's not in loader.conf, so I'm not sure where it's coming from. In my experience that kldload error usually just means it's compiled in. But it's not listed in my kernel conf file. So that's kind of a mystery. Thanks, Denver ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to freebsd-usb-unsubscr...@freebsd.org
Re: wacom and x11 and webcamd
Hans Petter Selasky wrote: On Monday 09 April 2012 21:28:02 Denver Hull wrote: Hans Petter Selasky wrote: On Monday 09 April 2012 19:59:17 Denver Hull wrote: Hans Petter Selasky wrote: On Thursday 29 March 2012 23:20:43 Denver Hull wrote: Hans Petter Selasky wrote: On Saturday 24 March 2012 18:14:41 Denver Hull wrote: Hello, I discovered this when I saw an update to input-wacom at freshports.org. I've installed cuse4bsd, the new input-wacom, and the latest webcamd: cuse4bsd-kmod-0.1.23 input-wacom-40.0.11.1 webcamd-3.2.0.2 I believe I've followed all the instructions properly, and when I start webcamd, everything seems to be correct: Attached ugen1.2[0] to cuse unit 0 Creating /dev/input/event0 According to dmesg, ugen1.2 is the correct device (I have a Bamboo Pen): ugen1.2:Wacom Co.,Ltd. at usbus1 The /dev/input/event0 node is indeed created. However, when I start X, I get the following: (EE) stylus: Wacom X driver can't grab event device (Bad address) (EE) eraser: Wacom X driver can't grab event device (Bad address) (EE) cursor: Wacom X driver can't grab event device (Bad address) (EE) pad: Wacom X driver can't grab event device (Bad address) (EE) touch: Wacom X driver can't grab event device (Bad address) Protocol not supported by server The last line repeats indefinitely, and X never finishes starting up. The system I'm trying this on is 8.3-PRERELEASE. I had tried this quickly a while ago on 8.2-STABLE with similar results. Does anyone have any ideas about what might be wrong? Hi, I think the wacom has two interfaces. So you need to do two instances of webcamd, using -i 0 and -i 1 . Else search google for webcamd-3.4.0.1 --HPS My Bamboo Pen is working fine now. I installed your latest version, webcamd-3.4.0.1, and that takes care of getting webcamd started properly. It's still necessary to make sure moused doesn't attach to the tablet. I'm not sure what the best way is to do that, but for now I've adjusted /etc/devd.conf so only the first ums device gets attached. Thanks Hans, this is great. I wish I had one or two other devices I could try. Hi, To avoid ums attach, see usbconfig dump_quirk_names | grep UMS. --HPS I don't get anything with that command on my 8.2-STABLE system. Is that something that will work on 9 but not 8? Did you kldload usb_quirk ? --HPS Well, that reports kldload: can't load usb_quirk: File exists, but usb_quirk isn't listed in kldstat. The man page for usb_quirk(4) doesn't show anything for UMS. However, everything listed in the man page is reported by usbconfig dump_quirk_names. Or at least it looks that way. I didn't do a line by line check. I checked my kernel conf file, and there's no device usb_quirk line, and it's not in loader.conf, so I'm not sure where it's coming from. In my experience that kldload error usually just means it's compiled in. But it's not listed in my kernel conf file. So that's kind of a mystery. Did you run the usbconfig command like root ? --HPS Yes. ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to freebsd-usb-unsubscr...@freebsd.org
Re: wacom and x11 and webcamd
Hans Petter Selasky wrote: On Monday 09 April 2012 21:41:30 Denver Hull wrote: Hans Petter Selasky wrote: Did you run the usbconfig command like root ? --HPS Yes. Hi, It looks like we currently don't have a quirk for UMS, like the following. Adding one such though would be trivial. UQ_HID_IGNORE UQ_KBD_IGNORE --HPS Ok, so until we do have one, I'll continue to use devd.conf to specify the exact device for moused. Thanks, Denver ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to freebsd-usb-unsubscr...@freebsd.org
Re: Seagate FreeAgent GoFlex 1.5TB external HDD problems
Hans Petter Selasky wrote: BTW: You could try to make a simple c-test program that reads and writes random LBA's from user-space, and see when it stops working. Sorry to interrupt, but I have a test program that does exactly that, and more, that I used to use when I was testing SCSI disk arrays. It works on a number of platforms, including FreeBSD, and should work on any type of storage device. If you're interested, I can either send you the source, or make it available by ftp. Might be easier than cobbling something up from scratch. Thanks, Denver ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to freebsd-usb-unsubscr...@freebsd.org
Re: Seagate FreeAgent GoFlex 1.5TB external HDD problems
maxim naumov wrote: On Mon, Jun 25, 2012 at 4:29 PM, Denver Hulldenv...@comcast.net wrote: storage device. If you're interested, I can either send you the source, or make it available by ftp. Might be easier than cobbling something up from scratch. Denver, that is very considerate of you. please do send me the source. I was going to use iozone but so far couldn't figure out how to make it work on block devices. I am also going to try msdosfs on that drive in the meantime. /max The source is available here: http://irresistible-images.com/files/diskrand/diskrand.tgz For instructions, just type diskrand with no parameters. If you have any trouble with it let me know. It's been a while since I used it, but I can probably still figure it out. To build it, use gmake in the parent (diskrand) directory. It will figure out your platform and build diskrand in the appropriate subdirectory: BSD, LINUX, SGI, etc. Optional gmake targets you can use are all, clean, install. You may need to use clean first, then install. For FreeBSD, install puts the executable in /usr/local/bin. It's mostly a tool to check for data corruption, so the normal use automatically includes an initial data fill over the specified range unless you disable it with -n. The data consists of a pattern based on the LBA. Data compare errors result in an output of all the data that didn't match, then it stops. Other errors will also cause it to stop. Reads always include a verification of the data, and writes are always a data pattern based on the LBA. It's unique for each LBA, but always the same for a specific LBA. In normal operation everything after the initialization is random: the starting LBA, the size of the transfer, whether it's a read or write. You can override any of that with the command-line switches. You can run multiple copies of diskrand on one device by assigning a different range within the device for each copy. You can get a lot of I/O activity going with that method. I guess that's about all. Let me know if you have any questions. Thanks, Denver ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to freebsd-usb-unsubscr...@freebsd.org
Retry a device reporting medium not present
Hello,
I have a Sony PRS 650 ebook reader that always reports medium not present when it's first plugged in. On FreeBSD this results in device nodes that aren't functional. On other systems, like Linux or Windows, retries are performed, with the result that the reader is accessible as it should be. An interesting note about this is that if I delete all the books on the reader it does not initially report medium not present when it's plugged in. In which case everything works as it should on FreeBSD. But after I've added books it begins to report medium not present. If the reader, with books, is present in when the system boots up then everything is fine. My impression of all this is that once I've loaded the reader up with some books, it takes it a little while to become ready after it's plugged into a USB port. When it reports medium not present, FreeBSD just gives up on it. At least that's the difference I see in the dmesg reports between Linux and FreeBSD. Linux
retries, and is successful, FreeBSD doesn't.
I've searched around to see if I could find an answer to this, but haven't
found anything very helpful. I have found various reports of situations that
sound similar, but never with any solid resolution. It may be that it was
never clear that the sequence I've described was occurring.
I have managed to get the reader to function by adding the following to
/etc/devd.conf:
attach 100 {
match device-name ugen[0-9]+.[0-9]+;
match vendor 0x054c;
match product 0x031e;
# 2 seconds is marginal:
action /bin/sleep 3;
action /usr/sbin/usbconfig -d $device-name set_config 1;
action /usr/sbin/usbconfig -d $device-name set_config 0;
};
I've been using that for about a year and a half. I think I came up with it
after combining suggestions from various places for cases where a device would
work if it was present when the system booted, but not when it was plugged in
after the system was running. I don't think it's the best answer, but so far
it's the only one I've found that works consistently. A quirk that allowed for
retries that could be applied to this situation would, I think, be a perfect
solution. Or is there already a solution that I haven't discovered?
I'm currently running FreeBSD 9.2-STABLE #2 r258073, i386. The reader has
behaved the same way on systems with 8.x, i386 and amd64.
I will be happy to supply any additional information that may be required.
Thanks,
Denver
___
freebsd-usb@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-usb
To unsubscribe, send any mail to freebsd-usb-unsubscr...@freebsd.org
Re: Timeouts during initial Mode Sense commands
Hans Petter Selasky wrote: On 2019-12-21 00:46, Denver Hull wrote: How hard would it be to change things to use 0x1a instead of 0x5a temporarily? There is a tool called usbtest in /usr/src/tools/tools/usbtest which can exercise the SCSI commands for mass storage devices. --HPS Very nice, thanks. My tools require an actual SCSI device node so they aren't much help when there isn't one. The usbtest host mode tests seem to work ok with the device in question, but not the mass storage tests: >30 Attaching to: ugen2.12: Express> at usbus2 @ iface 2 Resetting device ... Testing SCSI commands ... ERROR: CBW reception: 4 ERROR: CBW reception: 4 ERROR: CBW reception: 4 Cannot read disk capacity (0 / 4) ERROR: CBW reception: 4 Cannot read disk capacity (1 / 4) ERROR: CBW reception: 4 Cannot read disk capacity (2 / 4) ERROR: CBW reception: 4 Cannot read disk capacity (3 / 4) [0.2.4] - Mass Storage Test Parameters: However, I did dust off one of my old tools and tried using it to send both 6 byte and 10 byte mode sense commands from Linux. The 6 byte commands always worked, but not the 10. They resulted in lots of "connection reset by peer" and "broken pipe" status messages, along with port reset commands. I saved wireshark/usbmon traces from both, and have attached them. I think they're small enough to get through this time. If the problem with these devices really is that they can't respond properly to 10 byte mode sense commands (and that's how it's beginning to look), then what? Thanks, Denver ___ freebsd-usb@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to "freebsd-usb-unsubscr...@freebsd.org"
Re: Timeouts during initial Mode Sense commands
Hans Petter Selasky wrote: On 2019-12-19 01:11, Denver Hull wrote: Hello, I have several different microcontroller boards that are supposed to appear as storage devices when plugged in. They work fine on Linux systems, but on FreeBSD 11.3 and 12.1 they don't show up at all. Here's what dmesg shows for one of them: ugen1.3: at usbus1 umodem0 on uhub1 umodem0: on usbus1 umodem0: data interface 1, has no CM over data, has no break umass3 on uhub1 umass3: on usbus1 umass3: SCSI over Bulk-Only; quirks = 0x umass3:5:3: Attached to scbus5 uaudio0 on uhub1 uaudio0: on usbus1 uaudio0: No playback. uaudio0: No recording. uaudio0: MIDI sequencer. uaudio0: No HID volume keys found. ums2 on uhub1 ums2: on usbus1 ums2: 16 buttons and [XYZ] coordinates ID=2 (da3:umass-sim3:3:0:0): got CAM status 0x44 (da3:umass-sim3:3:0:0): fatal error, failed to attach to device g_access(944): provider da3 has error 6 set g_access(944): provider da3 has error 6 set g_access(944): provider da3 has error 6 set g_access(944): provider da3 has error 6 set g_access(944): provider da3 has error 6 set There's a definite delay after the last ums message. I used camcontrol debug in single user mode on a bare 12.1 system to get a little more information about what was happening. It looks like the initial Inquiry and Test Unit Ready commands succeed, but the next Mode Sense command times out, as well as all subsequent commands. There are several seconds of inactivity between retries, and there's no sense data, so I'm assuming that indicates timeout. At this point I'm not sure how best to proceed to get these devices to work, so any help will be appreciated. Did you try setting one or more quirks for these devices using usbconfig? UQ_MSC_NO_TEST_UNIT_READY UQ_MSC_NO_RS_CLEAR_UA UQ_MSC_NO_START_STOP UQ_MSC_NO_GETMAXLUN UQ_MSC_NO_INQUIRY UQ_MSC_NO_INQUIRY_EVPD UQ_MSC_NO_PREVENT_ALLOW UQ_MSC_NO_SYNC_CACHE UQ_MSC_SHUTTLE_INIT UQ_MSC_ALT_IFACE_1 UQ_MSC_FLOPPY_SPEED UQ_MSC_IGNORE_RESIDUE UQ_MSC_WRONG_CSWSIG UQ_MSC_RBC_PAD_TO_12 UQ_MSC_READ_CAP_OFFBY1 UQ_MSC_FORCE_SHORT_INQ If you run "usbdump -i usbusX -f Y -s 65536 -vvv" you might see the last failing SCSI command. X.Y are numbers after ugen for your device. Likely your device has a software bug in its USB/SCSI implementation, which is quite common unfortunately. --HPS After I sent the previous message I did try UQ_MSC_NO_TEST_UNIT_READY. Although the system reports "quirks = 0001", the initial TUR is still being issued during the probe sequence. I tried the usbdump command you suggested, and I can clearly see where the timeouts are, and frames that begin with "USBC" seem to contain a SCSI CDB. But there's a lot of other stuff in between that I haven't been able to figure out, so I've attached a sample. Hopefully it will help. Thanks, Denver 08:55:51.780196 usbus2.12 SUBM-CTRL-EP=,SPD=FULL,NFR=1,SLEN=8,IVAL=0 frame[0] WRITE 8 bytes 00 05 0C 00 00 00 00 00 -- -- -- -- -- -- -- -- || flags 0x50 status 0xea3a3 08:55:51.780364 usbus2.12 DONE-CTRL-EP=,SPD=FULL,NFR=1,SLEN=0,IVAL=0,ERR=0 frame[0] WRITE 8 bytes flags 0x50 status 0xca3a1 08:55:51.780399 usbus2.12 SUBM-CTRL-EP=,SPD=FULL,NFR=1,SLEN=0,IVAL=0 frame[0] WRITE 0 bytes flags 0x10 status 0xca0a3 08:55:51.828994 usbus2.12 DONE-CTRL-EP=,SPD=FULL,NFR=1,SLEN=0,IVAL=0,ERR=0 frame[0] WRITE 0 bytes flags 0x10 status 0xea0a1 08:55:51.843106 usbus2.12 SUBM-CTRL-EP=0080,SPD=FULL,NFR=2,SLEN=8,IVAL=0 frame[0] WRITE 8 bytes 80 06 00 01 00 00 08 00 -- -- -- -- -- -- -- -- || frame[1] READ 8 bytes flags 0x10 status 0xea1a3 08:55:51.846842 usbus2.12 DONE-CTRL-EP=0080,SPD=FULL,NFR=2,SLEN=8,IVAL=0,ERR=0 frame[0] WRITE 8 bytes frame[1] READ 8 bytes 12 01 00 02 00 00 00 40 -- -- -- -- -- -- -- -- |...@| flags 0x10 status 0xca1a1 08:55:51.850023 usbus2.12 SUBM-CTRL-EP=0080,SPD=FULL,NFR=2,SLEN=8,IVAL=0 frame[0] WRITE 8 bytes 80 06 00 01 00 00 12 00 -- -- -- -- -- -- -- -- || frame[1] READ 18 bytes flags 0x10 status 0xea1a3 08:55:51.851824 usbus2.12 DONE-CTRL-EP=0080,SPD=FULL,NFR=2,SLEN=20,IVAL=0,ERR=0 frame[0] WRITE 8 bytes frame[1] READ 18 bytes 12 01 00 02 00 00 00 40 9A 23 36 80 00 01 02 03 |...@.#6.| 0010 01 01 -- -- -- -- -- -- -- -- -- -- -- -- -- -- |.. | flags 0x10 status 0xca1a1 08:55:51.851839 usbus2.12 SUBM-CTRL-EP=0080,SPD=FULL,NFR=2,SLEN=8,IVAL=0 frame[0] WRITE 8 bytes 80 06 00 03 00 00 02 00 -- -- -- -- -- -- -- -- || frame[1] READ 2 bytes flags 0x10 status 0xca1a3 08:55:51.856952 usbus2.12 DONE-CTRL-EP=0080,SPD=FULL,NFR=2,SLEN=4,IVAL=0,ERR=0 frame[0] WRITE 8 bytes frame[1] READ 2 bytes 04 03 -- -- -- -- -- -- -- -- -- -- -- -- -- -- |.. | flags 0x10 status 0xea1a1 08:55:51
Timeouts during initial Mode Sense commands
Hello, I have several different microcontroller boards that are supposed to appear as storage devices when plugged in. They work fine on Linux systems, but on FreeBSD 11.3 and 12.1 they don't show up at all. Here's what dmesg shows for one of them: ugen1.3: at usbus1 umodem0 on uhub1 umodem0: on usbus1 umodem0: data interface 1, has no CM over data, has no break umass3 on uhub1 umass3: on usbus1 umass3: SCSI over Bulk-Only; quirks = 0x umass3:5:3: Attached to scbus5 uaudio0 on uhub1 uaudio0: on usbus1 uaudio0: No playback. uaudio0: No recording. uaudio0: MIDI sequencer. uaudio0: No HID volume keys found. ums2 on uhub1 ums2: on usbus1 ums2: 16 buttons and [XYZ] coordinates ID=2 (da3:umass-sim3:3:0:0): got CAM status 0x44 (da3:umass-sim3:3:0:0): fatal error, failed to attach to device g_access(944): provider da3 has error 6 set g_access(944): provider da3 has error 6 set g_access(944): provider da3 has error 6 set g_access(944): provider da3 has error 6 set g_access(944): provider da3 has error 6 set There's a definite delay after the last ums message. I used camcontrol debug in single user mode on a bare 12.1 system to get a little more information about what was happening. It looks like the initial Inquiry and Test Unit Ready commands succeed, but the next Mode Sense command times out, as well as all subsequent commands. There are several seconds of inactivity between retries, and there's no sense data, so I'm assuming that indicates timeout. At this point I'm not sure how best to proceed to get these devices to work, so any help will be appreciated. Regards, Denver ___ freebsd-usb@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to "freebsd-usb-unsubscr...@freebsd.org"
Re: Timeouts during initial Mode Sense commands
Hans Petter Selasky wrote:
On 2019-12-20 13:54, Denver Hull wrote:
Hans Petter Selasky wrote:
On 2019-12-19 01:11, Denver Hull wrote:
Hello,
I have several different microcontroller boards that are supposed
to appear as storage devices when plugged in. They work fine on
Linux systems, but on FreeBSD 11.3 and 12.1 they don't show up at
all. Here's what dmesg shows for one of them:
ugen1.3: at usbus1
umodem0 on uhub1
umodem0: on usbus1
umodem0: data interface 1, has no CM over data, has no break
umass3 on uhub1
umass3: on usbus1
umass3: SCSI over Bulk-Only; quirks = 0x
umass3:5:3: Attached to scbus5
uaudio0 on uhub1
uaudio0: on usbus1
uaudio0: No playback.
uaudio0: No recording.
uaudio0: MIDI sequencer.
uaudio0: No HID volume keys found.
ums2 on uhub1
ums2: on usbus1
ums2: 16 buttons and [XYZ] coordinates ID=2
(da3:umass-sim3:3:0:0): got CAM status 0x44
(da3:umass-sim3:3:0:0): fatal error, failed to attach to device
g_access(944): provider da3 has error 6 set
g_access(944): provider da3 has error 6 set
g_access(944): provider da3 has error 6 set
g_access(944): provider da3 has error 6 set
g_access(944): provider da3 has error 6 set
There's a definite delay after the last ums message. I used
camcontrol debug in single user mode on a bare 12.1 system to get a
little more information about what was happening. It looks like the
initial Inquiry and Test Unit Ready commands succeed, but the next
Mode Sense command times out, as well as all subsequent commands.
There are several seconds of inactivity between retries, and
there's no sense data, so I'm assuming that indicates timeout.
At this point I'm not sure how best to proceed to get these devices
to work, so any help will be appreciated.
Did you try setting one or more quirks for these devices using
usbconfig?
UQ_MSC_NO_TEST_UNIT_READY
UQ_MSC_NO_RS_CLEAR_UA
UQ_MSC_NO_START_STOP
UQ_MSC_NO_GETMAXLUN
UQ_MSC_NO_INQUIRY
UQ_MSC_NO_INQUIRY_EVPD
UQ_MSC_NO_PREVENT_ALLOW
UQ_MSC_NO_SYNC_CACHE
UQ_MSC_SHUTTLE_INIT
UQ_MSC_ALT_IFACE_1
UQ_MSC_FLOPPY_SPEED
UQ_MSC_IGNORE_RESIDUE
UQ_MSC_WRONG_CSWSIG
UQ_MSC_RBC_PAD_TO_12
UQ_MSC_READ_CAP_OFFBY1
UQ_MSC_FORCE_SHORT_INQ
If you run "usbdump -i usbusX -f Y -s 65536 -vvv" you might see the
last failing SCSI command. X.Y are numbers after ugen for your device.
Likely your device has a software bug in its USB/SCSI
implementation, which is quite common unfortunately.
--HPS
After I sent the previous message I did try
UQ_MSC_NO_TEST_UNIT_READY. Although the system reports "quirks =
0001", the initial TUR is still being issued during the probe
sequence. I tried the usbdump command you suggested, and I can
clearly see where the timeouts are, and frames that begin with "USBC"
seem to contain a SCSI CDB. But there's a lot of other stuff in
between that I haven't been able to figure out, so I've attached a
sample. Hopefully it will help.
Hi,
All the USBC's are raw SCSI commands, which use the following layout:
/* Command Block Wrapper */
typedef struct {
uDWord dCBWSignature;
#define CBWSIGNATURE 0x43425355
uDWord dCBWTag;
uDWord dCBWDataTransferLength;
uByte bCBWFlags;
#define CBWFLAGS_OUT 0x00
#define CBWFLAGS_IN 0x80
uByte bCBWLUN;
uByte bCDBLength;
#define CBWCDBLENGTH 16
uByte CBWCDB[CBWCDBLENGTH];
} __packed umass_bbb_cbw_t;
We had a SoC to add support for the usbdump format to wireshark:
https://wiki.freebsd.org/SummerOfCode2017/usbdump-wireshark
You might find that useful.
My first suspicion is that your device is not fully USB class
compliant, and that's why it is STALLING and failing to recover.
--HPS
Wireshark: I was wondering if that might not work. I'll look into it,
thanks.
I saw that stall, but with everything else that's going on in there, I
couldn't tell if it was significant or not. I'll see if I can find out
how Linux is negotiating with this device and post the results. I don't
know if that will help or not, but it's worth trying.
Thanks,
Denver
___
freebsd-usb@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-usb
To unsubscribe, send any mail to "freebsd-usb-unsubscr...@freebsd.org"
Re: Timeouts during initial Mode Sense commands
Hans Petter Selasky wrote:
On 2019-12-20 13:54, Denver Hull wrote:
Hans Petter Selasky wrote:
On 2019-12-19 01:11, Denver Hull wrote:
Hello,
I have several different microcontroller boards that are supposed
to appear as storage devices when plugged in. They work fine on
Linux systems, but on FreeBSD 11.3 and 12.1 they don't show up at
all. Here's what dmesg shows for one of them:
ugen1.3: at usbus1
umodem0 on uhub1
umodem0: on usbus1
umodem0: data interface 1, has no CM over data, has no break
umass3 on uhub1
umass3: on usbus1
umass3: SCSI over Bulk-Only; quirks = 0x
umass3:5:3: Attached to scbus5
uaudio0 on uhub1
uaudio0: on usbus1
uaudio0: No playback.
uaudio0: No recording.
uaudio0: MIDI sequencer.
uaudio0: No HID volume keys found.
ums2 on uhub1
ums2: on usbus1
ums2: 16 buttons and [XYZ] coordinates ID=2
(da3:umass-sim3:3:0:0): got CAM status 0x44
(da3:umass-sim3:3:0:0): fatal error, failed to attach to device
g_access(944): provider da3 has error 6 set
g_access(944): provider da3 has error 6 set
g_access(944): provider da3 has error 6 set
g_access(944): provider da3 has error 6 set
g_access(944): provider da3 has error 6 set
There's a definite delay after the last ums message. I used
camcontrol debug in single user mode on a bare 12.1 system to get a
little more information about what was happening. It looks like the
initial Inquiry and Test Unit Ready commands succeed, but the next
Mode Sense command times out, as well as all subsequent commands.
There are several seconds of inactivity between retries, and
there's no sense data, so I'm assuming that indicates timeout.
At this point I'm not sure how best to proceed to get these devices
to work, so any help will be appreciated.
Did you try setting one or more quirks for these devices using
usbconfig?
UQ_MSC_NO_TEST_UNIT_READY
UQ_MSC_NO_RS_CLEAR_UA
UQ_MSC_NO_START_STOP
UQ_MSC_NO_GETMAXLUN
UQ_MSC_NO_INQUIRY
UQ_MSC_NO_INQUIRY_EVPD
UQ_MSC_NO_PREVENT_ALLOW
UQ_MSC_NO_SYNC_CACHE
UQ_MSC_SHUTTLE_INIT
UQ_MSC_ALT_IFACE_1
UQ_MSC_FLOPPY_SPEED
UQ_MSC_IGNORE_RESIDUE
UQ_MSC_WRONG_CSWSIG
UQ_MSC_RBC_PAD_TO_12
UQ_MSC_READ_CAP_OFFBY1
UQ_MSC_FORCE_SHORT_INQ
If you run "usbdump -i usbusX -f Y -s 65536 -vvv" you might see the
last failing SCSI command. X.Y are numbers after ugen for your device.
Likely your device has a software bug in its USB/SCSI
implementation, which is quite common unfortunately.
--HPS
After I sent the previous message I did try
UQ_MSC_NO_TEST_UNIT_READY. Although the system reports "quirks =
0001", the initial TUR is still being issued during the probe
sequence. I tried the usbdump command you suggested, and I can
clearly see where the timeouts are, and frames that begin with "USBC"
seem to contain a SCSI CDB. But there's a lot of other stuff in
between that I haven't been able to figure out, so I've attached a
sample. Hopefully it will help.
Hi,
All the USBC's are raw SCSI commands, which use the following layout:
/* Command Block Wrapper */
typedef struct {
uDWord dCBWSignature;
#define CBWSIGNATURE 0x43425355
uDWord dCBWTag;
uDWord dCBWDataTransferLength;
uByte bCBWFlags;
#define CBWFLAGS_OUT 0x00
#define CBWFLAGS_IN 0x80
uByte bCBWLUN;
uByte bCDBLength;
#define CBWCDBLENGTH 16
uByte CBWCDB[CBWCDBLENGTH];
} __packed umass_bbb_cbw_t;
We had a SoC to add support for the usbdump format to wireshark:
https://wiki.freebsd.org/SummerOfCode2017/usbdump-wireshark
You might find that useful.
My first suspicion is that your device is not fully USB class
compliant, and that's why it is STALLING and failing to recover.
--HPS
I checked on a Linux system, and the negotiation follows a slightly
different pattern, but as far as I can see, the biggest difference is
that Linux uses 6 byte Mode Sense commands instead of 10 byte. I wonder
if that's all that's making the device choke? How hard would it be to
change things to use 0x1a instead of 0x5a temporarily? Alternatively, I
could see if I can figure out how to issue arbitrary SCSI commands on
Linux. I used to have something for that purpose that worked on a
variety of platforms, but it's been ages since I needed it. In any
case, I'll attach the Linux wireshark trace. The negotiation seems to
begin at frame 2331.
Thanks,
Denver
___
freebsd-usb@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-usb
To unsubscribe, send any mail to "freebsd-usb-unsubscr...@freebsd.org"
Re: Timeouts during initial Mode Sense commands
Warner Losh wrote:
On Sun, Feb 2, 2020 at 12:32 PM Denver Hull <mailto:denv...@comcast.net>> wrote:
Hans Petter Selasky wrote:
> On 2019-12-20 13:54, Denver Hull wrote:
>> Hans Petter Selasky wrote:
>>> On 2019-12-19 01:11, Denver Hull wrote:
>>>> Hello,
>>>>
>>>> I have several different microcontroller boards that are
supposed
>>>> to appear as storage devices when plugged in. They work fine on
>>>> Linux systems, but on FreeBSD 11.3 and 12.1 they don't show
up at
>>>> all. Here's what dmesg shows for one of them:
>>>>
>>>> ugen1.3: at usbus1
>>>> umodem0 on uhub1
>>>> umodem0: on usbus1
>>>> umodem0: data interface 1, has no CM over data, has no break
>>>> umass3 on uhub1
>>>> umass3: on usbus1
>>>> umass3: SCSI over Bulk-Only; quirks = 0x
>>>> umass3:5:3: Attached to scbus5
>>>> uaudio0 on uhub1
>>>> uaudio0: on usbus1
>>>> uaudio0: No playback.
>>>> uaudio0: No recording.
>>>> uaudio0: MIDI sequencer.
>>>> uaudio0: No HID volume keys found.
>>>> ums2 on uhub1
>>>> ums2: on usbus1
>>>> ums2: 16 buttons and [XYZ] coordinates ID=2
>>>> (da3:umass-sim3:3:0:0): got CAM status 0x44
>>>> (da3:umass-sim3:3:0:0): fatal error, failed to attach to device
>>>> g_access(944): provider da3 has error 6 set
>>>> g_access(944): provider da3 has error 6 set
>>>> g_access(944): provider da3 has error 6 set
>>>> g_access(944): provider da3 has error 6 set
>>>> g_access(944): provider da3 has error 6 set
>>>>
>>>> There's a definite delay after the last ums message. I used
>>>> camcontrol debug in single user mode on a bare 12.1 system to
get a
>>>> little more information about what was happening. It looks
like the
>>>> initial Inquiry and Test Unit Ready commands succeed, but the
next
>>>> Mode Sense command times out, as well as all subsequent
commands.
>>>> There are several seconds of inactivity between retries, and
>>>> there's no sense data, so I'm assuming that indicates timeout.
>>>>
>>>> At this point I'm not sure how best to proceed to get these
devices
>>>> to work, so any help will be appreciated.
>>>>
>>>
>>> Did you try setting one or more quirks for these devices using
>>> usbconfig?
>>>
>>> UQ_MSC_NO_TEST_UNIT_READY
>>> UQ_MSC_NO_RS_CLEAR_UA
>>> UQ_MSC_NO_START_STOP
>>> UQ_MSC_NO_GETMAXLUN
>>> UQ_MSC_NO_INQUIRY
>>> UQ_MSC_NO_INQUIRY_EVPD
>>> UQ_MSC_NO_PREVENT_ALLOW
>>> UQ_MSC_NO_SYNC_CACHE
>>> UQ_MSC_SHUTTLE_INIT
>>> UQ_MSC_ALT_IFACE_1
>>> UQ_MSC_FLOPPY_SPEED
>>> UQ_MSC_IGNORE_RESIDUE
>>> UQ_MSC_WRONG_CSWSIG
>>> UQ_MSC_RBC_PAD_TO_12
>>> UQ_MSC_READ_CAP_OFFBY1
>>> UQ_MSC_FORCE_SHORT_INQ
>>>
>>> If you run "usbdump -i usbusX -f Y -s 65536 -vvv" you might
see the
>>> last failing SCSI command. X.Y are numbers after ugen for your
device.
>>>
>>> Likely your device has a software bug in its USB/SCSI
>>> implementation, which is quite common unfortunately.
>>>
>>> --HPS
>>>
>> After I sent the previous message I did try
>> UQ_MSC_NO_TEST_UNIT_READY. Although the system reports "quirks =
>> 0001", the initial TUR is still being issued during the probe
>> sequence. I tried the usbdump command you suggested, and I can
>> clearly see where the timeouts are, and frames that begin with
"USBC"
>> seem to contain a SCSI CDB. But there's a lot of other stuff in
>> between that I haven't been able to figure out, so I've attached a
>> sample. Hopefully it will help.
>>
>
> Hi,
>
> All the USBC's are raw SCSI commands, which use the following
layout:
>
>> /* Command Block Wrapper */
>> typedef struct {
>> uDWord dCBWSignature;
>> #define CBWSIGNATURE 0x43425355
>> uDWord dCBWTag;
>> uDWord dCBWDataTransferLength;
