Subject: kern/25684: tlp0 driver for Davicom DM9102 hangs on some transfers
To: None <gnats-bugs@gnats.NetBSD.org>
From: None <danielfdickinson@yahoo.ca>
List: netbsd-bugs
Date: 05/23/2004 07:27:33
>Number: 25684
>Category: kern
>Synopsis: tlp0 driver for Davicom DM9102 hangs on some transfers
>Confidential: no
>Severity: serious
>Priority: high
>Responsible: kern-bug-people
>State: open
>Class: sw-bug
>Submitter-Id: net
>Arrival-Date: Sun May 23 07:28:00 UTC 2004
>Closed-Date:
>Last-Modified:
>Originator: Daniel Dickinson
>Release: NetBSD 2.0 BETA
>Organization:
>Environment:
NetBSD davor-netbsd 2.0_BETA NetBsd 2.0_BETA (GENERIC) #0: Sun May 16 02:57:38 EDT 2004 root@davor-netbsd:/usr/obj/sys/arch/i386/compiles/GENERIC i386
>Description:
This is for NetBSD 2.0_BETA (downloaded 2004-05-15)
I'm using a PC-Chips M599LMR Motherboard with an onboard
Davicom DM9102 (rh8 agrees with this) with DM9101 PHY (and
in parentheses dmesg reports AMD AM79C873; I'm not sure
about rh8) and attempting to transfer certain groups of
files causes the system to stop responding (no pretty
keyboard lights changing for caps lock et al, no hard drive
activity, no network activity, can't switch virtual
terminals, etc).
At first I thought it was the amount of traffic or nfs
since I was trying to do a cp -r of a large subtree on an
NFS server, however fmirror also hung the system although
at a different spot, and in another transfer an nfs
transfer hung the system on a particular file every time,
but switching to ftp made it work. Weird.
There are no log messages when this happens to guide me as
to what's wrong. Should I PR this and/or what other
information would it be helpful for me to send (if I can
find the file that was always failing would that help, or
is it likely site-specific?). I am more than willing to
help with the debug, but I don't know where to start, never
having dug into the NetBSD code before, and not even sure
what debug tools are available.
>How-To-Repeat:
1: Transfer a large subtree by cp -r (over nfs)
2: Attempt to cp over nfs the file that caused the hang in 1:
or
1: Transfer a large subtree using fmirror
>Fix:
>Release-Note:
>Audit-Trail:
>Unformatted: