Re: system boot hang due to inteldrm(4)
On Tue, Oct 01, 2019 at 12:27:48AM +0200, Jan Klemkow wrote: > Hi, > > After updating my router to current, the systems hangs during the boot. > Maybe its caused by the "invalid EDID"?! The System boots up normaly > and doesn't hang, if I disable inteldrm(4) in UKC. > > Is this issue known? Or, witch additional debug information should I > provide to help fixing this bug? Building a kernel with 'option DRMDEBUG' will give more information. Is the machine hooked up to a kvm or monitor? What Lanner model is this? "gbXSo" doesn't help. > > Thanks, > Jan > > [ using 2744944 bytes of bsd ELF symbol table ] > Copyright (c) 1982, 1986, 1989, 1991, 1993 > The Regents of the University of California. All rights reserved. > Copyright (c) 1995-2019 OpenBSD. All rights reserved. https://www.OpenBSD.org > > OpenBSD 6.6-beta (GENERIC.MP) #328: Thu Sep 26 21:37:06 MDT 2019 > dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP > real mem = 2024398848 (1930MB) > avail mem = 1950400512 (1860MB) > mpath0 at root > scsibus0 at mpath0: 256 targets > mainbus0 at root > bios0 at mainbus0: SMBIOS rev. 2.8 @ 0xeca50 (49 entries) > bios0: vendor American Megatrends Inc. version "5.6.5" date 01/05/2017 > bios0: Lanner Electronics gbXSo > acpi0 at bios0: ACPI 5.0 > acpi0: sleep states S0 S4 S5 > acpi0: tables DSDT FACP APIC FPDT LPIT MCFG HPET SSDT SSDT SSDT UEFI > acpi0: wakeup devices EHC1(S4) PXSX(S4) PXSX(S4) PXSX(S4) PXSX(S4) PWRB(S0) > BRCM(S0) > 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) Celeron(R) CPU N2807 @ 1.58GHz, 1583.59 MHz, 06-37-08 > 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,SSE4.1,SSE4.2,MOVBE,POPCNT,DEADLINE,RDRAND,NXE,RDTSCP,LONG,LAHF,3DNOWP,PERF,ITSC,TSC_ADJUST,SMEP,ERMS,MD_CLEAR,IBRS,IBPB,STIBP,SENSOR,ARAT,MELTDOWN > cpu0: 1MB 64b/line 16-way L2 cache > tsc_timecounter_init: TSC skew=0 observed drift=0 > cpu0: smt 0, core 0, package 0 > mtrr: Pentium Pro MTRR support, 8 var ranges, 88 fixed ranges > cpu0: apic clock running at 83MHz > cpu0: mwait min=64, max=64, C-substates=0.2.0.0.0.0.3.3, IBE > cpu1 at mainbus0: apid 2 (application processor) > TSC skew=0 > cpu1: Intel(R) Celeron(R) CPU N2807 @ 1.58GHz, 1583.34 MHz, 06-37-08 > 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,SSE4.1,SSE4.2,MOVBE,POPCNT,DEADLINE,RDRAND,NXE,RDTSCP,LONG,LAHF,3DNOWP,PERF,ITSC,TSC_ADJUST,SMEP,ERMS,MD_CLEAR,IBRS,IBPB,STIBP,SENSOR,ARAT,MELTDOWN > cpu1: 1MB 64b/line 16-way L2 cache > tsc_timecounter_init: TSC skew=0 observed drift=0 > cpu1: smt 0, core 1, package 0 > ioapic0 at mainbus0: apid 1 pa 0xfec0, version 20, 87 pins > acpimcfg0 at acpi0 > acpimcfg0: addr 0xe000, bus 0-255 > acpihpet0 at acpi0: 14318179 Hz > acpiprt0 at acpi0: bus 0 (PCI0) > acpiprt1 at acpi0: bus 2 (RP02) > acpiprt2 at acpi0: bus 3 (RP03) > acpiprt3 at acpi0: bus 4 (RP04) > acpiprt4 at acpi0: bus 1 (RP01) > acpiec0 at acpi0: not present > acpicpu0 at acpi0: C3(10@1500 mwait.1@0x52), C2(10@500 mwait.1@0x51), > C1(1000@1 mwait.1), PSS > acpicpu1 at acpi0: C3(10@1500 mwait.1@0x52), C2(10@500 mwait.1@0x51), > C1(1000@1 mwait.1), PSS > acpipwrres0 at acpi0: PLPE > acpipwrres1 at acpi0: PLPE > acpipwrres2 at acpi0: USBC, resource for EHC1, OTG1 > acpipwrres3 at acpi0: CLK0, resource for CAM1 > acpipwrres4 at acpi0: CLK1, resource for CAM0, CAM2 > acpipwrres5 at acpi0: FN00, resource for FAN0 > acpitz0 at acpi0: critical temperature is 90 degC > "INT3396" at acpi0 not configured > acpicmos0 at acpi0 > acpipci0 at acpi0 PCI0: 0x0004 0x0011 0x0001 > "DMA0F28" at acpi0 not configured > acpibtn0 at acpi0: PWRB > acpibtn1 at acpi0: SLPB > "BCM2E1A" at acpi0 not configured > "BCM4752" at acpi0 not configured > "AUTH2750" at acpi0 not configured > "INTCF0B" at acpi0 not configured > "INTCF1A" at acpi0 not configured > "INTCF1C" at acpi0 not configured > "SMO91D0" at acpi0 not configured > "MSFT0002" at acpi0 not configured > "INT33BD" at acpi0 not configured > "PNP0C0B" at acpi0 not configured > acpivideo0 at acpi0: GFX0 > acpivout0 at acpivideo0: DD1F > cpu0: using VERW MDS workaround > cpu0: Enhanced SpeedStep 1583 MHz: speeds: 1577, 1494, 1411, 1328, 1245, > 1162, 1079, 996, 913, 830, 747, 664, 581, 498 MHz > pci0 at mainbus0 bus 0 > pchb0 at pci0 dev 0 function 0 "Intel Bay Trail Host" rev 0x0e > inteldrm0 at pci0 dev 2 function 0 "Intel Bay Trail Video" rev 0x0e > drm0 at inteldrm0 > inteldrm0: msi > ahci0 at pci0 dev 19 function 0 "Intel Bay Trail AHCI" rev 0x0e: msi, AHCI 1.3 > ahci0: port 0: 3.0Gb/s > scsibus1 at ahci0: 32 targets > sd0 at scsibus1 targ 0 lun 0: > naa.524693f2ca20f959 > sd0: 7641MB, 512
system boot hang due to inteldrm(4)
Hi, After updating my router to current, the systems hangs during the boot. Maybe its caused by the "invalid EDID"?! The System boots up normaly and doesn't hang, if I disable inteldrm(4) in UKC. Is this issue known? Or, witch additional debug information should I provide to help fixing this bug? Thanks, Jan [ using 2744944 bytes of bsd ELF symbol table ] Copyright (c) 1982, 1986, 1989, 1991, 1993 The Regents of the University of California. All rights reserved. Copyright (c) 1995-2019 OpenBSD. All rights reserved. https://www.OpenBSD.org OpenBSD 6.6-beta (GENERIC.MP) #328: Thu Sep 26 21:37:06 MDT 2019 dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP real mem = 2024398848 (1930MB) avail mem = 1950400512 (1860MB) mpath0 at root scsibus0 at mpath0: 256 targets mainbus0 at root bios0 at mainbus0: SMBIOS rev. 2.8 @ 0xeca50 (49 entries) bios0: vendor American Megatrends Inc. version "5.6.5" date 01/05/2017 bios0: Lanner Electronics gbXSo acpi0 at bios0: ACPI 5.0 acpi0: sleep states S0 S4 S5 acpi0: tables DSDT FACP APIC FPDT LPIT MCFG HPET SSDT SSDT SSDT UEFI acpi0: wakeup devices EHC1(S4) PXSX(S4) PXSX(S4) PXSX(S4) PXSX(S4) PWRB(S0) BRCM(S0) 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) Celeron(R) CPU N2807 @ 1.58GHz, 1583.59 MHz, 06-37-08 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,SSE4.1,SSE4.2,MOVBE,POPCNT,DEADLINE,RDRAND,NXE,RDTSCP,LONG,LAHF,3DNOWP,PERF,ITSC,TSC_ADJUST,SMEP,ERMS,MD_CLEAR,IBRS,IBPB,STIBP,SENSOR,ARAT,MELTDOWN cpu0: 1MB 64b/line 16-way L2 cache tsc_timecounter_init: TSC skew=0 observed drift=0 cpu0: smt 0, core 0, package 0 mtrr: Pentium Pro MTRR support, 8 var ranges, 88 fixed ranges cpu0: apic clock running at 83MHz cpu0: mwait min=64, max=64, C-substates=0.2.0.0.0.0.3.3, IBE cpu1 at mainbus0: apid 2 (application processor) TSC skew=0 cpu1: Intel(R) Celeron(R) CPU N2807 @ 1.58GHz, 1583.34 MHz, 06-37-08 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,SSE4.1,SSE4.2,MOVBE,POPCNT,DEADLINE,RDRAND,NXE,RDTSCP,LONG,LAHF,3DNOWP,PERF,ITSC,TSC_ADJUST,SMEP,ERMS,MD_CLEAR,IBRS,IBPB,STIBP,SENSOR,ARAT,MELTDOWN cpu1: 1MB 64b/line 16-way L2 cache tsc_timecounter_init: TSC skew=0 observed drift=0 cpu1: smt 0, core 1, package 0 ioapic0 at mainbus0: apid 1 pa 0xfec0, version 20, 87 pins acpimcfg0 at acpi0 acpimcfg0: addr 0xe000, bus 0-255 acpihpet0 at acpi0: 14318179 Hz acpiprt0 at acpi0: bus 0 (PCI0) acpiprt1 at acpi0: bus 2 (RP02) acpiprt2 at acpi0: bus 3 (RP03) acpiprt3 at acpi0: bus 4 (RP04) acpiprt4 at acpi0: bus 1 (RP01) acpiec0 at acpi0: not present acpicpu0 at acpi0: C3(10@1500 mwait.1@0x52), C2(10@500 mwait.1@0x51), C1(1000@1 mwait.1), PSS acpicpu1 at acpi0: C3(10@1500 mwait.1@0x52), C2(10@500 mwait.1@0x51), C1(1000@1 mwait.1), PSS acpipwrres0 at acpi0: PLPE acpipwrres1 at acpi0: PLPE acpipwrres2 at acpi0: USBC, resource for EHC1, OTG1 acpipwrres3 at acpi0: CLK0, resource for CAM1 acpipwrres4 at acpi0: CLK1, resource for CAM0, CAM2 acpipwrres5 at acpi0: FN00, resource for FAN0 acpitz0 at acpi0: critical temperature is 90 degC "INT3396" at acpi0 not configured acpicmos0 at acpi0 acpipci0 at acpi0 PCI0: 0x0004 0x0011 0x0001 "DMA0F28" at acpi0 not configured acpibtn0 at acpi0: PWRB acpibtn1 at acpi0: SLPB "BCM2E1A" at acpi0 not configured "BCM4752" at acpi0 not configured "AUTH2750" at acpi0 not configured "INTCF0B" at acpi0 not configured "INTCF1A" at acpi0 not configured "INTCF1C" at acpi0 not configured "SMO91D0" at acpi0 not configured "MSFT0002" at acpi0 not configured "INT33BD" at acpi0 not configured "PNP0C0B" at acpi0 not configured acpivideo0 at acpi0: GFX0 acpivout0 at acpivideo0: DD1F cpu0: using VERW MDS workaround cpu0: Enhanced SpeedStep 1583 MHz: speeds: 1577, 1494, 1411, 1328, 1245, 1162, 1079, 996, 913, 830, 747, 664, 581, 498 MHz pci0 at mainbus0 bus 0 pchb0 at pci0 dev 0 function 0 "Intel Bay Trail Host" rev 0x0e inteldrm0 at pci0 dev 2 function 0 "Intel Bay Trail Video" rev 0x0e drm0 at inteldrm0 inteldrm0: msi ahci0 at pci0 dev 19 function 0 "Intel Bay Trail AHCI" rev 0x0e: msi, AHCI 1.3 ahci0: port 0: 3.0Gb/s scsibus1 at ahci0: 32 targets sd0 at scsibus1 targ 0 lun 0: naa.524693f2ca20f959 sd0: 7641MB, 512 bytes/sector, 15649200 sectors, thin "Intel Bay Trail TXE" rev 0x0e at pci0 dev 26 function 0 not configured azalia0 at pci0 dev 27 function 0 "Intel Bay Trail HD Audio" rev 0x0e: msi azalia0: no supported codecs ppb0 at pci0 dev 28 function 0 "Intel Bay Trail PCIE" rev 0x0e: msi pci1 at ppb0 bus 1 bwfm0 at pci1 dev 0 function 0 "Broadcom BCM4350" rev 0x08: msi ppb1 at pci0 dev 28 function 1 "Intel Bay Trail PCIE" rev 0x0e: msi pci2 at
Attach Hyper-V guest services to VMBus 4.0
Hi,
I've got a verbal report that Hyper-V guest services aren't attached
on modern Windows 10 systems so I believe we should get this one-liner
in before 6.6.
FreeBSD revision 349856 adds another define for VMBus 5.0 but AFAICT
it doesn't attempt to use it in version negotiations.
Unfortunately, I can't test this myself at the moment.
I've got another two fixes for Hyper-V but can't test them either, so
if somebody is willing to test, please take a look at http://ix.io/1X2V
Cheers,
Mike
diff --git sys/dev/pv/hyperv.c sys/dev/pv/hyperv.c
index a75276335d6..3ab2ae22831 100644
--- sys/dev/pv/hyperv.c
+++ sys/dev/pv/hyperv.c
@@ -803,10 +803,11 @@ hv_channel_delivered(struct hv_softc *sc, struct
vmbus_chanmsg_hdr *hdr)
int
hv_vmbus_connect(struct hv_softc *sc)
{
const uint32_t versions[] = {
+ VMBUS_VERSION_WIN10,
VMBUS_VERSION_WIN8_1, VMBUS_VERSION_WIN8,
VMBUS_VERSION_WIN7, VMBUS_VERSION_WS2008
};
struct vmbus_chanmsg_connect cmd;
struct vmbus_chanmsg_connect_resp rsp;
AMD64 current update overwrites grub2 in dual boot setup
My last 2 updates overwrite Grub2 in a Centos 8/OpenBSD setup. The update proceed normally and generates no warnings. I recovered the last time by booting the Centos install disk in rescue mode and running grub-install. With some direction, I should be able to provide install logs on my next OpenBSD-current update. Please provide specifics as to what is needed. Thanks -- J. Scott Heppler
Re: namei.9: Typofix
On Mon, Sep 30, 2019 at 09:45:38PM +0200, Klemens Nanni wrote: > On Mon, Sep 30, 2019 at 08:37:31PM +0100, Jason McIntyre wrote: > > i think this is probably correct. but i also think that text should be > > in commas: > > > > The segment flag, which defines ..., is specified by segflg. > Fine with me. > > > there's another text segment that i suspect should be singular: > Thanks. > > OK? > yes, fine with me. jmc > > Index: namei.9 > === > RCS file: /cvs/src/share/man/man9/namei.9,v > retrieving revision 1.21 > diff -u -p -r1.21 namei.9 > --- namei.9 13 Aug 2018 23:13:02 - 1.21 > +++ namei.9 30 Sep 2019 19:45:10 - > @@ -199,7 +199,7 @@ and is of length > .Em ndp-\*[Gt]ni_pathlen . > The > .Em ndp-\*[Gt]segflg > -flags defines whether the name in > +flag defines whether the name in > .Em ndp-\*[Gt]ni_dirp > is an address in kernel space (UIO_SYSSPACE) or an address in user > space (UIO_USERSPACE). > @@ -272,8 +272,8 @@ These are the values to which > and > .Em ndp-\*[Gt]ni_cnd.cn_flags > are respectively set. > -The segment flags which defines whether the pathname is in kernel > -address space or user address space is specified by > +The segment flag, which defines whether the pathname is in kernel > +address space or user address space, is specified by > .Fa segflg . > The directory from which relative pathnames will be looked up is > specified by >
Re: namei.9: Typofix
On Mon, Sep 30, 2019 at 08:37:31PM +0100, Jason McIntyre wrote: > i think this is probably correct. but i also think that text should be > in commas: > > The segment flag, which defines ..., is specified by segflg. Fine with me. > there's another text segment that i suspect should be singular: Thanks. OK? Index: namei.9 === RCS file: /cvs/src/share/man/man9/namei.9,v retrieving revision 1.21 diff -u -p -r1.21 namei.9 --- namei.9 13 Aug 2018 23:13:02 - 1.21 +++ namei.9 30 Sep 2019 19:45:10 - @@ -199,7 +199,7 @@ and is of length .Em ndp-\*[Gt]ni_pathlen . The .Em ndp-\*[Gt]segflg -flags defines whether the name in +flag defines whether the name in .Em ndp-\*[Gt]ni_dirp is an address in kernel space (UIO_SYSSPACE) or an address in user space (UIO_USERSPACE). @@ -272,8 +272,8 @@ These are the values to which and .Em ndp-\*[Gt]ni_cnd.cn_flags are respectively set. -The segment flags which defines whether the pathname is in kernel -address space or user address space is specified by +The segment flag, which defines whether the pathname is in kernel +address space or user address space, is specified by .Fa segflg . The directory from which relative pathnames will be looked up is specified by
Re: namei.9: Typofix
On Mon, Sep 30, 2019 at 08:58:19PM +0200, Klemens Nanni wrote: > segflg is singular, had to read that sentence thrice to get it right. > > OK? > > > Index: man/man9/namei.9 > === > RCS file: /cvs/src/share/man/man9/namei.9,v > retrieving revision 1.21 > diff -u -p -r1.21 namei.9 > --- man/man9/namei.9 13 Aug 2018 23:13:02 - 1.21 > +++ man/man9/namei.9 30 Sep 2019 18:55:51 - > @@ -272,7 +272,7 @@ These are the values to which > and > .Em ndp-\*[Gt]ni_cnd.cn_flags > are respectively set. > -The segment flags which defines whether the pathname is in kernel > +The segment flag which defines whether the pathname is in kernel > address space or user address space is specified by > .Fa segflg . > The directory from which relative pathnames will be looked up is > i think this is probably correct. but i also think that text should be in commas: The segment flag, which defines ..., is specified by segflg. there's another text segment that i suspect should be singular: FUNCTIONS namei(ndp) Convert a pathname into a pointer to a vnode. The pathname is specified by ndp->ni_dirp and is of length ndp->ni_pathlen. The ndp->segflg flags defines whether the name in ndp->ni_dirp is an address in kernel space (UIO_SYSSPACE) or an address in user space (UIO_USERSPACE). i suspect it should read "The ndp->segflg flag defines". jmc
namei.9: Typofix
segflg is singular, had to read that sentence thrice to get it right. OK? Index: man/man9/namei.9 === RCS file: /cvs/src/share/man/man9/namei.9,v retrieving revision 1.21 diff -u -p -r1.21 namei.9 --- man/man9/namei.913 Aug 2018 23:13:02 - 1.21 +++ man/man9/namei.930 Sep 2019 18:55:51 - @@ -272,7 +272,7 @@ These are the values to which and .Em ndp-\*[Gt]ni_cnd.cn_flags are respectively set. -The segment flags which defines whether the pathname is in kernel +The segment flag which defines whether the pathname is in kernel address space or user address space is specified by .Fa segflg . The directory from which relative pathnames will be looked up is
bgpd changes for portability
The portable version returns -1 in kr_init() because then the fd is
skipped in the poll loop. Now the problem is I changed this some time ago
to exit bgpd. I changed the function to pass the fd a pointer arg and so
the return -1 still works.
Additionally introduce a tcp_md5_unset() function which will be used by
the linux compat to unregister TCP MD5SUM keys from listening sockets when
a peer is removed.
Last but not least, remove the call to pfkey_remove() in session.c (the
session engine does not even have the pfkey socket to talk to) and also
use the right bgpd_config pointer in merge_peers (don't fall back to the
gloabl conf).
OK?
--
:wq Claudio
Index: bgpd.c
===
RCS file: /cvs/src/usr.sbin/bgpd/bgpd.c,v
retrieving revision 1.225
diff -u -p -r1.225 bgpd.c
--- bgpd.c 8 Aug 2019 11:33:08 - 1.225
+++ bgpd.c 30 Sep 2019 13:28:42 -
@@ -234,7 +234,7 @@ main(int argc, char *argv[])
imsg_init(ibuf_se, pipe_m2s[0]);
imsg_init(ibuf_rde, pipe_m2r[0]);
mrt_init(ibuf_rde, ibuf_se);
- if ((rfd = kr_init()) == -1)
+ if (kr_init(&rfd) == -1)
quit = 1;
keyfd = pfkey_init();
Index: bgpd.h
===
RCS file: /cvs/src/usr.sbin/bgpd/bgpd.h,v
retrieving revision 1.393
diff -u -p -r1.393 bgpd.h
--- bgpd.h 27 Sep 2019 10:33:06 - 1.393
+++ bgpd.h 30 Sep 2019 13:28:21 -
@@ -1185,7 +1185,7 @@ int prefixset_cmp(struct prefixset_item
RB_PROTOTYPE(prefixset_tree, prefixset_item, entry, prefixset_cmp);
/* kroute.c */
-int kr_init(void);
+int kr_init(int *);
int ktable_update(u_int, char *, int, u_int8_t);
voidktable_preload(void);
voidktable_postload(u_int8_t);
Index: kroute.c
===
RCS file: /cvs/src/usr.sbin/bgpd/kroute.c,v
retrieving revision 1.238
diff -u -p -r1.238 kroute.c
--- kroute.c8 Aug 2019 20:06:29 - 1.238
+++ kroute.c30 Sep 2019 13:28:13 -
@@ -213,7 +213,7 @@ RB_GENERATE(kif_tree, kif_node, entry, k
*/
int
-kr_init(void)
+kr_init(int *fd)
{
int opt = 0, rcvbuf, default_rcvbuf;
unsigned inttid = RTABLE_ANY;
@@ -257,7 +257,8 @@ kr_init(void)
if (fetchifs(0) == -1)
return (-1);
- return (kr_state.fd);
+ *fd = kr_state.fd;
+ return (0);
}
int
Index: pfkey.c
===
RCS file: /cvs/src/usr.sbin/bgpd/pfkey.c,v
retrieving revision 1.59
diff -u -p -r1.59 pfkey.c
--- pfkey.c 30 Sep 2019 12:10:38 - 1.59
+++ pfkey.c 30 Sep 2019 14:05:16 -
@@ -866,3 +866,9 @@ tcp_md5_listen(struct listen_addr *la, s
}
return 0;
}
+
+/* dummy function for portable */
+void
+tcp_md5_unset(struct bgpd_config *conf, struct peer *p)
+{
+}
Index: session.c
===
RCS file: /cvs/src/usr.sbin/bgpd/session.c,v
retrieving revision 1.391
diff -u -p -r1.391 session.c
--- session.c 30 Sep 2019 12:10:38 - 1.391
+++ session.c 30 Sep 2019 14:03:50 -
@@ -276,7 +276,7 @@ session_main(int debug, int verbose)
log_peer_warnx(&p->conf, "removed");
RB_REMOVE(peer_head, &conf->peers, p);
timer_remove_all(p);
- pfkey_remove(p);
+ tcp_md5_unset(conf, p);
free(p);
peer_cnt--;
continue;
@@ -3170,7 +3170,7 @@ merge_peers(struct bgpd_config *c, struc
{
struct peer *p, *np, *next;
- RB_FOREACH(p, peer_head, &conf->peers) {
+ RB_FOREACH(p, peer_head, &c->peers) {
/* templates are handled specially */
if (p->template != NULL)
continue;
@@ -3203,7 +3203,7 @@ merge_peers(struct bgpd_config *c, struc
/* apply the config to all clones of a template */
if (p->conf.template) {
struct peer *xp;
- RB_FOREACH(xp, peer_head, &conf->peers) {
+ RB_FOREACH(xp, peer_head, &c->peers) {
if (xp->template != p)
continue;
session_template_clone(xp, NULL, xp->conf.id,
@@ -3218,7 +3218,7 @@ merge_peers(struct bgpd_config *c, struc
/* pfkeys of new peers already loaded by the parent process */
RB_FOREACH_SAFE(np, peer_head, &nc->peers, next) {
RB_REMOVE(peer_head, &nc->peers, np);
- if (RB_INSERT(peer_head, &conf->peers
Re: eoip.4: document interface admin
Jason McIntyre wrote: > On Mon, Sep 30, 2019 at 10:28:50AM +1000, David Gwynne wrote: > > i got an email recently asking how to configure the tunnel identifier > > on an eoip(4) interface, and initially wanted to point the sender > > at the manpage. unfortunately, the manpage is written for programmers > > who have spent a lot of time in network drivers, ie, me. everyone > > else who just wants to configure an interface with ifconfig(8) or > > netstart(8) loses. > > > > this adds a subsection to the eoip manpage on how to administer the > > interfaces, and very slightly tweaks the example to show how the tunnel > > id lines up between openbsd and whatever mikrotik calls their os. > > > > so ok? > > > > i actually like this change as it makes the documentation more useful > > for what people do with an interface, which is operate it. if this goes > > in i would like to update the other pseudo interface driver manpages so > > they're more like this. > > > > morning. > > i'm not against this addition, but it does seem like we're > setting up issues for the future: we'll be moving from having this info > in one place to many. when it changes, it's easier to get it wrong. > > what's the thinking? i mean, the stuff is already there in ifconfig(8). > is it not clear enough? can we make it clearer? or are people just not > working out where to look? > > we kind of farmed all this info into ifconfig(8). i'm not sure whether > we want to move it out again. or if we do, do we try to reduce the > content in ifconfig.8? documentation critical to useability must be discoverable.
Re: sxitemp: set calibraration data, introducing sxisid
> Date: Sun, 29 Sep 2019 23:14:14 +0200 > From: Krystian Lewandowski > > Mark, thank you for quick feedback. > > I'm not pushing or anything of course, > just want to provide more information. > > I put radiator on A64+ I'm using (both were tested with radiator), > also FreeBSD and OpenBSD may have been using different clocks > (648MHz vs 768MHz), original mail was sent in April, long before > sxiccmu update. > > After cold boot (when unused for a few hours) axppmic temp is more inline > with sxitemp when sxisid is used. > > I've also tested Pinebook. > I did not plug power supply and used low brightness allowing PMIC to stay > cool on Pinebook. I tried to test everything after temps stabilized at idle > and to report consecutive boots. > > - Pinebook with sxisid: > $ uname -a > OpenBSD pinebook.belchatow.vectranet.pl 6.6 GENERIC.MP#6 arm64 > > hw.sensors.axppmic0.temp0=38.62 degC > hw.sensors.sxitemp0.temp0=33.41 degC (CPU) > hw.sensors.sxitemp0.temp1=34.93 degC (GPU) > hw.sensors.sxitemp0.temp2=35.51 degC > hw.cpuspeed=648 > > > - Pinebook vanilla: > $ uname -a > OpenBSD pinebook.belchatow.vectranet.pl 6.6 GENERIC#236 arm64 > > hw.sensors.axppmic0.temp0=34.69 degC > hw.sensors.sxitemp0.temp0=35.86 degC (CPU) > hw.sensors.sxitemp0.temp1=37.27 degC (GPU) > hw.sensors.sxitemp0.temp2=37.38 degC > hw.cpuspeed=648 > > > - A64+ with sxisid: > > hw.sensors.axppmic0.temp0=39.15 degC > hw.sensors.sxitemp0.temp0=37.38 degC (CPU) > hw.sensors.sxitemp0.temp1=36.33 degC (GPU) > hw.sensors.sxitemp0.temp2=38.55 degC > > > - A64+ vanilla: > > hw.sensors.axppmic0.temp0=38.73 degC > hw.sensors.sxitemp0.temp0=50.47 degC (CPU) > hw.sensors.sxitemp0.temp1=51.99 degC (GPU) > hw.sensors.sxitemp0.temp2=51.87 degC Those numbers look a bit more reasonable than the FreeBSD numbers you posted earlier. The axppmic(4) sensors is on a different chip though, so the temperatures aren't necessarily related. In the end the actual temperature doesn't really matter. What matters is that the trip points are chosen such that we don't throttle the CPU too early or too late. It's a bit sad that the upstreaming of the thermal sensor support in mainline Linux seems to have stalled completely. I'm a litte bit reluctant to add a lot of code if it is not clear that this will ever land in mainline Linux. That said, the "sid" stuff has proper bindings so I'll take a closer look at it.
Re: eoip.4: document interface admin
On Mon, Sep 30, 2019 at 05:42:33PM +1000, David Gwynne wrote: > On Mon, Sep 30, 2019 at 06:49:14AM +0100, Jason McIntyre wrote: > > On Mon, Sep 30, 2019 at 10:28:50AM +1000, David Gwynne wrote: > > > i got an email recently asking how to configure the tunnel identifier > > > on an eoip(4) interface, and initially wanted to point the sender > > > at the manpage. unfortunately, the manpage is written for programmers > > > who have spent a lot of time in network drivers, ie, me. everyone > > > else who just wants to configure an interface with ifconfig(8) or > > > netstart(8) loses. > > > > > > this adds a subsection to the eoip manpage on how to administer the > > > interfaces, and very slightly tweaks the example to show how the tunnel > > > id lines up between openbsd and whatever mikrotik calls their os. > > > > > > so ok? > > > > > > i actually like this change as it makes the documentation more useful > > > for what people do with an interface, which is operate it. if this goes > > > in i would like to update the other pseudo interface driver manpages so > > > they're more like this. > > > > > > > morning. > > > > i'm not against this addition, but it does seem like we're > > setting up issues for the future: we'll be moving from having this info > > in one place to many. when it changes, it's easier to get it wrong. > > > > what's the thinking? i mean, the stuff is already there in ifconfig(8). > > is it not clear enough? can we make it clearer? or are people just not > > working out where to look? > > we (openbsd) try to provide a generic set of ioctls and therefore > command line options in ifconfig that end up configuring specific things > in a variety of drivers. on top of this, different drivers implement a > different subset of these ioctls and ifconfig arguments depending on > what the protocol is actually capable of. > > in this specific situation, the problem is that eoip on a mikrotik > (where the eoip protocol was invented) requires the configuration of a > 16-bit tunnel identifier, but it is not obvious what you have to > type in openbsd to set that. the tunnel-id is kind of equivalent > to a vlan tag number, and like the vlan tag number on a vlan > interface, it is configured with the vnetid argument in ifconfig. > that's not obvious from the manpage. > > another example is GRE, which as a protocol it has an optional key > field in it's header. it's the same problem here same in that it > is called one thing in the protocol but you don't type "ifconfig gre0 > key 1234". again, you use vnetid to set that. > > an example of the differening subsets of functionality is also around > vnetids. in GRE as a protocol, the Key is optional so you can use > ifconfig gre0 -vnetid to disable use of it. in vlan(4) there's a magic > value (0) on the wire that means the vlan tag is kind of like a default and > you only care about the priority bits, which again you use -vnetid to enable > the use of. eoip(4) is different again in that the tunnel-id is > mandatory and there are no magic values, so it doesn't support > -vnetid. > > > we kind of farmed all this info into ifconfig(8). i'm not sure whether > > we want to move it out again. or if we do, do we try to reduce the > > content in ifconfig.8? > > my opinion is that we should still document what things you can > pass to ifconfig, but cut out some references to specific behaviours > of various drivers. what functionality a specific driver supports > should be in the documentation for that specific driver. > > alternatively we can come up with a better way to document what a driver > does wrt to things like vnetids. > i'm fine with whatever way you think makes most sense. but it would be good to not list all that stuff in ifconfig, and then again in the driver page. maybe you should push on with moving such details to the driver pages, then we can look and see whether we can remove some stuff from ifconfig.8. jmc
Re: eoip.4: document interface admin
David Gwynne(da...@gwynne.id.au) on 2019.09.30 17:42:33 +1000: > On Mon, Sep 30, 2019 at 06:49:14AM +0100, Jason McIntyre wrote: > > On Mon, Sep 30, 2019 at 10:28:50AM +1000, David Gwynne wrote: > > > i got an email recently asking how to configure the tunnel identifier > > > on an eoip(4) interface, and initially wanted to point the sender > > > at the manpage. unfortunately, the manpage is written for programmers > > > who have spent a lot of time in network drivers, ie, me. everyone > > > else who just wants to configure an interface with ifconfig(8) or > > > netstart(8) loses. > > > > > > this adds a subsection to the eoip manpage on how to administer the > > > interfaces, and very slightly tweaks the example to show how the tunnel > > > id lines up between openbsd and whatever mikrotik calls their os. > > > > > > so ok? > > > > > > i actually like this change as it makes the documentation more useful > > > for what people do with an interface, which is operate it. if this goes > > > in i would like to update the other pseudo interface driver manpages so > > > they're more like this. > > > > > > > morning. > > > > i'm not against this addition, but it does seem like we're > > setting up issues for the future: we'll be moving from having this info > > in one place to many. when it changes, it's easier to get it wrong. > > > > what's the thinking? i mean, the stuff is already there in ifconfig(8). > > is it not clear enough? can we make it clearer? or are people just not > > working out where to look? > > we (openbsd) try to provide a generic set of ioctls and therefore > command line options in ifconfig that end up configuring specific things > in a variety of drivers. on top of this, different drivers implement a > different subset of these ioctls and ifconfig arguments depending on > what the protocol is actually capable of. > > in this specific situation, the problem is that eoip on a mikrotik > (where the eoip protocol was invented) requires the configuration of a > 16-bit tunnel identifier, but it is not obvious what you have to > type in openbsd to set that. the tunnel-id is kind of equivalent > to a vlan tag number, and like the vlan tag number on a vlan > interface, it is configured with the vnetid argument in ifconfig. > that's not obvious from the manpage. > > another example is GRE, which as a protocol it has an optional key > field in it's header. it's the same problem here same in that it > is called one thing in the protocol but you don't type "ifconfig gre0 > key 1234". again, you use vnetid to set that. > > an example of the differening subsets of functionality is also around > vnetids. in GRE as a protocol, the Key is optional so you can use > ifconfig gre0 -vnetid to disable use of it. in vlan(4) there's a magic > value (0) on the wire that means the vlan tag is kind of like a default and > you only care about the priority bits, which again you use -vnetid to enable > the use of. eoip(4) is different again in that the tunnel-id is > mandatory and there are no magic values, so it doesn't support > -vnetid. I think the problem is that all the encapsulation interfaces are described under TUNNEL in the ifconfig manpage, even though there are a lot of different things to say about them. The vnetid secription under TUNNEL does not mention the gre(4) behaiviour you mention, for example. Adding a lot of information to that section about specific tunnel drivers seems excessive to me. With some of these drivers, having extra information and examples (more than we usually have) is really helpful because you often use them to connect to non-OpenBSD devices and have to correlate different configuration syntax, methods and description to get it working. So let's put it into the driver manpage. So i'm with David here. > > we kind of farmed all this info into ifconfig(8). i'm not sure whether > > we want to move it out again. or if we do, do we try to reduce the > > content in ifconfig.8? > > my opinion is that we should still document what things you can > pass to ifconfig, but cut out some references to specific behaviours > of various drivers. what functionality a specific driver supports > should be in the documentation for that specific driver. > > alternatively we can come up with a better way to document what a driver > does wrt to things like vnetids. > > > > > jmc > > > > > Index: eoip.4 > > > === > > > RCS file: /cvs/src/share/man/man4/eoip.4,v > > > retrieving revision 1.4 > > > diff -u -p -r1.4 eoip.4 > > > --- eoip.429 May 2019 19:37:06 - 1.4 > > > +++ eoip.430 Sep 2019 00:11:55 - > > > @@ -83,12 +83,68 @@ route to the tunnel destination than the > > > via the tunnel interface. > > > Alternatively, the tunnel traffic may be configured in a separate > > > routing table to the encapsulated traffic. > > > +.Ss Network Interface Administration > > > +.Nm > > > +interfaces may
Re: remove custom mbuf copy function support from bpf internals
On Mon, Sep 30, 2019 at 08:54:14AM +0200, Claudio Jeker wrote:
> On Mon, Sep 30, 2019 at 12:06:34PM +1000, David Gwynne wrote:
> > the "public" bpf api no longer supports custom copy functions, so we can
> > remove the plumbing for it internally in the bpf code.
> >
> > ok?
> >
> > Index: bpf.c
> > ===
> > RCS file: /cvs/src/sys/net/bpf.c,v
> > retrieving revision 1.180
> > diff -u -p -r1.180 bpf.c
> > --- bpf.c 30 Sep 2019 01:53:05 - 1.180
> > +++ bpf.c 30 Sep 2019 02:04:37 -
> > @@ -94,8 +94,6 @@ LIST_HEAD(, bpf_d) bpf_d_list;
> >
> > intbpf_allocbufs(struct bpf_d *);
> > void bpf_ifname(struct bpf_if*, struct ifreq *);
> > -int_bpf_mtap(caddr_t, const struct mbuf *, u_int,
> > - void (*)(const void *, void *, size_t));
> > void bpf_mcopy(const void *, void *, size_t);
> > intbpf_movein(struct uio *, struct bpf_d *, struct mbuf **,
> > struct sockaddr *);
> > @@ -105,7 +103,7 @@ int bpfkqfilter(dev_t, struct knote *);
> > void bpf_wakeup(struct bpf_d *);
> > void bpf_wakeup_cb(void *);
> > void bpf_catchpacket(struct bpf_d *, u_char *, size_t, size_t,
> > - void (*)(const void *, void *, size_t), struct timeval *);
> > + struct timeval *);
> > intbpf_getdltlist(struct bpf_d *, struct bpf_dltlist *);
> > intbpf_setdlt(struct bpf_d *, u_int);
> >
> > @@ -1241,12 +1239,8 @@ bpf_mcopy(const void *src_arg, void *dst
> > }
> > }
> >
> > -/*
> > - * like bpf_mtap, but copy fn can be given. used by various bpf_mtap*
> > - */
> > int
> > -_bpf_mtap(caddr_t arg, const struct mbuf *m, u_int direction,
> > -void (*cpfn)(const void *, void *, size_t))
> > +bpf_mtap(caddr_t arg, const struct mbuf *m, u_int direction)
> > {
> > struct bpf_if *bp = (struct bpf_if *)arg;
> > struct bpf_d *d;
> > @@ -1259,9 +1253,6 @@ _bpf_mtap(caddr_t arg, const struct mbuf
> > if (m == NULL)
> > return (0);
> >
> > - if (cpfn == NULL)
> > - cpfn = bpf_mcopy;
> > -
> > if (bp == NULL)
> > return (0);
> >
> > @@ -1299,8 +1290,7 @@ _bpf_mtap(caddr_t arg, const struct mbuf
> > }
> >
> > mtx_enter(&d->bd_mtx);
> > - bpf_catchpacket(d, (u_char *)m, pktlen, slen, cpfn,
> > - &tv);
> > + bpf_catchpacket(d, (u_char *)m, pktlen, slen, &tv);
> > mtx_leave(&d->bd_mtx);
> > }
> > }
> > @@ -1345,16 +1335,7 @@ bpf_tap_hdr(caddr_t arg, const void *hdr
> > *mp = (struct mbuf *)&md;
> > }
> >
> > - return _bpf_mtap(arg, m0, direction, bpf_mcopy);
> > -}
> > -
> > -/*
> > - * Incoming linkage from device drivers, when packet is in an mbuf chain.
> > - */
> > -int
> > -bpf_mtap(caddr_t arg, const struct mbuf *m, u_int direction)
> > -{
> > - return _bpf_mtap(arg, m, direction, NULL);
> > + return bpf_mtap(arg, m0, direction);
> > }
> >
> > /*
> > @@ -1382,7 +1363,7 @@ bpf_mtap_hdr(caddr_t arg, const void *da
> > } else
> > m0 = m;
> >
> > - return _bpf_mtap(arg, m0, direction, NULL);
> > + return bpf_mtap(arg, m0, direction);
> > }
> >
> > /*
> > @@ -1460,7 +1441,7 @@ bpf_mtap_ether(caddr_t arg, const struct
> > */
> > void
> > bpf_catchpacket(struct bpf_d *d, u_char *pkt, size_t pktlen, size_t
> > snaplen,
> > -void (*cpfn)(const void *, void *, size_t), struct timeval *tv)
> > +struct timeval *tv)
> > {
> > struct bpf_hdr *hp;
> > int totlen, curlen;
> > @@ -1513,10 +1494,12 @@ bpf_catchpacket(struct bpf_d *d, u_char
> > hp->bh_tstamp.tv_usec = tv->tv_usec;
> > hp->bh_datalen = pktlen;
> > hp->bh_hdrlen = hdrlen;
> > +
> > /*
> > * Copy the packet data into the store buffer and update its length.
> > */
> > - (*cpfn)(pkt, (u_char *)hp + hdrlen, (hp->bh_caplen = totlen - hdrlen));
> > + bpf_mcopy(pkt, (u_char *)hp + hdrlen,
> > + (hp->bh_caplen = totlen - hdrlen));
>
> This new line is not really needed but also yuck on assigning the size in
> a function call argument. Maybe do the hp->bh_caplen = totlen - hdrlen before
> the call and pass hp->bh_caplen to bpf_mcopy().
ikr. i'll take it as a free second commit after this one.
>
> > d->bd_slen = curlen + totlen;
> >
> > if (d->bd_immediate) {
> >
>
> OK claudio@
cheers :)
>
> --
> :wq Claudio
Re: eoip.4: document interface admin
On Mon, Sep 30, 2019 at 06:49:14AM +0100, Jason McIntyre wrote: > On Mon, Sep 30, 2019 at 10:28:50AM +1000, David Gwynne wrote: > > i got an email recently asking how to configure the tunnel identifier > > on an eoip(4) interface, and initially wanted to point the sender > > at the manpage. unfortunately, the manpage is written for programmers > > who have spent a lot of time in network drivers, ie, me. everyone > > else who just wants to configure an interface with ifconfig(8) or > > netstart(8) loses. > > > > this adds a subsection to the eoip manpage on how to administer the > > interfaces, and very slightly tweaks the example to show how the tunnel > > id lines up between openbsd and whatever mikrotik calls their os. > > > > so ok? > > > > i actually like this change as it makes the documentation more useful > > for what people do with an interface, which is operate it. if this goes > > in i would like to update the other pseudo interface driver manpages so > > they're more like this. > > > > morning. > > i'm not against this addition, but it does seem like we're > setting up issues for the future: we'll be moving from having this info > in one place to many. when it changes, it's easier to get it wrong. > > what's the thinking? i mean, the stuff is already there in ifconfig(8). > is it not clear enough? can we make it clearer? or are people just not > working out where to look? we (openbsd) try to provide a generic set of ioctls and therefore command line options in ifconfig that end up configuring specific things in a variety of drivers. on top of this, different drivers implement a different subset of these ioctls and ifconfig arguments depending on what the protocol is actually capable of. in this specific situation, the problem is that eoip on a mikrotik (where the eoip protocol was invented) requires the configuration of a 16-bit tunnel identifier, but it is not obvious what you have to type in openbsd to set that. the tunnel-id is kind of equivalent to a vlan tag number, and like the vlan tag number on a vlan interface, it is configured with the vnetid argument in ifconfig. that's not obvious from the manpage. another example is GRE, which as a protocol it has an optional key field in it's header. it's the same problem here same in that it is called one thing in the protocol but you don't type "ifconfig gre0 key 1234". again, you use vnetid to set that. an example of the differening subsets of functionality is also around vnetids. in GRE as a protocol, the Key is optional so you can use ifconfig gre0 -vnetid to disable use of it. in vlan(4) there's a magic value (0) on the wire that means the vlan tag is kind of like a default and you only care about the priority bits, which again you use -vnetid to enable the use of. eoip(4) is different again in that the tunnel-id is mandatory and there are no magic values, so it doesn't support -vnetid. > we kind of farmed all this info into ifconfig(8). i'm not sure whether > we want to move it out again. or if we do, do we try to reduce the > content in ifconfig.8? my opinion is that we should still document what things you can pass to ifconfig, but cut out some references to specific behaviours of various drivers. what functionality a specific driver supports should be in the documentation for that specific driver. alternatively we can come up with a better way to document what a driver does wrt to things like vnetids. > > jmc > > > Index: eoip.4 > > === > > RCS file: /cvs/src/share/man/man4/eoip.4,v > > retrieving revision 1.4 > > diff -u -p -r1.4 eoip.4 > > --- eoip.4 29 May 2019 19:37:06 - 1.4 > > +++ eoip.4 30 Sep 2019 00:11:55 - > > @@ -83,12 +83,68 @@ route to the tunnel destination than the > > via the tunnel interface. > > Alternatively, the tunnel traffic may be configured in a separate > > routing table to the encapsulated traffic. > > +.Ss Network Interface Administration > > +.Nm > > +interfaces may be configured by > > +.Xr ifconfig 8 > > +or > > +.Xr netstart 8 > > +using the following options: > > +.Bl -tag -width indent > > +.It Cm tunnel Ar src_address dest_address > > +Set the unicast IPv4 or IPv6 addresses for the encapsulating IP packets. > > +The addresses may only be configured while the interface is down. > > +.It Fl Ns Cm tunnel > > +Clear the addresses used for the encapsulating IP packets. > > +The addresses may only be cleared while the interface is down. > > +.It Cm vnetid Ar tunnel-identifier > > +Configure the virtual network identifier to use as the Tunnel Identifier. > > +The virtual network identifier may only be configured while the > > +interface is down. > > +The Tunnel Identifier is a 16-bit value between 0 and 65535 inclusive. > > +.It Cm tunneldomain Ar rdomain > > +Set the routing table the tunnel traffic operates in. > > +The routing table may only be configured while the interface is down. > > +.It Cm tunnelttl Ar ttl
