On 03/20/13 10:22, Ronald F. Guilmette wrote:
In message <51480f20.6060...@bitfrost.no>,
Hans Petter Selasky <h...@bitfrost.no> wrote:
On 03/18/13 23:39, Ronald F. Guilmette wrote:
1) What is the best way to debug this? I have seen HPS suggest to others
with USB problems that they either (a) use the usbdump(8) command to get
more info about the problems or else (b) compile and install a new kernel
in which the option USB_DEBUG has been defined. Which should I do, and
how may I interpret the results in either case?
I see two kind of hangs:
1) IRQ is spinning
2) DMA is going wild in the memory
In sys/dev/usb/controller/xhci.c there are debug prints, DPRINTF() and
DPRINTFN().
Hi,
OK. So what am I supposed to do in order to enable those?
You need "options USB_DEBUG" in the kernel config.
Then you need to execute:
sysctl hw.usb.xhci.debug=15
You probably want to have a print in the interrupt routine.
Could you be a little more specific please? I do not do kernel coding,
and thus, I don't know what things I should be calling in order to get
some new kind of debug output.
You can use printf("MY printout\n"); to get printouts in the kernel.
I also don't know where is the interrupt routine, and even if I found that,
I would probably not have any idea where, within that, I should add some
sort of statement to print ?something? let alone what sorts of something
would be Good or Useful to print at that point.
Just search for "interrupt". Debug level is controlled via sysctl
hw.usb.xhci.debug=X
OK, but what should I be setting that to in order to get useful but non-
overwehlming debug information?
Just set it to the maximum and store everything. You won't get so much
unless you transfer a lot of data.
2) What are the command timeouts set to in the XHCI driver and how can I
increase them? (Perhaps my card is just barely meeting the published
USB standard timing specs, and just need a tiny bit more time?)
The XHCI is an active USB controller.
I have no idea what that means.
That means many high-level USB
commands must be fed into it using separate commands.
You did not complete the sentence.
That means many high-level USB commands must be fed into it using separate
commands IN ORDER TO ACCOMPLISH WHAT?
To understand this you need to read about how the EHCI / OHCI / XHCI /
UHCI controllers work.
I'm sorry. I just don't understand what point you were trying to make.
The point is that the command timeout is something bad happening in the
XHCI hardware / card you've got and not specific to the USB device you
plug in.
These have nothing to do with what is transferred to the USB device.
OK. What has that fact got to do with my question about timeouts?
I'm sorry to be so ignorant, but I am. You seem to be assuming that I have
a lot of knowledge about either (a) how low-level hardware interfaces to
USB things normally operate and/or (b) about FreeBSD drivers in particlar
and/or your USB driver specifically. Although I am willing to learn, unfor-
tuantely I do not currently know much if anything about any of this stuff.
I just know that I want to do what it takes to get this USB hardware that
I have here working under FreeBSD.
I'm not afraid to answer questions :-)
3) What exactly is "hw.usb.no_cs_fail" ?
This just instructs the system to not re-enumerate the device on
repeated clear stall failures.
I suppose that now I should go and google for "clear stall failures". (I'm
sorry, but I have no idea what those are either, but I will try to read up
on that on my own.)
Yes, that's a good idea.
4) What exactly is "hw.usb.u3g.debug" ?
That's debugging for u3g driver module.
Oh. OK. I think that seems to be utterly irrelevant to my attempts to
use USB stuff.
5) What exactly is "diveration" ?
Where did you find this?
That's a typo. It should be derivation
Near the top of the driver source:
/usr/src/sys/dev/usb/controller/xhci.c
/*
* A few words about the design implementation: This driver emulates
* the concept about TDs which is found in EHCI specification. This
* way we avoid too much diveration among USB drivers.
*/ ^^^^^^^^^^
Is this easier to understand:
/*
* A few words about the design implementation: This driver emulates
* the concept about TDs which is found in EHCI specification. This
* way we achieve that the USB controller drivers look similar to
* eachother which makes it easier to understand the code.
*/
--HPS
_______________________________________________
freebsd-usb@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-usb
To unsubscribe, send any mail to "freebsd-usb-unsubscr...@freebsd.org"
