Return to BSD News archive
Xref: sserve comp.os.386bsd.questions:2464 comp.os.386bsd.bugs:753
Path: sserve!newshost.anu.edu.au!munnari.oz.au!spool.mu.edu!howland.reston.ans.net!usenet.ins.cwru.edu!lerc.nasa.gov!eagle!mikef
From: mikef@sarah.lerc.nasa.gov (Mike J. Fuller)
Newsgroups: comp.os.386bsd.questions,comp.os.386bsd.bugs
Subject: [NetBSD] 3Com ethernet problems, misc bugs, and debugging kernels
Date: 16 May 1993 20:50:20 GMT
Organization: Computational Materials Laboratory, NASA Lewis Research Center
Lines: 98
Distribution: world
Message-ID: <1t69ec$bau@eagle.lerc.nasa.gov>
Reply-To: mikef@polymer.uakron.edu
NNTP-Posting-Host: sarah.lerc.nasa.gov
X-Newsreader: GNU Emacs 18.58.2, GNUS 3.14.1, NNTP 3.10
Hey folks, I've got a real strange problem and some minor bug reports.
First off, the system: AT&T 6386/SX WGS running NetBSD 0.8, 8Mb memory, 450
Mb IDE drive, VGA, 1 parallel & 2 serial ports (all currently disabled), and
a 3Com 3C503-16-TP ethernet card. Basically, the "real strange problem" is
that the system panics whenever I throw some heavy network traffic at it
(ftp, rcp, tar | rsh, etc.). The two panics that I was able to write down
went something like this:
vm_fault (fe0ea000, fe714000, 3, 0) -> 1
type c, code 2
trap type 12 code = 2 eip = fe000815 cs = 8
eflags = 10686 cr2 fe715ffe cpl 0
panic: trap
updating disks before rebooting...
and
vm_fault (fe0ea000, fe715000, 3, 0) -> 1
type c, code fe060002
trap type 12 code = fe060002 eip = fe000806 cs = 8
eflags = 10696 cr2 fe714ced cpl 200
panic: trap
updating disks before rebooting...
Both of those times, it failed to do a crash dump and reboot. Does anybody
know what the addresses and codes correspond to? Better yet, does anybody
have an idea of how to fix this problem? One time (out of about 8) that it
crashed, it did complete the crash dump, so I did a savecore and tried to
analyze it, but gdb complained about there being no debug symbols in the
kernel. :-(
I have tried various IRQ, memory, and port settings on the card to no avail,
as well and the 8/16 bit modes. Yes, the card does pass 3Com's diagnostics.
It really bugs me because I had been using a Western Digital card (which I
borrowed from a friend and had to return) that worked flawlessly for over a
week. I really beat on the machine with network traffic of all sorts
(multiple ftp's, remote backups, etc.), and it never once so much as burped.
From looking around on the net, it looks like the if_ec sources are the same
for NetBSD and 386BSD, and neither have been changed in a while.
In the course of looking into the problem, I couldn't help but notice a few
"annoyances" with the driver. For example, putting a newline in the
following printf() in ecattach():
/*
* Weeee.. We get to tell people we exist...
*/
printf(" address %s\n", ether_sprintf(sc->ec_addr));
keeps the address message from running into npx0's probe message on bootup.
Similarly, I commented out the following message in ec_init() because I did
not find it to be very informative:
printf("ecinit");
I also found that sc->ec_if.if_ipackets never gets incremented (therefore,
the number of input packets given by netstat -i remains constant). I would
fix that myself, but I'm not sure what the "right place" to do it is. Also,
a friend of mine who runs 386BSD and has a 3Com card claims that the:
/*
* XXX (untested)
* select thick (e.g. AUI connector) if LLC0 bit is set
*/
code doesn't work, which forces anyone who wants to use the AUI port on a
3Com card to have to hard-code it in the driver (I'm using the 10Base-T port
on mine, so I didn't have to change it).
Another problem: if I login on the console, start something in the
background (like make), and then log out, every subsequent login on the
console results in:
Warning: no access to tty (Inappropriate ioctl for device)
Thus no job control in this shell.
Needless to say, it's real annoying.
Lastly, does anybody know how to build a debugging kernel? I've tried doing
a "config -g" (which should work, according to the man page for config) and
adding "options DEBUG" to my kernel conf file, both without any results
(i.e., I still get "couldn't find db_symtab symbols" after "rearranging
symbols" at the end of the make). Just for the heck of it, I tried manually
adding a "-g" to CFLAGS in the Makefile, but instead of "couldn't find
db_symtab symbols", I got something about "out of memory" (not likely -- I
have 50Mb of swap space).
Any fixes/suggestions for any of the above problems?
Thanks in advance...
Mike
/-----------------------------------------------------------------------------\
| Mike J. Fuller | Internet: mikef@sarah.lerc.nasa.gov | "I hate |
|----------------| mikef@zippysun.math.uakron.edu | quotations." |
|/\/\/\/\/\/\/\/\| Bitnet: r2mjf@akronvm | -- R.W. Emerson |
\-----------------------------------------------------------------------------/