Bug#530823: closed by Moritz Muehlenhoff <jmm@inutil.org> (Re: Can't get an IP address using the ath5k driver; madwifi worked.)
On Tue, Sep 08, 2009 at 08:24:19PM +0000, Debian Bug Tracking System <owner@bugs.debian.org> was heard to say:
> On Thu, Sep 03, 2009 at 08:02:27PM -0700, Daniel Burrows wrote:
> > On Tue, Sep 01, 2009 at 07:22:36PM +0200, Moritz Muehlenhoff <jmm@inutil.org> was heard to say:
> > > On Wed, Jul 15, 2009 at 10:51:25PM +0200, Moritz Muehlenhoff wrote:
> > > > For Lenny I'd recommend to stay with the madwifi driver (which was
> > > > only removed from unstable). If the error persists with 2.6.30
> > > > from unstable, please file a bug at bugzilla.kernel.org and
> > > > send the bugnumber to this bug. This needs to be fixed upstream,
> > > > the Debian kernel doesn't carry ath5k patches.
> > >
> > > Daniel, did you report this upstream?
> >
> > After the third or fourth Debian revision to the kernel, things are
> > working again, more or less.
>
> Then it seems to have been fixed in one of the stable point updates
> for 2.6.30, closing.
I may have spoken too soon. I can get an IP address now, but...
64 bytes from 192.168.1.1: icmp_seq=82 ttl=127 time=87.1 ms
64 bytes from 192.168.1.1: icmp_seq=83 ttl=127 time=189 ms
64 bytes from 192.168.1.1: icmp_seq=84 ttl=127 time=288 ms
64 bytes from 192.168.1.1: icmp_seq=85 ttl=127 time=205 ms
64 bytes from 192.168.1.1: icmp_seq=86 ttl=127 time=392 ms
64 bytes from 192.168.1.1: icmp_seq=87 ttl=127 time=232 ms
64 bytes from 192.168.1.1: icmp_seq=88 ttl=127 time=224 ms
64 bytes from 192.168.1.1: icmp_seq=89 ttl=127 time=3080 ms
64 bytes from 192.168.1.1: icmp_seq=90 ttl=127 time=6538 ms
64 bytes from 192.168.1.1: icmp_seq=91 ttl=127 time=5538 ms
64 bytes from 192.168.1.1: icmp_seq=92 ttl=127 time=4943 ms
64 bytes from 192.168.1.1: icmp_seq=93 ttl=127 time=4303 ms
64 bytes from 192.168.1.1: icmp_seq=94 ttl=127 time=3611 ms
64 bytes from 192.168.1.1: icmp_seq=95 ttl=127 time=3618 ms
64 bytes from 192.168.1.1: icmp_seq=96 ttl=127 time=20548 ms
64 bytes from 192.168.1.1: icmp_seq=97 ttl=127 time=19581 ms
64 bytes from 192.168.1.1: icmp_seq=98 ttl=127 time=18607 ms
64 bytes from 192.168.1.1: icmp_seq=99 ttl=127 time=17734 ms
64 bytes from 192.168.1.1: icmp_seq=100 ttl=127 time=16739 ms
64 bytes from 192.168.1.1: icmp_seq=101 ttl=127 time=15809 ms
64 bytes from 192.168.1.1: icmp_seq=102 ttl=127 time=16791 ms
64 bytes from 192.168.1.1: icmp_seq=103 ttl=127 time=15797 ms
64 bytes from 192.168.1.1: icmp_seq=104 ttl=127 time=14825 ms
64 bytes from 192.168.1.1: icmp_seq=105 ttl=127 time=14239 ms
64 bytes from 192.168.1.1: icmp_seq=106 ttl=127 time=17390 ms
64 bytes from 192.168.1.1: icmp_seq=107 ttl=127 time=8936 ms
64 bytes from 192.168.1.1: icmp_seq=108 ttl=127 time=8021 ms
64 bytes from 192.168.1.1: icmp_seq=109 ttl=127 time=7923 ms
64 bytes from 192.168.1.1: icmp_seq=110 ttl=127 time=7045 ms
64 bytes from 192.168.1.1: icmp_seq=111 ttl=127 time=6081 ms
64 bytes from 192.168.1.1: icmp_seq=112 ttl=127 time=5193 ms
64 bytes from 192.168.1.1: icmp_seq=113 ttl=127 time=4389 ms
64 bytes from 192.168.1.1: icmp_seq=114 ttl=127 time=3519 ms
64 bytes from 192.168.1.1: icmp_seq=115 ttl=127 time=2529 ms
64 bytes from 192.168.1.1: icmp_seq=116 ttl=127 time=1897 ms
64 bytes from 192.168.1.1: icmp_seq=117 ttl=127 time=905 ms
64 bytes from 192.168.1.1: icmp_seq=118 ttl=127 time=817 ms
64 bytes from 192.168.1.1: icmp_seq=119 ttl=127 time=134 ms
64 bytes from 192.168.1.1: icmp_seq=120 ttl=127 time=40.3 ms
Here 192.168.1.1 is the wireless router in the next room that my
computer is associated with; in extreme cases, the system just becomes
totally unable to talk to the router at all. At best, my network
connections tend to have wildly fluctuating speeds, and occasionally
they just drop out. In contrast, my Windows laptop sitting next to this
desktop has a perfect connection.
I've also noticed that I occasionally see this message in syslog:
Sep 12 11:09:10 emurlahn kernel: [1024281.542085] ath5k phy0: unsupported jumbo
It doesn't appear to be directly correlated to random fluctuations in
my ping times, though.
Daniel
Reply to: