Comments below. -- Michael Schwarz > On Mon, 19 Mar 2007, Michael Schwarz wrote: > >> I'm going to hang on to the hardware. This is a pilot/demo that may lead >> to development of a new device, and, if so, I'll be getting back into >> device driver writing. Working this problem would be great practice for >> that. So I will do it. The only problem is I don't know when! >> >> I believe I can replicate the problem, so I'll find time (perhaps next >> weekend) to capture the data of interest. > > Michael, you don't seem to appreciate the basic principles for tracking > down problems. I want to bristle at this. I've been a professional software developer for nearly 20 years. But I can't because all of your points below are, of course, dead on for tracking down a device-level problem. > > First: Simplify. Get rid of everything that isn't relevant > to the problem and could serve to distract you. In particular, > don't run X. That will eliminate around half of your running > processes and shrink the stack dump down so that it might fit > in the kernel buffer without overflowing. Right on. And I know this; I should have had two boxes where I was working; one where I could do browsy-emaily things separate from the problem I was working. > > Second: Simplify. Don't run kernels that have been modified by > Fedora or anybody else. Use a plain vanilla kernel from > kernel.org. Yeah; But here was where I lacked confidence. I used to know every inch of my kernel and my hardware, but, as previously stated, that was back in the 2.2.x days. I wasn't confident that I could run my hardware with a plain-vanilla kernel or that I could successfully roll my own working 2.6.x kernel in a timely manner. But, of course, I understand why this is a good idea. > > Third: Simplify. Try not to collect the same data over and over > again (take a look at the starts of all those dmesg files you > compressed and emailed). You can clear the kernel's log buffer > after dumping it by doing "dmesg -c >/dev/null". Thanks, I actually didn't know that flag. Makes me feel pretty stupid... > > Fourth: Be prepared to make changes. This means making changes > to the kernel configuration or source code, another reason for > using a stock kernel. I agree -- I just lacked confidence doing so with newer kernels. I used to ALWAYS build my own kernel right up through the 2.2.x series, building the kernel to exactly match my hardware. I just haven't kept up. And if you compare the 2.2.x kernel's configuration parameter list to the 2.6.x, well, you can maybe understand why I was reluctant to launch on that when under time pressure. But you point (I gather) is that if I had, it might well have taken less time than it did... > > To get some really useful data, you need to build a kernel with > CONFIG_USB_DEBUG turned on. Without that setting there won't be any > helpful debugging information in the log. Before I send any more info on this problem, I will do this and all of the above. > > Then you should run a minimal system. Single-user mode would be best, > but that can be _too_ bare-bones. No GUI will suffice. Will do. > > Then you should clear the kernel log before before starting the big file > copy. Basically nothing that happens before then is important, because > nothing has gone wrong. > > Then after the hang occurs, see what shows up in the dmesg log. And get a > stack dump. > >> Mr. Stern: Where might I go for low level programming information on USB >> devices? I'm interested in registers/DMA/packet formats, etc. > > Are you interested in USB devices (i.e., flash drives, webcams, and so on > -- the things you plug in to a USB connection) or USB controllers (the > hardware in your computer that manages the USB bus)? Firstly the controllers, then specific devices. > >> I've found info on the USB protocol itself, but I haven't found info on >> devices. Obviously I can dig through kernel source, but documents would >> be >> nice! Again, if this is an unreasonable request for you to "do my >> homework," just say so! I won't be offended. I'm sure I can find it >> myself >> given time, but if you happen to have some URLs handy, they'd be >> appreciated. > > There are three types of USB controllers used in personal computers: UHCI, > OHCI, and EHCI. Links to their specifications are available here: > > http://www.usb.org/developers/resources/ Thanks. This is just what I wanted. > > Specifications for various classes of USB devices are available here: > > http://www.usb.org/developers/devclass_docs And this. Thank you much. I won't post on this issue again until I've "cleared the decks" of the items you mention above. Thanks again. > > Alan Stern > > - To unsubscribe from this list: send the line "unsubscribe linux-raid" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
