Re: LOR on em in HEAD ( was Re: em driver regression

From: Jack Vogel <jfvogel_at_gmail.com>
Date: Sat, 10 Apr 2010 17:09:01 -0700
What's disabled is the drbr stuff in the stack, that will not keep the 82574
from
initializing MSIX and multiple internal queues, if  you have that adapter I
would
suggest you #define EM_MULTIQUEUE somewhere (Makefile, if_em.h or if_em.c)
since I believe its the one place where you will benefit. At least try it
and see.

Jack


On Sat, Apr 10, 2010 at 3:07 PM, Mike Tancsa <mike_at_sentex.net> wrote:

> At 03:29 PM 4/10/2010, Jack Vogel wrote:
>
>> Added the missing locks around calls to rxeof and checked it in a minute
>> ago.
>>
>> Sorry guys!
>>
>
> Looks good for me now.  BTW, I thought the multi-queue was supposed to be
> disabled on the em nic ?
>
>
>
> em0: <Intel(R) PRO/1000 Network Connection 7.0.4> port 0x3040-0x305f mem
> 0xc1b00000-0xc1b1ffff,0xc1b25000-0xc1b25fff irq 20 at device 25.0 on pci0
> em0: Using MSI interrupt
> em0: [FILTER]
> em0: Ethernet address: 00:15:17:c8:4b:99
> em1: <Intel(R) PRO/1000 Network Connection 7.0.4> port 0x1000-0x101f mem
> 0xc1900000-0xc191ffff,0xc1920000-0xc1923fff irq 16 at device 0.0 on pci3
> em1: Using MSIX interrupts with 5 vectors
> em1: [ITHREAD]
> em1: [ITHREAD]
> em1: [ITHREAD]
> em1: [ITHREAD]
> em1: [ITHREAD]
> em1: Ethernet address: 00:15:17:c8:4b:98
>
> 0(i5b)% vmstat -i
> interrupt                          total       rate
> irq4: uart0                         6285         13
> irq21: ehci0                         728          1
> irq23: ehci1                        1078          2
> cpu0: timer                       924321       1992
> irq256: em0                         9375         20
> irq257: em1                          127          0
>
> irq258: em1                            7          0
> irq261: em1                            2          0
> irq262: ahci0                         69          0
> cpu3: timer                       923686       1990
> cpu1: timer                       923651       1990
> cpu2: timer                       923597       1990
> Total                            3712926       8001
>
> 0(i5b)%
>
> em0_at_pci0:0:25:0:        class=0x020000 card=0x34ec8086 chip=0x10ef8086
> rev=0x05 hdr=0x00
>    vendor     = 'Intel Corporation'
>    class      = network
>    subclass   = ethernet
>    cap 01[c8] = powerspec 2  supports D0 D3  current D0
>    cap 05[d0] = MSI supports 1 message, 64 bit enabled with 1 message
>    cap 13[e0] = PCI Advanced Features: FLR TP
>
> em1_at_pci0:3:0:0: class=0x020000 card=0x34ec8086 chip=0x10d38086 rev=0x00
> hdr=0x00
>    vendor     = 'Intel Corporation'
>    device     = 'Intel 82574L Gigabit Ethernet Controller (82574L)'
>    class      = network
>    subclass   = ethernet
>    cap 01[c8] = powerspec 2  supports D0 D3  current D0
>    cap 05[d0] = MSI supports 1 message, 64 bit
>    cap 10[e0] = PCI-Express 1 endpoint max data 128(256) link x1(x1)
>    cap 11[a0] = MSI-X supports 5 messages in map 0x1c enabled
>
>  Jack
>>
>>
>>
>> On Sat, Apr 10, 2010 at 9:05 AM, Bjoern A. Zeeb <<mailto:
>> bzeeb-lists_at_lists.zabbadoz.net>bzeeb-lists_at_lists.zabbadoz.net> wrote:
>> On Sat, 10 Apr 2010, Mike Tancsa wrote:
>>
>> Hi Mike,
>>
>>
>> At 05:11 PM 4/9/2010, Jack Vogel wrote:
>> Don't know, but I would just ignore it, I think its a false warning
>> anyway.
>>
>>
>> OK.  I updated to HEAD as of this AM, but now I get a panic at bootup
>>
>> ...
>>
>> Trying to mount root from nfs:
>> NFS ROOT: 10.255.255.1:/usr/home/pxe9/
>> panic: mutex em0:rx(0) not owned at
>> /usr/HEAD/src/sys/modules/em/../../dev/e1000/if_em.c:4093
>> cpuid = 3
>> KDB: enter: panic
>> [ thread pid 0 tid 100032 ]
>> Stopped at      kdb_enter+0x3a: movl    $0,kdb_why
>> db> bt
>> Tracing pid 0 tid 100032 td 0xc5f5bb40
>> kdb_enter(c0cb0e9d,c0cb0e9d,c0caf56e,c5b2ac28,3,...) at kdb_enter+0x3a
>> panic(c0caf56e,c6002024,c11a0357,ffd,c5b2ac7c,...) at panic+0x136
>> _mtx_assert(c6002010,4,c11a0357,ffd,64,...) at _mtx_assert+0x87
>> em_rxeof(246,c5ff7d98,c5b2aca8,c088e194,c5ff7d98,...) at em_rxeof+0x3b
>> em_handle_que(c6006000,1,c0cb5c9c,4f,c5ff7d98,...) at em_handle_que+0x38
>> taskqueue_run(c5ff7d80,c5ff7d98,c0ca6410,0,c0caf5f6,...) at
>> taskqueue_run+0x103
>> taskqueue_thread_loop(c600a520,c5b2ad38,c0cac192,343,c0e0ce20,...) at
>> taskqueue_thread_loop+0x68
>> fork_exit(c08dcde0,c600a520,c5b2ad38) at fork_exit+0xb8
>> fork_trampoline() at fork_trampoline+0x8
>> --- trap 0, eip = 0, esp = 0xc5b2ad70, ebp = 0 ---
>> db>
>>
>>
>>
>> This is a bug that seems to only happen in the Kitchener area as I hit
>> it with a machine there just a few minutes ago as well.
>>
>> This one has fixed it for me:
>> <http://lists.freebsd.org/pipermail/svn-src-head/2010-April/016249.html>
>> http://lists.freebsd.org/pipermail/svn-src-head/2010-April/016249.html
>>
>>
>> /bz
>>
>> --
>> Bjoern A. Zeeb         It will not break if you know what you are doing.
>>
>>
> --------------------------------------------------------------------
> Mike Tancsa,                                      tel +1 519 651 3400
> Sentex Communications,                            mike_at_sentex.net
> Providing Internet since 1994                    www.sentex.net
> Cambridge, Ontario Canada                         www.sentex.net/mike
>
>
Received on Sat Apr 10 2010 - 22:09:03 UTC

This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:40:02 UTC