On Wed, Feb 14, 2024 at 06:19:04PM -0800, Mark Millard wrote:
> Your changes have the RPi4B that previously got the
> panic to boot all the way instead. Details:
>
> I have updated my pkg base environment to have the
> downloaded kernels (and kernel source) with your
> changes and have booted
On 2/14/24 11:03 PM, Mark Millard wrote:
On Feb 14, 2024, at 18:19, Mark Millard wrote:
Your changes have the RPi4B that previously got the
panic to boot all the way instead. Details:
I have updated my pkg base environment to have the
downloaded kernels (and kernel source) with your
changes
On Feb 14, 2024, at 18:19, Mark Millard wrote:
> Your changes have the RPi4B that previously got the
> panic to boot all the way instead. Details:
>
> I have updated my pkg base environment to have the
> downloaded kernels (and kernel source) with your
> changes and have booted with each of:
>
Your changes have the RPi4B that previously got the
panic to boot all the way instead. Details:
I have updated my pkg base environment to have the
downloaded kernels (and kernel source) with your
changes and have booted with each of:
/boot/kernel/kernel
/boot/kernel.GENERIC-NODEBUG/kernel
For
[Added at bottom: EDK2 notes referencing the non-ECAM compliant
PCie in the BCM2711.]
On Feb 14, 2024, at 10:23, John Baldwin wrote:
> On 2/14/24 10:16 AM, Mark Millard wrote:
>> Top posting a related but separate item:
>> I looked up some old (2022-Dec-17) lspci -v output from
>> a Linux boot.
Hey John,
On Wed, Feb 14, 2024 at 10:30 AM John Baldwin wrote:
> On 2/14/24 8:42 AM, Warner Losh wrote:
> > On Wed, Feb 14, 2024 at 9:08 AM John Baldwin wrote:
> >
> >> On 2/12/24 5:57 PM, Mark Millard wrote:
> >>> On Feb 12, 2024, at 16:36, Mark Millard wrote:
> >>>
> On Feb 12, 2024,
On 2/14/24 10:16 AM, Mark Millard wrote:
Top posting a related but separate item:
I looked up some old (2022-Dec-17) lspci -v output from
a Linux boot. Note the "Memory at" value 6 (in
the 35 bit BCM2711 address space) and the "(64-bit,
non-prefetchable)" (and "[size=4K]").
01:00.0 USB
On 2/14/24 9:57 AM, Mark Millard wrote:
On Feb 14, 2024, at 08:08, John Baldwin wrote:
On 2/12/24 5:57 PM, Mark Millard wrote:
On Feb 12, 2024, at 16:36, Mark Millard wrote:
On Feb 12, 2024, at 16:10, Mark Millard wrote:
On Feb 12, 2024, at 12:00, Mark Millard wrote:
[Gack: I was
Top posting a related but separate item:
I looked up some old (2022-Dec-17) lspci -v output from
a Linux boot. Note the "Memory at" value 6 (in
the 35 bit BCM2711 address space) and the "(64-bit,
non-prefetchable)" (and "[size=4K]").
01:00.0 USB controller: VIA Technologies, Inc.
On Feb 14, 2024, at 08:08, John Baldwin wrote:
> On 2/12/24 5:57 PM, Mark Millard wrote:
>> On Feb 12, 2024, at 16:36, Mark Millard wrote:
>>> On Feb 12, 2024, at 16:10, Mark Millard wrote:
>>>
On Feb 12, 2024, at 12:00, Mark Millard wrote:
> [Gack: I was looking at the wrong
On 2/14/24 8:42 AM, Warner Losh wrote:
On Wed, Feb 14, 2024 at 9:08 AM John Baldwin wrote:
On 2/12/24 5:57 PM, Mark Millard wrote:
On Feb 12, 2024, at 16:36, Mark Millard wrote:
On Feb 12, 2024, at 16:10, Mark Millard wrote:
On Feb 12, 2024, at 12:00, Mark Millard wrote:
[Gack: I
On Wed, Feb 14, 2024 at 9:08 AM John Baldwin wrote:
> On 2/12/24 5:57 PM, Mark Millard wrote:
> > On Feb 12, 2024, at 16:36, Mark Millard wrote:
> >
> >> On Feb 12, 2024, at 16:10, Mark Millard wrote:
> >>
> >>> On Feb 12, 2024, at 12:00, Mark Millard wrote:
> >>>
> [Gack: I was looking
On 2/12/24 5:57 PM, Mark Millard wrote:
On Feb 12, 2024, at 16:36, Mark Millard wrote:
On Feb 12, 2024, at 16:10, Mark Millard wrote:
On Feb 12, 2024, at 12:00, Mark Millard wrote:
[Gack: I was looking at the wrong vintage of source code, predating
your changes: wrong system used.]
On
On Feb 12, 2024, at 16:36, Mark Millard wrote:
> On Feb 12, 2024, at 16:10, Mark Millard wrote:
>
>> On Feb 12, 2024, at 12:00, Mark Millard wrote:
>>
>>> [Gack: I was looking at the wrong vintage of source code, predating
>>> your changes: wrong system used.]
>>>
>>>
>>> On Feb 12, 2024,
On Feb 12, 2024, at 16:10, Mark Millard wrote:
> On Feb 12, 2024, at 12:00, Mark Millard wrote:
>
>> [Gack: I was looking at the wrong vintage of source code, predating
>> your changes: wrong system used.]
>>
>>
>> On Feb 12, 2024, at 10:41, Mark Millard wrote:
>>
>>> On Feb 12, 2024, at
On Feb 12, 2024, at 12:00, Mark Millard wrote:
> [Gack: I was looking at the wrong vintage of source code, predating
> your changes: wrong system used.]
>
>
> On Feb 12, 2024, at 10:41, Mark Millard wrote:
>
>> On Feb 12, 2024, at 09:32, John Baldwin wrote:
>>
>>> On 2/9/24 8:13 PM, Mark
On Feb 12, 2024, at 10:02, John Kennedy wrote:
> On Mon, Feb 12, 2024 at 09:36:46AM -0800, John Baldwin wrote:
>> Without a stack trace it is pretty much impossible to debug a panic like
>> this.
>> Do you have KDB_TRACE enabled in your kernel config? I'm also not sure how
>> the
>> PCI
[Gack: I was looking at the wrong vintage of source code, predating
your changes: wrong system used.]
On Feb 12, 2024, at 10:41, Mark Millard wrote:
> On Feb 12, 2024, at 09:32, John Baldwin wrote:
>
>> On 2/9/24 8:13 PM, Mark Millard wrote:
>>> Summary:
>>> pcib0: mem
>>>
On 2/12/24 13:44, Michael Butler wrote:
On 2/12/24 12:36, John Baldwin wrote:
[ .. trimmed .. ]
Short of a stack trace, you can at least use lldb or gdb to lookup
the source line associated with the faulting instruction pointer (as
long as it isn't in a kernel module), e.g. for gdb you
On 2/12/24 12:36, John Baldwin wrote:
[ .. trimmed .. ]
Short of a stack trace, you can at least use lldb or gdb to lookup
the source line associated with the faulting instruction pointer (as
long as it isn't in a kernel module), e.g. for gdb you would use 'gdb
/boot/kernel/kernel' and then
On Feb 12, 2024, at 09:32, John Baldwin wrote:
> On 2/9/24 8:13 PM, Mark Millard wrote:
>> Summary:
>> pcib0: mem 0x7d50-0x7d50930f
>> irq 80,81 on simplebus2
>> pcib0: parsing FDT for ECAM0:
>> pcib0: PCI addr: 0xc000, CPU addr: 0x6, Size: 0x4000
>> . . .
>>
On 2/12/24 12:36, John Baldwin wrote:
On 2/10/24 2:09 PM, Michael Butler wrote:
I have stability problems with anything at or after this commit
(b377ff8) on an amd64 laptop. While I see the following panic logged, no
crash dump is preserved :-( It happens after ~5-6 minutes running in KDE
(X).
On 2/10/24 2:09 PM, Michael Butler wrote:
I have stability problems with anything at or after this commit
(b377ff8) on an amd64 laptop. While I see the following panic logged, no
crash dump is preserved :-( It happens after ~5-6 minutes running in KDE
(X).
Reverting to 36efc64 seems to work
On 2/9/24 8:13 PM, Mark Millard wrote:
Summary:
pcib0: mem 0x7d50-0x7d50930f
irq 80,81 on simplebus2
pcib0: parsing FDT for ECAM0:
pcib0: PCI addr: 0xc000, CPU addr: 0x6, Size: 0x4000
. . .
rman_manage_region: request: start 0x6, end
0x6000f
panic: Failed to
I have stability problems with anything at or after this commit
(b377ff8) on an amd64 laptop. While I see the following panic logged, no
crash dump is preserved :-( It happens after ~5-6 minutes running in KDE
(X).
Reverting to 36efc64 seems to work reliably (after ACPI changes but
before
On Feb 9, 2024, at 23:44, Bakul Shah wrote:
> $ git bisect good
> b377ff8110e3489eb6e6b920b51a2384dfc4eb0b is the first bad commit
>
>> On Feb 9, 2024, at 8:13 PM, Mark Millard wrote:
>>
>> Summary:
>>
>> pcib0: mem 0x7d50-0x7d50930f
>> irq 80,81 on simplebus2
>> pcib0: parsing FDT
$ git bisect good
b377ff8110e3489eb6e6b920b51a2384dfc4eb0b is the first bad commit
> On Feb 9, 2024, at 8:13 PM, Mark Millard wrote:
>
> Summary:
>
> pcib0: mem 0x7d50-0x7d50930f
> irq 80,81 on simplebus2
> pcib0: parsing FDT for ECAM0:
> pcib0: PCI addr: 0xc000, CPU addr:
Summary:
pcib0: mem 0x7d50-0x7d50930f
irq 80,81 on simplebus2
pcib0: parsing FDT for ECAM0:
pcib0: PCI addr: 0xc000, CPU addr: 0x6, Size: 0x4000
. .
rman_manage_region: request: start 0x6, end
0x6000f
panic: Failed to add resource to rman
Detail:
. .
28 matches
Mail list logo
