[linux-usb-devel] patch usb-file-storage-gadget-add-reference-count-for-children.patch added to gregkh-2.6 tree

2005-11-15 Thread gregkh 

This is a note to let you know that I've just added the patch titled

 Subject: USB: file-storage gadget: Add reference count for children

to my gregkh-2.6 tree.  Its filename is

 usb-file-storage-gadget-add-reference-count-for-children.patch

This tree can be found at 
http://www.kernel.org/pub/linux/kernel/people/gregkh/gregkh-2.6/patches/

Patches currently in gregkh-2.6 which might be from [EMAIL PROTECTED] are

usb/ehci-fix-conflation-of-buf-0-with-len-0.patch
usb/usb-libusual.patch
usb/usb-remove-usb_audio-and-usb_midi-drivers.patch
usb/usb-file-storage-gadget-add-reference-count-for-children.patch
usb/usb-makefile-change-for-libusual.patch


>From [EMAIL PROTECTED] Wed Nov  9 14:03:45 2005
Date: Wed, 9 Nov 2005 16:59:56 -0500 (EST)
From: Alan Stern <[EMAIL PROTECTED]>
To: Greg KH <[EMAIL PROTECTED]>
cc: USB development list 
Subject: USB: file-storage gadget: Add reference count for children
Message-ID: <[EMAIL PROTECTED]>

This patch (as601) adds a proper reference count to the file-storage
gadget's main data structure, to keep track of references held by child
devices (LUNs in this case).  Before this, the driver would wait for
each child to be released before unbinding.

While there's nothing really wrong with that (you can't create a hang by
doing "rmmod g_file_storage 
Signed-off-by: Greg Kroah-Hartman <[EMAIL PROTECTED]>

---
 drivers/usb/gadget/file_storage.c |   30 +-
 1 file changed, 17 insertions(+), 13 deletions(-)

--- gregkh-2.6.orig/drivers/usb/gadget/file_storage.c
+++ gregkh-2.6/drivers/usb/gadget/file_storage.c
@@ -224,6 +224,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -631,6 +632,9 @@ struct fsg_dev {
/* filesem protects: backing files in use */
struct rw_semaphore filesem;
 
+   /* reference counting: wait until all LUNs are released */
+   struct kref ref;
+
struct usb_ep   *ep0;   // Handy copy of gadget->ep0
struct usb_request  *ep0req;// For control responses
volatile unsigned int   ep0_req_tag;
@@ -694,7 +698,6 @@ struct fsg_dev {
unsigned intnluns;
struct lun  *luns;
struct lun  *curlun;
-   struct completion   lun_released;
 };
 
 typedef void (*fsg_routine_t)(struct fsg_dev *);
@@ -3642,11 +3645,19 @@ static DEVICE_ATTR(file, 0444, show_file
 
 /*-*/
 
+static void fsg_release(struct kref *ref)
+{
+   struct fsg_dev  *fsg = container_of(ref, struct fsg_dev, ref);
+
+   kfree(fsg->luns);
+   kfree(fsg);
+}
+
 static void lun_release(struct device *dev)
 {
struct fsg_dev  *fsg = (struct fsg_dev *) dev_get_drvdata(dev);
 
-   complete(&fsg->lun_released);
+   kref_put(&fsg->ref, fsg_release);
 }
 
 static void fsg_unbind(struct usb_gadget *gadget)
@@ -3660,14 +3671,12 @@ static void fsg_unbind(struct usb_gadget
clear_bit(REGISTERED, &fsg->atomic_bitflags);
 
/* Unregister the sysfs attribute files and the LUNs */
-   init_completion(&fsg->lun_released);
for (i = 0; i < fsg->nluns; ++i) {
curlun = &fsg->luns[i];
if (curlun->registered) {
device_remove_file(&curlun->dev, &dev_attr_ro);
device_remove_file(&curlun->dev, &dev_attr_file);
device_unregister(&curlun->dev);
-   wait_for_completion(&fsg->lun_released);
curlun->registered = 0;
}
}
@@ -3846,6 +3855,7 @@ static int __init fsg_bind(struct usb_ga
curlun->dev.release = lun_release;
device_create_file(&curlun->dev, &dev_attr_ro);
device_create_file(&curlun->dev, &dev_attr_file);
+   kref_get(&fsg->ref);
}
 
if (file[i] && *file[i]) {
@@ -4061,6 +4071,7 @@ static int __init fsg_alloc(void)
return -ENOMEM;
spin_lock_init(&fsg->lock);
init_rwsem(&fsg->filesem);
+   kref_init(&fsg->ref);
init_waitqueue_head(&fsg->thread_wqh);
init_completion(&fsg->thread_notifier);
 
@@ -4069,13 +4080,6 @@ static int __init fsg_alloc(void)
 }
 
 
-static void fsg_free(struct fsg_dev *fsg)
-{
-   kfree(fsg->luns);
-   kfree(fsg);
-}
-
-
 static int __init fsg_init(void)
 {
int rc;
@@ -4085,7 +4089,7 @@ static int __init fsg_init(void)
return rc;
fsg = the_fsg;
if ((rc = usb_gadget_register_driver(&fsg_driver)) != 0)
-   fsg_free(fsg);
+   kref_put(&fsg->ref, fsg_release);
return rc;
 }
 module_init(fsg_init);
@@ -4103,6 +4107,6 @@ static void __exit fsg_cleanup(void)
wait_for_completion(&fsg->thread_notifier);
 
close_all_backing_files

Re: [linux-usb-devel] Problem with async bulk in a new driver

2005-11-15 Thread Daniel Drake 

gerard klaver wrote:

Did you set the configuration, interface and altsetting before the bulk
read command?


Not explicitly, but my driver probe routine checks the interface so this 
should be already binded. I based my driver on the structure of others, so I 
don't think this is required.


Either way, I'll have a play with this and see if it helps. Thanks for the 
suggestion.



Also putting this info on a website is maybe a better idea for sharing
info.


Sorry, should have said that the driver code is at 
http://dev.gentoo.org/~dsd/dpfp

I'll add the sniffed logs there soon.


No info about the used fingerprint chip i assume?


Nope, not other than its manufactured by Digital Persona and I expect the 
hardware is very similar to their UareU 4000 device.



Depending on your plans for such a device, writing a sane backend could
be another option (scanner/webcam).


Maybe, I'm hoping to be able to extract images from it and then use the BioAPI 
stuff (www.linuxbiometrics.com) to do fingerprint recognition. I haven't 
really looked that far just yet anyway :)


Thanks
Daniel


---
This SF.Net email is sponsored by the JBoss Inc.  Get Certified Today
Register for a JBoss Training Course.  Free Certification Exam
for All Training Attendees Through End of 2005. For more info visit:
http://ads.osdn.com/?ad_id=7628&alloc_id=16845&op=click
___
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] Problem with async bulk in a new driver

2005-11-15 Thread Daniel Drake 

Alan Stern wrote:
But the data shown by usbmon is different from the data shown by UsbSnoop!  
The Linux data indicates the presence of 3 interfaces whereas the Windows

data indicates just 1.  Maybe Windows has filtered the data for you.


Under UsbSnoop I get 4 possible options for what I log- any of the 3 
interfaces, plus a composite device. The logs I posted were from the 
fingerprint interface alone. That may be an explanation for this.


I would certainly be suspicious about the other interfaces.  Note that 
HID-compliant interfaces can receive reports as well as send them.


I guess that is the next step then.

Thanks a lot for going to the effort of looking over this, the explanations 
are much appreciated.


Daniel


---
This SF.Net email is sponsored by the JBoss Inc.  Get Certified Today
Register for a JBoss Training Course.  Free Certification Exam
for All Training Attendees Through End of 2005. For more info visit:
http://ads.osdn.com/?ad_id=7628&alloc_id=16845&op=click
___
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] HELP: Problem with HP Laserjet 1022 and USB in Linux 2.6.12

2005-11-15 Thread Neil Brown 
On Tuesday November 15, [EMAIL PROTECTED] wrote:
> > 
> > I'll leave it up to you to decide if it should be submitted to
> > mainline.
> 
> Not just now.

Fine.

> 
> Can you get a usbmon log showing your change in action?  It would be 
> interesting to see the time intervals involved.

I've got piles of usbmon logs, and I'm happy to create more.  Could
you be specific about that would help, and different setting show
different things differently :-)

For example, I have a rather nice log with 64 byte writes (so there is
one packet per UDB).  If I take the completion time stamps, find the
remainder after dividing by 111838(microseconds) and graph that I get
a really interesting graph!!  I cannot explain all the features, but
I'm sure they correlate significantly to some aspect of the printer
hardware

I guess the question is what size write request would be most helpful.
8192bytes means there is plenty of opportunity for FSBR to push lots
of packets out, but it means that each record reported by usbmon
corresponds to 128 packets, so you lose a lot of detail.
64bytes gives more detail, but with less chance for FSBR to have an
effect (as usblp only submits one URB at a time).
Maybe 512 would be a reasonable compromise?

> 
> It would also be worthwhile to see if you can get more or less the same 
> effect without all those changes, just by increasing IDLE_TIMEOUT to 1000 
> ms or something like that.

I did get similar throughput with IDLE_TIMEOUT set to 5.  1000
wouldn't be enough with 8K writes, as an 8K write often takes more
than one second.  But I'm happy to redo some tests to be able to give
you clear before/after results.  It'll probably have to wait a week or
so, as I've spent more time on this that I really should have lately.

NeilBrown


---
This SF.Net email is sponsored by the JBoss Inc.  Get Certified Today
Register for a JBoss Training Course.  Free Certification Exam
for All Training Attendees Through End of 2005. For more info visit:
http://ads.osdn.com/?ad_id=7628&alloc_id=16845&op=click
___
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 stack hangs after sporadic disconnect

2005-11-15 Thread Jan Kiszka 
Alan Stern wrote:
> On Tue, 15 Nov 2005, Jan Kiszka wrote:
> 
> 
>>>And get that stack trace.  It's the best way to find the exact location of 
>>>the problem.
>>>
>>
>>Will the trace I request typically hours after the disconnect (I can't
>>sit aside my box all the time...) still contain valuable information? Or
>>should I better place some trace-triggering command at a prominent place?
> 
> 
> If things do hang up the way you described, then the trace will still be 
> useful even hours later.
> 

Trace attached. One ehci_endpoint_disable call actually does not return.

I furthermore had my box running without ehci for about 8 hours today,
and no disconnect occured.

Next step?

Jan
Nov 15 19:27:29 nibbler -- MARK --
Nov 15 19:47:30 nibbler -- MARK --
Nov 15 20:07:30 nibbler -- MARK --
Nov 15 20:07:39 nibbler kernel: hub 4-0:1.0: state 5 ports 6 chg  evt 0008
Nov 15 20:07:39 nibbler kernel: ehci_hcd :00:10.3: GetStatus port 3 status 
00180b POWER sig=j PEC CSC CONNECT
Nov 15 20:07:39 nibbler kernel: hub 4-0:1.0: port 3, status 0501, change 0003, 
480 Mb/s
Nov 15 20:07:39 nibbler kernel: usb 4-3: USB disconnect, address 2
Nov 15 20:07:39 nibbler kernel: usb 4-3: usb_disable_device nuking all URBs
Nov 15 20:07:39 nibbler kernel: ehci_endpoint_disable:enter
Nov 15 20:07:39 nibbler kernel: ehci_endpoint_disable:exit
Nov 15 20:07:39 nibbler kernel: ehci_endpoint_disable:enter
Nov 15 20:07:39 nibbler kernel: ehci_endpoint_disable:exit
Nov 15 20:07:39 nibbler kernel: ehci_endpoint_disable:enter
Nov 15 20:07:39 nibbler kernel: ehci_endpoint_disable:exit
Nov 15 20:07:39 nibbler kernel: ehci_hcd :00:10.3: shutdown urb c6b55820 
pipe c0008280 ep1in-bulk
Nov 15 20:07:39 nibbler kernel: ehci_endpoint_disable:enter
Nov 15 20:27:30 nibbler -- MARK --
Nov 15 20:47:30 nibbler -- MARK --
Nov 15 21:07:31 nibbler -- MARK --
Nov 15 21:18:46 nibbler kernel:   c7291f5c 00bfa086 c7293f5c c728ff5c 
00bfa086 4b87ad6e c011e16d ccd10560 
Nov 15 21:18:46 nibbler kernel: Call Trace:
Nov 15 21:18:46 nibbler kernel:  [schedule_timeout+130/163] 
schedule_timeout+0x82/0xa3
Nov 15 21:18:46 nibbler kernel:  [process_timeout+0/9] process_timeout+0x0/0x9
Nov 15 21:18:46 nibbler kernel:  [pg0+257422591/1070355456] 
svc_recv+0x277/0x411 [sunrpc]
Nov 15 21:18:46 nibbler kernel:  [default_wake_function+0/18] 
default_wake_function+0x0/0x12
Nov 15 21:18:46 nibbler kernel:  [pg0+257737325/1070355456] nfsd+0xdc/0x2dd 
[nfsd]
Nov 15 21:18:46 nibbler kernel:  [pg0+257737105/1070355456] nfsd+0x0/0x2dd 
[nfsd]
Nov 15 21:18:46 nibbler kernel:  [kernel_thread_helper+5/11] 
kernel_thread_helper+0x5/0xb
Nov 15 21:18:46 nibbler kernel: nfsd  S 003D3369 0  5754  1 
 5755  5753 (L-TLB)
Nov 15 21:18:46 nibbler kernel: c7293f4c  cbda1600 003d3369 ccd10158 
ccd10030 cbda1600 003d3369 
Nov 15 21:18:46 nibbler kernel:  c0316ed8 c7293f5c 
00bfa086 cd290560 c7292000 c0261e67 
Nov 15 21:18:46 nibbler kernel:c7293f5c 00bfa086 c72b5f5c c7291f5c 
00bfa086 4b87ad6e c011e16d ccd10030 
Nov 15 21:18:46 nibbler kernel: Call Trace:
Nov 15 21:18:46 nibbler kernel:  [schedule_timeout+130/163] 
schedule_timeout+0x82/0xa3
Nov 15 21:18:46 nibbler kernel:  [process_timeout+0/9] process_timeout+0x0/0x9
Nov 15 21:18:46 nibbler kernel:  [pg0+257422591/1070355456] 
svc_recv+0x277/0x411 [sunrpc]
Nov 15 21:18:46 nibbler kernel:  [default_wake_function+0/18] 
default_wake_function+0x0/0x12
Nov 15 21:18:46 nibbler kernel:  [pg0+257737325/1070355456] nfsd+0xdc/0x2dd 
[nfsd]
Nov 15 21:18:46 nibbler kernel:  [pg0+257737105/1070355456] nfsd+0x0/0x2dd 
[nfsd]
Nov 15 21:18:46 nibbler kernel:  [kernel_thread_helper+5/11] 
kernel_thread_helper+0x5/0xb
Nov 15 21:18:46 nibbler kernel: nfsd  S 003D3369 0  5755  1 
 5756  5754 (L-TLB)
Nov 15 21:18:46 nibbler kernel: c72b5f4c  cbda1600 003d3369 c7239bd8 
c7239ab0 cbda1600 003d3369 
Nov 15 21:18:46 nibbler kernel:  c0316ed8 c72b5f5c 
00bfa086 c7bcdb60 c72b4000 c0261e67 
Nov 15 21:18:46 nibbler kernel:c72b5f5c 00bfa086 c72b7f5c c7293f5c 
00bfa086 4b87ad6e c011e16d c7239ab0 
Nov 15 21:18:46 nibbler kernel: Call Trace:
Nov 15 21:18:46 nibbler kernel:  [schedule_timeout+130/163] 
schedule_timeout+0x82/0xa3
Nov 15 21:18:46 nibbler kernel:  [process_timeout+0/9] process_timeout+0x0/0x9
Nov 15 21:18:46 nibbler kernel:  [pg0+257422591/1070355456] 
svc_recv+0x277/0x411 [sunrpc]
Nov 15 21:18:46 nibbler kernel:  [default_wake_function+0/18] 
default_wake_function+0x0/0x12
Nov 15 21:18:46 nibbler kernel:  [pg0+257737325/1070355456] nfsd+0xdc/0x2dd 
[nfsd]
Nov 15 21:18:46 nibbler kernel:  [pg0+257737105/1070355456] nfsd+0x0/0x2dd 
[nfsd]
Nov 15 21:18:46 nibbler kernel:  [kernel_thread_helper+5/11] 
kernel_thread_helper+0x5/0xb
Nov 15 21:18:46 nibbler kernel: nfsd  S 003D3369 0  5756  1 
 5757  5755 (L-TLB)
Nov 15 21:18:46 nibbler kernel: c72b7f4c  cbda1600 003d3369 c72396a8 
c7239580 cbda1600 0

[linux-usb-devel] usbmon question

2005-11-15 Thread Alan Stern 
Pete:

What is the reason for this comment and test in mon_text.c?

/*
 * Bulk is easy to shortcut reliably. 
 * XXX Other pipe types need consideration. Currently, we overdo it
 * and collect garbage for them: better more than less.
 */
if (usb_pipebulk(pipe) || usb_pipecontrol(pipe)) {
if (usb_pipein(pipe)) {
if (ev_type == 'S')
return '<';
} else {
if (ev_type == 'C')
return '>';
}
}

Surely that first test isn't needed at all.  Interrupt and isochronous 
transfers send data in or out in the same way as bulk and control.

Alan Stern



---
This SF.Net email is sponsored by the JBoss Inc.  Get Certified Today
Register for a JBoss Training Course.  Free Certification Exam
for All Training Attendees Through End of 2005. For more info visit:
http://ads.osdn.com/?ad_id=7628&alloc_id=16845&op=click
___
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] Problem with async bulk in a new driver

2005-11-15 Thread Alan Stern 
On Mon, 14 Nov 2005, Daniel Drake wrote:

> I'm sorry to throw a mass of sniffed data and early driver code at the list, 
> but I've been working on this problem for a few days now, with no success. 
> I'm 
> hoping that someone might be able to spot an obvious mistake or offer 
> suggestions on things to try :)

...

> My driver clones the sequence 1-6 just fine, but I don't get the response 
> from 
> either bulk command. I've noticed that despite this, the callback functions 
> *do* get executed when I unplug the device - is this normal?

Yes.  If an URB submission succeeds then the callback routine is 
guaranteed to be called eventually.

> The control commands work fine, I get the desired responses and the device 
> even visibly reacts to some commands (e.g. turning the light on). I'm 
> wondering if it's just something I'm doing wrong with bulk transfers, but 
> I've 
> looked over it a good few times now...

One bulk and one interrupt transfer, not two bulk.

> I'm attaching the UsbSnoop logs on the fingerprint interface, semi-annotated 
> Linux usbmon logs on the port when HID support is disabled (i.e. a sniff of 
> my 
> own driver), and the driver code so-far. I'm also attaching the "lsusb -v" 
> output for the device.

In answer to some of the things you mentioned in the usbmon log...

The initial portion is indeed irrelevant.  It shows the device detection
and address setup.  UsbSnoop might show you some of that stuff if you
traced the root hub.

The URB you labelled with just a '?' corresponds to URB 2 and the one
before it corresponds to URB 1 (read the entire configuration descriptor
and read just the first 9 bytes, respectively).  The three preceding URBs 
have no equivalent in Windows; they are meant to check for a high-speed 
capable device using only a full-speed connection.

But the data shown by usbmon is different from the data shown by UsbSnoop!  
The Linux data indicates the presence of 3 interfaces whereas the Windows
data indicates just 1.  Maybe Windows has filtered the data for you.

The Set-Configuration call isn't done that much later in Linux than in
Windows.  The only difference is that Windows reads the string descriptors
after Set-Config whereas Linux reads them before.

I didn't go through the details of the firmware transfer, but everything 
else looked correct.  It's not obvious why the device doesn't respond to 
your program.

The URB at the end was sent after your driver's probe routine returned.  
It was in response to the URB that completed way back at timestamp 
2984128892.

> I haven't focused much on what the other interfaces are doing, as they are 
> HID-compliant I don't think they are doing anything special, and I doubt (in 
> terms of implementing the components in the hardware) that sending commands 
> to 
> another interface would affect the fingerprint reader... I guess this is the 
> next thing to check, if nothing emerges at this point.

I would certainly be suspicious about the other interfaces.  Note that 
HID-compliant interfaces can receive reports as well as send them.

Alan Stern



---
This SF.Net email is sponsored by the JBoss Inc.  Get Certified Today
Register for a JBoss Training Course.  Free Certification Exam
for All Training Attendees Through End of 2005. For more info visit:
http://ads.osdn.com/?ad_id=7628&alloc_id=16845&op=click
___
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] Problem with async bulk in a new driver

2005-11-15 Thread gerard klaver 
On Mon, 2005-11-14 at 23:36 +, Daniel Drake wrote:
> I'm sorry to throw a mass of sniffed data and early driver code at the list, 
> but I've been working on this problem for a few days now, with no success. 
> I'm 
> hoping that someone might be able to spot an obvious mistake or offer 
> suggestions on things to try :)
> 
> I'm writing a driver for a fingerprint reader found in a USB keyboard.
> The keyboard has 3 interfaces, two HID (presumably one for keyboard and one 
> for wireless mouse), and one which is the fingerprint reader. I'm working on 
> a 
> driver for the 3rd interface, obviously.
> 
> The 3rd interface has two endpoints, one bulk in and one interrupt in.
> 
> The UsbSnoop log I'm attaching is from the 3rd interface and shows a sequence 
> of events like:
> 
> 1. configuration setting, descriptor fetching
> 2. a series of synchronous control commands
> 3. an async transfer down the bulk-in endpoint fired
> 4. an async interrupt transfer fired on the int-in endpoint
> 5. more control commands including upload of firmware
> 6. short pause
> 7. interrupt transfer from step 4 returns
> 8. re-fire interrupt
> 9. more control commands
> 10. pause
> 11. bulk command from step 3 returns
> 12. ...
> 
> My driver clones the sequence 1-6 just fine, but I don't get the response 
> from 
> either bulk command. I've noticed that despite this, the callback functions 
> *do* get executed when I unplug the device - is this normal?
> 
> The control commands work fine, I get the desired responses and the device 
> even visibly reacts to some commands (e.g. turning the light on). I'm 
> wondering if it's just something I'm doing wrong with bulk transfers, but 
> I've 
> looked over it a good few times now...
> 
> I'm attaching the UsbSnoop logs on the fingerprint interface, semi-annotated 
> Linux usbmon logs on the port when HID support is disabled (i.e. a sniff of 
> my 
> own driver), and the driver code so-far. I'm also attaching the "lsusb -v" 
> output for the device.
> 
> Note that the Windows driver gets the flag bits wrong in the bulk commands - 
> it appears to be sending data out of the in endpoints - this is apparently 
> common in Windows drivers, the windows API must fix that up automatically.
> 
> I haven't focused much on what the other interfaces are doing, as they are 
> HID-compliant I don't think they are doing anything special, and I doubt (in 
> terms of implementing the components in the hardware) that sending commands 
> to 
> another interface would affect the fingerprint reader... I guess this is the 
> next thing to check, if nothing emerges at this point.
> 
> I'd be very grateful to anyone who has any ideas here...
> 
> Thanks,
> Daniel


Did you set the configuration, interface and altsetting before the bulk
read command?

Also putting this info on a website is maybe a better idea for sharing
info.

No info about the used fingerprint chip i assume?

Depending on your plans for such a device, writing a sane backend could
be another option (scanner/webcam).

   
-- 

m.vr.gr.
Gerard Klaver



---
This SF.Net email is sponsored by the JBoss Inc.  Get Certified Today
Register for a JBoss Training Course.  Free Certification Exam
for All Training Attendees Through End of 2005. For more info visit:
http://ads.osdn.com/?ad_id=7628&alloc_id=16845&op=click
___
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 stack hangs after sporadic disconnect

2005-11-15 Thread Alan Stern 
On Tue, 15 Nov 2005, Jan Kiszka wrote:

> > And get that stack trace.  It's the best way to find the exact location of 
> > the problem.
> > 
> 
> Will the trace I request typically hours after the disconnect (I can't
> sit aside my box all the time...) still contain valuable information? Or
> should I better place some trace-triggering command at a prominent place?

If things do hang up the way you described, then the trace will still be 
useful even hours later.

Alan Stern



---
This SF.Net email is sponsored by the JBoss Inc.  Get Certified Today
Register for a JBoss Training Course.  Free Certification Exam
for All Training Attendees Through End of 2005. For more info visit:
http://ads.osdn.com/?ad_id=7628&alloc_id=16845&op=click
___
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 stack hangs after sporadic disconnect

2005-11-15 Thread Jan Kiszka 
Alan Stern wrote:
> On Tue, 15 Nov 2005, Jan Kiszka wrote:
> 
>> I placed some printks in the rt2570's disconnect routine. While I can
>> find them in the logs when I physically disconnect the stick, I did not
>> get them last night during another sporadic disconnect. So the
>> high-level driver seems to be out of the game regarding the stack
>> lock-up, doesn't it?
>>
>> I'm now trying if the situation changes without the ehci being loaded.
> 
> It could be that the problem is in the ehci_endpoint_disable routine in
> the EHCI driver; that would prevent the disconnect routine from getting
> called.  Maybe even the hang is caused by whatever caused the sporadic
> disconnect.  Try putting printk statements at the entry and exit points of
> that routine and see what you get.

Ok.

> 
> And get that stack trace.  It's the best way to find the exact location of 
> the problem.
> 

Will the trace I request typically hours after the disconnect (I can't
sit aside my box all the time...) still contain valuable information? Or
should I better place some trace-triggering command at a prominent place?

Jan



signature.asc
Description: OpenPGP digital signature

Re: [linux-usb-devel] USB stack hangs after sporadic disconnect

2005-11-15 Thread Alan Stern 
On Tue, 15 Nov 2005, Jan Kiszka wrote:

> I placed some printks in the rt2570's disconnect routine. While I can
> find them in the logs when I physically disconnect the stick, I did not
> get them last night during another sporadic disconnect. So the
> high-level driver seems to be out of the game regarding the stack
> lock-up, doesn't it?
> 
> I'm now trying if the situation changes without the ehci being loaded.

It could be that the problem is in the ehci_endpoint_disable routine in
the EHCI driver; that would prevent the disconnect routine from getting
called.  Maybe even the hang is caused by whatever caused the sporadic
disconnect.  Try putting printk statements at the entry and exit points of
that routine and see what you get.

And get that stack trace.  It's the best way to find the exact location of 
the problem.

Alan Stern



---
This SF.Net email is sponsored by the JBoss Inc.  Get Certified Today
Register for a JBoss Training Course.  Free Certification Exam
for All Training Attendees Through End of 2005. For more info visit:
http://ads.osdn.com/?ad_id=7628&alloc_id=16845&op=click
___
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] HELP: Problem with HP Laserjet 1022 and USB in Linux 2.6.12

2005-11-15 Thread Alan Stern 
On Tue, 15 Nov 2005, Neil Brown wrote:

> Yes, I think changing the IDLE_TIMEOUT does help.
> I think I now know enough about what is going on to decide that I have
> a good-enough fix, and that it won't get any better (with either
> berating HP to fix the printer, or using a USB2.0 interface).
> 
> It seems that the printer only accepts data packets during a small
> window ever 112msecs or so.  It is vital that we hit that window to
> get any sort of speed.
> 
> With the default timeout, we only through packets steadily at the
> printer for about 100ms. After that, we drop down to 1 per msec which
> makes the hit rate much worse.
> 
> So I've defined a new transfer_flag which disables the FSBR timeout,
> and a printer quirk for my printer what sets this flag.
> With this patch, I getting (barely) adequate performance - better than
> 2.4 and much better than standard 2.6.
> 
> Below is the patch - so if someone else has this problem they might
> find the patch on the mailing list archives.
> 
> I'll leave it up to you to decide if it should be submitted to
> mainline.

Not just now.

Can you get a usbmon log showing your change in action?  It would be 
interesting to see the time intervals involved.

It would also be worthwhile to see if you can get more or less the same 
effect without all those changes, just by increasing IDLE_TIMEOUT to 1000 
ms or something like that.

Alan Stern



---
This SF.Net email is sponsored by the JBoss Inc.  Get Certified Today
Register for a JBoss Training Course.  Free Certification Exam
for All Training Attendees Through End of 2005. For more info visit:
http://ads.osdn.com/?ad_id=7628&alloc_id=16845&op=click
___
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] problem with usb-skeleton driver while writing

2005-11-15 Thread Ushit Kumar 

Hi,

I am using the usb-skeleton driver as the model for a host driver for 
Neomagic's MM6 plus chip. I am using Centos release 3.4 (kernel 
2.4.21-27.0.1.EL on i686) and the host controller is uhci.


My problem is that I am unable to send data to the client device. The 
driver loads ok, it can be opened sucessfully, write call goes through, 
address of the endpoint is correct and the data to be transmitted is 
sent correctly from application to driver.


I have created a small application that opens the usb-skel driver, and 
attempts to send "Hello World" string to the MM6 plus board. The call to 
usb_submit_urb goes through without any errors. However the 
skel_write_bulk_callback reports an error code of -2 (ENONENT). My 
understanding is that this means that the URB was cancelled.


One other strange thing. I can send my string across to the other side, 
if I run my sample program several times.


What could be the problem.

TIA,

Ushit



---
This SF.Net email is sponsored by the JBoss Inc.  Get Certified Today
Register for a JBoss Training Course.  Free Certification Exam
for All Training Attendees Through End of 2005. For more info visit:
http://ads.osdn.com/?ad_id=7628&alloc_id=16845&op=click
___
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] Re: USB patches for 2.6.15-rc1??

2005-11-15 Thread David Kubicek 
On Mon, Nov 14, 2005 at 12:09:24PM -0800, Greg Kroah-Hartman wrote:
> On Mon, Nov 14, 2005 at 12:04:56PM -0800, Greg Kroah-Hartman wrote:
> > Here are a few USB patches against your latest git tree, they have all
> > been in the past few -mm releases just fine.  They fix some build bugs,
> > add some new device ids, and add a new simple usb-serial driver.
> 
> Oh, forgot the combined diffstat of the whole series, sorry about that:
> 
>  Documentation/devices.txt|   12 
>  Documentation/usb/bluetooth.txt  |   45 --
>  drivers/usb/core/devio.c |5 
>  drivers/usb/core/inode.c |8 
>  drivers/usb/core/message.c   |4 
>  drivers/usb/gadget/dummy_hcd.c   |5 
>  drivers/usb/input/hid-core.c |   13 
>  drivers/usb/input/wacom.c|  134 +-
>  drivers/usb/serial/ChangeLog.history |  730 
> ++
>  drivers/usb/serial/ChangeLog.old |  731 
> ---
>  drivers/usb/serial/Kconfig   |9 
>  drivers/usb/serial/Makefile  |1 
>  drivers/usb/serial/anydata.c |  123 +
>  drivers/usb/serial/cp2101.c  |2 
>  drivers/usb/serial/generic.c |2 
>  drivers/usb/storage/Kconfig  |3 
>  drivers/usb/storage/unusual_devs.h   |6 
>  17 files changed, 1000 insertions(+), 833 deletions(-)

Hi Greg,

may I ask you what about the "URB/buffer ring queue" patch I've
submitted months ago for CDC ACM modems and which you accepted into your
tree when Oliver sent it to you for merging like a week ago? We (tens of
thousands of users in Czech Rep.) are anxiously waiting for this patch
for almost three release cycles to be merged and still nothing
happens... I spent some time finding out the issue and fixing it for the
benefit of all broadband users in CR, who were quite happy that they
will be able to use their connection fully - most of them dual boots to
Windows if they want full speed!! (Horror!:)) The patch was extremely
tested, audited by two people, please - could you do it for us?

There is, maybe, possibly usable sped-up generic usb-serial version, but
I reckon that for CDC ACM modems should be used CDC ACM driver, when
available. And when it is available, it should also be usable as much as
possible - this includes transfer rates over 256kbits/s, which are quite
common (ten times that, actually!). Not to mention that you can't do
some important things with just the data-channel of the generic iface...

Thank you for your consideration,
David

-- 
David Kubíček
System Specialist

gedas ČR s.r.o.
Mladá Boleslav, Husova 217
Phone:  (420) 326 329 359
Mobile: (420) 724 073 280
Email:  [EMAIL PROTECTED]
Web:http://www.awk.cz


---
This SF.Net email is sponsored by the JBoss Inc.  Get Certified Today
Register for a JBoss Training Course.  Free Certification Exam
for All Training Attendees Through End of 2005. For more info visit:
http://ads.osdn.com/?ad_id=7628&alloc_id=16845&op=click
___
linux-usb-devel@lists.sourceforge.net
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel