Re: how to fsck automatically at boot
On May 20 13:22:26, mikyde...@yahoo.fr wrote: > Hello, > > I have two use cases and problems with fsck. > > 1) When my openbsd boots after an outage, the system asks me to fsck /, /usr, > /var or /home manually. > So I do > fsck /dev/sd0a > And then I'm asked questions and I usually answer F > > So my question is that I want this process to be done automatically at boot > time for each partition that has a problem. The /etc/rc boot script calls fsck -p; if that fails, it means fsck -p was unable to fix a major problem. It is the point that it requires an admin's intervention. You would have to change the fsck call to fsck -y; but don't do that. (Also, don't let a server have power outages, obviously.) > This is because I use a small server without screen and keyboard. So what? That is no excuse to leave broken filesystems unattended. > 2) I have another disk in my small server, and I mount one partition of it > with in fstab > aa929243b0f5.a /var/mylogs ffs rw,nodev,nosuid 1 2 > When I remove that disk the boot sequence stops and asks for a fsck > I would like that this disk is mounted when it's present, but when it's not > installed I don't want the boot sequence to stop Make it also "noauto" in fstab and mount it in rc.local. (Also, don't remove disks from servers, obviously.)
Re: Could OpenBSD use some compute?
On May 14 12:24:28, romand...@gmail.com wrote: > If someone had spare capacity, (say, in their homelab, ~80% available, > about same amount 10k/mon would buy in AWS spot instances), and wanted to > share it with the open source community in general and OpenBSD devs in > particular, and were willing to do some ops and eat the electricity bill, > how could they go about putting all those to good use? > Hosting mirrors comes to mind, maybe some build/test server? Fuzzy testing > dev branches? "I'm asking for a friend"
Re: What software to debugging and analyzing C?
On May 12 11:51:32, cpb_m...@bennettconstruction.us wrote: > In a short, he recommended valgrind to help finding memory leaks. man malloc
Re: Favorite configuration and system replication tools?
On May 07 22:15:27, olp...@yahoo.ca wrote: > I was wondering which programs you use for replicating/copying/syncing > environments/configs on your openbsd systems with between your desktops (home > or work) and laptops? git > Do you also maintain installeded/removed packages in some standard way across > systems so that you have reasonable consistent systems to work on? a plaintext list of package names
Re: Hardware recommendation for small form factor, noiseless, server
On May 06 21:03:17, mytraddr...@gmail.com wrote: > Hi all, > > can anyone please advise on what computer I can purchase with the following > requirements: > > - fully supports OpenBSD > - no noise > - good quality wifi > - small form factor preferably > - processor does not need to be fast (no highly intensive compute load) > - low RAM need > - needs 1 TB of hard drive at least > - will be used only remotely, for basic and low-intensity server-type > applications (no desktop use) > - under $500 PC Engiunes APU2, with a wifi card plugged in, and most of the $500 buying the 1 TB storage. OpenBSD 7.5-current (GENERIC.MP) #34: Sat Apr 27 21:19:57 MDT 2024 dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP real mem = 2112446464 (2014MB) avail mem = 2027487232 (1933MB) random: good seed from bootblocks mpath0 at root scsibus0 at mpath0: 256 targets mainbus0 at root bios0 at mainbus0: SMBIOS rev. 3.0 @ 0x7ee97040 (13 entries) bios0: vendor coreboot version "v4.19.0.1" date 01/31/2023 bios0: PC Engines apu2 acpi0 at bios0: ACPI 6.0 acpi0: sleep states S0 S1 S4 S5 acpi0: tables DSDT FACP SSDT MCFG TPM2 APIC HEST IVRS SSDT SSDT DRTM HPET acpi0: wakeup devices PBR4(S4) PBR5(S4) PBR6(S4) PBR7(S4) PBR8(S4) UOH1(S3) UOH2(S3) UOH3(S3) UOH4(S3) UOH5(S3) UOH6(S3) XHC0(S4) acpitimer0 at acpi0: 3579545 Hz, 32 bits acpimcfg0 at acpi0 acpimcfg0: addr 0xf800, bus 0-63 acpimadt0 at acpi0 addr 0xfee0: PC-AT compat cpu0 at mainbus0: apid 0 (boot processor) cpu0: AMD GX-412TC SOC, 998.17 MHz, 16-30-01, patch 07030105 cpu0: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,HTT,SSE3,PCLMUL,MWAIT,SSSE3,CX16,SSE4.1,SSE4.2,MOVBE,POPCNT,AES,XSAVE,AVX,F16C,NXE,MMXX,FFXSR,PAGE1GB,RDTSCP,LONG,LAHF,CMPLEG,SVM,EAPICSP,AMCR8,ABM,SSE4A,MASSE,3DNOWP,OSVW,IBS,SKINIT,TOPEXT,DBKP,PERFTSC,PCTRL3,HWPSTATE,ITSC,BMI1,XSAVEOPT cpu0: 32KB 64b/line 8-way D-cache, 32KB 64b/line 2-way I-cache, 2MB 64b/line 16-way L2 cache cpu0: smt 0, core 0, package 0 mtrr: Pentium Pro MTRR support, 8 var ranges, 88 fixed ranges cpu0: apic clock running at 99MHz cpu0: mwait min=64, max=64, IBE cpu1 at mainbus0: apid 1 (application processor) cpu1: AMD GX-412TC SOC, 998.44 MHz, 16-30-01, patch 07030105 cpu1: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,HTT,SSE3,PCLMUL,MWAIT,SSSE3,CX16,SSE4.1,SSE4.2,MOVBE,POPCNT,AES,XSAVE,AVX,F16C,NXE,MMXX,FFXSR,PAGE1GB,RDTSCP,LONG,LAHF,CMPLEG,SVM,EAPICSP,AMCR8,ABM,SSE4A,MASSE,3DNOWP,OSVW,IBS,SKINIT,TOPEXT,DBKP,PERFTSC,PCTRL3,HWPSTATE,ITSC,BMI1,XSAVEOPT cpu1: 32KB 64b/line 8-way D-cache, 32KB 64b/line 2-way I-cache, 2MB 64b/line 16-way L2 cache cpu1: smt 0, core 1, package 0 cpu2 at mainbus0: apid 2 (application processor) cpu2: AMD GX-412TC SOC, 998.37 MHz, 16-30-01, patch 07030105 cpu2: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,HTT,SSE3,PCLMUL,MWAIT,SSSE3,CX16,SSE4.1,SSE4.2,MOVBE,POPCNT,AES,XSAVE,AVX,F16C,NXE,MMXX,FFXSR,PAGE1GB,RDTSCP,LONG,LAHF,CMPLEG,SVM,EAPICSP,AMCR8,ABM,SSE4A,MASSE,3DNOWP,OSVW,IBS,SKINIT,TOPEXT,DBKP,PERFTSC,PCTRL3,HWPSTATE,ITSC,BMI1,XSAVEOPT cpu2: 32KB 64b/line 8-way D-cache, 32KB 64b/line 2-way I-cache, 2MB 64b/line 16-way L2 cache cpu2: smt 0, core 2, package 0 cpu3 at mainbus0: apid 3 (application processor) cpu3: AMD GX-412TC SOC, 998.31 MHz, 16-30-01, patch 07030105 cpu3: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,HTT,SSE3,PCLMUL,MWAIT,SSSE3,CX16,SSE4.1,SSE4.2,MOVBE,POPCNT,AES,XSAVE,AVX,F16C,NXE,MMXX,FFXSR,PAGE1GB,RDTSCP,LONG,LAHF,CMPLEG,SVM,EAPICSP,AMCR8,ABM,SSE4A,MASSE,3DNOWP,OSVW,IBS,SKINIT,TOPEXT,DBKP,PERFTSC,PCTRL3,HWPSTATE,ITSC,BMI1,XSAVEOPT cpu3: 32KB 64b/line 8-way D-cache, 32KB 64b/line 2-way I-cache, 2MB 64b/line 16-way L2 cache cpu3: smt 0, core 3, package 0 ioapic0 at mainbus0: apid 4 pa 0xfec0, version 21, 24 pins ioapic1 at mainbus0: apid 5 pa 0xfec2, version 21, 32 pins acpihpet0 at acpi0: 14318180 Hz acpiprt0 at acpi0: bus 0 (PCI0) acpiprt1 at acpi0: bus -1 (PBR4) acpiprt2 at acpi0: bus 1 (PBR5) acpiprt3 at acpi0: bus -1 (PBR6) acpiprt4 at acpi0: bus 2 (PBR7) acpiprt5 at acpi0: bus -1 (PBR8) acpicpu0 at acpi0: C2(0@400 io@0x1771), C1(@1 halt!), PSS acpicpu1 at acpi0: C2(0@400 io@0x1771), C1(@1 halt!), PSS acpicpu2 at acpi0: C2(0@400 io@0x1771), C1(@1 halt!), PSS acpicpu3 at acpi0: C2(0@400 io@0x1771), C1(@1 halt!), PSS acpicpu4 at acpi0: no cpu matching ACPI ID 4 acpicpu5 at acpi0: no cpu matching ACPI ID 5 acpicpu6 at acpi0: no cpu matching ACPI ID 6 acpicpu7 at acpi0: no cpu matching ACPI ID 7 acpipci0 at acpi0 PCI0: 0x 0x0011 0x0001 acpicmos0 at acpi0 com0 at acpi0 COM1 addr 0x3f8/0x8 irq 4: ns16550a, 16 byte fifo com0: console com1 at acpi0 COM2 addr 0x2f8/0x8 irq 3: ns16550a, 16 byte fifo amdgpio0 at acpi0 GPIO uid 0 addr 0xfed81500/0x300 irq 7, 184 pins "PRP0001" at acpi0 not configured "PRP0001" at acpi0 not
Re: >10W idle power usage on framework laptop 12th gen 13inch
Where do you get the > 10W number? Not in the sysctl output, and you are running on battery. On Apr 28 11:53:09, n...@fastmail.com wrote: > I am seeing a lot of power drawn even when nothing is going on on the system > (top shows everything at zero, load average is 0.01). This is even if the > backlight is dim. > > On an Ubuntu Linxu system, i was getting about 3.5-4W when nothing much was > going on. > > Any ideas if it's remediable or where to start digging? > > dmesg.boot attached Trim the dmesg to only contain the actual dmesg. On Apr 28 12:14:47, n...@fastmail.com wrote: > I forgot to mention that I have apmd running in automatic mode. I've also > tried obsdfreqd but it does not seem to have much of an effect on or off. > Here is my `sysctl hw.sensors' output (with obsdfreqd on) > > ```sysctl hw.sensors > hw.sensors.cpu0.temp0=47.00 degC > hw.sensors.cpu0.frequency0=6.00 Hz > hw.sensors.cpu2.frequency0=7.00 Hz > hw.sensors.cpu4.frequency0=55000.00 Hz > hw.sensors.cpu6.frequency0=65000.00 Hz > hw.sensors.cpu8.frequency0=45000.00 Hz > hw.sensors.cpu9.frequency0=55000.00 Hz > hw.sensors.cpu10.frequency0=65000.00 Hz > hw.sensors.cpu11.frequency0=6.00 Hz > hw.sensors.cpu12.frequency0=55000.00 Hz > hw.sensors.cpu13.frequency0=55000.00 Hz > hw.sensors.cpu14.frequency0=55000.00 Hz > hw.sensors.cpu15.frequency0=55000.00 Hz > hw.sensors.acpibtn0.indicator0=On (lid open) > hw.sensors.acpiac0.indicator0=Off (power supply) > hw.sensors.acpibat0.volt0=15.40 VDC (voltage) > hw.sensors.acpibat0.volt1=14.29 VDC (current voltage) > hw.sensors.acpibat0.current0=0.69 A (rate) > hw.sensors.acpibat0.amphour0=3.01 Ah (last full capacity) > hw.sensors.acpibat0.amphour1=0.30 Ah (warning capacity) > hw.sensors.acpibat0.amphour2=0.09 Ah (low capacity) > hw.sensors.acpibat0.amphour3=0.12 Ah (remaining capacity), WARNING > hw.sensors.acpibat0.amphour4=3.57 Ah (design capacity) > hw.sensors.acpibat0.raw0=5 (battery discharging), OK So you are running on battery, not AC. Where did you get the "10W" ? > hw.sensors.acpibat0.raw1=4 (discharge cycles) Probably not related, but your battery has dropped full charge from 3.57 Ah to 3.01 in four cycles? > hw.sensors.acpitz0.temp0=42.80 degC (zone temperature) > hw.sensors.acpitz1.temp0=40.80 degC (zone temperature) > hw.sensors.acpitz2.temp0=41.80 degC (zone temperature) > hw.sensors.acpitz3.temp0=38.80 degC (zone temperature) > hw.sensors.acpitz4.temp0=31.80 degC (zone temperature) > hw.sensors.softraid0.drive0=online (sd1), OK > ```
Re: Security questions: Login spoofing, X11 keylogging, and sandboxed apps
go away On Mar 28 21:16:45, dan.peretz...@gmail.com wrote: > You didn't "Reply All", so I didn't get your reply in my inbox. (The person > you're replying to should be in the To field, and the mailing list in the > Cc field.) > > >Even on windows; this has nothing to do with intercepting ctrl-alt-del. > False. Ctrl-Alt-Delete cannot be intercepted on Windows without first > compromising the integrity of the operating system. The Windows kernel is > hardcoded to forward Ctrl-Alt-Delete to Winlogon, and Winlogon runs in a > separate Secure Desktop mode that takes over the entire screen and no other > programs can intercept keystrokes from or send keystrokes to. > https://security.stackexchange.com/a/34975 > https://learn.microsoft.com/windows/win32/winstation/desktops > > >I don't believe that's true. > >"Dear X11, what is $user typing into his firefox textarea"? > I'm not an X11 expert, and I'm not sure if the example provided in the > following link is because the program and the desktop it's running under > have different UIDs (rather than locking the desktop, logging into a > different user with a new desktop session using a SAK like Ctrl-Alt-Delete, > and running it there), but I found this old blog post, by whom I believe is > the founder of Qubes OS, being cited somewhere: > https://theinvisiblethings.blogspot.com/2011/04/linux-security-circus-on-gui-isolation.html > It is common knowledge that X11 is insecure by design, not (only) by the > ancient code, so even if the blog post isn't relevant anymore, it wouldn't > surprise me if such attacks could still be done. > > >>I saw that Chromium, Firefox, and Tor Browser on OpenBSD (at least when > installed from the OpenBSD package manager/ports) are sandboxed with > pledge(2) and unveil(2). > >find /usr/ports/ -name pledge\* > Already done: > https://openports.pl/search?file=unveil > This only lists third-party packages that have an OpenBSD ports-originated > addition of pledge/unveil configuration files; packages that use > pledge/unveil without configuration files, or whose pledge/unveil > configuration files originate from the upstream distribution, are not > listed. Chromium, Ungoogled Chromium, Firefox, Firefox ESR, and Tor Browser > are sandboxed, which is excellent because Web browsing is one of the most > popular desktop activity and browsers are meant to use networking and > execute untrusted JavaScript/WebAssembly code, and parse untrusted data > like media, CSS, etc. Contrary to servers, that if they're hacked then some > business might be ruined, personal computers are used to do banking and > shopping online, chat with distant friends/family > members/doctors/lawyers/coworkers/etc., and hold our personal thoughts and > memories, so I believe that they shouldn't get compromised just because the > user entered the wrong website on a bad day, or opened the wrong video, or > the wrong file, etc. OpenBSD already has the excellent system calls > pledge(2) and unveil(2), and already uses them extensively in the base > system and for the aforementioned browsers, but what about other programs?
Re: Security questions: Login spoofing, X11 keylogging, and sandboxed apps
> (1) Does OpenBSD have a mechanism like Ctrl-Alt-Delete on Windows (Secure > Attention Key, or SAK) to prevent malware (or a website in fullscreen, for > example) from faking a logout process and/or faking a login prompt? On > Windows the kernel ensures that the operating system captures this key > combination and takes over with a real login prompt that malware can't fake > without first defeating the OS security. Any X11 program can display a screen that looks like the login screen. Even on windows; this has nothing to do with intercepting ctrl-alt-del. > (2) I've learned that X11 allows locally running malware to sniff the > keystrokes input to any other X11-using app running under any user. I don't believe that's true. Where have you "learned" that, and how does that work? "Dear X11, what is $user typing into his firefox textarea"? > (3) I saw that Chromium, Firefox, and Tor Browser on OpenBSD (at least when > installed from the OpenBSD package manager/ports) are sandboxed with > pledge(2) and unveil(2). Are there any other major apps, especially that > commonly accept untrusted input, that are also sandboxed like that on > OpenBSD? Especially email clients, media players, word processors, apps to > send/receive/sync files, etc. find /usr/ports/ -name pledge\*
Re: Reload hostname.if file after suspend and resume (urtwn, zzz)
On Mar 25 15:52:38, zeni...@proton.me wrote:
> Thanks for the quick response. It looks like hotplugd was what I was precisely
> looking for. As usual, my usecase was inside the manpage :).
> As a final note, I tried to do it with the resume script but it did not seem
> to
> work. I guess it was because the attachment takes a delay from the execution
> of the resume script.
Suspecting the same, I put the following into etc/apm/resume
#!/bin/sh
case ${0##*/} in
resume)
sleep 5
rcctl restart wpa_supplicant
;;
*)
;;
esac
> On Monday, March 25th, 2024 at 1:38 PM, Stefan Sperling
> wrote:
>
> > On Mon, Mar 25, 2024 at 12:13:06PM +, ZenitDS wrote:
> >
> > > Hello,
> > > On boot the urtwn0 interface is configured as expected, but after
> > > I sleep using 'zzz', it gets resetted and I have to manually run
> > > 'sh /etc/netstart' with root priviliges to reconfigure the interface.
> > > I tried using /etc/apm/resume, but running it there made no difference.
> > > I have seen that some people solved this issue by having a background
> > > process checking at every moment if a connection exists, and if it does
> > > not then run the sh /etc/netstart script, but it looks like a hacky.
> > > Any help will be much appreciated
> > > Thanks in advance
> >
> >
> > You can use the /etc/apm/resume script (see the apmd(8) manual page)
> > to run /etc/netstart urtwn0 on resume.
> > Or use hotplugd(8) to run /etc/netstart urtwn0 whenever the urtwn0 device
> > gets attached, be it during resume or when inserted into a USB port.
>
>
Re: aucat options parsing
On Mar 21 10:07:08, h...@stare.cz wrote: > This seems strange: > > $ aucat -n -d -i input.wav -c -r 8000 -o out.wav > input.wav: skipped unknown chunk > input.wav: play, chan 0:3, 48000Hz, s16le, bytes 80..1920080, vol 8388608 > -r: channel range expected > > It is an ommited number in -c 1 of course, > not a missing sample rate. Sorry, my bad; it is a missing channel range of course. Without using the new -m, it seems that one _must_ use the old -c syntax of -c lo:hi; in particular, -c 1 -o out.wav is illegal, even though it is a valid (new) syntax. If that is the case, shouild the manpage mention that? Jan
aucat options parsing
This seems strange: $ aucat -n -d -i input.wav -c -r 8000 -o out.wav input.wav: skipped unknown chunk input.wav: play, chan 0:3, 48000Hz, s16le, bytes 80..1920080, vol 8388608 -r: channel range expected It is an ommited number in -c 1 of course, not a missing sample rate. Jan
Re: Ignore some USB devices
On Feb 19 22:33:53, kir...@korins.ky wrote: > On Mon, 19 Feb 2024 22:15:40 +0100, > Jan Stary wrote: > > > > On Feb 19 22:08:40, kir...@korins.ky wrote: > > > On Mon, 19 Feb 2024 21:58:51 +0100, > > > Thomas L. wrote: > > > > > > > > you can select which audio device is used with -f/-F flags to sndiod > > > > (details in man-page) in /etc/rc.conf.local. maybe that helps? > > > > > > thanks, but I right now I do have: > > > > > > ~ $ rcctl get sndiod flags > > > -f rsnd/0 -F rsnd/1 -F rsnd/2 > > > > Do you actualy want to switch between the three? > > What are the three audio devices you want to use, and why? > > I use the rsnd/1 or rsnd/2 to listen music via wireless headphones, Why do you have two of those? > and rsnd/0 with wired headset to make video calls. > > I never use display's audio and it creates only issue for me. To be clear: even when you connect the display, presumably because you want to use it as a display (and maybe even its camera), you want the sound to stay at whatever snd device you are using; in particular, you don't want sndio to switch to the new snd device provided by the newly plugged display's uaudio. Is there a setting in the display that would completely disable its audio? > Let take two use cases: > 1. Listen some music when laptop is connected to the display on wireless >headphones by attaching USB dongle; > 2. Connect laptop to the display when listen some music on wireless >headphones via USB dongle. > > The first one leads to rsnd/2 as desired device, and the second one to > rsnd/1 as desired device. > > As side effect of (2) music might be redirect to the display which has > quite hight default level of volume. > > So, right now to attach laptop to the screen and do not wake famly up at > the night I should: > - pause the music; > - deattach USB dongle; > - connect laptop to the screen; > - attach USB dongle; > - and finaly resume music. You could also detach-and-reattach the headphones dongle *after* you attach the display. You could also send a dmesg showing all of those devies.
Re: Ignore some USB devices
On Feb 19 22:16:37, kir...@korins.ky wrote: > On Mon, 19 Feb 2024 22:05:37 +0100, > Jan Stary wrote:Ri > > > > Why are you using this camera, and not the other one? > > > > > and after that > > > X11 screen dissapear, and fplay doesn't response on C-c anymore. > > > Deattach the display helps to kills fplay. > > > > It is entirely unclear what you are trying to do. > > > > Are you using ffplay to record from a camera? > > Which camera? The display's camera? I thought you had > > another camera (which you want to use instead): > > why don't you just run ffplay with _that_ camera? > > > > Generaly, if the devices you don't want to use > > (such as the display's camera as uvideo1, > > ar the display's microphone as uaudio1) > > simply attach and exist, it doesn't mean > > you have to use them; having them exist > > breaks nothing, just tell you applications > > to use the ones you want (uaudio0, uvideo0?). > > > > Sorry, I wasn't clear. > > Camera just exists and I use one in laptop which works, and just > existing camera doesn't create any issue. > > But 3rd audio device does create some issue. > > Right now I do have 3 audio devices: > - embeded inside laptop; > - embeded inside display; > - USB dongle to connect to bluetooth headphones. > > I also have: > > ~ $ rcctl get sndiod flags > -f rsnd/0 -F rsnd/1 -F rsnd/2 > ~ $ > > that works almost fine, but requires to deattach USB dongle before I > connect laptop to the display, otherwise the display's one will bersnd/2 > with priority, and music will be redirect into it. > > That can be quite unfair regarding my family, special at 3 am because > default volume level of display's audio isn't low. OK, now I see: the headphones dongle needs to connect last to become the -F snd/2 that overrides the previous. You should have started by saying that. So get some normal headphones that plug into the laptop (without creating a new device) and simply connect the display when you want, or don't connect it when you don't.
Re: Ignore some USB devices
On Feb 19 22:08:40, kir...@korins.ky wrote: > On Mon, 19 Feb 2024 21:58:51 +0100, > Thomas L. wrote: > > > > you can select which audio device is used with -f/-F flags to sndiod > > (details in man-page) in /etc/rc.conf.local. maybe that helps? > > thanks, but I right now I do have: > > ~ $ rcctl get sndiod flags > -f rsnd/0 -F rsnd/1 -F rsnd/2 Do you actualy want to switch between the three? What are the three audio devices you want to use, and why? > that works almost fine, but requires to deattach USB dongle What USB dongle? > before I connect laptop to the display. > If I forgot to do it, the display's audio will be rsnd/2 with priority. What is the rsnd/2 you _want_? How does _detaching_ anything before the display attaches help that?
Re: Automatic OS updates
> On 2024-02-15, b...@fea.st wrote: > > So I was curious, am I the only one using automatic OS updates > > in cron to keep the fish fresh and the bits dust free? > > 0 3 * * * root sysupgrade And this saves you what, ten keystrokes a day? Possibly hitting a bad moment to update blindly?
many serial ports
What HW do people use to read data from many serial ports simultaneously? My use case is reading the output of https://en.wikipedia.org/wiki/Electropalatography The device has eight serial port outputs; I need to read those at the computer side. Do I just stuff my box with 8 cereals, or is there something more elegant? Some multiplexing USB dongle? Jan
Re: No audio playback with azalia0 Intel Braswell HD Audio
azalia0 at pci0 dev 27 function 0 "Intel Braswell HD Audio" rev 0x35: msi azalia0: no supported codecs You would have something like azalia0 at pci1 dev 27 function 0 "Intel 3400 HD Audio" rev 0x06: msi azalia0: codecs: Conexant/0x5069, Intel/0x2804, using Conexant/0x5069 audio0 at azalia0 if any codecs of this card were supported. In particular, you don't have an audio(4) device; there is no "workaround" to that. Someone has to write the driver for your Braswell. (Idealy, donate the notebook to a developer :-) Jan On Feb 05 20:28:16, j...@ircnow.org wrote: > Greetings, > > I am attempting to play audio on an HP Chromebook 11 G5 Setzer, > but OpenBSD appears to be missing the necessary codecs. Are there any > workarounds? I'm guessing that switching from the built-in speakers to > headphones won't make any difference. Any suggestions appreciated. > > Here's the output I see when using ogg123: > > bsd$ ogg123 -d sndio Mozart_-_Eine_kleine_Nachtmusik_-_1._Allegro.ogg > > Audio Device: sndio audio output > > Playing: Mozart_-_Eine_kleine_Nachtmusik_-_1._Allegro.ogg > Ogg Vorbis stream: 2 channel, 44100 Hz > Title: ADVENT CHAMBER ORCHESTRA Artist=Roxanna Pavel Goldstein, Musical > Director > ERROR: Cannot open device sndio. > > > I tried running sndiod in debug mode: > > bsd$ doas sndiod - > snd0 pst=cfg.default: rec=0:1 play=0:1 vol=8388608 dup > snd0 pst=cfg.0: rec=0:1 play=0:1 vol=8388608 dup > snd1 pst=cfg.1: rec=0:1 play=0:1 vol=8388608 dup > snd2 pst=cfg.2: rec=0:1 play=0:1 vol=8388608 dup > snd3 pst=cfg.3: rec=0:1 play=0:1 vol=8388608 dup > helper(helper|ini): created > poll: helper: 1 > worker(worker|ini): created > listen(/tmp/sndio/sock0|ini): created > default/server.device=0:1 at 1 -> opt_dev:default/0: added > default/server.device=1:0 at 2 -> opt_dev:default/1: added > default/server.device=2:0 at 3 -> opt_dev:default/2: added > default/server.device=3:0 at 4 -> opt_dev:default/3: added > poll: listen: 1 worker: 1 > sock(sock|ini): created > listen(/tmp/sndio/sock0|ini): processed in 226us > worker(worker|ini): processed in 1us > sock,rmsg,widl: no messages to build anymore, idling... > poll: sock: 1 listen: 1 worker: 1 > helper: recv: cmd = 0, num = 0, mode = 3, fd = -1 > helper: send: cmd = 3, num = 0, mode = 0, fd = -1 > helper(helper|ini): processed in 339us > poll: helper: 1 > helper: recv: cmd = 0, num = 0, mode = 1, fd = -1 > helper: send: cmd = 3, num = 0, mode = 0, fd = -1 > helper(helper|ini): processed in 105us > poll: helper: 1 > sock,rmsg,widl: reading 40 todo > sock,rmsg,widl: read full message > sock,rmsg,widl: AUTH message > sock,rmsg,widl: reading 40 todo > sock,rmsg,widl: read full message > sock,rmsg,widl: HELLO message > sock,rmsg,widl: hello from , mode = 1, ver 7 > app/ogg0.level=127 at 5 -> slot_level:ogg0: added > snd0 pst=cfg: device requested > worker: send: cmd = 0, num = 0, mode = 3, fd = -1 > worker: recv: cmd = 3, num = 0, mode = 0, fd = -1 > worker: send: cmd = 0, num = 0, mode = 1, fd = -1 > worker: recv: cmd = 3, num = 0, mode = 0, fd = -1 > worker: send: cmd = 0, num = 0, mode = 2, fd = -1 > worker: recv: cmd = 3, num = 0, mode = 0, fd = -1 > snd0 pst=cfg: failed to open audio device > sock,rmsg,widl: closing > sock(sock|zom): destroyed > sock(sock|zom): processed in 8478us > listen(/tmp/sndio/sock0|ini): processed in 1us > worker(worker|ini): processed in 0us > poll: listen: 1 worker: 1 > helper: recv: cmd = 0, num = 0, mode = 2, fd = -1 > helper: send: cmd = 3, num = 0, mode = 0, fd = -1 > helper(helper|ini): processed in 206us > poll: helper: 1 > ^Cpoll: helper: 1 > helper: hup > helper(helper|zom): destroyed > helper(helper|zom): processed in 54us > nothing to do... > worker(worker|zom): destroyed > listen(/tmp/sndio/sock0|zom): destroyed > default/server.device=0:1 at 1 -> opt_dev:default/0: removed > default/server.device=1:0 at 2 -> opt_dev:default/1: removed > default/server.device=2:0 at 3 -> opt_dev:default/2: removed > default/server.device=3:0 at 4 -> opt_dev:default/3: removed > snd0 pst=cfg: draining > snd1 pst=cfg: draining > snd2 pst=cfg: draining > snd3 pst=cfg: draining > nothing to do... > snd0 pst=cfg: deleting > snd1 pst=cfg: deleting > snd2 pst=cfg: deleting > snd3 pst=cfg: deleting > > Below is my dmesg output: > > OpenBSD 7.4 (GENERIC.MP) #1382: Wed Sep 27 10:51:31 MDT 2023 > dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP > real mem = 2068180992 (1972MB) > avail mem = 1985822720 (1893MB) > random: good seed from bootblocks > mpath0 at root > scsibus0 at mpath0: 256 targets > mainbus0 at root > bios0 at mainbus0: SMBIOS rev. 3.0 @ 0x1fee8000 (17 entries) > bios0: vendor coreboot version "MrChromebox-4.20.1" date 07/21/2023 > bios0: GOOGLE Setzer > efi0 at bios0: UEFI 2.7 > efi0: EDK II rev 0x1 > acpi0 at bios0: ACPI 6.0 > acpi0: sleep states S0 S1 S3 S4 S5 > acpi0: tables DSDT FACP SSDT MCFG TCPA APIC HPET TCPA BGRT > acpi0: wakeup devices XHCI(S3) > acpitimer0 at acpi0: 3579545
Re: cleaning up /usr/local/lib after (many) upgrades?
On Jan 27 22:39:30, a...@lists.gxis.de wrote: > ...on 2024-01-27 20:44:07, Jan Stary wrote: > > > > > does pkg_delete -a help? It should remove all the packages not > needed, > > > I tried pkg_delete -a earlier today, but while it gave me a bunch > > > of files that I think were from base (/usr/X11R6 mostly), it didn't > > > turn up anything from /usr/local on this system. > > pkg_delete will never remove anything from base. > > Show the actual ouput. > > Yes, I mixed that up. What I was thinking of when writing that > answer was actually the output of pkg_check -F > > As of now, pkg_delete -an will look like this: Well there you go: remove these with pkg_delete -a > -- cut -- > # pkg_delete -an > .libs1-libvpx-1.7.0v0: ok > .libs1-icu4c-67.1: ok > t1lib-5.1.2p0: ok > .libs1-curl-7.64.1p1: ok > blas-3.8.0p1:lapack-3.8.0p2: ok > .libs1-python-3.6.9: ok > .libs-gd-2.1.1p3: ok > libmilter-8.18.0.2:opendkim-2.10.3p3: ok > libmilter-8.18.0.2: ok > .libs-libffi-3.3p1: ok > .libs-mariadb-client-10.0.38v1: ok > .libs-isc-bind-9.16.6v0: ok > .libs-gettext-runtime-0.21.1: ok > .libs1-png-1.6.35p0: ok > .libs-jpeg-1.5.3v0: ok > .libs1-snappy-1.1.7p0: ok > .libs1-oniguruma-6.9.1: ok > .libs-gettext-runtime-0.20.1p1: ok > .libs-isc-bind-9.11.4pl2: ok > .libs-libuv-1.30.1: ok > .libs-lz4-1.8.3: ok > .libs1-libvpx-1.10.0v0: ok > .libs1-libmagic-5.32: ok > .libs-protobuf-2.4.1p6: ok > .libs1-libvpx-1.6.1p0: ok > .libs1-libinotify-20180201: ok > .libs-giflib-5.1.6: ok > .libs1-icu4c-71.1v0: ok > .libs1-libxml-2.9.5: ok > libbind-6.0p7v0: ok > .libs1-isc-bind-9.16.9v0: ok > .libs1-icu4c-57.1: ok > .libs-oniguruma-6.9.0: ok > .libs1-dovecot-2.2.36p0: ok > .libs1-libwebp-0.5.2: ok > libmcrypt-2.5.8p2: ok > .libs1-isc-bind-9.11.19v0: ok > .libs-icu4c-68.2v0: ok > libvpx-1.13.1v0: ok > .libs-python-3.7.10: ok > .libs1-tiff-4.0.6p1: ok > .libs-mariadb-client-10.6.9v1: ok > .libs1-pcre2-10.36: ok > .libs-nghttp3-0.9.0: ok > .libs1-lz4-0.131p1: ok > .libs-luajit-2.0.4p0: ok > .libs-lapack-3.7.1p1: ok > .libs-libvpx-1.12.0v0: ok > .libs-icu4c-63.1: ok > .libs1-json-c-0.12p2: ok > .libs1-glib2-2.54.3p1: ok > .libs1-libvpx-1.5.0p0: ok > fann-2.2.0: ok > .libs-icu4c-58.2p0: ok > .libs1-protobuf-3.13.0: ok > .libs1-isc-bind-9.10.4pl6: ok > .libs-oniguruma-6.9.7.1: ok > .libs1-zstd-1.4.5p0: ok > pcre-8.45: ok > .libs1-python-3.8.13p0: ok > .libs-gcc-libs-4.9.4p18: ok > .libs1-libzip-1.5.2: ok > .libs1-mariadb-client-10.5.12p0v1: ok > .libs-json-c-0.13.1p0: ok > .libs-libxml-2.9.13p1: ok > .libs1-protobuf-3.9.1p0: ok > .libs-libxml-2.9.10p3: ok > .libs1-libgcrypt-1.9.4: ok > .libs-gd-2.3.2: ok > .libs1-libvpx-1.11.0p1v0: ok > .libs1-libbind-6.0p4v0: ok > .libs1-libusb1-1.0.23p2: ok > .libs-protobuf-3.11.4: ok > .libs-zstd-1.3.8: ok > .libs-protobuf-3.6.1: ok > .libs1-tiff-4.4.0p2: ok > re2c-3.1: ok > .libs-ngtcp2-0.13.1: ok > .libs1-snappy-1.1.8: ok > .libs-oniguruma-6.9.4: ok > .libs1-tiff-4.2.0: ok > .libs-protobuf-3.19.3: ok > .libs-libvpx-1.9.0v0: ok > .libs-libxml-2.10.4: ok > -- cut -- > > > > Alex. > > >
Re: cleaning up /usr/local/lib after (many) upgrades?
On Jan 27 17:46:07, a...@lists.gxis.de wrote: > I'm looking at one of my OpenBSD systems here that has been upgraded > over a long time, and has /usr/local running out of space. > > It seems there's a lot of old versions of shared libraries in > /usr/local/lib, like for example: > > > # ls -al /usr/local/lib/libvpx.so.* > > -rw-r--r-- 1 root bin 1909442 Mar 27 2018 /usr/local/lib/libvpx.so.10.0 > > -rw-r--r-- 1 root bin 2047296 Oct 11 2018 /usr/local/lib/libvpx.so.11.0 > > -rw-r--r-- 1 root bin 3182104 Apr 19 2021 /usr/local/lib/libvpx.so.12.0 > > -rw-r--r-- 1 root bin 2049592 Sep 26 2021 /usr/local/lib/libvpx.so.13.0 > > -rw-r--r-- 1 root bin 2062112 Sep 29 2022 /usr/local/lib/libvpx.so.14.0 > > -rw-r--r-- 1 root bin 2057584 Mar 25 2023 /usr/local/lib/libvpx.so.15.0 > > -rw-r--r-- 1 root bin 2069504 Oct 6 00:20 /usr/local/lib/libvpx.so.16.0 > > -rw-r--r-- 1 root bin 1869707 Jul 26 2016 /usr/local/lib/libvpx.so.7.0 > > -rw-r--r-- 1 root bin 1909806 Oct 2 2017 /usr/local/lib/libvpx.so.8.0 > > Is this expected, or a result of some error I made during upgrades? That's definitely weird. Which packages own these files? $ pkg_info -E /usr/local/lib/libvpx.so.8.0 $ doas pkg_check -Fq > Usually I'm just running pkg_add -u to pull fresh versions of packages. > And is there some "standard" way to get rid of the old versions? pkg_add generally replaces the old version with the new versions. > I could probably compare whatever is there against the pkglocate > database or check each file against pkglocate individually and parse > the output or something That's what pkg_info -F does.
Re: drm on MacBook Air (M1)
On Jan 23 21:09:10, h...@stare.cz wrote: > these are the errors drm reports: > > Jan 23 15:03:49 mb /bsd: drm:pid35173:iomfb_poweroff_v12_3 *ERROR* > dcp_poweroff() done > Jan 23 15:27:35 mb /bsd: drm:pid35173:iomfb_poweron_v12_3 *ERROR* > dcp_poweron() starting > Jan 23 16:05:40 mb /bsd: drm:pid35173:iomfb_poweroff_v12_3 *ERROR* > dcp_poweroff() done > Jan 23 16:09:07 mb /bsd: drm:pid35173:iomfb_poweron_v12_3 *ERROR* > dcp_poweron() starting > Jan 23 16:20:30 mb /bsd: drm:pid35173:iomfb_poweroff_v12_3 *ERROR* > dcp_poweroff() done > Jan 23 16:20:49 mb /bsd: drm:pid35173:iomfb_poweron_v12_3 *ERROR* > dcp_poweron() starting > Jan 23 16:30:49 mb /bsd: drm:pid35173:iomfb_poweroff_v12_3 *ERROR* > dcp_poweroff() done > Jan 23 16:32:23 mb /bsd: drm:pid35173:iomfb_poweron_v12_3 *ERROR* > dcp_poweron() starting > Jan 23 16:44:46 mb /bsd: drm:pid35173:iomfb_poweroff_v12_3 *ERROR* > dcp_poweroff() done > Jan 23 17:19:17 mb /bsd: drm:pid35173:iomfb_poweron_v12_3 *ERROR* > dcp_poweron() starting > Jan 23 17:33:51 mb /bsd: drm:pid35173:iomfb_poweroff_v12_3 *ERROR* > dcp_poweroff() done > Jan 23 17:35:18 mb /bsd: drm:pid35173:iomfb_poweron_v12_3 *ERROR* > dcp_poweron() starting > Jan 23 17:47:09 mb /bsd: drm:pid35173:iomfb_poweroff_v12_3 *ERROR* > dcp_poweroff() done > Jan 23 17:49:58 mb /bsd: drm:pid35173:iomfb_poweron_v12_3 *ERROR* > dcp_poweron() starting > Jan 23 18:02:08 mb /bsd: drm:pid35173:iomfb_poweroff_v12_3 *ERROR* > dcp_poweroff() done > Jan 23 19:20:16 mb /bsd: drm:pid35173:iomfb_poweron_v12_3 *ERROR* > dcp_poweron() starting > Jan 23 19:30:34 mb /bsd: drm:pid35173:iomfb_poweroff_v12_3 *ERROR* > dcp_poweroff() done > Jan 23 19:41:14 mb /bsd: drm:pid35173:iomfb_poweron_v12_3 *ERROR* > dcp_poweron() starting > > That pid is the X process. The times are when the screensaver kicks in. > After 'xset s blank s activate', the screen blanks for a moment, > but lights backup up almost immediately, dimmed; after Fn+F2 > (on this macbook) it lights up fully. How can I debug this? Also, video does not light back up after closing and opening the lid. This is with machdep.lidaction=0: Jan 23 21:59:02 mb /bsd: drm:pid60117:iomfb_poweroff_v12_3 *ERROR* dcp_poweroff() done Jan 23 21:59:02 mb /bsd: uhub0 detached Jan 23 21:59:02 mb /bsd: uhub1 detached Jan 23 21:59:27 mb /bsd: uhub0 at usb0 configuration 1 interface 0 "Generic xHCI root hub" rev 3.00/1.00 addr 1 Jan 23 21:59:27 mb /bsd: uhub1 at usb1 configuration 1 interface 0 "Generic xHCI root hub" rev 3.00/1.00 addr 1 Jan 23 21:59:27 mb /bsd: drm:pid60117:iomfb_poweron_v12_3 *ERROR* dcp_poweron() starting Jan 23 21:59:27 mb /bsd: aplsmc0: system 1.03 W After opening the lid, the machine apparently gets operating again, as witnessed by the pinging ping pinging the pings again (to another machine), but the screen remains black. Jan
drm on MacBook Air (M1)
This is current/arm64 on an M1 MacBook Air; current dmesg and previous dmesg below. The biggest difference seems to be drm replacing simplefb (thank you): -"dcp" at simplebus0 not configured -"display-subsystem" at simplebus0 not configured +apldcp0 at simplebus0 +apldrm0 at simplebus0 +drm0 at apldrm0 -simplefb0 at mainbus0: 2560x1600, 32bpp -wsdisplay0 at simplefb0 mux 1: console (std, vt100 emulation), using wskbd0 -wsdisplay0: screen 1-5 added (std, vt100 emulation) +"framebuffer" at mainbus0 not configured +apldrm0: 2560x1600, 32bpp +wsdisplay0 at apldrm0 mux 1: console (std, vt100 emulation), using wskbd0 +wsdisplay0: screen 1-5 added (std, vt100 emulation) Now that this works, should apldrm(4) be mentioned in the drm(4) manpage like the other drms? Index: drm.4 === RCS file: /cvs/src/share/man/man4/drm.4,v retrieving revision 1.13 diff -u -p -r1.13 drm.4 --- drm.4 7 Jan 2022 00:44:17 - 1.13 +++ drm.4 23 Jan 2024 19:11:41 - @@ -33,6 +33,9 @@ .Cd "amdgpu* at pci?" .Cd "drm* at amdgpu?" .Cd "wsdisplay* at amdgpu?" +.Cd "apldrm* at fdt?" +.Cd "drm* at apldrm?" +.Cd "wsdisplay* at apldrm?" .Pp .Cd "# amd64, i386" .Cd "inteldrm* at pci?" I am adding this to the "# arm64" section; is apldrm also relevant to the other Apple platforms? (I am not at my macppc machine now.) While here, is fdt some generic "device tree" pseudodevice? My apldrm is at simplebus. Please excuse my devtree ignorance. A lot of devices are configured at fdt in the GENERIC config, but no fdt appears in any of my dmesgs on any machine. Also, while it runs, apparently without problems, these are the errors drm reports: Jan 23 15:03:49 mb /bsd: drm:pid35173:iomfb_poweroff_v12_3 *ERROR* dcp_poweroff() done Jan 23 15:27:35 mb /bsd: drm:pid35173:iomfb_poweron_v12_3 *ERROR* dcp_poweron() starting Jan 23 16:05:40 mb /bsd: drm:pid35173:iomfb_poweroff_v12_3 *ERROR* dcp_poweroff() done Jan 23 16:09:07 mb /bsd: drm:pid35173:iomfb_poweron_v12_3 *ERROR* dcp_poweron() starting Jan 23 16:20:30 mb /bsd: drm:pid35173:iomfb_poweroff_v12_3 *ERROR* dcp_poweroff() done Jan 23 16:20:49 mb /bsd: drm:pid35173:iomfb_poweron_v12_3 *ERROR* dcp_poweron() starting Jan 23 16:30:49 mb /bsd: drm:pid35173:iomfb_poweroff_v12_3 *ERROR* dcp_poweroff() done Jan 23 16:32:23 mb /bsd: drm:pid35173:iomfb_poweron_v12_3 *ERROR* dcp_poweron() starting Jan 23 16:44:46 mb /bsd: drm:pid35173:iomfb_poweroff_v12_3 *ERROR* dcp_poweroff() done Jan 23 17:19:17 mb /bsd: drm:pid35173:iomfb_poweron_v12_3 *ERROR* dcp_poweron() starting Jan 23 17:33:51 mb /bsd: drm:pid35173:iomfb_poweroff_v12_3 *ERROR* dcp_poweroff() done Jan 23 17:35:18 mb /bsd: drm:pid35173:iomfb_poweron_v12_3 *ERROR* dcp_poweron() starting Jan 23 17:47:09 mb /bsd: drm:pid35173:iomfb_poweroff_v12_3 *ERROR* dcp_poweroff() done Jan 23 17:49:58 mb /bsd: drm:pid35173:iomfb_poweron_v12_3 *ERROR* dcp_poweron() starting Jan 23 18:02:08 mb /bsd: drm:pid35173:iomfb_poweroff_v12_3 *ERROR* dcp_poweroff() done Jan 23 19:20:16 mb /bsd: drm:pid35173:iomfb_poweron_v12_3 *ERROR* dcp_poweron() starting Jan 23 19:30:34 mb /bsd: drm:pid35173:iomfb_poweroff_v12_3 *ERROR* dcp_poweroff() done Jan 23 19:41:14 mb /bsd: drm:pid35173:iomfb_poweron_v12_3 *ERROR* dcp_poweron() starting That pid is the X process. The times are when the screensaver kicks in. After 'xset s blank s activate', the screen blanks for a moment, but lights backup up almost immediately, dimmed; after Fn+F2 (on this macbook) it lights up fully. How can I debug this? Thank you for the continuous improvements. Jan before: OpenBSD 7.4-current (GENERIC.MP) #0: Wed Dec 27 11:51:08 CET 2023 h...@mb.stare.cz:/usr/src/sys/arch/arm64/compile/GENERIC.MP real mem = 7991373824 (7621MB) avail mem = 7619371008 (7266MB) random: good seed from bootblocks mainbus0 at root: Apple MacBook Air (M1, 2020) efi0 at mainbus0: UEFI 2.10 efi0: Das U-Boot rev 0x20230700 cpu0 at mainbus0 mpidr 0: Apple Icestorm r1p1 cpu0: 128KB 64b/line 8-way L1 VIPT I-cache, 64KB 64b/line 8-way L1 D-cache cpu0: 4096KB 128b/line 16-way L2 cache cpu0: TLBIOS+IRANGE,TS+AXFLAG,FHM,DP,SHA3,RDM,Atomic,CRC32,SHA2+SHA512,SHA1,AES+PMULL,SPECRES,SB,FRINTTS,GPI,LRCPC+LDAPUR,FCMA,JSCVT,API+PAC,DPB,SpecSEI,PAN+ATS1E1,LO,HPDS,VH,CSV3,CSV2,DIT,SBSS+MSR cpu1 at mainbus0 mpidr 1: Apple Icestorm r1p1 cpu1: 128KB 64b/line 8-way L1 VIPT I-cache, 64KB 64b/line 8-way L1 D-cache cpu1: 4096KB 128b/line 16-way L2 cache cpu1: TLBIOS+IRANGE,TS+AXFLAG,FHM,DP,SHA3,RDM,Atomic,CRC32,SHA2+SHA512,SHA1,AES+PMULL,SPECRES,SB,FRINTTS,GPI,LRCPC+LDAPUR,FCMA,JSCVT,API+PAC,DPB,SpecSEI,PAN+ATS1E1,LO,HPDS,VH,CSV3,CSV2,DIT,SBSS+MSR cpu2 at mainbus0 mpidr 2: Apple Icestorm r1p1 cpu2: 128KB 64b/line 8-way L1 VIPT I-cache, 64KB 64b/line 8-way L1 D-cache cpu2: 4096KB 128b/line 16-way L2 cache cpu2:
Re: bioctl: Can't locate device
On Jan 22 13:53:17, open...@mlst.nl wrote:
> Hi Jan,
>
> I followed the Disk FAQ, foe UEFI.
> https://www.openbsd.org/faq/faq14.html#softraid
>
> # fdisk -gy -b 532480 sd1
> # fdisk -gy -b 532480 sd2
> # fdisk -gy -b 532480 sd3
> # fdisk -gy -b 532480 sd4
>
> For all of them I did:
> # disklabel -E sd1
> sd1> a a
> offset: [64]
> size: [39825135] *
> FS type: [4.2BSD] RAID
> sd1*> w
> sd1> q
>
> # bioctl -c 1 -l sd1a,sd2a softraid0
To be clear: this creates sd5 ...
> # bioctl -c 1 -l sd3a,sd4a softraid0
... and this creates sd6, right?
> # dd if=/dev/zero of=/dev/rsd5c bs=1m count=1
> # dd if=/dev/zero of=/dev/rsd6c bs=1m count=1
>
> After that newfs.
How exactly? newfs sd5a?
Without any fdisk or disklabel on the newly created sd5?
What does disklabel sd5 say?
> One thing I forgot:
> root@epyc1:~ # sysctl hw | grep drive
> hw.sensors.softraid0.drive0=online (sd5), OK
> hw.sensors.softraid0.drive1=online (sd6), OK
>
> Mischa
>
> On 2024-01-22 12:56, Jan Stary wrote:
> > How exactly did you create the sd5 SR RAID 1 and the sd6 SR RAID 1?
> >
> > On Jan 22 12:23:36, open...@mlst.nl wrote:
> > > Hi All,
> > >
> > > I created to softraid0 drives, following the FAQ.
> > > ALl seems to be working without problems, however bioctl isn’t able
> > > to “see”
> > > the softraid0 drives, sd5 and sd6.
> > >
> > > root@epyc1:~ # dmesg | egrep 'sd([0-6])'
> > > sd0 at scsibus1 targ 0 lun 0:
> > > t10.ATA_DELLBOSS_VD_37b61d1b1f560010_
> > > sd0: 457798MB, 512 bytes/sector, 937571968 sectors, thin
> > > sd1 at scsibus2 targ 1 lun 0:
> > > sd1: 7630885MB, 512 bytes/sector, 15628053168 sectors
> > > sd2 at scsibus3 targ 1 lun 0:
> > > sd2: 7630885MB, 512 bytes/sector, 15628053168 sectors
> > > sd3 at scsibus6 targ 1 lun 0:
> > > sd3: 7630885MB, 512 bytes/sector, 15628053168 sectors
> > > sd4 at scsibus7 targ 1 lun 0:
> > > sd4: 7630885MB, 512 bytes/sector, 15628053168 sectors
> > > sd5 at scsibus9 targ 1 lun 0:
> > > sd5: 7630625MB, 512 bytes/sector, 15627520063 sectors
> > > sd6 at scsibus9 targ 2 lun 0:
> > > sd6: 7630625MB, 512 bytes/sector, 15627520063 sectors
> > > root on sd0a (964c4608967fd9ca.a) swap on sd0b dump on sd0b
> > >
> > > root@epyc1:~ # for i in $(jot 7 0); do bioctl sd${i}; done
> > > sd0: , serial 37b61d1b1f560010
> > > sd1: , serial (unknown)
> > > sd2: , serial (unknown)
> > > sd3: , serial (unknown)
> > > sd4: , serial (unknown)
> > > bioctl: Can't locate sd5 device via /dev/bio
> > > bioctl: Can't locate sd6 device via /dev/bio
> > >
> > > root@epyc1:~ # df -h
> > > Filesystem SizeUsed Avail Capacity Mounted on
> > > /dev/sd0a 986M107M830M12%/
> > > /dev/sd0l 277G192K263G 1%/home
> > > /dev/sd0d 3.9G 10.0K3.7G 1%/tmp
> > > /dev/sd0f 29.1G1.3G 26.3G 5%/usr
> > > /dev/sd0g 986M288M648M31%/usr/X11R6
> > > /dev/sd0h 19.4G 23.8M 18.4G 1%/usr/local
> > > /dev/sd0k 5.8G2.0K5.5G 1%/usr/obj
> > > /dev/sd0j 2.9G2.0K2.8G 1%/usr/src
> > > /dev/sd5c 7.0T367G6.3T 6%/var
> > > /dev/sd6c 7.0T670G6.0T10%/var/data
> > >
> > > Any idea?
> > >
> > > Mischa
> > >
> > >
>
>
Re: disk not found after first reboot
On Jan 20 17:48:01, i...@lyberth.dk wrote: > Installation goes just fine. I sellect the disk (whole disk) auto > partition, create user, install the files. At the end it asks to reboot > halt or go to shell. No error messages, i just reboot, and get the no > bootable device found message You are rebooting with the usb install media out, right? If are using GPT, have you tried MBR? Boot the install media again, but don't reinstall; go to shell and get the output of fdisk and disklabel on the _target_ disk, i.e. the one you installed on.
Re: disk not found after first reboot
On Jan 20 16:43:54, i...@lyberth.dk wrote: > I had the disk in my windows pc, had diskmgr make a gpt drive of it and > then i could use the disk in OoenBsd. As I said: don't complicate it with other OSes. You don't need to massage your disk with win diskmgr prior to an openbsd installation; the installer will take care of the paritioning. So, reinstall anew; what do the last lines of the successfull install say?
Re: disk not found after first reboot
> > /dev/sd0c represents the whole drive, so dd should be pointed at it. > > You should need to dd anything "Shouldn't", obviously.
Re: disk not found after first reboot
On Jan 20 05:12:40, nothingn...@citycable.ch wrote: > > On 19/01/2024 01:38, Isak Lyberth wrote: > > Hello guys, I am sorry to bother you with such a basic question. > > After many years of only using my favorite OS on my firewall, I have > > decided to install OpenBSD 7.4 on my Dell Latitude 7490 laptop, fitted with > > a 500 GB Samsung 980 (non pro) nvme disk i use the entire disk with auto > > partitioning). > > it had Windows on it when iÍ got it, I removed it and used Linux Mint for > > about a week and now i have installed OpenBSD 7.4. i have tried it a lot of > > times, clearing the disk with the dd if=/dev/zero of=/dev/sd0 command and > > also dd'd to sd0a, rsd0 and anything i could think of, i also tried exiting > > to shell and done some fdisk -iy sd0 (suggested on reddit) > > I have tested that I can get FreeBSD and Dragonfly bsd installed on the > > laptop. > > > > I will gladly supply more info if needed. > > But how do I get my laptop to boot OpenBSD? > > > > Kind regards Isak > > Hi, > > /dev/sd0c represents the whole drive, so dd should be pointed at it. You should need to dd anything as a part of installation, and zeroing out a disk will surely not fix you booting problem. > If you're having beginner > problems, try using gpartdisk from a Linux flash drive to create an A6 > partition and then installing OpenBSD. No. If you're having beginner problems, start with a dedicated machine where nothing matters and practice there. In particular, don't bring other OSes into it. Jan
Re: Partition completely wiped out, why?
On Jan 11 01:35:20, p...@jbechtel.de wrote: > TL;DR - maybe the reason is some bad interaction between Linux mount > with wrong -o ufstype=old with following BSD auto-fsck on boot? I don't suppose linux's mount of a wrong type or obsd's autofsck would wipe the filesystem clean. > > > What also may be noted is that the ufs magic 0x00011954 (or, > > > 1954 0001, in hexdump switched 2-bytes) was present at position > > > 0x255c and 0x455c and several times at larger offsets. > > > > Could these be copies of the superblock? > > How to find out? Does this help? # scan_ffs -v wd0j man fsck says: -b block# Causes fsck to use the specified block as the location of the superblock. Block 32 is usually an alternate super block. So I'm guessing yes, these are copies of the superblock. > block 32 id 5351628a,266db641 size 900728 > block 6624 id 6581,4040010 size 4 > block 414688 id 5351628a,266db641 size 900728 > block 829344 id 5351628a,266db641 size 900728 > block 1244000 id 5351628a,266db641 size 900728 > block 1255916 id 95be8,c4834800 size 50640872 > block 1658656 id 5351628a,266db641 size 900728 > block 2073312 id 5351628a,266db641 size 900728 > block 2487968 id 5351628a,266db641 size 900728 > block 2902624 id 5351628a,266db641 size 900728 > block 3317280 id 5351628a,266db641 size 900728 > scan_ffs: read: Invalid argument > > Where? Into that same small partition? > > On another disk in that same machine? > > On other partitions on that same disk? > > OK, so here's an overview: > > old MBR table (read from one of the rare backups): >Partition 1 20480s -> 614400s (290MiB) ext2 "bootpart" >Partition 2614400s -> 4333568s (1.8GiB) 0xA6 (OpenBSD) >Partition 3 4333568s -> 2768s (7.5GiB) ext4 "main_system" >Partition 4 2768s -> 20971520s (474MiB) Linux swap > > old disklabel (partition 2 of old MBR table, again from backup): >Partition a614400s -> 4217312s (1.7GiB) type 7 (4.2BSD) >Partition b 4217312s -> 4333565s ( 57MiB) type 1 (swap) >Partition c 0s -> 20971520s ( 10GiB) type 0 (unused) >Partition i 20480s -> 614400s (209MiB) type 17 (unknown) >Partition j 4333568s -> 2768s (7.5GiB) type 17 (unknown) >Partition k 2768s -> 20971520s (474MiB) type 10 (other) To be sure: this is not what a fdisk or disklabel output looks like. So where exactly is this coming from? Also, how did you end up having partitions i, j, k, named like that? Is that what you did in your 5.4 install? > recent MBR table: >Partition 1 0s ->0s0x00 (unused) >Partition 2 0s ->0s0x00 (unused) >Partition 3 0s ->0s0x00 (unused) >Partition 464s -> 20971520s ( 10GiB) 0xA6 (OpenBSD) > > recent disklabel (partition 4) >Partition b 4217312s -> 5628288s 4.2BSD / Surely partition 'a'. Are you typing these by hand? Can you post the actual fdisk and disklabel output? >Partition b 5628288s -> 6152576s swapnone >Partition c 0s -> 20971520s unused >Partition d 17471040s -> 20971520s 4.2BSD /usr >Partition e 6162576s -> 13153248s 4.2BSD /var >Partition f 13153248s -> 17471040s 4.2BSD /home >Partition i 20480s -> 614400s unknown >Partition j614400s -> 4217312s 4.2BSD (/oldbsd5) > > > > assigned a mount point to the old partition, "/oldbsd5", which > > > worked on first boot. I just saw the usual files usr, mnt, ... when > > > invoking "ls /oldbsd5", assumed it was working then. Must have, if you could mount it and ls it. > > To be clear: you installed 7.4 somewhere else > > and just mounted the old small partition from > > the new 7.4 install, seeing the old data. > > Uh-oh, good question. I try to recall. Well, that's what you just said: the old partition being wd0j of the new install, being mountable and listable. Are you sure you didn't simply rewrite it during the 7.4 install? (Being in place, i.e. within the same sectors, but newfs'd empty.) > I tried to mount the partition in Rescue Linux. (not -o ro probably) I When? After you saw it as empty under you new 7.4 install? Why? > guess this "succeeded" but when trying ls /mnt/ I got some error. What error? > This failed because the UFS type selection defaulted wrong. Then I chose the > right UFS type with -o ufstype=44bsd, maybe -o ufstype=44bsd,ro > After mounting with right ufstype, I saw right data. (Probably this is > what I remember. Files in root directory looked well there) Well, could you also do the same from within your new 7.4 install? (Why would you bring another OS into it?) > In installation I went to manual disklabel edit. One of the steps there > was to assign the mount point /oldbsd5 there. Assigning a mount point does not mean the installer will not newfs it; you assign a mount point to the fresh filestystems too ... > > > Automatic
Re: File corruption on SSD disk
On Jan 09 16:40:48, obsd.t...@randy.pensive.org wrote:
> I'm running OpenBSD on a Protectli box as a router/firewall. The disk is an
> SSD. Every now and then I reboot it ("sudo shutdown -r now") just to make
> sure it comes back up. Several times it hung on disk errors that the auto
> 'fsck' can't fix. I was able to manually run 'fsck' and answer its prompts
> to clean up the problems, which sometimes were unreferenced inodes or
> similar things. It deleted some files in /var. The system runs OK, so
> perhaps the files aren't used in my minimal setup.
>
> I have two questions:
>
> (1) In "/etc/rc" I changed [fsck -p "$@"] to [fsck -f "$@"] in an attempt to
> get it to force fix problems, so the system could recover without someone
> manually doing it. That didn't work (it still stopped startup with the disk
> errors), so I tried making it [do_fsck -f -y] but that didn't work either.
> How does one make the system recover (e.g., how would an unstaffed/dark
> computer operations center do it)?
>
> (2) Why would the system develop disk problems? Might the SSD be failing?
Of course.
> Should I proactively replace it?
There's hardly anything proactive about it,
it it's showing unrecoverable fsck errors already.
> If I do replace it, should I start fresh
> with a clean install versus cloning the current disk?
Definitely a clean install on another disk.
> By the way, the SSD is a Samsung SSD 870 EVO 500GB (only using a tiny bit of
> it). Micromat's Lifespan says it has 100% life left, and their Tech Tools
> Pro found no bad blocks.
Boot from the new clean install
and read the entire old disk with dd if=/dev/sdXc
Jan
Re: Partition completely wiped out, why?
On Jan 10 00:21:12, p...@jbechtel.de wrote: > Ten years ago I installed OpenBSD 5.[?] which included setting up a > small partition of 2 GB, including the full OS with kernel, programs, > web-related data, etc.. Why did you install everything in one small partition? > What also may be noted is that the ufs magic 0x00011954 (or, > 1954 0001, in hexdump switched 2-bytes) was present at position 0x255c > and 0x455c and several times at larger offsets. Could these be copies of the superblock? > (very helpful, this > post: https://bugzilla.kernel.org/show_bug.cgi?id=197733; looked > similar to mine few days ago) That says "unable to mount UFS", while yours was a perfectly fine system, AFAIU. > This weekend I installed OpenBSD 7.4. Where? Into that same small partition? On another disk in that same machine? On other partitions on that same disk? > Finally I reconstructed the partition table What partition table? You had one partition. > (fresh MBR pointing to the still intact disklabel) > assigned a mount point to the old partition, "/oldbsd5", which worked > on first boot. I just saw the usual files usr, mnt, ... when invoking > "ls /oldbsd5", assumed it was working then. To be clear: you installed 7.4 somewhere else and just mounted the old small partition from the new 7.4 install, seeing the old data. > Automatic fstab entry was > [hash].j /oldbsd5 ffs rw,nodev,nosuid 1 2 What do you mean by "automatic"? Surely the installer didn't create an "/oldbsd5" mountpoint. > Then I deleted "rw," Why? > from fstab and maybe rebooted the system once or > twice. I'm pretty sure that I never made rm -rf on that directory. "Pretty sure," he said. You cannot rm a mounted point, so if it was indeed mounted, "rm -rf /oldbsd5" wouldn't work. (But "rm -rf /oldbsd5/*" would.) > Then > I found out (with df -h) that the partition is empty. Show the df -h output. > Really actually > empty, so theres no hidden file, no file, no lost+found, just nothing. Show the fstab and the disklabel and output of mount -v > The data, however, is still scattered on disk. I can see the lines of > known text files with grep. Grepping what, the /dev/sdXj ? > I also can see the signature at 0x455c, but > not any more at 0x255c. fsck doesn't find anything problematic. So what does fsck /oldbsd5 actually say? Is the partition actually mounted? Jan
Re: Why the mail filter?
There's nothing to "confront". Go away. On Dec 25 05:31:13, mikee...@firemail.cc wrote: > Got a problem with my emails? Can't confront me man to man? Like fucking > faggot scum? > >
Re: cumbersome mtree (OT!) - Process to have RADXIDE (MIT) among ports
wrong list, wrong subject On Dec 09 21:47:21, my2...@has.im wrote: > > Hello, > > I just reached version 1.2.5 of RADXIDE (MIT license), turned around > many bugs, templetized its colors, contacted previous snippets code > authors figuring in About. > > Now, I'm wondering what is eventually the process to have RADXIDE as > a small package inside OpenBSD. > > Nevertheless this would like the last invitation to try the software to > check it out. > > Thnx, > > == Nowarez Market > > > > Nowarez Market wrote: > > > > For who is wondering (and not) I come from publishing RADXIDE ver > > 1.0.5 (tcl-tk, MIT license) I could appreciate anyone involvement or > > feedback. > > > > https://radxide.com > > https://github.com/par7133/RADXIDE > >
Re: ls in color
On Dec 08 19:41:23, cahlu...@planet.nl wrote: > In openBSD V7.4 I would like to see the output of ls in color, and therefore > would like to know how to configure that. The output of "man ls" provides no > information about this. Can anyone give me a tip? Put your brown goggles on.
Re: FAT names exceeding spec length
People have already explained to you that 8 + 1 + 3 is less than 255. Can you kindly shut the fuck up already? On Dec 05 13:59:11, my2...@has.im wrote: > Thanks for the reply. > > Absolutely perceived, I haven't counted them. But I counted the 8.3 format > for true: > all the info contained in my ebook title was lost (but experimenting it is no > problem). > > Now I checked better. Indeed it is Opera web browser that is able to save on > Android 11 exceeding > the name limits: > Tcl_Tk 8.5 Programming Cookbook -- Bert Wheeler -- 2011 -- Packt -- > 9781849512992 -- 9ed273d2c640e4ae4761242a2c28d31c -- Capitan Cloud Ebook > Repo.pdf > > Android as per your guessing is enforcing the name limits here and there, > "enough" well. > > However, this the situation. Cutting to 8.3 format or being more conservative? > That could be the question for you. But indeed I leave the subect to you now. > > > == Nowarez Market > > Dec 5, 2023 12:29:30 Anders Andersson : > > > Wonder if OP is actually seeing more than 255 unique "User-perceived > > characters" or just more than 255 bytes? > >
Re: Realtek 8723BE unsupported
On Dec 04 11:16:04, da...@gwynne.id.au wrote: > On Sun, Dec 03, 2023 at 06:02:03PM +0100, Jan Stary wrote: > > (please keep replies on the list) > > > > On Dec 03 12:08:08, kolip...@exoticsilicon.com wrote: > > > On Sun, Dec 03, 2023 at 02:35:11PM +0100, Jan Stary wrote: > > > > This is current/amd64 on a HP 260 G2 mini PC (dmesg below). > > > > Everything works, except the wifi seems to be unsupported: > > > > > > > > "Realtek 8723BE" rev 0x00 at pci2 dev 0 function 0 not configured > > > > > > What does pcidump -v show? > > > > First of all, pcidump -v (but not pcidump) fucks up re(4): > > > > rgephy0 detached > > re0 detached > > re0 at pci1 dev 0 function 0 "Realtek 8168" rev 0x10: RTL8168GU/8111GU > > (0x5080), msi, address 7c:d3:0a:21:eb:f5 > > rgephy0 at re0 phy 7: RTL8251 PHY, rev. 0 > > re0: cannot create re-stats kstat > > rgephy0 detached > > re0 detached > > re0 at pci1 dev 0 function 0 "Realtek 8168" rev 0x10: RTL8168GU/8111GU > > (0x5080), msi, address 7c:d3:0a:21:eb:f5 > > rgephy0 at re0 phy 7: RTL8251 PHY, rev. 0 > > re0: cannot create re-stats kstat > > > > Is anyone seeing that, i.e. devices detaching > > when they are being probed by pcidump? > > > > After doing the pcidump -v localy and rebooting to upload, I get this. > > Note that the Realtek 8168 entry seems mangled (related to the above?). > > pcidump causing a device to detach is a problem, but the kstat bit is a > separate problem too. > > the diff below consolidates the detach code in re(4) and adds the code > to tear the kstat down when the device goes away. With the diff, this is what messages say during pcidump -v: rgephy0 detached re0 detached re0 at pci1 dev 0 function 0 "Realtek 8168" rev 0x10: RTL8168GU/8111GU (0x5080), msi, address 7c:d3:0a:21:eb:f5 rgephy0 at re0 phy 7: RTL8251 PHY, rev. 0 So it seems re0 detaches and re-ataches. Understandably, it loses the IP address, re0: flags=8802 mtu 1500 lladdr 7c:d3:0a:21:eb:f5 index 5 priority 0 llprio 3 media: Ethernet autoselect (1000baseT full-duplex) status: active but an /etc/netstart works as on boot and renews the dhcp lease. re0: flags=808843 mtu 1500 lladdr 7c:d3:0a:21:eb:f5 index 5 priority 0 llprio 3 groups: egress media: Ethernet autoselect (1000baseT full-duplex) status: active inet 192.168.11.28 netmask 0xff00 broadcast 192.168.11.255 The diff in the actual pcidump output is indeed in the re section (see previous): @@ -303,10 +303,6 @@ Domain /dev/pci0: 0x00b0: Capability 0x11: Extended Message Signalled Interrupts (MSI-X) Enabled: no; table size 4 (BAR 4:0) 0x00d0: Capability 0x03: Vital Product Data (VPD) - 00 - 00 - 00 - 00 7f: [|vpd] Anyway, why does re detach at all. And does this reveal anything about the original question Realtek 8723BE support? Jan Domain /dev/pci0: 0:0:0: Intel Core 6G Host 0x: Vendor ID: 8086, Product ID: 1904 0x0004: Command: 0106, Status: 2090 0x0008: Class: 06 Bridge, Subclass: 00 Host, Interface: 00, Revision: 08 0x000c: BIST: 00, Header Type: 00, Latency Timer: 00, Cache Line Size: 00 0x0010: BAR empty () 0x0014: BAR empty () 0x0018: BAR empty () 0x001c: BAR empty () 0x0020: BAR empty () 0x0024: BAR empty () 0x0028: Cardbus CIS: 0x002c: Subsystem Vendor ID: 103c Product ID: 8184 0x0030: Expansion ROM Base Address: 0x0038: 0x003c: Interrupt Pin: 00 Line: 00 Min Gnt: 00 Max Lat: 00 0x00e0: Capability 0x09: Vendor Specific 0:2:0: Intel HD Graphics 520 0x: Vendor ID: 8086, Product ID: 1916 0x0004: Command: 0007, Status: 0010 0x0008: Class: 03 Display, Subclass: 00 VGA, Interface: 00, Revision: 07 0x000c: BIST: 00, Header Type: 00, Latency Timer: 00, Cache Line Size: 00 0x0010: BAR mem 64bit addr: 0xee00/0x0100 0x0018: BAR mem prefetchable 64bit addr: 0xd000/0x1000 0x0020: BAR io addr: 0xf000/0x0040 0x0024: BAR empty () 0x0028: Cardbus CIS: 0x002c: Subsystem Vendor ID: 103c Product ID: 8184 0x0030: Expansion ROM Base Address: 0x0038: 0x003c: Interrupt Pin: 01 Line: 0b Min Gnt: 00 Max Lat: 00 0x0040: Capability 0x09: Vendor Specific 0x0070: Capability 0x10: PCI
Re: Realtek 8723BE unsupported
(please keep replies on the list) On Dec 03 12:08:08, kolip...@exoticsilicon.com wrote: > On Sun, Dec 03, 2023 at 02:35:11PM +0100, Jan Stary wrote: > > This is current/amd64 on a HP 260 G2 mini PC (dmesg below). > > Everything works, except the wifi seems to be unsupported: > > > > "Realtek 8723BE" rev 0x00 at pci2 dev 0 function 0 not configured > > What does pcidump -v show? First of all, pcidump -v (but not pcidump) fucks up re(4): rgephy0 detached re0 detached re0 at pci1 dev 0 function 0 "Realtek 8168" rev 0x10: RTL8168GU/8111GU (0x5080), msi, address 7c:d3:0a:21:eb:f5 rgephy0 at re0 phy 7: RTL8251 PHY, rev. 0 re0: cannot create re-stats kstat rgephy0 detached re0 detached re0 at pci1 dev 0 function 0 "Realtek 8168" rev 0x10: RTL8168GU/8111GU (0x5080), msi, address 7c:d3:0a:21:eb:f5 rgephy0 at re0 phy 7: RTL8251 PHY, rev. 0 re0: cannot create re-stats kstat Is anyone seeing that, i.e. devices detaching when they are being probed by pcidump? After doing the pcidump -v localy and rebooting to upload, I get this. Note that the Realtek 8168 entry seems mangled (related to the above?). bzm# pcidump -v Domain /dev/pci0: 0:0:0: Intel Core 6G Host 0x: Vendor ID: 8086, Product ID: 1904 0x0004: Command: 0106, Status: 2090 0x0008: Class: 06 Bridge, Subclass: 00 Host, Interface: 00, Revision: 08 0x000c: BIST: 00, Header Type: 00, Latency Timer: 00, Cache Line Size: 00 0x0010: BAR empty () 0x0014: BAR empty () 0x0018: BAR empty () 0x001c: BAR empty () 0x0020: BAR empty () 0x0024: BAR empty () 0x0028: Cardbus CIS: 0x002c: Subsystem Vendor ID: 103c Product ID: 8184 0x0030: Expansion ROM Base Address: 0x0038: 0x003c: Interrupt Pin: 00 Line: 00 Min Gnt: 00 Max Lat: 00 0x00e0: Capability 0x09: Vendor Specific 0:2:0: Intel HD Graphics 520 0x: Vendor ID: 8086, Product ID: 1916 0x0004: Command: 0007, Status: 0010 0x0008: Class: 03 Display, Subclass: 00 VGA, Interface: 00, Revision: 07 0x000c: BIST: 00, Header Type: 00, Latency Timer: 00, Cache Line Size: 00 0x0010: BAR mem 64bit addr: 0xee00/0x0100 0x0018: BAR mem prefetchable 64bit addr: 0xd000/0x1000 0x0020: BAR io addr: 0xf000/0x0040 0x0024: BAR empty () 0x0028: Cardbus CIS: 0x002c: Subsystem Vendor ID: 103c Product ID: 8184 0x0030: Expansion ROM Base Address: 0x0038: 0x003c: Interrupt Pin: 01 Line: 0b Min Gnt: 00 Max Lat: 00 0x0040: Capability 0x09: Vendor Specific 0x0070: Capability 0x10: PCI Express Max Payload Size: 128 / 128 bytes Max Read Request Size: 128 bytes 0x0100: Enhanced Capability 0x1b: Process Address Space ID 0x0200: Enhanced Capability 0x0f: Address Translation Services 0x0300: Enhanced Capability 0x13: Page Request Interface 0x00ac: Capability 0x05: Message Signalled Interrupts (MSI) Enabled: yes 0x00d0: Capability 0x01: Power Management State: D0 0:8:0: Intel Core GMM 0x: Vendor ID: 8086, Product ID: 1911 0x0004: Command: 0006, Status: 0010 0x0008: Class: 08 System, Subclass: 80 Miscellaneous, Interface: 00, Revision: 00 0x000c: BIST: 00, Header Type: 00, Latency Timer: 00, Cache Line Size: 00 0x0010: BAR mem 64bit addr: 0xef22e000/0x1000 0x0018: BAR empty () 0x001c: BAR empty () 0x0020: BAR empty () 0x0024: BAR empty () 0x0028: Cardbus CIS: 0x002c: Subsystem Vendor ID: 103c Product ID: 8184 0x0030: Expansion ROM Base Address: 0x0038: 0x003c: Interrupt Pin: 01 Line: 0b Min Gnt: 00 Max Lat: 00 0x0090: Capability 0x05: Message Signalled Interrupts (MSI) Enabled: no 0x00dc: Capability 0x01: Power Management State: D0 0x00f0: Capability 0x13: PCI Advanced Features 0:20:0: Intel 100 Series xHCI 0x: Vendor ID: 8086, Product ID: 9d2f 0x0004: Command: 0106, Status: 0290 0x0008: Class: 0c Serial Bus, Subclass: 03 USB, Interface: 30, Revision: 21 0x000c: BIST: 00, Header Type: 80, Latency Timer: 00, Cache Line Size: 00 0x0010: BAR mem 64bit addr: 0xef21/0x0001 0x0018: BAR empty () 0x001c: BAR empty () 0x0020: BAR empty () 0x0024: BAR empty () 0x0028: Cardbus CIS: 0x
re(4) timeouts
This is current/amd64 on a HP 260 (a mini PC, dmesg below). Everything seems to work, with two exceptions: 1. The re0 keeps complaining about re0: watchdog timeout re0: stopping TXQ timed out! and never initializes enough to get an address. Is anyone seeing this with re(4)? Is that a driver issue? The machine boots windows (yet) from the internal disk where the NIC seems to work just fine, so I don't think it is a HW error. 2. The pckbc occasionaly complains abut pckbc: command timeout but the keyboards seems to be working just fine. Jan OpenBSD 7.4-current (GENERIC.MP) #1471: Thu Nov 30 07:57:45 MST 2023 dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP real mem = 8454909952 (8063MB) avail mem = 8179015680 (7800MB) random: good seed from bootblocks mpath0 at root scsibus0 at mpath0: 256 targets mainbus0 at root bios0 at mainbus0: SMBIOS rev. 2.8 @ 0xed1e0 (37 entries) bios0: vendor AMI version "02.25" date 03/10/2022 bios0: HP Pippin2 acpi0 at bios0: ACPI 5.0 acpi0: sleep states S0 S3 S4 S5 acpi0: tables DSDT FACP APIC FPDT FIDT MCFG HPET SSDT LPIT SSDT SSDT SSDT SSDT DBGP DBG2 SSDT SSDT UEFI SSDT DMAR DBGP acpi0: wakeup devices PEG0(S4) PEGP(S4) PEG1(S4) PEGP(S4) PEG2(S4) PEGP(S4) RP09(S4) PXSX(S4) RP10(S4) PXSX(S4) RP11(S4) PXSX(S4) RP12(S4) PXSX(S4) RP13(S4) PXSX(S4) [...] acpitimer0 at acpi0: 3579545 Hz, 24 bits acpimadt0 at acpi0 addr 0xfee0: PC-AT compat cpu0 at mainbus0: apid 0 (boot processor) cpu0: Intel(R) Core(TM) i3-6100U CPU @ 2.30GHz, 2194.89 MHz, 06-4e-03, patch 00f0 cpu0: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,SDBG,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,ABM,3DNOWP,PERF,ITSC,FSGSBASE,TSC_ADJUST,SGX,BMI1,HLE,AVX2,SMEP,BMI2,ERMS,INVPCID,RTM,MPX,RDSEED,ADX,SMAP,CLFLUSHOPT,PT,SRBDS_CTRL,MD_CLEAR,TSXFA,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,RSBA,MISC_PKG_CT,ENERGY_FILT,XSAVEOPT,XSAVEC,XGETBV1,XSAVES,MELTDOWN cpu0: 32KB 64b/line 8-way D-cache, 32KB 64b/line 8-way I-cache, 256KB 64b/line 4-way L2 cache, 3MB 64b/line 12-way L3 cache cpu0: smt 0, core 0, package 0 mtrr: Pentium Pro MTRR support, 10 var ranges, 88 fixed ranges cpu0: apic clock running at 24MHz cpu0: mwait min=64, max=64, C-substates=0.2.1.2.4.1.1.1, IBE cpu1 at mainbus0: apid 2 (application processor) cpu1: Intel(R) Core(TM) i3-6100U CPU @ 2.30GHz, 2194.89 MHz, 06-4e-03, patch 00f0 cpu1: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,SDBG,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,ABM,3DNOWP,PERF,ITSC,FSGSBASE,TSC_ADJUST,SGX,BMI1,HLE,AVX2,SMEP,BMI2,ERMS,INVPCID,RTM,MPX,RDSEED,ADX,SMAP,CLFLUSHOPT,PT,SRBDS_CTRL,MD_CLEAR,TSXFA,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,RSBA,MISC_PKG_CT,ENERGY_FILT,XSAVEOPT,XSAVEC,XGETBV1,XSAVES,MELTDOWN cpu1: 32KB 64b/line 8-way D-cache, 32KB 64b/line 8-way I-cache, 256KB 64b/line 4-way L2 cache, 3MB 64b/line 12-way L3 cache cpu1: smt 0, core 1, package 0 cpu2 at mainbus0: apid 1 (application processor) cpu2: Intel(R) Core(TM) i3-6100U CPU @ 2.30GHz, 2194.89 MHz, 06-4e-03, patch 00f0 cpu2: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,SDBG,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,ABM,3DNOWP,PERF,ITSC,FSGSBASE,TSC_ADJUST,SGX,BMI1,HLE,AVX2,SMEP,BMI2,ERMS,INVPCID,RTM,MPX,RDSEED,ADX,SMAP,CLFLUSHOPT,PT,SRBDS_CTRL,MD_CLEAR,TSXFA,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,RSBA,MISC_PKG_CT,ENERGY_FILT,XSAVEOPT,XSAVEC,XGETBV1,XSAVES,MELTDOWN cpu2: 32KB 64b/line 8-way D-cache, 32KB 64b/line 8-way I-cache, 256KB 64b/line 4-way L2 cache, 3MB 64b/line 12-way L3 cache cpu2: smt 1, core 0, package 0 cpu3 at mainbus0: apid 3 (application processor) cpu3: Intel(R) Core(TM) i3-6100U CPU @ 2.30GHz, 2194.89 MHz, 06-4e-03, patch 00f0 cpu3: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,SDBG,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,ABM,3DNOWP,PERF,ITSC,FSGSBASE,TSC_ADJUST,SGX,BMI1,HLE,AVX2,SMEP,BMI2,ERMS,INVPCID,RTM,MPX,RDSEED,ADX,SMAP,CLFLUSHOPT,PT,SRBDS_CTRL,MD_CLEAR,TSXFA,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,RSBA,MISC_PKG_CT,ENERGY_FILT,XSAVEOPT,XSAVEC,XGETBV1,XSAVES,MELTDOWN cpu3: 32KB 64b/line 8-way D-cache, 32KB 64b/line 8-way I-cache, 256KB 64b/line 4-way L2 cache, 3MB 64b/line 12-way L3 cache cpu3: smt 1, core 1,
Re: PineView not using the whole screen
On Nov 28 20:30:39, kolip...@exoticsilicon.com wrote: > On Sun, Nov 26, 2023 at 04:12:39PM +0100, Jan Stary wrote: > > Can I make the VGA output the default globaly, so that > > individual users don't need to xrandr in their .xsession? > > Does this /etc/xorg.conf fix it? Thanks for the hint, but no. See below. > Section "Device" > Identifier "My device" > Option "Monitor-VGA1" "My monitor" > EndSection > > Section "Monitor" > Identifier "My monitor" > Option "Primary" "true" > Option "PreferredMode" "1680x1050" > EndSection The Xorg log has this to say (full log below): [ 9246.525] (II) intel(0): switch to mode 1680x1050@60.0 on VGA1 using pipe 0, position (0, 0), rotation normal, reflection none [ 9246.555] (II) intel(0): switch to mode 1280x800@58.1 on LVDS1 using pipe 1, position (0, 0), rotation normal, reflection none [ 9246.573] (II) intel(0): Setting screen physical size to 430 x 270 So it recognizes the modes for the two putputs, and even recognizes the right physical size. But I am still seeing the same problem: a "maximalized" window will only occupy the upper left 1280x800 rectangle of the full 1680x1050 screen. Upon loging in via xenodm, xrandr says: Screen 0: minimum 8 x 8, current 1680 x 1050, maximum 32767 x 32767 LVDS1 connected primary 1280x800+0+0 (normal left inverted right x axis y axis) 338mm x 211mm 1280x800 58.14*+ 1280x720 59.8659.74 1024x768 60.00 1024x576 59.9059.82 960x540 59.6359.82 800x600 60.3256.25 864x486 59.9259.57 640x480 59.94 720x405 59.5158.99 640x360 59.8459.32 VGA1 connected 1680x1050+0+0 (normal left inverted right x axis y axis) 434mm x 270mm 1680x1050 59.95*+ 1280x1024 75.0260.02 1280x960 60.00 1152x864 75.00 1024x768 75.0360.00 832x624 74.55 800x600 75.0060.3256.25 640x480 75.0059.94 720x400 70.08 VIRTUAL1 disconnected (normal left inverted right x axis y axis) So the 1680x1050 mode is set, but that is only a mode of the VGA, which is _not_ the primary, LVDS is. Upon making VGA the primary via xrandr, as described before, the problem disappears, i.e. the running cwm starts making full screen windows full screen. (Same with other WM's, which makes me think it's a X problem, not a wm problem.) Repeating myself: does anyone please know th following? 1. Why are there two "outputs" recognized when the machine only has a (visible) VGA connected by a VGA cable to the monitor? 2. How can I make the VGA the primary globaly, so that users don't need to say that in their ~/.xsession ? Jan [ 9246.081] (--) checkDevMem: using aperture driver /dev/xf86 [ 9246.133] (--) Using wscons driver on /dev/ttyC4 [ 9246.171] X.Org X Server 1.21.1.9 X Protocol Version 11, Revision 0 [ 9246.171] Current Operating System: OpenBSD bzm.stare.cz 7.4 GENERIC.MP#1468 amd64 [ 9246.171] [ 9246.171] Current version of pixman: 0.42.2 [ 9246.171]Before reporting problems, check http://wiki.x.org to make sure that you have the latest version. [ 9246.171] Markers: (--) probed, (**) from config file, (==) default setting, (++) from command line, (!!) notice, (II) informational, (WW) warning, (EE) error, (NI) not implemented, (??) unknown. [ 9246.173] (==) Log file: "/var/log/Xorg.0.log", Time: Wed Nov 29 19:08:08 2023 [ 9246.174] (==) Using config file: "/etc/xorg.conf" [ 9246.174] (==) Using system config directory "/usr/X11R6/share/X11/xorg.conf.d" [ 9246.175] (==) No Layout section. Using the first Screen section. [ 9246.175] (==) No screen section available. Using defaults. [ 9246.175] (**) |-->Screen "Default Screen Section" (0) [ 9246.175] (**) | |-->Monitor "" [ 9246.177] (==) No device specified for screen "Default Screen Section". Using the first device section listed. [ 9246.177] (**) | |-->Device "My device" [ 9246.177] (==) No monitor specified for screen "Default Screen Section". Using a default monitor configuration. [ 9246.177] (==) Automatically adding devices [ 9246.177] (==) Automatically enabling devices [ 9246.177] (==) Not automatically adding GPU devices [ 9246.177] (==) Automatically binding GPU devices [ 9246.177] (==) Max clients allowed: 256, resource mask: 0x1f [ 9246.178] (==) FontPath set to: /usr/X11R6/lib/X11/fonts/misc/, /usr/X11R6/lib/X11/fonts/TTF/, /usr/X11R6/lib/X11/fonts/OTF/, /usr/X11R6/lib/X11/fonts/Type1/, /usr/X11R6/lib/X11/fonts/100dpi/, /usr/X11R6/lib/X11/fonts/75dpi/ [ 9246.178] (==) ModulePath set to
Re: PineView not using the whole screen
On Oct 20 16:46:32, h...@stare.cz wrote: > This is current/amd64 on a PC (dmesg and X log below). > > It seems that both X and the console only use > a portion of the available screen, in the upper left corner. > Please see the lame jpegs (sorry): > > the console > http://stare.cz/.tmp/fs4.jpeg > > the xenodm login screen > http://stare.cz/.tmp/fs3.jpeg > > a maximalized xterm with a tmux session > http://stare.cz/.tmp/fs2.jpeg > > a maximalized firefox window > http://stare.cz/.tmp/fs1.jpeg > > (Maximalized means cwm's ctrl+alt+f, > but it's the same with other window managers.) > > What's strange is that X somehow "knows" the actual size, > as the xconsole box is in the actual lower right corner. > > The booting sequence (white on blue) uses the whole screen, until > > inteldrm0: 1280x800, 32bpp > > where the monitor "blinks", and starting with > > wsdisplay0 at inteldrm0 mux 1: console (std, vt100 emulation), using wskbd0 > > the booting kernel only uses that portion of the scren. > That makes me *suspect* it's a inteldrm problem. According to xrandr -q Screen 0: minimum 8 x 8, current 1680 x 1050, maximum 32767 x 32767 LVDS1 connected 1280x800+0+0 (normal left inverted right x axis y axis) 338mm x 211mm 1280x800 58.14*+ 1280x720 59.8659.74 1024x768 60.00 1024x576 59.9059.82 960x540 59.6359.82 800x600 60.3256.25 864x486 59.9259.57 640x480 59.94 720x405 59.5158.99 640x360 59.8459.32 VGA1 connected primary 1680x1050+0+0 (normal left inverted right x axis y axis) 434mm x 270mm 1680x1050 59.95*+ 1280x1024 75.0260.02 1280x960 60.00 1152x864 75.00 1024x768 75.0360.00 832x624 74.55 800x600 75.0060.3256.25 640x480 75.0059.94 720x400 70.08 Only one monitor is attached to the PC, with a VGA cable. Apparently, the X subsystem somehow recognizes two outputs, the LVDS1 and the VGA1, and considers the smaller LVDS, with its preferred mode of 1280x800, the primary. The mm dimensions reported are correct in that the 338x211 is exactly the portion of the not-full screen a "maximalized" window will use, while the monitor itself is 434x270 mm. (xdpyinfo also says the monitor is 338x211.) Setting xrandr --output VGA1 --primary works around the problem. Why are there two outputs recognized for the monitor? Can I make the VGA output the default globaly, so that individual users don't need to xrandr in their .xsession? Jan $ xrandr --verbose Screen 0: minimum 8 x 8, current 1680 x 1050, maximum 32767 x 32767 LVDS1 connected 1280x800+0+0 (0x45) normal (normal left inverted right x axis y axis) 338mm x 211mm Identifier: 0x41 Timestamp: 982221 Subpixel: horizontal rgb Gamma: 1.0:1.0:1.0 Brightness: 1.0 Clones: CRTC: 1 CRTCs: 1 Transform: 1.00 0.00 0.00 0.00 1.00 0.00 0.00 0.00 1.00 filter: BACKLIGHT: 15625 range: (0, 15625) Backlight: 15625 range: (0, 15625) scaling mode: Full aspect supported: Full, Center, Full aspect link-status: Good supported: Good, Bad non-desktop: 0 range: (0, 1) 1280x800 (0x45) 68.900MHz -HSync -VSync *current +preferred h: width 1280 start 1292 end 1340 total 1440 skew0 clock 47.85KHz v: height 800 start 804 end 807 total 823 clock 58.14Hz 1280x720 (0x14f) 74.500MHz -HSync +VSync h: width 1280 start 1344 end 1472 total 1664 skew0 clock 44.77KHz v: height 720 start 723 end 728 total 748 clock 59.86Hz 1280x720 (0x150) 63.750MHz +HSync -VSync h: width 1280 start 1328 end 1360 total 1440 skew0 clock 44.27KHz v: height 720 start 723 end 728 total 741 clock 59.74Hz 1024x768 (0x151) 65.000MHz -HSync -VSync h: width 1024 start 1048 end 1184 total 1344 skew0 clock 48.36KHz v: height 768 start 771 end 777 total 806 clock 60.00Hz 1024x576 (0x152) 46.500MHz -HSync +VSync h: width 1024 start 1064 end 1160 total 1296 skew0 clock 35.88KHz v: height 576 start 579 end 584 total 599 clock 59.90Hz 1024x576 (0x153) 42.000MHz +HSync -VSync h: width 1024 start 1072 end 1104 total 1184 skew0 clock 35.47KHz v: height 576 start 579 end 584 total 593 clock 59.82Hz 960x540 (0x154) 40.750MHz -HSync +VSync h: width 960 start 992 end 1088 total 1216 skew0 clock 33.51KHz v: height 540 start 543 end 548 total 562 clock 59.63Hz 960x540 (0x155) 37.250MHz +HSync -VSync h: width 960 start 1008 end 1040 total 1120
Re: Upgrading from 7.3 to 7.4 with sysupgrade
IF you have a good reason to not let sysupgrade do a full install (space? on my RPI that's the case), you can simply sysupgrade -sfn rm /home/_sysupgrade/x* reboot
Re: Default Revival of a ten years old computer : how would you do it?
On Nov 06 11:29:22, h...@mailo.com wrote: > since few months im discovering openbsd ; as linux has been often recommended > for windows's users with a very slow system, i guess that it's not that > unadvised to use openbsd with a GUI for web browsing and little software (eg > LO, gimp..) the fact that linux "has been often recommended" has nothing to do with whether openbsd will work for you. > i have tested "recent" openbsd releases, since 2022, > and almost all of them are a bit slow with xfce/firefox etc. That depends largely on the machine. If you have a specific machine in mind, this email should include a dmesg. > i was wondering, for laptops range of 2013/16 years old, > what would you recommmend them for a common web browsing using openbsd? Common web browsing using openbsd means install the base system and then pkg_add firefox. There are much more lightweight window managers than xfce, such as the base cwm. Whether that will be "slow" is anybody's guess as we known nothing about your machine. That being said, I happily run firefox on older Thinkpads similar to the one below (a 2014 Thinkpad E145). Jan OpenBSD 7.2-current (GENERIC.MP) #911: Wed Dec 28 10:45:43 MST 2022 dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP real mem = 5647761408 (5386MB) avail mem = 5459165184 (5206MB) random: good seed from bootblocks mpath0 at root scsibus0 at mpath0: 256 targets mainbus0 at root bios0 at mainbus0: SMBIOS rev. 2.7 @ 0xbe5c4000 (47 entries) bios0: vendor LENOVO version "HSET57WW (2.02 )" date 02/24/2014 bios0: LENOVO 20BCMC acpi0 at bios0: ACPI 5.0 acpi0: sleep states S0 S3 S4 S5 acpi0: tables DSDT FACP HPET APIC MCFG SBST FPDT UEFI MSDM UEFI SSDT SSDT UEFI SSDT SSDT SSDT SSDT SSDT acpi0: wakeup devices GPP0(S4) GPP1(S4) GPP2(S4) GPP3(S4) GFX_(S4) XHC0(S3) OHC1(S3) EHC2(S3) OHC3(S3) EHC3(S3) SBAZ(S4) LID_(S4) acpitimer0 at acpi0: 3579545 Hz, 32 bits acpihpet0 at acpi0: 14318180 Hz acpimadt0 at acpi0 addr 0xfee0: PC-AT compat cpu0 at mainbus0: apid 0 (boot processor) cpu0: AMD E1-2500 APU with Radeon(TM) HD Graphics, 1397.40 MHz, 16-00-01 cpu0: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,HTT,SSE3,PCLMUL,MWAIT,SSSE3,CX16,SSE4.1,SSE4.2,MOVBE,POPCNT,AES,XSAVE,AVX,F16C,NXE,MMXX,FFXSR,PAGE1GB,RDTSCP,LONG,LAHF,CMPLEG,SVM,EAPICSP,AMCR8,ABM,SSE4A,MASSE,3DNOWP,OSVW,IBS,SKINIT,TOPEXT,DBKP,PCTRL3,ITSC,BMI1,XSAVEOPT cpu0: 32KB 64b/line 8-way D-cache, 32KB 64b/line 2-way I-cache, 1MB 64b/line 16-way L2 cache cpu0: smt 0, core 0, package 0 mtrr: Pentium Pro MTRR support, 8 var ranges, 88 fixed ranges cpu0: apic clock running at 99MHz cpu0: mwait min=64, max=64, IBE cpu1 at mainbus0: apid 1 (application processor) cpu1: AMD E1-2500 APU with Radeon(TM) HD Graphics, 1397.40 MHz, 16-00-01 cpu1: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,HTT,SSE3,PCLMUL,MWAIT,SSSE3,CX16,SSE4.1,SSE4.2,MOVBE,POPCNT,AES,XSAVE,AVX,F16C,NXE,MMXX,FFXSR,PAGE1GB,RDTSCP,LONG,LAHF,CMPLEG,SVM,EAPICSP,AMCR8,ABM,SSE4A,MASSE,3DNOWP,OSVW,IBS,SKINIT,TOPEXT,DBKP,PCTRL3,ITSC,BMI1,XSAVEOPT cpu1: 32KB 64b/line 8-way D-cache, 32KB 64b/line 2-way I-cache, 1MB 64b/line 16-way L2 cache cpu1: smt 0, core 1, package 0 ioapic0 at mainbus0: apid 4 pa 0xfec0, version 21, 24 pins, remapped ioapic1 at mainbus0: apid 5 pa 0xfec01000, version 21, 32 pins, remapped acpimcfg0 at acpi0 acpimcfg0: addr 0xf800, bus 0-63 acpiprt0 at acpi0: bus 0 (PCI0) acpiprt1 at acpi0: bus 1 (GPP0) acpiprt2 at acpi0: bus 3 (GPP1) acpiprt3 at acpi0: bus -1 (GPP2) acpiprt4 at acpi0: bus 4 (GPP3) acpiprt5 at acpi0: bus -1 (GFX_) acpiec0 at acpi0 acpibtn0 at acpi0: PWRB acpipci0 at acpi0 PCI0: 0x0010 0x0011 0x acpicmos0 at acpi0 "SMB0001" at acpi0 not configured acpithinkpad0 at acpi0: version 1.0 acpiac0 at acpi0: AC unit offline acpibat0 at acpi0: BAT1 model "45N1174" serial 898 type LION oem "SANYO" acpibtn1 at acpi0: LID_ "PNP0C14" at acpi0 not configured "PNP0C14" at acpi0 not configured "ASD0001" at acpi0 not configured acpicpu0 at acpi0: C2(0@400 io@0x841), C1(@1 halt!), PSS acpicpu1 at acpi0: C2(0@400 io@0x841), C1(@1 halt!), PSS acpitz0 at acpi0: critical temperature is 100 degC acpivideo0 at acpi0: VGA_ acpivout0 at acpivideo0: LCD_ cpu0: 1397 MHz: speeds: 1400 1200 1000 900 800 MHz pci0 at mainbus0 bus 0 0:1:0: rom address conflict 0xfffe/0x2 pchb0 at pci0 dev 0 function 0 "AMD 16h Host" rev 0x00 radeondrm0 at pci0 dev 1 function 0 "ATI Kabini" rev 0x00 drm0 at radeondrm0 radeondrm0: msi azalia0 at pci0 dev 1 function 1 "ATI Radeon HD Audio" rev 0x00: msi azalia0: no supported codecs pchb1 at pci0 dev 2 function 0 vendor "AMD", unknown product 0x1538 rev 0x00 ppb0 at pci0 dev 2 function 2 "AMD 16h PCIE" rev 0x00: msi pci1 at ppb0 bus 1 rtwn0 at pci1 dev 0 function 0 "Realtek 8188CE" rev 0x01: msi rtwn0: MAC/BB RTL8188CE, RF 6052 1T1R, address 20:16:d8:41:c4:fd ppb1 at pci0 dev 2 function
Re: PineView not using the whole screen
It's realy getting tiresome. Take your incoherent rambling somewhere else. On Oct 26 12:15:47, my2...@has.im wrote: > Well, here for a secure OpenBSD I'm expecting a minimal usage of resources. > But I see..if inserting my physical keyboard I get two keyboard devices > attached to run a sleep > button properly on a *consumer multimedia product* well..I missed mayb the > point and > everything is questionable. > > Then, if you are asking tips on how to attack my working station by injection > of keystrocks on a > pseudo keyboard device I have no clue but is it important indeed? > > ( I also asked you in my previous posts to stress test better this ucc driver > and parents because my bad > experiences with usb keyboards passing by an Aten KVM "Secure" switch, is it > anything enlightning? ) > > A little surprised, sincerelly. > > -- Daniele Bonini > > Oct 26, 2023 11:33:25 Crystal Kolipe : > > > On Thu, Oct 26, 2023 at 10:07:41AM +0200, Daniele B. wrote: > >> Just to specify I'm hoping you are going to solve this software issue in > >> the next releases (a properly running device driver is maybe better that > >> properly running sleep button at my side) > > > > What software issue are you talking about? > > > > Do you actually have any keyboards that don't work correctly with OpenBSD? > > > > What is the problem with the ucc driver attaching as well? Does it break > > anything? > >
Re: my first patch
On Oct 25 12:10:07, maria.mori...@icloud.com wrote: > > > SoX's play --ignore-length can play it. > > > SoX's --ignore-length appears in a few formats, as far as the wav format > goes, the code comments suggest it is implemented to handle 32-bit wav files > greater than 2GB. It seems you just found a happy side effect. --ignore-length Override an (incorrect) audio length given in an audio file's header. If this option is given then SoX will keep reading audio until it reaches the end of the input file.
Re: my first patch
On Oct 24 22:09:02, a...@caoua.org wrote: > faad -w file.m4a | cat >file.wav > results in a file with zero-size data chunk (because faad couldn't > seek to the beginning of the file to fixup the header). aucat, > audacious, audacity and sox can't play it; mpv, and ffplay can SoX's play --ignore-length can play it.
Re: X session doesn't survive zzz
On Oct 22 17:02:50, guent...@gmail.com wrote: > I would start by removing X from the picture and verify that suspend and > resume are working (or not) when X is not running. Are USB devices failing > to reattach or coming back in some weird mode which isn't working? Can you > ssh in? Without X running, everything seems to resume fine. For completeness, this is what /var/log/messages says about the suspend and resume. Oct 23 16:37:59 box apmd: system suspending Oct 23 16:37:59 box apmd: battery status: absent. external power status: not known. estimated battery life 0% Oct 23 16:38:23 box /bsd: ukbd0: was console keyboard Oct 23 16:38:23 box /bsd: wskbd0 detached Oct 23 16:38:23 box /bsd: ukbd0 detached Oct 23 16:38:23 box /bsd: uhidev0 detached Oct 23 16:38:23 box /bsd: wskbd1: disconnecting from wsdisplay0 Oct 23 16:38:23 box /bsd: wskbd1 detached Oct 23 16:38:23 box /bsd: ucc0 detached Oct 23 16:38:23 box /bsd: uhid0 detached Oct 23 16:38:23 box /bsd: wskbd2: disconnecting from wsdisplay0 Oct 23 16:38:23 box /bsd: wskbd2 detached Oct 23 16:38:23 box /bsd: ucc1 detached Oct 23 16:38:23 box /bsd: uhidev1 detached Oct 23 16:38:23 box /bsd: wsmouse0 detached Oct 23 16:38:23 box /bsd: ums0 detached Oct 23 16:38:23 box /bsd: uhidev2 detached Oct 23 16:38:23 box /bsd: uhub3 detached Oct 23 16:38:23 box /bsd: uhub0 detached Oct 23 16:38:23 box /bsd: uhub1 detached Oct 23 16:38:23 box /bsd: uhub4 detached Oct 23 16:38:23 box /bsd: uhub2 detached Oct 23 16:38:23 box /bsd: uhub0 at usb0 configuration 1 interface 0 "Intel EHCI root hub" rev 2.00/1.00 addr 1 Oct 23 16:38:23 box /bsd: uhub1 at usb1 configuration 1 interface 0 "Etron xHCI root hub" rev 3.00/1.00 addr 1 Oct 23 16:38:23 box /bsd: uhub2 at usb2 configuration 1 interface 0 "Intel EHCI root hub" rev 2.00/1.00 addr 1 Oct 23 16:38:23 box apmd: system resumed from sleep Oct 23 16:38:23 box apmd: battery status: absent. external power status: not known. estimated battery life 0% Oct 23 16:38:24 box /bsd: uhub3 at uhub0 port 1 configuration 1 interface 0 "Intel Rate Matching Hub" rev 2.00/0.00 addr 2 Oct 23 16:38:25 box /bsd: uhidev0 at uhub3 port 5 configuration 1 interface 0 "Logitech USB Keyboard" rev 1.10/64.00 addr 3 Oct 23 16:38:25 box /bsd: uhidev0: iclass 3/1 Oct 23 16:38:25 box /bsd: ukbd0 at uhidev0: 8 variable keys, 6 key codes Oct 23 16:38:25 box /bsd: wskbd0 at ukbd0: console keyboard, using wsdisplay0 Oct 23 16:38:25 box /bsd: uhidev1 at uhub3 port 5 configuration 1 interface 1 "Logitech USB Keyboard" rev 1.10/64.00 addr 3 Oct 23 16:38:25 box /bsd: uhidev1: iclass 3/0, 3 report ids Oct 23 16:38:25 box /bsd: ucc0 at uhidev1 reportid 1: 2 usages, 3 keys, enum Oct 23 16:38:25 box /bsd: wskbd1 at ucc0 mux 1 Oct 23 16:38:25 box /bsd: wskbd1: connecting to wsdisplay0 Oct 23 16:38:25 box /bsd: uhid0 at uhidev1 reportid 2: input=1, output=0, feature=0 Oct 23 16:38:25 box /bsd: ucc1 at uhidev1 reportid 3: 21 usages, 14 keys, enum Oct 23 16:38:25 box /bsd: wskbd2 at ucc1 mux 1 Oct 23 16:38:25 box /bsd: wskbd2: connecting to wsdisplay0 Oct 23 16:38:26 box /bsd: uhidev2 at uhub3 port 6 configuration 1 interface 0 "Genius Optical Mouse" rev 1.10/1.00 addr 4 Oct 23 16:38:26 box /bsd: uhidev2: iclass 3/1 Oct 23 16:38:26 box /bsd: ums0 at uhidev2: 3 buttons, Z dir Oct 23 16:38:26 box /bsd: wsmouse0 at ums0 mux 0 Oct 23 16:38:26 box /bsd: uhub4 at uhub2 port 1 configuration 1 interface 0 "Intel Rate Matching Hub" rev 2.00/0.00 addr 2 (I have tried three times, the messages are identical.) > If that's working fine, then bring X back into the picture but capture > /var/log/Xorg.0.log both before suspending and then after resuming (ssh in > if necessary) and see what X is falling over on. See below for the X logs of a working and nonworking resume. Reproducibly, X resumes fine if I suspend from a console: ctrl-alt-f1 and zzz from there, ctrl-zlt-f5 after resume; firefox and all the xterms are still running. Reproducibly, X fails to resume when I zzz from an xterm, i.e. suspend from within the running X. The diff in X log suggests it's the kbd encoding that fails (-good +bad): -(II) config/wscons: checking input device /dev/wskbd -(II) wskbd: using layout us -(II) LoadModule: "kbd" -(II) Loading /usr/X11R6/lib/modules/input/kbd_drv.so -(II) Module kbd: vendor="X.Org Foundation" - compiled for 1.21.1.8, module version = 2.0.0 - Module class: X.Org XInput Driver - ABI class: X.Org XInput driver, version 24.4 -(II) Using input driver 'kbd' for '/dev/wskbd' -(**) /dev/wskbd: always reports core events -(**) /dev/wskbd: always reports core events -(**) Option "Protocol" "standard" -(**) Option "XkbRules" "base" -(**) Option "XkbModel" "pc105" -(**) Option "XkbLayout" "us" -(II) XINPUT: Adding extended input device "/dev/wskbd" (type: KEYBOARD, id 6) +(WW) wskbd: ioctl(WSKBDIO_GETENCODING) failed: Inappropriate ioctl for device Once I rcctl restart xenodm, everything works again, except the previously running X clients are dead.
Re: a2ps error; printing utf8 to a postscipt printer
On Oct 23 17:22:37, rsyk...@disroot.org wrote: > after upgrading to OpenBSD 7.4 (as far as I can tell), > a2ps program stopped working: Do you mean specificaly the upgrade of the base system, or the ugraded a2ps package? I doubt the _system_ upgrade itself broke a2ps ... > ;a2ps /home/ruda/mnt/tarkil/SIMUL/acceptance/accept1detE0.ijs What an ijs file and how does a2ps know it's a plain text file? Is that the default? > [/home/ruda/mnt/tarkil/SIMUL/acceptance/accept1detE0.ijs (plain): 2 pages on > 1 sheet] > Usage: a2ps-lpr-wrapper [-d printer] FILE... > a2ps: received SIGPIPE Who is the caller of a2ps-lpr-wrapper? Does a2ps itselt call it? Or some script you have? What your /etc/printcap ? > It seems to me that a2ps-lpr-wrapper expects a FILE argument, > while a2ps (which invokes the wrapper?) does not supply one... > > Has anybody else had this issue? > Thanks for comments. > > Loosely related: What program do you use to print utf8 > encoded text file to a postscipt printer? (Neither a2ps, nor > enscript does it. u2ps is in ports. > At this moment I either remove any > diacritics with 'recode -f utf8..flat ...', Or you can iconv -t to some encoding that a2ps supports. Jan
PineView not using the whole screen
This is current/amd64 on a PC (dmesg and X log below). It seems that both X and the console only use a portion of the available screen, in the upper left corner. Please see the lame jpegs (sorry): the console http://stare.cz/.tmp/fs4.jpeg the xenodm login screen http://stare.cz/.tmp/fs3.jpeg a maximalized xterm with a tmux session http://stare.cz/.tmp/fs2.jpeg a maximalized firefox window http://stare.cz/.tmp/fs1.jpeg (Maximalized means cwm's ctrl+alt+f, but it's the same with other window managers.) What's strange is that X somehow "knows" the actual size, as the xconsole box is in the actual lower right corner. The booting sequence (white on blue) uses the whole screen, until inteldrm0: 1280x800, 32bpp where the monitor "blinks", and starting with wsdisplay0 at inteldrm0 mux 1: console (std, vt100 emulation), using wskbd0 the booting kernel only uses that portion of the scren. That makes me *suspect* it's a inteldrm problem. (It is also puzzling that the booting sequence ends with inteldrm0: 1280x800, 32bpp wsdisplay0 at inteldrm0 mux 1: console (std, vt100 emulation), using wskbd0 wskbd1: connecting to wsdisplay0 wskbd2: connecting to wsdisplay0 wsdisplay0: screen 1-5 added (std, vt100 emulation) Needless to say, I only have one keyboard attached. Are there some devices being perhaps emulated as wskbds?) The X log starts with [27.357] (WW) checkDevMem: failed to open /dev/xf86 and /dev/mem (Operation not permitted) Check that you have set 'machdep.allowaperture=1' in /etc/sysctl.conf and reboot your machine refer to xf86(4) for details so I rebooted with machdep.allowaperture=1 but that doesn't seem to have changed anything. X log for that is also below, the diff being mostly + (--) checkDevMem: using aperture driver /dev/xf86 + (II) AIGLX: Suspending AIGLX clients for VT switch Disabling inteldrm in the kernel (dmesg also below) makes the booting kernel use the whole screen the whole time, but xenodm does not even start with vga as opposed to inteldrm (is that expected)? -inteldrm0 at pci0 dev 2 function 0 "Intel Pineview Video" rev 0x02 -drm0 at inteldrm0 -intagp0 at inteldrm0 -agp0 at intagp0: aperture at 0xe000, size 0x1000 -inteldrm0: apic 8 int 16, PINEVIEW, gen 3 +vga1 at pci0 dev 2 function 0 "Intel Pineview Video" rev 0x02 +wsdisplay0 at vga1 mux 1: console (80x25, vt100 emulation) +wsdisplay0: screen 1-5 added (80x25, vt100 emulation) -wskbd0 at pckbd0: console keyboard +wskbd0 at pckbd0: console keyboard, using wsdisplay0 -inteldrm0: 1280x800, 32bpp -wsdisplay0 at inteldrm0 mux 1: console (std, vt100 emulation), using wskbd0 -wsdisplay0: screen 1-5 added (std, vt100 emulation) How can I further debug this? Jan dmesg: OpenBSD 7.4-current (GENERIC.MP) #1411: Tue Oct 17 21:56:20 MDT 2023 dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP real mem = 8554905600 (8158MB) avail mem = 8275869696 (7892MB) random: good seed from bootblocks mpath0 at root scsibus0 at mpath0: 256 targets mainbus0 at root bios0 at mainbus0: SMBIOS rev. 2.5 @ 0xe69cb (27 entries) bios0: vendor Intel Corp. version "MWPNT10N.86A.0069.2010.0913.1432" date 09/13/2010 bios0: Intel Corporation D525MW acpi0 at bios0: ACPI 3.0 acpi0: sleep states S0 S1 S3 S4 S5 acpi0: tables DSDT FACP APIC MCFG HPET SSDT acpi0: wakeup devices SLPB(S4) UAR1(S4) UAR2(S4) P32_(S4) ILAN(S4) PEX0(S4) PEX1(S4) PEX2(S4) PEX3(S4) UHC1(S3) UHC2(S3) UHC3(S3) UHC4(S3) EHCI(S3) AZAL(S4) acpitimer0 at acpi0: 3579545 Hz, 24 bits acpimadt0 at acpi0 addr 0xfee0: PC-AT compat cpu0 at mainbus0: apid 0 (boot processor) cpu0: Intel(R) Atom(TM) CPU D525 @ 1.80GHz, 1800.19 MHz, 06-1c-0a, patch 0107 cpu0: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,DTES64,MWAIT,DS-CPL,TM2,SSSE3,CX16,xTPR,PDCM,MOVBE,NXE,LONG,LAHF,PERF,MELTDOWN cpu0: 512KB 64b/line 8-way L2 cache mtrr: Pentium Pro MTRR support, 7 var ranges, 88 fixed ranges cpu0: apic clock running at 200MHz cpu1 at mainbus0: apid 1 (application processor) cpu1: Intel(R) Atom(TM) CPU D525 @ 1.80GHz, 1800.27 MHz, 06-1c-0a, patch 0107 cpu1: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,DTES64,MWAIT,DS-CPL,TM2,SSSE3,CX16,xTPR,PDCM,MOVBE,NXE,LONG,LAHF,PERF,MELTDOWN cpu1: 512KB 64b/line 8-way L2 cache cpu2 at mainbus0: apid 2 (application processor) cpu2: Intel(R) Atom(TM) CPU D525 @ 1.80GHz, 1800.24 MHz, 06-1c-0a, patch 0107 cpu2: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,DTES64,MWAIT,DS-CPL,TM2,SSSE3,CX16,xTPR,PDCM,MOVBE,NXE,LONG,LAHF,PERF,MELTDOWN cpu2: 512KB 64b/line 8-way L2 cache cpu3 at mainbus0: apid 3 (application processor) cpu3: Intel(R) Atom(TM) CPU D525 @ 1.80GHz, 1800.34 MHz, 06-1c-0a, patch 0107 cpu3:
Re: X session doesn't survive zzz
On Oct 18 11:11:54, h...@stare.cz wrote: > This is current/amd64 on a PC (dmesg below). > After a resume from zzz inside a running X session, > I am greeted with the xenodm login screen > into which I cannot login: the keyboard does nothing > (is it the USB keyboard not reattaching properly?). > > Loging in on the console, To be clear: typing the username and passwd into the xenodm login screen does nothing, but on the console the kbd works as expeceted. > I see that the X session > and the X applications (firefox, xterms) are dead. > On the other hand, the mplayer that has been zzz'ed > inside a tmux session starts playing again. > > After restarting xenodm with rcctl restart xenodm, > I can log in and everything seems to work again. > > See the dmesg below, including the zzz and resume, > and the full X log up to here. How can I debug this? > > Jan > > > OpenBSD 7.4-current (GENERIC.MP) #1406: Sun Oct 15 10:34:05 MDT 2023 > dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP > real mem = 8285454336 (7901MB) > avail mem = 8014598144 (7643MB) > random: good seed from bootblocks > mpath0 at root > scsibus0 at mpath0: 256 targets > mainbus0 at root > bios0 at mainbus0: SMBIOS rev. 2.4 @ 0xf0100 (36 entries) > bios0: vendor Award Software International, Inc. version "F3" date 03/31/2011 > bios0: Gigabyte Technology Co., Ltd. H67MA-USB3-B3 > acpi0 at bios0: ACPI 1.0 > acpi0: sleep states S0 S3 S4 S5 > acpi0: tables DSDT FACP HPET MCFG ASPT SSPT EUDS MATS TAMG APIC SSDT > acpi0: wakeup devices PCI0(S5) PEX0(S5) PEX1(S5) PEX2(S5) PEX3(S5) PEX4(S5) > PEX5(S5) PEX6(S5) PEX7(S5) HUB0(S5) UAR1(S3) USBE(S3) USE2(S3) AZAL(S5) > acpitimer0 at acpi0: 3579545 Hz, 24 bits > acpihpet0 at acpi0: 14318179 Hz > acpimcfg0 at acpi0 > acpimcfg0: addr 0xf400, bus 0-63 > acpimadt0 at acpi0 addr 0xfee0: PC-AT compat > cpu0 at mainbus0: apid 0 (boot processor) > cpu0: Intel(R) Core(TM) i7-2600 CPU @ 3.40GHz, 3492.09 MHz, 06-2a-07, patch > 002f > cpu0: > FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,POPCNT,DEADLINE,AES,XSAVE,AVX,NXE,RDTSCP,LONG,LAHF,PERF,ITSC,MD_CLEAR,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,MELTDOWN > cpu0: 32KB 64b/line 8-way D-cache, 32KB 64b/line 8-way I-cache, 256KB > 64b/line 8-way L2 cache, 8MB 64b/line 16-way L3 cache > cpu0: smt 0, core 0, package 0 > mtrr: Pentium Pro MTRR support, 10 var ranges, 88 fixed ranges > cpu0: apic clock running at 99MHz > cpu0: mwait min=64, max=64, C-substates=0.2.1.1, IBE > cpu1 at mainbus0: apid 2 (application processor) > cpu1: Intel(R) Core(TM) i7-2600 CPU @ 3.40GHz, 3492.12 MHz, 06-2a-07, patch > 002f > cpu1: > FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,POPCNT,DEADLINE,AES,XSAVE,AVX,NXE,RDTSCP,LONG,LAHF,PERF,ITSC,MD_CLEAR,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,MELTDOWN > cpu1: 32KB 64b/line 8-way D-cache, 32KB 64b/line 8-way I-cache, 256KB > 64b/line 8-way L2 cache, 8MB 64b/line 16-way L3 cache > cpu1: smt 0, core 1, package 0 > cpu2 at mainbus0: apid 4 (application processor) > cpu2: Intel(R) Core(TM) i7-2600 CPU @ 3.40GHz, 3492.19 MHz, 06-2a-07, patch > 002f > cpu2: > FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,POPCNT,DEADLINE,AES,XSAVE,AVX,NXE,RDTSCP,LONG,LAHF,PERF,ITSC,MD_CLEAR,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,MELTDOWN > cpu2: 32KB 64b/line 8-way D-cache, 32KB 64b/line 8-way I-cache, 256KB > 64b/line 8-way L2 cache, 8MB 64b/line 16-way L3 cache > cpu2: smt 0, core 2, package 0 > cpu3 at mainbus0: apid 6 (application processor) > cpu3: Intel(R) Core(TM) i7-2600 CPU @ 3.40GHz, 3492.25 MHz, 06-2a-07, patch > 002f > cpu3: > FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,POPCNT,DEADLINE,AES,XSAVE,AVX,NXE,RDTSCP,LONG,LAHF,PERF,ITSC,MD_CLEAR,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,MELTDOWN > cpu3: 32KB 64b/line 8-way D-cache, 32KB 64b/line 8-way I-cache, 256KB > 64b/line 8-way L2 cache, 8MB 64b/line 16-way L3 cache > cpu3: smt 0, core 3, package 0 > cpu4 at mainbus0: apid 1 (application processor) > cpu4: Intel(R) Core(TM) i7-2600 CPU @ 3.40GHz, 3492.37 MHz, 06-2a-07, patch > 002f > cpu4: >
X session doesn't survive zzz
This is current/amd64 on a PC (dmesg below). After a resume from zzz inside a running X session, I am greeted with the xenodm login screen into which I cannot login: the keyboard does nothing (is it the USB keyboard not reattaching properly?). Loging in on the console, I see that the X session and the X applications (firefox, xterms) are dead. On the other hand, the mplayer that has been zzz'ed inside a tmux session starts playing again. After restarting xenodm with rcctl restart xenodm, I can log in and everything seems to work again. See the dmesg below, including the zzz and resume, and the full X log up to here. How can I debug this? Jan OpenBSD 7.4-current (GENERIC.MP) #1406: Sun Oct 15 10:34:05 MDT 2023 dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP real mem = 8285454336 (7901MB) avail mem = 8014598144 (7643MB) random: good seed from bootblocks mpath0 at root scsibus0 at mpath0: 256 targets mainbus0 at root bios0 at mainbus0: SMBIOS rev. 2.4 @ 0xf0100 (36 entries) bios0: vendor Award Software International, Inc. version "F3" date 03/31/2011 bios0: Gigabyte Technology Co., Ltd. H67MA-USB3-B3 acpi0 at bios0: ACPI 1.0 acpi0: sleep states S0 S3 S4 S5 acpi0: tables DSDT FACP HPET MCFG ASPT SSPT EUDS MATS TAMG APIC SSDT acpi0: wakeup devices PCI0(S5) PEX0(S5) PEX1(S5) PEX2(S5) PEX3(S5) PEX4(S5) PEX5(S5) PEX6(S5) PEX7(S5) HUB0(S5) UAR1(S3) USBE(S3) USE2(S3) AZAL(S5) acpitimer0 at acpi0: 3579545 Hz, 24 bits acpihpet0 at acpi0: 14318179 Hz acpimcfg0 at acpi0 acpimcfg0: addr 0xf400, bus 0-63 acpimadt0 at acpi0 addr 0xfee0: PC-AT compat cpu0 at mainbus0: apid 0 (boot processor) cpu0: Intel(R) Core(TM) i7-2600 CPU @ 3.40GHz, 3492.09 MHz, 06-2a-07, patch 002f cpu0: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,POPCNT,DEADLINE,AES,XSAVE,AVX,NXE,RDTSCP,LONG,LAHF,PERF,ITSC,MD_CLEAR,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,MELTDOWN cpu0: 32KB 64b/line 8-way D-cache, 32KB 64b/line 8-way I-cache, 256KB 64b/line 8-way L2 cache, 8MB 64b/line 16-way L3 cache cpu0: smt 0, core 0, package 0 mtrr: Pentium Pro MTRR support, 10 var ranges, 88 fixed ranges cpu0: apic clock running at 99MHz cpu0: mwait min=64, max=64, C-substates=0.2.1.1, IBE cpu1 at mainbus0: apid 2 (application processor) cpu1: Intel(R) Core(TM) i7-2600 CPU @ 3.40GHz, 3492.12 MHz, 06-2a-07, patch 002f cpu1: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,POPCNT,DEADLINE,AES,XSAVE,AVX,NXE,RDTSCP,LONG,LAHF,PERF,ITSC,MD_CLEAR,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,MELTDOWN cpu1: 32KB 64b/line 8-way D-cache, 32KB 64b/line 8-way I-cache, 256KB 64b/line 8-way L2 cache, 8MB 64b/line 16-way L3 cache cpu1: smt 0, core 1, package 0 cpu2 at mainbus0: apid 4 (application processor) cpu2: Intel(R) Core(TM) i7-2600 CPU @ 3.40GHz, 3492.19 MHz, 06-2a-07, patch 002f cpu2: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,POPCNT,DEADLINE,AES,XSAVE,AVX,NXE,RDTSCP,LONG,LAHF,PERF,ITSC,MD_CLEAR,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,MELTDOWN cpu2: 32KB 64b/line 8-way D-cache, 32KB 64b/line 8-way I-cache, 256KB 64b/line 8-way L2 cache, 8MB 64b/line 16-way L3 cache cpu2: smt 0, core 2, package 0 cpu3 at mainbus0: apid 6 (application processor) cpu3: Intel(R) Core(TM) i7-2600 CPU @ 3.40GHz, 3492.25 MHz, 06-2a-07, patch 002f cpu3: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,POPCNT,DEADLINE,AES,XSAVE,AVX,NXE,RDTSCP,LONG,LAHF,PERF,ITSC,MD_CLEAR,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,MELTDOWN cpu3: 32KB 64b/line 8-way D-cache, 32KB 64b/line 8-way I-cache, 256KB 64b/line 8-way L2 cache, 8MB 64b/line 16-way L3 cache cpu3: smt 0, core 3, package 0 cpu4 at mainbus0: apid 1 (application processor) cpu4: Intel(R) Core(TM) i7-2600 CPU @ 3.40GHz, 3492.37 MHz, 06-2a-07, patch 002f cpu4: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,POPCNT,DEADLINE,AES,XSAVE,AVX,NXE,RDTSCP,LONG,LAHF,PERF,ITSC,MD_CLEAR,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,MELTDOWN cpu4: 32KB 64b/line 8-way D-cache, 32KB 64b/line 8-way I-cache, 256KB 64b/line 8-way L2 cache, 8MB 64b/line 16-way L3 cache cpu4: smt 1, core 0, package 0 cpu5 at mainbus0: apid 3 (application processor) cpu5:
Re: reorder_kernel: failed
On Oct 17 18:20:01, cahlu...@planet.nl wrote: > > > Op 17-10-2023 om 16:53 schreef Jan Stary: > > On Oct 17 16:46:13, cahlu...@planet.nl wrote: > > > Hi all, > > > > > > After a new installation of openBSD 7.4 I received the following message: > > > "reorder_kernel: failed -- see > > > /usr/share/relink/kernel/GENERIC.MP/relink.log". That turns out to be a > > > zlib > > > compressed data file, and I don't know how to unpack or read it. Does > > > anyone > > > know how I can do that? > > That's supposed to be a text file (a log, duh). > > Have you looked at it? What makes you think it's a zlib file? > > > file /usr/share/relink/kernel/GENERIC.MP/relink.log Let's play the "how long can you make it" game: So what does zless display, if it's a zlib file? And what does less display, if it's a plaintext file? Have your tried those?
Re: reorder_kernel: failed
On Oct 17 16:46:13, cahlu...@planet.nl wrote: > Hi all, > > After a new installation of openBSD 7.4 I received the following message: > "reorder_kernel: failed -- see > /usr/share/relink/kernel/GENERIC.MP/relink.log". That turns out to be a zlib > compressed data file, and I don't know how to unpack or read it. Does anyone > know how I can do that? That's supposed to be a text file (a log, duh). Have you looked at it? What makes you think it's a zlib file?
Re: SSH from old Mac fail to login via ssh rsa key
Use an ed25519 key instead of the obsolete rsa key. Chances are the sshd server is refusing to work with the obsolete key. If you showed the actual ssh -v output, people would if that is the case. On Oct 08 19:44:36, my2...@has.im wrote: > Hello, > > While moving my stuff online I decided that it was the time to allow > more machines to login to my server. > > Indeed I have my usual old Mac that merits a chance to login to my cloud > server too.. ;) > > I went to my Mac (SSH -V: OpenSSH 6.9p1 LibreSSL 2.1.8) and launched > ssh-keygen produced for my my user a nice RSA key. I grabbed it and I > went on my > cloud server (SSH -V: OpenSSH 9.2p1 OpenSSL 3.0.9) and appended it in > my .ssh/authorized_keys. > > SSHD user authentication by password is disabled on the cloud server.. > > I rebooted the Mac and restarted SSH on the cloud server.. but > the Mac SSH continues to ask to me to login with the root password > instead to ask the RSA file password to access its public key. > >From the man I see that asking the root password is the last chance > given to the user to login if anything goes wrong.. > > Is there any chance to make Mac SSH login works by key or I can give it > up? > > Thanks! > > -- Daniele Bonini > >
Re: Webcam support on Lenovo Thinkpad T14 Gen3 (Intel)
On Oct 07 13:30:50, dco...@gmail.com wrote: > On Sat, Oct 7, 2023 at 1:26 PM Jan Stary wrote: > > > > On Oct 07 07:08:21, kolip...@exoticsilicon.com wrote: > > > On Sat, Oct 07, 2023 at 08:51:36AM +, Comte wrote: > > > > The webcam seems well detected but no image is displayed... > > > > To be sure: you have kern.audio.record=1, right? > > kern.video.record, not kern.audio.record. ECOFFEE, sorry
Re: Webcam support on Lenovo Thinkpad T14 Gen3 (Intel)
On Oct 07 07:08:21, kolip...@exoticsilicon.com wrote: > On Sat, Oct 07, 2023 at 08:51:36AM +, Comte wrote: > > The webcam seems well detected but no image is displayed... To be sure: you have kern.audio.record=1, right?
Re: I nuked my filesystem
On Sep 27 09:17:47, spritskills...@gmail.com wrote: > Thank you all for your replies. I needed to step away from my > computer last night so I apologize for the terse email. > sd0 is my physical hard disk with full disk encryption. I wrote a 5gb > iso over the beginning of sd1c (my softraid volume). > > > I am using a CRYPTO RAID partition and luckily I'm smart enough not to > > > nuke that. To be clear: having overwritten the starting 5GB of sd1c, but not of the underlying sd0c, you still have the CRYPTO volume on sd0c which you can attach with bioctl, right? Can you please confirm with disklabel -pg sd0 and bioctl? > I rebooted. I > installed openbsd on a separate drive, booted it, > mounted the encrypted volume, You mean attached it at softraid0 with bioctl(8), not "mounted" anything as in mount(8)ing a filesystem, right?
Re: I nuked my filesystem
On Sep 26 21:42:02, spritskills...@gmail.com wrote: > I did the thing. > dd'd a 5gb img to my ssd instead of my usb and I want to die. > dd if=file.iso of=/dev/sd1c At this point, you are supposed to tell what your disk layout is (or was :-). Is sd1 your boot disk? What partitions did it contain? Or is sd0 where your system is installed? In particular, do you still have /etc and /var/backups ? > I am using a CRYPTO RAID partition > and luckily I'm smart enough not to nuke that. Pray tell, what is that unnuked partition? Is that where your untouched base system still lives? > My ssd is 2TB so I believe it uses FFS2 by default. newfs makes FFS2 by default regardless of the size. > I'm hopelessly running scan_ffs on it So you still have /sbin/scan_ffs, so you still have /sbin. What else do you still have? How exactly are you running scan_ffs? > in case it was silently updated > or the man is wrong Meaning this? scan_ffs works only on FFS file systems, not FFS2 file systems. (I have no idea.) > or there's a God. There's no God. There's only backup. > Any advice on how to recover what's left? First you have to show what actually is left, i.e. what parts of the system are still available. Was sd1 a big /data disk such as /home, with the base system living elsewhere?
Re: Speed: dump/restore vs rsync
> While I can't comment on the actual numbers, one thing one could consider > when restoring (from any medium/type) into a new empty file system is that > you can mount the destination fs async during the restore in order to speed > it up a bit. I'll just add that mount(8) explicitly says so: The most common use of this flag is to speed up restore(8) where it can give a factor of two speed increase.
Re: Does openBSD come with a web browser?
On Sep 10 18:27:27, de...@mailbox.org wrote: > (I am considering getting a laptop with openBSD, but have > not yet done so, which is why I can't easily check on my own.) I doubt you will get a laptop with OpenBSD, more likely you will have to install OpenBSD yourself. (Which is not hard.) > Does openBSD come with a web browser? The "the FAQ and" parts of > https://www.openbsd.org/mail.html suggest that it does, but I haven't > found any more detail regarding this at https://www.openbsd.org/ . https://www.openbsd.org/faq/faq15.html pkg_add firefox lynx
Re: Update from 6.5 to 7.3
If it's a firewall, chances are that what it's worth is a few files in /etc. It might be much easier to backup, reinstall with 7.3 and give those few files some love. Jan On Sep 08 10:01:45, alessandro.ba...@gmail.com wrote: > Hi list, > I've a problem. I need to upgrade OpenBSD from 6.5 to 7.3 on an APU2D. This > is a firewall. > The problem is that I cannot find older ISO of OpenBSD. Can someone point me > in the right direction? > > Thank you in advance. > >
Re: "OpenBSD Doc" App idea
On Sep 07 18:19:29, my2...@has.im wrote: > Clearly I do not want to discriminate among > Windowz Doc, Mac Doc, Linux Doc and OpenBSD Doc > mobile apps, of the App Store ( the proposed order is clearly random) Learn to discriminate, for everyone's sake.
Re: "OpenBSD Doc" App idea
Without even reading ahead: you are either trolling or just fucking retarded. (Is that a haiku?) On Sep 07 16:27:18, my2...@has.im wrote: > Hello, > > Just pushing myself over any device limit.. > I just searched the App Stores for "Unix" and related ones > and wondering if we can hope to have an "OpenBSD Doc" > app beside a "FreeBSD Doc" app anytime soon? > > Anyone's offer? Yes I'm talking to you.. ;D > > -- Daniele Bonini > >
Re: Printing Via Wifi
It makes no difference that it's wifi. If the printer is network connected, you can set it up in printcap(5) as any other network-connected printer. Make sure that the printer speaks postscript natively. Otherwise, you will have to jump through hoops, installing a printer-specific filter/driver etc, which makes it much more complicated. On Sep 04 18:47:06, titomarifran...@gmail.com wrote: > Hi everyone, > Can somebody please point me to the proper resources on printing through > wifi? > I will have an Epson L3250 and wants to print from my OpenBSD 7.3 > laptop. This printer should work nicely with my office-issued Mac, and > wants to use it with my personal laptop running OpenBSD. > Advise would be greatly appreciated. > Thank you. >
Re: local video playback causes system to freeze
On Aug 29 06:08:25, subrat.k.l...@protonmail.com wrote: > Hi everyone, > I'm a new openbsd user trying to learn openbsd and use it as my daily > driver. I'm facing an issue with local video playback where the screen > gets stuck whenever I try to play any video and the only option I have > is to force reboot the system using the power button. Can you switch to console woith crtl-alt-f1? > I want to debug and fix the issue however I'm unable to figure out > where to start and what to check. It would be of great help if you > could point me out in the right direction. > > Here is the softwares that I've used - > window manager - cwm > video player - mpv, vlc Does the same happen with other video players, e.g. ffplay or mplayer? > The video playback on the browser(firefox) works perfectly fine > though. > > Here is the dmesg - > OpenBSD 7.3 (GENERIC.MP) #3: Tue Jul 25 08:20:26 MDT 2023 > > r...@syspatch-73-amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP > real mem = 8241840128 (7860MB) > avail mem = 7972634624 (7603MB) > random: good seed from bootblocks > mpath0 at root > scsibus0 at mpath0: 256 targets > mainbus0 at root > bios0 at mainbus0: SMBIOS rev. 3.4 @ 0x8f0a3000 (79 entries) > bios0: vendor LENOVO version "R1SET44W(1.15)" date 10/11/2022 > bios0: LENOVO 21E6S05E00 > efi0 at bios0: UEFI 2.7 > efi0: Lenovo rev 0x1150 > acpi0 at bios0: ACPI 6.3 > acpi0: sleep states S0 S4 S5 > acpi0: tables DSDT FACP SSDT SSDT SSDT SSDT SSDT SSDT TPM2 HPET APIC MCFG > ECDT SSDT SSDT SSDT SSDT SSDT SSDT LPIT WSMT SSDT DBGP DBG2 NHLT POAT SSDT > BATB SSDT SSDT SSDT BGRT PHAT UEFI FPDT > acpi0: wakeup devices PEG0(S4) PEGP(S4) PEGP(S4) PEG2(S4) PEGP(S4) GLAN(S4) > XHCI(S3) XDCI(S4) HDAS(S4) CNVW(S4) RP01(S4) PXSX(S4) RP02(S4) PXSX(S4) > PXSX(S4) RP04(S4) [...] > acpitimer0 at acpi0: 3579545 Hz, 24 bits > acpihpet0 at acpi0: 1920 Hz > acpimadt0 at acpi0 addr 0xfee0: PC-AT compat > cpu0 at mainbus0: apid 0 (boot processor) > cpu0: 12th Gen Intel(R) Core(TM) i3-1215U, 1197.29 MHz, 06-9a-04 > cpu0: > FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,SDBG,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,ABM,3DNOWP,PERF,ITSC,FSGSBASE,TSC_ADJUST,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,RDSEED,ADX,SMAP,CLFLUSHOPT,CLWB,PT,SHA,UMIP,PKU,WAITPKG,PKS,MD_CLEAR,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,XSAVEC,XGETBV1,XSAVES > cpu0: 48KB 64b/line 12-way D-cache, 32KB 64b/line 8-way I-cache, 1MB 64b/line > 10-way L2 cache, 10MB 64b/line 10-way L3 cache > cpu0: smt 0, core 0, package 0 > mtrr: Pentium Pro MTRR support, 10 var ranges, 88 fixed ranges > cpu0: apic clock running at 38MHz > cpu0: mwait min=64, max=64, C-substates=0.2.0.2.0.1.0.1, IBE > cpu1 at mainbus0: apid 1 (application processor) > cpu1: 12th Gen Intel(R) Core(TM) i3-1215U, 1197.28 MHz, 06-9a-04 > cpu1: > FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,SDBG,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,ABM,3DNOWP,PERF,ITSC,FSGSBASE,TSC_ADJUST,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,RDSEED,ADX,SMAP,CLFLUSHOPT,CLWB,PT,SHA,UMIP,PKU,PKS,MD_CLEAR,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,XSAVEC,XGETBV1,XSAVES > cpu1: 48KB 64b/line 12-way D-cache, 32KB 64b/line 8-way I-cache, 1MB 64b/line > 10-way L2 cache, 10MB 64b/line 10-way L3 cache > cpu1: smt 1, core 0, package 0 > cpu2 at mainbus0: apid 8 (application processor) > cpu2: 12th Gen Intel(R) Core(TM) i3-1215U, 1197.28 MHz, 06-9a-04 > cpu2: > FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,SDBG,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,ABM,3DNOWP,PERF,ITSC,FSGSBASE,TSC_ADJUST,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,RDSEED,ADX,SMAP,CLFLUSHOPT,CLWB,PT,SHA,UMIP,PKU,PKS,MD_CLEAR,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,XSAVEC,XGETBV1,XSAVES > cpu2: 48KB 64b/line 12-way D-cache, 32KB 64b/line 8-way I-cache, 1MB 64b/line > 10-way L2 cache, 10MB 64b/line 10-way L3 cache > cpu2: smt 0, core 4, package 0 > cpu3 at mainbus0: apid 9 (application processor) > cpu3: 12th Gen Intel(R) Core(TM) i3-1215U, 1197.28 MHz, 06-9a-04 > cpu3: >
Re: File transfer using ftp from bsd.rd booted system
On Aug 27 22:56:59, ch...@mailfence.com wrote: > I would like be able to transfer files over ethernet from a system > that has been booted from bsd.rd Why do you need that? (The only case where I want to have files from a bsd.rd boot is a dmesg of a machine I am looking at, without installing. Which I save on the media I booted from.)
Re: My /usr cleaning campaign..
On Aug 13 04:37:25, my2...@has.im wrote: > - /usr/local/share/gtk-doc (=131MB), html doc completed of some vary > .png files.. I guess this could be not only an endemic problem of my > stick as gtk-doc is not installed here: I'm not in the need of GTK C > code documentation > - /usr/local/share/doc (=118MB) So you have /usr/local under the /usr filesystem. Make /usr/local separate. Chances are that's what's filling your /usr, which by itself is pretty small. > - what about /usr/local/share/gir-1.0 (70M) ? If you worry about 70MB dirs, you are wasting your time, and everyone else's. Just reinstall /usr/local on a separate 10GB partition and be done with it. It costs almost nothing. > I'd like almost to delete ./gtk-doc and move ./doc to eg. /home/ (with > sensibly more space) with a link to among the toppings.. ;D Stop wasting time.
Re: Recognition Of My Wireless Network Device
On Aug 09 07:36:00, stu.li...@spacehopper.org wrote: > On 2023-08-08, Jan Stary wrote: > > On Aug 07 15:32:05, mill...@openbsd.org wrote: > >> Your best bet may be to replace the onboard wireless with a card > >> that is supported by OpenBSD. > > > > On Aug 08 09:55:58, stu.li...@spacehopper.org wrote: > >> Swapping to a different card is likely to give better results (generally > >> faster, more stable, and able to use the proper antennas in the laptop, > >> usually around the display, rather than a tiny pcb trace antenna) > > > > Exactly. Replace the BCM with Intel or something. > > Takes about ten minutes and costs peanuts. > > Maybe. But these were popular on some HP stuff where changing it often > requires some dodgy hacked BIOS download which may or may not be safe > to use. That's why I added the other bit. Ah, right: some Thinkpads for example have a whitelist of allowed wifi chips they will let you booth with ...
Re: Recognition Of My Wireless Network Device
On Aug 07 15:32:05, mill...@openbsd.org wrote: > Your best bet may be to replace the onboard wireless with a card > that is supported by OpenBSD. On Aug 08 09:55:58, stu.li...@spacehopper.org wrote: > Swapping to a different card is likely to give better results (generally > faster, more stable, and able to use the proper antennas in the laptop, > usually around the display, rather than a tiny pcb trace antenna) Exactly. Replace the BCM with Intel or something. Takes about ten minutes and costs peanuts.
Re: daily insecurity output (emails) end with: mtree special: exit code 2
> > Checking special files and directories. > > Output format is: > > filename: > > criteria (shouldbe, reallyis) > > etc/pf.conf: > > permissions (0600, 0640) > > This seems to be since I updated to a snapshot: I don't believe an upgrade switched on the read bit on your /etc/pf.conf
Re: lidaction on an M1 macbook
On Jun 22 16:57:45, tobias.hei...@stusta.de wrote:
> > > > The arm64 default for the machdep.lidaction is 1, making the
> > > > system suspend when the lid is closed.
> >
> > On this M1 macbook (dmesg below), I see no difference
> > between lidaction=0 and lidaction=1; with both,
> > closing and opening the lid does this:
> >
> Is this still the case?
Yes.
> For me lidaction=0 seems to only disable the screen which is inteded,
> lidaction=1 triggers a suspend.
For me, both lidaction=0 and lidaction=1
turn the screen off, but do not suspend.
Only apm -z suspends.
closing the lid with machdep.lidaction=0
Jun 23 10:33:40 mb /bsd: uhub0 detached
Jun 23 10:33:40 mb /bsd: uhub1 detached
Jun 23 10:34:57 mb /bsd: wsdisplay_switch2: not switching
Jun 23 10:34:57 mb /bsd: cpu0: 1 wakeup events
Jun 23 10:34:57 mb /bsd: uhub0 at usb0 configuration 1 interface 0 "Generic
xHCI root hub" rev 3.00/1.00 addr 1
Jun 23 10:34:57 mb /bsd: uhub1 at usb1 configuration 1 interface 0 "Generic
xHCI root hub" rev 3.00/1.00 addr 1
Jun 23 10:34:57 mb /bsd: cpu7: 1 wakeup events
Jun 23 10:34:57 mb /bsd: cpu4: 1 wakeup events
Jun 23 10:34:57 mb /bsd: cpu6: 1 wakeup events
Jun 23 10:34:57 mb /bsd: cpu5: 1 wakeup events
Jun 23 10:34:57 mb /bsd: cpu1: 1 wakeup events
Jun 23 10:34:57 mb /bsd: cpu2: 1 wakeup events
Jun 23 10:34:57 mb /bsd: cpu3: 1 wakeup events
Jun 23 10:34:57 mb root: running /etc/apm/resume
Jun 23 10:35:03 mb apmd: system resumed from sleep
Jun 23 10:35:03 mb apmd: battery status: high. external power status:
connected. estimated battery life 100%
closing the lid with machdep.lidaction=1
Jun 23 10:35:56 mb /bsd: uhub0 detached
Jun 23 10:35:56 mb /bsd: uhub1 detached
Jun 23 10:36:47 mb /bsd: wsdisplay_switch2: not switching
Jun 23 10:36:47 mb /bsd: cpu0: 1 wakeup events
Jun 23 10:36:47 mb /bsd: uhub0 at usb0 configuration 1 interface 0 "Generic
xHCI root hub" rev 3.00/1.00 addr 1
Jun 23 10:36:47 mb /bsd: uhub1 at usb1 configuration 1 interface 0 "Generic
xHCI root hub" rev 3.00/1.00 addr 1
Jun 23 10:36:47 mb /bsd: cpu7: 1 wakeup events
Jun 23 10:36:47 mb /bsd: cpu5: 1 wakeup events
Jun 23 10:36:47 mb /bsd: cpu4: 1 wakeup events
Jun 23 10:36:47 mb /bsd: cpu6: 1 wakeup events
Jun 23 10:36:47 mb /bsd: cpu3: 1 wakeup events
Jun 23 10:36:47 mb /bsd: cpu1: 1 wakeup events
Jun 23 10:36:47 mb /bsd: cpu2: 1 wakeup events
Jun 23 10:36:47 mb root: running /etc/apm/resume
Jun 23 10:36:53 mb apmd: system resumed from sleep
Jun 23 10:36:53 mb apmd: battery status: high. external power status:
connected. estimated battery life 100%
running apm -z
Jun 23 10:37:16 mb apmd: system suspending
Jun 23 10:37:16 mb apmd: battery status: high. external power status:
connected. estimated battery life 100%
Jun 23 10:37:16 mb root: running /etc/apm/suspend
Jun 23 10:37:17 mb /bsd: uhub0 detached
Jun 23 10:37:17 mb /bsd: uhub1 detached
Jun 23 10:38:00 mb /bsd: wsdisplay_switch2: not switching
Jun 23 10:38:00 mb /bsd: cpu0: 1 wakeup events
Jun 23 10:38:00 mb /bsd: uhub0 at usb0 configuration 1 interface 0 "Generic
xHCI root hub" rev 3.00/1.00 addr 1
Jun 23 10:38:00 mb /bsd: uhub1 at usb1 configuration 1 interface 0 "Generic
xHCI root hub" rev 3.00/1.00 addr 1
Jun 23 10:38:00 mb /bsd: cpu7: 1 wakeup events
Jun 23 10:38:00 mb /bsd: cpu4: 1 wakeup events
Jun 23 10:38:00 mb /bsd: cpu5: 1 wakeup events
Jun 23 10:38:00 mb /bsd: cpu6: 1 wakeup events
Jun 23 10:38:00 mb /bsd: cpu1: 1 wakeup events
Jun 23 10:38:00 mb /bsd: cpu3: 1 wakeup events
Jun 23 10:38:00 mb /bsd: cpu2: 1 wakeup events
Jun 23 10:38:01 mb root: running /etc/apm/resume
Jun 23 10:38:06 mb apmd: system resumed from sleep
Jun 23 10:38:06 mb apmd: battery status: high. external power status:
connected. estimated battery life 100%
Jan
/etc/apm/{suspend,resume} are the same file:
#!/bin/sh
logger running $0
dmesg:
OpenBSD 7.3-current (GENERIC.MP) #2170: Thu Jun 22 14:47:18 MDT 2023
dera...@arm64.openbsd.org:/usr/src/sys/arch/arm64/compile/GENERIC.MP
real mem = 8001478656 (7630MB)
avail mem = 7634296832 (7280MB)
random: good seed from bootblocks
mainbus0 at root: Apple MacBook Air (M1, 2020)
cpu0 at mainbus0 mpidr 0: Apple Icestorm r1p1
cpu0: 128KB 64b/line 8-way L1 VIPT I-cache, 64KB 64b/line 8-way L1 D-cache
cpu0: 4096KB 128b/line 16-way L2 cache
cpu0:
TLBIOS+IRANGE,TS+AXFLAG,FHM,DP,SHA3,RDM,Atomic,CRC32,SHA2+SHA512,SHA1,AES+PMULL,SPECRES,SB,FRINTTS,GPI,LRCPC+LDAPUR,FCMA,JSCVT,API+PAC,DPB,SpecSEI,PAN+ATS1E1,LO,HPDS,VH,CSV3,CSV2,DIT,SBSS+MSR
cpu1 at mainbus0 mpidr 1: Apple Icestorm r1p1
cpu1: 128KB 64b/line 8-way L1 VIPT I-cache, 64KB 64b/line 8-way L1 D-cache
cpu1: 4096KB 128b/line 16-way L2 cache
cpu1:
TLBIOS+IRANGE,TS+AXFLAG,FHM,DP,SHA3,RDM,Atomic,CRC32,SHA2+SHA512,SHA1,AES+PMULL,SPECRES,SB,FRINTTS,GPI,LRCPC+LDAPUR,FCMA,JSCVT,API+PAC,DPB,SpecSEI,PAN+ATS1E1,LO,HPDS,VH,CSV3,CSV2,DIT,SBSS+MSR
cpu2 at mainbus0 mpidr 2: Apple Icestorm r1p1
cpu2: 128KB 64b/line 8-way L1 VIPT I-cache, 64KB 64b/line 8-way L1 D-cache
cpu2: 4096KB 128b/line 16-way L2 cache
Re: lidaction on an M1 macbook
ping On Apr 11 18:29:50, h...@stare.cz wrote: > > o On arm64, add a machdep.lidaction sysctl(8) > > for aplsmc(4) Apple Silicon laptops. > > Should that be mentioned in the arm64 examples/sysctl.conf > as on other such architectures? > > Index: etc/etc.arm64/sysctl.conf > === > RCS file: /cvs/src/etc/etc.arm64/sysctl.conf,v > retrieving revision 1.1 > diff -u -p -r1.1 sysctl.conf > --- etc.arm64/sysctl.conf 11 Jan 2017 22:57:34 - 1.1 > +++ etc.arm64/sysctl.conf 11 Apr 2023 15:40:50 - > @@ -0,0 +1 @@ > +#machdep.lidaction=0 # 1=suspend, 2=hibernate laptop upon lid closing > > > > aplsmc(4) provides support for the lid position sensor. > > Should that be mentioned in aplsmc(4)? > > Index: aplsmc.4 > === > RCS file: /cvs/src/share/man/man4/man4.arm64/aplsmc.4,v > retrieving revision 1.2 > diff -u -p -r1.2 aplsmc.4 > --- aplsmc.4 10 Jan 2022 21:16:44 - 1.2 > +++ aplsmc.4 11 Apr 2023 15:49:20 - > @@ -28,7 +28,7 @@ The > driver provides support for the System Management Controller (SMC) > found on various Apple SoCs. > The driver provides a collection of current, fan, power, temperature, > -voltage and battery information sensors. > +voltage, lid position and battery information sensors. > .Pp > Sensor values are made available through the > .Xr sysctl 8 > > > > > The arm64 default for the machdep.lidaction is 1, making the > > > system suspend when the lid is closed. > > On this M1 macbook (dmesg below), I see no difference > between lidaction=0 and lidaction=1; with both, > closing and opening the lid does this: > > (lidaction=0) > > Apr 11 16:54:22 mb /bsd: uhub0 detached > Apr 11 16:54:22 mb /bsd: uhub1 detached > > Apr 11 16:54:31 mb /bsd: wsdisplay_switch2: not switching > Apr 11 16:54:31 mb /bsd: cpu0: 1 wakeup events > Apr 11 16:54:31 mb /bsd: uhub0 at usb0 configuration 1 interface 0 "Generic > xHCI root hub" rev 3.00/1.00 addr 1 > Apr 11 16:54:31 mb /bsd: uhub1 at usb1 configuration 1 interface 0 "Generic > xHCI root hub" rev 3.00/1.00 addr 1 > Apr 11 16:54:31 mb /bsd: cpu7: 1 wakeup events > Apr 11 16:54:31 mb /bsd: cpu4: 1 wakeup events > Apr 11 16:54:31 mb /bsd: cpu6: 1 wakeup events > Apr 11 16:54:31 mb /bsd: cpu5: 1 wakeup events > Apr 11 16:54:31 mb /bsd: cpu1: 1 wakeup events > Apr 11 16:54:31 mb /bsd: cpu3: 1 wakeup events > Apr 11 16:54:31 mb /bsd: cp > Apr 11 16:54:31 mb /bsd: u2: 1 wakeup events > Apr 11 16:54:31 mb root: running /etc/apm/resume > Apr 11 16:54:36 mb apmd: system resumed from sleep > Apr 11 16:54:36 mb apmd: battery status: high. external power status: not > connected. estimated battery life 99% (834 minutes life time estimate) > > (lidaction=1) > > Apr 11 17:05:12 mb /bsd: uhub0 detached > Apr 11 17:05:12 mb /bsd: uhub1 detached > > Apr 11 17:05:20 mb /bsd: wsdisplay_switch2: not switching > Apr 11 17:05:20 mb /bsd: cpu0: 1 wakeup events > Apr 11 17:05:20 mb /bsd: uhub0 at usb0 configuration 1 interface 0 "Generic > xHCI root hub" rev 3.00/1.00 addr 1 > Apr 11 17:05:20 mb /bsd: uhub1 at usb1 configuration 1 interface 0 "Generic > xHCI root hub" rev 3.00/1.00 addr 1 > Apr 11 17:05:20 mb /bsd: cpu7: 1 wakeup events > Apr 11 17:05:20 mb /bsd: cpu5: 1 wakeup events > Apr 11 17:05:20 mb /bsd: cpu4: 1 wakeup events > Apr 11 17:05:20 mb /bsd: cpu6: 1 wakeup events > Apr 11 17:05:20 mb /bsd: cpu2: 1 wakeup events > Apr 11 17:05:20 mb /bsd: cpu3: 1 wakeup events > Apr 11 17:05:20 mb /bsd: cpu1: 1 wakeup events > Apr 11 17:05:20 mb root: running /etc/apm/resume > Apr 11 17:05:26 mb apmd: system resumed from sleep > Apr 11 17:05:26 mb apmd: battery status: high. external power status: not > connected. estimated battery life 98% (796 minutes life time estimate) > > So even with lidaction=0 it kind-of-suspends, > and kind-of-resumes, running /etc/apm/resume. > Is that expected? > > There also seems to be a difference between suspending with apm -z > and suspending by closing the lid; namely, apm -z does call > /etc/apm/suspend but the lid does not. Is that intended? > > (apm -z) > > Apr 11 16:55:30 mb apmd: system suspending >^^^ > Apr 11 16:55:30 mb apmd: battery status: high. external power status: not > connected. estimated battery life 99% (712 minutes life time estimate) > Apr 11 16:55:30 mb root: running /etc/apm/suspend > > Apr 11 16:55:31 mb /bsd: uhub0 detached > Apr 11 16:55:31 mb /bsd: uhub1 detached > > Apr 11 16:55:37 mb /bsd: wsdisplay_switch2: not switching > Apr 11 16:55:37 mb /bsd: cpu0: 1 wakeup events > Apr 11 16:55:37 mb /bsd: uhub0 at usb0 configuration 1 interface 0 "Generic > xHCI root hub" rev 3.00/1.00 addr 1 > Apr 11 16:55:37 mb /bsd: uhub1 at usb1 configuration 1 interface 0 "Generic > xHCI root hub" rev 3.00/1.00 addr 1 > Apr 11 16:55:37 mb /bsd: cpu7: 1 wakeup
Re: Failure to install on MacBook Pro Retina early 2015
On May 22 23:24:04, dave_t_tur...@barradas.free-online.co.uk wrote: > The MacBookPro uses UEFI and will only boot from a USB stick for the > install. > After using the Apple magic 'alt' key to boot from the USB stick I get > this:- > probing pc0 mem [list of numbers] > disk: hdo* hd1* > > > OpenBSD /amd64 BOOTX64 3.62 > open (hd0a: /etc/boot.conf: Invalid argument > failed (22) will try /bsd I see a similar problem on an old macppc (dmesg below). In my case, the error message is boot.conf: line too long while there is no boot.conf > Using 'set' and 'help' doesn't yield any useful info > to find the boot.conf file. That should be /etc/boot.conf. I guess there is one on the install media - what dfoes it say? > ls gives hd0a Invalid Argument > ls hd0a gives hd0a:hd0a Invalid Argument I am able to boot with > boot hd:/bsd but I only have one disk in. Try that or > boot hd0a:/bsd > set shows the device as hd0. > hd0a is definitely the USB stick. To be sure: you are trying to boot the USB stick to install, right? As opposed to trying to boot the already installed system. > Is this install doomed to fail or am I missing some secret info that > rummaging through the boot(8) > boot_config(8) and boot_configamd64(8) man pages has failed to find? Also, are you sure it's an amd64 machine? (Not related to the boot problem I guess.) Jan [ using 1330724 bytes of bsd ELF symbol table ] console out [ATY,RockHopper2_A] console in [keyboard], using USB using parent ATY,RockHopper2Paren:: memaddr 9800, size 800 : consaddr 9c008000 : ioaddr 9002, size 2: width 1920 linebytes 2048 height 1080 depth 8 Copyright (c) 1982, 1986, 1989, 1991, 1993 The Regents of the University of California. All rights reserved. Copyright (c) 1995-2023 OpenBSD. All rights reserved. https://www.OpenBSD.org OpenBSD 7.3-current (GENERIC) #105: Sat Apr 15 17:07:53 MDT 2023 dera...@macppc.openbsd.org:/usr/src/sys/arch/macppc/compile/GENERIC real mem = 1073741824 (1024MB) avail mem = 1025327104 (977MB) random: good seed from bootblocks mpath0 at root scsibus0 at mpath0: 256 targets mainbus0 at root: model PowerMac10,2 cpu0 at mainbus0: 7447A (Revision 0x102): 1499 MHz: 512KB L2 cache mem0 at mainbus0 spdmem0 at mem0: 1GB DDR SDRAM non-parity PC3200CL3.0 memc0 at mainbus0: uni-n rev 0xd2 "hw-clock" at memc0 not configured kiic0 at memc0 offset 0xf8001000 iic0 at kiic0 mpcpcibr0 at mainbus0 pci: uni-north pci0 at mpcpcibr0 bus 0 pchb0 at pci0 dev 11 function 0 "Apple UniNorth AGP" rev 0x00 agp at pchb0 not configured radeondrm0 at pci0 dev 16 function 0 "ATI Radeon 9200" rev 0x01 drm0 at radeondrm0 radeondrm0: irq 48 mpcpcibr1 at mainbus0 pci: uni-north pci1 at mpcpcibr1 bus 0 macobio0 at pci1 dev 23 function 0 "Apple Intrepid" rev 0x00 openpic0 at macobio0 offset 0x4: version 0x4614 feature 3f0302 LE macgpio0 at macobio0 offset 0x50 "modem-reset" at macgpio0 offset 0x1d not configured "modem-power" at macgpio0 offset 0x1c not configured macgpio1 at macgpio0 offset 0x9: irq 47 "programmer-switch" at macgpio0 offset 0x11 not configured "gpio5" at macgpio0 offset 0x6f not configured "gpio6" at macgpio0 offset 0x70 not configured "extint-gpio15" at macgpio0 offset 0x67 not configured "escc-legacy" at macobio0 offset 0x12000 not configured zs0 at macobio0 offset 0x13000: irq 22,23 zstty0 at zs0 channel 0 zstty1 at zs0 channel 1 aoa0 at macobio0 offset 0x1: irq 30,1,2 "timer" at macobio0 offset 0x15000 not configured adb0 at macobio0 offset 0x16000 apm0 at adb0: battery flags 0x0, 0% charged piic0 at adb0 iic1 at piic0 maxtmp0 at iic1 addr 0xc8: max6642 kiic1 at macobio0 offset 0x18000 iic2 at kiic1 wdc0 at macobio0 offset 0x2 irq 24: DMA audio0 at aoa0 ohci0 at pci1 dev 26 function 0 "Apple Intrepid USB" rev 0x00: irq 29, version 1.0, legacy support ohci1 at pci1 dev 27 function 0 "NEC USB" rev 0x43: irq 63, version 1.0 ohci2 at pci1 dev 27 function 1 "NEC USB" rev 0x43: irq 63, version 1.0 ehci0 at pci1 dev 27 function 2 "NEC USB" rev 0x04: irq 63 usb0 at ehci0: USB revision 2.0 uhub0 at usb0 configuration 1 interface 0 "NEC EHCI root hub" rev 2.00/1.00 addr 1 usb1 at ohci0: USB revision 1.0 uhub1 at usb1 configuration 1 interface 0 "Apple OHCI root hub" rev 1.00/1.00 addr 1 usb2 at ohci1: USB revision 1.0 uhub2 at usb2 configuration 1 interface 0 "NEC OHCI root hub" rev 1.00/1.00 addr 1 usb3 at ohci2: USB revision 1.0 uhub3 at usb3 configuration 1 interface 0 "NEC OHCI root hub" rev 1.00/1.00 addr 1 mpcpcibr2 at mainbus0 pci: uni-north pci2 at mpcpcibr2 bus 0 kauaiata0 at pci2 dev 13 function 0 "Apple Intrepid ATA" rev 0x00 wdc1 at kauaiata0 irq 39: DMA wd0 at wdc1 channel 0 drive 0: wd0: 16-sector PIO, LBA48, 152627MB, 312581808 sectors wd0(wdc1:0:0): using PIO mode 4, DMA mode 2, Ultra-DMA mode 5 "Apple UniNorth Firewire" rev 0x81 at pci2 dev 14 function 0 not configured gem0 at pci2 dev 15 function 0 "Apple Uni-N2 GMAC" rev 0x80: irq 41, address
unclean / on every boot (SD card in APU1C)
This is current/amd64 on an APU1C (dmesg below). It runs off a microSD card (sd1 in a SD card adapter in the SD slot) and has a 60GB mSATA (sd0 in the mSATA slot ) for backups of others. Filesystem SizeUsed Avail Capacity Mounted on /dev/sd1a 501M106M370M23%/ /dev/sd1d 989M6.0K940M 1%/tmp /dev/sd1e 249M6.7M229M 3%/var /dev/sd1f 989M950K939M 1%/var/log /dev/sd1g 1.5G1.4M1.4G 1%/var/www /dev/sd1h 1.9G651M1.2G35%/usr /dev/sd1i 4.8G193M4.4G 5%/usr/local /dev/sd1l 4.8G 54.3M4.5G 2%/home /dev/sd0a 55.8G129M 52.9G 1%/backup The problem is the root filesystem is always unclean after a reboot. That is, after a warm reboot with 'shutdown -r' or 'reboot': WARNING: / was not properly unmounted Automatic boot in progress: starting file system checks. /dev/sd1a (47e56166cfb1e429.a): 1758 files, 54169 used, 202494 free (38 frags, 25307 blocks, 0.0% fragmentation) /dev/sd1a (47e56166cfb1e429.a): MARKING FILE SYSTEM CLEAN This never happens with a cold reboot (shutdown -h or halt). It also never happens with the mSATA disk. The shutdown (cold or warm) does report 'syncing disks ... done' and doesn't report any problems. How can I debug this? Is it something specific about microSD cards? In every case, the filesystem just got fsck'ed on boot and runs fine; but it seems unreliable booting an unclean / Jan OpenBSD 7.3-current (GENERIC.MP) #0: Sat Apr 29 23:58:22 CEST 2023 h...@stary.stare.cz:/usr/src/sys/arch/amd64/compile/GENERIC.MP real mem = 2098511872 (2001MB) avail mem = 2015338496 (1921MB) random: good seed from bootblocks mpath0 at root scsibus0 at mpath0: 256 targets mainbus0 at root bios0 at mainbus0: SMBIOS rev. 2.7 @ 0x7e16d820 (7 entries) bios0: vendor coreboot version "4.0" date 09/08/2014 bios0: PC Engines APU acpi0 at bios0: ACPI 4.0 acpi0: sleep states S0 S1 S3 S4 S5 acpi0: tables DSDT FACP SPCR HPET APIC HEST SSDT SSDT SSDT acpi0: wakeup devices AGPB(S4) HDMI(S4) PBR4(S4) PBR5(S4) PBR6(S4) PBR7(S4) PE20(S4) PE21(S4) PE22(S4) PE23(S4) PIBR(S4) UOH1(S3) UOH2(S3) UOH3(S3) UOH4(S3) UOH5(S3) [...] acpitimer0 at acpi0: 3579545 Hz, 32 bits acpihpet0 at acpi0: 14318180 Hz acpimadt0 at acpi0 addr 0xfee0: PC-AT compat cpu0 at mainbus0: apid 0 (boot processor) cpu0: AMD G-T40E Processor, 1000.01 MHz, 14-02-00 cpu0: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,HTT,SSE3,MWAIT,SSSE3,CX16,POPCNT,NXE,MMXX,FFXSR,PAGE1GB,RDTSCP,LONG,LAHF,CMPLEG,SVM,EAPICSP,AMCR8,ABM,SSE4A,MASSE,3DNOWP,IBS,SKINIT,ITSC cpu0: 32KB 64b/line 8-way D-cache, 32KB 64b/line 2-way I-cache cpu0: 512KB 64b/line 16-way L2 cache cpu0: smt 0, core 0, package 0 mtrr: Pentium Pro MTRR support, 8 var ranges, 88 fixed ranges cpu0: apic clock running at 200MHz cpu0: mwait min=64, max=64, IBE cpu1 at mainbus0: apid 1 (application processor) cpu1: AMD G-T40E Processor, 1000.02 MHz, 14-02-00 cpu1: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,HTT,SSE3,MWAIT,SSSE3,CX16,POPCNT,NXE,MMXX,FFXSR,PAGE1GB,RDTSCP,LONG,LAHF,CMPLEG,SVM,EAPICSP,AMCR8,ABM,SSE4A,MASSE,3DNOWP,IBS,SKINIT,ITSC cpu1: 32KB 64b/line 8-way D-cache, 32KB 64b/line 2-way I-cache cpu1: 512KB 64b/line 16-way L2 cache cpu1: smt 0, core 1, package 0 ioapic0 at mainbus0: apid 2 pa 0xfec0, version 21, 24 pins acpiprt0 at acpi0: bus 0 (PCI0) acpiprt1 at acpi0: bus -1 (AGPB) acpiprt2 at acpi0: bus -1 (HDMI) acpiprt3 at acpi0: bus 1 (PBR4) acpiprt4 at acpi0: bus 2 (PBR5) acpiprt5 at acpi0: bus 3 (PBR6) acpiprt6 at acpi0: bus -1 (PBR7) acpiprt7 at acpi0: bus 5 (PE20) acpiprt8 at acpi0: bus -1 (PE21) acpiprt9 at acpi0: bus -1 (PE22) acpiprt10 at acpi0: bus -1 (PE23) acpiprt11 at acpi0: bus 4 (PIBR) acpipci0 at acpi0 PCI0: 0x 0x0011 0x0001 acpicmos0 at acpi0 acpibtn0 at acpi0: PWRB acpicpu0 at acpi0: C2(0@100 io@0x841), C1(@1 halt!), PSS acpicpu1 at acpi0: C2(0@100 io@0x841), C1(@1 halt!), PSS cpu0: 1000 MHz: speeds: 1000 800 MHz pci0 at mainbus0 bus 0 pchb0 at pci0 dev 0 function 0 "AMD 14h Host" rev 0x00 ppb0 at pci0 dev 4 function 0 "AMD 14h PCIE" rev 0x00: msi pci1 at ppb0 bus 1 re0 at pci1 dev 0 function 0 "Realtek 8168" rev 0x06: RTL8168E/8111E (0x2c00), msi, address 00:0d:b9:3d:bb:fc rgephy0 at re0 phy 7: RTL8169S/8110S/8211 PHY, rev. 4 ppb1 at pci0 dev 5 function 0 "AMD 14h PCIE" rev 0x00: msi pci2 at ppb1 bus 2 re1 at pci2 dev 0 function 0 "Realtek 8168" rev 0x06: RTL8168E/8111E (0x2c00), msi, address 00:0d:b9:3d:bb:fd rgephy1 at re1 phy 7: RTL8169S/8110S/8211 PHY, rev. 4 ppb2 at pci0 dev 6 function 0 "AMD 14h PCIE" rev 0x00: msi pci3 at ppb2 bus 3 re2 at pci3 dev 0 function 0 "Realtek 8168" rev 0x06: RTL8168E/8111E (0x2c00), msi, address 00:0d:b9:3d:bb:fe rgephy2 at re2 phy 7: RTL8169S/8110S/8211 PHY, rev. 4 ahci0 at pci0 dev 17 function 0 "ATI SBx00 SATA" rev
Re: apm doesn't know AC state on APU1C
On Apr 26 11:38:40, dera...@openbsd.org wrote: > Jan Stary wrote: > > > On Apr 26 14:57:22, stu.li...@spacehopper.org wrote: > > > On 2023-04-26, Jan Stary wrote: > > > > This is current/amd64 on an APU1C (dmesg below). > > > > While 'sysctl hw' knows hw.power=1, apm doesn't know: > > > > > > > > Battery state: absent, 0% remaining, unknown life estimate > > > > AC adapter state: not known > > > > Performance adjustment mode: auto (1000 MHz) > > > > > > > > Yes, apmd -A is running. > > > > > > > > Not that this matters much, the machine will always be on AC; > > > > but it still seems strange for apm to not know. > > > > > > I don't expect the machine has bothered with a way to pass that > > > information through to the OS. > > > > Does sysctl hw.power know through a different way than apm? > > Does your APU1C have acpi? Yes (dmesg below). Is that how sysctl hw gets it, as opposed to apm? Jan OpenBSD 7.3-current (GENERIC.MP) #0: Wed Apr 26 12:48:53 CEST 2023 h...@stary.stare.cz:/usr/src/sys/arch/amd64/compile/GENERIC.MP real mem = 2098511872 (2001MB) avail mem = 2015346688 (1921MB) random: good seed from bootblocks mpath0 at root scsibus0 at mpath0: 256 targets mainbus0 at root bios0 at mainbus0: SMBIOS rev. 2.7 @ 0x7e16d820 (7 entries) bios0: vendor coreboot version "4.0" date 09/08/2014 bios0: PC Engines APU acpi0 at bios0: ACPI 4.0 acpi0: sleep states S0 S1 S3 S4 S5 acpi0: tables DSDT FACP SPCR HPET APIC HEST SSDT SSDT SSDT acpi0: wakeup devices AGPB(S4) HDMI(S4) PBR4(S4) PBR5(S4) PBR6(S4) PBR7(S4) PE20(S4) PE21(S4) PE22(S4) PE23(S4) PIBR(S4) UOH1(S3) UOH2(S3) UOH3(S3) UOH4(S3) UOH5(S3) [...] acpitimer0 at acpi0: 3579545 Hz, 32 bits acpihpet0 at acpi0: 14318180 Hz acpimadt0 at acpi0 addr 0xfee0: PC-AT compat cpu0 at mainbus0: apid 0 (boot processor) cpu0: AMD G-T40E Processor, 1000.02 MHz, 14-02-00 cpu0: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,HTT,SSE3,MWAIT,SSSE3,CX16,POPCNT,NXE,MMXX,FFXSR,PAGE1GB,RDTSCP,LONG,LAHF,CMPLEG,SVM,EAPICSP,AMCR8,ABM,SSE4A,MASSE,3DNOWP,IBS,SKINIT,ITSC cpu0: 32KB 64b/line 8-way D-cache, 32KB 64b/line 2-way I-cache cpu0: 512KB 64b/line 16-way L2 cache cpu0: smt 0, core 0, package 0 mtrr: Pentium Pro MTRR support, 8 var ranges, 88 fixed ranges cpu0: apic clock running at 200MHz cpu0: mwait min=64, max=64, IBE cpu1 at mainbus0: apid 1 (application processor) cpu1: AMD G-T40E Processor, 1000.02 MHz, 14-02-00 cpu1: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,HTT,SSE3,MWAIT,SSSE3,CX16,POPCNT,NXE,MMXX,FFXSR,PAGE1GB,RDTSCP,LONG,LAHF,CMPLEG,SVM,EAPICSP,AMCR8,ABM,SSE4A,MASSE,3DNOWP,IBS,SKINIT,ITSC cpu1: 32KB 64b/line 8-way D-cache, 32KB 64b/line 2-way I-cache cpu1: 512KB 64b/line 16-way L2 cache cpu1: smt 0, core 1, package 0 ioapic0 at mainbus0: apid 2 pa 0xfec0, version 21, 24 pins acpiprt0 at acpi0: bus 0 (PCI0) acpiprt1 at acpi0: bus -1 (AGPB) acpiprt2 at acpi0: bus -1 (HDMI) acpiprt3 at acpi0: bus 1 (PBR4) acpiprt4 at acpi0: bus 2 (PBR5) acpiprt5 at acpi0: bus 3 (PBR6) acpiprt6 at acpi0: bus -1 (PBR7) acpiprt7 at acpi0: bus 5 (PE20) acpiprt8 at acpi0: bus -1 (PE21) acpiprt9 at acpi0: bus -1 (PE22) acpiprt10 at acpi0: bus -1 (PE23) acpiprt11 at acpi0: bus 4 (PIBR) acpipci0 at acpi0 PCI0: 0x 0x0011 0x0001 acpicmos0 at acpi0 acpibtn0 at acpi0: PWRB acpicpu0 at acpi0: C2(0@100 io@0x841), C1(@1 halt!), PSS acpicpu1 at acpi0: C2(0@100 io@0x841), C1(@1 halt!), PSS cpu0: 1000 MHz: speeds: 1000 800 MHz pci0 at mainbus0 bus 0 pchb0 at pci0 dev 0 function 0 "AMD 14h Host" rev 0x00 ppb0 at pci0 dev 4 function 0 "AMD 14h PCIE" rev 0x00: msi pci1 at ppb0 bus 1 re0 at pci1 dev 0 function 0 "Realtek 8168" rev 0x06: RTL8168E/8111E (0x2c00), msi, address 00:0d:b9:3d:bb:fc rgephy0 at re0 phy 7: RTL8169S/8110S/8211 PHY, rev. 4 ppb1 at pci0 dev 5 function 0 "AMD 14h PCIE" rev 0x00: msi pci2 at ppb1 bus 2 re1 at pci2 dev 0 function 0 "Realtek 8168" rev 0x06: RTL8168E/8111E (0x2c00), msi, address 00:0d:b9:3d:bb:fd rgephy1 at re1 phy 7: RTL8169S/8110S/8211 PHY, rev. 4 ppb2 at pci0 dev 6 function 0 "AMD 14h PCIE" rev 0x00: msi pci3 at ppb2 bus 3 re2 at pci3 dev 0 function 0 "Realtek 8168" rev 0x06: RTL8168E/8111E (0x2c00), msi, address 00:0d:b9:3d:bb:fe rgephy2 at re2 phy 7: RTL8169S/8110S/8211 PHY, rev. 4 ahci0 at pci0 dev 17 function 0 "ATI SBx00 SATA" rev 0x40: apic 2 int 19, AHCI 1.2 scsibus1 at ahci0: 32 targets ohci0 at pci0 dev 18 function 0 "ATI SB700 USB" rev 0x00: apic 2 int 18, version 1.0, legacy support ehci0 at pci0 dev 18 function 2 "ATI SB700 USB2" rev 0x00: apic 2 int 17 usb0 at ehci0: USB revision 2.0 uhub0 at usb0 configur
Re: apm doesn't know AC state on APU1C
On Apr 26 14:57:22, stu.li...@spacehopper.org wrote: > On 2023-04-26, Jan Stary wrote: > > This is current/amd64 on an APU1C (dmesg below). > > While 'sysctl hw' knows hw.power=1, apm doesn't know: > > > > Battery state: absent, 0% remaining, unknown life estimate > > AC adapter state: not known > > Performance adjustment mode: auto (1000 MHz) > > > > Yes, apmd -A is running. > > > > Not that this matters much, the machine will always be on AC; > > but it still seems strange for apm to not know. > > I don't expect the machine has bothered with a way to pass that > information through to the OS. Does sysctl hw.power know through a different way than apm?
apm doesn't know AC state on APU1C
This is current/amd64 on an APU1C (dmesg below). While 'sysctl hw' knows hw.power=1, apm doesn't know: Battery state: absent, 0% remaining, unknown life estimate AC adapter state: not known Performance adjustment mode: auto (1000 MHz) Yes, apmd -A is running. Not that this matters much, the machine will always be on AC; but it still seems strange for apm to not know. Jan $ sysctl hw hw.machine=amd64 hw.model=AMD G-T40E Processor hw.ncpu=2 hw.byteorder=1234 hw.pagesize=4096 hw.disknames=sd0:6f8cb251ba678394,sd1:47e56166cfb1e429 hw.diskcount=2 hw.sensors.cpu0.frequency0=9.00 Hz hw.sensors.cpu1.frequency0=85000.00 Hz hw.sensors.km0.temp0=50.88 degC hw.cpuspeed=1000 hw.setperf=100 hw.vendor=PC Engines hw.product=APU hw.version=1.0 hw.serialno=1011391 hw.physmem=2098511872 hw.usermem=2098495488 hw.ncpufound=2 hw.allowpowerdown=1 hw.perfpolicy=auto hw.smt=0 hw.ncpuonline=2 hw.power=1 OpenBSD 7.3-current (GENERIC.MP) #0: Wed Apr 26 12:48:53 CEST 2023 h...@stary.stare.cz:/usr/src/sys/arch/amd64/compile/GENERIC.MP real mem = 2098511872 (2001MB) avail mem = 2015346688 (1921MB) random: good seed from bootblocks mpath0 at root scsibus0 at mpath0: 256 targets mainbus0 at root bios0 at mainbus0: SMBIOS rev. 2.7 @ 0x7e16d820 (7 entries) bios0: vendor coreboot version "4.0" date 09/08/2014 bios0: PC Engines APU acpi0 at bios0: ACPI 4.0 acpi0: sleep states S0 S1 S3 S4 S5 acpi0: tables DSDT FACP SPCR HPET APIC HEST SSDT SSDT SSDT acpi0: wakeup devices AGPB(S4) HDMI(S4) PBR4(S4) PBR5(S4) PBR6(S4) PBR7(S4) PE20(S4) PE21(S4) PE22(S4) PE23(S4) PIBR(S4) UOH1(S3) UOH2(S3) UOH3(S3) UOH4(S3) UOH5(S3) [...] acpitimer0 at acpi0: 3579545 Hz, 32 bits acpihpet0 at acpi0: 14318180 Hz acpimadt0 at acpi0 addr 0xfee0: PC-AT compat cpu0 at mainbus0: apid 0 (boot processor) cpu0: AMD G-T40E Processor, 1000.02 MHz, 14-02-00 cpu0: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,HTT,SSE3,MWAIT,SSSE3,CX16,POPCNT,NXE,MMXX,FFXSR,PAGE1GB,RDTSCP,LONG,LAHF,CMPLEG,SVM,EAPICSP,AMCR8,ABM,SSE4A,MASSE,3DNOWP,IBS,SKINIT,ITSC cpu0: 32KB 64b/line 8-way D-cache, 32KB 64b/line 2-way I-cache cpu0: 512KB 64b/line 16-way L2 cache cpu0: smt 0, core 0, package 0 mtrr: Pentium Pro MTRR support, 8 var ranges, 88 fixed ranges cpu0: apic clock running at 200MHz cpu0: mwait min=64, max=64, IBE cpu1 at mainbus0: apid 1 (application processor) cpu1: AMD G-T40E Processor, 1000.02 MHz, 14-02-00 cpu1: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,HTT,SSE3,MWAIT,SSSE3,CX16,POPCNT,NXE,MMXX,FFXSR,PAGE1GB,RDTSCP,LONG,LAHF,CMPLEG,SVM,EAPICSP,AMCR8,ABM,SSE4A,MASSE,3DNOWP,IBS,SKINIT,ITSC cpu1: 32KB 64b/line 8-way D-cache, 32KB 64b/line 2-way I-cache cpu1: 512KB 64b/line 16-way L2 cache cpu1: smt 0, core 1, package 0 ioapic0 at mainbus0: apid 2 pa 0xfec0, version 21, 24 pins acpiprt0 at acpi0: bus 0 (PCI0) acpiprt1 at acpi0: bus -1 (AGPB) acpiprt2 at acpi0: bus -1 (HDMI) acpiprt3 at acpi0: bus 1 (PBR4) acpiprt4 at acpi0: bus 2 (PBR5) acpiprt5 at acpi0: bus 3 (PBR6) acpiprt6 at acpi0: bus -1 (PBR7) acpiprt7 at acpi0: bus 5 (PE20) acpiprt8 at acpi0: bus -1 (PE21) acpiprt9 at acpi0: bus -1 (PE22) acpiprt10 at acpi0: bus -1 (PE23) acpiprt11 at acpi0: bus 4 (PIBR) acpipci0 at acpi0 PCI0: 0x 0x0011 0x0001 acpicmos0 at acpi0 acpibtn0 at acpi0: PWRB acpicpu0 at acpi0: C2(0@100 io@0x841), C1(@1 halt!), PSS acpicpu1 at acpi0: C2(0@100 io@0x841), C1(@1 halt!), PSS cpu0: 1000 MHz: speeds: 1000 800 MHz pci0 at mainbus0 bus 0 pchb0 at pci0 dev 0 function 0 "AMD 14h Host" rev 0x00 ppb0 at pci0 dev 4 function 0 "AMD 14h PCIE" rev 0x00: msi pci1 at ppb0 bus 1 re0 at pci1 dev 0 function 0 "Realtek 8168" rev 0x06: RTL8168E/8111E (0x2c00), msi, address 00:0d:b9:3d:bb:fc rgephy0 at re0 phy 7: RTL8169S/8110S/8211 PHY, rev. 4 ppb1 at pci0 dev 5 function 0 "AMD 14h PCIE" rev 0x00: msi pci2 at ppb1 bus 2 re1 at pci2 dev 0 function 0 "Realtek 8168" rev 0x06: RTL8168E/8111E (0x2c00), msi, address 00:0d:b9:3d:bb:fd rgephy1 at re1 phy 7: RTL8169S/8110S/8211 PHY, rev. 4 ppb2 at pci0 dev 6 function 0 "AMD 14h PCIE" rev 0x00: msi pci3 at ppb2 bus 3 re2 at pci3 dev 0 function 0 "Realtek 8168" rev 0x06: RTL8168E/8111E (0x2c00), msi, address 00:0d:b9:3d:bb:fe rgephy2 at re2 phy 7: RTL8169S/8110S/8211 PHY, rev. 4 ahci0 at pci0 dev 17 function 0 "ATI SBx00 SATA" rev 0x40: apic 2 int 19, AHCI 1.2 scsibus1 at ahci0: 32 targets ohci0 at pci0 dev 18 function 0 "ATI SB700 USB" rev 0x00: apic 2 int 18, version 1.0, legacy support ehci0 at pci0 dev 18 function 2 "ATI SB700 USB2" rev 0x00: apic 2 int 17 usb0 at ehci0: USB revision 2.0 uhub0 at usb0 configuration 1 interface 0 "ATI EHCI root hub" rev 2.00/1.00 addr 1 ohci1 at pci0 dev 19 function 0 "ATI SB700 USB" rev 0x00: apic 2 int 18, version 1.0, legacy support ehci1 at pci0 dev 19 function 2 "ATI SB700 USB2" rev 0x00: apic 2 int 17 usb1 at ehci1: USB revision 2.0 uhub1 at usb1 configuration 1 interface 0 "ATI
Re: hw RNG on APUs
On Apr 23 23:17:10, h...@stare.cz wrote: > On Apr 23 21:00:35, na...@mips.inka.de wrote: > > > That was in 2022. Lots of people will have machines without new BIOS. > > I have the latest firmware and the ccp(4) RNG returns nothing but 0. > > With your diff, my APU2d's and APU2e's report all zeroes > with each of bios v4.11.0.5, v4.17.0.1, v4.17.0.2, v4.19.0.1 > I'll try with the current diff. Yes, zeroes as well on both.
Re: hw RNG on APUs
On Apr 23 21:00:35, na...@mips.inka.de wrote:
> > That was in 2022. Lots of people will have machines without new BIOS.
> I have the latest firmware and the ccp(4) RNG returns nothing but 0.
With your diff, my APU2d's and APU2e's report all zeroes
with each of bios v4.11.0.5, v4.17.0.1, v4.17.0.2, v4.19.0.1
I'll try with the current diff.
Jan
> > I wonder if our kernel should have similar code to enable the registers.
>
> I tried that yesterday to no effect... but I'm not certain that
> what I'm trying to do below is equivalent to this coreboot change:
>
> + /* Enable access to PSP MMIO BARs. This is needed for CCP. */
> + dev = pcidev_on_root(8, 0);
> + if (dev != NULL)
> + pci_update_config8(dev, 0x48, 0xff, 0x3d);
>
> # pcidump 0:8:0
> 0:8:0: AMD 16h Crypto
>
> Index: dev/pci/ccp_pci.c
> ===
> RCS file: /cvs/src/sys/dev/pci/ccp_pci.c,v
> retrieving revision 1.7
> diff -u -p -r1.7 ccp_pci.c
> --- dev/pci/ccp_pci.c 24 Oct 2022 04:57:29 - 1.7
> +++ dev/pci/ccp_pci.c 22 Apr 2023 21:52:32 -
> @@ -31,7 +31,8 @@
>
> #include
>
> -#define CCP_PCI_BAR 0x18
> +#define CCP_PCI_BAR 0x18
> +#define CCP_PSP_BAR_ENABLES 0x48
>
> int ccp_pci_match(struct device *, void *, void *);
> void ccp_pci_attach(struct device *, struct device *, void *);
> @@ -62,7 +63,8 @@ ccp_pci_attach(struct device *parent, st
> {
> struct ccp_softc *sc = (struct ccp_softc *)self;
> struct pci_attach_args *pa = aux;
> - pcireg_t memtype;
> + pci_chipset_tag_t pc = pa->pa_pc;
> + pcireg_t memtype, reg;
>
> memtype = pci_mapreg_type(pa->pa_pc, pa->pa_tag, CCP_PCI_BAR);
> if (PCI_MAPREG_TYPE(memtype) != PCI_MAPREG_TYPE_MEM) {
> @@ -75,6 +77,10 @@ ccp_pci_attach(struct device *parent, st
> printf(": cannot map registers\n");
> return;
> }
> +
> + reg = pci_conf_read(pc, pa->pa_tag, CCP_PSP_BAR_ENABLES);
> + reg |= 0x3d;
> + pci_conf_write(pc, pa->pa_tag, CCP_PSP_BAR_ENABLES, reg);
>
> ccp_attach(sc);
> }
> --
> Christian "naddy" Weisgerber na...@mips.inka.de
>
Re: hw RNG on APUs
On Apr 21 17:27:37, dera...@openbsd.org wrote: > Christian Weisgerber wrote: > > > Christian Weisgerber: > > > > > I built a kernel with an instrumented driver. Unfortunately, no > > > entropy is provided: > > > > FWIW, it appears to work on the SoftIron OverDrive 1000: > > > > ccp: rng 058f9dad > > ccp: rng f0a495ba > > ccp: rng a757bdf7 > > ccp: rng 31b21d19 > > ccp: rng d1ce1c78 > > ccp: rng 863c9199 > > The driver does no initialization. Maybe there is a register that needs to > be initialized, and some firmwares initialize it, but others don't. for reference, coreboot claims to enable it on the apu: https://github.com/pcengines/coreboot/pull/505 https://github.com/pcengines/apu2-documentation/issues/112
Re: hardware
Once we leveraged the synergy of the red and purple solution frameworks. On Apr 18 07:47:56, deich...@placebonol.com wrote: > I was always partial to the blue or purple ones. > > On April 18, 2023 3:42:58 AM MDT, Joel Carnat wrote: > > > >> Le 18 avr. 2023 à 11:30, Stuart Henderson a > >> écrit : > >> > >> On 2023-04-18, Mischa wrote: > On 2023-04-17 23:37, Mike Larkin wrote: > On Mon, Apr 17, 2023 at 02:21:14PM -0600, Theo de Raadt wrote: > > Gustavo Rios wrote: > > > >> What is the best supported servers by OpenBSD ? > > > > The silver ones work a little bit better than the black ones. > > > > disagree. All my long running servers are the black ones. > >>> > >>> I concur. The black ones are the best! > >>> They also need to have blue blinkenlights. > >> > >> No love for the blue ones? > > > >If SunFire v100 count as blue, I do. > > > > >
hw RNG on APUs
Reading random(4), System activity (such as disk, network, and clock device interrupts), and hardware random generator output is collected, ... Does OpenBSD use any hardware RNG on the PC Engines APUs? https://github.com/pcengines/apu2-documentation/issues/112 discusses the firmware support for it. Jan
lidaction on an M1 macbook
> o On arm64, add a machdep.lidaction sysctl(8) > for aplsmc(4) Apple Silicon laptops. Should that be mentioned in the arm64 examples/sysctl.conf as on other such architectures? Index: etc/etc.arm64/sysctl.conf === RCS file: /cvs/src/etc/etc.arm64/sysctl.conf,v retrieving revision 1.1 diff -u -p -r1.1 sysctl.conf --- etc.arm64/sysctl.conf 11 Jan 2017 22:57:34 - 1.1 +++ etc.arm64/sysctl.conf 11 Apr 2023 15:40:50 - @@ -0,0 +1 @@ +#machdep.lidaction=0 # 1=suspend, 2=hibernate laptop upon lid closing > aplsmc(4) provides support for the lid position sensor. Should that be mentioned in aplsmc(4)? Index: aplsmc.4 === RCS file: /cvs/src/share/man/man4/man4.arm64/aplsmc.4,v retrieving revision 1.2 diff -u -p -r1.2 aplsmc.4 --- aplsmc.410 Jan 2022 21:16:44 - 1.2 +++ aplsmc.411 Apr 2023 15:49:20 - @@ -28,7 +28,7 @@ The driver provides support for the System Management Controller (SMC) found on various Apple SoCs. The driver provides a collection of current, fan, power, temperature, -voltage and battery information sensors. +voltage, lid position and battery information sensors. .Pp Sensor values are made available through the .Xr sysctl 8 > > The arm64 default for the machdep.lidaction is 1, making the > > system suspend when the lid is closed. On this M1 macbook (dmesg below), I see no difference between lidaction=0 and lidaction=1; with both, closing and opening the lid does this: (lidaction=0) Apr 11 16:54:22 mb /bsd: uhub0 detached Apr 11 16:54:22 mb /bsd: uhub1 detached Apr 11 16:54:31 mb /bsd: wsdisplay_switch2: not switching Apr 11 16:54:31 mb /bsd: cpu0: 1 wakeup events Apr 11 16:54:31 mb /bsd: uhub0 at usb0 configuration 1 interface 0 "Generic xHCI root hub" rev 3.00/1.00 addr 1 Apr 11 16:54:31 mb /bsd: uhub1 at usb1 configuration 1 interface 0 "Generic xHCI root hub" rev 3.00/1.00 addr 1 Apr 11 16:54:31 mb /bsd: cpu7: 1 wakeup events Apr 11 16:54:31 mb /bsd: cpu4: 1 wakeup events Apr 11 16:54:31 mb /bsd: cpu6: 1 wakeup events Apr 11 16:54:31 mb /bsd: cpu5: 1 wakeup events Apr 11 16:54:31 mb /bsd: cpu1: 1 wakeup events Apr 11 16:54:31 mb /bsd: cpu3: 1 wakeup events Apr 11 16:54:31 mb /bsd: cp Apr 11 16:54:31 mb /bsd: u2: 1 wakeup events Apr 11 16:54:31 mb root: running /etc/apm/resume Apr 11 16:54:36 mb apmd: system resumed from sleep Apr 11 16:54:36 mb apmd: battery status: high. external power status: not connected. estimated battery life 99% (834 minutes life time estimate) (lidaction=1) Apr 11 17:05:12 mb /bsd: uhub0 detached Apr 11 17:05:12 mb /bsd: uhub1 detached Apr 11 17:05:20 mb /bsd: wsdisplay_switch2: not switching Apr 11 17:05:20 mb /bsd: cpu0: 1 wakeup events Apr 11 17:05:20 mb /bsd: uhub0 at usb0 configuration 1 interface 0 "Generic xHCI root hub" rev 3.00/1.00 addr 1 Apr 11 17:05:20 mb /bsd: uhub1 at usb1 configuration 1 interface 0 "Generic xHCI root hub" rev 3.00/1.00 addr 1 Apr 11 17:05:20 mb /bsd: cpu7: 1 wakeup events Apr 11 17:05:20 mb /bsd: cpu5: 1 wakeup events Apr 11 17:05:20 mb /bsd: cpu4: 1 wakeup events Apr 11 17:05:20 mb /bsd: cpu6: 1 wakeup events Apr 11 17:05:20 mb /bsd: cpu2: 1 wakeup events Apr 11 17:05:20 mb /bsd: cpu3: 1 wakeup events Apr 11 17:05:20 mb /bsd: cpu1: 1 wakeup events Apr 11 17:05:20 mb root: running /etc/apm/resume Apr 11 17:05:26 mb apmd: system resumed from sleep Apr 11 17:05:26 mb apmd: battery status: high. external power status: not connected. estimated battery life 98% (796 minutes life time estimate) So even with lidaction=0 it kind-of-suspends, and kind-of-resumes, running /etc/apm/resume. Is that expected? There also seems to be a difference between suspending with apm -z and suspending by closing the lid; namely, apm -z does call /etc/apm/suspend but the lid does not. Is that intended? (apm -z) Apr 11 16:55:30 mb apmd: system suspending ^^^ Apr 11 16:55:30 mb apmd: battery status: high. external power status: not connected. estimated battery life 99% (712 minutes life time estimate) Apr 11 16:55:30 mb root: running /etc/apm/suspend Apr 11 16:55:31 mb /bsd: uhub0 detached Apr 11 16:55:31 mb /bsd: uhub1 detached Apr 11 16:55:37 mb /bsd: wsdisplay_switch2: not switching Apr 11 16:55:37 mb /bsd: cpu0: 1 wakeup events Apr 11 16:55:37 mb /bsd: uhub0 at usb0 configuration 1 interface 0 "Generic xHCI root hub" rev 3.00/1.00 addr 1 Apr 11 16:55:37 mb /bsd: uhub1 at usb1 configuration 1 interface 0 "Generic xHCI root hub" rev 3.00/1.00 addr 1 Apr 11 16:55:37 mb /bsd: cpu7: 1 wakeup events Apr 11 16:55:37 mb /bsd: cpu4: 1 wakeup events Apr 11 16:55:37 mb /bsd: cpu5: 1 wakeup events Apr 11 16:55:37 mb /bsd: cpu6: 1 wakeup events Apr 11 16:55:37 mb /bsd: cpu2: 1 wakeup events Apr 11 16:55:37 mb /bsd: cp Apr 11 16:55:37 mb /bsd: u3: 1 wakeup events Apr 11
Re: Command At Startup
On Apr 01 11:26:31, open...@cpnetserver.net wrote: > Hi Guys, OpenBSD 7.2 > I have no way to get a stupid autorun script to load. Can anyone tell me > where to put this script? > In /etc/rc.local it doesn't work... > The scirtp is located in the path /home/tech > and contains only this: > -- > #!/bin/ksh > /usr/sbin/apm -C > -- There is no apm -C
Re: Recovering from as identical as faulty backup disk..
On Mar 24 17:47:28, my2...@aol.com wrote: > a slight different console output: > https://5md.at/l/obcons1 Don't do this. Console output is text - put it into the email, don't make people go to a web page to read console output. > I expect there is problem on that disk. Obviously. > and there is a problem in OpenBSD caused by the same UID of the two disks. 1. Guess what the letters U I D stand for. 2. Don't use two disk with the same uid.
Re: Recovering from as identical as faulty backup disk..
On Mar 24 04:34:42, my2...@aol.com wrote: > sd1(umass0:1:0) Check Condition (error 0x70) on opcode 0x2a >SENSE KEY: Aborted Command > ASC/ASCQ: information Unit iuCRC Error Detected > > sd1 was the original disk which the second backup disk was copy from. > And obviously the faulty sd3 had the same UID of sd1. Why would another disk have the same UID and how is that obvious? Your problem is a HW failure, not a clash of names. > Apart my the physical problem of the identical bit-by-bit copy So how did you make that copy? Just dd sd1c onto sd3c? Why? > 2) The CRC problem of sd3 is passed to sd1 What do you mean by that? > I then rebooted on the backup disk and fix the fss prb to solve my > situation but frankly the system could be more helpful and less error > prone in these kind of emergency situations. You could also make normal backups.
Re: how to transmit desktop sound on xenodm.
On Mar 21 16:56:51, openbsd_s...@protonmail.com wrote: > How to convert "sndiod data stream" to "RTP(rtmp/rtsp) data stream". > mplayer and vlc can recive the "RTP(rtmp/rtsp) data stream". "sndio data stream" is linear PCM audio data. That can be played in any audio player out there. Why do you want to convert it to a RTP stream first? > If OpenBSD packages have "module-sndio", it will same too... > I know, OpenBSD ports and packages "omit the any functions". > I understood "If I can use the any useful factions. it is so lucky.". I cannot quite parse your sentences.
Re: azalia SPDIF with monitored line-in
On Mar 04 18:46:29, neb...@rawtext.club wrote:
> On Sat, Mar 04, 2023 at 06:21:08PM +0100, Jan Stary wrote:
> > > I have two devices around here. Let's call one devA and one devB.
> > > devB is my main OpenBSD workstation devA is some kind of gaming device
> > > which has a normal 2 channel audio jack. I want to connect the line out
> > > connector of devA to the line-in of devB and listen to both devices
> > > with my headphone amplifier connected to out/spdif of devB.
> >
> > Why do you want that? I mean, what are the two simultaneous things
> > you want to listen to, one comming from your game console and one
> > from your workstation?
> Mostly it's running an audio player, a voip application or video player
> on my workstation while playing on the other device.
That' what confuses me: you want to listen to the game play,
while simultaneously playing some other music?
> > > In analog mode this works beside the poor quality of the mainboard
> > > which seems to generate a lot of noise.
> >
> > That's not poor quality of the mainboard,
> > that's an electronic device suffering a _lot_
> > of interference from the electronics jungle around it.
> Isn't the board shielded inside it's case? (metal) Around the metal case
> there is also a small rack where the only other component running is a
> small switch? My guess would have been that the case and the rack should
> shield the internal components so the inteference must be coming from
> the board itself?
That's not the problem.
The on-board audio device gets interference
from all the other electronics _inside_ the case.
> If that's not the case, is there something I can do to
> improve the situation?
Use an USB audio card that doesn;t have to live inside the case.
> I've often read about audio components on
> mainboards being badly shielded from other components so assumed it
> maybe coming from those. Could a dedicated sound card maybe fix that,
> provided it got better shielding?
It will never be shielded enough;
inside the case, it will always get a lot of noise.
> > > When switching to SPDIF the noise is gone
> >
> > Yes: the digital signal does not suffer from the analog noise.
> Of course, bad worded from my side. I wanted to point out that
> nothing, not even noise from devA out is coming with that signal.
> >
> > Does you headphone amplifier take the spdif output of your workstation?
> > (What headphone amplifier is that?)
> The headphone amplifier is a beyerdynamic A20 which takes two analog RCA
> inputs.
So the headphine amplifier cannot take any spdif input,
having only analog inputs.
> I was a bit testing and had a 24bit/192khz DAC laying
> around and put it in between
Meaning, inbetween your workstation and the headphones amplifier.
So there is another device involved which you didn't even mention.
> with a very short RCA cable to get rid of
> that noise.
The cable is hardly the problem.
> Not ideal but worked as the digital signal of course not
> suffers from analog noise and the analog part is only 0.3m long now.
So the analiog output of your gaming console
gets converted to digital by your onboard audio chip,
mixed with what the workstation itself plays (you are
running sndiod I suppoes), and that mix is sent out as spdif
to another DAC, which converts it to analog
and sends it to your headphones amplifier.
(Except the game sound is lost somewhere along the way.)
That seems a bot convoluted to me.
> > > I switched to SPDIF with the following mixerctl(8) command
> > > `mixerctl -t outputs.mode=digital`
> > >
> > > I tried to set the "SPDIF_source" to something different but mixerctl
> > > states "Bad enum value ...". Is there any chance to mix the line-in
> > > with the default output like I did in analog mode? What am I missing
> > > here? In azalia(4) the outputs.mode and record.mode can both be set to
> > > analog or digital
> >
> > I see no record.mode in the mixerctl settings.
> >
> > > as far as I unterstand line-in should be record?
> >
> > Your mixerctl says it's an input.
> >
> > > mixerctl -a
> >
> > mixerctl -av might be more telling.
> Thanks, how could I overlook that...
> ---
> inputs.dac-0:1=126,126
> inputs.dac-4:5=126,126
> inputs.dac-2:3=126,126
> inputs.dac-6:7=126,126
> record.adc-0:1_mute=off [ off on ]
> record.adc-0:1=128,128
> record.adc-2:3_mute=off [ off on ]
> record.adc-2:3=128,128
> inputs.mix_source=mic,mic2,line-in,hp,line2,line3 { mic mic2 line-in hp
> line2 line3 }
> inputs.mix_mic=120,120
> inputs.mix_mic2=120,120
> inputs.mix_line-in=120,
Re: azalia SPDIF with monitored line-in
> I have two devices around here. Let's call one devA and one devB. > devB is my main OpenBSD workstation devA is some kind of gaming device > which has a normal 2 channel audio jack. I want to connect the line out > connector of devA to the line-in of devB and listen to both devices > with my headphone amplifier connected to out/spdif of devB. Why do you want that? I mean, what are the two simultaneous things you want to listen to, one comming from your game console and one from your workstation? > In analog mode this works beside the poor quality of the mainboard > which seems to generate a lot of noise. That's not poor quality of the mainboard, that's an electronic device suffering a _lot_ of interference from the electronics jungle around it. > When switching to SPDIF the noise is gone Yes: the digital signal does not suffer from the analog noise. Does you headphone amplifier take the spdif output of your workstation? (What headphone amplifier is that?) > but the line-in output is gone too. Meaning, you still hear the sounds that your workstation produces, but not the sound your gaming console sends to your line-in? > I switched to SPDIF with the following mixerctl(8) command > `mixerctl -t outputs.mode=digital` > > I tried to set the "SPDIF_source" to something different but mixerctl > states "Bad enum value ...". Is there any chance to mix the line-in > with the default output like I did in analog mode? What am I missing > here? In azalia(4) the outputs.mode and record.mode can both be set to > analog or digital I see no record.mode in the mixerctl settings. > as far as I unterstand line-in should be record? Your mixerctl says it's an input. > mixerctl -a mixerctl -av might be more telling. Jan > --- > inputs.dac-0:1=126,126 > inputs.dac-4:5=126,126 > inputs.dac-2:3=126,126 > inputs.dac-6:7=126,126 > record.adc-0:1_mute=off > record.adc-0:1=128,128 > record.adc-2:3_mute=off > record.adc-2:3=128,128 > inputs.mix_source=mic,mic2,line-in,hp,line2,line3 > inputs.mix_mic=120,120 > inputs.mix_mic2=120,120 > inputs.mix_line-in=120,120 > inputs.mix_hp=120,120 > inputs.mix_line2=120,120 > inputs.mix_line3=120,120 > inputs.mix2_source=dac-0:1,mix > inputs.mix3_source=dac-4:5,mix > inputs.mix4_source=dac-2:3,mix > inputs.mix5_source=dac-6:7,mix > outputs.line_source=mix2 > outputs.line_mute=off > outputs.line_boost=off > outputs.line_eapd=on > outputs.line2_source=mix3 > outputs.line2_mute=off > outputs.line2_dir=output > outputs.line3_source=mix4 > outputs.line3_mute=off > outputs.line3_dir=output > outputs.mic_source=mix8 > outputs.mic_mute=off > inputs.mic=85,85 > outputs.mic_dir=input-vr80 > outputs.mic2_source=mix2 > outputs.mic2_mute=off > inputs.mic2=85,85 > outputs.mic2_dir=input-vr80 > outputs.mic2_boost=off > outputs.line-in_source=mix2 > outputs.line-in_mute=off > inputs.line-in=85,85 > outputs.line-in_dir=input > outputs.hp_source=mix5 > outputs.hp_mute=off > inputs.hp=85,85 > outputs.hp_dir=output > outputs.hp_boost=off > outputs.hp_eapd=on > outputs.SPDIF_source=dig-dac-0:1 > record.adc-2:3_source=mic,mic2,line-in,hp,line2,line3,mix > record.adc-0:1_source=mic,mic2,line-in,hp,line2,line3,mix > inputs.dac-8:9=126,126 > inputs.mix8_source=dac-8:9,mix > outputs.line_sense=unplugged > outputs.line2_sense=unplugged > outputs.line3_sense=unplugged > outputs.mic_sense=unplugged > outputs.mic2_sense=unplugged > outputs.line-in_sense=plugged > outputs.hp_sense=unplugged > outputs.master=126,126 > outputs.master.mute=off > outputs.master.slaves=dac-0:1,dac-6:7,line,hp > record.volume=128,128 > record.volume.mute=off > record.volume.slaves=adc-0:1,adc-2:3 > outputs.mode=digital > record.enable=sysctl
Re: disk integrity checking
On Feb 22 07:52:11, n...@holland-consulting.net wrote: > (this is a request for a "that's stupid", not a suggestion > of something people should do at this point) > > An idea that's been floating around in my head, inspired > by the ZFS "scrubbing" idea: rather than build that "check > your data" process into the file system, just do something > periodically like this: > > # dd if=/dev/rsd0c of=/dev/null bs=1m Yes; this line has been in my weekly.local for years now, for every disk that matters. > and repeat against all physical drives. The logic being, > all hard drives have some kind of error detection logic > in them, at least a checksum of some kind on all data blocks. > See if you can read every block on the disk. No errors, your > data might be intact. Errors, it probably isn't (or won't > be in the future). Crypto-grade integrity, probably not... > but probably quite sufficient for spotting most bad spots > on the disk. Exactly. This has been an early warning to me more than once. Any IO errors, throw the disk out. Some disks are supposed to replace a bad block with a spare, as long as they have spare blocks. Running this, I hope to trigger that before I see IO errors in production. > So...I tried it against disks with mounted file systems and > softraid partitions on them. > > It...seems to work. I did have one laptop with a softraid > encrypted drive that gave a nice, clear "Input/output error", > but I can't reproduce it (maybe it got locked out? Seems > odd on a read, but ... > > Is this sane? is it safe to attempt to read all the blocks > on an entire 'c' partition of a disk that's doing "other > things" at the same time, including a layers of softraid? Being run in weekly.local, which is 03:30 in the Sat morning, my machines are not doing much; but I have also run that on workstations while firefoxing as usual, no problems except the occassional slowdown. I keep a log of the times it takes for each disk, observing how they get slower over time, gradually replacing rotating plates with SSDs everywhere. (Strangely, it seems to matter in which of the "same" PCIe slots you put an NVME disk, for example.) Jan
scp to an unwritable filesystem - err msg
This is current/amd64 on a PC; no dmesg as it's not HW related. I have a filesystem on a remote machine, mounted ro. When trying to copy onto that filesystem: $ scp -r dir/ box:/fs/path/ Enter passphrase for key '/Users/hans/.ssh/id_ed25519': scp: stat remote: No such file or directory scp: failed to upload directory dir/ to /fs/path/ After a bit of headscratching, I copied to box:/tmp instead and then moved /tmp/dir to /fs/path on the remote machine, realizing that it's mounted ro. That makes me think that the scp: stat remote: No such file or directory message is a bit misleading: /fs/path/dir cannot be created, as in box$ mv: rename /tmp/dir to /fs/path/dir: Read-only file system not that an intermediate path does not exist. If I'm reading usr.bin/ssh/ right, it's the get_decode_stat() calling fx2txt(), but the code is a bit over my head ... Note that this happens when scp'ing a directory; when scping a file onto the ro fs, the message is scp: dest open "/fs/path/foo": Failure Jan
Re: Safely remove USB drive
On Feb 08 13:56:18, pe...@bsdly.net wrote: > 1) close any open files stored there > 2) make sure no process has the media as $PWD (as in, cd away from there, >and really a variation on the first) > 3) issue at least one sync command (some folklore will insist on three) > 4) umount the media from wherever it was mounted 4 takes care of 1,2,3, right?
Re: Live stick / cd from official sources
post the full dmesg On Feb 04 17:48:15, my2...@aol.com wrote: > Sorry if I bother you again with the thread. > > The minipc will be on business from tomorrow and I will use it > together with a little student of mine: it is enough critical that the > "not configured" hello! doesn't reppresent anything "risky". > Eg: I tried to tweak the custom bios of Fujitsu for a more perfomant > fan/cpu but the machine started litterally to fly while booting. Precautially > I hanged manually the booting process. > > The part of dmesg I'm wondering about is the following: > > "FUJ02E3" at acpi0 not configured > > "PNP0C14" at acpi0 not configured > "PNP0C32" at acpi0 not configured > "PNP0C14" at acpi0 not configured > > "PNP0C0B" at acpi0 not configured > "PNP0C0B" at acpi0 not configured > "PNP0C0B" at acpi0 not configured > "PNP0C0B" at acpi0 not configured > "PNP0C0B" at acpi0 not configured > > acpicpu0 at acpi0: C1(@1 halt!), PSS > acpicpu1 at acpi0: C1(@1 halt!), PSS > acpicpu2 at acpi0: C1(@1 halt!), PSS > acpicpu3 at acpi0: C1(@1 halt!), PSS > > cpu0: using Broadwell MDS workaround > > And for your own concerns: > azalia0 at pci0 dev 3 function 0 "Intel Core 4G HD Audio" rev 0x06: msi > azalia0: No codecs found > > Thanks! > -- Daniele Bonini > > Feb 1, 2023 23:24:20 Daniele B. : > > > Just a small boot summary to attach to the thread.. > > > > ( I'm not that easy to share more about my config and sorry about that) > > > > The Fujitsu mini-pc has a custom made Ami Bios configuration. > > > > It went immidiately up and running although with some "not configured" > > hello! > > that didn't impact the correct system launch in all its main components. > > > > The software configuration instead had a serious problem with Netbeans Ide > > that was not able to > > open and it crashed just after the splash. Unfortunately, I'm sure the > > problem is related to the hardware conf > > change that somehow was referenced in the local files (cache, user conf or > > both) that I erased to > > left Netbeans regenerating them. Between the hardware changes that I care > > most: > > - cpu0 -> acpitz0 in the sensors > > - the name of the ethernet (java somehow likes the net) > > > > Cosmetic stuff: I cut off xorg.conf device "overclocking" parameters to a > > standard configuration to > > get the new video card much more speedy: my xorg.conf was aged and probably > > xorg has already been > > optimized to survive best without "my optimal hints". > > > > :D > > > > -- Daniele Bonini > > > > Feb 1, 2023 12:48:45 Peter N. M. Hansteen : > > > >> On Wed, Feb 01, 2023 at 12:36:18PM +0100, Daniele B. wrote: > >>> The mini-pc arrived in three working days, from Germany to Italy. 30 > >>> bucks of DHL delivery but.. > >>> I could be certainly happy of such a service.. > >>> > >>> (although at time I can't still be sure about the possibility to openbsd > >>> it..). > >>> > >>> Can we arrange these situation in a better bsd fashion? > >>> > >>> I will update you to bugs@ as soon I can boot this mini-pc, hopefully > >>> I will not :D > >> > >> As several of us have said already, more likely than not the install will > >> be easy and > >> straightforward. If it isn't, bugs@ is the place to report. > >> > >> And anyway as soon as you have the thing running, sending the dmesg as > >> described > >> in https://www.openbsd.org/faq/faq4.html#SendDmesg will be much > >> appreciated. > >> > >> - Peter > >> > >> -- > >> Peter N. M. Hansteen, member of the first RFC 1149 implementation team > >> https://bsdly.blogspot.com/ https://www.bsdly.net/ https://www.nuug.no/ > >> "Remember to set the evil bit on all malicious network traffic" > >> delilah spamd[29949]: 85.152.224.147: disconnected after 42673 seconds. > >
Re: Live stick / cd from official sources
On Feb 01 12:36:18, my2...@aol.com wrote: > is it so ridiculous to ask a system test to boot in graphical mode in > 2.5 min to care about it? In the time it took you to write these emeils, you could have a _full_install_ on a USB stick, including X and everything.
Re: chmod change means dump(8) the file
On Jan 26 00:18:45, h...@stare.cz wrote:
> I have a large /media disk that I backup nightly using dump(8):
> full level 0 on the Sun/Mon night, incrementals through the week.
> The level 0 dump is huge, the incrementals are usualy trivial
> unless I add something to /media.
>
> Yesterday I chmod'd a lot of the files, without making any other change.
> That resulted in a huge level 2 dump; I suppose a chmod change counts
> as a changed file, so they all got dumped anew, even though the content
> of the file(s) has not changed.
>
> Is that intentional? It seems there is a lot of space to be saved
> if it's "only" the metadata that have changed. Is that decided by
> simply looking at the stat(2)? In particular, newer ctime is
> just as good a reason to dump the _content_ as newer mtime?
Seems so:
/* Determine if given inode should be dumped */
[...]
if (CHECKNODUMP(dp) &&
(DIP(dp, di_mtime) >= spcl.c_ddate ||
DIP(dp, di_ctime) >= spcl.c_ddate)) {
chmod change means dump(8) the file
I have a large /media disk that I backup nightly using dump(8): full level 0 on the Sun/Mon night, incrementals through the week. The level 0 dump is huge, the incrementals are usualy trivial unless I add something to /media. Yesterday I chmod'd a lot of the files, without making any other change. That resulted in a huge level 2 dump; I suppose a chmod change counts as a changed file, so they all got dumped anew, even though the content of the file(s) has not changed. Is that intentional? It seems there is a lot of space to be saved if it's "only" the metadata that have changed. Is that decided by simply looking at the stat(2)? In particular, newer ctime is just as good a reason to dump the _content_ as newer mtime? Jan
Re: old UNIX documentation
On Sep 13 07:04:55, j...@kerhand.co.uk wrote: > > Long ago and far away, the Berkeley distributions used to ship an > > assortment of system documentation in /usr/share/doc, including a > > general-purpose system administrators manual. > > > > I guess people didn't want to update those, or maybe thought they > > were sacred relics, never to be touched. But all the *BSDs dropped > > them, years ago. I thought that was the wrong move; they should > > have been kept, along with a /usr/share/doc/README that noted they > > are historical, and therefore probably out of date. Although I'm > > sure the vi documentation stands up to this day. > > > > we stopped installing them because many of them were falling out of date > and there wasn;t really the resources (or motivation) to update them. > however not all of them were removed. although no longer installed, some > of the better ones remain in the source tree. from a quick look: Some of them are still quite nice to read! > /usr/src/usr.bin/gprof/PSD.doc > /usr/src/usr.bin/lex/PSD.doc > /usr/src/usr.bin/m4/PSD.doc > /usr/src/usr.bin/make/PSD.doc > /usr/src/usr.bin/yacc/PSD.doc > /usr/src/bin/csh/USD.doc > /usr/src/bin/ed/USD.doc > /usr/src/games/trek/USD.doc > /usr/src/usr.bin/awk/USD.doc > /usr/src/usr.bin/bc/USD.doc Index: usr.bin/bc//USD.doc/bc === RCS file: /cvs/src/usr.bin/bc/USD.doc/bc,v retrieving revision 1.9 diff -u -p -r1.9 bc --- usr.bin/bc//USD.doc/bc 9 Jul 2004 10:23:05 - 1.9 +++ usr.bin/bc//USD.doc/bc 14 Jan 2023 22:41:09 - @@ -1029,7 +1029,7 @@ to the named expression on the left. .PP The result of the above expressions is equivalent to ``named expression = named expression OP expression'', -where OP is the operator after the = sign. +where OP is the operator before the = sign. .NH 1 Relations .PP > /usr/src/usr.bin/dc/USD.doc > /usr/src/usr.bin/mail/USD.doc > /usr/src/usr.bin/sed/USD.doc > /usr/src/usr.bin/vi/docs/USD.doc > /usr/src/sbin/fsck_ffs/SMM.doc > /usr/src/usr.sbin/lpr/SMM.doc > > jmc > >
Re: sndio and bit perfect playback
On Jan 13 15:58:20, euryd...@riseup.net wrote: > On 23/01/13 12:42, Jan Stary wrote: > > On Jan 09 13:10:09, euryd...@riseup.net wrote: > > > I was able to distinguish between samples created by > > > audio/sox and aucat(1) in informal AB/X testing on my 7th generation X1 > > > Carbon > > > with HiFiMan Sundara headphones plugged in. To describe the circumstances > > > + > > > outcome briefly: 9 out of 10 correct in 10 trials > > > > http://stare.cz/.tmp/resample/ > > Which is which? > > That's not how AB/X tests work, but it also doesn't matter because they're all > the same file. Aaaah, now you have spoiled that as well :-)
Re: sndio and bit perfect playback
> > > I'd certainly be interested in the ability to play audio in a way > > > that avoids resampling altogether, > > > > If you have a 48kHz file, and your audio device can only do 44100, > > then you have to resample, no way around it. > > > similar to what a user can do on FreeBSD with the > > > following sysctl tweaks: > > > # sysctl hw.snd.maxautovchans=0 dev.pcm.0.bitperfect=1 > > It's off topis of course, but What is dev.pcm.%d.bitperfect gonna do > > if the sample rate (or some other characteristics) is not what the device > > itself supports? As in e.g. $ play -r 12345 -c 3 -n synth 10 On Jan 10 09:36:28, a...@caoua.org wrote: > chown /dev/audio* > rcctl stop sndiod After doing that, $ play -V 48000.wav play: SoX v14.4.2 play INFO formats: detected file format type `wav' Input File : '48000.wav' Channels : 2 Sample Rate: 48000 Precision : 16-bit Duration : 00:00:25.00 = 120 samples ~ 1875 CDDA sectors File Size : 4.80M Bit Rate : 1.54M Sample Encoding: 16-bit Signed Integer PCM Endian Type: little Reverse Nibbles: no Reverse Bits : no Output File: 'default' (sndio) Channels : 2 Sample Rate: 48000 Precision : 16-bit Duration : 00:00:25.00 = 120 samples ~ 1875 CDDA sectors Sample Encoding: 16-bit Signed Integer PCM Endian Type: little Reverse Nibbles: no Reverse Bits : no play INFO sox: effects chain: input48000Hz 2 channels play INFO sox: effects chain: output 48000Hz 2 channels In:15.4% 00:00:03.84 [00:00:21.16] Out:184kk [ ---=|=--- ]Clip:0 $ play -V 44100.wav play: SoX v14.4.2 play INFO formats: detected file format type `wav' Input File : '44100.wav' Channels : 2 Sample Rate: 44100 Precision : 16-bit Duration : 00:00:25.00 = 1102500 samples = 1875 CDDA sectors File Size : 4.41M Bit Rate : 1.41M Sample Encoding: 16-bit Signed Integer PCM Endian Type: little Reverse Nibbles: no Reverse Bits : no Output File: 'default' (sndio) Channels : 2 Sample Rate: 44100 Precision : 16-bit Duration : 00:00:25.00 = 1102500 samples = 1875 CDDA sectors Sample Encoding: 16-bit Signed Integer PCM Endian Type: little Reverse Nibbles: no Reverse Bits : no play INFO sox: effects chain: input44100Hz 2 channels play INFO sox: effects chain: output 44100Hz 2 channels In:25.3% 00:00:06.32 [00:00:18.68] Out:279kk [ =|= ]Clip:0 Aborted. $ aucat -i 44100.wav default: unsupported audio params $ aucat -i 48000.wav default: unsupported audio params It seems sox negotiates either 48000 or 44100 with sndio (meaning the sndio library, not the non-running sndiod) and sends that, but aucat errors out. But the device itself can do 48000 (says audioctl), so is that a bug in aucat? Jan
Re: sndio and bit perfect playback
On Jan 09 13:10:09, euryd...@riseup.net wrote: > I was able to distinguish between samples created by > audio/sox and aucat(1) in informal AB/X testing on my 7th generation X1 Carbon > with HiFiMan Sundara headphones plugged in. To describe the circumstances + > outcome briefly: 9 out of 10 correct in 10 trials http://stare.cz/.tmp/resample/ Which is which?
Re: sndio and bit perfect playback
On Jan 11 01:10:11, a...@caoua.org wrote: > On Tue, Jan 10, 2023 at 08:22:27PM +, John Rigg wrote: > > > > > > # If I recall correctly, I converted to FLAC here because the WAV > > > > headers > > > > # generated by aucat and SoX differed, and so SoX would refuse to play > > > > WAV fil > > > es > > > > # created by aucat. > > > > > > That would be a bug in itself. > > > How exactly does SoX refuse to play the WAVs created by aucat? > > > > sox is strict about headers and will complain if cbSize is inconsistent with > > fmt size. Workaround is to use the '-t sndfile' option. > > > > aucat is not alone here; several other programs write .wav files that > > require this option with sox. > > > > Here's a diff to switch aucat to extended wav format. According to > Microsoft docs, it is needed if bits > 16 or if there are more than 2 > channels, which aucat supports. It fixes the sox problem. Thank you. One nit that's perhaps related: $ aucat -n in.wav -o out.wav produces a stereo 24bit out.wav, as -c 0:1 -e s24 is the default. Would it make more sense with -n to preserve the characteristics of in.wav instead? Jan > No regressions found with various ports and few windows programs. > > ok? > > Index: afile.c > === > RCS file: /cvs/src/usr.bin/aucat/afile.c,v > retrieving revision 1.9 > diff -u -p -u -p -r1.9 afile.c > --- afile.c 24 Oct 2021 21:24:15 - 1.9 > +++ afile.c 10 Jan 2023 23:52:47 - > @@ -432,12 +432,17 @@ afile_wav_writehdr(struct afile *f) > le32_set(, f->endpos - sizeof(hdr.riff)); > memcpy(hdr.fmt_hdr.id, wav_id_fmt, 4); > le32_set(_hdr.size, sizeof(hdr.fmt)); > - le16_set(, 1); > + le16_set(, WAV_FMT_EXT); > le16_set(, f->nch); > le32_set(, f->rate); > le32_set(, f->rate * f->par.bps * f->nch); > le16_set(, f->par.bps * f->nch); > le16_set(, f->par.bits); > + le16_set(, > + WAV_FMT_EXT_SIZE - WAV_FMT_SIZE - sizeof(hdr.fmt.extsize)); > + le16_set(, f->par.bits); > + le16_set(, 1); > + memcpy(, wav_guid, sizeof(hdr.fmt.guid)); > memcpy(hdr.data_hdr.id, wav_id_data, 4); > le32_set(_hdr.size, f->endpos - f->startpos); > return afile_writehdr(f, , sizeof(struct wav_hdr)); > >
Re: sndio and bit perfect playback
I don't get the point of your message explaning what dither is. My whole point was that one of the sources of the perceived difference between how sox resamples and hows aucat resamples might be dithering, as aucat does not differ (right?). On Jan 09 17:01:52, g...@oat.com wrote: > The math goes back to Shannon and sampling theory: > > Any time you remove significant digits you remove information. > One interpretation is that you introduce noise. > Period. The math says so. > The math says what the resulting power is. > > You have the option to determine where the noise goes. > > If you do nothing the noise is correlated with the input > signal. You get what in audio terms is intermodulation > distortion. In the simplest case this is harmonic distortion. > > You can spread the noise by applying digital transforms. > You -cannot- remove it entirely. > The easiest and most common method is dithering > which spreads the power over the (audio) spectrum. > That result can be white, pink etc. > > People are very sensitive to intermodulation distortion. > Less sensitive to harmonic distortion. > (People who like vacuum tubes and vinyl -like- > second harmonic distortion = "rich sound" ) > Very less sensitive to random noise. > Even less to mostly-random noise outside of 1KHz-5KHz or so. > > Some of the standard minimal tests of audio equipment translated > to the digital domain: > > Run FFTs with sufficient accuracy on the following > (double precision at least for good results): > (a) a precise sine wave (32 bits or better) truncated to 24 and 16 bits > testing harmonic distortion (usually 1KHz) > > (b) two sines (usually 1KHz and 7KHz) testing intermodulation distortion > > (c) (a) and (b) resampled (96 to 48, 48 to 44.1, etc.) and > resampled 24 to 16 testing purely digital distortion > > Decide for yourself if the results are significant for your use. > > If you read the sox(1) man page you'll notice that it computes > in 32 bits and applies dithering -by default- when truncating to > the output sample width. You can defeat it if you want and > wish to accept the result. > >
Re: sndio and bit perfect playback
On Jan 09 13:10:09, euryd...@riseup.net wrote:
> > > aucat(1) currently says
> > >
> > > BUGS
> > >Resampling is low quality.
> > >
> > > Is this still considered to be the case?
> >
> > IMO, it doesn't deserve the BUGS section anymore, I'll remove this
> > sentence. Objections?
>
> Although I need to finalize the Perl script I was using to do this (life gets
> busy), in practice I was able to distinguish between samples created by
> audio/sox and aucat(1) in informal AB/X testing on my 7th generation X1 Carbon
> with HiFiMan Sundara headphones plugged in. To describe the circumstances +
> outcome briefly: 9 out of 10 correct in 10 trials; randomly sampling from an
> array containing the givens A and B to get an unknown X; comparing 15 seconds
> of
> audio; audio/sox as the playback software. In the future, I would do >=16
> trials, and perhaps conduct the tests from my desktop instead since it has a
> discrete amp and DAC.
>
> In offline resampling from 48kHz to 44.1kHz, the highs were most affected and
> that's what I was able to use to distinguish between samples. The percussion,
> especially the cymbals, sounded different in particular because the clip
> resampled by aucat had cymbal crashes that seemed to 'shimmer' much less (the
> decay was more rapid). The spectrograms seemed to confirm that the highs were
> most affected.
>
> Whether that means "low quality resampling" or merely that the results of the
> two commands can be differentiated is something I'm uncertain of. Either way,
> I
> don't know enough about C or sndio internals to be useful in that domain yet.
> As
> an aside, I did find this to be a useful resource for learning about digital
> audio resampling, and they recommend audio/sox there.
>
> https://ccrma.stanford.edu/~jos/resample/
>
> I hadn't said anything about this earlier because I wanted to take the time to
> finish + document the script, reproduce my results with a royalty free sample
> at
> a greater trial count, and then post. Given that I haven't done so yet, I can
> at
> least post the commands used to resample the audio for those that are
> interested.
>
>
> # This was originally an opus file downloaded with www/yt-dlp.
> # Converting to WAV so both SoX and aucat can work with it.
> $ opusdec input.{opus,wav}
Can you please point to the specific opus file,
so that I can reproduce exactly what you have done?
> # Resample 16-bit 48kHz WAV file to 44.1kHz using both SoX and aucat(1).
> #
> # If I recall correctly, I converted to FLAC here because the WAV headers
> # generated by aucat and SoX differed, and so SoX would refuse to play WAV
> files
> # created by aucat.
That would be a bug in itself.
How exactly does SoX refuse to play the WAVs created by aucat?
> $ sox -G input.wav -t wav - rate -v 44100 | flac - -o output-sox.flac
> $ aucat -i input.wav -h wav -r 44100 -e s16 -o - | flac - -o output-aucat.flac
sox dithers by default; can you try with sox -D
to see of the results are more similar?
> # Generate spectrograms for later inspection/comparison.
> $ sox output-sox.flac -n spectrogram -o spectrogram-sox.png
> $ sox output-aucat.flac -n spectrogram -o spectrogram-aucat.png
>
> I'd certainly be interested in the ability to play audio in a way
> that avoids resampling altogether,
If you have a 48kHz file, and your audio device can only do 44100,
then you have to resample, no way around it.
> similar to what a user can do on FreeBSD with the
> following sysctl tweaks:
>
> # sysctl hw.snd.maxautovchans=0 dev.pcm.0.bitperfect=1
>
> https://www.freebsd.org/cgi/man.cgi?query=sound=FreeBSD+13.1-RELEASE=html
It's off topis of course, but What is dev.pcm.%d.bitperfect gonna do
if the sample rate (or some other characteristics) is not what the device
itself supports? As in e.g. $ play -r 12345 -c 3 -n synth 10
