Blocking the submission on urbs to usb core
Hello Everybody, I've implemented my own usb filter. (same like usbmon) I am able to capture all urbs that are generated in host controller. But problem is those urbs get submitted to usb core automatically. I don't want this. In fact I want this submission under my control. How should I do it? I've my own functions as submit, complete and submit_error. I want my code in this functions such that I can pass those urbs to core or hcd from this place. Learning is not compulsory. . . neither is survival. Cheers Ashish website:www.alohatechnology.com Get the freedom to save as many mails as you wish. To know how, go to http://help.yahoo.com/l/in/yahoo/mail/yahoomail/tools/tools-08.html - To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Kingston Datatraveler
Hi, Tried that and had the same result. I also tried different cables with the same result. I don't believe it is a cabling issue as I have several of these broads (Evalue Tehcnoligies ECM-3610) and it is reproducible regardless of what the cabling setup is. This boards has a VIA VT82C686B South bridge 352BGA. I have also tried several kernels all the way up to 2.6.23.9. On Dec 19, 2007 12:15 AM, Pete Zaitcev <[EMAIL PROTECTED]> wrote: > On Tue, 18 Dec 2007 16:27:28 +, "Brian Murphy" <[EMAIL PROTECTED]> wrote: > > > sda:<6>usb 1-2: reset full speed USB device using uhci_hcd and address 8 > > usb 1-2: device descriptor read/64, error -84 > > Try to insert a self-powered hub. > > -- Pete > - To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Kingston Datatraveler
Please don't top-post. On Wed, 19 Dec 2007, Brian Murphy wrote: > Hi, > > Tried that and had the same result. I also tried different cables with > the same result. I don't believe it is a cabling issue as I have > several of these broads (Evalue Tehcnoligies ECM-3610) and it is > reproducible regardless of what the cabling setup is. This boards has > a VIA VT82C686B South bridge 352BGA. I have also tried several > kernels all the way up to 2.6.23.9. > > On Dec 19, 2007 12:15 AM, Pete Zaitcev <[EMAIL PROTECTED]> wrote: > > On Tue, 18 Dec 2007 16:27:28 +, "Brian Murphy" <[EMAIL PROTECTED]> > > wrote: > > > > > sda:<6>usb 1-2: reset full speed USB device using uhci_hcd and address 8 > > > usb 1-2: device descriptor read/64, error -84 > > > > Try to insert a self-powered hub. > > > > -- Pete Have you tried plugging both the flash drive and the HID device into the external hub, with no other devices attached directly to the computer? Alan Stern - To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Blocking the submission on urbs to usb core
On Wed, 19 Dec 2007, ashish mahamuni wrote: > Hello Everybody, > > I've implemented my own usb filter. (same like usbmon) usbmon is not a filter. It is a communications channel from the kernel to userspace. > I am able to capture all urbs that are generated in > host controller. That makes no sense. URBs are not generated in the host controller; they are generated by drivers. > But problem is those urbs get submitted to usb core > automatically. What do you mean by "automatically"? No URBs are submitted manually (that is, by a human being) -- they are all submitted by drivers, and all drivers run automatically. > I don't want this. In fact I want this submission > under my control. URB submission is not under your control. You cannot prevent URBs from being submitted. The most you can do is force submissions to fail. > How should I do it? > I've my own functions as submit, complete and > submit_error. > I want my code in this functions such that I can pass > those urbs to core or hcd from this place. That is impossible. The submit, submit_error, and complete routines are called by the core, so they can't pass URBs to the core. And since the core passes URBs to the HCD, your routines cannot also pass the URBs to the HCD. You need to rethink your strategy. I don't know what you are trying to accomplish, but whatever it is, you are using a bad approach. Alan Stern - To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Kingston Datatraveler
On Wed, 19 Dec 2007 10:03:57 +, "Brian Murphy" <[EMAIL PROTECTED]> wrote: > Hi, > > Tried that and had the same result. I also tried different cables with > the same result. I don't believe it is a cabling issue as I have > several of these broads (Evalue Tehcnoligies ECM-3610) and it is > reproducible regardless of what the cabling setup is. This boards has > a VIA VT82C686B South bridge 352BGA. I have also tried several > kernels all the way up to 2.6.23.9. > > On Dec 19, 2007 12:15 AM, Pete Zaitcev <[EMAIL PROTECTED]> wrote: >> On Tue, 18 Dec 2007 16:27:28 +, "Brian Murphy" > <[EMAIL PROTECTED]> wrote: >> >> > sda:<6>usb 1-2: reset full speed USB device using uhci_hcd and what about modprobe -r uhci_hcd and using ehci_hcd instead? Does it help ? -- Best Regards, Felipe Balbi http://felipebalbi.com [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Blocking the submission on urbs to usb core
On Wed, Dec 19, 2007 at 08:59:47AM +, ashish mahamuni wrote: > Hello Everybody, > > I've implemented my own usb filter. (same like usbmon) What's wrong with usbmon? > I am able to capture all urbs that are generated in > host controller. host controllers don't generate urbs, drivers do. > But problem is those urbs get submitted to usb core > automatically. That's because drivers do this :) > I don't want this. In fact I want this submission > under my control. What exactly are you trying to do here? confused, greg k-h - To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: 2.6.24-rc5-mm1
On Wed, 19 Dec 2007, Dave Young wrote: > I tested on another machine with kernel 2.6.24-rc2. And the result is > diffrent again. > Here is the result: > > 1. on 2.6.24-rc2, when I plugin the player the kernel reports below messages: > > usb-storage: waiting for device to settle before scanning > /*[lets mark the below part as part 1]*/ > scsi 0:0:0:0: Direct-Access Newman mp3 PQ: 0 ANSI: 0 > CCS > sd 0:0:0:0: [sda] 245248 512-byte hardware sectors (126 MB) > sd 0:0:0:0: [sda] Write Protect is on > sd 0:0:0:0: [sda] Mode Sense: 03 00 80 00 > sd 0:0:0:0: [sda] Assuming drive cache: write through > sd 0:0:0:0: [sda] 245248 512-byte hardware sectors (126 MB) > sd 0:0:0:0: [sda] Write Protect is on > sd 0:0:0:0: [sda] Mode Sense: 03 00 80 00 > sd 0:0:0:0: [sda] Assuming drive cache: write through > sda: sda1 > /*[lets mark the below part as part 2]*/ > sd 0:0:0:0: [sda] Attached SCSI removable disk > usb-storage: device scan complete > sd 0:0:0:0: [sda] 245248 512-byte hardware sectors (126 MB) > sd 0:0:0:0: [sda] Write Protect is off > sd 0:0:0:0: [sda] Mode Sense: 03 00 00 00 > sd 0:0:0:0: [sda] Assuming drive cache: write through > sd 0:0:0:0: [sda] 245248 512-byte hardware sectors (126 MB) > sd 0:0:0:0: [sda] Write Protect is off > sd 0:0:0:0: [sda] Mode Sense: 03 00 00 00 > sd 0:0:0:0: [sda] Assuming drive cache: write through > sda: sda1 This is not normal. When you plug in a storage device you should get all of the messages in your part 1 plus the first two lines in your part 2, but not the rest of part 2. > 2. on 2.6.24-rc5 kernel reports only the part 1, after try mount the > disk it reports the part 2 and mount the partition as rw > > 3. on 2.6.24-rc5 kernel reports only the part 1, after try mount the > disk it just mount the partition as ro with nothing more messages. You must have a typo there. Those can't both be true for 2.6.24-rc5. In fact you shouldn't see part 2 at all. Here's what I get when I plug in a USB mass-storage device under 2.6.24-rc5: [ 87.903014] usb-storage: device found at 2 [ 87.909570] scsi 0:0:0:0: Direct-Access Memorex TD 2B1.09 PQ: 0 ANSI: 0 CCS [ 87.913144] usb-storage: device scan complete [ 88.804031] sd 0:0:0:0: [sda] 243712 512-byte hardware sectors (125 MB) [ 88.805507] sd 0:0:0:0: [sda] Write Protect is off [ 88.805577] sd 0:0:0:0: [sda] Mode Sense: 03 00 00 00 [ 88.805639] sd 0:0:0:0: [sda] Assuming drive cache: write through [ 88.809526] sd 0:0:0:0: [sda] 243712 512-byte hardware sectors (125 MB) [ 88.810421] sd 0:0:0:0: [sda] Write Protect is off [ 88.810488] sd 0:0:0:0: [sda] Mode Sense: 03 00 00 00 [ 88.810575] sd 0:0:0:0: [sda] Assuming drive cache: write through [ 88.810641] sda: sda1 [ 88.812450] sd 0:0:0:0: [sda] Attached SCSI removable disk [ 89.041014] sd 0:0:0:0: Attached scsi generic sg0 type 0 Mounting the disk produces no extra output at all. I get the same result under 2.6.23 and earlier operating systems. You should see approximately the same thing. Alan Stern - To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Strange Problem with Audio Device
On Fri, 14 Dec 2007, Jay Monkman wrote: > On Fri, Dec 14, 2007 at 11:03:59AM -0500, Alan Stern wrote: > > On Thu, 13 Dec 2007, Jay Monkman wrote: > > Does it also have a built-in OHCI controller? > > Thanks for your help. No, it only has the EHCI controller. I was > mistaken about the root hub - it has 2 ports, although only one is > connected to a transceiver. The manual for this CPU is at > http://www.freescale.com/files/32bit/doc/ref_manual/MPC8349ERM.pdf > > > > > Does the hub run at full speed or high speed? What about the audio > > device? > > The hub is a high speed hub, and the audio device is full speed. > > I have tried a full speed hub, and get a different failure. When I run > my test program, I get this from the kernel: > cannot submit datapipe for urb 0, error -28: not enough bandwidth > My test program shouldn't use all the bus bandwidth. It's full-duplex > stereo, 16 bits per sample at 32Khz. Even if the audio device is > really running at 48Khz, that's about 3 Mbps. Yes, that's understandable. The problems surface whenever you have a full-speed device attached directly to the computer (rather than going through a high-speed hub). I don't know how the Freescale controller is supposed to work. Apparently it doesn't use a companion controller for full-speed connections. Maybe it has a Transaction Translator in its root hub instead. If that's the case, then the TT isn't working right. It could be a problem with the controller hardware or a problem with the driver; I have no idea which. Alan Stern - To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Kingston Datatraveler
Hi, Yes, and I get the same result. On Dec 19, 2007 3:42 PM, Alan Stern <[EMAIL PROTECTED]> wrote: > Please don't top-post. > > > On Wed, 19 Dec 2007, Brian Murphy wrote: > > > Hi, > > > > Tried that and had the same result. I also tried different cables with > > the same result. I don't believe it is a cabling issue as I have > > several of these broads (Evalue Tehcnoligies ECM-3610) and it is > > reproducible regardless of what the cabling setup is. This boards has > > a VIA VT82C686B South bridge 352BGA. I have also tried several > > kernels all the way up to 2.6.23.9. > > > > On Dec 19, 2007 12:15 AM, Pete Zaitcev <[EMAIL PROTECTED]> wrote: > > > On Tue, 18 Dec 2007 16:27:28 +, "Brian Murphy" <[EMAIL PROTECTED]> > > > wrote: > > > > > > > sda:<6>usb 1-2: reset full speed USB device using uhci_hcd and address > > > > 8 > > > > usb 1-2: device descriptor read/64, error -84 > > > > > > Try to insert a self-powered hub. > > > > > > -- Pete > > Have you tried plugging both the flash drive and the HID device into > the external hub, with no other devices attached directly to the > computer? > > Alan Stern > > - To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Kingston Datatraveler
Can you provide a usbmon trace? Start the trace before plugging in the hub; that way it will show what happens when the hub is attached, when the mouse is plugged into the hub, and when the flash drive is plugged into the hub. Alan Stern - To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
cannot submit datapipe for urb 0, error -28: not enough bandwidth
I have an application on an embedded device. It was all happily working with a usb-storage device, a pl2303-based gps device and a usb-audio device plugged into a usb2 hub. Now I've added a usb mouse and when I open the associated /dev/event0, I start seeing the messages below when I try to play audio to the usb-audio device. cannot submit datapipe for urb 0, error -28: not enough bandwidth output: ioctl(SNDCTL_DSP_SYNC): Broken pipe cannot submit datapipe for urb 0, error -28: not enough bandwidth cannot submit datapipe for urb 0, error -28: not enough bandwidth output: ioctl(SNDCTL_DSP_SYNC): Broken pipe cannot submit datapipe for urb 0, error -28: not enough bandwidth (I've cleaned the messages up a bit from what shows on the console, the second "cannot submit [...]" typically lands in the middle of the "output: ioctl [...]" message). With gpsd running (opening /dev/ttyUSB0), with "cat < /dev/event0 > /dev/null", then "/usr/bin/madplay -Q -a -10 --no-tty-control random.mp3" seems to screw me. Without the /dev/event0 open, I don't have the problem. Am I screwed, or is there something I can tweak? $ cat /proc/cpuinfo system type : Broadcom BCM47xx processor : 0 cpu model : Broadcom BCM3302 V0.7 BogoMIPS: 197.12 wait instruction: yes microsecond timers : yes tlb_entries : 32 extra interrupt vector : no hardware watchpoint : no ASEs implemented: VCED exceptions : not available VCEI exceptions : not available $ uname -a Linux OpenWrt 2.6.23.1 #2 Fri Nov 23 04:56:20 PST 2007 mips unknown $ cat /proc/bus/usb/devices T: Bus=03 Lev=00 Prnt=00 Port=00 Cnt=00 Dev#= 1 Spd=480 MxCh= 2 B: Alloc= 3/800 us ( 0%), #Int= 2, #Iso= 8 D: Ver= 2.00 Cls=09(hub ) Sub=00 Prot=01 MxPS=64 #Cfgs= 1 P: Vendor= ProdID= Rev= 2.06 S: Manufacturer=Linux 2.6.23.1 ehci_hcd S: Product=EHCI Host Controller S: SerialNumber=:00:02.2 C:* #Ifs= 1 Cfg#= 1 Atr=e0 MxPwr= 0mA I:* If#= 0 Alt= 0 #EPs= 1 Cls=09(hub ) Sub=00 Prot=00 Driver=hub E: Ad=81(I) Atr=03(Int.) MxPS= 4 Ivl=256ms T: Bus=03 Lev=01 Prnt=01 Port=00 Cnt=01 Dev#= 2 Spd=480 MxCh= 4 D: Ver= 2.00 Cls=09(hub ) Sub=00 Prot=01 MxPS=64 #Cfgs= 1 P: Vendor=05e3 ProdID=0660 Rev= 5.07 S: Product=USB2.0 Hub C:* #Ifs= 1 Cfg#= 1 Atr=e0 MxPwr=100mA I:* If#= 0 Alt= 0 #EPs= 1 Cls=09(hub ) Sub=00 Prot=00 Driver=hub E: Ad=81(I) Atr=03(Int.) MxPS= 1 Ivl=256ms T: Bus=03 Lev=02 Prnt=02 Port=00 Cnt=01 Dev#= 3 Spd=1.5 MxCh= 0 D: Ver= 1.10 Cls=00(>ifc ) Sub=00 Prot=00 MxPS= 8 #Cfgs= 1 P: Vendor=046d ProdID=c001 Rev= 4.00 S: Manufacturer=Logitech S: Product=USB Mouse C:* #Ifs= 1 Cfg#= 1 Atr=a0 MxPwr= 50mA I:* If#= 0 Alt= 0 #EPs= 1 Cls=03(HID ) Sub=01 Prot=02 Driver=usbhid E: Ad=81(I) Atr=03(Int.) MxPS= 8 Ivl=10ms T: Bus=03 Lev=02 Prnt=02 Port=01 Cnt=02 Dev#= 4 Spd=12 MxCh= 0 D: Ver= 1.10 Cls=00(>ifc ) Sub=00 Prot=00 MxPS=64 #Cfgs= 1 P: Vendor=067b ProdID=2303 Rev= 3.00 S: Manufacturer=Prolific Technology Inc. S: Product=USB-Serial Controller C:* #Ifs= 1 Cfg#= 1 Atr=80 MxPwr=100mA I:* If#= 0 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=00 Prot=00 Driver=pl2303 E: Ad=81(I) Atr=03(Int.) MxPS= 10 Ivl=1ms E: Ad=02(O) Atr=02(Bulk) MxPS= 64 Ivl=0ms E: Ad=83(I) Atr=02(Bulk) MxPS= 64 Ivl=0ms T: Bus=03 Lev=02 Prnt=02 Port=02 Cnt=03 Dev#= 5 Spd=12 MxCh= 0 D: Ver= 1.10 Cls=00(>ifc ) Sub=00 Prot=00 MxPS= 8 #Cfgs= 1 P: Vendor=0d8c ProdID=0103 Rev= 0.10 S: Manufacturer=C-Media INC. S: Product=C-Media USB Audio C:* #Ifs= 2 Cfg#= 1 Atr=80 MxPwr=500mA I:* If#= 0 Alt= 0 #EPs= 0 Cls=01(audio) Sub=01 Prot=00 Driver=snd-usb-audio I: If#= 1 Alt= 0 #EPs= 0 Cls=01(audio) Sub=02 Prot=00 Driver=snd-usb-audio I:* If#= 1 Alt= 1 #EPs= 1 Cls=01(audio) Sub=02 Prot=00 Driver=snd-usb-audio E: Ad=06(O) Atr=09(Isoc) MxPS= 192 Ivl=1ms T: Bus=03 Lev=02 Prnt=02 Port=03 Cnt=04 Dev#= 6 Spd=480 MxCh= 0 D: Ver= 2.00 Cls=00(>ifc ) Sub=00 Prot=00 MxPS=64 #Cfgs= 1 P: Vendor=0781 ProdID=5151 Rev= 0.10 S: Manufacturer=SanDisk Corporation S: Product=Cruzer Micro S: SerialNumber=20052243530A7360A9A6 C:* #Ifs= 1 Cfg#= 1 Atr=80 MxPwr=200mA I:* If#= 0 Alt= 0 #EPs= 2 Cls=08(stor.) Sub=06 Prot=50 Driver=usb-storage E: Ad=81(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=01(O) Atr=02(Bulk) MxPS= 512 Ivl=125us T: Bus=02 Lev=00 Prnt=00 Port=00 Cnt=00 Dev#= 1 Spd=12 MxCh= 1 B: Alloc= 0/900 us ( 0%), #Int= 0, #Iso= 0 D: Ver= 1.10 Cls=09(hub ) Sub=00 Prot=00 MxPS=64 #Cfgs= 1 P: Vendor= ProdID= Rev= 2.06 S: Manufacturer=Linux 2.6.23.1 ohci_hcd S: Product=OHCI Host Controller S: SerialNumber=:00:02.1 C:* #Ifs= 1 Cfg#= 1 Atr=e0 MxPwr= 0mA I:* If#= 0 Alt= 0 #EPs= 1 Cls=09(hub ) Sub=00 Prot=00 Driver=hub E: Ad=81(
Re: Strange Problem with Audio Device
On Wednesday 19 December 2007, Alan Stern wrote: > I don't know how the Freescale controller is supposed to work. > Apparently it doesn't use a companion controller for full-speed > connections. Maybe it has a Transaction Translator in its root hub > instead. Yes. ARC originally sold that IP design, then it went to TDI, and now another company sells the licences. It doesn't actually need a TT in the root hub, but that's how it looks to the driver. What it does is send out full speed (or low speed) signaling directly from root hub ports, rather than high speed signaling with special split transaction support. > If that's the case, then the TT isn't working right. It could be a > problem with the controller hardware or a problem with the driver; I > have no idea which. Near as I can tell it's a combination of things. The TT scheduler probably doesn't handle that situation correctly. But there seems to be a second problem related to correct-but-suboptimal handling for bandwidth allocation. Basically, quantization: scheduling is split into eight microframes, and a pair of transactions that could fit into seven of them is treated as if they can't because one takes just short of six (counted as six) and the other takes just over one (counted as two) ... which adds up to more than seven, meaning only one of the transactions gets allowed. - Dave - To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[patch 2.6.24-rc5-git] usb gadget: ethernet error path potential oops fix
Fix potential (never-observed) oops on rare error path,
bugzilla #9594. Fix uses the same test as used earlier.
Also make the adjacent "else" block look like an "else" block
instead of hiding like a bug.
Signed-off-by: David Brownell <[EMAIL PROTECTED]>
---
drivers/usb/gadget/ether.c |6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
--- g26.orig/drivers/usb/gadget/ether.c 2007-12-19 10:06:30.0 -0800
+++ g26/drivers/usb/gadget/ether.c 2007-12-19 10:26:56.0 -0800
@@ -1067,19 +1067,19 @@ done:
/* on error, disable any endpoints */
if (result < 0) {
- if (!subset_active(dev))
+ if (!subset_active(dev) && dev->status_ep)
(void) usb_ep_disable (dev->status_ep);
dev->status = NULL;
(void) usb_ep_disable (dev->in_ep);
(void) usb_ep_disable (dev->out_ep);
dev->in = NULL;
dev->out = NULL;
- } else
+ }
/* activate non-CDC configs right away
* this isn't strictly according to the RNDIS spec
*/
- if (!cdc_active (dev)) {
+ else if (!cdc_active (dev)) {
netif_carrier_on (dev->net);
if (netif_running (dev->net)) {
spin_unlock (&dev->lock);
-
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
[patch 2.6.24-rc5-git] usb host: ehci potential oops fix on ARC/TDI cores
Kernel bugzilla entry #9569 reports a potential OOPS in some code
supporting the integrated root hub TT support used on ARC/TDI
derived cores. (This seems to have been a longstanding issue.)
This patch cleans up usage of urb->dev->tt to avoid that potential
oops and also fixes some overly long lines.
Signed-off-by: David Brownell <[EMAIL PROTECTED]>
---
drivers/usb/host/ehci-q.c | 19 +++
1 files changed, 11 insertions(+), 8 deletions(-)
--- a/drivers/usb/host/ehci-q.c 2007-12-06 09:50:53.0 -0800
+++ b/drivers/usb/host/ehci-q.c 2007-12-15 11:30:18.0 -0800
@@ -198,7 +198,8 @@ static int qtd_copy_status (
/* if async CSPLIT failed, try cleaning out the TT buffer */
if (status != -EPIPE
- && urb->dev->tt && !usb_pipeint (urb->pipe)
+ && urb->dev->tt
+ && !usb_pipeint(urb->pipe)
&& ((token & QTD_STS_MMF) != 0
|| QTD_CERR(token) == 0)
&& (!ehci_is_TDI(ehci)
@@ -211,6 +212,9 @@ static int qtd_copy_status (
urb->dev->ttport, urb->dev->devnum,
usb_pipeendpoint (urb->pipe), token);
#endif /* DEBUG */
+ /* REVISIT ARC-derived cores don't clear the root
+* hub TT buffer in this way...
+*/
usb_hub_tt_clear_buffer (urb->dev, urb->pipe);
}
}
@@ -638,6 +642,7 @@ qh_make (
u32 info1 = 0, info2 = 0;
int is_input, type;
int maxp = 0;
+ struct usb_tt *tt = urb->dev->tt;
if (!qh)
return qh;
@@ -661,8 +666,9 @@ qh_make (
* For control/bulk requests, the HC or TT handles these.
*/
if (type == PIPE_INTERRUPT) {
- qh->usecs = NS_TO_US (usb_calc_bus_time (USB_SPEED_HIGH,
is_input, 0,
- hb_mult (maxp) * max_packet (maxp)));
+ qh->usecs = NS_TO_US(usb_calc_bus_time(USB_SPEED_HIGH,
+ is_input, 0,
+ hb_mult(maxp) * max_packet(maxp)));
qh->start = NO_FRAME;
if (urb->dev->speed == USB_SPEED_HIGH) {
@@ -680,7 +686,6 @@ qh_make (
goto done;
}
} else {
- struct usb_tt *tt = urb->dev->tt;
int think_time;
/* gap is f(FS/LS transfer times) */
@@ -736,10 +741,8 @@ qh_make (
/* set the address of the TT; for TDI's integrated
* root hub tt, leave it zeroed.
*/
- if (!ehci_is_TDI(ehci)
- || urb->dev->tt->hub !=
- ehci_to_hcd(ehci)->self.root_hub)
- info2 |= urb->dev->tt->hub->devnum << 16;
+ if (tt && tt->hub != ehci_to_hcd(ehci)->self.root_hub)
+ info2 |= tt->hub->devnum << 16;
/* NOTE: if (PIPE_INTERRUPT) { scheduler sets c-mask } */
-
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: cannot submit datapipe for urb 0, error -28: not enough bandwidth
On 19 Dec 2007, Russell Senior wrote: > I have an application on an embedded device. It was all happily > working with a usb-storage device, a pl2303-based gps device and a > usb-audio device plugged into a usb2 hub. Now I've added a usb mouse > and when I open the associated /dev/event0, I start seeing the > messages below when I try to play audio to the usb-audio device. > > cannot submit datapipe for urb 0, error -28: not enough bandwidth > output: ioctl(SNDCTL_DSP_SYNC): Broken pipe > cannot submit datapipe for urb 0, error -28: not enough bandwidth > cannot submit datapipe for urb 0, error -28: not enough bandwidth > output: ioctl(SNDCTL_DSP_SYNC): Broken pipe > cannot submit datapipe for urb 0, error -28: not enough bandwidth > > > (I've cleaned the messages up a bit from what shows on the console, > the second "cannot submit [...]" typically lands in the middle of the > "output: ioctl [...]" message). > > With gpsd running (opening /dev/ttyUSB0), with "cat < /dev/event0 > > /dev/null", > then "/usr/bin/madplay -Q -a -10 --no-tty-control random.mp3" seems to > screw me. Without the /dev/event0 open, I don't have the problem. > > Am I screwed, or is there something I can tweak? You can try replacing your hub. Some USB 2.0 hubs have greater bandwidth capacity for full-speed devices than yours (they have separate Transaction Translators for each port). Or you can try plugging some of those full-speed devices directly into the computer rather than into the hub. The storage device doesn't matter, but the gps, audio, and mouse devices are all sharing the hub's bandwidth. Alan Stern - To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [linux-usb-devel] Blocking the submission on urbs to usb core
On Wed, Dec 19, 2007 at 05:21:29PM +, ashish mahamuni wrote: > I am trying to send those urbs to remote machine,where > I will try to detect my device > This is client-server apporoach > I'll attach device to server,I don't want that device > to be detected on server. > I want this device to be detected on client. i.e. my > remote machine. So you want to send the USB packets from the device attached to the server to the client machine, say through a socket? And you don't want the USB device driver on the server side to respond to the packets, you want the client to respond to them instead? It sounds like what you want is to replace the driver for the USB device on the server side with a driver that sends the USB device data to the server over a socket, and sends data received through the socket to the device. I'm not sure how a filter would work for this; unless you're trying to generalize this code for all devices? But why do you want the remote machine handle communication? What underlying problem are you trying to solve? Sarah - To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: 2.6.24-rc5-mm1
On Dec 20, 2007 12:07 AM, Alan Stern <[EMAIL PROTECTED]> wrote: > > On Wed, 19 Dec 2007, Dave Young wrote: > > > I tested on another machine with kernel 2.6.24-rc2. And the result is > > diffrent again. > > Here is the result: > > > > 1. on 2.6.24-rc2, when I plugin the player the kernel reports below > > messages: > > > > usb-storage: waiting for device to settle before scanning > > /*[lets mark the below part as part 1]*/ > > scsi 0:0:0:0: Direct-Access Newman mp3 PQ: 0 ANSI: > > 0 CCS > > sd 0:0:0:0: [sda] 245248 512-byte hardware sectors (126 MB) > > sd 0:0:0:0: [sda] Write Protect is on > > sd 0:0:0:0: [sda] Mode Sense: 03 00 80 00 > > sd 0:0:0:0: [sda] Assuming drive cache: write through > > sd 0:0:0:0: [sda] 245248 512-byte hardware sectors (126 MB) > > sd 0:0:0:0: [sda] Write Protect is on > > sd 0:0:0:0: [sda] Mode Sense: 03 00 80 00 > > sd 0:0:0:0: [sda] Assuming drive cache: write through > > sda: sda1 > > /*[lets mark the below part as part 2]*/ > > sd 0:0:0:0: [sda] Attached SCSI removable disk > > usb-storage: device scan complete > > sd 0:0:0:0: [sda] 245248 512-byte hardware sectors (126 MB) > > sd 0:0:0:0: [sda] Write Protect is off > > sd 0:0:0:0: [sda] Mode Sense: 03 00 00 00 > > sd 0:0:0:0: [sda] Assuming drive cache: write through > > sd 0:0:0:0: [sda] 245248 512-byte hardware sectors (126 MB) > > sd 0:0:0:0: [sda] Write Protect is off > > sd 0:0:0:0: [sda] Mode Sense: 03 00 00 00 > > sd 0:0:0:0: [sda] Assuming drive cache: write through > > sda: sda1 > > This is not normal. When you plug in a storage device you should get > all of the messages in your part 1 plus the first two lines in your > part 2, but not the rest of part 2. > > > 2. on 2.6.24-rc5 kernel reports only the part 1, after try mount the > > disk it reports the part 2 and mount the partition as rw > > > > 3. on 2.6.24-rc5 kernel reports only the part 1, after try mount the > > disk it just mount the partition as ro with nothing more messages. > > You must have a typo there. Those can't both be true for 2.6.24-rc5. > In fact you shouldn't see part 2 at all. > > Here's what I get when I plug in a USB mass-storage device under > 2.6.24-rc5: > > [ 87.903014] usb-storage: device found at 2 > [ 87.909570] scsi 0:0:0:0: Direct-Access Memorex TD 2B1.09 > PQ: 0 ANSI: 0 CCS > [ 87.913144] usb-storage: device scan complete > [ 88.804031] sd 0:0:0:0: [sda] 243712 512-byte hardware sectors (125 MB) > [ 88.805507] sd 0:0:0:0: [sda] Write Protect is off > [ 88.805577] sd 0:0:0:0: [sda] Mode Sense: 03 00 00 00 > [ 88.805639] sd 0:0:0:0: [sda] Assuming drive cache: write through > [ 88.809526] sd 0:0:0:0: [sda] 243712 512-byte hardware sectors (125 MB) > [ 88.810421] sd 0:0:0:0: [sda] Write Protect is off > [ 88.810488] sd 0:0:0:0: [sda] Mode Sense: 03 00 00 00 > [ 88.810575] sd 0:0:0:0: [sda] Assuming drive cache: write through > [ 88.810641] sda: sda1 > [ 88.812450] sd 0:0:0:0: [sda] Attached SCSI removable disk > [ 89.041014] sd 0:0:0:0: Attached scsi generic sg0 type 0 > > Mounting the disk produces no extra output at all. I get the same > result under 2.6.23 and earlier operating systems. You should see > approximately the same thing. Hi, Alan I'm sure about my post. I'm not so famillar with usb. It looks weird. Seems that my device will be firstly recoganized as a mp3 player and then a usb storage, so the system will report part 1 & part 2 under previous kernels. Regards dave - To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: cannot submit datapipe for urb 0, error -28: not enough bandwidth
> "Alan" == Alan Stern <[EMAIL PROTECTED]> writes: Alan> On 19 Dec 2007, Russell Senior wrote: >> I have an application on an embedded device. It was all happily >> working with a usb-storage device, a pl2303-based gps device and a >> usb-audio device plugged into a usb2 hub. Now I've added a usb >> mouse and when I open the associated /dev/event0, I start seeing >> the messages below when I try to play audio to the usb-audio >> device. >> >> cannot submit datapipe for urb 0, error -28: not enough bandwidth >> output: ioctl(SNDCTL_DSP_SYNC): Broken pipe cannot submit datapipe >> for urb 0, error -28: not enough bandwidth cannot submit datapipe >> for urb 0, error -28: not enough bandwidth output: >> ioctl(SNDCTL_DSP_SYNC): Broken pipe cannot submit datapipe for urb >> 0, error -28: not enough bandwidth >> >> [...] >> >> With gpsd running (opening /dev/ttyUSB0), with "cat < /dev/event0 > >> /dev/null", then "/usr/bin/madplay -Q -a -10 --no-tty-control >> random.mp3" seems to screw me. Without the /dev/event0 open, I >> don't have the problem. >> >> Am I screwed, or is there something I can tweak? Alan> You can try replacing your hub. Some USB 2.0 hubs have greater Alan> bandwidth capacity for full-speed devices than yours (they have Alan> separate Transaction Translators for each port). Can you suggest one? I have a few lying around to try, but if I have to buy one I'd like to get the right one the first time. Alan> Or you can try plugging some of those full-speed devices Alan> directly into the computer rather than into the hub. Regrettably, the board has but one usb port. Alan> The storage device doesn't matter, but the gps, audio, and mouse Alan> devices are all sharing the hub's bandwidth. Right. Thanks! -- Russell Senior ``I have nine fingers; you have ten.'' [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: 2.6.24-rc5-mm1
Note carefully. This: > > > 2. on 2.6.24-rc5 kernel reports only the part 1, after try mount the > > > disk it reports the part 2 and mount the partition as rw contradicts this: > > > 3. on 2.6.24-rc5 kernel reports only the part 1, after try mount the > > > disk it just mount the partition as ro with nothing more messages. So which is correct? > Hi, Alan > > I'm sure about my post. But your post contradicts itself. It can't be correct. > I'm not so famillar with usb. > It looks weird. Seems that my device will be firstly recoganized as a > mp3 player and then a usb storage, so the system will report part 1 & > part 2 under previous kernels. I think those "part 2" messages aren't caused by the kernel at all, but instead by some program running on your computer. You could try booting into single-user mode and see if the behavior changes. Also there's no question -- the device does behave strangely. It shouldn't change the write-protect setting all by itself. Alan Stern - To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: 2.6.24-rc5-mm1
On Dec 20, 2007 11:34 AM, Alan Stern <[EMAIL PROTECTED]> wrote: > Note carefully. This: > > > > > 2. on 2.6.24-rc5 kernel reports only the part 1, after try mount the > > > > disk it reports the part 2 and mount the partition as rw > > contradicts this: > > > > > 3. on 2.6.24-rc5 kernel reports only the part 1, after try mount the > > > > disk it just mount the partition as ro with nothing more messages. Oh, sorry. It's a typo. should be 2.6.24-rc5-mm1 > > So which is correct? > > > Hi, Alan > > > > I'm sure about my post. > > But your post contradicts itself. It can't be correct. > > > I'm not so famillar with usb. > > It looks weird. Seems that my device will be firstly recoganized as a > > mp3 player and then a usb storage, so the system will report part 1 & > > part 2 under previous kernels. > > I think those "part 2" messages aren't caused by the kernel at all, but > instead by some program running on your computer. You could try > booting into single-user mode and see if the behavior changes. No doubt for me. Under osx plugin this device will popup a dialog(I don't remember the content), after press ok then the disk icon go away, and then being remount again. > > Also there's no question -- the device does behave strangely. It > shouldn't change the write-protect setting all by itself. Yes, I think so too. > > Alan Stern > > - To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
