FYI: new X server in -current, among other X things
On Friday 15 Jul 2022, at 15:12, matthew green wrote: > i've updated most of xsrc to their latest versions. > > there are probably a few build issues left to find > across all ports, and perhaps some run-time ones too > but basic testing looks fine for me. > > please send-pr or email here if you find problems. Hi, A bit late ... but I just updated and found a wskbd/xorg.conf rather small issue but also rather painful, so I report here in case something can be improved (including my own limited knowledge on this topic :) Before, I used to have a InputDevice keyboard section in my xorg.conf, so that I could pass some xkb options (required to all the extra sun keys working): Option "XkbModel""sun_type6_usb" Option "XkbLayout" "us" Option "XkbOptions" "compose:menu" Option "XkbRules""base" After the update, I noticed this stopped working, because: (WW) Hotplugging is on, devices using drivers 'kbd', 'mouse' or 'vmmouse' will be disabled. So, I tried to disable "hotplugging" (Option "AutoAddDevices" "false") and kept the InputDevice section with: Driver "kbd" Option "Device" "/dev/wskbd" This failed because "/dev/wskbd" was said to be already open (by whom?). Using "/dev/wskbd0" instead mostly worked, except that switching to VT0 was leaving the keyboard in a weird state, sending escape codes instead of normal keys and preventing to type anything useful. (but a few times it was also kind of self-reparing and was working ...) So basically the issue is that manually adding a keyboard does not work anymore? (also, I don't fully understand the difference between /dev/wskbd and /dev/wskb0: man 4 wskbd, kbd, wscons, wsmux don't talk about it, maybe I missed some other documentation). I finally switched back to hotplugging, and added a InputClass section instead of a InputDevice, with MatchDriver "kbd" and my custom xkb options. (I failed to use a "MachUSBID" setting, which would have been more correct, but probably wscons does not report the USB id to Xorg). So all-in-all I'm fine with this setting, but it took me quite some time to figure out what to do and I'm still not sure I did it the right way :) Best, Anthony
Re: 9.99.73 NFS file corruption
On Sunday 18 Oct 2020, at 17:59, Rin Okuyama wrote: > Thank you very much for providing test case. I can reproduce the > problem on amd64 and i386. I've reverted that commit. I've been running 9.99.74 / Oct 18 for more than 12h and I did not see any issues so far. Thanks for your help!
9.99.73 NFS file corruption
On Friday 16 Oct 2020, at 11:05, Anthony Mallet wrote:
> For some databases (especially those in the firefox profile, but not
> only), inserting a row in some tables (not all) from a NFS client does
> not update the file on the server.
I made some progress on this, and could apparently fix something. See
attached a sample script that reliably reproduces the issue.
To summarize: when the script is run on the NFS client, changes in the
sqlite database do appear on the NFS client, but do not appear on
the server.
As Chuck suggested in another e-mail, reverting uvm_bio.c to previous 1.121
$NetBSD: uvm_bio.c,v 1.121 2020/07/09 09:24:32 rin Exp $
appears to fix the issue (at least the test script was working 3 times
in a row while it always failed with uvm_bio.c:1.222).
Hope this helps ...
Anthony
#!/bin/sh
sqlite=/usr/bin/sqlite3
db=test.sqlite
nfsserver=cactus
rm -f $db
$sqlite $db 'create table t(x text, i integer primary key autoincrement)'
$sqlite $db 'insert into t (x) values ("abcdefghijklmnopqrstuvwxyz")'
x=`$sqlite $db 'select * from t;'`
y=`ssh $nfsserver $sqlite $db "'select * from t;'"`
test "$x" = "$y" || { echo "fail: $x vs $y"; exit 2; }
echo ok
9.99.73 NFS file corruption
Hi, As wiz@ and reinoud@ already mentionned¹, I also experience frequent corruption with sqlite3 databases over NFS. There is no concurrent access to the database (single NFS client). For some databases (especially those in the firefox profile, but not only), inserting a row in some tables (not all) from a NFS client does not update the file on the server. However, on the client, the change is still visible for some time. Also, a 'vacuum' command leads to 'database is corrupted' on both the client and the server. But I could not reproduce this on a fresh new database yet. So, pure speculation, this makes me think of a cache flushing issue? This is since NetBSD 9.99.73 / Oct 10, but my previous working kernel was only NetBSD 9.99.65 / Jun 9, so probably a bit too old to narrown down to the faulty commit. ¹ http://mail-index.netbsd.org/current-users/2020/10/11/msg039671.html http://mail-index.netbsd.org/tech-kern/2020/10/12/msg026830.html
Re: npf lock issue?
On Friday 21 Apr 2017, at 23:41, Anthony Mallet wrote: > Yes. npf does not seem to be involed at all. I kept the same message > subject for consistency but I guess a new thread should be started. Closing this thread, npf is not involved at all. For the records, the issue is discussed in PR/52252, with an explation/possible fix.
Re: npf lock issue?
On Friday 21 Apr 2017, at 22:15, Mindaugas Rasiukevicius wrote: | > #11 0x804b3075 in panic ( | > fmt=fmt@entry=0x806b6790 "uvm_km_check_empty: va %p | > has pa 0x%llx") at /usr/src/sys/kern/subr_prf.c:258 | > #12 0x8044ed05 in uvm_km_check_empty ( | > map=map@entry=0x8081c780 , | > start=, end=18446744071572586496) at | > /usr/src/sys/uvm/uvm_km.c:563 | > #13 0x8045268f in uvm_map ( | > map=map@entry=0x8081c780 , | > startp=startp@entry=0xfe80cc383918, size=size@entry=65536, | > uobj=, uoffset=uoffset@entry=-1, | > align=, flags=, | > flags@entry=5927) at /usr/src/sys/uvm/uvm_map.c:1096 | > #14 0x8044ee4f in uvm_km_alloc ( | > map=0x8081c780 , | > size=size@entry=65536, align=align@entry=4096, | > flags=flags@entry=49) at /usr/src/sys/uvm/uvm_km.c:621 | > #15 0x80240a4d in alloc_chunk (size=65536) | > at | > /usr/src/sys/external/bsd/sljit/dist/sljit_src/sljitExecAllocator.c:110 | > #16 sljit_malloc_exec (size=) | > at | > /usr/src/sys/external/bsd/sljit/dist/sljit_src/sljitExecAllocator.c:221 | > 221 header = (struct block_header*)alloc_chunk(chunk_size); | > | > Does this ring a bell to anyone? | | This looks like a bug in sljit rather than NPF per se. The panic | message suggests some kind of KVA leak. I suspect it might be a | result of e.g. a free_chunk() call with an incorrect size in the | sljitExecAllocator.c code. Yes. npf does not seem to be involed at all. I kept the same message subject for consistency but I guess a new thread should be started. Actually, sljit does not seem involed either. After my post, I noticed that anything that tries to uvm_km_alloc() from module_map has the same failure. On the failing machine, options MODULAR is used but I have no modules. So npf happens to be the first piece of code allocating memory from module_map (sljit actually). But, for instance, a modload(1) right after boot also fails in exactly the same way. The page that uvm_km_check_empty() finds already mapped is the very first one of module_map. I checked the latest commits in uvm since January without noticing anything suspect (and I don't have UVM_HOTPLUG defined either). But my knowledge of uvm is nearly zero ... so I did not really progress on this.
