public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: David Brownell <david-b@pacbell.net>
To: Colin Leroy <colin@colino.net>
Cc: linux-usb-devel@lists.sourceforge.net, linux-kernel@vger.kernel.org
Subject: Re: [linux-usb-devel] [2.6.12-rc4] network wlan connection goes down
Date: Tue, 10 May 2005 07:07:13 -0700	[thread overview]
Message-ID: <200505100707.13356.david-b@pacbell.net> (raw)
In-Reply-To: <20050510104349.7aca4227@colin.toulouse>

On Tuesday 10 May 2005 1:43 am, Colin Leroy wrote:
> On Mon, 9 May 2005 08:12:48 -0700
> David Brownell <david-b@pacbell.net> wrote:
> 
> > However, if you enable CONFIG_USB_DEBUG and send the "async" and
> > "registers" files from the relevant /sys/class/usb_host/usbN
> > directory, it should be easy to tell whether there's an issue at that
> > particular level.
> 
> ok, I reproduced it. I've put in place a crontab that checks if my
> router is pingable, and if not, dumps async and registers, resets the
> zd1201 (the iwconfig command is the one that puts it back into a
> functioning state), and dumps async and registers.

Hmm, well nothing looks wrong at the OHCI level.  It's possible that
the data toggle got screwed up somehow; there are devices where the
hardware doesn't reset it when it should.  If that's the case, there'd
likely be some rx or tx error (does "ifconfig" show any?  dmesg?) and
the wlan driver's recovery would need updating to ensure that the
various endpoints get properly reset given those quirks.

If you can report what the "iwconfig essid ..." command does down
at the USB level, that should help sort things out.  It's possible
that the network TX timeout mechanism might be a good place to kick
in some driver recovery scheme.  And it's not unknown that device
firmware cause problems!

It might also be good to check whether this is a case where packets
go out, but don't come back in; or vice versa.


> Here's the result:
> ... <snip> ...
> 
> The registers file changes while everything works, too. For example
> "BLF" isn't always present on the cmdstatus line.

BLF == "Bulk List Filled", basically it means the wlan
driver submitted a bulk URB and your printed the schedule
out before the hardware restarted its scan of that part
of the async schedule and cleared the bit.

What those dumps showed is just that there's an IN transfer
pending, with that WLAN driver polling the device to see
if there's a packet for your Linux host.  USB network links
do that more or less all the time the link is up.


> Also, I saw these lines in dmesg. Sadly enough they don't appear in
> syslog so I can't tell whether it happened at the same time the network
> went down.
> ohci_hcd 0001:10:1b.0: fminterval a7782edf
> ohci_hcd 0001:10:1b.0: fminterval a7782edf
> ohci_hcd 0001:10:1b.0: fminterval a7782edf
> ohci_hcd 0001:10:1b.0: fminterval a7782edf

Safe to ignore; there's some debug stuff that shouldn't
kick in when you "cat registers", but it does.

- Dave


> 
> Hope this helps,
> -- 
> Colin
> 

  reply	other threads:[~2005-05-10 14:07 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-05-09 14:24 [2.6.12-rc4] network wlan connection goes down Colin Leroy
2005-05-09 15:12 ` [linux-usb-devel] " David Brownell
2005-05-10  8:43   ` Colin Leroy
2005-05-10 14:07     ` David Brownell [this message]
2005-05-11  7:09       ` Colin Leroy
2005-05-11 11:59         ` Jeroen Vreeken

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=200505100707.13356.david-b@pacbell.net \
    --to=david-b@pacbell.net \
    --cc=colin@colino.net \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-usb-devel@lists.sourceforge.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox