Panic in RELENG_7_1 with fxp(4)

Wed Jan 7 13:22:24 UTC 2009

Pyun YongHyeon wrote:
> On Tue, Jan 06, 2009 at 09:23:01AM -0600, Brandon Weisz wrote:
>  > Pyun YongHyeon wrote:
>  > >On Mon, Jan 05, 2009 at 06:19:26AM -0600, Brandon Weisz wrote:
>  > > > Pyun YongHyeon wrote:
>  > > > >On Sat, Jan 03, 2009 at 10:16:58PM -0800, Garrett Cooper wrote:
>  > > > > > On Jan 3, 2009, at 5:17 PM, Brandon Weisz wrote:
>  > > > > > 
>  > > > > > >After running 7-PRERELEASE from around November 25th, I upgraded  
>  > > > > > >today to find the system panics repeatably on RELENG_7_1 sources.  
>  > > I  > > > >can boot back to the old kernel and it operates as expected.  
>  > > It  > > > >seems to be related to fxp(4).
>  > > > > > >
>  > > > > > >FreeBSD didy.internal 7.1-RELEASE FreeBSD 7.1-RELEASE #0: Sat Jan  
>  > > 3
>  > > > > > >18:11:18 CST 2009     bweisz at didy.internal:/usr/obj/usr/src/sys/ 
>  > > > > > >DIDY  i386
>  > > > > > >
>  > > > 
>  > > > ....
>  > > > 
>  > > > > > >
>  > > > > > >I replaced the fxp(4) card with an old xl(4) card lying on my desk 
>  > > > > > >and the panics stopped.  Is this a failing nic card or some other  
>  > > > > > >trigger?
>  > > > > > >
>  > > > > > >Brandon
>  > > > > > 
>  > > > > > Memory serves me correctly an MFC was done not too long before 7.1  
>  > > > > > release was setup.
>  > > > > > 
>  > > > >
>  > > > >I don't know what MFCes were done, at least I didn't MFC any
>  > > > >changes I made.
>  > > > >
>  > > > > > Let's see what Pyun says...
>  > > > > > 
>  > > > >
>  > > > >I'm not sure what is root cause of this panic. If you can reliably
>  > > > >reproduce the panic would you let me know?
>  > > > >CURRENT has a couple of fixes for edge-cases as well as some new
>  > > > >hardware features(TSO, VLAN hardware tagging and WOL etc). Would
>  > > > >you try latest fxp(4) in HEAD?
>  > > > >I think you can use cvsweb interface to get latest files.
>  > > > >http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/dev/fxp/if_fxp.c
>  > > > >http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/dev/fxp/if_fxpreg.h
>  > > > >http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/dev/fxp/if_fxpvar.h
>  > > > >
>  > > > 
>  > > > Hi Pyun
>  > > > 
>  > > > The system reliably panics on boot up.  I tested fxp from HEAD with the 
>  > > > same result.
>  > > > 
>  > > > 7.1-RELEASE = Panic
>  > > > 7.1-RELEASE with fxp from HEAD = Panic
>  > > > 7.1-PRERELEASE from Tue Nov 25 = operates as expected
>  > > > 
>  > > > This is an old card.  Some details on the card:
>  > > > 
>  > > > fxp0: <Intel 82559 Pro/100 Ethernet> port 0xd100-0xd13f mem 
>  > > > 0xfca03000-0xfca03fff,0xfc800000-0xfc8fffff irq 17 at device 9.0 on pci0
>  > > > miibus0: <MII bus> on fxp0
>  > > > inphy0: <i82555 10/100 media interface> PHY 1 on miibus0
>  > > > inphy0:  10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto
>  > > > fxp0: Ethernet address: 00:d0:b7:6c:1c:0a
>  > > > fxp0: [ITHREAD]
>  > > > 
>  > > > fxp0 at pci0:0:9:0:	class=0x020000 card=0x000b8086 chip=0x12298086 
>  > > > rev=0x08 hdr=0x00
>  > > >     vendor     = 'Intel Corporation'
>  > > >     device     = '82550/1/7/8/9 EtherExpress PRO/100(B) Ethernet 
>  > > Adapter'
>  > > >     class      = network
>  > > >     subclass   = ethernet
>  > > > 
>  > > > As a test, I unplugged the ethernet cable and the system booted fully, 
>  > > > however it produced a panic as soon as I connected the cable.  This 
>  > > > backtrace is from 7.1-RELEASE with fxp sources from HEAD.
>  > > > 
>  > >
>  > >I still can't reproduce this but would you try fxp(4) in the
>  > >following URLs?
>  > >http://people.freebsd.org/~yongari/fxp/if_fxp.c
>  > >http://people.freebsd.org/~yongari/fxp/if_fxpreg.h
>  > >http://people.freebsd.org/~yongari/fxp/if_fxpvar.h
>  > >
>  > 
>  > With this version, the system still panics as before.
>  > 
> 
> I think the panic message you posted below is not related with
> fxp(4). Show me panic message for fxp(4), that would be more 
> helpful to narrow down possible cause of issue.
> BTW, are you using non-standard compilation flag or customized
> kernel? Since there are lot of systems that still rely on fxp(4)
> I wonder how this issue is not reported yet.
> Did GENERIC kernel also show exact the same behaviour?

The system still panics with the fxp card installed, as seen below. 
While I agree this panic looks different, taking out the fxp card and 
replacing it with xl(4) card stopped the panic.  I can also stop the 
panic and use the fxp card with the old kernel from Nov 25.

I'm not using any compiler flags in make.conf or src.conf.  I am using a 
  somewhat custom kernel:

include 	GENERIC
ident		DIDY

# Changes and additions
options         SC_PIXEL_MODE
options 	SC_HISTORY_SIZE=8192

options         ALTQ
options         ALTQ_CBQ
options         ALTQ_RED
options         ALTQ_RIO
options         ALTQ_HFSC
options         ALTQ_CDNR
options         ALTQ_PRIQ

#options 	KVA_PAGES=512

device		puc

I'll give GENERIC a go and see if that makes any difference.

> 
>  > After the system panic with this patch, I went into the bios and 
>  > disabled all unnecessary hardware such as parallel port, usb controller 
>  > and on-board audio.  The resulting panic below appears different.
>  > 
>  > Fatal trap 12: page fault while in kernel mode
>  > cpuid = 0; apic id = 00
>  > fault virtual address	= 0x400
>  > fault code		= supervisor read, page not present
>  > instruction pointer	= 0x20:0xc07eefec
>  > stack pointer	        = 0x28:0xe4339ac0
>  > frame pointer	        = 0x28:0xe4339ae4
>  > 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		= 28 (irq23: vr0)
>  > trap number		= 12
>  > panic: page fault
>  > cpuid = 0
>  > Uptime: 50s
>  > Physical memory: 995 MB
>  > Dumping 162 MB: 147 131 115 99 83 67 51 35 19 3
>  > 
> 
> [...]
> 