>
> Linus, Alan
>
> In both stable and development branches of the kernel, when
>reschedule_idle is called, it is presumed, that reschedule_idle will
>release the spin_lock, thus call spin_unlock_irqrestore. This does not
>happen when the kernels are compiled this __SMP__. Artur Skawina
><skawina@geocities.com> thinks this might delay servicing interrupts
>unnecessarily. (thanks Artur for your response).
Aha, maybe that's why my i486 laptop gets 1001.2 ms and 3.0 ms
alternatingly over local Ethernet. I run rc5des and the ping.
Packets:
root@despair:~# ping moving
PING moving.m-l.org (192.168.1.2) from 192.168.1.20 : 56(84) bytes of data.
64 bytes from 192.168.1.2: icmp_seq=0 ttl=255 time=14.9 ms
64 bytes from 192.168.1.2: icmp_seq=1 ttl=255 time=1.8 ms
64 bytes from 192.168.1.2: icmp_seq=2 ttl=255 time=1.7 ms
64 bytes from 192.168.1.2: icmp_seq=3 ttl=255 time=1.7 ms
64 bytes from 192.168.1.2: icmp_seq=4 ttl=255 time=911.5 ms
64 bytes from 192.168.1.2: icmp_seq=5 ttl=255 time=911.5 ms
64 bytes from 192.168.1.2: icmp_seq=6 ttl=255 time=1.7 ms
64 bytes from 192.168.1.2: icmp_seq=7 ttl=255 time=1001.3 ms
64 bytes from 192.168.1.2: icmp_seq=8 ttl=255 time=22.4 ms
64 bytes from 192.168.1.2: icmp_seq=9 ttl=255 time=1001.3 ms
64 bytes from 192.168.1.2: icmp_seq=10 ttl=255 time=22.4 ms
64 bytes from 192.168.1.2: icmp_seq=11 ttl=255 time=1001.3 ms
64 bytes from 192.168.1.2: icmp_seq=12 ttl=255 time=22.5 ms
64 bytes from 192.168.1.2: icmp_seq=13 ttl=255 time=1001.3 ms
64 bytes from 192.168.1.2: icmp_seq=14 ttl=255 time=22.5 ms
64 bytes from 192.168.1.2: icmp_seq=15 ttl=255 time=1001.9 ms
64 bytes from 192.168.1.2: icmp_seq=16 ttl=255 time=2.9 ms
--- moving.m-l.org ping statistics ---
17 packets transmitted, 17 packets received, 0% packet loss
round-trip min/avg/max = 1.7/408.5/1001.9 ms
What was particularly interesting was I ran ping, and then suspended it. I
completely lost networking to the box. The ping time when I resumed the
ping was 28 seconds. Networking returned to normal and interactive use
never changed. I can do it repeatedly too.
That's a very odd way to DoS a box...
-George Greer
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/