Re: dhcpleased restricted
gwes wrote: > On 7/16/21 10:35 PM, Theo de Raadt wrote: > > This is intentional. > > > > We are moving from a model where dhclient on 1 interface believes it is > > MASTER of /etc/resolv.conf and a bunch of system aspects, and the > > userbase is familiar with a pile of hacky control knobs in > > dhclient.conf. > > > > Towards a model where multiple interfaces + unwind can advertise their > > DNS resolution abilities to resolvd, which then sorts the offers and > > maintains a configuration. > > > > dhclient will remain available for people who want that old model, but I > > suspect they will encounter increasing difficulty sticking to it. > > > > Because the default configuration is changing. > > > > > dhcpleased inspects all interfaces Bullshit. > dhclient only works with assigned interfaces > There are times when one interface configured by dhcp must be supervised > but other interfaces must not be disturbed >>despite any flags<<, > e.g. during > a reconfiguration, testing, switchover, etc. > Will there be a way to confine dhcpleased to a defined set of interfaces? dhcpleased only works on interfaces configured "inet autoconf". dhcpleased is a dynamic host configuration protocol (DHCP) daemon for clients. It requests IP configuration information from for example those offered by dhcpd(8), on interfaces with the AUTOCONF4 flag set. ^^ Is there a way to confine slaacd to a defined set of interfaces? Yes. Exactly the same way. slaacd is a stateless address autoconfiguration (SLAAC) daemon for clients. It listens for IPv6 router advertisement messages, for example those sent by rad(8), on interfaces with the AUTOCONF6 flag set.
dhcpleased restricted
On 7/16/21 10:35 PM, Theo de Raadt wrote: This is intentional. We are moving from a model where dhclient on 1 interface believes it is MASTER of /etc/resolv.conf and a bunch of system aspects, and the userbase is familiar with a pile of hacky control knobs in dhclient.conf. Towards a model where multiple interfaces + unwind can advertise their DNS resolution abilities to resolvd, which then sorts the offers and maintains a configuration. dhclient will remain available for people who want that old model, but I suspect they will encounter increasing difficulty sticking to it. Because the default configuration is changing. dhcpleased inspects all interfaces dhclient only works with assigned interfaces There are times when one interface configured by dhcp must be supervised but other interfaces must not be disturbed >>despite any flags<<, e.g. during a reconfiguration, testing, switchover, etc. Will there be a way to confine dhcpleased to a defined set of interfaces? thanks Geoff Steckel
Re: dhcp issues
On Fri, Jul 16, 2021 at 09:57:21PM -0400, Sonic wrote: > Having some issues after a sysupgrade to the latest snapshot (of this > writing) - OpenBSD 6.9-current (GENERIC.MP) #131. > > Seems the base change to dhcpleased/resolvd has presented some issues. > Pf does not start on boot as it claims my dhcp interface has no > address, however after logging in I can load pf and almost resume > normal operations. Apparently the interface does get an IP address, > but the start of pf doesn't wait for it. as deraadt@ said, without pf.conf it is hard to judge... could you share your pf.conf ? > Almost, because my supersedes, etc. in /etc/dhclient.conf are > completely ignored. which supersedes do you use ? sharing your dhclient.conf might help too. > The only workaround I found was to disable resolvd so I could manually > propagate /etc/resolv.conf without it being overwritten. resolvd doesn't override resolv.conf. it only prepends nameserver lines obtained from dhcpleased (via dhcpv4) or slaacd (via stateless ipv6). could you share your expected resolv.conf and the "overrided" one ? thanks. -- Sebastien Marie
Re: dhcp issues
Sonic wrote: > Having some issues after a sysupgrade to the latest snapshot (of this > writing) - OpenBSD 6.9-current (GENERIC.MP) #131. > > Seems the base change to dhcpleased/resolvd has presented some issues. This is intentional. We are moving from a model where dhclient on 1 interface believes it is MASTER of /etc/resolv.conf and a bunch of system aspects, and the userbase is familiar with a pile of hacky control knobs in dhclient.conf. Towards a model where multiple interfaces + unwind can advertise their DNS resolution abilities to resolvd, which then sorts the offers and maintains a configuration. dhclient will remain available for people who want that old model, but I suspect they will encounter increasing difficulty sticking to it. Because the default configuration is changing. > Pf does not start on boot as it claims my dhcp interface has no > address, however after logging in I can load pf and almost resume > normal operations. Apparently the interface does get an IP address, > but the start of pf doesn't wait for it. You didn't include any pieces of your pf.conf to show, so who can judge? Anyways I'll let other people you didn't show your config to explain how you are probably using pf incorrectly on interfaces configured with dynamic addressing. > Almost, because my supersedes, etc. in /etc/dhclient.conf are > completely ignored. Of course. > The only workaround I found was to disable resolvd so I could manually > propagate /etc/resolv.conf without it being overwritten. We take no position on what people do after they install openbsd...
Re: `jq` won't chroot?
Thanks Theo! > It seems you copied libjq and libonig into usr/local/lib in the chroot. > By default, ld.so only looks for shared objects in /usr/lib, so it can't > find them. > > # env LD_LIBRARY_PATH=/usr/lib:/usr/local/lib chroot /var/www > /usr/local/bin/jq --version > > should work. Indeed it did. Shorter: env LD_LIBRARY_PATH='/usr/local/lib:$LD_LIBRARY_PATH' /usr/local/bin/jq --version > Chrooting to / works because rc(8) runs ldconfig(8) to add > /usr/local/lib and /usr/X11R6/lib if they're present. > > You can copy all the libraries into /var/www/usr/lib, you can set > LD_LIBRARY_PATH=/usr/local/lib:/usr/, or you can run ldconfig in the > chroot. > > Read ld.so(1) and ldconfig(8)for more details. Yes, setting `ldconfig -n /usr/local/lib` is a more sticky option. The `env` approach seems best when just one `jq` command, whereas the `ldconfig` approach seems better when there is more than one `jq` command... Thanks! K.
dhcp issues
Having some issues after a sysupgrade to the latest snapshot (of this writing) - OpenBSD 6.9-current (GENERIC.MP) #131. Seems the base change to dhcpleased/resolvd has presented some issues. Pf does not start on boot as it claims my dhcp interface has no address, however after logging in I can load pf and almost resume normal operations. Apparently the interface does get an IP address, but the start of pf doesn't wait for it. Almost, because my supersedes, etc. in /etc/dhclient.conf are completely ignored. The only workaround I found was to disable resolvd so I could manually propagate /etc/resolv.conf without it being overwritten.
Re: `jq` won't chroot?
On Fri, Jul 16, 2021 at 10:24:10PM +, Kent Watsen wrote: > I’ve spent a few hours on this and am lost. I have plenty experience moving > executables into a chroot environments, but `jq` is proving to be > exceptionally difficult. > > The executable is found when chrooted to ‘/‘ but not ' /var/www’. Yes, of > course I copied all the files referenced from `ldd` into the chroot, and set > their file permissions to 777 (and likewise all the parent directories): > > # pkg_add jq > > # chroot / /usr/local/bin/jq --version > jq-1.6 > > *** COPY `ldd /usr/local/bin/jq` DEPENDENCIES INTO /var/www/ HERE *** > > # chroot /var/www /usr/local/bin/jq --version > ld.so: jq: can't load library 'libonig.so.7.1’ > > > Any ideas? It seems you copied libjq and libonig into usr/local/lib in the chroot. By default, ld.so only looks for shared objects in /usr/lib, so it can't find them. # env LD_LIBRARY_PATH=/usr/lib:/usr/local/lib chroot /var/www /usr/local/bin/jq --version should work. Chrooting to / works because rc(8) runs ldconfig(8) to add /usr/local/lib and /usr/X11R6/lib if they're present. You can copy all the libraries into /var/www/usr/lib, you can set LD_LIBRARY_PATH=/usr/local/lib:/usr/, or you can run ldconfig in the chroot. Read ld.so(1) and ldconfig(8) for more details.
Re: `jq` won't chroot?
Easy button for putting all the dependency files into the chroot:
# for f in `ldd /usr/local/bin/jq | grep '0' | awk '{print $7}'`; do
d=`dirname $f | sed 's#^/##’`
mkdir -p /var/www/$d
cp $f /var/www/$d/
done
K.
> On Jul 16, 2021, at 6:24 PM, Kent Watsen wrote:
>
> I’ve spent a few hours on this and am lost. I have plenty experience moving
> executables into a chroot environments, but `jq` is proving to be
> exceptionally difficult.
>
> The executable is found when chrooted to ‘/‘ but not ' /var/www’. Yes, of
> course I copied all the files referenced from `ldd` into the chroot, and set
> their file permissions to 777 (and likewise all the parent directories):
>
> # pkg_add jq
>
> # chroot / /usr/local/bin/jq --version
> jq-1.6
>
> *** COPY `ldd /usr/local/bin/jq` DEPENDENCIES INTO /var/www/ HERE ***
>
> # chroot /var/www /usr/local/bin/jq --version
> ld.so: jq: can't load library 'libonig.so.7.1’
> Killed
>
> Any ideas?
>
> K.
>
Re: Intel 10Gb card (82598AF) on 6.9 release
On Fri, Jul 16, 2021 at 05:14:49PM -0400, Adam Stouffer wrote:
> I'm having difficulty getting an Intel 10Gb ethernet card recognized
> on 6.9. The card is recognized by the ix driver but this error shows
> up in dmesg:
>
> ix0 at pci1 dev 0 function 0 "Intel 82598AF" rev
> 0x01ixgbe_allocate_msix: pci_intr_map_msix vec 0 failed
I think the problem here is that we don't check if msi is enabled
before deciding we can use msix. Can you try this diff out?
I wrote this after seeing a similar report somewhere, but I can't find
it now.
Index: pci.c
===
RCS file: /cvs/src/sys/dev/pci/pci.c,v
retrieving revision 1.119
diff -u -p -r1.119 pci.c
--- pci.c 8 Sep 2020 20:13:52 - 1.119
+++ pci.c 22 Jun 2021 02:55:50 -
@@ -410,16 +410,48 @@ pcisubmatch(struct device *parent, void
}
int
+pci_device_msi_enabled(pci_chipset_tag_t pc, pcitag_t tag)
+{
+ int off;
+ pcireg_t cap;
+ uint64_t addr;
+
+ if (pci_get_ht_capability(pc, tag, PCI_HT_CAP_MSI, , )) {
+ /*
+* XXX Should we enable MSI mapping ourselves on
+* systems that have it disabled?
+*/
+ if (cap & PCI_HT_MSI_ENABLED) {
+ if ((cap & PCI_HT_MSI_FIXED) == 0) {
+ addr = pci_conf_read(pc, tag,
+ off + PCI_HT_MSI_ADDR);
+ addr |= (uint64_t)pci_conf_read(pc, tag,
+ off + PCI_HT_MSI_ADDR_HI32) << 32;
+ } else
+ addr = PCI_HT_MSI_FIXED_ADDR;
+
+ /*
+* XXX This will fail to enable MSI on systems
+* that don't use the canonical address.
+*/
+ if (addr == PCI_HT_MSI_FIXED_ADDR)
+ return (1);
+ }
+ }
+
+ return (0);
+}
+
+int
pci_probe_device(struct pci_softc *sc, pcitag_t tag,
int (*match)(struct pci_attach_args *), struct pci_attach_args *pap)
{
pci_chipset_tag_t pc = sc->sc_pc;
struct pci_attach_args pa;
struct pci_dev *pd;
- pcireg_t id, class, intr, bhlcr, cap;
+ pcireg_t id, class, intr, bhlcr;
int pin, bus, device, function;
- int off, ret = 0;
- uint64_t addr;
+ int ret = 0;
pci_decompose_tag(pc, tag, , , );
@@ -486,28 +518,8 @@ pci_probe_device(struct pci_softc *sc, p
}
pa.pa_intrline = PCI_INTERRUPT_LINE(intr);
- if (pci_get_ht_capability(pc, tag, PCI_HT_CAP_MSI, , )) {
- /*
-* XXX Should we enable MSI mapping ourselves on
-* systems that have it disabled?
-*/
- if (cap & PCI_HT_MSI_ENABLED) {
- if ((cap & PCI_HT_MSI_FIXED) == 0) {
- addr = pci_conf_read(pc, tag,
- off + PCI_HT_MSI_ADDR);
- addr |= (uint64_t)pci_conf_read(pc, tag,
- off + PCI_HT_MSI_ADDR_HI32) << 32;
- } else
- addr = PCI_HT_MSI_FIXED_ADDR;
-
- /*
-* XXX This will fail to enable MSI on systems
-* that don't use the canonical address.
-*/
- if (addr == PCI_HT_MSI_FIXED_ADDR)
- pa.pa_flags |= PCI_FLAGS_MSI_ENABLED;
- }
- }
+ if (pci_device_msi_enabled(pc, tag))
+ pa.pa_flags |= PCI_FLAGS_MSI_ENABLED;
/*
* Give the MD code a chance to alter pci_attach_args and/or
@@ -1697,6 +1709,9 @@ int
pci_intr_msix_count(pci_chipset_tag_t pc, pcitag_t tag)
{
pcireg_t reg;
+
+ if (pci_device_msi_enabled(pc, tag) == 0)
+ return (0);
if (pci_get_capability(pc, tag, PCI_CAP_MSIX, NULL, ) == 0)
return (0);
`jq` won't chroot?
I’ve spent a few hours on this and am lost. I have plenty experience moving executables into a chroot environments, but `jq` is proving to be exceptionally difficult. The executable is found when chrooted to ‘/‘ but not ' /var/www’. Yes, of course I copied all the files referenced from `ldd` into the chroot, and set their file permissions to 777 (and likewise all the parent directories): # pkg_add jq # chroot / /usr/local/bin/jq --version jq-1.6 *** COPY `ldd /usr/local/bin/jq` DEPENDENCIES INTO /var/www/ HERE *** # chroot /var/www /usr/local/bin/jq --version ld.so: jq: can't load library 'libonig.so.7.1’ Any ideas? K.
Unable to configure (and use) microphone via mixerctl.
I've found myself unable to use my laptop mic with my new OpenBSD install. Using mixerctl, I try to set values to use "mic" instead of "mic2" for inputs, but I am met with the error "mixerctl: Bad set value mic" in most cases. I have enabled the kern.audio.record sysctl and I am certain the built in microphone works as it's worked out of the box with alsa on various linux distros. Here is my mixerctl output: inputs.dac-2:3=174,174 inputs.dac-0:1=174,174 record.adc-0:1_mute=off record.adc-0:1=252,252 record.adc-4:5_mute=off record.adc-4:5=252,252 inputs.mix_source=mic2 inputs.mix_mic2=120,120 inputs.mix2_source=dac-2:3,mix inputs.mix3_source=dac-0:1,mix record.adc-2:3_source=mic record.adc-2:3_mute=off record.adc-2:3=252,252 inputs.mic=85,85 outputs.spkr_source=mix2 outputs.spkr_mute=on outputs.spkr_eapd=on inputs.mic2=85,85 outputs.mic2_dir=input-vr80 outputs.hp_source=mix3 outputs.hp_mute=off outputs.hp_boost=off outputs.hp_eapd=on record.adc-4:5_source=mic2,mix record.adc-0:1_source=mic2,mix outputs.mic2_sense=unplugged outputs.hp_sense=plugged outputs.spkr_muters=hp outputs.master=255,255 outputs.master.mute=off outputs.master.slaves=dac-2:3,dac-0:1,spkr,hp record.volume=255,255 record.volume.mute=off record.volume.slaves=adc-0:1,adc-4:5,adc-2:3 record.enable=sysctl ...And here is my dmesg output: OpenBSD 6.9 (GENERIC.MP) #473: Mon Apr 19 10:40:28 MDT 2021 dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MPreal mem = 4141572096 (3949MB)avail mem = 4000673792 (3815MB)random: good seed from bootblocksmpath0 at rootscsibus0 at mpath0: 256 targetsmainbus0 at rootbios0 at mainbus0: SMBIOS rev. 2.7 @ 0x78f06020 (15 entries)bios0: vendor coreboot version "MrChromebox" date 02/04/2018bios0: GOOGLE Auron_Yunaacpi0 at bios0: ACPI 4.0acpi0: sleep states S0 S1 S2 S3 S4 S5acpi0: tables DSDT FACP SSDT MCFG TCPA APIC HPET BGRTacpi0: wakeup devices HDEF(S3) WLAN(S3) EHCI(S3) XHCI(S3) LID0(S5) ETPA(S3)acpitimer0 at acpi0: 3579545 Hz, 24 bitsacpimcfg0 at acpi0acpimcfg0: addr 0xf000, bus 0-255acpimadt0 at acpi0 addr 0xfee0: PC-AT compatcpu0 at mainbus0: apid 0 (boot processor)cpu0: Intel(R) Celeron(R) CPU 3215U @ 1.70GHz, 1696.39 MHz, 06-3d-04cpu0: 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,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,XSAVE,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,ABM,3DNOWP,PERF,ITSC,FSGSBASE,TSC_ADJUST,ERMS,INVPCID,RDSEED,PT,SRBDS_CTRL,MD_CLEAR,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,MELTDOWNcpu0: 256KB 64b/line 8-way L2 cachecpu0: smt 0, core 0, package 0mtrr: Pentium Pro MTRR support, 10 var ranges, 88 fixed rangescpu0: apic clock running at 99MHzcpu0: mwait min=64, max=64, C-substates=0.2.1.2.4.1.1.1, IBEcpu1 at mainbus0: apid 2 (application processor)cpu1: Intel(R) Celeron(R) CPU 3215U @ 1.70GHz, 1696.09 MHz, 06-3d-04cpu1: 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,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,XSAVE,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,ABM,3DNOWP,PERF,ITSC,FSGSBASE,TSC_ADJUST,ERMS,INVPCID,RDSEED,PT,SRBDS_CTRL,MD_CLEAR,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,MELTDOWNcpu1: 256KB 64b/line 8-way L2 cachecpu1: smt 0, core 1, package 0ioapic0 at mainbus0: apid 2 pa 0xfec0, version 20, 40 pinsacpihpet0 at acpi0: 14318179 Hzacpiprt0 at acpi0: bus 0 (PCI0)acpiprt1 at acpi0: bus 1 (RP01)acpiprt2 at acpi0: bus -1 (RP02)acpiprt3 at acpi0: bus -1 (RP03)acpiprt4 at acpi0: bus -1 (RP04)acpiprt5 at acpi0: bus -1 (RP05)acpiprt6 at acpi0: bus -1 (RP06)acpiprt7 at acpi0: bus -1 (RP07)acpiprt8 at acpi0: bus -1 (RP08)acpiec0 at acpi0acpipci0 at acpi0 PCI0: 0x 0x0011 0x0001acpicmos0 at acpi0"INT3437" at acpi0 not configuredacpibtn0 at acpi0: LID0acpiac0 at acpi0: AC unit onlineacpibat0 at acpi0: BAT0 model "AC14B8K" serial B360 type LION oem "LGC""GOOG0004" at acpi0 not configured"PNP0A05" at acpi0 not configured"INTL9C60" at acpi0 not configureddwiic0 at acpi0 I2C0 addr 0xe1122000/0x1000 irq 7iic0 at dwiic0"ELAN" at iic0 addr 0x15 not configureddwiic1 at acpi0 I2C1 addr 0xe1124000/0x1000 irq 7iic1 at dwiic1acpibtn1 at acpi0: PWRB"PNP0C0B" at acpi0 not configured"PNP0C0B" at acpi0 not configured"BOOT" at acpi0 not configuredacpicpu0 at acpi0: C3(400@506 mwait.1@0x60), C2(700@148 mwait.1@0x33), C1(1000@0 mwait.1@0x1), PSSacpicpu1 at acpi0: C3(400@506 mwait.1@0x60), C2(700@148 mwait.1@0x33), C1(1000@0 mwait.1@0x1), PSSacpitz0 at acpi0: critical temperature is 104 degCacpipwrres0 at acpi0: TNP0, resource for TDP0acpipwrres1 at acpi0: TNP1, resource for TDP1acpivideo0 at acpi0: GFX0cpu0: using VERW MDS workaround (except on vmm entry)cpu0: Enhanced SpeedStep 1696 MHz: speeds: 1701, 1700, 1500, 1300, 1100,
Intel 10Gb card (82598AF) on 6.9 release
I'm having difficulty getting an Intel 10Gb ethernet card recognized on 6.9. The card is recognized by the ix driver but this error shows up in dmesg: ix0 at pci1 dev 0 function 0 "Intel 82598AF" rev 0x01ixgbe_allocate_msix: pci_intr_map_msix vec 0 failed The rest of dmesg: OpenBSD 6.9 (GENERIC.MP) #3: Mon Jun 7 08:21:26 MDT 2021 r...@syspatch-69-amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP real mem = 6341455872 (6047MB) avail mem = 6133891072 (5849MB) random: good seed from bootblocks mpath0 at root scsibus0 at mpath0: 256 targets mainbus0 at root bios0 at mainbus0: SMBIOS rev. 2.5 @ 0xea0c0 (74 entries) bios0: vendor Hewlett-Packard version "786F1 v01.35" date 10/23/2015 bios0: Hewlett-Packard HP Compaq dc7800 Small Form Factor acpi0 at bios0: ACPI 1.0 acpi0: sleep states S0 S3 S4 S5 acpi0: tables DSDT FACP APIC ASF! MCFG TCPA SLIC HPET DMAR acpi0: wakeup devices PCI0(S4) COM1(S4) PEG1(S4) PEG2(S4) IGBE(S4) PCX1(S4) PCX2(S4) PCX5(S4) PCX6(S4) HUB_(S4) USB1(S3) USB2(S3) USB3(S3) USB4(S3) USB5(S3) USB6(S3) [...] 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)2 Duo CPU E8400 @ 3.00GHz, 2992.96 MHz, 06-17-06 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,VMX,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,SSE4.1,NXE,LONG,LAHF,PERF,SENSOR,MELTDOWN cpu0: 6MB 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 332MHz cpu0: mwait min=64, max=64, C-substates=0.2.2.2.2, IBE cpu1 at mainbus0: apid 1 (application processor) cpu1: Intel(R) Core(TM)2 Duo CPU E8400 @ 3.00GHz, 2992.51 MHz, 06-17-06 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,VMX,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,SSE4.1,NXE,LONG,LAHF,PERF,SENSOR,MELTDOWN cpu1: 6MB 64b/line 16-way L2 cache cpu1: smt 0, core 1, package 0 ioapic0 at mainbus0: apid 1 pa 0xfec0, version 20, 24 pins, remapped acpimcfg0 at acpi0 acpimcfg0: addr 0xf400, bus 0-63 acpihpet0 at acpi0: 14318179 Hz acpiprt0 at acpi0: bus 0 (PCI0) acpiprt1 at acpi0: bus 1 (PEG1) acpiprt2 at acpi0: bus -1 (PEG2) acpiprt3 at acpi0: bus 32 (PCX1) acpiprt4 at acpi0: bus 48 (PCX2) acpiprt5 at acpi0: bus -1 (PCX5) acpiprt6 at acpi0: bus -1 (PCX6) acpiprt7 at acpi0: bus 7 (HUB_) acpipci0 at acpi0 PCI0: 0x 0x0011 0x0001 acpicmos0 at acpi0 "PNP0003" at acpi0 not configured tpm0 at acpi0 TPM_ addr 0x4e/0x2, device 0x rev 0xff acpibtn0 at acpi0: PBTN "PNP0C14" at acpi0 not configured acpicpu0 at acpi0: !C2(750@40 io@0xf814), C1(1000@20 halt), PSS acpicpu1 at acpi0: !C2(750@40 io@0xf814), C1(1000@20 halt), PSS cpu0: Enhanced SpeedStep 2992 MHz: speeds: 3000, 1998 MHz pci0 at mainbus0 bus 0 pchb0 at pci0 dev 0 function 0 "Intel 82Q35 Host" rev 0x02 ppb0 at pci0 dev 1 function 0 "Intel 82Q35 PCIE" rev 0x02: apic 1 int 16 pci1 at ppb0 bus 1 em0 at pci1 dev 0 function 0 "Intel 82571EB" rev 0x06: apic 1 int 16, address 00:14:5e:76:e2:48 inteldrm0 at pci0 dev 2 function 0 "Intel 82Q35 Video" rev 0x02 drm0 at inteldrm0 intagp0 at inteldrm0 agp0 at intagp0: aperture at 0xe000, size 0x1000 inteldrm0: apic 1 int 16, G33, gen 3 "Intel 82Q35 HECI" rev 0x02 at pci0 dev 3 function 0 not configured pciide0 at pci0 dev 3 function 2 "Intel 82Q35 PT IDER" rev 0x02: DMA (unsupported), channel 0 wired to native-PCI, channel 1 wired to native-PCI pciide0: using apic 1 int 18 for native-PCI interrupt pciide0: channel 0 ignored (not responding; disabled or no drives?) pciide0: channel 1 ignored (not responding; disabled or no drives?) puc0 at pci0 dev 3 function 3 "Intel 82Q35 KT" rev 0x02: ports: 16 com com4 at puc0 port 0 apic 1 int 17: ns16550a, 16 byte fifo com4: probed fifo depth: 0 bytes em2 at pci0 dev 25 function 0 "Intel ICH9 IGP AMT" rev 0x02: apic 1 int 19, address 00:1f:29:d3:dc:76 uhci0 at pci0 dev 26 function 0 "Intel 82801I USB" rev 0x02: apic 1 int 20 uhci1 at pci0 dev 26 function 1 "Intel 82801I USB" rev 0x02: apic 1 int 21 uhci2 at pci0 dev 26 function 2 "Intel 82801I USB" rev 0x02: apic 1 int 22 ehci0 at pci0 dev 26 function 7 "Intel 82801I USB" rev 0x02: apic 1 int 22 usb0 at ehci0: USB revision 2.0 uhub0 at usb0 configuration 1 interface 0 "Intel EHCI root hub" rev 2.00/1.00 addr 1 azalia0 at pci0 dev 27 function 0 "Intel 82801I HD Audio" rev 0x02: apic 1 int 21 azalia0: codecs: Analog Devices AD1884 audio0 at azalia0 ppb1 at pci0 dev 28 function 0 "Intel 82801I PCIE" rev 0x02 pci2 at ppb1 bus 32 ppb2 at pci0 dev 28 function 1 "Intel 82801I PCIE" rev 0x02: apic 1 int 21 pci3 at ppb2 bus 48 uhci3 at pci0 dev 29 function 0 "Intel 82801I USB" rev 0x02: apic 1 int 20 uhci4 at pci0 dev 29 function 1 "Intel 82801I USB" rev 0x02: apic 1 int 21 ehci1 at pci0 dev 29
Re: groups new
Hi Stefan, committed! While committing, i added the missing "P Baden" because it appears we sort the German groups alphabetically by Land. Some might regard the following as typical ;-) for Germany: This Group is not just an informal group (like, for example, the OpenBSD project itself is), but a formal, legal entity in the form of a registered association according to the German civil law (BGB) officially registered with the district court. The group has formal, written bylaws, a board, chairman, CFO, and cash auditors, formal membership (including membership fees), formal annual members' meetings discussing stuff like elections, budget discharges and so on and so forth... :-o But don't worry, *anybody* can participate in all activities without being required to become a member, and without having to participate in any of the formalities. Yours, Ingo P.S. And no, it a totally unfounded rumour and a vicious lie that naddy@ was nominated for CFO during the last annual members' meetings on May 7, 2021. I just invented that out of thin air! Stefan Hagen wrote on Fri, Jul 16, 2021 at 12:22:55PM +0200: > 0 > C Germany > P > T Heidelberg > F 1st Friday and 3rd Monday each month at 7:00PM > O Unix User Group Rhein-Neckar (UUGRN) > I Stefan Hagen > M s...@uugrn.org > U https://uugrn.org > N *BSD
Re: Should 80MB of RAM be enough for kernel relinking on i386?
> Your swap is only 256MB. That seem too low. (We have walked away > from making it correspond to physical memory, but still, it seems > uncomfortably low). > > As well, /usr seems a bit large, leaving not much for /home. > > The autoallocation scheme might have made a less than perfect > decision here. I tried the same thing except for editing the partition layout to allow for 512M of swap: wd1*> p m OpenBSD area: 64-15662304; size: 7647.6M; free: 955.0M #size offset fstype [fsize bsize cpg] a: 1060.6M 64 4.2BSD 2048 16384 1 # / b: 512.0M 2172128swap c: 7647.6M0 unused d: 3072.0M 3220704 4.2BSD 2048 16384 1 # /usr e: 2048.0M 9512128 4.2BSD 2048 16384 1 # /home and 768M: wd1*> p m OpenBSD area: 64-15662304; size: 7647.6M; free: 699.0M #size offset fstype [fsize bsize cpg] a: 1060.6M 64 4.2BSD 2048 16384 1 # / b: 768.0M 2172128swap c: 7647.6M0 unused d: 3072.0M 3744992 4.2BSD 2048 16384 1 # /usr e: 2048.0M 10036416 4.2BSD 2048 16384 1 # /home ...and there's no practical difference, the system will just sit for half an hour, print one or two seg faults in that time and then reboot. memtest86 didn't print any errors so I'm assuming my memory is fine. I'd say x86 computers without INT 13h Extensions support in the BIOS are pretty much obsolete at this point given that nearly all of them are going to be a combo of very small memory (>128MB was very rare before 1998) and small disk (8.4GB limit).
Re: Should 80MB of RAM be enough for kernel relinking on i386?
On Thu, Jul 15, 2021 at 08:48:54AM -0600, Theo de Raadt wrote:
> Otto Moerbeek wrote:
>
> > On Wed, Jul 14, 2021 at 05:28:06PM -0600, Theo de Raadt wrote:
> >
> > > The problem appears to be here:
> > >
> > > > wdc2 at pcmcia0 function 0 "TRANSCEND, TS8GCF133, " port 0x340/16: irq 3
> > > > wd1 at wdc2 channel 0 drive 0:
> > > > wd1: 1-sector PIO, LBA48, 7647MB, 15662304 sectors
> > > > wd1(wdc2:0:0): using BIOS timings
> > >
> > > > a: 1060.6M 64 4.2BSD 2048 16384 1 # /
> > > > b: 256.0M 2172128swap
> > > > c: 7647.6M0 unused
> > > > d: 3072.0M 2696416 4.2BSD 2048 16384 1 # /usr
> > > > e: 2048.0M 8987872 4.2BSD 2048 16384 1 #
> > > > /home
> > >
> > > Your swap is only 256MB. That seem too low. (We have walked away from
> > > making it correspond to physical memory, but still, it seems
> > > uncomfortably low).
> > >
> > > As well, /usr seems a bit large, leaving not much for /home.
> > >
> > > The autoallocation scheme might have made a less than perfect decision
> > > here.
> > >
> >
> > Thhis is bassed on the "medium" allocation, swap, /usr and /home have
> > reached there max according to the table. We can make swap have a
> > alrager max and take more of the pie. What would be a good max size
> > for swap these days omn such a small disk?
>
> I suspect, but don't know, that 400MB would be enough for the link.
So how aboht this? allocate a bit more to swap and increase the max,
plus increase the max for /home.
Index: editor.c
===
RCS file: /cvs/src/sbin/disklabel/editor.c,v
retrieving revision 1.368
diff -u -p -r1.368 editor.c
--- editor.c30 May 2021 19:02:30 - 1.368
+++ editor.c16 Jul 2021 12:14:27 -
@@ -103,9 +103,9 @@ struct space_allocation alloc_big[] = {
struct space_allocation alloc_medium[] = {
{ MEG(800), GIG(2), 5, "/" },
- { MEG(80), MEG(256), 10, "swap"},
- { MEG(1300), GIG(3), 78, "/usr"},
- { MEG(256), GIG(2), 7, "/home" }
+ { MEG(80), MEG(512), 20, "swap"},
+ { MEG(1300), GIG(3), 68, "/usr"},
+ { MEG(256), GIG(3), 7, "/home" }
};
struct space_allocation alloc_small[] = {
This produces:
vnd0*> p g
OpenBSD area: 0-15662305; size: 7.5G; free: 0.0G
#size offset fstype [fsize bsize cpg]
a: 1.0G0 4.2BSD 2048 16384 1 # /
b: 0.5G 2172064swap
c: 7.5G0 unused
d: 3.0G 3220640 4.2BSD 2048 16384 1 # /usr
e: 2.9G 9512096 4.2BSD 2048 16384 1 # /home
-Otto
Re: groups new
Ingo Schwarze wrote: > Hi Stefan, > > Stefan Hagen wrote on Fri, Jul 16, 2021 at 12:22:55PM +0200: > >> U https://uugrn.org > > i suspect that your web server is misconfigured; at least for me, > it appears to redirect to itself: > > $ w3m -dump_source https://uugrn.org > Redirection loop detected (https://uugrn.org/) > > Could you please check? Whoops! It was indeed an issue. Fixed now. Best Regards, Stefan
Re: groups new
Hi Stefan, Stefan Hagen wrote on Fri, Jul 16, 2021 at 12:22:55PM +0200: > U https://uugrn.org i suspect that your web server is misconfigured; at least for me, it appears to redirect to itself: $ w3m -dump_source https://uugrn.org Redirection loop detected (https://uugrn.org/) 302 Found [...] 302 Found OpenBSD httpd Could you please check? Yours, Ingo
Re: new support
Thanks a lot. Regards, Robert W dniu 16.07.2021 o 12:08, Ingo Schwarze pisze: Hi Robert, nice to have a service provider in Poland, too. :-) Committed; it will show up on the OpenBSD site with a short delay. Yours, Ingo bi...@apisoft.pl wrote on Thu, Jul 15, 2021 at 04:26:56PM +0200: 0 C Poland P mazowieckie T Radom Z 26-600 O APISOFT Sp. z o.o. I Robert Zajda A Wiejska 58a/25 M bi...@apisoft.pl U https://www.apisoft.pl/ B +48 503 146 490 X N Linux/BSD consulting, installation, maintenance and support services. Secure servers, VPN, firewalls, OpenBSD-based Web Hosting. 15 years of experience. -- APISOFT Sp. z o.o. ul. Wiejska 58A/25, 26-600 RADOM II piętro, pok. 25 www.apisoft.pl kom. +48 503-146-490 tel. +48 48 380-88-88 +48 48 380-88-89 fax. +48 48 380-88-90 APISOFT Sp. z o.o. z siedzibą w Radomiu, ul. Wiejska 58a lok. 25, wpisana do rejestru przedsiębiorców Krajowego Rejestru Sądowego prowadzonego przez Sąd Rejonowy Lublin-Wschód w Lublinie z siedzibą w Świdniku VI Wydział Gospodarczy Krajowego Rejestru Sądowego, pod numerem KRS 751035, kapitał zakładowy wynosi 1 zł. Jeżeli otrzymuje Pan/Pani od nas wiadomość, oznacza to, że przetwarzamy Pana/Pani dane osobowe co najmniej w tym zakresie. Jesteśmy administratorem tych danych osobowych. Są one przetwarzane w sposób zgodny z prawem i z poszanowaniem wszelkich uprawnień przyznanych osobom których dane dotyczą przez obowiązujące przepisy (np. prawo do wycofania zgody, sprzeciwu, ograniczenia przetwarzania, dostępu, sprostowania, wniesienia skargi i innych). Dane przetwarzamy co do zasady tylko w celu w jaki zostały nam przekazane. Nie przekazujemy danych podmiotom zewnętrznym, nie sprzedajemy baz danych, nie robimy z danymi nic czego byście Państwo od nas nie oczekiwali. Przy rozpoczęciu przetwarzania Waszych danych osobowych powinniście Państwo zostać poinformowani o szczegółach tego procesu. Informację na ten temat można jednak zawsze uzyskać w naszej polityce bezpieczeństwa dostępnej na naszej stronie internetowej lub poprzez kontakt z nami.
groups new
0 C Germany P T Heidelberg F 1st Friday and 3rd Monday each month at 7:00PM O Unix User Group Rhein-Neckar (UUGRN) I Stefan Hagen M s...@uugrn.org U https://uugrn.org N *BSD
Re: new support
Hi Robert, nice to have a service provider in Poland, too. :-) Committed; it will show up on the OpenBSD site with a short delay. Yours, Ingo bi...@apisoft.pl wrote on Thu, Jul 15, 2021 at 04:26:56PM +0200: > 0 > C Poland > P mazowieckie > T Radom > Z 26-600 > O APISOFT Sp. z o.o. > I Robert Zajda > A Wiejska 58a/25 > M bi...@apisoft.pl > U https://www.apisoft.pl/ > B +48 503 146 490 > X > N Linux/BSD consulting, installation, maintenance and support services. > Secure servers, VPN, firewalls, OpenBSD-based Web Hosting. > 15 years of experience.
Re: style.9 typos
Hi Claudio and Todd,
Todd C. Miller wrote on Thu, Jul 15, 2021 at 02:01:23PM -0600:
> You are expected to know that ^I (control-I) is the tab character.
> Using ^I instead of a literal tab character in the manual was
> supposed to make it clear that this is a tab and not a series of
> spaces but maybe it is not so obvious...
You aren't even expected to know; "I" being the ninth letter of the
alphabet, hence ^I = 0x09 = ht not necessarily being obvious is the
reason why the manual page already explains it explicitely, it
says:
Put a tab after the first word, i.e., use `int^Ix;'
and `struct^Ifoo *x;'.
So i think the OP's patch is wrong.
It is also wrong because using a literal tab character in roff(7)
input in filled mode is discouraged roff(7) syntax:
$ printf 'foo\tbar' | mandoc -Tlint
mandoc: :1:4: WARNING: tab in filled text
$ man mandoc
[...]
DIAGNOSTICS
[...]
tab in filled text
(mdoc, man) The meaning of tab characters is only well-defined in non-
fill mode: In fill mode, whitespace is not supposed to be significant on
text input lines. As an implementation dependent choice, tab characters
on text lines are passed through to the formatters in any case. Given
that the text before the tab character will be filled, it is hard to
predict which tab stop position the tab will advance to.
So to use "intx", that string would have to be set in
unfilled mode. And exactly that is already there, right below:
struct foo {
struct foo *next; /* List of active foo */
struct mumble amumble; /* Comment for mumble */
int bar;
};
That struct display does contain literal tabs in the mdoc(7) source
code, as indeed it should.
Yes, tabs versus spaces is a royal PITA in Unix in general.
That long-standing source of confusion wasn't mitigated until
much later, when the Python programming language was invented.
Yours,
Ingo
