Re: disable libc sys wrappers?
> Added a -T option to ktrace for transparency. I got ambitious here and made > it take suboptions, anticipating that other transparency modifications may > be desired. Please don't do that. First off, I see no future in the open/openat idea. Not just pledge, not just unveil, not just reduction in ktrace clarity, I see no upside and only downsides. But secondly, I see no future in any other ideas of reducing system calls, since they are the fundamental interface to do a request without magic. This time thing is magic becuase it has to be (latency and accuracy), but I see no future for anything else being magic. If you make -T take options noone will use it, and the exercise is pointless. Noone is going to manually set the environment variable, that much I can tell you also...
Re: disable libc sys wrappers?
> Call getenv before issetugid. Why?? issetugid is a syscall (yes, it has overhead) which (amongst other things) whether you can trust the environment. But getenv -- that's a call which trusts enough of the environment array's structure, to do a walk, and find. Why do the walk, at all, if you aren't supposed to? It might not just be the string in the environment, it might be some other corruption (I can't see one, but WHY do the idiom in a less safe way?) It is entirely BACKWARDS from what we do elsewhere. Who suggested you do this?
Re: disable libc sys wrappers?
On 2020-07-09, Theo de Raadt wrote:
> Hang on. Do people ever want to force time calls, outside of ktrace?
> I doubt it. Should ktrace maybe have a flag, similar to -B with LD_BIND_NOW,
> which sets the new environment variable? Maybe -T? The problem smells very
> similar to the root cause for LD_BIND_NOW setting..
So taking into account most feedback, another round.
env variable is now _LIBC_NOUSERTC. It's not libc's concern that ktrace may
want this, so I didn't go with that. The feature in question is usertc,
so that seems the most direct name.
Call getenv before issetugid.
Added a -T option to ktrace for transparency. I got ambitious here and made
it take suboptions, anticipating that other transparency modifications may
be desired. Fold in -B perhaps? I think typing -Tt is not so burdensome,
and saves us some alphabet down the line.
As a bonus, fix ktrace usage. -B only works with second synopsis, with command.
Index: lib/libc/dlfcn/init.c
===
RCS file: /home/cvs/src/lib/libc/dlfcn/init.c,v
retrieving revision 1.8
diff -u -p -r1.8 init.c
--- lib/libc/dlfcn/init.c 6 Jul 2020 13:33:05 - 1.8
+++ lib/libc/dlfcn/init.c 10 Jul 2020 02:12:41 -
@@ -114,6 +114,8 @@ _libc_preinit(int argc, char **argv, cha
_timekeep->tk_version != TK_VERSION)
_timekeep = NULL;
}
+ if (getenv("_LIBC_NOUSERTC") && issetugid() == 0)
+ _timekeep = NULL;
break;
}
}
Index: usr.bin/ktrace/extern.h
===
RCS file: /home/cvs/src/usr.bin/ktrace/extern.h,v
retrieving revision 1.4
diff -u -p -r1.4 extern.h
--- usr.bin/ktrace/extern.h 26 Apr 2018 18:30:36 - 1.4
+++ usr.bin/ktrace/extern.h 10 Jul 2020 02:21:37 -
@@ -26,3 +26,4 @@
*/
int getpoints(const char *, int);
+int gettrans(const char *, int);
Index: usr.bin/ktrace/ktrace.1
===
RCS file: /home/cvs/src/usr.bin/ktrace/ktrace.1,v
retrieving revision 1.30
diff -u -p -r1.30 ktrace.1
--- usr.bin/ktrace/ktrace.1 15 May 2019 15:36:59 - 1.30
+++ usr.bin/ktrace/ktrace.1 10 Jul 2020 02:24:04 -
@@ -37,14 +37,15 @@
.Nd enable kernel process tracing
.Sh SYNOPSIS
.Nm ktrace
-.Op Fl aBCcdi
+.Op Fl aCcdi
.Op Fl f Ar trfile
.Op Fl g Ar pgid
.Op Fl p Ar pid
.Op Fl t Ar trstr
.Nm ktrace
-.Op Fl adi
+.Op Fl aBdi
.Op Fl f Ar trfile
+.Op Fl T Ar transopts
.Op Fl t Ar trstr
.Ar command
.Sh DESCRIPTION
@@ -109,6 +110,15 @@ processes.
Enable (disable) tracing on the indicated process ID (only one
.Fl p
flag is permitted).
+.It Fl T Ar transopts
+Request additional transparency from libc.
+By default, no options are enabled.
+The argument can contain one or more of the following letters.
+.Pp
+.Bl -tag -width flag -offset indent -compact
+.It Cm t
+Disable userland timecounters so that time related system calls are visible.
+.El
.It Fl t Ar trstr
Select which information to put into the dump file.
The argument can contain one or more of the following letters.
Index: usr.bin/ktrace/ktrace.c
===
RCS file: /home/cvs/src/usr.bin/ktrace/ktrace.c,v
retrieving revision 1.36
diff -u -p -r1.36 ktrace.c
--- usr.bin/ktrace/ktrace.c 28 Jun 2019 13:35:01 - 1.36
+++ usr.bin/ktrace/ktrace.c 10 Jul 2020 02:23:33 -
@@ -60,7 +60,7 @@ int
main(int argc, char *argv[])
{
enum { NOTSET, CLEAR, CLEARALL } clear;
- int append, ch, fd, inherit, ops, pidset, trpoints;
+ int append, ch, fd, inherit, ops, pidset, trpoints, transparency;
pid_t pid;
char *tracefile, *tracespec;
mode_t omask;
@@ -71,6 +71,7 @@ main(int argc, char *argv[])
clear = NOTSET;
append = ops = pidset = inherit = pid = 0;
trpoints = is_ltrace ? KTRFAC_USER : DEF_POINTS;
+ transparency = 0;
tracefile = DEF_TRACEFILE;
tracespec = NULL;
@@ -100,7 +101,7 @@ main(int argc, char *argv[])
usage();
}
} else {
- while ((ch = getopt(argc, argv, "aBCcdf:g:ip:t:")) != -1)
+ while ((ch = getopt(argc, argv, "aBCcdf:g:ip:t:T:")) != -1)
switch ((char)ch) {
case 'a':
append = 1;
@@ -140,6 +141,13 @@ main(int argc, char *argv[])
usage();
}
break;
+ case 'T':
+ transparency = gettrans(optarg, 0);
+ if (transparency < 0) {
+ warnx("unknown
deprecate interface input handler lists, just use a single function pointer
this diff is about fixing some semantic issues with the current interface input handler list processing. i was a bit worried it would cause a small performance hit, but it seems it has the opposite effect and is actually slightly faster. so in my opinion it is more correct, but also improves performance. originially the network stack only really dealt with layer 3 protocols like ipv4, arp, ipv6, and so on. this meant ethernet drivers (ie, 90% of network drivers) had to pull the ethernet header apart in their hardware interrupt handlers before they could throw IP packets over the wall (read queue packets for softnet to process). etherent got complicated though. there's a whole bunch of pseudo/virtual interfaces that do interesting things at the ethernet level, and when we were doing the intiial mpsafe network stack work, none of them were mpsafe. this meant that we couldn't pull ethernet headers apart without taking the big lock, which meant that mpsafe hardware interrupt handlers for nics wouldn't be able to run completely big lock free in moderately interesting network configs. so to help out in the initial mpsafe work, we decided to throw ethernet packets straight off the ring over to softnet and pull ethernet apart there. this let the interrupts run without biglock, but the virtual ethernet interface drivers weren't mpsafe yet. to mitigate against that, we made processing for them optional. since then we have made pretty much all the pseudo interfaces mpsafe though. so the currently situation is that by default, the softnet interface input handler for ethernet interfaces simply looks at the protocol and splits it up into ip/arp/etc. when you enable somethiing like vlan(4) on an interface, it prepends an input handler to normal ethernet one. this handler acts like a filter, so the vlan one takes vlan encapsulated packets away and lets the rest fall through to the normal ethernet one. the bridge input handler looks at the mac address on the packet forwards it based on the address. the semantic problems referred to above kick in if you enable bridge and vlan at the same time. depending on the order in which you attach them to the physical interface, they will filter in different orders. if you enable bridge after vlan, packets will be sent to other ports regardless of the vlan tags on the packet. this sucks if you want to land a vlan on the current box, but bridge everythign else. im arguing that the interaction between vlan interfaces and bridges should be deterministic. and all the virtual interfaces actually. the semantics im suggested are documented as comments in ether_input in the diff below, but i'll list them here too: * Ethernet input has several "phases" of filtering packets to * support virtual/pseudo interfaces before actual layer 3 protocol * handling. * * First phase: * * The first phase supports drivers that aggregate multiple Ethernet * ports into a single logical interface, ie, aggr(4) and trunk(4). * These drivers intercept packets by swapping out the if_input handler * on the "port" interfaces to steal the packets before they get here * to ether_input(). * Second phase: service delimited packet filtering. * * Let vlan(4) and svlan(4) look at "service delimited" * packets. If a virtual interface does not exist to take * those packets, they're returned to ether_input() so a * bridge can have a go at forwarding them. * Third phase: bridge processing. * * Give the packet to a bridge interface, ie, bridge(4), * switch(4), or tpmr(4), if it is configured. A bridge * may take the packet and forward it to another port, or it * may return it here to ether_input() to support local * delivery to this port. * Fourth phase: drop service delimited packets. * * If the packet has a tag, and a bridge didn't want it, * it's not for this port. * Fifth phase: destination address check. * * Is the packet specifically addressed to this port? * If it's not for this port, it could be for carp(4). * If not, it must be multicast or broadcast to go further. * Sixth phase: protocol demux. * * At this point it is known that the packet is destined * for layer 3 protocol handling on the local port. another motivation for doing this is that jmatthew@ tried to convert the srpl holding the interface input handlers to an smrl, and it blew up cos it's possible to do a context switch in the network stack. you're not supposed to do that with srps either, but they're a bit more forgiving. getting rid of the list means another step closer to deprecating srps. Index: net/if.c === RCS file: /cvs/src/sys/net/if.c,v retrieving revision 1.611 diff -u -p -r1.611 if.c --- net/if.c30 Jun 2020 09:31:38 - 1.611 +++ net/if.c9 Jul 2020 10:15:36 - @@ -631,8 +631,6 @@ if_attach_common(struct ifnet *ifp) if (ifp->if_enqueue == NULL) ifp->if_enqueue = if_enqueue_ifq;
Re: bridge(4) shouldn't try to create new interfaces when i make a typo
> On 10 Jul 2020, at 12:45 am, sven falempin wrote: > > On Thu, Jul 9, 2020 at 3:31 AM Klemens Nanni wrote: >> >> On Thu, Jul 09, 2020 at 05:08:01PM +1000, David Gwynne wrote: >>> if i accidentally `ifconfig bridge add gre0` instead of egre0, having >>> bridge create gre0 and then not like it is not what i expect to happen. >>> especially when it leaves me with an extra gre0 interface lying around >>> afterwards. >>> >>> i can appreciate that this was trying to be helpful when you wanted >>> to add virtual interfaces to a bridge on boot, but that was before >>> netstart(8) created all the interfaces with config files up front, before >>> it then goes through and runs the config for them. >> I agree. >> >> OK kn >> > > this will force the use of create beforehand ? the interface you want to add as a bridge port will have to exist before you can add it to a bridge. > or ifconfig bridge0 up will still work ? ifconfig does that, so this diff does not break that. > because script in the wild may not do the create first. scripts may have to be fixed as things change. > > -- > -- > - > Knowing is not enough; we must apply. Willing is not enough; we must do >
[PATCH] AZALIA(4) no audio after suspend
Hi,
I have been running -current on my laptop the last couple of weeks and
after watching some videos I realized that audio playback is gone after
I suspended my laptop.
Reading through the code I arrived at this solution to restore audio
playback after suspend.
The patch has been tested on this card these last couple of days without
any issues.
audio0 at azalia0
azalia0 at pci0 dev 27 function 0 "Intel 82801GB HD Audio" rev 0x02: msi
azalia0: codecs: Realtek ALC272
azalia0: codecs: Realtek ALC272
Index: azalia.c
===
RCS file: /cvs/src/sys/dev/pci/azalia.c,v
retrieving revision 1.257
diff -u -p -u -p -r1.257 azalia.c
--- azalia.c9 Jun 2020 03:36:05 - 1.257
+++ azalia.c9 Jul 2020 21:15:32 -
@@ -904,6 +904,15 @@ azalia_init(azalia_t *az, int resuming)
if (err)
return(err);
+ if (resuming) {
+ err = azalia_init_codecs(az);
+ if (err)
+ return(err);
+ err = azalia_init_streams(az);
+ if (err)
+ return(err);
+ }
+
AZ_WRITE_4(az, INTCTL,
AZ_READ_4(az, INTCTL) | HDA_INTCTL_CIE | HDA_INTCTL_GIE);
Re: silicom X710 ixl, unable to query phy types, no sff
Thanks. The Intel NVM update on that link is the one I mentioned that says not to use it on OEM cards, this is in the readme "This package is intended to be used on Intel branded adapters. Please contact your OEM vendor for an appropriate package. In some cases this package may update an OEM device. This package only updates the NVM image for the device family listed on the package. Each Intel Ethernet product family has its own NVM Update Package." The quad cards are expensive enough that I thought it prudent to follow that advice and ask the vendor. If they had been less helpful then maybe I would have tried the straight-from-Intel file anyway but no need now :) On 2020/07/09 20:55, Tom Smyth wrote: > Hi Stuart, > Just a suggestion > but I have had a difficult time with xl710s Last summer and my vendor > advised me to upgrade the firmware on the cards > if you upgrade > The firmware can be downloaded from here: > https://downloadcenter.intel.com/product/93104/Intel-Ethernet-Controller-XL710-BM1 > (check the exact chipset you have) > > > You can apply the update by running "nvmupdate64e" and following the > prompts. You'll need to restart the machine or power cycle ... > > Hope this helps, > > > > > > On Wed, 8 Jul 2020 at 23:09, Stuart Henderson wrote: > > > I have some ixl cards which show "unable to query phy types" at > > attach time, and return either EIO or ENODEV if I try fetching sff > > pages. > > > > I booted with SFP+ in all ixl ports and have this: > > > > ixl0 at pci6 dev 0 function 0 "Intel X710 SFP+" rev 0x02: port 1, FW > > 5.0.40043 API 1.5, msix, 4 queues, address 00:e0:ed:75:a5:5c > > ixl0: unable to query phy types > > ixl1 at pci6 dev 0 function 1 "Intel X710 SFP+" rev 0x02: port 0, FW > > 5.0.40043 API 1.5, msix, 4 queues, address 00:e0:ed:75:a5:5d > > ixl1: unable to query phy types > > ixl2 at pci6 dev 0 function 2 "Intel X710 SFP+" rev 0x02: port 2, FW > > 5.0.40043 API 1.5, msix, 4 queues, address 00:e0:ed:75:a5:5e > > ixl2: unable to query phy types > > ixl3 at pci6 dev 0 function 3 "Intel X710 SFP+" rev 0x02: port 3, FW > > 5.0.40043 API 1.5, msix, 4 queues, address 00:e0:ed:75:a5:5f > > ixl3: unable to query phy types > > > > # ifconfig ixl sff > > ixl0: flags=8802 mtu 1500 > > lladdr 00:e0:ed:75:a5:5c > > index 3 priority 0 llprio 3 > > media: Ethernet autoselect > > status: no carrier > > ifconfig: ixl0 transceiver: Input/output error > > ixl1: flags=8802 mtu 1500 > > lladdr 00:e0:ed:75:a5:5d > > index 4 priority 0 llprio 3 > > media: Ethernet autoselect > > status: no carrier > > ifconfig: ixl1 transceiver: Input/output error > > ixl2: flags=8802 mtu 1500 > > lladdr 00:e0:ed:75:a5:5e > > index 5 priority 0 llprio 3 > > media: Ethernet autoselect (10GbaseLR full-duplex) > > status: active > > ifconfig: ixl2 transceiver: Operation not supported by device > > ixl3: flags=8802 mtu 1500 > > lladdr 00:e0:ed:75:a5:5f > > index 6 priority 0 llprio 3 > > media: Ethernet autoselect > > status: no carrier > > ifconfig: ixl3 transceiver: Input/output error > > > > With "ifconfig ixlX debug" set, I get this on the interface > > > > ixl2: ixl_sff_get_byte(dev 0xa0, reg 0x7f) -> 0003 > > > > Firmware on these are a bit older than the Intel cards that I've seen > > so my first thought is to try updating, I've mailed Silicom to ask them > > if they can provide anything newer (Intel's own downloads say not to > > use them for non Intel-branded cards and I don't really want to > > brick a card..), does anyone have other ideas while I'm waiting to > > hear back from them? > > > > > > OpenBSD 6.7-current (GENERIC.MP) #337: Wed Jul 8 10:37:10 MDT 2020 > > dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP > > real mem = 8464842752 (8072MB) > > avail mem = 8193245184 (7813MB) > > random: good seed from bootblocks > > mpath0 at root > > scsibus0 at mpath0: 256 targets > > mainbus0 at root > > bios0 at mainbus0: SMBIOS rev. 2.8 @ 0xed9b0 (46 entries) > > bios0: vendor American Megatrends Inc. version "1.3" date 03/19/2018 > > bios0: Supermicro Super Server > > acpi0 at bios0: ACPI 5.0 > > acpi0: sleep states S0 S4 S5 > > acpi0: tables DSDT FACP APIC FPDT FIDT SPMI MCFG UEFI DBG2 HPET WDDT SSDT > > SSDT SSDT PRAD DMAR HEST BERT ERST EINJ > > acpi0: wakeup devices IP2P(S4) EHC1(S4) EHC2(S4) RP07(S4) RP08(S4) > > BR1A(S4) BR1B(S4) BR2A(S4) BR2B(S4) BR2C(S4) BR2D(S4) BR3A(S4) BR3B(S4) > > BR3C(S4) BR3D(S4) RP01(S4) [...] > > acpitimer0 at acpi0: 3579545 Hz, 24 bits > > acpimadt0 at acpi0 addr 0xfee0: PC-AT compat > > cpu0 at mainbus0: apid 0 (boot processor) > > cpu0: Intel(R) Xeon(R) CPU D-1518 @ 2.20GHz, 2200.27 MHz, 06-56-03 > > cpu0: > >
Re: silicom X710 ixl, unable to query phy types, no sff
Hi Stuart, Just a suggestion but I have had a difficult time with xl710s Last summer and my vendor advised me to upgrade the firmware on the cards if you upgrade The firmware can be downloaded from here: https://downloadcenter.intel.com/product/93104/Intel-Ethernet-Controller-XL710-BM1 (check the exact chipset you have) You can apply the update by running "nvmupdate64e" and following the prompts. You'll need to restart the machine or power cycle ... Hope this helps, On Wed, 8 Jul 2020 at 23:09, Stuart Henderson wrote: > I have some ixl cards which show "unable to query phy types" at > attach time, and return either EIO or ENODEV if I try fetching sff > pages. > > I booted with SFP+ in all ixl ports and have this: > > ixl0 at pci6 dev 0 function 0 "Intel X710 SFP+" rev 0x02: port 1, FW > 5.0.40043 API 1.5, msix, 4 queues, address 00:e0:ed:75:a5:5c > ixl0: unable to query phy types > ixl1 at pci6 dev 0 function 1 "Intel X710 SFP+" rev 0x02: port 0, FW > 5.0.40043 API 1.5, msix, 4 queues, address 00:e0:ed:75:a5:5d > ixl1: unable to query phy types > ixl2 at pci6 dev 0 function 2 "Intel X710 SFP+" rev 0x02: port 2, FW > 5.0.40043 API 1.5, msix, 4 queues, address 00:e0:ed:75:a5:5e > ixl2: unable to query phy types > ixl3 at pci6 dev 0 function 3 "Intel X710 SFP+" rev 0x02: port 3, FW > 5.0.40043 API 1.5, msix, 4 queues, address 00:e0:ed:75:a5:5f > ixl3: unable to query phy types > > # ifconfig ixl sff > ixl0: flags=8802 mtu 1500 > lladdr 00:e0:ed:75:a5:5c > index 3 priority 0 llprio 3 > media: Ethernet autoselect > status: no carrier > ifconfig: ixl0 transceiver: Input/output error > ixl1: flags=8802 mtu 1500 > lladdr 00:e0:ed:75:a5:5d > index 4 priority 0 llprio 3 > media: Ethernet autoselect > status: no carrier > ifconfig: ixl1 transceiver: Input/output error > ixl2: flags=8802 mtu 1500 > lladdr 00:e0:ed:75:a5:5e > index 5 priority 0 llprio 3 > media: Ethernet autoselect (10GbaseLR full-duplex) > status: active > ifconfig: ixl2 transceiver: Operation not supported by device > ixl3: flags=8802 mtu 1500 > lladdr 00:e0:ed:75:a5:5f > index 6 priority 0 llprio 3 > media: Ethernet autoselect > status: no carrier > ifconfig: ixl3 transceiver: Input/output error > > With "ifconfig ixlX debug" set, I get this on the interface > > ixl2: ixl_sff_get_byte(dev 0xa0, reg 0x7f) -> 0003 > > Firmware on these are a bit older than the Intel cards that I've seen > so my first thought is to try updating, I've mailed Silicom to ask them > if they can provide anything newer (Intel's own downloads say not to > use them for non Intel-branded cards and I don't really want to > brick a card..), does anyone have other ideas while I'm waiting to > hear back from them? > > > OpenBSD 6.7-current (GENERIC.MP) #337: Wed Jul 8 10:37:10 MDT 2020 > dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP > real mem = 8464842752 (8072MB) > avail mem = 8193245184 (7813MB) > random: good seed from bootblocks > mpath0 at root > scsibus0 at mpath0: 256 targets > mainbus0 at root > bios0 at mainbus0: SMBIOS rev. 2.8 @ 0xed9b0 (46 entries) > bios0: vendor American Megatrends Inc. version "1.3" date 03/19/2018 > bios0: Supermicro Super Server > acpi0 at bios0: ACPI 5.0 > acpi0: sleep states S0 S4 S5 > acpi0: tables DSDT FACP APIC FPDT FIDT SPMI MCFG UEFI DBG2 HPET WDDT SSDT > SSDT SSDT PRAD DMAR HEST BERT ERST EINJ > acpi0: wakeup devices IP2P(S4) EHC1(S4) EHC2(S4) RP07(S4) RP08(S4) > BR1A(S4) BR1B(S4) BR2A(S4) BR2B(S4) BR2C(S4) BR2D(S4) BR3A(S4) BR3B(S4) > BR3C(S4) BR3D(S4) RP01(S4) [...] > acpitimer0 at acpi0: 3579545 Hz, 24 bits > acpimadt0 at acpi0 addr 0xfee0: PC-AT compat > cpu0 at mainbus0: apid 0 (boot processor) > cpu0: Intel(R) Xeon(R) CPU D-1518 @ 2.20GHz, 2200.27 MHz, 06-56-03 > cpu0: > FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,SDBG,FMA3,CX16,xTPR,PDCM,PCID,DCA,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,ABM,3DNOWP,PERF,ITSC,FSGSBASE,TSC_ADJUST,BMI1,HLE,AVX2,SMEP,BMI2,ERMS,INVPCID,RTM,PQM,RDSEED,ADX,SMAP,PT,MD_CLEAR,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,MELTDOWN > cpu0: 256KB 64b/line 8-way L2 cache > cpu0: TSC skew=0 observed drift=0 > 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.2, IBE > cpu1 at mainbus0: apid 2 (application processor) > cpu1: Intel(R) Xeon(R) CPU D-1518 @ 2.20GHz, 2200.01 MHz, 06-56-03 > cpu1: >
Re: disable libc sys wrappers?
Hi Mark, Mark Kettenis wrote on Thu, Jul 09, 2020 at 07:59:25PM +0200: > Ingo Schwrze wrote: >> Now that i look at that, and at what you said previously, is it even >> plausible that some user ever wants "-t c" ktracing but does >> specifically *not* want to see clock_gettime(2) and friends? [...] > Yes. If I ktrace something like chromium I really don't want to see > the thousands of pointless clock_gettime(2) calls. Fair enough. Together with what deraadt@ explained, it probably is -T, then. >> Regarding the LD_ prefix, clock_gettime(2) and gettimeofday(2) >> are in and , respectively, but maybe a TIME_ >> prefix would be too specific. Sure, it is the "time" sublibrary >> of libc, but "TIME_" wouldn't really make it apparent that it >> is related to libc at all. >> >> So, should it instead be something like: >> >> LIBC_KTRACE_GETTIME ? > I wonder if it should start with an underscore instead to indicate > that the variable is not for public consumption. _KTRACE_TIME would > do the job for me. We can always rename it if we discover another use > case apart from ktrace. Sounds like user interface is almost finished; _KTRACE_TIME sounds nicely concise, yet still properly specific. Yours, Ingo
Re: disable libc sys wrappers?
> Date: Thu, 9 Jul 2020 19:43:52 +0200 > From: Ingo Schwarze > > Hi Theo, > > Theo de Raadt wrote on Thu, Jul 09, 2020 at 11:08:38AM -0600: > > Ingo Schwarze wrote: > > >> So, what about > >> LD_KTRACE_GETTIME > >> or a similar environment variable name? > > > That naming seems logical. > > > > If it is mostly hidden behind a ktrace flag (-T ?) then I think > > we're in good shape. > > Technically, the implementation of the new ktrace(1) flag will be > totally different from the implementation of the existing ktrace -t > flags. But from the user perspective, the purpose of the new flag > is just to "put some more information into the dump file", so > shouldn't it be just another -t letter? Like, > > c trace system calls > T trace clock_gettime(2) and gettimeofday(2) > > or similar? > > Now that i look at that, and at what you said previously, is it even > plausible that some user ever wants "-t c" ktracing but does > specifically *not* want to see clock_gettime(2) and friends? > > If "i want system call ktracing" logically more or less implies "i > also want to see clock_gettime and friends", then maybe we do not > need a new command line flag at all, not even a sub-flag, and can > instead just let "-t c" enable that, too? Yes. If I ktrace something like chromium I really don't want to see the thousands of pointless clock_gettime(2) calls. > > Regarding the LD_ prefix, clock_gettime(2) and gettimeofday(2) > are in and , respectively, but maybe a TIME_ > prefix would be too specific. Sure, it is the "time" sublibrary > of libc, but "TIME_" wouldn't really make it apparent that it > is related to libc at all. > > So, should it instead be something like: > > LIBC_KTRACE_GETTIME ? I wonder if it should start with an underscore instead to indicate that the variable is not for public consumption. _KTRACE_TIME would do the job for me. We can always rename it if we discover another use case apart from ktrace.
Re: disable libc sys wrappers?
Ingo Schwarze wrote: > Hi Theo, > > Theo de Raadt wrote on Thu, Jul 09, 2020 at 11:08:38AM -0600: > > Ingo Schwarze wrote: > > >> So, what about > >> LD_KTRACE_GETTIME > >> or a similar environment variable name? > > > That naming seems logical. > > > > If it is mostly hidden behind a ktrace flag (-T ?) then I think > > we're in good shape. > > Technically, the implementation of the new ktrace(1) flag will be > totally different from the implementation of the existing ktrace -t > flags. But from the user perspective, the purpose of the new flag > is just to "put some more information into the dump file", so > shouldn't it be just another -t letter? Like, > > c trace system calls > T trace clock_gettime(2) and gettimeofday(2) > > or similar? Every single one of the -t sub-optionsd are flags passed to the kernel, and the kernel evaluates what to export. This is completely not like -t. > Now that i look at that, and at what you said previously, is it even > plausible that some user ever wants "-t c" ktracing but does > specifically *not* want to see clock_gettime(2) and friends? Sorry, that isn't how this works. > Unless i'm mistaken, we don't provide a way either to say "i want > to see system calls, except that i don't want to see chdir(2), > chmod(2), getuid(2), and mprotect(2)." And that is not what is happening here. This is a totally new condition where libc has a way to "skip" doing "calls to system calls" but we need a way to expose them *BECAUSE THE DEVELOPMENT PROCESS NEEDS THE VISIBILITY*.
Re: disable libc sys wrappers?
Hi Theo, Theo de Raadt wrote on Thu, Jul 09, 2020 at 11:08:38AM -0600: > Ingo Schwarze wrote: >> So, what about >> LD_KTRACE_GETTIME >> or a similar environment variable name? > That naming seems logical. > > If it is mostly hidden behind a ktrace flag (-T ?) then I think > we're in good shape. Technically, the implementation of the new ktrace(1) flag will be totally different from the implementation of the existing ktrace -t flags. But from the user perspective, the purpose of the new flag is just to "put some more information into the dump file", so shouldn't it be just another -t letter? Like, c trace system calls T trace clock_gettime(2) and gettimeofday(2) or similar? Now that i look at that, and at what you said previously, is it even plausible that some user ever wants "-t c" ktracing but does specifically *not* want to see clock_gettime(2) and friends? If "i want system call ktracing" logically more or less implies "i also want to see clock_gettime and friends", then maybe we do not need a new command line flag at all, not even a sub-flag, and can instead just let "-t c" enable that, too? Keeping the user interface small is often good. Needing only one sub-flag rather than two to see all system calls doesn't seem that bad, either. Unless i'm mistaken, we don't provide a way either to say "i want to see system calls, except that i don't want to see chdir(2), chmod(2), getuid(2), and mprotect(2)." Regarding the LD_ prefix, clock_gettime(2) and gettimeofday(2) are in and , respectively, but maybe a TIME_ prefix would be too specific. Sure, it is the "time" sublibrary of libc, but "TIME_" wouldn't really make it apparent that it is related to libc at all. So, should it instead be something like: LIBC_KTRACE_GETTIME ? Yours, Ingo
Re: disable libc sys wrappers?
Ingo Schwarze wrote: > Hi Theo, > > Theo de Raadt wrote on Thu, Jul 09, 2020 at 09:47:26AM -0600: > > > This time, they become invisible. > [...] > > There are many circumstances where ltrace is not suitable. > [...] > > We fiddle with programs all the time, to inspect them. > > Fair enough, then. > > The following variables already exist according to man -ak Ev~'\ > * LD_PRELOAD > * LD_LIBRARY_PATH > * LD_BIND_NOW > * LD_TRACE_LOADED_OBJECTS > * LD_DEBUG > > I susspect the name should: > > * start with "LD_" > * contain "TIME" > * contain "SYSCALL" or "KTRACE" Actually the LD_ in those names refers to ld.so, but ld.so is not making this decision. libc is. It also works for static binaries, because the checking position is inside libc initialization. That said, I don't like the originally proposed prefix STDIO_
Re: disable libc sys wrappers?
Ingo Schwarze wrote: > Hi Theo, > > Theo de Raadt wrote on Thu, Jul 09, 2020 at 09:47:26AM -0600: > > > This time, they become invisible. > [...] > > There are many circumstances where ltrace is not suitable. > [...] > > We fiddle with programs all the time, to inspect them. > > Fair enough, then. > > The following variables already exist according to man -ak Ev~'\ > * LD_PRELOAD > * LD_LIBRARY_PATH > * LD_BIND_NOW > * LD_TRACE_LOADED_OBJECTS > * LD_DEBUG > > I susspect the name should: > > * start with "LD_" > * contain "TIME" > * contain "SYSCALL" or "KTRACE" > > If i understand correctly, what the user really wants is that > time-related API calls appear in ktrace; that they cause system > calls is merely how that is implemented. Consequently, from the > user perspective, "KTRACE" is more relevant than "SYSCALL". > It is also clearer what it does; i assume using the word "SYSCALL" > would require a lengthy wording like "FORCE_SYSCALL". > > So, what about > > LD_KTRACE_GETTIME > > or a similar environment variable name? That naming seems logical. If it is mostly hidden behind a ktrace flag (-T ?) then I think we're in good shape.
Re: disable libc sys wrappers?
Hi Theo, Theo de Raadt wrote on Thu, Jul 09, 2020 at 09:47:26AM -0600: > This time, they become invisible. [...] > There are many circumstances where ltrace is not suitable. [...] > We fiddle with programs all the time, to inspect them. Fair enough, then. The following variables already exist according to man -ak Ev~'\
[patch] usbdevs: add Dell DW5821e LTE
I just purchased a Dell Latitude 7300 which I ordered with a Dell DW5821e Snapdragon X20 LTE device. Attached is a patch to add it to usbdevs. I am working on getting it to work with umb(4) but this is a needed step as I understand it. Also attached is my usbdevs output for this device. Thank you. Bryan addr 02: 413c:81d7 Dell Inc., DW5821e Snapdragon X20 LTE super speed, power 224 mA, config 1, rev 3.18, iSerial 0123456789ABCDEF driver: uhidev0 driver: ugen0 Index: sys/dev/usb/usbdevs === RCS file: /cvs/src/sys/dev/usb/usbdevs,v retrieving revision 1.718 diff -u -p -r1.718 usbdevs --- sys/dev/usb/usbdevs 6 Jul 2020 10:35:42 - 1.718 +++ sys/dev/usb/usbdevs 8 Jul 2020 01:04:46 - @@ -1490,6 +1490,7 @@ product DELL PRISM_GT_2 0x8104 PrismGT product DELL W5500 0x8115 W5500 HSDPA product DELL U740 0x8135 Dell U740 CDMA product DELL EU870D0x8138 EU870D HSDPA +product DELL DW5821E 0x81d7 DW5821e LTE product DELL DW700 0x9500 DW700 GPS product DELL2 UPS 0x UPS
Re: arm64 usertc
On Thu, Jul 09, 2020 at 10:35:46AM +0200, Mark Kettenis wrote:
>
> Here is the arm64 version. Again I've taken the approach of copying
> the kernel timecounter code verbatim. Technically we don't need the
> Cortex-A73 errata workaround here since the timecounter only uses the
> low 32 bits. But that is true for the kernel as well! If people
> think it is worth avoiding this, I'd propose to introduce
> agtimer_readcnt32() and use that for the timecounter in both the
> kernel and userland.
I think keeping it simple in userspace is preferable. We only want the
lower 32 bits, so let's only work with those bits.
While discussing the powerpc usertc code Theo pointed out to me
(again) that you can get a context switch at any moment in userspace.
Multiple reads may yield results from multiple cores.
Said another way...
> @@ -18,4 +18,39 @@
> #include
> #include
>
> -int (*const _tc_get_timecount)(struct timekeep *, u_int *) = NULL;
> +static inline uint64_t
> +agtimer_readcnt64(void)
> +{
> + uint64_t val0, val1;
> +
> + /*
> + * Work around Cortex-A73 errata 858921, where there is a
> + * one-cycle window where the read might return the old value
> + * for the low 32 bits and the new value for the high 32 bits
> + * upon roll-over of the low 32 bits.
> + */
> + __asm volatile("isb" : : : "memory");
> + __asm volatile("mrs %x0, CNTVCT_EL0" : "=r" (val0));
Hypothetically, what might happen if you were switched *here*?
Between these two instructions?
> + __asm volatile("mrs %x0, CNTVCT_EL0" : "=r" (val1));
> + return ((val0 ^ val1) & 0x1ULL) ? val0 : val1;
> +}
Re: silicom X710 ixl, unable to query phy types, no sff
David Gwynne wrote: > so the problem is the older api doenst support the "get phy types" > command, or the sff commands. should we silence the "get phy types" > error output? is there a better errno to use when the sff command > isn't supported? should we add something to the manpage? should that > something be "i'm not angry, just disappointed"? I don't think it is the errno that matters, it is this: > ifconfig: ixl0 transceiver: Input/output error Way I read the code, there's no other cause for EIO in that place in ifconfig. Why print the errno translation. Why not just something vague like this: ixl3: flags=8802 mtu 1500 lladdr 00:e0:ed:75:a5:5f index 6 priority 0 llprio 3 media: Ethernet autoselect (10GbaseLR full-duplex) status: active transceiver: cannot determine Or something like that. Consider it a soft error.
Re: disable libc sys wrappers?
Ingo Schwarze wrote: > Hi, > > i wonder whether there is a layering violation going on here. > > From the user perspective, whether an API call is a syscall or a > mere library function doesn't make any difference, it's an > implementation detail. >From the developer's perspective it is a HUGE DEAL, because ktrace now doesn't show calls to gettimeofday / clock_gettime calls in the code most often traced (event loops). > API calls have often moved from being library > functions to syscall and vice versa, witnessed by the blurry line > between sections 2 and 3 in the manual (which is not a problem at > all). When that happened, they remained visible. This time, they become invisible. o you say the user wants to see whether their program calls > some time-related API functions, and in the past, ktrace was useful > for that. On a machine where syscalls for the purpose are no longer > needed due to pirofti@'s optimization, does it really make sense to > force useless syscalls just to be able to see the API calls in ktrace? > Wouldn't it make more sense to instead simply use ltrace(1), which IIUC > is intended for just that purpose, tracing API calls? There are many circumstances where ltrace is not suitable. It exposes the wrong interface, and fails to show the parameters in the expected fashion. > Someone said setting up ltrace(1) is kind of harder, while ktrace(1) > is very easy to use (i can confirm the latter, i use ktrace regularly). > So maybe the real problem is to make sure ltrace(1) is about as easy > to use as ktrace(1)? (Not sure what exactly the problem(s) with ltrace > usability are, if any, i didn't use it much so far.) I don't want to see the layers of functions, which means I don't want to use ltrace. I want ktrace to be useful. > It feels odd that a user would fiddle with the internal way how API > calls are implemented, in particular using something as scary as > environment variables, just to *inspect* what their program is doing... We fiddle with programs all the time, to inspect them. We add debug printf's! How can doing this in a more subtle way be harmful?
Re: disable libc sys wrappers?
Hi, i wonder whether there is a layering violation going on here. >From the user perspective, whether an API call is a syscall or a mere library function doesn't make any difference, it's an implementation detail. API calls have often moved from being library functions to syscall and vice versa, witnessed by the blurry line between sections 2 and 3 in the manual (which is not a problem at all). So you say the user wants to see whether their program calls some time-related API functions, and in the past, ktrace was useful for that. On a machine where syscalls for the purpose are no longer needed due to pirofti@'s optimization, does it really make sense to force useless syscalls just to be able to see the API calls in ktrace? Wouldn't it make more sense to instead simply use ltrace(1), which IIUC is intended for just that purpose, tracing API calls? Someone said setting up ltrace(1) is kind of harder, while ktrace(1) is very easy to use (i can confirm the latter, i use ktrace regularly). So maybe the real problem is to make sure ltrace(1) is about as easy to use as ktrace(1)? (Not sure what exactly the problem(s) with ltrace usability are, if any, i didn't use it much so far.) It feels odd that a user would fiddle with the internal way how API calls are implemented, in particular using something as scary as environment variables, just to *inspect* what their program is doing... And that they would actually change what their program is doing just for the purpose of that inspection... Obviously, i don't object to any of this, and i may be totally wrong trying to think about something so deep down in the system. I'm just wondering... Yours, Ingo
Re: pshared semaphores
Mark Kettenis wrote:
> > From: "Ted Unangst"
> > Date: Thu, 09 Jul 2020 11:07:02 -0400
> >
> > On 2020-07-08, Mark Kettenis wrote:
> > > > From: "Ted Unangst"
> > > > Date: Wed, 08 Jul 2020 05:20:23 -0400
> > > >
> > > > On 2020-07-08, Ted Unangst wrote:
> > > > > I think this makes sem_init(pshared) work.
> > > >
> > > > Whoops, need more context to include the header file changes.
> > >
> > > It is a bit of a pity that we have to expose the internals here, but I
> > > don't see an easy way to avoid that, especially since hppa requires
> > > 16-byte alignment. At least doesn't do any
> > > namespace pollution as I believe a single underscore is enough here as
> > > everything is in file scope?
> > >
> > > This will require a libpthread major bump, and those are really
> > > painful! So I'm not sure we should do this just for pshared
> > > semaphores which hardly anybody uses.
> > >
> > > I wonder if we do this, should we include some additional padding in
> > > the struct for future expansion?
> >
> > We can also expose only a padded struct sem { int _pad[4]; } or so.
> > That's a bit more cumbersome, and we need to be careful. But certainly
> > possible.
>
> Tricky since _atomic_lock is actually an array on hppa and need
> 16-byte alignment. And the lock is actually used on hppa.
Yes that's a good point:
If you pad for the future, use the maximum-sized types, thereby trying to
anticipate the future.
It might not be enough for the bizzare hppa case, but it might help other
architectures...
Re: disable libc sys wrappers?
> From: "Theo de Raadt" > Date: Thu, 09 Jul 2020 09:13:24 -0600 > > Ted Unangst wrote: > > > On 2020-07-08, Theo de Raadt wrote: > > > I think we need something like this. > > > > > > Documenting it will be a challenge. > > > > > > I really don't like the name as is too generic, when the control is only > > > for a narrow set of "current time" system calls. > > > > I thought I'd start with something, but lots of questions. > > > > Should it be per wrapper? > > Perhaps not named per syscall, but named per grouping. This causes > direct syscalls for time retrieval. Can you find a name for that? > > > I know in the past we've had some similar > > conversations about eliminating syscalls (open/openat) > > I don't think we'll be doing that, because it doesn't really make the > world any better and, as is evident with time handling mangles ktrace > too much. > > > Initial thought is it's easier to make one button, and then document > > it in ktrace perhaps? > > Probably in kdump also. > > Hang on. Do people ever want to force time calls, outside of ktrace? > I doubt it. Should ktrace maybe have a flag, similar to -B with LD_BIND_NOW, > which sets the new environment variable? Maybe -T? The problem smells very > similar to the root cause for LD_BIND_NOW setting.. Yes. I think that makes lot of sense. And I don't think we need to document the envionment variable in that case.
Re: pshared semaphores
> From: "Ted Unangst"
> Date: Thu, 09 Jul 2020 11:07:02 -0400
>
> On 2020-07-08, Mark Kettenis wrote:
> > > From: "Ted Unangst"
> > > Date: Wed, 08 Jul 2020 05:20:23 -0400
> > >
> > > On 2020-07-08, Ted Unangst wrote:
> > > > I think this makes sem_init(pshared) work.
> > >
> > > Whoops, need more context to include the header file changes.
> >
> > It is a bit of a pity that we have to expose the internals here, but I
> > don't see an easy way to avoid that, especially since hppa requires
> > 16-byte alignment. At least doesn't do any
> > namespace pollution as I believe a single underscore is enough here as
> > everything is in file scope?
> >
> > This will require a libpthread major bump, and those are really
> > painful! So I'm not sure we should do this just for pshared
> > semaphores which hardly anybody uses.
> >
> > I wonder if we do this, should we include some additional padding in
> > the struct for future expansion?
>
> We can also expose only a padded struct sem { int _pad[4]; } or so.
> That's a bit more cumbersome, and we need to be careful. But certainly
> possible.
Tricky since _atomic_lock is actually an array on hppa and need
16-byte alignment. And the lock is actually used on hppa.
On the other hand, opaqueness would allow us to ditch the lock member
on architectures that use the futex.
> If this is useful, I think we should also consider removing the
> indirection from pthread and mutex, etc. This is more work, but I
> don't mind doing it all at once. Semaphore is just first priority.
Yes. I think the situation where pshared semaphores work pshared
mutexes don't work would be a little bit awkward.
> (I think the mail issues are better now, thanks everyone.)
Looks like it.
Re: disable libc sys wrappers?
Ted Unangst wrote: > On 2020-07-08, Theo de Raadt wrote: > > I think we need something like this. > > > > Documenting it will be a challenge. > > > > I really don't like the name as is too generic, when the control is only > > for a narrow set of "current time" system calls. > > I thought I'd start with something, but lots of questions. > > Should it be per wrapper? Perhaps not named per syscall, but named per grouping. This causes direct syscalls for time retrieval. Can you find a name for that? > I know in the past we've had some similar > conversations about eliminating syscalls (open/openat) I don't think we'll be doing that, because it doesn't really make the world any better and, as is evident with time handling mangles ktrace too much. > Initial thought is it's easier to make one button, and then document > it in ktrace perhaps? Probably in kdump also. Hang on. Do people ever want to force time calls, outside of ktrace? I doubt it. Should ktrace maybe have a flag, similar to -B with LD_BIND_NOW, which sets the new environment variable? Maybe -T? The problem smells very similar to the root cause for LD_BIND_NOW setting..
Re: pshared semaphores
On 2020-07-08, Mark Kettenis wrote:
> > From: "Ted Unangst"
> > Date: Wed, 08 Jul 2020 05:20:23 -0400
> >
> > On 2020-07-08, Ted Unangst wrote:
> > > I think this makes sem_init(pshared) work.
> >
> > Whoops, need more context to include the header file changes.
>
> It is a bit of a pity that we have to expose the internals here, but I
> don't see an easy way to avoid that, especially since hppa requires
> 16-byte alignment. At least doesn't do any
> namespace pollution as I believe a single underscore is enough here as
> everything is in file scope?
>
> This will require a libpthread major bump, and those are really
> painful! So I'm not sure we should do this just for pshared
> semaphores which hardly anybody uses.
>
> I wonder if we do this, should we include some additional padding in
> the struct for future expansion?
We can also expose only a padded struct sem { int _pad[4]; } or so.
That's a bit more cumbersome, and we need to be careful. But certainly
possible.
If this is useful, I think we should also consider removing the
indirection from pthread and mutex, etc. This is more work, but I
don't mind doing it all at once. Semaphore is just first priority.
(I think the mail issues are better now, thanks everyone.)
Re: disable libc sys wrappers?
On 2020-07-08, Theo de Raadt wrote: > I think we need something like this. > > Documenting it will be a challenge. > > I really don't like the name as is too generic, when the control is only > for a narrow set of "current time" system calls. I thought I'd start with something, but lots of questions. Should it be per wrapper? I know in the past we've had some similar conversations about eliminating syscalls (open/openat) and I imagine there will be future instances. Initial thought is it's easier to make one button, and then document it in ktrace perhaps? But we can also add per function options, and document them in the appropriate pages.
Re: bridge(4) shouldn't try to create new interfaces when i make a typo
On Thu, Jul 9, 2020 at 3:31 AM Klemens Nanni wrote: > > On Thu, Jul 09, 2020 at 05:08:01PM +1000, David Gwynne wrote: > > if i accidentally `ifconfig bridge add gre0` instead of egre0, having > > bridge create gre0 and then not like it is not what i expect to happen. > > especially when it leaves me with an extra gre0 interface lying around > > afterwards. > > > > i can appreciate that this was trying to be helpful when you wanted > > to add virtual interfaces to a bridge on boot, but that was before > > netstart(8) created all the interfaces with config files up front, before > > it then goes through and runs the config for them. > I agree. > > OK kn > this will force the use of create beforehand ? or ifconfig bridge0 up will still work ? because script in the wild may not do the create first. -- -- - Knowing is not enough; we must apply. Willing is not enough; we must do
Re: silicom X710 ixl, unable to query phy types, no sff
On 2020/07/09 22:57, David Gwynne wrote:
> ok.
>
> so the problem is the older api doenst support the "get phy types" command,
> or the sff commands.
yes, looks like it.
> should we silence the "get phy types" error output?
I think that makes sense.
> is there a better errno to use when the sff command isn't supported? should
> we add something to the manpage? should that something be "i'm not angry,
> just disappointed"?
linux does this in the kernel driver (i40e_ethdev.c)
static int i40e_get_module_info(struct rte_eth_dev *dev,
struct rte_dev_module_info *modinfo)
{
struct i40e_hw *hw = I40E_DEV_PRIVATE_TO_HW(dev->data->dev_private);
uint32_t sff8472_comp = 0;
uint32_t sff8472_swap = 0;
uint32_t sff8636_rev = 0;
i40e_status status;
uint32_t type = 0;
/* Check if firmware supports reading module EEPROM. */
if (!(hw->flags & I40E_HW_FLAG_AQ_PHY_ACCESS_CAPABLE)) {
PMD_DRV_LOG(ERR,
"Module EEPROM memory read not supported. "
"Please update the NVM image.\n");
return -EINVAL;
}
reported by ethtool like this
# /usr/sbin/ethtool --module-info ens1f2
Cannot get module EEPROM information: Invalid argument
btw, Silicom didn't recognise the firmware version as we print it (5.0.40043),
ethtool and the intel tools display it like this instead
# /usr/sbin/ethtool -i ens1f2
driver: i40e
version: 2.3.2-k
firmware-version: 5.02 0x80002248 0.0.0
expansion-rom-version:
bus-info: :05:00.2
supports-statistics: yes
supports-test: yes
supports-eeprom-access: yes
supports-register-dump: yes
supports-priv-flags: yes
>
> > On 9 Jul 2020, at 10:36 pm, Stuart Henderson wrote:
> >
> > Update on this: Silicom support responded promptly, asked sensible
> > questions, didn't immediately bail on the fact that I'm not running a
> > supported OS, and prepared an update (to run under Linux but the
> > Debian live image worked fine for this).
> >
> > ixl0 at pci6 dev 0 function 0 "Intel X710 SFP+" rev 0x02: port 1, FW
> > 7.0.50775 API 1.8, msix, 4 queues, address 00:e0:ed:75:a5:5c
> > ixl1 at pci6 dev 0 function 1 "Intel X710 SFP+" rev 0x02: port 0, FW
> > 7.0.50775 API 1.8, msix, 4 queues, address 00:e0:ed:75:a5:5d
> > ixl2 at pci6 dev 0 function 2 "Intel X710 SFP+" rev 0x02: port 2, FW
> > 7.0.50775 API 1.8, msix, 4 queues, address 00:e0:ed:75:a5:5e
> > ixl3 at pci6 dev 0 function 3 "Intel X710 SFP+" rev 0x02: port 3, FW
> > 7.0.50775 API 1.8, msix, 4 queues, address 00:e0:ed:75:a5:5f
> >
> > ixl3: flags=8802 mtu 1500
> >lladdr 00:e0:ed:75:a5:5f
> >index 6 priority 0 llprio 3
> >media: Ethernet autoselect (10GbaseLR full-duplex)
> >status: active
> >transceiver: SFP LC, 1310 nm, 10.0km SMF
> >model: FLEXOPTIX P.1396.10 rev A
> >serial: F78R21S, date: 2018-07-09
> >voltage: 3.30 V, bias current: 32.07 mA
> >temp: 29.43 C (low -25.00 C, high 90.00 C)
> >tx: -2.63 dBm (low -7.00 dBm, high 2.50 dBm)
> >rx: -4.75 dBm (low -16.00 dBm, high 1.00 dBm)
> >
> >
> >
> > On 2020/07/08 22:59, Stuart Henderson wrote:
> >> I have some ixl cards which show "unable to query phy types" at
> >> attach time, and return either EIO or ENODEV if I try fetching sff
> >> pages.
> >>
> >> I booted with SFP+ in all ixl ports and have this:
> >>
> >> ixl0 at pci6 dev 0 function 0 "Intel X710 SFP+" rev 0x02: port 1, FW
> >> 5.0.40043 API 1.5, msix, 4 queues, address 00:e0:ed:75:a5:5c
> >> ixl0: unable to query phy types
> >> ixl1 at pci6 dev 0 function 1 "Intel X710 SFP+" rev 0x02: port 0, FW
> >> 5.0.40043 API 1.5, msix, 4 queues, address 00:e0:ed:75:a5:5d
> >> ixl1: unable to query phy types
> >> ixl2 at pci6 dev 0 function 2 "Intel X710 SFP+" rev 0x02: port 2, FW
> >> 5.0.40043 API 1.5, msix, 4 queues, address 00:e0:ed:75:a5:5e
> >> ixl2: unable to query phy types
> >> ixl3 at pci6 dev 0 function 3 "Intel X710 SFP+" rev 0x02: port 3, FW
> >> 5.0.40043 API 1.5, msix, 4 queues, address 00:e0:ed:75:a5:5f
> >> ixl3: unable to query phy types
> >>
> >> # ifconfig ixl sff
> >> ixl0: flags=8802 mtu 1500
> >>lladdr 00:e0:ed:75:a5:5c
> >>index 3 priority 0 llprio 3
> >>media: Ethernet autoselect
> >>status: no carrier
> >> ifconfig: ixl0 transceiver: Input/output error
> >> ixl1: flags=8802 mtu 1500
> >>lladdr 00:e0:ed:75:a5:5d
> >>index 4 priority 0 llprio 3
> >>media: Ethernet autoselect
> >>status: no carrier
> >> ifconfig: ixl1 transceiver: Input/output error
> >> ixl2: flags=8802 mtu 1500
> >>lladdr 00:e0:ed:75:a5:5e
> >>index 5 priority 0 llprio 3
> >>media: Ethernet autoselect (10GbaseLR full-duplex)
> >>status: active
> >> ifconfig: ixl2 transceiver: Operation not supported by device
> >> ixl3: flags=8802 mtu 1500
> >>lladdr 00:e0:ed:75:a5:5f
> >>
Re: silicom X710 ixl, unable to query phy types, no sff
ok. so the problem is the older api doenst support the "get phy types" command, or the sff commands. should we silence the "get phy types" error output? is there a better errno to use when the sff command isn't supported? should we add something to the manpage? should that something be "i'm not angry, just disappointed"? > On 9 Jul 2020, at 10:36 pm, Stuart Henderson wrote: > > Update on this: Silicom support responded promptly, asked sensible > questions, didn't immediately bail on the fact that I'm not running a > supported OS, and prepared an update (to run under Linux but the > Debian live image worked fine for this). > > ixl0 at pci6 dev 0 function 0 "Intel X710 SFP+" rev 0x02: port 1, FW > 7.0.50775 API 1.8, msix, 4 queues, address 00:e0:ed:75:a5:5c > ixl1 at pci6 dev 0 function 1 "Intel X710 SFP+" rev 0x02: port 0, FW > 7.0.50775 API 1.8, msix, 4 queues, address 00:e0:ed:75:a5:5d > ixl2 at pci6 dev 0 function 2 "Intel X710 SFP+" rev 0x02: port 2, FW > 7.0.50775 API 1.8, msix, 4 queues, address 00:e0:ed:75:a5:5e > ixl3 at pci6 dev 0 function 3 "Intel X710 SFP+" rev 0x02: port 3, FW > 7.0.50775 API 1.8, msix, 4 queues, address 00:e0:ed:75:a5:5f > > ixl3: flags=8802 mtu 1500 >lladdr 00:e0:ed:75:a5:5f >index 6 priority 0 llprio 3 >media: Ethernet autoselect (10GbaseLR full-duplex) >status: active >transceiver: SFP LC, 1310 nm, 10.0km SMF >model: FLEXOPTIX P.1396.10 rev A >serial: F78R21S, date: 2018-07-09 >voltage: 3.30 V, bias current: 32.07 mA >temp: 29.43 C (low -25.00 C, high 90.00 C) >tx: -2.63 dBm (low -7.00 dBm, high 2.50 dBm) >rx: -4.75 dBm (low -16.00 dBm, high 1.00 dBm) > > > > On 2020/07/08 22:59, Stuart Henderson wrote: >> I have some ixl cards which show "unable to query phy types" at >> attach time, and return either EIO or ENODEV if I try fetching sff >> pages. >> >> I booted with SFP+ in all ixl ports and have this: >> >> ixl0 at pci6 dev 0 function 0 "Intel X710 SFP+" rev 0x02: port 1, FW >> 5.0.40043 API 1.5, msix, 4 queues, address 00:e0:ed:75:a5:5c >> ixl0: unable to query phy types >> ixl1 at pci6 dev 0 function 1 "Intel X710 SFP+" rev 0x02: port 0, FW >> 5.0.40043 API 1.5, msix, 4 queues, address 00:e0:ed:75:a5:5d >> ixl1: unable to query phy types >> ixl2 at pci6 dev 0 function 2 "Intel X710 SFP+" rev 0x02: port 2, FW >> 5.0.40043 API 1.5, msix, 4 queues, address 00:e0:ed:75:a5:5e >> ixl2: unable to query phy types >> ixl3 at pci6 dev 0 function 3 "Intel X710 SFP+" rev 0x02: port 3, FW >> 5.0.40043 API 1.5, msix, 4 queues, address 00:e0:ed:75:a5:5f >> ixl3: unable to query phy types >> >> # ifconfig ixl sff >> ixl0: flags=8802 mtu 1500 >>lladdr 00:e0:ed:75:a5:5c >>index 3 priority 0 llprio 3 >>media: Ethernet autoselect >>status: no carrier >> ifconfig: ixl0 transceiver: Input/output error >> ixl1: flags=8802 mtu 1500 >>lladdr 00:e0:ed:75:a5:5d >>index 4 priority 0 llprio 3 >>media: Ethernet autoselect >>status: no carrier >> ifconfig: ixl1 transceiver: Input/output error >> ixl2: flags=8802 mtu 1500 >>lladdr 00:e0:ed:75:a5:5e >>index 5 priority 0 llprio 3 >>media: Ethernet autoselect (10GbaseLR full-duplex) >>status: active >> ifconfig: ixl2 transceiver: Operation not supported by device >> ixl3: flags=8802 mtu 1500 >>lladdr 00:e0:ed:75:a5:5f >>index 6 priority 0 llprio 3 >>media: Ethernet autoselect >>status: no carrier >> ifconfig: ixl3 transceiver: Input/output error >> >> With "ifconfig ixlX debug" set, I get this on the interface >> >> ixl2: ixl_sff_get_byte(dev 0xa0, reg 0x7f) -> 0003 >> >> Firmware on these are a bit older than the Intel cards that I've seen >> so my first thought is to try updating, I've mailed Silicom to ask them >> if they can provide anything newer (Intel's own downloads say not to >> use them for non Intel-branded cards and I don't really want to >> brick a card..), does anyone have other ideas while I'm waiting to >> hear back from them? >> >> >> OpenBSD 6.7-current (GENERIC.MP) #337: Wed Jul 8 10:37:10 MDT 2020 >>dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP >> real mem = 8464842752 (8072MB) >> avail mem = 8193245184 (7813MB) >> random: good seed from bootblocks >> mpath0 at root >> scsibus0 at mpath0: 256 targets >> mainbus0 at root >> bios0 at mainbus0: SMBIOS rev. 2.8 @ 0xed9b0 (46 entries) >> bios0: vendor American Megatrends Inc. version "1.3" date 03/19/2018 >> bios0: Supermicro Super Server >> acpi0 at bios0: ACPI 5.0 >> acpi0: sleep states S0 S4 S5 >> acpi0: tables DSDT FACP APIC FPDT FIDT SPMI MCFG UEFI DBG2 HPET WDDT SSDT >> SSDT SSDT PRAD DMAR HEST BERT ERST EINJ >> acpi0: wakeup devices IP2P(S4) EHC1(S4) EHC2(S4) RP07(S4) RP08(S4) BR1A(S4) >> BR1B(S4) BR2A(S4) BR2B(S4) BR2C(S4) BR2D(S4) BR3A(S4) BR3B(S4) BR3C(S4) >> BR3D(S4) RP01(S4) [...] >> acpitimer0 at acpi0:
Re: silicom X710 ixl, unable to query phy types, no sff
Update on this: Silicom support responded promptly, asked sensible questions, didn't immediately bail on the fact that I'm not running a supported OS, and prepared an update (to run under Linux but the Debian live image worked fine for this). ixl0 at pci6 dev 0 function 0 "Intel X710 SFP+" rev 0x02: port 1, FW 7.0.50775 API 1.8, msix, 4 queues, address 00:e0:ed:75:a5:5c ixl1 at pci6 dev 0 function 1 "Intel X710 SFP+" rev 0x02: port 0, FW 7.0.50775 API 1.8, msix, 4 queues, address 00:e0:ed:75:a5:5d ixl2 at pci6 dev 0 function 2 "Intel X710 SFP+" rev 0x02: port 2, FW 7.0.50775 API 1.8, msix, 4 queues, address 00:e0:ed:75:a5:5e ixl3 at pci6 dev 0 function 3 "Intel X710 SFP+" rev 0x02: port 3, FW 7.0.50775 API 1.8, msix, 4 queues, address 00:e0:ed:75:a5:5f ixl3: flags=8802 mtu 1500 lladdr 00:e0:ed:75:a5:5f index 6 priority 0 llprio 3 media: Ethernet autoselect (10GbaseLR full-duplex) status: active transceiver: SFP LC, 1310 nm, 10.0km SMF model: FLEXOPTIX P.1396.10 rev A serial: F78R21S, date: 2018-07-09 voltage: 3.30 V, bias current: 32.07 mA temp: 29.43 C (low -25.00 C, high 90.00 C) tx: -2.63 dBm (low -7.00 dBm, high 2.50 dBm) rx: -4.75 dBm (low -16.00 dBm, high 1.00 dBm) On 2020/07/08 22:59, Stuart Henderson wrote: > I have some ixl cards which show "unable to query phy types" at > attach time, and return either EIO or ENODEV if I try fetching sff > pages. > > I booted with SFP+ in all ixl ports and have this: > > ixl0 at pci6 dev 0 function 0 "Intel X710 SFP+" rev 0x02: port 1, FW > 5.0.40043 API 1.5, msix, 4 queues, address 00:e0:ed:75:a5:5c > ixl0: unable to query phy types > ixl1 at pci6 dev 0 function 1 "Intel X710 SFP+" rev 0x02: port 0, FW > 5.0.40043 API 1.5, msix, 4 queues, address 00:e0:ed:75:a5:5d > ixl1: unable to query phy types > ixl2 at pci6 dev 0 function 2 "Intel X710 SFP+" rev 0x02: port 2, FW > 5.0.40043 API 1.5, msix, 4 queues, address 00:e0:ed:75:a5:5e > ixl2: unable to query phy types > ixl3 at pci6 dev 0 function 3 "Intel X710 SFP+" rev 0x02: port 3, FW > 5.0.40043 API 1.5, msix, 4 queues, address 00:e0:ed:75:a5:5f > ixl3: unable to query phy types > > # ifconfig ixl sff > ixl0: flags=8802 mtu 1500 > lladdr 00:e0:ed:75:a5:5c > index 3 priority 0 llprio 3 > media: Ethernet autoselect > status: no carrier > ifconfig: ixl0 transceiver: Input/output error > ixl1: flags=8802 mtu 1500 > lladdr 00:e0:ed:75:a5:5d > index 4 priority 0 llprio 3 > media: Ethernet autoselect > status: no carrier > ifconfig: ixl1 transceiver: Input/output error > ixl2: flags=8802 mtu 1500 > lladdr 00:e0:ed:75:a5:5e > index 5 priority 0 llprio 3 > media: Ethernet autoselect (10GbaseLR full-duplex) > status: active > ifconfig: ixl2 transceiver: Operation not supported by device > ixl3: flags=8802 mtu 1500 > lladdr 00:e0:ed:75:a5:5f > index 6 priority 0 llprio 3 > media: Ethernet autoselect > status: no carrier > ifconfig: ixl3 transceiver: Input/output error > > With "ifconfig ixlX debug" set, I get this on the interface > > ixl2: ixl_sff_get_byte(dev 0xa0, reg 0x7f) -> 0003 > > Firmware on these are a bit older than the Intel cards that I've seen > so my first thought is to try updating, I've mailed Silicom to ask them > if they can provide anything newer (Intel's own downloads say not to > use them for non Intel-branded cards and I don't really want to > brick a card..), does anyone have other ideas while I'm waiting to > hear back from them? > > > OpenBSD 6.7-current (GENERIC.MP) #337: Wed Jul 8 10:37:10 MDT 2020 > dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP > real mem = 8464842752 (8072MB) > avail mem = 8193245184 (7813MB) > random: good seed from bootblocks > mpath0 at root > scsibus0 at mpath0: 256 targets > mainbus0 at root > bios0 at mainbus0: SMBIOS rev. 2.8 @ 0xed9b0 (46 entries) > bios0: vendor American Megatrends Inc. version "1.3" date 03/19/2018 > bios0: Supermicro Super Server > acpi0 at bios0: ACPI 5.0 > acpi0: sleep states S0 S4 S5 > acpi0: tables DSDT FACP APIC FPDT FIDT SPMI MCFG UEFI DBG2 HPET WDDT SSDT > SSDT SSDT PRAD DMAR HEST BERT ERST EINJ > acpi0: wakeup devices IP2P(S4) EHC1(S4) EHC2(S4) RP07(S4) RP08(S4) BR1A(S4) > BR1B(S4) BR2A(S4) BR2B(S4) BR2C(S4) BR2D(S4) BR3A(S4) BR3B(S4) BR3C(S4) > BR3D(S4) RP01(S4) [...] > acpitimer0 at acpi0: 3579545 Hz, 24 bits > acpimadt0 at acpi0 addr 0xfee0: PC-AT compat > cpu0 at mainbus0: apid 0 (boot processor) > cpu0: Intel(R) Xeon(R) CPU D-1518 @ 2.20GHz, 2200.27 MHz, 06-56-03 > cpu0: >
Re: arm64 usertc
On 09.07.2020 11:35, Mark Kettenis wrote:
Here is the arm64 version. Again I've taken the approach of copying
the kernel timecounter code verbatim. Technically we don't need the
Cortex-A73 errata workaround here since the timecounter only uses the
low 32 bits. But that is true for the kernel as well! If people
think it is worth avoiding this, I'd propose to introduce
agtimer_readcnt32() and use that for the timecounter in both the
kernel and userland.
I modified Scott's test program and ran it on machine with both
Cortex-A53 and Cortex-A73 cores. That didn't reveal any glitches. So
it seems that indeed the ARM design removes any detectable skew
between the cores.
ok?
Reads OK to me.
Index: lib/libc/arch/aarch64/gen/usertc.c
===
RCS file: /cvs/src/lib/libc/arch/aarch64/gen/usertc.c,v
retrieving revision 1.1
diff -u -p -r1.1 usertc.c
--- lib/libc/arch/aarch64/gen/usertc.c 6 Jul 2020 13:33:05 - 1.1
+++ lib/libc/arch/aarch64/gen/usertc.c 9 Jul 2020 08:12:44 -
@@ -1,6 +1,6 @@
-/* $OpenBSD: usertc.c,v 1.1 2020/07/06 13:33:05 pirofti Exp $ */
+/* $OpenBSD$ */
/*
- * Copyright (c) 2020 Paul Irofti
+ * Copyright (c) 2020 Mark Kettenis
*
* Permission to use, copy, modify, and distribute this software for any
* purpose with or without fee is hereby granted, provided that the above
@@ -18,4 +18,39 @@
#include
#include
-int (*const _tc_get_timecount)(struct timekeep *, u_int *) = NULL;
+static inline uint64_t
+agtimer_readcnt64(void)
+{
+ uint64_t val0, val1;
+
+ /*
+* Work around Cortex-A73 errata 858921, where there is a
+* one-cycle window where the read might return the old value
+* for the low 32 bits and the new value for the high 32 bits
+* upon roll-over of the low 32 bits.
+*/
+ __asm volatile("isb" : : : "memory");
+ __asm volatile("mrs %x0, CNTVCT_EL0" : "=r" (val0));
+ __asm volatile("mrs %x0, CNTVCT_EL0" : "=r" (val1));
+ return ((val0 ^ val1) & 0x1ULL) ? val0 : val1;
+}
+
+static inline u_int
+agtimer_get_timecount(struct timecounter *tc)
+{
+ return agtimer_readcnt64();
+}
+
+static int
+tc_get_timecount(struct timekeep *tk, u_int *tc)
+{
+ switch (tk->tk_user) {
+ case TC_AGTIMER:
+ *tc = agtimer_get_timecount(NULL);
+ return 0;
+ }
+
+ return -1;
+}
+
+int (*const _tc_get_timecount)(struct timekeep *, u_int *) = tc_get_timecount;
Index: sys/arch/arm64/dev/agtimer.c
===
RCS file: /cvs/src/sys/arch/arm64/dev/agtimer.c,v
retrieving revision 1.13
diff -u -p -r1.13 agtimer.c
--- sys/arch/arm64/dev/agtimer.c6 Jul 2020 13:33:06 - 1.13
+++ sys/arch/arm64/dev/agtimer.c9 Jul 2020 08:12:45 -
@@ -43,7 +43,8 @@ int32_t agtimer_frequency = TIMER_FREQUE
u_int agtimer_get_timecount(struct timecounter *);
static struct timecounter agtimer_timecounter = {
- agtimer_get_timecount, NULL, 0x7fff, 0, "agtimer", 0, NULL, 0
+ agtimer_get_timecount, NULL, 0x7fff, 0, "agtimer", 0, NULL,
+ TC_AGTIMER
};
struct agtimer_pcpu_softc {
Index: sys/arch/arm64/include/timetc.h
===
RCS file: /cvs/src/sys/arch/arm64/include/timetc.h,v
retrieving revision 1.1
diff -u -p -r1.1 timetc.h
--- sys/arch/arm64/include/timetc.h 6 Jul 2020 13:33:07 - 1.1
+++ sys/arch/arm64/include/timetc.h 9 Jul 2020 08:12:45 -
@@ -18,6 +18,6 @@
#ifndef _MACHINE_TIMETC_H_
#define _MACHINE_TIMETC_H_
-#define TC_LAST 0
+#define TC_AGTIMER 1
#endif /* _MACHINE_TIMETC_H_ */
arm64 usertc
Here is the arm64 version. Again I've taken the approach of copying
the kernel timecounter code verbatim. Technically we don't need the
Cortex-A73 errata workaround here since the timecounter only uses the
low 32 bits. But that is true for the kernel as well! If people
think it is worth avoiding this, I'd propose to introduce
agtimer_readcnt32() and use that for the timecounter in both the
kernel and userland.
I modified Scott's test program and ran it on machine with both
Cortex-A53 and Cortex-A73 cores. That didn't reveal any glitches. So
it seems that indeed the ARM design removes any detectable skew
between the cores.
ok?
Index: lib/libc/arch/aarch64/gen/usertc.c
===
RCS file: /cvs/src/lib/libc/arch/aarch64/gen/usertc.c,v
retrieving revision 1.1
diff -u -p -r1.1 usertc.c
--- lib/libc/arch/aarch64/gen/usertc.c 6 Jul 2020 13:33:05 - 1.1
+++ lib/libc/arch/aarch64/gen/usertc.c 9 Jul 2020 08:12:44 -
@@ -1,6 +1,6 @@
-/* $OpenBSD: usertc.c,v 1.1 2020/07/06 13:33:05 pirofti Exp $ */
+/* $OpenBSD$ */
/*
- * Copyright (c) 2020 Paul Irofti
+ * Copyright (c) 2020 Mark Kettenis
*
* Permission to use, copy, modify, and distribute this software for any
* purpose with or without fee is hereby granted, provided that the above
@@ -18,4 +18,39 @@
#include
#include
-int (*const _tc_get_timecount)(struct timekeep *, u_int *) = NULL;
+static inline uint64_t
+agtimer_readcnt64(void)
+{
+ uint64_t val0, val1;
+
+ /*
+* Work around Cortex-A73 errata 858921, where there is a
+* one-cycle window where the read might return the old value
+* for the low 32 bits and the new value for the high 32 bits
+* upon roll-over of the low 32 bits.
+*/
+ __asm volatile("isb" : : : "memory");
+ __asm volatile("mrs %x0, CNTVCT_EL0" : "=r" (val0));
+ __asm volatile("mrs %x0, CNTVCT_EL0" : "=r" (val1));
+ return ((val0 ^ val1) & 0x1ULL) ? val0 : val1;
+}
+
+static inline u_int
+agtimer_get_timecount(struct timecounter *tc)
+{
+ return agtimer_readcnt64();
+}
+
+static int
+tc_get_timecount(struct timekeep *tk, u_int *tc)
+{
+ switch (tk->tk_user) {
+ case TC_AGTIMER:
+ *tc = agtimer_get_timecount(NULL);
+ return 0;
+ }
+
+ return -1;
+}
+
+int (*const _tc_get_timecount)(struct timekeep *, u_int *) = tc_get_timecount;
Index: sys/arch/arm64/dev/agtimer.c
===
RCS file: /cvs/src/sys/arch/arm64/dev/agtimer.c,v
retrieving revision 1.13
diff -u -p -r1.13 agtimer.c
--- sys/arch/arm64/dev/agtimer.c6 Jul 2020 13:33:06 - 1.13
+++ sys/arch/arm64/dev/agtimer.c9 Jul 2020 08:12:45 -
@@ -43,7 +43,8 @@ int32_t agtimer_frequency = TIMER_FREQUE
u_int agtimer_get_timecount(struct timecounter *);
static struct timecounter agtimer_timecounter = {
- agtimer_get_timecount, NULL, 0x7fff, 0, "agtimer", 0, NULL, 0
+ agtimer_get_timecount, NULL, 0x7fff, 0, "agtimer", 0, NULL,
+ TC_AGTIMER
};
struct agtimer_pcpu_softc {
Index: sys/arch/arm64/include/timetc.h
===
RCS file: /cvs/src/sys/arch/arm64/include/timetc.h,v
retrieving revision 1.1
diff -u -p -r1.1 timetc.h
--- sys/arch/arm64/include/timetc.h 6 Jul 2020 13:33:07 - 1.1
+++ sys/arch/arm64/include/timetc.h 9 Jul 2020 08:12:45 -
@@ -18,6 +18,6 @@
#ifndef _MACHINE_TIMETC_H_
#define _MACHINE_TIMETC_H_
-#defineTC_LAST 0
+#define TC_AGTIMER 1
#endif /* _MACHINE_TIMETC_H_ */
Re: bridge(4) shouldn't try to create new interfaces when i make a typo
On Thu, Jul 09, 2020 at 05:08:01PM +1000, David Gwynne wrote: > if i accidentally `ifconfig bridge add gre0` instead of egre0, having > bridge create gre0 and then not like it is not what i expect to happen. > especially when it leaves me with an extra gre0 interface lying around > afterwards. > > i can appreciate that this was trying to be helpful when you wanted > to add virtual interfaces to a bridge on boot, but that was before > netstart(8) created all the interfaces with config files up front, before > it then goes through and runs the config for them. I agree. OK kn
bridge(4) shouldn't try to create new interfaces when i make a typo
if i accidentally `ifconfig bridge add gre0` instead of egre0, having
bridge create gre0 and then not like it is not what i expect to happen.
especially when it leaves me with an extra gre0 interface lying around
afterwards.
i can appreciate that this was trying to be helpful when you wanted
to add virtual interfaces to a bridge on boot, but that was before
netstart(8) created all the interfaces with config files up front, before
it then goes through and runs the config for them.
ok?
Index: if_bridge.c
===
RCS file: /cvs/src/sys/net/if_bridge.c,v
retrieving revision 1.340
diff -u -p -r1.340 if_bridge.c
--- if_bridge.c 24 Jun 2020 22:03:42 - 1.340
+++ if_bridge.c 9 Jul 2020 07:02:24 -
@@ -273,14 +273,6 @@ bridge_ioctl(struct ifnet *ifp, u_long c
break;
ifs = ifunit(req->ifbr_ifsname);
-
- /* try to create the interface if it does't exist */
- if (ifs == NULL) {
- error = if_clone_create(req->ifbr_ifsname, 0);
- if (error == 0)
- ifs = ifunit(req->ifbr_ifsname);
- }
-
if (ifs == NULL) { /* no such interface */
error = ENOENT;
break;
let's not pretend switch(4) works with anything except ethernet interfaces.
the code pretty obviously assumes that it only handles Ethernet packets,
so we should restrict it to IF_ETHER type interfaces.
ok?
Index: if_switch.c
===
RCS file: /cvs/src/sys/net/if_switch.c,v
retrieving revision 1.30
diff -u -p -r1.30 if_switch.c
--- if_switch.c 6 Nov 2019 03:51:26 - 1.30
+++ if_switch.c 9 Jul 2020 05:59:51 -
@@ -506,6 +506,9 @@ switch_port_add(struct switch_softc *sc,
if ((ifs = ifunit(req->ifbr_ifsname)) == NULL)
return (ENOENT);
+ if (ifs->if_type != IFT_ETHER)
+ return (EPROTONOSUPPORT);
+
if (ifs->if_bridgeidx != 0)
return (EBUSY);
@@ -517,15 +520,12 @@ switch_port_add(struct switch_softc *sc,
return (EBUSY);
}
- if (ifs->if_type == IFT_ETHER) {
- if ((error = ifpromisc(ifs, 1)) != 0)
- return (error);
- }
+ if ((error = ifpromisc(ifs, 1)) != 0)
+ return (error);
swpo = malloc(sizeof(*swpo), M_DEVBUF, M_NOWAIT|M_ZERO);
if (swpo == NULL) {
- if (ifs->if_type == IFT_ETHER)
- ifpromisc(ifs, 0);
+ ifpromisc(ifs, 0);
return (ENOMEM);
}
swpo->swpo_switch = sc;
Re: disable libc sys wrappers?
On Wed, Jul 8, 2020 at 8:06 AM Theo de Raadt wrote: > Mark Kettenis wrote: > > > > From: "Theo de Raadt" > > > Date: Wed, 08 Jul 2020 09:42:41 -0600 > > > > > > I think we need something like this. > > > > > > Documenting it will be a challenge. > > > > > > I really don't like the name as is too generic, when the control is > only > > > for a narrow set of "current time" system calls. > > > > I'm not sure we should be using getenv() in this early initialization > > function though. > > Ah, you worry about the static "#ifndef PIC / early_static_init" versus > "PIC ld.so" environ setup, and this very early getenv() call might not be > looking at the environ global. > It's late enough in the process (after a possible call to early_static_init(), and definitely after any fixup by ld.so) that it should work Just Fine. I would flip the test to check the environment before running issetugid(2) because the syscall is more expensive and it's nice not to clutter the kdump output. ;-) Philip Guenther
