Take the 2-minute tour ×
Unix & Linux Stack Exchange is a question and answer site for users of Linux, FreeBSD and other Un*x-like operating systems.. It's 100% free, no registration required.

I built a linux distribution using the Yocto Project, with little customization. It runs on a Single Board Computer.

When I ping this machine, I get the following result:

PING 10.128.11.1 (10.128.11.1) 56(84) bytes of data.
64 bytes from 10.128.11.1: icmp_req=1 ttl=64 time=11.6 ms
64 bytes from 10.128.11.1: icmp_req=2 ttl=64 time=9.79 ms
64 bytes from 10.128.11.1: icmp_req=3 ttl=64 time=7.76 ms
64 bytes from 10.128.11.1: icmp_req=4 ttl=64 time=5.78 ms
64 bytes from 10.128.11.1: icmp_req=5 ttl=64 time=3.75 ms
64 bytes from 10.128.11.1: icmp_req=6 ttl=64 time=1.80 ms
64 bytes from 10.128.11.1: icmp_req=7 ttl=64 time=99.7 ms
64 bytes from 10.128.11.1: icmp_req=8 ttl=64 time=97.8 ms
64 bytes from 10.128.11.1: icmp_req=9 ttl=64 time=95.8 ms
64 bytes from 10.128.11.1: icmp_req=10 ttl=64 time=93.8 ms
64 bytes from 10.128.11.1: icmp_req=11 ttl=64 time=91.8 ms
64 bytes from 10.128.11.1: icmp_req=12 ttl=64 time=89.8 ms
64 bytes from 10.128.11.1: icmp_req=13 ttl=64 time=87.8 ms
-- snip --
64 bytes from 10.128.11.1: icmp_req=52 ttl=64 time=15.7 ms
64 bytes from 10.128.11.1: icmp_req=53 ttl=64 time=13.7 ms
64 bytes from 10.128.11.1: icmp_req=54 ttl=64 time=11.7 ms
64 bytes from 10.128.11.1: icmp_req=55 ttl=64 time=9.77 ms
64 bytes from 10.128.11.1: icmp_req=56 ttl=64 time=7.78 ms
64 bytes from 10.128.11.1: icmp_req=57 ttl=64 time=5.75 ms
64 bytes from 10.128.11.1: icmp_req=58 ttl=64 time=3.78 ms
64 bytes from 10.128.11.1: icmp_req=59 ttl=64 time=1.76 ms
64 bytes from 10.128.11.1: icmp_req=60 ttl=64 time=99.7 ms

The value keeps decreasing by 2 ms for each packet, then it goes up to 100 ms, and decreases by 2ms again.

When I configure the interface, I get strange errors (but the interface works):

[   65.404850] irq 15: nobody cared (try booting with the "irqpoll" option)
[   65.404957] Pid: 661, comm: ifconfig Not tainted 3.8.1-yocto-standard #2
[   65.405036] Call Trace:
[   65.405136]  [<c10a9a39>] __report_bad_irq+0x29/0xd0
[   65.405237]  [<c13b18fd>] ? add_interrupt_randomness+0x1d/0x160
[   65.405329]  [<c10a9e65>] note_interrupt+0x165/0x1b0
-- snip --    
[   65.405617]  [<c112fcc3>] ? sys_ioctl+0x63/0x90
[   65.405617]  [<c1662970>] ? syscall_call+0x7/0xb
[   65.405617] handlers:
[   65.405617] [<c1473100>] rtl8139_interrupt
[   65.405617] Disabling IRQ #15

I searched for variables in sysctl -A output that could cause this behaviour, changed a few, but to no avail. I diabled IPv6. I tried a RT-kernel. I tried the kernel parameters acpi=noirq and irqpoll. I checked dmesg and saw that the driver registered the IRQ15 correctly:

[    6.926691] 8139too: 8139too Fast Ethernet driver 0.9.28
[    6.927813] 8139too 0000:00:09.0 eth0: RealTek RTL8139 at 0x0001fc00, 00:05:b7:dd:53:25, IRQ 15

I have searched Documentation/ and Documentation/networking/ folders of the kernel for information, but found none. I used Google extensively, didn't find anything.

Any ideas of what might be the source of this behavior?

share|improve this question
    
Some ping implementations use gettimeofday(3) to calculate round-trip times. As a result, ping may print incorrect results if your system time is not reliable. –  paraxor Aug 15 '13 at 23:35
    
@EvanTeitelman Indeed, my ping implementation does use gettimeofday. However, I checked those results with Wireshark and it shows the same behavior (2 ms decrements). Therefore, I don't think gettimeofday is the culprit... –  Bruno Martins Aug 16 '13 at 11:41
1  
And, I think it might be worthy of note, those two computers are connected with a direct short Ethernet cable, so I would expect latencies in the order of microseconds, not miliseconds.... –  Bruno Martins Aug 16 '13 at 12:39
    
The nobody cared messages and the ping results are probably related. Is the 8139too the right driver? In the past there been some issue with the 8139cp. Have some option on insert? Some debug option maybe? On /proc/interrupts there's some other driver using 15? –  Alex Aug 17 '13 at 23:14
add comment

1 Answer

The problem was a misconfigured BIOS. Resetting it to the default values solved the issue. I was not able to find which configuration caused the problem... I'm leaving this answer for the sake of completeness.

share|improve this answer
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.