Skip to contentSkip to conversation

WARNING: CPU: 0 PID: 0 at net/sched/sch_generic.c:264 dev_watchdog+0x276/0x280()

DISCUSSION poma 2 participants 7 messages Feb 18, 2014 – Mar 8, 2014

Subsystems (3)
lore
Share & tools
lore

poma

author
#0 lore raw

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

author
#1 lore raw
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=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
Quoted 6 lines

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

_______________________________________________
kernel mailing list
[email protected]
https://admin.fedoraproject.org/mailman/listinfo/kernel

author
#3 lore raw
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=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

_______________________________________________
kernel mailing list
[email protected]
https://admin.fedoraproject.org/mailman/listinfo/kernel

author
#4 lore raw
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

#5 lore raw

([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

[1] https://bugzilla.kernel.org/attachment.cgi?id=125961

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
index 91a67ae..b5c7810 100644
@@ -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);
author
#6 lore raw

On 08.03.2014 13:35, Francois Romieu wrote:
...

Quoted 4 lines

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 mailing list
[email protected]
https://admin.fedoraproject.org/mailman/listinfo/kernel