> 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
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 =
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?
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 th
[+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 vmall
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
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.2750
> 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
> 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 virtu
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
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
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 = c
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=0
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] Intern
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
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=
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 worki
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 res
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 di
19 matches
Mail list logo
