Re: Any insight on this ubuntu bug?

[Tom Sutherland <tsuther i3businesssolutions com>]

The problem seems to happen when I move from one wireless network to
another (home to work, work to home) so I can generally get it to fail
once/day or so.

If there's any testing/debugging that doesn't require skill, I'd be
happy to help.

oh, and thanks for the responses.


On Tue, 2010-01-26 at 17:43 -0500, Dan Williams wrote:
> On Tue, 2010-01-26 at 16:31 -0500, Tony Espy wrote:
> > Dan Williams wrote:
> > > On Tue, 2010-01-26 at 15:44 -0500, Tom Sutherland wrote:
> > >> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/352228
> > >>
> > >> Wireless gets disconnected every so often and it appears the only
> > >> workaround is to do a "sudo restart network-manager"
> > >>
> > >> It makes sense that this is a crappy firmware/driver issues with
> > >> specific Intel cards, but is it possible network-manager isn't coping
> > >> well?
> > > 
> > > I seem to recall a kernel patch for this bug being submitted in the past
> > > week or two.
> > > 
> > > Basically, it's a driver bug.  I'd be very skeptical of a simple NM
> > > restart fixing this as that doesn't do anything reinitialize or fix the
> > > driver.  An rmmod/modprobe is necessary in situations like that to
> > > re-load the driver and get it talking to the card again.
> > 
> > I just added a comment to the bug pretty much echoing Dan.
> > 
> > That said, I also think there's a possibility that the system calls made 
> > by NM and wpa_supplicant during a restart might be sufficient to jog the 
> > driver into working again.  Just a theory...
> 
> Yeah, the only interesting thing there would be IFF_UP/IFF_DOWN.  And
> that may actually be enough, since I think on IFF_DOWN the iwl driver
> will unload firmware?  I forget what it does.
> 
> A thought:
> 
> Down the device in NMDeviceWifi's activation_failure_handler() and
> schedule an idle handler for 250ms from now to up the device.  Clear
> that idle handler in stage1_device_prepare, and then bring the device up
> there too.  Otherwise let the idle handler fire and re-up the device.
> Also add a check to scanning_allowed() so that if the re-up idle handler
> is non-zero, we don't allow scans (most devices can't scan when they are
> down).
> 
> That might be a workaround.  Of coruse before adding something like that
> we should probably see if it makes any difference.
> 
> Dan
> 
>