Bug#609538: r8169: long delay during resume

2011-01-10 Thread Jarek Kamiński 
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 an

Bug#609538: r8169: long delay during resume

2011-01-10 Thread Jarek Kamiński 
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

Bug#609538: r8169: long delay during resume

2011-01-11 Thread Jarek Kamiński 
W dniu 11.01.2011 14:25, Francois Romieu pisze:
> Jarek Kamiński  :
> [...]
>> 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-netdev&m=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

2011-01-20 Thread Jarek Kamiński 
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#536183: Can't change CPU scaling governor after .29 to .30 upgrade.

2009-08-03 Thread Jarek Kamiński 
On Wed, Jul 08, 2009 at 12:16:58PM +1000, Trent W. Buck wrote:

Hi Trent.

> After upgrading from .29 to .30, I can no longer change my CPU
> frequency scaling governor:
> 
> # cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_available_governors
> ondemand performance
> # printf ondemand >/sys/devices/system/cpu/cpu0/cpufreq/scaling_governor
> # cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor
> performance
> 
> This is super annoying.  I am using an EeePC 701 with a Celeron CPU.
> 
> ** Kernel log:
> [   73.276680] ondemand governor failed, too long transition latency of HW, 
> fallback to performance governor
> [  158.079576] ondemand governor failed, too long transition latency of HW, 
> fallback to performance governor
> [ 2192.786164] ondemand governor failed, too long transition latency of HW, 
> fallback to performance governor
> [ 2235.556866] ondemand governor failed, too long transition latency of HW, 
> fallback to performance governor
> 
> ** Loaded modules:
> Module  Size  Used by
> p4_clockmod 3948  0 
> speedstep_lib   4136  1 p4_clockmod

I'm also hit by this bug. I've found some information at
:
| You should not use ondemand with clockmod. The clockmod module has
| a very high switching latency, that's why it's disabled in 2.6.30. The
| error message says it all I think.

Unfortunately p4-clockmod is the only driver working with my CPU
(Intel(R) Celeron(R) CPU 2.60GHz), but You have newer CPU, so maybe it's
worth trying other drivers.

Of course I see it as a regression, it would be nice, if it gets
fixed...

Jarek.


signature.asc
Description: Digital signature