On Tuesday 10 May 2005 1:43 am, Colin Leroy wrote:
> On Mon, 9 May 2005 08:12:48 -0700
> David Brownell <[email protected]> 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
>
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]