On Tue, Mar 19, 2002, Greg KH <[EMAIL PROTECTED]> wrote: > On Tue, Mar 19, 2002 at 01:54:01PM -0500, Johannes Erdfelt wrote: > > On Tue, Mar 19, 2002, David Brownell <[EMAIL PROTECTED]> wrote: > > > > > > > I've added this to my tree, but no, it does not solve my lockup problem > > > > > > > (for those playing at home, it's a SMP kernel on a UP box, with a > > > > > > > Microsoft trackball.) I'll do more tests tomorrow to see if I can > > > > > > > narrow it down some more (i.e. if it's only with a specific device > > > > > > > plugged in or not.) > > > > > > > > > > I tried again this morning and reproduced it, and captured an oops. > > > > > I can load uhci.o with no devices plugged into the bus just fine. But > > > > > when I insert my trackball into the root hub I get the following oops: > > > > > > Possibly related ... the 2.5 version is mostly the same: > > > > > > With a 2.5.7-pre1 kernel, "uhci", that pci_pool patch I sent around > > > recently (which is in 2.5.7 fyi, and applies to 2.4.19-pre except for > > > the very last chunk), and with CONFIG_DEBUG_SLAB, I got an > > > OOPS too. I couldn't ksymoops in this setup. > > > > > > This was when plugging in another (low speed) trackball, and > > > the OOPS was clearly caused by accessing poisoned pci_pool > > > memory. Seems like something in_irq() was trying to walk a > > > pointer that had been poisoned -- actually to offset it, it was an > > > access to an address like like a7a7a7b6 which oopesed. > > > > Aha. Greg, do you compile your kernels with slab poisoning enabled? > > Yes I do. I'll go turn that off and try again.
Probably why I couldn't reproduce it. I'm compiling a kernel with poisoning enabled. I suspect your new kernel won't have reproducible problems, but there's still a bug there. This is one situation where the registers would have pointed it out very quickly. :/ JE _______________________________________________ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
