Re: cumbersome mtree
Hello Michael, thnx for the answer. I come from a couple of long white nights and indeed this night was the longest one (for who is interested I'm playing on a barely simple ide that at a certain point in time hopefully should enforce RAD amenities, good practices, etc. I'm working in tcltk). Let me reconnect with my body and I will give a try to your suggestion. -- Nowarez Market Nov 28, 2023 06:35:36 Michael Hekeler : > 'man mtree' is a good start. > or check security(8). On 7.4 you can do: > $ grep -B 12 -A 27 "sub check_mtree" /usr/libexec/security
Re: cumbersome mtree
> Hello, > > I was enthusiastic to write down a tool that permitted everyone > to check and print the default file permissions of a given path > but when I knocked my eyes against mtree behavior I remained > frightened. > > Given for example: > > mtree -c -f /etc/mtree/4.4BSD.dist -K uid,guid,mode -p /usr/games -e what is your intention when using these flags? What do you want to do? > I was expecting that: > -p let me pass the path to check to mtree like /usr/games Yes, you are right: p uses path instead of the current directory. > -K uid,guid,mode let me suggest the output for each file entry > specified together with -c command option on 7.4: $ man mtree | grep -A 57 "supported keywords" it also gives hint about the specified 'guid' keyword > But indeed mtree behavior is really different. Yes, you are right. > Please point me in the right direction with mtre 'man mtree' is a good start. or check security(8). On 7.4 you can do: $ grep -B 12 -A 27 "sub check_mtree" /usr/libexec/security
Re: OnLogic Helix 330
On Mon, Nov 27, 2023 at 09:10:18PM -0700, Devin Reade wrote: > On Tue, 2023-11-28 at 11:29 +1100, Jonathan Gray wrote: > > > STD_PHYID1 67C9 > > STD_PHYID2 DC00 > > > > /sys/dev/mii/miivar.h > [...] > > Thanks. > > So it looks like the approach here is to add a gpyphy.c and > gpyphyreg.h file, and tie it in via miidevs, correct? Yes, though a .h isn't needed. Two models are described on page 182 of the datasheet "Chip Identification and Ordering Information". > > I don't understand files.mii but it looks like it's only had one > commit in the last nine years; is files.mii obsolete? If not, > where do I find out more? Not all Ethernet drivers use the sys/dev/mii code. The config glue would look something like the below, see files.conf(5) and config(8). miidevs.h is regenerated by running 'make' in /sys/dev/mii after modifying miidevs. Index: sys/dev/mii/miidevs === RCS file: /cvs/src/sys/dev/mii/miidevs,v diff -u -p -r1.133 miidevs --- sys/dev/mii/miidevs 8 Jul 2023 08:18:30 - 1.133 +++ sys/dev/mii/miidevs 28 Nov 2023 04:23:25 - @@ -73,6 +73,7 @@ oui PLESSEYSEMI 0x046b40Plessey Semi. oui NATSEMI0x080017National Semi. oui TI 0x080028Texas Instruments oui MOTORCOMM 0x13d47aMotorcomm +oui MAXLINEAR 0x19f277MaxLinear /* in the 79c873, AMD uses another OUI (which matches Davicom!) */ oui xxALTIMA 0x000895Altima @@ -264,6 +265,10 @@ model MARVELL E1116R 0x0024 88E1116R Gi model MARVELL E30160x0026 88E3016 10/100 PHY model MARVELL PHYG65G 0x0027 PHYG65G Gigabit PHY model MARVELL E15450x002a 88E1545 Quad 10/100/1000 PHY + +/* MaxLinear PHYs */ +model MAXLINEAR GPY115B0x0030 GPY115B Gigabit PHY +model MAXLINEAR GPY115C0x0031 GPY115C Gigabit PHY /* Micrel PHYs */ model MICREL KSZ9021 0x0021 KSZ9021 10/100/1000 PHY Index: sys/dev/mii/files.mii === RCS file: /cvs/src/sys/dev/mii/files.mii,v diff -u -p -r1.33 files.mii --- sys/dev/mii/files.mii 4 Mar 2023 22:40:37 - 1.33 +++ sys/dev/mii/files.mii 28 Nov 2023 04:25:43 - @@ -152,3 +152,7 @@ filedev/mii/brswphy.c brswphy device ytphy: mii_phy attach ytphy at mii file dev/mii/ytphy.c ytphy + +device gpyphy: mii_phy +attach gpyphy at mii +file dev/mii/gpyphy.cgpyphy Index: sys/arch/amd64/conf/GENERIC === RCS file: /cvs/src/sys/arch/amd64/conf/GENERIC,v diff -u -p -r1.520 GENERIC --- sys/arch/amd64/conf/GENERIC 11 Oct 2023 12:52:00 - 1.520 +++ sys/arch/amd64/conf/GENERIC 28 Nov 2023 04:27:28 - @@ -626,6 +626,7 @@ etphy* at mii? # Agere/LSI ET1011 Tru jmphy* at mii? # JMicron JMP202/JMP211 PHYs atphy* at mii? # Attansic F1 PHYs ipgphy*at mii? # IC Plus IP1000A PHYs +gpyphy* at mii?# MaxLinear GPY115 PHYs ukphy* at mii? # "unknown" PHYs eap* at pci? # Ensoniq AudioPCI S5016
Re: OnLogic Helix 330
On Tue, 2023-11-28 at 11:29 +1100, Jonathan Gray wrote: > STD_PHYID1 67C9 > STD_PHYID2 DC00 > > /sys/dev/mii/miivar.h [...] Thanks. So it looks like the approach here is to add a gpyphy.c and gpyphyreg.h file, and tie it in via miidevs, correct? I don't understand files.mii but it looks like it's only had one commit in the last nine years; is files.mii obsolete? If not, where do I find out more?
Re: a couple question about my fde setup
From: Nick Holland To: misc@openbsd.org Date: Mon, 20 Nov 2023 07:47:40 -0500 Subject: Re: a couple question about my fde setup On 11/19/23 18:09, Shadrock Uhuru wrote: hi all a couple question about my fde first, i have fde setup using a keydisk on my laptop, encryption and decryption works fine when i reboot with the key inserted it doesn't find the key, i have to shut the machine down and restart it then the key is detected, is this normally how a reboot works with fde and keydisk ? second when i boot the laptop it tries to boot from the wrong disk, it tries to boot off hd0 whereby at the boot prompt i then have to type boot sd0a:/bsd which then proceeds to a normal boot, do i just run /usr/mdec/installboot -v /boot /usr/mdec/biosboot sd0 to fix this ? You have provided a whole lot of no-information here. dmesg, disk layout and boot mode would be nice starting points. "hd0"? What is that in your machine? Hi Nick ok lets fix that see below for dmesg, fdisk and disklabel output and corrected boot messages. Both issues sound like a firmware issue. Boot device is usually controllable in BIOS/firmware setup -- once the OpenBSD boot loader is running, it is too late to determine what you boot from. USB storage not being found under some boot conditions and being seen on others, sounds like a firmware bug. Almost certainly, in fact, as OpenBSD itself isn't loaded and running, it's just the boot code talking to the firmware or BIOS. any modern-ish computers support both UEFI and BIOS booting. They often have different bugs in different modes. I have a couple machines here that were sold running embedded Linux with a warning "must use BIOS mode" in the firmware for their original application...but OpenBSD only can see storage in EFI mode. Also look for firmware updates to your system. I'd suggest starting with reloading in the opposite boot mode first, because if a new BIOS will have to reinstall to switch boot modes technically, no, but if you have to ask, yes). Nick. = Dmesg: OpenBSD 7.3 (GENERIC.MP) #0: Wed Jul 12 05:09:49 MDT 2023 r...@syspatch-73-amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP real mem = 8482910208 (8089MB) avail mem = 8206409728 (7826MB) random: good seed from bootblocks mpath0 at root scsibus0 at mpath0: 256 targets mainbus0 at root bios0 at mainbus0: SMBIOS rev. 2.6 @ 0xe0850 (63 entries) bios0: vendor Phoenix Technologies Ltd. version "07QA" date 04/20/2012 bios0: SAMSUNG ELECTRONICS CO., LTD. 300E4A/300E5A/300E7A/3430EA/3530EA efi0 at bios0: UEFI 2.0 acpi0 at bios0: ACPI 3.0 acpi0: sleep states S0 S1 S3 S4 S5 acpi0: tables DSDT FACP SLIC SSDT ASF! HPET APIC MCFG SSDT SSDT UEFI UEFI UEFI acpi0: wakeup devices P0P1(S4) GLAN(S4) HDEF(S4) RP01(S4) PXSX(S4) RP02(S4) PXSX(S4) RP03(S4) PXSX(S4) RP04(S4) PXSX(S4) RP05(S4) PXSX(S4) RP06(S4) PXSX(S4) RP07(S4) [...] acpitimer0 at acpi0: 3579545 Hz, 24 bits acpihpet0 at acpi0: 14318179 Hz acpimadt0 at acpi0 addr 0xfee0: PC-AT compat cpu0 at mainbus0: apid 0 (boot processor) cpu0: Intel(R) Core(TM) i3-2350M CPU @ 2.30GHz, 2294.83 MHz, 06-2a-07 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,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,POPCNT,DEADLINE,XSAVE,AVX,NXE,RDTSCP,LONG,LAHF,PERF,ITSC,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, 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 99MHz cpu0: mwait min=64, max=64, C-substates=0.2.1.1.2, IBE cpu1 at mainbus0: apid 1 (application processor) cpu1: Intel(R) Core(TM) i3-2350M CPU @ 2.30GHz, 2294.82 MHz, 06-2a-07 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,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,POPCNT,DEADLINE,XSAVE,AVX,NXE,RDTSCP,LONG,LAHF,PERF,ITSC,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, 3MB 64b/line 12-way L3 cache cpu1: smt 1, core 0, package 0 cpu2 at mainbus0: apid 2 (application processor) cpu2: Intel(R) Core(TM) i3-2350M CPU @ 2.30GHz, 2294.83 MHz, 06-2a-07 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,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,POPCNT,DEADLINE,XSAVE,AVX,NXE,RDTSCP,LONG,LAHF,PERF,ITSC,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, 3MB 64b/line 12-way L3 cache cpu2: smt 0, core 1, package 0 cpu3 at mainbus0: apid 3
Re: OnLogic Helix 330
On Mon, Nov 27, 2023 at 11:30:23PM -, Stuart Henderson wrote: > On 2023-11-27, Devin Reade wrote: > > Once running snapshots, I initially configured the network for dwqe0. > > It came up and I was able to ping hosts on the dwqe0 network, but > > I noticed that carrier state seemed unpredictable. I then deleted > > hostname.dwqe0 and started trying to determine behavior based only on > > ifconfig status and media values. In short, things seem to be > > quite unpredicable. Some sample trials are shown, below: > [..] > > I don't know enough about it to go into detail, but these sort of symptoms > are making me think of issues with the PHY driver rather than the nic driver. > > > dwqe0 at pci0 dev 29 function 1 "Intel Elkhart Lake Ethernet" rev 0x11: rev > > 0x52, address 84:8b:cd:4d:b5:f6 > > ukphy0 at dwqe0 phy 1: Generic IEEE 802.3u media interface, rev. 3: OUI > > 0x19f277, model 0x0030 > > dwqe1 at pci0 dev 29 function 2 "Intel Elkhart Lake Ethernet" rev 0x11: rev > > 0x52, address 84:8b:cd:4d:bc:36 > > ukphy1 at dwqe1 phy 1: Generic IEEE 802.3u media interface, rev. 3: OUI > > 0x19f277, model 0x0030 > > No idea whether there might be a better phy driver to start from, nothing > shows up in searches for that OUI. Maybe there are clues in linux dmesg or > mii tools. https://www.onlogic.com/hx330/ "1x MaxLinear GPY115 or 2x MaxLinear GPY115" https://assets.maxlinear.com/web/documents/617807_gpy115b1vi_gpy115c0vi_ds_rev1.4.pdf STD_PHYID1 67C9 STD_PHYID2 DC00 /sys/dev/mii/miivar.h #define MII_OUI(id1, id2) (((id1) << 6) | ((id2) >> 10)) (0x67c9 << 6) | (0xdc00 >> 10) is 0x19f277 #define IDR2_MODEL 0x03f0 /* vendor model */ #define MII_MODEL(id2) (((id2) & IDR2_MODEL) >> 4) as model is 0x30 ID2 will have those bits set 0xdc00 | (0x30 << 4) is 0xdf00
Re: OnLogic Helix 330
On Mon, 2023-11-27 at 23:30 +, Stuart Henderson wrote: > I don't know enough about it to go into detail, but these sort of > symptoms are making me think of issues with the PHY driver rather > than the nic driver. Yeah, mostly at the moment I'm trying to understand the different obsd network device layers. It looks like ukphy is a fallback for when a more specific PHY is not located, which means I'm likely looking for the PHY detection code. This part of the code base is new to me ... Devin
Re: OnLogic Helix 330
On 2023-11-27, Devin Reade wrote: > Once running snapshots, I initially configured the network for dwqe0. > It came up and I was able to ping hosts on the dwqe0 network, but > I noticed that carrier state seemed unpredictable. I then deleted > hostname.dwqe0 and started trying to determine behavior based only on > ifconfig status and media values. In short, things seem to be > quite unpredicable. Some sample trials are shown, below: [..] I don't know enough about it to go into detail, but these sort of symptoms are making me think of issues with the PHY driver rather than the nic driver. > dwqe0 at pci0 dev 29 function 1 "Intel Elkhart Lake Ethernet" rev 0x11: rev > 0x52, address 84:8b:cd:4d:b5:f6 > ukphy0 at dwqe0 phy 1: Generic IEEE 802.3u media interface, rev. 3: OUI > 0x19f277, model 0x0030 > dwqe1 at pci0 dev 29 function 2 "Intel Elkhart Lake Ethernet" rev 0x11: rev > 0x52, address 84:8b:cd:4d:bc:36 > ukphy1 at dwqe1 phy 1: Generic IEEE 802.3u media interface, rev. 3: OUI > 0x19f277, model 0x0030 No idea whether there might be a better phy driver to start from, nothing shows up in searches for that OUI. Maybe there are clues in linux dmesg or mii tools.
httpd: request rewrite & directory auto index
Hi misc@,
I may have found a bug with the combination of
`request rewrite` and `directory auto index`
when using httpd(8).
Preparation:
mkdir -p /var/www/htdocs/pub/user
echo "Hello World" > /var/www/htdocs/pub/user/test
/etc/httpd.conf:
server "example.com" {
listen on * port 80
root "/htdocs/website"
location match "/~(.*)" {
request rewrite "/%1"
root "/htdocs/pub"
directory auto index
}
}
`curl http://127.0.0.1/~user/test` works perfectly fine,
but `curl http://127.0.0.1/~user/` fails with Internal Server Error.
If I comment out the `request rewrite` and move user to ~user,
it works again.
--
Benjamin Stürz
Re: (Tina Turner) Scrumbled sectors playing dvd
On 28/11/23 00:10, Nowarez Market wrote: Talking about medium, I just mounted a dvd of Tina Turner: wiz# mount -t cd9660 /dev/cd0a /mnt/cdrom And I understand OpenBSD could eventually get a little wired but not like from screenshot attached.. I'm trying to playing it with Parole.. DVDs have Content Scramble System. https://en.wikipedia.org/wiki/Content_Scramble_System You may need to check libdvdcss support is compiled in and enabled. -- Stuart Longland (aka Redhatter, VK4MSL) I haven't lost my mind... ...it's backed up on a tape somewhere.
Re: OnLogic Helix 330
It took me a while to get to this, and I'm just starting to investigate, but I figured I'd give an update. Based on Stefan's comments, I wasn't expecting things to work, but I figured I'd post what I have so far. The behavior seems to be consistent between the 18 Nov and 24 Nov snapshots; the dmesg for the latter is at the end of this post, as well as the output of `ifconfig -a` and `pcidump -v 2>&1`; for the latter, note the PCIOCGETVPD that shows up when dumping 0:29:1. Summary: Two dwqe devices show, but the behavior is inconsistent. The first bit on Observations describes some of the inconsistency in case it provides anyone with some insight. After that, there's a short discussion section, followed by pcidump and dmesg outputs. Note that em0 is configured throughout (I'm mostly connecting via ssh while watching console). Changes are made on dwqe only. The cabling to the dwqe ports was validated by observing link status and media changes when the cabling was attached to em1. === Observations: Once running snapshots, I initially configured the network for dwqe0. It came up and I was able to ping hosts on the dwqe0 network, but I noticed that carrier state seemed unpredictable. I then deleted hostname.dwqe0 and started trying to determine behavior based only on ifconfig status and media values. In short, things seem to be quite unpredicable. Some sample trials are shown, below: Trial 1: When neither dwqe device is configured, but dwqe0 is plugged into a switch at boot (all expected behavior): a. Initially status on dwqe0 is "active", dwqe1 is "no carrier". b. Unplugging the cable results in both being "no carrier". c. Plugging into dwqe1 changes dwqe1 to "active" d. Changing cable to dwqe0 results in dwqe0 "active", and dwqe1 as "no carrier". Trial 2: When neither dwqe device is configured, and neither device is plugged into a switch: a. Initially at boot the carrier LEDs are dark (as expected). b. ifconfig does not report a status line at all (media shows as autoselect/none) c. Plugging dwqe0 into the switch fails to result in a change of status or media values, the link light doesn't show d. Switching the cable from dwqe0 to dwqe1 exhibits the same behavior as (c) Trial 3: Similar sequence as Trial 1, except this time: a. The link light of dwqe0 comes on at boot b. Neither dwqe status value is shown, media is autoselect/none, similar to Trial 2 c. The link light stays on when dwqe0 is unplugged. Trial 4: Following trial 3, do a shutdown and manual power-off (but leave the power connector attached): a. The link light of dwqe0 stays on while the device is powered down, even if the cable is detached b. Detaching power caused the link light to go off. Waiting 20s and reapplying power resulted in the no-link-light case of Trial 2, other than the fact that the cable was still connected. Trial 5: I actually saw this one early on, when hostname.dwqe0 was configured, and dwqe0 was plugged in during boot: a. Network connection is alive as configured. b. Detatching the cable causes dwqe0 to go "no carrier" c. Reattaching the cable does NOT return the status to "active". This seems to be intermittent. Trial 6: I'm pretty sure I also saw a case where the cable was plugged into dwqe0 after boot, the link light was initially off, but eventually lit after a few _minutes_. I wasn't recording enough detail at that point to be sure, though. === Discussion I'm just starting to wrap my head around the network device driver code. I've read the EuroBSDCon 2017 paper, and am going through the various *dwqe* files in CVS, as well as pcidevs*. Other hints are welcome. Stefan mentioned up-thread: > At present we are only attaching dwqe to one of several possible MAC > PCI IDs I'm assuming this is referring to dwqe_pci_attach, which would imply that the attach _does_ occur already since dmesg shows the two Elkhart Lake Ethernets? === ifconfig -a (trimmed, dwqe0 currently connected to switch) dwqe0: flags=8802 mtu 1500 lladdr 84:8b:cd:4d:b5:f6 index 3 priority 0 llprio 3 media: Ethernet autoselect (none) dwqe1: flags=8802 mtu 1500 lladdr 84:8b:cd:4d:bc:36 index 4 priority 0 llprio 3 media: Ethernet autoselect (none) === pcidump -v Domain /dev/pci0: 0:0:0: Intel Elkhart Lake Host 0x: Vendor ID: 8086, Product ID: 453a 0x0004: Command: 0006, Status: 2090 0x0008: Class: 06 Bridge, Subclass: 00 Host, Interface: 00, Revision: 01 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:
Re: CPU0 at 100% on Thinkpad 480 with OpenBSD 7.4
On Mon, Nov 27, 2023 at 11:38:01AM -0700, Theo de Raadt wrote: > Mike Larkin wrote: > > > On Mon, Nov 27, 2023 at 01:05:56PM -0500, Laurent Cimon wrote: > > > Hi, > > > > > > > > > The CPU0 on my Thinkpad 480 is always running at around 100%. It's on > > > OpenBSD 7.4. > > > > > > It seems to be doing this in the kernel. > > > > > > > > > Here is the CPU's line from top(1). > > > > > > CPU0: 0.0% user, 0.0% nice, 79.3% sys, 3.8% spin, 16.3 > > > > > > > > > It's always this specific CPU, and it's been draining my battery. > > > > > > How do I find what causes this? > > > > > > > > > I think that it starts doing it after waking from sleep, as it doesn't do > > > it > > > when the system is freshly started. > > > > > > But I'd need to do some tests before verifying this. > > > > > > > > > Laurent > > > > > > > Please search the list, this has been reported and solved many times, > > specifically for this machine. > > > > It is not solved. > > There is a "workaround" > > We do something wrong by not managing thunderbolt, but it is not clear > what we are supposed to do. My theory is that thunderbolt is initialized > far enough by BIOS or chipset default configuration or our driver, that > interrupts occur which we don't handle, and spin. > fair enough, that's a more accurate description.
Re: CPU0 at 100% on Thinkpad 480 with OpenBSD 7.4
Mike Larkin wrote: > On Mon, Nov 27, 2023 at 01:05:56PM -0500, Laurent Cimon wrote: > > Hi, > > > > > > The CPU0 on my Thinkpad 480 is always running at around 100%. It's on > > OpenBSD 7.4. > > > > It seems to be doing this in the kernel. > > > > > > Here is the CPU's line from top(1). > > > > CPU0: 0.0% user, 0.0% nice, 79.3% sys, 3.8% spin, 16.3 > > > > > > It's always this specific CPU, and it's been draining my battery. > > > > How do I find what causes this? > > > > > > I think that it starts doing it after waking from sleep, as it doesn't do it > > when the system is freshly started. > > > > But I'd need to do some tests before verifying this. > > > > > > Laurent > > > > Please search the list, this has been reported and solved many times, > specifically for this machine. > It is not solved. There is a "workaround" We do something wrong by not managing thunderbolt, but it is not clear what we are supposed to do. My theory is that thunderbolt is initialized far enough by BIOS or chipset default configuration or our driver, that interrupts occur which we don't handle, and spin.
Re: CPU0 at 100% on Thinkpad 480 with OpenBSD 7.4
On 11/27/23 13:12, Mike Larkin wrote: On Mon, Nov 27, 2023 at 01:05:56PM -0500, Laurent Cimon wrote: Hi, The CPU0 on my Thinkpad 480 is always running at around 100%. It's on OpenBSD 7.4. It seems to be doing this in the kernel. Here is the CPU's line from top(1). CPU0: 0.0% user, 0.0% nice, 79.3% sys, 3.8% spin, 16.3 It's always this specific CPU, and it's been draining my battery. How do I find what causes this? I think that it starts doing it after waking from sleep, as it doesn't do it when the system is freshly started. But I'd need to do some tests before verifying this. Laurent Please search the list, this has been reported and solved many times, specifically for this machine. I found the solution on the Lenovo forums. It's an ACPI issue with Thunderbolt, affecting even Linux and older versions of Windows. The solution is to disable Thunderbolt in the BIOS. Security -> I/O Port Access. Laurent
Re: CPU0 at 100% on Thinkpad 480 with OpenBSD 7.4
On Mon, Nov 27, 2023 at 01:05:56PM -0500, Laurent Cimon wrote: > Hi, > > > The CPU0 on my Thinkpad 480 is always running at around 100%. It's on > OpenBSD 7.4. > > It seems to be doing this in the kernel. > > > Here is the CPU's line from top(1). > > CPU0: 0.0% user, 0.0% nice, 79.3% sys, 3.8% spin, 16.3 > > > It's always this specific CPU, and it's been draining my battery. > > How do I find what causes this? > > > I think that it starts doing it after waking from sleep, as it doesn't do it > when the system is freshly started. > > But I'd need to do some tests before verifying this. > > > Laurent > Please search the list, this has been reported and solved many times, specifically for this machine.
CPU0 at 100% on Thinkpad 480 with OpenBSD 7.4
Hi, The CPU0 on my Thinkpad 480 is always running at around 100%. It's on OpenBSD 7.4. It seems to be doing this in the kernel. Here is the CPU's line from top(1). CPU0: 0.0% user, 0.0% nice, 79.3% sys, 3.8% spin, 16.3 It's always this specific CPU, and it's been draining my battery. How do I find what causes this? I think that it starts doing it after waking from sleep, as it doesn't do it when the system is freshly started. But I'd need to do some tests before verifying this. Laurent
Re: OpenBSD SMP - BGPd - send_rtmsg: action 1, prefix A.B.C.D/24: No buffer space available - panic: malloc: out of space in kmem_map
On Mon, Nov 27, 2023 at 04:57:35PM +0100, Laurent CARON wrote: > Hi, > > I'm currently migrating a BGPd server. > > Specs of "old" machine: > > - Dell R720 with Intel(R) Xeon(R) CPU E5-2637 v2and 16GB RAM > > - SMP Kernel (default) > > - BGPd runs fine with 5 full views > > - X710 NIC (ixl) 4 port interface > > Specs of "new" machine: > > - Dell R750xs with Intel(R) Xeon(R) Gold 6334 CPU @ 3.60GHz and 128GB RAM > > - SMP Kernel (default) > > - X710 NIC (ixl) 2 nics with 2 ports each > > - BGPd crashes with "panic: malloc: out of space in kmem_map" (please see > screenshot). > > - When launching 'bgpd -dv' on the console, logs are showing: > > send_rtmsg: action 1, prefix 179.62.148.0/24: No buffer space available > send_rtmsg: action 1, prefix 176.59.72.0/23: No buffer space available > send_rtmsg: action 1, prefix 176.59.70.0/23: No buffer space available > send_rtmsg: action 1, prefix 176.59.74.0/23: No buffer space available > send_rtmsg: action 1, prefix 185.78.92.0/22: No buffer space available > send_rtmsg: action 1, prefix 176.59.64.0/23: No buffer space available > send_rtmsg: action 1, prefix 176.59.66.0/23: No buffer space available > > . > > send_rtmsg: action 1, prefix 31.132.21.0/24: No buffer space available > send_rtmsg: action 1, prefix 38.94.167.0/24: No buffer space available > > then the machine crashes after having processed a few thousands prefixes. > > When using the SP (boot /bsd.sp) kernel, the issue doesn't arise. > > Do you have any pointer to solve this issue ? Please send vmstat -m output of the affected machine. The problem is probably the multiqueue support in ixl(4) that consumes too much memory. -- :wq Claudio
OpenBSD SMP - BGPd - send_rtmsg: action 1, prefix A.B.C.D/24: No buffer space available - panic: malloc: out of space in kmem_map
Hi, I'm currently migrating a BGPd server. Specs of "old" machine: - Dell R720 with Intel(R) Xeon(R) CPU E5-2637 v2and 16GB RAM - SMP Kernel (default) - BGPd runs fine with 5 full views - X710 NIC (ixl) 4 port interface Specs of "new" machine: - Dell R750xs with Intel(R) Xeon(R) Gold 6334 CPU @ 3.60GHz and 128GB RAM - SMP Kernel (default) - X710 NIC (ixl) 2 nics with 2 ports each - BGPd crashes with "panic: malloc: out of space in kmem_map" (please see screenshot). - When launching 'bgpd -dv' on the console, logs are showing: send_rtmsg: action 1, prefix 179.62.148.0/24: No buffer space available send_rtmsg: action 1, prefix 176.59.72.0/23: No buffer space available send_rtmsg: action 1, prefix 176.59.70.0/23: No buffer space available send_rtmsg: action 1, prefix 176.59.74.0/23: No buffer space available send_rtmsg: action 1, prefix 185.78.92.0/22: No buffer space available send_rtmsg: action 1, prefix 176.59.64.0/23: No buffer space available send_rtmsg: action 1, prefix 176.59.66.0/23: No buffer space available . send_rtmsg: action 1, prefix 31.132.21.0/24: No buffer space available send_rtmsg: action 1, prefix 38.94.167.0/24: No buffer space available then the machine crashes after having processed a few thousands prefixes. When using the SP (boot /bsd.sp) kernel, the issue doesn't arise. Do you have any pointer to solve this issue ? Thanks
(Tina Turner) Scrumbled sectors playing dvd
Hello, 7.4 Talking about medium, I just mounted a dvd of Tina Turner: wiz# mount -t cd9660 /dev/cd0a /mnt/cdrom And I understand OpenBSD could eventually get a little wired but not like from screenshot attached.. I'm trying to playing it with Parole.. == Nowarez Market
Re: OpenBSD alternative setup to ZFS on Linux or FreeBSD
On 2023/11/26 11:36, Crystal Kolipe wrote: > On Sun, Nov 26, 2023 at 01:52:22PM -, Stuart Henderson wrote: > > On 2023-11-24, Crystal Kolipe wrote: > > > At the end of last year, I did a comprehensive write-up about using > > > blu-ray > > > recordable on OpenBSD, and as part of that I checked around 100 BD-R discs > > > that had been written about 10 years previously and verified as good at > > > the > > > time. Ten years laster, I found exactly ZERO bad discs. All data was > > > readable from every single disc, (and returned the correct checksums). > > > > Anyone know whether USB BD-R drives are likely to work on OpenBSD? > > From a software point of view you are just writing to the /dev/rcd* device, so > any standards-compliant USB BD-R drive should work. > > Like any USB peripherals, there are probably some stupid ones that don't or > would require tweaks to the kernel to be recognised, etc. > > Having said that, for maximum reliable operation you need a sustained data > rate up to ~50 Mb/sec, and I wouldn't entirely trust USB for that. > > Any reason why you particularly want a USB one? If I wanted a reliable > external BD-R drive that I could move between machines, I'd probably put one > of the Pioneer ones in an external eSATA enclosure. I don't think I have any hardware with eSATA (and most of my boxes are either laptops or mini PCs - I think there's only one machine where I could add a card with eSATA). > The one Asus drive I tested had a few quirks, BTW, so I wouldn't be > inclined to invest in one of those. Thanks for the hints.
Re: FAT names exceeding spec length
There is also some ironic stuff behind these happenings: if you have the possibility to check your lost long file names you will discover that the most significant information are contained in the first 99 chars. Nowarez Market wrote: > > Clearly the problem is that from the user prospective in these kind > of events all the information contained in the longer file names are > lost. > > A file copy from Android is always completely transparent to the user, > anyhow. Android open behavior "doesn't help" copping with these long > names: if I copy files from an Android tablet and only after some > days I retrieve them..information are lost in OpenBSD. > > > Nowarez Market wrote: > > > I have a fat32 usb stick that I use to transfer files > > from/to my Android tablet since years. > > > > I just want to drop the hint that Android manage > > to render the file names exceeding 255 chars offering > > the user the long form anyway while OpenBSD strictly > > apply the FAT specs rendering these file names > > in the 8 chars format. > >
Re: FAT names exceeding spec length
Clearly the problem is that from the user prospective in these kind of events all the information contained in the longer file names are lost. A file copy from Android is always completely transparent to the user, anyhow. Android open behavior "doesn't help" copping with these long names: if I copy files from an Android tablet and only after some days I retrieve them..information are lost in OpenBSD. Nowarez Market wrote: > I have a fat32 usb stick that I use to transfer files > from/to my Android tablet since years. > > I just want to drop the hint that Android manage > to render the file names exceeding 255 chars offering > the user the long form anyway while OpenBSD strictly > apply the FAT specs rendering these file names > in the 8 chars format.
FAT names exceeding spec length
Hello, I have a fat32 usb stick that I use to transfer files from/to my Android tablet since years. I just want to drop the hint that Android manage to render the file names exceeding 255 chars offering the user the long form anyway while OpenBSD strictly apply the FAT specs rendering these file names in the 8 chars format. == Daniele Bonini
