Bug 5947
| Summary: | r8169 Losing some ticks | ||
|---|---|---|---|
| Product: | Drivers | Reporter: | Olivier Mondoloni (elgrande71) |
| Component: | Network | Assignee: | Francois Romieu (romieu) |
| Status: | CLOSED CODE_FIX | ||
| Severity: | normal | CC: | akpm, romieu |
| Priority: | P2 | ||
| Hardware: | i386 | ||
| OS: | Linux | ||
| Kernel Version: | 2.6.15.1, 2.6.16-rc1, 2.6.16-rc1-mm2 | Subsystem: | |
| Regression: | --- | Bisected commit-id: | |
| Attachments: |
kernel config file for 2.6.16-rc1-mm2 compilation
lspci from my computer /proc/interrupts before eth1 is start /proc/interrupts after eth1 started lower the maximum time spent polling the MII registers dmesg from 2.6.15.1 with r8169 patch dmesg from 2.6.15.1 with r8169 napi shorten the time spent polling the mii registers 2.6.15.1 dmesg with r8169 patch2 |
||
|
Description
Olivier Mondoloni
2006-01-24 01:16:05 UTC
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. |