Date: Wed, 20 Mar 2013 02:22:26 -0700 From: "Ronald F. Guilmette" <rfg@tristatelogic.com> To: freebsd-usb@freebsd.org Subject: Re: Help please... More problems with USB 3.0 (kernel freezes) Message-ID: <64636.1363771346@server1.tristatelogic.com> In-Reply-To: <51480F20.6060601@bitfrost.no>
next in thread | previous in thread | raw e-mail | index | archive | help
In message <51480F20.6060601@bitfrost.no>, Hans Petter Selasky <hps@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(). OK. So what am I supposed to do in order to enable those? >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. 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? >> >> 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? I'm sorry. I just don't understand what point you were trying to make. >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. >> 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.) >> 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? 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. */ ^^^^^^^^^^ ??
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?64636.1363771346>