[linux-usb-devel] [UHCI] deadlock when interrupts are broken
Hi:
The UHCI driver only cleans up removed QH/TD/URB entries in the interrupt
routine. This means that if the interrupts aren't working for whatever
reason (in my case it's a bug in suspend/resume), these entries will never
be cleaned up. This can easily cause deadlocks if you unlink an URB and
then wait for it to be given back.
This patch fixes this by making the unlink schedule a tasklet to do the
cleanup rather than triggering an interrupt.
Cheers,
--
Debian GNU/Linux 3.0 is out! ( http://www.debian.org/ )
Email: Herbert Xu ~{PmV>HI~} <[EMAIL PROTECTED]>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Index: kernel-2.5/drivers/usb/host/uhci-hcd.c
===
RCS file:
/home/gondolin/herbert/src/CVS/debian/kernel-source-2.5/drivers/usb/host/uhci-hcd.c,v
retrieving revision 1.1.1.14
diff -u -r1.1.1.14 uhci-hcd.c
--- kernel-2.5/drivers/usb/host/uhci-hcd.c 17 Oct 2003 21:43:29 -
1.1.1.14
+++ kernel-2.5/drivers/usb/host/uhci-hcd.c 6 Dec 2003 11:30:41 -
@@ -90,6 +90,7 @@
static int uhci_get_current_frame_number(struct uhci_hcd *uhci);
static int uhci_urb_dequeue(struct usb_hcd *hcd, struct urb *urb);
static void uhci_unlink_generic(struct uhci_hcd *uhci, struct urb *urb);
+static void uhci_irq_tail(struct usb_hcd *hcd, struct pt_regs *regs);
static void hc_state_transitions(struct uhci_hcd *uhci);
@@ -112,11 +113,7 @@
*/
static inline void uhci_set_next_interrupt(struct uhci_hcd *uhci)
{
- unsigned long flags;
-
- spin_lock_irqsave(&uhci->frame_list_lock, flags);
- uhci->term_td->status |= cpu_to_le32(TD_CTRL_IOC);
- spin_unlock_irqrestore(&uhci->frame_list_lock, flags);
+ tasklet_schedule(&uhci->irq_tasklet);
}
static inline void uhci_clear_next_interrupt(struct uhci_hcd *uhci)
@@ -1905,7 +1902,6 @@
struct uhci_hcd *uhci = hcd_to_uhci(hcd);
unsigned int io_addr = uhci->io_addr;
unsigned short status;
- struct list_head *tmp, *head;
/*
* Read the interrupt status, and write it back to clear the
@@ -1930,14 +1926,22 @@
if (status & USBSTS_RD)
uhci->resume_detect = 1;
+ uhci_clear_next_interrupt(uhci);
+
+ uhci_irq_tail(hcd, regs);
+}
+
+static void uhci_irq_tail(struct usb_hcd *hcd, struct pt_regs *regs)
+{
+ struct uhci_hcd *uhci = hcd_to_uhci(hcd);
+ struct list_head *tmp, *head;
+
uhci_free_pending_qhs(uhci);
uhci_free_pending_tds(uhci);
uhci_remove_pending_qhs(uhci);
- uhci_clear_next_interrupt(uhci);
-
/* Walk the list of pending URB's to see which ones completed */
spin_lock(&uhci->urb_list_lock);
head = &uhci->urb_list;
@@ -1956,6 +1960,13 @@
uhci_finish_completion(hcd, regs);
}
+static void uhci_irq_tasklet(unsigned long data)
+{
+ struct usb_hcd *hcd = (void *)data;
+
+ uhci_irq_tail(hcd, NULL);
+}
+
static void reset_hc(struct uhci_hcd *uhci)
{
unsigned int io_addr = uhci->io_addr;
@@ -2453,14 +2464,11 @@
* At this point, we're guaranteed that no new connects can be made
* to this bus since there are no more parents
*/
- uhci_free_pending_qhs(uhci);
- uhci_free_pending_tds(uhci);
- uhci_remove_pending_qhs(uhci);
reset_hc(uhci);
- uhci_free_pending_qhs(uhci);
- uhci_free_pending_tds(uhci);
+ tasklet_schedule(&uhci->irq_tasklet);
+ tasklet_kill(&uhci->irq_tasklet);
release_uhci(uhci);
}
@@ -2505,6 +2513,8 @@
memset(uhci, 0, sizeof(*uhci));
uhci->hcd.product_desc = "UHCI Host Controller";
+ tasklet_init(&uhci->irq_tasklet, uhci_irq_tasklet,
+(unsigned long)&uhci->hcd);
return &uhci->hcd;
}
Index: kernel-2.5/drivers/usb/host/uhci-hcd.h
===
RCS file:
/home/gondolin/herbert/src/CVS/debian/kernel-source-2.5/drivers/usb/host/uhci-hcd.h,v
retrieving revision 1.1.1.4
diff -u -r1.1.1.4 uhci-hcd.h
--- kernel-2.5/drivers/usb/host/uhci-hcd.h 27 Sep 2003 00:01:59 - 1.1.1.4
+++ kernel-2.5/drivers/usb/host/uhci-hcd.h 6 Dec 2003 10:38:25 -
@@ -3,6 +3,7 @@
#include
#include
+#include
#define usb_packetid(pipe) (usb_pipein(pipe) ? USB_PID_IN : USB_PID_OUT)
#define PIPE_DEVEP_MASK0x0007ff00
@@ -366,6 +367,8 @@
int rh_numports;
struct timer_list stall_timer;
+
+ struct tasklet_struct irq_tasklet;
};
struct urb_priv {
[linux-usb-devel] Re: [OOPS, usbcore, releaseintf] 2.6.0-test10-mm1
Hi Vince, I'm not sure, but it looks like a bug in the USB core. I was kind of expecting this :) My patch causes devio.c to hold a reference to the usb_device maybe long after the device has been disconnected. This is supposed to be OK, but from your Oops it looks like some part of the hcd was finalized too early (before devio.c dropped its reference to the usb_device). Maybe one of the USB guys can comment? All the best, Duncan. On Sunday 07 December 2003 23:54, Vince wrote: > Duncan Sands wrote: > > Hi Vincent, that's great! I think the fix is solid, but can you please > > beat on it a bit just to be sure... > > > > Thanks, > > > > Duncan. > > I'm not sure how to reproduce the previous oops (not even if it was > really related to your patch...), but here follows a real, untainted > oops I finally got: > > [9889]: shutting down for system reboot > printing eip: > c8ae8999 > Oops: [#1] > PREEMPT > CPU:0 > EIP:0060:[]Not tainted VLI > EFLAGS: 00010286 > EIP is at hcd_pci_release+0x19/0x20 [usbcore] > eax: c8c69d80 ebx: c637f050 ecx: c8af6c20 edx: c637f000 > esi: c031e65c edi: c031e680 ebp: c0019ec4 esp: c0019ec0 > ds: 007b es: 007b ss: 0068 > Process modem_run (pid: 8460, threadinfo=c0018000 task=c1508080) > Stack: c637f000 c0019ed0 c8ae455d c637f000 c0019ee8 c0203738 c637f048 > c0019f00 > c8ae77d6 c031e450 c0019f00 c01bc88f c637f050 c6b09200 c031e428 c031e440 > c0019f10 c8ae08b6 c637f050 c0019f2c c02019e1 c6b092cc c0019f2c > Call Trace: > [] usb_host_release+0x1d/0x20 [usbcore] > [] class_dev_release+0x58/0x60 > [] usb_destroy_configuration+0xb6/0xf0 [usbcore] > [] kobject_cleanup+0x6f/0x80 > [] usb_release_dev+0x46/0x60 [usbcore] > [] device_release+0x21/0x80 > [] kobject_cleanup+0x6f/0x80 > [] usbdev_release+0x88/0xc0 [usbcore] > [] __fput+0x10c/0x120 > [] filp_close+0x57/0x80 > [] sys_close+0x61/0x90 > [] sysenter_past_esp+0x43/0x65 > > Code: 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 55 89 e5 83 > ec 04 8b 45 08 8b 50 30 85 d2 74 0c 8b 82 08 01 00 00 89 14 24 50 > 28 c9 c3 89 f6 55 89 e5 57 56 53 83 ec 34 8b 5d 0c e8 3f > <0>Fatal exception: panic in 5 seconds --- This SF.net email is sponsored by: IBM Linux Tutorials. Become an expert in LINUX or just sharpen your skills. Sign up for IBM's Free Linux Tutorials. Learn everything from the bash shell to sys admin. Click now! http://ads.osdn.com/?ad_id=1278&alloc_id=3371&op=click ___ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
[linux-usb-devel] Investment Opportunity
DEAR SIR. PLEASE I AM A BOY OF 25 YEARS AND I AM LOOKING FOR INVESTMENT OPPORTUNITY. I INTENDED TO INVEST THE SUM OF TWENTY MILLION UNITED STATES DOLLARS INHERITED BY MY LATE FATHER.I AM FROM ZIMBABWE.BUT I AM LIVING IN THE NETHERLANDS (EUROPE) AT THE MOMENT FOR MORE INFORMATION REACH ME ON MY NUMBER 0031647858017 OR THROUGH THE MAIL. [EMAIL PROTECTED] BEST REGARDS ROBERT HARARE
Re: [linux-usb-devel] RFC: Synchronous unlinking and resubmission of URBs
Hi Dave, On Monday 08 December 2003 05:59, David Brownell wrote: > Duncan Sands wrote: > > This just came up in devio.c: the "synchronous" call to usb_unlink_urb > > was returning immediately with -EBUSY (probably because the core > > just nuked the urbs) even though the completion handlers hadn't > > finished. > > That was with uhci-hcd, right? To support Greg's wish to support > a "fire-and-forget" urb management policy, I think we really need > to have a uhci_endpoint_disable() that's waiting for those urbs. yes it was uhci. You're pointing out that the uhci implementation of urb nuking is not complete, right? I'd forgotten about that, and indeed it would explain how this panic was able to occur. > I bet nobody checks the return code because they expect the core to > > do whatever it takes to unlink the urb - even if it takes a long time. > > Considering that the core+hcds never actually tried to implement > the behavior those drivers were assuming, I've just assumed that > idiom was just another longstanding bug. Sure, but it is my impression (based on nothing at all, like all the best opinions) that the situation is like this: Number of places that wrongly rely on usb_unlink_urb (sync) behaving the way Alan suggested it should: lots. Number of places that would break if Alan's semantics were implemented: little. Number of ways that current semantics are more useful than the proposed semantics: little. In short, are the current semantics actually useful? More useful than those proposed by Alan? > Back on 2.4 the fact that unlinking doesn't work that way was maybe > less trouble, since the core wasn't doing any unlinking on disconnect > paths. (At least OHCI just succeeded there, rather than report EBUSY; > showing that wishful thinking can seem to work.) On 2.6 the core > does some unlinks, since so many drivers do it wrong; but if they're > running on UHCI, that driver bug currenly seems to hurt more. Yes. All the best, Duncan. --- This SF.net email is sponsored by: IBM Linux Tutorials. Become an expert in LINUX or just sharpen your skills. Sign up for IBM's Free Linux Tutorials. Learn everything from the bash shell to sys admin. Click now! http://ads.osdn.com/?ad_id=1278&alloc_id=3371&op=click ___ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] RFC: Synchronous unlinking and resubmission of URBs
Hi Alan, > In my opinion these semantics are insufficient. Certainly they are > not appropriate for the way usb_unlink_urb() is actually used in many > drivers. A very hasty survey of source files in drivers/usb/class > showns that most synchronous unlinkers require these semantics > instead: Regardless of whether the URB was in progress or not, when > the routine returns the URB must no longer be linked and must be > available for immediate reuse. Also the completion function must have > already returned so that it can safely be unloaded from memory (as in > rmmod). Resubmission within the completion function doesn't make much > sense in the context of a synchronous unlink, so it wouldn't hurt -- > and indeed it might help -- if the core fails such resubmissions. The > return code from the unlink doesn't really matter since callers > usually don't check it, so there's no harm in continuing to return > -EBUSY if the URB wasn't in progress. better to be explicit I think: provide a routine for halting the endpoint (I guess this exists already). Then people who resubmit in the completion handler can do: halt the endpoint (all submissions to the endpoint will fail). unlink the urb (synchronously) restart the endpoint If I understand right, you are proposing to bundle the "halt the endpoint" part into usb_unlink_urb (sync)? Ciao, Duncan. --- This SF.net email is sponsored by: IBM Linux Tutorials. Become an expert in LINUX or just sharpen your skills. Sign up for IBM's Free Linux Tutorials. Learn everything from the bash shell to sys admin. Click now! http://ads.osdn.com/?ad_id=1278&alloc_id=3371&op=click ___ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] RFC: Synchronous unlinking and resubmission of URBs
Hi Dave,
> Drivers now could easily get those cleanup semantics with something
> much smaller than your patch (though hcd_unlink_urb should still
> get rid of that splice logic!):
>
>static inline void urb_begone(struct urb *urb)
>{
>while (usb_unlink_urb (urb) == -EBUSY) {
>set_current_state (TASK_UNINTERRUPTIBLE);
>schedule_timeout (HZ/100);
>}
>}
why not have usb_unlink_urb (sync) do this?
Ciao,
Duncan.
---
This SF.net email is sponsored by: IBM Linux Tutorials.
Become an expert in LINUX or just sharpen your skills. Sign up for IBM's
Free Linux Tutorials. Learn everything from the bash shell to sys admin.
Click now! http://ads.osdn.com/?ad_id=1278&alloc_id=3371&op=click
___
[EMAIL PROTECTED]
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] RFC: Synchronous unlinking and resubmission of URBs
> better to be explicit I think: provide a routine for halting the endpoint > (I guess this exists already). Then people who resubmit in the completion > handler can do: > > halt the endpoint (all submissions to the endpoint will fail). > unlink the urb (synchronously) > restart the endpoint > > If I understand right, you are proposing to bundle the "halt the endpoint" > part into usb_unlink_urb (sync)? No, it seems to me he wants a "halt the urb" function. But that's not really an issue. All you need to do is to spin on a running completion handler. After that either the completion handler has run, which means the assumption drivers make is safe to make, or you can unlink the newly submitted urb. Not quite so trivial to implement without races, but there are _no_ changes to existing semantics. Regards Oliver --- This SF.net email is sponsored by: IBM Linux Tutorials. Become an expert in LINUX or just sharpen your skills. Sign up for IBM's Free Linux Tutorials. Learn everything from the bash shell to sys admin. Click now! http://ads.osdn.com/?ad_id=1278&alloc_id=3371&op=click ___ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
[linux-usb-devel] Re: datafab.c
[EMAIL PROTECTED] wrote: On the one hand, I have never seen SCSI error recovery do something useful. On the other hand, in this case, it is mostly our fault. If we return errors with the meaning "don't retry, that is meaningless" that would stop the SCSI layer from doing its nonsense. I tried your suggestion - insmod without CF card inserted and found that it took 13 minutes in my case. Then polished the error returns a bit and got it down to 2 seconds instead. Yes, I have 26 minutes due to having two luns from my datafab device. What I really don't like about "sd.c" is that it considers the device "ready for access" when even not a single GOOD was returned from the datafab driver. Finally this behavior results in an I/O error when reading the partition table. Should we report this to the scsi maintainers (whose email / ml I btw. don't know)? Now you want to see the improved code, but just a moment ago my ethernet hub broke down - never had that happen before - so my development machine is out of reach for the moment. The changes are easy to describe. Oh the poor hub, R.I.P. In the routine *determine_lun() there are three possible results: *GOOD / *FAILED / *ERROR. The two cases where a lun is discovered were and remain *GOOD. The cases where we cannot send a command at all (the write fails) were and remain *ERROR. The remaining cases (we do not try because of beenhere, or we try but do not find a lun) return *FAILED. When FAILED is returned, the sense code for Unit Attention, No Media is set. Clear the beenhere when we return *FAILED after trying in vain, so that we can try later. (In fact I made beenhere the condition info->lun == -2, and changed all tests elsewhere from "if (info->lun == -1)" to "if (info->lun < 0)".) I have a more fundamental question: Why do we need lun detection? The datafab reader is already presented to the OS as a two lun device (sda/sdb). In this case the user can decide which lun to use. Or is your datafab device different with this regard? The other possibility would be to report only a single lun to the OS and let the lun detection select the lun with a CF inserted. So my question is: should I modify datafab to present the two luns indepently to the operating system and send you the patch? greetings, eduard. --- This SF.net email is sponsored by: IBM Linux Tutorials. Become an expert in LINUX or just sharpen your skills. Sign up for IBM's Free Linux Tutorials. Learn everything from the bash shell to sys admin. Click now! http://ads.osdn.com/?ad_id=1278&alloc_id=3371&op=click ___ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
[linux-usb-devel] unusual_devs.h: patch for Pentax Optio 330/430 RS
Dear list, I would like to quickly drop in this patch against the vanilla linux 2.4.23 source tree which enabled the use of a Pentax Optio 330/430 RS digital camera as a mass storage device for me. I've been using this patch for quite some time now with a Pentax Optio 430 RS and it has never given me any trouble. Note: This patch does (according to other people) not work for the older non-RS-versions of the Pentax Optio series (Optio 330/430). It only works for the RS series. Please let me know if the patch is ok or if I need to change anything. Cheers, Christian -- JOIN - IP Version 6 in the WiN Christian Strauf A DFN project Westfälische Wilhelms-Universität Münster http://www.join.uni-muenster.de Zentrum für Informationsverarbeitung Team: [EMAIL PROTECTED] Röntgenstrasse 9-13 Priv: [EMAIL PROTECTED]D-48149 Münster / Germany GPG-/PGP-Key-ID: 1DFAAA9A Fon: +49 251 83 31639, Fax: +49 251 83 31653 --- linux-2.4.23/drivers/usb/storage/unusual_devs.h 2003-11-28 19:26:20.0 +0100 +++ linux-2.4.23-new/drivers/usb/storage/unusual_devs.h 2003-12-08 13:47:36.0 +0100 @@ -609,6 +609,14 @@ US_SC_8070, US_PR_CBI, NULL, US_FL_FIX_INQUIRY ), +/* From Christian Strauf <[EMAIL PROTECTED]> + * Pentax Optio 330/430RS digital still cameras + */ +UNUSUAL_DEV( 0x0a17, 0x04, 0x, 0x, + "Pentax", + "Optio 330/430 RS", + US_SC_8070, US_PR_CB, NULL, US_FL_FIX_INQUIRY), + #ifdef CONFIG_USB_STORAGE_ISD200 UNUSUAL_DEV( 0x0bf6, 0xa001, 0x0100, 0x0110, "ATI",
[linux-usb-devel] Re: datafab.c
My own sources have somewhere at the top of datafab.c the comment /* * Commands: 8 bytes * Three commands are known: * * Identify: 00 01 00 00 00 a0 ec 01 * (with b0 instead of a0 for LUN 1). * * Read: 00 nn xx xx xx ex 20 01 * (with f0 instead of e0 for LUN 1; * nn: sector count, xx: sector, 28 bits, little endian) * * Write:00 nn xx xx xx ex 30 02 * (idem; returns 2-byte status reply) * * Note that EC, 20, 30 are the ATA commands * IDENTIFY DRIVE, READ SECTORS, WRITE SECTORS. */ The device I played with recently is an Apacer CF+SM, where this datafab.c is used for the CF part, which is lun 0 of the device, and I use lun 0 of the datafab part. (There are various concepts of lun here. In the below I do not mean scsi or usb lun, but info->lun, the datafab lun.) >From you I understand that you have a single-use device and both lun 0 and lun 1 work - is that true? That is, does your device work both with info->lun = 0 and with info->lun = 1? > I have a more fundamental question: Why do we need lun detection? You wrote info->lun = srb->device->lun; and maybe that would work. These are two very different animals in principle, but maybe it is true that if the datafab is used for two devices the usb 0,1 are mapped this way, randomly, to the datafab 0,1. While if the datafab is used for one device maybe it does not matter which lun is used. That last sentence expresses my uncertainty: it is conceivable that datafab.c is called with srb->device->lun == 1 while only datafab lun 0 works. That would be a case where we need detection. Let me try to ask the original author why detection was needed for him and cc Jimmie Mayfield. Andries --- This SF.net email is sponsored by: IBM Linux Tutorials. Become an expert in LINUX or just sharpen your skills. Sign up for IBM's Free Linux Tutorials. Learn everything from the bash shell to sys admin. Click now! http://ads.osdn.com/?ad_id=1278&alloc_id=3371&op=click ___ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] Problems with Gamesurround Muse Pocket USB & 2.6.0-test11
please also post the decoded USB audio descriptor, using lsusb Tom --- This SF.net email is sponsored by: IBM Linux Tutorials. Become an expert in LINUX or just sharpen your skills. Sign up for IBM's Free Linux Tutorials. Learn everything from the bash shell to sys admin. Click now! http://ads.osdn.com/?ad_id=1278&alloc_id=3371&op=click ___ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] Problems with Gamesurround Muse Pocket USB & 2.6.0-test11
Hi, and thanks for the reply :-) > please also post the decoded USB audio descriptor, using lsusb > > Tom > here it is svetljo [EMAIL PROTECTED] SPECS]# lsusb -s 001:003 -vv Bus 001 Device 003: ID 06f8:c000 cannot get string descriptor 1, error = Broken pipe(32) Device Descriptor: bLength18 bDescriptorType 1 bcdUSB 1.10 bDeviceClass0 (Defined at Interface level) bDeviceSubClass 0 bDeviceProtocol 0 bMaxPacketSize064 idVendor 0x06f8 idProduct 0xc000 bcdDevice1.00 iManufacturer 0 iProduct1 iSerial 0 bNumConfigurations 1 Configuration Descriptor: bLength 9 bDescriptorType 2 wTotalLength 337 bNumInterfaces 4 bConfigurationValue 1 iConfiguration 0 bmAttributes 0xa0 Remote Wakeup MaxPower 500mA Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber0 bAlternateSetting 0 bNumEndpoints 0 bInterfaceClass 1 Audio bInterfaceSubClass 1 Control Device bInterfaceProtocol 0 iInterface 0 AudioControl Interface Descriptor: bLength10 bDescriptorType36 bDescriptorSubtype 1 (HEADER) bcdADC 1.00 wTotalLength 147 bInCollection 2 baInterfaceNr( 0) 1 baInterfaceNr( 1) 2 AudioControl Interface Descriptor: bLength12 bDescriptorType36 bDescriptorSubtype 2 (INPUT_TERMINAL) bTerminalID 1 wTerminalType 0x0101 USB Streaming bAssocTerminal 0 bNrChannels 6 wChannelConfig 0x003f Left Front (L) Right Front (R) Center Front (C) Low Freqency Enhancement (LFE) Left Surround (LS) Right Surround (RS) iChannelNames 0 iTerminal 0 AudioControl Interface Descriptor: bLength12 bDescriptorType36 bDescriptorSubtype 2 (INPUT_TERMINAL) bTerminalID 2 wTerminalType 0x0201 Microphone bAssocTerminal 0 bNrChannels 2 wChannelConfig 0x0003 Left Front (L) Right Front (R) iChannelNames 0 iTerminal 0 AudioControl Interface Descriptor: bLength12 bDescriptorType36 bDescriptorSubtype 2 (INPUT_TERMINAL) bTerminalID 3 wTerminalType 0x0603 Line Connector bAssocTerminal 0 bNrChannels 2 wChannelConfig 0x0003 Left Front (L) Right Front (R) iChannelNames 0 iTerminal 0 AudioControl Interface Descriptor: bLength 9 bDescriptorType36 bDescriptorSubtype 3 (OUTPUT_TERMINAL) bTerminalID 6 wTerminalType 0x0301 Speaker bAssocTerminal 0 bSourceID 9 iTerminal 0 AudioControl Interface Descriptor: bLength 9 bDescriptorType36 bDescriptorSubtype 3 (OUTPUT_TERMINAL) bTerminalID 7 wTerminalType 0x0101 USB Streaming bAssocTerminal 0 bSourceID 8 iTerminal 0 AudioControl Interface Descriptor: bLength 8 bDescriptorType36 bDescriptorSubtype 5 (SELECTOR_UNIT) bUnitID 8 bNrInPins 2 baSource( 0) 10 baSource( 1) 11 iSelector 0 AudioControl Interface Descriptor: bLength14 bDescriptorType36 bDescriptorSubtype 6 (FEATURE_UNIT) bUnitID 9 bSourceID 15 bControlSize1 bmaControls( 0) 0x03 Mute Volume bmaControls( 0) 0x00 bmaControls( 0) 0x00 bmaControls( 0) 0x00 bmaControls( 0) 0x00 bmaControls( 0) 0x00 bmaControls( 0) 0x00 iFeature0 AudioControl Interface Descriptor: bLength10 bDescriptorType36 bDescriptorSubtype 6 (FEATURE_UNIT) bUnitID10 bSourceID 2 bControl
Re: [linux-usb-devel] Problems with Gamesurround Muse Pocket USB & 2.6.0-test11
Thanks. > bNrChannels 6 Hm, the OSS driver doesn't really support more than 2 channels, as the OSS API is more or less stereo only. ALSA should be better suited for this, but I don't know too much about their USB driver... Tom --- This SF.net email is sponsored by: IBM Linux Tutorials. Become an expert in LINUX or just sharpen your skills. Sign up for IBM's Free Linux Tutorials. Learn everything from the bash shell to sys admin. Click now! http://ads.osdn.com/?ad_id=1278&alloc_id=3371&op=click ___ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] Problems with Gamesurround Muse Pocket USB & 2.6.0-test11
> Thanks. > > > bNrChannels 6 > > Hm, the OSS driver doesn't really support more than 2 channels, as the > OSS API is more or less stereo only. ok, but it has two interfaces - 2ch & 6ch, or am i wrong and it's supposed to work on Mac(without driver) as a stereo device(written on the box) currently : 1. with oss driver i'm getting stereo sound on the front chanels, but i can not controll it at all, headphones are almost working - i can control the level from a mixer, but not from program (e.g. mplayer, xmms) - [EMAIL PROTECTED] root]# aumix -d /dev/mixer1 -q vol 18, 18 // this one controls the headphones line 83, 83 // no effect mic 74, 74 [EMAIL PROTECTED] root]# aumix -d /dev/mixer2 -q line 0, 0, P // no effect mic 0, 0, R 2. with alsa if i unload the oss driver, and load snd-usb-audio only a mixer device is registered, no dsp devices nothing is working > ALSA should be better suited for this, but I don't know too much about > their USB driver... well i'm still waiting my messages to hit alsa-devel, let's see what will happen, but shouldn't it work with the oss driver at least in stereo mode thanks for your help svetljo -- +++ GMX - die erste Adresse für Mail, Message, More +++ Neu: Preissenkung für MMS und FreeMMS! http://www.gmx.net --- This SF.net email is sponsored by: IBM Linux Tutorials. Become an expert in LINUX or just sharpen your skills. Sign up for IBM's Free Linux Tutorials. Learn everything from the bash shell to sys admin. Click now! http://ads.osdn.com/?ad_id=1278&alloc_id=3371&op=click ___ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
[linux-usb-devel] Re: datafab.c
Phew, this is a really complex topic. Multiple LUNs at multiple levels :( [EMAIL PROTECTED] wrote: My own sources have somewhere at the top of datafab.c the comment /* * Commands: 8 bytes * Three commands are known: * * Identify: 00 01 00 00 00 a0 ec 01 * (with b0 instead of a0 for LUN 1). * * Read: 00 nn xx xx xx ex 20 01 * (with f0 instead of e0 for LUN 1; * nn: sector count, xx: sector, 28 bits, little endian) * * Write:00 nn xx xx xx ex 30 02 * (idem; returns 2-byte status reply) * * Note that EC, 20, 30 are the ATA commands * IDENTIFY DRIVE, READ SECTORS, WRITE SECTORS. */ The device I played with recently is an Apacer CF+SM, where this datafab.c is used for the CF part, which is lun 0 of the device, and I use lun 0 of the datafab part. (There are various concepts of lun here. In the below I do not mean scsi or usb lun, but info->lun, the datafab lun.) From you I understand that you have a single-use device and both lun 0 and lun 1 work - is that true? > That is, does your device work both with info->lun = 0 > and with info->lun = 1? Well, no: If "b0" is sent during Identify to the device I never get a proper 512 byte (aka. medium present) result, only for "a0". Maybe it is possible with some soldering to make my CF reader a dual slot CF reader, I don't know. But when lun detection determines the lun the same CF can be accessed by means of using "sda" or "sdb" which is somehow shaky. I have a more fundamental question: Why do we need lun detection? You wrote info->lun = srb->device->lun; Keep in mind that this does only work when the two subdevices are never accessed parallel! My idea was to remove the info->lun variable and add a lun parameter to every datafab.c function. and maybe that would work. These are two very different animals in principle, but maybe it is true that if the datafab is used for two devices the usb 0,1 are mapped this way, randomly, to the datafab 0,1. While if the datafab is used for one device maybe it does not matter which lun is used. That last sentence expresses my uncertainty: it is conceivable that datafab.c is called with srb->device->lun == 1 while only datafab lun 0 works. That would be a case where we need detection. IMHO it does not matter if only a single lun works. The user has to find the correct one, which should be in all cases the first one (sda). The second one will always be reported as "medium not present". Or we simply report the datafab as a single lun device and use the lun detection. greetings, eduard. --- This SF.net email is sponsored by: IBM Linux Tutorials. Become an expert in LINUX or just sharpen your skills. Sign up for IBM's Free Linux Tutorials. Learn everything from the bash shell to sys admin. Click now! http://ads.osdn.com/?ad_id=1278&alloc_id=3371&op=click ___ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
[linux-usb-devel] Re: datafab.c
On Mon, 8 Dec 2003, Eduard Hasenleithner wrote: > I have a more fundamental question: Why do we need lun detection? The > datafab reader is already presented to the OS as a two lun device > (sda/sdb). In this case the user can decide which lun to use. Or is your > datafab device different with this regard? > > The other possibility would be to report only a single lun to the OS and > let the lun detection select the lun with a CF inserted. So my question > is: should I modify datafab to present the two luns indepently to the > operating system and send you the patch? I don't have a card reader and know almost nothing about how they work. But following this thread has inspired a question: What happens to the lun mapping when there are two slots in the reader and _both_ slots have a card inserted? And a related variant: what if one of the cards is CF and the other is SM, or what if both cards are the same type? Alan Stern --- This SF.net email is sponsored by: IBM Linux Tutorials. Become an expert in LINUX or just sharpen your skills. Sign up for IBM's Free Linux Tutorials. Learn everything from the bash shell to sys admin. Click now! http://ads.osdn.com/?ad_id=1278&alloc_id=3371&op=click ___ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] unusual_devs.h: patch for Pentax Optio 330/430 RS
On Mon, 8 Dec 2003, Christian Strauf wrote: > Dear list, > > I would like to quickly drop in this patch against the vanilla linux > 2.4.23 source tree which enabled the use of a Pentax Optio 330/430 RS > digital camera as a mass storage device for me. > > I've been using this patch for quite some time now with a Pentax Optio > 430 RS and it has never given me any trouble. > > Note: This patch does (according to other people) not work for the older > non-RS-versions of the Pentax Optio series (Optio 330/430). It only > works for the RS series. > > Please let me know if the patch is ok or if I need to change anything. > > Cheers, > Christian Does your patch work if you leave out the FIX_INQUIRY flag or is that flag necessary? Also, do you get any messages in your kernel log about unneeded SubClass or Protocol values in the unusual_devs entry? Finally, does the product ID in your patch select _only_ the RS cameras or would it mistakenly be applied to the older version cameras as well? Alan Stern --- This SF.net email is sponsored by: IBM Linux Tutorials. Become an expert in LINUX or just sharpen your skills. Sign up for IBM's Free Linux Tutorials. Learn everything from the bash shell to sys admin. Click now! http://ads.osdn.com/?ad_id=1278&alloc_id=3371&op=click ___ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] [UHCI] deadlock when interrupts are broken
On Mon, 8 Dec 2003, Herbert Xu wrote: > Hi: > > The UHCI driver only cleans up removed QH/TD/URB entries in the interrupt > routine. This means that if the interrupts aren't working for whatever > reason (in my case it's a bug in suspend/resume), these entries will never > be cleaned up. This can easily cause deadlocks if you unlink an URB and > then wait for it to be given back. > > This patch fixes this by making the unlink schedule a tasklet to do the > cleanup rather than triggering an interrupt. > > Cheers, This doesn't seem necessary to me. If interrupts aren't working, you're going to have much worse problems than waiting for an URB to be given back! The correct way to fix your problem is to address the bug in suspend/resume. Alan Stern --- This SF.net email is sponsored by: IBM Linux Tutorials. Become an expert in LINUX or just sharpen your skills. Sign up for IBM's Free Linux Tutorials. Learn everything from the bash shell to sys admin. Click now! http://ads.osdn.com/?ad_id=1278&alloc_id=3371&op=click ___ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] Re: [OOPS, usbcore, releaseintf] 2.6.0-test10-mm1
Duncan Sands wrote: Hi Vince, I'm not sure, but it looks like a bug in the USB core. I was kind of expecting this :) My patch causes devio.c to hold a reference to the usb_device maybe long after the device has been disconnected. This is supposed to be OK, but from your ... no, that's not supposed to be OK. Returning from disconnect() means that a device driver is no longer referencing the interface the driver bound to, or ep0. - Dave Oops it looks like some part of the hcd was finalized too early (before devio.c dropped its reference to the usb_device). Maybe one of the USB guys can comment? --- This SF.net email is sponsored by: IBM Linux Tutorials. Become an expert in LINUX or just sharpen your skills. Sign up for IBM's Free Linux Tutorials. Learn everything from the bash shell to sys admin. Click now! http://ads.osdn.com/?ad_id=1278&alloc_id=3371&op=click ___ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] unusual_devs.h: patch for Pentax Optio 330/430 RS
Hi Alan, > Does your patch work if you leave out the FIX_INQUIRY flag or is that flag > necessary? Also, do you get any messages in your kernel log about I need to test what happens if I leave out the FIX_INQUIRY flag. If I set this to "0", what will the consequences be in the worst case? Will it corrupt data or will it simply fail to recognize media and stuff like that? I'm just asking what to expect -- as long as it doesn't wreck my camera, I'm fine with testing it. ;-) > unneeded SubClass or Protocol values in the unusual_devs entry? Finally, I don't get any messages concerning SubClass or Protocol Values (at least not if I plug the camera in, get the SCSI devices, mount it, make file operations on it, umount the device and remove the camera; also, I've made file operations with more than 300 MBs at a time and the camera behaved very well). > does the product ID in your patch select _only_ the RS cameras or would it > mistakenly be applied to the older version cameras as well? Unfortunately I don't have access to one of the older cameras so I can't test it. If I remember correctly, someone once told me that they have different product IDs. However, I'm unable to confirm it. Christian --- This SF.net email is sponsored by: IBM Linux Tutorials. Become an expert in LINUX or just sharpen your skills. Sign up for IBM's Free Linux Tutorials. Learn everything from the bash shell to sys admin. Click now! http://ads.osdn.com/?ad_id=1278&alloc_id=3371&op=click ___ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] Re: [OOPS, usbcore, releaseintf] 2.6.0-test10-mm1
On Monday 08 December 2003 17:03, David Brownell wrote: > Duncan Sands wrote: > > Hi Vince, I'm not sure, but it looks like a bug in the USB core. > > I was kind of expecting this :) My patch causes devio.c to hold > > a reference to the usb_device maybe long after the device has > > been disconnected. This is supposed to be OK, but from your > > ... no, that's not supposed to be OK. Returning from disconnect() > means that a device driver is no longer referencing the interface > the driver bound to, or ep0. Well, I thought Greg wanted it to be OK :) Anyway, I don't use the device after disconnect except to take the semaphore (dev->serialize), check for disconnection (dev->state), and of course to execute a usb_put_dev. Surely this usage should be OK? Ciao, Duncan. --- This SF.net email is sponsored by: IBM Linux Tutorials. Become an expert in LINUX or just sharpen your skills. Sign up for IBM's Free Linux Tutorials. Learn everything from the bash shell to sys admin. Click now! http://ads.osdn.com/?ad_id=1278&alloc_id=3371&op=click ___ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] [BUG REPORT] Timeout when sending control messages
On Sun, 7 Dec 2003, Mathias Gug wrote: > > > > >From: Alan Stern <[EMAIL PROTECTED]> > >Okay, that clears it up! > > > >The only difference is the removal of the parentheses around the ep > >parameter in the macro texts. Perusal of the kernel code shows that this > >will make a difference in one place. The following line is from > >proc_resetep() in drivers/usb/devio.c: > > > > usb_settoggle(ps->dev, ep & 0xf, !(ep & USB_DIR_IN), 0); > > > >That must be what is causing all your problems; without the parens you get > >macro expansions that look like "(1 << ep & 0xf)". Since the left-shift > >operator binds more tightly than the logical-and operator, the meaning is > >wrong. > > > >This problem was fixed 10 months ago, see > > > >http://linux.bkbits.net:8080/linux-2.4/[EMAIL > >PROTECTED]|src/|src/include|src/include/linux|related/include/linux/usb.h > > > >So if you would try using the most current 2.4.23 kernel, your problem > >should go away. > > > Unfortunatly not. I still see the timeout problem with 2.4.23. Is it cropping up at the same place? Are the extra parens present in the definition of the *_toggle macros/functions? If they are, then something else that changed between 2.4.21-4 and 2.4.23 must be responsible. Alan Stern --- This SF.net email is sponsored by: IBM Linux Tutorials. Become an expert in LINUX or just sharpen your skills. Sign up for IBM's Free Linux Tutorials. Learn everything from the bash shell to sys admin. Click now! http://ads.osdn.com/?ad_id=1278&alloc_id=3371&op=click ___ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] unusual_devs.h: patch for Pentax Optio 330/430 RS
On Mon, 8 Dec 2003, Christian Strauf wrote: > Hi Alan, > > > Does your patch work if you leave out the FIX_INQUIRY flag or is that flag > > necessary? Also, do you get any messages in your kernel log about > I need to test what happens if I leave out the FIX_INQUIRY flag. If I > set this to "0", what will the consequences be in the worst case? Will > it corrupt data or will it simply fail to recognize media and stuff like > that? I'm just asking what to expect -- as long as it doesn't wreck my > camera, I'm fine with testing it. ;-) The most likely failure mode is that the SCSI probe will generate a bunch of errors and will not recognize the existence of the camera. Nothing will be corrupted. > > unneeded SubClass or Protocol values in the unusual_devs entry? Finally, > I don't get any messages concerning SubClass or Protocol Values (at > least not if I plug the camera in, get the SCSI devices, mount it, make > file operations on it, umount the device and remove the camera; also, > I've made file operations with more than 300 MBs at a time and the > camera behaved very well). > > > does the product ID in your patch select _only_ the RS cameras or would it > > mistakenly be applied to the older version cameras as well? > Unfortunately I don't have access to one of the older cameras so I can't > test it. If I remember correctly, someone once told me that they have > different product IDs. However, I'm unable to confirm it. Okay, good. Alan Stern --- This SF.net email is sponsored by: IBM Linux Tutorials. Become an expert in LINUX or just sharpen your skills. Sign up for IBM's Free Linux Tutorials. Learn everything from the bash shell to sys admin. Click now! http://ads.osdn.com/?ad_id=1278&alloc_id=3371&op=click ___ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] Re: [OOPS, usbcore, releaseintf] 2.6.0-test10-mm1
On Mon, 8 Dec 2003, Duncan Sands wrote: > On Monday 08 December 2003 17:03, David Brownell wrote: > > Duncan Sands wrote: > > > Hi Vince, I'm not sure, but it looks like a bug in the USB core. > > > I was kind of expecting this :) My patch causes devio.c to hold > > > a reference to the usb_device maybe long after the device has > > > been disconnected. This is supposed to be OK, but from your > > > > ... no, that's not supposed to be OK. Returning from disconnect() > > means that a device driver is no longer referencing the interface > > the driver bound to, or ep0. > > Well, I thought Greg wanted it to be OK :) Anyway, I don't use > the device after disconnect except to take the semaphore > (dev->serialize), check for disconnection (dev->state), and > of course to execute a usb_put_dev. Surely this usage should > be OK? As long as your disconnect routine doesn't do usb_put_dev, so that it maintains its reference, I don't see a problem. But why do you want to check dev->state later on? Once your disconnect routine has returned, you should be totally through with the device. You should no longer care whether it's attached or not. And of course, remember that there are valid reasons for your disconnect routine to be called even when the device remains attached. (rmmod is a good example.) Alan Stern --- This SF.net email is sponsored by: IBM Linux Tutorials. Become an expert in LINUX or just sharpen your skills. Sign up for IBM's Free Linux Tutorials. Learn everything from the bash shell to sys admin. Click now! http://ads.osdn.com/?ad_id=1278&alloc_id=3371&op=click ___ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] RFC: Synchronous unlinking and resubmission of URBs
Duncan Sands wrote:
static inline void urb_begone(struct urb *urb)
{
while (usb_unlink_urb (urb) == -EBUSY) {
set_current_state (TASK_UNINTERRUPTIBLE);
schedule_timeout (HZ/100);
}
}
why not have usb_unlink_urb (sync) do this?
That'd work, and could finally be a good reason for
that routine not to be a simple inlined call! I'd
thought a bit about that approach.
But if usbcore were to get changed, why not change it
to have a usb_urb_begone() call that MUST (eventually)
be used for all synchronous unlinks? That's a better
long-term approach IMO.
Thing is, I really do think that every device driver
using synchronous unlink models should get checked
to make sure it's not got other disconnect() bugs
lurking; they've been a longstanding problem. And at
least some checking would be done as part of making
synchronous unlink calls use a different function.
- Dave
---
This SF.net email is sponsored by: IBM Linux Tutorials.
Become an expert in LINUX or just sharpen your skills. Sign up for IBM's
Free Linux Tutorials. Learn everything from the bash shell to sys admin.
Click now! http://ads.osdn.com/?ad_id=1278&alloc_id=3371&op=click
___
[EMAIL PROTECTED]
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] RFC: Synchronous unlinking and resubmission of URBs
better to be explicit I think: provide a routine for halting the endpoint (I guess this exists already). Then people who resubmit in the completion handler can do: halt the endpoint (all submissions to the endpoint will fail). unlink the urb (synchronously) restart the endpoint Not all endpoints are haltable in a useful sense. - Isochronous ones don't halt. - Control endpoint halts aren't persistent. Drivers that resubmit in completion without synchronizing with their own disconnect processing are buggy -- plain and simple. Left hand fighting with right hand. - Dave --- This SF.net email is sponsored by: IBM Linux Tutorials. Become an expert in LINUX or just sharpen your skills. Sign up for IBM's Free Linux Tutorials. Learn everything from the bash shell to sys admin. Click now! http://ads.osdn.com/?ad_id=1278&alloc_id=3371&op=click ___ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
[linux-usb-devel] issues with UHCI
Dear list: I'm not entirely certain, but I think I've a bug or two to report. At this point, my USB device is under development and should imitate a USB mouse. Problem 1) When it is plugged into a Windows box, it works as expected, but when I plug it into a Linux box it doesn't seem to finish grabbing all the descriptors. Here is an output of kmsg (please excuse the extra output... ...I've added a bit while trying to understand the system): <7>drivers/usb/host/uhci-hcd.c: 1800: wakeup_hc <7>hub 1-0:1.0: port 2, status 101, change 1, 12 Mb/s <7>hub 1-0:1.0: debounce: port 2: delay 100ms stable 4 status 0x101 <6>hub 1-0:1.0: new USB device on port 2, assigned address 14 <7>usb 1-2: new device strings: Mfr=0, Product=0, SerialNumber=0 <7>drivers/usb/core/usb.c: usb_hotplug <4>usb 1-2: config 0 descriptor??<7>numconfigs = 1Configuration: <4> bLength = 9 <4> bDescriptorType = 02 <4> wTotalLength = 0022 <4> bNumInterfaces = 01 <4> bConfigurationValue = 00 <4> iConfiguration = 00 <4> bmAttributes = a0 <4> bMaxPower = 304mA However, when I change the configuration value to 0x01, there is no problem with either system. I've noticed the code for the error message "config 0 descriptor??" is if (cp && configuration == 0) dev_warn(&dev->, "config 0 descriptor??\n"); which is of some confusion to me: the configuration value of '0' is perfectly valid, I think. This may cause problems with other devices, too. Problem 2) The amount of returned descriptor is a bit touchy. As far as I can tell, by the USB specification, when the host asks for 'x' number of bytes through the wLength field, the device is expected to return a payload of 'x' of bytes during the data phase. However, in practice this does not work as expected. First, when the host requests the first 8 bytes of the device descriptor, it hangs and reports a CRC error. Funny enough, it has actually received all 8 bytes expected, but still the UHCI silicon generates a CRC/Timeout error: <7>drivers/usb/host/uhci-hcd.c: 1800: wakeup_hc <7>hub 1-0:1.0: debounce: port 2: delay 100ms stable 4 status 0x101 <6>hub 1-0:1.0: new USB device on port 2, assigned address 17 <4>usb 1-2: control timeout on ep0in <4>usb 1-2: actual length = 0 <7>drivers/usb/host/uhci-hcd.c: uhci_result_control() failed with status 44 <4>[c5363240] link (053631e2) element (0532e100) <4> 0: [c532e100] link (0532e140) e0 Stalled CRC/Timeo Length=7 MaxLen=7 DT0 EndPt=0 Dev=11, PID=2d(SETUP) (buf=0ad312c0) <4> 1: [c532e140] link (0532e180) e3 SPD Active Length=0 MaxLen=7 DT1 EndPt=0 Dev=11, PID=69(IN) (buf=069a8364) <4> 2: [c532e180] link (0001) e3 IOC Active Length=0 MaxLen=7ff DT1 EndPt=0 Dev=11, PID=e1(OUT) (buf=) When hooked up to a Windows box, it does the same thing. So, despite the odd behavior, I send the entire device descriptor even when only 8 bytes are requested, and the initialization process continues. However, when the configuration descriptor is requested things get more out-of-sync. The windows system will not work if I send any more than 8 bytes (as requested). When working with Linux, the entire configuration descriptor must be sent when the initial 8 bytes are requested, or the initialization process just stops. Huh. Does anyone have an explanation for this odd behavoir? If I am making a silly mistake, or should eduacte myself more, please point me in the direction of a book or other reading. Thanks, Ethan Mattor --- This SF.net email is sponsored by: IBM Linux Tutorials. Become an expert in LINUX or just sharpen your skills. Sign up for IBM's Free Linux Tutorials. Learn everything from the bash shell to sys admin. Click now! http://ads.osdn.com/?ad_id=1278&alloc_id=3371&op=click ___ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] RFC: Synchronous unlinking and resubmissionof URBs
Am Montag, 8. Dezember 2003 17:49 schrieb David Brownell: > > better to be explicit I think: provide a routine for halting the endpoint > > (I guess this exists already). Then people who resubmit in the completion > > handler can do: > > > > halt the endpoint (all submissions to the endpoint will fail). > > unlink the urb (synchronously) > > restart the endpoint > > Not all endpoints are haltable in a useful sense. > - Isochronous ones don't halt. > - Control endpoint halts aren't persistent. Nor is it the correct thing to do. You really want to "halt" are rather block the urb. Just because one urb to ep 0 is given to usb_unlink_urb() doesn't mean that you can block all others. > Drivers that resubmit in completion without synchronizing > with their own disconnect processing are buggy -- plain and > simple. Left hand fighting with right hand. There needs to be synchronisation, but the core can provide it or at least most of it. You just need to make ordinary completion and usb_unlink_urb() atomic to each other. In this case a simple conditional on the urb's status is sufficient synchronisation. Regards Oliver --- This SF.net email is sponsored by: IBM Linux Tutorials. Become an expert in LINUX or just sharpen your skills. Sign up for IBM's Free Linux Tutorials. Learn everything from the bash shell to sys admin. Click now! http://ads.osdn.com/?ad_id=1278&alloc_id=3371&op=click ___ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] unusual_devs.h: patch for Pentax Optio 330/430 RS
As I am the original person who posted the patch, I would like to use this opertunity to fix a few things. I have looked at the windows driver .inf, and according to it, we should have the following: - UNUSUAL_DEV( 0x0a17, 0x0004, 0x, 0x, "Pentax", "USB DISK Device", US_SC_8070, US_PR_CB, NULL, US_FL_FIX_INQUIRY), As you can see, the windows driver just uses the standard USB driver that comes with Window2000/NT. Windows states CB instead of CBI but the camera functions perfectly ok using either US_PR_CB or US_PR_CBI. The US_SC_8070 comes from a simple lsusb -v for the camera. bInterfaceClass 8 Mass Storage bInterfaceSubClass 5 SFF-8070i I think it would be sensible to change the description to "Pentax USB DISK Device", rather that the camera name, because so many camera's use the same USB chips and the Windows driver does that. The windows driver does not seem to need "FIX_INQUIRY", so from that I conclude that we are doing something wrong in the kernel, because in linux one cannot access the device at all without FIX_INQUIRY set. Someone will have to do a windows2000 usbsnoopy to really find out why. For info, I have a Pentax Optio 430RS camera, and a friend of mine has the 430 (Without RS) and they both work fine with the above entry. I attach a copy of lsusb -v for those interested. Note that the lsusb command thinks I have a "Pentax Corp. Pentax Optio 330" but I actually have a 430RS. I think that wherever the "Pentax Corp. Pentax Optio 330" comes from, it should be replaced by "Pentax Corp. USB DISK Device". From the windows .inf file: - ;--- Windows2000 section --; [PENUSBC1.Dev.NT] Include=usbstor.inf Needs=USBSTOR_CB.NT CopyFiles=USBSTOR.CopyList AddReg=USBSTOR.AddReg [PENUSBC1.Dev.NT.Services] Include=usbstor.inf Needs=USBSTOR_CB.NT.Services ;---; [Strings] MSFT="Asahi Optical Co., Ltd." MfgName="Asahi Optical Co., Ltd." USB\VID_0A17&PID_0004.DeviceDesc="PENTAX USB DISK Device" PENUSBC1.SvcDesc="PENTAX USB DISK Device" Christian Strauf wrote: Dear list, I would like to quickly drop in this patch against the vanilla linux 2.4.23 source tree which enabled the use of a Pentax Optio 330/430 RS digital camera as a mass storage device for me. I've been using this patch for quite some time now with a Pentax Optio 430 RS and it has never given me any trouble. Note: This patch does (according to other people) not work for the older non-RS-versions of the Pentax Optio series (Optio 330/430). It only works for the RS series. Please let me know if the patch is ok or if I need to change anything. Cheers, Christian --- linux-2.4.23/drivers/usb/storage/unusual_devs.h 2003-11-28 19:26:20.0 +0100 +++ linux-2.4.23-new/drivers/usb/storage/unusual_devs.h 2003-12-08 13:47:36.0 +0100 @@ -609,6 +609,14 @@ US_SC_8070, US_PR_CBI, NULL, US_FL_FIX_INQUIRY ), +/* From Christian Strauf <[EMAIL PROTECTED]> + * Pentax Optio 330/430RS digital still cameras + */ +UNUSUAL_DEV( 0x0a17, 0x04, 0x, 0x, + "Pentax", + "Optio 330/430 RS", + US_SC_8070, US_PR_CB, NULL, US_FL_FIX_INQUIRY), + #ifdef CONFIG_USB_STORAGE_ISD200 UNUSUAL_DEV( 0x0bf6, 0xa001, 0x0100, 0x0110, "ATI", Bus 001 Device 014: ID 0a17:0004 Pentax Corp. Pentax Optio 330 <--- I think this should instead say "USB Disk Device". Device Descriptor: bLength18 bDescriptorType 1 bcdUSB 1.00 bDeviceClass0 Interface bDeviceSubClass 0 bDeviceProtocol 0 bMaxPacketSize0 8 idVendor 0x0a17 Pentax Corp. idProduct 0x0004 Pentax Optio 330 <--- I think this should instead say "USB Disk Device". bcdDevice 10.00 iManufacturer 1 ASAHI PENTAX iProduct2 PENTAX OPTIO 430RS iSerial 0 bNumConfigurations 1 Configuration Descriptor: bLength 9 bDescriptorType 2 wTotalLength 39 bNumInterfaces 1 bConfigurationValue 1 iConfiguration 0 bmAttributes 0x40 Self Powered MaxPower0mA Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber0 bAlternateSetting 0 bNumEndpoints 3 bInterfaceClass 8 Mass Storage bInterfaceSubClass 5 SFF-8070i bInterfaceProtocol 1 iInterface 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x81 EP 1 IN bmAttributes2 Transfer Type
Re: [linux-usb-devel] unusual_devs.h: patch for Pentax Optio 330/430 RS
Alan Stern wrote: On Mon, 8 Dec 2003, Christian Strauf wrote: Hi Alan, Does your patch work if you leave out the FIX_INQUIRY flag or is that flag necessary? Also, do you get any messages in your kernel log about I need to test what happens if I leave out the FIX_INQUIRY flag. If I set this to "0", what will the consequences be in the worst case? Will it corrupt data or will it simply fail to recognize media and stuff like that? I'm just asking what to expect -- as long as it doesn't wreck my camera, I'm fine with testing it. ;-) The most likely failure mode is that the SCSI probe will generate a bunch of errors and will not recognize the existence of the camera. Nothing will be corrupted. That is indead what happens when FIX_INQUIRY flag is not set. Cheers James --- This SF.net email is sponsored by: IBM Linux Tutorials. Become an expert in LINUX or just sharpen your skills. Sign up for IBM's Free Linux Tutorials. Learn everything from the bash shell to sys admin. Click now! http://ads.osdn.com/?ad_id=1278&alloc_id=3371&op=click ___ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] Re: [OOPS, usbcore, releaseintf] 2.6.0-test10-mm1
... hold a reference to the usb_device maybe long after the device has been disconnected. This is supposed to be OK, but from your ... no, that's not supposed to be OK. Returning from disconnect() means that a device driver is no longer referencing the interface the driver bound to, or ep0. Well, I thought Greg wanted it to be OK :) Anyway, I don't use the device after disconnect except to take the semaphore (dev->serialize), check for disconnection (dev->state), and of course to execute a usb_put_dev. Surely this usage should be OK? Why do you even need that much though? You're not allowed to be USING the device any more; that's the sense in which I was using "reference". Refcounting is orthogonal, except in the sense that to use without owning/borrowing a refcount will likely cause oopsing someday. As long as your disconnect routine doesn't do usb_put_dev, so that it There's an implicit usb_get_dev() associated with probe(), and an implicit usb_put_dev() associated with disconnect(). If you're going to add an explicit put(), you need to also add an explicit get(). Few drivers do; most rely on the implicit refcounts. But if you keep an extra reference to the device, you'd need some way to get rid of it. Yes, "usbfs" is wierd in lots of ways ... it's got references associated with several distinct roles, including implicitly associated with device creation, and so I'd suspect it doesn't keep them all straight. Plus, using the claim/release binding model (in its current state) opens it up to a different family of bugs ... since that doesn't hook up properly to the driver model yet, and making it do so is non-trivial. maintains its reference, I don't see a problem. But why do you want to check dev->state later on? Once your disconnect routine has returned, you should be totally through with the device. You should no longer care whether it's attached or not. And of course, remember that there are valid reasons for your disconnect routine to be called even when the device remains attached. (rmmod is a good example.) And adding special case logic for rmmod paths isn't a good thing; better just to implement disconnect() as I described. - Dave --- This SF.net email is sponsored by: IBM Linux Tutorials. Become an expert in LINUX or just sharpen your skills. Sign up for IBM's Free Linux Tutorials. Learn everything from the bash shell to sys admin. Click now! http://ads.osdn.com/?ad_id=1278&alloc_id=3371&op=click ___ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] issues with UHCI
Both your issues seem to be buggy-device issues, not a UHCI issues. Or are you also reporting that OHCI and EHCI work fine with it? However, when I change the configuration value to 0x01, there is no problem with either system. I've noticed the code for the error message "config 0 descriptor??" is if (cp && configuration == 0) dev_warn(&dev->, "config 0 descriptor??\n"); which is of some confusion to me: the configuration value of '0' is perfectly valid, I think. This may cause problems with other devices, too. Actually it's not valid. Configuration number zero is reserved in the USB spec to indicate the device is in the ADDRESS state (so only ep0 is ever available). It should never appear in any device descriptor. Hence the warning: the device is ill, and other problems may be upcoming... Problem 2) The amount of returned descriptor is a bit touchy. As far as I can tell, by the USB specification, when the host asks for 'x' number of bytes through the wLength field, the device is expected to return a payload of 'x' of bytes during the data phase. However, in practice this does not work as Actually, it should return "up to X bytes". So, despite the odd behavior, I send the entire device descriptor even when only 8 bytes are requested, and the initialization process continues. Sounds like your firmware isn't sending eight byte responses correctly. If ep0 maxpacket is bigger than eight bytes, you probably need to do an explicit flush for such short packets. What USB controller is your device using? Is it running Linux? - Dave --- This SF.net email is sponsored by: IBM Linux Tutorials. Become an expert in LINUX or just sharpen your skills. Sign up for IBM's Free Linux Tutorials. Learn everything from the bash shell to sys admin. Click now! http://ads.osdn.com/?ad_id=1278&alloc_id=3371&op=click ___ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] RFC: Synchronous unlinking and resubmission of URBs
On Sun, 7 Dec 2003, Duncan Sands wrote:
> This just came up in devio.c: the "synchronous" call to usb_unlink_urb
> was returning immediately with -EBUSY (probably because the core
> just nuked the urbs) even though the completion handlers hadn't
> finished. The code assumed (of course - doesn't everybody?) that the
> completion handlers had run, and moved on to do bad things, leading to
> a kernel panic.
Lots of drivers make that assumption.
> In my opinion synchronous usb_unlink_urb should not return until
> completion handlers have been run. If someone has already started
> unlinking the urb, so much the better: the call should wait until that has
> finished, then return.
That was the essence of my suggested patch.
> PS: The speedtouch driver gets it right (or so I hope), at the expense
> of an ugly block of code in the disconnect routine.
I'm very familiar with only a couple of drivers (usb-skeleton and
usb-storage) and they both get it right. class/audio.c looks okay too at
a hasty check. But none of the other class drivers I looked it were
correct.
On Sun, 7 Dec 2003, Oliver Neukum wrote:
> More than that. New submissions of that URB must fail, or the newly
> submitted URB unlinked, if the completion handler has won the race.
My patch does this (submissions made before the synchronous unlink returns
will fail).
On Sun, 7 Dec 2003, David Brownell wrote:
> But did any kernel ever guarantee those semantics? I don't think so.
> Certainly 2.6 never did, and neither OHCI nor EHCI on 2.4 does...
I agree, they didn't. However, that lack didn't prevent driver authors
from _assuming_ that they did.
> Even today (because of "no uhci_endpoint_disable") drivers that don't
> wait for all their completions in disconnect() will have unique problems.
> That family of problems was worse on 2.4 kernels.
>
> Drivers now could easily get those cleanup semantics with something
> much smaller than your patch (though hcd_unlink_urb should still
> get rid of that splice logic!):
>
>static inline void urb_begone(struct urb *urb)
>{
>while (usb_unlink_urb (urb) == -EBUSY) {
>set_current_state (TASK_UNINTERRUPTIBLE);
>schedule_timeout (HZ/100);
>}
>}
Whether this is smaller than my patch is a question of interpretation:
Yours is a much bigger change for the device driver! It also doesn't
address the problems of failing resubmission and races between submit and
unlink.
Yes, I know you think drivers should solve those problems themselves.
And clearly to a great extent they do. But they don't all solve all the
problems. I think the difficulty is that historically the guarantees made
by the synchronous unlink call were not spelled out clearly enough, so a
lot of people misunderstood them. I did at first.
> I still prefer async unlinks though ... maybe because it pushes
> device drivers to pay closer attention and avoid odd stuff ...
Agreed. Ideally, I would like to make usb_unlink_urb() always be
asynchronous and add usb_unlink_urb_synch() as a new function.
Unforunately, the majority of unlink calls in existing drivers are of
the synchronous kind.
> I think an urb_begone() should be relatively doable almost instantly
> as a driver-specific helper. Likely every driver that tries to use
> synchronous unlink should be audited for disconnect and resubmit, and
> one mark that it's been audited (if not entirely fixed) could be using
> urb_begone() rather than a synchronous usb_unlink_urb().
Again, I agree about the auditing. It would be a big job, though. Just
for reference, here's a complete list of all source files under
drivers/usb that use URB_ASYNC_UNLINK:
misc/auerswald.c, misc/usbtest.c
net/*.c
serial/keyspan.c
storage/tranport.c
Every other driver that does an unlink must necessarily be using
synchronous unlinking. That's a lot of them!
> Duncan Sands wrote:
> >
> > This just came up in devio.c: the "synchronous" call to usb_unlink_urb
> > was returning immediately with -EBUSY (probably because the core
> > just nuked the urbs) even though the completion handlers hadn't
> > finished.
>
> That was with uhci-hcd, right? To support Greg's wish to support
> a "fire-and-forget" urb management policy, I think we really need
> to have a uhci_endpoint_disable() that's waiting for those urbs.
On Mon, 8 Dec 2003, Duncan Sands wrote:
> yes it was uhci. You're pointing out that the uhci implementation of
> urb nuking is not complete, right? I'd forgotten about that, and indeed
> it would explain how this panic was able to occur.
When the code freeze ends, I will submit my version of such a routine.
But as far as I can see, there is _no_ statement in the kernel source
about what struct usb_operations->disable() is supposed to do. The
comments in front of one implementation in hcd.c (hcd_endpoint_disable)
merely state that all endpoint state is gone from the hardware. Since
UHCI doesn't sto
Re: [linux-usb-devel] Re: [OOPS, usbcore, releaseintf] 2.6.0-test10-mm1
On Monday 08 December 2003 17:31, Alan Stern wrote:
> On Mon, 8 Dec 2003, Duncan Sands wrote:
> > On Monday 08 December 2003 17:03, David Brownell wrote:
> > > Duncan Sands wrote:
> > > > Hi Vince, I'm not sure, but it looks like a bug in the USB core.
> > > > I was kind of expecting this :) My patch causes devio.c to hold
> > > > a reference to the usb_device maybe long after the device has
> > > > been disconnected. This is supposed to be OK, but from your
> > >
> > > ... no, that's not supposed to be OK. Returning from disconnect()
> > > means that a device driver is no longer referencing the interface
> > > the driver bound to, or ep0.
> >
> > Well, I thought Greg wanted it to be OK :) Anyway, I don't use
> > the device after disconnect except to take the semaphore
> > (dev->serialize), check for disconnection (dev->state), and
> > of course to execute a usb_put_dev. Surely this usage should
> > be OK?
>
> As long as your disconnect routine doesn't do usb_put_dev, so that it
> maintains its reference, I don't see a problem. But why do you want to
> check dev->state later on? Once your disconnect routine has returned, you
> should be totally through with the device. You should no longer care
> whether it's attached or not.
Hi Alan, this is for usbfs, not a normal driver. Recall that I want to replace
use of ps->devsem with ps->dev->serialize. Currently ps->dev is set to NULL in
the devio.c usbfs disconnect method (if some interface is claimed) or in
inode.c on device disconnect, making it hard to lock with ps->dev->serialize :)
Thus disconnect should no longer be signalled by setting ps->dev to NULL.
For the same reason ps->dev should not be freed on disconnect. It follows
that I should hold a reference to ps->dev until ps goes down. And this is
what I do. By the way, rather than introducing a new flag to indicate
disconnection, ps->dev->state will do.
> And of course, remember that there are valid reasons for your disconnect
> routine to be called even when the device remains attached. (rmmod is a
> good example.)
Sure.
All the best,
Duncan.
PS: Here is the patch that fixed the original usbfs Oops, but gained the new
one Vince reported:
diff -Nru a/drivers/usb/core/devio.c b/drivers/usb/core/devio.c
--- a/drivers/usb/core/devio.c Sun Dec 7 01:20:31 2003
+++ b/drivers/usb/core/devio.c Sun Dec 7 01:20:31 2003
@@ -87,17 +87,15 @@
static ssize_t usbdev_read(struct file *file, char __user *buf, size_t nbytes, loff_t
*ppos)
{
struct dev_state *ps = (struct dev_state *)file->private_data;
+ struct usb_device *dev = ps->dev;
ssize_t ret = 0;
unsigned len;
loff_t pos;
int i;
pos = *ppos;
- down_read(&ps->devsem);
- if (!ps->dev) {
- ret = -ENODEV;
- goto err;
- } else if (pos < 0) {
+ down(&dev->serialize);
+ if (pos < 0) {
ret = -EINVAL;
goto err;
}
@@ -106,7 +104,7 @@
len = sizeof(struct usb_device_descriptor) - pos;
if (len > nbytes)
len = nbytes;
- if (copy_to_user(buf, ((char *)&ps->dev->descriptor) + pos, len)) {
+ if (copy_to_user(buf, ((char *)&dev->descriptor) + pos, len)) {
ret = -EFAULT;
goto err;
}
@@ -118,9 +116,9 @@
}
pos = sizeof(struct usb_device_descriptor);
- for (i = 0; nbytes && i < ps->dev->descriptor.bNumConfigurations; i++) {
+ for (i = 0; nbytes && i < dev->descriptor.bNumConfigurations; i++) {
struct usb_config_descriptor *config =
- (struct usb_config_descriptor *)ps->dev->rawdescriptors[i];
+ (struct usb_config_descriptor *)dev->rawdescriptors[i];
unsigned int length = le16_to_cpu(config->wTotalLength);
if (*ppos < pos + length) {
@@ -129,7 +127,7 @@
len = nbytes;
if (copy_to_user(buf,
- ps->dev->rawdescriptors[i] + (*ppos - pos), len)) {
+ dev->rawdescriptors[i] + (*ppos - pos), len)) {
ret = -EFAULT;
goto err;
}
@@ -144,7 +142,7 @@
}
err:
- up_read(&ps->devsem);
+ up(&dev->serialize);
return ret;
}
@@ -324,22 +322,18 @@
static void driver_disconnect(struct usb_interface *intf)
{
struct dev_state *ps = usb_get_intfdata (intf);
+ unsigned int ifnum = intf->altsetting->desc.bInterfaceNumber;
if (!ps)
return;
- /* this waits till synchronous requests complete */
- down_write (&ps->devsem);
-
/* prevent new I/O requests */
- ps->dev = 0;
- ps->ifclaimed = 0;
usb_set_intfdata (intf, NULL);
+ if (ifnum < 8*sizeof(ps->ifclaimed))
[linux-usb-devel] Re: [UHCI] deadlock when interrupts are broken
On Mon, Dec 08, 2003, Herbert Xu <[EMAIL PROTECTED]> wrote: > The UHCI driver only cleans up removed QH/TD/URB entries in the interrupt > routine. This means that if the interrupts aren't working for whatever > reason (in my case it's a bug in suspend/resume), these entries will never > be cleaned up. This can easily cause deadlocks if you unlink an URB and > then wait for it to be given back. > > This patch fixes this by making the unlink schedule a tasklet to do the > cleanup rather than triggering an interrupt. I'll echo what Alan said and say the real fix here is fixing the suspend/resume case. Regardless, this patch makes things worse. We need to wait for the next frame to know the hardware is done using the QHs and TDs before we can clean them up. This patch changes this so we clean up those entries before the hardware is done, which is very bad. That is why we wait for the next interrupt from the hardware, it's the only way to ensure that the hardware is done using the memory before we can clean it up. JE --- This SF.net email is sponsored by: IBM Linux Tutorials. Become an expert in LINUX or just sharpen your skills. Sign up for IBM's Free Linux Tutorials. Learn everything from the bash shell to sys admin. Click now! http://ads.osdn.com/?ad_id=1278&alloc_id=3371&op=click ___ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] RFC: Synchronous unlinking and resubmissionof URBs
> On Sun, 7 Dec 2003, Oliver Neukum wrote: > > > More than that. New submissions of that URB must fail, or the newly > > submitted URB unlinked, if the completion handler has won the race. > > My patch does this (submissions made before the synchronous unlink returns > will fail). I've changed my mind on this. Outright failure is a change of semantics. It is not needed. Simply set a flag in this case and return success. After the completion handler has returned, check the flag and recall it with the error code for synchronous unlink in urb->status. [..] > > But that's not really an issue. All you need to do is to spin on a running > > completion handler. After that either the completion handler has run, > > which means the assumption drivers make is safe to make, or you > > can unlink the newly submitted urb. > > Not quite so trivial to implement without races, but there are _no_ > > changes to existing semantics. > > You're correct that this can be done by writing the driver appropriately. > My point is that a lot of drivers would need to be changed, and it's > easier to change the core and alter the semantics of the API. Yes. That's the point. The essential point here is that usb_unlink_urb() has to wait for the completion handler. The rest is sugar coating. As I have pointed out you can do it with zero change to the API. [..] > On Mon, 8 Dec 2003, David Brownell wrote: > > > But if usbcore were to get changed, why not change it > > to have a usb_urb_begone() call that MUST (eventually) > > be used for all synchronous unlinks? That's a better > > long-term approach IMO. > > I like that idea. In fact, why not make usb_unlink_urb() be purely async? Shouldn't the common case of synchronous unlink be made simple? > Another important area where better synchronization is needed in the core > is submission/unlinking. An URB should be either: > > idle (not used at all or just beginning the submission process > but not yet linked by the HCD), > in progress (linked by the HCD, no errors encountered yet, not > unlinked, not completed), > or finishing up (error, unlink, or in completion handler). > > These state changes should be protected by urb->lock. But they aren't, > and we currently can't distinguish between idle and finishing up. > > My proposal would make thise categories reliably detectable: > > idle: urb->usage_count == 0, > in progress:urb->usage_count > 0 and urb->status = -EINPROGRESS, > finishing up: urb->usage_count > 0 and > urb->status != -EINPROGRESS. > What exactly does this buy? usb_submit_urb() and usb_unlink_urb() don't change their behaviour based on this states #1 and #3, except for usb_unlink_urb() waiting for a transition out of #3 > All right. I was hoping to stir up a little discussion, and apparently I > succeeded. It would be nice to arrive at a consensus regarding a few key > points: > > Should the core change to prevent resubmission of URBs under > certain circumstances? > > Should URB state tracking be more reliable? > > Should we try to fix the existing synchronous unlinking problem > by auditing drivers or by altering the core to make it match more > closely the drivers' preconceptions? Should we change them both > a little? No to the third option. Either go through all drivers _or_ change the core. Not both. Having seperate operations for synchronous and asynchronous unlinking is independent from that and a good idea, but 2.7 stuff. Regards Oliver --- This SF.net email is sponsored by: IBM Linux Tutorials. Become an expert in LINUX or just sharpen your skills. Sign up for IBM's Free Linux Tutorials. Learn everything from the bash shell to sys admin. Click now! http://ads.osdn.com/?ad_id=1278&alloc_id=3371&op=click ___ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] issues with UHCI
On Mon, 8 Dec 2003, Ethan Mattor wrote: > Problem 2) > The amount of returned descriptor is a bit touchy. As far as I can tell, by > the USB specification, when the host asks for 'x' number of bytes through > the wLength field, the device is expected to return a payload of 'x' of > bytes during the data phase. However, in practice this does not work as > expected. First, when the host requests the first 8 bytes of the device > descriptor, it hangs and reports a CRC error. Funny enough, it has actually > received all 8 bytes expected, but still the UHCI silicon generates a > CRC/Timeout error: > > <7>drivers/usb/host/uhci-hcd.c: 1800: wakeup_hc > <7>hub 1-0:1.0: debounce: port 2: delay 100ms stable 4 status 0x101 > <6>hub 1-0:1.0: new USB device on port 2, assigned address 17 > <4>usb 1-2: control timeout on ep0in > <4>usb 1-2: actual length = 0 > <7>drivers/usb/host/uhci-hcd.c: uhci_result_control() failed with status > 44 <4>[c5363240] link (053631e2) element (0532e100) > <4> 0: [c532e100] link (0532e140) e0 Stalled CRC/Timeo Length=7 MaxLen=7 DT0 > EndPt=0 Dev=11, PID=2d(SETUP) (buf=0ad312c0) > <4> 1: [c532e140] link (0532e180) e3 SPD Active Length=0 MaxLen=7 DT1 > EndPt=0 Dev=11, PID=69(IN) (buf=069a8364) > <4> 2: [c532e180] link (0001) e3 IOC Active Length=0 MaxLen=7ff DT1 > EndPt=0 Dev=11, PID=e1(OUT) (buf=) The CRC/Timeout error is for the SETUP packet. This means that the device didn't send an ACK in response to the SETUP as it was obliged to do. Or if it did send one, the ACK got mangled somehow. According to this log trace the host never did send the IN packet asking for the device to transmit its 8 bytes. So what makes you think the device sent them? And if the device did send them, why did it send them without being asked to do so? Alan Stern --- This SF.net email is sponsored by: IBM Linux Tutorials. Become an expert in LINUX or just sharpen your skills. Sign up for IBM's Free Linux Tutorials. Learn everything from the bash shell to sys admin. Click now! http://ads.osdn.com/?ad_id=1278&alloc_id=3371&op=click ___ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
[linux-usb-devel] Re: datafab.c
I don't have a card reader and know almost nothing about how they work. But following this thread has inspired a question: What happens to the lun mapping when there are two slots in the reader and _both_ slots have a card inserted? The mapping does not depend on the presence of media. And a related variant: what if one of the cards is CF and the other is SM, or what if both cards are the same type? There is no choice what to insert where, SM cards are much thinner than CF cards. Andries --- This SF.net email is sponsored by: IBM Linux Tutorials. Become an expert in LINUX or just sharpen your skills. Sign up for IBM's Free Linux Tutorials. Learn everything from the bash shell to sys admin. Click now! http://ads.osdn.com/?ad_id=1278&alloc_id=3371&op=click ___ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] Re: [OOPS, usbcore, releaseintf] 2.6.0-test10-mm1
On Mon, 8 Dec 2003, Duncan Sands wrote: > Hi Alan, this is for usbfs, not a normal driver. Recall that I want to replace > use of ps->devsem with ps->dev->serialize. Maybe you shouldn't do that. Other drivers maintain their own data structure separately from the struct usb_device and with its own lock. But usbfs may suffer from complications as a result of its unorthodox approach to device ownership. > Currently ps->dev is set to NULL in > the devio.c usbfs disconnect method (if some interface is claimed) or in > inode.c on device disconnect, making it hard to lock with ps->dev->serialize :) > Thus disconnect should no longer be signalled by setting ps->dev to NULL. If you would keep the ps->devsem lock, would there be any problem in setting ps->dev to NULL to indicate disconnection? Are they any reasons for not keeping ps->devsem? Since usbfs generally acts as a driver and drivers generally don't have to concern themselves with usbdev->serialize (the core handles it for them), shouldn't usbfs also be able to ignore ps->dev->serialize? Alan Stern --- This SF.net email is sponsored by: IBM Linux Tutorials. Become an expert in LINUX or just sharpen your skills. Sign up for IBM's Free Linux Tutorials. Learn everything from the bash shell to sys admin. Click now! http://ads.osdn.com/?ad_id=1278&alloc_id=3371&op=click ___ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
[linux-usb-devel] Re: datafab.c
On Mon, Dec 08, 2003 at 02:15:38PM +0100, [EMAIL PROTECTED] wrote: > > I have a more fundamental question: Why do we need lun detection? > > You wrote > > info->lun = srb->device->lun; > > and maybe that would work. These are two very different animals > in principle, but maybe it is true that if the datafab is used > for two devices the usb 0,1 are mapped this way, randomly, to > the datafab 0,1. While if the datafab is used for one device > maybe it does not matter which lun is used. > > That last sentence expresses my uncertainty: it is conceivable > that datafab.c is called with srb->device->lun == 1 while > only datafab lun 0 works. That would be a case where we need > detection. Forgive me, it's been a long time since I've looked at this USB stuff and I've just now been CC'd on this conversation. The "LUN" stuff is a hack at best and I am by no means convinced that it was the right thing to do. It was added back when the driver was in development in order to help an early user get his multi-slot reader to function. I no longer have his USB traffic dump files but it appeared that his windows driver was probing LUNs prior to doing anything useful with the device. In his case, the CF slot corresponded to second LUN probed. The first LUN was presumably his smartmedia slot which spoke some entirely different protocol and refused to acknowledge the identify device query. An unwanted side effect of this code, as you've noted, was that for single slot CF readers, the LUN code ends up detecting phantom devices. That is, the device would respond successfully to an identify device query regardless of which LUN it was sent to. My hardware doesn't behave this way but then it's a fairly old reader. I was never able to nail down a particular query issued by a windows driver that indicates whether or not additional LUNs should be probed. I, perhaps incorrectly, assumed that these probes were enabled at compile-time by companies only if the company's hardware required them. Obviously this would be difficult to do in the Linux driver where one driver must work for everybody with a reader based on this chipset so the probes were enabled all the time. It's not pretty code and I would have much preferred something more intelligent but I was out of ideas and looking at the windows driver traffic didn't lend any additional insight. Jimmie -- Jimmie Mayfield http://www.sackheads.org/mayfieldemail: [EMAIL PROTECTED] My mail provider does not welcome UCE -- http://www.sackheads.org/uce --- This SF.net email is sponsored by: IBM Linux Tutorials. Become an expert in LINUX or just sharpen your skills. Sign up for IBM's Free Linux Tutorials. Learn everything from the bash shell to sys admin. Click now! http://ads.osdn.com/?ad_id=1278&alloc_id=3371&op=click ___ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
[linux-usb-devel] Re: datafab.c
On Mon, Dec 08, 2003 at 01:38:52PM -0500, Jimmie Mayfield wrote: > An unwanted side effect of this code, as you've noted, was that for > single slot CF readers, the LUN code ends up detecting phantom devices. > That is, the device would respond successfully to an identify device query > regardless of which LUN it was sent to. My hardware doesn't behave this > way but then it's a fairly old reader. Actually, after thinking about this for a few moments (remember, it's been a couple years since I've looked at this code) and looking at the code, it seems that this isn't what's happening. The determine_lun() routine will return as soon as it finds a responsive LUN so if LUN 0 responds successfully, it will not go on to probe LUN 1. So if multiple phantom devices are showing up, it must be because the UHCI/OHCI code really believes that they're present. The explanation of the origin of the determine_lun() code still stands, though. It was an attempt to allow multiple slot readers to function properly. Sorry about the confusion. Jimmie --- This SF.net email is sponsored by: IBM Linux Tutorials. Become an expert in LINUX or just sharpen your skills. Sign up for IBM's Free Linux Tutorials. Learn everything from the bash shell to sys admin. Click now! http://ads.osdn.com/?ad_id=1278&alloc_id=3371&op=click ___ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] RFC: Synchronous unlinking and resubmissionof URBs
On Mon, 8 Dec 2003, Oliver Neukum wrote: > > My patch does this (submissions made before the synchronous unlink returns > > will fail). > > I've changed my mind on this. Outright failure is a change of semantics. > It is not needed. Simply set a flag in this case and return success. > After the completion handler has returned, check the flag and recall it > with the error code for synchronous unlink in urb->status. > > > Not quite so trivial to implement without races, but there are _no_ > > > changes to existing semantics. > Yes. That's the point. The essential point here is that usb_unlink_urb() > has to wait for the completion handler. The rest is sugar coating. > As I have pointed out you can do it with zero change to the API. I think you have underestimated the problems here. Suppose the completion handler resubmits and the resubmitted URB manages to complete before the original completion handler returns? Then giveback_urb would be invoked reentrantly. Which invocation should unlink_urb() then wait for? What if the resubmitted completion was the result of another synchronous unlink? Furthermore, in stating your essential point you have contradicted yourself. "usb_unlink_urb() has to wait for the completion handler". But the API currently does not make that guarantee. If you add it in, you change the API. > > I like that idea. In fact, why not make usb_unlink_urb() be purely async? > > Shouldn't the common case of synchronous unlink be made simple? To some extent I sympathize. But there is a precedent for not making the common case simple. Consider fork-exec. The most common use is for spawning new processes. But separating the two operations, thereby making spawn less simple, provided new and important capabilities. From the USB core's point of view, asynchronous unlink is the natural atomic operation. > > Another important area where better synchronization is needed in the core > > is submission/unlinking. An URB should be either: > > > > idle (not used at all or just beginning the submission process > > but not yet linked by the HCD), > > in progress (linked by the HCD, no errors encountered yet, not > > unlinked, not completed), > > or finishing up (error, unlink, or in completion handler). > > > > These state changes should be protected by urb->lock. But they aren't, > > and we currently can't distinguish between idle and finishing up. > > > > My proposal would make thise categories reliably detectable: > > > > idle: urb->usage_count == 0, > > in progress:urb->usage_count > 0 and urb->status = -EINPROGRESS, > > finishing up: urb->usage_count > 0 and > > urb->status != -EINPROGRESS. > > > > What exactly does this buy? > usb_submit_urb() and usb_unlink_urb() don't change their behaviour based > on this states #1 and #3, except for usb_unlink_urb() waiting for a transition > out of #3 Waiting for a transition out of state #3 is important for synchronous unlinking. Also, even though the difference between state #2 on the one hand and states #1 and #3 on the other can currently be checked by looking at urb->status, doing so isn't reliable. urb->status is set to -EINPROGRESS in usb_submit_urb() long before the HCD has actually linked it in (and hence before an unlink call can succeed). > Having seperate operations for synchronous and asynchronous unlinking > is independent from that and a good idea, but 2.7 stuff. As far as I'm concerned, this is all 2.7 stuff. Alan Stern --- This SF.net email is sponsored by: IBM Linux Tutorials. Become an expert in LINUX or just sharpen your skills. Sign up for IBM's Free Linux Tutorials. Learn everything from the bash shell to sys admin. Click now! http://ads.osdn.com/?ad_id=1278&alloc_id=3371&op=click ___ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
[linux-usb-devel] Re: PROBLEM: not getting any endpoint on USB interface 0 with kernel 2.6 pre 9
On Sat, 6 Dec 2003, Bruno GRIEDER wrote: > Hi Alan, > > Thanks for your reply. I have been unavailable most of last week, but > here is the information requested. > > First, I discovered that the issue of having no endpoints listed in 2.6 > test9 only happened when I plugged the device after boot. If the device > is plugged before I boot, the endpoints are listed. At least I can now > progress on the driver rewriting. > > I have looked for error messages in the case where I plug after boot. > Here is a snippet of /var/log/syslog > Dec 6 12:19:31 localhost /etc/hotplug/usb.agent: Bad USB agent > invocation > Dec 6 12:19:31 localhost kernel: usb 1-2: new device strings: Mfr=0, > Product=0, SerialNumber=0 > Dec 6 12:19:31 localhost kernel: drivers/usb/core/usb.c: usb_hotplug > Dec 6 12:19:31 localhost kernel: usb 1-2: registering 1-2:1.0 (config > #1, interface 0) > Dec 6 12:19:31 localhost kernel: drivers/usb/core/usb.c: usb_hotplug > Dec 6 12:19:34 localhost /etc/hotplug/usb.agent: ... no modules for USB > product 864/4100/100 > Dec 6 12:19:35 localhost kernel: usbfs: process 2291 (lsusb) did not > claim interface 0 before use > Dec 6 12:19:35 localhost kernel: usbfs: USBDEVFS_CONTROL failed cmd > lsusb dev 2 rqt 128 rq 6 len 256 ret -32 > > Do these two lines indicate anything that could be related to the pb? I suppose it's possible. Both indicate some error associated with hotplug support. You might try turning off the hotplug agent to see if that makes any difference. Alan Stern --- This SF.net email is sponsored by: IBM Linux Tutorials. Become an expert in LINUX or just sharpen your skills. Sign up for IBM's Free Linux Tutorials. Learn everything from the bash shell to sys admin. Click now! http://ads.osdn.com/?ad_id=1278&alloc_id=3371&op=click ___ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] RFC: Synchronous unlinking and resubmission of URBs
On Monday 08 December 2003 11:41, Duncan Sands wrote: > Sure, but it is my impression (based on nothing at all, like all the best > opinions) that the situation is like this: > > Number of places that wrongly rely on usb_unlink_urb (sync) behaving > the way Alan suggested it should: lots. > > Number of places that would break if Alan's semantics were implemented: > little. > > Number of ways that current semantics are more useful than the > proposed semantics: little. I can't say it better... Most unlinks are done at disconnect, and clearly they have to be synchronous and there is no sense of failure or retry. But I won't wait until 2.7 best regards Wolfgang Mües --- This SF.net email is sponsored by: IBM Linux Tutorials. Become an expert in LINUX or just sharpen your skills. Sign up for IBM's Free Linux Tutorials. Learn everything from the bash shell to sys admin. Click now! http://ads.osdn.com/?ad_id78&alloc_id371&op=click ___ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] Re: [OOPS, usbcore, releaseintf] 2.6.0-test10-mm1
Hi Alan, > But usbfs may suffer from complications as a result of its unorthodox > approach to device ownership. Yes, you have put your finger on it. > > Currently ps->dev is set to NULL in > > the devio.c usbfs disconnect method (if some interface is claimed) or in > > inode.c on device disconnect, making it hard to lock with > > ps->dev->serialize :) Thus disconnect should no longer be signalled by > > setting ps->dev to NULL. > > If you would keep the ps->devsem lock, would there be any problem in > setting ps->dev to NULL to indicate disconnection? You can't keep the ps->devsem lock and use ps->dev->serialize, because it leads to deadlock. Actually, simply replacing ps->devsem with ps->dev->serialize cannot lead to any new deadlocks, it makes deadlocks that could occasionally happen always happen (such deadlocks exist right now in usbfs). Some of the current deadlocks can be eliminated without giving up ps->devsem, but not all. So the question is: must ps->dev->serialize be used? > Are they any reasons for not keeping ps->devsem? Since usbfs generally > acts as a driver and drivers generally don't have to concern themselves > with usbdev->serialize (the core handles it for them), shouldn't usbfs > also be able to ignore ps->dev->serialize? No, because it needs to do operations on interfaces it hasn't claimed (such as looking them up and claiming them). This is why it needs to protect itself, at least momentarily, against configurations shifting under it. This can be done by using the BKL more. However it can be done more simply using ps->dev->serialize (in fact it is simpler than what is there now). By the way, if it is somehow fatal to do usb_put_dev after disconnect, what is the point of referencing counting at all? You might as well free up the usb_device structure immediately after disconnect, since there is sure to be a reference before disconnect, and (apparently) there had better not be a reference after disconnect... All the best, Duncan. --- This SF.net email is sponsored by: IBM Linux Tutorials. Become an expert in LINUX or just sharpen your skills. Sign up for IBM's Free Linux Tutorials. Learn everything from the bash shell to sys admin. Click now! http://ads.osdn.com/?ad_id=1278&alloc_id=3371&op=click ___ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] Backport of printer 2.6=>2.4
> Pete, I tested your backport + this change above on 2.4.23 and it works
> well on my HP psc 2110.
> I did have to apply part of the patch by hand, so I rediffed it against
> 2.4.23. Patch is below.
OK, either way is good. However, I don't understand why it
didn't apply for you. I tried this way and that, it all matches.
The patch you posted applies cleanly, too. Hmmm I think the
attached should be perfect. I do not much like the syntax of
"while ( 1==1 )", but if 2.6 has it...
Greg, can you take it?
-- Pete
diff -urN -X dontdiff linux-2.4.23/drivers/usb/printer.c
linux-2.4.23-nip/drivers/usb/printer.c
--- linux-2.4.23/drivers/usb/printer.c 2002-11-28 15:53:14.0 -0800
+++ linux-2.4.23-nip/drivers/usb/printer.c 2003-12-08 11:43:21.0 -0800
@@ -22,8 +22,11 @@
* v0.7 - fixed bulk-IN read and poll (David Paschal)
* v0.8 - add devfs support
* v0.9 - fix unplug-while-open paths
- * v0.10 - add proto_bias option (Pete Zaitcev)
- * v0.11 - add hpoj.sourceforge.net ioctls (David Paschal)
+ * v0.10- remove sleep_on, fix error on oom ([EMAIL PROTECTED])
+ * v0.11 - add proto_bias option (Pete Zaitcev)
+ * v0.12 - add hpoj.sourceforge.net ioctls (David Paschal)
+ * v0.13 - alloc space for statusbuf ( not on stack);
+ * use usb_buffer_alloc() for read buf & write buf;
*/
/*
@@ -58,12 +61,12 @@
/*
* Version Information
*/
-#define DRIVER_VERSION "v0.11"
+#define DRIVER_VERSION "v0.13"
#define DRIVER_AUTHOR "Michael Gee, Pavel Machek, Vojtech Pavlik, Randy Dunlap, Pete
Zaitcev, David Paschal"
#define DRIVER_DESC "USB Printer Device Class driver"
#define USBLP_BUF_SIZE 8192
-#define DEVICE_ID_SIZE 1024
+#define USBLP_DEVICE_ID_SIZE 1024
/* ioctls: */
#define LPGETSTATUS0x060b /* same as in drivers/char/lp.c */
@@ -115,12 +118,20 @@
#define USBLP_LAST_PROTOCOL3
#define USBLP_MAX_PROTOCOLS(USBLP_LAST_PROTOCOL+1)
+/*
+ * some arbitrary status buffer size;
+ * need a status buffer that is allocated via kmalloc(), not on stack
+ */
+#define STATUS_BUF_SIZE8
+
struct usblp {
struct usb_device *dev; /* USB device */
devfs_handle_t devfs; /* devfs device */
struct semaphoresem;/* locks this struct,
especially "dev" */
- char*buf; /* writeurb.transfer_buffer */
- struct urb readurb, writeurb; /* The urbs */
+ char*writebuf; /* write transfer_buffer */
+ char*readbuf; /* read transfer_buffer */
+ char*statusbuf; /* status transfer_buffer */
+ struct urb *readurb, *writeurb;/* The urbs */
wait_queue_head_t wait; /* Z ... */
int readcount; /* Counter for reads */
int ifnum; /* Interface number */
@@ -133,8 +144,11 @@
} protocol[USBLP_MAX_PROTOCOLS];
int current_protocol;
int minor; /* minor number of device */
+ int wcomplete; /* writing is completed */
+ int rcomplete; /* reading is completed */
unsigned intquirks; /* quirks flags */
unsigned char used; /* True if open */
+ unsigned char present;/* True if not disconnected */
unsigned char bidir; /* interface is bidirectional
*/
unsigned char *device_id_string; /* IEEE 1284 DEVICE ID string
(ptr) */
/* first 2 bytes are
(big-endian) length */
@@ -146,8 +160,11 @@
dbg("usblp=0x%p", usblp);
dbg("dev=0x%p", usblp->dev);
- dbg("devfs=0x%p", usblp->devfs);
- dbg("buf=0x%p", usblp->buf);
+ dbg("present=%d", usblp->present);
+ dbg("readbuf=0x%p", usblp->readbuf);
+ dbg("writebuf=0x%p", usblp->writebuf);
+ dbg("readurb=0x%p", usblp->readurb);
+ dbg("writeurb=0x%p", usblp->writeurb);
dbg("readcount=%d", usblp->readcount);
dbg("ifnum=%d", usblp->ifnum);
for (p = USBLP_FIRST_PROTOCOL; p <= USBLP_LAST_PROTOCOL; p++) {
@@ -157,6 +174,8 @@
}
dbg("current_protocol=%d", usblp->current_protocol);
dbg("minor=%d", usblp->minor);
+ dbg("wcomplete=%d", usblp->wcomplete);
+ dbg("rcomplete=%d", usblp->rcomplete);
dbg("quirks=%d", usblp->quirks);
dbg("used=%d", usblp->used);
dbg("bidir=%d", usblp->bidir);
@@ -239,17 +258,31 @@
* URB callback.
*/
-static void usblp_bulk(struct urb *u
[linux-usb-devel] usb-storage in 2.4
Customers keep complaining that usb-storage is unusable in 2.4,
so I looked at it and WOA! Very simple things, like running
dd if=/dev/sda of=/dev/null bs=8k and then unplugging the
flash cause oopses and lockups; once those are fixed, storage
can get offline forever. Ugh.
2.6 looks much saner, but it's somewhat different and I do not
dare a backport. Here's a patch to add some sanity into the
carnival of semaphores. Oh, and never return failure from
the bus reset - it only serves to fall back to adapter reset,
which we do not implement.
I would like someone to test it, to make sure I am not
breaking things (e.g. if any hangs happen).
Greg & Matt, if you approve, I'll take arguing this with Marcelo,
if you need a help here. This is an issue for us, because
of proliferation of USB storage as factory option. And we
cannot just go to 2.6.
-- Pete
diff -urN -X dontdiff linux-2.4.23/drivers/usb/storage/scsiglue.c
linux-2.4.23-nip/drivers/usb/storage/scsiglue.c
--- linux-2.4.23/drivers/usb/storage/scsiglue.c 2003-06-13 07:51:37.0 -0700
+++ linux-2.4.23-nip/drivers/usb/storage/scsiglue.c 2003-12-06 01:10:46.0
-0800
@@ -213,9 +213,20 @@
static int device_reset( Scsi_Cmnd *srb )
{
struct us_data *us = (struct us_data *)srb->host->hostdata[0];
+ int rc;
US_DEBUGP("device_reset() called\n" );
- return us->transport_reset(us);
+ spin_unlock_irq(&io_request_lock);
+ down(&(us->dev_semaphore));
+ if (!us->pusb_dev) {
+ up(&(us->dev_semaphore));
+ spin_lock_irq(&io_request_lock);
+ return SUCCESS;
+ }
+ rc = us->transport_reset(us);
+ up(&(us->dev_semaphore));
+ spin_lock_irq(&io_request_lock);
+ return rc;
}
/* This resets the device port, and simulates the device
@@ -230,27 +241,32 @@
/* we use the usb_reset_device() function to handle this for us */
US_DEBUGP("bus_reset() called\n");
+ spin_unlock_irq(&io_request_lock);
+
+ down(&(us->dev_semaphore));
+
/* if the device has been removed, this worked */
if (!us->pusb_dev) {
US_DEBUGP("-- device removed already\n");
+ up(&(us->dev_semaphore));
+ spin_lock_irq(&io_request_lock);
return SUCCESS;
}
- spin_unlock_irq(&io_request_lock);
-
/* release the IRQ, if we have one */
- down(&(us->irq_urb_sem));
if (us->irq_urb) {
US_DEBUGP("-- releasing irq URB\n");
result = usb_unlink_urb(us->irq_urb);
US_DEBUGP("-- usb_unlink_urb() returned %d\n", result);
}
- up(&(us->irq_urb_sem));
/* attempt to reset the port */
if (usb_reset_device(us->pusb_dev) < 0) {
- spin_lock_irq(&io_request_lock);
- return FAILED;
+ /*
+* Do not return errors, or else the error handler might
+* invoke host_reset, which is not implemented.
+*/
+ goto bail_out;
}
/* FIXME: This needs to lock out driver probing while it's working
@@ -281,28 +297,36 @@
up(&intf->driver->serialize);
}
+bail_out:
/* re-allocate the IRQ URB and submit it to restore connectivity
* for CBI devices
*/
if (us->protocol == US_PR_CBI) {
- down(&(us->irq_urb_sem));
us->irq_urb->dev = us->pusb_dev;
result = usb_submit_urb(us->irq_urb);
US_DEBUGP("usb_submit_urb() returns %d\n", result);
- up(&(us->irq_urb_sem));
}
-
+
+ up(&(us->dev_semaphore));
+
spin_lock_irq(&io_request_lock);
US_DEBUGP("bus_reset() complete\n");
return SUCCESS;
}
-/* FIXME: This doesn't do anything right now */
static int host_reset( Scsi_Cmnd *srb )
{
- printk(KERN_CRIT "usb-storage: host_reset() requested but not implemented\n" );
- return FAILED;
+ struct us_data *us = (struct us_data *)srb->host->hostdata[0];
+
+ spin_unlock_irq(&io_request_lock);
+ down(&(us->dev_semaphore));
+printk(KERN_CRIT "usb-storage: host_reset() requested but hardly
implemented\n" );
+ up(&(us->dev_semaphore));
+ spin_lock_irq(&io_request_lock);
+ US_DEBUGP("host_reset() complete\n");
+
+ return SUCCESS;
}
/***
@@ -394,6 +418,13 @@
can_queue: 1,
this_id:-1,
+ /*
+* This is supposed to be an HBA limit. In our case, it is here
+* because many _devices_ break if transfer is too long, but
+* we know no reliable way to detect and blacklist them.
+*/
+ max_sectors:240,
+
sg_tablesize: SG_ALL,
cmd_per_lun:1,
present:0,
diff
[linux-usb-devel] pl2303 driver with "dumb" devices
Hi, I wrote an email directly to "greg at kroah.com" because he's the author of the pl2303 driver but I think I could have some help here too about an issue with the pl2303 driver. if I connect a usb-serial adapter to my laptop, and I connect to this adapter an external serial modem, everything's perfect. But, if I connect another device, for example a telescope, (which happens to have only 3 lines connected, TX, RX and GND) I can't send or receive anything. The same hardware works well in windows and I can access the telescope using minicom on a desktop computer with a real serial port. Do you perhaps think that, the pl2303 doesn't work well with devices that implement a 3-wire only communication? Is there somothing to do? I used linux-2.6.0-test11-bk5 and linux-2.4.23 in my tests. Thank you as --- This SF.net email is sponsored by: IBM Linux Tutorials. Become an expert in LINUX or just sharpen your skills. Sign up for IBM's Free Linux Tutorials. Learn everything from the bash shell to sys admin. Click now! http://ads.osdn.com/?ad_id=1278&alloc_id=3371&op=click ___ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
[linux-usb-devel] Re: [UHCI] deadlock when interrupts are broken
On Mon, Dec 08, 2003 at 01:04:39PM -0500, Johannes Erdfelt wrote:
>
> I'll echo what Alan said and say the real fix here is fixing the
> suspend/resume case.
I agree completely. However, it would be nice to have a safety net
when things go wrong. In particular, being able to remove the uhci-hcd
module when the interrupts stop working for whatever reason can't be
a bad thing.
> Regardless, this patch makes things worse. We need to wait for the next
> frame to know the hardware is done using the QHs and TDs before we can
> clean them up.
>
> This patch changes this so we clean up those entries before the hardware
> is done, which is very bad.
Sorry about that. Can you please comment on the following patch which
no longer frees the QHs and TDs outside of the interrupt routine.
Cheers,
--
Debian GNU/Linux 3.0 is out! ( http://www.debian.org/ )
Email: Herbert Xu ~{PmV>HI~} <[EMAIL PROTECTED]>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Index: kernel-2.5/drivers/usb/host/uhci-hcd.c
===
RCS file:
/home/gondolin/herbert/src/CVS/debian/kernel-source-2.5/drivers/usb/host/uhci-hcd.c,v
retrieving revision 1.1.1.14
diff -u -r1.1.1.14 uhci-hcd.c
--- kernel-2.5/drivers/usb/host/uhci-hcd.c 17 Oct 2003 21:43:29 -
1.1.1.14
+++ kernel-2.5/drivers/usb/host/uhci-hcd.c 8 Dec 2003 20:56:03 -
@@ -90,6 +90,7 @@
static int uhci_get_current_frame_number(struct uhci_hcd *uhci);
static int uhci_urb_dequeue(struct usb_hcd *hcd, struct urb *urb);
static void uhci_unlink_generic(struct uhci_hcd *uhci, struct urb *urb);
+static void uhci_irq_tail(struct usb_hcd *hcd, struct pt_regs *regs);
static void hc_state_transitions(struct uhci_hcd *uhci);
@@ -1667,9 +1668,9 @@
spin_lock(&uhci->urb_remove_list_lock);
- /* If we're the first, set the next interrupt bit */
+ /* If we're the first, schedule tasklet */
if (list_empty(&uhci->urb_remove_list))
- uhci_set_next_interrupt(uhci);
+ tasklet_schedule(&uhci->irq_tasklet);
list_add(&urbp->urb_list, &uhci->urb_remove_list);
spin_unlock(&uhci->urb_remove_list_lock);
@@ -1934,8 +1935,6 @@
uhci_free_pending_tds(uhci);
- uhci_remove_pending_qhs(uhci);
-
uhci_clear_next_interrupt(uhci);
/* Walk the list of pending URB's to see which ones completed */
@@ -1953,9 +1952,25 @@
}
spin_unlock(&uhci->urb_list_lock);
+ uhci_irq_tail(hcd, regs);
+}
+
+static void uhci_irq_tail(struct usb_hcd *hcd, struct pt_regs *regs)
+{
+ struct uhci_hcd *uhci = hcd_to_uhci(hcd);
+
+ uhci_remove_pending_qhs(uhci);
+
uhci_finish_completion(hcd, regs);
}
+static void uhci_irq_tasklet(unsigned long data)
+{
+ struct usb_hcd *hcd = (void *)data;
+
+ uhci_irq_tail(hcd, NULL);
+}
+
static void reset_hc(struct uhci_hcd *uhci)
{
unsigned int io_addr = uhci->io_addr;
@@ -2455,7 +2470,8 @@
*/
uhci_free_pending_qhs(uhci);
uhci_free_pending_tds(uhci);
- uhci_remove_pending_qhs(uhci);
+ tasklet_schedule(&uhci->irq_tasklet);
+ tasklet_kill(&uhci->irq_tasklet);
reset_hc(uhci);
@@ -2505,6 +2521,8 @@
memset(uhci, 0, sizeof(*uhci));
uhci->hcd.product_desc = "UHCI Host Controller";
+ tasklet_init(&uhci->irq_tasklet, uhci_irq_tasklet,
+(unsigned long)&uhci->hcd);
return &uhci->hcd;
}
Index: kernel-2.5/drivers/usb/host/uhci-hcd.h
===
RCS file:
/home/gondolin/herbert/src/CVS/debian/kernel-source-2.5/drivers/usb/host/uhci-hcd.h,v
retrieving revision 1.1.1.4
retrieving revision 1.2
diff -u -r1.1.1.4 -r1.2
--- kernel-2.5/drivers/usb/host/uhci-hcd.h 27 Sep 2003 00:01:59 - 1.1.1.4
+++ kernel-2.5/drivers/usb/host/uhci-hcd.h 8 Dec 2003 08:57:52 - 1.2
@@ -3,6 +3,7 @@
#include
#include
+#include
#define usb_packetid(pipe) (usb_pipein(pipe) ? USB_PID_IN : USB_PID_OUT)
#define PIPE_DEVEP_MASK0x0007ff00
@@ -366,6 +367,8 @@
int rh_numports;
struct timer_list stall_timer;
+
+ struct tasklet_struct irq_tasklet;
};
struct urb_priv {
Re: [linux-usb-devel] RFC: Synchronous unlinking and resubmission of URBs
Number of places that would break if Alan's semantics were implemented: little. I'll disagree. Which is why I've pointed out two distinct fixes, both safer: - Retry on -EBUSY (needed for any non-disconnect paths) - Add uhci_endpoint_disable (only helps disconnect paths) The problem is that "Alan's semantics" was a menu, and some parts of that menu were invasive. (Especially the parts trying to add new resubmit models.) There was commenting that drivers don't handle -EBUSY right; there was a patch; and there were a number of other ideas. Number of ways that current semantics are more useful than the proposed semantics: little. Again, which part? The current semantics are extremely precise, simple, and accurate. That's how we can know that a layer doing something like "retry on -EBUSY" will actually address the only concrete issue I've seen identified -- and even the disconnect paths, which touch on other issues. - Dave --- This SF.net email is sponsored by: IBM Linux Tutorials. Become an expert in LINUX or just sharpen your skills. Sign up for IBM's Free Linux Tutorials. Learn everything from the bash shell to sys admin. Click now! http://ads.osdn.com/?ad_id=1278&alloc_id=3371&op=click ___ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] RFC: Synchronous unlinking and resubmission of URBs
Most unlinks are done at disconnect, and clearly they have to be synchronous and there is no sense of failure or retry. But I won't wait until 2.7 Adding uhci_endpoint_disconnect() will resolve the disconnect() path issue. In fact, once that's added, drivers could even start to get rid of all urb unlink calls in their disconnect() logic, enabling that "fire and forget" model. - Dave --- This SF.net email is sponsored by: IBM Linux Tutorials. Become an expert in LINUX or just sharpen your skills. Sign up for IBM's Free Linux Tutorials. Learn everything from the bash shell to sys admin. Click now! http://ads.osdn.com/?ad_id=1278&alloc_id=3371&op=click ___ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] RFC: Synchronous unlinking and resubmission of URBs
Alan Stern responding to David Brownell: But did any kernel ever guarantee those semantics? I don't think so. Certainly 2.6 never did, and neither OHCI nor EHCI on 2.4 does... I agree, they didn't. However, that lack didn't prevent driver authors from _assuming_ that they did. Sure, but I can't think of that as anything other than a set of long-standing driver bugs. static inline void urb_begone(struct urb *urb) ... Whether this is smaller than my patch is a question of interpretation: Yours is a much bigger change for the device driver! It also doesn't But those are less fragile than the combination of usbcore and the hcds. Changing the semantics of unlinking could have lots of un-intended consequences at lower levels; IMO they should get even simpler, not more complicated. On the other hand, if we just agreed not to call those semantics by the name "unlinking", and to provide them through some simple function like usb_urb_begone(), then I see simple ways out. Sure many drivers would need "obviously correct" one-line changes, to call that routine. But that'd be unlikely to break any of the hard-to-fix lower level code. address the problems of failing resubmission and races between submit and unlink. That second problem is orthogonal; even drivers that use asynchronous unlinking have to solve it. I don't think that usbcore should be involved in such policies. It certainly can't know what the driver intended, so it can't guess how to patch up a given event sequence for the relevant version of "correct". I think the difficulty is that historically the guarantees made by the synchronous unlink call were not spelled out clearly enough, so a lot of people misunderstood them. I did at first. Sure, this is part of why the 2.6 kernel has much more kerneldoc! I think of it as an API maturity issue; the issue wasn't unique to synchronous unlinking. The URB lifecycle model had lots of odd quirks with respect to urbs-in-flight, most of which weren't implemented consistently. They're now gone, and the remaining behaviors tend to be easily testable. But as far as I can see, there is _no_ statement in the kernel source about what struct usb_operations->disable() is supposed to do. The comments in front of one implementation in hcd.c (hcd_endpoint_disable) merely state that all endpoint state is gone from the hardware. Since UHCI doesn't store any endpoint state in the hardware to begin with, that doesn't say anything. _Nothing_ is mentioned anywhere about waiting until all the software/driver state is gone as well. If usbfs were waiting for urb completions, that UHCI-specific behavior wouldn't matter -- there'd be no oopsing. If that UHCI-specific behavior were changed, there'd also be none. ... the thing is, I think that we probably added an "expectation" that HCDs wait for the URBs to complete, by some changes several months after the disable() method was first defined. That's where the UHCI-specific problem came up. It's hard to see "fire and forget" working well if urbs can complete after disconnect() is invoked -- the "forget" part wouldn't work. why not have usb_unlink_urb (sync) do this? If the urb was resubmitted by the completion handler, urb_begone() as written would loop endlessly. At the risk of sounding like a broken record, device drivers that don't have synchronization on resubmit paths are buggy, and they need to add it. Of course, auditing for resubmit bugs could easily be part of converting to call some urb_begone(). - Dave --- This SF.net email is sponsored by: IBM Linux Tutorials. Become an expert in LINUX or just sharpen your skills. Sign up for IBM's Free Linux Tutorials. Learn everything from the bash shell to sys admin. Click now! http://ads.osdn.com/?ad_id=1278&alloc_id=3371&op=click ___ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] RFC: Synchronous unlinking and resubmission of URBs
But if usbcore were to get changed, why not change it to have a usb_urb_begone() call that MUST (eventually) be used for all synchronous unlinks? That's a better long-term approach IMO. I like that idea. In fact, why not make usb_unlink_urb() be purely async? Eventually, yes -- getting rid of that async unlink flag would be a good deed, but it'd need to be done carefully. I'd not rush that into the 2.6 series. Drivers that want to wait for the URB to finish completely could then call usb_urb_begone() after unlinking it. (The implementation could perhaps be spruced up a little. Something like my usage_count field should be used; there's already a FIXME about improving the URB state in hcd.c. And it wouldn't hurt to use a blocking primitive rather than polling every 1/100th second. There could even be an interruptible version, although I don't know that there's any need for such a thing.) I'll be shocked if that name survives too ... ;) Maybe "usb_stop_urb()" would be better. Re implementation, I'll continue to lobby for simplicity. Polling doesn't bother me much, since it should only be called once. Drivers can implement interruptible waits themselves, on top of async unlink. And the usage count thing seems to be designed to facilitate something that I think usbcore should avoid. Another important area where better synchronization is needed in the core is submission/unlinking. An URB should be either: idle (not used at all or just beginning the submission process but not yet linked by the HCD), in progress (linked by the HCD, no errors encountered yet, not unlinked, not completed), or finishing up (error, unlink, or in completion handler). Why should the model visible to drivers be any more complex than the simple two-state model I thought we had today? - URB is inactive. Device driver handles any nuances like never-used, just-completed, etc. Device driver may submit it, if it's properly initialized. - URB is submitted. HCD controls it, and manages nuances like whether the hardware sees it, whether it's being canceled, whether completion status is known, etc. HCD will give it back (state becomes inactive). Device driver may unlink, but otherwise may not access that URB. That is, your "finishing up" is just some HCD-internal variant of "linked" -- except for "in completion handler", which is the first not-linked state on today's return path. These state changes should be protected by urb->lock. But they aren't, and we currently can't distinguish between idle and finishing up. I don't follow. Today, state transitions are made by only two function calls -- usb_submit_urb, usb_hcd_giveback_urb -- since there are only two transitions. And urb->lock is used to make the usbcore/hcd boundary handle unlinking -- no more. - Dave --- This SF.net email is sponsored by: IBM Linux Tutorials. Become an expert in LINUX or just sharpen your skills. Sign up for IBM's Free Linux Tutorials. Learn everything from the bash shell to sys admin. Click now! http://ads.osdn.com/?ad_id=1278&alloc_id=3371&op=click ___ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] Re: [OOPS, usbcore, releaseintf] 2.6.0-test10-mm1
On Mon, 8 Dec 2003, Duncan Sands wrote: > > If you would keep the ps->devsem lock, would there be any problem in > > setting ps->dev to NULL to indicate disconnection? > > You can't keep the ps->devsem lock and use ps->dev->serialize, because it > leads to deadlock. How so? Remember that I am almost totally unfamiliar with the details of the usbfs code. Are you saying there are places where the driver holds one lock and needs to acquire the other and vice versa? > Actually, simply replacing ps->devsem with ps->dev->serialize > cannot lead to any new deadlocks, it makes deadlocks that could occasionally > happen always happen (such deadlocks exist right now in usbfs). Some of the > current deadlocks can be eliminated without giving up ps->devsem, but not all. > So the question is: must ps->dev->serialize be used? It must be held when you call usb_reset_configuration(). It must _not_ be held when you call usb_set_configuration(). For usb_reset_device() right now you must not hold it, although that may change in the future. For usb_unbind_interface() you must not hold it. There's a note that usb_driver_claim_interface() grabs the BKL for some reason having to do with usbfs -- no doubt when usbfs is fixed that won't be needed and the caller will be required to hold dev->serialize instead. If you call usb_ifnum_to_if() you ought to hold the serialize lock; otherwise the configuration might change out from under you. But it's not necessary. Likewise for usb_epnum_to_ep_desc if you're looking up an endpoint that isn't part of an interface you have bound. > > Are they any reasons for not keeping ps->devsem? Since usbfs generally > > acts as a driver and drivers generally don't have to concern themselves > > with usbdev->serialize (the core handles it for them), shouldn't usbfs > > also be able to ignore ps->dev->serialize? > > No, because it needs to do operations on interfaces it hasn't claimed (such > as looking them up and claiming them). This is why it needs to protect > itself, at least momentarily, against configurations shifting under it. This > can be done by using the BKL more. However it can be done more simply > using ps->dev->serialize (in fact it is simpler than what is there now). That agrees with my assessment. It ought to be possible to remove these references to the BKL in favor of ps->dev->serialize. > By the way, if it is somehow fatal to do usb_put_dev after disconnect, > what is the point of referencing counting at all? You might as well > free up the usb_device structure immediately after disconnect, since > there is sure to be a reference before disconnect, and (apparently) > there had better not be a reference after disconnect... There's some sort of misunderstanding here. It's not fatal to do usb_put_dev() after disconnect, provided you called usb_get_dev() earlier. I'm not sure what the cause was of the oops you were getting, but it wasn't that. Alan Stern --- This SF.net email is sponsored by: IBM Linux Tutorials. Become an expert in LINUX or just sharpen your skills. Sign up for IBM's Free Linux Tutorials. Learn everything from the bash shell to sys admin. Click now! http://ads.osdn.com/?ad_id=1278&alloc_id=3371&op=click ___ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] Re: [UHCI] deadlock when interrupts are broken
On Tue, 9 Dec 2003, Herbert Xu wrote: > On Mon, Dec 08, 2003 at 01:04:39PM -0500, Johannes Erdfelt wrote: > > > > I'll echo what Alan said and say the real fix here is fixing the > > suspend/resume case. > > I agree completely. However, it would be nice to have a safety net > when things go wrong. In particular, being able to remove the uhci-hcd > module when the interrupts stop working for whatever reason can't be > a bad thing. That's supposed to work right now. However, there may be a problem with the uhci_stop() routine. While I haven't checked this in detail, it appears that the first calls to uhci_free_pending_qhs() and uhci_free_pending_tds() may be unnecessary, while there ought to be a call to uhci_finish_completion() just after the reset_hc(). > > > Regardless, this patch makes things worse. We need to wait for the next > > frame to know the hardware is done using the QHs and TDs before we can > > clean them up. > > > > This patch changes this so we clean up those entries before the hardware > > is done, which is very bad. > > Sorry about that. Can you please comment on the following patch which > no longer frees the QHs and TDs outside of the interrupt routine. I suspect your patch is not really needed. Try implementing what I said above and see if it helps. Better yet, go through the code in uhci_stop() more carefully than I did and figure out what it really should be doing. Alan Stern --- This SF.net email is sponsored by: IBM Linux Tutorials. Become an expert in LINUX or just sharpen your skills. Sign up for IBM's Free Linux Tutorials. Learn everything from the bash shell to sys admin. Click now! http://ads.osdn.com/?ad_id=1278&alloc_id=3371&op=click ___ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] RFC: Synchronous unlinking and resubmission of URBs
On Mon, 8 Dec 2003, David Brownell wrote: > > > Most unlinks are done at disconnect, and clearly they have to > > be synchronous and there is no sense of failure or retry. > > > > But I won't wait until 2.7 > > Adding uhci_endpoint_disconnect() will resolve the disconnect() > path issue. > > In fact, once that's added, drivers could even start to get > rid of all urb unlink calls in their disconnect() logic, > enabling that "fire and forget" model. Remember the non-hcd drivers. Do they implement disable_endpoint() in the right way? Alan Stern --- This SF.net email is sponsored by: IBM Linux Tutorials. Become an expert in LINUX or just sharpen your skills. Sign up for IBM's Free Linux Tutorials. Learn everything from the bash shell to sys admin. Click now! http://ads.osdn.com/?ad_id=1278&alloc_id=3371&op=click ___ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] Oops in usb_physical_reset_device
Jamie Lokier wrote: Alan Stern wrote: Sorry, my question wasn't clear. What I'm trying to understand is, after you had done echo 0 >.../bConfigurationValue why was any code calling usb_reset_device? And exactly which code was calling usb_reset_device? USBDEVFS_RESET. Seems to me that usb_physical_reset_device() should just be returning "early" when dev->actconfig is null It could re-read descriptors, but it shouldn't be trying to restore a non-existent configuration (or pick one). Likely the simplest fix is just to fail at the very top of that routine if there's no configuration. That routine needs some significant changes, that'd be a way to avoid them and prevent user-initiated oopses. Simple patch -- feel like making it? That one might even meet the 2.6.0 integration criteria. - Dave --- This SF.net email is sponsored by: IBM Linux Tutorials. Become an expert in LINUX or just sharpen your skills. Sign up for IBM's Free Linux Tutorials. Learn everything from the bash shell to sys admin. Click now! http://ads.osdn.com/?ad_id=1278&alloc_id=3371&op=click ___ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] Re: [OOPS, usbcore, releaseintf] 2.6.0-test10-mm1
> > You can't keep the ps->devsem lock and use ps->dev->serialize, because it > > leads to deadlock. > > How so? Remember that I am almost totally unfamiliar with the details of > the usbfs code. Are you saying there are places where the driver holds > one lock and needs to acquire the other and vice versa? Yes. ps->devsem is used to protect against disconnection: all top level routines take it (as a read lock), and in driver_disconnect it is taken as a write lock. Top level routines call lower level routines which sometimes need to take dev->serialize (and do already in several places). Thus: ps->devsem taken, then dev->serialize. However, dev->serialize is taken by the USB core before calling driver_disconnect. Thus: dev->serialize taken, then ps->devsem. > > Actually, simply replacing ps->devsem with ps->dev->serialize > > cannot lead to any new deadlocks, it makes deadlocks that could > > occasionally happen always happen (such deadlocks exist right now in > > usbfs). Some of the current deadlocks can be eliminated without giving > > up ps->devsem, but not all. So the question is: must ps->dev->serialize > > be used? > > It must be held when you call usb_reset_configuration(). It must _not_ be > held when you call usb_set_configuration(). For usb_reset_device() right > now you must not hold it, although that may change in the future. For > usb_unbind_interface() you must not hold it. There's a note that > usb_driver_claim_interface() grabs the BKL for some reason having to do > with usbfs -- no doubt when usbfs is fixed that won't be needed and the > caller will be required to hold dev->serialize instead. Right. And why should (for example) dev->serialize not be held when it calls usb_set_configuration? - because usb_set_configuration takes dev->serialize. This is one of the places I mentioned above where deadlock can occur right now. > If you call usb_ifnum_to_if() you ought to hold the serialize lock; > otherwise the configuration might change out from under you. But it's not > necessary. Likewise for usb_epnum_to_ep_desc if you're looking up an > endpoint that isn't part of an interface you have bound. Why isn't it necessary? As far as I can see it is vital. > > > Are they any reasons for not keeping ps->devsem? Since usbfs generally > > > acts as a driver and drivers generally don't have to concern themselves > > > with usbdev->serialize (the core handles it for them), shouldn't usbfs > > > also be able to ignore ps->dev->serialize? > > > > No, because it needs to do operations on interfaces it hasn't claimed > > (such as looking them up and claiming them). This is why it needs to > > protect itself, at least momentarily, against configurations shifting > > under it. This can be done by using the BKL more. However it can be > > done more simply using ps->dev->serialize (in fact it is simpler than > > what is there now). > > That agrees with my assessment. It ought to be possible to remove these > references to the BKL in favor of ps->dev->serialize. Yes, and that is what my patch does. And due to the above problem with deadlock it replaces ps->devsem with ps->dev->serialize everywhere. > > By the way, if it is somehow fatal to do usb_put_dev after disconnect, > > what is the point of referencing counting at all? You might as well > > free up the usb_device structure immediately after disconnect, since > > there is sure to be a reference before disconnect, and (apparently) > > there had better not be a reference after disconnect... > > There's some sort of misunderstanding here. It's not fatal to do > usb_put_dev() after disconnect, provided you called usb_get_dev() earlier. > I'm not sure what the cause was of the oops you were getting, but it > wasn't that. It was AFAICS, though of course it shouldn't be. Ciao, Duncan. --- This SF.net email is sponsored by: IBM Linux Tutorials. Become an expert in LINUX or just sharpen your skills. Sign up for IBM's Free Linux Tutorials. Learn everything from the bash shell to sys admin. Click now! http://ads.osdn.com/?ad_id=1278&alloc_id=3371&op=click ___ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] RFC: Synchronous unlinking and resubmission of URBs
Adding uhci_endpoint_disconnect() will resolve the disconnect() path issue. In fact, once that's added, drivers could even start to get rid of all urb unlink calls in their disconnect() logic, enabling that "fire and forget" model. Remember the non-hcd drivers. Do they implement disable_endpoint() in the right way? Well, if they're going to run on 2.6 they certainly should ... :) Right now the only such old-style HCD in the kernel tree is the SL-811 code, and it allegedly doesn't work. Old-style HCDs are by and large found in embedded Linux systems, and most of those folk haven't started moving to 2.6 kernels. They'll have to update USB drivers as well as everything else. - Dave --- This SF.net email is sponsored by: IBM Linux Tutorials. Become an expert in LINUX or just sharpen your skills. Sign up for IBM's Free Linux Tutorials. Learn everything from the bash shell to sys admin. Click now! http://ads.osdn.com/?ad_id=1278&alloc_id=3371&op=click ___ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] RFC: Synchronous unlinking and resubmission of URBs
This is becoming more complex than I expected... In the following, please don't think that I'm trying to defend the strategy I suggested earlier. I don't care very much what solution ends up being adopted; I just want to make people aware of the scope and nature of the problem. Part of the difficulty stems from the fact that a driver's view of things might not be in close accord with the core's views, and that even different core developers may have had different views at one time or another. On Mon, 8 Dec 2003, David Brownell wrote: > Alan Stern responding to David Brownell: > > >>But did any kernel ever guarantee those semantics? I don't think so. > >>Certainly 2.6 never did, and neither OHCI nor EHCI on 2.4 does... > > > > I agree, they didn't. However, that lack didn't prevent driver authors > > from _assuming_ that they did. > > Sure, but I can't think of that as anything other than a > set of long-standing driver bugs. Someone with a different viewpoint might call it a long-standing bug in the core :-) Regardless, it should be fixed. > > Whether this is smaller than my patch is a question of interpretation: > > Yours is a much bigger change for the device driver! It also doesn't > > But those are less fragile than the combination of usbcore and > the hcds. Changing the semantics of unlinking could have lots > of un-intended consequences at lower levels; IMO they should > get even simpler, not more complicated. The changes I suggested did not affect the lower levels (HCDs) more than minimally. Mostly they changed the way synchronous unlink worked at the hcd.c level and added a failure mode to submit_urb. Overall I could argue that the net result was not more complication, in that synchronous unlinking would behave more uniformly than it currently does. > On the other hand, if we just agreed not to call those semantics > by the name "unlinking", and to provide them through some simple > function like usb_urb_begone(), then I see simple ways out. > > Sure many drivers would need "obviously correct" one-line changes, > to call that routine. But that'd be unlikely to break any of > the hard-to-fix lower level code. That's fine by me. A large part of the problem has been that people want varying functionality but they call the functions by the same name. One person saying "Your implementation of usb_unlink_urb is wrong because it doesn't do what I think it should", when in fact it does do what the other person thinks it should, can only lead to mayhem. > > address the problems of failing resubmission and races between submit and > > unlink. > > That second problem is orthogonal; even drivers that use > asynchronous unlinking have to solve it. Yes. The resubmission issue is more subtle. After all, if one agrees that synchronous unlink means waiting until the completion handler has returned _and_ the URB is idle, what then should happen if the completion handler resubmits? On the other hand, if one thinks that synchronous unlink merely means waiting until the completion handler returns, there's no problem. It's that same paradigm error. Different people have different expectations and we need to settle on a single meaning. > > But as far as I can see, there is _no_ statement in the kernel source > > about what struct usb_operations->disable() is supposed to do. The > > comments in front of one implementation in hcd.c (hcd_endpoint_disable) > > merely state that all endpoint state is gone from the hardware. Since > > UHCI doesn't store any endpoint state in the hardware to begin with, > > that doesn't say anything. _Nothing_ is mentioned anywhere about > > waiting until all the software/driver state is gone as well. > > If usbfs were waiting for urb completions, that UHCI-specific > behavior wouldn't matter -- there'd be no oopsing. If that > UHCI-specific behavior were changed, there'd also be none. > > ... the thing is, I think that we probably added an "expectation" > that HCDs wait for the URBs to complete, by some changes several > months after the disable() method was first defined. That's > where the UHCI-specific problem came up. This is not a real problem. We just need to add kerneldoc explaining what the disable() method is supposed to do (along with adding the UHCI implementation). > > If the urb was resubmitted by the completion handler, urb_begone() as > > written would loop endlessly. > > At the risk of sounding like a broken record, device > drivers that don't have synchronization on resubmit > paths are buggy, and they need to add it. Wouldn't it be nice if the core provided a mechanism (not a policy!) that would make it easy for drivers to synchronize on resubmit paths without having to add a lot of tricky locking code? endpoint_disable() combined with urb_begone() might well be enough. Alan Stern --- This SF.net email is sponsored by: IBM Linux Tutorials. Become a
Re: [linux-usb-devel] RFC: Synchronous unlinking and resubmissionofURBs
Am Montag, 8. Dezember 2003 20:07 schrieb Alan Stern: > On Mon, 8 Dec 2003, Oliver Neukum wrote: > > > > My patch does this (submissions made before the synchronous unlink returns > > > will fail). > > > > I've changed my mind on this. Outright failure is a change of semantics. > > It is not needed. Simply set a flag in this case and return success. > > After the completion handler has returned, check the flag and recall it > > with the error code for synchronous unlink in urb->status. > > > > > Not quite so trivial to implement without races, but there are _no_ > > > > changes to existing semantics. > > > Yes. That's the point. The essential point here is that usb_unlink_urb() > > has to wait for the completion handler. The rest is sugar coating. > > As I have pointed out you can do it with zero change to the API. > > I think you have underestimated the problems here. Suppose the completion > handler resubmits and the resubmitted URB manages to complete before the > original completion handler returns? Then giveback_urb would be invoked > reentrantly. Which invocation should unlink_urb() then wait for? What if > the resubmitted completion was the result of another synchronous unlink? Why are these new problems? The newly submitted URB cannot complete because the hardware or SMP code will prevent an IRQ handler from being reentered. You yourself have solved the problem or you couldn't fail resubmission under these circumstances. Could you elaborate? > Furthermore, in stating your essential point you have contradicted > yourself. "usb_unlink_urb() has to wait for the completion handler". > But the API currently does not make that guarantee. If you add it in, you > change the API. No, or at least not visibly ;-) The current code will return either before after, while or before the completion handler has run. If we change the code so that the completion handler will always have run we behave in a way the current code can behave. We just do so always. Correct code will not be affected. The same is true for racing with resubmission in the completion handler. The current code can either error or unlink the newly submitted URB. If we make sure the latter case always wins the race, it's still not an outright change of the API. > > > I like that idea. In fact, why not make usb_unlink_urb() be purely async? > > > > Shouldn't the common case of synchronous unlink be made simple? > > To some extent I sympathize. But there is a precedent for not making the > common case simple. Consider fork-exec. The most common use is for > spawning new processes. But separating the two operations, thereby making > spawn less simple, provided new and important capabilities. From the USB > core's point of view, asynchronous unlink is the natural atomic operation. OK, I'll consider it a matter of personal taste then :-) > > > Another important area where better synchronization is needed in the core > > > is submission/unlinking. An URB should be either: > > > > > > idle (not used at all or just beginning the submission process > > > but not yet linked by the HCD), > > > in progress (linked by the HCD, no errors encountered yet, not > > > unlinked, not completed), > > > or finishing up (error, unlink, or in completion handler). > > > > > > These state changes should be protected by urb->lock. But they aren't, > > > and we currently can't distinguish between idle and finishing up. > > > > > > My proposal would make thise categories reliably detectable: > > > > > > idle: urb->usage_count == 0, > > > in progress:urb->usage_count > 0 and urb->status = -EINPROGRESS, > > > finishing up: urb->usage_count > 0 and > > > urb->status != -EINPROGRESS. > > > > > > > What exactly does this buy? > > usb_submit_urb() and usb_unlink_urb() don't change their behaviour based > > on this states #1 and #3, except for usb_unlink_urb() waiting for a transition > > out of #3 > > Waiting for a transition out of state #3 is important for synchronous > unlinking. Also, even though the difference between state #2 on the one > hand and states #1 and #3 on the other can currently be checked by looking > at urb->status, doing so isn't reliable. urb->status is set to > -EINPROGRESS in usb_submit_urb() long before the HCD has actually linked > it in (and hence before an unlink call can succeed). I see. > > Having seperate operations for synchronous and asynchronous unlinking > > is independent from that and a good idea, but 2.7 stuff. > > As far as I'm concerned, this is all 2.7 stuff. Well, you are saying that there are numerous bugs in the drivers concerning usb_unlink_urb(). Shouldn't something be done? Regards Oliver --- This SF.net email is sponsored by: IBM Linux Tutorials. Become an expert in LINUX or just sharpen your skills. Sign up for IBM's Free Linux
Re: [linux-usb-devel] RFC: Synchronous unlinking and resubmission of URBs
On Mon, 8 Dec 2003, David Brownell wrote: > I'll be shocked if that name survives too ... ;) > Maybe "usb_stop_urb()" would be better. Or usb_wait_for_urb(). > Re implementation, I'll continue to lobby for simplicity. > Polling doesn't bother me much, since it should only be > called once. It's true that HC drivers ought to be able to unlink and giveback an URB in only a few hundredths of a second. > Drivers can implement interruptible waits > themselves, on top of async unlink. If any of them even need it. > And the usage count thing seems to be designed to facilitate something > that I think usbcore should avoid. I'm not sure what you're referring to. The particular reason I introduced it was to handle the case of reentrant calls to giveback_urb. I don't see how the core can avoid them if the proper conditions come up. > > Another important area where better synchronization is needed in the core > > is submission/unlinking. An URB should be either: > > > > idle (not used at all or just beginning the submission process > > but not yet linked by the HCD), > > in progress (linked by the HCD, no errors encountered yet, not > > unlinked, not completed), > > or finishing up (error, unlink, or in completion handler). > > Why should the model visible to drivers be any more complex > than the simple two-state model I thought we had today? > >- URB is inactive. Device driver handles any nuances like > never-used, just-completed, etc. Device driver may submit > it, if it's properly initialized. > >- URB is submitted. HCD controls it, and manages nuances like > whether the hardware sees it, whether it's being canceled, > whether completion status is known, etc. HCD will give it > back (state becomes inactive). Device driver may unlink, > but otherwise may not access that URB. > > That is, your "finishing up" is just some HCD-internal variant > of "linked" -- except for "in completion handler", which is > the first not-linked state on today's return path. The problem with this simple two-state model is that it does not facilitate an implementation of synchronous unlinking that waits until the URB is idle. Of course, for anyone who believes that synchronous unlink only means waiting until the completion handler returns, this doesn't matter. But for device drivers that want to reuse an URB it does matter. Anyway, the existing code doesn't follow this model exactly: usb_unlink_urb checks whether urb->status is -EINPROGRESS before calling the HC driver. According to the model it shouldn't do that; instead it should check whether the URB is submitted (active). But we currently have no way of doing this, since still-linked URBs can have status other than -EINPROGRESS and non-linked URBs can have status equal to -EINPROGRESS. > > These state changes should be protected by urb->lock. But they aren't, > > and we currently can't distinguish between idle and finishing up. > > I don't follow. Today, state transitions are made by only two > function calls -- usb_submit_urb, usb_hcd_giveback_urb -- since > there are only two transitions. And urb->lock is used to make > the usbcore/hcd boundary handle unlinking -- no more. Exactly -- no more. It doesn't protect the submission transition. Alan Stern --- This SF.net email is sponsored by: IBM Linux Tutorials. Become an expert in LINUX or just sharpen your skills. Sign up for IBM's Free Linux Tutorials. Learn everything from the bash shell to sys admin. Click now! http://ads.osdn.com/?ad_id=1278&alloc_id=3371&op=click ___ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
[linux-usb-devel] Re: [UHCI] deadlock when interrupts are broken
On Tue, Dec 09, 2003 at 08:02:07AM +1100, herbert wrote:
>
> Sorry about that. Can you please comment on the following patch which
> no longer frees the QHs and TDs outside of the interrupt routine.
I guess this patch has the same problems as the last since the TDs
might still be active. But if that's the case, isn't the current code
racy as well since when uhci_urb_dequeue adds an entry to urb_remove_list,
the interrupt routine may already be active so it may process the entry
straight away. What protects that from racing against the hardware?
Cheers,
--
Debian GNU/Linux 3.0 is out! ( http://www.debian.org/ )
Email: Herbert Xu ~{PmV>HI~} <[EMAIL PROTECTED]>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
---
This SF.net email is sponsored by: IBM Linux Tutorials.
Become an expert in LINUX or just sharpen your skills. Sign up for IBM's
Free Linux Tutorials. Learn everything from the bash shell to sys admin.
Click now! http://ads.osdn.com/?ad_id=1278&alloc_id=3371&op=click
___
[EMAIL PROTECTED]
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] Re: [UHCI] deadlock when interrupts are broken
On Mon, Dec 08, 2003 at 04:37:26PM -0500, Alan Stern wrote:
>
> That's supposed to work right now. However, there may be a problem with
> the uhci_stop() routine. While I haven't checked this in detail, it
> appears that the first calls to uhci_free_pending_qhs() and
> uhci_free_pending_tds() may be unnecessary, while there ought to be a call
> to uhci_finish_completion() just after the reset_hc().
Unfortunately this doesn't fix the problem that I was seeing.
The problem here is the khubd is stuck in usb_set_address() waiting
for the URB to complete, but it never finishes because the UHCI driver
isn't getting any interrupts.
Unloading UHCI gets stuck because usb_disconnect() is called before
uhci_stop() and usb_disconnect() can't finish because khubd is holding
its semaphore.
> I suspect your patch is not really needed. Try implementing what I said
> above and see if it helps. Better yet, go through the code in uhci_stop()
> more carefully than I did and figure out what it really should be doing.
This makes sense. But we'll need to resolve issues like the above
before it'll work.
Cheers,
--
Debian GNU/Linux 3.0 is out! ( http://www.debian.org/ )
Email: Herbert Xu ~{PmV>HI~} <[EMAIL PROTECTED]>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
---
This SF.net email is sponsored by: IBM Linux Tutorials.
Become an expert in LINUX or just sharpen your skills. Sign up for IBM's
Free Linux Tutorials. Learn everything from the bash shell to sys admin.
Click now! http://ads.osdn.com/?ad_id=1278&alloc_id=3371&op=click
___
[EMAIL PROTECTED]
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
[linux-usb-devel] Timeout problems for ADSL USB modems
Hello, I have adapted Alcatel Speedtouch USB Linux driver to work with several ADSL USB modems. I'd like know your conclusion about timeout problems. Please, you see this thread: https://sourceforge.net/forum/forum.php?thread_id=952503&forum_id=287227 Solution for kernel 2.4.23 from an user: "I'm connect whit 2.4.23 kernel. I only change usb_settoggle definition in usb.h . But kernel isn't full configure I set only minimal options to work." Regards, Josep --- This SF.net email is sponsored by: IBM Linux Tutorials. Become an expert in LINUX or just sharpen your skills. Sign up for IBM's Free Linux Tutorials. Learn everything from the bash shell to sys admin. Click now! http://ads.osdn.com/?ad_id=1278&alloc_id=3371&op=click ___ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
[linux-usb-devel] Timeout problems for ADSL USB modems (second part)
To solve USB timeout problems with new kernels (2.4.22, 2.4.23 and others):
Edit "./include/linux/usb.h"
Change "usb_settoggle" definition.
Change this:
static inline void usb_settoggle(struct usb_device *dev,
unsigned int ep,
unsigned int out,
int bit)
{
dev->toggle[out] &= ~(1 << ep);
dev->toggle[out] |= bit << ep;
}
by this:
#define usb_settoggle(dev, ep, out, bit) ((dev)->toggle[out] =
((dev)->toggle[out] & ~(1 << ep)) | ((bit) << ep))
Solution provided by users of Zyxel 630-11 Linux driver forum
(http://sourceforge.net/projects/zyxel630-11
Regards,
Josep
---
This SF.net email is sponsored by: IBM Linux Tutorials.
Become an expert in LINUX or just sharpen your skills. Sign up for IBM's
Free Linux Tutorials. Learn everything from the bash shell to sys admin.
Click now! http://ads.osdn.com/?ad_id=1278&alloc_id=3371&op=click
___
[EMAIL PROTECTED]
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
[linux-usb-devel] USB / TAPE Devices
Hello all, I'm digging through the USB mass storage code and am pretty confused. Previously we used a Sony AIT-1 tape drive via SCSI. However, we recently acquired a new model that supports either firewire / USB. Neither works (I think for the same reason). I realize that most people do not have such an expensive tape device so little testing happens on these units--thats why I'm trying to figure whats going on and hopefully fix the problem. The device can be read/written to, but I cannot set the block size of the device (I/O ERROR). A block size change equates to the issuing of a MODE_SELECT command. In looking through the various code (2.4.22 kernel), I see a whole bunch of mess related to MODE_SELECT(6) vs MODE_SELECT(10) translation. There are multiple transports such as: SCSI transports, ATAPI, and QIC routines. >From my detailed device programming manual - the device is an ATAPI tape drive put into a USB 2.0 / Firewire external case. The documentation shows that the device ONLY support MODE_SELECT(6) which is command 0x15 - however that command must be 12 bytes long. It looks just like a SCSI MODE_SELECT(6) padded with zeros on the end. What is the correct way to support this device with a 2.4 kernel? I'm a bit confused when it comes to tracing the flow of the data from the original 'mt -f /dev/st0 setblk 0' down to the USB level. I find that the scsi mid-level set the command len to 6 based on the MODE_SELECT(6) opcode. In looking at the mass storage device driver: The device is reporting its protocol as "Transparent SCSI" (0x50) which causes the usb_stor_transparent_scsi_command() protocol handler to be used. Looking at this handler I don't see where it pads the command to 12 ATAPI bytes. I also notice some 'US_FL_MODE_XLATE' flags - however am I correct to assume that the 'us->flags' is never set except for devices listed in the 'unusual_devices' array with their flags forced? 1) How should a device like this be handled? I thought maybe it should be considered ATAPI instead of Transparent SCSI since the underlying tape drive is an ATAPI version (Sony SDX-420C). However, the ATAPI protocol routines translate from MODE_SELECT(6) to MODE_SELECT(10) which is not supported by this device. It seems like there needs to be a mode simply for padding and nothing else. I hope this makes some sense. The archives didn't help on this issue, but that might be because I am the first person using one of these tape devices - it appears most mass storage issues to date relate to DVD, CD, or FLASH devices. --- This SF.net email is sponsored by: IBM Linux Tutorials. Become an expert in LINUX or just sharpen your skills. Sign up for IBM's Free Linux Tutorials. Learn everything from the bash shell to sys admin. Click now! http://ads.osdn.com/?ad_id=1278&alloc_id=3371&op=click ___ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] Re: [OOPS, usbcore, releaseintf] 2.6.0-test10-mm1
On Mon, 8 Dec 2003, Duncan Sands wrote: > > > You can't keep the ps->devsem lock and use ps->dev->serialize, because it > > > leads to deadlock. > > > > How so? Remember that I am almost totally unfamiliar with the details of > > the usbfs code. Are you saying there are places where the driver holds > > one lock and needs to acquire the other and vice versa? > > Yes. ps->devsem is used to protect against disconnection: all top level > routines take it (as a read lock), and in driver_disconnect it is taken as a > write lock. Top level routines call lower level routines which sometimes > need to take dev->serialize (and do already in several places). > > Thus: ps->devsem taken, then dev->serialize. > > However, dev->serialize is taken by the USB core before calling > driver_disconnect. > > Thus: dev->serialize taken, then ps->devsem. This is a tricky situation, no doubt about it. Your situation is a little different from the usual one because ps->devsem locks the whole device, not just a single interface. It should still be able to work. But maybe you're right; since ps->devsem locks the same thing as ps->dev->serialize, maybe it's not needed. By the way, when usbfs takes ownership of a device, does it bind to the device's interfaces? > Right. And why should (for example) dev->serialize not be held when it > calls usb_set_configuration? - because usb_set_configuration takes > dev->serialize. This is one of the places I mentioned above where > deadlock can occur right now. You may simply have to release the lock because calling usb_set_configuration and then reacquire it afterwards. That leads to the question of how to assure that the device doesn't go away before usb_set_configuration is called. Perhaps usb_set_configuration and usb_unbind_interface should be changed to require the caller to hold the serialize lock. > > If you call usb_ifnum_to_if() you ought to hold the serialize lock; > > otherwise the configuration might change out from under you. But it's not > > necessary. Likewise for usb_epnum_to_ep_desc if you're looking up an > > endpoint that isn't part of an interface you have bound. > > Why isn't it necessary? As far as I can see it is vital. I mean it won't cause an oops, although it might provide an invalid result. It's not _required_ by the API (maybe it should be). Actually, there's another sense in which it's not necessary. Since changing configurations first involves unbinding the existing drivers, if you hold a driver-private lock that will block your disconnect routine then you can safely call usb_ifnum_to_if even without holding dev->serialize. > > There's some sort of misunderstanding here. It's not fatal to do > > usb_put_dev() after disconnect, provided you called usb_get_dev() earlier. > > I'm not sure what the cause was of the oops you were getting, but it > > wasn't that. > > It was AFAICS, though of course it shouldn't be. I didn't note the reason for the oops. Was it a segmentation violation? The usb_device memory isn't deallocated until the reference count goes to 0. Maybe something was doing an extra usb_put_dev. Alan Stern --- This SF.net email is sponsored by: IBM Linux Tutorials. Become an expert in LINUX or just sharpen your skills. Sign up for IBM's Free Linux Tutorials. Learn everything from the bash shell to sys admin. Click now! http://ads.osdn.com/?ad_id=1278&alloc_id=3371&op=click ___ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
[linux-usb-devel] Usb root on 2.6.0
Hi! Sorry to bother you, probably someone asked about it before, but there is no search on sf.net, so I don't know... Does anyone know how to setup root partition on usb-storage device. There is a patch mentioned on linux-usb.sourceforge.net: http://www.lammerts.org/software/kernelpatches/usb-storage-root.patch but it seems to work only on 2.4.14-17, and than the patches are rejected because root device inits went from super.c to do_mounts.c. In meantime some api changed a bit, so direct transformation of that patch into 2.6 code (paste the code into similiar function in do_mounts) seems not to work. Is anyone working on it? On 2.4.14 there was enough to delay the kernel a bit before mounting root, but not on the 2.6:( Thx in advance Tomasz --- This SF.net email is sponsored by: IBM Linux Tutorials. Become an expert in LINUX or just sharpen your skills. Sign up for IBM's Free Linux Tutorials. Learn everything from the bash shell to sys admin. Click now! http://ads.osdn.com/?ad_id=1278&alloc_id=3371&op=click ___ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] Usb root on 2.6.0
On Mon, 08 Dec 2003 23:02:32 + Tomasz Mloduchowski <[EMAIL PROTECTED]> wrote: | Hi! | | Sorry to bother you, probably someone asked about it before, but there | is no search on sf.net, so I don't know... | | Does anyone know how to setup root partition on usb-storage device. | | There is a patch mentioned on linux-usb.sourceforge.net: | http://www.lammerts.org/software/kernelpatches/usb-storage-root.patch | | but it seems to work only on 2.4.14-17, and than the patches are | rejected because root device inits went from super.c to do_mounts.c. | | In meantime some api changed a bit, so direct transformation of that | patch into 2.6 code (paste the code into similiar function in do_mounts) | seems not to work. | | Is anyone working on it? On 2.4.14 there was enough to delay the kernel | a bit before mounting root, but not on the 2.6:( I updated the Lammerts patch to 2.4.22 and someone tested it and verified that it works (for them :). I haven't looked at applying it to 2.6.0-test, but I can do that if you have troubles doing it. The 2.4.x udpated patch is at http://www.xenotime.net/linux/usb/usbboot-2422.patch -- ~Randy MOTD: Always include version info. --- This SF.net email is sponsored by: IBM Linux Tutorials. Become an expert in LINUX or just sharpen your skills. Sign up for IBM's Free Linux Tutorials. Learn everything from the bash shell to sys admin. Click now! http://ads.osdn.com/?ad_id=1278&alloc_id=3371&op=click ___ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] Re: [UHCI] deadlock when interrupts are broken
Herbert Xu wrote: The problem here is the khubd is stuck in usb_set_address() waiting for the URB to complete, but it never finishes because the UHCI driver isn't getting any interrupts. OHCI could have the same problem. EHCI doesn't, since it's had a timer interrupt ever since it first needed one to work on a VIA VT6202 chip ... :) I've thought that OHCI could detect this "IRQs are broken" problem earlier. I suspect UHCI could use the same kind of fix that came to mind: as the HCD starts, enable an IRQ for SOF, and wait a couple milliseconds to make sure it had a chance to arrive. If it came -- continue. Else, report IRQs not working (because of ACPI or whatever) and refuse to initialize that controller. Comments? - Dave --- This SF.net email is sponsored by: IBM Linux Tutorials. Become an expert in LINUX or just sharpen your skills. Sign up for IBM's Free Linux Tutorials. Learn everything from the bash shell to sys admin. Click now! http://ads.osdn.com/?ad_id=1278&alloc_id=3371&op=click ___ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] Re: [UHCI] deadlock when interrupts are broken
On Mon, Dec 08, 2003, David Brownell <[EMAIL PROTECTED]> wrote: > Herbert Xu wrote: > > > The problem here is the khubd is stuck in usb_set_address() waiting > > for the URB to complete, but it never finishes because the UHCI driver > > isn't getting any interrupts. > > OHCI could have the same problem. > > EHCI doesn't, since it's had a timer interrupt ever since it > first needed one to work on a VIA VT6202 chip ... :) > > I've thought that OHCI could detect this "IRQs are broken" > problem earlier. I suspect UHCI could use the same kind of > fix that came to mind: as the HCD starts, enable an IRQ > for SOF, and wait a couple milliseconds to make sure it > had a chance to arrive. If it came -- continue. Else, > report IRQs not working (because of ACPI or whatever) and > refuse to initialize that controller. I've thought of doing something similar, but I decided against implementing it. Mostly because it would slow down the initialization of the controller and it will be obvious that something is broken when a device is plugged in later. Thinking about it now, I guess a clearer error message, for a problem as frequest as this, would be a good thing. JE --- This SF.net email is sponsored by: IBM Linux Tutorials. Become an expert in LINUX or just sharpen your skills. Sign up for IBM's Free Linux Tutorials. Learn everything from the bash shell to sys admin. Click now! http://ads.osdn.com/?ad_id=1278&alloc_id=3371&op=click ___ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
[linux-usb-devel] 802.11 wireless
I've been trying to find a USB 802.11 wireless device, for use with Linux. I'm having a little difficulties figuring out which models will work with standard Linux source, which models require a patch, which models have binary only modules, and which models require windoze. If anybody has any good experiences with a particular device, could you tell which device? Thanks David -- David Meggy Engineering Technical Solutions Inc. Unit #1 7157 Honeyman St Delta BC Canada, V4G 1E2 www.techsol.ca eMail: [EMAIL PROTECTED] Tel: 604 946 TECH (8324) Fax: 604 946 6445 --- This SF.net email is sponsored by: IBM Linux Tutorials. Become an expert in LINUX or just sharpen your skills. Sign up for IBM's Free Linux Tutorials. Learn everything from the bash shell to sys admin. Click now! http://ads.osdn.com/?ad_id=1278&alloc_id=3371&op=click ___ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] Re: [UHCI] deadlock when interrupts are broken
I've thought that OHCI could detect this "IRQs are broken" problem earlier. I suspect UHCI could use the same kind of fix that came to mind: as the HCD starts, enable an IRQ for SOF, and wait a couple milliseconds to make sure it had a chance to arrive. If it came -- continue. Else, report IRQs not working (because of ACPI or whatever) and refuse to initialize that controller. I've thought of doing something similar, but I decided against implementing it. Mostly because it would slow down the initialization of the controller and it will be obvious that something is broken when a device is plugged in later. Right, but "deadlock" is a rather unfriendly kind of obvious. Which is why a better fix was on my mind... Thinking about it now, I guess a clearer error message, for a problem as frequest as this, would be a good thing. I'd expect that Herbert was getting the "Unlink after no-IRQ? ..." message from hcd_unlink_urb() ... I added that a while back, and I like to think it's somewhat reduced the number of failure reports we get which we'd just need to blame on IRQ setup problems. (I sure don't remember seeing any such reports recently, which seems like a significant change.) Getting such a message before a deadlock is way better than getting none at all. But not deadlocking would be even better ... ;) - Dave --- This SF.net email is sponsored by: IBM Linux Tutorials. Become an expert in LINUX or just sharpen your skills. Sign up for IBM's Free Linux Tutorials. Learn everything from the bash shell to sys admin. Click now! http://ads.osdn.com/?ad_id=1278&alloc_id=3371&op=click ___ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] Re: [UHCI] deadlock when interrupts are broken
On Mon, Dec 08, 2003, David Brownell <[EMAIL PROTECTED]> wrote: > > >>I've thought that OHCI could detect this "IRQs are broken" > >>problem earlier. I suspect UHCI could use the same kind of > >>fix that came to mind: as the HCD starts, enable an IRQ > >>for SOF, and wait a couple milliseconds to make sure it > >>had a chance to arrive. If it came -- continue. Else, > >>report IRQs not working (because of ACPI or whatever) and > >>refuse to initialize that controller. > > > > I've thought of doing something similar, but I decided against > > implementing it. Mostly because it would slow down the initialization of > > the controller and it will be obvious that something is broken when a > > device is plugged in later. > > Right, but "deadlock" is a rather unfriendly kind of obvious. > Which is why a better fix was on my mind... The deadlock is another problem, I'm sure of it. > > Thinking about it now, I guess a clearer error message, for a problem as > > frequest as this, would be a good thing. > > I'd expect that Herbert was getting the "Unlink after no-IRQ? ..." > message from hcd_unlink_urb() ... I added that a while back, and > I like to think it's somewhat reduced the number of failure reports > we get which we'd just need to blame on IRQ setup problems. (I sure > don't remember seeing any such reports recently, which seems like a > significant change.) > > Getting such a message before a deadlock is way better than getting > none at all. But not deadlocking would be even better ... ;) Yes. I think the ultimate problem is the deadlock, which should not be happening. Atleast, it didn't happen in the past. I think a bug must have crept in there somewhere. JE --- This SF.net email is sponsored by: IBM Linux Tutorials. Become an expert in LINUX or just sharpen your skills. Sign up for IBM's Free Linux Tutorials. Learn everything from the bash shell to sys admin. Click now! http://ads.osdn.com/?ad_id=1278&alloc_id=3371&op=click ___ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] Re: [UHCI] deadlock when interrupts are broken
> > I'd expect that Herbert was getting the "Unlink after no-IRQ? ..."
> > message from hcd_unlink_urb() ... I added that a while back, and
I don't get that error because the interrupts stopped working after a
suspend/resume. Since the saw_irq flag isn't reset during a
suspend/resume that message is not shown.
--
Debian GNU/Linux 3.0 is out! ( http://www.debian.org/ )
Email: Herbert Xu ~{PmV>HI~} <[EMAIL PROTECTED]>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
---
This SF.net email is sponsored by: IBM Linux Tutorials.
Become an expert in LINUX or just sharpen your skills. Sign up for IBM's
Free Linux Tutorials. Learn everything from the bash shell to sys admin.
Click now! http://ads.osdn.com/?ad_id=1278&alloc_id=3371&op=click
___
[EMAIL PROTECTED]
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] usb-storage in 2.4
On Mon, 8 Dec 2003 12:52:30 -0800 "Randy.Dunlap" <[EMAIL PROTECTED]> wrote: | Customers keep complaining that usb-storage is unusable in 2.4, | so I looked at it and WOA! Very simple things, like running | dd if=/dev/sda of=/dev/null bs=8k and then unplugging the | flash cause oopses and lockups; once those are fixed, storage | can get offline forever. Ugh. | | 2.6 looks much saner, but it's somewhat different and I do not | dare a backport. Here's a patch to add some sanity into the | carnival of semaphores. Oh, and never return failure from | the bus reset - it only serves to fall back to adapter reset, | which we do not implement. | | I would like someone to test it, to make sure I am not | breaking things (e.g. if any hangs happen). | | Greg & Matt, if you approve, I'll take arguing this with Marcelo, | if you need a help here. This is an issue for us, because | of proliferation of USB storage as factory option. And we | cannot just go to 2.6. I can't say that I tried to break it. I didn't pull plugs during USB I/O, e.g. I did apply this patch to 2.4.23 and run it on almost all of the USB storage devices that I have. All I/O was successful, using uhci, ohci, and ehci, playing mp3's while copying, etc. I compared several large copied files and they matched with no errors. devices: Y-E DATA floppy drives, SanDisk CF reader (single LUN), Belkin CF reader (multi-LUN), Lexar flash JumpDrive device, Mitsumi cd-rw (reading only), Maxtor hard drive, AcomData hard drive. Didn't test ZIP drive. -- ~Randy --- This SF.net email is sponsored by: IBM Linux Tutorials. Become an expert in LINUX or just sharpen your skills. Sign up for IBM's Free Linux Tutorials. Learn everything from the bash shell to sys admin. Click now! http://ads.osdn.com/?ad_id=1278&alloc_id=3371&op=click ___ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
[linux-usb-devel] canceling pending urbs (2.6.0-test11)?
How to cancel given URBs (that may be submitted earlier) so that I can be sure that after a certain point the USB subsystem will not access them again (to call usb_free_urb())? The first try would be to call usb_unlink_urb() (synchronously), but this checks for -EINPROGRESS and fails if the urb status is something else--in particular, if the device was just unplugged, the urbs may still be on the way, calling completion handler later, but usb_unlink_urb() fails, because status is changed. Looking in usb-skeleton.c, I see that it uses "completions" to wait until the URB handler has been called, but what if something goes wrong and the handler will never get called? I'd rather not to trust this, if possible, and that looks a bit unnecessarily complicated too. Also, I read pwc-if.c and ov511.c drivers it looks like they have a bug--they call usb_unlink_urb() and then immediately after usb_free_urb() but since the former doesn't guarantee that the URBs wouldn't be accessed later, the access may go to already freed memory. Searching mailing lists, I found a thread about "URB nuking on disconnect" but I'm not sure if it applies here. --- This SF.net email is sponsored by: IBM Linux Tutorials. Become an expert in LINUX or just sharpen your skills. Sign up for IBM's Free Linux Tutorials. Learn everything from the bash shell to sys admin. Click now! http://ads.osdn.com/?ad_id=1278&alloc_id=3371&op=click ___ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
