Subject: kern/28362: need proper error recovery path for network drivers getting EAGAIN for DMA maps
To: None <kern-bug-people@netbsd.org, gnats-admin@netbsd.org,>
From: Greg A. Woods <woods@weird.com>
List: netbsd-bugs
Date: 11/19/2004 21:32:00
>Number: 28362
>Category: kern
>Synopsis: need proper error recovery path for network drivers getting EAGAIN for DMA maps
>Confidential: no
>Severity: non-critical
>Priority: low
>Responsible: kern-bug-people
>State: open
>Class: sw-bug
>Submitter-Id: net
>Arrival-Date: Fri Nov 19 21:32:00 +0000 2004
>Originator: Greg A. Woods
>Release: NetBSD
>Organization:
Planix, Inc.; Toronto, Ontario; Canada
>Environment:
System: NetBSD
>Description:
From a posting on 2004/11/18 to tech-kern & port-alpha by Jason Thorpe:
On Nov 18, 2004, at 11:40 AM, Greg A. Woods wrote:
>
> [console]<@> # ifconfig wm0 inet 205.207.148.230 up
> wm0: unable to load rx DMA map 1, error = 35
> panic: wm_add_rxbuf
> Stopped in pid 49.1 (ifconfig) at netbsd:cpu_Debugger+0x4: ret z
> ero,(ra)
> db> where
> No such command
> db> trace
> cpu_Debugger() at netbsd:cpu_Debugger+0x4
> panic() at netbsd:panic+0x1f8
> wm_add_rxbuf() at netbsd:wm_add_rxbuf+0x4dc
> wm_init() at netbsd:wm_init+0x490
> ether_ioctl() at netbsd:ether_ioctl+0xac
> wm_ioctl() at netbsd:wm_ioctl+0x90
> ifioctl() at netbsd:ifioctl+0x434
> soo_ioctl() at netbsd:soo_ioctl+0xf8
> sys_ioctl() at netbsd:sys_ioctl+0x12c
> syscall_plain() at netbsd:syscall_plain+0xc4
> XentSys() at netbsd:XentSys+0x5c
> --- syscall (54) ---
> --- user mode ---
> db>
EAGAIN -- insufficient resources for the request. This could
technically happen with any network interface, and this lack of error
recovery path is something I've often groaned about (especially since
I'm the one who wrote that code in ~every network driver :-)
send-pr it, please...
-- Jason R. Thorpe <thorpej@shagadelic.org>
>How-To-Repeat:
This particular problem seems to have been triggered by a buggy bge(4)
driver gobbling up all the resources and leaving none for wm0.
>Fix:
none supplied