Re: CVS: cvs.openbsd.org: src

[Chris Cappuccio]

Todd C. Miller [mill...@openbsd.org] wrote:
> On Tue, 10 Oct 2023 10:50:08 +0100, Stuart Henderson wrote:
> 
> > Presumably 465 should be treated the same, though the hardcoded ports
> > don't feel entirely right here - this is presumably something that would
> > want adding for any connection which is allowed to relay ..
> 
> Yes, I think so.  Hard-coding ports is not great but there isn't a
> way in the config file to indicate that explicitly.
> 

The Message-ID should be added to any message that doesn't have one.
An existing Message-ID should not be removed or changed.

The RFC says it "MAY be applied when necessary by an originating SMTP server"
so the port numbers aren't a terrible idea, but it leaves open plenty
of room to not add one if someone isn't following the 465/587 scheme.

If the smtp_tx_dataline or a subset could be called when we know the
message isn't being delivered locally, that would be ideal and avoid
the need to lookup port numbers.

Chris

Re: wg destroy hangs

[Chris Cappuccio]

Can you try compiling without this:

https://cvsweb.openbsd.org/cgi-bin/cvsweb/src/sys/net/if_wg.c.diff?r1=1.29=1.30

Kirill Miazine [k...@krot.org] wrote:
> Recently on snapshots I have noticed that ifconfig wgN destroy would just
> hang there, without any way to get back the control. Power reset would be
> the only way to reboot and regain control.
> 
> I don't have exact date when it happened first, maybe some 10 days ago, but
> problem is present on most recent snapshot (amd64).
> 
> -- Kirill

Re: fix vlan handling with tcplro on ix(4)

[Chris Cappuccio]

Jan Klemkow [j.klem...@wemelug.de] wrote:
> +#if NVLAN > 0
> + if (ext.evh)
> + hdrlen += ETHER_VLAN_ENCAP_LEN;
> +#endif
>   if (ext.ip4)
>   hdrlen += ext.ip4->ip_hl << 2;
>   if (ext.ip6)

I'm not sure this should be tied to the compilation of the vlan
driver in the kernel. Since the length is larger in either case,
the ix driver should behave the same in either case.

Chris

Re: ifconfig rename tcplro

[Chris Cappuccio]

Jan Klemkow [j.klem...@wemelug.de] wrote:
> On Tue, Jun 06, 2023 at 05:54:31PM +0300, Vitaliy Makkoveev wrote:
> > On Tue, Jun 06, 2023 at 02:31:52PM +0200, Alexander Bluhm wrote:
> > > I would suggest to rename ifconfig tcprecvoffload to tcplro.  Maybe
> > > it's just because I had to type that long name too often.
> > > 
> > > With that we have consistent naming:
> > > # ifconfig ix0 tcplro
> > > # sysctl net.inet.tcp.tso=1
> > > 
> > > Also the coresponding flag are named LRO.
> > > # ifconfig ix1 hwfeatures
> > > ix1: flags=2008843 mtu 1500
> > > 
> > > hwfeatures=71b7
> > >  hardmtu 9198
> > > 
> > > The feature is quite new, so I have no backward compatiblity concerns.
> > > 
> > > ok?
> > 
> > Could you name it "lro" like FreeBSD uses?
> 
> I also would prefer this one.

and tcpsendoffload back to tso ?

was the reason for changing it from tso due to the initial conflation of TSO 
and LRO in the tree?

Re: installer: amd64 EFI: default to GPT

[Chris Cappuccio]

Klemens Nanni [k...@openbsd.org] wrote:
> On Sun, May 07, 2023 at 06:22:55PM +0200, Mark Kettenis wrote:
> > > Date: Sat,  6 May 2023 22:47:55 +
> > > From: Klemens Nanni 
> > > 
> > > On Sat, Apr 29, 2023 at 06:47:48PM +, Klemens Nanni wrote:
> > > > Installing to a wiped disk on EFI machines suggests MBR not GPT when 
> > > > chosing
> > > > (E)dit because MBR vs. GPT in this manual case is picked based on 
> > > > existing
> > > > data on the disk, not whether it has EFI.
> > > > 
> > > > Fix that so users get correct instructions and don't end up with legacy
> > > > partitioning in fresh installs on new machines.
> > > > 
> > > > Feedback? OK?
> > > 
> > > Anyone?
> > > 
> > > Put differently, in the manual (E)dit case, the guidance message should
> > > be oriented towards the actual system (this diff) and not whatever is on
> > > the disk that's about to be set up by hand (-current).
> > 
> > Makes no sense to me.  If you choose (E)dit, you want to make changes
> > to the partition table that is already on the disk.
> 
> If the disk has random garbage or you zero it, the (E)dit case looks for GPT
> which is not there and then suggests to to MBR instead.
> 
> > EFI firmware doesn't really care whether you have a GPT partition
> > table or a traditional MBR partition table.
> 
> That might work, but shouldn't you go for GPT with an ESP on UEFI systems?
> 
> In the case I describe and hit, our installer advises to just create an MBR
> with one OpenBSD partition, whereas I think we should rather hint users at GPT
> with ESP and an OpenBDS partition on UEFI systems.
> 

I don't quite understand the case this patch solves, because my installs to
fresh media always get EFI/GPT. It doesn't default to MBR. However, if
there is a case where it tries to use MBR, that isn't going to work so well.

MBR boot is totally unsupported on modern Intel. Starting with 10th gen
Intel processors, Intel only supplies graphics code for EFI mode.

With some 10th gen chipsets, like W480, the BIOS still gives you can option to
boot MBR with zero graphics. For the BIOS on 11th gen chipsets like the W580,
there is no MBR boot capability at all, for whatever reason.

Re: add Aquantia AQC113CS to pcidevs

[Chris Cappuccio]

Paul de Weerd [we...@weirdnet.nl] wrote:
> My new motherboard has a 10GB/s interface that doesn't work with
> -current.  It's this thing:
> 

https://git.kernel.org/pub/scm/linux/kernel/git/netdev/net-next.git/commit/?id=bf2320a60e687760400cf964ec3e60ceccb90f93

Re: Questions about the code review process in OpenBSD

[Chris Cappuccio]

i...@tutanota.com [i...@tutanota.com] wrote:
>
> Is it a condition for code to go into the OpenBSD source tree (not
> talking about ports) that at least one other developer has reviewed the
> code?
> 

Yes

> Is there a process in place to guarantee this?
> 

Yes, manual review all the way down.

If someone commits without review from people who have experience in an area, 
their work will be reversed. If they are really acting improperly, their 
account will be removed.

Re: bioctl.8: noauto flag has no effect in bootloaders

[Chris Cappuccio]

Klemens Nanni [k...@openbsd.org] wrote:
> Reading "at boot time" may come off as "in the bootloader"

> -Do not automatically assemble this volume at boot time.
> +Do not automatically assemble this volume at system startup time.

I don't think this reads any different. If you want to be very
clear, talk about the kernel.

I'd use "kernel start" instead of "boot time" or "system startup time"
(which are both vague to me.)

Re: vsw.4: mention veb next to bridge

[Chris Cappuccio]

Klemens Nanni [k...@openbsd.org] wrote:
> veb(4) works just fine in this setup, so don't give the impression only
> bridge(4) would work.
> 

In related items, is it time to tedu bridge(4) and vether(4) ? Is there
anything veb(4) and vport(4) can't do?

Re: unlock pf_purge

[Chris Cappuccio]

David Gwynne [da...@gwynne.id.au] wrote:
> the main change here is to move pf_purge out from under the kernel lock.
> 
> another part of the change is to limit the amount of work the state
> purging does to avoid hogging a cpu too much, and to also avoid holding
> NET_LOCK for too long.
> 

I've been running this on my "CGN" pfsync cluster (~500k states) and it
seems to be stable so far. With NET_TASKQ=4 on a 4 CPU box, I see mostly
3 cores taxed and not 4. If I go to NET_TASKQ=8 on a 10 CPU box, I see
5 and sometimes 6 cores taxed. Since I'm using pfsync, there is always one
net taskq that is much busier than the rest, so my results may be a little
skewed.

Chris

Re: Security support status of xnf(4) and xbf(4)

[Chris Cappuccio]

Demi Marie Obenour [d...@invisiblethingslab.com] wrote:
> Linux???s netfront and blkfront drivers recently had a security
> vulnerability (XSA-396) that allowed a malicious backend to potentially
> compromise them.  In follow-up audits, I found that OpenBSD???s xnf(4)
> currently trusts the backend domain.  I reported this privately to Theo
> de Raadt, who indicated that OpenBSD does not consider this to be a
> security concern.
> 

A malicious backend could completely compromise the virtual host in an
infinite number of ways. Perhaps a small patch to find incorrect values
would be of value, but even then, a patch would only be a very slight
improvment. If you patch the manual page, should OpenBSD start putting
notifications in all manual pages that a compromised virtual machine
backend may compromise the integrity of the virtual host?

Chris

Re: explain priority codepoints and their mapping in vlan.4

[Chris Cappuccio]

Christopher Zimmermann [chr...@openbsd.org] wrote:
> On Mon, Dec 20, 2021 at 04:41:07PM -0700, Theo de Raadt wrote:
> > You say it twice.  But my eyes still glazed over it, not seeing what was
> > going on the first two times.
> > 
> > Maybe something more like
> > 
> >  prio 0 and 1 are mapped out of order to PCP 1 and 0, but prio 2 to
> >  7 are mapped directly to PCP 2 to 7.
> > 
> > No that still doesn't quite capture it in a visible way. How about
> > 
> >  prio 2 to 7 are mapped directly to PCP 2 to 7, but prio 0 and 1
> >  are mapped backwards, to PCP 1 and 0, because <...>
> > 
> > Something which will draw the eye+brain to 'something is different here'.
> > The table alone doesn't do that.
> 
> I agree. How about this?
> 
>  The 802.1Q and 802.1ad protocols include a Priority Code Point (PCP).  By
>  default, the 802.1p PCP in a transmitted packet is based on the priority
>  of packets sent over the interface, which may be altered via pf.conf(5);
>  see the prio option for more information.  Alternatively, the ifconfig(4)
>  txprio option can set a specific priority for transmitted packets. On
>  vlan and svlan interfaces priorities 2 to 7 will be mapped directly to
>  PCP 2 to 7, but priorities 0 and 1 are mapped backwards, to PCP 1 and 0.
>  This is because 802.1p defines PCP 1 as lowest priority and PCP 0 as
>  second lowest priority, which is meant to be used as default (???best
>  effort???).
> 

I think the best way to get someone's attention is to mention the
conflict first, like in Theo's example. Yours seems wordy, a person
has to read several sentences before they even realize something
unusual going on here.

Chris

Re: smtpd smtp_proceed_wiz function

[Chris Cappuccio]

Crystal Kolipe [kolip...@exoticsilicon.com] wrote:
> On Mon, Nov 08, 2021 at 06:13:14PM +, Stuart Henderson wrote:
> > On 2021/11/08 14:52, Crystal Kolipe wrote:
> > > I'm not aware of a 'wiz' command in any SMTP related RFC.
> > This will become clear if you look into sendmail history :)
> 
> Got it :).
> 
> I assume that this won't be implemented in OpenBSD any time soon
> then.

We could emulate it and pretend that we are an ancient vulnerable 
verison of Sendmail, or pretty much any version since they all
contain a plethora of vulnerabilities.

While we're at it, maybe emulate Microsoft Exchange and EXIM :)

Chris 

Re: [patch] httpd static gzip compression

[Chris Cappuccio]

Solene Rapenne [sol...@perso.pw] wrote:
> On jeudi 4 novembre 2021 15:09:39 CET, Stuart Henderson wrote:
> > 
> > btw this was rejected before,
> > 
> > https://github.com/reyk/httpd/issues/21
> 
> It's not clear if "static" compression is rejected. Sure, on-the-fly
> compilation is complicated and bring issues, static compression
> is easy to implement and predictible IMO.

In my opinion, this feature makes sense if it can be activated by the
'location' ...

It requires explicit preparation by the site operator so it should
only activated on demand, per-directory

It makes sense to me in this context

If someone explicitly requests the .gz version, they get it, regardless
of this setting

If someone requests the non-gz version, their browser should only
get the gz if it agrees to transparently handle the compression

And the gz swap only gets activated if the site operator tells
httpd this is the desired behavior for a particular directory tree through
the location keyword...

Chris

Re: forwarding in parallel ipsec workaround

[Chris Cappuccio]

Hrvoje Popovski [hrv...@srce.hr] wrote:
> 
> box didn't panic, just stopped forwarding traffic through tunnel.

any chance any progress has been made here? is there any newer versions
of these diffs floating around?

Re: Willing to test any driver for AX210

[Chris Cappuccio]

The iwlwifi driver has this commit for adding the "device family AX210"

https://patchwork.kernel.org/project/linux-wireless/patch/20190207223622.9642-14-l...@coelho.fi/

There are other commits too. It requires driver adaptation, firmware,
the iwx driver will have to be extended.

Re: [External] : forwarding in parallel

[Chris Cappuccio]

Alexandr Nedvedicky [alexandr.nedvedi...@oracle.com] wrote:
> diff --git a/sys/net/if_tpmr.c b/sys/net/if_tpmr.c
> index f6eb99f347c..4ffa5b18293 100644
> @@ -725,10 +759,9 @@ tpmr_p_dtor(struct tpmr_softc *sc, struct tpmr_port *p, 
> const char *op)
>   if_detachhook_del(ifp0, >p_dtask);
>   if_linkstatehook_del(ifp0, >p_ltask);
>  
> - smr_barrier();
> + tpmr_p_rele(p);
>  
> - if_put(ifp0);
> - free(p, M_DEVBUF, sizeof(*p));
> + smr_barrier();
>  
>   if (ifp->if_link_state != LINK_STATE_DOWN) {
>   ifp->if_link_state = LINK_STATE_DOWN;

The order is changing here, it was smr_barrier and then the
equivalent of tpmr_p_rele, now it is tpmr_p_rele first,
smr_barrier second, is that change intentional ?

Chris

Re: gpio(4) support for APU2

[Chris Cappuccio]

Chris Narkiewicz [he...@ezaquarii.com] wrote:
> On Wed, Jan 29, 2020 at 10:47:28PM +0800, Nathanael Rensen wrote:
> > The diff below adds gpio(4) support to wbsio(4) for Nuvoton NCT5104D
> > (pcengines APU2).
> 
> I'm resurrecting this thread. I was looking for GPIO support for APU2
> board and found this patch in archives.
> 
> Any chance of taking it in?
> 

This is not the first patch to support gpio on wbsio, it's at least
the third, but arguably the best :)

Mark Kettenis said:

"But as before this diff does nothing to make sure it is actually
safe to touch these gpio pins.  Other machines might have the same
chip but use the pins internally to switch power to on-board
components."

A simple way to do this could be some kind of description file
specific to the board. Kind of like an FDT, but just for GPIO pins. 
GPIO Descriptor Tree?

So, when you are using an APU1/APU2, copy apu.gpiodt to /etc/gpiodt
and the kernel will load it on boot like a firmware image to decide
what pins you get access to from userland. Or maybe gpioctl would
load allowed pin use settings in rc.securelevel ?

Is this a sane way to go? If so, what attributes would be needed for
each pin? Something like user, locked, kernel?

apu.gpiodt:

gpio0@wbsio {
hwproduct = "APU";
pin0 = "locked";
pin1 = "locked";
pin2 = "locked";
pin3 = "user";
pin4 = "user";
pin5 = "user";
pin6 = "user";
pin7 = "user";
pin8 = "user";
pin9 = "user";
pin10 = "user";
pin11 = "user";
pin12 = "user";
pin13 = "user";
pin14 = "user";
pin15 = "user";
};

Chris

Re: list hyperv features in dmesg

[Chris Cappuccio]

Peter J. Philipp [p...@delphinusdns.org] wrote:
> 
> Before:
> pvbus0 at mainbus0: Hyper-V 10.0
> hyperv0 at pvbus0: protocol 4.0, features 0x2e7f
> hyperv0: heartbeat, kvp, shutdown, timesync
> hvs0 at hyperv0 channel 2: ide, protocol 6.2
> 
> After:
> 
> pvbus0 at mainbus0: Hyper-V 10.0
> hyperv0 at pvbus0: protocol 4.0, features 0x2e7f 
> TIME_REFCNT,SYNIC,SYNTIMER,APIC
> ,HYPERCALL,VP_INDEX,GUEST_IDLE
> hyperv0: pm features 0x2 
> hyperv0: features3 0xbed7b2 ,XMM_HYPERCALL3,GUEST_IDLE3,NUMA3,TIME_FREQ3
> hyperv0: heartbeat, kvp, shutdown, timesync
> hvs0 at hyperv0 channel 2: ide, protocol 6.2
> 
> Below is patch, what do you think?  Is it worthy?
> 

If you're going to print flags for some unsupported features, why
not print them all? 

The 'features3' line doesn't look clean

Typically uppercase flags like this are formatted like 

In any event, I'm not sure what benefit this brings. Doesn't 
"hyperv0: heartbeat, kvp, shutdown, timesync" already show what features
are in use?

I imagine it might be interesting to know what features are available but
not in use. Is there a command-line utility that could be extended to show
this info?

Chris

Re: Thread Local Storage in clang

[Chris Cappuccio]

Marc Espie [es...@nerim.net] wrote:
> 
> Thinking some more about it, I would suspect the configury stuff in that
> library to expect native support... tls doesn't work on OpenBSD unless you
> respect the toolchain.
> 
> in particular, it won't fly without the support library (the emutls stuff
> in libc++abi)
> 
> clang platforms aren't incredibly common.  It definitely looks like the most
> likely explanation.

Never mind, clang works fine, it's gcc that fails. For some reason after 
upgrading to 6.9 and upgrading ports, the librdkafka started choosing
gcc instead of clang and I was looking in the wrong direction.

Thread Local Storage in clang

[Chris Cappuccio]

I tried to compile librdkafka on OpenBSD 6.5 (clang 7.0.1) and clang compiled
the __thread parts with some built-in mechanism. I upgraded the system to
OpenBSD 6.9 and TLS is no longer supported by the in-tree clang. Was this
intended to be turned off? Did the 6.5 version even work? Is Thread Local
Storage support in clang desired in general or no? Marc Espie's clang 
presentation from July 2017 mentions that we do and that Mark Kettenis
helped make it happen. I'm having a hard time finding much other discussion
either way.

Re: ftpd(8): remove useless parameter of get_line()

[Chris Cappuccio]

Jan Klemkow [j.klem...@wemelug.de] wrote:
> Hi,
> 
> This diff removes the useless FILE* parameter of get_line().  In every
> call this parameter is always "stdin".  Thus, we can replace ever use of
> the variable iop with stdin.
> 
> Like every other diff, I tested this diff with the ftpd regression
> tests.
> 
> OK?
> 

looks fine to me

Re: sysctl net.inet.ip.arpqueued read only

[Chris Cappuccio]

Vitaliy Makkoveev [m...@openbsd.org] wrote:
> 
> 
> > On 26 Apr 2021, at 01:43, Theo de Raadt  wrote:
> > 
> > I am not a fan of this strange behaviour, where the min+max values
> > have additional behaviours.  It is too surprising, and surprising
> > often turns into error-prone.
> 
> Agreed. Also according sysctl_int_bounded() code this behaviour looks
> like non obvious side effect. 
> 

Would 0, 0 min, max be a simple and obvious way to say "read only" ?

Re: iwn: fix hangs with Tx aggregation

[Chris Cappuccio]

Stefan Sperling [s...@stsp.name] wrote:
> 
> Sending BA req frames with the firmware node which represents the AP seems to
> fix the problem. I have not yet managed to trigger it again with this patch.
> My best explanation is that this allows the firmware to retry block ack
> requests properly, and to stop retrying once a BA is received from the AP.
> 
> ok?
> 

I suspect you're absolutely right. Thank you for debugging this shitty firmware.

Re: uvm_fault_lower refactoring

[Chris Cappuccio]

Martin Pieuchot [m...@openbsd.org] wrote:
> On 16/02/21(Tue) 11:20, Martin Pieuchot wrote:
> > Start by moving `pgo_fault' handler outside of uvm_fault_lower().
> > 
> > If a page has a backing object that prefer to handler to fault itself
> > the locking will be different, so keep it under KERNEL_LOCK() for the
> > moment and make it separate from the rest of uvm_fault_lower().
> > 
> > ok?
> 
> Anyone?
> 

It makes sense, and works on my workstation...

Re: vmm(4): cpuid leaf 0x15 fixes clock speed problem in Linux guest [PATCH]

[Chris Cappuccio]

Pratik Vyas [m...@pd.io] wrote:
> 
> This cpuid emulation bit was added during the time when using tsc was
> the only way to get a precise clock and before pvclock was added [2].  This
> also doesn't work on AMD machines (on at least mine).  We could get rid
> of this cpuid emulation.
>

If cpuid emulation makes Jozef's case worse, where does it actually help?

Re: Mellanox ConnectX-6 Driver no working

[Chris Cappuccio]

Nilson Lopes [noslin...@gmail.com] wrote:
> 
> If we look carefully in the list of PCI codes in  '/sys/dev/pci/pcidevs'
> source code here
> https://github.com/openbsd/src/blob/master/sys/dev/pci/pcidevs#L6323-L6335,
> we see that the card I'm using is known as MELLANOX MT28908.
> [image: image.png]
> 
> 
> But, the source code for the 'mcx' driver  does not have that particular
> model:
> https://github.com/openbsd/src/blob/master/sys/dev/pci/if_mcx.c#L2536-L2546

It may be as simple as adding the pci device to the matching list in 
sys/dev/pci/if_mcx.c and installing your new kernel. You could just put the new 
if_mcx.o file into the kernel relink directory and relink if you want to do 
quick tests.

Also you are best using 6.8-current as it has some mcx fixes that are post 
6.8-release. 

Chris

Re: TCP congestion control progression

[Chris Cappuccio]

Brian Brombacher [br...@planetunix.net] wrote:
> 
> I am wondering what approach the project is planning to use to modernize 
> the congestion control algorithms.  I'm interested in assisting the project 
> with development effort in this area.  I've spent time making modifications
> for my own purposes and would prefer to understand the projects goals before
> continuing, if possible.
> 

Various improvements have been made over the years for dynamic window size,
also further tweaks for higher bandwidth over high latency connections. I'd
recommend sharing your current modifications here to get feedback.

Chris

Re: ADMtec aue(4) interface supporting VLAN_MTU ?

[Chris Cappuccio]

Tom Smyth [tom.sm...@wirelessconnect.eu] wrote:
> Hi Chrisz,
> 
> 4 bytes for the vlan header .. have you tried increasing the parent
> intetface mtu by 4bytes
> 

IFCAP_VLAN_MTU is a direct bypass for this. "hardmtu" on the parent interface
is perhaps more interesting as it will limit everything including these
encapsulations

Re: SATA HDD hot-plugging question

[Chris Cappuccio]

sysadmin [r...@bh0.amt.ru] wrote:
> Hello.
> 
> Does the ahci driver support SATA HDD hot-plugging? There is no
> information about it in the ahci(4) man page.

although it isn't supported today, i think it would be fairly easy to do
if you have an itch for it.

Re: Fix a segmentation fault in awk

[Chris Cappuccio]

Frederic Cambus [f...@statdns.com] wrote:
> 
> [1] http://distcache.FreeBSD.org/ports-distfiles/nawk-20121220/awk.tar.gz
> 

Following the lack of hosting from Bell Labs, the post-2012 tree is on
Github.  Brian Kernighan's page now points to:

https://github.com/onetrueawk/awk

Looking through the history it includes some fixes from OpenBSD.

Chris

Re: Fix a segmentation fault in awk

[Chris Cappuccio]

Andras Farkas [deepbluemist...@gmail.com] wrote:
> On Mon, Aug 12, 2019 at 3:45 PM Frederic Cambus  wrote:
> > Hi tech@,
> > Here is a diff to fix a segmentation fault in awk, from upstream
> > version 20121220 [1]. Upstream fix didn't check for strdup return value
> > so I added the check.
> I've always been curious, why isn't the latest version of awk, the
> 2012 version, used in OpenBSD?  There may be a reason, but I've never
> been able to figure it out.

Ironically the last update was in 2011. Todd Miller has been keeping it up-to-
date until that point. It'd make sense for someone to analyze the local
changes and import the newer version. The only reason seems to be that the
work needs to be done. Importing the fix is a good first step.

Chris

Re: ADMtec aue interface does not work with full 1500 VLAN_MTU

[Chris Cappuccio]

Christopher Zimmermann [chr...@openbsd.org] wrote:
> This works:
> 
> doas ifconfig vlan67 mtu 1496
> 
> this doesn't:
> 
> doas ifconfig vlan67 mtu 1497
> 
> 
> Should we therefore disable VLAN_MTU on this chipset?
> 
> - ifp->if_capabilities = IFCAP_VLAN_MTU;
> -


Yes absolutely. If IFCAP_VLAN_MTU actually worked for some chip versions,
more work is needed to distinguish the working chipsets.

Chris

Re: ld.so speedup (part 2)

[Chris Cappuccio]

Stuart Henderson [s...@spacehopper.org] wrote:
> 
> This doesn't match my experience:
> 
> $ time sudo rcctl start samba
> smbd(ok)
> nmbd(ok)
> 0m00.81s real 0m00.31s user 0m00.31s system

He was linking Samba with Kerberos libs too.

Re: Talking about time (ntpd -s)

[Chris Cappuccio]

sven falempin [sven.falem...@gmail.com] wrote:
> 
> Alast why not just wait for something to respond and then set time ??
> This (bit ugly) diff reveals some dead code in ntpd
> 
> https://pastebin.com/9PwqBDHz
> 
> Is there another way to bootstrap time correctly ?
> 

ntpd will wait under normal invocation, but -s jumps the system time and
ntpd is only given the limited amount of time for this to happen. The system
does not want to jump to a new time once other daemons are started. That's
why the behavior is the way it is now. If you know you have an interface
that takes a long time to come up for some reason, you can add an appropriate
'sleep' statement in the hostname.if file, or even a script that takes on
a more complicated set of actions before allowing the system to move forward.

Re: nvme_pci.c patch for MSI-X

[Chris Cappuccio]

I think the current MSI-X implementation is a minimal skeleton, enough for some
devices under virtualization. I don't know if it's enough for NVMe on real
hardware.

Jason Tubnor [ja...@tubnor.net] wrote:
> Hi,
> 
> Below is a patch that fixes an issue where NVMe storage is presented only
> via MSI-X.  This issue came about as the NVMe implementation in bhyve only
> uses MSI-X.
> 
> Thanks to Chuck Tuffli for the initial patch.  It was adjusted to deal with
> with both cases.
> 
> Thank,
> 
> Jason Tubnor
> 
> Index: sys/dev/pci/nvme_pci.c
> ===
> RCS file: /cvs/src/sys/dev/pci/nvme_pci.c,v
> retrieving revision 1.7
> diff -u -p -u -r1.7 nvme_pci.c
> --- sys/dev/pci/nvme_pci.c 10 Jan 2018 15:45:46 - 1.7
> +++ sys/dev/pci/nvme_pci.c 24 Mar 2019 08:22:42 -
> @@ -105,7 +105,7 @@ nvme_pci_attach(struct device *parent, s
>   return;
>   }
> 
> - if (pci_intr_map_msi(pa, ) != 0) {
> + if ((pci_intr_map_msix(pa, 0, ) != 0) && (pci_intr_map_msi(pa, ) !=
> 0)) {
>   if (pci_intr_map(pa, ) != 0) {
>   printf(": unable to map interrupt\n");
>   goto unmap;

make NET_TASKQ optionable

[Chris Cappuccio]

For future testing purposes, is this ok for the tree?

Index: if.c
===
RCS file: /cvs/src/sys/net/if.c,v
retrieving revision 1.570
diff -u -p -u -r1.570 if.c
--- if.c20 Dec 2018 10:26:36 -  1.570
+++ if.c30 Dec 2018 18:49:41 -
@@ -233,7 +233,9 @@ int ifq_congestion;
 
 int netisr;
 
+#ifndef NET_TASKQ
 #defineNET_TASKQ   1
+#endif
 struct taskq   *nettqmp[NET_TASKQ];
 
 struct task if_input_task_locked = TASK_INITIALIZER(if_netisr, NULL);

Re: allow weak passwd

[Chris Cappuccio]

Ted Unangst [t...@tedunangst.com] wrote:
> 
> i get tired of typing the same password five times.

The first three times, just hit 'a' 
The fourth time, enter the password you want

Re: pvclock(4)

[Chris Cappuccio]

Reyk Floeter [r...@openbsd.org] wrote:
>
> Yes, KVM???s stable bit is not a reliable indication as it is seems to depend 
> on the capabilities of the KVM version and not the actual availability of the 
> feature on the particular hardware. How annoying.
>
> As mentioned before: I???d like to disable pvclock for now and I can do that 
> in the morning CET if nobody beats me to it.
>
> I have an idea how to deal with old platforms afterwards but this needs some 
> more tests and thoughts.
>

Perhaps the solution is as "simple" as checking the status of the bit
after the presence of the bit is established ?

Index: pvclock.c
===
RCS file: /cvs/src/sys/dev/pv/pvclock.c,v
retrieving revision 1.2
diff -u -p -u -r1.2 pvclock.c
--- pvclock.c   24 Nov 2018 13:12:29 -  1.2
+++ pvclock.c   4 Dec 2018 00:53:56 -
@@ -127,8 +127,10 @@ pvclock_match(struct device *parent, voi
 void
 pvclock_attach(struct device *parent, struct device *self, void *aux)
 {
-   struct pvclock_softc*sc = (struct pvclock_softc *)self;
-   paddr_t  pa;
+   struct pvclock_softc*sc = (struct pvclock_softc *)self;
+   struct pvclock_time_info*ti;
+   paddr_t  pa;
+   uint8_t  flags;
 
if ((sc->sc_time = km_alloc(PAGE_SIZE,
_any, _zero, _nowait)) == NULL) {
@@ -151,6 +153,13 @@ pvclock_attach(struct device *parent, st
 
/* Better than HPET but below TSC */
sc->sc_tc->tc_quality = 1500;
+
+   ti = sc->sc_time;
+   flags = ti->ti_flags;
+   if ((flags & PVCLOCK_FLAG_TSC_STABLE) == 0) {
+   printf(": unstable timestamp counter\n");
+   return;
+   }
 
tc_init(sc->sc_tc);
 

Re: pvclock(4)

[Chris Cappuccio]

johnw [johnw.m...@gmail.com] wrote:
> 
> Hi, after disable pvclock, it can boot with new kernel again, thanks.
...
> cpu0: Intel(R) Core(TM)2 Duo CPU E8400 @ 3.00GHz, 105.29 MHz, 06-17-0a
> cpu0: 
> FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,SS,SSE3,SSSE3,CX16,SSE4.1,x2APIC,DEADLINE,XSAVE,HV,NXE,LONG,LAHF,PERF,ARAT,MELTDOWN
...

This CPU clearly doesn't have the invariant TSC (it is required according
to Reyk Floeter's tech@ posting from Nov 19th.) So, pvclock does not handle
this situation properly, apparently checking for KVM_FEATURE_CLOCKSOURCE2
and KVM_FEATURE_CLOCKSOURCE_STABLE_BIT is not enough. 

Chris

Re: Vim core dump

[Chris Cappuccio]

def...@posteo.de [def...@posteo.de] wrote:
> Hi, all
> 
> Could you be so kind to explain me why OpenBSD has no Dump core issue with
> Vim :
> https://github.com/vim/vim/issues/3619
> 

This is the wrong list for random discussion, but obviously, OpenBSD
is so far superior it can even help to avoid OTHER people's mistakes :)

Chris

Re: OpenBSD on AMD Ryzen7 2700 Asrock B450 chipset

[Chris Cappuccio]

Denis [den...@mindall.org] wrote:
> 
> Hardware is relatively new. Can test any compatibility issues/fixes on it.
> 
> There are a lot of "unconfigured" hardware is present in dmesg:
> 
> OpenBSD 6.4 (RAMDISK_CD) #348: Thu Oct 11 13:36:16 MDT 2018
> dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/RAMDISK_CD

The RAMDISK kernels are stripped down. The GENERIC.MP output is more
interesting. Please send it to dm...@openbsd.org (not tech@)

Re: NTPd server using DVB-T as clocksource

[Chris Cappuccio]

Lars Schotte [l...@gustik.eu] wrote:
> Well, I know that OpenBSD currently has no support for DVB-T but Linux
> does, so I would run that RaspberryPi with Linux. However, the question
> would be how to pair its output with OpenNTPd or NTPd.
> 

OpenBSD actually does support some of the ugen userland based decovers for
the R820T, as well as the RPi3.

In any event if the target is OpenNTPd, formatting the data as NMEA 0183
would be appropriate.

Re: NTPd server using DVB-T as clocksource

[Chris Cappuccio]

Lars Schotte [l...@gustik.eu] wrote:
> 
> Now, I do not like all this, that's why I ordered
> vk-172 gmouse g-mouse USB GPS/GLONASS USB over amazon
> and hope I can use that in combination with some Raspberry PI as NTPd
> clocksource, as I saw some ppl doing.
> 
> But that is only one clocksource, multiple would be preferrable.
> I have some DVB-T adapter lying around that can also be used as a
> clocksource, since those old DVB-T adapters are not good for TV anymore
> since ppl are sending DVB-T2, there is still for the forseeable
> future enough frequencies that will be still old DVB-T and those have
> time signal in them that can be used SOMEHOW.
> 

In OpenBSD, you would write a kernel USB driver that sets up the DVB-T
adapter to receive the appropriate signal and decode it. But the DVB
decoding might be too involved for what should be a small kernel driver.
Maybe you can hack the dvbdate utility into a source of NMEA 0183 data
to be opened as a socket from ntpd. 

Chris

Re: Linux DRM

[Chris Cappuccio]

Joseph Mayer [joseph.ma...@protonmail.com] wrote:
> 
> For the one who has not reviewed the code, can you quantify and
> illustrate approximately how bad it is?
> 

Perhaps he was reading from someone who does know some detail of the code?

https://arcan-fe.com/2018/04/25/towards-secure-system-graphics-arcan-and-openbsd/

Re: About differences with GNU patch(1)

[Chris Cappuccio]

Vadim Zhukov [persg...@gmail.com] wrote:
> , 20 ??. 2018 ??. ?? 21:17, Vadim Zhukov :
> >
> > Hi,
> >
> > The Ansible "patch" module fails to work on OpenBSD because it tries
> > to use "--dry-run" command-line option on patch(1), while ours
> > supports -C/--check instead. For now, I have an obvious, hm, patch :)
> > for patch.py that replaces --dry-run with --check. But what way do
> > people prefer: to move OpenBSD's patch(1) closer to GNU one, or to add
> > some logic to patch.py that'll detect correct command-line option to
> > use?
> >
> > There's also an issue with --binary: we don't support this option on
> > OpenBSD, and  GNU patch manual page says it's a no-op on POSIX anyway.
> > Would it be okay to add --binary as a no-op option to our patch?
> 
> BTW, the FreeBSD patch got --dry-run 4 years ago:
> https://svnweb.freebsd.org/base/head/usr.bin/patch/patch.c?r1=267490=267512
> 
> NetBSD got it in 2005:
> http://cvsweb.netbsd.org/bsdweb.cgi/src/usr.bin/patch/patch.c.diff?r1=1.22=1.23_with_tag=MAIN
> 
> Neither has --binary.
> 

Marc Espie did -C in 1998. See:

http://cvsweb.openbsd.org/cgi-bin/cvsweb/src/usr.bin/patch/patch.c.diff?r1=1.10=1.11

I think OpenBSD generally shies away from --gnu-style-options because they're
rather ugly compared to the originals. Unfortunately GNU is apparently setting
the standard for FreeBSD and NetBSD now.

Chris

Re: em: minimum ethernet frame size

[Chris Cappuccio]

sc->hw.min_frame_size is only used for TBI mode, which is only available
on the 82543 according to em_set_media_type()

You'd need to carefully analyze how the TBI_ACCEPT macro is used to see
what's right here. The macro even seems to assume that the vlan tag size
might be part of min_frame_size.

Michele Curti [michele.cu...@gmail.com] wrote:
> Hi,
> in sys/dev/pci/if_em.c at line 469 there is:
>   sc->hw.min_frame_size =
>   ETHER_MIN_LEN + ETHER_CRC_LEN;
> 
> But ETHER_MIN_LEN already includes the CRC size:
> #define ETHER_MIN_LEN   64  /* Minimum frame length, CRC included   */
> 
> In revision 1.41 the code changed in this way:
> sc->hw.min_frame_size =
> -   MINIMUM_ETHERNET_PACKET_SIZE + ETHER_CRC_LEN;
> +   ETHER_MIN_LEN + ETHER_CRC_LEN;
> 
> But MINIMUM_ETHERNET_PACKET_SIZE was the size without CRC.
> 
> #define MINIMUM_ETHERNET_FRAME_SIZE  64   /* With FCS */
> #define ETHERNET_FCS_SIZE4
> #define MINIMUM_ETHERNET_PACKET_SIZE \
> (MINIMUM_ETHERNET_FRAME_SIZE - ETHERNET_FCS_SIZE)
> 
> So I attached the following diff to restore the original minimum 
> size (by the way, what's the effect of having min_frame_size set 
> to 68? Discarding valid packets sized from 64 to 67?)
> 
> Regards,
> Michele
> 
> 
> Index: sys/dev/pci/if_em.c
> ===
> RCS file: /cvs/src/sys/dev/pci/if_em.c,v
> retrieving revision 1.336
> diff -u -p -r1.336 if_em.c
> --- sys/dev/pci/if_em.c   25 Jul 2017 20:45:18 -  1.336
> +++ sys/dev/pci/if_em.c   2 Feb 2018 11:13:43 -
> @@ -466,8 +466,7 @@ em_attach(struct device *parent, struct 
>   MAX_JUMBO_FRAME_SIZE;
>   }
>  
> - sc->hw.min_frame_size = 
> - ETHER_MIN_LEN + ETHER_CRC_LEN;
> + sc->hw.min_frame_size = ETHER_MIN_LEN;
>  
>   /* Allocate Transmit Descriptor ring */
>   if (em_dma_malloc(sc, sc->sc_tx_slots * sizeof(struct em_tx_desc),

Re: i386 zzz broken, Was: CVS: cvs.openbsd.org: src

[Chris Cappuccio]

li...@wrant.com [li...@wrant.com] wrote:
> 
> Please let me know if you want me to generate some dumps or similar, but
> unfortunately, I can't yet test patches or handle compilation on my own.
> I realise my info on this is incredibly lacking as quality & usefulness.
> 

Stuart Henderson has an archive of kernels from snapshot builds that you
can use to better narrow down when the regression started.

Unfortunately I don't remember the URL. Someone who has it easily accessible
may choose to provide it in a reply. You should be able to boot the older
kernels with either the 6.2-beta userland, or with the 6.1 userland. One or
the other will work typically. If you can try them and narrow down,
that's all that's necessary.

Chris

Re: Please test: HZ bump

[Chris Cappuccio]

I've been testing the second version of this diff in a number of areas 
(servers, desktop, laptop, routers) and I haven't noticed anything interesting
with power usage, run time on the laptops nor anything else, anywhere. That's
probably a good thing...

Re: ripd(8) fails on P2P links

[Chris Cappuccio]

Piotr Durlej [pi...@durlej.net] wrote:
> 
> And here is a patch:
> 

Whoops, I missed this part...And unlike mine it is correct, as there may
not be a destination configured. I think this is the right way to go.

> diff --git a/usr.sbin/ripd/packet.c b/usr.sbin/ripd/packet.c
> index 37b4a91..b956ec0 100644
> --- a/usr.sbin/ripd/packet.c
> +++ b/usr.sbin/ripd/packet.c
> @@ -232,15 +232,17 @@ find_iface(struct ripd_conf *xconf, unsigned int
> ifindex, struct in_addr src)
> 
>  /* returned interface needs to be active */
>  LIST_FOREACH(iface, >iface_list, entry) {
> -if (ifindex != 0 && ifindex == iface->ifindex &&
> -!iface->passive && (iface->addr.s_addr &
> +if (ifindex == 0 || ifindex != iface->ifindex)
> +continue;
> +
> +if (iface->passive)
> +continue;
> +
> +if ((iface->addr.s_addr &
>  iface->mask.s_addr) == (src.s_addr & iface->mask.s_addr))
> -/*
> - * XXX may fail on P2P links because src and dst don't
> - * have to share a common subnet on the otherhand
> - * checking something like this will help to support
> - * multiple networks configured on one interface.
> - */
> +return (iface);
> +
> +if (iface->dst.s_addr && iface->dst.s_addr == src.s_addr)
>  return (iface);
>  }
> 

Re: ripd(8) fails on P2P links

[Chris Cappuccio]

For P2P links, the destination address should be configured as
the peer. If so, perhaps this works?

Index: packet.c
===
RCS file: /cvs/src/usr.sbin/ripd/packet.c,v
retrieving revision 1.12
diff -u -p -u -r1.12 packet.c
--- packet.c25 Oct 2014 03:23:49 -  1.12
+++ packet.c6 Dec 2016 01:34:09 -
@@ -233,15 +233,13 @@ find_iface(struct ripd_conf *xconf, unsi
/* returned interface needs to be active */
LIST_FOREACH(iface, >iface_list, entry) {
if (ifindex != 0 && ifindex == iface->ifindex &&
-   !iface->passive && (iface->addr.s_addr &
-   iface->mask.s_addr) == (src.s_addr & iface->mask.s_addr))
-   /*
-* XXX may fail on P2P links because src and dst don't
-* have to share a common subnet on the otherhand
-* checking something like this will help to support
-* multiple networks configured on one interface.
-*/
-   return (iface);
+   !iface->passive) {
+   if ((iface->addr.s_addr & iface->mask.s_addr) == 
+   (src.s_addr & iface->mask.s_addr))
+   return (iface);
+   if (iface->dst.s_addr == src.s_addr)
+   return (iface);
+   }
}
 
return (NULL);

Re: rebound quantum entanglement

[Chris Cappuccio]

Theo de Raadt [dera...@openbsd.org] wrote:
> > That rebound acts like a nameserver is what prompted the idea to
> > hijack the resolver. But it's really a tool that takes over certain
> > duties from the libc resolver, so the libc resolver should be properly
> > configurable to hand over duties, or not. 'search' is the logical
> > place for this.
> 
> So maybe the first generation Ted proposes has some problems.  And
> what have YOU DONE recently??
> 

Sorry guys. I didn't mean to shit all over Ted's first revision. I was
just flabbergasted at the casual tone of this conversation, in contrast
to what was being discussed.

> Look, I think some people don't understand the goal.
> 
> search won't work in roaming + non-roaming situations.  There are
> solutions being discussed to make that easier, they dovetail into
> this slightly.
> 

Roaming means dhclient right?

SOCK_DNS sounds like a great clue.

Chris

Re: rebound quantum entanglement

[Chris Cappuccio]

Bryan Steele [bry...@gmail.com] wrote:
> On Thu, Sep 15, 2016 at 10:14:51AM -0400, Ted Unangst wrote:
> > Florian Obser wrote:
> > > Not everything listening on localhost port 53 is a recursive resolver.
> > > nsd(8) per defaults listens on 0.0.0.0 and will respond with REFUSED for
> > > almost every query. asr stops in that case and does not try the next
> > > resolver in the list.
> > 
> > Ah! There's the catch. The good news is I think we can still bind to
> > localhost:53 if nsd is on *:53 (right?). This matters if rebound isn't
> > listening.
> 
> Perhaps I'm confused, but what happens when rebound is stopped by the
> user or it crashes? I think that would mean requests would fallback to
> nsd on *:53 which as Florian mentioned, would not try the next
> nameserver in resolv.conf.
> 

This entire discussion is bat-shit crazy to me!

Adding secret nameservers to resolv.conf is plain wrong. Hijacking the
libc resolver is an approach for systemd, not OpenBSD.

I already configure special nameservers on certain machines, that
bind to 127.0.0.1, for my own reasons. In a general sense, when
I configure the system to do something, and it does something
different, I now have to recompile libc. What !??!?!

This point that has been reached in this discussion just reinforces
the idea that this approach is wrong.

The sensible thing to do is add a 'search' parameter to resolv.conf. 
If programs parse resolv.conf themselves, and they break, we should
fix them. 

It seems like the default should be 'search rebound file bind' and
'search rebound bind file' if no 'lookup' keyword is specified. Most
users won't ever have 'search rebound' visible in their resolv.conf.

That rebound acts like a nameserver is what prompted the idea to
hijack the resolver. But it's really a tool that takes over certain
duties from the libc resolver, so the libc resolver should be properly
configurable to hand over duties, or not. 'search' is the logical
place for this.

Chris

Re: switch the cubie miniroot to cubieboard2

[Chris Cappuccio]

si...@slackware.it [si...@slackware.it] wrote:
> Speaking as a Cubieboard owner here ;-)
> Would it be too much hassle to provide both images? (and a pony!)
> 

It's fairly easy to take a miniroot image for a similar board, and
adapt it to your board.

Since both the Cubieboard and Cubieboard2 are Allwinner based,
the miniroot's general structure does not change.

1. Install u-boot-2016.07p1 from ports/packages (packages if you don't
want to wait all day)

2. Examine /usr/src/distrib/armv7/ramdisk/install.md and find
a similar board (same or similar chipset).

3. Find the proper u-boot/dtb stuff in /usr/local/share/u-boot

4. Download the miniroot image for a board that has the same
or similar chipset to your board

5. vnconfig vnd0 miniroot.fs

6. Install proper u-boot image to the miniroot image. The install.md
file tells you how to copy the proper u-boot/dtb over. For instance,
Cubieboard is Allwinner A10/A20, and my Lime is A20.

install.md says:

cubie)
dd if=$_mdec/u-boot-sunxi-with-spl.bin of=${_disk}c \
bs=1024 seek=8 >/dev/null 2>&1

So, to get my Lime or Lime2 working, I do this:

dd if=/usr/local/share/u-boot/A20-OLinuXino-Lime2/u-boot-sunxi-with-spl.bin 
of=/dev/rvnd0c bs=1024 seek=8

(Note: Lime and lime2 bootloaders will appear to work on both boards,
but if you don't use the right one, the Realtek ethernet PHY will
not be properly initialized.)

7. vnconfig -u vnd0

8. Write miniroot.fs to your SD card

You don't have to use vnd, but this is conceptually simpler
and less error prone than trying to chop it up with dd.

Chris

Re: ifconfig baudrate

[Chris Cappuccio]

Reyk Floeter [r...@openbsd.org] wrote:
> 
> Ok, it makes some sense to have this information for Ethernet.
> 

I am strongly opposed to this change on wired or wireless. Why the
push for having less information?

> For 11n and all these new wireless rates it doesn't provide any useful
> information, what does "HT-MCS0" mean?  Or "HT-MCS70"?  In this case
> it would be much more useful to have the actual speed and not some
> obscure technical details from 802.11.
> 

This is a standard. On 11n, everything from MCS0 to MCS7 is
the single stream version of MCS8 to MCS15. The PHY rate can't tell
you which is in effect alone. We don't support >MCS7 yet so maybe
this is less obvious.

You want to go away from having to know anything about the 11n
MCS table to figure out your expected baud rate? You should
display both.

I'd much rather know what modulation and error coding scheme is in
effect, than know only what the physical data rate is. It's utterly
meaningless by itself.

Chris

Re: armv7 Cortex-A7 fix

[Chris Cappuccio]

Tinker [ti...@openmailbox.org] wrote:
> On 2016-08-11 08:30, Mark Kettenis wrote:
> > Finally found the pmap bug that kept Cortex-A7 from working.  Turns
> > out we have to flush the TLB when removing a L1 slot as well.  Already
> > committed the diff, but here it is for those that are interested.
> 
> For the unintroduced but curious, of what material consequence was the pmap
> bug

Crashes on boot up

> and what works that did not work previously, now that it's fixed?
> 

Now it boots up successfully!!

You gotta know when hold 'em, know when to fold 'em, know when flush your TLBs, 
know when to run...

Re: read(2) on directories

[Chris Cappuccio]

Todd C. Miller [todd.mil...@courtesan.com] wrote:
> On Tue, 12 Jul 2016 12:47:46 -0700, Chris Cappuccio wrote:
> 
> > I've personally always liked being able to cat / read() a directory
> > since it gives you a peek behind the curtain and reflects the
> > reality of how the filesystem is constructed. 
> 
> You haven't been able to do that on OpenBSD for a very long time.
> 

I've been in a deep depression ever since :)

Re: read(2) on directories

[Chris Cappuccio]

Todd C. Miller [todd.mil...@courtesan.com] wrote:
> >From source inspection, Net and Free appear to allow read(2) of
> dirs to succeed.  However, since Linux, Mac OS X and Solaris have
> the EISDIR behavior I think it is probably safe from a portability
> standpoint.
> 
> We're long past the days when opendir(3)/readdir(3) used read(2)...
> 
> HP-UX and AIX still allow reads of directories but no one cares
> about them ;-)
> 

I've personally always liked being able to cat / read() a directory
since it gives you a peek behind the curtain and reflects the
reality of how the filesystem is constructed. 

Re: [PATCH] let the mbufs use more then 4gb of memory

[Chris Cappuccio]

Mark Kettenis [mark.kette...@xs4all.nl] wrote:
> 
> We really don't want to implement bounce-buffers.  Adding IOMMU
> support is probably a better approach as it also brings some security
> benefits.  Not all amd64 hardware supports an IOMMU.  And hardware
> that does support it doesn't always have it enabled.  But for modern
> hardware an iommu is pretty much standard, except for the absolute
> low-end.  But those low-end machines tend to have only 2GB of memory
> anyway.

Is the sparc64 iommu code port usable for this purpose?

http://cvsweb.openbsd.org/cgi-bin/cvsweb/src/sys/arch/amd64/amd64/Attic/sg_dma.c

Re: LTE umsm

[Chris Cappuccio]

Martin Pieuchot [m...@openbsd.org] wrote:
> On 20/05/16(Fri) 09:47, Chris Cappuccio wrote:
> > So to just remove the ifaceno check, here's the diff.
> > 
> > This matches u3g behaviour for SIERRA TRUINSTALL devices. There is
> > still a bit of hardcoded stuff that needs to be reviewed in umsm
> > for other devices. I think yuo@ was trying to match some of these
> > style checks when he added support for these devices (but it
> > does not appear to be necessary to isolate based on ifaceno for
> > u3g)
> 
> Did you try this with the corresponding device?
> 

I tested the 313U and 770S. 

Re: LTE umsm

[Chris Cappuccio]

So to just remove the ifaceno check, here's the diff.

This matches u3g behaviour for SIERRA TRUINSTALL devices. There is
still a bit of hardcoded stuff that needs to be reviewed in umsm
for other devices. I think yuo@ was trying to match some of these
style checks when he added support for these devices (but it
does not appear to be necessary to isolate based on ifaceno for
u3g)

Index: umsm.c
===
RCS file: /cvs/src/sys/dev/usb/umsm.c,v
retrieving revision 1.104
diff -u -p -u -r1.104 umsm.c
--- umsm.c  29 Sep 2015 08:34:28 -  1.104
+++ umsm.c  20 May 2016 16:37:08 -
@@ -115,6 +115,7 @@ struct umsm_type {
 
 static const struct umsm_type umsm_devs[] = {
{{ USB_VENDOR_AIRPRIME, USB_PRODUCT_AIRPRIME_PC5220 }, 0},
+   {{ USB_VENDOR_AIRPRIME, USB_PRODUCT_AIRPRIME_AIRCARD_313U }, 0},
 
{{ USB_VENDOR_ANYDATA,  USB_PRODUCT_ANYDATA_A2502 }, 0},
{{ USB_VENDOR_ANYDATA,  USB_PRODUCT_ANYDATA_ADU_500A }, 0},
@@ -247,6 +248,7 @@ static const struct umsm_type umsm_devs[
{{ USB_VENDOR_SIERRA, USB_PRODUCT_SIERRA_USB305}, 0},
{{ USB_VENDOR_SIERRA, USB_PRODUCT_SIERRA_TRUINSTALL }, DEV_TRUINSTALL},
{{ USB_VENDOR_SIERRA, USB_PRODUCT_SIERRA_MC8355}, 0},
+   {{ USB_VENDOR_SIERRA, USB_PRODUCT_SIERRA_AIRCARD_770S}, 0},
 
{{ USB_VENDOR_TCTMOBILE, USB_PRODUCT_TCTMOBILE_UMASS }, DEV_UMASS3},
{{ USB_VENDOR_TCTMOBILE, USB_PRODUCT_TCTMOBILE_UMASS_2 }, DEV_UMASS3},
@@ -358,8 +360,7 @@ umsm_attach(struct device *parent, struc
 umsm_huawei_changemode(uaa->device);
printf("%s: umass only mode. need to reattach\n",
sc->sc_dev.dv_xname);
-   } else if ((sc->sc_flag & DEV_TRUINSTALL) &&
-   uaa->ifaceno == 0) {
+   } else if (sc->sc_flag & DEV_TRUINSTALL) {
umsm_truinstall_changemode(uaa->device);
printf("%s: truinstall mode. need to reattach\n",
sc->sc_dev.dv_xname);

Re: LTE umsm

[Chris Cappuccio]

Martin Pieuchot [m...@openbsd.org] wrote:
> On 19/05/16(Thu) 19:27, Chris Cappuccio wrote:
> > Here is a patch to support some newer LTE umsm devices
> > 
> > Yes, the 313U actually has an SD card slot. And yes, it actually
> > changes vendor ID to Airprime after the umsm_truinstall_changemode
> > takes place.
> > 
> > Matching ifaceno == 9 for newer USB_PRODUCT_SIERRA_TRUINSTALL devices
> > is necessary. They don't show up as 0. (It's possible that Huawei will
> > will need the same treatment in umsm_attach if they use newer umsm chips)
> 
> No.  Hardcoding interface number is not the way to go.  Interfaces
> descriptors have a class, subclass and protocol that should be looked
> at. 
> 
> In 3 months a new device will show up with different interfaces layout and
> we will have to hardcode something else?
> 

I agree in principle, however in practice, the goal is to run
umsm_truinstall_changemode to get the device to present itself in a useful
manner.

Before umsm_truinstall_changemode, the class is UICLASS_MASS, subclass
UISUBCLASS_SCSI, and protocol UIPROTO_MASS_BBB. That's a USB disk.

FreeBSD's u3g driver is similar. We could match FreeBSD behavior by simply
removing the ifnaceno check. Then we are just matching on
USB_PRODUCT_SIERRA_TRUINSTALL and UICLASS_MASS.

Chris

LTE umsm

[Chris Cappuccio]

Here is a patch to support some newer LTE umsm devices

Yes, the 313U actually has an SD card slot. And yes, it actually
changes vendor ID to Airprime after the umsm_truinstall_changemode
takes place.

Matching ifaceno == 9 for newer USB_PRODUCT_SIERRA_TRUINSTALL devices
is necessary. They don't show up as 0. (It's possible that Huawei will
will need the same treatment in umsm_attach if they use newer umsm chips)

ok?

Aircard 313U:

umsm0 at uhub5 port 3 configuration 1 interface 9 "Sierra Wireless, 
Incorporated USB MMC Storage" rev 2.00/0.00 addr 5
umsm0: truinstall mode. need to reattach
umsm0 detached
umsm0 at uhub5 port 3 configuration 1 interface 0 "Sierra Wireless, 
Incorporated AirCard 313U" rev 2.00/0.06 addr 5
ucom1 at umsm0
umsm1 at uhub5 port 3 configuration 1 interface 1 "Sierra Wireless, 
Incorporated AirCard 313U" rev 2.00/0.06 addr 5
ucom2 at umsm1
umsm2 at uhub5 port 3 configuration 1 interface 2 "Sierra Wireless, 
Incorporated AirCard 313U" rev 2.00/0.06 addr 5
ucom3 at umsm2
umsm3 at uhub5 port 3 configuration 1 interface 3 "Sierra Wireless, 
Incorporated AirCard 313U" rev 2.00/0.06 addr 5
ucom4 at umsm3
umsm4 at uhub5 port 3 configuration 1 interface 4 "Sierra Wireless, 
Incorporated AirCard 313U" rev 2.00/0.06 addr 5
ucom5 at umsm4
umass1 at uhub5 port 3 configuration 1 interface 9 "Sierra Wireless, 
Incorporated AirCard 313U" rev 2.00/0.06 addr 5
umass1: using SCSI over Bulk-Only
scsibus3 at umass1: 2 targets, initiator 0
sd5 at scsibus3 targ 1 lun 0:  SCSI2 0/direct removable 
serial.0f3d68aa615000291196
umsm5 at uhub5 port 3 configuration 1 interface 7 "Sierra Wireless, 
Incorporated AirCard 313U" rev 2.00/0.06 addr 5
ucom6 at umsm5

Aircard 770S:

umsm0 at uhub5 port 3 configuration 1 interface 9 "NETGEAR, Inc. AirCard 770S" 
rev 2.00/0.06 addr 5
umsm0: truinstall mode. need to reattach
umsm0 detached
umsm0 at uhub5 port 3 configuration 1 interface 3 "NETGEAR, Inc. AirCard 770S" 
rev 2.00/0.06 addr 5
ucom1 at umsm0
umsm1 at uhub5 port 3 configuration 1 interface 8 "NETGEAR, Inc. AirCard 770S" 
rev 2.00/0.06 addr 5
ucom2 at umsm1
umsm2 at uhub5 port 3 configuration 1 interface 0 "NETGEAR, Inc. AirCard 770S" 
rev 2.00/0.06 addr 5
ucom3 at umsm2

Index: umsm.c
===
RCS file: /cvs/src/sys/dev/usb/umsm.c,v
retrieving revision 1.104
diff -u -p -u -r1.104 umsm.c
--- umsm.c  29 Sep 2015 08:34:28 -  1.104
+++ umsm.c  20 May 2016 02:05:54 -
@@ -115,6 +115,7 @@ struct umsm_type {
 
 static const struct umsm_type umsm_devs[] = {
{{ USB_VENDOR_AIRPRIME, USB_PRODUCT_AIRPRIME_PC5220 }, 0},
+   {{ USB_VENDOR_AIRPRIME, USB_PRODUCT_AIRPRIME_AIRCARD_313U }, 0},
 
{{ USB_VENDOR_ANYDATA,  USB_PRODUCT_ANYDATA_A2502 }, 0},
{{ USB_VENDOR_ANYDATA,  USB_PRODUCT_ANYDATA_ADU_500A }, 0},
@@ -247,6 +248,7 @@ static const struct umsm_type umsm_devs[
{{ USB_VENDOR_SIERRA, USB_PRODUCT_SIERRA_USB305}, 0},
{{ USB_VENDOR_SIERRA, USB_PRODUCT_SIERRA_TRUINSTALL }, DEV_TRUINSTALL},
{{ USB_VENDOR_SIERRA, USB_PRODUCT_SIERRA_MC8355}, 0},
+   {{ USB_VENDOR_SIERRA, USB_PRODUCT_SIERRA_AIRCARD_770S}, 0},
 
{{ USB_VENDOR_TCTMOBILE, USB_PRODUCT_TCTMOBILE_UMASS }, DEV_UMASS3},
{{ USB_VENDOR_TCTMOBILE, USB_PRODUCT_TCTMOBILE_UMASS_2 }, DEV_UMASS3},
@@ -359,7 +361,7 @@ umsm_attach(struct device *parent, struc
printf("%s: umass only mode. need to reattach\n",
sc->sc_dev.dv_xname);
} else if ((sc->sc_flag & DEV_TRUINSTALL) &&
-   uaa->ifaceno == 0) {
+   (uaa->ifaceno == 0 || uaa->ifaceno == 9)) {
umsm_truinstall_changemode(uaa->device);
printf("%s: truinstall mode. need to reattach\n",
sc->sc_dev.dv_xname);

Re: Is loss of read-only /usr permanent?

[Chris Cappuccio]

RD Thrush [openbsd-t...@thrush.com] wrote:
> On 05/13/16 11:07, Theo de Raadt wrote:
> >> Since the anti-ROP mechanism in libc [2] was added in late April, -current 
> >> with read-only /usr produces something like the following message:
> >> re-ordering libraries:install: /usr/lib/INS@OPOjn7ck17: Read-only file 
> >> system
> > 
> > Look, your statement is false.  I can install a snapshot right now,
> > and I won't see what you report.
> 
> The report is fairly easy to reproduce.  Make the /usr filesystem read-only 
> in /etc/fstab, go to single user mode and exit back to multi-user.  I've 
> appended a transcript.
> 
> > That is the result of a mis-configuration on your part.
> 
> It's unfortunate that mounting /usr read-only is now a mis-configuration.
> 

Robert, what do you suggest?

1. Say sorry, no mitigation because we want to support all possible
configurations

2. Say OK, and provide a work-around in /etc/rc that might (or might not)
work with your situation, and makes the overall situation more complicated
for everyone

3. Say sorry, the mitigation technique will not be changed. You are on your
own.

I think it comes down to this. If you want read-only /etc, you'll have to
modify /etc/rc, if you still want the mitigation.

Re: pledge: telnet should not verify if hostname is a fully qualified domain

[Chris Cappuccio]

Adam Wolk [adam.w...@tintagel.pl] wrote:
>
> I would like to just drop that part of code. Any OK's, comments?
> 

Please do. It's utterly useless. ok chris@

> Index: commands.c
> ===
> RCS file: /cvs/src/usr.bin/telnet/commands.c,v
> retrieving revision 1.83
> diff -u -p -r1.83 commands.c
> --- commands.c16 Mar 2016 15:41:11 -  1.83
> +++ commands.c3 May 2016 00:24:51 -
> @@ -1445,14 +1445,6 @@ env_init(void)
>  
>   gethostname(hbuf, sizeof hbuf);
>  
> - /* If this is not the full name, try to get it via DNS */
> - if (strchr(hbuf, '.') == 0) {
> - struct hostent *he = gethostbyname(hbuf);
> - if (he != 0)
> - strncpy(hbuf, he->h_name, sizeof hbuf-1);
> - hbuf[sizeof hbuf-1] = '\0';
> - }
> -
>   if (asprintf (, "%s%s", hbuf, cp2) == -1)
>   err(1, "asprintf");
>  

Re: dc patch

[Chris Cappuccio]

Edgar Pettijohn [ed...@pettijohn-web.com] wrote:
> nevermind just found the elusive "q"
> 

There's always the universal ^D

Re: APU1 ethernet LEDs

[Chris Cappuccio]

Did you bring this up to Pascal Dornier ? I think he would rather fix
the eeprom...

This is specific to the hardware layout, the eeprom is the right place,
not the driver!

On the other hand, I think the CSR_WRITE_1 is perfectly clear

Stuart Henderson [s...@spacehopper.org] wrote:
> The re(4) variant on the PC Engines APU1, RTL8111E, has a flexible LED
> configuration. The nic's default config seems to be intended for
> controlling 3 LEDs (or one single-colour and a bi-colour LED with
> different colours to indicate link speed) however the ethernet ports
> on the APU1 only have two LEDs (one green one amber).
> 
> Defaults can be changed in eeprom but (intentionally or not) this
> hasn't been done on the APU1 so in normal situations with a 1GB link,
> you only ever see one lit LED, and even that is normally off, only
> blinking for activity. I don't know of any APU users who like
> the default setup.
> 
> Section 6.2.6 of the RTL8111E-VB-GR / -VB-CG / -VC-CG datasheet
> tells us how to reprogramme it. Do we want to change it?
> 
> Without diff:
> 
> green: normally off, blink on for activity.
> amber: on solid for 100MB link, off for 1GB link.
> 
> With diff:
> 
> green: normally on if link at any speed. blink off for activity.
> amber: on solid for 1GB link, otherwise off.
> 
> Some other settings are possible but I think this gives the best
> combination of information under "normal" conditions given only
> 2 LEDs.
> 
> Looking at unique "RTL8168E/8111E (0x2c00)" entries from dmesglog
> back to Feb 2013, there are 7 APUs (=21 NICs), and 20 non-APUs.
> Do we care if we change led state for those others too? We could
> check the MAC vendor for 00:0d:b9, but I think this is unnecessary
> complexity (and who knows, maybe it's an improvement for some of
> those too).
> 
> Any comments/OKs? (I am not 100% happy with the clarity of the new
> CSR_WRITE_1 line, but my earlier iterations were worse ;)
> 

Re: New scheduler for OpenBSD

[Chris Cappuccio]

Michal Mazurek [akf...@jasminek.net] wrote:
> On 16:28:33, 14.03.16, Martin Pieuchot wrote:
> > > The number of calls to yield() dropped to 4,576.
> > 
> > This is really similar to what I observed with Firefox and Chrome.
> > 
> > > This is where I get stuck, I don't know how to replace the call to
> > > sched_yield(), or whether it is a good idea to do so. Any advice?
> > 
> > I'd assume the problem is not in the _spinlock() implementation itself
> > but rather on the code calling this lock.  Do you know which code is
> > triggering this?
> > 
> > See r1.13 of lib/librthread/rthread_libc.c, this is an example where a
> > the use of a spinlock created similar symptoms.
> 
> I don't know how to fix it, but in the meanwhile here is a workaround so
> I can continue working on the scheduler. In yield():
> 
> + tmp = p->p_rrticks;
> + sched_deadline(p);
> + p->p_rrticks = tmp;
> 
> So penalise a process calling yield() by giving it the worst deadline,
> i.e. make it go to the end of the run queue.
> 
> Other than this, no changes.
> 
> Chrome still isn't smooth.
> 

On a frankenstein 5.9 kernel with bob beck's latest NOWAIT vfs_biomem buffer 
alloc and this, I'm getting very smooth action on chrome, with video, even on
an old x201. I don't remember the last time it could re-open 20 tabs without
constantly pausing most of itself, or the last time youtube videos would
play on this laptop in chrome, without random and frequenty stuttering.

Re: New scheduler for OpenBSD

[Chris Cappuccio]

Bob Beck [b...@openbsd.org] wrote:
> this is cool .. but
> 
> I would be interested in someone comparing server workloads, as
> opposed to interactive GUI response, using this.
> 
> I wouldn't be surprised that inspiriation from BFS would produce
> better interactive response, my bigger concern
> would be does this adversely impact how we deal with non-interactive 
> workloads.

I've been testing it on my heavily loaded Zabbix server, which regularly
get dozens of variables from over 5,000 devices. I get mixed results, the
load avg is higher, and the idle cpu time is generally higher, I regularly
see 1 second (top 's 1') CPU idle of 50-70% where I regularly saw 20-50% 
with the old scheduler. This is in top with all cpus collasped into 1 (top
'1'). I suspect if I averaged it over time, the difference could be less   
dramatic.

I'm using Postgres, there is no heavily threaded stuff, so I have
no idea why the idle CPU seems to be higher. The load avg is a bit higher,
it seems to stay up around 48 longer with the new scheduler, and also
shoots up and down more quickly. None of this is particularly well measured,
just a weird observation. With the old scheduler the load avg would fluctuate
from 32-42, and seemed to stay at a particular value for a longer period
of time (whatever that means.)

Zabbix is a horrible pig, and my polling confiuguration is not fine-tuned 
to top it off. The box is a "Xeon E2-1230 v3 @ 3.30GHz" with 16GB RAM and
two Samsung 845DC SSDs in softraid raid1. We use Postgres as a time-series
database, I'm looking at alternatives using collectd and graphite and
whatever, I really want to get away from Zabbix + Postgres.

Since this scheduler has a hack to help spinning threaded apps, that
explains why there is less CPU usage during video playback, but I don't
know how to explain my Zabbix results. It takes at least 2 minutes after
boot before the Zabbix box stabilizes to the levels I'm describing
here. 

If I set top to .1 second (top 's .1') then the new scheduler seems to
drive all CPUs to 0% idle for shorter periods of time, but more
frequently.

These are really rough observations. This box spawns lots of dirty
perl processes and also lots of fping processes for monitoring. I've
not spent the time to optimize this area at all. I was curious if this
scheduler or other OS level optmizations might take away some of the
costs here. With this rather stupid polling architecture, perhaps
copy-on-write is still the biggest win...

Chris

Re: New scheduler for OpenBSD

[Chris Cappuccio]

Alexandre Ratchov [a...@caoua.org] wrote:
> On Tue, Mar 15, 2016 at 03:05:47PM +0100, Michal Mazurek wrote:
> > 
> > Please test, and let me know if the performance of something else
> > degrades.
> > 
> 
> With your diff firefox consumes twice less cpu (watched the same
> video with and without the diff).  This suggests firefox spins
> somewhere and your diff makes it spin less.
> 
> When audio device is using small blocks it stutters more with your
> diff though; according to device counters the stuttering is caused
> by sndiod not getting the cpu fast enough.

there is no 'nice' functionality at the moment

Re: remove net80211 turbo mode

[Chris Cappuccio]

Stuart Henderson [st...@openbsd.org] wrote:
> 
> +1, I wondered if we should do this when reading the 11n diffs.
> 
> If people need more speed it's likely that they will get better
> performance with 20MHz channels on a newer radio/MAC than 40MHz
> on a 10-year-old one.
> 
> Free the spectrum!

i've never seen any significant improvement from the old 40mhz mode,
just much higher noise sensitivity

Re: mpsafe re(4)

[Chris Cappuccio]

Dimitris Papastamos [s...@2f30.org] wrote:
> On Sat, Dec 05, 2015 at 06:11:51PM +0100, Jonathan Matthew wrote:
> > The main interesting bit here is the txeof and start loops, which previously
> > operated based on the prod/cons indices and the contents of the tx queue,
> > but now just uses the indices as that's the only way to get a consistent 
> > view
> > of the tx queue state.
> > 
> > At the moment I don't think the tx ring is big enough to use IFQ_DEQUEUE
> > instead of ifq_deq_begin/commit, but maybe I'm wrong about that.
> > 
> > can someone try this on an APU1?
> 
> I've tested this on my router and it seems to work okay.  I've also used
> tcpbench with various combinations.
> 
> re0 at pci2 dev 0 function 0 "Realtek 8168" rev 0x0c: RTL8168G/8111G
> (0x4c00), msi, address 80:ee:73:9f:1d:3e
> re1 at pci3 dev 0 function 0 "Realtek 8168" rev 0x0c: RTL8168G/8111G
> (0x4c00), msi, address 80:ee:73:9f:1d:3d

Testing fine for me on APU1 so far.

Re: PC Engines APU2 coming soon - how is OpenBSD's support so far?

[Chris Cappuccio]

Noth [nothingn...@citycable.ch] wrote:
> Hi again,
> 
>   I think I've found a bug: if I have a console session open using minicom
> or cu when rebooting, the machine hangs. This doesn't happen with either
> CentOS Linux 7 or FreeBSD 10.2 / 11. I can reproduce the problem. Anyone
> else have this issue ?
> 

The boot loader output is emulated video output until it switches to com0.
Once it reads 'stty com0 115200; set tty com0' from /etc/boot.conf, it 
switches from video output to serial output.

During the switch, some contents comes out of the boot loader that is at
the wrong baud rate (or something similar). This causes some high characters
to come out, which your terminal emulator might interpret as a terminal command
and it could even send a short reply back. If it does, this reply stops the
auto-boot process and you sit at boot> indefinitely.

The solution is to not leave a terminal emulator connected during the boot
(or fix the boot loader to not output high characters)

Re: PC Engines APU2 coming soon - how is OpenBSD's support so far?

[Chris Cappuccio]

Noth [nothingn...@citycable.ch] wrote:
> No it freezes after the "rebooting..." message appears. It isn't before the
> firmware restarts. Hopefully the next firmware release will some kind of fix
> for this.
> 

The non-ACPI kernel does this (bsd.rd). bsd should not do this

Re: PC Engines APU2 coming soon - how is OpenBSD's support so far?

[Chris Cappuccio]

Mathias Schmocker [s...@smat.ch] wrote:
> 
> First tests with a bootable OpenBSD amd64 5.8-current USB stick and
> installation on the 16GB mSata internal storage.
> After reboot, BIOS could find mSata to boot on, but defaulted to the memtest
> boot payload
> 

This is a setting you can change, although the default boot order would put 
memtest last.

I've had no problems with apu2 detecting msata so far..

> Unable to abort memtest by pressing (esc) on the serial console, or (c) for
> configure.
> 

You have to escape to the prompt before memtest starts.

Re: PC Engines APU2 coming soon - how is OpenBSD's support so far?

[Chris Cappuccio]

Brian Conway [bcon...@rcesoftware.com] wrote:
> I meant positioning the whole case bottom-up (i.e. but the hot surface
> at the top).

Oh I see!

I just got a beta unit. I was late to the party. I used some of this
ZM-STG1 thermal grease (comes with a paint applicator type brush) and
the integrated memtest goes between 46 and 47 C. With intel ethernet,
four cores and usb3, this is a pretty nice unit!

I wonder if these are four discrete cores or if AMD is playing games
(like the bulldozer lawsuit as of late.)

Chris

Re: PC Engines APU2 coming soon - how is OpenBSD's support so far?

[Chris Cappuccio]

Brian Conway [bcon...@rcesoftware.com] wrote:
> 
> Taking into account Mr. Cappuccio's advice on using thermal paste
> between the CPU and heat spreader, and also positioning it bottom-up,
> this one stabilized at 51 C at idle. I haven't had a chance to do much
> benchmarking for higher temps yet, other than a run of `openssl speed`
> to warm it up.

If you put the heat speader upside down, the sticky pad would be against
the cpu heatsink contact area?? There's only one way to put that device in.

Re: restricting DNS to port 53

[Chris Cappuccio]

gwes [g...@oat.com] wrote:
> Will unbound and nsd be restricted to port 53 only?
> 

No

Re: PC Engines APU2 coming soon - how is OpenBSD's support so far?

[Chris Cappuccio]

Noth,
I got my APU (first rev) to go from 56-58 temps down to 49-50 by using heatsink 
paste instead of the thermal pad...

Noth [nothingn...@citycable.ch] wrote:
> Thanks Stuart, that works for me!
> 
> # sysctl hw
> hw.machine=amd64
> hw.model=AMD GX-412TC SOC
> hw.ncpu=4
> hw.byteorder=1234
> hw.pagesize=4096
> hw.disknames=sd0:47e18331a1a8156e
> hw.diskcount=1
> hw.sensors.km0.temp0=59.38 degC
> hw.cpuspeed=998
> hw.setperf=100
> hw.vendor=PC Engines
> hw.product=apu2
> hw.version=1.0
> hw.serialno=123456789
> hw.physmem=4261081088
> hw.usermem=4261056512
> hw.ncpufound=4
> hw.allowpowerdown=1
> hw.perfpolicy=manual
> 
> On 04/11/15 18:47, Stuart Henderson wrote:
> >this will probably get you a cpu temperature sensor.
> >
> >Index: km.c
> >===
> >RCS file: /cvs/src/sys/dev/pci/km.c,v
> >retrieving revision 1.10
> >diff -u -p -r1.10 km.c
> >--- km.c 14 Mar 2015 03:38:48 -  1.10
> >+++ km.c 4 Nov 2015 17:44:25 -
> >@@ -72,7 +72,8 @@ static const struct pci_matchid km_devic
> > { PCI_VENDOR_AMD, PCI_PRODUCT_AMD_AMD64_14_MISC },
> > { PCI_VENDOR_AMD, PCI_PRODUCT_AMD_AMD64_15_0x_MISC },
> > { PCI_VENDOR_AMD, PCI_PRODUCT_AMD_AMD64_15_1x_MISC },
> >-{ PCI_VENDOR_AMD, PCI_PRODUCT_AMD_AMD64_16_MISC }
> >+{ PCI_VENDOR_AMD, PCI_PRODUCT_AMD_AMD64_16_MISC },
> >+{ PCI_VENDOR_AMD, PCI_PRODUCT_AMD_AMD64_16_3X_MISC }
> >  };
> >

Re: Purge route entries when an address is removed

[Chris Cappuccio]

Martin Pieuchot [m...@openbsd.org] wrote:
> Currently we leave RTF_STATIC route entries in the table when the
> address they are attached to is removed from a system.
> 
> That's why ifas need to be refcounted and that's why we have *a lot*
> of checks in the stack to not use cached routes attached to such ifa.
> 
> I'd like to simplify all of this by simply purging all the routes
> attached to an ifa being removed.  This behavior is coherent with
> the fact that routes *need* an ifa to be inserted in the table.
> 
> This makes the kernel simpler as it no longer try to find a new ifa
> when a route with a stale address is being used.
> 

I'm pretty sure this feature has been broken for a while. Once upon
a time in OpenBSD, this used to work:

ifconfig em0 192.168.1.2/24
route add default 192.168.1.1
ping 8.8.8.8
reply!
ifconfig em0 delete 192.168.1.2
ifconfig em1 192.168.1.2/24
ping 8.8.8.8
reply!

For some years, this has been required:

ifconfig em0 192.168.1.2/24
route add default 192.168.1.1
ping 8.8.8.8  
reply!
ifconfig em0 delete 192.168.1.2
ifconfig em1 192.168.1.2/24
**route delete default**
**route add default 192.168.1.1**
ping 8.8.8.8
reply!

It appears, what you're proposing is:

ifconfig em0 192.168.1.2/24
route add default 192.168.1.1
ping 8.8.8.8
reply!
ifconfig em0 delete 192.168.1.2
ifconfig em1 192.168.1.2/24
**route add default 192.168.1.1**
ping 8.8.8.8
reply!

As a user (only), I really like the original behavior, it seems to be
consistent with the behavior of some other systems, at least in the case
of the default router. If there was some way to do this without stupid
complexity, it might be worth considering.

In any event, what you propose seems much better than the current state
of affairs, where you end up with broken routes in the table that need
nothing more than to be removed.

Chris

Re: whois(1): fix lookup of XX.network

[Chris Cappuccio]

Stuart Henderson [st...@openbsd.org] wrote:
 When I added code to use whois.nic.XX for new TLDs I forgot to think
 about one case, where the TLD is a substring of one of the traditional
 TLDs who have to use the old whois-servers.net method. Specifically,
 trying to lookup a .network name will incorrectly try to use
 network.whois-servers.net - strncasecmp was the wrong decision,
 so this diff switches to strcasecmp instead to fix. They're all
 null-terminated strings.
 

Makes perfect sense
ok chris@

Re: Brainy: User-Triggerable Kernel Memory Leak in execve()

[Chris Cappuccio]

Maxime Villard [m...@m00nbsd.net] wrote:
 
 Now, I believe that this effort is too much for my spare time. If you
 want to say thanks to me for reporting this vulnerability, dear Sam,
 it's never too late.
 

I put here a thanks among others:

Thank you for your effort to help improve the OpenBSD operating system,
to the benefit of its users, developers, and the many others who are
using the code in their own systems. Your work is appreciated, each
commit fixing a bug that you found is perhaps the spiritual thank-you
of which you have detected the subtle presence :)

Chris

Re: softdep by default on AMD64

[Chris Cappuccio]

?? ?? [art.is...@yandex.ru] wrote:
 On Fri, Jul 24, 2015 at 07:56:07AM +0100, Nicholas Marriott wrote:
  generally reliable HAHAHAHAHA
 
 Why irony? It's more or less true for ALL modern computing system.

Think of it as a selling point. OpenBSD ffs softdep: On the cutting
edge of reliability!

Re: Kill arp_ifinit()?

[Chris Cappuccio]

Martin Pieuchot [m...@openbsd.org] wrote:
 On 07/07/15(Tue) 18:02, Martin Pieuchot wrote:
  Maybe not yet but at least I'd like to do the ARP request a bit later.
  
  We create a RTF_LOCAL route entry for every configured address.  So
  use this information to emit a who-has for the configured address.
  
  This also has the advantage of *not* sending an ARP request if 
  something wrong happens between the SIOCSIFADDR ioctl and the
  RTF_LOCAL route creation.
 
 Anybody?
 

Looks ok to me!!

Re: Better de(4) fix

[Chris Cappuccio]

Why do we still prefer de over dc for 211140 ?

Reyk Floeter [r...@openbsd.org] wrote:
 On Thu, Jun 25, 2015 at 09:21:11PM +0200, Mark Kettenis wrote:
  There really is no excuse for using dma_alloc(9) if you have the
  bus_dmatag_t available.
  
  This re-uses tulip_busdma_allocmem(), which simplifies the code for
  allocating the dmamap and such.
  
  Unfortunately I can't test this myself right now.
  
 
 Fixes the panic on Hyper-V, see dmesg below.
 
 Unrelated to that, no interrupts on the nic with the ioapic enabled
 (no traffic and autoneg timeouts).  
 
 Reyk
 
 OpenBSD 5.8-beta (GENERIC.MP) #7: Thu Jun 25 22:03:02 CEST 2015
 root@openbsd.hyperv:/usr/src/sys/arch/amd64/compile/GENERIC.MP
 real mem = 8573091840 (8175MB)
 avail mem = 8309399552 (7924MB)
 mpath0 at root
 scsibus0 at mpath0: 256 targets
 mainbus0 at root
 bios0 at mainbus0: SMBIOS rev. 2.3 @ 0xf8ec0 (216 entries)
 bios0: vendor American Megatrends Inc. version 090006 date 05/23/2012
 bios0: Microsoft Corporation Virtual Machine
 acpi0 at bios0: rev 0
 acpi0: sleep states S0 S5
 acpi0: tables DSDT FACP WAET SLIC OEM0 SRAT APIC OEMB
 acpi0: wakeup devices
 acpitimer0 at acpi0: 3579545 Hz, 32 bits
 acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
 cpu0 at mainbus0: apid 0 (boot processor)
 cpu0: Intel(R) Core(TM) i5-4590 CPU @ 3.30GHz, 1645.76 MHz
 cpu0: 
 FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,SS,SSE3,PCLMUL,SSSE3,FMA3,CX16,SSE4.1,SSE4.2,MOVBE,POPCNT,AES,XSAVE,AVX,F16C,RDRAND,HV,NXE,LONG,LAHF,ABM,FSGSBASE,BMI1,HLE,AVX2,SMEP,BMI2,ERMS,RTM
 cpu0: 256KB 64b/line 8-way L2 cache
 cpu0: smt 0, core 0, package 0
 mtrr: Pentium Pro MTRR support, 8 var ranges, 88 fixed ranges
 cpu0: apic clock running at 106MHz
 cpu1 at mainbus0: apid 1 (application processor)
 cpu1: Intel(R) Core(TM) i5-4590 CPU @ 3.30GHz, 1745.46 MHz
 cpu1: 
 FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,SS,SSE3,PCLMUL,SSSE3,FMA3,CX16,SSE4.1,SSE4.2,MOVBE,POPCNT,AES,XSAVE,AVX,F16C,RDRAND,HV,NXE,LONG,LAHF,ABM,FSGSBASE,BMI1,HLE,AVX2,SMEP,BMI2,ERMS,RTM
 cpu1: 256KB 64b/line 8-way L2 cache
 cpu1: smt 0, core 0, package 1
 ioapic0 at mainbus0: apid 0 pa 0xfec0, version 11, 24 pins
 ioapic0: misconfigured as apic 2, remapped to apid 0
 acpiprt0 at acpi0: bus 0 (PCI0)
 acpicpu0 at acpi0
 acpicpu1 at acpi0
 pci0 at mainbus0 bus 0
 pchb0 at pci0 dev 0 function 0 Intel 82443BX rev 0x03
 pcib0 at pci0 dev 7 function 0 Intel 82371AB PIIX4 ISA rev 0x01
 pciide0 at pci0 dev 7 function 1 Intel 82371AB IDE rev 0x01: DMA, channel 0 
 wired to compatibility, channel 1 wired to compatibility
 wd0 at pciide0 channel 0 drive 0: Virtual HD
 wd0: 128-sector PIO, LBA48, 10240MB, 20971520 sectors
 wd0(pciide0:0:0): using PIO mode 4, DMA mode 2
 atapiscsi0 at pciide0 channel 1 drive 0
 scsibus1 at atapiscsi0: 2 targets
 cd0 at scsibus1 targ 0 lun 0: Msft, Virtual CD/ROM, 1.0 ATAPI 5/cdrom 
 removable
 cd0(pciide0:1:0): using PIO mode 4, DMA mode 2
 piixpm0 at pci0 dev 7 function 3 Intel 82371AB Power rev 0x02: SMBus 
 disabled
 vga1 at pci0 dev 8 function 0 Microsoft VGA rev 0x00
 wsdisplay0 at vga1 mux 1: console (80x25, vt100 emulation)
 wsdisplay0: screen 1-5 added (80x25, vt100 emulation)
 de0 at pci0 dev 10 function 0 DEC 21140 rev 0x20, 21140A pass 2.0: apic 0 
 int 11, address 00:15:5d:01:9b:03
 isa0 at pcib0
 isadma0 at isa0
 fdc0 at isa0 port 0x3f0/6 irq 6 drq 2
 fd0 at fdc0 drive 0: 1.44MB 80 cyl, 2 head, 18 sec
 fd1 at fdc0 drive 1: density unknown
 com0 at isa0 port 0x3f8/8 irq 4: ns16550a, 16 byte fifo
 com1 at isa0 port 0x2f8/8 irq 3: ns16550a, 16 byte fifo
 pckbc0 at isa0 port 0x60/5 irq 1 irq 12
 pckbd0 at pckbc0 (kbd slot)
 wskbd0 at pckbd0: console keyboard, using wsdisplay0
 pms0 at pckbc0 (aux slot)
 wsmouse0 at pms0 mux 0
 pcppi0 at isa0 port 0x61
 spkr0 at pcppi0
 vscsi0 at root
 scsibus2 at vscsi0: 256 targets
 softraid0 at root
 scsibus3 at softraid0: 256 targets
 root on wd0a (02632bce06e92172.a) swap on wd0b dump on wd0b
 
 

-- 
The bums will always lose

Re: pfi_kif leaks for PBR rules

[Chris Cappuccio]

Alexandr Nedvedicky [alexandr.nedvedi...@oracle.com] wrote:
 
 is missing at pfr_destroy_kentry(). We created patch against OpenBSD CURRENT.
 We have no OpenBSD boxes around, where we could verify our fix.
 

You are aware that OpenBSD supports both host and guest roles of
Sparc system virtualization ? Quite easy to install, I might add,
it's very simple to setup. As a host of virtual guests, it also
supports a bit of modern Sparc hardware, out-of-the-box.

Chris

Re: rtentry leak

[Chris Cappuccio]

Martin Pieuchot [mpieuc...@nolizard.org] wrote:
 
 Indeed!  And the ifa might also be freed so this chunk is completely
 wrong.  Here's a version of the diff without it, ok?
 

This looks ok to me

 
 Index: net/route.c
 ===
 RCS file: /home/ncvs/src/sys/net/route.c,v
 retrieving revision 1.189
 diff -u -p -r1.189 route.c
 --- net/route.c   4 Nov 2014 15:24:40 -   1.189
 +++ net/route.c   6 Nov 2014 10:24:02 -
 @@ -215,7 +215,7 @@ route_init(void)
  {
   struct domain*dom;
  
 - pool_init(rtentry_pool, sizeof(struct rtentry), 0, 0, 0, rtent,
 + pool_init(rtentry_pool, sizeof(struct rtentry), 0, 0, 0, rtentry,
   NULL);
   rn_init();  /* initialize all zeroes, all ones, mask table */
  
 @@ -1220,7 +1220,7 @@ rt_ifa_addloop(struct ifaddr *ifa)
   if (rt == NULL || !ISSET(rt-rt_flags, flags));
   rt_ifa_add(ifa, RTF_UP | flags, ifa-ifa_addr);
   if (rt)
 - rt-rt_refcnt--;
 + rtfree(rt);
  }
  
  /*
 @@ -1267,7 +1267,7 @@ rt_ifa_delloop(struct ifaddr *ifa)
   if (rt != NULL  ISSET(rt-rt_flags, flags))
   rt_ifa_del(ifa, flags, ifa-ifa_addr);
   if (rt)
 - rt-rt_refcnt--;
 + rtfree(rt);
  }
  
  /*

-- 
The bums will always lose

Re: LibreSSL: GOST ciphers implementation

[Chris Cappuccio]

?? ?? [art.is...@yandex.ru] wrote:
 On Tue, Nov 04, 2014 at 08:42:03PM +, Miod Vallat wrote:
   Two weeks has passed. Is there anything that I can do to
   push GOST ciphers towards LibreSSL?
  
  Sorry about that. Joel and/or I need to review the diff again and push
  it. I'll try to find time for this next week-end (famous last words).
  
  Miod
 
 This is suspicious person for me (group of people?). There are lots of
 commits since about 2011 in many low-level and/or critical components
 from this person: linux kernel, android, gnupg, tcpdump, alsa, tor,
 openssl etc, etc..
 
 I'm almost certainly wrong, but not too much there competencies for one
 person?

So, you're saying, he's really dmi...@svr.gov.ru, the source of Russian
backdoors into technology worldwide!!!

I guess the open-source ecosystem has been thoroughly poisoned!

Putin is going to take us over. OpenBSD and Linux are ruined! Fuck, I'm
switching to Windows 8.

Re: rtentry leak

[Chris Cappuccio]

Martin Pieuchot [mpieuc...@nolizard.org] wrote:
 
 @@ -653,12 +653,12 @@ ifa_ifwithroute(int flags, struct sockad
   struct rtentry  *rt = rtalloc(gateway, 0, rtableid);
   if (rt == NULL)
   return (NULL);
 - rt-rt_refcnt--;
   /* The gateway must be local if the same address family. */
   if ((rt-rt_flags  RTF_GATEWAY) 
   rt_key(rt)-sa_family == dst-sa_family)
   return (NULL);

And
if ((rt-rt_flags  RTF_GATEWAY) 
rt_key(rt)-sa_family == dst-sa_family) {
+   rtfree(rt);
return (NULL);
}


   ifa = rt-rt_ifa;
 + rtfree(rt);
   if (ifa == NULL || ifa-ifa_ifp == NULL)
   return (NULL);

Re: need help setting an encrypted root FS on dual boot system

[Chris Cappuccio]

Matthieu Herrb [matth...@herrb.eu] wrote:
 Hi,
 
 I've a laptop with  Ubuntu 14.04/OpenBSD-current dual boot. 
 I'm trying to convert the OpenBSD FS to softraid(4) encryption with
 passphrase.
 
 I'm booting from an USB drive to access the disk to shuffle data on
 it. 
 
 After backing up my data, changing the OpenBSD disklabel in sd0 to
 have one RAID partition and one swap partition, running bioctl to
 setup an encrypted sd2 softraid and restoring my data, I'm stuck with 
 bootblocks. 
 
 What is the correct installboot incantation to setup bootblocks so
 that Ubuuntu's grub which chainloads the OpenBSD part of the disk
 loads a softraid-aware biosboot ?
 

Doesn't installboot load the first-stage at the beginning of the OpenBSD
partition according to disklabel? Grub is just replacing the MBR. I don't
understand how crypto would make grub-first-stage step any different.
(for that matter, I also don't understand how the first-stage can even
load the second-stage /boot from an encrypted partition!!)

Re: pppoe(4), add example for ipv6

[Chris Cappuccio]

Stuart Henderson [st...@openbsd.org] wrote:
 Any comments on the diff in this?
 
  +#ifdef INET6
  +   sc-sc_sppp.pp_if.if_xflags = ~IFXF_NOINET6;
  +#endif

Aside from what Stefan said, isn't this flag going to be removed
in favor of a flag that explicitly enables INET6 for interfaces?

Re: improving OpenBSD's gmac.c...

[Chris Cappuccio]

Christian Weisgerber [na...@mips.inka.de] wrote:
 John-Mark Gurney:
 
  I also have an implementation of ghash that does a 4 bit lookup table
  version with the table split between cache lines in p4 at:
  https://p4db.freebsd.org/fileViewer.cgi?FSPC=//depot/projects/opencrypto/sys/opencrypto/gfmult.cREV=4
  
  This also has a version with does 4 blocks at a time getting a
  further speed up...
 
 FWIW, I did a quick  dirty merge of this into the OpenBSD tree and
 the speed of my test (net6501-50, tcpbench -u over esp aes-128-gmac)
 almost doubled.
 

That makes me horny.

Re: re(4) mtu 1500

[Chris Cappuccio]

I like MIMO/SISO better than 1x1 2x2 etc. Fix that shit :)

Stuart Henderson [st...@openbsd.org] wrote:
 On 2014/10/06 12:19, Chris Cappuccio wrote:
  Stuart Henderson [s...@spacehopper.org] wrote:
   Does anyone have an idea of what's needed for working jumbos on the
   RL_FLAG_JUMBOV2 variants of re(4) where they're currently disabled?
   These seem to account for most of the chips seen in hardware
   designs from the last couple of years (including APU and some others).
   
   if ((sc-rl_flags  RL_FLAG_JUMBOV2) == 0)
   ifp-if_hardmtu = sc-rl_max_mtu;
   
  
  I think the secrets are here :)
  
  http://svnweb.freebsd.org/base/releng/10.1/sys/dev/re/if_re.c?revision=272461view=markup
  
 
 Ah, more specifically
 
 http://svnweb.freebsd.org/base?view=revisionrevision=217499 /
 http://svnweb.freebsd.org/base/head/sys/dev/re/if_re.c?r1=217498r2=217499pathrev=217499
 
 OK that's probably more than I can figure out how to port without
 hardware then..

-- 
The bums will always lose

Re: re(4) mtu 1500

[Chris Cappuccio]

Stuart Henderson [s...@spacehopper.org] wrote:
 Does anyone have an idea of what's needed for working jumbos on the
 RL_FLAG_JUMBOV2 variants of re(4) where they're currently disabled?
 These seem to account for most of the chips seen in hardware
 designs from the last couple of years (including APU and some others).
 
 if ((sc-rl_flags  RL_FLAG_JUMBOV2) == 0)
 ifp-if_hardmtu = sc-rl_max_mtu;
 

I think the secrets are here :)

http://svnweb.freebsd.org/base/releng/10.1/sys/dev/re/if_re.c?revision=272461view=markup

Re: deprecate scsi_task usage in arc(4)

[Chris Cappuccio]

David Gwynne [da...@gwynne.id.au] wrote:
 can someone test this?
 

Running now.

arc0 at pci3 dev 14 function 0 Areca ARC-1210 rev 0x00: apic 8 int 19
arc0: 4 ports, 256MB SDRAM, firmware V1.43 2007-4-17
scsibus1 at arc0: 16 targets
sd0 at scsibus1 targ 0 lun 0: Areca, ARC-1210-VOL#00, R001 SCSI3 0/direct 
fixed eui.0004d927f800
sd0: 953674MB, 512 bytes/sector, 1953124864 sectors
...
# bioctl arc0
Volume  Status   Size Device  
 arc0 0 Online   99930368 sd0 RAID1 
  0 Online  1000204886016 0:0.0   noencl ST31000528AS CC38
  1 Online  1000204886016 0:1.0   noencl ST31000528AS CC38
# sysctl hw.sensors.arc0
hw.sensors.arc0.drive0=online (sd0), OK

Chris

Re: SSH Sourcing

[Chris Cappuccio]

Nagle, Edwin (James) [edwin.na...@austinenergy.com] wrote:
 Good morning,
 
 My problem is, I am separating users based on interface IP and radius, and 
 therefore need to force their outbound SSH sessions to bind to the IP address 
 of the interface they came in on (or at least a different IP) so I can create 
 firewall rules to restrict outbound access.  However, all outbound SSH 
 sessions are sourced through the default (bnx0) interface and therefore 
 hamper my ability to effectively firewall the outbound SSH requests since the 
 user could be in one of three firewall groups.  I may be just thinking too 
 hard about this but it seems to me there should be (and likely is) a simple 
 way to bind the outgoing connection from the source address.
 
 Any ideas, or should I just create three virtual machines and be done with it?
 
 Again, thanks in advance for any guidance!
 

If each user ID is correlated with a separate IP, you could run different sshd 
each which only allows certain users to log in, and then use pf to restrict 
each user in certain ways. 

Re: let vlan(4) mtu be limited by the parents hardmtu instead of current mtu

[Chris Cappuccio]

Stuart Henderson [st...@openbsd.org] wrote:
 On 2014/08/20 17:17, Chris Cappuccio wrote:
  David Gwynne [da...@gwynne.id.au] wrote:
   sthen@ says this is likely a bit optimistic. while most of our drivers 
   unconditionally configure their max mru, there's some stupid ones that 
   still interpret the configured mtu as a what the mru should be.
   
  
  All the more reason to make this change, I'd say :)
 
 it's not just that - there are some like et(4) with obvious trade-offs visible
 in the driver source code which are only wanted in the case where jumbos are
 actually in use. and who knows what various chips will do internally when the
 command to permit jumbos or raise the valid packet size is sent.
 

I don't think this is relevant. If a chip or driver is buggy in the jumbo MTU
non-vlan case, now it will be buggy in the (somewhat unique) vlan jumbo MTU
case as well

 that said, there is a clear use case for being able to do 1500 MTU packets
 untagged while using jumbos on a vlan...

Yeah

Re: let vlan(4) mtu be limited by the parents hardmtu instead of current mtu

[Chris Cappuccio]

Stuart Henderson [st...@openbsd.org] wrote:
 On 2014/08/21 08:45, Chris Cappuccio wrote:
  Stuart Henderson [st...@openbsd.org] wrote:
   On 2014/08/20 17:17, Chris Cappuccio wrote:
David Gwynne [da...@gwynne.id.au] wrote:
 sthen@ says this is likely a bit optimistic. while most of our 
 drivers unconditionally configure their max mru, there's some stupid 
 ones that still interpret the configured mtu as a what the mru should 
 be.
 

All the more reason to make this change, I'd say :)
   
   it's not just that - there are some like et(4) with obvious trade-offs 
   visible
   in the driver source code which are only wanted in the case where jumbos 
   are
   actually in use. and who knows what various chips will do internally when 
   the
   command to permit jumbos or raise the valid packet size is sent.
   
  
  I don't think this is relevant. If a chip or driver is buggy in the jumbo 
  MTU
  non-vlan case, now it will be buggy in the (somewhat unique) vlan jumbo MTU
  case as well
 
 Oh I was thinking of the case where we changed those drivers to fix things
 so that the 1500 MTU untagged / high MTU tagged state worked which would
 involve downsides for non-jumbo. If you don't care if the new support
 actually works on some chips then that wouldn't apply..
 

Well in the case of if_et, the change the dlg proposes in if_vlan would not
make a difference to the if_et behavior at all. My first glance at et says
hardmtu == mtu 

Re: let vlan(4) mtu be limited by the parents hardmtu instead of current mtu

[Chris Cappuccio]

ok chris@ 

David Gwynne [da...@gwynne.id.au] wrote:
 this lets you have networks on the native vlan on an interface
 at 1500, while setting a child vlan interfaces mtu to jumbos.
 
 ok?
 
 Index: if_vlan.c
 ===
 RCS file: /cvs/src/sys/net/if_vlan.c,v
 retrieving revision 1.108
 diff -u -p -r1.108 if_vlan.c
 --- if_vlan.c 12 Jul 2014 18:44:22 -  1.108
 +++ if_vlan.c 19 Aug 2014 23:52:15 -
 @@ -528,9 +528,9 @@ vlan_ioctl(struct ifnet *ifp, u_long cmd
   case SIOCSIFMTU:
   if (ifv-ifv_p != NULL) {
   if (ifv-ifv_p-if_capabilities  IFCAP_VLAN_MTU)
 - p_mtu = ifv-ifv_p-if_mtu;
 + p_mtu = ifv-ifv_p-if_hardmtu;
   else
 - p_mtu = ifv-ifv_p-if_mtu - EVL_ENCAPLEN;
 + p_mtu = ifv-ifv_p-if_hardmtu - EVL_ENCAPLEN;
   
   if (ifr-ifr_mtu  p_mtu || ifr-ifr_mtu  ETHERMIN)
   error = EINVAL;

Re: let vlan(4) mtu be limited by the parents hardmtu instead of current mtu

[Chris Cappuccio]

David Gwynne [da...@gwynne.id.au] wrote:
 sthen@ says this is likely a bit optimistic. while most of our drivers 
 unconditionally configure their max mru, there's some stupid ones that still 
 interpret the configured mtu as a what the mru should be.
 

All the more reason to make this change, I'd say :)