Panic in RELENG_7_1 with fxp(4)

Pyun YongHyeon pyunyh at gmail.com
Thu Jan 8 01:19:26 UTC 2009


On Wed, Jan 07, 2009 at 10:08:36AM -0600, Brandon Weisz wrote:
 > Pyun YongHyeon wrote:
 > 
 > ....
 > 
 > >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?
 > >
 > 
 > Hi Pyun,
 > 
 > As suggested, the GENERIC kernel did not panic.  After a few more tests, 
 > the culprit appears to be:
 > 
 > device		puc
 > 
 > With puc(4) removed, the system is running on 7.1-RELEASE kernel with 
 > the fxp(4) card operating as expected.  For now I'll be shelving the 
 > cheap pci serial card.
 > 
 > If anyone wishes to investigate this further I'm happy to continue testing.
 > 

Hmm, I still have no idea how puc(4) can trigger the issue.
Marcel may have more idea how to debug this(CCed).

 > Thank you very much for your help.
 > 
 > Brandon
 > 
 > 
 > > > 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
 > > > 
 > >
 > >[...]
 > >
 > 

-- 
Regards,
Pyun YongHyeon


More information about the freebsd-stable mailing list