2.6.9-rc4 USB storage problems

2.6.9-rc4 USB storage problems

[Wolfgang Scheicher]

I'm sorry for not being able to track down the issue better:

if i mount my usb-stick ( Sandisk Micro 256MB, USB2.0, FAT ), write a file 
(for example 4MB) to it and unmount or sync, then there is a lot of activity 
on the stick, but the unmount or sync doesn't finish ( waited > 10 Minutes - 
should not take more than 1-2 sec ).

2.6.9-rc2 seems to be the same issue
i remember 2.6.7 and before being fine for my usb-stick, 2.6.8(.x) i need to 
test...

oh - and it _is_ detected as high speed USB device - and eaven if it would 
have been usb 1.x it shouldn't take that long.

any hints? any patches i shall try?

Worf

Re: 2.6.9-rc4 USB storage problems

[bert hubert]

On Tue, Oct 12, 2004 at 02:24:59PM +0200, Wolfgang Scheicher wrote:
> 
> I'm sorry for not being able to track down the issue better:
> 
> if i mount my usb-stick ( Sandisk Micro 256MB, USB2.0, FAT ), write a file 
> (for example 4MB) to it and unmount or sync, then there is a lot of activity 
> on the stick, but the unmount or sync doesn't finish ( waited > 10 Minutes - 
> should not take more than 1-2 sec ).

Can you run vmstat 1 during this process - so start vmstat 1 before umount,
and then umount but leave it running.

> any hints? any patches i shall try?

Please provide dmesg output, and vmstat 1.

-- 
http://www.PowerDNS.com      Open source, database driven DNS Software 
http://lartc.org           Linux Advanced Routing & Traffic Control HOWTO

Re: 2.6.9 USB storage problems

[Wolfgang Scheicher]

Am Dienstag, 12. Oktober 2004 19:51 schrieb bert hubert:
> On Tue, Oct 12, 2004 at 02:24:59PM +0200, Wolfgang Scheicher wrote:
>> if i mount my usb-stick ( Sandisk Micro 256MB, USB2.0, FAT ), write a
>> file (for example 4MB) to it and unmount or sync, then there is a lot of
>> activity on the stick, but the unmount or sync doesn't finish ( waited >
>> 10 Minutes - should not take more than 1-2 sec ).
>
> Can you run vmstat 1 during this process - so start vmstat 1 before umount,
> and then umount but leave it running.
>
>> any hints? any patches i shall try?
>
> Please provide dmesg output, and vmstat 1.

sorry for not responding earlier.

what exactely of dmesg?
i think this is the usb stick related part in dmesg:
[...]
ohci_hcd: 2004 Feb 02 USB 1.1 'Open' Host Controller (OHCI) Driver (PCI)
ACPI: PCI interrupt 0000:00:02.0[A] -> GSI 5 (level, low) -> IRQ 5
ohci_hcd 0000:00:02.0: nVidia Corporation nForce2 USB Controller
PCI: Setting latency timer of device 0000:00:02.0 to 64
ohci_hcd 0000:00:02.0: irq 5, pci mem e0c22000
ohci_hcd 0000:00:02.0: new USB bus registered, assigned bus number 1
hub 1-0:1.0: USB hub found
hub 1-0:1.0: 3 ports detected
ACPI: PCI interrupt 0000:00:02.1[B] -> GSI 11 (level, low) -> IRQ 11
ohci_hcd 0000:00:02.1: nVidia Corporation nForce2 USB Controller (#2)
PCI: Setting latency timer of device 0000:00:02.1 to 64
ohci_hcd 0000:00:02.1: irq 11, pci mem e0c34000
ohci_hcd 0000:00:02.1: new USB bus registered, assigned bus number 2
hub 2-0:1.0: USB hub found
hub 2-0:1.0: 3 ports detected
ACPI: PCI interrupt 0000:00:02.2[C] -> GSI 3 (level, low) -> IRQ 3
ehci_hcd 0000:00:02.2: nVidia Corporation nForce2 USB Controller
PCI: Setting latency timer of device 0000:00:02.2 to 64
ehci_hcd 0000:00:02.2: irq 3, pci mem e0c36000
ehci_hcd 0000:00:02.2: new USB bus registered, assigned bus number 3
PCI: cache line size of 64 is not supported by device 0000:00:02.2
ehci_hcd 0000:00:02.2: USB 2.0 enabled, EHCI 1.00, driver 2004-May-10
hub 3-0:1.0: USB hub found
hub 3-0:1.0: 6 ports detected
forcedeth.c: Reverse Engineered nForce ethernet driver. Version 0.29.
ACPI: PCI interrupt 0000:00:04.0[A] -> GSI 11 (level, low) -> IRQ 11
PCI: Setting latency timer of device 0000:00:04.0 to 64
ohci_hcd 0000:00:02.1: wakeup

[...]

usb 3-2: new high speed USB device using address 4
ub: sizeof ub_scsi_cmd 60 ub_dev 924
uba: device 4 capacity nsec 512000 bsize 512
uba: was not changed
 /dev/ub/a: p1
usbcore: registered new driver ub
uba: was not changed


vmstat 1 looks like:

procs -----------memory---------- ---swap-- -----io---- --system-- ----cpu----
 r  b   swpd   free   buff  cache   si   so    bi    bo   in    cs us sy id wa
 0  0      0  69388  47636 197444    0    0     0     0 1426  1449 13  7 80  0
 0  0      0  69388  47636 197448    0    0     0   148 1430  1311 10  4 86  0
 0  0      0  69388  47636 197448    0    0     0     0 1428  1426 11  4 85  0
[now umount starts]
 0  1      0  69132  47636 197448    0    0     0    80 1392  1869 16  3 19 62
 0  1      0  69132  47636 197448    0    0     0     0 1410  1119  8  1  0 91
 0  1      0  69132  47636 197448    0    0     0     0 1413  1103  6  3  0 91
[...this was a 200kb test file, skipping ca. 30 similar lines...]
 0  1      0  69164  47636 197448    0    0     0     0 1409  1130  7  2  0 91
 0  1      0  69164  47636 197448    0    0     0     0 1421  1088  8  2  0 90
 0  0      0  70716  47468 197240    0    0     0     0 1394  1206 11  1 12 76
[now umount finished]
 0  0      0  70716  47508 197240    0    0     0   112 1366  1033  8  2 90  0
 0  0      0  70716  47508 197240    0    0     0    84 1387  1047  6  5 89  0
 0  0      0  70716  47508 197240    0    0     0     0 1365  1134  6  2 92  0

i tested with 100kb, 200kb and 400kb (which takes long, but not too long to 
wait) and i wonder if time actually grows linear with bigger files, or if 
it's eaven worse.

reading is at ca. 500kb/sec

btw - i compared several kernel versions in the meantime.
2.6.8 doesn't show the issue, 2.6.9-rc2 up to 2.6.9 does...

Worf

Re: 2.6.9 USB storage problems

[Matthew Dharm]

[-- Attachment #1: Type: text/plain, Size: 4963 bytes --]

You're using the UB driver.  Does it work if you turn that off and use the
usb-storage driver instead?

Matt

On Mon, Nov 01, 2004 at 06:50:47PM +0100, Wolfgang Scheicher wrote:
> Am Dienstag, 12. Oktober 2004 19:51 schrieb bert hubert:
> > On Tue, Oct 12, 2004 at 02:24:59PM +0200, Wolfgang Scheicher wrote:
> >> if i mount my usb-stick ( Sandisk Micro 256MB, USB2.0, FAT ), write a
> >> file (for example 4MB) to it and unmount or sync, then there is a lot of
> >> activity on the stick, but the unmount or sync doesn't finish ( waited >
> >> 10 Minutes - should not take more than 1-2 sec ).
> >
> > Can you run vmstat 1 during this process - so start vmstat 1 before umount,
> > and then umount but leave it running.
> >
> >> any hints? any patches i shall try?
> >
> > Please provide dmesg output, and vmstat 1.
> 
> sorry for not responding earlier.
> 
> what exactely of dmesg?
> i think this is the usb stick related part in dmesg:
> [...]
> ohci_hcd: 2004 Feb 02 USB 1.1 'Open' Host Controller (OHCI) Driver (PCI)
> ACPI: PCI interrupt 0000:00:02.0[A] -> GSI 5 (level, low) -> IRQ 5
> ohci_hcd 0000:00:02.0: nVidia Corporation nForce2 USB Controller
> PCI: Setting latency timer of device 0000:00:02.0 to 64
> ohci_hcd 0000:00:02.0: irq 5, pci mem e0c22000
> ohci_hcd 0000:00:02.0: new USB bus registered, assigned bus number 1
> hub 1-0:1.0: USB hub found
> hub 1-0:1.0: 3 ports detected
> ACPI: PCI interrupt 0000:00:02.1[B] -> GSI 11 (level, low) -> IRQ 11
> ohci_hcd 0000:00:02.1: nVidia Corporation nForce2 USB Controller (#2)
> PCI: Setting latency timer of device 0000:00:02.1 to 64
> ohci_hcd 0000:00:02.1: irq 11, pci mem e0c34000
> ohci_hcd 0000:00:02.1: new USB bus registered, assigned bus number 2
> hub 2-0:1.0: USB hub found
> hub 2-0:1.0: 3 ports detected
> ACPI: PCI interrupt 0000:00:02.2[C] -> GSI 3 (level, low) -> IRQ 3
> ehci_hcd 0000:00:02.2: nVidia Corporation nForce2 USB Controller
> PCI: Setting latency timer of device 0000:00:02.2 to 64
> ehci_hcd 0000:00:02.2: irq 3, pci mem e0c36000
> ehci_hcd 0000:00:02.2: new USB bus registered, assigned bus number 3
> PCI: cache line size of 64 is not supported by device 0000:00:02.2
> ehci_hcd 0000:00:02.2: USB 2.0 enabled, EHCI 1.00, driver 2004-May-10
> hub 3-0:1.0: USB hub found
> hub 3-0:1.0: 6 ports detected
> forcedeth.c: Reverse Engineered nForce ethernet driver. Version 0.29.
> ACPI: PCI interrupt 0000:00:04.0[A] -> GSI 11 (level, low) -> IRQ 11
> PCI: Setting latency timer of device 0000:00:04.0 to 64
> ohci_hcd 0000:00:02.1: wakeup
> 
> [...]
> 
> usb 3-2: new high speed USB device using address 4
> ub: sizeof ub_scsi_cmd 60 ub_dev 924
> uba: device 4 capacity nsec 512000 bsize 512
> uba: was not changed
>  /dev/ub/a: p1
> usbcore: registered new driver ub
> uba: was not changed
> 
> 
> vmstat 1 looks like:
> 
> procs -----------memory---------- ---swap-- -----io---- --system-- ----cpu----
>  r  b   swpd   free   buff  cache   si   so    bi    bo   in    cs us sy id wa
>  0  0      0  69388  47636 197444    0    0     0     0 1426  1449 13  7 80  0
>  0  0      0  69388  47636 197448    0    0     0   148 1430  1311 10  4 86  0
>  0  0      0  69388  47636 197448    0    0     0     0 1428  1426 11  4 85  0
> [now umount starts]
>  0  1      0  69132  47636 197448    0    0     0    80 1392  1869 16  3 19 62
>  0  1      0  69132  47636 197448    0    0     0     0 1410  1119  8  1  0 91
>  0  1      0  69132  47636 197448    0    0     0     0 1413  1103  6  3  0 91
> [...this was a 200kb test file, skipping ca. 30 similar lines...]
>  0  1      0  69164  47636 197448    0    0     0     0 1409  1130  7  2  0 91
>  0  1      0  69164  47636 197448    0    0     0     0 1421  1088  8  2  0 90
>  0  0      0  70716  47468 197240    0    0     0     0 1394  1206 11  1 12 76
> [now umount finished]
>  0  0      0  70716  47508 197240    0    0     0   112 1366  1033  8  2 90  0
>  0  0      0  70716  47508 197240    0    0     0    84 1387  1047  6  5 89  0
>  0  0      0  70716  47508 197240    0    0     0     0 1365  1134  6  2 92  0
> 
> i tested with 100kb, 200kb and 400kb (which takes long, but not too long to 
> wait) and i wonder if time actually grows linear with bigger files, or if 
> it's eaven worse.
> 
> reading is at ca. 500kb/sec
> 
> btw - i compared several kernel versions in the meantime.
> 2.6.8 doesn't show the issue, 2.6.9-rc2 up to 2.6.9 does...
> 
> Worf
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/

-- 
Matthew Dharm                              Home: mdharm-usb@one-eyed-alien.net 
Maintainer, Linux USB Mass Storage Driver

It was a new hope.
					-- Dust Puppy
User Friendly, 12/25/1998

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: 2.6.9 USB storage problems

[Wolfgang Scheicher]

Am Montag, 1. November 2004 20:10 schrieb Matthew Dharm:
> You're using the UB driver.  Does it work if you turn that off and use the
> usb-storage driver instead?

Damn, you are right - this is a new driver...
I didn't notice that, i did rely on hotplug to load the correct modules.

Removed the ub driver and everything is fine now.

That means - just unloadin ub and loading usb-storage didn't work. 

I had to remove it from the kernel config and rebuild the modules. Actually 
usb-storage was the only module being rebuilt. Looks like usb-storage's 
functionality is different if ub is built.

So, my system works fine again, thank you.
But it leaves the question: why does ub perform so badly?

And: could maybe somebody put some hints into the ub help?
"This driver supports certain USB attached storage devices such as flash 
keys." didn't sound so bad to me...

Worf

Re: 2.6.9 USB storage problems

[Matthew Dharm]

[-- Attachment #1: Type: text/plain, Size: 1417 bytes --]

On Mon, Nov 01, 2004 at 08:40:32PM +0100, Wolfgang Scheicher wrote:
> Am Montag, 1. November 2004 20:10 schrieb Matthew Dharm:
> > You're using the UB driver.  Does it work if you turn that off and use the
> > usb-storage driver instead?
> 
> Damn, you are right - this is a new driver...
> I didn't notice that, i did rely on hotplug to load the correct modules.
> 
> Removed the ub driver and everything is fine now.
> 
> That means - just unloadin ub and loading usb-storage didn't work. 
> 
> I had to remove it from the kernel config and rebuild the modules. Actually 
> usb-storage was the only module being rebuilt. Looks like usb-storage's 
> functionality is different if ub is built.
> 
> So, my system works fine again, thank you.
> But it leaves the question: why does ub perform so badly?

Talk to Pete Zaitcev about that.

> And: could maybe somebody put some hints into the ub help?
> "This driver supports certain USB attached storage devices such as flash 
> keys." didn't sound so bad to me...

That should definately happen.  Along with a note that this blocks
usb-storage from working with many devices if enabled.

Matt

-- 
Matthew Dharm                              Home: mdharm-usb@one-eyed-alien.net 
Maintainer, Linux USB Mass Storage Driver

I think the problem is there's a nut loose on your keyboard.
					-- Greg to Customer
User Friendly, 1/5/1999 

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: 2.6.9 USB storage problems

[Wolfgang Scheicher]

Am Montag, 1. November 2004 22:35 schrieb Matthew Dharm:
> On Mon, Nov 01, 2004 at 08:40:32PM +0100, Wolfgang Scheicher wrote:
>> Am Montag, 1. November 2004 20:10 schrieb Matthew Dharm:
>>> You're using the UB driver.  Does it work if you turn that off and use
>>> the usb-storage driver instead?
>>
>> Damn, you are right - this is a new driver...
>> I didn't notice that, i did rely on hotplug to load the correct modules.
>>
>> Removed the ub driver and everything is fine now.
>>
>> That means - just unloadin ub and loading usb-storage didn't work.
>>
>> I had to remove it from the kernel config and rebuild the modules.
>> Actually usb-storage was the only module being rebuilt. Looks like
>> usb-storage's functionality is different if ub is built.
>>
>> So, my system works fine again, thank you.
>> But it leaves the question: why does ub perform so badly?
>
> Talk to Pete Zaitcev about that.

ok - so this goes to him too :-)

Pete, i don't know if you have seen my previous posts...
I did now have a look at the comments in ub.c
Looks like the driver is very new and a lot has yet to be done.
I cannot really tell what of the points on the todo list may be related to my 
problem. I miss information and "ub" isn't really a good keyword to google 
for either.

What is the difference to the usb-storage driver?
What is the state, what are the plans?

>> And: could maybe somebody put some hints into the ub help?
>> "This driver supports certain USB attached storage devices such as flash
>> keys." didn't sound so bad to me...
>
> That should definately happen.  Along with a note that this blocks
> usb-storage from working with many devices if enabled.

Yep. Absolutely.

Worf

Re: 2.6.9 USB storage problems

[Pete Zaitcev]

On Mon, 1 Nov 2004 23:19:13 +0100, Wolfgang Scheicher <worf@sbox.tu-graz.ac.at> wrote:

> Looks like the driver is very new and a lot has yet to be done.

This is why it defaults to N in defconfig, and this is why the help for
CONFIG_BLK_DEV_UB says "If unsure, say N."

-- Pete

Re: 2.6.9 USB storage problems

[Pete Zaitcev]

On Mon, 1 Nov 2004 23:19:13 +0100, Wolfgang Scheicher <worf@sbox.tu-graz.ac.at> wrote:

> >> And: could maybe somebody put some hints into the ub help?
> >> "This driver supports certain USB attached storage devices such as flash
> >> keys." didn't sound so bad to me...
> >
> > That should definately happen.  Along with a note that this blocks
> > usb-storage from working with many devices if enabled.
> 
> Yep. Absolutely.

I don't like too much wordage. How about this:

diff -urp -X dontdiff linux-2.6.10-rc1/drivers/block/Kconfig linux-2.6.10-rc1-ub/drivers/block/Kconfig
--- linux-2.6.10-rc1/drivers/block/Kconfig	2004-10-28 09:46:38.000000000 -0700
+++ linux-2.6.10-rc1-ub/drivers/block/Kconfig	2004-11-01 16:09:13.727453544 -0800
@@ -308,6 +308,8 @@ config BLK_DEV_UB
 	  This driver supports certain USB attached storage devices
 	  such as flash keys.
 
+	  Warning: Enabling this cripples the usb-storage driver.
+
 	  If unsure, say N.
 
 config BLK_DEV_RAM

-- Pete

Re: 2.6.9 USB storage problems

[Bill Davidsen]

Pete Zaitcev wrote:
> On Mon, 1 Nov 2004 23:19:13 +0100, Wolfgang Scheicher <worf@sbox.tu-graz.ac.at> wrote:
> 
> 
>>>>And: could maybe somebody put some hints into the ub help?
>>>>"This driver supports certain USB attached storage devices such as flash
>>>>keys." didn't sound so bad to me...
>>>
>>>That should definately happen.  Along with a note that this blocks
>>>usb-storage from working with many devices if enabled.
>>
>>Yep. Absolutely.
> 
> 
> I don't like too much wordage. How about this:
> 
> diff -urp -X dontdiff linux-2.6.10-rc1/drivers/block/Kconfig linux-2.6.10-rc1-ub/drivers/block/Kconfig
> --- linux-2.6.10-rc1/drivers/block/Kconfig	2004-10-28 09:46:38.000000000 -0700
> +++ linux-2.6.10-rc1-ub/drivers/block/Kconfig	2004-11-01 16:09:13.727453544 -0800
> @@ -308,6 +308,8 @@ config BLK_DEV_UB
>  	  This driver supports certain USB attached storage devices
>  	  such as flash keys.
>  
> +	  Warning: Enabling this cripples the usb-storage driver.
> +
>  	  If unsure, say N.
>  
>  config BLK_DEV_RAM

I just got information on this in another thread, in case you didn't see 
my note there, is this behaviour a bug, design choice, or unavoidable 
hardware issue? I can turn it off now, but I'm supposed to be getting a 
flash key thing to test, which is why I turned it on in the first place.

-- 
    -bill davidsen (davidsen@tmr.com)
"The secret to procrastination is to put things off until the
  last possible moment - but no longer"  -me

Re: 2.6.9 USB storage problems

[Pete Zaitcev]

On Wed, 03 Nov 2004 17:02:43 -0500, Bill Davidsen <davidsen@tmr.com> wrote:

> I just got information on this in another thread, in case you didn't see 
> my note there, is this behaviour a bug, design choice, or unavoidable 
> hardware issue? I can turn it off now, but I'm supposed to be getting a 
> flash key thing to test, which is why I turned it on in the first place.

The explanation may be a little long.

On most distributions, drivers are loaded with hotplug. Nobody, and I do
mean it, for all practical reasons nobody loads their drivers from
/etc/rc.d/rc.local anymore. (Side note: it is possible to load ub from
/etc/modprobe.conf, but not usb-storage, because of too many layers
between a block device and usb-storage: an open is a non-event there)

The hotplug is controlled by match lists, generated from C source (indirectly;
actually from object files, compiled from C source). This way, what is loaded
by hotplug would match what is present if same things were linked in, among
other things. The hotplug has no preference mechanism aside from hand-editing
those match lists. They have to be non-conflicting.

Given the above, it's hurtful to allow drivers to conflict, so such conflicts
are rare. I know of bcm5700 vs. tg3, eepro100 vs. e100, 812x vs 8130too.
AFAIK, in all such cases if one is configured, another cannot be configured
and vice versa. The USB contains an exception, curiously enough. In 2.4
kernels, it was possible to configure both uhci (ALT) and usb-uhci as
modules. It was annoying; Red Hat resolved it by loading usb-uhci from
/etc/rc.d/rc.sysinit (also marked in /etc/modules.conf, but that was
just a tag for kudzu and other tools).

So, when ub is configured to service certain classes of devices, usb-storage
relinquishes its control of them, resolving the conflict. This is assymmetric
in its implementation, but it's an artefact; no implication is made about
which driver is first among equals. In an ideal world we'd have something
like CONFIG_USB_STORAGE_PREF with two values "ub" and "usb-storage", or such.

I thought about the coexistence between the two at some length, and it seems
to me that the current scheme is the simplest workable scheme. I even thought
it as "least confusing" until messages from Wolfgang and others made it clear
that relationship between ub and usb-storage is not obvious enough to them.
I'm always open to patches, too.

-- Pete

Re: 2.6.9 USB storage problems

[Bill Davidsen]

On Thu, 4 Nov 2004, Pete Zaitcev wrote:

> On Wed, 03 Nov 2004 17:02:43 -0500, Bill Davidsen <davidsen@tmr.com> wrote:
> 
> > I just got information on this in another thread, in case you didn't see 
> > my note there, is this behaviour a bug, design choice, or unavoidable 
> > hardware issue? I can turn it off now, but I'm supposed to be getting a 
> > flash key thing to test, which is why I turned it on in the first place.
> 
> The explanation may be a little long.

Thank you for taking the time to make it! I now understand the problem
not only well enough to avoid it, but to ask another question below.
> 
> On most distributions, drivers are loaded with hotplug. Nobody, and I do
> mean it, for all practical reasons nobody loads their drivers from
> /etc/rc.d/rc.local anymore. (Side note: it is possible to load ub from
> /etc/modprobe.conf, but not usb-storage, because of too many layers
> between a block device and usb-storage: an open is a non-event there)
> 
> The hotplug is controlled by match lists, generated from C source (indirectly;
> actually from object files, compiled from C source). This way, what is loaded
> by hotplug would match what is present if same things were linked in, among
> other things. The hotplug has no preference mechanism aside from hand-editing
> those match lists. They have to be non-conflicting.
> 
> Given the above, it's hurtful to allow drivers to conflict, so such conflicts
> are rare. I know of bcm5700 vs. tg3, eepro100 vs. e100, 812x vs 8130too.
> AFAIK, in all such cases if one is configured, another cannot be configured
> and vice versa. The USB contains an exception, curiously enough. In 2.4
> kernels, it was possible to configure both uhci (ALT) and usb-uhci as
> modules. It was annoying; Red Hat resolved it by loading usb-uhci from
> /etc/rc.d/rc.sysinit (also marked in /etc/modules.conf, but that was
> just a tag for kudzu and other tools).
> 
> So, when ub is configured to service certain classes of devices, usb-storage
> relinquishes its control of them, resolving the conflict. This is assymmetric
> in its implementation, but it's an artefact; no implication is made about
> which driver is first among equals. In an ideal world we'd have something
> like CONFIG_USB_STORAGE_PREF with two values "ub" and "usb-storage", or such.
> 
> I thought about the coexistence between the two at some length, and it seems
> to me that the current scheme is the simplest workable scheme. I even thought
> it as "least confusing" until messages from Wolfgang and others made it clear
> that relationship between ub and usb-storage is not obvious enough to them.
> I'm always open to patches, too.

It would seem that wanting to use both flash keys and more common USB
devices would be the common case for those who use flash keys at all.
Would it be possible to have the regular USB drivers support the slow
devices, if only to the extent of handing them off as they do CD, NIC, or
disk? Or are these slow devices so unique that they are totally
incompatible with faster devices?

> 
> -- Pete
> 

-- 
bill davidsen <davidsen@tmr.com>
  CTO, TMR Associates, Inc
Doing interesting things with little computers since 1979.

Re: 2.6.9 USB storage problems

[Pete Zaitcev]

On Thu, 4 Nov 2004 14:04:58 -0500 (EST), Bill Davidsen <davidsen@tmr.com> wrote:

> > I thought about the coexistence between the two at some length, and it seems
> > to me that the current scheme is the simplest workable scheme. I even thought
> > it as "least confusing" until messages from Wolfgang and others made it clear
> > that relationship between ub and usb-storage is not obvious enough to them.
> > I'm always open to patches, too.
> 
> It would seem that wanting to use both flash keys and more common USB
> devices would be the common case for those who use flash keys at all.
> Would it be possible to have the regular USB drivers support the slow
> devices, if only to the extent of handing them off as they do CD, NIC, or
> disk? Or are these slow devices so unique that they are totally
> incompatible with faster devices?

It's not a question of speed, in my view, but rather the protocol.
I have a patch by Peter Jones in my queue, which allows to burn CDs
with ub, for example. But splitting a whole protocol class is difficult.
It would be great to give DVDs to usb-storage and keep hard drives
and flash keys to ub, but I don't see a good way to accomplish that.

Again, if you come up with a patch which does inquiry and somehow
arranges who handles what, it may be a good thing. But it has to pass
a test of "not introducing too much complexity for too little gain".

I understand that I am setting a situation of two drivers doing similar
thing but not quite in the same way, just like in the bad old days
of uhci and usb-uhci. My current goal is to allow all users to have ub
configured at all times, if they want to. If it didn't fail devices like
Fabio's and if burned CDs, you'd never notice that something was different,
right? If this turns out unattainable, we can always remove ub from
the tree.

-- Pete