Re: page fault in igb driver on 8.0-RC2

On Mon, Nov 09, 2009 at 05:15:44PM -0500, Mike Tancsa wrote:
> At 03:33 PM 11/9/2009, Mike Tancsa wrote:
> 
> 
> And with dcons connected for debugging, a clean RELENG_8 just checked 
> out, this comes up on the console when trying to bring up igb0 (igb1 
> works just fine)
> 
> GET BUF: dmamap load failure - 12
> GET BUF: dmamap load failure - 12
> GET BUF: dmamap load failure - 12
> GET BUF: dmamap load failure - 12
> GET BUF: dmamap load failure - 12
> GET BUF: dmamap load failure - 12
> GET BUF: dmamap load failure - 12
> GET BUF: dmamap load failure - 12
> 
> 
> Fatal trap 12: page fault while in kernel mode
> cpuid = 5; apic id = 05
> fault virtual address   = 0x10
> fault code              = supervisor write, page not present
> instruction pointer     = 0x20:0xc062838c
> stack pointer           = 0x28:0xe75f4c18
> frame pointer           = 0x28:0xe75f4c78
> 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         = 12 (irq257: igb0)
> [thread pid 12 tid 100046 ]
> Stopped at      igb_rxeof+0x1ec:        orl     $0x2,0x10(%esi)
> db> bt
> Tracing pid 12 tid 100046 td 0xc743a000
> igb_rxeof(c74ca1c0,5,5,c74ca240,c749a700,...) at igb_rxeof+0x1ec
> igb_msix_rx(c74a4b00,0,109,d40f8d68,aa,...) at igb_msix_rx+0x29
> intr_event_execute_handlers(c715f7f8,c749a700,c0c86d45,4f6,c749a770,...) 
> at intr_event_execute_handlers+0x14b
> ithread_loop(c74b0a00,e75f4d38,90a490a4,e8c3e8c3,176b176b,...) at 
> ithread_loop+0x6b
> fork_exit(c086b420,c74b0a00,e75f4d38) at fork_exit+0x91
> fork_trampoline() at fork_trampoline+0x8
> --- trap 0, eip = 0, esp = 0xe75f4d70, ebp = 0 ---
> db>
> 

Sorry Mike,
I haven't had time to fix the issue with igb(4). As you know I have
been fixing several bugs in bge(4). Most bugs(4) were fixed in my
local tree but one thing, poor Tx performance on PCIe controller
was not solved yet. At first I thought it could be side-effect of
newly added TSO feature written by me but stock bge(4) also showed
the same issue. The controller does not show poor performance if
TSO is used. But not all TCP traffic can make use TSO, bge(4) may
suffer from poor Tx performance. I still have no idea why it
happens. If I manage to fix that one I'll look into the igb(4)
issue.