[linux-usb-devel] Re: SL811 USB driver interrupt handling
Hello You can have several bulk tansfert in one frame. And each device may have an interrupt packet for a frame number. In the same frame you may have one ore more isochronous, one or more interrupt, one or more bulk and one or more configure packet and for one or more device: You can have more than one packet in a frame. If there is still enough room in frame you can send more than one packet. Sylvain > Message: 4 > Date: Sat, 18 Jan 2003 11:33:39 -0500 > From: thomas chen <[EMAIL PROTECTED]> > Organization: on-go > To: Pei Liu <[EMAIL PROTECTED]> > CC: [EMAIL PROTECTED] > Subject: [linux-usb-devel] SL811 USB driver interrupt handling > > i am not sure if i understand this driver in depth the question > i have is who can multiple "packets" be sent within the same frame? > > the interrupt service routine (hc_interrupt) seems to allow only ONE > packet per frame? is this correct??? > > when xferdone is handled... the sh_done_list is called... if the > packet is done... it would return a (-1)... and the interrupt service > routine would not start another transaction (sh_schedule_transaction) > if the return value is not 0 that means no packet will go out until > next frame? > > is this the original design intent? am i missing something? > > thanks a bunch > > tom --- This SF.NET email is sponsored by: FREE SSL Guide from Thawte are you planning your Web Server Security? Click here to get a FREE Thawte SSL guide and find the answers to all your SSL security issues. http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0026en ___ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
[linux-usb-devel] Re: [Swsusp] after resume, rmmod usbcore fails
Am Montag, 20. Januar 2003 09:47 schrieb Charl P. Botha: > On Mon, 2003-01-20 at 07:31, Oliver Neukum wrote: > > Am Montag, 20. Januar 2003 00:03 schrieb Charl P. Botha: > > > This is kernel version 2.4.21-pre3 + acpi20030109 + swsusp16 and the > > > unkillable khubd happens after a cold restart, even if ALL usb modules > > > are removed before suspend and re-insmodded at resume. > > > > Just to make sure, are you doing a power cycle? > > Hmmm, good question. The machine is switched off via ACPI: this is a > full power-off S5. I switch it on again with the power button. Could you try this without any ACPI? ACPI is still experimental, so I'd like to be able to rule it out. Regards Oliver --- This SF.NET email is sponsored by: FREE SSL Guide from Thawte are you planning your Web Server Security? Click here to get a FREE Thawte SSL guide and find the answers to all your SSL security issues. http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0026en ___ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
[linux-usb-devel] [PATCH] simplify speedtouch receive urb lifecycle
speedtouch: simplify the receive urb lifecycle: allocate them in the usb probe
function,
free them on disconnect.
speedtouch.c | 81 +--
1 files changed, 51 insertions(+), 30 deletions(-)
diff -Nru a/drivers/usb/misc/speedtouch.c b/drivers/usb/misc/speedtouch.c
--- a/drivers/usb/misc/speedtouch.c Mon Jan 20 11:14:11 2003
+++ b/drivers/usb/misc/speedtouch.c Mon Jan 20 11:14:11 2003
@@ -688,18 +688,6 @@
for (i = 0, succes = 0; i < UDSL_NUMBER_RCV_URBS; i++) {
struct udsl_data_ctx *ctx = &(instance->rcvbufs[i]);
- ctx->urb = NULL;
- ctx->skb = dev_alloc_skb (UDSL_RECEIVE_BUFFER_SIZE);
- if (!ctx->skb)
- continue;
-
- ctx->urb = usb_alloc_urb (0, GFP_KERNEL);
- if (!ctx->urb) {
- kfree_skb (ctx->skb);
- ctx->skb = NULL;
- break;
- };
-
usb_fill_bulk_urb (ctx->urb,
instance->usb_dev,
usb_rcvbulkpipe (instance->usb_dev,
UDSL_ENDPOINT_DATA_IN),
@@ -707,12 +695,6 @@
UDSL_RECEIVE_BUFFER_SIZE,
udsl_usb_data_receive, ctx);
-
- ctx->instance = instance;
-
- PDEBUG ("udsl_usb_data_init: usb with skb->truesize = %d (Asked for
%d)\n",
- ctx->skb->truesize, UDSL_RECEIVE_BUFFER_SIZE);
-
if (usb_submit_urb (ctx->urb, GFP_KERNEL) < 0)
PDEBUG ("udsl_usb_data_init: Submit failed, loosing urb.\n");
else
@@ -753,10 +735,6 @@
continue;
usb_unlink_urb (ctx->urb);
-
- usb_free_urb (ctx->urb);
- kfree_skb (ctx->skb);
- ctx->skb = NULL;
}
tasklet_kill (&instance->recvqueue_tasklet);
@@ -842,6 +820,27 @@
tasklet_init (&instance->recvqueue_tasklet, udsl_atm_processqueue, (unsigned
long) instance);
+ /* receive urb init */
+ for (i = 0; i < UDSL_NUMBER_RCV_URBS; i++) {
+ struct udsl_data_ctx *ctx = &(instance->rcvbufs[i]);
+
+ if (!(ctx->skb = dev_alloc_skb (UDSL_RECEIVE_BUFFER_SIZE))) {
+ PDEBUG ("No memory for skb %d!\n", i);
+ err = -ENOMEM;
+ goto fail_urbs;
+ }
+
+ if (!(ctx->urb = usb_alloc_urb (0, GFP_KERNEL))) {
+ PDEBUG ("No memory for receive urb %d!\n", i);
+ err = -ENOMEM;
+ goto fail_urbs;
+ }
+
+ ctx->instance = instance;
+
+ PDEBUG ("skb->truesize = %d (asked for %d)\n", ctx->skb->truesize,
+UDSL_RECEIVE_BUFFER_SIZE);
+ }
+
/* atm init */
if (!(instance->atm_dev = atm_dev_register (udsl_driver_name,
&udsl_atm_devops, -1, 0))) {
PDEBUG ("failed to register ATM device!\n");
@@ -874,6 +873,16 @@
return 0;
fail_atm:
+fail_urbs:
+ for (i = 0; i < UDSL_NUMBER_RCV_URBS; i++) {
+ struct udsl_data_ctx *ctx = &(instance->rcvbufs[i]);
+
+ if (ctx->skb)
+ kfree_skb (ctx->skb);
+
+ if (ctx->urb)
+ usb_free_urb (ctx->urb);
+ }
kfree (instance);
fail_instance:
return err;
@@ -882,20 +891,32 @@
static void udsl_usb_disconnect (struct usb_interface *intf)
{
struct udsl_instance_data *instance = usb_get_intfdata (intf);
+ int i;
PDEBUG ("disconnecting\n");
usb_set_intfdata (intf, NULL);
- if (instance) {
- /* unlinking receive buffers */
- udsl_usb_data_exit (instance);
-
- /* removing atm device */
- if (instance->atm_dev)
- udsl_atm_stopdevice (instance);
- kfree (instance);
+ if (!instance) {
+ PDEBUG ("NULL instance!\n");
+ return;
}
+
+ /* unlinking receive buffers */
+ udsl_usb_data_exit (instance);
+
+ for (i = 0; i < UDSL_NUMBER_RCV_URBS; i++) {
+ struct udsl_data_ctx *ctx = &(instance->rcvbufs[i]);
+
+ usb_free_urb (ctx->urb);
+ kfree_skb (ctx->skb);
+ }
+
+ /* removing atm device */
+ if (instance->atm_dev)
+ udsl_atm_stopdevice (instance);
+
+ kfree (instance);
}
---
This SF.NET email is sponsored by: FREE SSL Guide from Thawte
are you planning your Web Server Security? Click here to get a FREE
Thawte SSL guide and find the answers to all your SSL security issues.
http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0026en
___
[E
Re: [linux-usb-devel] Need "advice" on communicating with Labjack USB device
> MaxPower Needed: 100mA Eric, The device appears non-compliant with USB 1.1 specification for power. Their documentation states that it is USB bus-powered, drawing a maximum of 100mA from the bus; yet the device can supply up to 200mA for 16 output pins. Add the power needed for the 'device' and other output pins to determine what the MaxPower should be. IMHO the best start is to obtain a specification for the device, detailing accessing the 8k memory, its microprocessor, and adjusting the information that the device did provide. Not having a specification can raise the difficulty of writing a driver by a substantial amount. best regards, gm --- This SF.NET email is sponsored by: FREE SSL Guide from Thawte are you planning your Web Server Security? Click here to get a FREE Thawte SSL guide and find the answers to all your SSL security issues. http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0026en ___ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
[linux-usb-devel] Re: SL811 USB driver interrupt handling
thanks... but i thought sh_done_list returns (urb_state = -1) if it is done??? but in the hc_interrupt... it checks whether urb_state == 0... which means it would not try another packet??? Pei Liu wrote: > > > > >i am not sure if i understand this driver in depth the question > >i have is who can multiple "packets" be sent within the same frame? > > Yes, you can send multiple USB transactions within the same frame. > > > > >the interrupt service routine (hc_interrupt) seems to allow only ONE > >packet per frame? is this correct??? > > > >when xferdone is handled... the sh_done_list is called... if the > >packet is done... it would return a (-1)... and the interrupt service > >routine would not start another transaction (sh_schedule_transaction) > >if the return value is not 0 that means no packet will go out until > >next frame? > > > > When USB Done interrupt occurred, it handles the interrupt by calling > sh_done_list() function. The sh_done_list() returns a code that determines > if the current USB transactions has completed. If it has not completed, it > would call the sh_add_packet() to complete current USB transaction.If it > has completed, then it would call the sh_schedule_trans() routine which will > schedule the next USB transactions. > > Pei --- This SF.NET email is sponsored by: FREE SSL Guide from Thawte are you planning your Web Server Security? Click here to get a FREE Thawte SSL guide and find the answers to all your SSL security issues. http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0026en ___ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
[linux-usb-devel] Re: SL811 USB driver interrupt handling
> >i am not sure if i understand this driver in depth the question >i have is who can multiple "packets" be sent within the same frame? Yes, you can send multiple USB transactions within the same frame. > >the interrupt service routine (hc_interrupt) seems to allow only ONE >packet per frame? is this correct??? > >when xferdone is handled... the sh_done_list is called... if the >packet is done... it would return a (-1)... and the interrupt service >routine would not start another transaction (sh_schedule_transaction) >if the return value is not 0 that means no packet will go out until >next frame? > When USB Done interrupt occurred, it handles the interrupt by calling sh_done_list() function. The sh_done_list() returns a code that determines if the current USB transactions has completed. If it has not completed, it would call the sh_add_packet() to complete current USB transaction.If it has completed, then it would call the sh_schedule_trans() routine which will schedule the next USB transactions. Pei --- This SF.NET email is sponsored by: FREE SSL Guide from Thawte are you planning your Web Server Security? Click here to get a FREE Thawte SSL guide and find the answers to all your SSL security issues. http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0026en ___ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
[linux-usb-devel] Re: SL811 USB driver interrupt handling
Do you know if it is ACCEPTABLE to turn of SOF interrupt when there is nothing to send a. would it stop SOF generation towards the function/device? b. can the driver turns on SOF before having something to send??? and turn if off after all ack/tarnsactions are completed this is to prevent loading down the cpu for those 1ms interrupt??? thanks Pei Liu wrote: > > > > >i am not sure if i understand this driver in depth the question > >i have is who can multiple "packets" be sent within the same frame? > > Yes, you can send multiple USB transactions within the same frame. > > > > >the interrupt service routine (hc_interrupt) seems to allow only ONE > >packet per frame? is this correct??? > > > >when xferdone is handled... the sh_done_list is called... if the > >packet is done... it would return a (-1)... and the interrupt service > >routine would not start another transaction (sh_schedule_transaction) > >if the return value is not 0 that means no packet will go out until > >next frame? > > > > When USB Done interrupt occurred, it handles the interrupt by calling > sh_done_list() function. The sh_done_list() returns a code that determines > if the current USB transactions has completed. If it has not completed, it > would call the sh_add_packet() to complete current USB transaction.If it > has completed, then it would call the sh_schedule_trans() routine which will > schedule the next USB transactions. > > Pei --- This SF.NET email is sponsored by: FREE SSL Guide from Thawte are you planning your Web Server Security? Click here to get a FREE Thawte SSL guide and find the answers to all your SSL security issues. http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0026en ___ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
[linux-usb-devel] Using drivers/usb from 2.4.21-pre3 in 2.4.19 kernel
As mentioned in a previous message, I'm unable to use 2.4.20 and 2.4.21-pre3 on my Globespan IVR (mips-based, little-endian) platform due to (I'm guessing) IDE problems. My kernel starts from flash, and detects the ide drives, but can't boot from them when the kernel is done loading. When I try to use the ehci driver in 2.4.19, any process that writes to the drive will freeze after writing about 20 MB of data. I was planning to try the new driver from 2.4.21-pre3 in the 2.4.19 kernel, but I'm running into problems. Perhaps someone else can shed some light on this. I replaced drivers/usb/* and include/linux/usb*.h in my 2.4.19 tree with the versions from 2.4.21-pre3. I was able to compile the kernel, but when I installed it I got the following errors when I turned on my USB 2.0 hard drive: hub.c: new USB device 00:13.2-2, assigned address 2 ehci-hcd 00:13.2: fatal error pci_pool_free 00:13.2/ehci_qtd, a03ee120/3ee120 (bad dma) pci_pool_free 00:13.2/ehci_qtd, a03ee0c0/3ee0c0 (bad dma) ehci-hcd 00:13.2: stopped in_interrupt! usb.c: USB device not accepting new address=2 (error=-32) hub.c: usb_hub_port_status (1) failed (err = -143) hub.c: usb_hub_port_status (1) failed (err = -143) hub.c: usb_hub_port_status (1) failed (err = -143) hub.c: usb_hub_port_status (1) failed (err = -143) hub.c: usb_hub_port_status (1) failed (err = -143) hub.c: Cannot enable port 2 of hub 1, disabling port. hub.c: Maybe the USB cable is bad? hub.c: cannot disable port 2 of hub 1 (err = -143) hub.c: usb_hub_port_status (1) failed (err = -143) hub.c: usb_hub_port_status (1) failed (err = -143) hub.c: usb_hub_port_status (1) failed (err = -143) hub.c: get_hub_status failed hub.c: new USB device 00:13.1-1, assigned address 2 scsi0 : SCSI emulation for USB Mass Storage devices The EHCI driver fails, and it falls back to OHCI (which works just fine). Any ideas why EHCI would fail like that? Do I need to update another part of the 2.4.19 kernel to be compatible with the 2.4.21-pre3 EHCI driver? I just switched back to the original 2.4.19 USB code, and drives mount just fine (Spd=480) under the EHCI driver. -- Tom Collins [EMAIL PROTECTED] --- This SF.NET email is sponsored by: FREE SSL Guide from Thawte are you planning your Web Server Security? Click here to get a FREE Thawte SSL guide and find the answers to all your SSL security issues. http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0026en ___ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
[linux-usb-devel] Re: SL811 USB driver interrupt handling
> >but i thought sh_done_list returns (urb_state = -1) if it is done??? >but in the hc_interrupt... it checks whether urb_state == 0... which >means it would not try another packet??? Yes, I think I understand your concern. The sh_done_list returns a -1 when it has completed the URB, in such case, the hc_interrupt would not call send another packet. But you still have to remember in the sh_schedule_trans routine, which initiated every SOF, would continue to call even after the hc_interrupt returns. The sequence is like this -->sh_schedule_trans -->> scan_urb_list --->> sh_add_packet() ->hc_interrupt ; interrupt occurred because xferdone irq. In this case, the sh_schedule_trans would be pre-empted --->sh_done_list : take care of the xferdone irq ---> sh_add_packet if urb_state >=0 .. ->hc_interrupt ; interrupt occurred because xferdone irq. --->sh_done_list : take care of the xferdone irq ---> hc_interrupt exits when urb_state = -1; --> sh_schedules continues with the next urb after all irq has handled. Pei --- This SF.NET email is sponsored by: FREE SSL Guide from Thawte are you planning your Web Server Security? Click here to get a FREE Thawte SSL guide and find the answers to all your SSL security issues. http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0026en ___ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
[linux-usb-devel] Re: SL811 USB driver interrupt handling
that means the packet will be sent during next frame instead?
can we just change the hc_interrupt to
if ( && urb_state <= 0)
{
if (urb_state == 0) add_packet
else schedule_trans
Pei Liu wrote:
>
> >
> >but i thought sh_done_list returns (urb_state = -1) if it is done???
> >but in the hc_interrupt... it checks whether urb_state == 0... which
> >means it would not try another packet???
>
> Yes, I think I understand your concern. The sh_done_list returns a -1 when
> it has completed the URB, in such case, the hc_interrupt would not call send
> another packet. But you still have to remember in the sh_schedule_trans
> routine, which initiated every SOF, would continue to call even after the
> hc_interrupt returns. The sequence is like this
>
> -->sh_schedule_trans
> -->> scan_urb_list
> --->> sh_add_packet()
>
> ->hc_interrupt ; interrupt occurred because xferdone irq. In this case, the
> sh_schedule_trans would be pre-empted
> --->sh_done_list : take care of the xferdone irq
> ---> sh_add_packet if urb_state >=0
>
> ..
>
> ->hc_interrupt ; interrupt occurred because xferdone irq.
> --->sh_done_list : take care of the xferdone irq
> ---> hc_interrupt exits when urb_state = -1;
>
> --> sh_schedules continues with the next urb after all irq has handled.
>
> Pei
---
This SF.NET email is sponsored by: FREE SSL Guide from Thawte
are you planning your Web Server Security? Click here to get a FREE
Thawte SSL guide and find the answers to all your SSL security issues.
http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0026en
___
[EMAIL PROTECTED]
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] Using drivers/usb from 2.4.21-pre3 in 2.4.19kernel
Tom Collins wrote: I replaced drivers/usb/* and include/linux/usb*.h in my 2.4.19 tree with the versions from 2.4.21-pre3. I was able to compile the kernel, but when I installed it I got the following errors when I turned on my USB 2.0 hard drive: hub.c: new USB device 00:13.2-2, assigned address 2 ehci-hcd 00:13.2: fatal error So the hardware threw up its hands because something happened that it didn't like at all. At that point it's hard to say just what, particularly since you haven't included the debug messages. The register dumps can help, but I suspect you'd need more detailed diagnostics than you'd get by default. I'd suspect something went goofy when you swapped out the USB code, unless you get the same failure on a generic 2.4.21-pre3 or 2.5.58+ kernel. pci_pool_free 00:13.2/ehci_qtd, a03ee120/3ee120 (bad dma) pci_pool_free 00:13.2/ehci_qtd, a03ee0c0/3ee0c0 (bad dma) This might indicate some corruption in the kmalloc pool (used to track pages in that qtd pool), or else suggest that the reason the hardware got unhappy is because it was somehow given bogus DMA addresses. ehci-hcd 00:13.2: stopped in_interrupt! There's a small patch that "hcd.c" needs to get, basically after an HCD dies in_interrupt() it's got to cause the cleanup to happen in a task context (keventd). Lacking that, the rest of the messages will be meaningless, since the hcd was supposed to clean up but it's been left in a "dead" state. - Dave --- This SF.NET email is sponsored by: FREE SSL Guide from Thawte are you planning your Web Server Security? Click here to get a FREE Thawte SSL guide and find the answers to all your SSL security issues. http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0026en ___ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] Re: SL811 USB driver interrupt handling
>that means the packet will be sent during next frame instead?
No, the sh_schedule_trans() got preempted when a xferdone irq occurs (Kinda
like suspended/blocked), and will continue after the irq has been handled.
(kinda like resume)
>can we just change the hc_interrupt to
>
>if ( && urb_state <= 0)
>{
> if (urb_state == 0) add_packet
> else schedule_trans
>
That is not totally correct, we can't really call sh_schedule_trans() again
in the xferdone because it would try to schedule to isochronous urb,
interrupt urb, control urb, and bulk urb again in that order. This would
violate the USB spec.
>
>Pei Liu wrote:
>>
>> >
>> >but i thought sh_done_list returns (urb_state = -1) if it is done???
>> >but in the hc_interrupt... it checks whether urb_state == 0... which
>> >means it would not try another packet???
>>
>> Yes, I think I understand your concern. The sh_done_list returns a -1
when
>> it has completed the URB, in such case, the hc_interrupt would not call
send
>> another packet. But you still have to remember in the sh_schedule_trans
>> routine, which initiated every SOF, would continue to call even after the
>> hc_interrupt returns. The sequence is like this
>>
>> -->sh_schedule_trans
>> -->> scan_urb_list
>> --->> sh_add_packet()
>>
>> ->hc_interrupt ; interrupt occurred because xferdone irq. In this case,
the
>> sh_schedule_trans would be pre-empted
>> --->sh_done_list : take care of the xferdone irq
>> ---> sh_add_packet if urb_state >=0
>>
>> ..
>>
>> ->hc_interrupt ; interrupt occurred because xferdone irq.
>> --->sh_done_list : take care of the xferdone irq
>> ---> hc_interrupt exits when urb_state = -1;
>>
>> --> sh_schedules continues with the next urb after all irq has handled.
>>
>> Pei
>
>
>---
>This SF.NET email is sponsored by: FREE SSL Guide from Thawte
>are you planning your Web Server Security? Click here to get a FREE
>Thawte SSL guide and find the answers to all your SSL security issues.
>http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0026en
>___
>[EMAIL PROTECTED]
>To unsubscribe, use the last form field at:
>https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
---
This SF.NET email is sponsored by: FREE SSL Guide from Thawte
are you planning your Web Server Security? Click here to get a FREE
Thawte SSL guide and find the answers to all your SSL security issues.
http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0026en
___
[EMAIL PROTECTED]
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] Re: [PATCH] USB changes for 2.5.58
Matthew Dharm wrote: In a separate discussion with Mike, he mentioned that you can't scsi_remove_device() unless there are no pending commands. How the hell is an LLD supposed to assure that!?!? ABORT TASK/ABORT TASK SET. For a year now I've been trying to get something of the sort scsi_cancel_task/set(). It will send the aforementioned task management functions (TMF) (depending on the abilities of the device) to the device server (LLD). After which the initiator should NOT get a response to any already queued commands in the LLD. LLDD should be smarter if they do their own queuing and snoop this and act accordingly. After sending such a TMF to the LLD, one can clean all ULP queues (scsi, block, etc), knowing that there'd be no response to a command (which is now gone), and then actually remove the device. In my own drivers/mini-scsi-core, I do something like this: 1. mark the device off (stop queuing anything to it, return error or whatever), 2. send the aforementioned TMF, 2a) wait for current transfers to complete 3. cancel ULP queues. Now the device is cleanly off, and one can remove it/restart it/whatever. Note that this method is cleanly reversible (1. turn on, 2. LUN/device RESET (scsi layer), 3. start queuing (block layer)). (Note as well that I make distinction between LLD and LLDD, where the last D stands for ``driver'' in LLDD.) The way this should work is that the LLD calls scsi_remove_device(), and that cuts off the flow of commands. The LLD can promise to error-out any pending commands in the device command queue. I take it you mean that the transport will tell the LLDD that the device is gone and it (LLDD) call the one above, SCSI Core to remove the device. Hmm, more thinking needs to be done here, as shouldn't this be handled by hotplugging? I.e. Targets do not *initiate* events. The transport can notify that the device is gone, but an ULP entity will call scsi_remove_device() not the other way around. -- Luben --- This SF.NET email is sponsored by: FREE SSL Guide from Thawte are you planning your Web Server Security? Click here to get a FREE Thawte SSL guide and find the answers to all your SSL security issues. http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0026en ___ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] TODO-List
Oliver Neukum wrote:
Hi,
I was just looking at the TODO list and it seemed to me that a list somewhat
more specific and focused on usbcore might be useful.
I think the real issue is who will fix the various bugs and issues that
turn up, but having lists can help focus that energy.
So here's the list of things related to the core I remember so we can look
at the issues and see which need attention before 2.6.0
- reseting during probe will deadlock
- reseting through usbfs will not reprobe
- usb_reset_device() and usb_set_configuration() race with probe()
- bandwidth checking is broken
Removals? Additions? Comments?
Yes, I'll be glad to see more of the usbcore cleanups happen.
Here are a random bunch of things
- Someone just emailed me for help on that classic, and still
unresolved, issue of associating a device from 'lsusb' (etc)
with the right /dev/... printer node. This is largely an
issue usbcore (or the driver model) should solve; it's not
specific to printers (or scanners, or any other driver).
- Your set_configuration updates should happen -- do you have a
current version of that patch?
- Now that the driver model core supports explicit bind/unbind of
drivers to devices, we should get rid of usb_interface->driver
since usb_interface->dev.driver does that job. (This is a case
of me needing to update a patch.)
- usb_set_interface() signature: should take an interface and an
altsetting, not a device and two magic numbers.
- We should have some notion of device state so that we can make
sure that once disconnect processing begins, urb submits fail.
- I still want to see that nasty synchronization code used by
usb_{control,bulk}_msg() get replaced. (I've got a patch
to dust off, but the real issue is that 'struct completion'
should have iowait-and-timeout primitives too...)
- More work can/should be done to merge the "usb_bus" and "hcd"
layers.
- In usb_device we should maintain an array of the current
endpoint descriptors, replacing the maxpacket arrays.
That's hardly a complete list of course.
- Dave
---
This SF.NET email is sponsored by: FREE SSL Guide from Thawte
are you planning your Web Server Security? Click here to get a FREE
Thawte SSL guide and find the answers to all your SSL security issues.
http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0026en
___
[EMAIL PROTECTED]
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] TODO-List
Am Montag, 20. Januar 2003 19:21 schrieb David Brownell:
> Oliver Neukum wrote:
> > Hi,
> >
> > I was just looking at the TODO list and it seemed to me that a list
> > somewhat more specific and focused on usbcore might be useful.
>
> I think the real issue is who will fix the various bugs and issues that
> turn up, but having lists can help focus that energy.
Yes, but bugs in usbcore are most important as they affect everything
in USB.
> > So here's the list of things related to the core I remember so we can
> > look at the issues and see which need attention before 2.6.0
> >
> > - reseting during probe will deadlock
> > - reseting through usbfs will not reprobe
> > - usb_reset_device() and usb_set_configuration() race with probe()
> > - bandwidth checking is broken
> >
> > Removals? Additions? Comments?
>
> Yes, I'll be glad to see more of the usbcore cleanups happen.
> Here are a random bunch of things
>
> - Someone just emailed me for help on that classic, and still
> unresolved, issue of associating a device from 'lsusb' (etc)
> with the right /dev/... printer node. This is largely an
> issue usbcore (or the driver model) should solve; it's not
> specific to printers (or scanners, or any other driver).
Not terribly specific to USB. That's why driverfs was invented,
wasn't it?
> - Your set_configuration updates should happen -- do you have a
> current version of that patch?
Still working on it. The old version was racy.
> - Now that the driver model core supports explicit bind/unbind of
> drivers to devices, we should get rid of usb_interface->driver
> since usb_interface->dev.driver does that job. (This is a case
> of me needing to update a patch.)
>
> - usb_set_interface() signature: should take an interface and an
> altsetting, not a device and two magic numbers.
>
> - We should have some notion of device state so that we can make
> sure that once disconnect processing begins, urb submits fail.
>
> - I still want to see that nasty synchronization code used by
> usb_{control,bulk}_msg() get replaced. (I've got a patch
> to dust off, but the real issue is that 'struct completion'
> should have iowait-and-timeout primitives too...)
>
> - More work can/should be done to merge the "usb_bus" and "hcd"
> layers.
>
> - In usb_device we should maintain an array of the current
> endpoint descriptors, replacing the maxpacket arrays.
>
> That's hardly a complete list of course.
And how much is 2.7? It's a very long list :-(.
I am afraid we'll have to set priorities.
Regards
Oliver
---
This SF.NET email is sponsored by: FREE SSL Guide from Thawte
are you planning your Web Server Security? Click here to get a FREE
Thawte SSL guide and find the answers to all your SSL security issues.
http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0026en
___
[EMAIL PROTECTED]
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] Re: Discussing the URB lifecycle, again
Alan Stern wrote: Okay, let's forget about bandwidth reservation for the time being. Sure, particularly since I didn't have a chance to investigate that too deeply ... there did seem to be some logic intending to recycle allocations in uhci-hcd, maybe it's reallly correct. And I suspect other issues with the uhci code should be higher priority anyway. As for the other posts on this thread, I hope to have time to read them later. Adding more spinlocks is (more often than not) a Bad Thing, deadlock-prone. It's not clear to me why urb->lock wouldn't suffice, and there's some other wierdness being proposed. I agree that using a spinlock to solve our problem is an unorthodox approach. Since that thread had so much traffic, digesting it still hasn't happened. (Plus it's got to be lower priority than some other stuff.) - Dave --- This SF.NET email is sponsored by: FREE SSL Guide from Thawte are you planning your Web Server Security? Click here to get a FREE Thawte SSL guide and find the answers to all your SSL security issues. http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0026en ___ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
[linux-usb-devel] Help for usr modem 5633
Can anyone help me for using under linux the us robotics modem 5633 (the 5605 is the old model) Thanks Antonio Bernabei --- This SF.NET email is sponsored by: FREE SSL Guide from Thawte are you planning your Web Server Security? Click here to get a FREE Thawte SSL guide and find the answers to all your SSL security issues. http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0026en ___ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] Re: SL811 USB driver interrupt handling
> >Do you know if it is ACCEPTABLE to turn of SOF interrupt when there >is nothing to send It is possible, but the driver needs a different method to keep track of the frame number. I don't have the hardware specification with me, I think hardware keep tracks the frame number also, all you have to do is read a frame number register. But you have to remember there are still isochronous and interrupt endpoints, those periodic urbs needs to be send in a certain interval. so there might be more than a handful of changes needed to the driver to make this work. >a. would it stop SOF generation towards the function/device? no.. just disable the SOF interrupt in the interrupt enable register. >b. can the driver turns on SOF before having something to send??? >and turn if off after all ack/tarnsactions are completed > Yes.. again it is in the interrupt enable register. pei >this is to prevent loading down the cpu for those 1ms interrupt??? > >thanks > > >Pei Liu wrote: >> >> > >> >i am not sure if i understand this driver in depth the question >> >i have is who can multiple "packets" be sent within the same frame? >> >> Yes, you can send multiple USB transactions within the same frame. >> >> > >> >the interrupt service routine (hc_interrupt) seems to allow only ONE >> >packet per frame? is this correct??? >> > >> >when xferdone is handled... the sh_done_list is called... if the >> >packet is done... it would return a (-1)... and the interrupt service >> >routine would not start another transaction (sh_schedule_transaction) >> >if the return value is not 0 that means no packet will go out until >> >next frame? >> > >> >> When USB Done interrupt occurred, it handles the interrupt by calling >> sh_done_list() function. The sh_done_list() returns a code that determines >> if the current USB transactions has completed. If it has not completed, it >> would call the sh_add_packet() to complete current USB transaction.If it >> has completed, then it would call the sh_schedule_trans() routine which will >> schedule the next USB transactions. >> >> Pei > > >--- >This SF.NET email is sponsored by: FREE SSL Guide from Thawte >are you planning your Web Server Security? Click here to get a FREE >Thawte SSL guide and find the answers to all your SSL security issues. >http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0026en >___ >[EMAIL PROTECTED] >To unsubscribe, use the last form field at: >https://lists.sourceforge.net/lists/listinfo/linux-usb-devel --- This SF.NET email is sponsored by: FREE SSL Guide from Thawte are you planning your Web Server Security? Click here to get a FREE Thawte SSL guide and find the answers to all your SSL security issues. http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0026en ___ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] Re: SL811 USB driver interrupt handling
Pei Do you know if INSERT/REMOVE interrupt works for SL811H??? the driver seems to have that interrupt enabled but when the cable is removed.. nothing happen... is this interrupt for exactly what i thought i meant? (removing/insertion of cable)??? thanks --- This SF.NET email is sponsored by: FREE SSL Guide from Thawte are you planning your Web Server Security? Click here to get a FREE Thawte SSL guide and find the answers to all your SSL security issues. http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0026en ___ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
[linux-usb-devel] [PATCH 2.4.21-pre3]: scanner.h, scanner.c: New vendor/product ids
Hi,
This patch adds vendor/product ids for Artec, Canon, Compaq, Epson,
HP, and Microtek scanners. Further more, the device list was cleaned
up, sorted and duplicated entries have been removed.
Bye,
Henning
diff -u -r linux-2.4.21-pre3.syslog/drivers/usb/scanner.c
linux-2.4.21-pre3.newids4/drivers/usb/scanner.c
--- linux-2.4.21-pre3.syslog/drivers/usb/scanner.c 2003-01-17 22:54:50.0
+0100
+++ linux-2.4.21-pre3.newids4/drivers/usb/scanner.c 2003-01-20 20:47:33.0
++0100
@@ -334,7 +334,10 @@
* <[EMAIL PROTECTED]>.
*
* 0.4.10 01/07/2003
- *- Added vendor/product ids for Visioneer scanners.
+ *- Added vendor/product ids for Artec, Canon, Compaq, Epson, HP, Microtek
+ * and Visioneer scanners. Thanks to William Lam <[EMAIL PROTECTED]>,
+ * Till Kamppeter <[EMAIL PROTECTED]> and others for all the ids.
+ *- Cleaned up list of vendor/product ids.
*- Print information about user-supplied ids only once at startup instead
* of everytime any USB device is plugged in.
*- Removed PV8630 ioctls. Use the standard ioctls instead.
diff -u -r linux-2.4.21-pre3.syslog/drivers/usb/scanner.h
linux-2.4.21-pre3.newids4/drivers/usb/scanner.h
--- linux-2.4.21-pre3.syslog/drivers/usb/scanner.h 2003-01-17 23:39:38.0
+0100
+++ linux-2.4.21-pre3.newids4/drivers/usb/scanner.h 2003-01-20 21:07:15.0
++0100
@@ -71,79 +71,90 @@
static struct usb_device_id scanner_device_ids [] = {
/* Acer (now Benq) */
- { USB_DEVICE(0x04a5, 0x2060) }, /* 620U & 640U (!)*/
- { USB_DEVICE(0x04a5, 0x2040) }, /* 620U (!) */
- { USB_DEVICE(0x04a5, 0x20c0) }, /* 1240UT, 1240U */
- { USB_DEVICE(0x04a5, 0x2022) }, /* 340U */
{ USB_DEVICE(0x04a5, 0x1a20) }, /* Unknown - Oliver Schwartz */
{ USB_DEVICE(0x04a5, 0x1a2a) }, /* Another 620U */
+ { USB_DEVICE(0x04a5, 0x2022) }, /* 340U */
+ { USB_DEVICE(0x04a5, 0x2040) }, /* 620U (!) */
+ { USB_DEVICE(0x04a5, 0x2060) }, /* 620U & 640U (!)*/
{ USB_DEVICE(0x04a5, 0x207e) }, /* 640BU */
+ { USB_DEVICE(0x04a5, 0x20b0) }, /* Benq 4300 */
{ USB_DEVICE(0x04a5, 0x20be) }, /* Unknown - Oliver Schwartz */
+ { USB_DEVICE(0x04a5, 0x20c0) }, /* 1240UT, 1240U */
{ USB_DEVICE(0x04a5, 0x20de) }, /* S2W 3300U */
- { USB_DEVICE(0x04a5, 0x20b0) }, /* Benq 4300 */
- { USB_DEVICE(0x04a5, 0x20fe) }, /* Benq 5300 */
{ USB_DEVICE(0x04a5, 0x20fc) }, /* Benq 5000 */
+ { USB_DEVICE(0x04a5, 0x20fe) }, /* Benq 5300 */
/* Agfa */
{ USB_DEVICE(0x06bd, 0x0001) }, /* SnapScan 1212U */
{ USB_DEVICE(0x06bd, 0x0002) }, /* SnapScan 1236U */
- { USB_DEVICE(0x06bd, 0x2061) }, /* Another SnapScan 1212U (?)*/
{ USB_DEVICE(0x06bd, 0x0100) }, /* SnapScan Touch */
+ { USB_DEVICE(0x06bd, 0x2061) }, /* Another SnapScan 1212U (?)*/
+ { USB_DEVICE(0x06bd, 0x208d) }, /* Snapscan e40 */
+ { USB_DEVICE(0x06bd, 0x208f) }, /* SnapScan e50*/
{ USB_DEVICE(0x06bd, 0x2091) }, /* SnapScan e20 */
+ { USB_DEVICE(0x06bd, 0x2093) }, /* SnapScan e10*/
{ USB_DEVICE(0x06bd, 0x2095) }, /* SnapScan e25 */
{ USB_DEVICE(0x06bd, 0x2097) }, /* SnapScan e26 */
- { USB_DEVICE(0x06bd, 0x208d) }, /* Snapscan e40 */
- { USB_DEVICE(0x06bd, 0x2093) }, /* SnapScan e10*/
- { USB_DEVICE(0x06bd, 0x20ff) }, /* SnapScan e42*/
- { USB_DEVICE(0x06bd, 0x208f) }, /* SnapScan e50*/
{ USB_DEVICE(0x06bd, 0x20fd) }, /* SnapScan e52*/
+ { USB_DEVICE(0x06bd, 0x20ff) }, /* SnapScan e42*/
+ /* Artec */
+ { USB_DEVICE(0x05d8, 0x4001) }, /* Ultima 2000 */
+ { USB_DEVICE(0x05d8, 0x4002) }, /* Ultima 2000 (GT6801 based) */
/* Benq: see Acer */
/* Canon */
- { USB_DEVICE(0x04a9, 0x2201) }, /* FB320U */
- { USB_DEVICE(0x04a9, 0x2205) }, /* FB1210U */
+ { USB_DEVICE(0x04a9, 0x2201) }, /* CanoScan FB320U */
{ USB_DEVICE(0x04a9, 0x2202) }, /* CanoScan FB620U */
{ USB_DEVICE(0x04a9, 0x2204) }, /* CanoScan FB630U/FB636U */
+ { USB_DEVICE(0x04a9, 0x2205) }, /* CanoScan FB1210U */
{ USB_DEVICE(0x04a9, 0x2206) }, /* CanoScan N650U/N656U */
{ USB_DEVICE(0x04a9, 0x2207) }, /* CanoScan N1220U */
{ USB_DEVICE(0x04a9, 0x2208) }, /* CanoScan D660U */
- { USB_DEVICE(0x04a9, 0x220b) }, /* D646U */
+ { USB_DEVICE(0x04a9, 0x220b) }, /* CanoScan D646U */
+ { USB_DEVICE(0x04a9, 0x220c) }, /* CanoScan D1250U2 */
{ USB_DEVICE(0x04a9, 0x220d) }, /* CanoScan N670U/N676U/LIDE 20 */
{ USB_DEVICE(0x04a9, 0x220e) }, /* CanoScan N1240U/LIDE 30 */
{ USB_DEVICE(0x04a9, 0x3042) }, /* FS4000US */
/* Colorado -- See Primax/Colorado below */
+ /* Compaq */
+ { USB_DEVICE(0x049f, 0x0021) }, /* S200 */
/* Epson -- See Seiko/Epson below */
/* Genius */
- { USB_DEVICE(0x0458, 0x2001) }, /* ColorPage-Vivid Pro */
+
[linux-usb-devel] [PATCH 2.5.59] scanner.h, scanner.c: New vendor/product ids
Hi,
This patch adds vendor/product ids for Artec, Canon, Compaq, Epson,
HP, and Microtek scanners. Further more, the device list was cleaned
up, sorted and duplicated entries have been removed.
Bye,
Henning
diff -u -r linux-2.5.59-syslog/drivers/usb/image/scanner.c
linux-2.5.59-newids4/drivers/usb/image/scanner.c
--- linux-2.5.59-syslog/drivers/usb/image/scanner.c 2003-01-18 00:33:54.0
+0100
+++ linux-2.5.59-newids4/drivers/usb/image/scanner.c2003-01-20 21:15:24.0
++0100
@@ -333,7 +333,10 @@
* <[EMAIL PROTECTED]>.
*
* 0.4.10 01/07/2003
- *- Added vendor/product ids for Visioneer scanners.
+ *- Added vendor/product ids for Artec, Canon, Compaq, Epson, HP, Microtek
+ * and Visioneer scanners. Thanks to William Lam <[EMAIL PROTECTED]>,
+ * Till Kamppeter <[EMAIL PROTECTED]> and others for all the ids.
+ *- Cleaned up list of vendor/product ids.
*- Print information about user-supplied ids only once at startup instead
* of everytime any USB device is plugged in.
*- Removed PV8630 ioctls. Use the standard ioctls instead.
diff -u -r linux-2.5.59-syslog/drivers/usb/image/scanner.h
linux-2.5.59-newids4/drivers/usb/image/scanner.h
--- linux-2.5.59-syslog/drivers/usb/image/scanner.h 2003-01-18 00:21:34.0
+0100
+++ linux-2.5.59-newids4/drivers/usb/image/scanner.h2003-01-20 21:05:55.0
++0100
@@ -71,79 +71,90 @@
static struct usb_device_id scanner_device_ids [] = {
/* Acer (now Benq) */
- { USB_DEVICE(0x04a5, 0x2060) }, /* 620U & 640U (!)*/
- { USB_DEVICE(0x04a5, 0x2040) }, /* 620U (!) */
- { USB_DEVICE(0x04a5, 0x20c0) }, /* 1240UT, 1240U */
- { USB_DEVICE(0x04a5, 0x2022) }, /* 340U */
{ USB_DEVICE(0x04a5, 0x1a20) }, /* Unknown - Oliver Schwartz */
{ USB_DEVICE(0x04a5, 0x1a2a) }, /* Another 620U */
+ { USB_DEVICE(0x04a5, 0x2022) }, /* 340U */
+ { USB_DEVICE(0x04a5, 0x2040) }, /* 620U (!) */
+ { USB_DEVICE(0x04a5, 0x2060) }, /* 620U & 640U (!)*/
{ USB_DEVICE(0x04a5, 0x207e) }, /* 640BU */
+ { USB_DEVICE(0x04a5, 0x20b0) }, /* Benq 4300 */
{ USB_DEVICE(0x04a5, 0x20be) }, /* Unknown - Oliver Schwartz */
+ { USB_DEVICE(0x04a5, 0x20c0) }, /* 1240UT, 1240U */
{ USB_DEVICE(0x04a5, 0x20de) }, /* S2W 3300U */
- { USB_DEVICE(0x04a5, 0x20b0) }, /* Benq 4300 */
- { USB_DEVICE(0x04a5, 0x20fe) }, /* Benq 5300 */
{ USB_DEVICE(0x04a5, 0x20fc) }, /* Benq 5000 */
+ { USB_DEVICE(0x04a5, 0x20fe) }, /* Benq 5300 */
/* Agfa */
{ USB_DEVICE(0x06bd, 0x0001) }, /* SnapScan 1212U */
{ USB_DEVICE(0x06bd, 0x0002) }, /* SnapScan 1236U */
- { USB_DEVICE(0x06bd, 0x2061) }, /* Another SnapScan 1212U (?)*/
{ USB_DEVICE(0x06bd, 0x0100) }, /* SnapScan Touch */
+ { USB_DEVICE(0x06bd, 0x2061) }, /* Another SnapScan 1212U (?)*/
+ { USB_DEVICE(0x06bd, 0x208d) }, /* Snapscan e40 */
+ { USB_DEVICE(0x06bd, 0x208f) }, /* SnapScan e50*/
{ USB_DEVICE(0x06bd, 0x2091) }, /* SnapScan e20 */
+ { USB_DEVICE(0x06bd, 0x2093) }, /* SnapScan e10*/
{ USB_DEVICE(0x06bd, 0x2095) }, /* SnapScan e25 */
{ USB_DEVICE(0x06bd, 0x2097) }, /* SnapScan e26 */
- { USB_DEVICE(0x06bd, 0x208d) }, /* Snapscan e40 */
- { USB_DEVICE(0x06bd, 0x2093) }, /* SnapScan e10*/
- { USB_DEVICE(0x06bd, 0x20ff) }, /* SnapScan e42*/
- { USB_DEVICE(0x06bd, 0x208f) }, /* SnapScan e50*/
{ USB_DEVICE(0x06bd, 0x20fd) }, /* SnapScan e52*/
+ { USB_DEVICE(0x06bd, 0x20ff) }, /* SnapScan e42*/
+ /* Artec */
+ { USB_DEVICE(0x05d8, 0x4001) }, /* Ultima 2000 */
+ { USB_DEVICE(0x05d8, 0x4002) }, /* Ultima 2000 (GT6801 based) */
/* Benq: see Acer */
/* Canon */
- { USB_DEVICE(0x04a9, 0x2201) }, /* FB320U */
- { USB_DEVICE(0x04a9, 0x2205) }, /* FB1210U */
+ { USB_DEVICE(0x04a9, 0x2201) }, /* CanoScan FB320U */
{ USB_DEVICE(0x04a9, 0x2202) }, /* CanoScan FB620U */
{ USB_DEVICE(0x04a9, 0x2204) }, /* CanoScan FB630U/FB636U */
+ { USB_DEVICE(0x04a9, 0x2205) }, /* CanoScan FB1210U */
{ USB_DEVICE(0x04a9, 0x2206) }, /* CanoScan N650U/N656U */
{ USB_DEVICE(0x04a9, 0x2207) }, /* CanoScan N1220U */
{ USB_DEVICE(0x04a9, 0x2208) }, /* CanoScan D660U */
- { USB_DEVICE(0x04a9, 0x220b) }, /* D646U */
+ { USB_DEVICE(0x04a9, 0x220b) }, /* CanoScan D646U */
+ { USB_DEVICE(0x04a9, 0x220c) }, /* CanoScan D1250U2 */
{ USB_DEVICE(0x04a9, 0x220d) }, /* CanoScan N670U/N676U/LIDE 20 */
{ USB_DEVICE(0x04a9, 0x220e) }, /* CanoScan N1240U/LIDE 30 */
{ USB_DEVICE(0x04a9, 0x3042) }, /* FS4000US */
/* Colorado -- See Primax/Colorado below */
+ /* Compaq */
+ { USB_DEVICE(0x049f, 0x0021) }, /* S200 */
/* Epson -- See Seiko/Epson below */
/* Genius */
- { USB_DEVICE(0x0458, 0x2001) }, /* ColorPage-Vivid Pro */
[linux-usb-devel] possibility of task getting stuck in sg handling
Hi,
this patch fixes a bug where submitting an sg request could get a task
stuck in state D if the first submission fails.
Regards
Oliver
You can import this changeset into BK by piping this whole message to:
'| bk receive [path to repository]' or apply the patch as usual.
===
[EMAIL PROTECTED], 2003-01-20 21:32:53+01:00, [EMAIL PROTECTED]
- fix task stuck in state D in usb_sg_wait()
message.c | 14 +++---
1 files changed, 11 insertions(+), 3 deletions(-)
diff -Nru a/drivers/usb/core/message.c b/drivers/usb/core/message.c
--- a/drivers/usb/core/message.cMon Jan 20 21:36:57 2003
+++ b/drivers/usb/core/message.cMon Jan 20 21:36:57 2003
@@ -412,8 +412,10 @@
*/
void usb_sg_wait (struct usb_sg_request *io)
{
- int i;
+ int i,retries;
unsigned long flags;
+
+ retries = 0;
/* queue the urbs. */
spin_lock_irqsave (&io->lock, flags);
@@ -433,10 +435,14 @@
case -ENOMEM:
retval = 0;
i--;
+ retries++;
+ if (retries > 5) {
+ usb_sg_cancel(io);
+ goto give_up_and_exit;
+ }
// FIXME: should it usb_sg_cancel() on INTERRUPT?
// how about imposing a backoff?
- set_current_state (TASK_UNINTERRUPTIBLE);
- schedule ();
+ yield();
break;
/* no error? continue immediately.
@@ -447,6 +453,7 @@
*/
case 0:
cpu_relax ();
+ retries = 0;
break;
/* fail any uncompleted urbs */
@@ -467,6 +474,7 @@
*/
wait_for_completion (&io->complete);
+give_up_and_exit:
sg_clean (io);
}
===
This BitKeeper patch contains the following changesets:
1.1286
## Wrapped with gzip_uu ##
begin 664 bkpatch5004
M'XL(`.I=+#X``\54;6O;,!#^+/V*@WY)R!+KQ9(=EY1L[=C&!@L9_1P<6W&$
M$ZO8\IHR[[]/2M*6E2UEW6#&X--SI[OG[AY\!M>-JA-D-OJKJO$9O#>-=4=5
MF4J-UF:K-KIJ=R-3%\XY-\8Y`P\'AQO!LAS:6JDF:)LE$]@%S5*;K<'YF@31
M$7]`[-V-2M#\[;OK3Z_G&$\F<+E.JT)]418F$[PLIWFK-J.R-NG:U^L>W!TC
MA%+*!.%"4M&QF/.PHY(LQQEGCXAP_&)"7X`HI:%=,#]\QL
MN[SV'>_W&F2F5L%6-4U:J%'FFV%$$DY%&%+942+#<;>2(N1Q&,D\IC'ARU,C
M>R:YVP]S%3@3O!."$[%7R^_O>/G\8_8GQ?0L>ZY`($1NH<'@W-_TBOHW0=>@.C#-X^B8UM96F5JT].FOP]&A;$&"M?,
MHKU9I%6^4#MM]Z[OCA>/76%7:.QY(72GU2;O]7WM\`@]H20]_#1=\OA'S-8J
4*YMV.\E3+J(HRO$/(=KV17T%
`
end
---
This SF.NET email is sponsored by: FREE SSL Guide from Thawte
are you planning your Web Server Security? Click here to get a FREE
Thawte SSL guide and find the answers to all your SSL security issues.
http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0026en
___
[EMAIL PROTECTED]
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] Re: SL811 USB driver interrupt handling
>Do you know if INSERT/REMOVE interrupt works for SL811H??? the driver >seems to have that interrupt enabled but when the cable is removed.. >nothing happen... is this interrupt for exactly what i thought i meant? >(removing/insertion of cable)??? > The INSERT/REMOVE irq works for the SL811HS. When cable disconnect or connected, it will cause the Insert/Remove irq. Then the logic will check the D+/D- line to determine the connected or disconnect, and also checks for the speed of the device. Pei --- This SF.NET email is sponsored by: FREE SSL Guide from Thawte are you planning your Web Server Security? Click here to get a FREE Thawte SSL guide and find the answers to all your SSL security issues. http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0026en ___ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
[linux-usb-devel] 2.4.20 Oops on close of Keyspan ttyUSB
I've recently been trying 2.4.20 and the keyspan driver. I've been using the keyspans fine with 2.4.18 and 2.4.19 (in fact we have 100s of them ;-) but trying them with 2.4.20 I get the Oops below quite a lot. It happens on close of the port but I think there must have to be data flowing through the port at the moment of close to trigger it. Our bit error rate test program with a looped back connector triggers it just about every time when you ctrl-c the program. Any help gratefully received! (I captured the below with serial console so it should be accurate!) ksymoops 2.4.6 on i686 2.4.20-s1. Options used -V (default) -k /proc/ksyms (default) -l /proc/modules (default) -o /lib/modules/2.4.20-s1/ (default) -m /boot/System.map-2.4.20-s1 (default) Warning: You did not tell me where to find symbol information. I will assume that the log matches the kernel and modules that are running right now and I'll use the default options above for symbol resolution. If the current kernel and/or modules do not match the log, you can get more accurate output by telling me the kernel version and where to find map, modules, ksyms etc. ksymoops -h explains the options. Warning (expand_objects): object /lib/modules/2.4.20-s1/kernel/drivers/ide/ide-disk.o for module ide-disk has changed since load Warning (expand_objects): object /lib/modules/2.4.20-s1/kernel/drivers/ide/ide-probe-mod.o for module ide-probe-mod has changed since load Warning (expand_objects): object /lib/modules/2.4.20-s1/kernel/drivers/ide/ide-mod.o for module ide-mod has changed since load Warning (expand_objects): object /lib/modules/2.4.20-s1/kernel/fs/ext3/ext3.o for module ext3 has changed since load Warning (expand_objects): object /lib/modules/2.4.20-s1/kernel/fs/jbd/jbd.o for module jbd has changed since load Warning (expand_objects): object /lib/modules/2.4.20-s1/kernel/net/unix/unix.o for module unix has changed since load cpu: 0, clocks: 1002339, slice: 501169 ac97_codec: AC97 codec, id: TRA3(TriTech TR28023) kernel BUG at sched.c:564! invalid operand: CPU:0 EIP:0010:[]Not tainted Using defaults from ksymoops -t elf32-i386 -a i386 EFLAGS: 00010282 eax: 0018 ebx: f789d078 ecx: f3332000 edx: f36b8280 esi: fccc edi: f3332000 ebp: fcb8 esp: fc94 ds: 0018 es: 0018 ss: 0018 Process cambert (pid: 819, stackpage=f000) Stack: c01db67e f789d078 fccc f3332000 c028d3e0 0086 f3332000 f789d078 f369d168 c010754d f789d01c f789d000 ffea 0001 f3332000 f789d084 f789d084 c0107698 f789d078 f789d000 f89c9241 006d Call Trace:[] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] Code: 0f 0b 34 02 76 b6 1d c0 83 c4 04 8b 4d f4 c1 e1 05 81 c1 20 >>EIP; c0114e19<= >>ebx; f789d078 <_end+37610b28/38580b10> >>ecx; f3332000 <_end+330a5ab0/38580b10> >>edx; f36b8280 <_end+3342bd30/38580b10> >>esi; fccc <_end+330a777c/38580b10> >>edi; f3332000 <_end+330a5ab0/38580b10> >>ebp; fcb8 <_end+330a7768/38580b10> >>esp; fc94 <_end+330a7744/38580b10> Trace; c010754d <__down+55/9c> Trace; c0107698 <__down_failed+8/c> Trace; f89c9241 <[usbserial].text.lock.usbserial+41/df> Trace; c016281c Trace; c0162b8a Trace; c016331f Trace; c017e466 Trace; f88ed7b5 <[usb-uhci]delete_desc+19/20> Trace; f88ed958 <[usb-uhci]delete_qh+58/64> Trace; c01620df Trace; c011b46c <__run_task_queue+50/5c> Trace; c011e122 Trace; c011b3b2 Trace; c011b2f6 Trace; c011b11a Trace; c0109bb2 Trace; f89c0018 <[tulip]tulip_media_cap+718/113f> Trace; c01cc5f6 <__rdtsc_delay+16/1c> Trace; c01cc637 <__delay+13/28> Trace; c01cc688 <__const_udelay+1c/24> Trace; f89ce27a <[keyspan]keyspan_close+ae/158> Trace; c01615b0 Trace; f89c74b4 <[usbserial]__serial_close+4c/7c> Trace; f89c7574 <[usbserial]serial_close+90/a4> Trace; c0160e70 Trace; f89c7ab3 <[usbserial]serial_ioctl+cf/f4> Trace; c016149e Trace; c0134204 Trace; c01332b5 Trace; c0133303 Trace; c01086d3 Code; c0114e19 <_EIP>: Code; c0114e19<= 0: 0f 0b ud2a <= Code; c0114e1b 2: 34 02 xor$0x2,%al Code; c0114e1d 4: 76 b6 jbeffbc <_EIP+0xffbc> c0114dd5 Code; c0114e1f 6: 1d c0 83 c4 04sbb$0x4c483c0,%eax Code; c0114e24 b: 8b 4d f4 mov0xfff4(%ebp),%ecx Code; c0114e27 e: c1 e1 05 shl$0x5,%ecx Code; c0114e2a 11: 81 c1 20 00 00 00 add$0x20,%ecx <0>Kernel panic: Aiee, killing interrupt handler! 7 warnings issued. Results may not be reliable. -- Nick Craig-Wood [EMAIL PROTECTED] --- This SF.NET email is sponsored by: FREE SSL Guide from Thawte are you planning your Web Server Security? Click here to get a FRE
[linux-usb-devel] Re: possibility of task getting stuck in sg handling
Oliver Neukum wrote: this patch fixes a bug where submitting an sg request could get a task stuck in state D if the first submission fails. Did you actually observe that? I strongly suspect not. Using yield() instead of that schedule() bit should be OK (is that what you're saying would get "stuck"?), but the rest isn't. The patch is problematic, since it basically prevents submission of large scatterlists from working at all in cases where resources are very tight. It's placing an arbitrary and *very small* limit on how long it tries to recover from "can't proceed just now, try again later" types of faults. If there's to be a way to stop retrying, it should NOT be because of hitting some arbitrary limit, easily reached on busy systems. I could understand allowing the task to be interrupted (maybe) since then the policy is clearly in the hands of someone with appropriate knowledge. Greg, please do _not_ merge this when you're back on-line. - Dave --- This SF.NET email is sponsored by: FREE SSL Guide from Thawte are you planning your Web Server Security? Click here to get a FREE Thawte SSL guide and find the answers to all your SSL security issues. http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0026en ___ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
[linux-usb-devel] [PATCH] small uhci bug, 2.4.20
I noticed that if you modprobe uhci but have no such hardware (it was
an alpha, with ohci, and I was tired) the module fails to load,
obviously, but it leaves a proc file behind, /proc/driver/uhci.
The attached patch should fix that, it seemed simple enough. It's not
tested beyond the fact that it compiles, but I have a good feeling about
it.
The patch is against 2.4.20.
/August.
--
Wrong on most accounts. const Foo *foo; and Foo const *foo; mean the same: foo
being a pointer to const Foo. const Foo const *foo; would mean the same but is
illegal (double const). You are confusing this with Foo * const foo; and const
Foo * const foo; respectively. -David Kastrup, comp.os.linux.development.system
--- drivers/usb/uhci.c 2002-11-29 00:53:15.0 +0100
+++ drivers/usb/uhci-mod.c 2003-01-20 22:55:44.0 +0100
@@ -3136,7 +3136,7 @@
up_failed:
#ifdef CONFIG_PROC_FS
- remove_proc_entry("uhci", 0);
+ remove_proc_entry("driver/uhci", 0);
proc_failed:
#endif
@@ -3156,7 +3156,7 @@
printk(KERN_INFO "uhci: not all urb_priv's were freed\n");
#ifdef CONFIG_PROC_FS
- remove_proc_entry("uhci", 0);
+ remove_proc_entry("driver/uhci", 0);
#endif
if (errbuf)
Re: [linux-usb-devel] Re: [PATCH] USB changes for 2.5.58
> I take it you mean that the transport will tell the LLDD that the device > is gone and it (LLDD) call the one above, SCSI Core to remove the device. > > Hmm, more thinking needs to be done here, as shouldn't this be handled > by hotplugging? I.e. Targets do not *initiate* events. > > The transport can notify that the device is gone, but an ULP entity will > call scsi_remove_device() not the other way around. NO! This is an insanely complicated scheme. We have no notification beforehand. User yanks out cable. That's it. No preperation at all. We as the writers of device drivers need a way to get rid of the device as we are notified of the physical disconnect. It is not our job to maintain devices in an undead state. And a scheme that goes subsystem driver -> hotplugging -> script finding corresponding devices -> script doing proc magic -> scsi layer notifying low level driver is _not_ sensible. It triples the amount of complexity. We need a simple scheme like 1. block further requests 2. kill old requests 3. remove device Regards Oliver --- This SF.NET email is sponsored by: FREE SSL Guide from Thawte are you planning your Web Server Security? Click here to get a FREE Thawte SSL guide and find the answers to all your SSL security issues. http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0026en ___ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] Re: [PATCH] USB changes for 2.5.58
Oliver Neukum wrote: I take it you mean that the transport will tell the LLDD that the device is gone and it (LLDD) call the one above, SCSI Core to remove the device. Hmm, more thinking needs to be done here, as shouldn't this be handled by hotplugging? I.e. Targets do not *initiate* events. The transport can notify that the device is gone, but an ULP entity will call scsi_remove_device() not the other way around. NO! We're probably talking about two different things. This is an insanely complicated scheme. We have no notification beforehand. User yanks out cable. That's it. No preperation at all. So now you have two possibilities: a) the transport supports this event notification, b) the transport doesn't support this event notification. Let me just elaborate a bit more here: since the transport/LLDD would know that the device has just disappeared (a)), it *will* return error in the due time when someone is trying to use it (and this is the same error as if there had never been such a device). But a removal of a device would probably have to start in top-down approach, to free/release/etc resources/etc, rather than a bottom-up approach (I just cannot see how this would work...) In fact, this is the whole point of hotplugging, as there may be other closely related things which would have to be done. We as the writers of device drivers need a way to get rid of the device as we are notified of the physical disconnect. Yes, and as I explained earlier: you *may* get notified by the transport. > It is not our job to maintain devices in an undead state. Yes, Linus has said this here before and it's pointless for you to repeat it here. Furthermore, nothing I've said suggests that. Everyone agrees with this. And a scheme that goes subsystem driver -> hotplugging -> script finding corresponding devices -> script doing proc magic -> scsi layer notifying low level driver is _not_ sensible. It triples the amount of complexity. We need a simple scheme like 1. block further requests 2. kill old requests 3. remove device But there's nothing non-trivial about this scheme -- i.e. it's no brainer -- everyone knows that *those* are the minimum set of steps. Q: who initiates step 1? If it's the user, then we're wasting time discussing trivialities here (or maybe we're showing that we're working :-)) ). But if it's not the user, then... In general, I wasn't really discussing hotplugging, I was basically hinting that SCSI Core could use a few more functionalities, and that some things need to go away. -- Luben --- This SF.NET email is sponsored by: FREE SSL Guide from Thawte are you planning your Web Server Security? Click here to get a FREE Thawte SSL guide and find the answers to all your SSL security issues. http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0026en ___ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] Re: [PATCH] USB changes for 2.5.58
> > We as the writers of device drivers need a way to get rid of the device > > as we are notified of the physical disconnect. > > Yes, and as I explained earlier: you *may* get notified by the transport. That exactly is the point. There must be no maybe. Gone is gone. Failure is not an option here. Only LLDD knows reliably whether a device is gone and there can be no second guessing by higher levels. Consequently, the LLDD reports it and the higher layers delete the device as gently as possible, but delete it in any case. Regards Oliver --- This SF.NET email is sponsored by: FREE SSL Guide from Thawte are you planning your Web Server Security? Click here to get a FREE Thawte SSL guide and find the answers to all your SSL security issues. http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0026en ___ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] Re: [PATCH] USB changes for 2.5.58
Luben Tuikov wrote: But a removal of a device would probably have to start in top-down approach, to free/release/etc resources/etc, rather than a bottom-up approach (I just cannot see how this would work...) Well, the driver model core covers key parts of that. Or it was at least intended to ... in fact, today I think the bus drivers (like USB and PCI) need to own the top-down logic for cases like resume and hub/bridge/adapter (dis)connect. (And their bottom-up analogues for suspension.) In general, I wasn't really discussing hotplugging, I was basically hinting that SCSI Core could use a few more functionalities, and that some things need to go away. There does seem to be some consensus on that point, which is a good place to start! - Dave --- This SF.NET email is sponsored by: FREE SSL Guide from Thawte are you planning your Web Server Security? Click here to get a FREE Thawte SSL guide and find the answers to all your SSL security issues. http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0026en ___ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] Re: [PATCH] USB changes for 2.5.58
Luben Tuikov wrote:
The way this should work is that the LLD calls scsi_remove_device(), and
that cuts off the flow of commands. The LLD can promise to error-out any
pending commands in the device command queue.
I take it you mean that the transport will tell the LLDD that the device
is gone and it (LLDD) call the one above, SCSI Core to remove the device.
Hmm, more thinking needs to be done here, as shouldn't this be handled
by hotplugging? I.e. Targets do not *initiate* events.
Not exactly, but the bus driver ("transport"?) certainly does initiate
reports like "here's a new device on the bus" or "that device is gone".
That's when hotplugging kicks in (both in-kernel and in-userland).
And the only way to access a device ("target") on the bus is to give a
request to that bus driver. If, when servicing that request, the bus
driver notices the device is gone ... that can act a lot like a device
initiating a "device gone" event would look.
The transport can notify that the device is gone, but an ULP entity will
call scsi_remove_device() not the other way around.
That's how USB works today: khubd shuts things down. Device drivers
get disconnect() callbacks, just as when their modules are removed.
EXCEPT that "khubd" is part of usbcore (roughly analagous to parts
of the scsi mid-layer) ... so the drivers acting as host side proxies
for the target hardware ("usb device") are purely reactive. Their
only roles in hotplug scenarios are to bind to devices (when a new
one appears, using probe callbacks) or unbind from them (when one
goes away, using disconnect callbacks).
Those disconnect() callbacks have a few key responsibilities, very
much including shutting down the entire higher level I/O queue to
that device. I think you're saying that SCSI drivers don't have
such a responsibility (unlike USB or PCI) ... if so, that would
seem to be worth changing.
- Dave
---
This SF.NET email is sponsored by: FREE SSL Guide from Thawte
are you planning your Web Server Security? Click here to get a FREE
Thawte SSL guide and find the answers to all your SSL security issues.
http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0026en
___
[EMAIL PROTECTED]
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] Re: [PATCH] USB changes for 2.5.58
Am Montag, 20. Januar 2003 21:08 schrieb David Brownell:
> Luben Tuikov wrote:
> >> The way this should work is that the LLD calls scsi_remove_device(), and
> >> that cuts off the flow of commands. The LLD can promise to error-out
> >> any pending commands in the device command queue.
> >
> > I take it you mean that the transport will tell the LLDD that the device
> > is gone and it (LLDD) call the one above, SCSI Core to remove the device.
> >
> > Hmm, more thinking needs to be done here, as shouldn't this be handled
> > by hotplugging? I.e. Targets do not *initiate* events.
>
> Not exactly, but the bus driver ("transport"?) certainly does initiate
> reports like "here's a new device on the bus" or "that device is gone".
> That's when hotplugging kicks in (both in-kernel and in-userland).
>
> And the only way to access a device ("target") on the bus is to give a
> request to that bus driver. If, when servicing that request, the bus
> driver notices the device is gone ... that can act a lot like a device
> initiating a "device gone" event would look.
Correct. As a LLDD is the lowest layer, these are equivalent thing.
Only a LLDD can positively detect a device or a bus going away.
> > The transport can notify that the device is gone, but an ULP entity will
> > call scsi_remove_device() not the other way around.
>
> That's how USB works today: khubd shuts things down. Device drivers
> get disconnect() callbacks, just as when their modules are removed.
>
> EXCEPT that "khubd" is part of usbcore (roughly analagous to parts
> of the scsi mid-layer) ... so the drivers acting as host side proxies
> for the target hardware ("usb device") are purely reactive. Their
> only roles in hotplug scenarios are to bind to devices (when a new
> one appears, using probe callbacks) or unbind from them (when one
> goes away, using disconnect callbacks).
That model cannot be applied to SCSI as it is much more diverse
in the number of bus types it supports.
USB can do it, because it knows about hubs. SCSI cannot,
as there are no hubs in SCSI.
> Those disconnect() callbacks have a few key responsibilities, very
> much including shutting down the entire higher level I/O queue to
> that device. I think you're saying that SCSI drivers don't have
> such a responsibility (unlike USB or PCI) ... if so, that would
> seem to be worth changing.
If the scsi layer cannot on its own detect that a device or a bus is gone,
there'll be no sense in having a callback. It's just a complication.
Regards
Oliver
---
This SF.NET email is sponsored by: FREE SSL Guide from Thawte
are you planning your Web Server Security? Click here to get a FREE
Thawte SSL guide and find the answers to all your SSL security issues.
http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0026en
___
[EMAIL PROTECTED]
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] Re: [PATCH] USB changes for 2.5.58
Oliver Neukum wrote: That model cannot be applied to SCSI as it is much more diverse in the number of bus types it supports. USB can do it, because it knows about hubs. SCSI cannot, as there are no hubs in SCSI. Hubs are irrelevant here, the key functionality is noticing hardware addition/disconnect. Parts of it can be done in bus adapter code, parts of it can't. SCSI probes LUNS in much the same way khubd probes hub ports, and as I recall most of that logic isn't any more specific to the adapter than virtual root hub code is for USB. Those disconnect() callbacks have a few key responsibilities, very much including shutting down the entire higher level I/O queue to that device. I think you're saying that SCSI drivers don't have such a responsibility (unlike USB or PCI) ... if so, that would seem to be worth changing. If the scsi layer cannot on its own detect that a device or a bus is gone, there'll be no sense in having a callback. It's just a complication. Erm ... which of the three SCSI layers are you talking about? I was talking about the highest level, which is precisely the layer I think has been identified as already needing to know when to shut down the I/O queues (sd_mod and friends). - Dave --- This SF.NET email is sponsored by: FREE SSL Guide from Thawte are you planning your Web Server Security? Click here to get a FREE Thawte SSL guide and find the answers to all your SSL security issues. http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0026en ___ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] Re: [PATCH] USB changes for 2.5.58
Am Montag, 20. Januar 2003 22:24 schrieb David Brownell: > Oliver Neukum wrote: > > That model cannot be applied to SCSI as it is much more diverse > > in the number of bus types it supports. > > USB can do it, because it knows about hubs. SCSI cannot, > > as there are no hubs in SCSI. > > Hubs are irrelevant here, the key functionality is noticing > hardware addition/disconnect. Parts of it can be done in bus > adapter code, parts of it can't. SCSI probes LUNS in much > the same way khubd probes hub ports, and as I recall most of > that logic isn't any more specific to the adapter than virtual > root hub code is for USB. I should be more specific. The SCSI is different for several reasons: - we are talking about bus as well as device detection - there's no common way to probe for devices (the probing of LUNs works only on conventional busses) - many SCSI devices are not really SCSI devices. They just use the command set SCSI hotplug detection doesn't work for the same reason that USB can handle only detection of devices by itself. Busses on the other hand are not handled by USB itself. > >>Those disconnect() callbacks have a few key responsibilities, very > >>much including shutting down the entire higher level I/O queue to > >>that device. I think you're saying that SCSI drivers don't have > >>such a responsibility (unlike USB or PCI) ... if so, that would > >>seem to be worth changing. > > > > If the scsi layer cannot on its own detect that a device or a bus is > > gone, there'll be no sense in having a callback. It's just a > > complication. > > Erm ... which of the three SCSI layers are you talking about? I was > talking about the highest level, which is precisely the layer I think > has been identified as already needing to know when to shut down the > I/O queues (sd_mod and friends). In SCSI view device and bus disconnection is recognised by the lowest level. As it knows nothing about the high layers, it notifies the midlayer which in turn notifies the high level drivers. What should a callback do? The low level driver cannot do more than notify. I don't see what the midlayer could do with a callback, but I defer judgement here to the SCSI people, but definitely the LLDD has no use for a callback. Regards Oliver --- This SF.NET email is sponsored by: FREE SSL Guide from Thawte are you planning your Web Server Security? Click here to get a FREE Thawte SSL guide and find the answers to all your SSL security issues. http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0026en ___ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] Re: [PATCH] USB changes for 2.5.58
David Brownell wrote:
Luben Tuikov wrote:
The way this should work is that the LLD calls scsi_remove_device(), and
that cuts off the flow of commands. The LLD can promise to error-out
any
pending commands in the device command queue.
I take it you mean that the transport will tell the LLDD that the device
is gone and it (LLDD) call the one above, SCSI Core to remove the device.
Hmm, more thinking needs to be done here, as shouldn't this be handled
by hotplugging? I.e. Targets do not *initiate* events.
Not exactly, but the bus driver ("transport"?) certainly does initiate
reports like "here's a new device on the bus" or "that device is gone".
That's when hotplugging kicks in (both in-kernel and in-userland).
And the only way to access a device ("target") on the bus is to give a
request to that bus driver. If, when servicing that request, the bus
driver notices the device is gone ... that can act a lot like a device
initiating a "device gone" event would look.
David, when I said ``... the transport will tell the LLDD that the
device ...'' this is *exactly* what I meant. You're just repeating
it here in a more broken-down way.
By transport I mean USB, FC, SPI, etc; LLDD is the transport portal
and the initiator (aka the initiator port). This terminology is not
really that new, but still not that old, and described in SAM-3.
The transport can notify that the device is gone, but an ULP entity will
call scsi_remove_device() not the other way around.
That's how USB works today: khubd shuts things down. Device drivers
get disconnect() callbacks, just as when their modules are removed.
Pardon me, I'm not very familiar with the USB subsystem, but this only
makes sense -- why would anyone do it any other way... :-)
EXCEPT that "khubd" is part of usbcore (roughly analagous to parts
of the scsi mid-layer) ... so the drivers acting as host side proxies
for the target hardware ("usb device") are purely reactive. Their
only roles in hotplug scenarios are to bind to devices (when a new
one appears, using probe callbacks) or unbind from them (when one
goes away, using disconnect callbacks).
Very nice.
Those disconnect() callbacks have a few key responsibilities, very
much including shutting down the entire higher level I/O queue to
that device. I think you're saying that SCSI drivers don't have
such a responsibility (unlike USB or PCI) ... if so, that would
seem to be worth changing.
We just cannot let a transport event just wipe out a device,
without consulting hotplugging first -- think security.
SCSI drivers' (LLDD) responsibility is changing. This is inevitable,
due to the reorganization of SAM-3 and SPC-3. There's no more
such a thing as a ``bus'' in SCSI, e.g. ``Bus'' *may* be a
concept of the transport, and then again it may not.
General:
SCSI was never designed to support Target initiated events.
SAM-3 has no provision for it, except passively when the next
command status is returned (e.g. UA).
For this reason, device removal is *transport* related event --
it has *nothing* to do with the SCSI target/target device, except
that it's gone :-) .
Being pedantic, this would be a /transport initiated event/ .
When this event takes place, the LLDD will notice it, and
let the kernel know about it, via a callback, all the while
the LLDD will return TARGET error (since it's gone), until
is has been told slave_destroy(), after which it should
never be queried of it, and if it is it should return the same
error.
That is, when a transport event takes place, the LLDD doesn't
have to ``run to'' SCSI Core right away. Just let the kernel
know about this event, and start returning errors, on newly
queued commands.
The kernel will decide what to do about this device going away,
i.e. hotplugging, sysop notification, etc.
I guess we're crossing in this discussion in such a way, just
because of USB and SCSI crossing here. But if we think that
USB is the transport and that it could also be FC, SPI, SSA,
iSCSI, then a general framework of the workings is inevitable.
I.e. when talking about LLDDs we'd concentrate less on ``Target''
and more on ``transport''.
--
Luben
---
This SF.NET email is sponsored by: FREE SSL Guide from Thawte
are you planning your Web Server Security? Click here to get a FREE
Thawte SSL guide and find the answers to all your SSL security issues.
http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0026en
___
[EMAIL PROTECTED]
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] Re: [PATCH] USB changes for 2.5.58
Oliver Neukum wrote: I should be more specific. Yes... The SCSI is different for several reasons: - we are talking about bus as well as device detection - there's no common way to probe for devices (the probing of LUNs works only on conventional busses) So the SCSI stack needs to support more than one model for device/bus detection. This can't be news. And some of them have to handle "conventional" busses, like USB and PCI; maybe even handle booting off them... - many SCSI devices are not really SCSI devices. They just use the command set SCSI hotplug detection doesn't work for the same reason that USB can handle only detection of devices by itself. Busses on the other hand are not handled by USB itself. Just how is it that USB doesn't handle USB? "B" == "Bus" ... :) If you mean that HCs hook up to a different bus (often PCI), with its own hotplug support, that doesn't seem so different from SCSI HBAs hooking up to such busses (often PCI) and cascading the same hotplug support... Erm ... which of the three SCSI layers are you talking about? I was talking about the highest level,.. In SCSI view device and bus disconnection is recognised by the lowest level. As it knows nothing about the high layers, it notifies the midlayer So you were talking past what I said about notifying that highest level, not disagreeing with it. --- This SF.NET email is sponsored by: FREE SSL Guide from Thawte are you planning your Web Server Security? Click here to get a FREE Thawte SSL guide and find the answers to all your SSL security issues. http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0026en ___ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] Re: [PATCH] USB changes for 2.5.58
Luben Tuikov wrote: David, when I said ``... the transport will tell the LLDD that the device ...'' this is *exactly* what I meant. You're just repeating it here in a more broken-down way. OK By transport I mean USB, FC, SPI, etc; LLDD is the transport portal and the initiator (aka the initiator port). This terminology is not really that new, but still not that old, and described in SAM-3. I was hoping for something described in the 2.5.58 kernel docs, which only talks about LLD (Documentation/scsi) except in one case (looked like a typo) ... I remember SAM-3 as a kind of missile! We just cannot let a transport event just wipe out a device, without consulting hotplugging first -- think security. Certainly "device gone" would be an auditable event, but this is primarily an integrity issue: don't free objects until other components have stopped using them. If any components attach security policies to that "gone" state transition, that'd be atypical but purely their own business. (Like a transport erasing session master keys ... most transports wouldn't have them, and would likely erase them as soon as the device is known to be gone, no hotplug involved.) That is, when a transport event takes place, the LLDD doesn't have to ``run to'' SCSI Core right away. Just let the kernel know about this event, and start returning errors, on newly queued commands. The kernel will decide what to do about this device going away, i.e. hotplugging, sysop notification, etc. Sounds right. Except that it'd normally be the SCSI core that we "let" know about the event. (Not always, I can imagine that some transports might be able to kick in recovery procedures and find some other path for accessing the device. But in such cases, SCSI might never see the device as "gone" ... ) - Dave --- This SF.NET email is sponsored by: FREE SSL Guide from Thawte are you planning your Web Server Security? Click here to get a FREE Thawte SSL guide and find the answers to all your SSL security issues. http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0026en ___ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
[linux-usb-devel] Re: possibility of task getting stuck in sg handling
Am Montag, 20. Januar 2003 23:09 schrieb David Brownell: > Oliver Neukum wrote: > > this patch fixes a bug where submitting an sg request could get a task > > stuck in state D if the first submission fails. > > Did you actually observe that? I strongly suspect not. Using yield() > instead of that schedule() bit should be OK (is that what you're saying > would get "stuck"?), but the rest isn't. Did you observe this code working? set_current_state (TASK_UNINTERRUPTIBLE); schedule (); break; Here you schedule with the task state UNINTERRUPTIBLE and you are not on a waitqueue. You are dead at this point. > The patch is problematic, since it basically prevents submission of large > scatterlists from working at all in cases where resources are very tight. > It's placing an arbitrary and *very small* limit on how long it tries to > recover from "can't proceed just now, try again later" types of faults. > > If there's to be a way to stop retrying, it should NOT be because of > hitting some arbitrary limit, easily reached on busy systems. I could > understand allowing the task to be interrupted (maybe) since then the > policy is clearly in the hands of someone with appropriate knowledge. If you know a better way how to determine how often to loop, I'll implement it. But we cannot loop forever. As for making this interruptible, it's problematic to have that. The main user of this is storage, which will have to react with an IO error eventually. You may change the number of retries, but at some point, you have to give up. Perhaps we should wait a little in each loop, too, but it doesn't solve the fundamental problem. You'd have to use a mempool for that. Regards Oliver --- This SF.NET email is sponsored by: FREE SSL Guide from Thawte are you planning your Web Server Security? Click here to get a FREE Thawte SSL guide and find the answers to all your SSL security issues. http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0026en ___ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] TODO-List
Oliver Neukum wrote: Removals? Additions? Comments? Yes, I'll be glad to see more of the usbcore cleanups happen. Here are a random bunch of things - Someone just emailed me for help on that classic, and still unresolved, issue of associating a device from 'lsusb' (etc) with the right /dev/... printer node. This is largely an issue usbcore (or the driver model) should solve; it's not specific to printers (or scanners, or any other driver). Not terribly specific to USB. That's why driverfs was invented, wasn't it? But it's still un-resolved, and we _know_ this is an end-user configurability (usability) issue already. More impact than many other problems that get discussed here... And near as I can tell, NO driverfs hasn't wanted to solve this in any general way; that'd be "devfs", maybe. Though I've seen some block devices showing up through symlinks whose basenames match /dev/... node basenames, and that might be useful. That's hardly a complete list of course. And how much is 2.7? It's a very long list :-(. Is it? Depends how many people are taking things off it, and I'd hope the point of having a shared list is that it's easier for lurkers to help. (There are quite a lot of folk who'd like to make small contributions, but aren't quite sure where to start.) I am afraid we'll have to set priorities. I think the effective way to do that, in Linux, is to pick a bug and fix it ... then repeat. If lots of people are doing that, coordination can prevent wasted effort; one way we coordinate is by merging into Greg's trees and then into Linus' and Marcelo's trees. - Dave --- This SF.NET email is sponsored by: FREE SSL Guide from Thawte are you planning your Web Server Security? Click here to get a FREE Thawte SSL guide and find the answers to all your SSL security issues. http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0026en ___ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
[linux-usb-devel] Re: possibility of task getting stuck in sg handling
Oliver Neukum wrote: Am Montag, 20. Januar 2003 23:09 schrieb David Brownell: Oliver Neukum wrote: this patch fixes a bug where submitting an sg request could get a task stuck in state D if the first submission fails. Did you actually observe that? I strongly suspect not. Using yield() instead of that schedule() bit should be OK (is that what you're saying would get "stuck"?), but the rest isn't. Here you schedule with the task state UNINTERRUPTIBLE and you are not on a waitqueue. You are dead at this point. As I already said, using yield() should be OK. Submit a patch that changes just that. The patch is problematic, since it basically prevents submission of large scatterlists from working at all in cases where resources are very tight. .. If you know a better way how to determine how often to loop, I'll implement it. Any "better way" observes the "graceful degradation" design principle. Basically: it's not OK to break under load; slowing down is strongly preferable to being fragile, so long as things still work. In this case that means retry until success, as now written; instead of turning situations where the operation will succeed (next retry succeeds) into ones that will fail (trashing who knows how much work by reporting high system load as if it were a hard error). A patch to preallocate urb->hcpriv would be forward motion, it'd remove a failure path. There are other similar patches. (Someone should make UHCI allocate TDs with SLAB_KERNEL when that's how the urb is submitted, and I should dust off the OHCI patch that makes it do that again.) Turning success paths into failure paths is _backward_ motion. - Dave --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] TODO-List
David Brownell wrote: Oliver Neukum wrote: Removals? Additions? Comments? Yes, I'll be glad to see more of the usbcore cleanups happen. Here are a random bunch of things - Someone just emailed me for help on that classic, and still unresolved, issue of associating a device from 'lsusb' (etc) with the right /dev/... printer node. This is largely an issue usbcore (or the driver model) should solve; it's not specific to printers (or scanners, or any other driver). Not terribly specific to USB. That's why driverfs was invented, wasn't it? But it's still un-resolved, and we _know_ this is an end-user configurability (usability) issue already. More impact than many other problems that get discussed here... And near as I can tell, NO driverfs hasn't wanted to solve this in any general way; that'd be "devfs", maybe. Though I've seen some block devices showing up through symlinks whose basenames match /dev/... node basenames, and that might be useful. Though I'm not real useful when it comes to contributing code at this time, I'd like to add my voice to those that feel the lack of decent topological names has real user impact and limits usability. For us it isn't printers, but rather serial ports. I've been told that driverfs will do this. I don't know its state. We can use /proc/tty stuff in 2.4.20 (not sure when it was added) but would _MUCH_ rather see something that looks like the symlinks of devfs. This way COTS software will work properly without modification. Currently we are using a 2.4.17 kernel with a disgusting hack to the usb serial driver that puts symlinks in /dev (hard coded) when usb serial ports come and go. This is decidedly sub-optimal but we are getting by. We are resolving some issues with 2.4.20, but when that is done we will update our software to use a library function to look up the dev name by looking in /proc/tty/driver/usb. But this seems like a hack and requires putting annoying wrappers around software that isn't easily modified. It generally makes programs very Linux/USB/TTY specific. Even wrappers have their limitations. To generalize what I'd like to see, it would be a tree that starts with the bus type (PCI, USB, etc) and bus number (USB-0, etc) and then a directory path that represents the ports or slot numbers until you get to the device. For USB I'd like to see an entry in that directory for each USB endpoint. The way devfs works looks very much like what I want. ...but I suppose I can like and want as much as I'd like until I contribute some code. ;-) Thanks! Ty -- Tyson D Sawyer iRobot Corporation Senior Systems EngineerMilitary Systems Division [EMAIL PROTECTED] Robots for the Real World 603-654-3400 ext 206 http://www.irobot.com --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] TODO-List
Am Montag, 20. Januar 2003 21:41 schrieb David Brownell: > Oliver Neukum wrote: > >>>Removals? Additions? Comments? > >> > >>Yes, I'll be glad to see more of the usbcore cleanups happen. > >>Here are a random bunch of things > >> > >> - Someone just emailed me for help on that classic, and still > >>unresolved, issue of associating a device from 'lsusb' (etc) > >>with the right /dev/... printer node. This is largely an > >>issue usbcore (or the driver model) should solve; it's not > >>specific to printers (or scanners, or any other driver). > > > > Not terribly specific to USB. That's why driverfs was invented, > > wasn't it? > > But it's still un-resolved, and we _know_ this is an end-user Sadly, you are right. > configurability (usability) issue already. More impact than many > other problems that get discussed here... Ehm, we are fixing bugs. So I'd say that these problems we usually discuss should not have visible impact except for increased stability ;-) > And near as I can tell, NO driverfs hasn't wanted to solve this > in any general way; that'd be "devfs", maybe. Though I've seen > some block devices showing up through symlinks whose basenames > match /dev/... node basenames, and that might be useful. Well, we could probably code something up that exports major,minor for the character devices from usbcore. But I am not happy with that. It's a kludge and fundamentally racy, just as bad as the old usbd. We'd have to implement our own symlinks with revalidation to do this cleanly. I am afraid that this is not so simple. What do you think? Besides Pat and Greg will probably be after our skins for doing that. > >>That's hardly a complete list of course. > > > > And how much is 2.7? It's a very long list :-(. > > Is it? Depends how many people are taking things off it, > and I'd hope the point of having a shared list is that > it's easier for lurkers to help. (There are quite a lot > of folk who'd like to make small contributions, but aren't > quite sure where to start.) > > > I am afraid we'll have to set priorities. > > I think the effective way to do that, in Linux, is to > pick a bug and fix it ... then repeat. If lots of > people are doing that, coordination can prevent wasted > effort; one way we coordinate is by merging into Greg's > trees and then into Linus' and Marcelo's trees. What you posted are improvements for sure, but are they bugs? When will we go to code freeze? Regards Oliver --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
[linux-usb-devel] Re: possibility of task getting stuck in sg handling
> >>The patch is problematic, since it basically prevents submission of large > >>scatterlists from working at all in cases where resources are very tight. > >>.. > > > > If you know a better way how to determine how often to loop, I'll > > implement it. > > Any "better way" observes the "graceful degradation" design principle. > Basically: it's not OK to break under load; slowing down is strongly > preferable to being fragile, so long as things still work. Provided they work at all. Unless we can guarantee that the error conditions are temporary, we must eventually fail. I just can't see that. Could you explain why the submission will eventually work? Maybe I am dense. Regards Oliver --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] TODO-List
Oliver Neukum wrote: When will we go to code freeze? No such thing as "code freeze", not like commercial UNIX where it means a year before customers could see fixes. (If they're willing to pay through the nose for patches.) On the other hand, 2.5.59 won't change for a few weeks, that's at least starting to shrink change logs ... Aren't you already working to stabilize things?? ;) - Dave --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] Re: [PATCH] USB changes for 2.5.58
> So the SCSI stack needs to support more than one model for > device/bus detection. This can't be news. And some of them > have to handle "conventional" busses, like USB and PCI; maybe > even handle booting off them... Until very recently it was news. And they still haven't fully comprehended the implications. > If you mean that HCs hook up to a different bus (often PCI), with its > own hotplug support, that doesn't seem so different from SCSI HBAs > hooking up to such busses (often PCI) and cascading the same hotplug > support... Right. Only that in SCSI it's that way for devices as well, not just busses. Therefore removal detection and notification is a strict bottom to top process. > >>Erm ... which of the three SCSI layers are you talking about? I was > >>talking about the highest level,.. > > > > In SCSI view device and bus disconnection is recognised by the lowest > > level. As it knows nothing about the high layers, it notifies the > > midlayer > > So you were talking past what I said about notifying that highest level, > not disagreeing with it. I was trying to make the point that callbacks have no place in that process. It must go bottom to top and that's it. And there must be no error conditions on the way. Refusing to take notice of a device removal is just not an option. This is exactly what the current SCSI idea of an API to do bus removal does. Regards Oliver --- This SF.NET email is sponsored by: FREE SSL Guide from Thawte are you planning your Web Server Security? Click here to get a FREE Thawte SSL guide and find the answers to all your SSL security issues. http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0026en ___ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] Re: [PATCH] USB changes for 2.5.58
> > By transport I mean USB, FC, SPI, etc; LLDD is the transport portal > > and the initiator (aka the initiator port). This terminology is not > > really that new, but still not that old, and described in SAM-3. > > I was hoping for something described in the 2.5.58 kernel docs, > which only talks about LLD (Documentation/scsi) except in one case > (looked like a typo) ... I remember SAM-3 as a kind of missile! Possibly the view people at IBM have of SCSI is more comprehensive than ordinarily used. We are probably better of talking about low level drivers (LLDs). Whether these drive devices, busses or transport mechanisms is not really relevant here. > > We just cannot let a transport event just wipe out a device, > > without consulting hotplugging first -- think security. > > Certainly "device gone" would be an auditable event, but this is > primarily an integrity issue: don't free objects until other > components have stopped using them. Right. There's nothing wrong with a LLD having to wait for a _limited_ time by making a blocking call to the midlayer. But that call must finish within a limited,reasonable time and it must succeed. The complexity for handling hotunplugging belongs squarely in a centralised place, but not every LLD. It is true that currently hotplugging is a generic safety problem (unless you use devfs). The problem is reuse of device nodes leading to a race with the hotplug skripts. Old permissions may for a time be applied to a new device. But that just means that the hotplugging user space notification model is incomplete. Now the simple fix with a callback into the LLD which would allow simply waiting for the unplugging skript to run is true madness. You cannot stall a hotpluggable subsystem waiting on a skript, neither can you do sane error handling. Problem should be fixed where they arise, eg. "lock" a new hotplugged device. > If any components attach security policies to that "gone" state > transition, that'd be atypical but purely their own business. > (Like a transport erasing session master keys ... most transports > wouldn't have them, and would likely erase them as soon as the > device is known to be gone, no hotplug involved.) Right. > > That is, when a transport event takes place, the LLDD doesn't > > have to ``run to'' SCSI Core right away. Just let the kernel > > know about this event, and start returning errors, on newly > > queued commands. > > > > The kernel will decide what to do about this device going away, > > i.e. hotplugging, sysop notification, etc. > > Sounds right. Except that it'd normally be the SCSI core that > we "let" know about the event. (Not always, I can imagine that > some transports might be able to kick in recovery procedures > and find some other path for accessing the device. But in > such cases, SCSI might never see the device as "gone" ... ) I must disagree. There's no decision involved here. You handle tasks having the device open, clean things up, free up the resources and fire off a user space notification. Decisions get made in user space where policy can be reasonably implemented. Regards Oliver --- This SF.NET email is sponsored by: FREE SSL Guide from Thawte are you planning your Web Server Security? Click here to get a FREE Thawte SSL guide and find the answers to all your SSL security issues. http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0026en ___ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] Re: [PATCH] USB changes for 2.5.58
Oliver Neukum wrote: So you were talking past what I said about notifying that highest level, not disagreeing with it. I was trying to make the point that callbacks have no place in that process. If so, you didn't persuade me ... It must go bottom to top and that's it. ... because those disconnect() callbacks are exactly how USB and PCI deliver that notification to the "top" level, and you've already agreed that SCSI needs to accomodate those models. So clearly they have at least that much of a place. Refusing to take notice of a device removal is just not an option. This is exactly what the current SCSI idea of an API to do bus removal does. I perceive violent agreement that a change is needed in that area. But the next step there would seem to be a patch to the SCSI APIs, unless I mis-understood what Matt was saying about the issue he ran into when making usb-storage use the enumeration facilities in the current SCSI mid/low layers. - Dave --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] Re: [PATCH] USB changes for 2.5.58
Am Dienstag, 21. Januar 2003 01:44 schrieb David Brownell: > Oliver Neukum wrote: > >>So you were talking past what I said about notifying that highest level, > >>not disagreeing with it. > > > > I was trying to make the point that callbacks have no place in that > > process. > > If so, you didn't persuade me ... > > > It must go bottom to top and that's it. > > ... because those disconnect() callbacks are exactly how USB and PCI > deliver that notification to the "top" level, and you've already agreed > that SCSI needs to accomodate those models. So clearly they have at least > that much of a place. Disconnect is not really a callback. There's a distinct lack of a back movement here. khubd -> usbcore -> disconnect() in driver -> [layer on top] The proposed API in SCSI looks like: -> LLD -> midlayer -> top layer -> midlayer -> LLD with destroy_slave() and that's not OK. > > Refusing to take notice of a device removal is just not an option. > > This is exactly what the current SCSI idea of an API to do bus removal > > does. > > I perceive violent agreement that a change is needed in that area. > > But the next step there would seem to be a patch to the SCSI APIs, > unless I mis-understood what Matt was saying about the issue he ran > into when making usb-storage use the enumeration facilities in the > current SCSI mid/low layers. I have some horrible notions when I see what APIs grace the SCSI layer. Regards Oliver --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
[linux-usb-devel] Re: possibility of task getting stuck in sg handling
Oliver Neukum wrote: Any "better way" observes the "graceful degradation" design principle. Basically: it's not OK to break under load; slowing down is strongly preferable to being fragile, so long as things still work. Provided they work at all. Unless we can guarantee that the error conditions are temporary, we must eventually fail. Didn't I say "... still work"? Progress is clearly forward in the typical cases (like a previous urb completing frees up enough TDs). For the last half-percent, one re-works memory allocation models ... in ways that doesn't seem to me like 2.6 issues. - Dave --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] Re: [PATCH] USB changes for 2.5.58
On Mon, 2003-01-20 at 18:23, Oliver Neukum wrote: > > The transport can notify that the device is gone, but an ULP entity will > > call scsi_remove_device() not the other way around. > > NO! > > This is an insanely complicated scheme. > We have no notification beforehand. User yanks out cable. > That's it. No preperation at all. > > We as the writers of device drivers need a way to get rid of the device > as we are notified of the physical disconnect. It is not our job to maintain > devices in an undead state. If you think about it rationally there isnt a lot that can be done higher up. At the point the hardware vanishes there may be other threads of execution already in your driver, so undead state is a reality you have to live with, at least briefly. Providing you refcount objects and defer freeing of resources its not normally too terrible --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] Lacie USB2.0 Hard disk bug report
pre3-ac has a page list handling bug. That is probably the issue --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
RE: [linux-usb-devel] Re: [PATCH] USB changes for 2.5.58
> That model cannot be applied to SCSI as it is much more diverse > in the number of bus types it supports. > USB can do it, because it knows about hubs. SCSI cannot, > as there are no hubs in SCSI. Not entirely true - there are devices known as bridges that bridge parallel SCSI to parallel SCSI and parallel SCSI to fiber channel. Not to talk about fiber channel as a SCSI interface. Tnx & Bi Bennie Venter --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
[linux-usb-devel] Re: possibility of task getting stuck in sg handling
Am Dienstag, 21. Januar 2003 03:06 schrieb David Brownell:
> Oliver Neukum wrote:
> >>Any "better way" observes the "graceful degradation" design principle.
> >>Basically: it's not OK to break under load; slowing down is strongly
> >>preferable to being fragile, so long as things still work.
> >
> > Provided they work at all. Unless we can guarantee that the error
> > conditions are temporary, we must eventually fail.
>
> Didn't I say "... still work"? Progress is clearly forward in the
> typical cases (like a previous urb completing frees up enough TDs).
> For the last half-percent, one re-works memory allocation models ...
> in ways that doesn't seem to me like 2.6 issues.
Like this version better?
If progress in the typical case is clearly forward, the call will very
likely succeed. But that doesn't mean that the atypical case where
no progress is made can be ignored. An infinite loop is never
acceptable.
If a small risk of an infinite loop is acceptable to you, why is a small
risk of an API call failing not acceptable? We can discuss endlessly
about the exact point to give up, but, as this code path is obviously
rarely taken (the lockups were not noticed), I see no point.
You may of course fix the issue by changing things at lower levels,
but, as you said, this is 2.7 stuff. So what to do in the meantime?
Could you live with returning the number of bytes that remain to be
transfered so that higher layers can recover from this condition?
Regards
Oliver
You can import this changeset into BK by piping this whole message to:
'| bk receive [path to repository]' or apply the patch as usual.
===
[EMAIL PROTECTED], 2003-01-21 08:34:38+01:00, [EMAIL PROTECTED]
- improve error handling in sg case
message.c |8
1 files changed, 4 insertions(+), 4 deletions(-)
diff -Nru a/drivers/usb/core/message.c b/drivers/usb/core/message.c
--- a/drivers/usb/core/message.cTue Jan 21 08:35:22 2003
+++ b/drivers/usb/core/message.cTue Jan 21 08:35:22 2003
@@ -436,13 +436,13 @@
retval = 0;
i--;
retries++;
- if (retries > 5) {
+ if (retries > 50) { //number with particular reason
usb_sg_cancel(io);
goto give_up_and_exit;
}
- // FIXME: should it usb_sg_cancel() on INTERRUPT?
- // how about imposing a backoff?
- yield();
+ /* we wait some time for kswapd to do it's job */
+ set_current_state(TASK_UNINTERRUPTIBLE);
+ schedule_timeout(HZ/5); //wild guess
break;
/* no error? continue immediately.
===
This BitKeeper patch contains the following changesets:
1.1287
## Wrapped with gzip_uu ##
begin 664 bkpatch7459
M'XL(`#KX+#X``[U4R6[;,!`]FU\Q0`[-`END2&IQX"`KFB!!:CCQI1=#RUA6
M;8L&2<4MJH\O9:,)BK9.-U0@1)$S\_CF\4%[,#:H^QVU*)]0DSVX5L:Z)5:J
MPMY,+7%15O7'GM*%"XZ49'(5#N4>;Y#&C4YZ+/HR/*^I3"#FPX8M"EY!S^OH,+DD$7RN5*JR<$U%II
M7I+J5>`6^OA=&0
M"QXV`0N%W)CDYS6M:_XQ^YT>>IW]5U-)R:GB*_VRIK>3O
MH*O7F^$L,MRA_A\8[E+P&!BYV4Z=3J>[B=C.]O[A^O1J/Q\/'F_.[J
MX'B3F\TPKQOWWORX-@Q79>+'(K:2?+RXW/)V=S4RT$X94D8RYA\
)`9>^@&YD!0``
`
end
---
This SF.NET email is sponsored by:
SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
http://www.vasoftware.com
___
[EMAIL PROTECTED]
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
[linux-usb-devel] SL811: Question about non-DMA-usage
Hi ! I have an embedded XScale system with an SL811HS USB host chip. I've got usb-2.4 via Bitkeeper and looked into it because it had code for this USB chip and I had problems with http://www.arm.linux.org.uk/developer/patches/viewpatch.php?id=1272/1 The links to my mail with the problems I had with this driver are http://lists.arm.linux.org.uk/pipermail/linux-arm-kernel/2003-January/013071.html So I copied the relevant pieces from the usb-2.4 tree into my 2.4.19-rmk4-pxa2 tree and tried to compile the stuff. However, this did not work. I saw that in hcd.c there is the following code: // NOTE: 2.5 does this if !URB_NO_DMA_MAP transfer flag if (usb_pipecontrol (urb->pipe)) urb->setup_dma = pci_map_single ( hcd->pdev, urb->setup_packet, sizeof (struct usb_ctrlrequest), PCI_DMA_TODEVICE); if (urb->transfer_buffer_length != 0) urb->transfer_dma = pci_map_single ( hcd->pdev, urb->transfer_buffer, urb->transfer_buffer_length, usb_pipein (urb->pipe) ? PCI_DMA_FROMDEVICE : PCI_DMA_TODEVICE); No I wonder how I would convert this code to work on my PCI-less device --- That means that CONFIG_PCI is not set so there is no hcd->pdev. Also, the chip is not DMA-driven, nDACK and nDREQ pins are not connected to the CPU, so calling dma functions should not be done ?!? --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] Re: [PATCH] USB changes for 2.5.58
Am Dienstag, 21. Januar 2003 04:31 schrieb Alan: > On Mon, 2003-01-20 at 18:23, Oliver Neukum wrote: > > > The transport can notify that the device is gone, but an ULP entity > > > will call scsi_remove_device() not the other way around. > > > > NO! > > > > This is an insanely complicated scheme. > > We have no notification beforehand. User yanks out cable. > > That's it. No preperation at all. > > > > We as the writers of device drivers need a way to get rid of the device > > as we are notified of the physical disconnect. It is not our job to > > maintain devices in an undead state. > > If you think about it rationally there isnt a lot that can be done higher > up. At the point the hardware vanishes there may be other threads of > execution already in your driver, so undead state is a reality you have to > live with, at least briefly. No problem with that. I have a problem with notifying the SCSI layer and then waiting for an unlimited time until maybe the SCSI layer decides to inform me of a success. You see, disconnection has to work. Having to wait for an unlimited time is a kind of failure. I simply don't trust the SCSI layer. I've had to much trouble with it already. Regards Oliver --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
