Re: Recent commits reject RPi4B booting: pcib0 vs. pcib1 "rman_manage_region: request" leads to panic

2024-02-09 Thread Bakul Shah
$ 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:

Recent commits reject RPi4B booting: pcib0 vs. pcib1 "rman_manage_region: request" leads to panic

2024-02-09 Thread Mark Millard
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: . .

Re: FreeBSD panics possibly caused by nfs clients

2024-02-09 Thread Rick Macklem
On Fri, Feb 9, 2024 at 10:23 AM Matthew L. Dailey wrote: > > I had my first kernel panic with a KASAN kernel after only 01:27. This > first panic was a "double fault," which isn't anything we've seen > previously - usually we've seen trap 9 or trap 12, but sometimes others. > Based on the

Re: FreeBSD panics possibly caused by nfs clients

2024-02-09 Thread Mark Johnston
On Fri, Feb 09, 2024 at 10:11:14PM +, Matthew L. Dailey wrote: > On 2/9/24 4:18 PM, Mark Johnston wrote: > > [You don't often get email from ma...@freebsd.org. Learn why this is > > important at https://aka.ms/LearnAboutSenderIdentification ] > > > > On Fri, Feb 09, 2024 at 06:23:08PM +,

Re: FreeBSD panics possibly caused by nfs clients

2024-02-09 Thread Rick Macklem
On Fri, Feb 9, 2024 at 2:04 PM Zaphod Beeblebrox wrote: > > Just in case it's relevant, I'm carrying around this patch on my fairly busy > little RISC-V machine. > > diff --git a/sys/fs/nfsclient/nfs_clvnops.c b/sys/fs/nfsclient/nfs_clvnops.c > index 0b8c587a542c..85c0ebd7a10f 100644 > ---

Re: FreeBSD panics possibly caused by nfs clients

2024-02-09 Thread Matthew L. Dailey
On 2/9/24 4:18 PM, Mark Johnston wrote: > [You don't often get email from ma...@freebsd.org. Learn why this is > important at https://aka.ms/LearnAboutSenderIdentification ] > > On Fri, Feb 09, 2024 at 06:23:08PM +, Matthew L. Dailey wrote: >> I had my first kernel panic with a KASAN

Re: FreeBSD panics possibly caused by nfs clients

2024-02-09 Thread Zaphod Beeblebrox
Just in case it's relevant, I'm carrying around this patch on my fairly busy little RISC-V machine. diff --git a/sys/fs/nfsclient/nfs_clvnops.c b/sys/fs/nfsclient/nfs_clvnops.c index 0b8c587a542c..85c0ebd7a10f 100644 --- a/sys/fs/nfsclient/nfs_clvnops.c +++ b/sys/fs/nfsclient/nfs_clvnops.c @@

Re: FreeBSD panics possibly caused by nfs clients

2024-02-09 Thread Mark Johnston
On Fri, Feb 09, 2024 at 06:23:08PM +, Matthew L. Dailey wrote: > I had my first kernel panic with a KASAN kernel after only 01:27. This > first panic was a "double fault," which isn't anything we've seen > previously - usually we've seen trap 9 or trap 12, but sometimes others. > Based on

Re: FreeBSD panics possibly caused by nfs clients

2024-02-09 Thread Matthew L. Dailey
I had my first kernel panic with a KASAN kernel after only 01:27. This first panic was a "double fault," which isn't anything we've seen previously - usually we've seen trap 9 or trap 12, but sometimes others. Based on the backtrace, it definitely looks like KASAN caught something, but I don't

Re: FreeBSD panics possibly caused by nfs clients

2024-02-09 Thread Matthew L. Dailey
On 2/9/24 11:04 AM, Mark Johnston wrote: > [You don't often get email from ma...@freebsd.org. Learn why this is > important at https://aka.ms/LearnAboutSenderIdentification ] > > On Thu, Feb 08, 2024 at 03:34:52PM +, Matthew L. Dailey wrote: >> Good morning all, >> >> Per Rick Macklem's

Re: FreeBSD panics possibly caused by nfs clients

2024-02-09 Thread Mark Johnston
On Thu, Feb 08, 2024 at 03:34:52PM +, Matthew L. Dailey wrote: > Good morning all, > > Per Rick Macklem's suggestion, I'm posting this query here in the hopes > that other may have ideas. > > We did do some minimal testing with ufs around this problem back in > August, but hadn't narrowed