Re: db> reset -> panic: acquiring blockable sleep lock with spinlock or critical section held ...
On 11/20/23 15:40, Bjoern A. Zeeb wrote: On Mon, 20 Nov 2023, Mitchell Horne wrote: Hi Mitchell, On 11/16/23 18:21, Bjoern A. Zeeb wrote: Hi, I seem to remember changes related to that a while ago but my cache is miss for the actual change. Are we suppoed to handle this case? It would be nice if "reset" would reset again the first time ... Hi Bjoern, This is still my fault, I am sorry to say. If you recall, I proposed a fix after your initial report (back in February!), see now that you say I do. I thought we had this all sorted. Cache miss, miss. Maybe I had a local patch and hadn't seen it for a while 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 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 this year. Thank you for stepping up working on this and the fixes. It is much appreciated! Bjoern You are welcome. FYI the fix has landed in main, 4e78a766f607. Mitchell
Re: db> reset -> panic: acquiring blockable sleep lock with spinlock or critical section held ...
On 11/16/23 18:21, Bjoern A. Zeeb wrote: Hi, I seem to remember changes related to that a while ago but my cache is miss for the actual change. Are we suppoed to handle this case? It would be nice if "reset" would reset again the first time ... Hi Bjoern, This is still my fault, I am sorry to say. If you recall, I proposed a fix after your initial report (back in February!), see https://reviews.freebsd.org/D38656. However, I held off on committing it because I had some more work to do in the area, and believed there was a more correct way to fix this edge-case. 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 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. Cheers, Mitchell KDB: enter: Break to debugger [ thread pid 11 tid 15 ] 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_self_wrapper() at db_trace_self_wrapper+0x38 vpanic() at vpanic+0x1a0 panic() at panic+0x48 witness_checkorder() at witness_checkorder+0xb4c __mtx_lock_flags() at __mtx_lock_flags+0xac eventhandler_find_list() at eventhandler_find_list+0x44 kern_reboot() at kern_reboot+0x284 db_reset() at db_reset+0xd8 db_command() at db_command+0x2e4 db_command_loop() at db_command_loop+0x58 db_trap() at db_trap+0x100 kdb_trap() at kdb_trap+0x364 handle_el1h_sync() at handle_el1h_sync+0x18 --- exception, esr 0xf200 kdb_alt_break_internal() at kdb_alt_break_internal+0x180 kdb_alt_break() at kdb_alt_break+0x10 uart_intr_rxready() at uart_intr_rxready+0x8c uart_intr() at uart_intr+0x120 intr_event_handle() at intr_event_handle+0xf4 intr_isrc_dispatch() at intr_isrc_dispatch+0x78 arm_gic_v3_intr() at arm_gic_v3_intr+0x120 intr_irq_handler() at intr_irq_handler+0x88 handle_el1h_irq() at handle_el1h_irq+0x14 --- interrupt cpu_idle() at cpu_idle+0x78 sched_idletd() at sched_idletd+0x4a0 fork_exit() at fork_exit+0x78 fork_trampoline() at fork_trampoline+0x18 KDB: enter: panic [ thread pid 11 tid 15 ] Stopped at kdb_enter+0x48: str xzr, [x19, #896] db> reset Uptime: 5m7s INFO: PSCI Power Domain Map:
Re: System lockups on 14-current with Plasma 5
On 7/3/23 18:20, Patrick McMunn wrote: I was just wondering if anyone else has experienced random freezes where everything except the mouse cursor becomes completely unresponsive. This began when I would come to my computer in the morning and find the screen black and the system in sleep mode. It would not wake up to keypresses or mouse movement. So I disabled power management in Plasma 5. This still happened after disabling power management, so I disabled the screensaver. That's when I would come to find my computer in the morning with the screen still on, but as soon as I would click on anything, everything but the cursor would freeze. At first, I thought it would happen only after being idle a long time. But then it began to happen while actively using the system after even a short time like less than an hour. It progressively became more frequent over a few days until it would happen immediately upon logging into Plasma 5. I originally installed 14-current onto a spare laptop hard drive that I installed on a secondary SATA port on my desktop just so I could test it. But after these issues occurred, I suspected a faulty hard drive and decided to install 14-current onto my main hard drive in a separate partition alongside Windows 10 and Gentoo. I went ahead and disabled sleep power management and the screensaver on the new installation. But I soon began to experience random lockups during use. I installed Gnome 3, LXQT, and Cinnamon desktops to try as alternatives. Maybe I haven't tested enough, but I have yet to experience any lockups with these other desktop environments. I had previously run Plasma 5 from quarterly on 13.2-release without any lockups. So maybe it's an issue with Plasma 5 from the latest repo. It's hard to know since there apparently is no quarterly repo available for 14-current. So it's unclear whether the issue is with the latest Plasma 5 or some compatibility issue with Plasma 5 on 14-current that I did not experience on 13.2-release. Hi, I experienced some similar symptoms a while back on -current with KDE. After some investigation I found that the system was panicking due to some failed debug assertion triggered by the nvidia graphics driver. As a result, the system would drop to the debugger, but was unable to switch virtual terminals, so it appeared to hang. My solution was just to start running the GENERIC-NODEBUG kernel instead. Does the system respond to network pings after the lock-up occurs? If not then perhaps you are experiencing this type of silent panic. You can set the debug.debugger_on_panic sysctl value to 0, which should result in an immediate reboot+kernel dump when such a panic occurs. Hope it helps. Mitchell
Re: Tooling Integration and Developer Experience
On 1/31/23 04:52, Stephane Rochoy wrote:
Mitchell Horne writes:
[Src] Needs Reviewer
https://reviews.freebsd.org/differential/query/65AoyPFlIhdE/
What is the purpose of the "Contributor Reviews (base)"
project/group?
Regards,
--
Stéphane Rochoy
O: Stormshield
It is a group ("Project") that anyone can join to receive notifications
whenever the group is tagged. Groups can be added as a reviewer on a
revision, for example.
There is a Herald rule to automatically add this Contributor Reviews
group as a subscriber to any src revisions that have no reviewers specified.
This makes it an imperfect search criteria for "reviews which are
accepted but not authored by a FreeBSD committer".
Mitchell
Re: Tooling Integration and Developer Experience
On 1/30/23 13:32, User Ngor wrote: On 1/30/23 13:53, Warner Losh wrote: On Mon, Jan 30, 2023 at 3:40 AM Kurt Jaeger wrote: Hi, On 1/30/23 02:54, Julian H. Stacey wrote: The main idea: to prevent information fragmentation and improve discoverability, cross-referencing abilities, search, etc. With regards to improving discoverability, Phabricator's Owner tool could be a good tactical move: it allow to bind code area to peoples in order to automatically add them to reviews. If you know phabricator in more detail, is there any kind of tool to understand the activity going on ? In bugs.freebsd.org, there is the dashboard: https://bugs.freebsd.org/bugzilla/page.cgi?id=dashboard.html I think we might need something similar to help us understand the current state of the phabricator instance and the work being done. Phab allows Dashboards, but no-one had the time to configure some queries to provide relevant stats. Phab is a terrible tool for discovery. For example, how do I query all the reviews I've ticked 'OK' that are still open, by non-committers? How do I flag things as 'interesting to me'? I can tick a flag, but I can't query flags. Also, I can't get an email address for submitter either. That makes it more of a pain to land the commit. You can search flags here [1]. You can filter them by color and the object (i.e. differential revision or any other Phab thing). Flags are personal and not visible to anybody else For common use I think tags are better and are queryable in here [2]. Tags require projects, projects can be created by administrators, this is a bit counter-intuitive, but it works For what it's worth, I experimented with creating some "useful" queries a little while back. The advanced search function was clunky to use, and really leaves a lot to be desired in terms of specificity. As mentioned elsewhere, no regex, and some of the things you can filter for when creating Herald rules are unavailable to the advanced search. Which is a shame, because overall I am a fan of phabricator as a review tool. Anyway, here they are (you can click Use Results to save it): [Src] Needs Committer https://reviews.freebsd.org/differential/query/oCjMrczXbpBS/ [Src] Needs Reviewer https://reviews.freebsd.org/differential/query/65AoyPFlIhdE/ [Src] Stale Revisions (1yr+) https://reviews.freebsd.org/differential/query/bGPGaIhtb0PX/ [Src] Stalled Revisions (changes required, changes planned, WIP) https://reviews.freebsd.org/differential/query/WD_lfbHCq1P_/ Mitchell But there's two other issues: The FreeBSD project has had a long history of being behind, regardless of the tools we use. There's a labor shortage to process these things as well. Second, lots of people want to talk, but few want to do the work. I tried leading an effort in this area,but grew weary of the passive-aggressive comments about how I basically sucked for not having it done already (from the same people that did 0 actual work on it). I'd love to help and do the grunt work. What is important is some form of consensus that project actually needs this. I don't know how this works, the is very little visibility from the Core on these matters. [1]https://reviews.freebsd.org/flag/ [2] https://reviews.freebsd.org/differential/query/advanced/
Re: make buildworld broken on RISC-V.
On Wed, Oct 6, 2021 at 7:23 AM Karel Gardas wrote:
>
>
> Hello,
>
> I'm using 14-CURRENT oprovided qcow2 image from September 30 in
> qemu-system-risc64. It runs fine so I'm testing it with attempting make
> buildworld. This unfortunately fails with:
>
> ===> lib/clang/headers (includes)
> [Creating objdir /usr/obj/usr/src/riscv.riscv64/lib/clang/headers...]
> clang-tblgen -gen-arm-bf16 -I
> /usr/src/contrib/llvm-project/clang/include/clang/Basic -d arm_bf16.h.d
> -o arm_bf16.h
> /usr/src/contrib/llvm-project/clang/include/clang/Basic/arm_bf16.td
> ELF binary type "0" not known.
> /usr/obj/usr/src/riscv.riscv64/tmp/legacy/usr/sbin/clang-tblgen: ELF�Т:
> not found
> /usr/obj/usr/src/riscv.riscv64/tmp/legacy/usr/sbin/clang-tblgen: @h�a@8:
> not found
> /usr/obj/usr/src/riscv.riscv64/tmp/legacy/usr/sbin/clang-tblgen: @@@0�:
> not found
> /usr/obj/usr/src/riscv.riscv64/tmp/legacy/usr/sbin/clang-tblgen: �: not
> found
> /usr/obj/usr/src/riscv.riscv64/tmp/legacy/usr/sbin/clang-tblgen: 1:
> Syntax error: "(" unexpected
> /usr/obj/usr/src/riscv.riscv64/tmp/legacy/usr/sbin/clang-tblgen: 5:
> Syntax error: Error in command substitution
> *** Error code 2
>
> Stop.
> make[5]: stopped in /usr/src/lib/clang/headers
> *** Error code 1
>
> Stop.
> make[4]: stopped in /usr/src/lib/clang
> *** Error code 1
>
> Stop.
> make[3]: stopped in /usr/src/lib
> *** Error code 1
>
> Stop.
> make[2]: stopped in /usr/src
>370.58 real 114.97 user 258.16 sys
> *** Error code 1
>
> Stop.
> make[1]: stopped in /usr/src
> *** Error code 1
>
> Stop.
> make: stopped in /usr/src
>
>
> I'm not sure which from available clang-tblgen is invoked:
>
> # find / -type f -name
> 'clang-tblgen'/usr/obj/usr/src/riscv.riscv64/tmp/legacy/bin/clang-tblgen
> /usr/obj/usr/src/riscv.riscv64/tmp/obj-tools/usr.bin/clang/clang-tblgen/clang-tblgen
>
>
> but both seems to be reasonable file types:
>
> root@freebsd:/usr/src/lib/clang/headers # file
> /usr/obj/usr/src/riscv.riscv64/tmp/legacy/bin/clang-tblgen
> /usr/obj/usr/src/riscv.riscv64/tmp/legacy/bin/clang-tblgen: ELF 64-bit
> LSB executable, UCB RISC-V, version 1 (SYSV), statically linked,
> FreeBSD-style, not stripped
> root@freebsd:/usr/src/lib/clang/headers # file
> /usr/obj/usr/src/riscv.riscv64/tmp/obj-tools/usr.bin/clang/clang-tblgen/clang-tblgen
> /usr/obj/usr/src/riscv.riscv64/tmp/obj-tools/usr.bin/clang/clang-tblgen/clang-tblgen:
> ELF 64-bit LSB executable, UCB RISC-V, version 1 (SYSV), statically
> linked, FreeBSD-style, not stripped
>
>
> Is there any trick how to solve this issue?
>
This has been reported here:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=258358
There is a workaround provided which allows the build to proceed, see
comment #4 and #6.
Cheers,
Mitchell
> Thanks,
> Karel
>
Re: RISC-V root device question -> Panic
On Mon, Dec 14, 2020 at 6:03 PM Michael Dexter wrote: > > Mitchell, > > On 12/7/20 1:56 PM, Mitchell Horne wrote: > > You can also override it using the QEMU commandline, which is simpler > > since you won't need to recompile anything. Adding the following > > argument should suffice: > > This works great but riscv 12-STABLE using last week's snapshot revision > throws the panic output included below under QEMU and leaves nothing in > /var/crash > > What expectations should I set for RISC-V STABLE and CURRENT? > Hi Michael, sorry for my delayed reply. Development and testing has been almost entirely focused on CURRENT. I believe riscv64 may have been functional on stable/12 at some point (and we even made an effort to MFC changes there), but it is not used anymore as far as I know. The expectations I would set going forward are that 13.0 will be the first functional release for the architecture (including stable/13 when it is branched), and stable/12 will remain unsupported. Also, to follow up on earlier items in this thread, I have documented how to generate a bootable RISC-V image containing an EFI partition with loader.efi. If you encounter any issues with the instructions, please let me know. https://wiki.freebsd.org/riscv/QEMU#Generate_a_root_filesystem Cheers, Mitchell > All the best, > > Michael > > t[0] == 0xffc0006c9d98 > t[1] == 0x40c5 > t[2] == 0x40c65000 > t[3] == 0x0001 > t[4] == 0x > t[5] == 0x0001 > t[6] == 0x0001 > s[0] == 0xffd0b1600248 > s[1] == 0x40e49000 > s[2] == 0xf000 > s[3] == 0x00ff > s[4] == 0x4100 > s[5] == 0x0001 > s[6] == 0xffc000aff988 > s[7] == 0x410a1000 > s[8] == 0x0280 > s[9] == 0x > s[10] == 0x1000 > s[11] == 0xff73 > a[0] == 0x > a[1] == 0xffd00297d560 > a[2] == 0x > a[3] == 0x0021 > a[4] == 0x > a[5] == 0x0021 > a[6] == 0x003f > a[7] == 0xffc000aff900 > sepc == 0xffc0004ce414 > sstatus == 0x0120 > panic: Fatal page fault at 0xffc0004ce414: 0x65 > cpuid = 1 > time = 1607915275 > KDB: stack backtrace: > #0 0xffc00023f2d4 at kdb_backtrace+0x50 > Uptime: 2d1h40m41s > Automatic reboot in 15 seconds - press a key on the console to abort > Rebooting... ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: RISC-V root device question
On Mon, Dec 7, 2020 at 6:28 PM Michael Dexter wrote: > > On 12/7/20 1:56 PM, Mitchell Horne wrote: > > As you suggest, it is possible to overwrite the default root device in > > the kernel config, by adding a line such as: > >options ROOTDEVNAME=\"ufs:/dev/vtbd0p3\" > > Thank you for the syntax! > > > You can also override it using the QEMU commandline, which is simpler > > since you won't need to recompile anything. Adding the following > > argument should suffice: > >-append="vfs.root.mountfrom=ufs:/dev/vtbd0p3" > > Note that you can set arbitrary kernel environment variables this way ^^ > > My string: > > qemu-system-riscv64 -machine virt -m 2048M -smp 2 -nographic -kernel > /vms/riscv/kernel -bios > /usr/local/share/opensbi/lp64/generic/firmware/fw_jump.elf > -append="vfs.root.mountfrom=ufs:/dev/vtbd0p3" -drive > file=$1,format=raw,id=hd0 -device virtio-blk-device,drive=hd0 -netdev > tap,ifname=tap0,script=no,id=net0 > > Reports: -append=vfs.root.mountfrom=ufs:/dev/vtbd0p3: invalid option > My bad, the extra '=' is a typo. It should be: -append "vfs.root.mountfrom=ufs:/dev/vtbd0p3" > I have tried it both there after ...elf and at the end of the string. Is > this perhaps the wrong position? > > > Finally, we do have support for loader.efi on RISC-V, although I have > > not yet documented how to use it on the wiki page. If you would like > > to try this method, please follow up with me and I can provide > > instructions. > > I am happy to if it is ready for public consumption. > Great, I will write that up soon. > > Otherwise, you can expect to see weekly RISC-V snapshots appear in the > > next week or two, and I will ensure that the wiki page is up to date > > with how to run them. > > Thank you and keep up the good work! > > Michael ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: RISC-V root device question
On Mon, Dec 7, 2020 at 4:54 PM Michael Dexter wrote: > > All, > > The FreeBSD wiki page on RISC-V reads: > > If you get mountroot prompt, then indicate to the kernel the location of > rootfs: > > mountroot> ufs:/dev/vtbd0 > > This indeed appears to be remain the case on CURRENT as of last week. > > Specifying a device and partition, or disklabel at the mountroot> prompt > works every time but none of these do not help in loader.conf (tested > individually): > > cam.boot_delay="10" > vfs.root.mountfrom="ufs:/dev/vtbd0p3" > vfs.root.mountfrom="ufs:/dev/gpt/rootfs" > rootdev="/dev/vtbd0p3" > rootdev="vtbd0p3" > currdev="vtbd0p3" > > Or these in the fstab: > > /dev/gpt/rootfs / ufs rw,noatime 1 1 > /dev/vtbd0p3 / ufs rw,noatime 1 1 > > Are there any other options? Perhaps building the device name into the > kernel? > > Thank you! > > Michael Hi Michael, If you have followed the directions on that wiki page exactly, then you have booted without FreeBSD's loader(8), and that is why your loader.conf variables are not taking effect. There are a couple solutions to this. As you suggest, it is possible to overwrite the default root device in the kernel config, by adding a line such as: options ROOTDEVNAME=\"ufs:/dev/vtbd0p3\" You can also override it using the QEMU commandline, which is simpler since you won't need to recompile anything. Adding the following argument should suffice: -append="vfs.root.mountfrom=ufs:/dev/vtbd0p3" Note that you can set arbitrary kernel environment variables this way ^^ Finally, we do have support for loader.efi on RISC-V, although I have not yet documented how to use it on the wiki page. If you would like to try this method, please follow up with me and I can provide instructions. Otherwise, you can expect to see weekly RISC-V snapshots appear in the next week or two, and I will ensure that the wiki page is up to date with how to run them. Cheers, Mitchell > ___ > freebsd-current@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org" ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: GCC 8.x or 9.x for FreeBSD rv64imafdc ??
On Tue, Nov 26, 2019 at 3:57 AM Dennis Clarke wrote: > > > > I will cross post this as there are very few options left. > > rv64imafdc folks : > > I will send this out to the only people and places that are likely to > not simply be a black hole from which nothing ever returns. However > most of my messages do just die on the mail lists with no reply from > anyone ever and that is very true for the gcc maillists for anything > RISC-V related. I wish I knew why. > > I am able to checkout and cross compile FreeBSD 13.0-CURRENT r354873 > however there is no compiler. I looked. The output destination rootfs > shows no signs of LLVM/Clang and certainly not gcc of any flavor. > > I do see wonderful things like : > > > https://github.com/freebsd-riscv/riscv-gcc/commit/be9abee2aaa919ad8530336569d17b5a60049717 > > > However nothing actually usable by any user out here in the more or less > real world that is not inside SiFive or similar. > > So is there any place at all that one may attain a compiler or am I left > to decipher the horrific mess that is known as the Canadian cross > compiler bootstrap which has never worked for me. > As of r354660, clang is built as part of buildworld. If you are using r354873 then you should have it as /usr/bin/clang, perhaps you just need to regenerate your rootfs. Cheers, Mitchell > -- > Dennis Clarke > RISC-V/SPARC/PPC/ARM/CISC > UNIX and Linux spoken > GreyBeard and suspenders optional > ___ > freebsd-current@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org" ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
