NetBSD Problem Report #28362

From woods@building.weird.com  Fri Nov 19 21:31:25 2004
Return-Path: <woods@building.weird.com>
Received: from building.weird.com (building.weird.com [204.92.254.24])
	by narn.netbsd.org (Postfix) with ESMTP id AF9502525D1
	for <gnats-bugs@gnats.netbsd.org>; Fri, 19 Nov 2004 21:31:25 +0000 (UTC)
From: "Greg A. Woods" <woods@weird.com>
Reply-To: "Greg A. Woods" <woods@planix.com>
To: NetBSD GNATS submissions and followups <gnats-bugs@netbsd.org>
Subject: need proper error recovery path for network drivers getting EAGAIN for DMA maps
X-Send-Pr-Version: 3.95

>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:
X-Bogosity: No, tests=bogofilter, spamicity=0.000000, version=0.92.6

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

Home	PR Database Search