Re: em driver, 82574L chip, and possibly ASPM
On 11/23/2010 7:47 AM, Ivan Voras wrote: > It looks like I'm unfortunate enough to have to deploy on a machine > which has the 82574L Intel NIC chip on a Supermicro X8SIE-F board, which > apparently has hardware issues, according to this thread: > > http://sourceforge.net/tracker/index.php?func=detail&aid=2908463&group_id=42302&atid=447449 > > Interesting, this is the same nic that has been giving me grief! Mine is on an Intel server board (S3420GPX). The symptoms are VERY similar to what the LINUX user sees as well with RX errors and the traffic patterns. ---Mike > One of the proposed workarounds is disabling "Active State Power > Management" in the BIOS and in the OS. > > I have disabled it in BIOS but I don't know how to disable it in FreeBSD > (apparently only disabling it in BIOS isn't enough). > > Any ideas on how to achieve the effect in FreeBSD? > > ___ > freebsd-...@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org" > > ___ freebsd-hardware@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hardware To unsubscribe, send any mail to "freebsd-hardware-unsubscr...@freebsd.org"
Re: em driver, 82574L chip, and possibly ASPM
On 23-11-2010 13:47, Ivan Voras wrote: > It looks like I'm unfortunate enough to have to deploy on a machine > which has the 82574L Intel NIC chip on a Supermicro X8SIE-F board, which > apparently has hardware issues, according to this thread: I have a Supermicro X7SPE-HF board with two onboard Intel 82574L nics and I see the same thing. The nics seem to "die" if I push enough data through them and the only way to recover is to reboot. I noticed this a few days ago and I haven't had any time to investigate more, so I guess this is just a "me too"... -- Joel ___ freebsd-hardware@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hardware To unsubscribe, send any mail to "freebsd-hardware-unsubscr...@freebsd.org"
Re: em driver, 82574L chip, and possibly ASPM
On 11/23/2010 8:16 AM, Ivan Voras wrote:
> On 11/23/10 14:03, Mike Tancsa wrote:
>> On 11/23/2010 7:47 AM, Ivan Voras wrote:
>>> It looks like I'm unfortunate enough to have to deploy on a machine
>>> which has the 82574L Intel NIC chip on a Supermicro X8SIE-F board, which
>>> apparently has hardware issues, according to this thread:
>>>
>>> http://sourceforge.net/tracker/index.php?func=detail&aid=2908463&group_id=42302&atid=447449
>>>
>>>
>>>
>>
>> Interesting, this is the same nic that has been giving me grief! Mine is
>> on an Intel server board (S3420GPX). The symptoms are VERY similar to
>> what the LINUX user sees as well with RX errors and the traffic patterns.
>
> I've posted detailed info on this NIC in the thread "em card wedging" -
> can you compare it with yours?
>
> The whole thing looks very sensitive to BIOS settings. I've just toggled
> something that looked unrelated (don't remember what, I've been toggling
> BIOS settings all day) and the machine has been doing a flood-ping for
> 20 minutes without wedging (which doesn't mean it won't wedge as soon as
> I send this message, it did such things before).
I posted whats in the BIOS at
http://www.tancsa.com/82574.html
Unfortunately, if I disable the BIOS option highlighted I can no longer
netboot the box :( For my production box having the issues, this is not
a problem. But it makes it difficult for testing on my lab box. I am
not sure if that even really disables IPMI ? Also on this box whats
NIC1 and NIC2 is the opposite of what FreeBSD sees as em0 and em1.
So far I have tried
Driver from HEAD -- This seems to help a bit in that wedges are less
disable MSIX - no difference, still hangs
It seems the nic will get one error and never recover. There will just
be a steady stream of them. On the other onboard nic (a different type
of em), the card will see the odd "no_buff" error, but it recovers like
all the other em nics. Where as this problem nic, gets errors and they
just keep on going up and up. Using the driver from HEAD, I can do an
ifconfig em1 down;sleep 1;ifconfig em1 up and that fixes the problem
dev.em.1.mac_stats.missed_packets: 1292
dev.em.1.mac_stats.recv_no_buff: 31
where as previous versions of the driver would panic the box doing that.
Looking at the driver from HEAD, there does seem to be some mention of
ASPM. Is this what the LINUX driver is doing too ?
/* PCI-Ex Control Registers */
switch (hw->mac.type) {
case e1000_82574:
case e1000_82583:
reg = E1000_READ_REG(hw, E1000_GCR);
reg |= (1 << 22);
E1000_WRITE_REG(hw, E1000_GCR, reg);
/*
* Workaround for hardware errata.
* apply workaround for hardware errata documented in errata
* docs Fixes issue where some error prone or unreliable
PCIe
* completions are occurring, particularly with ASPM
enabled.
* Without fix, issue can cause tx timeouts.
*/
reg = E1000_READ_REG(hw, E1000_GCR2);
reg |= 1;
E1000_WRITE_REG(hw, E1000_GCR2, reg);
break;
default:
break;
}
return;
---Mike
___
freebsd-hardware@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hardware
To unsubscribe, send any mail to "freebsd-hardware-unsubscr...@freebsd.org"
Re: em driver, 82574L chip, and possibly ASPM
On Tue, 2010-11-23 at 04:47 -0800, Ivan Voras wrote: > It looks like I'm unfortunate enough to have to deploy on a machine > which has the 82574L Intel NIC chip on a Supermicro X8SIE-F board, which > apparently has hardware issues, according to this thread: > > http://sourceforge.net/tracker/index.php?func=detail&aid=2908463&group_id=42302&atid=447449 > > One of the proposed workarounds is disabling "Active State Power > Management" in the BIOS and in the OS. > > I have disabled it in BIOS but I don't know how to disable it in FreeBSD > (apparently only disabling it in BIOS isn't enough). > > Any ideas on how to achieve the effect in FreeBSD? > > ___ > freebsd-...@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org" Can I get an example pciconf -lv off of a couple of machines? I've been seeing some "issues" here at big purple that are similar. Sean mine: i...@pci0:5:0:0:class=0x02 card=0x8975152d chip=0x10c98086 rev=0x01 hdr=0x00 vendor = 'Intel Corporation' class = network subclass = ethernet i...@pci0:5:0:1:class=0x02 card=0x8975152d chip=0x10c98086 rev=0x01 hdr=0x00 vendor = 'Intel Corporation' class = network subclass = ethernet ___ freebsd-hardware@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hardware To unsubscribe, send any mail to "freebsd-hardware-unsubscr...@freebsd.org"
Re: em driver, 82574L chip, and possibly ASPM
On 11/23/2010 12:39 PM, Sean Bruno wrote: > On Tue, 2010-11-23 at 04:47 -0800, Ivan Voras wrote: >> It looks like I'm unfortunate enough to have to deploy on a machine >> which has the 82574L Intel NIC chip on a Supermicro X8SIE-F board, which > i...@pci0:5:0:0:class=0x02 card=0x8975152d chip=0x10c98086 Strange, the 82574 attaches as em for me, not igb 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 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 ecap 0001[100] = AER 1 0 fatal 0 non-fatal 0 corrected ecap 0003[140] = Serial 1 001517ed68a4 Normally, its msix, but I had disabled that hoping it would fix the problem em1: port 0x2000-0x201f mem 0xb410-0xb411,0xb412-0xb4123fff irq 16 at dev ice 0.0 on pci10 em1: Using an MSI interrupt em1: [FILTER] em1: Ethernet address: 00:15:17:ed:68:a4 ---Mike ___ freebsd-hardware@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hardware To unsubscribe, send any mail to "freebsd-hardware-unsubscr...@freebsd.org"
Re: em driver, 82574L chip, and possibly ASPM
Those are 82576, not 82574, totally different hardware. Would you please test the new driver that will be going into HEAD today, I'd like to see testing on it as much as possible for a few days. Cheers, Jack On Tue, Nov 23, 2010 at 9:39 AM, Sean Bruno wrote: > On Tue, 2010-11-23 at 04:47 -0800, Ivan Voras wrote: > > It looks like I'm unfortunate enough to have to deploy on a machine > > which has the 82574L Intel NIC chip on a Supermicro X8SIE-F board, which > > apparently has hardware issues, according to this thread: > > > > > http://sourceforge.net/tracker/index.php?func=detail&aid=2908463&group_id=42302&atid=447449 > > > > One of the proposed workarounds is disabling "Active State Power > > Management" in the BIOS and in the OS. > > > > I have disabled it in BIOS but I don't know how to disable it in FreeBSD > > (apparently only disabling it in BIOS isn't enough). > > > > Any ideas on how to achieve the effect in FreeBSD? > > > > ___ > > freebsd-...@freebsd.org mailing list > > http://lists.freebsd.org/mailman/listinfo/freebsd-net > > To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org" > > Can I get an example pciconf -lv off of a couple of machines? I've been > seeing some "issues" here at big purple that are similar. > > Sean > > mine: > > i...@pci0:5:0:0:class=0x02 card=0x8975152d chip=0x10c98086 > rev=0x01 hdr=0x00 >vendor = 'Intel Corporation' >class = network >subclass = ethernet > i...@pci0:5:0:1:class=0x02 card=0x8975152d chip=0x10c98086 > rev=0x01 hdr=0x00 >vendor = 'Intel Corporation' >class = network >subclass = ethernet > > > ___ > freebsd-...@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org" > ___ freebsd-hardware@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hardware To unsubscribe, send any mail to "freebsd-hardware-unsubscr...@freebsd.org"
Re: em driver, 82574L chip, and possibly ASPM
82574 is supposed to be em, not igb :) Its always had this kind of 'in-between' status, it was targeted as a 'client' or consumer part, but it has MSIX which make it almost like 8257[56]. Mike, there are some further 82574 changes to shared code that I'm looking into today. Jack On Tue, Nov 23, 2010 at 10:17 AM, Mike Tancsa wrote: > On 11/23/2010 12:39 PM, Sean Bruno wrote: > > On Tue, 2010-11-23 at 04:47 -0800, Ivan Voras wrote: > >> It looks like I'm unfortunate enough to have to deploy on a machine > >> which has the 82574L Intel NIC chip on a Supermicro X8SIE-F board, which > > i...@pci0:5:0:0:class=0x02 card=0x8975152d chip=0x10c98086 > > Strange, the 82574 attaches as em for me, not igb > > 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 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 > ecap 0001[100] = AER 1 0 fatal 0 non-fatal 0 corrected > ecap 0003[140] = Serial 1 001517ed68a4 > > Normally, its msix, but I had disabled that hoping it would fix the problem > > em1: port 0x2000-0x201f mem > 0xb410-0xb411,0xb412-0xb4123fff irq 16 at dev > ice 0.0 on pci10 > em1: Using an MSI interrupt > em1: [FILTER] > em1: Ethernet address: 00:15:17:ed:68:a4 > > >---Mike > ___ > freebsd-...@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org" > ___ freebsd-hardware@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hardware To unsubscribe, send any mail to "freebsd-hardware-unsubscr...@freebsd.org"
Re: em driver, 82574L chip, and possibly ASPM
On 23 November 2010 18:39, Sean Bruno wrote: > On Tue, 2010-11-23 at 04:47 -0800, Ivan Voras wrote: >> It looks like I'm unfortunate enough to have to deploy on a machine >> which has the 82574L Intel NIC chip on a Supermicro X8SIE-F board, which >> apparently has hardware issues, according to this thread: >> >> http://sourceforge.net/tracker/index.php?func=detail&aid=2908463&group_id=42302&atid=447449 >> >> One of the proposed workarounds is disabling "Active State Power >> Management" in the BIOS and in the OS. >> >> I have disabled it in BIOS but I don't know how to disable it in FreeBSD >> (apparently only disabling it in BIOS isn't enough). >> >> Any ideas on how to achieve the effect in FreeBSD? > Can I get an example pciconf -lv off of a couple of machines? I've been > seeing some "issues" here at big purple that are similar. > i...@pci0:5:0:0: class=0x02 card=0x8975152d chip=0x10c98086 > rev=0x01 hdr=0x00 > vendor = 'Intel Corporation' > class = network > subclass = ethernet > i...@pci0:5:0:1: class=0x02 card=0x8975152d chip=0x10c98086 > rev=0x01 hdr=0x00 > vendor = 'Intel Corporation' > class = network > subclass = ethernet Not the same card, mine is on the em driver. http://permalink.gmane.org/gmane.os.freebsd.devel.hardware/7584 ___ freebsd-hardware@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hardware To unsubscribe, send any mail to "freebsd-hardware-unsubscr...@freebsd.org"
Re: em driver, 82574L chip, and possibly ASPM
hi Ivan and Mike, wanted to follow up and see if you found a solid long-term solution to this bug. we are still seeing this problem in our 8.2 environment with ASPM already disabled. here is what we have: 1. motherboard is SuperMicro X8SIE-LN4F Intel Xeon: e...@pci0:3:0:0: class=0x02 card=0x040d15d9 chip=0x10d38086 rev=0x00 hdr=0x00 vendor = 'Intel Corporation' device = 'Intel 82574L Gigabit Ethernet Controller (82574L)' class = network subclass = ethernet e...@pci0:4:0:0: class=0x02 card=0x040d15d9 chip=0x10d38086 rev=0x00 hdr=0x00 vendor = 'Intel Corporation' device = 'Intel 82574L Gigabit Ethernet Controller (82574L)' class = network subclass = ethernet e...@pci0:5:0:0: class=0x02 card=0x040d15d9 chip=0x10d38086 rev=0x00 hdr=0x00 vendor = 'Intel Corporation' device = 'Intel 82574L Gigabit Ethernet Controller (82574L)' class = network subclass = ethernet e...@pci0:6:0:0: class=0x02 card=0x040d15d9 chip=0x10d38086 rev=0x00 hdr=0x00 vendor = 'Intel Corporation' device = 'Intel 82574L Gigabit Ethernet Controller (82574L)' class = network subclass = ethernet 2. ASPM is already disabled in the BIOS 3. when em1 interface locks up, sysctl debug says: Interface is NOT RUNNING and INACTIVE em1: hw tdh = 0, hw tdt = 0 em1: hw rdh = 0, hw rdt = 0 em1: Tx Queue Status = 0 em1: TX descriptors avail = 110 em1: Tx Descriptors avail failure = 319 em1: RX discarded packets = 0 em1: RX Next to Check = 80 em1: RX Next to Refresh = 80 4. doing "ifconfig em1 down; sleep1; ifconfig em1 up" resolves the issue and removes OACTIVE flag from em1. 5. we are running 8.2-PRERELEASE from December 19th: % grep '$FreeBSD' /usr/src/sys/dev/e1000/if_em.c /*$FreeBSD: src/sys/dev/e1000/if_em.c,v 1.21.2.18 2010/12/14 19:59:39 jfv Exp $*/ dmesg output is: em1: port 0xcc00-0xcc1f mem 0xfb4e-0xfb4f,0xfb4dc000-0xfb4d irq 17 at device 0.0 on pci4 em1: Reserved 0x2 bytes for rid 0x10 type 3 at 0xfb4e em1: Reserved 0x4000 bytes for rid 0x1c type 3 at 0xfb4dc000 em1: attempting to allocate 3 MSI-X vectors (5 supported) msi: routing MSI-X IRQ 259 to local APIC 0 vector 53 msi: routing MSI-X IRQ 260 to local APIC 0 vector 54 msi: routing MSI-X IRQ 261 to local APIC 0 vector 55 em1: using IRQs 259-261 for MSI-X em1: Using MSIX interrupts with 3 vectors em1: [MPSAFE] em1: [ITHREAD] em1: [MPSAFE] em1: [ITHREAD] em1: [MPSAFE] em1: [ITHREAD] em1: bpf attached em1: Ethernet address: 00:25:90:0e:25:e9 aside from running cronjob every minute to check for dead interface and reset it, is there anything else we can try? thanks. On Tue, Nov 23, 2010 at 10:36 AM, Jack Vogel wrote: > 82574 is supposed to be em, not igb :) Its always had this kind of > 'in-between' > status, it was targeted as a 'client' or consumer part, but it has MSIX > which > make it almost like 8257[56]. > > Mike, there are some further 82574 changes to shared code that I'm looking > into today. > > Jack > > > On Tue, Nov 23, 2010 at 10:17 AM, Mike Tancsa wrote: > > > On 11/23/2010 12:39 PM, Sean Bruno wrote: > > > On Tue, 2010-11-23 at 04:47 -0800, Ivan Voras wrote: > > >> It looks like I'm unfortunate enough to have to deploy on a machine > > >> which has the 82574L Intel NIC chip on a Supermicro X8SIE-F board, > which > > > i...@pci0:5:0:0:class=0x02 card=0x8975152d chip=0x10c98086 > > > > Strange, the 82574 attaches as em for me, not igb > > > > 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 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 > > ecap 0001[100] = AER 1 0 fatal 0 non-fatal 0 corrected > > ecap 0003[140] = Serial 1 001517ed68a4 > > > > Normally, its msix, but I had disabled that hoping it would fix the > problem > > > > em1: port 0x2000-0x201f mem > > 0xb410-0xb411,0xb412-0xb4123fff irq 16 at dev > > ice 0.0 on pci10 > > em1: Using an MSI interrupt > > em1: [FILTER] > > em1: Ethernet address: 00:15:17:ed:68:a4 > > > > > >---Mike > > ___ > > freebsd-...@freebsd.org mailing list > > http://lists.freebsd.org/mailman/listinfo/freebsd-net > > To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org" > > > ___ > freebsd-hardware@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hardware > To unsubscribe, send any mail to "freebsd-hardware-unsubscr...@freebsd.org > " > ___ freeb
Re: em driver, 82574L chip, and possibly ASPM
On 24 December 2010 23:44, Jan Koum wrote: > > hi Ivan and Mike, > wanted to follow up and see if you found a solid long-term solution to this > bug. we are still seeing this problem in our 8.2 environment with ASPM > already disabled. here is what we have: Hi, The patches Jack made when this discussion was ongoing helped both me and AFAIK Mike also. The machine I had which exhibited these problems now works fine and stable. The patches should have been MFCed, but just in case - try the version from 9-current. During testing, I've also found that the BIOS setting "Remap PCI memory" or "Remap device memory" or something like that (I can't look it up now) also helps if disabled. Mike AFAIK didn't have this setting in his machine's BIOS. ___ freebsd-hardware@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hardware To unsubscribe, send any mail to "freebsd-hardware-unsubscr...@freebsd.org"
Re: em driver, 82574L chip, and possibly ASPM
On 12/24/2010 5:44 PM, Jan Koum wrote: > hi Ivan and Mike, > > wanted to follow up and see if you found a solid long-term solution to this > bug. we are still seeing this problem in our 8.2 environment with ASPM > already disabled. here is what we have: Hmmm, With the latest version of the driver in RELENG_8 (its the same as in HEAD) I havent seen the problem. However, I would only see it once per week prior to that. The odd thing is that it would happen during a slightly lower than normal backup load, but almost always at the same time (early sunday AM). Not sure what would trigger it exactly. If it happened again, I was going to enable port mirroring on the switchport and capture the traffic, hoping some "special" pattern would enable the issue. Do you have IPMI enabled on the NIC ? I tried to turn it off on my MB, but there is no clear way to do this. It 'seems' to be off, but not sure if it really is. One thing I noticed was that when the NIC was hung, it still was able to receive and process IPMI commands from an external host. ---Mike > > 1. motherboard is SuperMicro X8SIE-LN4F Intel Xeon: > > e...@pci0:3:0:0: class=0x02 card=0x040d15d9 chip=0x10d38086 rev=0x00 > hdr=0x00 > vendor = 'Intel Corporation' > device = 'Intel 82574L Gigabit Ethernet Controller (82574L)' > class = network > subclass = ethernet > e...@pci0:4:0:0: class=0x02 card=0x040d15d9 chip=0x10d38086 rev=0x00 > hdr=0x00 > vendor = 'Intel Corporation' > device = 'Intel 82574L Gigabit Ethernet Controller (82574L)' > class = network > subclass = ethernet > e...@pci0:5:0:0: class=0x02 card=0x040d15d9 chip=0x10d38086 rev=0x00 > hdr=0x00 > vendor = 'Intel Corporation' > device = 'Intel 82574L Gigabit Ethernet Controller (82574L)' > class = network > subclass = ethernet > e...@pci0:6:0:0: class=0x02 card=0x040d15d9 chip=0x10d38086 rev=0x00 > hdr=0x00 > vendor = 'Intel Corporation' > device = 'Intel 82574L Gigabit Ethernet Controller (82574L)' > class = network > subclass = ethernet > > 2. ASPM is already disabled in the BIOS > > 3. when em1 interface locks up, sysctl debug says: > > Interface is NOT RUNNING > and INACTIVE > em1: hw tdh = 0, hw tdt = 0 > em1: hw rdh = 0, hw rdt = 0 > em1: Tx Queue Status = 0 > em1: TX descriptors avail = 110 > em1: Tx Descriptors avail failure = 319 > em1: RX discarded packets = 0 > em1: RX Next to Check = 80 > em1: RX Next to Refresh = 80 > > 4. doing "ifconfig em1 down; sleep1; ifconfig em1 up" resolves the issue and > removes OACTIVE flag from em1. > > 5. we are running 8.2-PRERELEASE from December 19th: > % grep '$FreeBSD' /usr/src/sys/dev/e1000/if_em.c > /*$FreeBSD: src/sys/dev/e1000/if_em.c,v 1.21.2.18 2010/12/14 19:59:39 jfv > Exp $*/ > > dmesg output is: > > em1: port 0xcc00-0xcc1f mem > 0xfb4e-0xfb4f,0xfb4dc000-0xfb4d irq 17 at device 0.0 on pci4 > em1: Reserved 0x2 bytes for rid 0x10 type 3 at 0xfb4e > em1: Reserved 0x4000 bytes for rid 0x1c type 3 at 0xfb4dc000 > em1: attempting to allocate 3 MSI-X vectors (5 supported) > msi: routing MSI-X IRQ 259 to local APIC 0 vector 53 > msi: routing MSI-X IRQ 260 to local APIC 0 vector 54 > msi: routing MSI-X IRQ 261 to local APIC 0 vector 55 > em1: using IRQs 259-261 for MSI-X > em1: Using MSIX interrupts with 3 vectors > em1: [MPSAFE] > em1: [ITHREAD] > em1: [MPSAFE] > em1: [ITHREAD] > em1: [MPSAFE] > em1: [ITHREAD] > em1: bpf attached > em1: Ethernet address: 00:25:90:0e:25:e9 > > aside from running cronjob every minute to check for dead interface and > reset it, is there anything else we can try? > > thanks. > > > On Tue, Nov 23, 2010 at 10:36 AM, Jack Vogel wrote: > >> 82574 is supposed to be em, not igb :) Its always had this kind of >> 'in-between' >> status, it was targeted as a 'client' or consumer part, but it has MSIX >> which >> make it almost like 8257[56]. >> >> Mike, there are some further 82574 changes to shared code that I'm looking >> into today. >> >> Jack >> >> >> On Tue, Nov 23, 2010 at 10:17 AM, Mike Tancsa wrote: >> >>> On 11/23/2010 12:39 PM, Sean Bruno wrote: On Tue, 2010-11-23 at 04:47 -0800, Ivan Voras wrote: > It looks like I'm unfortunate enough to have to deploy on a machine > which has the 82574L Intel NIC chip on a Supermicro X8SIE-F board, >> which i...@pci0:5:0:0:class=0x02 card=0x8975152d chip=0x10c98086 >>> >>> Strange, the 82574 attaches as em for me, not igb >>> >>> 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 enabled with 1 message >>>cap 10[e0] = PCI-Express 1 endp
Re: em driver, 82574L chip, and possibly ASPM
On 12/24/2010 5:44 PM, Jan Koum wrote: > hi Ivan and Mike, > > wanted to follow up and see if you found a solid long-term solution to this > bug. we are still seeing this problem in our 8.2 environment with ASPM > already disabled. here is what we have: > > 1. motherboard is SuperMicro X8SIE-LN4F Intel Xeon: > Hi Jack, Looks like this problem is not completely gone :( I have seen it now on 2 different machines. On the RELENG_7, ASPM was enabled in the BIOS (INTEL DH55TC MB), so I have disabled that for now to see what happens. On the RELENG_8 machine, its been a LOT better since 7.1.8, but again it happened last night during a backup dev.em.1.%desc: Intel(R) PRO/1000 Network Connection 7.1.8 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: pci10 dev.em.1.nvm: -1 dev.em.1.debug: -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.flow_control: 3 dev.em.1.link_irq: 346 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.rx_overruns: 0 dev.em.1.watchdog_timeouts: 0 dev.em.1.device_control: 1209008712 dev.em.1.rx_control: 67141634 dev.em.1.fc_high_water: 18432 dev.em.1.fc_low_water: 16932 dev.em.1.queue0.txd_head: 231 dev.em.1.queue0.txd_tail: 231 dev.em.1.queue0.tx_irq: 828804317 dev.em.1.queue0.no_desc_avail: 0 dev.em.1.queue0.rxd_head: 692 dev.em.1.queue0.rxd_tail: 691 dev.em.1.queue0.rx_irq: 1035962009 dev.em.1.mac_stats.excess_coll: 0 dev.em.1.mac_stats.single_coll: 0 dev.em.1.mac_stats.multiple_coll: 0 dev.em.1.mac_stats.late_coll: 0 dev.em.1.mac_stats.collision_count: 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: 395 dev.em.1.mac_stats.recv_no_buff: 22 dev.em.1.mac_stats.recv_undersize: 0 dev.em.1.mac_stats.recv_fragmented: 0 dev.em.1.mac_stats.recv_oversize: 0 dev.em.1.mac_stats.recv_jabber: 0 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.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: 2374779279 dev.em.1.mac_stats.good_pkts_recvd: 2374778884 dev.em.1.mac_stats.bcast_pkts_recvd: 91866 dev.em.1.mac_stats.mcast_pkts_recvd: 14709 dev.em.1.mac_stats.rx_frames_64: 3694217 dev.em.1.mac_stats.rx_frames_65_127: 42644392 dev.em.1.mac_stats.rx_frames_128_255: 52724116 dev.em.1.mac_stats.rx_frames_256_511: 768263 dev.em.1.mac_stats.rx_frames_512_1023: 28549934 dev.em.1.mac_stats.rx_frames_1024_1522: 2246397962 dev.em.1.mac_stats.good_octets_recvd: 3420561094673 dev.em.1.mac_stats.good_octets_txd: 130129757787 dev.em.1.mac_stats.total_pkts_txd: 1553568635 dev.em.1.mac_stats.good_pkts_txd: 1553568635 dev.em.1.mac_stats.bcast_pkts_txd: 13131 dev.em.1.mac_stats.mcast_pkts_txd: 9 dev.em.1.mac_stats.tx_frames_64: 564243380 dev.em.1.mac_stats.tx_frames_65_127: 864123029 dev.em.1.mac_stats.tx_frames_128_255: 119250324 dev.em.1.mac_stats.tx_frames_256_511: 240369 dev.em.1.mac_stats.tx_frames_512_1023: 554247 dev.em.1.mac_stats.tx_frames_1024_1522: 5157286 dev.em.1.mac_stats.tso_txd: 1216433 dev.em.1.mac_stats.tso_ctx_fail: 0 dev.em.1.interrupts.asserts: 51 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 em1: flags=8843 metric 0 mtu 1500 options=219b ether 00:15:17:ed:68:a4 inet xx.yy.13.254 netmask 0xff00 broadcast zz.yy.13.255 inet6 fe80::215:17ff:feed:68a4%em1 prefixlen 64 scopeid 0x3 inet xx.zz.1.1 netmask 0xff00 broadcast xx.zz.1.255 inet6 2607:f3e0:xx prefixlen 64 nd6 options=3 media: Ethernet autoselect (1000baseT ) status: active 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 The MB is an INTEL S3420GPX ---Mike ___ freebsd-hardware@freebsd.org mailing list htt
Re: em driver, 82574L chip, and possibly ASPM
On Tue, Jan 11, 2011 at 6:04 AM, Mike Tancsa wrote: > On 12/24/2010 5:44 PM, Jan Koum wrote: > > hi Ivan and Mike, > > > > wanted to follow up and see if you found a solid long-term solution to > this > > bug. we are still seeing this problem in our 8.2 environment with ASPM > > already disabled. here is what we have: > > > > 1. motherboard is SuperMicro X8SIE-LN4F Intel Xeon: > > > > Hi Jack, >Looks like this problem is not completely gone :( Dear Mike and Jack, sadly the problem is not gone for us either. here is what we know so far: - we are running latest e1000 drivers from 8.2 - we have ASPM disabled and we have the following bios settings: http://camel.ethereal.net/~jkb/bios/ - we have updated our BIOS and IPMI to the latest firmware available from our ISP - we added hw.em.rxd=4096 and hw.em.txd=4096 to loader.conf (thanks Sean for this tip -- these settings made problem happen much less frequently but didn't go away completely) the ONLY thing sort of saving our butts right now is this cron job that runs every minute: if /sbin/ping -q -c 10 www.google.com> /dev/null; then echo "OK" >> /tmp/em1.out else date >> /tmp/em1.out echo "broken" >> /tmp/em1.out /sbin/ifconfig em1 down sleep 3 /sbin/ifconfig em1 up fi this is obviously no way to run a high performance web servers in a long term. as mentioned in my previous emails, let us know if you need any further information or if you have any debug code you want us to run in production. we are willing to do pretty much anything to get this issue fixed thanks ___ freebsd-hardware@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hardware To unsubscribe, send any mail to "freebsd-hardware-unsubscr...@freebsd.org"
Re: em driver, 82574L chip, and possibly ASPM
On 1/21/2011 4:21 AM, Jan Koum wrote: > > > Dear Mike and Jack, > > sadly the problem is not gone for us either. here is what we know so far: Same here. There was a new BIOS from Intel for our motherboard (INTEL S3420GPX), but had another hang last night. Debug below. I will try the newer driver Monday. One other thing I noticed is that when the nic is in its hung state, the WOL option is gone ? e.g em1: flags=8843 metric 0 mtu 1500 options=19b ether 00:15:17:ed:68:a4 vs em1: flags=8843 metric 0 mtu 1500 options=219b ether 00:15:17:ed:68:a4 Interface is RUNNING and INACTIVE em1: hw tdh = 75, hw tdt = 75 em1: hw rdh = 771, hw rdt = 771 em1: Tx Queue Status = 0 em1: TX descriptors avail = 1024 em1: Tx Descriptors avail failure = 0 em1: RX discarded packets = 0 em1: RX Next to Check = 771 em1: RX Next to Refresh = 772 em1: link state changed to DOWN em1: link state changed to UP dev.em.1.%desc: Intel(R) PRO/1000 Network Connection 7.1.8 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: pci10 dev.em.1.nvm: -1 dev.em.1.debug: -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.flow_control: 3 dev.em.1.link_irq: 563 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.rx_overruns: 0 dev.em.1.watchdog_timeouts: 0 dev.em.1.device_control: 1209008712 dev.em.1.rx_control: 67141634 dev.em.1.fc_high_water: 18432 dev.em.1.fc_low_water: 16932 dev.em.1.queue0.txd_head: 68 dev.em.1.queue0.txd_tail: 68 dev.em.1.queue0.tx_irq: 6378625 dev.em.1.queue0.no_desc_avail: 0 dev.em.1.queue0.rxd_head: 771 dev.em.1.queue0.rxd_tail: 771 dev.em.1.queue0.rx_irq: 6987244 dev.em.1.mac_stats.excess_coll: 0 dev.em.1.mac_stats.single_coll: 0 dev.em.1.mac_stats.multiple_coll: 0 dev.em.1.mac_stats.late_coll: 0 dev.em.1.mac_stats.collision_count: 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: 625 dev.em.1.mac_stats.recv_no_buff: 16 dev.em.1.mac_stats.recv_undersize: 0 dev.em.1.mac_stats.recv_fragmented: 0 dev.em.1.mac_stats.recv_oversize: 0 dev.em.1.mac_stats.recv_jabber: 0 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.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: 28035460 dev.em.1.mac_stats.good_pkts_recvd: 28034835 dev.em.1.mac_stats.bcast_pkts_recvd: 2649 dev.em.1.mac_stats.mcast_pkts_recvd: 892 dev.em.1.mac_stats.rx_frames_64: 1443 dev.em.1.mac_stats.rx_frames_65_127: 398677 dev.em.1.mac_stats.rx_frames_128_255: 154336 dev.em.1.mac_stats.rx_frames_256_511: 473952 dev.em.1.mac_stats.rx_frames_512_1023: 199839 dev.em.1.mac_stats.rx_frames_1024_1522: 26806588 dev.em.1.mac_stats.good_octets_recvd: 40546236160 dev.em.1.mac_stats.good_octets_txd: 1625971127 dev.em.1.mac_stats.total_pkts_txd: 18447279 dev.em.1.mac_stats.good_pkts_txd: 18447279 dev.em.1.mac_stats.bcast_pkts_txd: 194 dev.em.1.mac_stats.mcast_pkts_txd: 6 dev.em.1.mac_stats.tx_frames_64: 352 dev.em.1.mac_stats.tx_frames_65_127: 16626040 dev.em.1.mac_stats.tx_frames_128_255: 1790624 dev.em.1.mac_stats.tx_frames_256_511: 876 dev.em.1.mac_stats.tx_frames_512_1023: 902 dev.em.1.mac_stats.tx_frames_1024_1522: 28485 dev.em.1.mac_stats.tso_txd: 2542 dev.em.1.mac_stats.tso_ctx_fail: 0 dev.em.1.interrupts.asserts: 222 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 ___ freebsd-hardware@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hardware To unsubscribe, send any mail to "freebsd-hardware-unsubscr...@freebsd.org"
Re: em driver, 82574L chip, and possibly ASPM
On 1/23/2011 10:21 AM, Mike Tancsa wrote: > On 1/21/2011 4:21 AM, Jan Koum wrote: > One other thing I noticed is that when the nic is in its hung state, the > WOL option is gone ? > > e.g > > em1: flags=8843 metric 0 mtu 1500 > options=19b > ether 00:15:17:ed:68:a4 > > vs > > > em1: flags=8843 metric 0 mtu 1500 > > options=219b > ether 00:15:17:ed:68:a4 Another hang last night :( Whats really strange is that the WOL_MAGIC and TSO4 got turned back on somehow ? I had explicitly turned it off, but when the NIC was in its bad state em1: flags=8843 metric 0 mtu 1500 options=2198 ... its back on along with TSO? Not sure if its coincidence or a side effect or what. For now, I have had to re-purpose this nic to something else. debug info shows Jan 28 00:25:10 backup3 kernel: Interface is RUNNING and INACTIVE Jan 28 00:25:10 backup3 kernel: em1: hw tdh = 625, hw tdt = 625 Jan 28 00:25:10 backup3 kernel: em1: hw rdh = 903, hw rdt = 903 Jan 28 00:25:10 backup3 kernel: em1: Tx Queue Status = 0 Jan 28 00:25:10 backup3 kernel: em1: TX descriptors avail = 1024 Jan 28 00:25:10 backup3 kernel: em1: Tx Descriptors avail failure = 0 Jan 28 00:25:10 backup3 kernel: em1: RX discarded packets = 0 Jan 28 00:25:10 backup3 kernel: em1: RX Next to Check = 903 Jan 28 00:25:10 backup3 kernel: em1: RX Next to Refresh = 904 Jan 28 00:25:27 backup3 kernel: em1: link state changed to DOWN Jan 28 00:25:30 backup3 kernel: em1: link state changed to UP ---Mike ___ freebsd-hardware@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hardware To unsubscribe, send any mail to "freebsd-hardware-unsubscr...@freebsd.org"
Re: em driver, 82574L chip, and possibly ASPM
On Fri, 2011-01-28 at 08:10 -0800, Mike Tancsa wrote:
> On 1/23/2011 10:21 AM, Mike Tancsa wrote:
> > On 1/21/2011 4:21 AM, Jan Koum wrote:
> > One other thing I noticed is that when the nic is in its hung state, the
> > WOL option is gone ?
> >
> > e.g
> >
> > em1: flags=8843 metric 0 mtu 1500
> > options=19b
> > ether 00:15:17:ed:68:a4
> >
> > vs
> >
> >
> > em1: flags=8843 metric 0 mtu 1500
> >
> > options=219b
> > ether 00:15:17:ed:68:a4
>
>
> Another hang last night :(
>
> Whats really strange is that the WOL_MAGIC and TSO4 got turned back on
> somehow ? I had explicitly turned it off, but when the NIC was in its
> bad state
>
> em1: flags=8843 metric 0 mtu 1500
> options=2198
>
> ... its back on along with TSO? Not sure if its coincidence or a side
> effect or what. For now, I have had to re-purpose this nic to something
> else.
>
> debug info shows
>
> Jan 28 00:25:10 backup3 kernel: Interface is RUNNING and INACTIVE
> Jan 28 00:25:10 backup3 kernel: em1: hw tdh = 625, hw tdt = 625
> Jan 28 00:25:10 backup3 kernel: em1: hw rdh = 903, hw rdt = 903
> Jan 28 00:25:10 backup3 kernel: em1: Tx Queue Status = 0
> Jan 28 00:25:10 backup3 kernel: em1: TX descriptors avail = 1024
> Jan 28 00:25:10 backup3 kernel: em1: Tx Descriptors avail failure = 0
> Jan 28 00:25:10 backup3 kernel: em1: RX discarded packets = 0
> Jan 28 00:25:10 backup3 kernel: em1: RX Next to Check = 903
> Jan 28 00:25:10 backup3 kernel: em1: RX Next to Refresh = 904
> Jan 28 00:25:27 backup3 kernel: em1: link state changed to DOWN
> Jan 28 00:25:30 backup3 kernel: em1: link state changed to UP
>
>
> ---Mike
I'm trying to get some more testing done regarding my suggestions around
the OACTIVE assertions in the driver. More or less, it looks like
intense periods of activity can push the driver into the OACTIVE hold
off state and the logic isn't quite right in igb(4) or em(4) to handle
it.
I suspect that something like this modification to igb(4) may be
required for em(4).
Comments?
Sean
--- p4/freebsd_7/src/sys/dev/e1000/if_igb.c 2010-12-23 11:06:17.127417000 -0800
+++ p4/ybsd_7/src/sys/dev/e1000/if_igb.c 2010-12-23 11:28:50.476993000 -0800
@@ -784,10 +784,14 @@
return;
/* Call cleanup if number of TX descriptors low */
+#if 0
if (txr->tx_avail <= IGB_TX_CLEANUP_THRESHOLD)
igb_txeof(txr);
+#endif
while (!IFQ_DRV_IS_EMPTY(&ifp->if_snd)) {
+ if (txr->tx_avail <= IGB_TX_CLEANUP_THRESHOLD)
+ igb_txeof(txr);
if (txr->tx_avail <= IGB_TX_OP_THRESHOLD) {
ifp->if_drv_flags |= IFF_DRV_OACTIVE;
break;
@@ -1162,10 +1166,10 @@
IGB_TX_LOCK(txr);
if (igb_txeof(txr))
more = TRUE;
- if (!IFQ_DRV_IS_EMPTY(&ifp->if_snd))
- igb_start_locked(txr, ifp);
+ /*if (!IFQ_DRV_IS_EMPTY(&ifp->if_snd)) Pointless as igb_start_locked() checks this right off the bat*/
+ igb_start_locked(txr, ifp);
IGB_TX_UNLOCK(txr);
- if (more) {
+ if (more || (ifp->if_drv_flags & IFF_DRV_OACTIVE)) {
taskqueue_enqueue(que->tq, &que->que_task);
return;
}
@@ -1361,7 +1370,7 @@
no_calc:
/* Schedule a clean task if needed*/
- if (more_tx || more_rx)
+ if (more_tx || more_rx || (ifp->if_drv_flags & IFF_DRV_OACTIVE))
taskqueue_enqueue(que->tq, &que->que_task);
else
/* Reenable this interrupt */
@@ -1535,6 +1545,14 @@
if (m_head->m_flags & M_VLANTAG)
cmd_type_len |= E1000_ADVTXD_DCMD_VLE;
+/*
+ * We just did this in before invocation, seems completely
+ * redundant, igb_handle_queue -> igb_txeof
+ * Pretty sure this is impossible as we check for the
+ * IGB_TX_CLEANUP_THRESHOLD in igb_start_locked() which happens
+ * before this func in invoked
+ */
+#if 0
/*
* Force a cleanup if number of TX descriptors
* available hits the threshold
@@ -1547,6 +1565,7 @@
return (ENOBUFS);
}
}
+#endif
/*
* Map the packet for DMA.
___
freebsd-hardware@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hardware
To unsubscribe, send any mail to "freebsd-hardware-unsubscr...@freebsd.org"
Re: em driver, 82574L chip, and possibly ASPM
On 2/1/2011 3:05 PM, Jack Vogel wrote: > At this point I'm open to any ideas, this sounds like a good one Sean, > thanks. > Mike, you want to test this ? Sure, I am feeling lucky ;-) If someone generates the appropriate em diffs for me, I will apply on the box that sees this issue the most. ---Mike > > Jack > > > On Tue, Feb 1, 2011 at 11:56 AM, Sean Bruno wrote: > >> On Fri, 2011-01-28 at 08:10 -0800, Mike Tancsa wrote: >>> On 1/23/2011 10:21 AM, Mike Tancsa wrote: On 1/21/2011 4:21 AM, Jan Koum wrote: One other thing I noticed is that when the nic is in its hung state, >> the WOL option is gone ? e.g em1: flags=8843 metric 0 mtu >> 1500 >> options=19b ether 00:15:17:ed:68:a4 vs em1: flags=8843 metric 0 mtu >> 1500 >> options=219b ether 00:15:17:ed:68:a4 >>> >>> >>> Another hang last night :( >>> >>> Whats really strange is that the WOL_MAGIC and TSO4 got turned back on >>> somehow ? I had explicitly turned it off, but when the NIC was in its >>> bad state >>> >>> em1: flags=8843 metric 0 mtu 1500 >>> options=2198 >>> >>> ... its back on along with TSO? Not sure if its coincidence or a side >>> effect or what. For now, I have had to re-purpose this nic to something >>> else. >>> >>> debug info shows >>> >>> Jan 28 00:25:10 backup3 kernel: Interface is RUNNING and INACTIVE >>> Jan 28 00:25:10 backup3 kernel: em1: hw tdh = 625, hw tdt = 625 >>> Jan 28 00:25:10 backup3 kernel: em1: hw rdh = 903, hw rdt = 903 >>> Jan 28 00:25:10 backup3 kernel: em1: Tx Queue Status = 0 >>> Jan 28 00:25:10 backup3 kernel: em1: TX descriptors avail = 1024 >>> Jan 28 00:25:10 backup3 kernel: em1: Tx Descriptors avail failure = 0 >>> Jan 28 00:25:10 backup3 kernel: em1: RX discarded packets = 0 >>> Jan 28 00:25:10 backup3 kernel: em1: RX Next to Check = 903 >>> Jan 28 00:25:10 backup3 kernel: em1: RX Next to Refresh = 904 >>> Jan 28 00:25:27 backup3 kernel: em1: link state changed to DOWN >>> Jan 28 00:25:30 backup3 kernel: em1: link state changed to UP >>> >>> >>> ---Mike >> >> >> I'm trying to get some more testing done regarding my suggestions around >> the OACTIVE assertions in the driver. More or less, it looks like >> intense periods of activity can push the driver into the OACTIVE hold >> off state and the logic isn't quite right in igb(4) or em(4) to handle >> it. >> >> I suspect that something like this modification to igb(4) may be >> required for em(4). >> >> Comments? >> >> Sean >> > -- --- Mike Tancsa, tel +1 519 651 3400 Sentex Communications, m...@sentex.net Providing Internet services since 1994 www.sentex.net Cambridge, Ontario Canada http://www.tancsa.com/ ___ freebsd-hardware@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hardware To unsubscribe, send any mail to "freebsd-hardware-unsubscr...@freebsd.org"
Re: em driver, 82574L chip, and possibly ASPM
On Tue, 2011-02-01 at 12:05 -0800, Jack Vogel wrote: > At this point I'm open to any ideas, this sounds like a good one Sean, > thanks. > Mike, you want to test this ? > > Jack > > > On Tue, Feb 1, 2011 at 11:56 AM, Sean Bruno > wrote: > > On Fri, 2011-01-28 at 08:10 -0800, Mike Tancsa wrote: > > On 1/23/2011 10:21 AM, Mike Tancsa wrote: > > > On 1/21/2011 4:21 AM, Jan Koum wrote: > > > One other thing I noticed is that when the nic is in its > hung state, the > > > WOL option is gone ? > > > > > > e.g > > > > > > em1: flags=8843 > metric 0 mtu 1500 > > > > options=19b > > > ether 00:15:17:ed:68:a4 > > > > > > vs > > > > > > > > > em1: flags=8843 > metric 0 mtu 1500 > > > > > > > > options=219b > > > ether 00:15:17:ed:68:a4 > > > > > > Another hang last night :( > > > > Whats really strange is that the WOL_MAGIC and TSO4 got > turned back on > > somehow ? I had explicitly turned it off, but when the NIC > was in its > > bad state > > > > em1: flags=8843 > metric 0 mtu 1500 > > > options=2198 > > > > ... its back on along with TSO? Not sure if its coincidence > or a side > > effect or what. For now, I have had to re-purpose this nic > to something > > else. > > > > debug info shows > > > > Jan 28 00:25:10 backup3 kernel: Interface is RUNNING and > INACTIVE > > Jan 28 00:25:10 backup3 kernel: em1: hw tdh = 625, hw tdt = > 625 > > Jan 28 00:25:10 backup3 kernel: em1: hw rdh = 903, hw rdt = > 903 > > Jan 28 00:25:10 backup3 kernel: em1: Tx Queue Status = 0 > > Jan 28 00:25:10 backup3 kernel: em1: TX descriptors avail = > 1024 > > Jan 28 00:25:10 backup3 kernel: em1: Tx Descriptors avail > failure = 0 > > Jan 28 00:25:10 backup3 kernel: em1: RX discarded packets = > 0 > > Jan 28 00:25:10 backup3 kernel: em1: RX Next to Check = 903 > > Jan 28 00:25:10 backup3 kernel: em1: RX Next to Refresh = > 904 > > Jan 28 00:25:27 backup3 kernel: em1: link state changed to > DOWN > > Jan 28 00:25:30 backup3 kernel: em1: link state changed to > UP > > > > > > ---Mike > > > > I'm trying to get some more testing done regarding my > suggestions around > the OACTIVE assertions in the driver. More or less, it looks > like > intense periods of activity can push the driver into the > OACTIVE hold > off state and the logic isn't quite right in igb(4) or em(4) > to handle > it. > > I suspect that something like this modification to igb(4) may > be > required for em(4). > > Comments? > > Sean > Does the logic I've implemented look sane? Sean ___ freebsd-hardware@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hardware To unsubscribe, send any mail to "freebsd-hardware-unsubscr...@freebsd.org"
Re: em driver, 82574L chip, and possibly ASPM
At this point I'm open to any ideas, this sounds like a good one Sean, thanks. Mike, you want to test this ? Jack On Tue, Feb 1, 2011 at 11:56 AM, Sean Bruno wrote: > On Fri, 2011-01-28 at 08:10 -0800, Mike Tancsa wrote: > > On 1/23/2011 10:21 AM, Mike Tancsa wrote: > > > On 1/21/2011 4:21 AM, Jan Koum wrote: > > > One other thing I noticed is that when the nic is in its hung state, > the > > > WOL option is gone ? > > > > > > e.g > > > > > > em1: flags=8843 metric 0 mtu > 1500 > > > > options=19b > > > ether 00:15:17:ed:68:a4 > > > > > > vs > > > > > > > > > em1: flags=8843 metric 0 mtu > 1500 > > > > > > > options=219b > > > ether 00:15:17:ed:68:a4 > > > > > > Another hang last night :( > > > > Whats really strange is that the WOL_MAGIC and TSO4 got turned back on > > somehow ? I had explicitly turned it off, but when the NIC was in its > > bad state > > > > em1: flags=8843 metric 0 mtu 1500 > > options=2198 > > > > ... its back on along with TSO? Not sure if its coincidence or a side > > effect or what. For now, I have had to re-purpose this nic to something > > else. > > > > debug info shows > > > > Jan 28 00:25:10 backup3 kernel: Interface is RUNNING and INACTIVE > > Jan 28 00:25:10 backup3 kernel: em1: hw tdh = 625, hw tdt = 625 > > Jan 28 00:25:10 backup3 kernel: em1: hw rdh = 903, hw rdt = 903 > > Jan 28 00:25:10 backup3 kernel: em1: Tx Queue Status = 0 > > Jan 28 00:25:10 backup3 kernel: em1: TX descriptors avail = 1024 > > Jan 28 00:25:10 backup3 kernel: em1: Tx Descriptors avail failure = 0 > > Jan 28 00:25:10 backup3 kernel: em1: RX discarded packets = 0 > > Jan 28 00:25:10 backup3 kernel: em1: RX Next to Check = 903 > > Jan 28 00:25:10 backup3 kernel: em1: RX Next to Refresh = 904 > > Jan 28 00:25:27 backup3 kernel: em1: link state changed to DOWN > > Jan 28 00:25:30 backup3 kernel: em1: link state changed to UP > > > > > > ---Mike > > > I'm trying to get some more testing done regarding my suggestions around > the OACTIVE assertions in the driver. More or less, it looks like > intense periods of activity can push the driver into the OACTIVE hold > off state and the logic isn't quite right in igb(4) or em(4) to handle > it. > > I suspect that something like this modification to igb(4) may be > required for em(4). > > Comments? > > Sean > ___ freebsd-hardware@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hardware To unsubscribe, send any mail to "freebsd-hardware-unsubscr...@freebsd.org"
Re: em driver, 82574L chip, and possibly ASPM
Looks good, except I don't like code #if 0'd out, I'll make an if_em.c to try and send it shortly. Jack On Tue, Feb 1, 2011 at 12:19 PM, Sean Bruno wrote: > On Tue, 2011-02-01 at 12:05 -0800, Jack Vogel wrote: > > At this point I'm open to any ideas, this sounds like a good one Sean, > > thanks. > > Mike, you want to test this ? > > > > Jack > > > > > > On Tue, Feb 1, 2011 at 11:56 AM, Sean Bruno > > wrote: > > > > On Fri, 2011-01-28 at 08:10 -0800, Mike Tancsa wrote: > > > On 1/23/2011 10:21 AM, Mike Tancsa wrote: > > > > On 1/21/2011 4:21 AM, Jan Koum wrote: > > > > One other thing I noticed is that when the nic is in its > > hung state, the > > > > WOL option is gone ? > > > > > > > > e.g > > > > > > > > em1: flags=8843 > > metric 0 mtu 1500 > > > > > > > options=19b > > > > ether 00:15:17:ed:68:a4 > > > > > > > > vs > > > > > > > > > > > > em1: flags=8843 > > metric 0 mtu 1500 > > > > > > > > > > > options=219b > > > > ether 00:15:17:ed:68:a4 > > > > > > > > > Another hang last night :( > > > > > > Whats really strange is that the WOL_MAGIC and TSO4 got > > turned back on > > > somehow ? I had explicitly turned it off, but when the NIC > > was in its > > > bad state > > > > > > em1: flags=8843 > > metric 0 mtu 1500 > > > > > options=2198 > > > > > > ... its back on along with TSO? Not sure if its coincidence > > or a side > > > effect or what. For now, I have had to re-purpose this nic > > to something > > > else. > > > > > > debug info shows > > > > > > Jan 28 00:25:10 backup3 kernel: Interface is RUNNING and > > INACTIVE > > > Jan 28 00:25:10 backup3 kernel: em1: hw tdh = 625, hw tdt = > > 625 > > > Jan 28 00:25:10 backup3 kernel: em1: hw rdh = 903, hw rdt = > > 903 > > > Jan 28 00:25:10 backup3 kernel: em1: Tx Queue Status = 0 > > > Jan 28 00:25:10 backup3 kernel: em1: TX descriptors avail = > > 1024 > > > Jan 28 00:25:10 backup3 kernel: em1: Tx Descriptors avail > > failure = 0 > > > Jan 28 00:25:10 backup3 kernel: em1: RX discarded packets = > > 0 > > > Jan 28 00:25:10 backup3 kernel: em1: RX Next to Check = 903 > > > Jan 28 00:25:10 backup3 kernel: em1: RX Next to Refresh = > > 904 > > > Jan 28 00:25:27 backup3 kernel: em1: link state changed to > > DOWN > > > Jan 28 00:25:30 backup3 kernel: em1: link state changed to > > UP > > > > > > > > > ---Mike > > > > > > > > I'm trying to get some more testing done regarding my > > suggestions around > > the OACTIVE assertions in the driver. More or less, it looks > > like > > intense periods of activity can push the driver into the > > OACTIVE hold > > off state and the logic isn't quite right in igb(4) or em(4) > > to handle > > it. > > > > I suspect that something like this modification to igb(4) may > > be > > required for em(4). > > > > Comments? > > > > Sean > > > > > Does the logic I've implemented look sane? > > Sean > > ___ freebsd-hardware@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hardware To unsubscribe, send any mail to "freebsd-hardware-unsubscr...@freebsd.org"
Re: em driver, 82574L chip, and possibly ASPM
Mike, just to remind me, are you running these 82574 adapters with MSIX ? Jack On Tue, Feb 1, 2011 at 12:37 PM, Jack Vogel wrote: > Looks good, except I don't like code #if 0'd out, I'll make an if_em.c to > try and > send it shortly. > > Jack > > > > On Tue, Feb 1, 2011 at 12:19 PM, Sean Bruno wrote: > >> On Tue, 2011-02-01 at 12:05 -0800, Jack Vogel wrote: >> > At this point I'm open to any ideas, this sounds like a good one Sean, >> > thanks. >> > Mike, you want to test this ? >> > >> > Jack >> > >> > >> > On Tue, Feb 1, 2011 at 11:56 AM, Sean Bruno >> > wrote: >> > >> > On Fri, 2011-01-28 at 08:10 -0800, Mike Tancsa wrote: >> > > On 1/23/2011 10:21 AM, Mike Tancsa wrote: >> > > > On 1/21/2011 4:21 AM, Jan Koum wrote: >> > > > One other thing I noticed is that when the nic is in its >> > hung state, the >> > > > WOL option is gone ? >> > > > >> > > > e.g >> > > > >> > > > em1: flags=8843 >> > metric 0 mtu 1500 >> > > > >> > >> options=19b >> > > > ether 00:15:17:ed:68:a4 >> > > > >> > > > vs >> > > > >> > > > >> > > > em1: flags=8843 >> > metric 0 mtu 1500 >> > > > >> > > > >> > >> options=219b >> > > > ether 00:15:17:ed:68:a4 >> > > >> > > >> > > Another hang last night :( >> > > >> > > Whats really strange is that the WOL_MAGIC and TSO4 got >> > turned back on >> > > somehow ? I had explicitly turned it off, but when the NIC >> > was in its >> > > bad state >> > > >> > > em1: flags=8843 >> > metric 0 mtu 1500 >> > > >> > options=2198 >> > > >> > > ... its back on along with TSO? Not sure if its coincidence >> > or a side >> > > effect or what. For now, I have had to re-purpose this nic >> > to something >> > > else. >> > > >> > > debug info shows >> > > >> > > Jan 28 00:25:10 backup3 kernel: Interface is RUNNING and >> > INACTIVE >> > > Jan 28 00:25:10 backup3 kernel: em1: hw tdh = 625, hw tdt = >> > 625 >> > > Jan 28 00:25:10 backup3 kernel: em1: hw rdh = 903, hw rdt = >> > 903 >> > > Jan 28 00:25:10 backup3 kernel: em1: Tx Queue Status = 0 >> > > Jan 28 00:25:10 backup3 kernel: em1: TX descriptors avail = >> > 1024 >> > > Jan 28 00:25:10 backup3 kernel: em1: Tx Descriptors avail >> > failure = 0 >> > > Jan 28 00:25:10 backup3 kernel: em1: RX discarded packets = >> > 0 >> > > Jan 28 00:25:10 backup3 kernel: em1: RX Next to Check = 903 >> > > Jan 28 00:25:10 backup3 kernel: em1: RX Next to Refresh = >> > 904 >> > > Jan 28 00:25:27 backup3 kernel: em1: link state changed to >> > DOWN >> > > Jan 28 00:25:30 backup3 kernel: em1: link state changed to >> > UP >> > > >> > > >> > > ---Mike >> > >> > >> > >> > I'm trying to get some more testing done regarding my >> > suggestions around >> > the OACTIVE assertions in the driver. More or less, it looks >> > like >> > intense periods of activity can push the driver into the >> > OACTIVE hold >> > off state and the logic isn't quite right in igb(4) or em(4) >> > to handle >> > it. >> > >> > I suspect that something like this modification to igb(4) may >> > be >> > required for em(4). >> > >> > Comments? >> > >> > Sean >> > >> >> >> Does the logic I've implemented look sane? >> >> Sean >> >> > ___ freebsd-hardware@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hardware To unsubscribe, send any mail to "freebsd-hardware-unsubscr...@freebsd.org"
Re: em driver, 82574L chip, and possibly ASPM
On 2/1/2011 3:55 PM, Jack Vogel wrote: > Mike, just to remind me, are you running these 82574 adapters with MSIX ? Yes. Board is an Intel MB (S3420GPX). 8G RAM, AMD64. Kernel from a few days ago 0(backup3)# vmstat -i | grep em1 irq257: em1:rx 0 113712958159 irq258: em1:tx 096623551135 irq259: em1:link 488 0 0(backup3)# grep ^em1 /var/run/dmesg.boot em1: port 0x2000-0x201f mem 0xb410-0xb411,0xb412-0xb4123fff irq 16 at device 0.0 on pci10 em1: Using MSIX interrupts with 3 vectors em1: [ITHREAD] em1: [ITHREAD] em1: [ITHREAD] em1: Ethernet address: 00:15:17:ed:68:a4 em1: link state changed to UP 0(backup3)# em1@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 ---Mike ___ freebsd-hardware@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hardware To unsubscribe, send any mail to "freebsd-hardware-unsubscr...@freebsd.org"
Re: em driver, 82574L chip, and possibly ASPM
But you aren't defining EM_MULTIQUEUE are you? (its not on by default) Jack On Tue, Feb 1, 2011 at 1:05 PM, Mike Tancsa wrote: > On 2/1/2011 3:55 PM, Jack Vogel wrote: > > Mike, just to remind me, are you running these 82574 adapters with MSIX ? > > Yes. Board is an Intel MB (S3420GPX). 8G RAM, AMD64. Kernel from a few > days ago > > > 0(backup3)# vmstat -i | grep em1 > irq257: em1:rx 0 113712958159 > irq258: em1:tx 096623551135 > irq259: em1:link 488 0 > 0(backup3)# grep ^em1 /var/run/dmesg.boot > em1: port 0x2000-0x201f mem > 0xb410-0xb411,0xb412-0xb4123fff irq 16 at device 0.0 on pci10 > em1: Using MSIX interrupts with 3 vectors > em1: [ITHREAD] > em1: [ITHREAD] > em1: [ITHREAD] > em1: Ethernet address: 00:15:17:ed:68:a4 > em1: link state changed to UP > 0(backup3)# > em1@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 > > ---Mike > ___ freebsd-hardware@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hardware To unsubscribe, send any mail to "freebsd-hardware-unsubscr...@freebsd.org"
Re: em driver, 82574L chip, and possibly ASPM
On 2/1/2011 4:17 PM, Jack Vogel wrote: > But you aren't defining EM_MULTIQUEUE are you? (its not on by default) Nope. Everything is the default wrt to the em driver. Nothing odd in loader.conf 0(backup3)% grep -v ^# /boot/loader.conf ahci_load="YES" siis_load="YES" if_em_load="YES" coretemp_load="YES" comconsole_speed="115200"# Set the current serial console speed console="comconsole,vidconsole" # A comma separated list of console(s) aesni_load="YES" cryptodev_load="YES" ---Mike ___ freebsd-hardware@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hardware To unsubscribe, send any mail to "freebsd-hardware-unsubscr...@freebsd.org"
Re: em driver, 82574L chip, and possibly ASPM
On 2/1/2011 4:43 PM, Jack Vogel wrote: > To those who are going to test, here is the if_em.c, based on head, with my > changes, I have to leave for the afternoon, and have not had a chance to > build > this, but it should work. I will check back in the later evening. > > Any blatant problems Sean, feel free to fix them :) My boxes are RELENG_7 and RELENG_8. Apart from manually hand editing those pesky sysctl changes out, is there a better way to generate RELENG_8 and 7 diffs ? ---Mike ___ freebsd-hardware@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hardware To unsubscribe, send any mail to "freebsd-hardware-unsubscr...@freebsd.org"
Re: em driver, 82574L chip, and possibly ASPM
On Tue, 2011-02-01 at 13:43 -0800, Jack Vogel wrote:
> To those who are going to test, here is the if_em.c, based on head,
> with my
> changes, I have to leave for the afternoon, and have not had a chance
> to build
> this, but it should work. I will check back in the later evening.
>
> Any blatant problems Sean, feel free to fix them :)
>
> Jack
>
I suspect that line 1490 should be:
if (more_rx || (ifp->if_drv_flags & IFF_DRV_OACTIVE)) {
Sean
___
freebsd-hardware@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hardware
To unsubscribe, send any mail to "freebsd-hardware-unsubscr...@freebsd.org"
Re: em driver, 82574L chip, and possibly ASPM
On Tue, 2011-02-01 at 13:51 -0800, Mike Tancsa wrote: > On 2/1/2011 4:43 PM, Jack Vogel wrote: > > To those who are going to test, here is the if_em.c, based on head, with my > > changes, I have to leave for the afternoon, and have not had a chance to > > build > > this, but it should work. I will check back in the later evening. > > > > Any blatant problems Sean, feel free to fix them :) > > My boxes are RELENG_7 and RELENG_8. Apart from manually hand editing > those pesky sysctl changes out, is there a better way to generate > RELENG_8 and 7 diffs ? > > ---Mike Not at the moment. sean ___ freebsd-hardware@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hardware To unsubscribe, send any mail to "freebsd-hardware-unsubscr...@freebsd.org"
Re: em driver, 82574L chip, and possibly ASPM
On Tue, Feb 01, 2011 at 04:51:37PM -0500, Mike Tancsa wrote: > On 2/1/2011 4:43 PM, Jack Vogel wrote: > > To those who are going to test, here is the if_em.c, based on head, with my > > changes, I have to leave for the afternoon, and have not had a chance to > > build > > this, but it should work. I will check back in the later evening. > > Did this get sent to the list? I didn't get this quoted message and I can't find it in the archives. If someone could post the current revision of if_em.c that would be great; we are also very eager to test. Thanks. ___ freebsd-hardware@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hardware To unsubscribe, send any mail to "freebsd-hardware-unsubscr...@freebsd.org"
Re: em driver, 82574L chip, and possibly ASPM
On 2/1/2011 7:56 PM, Chris Peiffer wrote: > > Did this get sent to the list? I didn't get this quoted message and I > can't find it in the archives. > > If someone could post the current revision of if_em.c that would be > great; we are also very eager to test. > Strange, it seems to be eaten/held by mailman ? I posted the file to http://www.tancsa.com/if_em.c % md5 if_em.c MD5 (if_em.c) = 0f2d48c7734496c2262f468cd1ab9117 % ident if_em.c if_em.c: $FreeBSD: src/sys/dev/e1000/if_em.c,v 1.68 2011/01/19 18:20:11 jfv Exp $ ---Mike -- --- Mike Tancsa, tel +1 519 651 3400 Sentex Communications, m...@sentex.net Providing Internet services since 1994 www.sentex.net Cambridge, Ontario Canada http://www.tancsa.com/ ___ freebsd-hardware@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hardware To unsubscribe, send any mail to "freebsd-hardware-unsubscr...@freebsd.org"
Re: em driver, 82574L chip, and possibly ASPM
On 2/1/2011 8:44 PM, Mike Tancsa wrote: > > % md5 if_em.c > MD5 (if_em.c) = 0f2d48c7734496c2262f468cd1ab9117 Sorry, thats MD5 (if_em.c) = 9cede4ab0d833e0f97172ed715e2b4e3 ---Mike -- --- Mike Tancsa, tel +1 519 651 3400 Sentex Communications, m...@sentex.net Providing Internet services since 1994 www.sentex.net Cambridge, Ontario Canada http://www.tancsa.com/ ___ freebsd-hardware@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hardware To unsubscribe, send any mail to "freebsd-hardware-unsubscr...@freebsd.org"
Re: em driver, 82574L chip, and possibly ASPM
On 2/1/2011 5:03 PM, Sean Bruno wrote:
> On Tue, 2011-02-01 at 13:43 -0800, Jack Vogel wrote:
>> To those who are going to test, here is the if_em.c, based on head,
>> with my
>> changes, I have to leave for the afternoon, and have not had a chance
>> to build
>> this, but it should work. I will check back in the later evening.
>>
>> Any blatant problems Sean, feel free to fix them :)
>>
>> Jack
>>
>
>
> I suspect that line 1490 should be:
> if (more_rx || (ifp->if_drv_flags & IFF_DRV_OACTIVE)) {
>
I have hacked up a RELENG_8 version which I think is correct including
the above change
http://www.tancsa.com/if_em-8.c
--- if_em.c.orig2011-02-01 21:47:14.0 -0500
+++ if_em.c 2011-02-01 21:47:19.0 -0500
@@ -30,7 +30,7 @@
POSSIBILITY OF SUCH DAMAGE.
**/
-/*$FreeBSD: src/sys/dev/e1000/if_em.c,v 1.21.2.20 2011/01/22 01:37:53
jfv Exp $*/
+/*$FreeBSD$*/
#ifdef HAVE_KERNEL_OPTION_HEADERS
#include "opt_device_polling.h"
@@ -93,7 +93,7 @@
/*
* Driver version:
*/
-char em_driver_version[] = "7.1.9";
+char em_driver_version[] = "7.1.9-test";
/*
* PCI Device ID Table
@@ -927,11 +927,10 @@
if (!adapter->link_active)
return;
-/* Call cleanup if number of TX descriptors low */
- if (txr->tx_avail <= EM_TX_CLEANUP_THRESHOLD)
- em_txeof(txr);
-
while (!IFQ_DRV_IS_EMPTY(&ifp->if_snd)) {
+ /* First cleanup if TX descriptors low */
+ if (txr->tx_avail <= EM_TX_CLEANUP_THRESHOLD)
+ em_txeof(txr);
if (txr->tx_avail < EM_MAX_SCATTER) {
ifp->if_drv_flags |= IFF_DRV_OACTIVE;
break;
@@ -1411,8 +1410,7 @@
if (!drbr_empty(ifp, txr->br))
em_mq_start_locked(ifp, txr, NULL);
#else
- if (!IFQ_DRV_IS_EMPTY(&ifp->if_snd))
- em_start_locked(ifp, txr);
+ em_start_locked(ifp, txr);
#endif
EM_TX_UNLOCK(txr);
@@ -1475,11 +1473,10 @@
struct ifnet*ifp = adapter->ifp;
struct tx_ring *txr = adapter->tx_rings;
struct rx_ring *rxr = adapter->rx_rings;
- boolmore;
-
if (ifp->if_drv_flags & IFF_DRV_RUNNING) {
- more = em_rxeof(rxr, adapter->rx_process_limit, NULL);
+ boolmore_rx;
+ more_rx = em_rxeof(rxr, adapter->rx_process_limit, NULL);
EM_TX_LOCK(txr);
em_txeof(txr);
@@ -1487,12 +1484,10 @@
if (!drbr_empty(ifp, txr->br))
em_mq_start_locked(ifp, txr, NULL);
#else
- if (!IFQ_DRV_IS_EMPTY(&ifp->if_snd))
- em_start_locked(ifp, txr);
+ em_start_locked(ifp, txr);
#endif
- em_txeof(txr);
EM_TX_UNLOCK(txr);
- if (more) {
+ if (more_rx || (ifp->if_drv_flags & IFF_DRV_OACTIVE)) {
taskqueue_enqueue(adapter->tq, &adapter->que_task);
return;
}
@@ -1604,7 +1599,6 @@
if (!IFQ_DRV_IS_EMPTY(&ifp->if_snd))
em_start_locked(ifp, txr);
#endif
- em_txeof(txr);
E1000_WRITE_REG(&adapter->hw, E1000_IMS, txr->ims);
EM_TX_UNLOCK(txr);
}
@@ -3730,17 +3724,17 @@
txr->queue_status = EM_QUEUE_HUNG;
/*
- * If we have enough room, clear IFF_DRV_OACTIVE
+ * If we have a minimum free, clear IFF_DRV_OACTIVE
* to tell the stack that it is OK to send packets.
*/
-if (txr->tx_avail > EM_TX_CLEANUP_THRESHOLD) {
+if (txr->tx_avail > EM_MAX_SCATTER)
ifp->if_drv_flags &= ~IFF_DRV_OACTIVE;
- /* Disable watchdog if all clean */
-if (txr->tx_avail == adapter->num_tx_desc) {
- txr->queue_status = EM_QUEUE_IDLE;
- return (FALSE);
- }
-}
+
+ /* Disable watchdog if all clean */
+ if (txr->tx_avail == adapter->num_tx_desc) {
+ txr->queue_status = EM_QUEUE_IDLE;
+ return (FALSE);
+ }
return (TRUE);
}
@@ -5064,8 +5058,8 @@
char namebuf[QUEUE_NAME_LEN];
/* Driver Statistics */
- SYSCTL_ADD_UINT(ctx, child, OID_AUTO, "link_irq",
- CTLFLAG_RD, &adapter->link_irq, 0,
+ SYSCTL_ADD_UINT(ctx, child, OID_AUTO, "link_irq",
+ CTLFLAG_RD, &adapter->link_irq,0,
"Link MSIX IRQ Handled");
SYSCTL_ADD_ULONG(ctx, child, OID_AUTO, "mbuf_alloc_fail",
CTLFLAG_RD, &adapter->mbuf_alloc_failed
Re: em driver, 82574L chip, and possibly ASPM
To those who are going to test, here is the if_em.c, based on head, with my changes, I have to leave for the afternoon, and have not had a chance to build this, but it should work. I will check back in the later evening. Any blatant problems Sean, feel free to fix them :) Jack On Tue, Feb 1, 2011 at 12:37 PM, Jack Vogel wrote: > Looks good, except I don't like code #if 0'd out, I'll make an if_em.c to > try and > send it shortly. > > Jack > > > > On Tue, Feb 1, 2011 at 12:19 PM, Sean Bruno wrote: > >> On Tue, 2011-02-01 at 12:05 -0800, Jack Vogel wrote: >> > At this point I'm open to any ideas, this sounds like a good one Sean, >> > thanks. >> > Mike, you want to test this ? >> > >> > Jack >> > >> > >> > On Tue, Feb 1, 2011 at 11:56 AM, Sean Bruno >> > wrote: >> > >> > On Fri, 2011-01-28 at 08:10 -0800, Mike Tancsa wrote: >> > > On 1/23/2011 10:21 AM, Mike Tancsa wrote: >> > > > On 1/21/2011 4:21 AM, Jan Koum wrote: >> > > > One other thing I noticed is that when the nic is in its >> > hung state, the >> > > > WOL option is gone ? >> > > > >> > > > e.g >> > > > >> > > > em1: flags=8843 >> > metric 0 mtu 1500 >> > > > >> > >> options=19b >> > > > ether 00:15:17:ed:68:a4 >> > > > >> > > > vs >> > > > >> > > > >> > > > em1: flags=8843 >> > metric 0 mtu 1500 >> > > > >> > > > >> > >> options=219b >> > > > ether 00:15:17:ed:68:a4 >> > > >> > > >> > > Another hang last night :( >> > > >> > > Whats really strange is that the WOL_MAGIC and TSO4 got >> > turned back on >> > > somehow ? I had explicitly turned it off, but when the NIC >> > was in its >> > > bad state >> > > >> > > em1: flags=8843 >> > metric 0 mtu 1500 >> > > >> > options=2198 >> > > >> > > ... its back on along with TSO? Not sure if its coincidence >> > or a side >> > > effect or what. For now, I have had to re-purpose this nic >> > to something >> > > else. >> > > >> > > debug info shows >> > > >> > > Jan 28 00:25:10 backup3 kernel: Interface is RUNNING and >> > INACTIVE >> > > Jan 28 00:25:10 backup3 kernel: em1: hw tdh = 625, hw tdt = >> > 625 >> > > Jan 28 00:25:10 backup3 kernel: em1: hw rdh = 903, hw rdt = >> > 903 >> > > Jan 28 00:25:10 backup3 kernel: em1: Tx Queue Status = 0 >> > > Jan 28 00:25:10 backup3 kernel: em1: TX descriptors avail = >> > 1024 >> > > Jan 28 00:25:10 backup3 kernel: em1: Tx Descriptors avail >> > failure = 0 >> > > Jan 28 00:25:10 backup3 kernel: em1: RX discarded packets = >> > 0 >> > > Jan 28 00:25:10 backup3 kernel: em1: RX Next to Check = 903 >> > > Jan 28 00:25:10 backup3 kernel: em1: RX Next to Refresh = >> > 904 >> > > Jan 28 00:25:27 backup3 kernel: em1: link state changed to >> > DOWN >> > > Jan 28 00:25:30 backup3 kernel: em1: link state changed to >> > UP >> > > >> > > >> > > ---Mike >> > >> > >> > >> > I'm trying to get some more testing done regarding my >> > suggestions around >> > the OACTIVE assertions in the driver. More or less, it looks >> > like >> > intense periods of activity can push the driver into the >> > OACTIVE hold >> > off state and the logic isn't quite right in igb(4) or em(4) >> > to handle >> > it. >> > >> > I suspect that something like this modification to igb(4) may >> > be >> > required for em(4). >> > >> > Comments? >> > >> > Sean >> > >> >> >> Does the logic I've implemented look sane? >> >> Sean >> >> > ___ freebsd-hardware@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hardware To unsubscribe, send any mail to "freebsd-hardware-unsubscr...@freebsd.org"
Re: em driver, 82574L chip, and possibly ASPM
So has everyone that wanted to get something testing been able to do so?
Jack
On Tue, Feb 1, 2011 at 7:03 PM, Mike Tancsa wrote:
> On 2/1/2011 5:03 PM, Sean Bruno wrote:
> > On Tue, 2011-02-01 at 13:43 -0800, Jack Vogel wrote:
> >> To those who are going to test, here is the if_em.c, based on head,
> >> with my
> >> changes, I have to leave for the afternoon, and have not had a chance
> >> to build
> >> this, but it should work. I will check back in the later evening.
> >>
> >> Any blatant problems Sean, feel free to fix them :)
> >>
> >> Jack
> >>
> >
> >
> > I suspect that line 1490 should be:
> > if (more_rx || (ifp->if_drv_flags & IFF_DRV_OACTIVE)) {
> >
>
>
> I have hacked up a RELENG_8 version which I think is correct including
> the above change
>
> http://www.tancsa.com/if_em-8.c
>
>
>
> --- if_em.c.orig2011-02-01 21:47:14.0 -0500
> +++ if_em.c 2011-02-01 21:47:19.0 -0500
> @@ -30,7 +30,7 @@
> POSSIBILITY OF SUCH DAMAGE.
>
>
>
> **/
> -/*$FreeBSD: src/sys/dev/e1000/if_em.c,v 1.21.2.20 2011/01/22 01:37:53
> jfv Exp $*/
> +/*$FreeBSD$*/
>
> #ifdef HAVE_KERNEL_OPTION_HEADERS
> #include "opt_device_polling.h"
> @@ -93,7 +93,7 @@
> /*
> * Driver version:
> */
> -char em_driver_version[] = "7.1.9";
> +char em_driver_version[] = "7.1.9-test";
>
> /*
> * PCI Device ID Table
> @@ -927,11 +927,10 @@
>if (!adapter->link_active)
>return;
>
> -/* Call cleanup if number of TX descriptors low */
> - if (txr->tx_avail <= EM_TX_CLEANUP_THRESHOLD)
> - em_txeof(txr);
> -
>while (!IFQ_DRV_IS_EMPTY(&ifp->if_snd)) {
> + /* First cleanup if TX descriptors low */
> + if (txr->tx_avail <= EM_TX_CLEANUP_THRESHOLD)
> + em_txeof(txr);
>if (txr->tx_avail < EM_MAX_SCATTER) {
>ifp->if_drv_flags |= IFF_DRV_OACTIVE;
>break;
> @@ -1411,8 +1410,7 @@
>if (!drbr_empty(ifp, txr->br))
>em_mq_start_locked(ifp, txr, NULL);
> #else
> - if (!IFQ_DRV_IS_EMPTY(&ifp->if_snd))
> - em_start_locked(ifp, txr);
> + em_start_locked(ifp, txr);
> #endif
>EM_TX_UNLOCK(txr);
>
> @@ -1475,11 +1473,10 @@
>struct ifnet*ifp = adapter->ifp;
>struct tx_ring *txr = adapter->tx_rings;
>struct rx_ring *rxr = adapter->rx_rings;
> - boolmore;
> -
>
>if (ifp->if_drv_flags & IFF_DRV_RUNNING) {
> - more = em_rxeof(rxr, adapter->rx_process_limit, NULL);
> + boolmore_rx;
> + more_rx = em_rxeof(rxr, adapter->rx_process_limit, NULL);
>
>EM_TX_LOCK(txr);
>em_txeof(txr);
> @@ -1487,12 +1484,10 @@
>if (!drbr_empty(ifp, txr->br))
>em_mq_start_locked(ifp, txr, NULL);
> #else
> - if (!IFQ_DRV_IS_EMPTY(&ifp->if_snd))
> - em_start_locked(ifp, txr);
> + em_start_locked(ifp, txr);
> #endif
> - em_txeof(txr);
>EM_TX_UNLOCK(txr);
> - if (more) {
> + if (more_rx || (ifp->if_drv_flags & IFF_DRV_OACTIVE)) {
>taskqueue_enqueue(adapter->tq, &adapter->que_task);
>return;
>}
> @@ -1604,7 +1599,6 @@
>if (!IFQ_DRV_IS_EMPTY(&ifp->if_snd))
>em_start_locked(ifp, txr);
> #endif
> - em_txeof(txr);
>E1000_WRITE_REG(&adapter->hw, E1000_IMS, txr->ims);
>EM_TX_UNLOCK(txr);
> }
> @@ -3730,17 +3724,17 @@
>txr->queue_status = EM_QUEUE_HUNG;
>
> /*
> - * If we have enough room, clear IFF_DRV_OACTIVE
> + * If we have a minimum free, clear IFF_DRV_OACTIVE
> * to tell the stack that it is OK to send packets.
> */
> -if (txr->tx_avail > EM_TX_CLEANUP_THRESHOLD) {
> +if (txr->tx_avail > EM_MAX_SCATTER)
> ifp->if_drv_flags &= ~IFF_DRV_OACTIVE;
> - /* Disable watchdog if all clean */
> -if (txr->tx_avail == adapter->num_tx_desc) {
> - txr->queue_status = EM_QUEUE_IDLE;
> - return (FALSE);
> - }
> -}
> +
> + /* Disable watchdog if all clean */
> + if (txr->tx_avail == adapter->num_tx_desc) {
> + txr->queue_status = EM_QUEUE_IDLE;
> + return (FALSE);
> + }
>
>return (TRUE);
> }
> @@ -5064,8 +5058,8 @@
>char namebuf[QUEUE_NAME_LEN];
>
>/* Driver Statistics */
> - SYSCTL_ADD_UINT(ctx, child, OID_AUTO, "li
Re: em driver, 82574L chip, and possibly ASPM
On 2/2/2011 12:37 PM, Jack Vogel wrote:
> So has everyone that wanted to get something testing been able to do so?
I have been testing in the back and will deploy to my production box
this afternoon. As I am not able to reproduce it easily, it will be a
bit before I can say the issue is gone. Jan however, was able to
trigger it with greater ease ?
---Mike
>
> Jack
>
>
> On Tue, Feb 1, 2011 at 7:03 PM, Mike Tancsa wrote:
>
>> On 2/1/2011 5:03 PM, Sean Bruno wrote:
>>> On Tue, 2011-02-01 at 13:43 -0800, Jack Vogel wrote:
To those who are going to test, here is the if_em.c, based on head,
with my
changes, I have to leave for the afternoon, and have not had a chance
to build
this, but it should work. I will check back in the later evening.
Any blatant problems Sean, feel free to fix them :)
Jack
>>>
>>>
>>> I suspect that line 1490 should be:
>>> if (more_rx || (ifp->if_drv_flags & IFF_DRV_OACTIVE)) {
>>>
>>
>>
>> I have hacked up a RELENG_8 version which I think is correct including
>> the above change
>>
>> http://www.tancsa.com/if_em-8.c
>>
>>
>>
>> --- if_em.c.orig2011-02-01 21:47:14.0 -0500
>> +++ if_em.c 2011-02-01 21:47:19.0 -0500
>> @@ -30,7 +30,7 @@
>> POSSIBILITY OF SUCH DAMAGE.
>>
>>
>>
>> **/
>> -/*$FreeBSD: src/sys/dev/e1000/if_em.c,v 1.21.2.20 2011/01/22 01:37:53
>> jfv Exp $*/
>> +/*$FreeBSD$*/
>>
>> #ifdef HAVE_KERNEL_OPTION_HEADERS
>> #include "opt_device_polling.h"
>> @@ -93,7 +93,7 @@
>> /*
>> * Driver version:
>> */
>> -char em_driver_version[] = "7.1.9";
>> +char em_driver_version[] = "7.1.9-test";
>>
>> /*
>> * PCI Device ID Table
>> @@ -927,11 +927,10 @@
>>if (!adapter->link_active)
>>return;
>>
>> -/* Call cleanup if number of TX descriptors low */
>> - if (txr->tx_avail <= EM_TX_CLEANUP_THRESHOLD)
>> - em_txeof(txr);
>> -
>>while (!IFQ_DRV_IS_EMPTY(&ifp->if_snd)) {
>> + /* First cleanup if TX descriptors low */
>> + if (txr->tx_avail <= EM_TX_CLEANUP_THRESHOLD)
>> + em_txeof(txr);
>>if (txr->tx_avail < EM_MAX_SCATTER) {
>>ifp->if_drv_flags |= IFF_DRV_OACTIVE;
>>break;
>> @@ -1411,8 +1410,7 @@
>>if (!drbr_empty(ifp, txr->br))
>>em_mq_start_locked(ifp, txr, NULL);
>> #else
>> - if (!IFQ_DRV_IS_EMPTY(&ifp->if_snd))
>> - em_start_locked(ifp, txr);
>> + em_start_locked(ifp, txr);
>> #endif
>>EM_TX_UNLOCK(txr);
>>
>> @@ -1475,11 +1473,10 @@
>>struct ifnet*ifp = adapter->ifp;
>>struct tx_ring *txr = adapter->tx_rings;
>>struct rx_ring *rxr = adapter->rx_rings;
>> - boolmore;
>> -
>>
>>if (ifp->if_drv_flags & IFF_DRV_RUNNING) {
>> - more = em_rxeof(rxr, adapter->rx_process_limit, NULL);
>> + boolmore_rx;
>> + more_rx = em_rxeof(rxr, adapter->rx_process_limit, NULL);
>>
>>EM_TX_LOCK(txr);
>>em_txeof(txr);
>> @@ -1487,12 +1484,10 @@
>>if (!drbr_empty(ifp, txr->br))
>>em_mq_start_locked(ifp, txr, NULL);
>> #else
>> - if (!IFQ_DRV_IS_EMPTY(&ifp->if_snd))
>> - em_start_locked(ifp, txr);
>> + em_start_locked(ifp, txr);
>> #endif
>> - em_txeof(txr);
>>EM_TX_UNLOCK(txr);
>> - if (more) {
>> + if (more_rx || (ifp->if_drv_flags & IFF_DRV_OACTIVE)) {
>>taskqueue_enqueue(adapter->tq, &adapter->que_task);
>>return;
>>}
>> @@ -1604,7 +1599,6 @@
>>if (!IFQ_DRV_IS_EMPTY(&ifp->if_snd))
>>em_start_locked(ifp, txr);
>> #endif
>> - em_txeof(txr);
>>E1000_WRITE_REG(&adapter->hw, E1000_IMS, txr->ims);
>>EM_TX_UNLOCK(txr);
>> }
>> @@ -3730,17 +3724,17 @@
>>txr->queue_status = EM_QUEUE_HUNG;
>>
>> /*
>> - * If we have enough room, clear IFF_DRV_OACTIVE
>> + * If we have a minimum free, clear IFF_DRV_OACTIVE
>> * to tell the stack that it is OK to send packets.
>> */
>> -if (txr->tx_avail > EM_TX_CLEANUP_THRESHOLD) {
>> +if (txr->tx_avail > EM_MAX_SCATTER)
>> ifp->if_drv_flags &= ~IFF_DRV_OACTIVE;
>> - /* Disable watchdog if all clean */
>> -if (txr->tx_avail == adapter->num_tx_desc) {
>> - txr->queue_status = EM_QUEUE_IDLE;
>> - return (FALSE
Re: em driver, 82574L chip, and possibly ASPM
Any more data on this problem or do we have to wait a while?
Sean
On Wed, 2011-02-02 at 10:28 -0800, Mike Tancsa wrote:
> On 2/2/2011 12:37 PM, Jack Vogel wrote:
> > So has everyone that wanted to get something testing been able to do so?
>
> I have been testing in the back and will deploy to my production box
> this afternoon. As I am not able to reproduce it easily, it will be a
> bit before I can say the issue is gone. Jan however, was able to
> trigger it with greater ease ?
>
> ---Mike
>
> >
> > Jack
> >
> >
> > On Tue, Feb 1, 2011 at 7:03 PM, Mike Tancsa wrote:
> >
> >> On 2/1/2011 5:03 PM, Sean Bruno wrote:
> >>> On Tue, 2011-02-01 at 13:43 -0800, Jack Vogel wrote:
> To those who are going to test, here is the if_em.c, based on head,
> with my
> changes, I have to leave for the afternoon, and have not had a chance
> to build
> this, but it should work. I will check back in the later evening.
>
> Any blatant problems Sean, feel free to fix them :)
>
> Jack
>
> >>>
> >>>
> >>> I suspect that line 1490 should be:
> >>> if (more_rx || (ifp->if_drv_flags & IFF_DRV_OACTIVE)) {
> >>>
> >>
> >>
> >> I have hacked up a RELENG_8 version which I think is correct including
> >> the above change
> >>
> >> http://www.tancsa.com/if_em-8.c
> >>
> >>
> >>
> >> --- if_em.c.orig2011-02-01 21:47:14.0 -0500
> >> +++ if_em.c 2011-02-01 21:47:19.0 -0500
> >> @@ -30,7 +30,7 @@
> >> POSSIBILITY OF SUCH DAMAGE.
> >>
> >>
> >>
> >> **/
> >> -/*$FreeBSD: src/sys/dev/e1000/if_em.c,v 1.21.2.20 2011/01/22 01:37:53
> >> jfv Exp $*/
> >> +/*$FreeBSD$*/
> >>
> >> #ifdef HAVE_KERNEL_OPTION_HEADERS
> >> #include "opt_device_polling.h"
> >> @@ -93,7 +93,7 @@
> >> /*
> >> * Driver version:
> >> */
> >> -char em_driver_version[] = "7.1.9";
> >> +char em_driver_version[] = "7.1.9-test";
> >>
> >> /*
> >> * PCI Device ID Table
> >> @@ -927,11 +927,10 @@
> >>if (!adapter->link_active)
> >>return;
> >>
> >> -/* Call cleanup if number of TX descriptors low */
> >> - if (txr->tx_avail <= EM_TX_CLEANUP_THRESHOLD)
> >> - em_txeof(txr);
> >> -
> >>while (!IFQ_DRV_IS_EMPTY(&ifp->if_snd)) {
> >> + /* First cleanup if TX descriptors low */
> >> + if (txr->tx_avail <= EM_TX_CLEANUP_THRESHOLD)
> >> + em_txeof(txr);
> >>if (txr->tx_avail < EM_MAX_SCATTER) {
> >>ifp->if_drv_flags |= IFF_DRV_OACTIVE;
> >>break;
> >> @@ -1411,8 +1410,7 @@
> >>if (!drbr_empty(ifp, txr->br))
> >>em_mq_start_locked(ifp, txr, NULL);
> >> #else
> >> - if (!IFQ_DRV_IS_EMPTY(&ifp->if_snd))
> >> - em_start_locked(ifp, txr);
> >> + em_start_locked(ifp, txr);
> >> #endif
> >>EM_TX_UNLOCK(txr);
> >>
> >> @@ -1475,11 +1473,10 @@
> >>struct ifnet*ifp = adapter->ifp;
> >>struct tx_ring *txr = adapter->tx_rings;
> >>struct rx_ring *rxr = adapter->rx_rings;
> >> - boolmore;
> >> -
> >>
> >>if (ifp->if_drv_flags & IFF_DRV_RUNNING) {
> >> - more = em_rxeof(rxr, adapter->rx_process_limit, NULL);
> >> + boolmore_rx;
> >> + more_rx = em_rxeof(rxr, adapter->rx_process_limit, NULL);
> >>
> >>EM_TX_LOCK(txr);
> >>em_txeof(txr);
> >> @@ -1487,12 +1484,10 @@
> >>if (!drbr_empty(ifp, txr->br))
> >>em_mq_start_locked(ifp, txr, NULL);
> >> #else
> >> - if (!IFQ_DRV_IS_EMPTY(&ifp->if_snd))
> >> - em_start_locked(ifp, txr);
> >> + em_start_locked(ifp, txr);
> >> #endif
> >> - em_txeof(txr);
> >>EM_TX_UNLOCK(txr);
> >> - if (more) {
> >> + if (more_rx || (ifp->if_drv_flags & IFF_DRV_OACTIVE)) {
> >>taskqueue_enqueue(adapter->tq, &adapter->que_task);
> >>return;
> >>}
> >> @@ -1604,7 +1599,6 @@
> >>if (!IFQ_DRV_IS_EMPTY(&ifp->if_snd))
> >>em_start_locked(ifp, txr);
> >> #endif
> >> - em_txeof(txr);
> >>E1000_WRITE_REG(&adapter->hw, E1000_IMS, txr->ims);
> >>EM_TX_UNLOCK(txr);
> >> }
> >> @@ -3730,17 +3724,17 @@
> >>txr->queue_status = EM_QUEUE_HUNG;
> >>
> >> /*
> >> - * If we have enough room, clear IFF_DRV_OACTIVE
> >> + * If we have a minimum free, clear IFF_DRV_OACTIVE
> >> * to tell the stack that it is OK to send packets.
> >> *
Re: em driver, 82574L chip, and possibly ASPM
Was curious too, but being more patient than you :)
Jack
On Fri, Feb 4, 2011 at 10:09 AM, Sean Bruno wrote:
> Any more data on this problem or do we have to wait a while?
>
> Sean
>
>
> On Wed, 2011-02-02 at 10:28 -0800, Mike Tancsa wrote:
> > On 2/2/2011 12:37 PM, Jack Vogel wrote:
> > > So has everyone that wanted to get something testing been able to do
> so?
> >
> > I have been testing in the back and will deploy to my production box
> > this afternoon. As I am not able to reproduce it easily, it will be a
> > bit before I can say the issue is gone. Jan however, was able to
> > trigger it with greater ease ?
> >
> > ---Mike
> >
> > >
> > > Jack
> > >
> > >
> > > On Tue, Feb 1, 2011 at 7:03 PM, Mike Tancsa wrote:
> > >
> > >> On 2/1/2011 5:03 PM, Sean Bruno wrote:
> > >>> On Tue, 2011-02-01 at 13:43 -0800, Jack Vogel wrote:
> > To those who are going to test, here is the if_em.c, based on head,
> > with my
> > changes, I have to leave for the afternoon, and have not had a
> chance
> > to build
> > this, but it should work. I will check back in the later evening.
> >
> > Any blatant problems Sean, feel free to fix them :)
> >
> > Jack
> >
> > >>>
> > >>>
> > >>> I suspect that line 1490 should be:
> > >>> if (more_rx || (ifp->if_drv_flags & IFF_DRV_OACTIVE)) {
> > >>>
> > >>
> > >>
> > >> I have hacked up a RELENG_8 version which I think is correct including
> > >> the above change
> > >>
> > >> http://www.tancsa.com/if_em-8.c
> > >>
> > >>
> > >>
> > >> --- if_em.c.orig2011-02-01 21:47:14.0 -0500
> > >> +++ if_em.c 2011-02-01 21:47:19.0 -0500
> > >> @@ -30,7 +30,7 @@
> > >> POSSIBILITY OF SUCH DAMAGE.
> > >>
> > >>
> > >>
>
> **/
> > >> -/*$FreeBSD: src/sys/dev/e1000/if_em.c,v 1.21.2.20 2011/01/22 01:37:53
> > >> jfv Exp $*/
> > >> +/*$FreeBSD$*/
> > >>
> > >> #ifdef HAVE_KERNEL_OPTION_HEADERS
> > >> #include "opt_device_polling.h"
> > >> @@ -93,7 +93,7 @@
> > >>
> /*
> > >> * Driver version:
> > >>
> */
> > >> -char em_driver_version[] = "7.1.9";
> > >> +char em_driver_version[] = "7.1.9-test";
> > >>
> > >>
> /*
> > >> * PCI Device ID Table
> > >> @@ -927,11 +927,10 @@
> > >>if (!adapter->link_active)
> > >>return;
> > >>
> > >> -/* Call cleanup if number of TX descriptors low */
> > >> - if (txr->tx_avail <= EM_TX_CLEANUP_THRESHOLD)
> > >> - em_txeof(txr);
> > >> -
> > >>while (!IFQ_DRV_IS_EMPTY(&ifp->if_snd)) {
> > >> + /* First cleanup if TX descriptors low */
> > >> + if (txr->tx_avail <= EM_TX_CLEANUP_THRESHOLD)
> > >> + em_txeof(txr);
> > >>if (txr->tx_avail < EM_MAX_SCATTER) {
> > >>ifp->if_drv_flags |= IFF_DRV_OACTIVE;
> > >>break;
> > >> @@ -1411,8 +1410,7 @@
> > >>if (!drbr_empty(ifp, txr->br))
> > >>em_mq_start_locked(ifp, txr, NULL);
> > >> #else
> > >> - if (!IFQ_DRV_IS_EMPTY(&ifp->if_snd))
> > >> - em_start_locked(ifp, txr);
> > >> + em_start_locked(ifp, txr);
> > >> #endif
> > >>EM_TX_UNLOCK(txr);
> > >>
> > >> @@ -1475,11 +1473,10 @@
> > >>struct ifnet*ifp = adapter->ifp;
> > >>struct tx_ring *txr = adapter->tx_rings;
> > >>struct rx_ring *rxr = adapter->rx_rings;
> > >> - boolmore;
> > >> -
> > >>
> > >>if (ifp->if_drv_flags & IFF_DRV_RUNNING) {
> > >> - more = em_rxeof(rxr, adapter->rx_process_limit, NULL);
> > >> + boolmore_rx;
> > >> + more_rx = em_rxeof(rxr, adapter->rx_process_limit,
> NULL);
> > >>
> > >>EM_TX_LOCK(txr);
> > >>em_txeof(txr);
> > >> @@ -1487,12 +1484,10 @@
> > >>if (!drbr_empty(ifp, txr->br))
> > >>em_mq_start_locked(ifp, txr, NULL);
> > >> #else
> > >> - if (!IFQ_DRV_IS_EMPTY(&ifp->if_snd))
> > >> - em_start_locked(ifp, txr);
> > >> + em_start_locked(ifp, txr);
> > >> #endif
> > >> - em_txeof(txr);
> > >>EM_TX_UNLOCK(txr);
> > >> - if (more) {
> > >> + if (more_rx || (ifp->if_drv_flags & IFF_DRV_OACTIVE))
> {
> > >>taskqueue_enqueue(adapter->tq,
> &adapter->que_task);
> > >>return;
> > >>}
> > >> @@ -1604,7 +1599,6 @@
> > >>if (!IFQ_DRV_IS_EMPTY(&ifp->if_snd))
> > >>em_start_locked(ifp, txr);
> > >> #endif
> > >> - em_txeof(txr);
> > >>E1000_WRITE_REG(&adapte
Re: em driver, 82574L chip, and possibly ASPM
meh, patience is not one of my character traits. :-)
Sean
On Fri, 2011-02-04 at 10:12 -0800, Jack Vogel wrote:
> Was curious too, but being more patient than you :)
>
> Jack
>
>
> On Fri, Feb 4, 2011 at 10:09 AM, Sean Bruno
> wrote:
> Any more data on this problem or do we have to wait a while?
>
> Sean
>
>
>
> On Wed, 2011-02-02 at 10:28 -0800, Mike Tancsa wrote:
> > On 2/2/2011 12:37 PM, Jack Vogel wrote:
> > > So has everyone that wanted to get something testing been
> able to do so?
> >
> > I have been testing in the back and will deploy to my
> production box
> > this afternoon. As I am not able to reproduce it easily, it
> will be a
> > bit before I can say the issue is gone. Jan however, was
> able to
> > trigger it with greater ease ?
> >
> > ---Mike
> >
> > >
> > > Jack
> > >
> > >
> > > On Tue, Feb 1, 2011 at 7:03 PM, Mike Tancsa
> wrote:
> > >
> > >> On 2/1/2011 5:03 PM, Sean Bruno wrote:
> > >>> On Tue, 2011-02-01 at 13:43 -0800, Jack Vogel wrote:
> > To those who are going to test, here is the if_em.c,
> based on head,
> > with my
> > changes, I have to leave for the afternoon, and have
> not had a chance
> > to build
> > this, but it should work. I will check back in the
> later evening.
> >
> > Any blatant problems Sean, feel free to fix them :)
> >
> > Jack
> >
> > >>>
> > >>>
> > >>> I suspect that line 1490 should be:
> > >>> if (more_rx || (ifp->if_drv_flags &
> IFF_DRV_OACTIVE)) {
> > >>>
> > >>
> > >>
> > >> I have hacked up a RELENG_8 version which I think is
> correct including
> > >> the above change
> > >>
> > >> http://www.tancsa.com/if_em-8.c
> > >>
> > >>
> > >>
> > >> --- if_em.c.orig2011-02-01 21:47:14.0
> -0500
> > >> +++ if_em.c 2011-02-01 21:47:19.0 -0500
> > >> @@ -30,7 +30,7 @@
> > >> POSSIBILITY OF SUCH DAMAGE.
> > >>
> > >>
> > >>
>
> **/
> > >> -/*$FreeBSD: src/sys/dev/e1000/if_em.c,v 1.21.2.20
> 2011/01/22 01:37:53
> > >> jfv Exp $*/
> > >> +/*$FreeBSD$*/
> > >>
> > >> #ifdef HAVE_KERNEL_OPTION_HEADERS
> > >> #include "opt_device_polling.h"
> > >> @@ -93,7 +93,7 @@
> > >>
>
> /*
> > >> * Driver version:
> > >>
>
> */
> > >> -char em_driver_version[] = "7.1.9";
> > >> +char em_driver_version[] = "7.1.9-test";
> > >>
> > >>
>
> /*
> > >> * PCI Device ID Table
> > >> @@ -927,11 +927,10 @@
> > >>if (!adapter->link_active)
> > >>return;
> > >>
> > >> -/* Call cleanup if number of TX descriptors low
> */
> > >> - if (txr->tx_avail <= EM_TX_CLEANUP_THRESHOLD)
> > >> - em_txeof(txr);
> > >> -
> > >>while (!IFQ_DRV_IS_EMPTY(&ifp->if_snd)) {
> > >> + /* First cleanup if TX descriptors low */
> > >> + if (txr->tx_avail <=
> EM_TX_CLEANUP_THRESHOLD)
> > >> + em_txeof(txr);
> > >>if (txr->tx_avail < EM_MAX_SCATTER) {
> > >>ifp->if_drv_flags |=
> IFF_DRV_OACTIVE;
> > >>break;
> > >> @@ -1411,8 +1410,7 @@
> > >>if (!drbr_empty(ifp, txr->br))
> > >>em_mq_start_locked(ifp, txr, NULL);
> > >> #else
> > >> - if (!IFQ_DRV_IS_EMPTY(&ifp->if_snd))
> > >> - em_start_locked(ifp, txr);
> > >> + em_start_locked(ifp, txr);
> > >> #endif
> > >>EM_TX_UNLOCK(txr);
> > >>
> > >> @@ -1475,11 +1473,10 @@
> > >>struct ifnet*ifp = adapter->ifp;
> > >>struct tx_ring *txr = adapter->tx_rings;
> > >>struct rx_ring *rxr = adapter->rx_rings;
> > >> - boolmore;
> > >> -
> > >>
> > >>if (ifp->if_drv_flags & IFF_DRV_RUNNING) {
> > >> -
Re: em driver, 82574L chip, and possibly ASPM
On 2/4/2011 1:09 PM, Sean Bruno wrote: > Any more data on this problem or do we have to wait a while? On my RELENG_8 production box, so far so good. It usually would hang on weekend runs, so tomorrow would be a good sign, but not a proof that its fixed as it has on occasion survived a few weeks in a row. I am running the version Jack posted with the one change Sean suggested and is at http://www.tancsa.com/if_em-8.c I am also using all default options for the two onboard nics em0: flags=8843 metric 0 mtu 1500 options=219b em1: flags=8843 metric 0 mtu 1500 options=219b em0: port 0x4040-0x405f mem 0xb450-0xb451,0xb4525000-0xb4525fff 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 pci10 em1: Using MSIX interrupts with 3 vectors em1: [ITHREAD] em1: [ITHREAD] em1: [ITHREAD] em1: Ethernet address: 00:15:17:ed:68:a4 em0: link state changed to UP em1: link state changed to UP ---Mike -- --- Mike Tancsa, tel +1 519 651 3400 Sentex Communications, m...@sentex.net Providing Internet services since 1994 www.sentex.net Cambridge, Ontario Canada http://www.tancsa.com/ ___ freebsd-hardware@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hardware To unsubscribe, send any mail to "freebsd-hardware-unsubscr...@freebsd.org"
Re: em driver, 82574L chip, and possibly ASPM
So far so good. I would often get a hang on the level zero dumps to my
backup server Sunday AM, and it made it through! So a good sign, but
not a definitive sign.
I have a PCIe em card that has this chipset as well and was showing the
same sort of problem in a customer's RELENG_7 box. I will see if I can
get the customer to try the card in their box with the patch for
RELENG_7 as it would show this issue at least once a day until I pulled
the card for an older version
---Mike
On 2/4/2011 1:12 PM, Jack Vogel wrote:
> Was curious too, but being more patient than you :)
>
> Jack
>
>
> On Fri, Feb 4, 2011 at 10:09 AM, Sean Bruno wrote:
>
>> Any more data on this problem or do we have to wait a while?
>>
>> Sean
>>
>>
>> On Wed, 2011-02-02 at 10:28 -0800, Mike Tancsa wrote:
>>> On 2/2/2011 12:37 PM, Jack Vogel wrote:
So has everyone that wanted to get something testing been able to do
>> so?
>>>
>>> I have been testing in the back and will deploy to my production box
>>> this afternoon. As I am not able to reproduce it easily, it will be a
>>> bit before I can say the issue is gone. Jan however, was able to
>>> trigger it with greater ease ?
>>>
>>> ---Mike
>>>
Jack
On Tue, Feb 1, 2011 at 7:03 PM, Mike Tancsa wrote:
> On 2/1/2011 5:03 PM, Sean Bruno wrote:
>> On Tue, 2011-02-01 at 13:43 -0800, Jack Vogel wrote:
>>> To those who are going to test, here is the if_em.c, based on head,
>>> with my
>>> changes, I have to leave for the afternoon, and have not had a
>> chance
>>> to build
>>> this, but it should work. I will check back in the later evening.
>>>
>>> Any blatant problems Sean, feel free to fix them :)
>>>
>>> Jack
>>>
>>
>>
>> I suspect that line 1490 should be:
>> if (more_rx || (ifp->if_drv_flags & IFF_DRV_OACTIVE)) {
>>
>
>
> I have hacked up a RELENG_8 version which I think is correct including
> the above change
>
> http://www.tancsa.com/if_em-8.c
>
>
>
> --- if_em.c.orig2011-02-01 21:47:14.0 -0500
> +++ if_em.c 2011-02-01 21:47:19.0 -0500
> @@ -30,7 +30,7 @@
> POSSIBILITY OF SUCH DAMAGE.
>
>
>
>>
>> **/
> -/*$FreeBSD: src/sys/dev/e1000/if_em.c,v 1.21.2.20 2011/01/22 01:37:53
> jfv Exp $*/
> +/*$FreeBSD$*/
>
> #ifdef HAVE_KERNEL_OPTION_HEADERS
> #include "opt_device_polling.h"
> @@ -93,7 +93,7 @@
>
>> /*
> * Driver version:
>
>> */
> -char em_driver_version[] = "7.1.9";
> +char em_driver_version[] = "7.1.9-test";
>
>
>> /*
> * PCI Device ID Table
> @@ -927,11 +927,10 @@
>if (!adapter->link_active)
>return;
>
> -/* Call cleanup if number of TX descriptors low */
> - if (txr->tx_avail <= EM_TX_CLEANUP_THRESHOLD)
> - em_txeof(txr);
> -
>while (!IFQ_DRV_IS_EMPTY(&ifp->if_snd)) {
> + /* First cleanup if TX descriptors low */
> + if (txr->tx_avail <= EM_TX_CLEANUP_THRESHOLD)
> + em_txeof(txr);
>if (txr->tx_avail < EM_MAX_SCATTER) {
>ifp->if_drv_flags |= IFF_DRV_OACTIVE;
>break;
> @@ -1411,8 +1410,7 @@
>if (!drbr_empty(ifp, txr->br))
>em_mq_start_locked(ifp, txr, NULL);
> #else
> - if (!IFQ_DRV_IS_EMPTY(&ifp->if_snd))
> - em_start_locked(ifp, txr);
> + em_start_locked(ifp, txr);
> #endif
>EM_TX_UNLOCK(txr);
>
> @@ -1475,11 +1473,10 @@
>struct ifnet*ifp = adapter->ifp;
>struct tx_ring *txr = adapter->tx_rings;
>struct rx_ring *rxr = adapter->rx_rings;
> - boolmore;
> -
>
>if (ifp->if_drv_flags & IFF_DRV_RUNNING) {
> - more = em_rxeof(rxr, adapter->rx_process_limit, NULL);
> + boolmore_rx;
> + more_rx = em_rxeof(rxr, adapter->rx_process_limit,
>> NULL);
>
>EM_TX_LOCK(txr);
>em_txeof(txr);
> @@ -1487,12 +1484,10 @@
>if (!drbr_empty(ifp, txr->br))
>em_mq_start_locked(ifp, txr, NULL);
> #else
> - if (!IFQ_DRV_IS_EMPTY(&ifp->if_snd))
> - em_start_locked(ifp, txr);
> + em_start_locked(ifp, txr);
> #endif
> - em_txeof(txr);
>EM_TX_UNLOCK(txr);
> -
Re: em driver, 82574L chip, and possibly ASPM
I have similar problems on a couple of 7.3 boxes with latest driver form
-CURRENT.
I just wanted to know if your 7 boxes work fine so I look for cause else where.
On 2/7/2011 3:23 AM, Mike Tancsa wrote:
So far so good. I would often get a hang on the level zero dumps to my
backup server Sunday AM, and it made it through! So a good sign, but
not a definitive sign.
I have a PCIe em card that has this chipset as well and was showing the
same sort of problem in a customer's RELENG_7 box. I will see if I can
get the customer to try the card in their box with the patch for
RELENG_7 as it would show this issue at least once a day until I pulled
the card for an older version
---Mike
On 2/4/2011 1:12 PM, Jack Vogel wrote:
Was curious too, but being more patient than you :)
Jack
On Fri, Feb 4, 2011 at 10:09 AM, Sean Bruno wrote:
Any more data on this problem or do we have to wait a while?
Sean
On Wed, 2011-02-02 at 10:28 -0800, Mike Tancsa wrote:
On 2/2/2011 12:37 PM, Jack Vogel wrote:
So has everyone that wanted to get something testing been able to do
so?
I have been testing in the back and will deploy to my production box
this afternoon. As I am not able to reproduce it easily, it will be a
bit before I can say the issue is gone. Jan however, was able to
trigger it with greater ease ?
---Mike
Jack
On Tue, Feb 1, 2011 at 7:03 PM, Mike Tancsa wrote:
On 2/1/2011 5:03 PM, Sean Bruno wrote:
On Tue, 2011-02-01 at 13:43 -0800, Jack Vogel wrote:
To those who are going to test, here is the if_em.c, based on head,
with my
changes, I have to leave for the afternoon, and have not had a
chance
to build
this, but it should work. I will check back in the later evening.
Any blatant problems Sean, feel free to fix them :)
Jack
I suspect that line 1490 should be:
if (more_rx || (ifp->if_drv_flags& IFF_DRV_OACTIVE)) {
I have hacked up a RELENG_8 version which I think is correct including
the above change
http://www.tancsa.com/if_em-8.c
--- if_em.c.orig2011-02-01 21:47:14.0 -0500
+++ if_em.c 2011-02-01 21:47:19.0 -0500
@@ -30,7 +30,7 @@
POSSIBILITY OF SUCH DAMAGE.
**/
-/*$FreeBSD: src/sys/dev/e1000/if_em.c,v 1.21.2.20 2011/01/22 01:37:53
jfv Exp $*/
+/*$FreeBSD$*/
#ifdef HAVE_KERNEL_OPTION_HEADERS
#include "opt_device_polling.h"
@@ -93,7 +93,7 @@
/*
* Driver version:
*/
-char em_driver_version[] = "7.1.9";
+char em_driver_version[] = "7.1.9-test";
/*
* PCI Device ID Table
@@ -927,11 +927,10 @@
if (!adapter->link_active)
return;
-/* Call cleanup if number of TX descriptors low */
- if (txr->tx_avail<= EM_TX_CLEANUP_THRESHOLD)
- em_txeof(txr);
-
while (!IFQ_DRV_IS_EMPTY(&ifp->if_snd)) {
+ /* First cleanup if TX descriptors low */
+ if (txr->tx_avail<= EM_TX_CLEANUP_THRESHOLD)
+ em_txeof(txr);
if (txr->tx_avail< EM_MAX_SCATTER) {
ifp->if_drv_flags |= IFF_DRV_OACTIVE;
break;
@@ -1411,8 +1410,7 @@
if (!drbr_empty(ifp, txr->br))
em_mq_start_locked(ifp, txr, NULL);
#else
- if (!IFQ_DRV_IS_EMPTY(&ifp->if_snd))
- em_start_locked(ifp, txr);
+ em_start_locked(ifp, txr);
#endif
EM_TX_UNLOCK(txr);
@@ -1475,11 +1473,10 @@
struct ifnet*ifp = adapter->ifp;
struct tx_ring *txr = adapter->tx_rings;
struct rx_ring *rxr = adapter->rx_rings;
- boolmore;
-
if (ifp->if_drv_flags& IFF_DRV_RUNNING) {
- more = em_rxeof(rxr, adapter->rx_process_limit, NULL);
+ boolmore_rx;
+ more_rx = em_rxeof(rxr, adapter->rx_process_limit,
NULL);
EM_TX_LOCK(txr);
em_txeof(txr);
@@ -1487,12 +1484,10 @@
if (!drbr_empty(ifp, txr->br))
em_mq_start_locked(ifp, txr, NULL);
#else
- if (!IFQ_DRV_IS_EMPTY(&ifp->if_snd))
- em_start_locked(ifp, txr);
+ em_start_locked(ifp, txr);
#endif
- em_txeof(txr);
EM_TX_UNLOCK(txr);
- if (more) {
+ if (more_rx || (ifp->if_drv_flags& IFF_DRV_OACTIVE))
{
taskqueue_enqueue(adapter->tq,
&adapter->que_task);
return;
}
@@ -1604,7 +1599,6 @@
if (!IFQ_DRV_IS_EMPTY(&ifp->if_snd))
em_start_locked(ifp, txr);
#endif
- em_txeof(txr);
E1000_WRITE_REG(&adapter->hw, E1000_IMS, txr->ims);
EM_TX_UNLOCK(txr)
Re: em driver, 82574L chip, and possibly ASPM
On 7/12/2011 3:03 PM, Hooman Fazaeli wrote: > > I have similar problems on a couple of 7.3 boxes with latest driver form > -CURRENT. > I just wanted to know if your 7 boxes work fine so I look for cause else > where. Yes, all has been working quite well for me to date. em1@pci0:11: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 pci11 em1: Using MSIX interrupts with 3 vectors em1: [ITHREAD] em1: [ITHREAD] em1: [ITHREAD] ---Mike -- --- Mike Tancsa, tel +1 519 651 3400 Sentex Communications, m...@sentex.net Providing Internet services since 1994 www.sentex.net Cambridge, Ontario Canada http://www.tancsa.com/ ___ freebsd-hardware@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hardware To unsubscribe, send any mail to "freebsd-hardware-unsubscr...@freebsd.org"
