I agree with both statements: that this is serious issues that
will affect many users; and that particularly since there are simple
work-arounds, the problem is not "critical" though is "serious" and
though it will probably cause a disproportionate amount of grief on
many users' parts, it is NOT and should not be sufficient justification
to hold-up the release of 2.0.

 	My comment of the subject was to reiterate that more than just
"umass" is affected AND in particular plugging in at or before boot is
NOT always a successful technique.  In fact, on the same machine, by
juggling USB ports, I can get either a "umass" or "ustir" to boot, the
second device attached will fail -- Yes, interchangeably - one device
will boot and one won't - i.e. exchanging ports exchanges the device's
behavior - sure seems like the same problem (that and the same function
call failing, in my mind, make this a single issue -- BTW.  Unplug both
"umass" and "ustir" devices and the USB keyboard, them the "ath2" attach
succeeds, again, seem to be the same problem - a deficit of contiguous
regions to allocate despite large amounts of free memory).

	Paul Shupak

>From port-i386-owner-track=Plectere.com@NetBSD.org Sun Oct 10 03:39:16 2004
>Delivered-To: port-i386@netbsd.org
>Subject: Re: My experience with the _RCs so far
>In-Reply-To: <200410101029.i9AATqCZ028902@Plectere.com>
>To: List Mail User <track@Plectere.com>
>Date: Sun, 10 Oct 2004 12:38:36 +0200 (CEST)
>Cc: khym@azeotrope.org, port-i386@NetBSD.org
>X-Mailer: ELM [version 2.4ME+ PL93 (25)]
>MIME-Version: 1.0
>Content-Transfer-Encoding: 7bit
>Content-Type: text/plain; charset=US-ASCII
>From: jdolecek@NetBSD.org (Jaromir Dolecek)
>Sender: port-i386-owner@NetBSD.org
>Precedence: list
>
>List Mail User wrote:
>> 	Both the "umass" and the "ustir" are USB devices, which both
>> misperform because a call to the function "usbd_alloc_buffer()" fails; UTSL.
>> The "ustir" is CERTAINLY the exact same failure mode as the "umass" driver.
>> 
>> 	Paul Shupak
>> 
>> P.S. And the Cardbus devices also fail with calls to allocate contiguous
>> physical memory (for DMA);  The problem is to be by no means confined just
>> the "umass" driver, but all affects devices requiring contiguous physical
>> memory buffers that span multiple pages.
>
>Indeed. This problem is on must-fix problem list for NetBSD 3.0.
>If the fix would not involve huge structural changes, I imagine
>it might appear even in some 2.x patch release. However, it would
>not hold the 2.0 release.
>
>Jaromir 
>-- 
>Jaromir Dolecek <jdolecek@NetBSD.org>            http://www.NetBSD.cz/
>-=- We should be mindful of the potential goal, but as the Buddhist -=-
>-=- masters say, ``You may notice during meditation that you        -=-
>-=- sometimes levitate or glow.   Do not let this distract you.''   -=-
>