Subject: port-i386/18499: fxp driver device timeout and panic on i386
To: None <gnats-bugs@gnats.netbsd.org>
From: Atsushi Onoe <onoe@sm.sony.co.jp>
List: netbsd-bugs
Date: 10/02/2002 19:27:00
>Number:         18499
>Category:       port-i386
>Synopsis:       fxp driver timeout and panic on i386
>Confidential:   no
>Severity:       critical
>Priority:       high
>Responsible:    port-i386-maintainer
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Wed Oct 02 03:36:00 PDT 2002
>Closed-Date:
>Last-Modified:
>Originator:     Atsushi Onoe
>Release:        NetBSD 1.6I
>Organization:
	Sony Corporation
>Environment:
	Note PC with internal fxp interface (815 chipset)
System: NetBSD nest.sm.sony.co.jp 1.6I NetBSD 1.6I (NEST) #247: Wed Oct 2 18:53:45 JST 2002 onoe@nest.sm.sony.co.jp:/work/netbsd/obj/NEST i386
Architecture: i386
Machine: i386
	The config file is based on GENERIC_LAPTOP slightly modified.
	Of course, MULTIPROCESSOR is NOT defined.
>Description:
	Some simultenous tcp connections for downloading images by w3m-img
	cause device timeout for fxp driver.  Sometimes it get panic by
	referencing null pointer within the bpf, which is opened by dhclient.

	After putting some printf into the driver, fxp_start() is re-entered
	while running.  The position of previous function looks random
	by assigning line number to static variable at several place.

	I'm not sure similar problem occurs for other drivers.  I'm pretty
	sure the problem is not seen until yesterday, so I doubt i386mp
	merge delivers interrupt within splnet.
>How-To-Repeat:
	Just viewing http://www.ietf.org and click any link within it
	by w3m-img through fxp driver.
	The problem can be reproduced before 5-times to try on my
	environment.
>Fix:
	not provided.
>Release-Note:
>Audit-Trail:
>Unformatted:
 	Current source as of 2 Oct 08:00 UTC 2002