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 another hardware engineer.
> 
> He's in CC :-)
> 
> > Hopefully it isn't an SMP system - but I wouldn't put it past them.
> 
> This is a dual- and quad- Cortex A9 MP platform :-(

So to do a config space access you have to use a pair of IPIs
to stop the other cpus doing any PCIe data accesses while the
MMIO bit makes the accesses all point to config space.
(After taking a lock to get access to the MMIO register.)

Or has someone a better idea?

David

N�r��yb�X��ǧv�^�)޺{.n�+{��^n�r���z���h�&���G���h�(�階�ݢj"���m��z�ޖ���f���h���~�m�

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 = ioremap_nocache(pci_resource_start(pdev, 0), len);
>>>
>>> Could I be passing garbage to ioremap_nocache?
>>
>> Oh...
>>
>> I have just now understood what Ard wrote a few days ago.
>>
>> 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 another hardware engineer.

He's in CC :-)

> Hopefully it isn't an SMP system - but I wouldn't put it past them.

This is a dual- and quad- Cortex A9 MP platform :-(

Regards.
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

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 happen?
> >
> > base = ioremap_nocache(pci_resource_start(pdev, 0), len);
> >
> > Could I be passing garbage to ioremap_nocache?
> 
> Oh...
> 
> I have just now understood what Ard wrote a few days ago.
> 
> 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 another hardware engineer.
Hopefully it isn't an SMP system - but I wouldn't put it past them.

David

N�r��yb�X��ǧv�^�)޺{.n�+{��^n�r���z���h�&���G���h�(�階�ݢj"���m��z�ޖ���f���h���~�m�

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 that -i uses
> to show where it was actually inlined, shame.

I used gcc-linaro-5.3.1-2016.05-x86_64_arm-linux-gnueabihf
Is that too old?

Might the issue come from my kernel config?

#
# Compile-time checks and compiler options
#
CONFIG_DEBUG_INFO=y
CONFIG_DEBUG_INFO_REDUCED=y
CONFIG_DEBUG_INFO_SPLIT=y
# CONFIG_DEBUG_INFO_DWARF4 is not set
# CONFIG_GDB_SCRIPTS is not set
CONFIG_ENABLE_WARN_DEPRECATED=y
CONFIG_ENABLE_MUST_CHECK=y
CONFIG_FRAME_WARN=1024
# CONFIG_STRIP_ASM_SYMS is not set
# CONFIG_READABLE_ASM is not set
# CONFIG_UNUSED_SYMBOLS is not set
# CONFIG_PAGE_OWNER is not set
# CONFIG_DEBUG_FS is not set
# CONFIG_HEADERS_CHECK is not set
# CONFIG_DEBUG_SECTION_MISMATCH is not set
CONFIG_SECTION_MISMATCH_WARN_ONLY=y
# CONFIG_DEBUG_FORCE_WEAK_PER_CPU is not set
# CONFIG_MAGIC_SYSRQ is not set
CONFIG_DEBUG_KERNEL=y


> Put together, if I'm skimming unfamiliar XHCI code and docs correctly,
> this would imply that a supposed read of the HCC Parameters register
> claimed that the extended capabilities register was at offset 0x29f8
> into a 0x2000-long BAR. That does suggest that whatever's being accessed
> through that ioremap() isn't actually the contents of BAR 0 at all (said
> field should apparently read as 0x140 representing an offset of 0x500).
> You're not still trying have your PCI host controller place its
> MEM-space window over the top of system RAM, are you? Otherwise, I'd be
> inclined to double check that your config space accesses and resource
> assignment are producing sane values.

It looks like the current PCI framework doesn't expect platforms to
multiplex config space and MEM space :-(

[0.994011] OF: PCI: host bridge /soc/pcie@5000 ranges:
[0.999721] OF: PCI: Parsing ranges property...
[1.004386] OF: PCI:   MEM 0x5000..0x5fff -> 0x
[1.010471] pci-host-generic 5000.pcie:
can't claim ECAM area [mem 0x5000-0x5fff]:
address conflict with /soc/pcie@5000 [mem 
0x5000-0x5fff]
[1.025265] pci-host-generic: probe of 5000.pcie failed with error -16

pcie@5000 {
compatible = "pci-host-ecam-generic";
reg = <0x5000 0x1000>;
device_type = "pci";
#size-cells = <2>;
#address-cells = <3>;
#interrupt-cells = <1>;
ranges = <0x0200 0x0 0x0  0x5000  0x0 
0x1000>;
};

Regards.
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

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 vmalloc address...
>>
> [1.272248] pgd = c0004000
> [1.275060] [d08664f4] *pgd=8f804811, *pte=, *ppte=
> [1.281476] Internal error: Oops: 7 [#1] PREEMPT SMP ARM
> [1.286897] Modules linked in:
> [1.290053] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 4.9.7-1-rc2 #151
> [1.296696] Hardware name: Sigma Tango DT
> [1.300808] task: cf82c9c0 task.stack: cf838000
> [1.305446] PC is at quirk_usb_early_handoff+0x3e8/0x790
> [1.310873] LR is at ioremap_page_range+0xf8/0x1a8
> [1.315771] pc : []lr : []psr: 000e0013
> [1.315771] sp : cf839d78  ip :   fp : cf839e38
> [1.327482] r10: c10248a0  r9 :   r8 : d08664f4
> [1.332816] r7 : d084e000  r6 : 2000  r5 : 000c0300  r4 : cfb5f800
> [1.339460] r3 : 000184f4  r2 :   r1 : 91001e13  r0 : d084e000
>>
>> ...and that specifically it's r0 + r3...
>>
 [1.258926] Unable to handle kernel paging request at virtual address 
 d0863f70
 [1.266284] pgd = c0004000
 [1.269097] [d0863f70] *pgd=8f804811, *pte=, *ppte=
 [1.275512] Internal error: Oops: 7 [#1] PREEMPT SMP ARM
 [1.280933] Modules linked in:
 [1.284089] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 4.9.7-1-rc2 #157
 [1.290732] Hardware name: Sigma Tango DT
 [1.294843] task: cf82c9c0 task.stack: cf838000
 [1.299482] PC is at quirk_usb_early_handoff+0x3e8/0x790
 [1.304907] LR is at ioremap_page_range+0xf8/0x1a8
 [1.309806] pc : []lr : []psr: 000e0013
 [1.309806] sp : cf839d78  ip :   fp : cf839e38
 [1.321517] r10: c10248a0  r9 :   r8 : d0863f70
 [1.326851] r7 : d084e000  r6 : 2000  r5 : 000c0300  r4 : cfb52800
 [1.333495] r3 : 00015f70  r2 :   r1 : 91001e13  r0 : d084e000
>>
>> ...and again...
>>
>>> [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] Internal error: Oops: 7 [#1] PREEMPT SMP ARM
>>> [1.283815] Modules linked in:
>>> [1.286970] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 4.9.7-1-rc2 #157
>>> [1.293614] Hardware name: Sigma Tango DT
>>> [1.297726] task: cf82c9c0 task.stack: cf838000
>>> [1.302364] PC is at quirk_usb_early_handoff+0x3e8/0x790
>>> [1.307790] LR is at ioremap_page_range+0xf8/0x1a8
>>> [1.312688] pc : []lr : []psr: 000e0013
>>> [1.312688] sp : cf839d78  ip :   fp : cf839e38
>>> [1.324399] r10: c10248a0  r9 :   r8 : d08611e4
>>> [1.329733] r7 : d084e000  r6 : 2000  r5 : 000c0300  r4 : cfb4e800
>>> [1.336377] r3 : 000131e4  r2 :   r1 : 91001e13  r0 : d084e000
>>
>> ...and again. And always at the same PC, too. Looking at
>> quirk_usb_early_handoff(), it mostly seems to go off poking bridge
>> resources, so I'd hazard a guess that it's down to your host driver,
>> with something uninitialised (or already freed) being used as an offset
>> into some ioremapped resource (which given the consistency of r0 is
>> probably allocated pretty early on).
>>
>> "addr2line -i -e vmlinux c039fe44", and work backwards from there ;)
>> In particular I'd follow the provenance of r3.
> 
> Starting from a fresh panic:
> 
> [1.236243] pcieport :00:00.0: enabling device (0140 -> 0142)
> [1.242474] pcieport :00:00.0: enabling bus mastering
> [1.248147] pci :01:00.0: calling quirk_usb_early_handoff+0x0/0x790
> [1.254904] pci :01:00.0: enabling device (0140 -> 0142)
> [1.260719] Unable to handle kernel paging request at virtual address 
> d08509f8
> [1.268073] pgd = c0004000
> [1.270874] [d08509f8] *pgd=8f804811, *pte=, *ppte=
> [1.277282] Internal error: Oops: 7 [#1] PREEMPT SMP ARM
> [1.282702] Modules linked in:
> [1.285858] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 4.9.7-1-rc2 #2
> [1.292327] Hardware name: Sigma Tango DT
> [1.296438] task: cf82c9c0 task.stack: cf838000
> [1.301076] PC is at quirk_usb_early_handoff+0x3e8/0x790
> [1.306501] LR is at ioremap_page_range+0xf8/0x1a8
> [1.311400] pc : []lr : []psr: 000e0013
> [1.311400] sp : cf839d78  ip :   fp : cf839e38
> [1.323110] r10: c10248a0  r9 :   r8 : d08509f8
> [1.328444] r7 : d084e000  r6 : 2000  r5 : 000c0300  r4 : cfb5f800
> [1.335087] r3 : 29f8  r2 :   r1 : 91001e13  r0 : d084e000
> [1.341732] Flags: nzcv  IRQs on  FIQs on  Mode SVC_32  ISA ARM  Segment 
> none

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 = ioremap_nocache(pci_resource_start(pdev, 0), len);
> 
> Could I be passing garbage to ioremap_nocache?

Oh...

I have just now understood what Ard wrote a few days ago.

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.

I was specifying an arbitrary address for the memory space,
which doesn't make any sense, as Ard pointed out.

So quirk_usb_handoff_xhci would ioremap(0x9100, 8192)
which is the size of the USB device's memory region, but
0x9100 is an address in system RAM. Thus, the readl
was actually picking up random garbage in RAM, which
makes xhci_find_next_ext_cap blow up pretty fast.

[1.265224] xhci_find_next_ext_cap: offset=0xec44

I'm off to fix my blunder.

Regards.
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

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
 [1.275060] [d08664f4] *pgd=8f804811, *pte=, *ppte=
 [1.281476] Internal error: Oops: 7 [#1] PREEMPT SMP ARM
 [1.286897] Modules linked in:
 [1.290053] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 4.9.7-1-rc2 #151
 [1.296696] Hardware name: Sigma Tango DT
 [1.300808] task: cf82c9c0 task.stack: cf838000
 [1.305446] PC is at quirk_usb_early_handoff+0x3e8/0x790
 [1.310873] LR is at ioremap_page_range+0xf8/0x1a8
 [1.315771] pc : []lr : []psr: 000e0013
 [1.315771] sp : cf839d78  ip :   fp : cf839e38
 [1.327482] r10: c10248a0  r9 :   r8 : d08664f4
 [1.332816] r7 : d084e000  r6 : 2000  r5 : 000c0300  r4 : cfb5f800
 [1.339460] r3 : 000184f4  r2 :   r1 : 91001e13  r0 : d084e000
> 
> ...and that specifically it's r0 + r3...
> 
>>> [1.258926] Unable to handle kernel paging request at virtual address 
>>> d0863f70
>>> [1.266284] pgd = c0004000
>>> [1.269097] [d0863f70] *pgd=8f804811, *pte=, *ppte=
>>> [1.275512] Internal error: Oops: 7 [#1] PREEMPT SMP ARM
>>> [1.280933] Modules linked in:
>>> [1.284089] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 4.9.7-1-rc2 #157
>>> [1.290732] Hardware name: Sigma Tango DT
>>> [1.294843] task: cf82c9c0 task.stack: cf838000
>>> [1.299482] PC is at quirk_usb_early_handoff+0x3e8/0x790
>>> [1.304907] LR is at ioremap_page_range+0xf8/0x1a8
>>> [1.309806] pc : []lr : []psr: 000e0013
>>> [1.309806] sp : cf839d78  ip :   fp : cf839e38
>>> [1.321517] r10: c10248a0  r9 :   r8 : d0863f70
>>> [1.326851] r7 : d084e000  r6 : 2000  r5 : 000c0300  r4 : cfb52800
>>> [1.333495] r3 : 00015f70  r2 :   r1 : 91001e13  r0 : d084e000
> 
> ...and again...
> 
>> [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] Internal error: Oops: 7 [#1] PREEMPT SMP ARM
>> [1.283815] Modules linked in:
>> [1.286970] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 4.9.7-1-rc2 #157
>> [1.293614] Hardware name: Sigma Tango DT
>> [1.297726] task: cf82c9c0 task.stack: cf838000
>> [1.302364] PC is at quirk_usb_early_handoff+0x3e8/0x790
>> [1.307790] LR is at ioremap_page_range+0xf8/0x1a8
>> [1.312688] pc : []lr : []psr: 000e0013
>> [1.312688] sp : cf839d78  ip :   fp : cf839e38
>> [1.324399] r10: c10248a0  r9 :   r8 : d08611e4
>> [1.329733] r7 : d084e000  r6 : 2000  r5 : 000c0300  r4 : cfb4e800
>> [1.336377] r3 : 000131e4  r2 :   r1 : 91001e13  r0 : d084e000
> 
> ...and again. And always at the same PC, too. Looking at
> quirk_usb_early_handoff(), it mostly seems to go off poking bridge
> resources, so I'd hazard a guess that it's down to your host driver,
> with something uninitialised (or already freed) being used as an offset
> into some ioremapped resource (which given the consistency of r0 is
> probably allocated pretty early on).
> 
> "addr2line -i -e vmlinux c039fe44", and work backwards from there ;)
> In particular I'd follow the provenance of r3.

Starting from a fresh panic:

[1.236243] pcieport :00:00.0: enabling device (0140 -> 0142)
[1.242474] pcieport :00:00.0: enabling bus mastering
[1.248147] pci :01:00.0: calling quirk_usb_early_handoff+0x0/0x790
[1.254904] pci :01:00.0: enabling device (0140 -> 0142)
[1.260719] Unable to handle kernel paging request at virtual address 
d08509f8
[1.268073] pgd = c0004000
[1.270874] [d08509f8] *pgd=8f804811, *pte=, *ppte=
[1.277282] Internal error: Oops: 7 [#1] PREEMPT SMP ARM
[1.282702] Modules linked in:
[1.285858] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 4.9.7-1-rc2 #2
[1.292327] Hardware name: Sigma Tango DT
[1.296438] task: cf82c9c0 task.stack: cf838000
[1.301076] PC is at quirk_usb_early_handoff+0x3e8/0x790
[1.306501] LR is at ioremap_page_range+0xf8/0x1a8
[1.311400] pc : []lr : []psr: 000e0013
[1.311400] sp : cf839d78  ip :   fp : cf839e38
[1.323110] r10: c10248a0  r9 :   r8 : d08509f8
[1.328444] r7 : d084e000  r6 : 2000  r5 : 000c0300  r4 : cfb5f800
[1.335087] r3 : 29f8  r2 :   r1 : 91001e13  r0 : d084e000
[1.341732] Flags: nzcv  IRQs on  FIQs on  Mode SVC_32  ISA ARM  Segment none
[1.348987] Control: 10c5387d  Table: 8faa004a  DAC: 0051
[1.354844] Process swapper/0 (pid: 1, stack limit = 0xcf838210)
[1.360963] Stack: (0xcf839d78 to

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.
> 
> Does gcc ever use the link register as a general purpose register?

Yes.

> (In which case, it is very likely to contain "garbage" as far as
> function addresses are concerned.)
> 
>> Educating people about the architecture's calling convention and
>> associated caveats is not the job of the panic handler.
> 
> That's a weird statement.
> 

By your own admission (in various threads and in #armlinux on IRC), you are not 
an expert in the topics you seek help about. Yet, that does not seem to stop 
you from sharing your opinions vocally, how 'weird' or 'useless' some things 
are.

As for the lr, I attempted to explain that in some cases, annotating its value 
can be useful. Adding an explanation to or letting the panic handler reason 
about whether this is currently the case is not so useful imo.--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

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 paging request at virtual address 
> d08611e4
> [1.269167] pgd = c0004000
> [1.271979] [d08611e4] *pgd=8f804811, *pte=, *ppte=
> [1.278394] Internal error: Oops: 7 [#1] PREEMPT SMP ARM
> [1.283815] Modules linked in:
> [1.286970] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 4.9.7-1-rc2 #157
> [1.293614] Hardware name: Sigma Tango DT
> [1.297726] task: cf82c9c0 task.stack: cf838000
> [1.302364] PC is at quirk_usb_early_handoff+0x3e8/0x790
> [1.307790] LR is at ioremap_page_range+0xf8/0x1a8
> [1.312688] pc : []lr : []psr: 000e0013
> [1.312688] sp : cf839d78  ip :   fp : cf839e38
> [1.324399] r10: c10248a0  r9 :   r8 : d08611e4
> [1.329733] r7 : d084e000  r6 : 2000  r5 : 000c0300  r4 : cfb4e800
> [1.336377] r3 : 000131e4  r2 :   r1 : 91001e13  r0 : d084e000
 
 ...and again. And always at the same PC, too.
>>> 
>>> By the way, isn't LR supposed to point to the caller of the
>>> current function? ("LR is at ioremap_page_range")
>>> 
>>> If so, why does it not appear in the back trace?
>> 
>> lr is supposed to point to the return address at function entry. After
>> that, all bets are off, really, since ARM usually pops the return
>> address from the stack straight into the pc register. So in this case,
>> it looks like it still contains the address that the most recent leaf
>> function returned to (or another function that actually restores the
>> return address into lr before branching to it). But it could easily
>> contain garbage as well.
> 
> If there is only a tiny chance that LR contains genuinely useful
> information, then what is the rationale for providing the info
> at all in the panic message?
> 
> I would argue that no info is better than info that is wrong
> most of the time.
> 

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.

Educating people about the architecture's calling convention and associated 
caveats is not the job of the panic handler.

--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

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 which case, it is very likely to contain "garbage" as far as
function addresses are concerned.)

> Educating people about the architecture's calling convention and
> associated caveats is not the job of the panic handler.

That's a weird statement.

Regards.
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

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
 [1.271979] [d08611e4] *pgd=8f804811, *pte=, *ppte=
 [1.278394] Internal error: Oops: 7 [#1] PREEMPT SMP ARM
 [1.283815] Modules linked in:
 [1.286970] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 4.9.7-1-rc2 #157
 [1.293614] Hardware name: Sigma Tango DT
 [1.297726] task: cf82c9c0 task.stack: cf838000
 [1.302364] PC is at quirk_usb_early_handoff+0x3e8/0x790
 [1.307790] LR is at ioremap_page_range+0xf8/0x1a8
 [1.312688] pc : []lr : []psr: 000e0013
 [1.312688] sp : cf839d78  ip :   fp : cf839e38
 [1.324399] r10: c10248a0  r9 :   r8 : d08611e4
 [1.329733] r7 : d084e000  r6 : 2000  r5 : 000c0300  r4 : cfb4e800
 [1.336377] r3 : 000131e4  r2 :   r1 : 91001e13  r0 : d084e000
>>>
>>> ...and again. And always at the same PC, too.
>>
>> By the way, isn't LR supposed to point to the caller of the
>> current function? ("LR is at ioremap_page_range")
>>
>> If so, why does it not appear in the back trace?
> 
> lr is supposed to point to the return address at function entry. After
> that, all bets are off, really, since ARM usually pops the return
> address from the stack straight into the pc register. So in this case,
> it looks like it still contains the address that the most recent leaf
> function returned to (or another function that actually restores the
> return address into lr before branching to it). But it could easily
> contain garbage as well.

If there is only a tiny chance that LR contains genuinely useful
information, then what is the rationale for providing the info
at all in the panic message?

I would argue that no info is better than info that is wrong
most of the time.

Regards.
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

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
> >>> [1.269167] pgd = c0004000
> >>> [1.271979] [d08611e4] *pgd=8f804811, *pte=, *ppte=
> >>> [1.278394] Internal error: Oops: 7 [#1] PREEMPT SMP ARM
> >>> [1.283815] Modules linked in:
> >>> [1.286970] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 4.9.7-1-rc2 #157
> >>> [1.293614] Hardware name: Sigma Tango DT
> >>> [1.297726] task: cf82c9c0 task.stack: cf838000
> >>> [1.302364] PC is at quirk_usb_early_handoff+0x3e8/0x790
> >>> [1.307790] LR is at ioremap_page_range+0xf8/0x1a8
> >>> [1.312688] pc : []lr : []psr: 000e0013
> >>> [1.312688] sp : cf839d78  ip :   fp : cf839e38
> >>> [1.324399] r10: c10248a0  r9 :   r8 : d08611e4
> >>> [1.329733] r7 : d084e000  r6 : 2000  r5 : 000c0300  r4 : cfb4e800
> >>> [1.336377] r3 : 000131e4  r2 :   r1 : 91001e13  r0 : d084e000
> >>
> >> ...and again. And always at the same PC, too.
> >
> > By the way, isn't LR supposed to point to the caller of the
> > current function? ("LR is at ioremap_page_range")
> >
> > If so, why does it not appear in the back trace?
> >
> 
> lr is supposed to point to the return address at function entry. After
> that, all bets are off, really, since ARM usually pops the return
> address from the stack straight into the pc register. So in this case,
> it looks like it still contains the address that the most recent leaf
> function returned to (or another function that actually restores the
> return address into lr before branching to it). But it could easily
> contain garbage as well.

Besides, the compiler often inlines static subroutines that are called
from only one place.  As a result there is no hardware stack frame for 
these subroutine calls, and they don't show up in the back trace.

Alan Stern

--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

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] *pgd=8f804811, *pte=, *ppte=
>>> [1.278394] Internal error: Oops: 7 [#1] PREEMPT SMP ARM
>>> [1.283815] Modules linked in:
>>> [1.286970] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 4.9.7-1-rc2 #157
>>> [1.293614] Hardware name: Sigma Tango DT
>>> [1.297726] task: cf82c9c0 task.stack: cf838000
>>> [1.302364] PC is at quirk_usb_early_handoff+0x3e8/0x790
>>> [1.307790] LR is at ioremap_page_range+0xf8/0x1a8
>>> [1.312688] pc : []lr : []psr: 000e0013
>>> [1.312688] sp : cf839d78  ip :   fp : cf839e38
>>> [1.324399] r10: c10248a0  r9 :   r8 : d08611e4
>>> [1.329733] r7 : d084e000  r6 : 2000  r5 : 000c0300  r4 : cfb4e800
>>> [1.336377] r3 : 000131e4  r2 :   r1 : 91001e13  r0 : d084e000
>>
>> ...and again. And always at the same PC, too.
>
> By the way, isn't LR supposed to point to the caller of the
> current function? ("LR is at ioremap_page_range")
>
> If so, why does it not appear in the back trace?
>

lr is supposed to point to the return address at function entry. After
that, all bets are off, really, since ARM usually pops the return
address from the stack straight into the pc register. So in this case,
it looks like it still contains the address that the most recent leaf
function returned to (or another function that actually restores the
return address into lr before branching to it). But it could easily
contain garbage as well.
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

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] Internal error: Oops: 7 [#1] PREEMPT SMP ARM
>> [1.283815] Modules linked in:
>> [1.286970] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 4.9.7-1-rc2 #157
>> [1.293614] Hardware name: Sigma Tango DT
>> [1.297726] task: cf82c9c0 task.stack: cf838000
>> [1.302364] PC is at quirk_usb_early_handoff+0x3e8/0x790
>> [1.307790] LR is at ioremap_page_range+0xf8/0x1a8
>> [1.312688] pc : []lr : []psr: 000e0013
>> [1.312688] sp : cf839d78  ip :   fp : cf839e38
>> [1.324399] r10: c10248a0  r9 :   r8 : d08611e4
>> [1.329733] r7 : d084e000  r6 : 2000  r5 : 000c0300  r4 : cfb4e800
>> [1.336377] r3 : 000131e4  r2 :   r1 : 91001e13  r0 : d084e000
> 
> ...and again. And always at the same PC, too.

By the way, isn't LR supposed to point to the caller of the
current function? ("LR is at ioremap_page_range")

If so, why does it not appear in the back trace?

[1.541152] [] (quirk_usb_early_handoff) from [] 
(pci_do_fixups+0xc8/0x158)
[1.549992] [] (pci_do_fixups) from [] 
(pci_bus_add_device+0x18/0x90)
[1.558301] [] (pci_bus_add_device) from [] 
(pci_bus_add_devices+0x3c/0x80)
[1.567133] [] (pci_bus_add_devices) from [] 
(pci_bus_add_devices+0x70/0x80)
[1.576055] [] (pci_bus_add_devices) from [] 
(pci_host_common_probe+0xfc/0x324)
[1.585243] [] (pci_host_common_probe) from [] 
(platform_drv_probe+0x34/0x7c)

Regards.
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

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 again. And always at the same PC, too. Looking at
> quirk_usb_early_handoff(), it mostly seems to go off poking bridge
> resources, so I'd hazard a guess that it's down to your host driver,
> with something uninitialised (or already freed) being used as an offset
> into some ioremapped resource (which given the consistency of r0 is
> probably allocated pretty early on).

When you say "host driver", do you mean the USB driver,
or the PCIe controller driver?

I am currently writing the PCIe controller driver, so I do
expect a large number of bugs there; but the USB driver is
just the generic XHCI driver. Although I now realize that
I wrote no DT node for the USB HW... Would that explain
the random weirdness?

> "addr2line -i -e vmlinux c039fe44", and work backwards from there ;) In
> particular I'd follow the provenance of r3.

I'll definitely take a closer look. Thanks for the disassembly.

Regards.
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

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=, *ppte=
>>> [1.281476] Internal error: Oops: 7 [#1] PREEMPT SMP ARM
>>> [1.286897] Modules linked in:
>>> [1.290053] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 4.9.7-1-rc2 #151
>>> [1.296696] Hardware name: Sigma Tango DT
>>> [1.300808] task: cf82c9c0 task.stack: cf838000
>>> [1.305446] PC is at quirk_usb_early_handoff+0x3e8/0x790
>>> [1.310873] LR is at ioremap_page_range+0xf8/0x1a8
>>> [1.315771] pc : []lr : []psr: 000e0013
>>> [1.315771] sp : cf839d78  ip :   fp : cf839e38
>>> [1.327482] r10: c10248a0  r9 :   r8 : d08664f4
>>> [1.332816] r7 : d084e000  r6 : 2000  r5 : 000c0300  r4 : cfb5f800
>>> [1.339460] r3 : 000184f4  r2 :   r1 : 91001e13  r0 : d084e000

...and that specifically it's r0 + r3...

[...]
>> [1.258926] Unable to handle kernel paging request at virtual address 
>> d0863f70
>> [1.266284] pgd = c0004000
>> [1.269097] [d0863f70] *pgd=8f804811, *pte=, *ppte=
>> [1.275512] Internal error: Oops: 7 [#1] PREEMPT SMP ARM
>> [1.280933] Modules linked in:
>> [1.284089] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 4.9.7-1-rc2 #157
>> [1.290732] Hardware name: Sigma Tango DT
>> [1.294843] task: cf82c9c0 task.stack: cf838000
>> [1.299482] PC is at quirk_usb_early_handoff+0x3e8/0x790
>> [1.304907] LR is at ioremap_page_range+0xf8/0x1a8
>> [1.309806] pc : []lr : []psr: 000e0013
>> [1.309806] sp : cf839d78  ip :   fp : cf839e38
>> [1.321517] r10: c10248a0  r9 :   r8 : d0863f70
>> [1.326851] r7 : d084e000  r6 : 2000  r5 : 000c0300  r4 : cfb52800
>> [1.333495] r3 : 00015f70  r2 :   r1 : 91001e13  r0 : d084e000

...and again...

[...]
> [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] Internal error: Oops: 7 [#1] PREEMPT SMP ARM
> [1.283815] Modules linked in:
> [1.286970] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 4.9.7-1-rc2 #157
> [1.293614] Hardware name: Sigma Tango DT
> [1.297726] task: cf82c9c0 task.stack: cf838000
> [1.302364] PC is at quirk_usb_early_handoff+0x3e8/0x790
> [1.307790] LR is at ioremap_page_range+0xf8/0x1a8
> [1.312688] pc : []lr : []psr: 000e0013
> [1.312688] sp : cf839d78  ip :   fp : cf839e38
> [1.324399] r10: c10248a0  r9 :   r8 : d08611e4
> [1.329733] r7 : d084e000  r6 : 2000  r5 : 000c0300  r4 : cfb4e800
> [1.336377] r3 : 000131e4  r2 :   r1 : 91001e13  r0 : d084e000

...and again. And always at the same PC, too. Looking at
quirk_usb_early_handoff(), it mostly seems to go off poking bridge
resources, so I'd hazard a guess that it's down to your host driver,
with something uninitialised (or already freed) being used as an offset
into some ioremapped resource (which given the consistency of r0 is
probably allocated pretty early on).

"addr2line -i -e vmlinux c039fe44", and work backwards from there ;) In
particular I'd follow the provenance of r3.

Robin.
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

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 working on
>> the PCIe support, so I may be responsible for the crash by virtue
>> of something I did or didn't do (e.g. I haven't set up the IRQs
>> correctly, but I didn't think it would crash the system).
>>
>> [0.987520] OF: PCI: host bridge /soc/pcie@5000 ranges:
>> [0.993236] OF: PCI:   No bus range found for /soc/pcie@5000, using 
>> [bus 00-ff]
>> [1.001034] OF: PCI: Parsing ranges property...
>> [1.005693] OF: PCI:   MEM 0x9000..0x9fff -> 0x9000
>> [1.014791] pci-host-generic 5000.pcie: ECAM at [mem 
>> 0x5000-0x5fff] for [bus 00-ff]
>> [1.028570] pci-host-generic 5000.pcie: PCI host bridge to bus :00
>> [1.035597] pci_bus :00: root bus resource [bus 00-ff]
>> [1.041212] pci_bus :00: root bus resource [mem 0x9000-0x9fff]
>> [1.048219] pci_bus :00: scanning bus
>> [1.052376] pci :00:00.0: [1105:0024] type 01 class 0x048000
>> [1.058529] pci :00:00.0: calling tango_pcie_fixup_class+0x0/0x10
>> [1.065119] pci :00:00.0: reg 0x10: [mem 0x-0x00ff 64bit]
>> [1.072068] pci :00:00.0: calling pci_fixup_ide_bases+0x0/0x40
>> [1.078415] pci :00:00.0: supports D1 D2
>> [1.082803] pci :00:00.0: PME# supported from D0 D1 D2 D3hot
>> [1.088937] pci :00:00.0: PME# disabled
>> [1.093445] pci_bus :00: fixups for bus
>> [1.097753] PCI: bus0: Fast back to back transfers disabled
>> [1.103453] pci :00:00.0: scanning [bus 00-00] behind bridge, pass 0
>> [1.110286] pci :00:00.0: bridge configuration invalid ([bus 00-00]), 
>> reconfiguring
>> [1.118433] pci :00:00.0: scanning [bus 00-00] behind bridge, pass 1
>> [1.125385] pci_bus :01: scanning bus
>> [1.129557] pci :01:00.0: [1912:0014] type 00 class 0x0c0330
>> [1.135727] pci :01:00.0: reg 0x10: [mem 0x-0x1fff 64bit]
>> [1.142730] pci :01:00.0: calling pci_fixup_ide_bases+0x0/0x40
>> [1.149150] pci :01:00.0: PME# supported from D0 D3hot D3cold
>> [1.155375] pci :01:00.0: PME# disabled
>> [1.159976] pci_bus :01: fixups for bus
>> [1.164305] PCI: bus1: Fast back to back transfers disabled
>> [1.170002] pci_bus :01: bus scan returning with max=01
>> [1.175701] pci_bus :01: busn_res: [bus 01-ff] end is updated to 01
>> [1.182447] pci_bus :00: bus scan returning with max=01
>> [1.188147] pci :00:00.0: fixup irq: got 0
>> [1.192707] pci :00:00.0: assigning IRQ 00
>> [1.197294] pci :01:00.0: fixup irq: got 20
>> [1.201945] pci :01:00.0: assigning IRQ 20
>> [1.206533] pci :00:00.0: BAR 0: assigned [mem 0x9000-0x90ff 
>> 64bit]
>> [1.213984] pci :00:00.0: BAR 8: assigned [mem 0x9100-0x910f]
>> [1.220908] pci :01:00.0: BAR 0: assigned [mem 0x9100-0x91001fff 
>> 64bit]
>> [1.228363] pci :00:00.0: PCI bridge to [bus 01]
>> [1.233449] pci :00:00.0:   bridge window [mem 0x9100-0x910f]
>> [1.240419] pcieport :00:00.0: enabling device (0140 -> 0142)
>> [1.246648] pcieport :00:00.0: enabling bus mastering
>> [1.252321] pci :01:00.0: calling quirk_usb_early_handoff+0x0/0x790
>> [1.259077] pci :01:00.0: enabling device (0140 -> 0142)
>> [1.264893] Unable to handle kernel paging request at virtual address 
>> d08664f4
>> [1.272248] pgd = c0004000
>> [1.275060] [d08664f4] *pgd=8f804811, *pte=, *ppte=
>> [1.281476] Internal error: Oops: 7 [#1] PREEMPT SMP ARM
>> [1.286897] Modules linked in:
>> [1.290053] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 4.9.7-1-rc2 #151
>> [1.296696] Hardware name: Sigma Tango DT
>> [1.300808] task: cf82c9c0 task.stack: cf838000
>> [1.305446] PC is at quirk_usb_early_handoff+0x3e8/0x790
>> [1.310873] LR is at ioremap_page_range+0xf8/0x1a8
>> [1.315771] pc : []lr : []psr: 000e0013
>> [1.315771] sp : cf839d78  ip :   fp : cf839e38
>> [1.327482] r10: c10248a0  r9 :   r8 : d08664f4
>> [1.332816] r7 : d084e000  r6 : 2000  r5 : 000c0300  r4 : cfb5f800
>> [1.339460] r3 : 000184f4  r2 :   r1 : 91001e13  r0 : d084e000
>> [1.346105] Flags: nzcv  IRQs on  FIQs on  Mode SVC_32  ISA ARM  Segment 
>> none
>> [1.353361] Control: 10c5387d  Table: 8fa9c04a  DAC: 0051
>> [1.359218] Process swapper/0 (pid: 1, stack limit = 0xcf838210)
>> [1.365339] Stack: (0xcf839d78 to 0xcf83a000)
>> [1.369800] 9d60:   
>> c058f578 c058b180
>> [1.378107] 9d80: cfb55240 cf839d98 c0350218 c05adccc

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 responsible for the crash by virtue
> of something I did or didn't do (e.g. I haven't set up the IRQs
> correctly, but I didn't think it would crash the system).
> 
> [0.987520] OF: PCI: host bridge /soc/pcie@5000 ranges:
> [0.993236] OF: PCI:   No bus range found for /soc/pcie@5000, using 
> [bus 00-ff]
> [1.001034] OF: PCI: Parsing ranges property...
> [1.005693] OF: PCI:   MEM 0x9000..0x9fff -> 0x9000
> [1.014791] pci-host-generic 5000.pcie: ECAM at [mem 
> 0x5000-0x5fff] for [bus 00-ff]
> [1.028570] pci-host-generic 5000.pcie: PCI host bridge to bus :00
> [1.035597] pci_bus :00: root bus resource [bus 00-ff]
> [1.041212] pci_bus :00: root bus resource [mem 0x9000-0x9fff]
> [1.048219] pci_bus :00: scanning bus
> [1.052376] pci :00:00.0: [1105:0024] type 01 class 0x048000
> [1.058529] pci :00:00.0: calling tango_pcie_fixup_class+0x0/0x10
> [1.065119] pci :00:00.0: reg 0x10: [mem 0x-0x00ff 64bit]
> [1.072068] pci :00:00.0: calling pci_fixup_ide_bases+0x0/0x40
> [1.078415] pci :00:00.0: supports D1 D2
> [1.082803] pci :00:00.0: PME# supported from D0 D1 D2 D3hot
> [1.088937] pci :00:00.0: PME# disabled
> [1.093445] pci_bus :00: fixups for bus
> [1.097753] PCI: bus0: Fast back to back transfers disabled
> [1.103453] pci :00:00.0: scanning [bus 00-00] behind bridge, pass 0
> [1.110286] pci :00:00.0: bridge configuration invalid ([bus 00-00]), 
> reconfiguring
> [1.118433] pci :00:00.0: scanning [bus 00-00] behind bridge, pass 1
> [1.125385] pci_bus :01: scanning bus
> [1.129557] pci :01:00.0: [1912:0014] type 00 class 0x0c0330
> [1.135727] pci :01:00.0: reg 0x10: [mem 0x-0x1fff 64bit]
> [1.142730] pci :01:00.0: calling pci_fixup_ide_bases+0x0/0x40
> [1.149150] pci :01:00.0: PME# supported from D0 D3hot D3cold
> [1.155375] pci :01:00.0: PME# disabled
> [1.159976] pci_bus :01: fixups for bus
> [1.164305] PCI: bus1: Fast back to back transfers disabled
> [1.170002] pci_bus :01: bus scan returning with max=01
> [1.175701] pci_bus :01: busn_res: [bus 01-ff] end is updated to 01
> [1.182447] pci_bus :00: bus scan returning with max=01
> [1.188147] pci :00:00.0: fixup irq: got 0
> [1.192707] pci :00:00.0: assigning IRQ 00
> [1.197294] pci :01:00.0: fixup irq: got 20
> [1.201945] pci :01:00.0: assigning IRQ 20
> [1.206533] pci :00:00.0: BAR 0: assigned [mem 0x9000-0x90ff 
> 64bit]
> [1.213984] pci :00:00.0: BAR 8: assigned [mem 0x9100-0x910f]
> [1.220908] pci :01:00.0: BAR 0: assigned [mem 0x9100-0x91001fff 
> 64bit]
> [1.228363] pci :00:00.0: PCI bridge to [bus 01]
> [1.233449] pci :00:00.0:   bridge window [mem 0x9100-0x910f]
> [1.240419] pcieport :00:00.0: enabling device (0140 -> 0142)
> [1.246648] pcieport :00:00.0: enabling bus mastering
> [1.252321] pci :01:00.0: calling quirk_usb_early_handoff+0x0/0x790
> [1.259077] pci :01:00.0: enabling device (0140 -> 0142)
> [1.264893] Unable to handle kernel paging request at virtual address 
> d08664f4
> [1.272248] pgd = c0004000
> [1.275060] [d08664f4] *pgd=8f804811, *pte=, *ppte=
> [1.281476] Internal error: Oops: 7 [#1] PREEMPT SMP ARM
> [1.286897] Modules linked in:
> [1.290053] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 4.9.7-1-rc2 #151
> [1.296696] Hardware name: Sigma Tango DT
> [1.300808] task: cf82c9c0 task.stack: cf838000
> [1.305446] PC is at quirk_usb_early_handoff+0x3e8/0x790
> [1.310873] LR is at ioremap_page_range+0xf8/0x1a8
> [1.315771] pc : []lr : []psr: 000e0013
> [1.315771] sp : cf839d78  ip :   fp : cf839e38
> [1.327482] r10: c10248a0  r9 :   r8 : d08664f4
> [1.332816] r7 : d084e000  r6 : 2000  r5 : 000c0300  r4 : cfb5f800
> [1.339460] r3 : 000184f4  r2 :   r1 : 91001e13  r0 : d084e000
> [1.346105] Flags: nzcv  IRQs on  FIQs on  Mode SVC_32  ISA ARM  Segment 
> none
> [1.353361] Control: 10c5387d  Table: 8fa9c04a  DAC: 0051
> [1.359218] Process swapper/0 (pid: 1, stack limit = 0xcf838210)
> [1.365339] Stack: (0xcf839d78 to 0xcf83a000)
> [1.369800] 9d60:   
> c058f578 c058b180
> [1.378107] 9d80: cfb55240 cf839d98 c0350218 c05adccc cfb5f800 c05adcdc 
> cf838000 
> [1.386413] 9da0:  c10248a0 cf839e38 c030bfa4 cf923b80 c034e69c 
>