netdev - b44: high ping times with wireless-dev

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [thread-next>] [day] [month] [year] [list]

Date:	Sat, 16 Jun 2007 23:27:43 +0200
From:	Maximilian Engelhardt <maxi@...monizer.de>
To:	netdev <netdev@...r.kernel.org>
Cc:	"linux-kernel" <linux-kernel@...r.kernel.org>,
	"linux-wireless" <linux-wireless@...r.kernel.org>,
	Michael Buesch <mb@...sch.de>,
	Gary Zambrano <zambrano@...adcom.com>,
	Stephen Hemminger <shemminger@...ux-foundation.org>,
	"Jeff Garzik" <jgarzik@...ox.com>,
	"Arnaldo Carvalho de Melo" <acme@...stprotocols.net>
Subject: b44: high ping times with wireless-dev

Hello,

I recently did some test and found out something interesting about the b44 
problem I wrote earlier. 

The problem is the following:
When I use my BCM4401 with the b44 driver in wireless-dev I get very high ping 
times looking like this:

64 bytes from 172.30.10.1: icmp_seq=1 ttl=64 time=1863 ms
64 bytes from 172.30.10.1: icmp_seq=2 ttl=64 time=855 ms
64 bytes from 172.30.10.1: icmp_seq=3 ttl=64 time=1855 ms
64 bytes from 172.30.10.1: icmp_seq=4 ttl=64 time=855 ms
64 bytes from 172.30.10.1: icmp_seq=5 ttl=64 time=1854 ms
64 bytes from 172.30.10.1: icmp_seq=6 ttl=64 time=854 ms
64 bytes from 172.30.10.1: icmp_seq=7 ttl=64 time=1851 ms
64 bytes from 172.30.10.1: icmp_seq=8 ttl=64 time=851 ms
64 bytes from 172.30.10.1: icmp_seq=9 ttl=64 time=1851 ms
64 bytes from 172.30.10.1: icmp_seq=10 ttl=64 time=851 ms

I also found out that shortly after I boot my laptop and log into kde ping 
times are not that high but start to increase very quickly:

64 bytes from 172.30.10.1: icmp_seq=53 ttl=64 time=2.19 ms
64 bytes from 172.30.10.1: icmp_seq=54 ttl=64 time=2.22 ms
64 bytes from 172.30.10.1: icmp_seq=55 ttl=64 time=2.20 ms
64 bytes from 172.30.10.1: icmp_seq=56 ttl=64 time=2.20 ms
64 bytes from 172.30.10.1: icmp_seq=57 ttl=64 time=18.6 ms
64 bytes from 172.30.10.1: icmp_seq=58 ttl=64 time=1268 ms
64 bytes from 172.30.10.1: icmp_seq=59 ttl=64 time=268 ms
64 bytes from 172.30.10.1: icmp_seq=60 ttl=64 time=1268 ms
64 bytes from 172.30.10.1: icmp_seq=61 ttl=64 time=268 ms
64 bytes from 172.30.10.1: icmp_seq=62 ttl=64 time=6.08 ms
64 bytes from 172.30.10.1: icmp_seq=63 ttl=64 time=268 ms
64 bytes from 172.30.10.1: icmp_seq=64 ttl=64 time=1264 ms
64 bytes from 172.30.10.1: icmp_seq=65 ttl=64 time=264 ms

After some time digging around I found out something really interesting. When 
I play some music ping times are immediately lower. If I stop playing music 
they are back to the same times as they were before.

I guess that there is a problem with interrupts so I post some information of 
my system in hope it will be usefull.

maxi@...la:~$ cat /proc/interrupts
          CPU0       
 0:     126317    XT-PIC-XT        timer
 1:       3600    XT-PIC-XT        i8042
 2:          0    XT-PIC-XT        cascade
 7:          1    XT-PIC-XT        parport0
 8:          1    XT-PIC-XT        rtc
 9:      17371    XT-PIC-XT        acpi
10:      13237    XT-PIC-XT        firewire_ohci, yenta, yenta, ehci_hcd:usb1, 
uhci_hcd:usb3, uhci_hcd:usb4, Intel 82801DB-ICH4, Intel 82801DB-ICH4 Modem, 
eth0
11:      89059    XT-PIC-XT        uhci_hcd:usb2, i915@pci:0000:00:02.0
12:        632    XT-PIC-XT        i8042
14:      10354    XT-PIC-XT        libata
15:       7408    XT-PIC-XT        libata
NMI:          0 
ERR:          0


[...]
ACPI: PCI Interrupt Link [LNKD] enabled at IRQ 10
ACPI: PCI Interrupt 0000:02:02.0[A] -> Link [LNKD] -> GSI 10 (level, low) -> 
IRQ 10
ssb: Sonics Silicon Backplane found on PCI device 0000:02:02.0
b44.c:v2.0
eth0: Broadcom 44xx/47xx 10/100BaseT Ethernet 00:c0:9f:29:99:a7
[...]

This problem did only happen with wireless-dev (checkout this evening) and 
with -mm kernels I used some time ago for testing. Currently I'm running 
2.6.22-rc4 that works perfectly fine and doesn't show that problem.

Maxi

Download attachment "signature.asc " of type "application/pgp-signature" (190 bytes)