Re: framebuffer console on old ATI

[Michael]

Hello,

On Thu, 23 May 2024 09:11:17 +
Riccardo Mottola  wrote:

> Michael wrote:
> > Did it crash or did if continue booting? If it continued to boot
> > radeonfb likely got the wiring of outputs to displays wrong.
> > With that, please try with options RADEONFB_BIOS_INIT, which adds code
> > to scan the BIOS for output info. This is not enabled by default
> > because most hardware we run radeonfb on doesn't have a PC BIOS. Should
> > probably be on by default on x86.  
> 
> did so. Still get a black screen. Before going black, I am able to see a
> "failed".
> Also, it hangs, because if I wait some time I can't login remotely (left
> dhcp on).

This is odd, but it's a data point at least.
Does it hang without RADEONFB_BIOS_INIT as well?
If it doesn't and you just get no useful output - does the laptop in
question have a VGA or DVI output? If it does, could you plug something
into it?
The reason I'm asking is, most/maybe all radeons have at least two
outputs, how they're wired to connectors, LCDs etc. is up to the
vendors. Normally there is a table in the video BIOS telling us exactly
what is connected to what. That's what RADEONFB_BIOS_INIT tries to find.
If we get it wrong we may very well end up with a black display.
On macppc we don't have a connector table but pretty much all *Books
wire up the internal display in exactly the same way, there are a few
exceptions but we can distinguish those from the model string in OF.

I know RADEONFB_BIOS_INIT works on macppc because I have an r360 card
with both OF and a PC BIOS in ROM, and with it radeonfb correctly
identifies both outputs as DVI.

The other possible cause would be some endianness screwup, radeonfb has
been used mostly on macppc and sparc64, and not much else. IIRC some
brave soul made it work on alpha a while ago, but it got pretty much
zero testing on x86.

> thanks to easy videos with iPhones... I was able to extract a frame:
> 
> radeonfb0: BIOS initialization failed

So the machine probably doesn't have a video BIOS, just like most Apple *Books.

Does Xorg run with a radeon driver on any OS at all? If so, could you
send me the xorg.0.log from such a thing? That should give at least a
hint on what we get wrong.

have fun
Michael

Re: ffmpeg6 drawtext option question

[Michael Lowery Wilson]

Hello,

Thank you very much for the heads up on this. I will go ahead and recompile.

In the meantime I read around a bit and found a work around by using ffmpeg 
instead of ffmpeg6. The necessary features for what I needed are apparently 
compiled in by default so it just works out of the box.


On 28/05/24 at 08:40P, RVP wrote:

On Tue, 28 May 2024, Michael Lowery Wilson wrote:


However, I get the below result instead:

[AVFilterGraph @ 0x7eb5fb57f580] No such filter: 'drawtext'
[vost#0:0/libx264 @ 0x7eb5fb53a500] Error initializing a simple filtergraph
Error opening output file timestamped-recording.mp4.



That error message is correct; there's no `drawtext' filter compiled in:

$ ffmpeg6 -filters 2>&1 | fgrep drawtext
$

Which points toward an issue with the drawtext filter. I have 
checked and my version of ffmpeg6 is compiled with the 
--enable-libfreetype flag by default, which is required for the 
drawtext filter:


https://ayosec.github.io/ffmpeg-filters-docs/3.3.9/Filters/Video/drawtext.html



According to the current docs. you also need `--enable-libharfbuzz' now:

https://ffmpeg.org/ffmpeg-filters.html#drawtext-1

Can you recompile with libharfbuzz added, then tell the pkgsrc folks if that
works?

-RVP


Michael

ffmpeg6 drawtext option question

[Michael Lowery Wilson]

Hello,

I am trying to test adding timestamp to a recorded video using ffmpeg6 using 
the following:


ffmpeg6 -i recording.mp4 -vf 
drawtext="fontsize=60:fontcolor=yellow:text='%{localtime}':x=(w-text_w):y=(h-text_h)" 
timestamped-recording.mp4


on

uname -a
NetBSD test.Home 10.0 NetBSD 10.0 (GENERIC) #0: Thu Mar 28 08:33:33 UTC 2024  
mkre...@mkrepro.netbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC amd64


However, I get the below result instead:

[AVFilterGraph @ 0x7eb5fb57f580] No such filter: 'drawtext'
[vost#0:0/libx264 @ 0x7eb5fb53a500] Error initializing a simple filtergraph
Error opening output file timestamped-recording.mp4.

Which points toward an issue with the drawtext filter. I have checked and my 
version of ffmpeg6 is compiled with the --enable-libfreetype flag by default,  
which is required for the drawtext filter:


https://ayosec.github.io/ffmpeg-filters-docs/3.3.9/Filters/Video/drawtext.html

My compiled options:

ffmpeg version 6.1.1 Copyright (c) 2000-2023 the FFmpeg developers
  built with gcc 10.5.0 (nb3 20231008)
  configuration: --enable-avfilter --enable-postproc --disable-ffplay 
--enable-rpath --enable-fontconfig --enable-libfreetype --enable-libass 
--enable-libaom --disable-librav1e --enable-libdav1d --disable-htmlpages
--enable-gnutls --disable-mbedtls --disable-libopencore-amrnb 
--disable-libopencore-amrwb --disable-openssl --disable-libjack
--disable-libpulse --disable-libtesseract --enable-libtheora 
--enable-libvorbis --enable-libmp3lame --enable-libopus --enable-libspeex

--enable-libxvid --enable-libx264 --enable-libx265 --enable-vdpau
--enable-vaapi --enable-libvpx --enable-libwebp --enable-libxcb 
--enable-libxcb-shape --enable-libxcb-shm --enable-libxcb-xfixes
--enable-libbluray --arch=x86_64 --cc=gcc --disable-debug 
--disable-optimizations --disable-stripping --enable-gpl --enable-libxml2 
--enable-pthreads --enable-shared --mandir=/usr/pkg/man --prefix=/usr/pkg 
--progs-suffix=6 --enable-runtime-cpudetect --datadir=/usr/pkg/share/ffmpeg6

--docdir=/usr/pkg/share/doc/ffmpeg6 --incdir=/usr/pkg/include/ffmpeg6
--libdir=/usr/pkg/lib/ffmpeg6 --shlibdir=/usr/pkg/lib/ffmpeg6

I also tried the original command while specifying a font file using:

-vf 
drawtext="/usr/pkg/share/texmf-dist/fonts/truetype/public/gnu-freefont/FreeSerif.ttf: 
fontcolor=yellow:text='%{localtime}':x=(w-text_w):y=(h-text_h)"


and get the following:

[AVFilterGraph @ 0x7ed38f266580] No option name near 
'/usr/pkg/share/texmf-dist/fonts/truetype/public/gnu-freefont/FreeSerif.ttf: 
fontcolor=yellow:text=%{localtime}:x=(w-text_w):y=(h-text_h)'
[AVFilterGraph @ 0x7ed38f266580] Error parsing a filter description around: 
[AVFilterGraph @ 0x7ed38f266580] Error parsing filterchain 
'drawtext=/usr/pkg/share/texmf-dist/fonts/truetype/public/gnu-freefont/FreeSerif.ttf: 
fontcolor=yellow:text='%{localtime}':x=(w-text_w):y=(h-text_h)' around: 
[vost#0:0/libx264 @ 0x7ed38f221500] Error initializing a simple filtergraph

Error opening output file timestamped-recording.mp4.
Error opening output files: Invalid argument

There is probably a simple fix to this, or something that I have overlooked, 
but I am quite challenged to find it.  Has anyone run into anything similar or 
has any advice as to how to get this working?


Thank you very much!

Michael

Re: framebuffer console on old ATI

[Michael]

Hello,

On Wed, 8 May 2024 10:14:55 +
Riccardo Mottola  wrote:

> Hi,
> 
> Michael wrote:
> >> How do I enable radeonfb? Can I do it through configurations or do I
> >> need to compile my own kernel to try?  
> > radeonfb* at pci?
> >   
> 
> I copied that line from ALL to my custom kernel build which I did for
> iwi debug.
> 
> I just get a big black screen... no text, no white cursor.
> Had to turn of via powerbutton.

Did it crash or did if continue booting? If it continued to boot
radeonfb likely got the wiring of outputs to displays wrong.
With that, please try with options RADEONFB_BIOS_INIT, which adds code
to scan the BIOS for output info. This is not enabled by default
because most hardware we run radeonfb on doesn't have a PC BIOS. Should
probably be on by default on x86.

have fun
Michael

Re: framebuffer console on old ATI

[Michael]

Hello,

On Tue, 7 May 2024 08:19:33 +
Riccardo Mottola  wrote:

> > Radeonfb should Just Work(tm) - it's used mainly on macppc and sparc64
> > but I'm pretty sure it's been run on at least some little endian hw
> > before.  
> 
> according to radeon manpage, mine would have an R100, the earliest
> supported on X11.

Yeah, I fixed a few problems there, xrender support was broken for r1xx.
Sun's xvr-100 card is a rebadged rv100...

> How do I enable radeonfb? Can I do it through configurations or do I
> need to compile my own kernel to try?

radeonfb* at pci?

> drm did not configure, dmesg says.

It's not a DRM driver, just an accelerated framebuffer console thing.
If you have an iBook you probably used it.

have fun
Michael

Re: framebuffer console on old ATI

[Michael]

Hello,

On Mon, 6 May 2024 23:17:12 +
Riccardo Mottola  wrote:

> X11, which appears to run fine, reports it as:
> [   646.096] (II) VESA(0): VESA VBE Total Mem: 16320 kB
> [   646.096] (II) VESA(0): VESA VBE OEM: ATI MOBILITY RADEON 7500
> [   646.096] (II) VESA(0): VESA VBE OEM Software Rev: 1.0
> [   646.096] (II) VESA(0): VESA VBE OEM Vendor: ATI Technologies Inc.
> [   646.096] (II) VESA(0): VESA VBE OEM Product: P7
> [   646.096] (II) VESA(0): VESA VBE OEM Product Rev: 01.00
> 
> 
> Linux has FB console on ever lower spec ATIs, but I have no direct
> comparison with this specific one, I admit.

Radeonfb should Just Work(tm) - it's used mainly on macppc and sparc64
but I'm pretty sure it's been run on at least some little endian hw
before.

have fun
Michael

Re: netbsd crashes when using fat filesys

[Michael van Elst]

rhia...@falu.nl (Rhialto) writes:

>$ sudo ./rump_msdos -o rw -o rump ./efi.img /tmp/t
>rump_msdos: "./efi.img" is a relative path.
>rump_msdos: using "/mnt/scratch/scratch/tmp/xcrash/efi.img" instead.
>[   1.000] entropy: ready

>terminal 2:

>$ cd /tmp/t
>$ ls -l
>total 4
>drwxr-xr-x  1 rhialto  wheel  4096 Apr 21  2021 efi/
>-rwxr-xr-x  1 rhialto  wheel 0 May  2 22:32 file*
>$ mv file file2
>mv: rename file to file2: Device not configured


I can repeat this with rump, but not with the kernel filesystem.
After my suggested change, rump no longer crashes.

N.B. the code change is in /usr/lib/librumpfs_msdos.so.0.0.

Re: netbsd crashes when using fat filesys

[Michael van Elst]

rhia...@falu.nl (Rhialto) writes:

>I had something similar recently when doing a rename of a file on a FAT
>file system (in this case my /efi file system). Fortunately I had it
>mounted with -o rump, because it was 100% repeatable.

>I filed http://gnats.netbsd.org/58146 for it.


Maybe that's rump.

msdosfs:
KASSERT(tcnp->cn_cred == cred);

genfs:  /*
 * XXX Want a better equality test.  `tcnp->cn_cred == cred'
 * hoses p2k because puffs transmits the creds separately and
 * allocates distinct but equivalent structures for them.
 */
KASSERT(kauth_cred_uidmatch(cred, tcnp->cn_cred));


Can you still repeat the crash when you change the assertion
to match the genfs check ?

Re: RPi 4b Wifi Device

[Michael van Elst]

michael.chepo...@gmail.com (Michael Cheponis) writes:

>I use the built-in GigE adaptor on the RPi 4B, because it's convenient as I
>have wired ethernet most places.   So I can't help with WiFi.

Ethernet is also faster, even when the WiFi chip does 802.11ac.

For Wifi on a RPI4b:

With RPI-OS running iperf3 shows about 80Mbit/s.
NetBSD (-current, but -10 should be similar) gets me about 40MBit/s.

Wifi is connected to a SDHC controller, and handling I/O there generates
quite some overhead (while iperf3 is running):

  PID   LID USERNAME PRI STATE   TIME   WCPUCPU NAME  COMMAND
0   118 root 123 CPU/1   1:33 39.45% 39.45% sdmmc0[system]
 7467 12269 mlelstv   85 mutex/2 0:03  4.79%  4.79% - iperf3
0 3 root 222 IDLE/0  0:04  2.59%  2.59% softnet*0 [system]
0   101 root 222 IDLE/3  0:03  1.81%  1.81% softnet*3 [system]
030 root 222 IDLE/2  0:02  1.32%  1.32% softnet*2 [system]
024 root 222 IDLE/1  0:02  0.93%  0.93% softnet*1 [system]

That's about 80% of one core.

Re: RPi 4b Wifi Device

[Michael Cheponis]

I run an RPi 4B/8G with external USB SSD drive; I do this because my uSD
cards were getting worn out after about a year of use; I've had no such
problems with my Samsung 870 EVO nor Samsung SSD T7.

I use the built-in GigE adaptor on the RPi 4B, because it's convenient as I
have wired ethernet most places.   So I can't help with WiFi.

I have been running an RPi 3 from a Lexar 64B Thumb Drive since June 2019 -
no problem there, either.

-Mike


-Mike


On Sat, Apr 20, 2024 at 2:04 PM Thomas D. Dean 
wrote:

> On 4/20/24 13:16, Michael van Elst wrote:
> > tomd...@wavecable.com ("Thomas D. Dean") writes:
> >
> >> # wpa_cli status
> >> Selected interface 'bwfm0'
> >> 21:58:44.815: bssid=60:38:e0:db:a9:7a
> >> freq=0
> >> ssid=tddhome
> >> id=0
> >> mode=station
> >> pairwise_cipher=TKIP
> >> group_cipher=TKIP
> >> key_mgmt=WPA-PSK
> >> wpa_state=GROUP_HANDSHAKE
> >> ip_address=169.254.135.120
> >> address=e4:5f:01:da:eb:46
> >
> >> I don't understand where the inet 169.254.135.120 comes from. The router
> >> pool is 192.168.1.xxx.
> >
> > 169.254.x.x is a "link local" address. dhcpcd falls back to such an
> > address, if it doesn't get an answer from a dhcp server. Apparently
> > wpa_supplicant cannot connect to the network.
> >
> >> wpa_state=GROUP_HANDSHAKE
> >
> > says that it still tries to associate. When it's done this would
> > change to COMPLETED.
> >
>
> I have two RPi 4b's. One with NetBSD 10 on an SD card and the other with
> RPi OS on a USB flash drive. (I can not get NetBSD to boot from a flash
> drive)
>
> As far as I can tell the network configurations are the same for WIFI on
> both. I see comments on the web about NetBSD 10 problems with the bwfm
> device.
>
> I need WIFI. So, I go back to RPi OS.
>
> Thanks for all the replies.
>
> Tom Dean
>

Re: need your advice before new Raspberry Pi purchase

[Michael]

Hello,

On Sat, 20 Apr 2024 11:46:51 +0200
Ramiro Aceves  wrote:

> "As of early 2024, NetBSD does not support the Raspberry Pi 5."
> 
> Reading that I inmediatly discarded the Raspberry Pi 5 choice. Being 
> realistic I think It does not work in NetBSD 10 now and I estimate it 
> will not work well for perhaps some years. Life is short, I cannot wait 
> and so I think RaspberryPi 4 should be my buying target.

Not sure what's missing - there is now at least beta UEFI firmware for the Pi5.

> "NetBSD 10"
> 
>  "RPI4 general support (but there are issues)"

I've been using an 8GB Pi4 and a Pi400 with UEFI for a while now.

>  "RPI4 ethernet (Broadcom GENETv5) (but the man page for genet(4) is 
> missing)"
> 
> Can I be sure that ethernet will work fine and reliable? Network speed?

Works fine on mine, good enough for NetBSD and pkgsrc builds with
sources over NFS.

>  "builtin bluetooth on RPI3 (RPI0W? RPI4?)"
> 
> Does bluetooth work on the Pi4?

Never tried.

>  "builtin WiFi on RPI0W, RPI3 and RPI4 - bwfm(4)"
> 
> Does WIFI bwfm  driver work as badly as in the ZeroW? Not relevant for 
> my future use of the Pi 4 cause I will use it through ethernet but that 
> will be a bonus, just curious.

IIRC I got it to connect to my router but never really stress tested
it. I prefer wired ethernet wherever practical.

>  "RPI4 xhci does not work with a straight netbsd-10 install"
> 
> I seems that below is the explanation.

Both my Pi4* boot from USB3 disks connected to USB3 ports.

> After switching to UEFI you will make USB ports work but 8 GB RapberryPi 
> will be reduced to 3 GB only with no workaround? What do "needing a 
> monitor" mean? Why?

The 3GB limit is on by default for some old linux kernels that don't
have the DMA workaround. It takes about 10 seconds to get into the UEFI
setup menu and turn it off.

[ 1.00] NetBSD 10.99.7 (GENERIC64) #0: Thu Aug 24 06:18:05 EDT 2023
[ 1.00] 
ml@paddy:/disk/build/obj_earm64/sys/arch/evbarm/compile/GENERIC64
[ 1.00] total memory = 8029 MB
[ 1.00] avail memory = 7740 MB
[ 1.00] entropy: ready
[ 1.00] ptyfs_hashinit: 0001feef5b00
[ 1.00] timecounter: Timecounters tick every 10.000 msec
[ 1.00] armfdt0 (root)
[ 1.00] armfdt0: using EFI runtime services for RTC
[ 1.00] simplebus0 at armfdt0: Raspberry Pi Foundation Raspberry Pi 4 
Model B
[ 1.00] simplebus1 at simplebus0
[ 1.00] acpifdt0 at simplebus0
[ 1.00] acpifdt0: SMBIOS rev. 3.3.0 @ 0x371d
...

> Does HDMI output work or should I use serial console? traditional boot 
> vs UEFI difference in this matter?

I'm typing this on a Pi400 with a monitor hooked to it. My Pi400 even
came with a micro-HDMI to regular HDMI cable.

have fun
Michael

Re: RPi 4b Wifi Device

[Michael van Elst]

tomd...@wavecable.com ("Thomas D. Dean") writes:

># wpa_cli status
>Selected interface 'bwfm0'
>21:58:44.815: bssid=60:38:e0:db:a9:7a
>freq=0
>ssid=tddhome
>id=0
>mode=station
>pairwise_cipher=TKIP
>group_cipher=TKIP
>key_mgmt=WPA-PSK
>wpa_state=GROUP_HANDSHAKE
>ip_address=169.254.135.120
>address=e4:5f:01:da:eb:46

>I don't understand where the inet 169.254.135.120 comes from. The router 
>pool is 192.168.1.xxx.

169.254.x.x is a "link local" address. dhcpcd falls back to such an
address, if it doesn't get an answer from a dhcp server. Apparently
wpa_supplicant cannot connect to the network.

>wpa_state=GROUP_HANDSHAKE

says that it still tries to associate. When it's done this would
change to COMPLETED.

Re: RPi 4b Wifi Device

[Michael van Elst]

tomd...@wavecable.com ("Thomas D. Dean") writes:

>How do I setup wpa_supplicant?

That depends on what you want to do.

Here are some examples:
https://wiki.netbsd.org/tutorials/how_to_use_wpa_supplicant/


Greetings,

Re: RPi 4b Wifi Device

[Michael van Elst]

tomd...@wavecable.com ("Thomas D. Dean") writes:

>On 4/18/24 22:00, Michael van Elst wrote:
>> bwfm0: Firmware file default:brcmfmac43455-sdio.bin
>> bwfm0: Firmware file model-spec: brcmfmac43455-sdio.raspberrypi,4-model-b.bin
>> bwfm0: Found Firmware file: brcmfmac43455-sdio.raspberrypi,4-model-b.bin

>> bwfm0: NVRAM file default:brcmfmac43455-sdio.txt
>> bwfm0: NVRAM file model-spec: brcmfmac43455-sdio.raspberrypi,4-model-b.txt
>> bwfm0: Found NVRAM file: brcmfmac43455-sdio.raspberrypi,4-model-b.txt

>> bwfm0: CLM file default:brcmfmac43455-sdio.clm_blob
>> bwfm0: CLM file model-spec: brcmfmac43455-sdio.raspberrypi,4-model-b.clm_blob
>> bwfm0: Found CLM file: brcmfmac43455-sdio.raspberrypi,4-model-b.clm_blob


>I saw bwfm0: in /var/log/messages, from memory, similar to the ones listed.
>One error. autoconfiguration error: NVRAM file not available.
>The CHIPACTIVE line is missng.


This means, a firmware file isn't found, because it is searched under
a different name.

You should have:

-r--r--r--  1 root  wheel  1863 Mar 28 17:45 
libdata/firmware/if_bwfm/brcmfmac43455-sdio.raspberrypi,4-model-b.txt

and need to create a symlink like:

cd /libdata/firmware/if_bwfm
ln -s brcmfmac43455-sdio.raspberrypi,4-model-b.txt 
"brcmfmac43455-sdio.Raspberry Pi 4 Model B.txt"

Reason is that the platform is canonically named "raspberrypi,4-model-b"
but UEFI chose "Raspberry Pi 4 Model B" instead.


Greetings,

Re: RPi 4b Wifi Device

[Michael van Elst]

tomd...@wavecable.com ("Thomas D. Dean") writes:

>What is the wifi device in the RPi 4b? Driver?

It's a chip similar to the one in the older RPIs:

bwfm0: chip 0x4345 rev 6
bwfm0: Firmware file default:brcmfmac43455-sdio.bin
bwfm0: Firmware file model-spec: brcmfmac43455-sdio.raspberrypi,4-model-b.bin
bwfm0: Found Firmware file: brcmfmac43455-sdio.raspberrypi,4-model-b.bin
bwfm0: NVRAM file default:brcmfmac43455-sdio.txt
bwfm0: NVRAM file model-spec: brcmfmac43455-sdio.raspberrypi,4-model-b.txt
bwfm0: Found NVRAM file: brcmfmac43455-sdio.raspberrypi,4-model-b.txt
bwfm0: CLM file default:brcmfmac43455-sdio.clm_blob
bwfm0: CLM file model-spec: brcmfmac43455-sdio.raspberrypi,4-model-b.clm_blob
bwfm0: Found CLM file: brcmfmac43455-sdio.raspberrypi,4-model-b.clm_blob
bwfm0: CHIPACTIVE

bwfm0: flags=0x8843 mtu 1500
ssid  nwkey *
powersave off
bssid ##:##:##:##:##:## chan 100
address: ##:##:##:##:##:##
media: IEEE802.11 autoselect (VHT mode 11ac)
status: active
inet6 fe80:::::%bwfm0/64 flags 0 scopeid 0x3

Re: Please forgive a blatant plug: I reviewed v10 for the Reg

[Michael Huff]

On Thu, Apr 18, 2024 at 3:01 AM Liam Proven  wrote:

> I thought this might interest folks here...
>
> NetBSD 10 proves old tech can still kick apps and take names three decades
> later
>
> Proper old-school Unix, not like those lazy, decadent Linux types
>
> https://www.theregister.com/2024/04/17/30yo_netbsd_releases_v10/
>
> Comments and feedback welcomed!
>
> --
> Liam Proven ~ Profile: https://about.me/liamproven
> Email: lpro...@cix.co.uk ~ gMail/gTalk/FB: lpro...@gmail.com
> Twitter/LinkedIn: lproven ~ Skype: liamproven
> IoM: (+44) 7624 277612: UK: (+44) 7939-087884
> Czech [+ WhatsApp/Telegram/Signal]: (+420) 702-829-053
>

I saw it on Hacker News ,
enjoyed the discussion on both sites (HN, Register) . Thanks for writing it
up and sharing it!

Re: hostapd

[Michael van Elst]

On Thu, Apr 04, 2024 at 11:28:41AM +0100, Patrick Welche wrote:
> 10:15:22.135344 IP (tos 0x0, ttl 64, id 12912, offset 0, flags [DF], proto 
> TCP (6), length 60)
> 192.168.100.3.60610 > 192.168.100.62.80: Flags [S], cksum 0x783f 
> (correct), seq 50981267, win 65535, options [mss 1460,sackOK,TS val 2022496 
> ecr 0,nop,wscale 6], length 0

> I assume
> 
> hostapd: urtwn0: interface state UNINITIALIZED->ENABLED
> hostapd: urtwn0: AP-ENABLED 
> 
> rules out a monitor mode? or ? The dhcpd response was fine...

dhcpd uses BPF to receive and transmit DHCP packets. So the symptoms would 
point to an issue in the ARP or IP layer.

-- 
Michael van Elst
Internet: mlel...@serpens.de
"A potential Snark may lurk in every tree."

Re: hostapd

[Michael van Elst]

pr...@welche.eu (Patrick Welche) writes:

>The system httpd via inetd doesn't receive a web page request from the
>device.
>tcpdump shows the device requesting it, but no response.

If httpd wouldn't run, the request would be answered with
a TCP RST.

If httpd does run, the request (SYN) is answered with a 
TCP SYN/ACK.

Can you say what exactly is "no response" here?


>on the server, telnet localhost 80, GET /, works

Did you configure (in /etc/inetd.conf) http for tcp or tcp6 ?
A 'telnet localhost 80' would see either, but a pure IPv4 client
only sees the 'tcp' one.


Greetings,

Re: RC6 (and later)

[Michael Cheponis]

I am not on the Release Team or involved except as a user --- however, I
greatly approve of _RC6 release, AND the additional time it will take for
people to beat on it before it becomes the 10.0 release.

We have more hardware to properly work on now (just for starters, all RPi
up to 4 at least), etc, and many new chips for old arches (e.g. N200 for
amd64) so when you look at the growing complexity, it makes sense to keep
testing by as large a group as possible before 'release'.

After all, when it comes right down to it, the Release is just a Number.
 Who cares what the number is -- it is the set of Stable Features that are
of interest.

I would encourage all to d/l _RC6 and bang on it, like I'm doing.

Thanks,
Mike


On Fri, Mar 15, 2024 at 7:30 AM Rose  wrote:

> Because, that's too god damned many...
>
> RELEASE NOW
>
> On Fri, Mar 15, 2024 at 9:19 AM Vitaly Shevtsov 
> wrote:
>
> > Because they can. Why not?
> >
> > On Fri, Mar 15, 2024 at 3:17 PM Todd Gruhn  wrote:
> > >
> > > There is now NetBSD-10.0RC6 -- I don't  ever recall seeing RC5 or later

Re: mbrlabel question

[Michael van Elst]

ea1...@gmail.com (Ramiro Aceves) writes:

> The following options are available:
> -f Force an update, even if there has been no change.
> -q Performs operations in a quiet fashion.
> -r In conjunction with -w, also update the on-disk label.
> -s sector  Specifies the logical sector number that has to be read from
>the disk in order to find the MBR.  Useful if the disk has
>remapping drivers on it and the MBR is located in a non-
>standard place.  Defaults to 0. 
> -w Update the in-core label if it has been changed.  See also -r.

>I do not know the difference between the in-core and on-disk options,
>what I should use and if I can break something with it.


The BSD partition information (aka "disklabel") exists in memory ("in-core")
and is also written to disk ("on-disk").

If you change only in-core, the change is temporary and volatile. When
the disk is no longer in use, or after a reboot, the changes are gone.

For permanent changes you need to write the on-disk label.

I.e. use

mbrlabel wd0

to show how the disklabel would look like, and use

mbrlabel -rw wd0

to actually change the disklabel permanently.

'forgot' password ? Couldn't generate salt

[Michael Cheponis]

I did a sysupgrade to amd64 to _RC5  (from _RC3), but it seems to have
reset my passwords.  The accounts are there, just the passwords have been
changed.

Tried logging in single-user as described in
https://www.netbsd.org/docs/guide/en/chap-boot.html

# passwd root
...
Couldn't generate salt.
Unable to change auth token: Error in service module
#



And of course, the password is not changed, and I still can't log in.

I'm probably doing something dumb.  Thanks for any help/pointers.

-Mike

Re: NetBSD and ECC RAM?

[Michael van Elst]

kevin.bowl...@kev009.com (Kevin Bowling) writes:

>Servers tend to have BMCs, so you can execute 'ipmitool sensors' and
>'ipmi sel elist' to get the information out.

ECC information is usually not provided by sensors. ECC errors may
be listed in the SEL, but even this usually occurs only when some
undocumented limit is reached. Often the messages also do not indicate
the memory module that produced the error.


>Linux has the 'EDAC' subsystem but I don't think it gains you so much
>if you have a BMC.

It gives you the data from the ECC circuits, immediately. So data is
no longer hidden by the BMC, you get precise information and you can
apply your own policies for e.g. replacing memory modules or migrating
services to other hardware.

The OS could be smart, lock out bad memory regions, recover some
errors by e.g. paging in text data again or even use mirrored RAM
(with motherboard support).


>A lot of fragile chipset specific code to get that.

Indeed.


Greetings,

Re: NetBSD and ECC RAM?

[Michael van Elst]

michael.chepo...@gmail.com (Michael Cheponis) writes:

>I've been running ECC in the Windows box for years, it seems like a 'no
>brainer' for servers. Servers usually run for years, and Stuff Happens over
>the years [1].
>But I'd prefer a reliable, unhackable, trustable compute fabric.  ECC is
>part of the 'reliable' part.

I agree, but the "box" will run with ECC, even when the OS doesn't
know about it. OS support is needed to get information about errors
and for better fault tolerance.


>I would also like to see per /dev entry ACLs.  I would like to see better
>security than owner-group-everbody permissions.

I have rarely seen ACLs being used for "better security". Even when that
was possible, the complexity usually outweighed any gain in control.

Systems that implied access control through simple rules worked much
better. It's still not a feature that you had to enable or a switch
you toggled, it requires constant effort, in particular on systems
that don't just perform a fixed set of functions.

Re: NetBSD and ECC RAM?

[Michael Cheponis]

I've been running ECC in the Windows box for years, it seems like a 'no
brainer' for servers. Servers usually run for years, and Stuff Happens over
the years [1].

Most of the computing industry has been hell-bent on performance, yielding
impressive gains (albeit with occasional setbacks:
https://cachewarpattack.com/ )

But I'd prefer a reliable, unhackable, trustable compute fabric.  ECC is
part of the 'reliable' part.

I would also like to see per /dev entry ACLs.  I would like to see better
security than owner-group-everbody permissions.  I would like to see almost
no normal system operations requiring root privs - and I would like to see
root privs made much more narrow and fine-grained in scope - only large
enough to do the specific job (e.g. change file permission, with a separate
capability to change file ownership; etc).

I'm certainly no computer security guru, or have any valid opinions except
as a luser.

Still --- I would like to see some performance gains "wasted" in order to
gain better reliable, unhackable, trustable systems.


Thanks for tolerating my mini-soapbox.
-Mike

[1] I recently had a NetBSD server's computer start to have random crashes
until I tried to boot it one more time, and it wouldn't come up at all.
 Then after cleaning everything, making sure disks were OK, and trying
again with no luck did I stare at the MB and saw  the electrolytic
caps' tops bulging out!   My rule: Never trust HW completely.  It will
fail.  Eventually.


On Fri, Feb 16, 2024 at 7:09 AM Hauke Fath (SPG) 
wrote:

> On 2024-02-16 01:14, Michael van Elst wrote:
> > We should have EDAC drivers that should at least report events,
> > but so far there is nothing...
>
> Sounds like a SoC project?
>
> Cheerio,
> Hauke
>
>
> (FreeBSD appears to be no better off:
> <
> https://forums.freebsd.org/threads/how-to-find-out-if-ecc-is-enabled.72839/
> >)
>
> --
>   The ASCII Ribbon CampaignHauke Fath
> () No HTML/RTF in email Institut für Nachrichtentechnik
> /\ No Word docs in email TU Darmstadt
>   Respect for open standards  Ruf +49-6151-16-21344
>

Re: NetBSD and ECC RAM?

[Michael van Elst]

h...@spg.tu-darmstadt.de ("Hauke Fath (SPG)") writes:

>one my favourite blogs is sporting a page on AMD ECC RAM support
>,

>Is this of any relevance to NetBSD, or do we just not bother?


We should have EDAC drivers that should at least report events,
but so far there is nothing...

Re: Raspberry Pi Zero W almost useless

[Michael]

Hello,

On Fri, 9 Feb 2024 06:25:56 +0100
Ramiro Aceves  wrote:

> >> I have also the same problem that I had with the chineese 8188FTV,  as
> >> soon I connect it to the raspberry pi it reboots inmediately. In the
> >> next reboot it works fine. It occurs the same in another Zero W that I
> >> own  with Raspbian and a different power supply. So I doubt that the
> >> culprit is the power supply. The Zero W seems to be a very flaky device
> >> in terms of power supply.
> >>  
> > A powered hub should fix that, when a device is plugged directly into the
> > raspberry pis usb (IIRC only 300mA is available) it can cause reboots.
> >   
> 
> Oh yes, that would be a right technical fix for the problem but it's a 
> bit of an aberration in terms of cost and size to use a powered HUB with 
> its own power supply to fix a little thing like the ZeroW, you know ;-)

Just use the hub to power the Pi. I used to do that wit the Pi1 and 2.

have fun
Michael

Re: Raspberry Pi Zero W almost useless

[Michael van Elst]

ea1...@gmail.com (Ramiro Aceves) writes:

>Oh yes, that would be a right technical fix for the problem but it's a 
>bit of an aberration in terms of cost and size to use a powered HUB with 
>its own power supply to fix a little thing like the ZeroW, you know ;-)

RPI0-3 models all have issues with power.

Especially on the original RPI1 and RPI0 variants you shouldn't
consider USB as being "hot pluggable". For the other models
hot-plugging low power USB devices (i.e. using 100mA or less)
should be fine. Unfortunately that might rule out things like
many gaming keyboards and also some WLAN dongles.

Re: NetBSD 10.0 RC_3 GENERIC amd64 home built kernel doesn't boot

[Michael van Elst]

fekete.zol...@minux.hu (=?UTF-8?Q?Fekete_Zolt=C3=A1n?=) writes:

>Hi There,

Hi,

maybe you can provide more information.


>I have a laptop from 2013, and I'm playing around with it.
>I've just compiled a kernel with the command:

>./build.sh -T ../tools -O ../obj -U -N1 -j2 kernel=GENERIC

is that from netbsd-10 sources? Did you change the GENERIC
configuration?


>... boot device: wd0
>... root on wd0c dumps on wd0b
>... vfs_mountroot: can't open root device

wd0c wouldn't be a standard installation. Usually you write a disklabel
that uses wd0a as the root partition.


>... cannot mount root, error = 6

error 6 could mean that the wd0 disk doesn't exist or that partition
wd0c doesn't contain a valid filesystem or that you have a stripped
kernel that lacks the filesystem code.


>I've checked, and as expected, DKWEDGE options are set properly as 
>mentioned in 'man dk(4)'.

What DKWEDGE options did you set?



>The system just boots fine with the kernel bundled in the installation 
>image.

Then you could show your disk layout as seen by the bundled kernel,
also what that kernel prints for 'boot device' and 'root on' and
what filesystem you used.

Re: shrinking a filesystem using resize_ffs(8)

[Michael van Elst]

jscha...@netmeister.org (Jan Schaumann) writes:

>Hi,

Hi,

>$ sudo newfs -C 2 /dev/rvnd0a

There is no '-C'. Maybe -O 2 ?

But resize_ffs doesn't support shrinking FFS2 and should
complain when you try.


>[ back to two '1048576' sized partitions ]

>$ sudo fsck_ffs -y -f /dev/rvnd0b
>[ all ok ]

The 'b' filesystem was probably never changed but maybe trashed in
a way that fsck doesn't understand.


>$ sudo resize_ffs -v /dev/rvnd0b
>No change requested: already 524288 blocks

The superblock and partition agree. Nothing
to do and nothing to check.


>$ sudo fsck_ffs -y -f /dev/rvnd0a
>** /dev/rvnd0a

>CANNOT READ: BLK 2010160
>CONTINUE? yes

The 'a' filesystem still thinks it is 1GB and you try to shrink
it. But the disklabel already restricts access to the lower half.
Any attempt to access data from the upper half fails.


>$ sudo resize_ffs -v /dev/rvnd0a
>resize_ffs: read failed: Invalid argument

Dito. Shrinking requires access to all the data.


>So... how do I shrink a filesystem?

You tell resize_fsck the new size with -s and then
reduce the partition size accordingly.

Re: Keyboards

[Michael Parson]

On 2024-01-19 19:14, Todd Gruhn wrote:
On Fri, Jan 19, 2024 at 7:02 PM Brad Spencer  
wrote:


Todd Gruhn  writes:

> Ump-teen years ago there was an analog-keyboard.
> It actually when 'click' when one pressed the key.
>
> Do these still exist??
> Do they last longer then the current keyboards?

I think I get what you are asking about..  yes, they very much exist.  
A
web search with "mechanical keyboard" or simular should find them.  
The

better ones will not be cheap.

There is also a subculture out there of people building their own
mechanical keyboards.  There are some very nice switches that you can
get, layouts, and designs, etc..  to roll your own or you can buy the
bits and assemble it yourself.  Not cheap, but very doable.  I think
"mechanical keyboard kit" might find those for you.

I use a 35+ year old mechanical USB keyboard that originally was on a
Gateway PC clone.  It is the color of a white and black cow.  It feels
nice and I like the color combination

If you have a ps/2 style keyboard that you like, say because it has a
nice feel, but want it USB, there are Ardunio projects on github that
implement a ps/2 to USB converter that work just fine.  You may also
still find converters for sale.


I will assume that NetBSD would talk to these?
Else they would not work ...


No one has answered this directly, but yes, they work fine.

I've got a CODE keyboard from WASD keyboards with 'clear' keyswitches 
that's been my daily driver for nearly 10 years now.  As far as the OS 
is concerned, it's just a USB keyboard, like any other.


If you were asking about the PS/2->USB adaptors or the Arduino projects, 
yeah those work too, the entire point of them is to convert the 
signalling into what the computer expects from a USB keyboard.


As others have mentioned, mechanical keyboards has a whole following on 
the Internet at large and can be a deep rabbit hole to dive down.


Welcome to the club. :)

You can get some in the $50 range, check Amazon (or your favorite online 
retailer) for "mechanical keyboard" and read the reviews for decent 
ones.  Once you get into it, and you start to recognize the brands of 
not just the keyboards, but the switches used in the keyboards, you'll 
find that you can easily spend in excess of $1-200 on a good keyboard.  
Might even find that you get a smaller portable mechanical keyboard to 
take with you when you travel so you can use a "real" keyboard instead 
of the one on your laptop.  Like I said, deep, deep hole.


--
Michael Parson
Pflugerville, TX

Re: Keyboards

[Michael]

Hello,

On Fri, 19 Jan 2024 15:53:28 +
Todd Gruhn  wrote:

> Ump-teen years ago there was an analog-keyboard.
> It actually when 'click' when one pressed the key.
> 
> Do these still exist??
> Do they last longer then the current keyboards?

I'm still using an IBM model M from 1993. Bought it for about 10 bucks
on a flea market in Berlin in the early 2000s.
These things are practically indestructible.

have fun
Michael

Re: WireGuard setup in NetBSD 10

[Michael van Elst]

k...@krot.org (Kirill Miazine) writes:

>> Maybe he still has auto_ifconfig=NO ?

>no, he didn't... but issue was if_wg not being loaded upon boot -- but
>loaded when ifconfig wg0 create was called.

The perils of the module autoloader.

Re: WireGuard setup in NetBSD 10

[Michael van Elst]

mar...@duskware.de (Martin Husemann) writes:

>On Thu, Jan 18, 2024 at 10:23:11AM +0100, Kirill Miazine wrote:
>> Does your custom kernel provide some wg devices initially?

>No, but "ifconfig -C" lists wg as a clonable device, so /etc/ifconfig.wg0
>is loaded.

Maybe he still has auto_ifconfig=NO ?

Re: Network and port redirection with QEMU not working with package compiled on 10.0_RC1

[Michael van Elst]

baba...@babafou.eu.org (Marc Baudoin) writes:

>Has anybody got a working QEMU (at least network-wise) compiled
>on NetBSD 10.0_RC[12]?

No problems here, neither with qemu-8.1.0 (2023Q3) nor qemu-8.1.3 (2023Q4):

Host:
NetBSD tazz 10.99.10 NetBSD 10.99.10 (TAZZ) #311: Sun Dec 24 15:24:24 UTC 2023  
mlelstv@slowpoke:/scratch2/obj.amd64/scratch/netbsd-current/src/sys/arch/amd64/compile/TAZZ
 amd64

Guest:
NetBSD standalone 10.99.5 NetBSD 10.99.5 (GENERIC) #0: Sun Jul  9 00:01:55 UTC 
2023  mkre...@mkrepro.netbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC amd64

configured with:

-netdev user,id=n1
-device virtio-net,netdev=n1

Re: Prob using CPIO

[Michael van Elst]

tgru...@gmail.com (Todd Gruhn) writes:

>I zip up much  music:

>   find . -depth -print | cpio -ov > file.cpio

>To unzip it , I must undo *cpio severa times severa times:

>   cpio -iv < file.cpio

Your 'zip' packs the local directory including the cpio file that
is being created. You don't have to cpio several times to unpack,
but the data (most likely) exists twice in the archive.


>Am I messing this up somehow? The *.cpio file is about 250MB...

Yes, don't include the resulting cpio file, easiest by writing
it to a separate directory.

Re: After -10 patch that fixes kern/57669

[Michael van Elst]

joel.bertr...@systella.fr (=?UTF-8?Q?BERTRAND_Jo=c3=abl?=) writes:

>   I have seen Michael has applied patch to fix ccb_timout to -10 kernel.
>Thus, I have rebuilt my tree to have a unpatched kernel and I cannot now
>access to my NAS over iSCSI. Of course, I have reinstalled kernel /and/
>userland.

>   In dmesg, I only obtain :

>[71,854636] Invalid socket 7


Looks like there is a bug with the default port number.

Quick workaround is to specify the target with port number
like 1.2.3.4:3260.

Re: Are The Packages Gone Again?

[Michael van Elst]

j...@m5.chicago.il.us ("Jay F. Shachter") writes:

>I was able to reinstall ghostscript (as I stated).  The others --
>ImageMagick6, atril, gv, libspectre and okular -- are gone.

At least there was no problem to build them.

-rw-r--r--  1 root  wheel  11102472 Sep 29 14:25 
final-amd64-10.0-2023Q3/All/ImageMagick6-6.9.12.91.tgz
-rw-r--r--  1 root  wheel   4430189 Sep 29 18:01 
final-amd64-10.0-2023Q3/All/atril-1.26.1nb1.tgz
-rw-r--r--  1 root  wheel220628 Sep 29 17:37 
final-amd64-10.0-2023Q3/All/gv-3.7.4nb12.tgz
-rw-r--r--  1 root  wheel 71680 Sep 29 13:50 
final-amd64-10.0-2023Q3/All/libspectre-0.2.9nb2.tgz
-rw-r--r--  1 root  wheel   9531552 Sep 30 00:34 
final-amd64-10.0-2023Q3/All/okular-23.04.3.tgz

Re: Are The Packages Gone Again?

[Michael van Elst]

j...@m5.chicago.il.us ("Jay F. Shachter") writes:

>Are the NetBSD 10 packages gone again?  I recently removed ghostscript
>with the intention of re-installing it (gs was complaining that there
>was no libtiff.so, which is preposterous, because there was, but I
>didn't want to argue with it).

Can't tell why they are gone. My last private bulk build yielded:

-rw-r--r--  1 root  wheel  1390 Sep 29 07:47 
final-amd64-10.0-2023Q3/All/ghostscript-9.05nb31.tgz
-rw-r--r--  1 root  wheel  23276644 Sep 29 07:47 
final-amd64-10.0-2023Q3/All/ghostscript-agpl-10.01.2.tgz
-rw-r--r--  1 root  wheel  5460 Sep 30 01:12 
final-amd64-10.0-2023Q3/All/ghostscript-cidfonts-2901nb6.tgz
-rw-r--r--  1 root  wheel  5456 Sep 30 14:37 
final-amd64-10.0-2023Q3/All/ghostscript-cmaps-20020913nb3.tgz
-rw-r--r--  1 root  wheel827591 Sep 29 07:30 
final-amd64-10.0-2023Q3/All/ghostscript-fonts-8.11nb3.tgz
-rw-r--r--  1 root  wheel  14937225 Sep 30 04:45 
final-amd64-10.0-2023Q3/All/ghostscript-gpl-9.06nb47.tgz

Re: iscsid - lfs and ipv6 issues

[Michael van Elst]

On Sun, Nov 19, 2023 at 12:34:13PM +0100, Ede Wolf wrote:
> Hello,
> 
> first of all a very big thanks to all of you. Since it seems I am the only
> one who is using ipv6 with iscsi, I do not need a fix. I can live (as I am
> doing now) with ipv4.
> I just know I do not have to waste any time in trying to figure out the
> syntax.

I think I've fixed IPv6 handling now (needs patches to iscsictl and
iscsid), at least it works here.


> Secondly: The iscsi target is ctld on FreeBSD. Currently even without any
> authentication.
> Now I doubt that an offline reporting is the case, because, relabelling the
> lun to 4.2BSD and mounting it with ffs does work. Without anything else
> being done on either side.

I can currently only test against istgt (from pkgsrc) on NetBSD and
a qnap NAS.

The error message (ENODEV) is only generated by LFS on failures to mount
a root filesystem. So no idea yet what error is triggered.

On the other hand, attempting to use LFS showed errors with handling
block sizes and running the filesystem tester (fsx) somewhen paniced
the system. Whatever was "fixed" in LFS was not good enough :-/



Greetings,
-- 
Michael van Elst
Internet: mlel...@serpens.de
"A potential Snark may lurk in every tree."

Re: CGD - unable to open after closing, using '-V gpt', argon2id and adiantum

[Michael van Elst]

luisvmen...@yandex.com (Luis Mendes) writes:

>== Now, trying to open the container again:
>cgdconfig -V gpt cgd0 NAME=nvme-crypt /etc/cgd/nvme-crypt
>After entering the four zeroes password, there's the message:
>"cgdconfig: verification failed, please reenter passphrase".

>What is wrong with this setup?

This way cgdconfig is looking inside the container for a GPT
label for validation. Did you create one ?

If you don't need to partition the container, you could
format a ffs filesystem for the whole disk (cgd0) and use
the 'ffs' verification method, which checks for a ffs 
superblock.

For other filesystems you need to partition (disklabel, mbr
or gpt) if you want the validation step and validate using
the partition information. But it's not strictly necessary to
validate, -V none will accept a wrong passphrase but e.g.
a mount will likely see garbage and fail.

Re: iscsid - lfs and ipv6 issues

[Michael van Elst]

On Sat, Nov 18, 2023 at 07:47:47PM +0700, Robert Elz wrote:
> 
> Using getaddrinfo() would be much better of course.

That's what I have now


-- 
    Michael van Elst
Internet: mlel...@serpens.de
"A potential Snark may lurk in every tree."

Re: iscsid - lfs and ipv6 issues

[Michael van Elst]

k...@munnari.oz.au (Robert Elz) writes:

>That looks to me as if it should work, and is a lot cleaner, though
>I doubt there's a great need to remove the [] if they were given.

getaddrinfo() doesn't strip or handle brackets.

Re: iscsid - lfs and ipv6 issues

[Michael van Elst]

k...@munnari.oz.au (Robert Elz) writes:

>  | The address parser looks broken.
>It certainly is, it is horrid.

>and the relevant function is get_address()

Maybe the patch below. It's still a bit naive (you can bracket anything,
not just ipv6 literals).

The address string is later used in iscsid_driverif.c, a name
is resolved with gethostbyname(), so while an ipv6 address might
be accepted, the code lacks ipv6 support.


Index: sbin/iscsictl/iscsic_parse.c
===
RCS file: /cvsroot/src/sbin/iscsictl/iscsic_parse.c,v
retrieving revision 1.4
diff -p -u -r1.4 iscsic_parse.c
--- sbin/iscsictl/iscsic_parse.c3 Dec 2021 13:27:38 -   1.4
+++ sbin/iscsictl/iscsic_parse.c18 Nov 2023 10:35:17 -
@@ -48,50 +48,55 @@
 STATIC void
 get_address(iscsi_portal_address_t * portal, char *str, char *arg)
 {
-   char *sp, *sp2;
+   char *sp;
int val;
 
if (!str || !*str)
arg_error(arg, "Address is missing");
 
-   /* is there a port? don't check inside square brackets (IPv6 addr) */
-   for (sp = str + 1, val = 0; *sp && (*sp != ':' || val); sp++) {
-   if (*sp == '[')
-   val = 1;
-   else if (*sp == ']')
-   val = 0;
-   }
-
-   /* */
-   if (*sp) {
-   for (sp2 = sp + 1; *sp2 && *sp2 != ':'; sp2++);
-   /* if there's a second colon, assume it's an unbracketed IPv6 
address */
-   if (!*sp2) {
-   /* truncate source, that's the address */
-   *sp++ = '\0';
-   if (sscanf(sp, "%d", ) != 1)
-   arg_error(arg, "Bad address format: Expected 
port number");
-   if (val < 0 || val > 0x)
-   arg_error(arg, "Bad address format: Port number 
out of range");
-   portal->port = (uint16_t) val;
-   }
-   /* is there a group tag? */
-   for (; isdigit((unsigned char)*sp); sp++);
-   if (*sp && *sp != ',')
-   arg_error(arg, "Bad address format: Extra character(s) 
'%c'", *sp);
-   } else
-   for (sp = str + 1; *sp && *sp != ','; sp++);
-
-   if (*sp) {
+   /* parse and strip trailing group tag */
+   sp = strchr(str, ',');
+   if (sp != NULL) {
if (sscanf(sp + 1, "%d", ) != 1)
arg_error(arg, "Bad address format: Expected group 
tag");
if (val < 0 || val > 0x)
arg_error(arg, "Bad address format: Group tag out of 
range");
portal->group_tag = (uint16_t) val;
-   /* truncate source, that's the address */
*sp = '\0';
}
-   /* only check length, don't verify correct format (too many 
possibilities) */
+
+   /* parse and strip trailing port number */
+   sp = strchr(str, ':');
+   if (sp != NULL) {
+   if (strchr(sp + 1, ':') != NULL) {
+   /*
+* if there's a second colon, assume
+* it's an unbracketed IPv6 address.
+*/
+   portal->port = 0;
+   } else {
+   if (sscanf(sp + 1, "%d", ) != 1)
+   arg_error(arg, "Bad address format: Expected 
port number");
+   if (val < 0 || val > 0x)
+   arg_error(arg, "Bad address format: Port number 
out of range");
+   portal->port = (uint16_t) val;
+   *sp = '\0';
+   }
+   }
+
+   /* remove brackets */
+   if (*str == '[') {
+   sp = strchr(str, ']');
+   if (sp != NULL && !*(sp+1)) {
+   str = str + 1;
+   *sp = '\0';
+   }
+   }
+
+   /*
+* only check length, don't verify correct format
+* (too many possibilities)
+*/
if (strlen(str) >= sizeof(portal->address))
arg_error(arg, "Bad address format: Address string too long");
 

Re: iscsid - lfs and ipv6 issues

[Michael van Elst]

lis...@nebelschwaden.de (Ede Wolf) writes:

>I am having two issues with iscsid/iscsictl. First, it seems, I cannot 
>mount an lfs formatted iscsi lun, no matter wether this drive is 
>gpt/wedge or plain disklabelled:

># mount -t lfs /dev/dk0 /import/
>mount_lfs: /dev/dk0 on /import: Operation not supported by device

This works here (as far as lfs works), but the error message is
rare. One possibility is that the SCSI driver reports an offline
unit. Can you tell what the iSCSI server is ?

>scsictl: add_send_target: Invalid option at or near '-a': Bad address 
>format: Extra character(s) ':'

The address parser looks broken. For some reason the first character is skipped 
when it tries to identify IPv6, I was successful with

iscsictl add_send_target -a 'x[ipv6-address]'


Greetings,

Re: rc.local nightmare

[Michael van Elst]

ea1...@gmail.com (Ramiro Aceves) writes:

>My script says on the console "Network connectivity to $TARGET is OK." 
>several times before the script dies. So ping works fine. (I have set 
>INTERVAL=3 seconds just to speed things up during testing.


Your script shouldn't create output from a background process.
When booting, output is piped through a logging process, and when
that exits, the next output will abort your process.

nohup doesn't help, it only redirects terminal output.

Ideally you should not print anything directly in a background
process but write a log file (or use logger / syslog).

To avoid any accidential problem, you should also redirect all
three standard handles (e.g. to /dev/null).

N.B. the connectivity check is a bit sensitive. I suggest to
probe with more than 1 packet and to also set a deadline (-w)
which allows for one extra second, e.g. ping -n -c 3 -w 4.

Re: NetBSD 10 Beta: Updating The Base System

[Michael van Elst]

On Tue, Oct 10, 2023 at 11:24:15AM -0500, Jay F. Shachter wrote:

> Please forgive my ignorance; how do I update my NetBSD 10 Beta system?

You can run sysinst to fetch sets from

http://cdn.netbsd.org/pub/NetBSD-daily/netbsd-10/latest/amd64/

or download the sets and unpack them manually.

There is also the sysupgrade tool in pkgsrc, but I never have used it.


> And does my PKG_PATH variable remain
> http://ftp.NetBSD.org/pub/pkgsrc/packages/NetBSD/amd64/10.0/All or
> do I now change it to something else?  Thank you in advance for any
> and all replies.

The path stays the same.


Greetings,
-- 
    Michael van Elst
Internet: mlel...@serpens.de
"A potential Snark may lurk in every tree."

Re: Bluetooth status, compatible USB Bluetooth adapters?

[Michael van Elst]

dyo...@pobox.com (David Young) writes:

>By the way, to interoperate with Bluetooth Low Energy devices, is
>anything beyond a compatible USB Bluetooth adapter needed?  For example,
>kernel or utility changes?

So far we don't support BLE at all. Devices that talk only BLE cannot be
used.

My Logitech mouse is BLE only, fortunately it comes with a dongle that
makes it appear as a regular (wired) USB mouse.

Re: Where are the 10.0 packages?

[Michael van Elst]

j...@m5.chicago.il.us ("Jay F. Shachter") writes:

>system a dhcp client of the other laptop), and I cannot, because the
>packages are no longer at
>http://ftp.NetBSD.org/pub/pkgsrc/packages/NetBSD/amd64/10.0/All where
>they used to be.

netbsd-10 got a second flag day, first when updating openssl, second
when bumping versions of dependent libraries.

The packages are being rebuilt and you should also update the base
system.

Re: UEFI installation

[Michael van Elst]

g...@lexort.com (Greg Troxel) writes:

>For the EFI partition, what are the rules?  It seems like

>  the size is at least X and less than Y

100MB is the minimum, some systems reject smaller EFI partitions.

It also should be FAT32.

Re: ZFS Bogosity

[Michael van Elst]

On Mon, Aug 14, 2023 at 07:50:01AM -0400, Greg Troxel wrote:
> 
> In this case, wedges show up as logical disks in hw.disknames, so it's
> really that partitions aren't disks.

Indeed, partitions are disks and wedges appear as a disk that doesn't
support partitions.


> > You can avoid this by ignoring and phasing out disklabel
> > partitions (which only work for "small" disks anyway) and use wedges
> > also to handle the bsd disklabel.
> 
> Do you mean "create dkN entries from the disklabel"?  That doesn't
> happen by default.

You have to set a kernel option. Since changing behaviour is a flag day,
it never happened (actually it happened and was reverted immediately).


> I still use disklabels on disks that are <= 2T, and I don't see that as
> really odd.

It's odd to treat disks differently, i.e. small disks with "physical"
driver names and a partition suffix, large disks with a name (or
an UUID as unique default name).

Make small disks using wedges, indepenent of disklabel or GPT, would
unify both.


> > Makeing zfs scan disklabel partitions derived from hw.disknames seems
> > to be the easier method though.
> 
> Yes, that seems not to have any real downsides and would make it behave
> as expected.

SMOP

-- 
Michael van Elst
Internet: mlel...@serpens.de
"A potential Snark may lurk in every tree."

Re: ZFS Bogosity

[Michael van Elst]

On Sun, Aug 13, 2023 at 08:22:08PM -0400, Greg Troxel wrote:
> 
> Given that wd3e is a name for a disk special file with defined size, it
> would seem that we should change that.  It seems to make just as much
> sense to probe wd3[a-p] as it does to probe wd3 (which is wd3d).

You can change the code to scan partitions instead. It gets a bit
more complicated, if wedges are involved.


> Alternatively, I see that we add wedges to hw.disknames. My system has
> a NetBSD boot image on a flash drive this minute, and:
>   hw.disknames = wd0 cd0 sd0 dk0 dk1
> so if we add dk0, which is really no different logically than sd0a, it
> seems like we should add disklabel partitions like wd3e.

The sysctl value reflects the device drivers from the autoconfig
process. It has no knowledge about disk content. This discrepancy
between disklabel partitions and wedges is maybe the largest problem
of wedges. You can avoid this by ignoring and phasing out disklabel
partitions (which only work for "small" disks anyway) and use wedges
also to handle the bsd disklabel.


> It also seems odd to special case /dev, vs using the dir if passed and
> doing hw.disknames->dev if not, but it seems best to minimally munge
> upstream.

That's an optimization to avoid scanning and probing all entries
in /dev/ which can take some time and may have unwanted side effects
when you scan non-disk devices.


> What happens on FreeBSD?  Are they so firm on gpt-only, geom and
> zfs-on-whole disk that this doesn't come up?  It seems obvious that
> people easing into zfs are going to use partial disks, if only as
>   / sw /usr on ffs, and
>   rest as sole storage for a pool
> .

For ZFS it rarely makes sense to use partitions. You need this as
a workaround to allow bootstrap without ZFS support in the boot
process, and you need it to exchange media with other systems
that use the partition table as identifier (but who uses disklabel?).


> 
> > You can also cache devices, then the pool devices are just used as
> > stored in the cache instead of scanning all disks for labels. But
> > that doesn't work nicely with wedges or anything else with changing
> > device units.
> 
> I found that my single pool tank0 with a single component wd0f has a
> cache file in /etc/zfs/zpool.cache.   But that seems not a general
> solution for import.

That is the general solution of ZFS to avoid the time consuming scanning
of /dev/ at startup, and you could arrange disk devices into something
like /dev/disk to avoid side effects on non-disk devices You see,
it's a design for something else.

Or you could arrange for "volume labels" to be visible in the filesystem
(e.g. use devpubd to create symlinks for wedges, or invent a device
filesystem that is filled by the kernel) and let zfs scan these.


Makeing zfs scan disklabel partitions derived from hw.disknames seems
to be the easier method though.



Greetings,
-- 
Michael van Elst
Internet: mlel...@serpens.de
"A potential Snark may lurk in every tree."

Re: ZFS Bogosity

[Michael van Elst]

g...@lexort.com (Greg Troxel) writes:

>David Brownlee  writes:
>> https://gnats.netbsd.org/57583

>Do you think this is just a bug that  it fails to look at wd3e
>etc. wrongly if there is /dev/zfs?

The code scans all devices in the specified device directory, unless
it's /dev/. Then it uses sysctl hw.disknames to enumerate disk devices,
and it doesn't care about disklabel partitions.

You can also cache devices, then the pool devices are just used as
stored in the cache instead of scanning all disks for labels. But
that doesn't work nicely with wedges or anything else with changing
device units.

Re: would anybody use binary packages for NetBSD/i386 10?

[Michael van Elst]

g...@lexort.com (Greg Troxel) writes:

>it was underpowered, that I might or might not ever power up again, and
>if I did I wouldn't use ftp.n.o packages on it.

What else? Self-compiling on a system you already consider outdated? :)

Binary packages are more important on systems that we consider old,
doesn't have to be a VAX.

Re: NetBSD 10 BETA successfully installed, does not recognize my wireless network device

[Michael van Elst]

j...@m5.chicago.il.us ("Jay F. Shachter") writes:

>else.  According to the output that I obtain when I boot my computer
>into OpenBSD and invoke the "pcidump -v" command -- and I have to
>engage in this roundabout procedure because I do not see a pcidump
>command, or anything resembling it, on my NetBSD system

It's something like
pcictl pci0 list

Detailed information with
pcictl pci0 dump 
plus parameters to specify which device.


>-- my wireless
>network device is a Broadcom BCM4313, Vendor ID 14e4, Product ID 4727.

I fear there is no driver for that chip. FreeBSD might have support for
it in the bwn driver, but that won't help you.

For Wifi you probably need something like an USB dongle, something like
an Edimax EW-7811Un should work. Since NetBSD so far only supports
802.11a/b/g, you also need to make sure that your WiFi (accesspoint/router)
has this enabled (it usually has).

Re: Network interface slowness

[Michael van Elst]

joel.bertr...@systella.fr (=?UTF-8?Q?BERTRAND_Jo=c3=abl?=) writes:

>CISCO FTTH adapter
>   ||
>   ||
>netbsdLinux
>   |
>   |
>  lan

>On NetBSD (-10) or workstations on LAN:
>- 400 Mbps downlink;
>- 4 (!) Mbps uplink, yes, 4 Mbps.


What happens when you unplug one of the lagg0 legs ?

Re: zfs pool behavior - is it ever freed?

[Michael van Elst]

g...@lexort.com (Greg Troxel) writes:

>mlel...@serpens.de (Michael van Elst) writes:

>> t...@netbsd.org (Tobias Nygren) writes:
>>
>>>There exists ZFS code which hooks into UVM to drain memory -- but part
>>>of it is ifdef __i386 for some reason. See arc_kmem_reap_now().
>>
>> That's an extra for 32bit systems (later code replaced __i386 with
>> the proper macro) where kernel address space is much smaller.

>Sure, but I don't see why it shouldn't always be hooked up.

It might have negative effects, as its used to reduce non-zfs-related
pools. The zfs-related-pools are freed in any case.

I think our problem is that the vcache doesn't get enough pressure.
For FreeBSD you will find the dnlc_reduce_cache() function in arc.c
that (in a separate thread) reduces metadata held by the kernel so that
buffers actually get unreferenced and can be freed afterwards.

We do have the vdrain_thread() that tries to keep cached vnodes
(and associated metadata) below the 'desiredvnodes' value. That
value however doesn't change under memory pressure. You can manually
change the value (as kern.maxvnodes) to get an immediate effect
(for e.g. UFS).

For ZFS however that apparently isn't enough. I can shrink the
vcache, but the ZFS buffers seem to be unaffected.

Re: zfs pool behavior - is it ever freed?

[Michael van Elst]

t...@netbsd.org (Tobias Nygren) writes:

>There exists ZFS code which hooks into UVM to drain memory -- but part
>of it is ifdef __i386 for some reason. See arc_kmem_reap_now().

That's an extra for 32bit systems (later code replaced __i386 with
the proper macro) where kernel address space is much smaller.

Re: zfs pool behavior - is it ever freed?

[Michael van Elst]

On Fri, Jul 28, 2023 at 12:26:57PM -0400, Greg Troxel wrote:
> mlel...@serpens.de (Michael van Elst) writes:
> 
> > g...@lexort.com (Greg Troxel) writes:
> >
> >>I'm not either, but if there is a precise description/code of what they
> >>did, that lowers the barrier to us stealing* it.  (* There is of course
> >>a long tradition of improvements from various *BSD being applied to
> >>others.)
> >
> > The FreeBSD code is already there and I have exposed a few settings:
> >
> > vfs.zfs_arc.meta_limit = 0
> > vfs.zfs_arc.meta_min = 0
> > vfs.zfs_arc.shrink_shift = 0
> > vfs.zfs_arc.max = 5292193280
> > vfs.zfs_arc.min = 661524160
> > vfs.zfs_arc.compressed = 1
> >
> > but that's not enough to control the behaviour.
> 
> Is that in current only?   I don't see that in netbsd-10.


Only in my local tree.


-- 
Michael van Elst
Internet: mlel...@serpens.de
"A potential Snark may lurk in every tree."

Re: zfs pool behavior - is it ever freed?

[Michael van Elst]

g...@lexort.com (Greg Troxel) writes:

>I'm not either, but if there is a precise description/code of what they
>did, that lowers the barrier to us stealing* it.  (* There is of course
>a long tradition of improvements from various *BSD being applied to
>others.)

The FreeBSD code is already there and I have exposed a few settings:

vfs.zfs_arc.meta_limit = 0
vfs.zfs_arc.meta_min = 0
vfs.zfs_arc.shrink_shift = 0
vfs.zfs_arc.max = 5292193280
vfs.zfs_arc.min = 661524160
vfs.zfs_arc.compressed = 1

but that's not enough to control the behaviour.

Re: zfs pool behavior - is it ever freed?

[Michael van Elst]

On Thu, Jul 27, 2023 at 06:42:02PM +0100, Mike Pumford wrote:
> 
> Now I might be reading it wrong but that suggest to me that it would be an
> awful idea to run ZFS on a system that needs memory for things other than
> filesystem caching as there is no way for those memory needs to force ZFS to
> give up its pool usage.

At least not in the current incarnation. There are lots of tunables
though that are supposed to limit ZFS memory usage, but so far we do
not expose these (FreeBSD does).


-- 
    Michael van Elst
Internet: mlel...@serpens.de
"A potential Snark may lurk in every tree."

Re: zfs pool behavior - is it ever freed?

[Michael van Elst]

g...@lexort.com (Greg Troxel) writes:

>  RAM and/or responds to pressure.  That's why we see almost no reports
>  of trouble expect for zfs.


There is almost no pressure on pools and several effects prevent
pressure from actually draining pool caches.

There is almost no pressure on vcache and the ZFS equivalents. Impact
by ZFS is much higher, because of the amount of memory locked up
this way. These data structures are significant as these actually
reference other data structures and buffers.

Swapping out userland pages is done much earlier, so with high ZFS
utilization you end with a system that has a huge part of real memory
allocated to the kernel. When you run out of swap (and processes
already get killed), then you see some effects on kernel data.

./build.sh -O ../obj tools producing error

[Michael Cheponis]

Hi, fresh download; /usr/src nonexistent, /usr/obj nonexistent


# cd /usr
# cvs checkout -A -P src
# cd src
# ./build.sh -O ../obj tools

gives me:

<< stuff  >>
cc -o nbmake arch.o buf.o compat.o cond.o dir.o for.o hash.o job.o lst.o
main.o make.o make_malloc.o meta.o metachar.o parse.o str.o suff.o targ.o
trace.o util.o var.o
ld: job.o: in function `JobPassSig_suspend':
job.c:(.text+0xd04): undefined reference to `__sigaction_siginfo'
job.c:(.text+0xd04): relocation truncated to fit: R_AARCH64_CALL26 against
undefined symbol `__sigaction_siginfo'
ld: job.c:(.text+0xd38): undefined reference to `__sigaction_siginfo'
job.c:(.text+0xd38): relocation truncated to fit: R_AARCH64_CALL26 against
undefined symbol `__sigaction_siginfo'
ld: util.o: in function `bmake_signal':
util.c:(.text+0x2c): undefined reference to `__sigaction_siginfo'
util.c:(.text+0x2c): relocation truncated to fit: R_AARCH64_CALL26 against
undefined symbol `__sigaction_siginfo'

ERROR: Build of nbmake failed


$ uname -a
NetBSD arm64 10.99.4 NetBSD 10.99.4 (MIKE64) #0: Wed May 24 16:54:43 UTC
2023  mac@arm64:/usr/obj/sys/arch/evbarm/compile/MIKE64 evbarm

(MIKE64's only diff from GENERIC is "options HZ=1000")


Thanks for any clues as to what bonehead thing I may be doing (or not
doing...)


Mike

Re: NetBSD & disks with 4K sector size

[Michael van Elst]

g...@lexort.com (Greg Troxel) writes:

>mlel...@serpens.de (Michael van Elst) writes:
>> The xbd driver lies about the sector size and always reports 512byte
>> sectors. If you pass through a 4k sector host disk, this make some
>> I/O operations fail.

>What do you suggest we do?

I suggested to make it tell the truth, all data is provided by the
backend. Then it just works like other drivers.

Re: NetBSD & disks with 4K sector size

[Michael van Elst]

g...@lexort.com (Greg Troxel) writes:

>With any luck, this is supported and the xbd driver in NetBSD is just
>not noticing the sector size variable and it's a fairly small matter of
>programming.

The xbd driver lies about the sector size and always reports 512byte
sectors. If you pass through a 4k sector host disk, this make some
I/O operations fail.

Re: NetBSD & disks with 4K sector size

[Michael van Elst]

li...@nerdbynature.de (Christian Kujau) writes:

>So, my question is: does NetBSD work with 4k sector size disks? I found 
>two[1][2] threads from 11 years ago, but nothing conclusive and with 
>somewhat conflicting[3][4] information.


The NetBSD Xen PV xbd device lies about sector sizes so that you can
pretend that you can copy images between disks with different
sector sizes.

Re: bioctl cosmetic issue

[Michael van Elst]

j...@ziaspace.com (John Klos) writes:

>[ 1.033007] mfii0 at pci1 dev 0 function 0: "LSI MegaRAID SAS 9271-4i", 
>firmware 23.34.0-0019, 1024MB cache

>Where is bioctl supposed to get the sector size?

bioctl prints a struct bioc_vol which has the volume size in bytes.

The calculation is done by the particular driver:

mfi.c:
mfii.c:

bv->bv_size = sc->sc_ld_details.mld_size * 512; /* bytes per block */

mpt_netbsd.c:

bv->bv_size = (uint64_t)rvol0->MaxLBA * 512;

But e.g.:

mpii.c:
bv->bv_size = le64toh(vpg->max_lba) * le16toh(vpg->block_size);

Re: Call for testing: Diagnostics for broken downloads from NetBSD.org CDN

[Michael van Elst]

On Sat, Jun 17, 2023 at 08:14:20AM -0400, Greg Troxel wrote:
> mlel...@serpens.de (Michael van Elst) writes:
> > Fastly caches data in segments:
> > https://docs.fastly.com/en/guides/segmented-caching


> Is a client that writes a partial file and exits considered buggy?

May depend on the client and is sometimes a user preference.


> Or
> are users obligated to check for exit status 0 and if not rm the file?

They should always check for exit status and that is unrelated to the
problem or whether this is an CDN or just a simple web server.



Greetings,
-- 
    Michael van Elst
Internet: mlel...@serpens.de
"A potential Snark may lurk in every tree."

Re: Call for testing: Diagnostics for broken downloads from NetBSD.org CDN

[Michael van Elst]

riastr...@netbsd.org (Taylor R Campbell) writes:

>We've been hearing reports of intermittent issues with broken partial
>downloads via our content delivery network, Fastly, from
>cdn.NetBSD.org, nycdn.NetBSD.org, and/or archive.NetBSD.org,
>particularly of large files like the installer images.

Fastly caches data in segments:

https://docs.fastly.com/en/guides/segmented-caching

If some segments of a file can be fetched from the backend
and others cannot, fastly will deliver a partial file and
return an error. For a complete file all segments must have
been fetched and cached succssfully.

This can easily happen with a backend that applies a connection
rate limit. And so it does

Transparent Page Placement

[Michael Cheponis]

TPP apparently improves 'hot' data locality with a low-overhead algorithm
that has been implemented in mainstream Linux.

https://cse.engin.umich.edu/stories/new-technique-for-memory-page-placement-integrated-into-linux-kernel

Re: touch screen support

[Michael van Elst]

dty...@anduin.org.uk (Dave Tyson) writes:

>I guess these touch screens need some calibration to set the x/y bounds
>and maybe some mods to the driver. Can anyone hit me with a cluebat as
>to where to start...

There are lots touchpads that need a more relaxed interpretation of their
capabilities. The uts driver already ignores the missing Digitizer:In_Range
HID usage for Elan touchpads.

The FreeBSD driver (wmt(4)) seems to ignore it completely. I'm not
sure if that is sufficient (Linux applies a ton of quirks to the
different touch screen models).

For a start it might be sufficient to go the FreeBSD way:

Index: uts.c
===
RCS file: /cvsroot/src/sys/dev/usb/uts.c,v
retrieving revision 1.16
diff -p -u -r1.16 uts.c
--- uts.c   10 May 2023 00:12:44 -  1.16
+++ uts.c   29 May 2023 08:38:50 -
@@ -215,7 +215,7 @@ uts_attach(device_t parent, device_t sel
} else {
aprint_error_dev(sc->sc_dev,
"touchscreen has no range report\n");
-   return;
+   // return;
}
}

Re: How to use the 'ls' -M flag?

[Michael Cheponis]

Using RVP's recipes -- success!

Thank you very much, and d'oh, of course it makes sense that the default
C/POSIX locale is "" -- the most 'reasonable' default.

p.s. yes, I used  "ls -lM"  not just the -M flag.   You need -l otherwise
-M by itself is a no-op.


On Fri, May 26, 2023 at 11:50 PM RVP  wrote:

> On Fri, 26 May 2023, Michael Cheponis wrote:
>
> > I'm having no success trying to get ls to print file sizes, using the -M
> > flag.
> >
>
> The `thousands separator' char. is locale-specific. In the default C/POSIX
> locale, it is "":
>
> $ locale -c thousands_sep
> LC_NUMERIC
> $ LC_NUMERIC=C locale -c thousands_sep
> thousands_sep=""
> $ LC_NUMERIC=en_US.UTF-8 locale -k thousands_sep
> thousands_sep=","
> $ LC_NUMERIC=en_US.UTF-8 ls -lM /netbsd.GENERIC
> -rwxr-xr-x  1 root  wheel  29,529,152 May 24 13:09 /netbsd.GENERIC
> $
>
> Set some locale in ~/.profile (or ~/.xinitrc, ~/.xsession, ...). Eg.:
>
> export LANG=en_GB.UTF-8
> export LC_CTYPE=$LANG
> export LC_ALL=""
>
> -RVP
>

How to use the 'ls' -M flag?

[Michael Cheponis]

I'm having no success trying to get ls to print file sizes, using the -M
flag.


 -MModifies the -l and -s options, causing the sizes or block counts
 reported to be separated with commas (or a locale appropriate
 separator) resulting in a more readable output.  Overrides -h;
 does not override -k.







* $ ls -lM *.c-rw-r--r--  1 root  wheel5535 Aug  7  2003
cmp.c-rw-r--r--  1 root  wheel   18251 May 26 21:21 ls.c-rw-r--r--  1 root
 wheel1839 Sep  5  2016 main.c-rw-r--r--  1 root  wheel   13806 May 26
21:52 print.c-rw-r--r--  1 root  wheel5090 Aug 29  2011 util.c*

I would expect to see something like this:



*-rw-r--r--  1 root  wheel5,535 Aug  7  2003 cmp.c-rw-r--r--  1 root
 wheel   18,251 May 26 21:21 ls.c*

etc.

Thanks for any hints.

-Mike

Re: Raspberry Pi 3 and NetBSD 10.0_BETA - WiFi stops working after few hours and wonky USB keyboard

[Michael van Elst]

bbartlomiej.m...@gmail.com (Bartek Krawczyk) writes:

>> Perhaps the device is going into power saving mode and your connection 
>> terminates?

>There's "powersave off" in the ifconfig output and I've issued the 
>ifconfig bwfm0 -powersave command explicitly as well. No change.

The default in netbsd-10 and -current is to have powersave disabled.
With powersave you often see latencies of ~100ms.


>> Another thing, change the channel of the router, perhaps there's 
>> interference from others around you?

>It's not the interference - other devices near it work just fine. And 
>have been working fine for years.

RPI has a weak antenna, so "other devices" may not be a good reference.


>I'll be raising a wpa_supplicant bug 
>then. Since it's working after wpa_supplicant restart and it's rekeying 
>periodically. Interference would impact it intermittently, not 
>completely after few hours. Thanks for suggestion, though.

I'd suspect a firmware bug. I should reactivate my RPI3 for a test.

N.B. I don't see issues with a RPI0w, a RPI4 and a BPI M2 Zero
which comes with a bwfm compatible chip.

Re: Running NetBSD as qemu guest on laptop, camouflaging as host

[Michael Huff]

On Wed, Mar 22, 2023 at 3:27 AM Chavdar Ivanov  wrote:

>
> Just xrandr for me.
>
>
I don't use vmware, but for virtualbox I have "vesa 0x160" added to
/boot.cfg to the boot normally line:
menu=Boot normally:vesa 0x160;rndseed /var/db/entropy-file;boot

With that, I don't need to use xrandr and I can have a full-screen console
that uses my whole 1920x1080 monitor -without having to run X. I decided on
that by running "vesa test" from the boot prompt on startup and picking out
the resolution I wanted.

I don't see why the same idea wouldn't work on vmware but I can't try it at
the moment.

Re: Prob with my speakers

[Michael van Elst]

tgru...@gmail.com (Todd Gruhn) writes:

>Speakers where cracking a lot. I noticed that when I reboot
>NetBSD I saw some info printed.

>How to I catch this and send it in? Is it in a log I can view?


The early messages should be in /var/run/dmesg.boot.
Output from starting services is logged in /var/run/rc.log.

/var/run is tmpfs, so the data is lost after a reboot.

Some, but not all of the dmesg output is also logged in /var/log/messages.

Re: libc license

[Michael Cheponis]

I believe the font size of the printed documentation is not specified...

I liked what Perry Metzger said about BSD vs 'other' licenses: "Instead of
worrying that people are going to steal my code, with BSD, I *know* they
will!"



On Fri, Feb 10, 2023 at 10:55 AM r0ller  wrote:

> Hi All,
>
> Thanks for the clarification!
>
> Best regards,
> r0ller
>
> PS: If only the libc could be redistributed with 0BSD license, it would
> have a big impact on the embedded use cases.
>
> On 2023. 02. 10. 16:07, Greg Troxel wrote:
> > Julian Coleman  writes:
> >
> >> If you want to redistribute libc, you need to provide some way to
> display
> >> the licences for every libc source file as part of the documentation for
> >> the embedded device.
> >
> > I think it is acceptable to ship the device with a paper license.  There
> > is no requirement that the device itself has to do the display.
> > This license was written back in the days when you'd get a tape and a
> > document explaining it.
> >
>

Re: Keeping NetBSD disklabel up to date

[Michael van Elst]

wolfg...@solfrank.net (Wolfgang Solfrank) writes:

>> Or you can run mbrlabel (without -w) and replace the previous entries
>> accordingly.

>No, without -w, mbrlabel will just print out the modified disklabel,
>but will neither change the in-core label nor the one on disk.

Indeed. you print the modified label and you then modify the entries
(with disklabel -e or similar).

Re: Keeping NetBSD disklabel up to date

[Michael van Elst]

bea...@sdf.org writes:

>So it sounds like mbrlabel by itself would not have been sufficient for
>avoiding this scenario; it's output still needs to be applied via the
>disklabel tool; is that correct?

Yes.


> I'm sort of surprised as the mbrlabel(8)
>manpage says

>  "mbrlabel is used to update a NetBSD disk label from the Master Boot
>   Record (MBR) label and Extended Boot Record (EBR) label(s) found on
>   disks that were previously used on DOS/Windows systems (or other MBR
>   using sys tems)."

>Perhaps it's grammatically correct but not literally correct -- it is
>used to update the disklabel but doesn't actually do it itself?

mbrlabel does the following:

- read the current disklabel from disk
- enumerate the MBR partitions, for each partition
  - ignore if a disklabel entry with the same offset and size exists.
  - ignore if a disklabel entry exists that overlaps
  - otherwise add a corresponding disklabel entry
- with -w option, write back the modified disklabel to disk

So the best thing that can happen is that the modified partitions
are appended. But usually it will just clash with with a previous
entry.

You can remove the previous disklabel entries for the non-NetBSD
partitions, and then run mbrlabel -w to append the new entries.

Or you can run mbrlabel (without -w) and replace the previous entries
accordingly.



>Regarding the GPT scheme as a possibility I'll have to get educated
>on that but perhaps it's the better way to go since I'm goning to
>have to start over with this disc anyway.  I had it in my head that
>GPT was a 64bit only option.

GPT is something that is understood by Linux and NetBSD, so there
cannot be any confusion, no need to synchronize the view between
both sides.

But it is also a change. You need a new bootloader that supports GPT
for both systems, GAG is too old for this. With NetBSD you also
get a new scheme to access the disk using "wedges".

Re: Keeping NetBSD disklabel up to date

[Michael van Elst]

bea...@sdf.org (beaker) writes:

>Is it safe and sufficient to run 'mbrlabel -fw ' on NetBSD
>whenever there has been partition resizing (usually via Gpartd)
>such that the disklabel no longer reflects the current partitioning
>state?

mbrlabel creates disklabel entries for MBR partition entries, nothing
generic. It also won't move any data.


>System in question is an old 32bit i386 with an MBR partition scheme
>on a SATA disc hosting several Linux partitions and one NetBSD FFS2
>partition.  Bootloader is GAG, not GRUB nor native NetBSD bootloader.

If you only change the Linux partitions, you can use mbrlabel
(without -w) to print the necessary disklabel entries. mbrlabel
doesn't know how to delete or modify existing entries, so you need
to do that and use the mbrlabel output as a template.

If you want to modify or even resize the NetBSD partitions, it gets
much more complicated. A save approach is to boot from an alternate
installation (Live- or Installation-CD), backup the partitions,
modify them accordingly and restore the partition content from
the backup. You may also have to reinstall the bootloader.

Re: FFSv2ea

[Michael van Elst]

clays.sh...@sdf.org (Clay Daniels) writes:

>If I try this:    #gpt show wd0
>I get this:        GPT part - NetBSD FFSv1/FFSv2

>Then the next installation I deliberately used the default of FFSv2, I 
>get the same thing. I'm sure I must be expecting the gpt command to do 
>more than it really does. What other commands shows the fast file system 
>in use?

gpt shows the entry in the partition table, there is only one type value
for NetBSD FFS which is independent of version.

To see details about FFS you can use the dumpfs tool as in:

   dumpfs -s /dev/...
or
   dumpfs -s /mount/point

e.g.:

# dumpfs -s /
file system: /dev/rdk3
format  FFSv2
endian  little-endian
...

# dumpfs -s /dev/vnd0a
file system: /dev/vnd0a
format  FFSv2ea
endian  little-endian
...

Re: Is this normal floppy behavior?

[Michael Cheponis]

>   It could also be that some program is still running which has a file in
> /a open. That would also explain why the space is still shown as
> allocated.

No other files were open; it was preceded by an "*rm -rf /a/**" cmd.

But even after doing that, umounting it, and re-mounting it,  I find:











*# pwd/root# umount /a# mount_msdos /dev/sd2a /a# df -h /aFilesystem
  Size   Used  Avail %Cap Mounted on/dev/sd2a  1.4M
 31K   1.4M   2% /a# ls -la /a total 1drwxr-xr-x   1 root  wheel  7168
Jan  1  1980 ./drwxr-xr-x  32 root  wheel  1024 Dec 29 02:38 ../*
Hmmm, somehow 31K are still used.   Used for what?   Now, I know that on
some filesystems, there is some 'hidden' disk space, which only root can
access.

Back in windows, 32,256 bytes (63 sectors) are seen to be 'used' - but
there are no files.

Is NetBSD 'reserving' some sectors for some reason?   (As I say, normally
after formatting, windows only marks sectors 'used' that are bad; and this
particular diskette has 2 bad sectors (1,024 bytes)).  Reformatting on
Windows gives the 1,024 'used' bytes, and 1,456,640 'available' bytes, a
capacity of 1,457,664 bytes.   Now, the entire disk is 2880 sectors of 512
bytes each, hence 1,474,560 bytes; so the Directory uses 1,474,560 -
1,457,664 =16,896 bytes, or 33 sectors.

Back on NetBSD, I get this oddness:




*# mount_msdos /dev/sd2a /a  mount_msdos: /dev/sd2a on /a: Operation not
supported by device# mount_msdos /dev/sd2a /a  *
*#*

OK, no big deal, but not sure why -- after a successful umount previously
and ejection of the diskette -- that the error message is generated upon a
new mount.


*# df -h /a*







*Filesystem Size   Used  Avail %Cap Mounted on/dev/sd2a
 1.4M   1.0K   1.4M   0% /aarm64# ls -la /a total 1drwxr-xr-x
1 root  wheel  7168 Jan  1  1980 ./drwxr-xr-x  32 root  wheel  1024 Dec 29
02:38 ../drwxr-xr-x   1 root  wheel   512 Jan  5 14:19 System Volume
Information/#  ls -la /a/System\ Volume\ Information *

*total 1-rwxr-xr-x  1 root  wheel  76 Jan  5 14:19 IndexerVolumeGuid**

This all looks reasonable, except perhaps the 1.0K 'Used' field.   (1K is
bad blocks; and the IndexerVolumeGuid is only 76 bytes, which would consume
1 sector of 512 bytes, therefore the 'Used' should presumably be "1,5K" ?)

*# df -G /a *





*/a (/dev/sd2a   ): 512 block size  512 frag size
2847 total blocks   2845 free blocks2845 available 0
total files 224 free files 1810 filesys id msdos fstype
  0x1000 flag255 filename length 0 owner
  0 syncwrites0 asyncwrites*
There are 2880 total sectors, and the directory uses 33 sectors, meaning
the max# of available sectors is 2847, as is reported.  2 sectors are bad,
hence 2845 actual free blocks.

But:  Where is *System Volume Information/**IndexerVolumeGuid *stored?

Writing the biggest possible file (given there are 2 bad sectors):






*# dd if=/dev/urandom of=big bs=1456640 count=1 1+0 records in1+0 records
out1456640 bytes transferred in 0.063 secs (23121269 bytes/sec)# time cp
big /a cp -pi big /a  0.00s user 0.01s system 0% cpu 14.627 total*

Clearly, the writes are buffered, as it takes about a minute to write all
cylinders.












*# df -G /a /a (/dev/sd2a   ): 512 block size  512 frag
size  2847 total blocks  0 free blocks   0 available
 0 total files 224 free files 1810 filesys id msdos
fstype   0x1000 flag255 filename length 0
owner 4 syncwrites6 asyncwrites# ls -la
/adrwxr-xr-x   1 root  wheel 7168 Jan  1  1980 ./drwxr-xr-x  32 root
 wheel 1024 Dec 29 02:38 ../drwxr-xr-x   1 root  wheel  512 Jan  5
14:19 System Volume Information/-rwxr-xr-x   1 root  wheel  1456640 Jan  5
22:37 big**

So *System Volume Information/**IndexerVolumeGuid *is stored 'someplace
special', it would seem.

And now, this is the the part I really don't understand:













*# rm -rf /a/*zsh: sure you want to delete all the files in /a [yn]?
yarm64# ls -la /atotal 1drwxr-xr-x   1 root  wheel  7168 Jan  1  1980
./drwxr-xr-x  32 root  wheel  1024 Dec 29 02:38 ../arm64# df -G /a
/a (/dev/sd2a   ): 512 block size  512 frag size  2847
total blocks899 free blocks 899 available 0 total
files 224 free files 1810 filesys id msdos fstype
0x1000 flag255 filename length 0 owner
7 syncwrites   12 asyncwrites*
-Mike


On Thu, Jan 5, 2023 at 2:07 PM  wrote:

> > On 1/5/23 21:32, Michael Cheponis wrote:
> >> fascinatingly, now, when I try to "umount" the filesystem:
> >>
> >> *# umount /a
> >> umount: /a: Device busy*
> >
> > Fascinating, from what you wrote you might still "be" in /a
>

Re: Is this normal floppy behavior?

[Michael Cheponis]

>> *# umount /a
>> umount: /a: Device busy*

> Fascinating, from what you wrote you might still "be" in /a

Whoops!   Trying to minimize arguments, locations, attempts.

Now, of course, wouldn't be nice if 'umount' said something like "hey
dude!  you're in the directory you're trying to umount."

Naturally, I 'should' know that "Device busy" means "hey dude! you're in
the directory you're trying to umount."

gosh.   ;-)




On Thu, Jan 5, 2023 at 1:33 PM Christian Groessler 
wrote:

> On 1/5/23 21:32, Michael Cheponis wrote:
> > fascinatingly, now, when I try to "umount" the filesystem:
> >
> > *# umount /a
> > umount: /a: Device busy*
>
> Fascinating, from what you wrote you might still "be" in /a
>
> regards,
> chris
>

Re: Is this normal floppy behavior?

[Michael Cheponis]

> Did you type sync and wait?

Not originally; but I just tried it, and doing "sync" and waiting 2 hours
produces no difference.

*# sync*
*# echo wait 2 hours*
*wait 2 hours*


*# df -h /a Filesystem Size   Used  Avail %Cap Mounted
on/dev/sd2a  1.4M   529K   895K  37% /a*

Some of the 529K is bad sectors  (like 1,024 bytes); but why is 529K
"used" when there are no files there:


*# pwd *




*/aarm64# ls -la  total 1drwxr-xr-x   1 root  wheel  7168 Jan  1  1980
./drwxr-xr-x  32 root  wheel  1024 Dec 29 02:38 ../*

fascinatingly, now, when I try to "umount" the filesystem:


*# umount /a  umount: /a: Device busy*


This behavior seems incorrect.

On Thu, Jan 5, 2023 at 5:26 AM Greg Troxel  wrote:

> Michael Cheponis  writes:
>
> > There are a bunch of files on the floppy when mounted; I delete them all;
> > but then, there is a large amount of 'used' space!   unmounting +
> > remounting 'fixes' this problem.
>
> Did you type sync and wait?
>

Is this normal floppy behavior?

[Michael Cheponis]

There are a bunch of files on the floppy when mounted; I delete them all;
but then, there is a large amount of 'used' space!   unmounting +
remounting 'fixes' this problem.

*# mount_msdos /dev/sd2a /a*













































*# ls -l /atotal 2drwxr-xr-x  1 root  wheel512 Jan  4 13:11 System
Volume Information/-rwxr-xr-x  1 root  wheel  65536 Jan  4 21:21
six.0*-rwxr-xr-x  1 root  wheel  65536 Jan  4 21:21 six.1*-rwxr-xr-x  1
root  wheel  65536 Jan  4 21:21 six.10*-rwxr-xr-x  1 root  wheel  65536 Jan
 4 21:21 six.11*-rwxr-xr-x  1 root  wheel  65536 Jan  4 21:21
six.12*-rwxr-xr-x  1 root  wheel  65536 Jan  4 21:21 six.13*-rwxr-xr-x  1
root  wheel  65536 Jan  4 21:22 six.14*-rwxr-xr-x  1 root  wheel  65536 Jan
 4 21:22 six.15*-rwxr-xr-x  1 root  wheel  65536 Jan  4 21:22
six.16*-rwxr-xr-x  1 root  wheel  65536 Jan  4 21:22 six.17*-rwxr-xr-x  1
root  wheel  65536 Jan  4 21:22 six.18*-rwxr-xr-x  1 root  wheel  65536 Jan
 4 21:22 six.19*-rwxr-xr-x  1 root  wheel  65536 Jan  4 21:21
six.2*-rwxr-xr-x  1 root  wheel  65536 Jan  4 21:22 six.20*-rwxr-xr-x  1
root  wheel  65536 Jan  4 21:22 six.21*-rwxr-xr-x  1 root  wheel  65536 Jan
 4 21:21 six.3*-rwxr-xr-x  1 root  wheel  65536 Jan  4 21:21
six.4*-rwxr-xr-x  1 root  wheel  65536 Jan  4 21:21 six.5*-rwxr-xr-x  1
root  wheel  65536 Jan  4 21:21 six.6*-rwxr-xr-x  1 root  wheel  65536 Jan
 4 21:21 six.7*-rwxr-xr-x  1 root  wheel  65536 Jan  4 21:21
six.8*-rwxr-xr-x  1 root  wheel  65536 Jan  4 21:21 six.9*-rwxr-xr-x  1
root  wheel275 Jan  4 21:22 six.bat*# df -h /aFilesystem Size
Used  Avail %Cap Mounted on/dev/sd2a  1.4M   1.4M
 14K  99% /a# rm -rf /a/*zsh: sure you want to delete all 24 files in /a
[yn]? y# ls -l /a# df -h /aFilesystem Size   Used  Avail
%Cap Mounted on/dev/sd2a  1.4M   517K   907K  36% /a#
umount /a# mount_msdos /dev/sd2a /a# ls -l /a# df -h /aFilesystem
Size   Used  Avail %Cap Mounted on/dev/sd2a  1.4M
 17K   1.4M   1% /a*

odd /dev/random behavior with dd ?

[Michael Cheponis]

Hi, 'dd' seems to behave different if the 'if' is /dev/random than if it is
anything else, e.g. /dev/zero:



























*# sh # dd if=/dev/zero of=zero.out bs=65536 count=11+0 records in1+0
records out65536 bytes transferred in 0.001 secs (65536000 bytes/sec)# ls
-l zero.out-rw-r--r--  1 root  wheel  65536 Jan  4 21:30 zero.out# dd
if=/dev/random of=random.out bs=65536 count=10+1 records in0+1 records
out32 bytes transferred in 0.001 secs (32000 bytes/sec)# ls -l
random.out-rw-r--r--  1 root  wheel  32 Jan  4 21:30 random.out# dd
if=/dev/random of=random.out.2 bs=65536 count=20480+2048 records in0+2048
records out65536 bytes transferred in 0.054 secs (1213629 bytes/sec)# ls -l
random.out.2-rw-r--r--  1 root  wheel  65536 Jan  4 21:31 random.out.2#
uname -aNetBSD arm64 9.99.102 NetBSD 9.99.102 (MIKE64) #0: Wed Oct 26
22:54:20 UTC 2022  mac@arm64:/usr/obj/sys/arch/evbarm/compile/MIKE64 evbarm*



Am I doing something stupid?

Thanks!
Mike

Re: 'cd' if HOME is unset

[Michael Cheponis]

Well, as a zsh user:

$ echo $HOME
/usr/mac
$ unset HOME
$ echo $HOME

$ zsh -c cd
$(no change in directory, no error msg)

also:

$ HOME=/usr/mac
$ echo $HOME
/usr/mac

$ (unset HOME; zsh -c cd)
$ (no error msg)


in all cases, directory does not change when HOME is not defined.


On Mon, Dec 26, 2022 at 9:47 AM Robert Elz  wrote:

> Date:Sun, 25 Dec 2022 15:33:57 -0800
> From:    Michael Cheponis 
> Message-ID:   5rw...@mail.gmail.com>
>
>   | Maybe it should print "$HOME is not set" in that case?
>
> Did you try it?
>
> It is easy...
>
> (unset HOME; sh -c cd)
>
> or use ksh (or some other shell) instead of sh to test it.
>
> Script started on Tue Dec 27 00:01:34 2022
> jacaranda$ (unset HOME; sh -c cd)
> cd: HOME not set
> jacaranda$ (unset HOME; ksh -c cd)
> ksh: cd: no home directory (HOME not set)
> jacaranda$ exit
>
> Script done on Tue Dec 27 00:03:06 2022
>
>
> Note HOME  not $HOME  is not set, $HOME is, if
> HOME is set, a pathname, or if HOME is not set, "",
> neither of which makes any sense to describe as 'not set'.
>
> kre
>

Re: 'cd' if HOME is unset

[Michael Cheponis]

Maybe it should print "$HOME is not set" in that case?


On Sun, Dec 25, 2022 at 2:52 PM Valery Ushakov  wrote:

> On Sat, Dec 24, 2022 at 22:32:22 -0500, Jan Schaumann wrote:
>
> > Robert Elz  wrote:
> > > Why bother?
> >
> > I happily admit that it's a rare edge case. I simply
> > find it surprising that 'cd' gives up if HOME is
> > unset.  Seems unintuitive to me.
>
> Some would say, "gives up", some would say it makes you aware you have
> a problem. :)
>
> DWIM is enticing, sure, but at some point it trasmutes into that
> JavaScript "WAT" talk moment.
>
> -uwe
>

Re: NetBSD-10.0_BETA: clock: unknown CMOS layout

[Michael van Elst]

dposto...@yandex.ru (Dmitrii Postolov) writes:

>"clock: unknown CMOS layout"

The message says that no century information is found in the CMOS RAM,
the hardware clock itself seems to keep only 2 year digits. The century
is then deduced as 1900 if the year number is less than 70 and 2000
otherwise.

This heuristic will fail 2030. Then the clock will start with a
date 100 years in the past and gets corrected later during the
boot process. Ugly, but probably not fatal.

Re: NetBSD-10.0_BETA: clock: unknown CMOS layout

[Michael van Elst]

dposto...@yandex.ru (Dmitrii Postolov) writes:

>On boot of NetBSD-10.0_BETA the message "clock: unknown CMOS layout" is 
>printed. There is no this message at boot on NetBSD-9.x.

It's a DIAGNOSTIC message, if you run NetBSD-9.x release, the kernel
is built without DIAGNOSTIC checks and messages, but NetBSD-10.0-BETA
still is.

Re: resolv.conf

[Michael van Elst]

tgru...@gmail.com (Todd Gruhn) writes:

>Spectrum upgraded. I start NetBSD, and /etc/resolv.conf has nothing.

>How do I fix this?
>Should there be any minimal resolv.conf settings???

You either get network settings automatically via DHCP (and that
should include data for resolv.conf) or you have set it manually,
then you do the configuration yourself.

Re: IBM IMM shared port

[Michael van Elst]

kab...@lich.phys.spbu.ru (Dima Veselov) writes:

>I have an IBM x3200 M3 server with built-in IMM IPMI service
>processor. This server have IPMI network port shared with first network 
>card. This setup is quite popular and I have several different servers 
>having no issues with that. While booting, OS initialize network 
>interface and IPMI stop responding for a while, then connection is 
>restored. My guess is that happens because of internal switch reset when 
>network interface get reset.

The ethernet controller is shared between BMC and OS. While this construct
may work in single-user mode, if BMC and OS driver co-operate, it tends
to fail exactly when you need it, i.e. when the system crashed and you
need IPMI to recover.
So I try to avoid it whenever possible and dedicate that interface to
the BMC.

Re: Debugging socket options

[Michael van Elst]

br...@nmsu.edu (Brook Milligan) writes:

> 18808  18808 guppy_basecaller CALL  socketpair(1,5,0,0x7f7fdb98)

socketpair(PF_LOCAL, SOCK_SEQPACKET, 0, );


> 18808  18808 guppy_basecaller CALL  =
>setsockopt(3,1,0x10,0x7f7fda14,4)

setsockopt(3, SOL_SOCKET, SO_PASSCRED, , sizeof(val));


I don't think that could work with our Linux emulation as we
do not support SO_PASSCRED.

Re: ldd-linux

[Michael van Elst]

On Sat, Dec 03, 2022 at 05:08:57PM -0700, Brook Milligan wrote:
> 
> Does it make sense to have updated linux library packages?

That always makes sense, but libstdc++ is the GNU C++ runtime
and this has usually very limited compatibility. A program
ususally wants (and often needs) exactly the version is was built for.


Greetings,
-- 
    Michael van Elst
Internet: mlel...@serpens.de
"A potential Snark may lurk in every tree."

Re: timers slow (sleep 1 taking five seconds)

[Michael van Elst]

r...@reedmedia.net ("Jeremy C. Reed") writes:

>acpi0: fixed power button present
>timecounter: Timecounter "ACPI-Fast" frequency 3579545 Hz quality 1000
>hpet0 at acpi0: high precision event timer (mem 0xfed0-0xfed00400)
>timecounter: Timecounter "hpet0" frequency 14318180 Hz quality 2000

>attimer1 at acpi0 (TMR, PNP0100): io 0x40-0x43 irq 0

>t1:reed$ date ; time sleep 1 ; date 
>Sat Dec  3 00:31:40 UTC 2022
>5.01s real 0.00s user 0.00s system
>Sat Dec  3 00:31:45 UTC 2022


Can you check

sysctl kern.timecounter.choice
sysctl kern.timecounter.hardware

Maybe you use a mis-calibrated TSC ? The ACPI-Fast and hpet0 counters
look reasonable.

Re: ldd-linux

[Michael van Elst]

br...@nmsu.edu (Brook Milligan) writes:

>All but one of these are provided by the emulators/suse131_base and =
>emulators/suse131_glib2 packages; the missing one is libstdc++.so.6.  =

Hmm. emulators/suse131_base (from 2022Q3 release) comes with:

/usr/pkg/emul/linux/usr/lib64/libstdc++.so.6
/usr/pkg/emul/linux/usr/lib64/libstdc++.so.6.0.18

Re: Local-only (non-ip) rpcbind(8)?

[Michael van Elst]

h...@spg.tu-darmstadt.de (Hauke Fath) writes:

>>  if (ipv6_only == 1 && 

>And here is where I naively would insert a commandline option flag to 
>disable all things non-local. Unless something like that already exists, 
>and I just didn't see it.

>>  strcmp(nconf->nc_protofmly,"inet") == 0) {
>>  /* DO NOTHING */

Nope, just the commandline option that filters out IPv4.

Re: Local-only (non-ip) rpcbind(8)?

[Michael van Elst]

h...@spg.tu-darmstadt.de (Hauke Fath) writes:

>Hi,

>can rpcbind(8) be set up to only use local transport, as opposed to 
>binding to interfaces?

>The closest I seem to come to that goal is by specifying '-h 127.0.0.1', 
>which results in a pointless

>Nov 18 15:45:05 HOST rpcbind: cannot bind 127.0.0.1 on udp: Address 
>already in use
>Nov 18 15:45:05 HOST rpcbind: cannot bind 127.0.0.1 on tcp: Address 
>already in use

When you specify hosts, rpcbind automatically adds 127.0.0.1 to the
list of addresses, thus the duplicate.

Here is what rpbind does:

-> bind to local transport
nconf = getnetconfigent("local");
init_transport(nconf);

-> bind to all visible transports configured
while ((nconf = getnetconfig(nc_handle))) {
if (nconf->nc_flag & NC_VISIBLE) {
if (ipv6_only == 1 && strcmp(nconf->nc_protofmly,
"inet") == 0) {
/* DO NOTHING */
} else
init_transport(nconf);
}
}
endnetconfig(nc_handle);

The configuration is in /etc/netconfig:

udp6   tpi_clts  v inet6udp -   -
tcp6   tpi_cots_ord  v inet6tcp -   -
udptpi_clts  v inet udp -   -
tcptpi_cots_ord  v inet tcp -   -
rawip  tpi_raw   - inet  -  -   -
local  tpi_cots_ord  - loopback  -  -   -

where 'v' is the NC_VISIBLE flag.

Of course that's a global setting and RPC clients use is too.

Re: switched from 9.99 to 9.3, init dies

[Michael van Elst]

riccardo.mott...@libero.it (Riccardo Mottola) writes:

>After the upgrade (which I believe is partially a downgrade, I don't 
>know when 9.3 was forked) boot dies with "panic: init died" apparently 
>in snprintf.

I would guess that "upgrading" killed your libc.

You can try to boot with -a (ask) and when the kernel asks for the
init program, tell it to run /rescue/init (assuming you have installed
the rescue set).

Otherwise you probably need to boot from a different medium (e.g.
an USB stick with the installation image).

Re: More floppy oddities

[Michael van Elst]

michael.chepo...@gmail.com (Michael Cheponis) writes:

>--7795b905eda356fd
>Content-Type: text/plain; charset="UTF-8"

># scsictl sd1 format
>/dev/rsd1: Check Condition on CDB: 1a 00 03 00 24 00
>SENSE KEY: No Additional Sense
> ASC/ASCQ: No Additional Sense Information

>I don't know what that means.


'1a' is a "mode sense" command that is used to query some information
(like geometry) and that failed.


>The console prints:
>[ 2207.9560928] sd1(umass1:0:0): medium error, data = 00 00 00 00 30 01 00
>00 00 00
>[ 2207.9610935] sd1c: error reading fsbn 64 (sd1 bn 64; cn 1 tn 1 sn 10)


Reading failed and the drive returned 'medium error', i.e. it couldn't
read anything. That could mean the medium is defective, but it could
also mean that the drive assumes some different formatting. It's possible
that the drive requires some configuration that our sd driver doesn't
provide.


>When trying 'fdformat'

>fdformat -f /dev/rsd1a -t 1440
>fdformat: Device `/dev/rsd1a' does not support floppy formatting:
>Inappropriate ioctl for device

fdformat is only for the fd driver.


>These diskettes have been pre-formatted under Windows 11, they work fine on
>that OS.  I have two different USB floppy drives, one is Teac, one is Sony;
>both work fine in Windows.

That would rule out a "real" medium error.

More floppy oddities

[Michael Cheponis]

# scsictl sd1 format
/dev/rsd1: Check Condition on CDB: 1a 00 03 00 24 00
SENSE KEY: No Additional Sense
 ASC/ASCQ: No Additional Sense Information

I don't know what that means.

The console prints:
[ 2207.9560928] sd1(umass1:0:0): medium error, data = 00 00 00 00 30 01 00
00 00 00
[ 2207.9610935] sd1c: error reading fsbn 64 (sd1 bn 64; cn 1 tn 1 sn 10)


When trying 'fdformat'

fdformat -f /dev/rsd1a -t 1440
fdformat: Device `/dev/rsd1a' does not support floppy formatting:
Inappropriate ioctl for device

Console prints:
[ 2376.3318245] sd1(umass1:0:0): medium error, data = 00 00 00 00 30 01 00
00 00 00
[ 2376.3358251] sd1c: error reading fsbn 64 (sd1 bn 64; cn 1 tn 1 sn 10)

SAME THING!  And, with a different diskette this time.

Interesting that I'm addressing /dev/rsd1a but the error message is about
the 'whole disk' sd1c

sometimes, when I try fdformat, I get this console message
[ 2576.4662150] sd1(umass1:0:0): not ready, data = 00 00 00 00 3a 00 00 00
00 00

but then just repeating the command 'works', meaning, I get the
inappropriate ioctl for device + the same 2 console lines

These diskettes have been pre-formatted under Windows 11, they work fine on
that OS.  I have two different USB floppy drives, one is Teac, one is Sony;
both work fine in Windows.

I'm a bit bamboozled as to where to go from here.

Thank you, again,
Mike