Re: [linux-usb-devel] Possible bug in isp116x-hcd
Hi Alan,
Index: usb-2.6/drivers/usb/host/isp116x-hcd.c
===
--- usb-2.6.orig/drivers/usb/host/isp116x-hcd.c
+++ usb-2.6/drivers/usb/host/isp116x-hcd.c
@@ -583,12 +583,15 @@ static void
finish_atl_transfers(struct
unpack_fifo(isp116x);
postproc_atl_queue(isp116x);
I think it is guaranteed that at this point all the ep's in
active ATL queue have their urb_list non-empty. There's a
relevant BUG_ON() in postproc_atl_queue(). The list_empty()
check below would be unnecessary.
for (ep = isp116x-atl_active; ep; ep = ep-active)
{
+ if (list_empty(ep-hep-urb_list))
+ continue;
urb =
container_of(ep-hep-urb_list.next,
struct urb, urb_list);
+
/* USB_PID_ACK check here avoids finishing of
control transfers, for which TD_DATAUNDERRUN
occured, while URB_SHORT_NOT_OK was set */
- if (urb urb-status != -EINPROGRESS
^^^
Yes, this is wrong. Thanks. As you are already at it, please
remove it.
+ if (urb-status != -EINPROGRESS
ep-nextpid != USB_PID_ACK)
finish_request(isp116x, ep, urb);
}
Olav
-
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] USB: cdc-subset.c support for new vendor/product ID
Hi,
Not sure whether this is the right place to submit the patch for
adding new vendor/product ID support.
Could anyone help or point to the right way?
--- driver/usb/net/cdc_subset.c.orig2007-06-14 19:45:52.062473040 +0800
+++ driver/usb/net/cdc_subset.c 2007-06-14 18:38:35.217166808 +0800
/*-*/
@@ -305,6 +305,9 @@ static const struct usb_device_id produc
USB_DEVICE (0x8086, 0x07d3),// blob bootloader
.driver_info = (unsigned long) blob_info,
}, {
+ USB_DEVICE (0x1286, 0x8001),// blob bootloader
+ .driver_info = (unsigned long) blob_info,
+}, {
// Linux Ethernet/RNDIS gadget on pxa210/25x/26x, second config
// e.g. Gumstix, current OpenZaurus, ...
USB_DEVICE_VER (0x0525, 0xa4a2, 0x0203, 0x0203),
Thanks a lot!
Jing
-
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] logs being spammed
Greetings folks; I had a message from sa_update this morning that prompted me to look at dmesg to see if anything made sense there. Anyway, I find dmesg and the messages log are being spammed with this although the applications seem to be running tolerably well: usb 3-3.4.3: hald-addon-usb- timed out on ep0in len=8/8 usb 3-3.4.3: hald-addon-usb- timed out on ep0in len=8/8 usb 3-3.4.3: hald-addon-usb- timed out on ep0in len=8/8 usb 3-3.4.3: hald-addon-usb- timed out on ep0in len=8/8 usb_endpoint usbdev3.11_ep81: ep_device_release called for usbdev3.11_ep81 usb_endpoint usbdev3.11_ep82: ep_device_release called for usbdev3.11_ep82 usb_endpoint usbdev3.11_ep03: ep_device_release called for usbdev3.11_ep03 usb 3-3.4.4: manual set_interface for iface 0, alt 0 usb_endpoint usbdev3.11_ep81: ep_device_release called for usbdev3.11_ep81 usb_endpoint usbdev3.11_ep82: ep_device_release called for usbdev3.11_ep82 usb_endpoint usbdev3.11_ep03: ep_device_release called for usbdev3.11_ep03 usb_endpoint usbdev3.11_ep81: ep_device_release called for usbdev3.11_ep81 usb_endpoint usbdev3.11_ep82: ep_device_release called for usbdev3.11_ep82 usb_endpoint usbdev3.11_ep03: ep_device_release called for usbdev3.11_ep03 usb 3-3.4.4: manual set_interface for iface 0, alt 0 usb_endpoint usbdev3.11_ep81: ep_device_release called for usbdev3.11_ep81 usb_endpoint usbdev3.11_ep82: ep_device_release called for usbdev3.11_ep82 usb_endpoint usbdev3.11_ep03: ep_device_release called for usbdev3.11_ep03 usb 3-3.4.3: hald-addon-usb- timed out on ep0in len=8/8 usb 3-3.4.3: hald-addon-usb- timed out on ep0in len=8/8 usb 3-3.4.3: hald-addon-usb- timed out on ep0in len=8/8 usb 3-3.4.3: hald-addon-usb- timed out on ep0in len=8/8 usb 3-3.4.3: hald-addon-usb- timed out on ep0in len=8/8 usb 3-3.4.3: hald-addon-usb- timed out on ep0in len=8/8 usb 3-3.4.3: hald-addon-usb- timed out on ep0in len=8/8 Can anyone comment? kernel is locally built 2.6.22-rc4, amd xp-2800, gig of ram. -- Cheers, Gene There are four boxes to be used in defense of liberty: soap, ballot, jury, and ammo. Please use in that order. -Ed Howdershelt (Author) The time is right to make new friends. - 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] [RFC] Eliminate usb_unlink_urb()'s return code
On Wednesday 13 June 2007, Alan Stern wrote: Dave and everyone else: The meaning of the return value from usb_unlink_urb() is not as clear as it should be. The value is used in only a handful of drivers, mostly for debugging output. David's code uses it for warnings and error messages, but not for altering the control flow. It's unclear what should be done, other than print diagnostics. The real question is this: Under what conditions does it make sense to say that usb_unlink_urb() has failed? If it fails. ;) Since the call races against URB completion, I think it never really makes sense. Here's a more detailed examination of the possibilities. Consider what happens when an URB is submitted: 0. Initially the URB is unlinked and idle. 1. The URB gets submitted and linked. 2. The URB is passed to the HCD, which enqueues it. 3. The URB completes and is dequeued by the HCD. 4. The URB is unlinked and passed to the completion routine. 5. The URB is once again idle (or it may be resubmitted). That's the typical flow, yep. No unlink/kill/etc. The only difference between #4 and #5 is of course a refcount; the URB becomes idle at some point on its way into the completion routine, at which point it can be resubmitted. The refcount is kept (starting at #1) to ensure the URB is not prematurely freed. Now consider what happens if usb_unlink_urb() is called just after each step above: The parenthesis indicating the unlink() result... 0. Nothing happens since the URB is idle. (Error) Since you say the after-#5 is the same as this, I'd not call it an error. It's a fault, sure ... but any error comes from a caller doing something that's defined to not succeed. When code does what it's defined to do, that's not an error. :) 1. This is the tricky part. We want the submission to fail but it hasn't finished yet. The URB is marked so that the HCD will recognize it has already been unlinked, and the enqueue call will fail. (Error?) Either of two outcomes could work, preserving the invariant that URBs are submitted exactly once and then completed either by normal I/O completion or else by unlink: - Submit succeeds, unlink does too (returning -ECONNRESET or whatever); - Neither call succeeds ... submit is aborted (though probably for puzzling reason), unlink does since this becomes case #0. The first of these makes a lot more sense to me, at this point, since nothing another thread does should make the submit fail unless the endpoint vanishes. You seem to be assuming the other path, which I'd normally file under very surprising behavior from a programming interface. Now, ISTR that when implementing this the first time, there was something preventing the sanest behavior here. I forget the details, but I know the relevant interfaces have since been at least partially fixed up. 2. The HCD's dequeue routine works in the usual way. (Success) Standard behavior. 3. The HCD's dequeue routine fails since the URB has already been dequeued. (Error?) The unlink shouldn't succeed, since the URB has completed in every sense except the trivial one of finishing giveback(). Note that you're combining completes and dequeues into one step, which doesn't really match my understanding. The two are can not be coupled atomic operations!! First completion happens (URB status becomes known, and is recorded). At some later point -- probably after recycling at least one TD, and other cleanup of HCD state including internal queues -- the URB starts its journey back to the driver. As soon as the status became known, the HCD has committed to returning the URB with that status, and the core accelerate completion of unlink() could no longer kick in. That real I/O status should never be replaced by a false unlinked status code. And before that hardware status is detected, we're still in the after step #2 case. It's unfortunate that sometimes that means discarding useful hardware status reports... since the unlink() status would override hardware status which might not yet have been collected. (Because for example maybe the relevant IRQ was being held off by locking during the unlink.) 4. The unlink call fails since the URB is no longer linked. (Error?) As above for #3, except that the urb got further into its journey back to the driver. 5. Same as 0. Sounds right. 0 is clearly an error and 2 is clearly a success. The others aren't so clear. I disagree. For #3 and #4 it's very clear: the URB has started to complete normally. Since unlink is nothing more than a way to kick in a software fault to accelerate the URB completion, the unlink can't succeed: there is nothing to accelerate, it's already going back and with some real status! And as you say, #5 is #0... leaving only #1 as potentially confusing.
Re: [linux-usb-devel] Possible bug in isp116x-hcd
On Thu, 14 Jun 2007, Olav Kongas wrote:
Hi Alan,
Index: usb-2.6/drivers/usb/host/isp116x-hcd.c
===
--- usb-2.6.orig/drivers/usb/host/isp116x-hcd.c
+++ usb-2.6/drivers/usb/host/isp116x-hcd.c
@@ -583,12 +583,15 @@ static void
finish_atl_transfers(struct
unpack_fifo(isp116x);
postproc_atl_queue(isp116x);
I think it is guaranteed that at this point all the ep's in
active ATL queue have their urb_list non-empty. There's a
relevant BUG_ON() in postproc_atl_queue(). The list_empty()
check below would be unnecessary.
I'll remove the list_empty() test.
for (ep = isp116x-atl_active; ep; ep = ep-active)
{
+ if (list_empty(ep-hep-urb_list))
+ continue;
urb =
container_of(ep-hep-urb_list.next,
struct urb, urb_list);
+
/* USB_PID_ACK check here avoids finishing of
control transfers, for which TD_DATAUNDERRUN
occured, while URB_SHORT_NOT_OK was set */
- if (urb urb-status != -EINPROGRESS
^^^
Yes, this is wrong. Thanks. As you are already at it, please
remove it.
Will do. Thanks for the feedback.
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] logs being spammed
On Thu, 14 Jun 2007, Gene Heskett wrote: Greetings folks; I had a message from sa_update this morning that prompted me to look at dmesg to see if anything made sense there. Anyway, I find dmesg and the messages log are being spammed with this although the applications seem to be running tolerably well: usb 3-3.4.3: hald-addon-usb- timed out on ep0in len=8/8 usb 3-3.4.3: hald-addon-usb- timed out on ep0in len=8/8 usb 3-3.4.3: hald-addon-usb- timed out on ep0in len=8/8 usb 3-3.4.3: hald-addon-usb- timed out on ep0in len=8/8 usb_endpoint usbdev3.11_ep81: ep_device_release called for usbdev3.11_ep81 usb_endpoint usbdev3.11_ep82: ep_device_release called for usbdev3.11_ep82 usb_endpoint usbdev3.11_ep03: ep_device_release called for usbdev3.11_ep03 usb 3-3.4.4: manual set_interface for iface 0, alt 0 ... Can anyone comment? kernel is locally built 2.6.22-rc4, amd xp-2800, gig of ram. These are all debugging messages. You can get rid of them by turning off CONFIG_USB_DEBUG. 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] [2/2] 2.6.22-rc4: known regressions v3
Hi all, The random seg faults on x86_64 is interesting as I have been getting random illegal instruction faults on sparc (sun4c) with 2.6.22-rc3. I have not yet tried to track it down. All I know at present is that it is not a problem on 2.6.20.9. Regards Mark Fortescue. On Wed, 13 Jun 2007, Michal Piotrowski wrote: Hi all, Here is a list of some known regressions in 2.6.22-rc4. Feel free to add new regressions/remove fixed etc. http://kernelnewbies.org/known_regressions Networking Subject: commit 9093bbb2d96d0184f037cea9b4e952a44ebe7c32 broke the bonding driver References : http://lkml.org/lkml/2007/6/13/65 Submitter : Dan Aloni [EMAIL PROTECTED] Handled-By : Stephen Hemminger [EMAIL PROTECTED] Status : Unknown Sparc64 Subject: 2.6.22-rc broke X on Ultra5 References : http://lkml.org/lkml/2007/5/22/78 Submitter : Mikael Pettersson [EMAIL PROTECTED] Handled-By : David Miller [EMAIL PROTECTED] Status : problem is being debugged Suspend Subject: hibernate(?) fails totally - regression References : http://lkml.org/lkml/2007/6/1/401 Submitter : David Greaves [EMAIL PROTECTED] Handled-By : Rafael J. Wysocki [EMAIL PROTECTED] Caused-By : Tejun Heo [EMAIL PROTECTED] commit 9666f4009c22f6520ac3fb8a19c9e32ab973e828 Status : problem is being debugged TTY Subject: OOPS (NULL pointer dereference) in v2.6.22-rc3 References : http://lkml.org/lkml/2007/6/1/389 http://bugzilla.kernel.org/show_bug.cgi?id=8473 http://bugzilla.kernel.org/show_bug.cgi?id=8574 Submitter : Alex Riesen [EMAIL PROTECTED] Status : problem is being debugged x86-64 Subject: x86-64 2.6.22-rc2 random segfaults References : http://lkml.org/lkml/2007/5/24/275 Submitter : Ioan Ionita [EMAIL PROTECTED] Status : Unknown Regards, Michal -- LOG http://www.stardust.webpages.pl/log/ - To unsubscribe from this list: send the line unsubscribe sparclinux in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html - 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/2] 2.6.22-rc4: known regressions v3
Hi all, Here is a list of some known regressions in 2.6.22-rc4. Feel free to add new regressions/remove fixed etc. http://kernelnewbies.org/known_regressions Networking Subject: commit 9093bbb2d96d0184f037cea9b4e952a44ebe7c32 broke the bonding driver References : http://lkml.org/lkml/2007/6/13/65 Submitter : Dan Aloni [EMAIL PROTECTED] Handled-By : Stephen Hemminger [EMAIL PROTECTED] Status : Unknown Sparc64 Subject: 2.6.22-rc broke X on Ultra5 References : http://lkml.org/lkml/2007/5/22/78 Submitter : Mikael Pettersson [EMAIL PROTECTED] Handled-By : David Miller [EMAIL PROTECTED] Status : problem is being debugged Suspend Subject: hibernate(?) fails totally - regression References : http://lkml.org/lkml/2007/6/1/401 Submitter : David Greaves [EMAIL PROTECTED] Handled-By : Rafael J. Wysocki [EMAIL PROTECTED] Caused-By : Tejun Heo [EMAIL PROTECTED] commit 9666f4009c22f6520ac3fb8a19c9e32ab973e828 Status : problem is being debugged TTY Subject: OOPS (NULL pointer dereference) in v2.6.22-rc3 References : http://lkml.org/lkml/2007/6/1/389 http://bugzilla.kernel.org/show_bug.cgi?id=8473 http://bugzilla.kernel.org/show_bug.cgi?id=8574 Submitter : Alex Riesen [EMAIL PROTECTED] Status : problem is being debugged x86-64 Subject: x86-64 2.6.22-rc2 random segfaults References : http://lkml.org/lkml/2007/5/24/275 Submitter : Ioan Ionita [EMAIL PROTECTED] Status : Unknown Regards, Michal -- LOG http://www.stardust.webpages.pl/log/ - 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/2] 2.6.22-rc4: known regressions v3
On 2007.06.13 21:57:56 +0200, Michal Piotrowski wrote: TTY Subject: OOPS (NULL pointer dereference) in v2.6.22-rc3 References : http://lkml.org/lkml/2007/6/1/389 http://bugzilla.kernel.org/show_bug.cgi?id=8473 http://bugzilla.kernel.org/show_bug.cgi?id=8574 Submitter : Alex Riesen [EMAIL PROTECTED] Status : problem is being debugged Patch available at: http://lkml.org/lkml/2007/6/8/490 Björn - 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/2] 2.6.22-rc4: known regressions v3
On 13/06/07, Björn Steinbrink [EMAIL PROTECTED] wrote: On 2007.06.13 21:57:56 +0200, Michal Piotrowski wrote: TTY Subject: OOPS (NULL pointer dereference) in v2.6.22-rc3 References : http://lkml.org/lkml/2007/6/1/389 http://bugzilla.kernel.org/show_bug.cgi?id=8473 http://bugzilla.kernel.org/show_bug.cgi?id=8574 Submitter : Alex Riesen [EMAIL PROTECTED] Status : problem is being debugged Patch available at: http://lkml.org/lkml/2007/6/8/490 Thanks for letting me know. Regards, Michal -- LOG http://www.stardust.webpages.pl/log/ - 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/2] 2.6.22-rc4: known regressions v3
On Wed, Jun 13, 2007 at 11:25:20PM +0100, Mark Fortescue wrote: The random seg faults on x86_64 is interesting as I have been getting random illegal instruction faults on sparc (sun4c) with 2.6.22-rc3. I have not yet tried to track it down. All I know at present is that it is not a problem on 2.6.20.9. Very interesting. Any hints as to how to test or how long to wait before the illegal instructions happen? -- wli - 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/2] 2.6.22-rc4: known regressions v3
Hi All, They apear as soon as simpleinit starts up. Somtimes I get to a login prompt before seeing any. Other times, commands in the simpleinit rc script fail. They do apear to be random. If a command failes, you re-run the command and it is OK. Commands seen to fail are basic (depmod, rm cat ..). The test I did use the same binaries with both the OK and problem kernels so it is not a change to the application code, it is definatly a kernel issue. Regards Mark Fortescue. On Wed, 13 Jun 2007, William Lee Irwin III wrote: On Wed, Jun 13, 2007 at 11:25:20PM +0100, Mark Fortescue wrote: The random seg faults on x86_64 is interesting as I have been getting random illegal instruction faults on sparc (sun4c) with 2.6.22-rc3. I have not yet tried to track it down. All I know at present is that it is not a problem on 2.6.20.9. Very interesting. Any hints as to how to test or how long to wait before the illegal instructions happen? -- wli - 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/2] 2.6.22-rc4: known regressions v3
On Thu, Jun 14, 2007 at 11:30:25AM +0100, Mark Fortescue wrote: They apear as soon as simpleinit starts up. Somtimes I get to a login prompt before seeing any. Other times, commands in the simpleinit rc script fail. They do apear to be random. If a command failes, you re-run the command and it is OK. Commands seen to fail are basic (depmod, rm cat ..). The test I did use the same binaries with both the OK and problem kernels so it is not a change to the application code, it is definatly a kernel issue. This sounds like it may be addressed by benh's ptep_set_access_flags() fixes. Those fixes are still in -mm, hopefully to hit mainline by 2.6.22. -- wli - 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] Fw: [Bugme-new] [Bug 8628] New: EHCI handoff, because others reported bugs not solve my problem
Begin forwarded message: Date: Thu, 14 Jun 2007 07:15:44 -0700 (PDT) From: [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: [Bugme-new] [Bug 8628] New: EHCI handoff, because others reported bugs not solve my problem http://bugzilla.kernel.org/show_bug.cgi?id=8628 Summary: EHCI handoff, because others reported bugs not solve my problem Product: Drivers Version: 2.5 KernelVersion: 2.6.22-rc3 Platform: All OS/Version: Linux Tree: Mainline Status: NEW Severity: normal Priority: P1 Component: USB AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] Most recent kernel where this bug did not occur: 2.4.33 in my Slackware 11. Hahaha Distribution: Gentoo Hardware Environment: HP Pavilion dv5000 CTO Notebook PC, 1GB RAM, Motherboard Intel, i686 Genuine Intel(R) CPU T2050 @ 1.60GHz GenuineIntel SMP Software Environment: gcc version 4.1.2 (Gentoo 4.1.2) Problem Description: My boot cold behind of line io scheduler cfq registered. Ok, none of new, but I debuged the code of pci-quirks.c of my kernel and detected the code that cold my boot. I attachment the code of bug. Hum, I updated my BIOS to last version (2007-05-25). My BIOS is a PhoenixBios, WinFlash (very sux). The patch http://bugzilla.kernel.org/show_bug.cgi?id=6011#c12 not solve my problem, continuos cold my boot PS.: My english is sux, sorry! -- Configure bugmail: http://bugzilla.kernel.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug, or are watching someone who is. - 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] [RFC] Eliminate usb_unlink_urb()'s return code
On Thu, 14 Jun 2007, David Brownell wrote: On Wednesday 13 June 2007, Alan Stern wrote: Dave and everyone else: The meaning of the return value from usb_unlink_urb() is not as clear as it should be. The value is used in only a handful of drivers, mostly for debugging output. David's code uses it for warnings and error messages, but not for altering the control flow. It's unclear what should be done, other than print diagnostics. Quite. That was what made me think of eliminating the return code. Since the call races against URB completion, I think it never really makes sense. Here's a more detailed examination of the possibilities. Consider what happens when an URB is submitted: 0. Initially the URB is unlinked and idle. 1. The URB gets submitted and linked. 2. The URB is passed to the HCD, which enqueues it. 3. The URB completes and is dequeued by the HCD. 4. The URB is unlinked and passed to the completion routine. 5. The URB is once again idle (or it may be resubmitted). That's the typical flow, yep. No unlink/kill/etc. The only difference between #4 and #5 is of course a refcount; the URB becomes idle at some point on its way into the completion routine, at which point it can be resubmitted. The refcount is kept (starting at #1) to ensure the URB is not prematurely freed. Right. Now consider what happens if usb_unlink_urb() is called just after each step above: The parenthesis indicating the unlink() result... 0. Nothing happens since the URB is idle. (Error) Since you say the after-#5 is the same as this, I'd not call it an error. It's a fault, sure ... but any error comes from a caller doing something that's defined to not succeed. When code does what it's defined to do, that's not an error. :) Error in the sense of returning a negative errno value. But I agree that fault is a better term. 1. This is the tricky part. We want the submission to fail but it hasn't finished yet. The URB is marked so that the HCD will recognize it has already been unlinked, and the enqueue call will fail. (Error?) Either of two outcomes could work, preserving the invariant that URBs are submitted exactly once and then completed either by normal I/O completion or else by unlink: - Submit succeeds, unlink does too (returning -ECONNRESET or whatever); - Neither call succeeds ... submit is aborted (though probably for puzzling reason), unlink does since this becomes case #0. Agreed. The first of these makes a lot more sense to me, at this point, since nothing another thread does should make the submit fail unless the endpoint vanishes. You seem to be assuming the other path, which I'd normally file under very surprising behavior from a programming interface. Yes, it could be confusing. On the other hand, it occurs under confusing circumstances: when an unlink is unsynchronized with a submit and arrives at just the wrong time. In a way this falls under the you get what you deserve heading... Now, ISTR that when implementing this the first time, there was something preventing the sanest behavior here. I forget the details, but I know the relevant interfaces have since been at least partially fixed up. By now the interfaces certainly ought to be in good shape! 2. The HCD's dequeue routine works in the usual way. (Success) Standard behavior. 3. The HCD's dequeue routine fails since the URB has already been dequeued. (Error?) The unlink shouldn't succeed, since the URB has completed in every sense except the trivial one of finishing giveback(). Note that you're combining completes and dequeues into one step, which doesn't really match my understanding. The two are can not be coupled atomic operations!! First completion happens (URB status becomes known, and is recorded). At some later point -- probably after recycling at least one TD, and other cleanup of HCD state including internal queues -- the URB starts its journey back to the driver. Although the two events aren't truly atomic, they generally occur under the protection of a single spinlock. That is, while holding the spinlock the HCD learns that the URB is complete, and then while still holding the lock it dequeues the URB and gets ready to send it back to the driver. That's close enough to atomic for my purposes. As soon as the status became known, the HCD has committed to returning the URB with that status, and the core accelerate completion of unlink() could no longer kick in. That real I/O status should never be replaced by a false unlinked status code. That's another part of the API which has never been made clear. I wouldn't be surprised if HCDs were inconsistent in this regard. As part of my changes, I'll insure that unlink doesn't change the status of a completed URB. And before that hardware
Re: [linux-usb-devel] [RFC] Eliminate usb_unlink_urb()'s return code
On Thursday 14 June 2007, Alan Stern wrote: On Thu, 14 Jun 2007, David Brownell wrote: And before that hardware status is detected, we're still in the after step #2 case. It's unfortunate that sometimes that means discarding useful hardware status reports... since the unlink() status would override hardware status which might not yet have been collected. (Because for example maybe the relevant IRQ was being held off by locking during the unlink.) The unlink status doesn't have to override hardware status reports, not even ones which haven't yet been collected. If there is a relevant IRQ pending, the giveback must not occur until the IRQ has been serviced -- in which case the status from the hardware would be available in time to override the unlink status. That implies you're removing unlink() return codes, yes? Because if it doesn't override status that's not yet been reported, then you would be wrongly reporting success for the unlink() ... since the URB wouldn't report itself as unlinked in complete(), but the unlink would have reported success. In particular, in 1 can we say that the URB was unlinked when strictly speaking it never got fully submitted to begin with? If the submit() succeeds, then there are only two ways for that URB to complete: (a) normally due to I/O completion, fault or normal; and (b) unlink, which is a fault triggered by the software. As I noted above, letting the unlink() prevent the submit() from succeeding seems like a pretty dubious model. But it might have become less surprising due to the way kill() can now change the URB lifecycle. The reason for using the both fail approach is that it's much simpler. A single test can fail the submit right at the beginning, with no need for a spurious code path which simulates a submit followed by an immediate giveback. There's less to go wrong and it runs more quickly. I guess I don't follow that argument. The issue here is that the queue is partly managed by usbcore, so there's a window between usbcore marking the URB as queued and then the HCD sticking it onto the hardware queue. So long as that window exists, unlink requests can sneak into that window. There's no simulation of a submit; the code path is the normal one, not a spurious one. At this point it might be possible to refactor things though... With the CRIS HCD gone, the remaining legacy HCD infrastructure can finally be removed. We *could* move responsibility for the per-endpoint queue entirely into HCDs, except for the head of the unlink() code path ... exposing the per-HCD spinlock used to protect that queue (and related stuff). And that's all without giving up the advantages of knowing where each endpoint's queue is located, so usbcore can look at it etc. That would let us get rid of case #1 entirely, including its messiness for unlinking ... also get rid of corresponding oddness on the giveback() paths. A net cleanup, which would unfortunately affect every HCD (including ones which have not yet merged upstream, sigh). One way to reduce drivers' confusion would be to have the submit call for the pre-empted URB return -EPERM. That's what usb_kill_urb would normally cause to happen and so many drivers are accustomed to it. Drivers calling usb_unlink_urb from a different thread, not synchronized with URB submission, ought to expect strange things to happen occasionally. If documented properly it should be acceptable. True enough. Now that kill() has that EPERM path, unlink() can do the same thing if that makes anything simpler. However, adding more fault paths seems to me like the wrong direction. That's what usbtest does, for example ... when it loses either of the internal races (before HW gets the URB, or after I/O has finished but before it's been handed back to the driver) it acts differently ... the test can't terminate until a real unlink happens (and shouldn't). It never triggers cases #0/#5; the case #2 is how the test exits. So usbtest in particular needs to know whether an URB really did undergo accelerated completion. Can't it tell from the final URB status? Case #2 will be the only way for usb-status to be set to -ECONNRESET. What matters here is testability of the interface. What are you proposing here, exactly, for the test? Remember that the reason for that loop resubmitting-in-completion is that it's hard to trigger unlinks. And those unlink paths are in serious need of testing, since they don't happen all that often, and historically are *very* bug-prone parts of HCDs. That makes three outcomes needed by async unlink: error because of driver screwup; success, accelerated completion coming any moment now; fault due to race lost, normal completion coming any moment now. If I take my preferred approach to #1 it would get its own code: race with submission, submission preempted. I'm still not sure whether that
Re: [linux-usb-devel] [RFC] Eliminate usb_unlink_urb()'s return code
On Thu, 14 Jun 2007, David Brownell wrote:
The unlink status doesn't have to override hardware status reports, not
even ones which haven't yet been collected. If there is a relevant IRQ
pending, the giveback must not occur until the IRQ has been serviced --
in which case the status from the hardware would be available in time
to override the unlink status.
That implies you're removing unlink() return codes, yes? Because
if it doesn't override status that's not yet been reported, then
you would be wrongly reporting success for the unlink() ... since
the URB wouldn't report itself as unlinked in complete(), but the
unlink would have reported success.
I should have been more clear about this... Yes, there is a
possibility that an unlink call can apparently succeed and yet the
hardware could complete the URB normally before the accelerated
completion kicks in. In the spirit of giving the driver all the
information available from the hardware, I think that the URB's final
status should reflect the normal completion (i.e., should be 0 or a
hardware/protocol error code, not -ECONNRESET or -ENOENT).
At unlink time there's no way to know if this will happen. Whether
reporting success for the unlink would be wrong is a matter of
judgment; after all, the unlink did what it was supposed to and the URB
completed promptly. I don't like the idea of returning an error status
for an URB that completely successfully at the hardware level.
Neither alternative is very satisfying... Which reminds me, ehci-hcd
doesn't try very hard (if at all!) to accelerate the completion of
unlinked Iso transfers. So shouldn't it return an error code for the
unlink attempt?
The reason for using the both fail approach is that it's much
simpler. A single test can fail the submit right at the beginning,
with no need for a spurious code path which simulates a submit
followed by an immediate giveback. There's less to go wrong and it
runs more quickly.
I guess I don't follow that argument. The issue here is that
the queue is partly managed by usbcore, so there's a window
between usbcore marking the URB as queued and then the HCD
sticking it onto the hardware queue.
Exactly. That's what I referred to earlier as the somewhat artificial
distinction between an URB being linked and enqueued.
So long as that window exists, unlink requests can sneak into
that window. There's no simulation of a submit; the code
path is the normal one, not a spurious one.
(Nitpicking: No, there really is a separate code path in many of the
HCDs. For example, in sl811h_urb_enqueue() there is:
/* in case of unlink-during-submit */
spin_lock(urb-lock);
if (urb-status != -EINPROGRESS) {
spin_unlock(urb-lock);
finish_request(sl811, ep, urb, 0);
retval = 0;
goto fail;
}
I don't know very much about that driver, but at first glance it seems
possible that this path doesn't stop the endpoint queue -- which would
be a bug.)
At this point it might be possible to refactor things though...
With the CRIS HCD gone, the remaining legacy HCD infrastructure
can finally be removed.
Hah! You're talking about stuff from before I started working on
usbcore. What parts of the HCD infrastructure count as legacy
nowadays?
(And speaking of bizarre HCDs, what's the story on u132-hcd.c? Is it
likely ever to be cleaned up?)
We *could* move responsibility for
the per-endpoint queue entirely into HCDs, except for the head
of the unlink() code path ... exposing the per-HCD spinlock
used to protect that queue (and related stuff).
Yes. Note that hcd_data_lock isn't per-HCD, even though it ought to
be. If it were then we wouldn't have to expose anything.
And that's
all without giving up the advantages of knowing where each
endpoint's queue is located, so usbcore can look at it etc.
That would let us get rid of case #1 entirely, including its
messiness for unlinking ... also get rid of corresponding
oddness on the giveback() paths. A net cleanup, which would
unfortunately affect every HCD (including ones which have
not yet merged upstream, sigh).
Well, the stuff I'm working on affects all the HCDs anyway. This would
just be more of the same. On the whole I think it's a good thing to
do. It would remove cases 1 and 4, rendering much of our discussion
moot.
So usbtest in particular needs to know whether an URB really did
undergo accelerated completion. Can't it tell from the final URB
status? Case #2 will be the only way for usb-status to be set to
-ECONNRESET.
What matters here is testability of the interface. What are you
proposing here, exactly, for the test?
Remember that the reason for that loop resubmitting-in-completion
is that it's hard to trigger unlinks. And those unlink paths are
in serious need of testing, since they don't happen all that often,
and historically
Re: [linux-usb-devel] ehci_hcd causes box to resume immediately after suspend to RAM
On Thu, 14 Jun 2007, Rafael J. Wysocki wrote: Hmmm... If you turn on CONFIG_USB_DEBUG, what shows up in /sys/class/usb_host/usb_hostN/registers where N is the bus number of the controller? bus pci, device :00:1d.7 (driver 10 Dec 2004) EHCI Host Controller EHCI 1.00, hcd state 4 ownership 0001 SMI sts/enable 0x8008 structural params 0x00103206 capability params 0x6871 status 1008 Halt FLR command 01 (park)=0 ithresh=1 period=1024 HALT intrenable 37 IAA FATAL PCD ERR INT uframe 36f1 port 1 status 701000 POWER sig=se0 port 2 status 701000 POWER sig=se0 port 3 status 701000 POWER sig=se0 port 4 status 701000 POWER sig=se0 port 5 status 701000 POWER sig=se0 port 6 status 701000 POWER sig=se0 irq normal 0 err 0 reclaim 0 (lost 0) complete 0 unlink 0 Nothing special there. Also, can you post a dmesg log (with CONFIG_USB_DEBUG enabled) showing what happens during the suspend and immediate resume? [That's after I have disabled the wakeup on the EHCI controller.] ... Restarting tasks ... 7hub 1-0:1.0: state 7 ports 6 chg evt ehci_hcd :00:1d.7: GetStatus port 3 status 001020 POWER sig=se0 OCC hub 1-0:1.0: over-current change on port 3 hub 1-0:1.0: trying to enable port power on non-switchable hub done. ehci_hcd :00:1d.7: GetStatus port 4 status 001020 POWER sig=se0 OCC hub 1-0:1.0: over-current change on port 4 hub 1-0:1.0: trying to enable port power on non-switchable hub ehci_hcd :00:1d.7: GetStatus port 5 status 001020 POWER sig=se0 OCC hub 1-0:1.0: over-current change on port 5 hub 1-0:1.0: trying to enable port power on non-switchable hub ehci_hcd :00:1d.7: GetStatus port 6 status 001020 POWER sig=se0 OCC hub 1-0:1.0: over-current change on port 6 hub 1-0:1.0: trying to enable port power on non-switchable hub That's odd. Where could these overcurrent changes be coming from? And how come they don't show up on ports 1 and 2? There's an excellent chance that they are responsible for your immediate resumes. 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] failure notice
Hi. This is the qmail-send program at eircom.net. I'm afraid I wasn't able to deliver your message to the following addresses. This is a permanent error; I've given up. Sorry it didn't work out. [EMAIL PROTECTED]: Sorry, no mailbox here by that name. vpopmail (#5.1.1) --- Enclosed is a copy of the message. ---BeginMessage--- by Server with SMTP; Received: (qmail 21964 by uid 858); Fri, 15 Jun 2007 04:44:50 +0200 Message-Id: [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: RE: query From: [EMAIL PROTECTED] MIME-Version: 1.0 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: 8bit style #1053;#1072; #1089;#1072;#1084;#1086;#1084; #1076;#1077;#1083;#1077; #1088;#1086;#1089;#1090; #1091; «#1040;#1092;#1080;#1096;#1080;» #1077;#1089;#1090;#1100;: #1084;#1099; #1085;#1072; 50% #1074;#1099;#1088;#1086;#1089;#1083;#1080; #1087;#1086; #1086;#1090;#1085;#1086;#1096;#1077;#1085;#1080;#1102; #1082; #1087;#1088;#1086;#1096;#1083;#1086;#1084;#1091; #1075;#1086;#1076;#1091; #1074; #1072;#1091;#1076;#1080;#1090;#1086;#1088;#1080;#1080; #1080; #1085;#1072; 80% #1074; #1076;#1077;#1085;#1100;#1075;#1072;#1093;. #1042; #1087;#1088;#1086;#1096;#1083;#1086;#1084; #1075;#1086;#1076;#1091; #1084;#1099; #1079;#1072;#1088;#1072;#1073;#1086;#1090;#1072;#1083;#1080; #1095;#1091;#1090;#1100; #1073;#1086;#1083;#1100;#1096;#1077; 3 #1084;#1080;#1083;#1083;#1080;#1086;#1085;#1086;#1074; #1076;#1086;#1083;#1083;#1072;#1088;#1086;#1074;, #1085;#1072; #11 01;#1090;#1086;#1090; #1075;#1086;#1076; #1091; #1085;#1072;#1089; #1076;#1086;#1074;#1086;#1083;#1100;#1085;#1086; #1075;#1088;#1072;#1085;#1076;#1080;#1086;#1079;#1085;#1099;#1077; #1087;#1083;#1072;#1085;#1099;, #1082;#1086;#1090;#1086;#1088;#1099;#1077; #1087;#1086;#1082;#1072; #1074;#1099;#1087;#1086;#1083;#1085;#1103;#1102;#1090;#1089;#1103;. #1063;#1090;#1086; #1082;#1072;#1089;#1072;#1077;#1090;#1089;#1103; #1088;#1086;#1089;#1090;#1072; TimeOut, #1089;#1080;#1090;#1091;#1072;#1094;#1080;#1103; #1089;#1083;#1077;#1076;#1091;#1102;#1097;#1072;#1103;. #1050;#1091;#1087;#1080;#1090;#1100; #1090;#1088;#1072;#1092;#1080;#1082; #1074; #1088;#1091;#1089;#1089;#1082;#1086;#1084; #1080;#1085;#1090;#1077;#1088;#1085;#1077;#1090;#1077; #1085;#1077;#1089;#1083;#1086;#1078;#1085;#1086; #1080; #1085;#1077;#1076;#1086;#1088;#1086;#1075;#1086;, #1085;#1072; #1090;#1072;#1082;#1080;#1093; #1087;#1083;#1086;#1097;#1072;#1076;#1082;#1072;#1093; #1082;#1072;#1082; RedTram #1080; «#1053;#1086;#1074;#1086;#1090;#1077;#1082;#1072;» #1074;#1099;#1074;#1077;#1096;#1077;#1085;#1099; #1087;#1088;#1072;#1081;#1089;-#1083;#1080;#1089;#1090;#1099;. #1054;#1076;#1080;#1085; #1087;#1086;#1089;#1077;#1090;#1080; #1090;#1077;#1083;#1100; #1090;#1072;#1084; #1089;#1090;#1086;#1080;#1090; 3 #1094;#1077;#1085;#1090;#1072;, #1087;#1088;#1080; #1073;#1086;#1083;#1100;#1096;#1080;#1093; #1086;#1073;#1098;#1077;#1084;#1072;#1093; #1089;#1082;#1080;#1076;#1082;#1072;. #1069;#1090;#1080; #1082;#1086;#1084;#1087;#1072;#1085;#1080;#1080; #1085;#1072;#1084; #1085;#1077; #1088;#1072;#1079; #1087;#1088;#1077;#1076;#1083;#1072;#1075;#1072;#1083;#1080; #1082;#1091;#1087;#1080;#1090;#1100; #1089;#1091;#1097;#1077;#1089;#1090;#1074;#1077;#1085;#1085;#1099;#1077; #1086;#1073;#1098;#1077;#1084;#1099; #1090;#1088;#1072;#1092;#1080;#1082;#1072; #1087;#1086; 2 #1094;#1077;#1085;#1090;#1072; #1079;#1072; #1087;#1086;#1089;#1077;#1090;#1080;#1090;#1077;#1083;#1103;. #1057;#1086;#1086;#1090;#1074;#1077;#1090;#1089;#1090;#1074;#1077;#1085;#1085;#1086;, #1087;#1088;#1080;#10 86;#1073;#1088;#1077;#1089;#1090;#1080; 600 #1090;#1099;#1089;. #1072;#1091;#1076;#1080;#1090;#1086;#1088;#1080;#1080; #1089;#1090;#1086;#1080;#1083;#1086; #1073;#1099; 1520 #1090;#1099;#1089;. #1076;#1086;#1083;#1083;#1072;#1088;#1086;#1074;. #1069;#1090;#1086; #1074;#1077;#1089;#1100;#1084;#1072; #1089;#1082;#1088;#1086;#1084;#1085;#1099;#1081; #1073;#1102;#1076;#1078;#1077;#1090;. #1045;#1089;#1083;#1080; #1073;#1099; #1091; #1085;#1072;#1089; #1073;#1099;#1083;#1086; #1078;#1077;#1083;#1072;#1085;#1080;#1077; #1080;#1084;#1080;#1090;#1080;#1088;#1086;#1074;#1072;#1090;#1100; #1073;#1086;#1083;#1100;#1096;#1086;#1081; #1086;#1093;#1074;#1072;#1090;, #1084;#1099; #1073;#1099; #1084;#1086;#1075;#1083;#1080; #1087;#1086;#1079;#1074;#1086;#1083;#1080;#1090;#1100; #1089;#1077;#1073;#1077; #1089;#1091;#1097;#1077;#1089;#1090;#1074;#1077;#1085; #1085;#1086; #1073;#1086;#1083;#1100;#1096;#1077;. #1052;#1099; #1072;#1082;#1090;#1080;#1074;#1085;#1086; #1080;#1089;#1087;#1086;#1083;#1100;#1079;#1091;#1077;#1084; #1082;#1086;#1085;#1090;#1077;#1082;#1089;#1090;#1085;#1091;#1102; #1088;#1077;#1082;#1083;#1072;#1084;#1091;, #1080; #1085;#1072;#1084; #1082;#1072;#1078;#1076;#1099;#1081; #1087;#1086;#1089;#1077;#1090;#1080;#1090;#1077;#1083;#1100; #1089;#1090;#1086;#1080;#1090; #1089;#1091;#1097;#1077;#1089;#1090;#1074;#1077;#1085;#1085;#1086;
