Panic in RELENG_7_1 with fxp(4)

[Brandon Weisz]

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.

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
>  > 
> 
> [...]
>