Skip site navigation (1)Skip section navigation (2)
Date:      Sat, 5 Mar 2005 19:39:36 +0100
From:      Maxime Henrion <mux@FreeBSD.org>
To:        Randy Bush <randy@psg.com>
Cc:        freebsd-current@freebsd.org
Subject:   Re: fxp0 and vlan panic
Message-ID:  <20050305183936.GR31320@elvis.mu.org>
In-Reply-To: <16937.64632.277343.646373@roam.psg.com>
References:  <1107887237.793.26.camel@buffy.york.ac.uk> <20050226120253.O87543@ury.york.ac.uk> <20050305020343.GO31320@elvis.mu.org> <16937.62150.818165.837486@roam.psg.com> <20050305182751.GQ31320@elvis.mu.org> <16937.64632.277343.646373@roam.psg.com>

next in thread | previous in thread | raw e-mail | index | archive | help
Randy Bush wrote:
> >>> Just for the record, and for people not reading CVS commit logs, I
> >>> committed a fix for this a few days ago and I will make sure to MFC
> >>> it in time for 5.4-RELEASE.
> >> 
> >> might this give me some help on occasional but repeated fxp
> >> crashes under load?
> >> 
> >> Fatal trap 12: page fault while in kernel mode
> >> fault virtual address   = 0x80808517
> >> fault code              = supervisor read, page not present
> >> instruction pointer     = 0x8:0xc047d2d0
> >> stack pointer           = 0x10:0xd3f78c88
> >> frame pointer           = 0x10:0xd3f78cac
> >> code segment            = base 0x0, limit 0xfffff, type 0x1b
> >>                         = DPL 0, pres 1, def32 1, gran 1
> >> processor eflags        = interrupt enabled, resume, IOPL = 0
> >> current process         = 15 (irq5: fxp0)
> >> [thread pid 15 tid 100008 ]
> >> Stopped at      fxp_intr_body+0xd0:     cmpw    $0,0(%esi)
> >> db> trace
> >> Tracing pid 15 tid 100008 td 0xc155fb80
> >> fxp_intr_body(c161a000,c161a000,40,ffffffff,c0630cb6) at fxp_intr_body+0xd0
> >> fxp_intr(c161a000,0,0,0,0) at fxp_intr+0x141
> >> ithread_loop(c1551a00,d3f78d48,0,0,0) at ithread_loop+0x1a8
> >> fork_exit(c04da530,c1551a00,d3f78d48) at fork_exit+0x7f
> >> fork_trampoline() at fork_trampoline+0x8
> >> --- trap 0x1, eip = 0, esp = 0xd3f78d7c, ebp = 0 ---
> > 
> > It probably won't help with that.  Could I have you to get a system core
> > for this crash and show me precisely where this happens with gdb -k ?
> 
> i wish.  on most of my current systems lately, crashes don't leave
> cores :-(
> 
> savecore: no dumps found
> 
> yet
> 
> # grep crash /etc/rc.conf
> dumpdev="/dev/da0s1b"   # Device name to crashdump to (or NO).
> dumpdir="/var/crash"    # Directory where crash dumps are to be stored
> 
> # df 
> Filesystem  1024-blocks     Used    Avail Capacity  Mounted on
> /dev/da0s1a      257998    89306   148054    38%    /
> devfs                 1        1        0   100%    /dev
> /dev/da0s1e       64462      222    59084     0%    /root
> /dev/da0s1h    30829122 13978770 14384024    49%    /usr
> /dev/da0s1f     1032142    90670   858902    10%    /var
> /dev/da0s1g     1032142    93282   856290    10%    /var/spool
> procfs                4        4        0   100%    /proc
> /dev/md0          63214       10    58148     0%    /tmp
> 
> randy

Hmm, can you try to use addr2line(1) on your debug kernel then?

Cheers,
Maxime



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20050305183936.GR31320>