linux-kernel - Re: 2.6.25-rc2 regression in rt61pci wireless driver

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-prev] [thread-next>] [day] [month] [year] [list]

Message-Id: <200802182251.35630.chris2553@googlemail.com>
Date:	Mon, 18 Feb 2008 22:51:35 +0000
From:	Chris Clayton <chris2553@...glemail.com>
To:	Ivo van Doorn <ivdoorn@...il.com>
Cc:	linux-kernel@...r.kernel.org, linux-wireless@...r.kernel.org
Subject: Re: 2.6.25-rc2 regression in rt61pci wireless driver

Hi Ivo,

On Monday 18 February 2008, Ivo van Doorn wrote:
> Hi,
> 
> > In 2.6.25 kernels, my wireless LAN dies after even the smallest amount
> > of network activity. The following screen cut shows what I typically
> > see:
> 
> How complete is this failure? Just TX or also RX?
> 
> Could you use the tools found here:
> http://www-user.rhrk.uni-kl.de/~nissler/rt2x00/index.html
> 
> and capture all TX/RX frames going through the hardware?
> Note that after the failure, this dumping facitilty should still report
> any ping request you might send to the interface.
> 

It will be tomorrow before I can provide this because I'm struggling to get
wireshark to build against the old (2.4.x) kernel headers that match glibc on
my laptop. I'll build it on my desktop, which has more recent headers, and
decode the frame dump there. But I need sleep now :)

> > [chris:~]$ uname -a
> > Linux laptop 2.6.25-rc2 #10 PREEMPT Sat Feb 16 09:53:04 UTC 2008 i686
> > GNU/Linux
> > [chris:~]$ ping 192.168.1.1
> > PING 192.168.1.1 (192.168.1.1) from 192.168.1.30 : 56(84) bytes of data.
> > 64 bytes from 192.168.1.1: icmp_seq=0 ttl=255 time=9.837 msec
> > 64 bytes from 192.168.1.1: icmp_seq=1 ttl=255 time=3.148 msec
> > 64 bytes from 192.168.1.1: icmp_seq=2 ttl=255 time=2.205 msec
> 
> I have a series of tests I would like to request from you,
> you mentioned you already enabled debugfs, and that is just what we need. ;)
> Please use attached script to create dumps of the hardware register contents.
> 
> There are specific moments that should be dumped:
> - kernel 2.6.24 (last known working version for you).
> - kernel 2.6.25-rc2 (after ifup, before TX dies)
> - kernel 2.6.25-rc2 (after ifup, after TX dies)
>  

These diagnostics are attached, with obvious filenames.

> > I will be more than happy to provide additional diagnostics, but
> > please bear in mind that I am not a git user, so cannot do bisects. I
> > am, however, perfectly capable of applying or reverting patches,
> > rebuilding and re-testing, so I am quite happy to do that.
> 
> Above traces should be enough, but to determine where rt2x00 broke
> down approximatly I need to have a few test result on specific moments.
> Could you test the kernel with the following versions:
> 
> rt2x00 2.0.11	2d68de3efa62655d551092f5c787505735d561ad
> rt2x00 2.0.12	a3c7aa58df7df80aa05f166fe3e42482247164cf
> rt2x00 2.0.13	5a6012e105ae1664cd2841c33bf59fbdd8d4dbcc
> 
> Checking those out is simply a matter of:
> git branch 2.0.11 2d68de3efa62655d551092f5c787505735d561ad
> git checkout 2.0.11
> 
> No further bisecting is needed, but with above tests I can at least
> narrow it down to find the cause of this issue.
> 
> Thanks.
> 
> Ivo
> 



-- 
Beauty is in the eye of the beerholder.

View attachment "debugfsdump-2.6.24.2" of type "text/plain" (6748 bytes)

View attachment "debugfsdump-2.6.25-rc2-after" of type "text/plain" (6748 bytes)

View attachment "debugfsdump-2.6.25-rc2-before" of type "text/plain" (6749 bytes)