Ahoy!
Debugging S3 aka suspend produces 'WARNINGS':
Steps to Reproduce: # echo core > /sys/power/pm_test # cat /sys/power/pm_test none [core] processors platform devices freezer # echo mem > /sys/power/state Results: - dmesg-3.14.0-0.rc3.git0.1.fc21.x86_64+debug-pm_test-core.diff https://bugzilla.redhat.com/attachment.cgi?id=864436
Steps to Reproduce: # echo processors > /sys/power/pm_test # cat /sys/power/pm_test none core [processors] platform devices freezer # echo mem > /sys/power/state Results: - dmesg-3.14.0-0.rc3.git0.1.fc21.x86_64+debug-pm_test-processors.diff https://bugzilla.redhat.com/attachment.cgi?id=864438
Steps to Reproduce: # echo platform > /sys/power/pm_test # cat /sys/power/pm_test none core processors [platform] devices freezer # echo mem > /sys/power/state Results: - dmesg-3.14.0-0.rc3.git0.1.fc21.x86_64+debug-pm_test-platform.diff https://bugzilla.redhat.com/attachment.cgi?id=864439
RHBZ 1010764: "[abrt] NETDEV WATCHDOG: em1 (e1000e): transmit queue 0 timed out" https://bugzilla.redhat.com/show_bug.cgi?id=1010764
Tested with Rawhide 'kernel-debug-3.14.0-0.rc3.git0.1.fc21.x86_64' http://koji.fedoraproject.org/koji/buildinfo?buildID=498711
poma
On 18.02.2014 11:15, poma wrote:
Ahoy!
Debugging S3 aka suspend produces 'WARNINGS':
Steps to Reproduce: # echo core > /sys/power/pm_test # cat /sys/power/pm_test none [core] processors platform devices freezer # echo mem > /sys/power/state Results:
- dmesg-3.14.0-0.rc3.git0.1.fc21.x86_64+debug-pm_test-core.diff https://bugzilla.redhat.com/attachment.cgi?id=864436
Steps to Reproduce: # echo processors > /sys/power/pm_test # cat /sys/power/pm_test none core [processors] platform devices freezer # echo mem > /sys/power/state Results:
- dmesg-3.14.0-0.rc3.git0.1.fc21.x86_64+debug-pm_test-processors.diff https://bugzilla.redhat.com/attachment.cgi?id=864438
Steps to Reproduce: # echo platform > /sys/power/pm_test # cat /sys/power/pm_test none core processors [platform] devices freezer # echo mem > /sys/power/state Results:
- dmesg-3.14.0-0.rc3.git0.1.fc21.x86_64+debug-pm_test-platform.diff https://bugzilla.redhat.com/attachment.cgi?id=864439
RHBZ 1010764: "[abrt] NETDEV WATCHDOG: em1 (e1000e): transmit queue 0 timed out" https://bugzilla.redhat.com/show_bug.cgi?id=1010764
Tested with Rawhide 'kernel-debug-3.14.0-0.rc3.git0.1.fc21.x86_64' http://koji.fedoraproject.org/koji/buildinfo?buildID=498711
A comparison of 'RealTek RTL-8169 GE' & 'SysKonnect GE'
Debugging S3 - core: # echo core > /sys/power/pm_test # echo mem > /sys/power/state RTL8169: - dmesg-3.14.0-0.rc3.git2.1.fc21.x86_64-r8169-pm_test-core.diff https://bugzilla.redhat.com/attachment.cgi?id=864959 SKGE: - dmesg-3.14.0-0.rc3.git2.1.fc21.x86_64-skge-pm_test-core.diff https://bugzilla.redhat.com/attachment.cgi?id=864960
Debugging S3 - processors: # echo processors > /sys/power/pm_test # echo mem > /sys/power/state RTL8169: - dmesg-3.14.0-0.rc3.git2.1.fc21.x86_64-r8169-pm_test-processors.diff https://bugzilla.redhat.com/attachment.cgi?id=864961 SKGE: - dmesg-3.14.0-0.rc3.git2.1.fc21.x86_64-skge-pm_test-processors.diff https://bugzilla.redhat.com/attachment.cgi?id=864962
Debugging S3 - platform: # echo platform > /sys/power/pm_test # echo mem > /sys/power/state RTL8169: - dmesg-3.14.0-0.rc3.git2.1.fc21.x86_64-r8169-pm_test-platform.diff https://bugzilla.redhat.com/attachment.cgi?id=864963 SKGE: - dmesg-3.14.0-0.rc3.git2.1.fc21.x86_64-skge-pm_test-platform.diff https://bugzilla.redhat.com/attachment.cgi?id=864964
RHBZ https://bugzilla.redhat.com/show_bug.cgi?id=1010764
Tested with Rawhide ' kernel-3.14.0-0.rc3.git2.1.fc21.x86_64' http://koji.fedoraproject.org/koji/buildinfo?buildID=499061
poma
... After a few dozen tests with the vanilla commits, and with the same amount of rawhide kernels ... https://bugzilla.redhat.com/attachment.cgi?id=871694
Dan, Francois you are both welcome with comments! Thanks.
poma
On 07.03.2014 00:32, poma wrote:
... After a few dozen tests with the vanilla commits, and with the same amount of rawhide kernels ... https://bugzilla.redhat.com/attachment.cgi?id=871694
Dan, Francois you are both welcome with comments! Thanks.
Thomas U2. :)
No barking w-dog, but now the network traffic is totally busted! https://bugzilla.redhat.com/attachment.cgi?id=871947 "ping: sendmsg: No buffer space available ..."
poma
On 07.03.2014 17:30, poma wrote:
On 07.03.2014 00:32, poma wrote:
... After a few dozen tests with the vanilla commits, and with the same amount of rawhide kernels ... https://bugzilla.redhat.com/attachment.cgi?id=871694
Dan, Francois you are both welcome with comments! Thanks.
Thomas U2. :)
No barking w-dog, but now the network traffic is totally busted! https://bugzilla.redhat.com/attachment.cgi?id=871947 "ping: sendmsg: No buffer space available ..."
Francois, do you have this[1] patch applicable for the recent 'r8169.c'?
$ patch -p5 < r8169-xmit.patch patching file r8169.c Hunk #1 FAILED at 5870. Hunk #2 succeeded at 5540 with fuzz 2 (offset -482 lines). Hunk #3 succeeded at 5641 (offset -494 lines). 1 out of 3 hunks FAILED -- saving rejects to file r8169.c.rej
poma
[1] https://bugzilla.kernel.org/attachment.cgi?id=125961 https://bugzilla.kernel.org/show_bug.cgi?id=14962#c37
(linux.nics@intel.com removed from the Cc: list)
poma pomidorabelisima@gmail.com : [...]
Francois, do you have this[1] patch applicable for the recent 'r8169.c'?
$ patch -p5 < r8169-xmit.patch patching file r8169.c Hunk #1 FAILED at 5870. Hunk #2 succeeded at 5540 with fuzz 2 (offset -482 lines). Hunk #3 succeeded at 5641 (offset -494 lines). 1 out of 3 hunks FAILED -- saving rejects to file r8169.c.rej
[...]
It applies fine against b01d4e68933ec23e43b1046fa35d593cefcf37d1 but a bug hides behind the 'start' variable. You may replace it with the patch below. The "netif_info(..., "frags ..." debug statement is noisy when enabled. Don't use it.
diff --git a/drivers/net/ethernet/realtek/r8169.c b/drivers/net/ethernet/realtek/r8169.c index 91a67ae..b5c7810 100644 --- a/drivers/net/ethernet/realtek/r8169.c +++ b/drivers/net/ethernet/realtek/r8169.c @@ -5811,7 +5811,7 @@ static void rtl8169_unmap_tx_skb(struct device *d, struct ring_info *tx_skb,
dma_unmap_single(d, le64_to_cpu(desc->addr), len, DMA_TO_DEVICE);
- desc->opts1 = 0x00; + desc->opts1 &= cpu_to_le32(RingEnd); desc->opts2 = 0x00; desc->addr = 0x00; tx_skb->len = 0; @@ -5870,10 +5870,42 @@ static void rtl_reset_work(struct rtl8169_private *tp) rtl8169_check_link_status(dev, tp, tp->mmio_addr); }
+static void rtl_desc_trace(struct rtl8169_private *tp, int start, u32 *data) +{ + netif_info(tp, drv, tp->dev, + "%02x: %08x %08x %08x %08x %08x %08x %08x %08x\n", + start, + data[ 0], data[ 4], data[ 8], data[12], + data[16], data[20], data[24], data[28]); +} + +static void rtl_tx_ring_trace(struct rtl8169_private *tp) +{ + int i, start = 0; + + netif_info(tp, drv, tp->dev, + "Tx dirty: %08x (%02x), Tx current: %08x (%02x)\n", + tp->dirty_tx, tp->dirty_tx % NUM_TX_DESC, + tp->cur_tx, tp->cur_tx % NUM_TX_DESC); + + for (i = 0; i < NUM_TX_DESC / 8; i++) { + u32 *data = &tp->TxDescArray[start].opts1; + int j; + + for (j = 0; j < 4; j++) + rtl_desc_trace(tp, start, data++); + netif_info(tp, drv, tp->dev, "\n"); + + start += 8; + } +} + static void rtl8169_tx_timeout(struct net_device *dev) { struct rtl8169_private *tp = netdev_priv(dev);
+ rtl_tx_ring_trace(tp); + rtl_schedule_task(tp, RTL_FLAG_TASK_RESET_PENDING); }
@@ -6009,6 +6041,7 @@ static netdev_tx_t rtl8169_start_xmit(struct sk_buff *skb, txd->addr = cpu_to_le64(mapping);
frags = rtl8169_xmit_frags(tp, skb, opts); + // netif_info(tp, drv, tp->dev, "frags: %d\n", frags); if (frags < 0) goto err_dma_1; else if (frags) @@ -6022,14 +6055,14 @@ static netdev_tx_t rtl8169_start_xmit(struct sk_buff *skb,
skb_tx_timestamp(skb);
- wmb(); + tp->cur_tx += frags + 1; + + smp_wmb();
/* Anti gcc 2.95.3 bugware (sic) */ status = opts[0] | len | (RingEnd * !((entry + 1) % NUM_TX_DESC)); txd->opts1 = cpu_to_le32(status);
- tp->cur_tx += frags + 1; - wmb();
RTL_W8(TxPoll, NPQ); @@ -6135,6 +6168,11 @@ static void rtl_tx(struct net_device *dev, struct rtl8169_private *tp) if (status & DescOwn) break;
+ if (!status) { + netif_info(tp, tx_done, dev, "Tx miss: %03d\n", entry); + break; + } + rtl8169_unmap_tx_skb(&tp->pci_dev->dev, tx_skb, tp->TxDescArray + entry); if (status & LastFrag) { @@ -6552,6 +6590,8 @@ static int rtl_open(struct net_device *dev)
rtl_hw_start(dev);
+ rtl_tx_ring_trace(tp); + netif_start_queue(dev);
rtl_unlock_work(tp);
On 08.03.2014 13:35, Francois Romieu wrote: ...
It applies fine against b01d4e68933ec23e43b1046fa35d593cefcf37d1 but a bug hides behind the 'start' variable. You may replace it with the patch below. The "netif_info(..., "frags ..." debug statement is noisy when enabled. Don't use it.
...
You're right! Thanks.
These are the results with your patch:
- RTL8110s RTL-8169 S3 TEST & r8169-RTL8110s-xmit-v2.patch https://bugzilla.redhat.com/attachment.cgi?id=872287
- r8169 RTL8110s pacchetto https://bugzilla.redhat.com/attachment.cgi?id=872299 https://bugzilla.redhat.com/attachment.cgi?id=872299&action=diff
poma
kernel@lists.fedoraproject.org