NetBSD Problem Report #19803

Received: (qmail 4534 invoked by uid 605); 12 Jan 2003 03:22:01 -0000
Message-Id: <200301120321.h0C3LuL01376@pepper.my.domain>
Date: Sun, 12 Jan 2003 12:21:56 +0900 (JST)
From: toshii@netbsd.org
Sender: gnats-bugs-owner@netbsd.org
Reply-To: toshii@netbsd.org
To: gnats-bugs@gnats.netbsd.org
Subject: usbd_alloc_buffer fails often
X-Send-Pr-Version: 3.95

>Number:         19803
>Category:       kern
>Synopsis:       usbd_alloc_buffer fails often due to memory fragmentation
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    kern-bug-people
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Sun Jan 12 03:23:00 +0000 2003
>Closed-Date:    
>Last-Modified:  Tue Aug 06 08:39:23 +0000 2019
>Originator:     IWAMOTO Toshihiro
>Release:        NetBSD 1.6L
>Organization:

>Environment:
System: NetBSD pepper.my.domain 1.6L NetBSD 1.6L (PEPPER) #111: Sat Jan 11 00:53:18 JST 2003 root@pepper.my.domain:/sys/arch/i386/compile/PEPPER i386
Architecture: i386
Machine: i386
>Description:
	umass ATTACH and ulpt_do_write need to allocate some memory,
	but this fails often.  See kern/19326 for the umass case.
	For ulpt, write(2) returns ENOMEM.

>How-To-Repeat:
	Use enough memory (using X with gnome, emacs, mozilla... seems to
	be enough for my system (with 512M ram)) so that kernel memory
	allocation fails.
	Then plug a umass device or try to print something through ulpt.

	Then terminate mozilla to free some memory and try again. They
	should work.
>Fix:
	usbd_alloc_buffer calls ohci_allocm to allocate memory,
	which after all calls bus_dmamem_alloc(..., BUS_DMA_NOWAIT) in
	usb_block_allocmem.
	(This is my speculation and I haven't confirmed. Memory allocation
	 failures might be happening elsewhere.)

	I guess bus_dmamem_alloc with BUS_DMA_WAITOK would fix this problem,
	but doing this isn't trivial for me.
>Release-Note:
>Audit-Trail:

From: Dave Sainty <dave@dtsp.co.nz>
To: augustss@netbsd.org
Cc: dave@dtsp.co.nz, toshii@netbsd.org, gnats-bugs@gnats.netbsd.org
Subject: Re: kern/19803: usbd_alloc_buffer fails often 
Date: Mon, 13 Jan 2003 01:35:49 +1300

 toshii@netbsd.org writes:

 > 
 > >Number:         19803
 > >Category:       kern
 > >Synopsis:       usbd_alloc_buffer fails often
 > >Confidential:   no
 > >Severity:       serious
 > >Priority:       medium
 > >Responsible:    kern-bug-people
 > >State:          open
 > >Class:          sw-bug
 > >Submitter-Id:   net
 > >Arrival-Date:   Sat Jan 11 19:23:00 PST 2003
 > >Originator:     IWAMOTO Toshihiro
 > >Release:        NetBSD 1.6L
 > 	
 > >Description:
 > 	umass ATTACH and ulpt_do_write need to allocate some memory,
 > 	but this fails often.  See kern/19326 for the umass case.
 > 	For ulpt, write(2) returns ENOMEM.
 > 
 > >How-To-Repeat:
 > 	Use enough memory (using X with gnome, emacs, mozilla... seems to
 > 	be enough for my system (with 512M ram)) so that kernel memory
 > 	allocation fails.
 > 	Then plug a umass device or try to print something through ulpt.
 > 
 > 	Then terminate mozilla to free some memory and try again. They
 > 	should work.
 > >Fix:
 > 	usbd_alloc_buffer calls ohci_allocm to allocate memory,
 > 	which after all calls bus_dmamem_alloc(..., BUS_DMA_NOWAIT) in
 > 	usb_block_allocmem.
 > 	(This is my speculation and I haven't confirmed. Memory allocation
 > 	 failures might be happening elsewhere.)
 > 
 > 	I guess bus_dmamem_alloc with BUS_DMA_WAITOK would fix this problem,
 > 	but doing this isn't trivial for me.

 Hmmm, I was eyeing this up recently too.  Not that I've noticed it
 failing.  But I did notice that memory allocations would often be
 NOWAIT in the guts of the USB support, but called from places where it
 would be otherwise acceptable and more reasonable to wait.  I think I
 was looking at usbd_alloc_xfer(), where the same applies.

 I don't have any solutions, except the obvious API changing ones :)
State-Changed-From-To: open->closed
State-Changed-By: maya@NetBSD.org
State-Changed-When: Mon, 05 Aug 2019 22:13:36 +0000
State-Changed-Why:
This PR documents an issue but:
- Is stale, so likely to be ignored,
- Doesn't contain the right information.

This is likely a memory fragmentation issue. I am under the impression USB still uses
more contiguous memory than it absolutely has to, so perhaps we could use a reminder,
but this PR isn't a good reminder because it doesn't talk about it.

Memory fragmentation issues have come and gone in netbsd since the filing of this PR,
so perhaps things are better or worse now. It's unclear.



From: matthew green <mrg@eterna.com.au>
To: gnats-bugs@netbsd.org
Cc: kern-bug-people@netbsd.org, netbsd-bugs@netbsd.org,
    gnats-admin@netbsd.org, maya@NetBSD.org, toshii@netbsd.org
Subject: re: kern/19803 (usbd_alloc_buffer fails often)
Date: Tue, 06 Aug 2019 11:10:00 +1000

 > State-Changed-From-To: open->closed
 > State-Changed-By: maya@NetBSD.org
 > State-Changed-When: Mon, 05 Aug 2019 22:13:36 +0000
 > State-Changed-Why:
 > This PR documents an issue but:
 > - Is stale, so likely to be ignored,
 > - Doesn't contain the right information.
 > =

 > This is likely a memory fragmentation issue. I am under the impression U=
 SB still uses
 > more contiguous memory than it absolutely has to, so perhaps we could us=
 e a reminder,
 > but this PR isn't a good reminder because it doesn't talk about it.
 > =

 > Memory fragmentation issues have come and gone in netbsd since the filin=
 g of this PR,
 > so perhaps things are better or worse now. It's unclear.

 AFAICT, this problem is still 100% the same.

 now that your update talks about fragmentation, i think the
 PR has all the details it needs -- it certainly happens on
 a 64GB machine with a lot of free ram that was active in
 recent times.  enough concurrent 4095mb dd's ends up making
 it work again.

 unless the problem is documented in another PR, i think this
 one should be re-opened.


 .mrg.

From: Martin Husemann <martin@duskware.de>
To: matthew green <mrg@eterna.com.au>
Cc: gnats-bugs@netbsd.org
Subject: Re: kern/19803 (usbd_alloc_buffer fails often)
Date: Tue, 6 Aug 2019 08:16:04 +0200

 On Tue, Aug 06, 2019 at 11:10:00AM +1000, matthew green wrote:
 > now that your update talks about fragmentation, i think the
 > PR has all the details it needs

 Which usb host controllers could do S/G and which support it in NetBSD
 now? (my guess: all but ohci and none).

 Martin

State-Changed-From-To: closed->open
State-Changed-By: maya@NetBSD.org
State-Changed-When: Tue, 06 Aug 2019 08:39:23 +0000
State-Changed-Why:
Re-opening with additional context.


>Unformatted:

NetBSD Home
NetBSD PR Database Search

(Contact us) $NetBSD: query-full-pr,v 1.43 2018/01/16 07:36:43 maya Exp $
$NetBSD: gnats_config.sh,v 1.9 2014/08/02 14:16:04 spz Exp $
Copyright © 1994-2017 The NetBSD Foundation, Inc. ALL RIGHTS RESERVED.