RE: Panic in quirk_usb_early_handoff

2017-03-06 Thread David Laight
> From: Mason > Sent: 06 March 2017 15:46 ... > >> The issue was that, on this platform, the PCI configuration space > >> and memory space are multiplexed; in other words they reside at > >> the same physical address, with a bit in MMIO to choose one or > >> the other. > > > > Time to shoot

Re: Panic in quirk_usb_early_handoff

2017-03-06 Thread Mason
On 06/03/2017 16:27, David Laight wrote: > Mason wrote: >> >>> So the kernel panics in xhci_find_next_ext_cap() >>> ( drivers/usb/host/xhci-ext-caps.h:122 ) >>> http://lxr.free-electrons.com/source/drivers/usb/host/xhci-ext-caps.h?v=4.9#L122 >>> >>> Any idea how this can happen? >>> >>> base

RE: Panic in quirk_usb_early_handoff

2017-03-06 Thread David Laight
From: Mason > Sent: 06 March 2017 13:50 > On 06/03/2017 13:42, Mason wrote: > > > So the kernel panics in xhci_find_next_ext_cap() > > ( drivers/usb/host/xhci-ext-caps.h:122 ) > > http://lxr.free-electrons.com/source/drivers/usb/host/xhci-ext-caps.h?v=4.9#L122 > > > > Any idea how this can

Re: Panic in quirk_usb_early_handoff

2017-03-06 Thread Mason
On 06/03/2017 15:30, Robin Murphy wrote: > On 06/03/17 12:42, Mason wrote: > >> $ arm-linux-gnueabihf-addr2line -i -e vmlinux c039fe44 >> arch/arm/include/asm/io.h:119 >> >> In other words, readl() >> Not as helpful as expected... > > I guess your toolchain isn't generating whatever debug info

Re: Panic in quirk_usb_early_handoff

2017-03-06 Thread Robin Murphy
[+linux-pci, just in case] On 06/03/17 12:42, Mason wrote: > On 03/03/2017 20:02, Robin Murphy wrote: > >> On 03/03/17 17:15, Mason wrote: >> > [1.264893] Unable to handle kernel paging request at virtual address > d08664f4 >> >> Note that that's a reasonable approximation of a

Re: Panic in quirk_usb_early_handoff

2017-03-06 Thread Mason
On 06/03/2017 13:42, Mason wrote: > So the kernel panics in xhci_find_next_ext_cap() > ( drivers/usb/host/xhci-ext-caps.h:122 ) > http://lxr.free-electrons.com/source/drivers/usb/host/xhci-ext-caps.h?v=4.9#L122 > > Any idea how this can happen? > > base =

Re: Panic in quirk_usb_early_handoff

2017-03-06 Thread Mason
On 03/03/2017 20:02, Robin Murphy wrote: > On 03/03/17 17:15, Mason wrote: > [1.264893] Unable to handle kernel paging request at virtual address d08664f4 > > Note that that's a reasonable approximation of a vmalloc address... > [1.272248] pgd = c0004000 [

Re: Panic in quirk_usb_early_handoff

2017-03-04 Thread Ard Biesheuvel
> On 4 Mar 2017, at 17:29, Mason wrote: > >> On 04/03/2017 18:16, Ard Biesheuvel wrote: >> >> After pc, the link register is the most likely to legally point into >> the kernel .text section so it makes sense imo to decode the address >> into a function name plus offset. >

Re: Panic in quirk_usb_early_handoff

2017-03-04 Thread Ard Biesheuvel
> On 4 Mar 2017, at 16:57, Mason wrote: > >> On 04/03/2017 09:07, Ard Biesheuvel wrote: >>> On 4 March 2017 at 00:24, Mason wrote: On 03/03/2017 20:02, Robin Murphy wrote: > On 03/03/17 17:15, Mason wrote: > > [1.261813] Unable to handle kernel

Re: Panic in quirk_usb_early_handoff

2017-03-04 Thread Mason
On 04/03/2017 18:16, Ard Biesheuvel wrote: > After pc, the link register is the most likely to legally point into > the kernel .text section so it makes sense imo to decode the address > into a function name plus offset. Does gcc ever use the link register as a general purpose register? (In

Re: Panic in quirk_usb_early_handoff

2017-03-04 Thread Mason
On 04/03/2017 09:07, Ard Biesheuvel wrote: > On 4 March 2017 at 00:24, Mason wrote: >> On 03/03/2017 20:02, Robin Murphy wrote: >> >>> On 03/03/17 17:15, Mason wrote: >>> [1.261813] Unable to handle kernel paging request at virtual address d08611e4 [1.269167] pgd = c0004000

Re: Panic in quirk_usb_early_handoff

2017-03-04 Thread Alan Stern
On Sat, 4 Mar 2017, Ard Biesheuvel wrote: > On 4 March 2017 at 00:24, Mason wrote: > > On 03/03/2017 20:02, Robin Murphy wrote: > > > >> On 03/03/17 17:15, Mason wrote: > >> > >>> [1.261813] Unable to handle kernel paging request at virtual address > >>> d08611e4 > >>> [

Re: Panic in quirk_usb_early_handoff

2017-03-04 Thread Ard Biesheuvel
On 4 March 2017 at 00:24, Mason wrote: > On 03/03/2017 20:02, Robin Murphy wrote: > >> On 03/03/17 17:15, Mason wrote: >> >>> [1.261813] Unable to handle kernel paging request at virtual address >>> d08611e4 >>> [1.269167] pgd = c0004000 >>> [1.271979] [d08611e4]

Re: Panic in quirk_usb_early_handoff

2017-03-03 Thread Mason
On 03/03/2017 20:02, Robin Murphy wrote: > On 03/03/17 17:15, Mason wrote: > >> [1.261813] Unable to handle kernel paging request at virtual address >> d08611e4 >> [1.269167] pgd = c0004000 >> [1.271979] [d08611e4] *pgd=8f804811, *pte=, *ppte= >> [1.278394]

Re: Panic in quirk_usb_early_handoff

2017-03-03 Thread Mason
On 03/03/2017 20:02, Robin Murphy wrote: > On 03/03/17 17:15, Mason wrote: > >> [1.264893] Unable to handle kernel paging request at virtual address >> d08664f4 > > Note that that's a reasonable approximation of a vmalloc address... > > ...and that specifically it's r0 + r3... > > ...and

Re: Panic in quirk_usb_early_handoff

2017-03-03 Thread Robin Murphy
On 03/03/17 17:15, Mason wrote: [...] >>> [1.264893] Unable to handle kernel paging request at virtual address >>> d08664f4 Note that that's a reasonable approximation of a vmalloc address... >>> [1.272248] pgd = c0004000 >>> [1.275060] [d08664f4] *pgd=8f804811, *pte=,

Re: Panic in quirk_usb_early_handoff

2017-03-03 Thread Mason
On 03/03/2017 18:10, Mason wrote: > On 03/03/2017 17:18, Mason wrote: >> Hello, >> >> I'm seeing this panic randomly at boot-time, so I want to throw >> it out there in case someone recognizes the issue off the top of >> their head. >> >> I'm on Linux 4.9, using a USB3 PCIe card. I'm actively

Re: Panic in quirk_usb_early_handoff

2017-03-03 Thread Mason
On 03/03/2017 17:18, Mason wrote: > Hello, > > I'm seeing this panic randomly at boot-time, so I want to throw > it out there in case someone recognizes the issue off the top of > their head. > > I'm on Linux 4.9, using a USB3 PCIe card. I'm actively working on > the PCIe support, so I may be