subject:"RELENG_7 em problems \(and RELENG

Re: RELENG_7 em problems (and RELENG_8)

2010-07-02 Thread Mike Tancsa


Hi Jack,
Just a followup to the email below. I now saw what appears 
to be the same problem on RELENG_8, but on a different nic and with 
VLANs.  So not sure if this is a general em problem, a problem 
specific to some em NICs, or a TSO problem in general.  The issue 
seemed to be triggered when I added a new vlan based on


e...@pci0:14:0:0:class=0x02 card=0x109a15d9 
chip=0x109a8086 rev=0x00 hdr=0x00

vendor = 'Intel Corporation'
device = 'Intel PRO/1000 PL Network Adaptor (82573L)'
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 10[e0] = PCI-Express 1 endpoint max data 128(256) link x1(x1)

pci14:  on pcib5
em3:  port 0x6000-0x601f 
mem 0xe830-0xe831 irq 17 at device 0.0 on pci14

em3: Using MSI interrupt
em3: [FILTER]
em3: Ethernet address: 00:30:48:9f:eb:81

em3: flags=8943 
metric 0 mtu 1500

options=2098
ether 00:30:48:9f:eb:81
inet 10.255.255.254 netmask 0xfffc broadcast 10.255.255.255
media: Ethernet autoselect (1000baseT )
status: active

I had to disable tso, rxcsum and txsum in order to see the devices on 
the other side of the two vlans trunked off em3.  Unfortunately, the 
other sides were switches 100km and 500km away so I didnt have any 
tcpdump capabilities to diagnose the issue.  I had already created 
one vlan off this NIC and all was fine.  A few weeks later, I added a 
new one and I could no longer telnet into the remote switches from 
the local machine But, I could telnet into the switches from 
machines not on the problem box. Hence, it would appear to be a 
general TSO issue no ? I disabled tso on the nic (I didnt disable 
net.inet.tcp.tso as I forgot about that).. Still nothing. I could 
always ping the remote devices, but no tcp services.  I then 
remembered this issue from before, so I tried disabling tso on the 
NIC. Still nothing. Then I disabled rxcsum and txcsum and I could 
then telnet into the remote devices.


This newly observed issue was from a buildworld on Mon Jun 14 
11:29:12 EDT 2010.


I will try and recreate the issue locally again to see if I can 
trigger the problem on demand.  Any thoughts on what it might be ? 
Perhaps an issue specific to certain em nics ?


---Mike


At 04:31 PM 6/10/2010, Mike Tancsa wrote:

Hi Jack,
I am seeing some issues on RELENG_7 with a specific em nic

e...@pci0:13:0:0:class=0x02 card=0x108c15d9 
chip=0x108c8086 rev=0x03 hdr=0x00

vendor = 'Intel Corporation'
device = 'Intel Corporation 82573E Gigabit Ethernet 
Controller (Copper) (82573E)'

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 10[e0] = PCI-Express 1 endpoint max data 128(256) link x1(x1)

If I disable tso, I am not able to make a tcp connection into the host

eg
0[psbgate1]# ifconfig em2
em2: flags=8843 metric 0 mtu 1500

options=219b
ether 00:30:48:9f:eb:80
inet 192.168.128.200 netmask 0xfff0 broadcast 192.168.128.207
media: Ethernet autoselect (100baseTX )
status: active
0[psbgate1]# ifconfig em2 -tso
0[psbgate1]#


Looking at the pcap, the checksum is bad on the syn-ack.  If I 
re-enable tso, it seems to be ok


16:18:01.113297 IP (tos 0x10, ttl 64, id 6339, offset 0, flags [DF], 
proto TCP (6), length 60) 192.168.128.196.54172 > 
192.168.128.200.22: S, cksum 0x4e79 (correct), 
3313156149:3313156149(0) win 65535 3,sackOK,timestamp 3376174416 0>
16:18:01.123676 IP (tos 0x0, ttl 64, id 3311, offset 0, flags [DF], 
proto TCP (6), length 60) 192.168.128.200.22 > 
192.168.128.196.54172: S, cksum 0x81c9 (incorrect (-> 0x51f2), 
1373042663:1373042663(0) ack 3313156150 win 65535 1460,nop,wscale 3,sackOK,timestamp 1251567646 3376174416>



em2:  port 0x5000-0x501f 
mem 0xe820-0xe821 irq 16 at device 0.0 on pci13

em2: Using MSI interrupt
em2: [FILTER]
em2: Ethernet address: 00:30:48:9f:eb:80
pcib5:  irq 16 at device 28.5 on pci0
pci14:  on pcib5
em3:  port 0x6000-0x601f 
mem 0xe830-0xe831 irq 17 at device 0.0 on pci14

em3: Using MSI interrupt
em3: [FILTER]
em3: Ethernet address: 00:30:48:9f:eb:81


Also there is still the issue with

http://lists.freebsd.org/pipermail/freebsd-stable/2009-November/052842.html

in RELENG_7 ?

---Mike



Mike Tancsa,  tel +1 519 651 3400
Sentex Communications,m...@sentex.net
Providing Internet since 1994www.sentex.net
Cambridge, Ontario Canada www.sentex.net/mike

___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To

Re: RELENG_7 em problems (and RELENG_8)

2010-07-02 Thread Jack Vogel

I got the email,  there are server outages around here today and people
leaving
for a long weekend, so not much getting done. I'll take some time and look
into
this after the weekend, ok?

Jack


On Fri, Jul 2, 2010 at 10:39 AM, Mike Tancsa  wrote:

> Hi Jack,
>Just a followup to the email below. I now saw what appears to be the
> same problem on RELENG_8, but on a different nic and with VLANs.  So not
> sure if this is a general em problem, a problem specific to some em NICs, or
> a TSO problem in general.  The issue seemed to be triggered when I added a
> new vlan based on
>
> e...@pci0:14:0:0:class=0x02 card=0x109a15d9 chip=0x109a8086
> rev=0x00 hdr=0x00
>vendor = 'Intel Corporation'
>device = 'Intel PRO/1000 PL Network Adaptor (82573L)'
>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 10[e0] = PCI-Express 1 endpoint max data 128(256) link x1(x1)
>
> pci14:  on pcib5
> em3:  port 0x6000-0x601f mem
> 0xe830-0xe831 irq 17 at device 0.0 on pci14
> em3: Using MSI interrupt
> em3: [FILTER]
> em3: Ethernet address: 00:30:48:9f:eb:81
>
> em3: flags=8943 metric 0
> mtu 1500
>options=2098
>ether 00:30:48:9f:eb:81
>inet 10.255.255.254 netmask 0xfffc broadcast 10.255.255.255
>media: Ethernet autoselect (1000baseT )
>status: active
>
> I had to disable tso, rxcsum and txsum in order to see the devices on the
> other side of the two vlans trunked off em3.  Unfortunately, the other sides
> were switches 100km and 500km away so I didnt have any tcpdump capabilities
> to diagnose the issue.  I had already created one vlan off this NIC and all
> was fine.  A few weeks later, I added a new one and I could no longer telnet
> into the remote switches from the local machine But, I could telnet into
> the switches from machines not on the problem box. Hence, it would appear to
> be a general TSO issue no ? I disabled tso on the nic (I didnt disable
> net.inet.tcp.tso as I forgot about that).. Still nothing. I could always
> ping the remote devices, but no tcp services.  I then remembered this issue
> from before, so I tried disabling tso on the NIC. Still nothing. Then I
> disabled rxcsum and txcsum and I could then telnet into the remote devices.
>
> This newly observed issue was from a buildworld on Mon Jun 14 11:29:12 EDT
> 2010.
>
> I will try and recreate the issue locally again to see if I can trigger the
> problem on demand.  Any thoughts on what it might be ? Perhaps an issue
> specific to certain em nics ?
>
>---Mike
>
>
> At 04:31 PM 6/10/2010, Mike Tancsa wrote:
>
>> Hi Jack,
>>I am seeing some issues on RELENG_7 with a specific em nic
>>
>> e...@pci0:13:0:0:class=0x02 card=0x108c15d9 chip=0x108c8086
>> rev=0x03 hdr=0x00
>>vendor = 'Intel Corporation'
>>device = 'Intel Corporation 82573E Gigabit Ethernet Controller
>> (Copper) (82573E)'
>>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 10[e0] = PCI-Express 1 endpoint max data 128(256) link x1(x1)
>>
>> If I disable tso, I am not able to make a tcp connection into the host
>>
>> eg
>> 0[psbgate1]# ifconfig em2
>> em2: flags=8843 metric 0 mtu 1500
>>
>>
>> options=219b
>>ether 00:30:48:9f:eb:80
>>inet 192.168.128.200 netmask 0xfff0 broadcast 192.168.128.207
>>media: Ethernet autoselect (100baseTX )
>>status: active
>> 0[psbgate1]# ifconfig em2 -tso
>> 0[psbgate1]#
>>
>>
>> Looking at the pcap, the checksum is bad on the syn-ack.  If I re-enable
>> tso, it seems to be ok
>>
>> 16:18:01.113297 IP (tos 0x10, ttl 64, id 6339, offset 0, flags [DF], proto
>> TCP (6), length 60) 192.168.128.196.54172 > 192.168.128.200.22: S, cksum
>> 0x4e79 (correct), 3313156149:3313156149(0) win 65535 > 3,sackOK,timestamp 3376174416 0>
>> 16:18:01.123676 IP (tos 0x0, ttl 64, id 3311, offset 0, flags [DF], proto
>> TCP (6), length 60) 192.168.128.200.22 > 192.168.128.196.54172: S, cksum
>> 0x81c9 (incorrect (-> 0x51f2), 1373042663:1373042663(0) ack 3313156150 win
>> 65535 
>>
>>
>> em2:  port 0x5000-0x501f mem
>> 0xe820-0xe821 irq 16 at device 0.0 on pci13
>> em2: Using MSI interrupt
>> em2: [FILTER]
>> em2: Ethernet address: 00:30:48:9f:eb:80
>> pcib5:  irq 16 at device 28.5 on pci0
>> pci14:  on pcib5
>> em3:  port 0x6000-0x601f mem
>> 0xe830-0xe831 irq 17 at device 0.0 on pci14
>> em3: Using MSI interrupt
>> em3: [FILTER]
>> em3: Ethernet address: 00:30:48:9f:eb:81
>>
>>
>> Also there is still the issue with
>>
>>
>> http://lists.freebsd.org/pipermail/freebsd-stable/2009-November/052842.html
>>
>> in RELENG_7 ?
>>
>>---Mike
>>
>>
>> 
>> Mike T

Re: RELENG_7 em problems (and RELENG_8)

2010-07-02 Thread Pyun YongHyeon

On Fri, Jul 02, 2010 at 01:39:22PM -0400, Mike Tancsa wrote:
> Hi Jack,
> Just a followup to the email below. I now saw what appears 
> to be the same problem on RELENG_8, but on a different nic and with 
> VLANs.  So not sure if this is a general em problem, a problem 
> specific to some em NICs, or a TSO problem in general.  The issue 
> seemed to be triggered when I added a new vlan based on
> 
> e...@pci0:14:0:0:class=0x02 card=0x109a15d9 
> chip=0x109a8086 rev=0x00 hdr=0x00
> vendor = 'Intel Corporation'
> device = 'Intel PRO/1000 PL Network Adaptor (82573L)'
> 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 10[e0] = PCI-Express 1 endpoint max data 128(256) link x1(x1)
> 
> pci14:  on pcib5
> em3:  port 0x6000-0x601f 
> mem 0xe830-0xe831 irq 17 at device 0.0 on pci14
> em3: Using MSI interrupt
> em3: [FILTER]
> em3: Ethernet address: 00:30:48:9f:eb:81
> 
> em3: flags=8943 
> metric 0 mtu 1500
> options=2098
> ether 00:30:48:9f:eb:81
> inet 10.255.255.254 netmask 0xfffc broadcast 10.255.255.255
> media: Ethernet autoselect (1000baseT )
> status: active
> 
> I had to disable tso, rxcsum and txsum in order to see the devices on 
> the other side of the two vlans trunked off em3.  Unfortunately, the 
> other sides were switches 100km and 500km away so I didnt have any 
> tcpdump capabilities to diagnose the issue.  I had already created 
> one vlan off this NIC and all was fine.  A few weeks later, I added a 
> new one and I could no longer telnet into the remote switches from 
> the local machine But, I could telnet into the switches from 
> machines not on the problem box. Hence, it would appear to be a 
> general TSO issue no ? I disabled tso on the nic (I didnt disable 
> net.inet.tcp.tso as I forgot about that).. Still nothing. I could 
> always ping the remote devices, but no tcp services.  I then 
> remembered this issue from before, so I tried disabling tso on the 
> NIC. Still nothing. Then I disabled rxcsum and txcsum and I could 
> then telnet into the remote devices.
> 
> This newly observed issue was from a buildworld on Mon Jun 14 
> 11:29:12 EDT 2010.
> 
> I will try and recreate the issue locally again to see if I can 
> trigger the problem on demand.  Any thoughts on what it might be ? 
> Perhaps an issue specific to certain em nics ?
> 

http://www.freebsd.org/cgi/query-pr.cgi?pr=141843
I'm not sure whether you're seeing the same issue though.
I didn't have chance to try latest em(4) on stable/7.
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: RELENG_7 em problems (and RELENG_8)

2010-07-02 Thread Mike Tancsa


At 03:36 PM 7/2/2010, Pyun YongHyeon wrote:


http://www.freebsd.org/cgi/query-pr.cgi?pr=141843
I'm not sure whether you're seeing the same issue though.
I didn't have chance to try latest em(4) on stable/7.



Wow, what a detailed PR!  That sure sounds like the issue I am seeing 
as well. I am just setting up another box to try and recreate the issue


---Mike



Mike Tancsa,  tel +1 519 651 3400
Sentex Communications,m...@sentex.net
Providing Internet since 1994www.sentex.net
Cambridge, Ontario Canada www.sentex.net/mike

___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: RELENG_7 em problems (and RELENG_8)

2010-08-16 Thread Mike Tancsa


Hi Jack,
FYI, I am still seeing this same problem on RELENG_8 (code 
as of today).  Unfortunately I cant try Pyun's patch since the 
underlying code has changed since then.


e...@pci0:3:0:0: class=0x02 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 enabled with 1 message
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

pci3:  on pcib3
em4:  port 0x1000-0x101f 
mem 0xb190-0xb191,0xb192-0xb1923fff irq 16 at device 0.0 on pci3

em4: Using MSI interrupt
em4: [FILTER]
em4: Ethernet address: 00:15:17:ed:3e:c4



---Mike


At 03:36 PM 7/2/2010, Pyun YongHyeon wrote:

On Fri, Jul 02, 2010 at 01:39:22PM -0400, Mike Tancsa wrote:
> Hi Jack,
> Just a followup to the email below. I now saw what appears
> to be the same problem on RELENG_8, but on a different nic and with
> VLANs.  So not sure if this is a general em problem, a problem
> specific to some em NICs, or a TSO problem in general.  The issue
> seemed to be triggered when I added a new vlan based on
>
> e...@pci0:14:0:0:class=0x02 card=0x109a15d9
> chip=0x109a8086 rev=0x00 hdr=0x00
> vendor = 'Intel Corporation'
> device = 'Intel PRO/1000 PL Network Adaptor (82573L)'
> 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 10[e0] = PCI-Express 1 endpoint max data 128(256) link x1(x1)
>
> pci14:  on pcib5
> em3:  port 0x6000-0x601f
> mem 0xe830-0xe831 irq 17 at device 0.0 on pci14
> em3: Using MSI interrupt
> em3: [FILTER]
> em3: Ethernet address: 00:30:48:9f:eb:81
>
> em3: flags=8943
> metric 0 mtu 1500
> options=2098
> ether 00:30:48:9f:eb:81
> inet 10.255.255.254 netmask 0xfffc broadcast 10.255.255.255
> media: Ethernet autoselect (1000baseT )
> status: active
>
> I had to disable tso, rxcsum and txsum in order to see the devices on
> the other side of the two vlans trunked off em3.  Unfortunately, the
> other sides were switches 100km and 500km away so I didnt have any
> tcpdump capabilities to diagnose the issue.  I had already created
> one vlan off this NIC and all was fine.  A few weeks later, I added a
> new one and I could no longer telnet into the remote switches from
> the local machine But, I could telnet into the switches from
> machines not on the problem box. Hence, it would appear to be a
> general TSO issue no ? I disabled tso on the nic (I didnt disable
> net.inet.tcp.tso as I forgot about that).. Still nothing. I could
> always ping the remote devices, but no tcp services.  I then
> remembered this issue from before, so I tried disabling tso on the
> NIC. Still nothing. Then I disabled rxcsum and txcsum and I could
> then telnet into the remote devices.
>
> This newly observed issue was from a buildworld on Mon Jun 14
> 11:29:12 EDT 2010.
>
> I will try and recreate the issue locally again to see if I can
> trigger the problem on demand.  Any thoughts on what it might be ?
> Perhaps an issue specific to certain em nics ?
>

http://www.freebsd.org/cgi/query-pr.cgi?pr=141843
I'm not sure whether you're seeing the same issue though.
I didn't have chance to try latest em(4) on stable/7.



Mike Tancsa,  tel +1 519 651 3400
Sentex Communications,m...@sentex.net
Providing Internet since 1994www.sentex.net
Cambridge, Ontario Canada www.sentex.net/mike

___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: RELENG_7 em problems (and RELENG_8)

2010-08-17 Thread Pyun YongHyeon

On Mon, Aug 16, 2010 at 05:07:11PM -0400, Mike Tancsa wrote:
> Hi Jack,
> FYI, I am still seeing this same problem on RELENG_8 (code 
> as of today).  Unfortunately I cant try Pyun's patch since the 
> underlying code has changed since then.
> 
> e...@pci0:3:0:0: class=0x02 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 enabled with 1 message
> 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
> 
> pci3:  on pcib3
> em4:  port 0x1000-0x101f 
> mem 0xb190-0xb191,0xb192-0xb1923fff irq 16 at device 0.0 on pci3
> em4: Using MSI interrupt
> em4: [FILTER]
> em4: Ethernet address: 00:15:17:ed:3e:c4
> 

Here is updated patch for HEAD and stable/8.
http://people.freebsd.org/~yongari/em.csum_tso.20100817.patch

It seems to work as expected under my limited environments. If
you're using multiple Tx queues with em(4) it would be better to
disable Tx checksum offloading as driver always have to create a
new checksum context for each frame. This will effectively disable
pipelined Tx data DMA which in turn greatly slows down Tx
performance for small sized frames. The reason driver have to
create a new checksum context when it uses multiple Tx queues comes
from hardware limitation. The controller tracks only for the last
context descriptor that was written such that driver does not know
the state of checksum context configured in other Tx queue.
Hope this helps.

> 
> 
> ---Mike
> 
> 
> At 03:36 PM 7/2/2010, Pyun YongHyeon wrote:
> >On Fri, Jul 02, 2010 at 01:39:22PM -0400, Mike Tancsa wrote:
> >> Hi Jack,
> >> Just a followup to the email below. I now saw what appears
> >> to be the same problem on RELENG_8, but on a different nic and with
> >> VLANs.  So not sure if this is a general em problem, a problem
> >> specific to some em NICs, or a TSO problem in general.  The issue
> >> seemed to be triggered when I added a new vlan based on
> >>
> >> e...@pci0:14:0:0:class=0x02 card=0x109a15d9
> >> chip=0x109a8086 rev=0x00 hdr=0x00
> >> vendor = 'Intel Corporation'
> >> device = 'Intel PRO/1000 PL Network Adaptor (82573L)'
> >> 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 10[e0] = PCI-Express 1 endpoint max data 128(256) link x1(x1)
> >>
> >> pci14:  on pcib5
> >> em3:  port 0x6000-0x601f
> >> mem 0xe830-0xe831 irq 17 at device 0.0 on pci14
> >> em3: Using MSI interrupt
> >> em3: [FILTER]
> >> em3: Ethernet address: 00:30:48:9f:eb:81
> >>
> >> em3: flags=8943
> >> metric 0 mtu 1500
> >> options=2098
> >> ether 00:30:48:9f:eb:81
> >> inet 10.255.255.254 netmask 0xfffc broadcast 10.255.255.255
> >> media: Ethernet autoselect (1000baseT )
> >> status: active
> >>
> >> I had to disable tso, rxcsum and txsum in order to see the devices on
> >> the other side of the two vlans trunked off em3.  Unfortunately, the
> >> other sides were switches 100km and 500km away so I didnt have any
> >> tcpdump capabilities to diagnose the issue.  I had already created
> >> one vlan off this NIC and all was fine.  A few weeks later, I added a
> >> new one and I could no longer telnet into the remote switches from
> >> the local machine But, I could telnet into the switches from
> >> machines not on the problem box. Hence, it would appear to be a
> >> general TSO issue no ? I disabled tso on the nic (I didnt disable
> >> net.inet.tcp.tso as I forgot about that).. Still nothing. I could
> >> always ping the remote devices, but no tcp services.  I then
> >> remembered this issue from before, so I tried disabling tso on the
> >> NIC. Still nothing. Then I disabled rxcsum and txcsum and I could
> >> then telnet into the remote devices.
> >>
> >> This newly observed issue was from a buildworld on Mon Jun 14
> >> 11:29:12 EDT 2010.
> >>
> >> I will try and recreate the issue locally again to see if I can
> >> trigger the problem on demand.  Any thoughts on what it might be ?
> >> Perhaps an issue specific to certain em nics ?
> >>
> >
> >http://www.freebsd.org/cgi/query-pr.cgi?pr=141843
> >I'm not sure whether you're seeing the same issue though.
> >I didn't have chance to try latest em(4) on stable/7.
> 
> 
> Mike Tancsa,  tel +1 519 651 3400
> Sentex Communications,m...@sentex.net
> Providing Internet since 1994www.sentex.net
> Cambridge, Ontario Canada

Re: RELENG_7 em problems (and RELENG_8)

2010-08-17 Thread Jack Vogel

Hmmm, interesting, I'll have to have some testing done, maybe for the 574 it
should automagically disable CSUM?

Jack


On Tue, Aug 17, 2010 at 11:52 AM, Pyun YongHyeon  wrote:

> On Mon, Aug 16, 2010 at 05:07:11PM -0400, Mike Tancsa wrote:
> > Hi Jack,
> > FYI, I am still seeing this same problem on RELENG_8 (code
> > as of today).  Unfortunately I cant try Pyun's patch since the
> > underlying code has changed since then.
> >
> > e...@pci0:3:0:0: class=0x02 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 enabled with 1 message
> > 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
> >
> > pci3:  on pcib3
> > em4:  port 0x1000-0x101f
> > mem 0xb190-0xb191,0xb192-0xb1923fff irq 16 at device 0.0 on
> pci3
> > em4: Using MSI interrupt
> > em4: [FILTER]
> > em4: Ethernet address: 00:15:17:ed:3e:c4
> >
>
> Here is updated patch for HEAD and stable/8.
> http://people.freebsd.org/~yongari/em.csum_tso.20100817.patch
>
> It seems to work as expected under my limited environments. If
> you're using multiple Tx queues with em(4) it would be better to
> disable Tx checksum offloading as driver always have to create a
> new checksum context for each frame. This will effectively disable
> pipelined Tx data DMA which in turn greatly slows down Tx
> performance for small sized frames. The reason driver have to
> create a new checksum context when it uses multiple Tx queues comes
> from hardware limitation. The controller tracks only for the last
> context descriptor that was written such that driver does not know
> the state of checksum context configured in other Tx queue.
> Hope this helps.
>
> >
> >
> > ---Mike
> >
> >
> > At 03:36 PM 7/2/2010, Pyun YongHyeon wrote:
> > >On Fri, Jul 02, 2010 at 01:39:22PM -0400, Mike Tancsa wrote:
> > >> Hi Jack,
> > >> Just a followup to the email below. I now saw what appears
> > >> to be the same problem on RELENG_8, but on a different nic and with
> > >> VLANs.  So not sure if this is a general em problem, a problem
> > >> specific to some em NICs, or a TSO problem in general.  The issue
> > >> seemed to be triggered when I added a new vlan based on
> > >>
> > >> e...@pci0:14:0:0:class=0x02 card=0x109a15d9
> > >> chip=0x109a8086 rev=0x00 hdr=0x00
> > >> vendor = 'Intel Corporation'
> > >> device = 'Intel PRO/1000 PL Network Adaptor (82573L)'
> > >> 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 10[e0] = PCI-Express 1 endpoint max data 128(256) link x1(x1)
> > >>
> > >> pci14:  on pcib5
> > >> em3:  port 0x6000-0x601f
> > >> mem 0xe830-0xe831 irq 17 at device 0.0 on pci14
> > >> em3: Using MSI interrupt
> > >> em3: [FILTER]
> > >> em3: Ethernet address: 00:30:48:9f:eb:81
> > >>
> > >> em3: flags=8943
> > >> metric 0 mtu 1500
> > >> options=2098
> > >> ether 00:30:48:9f:eb:81
> > >> inet 10.255.255.254 netmask 0xfffc broadcast
> 10.255.255.255
> > >> media: Ethernet autoselect (1000baseT )
> > >> status: active
> > >>
> > >> I had to disable tso, rxcsum and txsum in order to see the devices on
> > >> the other side of the two vlans trunked off em3.  Unfortunately, the
> > >> other sides were switches 100km and 500km away so I didnt have any
> > >> tcpdump capabilities to diagnose the issue.  I had already created
> > >> one vlan off this NIC and all was fine.  A few weeks later, I added a
> > >> new one and I could no longer telnet into the remote switches from
> > >> the local machine But, I could telnet into the switches from
> > >> machines not on the problem box. Hence, it would appear to be a
> > >> general TSO issue no ? I disabled tso on the nic (I didnt disable
> > >> net.inet.tcp.tso as I forgot about that).. Still nothing. I could
> > >> always ping the remote devices, but no tcp services.  I then
> > >> remembered this issue from before, so I tried disabling tso on the
> > >> NIC. Still nothing. Then I disabled rxcsum and txcsum and I could
> > >> then telnet into the remote devices.
> > >>
> > >> This newly observed issue was from a buildworld on Mon Jun 14
> > >> 11:29:12 EDT 2010.
> > >>
> > >> I will try and recreate the issue locally again to see if I can
> > >> trigger the problem on demand.  Any thoughts on what it might be ?
> > >> Perhaps an issue specific to certain em nics ?
> > >>
> > >
> > >http://www.freebsd.org/cgi/query-pr.cgi?pr=141843
> > >I

Re: RELENG_7 em problems (and RELENG_8)

2010-08-17 Thread Pyun YongHyeon

On Tue, Aug 17, 2010 at 11:52:08AM -0700, Pyun YongHyeon wrote:
> On Mon, Aug 16, 2010 at 05:07:11PM -0400, Mike Tancsa wrote:
> > Hi Jack,
> > FYI, I am still seeing this same problem on RELENG_8 (code 
> > as of today).  Unfortunately I cant try Pyun's patch since the 
> > underlying code has changed since then.
> > 
> > e...@pci0:3:0:0: class=0x02 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 enabled with 1 message
> > 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
> > 
> > pci3:  on pcib3
> > em4:  port 0x1000-0x101f 
> > mem 0xb190-0xb191,0xb192-0xb1923fff irq 16 at device 0.0 on pci3
> > em4: Using MSI interrupt
> > em4: [FILTER]
> > em4: Ethernet address: 00:15:17:ed:3e:c4
> > 
> 
> Here is updated patch for HEAD and stable/8.
> http://people.freebsd.org/~yongari/em.csum_tso.20100817.patch
> 
> It seems to work as expected under my limited environments. If
> you're using multiple Tx queues with em(4) it would be better to
> disable Tx checksum offloading as driver always have to create a
> new checksum context for each frame. This will effectively disable
> pipelined Tx data DMA which in turn greatly slows down Tx
> performance for small sized frames. The reason driver have to
> create a new checksum context when it uses multiple Tx queues comes
> from hardware limitation. The controller tracks only for the last
> context descriptor that was written such that driver does not know
> the state of checksum context configured in other Tx queue.
> Hope this helps.
> 

For igb(4) controllers, it seems we also need a way to avoid
creating a new checksum context for every Tx frame as we did in
em(4). Unlike em(4) controllers, igb(4) seems to maintain context
per queue such that we can safely reuse previously configured
context for a queue.
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: RELENG_7 em problems (and RELENG_8)

2010-08-17 Thread Jack Vogel

I believe the requirement of a context descriptor for most frames in the igb
driver
is just the way the hardware works, I've looked over the Linux driver again
and it
looks like they require the same. I don't believe its a big deal, just the
added
descriptor for the frame.

Jack


On Tue, Aug 17, 2010 at 12:14 PM, Pyun YongHyeon  wrote:

> On Tue, Aug 17, 2010 at 11:52:08AM -0700, Pyun YongHyeon wrote:
> > On Mon, Aug 16, 2010 at 05:07:11PM -0400, Mike Tancsa wrote:
> > > Hi Jack,
> > > FYI, I am still seeing this same problem on RELENG_8 (code
> > > as of today).  Unfortunately I cant try Pyun's patch since the
> > > underlying code has changed since then.
> > >
> > > e...@pci0:3:0:0: class=0x02 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 enabled with 1 message
> > > 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
> > >
> > > pci3:  on pcib3
> > > em4:  port 0x1000-0x101f
> > > mem 0xb190-0xb191,0xb192-0xb1923fff irq 16 at device 0.0 on
> pci3
> > > em4: Using MSI interrupt
> > > em4: [FILTER]
> > > em4: Ethernet address: 00:15:17:ed:3e:c4
> > >
> >
> > Here is updated patch for HEAD and stable/8.
> > http://people.freebsd.org/~yongari/em.csum_tso.20100817.patch
> >
> > It seems to work as expected under my limited environments. If
> > you're using multiple Tx queues with em(4) it would be better to
> > disable Tx checksum offloading as driver always have to create a
> > new checksum context for each frame. This will effectively disable
> > pipelined Tx data DMA which in turn greatly slows down Tx
> > performance for small sized frames. The reason driver have to
> > create a new checksum context when it uses multiple Tx queues comes
> > from hardware limitation. The controller tracks only for the last
> > context descriptor that was written such that driver does not know
> > the state of checksum context configured in other Tx queue.
> > Hope this helps.
> >
>
> For igb(4) controllers, it seems we also need a way to avoid
> creating a new checksum context for every Tx frame as we did in
> em(4). Unlike em(4) controllers, igb(4) seems to maintain context
> per queue such that we can safely reuse previously configured
> context for a queue.
> ___
> freebsd-stable@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-stable
> To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
>
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: RELENG_7 em problems (and RELENG_8)

2010-08-17 Thread Pyun YongHyeon

On Tue, Aug 17, 2010 at 12:05:56PM -0700, Jack Vogel wrote:
> Hmmm, interesting, I'll have to have some testing done, maybe for the 574 it
> should automagically disable CSUM?
> 

I don't have 82574 controller to test but it may depend on how
pipelined Tx data DMA works. If 82574 can still pipeline Tx data
DMA when a new context is written it would be better to enable
checksum offloading. If em(4) uses single Tx queue, we can safely
enable checksum offloading, I guess.

> Jack
> 
> 
> On Tue, Aug 17, 2010 at 11:52 AM, Pyun YongHyeon  wrote:
> 
> > On Mon, Aug 16, 2010 at 05:07:11PM -0400, Mike Tancsa wrote:
> > > Hi Jack,
> > > FYI, I am still seeing this same problem on RELENG_8 (code
> > > as of today).  Unfortunately I cant try Pyun's patch since the
> > > underlying code has changed since then.
> > >
> > > e...@pci0:3:0:0: class=0x02 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 enabled with 1 message
> > > 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
> > >
> > > pci3:  on pcib3
> > > em4:  port 0x1000-0x101f
> > > mem 0xb190-0xb191,0xb192-0xb1923fff irq 16 at device 0.0 on
> > pci3
> > > em4: Using MSI interrupt
> > > em4: [FILTER]
> > > em4: Ethernet address: 00:15:17:ed:3e:c4
> > >
> >
> > Here is updated patch for HEAD and stable/8.
> > http://people.freebsd.org/~yongari/em.csum_tso.20100817.patch
> >
> > It seems to work as expected under my limited environments. If
> > you're using multiple Tx queues with em(4) it would be better to
> > disable Tx checksum offloading as driver always have to create a
> > new checksum context for each frame. This will effectively disable
> > pipelined Tx data DMA which in turn greatly slows down Tx
> > performance for small sized frames. The reason driver have to
> > create a new checksum context when it uses multiple Tx queues comes
> > from hardware limitation. The controller tracks only for the last
> > context descriptor that was written such that driver does not know
> > the state of checksum context configured in other Tx queue.
> > Hope this helps.
> >
> > >
> > >
> > > ---Mike
> > >
> > >
> > > At 03:36 PM 7/2/2010, Pyun YongHyeon wrote:
> > > >On Fri, Jul 02, 2010 at 01:39:22PM -0400, Mike Tancsa wrote:
> > > >> Hi Jack,
> > > >> Just a followup to the email below. I now saw what appears
> > > >> to be the same problem on RELENG_8, but on a different nic and with
> > > >> VLANs.  So not sure if this is a general em problem, a problem
> > > >> specific to some em NICs, or a TSO problem in general.  The issue
> > > >> seemed to be triggered when I added a new vlan based on
> > > >>
> > > >> e...@pci0:14:0:0:class=0x02 card=0x109a15d9
> > > >> chip=0x109a8086 rev=0x00 hdr=0x00
> > > >> vendor = 'Intel Corporation'
> > > >> device = 'Intel PRO/1000 PL Network Adaptor (82573L)'
> > > >> 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 10[e0] = PCI-Express 1 endpoint max data 128(256) link x1(x1)
> > > >>
> > > >> pci14:  on pcib5
> > > >> em3:  port 0x6000-0x601f
> > > >> mem 0xe830-0xe831 irq 17 at device 0.0 on pci14
> > > >> em3: Using MSI interrupt
> > > >> em3: [FILTER]
> > > >> em3: Ethernet address: 00:30:48:9f:eb:81
> > > >>
> > > >> em3: flags=8943
> > > >> metric 0 mtu 1500
> > > >> options=2098
> > > >> ether 00:30:48:9f:eb:81
> > > >> inet 10.255.255.254 netmask 0xfffc broadcast
> > 10.255.255.255
> > > >> media: Ethernet autoselect (1000baseT )
> > > >> status: active
> > > >>
> > > >> I had to disable tso, rxcsum and txsum in order to see the devices on
> > > >> the other side of the two vlans trunked off em3.  Unfortunately, the
> > > >> other sides were switches 100km and 500km away so I didnt have any
> > > >> tcpdump capabilities to diagnose the issue.  I had already created
> > > >> one vlan off this NIC and all was fine.  A few weeks later, I added a
> > > >> new one and I could no longer telnet into the remote switches from
> > > >> the local machine But, I could telnet into the switches from
> > > >> machines not on the problem box. Hence, it would appear to be a
> > > >> general TSO issue no ? I disabled tso on the nic (I didnt disable
> > > >> net.inet.tcp.tso as I forgot about that).. Still nothing. I could
> > > >> always ping the remote devices, but no tcp services.  I then
> > > >> remember

Re: RELENG_7 em problems (and RELENG_8)

2010-08-17 Thread Jack Vogel

Well we do of course, i'll have my test engineer try it both ways and see
what
looks better. Let you know...

Jack


On Tue, Aug 17, 2010 at 12:35 PM, Pyun YongHyeon  wrote:

> On Tue, Aug 17, 2010 at 12:05:56PM -0700, Jack Vogel wrote:
> > Hmmm, interesting, I'll have to have some testing done, maybe for the 574
> it
> > should automagically disable CSUM?
> >
>
> I don't have 82574 controller to test but it may depend on how
> pipelined Tx data DMA works. If 82574 can still pipeline Tx data
> DMA when a new context is written it would be better to enable
> checksum offloading. If em(4) uses single Tx queue, we can safely
> enable checksum offloading, I guess.
>
> > Jack
> >
> >
> > On Tue, Aug 17, 2010 at 11:52 AM, Pyun YongHyeon 
> wrote:
> >
> > > On Mon, Aug 16, 2010 at 05:07:11PM -0400, Mike Tancsa wrote:
> > > > Hi Jack,
> > > > FYI, I am still seeing this same problem on RELENG_8 (code
> > > > as of today).  Unfortunately I cant try Pyun's patch since the
> > > > underlying code has changed since then.
> > > >
> > > > e...@pci0:3:0:0: class=0x02 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 enabled with 1
> message
> > > > 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
> > > >
> > > > pci3:  on pcib3
> > > > em4:  port 0x1000-0x101f
> > > > mem 0xb190-0xb191,0xb192-0xb1923fff irq 16 at device 0.0
> on
> > > pci3
> > > > em4: Using MSI interrupt
> > > > em4: [FILTER]
> > > > em4: Ethernet address: 00:15:17:ed:3e:c4
> > > >
> > >
> > > Here is updated patch for HEAD and stable/8.
> > > http://people.freebsd.org/~yongari/em.csum_tso.20100817.patch
> 
> > >
> > > It seems to work as expected under my limited environments. If
> > > you're using multiple Tx queues with em(4) it would be better to
> > > disable Tx checksum offloading as driver always have to create a
> > > new checksum context for each frame. This will effectively disable
> > > pipelined Tx data DMA which in turn greatly slows down Tx
> > > performance for small sized frames. The reason driver have to
> > > create a new checksum context when it uses multiple Tx queues comes
> > > from hardware limitation. The controller tracks only for the last
> > > context descriptor that was written such that driver does not know
> > > the state of checksum context configured in other Tx queue.
> > > Hope this helps.
> > >
> > > >
> > > >
> > > > ---Mike
> > > >
> > > >
> > > > At 03:36 PM 7/2/2010, Pyun YongHyeon wrote:
> > > > >On Fri, Jul 02, 2010 at 01:39:22PM -0400, Mike Tancsa wrote:
> > > > >> Hi Jack,
> > > > >> Just a followup to the email below. I now saw what appears
> > > > >> to be the same problem on RELENG_8, but on a different nic and
> with
> > > > >> VLANs.  So not sure if this is a general em problem, a problem
> > > > >> specific to some em NICs, or a TSO problem in general.  The issue
> > > > >> seemed to be triggered when I added a new vlan based on
> > > > >>
> > > > >> e...@pci0:14:0:0:class=0x02 card=0x109a15d9
> > > > >> chip=0x109a8086 rev=0x00 hdr=0x00
> > > > >> vendor = 'Intel Corporation'
> > > > >> device = 'Intel PRO/1000 PL Network Adaptor (82573L)'
> > > > >> 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 10[e0] = PCI-Express 1 endpoint max data 128(256) link
> x1(x1)
> > > > >>
> > > > >> pci14:  on pcib5
> > > > >> em3:  port
> 0x6000-0x601f
> > > > >> mem 0xe830-0xe831 irq 17 at device 0.0 on pci14
> > > > >> em3: Using MSI interrupt
> > > > >> em3: [FILTER]
> > > > >> em3: Ethernet address: 00:30:48:9f:eb:81
> > > > >>
> > > > >> em3: flags=8943
> > > > >> metric 0 mtu 1500
> > > > >>
> options=2098
> > > > >> ether 00:30:48:9f:eb:81
> > > > >> inet 10.255.255.254 netmask 0xfffc broadcast
> > > 10.255.255.255
> > > > >> media: Ethernet autoselect (1000baseT )
> > > > >> status: active
> > > > >>
> > > > >> I had to disable tso, rxcsum and txsum in order to see the devices
> on
> > > > >> the other side of the two vlans trunked off em3.  Unfortunately,
> the
> > > > >> other sides were switches 100km and 500km away so I didnt have any
> > > > >> tcpdump capabilities to diagnose the issue.  I had already created
> > > > >> one vlan off this NIC and all was fine.  A few weeks later, I
> added a
> >

Re: RELENG_7 em problems (and RELENG_8)

2010-08-17 Thread Pyun YongHyeon

On Tue, Aug 17, 2010 at 12:34:31PM -0700, Jack Vogel wrote:
> I believe the requirement of a context descriptor for most frames in the igb
> driver
> is just the way the hardware works, I've looked over the Linux driver again
> and it
> looks like they require the same. I don't believe its a big deal, just the
> added
> descriptor for the frame.
> 

Setting up context does not cost much. The real cost comes from
stopping requesting DMA for next packet whenever a new context
is written.
AFAIK Linux always added a new checksum context. I don't know
whether Linux cares about the cost of refilling pipeline or
measured the performance differences. FreeBSD noticed the
difference on em(4) controllers and took appropriate action to take
full advantage of the hardware feature, I think.
I have to experiment how igb(4) works when it is told to reuse
configured context(both checksum and TSO context).

> Jack
> 
> 
> On Tue, Aug 17, 2010 at 12:14 PM, Pyun YongHyeon  wrote:
> 
> > On Tue, Aug 17, 2010 at 11:52:08AM -0700, Pyun YongHyeon wrote:
> > > On Mon, Aug 16, 2010 at 05:07:11PM -0400, Mike Tancsa wrote:
> > > > Hi Jack,
> > > > FYI, I am still seeing this same problem on RELENG_8 (code
> > > > as of today).  Unfortunately I cant try Pyun's patch since the
> > > > underlying code has changed since then.
> > > >
> > > > e...@pci0:3:0:0: class=0x02 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 enabled with 1 message
> > > > 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
> > > >
> > > > pci3:  on pcib3
> > > > em4:  port 0x1000-0x101f
> > > > mem 0xb190-0xb191,0xb192-0xb1923fff irq 16 at device 0.0 on
> > pci3
> > > > em4: Using MSI interrupt
> > > > em4: [FILTER]
> > > > em4: Ethernet address: 00:15:17:ed:3e:c4
> > > >
> > >
> > > Here is updated patch for HEAD and stable/8.
> > > http://people.freebsd.org/~yongari/em.csum_tso.20100817.patch
> > >
> > > It seems to work as expected under my limited environments. If
> > > you're using multiple Tx queues with em(4) it would be better to
> > > disable Tx checksum offloading as driver always have to create a
> > > new checksum context for each frame. This will effectively disable
> > > pipelined Tx data DMA which in turn greatly slows down Tx
> > > performance for small sized frames. The reason driver have to
> > > create a new checksum context when it uses multiple Tx queues comes
> > > from hardware limitation. The controller tracks only for the last
> > > context descriptor that was written such that driver does not know
> > > the state of checksum context configured in other Tx queue.
> > > Hope this helps.
> > >
> >
> > For igb(4) controllers, it seems we also need a way to avoid
> > creating a new checksum context for every Tx frame as we did in
> > em(4). Unlike em(4) controllers, igb(4) seems to maintain context
> > per queue such that we can safely reuse previously configured
> > context for a queue.
> > ___
> > freebsd-stable@freebsd.org mailing list
> > http://lists.freebsd.org/mailman/listinfo/freebsd-stable
> > To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
> >
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: RELENG_7 em problems (and RELENG_8)

2010-08-17 Thread Jack Vogel

The guy who worries about the Linux driver's performance is in my team, and
he's
a very good engineer, and we're talking about the hardware's DMA, so its not
an OS issue, thus I'm not saying I'm sure, but I'm dubious about this, at
least
when we're talking about igb. But hey, I'm willing to be proven wrong :)

Jack


On Tue, Aug 17, 2010 at 12:47 PM, Pyun YongHyeon  wrote:

> On Tue, Aug 17, 2010 at 12:34:31PM -0700, Jack Vogel wrote:
> > I believe the requirement of a context descriptor for most frames in the
> igb
> > driver
> > is just the way the hardware works, I've looked over the Linux driver
> again
> > and it
> > looks like they require the same. I don't believe its a big deal, just
> the
> > added
> > descriptor for the frame.
> >
>
> Setting up context does not cost much. The real cost comes from
> stopping requesting DMA for next packet whenever a new context
> is written.
> AFAIK Linux always added a new checksum context. I don't know
> whether Linux cares about the cost of refilling pipeline or
> measured the performance differences. FreeBSD noticed the
> difference on em(4) controllers and took appropriate action to take
> full advantage of the hardware feature, I think.
> I have to experiment how igb(4) works when it is told to reuse
> configured context(both checksum and TSO context).
>
>
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: RELENG_7 em problems (and RELENG_8)

2010-08-17 Thread Mike Tancsa


At 02:52 PM 8/17/2010, Pyun YongHyeon wrote:


Here is updated patch for HEAD and stable/8.
http://people.freebsd.org/~yongari/em.csum_tso.20100817.patch

It seems to work as expected under my limited environments. If


Thanks! The patch applies cleanly and all works as expected now! I am 
no longer able to trigger the bug. I just use the stock unmodified 
driver normally, so no multi queues


# vmstat -i
interrupt  total   rate
irq256: em0  149  0
irq257: em13  0
irq259: em3  971  2
irq260: ahci0   1520  3



em3: flags=8843 metric 0 mtu 1500

options=219b
ether 00:15:17:xx:xx:xx
inet6 fe80::215:17ff:fexx:%em3 prefixlen 64 scopeid 0x4
inet 192.168.xx.xx netmask 0xff00 broadcast 192.168.xx.xx
nd6 options=3
media: Ethernet autoselect (100baseTX )
status: active


e...@pci0:3:0:0: class=0x02 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 enabled with 1 message
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



patch < em.csum_tso.20100817.patch
Hmm...  Looks like a unified diff to me...
The text leading up to this was:
--
|Index: sys/dev/e1000/if_em.c
|===
|--- sys/dev/e1000/if_em.c  (revision 211398)
|+++ sys/dev/e1000/if_em.c  (working copy)
--
Patching file sys/dev/e1000/if_em.c using Plan A...
Hunk #1 succeeded at 237.
Hunk #2 succeeded at 1730.
Hunk #3 succeeded at 1759.
Hunk #4 succeeded at 1930.
Hunk #5 succeeded at 3148.
Hunk #6 succeeded at 3351.
Hunk #7 succeeded at 3533.
Hunk #8 succeeded at 3590.
Hunk #9 succeeded at 3603.
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--
|Index: sys/dev/e1000/if_em.h
|===
|--- sys/dev/e1000/if_em.h  (revision 211398)
|+++ sys/dev/e1000/if_em.h  (working copy)
--
Patching file sys/dev/e1000/if_em.h using Plan A...
Hunk #1 succeeded at 284.
done

---Mike



you're using multiple Tx queues with em(4) it would be better to
disable Tx checksum offloading as driver always have to create a
new checksum context for each frame. This will effectively disable
pipelined Tx data DMA which in turn greatly slows down Tx
performance for small sized frames. The reason driver have to
create a new checksum context when it uses multiple Tx queues comes
from hardware limitation. The controller tracks only for the last
context descriptor that was written such that driver does not know
the state of checksum context configured in other Tx queue.
Hope this helps.

>
>
> ---Mike
>
>
> At 03:36 PM 7/2/2010, Pyun YongHyeon wrote:
> >On Fri, Jul 02, 2010 at 01:39:22PM -0400, Mike Tancsa wrote:
> >> Hi Jack,
> >> Just a followup to the email below. I now saw what appears
> >> to be the same problem on RELENG_8, but on a different nic and with
> >> VLANs.  So not sure if this is a general em problem, a problem
> >> specific to some em NICs, or a TSO problem in general.  The issue
> >> seemed to be triggered when I added a new vlan based on
> >>
> >> e...@pci0:14:0:0:class=0x02 card=0x109a15d9
> >> chip=0x109a8086 rev=0x00 hdr=0x00
> >> vendor = 'Intel Corporation'
> >> device = 'Intel PRO/1000 PL Network Adaptor (82573L)'
> >> 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 10[e0] = PCI-Express 1 endpoint max data 128(256) link x1(x1)
> >>
> >> pci14:  on pcib5
> >> em3:  port 0x6000-0x601f
> >> mem 0xe830-0xe831 irq 17 at device 0.0 on pci14
> >> em3: Using MSI interrupt
> >> em3: [FILTER]
> >> em3: Ethernet address: 00:30:48:9f:eb:81
> >>
> >> em3: flags=8943
> >> metric 0 mtu 1500
> >> options=2098
> >> ether 00:30:48:9f:eb:81
> >> inet 10.255.255.254 netmask 0xfffc broadcast 10.255.255.255
> >> media: Ethernet autoselect (1000baseT )
> >> status: active
> >>
> >> I had to disable tso, rxcsum and txsum in order to see the devices on
> >> the other side of the two vlans trunked off em3.  Unfortunately, the
> >> other sides were switches 100km and 500km away so I didnt have any
> >> tcpdump capabilities to diagnose the issue.  I had already created
> >> one vlan off this NIC and all was fine.  A f

Re: RELENG_7 em problems (and RELENG_8)

2010-08-17 Thread Pyun YongHyeon

On Tue, Aug 17, 2010 at 03:55:12PM -0400, Mike Tancsa wrote:
> At 02:52 PM 8/17/2010, Pyun YongHyeon wrote:
> 
> >Here is updated patch for HEAD and stable/8.
> >http://people.freebsd.org/~yongari/em.csum_tso.20100817.patch
> >
> >It seems to work as expected under my limited environments. If
> 
> Thanks! The patch applies cleanly and all works as expected now! I am 
> no longer able to trigger the bug. I just use the stock unmodified 
> driver normally, so no multi queues
> 

Glad to hear that. Thanks for testing!

> # vmstat -i
> interrupt  total   rate
> irq256: em0  149  0
> irq257: em13  0
> irq259: em3  971  2
> irq260: ahci0   1520  3
> 
> 
> 
> em3: flags=8843 metric 0 mtu 1500
> 
> options=219b
> ether 00:15:17:xx:xx:xx
> inet6 fe80::215:17ff:fexx:%em3 prefixlen 64 scopeid 0x4
> inet 192.168.xx.xx netmask 0xff00 broadcast 192.168.xx.xx
> nd6 options=3
> media: Ethernet autoselect (100baseTX )
> status: active
> 
> 
> e...@pci0:3:0:0: class=0x02 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 enabled with 1 message
> 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
> 
> 
> 
> patch < em.csum_tso.20100817.patch
> Hmm...  Looks like a unified diff to me...
> The text leading up to this was:
> --
> |Index: sys/dev/e1000/if_em.c
> |===
> |--- sys/dev/e1000/if_em.c  (revision 211398)
> |+++ sys/dev/e1000/if_em.c  (working copy)
> --
> Patching file sys/dev/e1000/if_em.c using Plan A...
> Hunk #1 succeeded at 237.
> Hunk #2 succeeded at 1730.
> Hunk #3 succeeded at 1759.
> Hunk #4 succeeded at 1930.
> Hunk #5 succeeded at 3148.
> Hunk #6 succeeded at 3351.
> Hunk #7 succeeded at 3533.
> Hunk #8 succeeded at 3590.
> Hunk #9 succeeded at 3603.
> Hmm...  The next patch looks like a unified diff to me...
> The text leading up to this was:
> --
> |Index: sys/dev/e1000/if_em.h
> |===
> |--- sys/dev/e1000/if_em.h  (revision 211398)
> |+++ sys/dev/e1000/if_em.h  (working copy)
> --
> Patching file sys/dev/e1000/if_em.h using Plan A...
> Hunk #1 succeeded at 284.
> done
> 
> ---Mike
> 
> 
> >you're using multiple Tx queues with em(4) it would be better to
> >disable Tx checksum offloading as driver always have to create a
> >new checksum context for each frame. This will effectively disable
> >pipelined Tx data DMA which in turn greatly slows down Tx
> >performance for small sized frames. The reason driver have to
> >create a new checksum context when it uses multiple Tx queues comes
> >from hardware limitation. The controller tracks only for the last
> >context descriptor that was written such that driver does not know
> >the state of checksum context configured in other Tx queue.
> >Hope this helps.
> >
> >>
> >>
> >> ---Mike
> >>
> >>
> >> At 03:36 PM 7/2/2010, Pyun YongHyeon wrote:
> >> >On Fri, Jul 02, 2010 at 01:39:22PM -0400, Mike Tancsa wrote:
> >> >> Hi Jack,
> >> >> Just a followup to the email below. I now saw what appears
> >> >> to be the same problem on RELENG_8, but on a different nic and with
> >> >> VLANs.  So not sure if this is a general em problem, a problem
> >> >> specific to some em NICs, or a TSO problem in general.  The issue
> >> >> seemed to be triggered when I added a new vlan based on
> >> >>
> >> >> e...@pci0:14:0:0:class=0x02 card=0x109a15d9
> >> >> chip=0x109a8086 rev=0x00 hdr=0x00
> >> >> vendor = 'Intel Corporation'
> >> >> device = 'Intel PRO/1000 PL Network Adaptor (82573L)'
> >> >> 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 10[e0] = PCI-Express 1 endpoint max data 128(256) link x1(x1)
> >> >>
> >> >> pci14:  on pcib5
> >> >> em3:  port 0x6000-0x601f
> >> >> mem 0xe830-0xe831 irq 17 at device 0.0 on pci14
> >> >> em3: Using MSI interrupt
> >> >> em3: [FILTER]
> >> >> em3: Ethernet address: 00:30:48:9f:eb:81
> >> >>
> >> >> em3: flags=8943
> >> >> metric 0 mtu 1500
> >> >> options=2098
> >> >> ether 00:30:48:9f:eb:81
> >> >> inet 10.255.255.254 netmask 0xfffc broadcast 
> >10.255.255.255
> >> >> media: Ethe

Re: RELENG_7 em problems (and RELENG_8)

2010-09-14 Thread Mike Tancsa


Hi Jack,
Any plans to commit the patch below ? I have been running it 
on a number of boxes and it works as expected with no side effects.


---Mike


At 04:00 PM 8/17/2010, Pyun YongHyeon wrote:

On Tue, Aug 17, 2010 at 03:55:12PM -0400, Mike Tancsa wrote:
> At 02:52 PM 8/17/2010, Pyun YongHyeon wrote:
>
> >Here is updated patch for HEAD and stable/8.
> >http://people.freebsd.org/~yongari/em.csum_tso.20100817.patch
> >
> >It seems to work as expected under my limited environments. If
>
> Thanks! The patch applies cleanly and all works as expected now! I am
> no longer able to trigger the bug. I just use the stock unmodified
> driver normally, so no multi queues
>

Glad to hear that. Thanks for testing!

> # vmstat -i
> interrupt  total   rate
> irq256: em0  149  0
> irq257: em13  0
> irq259: em3  971  2
> irq260: ahci0   1520  3
>
>
>
> em3: flags=8843 metric 0 mtu 1500
> 
options=219b

> ether 00:15:17:xx:xx:xx
> inet6 fe80::215:17ff:fexx:%em3 prefixlen 64 scopeid 0x4
> inet 192.168.xx.xx netmask 0xff00 broadcast 192.168.xx.xx
> nd6 options=3
> media: Ethernet autoselect (100baseTX )
> status: active
>
>
> e...@pci0:3:0:0: class=0x02 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 enabled with 1 message
> 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
>
>
>
> patch < em.csum_tso.20100817.patch
> Hmm...  Looks like a unified diff to me...
> The text leading up to this was:
> --
> |Index: sys/dev/e1000/if_em.c
> |===
> |--- sys/dev/e1000/if_em.c  (revision 211398)
> |+++ sys/dev/e1000/if_em.c  (working copy)
> --
> Patching file sys/dev/e1000/if_em.c using Plan A...
> Hunk #1 succeeded at 237.
> Hunk #2 succeeded at 1730.
> Hunk #3 succeeded at 1759.
> Hunk #4 succeeded at 1930.
> Hunk #5 succeeded at 3148.
> Hunk #6 succeeded at 3351.
> Hunk #7 succeeded at 3533.
> Hunk #8 succeeded at 3590.
> Hunk #9 succeeded at 3603.
> Hmm...  The next patch looks like a unified diff to me...
> The text leading up to this was:
> --
> |Index: sys/dev/e1000/if_em.h
> |===
> |--- sys/dev/e1000/if_em.h  (revision 211398)
> |+++ sys/dev/e1000/if_em.h  (working copy)
> --
> Patching file sys/dev/e1000/if_em.h using Plan A...
> Hunk #1 succeeded at 284.
> done
>
> ---Mike
>
>
> >you're using multiple Tx queues with em(4) it would be better to
> >disable Tx checksum offloading as driver always have to create a
> >new checksum context for each frame. This will effectively disable
> >pipelined Tx data DMA which in turn greatly slows down Tx
> >performance for small sized frames. The reason driver have to
> >create a new checksum context when it uses multiple Tx queues comes
> >from hardware limitation. The controller tracks only for the last
> >context descriptor that was written such that driver does not know
> >the state of checksum context configured in other Tx queue.
> >Hope this helps.
> >
> >>
> >>
> >> ---Mike
> >>
> >>
> >> At 03:36 PM 7/2/2010, Pyun YongHyeon wrote:
> >> >On Fri, Jul 02, 2010 at 01:39:22PM -0400, Mike Tancsa wrote:
> >> >> Hi Jack,
> >> >> Just a followup to the email below. I now saw what appears
> >> >> to be the same problem on RELENG_8, but on a different nic and with
> >> >> VLANs.  So not sure if this is a general em problem, a problem
> >> >> specific to some em NICs, or a TSO problem in general.  The issue
> >> >> seemed to be triggered when I added a new vlan based on
> >> >>
> >> >> e...@pci0:14:0:0:class=0x02 card=0x109a15d9
> >> >> chip=0x109a8086 rev=0x00 hdr=0x00
> >> >> vendor = 'Intel Corporation'
> >> >> device = 'Intel PRO/1000 PL Network Adaptor (82573L)'
> >> >> 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 10[e0] = PCI-Express 1 endpoint max data 128(256) link x1(x1)
> >> >>
> >> >> pci14:  on pcib5
> >> >> em3:  port 0x6000-0x601f
> >> >> mem 0xe830-0xe831 irq 17 at device 0.0 on pci14
> >> >> em3: Using MSI interrupt
> >> >> em3: [FILTER]
> >> >> em3: Ethernet address: 00:30:48:9f:eb:81
> >> >>
> >> >> em3: flags=8943
> >> >> metric 0

Re: RELENG_7 em problems (and RELENG_8)

2010-09-24 Thread Jack Vogel

There is a new revision of the em driver coming next week, its going thru
some
stress pounding over the weekend, if no issues show up I'll put it into
HEAD.

Yongari's changes in TX context handling which effects checksum and tso
are added. I've also decided that multiple queues in 82574 just are a source
of problems without a lot of benefit, so it still uses MSIX but with only 3
vectors,
meaning it seperates TX and RX but has a single queue.

Its looking very stable, I hope it fixes everyone's issues.

Jack


On Tue, Sep 14, 2010 at 10:59 AM, Mike Tancsa  wrote:

> Hi Jack,
>Any plans to commit the patch below ? I have been running it on a
> number of boxes and it works as expected with no side effects.
>
>---Mike
>
>
>
> At 04:00 PM 8/17/2010, Pyun YongHyeon wrote:
>
>> On Tue, Aug 17, 2010 at 03:55:12PM -0400, Mike Tancsa wrote:
>> > At 02:52 PM 8/17/2010, Pyun YongHyeon wrote:
>> >
>> > >Here is updated patch for HEAD and stable/8.
>> > >http://people.freebsd.org/~yongari/em.csum_tso.20100817.patch
>> > >
>> > >It seems to work as expected under my limited environments. If
>> >
>> > Thanks! The patch applies cleanly and all works as expected now! I am
>> > no longer able to trigger the bug. I just use the stock unmodified
>> > driver normally, so no multi queues
>> >
>>
>> Glad to hear that. Thanks for testing!
>>
>> > # vmstat -i
>> > interrupt  total   rate
>> > irq256: em0  149  0
>> > irq257: em13  0
>> > irq259: em3  971  2
>> > irq260: ahci0   1520  3
>> >
>> >
>> >
>> > em3: flags=8843 metric 0 mtu
>> 1500
>> >
>> options=219b
>> > ether 00:15:17:xx:xx:xx
>> > inet6 fe80::215:17ff:fexx:%em3 prefixlen 64 scopeid 0x4
>> > inet 192.168.xx.xx netmask 0xff00 broadcast 192.168.xx.xx
>> > nd6 options=3
>> > media: Ethernet autoselect (100baseTX )
>> > status: active
>> >
>> >
>> > e...@pci0:3:0:0: class=0x02 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 enabled with 1 message
>> > 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
>> >
>> >
>> >
>> > patch < em.csum_tso.20100817.patch
>> > Hmm...  Looks like a unified diff to me...
>> > The text leading up to this was:
>> > --
>> > |Index: sys/dev/e1000/if_em.c
>> > |===
>> > |--- sys/dev/e1000/if_em.c  (revision 211398)
>> > |+++ sys/dev/e1000/if_em.c  (working copy)
>> > --
>> > Patching file sys/dev/e1000/if_em.c using Plan A...
>> > Hunk #1 succeeded at 237.
>> > Hunk #2 succeeded at 1730.
>> > Hunk #3 succeeded at 1759.
>> > Hunk #4 succeeded at 1930.
>> > Hunk #5 succeeded at 3148.
>> > Hunk #6 succeeded at 3351.
>> > Hunk #7 succeeded at 3533.
>> > Hunk #8 succeeded at 3590.
>> > Hunk #9 succeeded at 3603.
>> > Hmm...  The next patch looks like a unified diff to me...
>> > The text leading up to this was:
>> > --
>> > |Index: sys/dev/e1000/if_em.h
>> > |===
>> > |--- sys/dev/e1000/if_em.h  (revision 211398)
>> > |+++ sys/dev/e1000/if_em.h  (working copy)
>> > --
>> > Patching file sys/dev/e1000/if_em.h using Plan A...
>> > Hunk #1 succeeded at 284.
>> > done
>> >
>> > ---Mike
>> >
>> >
>> > >you're using multiple Tx queues with em(4) it would be better to
>> > >disable Tx checksum offloading as driver always have to create a
>> > >new checksum context for each frame. This will effectively disable
>> > >pipelined Tx data DMA which in turn greatly slows down Tx
>> > >performance for small sized frames. The reason driver have to
>> > >create a new checksum context when it uses multiple Tx queues comes
>> > >from hardware limitation. The controller tracks only for the last
>> > >context descriptor that was written such that driver does not know
>> > >the state of checksum context configured in other Tx queue.
>> > >Hope this helps.
>> > >
>> > >>
>> > >>
>> > >> ---Mike
>> > >>
>> > >>
>> > >> At 03:36 PM 7/2/2010, Pyun YongHyeon wrote:
>> > >> >On Fri, Jul 02, 2010 at 01:39:22PM -0400, Mike Tancsa wrote:
>> > >> >> Hi Jack,
>> > >> >> Just a followup to the email below. I now saw what appears
>> > >> >> to be the same problem on RELENG_8, but on a different nic and
>> with
>> > >> >> VLANs.  So not sure if this is a general e

Re: RELENG_7 em problems (and RELENG_8)

2010-09-26 Thread Mike Tancsa


At 06:36 PM 9/24/2010, Jack Vogel wrote:

There is a new revision of the em driver coming next week, its going thru some
stress pounding over the weekend, if no issues show up I'll put it into HEAD.

Yongari's changes in TX context handling which effects checksum and tso
are added. I've also decided that multiple queues in 82574 just are a source
of problems without a lot of benefit, so it still uses MSIX but with 
only 3 vectors,

meaning it seperates TX and RX but has a single queue.


Thanks, looking forward to trying it out!  With respect to the 
multiple queues, I thought the driver already used just the one on 
RELENG_8 ?  If not, is there a way to force the existing driver to 
use just the one queue ?


On the box that has the NIC locking up, it shows

e...@pci0:9:0:0: class=0x02 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 enabled with 1 message
cap 10[e0] = PCI-Express 1 endpoint max data 128(256) link x1(x1)

and

vmstat -i shows

irq256: em0  5129063353
irq257: em1   531251 36

in a wedged state, stats look like

dev.em.1.%desc: Intel(R) PRO/1000 Network Connection 7.0.5
dev.em.1.%driver: em
dev.em.1.%location: slot=0 function=0 handle=\_SB_.PCI0.PEX4.HART
dev.em.1.%pnpinfo: vendor=0x8086 device=0x10d3 subvendor=0x8086 
subdevice=0x34ec class=0x02

dev.em.1.%parent: pci9
dev.em.1.nvm: -1
dev.em.1.rx_int_delay: 0
dev.em.1.tx_int_delay: 66
dev.em.1.rx_abs_int_delay: 66
dev.em.1.tx_abs_int_delay: 66
dev.em.1.rx_processing_limit: 100
dev.em.1.link_irq: 0
dev.em.1.mbuf_alloc_fail: 0
dev.em.1.cluster_alloc_fail: 0
dev.em.1.dropped: 0
dev.em.1.tx_dma_fail: 0
dev.em.1.fc_high_water: 18432
dev.em.1.fc_low_water: 16932
dev.em.1.mac_stats.excess_coll: 0
dev.em.1.mac_stats.symbol_errors: 0
dev.em.1.mac_stats.sequence_errors: 0
dev.em.1.mac_stats.defer_count: 0
dev.em.1.mac_stats.missed_packets: 41522
dev.em.1.mac_stats.recv_no_buff: 19
dev.em.1.mac_stats.recv_errs: 0
dev.em.1.mac_stats.crc_errs: 0
dev.em.1.mac_stats.alignment_errs: 0
dev.em.1.mac_stats.coll_ext_errs: 0
dev.em.1.mac_stats.rx_overruns: 41398
dev.em.1.mac_stats.watchdog_timeouts: 0
dev.em.1.mac_stats.xon_recvd: 0
dev.em.1.mac_stats.xon_txd: 0
dev.em.1.mac_stats.xoff_recvd: 0
dev.em.1.mac_stats.xoff_txd: 0
dev.em.1.mac_stats.total_pkts_recvd: 95229129
dev.em.1.mac_stats.good_pkts_recvd: 95187607
dev.em.1.mac_stats.bcast_pkts_recvd: 79244
dev.em.1.mac_stats.mcast_pkts_recvd: 0
dev.em.1.mac_stats.rx_frames_64: 93680
dev.em.1.mac_stats.rx_frames_65_127: 1516349
dev.em.1.mac_stats.rx_frames_128_255: 4464941
dev.em.1.mac_stats.rx_frames_256_511: 4024
dev.em.1.mac_stats.rx_frames_512_1023: 2096067
dev.em.1.mac_stats.rx_frames_1024_1522: 87012546
dev.em.1.mac_stats.good_octets_recvd: 0
dev.em.1.mac_stats.good_octest_txd: 0
dev.em.1.mac_stats.total_pkts_txd: 66775098
dev.em.1.mac_stats.good_pkts_txd: 66775098
dev.em.1.mac_stats.bcast_pkts_txd: 509
dev.em.1.mac_stats.mcast_pkts_txd: 7
dev.em.1.mac_stats.tx_frames_64: 48038472
dev.em.1.mac_stats.tx_frames_65_127: 13402833
dev.em.1.mac_stats.tx_frames_128_255: 5324413
dev.em.1.mac_stats.tx_frames_256_511: 957
dev.em.1.mac_stats.tx_frames_512_1023: 319
dev.em.1.mac_stats.tx_frames_1024_1522: 8104
dev.em.1.mac_stats.tso_txd: 1069
dev.em.1.mac_stats.tso_ctx_fail: 0
dev.em.1.interrupts.asserts: 0
dev.em.1.interrupts.rx_pkt_timer: 0
dev.em.1.interrupts.rx_abs_timer: 0
dev.em.1.interrupts.tx_pkt_timer: 0
dev.em.1.interrupts.tx_abs_timer: 0
dev.em.1.interrupts.tx_queue_empty: 0
dev.em.1.interrupts.tx_queue_min_thresh: 0
dev.em.1.interrupts.rx_desc_min_thresh: 0
dev.em.1.interrupts.rx_overrun: 0
dev.em.1.host.breaker_tx_pkt: 0
dev.em.1.host.host_tx_pkt_discard: 0
dev.em.1.host.rx_pkt: 0
dev.em.1.host.breaker_rx_pkts: 0
dev.em.1.host.breaker_rx_pkt_drop: 0
dev.em.1.host.tx_good_pkt: 0
dev.em.1.host.breaker_tx_pkt_drop: 0
dev.em.1.host.rx_good_bytes: 0
dev.em.1.host.tx_good_bytes: 0
dev.em.1.host.length_errors: 0
dev.em.1.host.serdes_violation_pkt: 0
dev.em.1.host.header_redir_missed: 0

ifconfig down/up just panics or locks up the box when its in this 
state.  I also have IPMI enabled on this nic, but it shows the same 
issue with it disabled.


---Mike



Mike Tancsa,  tel +1 519 651 3400
Sentex Communications,m...@sentex.net
Providing Internet since 1994www.sentex.net
Cambridge, Ontario Canada www.sentex.net/mike

___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-st

Re: RELENG_7 em problems (and RELENG_8)

2010-09-26 Thread Jack Vogel

The NIC has 5 MSIX vectors and can have 2 queues, I have been trying to
release code with both queues active, but its been unstable, I finally
concluded
its not worth the aggrevation :)

Your em1 is using MSI not MSIX and thus can't have multiple queues. I'm
not sure whats broken from what you show here. I will try to get the new
driver out shortly for you to try.

Jack


On Sun, Sep 26, 2010 at 2:57 PM, Mike Tancsa  wrote:

> At 06:36 PM 9/24/2010, Jack Vogel wrote:
>
>> There is a new revision of the em driver coming next week, its going thru
>> some
>> stress pounding over the weekend, if no issues show up I'll put it into
>> HEAD.
>>
>> Yongari's changes in TX context handling which effects checksum and tso
>> are added. I've also decided that multiple queues in 82574 just are a
>> source
>> of problems without a lot of benefit, so it still uses MSIX but with only
>> 3 vectors,
>> meaning it seperates TX and RX but has a single queue.
>>
>
> Thanks, looking forward to trying it out!  With respect to the multiple
> queues, I thought the driver already used just the one on RELENG_8 ?  If
> not, is there a way to force the existing driver to use just the one queue ?
>
> On the box that has the NIC locking up, it shows
>
> e...@pci0:9:0:0: class=0x02 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 enabled with 1 message
>cap 10[e0] = PCI-Express 1 endpoint max data 128(256) link x1(x1)
>
> and
>
> vmstat -i shows
>
> irq256: em0  5129063353
> irq257: em1   531251 36
>
> in a wedged state, stats look like
>
> dev.em.1.%desc: Intel(R) PRO/1000 Network Connection 7.0.5
> dev.em.1.%driver: em
> dev.em.1.%location: slot=0 function=0 handle=\_SB_.PCI0.PEX4.HART
> dev.em.1.%pnpinfo: vendor=0x8086 device=0x10d3 subvendor=0x8086
> subdevice=0x34ec class=0x02
> dev.em.1.%parent: pci9
> dev.em.1.nvm: -1
> dev.em.1.rx_int_delay: 0
> dev.em.1.tx_int_delay: 66
> dev.em.1.rx_abs_int_delay: 66
> dev.em.1.tx_abs_int_delay: 66
> dev.em.1.rx_processing_limit: 100
> dev.em.1.link_irq: 0
> dev.em.1.mbuf_alloc_fail: 0
> dev.em.1.cluster_alloc_fail: 0
> dev.em.1.dropped: 0
> dev.em.1.tx_dma_fail: 0
> dev.em.1.fc_high_water: 18432
> dev.em.1.fc_low_water: 16932
> dev.em.1.mac_stats.excess_coll: 0
> dev.em.1.mac_stats.symbol_errors: 0
> dev.em.1.mac_stats.sequence_errors: 0
> dev.em.1.mac_stats.defer_count: 0
> dev.em.1.mac_stats.missed_packets: 41522
> dev.em.1.mac_stats.recv_no_buff: 19
> dev.em.1.mac_stats.recv_errs: 0
> dev.em.1.mac_stats.crc_errs: 0
> dev.em.1.mac_stats.alignment_errs: 0
> dev.em.1.mac_stats.coll_ext_errs: 0
> dev.em.1.mac_stats.rx_overruns: 41398
> dev.em.1.mac_stats.watchdog_timeouts: 0
> dev.em.1.mac_stats.xon_recvd: 0
> dev.em.1.mac_stats.xon_txd: 0
> dev.em.1.mac_stats.xoff_recvd: 0
> dev.em.1.mac_stats.xoff_txd: 0
> dev.em.1.mac_stats.total_pkts_recvd: 95229129
> dev.em.1.mac_stats.good_pkts_recvd: 95187607
> dev.em.1.mac_stats.bcast_pkts_recvd: 79244
> dev.em.1.mac_stats.mcast_pkts_recvd: 0
> dev.em.1.mac_stats.rx_frames_64: 93680
> dev.em.1.mac_stats.rx_frames_65_127: 1516349
> dev.em.1.mac_stats.rx_frames_128_255: 4464941
> dev.em.1.mac_stats.rx_frames_256_511: 4024
> dev.em.1.mac_stats.rx_frames_512_1023: 2096067
> dev.em.1.mac_stats.rx_frames_1024_1522: 87012546
> dev.em.1.mac_stats.good_octets_recvd: 0
> dev.em.1.mac_stats.good_octest_txd: 0
> dev.em.1.mac_stats.total_pkts_txd: 66775098
> dev.em.1.mac_stats.good_pkts_txd: 66775098
> dev.em.1.mac_stats.bcast_pkts_txd: 509
> dev.em.1.mac_stats.mcast_pkts_txd: 7
> dev.em.1.mac_stats.tx_frames_64: 48038472
> dev.em.1.mac_stats.tx_frames_65_127: 13402833
> dev.em.1.mac_stats.tx_frames_128_255: 5324413
> dev.em.1.mac_stats.tx_frames_256_511: 957
> dev.em.1.mac_stats.tx_frames_512_1023: 319
> dev.em.1.mac_stats.tx_frames_1024_1522: 8104
> dev.em.1.mac_stats.tso_txd: 1069
> dev.em.1.mac_stats.tso_ctx_fail: 0
> dev.em.1.interrupts.asserts: 0
> dev.em.1.interrupts.rx_pkt_timer: 0
> dev.em.1.interrupts.rx_abs_timer: 0
> dev.em.1.interrupts.tx_pkt_timer: 0
> dev.em.1.interrupts.tx_abs_timer: 0
> dev.em.1.interrupts.tx_queue_empty: 0
> dev.em.1.interrupts.tx_queue_min_thresh: 0
> dev.em.1.interrupts.rx_desc_min_thresh: 0
> dev.em.1.interrupts.rx_overrun: 0
> dev.em.1.host.breaker_tx_pkt: 0
> dev.em.1.host.host_tx_pkt_discard: 0
> dev.em.1.host.rx_pkt: 0
> dev.em.1.host.breaker_rx_pkts: 0
> dev.em.1.host.breaker_rx_pkt_drop: 0
> dev.em.1.host.tx_good_pkt: 0
> dev.em.1.host.breaker_tx_pkt_drop: 0
> dev.em.1.host.rx_good_bytes: 0
> dev.em.1.host.tx_good_bytes: 0
> dev.em.1.host.length_errors: 0
> dev.em.1.host.serdes_violation_pkt: 0
> dev.em.1.host.header_redir_missed: 0
>
> ifconfig down/up just panics or locks up the box whe

Re: RELENG_7 em problems (and RELENG_8)

2010-09-26 Thread Mike Tancsa


At 06:19 PM 9/26/2010, Jack Vogel wrote:

Your em1 is using MSI not MSIX and thus can't have multiple queues. I'm
not sure whats broken from what you show here. I will try to get the new
driver out shortly for you to try.


With this particular NIC, it will wedge under high load.  I tried 2 
different motherboards and chipsets the same behaviour.


---Mike



Jack


On Sun, Sep 26, 2010 at 2:57 PM, Mike Tancsa 
<m...@sentex.net> wrote:

At 06:36 PM 9/24/2010, Jack Vogel wrote:
There is a new revision of the em driver coming next week, its going thru some
stress pounding over the weekend, if no issues show up I'll put it into HEAD.

Yongari's changes in TX context handling which effects checksum and tso
are added. I've also decided that multiple queues in 82574 just are a source
of problems without a lot of benefit, so it still uses MSIX but with 
only 3 vectors,

meaning it seperates TX and RX but has a single queue.


Thanks, looking forward to trying it out!  With respect to the 
multiple queues, I thought the driver already used just the one on 
RELENG_8 ?  If not, is there a way to force the existing driver to 
use just the one queue ?


On the box that has the NIC locking up, it shows

e...@pci0:9:0:0: class=0x02 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 enabled with 1 message
   cap 10[e0] = PCI-Express 1 endpoint max data 128(256) link x1(x1)

and

vmstat -i shows

irq256: em0  5129063353
irq257: em1   531251 36

in a wedged state, stats look like

dev.em.1.%desc: Intel(R) PRO/1000 Network Connection 7.0.5
dev.em.1.%driver: em
dev.em.1.%location: slot=0 function=0 handle=\_SB_.PCI0.PEX4.HART
dev.em.1.%pnpinfo: vendor=0x8086 device=0x10d3 subvendor=0x8086 
subdevice=0x34ec class=0x02

dev.em.1.%parent: pci9
dev.em.1.nvm: -1
dev.em.1.rx_int_delay: 0
dev.em.1.tx_int_delay: 66
dev.em.1.rx_abs_int_delay: 66
dev.em.1.tx_abs_int_delay: 66
dev.em.1.rx_processing_limit: 100
dev.em.1.link_irq: 0
dev.em.1.mbuf_alloc_fail: 0
dev.em.1.cluster_alloc_fail: 0
dev.em.1.dropped: 0
dev.em.1.tx_dma_fail: 0
dev.em.1.fc_high_water: 18432
dev.em.1.fc_low_water: 16932
dev.em.1.mac_stats.excess_coll: 0
dev.em.1.mac_stats.symbol_errors: 0
dev.em.1.mac_stats.sequence_errors: 0
dev.em.1.mac_stats.defer_count: 0
dev.em.1.mac_stats.missed_packets: 41522
dev.em.1.mac_stats.recv_no_buff: 19
dev.em.1.mac_stats.recv_errs: 0
dev.em.1.mac_stats.crc_errs: 0
dev.em.1.mac_stats.alignment_errs: 0
dev.em.1.mac_stats.coll_ext_errs: 0
dev.em.1.mac_stats.rx_overruns: 41398
dev.em.1.mac_stats.watchdog_timeouts: 0
dev.em.1.mac_stats.xon_recvd: 0
dev.em.1.mac_stats.xon_txd: 0
dev.em.1.mac_stats.xoff_recvd: 0
dev.em.1.mac_stats.xoff_txd: 0
dev.em.1.mac_stats.total_pkts_recvd: 95229129
dev.em.1.mac_stats.good_pkts_recvd: 95187607
dev.em.1.mac_stats.bcast_pkts_recvd: 79244
dev.em.1.mac_stats.mcast_pkts_recvd: 0
dev.em.1.mac_stats.rx_frames_64: 93680
dev.em.1.mac_stats.rx_frames_65_127: 1516349
dev.em.1.mac_stats.rx_frames_128_255: 4464941
dev.em.1.mac_stats.rx_frames_256_511: 4024
dev.em.1.mac_stats.rx_frames_512_1023: 2096067
dev.em.1.mac_stats.rx_frames_1024_1522: 87012546
dev.em.1.mac_stats.good_octets_recvd: 0
dev.em.1.mac_stats.good_octest_txd: 0
dev.em.1.mac_stats.total_pkts_txd: 66775098
dev.em.1.mac_stats.good_pkts_txd: 66775098
dev.em.1.mac_stats.bcast_pkts_txd: 509
dev.em.1.mac_stats.mcast_pkts_txd: 7
dev.em.1.mac_stats.tx_frames_64: 48038472
dev.em.1.mac_stats.tx_frames_65_127: 13402833
dev.em.1.mac_stats.tx_frames_128_255: 5324413
dev.em.1.mac_stats.tx_frames_256_511: 957
dev.em.1.mac_stats.tx_frames_512_1023: 319
dev.em.1.mac_stats.tx_frames_1024_1522: 8104
dev.em.1.mac_stats.tso_txd: 1069
dev.em.1.mac_stats.tso_ctx_fail: 0
dev.em.1.interrupts.asserts: 0
dev.em.1.interrupts.rx_pkt_timer: 0
dev.em.1.interrupts.rx_abs_timer: 0
dev.em.1.interrupts.tx_pkt_timer: 0
dev.em.1.interrupts.tx_abs_timer: 0
dev.em.1.interrupts.tx_queue_empty: 0
dev.em.1.interrupts.tx_queue_min_thresh: 0
dev.em.1.interrupts.rx_desc_min_thresh: 0
dev.em.1.interrupts.rx_overrun: 0
dev.em.1.host.breaker_tx_pkt: 0
dev.em.1.host.host_tx_pkt_discard: 0
dev.em.1.host.rx_pkt: 0
dev.em.1.host.breaker_rx_pkts: 0
dev.em.1.host.breaker_rx_pkt_drop: 0
dev.em.1.host.tx_good_pkt: 0
dev.em.1.host.breaker_tx_pkt_drop: 0
dev.em.1.host.rx_good_bytes: 0
dev.em.1.host.tx_good_bytes: 0
dev.em.1.host.length_errors: 0
dev.em.1.host.serdes_violation_pkt: 0
dev.em.1.host.header_redir_missed: 0

ifconfig down/up just panics or locks up the box when its in this 
state.  I also have IPMI enabled on this nic, but it shows the same 
issue with it disabled.


   ---Mike



---

Re: RELENG_7 em problems (and RELENG_8)

2010-09-26 Thread Jack Vogel

The system I've had stress tests running on has 82574 LOMs, so I hope it
will solve the problem, will see tomorrow morning at how things have held
up...

Jack


On Sun, Sep 26, 2010 at 4:43 PM, Mike Tancsa  wrote:

> At 06:19 PM 9/26/2010, Jack Vogel wrote:
>
>> Your em1 is using MSI not MSIX and thus can't have multiple queues. I'm
>> not sure whats broken from what you show here. I will try to get the new
>> driver out shortly for you to try.
>>
>
> With this particular NIC, it will wedge under high load.  I tried 2
> different motherboards and chipsets the same behaviour.
>
>---Mike
>
>
>  Jack
>>
>>
>>
>> On Sun, Sep 26, 2010 at 2:57 PM, Mike Tancsa <
>> m...@sentex.net> wrote:
>> At 06:36 PM 9/24/2010, Jack Vogel wrote:
>> There is a new revision of the em driver coming next week, its going thru
>> some
>> stress pounding over the weekend, if no issues show up I'll put it into
>> HEAD.
>>
>> Yongari's changes in TX context handling which effects checksum and tso
>> are added. I've also decided that multiple queues in 82574 just are a
>> source
>> of problems without a lot of benefit, so it still uses MSIX but with only
>> 3 vectors,
>> meaning it seperates TX and RX but has a single queue.
>>
>>
>> Thanks, looking forward to trying it out!  With respect to the multiple
>> queues, I thought the driver already used just the one on RELENG_8 ?  If
>> not, is there a way to force the existing driver to use just the one queue ?
>>
>> On the box that has the NIC locking up, it shows
>>
>> e...@pci0:9:0:0: class=0x02 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 enabled with 1 message
>>   cap 10[e0] = PCI-Express 1 endpoint max data 128(256) link x1(x1)
>>
>> and
>>
>> vmstat -i shows
>>
>> irq256: em0  5129063353
>> irq257: em1   531251 36
>>
>> in a wedged state, stats look like
>>
>> dev.em.1.%desc: Intel(R) PRO/1000 Network Connection 7.0.5
>> dev.em.1.%driver: em
>> dev.em.1.%location: slot=0 function=0 handle=\_SB_.PCI0.PEX4.HART
>> dev.em.1.%pnpinfo: vendor=0x8086 device=0x10d3 subvendor=0x8086
>> subdevice=0x34ec class=0x02
>> dev.em.1.%parent: pci9
>> dev.em.1.nvm: -1
>> dev.em.1.rx_int_delay: 0
>> dev.em.1.tx_int_delay: 66
>> dev.em.1.rx_abs_int_delay: 66
>> dev.em.1.tx_abs_int_delay: 66
>> dev.em.1.rx_processing_limit: 100
>> dev.em.1.link_irq: 0
>> dev.em.1.mbuf_alloc_fail: 0
>> dev.em.1.cluster_alloc_fail: 0
>> dev.em.1.dropped: 0
>> dev.em.1.tx_dma_fail: 0
>> dev.em.1.fc_high_water: 18432
>> dev.em.1.fc_low_water: 16932
>> dev.em.1.mac_stats.excess_coll: 0
>> dev.em.1.mac_stats.symbol_errors: 0
>> dev.em.1.mac_stats.sequence_errors: 0
>> dev.em.1.mac_stats.defer_count: 0
>> dev.em.1.mac_stats.missed_packets: 41522
>> dev.em.1.mac_stats.recv_no_buff: 19
>> dev.em.1.mac_stats.recv_errs: 0
>> dev.em.1.mac_stats.crc_errs: 0
>> dev.em.1.mac_stats.alignment_errs: 0
>> dev.em.1.mac_stats.coll_ext_errs: 0
>> dev.em.1.mac_stats.rx_overruns: 41398
>> dev.em.1.mac_stats.watchdog_timeouts: 0
>> dev.em.1.mac_stats.xon_recvd: 0
>> dev.em.1.mac_stats.xon_txd: 0
>> dev.em.1.mac_stats.xoff_recvd: 0
>> dev.em.1.mac_stats.xoff_txd: 0
>> dev.em.1.mac_stats.total_pkts_recvd: 95229129
>> dev.em.1.mac_stats.good_pkts_recvd: 95187607
>> dev.em.1.mac_stats.bcast_pkts_recvd: 79244
>> dev.em.1.mac_stats.mcast_pkts_recvd: 0
>> dev.em.1.mac_stats.rx_frames_64: 93680
>> dev.em.1.mac_stats.rx_frames_65_127: 1516349
>> dev.em.1.mac_stats.rx_frames_128_255: 4464941
>> dev.em.1.mac_stats.rx_frames_256_511: 4024
>> dev.em.1.mac_stats.rx_frames_512_1023: 2096067
>> dev.em.1.mac_stats.rx_frames_1024_1522: 87012546
>> dev.em.1.mac_stats.good_octets_recvd: 0
>> dev.em.1.mac_stats.good_octest_txd: 0
>> dev.em.1.mac_stats.total_pkts_txd: 66775098
>> dev.em.1.mac_stats.good_pkts_txd: 66775098
>> dev.em.1.mac_stats.bcast_pkts_txd: 509
>> dev.em.1.mac_stats.mcast_pkts_txd: 7
>> dev.em.1.mac_stats.tx_frames_64: 48038472
>> dev.em.1.mac_stats.tx_frames_65_127: 13402833
>> dev.em.1.mac_stats.tx_frames_128_255: 5324413
>> dev.em.1.mac_stats.tx_frames_256_511: 957
>> dev.em.1.mac_stats.tx_frames_512_1023: 319
>> dev.em.1.mac_stats.tx_frames_1024_1522: 8104
>> dev.em.1.mac_stats.tso_txd: 1069
>> dev.em.1.mac_stats.tso_ctx_fail: 0
>> dev.em.1.interrupts.asserts: 0
>> dev.em.1.interrupts.rx_pkt_timer: 0
>> dev.em.1.interrupts.rx_abs_timer: 0
>> dev.em.1.interrupts.tx_pkt_timer: 0
>> dev.em.1.interrupts.tx_abs_timer: 0
>> dev.em.1.interrupts.tx_queue_empty: 0
>> dev.em.1.interrupts.tx_queue_min_thresh: 0
>> dev.em.1.interrupts.rx_desc_min_thresh: 0
>> dev.em.1.interrupts.rx_overrun: 0
>> dev.em.1.host.breaker_tx_pkt: 0
>> dev.em.1.host.host_tx_pkt_discard: 0
>> dev.em.1.host.rx_p

Re: RELENG_7 em problems (and RELENG_8)

2010-09-30 Thread Mike Tancsa


At 08:00 PM 9/26/2010, Jack Vogel wrote:

The system I've had stress tests running on has 82574 LOMs, so I hope it
will solve the problem, will see tomorrow morning at how things have held
up...


I pulled a copy of sys/dev/e1000 from HEAD and copied onto my 
RELENG_8 box. I had another nic lock up last night :(  Anyways, now 
running with the driver from HEAD on RELENG_8 amd64


em0:  port 0x4040-0x405f 
mem 0xb440-0xb441,0xb4425000-0xb4425fff irq 16 at device 25.0 on pci0

em0: Using an MSI interrupt
em0: [FILTER]
em0: Ethernet address: 00:15:17:ed:68:a5


em1:  port 0x2000-0x201f 
mem 0xb410-0xb411,0xb412-0xb4123fff irq 16 at device 0.0 on pci9

em1: Using MSIX interrupts with 3 vectors
em1: [ITHREAD]
em1: [ITHREAD]
em1: [ITHREAD]
em1: Ethernet address: 00:15:17:ed:68:a4

e...@pci0:0:25:0:class=0x02 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

e...@pci0:9:0:0: class=0x02 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
ecap 0001[100] = AER 1 0 fatal 0 non-fatal 0 corrected
ecap 0003[140] = Serial 1 001517ed68a4


interrupt  total   rate
irq4: uart0 2283  6
irq16: siis04332 11
irq18: arcmsr0137175372
irq19: twa018805 51
irq21: ehci02734  7
irq23: ehci1 675  1
cpu0: timer   733804   1994
irq256: em073195198
irq257: em1:rx 0 238  0
irq258: em1:tx 0  37  0
irq260: ahci0   4328 11
cpu1: timer   725637   1971
cpu3: timer   725709   1972
cpu2: timer   725688   1971
Total3154640   8572


---Mike


Jack


On Sun, Sep 26, 2010 at 4:43 PM, Mike Tancsa 
<m...@sentex.net> wrote:

At 06:19 PM 9/26/2010, Jack Vogel wrote:
Your em1 is using MSI not MSIX and thus can't have multiple queues. I'm
not sure whats broken from what you show here. I will try to get the new
driver out shortly for you to try.


With this particular NIC, it will wedge under high load.  I tried 2 
different motherboards and chipsets the same behaviour.


   ---Mike


Jack



On Sun, Sep 26, 2010 at 2:57 PM, Mike Tancsa 
<m...@sentex.net> wrote:

At 06:36 PM 9/24/2010, Jack Vogel wrote:
There is a new revision of the em driver coming next week, its going thru some
stress pounding over the weekend, if no issues show up I'll put it into HEAD.

Yongari's changes in TX context handling which effects checksum and tso
are added. I've also decided that multiple queues in 82574 just are a source
of problems without a lot of benefit, so it still uses MSIX but with 
only 3 vectors,

meaning it seperates TX and RX but has a single queue.


Thanks, looking forward to trying it out!  With respect to the 
multiple queues, I thought the driver already used just the one on 
RELENG_8 ?  If not, is there a way to force the existing driver to 
use just the one queue ?


On the box that has the NIC locking up, it shows

e...@pci0:9:0:0: class=0x02 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 enabled with 1 message
  cap 10[e0] = PCI-Express 1 endpoint max data 128(256) link x1(x1)

and

vmstat -i shows

irq256: em0  5129063353
irq257: em1   531251 36

in a wedged state, stats look like

dev.em.1.%desc: Intel(R) PRO/1000 Network Connection 7.0.5
dev.em.1.%driver: em
dev.em.1.%location: slot=0 function=0 handle=\_SB_.PCI0.PEX4.HART
dev.em.1.%pnpinfo: vendor=0x8086 device=0x10d3 subvendor=0x8086 
subdevice=0x34ec class=0x02

dev.em.1.%parent: pci9
dev.em.1.nvm: -1
dev.em.1.rx_int_delay: 0
dev.em.1.tx_int_delay: 66
dev.em.1.rx_abs_int_delay: 66
dev.em.1.tx_abs_int_delay: 66
dev.em.1.rx_processing_limit: 100
dev.em.1.link_irq:

Re: RELENG_7 em problems (and RELENG_8)

2010-10-02 Thread Mike Tancsa



Hi Jack,
Two quick notes about the new driver.

On the server that was having nic lockups, so far so good.  Saturday 
AM, the box would take a lot of level0 dumps as well as do about 
70Mb/s of outbound rsync traffic.  By now, the nic would have wedged 
at least once So far so good!



On different, new box, I decided to try HEAD, with the new driver, 
and ran into problems with the onboard nic


e...@pci0:0:25:0:class=0x02 card=0x00368086 
chip=0x10f08086 rev=0x06 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

em0:  port 0xf020-0xf03f 
mem 0xfe50-0xfe51,0xfe527000-0xfe527fff irq 20 at device 25.0 on pci0

em0: Using MSI interrupt
em0: [FILTER]
em0: Ethernet address: 70:71:bc:09:5e:aa

This is an intel branded desktop board

acpi0:  on motherboard

I find I have to disable rx and tx csum on the interface, otherwise 
there are a lot of re-transmits due to missed packets.  tcpdump 
implies the packets are going out, but it seems never to get 
out.  The mother board is at the office on an unmanaged switch right 
now, so I dont have any stats from the switch.  But tcpdump shows a 
lot of outbound re-transmits. Turning off rxcsum and txcsum fixes the problem.


dev.em.0.%desc: Intel(R) PRO/1000 Network Connection 7.0.8
dev.em.0.%driver: em
dev.em.0.%location: slot=25 function=0 handle=\_SB_.PCI0.GBE_
dev.em.0.%pnpinfo: vendor=0x8086 device=0x10f0 subvendor=0x8086 
subdevice=0x0036 class=0x02

dev.em.0.%parent: pci0
dev.em.0.nvm: -1
dev.em.0.rx_int_delay: 0
dev.em.0.tx_int_delay: 66
dev.em.0.rx_abs_int_delay: 66
dev.em.0.tx_abs_int_delay: 66
dev.em.0.rx_processing_limit: 100
dev.em.0.link_irq: 0
dev.em.0.mbuf_alloc_fail: 0
dev.em.0.cluster_alloc_fail: 0
dev.em.0.dropped: 0
dev.em.0.tx_dma_fail: 0
dev.em.0.rx_overruns: 0
dev.em.0.watchdog_timeouts: 0
dev.em.0.device_control: 1074790976
dev.em.0.rx_control: 67141634
dev.em.0.fc_high_water: 8192
dev.em.0.fc_low_water: 6692
dev.em.0.queue0.txd_head: 15
dev.em.0.queue0.txd_tail: 17
dev.em.0.queue0.tx_irq: 0
dev.em.0.queue0.no_desc_avail: 0
dev.em.0.queue0.rxd_head: 843
dev.em.0.queue0.rxd_tail: 842
dev.em.0.queue0.rx_irq: 0
dev.em.0.mac_stats.excess_coll: 0
dev.em.0.mac_stats.single_coll: 0
dev.em.0.mac_stats.multiple_coll: 0
dev.em.0.mac_stats.late_coll: 0
dev.em.0.mac_stats.collision_count: 0
dev.em.0.mac_stats.symbol_errors: 0
dev.em.0.mac_stats.sequence_errors: 0
dev.em.0.mac_stats.defer_count: 0
dev.em.0.mac_stats.missed_packets: 0
dev.em.0.mac_stats.recv_no_buff: 0
dev.em.0.mac_stats.recv_undersize: 0
dev.em.0.mac_stats.recv_fragmented: 0
dev.em.0.mac_stats.recv_oversize: 0
dev.em.0.mac_stats.recv_jabber: 0
dev.em.0.mac_stats.recv_errs: 0
dev.em.0.mac_stats.crc_errs: 0
dev.em.0.mac_stats.alignment_errs: 0
dev.em.0.mac_stats.coll_ext_errs: 0
dev.em.0.mac_stats.xon_recvd: 80
dev.em.0.mac_stats.xon_txd: 0
dev.em.0.mac_stats.xoff_recvd: 82
dev.em.0.mac_stats.xoff_txd: 0
dev.em.0.mac_stats.total_pkts_recvd: 35697
dev.em.0.mac_stats.good_pkts_recvd: 35535
dev.em.0.mac_stats.bcast_pkts_recvd: 231
dev.em.0.mac_stats.mcast_pkts_recvd: 85
dev.em.0.mac_stats.rx_frames_64: 0
dev.em.0.mac_stats.rx_frames_65_127: 0
dev.em.0.mac_stats.rx_frames_128_255: 0
dev.em.0.mac_stats.rx_frames_256_511: 0
dev.em.0.mac_stats.rx_frames_512_1023: 0
dev.em.0.mac_stats.rx_frames_1024_1522: 0
dev.em.0.mac_stats.good_octets_recvd: 14878015
dev.em.0.mac_stats.good_octets_txd: 14051783
dev.em.0.mac_stats.total_pkts_txd: 45313
dev.em.0.mac_stats.good_pkts_txd: 45313
dev.em.0.mac_stats.bcast_pkts_txd: 3
dev.em.0.mac_stats.mcast_pkts_txd: 5
dev.em.0.mac_stats.tx_frames_64: 0
dev.em.0.mac_stats.tx_frames_65_127: 0
dev.em.0.mac_stats.tx_frames_128_255: 0
dev.em.0.mac_stats.tx_frames_256_511: 0
dev.em.0.mac_stats.tx_frames_512_1023: 0
dev.em.0.mac_stats.tx_frames_1024_1522: 0
dev.em.0.mac_stats.tso_txd: 2788
dev.em.0.mac_stats.tso_ctx_fail: 0
dev.em.0.interrupts.asserts: 48733
dev.em.0.interrupts.rx_pkt_timer: 0
dev.em.0.interrupts.rx_abs_timer: 0
dev.em.0.interrupts.tx_pkt_timer: 0
dev.em.0.interrupts.tx_abs_timer: 0
dev.em.0.interrupts.tx_queue_empty: 0
dev.em.0.interrupts.tx_queue_min_thresh: 0
dev.em.0.interrupts.rx_desc_min_thresh: 0
dev.em.0.interrupts.rx_overrun: 0
dev.em.0.wake: 0



At 08:00 PM 9/26/2010, Jack Vogel wrote:

The system I've had stress tests running on has 82574 LOMs, so I hope it
will solve the problem, will see tomorrow morning at how things have held
up...

Jack


On Sun, Sep 26, 2010 at 4:43 PM, Mike Tancsa 
<m...@sentex.net> wrote:

At 06:19 PM 9/26/2010, Jack Vogel wrote:
Your em1 is using MSI not MSIX and thus can't have multiple queues. I'm
not sure whats broken from what you show here. I will try to get the new
driver out shortly for you to try.


With this particular NIC, it will wedge un

Re: RELENG_7 em problems (and RELENG_8)

2010-11-07 Thread Mike Tancsa



Just for the archives, the version of
http://lists.freebsd.org/pipermail/svn-src-head/2010-November/022058.html 



fixes this particular problem on this particular version of the em 
nic for me on RELENG_8. The motherboard is an intel server board (S3420GPX)


e...@pci0:10:0:0:class=0x02 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
ecap 0001[100] = AER 1 0 fatal 0 non-fatal 0 corrected
ecap 0003[140] = Serial 1 001517ed68a4

em1:  port 0x2000-0x201f 
mem 0xb410-0xb411,0xb412-0xb4123fff irq 16 at device 0.0 on pci10

em1: Using MSIX interrupts with 3 vectors


vmstat -i
interrupt  total   rate
irq256: em0   1025859018993
irq257: em1:rx 0   512606295496
irq258: em1:tx 0   405695908393
irq259: em1:link   39853  0
Total10422193166  10096


---Mike


At 06:43 PM 9/26/2010, Mike Tancsa wrote:

At 06:19 PM 9/26/2010, Jack Vogel wrote:

Your em1 is using MSI not MSIX and thus can't have multiple queues. I'm
not sure whats broken from what you show here. I will try to get the new
driver out shortly for you to try.


With this particular NIC, it will wedge under high load.  I tried 2 
different motherboards and chipsets the same behaviour.


---Mike



Jack


On Sun, Sep 26, 2010 at 2:57 PM, Mike Tancsa 
<m...@sentex.net> wrote:

At 06:36 PM 9/24/2010, Jack Vogel wrote:
There is a new revision of the em driver coming next week, its 
going thru some

stress pounding over the weekend, if no issues show up I'll put it into HEAD.

Yongari's changes in TX context handling which effects checksum and tso
are added. I've also decided that multiple queues in 82574 just are a source
of problems without a lot of benefit, so it still uses MSIX but 
with only 3 vectors,

meaning it seperates TX and RX but has a single queue.


Thanks, looking forward to trying it out!  With respect to the 
multiple queues, I thought the driver already used just the one on 
RELENG_8 ?  If not, is there a way to force the existing driver to 
use just the one queue ?


On the box that has the NIC locking up, it shows

e...@pci0:9:0:0: class=0x02 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 enabled with 1 message
   cap 10[e0] = PCI-Express 1 endpoint max data 128(256) link x1(x1)

and

vmstat -i shows

irq256: em0  5129063353
irq257: em1   531251 36

in a wedged state, stats look like

dev.em.1.%desc: Intel(R) PRO/1000 Network Connection 7.0.5
dev.em.1.%driver: em
dev.em.1.%location: slot=0 function=0 handle=\_SB_.PCI0.PEX4.HART
dev.em.1.%pnpinfo: vendor=0x8086 device=0x10d3 subvendor=0x8086 
subdevice=0x34ec class=0x02

dev.em.1.%parent: pci9
dev.em.1.nvm: -1
dev.em.1.rx_int_delay: 0
dev.em.1.tx_int_delay: 66
dev.em.1.rx_abs_int_delay: 66
dev.em.1.tx_abs_int_delay: 66
dev.em.1.rx_processing_limit: 100
dev.em.1.link_irq: 0
dev.em.1.mbuf_alloc_fail: 0
dev.em.1.cluster_alloc_fail: 0
dev.em.1.dropped: 0
dev.em.1.tx_dma_fail: 0
dev.em.1.fc_high_water: 18432
dev.em.1.fc_low_water: 16932
dev.em.1.mac_stats.excess_coll: 0
dev.em.1.mac_stats.symbol_errors: 0
dev.em.1.mac_stats.sequence_errors: 0
dev.em.1.mac_stats.defer_count: 0
dev.em.1.mac_stats.missed_packets: 41522
dev.em.1.mac_stats.recv_no_buff: 19
dev.em.1.mac_stats.recv_errs: 0
dev.em.1.mac_stats.crc_errs: 0
dev.em.1.mac_stats.alignment_errs: 0
dev.em.1.mac_stats.coll_ext_errs: 0
dev.em.1.mac_stats.rx_overruns: 41398
dev.em.1.mac_stats.watchdog_timeouts: 0
dev.em.1.mac_stats.xon_recvd: 0
dev.em.1.mac_stats.xon_txd: 0
dev.em.1.mac_stats.xoff_recvd: 0
dev.em.1.mac_stats.xoff_txd: 0
dev.em.1.mac_stats.total_pkts_recvd: 95229129
dev.em.1.mac_stats.good_pkts_recvd: 95187607
dev.em.1.mac_stats.bcast_pkts_recvd: 79244
dev.em.1.mac_stats.mcast_pkts_recvd: 0
dev.em.1.mac_stats.rx_frames_64: 93680
dev.em.1.mac_stats.rx_frames_65_127: 1516349
dev.em.1.mac_stats.rx_frames_128_255: 4464941
dev.em.1.mac_stats.rx_frames_256_511: 4024
dev.em.1.mac_stats.rx_frames_512_1023: 2096067
dev.em.1.mac_stats.rx_frames_1024_1522: 87012546
dev.em.1.mac_stats.good_octets_recvd: 0
dev.em.1.mac_stats.good_octest_txd: 0
dev.em.1

Re: RELENG_7 em problems (and RELENG_8)

2010-11-23 Thread Mike Tancsa

Again, for the archives, this problem is sadly still here.  Although 
it appears to happen a little less frequently with the driver from 
HEAD. It seems it might be some issue specific to power savings, as 
LINUX users seem to have the same issues


http://sourceforge.net/tracker/index.php?func=detail&aid=2908463&group_id=42302&atid=447449 



Also

http://lists.freebsd.org/pipermail/freebsd-net/2010-November/027044.html 



has similar reports.  Also disabling msix does not seem to make a difference.

---Mike


At 12:22 PM 11/7/2010, Mike Tancsa wrote:


Just for the archives, the version of
http://lists.freebsd.org/pipermail/svn-src-head/2010-November/022058.html 



fixes this particular problem on this particular version of the em 
nic for me on RELENG_8. The motherboard is an intel server board (S3420GPX)


e...@pci0:10:0:0:class=0x02 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
ecap 0001[100] = AER 1 0 fatal 0 non-fatal 0 corrected
ecap 0003[140] = Serial 1 001517ed68a4

em1:  port 0x2000-0x201f 
mem 0xb410-0xb411,0xb412-0xb4123fff irq 16 at device 0.0 on pci10

em1: Using MSIX interrupts with 3 vectors


vmstat -i
interrupt  total   rate
irq256: em0   1025859018993
irq257: em1:rx 0   512606295496
irq258: em1:tx 0   405695908393
irq259: em1:link   39853  0
Total10422193166  10096


---Mike


At 06:43 PM 9/26/2010, Mike Tancsa wrote:

At 06:19 PM 9/26/2010, Jack Vogel wrote:

Your em1 is using MSI not MSIX and thus can't have multiple queues. I'm
not sure whats broken from what you show here. I will try to get the new
driver out shortly for you to try.


With this particular NIC, it will wedge under high load.  I tried 2 
different motherboards and chipsets the same behaviour.


---Mike



Jack


On Sun, Sep 26, 2010 at 2:57 PM, Mike Tancsa 
<m...@sentex.net> wrote:

At 06:36 PM 9/24/2010, Jack Vogel wrote:
There is a new revision of the em driver coming next week, its 
going thru some
stress pounding over the weekend, if no issues show up I'll put it 
into HEAD.


Yongari's changes in TX context handling which effects checksum and tso
are added. I've also decided that multiple queues in 82574 just are a source
of problems without a lot of benefit, so it still uses MSIX but 
with only 3 vectors,

meaning it seperates TX and RX but has a single queue.


Thanks, looking forward to trying it out!  With respect to the 
multiple queues, I thought the driver already used just the one on 
RELENG_8 ?  If not, is there a way to force the existing driver to 
use just the one queue ?


On the box that has the NIC locking up, it shows

e...@pci0:9:0:0: class=0x02 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 enabled with 1 message
   cap 10[e0] = PCI-Express 1 endpoint max data 128(256) link x1(x1)

and

vmstat -i shows

irq256: em0  5129063353
irq257: em1   531251 36

in a wedged state, stats look like

dev.em.1.%desc: Intel(R) PRO/1000 Network Connection 7.0.5
dev.em.1.%driver: em
dev.em.1.%location: slot=0 function=0 handle=\_SB_.PCI0.PEX4.HART
dev.em.1.%pnpinfo: vendor=0x8086 device=0x10d3 subvendor=0x8086 
subdevice=0x34ec class=0x02

dev.em.1.%parent: pci9
dev.em.1.nvm: -1
dev.em.1.rx_int_delay: 0
dev.em.1.tx_int_delay: 66
dev.em.1.rx_abs_int_delay: 66
dev.em.1.tx_abs_int_delay: 66
dev.em.1.rx_processing_limit: 100
dev.em.1.link_irq: 0
dev.em.1.mbuf_alloc_fail: 0
dev.em.1.cluster_alloc_fail: 0
dev.em.1.dropped: 0
dev.em.1.tx_dma_fail: 0
dev.em.1.fc_high_water: 18432
dev.em.1.fc_low_water: 16932
dev.em.1.mac_stats.excess_coll: 0
dev.em.1.mac_stats.symbol_errors: 0
dev.em.1.mac_stats.sequence_errors: 0
dev.em.1.mac_stats.defer_count: 0
dev.em.1.mac_stats.missed_packets: 41522
dev.em.1.mac_stats.recv_no_buff: 19
dev.em.1.mac_stats.recv_errs: 0
dev.em.1.mac_stats.crc_errs: 0
dev.em.1.mac_stats.alignment_errs: 0
dev.em.1.mac_stats.coll_ext_errs

Re: RELENG_7 em problems (and RELENG_8)

Re: RELENG_7 em problems (and RELENG_8)

Re: RELENG_7 em problems (and RELENG_8)

Re: RELENG_7 em problems (and RELENG_8)

Re: RELENG_7 em problems (and RELENG_8)

Re: RELENG_7 em problems (and RELENG_8)

Re: RELENG_7 em problems (and RELENG_8)

Re: RELENG_7 em problems (and RELENG_8)

Re: RELENG_7 em problems (and RELENG_8)

Re: RELENG_7 em problems (and RELENG_8)

Re: RELENG_7 em problems (and RELENG_8)

Re: RELENG_7 em problems (and RELENG_8)

Re: RELENG_7 em problems (and RELENG_8)

Re: RELENG_7 em problems (and RELENG_8)

Re: RELENG_7 em problems (and RELENG_8)

Re: RELENG_7 em problems (and RELENG_8)

Re: RELENG_7 em problems (and RELENG_8)

Re: RELENG_7 em problems (and RELENG_8)

Re: RELENG_7 em problems (and RELENG_8)

Re: RELENG_7 em problems (and RELENG_8)

Re: RELENG_7 em problems (and RELENG_8)

Re: RELENG_7 em problems (and RELENG_8)

Re: RELENG_7 em problems (and RELENG_8)

Re: RELENG_7 em problems (and RELENG_8)

Re: RELENG_7 em problems (and RELENG_8)

25 matches

Site Navigation

Mail list logo

Footer information