Re: [linux-usb-devel] rx errors reported by usbnet
On Friday 25 May 2007, Alan Stern wrote: > On Fri, 25 May 2007, Yum Rayan wrote: > > > > ohci_hcd :00:04.0: urb c3a33e00 path 1 ep1in 6d16 cc 6 --> > > > > status -71 > > > > ohci_hcd :00:04.0: urb c7881cc0 path 2 ep1in 6d16 cc 6 --> > > > > status -71 You might consider preventing that diagnostic when "cc == TD_PIDCHECKFAIL" and an ISP1563 quirk applies ... of course it's only seen if you manually enable verbose diagnostics. > > We checked the USB cable and protocol on the wire and everything looks > > good. The USB device that is connected to the hosts looks fine well. > > > > Finally we see this in the NXP ISP1563_Errata_070417: > > > > "Afer receiving a continous series of NAKs, ranging from 150 ms to 500 > > ms, the ISP1563 will retun a condition code 06h (PID failure) in the > > general Transfer Descriptor (TD). This error causes the software to > > stall the endpoint" They must be thinking of MS-Windows or something ... this isn't a TD_CC_STALL, so Linux would never report a stall!! > > "The workaround is to provide a software patch. > > The HCD can be modified so that whenever a PID check failure occurs, > > the HCD will not inform the client driver. Instead it just resubmits > > the TD on its own and the transaction continues". > > > > Is there exisiting code that demonstrates how to resubmit a TD? The > > suggested workaround does not seem good design. Any ideas? > > There is no demonstration code for resubmitting a TD, as far as I know. > You'll have to try writing your own. It's probably made easier by the fact that, unless they managed to *really* break OHCI, the TD queue on the relevant endpoint is something like ED->HEAD + v TD0 .. TD1 .. (TD2/PIDCHECK) .. TD3 .. TD4 dummy ^ ED->TAIL -+ So all you "should" need to do is re-activate the TD and patch the ED. > You're right that the workaround doesn't seem like a good design. What > would happen when a real PID error occurs? Admittedly this is highly > unlikely. Both "unexpected PID" and "PID check failure" are reported as EPROTO, FWIW. It's kind of surprising they shipped the hardware with this kind of erratum. Long sequences of NAKs are pretty routine... There's already logic in usbnet to back off given the EPROTO errors, then restart ... you should have gotten 'rx throttle' message, at least if you enabled link diagnostics with ethtool. So I'd find out first why things seemed to "lock up" rather than continue functioning. Sure the misbehavior is triggered by that hardware bug, which as Alan noted would normally be rare. Once that's resolved, you can consider whether it's worthwhile adding a nasty workaround, to avoid triggering the throttle/reactivate logic. I suspect it shouldn't be worthwhile... - Dave - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] [PATCH] USB Core hub.c: prevent re-enumeration on HNP
On Friday 25 May 2007, Greg KH wrote: > > > > Ditto. Greg, it'd be nice to see this in 2.6.22 if possible; > > there's a bunch of recent work on OTG hardware, and it'd be > > nice if folk doing that work only had to carry around driver > > patches, not usbcore patches. > > Ok, care to send it to me with all of the signed-off-by:s ? Done (off list) ... - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] hub.c port power handling on over-current
On Friday 25 May 2007, Engelmayer Christian wrote:
> Hi all,
>
> If I am not mistaken the current policy is to leave port power
> enabled at all times during over-current situations and let
> the power provider handle current limitation.
More accurately: let the hub handle it. And ISTR that the
hub is supposed to automatically power off (or at least current
limit) ports observing overcurrent conditions.
Overcurrent has been a problem recently with EHCI; I'm not
entirely sure why. It'd be no surprise to find that there's
something the driver should do differently for some silicon.
In particular, we want root hubs to follow chapter 11 of the
USB spec ("hubs"). The hub driver in usbcore expects that.
But the details of that expectation have changed a lot over
the 2.6 cycle, and I suspect some root hubs have fallen a
bit behind ... not acting enough like a "real" hub.
> I experienced problems with the EHCI on an MPC8343E, which
> after some over-current situations no longer asserts the
> Connect Change Status Bit in the Port Status and Control Register,
> leading to the result that USB would be fully functional, but
> is no longer effectively serviced...
>
> The solution to this problem according to Freescale support
> would be to disable and re-enable port power after the over-current
> situation. Trying this with a hardware debugger gets us back in service.
Is this an erratum, or are they saying that's how they read
the EHCI spec? Does this EHCI report that it supports per-port
power switching? (Probe messages with USB_DEBUG enabled will
report that, as will current versions of "lsusb -v".)
I'd have to check, but I think that Linux won't currently turn
off per-port power unless the host controller reports that it
actually supports per-port power switching. And most EHCI
implementations don't report that in the hardware, so Linux
won't power it off ...
> As I am no big fan of work-arounds and rather new to the
> USB-subsystem, might I ask what would be an accaptable way
> to patch this behaviour?
One thing to try would be to make the root hub descriptor
report that it supports per-port power switching ... assuming
that the hardware says otherwise. ehci_hub_descriptor() is
the thing; or maybe HCS_PPC().
I'd have to look at usbcore's hub driver again to verify,
but I think that might be sufficient to change its behavior.
If not, you might also have to modify ehci_hub_status() to
power off ports when OCC is detected ... some silicon will
do that automatically, some won't, Linux could always do so.
In general what we'd like to have is one code path which
can work on all hardware. If you read the EHCI spec you'll
see it allows some implementation flexibility in this area;
if this isn't an erratum, I'd expect that what makes your
case work better would not hurt other EHCI implementations.
- Dave
-
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
___
linux-usb-devel@lists.sourceforge.net
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] [PATCH] USB Core hub.c: prevent re-enumeration on HNP
On Wed, May 23, 2007 at 08:27:38AM -0700, David Brownell wrote: > On Wednesday 23 May 2007, Alan Stern wrote: > > On Wed, 23 May 2007, Pandita, Vikram wrote: > > > > > New proposed patch based on your inputs: > > > > > > Patch is to prevent the OTG host of doing 3 times enumeration of device > > > when the Host suspends for HNP. The error code used in this case is > > > ENOTSUPP. > > > > > > Signed-off-by: Vikram Pandita <[EMAIL PROTECTED]> > > > --- > > > diff -purN -X ./dontdiff a/drivers/usb/core/hub.c c/drivers/usb/core/hub.c > > > --- a/drivers/usb/core/hub.c2007-05-13 14:24:43.0 +0530 > > > +++ c/drivers/usb/core/hub.c2007-05-23 11:58:40.0 +0530 > > > @@ -1361,7 +1361,7 @@ int usb_new_device(struct usb_device *ud > > > if (err < 0) > > > dev_dbg(&udev->dev, "HNP fail, %d\n", > > > err); > > > } > > > - err = -ENODEV; > > > + err = -ENOTSUPP; > > > goto fail; > > > } > > > #endif > > > @@ -2571,7 +2571,7 @@ loop: > > > ep0_reinit(udev); > > > release_address(udev); > > > usb_put_dev(udev); > > > - if (status == -ENOTCONN) > > > + if ((status == -ENOTCONN) || (status == -ENOTSUPP)) > > > break; > > > } > > > > This looks good. > > > > Acked-by: Alan Stern <[EMAIL PROTECTED]> > > Ditto. Greg, it'd be nice to see this in 2.6.22 if possible; > there's a bunch of recent work on OTG hardware, and it'd be > nice if folk doing that work only had to carry around driver > patches, not usbcore patches. Ok, care to send it to me with all of the signed-off-by:s ? thanks, greg k-h - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
[linux-usb-devel] [patch 2.6.22-rc3] usb serial gadget, sparse fixes
Fix a few serial gadget issues reported by the latest "sparse":
some functions should have been defined as static, not just
declared that way.
Signed-off-by: David Brownell <[EMAIL PROTECTED]>
---
drivers/usb/gadget/serial.c | 14 --
1 file changed, 8 insertions(+), 6 deletions(-)
--- h4.orig/drivers/usb/gadget/serial.c 2007-05-19 11:40:33.0 -0700
+++ h4/drivers/usb/gadget/serial.c 2007-05-25 19:19:35.0 -0700
@@ -2215,7 +2215,7 @@ static struct gs_buf *gs_buf_alloc(unsig
*
* Free the buffer and all associated memory.
*/
-void gs_buf_free(struct gs_buf *gb)
+static void gs_buf_free(struct gs_buf *gb)
{
if (gb) {
kfree(gb->buf_buf);
@@ -2228,7 +2228,7 @@ void gs_buf_free(struct gs_buf *gb)
*
* Clear out all data in the circular buffer.
*/
-void gs_buf_clear(struct gs_buf *gb)
+static void gs_buf_clear(struct gs_buf *gb)
{
if (gb != NULL)
gb->buf_get = gb->buf_put;
@@ -2241,7 +2241,7 @@ void gs_buf_clear(struct gs_buf *gb)
* Return the number of bytes of data available in the circular
* buffer.
*/
-unsigned int gs_buf_data_avail(struct gs_buf *gb)
+static unsigned int gs_buf_data_avail(struct gs_buf *gb)
{
if (gb != NULL)
return (gb->buf_size + gb->buf_put - gb->buf_get) %
gb->buf_size;
@@ -2255,7 +2255,7 @@ unsigned int gs_buf_data_avail(struct gs
* Return the number of bytes of space available in the circular
* buffer.
*/
-unsigned int gs_buf_space_avail(struct gs_buf *gb)
+static unsigned int gs_buf_space_avail(struct gs_buf *gb)
{
if (gb != NULL)
return (gb->buf_size + gb->buf_get - gb->buf_put - 1) %
gb->buf_size;
@@ -2271,7 +2271,8 @@ unsigned int gs_buf_space_avail(struct g
*
* Return the number of bytes copied.
*/
-unsigned int gs_buf_put(struct gs_buf *gb, const char *buf, unsigned int count)
+static unsigned int
+gs_buf_put(struct gs_buf *gb, const char *buf, unsigned int count)
{
unsigned int len;
@@ -2309,7 +2310,8 @@ unsigned int gs_buf_put(struct gs_buf *g
*
* Return the number of bytes copied.
*/
-unsigned int gs_buf_get(struct gs_buf *gb, char *buf, unsigned int count)
+static unsigned int
+gs_buf_get(struct gs_buf *gb, char *buf, unsigned int count)
{
unsigned int len;
-
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
___
linux-usb-devel@lists.sourceforge.net
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
[linux-usb-devel] [patch 2.6.22-rc3] usb gadgets avoid le{16, 32}_to_cpup()
It turns out that le16_to_cpup() and le32_to_cpup() aren't always safe
to call with pointers into packed structures, since those are inlined
functions and GCC may lose the "packed" attribute. So those references
can become unaligned kernel accesses, which are evil on some hardware.
This patch updates uses of those routines in the gadget stack. The
references into packed structures can just use leXX_to_cpu(*x), which
in most cases is more natural. Some other uses in RNDIS, mostly in
debug code, were wrong in the first place; those use get_unaligned().
Signed-off-by: David Brownell <[EMAIL PROTECTED]>
---
drivers/usb/gadget/epautoconf.c |2 +-
drivers/usb/gadget/inode.c |8
drivers/usb/gadget/net2280.c|6 +++---
drivers/usb/gadget/omap_udc.c |6 +++---
drivers/usb/gadget/rndis.c | 35 ++-
5 files changed, 33 insertions(+), 24 deletions(-)
--- h4.orig/drivers/usb/gadget/epautoconf.c 2007-03-21 02:49:25.0
-0700
+++ h4/drivers/usb/gadget/epautoconf.c 2007-05-25 18:42:38.0 -0700
@@ -132,7 +132,7 @@ ep_matches (
* where it's an output parameter representing the full speed limit.
* the usb spec fixes high speed bulk maxpacket at 512 bytes.
*/
- max = 0x7ff & le16_to_cpup (&desc->wMaxPacketSize);
+ max = 0x7ff & le16_to_cpu(desc->wMaxPacketSize);
switch (type) {
case USB_ENDPOINT_XFER_INT:
/* INT: limit 64 bytes full speed, 1024 high speed */
--- h4.orig/drivers/usb/gadget/inode.c 2007-03-21 02:49:27.0 -0700
+++ h4/drivers/usb/gadget/inode.c 2007-05-25 18:42:38.0 -0700
@@ -1369,12 +1369,12 @@ config_buf (struct dev_data *dev, u8 typ
hs = !hs;
if (hs) {
dev->req->buf = dev->hs_config;
- len = le16_to_cpup (&dev->hs_config->wTotalLength);
+ len = le16_to_cpu(dev->hs_config->wTotalLength);
} else
#endif
{
dev->req->buf = dev->config;
- len = le16_to_cpup (&dev->config->wTotalLength);
+ len = le16_to_cpu(dev->config->wTotalLength);
}
((u8 *)dev->req->buf) [1] = type;
return len;
@@ -1885,7 +1885,7 @@ dev_config (struct file *fd, const char
/* full or low speed config */
dev->config = (void *) kbuf;
- total = le16_to_cpup (&dev->config->wTotalLength);
+ total = le16_to_cpu(dev->config->wTotalLength);
if (!is_valid_config (dev->config) || total >= length)
goto fail;
kbuf += total;
@@ -1894,7 +1894,7 @@ dev_config (struct file *fd, const char
/* optional high speed config */
if (kbuf [1] == USB_DT_CONFIG) {
dev->hs_config = (void *) kbuf;
- total = le16_to_cpup (&dev->hs_config->wTotalLength);
+ total = le16_to_cpu(dev->hs_config->wTotalLength);
if (!is_valid_config (dev->hs_config) || total >= length)
goto fail;
kbuf += total;
--- h4.orig/drivers/usb/gadget/net2280.c2007-05-19 11:40:33.0
-0700
+++ h4/drivers/usb/gadget/net2280.c 2007-05-25 18:42:38.0 -0700
@@ -2440,9 +2440,9 @@ static void handle_stat0_irqs (struct ne
tmp = 0;
-#definew_value le16_to_cpup (&u.r.wValue)
-#definew_index le16_to_cpup (&u.r.wIndex)
-#definew_lengthle16_to_cpup (&u.r.wLength)
+#definew_value le16_to_cpu(u.r.wValue)
+#definew_index le16_to_cpu(u.r.wIndex)
+#definew_lengthle16_to_cpu(u.r.wLength)
/* ack the irq */
writel (1 << SETUP_PACKET_INTERRUPT, &dev->regs->irqstat0);
--- h4.orig/drivers/usb/gadget/omap_udc.c 2007-04-13 19:35:01.0
-0700
+++ h4/drivers/usb/gadget/omap_udc.c2007-05-25 18:42:38.0 -0700
@@ -1651,9 +1651,9 @@ static void ep0_irq(struct omap_udc *udc
UDC_EP_NUM_REG = 0;
} while (UDC_IRQ_SRC_REG & UDC_SETUP);
-#definew_value le16_to_cpup (&u.r.wValue)
-#definew_index le16_to_cpup (&u.r.wIndex)
-#definew_lengthle16_to_cpup (&u.r.wLength)
+#definew_value le16_to_cpu(u.r.wValue)
+#definew_index le16_to_cpu(u.r.wIndex)
+#definew_lengthle16_to_cpu(u.r.wLength)
/* Delegate almost all control requests to the gadget driver,
* except for a handful of ch9 status/feature requests that
--- h4.orig/drivers/usb/gadget/rndis.c 2007-03-21 02:49:27.0 -0700
+++ h4/drivers/usb/gadget/rndis.c 2007-05-25 18:42:38.0 -0700
@@ -186,10 +186,14 @@ gen_ndis_query_resp (int configNr, u32 O
DEBUG("query OID %08x value, len %d:\n", OID, buf_len);
for (i = 0; i < buf_len; i += 16) {
DEBUG
[linux-usb-devel] [PATCH] Fix OTG HNP for hub.c (USB OTG HNP (can you find any other appropriate TLAs?)
* Alan Stern <[EMAIL PROTECTED]> [070525 14:09]:
> On Fri, 25 May 2007, David Brownell wrote:
>
> > You omitted the "(except as noted in Section 3.8)", which says
> > that a second connector is allowed iff it's a Mini-A connector.
> > That's a trivial counter-example...
> >
> > But in any case, section 3 is only talking about connectors,
> > not links that may be used internally on a mainboard and which
> > would not be externally visible. The example I gave was for
> > an on-mainboard device. (I've seen similar products using
> > SDIO to access modem chips. Again, nothing visible to the end
> > users; just boards leveraging volume pricing for parts using
> > a wire-efficient I/O bus.)
>
> Okay. Then does this patch look good?
Here's an experimental related patch that makes two N800's work
with HNP, not yet verified with OPT. It also remove some of the
nestedness. The mdelay(4) should be redone though...
Regards,
Tony
>From 0417568cbc57d6683c197f756acf9fcc235e168a Mon Sep 17 00:00:00 2001
From: Tony Lindgren <[EMAIL PROTECTED]>
Date: Mon, 14 May 2007 18:14:36 -0700
Subject: [PATCH] USB: Fix OTG HNP for hub.c
This patch makes makes OTG Host Negotiation Protocol (HNP)
to behave.
Signed-off-by: Tony Lindgren <[EMAIL PROTECTED]>
diff --git a/drivers/usb/core/hub.c b/drivers/usb/core/hub.c
index caaa46f..3947449 100644
--- a/drivers/usb/core/hub.c
+++ b/drivers/usb/core/hub.c
@@ -1252,6 +1252,81 @@ static inline void show_string(struct usb_device *udev, char *id, char *string)
#ifdef CONFIG_USB_OTG
#include "otg_whitelist.h"
static int __usb_port_suspend(struct usb_device *, int port1);
+
+/*
+ * OTG-aware devices on OTG-capable root hubs may be able to use SRP,
+ * to wake us after we've powered off VBUS; and HNP, switching roles
+ * "host" to "peripheral". The OTG descriptor helps figure this out.
+ */
+static int usb_new_device_offer_hnp(struct usb_device *udev)
+{
+ struct usb_bus *bus = udev->bus;
+ unsigned port1 = udev->portnum;
+ struct usb_otg_descriptor *desc = 0;
+ interr;
+
+ if (udev->bus->is_b_host || !udev->config
+ || udev->parent != udev->bus->root_hub)
+ return 0;
+
+ /* Descriptor may appear anywhere in config */
+ err = __usb_get_extra_descriptor(udev->rawdescriptors[0],
+le16_to_cpu(udev->config[0].desc.wTotalLength),
+USB_DT_OTG, (void **) &desc);
+ if (err < 0)
+ return 0;
+
+ if (!(desc->bmAttributes & USB_OTG_HNP))
+ return 0;
+
+ dev_info(&udev->dev, "Dual-Role OTG device on %sHNP port\n",
+(port1 == bus->otg_port) ? "" : "non-");
+
+ /* Tell B-device if we support HNP */
+ if (port1 == bus->otg_port)
+ bus->b_hnp_enable = 1;
+ err = usb_control_msg(udev, usb_sndctrlpipe(udev, 0),
+ USB_REQ_SET_FEATURE, 0,
+ bus->b_hnp_enable ? USB_DEVICE_B_HNP_ENABLE
+ : USB_DEVICE_A_ALT_HNP_SUPPORT,
+ 0, NULL, 0, USB_CTRL_SET_TIMEOUT);
+ if (err < 0) {
+ /*
+ * OTG MESSAGE: report errors here, customize to match your
+ * product.
+ */
+ dev_err(&udev->dev, "can't set HNP mode; %d\n", err);
+ bus->b_hnp_enable = 0;
+ return 0;
+ }
+
+ /* If B-device wants to do HNP, it will do it after we suspend */
+ if (bus->b_hnp_enable) {
+ dev_err(&udev->dev, "trying HNP, suspending bus\n");
+ err = __usb_port_suspend(udev, udev->bus->otg_port);
+ if (err < 0) {
+ dev_err(&udev->dev, "suspend for HNP failed\n");
+ return -ENODEV;
+ }
+
+ /* TB_ASE0_BRST, minimum 3.125 ms */
+ mdelay(4);
+
+ /* Failed resume means B-device took over the bus with HNP */
+ err = usb_port_resume(udev);
+ if (err < 0) {
+ dev_err(&udev->dev, "HNP success\n");
+ return -ENODEV;
+ }
+ }
+
+ /* HNP failed. Reject B-devices not in our whitelist */
+ if (!is_targeted(udev))
+ return -ENODEV;
+
+ return 0;
+}
+
#endif
/**
@@ -1305,63 +1380,8 @@ int usb_new_device(struct usb_device *udev)
show_string(udev, "SerialNumber", udev->serial);
#ifdef CONFIG_USB_OTG
- /*
- * OTG-aware devices on OTG-capable root hubs may be able to use SRP,
- * to wake us after we've powered off VBUS; and HNP, switching roles
- * "host" to "peripheral". The OTG descriptor helps figure this out.
- */
- if (!udev->bus->is_b_host
- && udev->config
- && udev->parent == udev->bus->root_hub) {
- struct usb_otg_descriptor *desc = 0;
- struct usb_bus *bus = udev->bus;
-
- /* descriptor may appear anywhere in config */
- if (__usb_get_extra_descriptor (udev->rawdescriptors[0],
- le16_to_cpu(udev->config[0].desc.wTotalLength),
- USB_DT_OTG, (void **) &desc) == 0) {
- if (desc->bmAttributes & USB_OTG_HNP) {
-unsigned port1 = udev->portnum;
-
-dev_info(&udev->dev,
- "Dual-Role OTG device on %sHNP port\n",
- (port1 == bus->otg_port)
- ? "" : "non-");
-
-/* enable HNP before suspend, it's simpler */
-if (port1 == bus->otg_port)
- bus->b_hnp_enable = 1;
-err = usb_control_msg(udev,
- usb_sndctrlpipe(udev, 0),
- USB_REQ_SET_FEATURE, 0,
- bus->b_hnp_enable
- ? USB_DEVICE_B_HNP_ENABLE
- : USB_DEVICE_A_ALT_HNP_SUP
Re: [linux-usb-devel] [2/3] 2.6.22-rc2: known regressions v2
From: Chris Newport <[EMAIL PROTECTED]> Date: Fri, 25 May 2007 19:03:51 +0100 > Not really a Solaris feature. This is a feature of the Openboot PROM > which is also used by several other vendors. > The Openboot PROM knows how to write to disk. The same should > apply on Apple hardware and others which use the openboot > convention. This is totally unusable even if it weren't stupid, and as someone who loves OpenBoot I think it's very stupid. The reason it's unusable is that PowerPC already and sparc64 soon (in order to support LDOMs) totally drops the OBP firmware very soon after early kernel boot. We pull in the device tree and then say "see ya" to openboot. PowerPC does it because sharing the address space with openboot is next to impossible on that cpu, sparc64 will need to do it because dynamic-reconfiguration of cpus in an LDOM is too hard to do with openboot there. - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] [2/3] 2.6.22-rc2: known regressions v2
Sorry, I did not make myself clear. Linus Torvalds wrote: >On Fri, 25 May 2007, Chris Newport wrote: > > >>Maybe we should take a hint from Solaris. >> >> > >No. Solaris is shit. They make their decisions based on "we control the >hardware" kind of setup. > > Not really a Solaris feature. This is a feature of the Openboot PROM which is also used by several other vendors. The Openboot PROM knows how to write to disk. The same should apply on Apple hardware and others which use the openboot convention. If dumps are enabled (disabled by default in a file read at boot) the crash() function need only set a couple of registers and do a prom interrupt. At this point the kernel is no longer involved so broken drivers etc are not an issue. The cute bit is that the SunOS debug program can be called as debug $DUMPFILE and it takes you to the failure point just like a tracefile. Crashdumps should not be enabled by default, they can chew rather a lot of disk space making a crashdump.datetime file every time something breaks > >>If the kernel crashes Solaris dumps core to swap and sets a flag. >>At the next boot this image is copied to /var/adm/crashdump where >>it is preserved for future debugging. Obviously swap needs to be >>larger than core, but this is usually the case. >> >> > >(a) it's not necessarily the case at all on many systems > >(b) _most_ crashes that are real BUG()'s (rather than WARN_ON()'s) leave >the system in such a fragile state that trying to write to disk is the >_last_ thing you should do. > >Linux does the right thing: it tries to not make bugs fatal. >Generally, you should see an oops, and things continue. Or a >WARN_ON(), and things continue. But you should avoid the "the machine >is now dead" cases. > >(c) have you looked at the size of drivers lately? I'd argue that *most* >bugs by far happen in something driver-related, and most of our source >code is likely drivers. > >Writing to disk when the biggest problem is a driver to begin with >is INSANE. > >So the fact is, Solaris is crap, and to a large degree Solaris is crap >exactly _because_ it assumes that it runs in a "controlled environment". > >Yes, in a controlled environment, dumping the whole memory image to disk >may be the right thing to do. BUT: in a controlled environment, you'll >never get the kind of usage that Linux gets. Why do you think Linux (and >Windows, for that matter) took away a lot of the market from traditional >UNIX? > >Answer: the traditional UNIX hardware/control model doesn't _work_. People >want more flexibility, both on a hardware side and on a usage side. And >once you have the flexibility, the "dump everything to disk" is simply not >an option any more. > >Disk dumps etc are options at things like wall street. But look at the bug >reports, and ask yourself how many of them happen at Wall Street, and how >many of them would even be _relevant_ to somebody there? > >So forget about it. The whole model is totally broken. We need to make >bug-reports short and sweet, enough so that random people can >copy-and-paste them into an email or take a digital photo. Anything else >IS TOTALLY INSANE AND USELESS! > > Linus > > - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] [2/3] 2.6.22-rc2: known regressions v2
On Fri, 25 May 2007, Andrew Morton wrote: > > > > There is an additional factor - dumps contain data which variously is - > > > copyright third parties, protected by privacy laws, just personally > > > private, security sensitive (eg browser history) and so on. > > > > Yes. > > We're uninterested in pagecache and user memory and they should be omitted > from the image (making it enormously smaller too). The people who would use crash-dumps (big sensitive firms) don't trust you. And they'd be right not to trust you. You end up having a _lot_ of sensitive data even if you avoid user memory and page cache. The network buffers, the dentries, and just stale data that hasn't been overwritten. So if you end up having secure data on that machine, you should *never* send a dump to somebody you don't trust. For the financial companies (which are practically the only ones that would use dumps) there can even be legal reasons why they cannot do that! > That leaves security keys and perhaps filenames, and these could probably > be addressed. It leaves almost every single kernel allocation, and no, it cannot be addressed. How are you going to clear out the network packets that you have in memory? They're just kmalloc'ed. > > I'm sure we've had one or two crashdumps over the years that have actually > > clarified a bug. > > > > But I seriously doubt it is more than a handful. > > We've had a few more than that, but all the ones I recall actually came > from the kdump developers who were hitting other bugs and who just happened > to know how to drive the thing. Right, I don't dispute that some _developers_ might use dumping. I dispute that any user would practically ever use it. And even for developers, I suspect it's _so_ far down the list of things you do, that it's practically zero. > > But 99% of the time, the problem doesn't happen on a developer machine, > > and even if it does, 90% of the time you really just want the traceback > > and register info that you get out of an oops. > > Often we don't even get that: "I was in X and it didn't hit the logs". Yes. > You can learn a hell of a lot by really carefully picking through kernel > memory with gdb. .. but you can learn equally much with other methods that do *not* involve the pain and suffering that is a kernel dump. Setting up netconsole or the firewire tools is much easier. The firewire thing in particular is nice, because it doesn't actually rely on the target having to even know about it (other than enabling the "remote DMA access" thing once on bootup). If you've ever picked through a kernel dump after-the-fact, I just bet you could have done equally well with firewire, and it would have had _zero_ impact on your kernel image. Now, contrast that with kdump, and ask yourself: which one do you think is worth concentrating effort on? - kdump: lots of code and maintenance effort, doesn't work if the CPU locks up, requires a lot of learning to go through the dump. - firewire: zero code, no maintenance effort, works even if the CPU locks up. Still does require the same learning to go through the end result. Which one wins? I know which one I'll push. Linus - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] [2/3] 2.6.22-rc2: known regressions v2
On Fri, May 25, 2007 at 10:37:14AM -0700, Andrew Morton wrote: > Often we don't even get that: "I was in X and it didn't hit the logs". Thats mostly solved by fixing the Oops and framebuffer code to co-operate and is a different problem Alan - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] [2/3] 2.6.22-rc2: known regressions v2
On Fri, 25 May 2007 10:19:52 -0700 (PDT) Linus Torvalds <[EMAIL PROTECTED]> wrote: > > > On Fri, 25 May 2007, Alan Cox wrote: > > > > There is an additional factor - dumps contain data which variously is - > > copyright third parties, protected by privacy laws, just personally > > private, security sensitive (eg browser history) and so on. > > Yes. We're uninterested in pagecache and user memory and they should be omitted from the image (making it enormously smaller too). That leaves security keys and perhaps filenames, and these could probably be addressed. > I'm sure we've had one or two crashdumps over the years that have actually > clarified a bug. > > But I seriously doubt it is more than a handful. We've had a few more than that, but all the ones I recall actually came from the kdump developers who were hitting other bugs and who just happened to know how to drive the thing. > > Diskdump (and even more so netdump) are useful in the hands of a > > developer crashing their own box just like kgdb, but not in the the > > normal and rational end user response of "its broken, hit reset" > > Amen, brother. > > Even for developers, I suspect a _lot_ of people end up doing "ok, let's > bisect this" or some other method to narrow it down to a specific case, > and then staring at the source code once they get to that point. > > At least I hope so. Even in user space, you should generally use gdb to > get a traceback and perhaps variable information, and then go look at the > source code. > > Yes, dumps can (in theory) be useful for one-off issues, but I doubt many > people have ever been able to get anything much more out of them than from > a kernel "oops" message. > > For developers, I can heartily recommend the firewire-based remote debug > facilities that the PowerPC people use. I've used it once or twice, and it > is fairly simple and much better than a full dump (adn it works even when > the CPU is totally locked up, which is the best reason for using it). > > But 99% of the time, the problem doesn't happen on a developer machine, > and even if it does, 90% of the time you really just want the traceback > and register info that you get out of an oops. > Often we don't even get that: "I was in X and it didn't hit the logs". You can learn a hell of a lot by really carefully picking through kernel memory with gdb. - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] [2/3] 2.6.22-rc2: known regressions v2
On Fri, 25 May 2007, Chuck Ebbert wrote: > > Windows can dump memory to the swap file on crash. Default is a "minidump" > IIRC but you can set it to dump all memory (or none.) And Linux can too. And exactly as with Windows, nobody should ever use it. It's a *developer* thing. It's not a user debug facility. And even developers are not all that likely to use it. Linus - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] [2/3] 2.6.22-rc2: known regressions v2
On Fri, 25 May 2007, Alan Cox wrote: > > There is an additional factor - dumps contain data which variously is - > copyright third parties, protected by privacy laws, just personally > private, security sensitive (eg browser history) and so on. Yes. I'm sure we've had one or two crashdumps over the years that have actually clarified a bug. But I seriously doubt it is more than a handful. > Diskdump (and even more so netdump) are useful in the hands of a > developer crashing their own box just like kgdb, but not in the the > normal and rational end user response of "its broken, hit reset" Amen, brother. Even for developers, I suspect a _lot_ of people end up doing "ok, let's bisect this" or some other method to narrow it down to a specific case, and then staring at the source code once they get to that point. At least I hope so. Even in user space, you should generally use gdb to get a traceback and perhaps variable information, and then go look at the source code. Yes, dumps can (in theory) be useful for one-off issues, but I doubt many people have ever been able to get anything much more out of them than from a kernel "oops" message. For developers, I can heartily recommend the firewire-based remote debug facilities that the PowerPC people use. I've used it once or twice, and it is fairly simple and much better than a full dump (adn it works even when the CPU is totally locked up, which is the best reason for using it). But 99% of the time, the problem doesn't happen on a developer machine, and even if it does, 90% of the time you really just want the traceback and register info that you get out of an oops. Linus - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] [2/3] 2.6.22-rc2: known regressions v2
> Disk dumps etc are options at things like wall street. But look at the bug > reports, and ask yourself how many of them happen at Wall Street, and how > many of them would even be _relevant_ to somebody there? There is an additional factor - dumps contain data which variously is - copyright third parties, protected by privacy laws, just personally private, security sensitive (eg browser history) and so on. The only reasons you can get dumps back in the hands of vendors is because there are strong formal agreements controlling where they go and what is done with them. Diskdump (and even more so netdump) are useful in the hands of a developer crashing their own box just like kgdb, but not in the the normal and rational end user response of "its broken, hit reset" Alan - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] [2/3] 2.6.22-rc2: known regressions v2
On Fri, 25 May 2007, Chris Newport wrote: > > Maybe we should take a hint from Solaris. No. Solaris is shit. They make their decisions based on "we control the hardware" kind of setup. > If the kernel crashes Solaris dumps core to swap and sets a flag. > At the next boot this image is copied to /var/adm/crashdump where > it is preserved for future debugging. Obviously swap needs to be > larger than core, but this is usually the case. (a) it's not necessarily the case at all on many systems (b) _most_ crashes that are real BUG()'s (rather than WARN_ON()'s) leave the system in such a fragile state that trying to write to disk is the _last_ thing you should do. Linux does the right thing: it tries to not make bugs fatal. Generally, you should see an oops, and things continue. Or a WARN_ON(), and things continue. But you should avoid the "the machine is now dead" cases. (c) have you looked at the size of drivers lately? I'd argue that *most* bugs by far happen in something driver-related, and most of our source code is likely drivers. Writing to disk when the biggest problem is a driver to begin with is INSANE. So the fact is, Solaris is crap, and to a large degree Solaris is crap exactly _because_ it assumes that it runs in a "controlled environment". Yes, in a controlled environment, dumping the whole memory image to disk may be the right thing to do. BUT: in a controlled environment, you'll never get the kind of usage that Linux gets. Why do you think Linux (and Windows, for that matter) took away a lot of the market from traditional UNIX? Answer: the traditional UNIX hardware/control model doesn't _work_. People want more flexibility, both on a hardware side and on a usage side. And once you have the flexibility, the "dump everything to disk" is simply not an option any more. Disk dumps etc are options at things like wall street. But look at the bug reports, and ask yourself how many of them happen at Wall Street, and how many of them would even be _relevant_ to somebody there? So forget about it. The whole model is totally broken. We need to make bug-reports short and sweet, enough so that random people can copy-and-paste them into an email or take a digital photo. Anything else IS TOTALLY INSANE AND USELESS! Linus - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] [2/3] 2.6.22-rc2: known regressions v2
On Fri, 25 May 2007, Andrew Morton wrote: > the image". But we're not - kernel developers don't know how to turn the > thing on in $RANDOM_DISTRO, testers have no experience with the feature > and kernel developers don't have experience handling the crash images. Well, we for instance have problems with huge crash dumps. Its even a challenge if the machine has only a few gigabytes of main memory. > And I'm not sure that the (required) "don't dump user memory and pagecache" > feature has been implemented yet? A colleague of mine is still working to get it to work just right on IA64. He does it full time. sigh. Jay what is the status on that? - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] [2/3] 2.6.22-rc2: known regressions v2
On Fri, 25 May 2007 14:34:56 +0200 Ingo Molnar <[EMAIL PROTECTED]> wrote: > * Chris Newport <[EMAIL PROTECTED]> wrote: > > > There is a fundamental problem in getting a decent log to debug a > > crashed kernel. Maybe we should take a hint from Solaris. If the > > kernel crashes Solaris dumps core to swap and sets a flag. At the next > > boot this image is copied to /var/adm/crashdump where it is preserved > > for future debugging. Obviously swap needs to be larger than core, but > > this is usually the case. > > we've got kdump, but it's not usually enabled by default by distros. Isn't that awful? By now we should be in the situation where if a tester is hitting a kernel crash we can say to them "please turn on crashdumps and send me the image". But we're not - kernel developers don't know how to turn the thing on in $RANDOM_DISTRO, testers have no experience with the feature and kernel developers don't have experience handling the crash images. And I'm not sure that the (required) "don't dump user memory and pagecache" feature has been implemented yet? It'd be in our interests to push all this along a bit. - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] [2/3] 2.6.22-rc2: known regressions v2
On Fri, 25 May 2007, Stefan Richter wrote: > Ingo Molnar wrote: > > i was adding WARN_ON()s that werent true 'warnings' but 'bugs'. > > IME, the trace dump in the kernel log looks scary enough to be > eventually reported, even if prefixed with "WARNING:". Oh, absolutely. It will stand out like a sore thumb. In fact, I think WARNING: stands out more than BUG:, if only because it's longer! Linus - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] [2/3] 2.6.22-rc2: known regressions v2
Chris Newport wrote: > There is a fundamental problem in getting a decent log to debug a > crashed kernel. If the test machine and a 2nd machine have FireWire ports, it's possible to get the kernel log and more via FireWire, unless the machine rebooted immediately or the PCI bus locked up. The program 'firescope' and the raw1394 driver is needed on the 2nd machine; the test machine has to have ohci1394 loaded. -- Stefan Richter -=-=-=== -=-= ==--= http://arcgraph.de/sr/ - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] [2/3] 2.6.22-rc2: known regressions v2
Ingo Molnar wrote: >A BUG_ON() has a (much) lower likelyhood of being reported back - for >most users it is a "X just hung hard, there was nothing in the syslog, i >had to switch back to the older kernel" experience, and they do not have >a serial console to hook up (newer hardware often doesnt even have a >serial port). With the WARN_ON()s we have a _chance_ that despite the >seriousness of the bug, the message makes it to the syslog, until the >system comes to a screeching halt due to side-effects of the bug. > >in that sense i am part of the problem: i was adding WARN_ON()s that >werent true 'warnings' but 'bugs'. So i'd very much like to fix that >problem, but i'd also like to solve the (very serious and existing) >problem of BUG_ON()s making it less likely to get bugs reported back. > > > There is a fundamental problem in getting a decent log to debug a crashed kernel. Maybe we should take a hint from Solaris. If the kernel crashes Solaris dumps core to swap and sets a flag. At the next boot this image is copied to /var/adm/crashdump where it is preserved for future debugging. Obviously swap needs to be larger than core, but this is usually the case. On Sun machines this is fairly easy because the dump can be performed by the OBP, on other architectures it may be more difficult to still have enough working kernel to achieve the dump after a kernel panic. Just a thought ... - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] [2/3] 2.6.22-rc2: known regressions v2
* Chris Newport <[EMAIL PROTECTED]> wrote: > There is a fundamental problem in getting a decent log to debug a > crashed kernel. Maybe we should take a hint from Solaris. If the > kernel crashes Solaris dumps core to swap and sets a flag. At the next > boot this image is copied to /var/adm/crashdump where it is preserved > for future debugging. Obviously swap needs to be larger than core, but > this is usually the case. we've got kdump, but it's not usually enabled by default by distros. Ingo - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] [2/3] 2.6.22-rc2: known regressions v2
Ingo Molnar wrote: > i was adding WARN_ON()s that werent true 'warnings' but 'bugs'. IME, the trace dump in the kernel log looks scary enough to be eventually reported, even if prefixed with "WARNING:". -- Stefan Richter -=-=-=== -=-= ==--= http://arcgraph.de/sr/ - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] [2/3] 2.6.22-rc2: known regressions v2
* Linus Torvalds <[EMAIL PROTECTED]> wrote: > > i very much agree that this kmalloc_index() one shouldnt be called a > > "BUG: ", but if you look at the majority of WARN_ON() instances they > > are checks for clear, serious kernel bugs. > > I _still_ disagree. > > There's a huge difference between "You killed my father, prepare to > die", and "Btw, I didn't like that, but I'll just continue". yeah ... > And that's the difference between BUG_ON() and WARN_ON(). how about this solution: make WARN_ON() a "WARNING: " like you suggested (i still agree with that in principle), but also solve the additional problem i'm trying to outline: make BUG_ON() _not_ crash the box [only if the user asks for a crash to happen in such circumstances - this can be a sysctl.]. Then i can change the majority of the current WARN_ON()s to BUG_ON()s. Most of the WARN_ON()s i personally add (and most of the WARN_ON()s i see others adding) are not WARN_ON()s because "i didnt like that and i'll just continue", they are WARN_ON() because i want _actual feedback from users_. A BUG_ON() has a (much) lower likelyhood of being reported back - for most users it is a "X just hung hard, there was nothing in the syslog, i had to switch back to the older kernel" experience, and they do not have a serial console to hook up (newer hardware often doesnt even have a serial port). With the WARN_ON()s we have a _chance_ that despite the seriousness of the bug, the message makes it to the syslog, until the system comes to a screeching halt due to side-effects of the bug. in that sense i am part of the problem: i was adding WARN_ON()s that werent true 'warnings' but 'bugs'. So i'd very much like to fix that problem, but i'd also like to solve the (very serious and existing) problem of BUG_ON()s making it less likely to get bugs reported back. Ingo - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] [2/3] 2.6.22-rc2: known regressions v2
Linus Torvalds wrote: > Doing it in the Makefile would make more sense, since I have to edit that > file anyway to change -rc5 to -rc6. Tangent: you should also change NAME when you do so :) - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
[linux-usb-devel] Please reactivate your Yahoo! Groups email address
Dear Yahoo! Groups member, You belong to one or more email groups provided by Yahoo! Groups (groups.yahoo.com). Recently, messages sent to you from Yahoo! Groups have been returned to us as undeliverable. As a result, we have temporarily turned off message delivery to this email address. If you are reading this message, the delivery problem appears to be fixed. To start receiving your groups messages by email again and turn your account back on, please visit: http://groups.yahoo.com/unbounce?adj=232689933,41657&p=1180129206 (You can also copy and paste this link into your browser, and hit the 'Return' key.) Once you reactivate your Yahoo! Groups account by clicking the link above, you will receive messages from your group(s) again. Tip: You can read messages you might have missed while delivery was turned off by visiting your groups here: http://groups.yahoo.com/mygroups Thank you for using Yahoo! Groups! Yahoo! Groups Customer Care Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/ - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] [2.6.22-rc1-mm1] ehci-hcd - BUG: scheduling while atomic: rmmod/0x00000001/4568
On Fri, 25 May 2007 14:40:05 -0700 Greg KH <[EMAIL PROTECTED]> wrote: > On Mon, May 21, 2007 at 11:44:37AM +0900, Mattia Dongili wrote: > > Hello, > > > > with gregkh-usb-usb-ehci-cpufreq-fix.patch removing ehci-hcd causes the > > following BUG: > > Thanks for letting me know. > > Stuart, any help here? pretty obvious. cpufreq_unregister_notifier() sleeps, and that patch causes it to be called under spinlock. Something like this... --- a/drivers/usb/host/ehci-hcd.c~fix-gregkh-usb-usb-ehci-cpufreq-fix +++ a/drivers/usb/host/ehci-hcd.c @@ -452,14 +452,14 @@ static void ehci_stop (struct usb_hcd *h if (HC_IS_RUNNING (hcd->state)) ehci_quiesce (ehci); -#ifdef CONFIG_CPU_FREQ - cpufreq_unregister_notifier(&ehci->cpufreq_transition, - CPUFREQ_TRANSITION_NOTIFIER); -#endif ehci_reset (ehci); ehci_writel(ehci, 0, &ehci->regs->intr_enable); spin_unlock_irq(&ehci->lock); +#ifdef CONFIG_CPU_FREQ + cpufreq_unregister_notifier(&ehci->cpufreq_transition, + CPUFREQ_TRANSITION_NOTIFIER); +#endif /* let companion controllers work when we aren't */ ehci_writel(ehci, 0, &ehci->regs->configured_flag); _ - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] [2.6.22-rc1-mm1] ehci-hcd - BUG: scheduling while atomic: rmmod/0x00000001/4568
On Mon, May 21, 2007 at 11:44:37AM +0900, Mattia Dongili wrote:
> Hello,
>
> with gregkh-usb-usb-ehci-cpufreq-fix.patch removing ehci-hcd causes the
> following BUG:
Thanks for letting me know.
Stuart, any help here?
thanks,
greg k-h
> [ 459.800033] BUG: scheduling while atomic: rmmod/0x0001/4568
> [ 459.800045] [] dump_trace+0x63/0x1ec
> [ 459.800055] [] show_trace_log_lvl+0x1a/0x30
> [ 459.800066] [] show_trace+0x12/0x14
> [ 459.800099] [] dump_stack+0x16/0x18
> [ 459.800135] [] __sched_text_start+0x56/0x7db
> [ 459.800142] [] wait_for_completion+0x65/0x9b
> [ 459.800147] [] synchronize_rcu+0x2d/0x33
> [ 459.800154] [] synchronize_srcu+0x23/0x5f
> [ 459.800160] [] srcu_notifier_chain_unregister+0x43/0x4d
> [ 459.800185] [] cpufreq_unregister_notifier+0x22/0x32
> [ 459.800203] [] ehci_stop+0x4f/0xb7 [ehci_hcd]
> [ 459.800248] [] usb_remove_hcd+0x97/0xd7 [usbcore]
> [ 459.800280] [] usb_hcd_pci_remove+0x18/0x6a [usbcore]
> [ 459.800317] [] pci_device_remove+0x1c/0x3d
> [ 459.800324] [] __device_release_driver+0x74/0x90
> [ 459.800332] [] driver_detach+0x81/0xc2
> [ 459.800337] [] bus_remove_driver+0x5d/0x7c
> [ 459.800342] [] driver_unregister+0xb/0xd
> [ 459.800347] [] pci_unregister_driver+0x13/0x65
> [ 459.800351] [] ehci_hcd_cleanup+0x10/0x12 [ehci_hcd]
> [ 459.800360] [] sys_delete_module+0x187/0x1ae
> [ 459.800367] [] sysenter_past_esp+0x5f/0x85
> [ 459.800373] [] 0xe410
> [ 459.800384] ===
>
> static void ehci_stop (struct usb_hcd *hcd)
> {
> ...
> spin_lock_irq(&ehci->lock);
> if (HC_IS_RUNNING (hcd->state))
> ehci_quiesce (ehci);
>
> #ifdef CONFIG_CPU_FREQ
> cpufreq_unregister_notifier(&ehci->cpufreq_transition,
> CPUFREQ_TRANSITION_NOTIFIER);
> #endif
>
> --
> mattia
> :wq!
-
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
___
linux-usb-devel@lists.sourceforge.net
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] crash for ftdi_sio
Am Freitag, 25. Mai 2007 16:11 schrieb Alan Stern: > On Fri, 25 May 2007, Sam Liddicott wrote: > > > I removed the USB keyboard and mouse to make things simpler. > > > > Still no joy, not even with any_ports_active returning 1 (and printk > > added there to be sure). > > > > Looks like a usbmon trace is needed; I'll get that to you as soon as the > > kernel rebuilds, > > This proves quite definitely that the auto-stop mechanism is not > related to the disconnection. Yes. Regards Oliver - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] USB OTG HNP (can you find any other appropriate TLAs?)
On Fri, 25 May 2007, David Brownell wrote:
> You omitted the "(except as noted in Section 3.8)", which says
> that a second connector is allowed iff it's a Mini-A connector.
> That's a trivial counter-example...
>
> But in any case, section 3 is only talking about connectors,
> not links that may be used internally on a mainboard and which
> would not be externally visible. The example I gave was for
> an on-mainboard device. (I've seen similar products using
> SDIO to access modem chips. Again, nothing visible to the end
> users; just boards leveraging volume pricing for parts using
> a wire-efficient I/O bus.)
Okay. Then does this patch look good?
Alan Stern
Index: usb-2.6/drivers/usb/core/hub.c
===
--- usb-2.6.orig/drivers/usb/core/hub.c
+++ usb-2.6/drivers/usb/core/hub.c
@@ -1334,7 +1334,6 @@ static void show_string(struct usb_devic
#ifdef CONFIG_USB_OTG
#include "otg_whitelist.h"
-static int __usb_port_suspend(struct usb_device *, int port1);
#endif
/**
@@ -1443,7 +1442,7 @@ int usb_new_device(struct usb_device *ud
* (Includes HNP test device.)
*/
if (udev->bus->b_hnp_enable || udev->bus->is_b_host) {
- err = __usb_port_suspend(udev, udev->bus->otg_port);
+ err = usb_port_suspend(udev);
if (err < 0)
dev_dbg(&udev->dev, "HNP fail, %d\n", err);
}
@@ -1687,6 +1686,23 @@ static int hub_port_suspend(struct usb_h
}
/*
+ * usb_port_suspend - suspend a usb device's upstream port
+ * @udev: device that's no longer in active use
+ * Context: must be able to sleep; device not locked; pm locks held
+ *
+ * Suspends a USB device that isn't in active use, conserving power.
+ * Devices may wake out of a suspend, if anything important happens,
+ * using the remote wakeup mechanism. They may also be taken out of
+ * suspend by the host, using usb_port_resume(). It's also routine
+ * to disconnect devices while they are suspended.
+ *
+ * This only affects the USB hardware for a device; its interfaces
+ * (and, for hubs, child devices) must already have been suspended.
+ *
+ * Suspending OTG devices may trigger HNP, if that's been enabled
+ * between a pair of dual-role devices. That will change roles, such
+ * as from A-Host to A-Peripheral or from B-Host back to B-Peripheral.
+ *
* Devices on USB hub ports have only one "suspend" state, corresponding
* to ACPI D2, "may cause the device to lose some context".
* State transitions include:
@@ -1703,21 +1719,19 @@ static int hub_port_suspend(struct usb_h
* If CONFIG_USB_SUSPEND isn't enabled, devices only really suspend when
* the root hub for their bus goes into global suspend ... so we don't
* (falsely) update the device power state to say it suspended.
+ *
+ * Returns 0 on success, else negative errno.
*/
-static int __usb_port_suspend (struct usb_device *udev, int port1)
+int usb_port_suspend(struct usb_device *udev)
{
int status = 0;
- /* caller owns the udev device lock */
- if (port1 < 0)
- return port1;
-
/* we change the device's upstream USB link,
* but root hubs have no upstream USB link.
*/
if (udev->parent)
- status = hub_port_suspend(hdev_to_hub(udev->parent), port1,
- udev);
+ status = hub_port_suspend(hdev_to_hub(udev->parent),
+ udev->portnum, udev);
else {
dev_dbg(&udev->dev, "usb %ssuspend\n",
udev->auto_pm ? "auto-" : "");
@@ -1727,31 +1741,6 @@ static int __usb_port_suspend (struct us
}
/*
- * usb_port_suspend - suspend a usb device's upstream port
- * @udev: device that's no longer in active use
- * Context: must be able to sleep; device not locked; pm locks held
- *
- * Suspends a USB device that isn't in active use, conserving power.
- * Devices may wake out of a suspend, if anything important happens,
- * using the remote wakeup mechanism. They may also be taken out of
- * suspend by the host, using usb_port_resume(). It's also routine
- * to disconnect devices while they are suspended.
- *
- * This only affects the USB hardware for a device; its interfaces
- * (and, for hubs, child devices) must already have been suspended.
- *
- * Suspending OTG devices may trigger HNP, if that's been enabled
- * between a pair of dual-role devices. That will change roles, such
- * as from A-Host to A-Peripheral or from B-Host back to B-Peripheral.
- *
- * Returns 0 on success, else negative errno.
- */
-int usb_port_suspend(struct usb_device *udev)
-{
- return __usb_port_suspend(udev, udev->portnum);
-}
-
-/*
* If the USB "suspend" state is in use (rather than "global suspend"),
* many devices will be individually taken out of suspend state using
* special" resum
[linux-usb-devel] No usb port on the docking station after docking
Hi, I have IBM ThinkPad A21m notebook and ThinkPad Dock. Docking working, but I have this problem: I run ThinkPad battery powered without dock. I connect ThinkPad to AC powered dock. I get ACPI debug message about docking. I enable slot: echo 1 > /sys/bus/pci/slots/1/power - this working. But no change on usb ports at the dock (lsusb - no info). Howto debug this ? There are no USB debug messages about changes - kernel compiled with USB debugging. Is problem - ACPI related - Any magick on the TI docking bridge - USB related problem ? Howto debug this ? USB port working without problem, if ThinkPad connected to docking station. Info: Bugreport to kernel: http://bugme.osdl.org/show_bug.cgi?id=8449 DSDT table http://acpi.sourceforge.net/dsdt/view.php?id=689 Record in usb devices database: http://www.qbik.ch/usb/devices/showdev.php?id=3706 I am using latest Linus git. I am ready for testing. Sorry for my bad english. Many thanks Pavel Kysilka programmer http://www.bsys.cz/ Information from NOD32 This message was checked by NOD32 Antivirus System for Linux Mail Servers. http://www.eset.com - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] rx errors reported by usbnet
On Fri, 25 May 2007, Yum Rayan wrote: > We checked the USB cable and protocol on the wire and everything looks > good. The USB device that is connected to the hosts looks fine well. > > Finally we see this in the NXP ISP1563_Errata_070417: > > "Afer receiving a continous series of NAKs, ranging from 150 ms to 500 > ms, the ISP1563 will retun a condition code 06h (PID failure) in the > general Transfer Descriptor (TD). This error causes the software to > stall the endpoint" "The workaround is to provide a software patch. > The HCD can be modified so that whenever a PID check failure occurs, > the HCD will not inform the client driver. Instead it just resubmits > the TD on its own and the transaction continues". > > Is there exisiting code that demonstrates how to resubmit a TD? The > suggested workaround does not seem good design. Any ideas? There is no demonstration code for resubmitting a TD, as far as I know. You'll have to try writing your own. You're right that the workaround doesn't seem like a good design. What would happen when a real PID error occurs? Admittedly this is highly unlikely. Alan Stern - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] issue detecting USB at boot
On Mon, May 14, 2007 at 03:26:53PM -0500, Kumar Gala wrote: > I'm seeing the following error message when I have a wireless usb ethernet > adapter plugged into an embedded PPC SoC. If I plug the adapter in after > the SoC has booted the device is detected w/o any issue. Which makes me > thing that there is some initialization timing issue. > > Any suggestions on what to poke/look/dbg at would be helpful. I've seen this before for some odd host controller interactions with low voltage issues. The host controller doesn't detect the device is connected for some reason due to an electrical issue, nothing that the kernel can do about this. You might want to check the power levels on the board... good luck, greg k-h - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] rx errors reported by usbnet
> > I have a bunch of USB devices configured for ethernet over USB > > connected to my machine. The host is running a 2.6.16 based kernel and > > I notice that rx errors reported via /proc/net/dev keep increasing > > infinitely. Initially the device responds without any problems, but at > > some random time, eventually the device and USB subsystem seem to lock > > up, i.e. commands like lsusb begin to fail. > > > > After some debug statements, I see that the RX errors are due to -71 > > EPROTO errors. Any help appreciated in understanding what is happening > > here. Here are the related messages (the messages keep repeating): > > > > ohci_hcd :00:04.0: urb c7881c60 path 2 ep1in 6d16 cc 6 --> status > > -71 > > ohci_hcd :00:04.0: urb c3a33ce0 path 2 ep1in 6d16 cc 6 --> status > > -71 > > ohci_hcd :00:04.0: urb c3a33e00 path 1 ep1in 6d16 cc 6 --> status > > -71 > > ohci_hcd :00:04.0: urb c7881cc0 path 2 ep1in 6d16 cc 6 --> status > > -71 > > These error codes indicate low-level USB communication problems. > There may be something wrong with the USB cable, or the device's USB > interface may have stopped running. We checked the USB cable and protocol on the wire and everything looks good. The USB device that is connected to the hosts looks fine well. Finally we see this in the NXP ISP1563_Errata_070417: "Afer receiving a continous series of NAKs, ranging from 150 ms to 500 ms, the ISP1563 will retun a condition code 06h (PID failure) in the general Transfer Descriptor (TD). This error causes the software to stall the endpoint" "The workaround is to provide a software patch. The HCD can be modified so that whenever a PID check failure occurs, the HCD will not inform the client driver. Instead it just resubmits the TD on its own and the transaction continues". Is there exisiting code that demonstrates how to resubmit a TD? The suggested workaround does not seem good design. Any ideas? Thanks. - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] USB OTG HNP (can you find any other appropriate TLAs?)
On Friday 25 May 2007, Alan Stern wrote: > On Thu, 24 May 2007, David Brownell wrote: > > On Thursday 24 May 2007, Alan Stern wrote: > > > > After all, an OTG device is required to have no > > > more than one USB connection, so the port number would always be equal > > > to udev->portnum and to 1. > > > > Not true. It's perfectly legit for a host to have multiple host > > ports, with only one of them being OTG-capable. > > Really? What about section 3.2 in the OTG spec, where it says that an > On-The-Go device must include: > > one, and only one connection: a Micro-AB receptacle. You omitted the "(except as noted in Section 3.8)", which says that a second connector is allowed iff it's a Mini-A connector. That's a trivial counter-example... But in any case, section 3 is only talking about connectors, not links that may be used internally on a mainboard and which would not be externally visible. The example I gave was for an on-mainboard device. (I've seen similar products using SDIO to access modem chips. Again, nothing visible to the end users; just boards leveraging volume pricing for parts using a wire-efficient I/O bus.) > Has this been superseded? Or do people simply ignore it? Rev 1.2 changed from 1.0a here; ISTR that 1.0a allowed more than one such connector, and allowed standard-A too. But also keep in mind that the constraint is on externally visible connectors, to reduce end-user confusion. And that as the section 3 intro says, the text there doesn't address technical details ... just the highlights. - Dave > > Not uncommon either; > > it's a simple implementation strategy (combining existing silicon IP > > with an OTG engine), and board designers find serial busses like USB > > are handy as a way to integrate various devices ... simple to route > > on the boards, only two pins, and so forth. It's not just a way to > > connect external devices. > > Alan Stern > - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] Linux USB Audio question -- asynchronous isochronous mode
Borislav Trifonov wrote: > The USB Audio standard uses isochronous transfer in one of three modes: > synchronous, adaptive, or asynchronous. I'm developing hardware that > will use the asynchronous mode to communicate with the PC, so that it is > the one doing flow control. > > My question stems from something someone told me about Windows, that it > actually will resample the data if asynchronous mode is used, which is > bad and not in the spirit of the standard specification. So I want to > confirm that Linux will _not_ do that when asynchronous USB Audio is > used, and the data will be bit-perfect -- the PCM data the player > application sends to the system is exactly what comes out the USB port. snd-usb-audio never resamples. The driver reports the actual sample rate (as reported in the async feedback packets, and measured relative to the USB clock) in /proc/asound/card*/stream*, but this is just for debugging purposes. The sample rate that is queried/set by user space is always assumed to be measured by the device's own clock. HTH Clemens - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] crash for ftdi_sio
On Fri, 25 May 2007, Sam Liddicott wrote: > I removed the USB keyboard and mouse to make things simpler. > > Still no joy, not even with any_ports_active returning 1 (and printk > added there to be sure). > > Looks like a usbmon trace is needed; I'll get that to you as soon as the > kernel rebuilds, This proves quite definitely that the auto-stop mechanism is not related to the disconnection. Alan Stern - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
[linux-usb-devel] Proofreading your professional documents
Dear Professor/Lecturer Please excuse us for contacting you directly. We are offering an efficient service to help you ensure your academic and professional work is written in perfect English. We will check the grammar and style of your work and return it to you to meet your requirements and deadlines. Proof-Reading-Service.com can provide you with a professional proofreading service at a very reasonable rate. All our proofreaders are highly qualified native English speakers. Many work as leading academics in their fields and all have extensive experience of proofreading to the highest standards. If you are interested in our service, please take a look at our website: www.proof-reading-service.com All you have to do is send us your document as a word attachment with the deadline and we will guarantee delivery of a perfectly written document to give you complete confidence when you submit your work. The fee is worked out on a flat rate (£6.95 per thousand words or 0.695 pence per word), so you know exactly how much the proofreading will cost in advance. Once we have received your document(s) we will confirm the word count, the price and the deadline. If you have not heard from us within 2 hours during normal business hours after you have sent your work please resend it from a different email account or send the file to [EMAIL PROTECTED] We look forward to hearing from you! Yours faithfully Proof-Reading-Service.com - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] USB OTG HNP (can you find any other appropriate TLAs?)
On Thu, 24 May 2007, David Brownell wrote:
> On Thursday 24 May 2007, Alan Stern wrote:
> > Dave:
> >
> > In this section from usb_new_device():
> >
> > if (!is_targeted(udev)) {
> >
> > /* Maybe it can talk to us, though we can't talk to it.
> > * (Includes HNP test device.)
> > */
> > if (udev->bus->b_hnp_enable || udev->bus->is_b_host) {
> > err = __usb_port_suspend(udev, udev->bus->otg_port);
> > if (err < 0)
> > dev_dbg(&udev->dev, "HNP fail, %d\n", err);
> > }
> >
> > Is there any reason to call __usb_port_suspend() rather than
> > usb_port_suspend()?
>
> Maybe not any more.
Okay, I'll change it. It will allow the removal of one layer of
nesting.
> > After all, an OTG device is required to have no
> > more than one USB connection, so the port number would always be equal
> > to udev->portnum and to 1.
>
> Not true. It's perfectly legit for a host to have multiple host
> ports, with only one of them being OTG-capable.
Really? What about section 3.2 in the OTG spec, where it says that an
On-The-Go device must include:
one, and only one connection: a Micro-AB receptacle.
Has this been superseded? Or do people simply ignore it?
> Not uncommon either;
> it's a simple implementation strategy (combining existing silicon IP
> with an OTG engine), and board designers find serial busses like USB
> are handy as a way to integrate various devices ... simple to route
> on the boards, only two pins, and so forth. It's not just a way to
> connect external devices.
Alan Stern
-
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
___
linux-usb-devel@lists.sourceforge.net
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] [PATCH 6/6] UNUSUAL_DEV: Sync up some reported devices from Ubuntu
On Thu, 2007-05-24 at 22:38 -0700, Phil Dibowitz wrote: > Ben Collins wrote: > >> I don't like to merge these because it means some other user of some new > >> device can get unintended consequences - but if we don't have access to the > >> data, it's better than nothing. Were you the person who owned the device? > >> If > >> not, do you still have the contact info - perhaps in a bugzilla or BTS > >> somewhere? > > > > For this device, yes. > > Alright... well since you no longer have the device, I guess we have no > choice. > > In the future, can you push these upstream sooner so the other distros and > users can get the fixes as well, and so that hopefully we can refine the > patch before the data is lost? > > > That's what the mailing list archive had in it :) Copy-and-paste > > Ditto. > > > IIRC, the bug report pointed to this diff, had reported that it fixed > > his problem after recompiling and testing with it. > > Alright... I guess I just want the one comment cleaned up - do you want me > to do it or would you like to send an updated patch? No need to send it to > LKML, just me and the two USB lists. I'll sanity-check it and then sign-off > on it. Here's the new patch, and also a link to the original Netac bug reported on linux-usb a few months ago. http://www.mail-archive.com/linux-usb-devel@lists.sourceforge.net/msg51919.html commit a3de204d2dd2b36bdc9ce16d85a03b71f89948ba Author: Ben Collins <[EMAIL PROTECTED]> Date: Wed May 23 18:39:24 2007 -0400 UNUSUAL_DEV: Sync up some reported devices from Ubuntu Various unusual dev entries accumulated from Ubuntu bug reports. CC: Phil Dibowitz <[EMAIL PROTECTED]> CC: Alan Stern <[EMAIL PROTECTED]> CC: linux-usb-devel@lists.sourceforge.net Signed-off-by: Ben Collins <[EMAIL PROTECTED]> diff --git a/drivers/usb/storage/unusual_devs.h b/drivers/usb/storage/unusual_devs.h index d230ee7..8a24f1c 100644 --- a/drivers/usb/storage/unusual_devs.h +++ b/drivers/usb/storage/unusual_devs.h @@ -1179,8 +1179,8 @@ UNUSUAL_DEV( 0x0a17, 0x006, 0x, 0x, US_SC_DEVICE, US_PR_DEVICE, NULL, US_FL_FIX_INQUIRY ), -/* These are virtual windows driver CDs, which the zd1211rw driver automatically - * converts into a WLAN devices. */ +/* These are virtual windows driver CDs, which the zd1211rw driver + * automatically converts into WLAN devices. */ UNUSUAL_DEV( 0x0ace, 0x2011, 0x0101, 0x0101, "ZyXEL", "G-220F USB-WLAN Install", @@ -1193,6 +1193,14 @@ UNUSUAL_DEV( 0x0ace, 0x20ff, 0x0101, 0x0101, US_SC_DEVICE, US_PR_DEVICE, NULL, US_FL_IGNORE_DEVICE ), +/* SanDisk that has a second LUN for a driver ISO, reported by + * Ben Collins <[EMAIL PROTECTED]> */ +UNUSUAL_DEV( 0x0781, 0x5406, 0x, 0x, + "SanDisk", + "U3 Cruzer Micro driver ISO", + US_SC_DEVICE, US_PR_DEVICE, NULL, + US_FL_SINGLE_LUN ), + #ifdef CONFIG_USB_STORAGE_ISD200 UNUSUAL_DEV( 0x0bf6, 0xa001, 0x0100, 0x0110, "ATI", @@ -1271,6 +1279,15 @@ UNUSUAL_DEV( 0x0dd8, 0x1060, 0x, 0x, US_SC_DEVICE, US_PR_DEVICE, NULL, US_FL_FIX_INQUIRY ), +/* Reported by Edward Chapman (taken from linux-usb mailing list) + Netac OnlyDisk Mini U2CV2 512MB USB 2.0 Flash Drive */ +UNUSUAL_DEV( 0x0dd8, 0xd202, 0x, 0x, + "Netac", + "USB Flash Disk", + US_SC_DEVICE, US_PR_DEVICE, NULL, + US_FL_IGNORE_RESIDUE ), + + /* Patch by Stephan Walter <[EMAIL PROTECTED]> * I don't know why, but it works... */ UNUSUAL_DEV( 0x0dda, 0x0001, 0x0012, 0x0012, -- Ubuntu : http://www.ubuntu.com/ Linux1394: http://wiki.linux1394.org/ - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] crash for ftdi_sio, usbmon
Am Freitag, 25. Mai 2007 11:27 schrieb Sam Liddicott: > de847900 337684980 C Bi:003:01 0 2 = 0160 > de847900 337684982 S Bi:003:01 -115 512 < > dd660380 337812432 S Ci:003:00 s c0 05 0002 2 < > df65b240 337864414 C Ii:001:01 0 1 = 04 > df65b240 337864422 S Ii:001:01 -115 2 < > dd660ce0 337864457 S Ci:001:00 s a3 00 0002 0004 4 < > dd660ce0 337864472 C Ci:001:00 0 4 = 01010300 > dd660ce0 337864476 S Co:001:00 s 23 01 0010 0002 0 > dd660ce0 337864479 C Co:001:00 0 0 > dd660ce0 337864482 S Co:001:00 s 23 01 0011 0002 0 > dd660ce0 337864484 C Co:001:00 0 0 > dd660380 338144475 C Ci:003:00 -108 -8 > de847900 338440538 C Bi:003:01 -108 0 > df461e60 338780618 C Ii:002:01 -108 0 Looks like talking to endpoint 0 precipitates the demise of the device. Could you load ftdi_sio.ko with "debug=1" and post the syslog? Regards Oliver -- SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nürnberg) This signature is a legal requirement - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] crash for ftdi_sio, usbmon
I think it maybe the carrier detect handling that is causing the problem, I'm investigating this. Sam - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
[linux-usb-devel] [patch 5/5] introduction of usb_anchor and overhaul of usb-skeleton
Hi, this patch set introduces usb_anchor and uses it to implement all modern APIs in the skeleton driver. - use of anchor in disconnect Regards Oliver Signed-off-by: Oliver Neukum <[EMAIL PROTECTED]> -- --- linux-2.6.22-rc2/drivers/usb/usb-skeleton.c.3 2007-05-25 13:11:33.0 +0200 +++ linux-2.6.22-rc2-autosuspend/drivers/usb/usb-skeleton.c 2007-05-25 13:13:32.0 +0200 @@ -444,7 +444,7 @@ static void skel_disconnect(struct usb_i dev->interface = NULL; mutex_unlock(&dev->io_mutex); - + usb_kill_anchored_urbs(&dev->submitted); /* decrement our usage count */ kref_put(&dev->kref, skel_delete); - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
[linux-usb-devel] [patch 4/5] introduction of usb_anchor and overhaul of usb-skeleton
Hi,
this patch set introduces usb_anchor and uses it to implement all modern
APIs in the skeleton driver.
- implementation of pre/post_reset
Regards
Oliver
Signed-off-by: Oliver Neukum <[EMAIL PROTECTED]>
--- linux-2.6.22-rc2/drivers/usb/usb-skeleton.c.2 2007-05-25
13:08:11.0 +0200
+++ linux-2.6.22-rc2-autosuspend/drivers/usb/usb-skeleton.c 2007-05-25
13:10:41.0 +0200
@@ -476,12 +476,31 @@ static int skel_resume (struct usb_inter
return 0;
}
+static void skel_pre_reset(struct usb_interface *intf)
+{
+ struct usb_skel *dev = usb_get_intfdata(intf);
+
+ mutex_lock(&dev->io_mutex);
+ skel_draw_down(dev);
+}
+
+static void skel_post_reset(struct usb_interface *intf)
+{
+ struct usb_skel *dev = usb_get_intfdata(intf);
+
+ /* we are sure no URBs are active - no locking needed */
+ dev->errors = -EPIPE;
+ mutex_unlock(&dev->io_mutex);
+}
+
static struct usb_driver skel_driver = {
.name = "skeleton",
.probe =skel_probe,
.disconnect = skel_disconnect,
.suspend = skel_suspend,
.resume = skel_resume,
+ .pre_reset =skel_pre_reset,
+ .post_reset = skel_post_reset,
.id_table = skel_table,
.supports_autosuspend = 1,
};
-
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
___
linux-usb-devel@lists.sourceforge.net
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
[linux-usb-devel] [patch 3/5] introduction of usb_anchor and overhaul of usb-skeleton
Hi,
this patch set introduces usb_anchor and uses it to implement all modern
APIs in the skeleton driver.
- support for suspend/resume
Regards
Oliver
Signed-off-by: Oliver Neukum <[EMAIL PROTECTED]>
-
--- linux-2.6.22-rc2/drivers/usb/usb-skeleton.c.1 2007-05-25
12:52:17.0 +0200
+++ linux-2.6.22-rc2-autosuspend/drivers/usb/usb-skeleton.c 2007-05-25
13:05:01.0 +0200
@@ -60,6 +60,7 @@ struct usb_skel {
__u8bulk_in_endpointAddr; /* the address of the
bulk in endpoint */
__u8bulk_out_endpointAddr; /* the address of the
bulk out endpoint */
int errors; /* the last request
tanked */
+ int open_count; /* count the number of
openers */
spinlock_t err_lock; /* lock for errors */
struct kref kref;
struct mutexio_mutex; /* synchronize I/O with
disconnect */
@@ -106,18 +107,29 @@ static int skel_open(struct inode *inode
/* increment our usage count for the device */
kref_get(&dev->kref);
- /* now we can drop the lock */
+
+ /* now we can drop the common lock */
+ mutex_lock(&dev->io_mutex);
mutex_unlock(&skel_open_lock);
- /* prevent the device from being autosuspended */
- retval = usb_autopm_get_interface(interface);
- if (retval) {
+ if (!dev->open_count++) {
+ retval = usb_autopm_get_interface(interface);
+ if (retval) {
+ mutex_unlock(&dev->io_mutex);
+ kref_put(&dev->kref, skel_delete);
+ goto exit;
+ }
+ } /* else { //uncomment this block if you want exclusive open
+ retval = -EBUSY;
+ dev->open_count--;
+ mutex_unlock(&dev->io_mutex);
kref_put(&dev->kref, skel_delete);
goto exit;
- }
+ } */
/* save our object in the file's private structure */
file->private_data = dev;
+ mutex_unlock(&dev->io_mutex);
exit:
return retval;
@@ -133,7 +145,7 @@ static int skel_release(struct inode *in
/* allow the device to be autosuspended */
mutex_lock(&dev->io_mutex);
- if (dev->interface)
+ if (!--dev->open_count && dev->interface)
usb_autopm_put_interface(dev->interface);
mutex_unlock(&dev->io_mutex);
@@ -449,10 +461,27 @@ static void skel_draw_down(struct usb_sk
usb_kill_anchored_urbs(&dev->submitted);
}
+static int skel_suspend(struct usb_interface *intf, pm_message_t message)
+{
+ struct usb_skel *dev = usb_get_intfdata(intf);
+
+ if (!dev)
+ return 0;
+ skel_draw_down(dev);
+ return 0;
+}
+
+static int skel_resume (struct usb_interface *intf)
+{
+ return 0;
+}
+
static struct usb_driver skel_driver = {
.name = "skeleton",
.probe =skel_probe,
.disconnect = skel_disconnect,
+ .suspend = skel_suspend,
+ .resume = skel_resume,
.id_table = skel_table,
.supports_autosuspend = 1,
};
-
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
___
linux-usb-devel@lists.sourceforge.net
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
[linux-usb-devel] [patch2/5] introduction of usb_anchor and overhaul of usb-skeleton
Hi,
this patch set introduces usb_anchor and uses it to implement all modern
APIs in the skeleton driver.
- proper error reporting in the skeleton driver
- implementation of flush()
Regards
Oliver
Signed-off-by: Oliver Neukum <[EMAIL PROTECTED]>
--- linux-2.6.22-rc2/drivers/usb/usb-skeleton.c 2007-05-22 14:50:34.0
+0200
+++ linux-2.6.22-rc2-autosuspend/drivers/usb/usb-skeleton.c 2007-05-25
12:47:51.0 +0200
@@ -54,16 +54,20 @@ struct usb_skel {
struct usb_device *udev; /* the usb device for
this device */
struct usb_interface*interface; /* the interface for
this device */
struct semaphorelimit_sem; /* limiting the number
of writes in progress */
+ struct usb_anchor submitted; /* in case we need to
retract our submissions */
unsigned char *bulk_in_buffer;/* the buffer to
receive data */
size_t bulk_in_size; /* the size of the
receive buffer */
__u8bulk_in_endpointAddr; /* the address of the
bulk in endpoint */
__u8bulk_out_endpointAddr; /* the address of the
bulk out endpoint */
+ int errors; /* the last request
tanked */
+ spinlock_t err_lock; /* lock for errors */
struct kref kref;
struct mutexio_mutex; /* synchronize I/O with
disconnect */
};
#define to_skel_dev(d) container_of(d, struct usb_skel, kref)
static struct usb_driver skel_driver;
+static void skel_draw_down(struct usb_skel *dev);
static void skel_delete(struct kref *kref)
{
@@ -138,6 +142,30 @@ static int skel_release(struct inode *in
return 0;
}
+static int skel_flush(struct file *file, fl_owner_t id)
+{
+ struct usb_skel *dev;
+ int res;
+
+ dev = (struct usb_skel *)file->private_data;
+ if (dev == NULL)
+ return -ENODEV;
+
+ /* wait for io to stop */
+ mutex_lock(&dev->io_mutex);
+ skel_draw_down(dev);
+
+ /* read out errors, leave subsequent opens a clean slate */
+ spin_lock_irq(&dev->err_lock);
+ res = dev->errors ? (dev->errors == -EPIPE ? -EPIPE : -EIO) : 0;
+ dev->errors = 0;
+ spin_unlock_irq(&dev->err_lock);
+
+ mutex_unlock(&dev->io_mutex);
+
+ return res;
+}
+
static ssize_t skel_read(struct file *file, char *buffer, size_t count, loff_t
*ppos)
{
struct usb_skel *dev;
@@ -179,12 +207,16 @@ static void skel_write_bulk_callback(str
dev = (struct usb_skel *)urb->context;
/* sync/async unlink faults aren't errors */
- if (urb->status &&
- !(urb->status == -ENOENT ||
- urb->status == -ECONNRESET ||
- urb->status == -ESHUTDOWN)) {
- err("%s - nonzero write bulk status received: %d",
- __FUNCTION__, urb->status);
+ if (urb->status) {
+ if(!(urb->status == -ENOENT ||
+ urb->status == -ECONNRESET ||
+ urb->status == -ESHUTDOWN))
+ err("%s - nonzero write bulk status received: %d",
+ __FUNCTION__, urb->status);
+
+ spin_lock(&dev->err_lock);
+ dev->errors = urb->status;
+ spin_unlock(&dev->err_lock);
}
/* free up our allocated buffer */
@@ -213,6 +245,17 @@ static ssize_t skel_write(struct file *f
goto exit;
}
+ spin_lock_irq(&dev->err_lock);
+ if ((retval = dev->errors) < 0) {
+ /* any error is reported once */
+ dev->errors = 0;
+ /* to preserve notifications about reset */
+ retval = (retval == -EPIPE) ? retval : -EIO;
+ }
+ spin_unlock_irq(&dev->err_lock);
+ if (retval < 0)
+ goto error;
+
/* create a urb, and a buffer for it, and copy the data to the urb */
urb = usb_alloc_urb(0, GFP_KERNEL);
if (!urb) {
@@ -244,13 +287,14 @@ static ssize_t skel_write(struct file *f
usb_sndbulkpipe(dev->udev,
dev->bulk_out_endpointAddr),
buf, writesize, skel_write_bulk_callback, dev);
urb->transfer_flags |= URB_NO_TRANSFER_DMA_MAP;
+ usb_anchor_urb(urb, &dev->submitted);
/* send the data out the bulk port */
retval = usb_submit_urb(urb, GFP_KERNEL);
mutex_unlock(&dev->io_mutex);
if (retval) {
err("%s - failed submitting write urb, error %d", __FUNCTION__,
retval);
- goto error;
+ goto error_unanchor;
}
/* release our reference to this urb, the USB core will eventually free
it entirely */
@@ -259,6 +303,8 @@ static ssize_t skel_write(struct file *f
[linux-usb-devel] [patch 1/5] introduction of usb_anchor and overhaul of usb-skeleton
Hi,
this patch set introduces usb_anchor and uses it to implement all modern
APIs in the skeleton driver.
- introduction of usb_anchor and its methods
Regards
Oliver
Signed-off-by: Oliver Neukum <[EMAIL PROTECTED]>
--- a/drivers/usb/core/hcd.c2007-05-22 14:50:32.0 +0200
+++ b/drivers/usb/core/hcd.c2007-05-22 15:36:17.0 +0200
@@ -1412,6 +1412,8 @@ void usb_hcd_giveback_urb (struct usb_hc
}
usbmon_urb_complete (&hcd->self, urb);
+ usb_unanchor_urb(urb);
+
/* pass ownership to the completion handler */
urb->complete (urb);
atomic_dec (&urb->use_count);
--- a/include/linux/usb.h 2007-05-22 14:51:01.0 +0200
+++ b/include/linux/usb.h 2007-05-23 18:49:02.0 +0200
@@ -958,11 +958,26 @@ struct usb_iso_packet_descriptor {
struct urb;
+struct usb_anchor {
+ struct list_head urb_list;
+ wait_queue_head_t wait;
+ spinlock_t lock;
+};
+
+static inline void init_usb_anchor(struct usb_anchor *anchor)
+{
+ INIT_LIST_HEAD(&anchor->urb_list);
+ init_waitqueue_head(&anchor->wait);
+ spin_lock_init(&anchor->lock);
+}
+
typedef void (*usb_complete_t)(struct urb *);
/**
* struct urb - USB Request Block
* @urb_list: For use by current owner of the URB.
+ * @anchor_list: membership in the list of an anchor
+ * @anchor: to anchor URBs to a common mooring
* @pipe: Holds endpoint number, direction, type, and more.
* Create these values with the eight macros available;
* usb_{snd,rcv}TYPEpipe(dev,endpoint), where the TYPE is "ctrl"
@@ -1135,6 +1150,8 @@ struct urb
/* public: documented fields in the urb that can be used by drivers */
struct list_head urb_list; /* list head for use by the urb's
* current owner */
+ struct list_head anchor_list; /* the URB may be anchored by the
driver */
+ struct usb_anchor *anchor;
struct usb_device *dev; /* (in) pointer to associated device */
unsigned int pipe; /* (in) pipe information */
int status; /* (return) non-ISO status */
@@ -1270,6 +1287,11 @@ extern struct urb *usb_get_urb(struct ur
extern int usb_submit_urb(struct urb *urb, gfp_t mem_flags);
extern int usb_unlink_urb(struct urb *urb);
extern void usb_kill_urb(struct urb *urb);
+extern void usb_kill_anchored_urbs(struct usb_anchor *anchor);
+extern void usb_anchor_urb(struct urb *urb, struct usb_anchor *anchor);
+extern void usb_unanchor_urb(struct urb *urb);
+extern int usb_wait_anchor_empty_timeout
+(struct usb_anchor *anchor, unsigned int timeout);
void *usb_buffer_alloc (struct usb_device *dev, size_t size,
gfp_t mem_flags, dma_addr_t *dma);
--- a/drivers/usb/core/urb.c2007-05-22 14:40:12.0 +0200
+++ b/drivers/usb/core/urb.c2007-05-23 18:48:06.0 +0200
@@ -4,6 +4,7 @@
#include
#include
#include
+#include
#include "hcd.h"
#define to_urb(d) container_of(d, struct urb, kref)
@@ -11,6 +12,7 @@
static void urb_destroy(struct kref *kref)
{
struct urb *urb = to_urb(kref);
+
kfree(urb);
}
@@ -34,6 +36,7 @@ void usb_init_urb(struct urb *urb)
memset(urb, 0, sizeof(*urb));
kref_init(&urb->kref);
spin_lock_init(&urb->lock);
+ INIT_LIST_HEAD(&urb->anchor_list);
}
}
@@ -100,8 +103,60 @@ struct urb * usb_get_urb(struct urb *urb
kref_get(&urb->kref);
return urb;
}
-
-
+
+/**
+ * usb_anchor_urb - anchors an URB while it is processed
+ * @urb: pointer to the urb to anchor
+ * @anchor: pointer to the anchor
+ *
+ * This can be called to have access to URBs which are to be executed
+ * without bothering to track them
+ */
+
+void usb_anchor_urb(struct urb *urb, struct usb_anchor *anchor)
+{
+ unsigned long flags;
+
+ spin_lock_irqsave(&anchor->lock, flags);
+ usb_get_urb(urb);
+ list_add_tail(&urb->anchor_list, &anchor->urb_list);
+ urb->anchor = anchor;
+ spin_unlock_irqrestore(&anchor->lock, flags);
+}
+
+/**
+ * usb_unanchor_urb - unanchors an URB
+ * @urb: pointer to the urb to anchor
+ *
+ * Call this to stop the system keeping track of this URB
+ */
+
+void usb_unanchor_urb(struct urb *urb)
+{
+ unsigned long flags;
+ struct usb_anchor *anchor;
+
+ if (!urb)
+ return;
+
+ anchor = urb->anchor;
+ if (!anchor)
+ return;
+
+ spin_lock_irqsave(&anchor->lock, flags);
+ if (unlikely(anchor != urb->anchor)) {
+ /* we've lost the race to another thread */
+ spin_unlock_irqrestore(&anchor->lock, flags);
+ return;
+ }
+ urb->anchor = NULL;
+ list_del(&urb->anchor_list);
+ spin_unlock_irqrestore(&anchor->lock, flags);
+ usb_put_urb(urb);
+ if (list_empty(&
[linux-usb-devel] [patch 0/5] introduction of usb_anchor and overhaul of usb-skeleton
Hi, this patch set introduces usb_anchor and uses it to implement all modern APIs in the skeleton driver. An anchor is a simple data structure to which URBs can be associated. Usbcore will keep track of these URBs, remove them upon completion and supplies several functions to work with them en masse. This allows drivers like skeleton to use the "fire and forget" technique and yet to correctly implement flush, suspend/resume and pre/post_reset. Regards Oliver - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
[linux-usb-devel] Please confirm your request to join NEURIM
Hello linux-usb-devel@lists.sourceforge.net, We have received your request to join the NEURIM group hosted by Yahoo! Groups, a free, easy-to-use community service. This request will expire in 7 days. TO BECOME A MEMBER OF THE GROUP: 1) Go to the Yahoo! Groups site by clicking on this link: http://groups.yahoo.com/i?i=uFs_HkJe1sFiZ01Q1DDc0fSXoqQ&e=linux-usb-devel%40lists%2Esourceforge%2Enet (If clicking doesn't work, "Cut" and "Paste" the line above into your Web browser's address bar.) -OR- 2) REPLY to this email by clicking "Reply" and then "Send" in your email program If you did not request, or do not want, a membership in the NEURIM group, please accept our apologies and ignore this message. Regards, Yahoo! Groups Customer Care Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/ - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] anchors and their use
Am Freitag, 25. Mai 2007 04:30 schrieb Alan Stern: > For a simple example driver, this is getting distressingly complicated. Our API is growing. We've introduced pre/post_reset and autosuspend within a recentlyish timeframe. How could a generic example avoid reflecting that? > Instead of worrying too much about error reporting, how about > implementing exclusive-open semantics? That would simplify things a > lot. Note that for simple drivers, exclusive-open is the rule rather > than the exception. It does not help. As yet I don't try to trace whose requests fail. Were I to do that, the patch would become even larger. In that sense it does implement exclusive open. Apart from that a generic example must have proper error handling. If we don't do it there we'll pay for it later fixing all derived drivers. > The order of your new routines is strange: suspend, pre_reset, resume, > post_reset. It's more natural to do suspend, resume, pre_reset, > post_reset. Before an event - after an event. I'll change it. Furthermore, I'll break up this patch into pieces to make it simpler to review. > There is no call to usb_pm_put_interface(). Oops. Thanks. Regards Oliver - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] [BUG] USB input death then system freeze
On Fri, 25 May 2007, Jiri Kosina wrote: > This is now handled in bugzilla [1]. Zan Lynx also reported this problem, > and from the HID_DEBUG output he provided is evident that it is caused by > HID layer receiving a report of size 4294967284 (which corresponds to > urb->actual_length of the URB received from USB core). For completness, this is a snippet of HID_DEBUG output that Zan sent me in a private mail, which demonstrates the urb->actual_length badness: ... drivers/hid/hid-core.c: report (size 3) (unnumbered) drivers/hid/hid-core.c: report 0 (size 3) = 00 00 00 hid-debug: input Keyboard.00e0 = 0 hid-debug: input Keyboard.00e1 = 0 hid-debug: input Keyboard.00e2 = 0 hid-debug: input Keyboard.00e3 = 0 hid-debug: input Keyboard.00e4 = 0 hid-debug: input Keyboard.00e5 = 0 hid-debug: input Keyboard.00e6 = 0 hid-debug: input Keyboard.00e7 = 0 drivers/hid/hid-core.c: report (size 4294967284) (unnumbered) drivers/hid/hid-core.c: report 0 (size 4294967284) = hid-debug: input Keyboard.00e0 = 0 hid-debug: input Keyboard.00e1 = 0 hid-debug: input Keyboard.00e2 = 0 hid-debug: input Keyboard.00e3 = 0 hid-debug: input Keyboard.00e4 = 0 hid-debug: input Keyboard.00e5 = 0 hid-debug: input Keyboard.00e6 = 0 hid-debug: input Keyboard.00e7 = 0 drivers/hid/hid-core.c: report (size 6) (numbered) drivers/hid/hid-core.c: report 2 (size 5) = 00 00 00 00 00 hid-debug: input Button.0001 = 0 hid-debug: input Button.0002 = 0 hid-debug: input Button.0003 = 0 hid-debug: input Button.0004 = 0 hid-debug: input Button.0005 = 0 hid-debug: input Button.0006 = 0 hid-debug: input Button.0007 = 0 hid-debug: input Button.0008 = 0 hid-debug: input GenericDesktop.X = 0 hid-debug: input GenericDesktop.Y = 0 hid-debug: input GenericDesktop.Wheel = 0 Hangcheck: hangcheck value past margin! drivers/hid/usbhid/hid-core.c: input irq status -75 received ... -- Jiri Kosina - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] [BUG] USB input death then system freeze
On Thu, 24 May 2007, Nicolas Mailhot wrote: > Most recent kernel where this bug did *NOT* occur: pre 2.6.21 mm > kernels, non-mm 2.6.22-rc2 > Distribution: Fedora Devel > Hardware Environment: EHCI input on external powered hub with CK804 mainboard > Software Environment: Nothing specific > Problem Description: > After a few hours of activity 2.6.22-rc1-mm1 and 2.6.22-rc2-mm1 will lose USB > HID INPUT (keyboard or mice with no priority), then the system will freeze > drivers/hid/usbhid/hid-core.c: input irq status -75 received This is now handled in bugzilla [1]. Zan Lynx also reported this problem, and from the HID_DEBUG output he provided is evident that it is caused by HID layer receiving a report of size 4294967284 (which corresponds to urb->actual_length of the URB received from USB core). Alan Stern suggested to reproduce the bug with CONFIG_USB_DEBUG and also collect the usbmon trace, so that we can clearly understand what happens. I am now inclined to think that this is caused by USB core messing up the URB somehow, HID core seems to receive the URB with already bogus values. [1] http://bugzilla.kernel.org/show_bug.cgi?id=8535 Thanks, -- Jiri Kosina - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] crash for ftdi_sio, usbmon
Here is usbmon output. The first cluster of traffic is (I believe) when minicom starts. The final cluster of traffic is (I believe) when everythnig breaks. Sam dd660740 334756980 S Co:003:00 s 40 00 0 dd660740 334759010 C Co:003:00 0 0 dd660740 334759057 S Co:003:00 s 40 04 0008 0 dd660740 334759989 C Co:003:00 0 0 dd660740 334760024 S Co:003:00 s 40 03 4138 0 dd660740 334760989 C Co:003:00 0 0 dd660740 334761019 S Co:003:00 s 40 01 0303 0 dd660740 334761988 C Co:003:00 0 0 dd660740 334762017 S Co:003:00 s 40 02 0 dd660740 334762988 C Co:003:00 0 0 dd660740 334763015 S Co:003:00 s 40 01 0303 0 dd660740 334763990 C Co:003:00 0 0 de847900 334764022 S Bi:003:01 -115 512 < dd660740 334764104 S Ci:003:00 s c0 05 0002 2 < dd660740 334764990 C Ci:003:00 0 2 = 0160 dd660740 334765046 S Co:003:00 s 40 04 0008 0 dd660740 334765990 C Co:003:00 0 0 dd660740 334766017 S Co:003:00 s 40 03 4138 0 dd660740 334766989 C Co:003:00 0 0 dd660740 334767015 S Co:003:00 s 40 02 0 dd660740 334767989 C Co:003:00 0 0 dd660740 334768021 S Ci:003:00 s c0 05 0002 2 < dd660740 334768990 C Ci:003:00 0 2 = 0160 dd660740 334769021 S Co:003:00 s 40 01 0303 0 dd660740 334769989 C Co:003:00 0 0 dd660740 334770022 S Co:003:00 s 40 04 0008 0 dd660740 334770989 C Co:003:00 0 0 dd660740 334771016 S Co:003:00 s 40 03 4138 0 dd660740 334771986 C Co:003:00 0 0 dd660740 334772013 S Co:003:00 s 40 02 0100 0 dd660740 334772989 C Co:003:00 0 0 dd660740 334773070 S Co:003:00 s 40 04 0008 0 dd660740 334773989 C Co:003:00 0 0 dd660740 334774015 S Co:003:00 s 40 03 4138 0 dd660740 334774989 C Co:003:00 0 0 dd660740 334775016 S Co:003:00 s 40 02 0100 0 dd660740 334775988 C Co:003:00 0 0 dd660740 334776023 S Co:003:00 s 40 04 0008 0 dd660740 334776988 C Co:003:00 0 0 dd660740 334777014 S Co:003:00 s 40 03 4138 0 dd660740 334777988 C Co:003:00 0 0 dd660740 334778015 S Co:003:00 s 40 02 0100 0 dd660740 334778989 C Co:003:00 0 0 de847900 334790041 C Bi:003:01 0 2 = 0160 de847900 334790087 S Bi:003:01 -115 512 < de847900 334806019 C Bi:003:01 0 2 = 0160 de847900 334806044 S Bi:003:01 -115 512 < dd660740 334814690 S Ci:003:00 s c0 05 0002 2 < dd660740 334815002 C Ci:003:00 0 2 = 0160 de847900 334821998 C Bi:003:01 0 2 = 0160 de847900 334822008 S Bi:003:01 -115 512 < de847900 334837992 C Bi:003:01 0 2 = 0160 de847900 334837996 S Bi:003:01 -115 512 < de847900 334853991 C Bi:003:01 0 2 = 0160 de847900 334853993 S Bi:003:01 -115 512 < de847900 334870001 C Bi:003:01 0 2 = 0160 de847900 334870011 S Bi:003:01 -115 512 < de847900 334885991 C Bi:003:01 0 2 = 0160 de847900 334885994 S Bi:003:01 -115 512 < de847900 334901993 C Bi:003:01 0 2 = 0160 de847900 334901996 S Bi:003:01 -115 512 < de847900 334917992 C Bi:003:01 0 2 = 0160 de847900 334917994 S Bi:003:01 -115 512 < de847900 334933991 C Bi:003:01 0 2 = 0160 de847900 334933994 S Bi:003:01 -115 512 < de847900 334949991 C Bi:003:01 0 2 = 0160 de847900 334949993 S Bi:003:01 -115 512 < de847900 334965991 C Bi:003:01 0 2 = 0160 de847900 334965994 S Bi:003:01 -115 512 < de847900 334981991 C Bi:003:01 0 2 = 0160 de847900 334981994 S Bi:003:01 -115 512 < de847900 334997992 C Bi:003:01 0 2 = 0160 de847900 334997995 S Bi:003:01 -115 512 < de847900 335013991 C Bi:003:01 0 2 = 0160 de847900 335013995 S Bi:003:01 -115 512 < de847900 33502 C Bi:003:01 0 2 = 0160 de847900 335030005 S Bi:003:01 -115 512 < de847900 335045990 C Bi:003:01 0 2 = 0160 de847900 335045993 S Bi:003:01 -115 512 < de847900 335061992 C Bi:003:01 0 2 = 0160 de847900 335061996 S Bi:003:01 -115 512 < de847900 335077990 C Bi:003:01 0 2 = 0160 de847900 335077993 S Bi:003:01 -115 512 < de847900 335093993 C Bi:003:01 0 2 = 0160 de847900 335093996 S Bi:003:01 -115 512 < de847900 335109991 C Bi:003:01 0 2 = 0160 de847900 335109994 S Bi:003:01 -115 512 < de847900 335125991 C Bi:003:01 0 2 = 0160 de847900 335125993 S Bi:003:01 -115 512 < de847900 335141990 C Bi:003:01 0 2 = 0160 de847900 335141993 S Bi:003:01 -115 512 < de847900 335157990 C Bi:003:01 0 2 = 0160 de847900 335157993 S Bi:003:01 -115 512 < de847900 335173989 C Bi:003:01 0 2 = 0160 de847900 335173992 S Bi:003:01 -115 512 < de847900 335189990 C Bi:003:01 0 2 = 0160 de847900 335189994 S Bi:003:01 -115 512 < de847900 335205992 C Bi:003:01 0 2 = 0160 de847900 335205994 S Bi:003:01 -115 512 < de847900 335221989 C Bi:003:01 0 2 = 0160 de847900 335221992 S Bi:003:01 -115 512 < de847900 335237991 C Bi:003:01 0 2 = 0160 de847900 335237993 S Bi:003:01 -115 512 < de847900 335253989 C Bi:003:01 0 2 = 0160 de847900 335253992 S Bi:003:01 -115 512 < de847900 335269990 C Bi:003:01 0 2 = 0160 de847900 335269992 S Bi:003:01 -115 512 < de847900 335285989 C Bi:003:01 0 2 = 0160 de847900 335285992 S Bi:003:01 -115 512 < de847900 335301991 C Bi:003:01 0 2 = 0160 de847900 335301993 S Bi:003:01 -115
Re: [linux-usb-devel] [patch]Re: autosuspend for HID devices, take #2
Am Freitag, 25. Mai 2007 04:20 schrieb Alan Stern:
> On Thu, 24 May 2007, Greg KH wrote:
>
> > On Wed, May 23, 2007 at 06:25:36PM +0200, Oliver Neukum wrote:
> > > Am Mittwoch, 23. Mai 2007 17:42 schrieb Alan Stern:
> > > > On Wed, 23 May 2007, Oliver Neukum wrote:
> > > >
> > > > > That gives me an idea.
> > > > > Resumption of a device has to be done in task context. So if I
> > > > > allocate
> > > > > a private freezable work queue for HID resumption, the freezer would
> > > > > guard against illicit resumptions, wouldn't it?
> > > >
> > > > You can use the ksuspend_usb_wq workqueue. It already exists, is
> > > > freezable, and is used for suspending and resuming USB devices.
> > >
> > > This adds a clean accessor for the USB core pm workqueue.
> >
> > But what code is using it? I don't want to add an api call if no one
> > uses it...
I can assure you that any input driver that has some output (HID,
PID, etc) will use this.
> In fact there's a potential user in hcd.c:usb_hcd_resume_root_hub().
> If there's to be an accessor, that routine should use it.
Done.
> Oliver, you should be careful about what happens when CONFIG_PM is off.
> Under those conditions the workqueue is not created.
Done
Regards
Oliver
Signed-off-by: Oliver Neukum <[EMAIL PROTECTED]>
--
--- a/include/linux/usb.h 2007-05-23 10:20:35.0 +0200
+++ b/include/linux/usb.h 2007-05-23 18:08:31.0 +0200
@@ -1343,6 +1343,8 @@ extern int usb_set_interface(struct usb_
/* this request isn't really synchronous, but it belongs with the others */
extern int usb_driver_set_configuration(struct usb_device *udev, int config);
+extern void usb_schedule_power_work(struct work_struct *work);
+
/*
* timeouts, in milliseconds, used for sending/receiving control messages
* they typically complete within a few frames (msec) after they're issued
--- a/drivers/usb/core/message.c2007-05-22 14:50:32.0 +0200
+++ b/drivers/usb/core/message.c2007-05-25 10:54:03.0 +0200
@@ -1648,6 +1648,24 @@ int usb_driver_set_configuration(struct
}
EXPORT_SYMBOL_GPL(usb_driver_set_configuration);
+/**
+ * usb_schedule_power_work - allow drivers to execute work in the context of
the pm thread
+ * @work: work to be executed
+ *
+ * This allows work to be scheduled which is to be executed under the
+ * same conditions pm's internal works are performed, namely to be
+ * frozen when they are frozen
+ */
+
+void usb_schedule_power_work(struct work_struct *work)
+{
+#ifdef CONFIG_PM
+ queue_work(ksuspend_usb_wq, work);
+#endif
+}
+
+EXPORT_SYMBOL(usb_schedule_power_work);
+
// synchronous request completion model
EXPORT_SYMBOL(usb_control_msg);
EXPORT_SYMBOL(usb_bulk_msg);
--- a/drivers/usb/core/hcd.c2007-05-22 14:50:32.0 +0200
+++ b/drivers/usb/core/hcd.c2007-05-25 10:53:56.0 +0200
@@ -1326,7 +1326,7 @@ void usb_hcd_resume_root_hub (struct usb
spin_lock_irqsave (&hcd_root_hub_lock, flags);
if (hcd->rh_registered)
- queue_work(ksuspend_usb_wq, &hcd->wakeup_work);
+ usb_schedule_power_work(&hcd->wakeup_work);
spin_unlock_irqrestore (&hcd_root_hub_lock, flags);
}
EXPORT_SYMBOL_GPL(usb_hcd_resume_root_hub);
-
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
___
linux-usb-devel@lists.sourceforge.net
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
[linux-usb-devel] hub.c port power handling on over-current
Hi all, If I am not mistaken the current policy is to leave port power enabled at all times during over-current situations and let the power provider handle current limitation. I experienced problems with the EHCI on an MPC8343E, which after some over-current situations no longer asserts the Connect Change Status Bit in the Port Status and Control Register, leading to the result that USB would be fully functional, but is no longer effectively serviced... The solution to this problem according to Freescale support would be to disable and re-enable port power after the over-current situation. Trying this with a hardware debugger gets us back in service. As I am no big fan of work-arounds and rather new to the USB-subsystem, might I ask what would be an accaptable way to patch this behaviour? Regards - Christian - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
[linux-usb-devel] Linux USB Audio question -- asynchronous isochronous mode
The USB Audio standard uses isochronous transfer in one of three modes: synchronous, adaptive, or asynchronous. I'm developing hardware that will use the asynchronous mode to communicate with the PC, so that it is the one doing flow control. My question stems from something someone told me about Windows, that it actually will resample the data if asynchronous mode is used, which is bad and not in the spirit of the standard specification. So I want to confirm that Linux will _not_ do that when asynchronous USB Audio is used, and the data will be bit-perfect -- the PCM data the player application sends to the system is exactly what comes out the USB port. Can someone confirm or deny? Thank you. - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
