RE: Chromium with Widevine: kernel panic: condition vp-> v_type == VDIR || VN_IS_DOOMED(vp) not met ⋯vfs_cache.c:34 52 (vn_fullpath_dir)

trap.c:235 #3 #4 0x000103257cf6 in ?? () Backtrace stopped: Cannot access memory at address 0x100a359f0 a non-gdb backtrace provided looks like, for example: . . . fpcurthread = 0xf801083aa000: pid 5562 "htop" idlethread = 0xf80001c7c740: tid 17 "idle: cpu4" . .

Re: panic in zfs/nvlist

On Thu, Sep 05, 2024 at 12:53:52PM -0400, Alexander Motin wrote: A> Hi Gleb, A> A> Could you check if this is relevant: A> https://github.com/openzfs/zfs/pull/16505 ? Yes! This is exactly the patch I am writing right now :) I will cherry-pick that to FreeBSD/main. -- Gleb Smirnoff

Re: panic in zfs/nvlist

Hi Gleb, Could you check if this is relevant: https://github.com/openzfs/zfs/pull/16505 ? On 05.09.2024 12:41, Gleb Smirnoff wrote: got instant panic at start of userland on todays main: --- trap 0x9, rip = 0x8039fd8d, rsp = 0xfe021a59c8c8, rbp = 0xfe021a59c8e0

panic in zfs/nvlist

Hi, got instant panic at start of userland on todays main: --- trap 0x9, rip = 0x8039fd8d, rsp = 0xfe021a59c8c8, rbp = 0xfe021a59c8e0 --- spl_nvlist_empty() at spl_nvlist_empty+0x3d/frame 0xfe021a59c8e0 zfsdev_ioctl_common() at zfsdev_ioctl_common+0x78d/frame

Re: Panic on GENERIC @ 6481b4

boot on a thinkpad x230. >>> >>> > I had the same issue. I rebuilt/reinstalled the >>> graphics/gpu-firmware-kmod and >>> > graphics/drm-515-kmod ports. After a reboot, all was well. >>> >>> Cool, thanks Shawn! >>> >>> Should we

Re: Panic on GENERIC @ 6481b4

/gpu-firmware-kmod and >> > graphics/drm-515-kmod ports. After a reboot, all was well. >> >> Cool, thanks Shawn! >> >> Should we put an entry in UPDATING when current will panic without the >> latest drm-kmod, or some other type of instruction somewhere? >>

Re: Panic on GENERIC @ 6481b4

urrent/generic from July 11th after a `make cleanworld` panics on > bare metal boot on a thinkpad x230. > > > I had the same issue. I rebuilt/reinstalled the > graphics/gpu-firmware-kmod and > > graphics/drm-515-kmod ports. After a reboot, all was well. > > Cool, thanks Shawn

Re: Panic on GENERIC @ 6481b4

e metal boot on a thinkpad x230. > I had the same issue. I rebuilt/reinstalled the graphics/gpu-firmware-kmod and > graphics/drm-515-kmod ports. After a reboot, all was well. Cool, thanks Shawn! Should we put an entry in UPDATING when current will panic without the latest drm-kmod, or som

Re: Panic on GENERIC @ 6481b4

p, so I don't have a > dump. Here is the trace: > > db> bt > Tracing pid 21935 tid 100228 td 0xf90006d0e000 > kdb_enter() at kdb_enter+0x33/ frame 0xfe00d70541d0 > panic() at panic+0x43/frame 0xfe00d7054230 > malloc_init() at malloc_init+0xf7/f

Panic on GENERIC @ 6481b4

tid 100228 td 0xf90006d0e000 kdb_enter() at kdb_enter+0x33/ frame 0xfe00d70541d0 panic() at panic+0x43/frame 0xfe00d7054230 malloc_init() at malloc_init+0xf7/frame 0xfe00d7054560 linker_load_module() at linker_load_module+0xc23/ frame 0xfe00d7054560 linker_load_dependencies() at linker_load

Re: 13.3 14.x panic in qlogic isp vm_fault_lookup: fault on nofault entry, addr: 0xfffffe0127d22000

  > Subject: 13.3 14.x panic in qlogic isp vm_fault_lookup: fault on nofault entry, addr: 0xfe0127d22000 > 13.2 works.   13.3 and 14.x panic.     13.3 iso will work if load ispfw first (escape to loader, unload kernel, load ispfw, load kernel, boot) also, adding    ispfw_loa

Panic testing ZFS raidz expansion feature.

isk2.img" disk3_type="virtio-blk" disk3_name="disk3.img" uuid="ff66b6cc-459e-11ef-92b1-c86000cc94af" network0_mac="58:9c:fc:0a:ad:da" # vm start fbsd15-bis in the VM: # zpool create tank raidz1 vtbd1 vtbd2 # zpool attach tank raidz1-0 vtbd3 p

13.3 14.x panic in qlogic isp vm_fault_lookup: fault on nofault entry, addr: 0xfffffe0127d22000

  13.2 works.   13.3 and 14.x panic.   an older system with two qlogic isp cards, isp0 and isp1, nothing attached to them, and it panics on boot with 13.3 and 14.x images. 13.2 works         Autoloading module: ichsmb ichsmb0: port 0x300-0x31f irq 22 at device 31.3 on pci0 smbus0: on

Re: panic: lock "tmpfsni" 0xfffff80721307090 already initialized

On Sat, May 25, 2024 at 1:32 AM Alexander Leidinger wrote: > > Hi, > > [123095] panic: lock "tmpfsni" 0xf80721307090 already initialized > [123095] cpuid = 8 > [123095] time = 1716597585 > [123095] KDB: stack backtrace: > [123095] db_trace_self_wrapper() a

panic: lock "tmpfsni" 0xfffff80721307090 already initialized

Hi, [123095] panic: lock "tmpfsni" 0xf80721307090 already initialized [123095] cpuid = 8 [123095] time = 1716597585 [123095] KDB: stack backtrace: [123095] db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xfe08285c9690 [123095] vpanic() at vpanic+0

Chromium with Widevine: kernel panic: condition vp->v_type == VDIR || VN_IS_DOOMED(vp) not met ⋯vfs_cache.c:3452 (vn_fullpath_dir)

Reproducible at .

Re: Panic: lock "lnxspin" 0xfffff800176c0730 already initialized

On Fri, May 17, 2024 at 08:00:05AM +0200, Emmanuel Vadot wrote: > ... > Indeed, even if I know that I tested with GENERIC and amdgpu I think > that I've only tested GENERIC-NODEBUG with i915kms. > Anyway, I've pushed both patches now. Sorry for the breakage. > > Cheers, > Success: g1-70(

Re: Panic: lock "lnxspin" 0xfffff800176c0730 already initialized

t; two different laptops, each of which has both Nvidia & Intel graphics > > > > (but for the older one (M4800), I stopped using (& building) the > > > > Nvidia driver, since enabling it appears to disable GLX). > > > > > > > > Anyway: photos of

Re: Panic: lock "lnxspin" 0xfffff800176c0730 already initialized

ilding) the > > > Nvidia driver, since enabling it appears to disable GLX). > > > > > > Anyway: photos of the backtraces are at > > > https://www.catwhisker.org/~david/FreeBSD/head/n270174/ > > > as are copies of the build typescripts. >

Re: Panic: lock "lnxspin" 0xfffff800176c0730 already initialized

https://www.catwhisker.org/~david/FreeBSD/head/n270174/ > > as are copies of the build typescripts. > > > > Unfortunately, the panic message itself had (just) scrolled off the > > top at the time I took the photos, but I hand-typed it (from the > > M4800) in the Su

Re: Panic: lock "lnxspin" 0xfffff800176c0730 already initialized

00), I stopped using (& building) the > Nvidia driver, since enabling it appears to disable GLX). > > Anyway: photos of the backtraces are at > https://www.catwhisker.org/~david/FreeBSD/head/n270174/ > as are copies of the build typescripts. > > Unfortunately, the panic messa

Panic: lock "lnxspin" 0xfffff800176c0730 already initialized

tos of the backtraces are at https://www.catwhisker.org/~david/FreeBSD/head/n270174/ as are copies of the build typescripts. Unfortunately, the panic message itself had (just) scrolled off the top at the time I took the photos, but I hand-typed it (from the M4800) in the Subject. Peace,

Resolved: Panic after update main-n269202-4e7aa03b7076 -> n269230-f6f67f58c19d

After the update to main-n269261-1e6db7be6921, head built & booted OK. FreeBSD 15.0-CURRENT #45 main-n269261-1e6db7be6921: Wed Apr 10 11:11:50 UTC 2024 r...@freebeast.catwhisker.org:/common/S4/obj/usr/src/amd64.amd64/sys/GENERIC amd64 1500018 1500018 Peace, david -- David H. Wolfskill

Re: Panic after update main-n269202-4e7aa03b7076 -> n269230-f6f67f58c19d

latest commits (see below, just for the r > ec > > ord and to prevent > > F> being wrong here). > > F> > > F> [...] > > F> commit 841cf52595b6a6b98e266b63e54a7cf6fb6ca73e (HEAD -> main, origin/ma > in > > , origin/HEAD) > > > >

Re: Panic after update main-n269202-4e7aa03b7076 -> n269230-f6f67f58c19d

On Tue, Apr 09, 2024 at 07:02:11PM +0200, FreeBSD User wrote: F> The crash is still present on the most recent checked out sources as of minutes ago. F> I just checked out on HEAD the latest commits (see below, just for the record and to prevent F> being wrong here). F> F> [...] F> commit 841cf5

Re: Panic after update main-n269202-4e7aa03b7076 -> n269230-f6f67f58c19d

D ELF64, nlm_syscall), rip = 0x3f00a2dfd2a, rsp = > 0x3f00 > D> 96f7168, rbp = 0x3f0096f7230 --- > D> KDB: enter: panic > D> [ thread pid 1208 tid 101107 ] > D> Stopped at kdb_enter+0x33: movq$0,0x104eb92(%rip) > D> db> > > This should be fixe

Re: Panic after update main-n269202-4e7aa03b7076 -> n269230-f6f67f58c19d

On Tue, Apr 09, 2024 at 09:18:49AM -0700, Gleb Smirnoff wrote: > ... > D> db> > > This should be fixed by just pushed e205fd318a296ffdb7392486cdcec7f660fcffcf. Thanks! :-) > Sorry for that! > Glad it's idenitfied & addressed. [Sorry for delay; commute this morning was a bit more turbulen

Re: Panic after update main-n269202-4e7aa03b7076 -> n269230-f6f67f58c19d

00 D> amd64_syscall() at amd64_syscall+0x158/frame 0xfe048c204f30 D> fast_syscall_common() at fast_syscall_common+0xf8/frame 0xfe048c204f30 D> --- syscall (154, FreeBSD ELF64, nlm_syscall), rip = 0x3f00a2dfd2a, rsp = 0x3f00 D> 96f7168, rbp = 0x3f0096f7230 --- D> KDB: enter: panic D>

Re: Panic after update main-n269202-4e7aa03b7076 -> n269230-f6f67f58c19d

gt; > = DPL 0, pres 1, long 1, def32 0, gran 1 > > > processor eflags= interrupt enabled, resume, IOPL = 0 > > > current process = 1208 (rpc.Starting automountd. > > > lockd) > > > rdi: rsi: f8

Re: Panic after update main-n269202-4e7aa03b7076 -> n269230-f6f67f58c19d

ess = 1208 (rpc.Starting automountd. > > lockd) > > rdi: rsi: f801078b0740 rdx: > > rcx: 010a r8: 818d30f0 r9: > > rax: rbx: Starting powerd.0018 rbp: &g

Re: Panic after update main-n269202-4e7aa03b7076 -> n269230-f6f67f58c19d

si: f801078b0740 rdx: > rcx: 010a r8: 818d30f0 r9: > rax: rbx: Starting powerd.0018 rbp: > fe048c204960 > r10: 0001 r11: 0001 r12: f80274e32c18 > r13: 010a r

Panic after update main-n269202-4e7aa03b7076 -> n269230-f6f67f58c19d

18 rbp: fe048c204960 r10: 0001 r11: 0001 r12: f80274e32c18 r13: 010a r14: f80274e32c00 r15: 812ae38a trap number = 12 panic: page fault cpuid = 9 time = 1712662362 KDB: stack backtrace: db_trace_self_wrapper() at db_trace_self_wrapper+

CURRENT 220ee18f1964 memstick kernel panic, MacBookPro8,3

Originally posted to Photograph:

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

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 > chang

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

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

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

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 b

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

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

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

[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.

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

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 simpl

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

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

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

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 Hmmm, I suspect this is due to the way that bus_translate_resource works which is

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

in wrote: >>>>>>> >>>>>>>> On 2/9/24 8:13 PM, Mark Millard wrote: >>>>>>>>> Summary: >>>>>>>>> pcib0: mem >>>>>>>>> 0x7d50-0x7d50930f irq 80,81 on simplebus2 >>&g

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

;>>>> On Feb 12, 2024, at 09:32, John Baldwin wrote: >>>>>> >>>>>>> On 2/9/24 8:13 PM, Mark Millard wrote: >>>>>>>> Summary: >>>>>>>> pcib0: mem >>>>>>>> 0x7d500000-0x7d50930f

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

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 Hmmm, I suspect this is due to the way that bus_translate_resource works which is

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

>>>> > >>>>> 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

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

: 0x4000 . . . rman_manage_region: request: start 0x6, end 0x6000f panic: Failed to add resource to rman Hmmm, I suspect this is due to the way that bus_translate_resource works which is fundamentally broken. It rewrites the start address of a resource in-situ instead of keeping

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

>>>>> pcib0: mem >>>>>> 0x7d50-0x7d50930f irq 80,81 on simplebus2 >>>>>> pcib0: parsing FDT for ECAM0: >>>>>> pcib0: PCI addr: 0xc000, CPU addr: 0x6, Size: 0x4000 >>>>>> . . . >>

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

ebus2 >>>>> 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 re

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

: 0x4000 >>>> . . . >>>> rman_manage_region: request: start 0x6, end >>>> 0x6000f >>>> panic: Failed to add resource to rman >>> >>> Hmmm, I suspect this is due to the way that bus_translate_resource works >>>

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

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 n

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

t; 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 >>> 0x60

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

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 would

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

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 'l

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

dr: 0x6, Size: 0x4000 >> . . . >> rman_manage_region: request: start 0x6, end >> 0x6000f >> panic: Failed to add resource to rman > > Hmmm, I suspect this is due to the way that bus_translate_resource works > which is > fundamentally broken. It rewrites the s

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

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

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

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

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

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

Kernel Panic sys/netinet/tcp_subr.c 2386

Hi, I just got a kernel panic on my 15.0-CURRENT machine, with an Assertion in sys/netinet/tcp_subr.c 2386 full log: https://people.freebsd.org/~wosch/tmp/kernel-panic-tcp_subr-line-2386.png OS: 15.0-CURRENT main-3e9515846f (10-Feb-2024, github.com/freebsd/freebsd-src) Should I worry

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

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

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

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 >&g

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

dr: 0xc000, CPU addr: 0x6, Size: 0x4000 > . . > rman_manage_region: request: start 0x60000, end > 0x6000f > panic: Failed to add resource to rman > > > Detail: > > > . . > pcib0: mem 0x7d50-0x7d50930f > irq 80,81 on simplebus2 > pcib0:

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

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: 15 & 14: ram_attach vs. its using regions_to_avail vs. "bus_alloc_resource" can lead to: panic("ram_attach: resource %d failed to attach", rid)

On Jan 12, 2024, at 09:57, Doug Rabson wrote: > On Sat, 30 Sept 2023 at 08:47, Mark Millard wrote: > ram_attach is based on regions_to_avail but that is a problem for > its later bus_alloc_resource use --and that can lead to: > > panic("ram_attach: resource %d fa

Re: 15 & 14: ram_attach vs. its using regions_to_avail vs. "bus_alloc_resource" can lead to: panic("ram_attach: resource %d failed to attach", rid)

On Sat, 30 Sept 2023 at 08:47, Mark Millard wrote: > ram_attach is based on regions_to_avail but that is a problem for > its later bus_alloc_resource use --and that can lead to: > > panic("ram_attach: resource %d failed to attach", rid); > > Unfortunately, the kno

Re: [resolved] After update to main-n266611-49a83b94395a: panic: bus_generic_rman_activate_resource

On Sat, 25 Nov 2023 12:16:49 -0800 David Wolfskill wrote: > On Sun, Nov 26, 2023 at 04:36:33AM +0900, Tomoaki AOKI wrote: > > Hi. > > > > Not tested, but does upgrading to commit ed88eef140a1 [1] and later > > help? (I'm still at commit 5d4f897f88ed on main.) > > > > [1] > > https://cgit.freebs

Re: [resolved] After update to main-n266611-49a83b94395a: panic: bus_generic_rman_activate_resource

On Sun, Nov 26, 2023 at 04:36:33AM +0900, Tomoaki AOKI wrote: > Hi. > > Not tested, but does upgrading to commit ed88eef140a1 [1] and later > help? (I'm still at commit 5d4f897f88ed on main.) > > [1] > https://cgit.freebsd.org/src/commit/?id=ed88eef140a1c3d57d546f409c216806dd3da809 > > Regards.

Re: After update to main-n266611-49a83b94395a: panic: bus_generic_rman_activate_resource

On Sun, Nov 26, 2023 at 04:36:33AM +0900, Tomoaki AOKI wrote: > Hi. > > Not tested, but does upgrading to commit ed88eef140a1 [1] and later > help? (I'm still at commit 5d4f897f88ed on main.) > > [1] > https://cgit.freebsd.org/src/commit/?id=ed88eef140a1c3d57d546f409c216806dd3da809 > > Regards.

Re: After update to main-n266611-49a83b94395a: panic: bus_generic_rman_activate_resource

ating to > main-n266588-2a35f3cdf63d.) > > Here's a backtrace: > > ... > Event timer "HPET6" frequency 14318180 Hz quality 340 > Event timer "HPET7" frequency 14318180 Hz quality 340 > panic: bus_generic_rman_activate_resource: rman 0x81b0b0e8

After update to main-n266611-49a83b94395a: panic: bus_generic_rman_activate_resource

cy 14318180 Hz quality 340 Event timer "HPET7" frequency 14318180 Hz quality 340 panic: bus_generic_rman_activate_resource: rman 0x81b0b0e8 doesn't match for resource 0xf801092b9280 cpuid = 20 time = 1 KDB: stack backtrace: db_trace_self_wrapper() at db_trace_self_wrapper+

Re: db> reset -> panic: acquiring blockable sleep lock with spinlock or critical section held ...

should (loaded word) eliminate this type of recursive panic during debugger reset. At least, that is the goal of the series :) I apologize for the delay on this, my ability to finish some of the work I've started has been spotty this year. Oh, no worries; I've been way worse

Re: HEADSUP: panic: running without device atpic requires a local APIC on UEFI systems after 0b01d45783c3

improvements of ACPI detection (e0f3dc82727f > > and 0b01d45783c3) would leave the system in an unbootable state if > the > > UEFI files are not being updated at the same time of "make > > installworld". At early boot the kernel would panic with: >

Re: HEADSUP: panic: running without device atpic requires a local APIC on UEFI systems after 0b01d45783c3

files are not being updated at the same time of "make installworld".  At early boot the kernel would panic with: panic: running without device atpic requires a local APIC on UEFI systems To recover a system in this state, at loader prompt, use: unset hint.acpi.

Re: HEADSUP: panic: running without device atpic requires a local APIC on UEFI systems after 0b01d45783c3

ld". At early boot the kernel would panic with: > > panic: running without device atpic requires a local APIC on UEFI systems > > To recover a system in this state, at loader prompt, use: > > unset hint.acpi.0.disabled > boot > > (I think core.lua should be modified

Re: HEADSUP: panic: running without device atpic requires a local APIC on UEFI systems after 0b01d45783c3

state if the > UEFI files are not being updated at the same time of "make > installworld". At early boot the kernel would panic with: > > panic: running without device atpic requires a local APIC on UEFI systems > > To recover a system in this state, at loader prompt, us

HEADSUP: panic: running without device atpic requires a local APIC on UEFI systems after 0b01d45783c3

Hi, It seems that the recent improvements of ACPI detection (e0f3dc82727f and 0b01d45783c3) would leave the system in an unbootable state if the UEFI files are not being updated at the same time of "make installworld". At early boot the kernel would panic with: panic: runni

Re: db> reset -> panic: acquiring blockable sleep lock with spinlock or critical section held ...

hile because of that. I likely dropped the ball on review and testing feedback. I posted what I believe to be the better fix just now, see https://reviews.freebsd.org/D42684. I will commit this ASAP along with some other tweaks to shutdown hooks which should (loaded word) eliminate this type of

Re: db> reset -> panic: acquiring blockable sleep lock with spinlock or critical section held ...

osted what I believe to be the better fix just now, see https://reviews.freebsd.org/D42684. I will commit this ASAP along with some other tweaks to shutdown hooks which should (loaded word) eliminate this type of recursive panic during debugger reset. At least, that is the goal of the se

Re: db> reset -> panic: acquiring blockable sleep lock with spinlock or critical section held ...

he first time ... We should perhaps make SCHEDULER_STOPPED() true when resetting from the debugger, since we can't make any assumptions about the state of the system (since we don't know how we got into DDB in the first place). Then the reset path here would behave as it does after a p

db> reset -> panic: acquiring blockable sleep lock with spinlock or critical section held ...

Stopped at kdb_alt_break_internal+0x180: str xzr, [x19, #896] db> reset panic: acquiring blockable sleep lock with spinlock or critical section held (sleep mutex) eventhandler @ /usr/src/sys/kern/subr_eventhandler.c:269 cpuid = 2 time = 307 KDB: stack backtrace: db_trace_self() at db_trace_self db_trace

Re: 14-ALPHA2 panic on cold boot

>> On Tuesday, August 29th, 2023 at 11:09 AM, cglogic >>> wrote: >>> >>>> Hello dear FreeBSD community, >>>> >>>> Recently I tried to boot from FreeBSD 14-ALPHA2 image and got panic on >>>> first boot after power on. >>&

Re: panic in cypto code

> On 6 Oct 2023, at 08:46, Steve Kargl > wrote: > > On Thu, Oct 05, 2023 at 03:11:02PM -0700, Steve Kargl wrote: >> >> I'll ping you off list when it's available. >> > > Well, this is interesting. I cannot upload the files to > a location from which I can then put them up on freefall. :(

Re: panic in cypto code

On Thu, Oct 05, 2023 at 03:11:02PM -0700, Steve Kargl wrote: > > I'll ping you off list when it's available. > Well, this is interesting. I cannot upload the files to a location from which I can then put them up on freefall. :( % scp -P1234 kernel.debug 10.95.76.21: kernel.debug

Re: panic in cypto code

penvpn. I normally leave the system running Xorg, > > and I would find the system in a "locked-up" blank-screen > > saver state. I assumed I was having a Xorg/drm-kmod problem, > > so I shut Xorg down last night. The above panic was waiting > > for me this m

Re: panic in cypto code

934c5349 rdx 0x53749f62934c5349 rbx 0xfe000e1cc200 >>> rcx 0x57bf32fec3cbde70 rsi 0x32e8db2f0591c5da rdi 0x832f0fb1e6d07eb0 >>> r8 0 r9 0 r10 0 >>> r11 0x60 r12 0x5af7589946bd13d9 r13 0xbeddd6a808e1dd54 >>> r14 0xcdf12bbf2708189c r15 0xeb262ae8536a7adf rflag

Re: panic in cypto code

8db2f0591c5da rdi 0x832f0fb1e6d07eb0 > > r8 0 r9 0 r10 0 > > r11 0x60 r12 0x5af7589946bd13d9 r13 0xbeddd6a808e1dd54 > > r14 0xcdf12bbf2708189c r15 0xeb262ae8536a7adf rflags 0x10246 > > cs 0x20 ss 0x28 ds 0x3b es 0x3b fs 0x13 gs 0x1b > > fsbase 0x1c02e381d120 gsbase 0x81a1 k

Re: panic in cypto code

0x20 ss 0x28 ds 0x3b es 0x3b fs 0x13 gs 0x1b > fsbase 0x1c02e381d120 gsbase 0x81a1 kgsbase 0 > cpuid = 0; apic id = 00 > panic: double fault > cpuid = 0 > time = 1696512769 > KDB: stack backtrace: > db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xff

panic in cypto code

r8 0 r9 0 r10 0 r11 0x60 r12 0x5af7589946bd13d9 r13 0xbeddd6a808e1dd54 r14 0xcdf12bbf2708189c r15 0xeb262ae8536a7adf rflags 0x10246 cs 0x20 ss 0x28 ds 0x3b es 0x3b fs 0x13 gs 0x1b fsbase 0x1c02e381d120 gsbase 0x81a1 kgsbase 0 cpuid = 0; apic id = 00 panic: double fault cpuid = 0 time

15 & 14: ram_attach vs. its using regions_to_avail vs. "bus_alloc_resource" can lead to: panic("ram_attach: resource %d failed to attach", rid)

ram_attach is based on regions_to_avail but that is a problem for its later bus_alloc_resource use --and that can lead to: panic("ram_attach: resource %d failed to attach", rid); Unfortunately, the known example is use of EDK2 on RPi4B class systems, not what is considered the supporte

Re: 14-ALPHA2 panic on cold boot

st 29th, 2023 at 11:09 AM, cglogic > wrote: > > Hello dear FreeBSD community, > > Recently I tried to boot from FreeBSD 14-ALPHA2 image and got panic on > first boot after power on. > My hardware is AMD Ryzen 9 5900X on ASUS ROG STRIX B550-E GAMING. > It's related to audi

Re: 14-ALPHA2 panic on cold boot

efore release. Thanks. --- Original Message --- On Monday, September 25th, 2023 at 11:26 AM, Santiago Martinez wrote: > Hi there, > FreeBSD 14.0-beta3 is now avail, have you tried it? > Also can you provide the dump or logs from the crash/panic? > Best regards. > > San

Re: 14-ALPHA2 panic on cold boot

Hi there, FreeBSD 14.0-beta3 is now avail, have you tried it? Also can you provide the dump or logs from the crash/panic? Best regards. Santi On 8/29/23 10:09, cglogic wrote: Hello dear FreeBSD community, Recently I tried to boot from FreeBSD 14-ALPHA2 image and got panic on first boot

Re: 14-ALPHA2 panic on cold boot

> On Tuesday, August 29th, 2023 at 11:09 AM, cglogic > wrote: > >> Hello dear FreeBSD community, >> >> Recently I tried to boot from FreeBSD 14-ALPHA2 image and got panic on first >> boot after power on. >> My hardware is AMD Ryzen 9 5900X on ASUS ROG

Re: kernel trap 12 .. cam_periph_release_locked_buses() panics under panic?

zy data corruption > or > > a weird traceback issue. > > No, we panic in wifi and then iterated again and again. > The first one is the lkpi_sta_auth_to_scan() panic. > Ah. OK. I don't think there's anything in cam_periph_release_locked_buses that could cause this... b

Re: kernel trap 12 .. cam_periph_release_locked_buses() panics under panic?

On Mon, 11 Sep 2023, Warner Losh wrote: That's a crazy traceback. We get a fatal trap and then call into the wifi stack? That makes no sense in the absence of some crazy data corruption or a weird traceback issue. No, we panic in wifi and then iterated again and again. The first one i

Re: kernel trap 12 .. cam_periph_release_locked_buses() panics under panic?

That's a crazy traceback. We get a fatal trap and then call into the wifi stack? That makes no sense in the absence of some crazy data corruption or a weird traceback issue. On Mon, Sep 11, 2023, 7:47 AM Bjoern A. Zeeb wrote: > Hi, > > had a kernel hitting an alll-to-known wifi i

kernel trap 12 .. cam_periph_release_locked_buses() panics under panic?

Hi, had a kernel hitting an alll-to-known wifi issue and panic (I was actually happy I could reproduce) and then the screen kept scrolling for a while panicing all over again and ddb was unusable (not so happy). I assume the problem is cam_periph_release_locked_buses()? /bz ... --- trap

Re: 14-ALPHA2 panic on cold boot

thout committers attention. --- Original Message --- On Tuesday, August 29th, 2023 at 11:09 AM, cglogic wrote: > Hello dear FreeBSD community, > > Recently I tried to boot from FreeBSD 14-ALPHA2 image and got panic on first > boot after power on. > My hardware is AMD Ryzen

Re: FreeBSD-15 kernel panic when the amdtemp device is in the kernel

On Sun, 03 Sep 2023 15:17:36 +0200 "Herbert J. Skuhra" wrote: [SNIP] > Probably best to file a PR: https://bugs.freebsd.org/bugzilla/ > Bugzilla 273543 -- Gary Jennejohn

Re: FreeBSD-15 kernel panic when the amdtemp device is in the kernel

On Sat, 02 Sep 2023 18:02:03 +0200, Gary Jennejohn wrote: > > On Sat, 02 Sep 2023 15:36:36 +0200 > "Herbert J. Skuhra" wrote: > > > On Fri, 01 Sep 2023 18:05:34 +0200, Gary Jennejohn wrote: > > > > > > On Fri, 1 Sep 2023 14:43:21 + > > > Gary Jennejohn wrote: > > > > > > > A git-bisect is p

Re: FreeBSD-15 kernel panic when the amdtemp device is in the kernel

On Sat, 02 Sep 2023 15:36:36 +0200 "Herbert J. Skuhra" wrote: > On Fri, 01 Sep 2023 18:05:34 +0200, Gary Jennejohn wrote: > > > > On Fri, 1 Sep 2023 14:43:21 + > > Gary Jennejohn wrote: > > > > > A git-bisect is probably required. > > > > > > > I did a bisect and the result was commit > > 9a

  1   2   3   4   5   6   7   8   9   10   >