[linux-usb-devel] SubClass and Protocol entries
[4296233.326000] usb-storage: This device (0482,0105,0100 S 06 P 50) has unneede d SubClass and Protocol entries in unusual_devs.h [4296233.326000]Please send a copy of this message to [EMAIL PROTECTED] .sourceforge.net -- Marwan Cyril Sabra 15, rue ALfred Brinon 69100 Villeurbanne Courriel: [EMAIL PROTECTED] Téléphone: 0033(0)4-78-84-64-25 Mobile: 0033(0)6-13-66-15-96 --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://ads.osdn.com/?ad_id=7637alloc_id=16865op=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] device not accepting address
-110 is the timeout error and your device it not accepting the SetAddress itself. What is your device ? On 12/7/05, driversbin driversbin [EMAIL PROTECTED] wrote: Hi, I am using a usb host-host cable from prolific (vendor id=0x067 product id=0x2501) . When I plug-in and out twice I start getting messages like the one below. usb 1-2: device not accepting address 4, error -110 usb 1-2: new full speed USB device using s3c2410-ohci and address 5 usb 1-2: device not accepting address 5, error -110 and device fails to get recognised. How can we solve this? Is it something wrong in the way we are trying to handle the device or is it with the hub driver? any help please Regards :-) __ Yahoo! DSL – Something to write home about. Just $16.99/mo. or less. dsl.yahoo.com --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://ads.osdn.com/?ad_id=7637alloc_id=16865op=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] Banned file: message.scr, .exe in mail from you
BANNED FILENAME ALERT Your message to: [EMAIL PROTECTED] was blocked by our Spam Firewall. The email you sent with the following subject has NOT BEEN DELIVERED: Subject: Mail Delivery (failure [EMAIL PROTECTED]) An attachment in that mail was of a file type that the Spam Firewall is set to block. Reporting-MTA: dns; mail1.iitk.ac.in Received-From-MTA: smtp; mail1.iitk.ac.in ([127.0.0.1]) Arrival-Date: Wed, 7 Dec 2005 17:28:23 +0530 (IST) Final-Recipient: rfc822; bkjha@iitk.ac.in Action: failed Status: 5.7.1 Diagnostic-Code: smtp; 550 5.7.1 Message content rejected, id=29284-01-70 - BANNED: message.scr, .exe Last-Attempt-Date: Wed, 7 Dec 2005 17:28:23 +0530 (IST) Received: from iitk.ac.in (unknown [61.246.12.122]) by mail1.iitk.ac.in (Spam Firewall) with SMTP id ABC601715F for [EMAIL PROTECTED]; Wed, 7 Dec 2005 17:28:19 +0530 (IST) From: linux-usb-devel@lists.sourceforge.net To: [EMAIL PROTECTED] Subject: Mail Delivery (failure [EMAIL PROTECTED]) Date: Wed, 7 Dec 2005 17:22:09 -0800 MIME-Version: 1.0 Content-Type: multipart/related; type=multipart/alternative; boundary==_NextPart_000_001B_01C0CA80.6B015D10 X-Priority: 3 X-MSMail-Priority: Normal Message-Id: [EMAIL PROTECTED]
Re: [linux-usb-devel] Re: [PATCH 00/10] usb-serial: Switches from spin lock to atomic_t.
On Tue, 6 Dec 2005 23:48:14 +0100 Oliver Neukum [EMAIL PROTECTED] wrote: | Am Dienstag, 6. Dezember 2005 21:13 schrieb Eduardo Pereira Habkost: | Anyway, I don't see yet why the atomic_t would make the code slower on | non-smp. Is atomic_add_unless(v, 1, 1) supposed to be slower than | 'if (!v) v = 1;' ? | | spin_lock() can be dropped on UP. atomic_XXX must either use an operation | on main memory, meaning less efficient code generation, or must disable | interrupts even on UP. Hmmm, I didn't know about the possibility to disable interrupts. In the OOPS thread: http://marc.theaimsgroup.com/?l=linux-usb-develm=113269682409774w=2 *IIUC*, Greg told us that we could think about the possibility to drop the spin lock and use the semaphore instead, because URB writes are slow. We (me and Eduardo) didn't like it because we would be using the same lock for two different problems, so we suggested the atomic_t, and Greg agreed (IIRC). Isn't it right? Is the URB write so fast that switching to atomic_t doesn't pay-off? -- Luiz Fernando N. Capitulino --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://ads.osdn.com/?ad_id=7637alloc_id=16865op=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] Re: [PATCH 00/10] usb-serial: Switches from spin lock to atomic_t.
On Tue, 6 Dec 2005 23:36:47 +0100 Oliver Neukum [EMAIL PROTECTED] wrote: | Am Dienstag, 6. Dezember 2005 22:18 schrieb Luiz Fernando Capitulino: | | Hi Pete, | | On Tue, 6 Dec 2005 13:02:07 -0800 | Pete Zaitcev [EMAIL PROTECTED] wrote: | | | On Tue, 6 Dec 2005 18:14:49 -0200, Luiz Fernando Capitulino [EMAIL PROTECTED] wrote: | | | | The spinlock makes the code less clear, error prone, and we already a | | semaphore in the struct usb_serial_port. | | | | The spinlocks _seems_ useless to me. | | | | Dude, semaphores are not compatible with interrupts. Surely you | | understand that? | | Sure thing man, take a look at this thread: | | http://marc.theaimsgroup.com/?l=linux-kernelm=113216151918308w=2 | | My comment 'we already have a semaphore in struct usb_serial_port' | was about what we've discussed in that thread, where question like | 'why should we have yet another lock here?' have been made. | | And *not* 'let's use the semaphore instead'. | | If _speed_ does not make difference, the spinlock seems useless, | because we could use atomic_t instead. | | You can atomically set _one_ value using atomic_t. A spinlock allows | that and other more complex schemes. We only need to set 'write_urb_busy', nothing more. -- Luiz Fernando N. Capitulino --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://ads.osdn.com/?ad_id=7637alloc_id=16865op=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] Re: [PATCH 00/10] usb-serial: Switches from spin lock to atomic_t.
Isn't it right? Is the URB write so fast that switching to atomic_t doesn't pay-off? an atomic_t access and a spinlock are basically the same price... so what's the payoff ? --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://ads.osdn.com/?ad_id=7637alloc_id=16865op=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] Re: [PATCH 00/10] usb-serial: Switches from spin lock to atomic_t.
On Wed, 07 Dec 2005 13:27:13 +0100 Arjan van de Ven [EMAIL PROTECTED] wrote: | | Isn't it right? Is the URB write so fast that switching to atomic_t | doesn't pay-off? | | an atomic_t access and a spinlock are basically the same price... so | what's the payoff ? One lock less, clean and less error prone code. -- Luiz Fernando N. Capitulino --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://ads.osdn.com/?ad_id=7637alloc_id=16865op=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] Re: [PATCH 00/10] usb-serial: Switches from spin lock to atomic_t.
On Wed, 2005-12-07 at 10:30 -0200, Luiz Fernando Capitulino wrote: On Wed, 07 Dec 2005 13:27:13 +0100 Arjan van de Ven [EMAIL PROTECTED] wrote: | | Isn't it right? Is the URB write so fast that switching to atomic_t | doesn't pay-off? | | an atomic_t access and a spinlock are basically the same price... so | what's the payoff ? One lock less, where? spin_unlock in principle runs unlocked on x86 at least (except for ppro workarounds but those are/should be optional) --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://ads.osdn.com/?ad_id=7637alloc_id=16865op=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] Re: [PATCH 00/10] usb-serial: Switches from spin lock to atomic_t.
On Wed, 07 Dec 2005 13:34:38 +0100 Arjan van de Ven [EMAIL PROTECTED] wrote: | On Wed, 2005-12-07 at 10:30 -0200, Luiz Fernando Capitulino wrote: | On Wed, 07 Dec 2005 13:27:13 +0100 | Arjan van de Ven [EMAIL PROTECTED] wrote: | | | | | Isn't it right? Is the URB write so fast that switching to atomic_t | | doesn't pay-off? | | | | an atomic_t access and a spinlock are basically the same price... so | | what's the payoff ? | | One lock less, | | where? In the 'usb_serial_port', my patch number nine removes the spin lock. | spin_unlock in principle runs unlocked on x86 at least | (except for ppro workarounds but those are/should be optional) | | -- Luiz Fernando N. Capitulino --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://ads.osdn.com/?ad_id=7637alloc_id=16865op=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] Re: [PATCH 00/10] usb-serial: Switches from spin lock to atomic_t.
On Wed, 7 Dec 2005 10:41:24 -0200 Luiz Fernando Capitulino [EMAIL PROTECTED] wrote: | On Wed, 07 Dec 2005 13:34:38 +0100 | Arjan van de Ven [EMAIL PROTECTED] wrote: | | | On Wed, 2005-12-07 at 10:30 -0200, Luiz Fernando Capitulino wrote: | | On Wed, 07 Dec 2005 13:27:13 +0100 | | Arjan van de Ven [EMAIL PROTECTED] wrote: | | | | | | | | Isn't it right? Is the URB write so fast that switching to atomic_t | | | doesn't pay-off? | | | | | | an atomic_t access and a spinlock are basically the same price... so | | | what's the payoff ? | | | | One lock less, | | | | where? | | In the 'usb_serial_port', my patch number nine removes the spin lock. struct 'usb_serial_port' I meant. -- Luiz Fernando N. Capitulino --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://ads.osdn.com/?ad_id=7637alloc_id=16865op=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] Re: [PATCH 00/10] usb-serial: Switches from spin lock to atomic_t.
Am Mittwoch, 7. Dezember 2005 13:25 schrieb Luiz Fernando Capitulino: On Tue, 6 Dec 2005 23:36:47 +0100 Oliver Neukum [EMAIL PROTECTED] wrote: | Am Dienstag, 6. Dezember 2005 22:18 schrieb Luiz Fernando Capitulino: | | Hi Pete, | | On Tue, 6 Dec 2005 13:02:07 -0800 | Pete Zaitcev [EMAIL PROTECTED] wrote: | | | On Tue, 6 Dec 2005 18:14:49 -0200, Luiz Fernando Capitulino [EMAIL PROTECTED] wrote: | | | | The spinlock makes the code less clear, error prone, and we already a | | semaphore in the struct usb_serial_port. | | | | The spinlocks _seems_ useless to me. | | | | Dude, semaphores are not compatible with interrupts. Surely you | | understand that? | | Sure thing man, take a look at this thread: | | http://marc.theaimsgroup.com/?l=linux-kernelm=113216151918308w=2 | | My comment 'we already have a semaphore in struct usb_serial_port' | was about what we've discussed in that thread, where question like | 'why should we have yet another lock here?' have been made. | | And *not* 'let's use the semaphore instead'. | | If _speed_ does not make difference, the spinlock seems useless, | because we could use atomic_t instead. | | You can atomically set _one_ value using atomic_t. A spinlock allows | that and other more complex schemes. We only need to set 'write_urb_busy', nothing more. So go hence and encapsulate that using the existent infrastructure. Thus you get the most efficient solution. Regards Oliver --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://ads.osdn.com/?ad_id=7637alloc_id=16865op=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] Re: [PATCH 00/10] usb-serial: Switches from spin lock to atomic_t.
On Wed, 7 Dec 2005 14:01:25 +0100 Oliver Neukum [EMAIL PROTECTED] wrote: | Am Mittwoch, 7. Dezember 2005 13:25 schrieb Luiz Fernando Capitulino: | On Tue, 6 Dec 2005 23:36:47 +0100 | Oliver Neukum [EMAIL PROTECTED] wrote: | | | Am Dienstag, 6. Dezember 2005 22:18 schrieb Luiz Fernando Capitulino: | | | | Hi Pete, | | | | On Tue, 6 Dec 2005 13:02:07 -0800 | | Pete Zaitcev [EMAIL PROTECTED] wrote: | | | | | On Tue, 6 Dec 2005 18:14:49 -0200, Luiz Fernando Capitulino [EMAIL PROTECTED] wrote: | | | | | | The spinlock makes the code less clear, error prone, and we already a | | | semaphore in the struct usb_serial_port. | | | | | | The spinlocks _seems_ useless to me. | | | | | | Dude, semaphores are not compatible with interrupts. Surely you | | | understand that? | | | | Sure thing man, take a look at this thread: | | | | http://marc.theaimsgroup.com/?l=linux-kernelm=113216151918308w=2 | | | | My comment 'we already have a semaphore in struct usb_serial_port' | | was about what we've discussed in that thread, where question like | | 'why should we have yet another lock here?' have been made. | | | | And *not* 'let's use the semaphore instead'. | | | | If _speed_ does not make difference, the spinlock seems useless, | | because we could use atomic_t instead. | | | | You can atomically set _one_ value using atomic_t. A spinlock allows | | that and other more complex schemes. | | We only need to set 'write_urb_busy', nothing more. | | So go hence and encapsulate that using the existent infrastructure. Thus | you get the most efficient solution. Yes, I was speaking about it with Eduardo some minutes ago. My only question is: currently the spin lock is not acquired for unlock operations (ie, setting 'write_urb_busy' to 0), and to check 'write_usb_busy' value. I don't know if it's safe. But, If I add the spin_lock()/spin_unlock() functions in my 'unlock' and 'locked' methods, I could increase the latency for SMP systems. Suggestions? Eduardo? Greg? -- Luiz Fernando N. Capitulino --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://ads.osdn.com/?ad_id=7637alloc_id=16865op=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] Kernel panics at USB initialization with kexec
On Thu, Dec 01, 2005 at 10:54:27PM -0800, Greg KH wrote: On Fri, Dec 02, 2005 at 12:20:09PM +0530, Rachita Kothiyal wrote: On Thu, Dec 01, 2005 at 05:17:48PM -0800, Greg KH wrote: On Thu, Dec 01, 2005 at 10:05:02PM +0530, Rachita Kothiyal wrote: Hi I am trying to kexec reboot to a 2.6.15-rc2-mm1 kernel, with USB builtin, on a x86_64 box, but the system just hangs during USB initialization. But strangely, if I comment out the ehci_info() in ehci_run() in the drivers/usb/host/ehci-hcd.c file, the system successfully reboots. I fail to understand how ehci_info, which translates to printk, is a cause of the system hanging. Any ideas on what could be going wrong would be of great help. Can you try 2.6.15-rc4 instead? It has some patches in this exact area. Thanks Greg. It works fine now. Great, thanks for testing and letting us know. Hi Greg, I was trying to kexec boot to a 2.6.15-rc5-mm1 kernel with USB builtin(same specifics as above), and it failed again at the USB initialization. But if I revert the gregkh-usb-usb-ehci-updates-driver-model-wakeup-flags.patch, from the mm patch set, it works fine. It worked fine on 2.6.15-rc5 though. Any thoughts on what could be going wrong? Thanks Rachita --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://ads.osdn.com/?ad_id=7637alloc_id=16865op=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] What is STUB_DEBUG_FILES?
On Tue, 6 Dec 2005, Ethan Dicks wrote: On Tue, Dec 06, 2005 at 12:46:32PM -0800, Deepak Saxena wrote: I really think we need a rule in Documentation/CodingStyle that says Thou shalt not #include .c files from .c files. Wow! And I thought that was universally understood as a Bad Idea. I'd endorse that rule. It does make sense to #include .c files on occasion. The example I have in mind is a single very large source file that you would like to divide up into pieces for easier handling. You can break it up into separate .c files, compile each one individually, and then link them together; that's the more-or-less standard approach. It means creating public symbols for every variable and function needing an inter-file reference. It also means creating header files with declarations for all these things. Alternatively, you can #include all the source files into a single master. That doesn't provide any improvement in compile time (in fact compile times are now slightly worse), but it also doesn't generate a lot of new, unwanted public symbols. Personally, I don't see why anyone should think that #include-ing one .c file in another is any worse than physically merging the files. Alan Stern --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://ads.osdn.com/?ad_id=7637alloc_id=16865op=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] Re: [PATCH 00/10] usb-serial: Switches from spin lock to atomic_t.
On Tue, 6 Dec 2005, Oliver Neukum wrote: Am Dienstag, 6. Dezember 2005 21:13 schrieb Eduardo Pereira Habkost: Anyway, I don't see yet why the atomic_t would make the code slower on non-smp. Is atomic_add_unless(v, 1, 1) supposed to be slower than 'if (!v) v = 1;' ? spin_lock() can be dropped on UP. atomic_XXX must either use an operation on main memory, meaning less efficient code generation, or must disable interrupts even on UP. atomic_add_unless is sort of a special case. It doesn't have a clean simple implementation, unlike most of the other atomic_t operations. If an equivalent result could be obtained using, e.g., atomic_inc_and_test, that would be a better approach. On the other hand, Oliver needs to be careful about claiming too much. In general atomic_t operations _are_ superior to the spinlock approach. If they weren't, atomic_t wouldn't belong in the kernel at all. Alan Stern --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://ads.osdn.com/?ad_id=7637alloc_id=16865op=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] SubClass and Protocol entries
On Wed, 7 Dec 2005, Marwan Cyril Sabra wrote: [4296233.326000] usb-storage: This device (0482,0105,0100 S 06 P 50) has unneede d SubClass and Protocol entries in unusual_devs.h [4296233.326000]Please send a copy of this message to [EMAIL PROTECTED] .sourceforge.net Phil, this isn't fixed in my kernel source. It's worthwhile checking with the original submitters of this entry. Either it's not needed at all or else it requires a US_FL_NEED_OVERRIDE. Alan Stern --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://ads.osdn.com/?ad_id=7637alloc_id=16865op=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] Re: [PATCH 00/10] usb-serial: Switches from spin lock to atomic_t.
On the other hand, Oliver needs to be careful about claiming too much. In general atomic_t operations _are_ superior to the spinlock approach. No they're not. Both are just about equally expensive cpu wise, sometimes the atomic_t ones are a bit more expensive (like on parisc architecture). But on x86 in either case it's a locked cycle, which is just expensive no matter which side you flip the coin... If they weren't, atomic_t wouldn't belong in the kernel at all. there's different usage patterns where either makes sense. In this case it looks just disgusting on very first sight; the atomic are used to implement a lock, and that lock itself is then implemented with a spinlock again. For me, again on first sight, the real solution appears to be to use a linux primitive for the higher level lock in the first place, instead of reimplementing your own thing with another own thing. --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://ads.osdn.com/?ad_id=7637alloc_id=16865op=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] usblp suspend failure with 2.6.15-rc5
On Tue, 6 Dec 2005, Carl-Daniel Hailfinger wrote:
Hi,
since I switched to 2.6.15-rc2-git6, my machine is not able to suspend
anymore if my USB printer is plugged in. The problem is reproducible.
usb 1-2: new full speed USB device using uhci_hcd and address 3
drivers/usb/class/usblp.c: usblp0: USB Bidirectional printer dev 3 if 0 alt 0
proto 2 vid 0x04E8 pid 0x3242
usbcore: registered new driver usblp
drivers/usb/class/usblp.c: v0.13: USB Printer Device Class driver
PM: Preparing system for mem sleep
Stopping tasks: ==|
usblp 1-2:1.0: no suspend?
Could not suspend device 1-2: error -16
Some devices failed to suspend
Restarting tasks... done
Earlier kernels (2.6.14.2 and before) worked just fine.
A first search suggests this problem was introduced between
2.6.14 and 2.6.15-rc2-git6. Should I try to narrow it down further?
No need. Try the patch below and see if it helps.
Alan Stern
Index: linux-2.6.15-rc3/drivers/usb/core/usb.c
===
--- linux-2.6.15-rc3.orig/drivers/usb/core/usb.c
+++ linux-2.6.15-rc3/drivers/usb/core/usb.c
@@ -1414,8 +1414,10 @@ static int usb_generic_suspend(struct de
}
if ((dev-driver == NULL) ||
- (dev-driver_data == usb_generic_driver_data))
+ (dev-driver_data == usb_generic_driver_data)) {
+ dev-power.power_state.event = PM_EVENT_FREEZE;
return 0;
+ }
intf = to_usb_interface(dev);
driver = to_usb_driver(dev-driver);
---
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems? Stop! Download the new AJAX search engine that makes
searching your log files as easy as surfing the web. DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_id=7637alloc_id=16865op=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] Re: [PATCH 00/10] usb-serial: Switches from spin lock to atomic_t.
On Wed, 7 Dec 2005, Alan Stern wrote:
On Tue, 6 Dec 2005, Oliver Neukum wrote:
Am Dienstag, 6. Dezember 2005 21:13 schrieb Eduardo Pereira Habkost:
Anyway, I don't see yet why the atomic_t would make the code slower on
non-smp. Is atomic_add_unless(v, 1, 1) supposed to be slower than
'if (!v) v = 1;' ?
spin_lock() can be dropped on UP. atomic_XXX must either use an operation
on main memory, meaning less efficient code generation, or must disable
interrupts even on UP.
atomic_add_unless is sort of a special case. It doesn't have a clean
simple implementation, unlike most of the other atomic_t operations. If
an equivalent result could be obtained using, e.g., atomic_inc_and_test,
that would be a better approach.
On the other hand, Oliver needs to be careful about claiming too much. In
general atomic_t operations _are_ superior to the spinlock approach. If
they weren't, atomic_t wouldn't belong in the kernel at all.
Alan Stern
You need to know what it is that you intend to do if the code
encounters a locked section.
For example, let's pretend that every operation is atomic so
that only the logic is investigated...
if(!critical_section_flag) {
critical_section_flag = TRUE;
do_something_in_critical_section();
}
else
WTF?;
A spin-lock will prevent the current CPU from even getting to
or modifying data in the critical section because alternate paths
via interrupts are blocked. The only other way for data to be
modified is from another CPU. That CPU will spin until the current
CPU releases the lock.
Atomic operations on flags (semaphores) provide the opportunity
for another CPU to do something useful until the critical section
is released, the WTF above. However, if the other CPU can't
schedule you are caught between a rock and a hard-place because
you would need to spin anyway.
Basically, if you can schedule, it's much better to protect
a section with semaphores and do the down(semi) / up(semi) thing.
If you can't schedule, it's much cleaner to use a spin-lock
which, in fact, will prevent interference with the critical
section in most cases because, unless another CPU is idle,
it is unlikely to encounter the same thread of code.
Cheers,
Dick Johnson
Penguin : Linux version 2.6.13.4 on an i686 machine (5589.55 BogoMips).
Warning : 98.36% of all statistics are fiction.
.
The information transmitted in this message is confidential and may be
privileged. Any review, retransmission, dissemination, or other use of this
information by persons or entities other than the intended recipient is
prohibited. If you are not the intended recipient, please notify Analogic
Corporation immediately - by replying to this message or by sending an email to
[EMAIL PROTECTED] - and destroy all copies of this information, including any
attachments, without reading or disclosing them.
Thank you.
---
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems? Stop! Download the new AJAX search engine that makes
searching your log files as easy as surfing the web. DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_idv37alloc_id865op=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] Re: [PATCH 00/10] usb-serial: Switches from spin lock to atomic_t.
Am Mittwoch, 7. Dezember 2005 16:22 schrieb Arjan van de Ven: On the other hand, Oliver needs to be careful about claiming too much. In general atomic_t operations _are_ superior to the spinlock approach. No they're not. Both are just about equally expensive cpu wise, sometimes the atomic_t ones are a bit more expensive (like on parisc architecture). But on x86 in either case it's a locked cycle, which is just expensive no matter which side you flip the coin... You are refering to SMP, aren't you? Regards Oliver --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://ads.osdn.com/?ad_idv37alloc_id865op=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] device not accepting address
On Tue, 6 Dec 2005, driversbin driversbin wrote: Hi, I am using a usb host-host cable from prolific (vendor id=0x067 product id=0x2501) . When I plug-in and out twice I start getting messages like the one below. usb 1-2: device not accepting address 4, error -110 usb 1-2: new full speed USB device using s3c2410-ohci and address 5 usb 1-2: device not accepting address 5, error -110 and device fails to get recognised. How can we solve this? Is it something wrong in the way we are trying to handle the device or is it with the hub driver? any help please What kernel are you using? If you're not using 2.6.14 or later, try upgrading before doing anything else. It's hard to tell just what is going wrong without more debugging information. If you turn on USB verbose debugging in the kernel configuration (CONFIG_USB_DEBUG) that may help indicate whether the problem lies in the drivers or in the device. The fact that it works sometimes but not others indicates that it's a device problem. On the other hand, if the device is bus-powered then it should reset completely every time you unplug it. Alan Stern --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://ads.osdn.com/?ad_id=7637alloc_id=16865op=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] Re: [PATCH 00/10] usb-serial: Switches from spin lock to atomic_t.
On Wed, 2005-12-07 at 16:37 +0100, Oliver Neukum wrote: Am Mittwoch, 7. Dezember 2005 16:22 schrieb Arjan van de Ven: On the other hand, Oliver needs to be careful about claiming too much. In general atomic_t operations _are_ superior to the spinlock approach. No they're not. Both are just about equally expensive cpu wise, sometimes the atomic_t ones are a bit more expensive (like on parisc architecture). But on x86 in either case it's a locked cycle, which is just expensive no matter which side you flip the coin... You are refering to SMP, aren't you? yes. on UP neither is a locked instruction ;) --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://ads.osdn.com/?ad_id=7637alloc_id=16865op=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] Re: [PATCH 00/10] usb-serial: Switches from spin lock to atomic_t.
Am Mittwoch, 7. Dezember 2005 16:40 schrieben Sie: On Wed, 2005-12-07 at 16:37 +0100, Oliver Neukum wrote: Am Mittwoch, 7. Dezember 2005 16:22 schrieb Arjan van de Ven: On the other hand, Oliver needs to be careful about claiming too much. In general atomic_t operations _are_ superior to the spinlock approach. No they're not. Both are just about equally expensive cpu wise, sometimes the atomic_t ones are a bit more expensive (like on parisc architecture). But on x86 in either case it's a locked cycle, which is just expensive no matter which side you flip the coin... You are refering to SMP, aren't you? yes. on UP neither is a locked instruction ;) But the atomic variant has to guard against interrupts, at least on architectures that do load/store only, hasn't it? AFAICT it is even theoretically impossible to tell for the compiler whether a function is always called with interrupts off. Regards Oliver --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://ads.osdn.com/?ad_id=7637alloc_id=16865op=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] Re: [PATCH 00/10] usb-serial: Switches from spin lock to atomic_t.
On Wed, Dec 07, 2005 at 04:22:23PM +0100, Arjan van de Ven wrote: On the other hand, Oliver needs to be careful about claiming too much. In general atomic_t operations _are_ superior to the spinlock approach. No they're not. Both are just about equally expensive cpu wise, sometimes the atomic_t ones are a bit more expensive (like on parisc architecture). But on x86 in either case it's a locked cycle, which is just expensive no matter which side you flip the coin... But if a lock is used exclusively to protect a int variable, an atomic_t seems to be more appropriate to me. Isn't it? If they weren't, atomic_t wouldn't belong in the kernel at all. there's different usage patterns where either makes sense. In this case it looks just disgusting on very first sight; the atomic are used to implement a lock, and that lock itself is then implemented with a spinlock again. For me, again on first sight, the real solution appears to be to use a linux primitive for the higher level lock in the first place, instead of reimplementing your own thing with another own thing. The patches don't implement any new lock scheme neither change the current behaviour. They just replace a spin_lock + integer variable (the spinlock is used just to protect an integer variable) by an atomic_t. The patches aren't adding any own lock scheme, but just replacing a spinlock that is used exclusively to protect an integer variable (write_urb_busy) by an atomic_t. The whole point of the changes is that using a spin_lock to protect only a int variable doesn't look like a Right Thing. Please, if you could, review the patches with this in mind: we aren't changing any behaviour neither creating any weird lock scheme, we are only doing two things: 1. Putting all the duplicated code that handles write_urb_busy (that already exists) in only one place 2. Replacing a spin_lock that is being used to protect only a single integer field by an atomic_t People got scared when they looked at the patch that does (1), thinking that we were creating new, weird, locking scheme (because we are doing (2) at the same time). But we are just isolating the existing 'write_urb_busy' scheme that is duplicated all around the usb-serial drivers. I guess (1) is a Good Thing, so the only question is: do you really disagree about doing (2)? -- Eduardo pgpKQnxJv9Msq.pgp Description: PGP signature
Re: [linux-usb-devel] usblp suspend failure with 2.6.15-rc5
Alan Stern schrieb:
On Tue, 6 Dec 2005, Carl-Daniel Hailfinger wrote:
since I switched to 2.6.15-rc2-git6, my machine is not able to suspend
anymore if my USB printer is plugged in. The problem is reproducible.
usb 1-2: new full speed USB device using uhci_hcd and address 3
drivers/usb/class/usblp.c: usblp0: USB Bidirectional printer dev 3 if 0 alt 0
proto 2 vid 0x04E8 pid 0x3242
usbcore: registered new driver usblp
drivers/usb/class/usblp.c: v0.13: USB Printer Device Class driver
PM: Preparing system for mem sleep
Stopping tasks: ==|
usblp 1-2:1.0: no suspend?
Could not suspend device 1-2: error -16
Some devices failed to suspend
Restarting tasks... done
Earlier kernels (2.6.14.2 and before) worked just fine.
A first search suggests this problem was introduced between
2.6.14 and 2.6.15-rc2-git6. Should I try to narrow it down further?
No need. Try the patch below and see if it helps.
Alan Stern
Index: linux-2.6.15-rc3/drivers/usb/core/usb.c
===
--- linux-2.6.15-rc3.orig/drivers/usb/core/usb.c
+++ linux-2.6.15-rc3/drivers/usb/core/usb.c
@@ -1414,8 +1414,10 @@ static int usb_generic_suspend(struct de
}
if ((dev-driver == NULL) ||
- (dev-driver_data == usb_generic_driver_data))
+ (dev-driver_data == usb_generic_driver_data)) {
+ dev-power.power_state.event = PM_EVENT_FREEZE;
return 0;
+ }
intf = to_usb_interface(dev);
driver = to_usb_driver(dev-driver);
Sorry, this patch didn't help. Anthing else I can try?
Regards,
Carl-Daniel
---
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems? Stop! Download the new AJAX search engine that makes
searching your log files as easy as surfing the web. DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_id=7637alloc_id=16865op=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] Re: [PATCH 00/10] usb-serial: Switches from spin lock to atomic_t.
On Wed, 7 Dec 2005, Arjan van de Ven wrote: On the other hand, Oliver needs to be careful about claiming too much. In general atomic_t operations _are_ superior to the spinlock approach. No they're not. Both are just about equally expensive cpu wise, sometimes the atomic_t ones are a bit more expensive (like on parisc architecture). But on x86 in either case it's a locked cycle, which is just expensive no matter which side you flip the coin... You're overgeneralizing. Sure, a locked cycle has a certain expense. But it's a lot less than the expense of a contested spinlock. On the other hand, many times UP systems can eliminate spinlocks entirely. There are lots of variables and many possible tradeoffs. Alan Stern --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://ads.osdn.com/?ad_id=7637alloc_id=16865op=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] Re: [PATCH 00/10] usb-serial: Switches from spin lock to atomic_t.
No they're not. Both are just about equally expensive cpu wise, sometimes the atomic_t ones are a bit more expensive (like on parisc architecture). But on x86 in either case it's a locked cycle, which is just expensive no matter which side you flip the coin... But if a lock is used exclusively to protect a int variable, an atomic_t seems to be more appropriate to me. Isn't it? sounds like it... Please, if you could, review the patches with this in mind: we aren't changing any behaviour neither creating any weird lock scheme, we are only doing two things: ... however you are NOT changing the behavior, which is EXACTLY my point; the current lock emulation behavior is wrong, all you're doing is replacing how you do the wrong thing ;) It's like having a bike with square wheels, and replacing a flat tire with one with air in, as opposed to replacing it with a round wheel... --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://ads.osdn.com/?ad_id=7637alloc_id=16865op=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] Re: [PATCH 00/10] usb-serial: Switches from spin lock to atomic_t.
On Mer, 2005-12-07 at 16:50 +0100, Oliver Neukum wrote: But the atomic variant has to guard against interrupts, at least on architectures that do load/store only, hasn't it? Yes. And you will see at least four different approaches 1. ll/sc where if the sequence was interrupted and may be stale it gets retried 2. locked operations where the IRQ cannot split the sequence and use of 3. spin locks to provide atomic operations where there are architecture limits 4. Use of instructions acting on memory where the CPU in question has them and (as is usual in processors) does not permit an IRQ mid instruction. Thus on x86 *foo++ might be atomic, might not on uniprocessor v interrupt solely because the compiler chooses the operations. Atomic_inc however merely has to use asm to force an inc of a memory location target. That instruction cannot be split part way by an interrupt so is sufficient. Relative efficiency of spin_lock versus atomic_foo is very platform dependant. --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://ads.osdn.com/?ad_id=7637alloc_id=16865op=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] Re: [PATCH 00/10] usb-serial: Switches from spin lock to atomic_t.
On Wed, 2005-12-07 at 11:01 -0500, Alan Stern wrote: On Wed, 7 Dec 2005, Arjan van de Ven wrote: On the other hand, Oliver needs to be careful about claiming too much. In general atomic_t operations _are_ superior to the spinlock approach. No they're not. Both are just about equally expensive cpu wise, sometimes the atomic_t ones are a bit more expensive (like on parisc architecture). But on x86 in either case it's a locked cycle, which is just expensive no matter which side you flip the coin... You're overgeneralizing. to some degree yes. Sure, a locked cycle has a certain expense. But it's a lot less than the expense of a contested spinlock. the chances that *this* spinlock ends up being contested are near zero, and.. in that scenario a locked cycle does the same thing, just in hardware. (eg the other cpu will busy wait until this locked cycle is done) --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://ads.osdn.com/?ad_id=7637alloc_id=16865op=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] Re: [PATCH 00/10] usb-serial: Switches from spin lock to atomic_t.
On Wed, 7 Dec 2005, linux-os (Dick Johnson) wrote:
You need to know what it is that you intend to do if the code
encounters a locked section.
For example, let's pretend that every operation is atomic so
that only the logic is investigated...
if(!critical_section_flag) {
critical_section_flag = TRUE;
do_something_in_critical_section();
}
else
WTF?;
A spin-lock will prevent the current CPU from even getting to
or modifying data in the critical section because alternate paths
via interrupts are blocked. The only other way for data to be
modified is from another CPU. That CPU will spin until the current
CPU releases the lock.
Atomic operations on flags (semaphores) provide the opportunity
for another CPU to do something useful until the critical section
is released, the WTF above. However, if the other CPU can't
schedule you are caught between a rock and a hard-place because
you would need to spin anyway.
Basically, if you can schedule, it's much better to protect
a section with semaphores and do the down(semi) / up(semi) thing.
If you can't schedule, it's much cleaner to use a spin-lock
which, in fact, will prevent interference with the critical
section in most cases because, unless another CPU is idle,
it is unlikely to encounter the same thread of code.
That's true as far as it goes. But it ignores the possibility that, for
example, the critical section is extremely short (like incrementing an
integer variable). In such situations, spinning is better than
scheduling. And even better than spinning is for the CPU to wait while
another CPU carries out a locked bus cycle (which is what atomic_t
operations do on x86). As well as being more efficient, it may even be
cleaner -- depending on one's personal taste. :-)
Alan Stern
---
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems? Stop! Download the new AJAX search engine that makes
searching your log files as easy as surfing the web. DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_id=7637alloc_id=16865op=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] usblp suspend failure with 2.6.15-rc5
On Wed, 7 Dec 2005, Carl-Daniel Hailfinger wrote: Sorry, this patch didn't help. Anthing else I can try? What does the dmesg log say? Alan Stern --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://ads.osdn.com/?ad_id=7637alloc_id=16865op=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] usblp suspend failure with 2.6.15-rc5
Alan Stern schrieb: On Wed, 7 Dec 2005, Carl-Daniel Hailfinger wrote: Sorry, this patch didn't help. Anthing else I can try? What does the dmesg log say? Same as before: usb 1-2: new full speed USB device using uhci_hcd and address 2 drivers/usb/class/usblp.c: usblp0: USB Bidirectional printer dev 2 if 0 alt 0 proto 2 vid 0x04E8 pid 0x3242 usbcore: registered new driver usblp drivers/usb/class/usblp.c: v0.13: USB Printer Device Class driver [...] PM: Preparing system for mem sleep Stopping tasks: ===| usblp 1-2:1.0: no suspend? Could not suspend device 1-2: error -16 Some devices failed to suspend Restarting tasks... done Regards, Carl-Daniel --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://ads.osdn.com/?ad_id=7637alloc_id=16865op=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] Re: [PATCH 00/10] usb-serial: Switches from spin lock to atomic_t.
On Wed, Dec 07, 2005 at 05:02:33PM +0100, Arjan van de Ven wrote: No they're not. Both are just about equally expensive cpu wise, sometimes the atomic_t ones are a bit more expensive (like on parisc architecture). But on x86 in either case it's a locked cycle, which is just expensive no matter which side you flip the coin... But if a lock is used exclusively to protect a int variable, an atomic_t seems to be more appropriate to me. Isn't it? sounds like it... Please, if you could, review the patches with this in mind: we aren't changing any behaviour neither creating any weird lock scheme, we are only doing two things: ... however you are NOT changing the behavior, which is EXACTLY my point; the current lock emulation behavior is wrong, all you're doing is replacing how you do the wrong thing ;) But now doing the Right Thing will be easy, as the wrong code isn't duplicated all around anymore: it is only in one place. ;) We have just done a small refactoring, trying to keep behaviour. I haven't analysed deeply the current code to check if the lock emulation could be replaced by a better approach. But at a first look, it didn't look wrong to me. I am open to suggestions on how to replace the write_urb_busy checking by something better. So, at least we agree that using atomic_t is better than the current approach, right? So, do you agree that, _if_ we chose to keep the write_urb_busy pseudo-locking, we could at least remove the code duplication for that and use an atomic_t instead of spin_lock+int? It's like having a bike with square wheels, and replacing a flat tire with one with air in, as opposed to replacing it with a round wheel... I am open to suggestions on how to build a round wheel in this case. :) -- Eduardo pgpBHQC8dhwth.pgp Description: PGP signature
Re: [linux-usb-devel] usblp suspend failure with 2.6.15-rc5
On Wed, 7 Dec 2005, Carl-Daniel Hailfinger wrote:
Alan Stern schrieb:
On Wed, 7 Dec 2005, Carl-Daniel Hailfinger wrote:
Sorry, this patch didn't help. Anthing else I can try?
What does the dmesg log say?
Same as before:
usb 1-2: new full speed USB device using uhci_hcd and address 2
drivers/usb/class/usblp.c: usblp0: USB Bidirectional printer dev 2 if 0 alt 0
proto 2 vid 0x04E8 pid 0x3242
usbcore: registered new driver usblp
drivers/usb/class/usblp.c: v0.13: USB Printer Device Class driver
[...]
PM: Preparing system for mem sleep
Stopping tasks: ===|
usblp 1-2:1.0: no suspend?
Could not suspend device 1-2: error -16
Some devices failed to suspend
Restarting tasks... done
Darn it. There were two problem pathways in that code and the patch
changed the wrong one. Okay, this patch changes both.
Bear in mind that this is just a temporary band-aid. The real problem is
that the usblp driver doesn't have any suspend/resume support. That still
needs to be fixed.
If you don't feel like using the patch below, you can simply rmmod usblp
before suspending and modprobe usblp after resuming. That's actually a
safer approach.
Alan Stern
Index: linux-2.6.15-rc3/drivers/usb/core/usb.c
===
--- linux-2.6.15-rc3.orig/drivers/usb/core/usb.c
+++ linux-2.6.15-rc3/drivers/usb/core/usb.c
@@ -1414,8 +1414,10 @@ static int usb_generic_suspend(struct de
}
if ((dev-driver == NULL) ||
- (dev-driver_data == usb_generic_driver_data))
+ (dev-driver_data == usb_generic_driver_data)) {
+ dev-power.power_state.event = PM_EVENT_FREEZE;
return 0;
+ }
intf = to_usb_interface(dev);
driver = to_usb_driver(dev-driver);
@@ -1433,6 +1435,7 @@ static int usb_generic_suspend(struct de
} else {
// FIXME else if there's no suspend method, disconnect...
dev_warn(dev, no %s?\n, suspend);
+ mark_quiesced(intf);
status = 0;
}
return status;
---
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems? Stop! Download the new AJAX search engine that makes
searching your log files as easy as surfing the web. DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_id=7637alloc_id=16865op=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: [PATCH 00/10] usb-serial: Switches from spin lock to atomic_t.
On Tue, Dec 06, 2005 at 09:56:10AM -0200, Luiz Fernando Capitulino wrote: Greg, Don't get scared. :-) I'm not scared, just not liking this patch series at all. In the end, it's just moving from one locking scheme to another. No big deal. The problem is, none of this should be needed at all. We need to move the usb-serial drivers over to use the serial core code. If that happens, then none of this locking is needed. That's the right thing to do, so I'm not going to take this patch series right now because of that. If you all want to work on moving to use the serial core, I would love to see that happen. thanks, greg k-h --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://ads.osdn.com/?ad_id=7637alloc_id=16865op=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: [PATCH 00/10] usb-serial: Switches from spin lock to atomic_t.
On Wed, 7 Dec 2005 08:41:18 -0800 Greg KH [EMAIL PROTECTED] wrote: | On Tue, Dec 06, 2005 at 09:56:10AM -0200, Luiz Fernando Capitulino wrote: | Greg, | | Don't get scared. :-) | | I'm not scared, just not liking this patch series at all. | | In the end, it's just moving from one locking scheme to another. No big | deal. I understand. | The problem is, none of this should be needed at all. We need to move | the usb-serial drivers over to use the serial core code. If that | happens, then none of this locking is needed. | | That's the right thing to do, so I'm not going to take this patch series | right now because of that. If you all want to work on moving to use the | serial core, I would love to see that happen. If it's the right thing to do, I'll love to work on that. :) There is only one problem though, I've never touched in the serial core. It means I'll need some time to do it, and maybe the first tries can be wrong. Any tips you have in mind are very welcome. Eduardo, let's do it? :) -- Luiz Fernando N. Capitulino --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://ads.osdn.com/?ad_id=7637alloc_id=16865op=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: [PATCH 00/10] usb-serial: Switches from spin lock to atomic_t.
Greg KH [EMAIL PROTECTED] writes: That's the right thing to do, so I'm not going to take this patch series right now because of that. If you all want to work on moving to use the serial core, I would love to see that happen. But wouldn't be better to have this intermediary solution merged while someone work on this conversion? -- O T A V I OS A L V A D O R - E-mail: [EMAIL PROTECTED] UIN: 5906116 GNU/Linux User: 239058 GPG ID: 49A5F855 Home Page: http://www.freedom.ind.br/otavio - Microsoft gives you Windows ... Linux gives you the whole house. --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://ads.osdn.com/?ad_id=7637alloc_id=16865op=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: [PATCH 00/10] usb-serial: Switches from spin lock to atomic_t.
On Wed, Dec 07, 2005 at 02:55:07PM -0200, Otavio Salvador wrote: Greg KH [EMAIL PROTECTED] writes: That's the right thing to do, so I'm not going to take this patch series right now because of that. If you all want to work on moving to use the serial core, I would love to see that happen. But wouldn't be better to have this intermediary solution merged while someone work on this conversion? No, why do you say that? It doesn't fix a bug at all, and it isn't a solution to any existing problem. thanks, greg k-h --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://ads.osdn.com/?ad_id=7637alloc_id=16865op=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: [PATCH 00/10] usb-serial: Switches from spin lock to atomic_t.
On Wed, Dec 07, 2005 at 02:51:13PM -0200, Luiz Fernando Capitulino wrote: On Wed, 7 Dec 2005 08:41:18 -0800 Greg KH [EMAIL PROTECTED] wrote: | On Tue, Dec 06, 2005 at 09:56:10AM -0200, Luiz Fernando Capitulino wrote: | Greg, | | Don't get scared. :-) | | I'm not scared, just not liking this patch series at all. | | In the end, it's just moving from one locking scheme to another. No big | deal. I understand. | The problem is, none of this should be needed at all. We need to move | the usb-serial drivers over to use the serial core code. If that | happens, then none of this locking is needed. | | That's the right thing to do, so I'm not going to take this patch series | right now because of that. If you all want to work on moving to use the | serial core, I would love to see that happen. If it's the right thing to do, I'll love to work on that. :) There is only one problem though, I've never touched in the serial core. It means I'll need some time to do it, and maybe the first tries can be wrong. Any tips you have in mind are very welcome. I have a small question: in my view, this patch series is a small step towards implementing the usb-serial drivers The Right Way, as it removes a a bit of duplicated code. If we start to do The Big Change to serial_core , probably we would make further refactorings on these parts, going towards The Right Way to implement the drivers. My question would be: where would the small refactorings belong, while the big change to serial_core is work in progress? I would like them to go to some tree for testing, while the work is being done, instead of pushing lots of changes later, but I don't know if there is someone who we could send them. Eduardo, let's do it? :) I would love it, but I will be on vacations in two weeks. So, probably on January. My wife is lucky that I won't have a notebook available during our vacations. 8) -- Eduardo pgpnpqqFQ5mYH.pgp Description: PGP signature
Re: [linux-usb-devel] usblp suspend failure with 2.6.15-rc5
Alan Stern schrieb:
Darn it. There were two problem pathways in that code and the patch
changed the wrong one. Okay, this patch changes both.
Bear in mind that this is just a temporary band-aid. The real problem is
that the usblp driver doesn't have any suspend/resume support. That still
needs to be fixed.
If you don't feel like using the patch below, you can simply rmmod usblp
before suspending and modprobe usblp after resuming. That's actually a
safer approach.
Alan Stern
Index: linux-2.6.15-rc3/drivers/usb/core/usb.c
===
--- linux-2.6.15-rc3.orig/drivers/usb/core/usb.c
+++ linux-2.6.15-rc3/drivers/usb/core/usb.c
@@ -1414,8 +1414,10 @@ static int usb_generic_suspend(struct de
}
if ((dev-driver == NULL) ||
- (dev-driver_data == usb_generic_driver_data))
+ (dev-driver_data == usb_generic_driver_data)) {
+ dev-power.power_state.event = PM_EVENT_FREEZE;
return 0;
+ }
intf = to_usb_interface(dev);
driver = to_usb_driver(dev-driver);
@@ -1433,6 +1435,7 @@ static int usb_generic_suspend(struct de
} else {
// FIXME else if there's no suspend method, disconnect...
dev_warn(dev, no %s?\n, suspend);
+ mark_quiesced(intf);
status = 0;
}
return status;
This patch fixes it. dmesg log follows:
drivers/usb/class/usblp.c: usblp0: USB Bidirectional printer dev 2 if 0 alt 0
proto 2 vid 0x04E8 pid 0x3242
usbcore: registered new driver usblp
drivers/usb/class/usblp.c: v0.13: USB Printer Device Class driver
[...]
PM: Preparing system for mem sleep
Stopping tasks: =|
usblp 2-2:1.0: no suspend?
ACPI: PCI interrupt for device :02:01.1 disabled
ACPI: PCI interrupt for device :02:01.0 disabled
ACPI: PCI interrupt for device :01:00.0 disabled
ACPI: PCI interrupt for device :00:1f.5 disabled
ACPI: PCI interrupt for device :00:1d.7 disabled
ACPI: PCI interrupt for device :00:1d.2 disabled
ACPI: PCI interrupt for device :00:1d.1 disabled
ACPI: PCI interrupt for device :00:1d.0 disabled
PM: Entering mem sleep
Intel machine check architecture supported.
Intel machine check reporting enabled on CPU#0.
Back to C!
PM: Finishing wakeup.
ACPI: PCI Interrupt :00:1d.0[A] - Link [LNKA] - GSI 5 (level, low) - IRQ
5
PCI: Setting latency timer of device :00:1d.0 to 64
ACPI: PCI Interrupt :00:1d.1[B] - Link [LNKD] - GSI 11 (level, low) -
IRQ 11
PCI: Setting latency timer of device :00:1d.1 to 64
ACPI: PCI Interrupt :00:1d.2[C] - Link [LNKC] - GSI 5 (level, low) - IRQ
5
PCI: Setting latency timer of device :00:1d.2 to 64
ACPI: PCI Interrupt :00:1d.7[D] - Link [LNKH] - GSI 11 (level, low) -
IRQ 11
PCI: Setting latency timer of device :00:1d.7 to 64
PCI: Setting latency timer of device :00:1e.0 to 64
ACPI: PCI Interrupt :00:1f.1[A] - Link [LNKC] - GSI 5 (level, low) - IRQ
5
ACPI: PCI Interrupt :00:1f.5[B] - Link [LNKB] - GSI 5 (level, low) - IRQ
5
PCI: Setting latency timer of device :00:1f.5 to 64
PCI: Enabling device :01:00.0 ( - 0003)
ACPI: PCI Interrupt :01:00.0[A] - Link [LNKA] - GSI 5 (level, low) - IRQ
5
PCI: Setting latency timer of device :01:00.0 to 64
eth0: link down
ACPI: PCI Interrupt :02:01.0[A] - Link [LNKB] - GSI 5 (level, low) - IRQ
5
ACPI: PCI Interrupt :02:01.1[B] - Link [LNKA] - GSI 5 (level, low) - IRQ
5
ACPI: PCI Interrupt :02:01.2[C] - Link [LNKC] - GSI 5 (level, low) - IRQ
5
eth0: link up, 100Mbps, full-duplex, lpa 0x45E1
usblp 2-2:1.0: no resume?
Restarting tasks...6usb 2-2: USB disconnect, address 2
drivers/usb/class/usblp.c: usblp0: removed
done
usb 2-2: new full speed USB device using uhci_hcd and address 3
drivers/usb/class/usblp.c: usblp0: USB Bidirectional printer dev 3 if 0 alt 0
proto 2 vid 0x04E8 pid 0x3242
Please send the patch above for inclusion in 2.6.15.
Thanks for your help!
Carl-Daniel
---
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems? Stop! Download the new AJAX search engine that makes
searching your log files as easy as surfing the web. DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_id=7637alloc_id=16865op=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] Error recovery in Xen's paravirtualizing USB driver for Linux
USB Folks, I've been working on a USB device driver for Linux running paravirtualized on the Xen hypervisor and I have a few questions about the design of the error recovery... This 'USB split driver' has a 'front-end' in the Linux kernel running in a guest domain of the hypervisor and a 'back-end' in the Linux kernel running in a device driver domain (usually the special privilidged domain 0). The user configures Xen to map a USB port from the back-end domain to the front-end domain and the split driver makes any USB device attached to the back-end port available in the front-end domain. The split driver works roughly as follows: o - The back-end uses usb_register to register itself as a driver matching all USB IDs so it gets probed for every USB device that is connected. When a USB device is probed for a configured port, the driver claims all the interfaces for the device. o - The front-end uses usb_create_hcd to create a HCD with a single port. o - The front-end and the back-end communicate using the Xen inter-domain communication primitives so the hub status in the front-end reflects whether or not a device is plugged into the back-end port. o - URBs received by the front-end HCD are translated into Xen inter-domain-communication primitives and routed to the back-end domain. o - The inter-domain communication primitives are translated back into URBs in the back-end and submitted to the Linux USB stack for the device attached to the back-end port. The split driver now works well enough to mount a filesystem on a USB key in the front-end domain so it's getting there. I did have a problem with URBs getting reordered on their way between the front-end and the back-end which led to miscompares where the correct bulk data was written on the USB key but at the wrong LBA. I fixed this by maintaining submission ordering in the URB queue from front-end to back-end. This issue made me realize there was a similar problem during error recovery if an URB fails when there are several in flight and indeed, reading the recent USB code, there is a big comment about the guarantees a driver gets on an error: the URB queue stalls until the driver's completion handler returns from completion of the failing URB and any URBs unlinked during completion of the failing URB. Right now, if there is an error on an URB in my USB split driver back-end then the back-end completion handler returns before the front end USB driver client's completion handler gets a chance to do any unlinks so the URBs are not stalled and my driver is broken. I'm trying to work out how to fix it. I'm thinking of doing the following: When there is an error returned by an URB in the back-end, the completion handler of the back end will unlink all of the URBs in progress for the endpoint of the failing URB and set a 'fail_urb' flag for the endpoint to fail back any URBs which arrive subsequently for that endpoint until the 'fail_urb' flag is reset. Whenever the front-end completion handler returns from completing an URB back to the client and finds that an endpoint has gone idle it will set a flag to indicate that the next URB sent to the back-end for that endpoint should clear the 'fail_urb' flag in the back end before starting. This strategy is similar to the concept of auto contingent allegiance for SCSI. My questions are as follows: 1) I think it is impossible to maintain exactly the same guarantee that the Linux USB stack provides across the Xen inter-domain interface because I don't think it is desirable to attempt the synchronisation of the two kernels in different domains required to nest the call of the front end completion within the call of the back end completion. Is this correct? 2) I believe the above strategy to be more conservative than the Linux guarantee and sufficient to avoid miscompares due to re-ordering as a result of URBs failing whilst there are multiple URBs in flight. Is this correct? 3) I think the above strategy is compatible with the suggested recovery mechanism for Linux USB drivers which is to unlink outstanding URBs in the URB completion handler. Is the above strategy likely to work? 4) I'm wondering what error to fail URBs with when 'fail_urb' is set. I'm guessing either -ECONNRESET which is the same as if the URB was unlinked or perhaps -EAGAIN. What would be the correct value? 5) Is there a more USBish way to solve this problem that will fit better with the USB infrastructure. 6) Any other ideas? Thanks for your help! Harry Butterworth --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://ads.osdn.com/?ad_id=7637alloc_id=16865op=click ___
[linux-usb-devel] Re: [PATCH 00/10] usb-serial: Switches from spin lock to atomic_t.
On Wed, Dec 07, 2005 at 03:13:32PM -0200, Eduardo Pereira Habkost wrote: I have a small question: in my view, this patch series is a small step towards implementing the usb-serial drivers The Right Way, as it removes a a bit of duplicated code. It doesn't remove any duplicated code, it only changes a spinlock to an atomic_t for one single value (which I personally do not think is the best thing to do, and based on the number of comments on this thread, I think others also feel this way.) If we start to do The Big Change to serial_core , probably we would make further refactorings on these parts, going towards The Right Way to implement the drivers. Sure, that's the way kernel development is done. My question would be: where would the small refactorings belong, while the big change to serial_core is work in progress? I would like them to go to some tree for testing, while the work is being done, instead of pushing lots of changes later, but I don't know if there is someone who we could send them. The normal way of doing work like this is, do it somewhere, and then break it all down into a series of steps, after you have figured out exactly where you are going to end up. Feel free to send me any patches that you feel should be applied that work toward this end goal. thanks, greg k-h --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://ads.osdn.com/?ad_id=7637alloc_id=16865op=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] SubClass and Protocol entries
Le mercredi 07 décembre 2005 à 10:16 -0500, Alan Stern a écrit : On Wed, 7 Dec 2005, Marwan Cyril Sabra wrote: [4296233.326000] usb-storage: This device (0482,0105,0100 S 06 P 50) has unneede d SubClass and Protocol entries in unusual_devs.h [4296233.326000]Please send a copy of this message to [EMAIL PROTECTED] .sourceforge.net Phil, this isn't fixed in my kernel source. It's worthwhile checking with the original submitters of this entry. Either it's not needed at all or else it requires a US_FL_NEED_OVERRIDE. Alan Stern If you guys need anything (more info), let me know :) Cyril -- Marwan Cyril Sabra 15, rue ALfred Brinon 69100 Villeurbanne Courriel: [EMAIL PROTECTED] Téléphone: 0033(0)4-78-84-64-25 Mobile: 0033(0)6-13-66-15-96 --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://ads.osdn.com/?ad_id=7637alloc_id=16865op=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: [PATCH 00/10] usb-serial: Switches from spin lock to atomic_t.
Hi, Greg, On Wed, Dec 07, 2005 at 09:56:14AM -0800, Greg KH wrote: On Wed, Dec 07, 2005 at 03:13:32PM -0200, Eduardo Pereira Habkost wrote: I have a small question: in my view, this patch series is a small step towards implementing the usb-serial drivers The Right Way, as it removes a a bit of duplicated code. It doesn't remove any duplicated code, it only changes a spinlock to an atomic_t for one single value (which I personally do not think is the best thing to do, and based on the number of comments on this thread, I think others also feel this way.) Every usb-serial driver currently has: spin_lock(port-lock); if (port-write_urb_busy) return; port-write_urb_busy = 1; spin_unlock(port-lock); Having the same 5 lines on many usb-serial drivers looks like duplicated code to me. Maybe I am being too exigent. Anyway, this is unrelated to the atomic_t change, and we could do it without dropping ths spinlock. But I would like to know: would you would accept such change (that encapsulate this write_urb_busy logic without necessarily dropping the spinlock)? And, about the atomic_t: I've felt most people didn't liked the atomic_t approach for one of two reasons: 1. The existence of write_urb_busy looks like a hack, and we've make it explicit when we isolated the code that uses write_urb_busy in a set of functions (the point of Arjan in his square wheel comment) 2. The whole discussion about atomic_t vs. spinlock efficiency I agree with (1), but I still don't see why using a spinlock to protect a single field is better than using atomic_t. Both in code readability and efficiency. Specially as the difference between each one (even which one is more efficient) is very arch-specific. Thank you very much for your advice, -- Eduardo pgpGRjZdQATJE.pgp Description: PGP signature
[linux-usb-devel] How to handle drivers with no suspend/resume method?
Dave: We need to settle on a policy for handling USB drivers that don't have suspend/resume support. The current code in 2.6.15-rc returns 0 for the interface suspend call but doesn't change the interface's power_state value. As a result, the suspend call for the device fails, aborting the entire system sleep transition. We could not worry about it and call mark_quiesced for the interface. Or we could unbind the driver, in accord with a FIXME comment (although there are locking issues). One or the other is necessary before 2.6.15 is released; otherwise there will be lots of complaints about USB updates breaking suspend. Alan Stern --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://ads.osdn.com/?ad_id=7637alloc_id=16865op=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] Error recovery in Xen's paravirtualizing USB driver for Linux
On Wed, 7 Dec 2005, harry wrote: USB Folks, I've been working on a USB device driver for Linux running paravirtualized on the Xen hypervisor and I have a few questions about the design of the error recovery... This 'USB split driver' has a 'front-end' in the Linux kernel running in a guest domain of the hypervisor and a 'back-end' in the Linux kernel running in a device driver domain (usually the special privilidged domain 0). The user configures Xen to map a USB port from the back-end domain to the front-end domain and the split driver makes any USB device attached to the back-end port available in the front-end domain. The split driver works roughly as follows: o - The back-end uses usb_register to register itself as a driver matching all USB IDs so it gets probed for every USB device that is connected. When a USB device is probed for a configured port, the driver claims all the interfaces for the device. o - The front-end uses usb_create_hcd to create a HCD with a single port. o - The front-end and the back-end communicate using the Xen inter-domain communication primitives so the hub status in the front-end reflects whether or not a device is plugged into the back-end port. o - URBs received by the front-end HCD are translated into Xen inter-domain-communication primitives and routed to the back-end domain. o - The inter-domain communication primitives are translated back into URBs in the back-end and submitted to the Linux USB stack for the device attached to the back-end port. The split driver now works well enough to mount a filesystem on a USB key in the front-end domain so it's getting there. I did have a problem with URBs getting reordered on their way between the front-end and the back-end which led to miscompares where the correct bulk data was written on the USB key but at the wrong LBA. I fixed this by maintaining submission ordering in the URB queue from front-end to back-end. Clearly this is necessary for any queue, not just queues of USB URBs. This issue made me realize there was a similar problem during error recovery if an URB fails when there are several in flight and indeed, reading the recent USB code, there is a big comment about the guarantees a driver gets on an error: the URB queue stalls until the driver's completion handler returns from completion of the failing URB and any URBs unlinked during completion of the failing URB. Right now, if there is an error on an URB in my USB split driver back-end then the back-end completion handler returns before the front end USB driver client's completion handler gets a chance to do any unlinks so the URBs are not stalled and my driver is broken. I'm trying to work out how to fix it. I'm thinking of doing the following: When there is an error returned by an URB in the back-end, the completion handler of the back end will unlink all of the URBs in progress for the endpoint of the failing URB and set a 'fail_urb' flag for the endpoint to fail back any URBs which arrive subsequently for that endpoint until the 'fail_urb' flag is reset. Whenever the front-end completion handler returns from completing an URB back to the client and finds that an endpoint has gone idle it will set a flag to indicate that the next URB sent to the back-end for that endpoint should clear the 'fail_urb' flag in the back end before starting. Failing isn't the right approach. The back-end should unlink all those URBs but keep them available, so that they can be resubmitted if necessary. When the front-end learns about the error, it has the option of unlinking the URBs or not -- if it doesn't unlink them then the back-end should resubmit them. Likewise for URBs received from the front end before the flag is cleared; they should be kept on the queue so that they can be submitted when the front-end's completion routine returns. This strategy is similar to the concept of auto contingent allegiance for SCSI. My questions are as follows: 1) I think it is impossible to maintain exactly the same guarantee that the Linux USB stack provides across the Xen inter-domain interface because I don't think it is desirable to attempt the synchronisation of the two kernels in different domains required to nest the call of the front end completion within the call of the back end completion. Is this correct? That is not a USB question; it has more to do with the organization of Xen. I don't know enough about Xen to answer fully. But if this inter-kernel synchronization requires any kind of sleeping, then you can't use it in the context of a USB completion routine. 2) I believe the above strategy to be more conservative than the Linux guarantee and sufficient to avoid miscompares due to re-ordering as a result of URBs failing whilst there are multiple URBs in flight. Is this correct? Forget about miscompares; you
Re: [linux-usb-devel] Error recovery in Xen's paravirtualizing USB driver for Linux
On Wed, 2005-12-07 at 14:35 -0500, Alan Stern wrote: I did have a problem with URBs getting reordered on their way between the front-end and the back-end which led to miscompares where the correct bulk data was written on the USB key but at the wrong LBA. I fixed this by maintaining submission ordering in the URB queue from front-end to back-end. Clearly this is necessary for any queue, not just queues of USB URBs. Some queues, for example sets of SCSI queue simple commands, are allowed to be reordered. This is useful for rotational position optimisation on single disk drives and concurrency on RAID arrays. Ordering makes sense for USB though---it just didn't click with me immediately. Failing isn't the right approach. The back-end should unlink all those URBs but keep them available, so that they can be resubmitted if necessary. When the front-end learns about the error, it has the option of unlinking the URBs or not -- if it doesn't unlink them then the back-end should resubmit them. Likewise for URBs received from the front end before the flag is cleared; they should be kept on the queue so that they can be submitted when the front-end's completion routine returns. Thanks. This is exactly the information I was looking for. Suspend/resume is liable to cause trouble. For instance, what happens to the various front-ends if the back-end decides to suspend a USB device? I don't know. Could you explain this scenario in more detail (imagine that none of the 800 page USB spec sunk in when I read it :-). What should happen in this case? -- Harry Butterworth [EMAIL PROTECTED] --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://ads.osdn.com/?ad_id=7637alloc_id=16865op=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: Error recovery in Xen's paravirtualizing USB driver for Linux
On Wed, 07 Dec 2005 18:31:17 +, harry [EMAIL PROTECTED] wrote: This 'USB split driver' has a 'front-end' in the Linux kernel running in a guest domain of the hypervisor and a 'back-end' in the Linux kernel running in a device driver domain (usually the special privilidged domain 0). Why don't you just let guest 0 to own the controller? This is what the guest 0 is for, as far as I know. If you create special stub drivers in the hypervisor, you might as well create virtual USB controllers for nonzero guests. o - The back-end uses usb_register to register itself as a driver matching all USB IDs so it gets probed for every USB device that is connected. When a USB device is probed for a configured port, the driver claims all the interfaces for the device. Ewww! Ewww! You are just going to hit all the difficulties the vmware guy hit, perhaps minus the size limitation in usbfs since you are bypassing it. I would expect that the scheme you're proposing were employed to let non-zero guests to drive some virtualized devices, but not for the guest zero. -- Pete --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://ads.osdn.com/?ad_id=7637alloc_id=16865op=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] Re: Error recovery in Xen's paravirtualizing USB driver for Linux
On Wed, 2005-12-07 at 15:00 -0800, Pete Zaitcev wrote: On Wed, 07 Dec 2005 18:31:17 +, harry [EMAIL PROTECTED] wrote: This 'USB split driver' has a 'front-end' in the Linux kernel running in a guest domain of the hypervisor and a 'back-end' in the Linux kernel running in a device driver domain (usually the special privilidged domain 0). Why don't you just let guest 0 to own the controller? This is what the guest 0 is for, as far as I know. Guest 0 normally owns the controller. Xen also has a concept of driver domains where you give a PCI device to a privileged guest other than 0 and run the driver in that guest. This is useful for driver development amongst other things. If you create special stub drivers in the hypervisor, you might as well create virtual USB controllers for nonzero guests. The stub drivers are not in the hypervisor but are for the Linux kernels run in the hypervisor virtual machines (domains). Yes, the front-end driver in the non-zero guest creates a virtual USB controller. o - The back-end uses usb_register to register itself as a driver matching all USB IDs so it gets probed for every USB device that is connected. When a USB device is probed for a configured port, the driver claims all the interfaces for the device. Ewww! Ewww! What should I be doing? You are just going to hit all the difficulties the vmware guy hit, What were they? perhaps minus the size limitation in usbfs since you are bypassing it. I would expect that the scheme you're proposing were employed to let non-zero guests to drive some virtualized devices, but not for the guest zero. Yes, it's for letting non-zero guest domains run USB drivers for devices attached to ports on USB controllers which are driven by domain 0. So, for example you can have one physical USB port, plug in a four port USB HUB and then map one port on the HUB to each of four guest domains. Any device plugged into the port mapped to a given guest domain will appear attached to a port on the virtual USB controller in the guest domain. USB devices in domain zero are just driven by the normal USB driver code. My split driver is not involved. Sorry for not being clear. Harry. -- Harry Butterworth [EMAIL PROTECTED] --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://ads.osdn.com/?ad_id=7637alloc_id=16865op=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: usbserial power OFF/ON issue
On Wed, Dec 07, 2005 at 06:01:16PM +0530, [EMAIL PROTECTED] wrote: Hi Greg, I have some doubts on usbserial driver with respect to connect and disconnect functions. I'm using Kermit application to communicate with the device, when I'm powering off the mobile, mobile is disconnecting and connecting it back, hence the file descriptor on which Kermit is opened is getting closed and not allowed to do further operations. Same scenario when I tried with windows OS using hyper terminal, after powering off the mobile, still the application exists and just after few seconds we can continue working with the same terminal window. How can we achieve this in Linux? or is it possible ? I hope you understand this. I'm sorry, but I do not understand the problem. The device is turned off, right? What happens to your program then? And please do not post using html email, the linux-usb-devel mailing list will reject such messages. thansk, greg k-h --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://ads.osdn.com/?ad_id=7637alloc_id=16865op=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: How to handle drivers with no suspend/resume method?
On Wednesday 07 December 2005 11:19 am, Alan Stern wrote: Dave: We need to settle on a policy for handling USB drivers that don't have suspend/resume support. The current code in 2.6.15-rc returns 0 for the interface suspend call but doesn't change the interface's power_state value. As a result, the suspend call for the device fails, aborting the entire system sleep transition. It could return a failure code, not zero. ;) We could not worry about it and call mark_quiesced for the interface. Or Except ... that it is NOT quiesced. That driver might just go issue an URB right away. Having the infrastructure going about lying about things like that would be error prone... A better option might be to mark the device dead/disconnected. None of the invariants would be broken, and the behavior is one that should already be well tested (on resume). And suspend could still work. we could unbind the driver, in accord with a FIXME comment (although there are locking issues). One or the other is necessary before 2.6.15 is released; otherwise there will be lots of complaints about USB updates breaking suspend. Yes, my patch for the FIXME thing was DOA because of locking problems. My notes say: ... driver core suspend() calls are made with dev-sem held, which means calls to usb_driver_release_interface() always deadlock when they try to claim the same lock. So I'm afraid that early disconnect won't work, and it'll have to be done later (by khubd after resume). - Dave --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://ads.osdn.com/?ad_id=7637alloc_id=16865op=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] Separate EHCI core code from bus glue logic (take 2)
On Tue, Dec 06, 2005 at 05:24:59PM -0800, Deepak Saxena wrote: I need to implement support for the on-chip EHCI HCD on the Intel IXP46x NPU and being on-chip, it is clearly !PCI. The existing EHCI code ties the bus glue and core together and makes it rather difficult to add a non-PCI HCD underneath. This patch attempts to get around this by creating a new ehci-pci module that hooks into the EHCI core via appropriate glue functions and also cleans up the debug support code while at it. We also export the ehci_tdi_reset() function as the IXP46x is basically a TDI implementation attached to the CPU bus (oh and it is the wrong endianess, but we won't go there yet). Signed-off-by: Deepak Saxena [EMAIL PROTECTED] --- Added MODULE_* macros to ehci-pci and some more small cleanups. So this is the better version? David, any objections to this? thanks, greg k-h --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://ads.osdn.com/?ad_id=7637alloc_id=16865op=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: usbserial power OFF/ON issue
Hi Greg, The Kermit application closes once the mobile is turned off (using AT+CFUN=0 command or any manually turn off the mobile) and it does not allows to perform any further operation. Our observation on this is after powering the mobile off disconnect function is called and the file descriptor becomes invalid. But in case of windows OS we don't see this problem after switching off the mobile using hyper terminal and we can still continue with the same hyper terminal for further operations. How can we achieve this in Linux OS? I hope you understood this and please give suggestions on this as soon as possible. Regards, Shalini G -Original Message- From: Greg KH [mailto:[EMAIL PROTECTED] Sent: Thursday, December 08, 2005 6:55 AM To: Shalini Rao (WT01 - Voice Next Generation Networks) Cc: linux-usb-devel@lists.sourceforge.net; Nitin Goel (WT01 - Voice Next Generation Networks); Sandhya Adabala (WT01 - Voice Next Generation Networks) Subject: Re: usbserial power OFF/ON issue On Wed, Dec 07, 2005 at 06:01:16PM +0530, [EMAIL PROTECTED] wrote: Hi Greg, I have some doubts on usbserial driver with respect to connect and disconnect functions. I'm using Kermit application to communicate with the device, when I'm powering off the mobile, mobile is disconnecting and connecting it back, hence the file descriptor on which Kermit is opened is getting closed and not allowed to do further operations. Same scenario when I tried with windows OS using hyper terminal, after powering off the mobile, still the application exists and just after few seconds we can continue working with the same terminal window. How can we achieve this in Linux? or is it possible ? I hope you understand this. I'm sorry, but I do not understand the problem. The device is turned off, right? What happens to your program then? And please do not post using html email, the linux-usb-devel mailing list will reject such messages. thansk, greg k-h --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://ads.osdn.com/?ad_idv37alloc_id865op=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] Oops in 2.6.15-rc4 while opening FT2232C device
Hi. Seems like some bug in usb-serial layer - the USB link was receiving data (zeroes) at the high speed, from FT2232C second port, configured as 245 FIFO. While connecting to /dev/tts/USB1 setting link opts got this oops. Rus serial_oops.bz2 Description: Binary data
[linux-usb-devel] Fwd: numerous usb isses (ehci not working, c.)
-- Forwarded message -- From: Travis H. [EMAIL PROTECTED] Date: Dec 3, 2005 7:48 PM Subject: numerous usb isses (ehci not working, c.) To: linux-usb-users@lists.sourceforge.net Hi, I'm going to lump a bunch of things into one email to save your patience. kernel: 2.6.13 SMP First, my PCI card probes as ehci but doesn't really seem to work very well: $ cat /proc/bus/usb/devices T: Bus=04 Lev=00 Prnt=00 Port=00 Cnt=00 Dev#= 1 Spd=480 MxCh= 4 B: Alloc= 0/800 us ( 0%), #Int= 0, #Iso= 0 D: Ver= 2.00 Cls=09(hub ) Sub=00 Prot=01 MxPS= 8 #Cfgs= 1 P: Vendor= ProdID= Rev= 2.06 S: Manufacturer=Linux 2.6.13-rc6-3124-smp ehci_hcd S: Product=EHCI Host Controller S: SerialNumber=:02:06.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= 2 Ivl=256ms T: Bus=03 Lev=00 Prnt=00 Port=00 Cnt=00 Dev#= 1 Spd=12 MxCh= 2 B: Alloc= 0/900 us ( 0%), #Int= 0, #Iso= 0 D: Ver= 1.10 Cls=09(hub ) Sub=00 Prot=00 MxPS= 8 #Cfgs= 1 P: Vendor= ProdID= Rev= 2.06 S: Manufacturer=Linux 2.6.13-rc6-3124-smp uhci_hcd S: Product=UHCI Host Controller S: SerialNumber=:02:06.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(I) Atr=03(Int.) MxPS= 2 Ivl=255ms T: Bus=02 Lev=00 Prnt=00 Port=00 Cnt=00 Dev#= 1 Spd=12 MxCh= 2 B: Alloc= 0/900 us ( 0%), #Int= 0, #Iso= 0 D: Ver= 1.10 Cls=09(hub ) Sub=00 Prot=00 MxPS= 8 #Cfgs= 1 P: Vendor= ProdID= Rev= 2.06 S: Manufacturer=Linux 2.6.13-rc6-3124-smp uhci_hcd S: Product=UHCI Host Controller S: SerialNumber=:02:06.0 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= 2 Ivl=255ms T: Bus=01 Lev=00 Prnt=00 Port=00 Cnt=00 Dev#= 1 Spd=12 MxCh= 2 B: Alloc= 0/900 us ( 0%), #Int= 0, #Iso= 0 D: Ver= 1.10 Cls=09(hub ) Sub=00 Prot=00 MxPS= 8 #Cfgs= 1 P: Vendor= ProdID= Rev= 2.06 S: Manufacturer=Linux 2.6.13-rc6-3124-smp uhci_hcd S: Product=UHCI Host Controller S: SerialNumber=:00:07.2 C:* #Ifs= 1 Cfg#= 1 Atr=c0 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= 2 Ivl=255ms relevant lspci -v output: 00:07.2 USB Controller: Intel Corp. 82371AB/EB/MB PIIX4 USB (rev 01) (prog-if 00 [UHCI]) Flags: bus master, medium devsel, latency 64, IRQ 19 I/O ports at dce0 [size=32] 02:06.0 USB Controller: VIA Technologies, Inc. VT82x UHCI USB 1.1 Controller (rev 61) (prog-if 00 [UHCI]) Subsystem: VIA Technologies, Inc. VT82x UHCI USB 1.1 Controller Flags: bus master, medium devsel, latency 64, IRQ 18 I/O ports at ece0 [size=32] Capabilities: [80] Power Management version 2 02:06.1 USB Controller: VIA Technologies, Inc. VT82x UHCI USB 1.1 Controller (rev 61) (prog-if 00 [UHCI]) Subsystem: VIA Technologies, Inc. VT82x UHCI USB 1.1 Controller Flags: bus master, medium devsel, latency 64, IRQ 19 I/O ports at ecc0 [size=32] Capabilities: [80] Power Management version 2 02:06.2 USB Controller: VIA Technologies, Inc. USB 2.0 (rev 63) (prog-if 20 [EHCI]) Subsystem: VIA Technologies, Inc. USB 2.0 Flags: bus master, medium devsel, latency 64, IRQ 16 Memory at fafffc00 (32-bit, non-prefetchable) [size=256] Capabilities: [80] Power Management version 2 # cat /proc/interrupts | grep -i usb; sleep 10; cat /proc/interrupts | grep -i usb 16: 6 29 IO-APIC-level ehci_hcd:usb4 18:32001273561228 IO-APIC-level uhci_hcd:usb2 19:7971448 13299277 IO-APIC-level libata, uhci_hcd:usb1, uhci_hcd:usb3 16: 6 29 IO-APIC-level ehci_hcd:usb4 18:32001273561228 IO-APIC-level uhci_hcd:usb2 19:7971448 13301709 IO-APIC-level libata, uhci_hcd:usb1, uhci_hcd:usb3 Typical errors: usb 4-4: new high speed USB device using ehci_hcd and address 6 usb 4-4: khubd timed out on ep0out len=0/0 usb 4-4: khubd timed out on ep0out len=0/0 usb 4-4: device not accepting address 6, error -110 hub 4-0:1.0: state 5 ports 4 chg evt hub 3-0:1.0: state 5 ports 2 chg evt 0002 uhci_hcd :02:06.1: port 1 portsc 01a3,00 hub 3-0:1.0: port 1, status 0301, change 0001, 1.5 Mb/s hub 3-0:1.0: debounce: port 1: total 100ms stable 100ms status 0x301 usb 3-1: new low speed USB device using uhci_hcd and address 4 usb 3-1: khubd timed out on ep0in len=0/64 usb 3-1: khubd timed out on ep0in len=0/64 usb 3-1: khubd timed out on ep0in len=0/64 usb 3-1: device descriptor read/64, error -110 usb 3-1: khubd timed out on ep0in len=0/64 ehci_hcd :02:06.2: remove, state 1 ehci_hcd :02:06.2: roothub graceful disconnect usb 3-1: khubd timed out on ep0in len=0/64 usb 3-1: khubd timed out on ep0in len=0/64 usb 3-1: device descriptor read/64, error -110 usb 3-1: new low speed
