Re: ACPI0007 ? Anyone know what it is?
ACPI0007 is the hardware ID of a device node that represents a processor device (there are two ways to do this -- either by declaring a Processor node in the device tree, or by declaring a standard device with HID ACPI0007). It's not used to discover processors by OSes because typically that is done well before the AML interpreter is brought online. Instead it is used to describe how to control processor performance and thermal management (what ACPI calls C-states, P-states, and T-states on older systems, or CPPC on newer systems). How processors are discovered is platform dependent, but at least for x86/Arm/RISC-V you would parse the ACPI MADT to find these early at boot. Each processor has a unique ID in firmware that lets you associate an (optional) processor device node with the processor definition in the MADT. The error message you are seeing comes from an (ill conceived IMHO) option ACPI_ACTIVATE_DEV which is not enabled by default in any kernels we ship. Each device node is going to have a _STA method that tells the OS whether that device is enabled. Because updating AML dynamically can be difficult, it's not uncommon for firmware to create templates for all possible processors and the _STA method will inspect some variable set early at boot to determine whether or not a given processor device is present. So tl;dr: - Your firmware says "There is no processor device here" - Your kernel config says "Let me try anyway" and asks firmware to enable the device. - Firmware says no. - You get an error message logged. HTH, Jared On Sat, 5 Nov 2022, Robert Elz wrote: This is just (well mostly) curiosity, it doesn't seem to affect anything that I know about, but during autoconfig, the kernel (any 9.99.x I have tried I think) prints acpi0: autoconfiguration error: failed to activate ACPI0007 64 times during the boot sequence (this one is from 9.99.105) I was just wondering what I apparently have so much of that this would appear so often (the other "failed to activate" messages I get seem to just occur once). The only thing that I'm aware of that I have 64 of is 64GB ram, but that's on just 2 DIMMs, and it is hard to believe that something is existing for each individual GB. Before I actually counted, when I just watched them scroll past (very quickly) during the boot, I guessed that it was perhaps once per CPU, but 64 CPUs, no matter how you count them, is way more than I have, so I doubt it is that. Anyone know ACPI well enough to know what that is? kre
Re: IDENTIFY failed
It's also possible that 2 full seconds of delays are unnecessary. Do those delays really need to be 500ms each? On Thu, 4 Nov 2021, Rin Okuyama wrote: Yeah, I know that. But, we already have two problem reports. What I am concerned about is similar problems will occur for a lot of machines. (Thinking again...) But, yes, by this way, innocent people will be punished forever by extra seconds per boot... Hmm, if affected hardware is somehow limited, we can just introduce something like AHCI_QUIRK_EXTRADELAY. Otherwise, we can reconsider, for example, before NetBSD 10 is released. Jun, Patrick, can you please provide full dmesg for your machines? Thanks, rin On 2021/11/04 19:58, Jared McNeill wrote: From the commit message: There are a handful of inexplicable 500ms delays introduced to the drive detect path in this driver, slowing boot. They can be re-enabled with options AHCISATA_EXTRA_DELAY, but should not be enabled for normal kernels. If a delay does need to be introduced in these places, the value should either be more carefully selected or the scope limited to hardware that requires the extra delay. I don't have any hardware that has problems with the delays removed, so go ahead and revert this commit if you're happy with that as a solution. It would be better to fix the problem properly though as this costs multiple seconds per drive at boot. Take care, Jared On Thu, 4 Nov 2021, Rin Okuyama wrote: Can't we put back AHCISATA_EXTRA_DELAY by default? IIUC, the option affects only probe/reset; no bad effects for I/O performance. Thanks, rin On 2021/11/01 21:19, Patrick Welche wrote: On Fri, Oct 29, 2021 at 01:05:26PM +0900, Jun Ebihara wrote: From: matthew green Subject: re: IDENTIFY failed Date: Fri, 29 Oct 2021 07:18:09 +1100 autoconfiguration error: ahcisata0 port 1: setting WDCTL_RST failed for drive 0 https://mail-index.netbsd.org/current-users/2021/10/27/msg041615.html this one has reduced timeframe, too: between NetBSD 9.99.91 (GENERIC) #0: Tue Oct 12 19:57:53 UTC 2021 OK NetBSD 9.99.92 (GENERIC) #0: Mon Oct 25 20:32:38 UTC 2021 Failed which changed how some interrupt handling works, and: http://mail-index.netbsd.org/source-changes/2021/10/11/msg132941.html which removed some delays in the probe path. possibly this one is more likely to be at fault since it touches the probe path directly. add /usr/src/sys/arch/amd64/conf/GENERIC.local options AHCISATA_EXTRA_DELAY compile kernel That did the trick - thanks! (Wanted to be near the box before trying it) Cheers, Patrick
Re: IDENTIFY failed
From the commit message: There are a handful of inexplicable 500ms delays introduced to the drive detect path in this driver, slowing boot. They can be re-enabled with options AHCISATA_EXTRA_DELAY, but should not be enabled for normal kernels. If a delay does need to be introduced in these places, the value should either be more carefully selected or the scope limited to hardware that requires the extra delay. I don't have any hardware that has problems with the delays removed, so go ahead and revert this commit if you're happy with that as a solution. It would be better to fix the problem properly though as this costs multiple seconds per drive at boot. Take care, Jared On Thu, 4 Nov 2021, Rin Okuyama wrote: Can't we put back AHCISATA_EXTRA_DELAY by default? IIUC, the option affects only probe/reset; no bad effects for I/O performance. Thanks, rin On 2021/11/01 21:19, Patrick Welche wrote: On Fri, Oct 29, 2021 at 01:05:26PM +0900, Jun Ebihara wrote: From: matthew green Subject: re: IDENTIFY failed Date: Fri, 29 Oct 2021 07:18:09 +1100 autoconfiguration error: ahcisata0 port 1: setting WDCTL_RST failed for drive 0 https://mail-index.netbsd.org/current-users/2021/10/27/msg041615.html this one has reduced timeframe, too: between NetBSD 9.99.91 (GENERIC) #0: Tue Oct 12 19:57:53 UTC 2021 OK NetBSD 9.99.92 (GENERIC) #0: Mon Oct 25 20:32:38 UTC 2021 Failed which changed how some interrupt handling works, and: http://mail-index.netbsd.org/source-changes/2021/10/11/msg132941.html which removed some delays in the probe path. possibly this one is more likely to be at fault since it touches the probe path directly. add /usr/src/sys/arch/amd64/conf/GENERIC.local options AHCISATA_EXTRA_DELAY compile kernel That did the trick - thanks! (Wanted to be near the box before trying it) Cheers, Patrick
"WDCTL_RST failed" fixed in -current (I hope)
Hi folks -- I committed some changes to the ahcisata driver over the past few days that appears to have solved the old "WDCTL_RST failed" problem that people have been seeing over the years. If you've run into this issue in the past, please re-test with -current and let me know how it goes! Take care, Jared
Re: cmake hanging
Still happens to me with a -current kernel and -9 chroot. Captured today: http://www.invisible.ca/tmp/cmake.txt On Sun, 20 Sep 2020, Chavdar Ivanov wrote: I am not seeing other people report these lately, but I still continue to get these hangings, e.g. when running git as part of a zsh prompt function; roughly every fourth command ends up with one of these, again as before, it is enough to attach with gdb to the got process and quit in order for it to complete. Here is another trace, -current is 9.99.73 from yesterday: [Switching to LWP 26563 of process 23529] 0x7a81318a86ea in ___lwp_park60 () from /usr/lib/libc.so.12 (gdb) thread apply all bt Thread 2 (LWP 23529 of process 23529): #0 0x7a813184554a in _lwp_wait () from /usr/lib/libc.so.12 #1 0x7a813200c7a2 in pthread_join () from /usr/lib/libpthread.so.1 #2 0x0054ba92 in preload_index () #3 0x0055a3e8 in refresh_index () #4 0x00425510 in cmd_status () #5 0x004053fe in handle_builtin () #6 0x00406301 in cmd_main () #7 0x005ed143 in main () Thread 1 (LWP 26563 of process 23529): #0 0x7a81318a86ea in ___lwp_park60 () from /usr/lib/libc.so.12 #1 0x7a813200975e in ?? () from /usr/lib/libpthread.so.1 #2 0x7a81318d6646 in je_malloc_mutex_lock_slow () from /usr/lib/libc.so.12 #3 0x7a813190dd76 in je_arena_choose_hard () from /usr/lib/libc.so.12 #4 0x7a81318b436d in je_tsd_tcache_data_init () from /usr/lib/libc.so.12 #5 0x7a81318b45ae in je_tsd_tcache_enabled_data_init () from /usr/lib/libc.so.12 #6 0x7a81318b1729 in je_tsd_fetch_slow () from /usr/lib/libc.so.12 #7 0x7a813190e0bc in malloc () from /usr/lib/libc.so.12 #8 0x005ce9fb in xrealloc () #9 0x005a2e20 in strbuf_grow () #10 0x005ad07b in lstat_cache_matchlen () #11 0x005ad1b5 in threaded_has_symlink_leading_path () #12 0x0054b808 in preload_thread () #13 0x7a813200bf4e in ?? () from /usr/lib/libpthread.so.1 #14 0x7a8131892480 in ?? () from /usr/lib/libc.so.12 #15 0x in ?? () On Tue, 1 Sep 2020 at 10:39, Chavdar Ivanov wrote: Another one, overnight, while building gimp, by gegl, attached. As I mentioned earlier, it is enough to attach to the process with gdb and then quit in order for the process to carry on working and complete the build. On Tue, 1 Sep 2020 at 08:55, Tom Ivar Helbekkmo wrote: Chavdar Ivanov writes: I am having the same cmake hangs as in this thread. I've attached the gdb 'thread apply all bt' output (collected with script). That looks suspiciouly similar to the hangs I'm seeing with dhcpd on amd64-current (note the mutex lock attempt, while nothing else looks very interesting): (gdb) thread apply all bt Thread 7 (process 12269): #0 0x7e573a2a892a in ___lwp_park60 () from /usr/lib/libc.so.12 #1 0x7e573e80a9a9 in pthread_cond_timedwait (cond=0x7e573fd67d08, mutex=0x7e573fd67cd8, abstime=0x0) at /usr/src/lib/libpthread/pthread_cond.c:167 #2 0x7e573f01ed2e in isc_app_ctxrun (ctx=0x7e573fd67c80) at /usr/src/external/mpl/bind/lib/libisc/../../dist/lib/isc/app.c:340 #3 0x5664e624 in dispatch () at /usr/src/external/mpl/dhcp/lib/common/../../dist/common/dispatch.c:121 #4 0x5668aae7 in main (argc=, argv=) at /usr/src/external/mpl/dhcp/bin/server/../../dist/server/dhcpd.c:1114 Thread 6 (process 21463): #0 0x7e573a2a892a in ___lwp_park60 () from /usr/lib/libc.so.12 #1 0x7e573e80a9a9 in pthread_cond_timedwait (cond=0x7e5740037850, mutex=0x7e5740037800, abstime=0x0) at /usr/src/lib/libpthread/pthread_cond.c:167 #2 0x7e573f02a0a4 in dispatch (threadid=, manager=0x7e5740036800) at /usr/src/external/mpl/bind/lib/libisc/../../dist/lib/isc/task.c:1059 #3 run (queuep=) at /usr/src/external/mpl/bind/lib/libisc/../../dist/lib/isc/task.c:1346 #4 0x7e573e80bee0 in pthread__create_tramp (cookie=0x7e574002e000) at /usr/src/lib/libpthread/pthread.c:560 #5 0x7e573a2924e0 in ?? () from /usr/lib/libc.so.12 #6 0x0040 in ?? () #7 0x7e573980 in ?? () #8 0x001003a0efff in ?? () #9 0x7e57396000c0 in ?? () #10 0x001fff40 in ?? () #11 0x in ?? () Thread 5 (process 19116): #0 0x7e573a244d8a in _sys___kevent50 () from /usr/lib/libc.so.12 #1 0x7e573e8079d8 in __kevent50 (fd=, ev=ev@entry=0x0, nev=nev@entry=0, rev=rev@entry=0x7e5740008000, nrev=nrev@entry=64, ts=ts@entry=0x0) at /usr/src/lib/libpthread/pthread_cancelstub.c:176 #2 0x7e573f0223c4 in netthread (uap=0x7e5740039800) at /usr/src/external/mpl/bind/lib/libisc/../../dist/lib/isc/unix/socket.c:3519 #3 0x7e573e80bee0 in pthread__create_tramp (cookie=0x7e574002fc00) at /usr/src/lib/libpthread/pthread.c:560 #4 0x7e573a2924e0 in ?? () from /usr/lib/libc.so.12 #5 0x0060 in ?? () #6 0x7e573940 in ?? () #7 0x002003a0efff in ?? () #8 0x7e5737a000c0 in ?? () #9 0x003fff40 in ?? ()
yet another uvm_amap panic
[ 37088.6770221] panic: kernel diagnostic assertion "amap->am_nused < amap->am_maxslot" failed: file "/home/source/ab/HEAD/src/sys/uvm/uvm_amap.c", line 1505 [ 37088.6870223] cpu4: Begin traceback... [ 37088.6870223] trace fp c0086e1d8a00 [ 37088.6970231] fp c0086e1d8a20 vpanic() at c04b3eac netbsd:vpanic+0x15c [ 37088.6970231] fp c0086e1d8a90 kern_assert() at c07d2eec netbsd:kern_assert+0x5c [ 37088.7070240] fp c0086e1d8b20 amap_add() at c04143cc netbsd:amap_add+0x214 [ 37088.7170234] fp c0086e1d8b60 uvmfault_promote() at c0419a7c netbsd:uvmfault_promote+0x174 [ 37088.7270239] fp c0086e1d8bc0 uvm_fault_internal() at c041b6b0 netbsd:uvm_fault_internal+0xf78 [ 37088.7370250] fp c0086e1d8de0 data_abort_handler() at c008e31c netbsd:data_abort_handler+0x184 [ 37088.7470247] fp c0086e1d8e60 trap_el0_sync() at c008d5bc netbsd:trap_el0_sync+0x35c [ 37088.7570263] tf c0086e1d8ed0 el0_trap() at c008a924 netbsd:el0_trap [ 37088.7570263] trapframe 0xc0086e1d8ed0 (304 bytes) [ 37088.7670355] pc=000200a4f5bc, spsr=2000 [ 37088.7770287]esr=9207,far=fe9bc0431fe0 [ 37088.7770287] x0=0003, x1=000201148000 [ 37088.7870299] x2=0008, x3=0001 [ 37088.7870299] x4=0060, x5=fe9bd8c1d888 [ 37088.7970293] x6=ffbc0710, x7= [ 37088.8070290] x8=000201148000, x9=000201114000 [ 37088.8070290]x10=0001,x11=0001 [ 37088.8170281]x12=000a,x13=ffbbfef8 [ 37088.8170281]x14=0240,x15=0240 [ 37088.8270283]x16=0002010789f8,x17=fe9bd97a7140 [ 37088.8270283]x18=0010,x19=ffbc06a8 [ 37088.8370282]x20=e1e0,x21=fe9bc0423e00 [ 37088.8470286]x22=fe9bc0431fe0,x23=000a [ 37088.8470286]x24=fe9bc2d8e1a0,x25=0002 [ 37088.8570282]x26=fe9bc4188ee0,x27=000200d91060 [ 37088.8570282]x28=, fp=x29=ffbc0490 [ 37088.8670287] lr=x30=000200a4f848, sp=ffbc0490 [ 37088.8770281] [ 37088.8770281] cpu4: End traceback...
Another uvm_amap panic in -current
Console output stopped working part-way through the traceback so only part of the trapframe is printed. [ 153620.7406721] panic: kernel diagnostic assertion "anon != NULL && anon->an_ref != 0" failed: file "/home/source/ab/HEAD/src/sys/uvm/uvm_amap.c", line 748 [ 153620.7534934] cpu0: Begin traceback... [ 153620.7534934] trace fp c008414bfb30 [ 153620.7814018] fp c008414bfb50 vpanic() at c04adf4c netbsd:vpanic+0x15c [ 153620.7934242] fp c008414bfbc0 kern_assert() at c07ccdec netbsd:kern_assert+0x5c [ 153620.8014956] fp c008414bfc50 amap_wipeout() at c040bc94 netbsd:amap_wipeout+0xf4 [ 153620.8315156] fp c008414bfc90 uvm_unmap_detach() at c041c454 netbsd:uvm_unmap_detach+0x6c [ 153620.8453990] fp c008414bfcd0 uvmspace_free() at c041ef08 netbsd:uvmspace_free+0xd8 [ 153620.8544258] fp c008414bfd00 exit1() at c0452bcc netbsd:exit1+0x174 [ 153620.8544258] fp c008414bfdf0 sys_exit() at c0453498 netbsd:sys_exit+0x38 [ 153620.9044388] fp c008414bfe20 syscall() at c008c384 netbsd:syscall+0x18c [ 153620.9044388] tf c008414bfed0 el0_trap() at c008a994 netbsd:el0_trap [ 153620.9197358] trapframe 0xc008414bfed0 (304 bytes) [ 153620.9272872] pc=f4aa7d931478, spsr=8000 [ 153620.9272872]esr=5601,far=f4aa7cab5048
uvm_amap panic in -current
This happened on aarch64 -current while running a pkgsrc bulk build: [ 346117.3280182] panic: kernel diagnostic assertion "amap->am_nused < amap->am_maxslot" failed: file "/home/source/ab/HEAD/src/sys/uvm/uvm_amap.c", line 1506 [ 346117.3380176] cpu4: Begin traceback... [ 346117.3380176] trace fp c0085a43fa10 [ 346117.3480181] fp c0085a43fa30 vpanic() at c04b2fd4 netbsd:vpanic+0x15c [ 346117.3580180] fp c0085a43faa0 kern_assert() at c07d208c netbsd:kern_assert+0x5c [ 346117.3580180] fp c0085a43fb30 amap_add() at c0412b1c netbsd:amap_add+0x214 [ 346117.3680249] fp c0085a43fb70 uvmfault_promote() at c041833c netbsd:uvmfault_promote+0x174 [ 346117.3780191] fp c0085a43fbd0 uvm_fault_internal() at c0419f70 netbsd:uvm_fault_internal+0xf78 [ 346117.3880182] fp c0085a43fdf0 data_abort_handler() at c008c754 netbsd:data_abort_handler+0x184 [ 346117.3980178] fp c0085a43fe70 trap_el0_sync() at c008bc6c netbsd:trap_el0_sync+0x27c [ 346117.4080236] tf c0085a43fed0 el0_trap() at c0089404 netbsd:el0_trap [ 346117.4180252] trapframe 0xc0085a43fed0 (304 bytes) [ 346117.4180252] pc=000200a4f5bc, spsr=2000 [ 346117.4280366]esr=9207,far=f60326efaf98 [ 346117.4280366] x0=0003, x1=00020114b000 [ 346117.4380257] x2=0003, x3=0008 [ 346117.4480252] x4=, x5= [ 346117.4480252] x6=ffd572d0, x7= [ 346117.4580251] x8=0003, x9= [ 346117.4580251]x10=0001,x11= [ 346117.4680282]x12=00020079,x13= [ 346117.4780348]x14=f60327797c18,x15= [ 346117.4780348]x16=00020107b730,x17=f6032d237100 [ 346117.4880322]x18=0068,x19=ffd57200 [ 346117.4880322]x20=2698,x21=f60326ef8900 [ 346117.4980323]x22=f60326efaf98,x23=000a [ 346117.5080321]x24=f603279ec340,x25=f603276a8b00 [ 346117.5080321]x26=f603279e7930,x27=000200d92438 [ 346117.5180324]x28=, fp=x29=ffd56fb0 [ 346117.5180324] lr=x30=000200a4fdd8, sp=ffd56fb0 [ 346117.5280369] [ 346117.5380361] cpu4: End traceback... Stopped in pid 20064.20064 (cc1plus) at netbsd:cpu_Debugger+0x4: ret
Re: blacklist -> blocklist in current
Thanks Christos. On Sun, 14 Jun 2020, Christos Zoulas wrote: Hello folks, I've renamed blacklist to blocklist, so if you are currently using it, you should rename things accordingly: - rc.conf variable - /var/db/blacklist.db file - npf table name Apologies for the inconvenience, christos
Re: panic: kernel diagnostic assertion "l == curlwp"
On Sat, 6 Jun 2020, Jason Thorpe wrote: On Jun 6, 2020, at 9:21 AM, Jared McNeill wrote: KASSERT-aside, I am left wondering based on that stack trace how copyout on aarch64 can fail here at all (that seems to be the only way that lwp_exit from sys__lwp_create can happen). What were you doing at the time? I guess obviously running a program that uses pthreads... pkgsrc bulk build, so ¯\_(ツ)_/¯
Re: panic: kernel diagnostic assertion "l == curlwp"
KASSERT-aside, I am left wondering based on that stack trace how copyout on aarch64 can fail here at all (that seems to be the only way that lwp_exit from sys__lwp_create can happen). On Sat, 6 Jun 2020, Jason Thorpe wrote: +rmind@ +ad@ On Jun 6, 2020, at 5:00 AM, Jared McNeill wrote: Looks like I hit another one on this path with your latest fix in place: [ 3737.4034537] panic: kernel diagnostic assertion "l == curlwp || ((l->l_flag & LW_SYSTEM) && pcu_valid == 0)" failed: file "/home/source/ab/HEAD/src/sys/kern/subr_pcu.c", line 133 This assertion was added in rev 1.18 by Mindaugas, 6 years ago. It obviously needs to be adjusted to handle the "lwp creation failed", but I'd have to study that code a lot more before I feel comfortable doing so. [ 3737.4134523] cpu18: Begin traceback... [ 3737.4234525] trace fp c0086cad0c50 [ 3737.4234525] fp c0086cad0c70 vpanic() at c04b230c netbsd:vpanic+0x15c [ 3737.4334526] fp c0086cad0ce0 kern_assert() at c07d052c netbsd:kern_assert+0x5c [ 3737.4434535] fp c0086cad0d70 pcu_discard_all() at c04a9a58 netbsd:pcu_discard_all+0x58 [ 3737.4534583] fp c0086cad0d90 lwp_exit() at c0461558 netbsd:lwp_exit+0x1b0 [ 3737.4534583] fp c0086cad0dd0 sys__lwp_create() at c04c4ed8 netbsd:sys__lwp_create+0xe8 [ 3737.4634613] fp c0086cad0e20 syscall() at c008a624 netbsd:syscall+0x18c [ 3737.4734599] tf c0086cad0ed0 el0_trap() at c0088c34 netbsd:el0_trap -- thorpej
Re: panic: kernel diagnostic assertion "l == curlwp"
Looks like I hit another one on this path with your latest fix in place:
[ 3737.4034537] panic: kernel diagnostic assertion "l == curlwp || ((l->l_flag & LW_SYSTEM) &&
pcu_valid == 0)" failed: file "/home/source/ab/HEAD/src/sys/kern/subr_pcu.c", line 133
[ 3737.4134523] cpu18: Begin traceback...
[ 3737.4234525] trace fp c0086cad0c50
[ 3737.4234525] fp c0086cad0c70 vpanic() at c04b230c
netbsd:vpanic+0x15c
[ 3737.4334526] fp c0086cad0ce0 kern_assert() at c07d052c
netbsd:kern_assert+0x5c
[ 3737.4434535] fp c0086cad0d70 pcu_discard_all() at c04a9a58
netbsd:pcu_discard_all+0x58
[ 3737.4534583] fp c0086cad0d90 lwp_exit() at c0461558
netbsd:lwp_exit+0x1b0
[ 3737.4534583] fp c0086cad0dd0 sys__lwp_create() at c04c4ed8
netbsd:sys__lwp_create+0xe8
[ 3737.4634613] fp c0086cad0e20 syscall() at c008a624
netbsd:syscall+0x18c
[ 3737.4734599] tf c0086cad0ed0 el0_trap() at c0088c34
netbsd:el0_trap
[ 3737.4834609] trapframe 0xc0086cad0ed0 (304 bytes)
[ 3737.4834609] pc=fdbd319c8958, spsr=2000
[ 3737.4934603]esr=56000135,far=fdbd319eb030
[ 3737.4934603] x0=ffbc41c0, x1=fdbd31db2260
[ 3737.5034629] x2=fdbd31d8e200, x3=
[ 3737.5134632] x4=ffbc4190, x5=0030
[ 3737.5134632] x6=ffbc41c0, x7=fdbd31af0208
[ 3737.5234664] x8=0001, x9=1003
[ 3737.5234664]x10=000c,x11=0001
[ 3737.5334641]x12=fdbd31da5c18,x13=
[ 3737.5334641]x14=,x15=fdbd31400980
[ 3737.5434637]x16=fdbd31da22e0,x17=fdbd319c8954
[ 3737.5534632]x18=0001,x19=ffbc41c0
[ 3737.5534632]x20=ec172e60,x21=0002
[ 3737.5634733]x22=fdbd31db2260,x23=fdbd31d8e200
[ 3737.5634733]x24=ec172000,x25=ffbc4190
[ 3737.5734687]x26=ec1732a8,x27=ec173070
[ 3737.5734687]x28=fdbd31db3400, fp=x29=ffbc41d0
[ 3737.5834824] lr=x30=fdbd31d8e224, sp=ffbc40e0
[ 3737.5934691]
[ 3737.5934691] cpu18: End traceback...
Stopped in pid 14611.14611 (conftest) atnetbsd:cpu_Debugger+0x4:ret
db{18}>
On Mon, 1 Jun 2020, Jason Thorpe wrote:
On Jun 1, 2020, at 6:36 AM, Kamil Rytarowski wrote:
lwp_exit() used to work for curlwp and !curlwp.
There is a regression that there was introduced code called from
lwp_exit() calling lwp_thread_cleanup(l) that asserts curlwp,
effectively enforcing lwp_exit() to be operational for curlwp only.
I just reviewed the entire code path below that assertion again, and nothing in
the current incarnation of the code relies on l == curlwp. I've removed the
assertion just now.
-- thorpej
Re: SOLVED: static linking glxgears and glxinfo now fails (mult. def. _glapi_tls_Context, etc.)
On Thu, 4 Jun 2020, Greg A. Woods wrote: I.e. they need to be run locally on a system running an X11 server with the appropriate extensions. (Yeah, I know what the "D" in "DRI" stands for, but still it is sad that it is once again no longer true that "The network is the computer" in all too many circumstances -- MESA/OpenGL apps should still work over a network, even if it has to give up on DRI to do so, but I suspect there's no support for this any more.) LIBGL_ALWAYS_INDIRECT=1 in your environment should help here.
lockdebug panic booting -current
Starting dhcpcd.
[ 13.3072671] Kernel lock error: _kernel_lock,244: spinout
[ 13.3072671] lock address : 0xc0f64d80 type : spin
[ 13.3172670] initialized : 0xc07dacd8
[ 13.3172670] shared holds : 0 exclusive: 1
[ 13.3272672] shares wanted: 0 exclusive: 4
[ 13.3372796] relevant cpu : 2 last held: 26
[ 13.3372796] relevant lwp : 0x009fed768600 last held: 0x9b98cb00
[ 13.3472797] last locked* : 0xc04840e0 unlocked : 0xc0449698
[ 13.3572920] curcpu holds : 0 wanted by: 0x009fed768600
[ 13.3672940] panic: LOCKDEBUG: Kernel lock error: _kernel_lock,244: spinout
[ 13.3672940] cpu2: Begin traceback...
[ 13.3772923] trace fp c0081e7b3a70
[ 13.3772923] fp c0081e7b3a90 vpanic() at c04baa24
netbsd:vpanic+0x15c
[ 13.3872925] fp c0081e7b3b00 panic() at c04bab1c netbsd:panic+0x44
[ 13.3872925] fp c0081e7b3b90 lockdebug_abort1() at c04af078
netbsd:lockdebug_abort1+0xf0
[ 13.3972924] fp c0081e7b3be0 _kernel_lock() at c0463af4
netbsd:_kernel_lock+0x274
[ 13.4073051] fp c0081e7b3c60 frag6_fasttimo() at c027013c
netbsd:frag6_fasttimo+0x24
[ 13.4173049] fp c0081e7b3c80 pffasttimo() at c04e65ac
netbsd:pffasttimo+0x4c
[ 13.4273193] fp c0081e7b3cb0 callout_softclock() at c0493c1c
netbsd:callout_softclock+0xfc
[ 13.4373187] fp c0081e7b3d40 softint_dispatch() at c048502c
netbsd:softint_dispatch+0xec
[ 13.4473189] fp c0081e793cc0 cpu_switchto_softint() at c0088d04
netbsd:cpu_switchto_softint+0x68
[ 13.4573189] fp c0081e793df8 cpu_idle() at c0089d10
netbsd:cpu_idle+0x58
[ 13.4573189] fp c0081e793e40 idle_loop() at c045e510
netbsd:idle_loop+0x190
[ 13.4673191] fp cpu_mpstart() at c0001a3c
netbsd:cpu_mpstart+0x15c
[ 13.4773287] cpu2: End traceback...
Stopped in pid 0.30 (system) at netbsd:cpu_Debugger+0x4:ret
db{2}>
Re: panic: kernel diagnostic assertion "l == curlwp"
Looks like lwp_exit is called with something other than curlwp in the
sys__lwp_create error path:
https://nxr.netbsd.org/xref/src/sys/kern/sys_lwp.c#156
On Mon, 1 Jun 2020, Jared McNeill wrote:
Just hit this panic on 9.99.64:
[ 6717.5700161] panic: kernel diagnostic assertion "l == curlwp" failed: file
"/home/source/ab/HEAD/src/sys/kern/kern_lwp.c", line 2063
[ 6717.5800161] cpu18: Begin traceback...
[ 6717.5900170] trace fp c0088f5d3c50
[ 6717.5900170] fp c0088f5d3c70 vpanic() at c04b0334
netbsd:vpanic+0x15c
[ 6717.6000167] fp c0088f5d3ce0 kern_assert() at c07ce26c
netbsd:kern_assert+0x5c
[ 6717.6100211] fp c0088f5d3d70 lwp_thread_cleanup() at c045f368
netbsd:lwp_thread_cleanup+0x80
[ 6717.6200270] fp c0088f5d3d90 lwp_exit() at c045f4ac
netbsd:lwp_exit+0xcc
[ 6717.6200270] fp c0088f5d3dd0 sys__lwp_create() at c04c2f00
netbsd:sys__lwp_create+0xe8
[ 6717.6300215] fp c0088f5d3e20 syscall() at c008a63c
netbsd:syscall+0x18c
[ 6717.6400221] tf c0088f5d3ed0 el0_trap() at c0088c74
netbsd:el0_trap
[ 6717.6500214] trapframe 0xc0088f5d3ed0 (304 bytes)
[ 6717.6500214] pc=f8abc4638958, spsr=2000
[ 6717.6600309]esr=56000135,far=f8abc465b030
[ 6717.6600309] x0=ffe68500, x1=f8abc4a1a260
[ 6717.6700228] x2=f8abc49fe200, x3=
[ 6717.6800338] x4=ffe684d0, x5=0030
[ 6717.6800338] x6=ffe68500, x7=f8abc4760208
[ 6717.6900234] x8=0001, x9=1003
[ 6717.6900234]x10=000c,x11=0001
[ 6717.7000252]x12=f8abc49e91d8,x13=
[ 6717.7000252]x14=,x15=f8abc4000980
[ 6717.7100242]x16=f8abc4a122e0,x17=f8abc4638954
[ 6717.7200306]x18=0001,x19=ffe68500
[ 6717.7200306]x20=f9a72e60,x21=0002
[ 6717.7300283]x22=f8abc4a1a260,x23=f8abc49fe200
[ 6717.7300283]x24=f9a72000,x25=ffe684d0
[ 6717.7400357]x26=f9a732a8,x27=f9a73070
[ 6717.7400357]x28=f8abc4a1b400, fp=x29=ffe68510
[ 6717.7500291] lr=x30=f8abc49fe224, sp=ffe68420
[ 6717.7600300]
[ 6717.7600300] cpu18: End traceback...
Stopped in pid 152.152 (conftest) atnetbsd:cpu_Debugger+0x4:ret
db{18}>
panic: kernel diagnostic assertion "l == curlwp"
Just hit this panic on 9.99.64:
[ 6717.5700161] panic: kernel diagnostic assertion "l == curlwp" failed: file
"/home/source/ab/HEAD/src/sys/kern/kern_lwp.c", line 2063
[ 6717.5800161] cpu18: Begin traceback...
[ 6717.5900170] trace fp c0088f5d3c50
[ 6717.5900170] fp c0088f5d3c70 vpanic() at c04b0334
netbsd:vpanic+0x15c
[ 6717.6000167] fp c0088f5d3ce0 kern_assert() at c07ce26c
netbsd:kern_assert+0x5c
[ 6717.6100211] fp c0088f5d3d70 lwp_thread_cleanup() at c045f368
netbsd:lwp_thread_cleanup+0x80
[ 6717.6200270] fp c0088f5d3d90 lwp_exit() at c045f4ac
netbsd:lwp_exit+0xcc
[ 6717.6200270] fp c0088f5d3dd0 sys__lwp_create() at c04c2f00
netbsd:sys__lwp_create+0xe8
[ 6717.6300215] fp c0088f5d3e20 syscall() at c008a63c
netbsd:syscall+0x18c
[ 6717.6400221] tf c0088f5d3ed0 el0_trap() at c0088c74
netbsd:el0_trap
[ 6717.6500214] trapframe 0xc0088f5d3ed0 (304 bytes)
[ 6717.6500214] pc=f8abc4638958, spsr=2000
[ 6717.6600309]esr=56000135,far=f8abc465b030
[ 6717.6600309] x0=ffe68500, x1=f8abc4a1a260
[ 6717.6700228] x2=f8abc49fe200, x3=
[ 6717.6800338] x4=ffe684d0, x5=0030
[ 6717.6800338] x6=ffe68500, x7=f8abc4760208
[ 6717.6900234] x8=0001, x9=1003
[ 6717.6900234]x10=000c,x11=0001
[ 6717.7000252]x12=f8abc49e91d8,x13=
[ 6717.7000252]x14=,x15=f8abc4000980
[ 6717.7100242]x16=f8abc4a122e0,x17=f8abc4638954
[ 6717.7200306]x18=0001,x19=ffe68500
[ 6717.7200306]x20=f9a72e60,x21=0002
[ 6717.7300283]x22=f8abc4a1a260,x23=f8abc49fe200
[ 6717.7300283]x24=f9a72000,x25=ffe684d0
[ 6717.7400357]x26=f9a732a8,x27=f9a73070
[ 6717.7400357]x28=f8abc4a1b400, fp=x29=ffe68510
[ 6717.7500291] lr=x30=f8abc49fe224, sp=ffe68420
[ 6717.7600300]
[ 6717.7600300] cpu18: End traceback...
Stopped in pid 152.152 (conftest) atnetbsd:cpu_Debugger+0x4:ret
db{18}>
Re: panic after DRM & nouveau MSI changes
I'll try to have a look at it over the next few days. Unfortunately this is an x86 specific problem and I don't have one to test so it could take some time to work out. On Wed, 5 Feb 2020, John D. Baker wrote: Recently MSI was re-enabled for DRM devices generally and nouveau devices specifically. The resulting kernel panics attaching the framebuffer console on nouveau-equipped machines. See the two most recent addenda to PR kern/52440 for details. Thanks. -- |/"\ John D. Baker, KN5UKS NetBSD Darwin/MacOS X |\ / jdbaker[snail]consolidated[flyspeck]net OpenBSDFreeBSD | X No HTML/proprietary data in email. BSD just sits there and works! |/ \ GPGkeyID: D703 4A7E 479F 63F8 D3F4 BD99 9572 8F23 E4AD 1645
Re: Pinebook and NetBSD 8.99.39 [UPDATE]
You have to write the image to the “entire disk” partition (rld2c), which will overwrite the disk label anyway. > On May 14, 2019, at 4:27 PM, Ron Georgia wrote: > > Question: if I disklabel -eI ld2 and remove partition e, then dd the image > again to /dev/rld2e, will that work or will I have a Pinebrick? > > On 5/14/19, 1:54 PM, "Ron Georgia" wrote: > >Well... I did both > >arm64# dd if=arm64.img of=/dev/rld2c bs=1m conv=sync >dd: /dev/rld2c: Input/output error >30+0 records in >29+0 records out >30408704 bytes transferred in 9.927 secs (3063231 bytes/sec) > >And > >arm64# dd if=NetBSD-evbarm-aarch64-201905120950Z-pinebook.img > of=/dev/rld2c bs=1m conv=sync >dd: /dev/rld2c: Input/output error >30+0 records in >29+0 records out >30408704 bytes transferred in 11.143 secs (2728951 bytes/sec) > >Both commands generated a ton of "ld2c: error writing fsbn..." errors. > When I reboot I get a blank screen. ( Any thoughts on what I can do? > >Disklabel looks like this: >arm64# disklabel ld2 ># /dev/rld2: >type: ld >disk: ld2 >label: default label >flags: >bytes/sector: 512 >sectors/track: 63 >tracks/cylinder: 32 >sectors/cylinder: 2016 >cylinders: 1040 >total sectors: 2097152 >rpm: 3600 >interleave: 1 >trackskew: 0 >cylinderskew: 0 >headswitch: 0 # microseconds >track-to-track seek: 0 # microseconds >drivedata: 0 > >5 partitions: >#sizeoffset fstype [fsize bsize cpg/sgs] > c: 2097152 0 4.2BSD 0 0 0 # (Cyl. 0 - > 1040*) > e:163840 32768 MSDOS # (Cyl. 16*- > 97*) >disklabel: boot block size 0 >disklabel: super block size 0 >disklabel: partitions c and e overlap > >I will surmise that overlapping partitions are not good? > >On 5/14/19, 12:53 PM, "Jason Thorpe" wrote: > > > >> On May 14, 2019, at 9:33 AM, Ron Georgia wrote: >> >> If I understand correctly: >> 1. boot Pinebook from microSD loaded with Pinebook NetBSD ARM Bootable >> Images from https://www.invisible.ca/arm/ >> 2. download arm64.img from >> ftp://nyftp.netbsd.org/pub/NetBSD-daily/HEAD/201905140810Z/evbarm-aarch64/binary/gzimg/ >> to microSD card. > >You can dd the invisible.ca imagine to the eMMC as well. It's just a > standard arm64.img with u-boot helpfully added by Jared; no need to download > a second one (to which you would then need to add u-boot). > >> 3. dd image to /dev/rld2c >> 4. Power down, remove SD card and reboot. >> >> Correct? >> For YES, press 1 >> For NO, press 2 >> >> On 5/14/19, 10:15 AM, "Jared McNeill" wrote: >> >> Easiest way is to download the image to the SD card, then dd it to the >> eMMC: >> >> # dd if=arm64.img of=/dev/rld2c bs=1m conv=sync >> >> You can't "wreck" your Pinebook this way as it will always try to boot >> from SD card first. So after writing the image to eMMC, shutdown the >> computer, remove the SD card, and power it back on. If something goes >> wrong, plug the SD card back in and it will boot from that device when you >> power it back on. >> >> >> On Tue, 14 May 2019, Ron Georgia wrote: >> >>> Instead of creating the image with dd, I followed the suggestion of >>> building the image with "highly recommend" Etcher. I am now able to login >>> as root! Not sure what happened. I am documenting every step of the way in >>> order to make my journey, mistakes and all, available to other "not so >>> savvy" Pinebook users. >>> >>> How do I install NetBSD directly onto my Pinebook? Do I use sysinst (per >>> https://wiki.netbsd.org/ports/evbarm/install_using_sysinst/)? >>> Before I "wreck" my Pinebook, do I select ld2 as the drive to partition and >>> install? >>> >>> === MISC DATA === >>> arm64# disklabel ld0 >>> # /dev/rld0: >>> type: SCSI >>> disk: STORAGE DEVICE >>> label: fictitious >>> flags: removable >>> bytes/sector: 512 >>> sectors/track: 32 >>> tracks/cylinder: 64 >>> sectors/cylinder: 2048 >>> cylinders: 1641 >>> total sectors: 31116288 >>> rpm: 3600 >>> interleave: 1 >>> trackskew: 0 >>> cylinderskew: 0 >>>
Re: Pinebook and NetBSD 8.99.39 [UPDATE]
Easiest way is to download the image to the SD card, then dd it to the eMMC: # dd if=arm64.img of=/dev/rld2c bs=1m conv=sync You can't "wreck" your Pinebook this way as it will always try to boot from SD card first. So after writing the image to eMMC, shutdown the computer, remove the SD card, and power it back on. If something goes wrong, plug the SD card back in and it will boot from that device when you power it back on. On Tue, 14 May 2019, Ron Georgia wrote: Instead of creating the image with dd, I followed the suggestion of building the image with "highly recommend" Etcher. I am now able to login as root! Not sure what happened. I am documenting every step of the way in order to make my journey, mistakes and all, available to other "not so savvy" Pinebook users. How do I install NetBSD directly onto my Pinebook? Do I use sysinst (per https://wiki.netbsd.org/ports/evbarm/install_using_sysinst/)? Before I "wreck" my Pinebook, do I select ld2 as the drive to partition and install? === MISC DATA === arm64# disklabel ld0 # /dev/rld0: type: SCSI disk: STORAGE DEVICE label: fictitious flags: removable bytes/sector: 512 sectors/track: 32 tracks/cylinder: 64 sectors/cylinder: 2048 cylinders: 1641 total sectors: 31116288 rpm: 3600 interleave: 1 trackskew: 0 cylinderskew: 0 headswitch: 0 # microseconds track-to-track seek: 0 # microseconds drivedata: 0 8 partitions: #sizeoffset fstype [fsize bsize cpg/sgs] a: 30657536458752 4.2BSD 0 0 0 # (Cyl.224 - 15193*) b:262144196608 swap # (Cyl. 96 -223) c: 31116288 0 unused 0 0# (Cyl. 0 - 15193*) d: 31116288 0 unused 0 0# (Cyl. 0 - 15193*) e:163840 32768 MSDOS # (Cyl. 16 - 95) arm64# disklabel ld2 # /dev/rld2: type: ld disk: ld2 label: default label flags: bytes/sector: 512 sectors/track: 63 tracks/cylinder: 32 sectors/cylinder: 2016 cylinders: 1040 total sectors: 2097152 rpm: 3600 interleave: 1 trackskew: 0 cylinderskew: 0 headswitch: 0 # microseconds track-to-track seek: 0 # microseconds drivedata: 0 3 partitions: #sizeoffset fstype [fsize bsize cpg/sgs] a: 2097152 0 4.2BSD 0 0 0 # (Cyl. 0 - 1040*) c: 2097152 0 4.2BSD 0 0 0 # (Cyl. 0 - 1040*) disklabel: boot block size 0 disklabel: super block size 0 disklabel: partitions a and c overlap arm64# gpt show ld0 GPT not found, displaying data from MBR. start size index contents 0 1 MBR 1 32767 Unused 32768163840 1 MBR part 12 (active) 196608262144 Unused 458752 30657536 2 MBR part 169 arm64# gpt show ld2 gpt: /dev/rld2: map entry doesn't fit media: new start + new size < start + size (1 + 1f < a000 + 1d5) arm64# dmesg | grep ld [ 1.16] axpreg5 at axppmic0: eldo2 [ 2.737735] sdmmc1: autoconfiguration error: couldn't enable card: 60 [ 2.811871] ld2 at sdmmc2: <0x45:0x0100:DF4016:0x00:0xfe875b0b:0x000> [ 2.811871] ld2: 1024 MB, 1040 cyl, 32 head, 63 sec, 512 bytes/sect x 2097152 sectors [ 2.828746] ld0 at sdmmc0: <0x03:0x5344:SS16G:0x80:0x42ce3d51:0x122> [ 2.848748] ld0: 15193 MB, 7717 cyl, 64 head, 63 sec, 512 bytes/sect x 31116288 sectors [ 2.848748] ld2: mbr partition exceeds disk size [ 2.848748] ld2: 8-bit width, 200.000 MHz [ 2.876482] ld0: 4-bit width, High-Speed/SDR25, 50.000 MHz [ 7.617842] ld2: mbr partition exceeds disk size [ 7.627841] boot device: ld0 [ 7.627841] root on ld0a dumps on ld0b [ 424.699875] ld2: mbr partition exceeds disk size [ 424.709875] ld2: mbr partition exceeds disk size [ 431.049997] ld2: mbr partition exceeds disk size [ 431.059997] ld2: mbr partition exceeds disk size [ 431.059997] ld2: mbr partition exceeds disk size [ 431.14] ld2: mbr partition exceeds disk size [ 442.320213] ld2: mbr partition exceeds disk size [ 746.325984] ld2: mbr partition exceeds disk size [ 746.335984] ld2: mbr partition exceeds disk size [ 1592.422047] ld2: mbr partition exceeds disk size [ 1592.422047] ld2: mbr partition exceeds disk size [ 1679.653695] ld2: mbr partition exceeds disk size [ 1679.673697] ld2: mbr partition exceeds disk size [ 1684.513788] ld2: mbr partition exceeds disk size [ 1684.513788] ld2: mbr partition exceeds disk size [ 1684.563793] ld2: mbr partition exceeds disk size [ 1684.583793] ld2: mbr partition exceeds disk size [ 1684.583793] ld2: mbr partition exceeds disk size [ 1761.785290] ld2: mbr partition exceeds disk size [ 1778.945617] ld2: mbr partition exceeds disk size [ 1993.819664] ld2: mbr partition exceeds disk size arm64# mount /dev/ld0a on / type ffs (noatime, local) /dev/ld0e on /boot type msdos (local) kernfs on /kern type kernfs (local) ptyfs on
Re: Hints for Bananapi and -current
On Tue, 7 May 2019, Markus Kilbinger wrote: - I was not able to bootarm.efi this kernel from its local ffs2 (!) netbsd partition on the sdcrad. Is bootarm.efi limited to ffs1? It uses ffs support from libsa, so I would expect it to work (but can't say that I have tried it on armv7). - In case of a connected sata disk: Is it possible to directly boot from that via bootarm.efi (or specify explicitly a boot device)? Only if the UEFI implementation (in this case U-Boot) supports the SATA controller. Cheers, Jared
Re: Hints for Bananapi and -current
So there is a better way to boot modern NetBSD/arm (using UEFI and bootarm.efi). If you want to boot the old way, it goes something like this: setenv bootargs root=ld0a console=fb fatload mmc 0 $kernel_addr_r netbsd-GENERIC.ub fatload mmc 0 $fdt_addr_r $fdtfile fdt addr $fdt_addr_r bootm $kernel_addr_r - $fdt_addr_r This method relies on 1) the kernel being wrapped with a legacy U-Boot image header, and 2) both the kernel and .dtb file being present on the FAT partition. Now on to the modern boot method.. Using U-Boot 2018.11 or later, setup a FAT partition with the following files on it: EFI/BOOT/bootarm.efi your-fdt-file.dtb U-Boot will automatically launch the UEFI bootloader and you will be presented with a countdown timer. bootarm will load a native ELF kernel (by default /netbsd) from the first FFS partition on the same drive that the loader came from. In addition, bootarm passes information about where to find the root device to the kernel automatically, so you shouldn’t need to specify a root= option. GENERIC and GENERIC64 kernels are setup to automatically use fb when available, so console=fb is also no longer required. Fast path to try this all out is to grab armv7.img from a build, add your U-Boot to it, and write to SD card. The image should boot automatically. Alternatively, you can download an image from www.invisible.ca/arm <http://www.invisible.ca/arm> that has U-Boot already applied for your board. Hope this helps! Jared > On May 1, 2019, at 5:07 PM, Frank Kardel wrote: > > Thanks - that got me beyond screen initialization. > > but > > bootm 8200 - $fdt_addr_r root=ld0a console=fb > > asked for the root device, swap, fs tape and init - so the parameters > probably did not reach the kernel at all. > > starting X didn't show anything on the 4K screen, X seemed to be running > though. > > I am also not sure whether the Bananapi HDMI can do the u-boot determined > 3940x2160 resolution. I have yet to play around with hdmi configuration. > > The dmesg output is attached. > > Adding a usb keyboard uncovered a panic while awaiting root device input: > > [ 3.4159917] ehci1: handing over low speed device on port 1 to companion > controller > [ 3.6660050] boot device: > [ 3.6660050] root device: uhidev0 at uhub3 port 1 configuration 1 interface > 0 > [ 5.0672791] uhidev0: DaKai (0xe8f) 2.4G RX (0xa8), rev 1.10/3.11, addr 2, > iclass 3/1 > [ 5.1663953] ukbd0 at uhidev0: 8 Variable keys, 6 Array codes > > [ 5.3375655] This port is broken, it does not call cnpollc() before calling > cngetc(). > [ 5.4375739] This should be fixed, but it will work anyway (for now). > [ 5.6775820] wskbd0 at ukbd0: console keyboard, using wsdisplay0 > [ 5.7732545] uhidev1 at uhub3 port 1 configuration 1 interface 1 > [ 5.8694170] uhidev1: DaKai (0xe8f) 2.4G RX (0xa8), rev 1.10/3.11, addr 2, > iclass 3/1 > [ 5.9727975] panic: usbd_transfer: not done > [ 6.0611224] cpu0: Begin traceback... > [ 6.1478907] 0x9c695b84: netbsd:db_panic+0x14 > [ 6.2380975] 0x9c695b9c: netbsd:vpanic+0x194 > [ 6.3276372] 0x9c695bb4: netbsd:snprintf > [ 6.4161552] 0x9c695bf4: netbsd:usbd_sync_transfer > [ 6.5075330] 0x9c695c34: netbsd:usbd_do_request_flags+0xa4 > [ 6.6012676] 0x9c695c4c: netbsd:usbd_do_request+0x20 > [ 6.6932964] 0x9c695c7c: netbsd:usbd_set_idle+0x70 > [ 6.7838060] 0x9c695d54: netbsd:uhidev_attach+0xdc > [ 6.8737881] 0x9c695d8c: netbsd:config_attach_loc+0x1b4 > [ 6.9701440] 0x9c695dbc: netbsd:config_found_sm_loc+0x54 > [ 7.0606941] 0x9c695e5c: netbsd:usbd_attachinterfaces+0x1b0 > [ 7.1525235] 0x9c695e8c: netbsd:usbd_probe_and_attach+0x84 > [ 7.2413633] 0x9c695ef4: netbsd:usbd_new_device+0x254 > [ 7.3280048] 0x9c695f5c: netbsd:uhub_explore+0x2dc > [ 7.4155137] 0x9c695f84: netbsd:usb_discover.isra.2+0x74 > [ 7.5044602] 0x9c695fac: netbsd:usb_event_thread+0x84 > [ 7.5926830] cpu0: End traceback... > Stopped in pid 0.59 (system) at netbsd:cpu_Debugger+0x4: bx r14 > > Any ideas ? > > Frank > > On 05/01/19 18:40, Jared McNeill wrote: >> Remove the following devices from your kernel config and the kernel should >> use simplefb instead: sunxidebe, sunxitcon, sunxihdmi, sunxidep >> >> I just peeked at the code quickly and it looks like the DE drivers are >> blindly using the display's advertised preferred mode without taking its own >> capabilities into consideration. >> >> >> On Wed, 1 May 2019, Frank Kardel wrote: >> >>> I tried -current with my Bananapi an had limited success: >>> >>> Using the first steps copying the image armv7 and the 2018.05 u-boot I >>> found the u-boot load attempting to perform a dhcp boot as noth
Re: Hints for Bananapi and -current
Remove the following devices from your kernel config and the kernel should use simplefb instead: sunxidebe, sunxitcon, sunxihdmi, sunxidep I just peeked at the code quickly and it looks like the DE drivers are blindly using the display's advertised preferred mode without taking its own capabilities into consideration. On Wed, 1 May 2019, Frank Kardel wrote: I tried -current with my Bananapi an had limited success: Using the first steps copying the image armv7 and the 2018.05 u-boot I found the u-boot load attempting to perform a dhcp boot as nothing was found on the mmc drive in autoboot. Did I miss somethnig to set up there ? I finally got a kernel to start booting with following chants: mmc dev 0 fatload mmc 0:1 $fdt_addr_r $fdtfile fatload mmc 0:1 8200 netbsd-GENERIC.ub bootm 8200 - $fdt_addr_r root=ld0a console=fb/none The output always stops at: [ 1.000] NetBSD 8.99.37 (GENERIC) #2: Sun Apr 28 10:09:56 CEST 2019 [ 1.000] kardel@Andromeda:/src/NetBSD/cur/src/obj.evbarm/sys/arch/evbarm/compile/GENERIC [ 1.000] total memory = 1022 MB [ 1.000] avail memory = 1012 MB [ 1.000] armfdt0 (root) [ 1.000] simplebus0 at armfdt0: LeMaker Banana Pi [ 1.000] simplebus1 at simplebus0 [ 1.000] cpus0 at simplebus0 [ 1.000] simplebus2 at simplebus0 [ 1.000] simplebus3 at simplebus0 [ 1.000] cpu0 at cpus0: Cortex-A7 r0p4 (Cortex V7A core) [ 1.000] cpu0: DC enabled IC enabled WB enabled LABT branch prediction enabled [ 1.000] cpu0: 32KB/32B 2-way L1 VIPT Instruction cache [ 1.000] cpu0: 32KB/64B 4-way write-back-locking-C L1 PIPT Data cache [ 1.000] cpu0: 256KB/64B 8-way write-through L2 PIPT Unified cache [ 1.000] vfp0 at cpu0: NEON MPE (VFP 3.0+), rounding, NaN propagation, denormals [ 1.000] cpufreqdt0 at cpu0 [ 1.000] cpu1 at cpus0 [ 1.000] cpufreqdt1 at cpu1 [ 1.000] gic0 at simplebus1: GIC [ 1.000] armgic0 at gic0: Generic Interrupt Controller, 160 sources (150 valid) [ 1.000] armgic0: 16 Priorities, 128 SPIs, 7 PPIs, 15 SGIs [ 1.000] fclock0 at simplebus2: 2500 Hz fixed clock (mii_phy_tx) [ 1.000] fclock1 at simplebus2: 12500 Hz fixed clock (gmac_int_tx) [ 1.000] fclock2 at simplebus2: 2400 Hz fixed clock (osc24M) [ 1.000] fclock3 at simplebus2: 32768 Hz fixed clock (osc32k) [ 1.000] gtmr0 at simplebus0: Generic Timer [ 1.000] gtmr0: interrupting on GIC irq 27 [ 1.000] armgtmr0 at gtmr0: ARM Generic Timer (24000 kHz) [ 1.420] sun4ia10ccu0 at simplebus1: A20 CCU [ 1.420] sunxinmi0 at simplebus1: NMI [ 1.420] sunxigmacclk0 at simplebus2: GMAC MII/RGMII clock mux [ 1.420] sunxigpio0 at simplebus1: PIO [ 1.420] gpio0 at sunxigpio0: 175 pins [ 1.420] sunxigpio0: interrupting on GIC irq 60 [ 1.420] sunxisramc0 at simplebus1: SRAM Controller [ 1.420] sunxidebe0 at simplebus1: Display Engine Backend (display-backend@1e6) [ 1.420] sunxidebe1 at simplebus1: Display Engine Backend (display-backend@1e4) So in summary I seem to get up to video initialization. For my 4K TV I had to increase the MAX_FB reserved memory to 32M but that didn't help, also not connecting any HDMI device didn't help. The u-boot bootm command was change to manage ramdisk images thus the tips on our web site don't apply to the new bootm syntax. Any other things I can try or that I overlooked? Frank
Re: Java & NetBSD (JNA or Linux emulation)
On Fri, 29 Mar 2019, David Brownlee wrote: Trying to fire up wildfly under the Linux oracle-8 JDK instead of native OpenJDK8 seems to start up OK (bar an inotify error), and the dl4j processing works fine (yay), but the server will not respond to any http requests - the port connects but no response is ever received. Does adding -Djava.net.preferIPv4Stack=true help? ISTR having to use that in the past.
Re: Compile failure in nand.c
Hi Chavdar -- This define is generated by config in locators.h (kernel obj directory). Make sure you have sys/dev/flash/files.flash rev 1.4 and that you've run config on your kernel since updating. Cheers, Jared On Tue, 14 Nov 2017, Chavdar Ivanov wrote: Hi, I am getting: ... # compile nand/nand.o /home/sysbuild/amd64/tools/bin/x86_64--netbsd-gcc -O2 -g -std=gnu99 -Wall -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wno-sign- compare -Wsystem-headers -Wno-traditional -Wa,--fatal-warnings -Wreturn-type -Wswitch -Wshadow -Wcast-qual -Wwrite-strings -Wextra -Wno-unus ed-parameter -Wno-sign-compare -Werror -ffreestanding -fno-strict-aliasing -Wno-pointer-sign -mno-red-zone -mno-mmx -mno-sse -mno-avx -msoft-fl oat -mcmodel=kernel -fno-omit-frame-pointer -I/home/sysbuild/src/common/include --sysroot=/home/sysbuild/amd64/destdir -I/home/sysbuild/src/commo n/include -nostdinc -I. -I/home/sysbuild/src/sys/modules/nand -isystem /home/sysbuild/src/sys -isystem /home/sysbuild/src/sys/arch -isystem /home /sysbuild/src/sys/../common/include -D_KERNEL -D_LKM -D_MODULE -DSYSCTL_INCLUDE_DESCR -c/home/sysbuild/src/sys/dev/nand/nand.c /home/sysbuild/src/sys/dev/nand/nand.c: In function 'nand_search': /home/sysbuild/src/sys/dev/nand/nand.c:191:17: error: 'FLASHBUSCF_DYNAMIC' undeclared (first use in this function) if (cf->cf_loc[FLASHBUSCF_DYNAMIC] != 0) ^ /home/sysbuild/src/sys/dev/nand/nand.c:191:17: note: each undeclared identifier is reported only once for each function it appears in *** [nand.o] Error code 1 ... in my last few builds; I couldn't locate the missing symbol elsewhere. I am building now with the offending line #if-ed out. Chavdar Ivanov --
Re: re0 watchdog timeouts
Are you able to get performance numbers before/after this set of changes? It has a noticeable impact on my arm board. Cheers, Jared On Wed, 17 May 2017, Patrick Welche wrote: On Mon, May 15, 2017 at 11:19:55PM -0700, Soren Jacobsen wrote: On 05/16 12:27, sc dying wrote: Is the condition at line 1919 of ic/rtl8169.c inverted? It should be `!=' to make it act as before patch when RTKQ_IM_HW is disabed in if_re_pci.c. Good eye. Fixed. With this (ic/rtl8169.c 1.151), and if_re_pci.c 1.46 (i.e., 1.47 reverted) I have a happy network! (No timeouts, delays nor file corruption seen so far despite trying.) Cheers, Patrick
Re: HDMI audio attach help wanted
On Sat, 29 Apr 2017, Robert Elz wrote: I can try turning on more debug in there (there appears to be lots) but I'm not sure I can ever figure out what any of it means, or which debug in particular might be relevant. It looks like if you can set the global int drm_debug to 2 you should get driver debug messages from i915drm (including some about DP/HDMI audio setup).
Re: Debugging Epiphany/Midori (webkit-gtk based) on earmv6hf (RPI 2)
Default stack size limits on evbarm are too low for webkit-gtk. Bump it up
with ulimit -s and the g_dpgettext2 problem should go away.
On Sun, 31 May 2015, Stephan wrote:
Hi folks,
I am currently testing some applications on the RPI 2. Some work
pretty well, others not yet. As for webkit-gtk based browsers, I am
experiencing crashes from time to time.
One problem that occurs often seems to be related to g_dpgettext2 ()
from glib2. The top of the stack looks like this:
(gdb) bt
#0 0x636f7452 in ?? ()
#1 0x45ff3fa8 in g_dpgettext2 () from /usr/pkg/lib/libglib-2.0.so.0
#2 0x42ad6030 in gtk_stock_lookup () from /usr/pkg/lib/libgtk-x11-2.0.so.0
#3 0x42987b98 in gtk_action_set_stock_id () from
/usr/pkg/lib/libgtk-x11-2.0.so.0
#4 0x45f55cfc in g_object_set_valist () from /usr/pkg/lib/libgobject-2.0.so.0
#5 0x45f5642c in g_object_set () from /usr/pkg/lib/libgobject-2.0.so.0
#6 0x4298a27c in gtk_action_group_add_actions_full () from
/usr/pkg/lib/libgtk-x11-2.0.so.0
#7 0x4298a388 in gtk_action_group_add_actions () from
/usr/pkg/lib/libgtk-x11-2.0.so.0
#8 0x0004238c in ?? ()
#9 0x45f5322c in g_object_new_internal () from /usr/pkg/lib/libgobject-2.0.so.0
#10 0x45f5587c in g_object_new_valist () from /usr/pkg/lib/libgobject-2.0.so.0
#11 0x45f55a24 in g_object_new () from /usr/pkg/lib/libgobject-2.0.so.0
#12 0x00043ff0 in ephy_window_new_with_chrome ()
#13 0x0003ac94 in ephy_shell_new_tab_full ()
#14 0x0003f81c in ?? ()
#15 0x40a090e8 in webkit_marshal_OBJECT__OBJECT () from
/usr/pkg/lib/libwebkitgtk-1.0.so.0
#16 0x45f4e070 in g_closure_invoke () from /usr/pkg/lib/libgobject-2.0.so.0
#17 0x45f6154c in signal_emit_unlocked_R () from
/usr/pkg/lib/libgobject-2.0.so.0
#18 0x45f69278 in g_signal_emit_valist () from /usr/pkg/lib/libgobject-2.0.so.0
#19 0x45f69cac in g_signal_emit_by_name () from /usr/pkg/lib/libgobject-2.0.so.0
#20 0x409d9074 in
WebKit::FrameLoaderClient::dispatchCreatePage(WebCore::NavigationAction
const) () from /usr/pkg/lib/libwebkitgtk-1.0.so.0
...
The call to the topmost frame happens from 0x45ff3fa4 in the said
funtion. The disassembly from within gdb loos like this:
(gdb) disass g_dpgettext2
Dump of assembler code for function g_dpgettext2:
0x45ff3f44 +0: mov r12, sp
0x45ff3f48 +4: push{r4, r5, r6, r7, r8, r9, r10, r11, r12, lr, pc}
0x45ff3f4c +8: sub r11, r12, #4
0x45ff3f50 +12:sub sp, sp, #12
0x45ff3f54 +16:mov r9, r0
0x45ff3f58 +20:mov r0, r1
0x45ff3f5c +24:mov r6, r2
0x45ff3f60 +28:str r1, [r11, #-48] ; 0x30
0x45ff3f64 +32:bl 0x45fd3f44
0x45ff3f68 +36:mov r5, r0
0x45ff3f6c +40:mov r0, r6
0x45ff3f70 +44:bl 0x45fd3f44
0x45ff3f74 +48:add r10, r5, #1
0x45ff3f78 +52:add r8, r0, #1
0x45ff3f7c +56:add r3, r8, r10
0x45ff3f80 +60:add r3, r3, #14
0x45ff3f84 +64:bic r3, r3, #7
0x45ff3f88 +68:sub sp, sp, r3
0x45ff3f8c +72:mov r3, sp
0x45ff3f90 +76:lsr r7, r3, #3
0x45ff3f94 +80:lsl r4, r7, #3
0x45ff3f98 +84:ldr r1, [r11, #-48] ; 0x30
0x45ff3f9c +88:mov r2, r5
0x45ff3fa0 +92:mov r0, r4
0x45ff3fa4 +96:bl 0x45fd3efc
0x45ff3fa8 +100: mov r3, #4
0x45ff3fac +104: mov r2, r8
0x45ff3fb0 +108: strbr3, [r5, r7, lsl #3]
...
Now the jump target actually seems to be some random memory:
(gdb) info symbol 0x45fd3efc
No symbol matches 0x45fd3efc.
At least it is mapped to the text section of libglib2. It decodes like
follows which just looks like random garbage:
(gdb) x/5i 0x45fd3efc
0x45fd3efc: add r12, pc, #1048576 ; 0x10
0x45fd3f00: add r12, r12, #4096 ; 0x1000
0x45fd3f04: ldr pc, [r12, #1652]! ; 0x674
0x45fd3f08: add r12, pc, #1048576 ; 0x10
0x45fd3f0c: add r12, r12, #4096 ; 0x1000
The disassembly of g_dpgettext2() from objdump looks weird as well:
00033f44 g_dpgettext2:
33f44: e1a0c00dmov ip, sp
33f48: e92ddff0push{r4, r5, r6, r7, r8, r9, sl,
fp, ip, lr, pc}
33f4c: e24cb004sub fp, ip, #4
33f50: e24dd00csub sp, sp, #12
33f54: e1a09000mov r9, r0
33f58: e1a1mov r0, r1
33f5c: e1a06002mov r6, r2
33f60: e50b1030str r1, [fp, #-48] ; 0x30
33f64: ebff7ff6bl 13f44 g_mem_chunk_new-0x7c
33f68: e1a05000mov r5, r0
33f6c: e1a6mov r0, r6
33f70: ebff7ff3bl 13f44 g_mem_chunk_new-0x7c
33f74: e285a001add sl, r5, #1
33f78: e2808001add r8, r0, #1
33f7c: e088300aadd r3, r8, sl
33f80: e283300eadd r3, r3, #14
33f84: e3c33007bic r3, r3, #7
33f88: e04dd003sub sp, sp, r3
33f8c: e1a0300dmov r3, sp
33f90:
Re: Debugging Epiphany/Midori (webkit-gtk based) on earmv6hf (RPI 2)
I saw the same issue a while back, don't remember exactly which version of
glib2 it was. I LD_PRELOAD'd a version of g_dpgettext2 that always
returned NULL and it made the crashes go away. g_dpgettext2 uses alloca
internally, so I increased stack size and the crashes went away again.
https://git.gnome.org/browse/glib/tree/glib/ggettext.c#n271
On Sun, 31 May 2015, Stephan wrote:
That does not help unfortunately - just tested again with ulimit -s unlimited.
I dont think we are hitting the stack boundary
because sp is still inside the stack region outlined by pmap. Have you seen the
very same issue as I do?
Am 31.05.2015 19:48 schrieb Jared McNeill jmcne...@invisible.ca:
Default stack size limits on evbarm are too low for webkit-gtk. Bump it
up with ulimit -s and the g_dpgettext2
problem should go away.
On Sun, 31 May 2015, Stephan wrote:
Hi folks,
I am currently testing some applications on the RPI 2. Some work
pretty well, others not yet. As for webkit-gtk based browsers, I am
experiencing crashes from time to time.
One problem that occurs often seems to be related to g_dpgettext2 ()
from glib2. The top of the stack looks like this:
(gdb) bt
#0 0x636f7452 in ?? ()
#1 0x45ff3fa8 in g_dpgettext2 () from /usr/pkg/lib/libglib-2.0.so.0
#2 0x42ad6030 in gtk_stock_lookup () from
/usr/pkg/lib/libgtk-x11-2.0.so.0
#3 0x42987b98 in gtk_action_set_stock_id () from
/usr/pkg/lib/libgtk-x11-2.0.so.0
#4 0x45f55cfc in g_object_set_valist () from
/usr/pkg/lib/libgobject-2.0.so.0
#5 0x45f5642c in g_object_set () from
/usr/pkg/lib/libgobject-2.0.so.0
#6 0x4298a27c in gtk_action_group_add_actions_full () from
/usr/pkg/lib/libgtk-x11-2.0.so.0
#7 0x4298a388 in gtk_action_group_add_actions () from
/usr/pkg/lib/libgtk-x11-2.0.so.0
#8 0x0004238c in ?? ()
#9 0x45f5322c in g_object_new_internal () from
/usr/pkg/lib/libgobject-2.0.so.0
#10 0x45f5587c in g_object_new_valist () from
/usr/pkg/lib/libgobject-2.0.so.0
#11 0x45f55a24 in g_object_new () from
/usr/pkg/lib/libgobject-2.0.so.0
#12 0x00043ff0 in ephy_window_new_with_chrome ()
#13 0x0003ac94 in ephy_shell_new_tab_full ()
#14 0x0003f81c in ?? ()
#15 0x40a090e8 in webkit_marshal_OBJECT__OBJECT () from
/usr/pkg/lib/libwebkitgtk-1.0.so.0
#16 0x45f4e070 in g_closure_invoke () from
/usr/pkg/lib/libgobject-2.0.so.0
#17 0x45f6154c in signal_emit_unlocked_R () from
/usr/pkg/lib/libgobject-2.0.so.0
#18 0x45f69278 in g_signal_emit_valist () from
/usr/pkg/lib/libgobject-2.0.so.0
#19 0x45f69cac in g_signal_emit_by_name () from
/usr/pkg/lib/libgobject-2.0.so.0
#20 0x409d9074 in
WebKit::FrameLoaderClient::dispatchCreatePage(WebCore::NavigationAction
const) () from /usr/pkg/lib/libwebkitgtk-1.0.so.0
...
The call to the topmost frame happens from 0x45ff3fa4 in the said
funtion. The disassembly from within gdb loos like this:
(gdb) disass g_dpgettext2
Dump of assembler code for function g_dpgettext2:
0x45ff3f44 +0: mov r12, sp
0x45ff3f48 +4: push {r4, r5, r6, r7, r8, r9, r10, r11,
r12, lr, pc}
0x45ff3f4c +8: sub r11, r12, #4
0x45ff3f50 +12: sub sp, sp, #12
0x45ff3f54 +16: mov r9, r0
0x45ff3f58 +20: mov r0, r1
0x45ff3f5c +24: mov r6, r2
0x45ff3f60 +28: str r1, [r11, #-48] ; 0x30
0x45ff3f64 +32: bl 0x45fd3f44
0x45ff3f68 +36: mov r5, r0
0x45ff3f6c +40: mov r0, r6
0x45ff3f70 +44: bl 0x45fd3f44
0x45ff3f74 +48: add r10, r5, #1
0x45ff3f78 +52: add r8, r0, #1
0x45ff3f7c +56: add r3, r8, r10
0x45ff3f80 +60: add r3, r3, #14
0x45ff3f84 +64: bic r3, r3, #7
0x45ff3f88 +68: sub sp, sp, r3
0x45ff3f8c +72: mov r3, sp
0x45ff3f90 +76: lsr r7, r3, #3
0x45ff3f94 +80: lsl r4, r7, #3
0x45ff3f98 +84: ldr r1, [r11, #-48] ; 0x30
0x45ff3f9c +88: mov r2, r5
0x45ff3fa0 +92: mov r0, r4
0x45ff3fa4 +96: bl 0x45fd3efc
0x45ff3fa8 +100: mov r3, #4
0x45ff3fac +104: mov r2, r8
0x45ff3fb0 +108: strb r3, [r5, r7, lsl #3]
...
Now the jump target actually seems to be some random memory
Re: RPI2 kernel dosn't link
Wups, I've checked in the fix. Thanks! On Sat, 14 Mar 2015, Kurt Schreiner wrote: Hi, with -current source cvs-updated some minutes ago compiling a kernel for RPI2 fails to link with cpu.o: In function `cpu_attach': cpu.c:(.text+0xa0c): undefined reference to `pmap_tlb0_info' cpu.c:(.text+0xa14): undefined reference to `pmap_tlb0_info' cpu.c:(.text+0xa20): undefined reference to `pmap_tlb_info_attach' pmap.o: In function `pmap_clearbit.isra.17': pmap.c:(.text+0x894): undefined reference to `pmap_tlb_invalidate_addr' pmap.o: In function `pmap_remove': pmap.c:(.text+0xe7c): undefined reference to `pmap_tlb_invalidate_addr' pmap.c:(.text+0x1078): undefined reference to `pmap_tlb_invalidate_addr' pmap.c:(.text+0x10f8): undefined reference to `pmap_tlb_invalidate_addr' pmap.o: In function `pmap_protect': pmap.c:(.text+0x1c48): undefined reference to `pmap_tlb_invalidate_addr' pmap.o:pmap.c:(.text+0x20c4): more undefined references to `pmap_tlb_invalidate_addr' follow ... after adding no options ARM11_COMPAT_MMU to .../conf/RPI2 to revert the change (for RPI) done in http://mail-index.netbsd.org/source-changes/2015/03/14/msg063971.html for RPI2) the kernel links fine again. === RCS file: /cvsroot/src/sys/arch/evbarm/conf/RPI2,v retrieving revision 1.2 diff -u -r1.2 RPI2 --- RPI24 Mar 2015 17:02:17 - 1.2 +++ RPI214 Mar 2015 17:42:30 - @@ -6,6 +6,7 @@ include arch/evbarm/conf/RPI +no options ARM11_COMPAT_MMU no options CPU_ARM1176 no options TPIDRPRW_IS_CURLWP no options __HAVE_MM_MD_CACHE_ALIASING If thats the right thing to do is another question. ;-) Kurt
Re: usermode
You need to build and load the syscallemu module from sys/arch/usermode/modules/syscallemu Cheers, Jared On Fri, 6 Feb 2015, Patrick Welche wrote: Just had a go at amd64 GENERIC_USERMODE. Am I missing something or should it be as easy as build netbsd and run it? I see (netbsd.gdb -vx): Information retrieved from system and elf image min VM address at 0x1000 start kernelat 0x4000 end kernelat 0x4020d41e end of init. data at 0x40519430 1st end of data at 0x4055e688 CUR end dataat 0x4055e688 ^MMemory summary ^M kmem_user_start 0x1000 ^M kmem_user_end 0x2fc0 ^M kmem_k_start0x4000 ^M kmem_k_end 0x4020e000 ^M kmem_kvm_start 0x2fe0 ^M kmem_kvm_end0x3fe0 ^M DRAM_cfg1073741824 ^M kvmsize 268435456 ^M user_len 801107968 ^MCreating memory mapped backend claiming 10240 KB of pv_table for 262144 pages of physical memory tlb va-pa lookup table is 2048 KB for 262143 logical pages pv_table initialiased correctly, mmap works kernel tlb entries initialized correctly kernel pmap l1 table initialiased correctly pmap_kenter_pa : v 0x2fe0, p 0x0, prot 3, flags 0 pmap_update_page: ppn 0, pv-pv_map = 0x40533fc0 page_activate: (va 0x2fe0, pa 0x0, prot 3, ppl 3) - 0x2fe0 page_activate: (va 0x2fe0, pa 0x0, prot 3, ppl 3) - 0x2fe0 ... pmap_update_page: ppn 3584, pv-pv_map = 0x40533fc0 page_activate: (va 0x30c0, pa 0xe0, prot 3, ppl 3) - 0x30c0 page_activate: (va 0x30c0, pa 0xe0, prot 3, ppl 3) - 0x30c0 kernel pmap entries mem added to the kernel pmap Program received signal SIGSYS, Bad system call. 0x401ed46a in syscall () (gdb) bt #0 0x401ed46a in syscall () #1 0x4489 in thunk_syscallemu_init (ustart=0x1000, uend=0x2fc0) at ../../../../arch/usermode/usermode/thunk.c:121 #2 0x400e1f79 in pmap_bootstrap () at ../../../../arch/usermode/usermode/pmap.c:420 #3 0x400af15a in main (argc=optimized out, argv=0x7f7fdb60) at ../../../../arch/usermode/usermode/machdep.c:219 I wonder which syscall() function is called, as I Index: usermode/syscall.c === RCS file: /cvsroot/src/sys/arch/usermode/usermode/syscall.c,v retrieving revision 1.24 diff -u -r1.24 syscall.c --- usermode/syscall.c 26 Jun 2013 15:11:30 - 1.24 +++ usermode/syscall.c 6 Feb 2015 10:31:45 - @@ -113,7 +113,7 @@ rval[0] = rval[1] = 0; error = md_syscall_getargs(l, ucp, nargs, argsize, args); -#if 0 +#if 1 aprint_debug(syscall no. %d, , code); aprint_debug(nargs %d, argsize %d = , nargs, argsize); thunk_printf_debug(syscall no. %d, , code); so expected to see some printout, or? Cheers, Patrick
