Bug#642911: TX watchdog timeout on RTL8168B
Jonathan Nieder jrnie...@gmail.com : [...] - Is the PCI commit after writing to IntrStatus needed in the context of 3.0.y which does not have 92fc43b4159b (r8169: modify the flow of the hw reset) but does call irq_mask_and_ack from time to time without a PCI commit immediately afterward? What symptoms does it address? MMIO writes are posted. One can only say that the write will be committed somewhere between the time it is requested and the next MMIO read for this register range. - Does init_one need the same don't ack uninteresting events change (0x - tp-intr_event)? No. Init is different. It happens once and the driver is only in control afterwards. - Am I understanding correctly that patch 3/4 (remove now-redundant case statements) is a code cleanup / no-op? Yes. -- Ueimor -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#642911: TX watchdog timeout on RTL8168B
Jonathan Nieder jrnie...@gmail.com : [...] From: Jonathan Nieder jrnie...@gmail.com Subject: r8169: use event mask when disabling interrupts [ Extracted from commit 811fd3010cf512f2e23e6c4c912aad54516dc706 upstream, which was written by François Romieu. ] Not sure what this one is about, to be honest. It's part of the no processing policy: the driver only acks what it cares about. -- Ueimor -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#656331: RTL8168b/8111b with ASUS M2A-VM (SB600): Network device stays down after resume
Paul Menzel pm.deb...@googlemail.com :
[forget runtime PM]
[18764.958557] r8169 :02:00.0: PME# disabled
[18781.998004] r8169 :02:00.0: eth0: link down
^^
[18781.998024] r8169 :02:00.0: eth0: link down
^^
Two link events within 20 us. /me wonders...
The datasheet states [the PHYStatus] register is updated continuously at
maximum periods of 300us. but it is far from clear that the coherency
with the interrupt status register can be taken for granted. Hayes ?
Paul, can you try the hack below ?
diff --git a/drivers/net/ethernet/realtek/r8169.c
b/drivers/net/ethernet/realtek/r8169.c
index 7a0c800..6daca05 100644
--- a/drivers/net/ethernet/realtek/r8169.c
+++ b/drivers/net/ethernet/realtek/r8169.c
@@ -1278,6 +1278,7 @@ static void __rtl8169_check_link_status(struct net_device
*dev,
{
unsigned long flags;
+ udelay(500);
spin_lock_irqsave(tp-lock, flags);
if (tp-link_ok(ioaddr)) {
rtl_link_chg_patch(tp);
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#656331: RTL8168b/8111b with ASUS M2A-VM (SB600): Network device stays down after resume
Paul Menzel pm.deb...@googlemail.com : [http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=656331] I experienced this problem (only) three times until now. If I remember correctly the last time with 3.2.1. I still do not know how to reproduce this. (good PR, nice) An 'ethtool -d' and a 'mii-tool -v' of the device after a successful resume and a failed one could help if it's a driver thing. You may check if runtime power management is enabled or not, especially after a failed resume. See the /sys/devices/pci:../:..:/power directory and its control, runtime_enabled and runtime_status files (control = on - runtime PM disabled, see Documentation/power/runtime_pm.txt) If it is enabled and the link does not come up fast enough (5 s), runtime PM will suspend the device. It should not matter as long as the link is still present because the device should (TM) soon generate a power management event. The latter not happening or the PME being ignored could explain the bug. If so, temporarily disabling runtime PM for your device after a failed resume instead of removing the module or the cable may be enough to recover the link. It's just a guess though. Please stay with v3.2 or above in the meantime. -- Ueimor -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#609538: r8169: long delay during resume
Jarek Kamiński ja...@vilo.eu.org :
[...]
The last 2.6.36 I've tried was 2.6.36-1~experimental.1, I've then
passsed and returned to 2.6.32 for unrelated problems. I think it wasn't
affected, but I can re-check it and/or test later 2.6.36 versions if it
may help.
The patch below against 2.6.37-git + davem's pending fixes (see
http://marc.info/?l=linux-netdevm=129448910825754) should help.
Can you give it a try ?
r8169: keep firmware in memory.
The firmware agent is not available during resume.
It will help with http://bugs.debian.org/609538 but it will not avoid
the 60 seconds delay when there is no firmware.
Signed-off-by: Francois Romieu rom...@fr.zoreil.com
Cc: Hayes hayesw...@realtek.com
Cc: Ben Hutchings b...@debian.org
---
drivers/net/r8169.c | 43 +++
1 files changed, 31 insertions(+), 12 deletions(-)
diff --git a/drivers/net/r8169.c b/drivers/net/r8169.c
index dd758cd..7e2f01c 100644
--- a/drivers/net/r8169.c
+++ b/drivers/net/r8169.c
@@ -554,6 +554,8 @@ struct rtl8169_private {
struct mii_if_info mii;
struct rtl8169_counters counters;
u32 saved_wolopts;
+
+ const struct firmware *fw;
};
MODULE_AUTHOR(Realtek and the Linux r8169 crew net...@vger.kernel.org);
@@ -1668,6 +1670,29 @@ rtl_phy_write_fw(struct rtl8169_private *tp, const
struct firmware *fw)
}
}
+static void rtl_release_firmware(struct rtl8169_private *tp)
+{
+ release_firmware(tp-fw);
+ tp-fw = NULL;
+}
+
+static int rtl_apply_firmware(struct rtl8169_private *tp, const char *fw_name)
+{
+ const struct firmware **fw = tp-fw;
+ int rc = !*fw;
+
+ if (rc) {
+ rc = request_firmware(fw, fw_name, tp-pci_dev-dev);
+ if (rc 0)
+ goto out;
+ }
+
+ /* TODO: release firmware once rtl_phy_write_fw signals failures. */
+ rtl_phy_write_fw(tp, *fw);
+out:
+ return rc;
+}
+
static void rtl8169s_hw_phy_config(struct rtl8169_private *tp)
{
static const struct phy_reg phy_reg_init[] = {
@@ -2041,7 +2066,6 @@ static void rtl8168d_1_hw_phy_config(struct
rtl8169_private *tp)
{ 0x0d, 0xf880 }
};
void __iomem *ioaddr = tp-mmio_addr;
- const struct firmware *fw;
rtl_writephy_batch(tp, phy_reg_init_0, ARRAY_SIZE(phy_reg_init_0));
@@ -2105,11 +2129,8 @@ static void rtl8168d_1_hw_phy_config(struct
rtl8169_private *tp)
rtl_writephy(tp, 0x1f, 0x0005);
rtl_writephy(tp, 0x05, 0x001b);
- if (rtl_readphy(tp, 0x06) == 0xbf00
- request_firmware(fw, FIRMWARE_8168D_1, tp-pci_dev-dev) == 0) {
- rtl_phy_write_fw(tp, fw);
- release_firmware(fw);
- } else {
+ if ((rtl_readphy(tp, 0x06) != 0xbf00) ||
+ (rtl_apply_firmware(tp, FIRMWARE_8168D_1) 0)) {
netif_warn(tp, probe, tp-dev, unable to apply firmware
patch\n);
}
@@ -2159,7 +2180,6 @@ static void rtl8168d_2_hw_phy_config(struct
rtl8169_private *tp)
{ 0x0d, 0xf880 }
};
void __iomem *ioaddr = tp-mmio_addr;
- const struct firmware *fw;
rtl_writephy_batch(tp, phy_reg_init_0, ARRAY_SIZE(phy_reg_init_0));
@@ -2214,11 +2234,8 @@ static void rtl8168d_2_hw_phy_config(struct
rtl8169_private *tp)
rtl_writephy(tp, 0x1f, 0x0005);
rtl_writephy(tp, 0x05, 0x001b);
- if (rtl_readphy(tp, 0x06) == 0xb300
- request_firmware(fw, FIRMWARE_8168D_2, tp-pci_dev-dev) == 0) {
- rtl_phy_write_fw(tp, fw);
- release_firmware(fw);
- } else {
+ if ((rtl_readphy(tp, 0x06) != 0xb300) ||
+ (rtl_apply_firmware(tp, FIRMWARE_8168D_2) 0)) {
netif_warn(tp, probe, tp-dev, unable to apply firmware
patch\n);
}
@@ -4662,6 +4679,8 @@ static int rtl8169_close(struct net_device *dev)
tp-TxDescArray = NULL;
tp-RxDescArray = NULL;
+ rtl_release_firmware(tp);
+
pm_runtime_put_sync(pdev-dev);
return 0;
--
1.7.3.4
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#609538: r8169: long delay during resume
Jarek Kamiński ja...@vilo.eu.org : [failure] /me slaps head Please check that it works if you add the patch below and I'll merge both for a proper submission. r8169: I am a clown. Modifying rtl8169_reset_task() to tolerate firmware changes between close() and open() but this is not high-priority. Signed-off-by: Francois Romieu rom...@fr.zoreil.com diff --git a/drivers/net/r8169.c b/drivers/net/r8169.c index 7e2f01c..57fa6bd 100644 --- a/drivers/net/r8169.c +++ b/drivers/net/r8169.c @@ -3119,6 +3119,8 @@ static void __devexit rtl8169_remove_one(struct pci_dev *pdev) cancel_delayed_work_sync(tp-task); + rtl_release_firmware(tp); + unregister_netdev(dev); if (pci_dev_run_wake(pdev)) @@ -4679,8 +4681,6 @@ static int rtl8169_close(struct net_device *dev) tp-TxDescArray = NULL; tp-RxDescArray = NULL; - rtl_release_firmware(tp); - pm_runtime_put_sync(pdev-dev); return 0; r8169: delay phy init until device opens. alone also doesn't do the trick. It was the expected behavior. -- Ueimor -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#564628: [PATCH] net/r8169: Correct the ram code for RTL8111D(L)
Ben Hutchings b...@debian.org : On Fri, 2010-11-26 at 19:54 +0800, Hayes Wang wrote: Correct the binary code (Low pass filter DLY_CAP fine tune from uC). The incorrect ram code would make the nic working abnormally. [...] I'm glad you finally acknowledge that this is code rather than simple register initialisation. I am not sure that Hayes is a native english speaker. I am glad to see him posting here. [...] Below are the changes Debian currently applies in preparation for proper licencing of the firmware. Do you have some scripts to convert the data at hand ? I would welcome a clear statement regarding the status of the binary thing (code ? data ?) but even without one *now*, I'd like to see it separated from the main code : the driver sucks and things will go worse with support code for the 8168e. Is there anybody objecting to it ? I will buy anything be it firmware API or plain .h. -- Ueimor -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#595265: linux-image-2.6.32-5-686: Nerwork card fails to come up again after suspend
Ben Hutchings b...@decadent.org.uk : [...] Arnout Boelens reported that his RTL8111/8168B fails to link-up after suspend and resume, both under Debian's kernel based on 2.6.32 and under 2.6.36-rc6. Full details are at http://bugs.debian.org/595265, though the log isn't very informative: [31837.396594] PM: Finishing wakeup. [31837.396597] Restarting tasks ... done. [31840.267267] r8169: eth0: link down Can you suggest how to investigate this further? Something like the patch made by Stanislaw at : https://bugzilla.redhat.com/show_bug.cgi?id=502974 -- Ueimor -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#595265: linux-image-2.6.32-5-686: Nerwork card fails to come up again after suspend
Eric Dumazet eric.duma...@gmail.com :
Le lundi 18 octobre 2010 à 23:45 +0200, Francois Romieu a écrit :
[...]
Something like the patch made by Stanislaw at :
https://bugzilla.redhat.com/show_bug.cgi?id=502974
Seems to be down at this moment, patch is also here (and included in
2.6.36-rc8 ) :
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=aeb19f6052b5e5c8a24aa444fbff73b84341beac
It's from the same author but it is not included in 2.6.36-stg yet :
Subject: [PATCH] r8169 init phy when resume
For unknown reasons some r8169 devices after resume operate at
100 Mb/s speed instead of 1000 Mb/s like before suspend. To fix
reset phy during resume.
Signed-off-by: Stanislaw Gruszka sgrus...@redhat.com
---
drivers/net/r8169.c |3 +++
1 files changed, 3 insertions(+), 0 deletions(-)
diff --git a/drivers/net/r8169.c b/drivers/net/r8169.c
index 17382c3..a4ce127 100644
--- a/drivers/net/r8169.c
+++ b/drivers/net/r8169.c
@@ -4847,6 +4847,9 @@ static int rtl8169_resume(struct device *device)
{
struct pci_dev *pdev = to_pci_dev(device);
struct net_device *dev = pci_get_drvdata(pdev);
+ struct rtl8169_private *tp = netdev_priv(dev);
+
+ rtl8169_init_phy(dev, tp);
if (!netif_running(dev))
goto out;
--
1.7.1
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#407217: not just on thecus devices...
Martin Michlmayr t...@cyrius.com : Copying Francois Romieu: Thanks. You are welcome. * David Monro dav...@davidmonro.net [2008-12-13 01:00]: I seem to have exactly the same issue on a normal PC [...] I'm not sure if Francois Romieu has made any progress with this. No. I guess that it makes no difference if your kernel is x86_64 or not ? -- Ueimor -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#407217: r8169: Thecus N2100, multicast packets problem
Martin Michlmayr [EMAIL PROTECTED] : [...] Did you see the bug report below ? Yes. I have not had time to investigate it yet. -- Ueimor -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
