Luigi Rizzo wrote:
> interesting dump... because it shows a bogus "length"
> parameter passed to ed_pio_readmem().
Bosko and I were discussing my problem offline a couple of weeks ago,
and in the course of a single morning I managed to create about 15
crashes. A couple of them were just like this latest one -- in
ed_pio_readmem() -- but most of the others were in rl_encap(),
which was called via a chain including rl_start(), bdg_forward(),
ether_input(), and ed_get_packet().
It looks, to me, like some sort of data corruption that is causing
a crash later on (but not immediately). And, as I reported earlier,
these crashes went away completely after I commented out the bridge-
specific code in if_ed.c (per a suggestion from Bosko).
I don't have crash dumps from those earlier crashes -- I was (and
still am) having unresolved problems getting the system to copy a
crash dump into swap space automatically after a panic, and I hadn't
yet hit upon the kludge of typing "call dumpsys" at the DDB prompt
-- but I did write down some tracing info from DDB for the earlier
crashes. See below for what I have; please understand that this is
all I have.
> Can you by chance find out what is the "len" value passed
> to ed_get_packet? The printout in line #10 below is par-
> tially deleted by some error message.
Sure. I did "up 10", followed by "print len", and the value of this
parameter was reported as 10.
> Now, NE2000 clones if you look at the driver are known
> for occasionally swapping the bytes of the length, but
> the driver was supposed to take care of this. Evidently
> there is some odd thing...
Please note that I've tried two different NE2000 clone cards -- one
ISA, one PCI -- and I got the same kinds of crashes from both. (The
crash I described last night was with the PCI card.)
Also, as I said, these crashes went away completely after I commented
out the BRIDGE-specific code in if_ed.c, per Bosko's recommendation.
I'm willing to agree with Bosko that leaving out this code is a tem-
porary workaround, and not a true fix -- but do you think it might be
possible to take it out in -STABLE for now, until the problem is found?
Rich Wales [EMAIL PROTECTED] http://www.webcom.com/richw/
========================================================================
(5 times)
Fatal trap 12: page fault while in kernel mode
rl_encap + 0x120
rl_start + 0x23
bdg_forward + 0x468
ether_input + 0x7b
ed_get_packet + 0x3b8
edintr + 0x5af
Xresume5 + 0x2b
(4 times)
Fatal trap 12: page fault while in kernel mode
rl_encap + 0x78
rl_start + 0x23
bdg_forward + 0x468
ether_input + 0x7b
ed_get_packet + 0x3b8
edintr + 0x5af
Xresume5 + 0x2b
(2 times)
Fatal trap 12: page fault while in kernel mode
rl_encap + 0x117
rl_start + 0x23
bdg_forward + 0x468
ether_input + 0x7b
ed_get_packet + 0x3b8
edintr + 0x5af
Xresume5 + 0x2b
(2 times)
Fatal trap 12: page fault while in kernel mode
ed_pio_readmem + 0x161
ed_get_packet + 0x393
edintr + 0x5af
Xresume5 + 0x2b
(1 time)
Fatal trap 12: page fault while in kernel mode
bpf_mtap + 0x18
ether_input + 0x2f
pcn_rxeof + 0xe1
pcn_intr + 0x8a
Xresume9 + 0x2b
(1 time)
Fatal trap 12: page fault while in kernel mode
(DDB went into endless loop)
========================================================================
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-net" in the body of the message
