Re: Call for tests: DRM fixes for upcoming NetBSD 10.1
On Sat, Oct 05, 2024 at 02:38:30PM +0900, Rin Okuyama wrote: > > We expect that some DRM-related problems for 10.0 have been fixed. > On the other hand, we concern potential regressions caused by the > pullup. It would really be appreciated if you can test 10.0_STABLE > during **this weekend**. If it doesn't work well (compared with > 10.0 or -current), something goes wrong. > No regressions with i915 after extensive use this weekend. Don't have radeon and nouveau at the moment.
Re: Does anyone use checknr(1)?
On Fri, May 24, 2024 at 10:00:47PM +0200, Roland Illig wrote: > Does anyone use this tool? Is it worth keeping? I'm quite surprised to learn that we have a man page linter that isn't mandoc(1). I think we all use that instead?
Re: amdgpu laptops with 10 & current?
On Tue, May 14, 2024 at 02:34:47PM +0100, Patrick Welche wrote: > On Tue, May 14, 2024 at 07:14:35AM +0000, nia wrote: > > WiFi may be Intel AX200/AX201/AX210/AX211 but it might depend. > > We don't have a driver for this. Previous models had iwm(4) which > > is a slow and buggy driver making a USB urtwn(4) the more compelling > > option, or urndis(4) with a tether to a smartphone. > > Another dmesg shows Intel Wireless AC 8265, which is iwm(4). > > Which reminds me: whatever happened to the new wifi project? Last few commits: 3 weeks ago Phil Nelson State save. Work to get msi-x interrupts working. Still not working. 2 months ago Martin Husemann Fix merge botch 2 months ago Martin Husemann Fix merge errors 6 months ago Phil Nelson State save, interrupt support added to iwlwifi, not working yet. So, still ongoing, just slowly
amdgpu laptops with 10 & current?
The ThinkPad A485 looks pretty interesting for use with NetBSD. - 1st Gen AMD Ryzen Mobile - 32 GiB DDR4 2400 MHz - AMD Radeon Vega 6, 8 or 10 Usually I prefer the smaller X series, but they've made them non-upgradable and harder to repair... ethernet is re0, this is different from the intel models that are usually wm0. internal dev chatter would point to wm(4) being the better driver, but probably not enough to matter for my purposes (100mbit/s DSL). I usually use ethernet at home. WiFi may be Intel AX200/AX201/AX210/AX211 but it might depend. We don't have a driver for this. Previous models had iwm(4) which is a slow and buggy driver making a USB urtwn(4) the more compelling option, or urndis(4) with a tether to a smartphone. Another dmesg shows Intel Wireless AC 8265, which is iwm(4). Lenovo laptops have control freak firmware that doesn't allow changing the card for a different model, but I wonder if it can be removed to reduce power consumption and allow suspend to function. Anyone using amdgpu with a device like this? I'm sure llvmpipe is okay(tm), would be nice to have the runtime configuration advantages of modesetting though.
Re: new "compat" sets have really made sets harder to manage.
I've thought about this a bit more and I want to write a separate script for generating the compat set lists, the current one is a little confusing (it tries to do a lot of things) and isn't really suited to generating a list based on another list. I'll work on this when I have time.
Re: new "compat" sets have really made sets harder to manage.
On Sun, Apr 14, 2024 at 07:41:04AM +1000, matthew green wrote: > ie, there are just *two* entries for this file (the real file, and > the debug file), and the rest is all derived from the "comaptfile" > and "debug" tags. the new ones has 30 copies, spread across a > number of files, all that will need editing as future GCCs appear. > > this is compounded across dozens of other files so there are now > hundreds or perhaps thousands of unnecessary duplicated lines, in > a couple of dozen of files. > > can someone please fix this? (nia is out for now, so maybe some > other enterprising person can help :) I've had some time to think about this and I'm a little bit torn. The "old way" was to have every compat shared library tied to a "host" shared library. This means that if the host platform (e.g. sparc64) is built with support for dtrace and zfs, you get dtrace and zfs 32-bit sparc shared libraries too. I think we need a bit more granularity than that. Maybe the answer is somewhere in-between, a shell script for managing shared libraries in the set lists...
Re: Failure building -current amd64
On Wed, Apr 10, 2024 at 11:44:04AM +0100, Chavdar Ivanov wrote: > Any ideas? A stale location in one of the flists? I was working on reworking the set lists on my private tree, then christos committed some new files and I had to do the awkward job of merging the changes. My bad... The missing directory was not added.
Re: modesetting vs intel in 10.0
On Thu, Aug 31, 2023 at 09:17:35PM +0100, Mike Pumford wrote: > On 30/08/2023 09:56, nia wrote: > > > I think detecting the year of manufacture is too much of a hard > > problem - there are simply too many new cards and I have no idea > > about a "cutoff point" where modesetting starts being OK (if it > > even isn't okay for any old cards at all - it should work as long > > as DRM/KMS works AFAIK) > > > Well speaking as someone whose older card worked fine under 9 and now just > ends up as a black screen with both the intel driver and the modesetting one > on 10.0. I'm more interesting in getting back to having a working > accelerated X setup. I did see the tearing on the intel driver on 9.x but it > was never bad enough to make me try the modesetting driver. > > For reference my now broken hardware is: > [ 1.008474] pci1: i/o space, memory space enabled, rd/line, wr/inv ok > [ 1.008474] i915drmkms0 at pci0 dev 2 function 0: Intel Haswell > Integrated Graphics Device (rev. 0x06) > > See kern/57268 for how my hardware fails. > > Mike OK, but this is not the question
Re: modesetting vs intel in 10.0
On Tue, Jul 11, 2023 at 09:58:51AM +1000, matthew green wrote: > > But maybe modesetting is mature enough (and intel bad enough) > > to warrant being the default for Intel GPUs. > > i'm not familiar with the various intel chipsets, i've only had > a couple of them over the years and besides porting the kabylake > bits into the older drm version, i've not really touched it much. > > but, you can adjust the list of drivers used by default here in > the xorg-server sources: > >hw/xfree86/common/xf86pciBus.c:xf86VideoPtrToDriverList() > > where it has a "default:" case for intel of "intel", and if you > can properly figure out how to change this to "modesetting" for > the newer ones (only?) that would be fine by me. > > (one way to handle this without having to patch this code would > be to install the intel driver as some other name, and then make > a copy of the "ati" front end called "intel" that loads either > the real intel driver or modesetting, depending.) It does allow having multiple defaults! This is the case, for example, for nvidia cards, which try nouveau first then fall back to to nv. I think detecting the year of manufacture is too much of a hard problem - there are simply too many new cards and I have no idea about a "cutoff point" where modesetting starts being OK (if it even isn't okay for any old cards at all - it should work as long as DRM/KMS works AFAIK)
Re: modesetting vs intel in 10.0
On Sat, Aug 26, 2023 at 06:47:01AM -0400, Greg Troxel wrote: > I am new to modern intel graphics. I have a UHD 630 with a 9th > generation (coffee lake?) CPU. It is using intel, and it works for > xterm :-) But I see artifacts while typing into github comment boxes. > Is this something I should try modesetting on? > > Is there a wiki page that collects "this option works or doesn't work, > and is or isn't preferred" with various graphics, along with > instructions for choosing? I know I could figure this out but it would > probably speed testing to have someone who already knows write it down > and post a link. Yes, the artifacts are a symptom. In general the intel driver has been discontinued since 2015 or so. In /etc/xorg.conf, try: Section "Device" Identifier "Card0" Driver "modesetting" EndSection (This is okay for the whole file if it doesn't exist already.)
Re: modesetting vs intel in 10.0
On Fri, Aug 25, 2023 at 08:55:13PM +0100, David Brownlee wrote: > Picking up on this, particularly with netbsd-10 looming, I think we > should at least whitelist some known good-with-modesetting Intel GPUs, > with a plan to swapping over to whitelisting keep-on-intel Intel over > time. I've pretty much only got haswell or newer, all of which are better with modesetting. Maybe you have some older GPUs which need intel?
Re: modesetting vs intel in 10.0
On Fri, Jul 07, 2023 at 08:18:18PM +0100, David Brownlee wrote: > On Fri, 7 Jul 2023 at 19:43, nia wrote: > > > > After some testing on a Skylake machine, I've concluded > > that xf86-video-modesetting is far superior to xf86-video-intel > > on that generation of Intel hardware - the most obvious thing > > is that modesetting has functional VSync and superior 3D performance > > with less tearing. > > > > Only problem is that we default to intel, modesetting you need > > to choose explicitly through xorg.conf. > > > > I also found similar problems in "radeon", but found that > > modesetting would somehow pick a display mode that the monitor > > didn't support. Maybe this is actually a drmkms bug - I'm not > > sure. > > > > But maybe modesetting is mature enough (and intel bad enough) > > to warrant being the default for Intel GPUs. > > Could we start with some form of whitelist to pick modesetting over intel? > > David Maybe GPUs released after intel became abandonware in 2014 or so...
modesetting vs intel in 10.0
After some testing on a Skylake machine, I've concluded that xf86-video-modesetting is far superior to xf86-video-intel on that generation of Intel hardware - the most obvious thing is that modesetting has functional VSync and superior 3D performance with less tearing. Only problem is that we default to intel, modesetting you need to choose explicitly through xorg.conf. I also found similar problems in "radeon", but found that modesetting would somehow pick a display mode that the monitor didn't support. Maybe this is actually a drmkms bug - I'm not sure. But maybe modesetting is mature enough (and intel bad enough) to warrant being the default for Intel GPUs.
Re: 5G wifi connection
On Fri, May 26, 2023 at 01:36:07PM +, Bruno Melo wrote: > Is there any USB driver with support to 5G connections? > > Thanks. - urndis(4), of course, is a performant option. - run(4) and rum(4) support 802.11a. The devices are older and larger than urtwn(4). Not all runs/rums have 11a. You can try trawling fleabay and see if you have any luck. - There are some USB bwfm(4) and athn(4) devices. I do not know if all USB athn(4)s support 11a.
Re: 10_BETA: Nice QOL improvements to the installer
On Thu, Dec 22, 2022 at 08:05:02AM +0530, Mayuresh wrote: > On Thu, Dec 22, 2022 at 06:18:41AM +1300, Lloyd Parkes wrote: > > I used the second (non-BIOS) image because I guessed it might be a hybrid > > installer. I think that my old NUCs only support BIOS booting from USB > > sticks, but I could easily be wrong. > > Ok. So, it appears the -bios image has become redundant now. Or hasn't it? > > If yes, they may want to stop building it to preempt such confusion. The BIOS-only image exists because of broken firmware.
Re: Branching for netbsd-10 next week
On Thu, Dec 15, 2022 at 07:59:35PM +, Thomas Mueller wrote: > How will I be able to access (read-only OK) FFS2ea from NetBSD 9.99.82, and > what about compatibility with FreeBSD regarding file system? I assume no > compatibility with Linux. > There will be no compatibility with either, older NetBSD releases won't recognize the superblock AFAIK. > Will I have to worry about the entropy problem when building or updating > packages from 9.99.82 to 10.99.1, or, less likely, 10.0_BETA? Has that been > fixed? There aren't any changes since 99.82 to the way entropy(7) accounting works because the opinions in the community are too strong.
Re: npf table loads slow??
There is a PR for bad behavior of NPF with large tables: http://gnats.netbsd.org/55892
Re: uwsgi rc.d
On Fri, Nov 25, 2022 at 10:30:53AM +0100, Sagar Acharya wrote: > run_rc_command --ini /abs/path/to/conf.ini This looks strange? It is usually run_rc_command "$1"
Re: ghc and current aarch64
On Sat, Nov 19, 2022 at 04:07:38PM +, adr wrote: > Right now the bootstrap compiler is built in netbsd-8, so it depends > on emulators/compat80, which isn't available to aarch64. So in > current (and I suppose 9 too) you'll end up with: > > /usr/pkgsrc/lang/ghc92/work/.tools/lib/ghc-9.2.1/bin/ghc-pkg: Shared object > "libcurses.so.8" not found > > Has someone crosscompiled a bootstrap compiler for haskell in current > or netbsd-9? > > Regards, > adr. If you install emulators/compat90 you will get libcurses.so.8. The aarch64 bootstrap will be built for netbsd-9. aarch64 netbsd-8 doesn't make sense because that never existed.
Re: Using the audio(4) driver for recording under -current?
On Wed, Oct 26, 2022 at 03:39:44PM -0700, Brian Buhrow wrote: > hello. Just to clarify, I'm not trying to use two audio devices for > recording at the same > time. What I was doing was something like: > > #set up the audio device first > audioctl -d /dev/sound2 -w record.rate=44100 record.channels=2 > record.precision=16 \ > record.encoding=slinear_le > > #Now, the mixer device > mixerctl -d /dev/mixer2 -w inputs.line=240,240 record.source=mic > inputs.mic.mute=off \ > record.volume=240,240 > > Then, to record: > cat /dev/sound2 > rawrecordingfile There are some quirks of /dev/sound that might cause problems, for example it has "sticky" pause state. I'd recommend using audiorecord(1) with /dev/audio instead just to get more consistent results. The man page has a nice predictable example to record CD quality audio: $ audiorecord -c 2 -e slinear_le -P 16 -s 44100 recording.wav It would also be interesting to see your full mixerctl -a output, there are many sound card dependent variables that could affect recording.
Re: effective use of blkdiscard(8)?
On Sat, Jun 25, 2022 at 05:22:02PM +1000, matthew green wrote: > > However, what about less obvious cases? > > > > A large file could be created, for example, with dd: > > > > # dd if=/dev/zero of=./testfile bs=4m count=1 > > > > Then discarded: > > > > # blkdiscard -v ./testfile > > > > Would this effectively mark 40GB of this drive unused to its controller? > > that's my understanding, given that the questions you ask below > are handled to be "yes". it certainly does seem to be the case > in my testing -- sometimes reading this data would return the > same data, sometimes random data (!? where from?), and most of > the time, zeroes -- so it certainly was triggering the storage. > > an additional thing we could/should add is "fstrim", which is > designed to be run eg, weekly, and the idea is to tell the disk > to discard all the unallocated sectors on the disk, which would > give you the above feature without having to do anything, and > infact give it to you for all the unused space. i have not > looked at how linux implements this, but it clearly needs the > file system itself to implement the backend. This is great :) > > How good are we at propgating TRIM commands through various block device > > layers? > > > > Is fdiscard() effective on a file on FFSv2 on a cgd(4) on a dk(4) wedge? > > > > What about ZFS on a dk(4) on a cgd(4) on a dk(4) wedge? > > all of this depends upon what their driver 'd_discard' > method does. the only ones that are not assigned to be > "nodiscard" are: > > /home/src/current/src/sys/dev/ld.c:95: .d_discard = lddiscard, > /home/src/current/src/sys/dev/ld.c:110: .d_discard = lddiscard, > /home/src/current/src/sys/dev/ld.c:123: .d_discard = ld_discard > /home/src/current/src/sys/dev/ata/wd.c:154: .d_discard = wddiscard, > /home/src/current/src/sys/dev/ata/wd.c:171: .d_discard = wddiscard, > /home/src/current/src/sys/dev/ata/wd.c:230: .d_discard = wd_discard > /home/src/current/src/sys/dev/dkwedge/dk.c:125: .d_discard = dkdiscard, > /home/src/current/src/sys/dev/dkwedge/dk.c:140: .d_discard = dkdiscard, > > so the vast majority of disk drivers do not support > this yet. If I'm reading the code right, dk(4) knows how to pass discard requests to the underlying device. But we still need to teach cgd this, I guess.
effective use of blkdiscard(8)?
blkdiscard(8) seems like a command in -current that's useful for regular maintenance of SSDs. I would assume that a regular run of: blkdiscard -v /dev/rwd0d would be useful to TRIM an entire SSD, obviously destructively, so would be useful when reinstalling NetBSD. However, what about less obvious cases? A large file could be created, for example, with dd: # dd if=/dev/zero of=./testfile bs=4m count=1 Then discarded: # blkdiscard -v ./testfile Would this effectively mark 40GB of this drive unused to its controller? How good are we at propgating TRIM commands through various block device layers? Is fdiscard() effective on a file on FFSv2 on a cgd(4) on a dk(4) wedge? What about ZFS on a dk(4) on a cgd(4) on a dk(4) wedge?
Re: CVS commit: src
On Wed, May 25, 2022 at 09:50:29PM +0700, Robert Elz wrote: > What is in pkgsrc/mbone is mostky tge ancient mbone tools > (I don't recognise everything) and the name fits for that. > We have nothing mbone in base that I know if, nomkmbone > (or whatever) doesn't make a lot of sense (as a name). > > kre > > ps: I build kernels with MROUTING turned on. I will rename the option to MKMROUTING.
Re: CVS commit: src
On Wed, May 25, 2022 at 08:42:20AM -0400, Greg Troxel wrote: > I was really surprisd that we had mbone applications in base; to me, > that would mean things like vic and vat. > > This is not about about MBONE; it's about multicast routing. The mbone > was an overlay network to connect local multicast islands, and operated > in the 90s. Interesting, thanks. > Separately from the mbone, I have used multicast routing support in > NetBSD across connected local networks. > > (Arguably map-mbone is misnamed; it really isn't about the mbone per se > but about whatever multicast network is available. But that's just a > historical note.) Is the name situation same for the category in pkgsrc? > I don't object to a default-on MK knob; having knobs to make base > smaller seems entirely reasonable. > > I would suggest "multicast" as a word rather than mbone, as what this > knob does is remove user-space support for IP multicast routing. > Someone who understands the history would not expect mrouted to vanish > by disabling mbone. All of these applications depends on the "MROUTING" kernel option, it seems, which is mostly default-off, except for a few (tending on the more obscure side) kernel configs. I wonder if anyone knows the history there.
Re: Supported graphics (in HEAD)
On Sat, May 07, 2022 at 06:02:23PM +0700, Robert Elz wrote: > I was kind of hoping (dreaming) that someone might say "If you > really don't care about acceleration" (I don't) "then just disable > x using userconf" (needing to build a custom kernel fine as well) > "and it should just work" (for any one of the 3 possible gpu types). Well if you insist ;) userconf disable i915drmkms [intel] userconf disable nouvea [nvidia] userconf disable radeon [old AMD] userconf disable amdgpu [new AMD] Use gop (UEFI) or vesa (BIOS) bootloader commands to set a framebuffer resolution. Add to /etc/xorg.conf: Section "Device" Identifier "Card0" Driver "wsfb" EndSection Should Just Work!
Re: Branching for NetBSD 10
On Mon, May 02, 2022 at 04:22:56PM +0200, Martin Husemann wrote: > https://gnats.NetBSD.org/56727 Ah, my bug. For the record this was a hdaudio bug that got worse in current. jmcneill fixed it. i915 is now perfect for me in current :)
Re: heads up: changes to synaptics trackpad driver
Hey, I noticed your code introduces a return statement above where mouse button packets are processed. Unfortunately your changes cause some of the physical buttons on my trackpad to no longer work (notably the middle one) so I've had to locally revert it for now.
Re: Disappearing mouse buttons
On Wed, Feb 09, 2022 at 09:16:08AM +0100, Tom Ivar Helbekkmo wrote: > That was, indeed, it! Thank you so much for identifying it for me! :) > > Does this mean that our /dev/wsmouse isn't working properly? Having a > device that exhibits this behaviour, should I be taking a closer look at > sys/dev/wscons/wsmouse.c? Or possibly lower down in the stack, like > sys/dev/usb/ums.c, or even sys/dev/hid/hidms.c, as it reports "5 buttons > and Z dir", where I assume it should be claiming (at least) 8 buttons, > seeing as my problem button is button 8 when it's working...? Nope, too low level. Take a look at how buttons are processed here: xsrc/external/mit/xf86-input-ws/dist/src/ws.c
Re: Disappearing mouse buttons
On Tue, Feb 08, 2022 at 03:06:43PM +0100, Tom Ivar Helbekkmo wrote: > I've been looking at changes in sys/dev/usb, sys/dev/hid, and > sys/dev/wscons, but I can't find anything that looks relevant. > > If anyone has any hints for me, that would be appreciated! > > -tih I think you're looking in the wrong area - the most likely culprit is a change I made to Xorg where the default driver for pointing devices will be "ws" instead of "mouse" (this is primaily useful for touchscreens and touchpads, and mirrors a similar change for OpenBSD). Sorry if it's indeed my fault
Re: HEADS UP: Merging drm update
On Sun, Dec 19, 2021 at 12:48:15PM +, Taylor R Campbell wrote: > > Date: Sun, 19 Dec 2021 01:42:53 + > > From: Taylor R Campbell > > > > > Date: Sat, 18 Dec 2021 17:06:13 + > > > From: Taylor R Campbell > > > > > > I'm planning to merge the drm update this weekend -- a cvs import and > > > merge commit, plus about 1300 commits on top of that from the git > > > repository. > > > > The update is in progress, but my commitbomb script isn't perfect and > > sometimes requires manual intervention, which won't happen while I'm > > asleep. The tree might not build for a few hours in that event. > > Apologies in advance! > > The commitbomb is done -- drm update merged. There may be build > fallout; let me know if so and I'll try to take care of it. thank you Maya and Taylor for this monumental effort!
Re: Useradd in 9.99.92
Fixed, thanks!
Re: Full rebuild required for aarch64
On Thu, Oct 14, 2021 at 11:18:28AM -0700, Michael Cheponis wrote: > ok, I'll byte: What is RELRO and MKPIE, and why does it force a > build-release? > > > On Thu, Oct 14, 2021 at 11:01 AM nia wrote: > > > Hi, > > > > I've enabled RELRO and MKPIE for aarch64 so update builds will not work, > > you will need to do a full release build if you are updating from source. > > > > Thanks for the patience. > > In short, they are features for hardening ELF binaries. The reason they require a full rebuild is that they cannot be enabled selectively without introducing problems and must be applied to the full tree. More in-depth explanations of RELRO: https://www.redhat.com/en/blog/hardening-elf-binaries-using-relocation-read-only-relro and MKPIE: https://en.wikipedia.org/wiki/Position-independent_code
Re: pwhash?
The Argon2 code was originally added and documented in 2019 but was not enabled by default. There were also a few edge cases where it didn't work and the hash format differed from the reference implementation so recently I've been fixing it up. To build with Argon2 support you need MKARGON2=yes in mk.conf. However, since the past day or so this is the default.
Full rebuild required for aarch64
Hi, I've enabled RELRO and MKPIE for aarch64 so update builds will not work, you will need to do a full release build if you are updating from source. Thanks for the patience.
Re: /bin/sh tabcomplete
On Tue, Sep 14, 2021 at 11:04:47AM -0400, Christos Zoulas wrote: > This is a side effect of the change to add file-completion for commands. > Fixed. > > christos Thanks for the quick fix christos - this was driving me mad, I thought I'd changed something by accident.
Re: null mounts seem to lose directories?
For now I've found a workaround: using a parent directory as the null moint point. Perhaps the bulklog directory gets deleted and re-created or something, but that doesn't explain why it's kept _partially_ in sync.
Re: null mounts seem to lose directories?
On Sun, Aug 22, 2021 at 12:52:10PM +0200, J. Hannken-Illjes wrote: > Using the attached script I see no problems. What are you > doing between the "mount -t tmpfs", "mount -t null" and this "ls"? A full bulk build of pkgsrc, unfortunately
Re: null mounts seem to lose directories?
Also, several older null mounts that appear in df but no longer exist seem un-unmountable: # umount -a -t null umount: /sandbox/nb9-i386-trunk/chroot/16/data: Invalid argument umount: /sandbox/nb9-i386-trunk/chroot/15/data: No such file or directory umount: /sandbox/nb9-i386-trunk/chroot/14/data: No such file or directory umount: /sandbox/nb9-i386-trunk/chroot/13/data: No such file or directory umount: /sandbox/nb9-i386-trunk/chroot/12/data: No such file or directory umount: /sandbox/nb9-i386-trunk/chroot/11/data: No such file or directory umount: /sandbox/nb9-i386-trunk/chroot/10/data: No such file or directory umount: /sandbox/nb9-i386-trunk/chroot/9/data: No such file or directory umount: /sandbox/nb9-i386-trunk/chroot/8/data: No such file or directory umount: /sandbox/nb9-i386-trunk/chroot/7/data: No such file or directory umount: /sandbox/nb9-i386-trunk/chroot/6/data: No such file or directory umount: /sandbox/nb9-i386-trunk/chroot/5/data: No such file or directory umount: /sandbox/nb9-i386-trunk/chroot/4/data: No such file or directory umount: /sandbox/nb9-i386-trunk/chroot/3/data: No such file or directory umount: /sandbox/nb9-i386-trunk/chroot/2/data: No such file or directory umount: /sandbox/nb9-i386-trunk/chroot/1/data: Invalid argument (The output is the same with -f).
null mounts seem to lose directories?
I have various null mounts on top of a tmpfs: $ df -h ... tmpfs 87G 1.0G86G 1% /sandbox/nb9-i386-trunk/chroot/1 /sandbox/nb9-i386-trunk/data/bulklog 237G79G 158G 33% /sandbox/nb9-i386-trunk/chroot/1/data/bulklog ... Directories are not being synchronized properly across the null mount: procyon$ ls /sandbox/nb9-i386-trunk/chroot/1/data/bulklog/rust-1.52.1nb4/ build.log checksum.log configure.log depends.log pre-clean.log work.log procyon$ ls /sandbox/nb9-i386-trunk/data/bulklog/rust-1.52.1nb4/ ls: /sandbox/nb9-i386-trunk/data/bulklog/rust-1.52.1nb4/: No such file or directory The source of the null mount is a ZFS dataset: # zfs list ... tank/sandbox/nb9-i386-trunk/data 124G 158G 79.2G /sandbox/nb9-i386-trunk/data ...
Re: RealTek wifi on -current amd64 on lenovo laptop
On Tue, May 11, 2021 at 09:37:30AM +0530, Mayuresh wrote: > product: RTL8821CE 802.11ac PCIe Wireless Network Adapter > > Is there any chance to get it to work in -current? There's no driver for Realtek 802.11ac PCIe hardware. You could try porting a driver from another OS.
Re: vether vs. tap, initialization order, etc
On Sat, Apr 24, 2021 at 07:57:30AM -0700, Jason Thorpe wrote: > > > On Apr 24, 2021, at 5:42 AM, nia wrote: > > > > I wonder if there's an initialization order difference > > somewhere. > > If you want to have control over the initialization order, you need to set > auto_ifconfig=NO. On one of my systems that has a bunch of Qemu VMs: > > auto_ifconfig=NO > net_interfaces="tap0 tap1 tap2 tap3 tap4 tap5 tap6 tap7 tap8 tap9 tap10 tap11 > bridge0” > > …otherwise I was having the problem of bridge0 being brought up before the > tap devices were created. > > -- thorpej > Thank you! This works great, I'll make note of it in the NetBSD Guide's section on networking.
vether vs. tap, initialization order, etc
I just updated our home router from 9.1 to -current because a roommate wanted to use wg(4). I use tap as a bridge endpoint for two NICs that are used for the LAN. I thought I'd be able to copy the configs and do a straightforward subtitution from tap to vether but this doesn't work. /etc/rc.d/network fails to "up" the bridge on boot. The bridge was previously initialized in /etc/ifconfig.tap0, like so, now /etc/ifconfig.vether0: create inet 10.0.1.1 netmask 255.255.255.0 !brconfig bridge0 add $int add re1 add re2 up I wonder if there's an initialization order difference somewhere.
Re: regarding the changes to kernel entropy gathering
On Mon, Apr 05, 2021 at 01:22:49PM -0700, Greg A. Woods wrote: > I don't see how. I don't see any evidence for that happening. > > So, show me how entropy is being collected in my system: > > 16:18 [1.793] # uptime > 4:19PM up 22 days, 16:04, 2 users, load averages: 0.00, 0.00, 0.00 > 16:19 [1.794] # sysctl kern.entropy > kern.entropy.collection = 1 > kern.entropy.depletion = 0 > kern.entropy.consolidate = -23552 > kern.entropy.gather = -23552 > kern.entropy.needed = 256 > kern.entropy.pending = 0 > kern.entropy.epoch = 24 > 16:19 [1.795] # rndctl -l > Source Bits Type Flags > ipmi0-Temp0 env estimate, collect, v, t, dv, dt You should update your rndctl to get my recent changes: $ priv rndctl -l Source Estimated bitsSamples Type Flags cgd0 04458546 disk collect, v, t /dev/random 0 0 ???collect, v ld0 0118 disk collect, v, t wd0 06160391 disk collect, v, t acpibat1-discha 0 5908 power collect, v, t acpibat1-charge 0 4212 power collect, v, t acpibat0-discha 0 1140 power collect, v, t acpibat0-charge 0 1698 power collect, v, t [...] seed256 2 ???estimate, collect, v rdrand/rdseed 512 1 rngestimate, collect, v
Re: regarding the changes to kernel entropy gathering
On Mon, Apr 05, 2021 at 12:51:44AM +0200, Joerg Sonnenberger wrote: > On Sun, Apr 04, 2021 at 02:16:41PM -0700, Paul Goyette wrote: > > Perhaps sysinst(8) should ask > > > > Do you need a hyper-secure system? > > > > If yes, then leave things as they are today. But if you answer no, > > we should automatically copy enough pseudo-entropy bits to /dev/rnd > > to prevent future blocking. > > For most architectures, sysinst does do exactly that. It assumes that > you don't just reset or reboot, but properly shutdown the system. > > Joerg Are you sure? AFAIK the estimation is saved inside the entropy file that gets written on shutdown, and loaded on next boot. If the estimation was zero, it stays zero, and you get blocking. Martin had a patch that added a menu to sysinst providing various options if estimation == 0, but IIRC it was disabled pending further discussion.
Re: regarding the changes to kernel entropy gathering
I have updated the rndctl(8) documentation so it reflects the current model in the kernel and is no longer misleading. It could still use some extra work (e.g. -l could print number of samples collected). On Sat, Apr 03, 2021 at 10:03:21PM +0200, Steffen Nurpmeso wrote: > Btw i track > > https://github.com/smuellerDD/jitterentropy-library.git > > for about two years, and i "never" (which is a couple of years at > least) understood why something like this isn't simply used. The kernel already mixes in hardclock jitter, among other things, to the entropy pool, but it doesn't increase the entropy estimate. Nothing does except hardware RNGs and direct entropy fed from the host machine, and there have been strong objections to re-introducing any kind of estimator that is based purely on runtime statistical gathering rather than models of hardware. "Potential entropy gathering schemes" have been discussed to death. Please stay on-topic.
Re: How to determine if graphics is supported by radeondrm?
as previously mentioned, the "radeon" DRM/KMS driver supports only older AMD GPUs - mostly everything of the TeraScale family. we do not yet have a working port of the "amdgpu" driver for newer stuff in 9.x or -current. until last year, I was happily using a Radeon HD 6570. this is a GPU introduced in 2011 with TeraScale 2 and DisplayPort, available in low-profile forms. I had trouble finding open source software that would not run at 1080p. several NetBSD developers like the Radeon HD 5450 because it is fanless. > Am I better off looking at iNtel stuff? if you want a newer integrated GPU, yes, in 9.x we support everything up to (including) Kaby Lake, which is hardware that debuted in 2016 and was discontinued for desktop processors in 2020. if you want a better CPU and are happy with an older external GPU, i would not advise getting Intel stuff. newer x86 hardware supports a generic unaccelerated full resolutoin dumb UEFI framebuffer. llvmpipe (the software OpenGL driver) will be chosen when this is in use. llvmpipe is very good on CPUs with lots of cores and threads, it is highly paralell. hope this helps, nia
Re: ACPI display brightness on Lenovo Thinkpad T430s
On Wed, Mar 10, 2021 at 11:23:50AM +0100, Fekete Zoltn wrote: > Hi There, > > Please give me advice how to proceed in the topic below. I want to have the > display brightness working. > > I have traced the route of the brightness buttonpress (up or down) in the > acpi subsystem in the kernel on my laptop. Everything seems to be alright. > The driver takes the button press, translates into an acpi code, then it > calls the acpi driver, which sends the code to the hardware. > The brightness of the display is not changing, however. > > Does anybody know what to do? I think the brightness tweaking bits were broken when DRM was updated for NetBSD 9.0, we have another chance to get it right for the next DRM update. Modifying the hw.acpi.acpiout0.brightness sysctl should not do nothing. Currently, I use sysutils/intel-backlight from pkgsrc. It performs raw access to PCI device nodes, so needs root and kern.securelevel=0 unfortunately.
Re: hg or git tools for building in base?
On Wed, Nov 25, 2020 at 07:34:17AM +, Thomas Mueller wrote: > from tech-lists on freebsd-current emailing list: > > > As subject - what will there be in base to interact with the new git repo? > > I mean, right now, for svn there is svnlite. What for git? > > > Shouldn't it be in base before the move to git? > > Relevance of this message here is that NetBSD users will face a similar > challenge when NetBSD switches from cvs to hg. > > How will NetBSD users be able to update their src, xsrc, and pkgsrc trees? > > FreeBSD, beginning with current, is readying to switch from svn to git. > > Will NetBSD users have to update pkgsrc tree just before the switch, and > hurry up, build and install mercurial so as not to be left in the lurch? > > Also, will current and stable branches, and pkgsrc, all switch to hg at the > same time, or will it be current src and xsrc first? > > Tom > There's no plan to have hg in base. You can download src and pkgsrc tarballs from cdn.netbsd.org already, and update from there.
Re: recent sysinst UX changesg
On Mon, Nov 09, 2020 at 11:03:31AM +, nia wrote:
> On Mon, Nov 09, 2020 at 11:18:31AM +0100, Martin Husemann wrote:
> > On Mon, Nov 09, 2020 at 10:10:56AM +, nia wrote:
> > > fwiw, i think the default options should be as close to Just Work as
> > > possible.
> > >
> > > i have installed NetBSD irl with people who have only a little bit of unix
> > > knowledge, and watched them wince every time something doesn't go as
> > > planned.
> > > often this is on older, spare hardware, that's just to play with the OS
> > > on,
> > > so it is likely to not have >2015 CPU features (RDRAND).
> >
> > I totaly agree with both of this, but "just work" is not a clear target,
> > especially when a simple step makes a difference in security (whether
> > manually typing in random things *does* make a difference is probably
> > for another debate).
> >
> > The description pointing at copying output from another machine is just
> > an option (and it actually helps a lot when you do installs via serial
> > console or similar).
> >
> > So: happy to make it more userfriendly, simpler, rephrase messages,
> > whatever needed - but we should not end up with insecure installs.
> >
> > Martin
>
> Requiring users to type in data is just going to result in a lot of
> users mashing the keyboard to get an install to work, is all I'm saying.
> That's no better than copying 32 bytes back into /dev/urandom to continue
> with the existing seed. The installation involves user input, after all.
>
> Treating USB RNGs as a common use case for everyday installs is an odd
> decision. They're probably common to have among a subset of NetBSD
> developers, and, well, nobody else.
>
> +{This system seems to lack a cryptographically strong pseudo random
> +number generator. There is not enough entropy available to create secure
> +keys (e.g. ssh host keys).
> +
> +You may use random data generated on another computer and load it
> +here, or you could enter random characters manually.
> +
> +If you own a USB random number device, connect it now and select
> +the "Re-test" option.}
>
> I would change this to:
>
> "{This system seems to lack a quality hardware random number generator.
>
> For increased system security, you may load random data generated
> on another computer. NetBSD will then use this as a seed.
>
> Otherwise, the installer can continue with a potentially insecure
> seed using data collected during the installation process.}"
>
> +message entropy_continue {Continue with existing potentially insecure
> seed}
> +message entropy_download_seed{Import random data from another
> machine}
>
> Lacking a HWRNG is the actual problem. Let's describe the actual problem.
> I don't think we need to present every new user installing NetBSD with
> information about USB RNG devices or crypto jargon.
By the way,
My thinkpad t60 has an audio dac. It has inputs. Audio DACs physically produce
random noise.
Since this is sysinst, power consumption concerns about sampling from
the DAC don't apply: Enable all inputs in sysinst, set gain to max, read 32
bytes from /dev/audio, return to normal state.
There's really no reason at all for this hardware to have entropy problems.
Re: recent sysinst UX changes
On Mon, Nov 09, 2020 at 11:18:31AM +0100, Martin Husemann wrote:
> On Mon, Nov 09, 2020 at 10:10:56AM +0000, nia wrote:
> > fwiw, i think the default options should be as close to Just Work as
> > possible.
> >
> > i have installed NetBSD irl with people who have only a little bit of unix
> > knowledge, and watched them wince every time something doesn't go as
> > planned.
> > often this is on older, spare hardware, that's just to play with the OS on,
> > so it is likely to not have >2015 CPU features (RDRAND).
>
> I totaly agree with both of this, but "just work" is not a clear target,
> especially when a simple step makes a difference in security (whether
> manually typing in random things *does* make a difference is probably
> for another debate).
>
> The description pointing at copying output from another machine is just
> an option (and it actually helps a lot when you do installs via serial
> console or similar).
>
> So: happy to make it more userfriendly, simpler, rephrase messages,
> whatever needed - but we should not end up with insecure installs.
>
> Martin
Requiring users to type in data is just going to result in a lot of
users mashing the keyboard to get an install to work, is all I'm saying.
That's no better than copying 32 bytes back into /dev/urandom to continue
with the existing seed. The installation involves user input, after all.
Treating USB RNGs as a common use case for everyday installs is an odd
decision. They're probably common to have among a subset of NetBSD
developers, and, well, nobody else.
+{This system seems to lack a cryptographically strong pseudo random
+number generator. There is not enough entropy available to create secure
+keys (e.g. ssh host keys).
+
+You may use random data generated on another computer and load it
+here, or you could enter random characters manually.
+
+If you own a USB random number device, connect it now and select
+the "Re-test" option.}
I would change this to:
"{This system seems to lack a quality hardware random number generator.
For increased system security, you may load random data generated
on another computer. NetBSD will then use this as a seed.
Otherwise, the installer can continue with a potentially insecure
seed using data collected during the installation process.}"
+message entropy_continue {Continue with existing potentially insecure
seed}
+message entropy_download_seed {Import random data from another machine}
Lacking a HWRNG is the actual problem. Let's describe the actual problem.
I don't think we need to present every new user installing NetBSD with
information about USB RNG devices or crypto jargon.
Re: recent sysinst UX changes
fwiw, i think the default options should be as close to Just Work as possible. i have installed NetBSD irl with people who have only a little bit of unix knowledge, and watched them wince every time something doesn't go as planned. often this is on older, spare hardware, that's just to play with the OS on, so it is likely to not have >2015 CPU features (RDRAND). On Mon, Nov 09, 2020 at 06:51:47AM +0100, Martin Husemann wrote: > On Sun, Nov 08, 2020 at 05:32:16PM +, nia wrote: > > after several changes in 9.1 and -current, it's strange to me that the > > option > > that I expect is the most popular for installing NetBSD (start over, fresh > > partitions, use the whole disk) is no longer the default option: > > It never was and I am not sure it should be. This option actually > is brand new and never was offered before this explicitly. > > I don't have a strong opinion on order of options and defaults though, > at this stage in an installer that offers to destroy all of your disk > you should be thinking twice what you select. thing is, "Want to install NetBSD? This might damage your disk and you should make a backup and think twice..." is already a dialog that appear prior to this one (with the default being no). the default option may be broken for a preexisting Linux/Windows GPT table, and the current wording makes it sound like you should only pick the "delete everything" option if you want to change the partitioning system to a different one (not GPT). it's also not clear, to a new user, what the difference between "use default partition sizes" and "delete everything" is. it's not clear to me :/ > > > while inputting entropy by hand isn't something i would consider > > acceptable to expose to everyday users of a modern operating system > > in the first place, the suggestion that they might use coin tosses > > makes the entire thing feel like a big joke (and in general the dialog > > is overly complicated). > > I am open to concrete suggestions how to improve things here. > Note that most users on real machines never should see this dialog > and that manual input is only one of a few options available. > > I feel the whole thing is a bad pain, but either something like this > or we will end up with insecure/incomplete installations. > > Martin i run into it on real hardware, thinkpad t60. my preference is: - when booting in a VM, if there is no RNG device attached, the system should print a warning with instructions on how to attach the device. - "Continue with possibly insecure RNG state" should be an available option that writes 32 bytes from urandom to random. The act of performing an installation should involve user input that is difficult for an adversary to predict, if not scientifically provably secure... the thinkpad has onboard devices that generate data that might not be provably random, but is near practically unpredictable, including various fan sensors and an audio DAC with inputs (hey, the installer could even set these to max gain...) is a typical new user, such as described above, likely to have another NetBSD machine to serve an entropy file over ftp with? no, they're going to spam on the keyboard. whose security is this helping?
recent sysinst UX changes
after several changes in 9.1 and -current, it's strange to me that the option
that I expect is the most popular for installing NetBSD (start over, fresh
partitions, use the whole disk) is no longer the default option:
> d: Delete everything, use different partitions
it's option 4! that doesn't feel right at all.
the installer in -current now asks users to input entropy by hand:
> {They should contain at last 256 bits of randomness, as in 256 coin
> tosses, 100 throws of a 6-sided die, 64 random hexadecimal digits, or
> (if you are able to copy & paste output from another machine into this
> installer) the output from running the following command on another
> machine whose randomness you trust:}
while inputting entropy by hand isn't something i would consider
acceptable to expose to everyday users of a modern operating system
in the first place, the suggestion that they might use coin tosses
makes the entire thing feel like a big joke (and in general the dialog
is overly complicated).
i really feel like both of these things could be improved.
Re: Automated report: NetBSD-current/i386 build failure
It should be fixed already.
"tsc went backwards" spam on resume
getting this a lot whenever my laptop recovers from suspend. was it intended? should my laptop not be using TSC as the default timecounter?
Re: "wireguard" implementation improperly merged and needs revert
Hi Jason, > We still need to protect the unique identity and reputation of > WireGuard (our "brand"). This ensures that when people see the > WireGuard name or logo, they know it is something we, the > WireGuard developers, have worked on." Personally, I would be in favour of entirely rebranding the NetBSD implementation to avoid this, because it's only introducing ourselves to potential legal problems. It's important that the NetBSD tree remains as free as possible, and that nobody introduce themselves to potential legal pain by modifying any part of it. We have also had a similar discussion with Mozilla's lawyers and simply opted to unbrand all of their software which we distribute. If only certain people can develop implementations of this protocol, this is not an open protocol.
Re: atexit(), dlclose() and more atexit()
On Mon, Jul 06, 2020 at 12:42:55AM +0700, Robert Elz wrote: > Actually, that one is a possible solution. dlclose() is not required > to do anything at all. While having it never do anything isn't what > we'd want, having it do nothing if there is a pending atexit function > from the dynamic object (or even simply one registered by the dynamic > object - though the problematic case, as I understand it, is when the > function has been removed and so can no longer sensibly be called) is > not a ridiculous suggestion. There is precedence for dlclose doing nothing - it's a no-op in musl libc, by design. There are obvious downsides (servers with reloadable modules suddenly have memory leaks) but that's arguably not critical. Their justification can be found here: https://wiki.musl-libc.org/functional-differences-from-glibc.html#Unloading-libraries
Re: blacklist -> blocklist in current
On Sun, Jun 14, 2020 at 10:01:57PM -0400, Christos Zoulas wrote: > > Hello folks, > > I've renamed blacklist to blocklist, so if you are currently using it, > you should rename things accordingly: > > - rc.conf variable > - /var/db/blacklist.db file > - npf table name > > Apologies for the inconvenience, > > christos Cool, thanks.
Re: NetBSD 9 on ThinkPad X220
On Thu, May 28, 2020 at 02:11:08PM +, nia wrote: > On Wed, May 27, 2020 at 07:24:22PM +0300, Jukka Ruohonen wrote: > > On Tue, May 26, 2020 at 07:38:31AM +, nia wrote: > > > Yeah, we really shouldn't be using xf86-video-intel. > > > It's been deprecated in favour of the modesetting driver for years. > > > > The modesetting(4) driver indeed works fine. Maybe there could be a note > > for newcomers and re-comers in x11/xf86-video-intel that this driver has > > been deprecated. > > > > > Which browser? (I'm responsible for the Firefox audio code on NetBSD.) > > > > I tried both Midori and Firefox. Do I need pulseaudio for the latter? As I > > recall, at some point they deprecated everything else at least for Linux. > > > > - Jukka > > Firefox needs no configuration or special options, it uses the native > NetBSD API by default. > > Midori needs audio/gst-plugins1-oss to be installed. ... fwiw in Firefox you can go to about:support, this is the output on my X250: Media Audio Backend sun Max Channels12 Preferred Sample Rate 48000 Output Devices NameGroup Vendor State Preferred Format ChannelsRate Latency Realtek ALC292 01h (default)/dev/audio Realtek Enabled All default: S16LE, support: S16LE 2 default: 48000, support: 1000 - 192000 40 - 7680 Realtek ALC292 01h (0) /dev/audio0 Realtek Enabled Nonedefault: S16LE, support: S16LE 2 default: 48000, support: 1000 - 192000 40 - 7680 Input Devices NameGroup Vendor State Preferred Format ChannelsRate Latency Realtek ALC292 01h (default)/dev/audio Realtek Enabled All default: S16LE, support: S16LE 2 default: 48000, support: 1000 - 192000 40 - 7680 Realtek ALC292 01h (0) /dev/audio0 Realtek Enabled Nonedefault: S16LE, support: S16LE 2 default: 48000, support: 1000 - 192000 40 - 7680 (www/firefox68, the most recent extended support version)
Re: NetBSD 9 on ThinkPad X220
On Wed, May 27, 2020 at 07:24:22PM +0300, Jukka Ruohonen wrote: > On Tue, May 26, 2020 at 07:38:31AM +0000, nia wrote: > > Yeah, we really shouldn't be using xf86-video-intel. > > It's been deprecated in favour of the modesetting driver for years. > > The modesetting(4) driver indeed works fine. Maybe there could be a note > for newcomers and re-comers in x11/xf86-video-intel that this driver has > been deprecated. > > > Which browser? (I'm responsible for the Firefox audio code on NetBSD.) > > I tried both Midori and Firefox. Do I need pulseaudio for the latter? As I > recall, at some point they deprecated everything else at least for Linux. > > - Jukka Firefox needs no configuration or special options, it uses the native NetBSD API by default. Midori needs audio/gst-plugins1-oss to be installed.
Re: NetBSD 9 on ThinkPad X220
On Mon, May 25, 2020 at 09:35:00PM +0300, Jukka Ruohonen wrote: > * X (modular) segfaults from the beginning (GENERIC_ALSR) for intel(4), but > works fine when "UXA" is set for "AccelMethod" in xorg.conf(5). Yeah, we really shouldn't be using xf86-video-intel. It's been deprecated in favour of the modesetting driver for years. > * Even though I didn't investigate much, audio output does not seem to work > with HTML5 stuff like YouTube (even though video plays even surprisingly > smoothly with the gst-plugins1-* stuff from pkgsrc). Which browser? (I'm responsible for the Firefox audio code on NetBSD.)
exciting new iwm panic (assert fail)
This driver is stable in 9. At some point, it became horribly unstable in -current. After thorpej's changes it seeems less unstable, it took several days for this to happen: NetBSD r 9.99.63 NetBSD 9.99.63 (R) #6: Fri May 22 23:06:42 IST 2020 nia@r:/home/nia/src/sys/arch/amd64/compile/obj/R amd64 [several screens of iwm0: autoconfiguration error: unhandled firmware response nonsense] iwm0: autoconfiguration error: unhandled firmware response 0x6266 0x66/0xea27c rx ring 0[14] iwm0: autoconfiguration error: unhandled firmware response 0x64bc 0xbc/0xea54f rx ring 0[14] iwm0: autoconfiguration error: unhandled firmware response 0xc002 0x2/0xf1f2495f rx ring 8[163] iwm0: autoconfiguration error: unhandled firmware response 0x 0xff/0x80 rx ring 127[255] iwm0: autoconfiguration error: unhandled firmware response 0x6005 0x5/0xf2fbe968 rx ring 9[173] iwm0: autoconfiguration error: Some HCMDs skipped?: idx=173 queued=0 cur=45 panic: kernel diagnostic assertion "ring->queued > 0" failed: file "/home/nia/src/sys/dev/pci/if_iwm.c", line 4459 cpu0: Begin traceback... vpanic() at netbsd:vpanic+0x152 __x86_indirect_thunk_rax() at netbsd:__x86_indirect_thunk_rax iwm_softintr() at netbsd:iwm_softintr+0x130a softint_dispatch() at netbsd:softint_dispatch+0x2d0 cpu0: End traceback... fatal breakpoint trap in supervisor mode trap type 1 code 0 rip 0x8021f3d5 cs 0x8 rflags 0x202 cr2 0x7a75ab013002 ilevel 0x6 rsp 0x8280aaa60ef0 curlwp 0xa52c9fe31480 pid 0.3 lowest kstack 0x8280aaa5d2c0
-current panics while iwm(4) is in use
Not reproducable in 9. db> crash> bt _KERNEL_OPT_NARCNET() at 0 _KERNEL_OPT_ACPI_SCANPCI() at _KERNEL_OPT_ACPI_SCANPCI+0x7 sys_reboot() at sys_reboot db_reboot_cmd() at db_reboot_cmd db_command() at db_command+0x13a db_command_loop() at db_command_loop+0xa6 db_trap() at db_trap+0xf9 kdb_trap() at kdb_trap+0xe1 trap() at trap+0x2c9 --- trap (number 1) --- breakpoint() at breakpoint+0x5 vpanic() at vpanic+0x178 kern_assert() at kern_assert+0x48 mi_switch() at mi_switch+0x7dd sleepq_block() at sleepq_block+0x17e iwm_firmware_load_sect() at iwm_firmware_load_sect+0x1c9 iwm_load_cpu_sections_7000() at iwm_load_cpu_sections_7000+0x68 iwm_load_ucode_wait_alive() at iwm_load_ucode_wait_alive+0x648 iwm_init_hw() at iwm_init_hw+0xb3 iwm_init() at iwm_init+0x3e ifmedia_change() at ifmedia_change+0x48 ifmedia_ioctl() at ifmedia_ioctl+0x12c ieee80211_ioctl() at ieee80211_ioctl+0x398 iwm_ioctl() at iwm_ioctl+0x169 doifioctl() at doifioctl+0x990 sys_ioctl() at sys_ioctl+0x59c syscall() at syscall+0x299 --- syscall (number 54) --- 734deef681ba: db> crash> callout ticks wheel arg func crash: _kvm_kvatop(0) crash: kvm_read(0x0, 16592): invalid translation (invalid level 4 PDE)
Re: Not transparent to keyboard, touchpad not working
On Sun, Mar 29, 2020 at 08:41:11AM -0300, Mandacar Cascavel wrote: > Besides all that, the touchpad buttons of my Lenovo Ideapad are not working > anymore. I have added a mouse to the laptop. Looks like I made a mistake. Can you try a fresh -current?
Re: Two finger scrolling
On Wed, Mar 18, 2020 at 12:55:27PM +0900, Ryo ONODERA wrote: > Hi, > > Can I add sysctl node to disable two finger scroll as follows? > > And > https://mail-index.netbsd.org/source-changes/2020/03/14/msg115107.html > is essential for my Synaptics 8.16 TouchPad in HP Sectre x360 13-inch > year 2017 model (ae019TU). > If it is removed, I cannot perform any drag-and-drop with two fingers. > My patch also adds this part if two finger scroll is disabled. We should probably fix the driver or temporarily revert so that gestures still work by default. I'm not sure why gestures are broken for me.
Re: Two finger scrolling
On Wed, Mar 18, 2020 at 12:17:23PM +1030, Brett Lymn wrote: > OK, IIRC whether or not you get the click pad button emulation depends > on how the device reports itself - they are only there for one-button > click pads. pms0: Extended W mode, Passthrough, Up/down buttons, Palm detect, One button click pad, Multi-finger Report, Multi-finger > My main concern here is that you have converted all multi-touch into a > scroll event. I probably did, but I can't test other multitouch events :/ > What W values were you getting when testing the two finger scroll? Do > you have a copy of the "Synaptics PS/2 TouchPad Interfacting Guide, PN: > 511-000275-01 Rev. B"? I haven't located a later document but this one > does describe the various modes and what W means in those modes because, > unfortunately, it is overloaded depending on the mode the device is in. > I can send you a pdf of the document off list if you don't already have > a copy. I recall finger_scroll-min=7 generating wrong scroll events, and finger_scroll-min=8 generating no events. I'd really appreciate the PDF. > Is it an actual synaptics touchpad on the end of I2C? I vaguely recall > that there is an ability to connect via I2C but I may be > mis-remembering. It's likely. Unfortunately this pad also needs fixing, the button is physically disconnected...
Re: Two finger scrolling
On Tue, Mar 17, 2020 at 05:05:19PM +1030, Brett Lymn wrote: > On Sun, Mar 15, 2020 at 11:00:09PM +0000, nia wrote: > > I've just committed a handful of changes to synaptics.c that give me > > smooth two-finger scrolling out of the box. > > > > I'm curious how many others are using multitouch touchpads and whether > > you notice any improvement. > > > > I will have a look when I get a chance. Just one question, what happens > if you place one finger on the touchpad and then place another on the > touchpad in a different area and move that second finger? Does the > cursor move or do you get scrolling? The answer "scrolling" in this > situation is bad. Thinkpads have external buttons wired, some laptops, > including my fujitsu do not have any external buttons. That is the > whole reason for the button emulation code because clicking a click pad > results in a left button event - that is all you get, to emulate more > buttons in this situation the region the finger in determines the button > pressed. So, to navigate a menu the first finger down determines the > button then a second finger is used to navigate. "Newer" thinkpads (x250, 2015...) have single-button clickpads with extra wired buttons. Until a few revisions ago these buttons couldn't be configured to act as regular mouse buttons and defaulted to acting as buttons 4 and 5. I haven't managed to get right clicks with the clickpad to work either, honestly. I was not sure how this was supposed to work until you explained it. To clarify, clicking the pad down with a single finger in the right area of the pad rarely results in a right click menu either. I worked around this by adding a knob to recognize the extra buttons as regular mouse buttons by default. I've got another laptop with a single button clickpad, and no buttons, but that's using the ims(4) driver which is significantly less useful. > > > The existing approximation (sysctl hw.synaptics.finger_scroll...) wasn't > > working for me at all, tweaking hw.synaptics.finger_scroll-min either > > gave me no scrolling or registered normal mouse movements as scrolling > > > > I suspect my fingers are significantly smaller than whoever wrote this > > code. Was anyone using this successfully, and how does scrolling compare > > after my changes? > > What can I say? It worked for me. One thing I have learnt is there is a > massive variation between laptop trackpads when it comes to reporting > the W value so values that work on one laptop are bad on others, I am > surprised that you were unable to get a fscroll_min that would work for > you. The number of sysctl parameters with fairly magical values makes configuring this driver to a usable state a quite confusing affair. But yeah, the values are not fine-grained enough for me for that particular knob.
Two finger scrolling
I've just committed a handful of changes to synaptics.c that give me smooth two-finger scrolling out of the box. I'm curious how many others are using multitouch touchpads and whether you notice any improvement. The existing approximation (sysctl hw.synaptics.finger_scroll...) wasn't working for me at all, tweaking hw.synaptics.finger_scroll-min either gave me no scrolling or registered normal mouse movements as scrolling I suspect my fingers are significantly smaller than whoever wrote this code. Was anyone using this successfully, and how does scrolling compare after my changes?
Re: Audio recording (using ossaudio)
On Sat, Mar 14, 2020 at 12:20:11AM +0200, Yorick Hardy wrote: > You are correct. I threw together a NetBSD audio driver based on the oss > driver, but it had exactly the same problem. Strangely, I have been unable to > reproduce the problem on an old i386 netbook (so far). > > I wrote a test program to try and reproduce what ffmpeg is doing, and > (I am not sure yet) it seems like non-blocking reads is causing the > distortion. The same test program with blocking reads seems to work > okay. > > I will look into it a bit more, and then report back. Right, /dev/audio doesn't support non-blocking I/O. But you're supposed to do short enough reads and writes that it shouldn't matter. That might be the cause of the worst of the problems. Do you want to work on this together somewhere?
Re: Audio recording (using ossaudio)
On Tue, Mar 10, 2020 at 08:49:55PM +0200, Yorick Hardy wrote: > Can anyone else record audio correctly via ossaudio? > audiorecord seems to work as long as the frequency > divides the native frequency (see dmesg excerpt below) (I missed this post, but got contacted about it directly off-list. I'm probably a good person to contact about this sort of thing). The sample rate and number of channels need to exactly match the device for ideal output. The ffmpeg OSS code looks very primitive. I might be persuaded to write a backend that does detection of device characteristics. It's basically required for proper audio recording on NetBSD. Note that our OSS emulation doesn't match the spec exactly, and is also undocumented, so doing anything non-trivial is hard. I don't recommend writing new code that uses it for that reason. Out of curiosity, does Audacity work for you (when set to single channel 16-bit PCM, etc - it defaults to 32-bit floats which won't work).
Re: firefox dumping core after NetBSD upgrade
On Fri, Oct 11, 2019 at 11:05:57AM -0700, bch wrote: > I quit running Firefox on my (-current) laptop months ago because the build > process (rust, esp) was so brutal. Have there been any community efforts to > organize the build artifacts from bleeding-edge environments to avoid > repeating (and failing, in my case) this most horrible build? > > -bch > There is wip/rust-bin. There are also various optimizations you can make to make it a bit less brutal. See my post here: https://mail-index.netbsd.org/pkgsrc-users/2019/08/13/msg029191.html
Re: NetBSD on a wireless router?
On Wed, Aug 14, 2019 at 04:33:41PM +0100, Sevan Janiyan wrote: > Just need a suitable wireless card that performs well in hostap mode on > NetBSD (I have no recommendations as I haven't played). Unfortunately I experienced some performance problems with the wle200nx the hardware comes bundled with, so I can at least put in a recommendation against that (unless I was doing something wrong, or there's a workaround).
Re: increasing number of USB devices
On Mon, Jul 29, 2019 at 08:24:14AM -0400, Greg Troxel wrote: > --- MAKEDEV.tmpl.~1.204.~ 2019-06-29 15:26:18.320963928 -0400 > +++ MAKEDEV.tmpl 2019-07-29 07:58:25.899384262 -0400 > @@ -913,7 +913,7 @@ ramdisk) > ;; > > usbs) > - makedev usb usb0 usb1 usb2 usb3 usb4 usb5 usb6 usb7 > + makedev usb usb0 usb1 usb2 usb3 usb4 usb5 usb6 usb7 usb8 usb9 usb10 > usb11 usb12 usb13 usb14 usb15 > makedev uhid0 uhid1 uhid2 uhid3 uhid4 uhid5 > makedev uhid6 uhid7 uhid8 uhid9 uhid10 uhid11 > makedev uhid12 uhid13 uhid14 uhid15 > This is likely the correct thing to do - see my change to the number of uhids visible just below. It was previously 4, I increased it to 16 a few months ago because my keyboard alone was using all of those four. Expectations have changed over time. These days USB is used for almost everything and the previous expectation of a couple of input nodes and maybe a single storage device doesn't really apply any more. There are also 'virtual' devices and other weird things going on... I'd just suggest formating it consistently with the line below it.
Re: libva looks for non-existent hw-specific libraries?
On Wed, Jul 03, 2019 at 02:33:58PM -0500, John D. Baker wrote: > I take this to mean that pkgsrc/modular Xorg is required. "Native" Xorg > need not apply. Foo. Actually, I only tested the update with native x.
Re: What to do with base X11 for netbsd-9 ?
On Wed, May 29, 2019 at 09:12:42AM +0200, Martin Husemann wrote: > So what is you story/opinion: is base X11 usable in -current? If not, > what needs to be done or what hardware needs fixes? Mostly, yeah. It was very broken in 8.0, and MesaLib and video-intel updates mean I no longer need to use modular xorg with my Kaby Lake laptop. My radeon destop runs well too. Recent changes improved the intel tearing situation. I'm reasonably happy. ... but I have two problems currently, with ugly workarounds in pkgsrc (which don't work for everything). Neither occurs when using modular xorg, and seem to be regressions: * r600_dri.so (and other DRI drivers) being linked improperly. Missing libxcb symbol errors when loading libGL with dlopen, as a lot of OpenGL software seems inclined to do. I committed a workaround for this to SDL2 the other day, as well as etlegacy. It's still a problem with software that uses libepoxy. * Certain programs that use OpenGL contexts can make the X server segfault when they exit. Reproducable by compiling retroarch with the x11+opengl options, starting and exiting it. maya has been helping investigate both, but we're stalled right now.
