I haven't done a PR because the issue is clearly identical.
But...
	"SigmaTel Inc  IrDA/USB Bridge, rev 1.10/0.00"

acts identically (I use "dd if=/dev/zero of=/dev/null bs=8m count=10",
to workaround - lower values of 'count' don't always work; count == 1
is about 50/50;  Unplug the device, "dd", then plug in and it works!)

	This problem can even occur during boot (on a machine with 1.5G
of RAM) -- There MUST be some simple solution, but I've just been using
the "dd" trick and haven't looked at the code (BTW, I've NOT seen the problem
on 1.6[A-K] machines with the same of similar configurations).

	Also, any Cardbus card with DMA buffers will likely also show
the problem.  I can repeatably cause it with a Netgear 511T, SMC2335W,
or Proxim cards (NOTE: the all use the "ath" driver).  Same "dd" workaround
applies.


	Paul Shupak
	track@plectere.com

P.S.  I'd bet every hotswapable device which allocates any buffer of
contiguous physical memory greater then a single page can cause the
problem (e.g. USB, CardBus/PCMIA, firewire and even SATA disk-drives).
Say even odds - upto $100 or so -- Any takers?


>From port-i386-owner-track=Plectere.com@NetBSD.org Wed Oct  6 11:54:49 2004
>Delivered-To: port-i386@netbsd.org
>X-Mailer: exmh version 2.3.1 03/08/2001 with nmh-1.0.4
>To: port-i386@NetBSD.org
>Subject: Re: My experience with the _RCs so far 
>In-Reply-To: Message from mlelstv@serpens.de (Michael van Elst) 
>   of "Wed, 06 Oct 2004 18:27:01 GMT." <ck1ddl$a5b$1@serpens.de> 
>Mime-Version: 1.0
>Content-Type: text/plain; charset=us-ascii
>Date: Wed, 06 Oct 2004 13:53:53 -0500
>From: Chapman Flack <flack@cerias.purdue.edu>
>X-Scanned-By: MIMEDefang 2.43
>Sender: port-i386-owner@NetBSD.org
>Precedence: list
>
>Michael van Elst wrote:
>> The umass driver requires a big chunk of memory while the hardware
>> could live with fragmented memory. When this is fixed the problem
>> goes away.
>
>It isn't just a problem for umass; it potentially affects any of the sorts
>of devices that can be plugged in and attached after boot time, if their
>drivers request contiguous memory.  I ran into it with a Cardbus NIC on a
>laptop.  The general problem, as I understood it, is when the kernel needs
>to allocate some contiguous memory and there are user processes that have
>some pages in the way, the memory manager needs to kick them out.  (They can
>always be paged back in.)  It just doesn't do that yet.  The complications
>are how to arrange for the kicking-out to be fast enough that things like
>drivers can safely do allocation without having to be reschedulable, and
>some ideas for that have been floated recently on tech-kern.  Solving the
>general problem would reduce the pressure for a bunch of device-specific
>workarounds.
>
>-Chap
>