Most recent kernel where this bug did not occur: 2.6.16-rc1-mm2 Distribution: Gentoo Linux 2005.1 Hardware Environment: ADM64 + Yukon Gigabit Ethernet + RTL8169 Gigabit Ethernet Software Environment: Linux (console or X) Problem Description: My RTL8169 network interface seems to display 'Losing some ticks...checking if CPU frequency changed' in dmesg when the link is down. When the link is up, no losing ticks messages is saved in dmesg. To be more precise, my Yukon network interface is for Internet and my RTL8169 is for fast LAN. Steps to reproduce: compile kernels with skge and r8169 drivers in kernel and without linux kernel modules system activated. In my network setup, ips broadcast and networks are different. My network configuration has been tested on Windows XP without any problems.
Sorry, but in the 2.6.16-rc1-mm2 kernel, the bug is still present.
Created attachment 7113 [details] kernel config file for 2.6.16-rc1-mm2 compilation
I suppose that r8169 is disabling interrupts for too long when the link is down.
Created attachment 7114 [details] lspci from my computer
Created attachment 7117 [details] /proc/interrupts before eth1 is start
Created attachment 7118 [details] /proc/interrupts after eth1 started
Created attachment 7125 [details] lower the maximum time spent polling the MII registers > I suppose that r8169 is disabling interrupts for too long when the > link is down. Possible workaround attached. I'll check the 802.3 spec for the upper bound but this stuff should be moved to a workqueue context anyway. -- Ueimor
If mdio_read/write are actually causing loss of ticks, either they really are timing out, or they're taking unexpectedly long. If the latter is true, this patch could cause the driver to malfunction, couldn't it?
Created attachment 7127 [details] dmesg from 2.6.15.1 with r8169 patch I try the patch posted above but nothing new. Always losing ticks message.
akpm: [...] > If the latter is true, this patch could cause the driver to malfunction, > couldn't it? Yes but the link is supposed to be down when the issue happens. Anyway it is apparently not the usual suspect. Olivier, can you give a simple try with NAPI enabled (just wondering) ? -- Ueimor
Created attachment 7140 [details] dmesg from 2.6.15.1 with r8169 napi Same message with napi activated at compilation time. If r8169 (module or kernel built-in) is not present on .config settings compilation file, Losing ticks does not appear in dmesg.
Created attachment 7143 [details] shorten the time spent polling the mii registers Olivier: [...] > If r8169 (module or kernel built-in) is not present on .config settings > compilation file, Losing ticks does not appear in dmesg. Ok but look closer at http://bugzilla.kernel.org/show_bug.cgi?id=5947: [...] > SCSI device sda: 312581808 512-byte hdwr sectors (160042 MB) > SCSI device sda: drive cache: write back > SCSI device sda: 312581808 512-byte hdwr sectors (160042 MB) > Losing some ticks... checking if CPU frequency changed. > SCSI device sda: drive cache: write back -> The r8169 module was not loaded at this time (it appears later in the dmesg). Something else hurts latency as well. The patch should fix whatever excess delay is due to the r8169 driver. It will not spend more than 0.5 ms with irq disabled. -- Ueimor
Created attachment 7148 [details] 2.6.15.1 dmesg with r8169 patch2 It seems that the message Losing ticks .. is gone. Thank you.
I am going test this kernel with this patch a few days to be sure.
Your patch seems to work well today. Thank you again.
Merged: http://www.kernel.org/git/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=2371408c021f961b92fd2c42480cfddc9c6254f0 -- Ueimor