Re: USB config SX lock deadlock
On 10/09/13 23:25, Daniel O'Connor wrote: On 09/10/2013, at 22:43, Hans Petter Selasky h...@bitfrost.no wrote: On 10/09/13 12:38, Daniel O'Connor wrote: On 09/10/2013, at 20:59, Hans Petter Selasky h...@bitfrost.no wrote: It is actually running r253505, sorry I should have mentioned that before. It isn't a serial device, although the driver is a thin wrapper around the usb_fifo code (which is very useful - thanks :) Does your application close the file handle when it gets a read/poll error? It might under some circumstances but not directly. It has 3 sub interfaces, if there is an error on one the the DAQ program will call abort() which would result in FDs being closed. However that sub interface does not use read/poll only ioctl. Hi, How do these IOCTLs work? Do you wakeup any sleepers at surprise detach? --HPS ___ 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: USB device configuration
It is allowed to set the configuration multiple times. Refer to USB
2.0 specification.
In what possible scenario would we want to set the configuration again? I
know USB 2.0 specification allows it. I have also tried to modify the code
and have sent SET_CONFIGURATION request to the device multiple times, and
device didn't report any error.
Or do you mean different configurations of a device, if a device supports
more that one configuration?
Is this making a difference for you?
I have scene a case in which we were unable to attach the umass driver to
the device but since USB_DEBUG was not enabled at that time so I was not
able to get more information out of it and being extremely intermittent in
nature, I am not able to reproduce it again. I am trying to figure out the
possible scenarios in which we might end up not attaching the driver to the
device. I believe if we are not able to select a configuration then we don't
attach the driver to the device.
In usb_unconfigure func:
udev-curr_config_no = USB_UNCONFIG_NO;
udev-curr_config_index = USB_UNCONFIG_INDEX
In usb_probe_and_attach func:
if (udev-curr_config_index == USB_UNCONFIG_INDEX) {
/* do nothing - no configuration has been set */
goto done;
}
From the console logs, it is clear that SET_ADDRESS went successfully, have
noticed that we have assigned a ugen name to the device and also request to
get the String descriptors(Product, Manufacturer etc) went successfully so
that make me believe that there might be an error in performing
SET_CONFIGURATION request. Do you have any other suggestions?
--
View this message in context:
http://freebsd.1045724.n5.nabble.com/USB-device-configuration-tp5850403p5850751.html
Sent from the freebsd-usb mailing list archive at Nabble.com.
___
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: USB config SX lock deadlock
On 10/10/2013, at 16:59, Hans Petter Selasky h...@bitfrost.no wrote: It might under some circumstances but not directly. It has 3 sub interfaces, if there is an error on one the the DAQ program will call abort() which would result in FDs being closed. However that sub interface does not use read/poll only ioctl. How do these IOCTLs work? They get turned into UT_READ_VENDOR_DEVICE requests in the driver. Do you wakeup any sleepers at surprise detach? The usb_fifo_* code handles all wakeups so I am not sure. Generally speaking the DAQ program sees these as IO errors and will then call abort() because the original code was for a PCI device and so it assumed the device could never disappear. -- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au The nice thing about standards is that there are so many of them to choose from. -- Andrew Tanenbaum GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C signature.asc Description: Message signed with OpenPGP using GPGMail
Re: USB config SX lock deadlock
On 10/10/13 09:38, Daniel O'Connor wrote:
On 10/10/2013, at 16:59, Hans Petter Selasky h...@bitfrost.no wrote:
It might under some circumstances but not directly.
It has 3 sub interfaces, if there is an error on one the the DAQ program will
call abort() which would result in FDs being closed.
However that sub interface does not use read/poll only ioctl.
How do these IOCTLs work?
They get turned into UT_READ_VENDOR_DEVICE requests in the driver.
Do you wakeup any sleepers at surprise detach?
Hi,
If you use synchronous USB control requests, then those should always
error out.
The usb_fifo_* code handles all wakeups so I am not sure.
The usb_fifo code only will only do refcounting. If you do USB control
requests, you should use the f_ioctl_post, callback, because the f_ioctl
callback does not protect against attach and detach or the enumeration
thread running.
err = (f-methods-f_ioctl) (f, cmd, addr, fflags);
DPRINTFN(2, f_ioctl cmd 0x%lx = %d\n, cmd, err);
if (err != ENOIOCTL)
goto done;
if (usb_usb_ref_device(cpd, refs)) {
err = ENXIO;
goto done;
}
err = (f-methods-f_ioctl_post) (f, cmd, addr, fflags);
DPRINTFN(2, f_ioctl_post cmd 0x%lx = %d\n, cmd, err);
--HPS
___
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: USB device configuration
Hi,
On 10/10/13 09:32, aseem.jolly wrote:
It is allowed to set the configuration multiple times. Refer to USB
2.0 specification.
In what possible scenario would we want to set the configuration again? I
know USB 2.0 specification allows it. I have also tried to modify the code
and have sent SET_CONFIGURATION request to the device multiple times, and
device didn't report any error.
Some devices have multiple configurations with different interfaces,
which the application selects depending on the use-case. Many devices
only have one configuration.
Or do you mean different configurations of a device, if a device supports
more that one configuration?
Is this making a difference for you?
I have scene a case in which we were unable to attach the umass driver to
the device but since USB_DEBUG was not enabled at that time so I was not
able to get more information out of it and being extremely intermittent in
nature, I am not able to reproduce it again. I am trying to figure out the
possible scenarios in which we might end up not attaching the driver to the
device. I believe if we are not able to select a configuration then we don't
attach the driver to the device.
In usb_unconfigure func:
udev-curr_config_no = USB_UNCONFIG_NO;
udev-curr_config_index = USB_UNCONFIG_INDEX
In usb_probe_and_attach func:
if (udev-curr_config_index == USB_UNCONFIG_INDEX) {
/* do nothing - no configuration has been set */
goto done;
}
From the console logs, it is clear that SET_ADDRESS went successfully, have
noticed that we have assigned a ugen name to the device and also request to
get the String descriptors(Product, Manufacturer etc) went successfully so
that make me believe that there might be an error in performing
SET_CONFIGURATION request. Do you have any other suggestions?
You can use usbdump to figure out exactly what went wrong with regard
to USB requests. That might get you a clearer picture of what's going on.
--HPS
___
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: USB config SX lock deadlock
On 10/10/2013, at 18:18, Hans Petter Selasky h...@bitfrost.no wrote: If you use synchronous USB control requests, then those should always error out. Yes it is synchronous (uses usbd_do_request_flags). The usb_fifo_* code handles all wakeups so I am not sure. The usb_fifo code only will only do refcounting. If you do USB control requests, you should use the f_ioctl_post, callback, because the f_ioctl callback does not protect against attach and detach or the enumeration thread running. Sorry, I misspoke earlier :( The usb_fifo code is only used for the RS485 and high speed data bus, the other (low speed configuration bus) is done using ioctl - usbd_do_request(UT_*_VENDOR_DEVICE). I will see about cranking up the debug level and trying to provoke a failure on the bench. -- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au The nice thing about standards is that there are so many of them to choose from. -- Andrew Tanenbaum GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C signature.asc Description: Message signed with OpenPGP using GPGMail
Re: USB device configuration
The device I am talking about has one configuration only. I was planning to
take bus trace or usbdump since I am not seeing it again so I don't think
that would help now.
On Thu, Oct 10, 2013 at 12:51 AM, Hans Petter Selasky h...@bitfrost.nowrote:
Hi,
On 10/10/13 09:32, aseem.jolly wrote:
It is allowed to set the configuration multiple times. Refer to USB
2.0 specification.
In what possible scenario would we want to set the configuration again? I
know USB 2.0 specification allows it. I have also tried to modify the code
and have sent SET_CONFIGURATION request to the device multiple times, and
device didn't report any error.
Some devices have multiple configurations with different interfaces, which
the application selects depending on the use-case. Many devices only have
one configuration.
Or do you mean different configurations of a device, if a device supports
more that one configuration?
Is this making a difference for you?
I have scene a case in which we were unable to attach the umass driver to
the device but since USB_DEBUG was not enabled at that time so I was not
able to get more information out of it and being extremely intermittent in
nature, I am not able to reproduce it again. I am trying to figure out the
possible scenarios in which we might end up not attaching the driver to
the
device. I believe if we are not able to select a configuration then we
don't
attach the driver to the device.
In usb_unconfigure func:
udev-curr_config_no = USB_UNCONFIG_NO;
udev-curr_config_index = USB_UNCONFIG_INDEX
In usb_probe_and_attach func:
if (udev-curr_config_index == USB_UNCONFIG_INDEX) {
/* do nothing - no configuration has been set */
goto done;
}
From the console logs, it is clear that SET_ADDRESS went successfully,
have
noticed that we have assigned a ugen name to the device and also request
to
get the String descriptors(Product, Manufacturer etc) went successfully so
that make me believe that there might be an error in performing
SET_CONFIGURATION request. Do you have any other suggestions?
You can use usbdump to figure out exactly what went wrong with regard to
USB requests. That might get you a clearer picture of what's going on.
--HPS
___
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: usb/182820: commit references a PR
The following reply was made to PR usb/182820; it has been noted by GNATS. From: dfil...@freebsd.org (dfilter service) To: bug-follo...@freebsd.org Cc: Subject: Re: usb/182820: commit references a PR Date: Thu, 10 Oct 2013 09:43:22 + (UTC) Author: hrs Date: Thu Oct 10 09:43:15 2013 New Revision: 256258 URL: http://svnweb.freebsd.org/changeset/base/256258 Log: Do not try to detach if the interface does not support IPv6. Tested by: hselasky PR: usb/182820 Approved by: re (glebius) Modified: head/sys/netinet6/in6_ifattach.c Modified: head/sys/netinet6/in6_ifattach.c == --- head/sys/netinet6/in6_ifattach.c Thu Oct 10 09:42:41 2013 (r256257) +++ head/sys/netinet6/in6_ifattach.c Thu Oct 10 09:43:15 2013 (r256258) @@ -809,6 +809,9 @@ in6_ifdetach(struct ifnet *ifp) struct sockaddr_in6 sin6; struct in6_multi_mship *imm; + if (ifp-if_afdata[AF_INET6] == NULL) + return; + /* remove neighbor management table */ nd6_purge(ifp); ___ svn-src-...@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to svn-src-all-unsubscr...@freebsd.org ___ 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: Using a C-Media multichannel USB DAC
On Thu, Oct 10, 2013 at 08:35:58AM +0200, Hans Petter Selasky wrote:
sysctl hw.usb.uaudio.default_channels=8
Thank you, I was not aware of this sysctl, it has the intended
effect.
The uaudio.c driver has support for talking directly to the USB HID
interface for USB audio devices (/dev/uhid0) if you need to do some
I think I will try the userland libusb way first as it may prove
handy to allow the user to dynamically change signals routing.
--
%!PS -- Bertrand Petit
/D{def}def/E{exch}D/G{get}D/I{2 div}D/U{dup}D/L{roll}D/Y{setgray}D/N{newpath}D
/O{N 0 0 moveto}D/P{pop}D/T{translate}D currentpagedevice/PageSize G U 0 G/w E
D 1 G /h E D w I h I T 0 Y 1 setlinewidth 0 1 2 { P 120 rotate 2 4 w U mul h U
mul add sqrt I 50 add {N 50 0 3 2 L 0 360 arc stroke}for}for/s{O true charpath
pathbbox exch 4 -1 L E sub I 3 1 L sub I} D /l(bp)D 0.94 Y /Helvetica findfont
22 scalefont setfont l s P(x)s exch P T O l show showpage
___
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
