WARNING: CPU: 0 PID: 0 at net/sched/sch_generic.c:264 dev_watchdog+0x276/0x280()
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
_______________________________________________
kernel mailing list
[email protected]
https://admin.fedoraproject.org/mailman/listinfo/kernel
Quoted 32 lines · poma
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=864436Steps 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=864438Steps 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
Quoted 6 lines
RHBZ 1010764:
"[abrt] NETDEV WATCHDOG: em1 (e1000e): transmit queue 0 timed out"
https://bugzilla.redhat.com/show_bug.cgi?id=1010764Tested 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
_______________________________________________
kernel mailing list
[email protected]
https://admin.fedoraproject.org/mailman/listinfo/kernel
...
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
_______________________________________________
kernel mailing list
[email protected]
https://admin.fedoraproject.org/mailman/listinfo/kernel
Quoted 7 lines · 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=871694Dan, 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
_______________________________________________
kernel mailing list
[email protected]
https://admin.fedoraproject.org/mailman/listinfo/kernel
Quoted 6 lines · poma
Quoted 5 lines · 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
Quoted 8 lines
Quoted 2 lines
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
_______________________________________________
kernel mailing list
[email protected]
https://admin.fedoraproject.org/mailman/listinfo/kernel
([email protected] removed from the Cc: list)
poma <[email protected]> :
[...]
Quoted 8 lines
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
[...]
Quoted 1 line
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.
drivers/net/ethernet/realtek/r8169.c +44 -4
@@ -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:
...
Quoted 4 lines
It applies fine against
b01d4e68933ec23e43b1046fa35d593cefcf37d1but 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 mailing list
[email protected]
https://admin.fedoraproject.org/mailman/listinfo/kernel