Subject: Re: USB reserve memory patch
To: Frank van der Linden <fvdl@NetBSD.org>
From: Steven M. Bellovin <smb@research.att.com>
List: port-i386
Date: 10/12/2004 09:27:52
In message <20041011212104.GA27999@vaasje.org>, Frank van der Linden writes:
>
>--6c2NcOVqGQ03X4Wi
>Content-Type: text/plain; charset=us-ascii
>Content-Disposition: inline
>
>I cooked up a patch that implements a workaround for runtime attachment
>of USB devices that need more than one page of contiguous memory, and
>have problems because memory is too fragmented at that point.
>
>The workaround is to have the host controller (ohci, uhci or ehci) set
>aside some contiguous memory at bootup, which is used should a USB
>allocation request failed later.
>
>The chunk of memory reserved is set via the USB_MEM_RESERVE option.
>Default is 256k.
>
>I tested this by forcing the plain allocation to fail for larger
>requests, so that it was forced to fall back to using the reserve.
>I plugged in a 250G external WD drive, used it, plugged in a USB
>floppy drive, used it, plugged them both out, plugged in the
>250G drive again, and used it again. They all used allocation
>buffers from the reserve (since I forced it), and it worked.
>
>The diff is attached. If you have a system where you had problems
>plugging in USB devices (umass, probably) after it had been up
>for a while, maybe you can try this patch. It's against -current,
>but I think it should apply for the 2.0 branch too.
>

Seems to be working on 2.0, though I'll have to test it more 
extensively.  Here are some kernel messages from using a USB flash 
disk, a USB floppy, and then the USB flash disk again:

umass0 at uhub0 port 1 configuration 1 interface 0
umass0: M-Systems DiskOnKey, rev 1.00/2.00, addr 2
umass0: using SCSI over Bulk-Only
uhci0: usb_reserve_allocm of size 65536 --> offs 0
scsibus0 at umass0: 2 targets, 1 lun per target
sd0 at scsibus0 target 0 lun 0: <M-Sys, DiskOnKey, 2.01> disk removable
sd0: fabricating a geometry
sd0: 31824 KB, 31 cyl, 64 head, 32 sec, 512 bytes/sect x 63648 sectors
sd0: fabricating a geometry
umass0: at uhub0 port 1 (addr 2) disconnected
sd0 detached
scsibus0 detached
uhci0: usb_reserve_freem offs 0 --> 0
umass0 detached
umass0 at uhub0 port 1 configuration 1 interface 0
umass0: TEAC TEAC FD-05PUB, rev 1.00/0.00, addr 2
umass0: using UFI over CBI with CCI
uhci0: usb_reserve_allocm of size 65536 --> offs 0
atapibus0 at umass0: 2 targets
sd0 at atapibus0 drive 0: <TEAC, FD-05PUB, 1026> disk removable
sd0: drive offline
umass0: at uhub0 port 1 (addr 2) disconnected
sd0 detached
atapibus0 detached
uhci0: usb_reserve_freem offs 0 --> 0
umass0 detached
umass0 at uhub0 port 1 configuration 1 interface 0
umass0: M-Systems DiskOnKey, rev 1.00/2.00, addr 2
umass0: using SCSI over Bulk-Only
uhci0: usb_reserve_allocm of size 65536 --> offs 0
scsibus0 at umass0: 2 targets, 1 lun per target
sd0 at scsibus0 target 0 lun 0: <M-Sys, DiskOnKey, 2.01> disk removable
sd0: fabricating a geometry
sd0: 31824 KB, 31 cyl, 64 head, 32 sec, 512 bytes/sect x 63648 sectors
sd0: fabricating a geometry
umass0: at uhub0 port 1 (addr 2) disconnected
sd0 detached
scsibus0 detached
uhci0: usb_reserve_freem offs 0 --> 0
umass0 detached


		--Steve Bellovin, http://www.research.att.com/~smb