Re: modesetting vs intel in 10.0
(reviving an old tread) On Mon 04 Sep 2023 at 20:18:49 -0400, Greg Troxel wrote: > Earlier the screen would go black for a few seconds pretty often (like 2 > every 30), with modesetting and also intel. I am now pretty sure that > this was because I was running zpool scrub. Without a scrub, I don't > get this. > > My graphics is: > > i915drmkms0 at pci0 dev 2 function 0: Intel UHD Graphics 630 (rev. 0x02) > i915drmkms0: interrupting at msi4 vec 0 (i915drmkms0) > i915drmkms0: notice: Failed to load DMC firmware i915/kbl_dmc_ver1_04.bin. > Disabling runtime power management. > [drm] Initialized i915 1.6.0 20200114 for i915drmkms0 on minor 0 > intelfb0 at i915drmkms0 > intelfb0: framebuffer at 0xc004, size 2560x1440, depth 32, stride 10240 Out of desperation, I pulled out my Radeon HD 5450 card and now I am using the same graphics as you are. > With the modesetting driver, it is also mostly great, except: > > same github comment box artifacts I didn't test this. > cursor is often not quite right and it's a little confusing to resize > windows as the change-icon clues are a bit off. It's like the "update > cursor" write calls get garbled output and then resolve. I see this too. I > scrolling in firefox has text with some scan lines messed up and then > over a second or two they resolve. I see this changing virtual > desktops to firefox also. switching to xterms is fine. I see this in firefox (123) menus when moving the mouse through the menus: the highlighting of the entries doesn't get painted right away. It kind of looks like some cached written data doesn't get pushed out to the final destination right away. The same could explain the mouse cursor. nia@ suggested to run xcompmgr. It fixes the Firefox menus for me, but not the mouse cursor. Also it breaks my use of xv (graphics/xv) to set my desktop background (and change it every 5 minutes). I'm trying to use feh for that now. With this config (kernel 10 + intel hw + modesetting driver) the x11/redshift program doesn't work any more (it works on my Thinkpad T470s with kernel 10 + intel hw + intel driver). -Olaf. -- ___ Olaf 'Rhialto' Seibert \X/ There is no AI. There is just someone else's work. --I. Rose signature.asc Description: PGP signature
Re: Upgrade of current pkgsrc fails due to gtk3 on 10.99
On Mon 15 Apr 2024 at 17:19:14 +0200, Riccardo Mottola wrote: > Does pkg_rr has a "cache" or is it fresh calculated information? It has a sort of cache, as hinted at by this: > rr> WARNING: mismatch variable not set due to permissions; > rr> mismatch status will not persist. where (if allowed) it sets a "mismatch" variable in the pkgdb on packages that are reported as mismatches. So the next time you don't need to run pkg_chk (the -u option) again. If the package gets deleted for some reason, the flag is deleted with it. So this would not explain your case, I think. > Riccardo -Olaf. -- ___ Olaf 'Rhialto' Seibert \X/ There is no AI. There is just someone else's work. --I. Rose signature.asc Description: PGP signature
Re: gdb crashes on current
On Thu 21 Mar 2024 at 00:29:40 +0500, Vitaly Shevtsov wrote: > Hello! > > It's when you run it with the `-tui` option - text user interface. > Also you can toggle it with C-x C-a or with "tui enable" and "tui disable", too... It can be kind of nice, when it works. -Olaf. -- ___ Olaf 'Rhialto' Seibert \X/ There is no AI. There is just someone else's work. --I. Rose signature.asc Description: PGP signature
Re: Removing a superfluous warning from xf86-input-ws/dist/src/ws.c
On Mon 05 Feb 2024 at 20:57:11 +0100, Rhialto wrote:
> I think I like the second suggestion slightly better, so I'll go with
> that. I'll do a test build first, even though it seems trivial. I didn't
> do a build in a while anyway...
I'll commit this then, if that looks ok. (I'm asking to double-check
since this isn't my usual area of committing - I test-compiled it but
unfortunately the build for -current doesn't drop in into 10.0RC3 as I
have it installed)
Index: ws.c
===
RCS file: /cvsroot/xsrc/external/mit/xf86-input-ws/dist/src/ws.c,v
retrieving revision 1.16
diff -u -r1.16 ws.c
--- ws.c4 Dec 2021 15:21:55 - 1.16
+++ ws.c6 Feb 2024 17:40:57 -
@@ -747,7 +747,9 @@
dw = 0;
}
#if GET_ABI_MAJOR(ABI_XINPUT_VERSION) >= 14
- if (hscroll || vscroll) {
+ static int warned = 0;
+ if ((hscroll || vscroll) && !warned) {
+ warned = 1;
xf86Msg(X_WARNING, "%s: hscroll=%d, vscroll=%d\n",
pInfo->name, hscroll, vscroll);
valuator_mask_zero(priv->scroll_mask);
-Olaf.
--
___ Olaf 'Rhialto' Seibert
\X/ There is no AI. There is just someone else's work. --I. Rose
signature.asc
Description: PGP signature
Re: Removing a superfluous warning from xf86-input-ws/dist/src/ws.c
On Mon 05 Feb 2024 at 10:18:09 +1100, matthew green wrote: > perhaps convert into a DBG(4, ...)? On Mon 05 Feb 2024 at 02:20:25 +0300, Valery Ushakov wrote: > May be make it reported only once, so that the message is still there > in the log, but it's not spammed uselessly, adding no new information? I think I like the second suggestion slightly better, so I'll go with that. I'll do a test build first, even though it seems trivial. I didn't do a build in a while anyway... -Olaf. -- ___ Olaf 'Rhialto' Seibert \X/ There is no AI. There is just someone else's work. --I. Rose signature.asc Description: PGP signature
Removing a superfluous warning from xf86-input-ws/dist/src/ws.c
In xsrc/external/mit/xf86-input-ws/dist/src/ws.c there is this fragment:
#if GET_ABI_MAJOR(ABI_XINPUT_VERSION) >= 14
if (hscroll || vscroll) {
xf86Msg(X_WARNING, "%s: hscroll=%d, vscroll=%d\n",
pInfo->name, hscroll, vscroll);
valuator_mask_zero(priv->scroll_mask);
valuator_mask_set_double(priv->scroll_mask,
HSCROLL_AXIS, (double) hscroll);
valuator_mask_set_double(priv->scroll_mask,
VSCROLL_AXIS, (double) vscroll);
xf86PostMotionEventM(pInfo->dev, FALSE,
priv->scroll_mask);
}
#endif
and it prints this warning every time I scroll using the touchpad on my
ThinkPad. Apparently it is a "new" way for touchpads to report scrolling
(both horizontal and vertica).
These messages are filling up my /var/log/Xorg.0.log and wearing out my
NVMe unnecesarily.
This touchpad method is not supported by the xf86-input-mouse driver so
with that one the touchpad doesn't scroll.
Shall I just remove the warning?
-Olaf.
--
___ Olaf 'Rhialto' Seibert
\X/ There is no AI. There is just someone else's work. --I. Rose
signature.asc
Description: PGP signature
Small mystery with grep -o -i
I came across a configure script that used this test: echo 'alma,korte,banan' | grep -oEia ',K[^,]+,' and expected the result to be ,korte, That looks fine: -o prints only the matching part from the line -E selects egrep syntax, which allows the + operator -i makes it case-insensitive, so that ,k matches ,K -a makes grep assume the input is ascii, which is a no-op here. However, on 9.3 it prints nothing. On 10.0_RC3, the same. By trying simpler versions, it appears it is the combination -o -i that causes the problem. If you leave out -i, and adjust pattern and input to have matching case, then the test case works. Another simplification, omitting -E and replacing + by *, has no effect. If you use another way to find what substring was matched, by replacing -o with --color=always, you find similar results. Interestingly, this: echo 'alma,korte,banan' | grep -Eia --color=always ',K[^,]+,' does actually print the input line as a match, but nothing in it is coloured as the match. I built (on the 9.3 system) the source from -current src/usr.bin/grep, and there it works. This confused me for a while - then I discovered that this isn't the version in actual use. That's the one in src/external/gpl2/grep. The GNU grep from pkgsrc (I tried grep-3.11) works on this example. So maybe all that is needed is to update our in-tree version. It is GPL 3+, though. The one we have seems to be version 2.5.1a(?), GPL 2+, The CHANGES file from upstream https://git.savannah.gnu.org/git/grep.git lists: * Noteworthy changes in release 2.6 (2010-03-23) [stable] ... grep -i -o would fail to report some matches; grep -i --color, while not missing any line containing a match, would fail to color some matches. related to commit 70e236167c3973fc428d2b5b297218fde9b68e73, committed 2010-03-17 Unfortunately this is a rather large commit, due to multibyte support. I expect that some of the changes are not directly related to this bug, but the parts that clearly are, are still not trivial. So I expect that patching just this bug isn't trivial, and simply importing a recent version from upstream is to be preferred. Ours is very, very old... -Olaf. -- ___ Olaf 'Rhialto' Seibert \X/ There is no AI. There is just someone else's work. --I. Rose signature.asc Description: PGP signature
Re: Call for testing: certctl, postinstall, TLS trust anchors
On Sun 08 Oct 2023 at 16:04:20 +, Taylor R Campbell wrote: > As far as I'm aware, S/MIME is only ever seriously deployed within a > single organization at a time (or a closed set of partnering > organizations). So I don't expect anything about it to seriously work > out of the box and I have no idea what public CAs do about it. mail/mutt supports S/MIME signing at least out of its box, but by default it uses its own management program `smime_keys` to manage the keys, stored in ~/.smime. That's the closest I know of. Sometimes I receive a mail signed with S/MIME from some mailing list but I don't think that mutt ever told me that the signature matched (due to the certificates not being set up). -Olaf. -- ___ Olaf 'Rhialto' Seibert \X/ There is no AI. There is just someone else's work. --I. Rose signature.asc Description: PGP signature
Re: cpu temperature readings
On Thu 29 Jun 2023 at 16:50:27 +0700, Robert Elz wrote: > And then for fun, at 3401 ... this one I needed to run the test several > times until the kernel picked one of the fastest processors to run it on When I was muddling with estd to dynamically slow down my cpus when not in use, I was told that the xx01 frequency on modern (Intel) processors will do that, even though in many sources that setting is still called "turbo boost" or similar. The other frequencies would actually be fixed. In your cpu this may be the case too, which would give confusing results if you're not aware of the possibility. -Olaf. -- ___ Olaf 'Rhialto' Seibert \X/ There is no AI. There is just someone else's work. --I. Rose signature.asc Description: PGP signature
Re: Reproducible deadlock? with VND on NetBSD 10.0_BETA Dom0 on Xen 4.15
On Thu 18 May 2023 at 07:37:38 +0200, Matthias Petermann wrote: > 1) Create the image file as sparse file: I seem to remember that vnds don't like sparse files. Maybe you can try with a non-sparse (dense?) file. -Olaf. -- ___ Olaf 'Rhialto' Seibert \X/ There is no AI. There is just someone else's work. --I. Rose signature.asc Description: PGP signature
Re: How to BIOS-boot from NVMe device?
On Thu 08 Sep 2022 at 12:36:46 -0400, Brad Spencer wrote: > This is a clear indication of a UEFI boot. There is confusion in the > docs about where the boot.cfg file should be located. I have also found > that the desired behavior works if it is in the root of the EFI > filesystem. How does the UEFI system decide what to boot? It obviously requires a special partition on a disk. But what if there are multiple files in there which are potentially bootable? I was expecting some built-in UEFI shell in my newest computer, so that I can handle such cases myself, or something like that. However, I found no signs of such a shell (and when I read about it, it generally seems to be assumed that it is indeed built-in). Also, even if I would find one as a file (I didn't find ut yet) and put it in my EFI partition, I'm not sure how to start it, since the system as shown no signs that it offers boot opptions more detailed than "boot from a disk". -Olaf. -- ___ "Buying carbon credits is a bit like a serial killer paying someone else to \X/ have kids to make his activity cost neutral." -The BOFHfalu.nl@rhialto signature.asc Description: PGP signature
Re: Branching for NetBSD 10
On Fri 03 Jun 2022 at 21:08:15 +0200, Reinoud Zandijk wrote: > Well I'd like to add another point! Fixed i915 DRM support! That seems to work on my laptop (although glxgears doesn't work, so it must be missing some things) but the touchpad doesn't have any effect in my case. -Olaf. -- ___ "Buying carbon credits is a bit like a serial killer paying someone else to \X/ have kids to make his activity cost neutral." -The BOFHfalu.nl@rhialto signature.asc Description: PGP signature
Re: Radeon HD 5450?
On Tue 10 May 2022 at 15:44:19 -0700, Phil Nelson wrote: > Is the 5450 too old a device for the UEFI boot only machine or > is there a way to get the BIOS address for the autoconfiguration? I have one of those too in my "new" machine, and I also noticed that when I booted in UEFI mode, it didn't work properly; but it has been a while, I don't remember exactly what the issue was. I'm booting in "BIOS mode" and with that it works fine. > --Phil -Olaf. -- ___ "Buying carbon credits is a bit like a serial killer paying someone else to \X/ have kids to make his activity cost neutral." -The BOFHfalu.nl@rhialto signature.asc Description: PGP signature
Re: HEADS UP: Merging drm update (Lenovo X230 mode switch issue in UEFI mode only, BIOS works)
On Fri 31 Dec 2021 at 11:30:32 +0100, Matthias Petermann wrote: > - When I boot current in UEFI mode, after the mode switch it only displays a > blank screen with a white background. After that, within a few seconds, a > kind of randomly structured dark spot develops from the center of the > screen, which then stretches to the edge of the screen [1]. I think I have seen that sort of effect in the past when playing with various sleep modes of my laptop. It may be that the display (or some display-related thing) is powered off and decaying. -Olaf. -- ___ "Buying carbon credits is a bit like a serial killer paying someone else to \X/ have kids to make his activity cost neutral." -The BOFHfalu.nl@rhialto signature.asc Description: PGP signature
Re: Anyone feel like fixing pkgsrc/emulators/tme ?
On Sat 10 Jul 2021 at 15:39:10 +0200, Rhialto wrote: > How far did you get? I tried sun3, and I got to booting the ramdisk > kernel from tape. But when I did the "dd bs=32k if=/dev/nrst0 > of=/dev/rsd0b" I got a core dump. Possibly I had not used edlabel > correctly due to it not getting a geometry it believed. Indeed, there I misinterpreted the size of my 1G disk, and put sd0b waaay out of bounds. I tried again, with partition b in cyl 1-63 and a in 64-1023. I could not start b at 0; in that case the dd command claimed it was read-only. > (And the mt -f /dev/nrst0 rewind / fsf 2 don't seem to match the > position of the miniroot.fs, which the instructions tell you to put as > 4th file) and that was actually corrected in Fredette's instructions. I installed all sets including X. The install script seemed to overwrite the generic /netbsd kernel (which I installed from tape in one of the sets) with the install kernel, so I had to re-extract it from tape. Startx works fine, but the mouse doesn't do anything, so then you're stuck... I didn't try networking. This is still on 9.2, not -current. -Olaf. -- ___ "Buying carbon credits is a bit like a serial killer paying someone else to \X/ have kids to make his activity cost neutral." -The BOFHfalu.nl@rhialto signature.asc Description: PGP signature
Re: Anyone feel like fixing pkgsrc/emulators/tme ?
On Sat 10 Jul 2021 at 16:05:31 +0200, Rhialto wrote: > I also didn't succeed in powering up the sun4c. When I gave the command > "command board0 power up", nothing appeared to happen. The tmesh window > remained gray, I did not get the tmesh> prompt back. (That happens for > sun3). In fact, any command I typed at the prompt there had the same effect. To reduce the scope, I started with an empty configuration and pasted just the first configuration line: .../scratch/tmp/sun4c$ tmesh /dev/null tmesh> ls tmesh> board0: tme/machine/sun4 name Calvin tmesh> ls board0: tme/machine/sun4 name Calvin tmesh> Segmentation fault (core dumped) :.../scratch/tmp/sun4c$ -Olaf. -- ___ "Buying carbon credits is a bit like a serial killer paying someone else to \X/ have kids to make his activity cost neutral." -The BOFHfalu.nl@rhialto signature.asc Description: PGP signature
Re: Anyone feel like fixing pkgsrc/emulators/tme ?
xr-x 1 root wheel 27 Jun 16 20:40 /usr/pkg/lib/libpangoft2-1.0.so.0 -> libpangoft2-1.0.so.0.4800.4 lrwxr-xr-x 1 root wheel 17 Jun 16 20:19 /usr/pkg/lib/libpcre.so.1 -> libpcre.so.1.2.12 lrwxr-xr-x 1 root wheel 19 Jun 16 20:25 /usr/pkg/lib/libpng16.so.16 -> libpng16.so.16.37.0 I also didn't succeed in powering up the sun4c. When I gave the command "command board0 power up", nothing appeared to happen. The tmesh window remained gray, I did not get the tmesh> prompt back. (That happens for sun3). > Martin -Olaf. -- ___ "Buying carbon credits is a bit like a serial killer paying someone else to \X/ have kids to make his activity cost neutral." -The BOFHfalu.nl@rhialto signature.asc Description: PGP signature
Re: Anyone feel like fixing pkgsrc/emulators/tme ?
On Sat 10 Jul 2021 at 15:41:27 +0200, Martin Husemann wrote: > On Sat, Jul 10, 2021 at 03:39:10PM +0200, Rhialto wrote: > > How far did you get? I tried sun3, and I got to booting the ramdisk Oh this is with NetBSD/amd64 9.2, not -current. I don't know if that makes a difference. -Olaf. -- ___ "Buying carbon credits is a bit like a serial killer paying someone else to \X/ have kids to make his activity cost neutral." -The BOFHfalu.nl@rhialto signature.asc Description: PGP signature
Re: Anyone feel like fixing pkgsrc/emulators/tme ?
On Sat 10 Jul 2021 at 12:50:08 +0200, Martin Husemann wrote: > Anyone feel like looking into that? The homepage has nice instructions and > setup is very straight forward. I am mostly interested in sun2, sun3 and > sun4c currently. How far did you get? I tried sun3, and I got to booting the ramdisk kernel from tape. But when I did the "dd bs=32k if=/dev/nrst0 of=/dev/rsd0b" I got a core dump. Possibly I had not used edlabel correctly due to it not getting a geometry it believed. (And the mt -f /dev/nrst0 rewind / fsf 2 don't seem to match the position of the miniroot.fs, which the instructions tell you to put as 4th file) > Martin -Olaf. -- ___ "Buying carbon credits is a bit like a serial killer paying someone else to \X/ have kids to make his activity cost neutral." -The BOFHfalu.nl@rhialto signature.asc Description: PGP signature
Re: build.sh live-image [virtio disk hang]
On Mon 31 May 2021 at 13:22:50 +0200, Rhialto wrote: > However when extracting the pkgsrc tar file, it hung on disk I/O. > When I retried, the same happened. > After that, even the fsck got blocked on disk I/O. I re-tried the same thing (almost the same thing; the partition was smaller) with an amd64/9.2 install in an OpenStack VM: extracting the pkgsrc tar file using sysinst. It hung before finishing. So there is either some general disk I/O problem, or it is specific to virtio disks (which seems more likely, so far). I could get the libvirt xml description and/or the qemu command line, in case it would provide useful. I did post the dmesg from the -current kernel elsewhere in the thread. -Olaf. -- ___ Q: "What's an anagram of Banach-Tarski?" -- Olaf "Rhialto" Seibert \X/ A: "Banach-Tarski Banach-Tarski." -- rhialto at falu dot nl signature.asc Description: PGP signature
Re: build.sh live-image
On Mon 31 May 2021 at 13:22:50 +0200, Rhialto wrote: > Would the change below be ok? I'll be looking at some more things to > improve for OpenStack but this is a good start. I was expecting that the metadata-querying script at src/distrib/utils/embedded/files/ec2_init could easily have some attributes added to it. But going by https://docs.openstack.org/nova/latest/user/metadata.html there aren't really that many that make sense to add. There is another helper script, openstack_init.py from pkgsrc/sysutils/openstack_init/files/openstack_init.py. But it assumes the config-drive option (which is not default) instead of fetching the data from http://169.254.169.254/openstack/latest/meta_data.json . That script requires Python (used to parse the JSON format) which I find a bit heavyweight. But the "random_seed" from his data would be nice to get, if it were easier to parse. Maybe I could just feed the whole json data string to rndctl, it would include the "random_seed" value if it's in there :) I was looking if there is something like "cloudinit" available in pkgsrc. That has some ways to specify creation of users, installation of packages, that sort of thing. But it doesn't seem to be there. -Olaf. -- ___ Q: "What's an anagram of Banach-Tarski?" -- Olaf "Rhialto" Seibert \X/ A: "Banach-Tarski Banach-Tarski." -- rhialto at falu dot nl signature.asc Description: PGP signature
Re: build.sh live-image
On Sat 29 May 2021 at 22:55:33 +0200, Rhialto wrote: > So /etc/rc.d/ec2_init should be able to work with OpenStack (although > putting the ssh key in root's authorized_keys may be a bit useless since > it seems that ssh root logins are not allowed). But the detection in > /etc/rc.conf.d/ec2_init would need to be adjusted (OpenStack is not ec2 > but does have the metadata service). Contrary to my expectation, login via ssh as root (using an ssh key) actually worked. -Olaf. -- ___ Q: "What's an anagram of Banach-Tarski?" -- Olaf "Rhialto" Seibert \X/ A: "Banach-Tarski Banach-Tarski." -- rhialto at falu dot nl signature.asc Description: PGP signature
Re: build.sh live-image
On Sun 30 May 2021 at 16:32:30 +1200, Lloyd Parkes wrote: > On 30/05/21 8:55 am, Rhialto wrote: > > > Another thing I noticed is that /etc/rc.d/resize_disklabel looks at the > > wrong MBR partition to check for NetBSD: it looks at partition 1 but > > should look at partition 0. > > resize_disklabel is designed for use on the Raspberry Pi where the NetBSD > partition comes after the FAT boot partition and so it is partition 1. > > When building amd64 images, I've resorted to rewriting the resize_disklabel > script from scratch. When I tried it today, resizing the root partition did actually work. Apparently the fdisk partition isn't that relevant for that. However when extracting the pkgsrc tar file, it hung on disk I/O. When I retried, the same happened. After that, even the fsck got blocked on disk I/O. Then I added the "log" option, and somehow then the extraction ran successfully to the end. The VM had only 4 GB of RAM; maybe that was an issue and the log option somehow caused less memory to be required? Or it could actually be a problem in the virtio disk driver. Would the change below be ok? I'll be looking at some more things to improve for OpenStack but this is a good start. murthe.8:.../amd64/liveimage/emuimage$ netbsd-cvs diff X11 forwarding request failed on channel 0 cvs diff: Diffing . Index: ec2_init === RCS file: /cvsroot/src/distrib/amd64/liveimage/emuimage/ec2_init,v retrieving revision 1.2 diff -u -r1.2 ec2_init --- ec2_init9 Sep 2020 13:25:48 - 1.2 +++ ec2_init31 May 2021 11:20:13 - @@ -13,6 +13,10 @@ *amazon*) val=YES ;; + # OpenStack is not EC2 but it does have a metadata service. + *openstack*) + val=YES + ;; esac fi done Copyright (c) 1996, 1997, 1998, 1999, 2000, 2001, 2002, 2003, 2004, 2005, 2006, 2007, 2008, 2009, 2010, 2011, 2012, 2013, 2014, 2015, 2016, 2017, 2018, 2019, 2020, 2021 The NetBSD Foundation, Inc. All rights reserved. Copyright (c) 1982, 1986, 1989, 1991, 1993 The Regents of the University of California. All rights reserved. NetBSD 9.99.82 (GENERIC) #0: Sat May 29 22:05:15 CEST 2021 rhia...@murthe.falu.nl:/tmpfs/obj.amd64/sys/arch/amd64/compile/GENERIC total memory = 4095 MB avail memory = 3941 MB entropy: entering seed from bootloader with 256 bits of entropy timecounter: Timecounters tick every 10.000 msec Kernelized RAIDframe activated timecounter: Timecounter "i8254" frequency 1193182 Hz quality 100 OpenStack Foundation OpenStack Nova (17.0.12) mainbus0 (root) ACPI: RSDP 0x000F6820 14 (v00 BOCHS ) ACPI: RSDT 0xBFFE1563 2C (v01 BOCHS BXPCRSDT 0001 BXPC 0001) ACPI: FACP 0xBFFE13F7 74 (v01 BOCHS BXPCFACP 0001 BXPC 0001) ACPI: DSDT 0xBFFE0040 0013B7 (v01 BOCHS BXPCDSDT 0001 BXPC 0001) ACPI: FACS 0xBFFE 40 ACPI: APIC 0xBFFE14EB 78 (v01 BOCHS BXPCAPIC 0001 BXPC 0001) ACPI: 1 ACPI AML tables successfully acquired and loaded ioapic0 at mainbus0 apid 0: pa 0xfec0, version 0x11, 24 pins cpu0 at mainbus0 apid 0 cpu0: Use lfence to serialize rdtsc cpu0: Intel Core Processor (Broadwell, IBRS), id 0x306d2 cpu0: node 0, package 0, core 0, smt 0 acpi0 at mainbus0: Intel ACPICA 20210331 acpi0: X/RSDT: OemId , AslId LNKS: ACPI: Found matching pin for 0.1.INTA at func 3: 9 LNKD: ACPI: Found matching pin for 0.1.INTD at func 2: 11 LNKC: ACPI: Found matching pin for 0.3.INTA at func 0: 11 LNKD: ACPI: Found matching pin for 0.4.INTA at func 0: 11 LNKA: ACPI: Found matching pin for 0.5.INTA at func 0: 10 acpi0: SCI interrupting at int 9 acpi0: fixed power button present timecounter: Timecounter "ACPI-Safe" frequency 3579545 Hz quality 900 pckbc1 at acpi0 (KBD, PNP0303) (kbd port): io 0x60,0x64 irq 1 pckbc2 at acpi0 (MOU, PNP0F13) (aux port): irq 12 FDC0 (PNP0700) at acpi0 not configured COM1 (PNP0501) at acpi0 not configured qemufwcfg0 at acpi0 (FWCF, QEMU0002): io 0x510-0x51b qemufwcfg0: ACPI: Enabled 2 GPEs in block 00 to 0F pckbd0 at pckbc1 (kbd slot) pckbc1: using irq 1 for kbd slot wskbd0 at pckbd0: console keyboard pms0 at pckbc1 (aux slot) pckbc1: using irq 12 for aux slot wsmouse0 at pms0 mux 0 pci0 at mainbus0 bus 0: configuration mode 1 pci0: i/o space, memory space enabled, rd/line, rd/mult, wr/inv ok pchb0 at pci0 dev 0 function 0: Intel 82441FX (PMC) PCI and Memory Controller (rev. 0x02) pcib0 at pci0 dev 1 function 0: Intel 82371SB (PIIX3) PCI-ISA Bridge (rev. 0x00) piixide0 at pci0 dev 1 function 1: Intel 82371SB IDE Interface (PIIX3) (rev. 0x00) piixide0: bus-master DMA support present piixide0: primary channel wired to com
build.sh live-image
I wanted to try if I can easily create a disk image to run in an OpenStack cloud. That differs a bit from EC2 cloud, but there is a sort of compatible metadata server (169.254.169.254) that can be used as well. So I tried the result from build.sh live-image. So /etc/rc.d/ec2_init should be able to work with OpenStack (although putting the ssh key in root's authorized_keys may be a bit useless since it seems that ssh root logins are not allowed). But the detection in /etc/rc.conf.d/ec2_init would need to be adjusted (OpenStack is not ec2 but does have the metadata service). Another thing I noticed is that /etc/rc.d/resize_disklabel looks at the wrong MBR partition to check for NetBSD: it looks at partition 1 but should look at partition 0. At least on this image (from build.sh live-image). Maybe it is also used on other types of live images? It can't be about skipping the EFI partition because those occur on GPT disks only. -Olaf. -- ___ Q: "What's an anagram of Banach-Tarski?" -- Olaf "Rhialto" Seibert \X/ A: "Banach-Tarski Banach-Tarski." -- rhialto at falu dot nl signature.asc Description: PGP signature
Re: Problem reports for version control systems
On Fri 30 Apr 2021 at 19:51:27 +1000, matthew green wrote: > > I too get long pauses with cvs, both at the beginning, > > and even longer at the end after update is complete. > > the end part is most likely cvs cleaning up after itslf by > removing all the subdirs it created but doesn't need. And the pause at the beginning is likely to be a full scan of the tree for "extra" files. Note that those get reported before you see any progress on the update itself. > .mrg. -Olaf. -- ___ Q: "What's an anagram of Banach-Tarski?" -- Olaf "Rhialto" Seibert \X/ A: "Banach-Tarski Banach-Tarski." -- rhialto at falu dot nl signature.asc Description: PGP signature
Re: Partial reads on unix domain sockets
On Wed 07 Apr 2021 at 13:43:52 +0200, Tom Ivar Helbekkmo wrote: > While there is no guarantee of a one to one relationship between writes > and reads, it seems that some applications expect this. In my case, it > was jack (pkgsrc/audio/jack) that failed. It comes with, among other > things, a daemon, jackd, and a library for use by clients wishing to > connect to it. Communication between jackd and its clients became > impossible with this change, because the code in jack expects to be able > to exchange C structs between server and clients. The jackd server has > a thread that uses poll() to wait for available packets from clients, > and when something arrives, it is read with code like this example: Shouldn't code that expects that open a SOCK_SEQPACKET socket instead of SOCK_STREAM? (Or SOCK_DGRAM perhaps, since socket(2) seems to say that SOCK_SEQPACKET doesn't exist for PF_LOCAL) -Olaf. -- ___ Q: "What's an anagram of Banach-Tarski?" -- Olaf "Rhialto" Seibert \X/ A: "Banach-Tarski Banach-Tarski." -- rhialto at falu dot nl signature.asc Description: PGP signature
Re: How to determine if graphics is supported by radeondrm?
On Sun 21 Mar 2021 at 10:46:17 +1300, Lloyd Parkes wrote: > > On 20/03/21 3:41 pm, Lloyd Parkes wrote: > > I also tried my Intel based laptop, but I only had an MBR image and HP > > seemed to have removed the old BIOS boot option in their newer firmware > > so I couldn't even boot the image. > > I just tried the 9.1 image on my ASUS UX550V laptop and it did load a proper > GLX renderer for the Intel GPU. I hadn't tried that laptop initially because > it also has an nVidia GPU in it, but then I realised that NetBSD will > probably ignore the nVidia GPU and it did. Ah yes. I looked up that model and it seems to have a "Intel Core i7-7700HQ" CPU in it, which (because of the 7xxx number) is apparenly of the 7th generation, which is apparently the latest that NetBSD has support for. > None of the trackpads on my laptops worked with the NetBSD image I was using > and I did not look into why. Weird.. > Lloyd Thanks, -Olaf. -- ___ Q: "What's an anagram of Banach-Tarski?" -- Olaf "Rhialto" Seibert \X/ A: "Banach-Tarski Banach-Tarski." -- rhialto at falu dot nl signature.asc Description: PGP signature
Re: How to determine if graphics is supported by radeondrm?
On Sat 20 Mar 2021 at 15:41:49 +1300, Lloyd Parkes wrote:
> HI all,
>
> On 18/03/21 10:03 am, Rhialto wrote:
> > For example, if I look at an "AMD Ryzen 3" cpu, which supposedly has
> > integrated graphics "AMD Radeon Vega 8, integrated GPU". Grepping -i for
> > "Vega" in src/sys/external/bsd/drm2/dist/drm yields no results; I take
> > it this is a bad sign?
>
> I booted a live image of 9.1 that I found on my Ryzen 3 laptop and it ends
> up running the Vesa driver with the "llvmpipe" OpenGL renderer. The Xorg log
> file shows that X thought about the AMD driver, but ended up using the VESA
> one. The log shows a long list of AMD GPU models, which looks like Xorg's
> way of saying that it doesn't know what model of AMD GPU I have.
Thanks for doing the experiment. I guess it tells us what I already
feared, that it doesn't do accelleration.
I think that the long list of AMD GPU models is simply always printed by
the AMD driver ("Look at all the models I support!") and then later it
decides if it really supports the GPU that's there. For instance on my
current box, it reports at some point after the long list:
[34.593] (--) RADEON(0): Chipset: "ATI Radeon HD 5450" (ChipID = 0x68f9)
(or maybe that's only because I have told X to use the Radeon driver and
not the modesetting driver...)
> Linux says the laptop has "AMD Ryzen 3 3300U with Radeon Vega Mobile Gfx"
> and Google tells me this is a Picasso/Radeon Vega 6.
>
> I found the file amdgpu_device.c with the amdgpu_asic_name definition at the
> top. NetBSD has many, many entries missing from this list. :-(
>
> I also tried my Intel based laptop, but I only had an MBR image and HP
> seemed to have removed the old BIOS boot option in their newer firmware so I
> couldn't even boot the image.
Thanks for doing the experiment!
> Lloyd
-Olaf.
--
___ Q: "What's an anagram of Banach-Tarski?" -- Olaf "Rhialto" Seibert
\X/ A: "Banach-Tarski Banach-Tarski." -- rhialto at falu dot nl
signature.asc
Description: PGP signature
How to determine if graphics is supported by radeondrm?
I'm looking for a new computer (my current one is 10 years old or so) and I'm wondering how I can determine if a certain graphics chipset is supported currently by NetBSD. With "supported" I mean that accelleration works at least for playing movies and GL- stuff such as done by emulators such as fs-uae and vice. For example, if I look at an "AMD Ryzen 3" cpu, which supposedly has integrated graphics "AMD Radeon Vega 8, integrated GPU". Grepping -i for "Vega" in src/sys/external/bsd/drm2/dist/drm yields no results; I take it this is a bad sign? Am I better off looking at iNtel stuff? -Olaf. -- ___ Q: "What's an anagram of Banach-Tarski?" -- Olaf "Rhialto" Seibert \X/ A: "Banach-Tarski Banach-Tarski." -- rhialto at falu dot nl signature.asc Description: PGP signature
Re: [HEADS UP] pkgsrc default database directory changed
On Sat 05 Dec 2020 at 15:14:52 +0100, Thomas Klausner wrote: > So the complete instructions as of now are: > > cd /usr/pkgsrc/pkgtools/pkg_install > make USE_CWRAPPERS=no install > cd /usr/pkg/sbin && install -c pkg_add pkg_admin pkg_create pkg_delete > pkg_info /usr/sbin/ > mv /var/db/pkg /usr/pkg/pkgdb > mv /var/db/pkg.refcount /usr/pkg/pkgdb.refcount A problem with pkg.refcount might be that files in that directory contain absolute pathnames starting with /var/db/pkg. E.g.: $ cat /var/db/pkg.refcount/groups/mail/cyrus-sasl-2.1.27nb1 /var/db/pkg/cyrus-sasl-2.1.27nb1 $ cat /var/db/pkg.refcount/files/usr/pkg/lib/perl5/vendor_perl/5.32.0/XML/SAX/ParserDetails.ini/p5-XML-SAX-1.02 /var/db/pkg/p5-XML-SAX-1.02 $ cat /var/db/pkg.refcount/users/smmsp/sendmail-8.15.2nb9 /var/db/pkg/sendmail-8.15.2nb9 -Olaf. -- Olaf 'Rhialto' Seibert -- rhialto at falu dot nl ___ Anyone who is capable of getting themselves made President should on \X/ no account be allowed to do the job. --Douglas Adams, "THGTTG" signature.asc Description: PGP signature
Re: atexit(), dlclose() and more atexit() (with reproducer)
I made a small program reproducing the problem, also with a base system
library. I randomly chose /usr/lib/libtermcap.so as default, but I think
everything that turns up by grep _fini /usr/lib/*.so will do.
Actual output:
$ ./dl
main thread 0x706e490a2800: calling exit()
main thread 0x706e490a2800: telling thread to exit
main thread 0x706e490a2800: calling pthread_join()
worker thread 0x706e4909f000: calling dlclose()
(deadlock)
Expected output:
$ ./dl
main thread 0x706d25e35800: calling exit()
main thread 0x706d25e35800: telling thread to exit
main thread 0x706d25e35800: calling pthread_join()
worker thread 0x706d25e32000: calling dlclose()
worker thread 0x706d25e32000: dlclose() returned
worker thread 0x706d25e32000: exiting
main thread 0x706d25e35800: pthread_join() returned
$
dl.c: (compile with "sh dl.c")
--><>---cut here---<><--
# /*
cc dl.c -o dl -pthread -ggdb
exit $?
*/
#include
#include
#include
#include
#include
void *library_handle;
pthread_t worker_thread = 0;
int worker_thread_should_exit = 0;
void cleanup_from_main_thread()
{
printf("main thread %p: telling thread to exit\n", pthread_self());
worker_thread_should_exit = 1;
printf("main thread %p: calling pthread_join()\n", pthread_self());
pthread_join(worker_thread, NULL);
printf("main thread %p: pthread_join() returned\n", pthread_self());
}
void *worker_thread_main(void *arg)
{
/* Do useful work */
while (!worker_thread_should_exit) {
sleep(1);
}
printf("worker thread %p: calling dlclose()\n", pthread_self());
dlclose(library_handle);
printf("worker thread %p: dlclose() returned\n", pthread_self());
printf("worker thread %p: exiting\n", pthread_self());
pthread_exit(NULL);
}
int
main(int argc, char **argv)
{
char *library = "/usr/lib/libtermcap.so";
if (argc > 1) {
library = argv[1];
}
library_handle = dlopen(library, RTLD_LAZY|RTLD_LOCAL);
pthread_create(_thread, NULL, worker_thread_main, NULL);
atexit(cleanup_from_main_thread);
/* Do useful work */
sleep(1);
printf("main thread %p: calling exit()\n", pthread_self());
exit(0);
}
--><>---cut here---<><--
-Olaf.
--
Olaf 'Rhialto' Seibert -- rhialto at falu dot nl
___ Anyone who is capable of getting themselves made President should on
\X/ no account be allowed to do the job. --Douglas Adams, "THGTTG"
signature.asc
Description: PGP signature
Re: atexit(), dlclose() and more atexit()
On Mon 29 Jun 2020 at 09:55:10 +0200, Rhialto wrote: > I've looked at __cxa_finalize a bit better, and it seems that the lock > mutex_lock(&__atexit_mutex); isn't just used to protect running the > atexit handlers, but even to protect looking at the list of handlers: > atexit_handler_stack. > So the fact that libavformat establishes a handler may be a red herring. > I will try to test this later today somehow. So I did a small experiment. Since VICE dlopens several of the ffmpeg's shared libraries, I changed the order that it is closing them. I get now: ffmpegdrv_shutdown: entered; calling ffmpeglib_close(); ffmpeglib_close: free_avcodec() vice_dynlib_close: pthread=0x72abf78b8000 ffmpeglib_close: free_avutil() vice_dynlib_close: pthread=0x72abf78b8000 ffmpeglib_close: free_swscale() vice_dynlib_close: pthread=0x72abf78b8000 ^C^\Quit (core dumped) meaning that it managed to dlclose libavcodec, libavutil, and hangs during libswscale. None of those contain calls to atexit that I could find in the source; only libavformat/avisynth.c refers to atexit. With my revised chain of events, I was expecting that it would deadlock while dlclosing the first shared library, which is now libavcodec. Instead it deadlocks at the third. I'm not sure yet what to make of that. I can only say that in gdb, breaking on __cxa_finalize, the first two libraries don't seem to get there at all and the first library to get there is Thread 9 "" hit Breakpoint 2, __cxa_finalize ( dso=0x7b02ccc7b940 <__dso_handle>) at /usr/src/lib/libc/stdlib/atexit.c:192 (gdb) bt #0 __cxa_finalize (dso=0x7b02ccc7b940 <__dso_handle>) at /usr/src/lib/libc/stdlib/atexit.c:192 #1 0x7b02cca02318 in ?? () from /usr/pkg/lib/ffmpeg4/libswscale.so.5 #2 0x7b02e49fe1a0 in ?? () #3 0x7b02cca6c579 in _fini () from /usr/pkg/lib/ffmpeg4/libswscale.so.5 #4 0x in ?? () I'm not sure why this library has a _fini() function which gets called. This would make the chain of events (3rd version): 1. In the original thread, it dlopen()s a library with a _fini function which calls __cxa_finalize(). [what causes this???] 2. There is no 2. 3. The main thread starts a new thread, and registers an atexit() handler to clean up that thread. 3a. Both threads run for a while doing their main jobs. 4. main thread exit()s. 5. atexit() handler obtains its lock (which protects the handler list), and calls the handler established in 3. 6. said handler tells the new thread to clean up and finish. One of the last things the thread does, is to dlclose() libavformat. 7. __cxa_finalize() gets called on behalf of the library, which tries to obtain the same lock that was already obtained, in a different thread, in step 5. 8. deadlock. In this case, the fault cannot be with libavformat or libswscale, right? -Olaf. -- Olaf 'Rhialto' Seibert -- rhialto at falu dot nl ___ Anyone who is capable of getting themselves made President should on \X/ no account be allowed to do the job. --Douglas Adams, "THGTTG" signature.asc Description: PGP signature
Re: atexit(), dlclose() and more atexit()
On Mon 29 Jun 2020 at 10:39:45 +0200, Martin Husemann wrote: > On Mon, Jun 29, 2020 at 09:55:10AM +0200, Rhialto wrote: > > 6. said handler tells the new thread to clean up and finish. One of the last > >things the thread does, is to dlclose() libavformat. > > How can an atexit() handler (or a destructor) defer work to a thread > (w/o waiting for the thread to complete, but then the thread makes no > sense)? I'm boiling down things to the essence here. The "new thread" isn't just there to do cleanup. It has been running the CPU emulation of VICE for potentially a long time. When the GTK3 GUI (which runs on the main thread) lets the user choose the Quit menu entry, it starts shutting things down. Part of the shutdown happens in the atexit handler. When this CPU emulating thread gets notified that it should finish up, it also handles the dlclose(), which in turn deadlocks. It is basically an unfortunate distribution of cleanup tasks which causes a deadlock. But I wonder if there is any standards text that describes whether this particular scenario is supposed to work. > Martin -Olaf. -- Olaf 'Rhialto' Seibert -- rhialto at falu dot nl ___ Anyone who is capable of getting themselves made President should on \X/ no account be allowed to do the job. --Douglas Adams, "THGTTG" signature.asc Description: PGP signature
Re: atexit(), dlclose() and more atexit()
On Sun 28 Jun 2020 at 23:29:05 +0200, Joerg Sonnenberger wrote: > On Sun, Jun 28, 2020 at 10:56:01PM +0200, Rhialto wrote: > > The funny thing is that libavformat uses an atexit handler due to issues > > with dynamic (un)loading (or so they claim). This is from their file > > ffmpeg-4.2.2/libavformat/avisynth.c: > > > > /* A conflict between C++ global objects, atexit, and dynamic loading > > requires > > * us to register our own atexit handler to prevent double freeing. */ > > It is fundamentally wrong to use a handler in a library that can be > unloaded. Some systems hack around that problem by looping over all > atexit handlers on dlclose, but that's exactly that, a costly hack. The > most common way this triggers is a segfault, actually. > The code should be using either a C dtor with the appropiate attribute > or __cxa_atexit directly, but the former is preferable. I've looked at __cxa_finalize a bit better, and it seems that the lock mutex_lock(&__atexit_mutex); isn't just used to protect running the atexit handlers, but even to protect looking at the list of handlers: atexit_handler_stack. So the fact that libavformat establishes a handler may be a red herring. I will try to test this later today somehow. This would make the chain of events: 1. In the original thread, it dlopen()s libavformat. 2. There is no 2. 3. The main thread starts a new thread, and registers an atexit() handler to clean up that thread. 4. main thread exit()s. 5. atexit() handler obtains its lock (which protects the handler list), and calls the handler established in 3. 6. said handler tells the new thread to clean up and finish. One of the last things the thread does, is to dlclose() libavformat. 7. __cxa_finalize() gets called on behalf of libavformat (as always happens when a library is unloaded), which tries to obtain the same lock that was already obtained, in a different thread, in step 5. 8. deadlock. In this case, the fault cannot be with libavformat, right? -Olaf. -- Olaf 'Rhialto' Seibert -- rhialto at falu dot nl ___ Anyone who is capable of getting themselves made President should on \X/ no account be allowed to do the job. --Douglas Adams, "THGTTG" signature.asc Description: PGP signature
Re: atexit(), dlclose() and more atexit()
On Sun 28 Jun 2020 at 22:39:28 +0200, Joerg Sonnenberger wrote: > On Sun, Jun 28, 2020 at 10:35:27PM +0200, Rhialto wrote: > > I have at hand a program (the current svn trunk of VICE, to be exact) > > which does the following: > > > > 1. In the original thread, it dlopen()s libavformat. > > 2. libavformat establishes an atexit() handler. > > 3. The main thread starts a new thread, and registers an atexit() > >handler to clean up that thread. > > 4. main thread exit()s. > > 5. atexit() handler obtains its lock, and calls the handler established in > > 3. > > 6. said handler tells the new thread to clean up and finish. One of the last > >things the thread does, is to dlclose() libavformat. > > 7. libavformat's atexit handling gets called, which tries to obtain the > >same lock that was already obtained, in a different thread, in step > >5. > > 8. deadlock. > > > > Who is in the wrong here? > > libavformat. Never use atexit() with a handler in a library that can be > closed. The funny thing is that libavformat uses an atexit handler due to issues with dynamic (un)loading (or so they claim). This is from their file ffmpeg-4.2.2/libavformat/avisynth.c: /* A conflict between C++ global objects, atexit, and dynamic loading requires * us to register our own atexit handler to prevent double freeing. */ > Joerg -Olaf. -- Olaf 'Rhialto' Seibert -- rhialto at falu dot nl ___ Anyone who is capable of getting themselves made President should on \X/ no account be allowed to do the job. --Douglas Adams, "THGTTG" signature.asc Description: PGP signature
atexit(), dlclose() and more atexit()
I have at hand a program (the current svn trunk of VICE, to be exact) which does the following: 1. In the original thread, it dlopen()s libavformat. 2. libavformat establishes an atexit() handler. 3. The main thread starts a new thread, and registers an atexit() handler to clean up that thread. 4. main thread exit()s. 5. atexit() handler obtains its lock, and calls the handler established in 3. 6. said handler tells the new thread to clean up and finish. One of the last things the thread does, is to dlclose() libavformat. 7. libavformat's atexit handling gets called, which tries to obtain the same lock that was already obtained, in a different thread, in step 5. 8. deadlock. Who is in the wrong here? Some stack traces for illustration. A more extensive version of this can be found at the bugtracker of VICE: https://sourceforge.net/p/vice-emu/bugs/1243/ See Thread 9 frame #3 versus Thread 1 frame #4 the "new thread": Thread 9 (LWP 9 of process 2731): #0 0x75e643aa1f7a in ___lwp_park60 () from /usr/lib/libc.so.12 #1 0x75e6440095a6 in pthread__mutex_lock_slow (ptm=ptm@entry=0x75e643fe1780 <__atexit_mutex>, ts=ts@entry=0x0) at /usr/src/lib/libpthread/pthread_mutex.c:384 #2 0x75e6440099b5 in pthread_mutex_lock (ptm=ptm@entry=0x75e643fe1780 <__atexit_mutex>) at /usr/src/lib/libpthread/pthread_mutex.c:208 #3 0x75e643b43a14 in __cxa_finalize (dso=0x75e638e145e0 <__dso_handle>) at /usr/src/lib/libc/stdlib/atexit.c:198 #4 0x75e638a397f8 in ?? () from /usr/pkg/lib/ffmpeg4/libavformat.so.58 #5 0x75e64b546160 in ?? () #6 0x75e638b8aed9 in _fini () from /usr/pkg/lib/ffmpeg4/libavformat.so.58 #7 0x in ?? () the main thread: Thread 1 (LWP 1 of process 2731): #0 0x75e643aa1f7a in ___lwp_park60 () from /usr/lib/libc.so.12 #1 0x75e64400a71f in pthread_cond_timedwait (cond=0x75e62dd910c0, mutex=0x75e62dd91018, abstime=0x0) at /usr/src/lib/libpthread/pthread_cond.c:168 #2 0x75e64400c2c8 in pthread_join (thread=0x75e62dd91000, valptr=valptr@entry=0x0) at /usr/src/lib/libpthread/pthread.c:724 #3 0x004312ec in vice_thread_shutdown () at ../../vice/src/main.c:350 #4 0x75e643b43ac0 in __cxa_finalize (dso=dso@entry=0x0) at /usr/src/lib/libc/stdlib/atexit.c:222 #5 0x75e643b437b3 in exit (status=status@entry=0) at /usr/src/lib/libc/stdlib/exit.c:60 #6 0x00445998 in archdep_vice_exit (excode=excode@entry=0) at ../../../../vice/src/arch/shared/archdep_atexit.c:119 #7 0x005ca086 in ui_exit () at ../../../../vice/src/arch/gtk3/ui.c:2051 #8 0x005cb4e4 in ui_close_callback (widget=, user_data=) at ../../../../vice/src/arch/gtk3/uicommands.c:226 #9 0x75e64878550c in _gtk_marshal_BOOLEAN__OBJECT_UINT_FLAGS () from /usr/pkg/lib/libgtk-3.so.0 #10 0x75e645c12352 in g_closure_invoke () from /usr/pkg/lib/libgobject-2.0.so.0 #11 0x75e645c233f0 in signal_emit_unlocked_R () from /usr/pkg/lib/libgobject-2.0.so.0 #12 0x75e645c2d61e in g_signal_emit_valist () from /usr/pkg/lib/libgobject-2.0.so.0 #13 0x75e645c2e3cc in g_signal_emit () from /usr/pkg/lib/libgobject-2.0.so.0 #14 0x75e6484f906f in gtk_accel_group_activate () from /usr/pkg/lib/libgtk-3.so.0 #15 0x75e6484fa6a6 in gtk_accel_groups_activate () from /usr/pkg/lib/libgtk-3.so.0 #16 0x75e648759a9a in gtk_window_activate_key () from /usr/pkg/lib/libgtk-3.so.0 #17 0x005c8453 in kbd_event_handler (w=0x75e64b450260, report=0x75e64cc7bd00, gp=) at ../../../../vice/src/arch/gtk3/kbd.c:366 #18 0x75e648784873 in _gtk_marshal_BOOLEAN__BOXED () from /usr/pkg/lib/libgtk-3.so.0 #19 0x75e645c12352 in g_closure_invoke () from /usr/pkg/lib/libgobject-2.0.so.0 #20 0x75e645c233f0 in signal_emit_unlocked_R () from /usr/pkg/lib/libgobject-2.0.so.0 #21 0x75e645c2d61e in g_signal_emit_valist () from /usr/pkg/lib/libgobject-2.0.so.0 #22 0x75e645c2e3cc in g_signal_emit () from /usr/pkg/lib/libgobject-2.0.so.0 #23 0x75e648738907 in gtk_widget_event_internal () from /usr/pkg/lib/libgtk-3.so.0 #24 0x75e64861332c in propagate_event () from /usr/pkg/lib/libgtk-3.so.0 #25 0x75e648614f44 in gtk_main_do_event () from /usr/pkg/lib/libgtk-3.so.0 #26 0x75e64802c9ae in _gdk_event_emit () from /usr/pkg/lib/libgdk-3.so.0 #27 0x75e64805ac44 in gdk_event_source_dispatch () from /usr/pkg/lib/libgdk-3.so.0 #28 0x75e645849543 in g_main_context_dispatch () from /usr/pkg/lib/libglib-2.0.so.0 #29 0x75e6458496fc in g_main_context_iterate.isra () from /usr/pkg/lib/libglib-2.0.so.0 #30 0x75e64584997a in g_main_loop_run () from /usr/pkg/lib/libglib-2.0.so.0 #31 0x75e6486142f2 in gtk_main () from /usr/pkg/lib/libgtk-3.so.0 #32 0x00634b7c in main (argc=1, argv=0x7f7fff1e0628) at ../../../../vice/src/arch/gtk3/gtk3main.c:91 signature.asc Description: PGP signature
Duplicate commits in git clone of src
I was looking at the git clone of the src repo (https://github.com/netbsd/src) and I noticed that there are lots of duplicate commits in there; some commits are even present 3 or 4 times. At first I thought this occurs only with very old commits, but it is the case for relatively recent ones as well. Normally this isn't so easy to see, but with gitk and these settings it is fairly obvious: choose menu View -> New View, select under References: All refs, All (local) branches, All tags, All remote-tracking branches. Lower down, select Strictly sort by date. If you dan scroll back just a few years of commits, you can find a bunch below the time "2017-04-10 23:53:37" Taking some random commits from 2017-03-22 23:37:41: c75b502dcf23b51c8d2504be7a9b5dd7823e4a09 Author: sevan 2017-03-22 23:37:41 Committer: sevan 2017-03-22 23:37:41 Parent: 20d6933e4ccdf0811b2b11f64dd019c016cea33e (On second through, it may be possible to have a NULL kfs_v in read and write) Child: fa4a1a6573dcb68fb2675cb80653b446a3231bb9 (KDTRACE_HOOKS is enabled by default in GENERIC.common, remove references in) Branch: remotes/origin/jdolecek_ncq d595117d197582e247e9d5d89ea2c3327feb9e3c Author: sevan 2017-03-22 23:37:41 Committer: sevan 2017-03-22 23:37:41 Parent: 058026589ba723ce74452748b5e78aa0a7cd15bc (On second through, it may be possible to have a NULL kfs_v in read and write) Child: b13c9c92f5f3fb3b6e010d31acd1b2a6bd1b1c22 (KDTRACE_HOOKS is enabled by default in GENERIC.common, remove references in) Branches: netbsd-9, remotes/origin/ad-namecache, remotes/origin/bouyer-xenpvh, remotes/origin/is-mlppp, remotes/origin/isaki-audio2, remotes/origin/jdolecek-ncq, remotes/origin/jdolecek-ncqfixes, remotes/origin/matt-nb8-mediatek, remotes/origin/netbsd-8, remotes/origin/netbsd-9, remotes/origin/perseant-stdc-iso10646, remotes/origin/pgoyette-compat, remotes/origin/phil-wifi, remotes/origin/prg-localcount2, remotes/origin/trunk, trunk Looking at the differences between these, I notice a different conversion of the author/committer name. Also it is on branch "jdolecek_ncq". The second one has improved the author/committer, mentions several branches, one of which is "jdolecek-ncq", with a dash rather than an underscore. With some other commits I saw, the branch names are "ROY" vs "roy". Around 1999-12-05 you can see triple commits (but there are too many branches and gitk doesn't show them, so analyzing that is more difficult). My guess here is that there was an incremental conversion, with improvements in author and branch name conversion along the way. But commits and branches from earlier processing stayed in the result, and hence the duplicates. Maybe it just needs a fresh conversion from the start to get rid of these duplicates. Or if that is not feasible, removal of the outdated branches from the origin repo would probably help a lot. But it is cool to be able to look back all the way to 1992 to the first commit! -Olaf. -- Olaf 'Rhialto' Seibert -- rhialto at falu dot nl ___ Anyone who is capable of getting themselves made President should on \X/ no account be allowed to do the job. --Douglas Adams, "THGTTG" signature.asc Description: PGP signature
Re: i386 Xen integration breaks linking NET4501 kernel
Probably similarly, linking fails when building an amd64 MODULAR kernel, with some Xen-related undefined symbol errors: building standard kern library create vers.c compile MODULAR/vers.o link MODULAR/netbsd /vol1/rhialto/tools.amd64/bin/x86_64--netbsd-ld: hypervisor.o: in function `xenkernfs_init': /mnt/vol1/rhialto/cvs/src/sys/arch/xen/xen/hypervisor.c:787: undefined reference to `kernfs_addentry' /vol1/rhialto/tools.amd64/bin/x86_64--netbsd-ld: xenbus_dev.o: in function `xenbus_kernfs_init': /mnt/vol1/rhialto/cvs/src/sys/arch/xen/xenbus/xenbus_dev.c:86: undefined reference to `kernfs_alloctype' /vol1/rhialto/tools.amd64/bin/x86_64--netbsd-ld: /mnt/vol1/rhialto/cvs/src/sys/arch/xen/xenbus/xenbus_dev.c:90: undefined reference to `kernfs_addentry' /vol1/rhialto/tools.amd64/bin/x86_64--netbsd-ld: /mnt/vol1/rhialto/cvs/src/sys/arch/xen/xenbus/xenbus_dev.c:93: undefined reference to `kernfs_alloctype' /vol1/rhialto/tools.amd64/bin/x86_64--netbsd-ld: /mnt/vol1/rhialto/cvs/src/sys/arch/xen/xenbus/xenbus_dev.c:97: undefined reference to `kernfs_addentry' -Olaf. -- Olaf 'Rhialto' Seibert -- rhialto at falu dot nl ___ Anyone who is capable of getting themselves made President should on \X/ no account be allowed to do the job. --Douglas Adams, "THGTTG" signature.asc Description: PGP signature
fdesc weirdness with /dev/stdin: Device not configured
$ echo a >xx $ sort /dev/stdin fd/0 murthe.7:/tmp$ ls -l /dev/fd/ total 16 crw--w 1 rhialto tty5, 15 Apr 13 17:56 0 crw--w 1 rhialto tty5, 15 Apr 13 17:56 1 crw--w 1 rhialto tty5, 15 Apr 13 17:56 2 drw-rw-rwT 85 root wheel 15872 Apr 13 17:56 3/ dr--r--r-- 2 root wheel512 Apr 9 15:15 4/ This is with 9.0 but I think the behaviour started in 8.0. (cat signature.asc Description: PGP signature
Re: More POSIX Issue 8 changes (msg #2)
and I'm not so sure about the text that follows: whereas the ERE ".*?c" matches the first character 'c', the third character in the string. [[ "abc abc" ]] Possibly it should match "abc", because that is leftmost; just matching "c" is shortest but I don't see it as being leftmost. I'm not sure how rigorous they define these terms. -Olaf. -- Olaf 'Rhialto' Seibert -- rhialto at falu dot nl ___ Anyone who is capable of getting themselves made President should on \X/ no account be allowed to do the job. --Douglas Adams, "THGTTG" signature.asc Description: PGP signature
Re: built-in vs loadable modules and userconf
On Sat 19 Oct 2019 at 08:16:02 -0700, Paul Goyette wrote: > If the module is built-in, it will never be loaded from the *.kmod file. > But as I pointed out above, disabling in userconf does NOT disable the > module, and does not prevent the module's initialization code from > executing. Side-thought: maybe userconf can benefit from a way to disable modules? -Olaf. -- Olaf 'Rhialto' Seibert -- rhialto at falu dot nl ___ Anyone who is capable of getting themselves made President should on \X/ no account be allowed to do the job. --Douglas Adams, "THGTTG" signature.asc Description: PGP signature
Re: i386 9.99.17 build fails for NET4501 kernel
On Thu 17 Oct 2019 at 11:07:44 +0200, Maxime Villard wrote: > I guess we whould disable the messages on this particular file for now as > the others have suggested, and file a PR in LLVM/GCC, because apart from > a compiler bug I don't see what it could be. The original error has no place in a freestanding build anyway, since vfork (and longjmp probably too) are concepts of hosted implementations only. -Olaf. -- Olaf 'Rhialto' Seibert -- rhialto at falu dot nl ___ Anyone who is capable of getting themselves made President should on \X/ no account be allowed to do the job. --Douglas Adams, "THGTTG" signature.asc Description: PGP signature
Re: Can I use pkg_src to upgrade to current?
On Thu 10 Oct 2019 at 12:46:43 +, m...@netbsd.org wrote:
> Unpack all of them in / ('tar xJpf') except etc.tar.xz. That one will
You don't even need the J option when decompressing, plain old z will
work too (for all the usual compressors used with tar). Sooo much more
convenient than Linux :) (For compressing with bzip2 J would be required
of course).
-Olaf.
--
Olaf 'Rhialto' Seibert -- rhialto at falu dot nl
___ Anyone who is capable of getting themselves made President should on
\X/ no account be allowed to do the job. --Douglas Adams, "THGTTG"
signature.asc
Description: PGP signature
Re: device-specific "vdpau" support?
On Sat 29 Jun 2019 at 20:55:16 +, m...@netbsd.org wrote: > Supposedly it's even more efficient video decoding, but I didn't do a > comparison (It would be pretty easy to do, since pkgsrc mesa does build > VDPAU). With the Linux I now have on my Pinebook, there are vdpau drivers for the graphics chipset, but no "regular" acceleration. As a result, video players can play 1080p videos perfectly, as long as you don't try to use anything GUI-ish, because that is still slow as molasses... That is the sort of difference it can make. (Personally, I'd prefer the other way around, if I had to choose only one...) -Olaf. -- ___ Olaf 'Rhialto' Seibert -- "What good is a Ring of Power \X/ rhialto/at/falu.nl -- if you're unable...to Speak." - Agent Elrond signature.asc Description: PGP signature
Re: Weirdness on (pinebook?) X in -current
On Sat 15 Jun 2019 at 07:29:02 +1000, matthew green wrote: > i don't know about the remapping issue, but.. > > > Similarly, the Emulate3Buttons option doesn't seem to work on the mouse. > > It is really needed since the pinebook touchpad doesn't have a middle > > button and it is required for pasting. > > > > Option "Emulate3Buttons" "On > > > > The setting is recognized and reported in /var/log/Xorg.0.log. > > > > Same question: pinebook specific, or generic X issue? > > this one appears to be a timing issue. i've a handful of times > managed to make double-click do middle-button, but it's only > been a handful of times out of hundreds. I tried increasing the "Emulate3Timeout" time to 500 (ms) and it didn't help at all. With an external USB mouse, pressing left + right worked fine to emulate the middle button. I am starting to suspect that the trackpad simply does not report multiple button presses. While running xev, I could not even see anything happening if I pressed a second button while another was already pressed, no matter if I did anthing slow or fast. > .mrg. -Olaf. -- ___ Olaf 'Rhialto' Seibert -- "What good is a Ring of Power \X/ rhialto/at/falu.nl -- if you're unable...to Speak." - Agent Elrond signature.asc Description: PGP signature
Re: UFS2 feature: inode space used for data
On Wed 13 Mar 2019 at 21:44:11 -, Michael van Elst wrote: > rhia...@falu.nl (Rhialto) writes: > > >in the set is allocated and initialized. The set of blocks that may > >be allocated to inodes is held as part of the free-space reserve > >until all other space in the filesystem is allocated. Only then can > >it be used for file data. > > >But the bit at the end: if you don't need so many inodes, but run out of > >data space, then unused inode blocks can be re-purposed as data blocks. > > I says that blocks that might be used for inodes later aren't allocated > for data unless there is no other free block. It doesn't talk about > re-purposing inode blocks once they are used as such. I thought that was what I wrote... because of the "unused". -Olaf. -- ___ Olaf 'Rhialto' Seibert -- "What good is a Ring of Power \X/ rhialto/at/falu.nl -- if you're unable...to Speak." - Agent Elrond signature.asc Description: PGP signature
UFS2 feature: inode space used for data
I was reading about the history of the Unix File System. In https://www.usenix.org/legacy/events/bsdcon03/tech/full_papers/mckusick/mckusick_html/ "Enhancements to the Fast Filesystem To Support Multi-Terabyte Storage Systems" there is this in section 4.1. Dynamic Inodes One of the common complaints about the UFS1 filesystem is that it preallocates all its inodes at the time that the filesystem is created. For filesystems with millions of files, the initialization of the filesystem can take several hours. Additionally, the filesystem creation program, newfs, had to assume that every filesystem would be filled with many small files and allocate a lot more inodes than were likely to ever be used. If a UFS1 filesystem uses up all its inodes, the only way to get more is to dump, rebuild, and restore the filesystem. The UFS2 filesystem resolves these problems by dynamically allocating its inodes. [...] To avoid these costs, UFS2 preallocates a range of inode numbers and a set of blocks for each cylinder group. Initially each cylinder group has a single block of inodes allocated (a typical block holds 32 or 64 inodes). When the block fills up, the next block of inodes in the set is allocated and initialized. The set of blocks that may be allocated to inodes is held as part of the free-space reserve until all other space in the filesystem is allocated. Only then can it be used for file data. I have indeed seen that we have code to delay initializing the inodes. But the bit at the end: if you don't need so many inodes, but run out of data space, then unused inode blocks can be re-purposed as data blocks. It doesn't look like we have that? At least I can't find any comment to that effect. Code would likely involve looking at and/or modifying cgp->cg_initediblk, but that field is used very rarely and not for this purpose. (On the other hand, I can't find such code in FreeBSD either, and I would expect it to be there, if anywhere.) Is my impression correct? -Olaf. -- ___ Olaf 'Rhialto' Seibert -- "What good is a Ring of Power \X/ rhialto/at/falu.nl -- if you're unable...to Speak." - Agent Elrond signature.asc Description: PGP signature
Re: xhci power to external device
I "solved" the problem by returning the disk in question ("performance
not as expected") and buying a "desktop" model (which has its own
external power supply). Since it is a 3,5" disk inside instead of a
2,5", it is a bit faster too.
-Olaf.
--
___ Olaf 'Rhialto' Seibert -- "What good is a Ring of Power
\X/ rhialto/at/falu.nl -- if you're unable...to Speak." - Agent Elrond
signature.asc
Description: PGP signature
Re: xhci power to external device
On Sun 17 Feb 2019 at 21:34:44 +0100, Rhialto wrote: > I have an external harddisk, like so: (output from usbdevs -v) > > Controller /dev/usb0: > addr 0: super speed, self powered, config 1, xHCI Root Hub(0x), vendor > 8086(0x8086), rev 1.00(0x0100) > port 1 addr 9: super speed, power 224 mA, config 1, Elements 25A1(0x25a1), > Western Digital(0x1058), rev 10.14(0x1014), serial To make things more interesting, I connected it to a laptop which has USB 2, not 3, and under Linux "lsusb -v" says bmAttributes 0x80 (Bus Powered) MaxPower 500mA On the same laptop, with NetBSD 8, also 500 mA: Controller /dev/usb7: addr 1: high speed, self powered, config 1, EHCI root hub(0x), vendor 8086(0x8086), rev 1.00(0x0100) port 1 addr 2: high speed, power 500 mA, config 1, Elements 25A1(0x25a1), Western Digital(0x1058), rev 10.14(0x1014), serial When I try the same on the original computer in a USB 2 port, I get the same result. On a MacBook (which does have USB 3), "System Information" says "Current Available (mA): 900" and "Current Required (mA): 896". And on a laptop with Linux and USB 3 ports, the same "224 mA" number is shown by lsusb -v. So there seems some confusion about the number, which supposedly is reported by the device and simply believed by the computer. So inspired by seeing "500 mA" on USB-2 ports, I plugged the disk into a USB-2 port on the original computer, and I don't see the symptoms (yet??) that made me think that there was a power problem. Can anyone shed some light on this? -Olaf. -- ___ Olaf 'Rhialto' Seibert -- "What good is a Ring of Power \X/ rhialto/at/falu.nl -- if you're unable...to Speak." - Agent Elrond signature.asc Description: PGP signature
xhci power to external device
I have an external harddisk, like so: (output from usbdevs -v) Controller /dev/usb0: addr 0: super speed, self powered, config 1, xHCI Root Hub(0x), vendor 8086(0x8086), rev 1.00(0x0100) port 1 addr 9: super speed, power 224 mA, config 1, Elements 25A1(0x25a1), Western Digital(0x1058), rev 10.14(0x1014), serial I have some reason to believe it does nog get enough power from the port. Is the "power 224 mA" how the current is actually limited? Or can the device draw more without telling us? For comparison, there is another device like so, which is a SD card reader: Controller /dev/usb3: addr 1: high speed, self powered, config 1, EHCI root hub(0x), vendor 8086(0x8086), rev 1.00(0x0100) port 1 addr 2: high speed, self powered, config 1, Rate Matching Hub(0x0024), Intel(0x8087), rev 0.00(0x) ... port 6 addr 3: high speed, power 500 mA, config 1, USB Storage(0x0723), Generic(0x05e3), rev 94.51(0x9451) so at least some devices can draw that much. If the given 224 mA are actually enforced, can I give the disk more anyway? -Olaf. -- ___ Olaf 'Rhialto' Seibert -- "What good is a Ring of Power \X/ rhialto/at/falu.nl -- if you're unable...to Speak." - Agent Elrond signature.asc Description: PGP signature
build.sh syspkgs
For the fun of it, I tried a "build.sh syspkgs", because I saw it as a subcommand of build.sh and I hadn't heard about it for a while. Is this actually supposed to work, or was this in the process of being removed but not completely? Anyway, it started out well but then stopped with this error: regpkg: WARNING: no comment for "base-x11-root" (using placeholder) regpkg: WARNING: no description for "base-x11-root" (re-using comment) Registered base-x11-root-8.99.27.0.20181215 Packaged base-x11-root-8.99.27.0.20181215.tgz Registered base-util-root-8.99.27.0.20181212 regpkg: ERROR: The metalog file (/vol1/rhialto/destdir.amd64/METALOG.sanitised) does not contain entries for the following files or directories which should be part of the base-util-root syspkg: ./bin/\133 --- makesyspkgs --- *** [makesyspkgs] Error code 128 nbmake[1]: stopped in /mnt/vol1/rhialto/cvs/src/distrib/sets 1 error Actuallu, the named METALOG.sanitised does contain a line for exactly that spelling: ./bin/\133 type=file uname=root gname=wheel mode=0555 size=18416 sha256=887c6f1483584be2d8a8247cccef74592807859f88a5ba1b193f43fe47d81132 However the file cvs/src/distrib/sets/lists/base/mi references the file like this: ./bin/[ base-util-root So it seem that somewhere along the line, the [ gets escaped for the error message but not for the actual check in the METALOG file. Or maybe the entry in METALOG should not be escaped? Anybody knows? -Olaf. -- ___ Olaf 'Rhialto' Seibert -- "What good is a Ring of Power \X/ rhialto/at/falu.nl -- if you're unable...to Speak." - Agent Elrond signature.asc Description: PGP signature
Re: Cross-compiling Haiku from NetBSD?
On Mon 03 Dec 2018 at 07:59:55 +, Thomas Mueller wrote: > You mention Haiku. Did you ever attempt to cross-compile Haiku from > NetBSD? > > I tried but never succeeded, apparently because Haiku build system > makes assumptions about where certain files are located on host > system. Some of these differ for NetBSD and even FreeBSD. Speaking of Haiku: I was just wondering if the display server and the userland graphics libraries are sufficently stand-alone that one could run them under NetBSD? It would make a nice replacement for X and Wayland and GTK... > Tom -Olaf. -- ___ Olaf 'Rhialto' Seibert -- "What good is a Ring of Power \X/ rhialto/at/falu.nl -- if you're unable...to Speak." - Agent Elrond signature.asc Description: PGP signature
Re: Strange build error on port evbarm64
On Thu 18 Oct 2018 at 08:12:21 +0800, Paul Goyette wrote: > > /installation/misc.inst.xx >vs /installation/misc/inst.xx > ^ > __| > Anyway, I'm not going to worry about it, as long as it's not a problem > due to my pgoyette-compat branch! Pure wild and unsubstantiated speculation: I recall a discussion recently about functions like basename(3) and whether they return a pointer to static storage, or modify their argument. Maybe this implementation detail did change recently and this is an unexpected side effect? -Olaf. -- ___ Olaf 'Rhialto' Seibert -- "What good is a Ring of Power \X/ rhialto/at/falu.nl -- if you're unable...to Speak." - Agent Elrond signature.asc Description: PGP signature
Re: usbdevices.config
On Sat 18 Aug 2018 at 11:51:20 -, Michael van Elst wrote: > pr...@cam.ac.uk (Patrick Welche) writes: > > >With the introduction of usbdevices.config, the old procedure of "copy > >GENERIC to NEWCOMPUTER and comment out what isn't needed" doesn't really > >work any more. What's the thinking on The New Way(tm)? > > It stopped working for some platforms a long time ago and always > had the problem that you needed to merge changes whenever GENERIC > was augmented. > > I am using a different scheme, where the custom config file includes > GENERIC but then overrides things as necessary. E.g.: > > -- > include "arch/i386/conf/GENERIC" > ident "MYCOMPUTER" > > no options COMPAT_NOMID > no options COMPAT_09 ...etc... more "no" options.. I've tried to do that, when going from 7 to 8 and bringing along my "no config" config file. When creating it for NetBSD 7, I already noticed that it didn't really save me any time. Changing adv*at pci? dev ? function ?# AdvanSys 1200[A,B], 9xx[U,UA] SCSI to no adv*at pci? # dev ? function ?# AdvanSys 1200[A,B], 9xx[U,UA] SCSI is much more time-consuming than simply removing the line. Just adding "no" at the start of the line is a syntax error. But, I persevered in the hope that it would save me time next time around. But it didn't. My config file for 7 didn't work for 8; something had been changed in the GENERIC for 8 and the combination didn't configure any more. I also realised that there would be some new hardware supported in GENERIC that I would not have excluded. So I needed to go through the whole GENERIC file again to double check it against my "no config" file. I still haven't finished doing that. There is no option for config to show the "effective" configuration at the end, so it is hard, if not impossible, to check that I have excluded everything I wanted to exclude. There is also no syntax for, say, "I only want re* as ethernet adapter, and drop all others". There is also no script (any more) to take dmesg.boot and generate a config file from it. I think I'll go back to just starting with GENERIC and deleting lines. It's quicker and much shorter :-( A grep '^[a-z]'|wc -l (to count non-comment, non-empty lines) on my 6.1.5 config file (an edited GENERIC) is 232 lines; for my 7.0.1 "no config' file, it is 302 lines. The "no" seemed a good idea. But it didn't bring me what I had hoped from it. -Olaf. -- ___ Olaf 'Rhialto' Seibert -- Wayland: Those who don't understand X \X/ rhialto/at/falu.nl -- are condemned to reinvent it. Poorly. signature.asc Description: PGP signature
Re: current status of autofs?
On Sun 22 Apr 2018 at 14:15:21 +0200, Edmond Dantes wrote: > It seems that that the problem was somehow related to rc.conf: If I > echoed automount=YES, autmountd=YES and autounmountd=YES to ^ o missing? > /etc/rc.conf, this didn't result in the services being enbled at the > next boot, as confirmed by running: You may have a typo in autOmountd. -Olaf. -- ___ Olaf 'Rhialto' Seibert -- Wayland: Those who don't understand X \X/ rhialto/at/falu.nl -- are condemned to reinvent it. Poorly. signature.asc Description: PGP signature
Re: Remove fortune quotes attributed to or providing admiration of Adolf Hitler [pr bin/52735]
On Sun 19 Nov 2017 at 21:07:39 +0100, Joerg Sonnenberger wrote: > I call this Bullshit. This is not even Political Correctness, it is part You do realise that the term "political correctness" was intruduced as a straw man to make perfectly reasonable arguments look ridiculous? Anybody who invokes that term automatically shows their true colours. *plonk* -Olaf. -- ___ Olaf 'Rhialto' Seibert -- Wayland: Those who don't understand X \X/ rhialto/at/falu.nl -- are condemned to reinvent it. Poorly. signature.asc Description: PGP signature
Re: Remove fortune quotes attributed to or providing admiration of Adolf Hitler [pr bin/52735]
On Sun 19 Nov 2017 at 18:14:06 +, co...@sdf.org wrote: > I still think that we should remove offensive quotes, and if people > cannot agree on it, all of fortune. It isn't even so much that they are "offensive" as such. It is just that out there in the Real World, you Simply Do Not Quote Adolf Hitler, at least not without embedding it in proper historical context and making absolutely clear that we're talking about a really horrible person, etc etc. Those are all things way outside the scope of fortune(1), so those quotes have no place there. Why this is so difficult to understand for intelligent persons, I don't know. -Olaf. -- ___ Olaf 'Rhialto' Seibert -- Wayland: Those who don't understand X \X/ rhialto/at/falu.nl -- are condemned to reinvent it. Poorly. signature.asc Description: PGP signature
Re: Remove fortune quotes attributed to or providing admiration of Adolf Hitler [pr bin/52735]
On Sat 18 Nov 2017 at 23:03:27 +, David Holland wrote: > On Sat, Nov 18, 2017 at 01:21:25PM +0100, Rhialto wrote: > > I checked our fortune cookies database, and I was appalled to notice > > that we do have the same quotes there. Apart from those quotes being > > wholly inappropriate in a list of funny quotes, they are probably > > illegal in Germany (where I now happen to live). > > > > I hereby propose to remove them (but not remove all fortunes). > > I have sent a pr (bin/52735, http://gnats.netbsd.org/52735) with a > > patch. > > You are completely missing the point of why those quotes are there. Such a remark is rather useless without stating why you think they are there. It does nothing to convince me, obviously. > David A. Holland > dholl...@netbsd.org -Olaf. -- ___ Olaf 'Rhialto' Seibert -- Wayland: Those who don't understand X \X/ rhialto/at/falu.nl -- are condemned to reinvent it. Poorly. signature.asc Description: PGP signature
Re: Remove fortune quotes attributed to or providing admiration of Adolf Hitler [pr bin/52735]
On Sat 18 Nov 2017 at 15:02:01 +0100, Hauke Fath wrote: > And note the following excerpt from fortune(6): > > -oChoose only from potentially offensive aphorisms. Please, > please, >please request a potentially offensive fortune if and only > if you >believe, deep down in your heart, that you are willing to be >offended. (And that if you are, you'll just quit using -o > rather >than give us grief about it, okay?) You may have noted that the mentioned quotes are NOT part of the offensive set! (As an aside: The criteria for what is "offensive" seem rather strange to me; they seem to be mostly religious or sexuality based, something that is looked at rather differently in Europe than the USA.) I agree that bad history should be remembered in context and not forgotten. However, that is not what these quotes do. They give no context, and they make A.H. seem like a relatively normal person. Now if he was quoted at his worst, it might be obvious what sort of monster he was, but that is not the effect of these quotes. His crimes against humanity are trivialised by putting things he said next to people like Mahatma Gandhi. -Olaf. -- ___ Olaf 'Rhialto' Seibert -- Wayland: Those who don't understand X \X/ rhialto/at/falu.nl -- are condemned to reinvent it. Poorly. signature.asc Description: PGP signature
Remove fortune quotes attributed to or providing admiration of Adolf Hitler [pr bin/52735]
It has come to my attention that FreeBSD has removed fortunes quoted from Adolf Hitler a few days ago. I was very surprised that there actually were such quotes! https://svnweb.freebsd.org/base?view=revision=325781 or https://github.com/freebsd/freebsd/commit/0271df5714d9ce5274f82889febb6536a2fdba59 Then soon after that they went a bit overboard and removed basically all fortune cookies: https://svnweb.freebsd.org/base?view=revision=325828 I tried to find any discussion on this in the FreeBSD mailing lists but could not find anything, save something from 10 years ago where obviously nothing was done in the end. http://freebsd.1045724.x6.nabble.com/Re-who-wrote-this-td4249321.html I checked our fortune cookies database, and I was appalled to notice that we do have the same quotes there. Apart from those quotes being wholly inappropriate in a list of funny quotes, they are probably illegal in Germany (where I now happen to live). I hereby propose to remove them (but not remove all fortunes). I have sent a pr (bin/52735, http://gnats.netbsd.org/52735) with a patch. >How-To-Repeat: $ fortune -m Hitler all -Olaf. -- ___ Olaf 'Rhialto' Seibert -- Wayland: Those who don't understand X \X/ rhialto/at/falu.nl -- are condemned to reinvent it. Poorly. signature.asc Description: PGP signature
Re: kern/52056: mount -u / causes a kernel assertion
On Sat 11 Mar 2017 at 08:00:54 +0700, Robert Elz wrote: > Given all that, the best might be to basically copy the FreeBSD setup, > though I think I would prefer if > > mount -u > > with no command line options at all (which currently means mount rw, > and disable any other mount options previously set, on NetBSD and FreeBSD, > and would be a "convert to rw, leaving all other options on OpenBSD) > was instead treated as if (in FreeBSD syntax) > mount -u -o fstab > was given, so this (just mount -u) becomes an easy way to simply set the > filesys mount to the way fstab says it should be. Hm, personally I would expect that an "update" option would only update the options specify, and leave ALL others unchanged. So the "-o current" syntax would be the default. MAYBE a special case could be made in case only -u is given and no other options, that then the fstab options are used, but the "-o fstab" syntax to make that explicit seems better to me. -Olaf. -- ___ Olaf 'Rhialto' Seibert -- Wayland: Those who don't understand X \X/ rhialto/at/xs4all.nl-- are condemned to reinvent it. Poorly. signature.asc Description: PGP signature
Re: high cpu load with tcpdump
On Sun 06 Mar 2016 at 18:59:57 +0100, Manuel Bouyer wrote: > On Fri, Mar 04, 2016 at 12:31:07PM +, Patrick Welche wrote: > > Was there ever a conclusion to the "pipe read returning EAGAIN" thread? > > > > https://mail-index.netbsd.org/current-users/2016/02/07/msg028841.html > > The conclusion was that it's a programming error in the application, > but there's still something messy with poll (it says there's one descriptor > ready for read but there are two descriptors in the fileset). Meanwhile, in 7.0.1, tcpdump still seems to cause (close to) 100% cpu load. (Tested with "tcpdump -i re1 -vvv icmp6" on an almost idle link) Has this been fixed in -current? Will it be in 7.0.2 (or 7.1?) soon? -Olaf. -- ___ Olaf 'Rhialto' Seibert -- Wayland: Those who don't understand X \X/ rhialto/at/xs4all.nl-- are condemned to reinvent it. Poorly. signature.asc Description: PGP signature
Re: xorg-server 1.18 ready for testing on x86 and shark
On Fri 19 Aug 2016 at 16:31:00 +1000, matthew green wrote: > to test, simply pass -V HAVE_XORG_SERVER_VER=118 to build.sh or set > it in mk.conf. I recently filed a PR about weird mouse defects, which turned out to be about left-handed mice. Some xorg 1.11.x version has a fix for this. See http://gnats.netbsd.org/51348 and 51149. Since 1.18 sounds higher than 1.11.x, the fix should already be in there. I can't try it out quickly right now; maybe somebody else can do a quick check? -Olaf. -- ___ Olaf 'Rhialto' Seibert -- Wayland: Those who don't understand X \X/ rhialto/at/xs4all.nl-- are condemned to reinvent it. Poorly. signature.asc Description: PGP signature
Re: repeated failure to properly shutdown
On Sat 23 Jul 2016 at 04:38:42 +0700, Robert Elz wrote: > That /dev/null turned into a regular file is another bug - it is being > created before the tmpfs /dev is made, I have seen that before as well, > but just corrected and ignored the problem until now. Similarly, I noticed that if /var is a tmpfs (or any initially empty directory really), then /etc/rc.d/mountcritlocal fails because it wants to cd to /var/run and that has not been created (if that ever happens). -Olaf. -- ___ Olaf 'Rhialto' Seibert -- Wayland: Those who don't understand X \X/ rhialto/at/xs4all.nl-- are condemned to reinvent it. Poorly. signature.asc Description: PGP signature
Re: strange messages from -current 'dhcpcd'
On Fri 24 Jun 2016 at 17:18:52 -0500, John D. Baker wrote: > I've just noticed some strange log messages emitted by 'dhcpcd' on > -current (7.99.32). I've seen these on i386, amd64, and evbarm-earmv7hf. Yes, I've seen one too: Jun 24 23:44:03 hostname dhcpcd[PID]: re1: invalid UDP packet from 150.142.192.168 Similarly, such a packet is not supposed to have arrived here from the outside due to a NATing router. I'm using a recent dhcpcd from its development trunk. -Olaf. -- ___ Olaf 'Rhialto' Seibert -- Wayland: Those who don't understand X \X/ rhialto/at/xs4all.nl-- are condemned to reinvent it. Poorly. signature.asc Description: PGP signature
Re: Identifying the NetBSD shell
On Mon 21 Mar 2016 at 14:42:21 -0400, Thor Lancelot Simon wrote: > I strongly agree. How about just giving it a date rather than a version > number? You can still bump the date only when something significant > changes. Then scripts can just numerically require that NBSH > 20160401 > or the like. That makes a lot of sense to me. Starting at or near 1.0 would seem to imply that sh is fairly new and didn't have many previous versions, which is untrue. -Olaf. -- ___ Olaf 'Rhialto' Seibert -- The Doctor: No, 'eureka' is Greek for \X/ rhialto/at/xs4all.nl-- 'this bath is too hot.' signature.asc Description: PGP signature
Re: Is tun(4) a cloning device?
On Fri 25 Dec 2015 at 13:57:30 -0500, Christos Zoulas wrote: > Well, we could factor out the common code for these kinds of cloners > from tap and use it for both tap and tun from the look of it. Why > don't you give it a try? I'll give it a go! It will be a few days before I can actually try it out though but there is no hurry. > christos -Olaf. -- ___ Olaf 'Rhialto' Seibert -- The Doctor: No, 'eureka' is Greek for \X/ rhialto/at/xs4all.nl-- 'this bath is too hot.' signature.asc Description: PGP signature
Re: Is tun(4) a cloning device?
On Fri 25 Dec 2015 at 16:02:57 +, Christos Zoulas wrote: > Exactly, it depends if it makes sense to have a magic minor device like > that... Does it? Well, it seems that Linux has it. In fact, it has a single file for both tap en tun (/dev/net/tun) and an ioctl to change it between tun and tap. I don't propose to go that far (I think needing to use an ioctl to choose mode is inconvenient), but having the same facilities for tun and tap would be nicely symmetrical. (I'm looking at this because I'm reworking the networking part of the klh10 PDP-10 emulator, at https://github.com/Rhialto/klh10/tree/libpcap, and the more symmetrical I can make stuff the happier it makes me. Tun is used for the KS10 with ITS, to make its IMP communicate with the world.) > christos -Olaf. -- ___ Olaf 'Rhialto' Seibert -- The Doctor: No, 'eureka' is Greek for \X/ rhialto/at/xs4all.nl-- 'this bath is too hot.' signature.asc Description: PGP signature
Re: Is tun(4) a cloning device?
On Fri 25 Dec 2015 at 17:26:04 +, Robert Swindells wrote: > Why not use tap(4) ? Yes, I use that too as an option. That's why I like tun and tap to be as similar as possible (barring their fundamental differences of course). If both can just open /dev/xxx that is nicer than one use case just opening /dev/tap and the other needing to probe /dev/tun0, tun1, etc. > I have used it in emulators for machines of the same vintage and it works > well. Indeed it does. Especially when bridged to another, real, interface. > Robert Swindells -Olaf. -- ___ Olaf 'Rhialto' Seibert -- The Doctor: No, 'eureka' is Greek for \X/ rhialto/at/xs4all.nl-- 'this bath is too hot.' signature.asc Description: PGP signature
Is tun(4) a cloning device?
From reading the source, net/if_tun.c, I get the impression that tun is a cloning device. Like tap. (The word clone appears several times) But for tap this is mentioned in the manual, and MAKEDEV creates a /dev/tap (next to /dev/tap[0-3]). But not for tun, when it seems it could be. Any particular reason for this? If they were both cloning it would remove a nagging inconsistency and be much nicer for virtual machine emulators. -Olaf. -- ___ Olaf 'Rhialto' Seibert -- The Doctor: No, 'eureka' is Greek for \X/ rhialto/at/xs4all.nl-- 'this bath is too hot.' signature.asc Description: PGP signature
no vga* at pci?
If I configure a (amd64, 7.0) kernel with no vga* at pci? then it fails to boot (properly). This is despite the fact that no "vga at pci" ever seems to get configured (so it is unneeded). Instead, I have acpivga0 at acpi0 (OVGA): ACPI Display Adapter What happens is rather strange. After the kernel is loaded, the copyright message does not appear. After a few moments the screen is however switched to graphics mode and the text that happens to be on-screen is converted to it. The colour is however not the usual green but something fairly dark and hardly visible. The caps-lock led reacts. One could think that the kernel is continuing with the boot process but without further feedback, but waiting a while never results in being able to log in with ssh. Any idea why vga is more important than it seems to be? -Olaf. -- ___ Olaf 'Rhialto' Seibert -- The Doctor: No, 'eureka' is Greek for \X/ rhialto/at/xs4all.nl-- 'this bath is too hot.' signature.asc Description: PGP signature
Re: Bad sleep time resolution of nanosleep(2)
On Tue 24 Nov 2015 at 06:54:09 +, Michael van Elst wrote: > N.B. nanosleep shouldn't be based on ticks. I agree. I found that I get much better precision if I simply subtract 1/HZ seconds from the time I want to sleep, since that always gets added in practice. But user programs should not need to do that (not need to find out the value of HZ). -Olaf. -- ___ Olaf 'Rhialto' Seibert -- The Doctor: No, 'eureka' is Greek for \X/ rhialto/at/xs4all.nl-- 'this bath is too hot.' signature.asc Description: PGP signature
Bad sleep time resolution of nanosleep(2)
In the context of the machine simulator simh, which needs some accurate
timing now and then, I have come across an example of rather bad time
resolution of the nanosleep() system call. The minimal sleep time seems
to be 20 ms, even if you ask for just 1 ms delay. If you ask for longer
sleeps, the discrepancy becomes relatively less but remains substantial:
20 ms becomes 30 ms, and 40 ms becomes 50.
For the standard HZ=100, one would expect the worst resolution to be
1000/100 = 10 ms.
As an experiment, I built a kernel with "options HZ=1000" for NetBSD 7,
and even there a 1 ms sleep still takes 2 ms. For other times, the
actual time seems systematically 1 ms too long.
This seems to indicate that the actual time is rounded up to whole ticks
and then another whole tick is added. I'd expect the former, but not the
latter; this seems rather unnecessarily inaccurate.
I have measured times in us (microseconds) using the following program,
which is derived from the simh sources.
#include
#include
#include
#include
#define NANOS_PER_MILLI 100
#define MILLIS_PER_SEC 1000
#define sleep1Samples 100
uint64_t sim_os_usec (void)
{
struct timeval cur;
gettimeofday (, NULL);
return cur.tv_sec * 100L + cur.tv_usec;
}
/* returns the time actually slept in microseconds */
uint32_t sim_os_ms_sleep (unsigned int milliseconds)
{
uint64_t stime = sim_os_usec ();
struct timespec treq;
treq.tv_sec = milliseconds / MILLIS_PER_SEC;
treq.tv_nsec = (milliseconds % MILLIS_PER_SEC) * NANOS_PER_MILLI;
(void) nanosleep (, NULL);
return sim_os_usec () - stime;
}
void sim_os_ms_sleep_init (int milliseconds)
{
uint32_t i, tot, tim;
uint64_t t1, t2;
sim_os_ms_sleep (1); /* Start sampling on a tick boundary
*/
for (i = 0, tot = 0; i < sleep1Samples; i++) {
t1 = sim_os_usec ();
sim_os_ms_sleep (milliseconds);
t2 = sim_os_usec ();
tot += (t2 - t1);
}
tim = (tot + (sleep1Samples - 1)) / sleep1Samples;
printf("precision of %d ms sleep: %d microsec (should be %d microsec)\n",
milliseconds, tim, milliseconds * 1000);
}
int main(int argc, char **argv)
{
int ms = 1;
if (argc > 1) {
ms = atoi(argv[1]);
}
sim_os_ms_sleep_init(ms);
return 0;
}
-Olaf.
--
___ Olaf 'Rhialto' Seibert -- The Doctor: No, 'eureka' is Greek for
\X/ rhialto/at/xs4all.nl-- 'this bath is too hot.'
signature.asc
Description: PGP signature
Re: Bad sleep time resolution of nanosleep(2)
On Tue 24 Nov 2015 at 00:41:42 +0100, Joerg Sonnenberger wrote: > On Tue, Nov 24, 2015 at 12:25:45AM +0100, Rhialto wrote: > > In the context of the machine simulator simh, which needs some accurate > > timing now and then, I have come across an example of rather bad time > > resolution of the nanosleep() system call. The minimal sleep time seems > > to be 20 ms, even if you ask for just 1 ms delay. If you ask for longer > > sleeps, the discrepancy becomes relatively less but remains substantial: > > 20 ms becomes 30 ms, and 40 ms becomes 50. > > Well, it is rounded up first to whole ticks, that's the easy part. Next > the callout is scheduled at the tick boundary and then the LWP is > unblocked and scheduled again. It will run in the next scheduling cycle > unless nothing else is running? I tried it on some fairly idle machines, and the result was quite consistent. It really looks like there is something in there that inadvertently always causes an extra tick delay. > Joerg -Olaf. -- ___ Olaf 'Rhialto' Seibert -- The Doctor: No, 'eureka' is Greek for \X/ rhialto/at/xs4all.nl-- 'this bath is too hot.' signature.asc Description: PGP signature
Re: NFS related panic? (was: Re: Killing a zombie process?)
On Fri 23 Oct 2015 at 00:46:57 +0200, Rhialto wrote: > This problem is very repeatable, usually within a few hours, just now it > happened within half an hour. > > It seems to me that somehow the nfs_reqq list gets corrupted. Then > either there is a crash when traversing it in nfs_timer() (occurring in > nfs_sigintr() due to being called with a bogus pointer), or there is a > hang when one of the NFS requests gets lost and never retried. I tried it with a TCP mount for NFS. Still hangs, this time in a bit under an hour of uptime. So the cause is likely not packet loss. -Olaf. -- ___ Olaf 'Rhialto' Seibert -- The Doctor: No, 'eureka' is Greek for \X/ rhialto/at/xs4all.nl-- 'this bath is too hot.' signature.asc Description: PGP signature
Re: NFS related panic? (was: Re: Killing a zombie process?)
This problem is very repeatable, usually within a few hours, just now it happened within half an hour. It seems to me that somehow the nfs_reqq list gets corrupted. Then either there is a crash when traversing it in nfs_timer() (occurring in nfs_sigintr() due to being called with a bogus pointer), or there is a hang when one of the NFS requests gets lost and never retried. -Olaf. -- ___ Olaf 'Rhialto' Seibert -- The Doctor: No, 'eureka' is Greek for \X/ rhialto/at/xs4all.nl-- 'this bath is too hot.' signature.asc Description: PGP signature
Re: NFS related panic? (was: Re: Killing a zombie process?)
On Tue 20 Oct 2015 at 01:04:59 +0200, Rhialto wrote:
> with a rebuilt netbsd.gdb (hopefully the addresses match)
>
> #5 0x806b94b4 in nfs_sigintr (nmp=0x0, rep=0xfe81163730a8,
> l=0x0) at ../../../../nfs/nfs_socket.c:871
nmp should not be NULL here... let's look at rep, where it comes from
via "nmp = rep->r_nmp;"
(gdb) print *(struct nfsreq *)0xfe81163730a8
$1 = {r_chain = {tqe_next = 0xfe811edcee40, tqe_prev = 0x1}, r_mreq =
0x828f9888, r_mrep = 0x0, r_md = 0x0, r_dpos = 0x0, r_nmp = 0x0, r_xid
= 0, r_flags = 0, r_retry = 0, r_rexmit = 0, r_procnum = 0, r_rtt = 0,
r_lwp = 0x0}
well, r_chain.tqe_prev looks bogus (unless that's a special marker), so
let's look at tqe_next:
(gdb) print *((struct nfsreq *)0xfe81163730a8)->r_chain.tqe_next
$3 = {r_chain = {tqe_next = 0x0, tqe_prev = 0x15aa3c85d}, r_mreq =
0xbd83e8af8fe58282, r_mrep = 0x81e39981e3a781e3, r_md = 0xe39d81e38180e38c,
r_dpos = 0x8890e5b4a0e5ae81, r_nmp = 0xe57baf81e3ab81e3, r_xid = 2179183259,
r_flags = -1565268289, r_retry = 0, r_rexmit = 0, r_procnum = 1520683101,
r_rtt = 1, r_lwp = 0x80e39981e3a781e3}
well, even more bogus. Too bad that the next frame has its argument
optimized out...
-Olaf.
--
___ Olaf 'Rhialto' Seibert -- The Doctor: No, 'eureka' is Greek for
\X/ rhialto/at/xs4all.nl-- 'this bath is too hot.'
signature.asc
Description: PGP signature
Re: NFS related panic? (was: Re: Killing a zombie process?)
with a rebuilt netbsd.gdb (hopefully the addresses match)
(gdb) target kvm netbsd.5.core
0x8063d735 in cpu_reboot (howto=howto@entry=260,
bootstr=bootstr@entry=0x0) at ../../../../arch/amd64/amd64/machdep.c:671
671 dumpsys();
(gdb) bt
#0 0x8063d735 in cpu_reboot (howto=howto@entry=260,
bootstr=bootstr@entry=0x0) at ../../../../arch/amd64/amd64/machdep.c:671
#1 0x80865182 in vpanic (fmt=0x80d123b2 "trap",
fmt@entry=0x80d123d2 "otection fault",
ap=ap@entry=0xfe80b9fc1d10) at ../../../../kern/subr_prf.c:340
#2 0x8086523d in panic (fmt=fmt@entry=0x80d123d2
"otection fault") at ../../../../kern/subr_prf.c:256
#3 0x808a84d6 in trap (frame=0xfe80b9fc1e30) at
../../../../arch/amd64/amd64/trap.c:298
#4 0x80100f46 in alltraps ()
#5 0x806b94b4 in nfs_sigintr (nmp=0x0, rep=0xfe81163730a8,
l=0x0) at ../../../../nfs/nfs_socket.c:871
#6 0x806b9b0e in nfs_timer (arg=) at
../../../../nfs/nfs_socket.c:752
#7 0x805e9458 in callout_softclock (v=) at
../../../../kern/kern_timeout.c:736
#8 0x805df84a in softint_execute (l=,
s=, si=) at
../../../../kern/kern_softint.c:589
#9 softint_dispatch (pinned=, s=2) at
../../../../kern/kern_softint.c:871
#10 0x8011402f in Xsoftintr ()
(gdb) kvm proc 0xfe813fb39860
nfs_timer (arg=) at ../../../../nfs/nfs_socket.c:735
735 {
(gdb) bt
#0 nfs_timer (arg=) at ../../../../nfs/nfs_socket.c:735
#1 0x in ?? ()
-Olaf.
--
___ Olaf 'Rhialto' Seibert -- The Doctor: No, 'eureka' is Greek for
\X/ rhialto/at/xs4all.nl-- 'this bath is too hot.'
signature.asc
Description: PGP signature
NFS related panic? (was: Re: Killing a zombie process?)
On Fri 16 Oct 2015 at 16:31:18 +0200, J. Hannken-Illjes wrote: > On 16 Oct 2015, at 13:44, Rhialto <rhia...@falu.nl> wrote: > > > "Interesting" results: it built packages overnight (from around 22:30 to > > 12:13, so for nearly 14 hours), then, when I didn't look, it rebooted. > > With panic? I re-tried and with a pure GENERIC 7.0 kernel it happened again and now I have a crash dump. Its dmesg ends with this: nfs server 10.0.0.16:/mnt/scratch: not responding nfs server 10.0.0.16:/mnt/scratch: is alive again fatal page fault in supervisor mode trap type 6 code 0 rip 806b94b4 cs 8 rflags 10246 cr2 38 ilevel 2 rsp ff fffe80b9fc1f28 curlwp 0xfe813fb39860 pid 0.5 lowest kstack 0xfe80b9fbf2c0 panic: trap cpu0: Begin traceback... vpanic() at netbsd:vpanic+0x13c snprintf() at netbsd:snprintf startlwp() at netbsd:startlwp alltraps() at netbsd:alltraps+0x96 callout_softclock() at netbsd:callout_softclock+0x248 softint_dispatch() at netbsd:softint_dispatch+0x79 DDB lost frame for netbsd:Xsoftintr+0x4f, trying 0xfe80b9fc1ff0 Xsoftintr() at netbsd:Xsoftintr+0x4f --- interrupt --- 0: cpu0: End traceback... dumping to dev 0,1 (offset=199775, size=1023726): pid 0.5 is this: PIDLID S CPU FLAGS STRUCT LWP * NAME WAIT 0> 5 7 0 200 fe813fb39860 softclk/0 gdb (without debugging symbols) so far thinks this is in nfs_timer(): (gdb) kvm proc 0xfe813fb39860 0x806b9aab in nfs_timer () (gdb) bt #0 0x806b9aab in nfs_timer () #1 0x0000 in ?? () -Olaf. -- ___ Olaf 'Rhialto' Seibert -- The Doctor: No, 'eureka' is Greek for \X/ rhialto/at/xs4all.nl-- 'this bath is too hot.' signature.asc Description: PGP signature
Re: Killing a zombie process?
On Thu 15 Oct 2015 at 20:12:44 +0200, Rhialto wrote: > On Thu 15 Oct 2015 at 06:57:42 +0700, Robert Elz wrote: > > Do you really need that mounted twice like that, and if not, can you try > > with one of them missing and see if the problem remains ? > > Good idea, I'll try that later! "Interesting" results: it built packages overnight (from around 22:30 to 12:13, so for nearly 14 hours), then, when I didn't look, it rebooted. -Olaf. -- ___ Olaf 'Rhialto' Seibert -- The Doctor: No, 'eureka' is Greek for \X/ rhialto/at/xs4all.nl-- 'this bath is too hot.' pgpjZl4aS0WfY.pgp Description: PGP signature
Re: Killing a zombie process?
On Fri 16 Oct 2015 at 16:29:55 +0200, J. Hannken-Illjes wrote: > Looks like we are waiting for a NFS operation to complete. > > Did the machine hang here? No, but I didn't try specifically to access the nfs volumes. Interestingly enough, after the reboot (which used the stock 7.0 GENERIC kernel) I'm back at a hanging build, at a point which even more points to NFS: 13:02 cd /usr/pkgsrc/print/teTeX3-texmf && /usr/bin/make update CLEANDEPENDS=yes ===> do-bin-install [teTeX-texmf-3.0nb56] ===> Binary install for teTeX-texmf-3.0nb56 => Installing teTeX-texmf-3.0nb56 from /pkg_comp/packages/All pkg_add: no pkg found for 'teTeX-texmf-3.0nb56', sorry. pkg_add: 1 package addition failed => No binary package found for teTeX-texmf-3.0nb56; installing from source. load: 1.00 cmd: sh 22134 [wait] 0.00u 0.00s 0% 1424k make[1]: Working in: /usr/pkgsrc/print/teTeX3-texmf make: Working in: /usr/pkgsrc/print/teTeX3-texmf make[2]: Working in: /usr/pkgsrc/print/teTeX3-texmf load: 1.00 cmd: sh 22134 [wait] 0.00u 0.00s 0% 1424k make[1]: Working in: /usr/pkgsrc/print/teTeX3-texmf make: Working in: /usr/pkgsrc/print/teTeX3-texmf make[2]: Working in: /usr/pkgsrc/print/teTeX3-texmf load: 0.03 cmd: sh 22134 [wait] 0.00u 0.00s 0% 1424k make[2]: Working in: /usr/pkgsrc/print/teTeX3-texmf make: Working in: /usr/pkgsrc/print/teTeX3-texmf make[1]: Working in: /usr/pkgsrc/print/teTeX3-texmf and no process in tstile. But now I am trying to access all the NFS mounts and they all manage to do at least an ls and du (at least for a few seconds until interrupted). Now I'm interrupting the make, which gives me a shell prompt back but not all is working: ^C pkg_comp:default70.conf# pkg_comp:default70.conf# pkg_comp:default70.conf# cd usr/pkgsrc/print/teTeX3-texmf pkg_comp:default70.conf# make clean load: 0.78 cmd: sh 28490 [wait] 0.00u 0.00s 0% 1424k make: Working in: /usr/pkgsrc/print/teTeX3-texmf The full du I was doing for the mount of /usr/pkgsrc is now also stalled. I think we can conclude from this that indeed it is some NFS problem. -Olaf. -- ___ Olaf 'Rhialto' Seibert -- The Doctor: No, 'eureka' is Greek for \X/ rhialto/at/xs4all.nl-- 'this bath is too hot.' pgp1LAPQggHie.pgp Description: PGP signature
Re: Killing a zombie process?
On Fri 16 Oct 2015 at 16:31:18 +0200, J. Hannken-Illjes wrote: > On 16 Oct 2015, at 13:44, Rhialto <rhia...@falu.nl> wrote: > > > On Thu 15 Oct 2015 at 20:12:44 +0200, Rhialto wrote: > >> On Thu 15 Oct 2015 at 06:57:42 +0700, Robert Elz wrote: > >>> Do you really need that mounted twice like that, and if not, can you try > >>> with one of them missing and see if the problem remains ? > >> > >> Good idea, I'll try that later! > > > > "Interesting" results: it built packages overnight (from around 22:30 to > > 12:13, so for nearly 14 hours), then, when I didn't look, it rebooted. > > With panic? This was logged; for some reason savecore claims there is no dump though. Oct 15 19:47:32 vargaz /netbsd: NetBSD 7.99.21 (GENERIC) #1: Wed Oct 14 01:52:52 CEST 2015 Oct 16 12:15:16 vargaz syslogd[798]: restart Oct 16 12:15:16 vargaz /netbsd: fatal page fault in supervisor mode Oct 16 12:15:16 vargaz /netbsd: trap type 6 code 0 rip 80714eed cs 8 rflags 10246 cr2 38 ilevel 2 rsp fe80b9fc6f10 Oct 16 12:15:16 vargaz /netbsd: curlwp 0xfe813fb34860 pid 0.5 lowest kstack 0xfe80b9fc32c0 Oct 16 12:15:16 vargaz /netbsd: panic: trap Oct 16 12:15:16 vargaz /netbsd: cpu0: Begin traceback... Oct 16 12:15:16 vargaz /netbsd: vpanic() at netbsd:vpanic+0x13c Oct 16 12:15:16 vargaz /netbsd: snprintf() at netbsd:snprintf Oct 16 12:15:16 vargaz /netbsd: startlwp() at netbsd:startlwp Oct 16 12:15:16 vargaz /netbsd: alltraps() at netbsd:alltraps+0x9e Oct 16 12:15:16 vargaz /netbsd: callout_softclock() at netbsd:callout_softclock+0x392 Oct 16 12:15:16 vargaz /netbsd: softint_dispatch() at netbsd:softint_dispatch+0xd3 Oct 16 12:15:16 vargaz /netbsd: DDB lost frame for netbsd:Xsoftintr+0x4f, trying 0xfe80b9fc6ff0 Oct 16 12:15:16 vargaz /netbsd: Xsoftintr() at netbsd:Xsoftintr+0x4f Oct 16 12:15:16 vargaz /netbsd: --- interrupt --- Oct 16 12:15:16 vargaz /netbsd: 0: Oct 16 12:15:16 vargaz /netbsd: cpu0: End traceback... Oct 16 12:15:16 vargaz /netbsd: Oct 16 12:15:16 vargaz /netbsd: dumping to dev 0,1 (offset=199775, size=1023726): Oct 16 12:15:16 vargaz /netbsd: dump succeeded Oct 16 12:15:16 vargaz /netbsd: Oct 16 12:15:16 vargaz /netbsd: Oct 16 12:15:16 vargaz /netbsd: rebooting... Oct 16 12:15:16 vargaz /netbsd: Copyright (c) 1996, 1997, 1998, 1999, 2000, 2001, 2002, 2003, 2004, 200 -Olaf. -- ___ Olaf 'Rhialto' Seibert -- The Doctor: No, 'eureka' is Greek for \X/ rhialto/at/xs4all.nl-- 'this bath is too hot.' pgpAW2dZkzxc5.pgp Description: PGP signature
Re: Killing a zombie process?
On Thu 15 Oct 2015 at 06:57:42 +0700, Robert Elz wrote: > I do wonder about ... > > | procfs on /usr/pkg/emul/linux32/proc type procfs (read-only, local) > | procfs on /usr/pkg/emul/linux32/proc type procfs (local) Ah good catch. That seems to be a botched attempt to mount the linux procfs /inside/ the chroot. But I made a typo somewhere. That used to be needed in the past for building some package I think, but since I don't have it on my main machine that is probably not true any more. > Especially since some of the tstile processes you showed are doing > lookups under namei_tryemulroot() However the getcwds should not come near that proc directory, since it is outside the chroot. > Do you really need that mounted twice like that, and if not, can you try > with one of them missing and see if the problem remains ? Good idea, I'll try that later! > kre -Olaf. -- ___ Olaf 'Rhialto' Seibert -- The Doctor: No, 'eureka' is Greek for \X/ rhialto/at/xs4all.nl-- 'this bath is too hot.' pgps_cMO0dZAW.pgp Description: PGP signature
Re: Killing a zombie process?
On Thu 15 Oct 2015 at 00:21:55 +0200, Rhialto wrote: > I've got a whole lot more in tstile, and that is even just from running > pkg_comp in the chroot. I didn't try to interrupt anything yet. I forgot to mention that this is with a kernel cvs'ed about 24 hours ago. So this issue isn't the same as the zombie-counting issue. -Olaf. -- ___ Olaf 'Rhialto' Seibert -- The Doctor: No, 'eureka' is Greek for \X/ rhialto/at/xs4all.nl-- 'this bath is too hot.' pgppbtv6tsBL9.pgp Description: PGP signature
Re: Killing a zombie process?
I may have something similar; with 7.0/amd64 GENERIC kernel. I've been doing builds in pkg_comp with the chroot directory and /usr/pkgsrc mounted over nfs. After some packages, some processes simply don't terminate. Some of my processes are now (after trying to exit pkg_comp which hangs) UID PID PPID CPU PRI NIVSZ RSS WCHAN STAT TTY TIME COMMAND 0 402 10 85 0 15360 1428 waitIpts/2 0:00.00 /bin/sh -c set -e; /usr/bin/find /pkg_comp/packages/*/lame-3.99.5nb3.tgz -type l -print\t 2>/dev/null | /usr/bin/xargs /bin/rm -f 1000 683 29070 85 0 13224 2588 waitIs pts/2 0:00.03 -bash 0 2847 683 257 117 0 13304 1576 tstile D+ pts/2 0:00.02 /bin/sh /usr/pkg/sbin/pkg_comp chroot 0 14284 10 85 0 15360 1428 waitIpts/2 0:00.00 /bin/sh -c set -e; /usr/bin/find /pkg_comp/packages/*/lame-3.99.5nb3.tgz -type l -print\t 2>/dev/null | /usr/bin/xargs /bin/rm -f 0 26291 402 708 117 0 15360 1004 tstile Dpts/2 0:00.00 /bin/sh -c set -e; /usr/bin/find /pkg_comp/packages/*/lame-3.99.5nb3.tgz -type l -print\t 2>/dev/null | /usr/bin/xargs /bin/rm -f 0 28266 142840 116 0 15360 1004 netio Dpts/2 0:00.01 /bin/sh -c set -e; /usr/bin/find /pkg_comp/packages/*/lame-3.99.5nb3.tgz -type l -print\t 2>/dev/null | /usr/bin/xargs /bin/rm -f No zombies involved, though. -Olaf. -- ___ Olaf 'Rhialto' Seibert -- The Doctor: No, 'eureka' is Greek for \X/ rhialto/at/xs4all.nl-- 'this bath is too hot.' pgpEteqPwgwva.pgp Description: PGP signature
Re: Debugging Epiphany/Midori (webkit-gtk based) on earmv6hf (RPI 2)
On Thu 08 Oct 2015 at 17:59:22 +, Stephan wrote: > IMHO it would be valid to pass the value of sp as the first argument > (mov r0, sp). However, the way how r0 is computed looks quite > obfuscated to me: > >0x4621402c <g_dpgettext2+72>: mov r3, sp=> ? >0x46214030 <g_dpgettext2+76>: lsr r7, r3, #3 => ? >0x46214034 <g_dpgettext2+80>: lsl r4, r7, #3 => ? ... >0x46214040 <g_dpgettext2+92>: mov r0, r4 => ? I don't really know any ARM assembly but it seems that the value from sp is shifted right 3 bits and then left again. In effect clearing the low 3 bits, or aligning to 8. Which by itself is a very sensible thing to do for an allocator. Unfortunately (since it rounds down) it can have the effect of allocating the memory lower than sp, which is bound to fail at some point. Probably the value should also go back into sp. There is also an alloca in libc: cvs/src/lib/libc/arch/arm/gen/alloca.S. It uses a similar shifting trick but it uses it to round up the allocation size to multiples of 8, and it does end up with the same value in r0 and sp. -Olaf. -- ___ Olaf 'Rhialto' Seibert -- The Doctor: No, 'eureka' is Greek for \X/ rhialto/at/xs4all.nl-- 'this bath is too hot.' pgpFCM8YmMK22.pgp Description: PGP signature
Re: pkgsrc-2015Q3 released
On Wed 30 Sep 2015 at 10:29:16 -0400, Greg Troxel wrote: > Basically yes. Howver, you may want to do a final update of the tree > From sourceforge and verify you have no uncommitted changes that you > want to keep. (If so, you will have to manage them manually.) which currently gives errors about "cannot close CVS/Entries" and "No space left on device"... precisely the sort of reasons we moved away from there of course. -Olaf. -- ___ Olaf 'Rhialto' Seibert -- The Doctor: No, 'eureka' is Greek for \X/ rhialto/at/xs4all.nl-- 'this bath is too hot.' pgpoN9Y81jqSp.pgp Description: PGP signature
Re: kqueue: SIGIO?
On Tue 29 Sep 2015 at 13:22:08 +0200, Tobias Nygren wrote: > Here is the relevant bit of the talk if you are curious: > > https://www.youtube.com/watch?v=t400SmZlnO8=youtu.be=1888 So he wants a signal when a message is available in a kqueue, in other words, can be read with kevent(2). I do notice there are message queues (mq(3)) which are file descriptors and have such functionality. Does that mean that mq_notify(3) might work on any file descriptor, or is that too optimistic in hoping that these things are implemented orthogonally? -Olaf. -- ___ Olaf 'Rhialto' Seibert -- The Doctor: No, 'eureka' is Greek for \X/ rhialto/at/xs4all.nl-- 'this bath is too hot.' pgpsL3oyNyHuS.pgp Description: PGP signature
Re: X server crashes on -current
On Mon 29 Jun 2015 at 00:42:29 +0200, Rhialto wrote: Datewise, that matches! I'm updating and retrying, and I will report the result. The problem with truetype fonts seems to be fixed indeed. I tried it a few times. The X server still leaves a core dump when you quit the initial login shell with ^D. Interestingly, the xkbcomp messages seem invisible on the screen but script caught them somehow. Script started on Mon Jun 29 23:14:04 2015 test$ startx xauth: file /home/rhialto/.serverauth.2064 does not exist xauth: (argv):1: bad display name test:0 in list command xauth: (stdin):1: bad display name test:0 in add command X.Org X Server 1.10.6 Release Date: 2011-07-08 X Protocol Version 11, Revision 0 Build Operating System: NetBSD/amd64 - Current Operating System: NetBSD test 7.99.19 NetBSD 7.99.19 (GENERIC) #1: Mon Jun 29 05:15:08 CEST 2015 rhia...@murthe.falu.nl:/mnt/scratch/scratch2/obj.amd64/sys/arch/amd64/compile/GENERIC amd64 Build Date: 01 August 2011 01:01:00AM Current version of pixman: 0.32.6 Before reporting problems, check http://wiki.X.Org to make sure that you have the latest version. Markers: (--) probed, (**) from config file, (==) default setting, (++) from command line, (!!) notice, (II) informational, (WW) warning, (EE) error, (NI) not implemented, (??) unknown. (==) Log file: /var/log/Xorg.0.log, Time: Mon Jun 29 23:14:10 2015 (==) Using default built-in configuration (21 lines) The XKEYBOARD keymap compiler (xkbcomp) reports: Error:Couldn't lookup keysym Symbol interpretation ignored Error:Couldn't lookup keysym Symbol interpretation ignored Errors from xkbcomp are not fatal to the X server à^] àà^] à9¹^\xinit: connection to X server lost waiting for X server to shut down /usr/X11R7/bin/xterm: fatal IO error 35 (Resource temporarily unavailable) or KillClient on X server :0 /usr/X11R7/bin/xterm: fatal IO error 35 (Resource temporarily unavailable) or KillClient on X server :0 .Segmentation fault at address 0x7f7fee9215b6 Fatal server error: Caught signal 11 (Segmentation fault). Server aborting Please consult the The X.Org Foundation support at http://wiki.X.Org for help. Please also check the log file at /var/log/Xorg.0.log for additional information. xinit: unexpected signal 3 xauth: (argv):1: bad display name test:0 in remove command test$ ^D Script done on Mon Jun 29 23:14:25 2015 Is it normal that glxinfo only works fully when run as root? If run as a normal user it complains about not being able to open some things, and ends with a core dump. Script started on Mon Jun 29 23:08:15 2015 test$ glxinfo name of display: :0 libGL error: failed to open drm device: Permission denied libGL error: failed to load driver: i965 display: :0 screen: 0 direct rendering: Yes server glx vendor string: SGI server glx version string: 1.4 server glx extensions: ... 0x074 24 dc 0 32 0 r y . 8 8 8 8 . . 0 24 8 16 16 16 16 0 0 Slow [1] Segmentation fault (core dumped) glxinfo test$ ^D Script done on Mon Jun 29 23:08:26 2015 -Olaf. -- ___ Olaf 'Rhialto' Seibert -- The Doctor: No, 'eureka' is Greek for \X/ rhialto/at/xs4all.nl-- 'this bath is too hot.' pgpg07xKUQ7Uc.pgp Description: PGP signature
X server crashes on -current
Earlier this week I build an amd64 current and a live image. I booted it on my laptop, and started X under a fresh user I created. No other configuration has been done, not even setting a host name. When I enabled TrueType fonts in xterm, the first time I got a blob of display corruption. When I did the same another time, after a reboot, the X server crashed. I have attached Xorg.0.log (which doesn't really tell me much) and /var/run/dmesg.boot. -Olaf. -- ___ Olaf 'Rhialto' Seibert -- The Doctor: No, 'eureka' is Greek for \X/ rhialto/at/xs4all.nl-- 'this bath is too hot.' [89.530] X.Org X Server 1.10.6 Release Date: 2011-07-08 [89.530] X Protocol Version 11, Revision 0 [89.531] Build Operating System: NetBSD/amd64 - [89.531] Current Operating System: NetBSD 7.99.19 NetBSD 7.99.19 (GENERIC) #0: Tue Jun 23 22:37:03 CEST 2015 rhia...@murthe.falu.nl:/mnt/scratch/scratch2/obj.amd64/sys/arch/amd64/compile/GENERIC amd64 [89.531] Build Date: 01 August 2011 01:01:00AM [89.531] [89.531] Current version of pixman: 0.32.6 [89.531]Before reporting problems, check http://wiki.X.Org to make sure that you have the latest version. [89.531] Markers: (--) probed, (**) from config file, (==) default setting, (++) from command line, (!!) notice, (II) informational, (WW) warning, (EE) error, (NI) not implemented, (??) unknown. [89.532] (==) Log file: /var/log/Xorg.0.log, Time: Fri Jun 26 17:00:21 2015 [89.547] (II) Loader magic: 0x829c80 [89.547] (II) Module ABI versions: [89.547]X.Org ANSI C Emulation: 0.4 [89.547]X.Org Video Driver: 10.0 [89.547]X.Org XInput driver : 12.2 [89.547]X.Org Server Extension : 5.0 [89.559] (--) PCI:*(0:0:2:0) 8086:2a42:103c:306b rev 7, Mem @ 0xd000/4194304, 0xc000/268435456, I/O @ 0x4110/8 [89.560] (--) PCI: (0:0:2:1) 8086:2a43:103c:306b rev 7, Mem @ 0xd240/1048576 [89.561] (==) Using default built-in configuration (21 lines) [89.561] (==) --- Start of built-in configuration --- [89.561]Section Device [89.561]Identifier Builtin Default intel Device 0 [89.561]Driver intel [89.561]EndSection [89.561]Section Screen [89.561]Identifier Builtin Default intel Screen 0 [89.561]Device Builtin Default intel Device 0 [89.562]EndSection [89.562]Section Device [89.562]Identifier Builtin Default vesa Device 0 [89.562]Driver vesa [89.562]EndSection [89.562]Section Screen [89.562]Identifier Builtin Default vesa Screen 0 [89.562]Device Builtin Default vesa Device 0 [89.562]EndSection [89.562]Section ServerLayout [89.562]Identifier Builtin Default Layout [89.562]Screen Builtin Default intel Screen 0 [89.562]Screen Builtin Default vesa Screen 0 [89.562]EndSection [89.562] (==) --- End of built-in configuration --- [89.563] (==) ServerLayout Builtin Default Layout [89.563] (**) |--Screen Builtin Default intel Screen 0 (0) [89.563] (**) | |--Monitor default monitor [89.567] (**) | |--Device Builtin Default intel Device 0 [89.567] (==) No monitor specified for screen Builtin Default intel Screen 0. Using a default monitor configuration. [89.567] (**) |--Screen Builtin Default vesa Screen 0 (1) [89.567] (**) | |--Monitor default monitor [89.567] (**) | |--Device Builtin Default vesa Device 0 [89.567] (==) No monitor specified for screen Builtin Default vesa Screen 0. Using a default monitor configuration. [89.569] (==) Not automatically adding devices [89.569] (==) Not automatically enabling devices [89.592] (==) FontPath set to: /usr/X11R7/lib/X11/fonts/misc/, /usr/X11R7/lib/X11/fonts/TTF/, /usr/X11R7/lib/X11/fonts/Type1/, /usr/X11R7/lib/X11/fonts/75dpi/, /usr/X11R7/lib/X11/fonts/100dpi/ [89.592] (==) ModulePath set to /usr/X11R7/lib/modules [89.592] (==) |--Input Device default pointer [89.592] (==) |--Input Device default keyboard [89.592] (==) The core pointer device wasn't specified explicitly in the layout. Using the default mouse configuration. [89.592] (==) The core keyboard device wasn't specified explicitly in the layout. Using the default keyboard configuration. [89.592] (II) LoadModule: extmod [89.602] (II) Loading /usr/X11R7/lib/modules/extensions/libextmod.so [89.610] (II) Module extmod: vendor=X.Org Foundation [89.612]compiled for 1.10.6, module version = 1.0.0 [89.612]Module class: X.Org Server Extension [89.612]ABI class: X.Org Server Extension, version 5.0 [89.612] (II) Loading extension MIT-SCREEN-SAVER [89.612] (II) Loading extension XFree86-VidModeExtension
Re: X server crashes on -current
On Sun 28 Jun 2015 at 22:39:16 +0100, Patrick Welche wrote: Hopefully this the same bug which Chuck Silvers fixed in v 1.31 of sys/external/bsd/drm2/dist/drm/i915/i915_gem.c on 2015-06-25 which might be just after earlier this week. Datewise, that matches! I'm updating and retrying, and I will report the result. Thanks! Patrick -Olaf. -- ___ Olaf 'Rhialto' Seibert -- The Doctor: No, 'eureka' is Greek for \X/ rhialto/at/xs4all.nl-- 'this bath is too hot.' pgphoDdFmb6kW.pgp Description: PGP signature
Re: Removal of acorn26 port
On Fri 17 Apr 2015 at 12:02:04 +, Thomas Mueller wrote: For that matter, does anybody still use port-vax? I have a few microVAXen... -Olaf. -- ___ Olaf 'Rhialto' Seibert -- The Doctor: No, 'eureka' is Greek for \X/ rhialto/at/xs4all.nl-- 'this bath is too hot.' pgpxDeoZtn55O.pgp Description: PGP signature
Re: Synaptics touchpad misdetected as clickpad [with patch]
On Tue 03 Mar 2015 at 02:30:47 +, Christos Zoulas wrote:
In article 20150303004630.gh6...@falu.nl, Rhialto rhia...@falu.nl wrote:
-=-=-=-=-=-
and no click pad. Which is isn't. It has 2 separate buttons below the
touchpad. Attaching an usb mouse serves as a workaround.
Any other info I can give?
You can turn debugging on and it will print more info...
Ok, I enabled SYNAPTICSDEBUG and booted with -x.
The kernel messages are now like so:
pms0 at pckbc1 (aux slot)
pms0: Synaptics touchpad version 6.5
pms0: synaptics_probe: Capabilities 0xa051.
pms0: pms_synaptics_probe_extended: Extended Buttons: 0.
pms0: pms_synaptics_probe_extended: Extended Capabilities: 0xa0 0x00 0x00.
pms0: pms_synaptics_probe_extended: Continued Capabilities 0x0f 0xf1 0x40.
pms0: Palm detect, One button click pad
Looking at the code which prints this, in
src/sys/dev/pckbport/synaptics.c, function
pms_synaptics_probe_extended(),
191 /* Ask about click pad */
192 if (((sc-caps SYNAPTICS_CAP_EXTNUM) + 0x08) =
193 SYNAPTICS_CONTINUED_CAPABILITIES)
194 {
195 res = pms_sliced_command(psc-sc_kbctag,
196 psc-sc_kbcslot, SYNAPTICS_CONTINUED_CAPABILITIES);
197 cmd[0] = PMS_SEND_DEV_STATUS;
198 res |= pckbport_poll_cmd(psc-sc_kbctag,
199 psc-sc_kbcslot, cmd, 1, 3, resp, 0);
200 if (res == 0) {
201 u_char clickpad_type = (resp[1] 0x1);
202 clickpad_type |= ((resp[0] 4) 0x1);
203
204 aprint_debug_dev(psc-sc_dev, %s: Continued
205 Capabilities 0x%02x 0x%02x 0x%02x.\n,
__func_ _,
206 resp[0], resp[1], resp[2]);
207 switch (clickpad_type) {
208 case 1:
209 sc-flags |=
SYN_FLAG_HAS_ONE_BUTTON_CLICKP AD;
210 break;
211 case 2:
212 sc-flags |=
SYN_FLAG_HAS_TWO_BUTTON_CLICKP AD;
213 break;
214 default:
215 break;
216 }
217 }
218 }
I have to wonder how case 2 can ever be reached, given the
initialisation of clickpad_type. This smells like there is something
incorrect here with clickpad_type.
If I look at what Linux does, in
https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/drivers/input/mouse/synaptics.h?id=refs/tags/v4.0-rc2
https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/drivers/input/mouse/synaptics.c?id=refs/tags/v4.0-rc2
then
/*
* The following describes response for the 0x0c query.
*
* byte masknamemeaning
* ---
* 10x01adjustable thresholdcapacitive button sensitivity
* can be adjusted
* 10x02report max query 0x0d gives max coord reported
* 10x04clearpadsensor is ClearPad product
* 10x08advanced gesturenot particularly meaningful
* 10x10clickpad bit 0 1-button ClickPad
* 10x60multifinger modeidentifies firmware finger counting
* (not reporting!) algorithm.
* Not particularly meaningful
* 10x80covered pad W clipped to 14, 15 == pad mostly
covered
* 20x01clickpad bit 1 2-button ClickPad
* 20x02deluxe LED controls touchpad support LED commands
* ala multimedia control bar
* 20x04reduced filtering firmware does less filtering on
* position data, driver should watch
* for noise.
* 20x08image sensorimage sensor tracks 5 fingers, but only
* reports 2.
* 20x01uniform clickpadwhole clickpad moves instead of being
* hinged at the top.
* 20x20report min query 0x0f gives min coord reported
*/
#define SYN_CAP_CLICKPAD(ex0c) ((ex0c) 0x10) /* 1-button
ClickPad */
#define SYN_CAP_CLICKPAD2BTN(ex0c) ((ex0c) 0x000100) /* 2-button
ClickPad */
and
if (SYN_EXT_CAP_REQUESTS(priv-capabilities) = 4) {
if (synaptics_send_cmd(psmouse, SYN_QUE_EXT_CAPAB_0C, cap)) {
psmouse_warn(psmouse,
device claims to have extended capability 0x0c, but I'm
not able to read it.\n);
} else {
priv-ext_cap_0c = (cap[0] 16) | (cap[1] 8) | cap[2];
}
}
I tried this patch:
Index: synaptics.c
Re: Synaptics touchpad misdetected as clickpad [with patch]
On Wed 04 Mar 2015 at 22:16:28 +, Christos Zoulas wrote:
Sure why don't you send a full patch that also has the above comment
reproduced...
Here it is. I adjusted the comment to zero-based.
I also gave it a quick test and worked the same as the previous patch.
Index: synaptics.c
===
RCS file: /cvsroot/src/sys/dev/pckbport/synaptics.c,v
retrieving revision 1.32
diff -u -r1.32 synaptics.c
--- synaptics.c 23 May 2014 01:11:29 - 1.32
+++ synaptics.c 4 Mar 2015 22:42:41 -
@@ -197,18 +197,46 @@
cmd[0] = PMS_SEND_DEV_STATUS;
res |= pckbport_poll_cmd(psc-sc_kbctag,
psc-sc_kbcslot, cmd, 1, 3, resp, 0);
+/*
+ * The following describes response for the
+ * SYNAPTICS_CONTINUED_CAPABILITIES query.
+ *
+ * bytemasknamemeaning
+ * ---
+ * 0 0x01adjustable thresholdcapacitive button sensitivity
+ * can be adjusted
+ * 0 0x02report max query 0x0d gives max coord reported
+ * 0 0x04clearpadsensor is ClearPad product
+ * 0 0x08advanced gesturenot particularly meaningful
+ * 0 0x10clickpad bit 0 1-button ClickPad
+ * 0 0x60multifinger modeidentifies firmware finger counting
+ * (not reporting!) algorithm.
+ * Not particularly meaningful
+ * 0 0x80covered pad W clipped to 14, 15 == pad mostly
covered
+ * 1 0x01clickpad bit 1 2-button ClickPad
+ * 1 0x02deluxe LED controls touchpad support LED commands
+ * ala multimedia control bar
+ * 1 0x04reduced filtering firmware does less filtering on
+ * position data, driver should watch
+ * for noise.
+ * 1 0x08image sensorimage sensor tracks 5 fingers, but only
+ * reports 2.
+ * 1 0x01uniform clickpadwhole clickpad moves instead of being
+ * hinged at the top.
+ * 1 0x20report min query 0x0f gives min coord reported
+ */
if (res == 0) {
- u_char clickpad_type = (resp[1] 0x1);
- clickpad_type |= ((resp[0] 4) 0x1);
+ u_char clickpad_type = (resp[0] 0x10);
+ clickpad_type |= (resp[1] 0x01);
aprint_debug_dev(psc-sc_dev, %s: Continued
Capabilities 0x%02x 0x%02x 0x%02x.\n, __func__,
resp[0], resp[1], resp[2]);
switch (clickpad_type) {
- case 1:
+ case 0x10:
sc-flags |= SYN_FLAG_HAS_ONE_BUTTON_CLICKPAD;
break;
- case 2:
+ case 0x01:
sc-flags |= SYN_FLAG_HAS_TWO_BUTTON_CLICKPAD;
break;
default:
christos
-Olaf.
--
___ Olaf 'Rhialto' Seibert -- The Doctor: No, 'eureka' is Greek for
\X/ rhialto/at/xs4all.nl-- 'this bath is too hot.'
pgp6uCYs32UG2.pgp
Description: PGP signature
Re: Read-only file system for usb stick partition?
On Tue 03 Mar 2015 at 07:35:31 +, Michael van Elst wrote: rhia...@falu.nl (Rhialto) writes: The NetBSD disk starts at sector 63, so that's where the disklabel is placed and you are not allowed to write over the disklabel. Oh, of course, yes.. Thanks! -Olaf. -- ___ Olaf 'Rhialto' Seibert -- The Doctor: No, 'eureka' is Greek for \X/ rhialto/at/xs4all.nl-- 'this bath is too hot.' pgplwT014nTM4.pgp Description: PGP signature
Synaptics touchpad misdetected as clickpad
I just tried a self-built fresh -current on my laptop to see how the graphics support is coming along. X works fine, so far, with the programs that come included in the live image, but I noticed that the left of the 2 buttons of my touchpad doesn't work any more. pms0 at pckbc1 (aux slot) pms0: Synaptics touchpad version 6.5 pms0: Palm detect, One button click pad pckbc1: using irq 12 for aux slot wsmouse0 at pms0 mux 0 It used to be detected as pms0 at pckbc1 (aux slot) pms0: Synaptics touchpad version 6.5 pms0: Palm detect pckbc1: using irq 12 for aux slot wsmouse0 at pms0 mux 0 and no click pad. Which is isn't. It has 2 separate buttons below the touchpad. Attaching an usb mouse serves as a workaround. Any other info I can give? -Olaf. -- ___ Olaf 'Rhialto' Seibert -- The Doctor: No, 'eureka' is Greek for \X/ rhialto/at/xs4all.nl-- 'this bath is too hot.' pgpKD8VsFFg30.pgp Description: PGP signature
Re: usermode
On Fri 06 Feb 2015 at 13:15:56 +, Patrick Welche wrote: On Fri, Feb 06, 2015 at 07:12:59AM -0400, Jared McNeill wrote: You need to build and load the syscallemu module from sys/arch/usermode/modules/syscallemu Much better: Starting program: /usr/src/sys/arch/amd64/compile/GENERIC_USERMODE/netbsd.gdb NetBSD/usermode startup Copyright (c) 1996, 1997, 1998, 1999, 2000, 2001, 2002, 2003, 2004, 2005, ... I notice that netbsd -h gives nice help, but leaves the tty in a no-echo state. One needs to do stty sane. -Olaf. -- ___ Olaf 'Rhialto' Seibert -- The Doctor: No, 'eureka' is Greek for \X/ rhialto/at/xs4all.nl-- 'this bath is too hot.' pgplC8ZWwZPdu.pgp Description: PGP signature
Re: blacklistd is now available for current (comments?)
On Wed 21 Jan 2015 at 08:11:59 -0500, Christos Zoulas wrote: As you can see from the patch, the daemon modification is trivial. Yes, I am planning to add this to more daemons (I think I will do named next because it is really spammy on my machines), and yes if there is a way to do this via PAM that would be even better. Maybe what the pam_af package is doing can be used? It can even run a program when blocking a host. christos -Olaf. -- ___ Olaf 'Rhialto' Seibert -- The Doctor: No, 'eureka' is Greek for \X/ rhialto/at/xs4all.nl-- 'this bath is too hot.' pgp5y7eOB4_yU.pgp Description: PGP signature
Re: base.tgz no longer contains './bin/[' (in HEAD and netbsd-7)
On Sat 25 Oct 2014 at 06:30:24 -0400, William D. Jones wrote: Oops, I should've just tested this- it appears that [ is a built-in on my current machines. I misunderstood and thought that the [ command wasn't included at all in the source tree due to a recent commit error (implying that all shell scripts that depended on it would break). Apologies. Nevertheless it should be there. echo is also a built-in in most shells, yet there is also a /bin/echo. The original sh had no builtins at all, I think, and different shells have different selections of built-ins. -Olaf. -- ___ Olaf 'Rhialto' Seibert -- The Doctor: No, 'eureka' is Greek for \X/ rhialto/at/xs4all.nl-- 'this bath is too hot.' pgpDrkMs3GCyV.pgp Description: PGP signature
Re: Some drmkms success on my laptop
On Sat 13 Sep 2014 at 02:35:11 +0200, Rhialto wrote:
pms0 at pckbc1 (aux slot)
pms0: Synaptics touchpad version 6.5
pms0: Palm detect, One button click pad
pckbc1: using irq 12 for aux slot
wsmouse0 at pms0 mux 0
One button click pad - I guess that explains why X only recognizes a
single button. The kernel mis-recognizes it. This is a regression, since
in the 6.x kernels it still works fine.
It is also nothing to do with DRMKMS, it also happens in the GENERIC
kernel. X uses the VESA driver there (which is sub-optimal since it uses
a resolution of 1024 x 768 instead of 1600 x 900).
The assertion failure I mentioned is in this fragment of code, for
reference, line 2833 of src/sys/external/bsd/drm2/dist/drm/i915/i915_gem.c:
2826 static void
2827 i915_gem_object_move_to_inactive(struct drm_i915_gem_object *obj)
2828 {
2829 struct drm_i915_private *dev_priv = obj-base.dev-dev_private;
2830 struct i915_address_space *vm;
2831 struct i915_vma *vma;
2832
2833 -- BUG_ON(obj-base.write_domain ~I915_GEM_GPU_DOMAINS);
2834 BUG_ON(!obj-active);
2835
2836 list_for_each_entry(vm, dev_priv-vm_list, global_link) {
2837 vma = i915_gem_obj_to_vma(obj, vm);
2838 if (vma !list_empty(vma-mm_list))
2839 list_move_tail(vma-mm_list, vm-inactive_list);
2840 }
-Olaf.
--
___ Olaf 'Rhialto' Seibert -- The Doctor: No, 'eureka' is Greek for
\X/ rhialto/at/xs4all.nl-- 'this bath is too hot.'
pgpp_W7q6lZf0.pgp
Description: PGP signature
