Re: [linux-usb-devel] Re: serious 2.6 bug in USB subsystem?

[David Mosberger <davidm@napali.hpl.hp.com>]

>>>>> On Thu, 30 Oct 2003 07:11:42 -0800, David Brownell <david-b@pacbell.net> said:

  David> David Mosberger wrote:

  >> On x86, there is no OOps, it just freezes.  On ia64, I get a nice MCA
  >> and from that we can infer that a USB host controller read from
  >> address 0xf0000000 caused the problem but since this is asynchronous
  >> to the kernel's code path, the instruction pointer etc. in the MCA
  >> state dump isn't terribly helpful.

  David> Does that 0xf0000000 (on ia64) match any obvious address mapping
  David> of the null pointer -- like a dma mapping?

Not really.  AFAIK, 0xf0000000 is part of the PCI MMIO address space,
but on the machines that I have access to, this particular address
isn't assigned to any device:

	$ lspci -v|fgrep 'Memory at'
        Memory at 0000000080000000 (32-bit, prefetchable) [size=128M]
        Memory at 0000000088000000 (32-bit, non-prefetchable) [size=512K]
        Memory at 00000000d0023000 (32-bit, non-prefetchable) [size=4K]
        Memory at 00000000d0022000 (32-bit, non-prefetchable) [size=4K]
        Memory at 00000000d0021000 (32-bit, non-prefetchable) [size=256]
        Memory at 00000000d0020000 (32-bit, non-prefetchable) [size=4K]
        Memory at 00000000d0000000 (32-bit, non-prefetchable) [size=128K]
        Memory at 00000000e0200000 (32-bit, non-prefetchable) [size=4K]
        Memory at 00000000e0100000 (32-bit, non-prefetchable) [size=1M]

  David> I'm not sure that if the HID driver were to pass a null
  David> buffer pointer, it would be caught anywhere.

OK, I'll try to find some time to trace the I/O MMU calls to see if
something isn't kosher at that level.  Is there a good way of getting
a relatively high-level of tracing in the USB subsystem that would
some me what's going on between the HID and the core USB level?

	--david