Bug#609538: r8169: long delay during resume
Hi, I had the same delay issue when resuming, and fixed it as suggested: by installing firmware-realtek. However, the driver don't actually need these firmware to work with my hardware (RTL8111/8168B rev3), and the only issue without the firmware is this resume-time delay (~60s for me). So, as you might understand, I feel a bit sad to have to install such a proprietary piece of software that I actually don't need (I know, it's only firmware, but still)... So, would it be possible to fix this 60s delay? (actually, I wonder why the driver tries to do something with firmwares at resume time when it had none before, but I probably miss something ^^) Thanks, Colomban PS: BTW, if I should open another bug or whatever, please tell me :) -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4d642d2e.8050...@herbesfolles.org
Bug#609538: r8169: long delay during resume
On Thu, Jan 20, 2011 at 03:20:03AM +, Ben Hutchings wrote: On Thu, 2011-01-20 at 10:04 +0700, Daniel J Blueman wrote: I see that Francois' patch is present in 2.6.38-rc1; is there a way to avoid this delay, or is this likely in request_firmware? It's a known problem with calls to request_firmware() when userland is not running (early initialisation or resume from sleep). It may be fixable. It was partially fixed in commit f1e02ed109df5f99abf942b8ccc99960cb09dd38 in linux-2.6.git (r8169: keep firmware in memory.). Sorry for not reporting it here, I clicked reply instead of group reply late in the night. If this commit could be included in Debian kernel, the bug could be closed. J. -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110120135534.ga24...@rocket.almost.secure.la
Bug#609538: r8169: long delay during resume
When resuming from suspended with 2.6.38-rc1 with my RTL8168d/8111d hardware, I see significant delays [1]. The only firmware I see in /lib/firmware is RTL8192E, thus it looks like this is due to it being not present. I see that Francois' patch is present in 2.6.38-rc1; is there a way to avoid this delay, or is this likely in request_firmware? Thanks, Daniel --- [1] [21786.797521] sdhci-pci :09:00.0: Will use DMA mode even though HW doesn't fully claim to support it. [21786.797530] sdhci-pci :09:00.0: setting latency timer to 64 [21847.280237] r8169 :0b:00.0: eth0: unable to apply firmware patch [21847.283688] PM: resume of devices complete after 61090.398 msecs [21848.934980] Synaptics Touchpad, model: 1, fw: 7.2, id: 0x1c0b1, caps: 0xd04733/0xa4/0xa [21848.980306] input: SynPS/2 Synaptics TouchPad as /devices/platform/i8042/serio1/input/input12 [21850.886820] PM: Finishing wakeup. [21850.08] Restarting tasks ... done. [21851.384291] r8169 :0b:00.0: eth0: unable to apply firmware patch [21851.386090] r8169 :0b:00.0: eth0: link down [21853.324784] EXT4-fs (sda1): re-mounted. Opts: commit=0 -- Daniel J Blueman -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/AANLkTikxpOS2fJ1Sqv=lg6cx1te+1w-zxfv+ymoh1...@mail.gmail.com
Bug#609538: r8169: long delay during resume
On Thu, 2011-01-20 at 10:04 +0700, Daniel J Blueman wrote: When resuming from suspended with 2.6.38-rc1 with my RTL8168d/8111d hardware, I see significant delays [1]. The only firmware I see in /lib/firmware is RTL8192E, thus it looks like this is due to it being not present. If you're using Debian, the necessary blob is in the firmware-realtek package. I see that Francois' patch is present in 2.6.38-rc1; is there a way to avoid this delay, or is this likely in request_firmware? [...] It's a known problem with calls to request_firmware() when userland is not running (early initialisation or resume from sleep). It may be fixable. Ben. -- Ben Hutchings Once a job is fouled up, anything done to improve it makes it worse. signature.asc Description: This is a digitally signed message part
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-kernel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive:
http://lists.debian.org/2011032524.ga2...@electric-eye.fr.zoreil.com
Bug#609538: r8169: long delay during resume
W dniu 11.01.2011 14:25, Francois Romieu pisze: 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. This patch applied against current git tree fixes problem (with firmware installed). However, cherry-picking eee3a96c6368f47df8df5bd4ed1843600652b337 (r8169: delay phy init until device opens.) from net-2.6.git and applying r8169: keep firmware in memory. still results with #v+ Jan 11 19:05:18 rocket kernel: [ 673.176439] ata1.00: configured for UDMA/100 Jan 11 19:05:18 rocket kernel: [ 731.639054] r8169 :13:00.0: eth0: unable to apply firmware patch Jan 11 19:05:18 rocket kernel: [ 731.640486] PM: resume of devices complete after 60228.033 msecs #v- (I don't fully understand why) r8169: delay phy init until device opens. alone also doesn't do the trick. -- pozdr(); // Jarek -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4d2c9fa8.7010...@vilo.eu.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-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110111202817.ga2...@electric-eye.fr.zoreil.com
Bug#609538: r8169: long delay during resume
Package: linux-2.6 Version: 2.6.37-1~experimental.1 Severity: normal File: /lib/modules/2.6.37-trunk-amd64/kernel/drivers/net/r8169.ko Tags: upstream Hi. 2.6.37 introduces regression in r8169. During every resume I get ~20 seconds delay: Jan 10 13:57:15 rocket kernel: [36458.257780] ata1.00: configured for UDMA/100 Jan 10 13:57:15 rocket kernel: [36517.738421] r8169 :13:00.0: eth0: unable to apply firmware patch Jan 10 13:57:15 rocket kernel: [36517.739859] PM: resume of devices complete after 61177.644 msecs Jan 10 13:57:15 rocket kernel: [36517.740258] PM: Finishing wakeup. Jan 10 13:57:15 rocket kernel: [36517.740259] Restarting tasks ... done. Bisecting leads to commit bca03d5f32c8ee9b5cfa1d32640a63fded6cb3c0 (r8169: remove the firmware of RTL8111D.). Further debugging showed, that firmware.agent is not called at all, I guess that udev is not working before Restarting tasks. Either r8169 tries to load firmware too early, or it should keep it loaded in memory for use during resume. The problem persist no matter if I have firmware-realtek installed, or not. Cheers, Jarek. -- Package-specific info: ** Version: Linux version 2.6.37-trunk-amd64 (Debian 2.6.37-1~experimental.1) (b...@decadent.org.uk) (gcc version 4.4.5 (Debian 4.4.5-10) ) #1 SMP Thu Jan 6 16:00:31 UTC 2011 ** Command line: BOOT_IMAGE=/vmlinuz-2.6.37-trunk-amd64 root=/dev/mapper/vg0-root ro resume=/dev/mapper/vg0-swap0 rootfstype=ext4 splash ** Tainted: P (1) * Proprietary module has been loaded. ** Kernel log: [36519.156777] ata1: EH complete [36519.334872] ehci_hcd: USB 2.0 'Enhanced' Host Controller (EHCI) Driver [36519.334921] ehci_hcd :00:1a.0: PCI INT A - GSI 16 (level, low) - IRQ 16 [36519.334971] ehci_hcd :00:1a.0: setting latency timer to 64 [36519.334978] ehci_hcd :00:1a.0: EHCI Host Controller [36519.335024] ehci_hcd :00:1a.0: new USB bus registered, assigned bus number 1 [36519.347401] ehci_hcd :00:1a.0: debug port 2 [36519.351384] ehci_hcd :00:1a.0: cache line size of 64 is not supported [36519.351410] ehci_hcd :00:1a.0: irq 16, io mem 0xfbc08000 [36519.367269] ehci_hcd :00:1a.0: USB 2.0 started, EHCI 1.00 [36519.367308] usb usb1: New USB device found, idVendor=1d6b, idProduct=0002 [36519.367312] usb usb1: New USB device strings: Mfr=3, Product=2, SerialNumber=1 [36519.367317] usb usb1: Product: EHCI Host Controller [36519.367320] usb usb1: Manufacturer: Linux 2.6.37-trunk-amd64 ehci_hcd [36519.367324] usb usb1: SerialNumber: :00:1a.0 [36519.367544] hub 1-0:1.0: USB hub found [36519.367554] hub 1-0:1.0: 2 ports detected [36519.367720] ehci_hcd :00:1d.0: PCI INT A - GSI 23 (level, low) - IRQ 23 [36519.367796] ehci_hcd :00:1d.0: setting latency timer to 64 [36519.367803] ehci_hcd :00:1d.0: EHCI Host Controller [36519.367894] ehci_hcd :00:1d.0: new USB bus registered, assigned bus number 2 [36519.387275] ehci_hcd :00:1d.0: debug port 2 [36519.391258] ehci_hcd :00:1d.0: cache line size of 64 is not supported [36519.391359] ehci_hcd :00:1d.0: irq 23, io mem 0xfbc07000 [36519.407191] ehci_hcd :00:1d.0: USB 2.0 started, EHCI 1.00 [36519.407224] usb usb2: New USB device found, idVendor=1d6b, idProduct=0002 [36519.407227] usb usb2: New USB device strings: Mfr=3, Product=2, SerialNumber=1 [36519.407230] usb usb2: Product: EHCI Host Controller [36519.407232] usb usb2: Manufacturer: Linux 2.6.37-trunk-amd64 ehci_hcd [36519.407234] usb usb2: SerialNumber: :00:1d.0 [36519.407979] hub 2-0:1.0: USB hub found [36519.407987] hub 2-0:1.0: 2 ports detected [36519.422831] Linux video capture interface: v2.00 [36519.429307] usbcore: registered new interface driver uvcvideo [36519.429311] USB Video Class driver (v1.0.0) [36519.451382] r8169 :13:00.0: eth0: link down [36519.451795] ADDRCONF(NETDEV_UP): eth0: link is not ready [36519.678749] usb 1-1: new high speed USB device using ehci_hcd and address 2 [36519.811173] usb 1-1: New USB device found, idVendor=8087, idProduct=0020 [36519.811179] usb 1-1: New USB device strings: Mfr=0, Product=0, SerialNumber=0 [36519.811474] hub 1-1:1.0: USB hub found [36519.811669] hub 1-1:1.0: 6 ports detected [36519.922265] usb 2-1: new high speed USB device using ehci_hcd and address 2 [36520.054400] usb 2-1: New USB device found, idVendor=8087, idProduct=0020 [36520.054403] usb 2-1: New USB device strings: Mfr=0, Product=0, SerialNumber=0 [36520.054675] hub 2-1:1.0: USB hub found [36520.055146] hub 2-1:1.0: 8 ports detected [36520.126005] usb 1-1.1: new full speed USB device using ehci_hcd and address 3 [36520.219447] usb 1-1.1: New USB device found, idVendor=0a5c, idProduct=4500 [36520.219454] usb 1-1.1: New USB device strings: Mfr=1, Product=2, SerialNumber=0 [36520.219458] usb 1-1.1: Product: BCM2046B1 [36520.219462] usb 1-1.1: Manufacturer: Broadcom [36520.220297] hub 1-1.1:1.0: USB hub found [36520.220432] hub 1-1.1:1.0: 3 ports detected [36520.293675] usb 1-1.2: new high speed USB device using ehci_hcd and
Bug#609538: r8169: long delay during resume
On Mon, 2011-01-10 at 14:14 +0100, Jarek Kamiński wrote: Package: linux-2.6 Version: 2.6.37-1~experimental.1 Severity: normal File: /lib/modules/2.6.37-trunk-amd64/kernel/drivers/net/r8169.ko Tags: upstream Hi. 2.6.37 introduces regression in r8169. During every resume I get ~20 seconds delay: Jan 10 13:57:15 rocket kernel: [36458.257780] ata1.00: configured for UDMA/100 Jan 10 13:57:15 rocket kernel: [36517.738421] r8169 :13:00.0: eth0: unable to apply firmware patch Jan 10 13:57:15 rocket kernel: [36517.739859] PM: resume of devices complete after 61177.644 msecs Jan 10 13:57:15 rocket kernel: [36517.740258] PM: Finishing wakeup. Jan 10 13:57:15 rocket kernel: [36517.740259] Restarting tasks ... done. Bisecting leads to commit bca03d5f32c8ee9b5cfa1d32640a63fded6cb3c0 (r8169: remove the firmware of RTL8111D.). Further debugging showed, that firmware.agent is not called at all, I guess that udev is not working before Restarting tasks. Right, only the kernel is running then. Either r8169 tries to load firmware too early, or it should keep it loaded in memory for use during resume. It should. But an earlier version of this patch was also in Debian's 2.6.36 so it would have had the same problem. Ben. The problem persist no matter if I have firmware-realtek installed, or not. -- Ben Hutchings Once a job is fouled up, anything done to improve it makes it worse. signature.asc Description: This is a digitally signed message part
Bug#609538: r8169: long delay during resume
W dniu 11.01.2011 06:49, Ben Hutchings pisze: On Mon, 2011-01-10 at 14:14 +0100, Jarek Kamiński wrote: Package: linux-2.6 Version: 2.6.37-1~experimental.1 2.6.37 introduces regression in r8169. During every resume I get ~20 seconds delay: Jan 10 13:57:15 rocket kernel: [36458.257780] ata1.00: configured for UDMA/100 Jan 10 13:57:15 rocket kernel: [36517.738421] r8169 :13:00.0: eth0: unable to apply firmware patch Jan 10 13:57:15 rocket kernel: [36517.739859] PM: resume of devices complete after 61177.644 msecs Jan 10 13:57:15 rocket kernel: [36517.740258] PM: Finishing wakeup. Jan 10 13:57:15 rocket kernel: [36517.740259] Restarting tasks ... done. Bisecting leads to commit bca03d5f32c8ee9b5cfa1d32640a63fded6cb3c0 (r8169: remove the firmware of RTL8111D.). Either r8169 tries to load firmware too early, or it should keep it loaded in memory for use during resume. It should. But an earlier version of this patch was also in Debian's 2.6.36 so it would have had the same problem. 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. Sorry if my information was misleading. -- pozdr(); // Jarek -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4d2c06cf.4090...@vilo.eu.org
