freebsd-stable Digest, Vol 351, Issue 8
freebsd-sta...@freebsd.org
freebsd...@freebsd.org
To subscribe or unsubscribe via the World Wide Web, visit
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
or, via email, send a message with subject or body 'help' to
freebsd-sta...@freebsd.org
You can reach the person managing the list at
freebsd-st...@freebsd.org
When replying, please edit your Subject line so it is more specific
than "Re: Contents of freebsd-stable digest..."
Today's Topics:
1. Re: em driver regression (Jack Vogel)
2. Re: em driver regression (Brandon Gooch)
3. Re: em driver regression (Pyun YongHyeon)
4. Re: em driver regression (Mike Tancsa)
5. Re: em driver regression (Jack Vogel)
6. Re: em driver regression (Pyun YongHyeon)
7. Realtek Ethernet not functioning on Asus M4A89GTD PRO
(Michael Beckmann)
8. booting issue with xen (Henrik Hudson)
9. Re: em driver regression (Jack Vogel)
10. Re: Realtek Ethernet not functioning on Asus M4A89GTD PRO
(Adam Vande More)
11. please see the conf/141050 (Svyatoslav Lempert)
12. please see the conf/141050 (Svyatoslav Lempert)
13. Re: CPU problems after 8.0-STABLE update (Jakub Lach)
14. RE: Realtek Ethernet not functioning on Asus M4A89GTD PRO
(Michael Beckmann)
----------------------------------------------------------------------
Message: 1
Date: Thu, 8 Apr 2010 12:17:01 -0700
From: Jack Vogel <jfv...@gmail.com>
Subject: Re: em driver regression
To: pyu...@gmail.com, Brandon Gooch <bgo...@se.edu>
Cc: freebsd...@freebsd.org
Message-ID:
<q2k2a41acea1004081217t2...@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1
Try the code I just checked in, it puts in the CRC stripping, but also
tweaks the
TX code, this may resolve the watchdogs. Let me know.
Cheers,
Jack
On Thu, Apr 8, 2010 at 11:39 AM, Pyun YongHyeon <pyu...@gmail.com> wrote:
> On Thu, Apr 08, 2010 at 11:27:10AM -0700, Jack Vogel wrote:
> > You know, I'm wondering if the so-called ALTQ fix, which makes the TX
> > start always queue is causing the problem on that side?
> >
>
> I'm not sure because I didn't configure ALTQ so it might be NOP for
> non-ALTQ case.
>
> > Jack
> >
> >
> > On Thu, Apr 8, 2010 at 11:22 AM, Jack Vogel <jfv...@gmail.com> wrote:
> >
> > >
> > >
> > > On Thu, Apr 8, 2010 at 11:17 AM, Pyun YongHyeon <pyu...@gmail.com>
> wrote:
> > >
> > >> On Thu, Apr 08, 2010 at 10:46:22AM -0400, Mike Tancsa wrote:
> > >> >
> > >> > OK, some more data... It seems dhclient is getting upset as well
> > >> > since the updated driver
> > >> >
> > >> > Apr 8 10:28:37 ich10 dhclient[1383]: DHCPDISCOVER on em0 to
> > >> > 255.255.255.255 port 67 interval 6
> > >> > Apr 8 10:28:38 ich10 dhclient[1383]: ip length 328 disagrees with
> > >> > bytes received 332.
> > >> > Apr 8 10:28:38 ich10 dhclient[1383]: accepting packet with data
> > >> > after udp payload.
> > >> > Apr 8 10:28:38 ich10 dhclient[1383]: DHCPOFFER from 192.168.xx.1
> > >> > Apr 8 10:28:40 ich10 dhclient[1383]: DHCPREQUEST on em0 to
> > >> > 255.255.255.255 port 67
> > >> > Apr 8 10:28:40 ich10 dhclient[1383]: ip length 328 disagrees with
> > >> > bytes received 332.
> > >> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> > >>
> > >> Try this patch. It should fix the issue. It seems Jack forgot to
> > >> strip CRC bytes as old em(4) didn't strip it, probably to
> > >> workaround silicon bug of old em(4) controllers.
> > >>
> > >>
> > > Actually it did strip it, but its buried in the code in an obscure way,
> > > that's
> > > what I just realized by looking at the old code. having the hardware
> strip
> > > will be easier I think.
> > >
> > >
> > >> It seems there are also TX issues here. The system load is too high
> > >> and sometimes system is not responsive while TX is in progress.
> > >> Because I initiated TCP bulk transfers, TSO should reduce CPU load
> > >> a lot but it didn't so I guess it could also be related watchdog
> > >> timeouts you've seen. I'll see what can be done.
> > >>
> > >
> > > Will look at that as well.
> > >
> > > Thanks!
> > >
> > > Jack
> > >
> > >
>
------------------------------
Message: 2
Date: Thu, 8 Apr 2010 14:52:07 -0500
From: Brandon Gooch <jamesbra...@gmail.com>
Subject: Re: em driver regression
To: Jack Vogel <jfv...@gmail.com>
Cc: pyu...@gmail.com, Brandon Gooch <bgo...@se.edu>,
freebsd...@freebsd.org
Message-ID:
<r2w179b97fb1004081252k2...@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1
On Thu, Apr 8, 2010 at 2:17 PM, Jack Vogel <jfv...@gmail.com> wrote:
> Try the code I just checked in, it puts in the CRC stripping, but also
> tweaks the
> TX code, this may resolve the watchdogs. Let me know.
>
> Cheers,
>
> Jack
>
Yes, this is indeed the fix for both the dhclient and VirtualBox issue
(at least with my setup). There appear to be no ill effects either.
Thank you Jack (and Pyun) for tracking down the problems! I'll keep my
eyes open for anything else.
-Brandon
------------------------------
Message: 3
Date: Thu, 8 Apr 2010 13:56:26 -0700
From: Pyun YongHyeon <pyu...@gmail.com>
Subject: Re: em driver regression
To: Mike Tancsa <mi...@sentex.net>
Cc: freebsd...@freebsd.org, jfv...@gmail.com
Message-ID: <2010040820...@michelle.cdnetworks.com>
Content-Type: text/plain; charset="us-ascii"
On Thu, Apr 08, 2010 at 02:31:18PM -0400, Mike Tancsa wrote:
> At 02:17 PM 4/8/2010, Pyun YongHyeon wrote:
>
> >Try this patch. It should fix the issue. It seems Jack forgot to
> >strip CRC bytes as old em(4) didn't strip it, probably to
> >workaround silicon bug of old em(4) controllers.
>
> Thanks! The attached patch does indeed fix the dhclient issue.
>
>
> >It seems there are also TX issues here. The system load is too high
> >and sometimes system is not responsive while TX is in progress.
> >Because I initiated TCP bulk transfers, TSO should reduce CPU load
> >a lot but it didn't so I guess it could also be related watchdog
> >timeouts you've seen. I'll see what can be done.
>
> Thanks for looking into that as well!!
>
> ---Mike
>
Mike,
Here is patch I'm working on. This patch fixes high system load and
system is very responsive as before. But it seems there is still
some TX issue here. Bulk UDP performance is very poor(< 700Mbps)
and I have no idea what caused this at this moment.
BTW, I have trouble to reproduce watchdog timeouts. I'm not sure
whether latest fix from Jack cured it. By chance does your
controller support multi TX/RX queues? You can check whether em(4)
uses multi-queues with "vmstat -i". If em(4) use multi-queue you
may have multiple irq output for em0.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: em.load.patch
Type: text/x-diff
Size: 4026 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20100408/5271a0d7/em.load-0001.bin
------------------------------
Message: 4
Date: Thu, 08 Apr 2010 17:05:05 -0400
From: Mike Tancsa <mi...@sentex.net>
Subject: Re: em driver regression
To: pyu...@gmail.com
Cc: freebsd...@freebsd.org, jfv...@gmail.com
Message-ID: <201004082105....@lava.sentex.ca>
Content-Type: text/plain; charset="us-ascii"; format=flowed
At 04:56 PM 4/8/2010, Pyun YongHyeon wrote:
>On Thu, Apr 08, 2010 at 02:31:18PM -0400, Mike Tancsa wrote:
> > At 02:17 PM 4/8/2010, Pyun YongHyeon wrote:
> >
> > >Try this patch. It should fix the issue. It seems Jack forgot to
> > >strip CRC bytes as old em(4) didn't strip it, probably to
> > >workaround silicon bug of old em(4) controllers.
> >
> > Thanks! The attached patch does indeed fix the dhclient issue.
> >
> >
> > >It seems there are also TX issues here. The system load is too high
> > >and sometimes system is not responsive while TX is in progress.
> > >Because I initiated TCP bulk transfers, TSO should reduce CPU load
> > >a lot but it didn't so I guess it could also be related watchdog
> > >timeouts you've seen. I'll see what can be done.
> >
> > Thanks for looking into that as well!!
> >
> > ---Mike
> >
>
>Mike,
>
>Here is patch I'm working on. This patch fixes high system load and
>system is very responsive as before. But it seems there is still
>some TX issue here. Bulk UDP performance is very poor(< 700Mbps)
>and I have no idea what caused this at this moment.
>
>BTW, I have trouble to reproduce watchdog timeouts. I'm not sure
>whether latest fix from Jack cured it. By chance does your
>controller support multi TX/RX queues? You can check whether em(4)
>uses multi-queues with "vmstat -i". If em(4) use multi-queue you
>may have multiple irq output for em0.
Hi,
I will give it a try later tonight! This one does not seem to.
0(ich10)# vmstat -i
interrupt total rate
irq16: uhci0+ 30 0
irq18: ehci0 uhci5 158419 17
irq19: fwohci0++ 86 0
irq21: uhci1 17 0
irq23: uhci3 ehci1 2 0
cpu0: timer 18570305 1994
irq256: igb0 80 0
irq257: igb0 255 0
irq258: igb0 66 0
irq259: igb0 32 0
irq260: igb0 2 0
irq261: igb1 2679 0
irq262: igb1 998 0
irq263: igb1 2468 0
irq264: igb1 6361 0
irq265: igb1 2 0
irq266: em0 33910 3
irq267: ahci1 15317 1
cpu1: timer 18557074 1993
cpu3: timer 18557168 1993
cpu2: timer 18557108 1993
Total 74462379 7998
0(ich10)#
--------------------------------------------------------------------
Mike Tancsa, tel +1 519 651 3400
Sentex Communications, mi...@sentex.net
Providing Internet since 1994 www.sentex.net
Cambridge, Ontario Canada www.sentex.net/mike
------------------------------
Message: 5
Date: Thu, 8 Apr 2010 14:06:09 -0700
From: Jack Vogel <jfv...@gmail.com>
Subject: Re: em driver regression
To: Mike Tancsa <mi...@sentex.net>
Cc: pyu...@gmail.com, freebsd...@freebsd.org
Message-ID:
<n2q2a41acea1004081406o9...@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1
Only one device support by em does multiqueue right now, and that is
Hartwell, 82574.
Jack
On Thu, Apr 8, 2010 at 2:05 PM, Mike Tancsa <mi...@sentex.net> wrote:
> At 04:56 PM 4/8/2010, Pyun YongHyeon wrote:
>
>> On Thu, Apr 08, 2010 at 02:31:18PM -0400, Mike Tancsa wrote:
>> > At 02:17 PM 4/8/2010, Pyun YongHyeon wrote:
>> >
>> > >Try this patch. It should fix the issue. It seems Jack forgot to
>> > >strip CRC bytes as old em(4) didn't strip it, probably to
>> > >workaround silicon bug of old em(4) controllers.
>> >
>> > Thanks! The attached patch does indeed fix the dhclient issue.
>> >
>> >
>> > >It seems there are also TX issues here. The system load is too high
>> > >and sometimes system is not responsive while TX is in progress.
>> > >Because I initiated TCP bulk transfers, TSO should reduce CPU load
>> > >a lot but it didn't so I guess it could also be related watchdog
>> > >timeouts you've seen. I'll see what can be done.
>> >
>> > Thanks for looking into that as well!!
>> >
>> > ---Mike
>> >
>>
>> Mike,
>>
>> Here is patch I'm working on. This patch fixes high system load and
>> system is very responsive as before. But it seems there is still
>> some TX issue here. Bulk UDP performance is very poor(< 700Mbps)
>> and I have no idea what caused this at this moment.
>>
>> BTW, I have trouble to reproduce watchdog timeouts. I'm not sure
>> whether latest fix from Jack cured it. By chance does your
>> controller support multi TX/RX queues? You can check whether em(4)
>> uses multi-queues with "vmstat -i". If em(4) use multi-queue you
>> may have multiple irq output for em0.
>>
>
> Hi,
> I will give it a try later tonight! This one does not seem to.
>
> 0(ich10)# vmstat -i
> interrupt total rate
> irq16: uhci0+ 30 0
> irq18: ehci0 uhci5 158419 17
> irq19: fwohci0++ 86 0
> irq21: uhci1 17 0
> irq23: uhci3 ehci1 2 0
> cpu0: timer 18570305 1994
> irq256: igb0 80 0
> irq257: igb0 255 0
> irq258: igb0 66 0
> irq259: igb0 32 0
> irq260: igb0 2 0
> irq261: igb1 2679 0
> irq262: igb1 998 0
> irq263: igb1 2468 0
> irq264: igb1 6361 0
> irq265: igb1 2 0
> irq266: em0 33910 3
> irq267: ahci1 15317 1
> cpu1: timer 18557074 1993
> cpu3: timer 18557168 1993
> cpu2: timer 18557108 1993
> Total 74462379 7998
> 0(ich10)#
>
>
>
>
>
>
>
> --------------------------------------------------------------------
> Mike Tancsa, tel +1 519 651 3400
> Sentex Communications, mi...@sentex.net
> Providing Internet since 1994 www.sentex.net
> Cambridge, Ontario Canada www.sentex.net/mike
>
>
------------------------------
Message: 6
Date: Thu, 8 Apr 2010 16:07:50 -0700
From: Pyun YongHyeon <pyu...@gmail.com>
Subject: Re: em driver regression
To: Jack Vogel <jfv...@gmail.com>
Cc: freebsd...@freebsd.org
Message-ID: <2010040823...@michelle.cdnetworks.com>
Content-Type: text/plain; charset="us-ascii"
On Thu, Apr 08, 2010 at 02:06:09PM -0700, Jack Vogel wrote:
> Only one device support by em does multiqueue right now, and that is
> Hartwell, 82574.
>
Thanks for the info.
Mike, here is updated patch. Now UDP bulk TX transfer performance
recovered a lot(about 890Mbps) but it still shows bad numbers
compared to other controllers. For example, bce(4) shows about
958Mbps for the same load.
During the testing I found a strong indication of packet reordering
issue of drbr interface. If I forcibly change to use single TX
queue, em(4) got 950Mbps as it used to be.
Jack, as we talked about possible drbr issue with igb(4), UDP
transfer seems to suffer from packet reordering issue here. Can we
make em(4)/igb(4) use single TX queue until we solve drbr interface
issue? Given that only one em(4) controller supports multiqueue,
dropping multiqueue support for em(4) does not look bad to me.
> Jack
>
>
> On Thu, Apr 8, 2010 at 2:05 PM, Mike Tancsa <mi...@sentex.net> wrote:
>
> > At 04:56 PM 4/8/2010, Pyun YongHyeon wrote:
> >
> >> On Thu, Apr 08, 2010 at 02:31:18PM -0400, Mike Tancsa wrote:
> >> > At 02:17 PM 4/8/2010, Pyun YongHyeon wrote:
> >> >
> >> > >Try this patch. It should fix the issue. It seems Jack forgot to
> >> > >strip CRC bytes as old em(4) didn't strip it, probably to
> >> > >workaround silicon bug of old em(4) controllers.
> >> >
> >> > Thanks! The attached patch does indeed fix the dhclient issue.
> >> >
> >> >
> >> > >It seems there are also TX issues here. The system load is too high
> >> > >and sometimes system is not responsive while TX is in progress.
> >> > >Because I initiated TCP bulk transfers, TSO should reduce CPU load
> >> > >a lot but it didn't so I guess it could also be related watchdog
> >> > >timeouts you've seen. I'll see what can be done.
> >> >
> >> > Thanks for looking into that as well!!
> >> >
> >> > ---Mike
> >> >
> >>
> >> Mike,
> >>
> >> Here is patch I'm working on. This patch fixes high system load and
> >> system is very responsive as before. But it seems there is still
> >> some TX issue here. Bulk UDP performance is very poor(< 700Mbps)
> >> and I have no idea what caused this at this moment.
> >>
> >> BTW, I have trouble to reproduce watchdog timeouts. I'm not sure
> >> whether latest fix from Jack cured it. By chance does your
> >> controller support multi TX/RX queues? You can check whether em(4)
> >> uses multi-queues with "vmstat -i". If em(4) use multi-queue you
> >> may have multiple irq output for em0.
> >>
> >
> > Hi,
> > I will give it a try later tonight! This one does not seem to.
> >
> > 0(ich10)# vmstat -i
> > interrupt total rate
> > irq16: uhci0+ 30 0
> > irq18: ehci0 uhci5 158419 17
> > irq19: fwohci0++ 86 0
> > irq21: uhci1 17 0
> > irq23: uhci3 ehci1 2 0
> > cpu0: timer 18570305 1994
> > irq256: igb0 80 0
> > irq257: igb0 255 0
> > irq258: igb0 66 0
> > irq259: igb0 32 0
> > irq260: igb0 2 0
> > irq261: igb1 2679 0
> > irq262: igb1 998 0
> > irq263: igb1 2468 0
> > irq264: igb1 6361 0
> > irq265: igb1 2 0
> > irq266: em0 33910 3
> > irq267: ahci1 15317 1
> > cpu1: timer 18557074 1993
> > cpu3: timer 18557168 1993
> > cpu2: timer 18557108 1993
> > Total 74462379 7998
> > 0(ich10)#
> >
-------------- next part --------------
Index: sys/dev/e1000/if_em.c
===================================================================
--- sys/dev/e1000/if_em.c (revision 206403)
+++ sys/dev/e1000/if_em.c (working copy)
@@ -812,6 +812,10 @@
return (err);
}
+ /* Call cleanup if number of TX descriptors low */
+ if (txr->tx_avail <= EM_TX_CLEANUP_THRESHOLD)
+ em_txeof(txr);
+
enq = 0;
if (m == NULL) {
next = drbr_dequeue(ifp, txr->br);
@@ -834,11 +838,16 @@
ETHER_BPF_MTAP(ifp, next);
if ((ifp->if_drv_flags & IFF_DRV_RUNNING) == 0)
break;
+ if (txr->tx_avail < EM_MAX_SCATTER) {
+ ifp->if_drv_flags |= IFF_DRV_OACTIVE;
+ break;
+ }
next = drbr_dequeue(ifp, txr->br);
}
if (enq > 0) {
/* Set the watchdog */
+ txr->watchdog_time = ticks;
txr->watchdog_check = TRUE;
}
return (err);
@@ -864,8 +873,7 @@
txr = &adapter->tx_rings[i];
if (EM_TX_TRYLOCK(txr)) {
- if (ifp->if_drv_flags & IFF_DRV_RUNNING)
- error = em_mq_start_locked(ifp, txr, m);
+ error = em_mq_start_locked(ifp, txr, m);
EM_TX_UNLOCK(txr);
} else
error = drbr_enqueue(ifp, txr->br, m);
@@ -909,8 +917,15 @@
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)) {
-
+ if (txr->tx_avail < EM_MAX_SCATTER) {
+ ifp->if_drv_flags |= IFF_DRV_OACTIVE;
+ break;
+ }
IFQ_DRV_DEQUEUE(&ifp->if_snd, m_head);
if (m_head == NULL)
break;
@@ -930,7 +945,8 @@
ETHER_BPF_MTAP(ifp, m_head);
/* Set timeout in case hardware has problems transmitting. */
- txr->watchdog_check = TRUE;
+ txr->watchdog_time = ticks;
+ txr->watchdog_check = TRUE;
}
return;
@@ -1427,17 +1443,12 @@
struct ifnet *ifp = adapter->ifp;
struct tx_ring *txr = adapter->tx_rings;
struct rx_ring *rxr = adapter->rx_rings;
- u32 loop = EM_MAX_LOOP;
- bool more_rx, more_tx;
+ bool more_rx;
-
if (ifp->if_drv_flags & IFF_DRV_RUNNING) {
+ more_rx = em_rxeof(rxr, adapter->rx_process_limit);
EM_TX_LOCK(txr);
- do {
- more_rx = em_rxeof(rxr, adapter->rx_process_limit);
- more_tx = em_txeof(txr);
- } while (loop-- && (more_rx || more_tx));
-
+ em_txeof(txr);
#if __FreeBSD_version >= 800000
if (!drbr_empty(ifp, txr->br))
em_mq_start_locked(ifp, txr, NULL);
@@ -1445,10 +1456,9 @@
if (!IFQ_DRV_IS_EMPTY(&ifp->if_snd))
em_start_locked(ifp, txr);
#endif
- if (more_rx || more_tx)
+ EM_TX_UNLOCK(txr);
+ if (more_rx)
taskqueue_enqueue(adapter->tq, &adapter->que_task);
-
- EM_TX_UNLOCK(txr);
}
em_enable_intr(adapter);
@@ -1466,18 +1476,13 @@
{
struct tx_ring *txr = arg;
struct adapter *adapter = txr->adapter;
- bool more;
++txr->tx_irq;
EM_TX_LOCK(txr);
- more = em_txeof(txr);
+ em_txeof(txr);
EM_TX_UNLOCK(txr);
- if (more)
- taskqueue_enqueue(txr->tq, &txr->tx_task);
- else
- /* Reenable this interrupt */
- E1000_WRITE_REG(&adapter->hw, E1000_IMS, txr->ims);
- return;
+ /* Reenable this interrupt */
+ E1000_WRITE_REG(&adapter->hw, E1000_IMS, txr->ims);
}
/*********************************************************************
@@ -1531,14 +1536,15 @@
{
struct rx_ring *rxr = context;
struct adapter *adapter = rxr->adapter;
- u32 loop = EM_MAX_LOOP;
bool more;
- do {
- more = em_rxeof(rxr, adapter->rx_process_limit);
- } while (loop-- && more);
- /* Reenable this interrupt */
- E1000_WRITE_REG(&adapter->hw, E1000_IMS, rxr->ims);
+ more = em_rxeof(rxr, adapter->rx_process_limit);
+ if (more)
+ taskqueue_enqueue(rxr->tq, &rxr->rx_task);
+ else {
+ /* Reenable this interrupt */
+ E1000_WRITE_REG(&adapter->hw, E1000_IMS, rxr->ims);
+ }
}
static void
@@ -1547,15 +1553,10 @@
struct tx_ring *txr = context;
struct adapter *adapter = txr->adapter;
struct ifnet *ifp = adapter->ifp;
- u32 loop = EM_MAX_LOOP;
- bool more;
if (!EM_TX_TRYLOCK(txr))
return;
- do {
- more = em_txeof(txr);
- } while (loop-- && more);
-
+ em_txeof(txr);
#if __FreeBSD_version >= 800000
if (!drbr_empty(ifp, txr->br))
em_mq_start_locked(ifp, txr, NULL);
@@ -1912,12 +1913,7 @@
bus_dmamap_sync(txr->txdma.dma_tag, txr->txdma.dma_map,
BUS_DMASYNC_PREREAD | BUS_DMASYNC_PREWRITE);
E1000_WRITE_REG(&adapter->hw, E1000_TDT(txr->me), i);
- txr->watchdog_time = ticks;
- /* Call cleanup if number of TX descriptors low */
- if (txr->tx_avail <= EM_TX_CLEANUP_THRESHOLD)
- em_txeof(txr);
-
return (0);
}
@@ -3619,7 +3615,8 @@
if (last != -1) {
eop_desc = &txr->tx_base[last];
/* Get new done point */
- if (++last == adapter->num_tx_desc) last = 0;
+ if (++last == adapter->num_tx_desc)
+ last = 0;
done = last;
} else
break;
@@ -4078,7 +4075,7 @@
em_rxeof(struct rx_ring *rxr, int count)
{
struct adapter *adapter = rxr->adapter;
- struct ifnet *ifp = adapter->ifp;;
+ struct ifnet *ifp = adapter->ifp;
struct mbuf *mp, *sendmp;
u8 status;
u16 len;
@@ -4088,6 +4085,7 @@
EM_RX_LOCK(rxr);
+ status = 0;
for (i = rxr->next_to_check, processed = 0; count != 0;) {
if ((ifp->if_drv_flags & IFF_DRV_RUNNING) == 0)
@@ -4195,7 +4193,11 @@
rxr->next_to_check = i;
EM_RX_UNLOCK(rxr);
+#ifdef DEVICE_POLLING
return (rxdone);
+#else
+ return ((status & E1000_RXD_STAT_DD) ? TRUE : FALSE);
+#endif
}
#ifndef __NO_STRICT_ALIGNMENT
Index: sys/dev/e1000/if_em.h
===================================================================
--- sys/dev/e1000/if_em.h (revision 206403)
+++ sys/dev/e1000/if_em.h (working copy)
@@ -223,7 +223,7 @@
#define HW_DEBUGOUT1(S, A) if (DEBUG_HW) printf(S "\n", A)
#define HW_DEBUGOUT2(S, A, B) if (DEBUG_HW) printf(S "\n", A, B)
-#define EM_MAX_SCATTER 64
+#define EM_MAX_SCATTER 32
#define EM_VFTA_SIZE 128
#define EM_TSO_SIZE (65535 + sizeof(struct ether_vlan_header))
#define EM_TSO_SEG_SIZE 4096 /* Max dma segment size */
------------------------------
Message: 7
Date: Fri, 9 Apr 2010 01:50:02 +0200
From: "Michael Beckmann" <mic...@apfel.de>
Subject: Realtek Ethernet not functioning on Asus M4A89GTD PRO
To: <sta...@freebsd.org>
Message-ID:
<!&!AAAAAAAAAAAYAAAAAAAAAFu8E7CkEvBMsgZ/8G4PwcPigAAAEAAAAHlHe9UOq29Hg4tmJB6O8ysBAAAAAA==@apfel.de>
Content-Type: text/plain; charset="US-ASCII"
Greetings,
the onboard Realtek Ethernet on my Asus M4A89GTD PRO is not functioning.
I use FreeBSD 8.0-STABLE with a generic kernel (amd64). Everything was
updated March 27, 2010.
Is it a bug?
Thanks,
Michael
pcib4: <ACPI PCI-PCI bridge> at device 21.0 on pci0
pci4: <ACPI PCI bus> on pcib4
re0: <RealTek 8168/8168B/8168C/8168CP/8168D/8168DP/8111B/8111C/8111CP/8111DP
PCIe Gigabit Ethernet> port 0xe800-0xe8ff mem
0xfdfff000-0xfdffffff,0xfdff8000-0xfdffbfff irq 16 at device 0.0 on pci4
re0: Using 1 MSI messages
re0: Chip rev. 0x2c000000
re0: MAC rev. 0x00000000
re0: Unknown H/W revision: 0x2c000000
device_attach: re0 attach returned 6
------------------------------
Message: 8
Date: Thu, 8 Apr 2010 16:33:54 -0800
From: Henrik Hudson <li...@rhavenn.net>
Subject: booting issue with xen
To: freebsd...@freebsd.org
Message-ID: <2010040900...@alucard.int.rhavenn.net>
Content-Type: text/plain; charset=us-ascii
note: i apologize for the new thread, but i accidently deleted the
old one.
I emailed a few days back about having issues running 8-STABLE in a
Xen environment. I solved this, sort of.
a) some more info on the environment:
-it's a Xen HVM hosted environment. So, the XEN DomU kernel
shouldn't be needed.
-i386 if I didn't mention that before.
b) I stripped down the kernel file to barebones for Xen HVM and now
if I select "Boot in Safe Mode" it works fine.
So, the question to the list: What does "Boot in Safe Mode" disable
that is causing the hang up in Xen? The kernel boots, it doesn't
throw any obvious errors, but hangs at "Trying to mount disk". When
I select "Boot in Safe Mode" it comes up fine.
thoughts?
henrik
--
Henrik Hudson
li...@rhavenn.net
-----------------------------------------
"God, root, what is difference?" Pitr; UF
------------------------------
Message: 9
Date: Thu, 8 Apr 2010 18:48:11 -0700
From: Jack Vogel <jfv...@gmail.com>
Subject: Re: em driver regression
To: pyu...@gmail.com
Cc: freebsd...@freebsd.org
Message-ID:
<j2i2a41acea1004081848k2...@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1
Ah, ok, let me play around with it a bit, perhaps I'll make it definable,
of course if there is no positive benefit from using it it would seem silly
to leave it around :)
Will look at your patch changes and that issue tomorrow. Thanks
for your efforts!
Jack
On Thu, Apr 8, 2010 at 4:07 PM, Pyun YongHyeon <pyu...@gmail.com> wrote:
> On Thu, Apr 08, 2010 at 02:06:09PM -0700, Jack Vogel wrote:
> > Only one device support by em does multiqueue right now, and that is
> > Hartwell, 82574.
> >
>
> Thanks for the info.
>
> Mike, here is updated patch. Now UDP bulk TX transfer performance
> recovered a lot(about 890Mbps) but it still shows bad numbers
> compared to other controllers. For example, bce(4) shows about
> 958Mbps for the same load.
> During the testing I found a strong indication of packet reordering
> issue of drbr interface. If I forcibly change to use single TX
> queue, em(4) got 950Mbps as it used to be.
>
> Jack, as we talked about possible drbr issue with igb(4), UDP
> transfer seems to suffer from packet reordering issue here. Can we
> make em(4)/igb(4) use single TX queue until we solve drbr interface
> issue? Given that only one em(4) controller supports multiqueue,
> dropping multiqueue support for em(4) does not look bad to me.
>
> > Jack
> >
> >
> > On Thu, Apr 8, 2010 at 2:05 PM, Mike Tancsa <mi...@sentex.net> wrote:
> >
> > > At 04:56 PM 4/8/2010, Pyun YongHyeon wrote:
> > >
> > >> On Thu, Apr 08, 2010 at 02:31:18PM -0400, Mike Tancsa wrote:
> > >> > At 02:17 PM 4/8/2010, Pyun YongHyeon wrote:
> > >> >
> > >> > >Try this patch. It should fix the issue. It seems Jack forgot to
> > >> > >strip CRC bytes as old em(4) didn't strip it, probably to
> > >> > >workaround silicon bug of old em(4) controllers.
> > >> >
> > >> > Thanks! The attached patch does indeed fix the dhclient issue.
> > >> >
> > >> >
> > >> > >It seems there are also TX issues here. The system load is too high
> > >> > >and sometimes system is not responsive while TX is in progress.
> > >> > >Because I initiated TCP bulk transfers, TSO should reduce CPU load
> > >> > >a lot but it didn't so I guess it could also be related watchdog
> > >> > >timeouts you've seen. I'll see what can be done.
> > >> >
> > >> > Thanks for looking into that as well!!
> > >> >
> > >> > ---Mike
> > >> >
> > >>
> > >> Mike,
> > >>
> > >> Here is patch I'm working on. This patch fixes high system load and
> > >> system is very responsive as before. But it seems there is still
> > >> some TX issue here. Bulk UDP performance is very poor(< 700Mbps)
> > >> and I have no idea what caused this at this moment.
> > >>
> > >> BTW, I have trouble to reproduce watchdog timeouts. I'm not sure
> > >> whether latest fix from Jack cured it. By chance does your
> > >> controller support multi TX/RX queues? You can check whether em(4)
> > >> uses multi-queues with "vmstat -i". If em(4) use multi-queue you
> > >> may have multiple irq output for em0.
> > >>
> > >
> > > Hi,
> > > I will give it a try later tonight! This one does not seem to.
> > >
> > > 0(ich10)# vmstat -i
> > > interrupt total rate
> > > irq16: uhci0+ 30 0
> > > irq18: ehci0 uhci5 158419 17
> > > irq19: fwohci0++ 86 0
> > > irq21: uhci1 17 0
> > > irq23: uhci3 ehci1 2 0
> > > cpu0: timer 18570305 1994
> > > irq256: igb0 80 0
> > > irq257: igb0 255 0
> > > irq258: igb0 66 0
> > > irq259: igb0 32 0
> > > irq260: igb0 2 0
> > > irq261: igb1 2679 0
> > > irq262: igb1 998 0
> > > irq263: igb1 2468 0
> > > irq264: igb1 6361 0
> > > irq265: igb1 2 0
> > > irq266: em0 33910 3
> > > irq267: ahci1 15317 1
> > > cpu1: timer 18557074 1993
> > > cpu3: timer 18557168 1993
> > > cpu2: timer 18557108 1993
> > > Total 74462379 7998
> > > 0(ich10)#
> > >
>
------------------------------
Message: 10
Date: Thu, 8 Apr 2010 21:59:08 -0500
From: Adam Vande More <amvan...@gmail.com>
Subject: Re: Realtek Ethernet not functioning on Asus M4A89GTD PRO
To: Michael Beckmann <mic...@apfel.de>
Cc: sta...@freebsd.org
Message-ID:
<q2l6201873e1004081959sc...@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1
On Thu, Apr 8, 2010 at 6:50 PM, Michael Beckmann <mic...@apfel.de> wrote:
> re0: <RealTek
> 8168/8168B/8168C/8168CP/8168D/8168DP/8111B/8111C/8111CP/8111DP
> PCIe Gigabit Ethernet> port 0xe800-0xe8ff mem
> 0xfdfff000-0xfdffffff,0xfdff8000-0xfdffbfff irq 16 at device 0.0 on pci4
>
> re0: Using 1 MSI messages
>
> re0: Chip rev. 0x2c000000
>
> re0: MAC rev. 0x00000000
>
> re0: Unknown H/W revision: 0x2c000000
>
> device_attach: re0 attach returned 6
>
What's pciconf -lv say about it?
Mine is
re0@pci0:3:0:0: class=0x020000 card=0x75811462 chip=0x816810ec rev=0x03
hdr=0x00
vendor = 'Realtek Semiconductor'
device = 'Gigabit Ethernet NIC(NDIS 6.0) (RTL8168/8111)'
class = network
subclass = ethernet
FreeBSD 8.0-STABLE #0: Sun Apr 4 01:28:48 CDT 2010
ro...@galacticdominator.com:/usr/obj/usr/src/sys/GENERIC
Cards work fine here.
--
Adam Vande More
------------------------------
Message: 11
Date: Fri, 9 Apr 2010 12:12:12 +0900
From: Svyatoslav Lempert <svyatosla...@gmail.com>
Subject: please see the conf/141050
To: sta...@freebsd.org
Message-ID:
<x2v5e7b89821004082012u7...@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8
Hello!
Please check this report
http://www.freebsd.org/cgi/query-pr.cgi?pr=conf/141050
I use quota on the root partitions and without this patch we (my
hosting company) can't use quota on /
Thank you in advance for your time, if this PR is not your area,
please forward my message to commiters of this part.
--
Svyatoslav
------------------------------
Message: 12
Date: Fri, 9 Apr 2010 12:20:37 +0900
From: Svyatoslav Lempert <svyatosla...@gmail.com>
Subject: please see the conf/141050
To: freebsd...@freebsd.org
Message-ID:
<o2v5e7b89821004082020hd...@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8
Hello!
Please check this report
http://www.freebsd.org/cgi/query-pr.cgi?pr=conf/141050
I use quota on the root partitions and without this patch we (my
hosting company) can't use quota on /
Thank you in advance for your time, if this PR is not your area,
please forward my message to commiters of this part.
--
Svyatoslav
------------------------------
Message: 13
Date: Fri, 9 Apr 2010 02:30:30 -0700 (PDT)
From: Jakub Lach <jakub...@mailplus.pl>
Subject: Re: CPU problems after 8.0-STABLE update
To: freebsd...@freebsd.org
Message-ID: <281898...@talk.nabble.com>
Content-Type: text/plain; charset=us-ascii
Andriy Gapon wrote:
>
>
> Really shooting in the dark here: are there any BIOS options about HPET
> and RTC on
> this system? Can you try playing with them?
>
>
Hello. I have similar problem. Once in few boots performance would be
sluggish and
top would be at 0%. It started on 4th April I think. After today's update,
problem is persistent.
Currently, as I type letters are appearing with considerable delay.
I'm using HPET, 8-STABLE amd64 r206412
(Thinkpad T400)
best regards,
-Jakub Lach
--
View this message in context: http://old.nabble.com/CPU-problems-after-8.0-STABLE-update-tp28131503p28189840.html
Sent from the freebsd-stable mailing list archive at Nabble.com.
------------------------------
Message: 14
Date: Fri, 9 Apr 2010 12:10:16 +0200
From: "Michael Beckmann" <mic...@apfel.de>
Subject: RE: Realtek Ethernet not functioning on Asus M4A89GTD PRO
To: "'Adam Vande More'" <amvan...@gmail.com>
Cc: sta...@freebsd.org
Message-ID:
<!&!AAAAAAAAAAAYAAAAAAAAAFu8E7CkEvBMsgZ/8G4PwcPigAAAEAAAAMLmphfTPo9DrEiQKSuLtj8BAAAAAA==@apfel.de>
Content-Type: text/plain; charset="us-ascii"
>On Thu, Apr 8, 2010 at 6:50 PM, Michael Beckmann <mic...@apfel.de> wrote:
>
>> re0: <RealTek
>> 8168/8168B/8168C/8168CP/8168D/8168DP/8111B/8111C/8111CP/8111DP
>> PCIe Gigabit Ethernet> port 0xe800-0xe8ff mem
>> 0xfdfff000-0xfdffffff,0xfdff8000-0xfdffbfff irq 16 at device 0.0 on pci4
>>
>> re0: Using 1 MSI messages
>> re0: Chip rev. 0x2c000000
>> re0: MAC rev. 0x00000000
>> re0: Unknown H/W revision: 0x2c000000
>> device_attach: re0 attach returned 6
>>
>
>
>What's pciconf -lv say about it?
>
>Mine is
>
>re0@pci0:3:0:0: class=0x020000 card=0x75811462 chip=0x816810ec rev=0x03
>hdr=0x00
> vendor = 'Realtek Semiconductor'
> device = 'Gigabit Ethernet NIC(NDIS 6.0) (RTL8168/8111)'
> class = network
> subclass = ethernet
>
>FreeBSD 8.0-STABLE #0: Sun Apr 4 01:28:48 CDT 2010
>ro...@galacticdominator.com:/usr/obj/usr/src/sys/GENERIC
>
>Cards work fine here.
Here is the output of pciconf -lv :
re0@pci0:4:0:0: class=0x020000 card=0x84321043 chip=0x816810ec rev=0x06
hdr=0x00
vendor = 'Realtek Semiconductor'
device = 'Gigabit Ethernet NIC(NDIS 6.0) (RTL8168/8111)'
class = network
subclass = ethernet
So I have rev=0x06 and you have rev=0x03. The dmesg output says I have an
unknown H/W revision.
The mainboard is fairly new. So I guess I have to report a bug and wait for
a driver update?
Thanks,
Michael
------------------------------
End of freebsd-stable Digest, Vol 351, Issue 8
**********************************************