KERNEL_ASSERT_LOCKED with unlocked sendmsg and sendto + udp6

[Gregor Best]

Hi,

with the patch that unlocks sendmsg and sendto, I get the following
KERNEL_ASSERT_LOCKED (transcribed from a photo of the screen) when I
start avahi_daemon:

panic: kernel diagnostic assertion "_kernel_lock_held()" failed: file 
"/usr/src/sys/net/if.c", line 1382
Stopped at db_enter+0x12: popq %r11
[PS output omitted, avahi_daemon is the active process on the CPU where the 
assertion hit]
[I've also omitted panic() from the traceback and replaced pointer parameters 
with XYZ and the like]

ifa_ifwithaddr(ABC,0) at ifa_ifwithaddr+0xed
in6_pcbselsrc(DEF,GHI,16) at in6_pcbselsrc+0x180
udp6_output(JKL,22d1,0,0) at udp6_output+0x293
sosend(MNO,PQR,STU,107,e,VWX) at sosend+0x351
sendit(YZA,BCD,EFG,HIJ,JKL) at sendit+0x3fb
sys_sendmsg(MNO,1c0,PQR) at sys_sendmsg+0x15a
syscall(STU) at syscall+0x32a
Xsyscall_untramp(6,0,0,0,0,1c) at Xsyscall_untramp+0xe4
end of kernel

If I revert the changes to syscall.master that marked sys_sendmsg and
sys_sendto as SY_NOLOCK, obviously the assertion doesn't get hit.

avahi_daemon is the only program I've seen this with. Chrome and a bunch
of others seem fine, including things that use the libc DNS resolver
(I've configured an unbound listening on ::1 as my DNS in
/etc/resolv.conf, which causes UDP traffic over IPv6 as well).

I'll upload the screen photo tomorrow, but I think I've transcribed the
relevant information from the stack trace that DDB showed.

-- 
Gregor

Re: mbuf statistics, tracking of drops

[Gregor Best]

On Thu, Nov 16, 2017 at 11:13:04AM +1000, David Gwynne wrote:
> 
> > On 16 Nov 2017, at 7:23 am, Gregor Best <g...@unobtanium.de> wrote:
> > 
> > Hi,
> > 
> > On Mon, Nov 13, 2017 at 01:47:01PM +1000, David Gwynne wrote:
> >> [...]
> >> pools maintain count of how many times they failed to provide an
> >> allocation. you can watch this with vmstat -m or systat pool.
> >> however, we could use that to populate mb_drops too.
> >> [...]
> > 
> > That's certainly smarter than my idea.
> 
> does it work though?
> 

Now that I think about it, not quite, or at least not without reaching
around into the pools innards to lock them while reading the statistics
to get a consistent view.

The problem is that the MBSTAT_DROPS part of the `counters` data
structure never gets modified, so we'd still need to loop over all pools
in sysctl_mbstat, since this is not just about mbpool but also about the
pools for payload data.

On the other hand, going back to my initial proposal would mean
essentially duplicating functionality the pools already provide, so
that's at least a bit unelegant. Especially since it adds at least one
splnet/splx dance.

Another option would be to just say "screw it" and count the failed
allocations without acquiring any locks on the pools, maybe via atomic
operations. Sounds a bit too complicated though.

At the moment, and after a night's sleep, I think my initial proposal is
the most straightforward way to do this. That, or getting rid of the
confusing counters in `netstat -m` that stay at 0 all the time...

-- 
Gregor

Re: mbuf statistics, tracking of drops

[Gregor Best]

Hi,

On Mon, Nov 13, 2017 at 01:47:01PM +1000, David Gwynne wrote:
> [...]
> pools maintain count of how many times they failed to provide an
> allocation. you can watch this with vmstat -m or systat pool.
> however, we could use that to populate mb_drops too.
> [...]

That's certainly smarter than my idea.

-- 
Gregor

Re: mbuf statistics, tracking of drops

[Gregor Best]

Hi Martin,

On Sun, Nov 12, 2017 at 03:40:59PM +0100, Martin Pieuchot wrote:
> [...]
> It does, some comments below.
> [...]

Wonderful.

> [...]
> This would be an approximation because it might happen that after
> returning NULL the second pool_get(9) won't sleep.  However I think
> it's the way to go because m_get(9) calls that can wait are generally
> not performance critical.
> [...]

I had not considered that the second pool_get might not block at all. On
the other hand `netstat -m` says "requests for memory delayed" for that
counter, so returning immediately on the second try not counting as a
delay is OK, I think.

> [...]
> Please do not expand the splx().  Only the counter need it.  Simply put
> the NULL check after the splx().
> [...]

I'm not sure I understand. If I move the NULL check after the splx(),
counters_leave() will already have been called so increasing the counter
value has no effect anymore. The only additional things running under
splnet will be a few assignments, so I think moving the splx() a bit
further down does not hurt too much.

Alternatively, I've attached a slightly different suggestion which
doesn't expand the scope of the splx() but duplicates a bit of code.
Does that make more sense?

-- 
Gregor

Index: uipc_mbuf.c
===
RCS file: /home/cvs/src/sys/kern/uipc_mbuf.c,v
retrieving revision 1.250
diff -u -p -r1.250 uipc_mbuf.c
--- uipc_mbuf.c 12 Oct 2017 09:14:16 -  1.250
+++ uipc_mbuf.c 12 Nov 2017 22:09:00 -
@@ -233,11 +233,15 @@ m_get(int nowait, int type)
KDASSERT(type < MT_NTYPES);
 
m = pool_get(, nowait == M_WAIT ? PR_WAITOK : PR_NOWAIT);
-   if (m == NULL)
-   return (NULL);
 
s = splnet();
counters = counters_enter(, mbstat);
+   if (m == NULL) {
+   counters[MBSTAT_DROPS]++;
+   counters_leave(, mbstat);
+   splx(s);
+   return NULL;
+   }
counters[type]++;
counters_leave(, mbstat);
splx(s);
@@ -266,11 +270,15 @@ m_gethdr(int nowait, int type)
KDASSERT(type < MT_NTYPES);
 
m = pool_get(, nowait == M_WAIT ? PR_WAITOK : PR_NOWAIT);
-   if (m == NULL)
-   return (NULL);
 
s = splnet();
counters = counters_enter(, mbstat);
+   if (m == NULL) {
+   counters[MBSTAT_DROPS]++;
+   counters_leave(, mbstat);
+   splx(s);
+   return NULL;
+   }
counters[type]++;
counters_leave(, mbstat);
splx(s);
@@ -349,7 +357,10 @@ m_clget(struct mbuf *m, int how, u_int p
 {
struct mbuf *m0 = NULL;
struct pool *pp;
+   struct counters_ref cr;
+   uint64_t *counters;
caddr_t buf;
+   int s;
 
pp = m_clpool(pktlen);
 #ifdef DIAGNOSTIC
@@ -364,9 +375,16 @@ m_clget(struct mbuf *m, int how, u_int p
 
m = m0;
}
+
buf = pool_get(pp, how == M_WAIT ? PR_WAITOK : PR_NOWAIT);
+
if (buf == NULL) {
m_freem(m0);
+   s = splnet();
+   counters = counters_enter(, mbstat);
+   counters[MBSTAT_DROPS]++;
+   counters_leave(, mbstat);
+   splx(s);
return (NULL);
}

mbuf statistics, tracking of drops

[Gregor Best]

Hi people,

while reading around in /sys/kern/uipc_mbuf.c to try to track down a
problem with my iwm(4) that seems to correlate with mbuf allocation
failures, I noticed that the MBSTAT_DROPS counter and its friends
MBSTAT_{WAIT,DRAIN} don't seem to get increased anywhere in /sys.

Does the patch below the signature make sense for counting MBSTAT_DROPS?

I've got a similar patch for MBSTAT_WAIT, but it's pretty ugly because
as far as I can see, there's no real way to notice when pool_get sleeps
except for "Try pool_get with M_NOWAIT first and if that returns NULL,
try again with M_WAITOK".

-- 
Gregor

Index: /sys/kern/uipc_mbuf.c
===
RCS file: /home/cvs/src/sys/kern/uipc_mbuf.c,v
retrieving revision 1.250
diff -u -p -r1.250 uipc_mbuf.c
--- /sys/kern/uipc_mbuf.c   12 Oct 2017 09:14:16 -  1.250
+++ /sys/kern/uipc_mbuf.c   11 Nov 2017 12:03:39 -
@@ -233,14 +233,14 @@ m_get(int nowait, int type)
KDASSERT(type < MT_NTYPES);
 
m = pool_get(, nowait == M_WAIT ? PR_WAITOK : PR_NOWAIT);
-   if (m == NULL)
-   return (NULL);
 
s = splnet();
counters = counters_enter(, mbstat);
+   if (m == NULL) {
+   counters[MBSTAT_DROPS]++;
+   goto out;
+   }
counters[type]++;
-   counters_leave(, mbstat);
-   splx(s);
 
m->m_type = type;
m->m_next = NULL;
@@ -248,6 +248,10 @@ m_get(int nowait, int type)
m->m_data = m->m_dat;
m->m_flags = 0;
 
+out:
+   counters_leave(, mbstat);
+   splx(s);
+
return (m);
 }
 
@@ -266,16 +270,23 @@ m_gethdr(int nowait, int type)
KDASSERT(type < MT_NTYPES);
 
m = pool_get(, nowait == M_WAIT ? PR_WAITOK : PR_NOWAIT);
-   if (m == NULL)
-   return (NULL);
 
s = splnet();
counters = counters_enter(, mbstat);
+   if (m == NULL) {
+   counters[MBSTAT_DROPS]++;
+   goto out;
+   }
counters[type]++;
+
+   m->m_type = type;
+
+out:
counters_leave(, mbstat);
splx(s);
 
-   m->m_type = type;
+   if (m == NULL)
+   return NULL;
 
return (m_inithdr(m));
 }
@@ -349,7 +360,10 @@ m_clget(struct mbuf *m, int how, u_int p
 {
struct mbuf *m0 = NULL;
struct pool *pp;
+   struct counters_ref cr;
+   uint64_t *counters;
caddr_t buf;
+   int s;
 
pp = m_clpool(pktlen);
 #ifdef DIAGNOSTIC
@@ -364,9 +378,16 @@ m_clget(struct mbuf *m, int how, u_int p
 
m = m0;
}
+
buf = pool_get(pp, how == M_WAIT ? PR_WAITOK : PR_NOWAIT);
+
if (buf == NULL) {
m_freem(m0);
+   s = splnet();
+   counters = counters_enter(, mbstat);
+   counters[MBSTAT_DROPS]++;
+   counters_leave(, mbstat);
+   splx(s);
return (NULL);
}
 

Re: handle non-standard 11n APs better

[Gregor Best]

On Tue, Dec 27, 2016 at 01:00:54AM +0100, Gregor Best wrote:
> On Mon, Dec 26, 2016 at 08:44:47PM +0100, Stefan Sperling wrote:
> > [...]
> > E.g. at 33C3 there are APs with: RxMCS 0xf8f8f800
> > 
> > The diff below makes OpenBSD clients work in 11n mode on such networks
> > by relaxing our "supported MCS" 11n feature check.
> > [...]
> 
> To go along with the 33c3 motto: "Works for me". Thanks a lot :)
> [...]

Looks like I spoke a bit too soon. The card associates and can receive
IPv6 router advertisements, but that seems to be it. I don't receive
replies to DHCP requests and statically configuring an address doesn't
yield a working connection either.

A PCAP file I captured with

tcpdump -y IEEE802_11 -ni iwm0 -w /tmp/nw.pcap

is at [0]. The output of ifconfig and a dmesg follows. The kernel is
one built from a CVS checkout from 0100 this morning.

Is this related to an AP with weird 11n handling at all?

-- 
Gregor

$ ifconfig iwm0
iwm0: flags=208843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST,AUTOCONF6> mtu 1500
lladdr e4:a4:71:e1:45:79
index 2 priority 4 llprio 3
groups: wlan
media: IEEE802.11 autoselect (OFDM18 mode 11a)
status: active
ieee80211: nwid 33C3-open chan 48 bssid 04:bd:88:62:96:91 65%
inet6 fe80::e6a4:71ff:fee1:4579%iwm0 prefixlen 64 scopeid 0x2
inet6 2001:67c:20a1:1192:e6a4:71ff:fee1:4579 prefixlen 64 autoconf 
pltime 0 vltime 3600
inet6 2001:67c:20a1:1192:8831:5f1e:f152:8cf3 prefixlen 64 deprecated 
autoconf autoconfprivacy pltime 0 vltime 3161
inet6 2001:67c:20a1:1192:2c51:2f3:5efe:5361 prefixlen 64 autoconf 
autoconfprivacy pltime 0 vltime 3464

$ dmesg

OpenBSD 6.0-current (GENERIC.MP) #54: Tue Dec 27 00:55:34 CET 2016
g...@sputnik.unobtanium.de:/usr/obj/sys/arch/amd64/compile/GENERIC.MP
real mem = 17078013952 (16286MB)
avail mem = 16554639360 (15787MB)
mpath0 at root
scsibus0 at mpath0: 256 targets
mainbus0 at root
bios0 at mainbus0: SMBIOS rev. 3.0 @ 0x87ed7000 (44 entries)
bios0: vendor American Megatrends Inc. version "5.11" date 08/29/2016
bios0: Notebook N24_25JU
acpi0 at bios0: rev 2
acpi0: sleep states S0 S3 S4 S5
acpi0: tables DSDT FACP APIC FPDT FIDT MCFG HPET SSDT SSDT DBGP DBG2 SSDT UEFI 
SSDT BGRT DMAR TPM2 ASF!
acpi0: wakeup devices PEGP(S4) PEG0(S4) PEGP(S4) PEG1(S4) PEGP(S4) PEG2(S4) 
PXSX(S4) RP17(S4) PXSX(S4) RP18(S4) PXSX(S4) RP19(S4) PXSX(S4) RP20(S4) 
PXSX(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) Core(TM) i5-6200U CPU @ 2.30GHz, 2694.51 MHz
cpu0: 
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,SDBG,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,LONG,LAHF,ABM,3DNOWP,PERF,ITSC,FSGSBASE,SGX,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,MPX,RDSEED,ADX,SMAP,CLFLUSHOPT,PT,SENSOR,ARAT
cpu0: 256KB 64b/line 8-way L2 cache
cpu0: smt 0, core 0, package 0
mtrr: Pentium Pro MTRR support, 10 var ranges, 88 fixed ranges
cpu0: apic clock running at 24MHz
cpu0: mwait min=64, max=64, C-substates=0.2.1.2.4.1.1.1, IBE
cpu1 at mainbus0: apid 2 (application processor)
cpu1: Intel(R) Core(TM) i5-6200U CPU @ 2.30GHz, 2693.75 MHz
cpu1: 
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,SDBG,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,LONG,LAHF,ABM,3DNOWP,PERF,ITSC,FSGSBASE,SGX,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,MPX,RDSEED,ADX,SMAP,CLFLUSHOPT,PT,SENSOR,ARAT
cpu1: 256KB 64b/line 8-way L2 cache
cpu1: smt 0, core 1, package 0
cpu2 at mainbus0: apid 1 (application processor)
cpu2: Intel(R) Core(TM) i5-6200U CPU @ 2.30GHz, 2693.75 MHz
cpu2: 
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,SDBG,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,LONG,LAHF,ABM,3DNOWP,PERF,ITSC,FSGSBASE,SGX,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,MPX,RDSEED,ADX,SMAP,CLFLUSHOPT,PT,SENSOR,ARAT
cpu2: 256KB 64b/line 8-way L2 cache
cpu2: smt 1, core 0, package 0
cpu3 at mainbus0: apid 3 (application processor)
cpu3: Intel(R) Core(TM) i5-6200U CPU @ 2.30GHz, 2693.75 MHz
cpu3: 
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,SDBG,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,LONG,LAHF,ABM,3DNOWP,PERF,ITSC,FSGSBASE,SGX,BMI1,A

Re: handle non-standard 11n APs better

[Gregor Best]

On Mon, Dec 26, 2016 at 08:44:47PM +0100, Stefan Sperling wrote:
> [...]
> E.g. at 33C3 there are APs with: RxMCS 0xf8f8f800
> 
> The diff below makes OpenBSD clients work in 11n mode on such networks
> by relaxing our "supported MCS" 11n feature check.
> [...]

To go along with the 33c3 motto: "Works for me". Thanks a lot :)

-- 
Gregor

Re: The end of nd6_output()

[Gregor Best]

Hi,

On Mon, Nov 07, 2016 at 03:55:29PM +0100, Gregor Best wrote:
> [...]
> I can't reproduce the problem anymore. If it does turn up again, I'll
> collect the output of route monitor. In the mean time, thanks a bunch
> for your help :)
> [...]

It happened again, this time in a slightly more convoluted scenario
with bgpd adding and removing routes. I grabbed the output of route
monitor from the time the tap0 interface was started, so it's quite big
:(

I've uploaded two versions, one with IPv4-addresses removed [0], one
with the addresses still in, in case I messed something up [1]. The
routing table looks like this (routes added by bgpd disappeared because
the session died after the broken route was added):

$ route -n show -inet6
Routing tables

Internet6:
DestinationGatewayFlags   Refs  
Use   Mtu  Prio Iface
defaultfe80::2a0:57ff:fe24:807d%trunk0 UG 1 
  46 -56 trunk0
::/96  ::1UGRS   0  
  0 32768 8 lo0
::/104 ::1UGRS   0  
  0 32768 8 lo0
::1::1UHhl  14  
568 32768 1 lo0
::127.0.0.0/104::1UGRS   0  
  0 32768 8 lo0
::224.0.0.0/100::1UGRS   0  
  0 32768 8 lo0
::255.0.0.0/104::1UGRS   0  
  0 32768 8 lo0
:::0.0.0.0/96  ::1UGRS   0  
  0 32768 8 lo0
2001:470:74bb::/64 2001:470:74bb::1   UCn0  
  0 - 4 tap0
2001:470:74bb::1   fe:e1:ba:d0:a8:dd  UHLl   0  
  0 - 1 tap0
2001:4dd0:af15:7478::/64   2001:4dd0:af15:7478:82fa:5bff:fe33:76b3 UCn  
  00 - 4 trunk0
2001:4dd0:af15:7478:82fa:5bff:fe33:76b3 80:fa:5b:33:76:b3  UHLl 
  00 - 1 trunk0
2001:4dd0:af15:7478:dc02:682d:13cf:94ec 80:fa:5b:33:76:b3  UHLl 
  0   33 - 1 trunk0
2002::/24  ::1UGRS   0  
  0 32768 8 lo0
2002:7f00::/24 ::1UGRS   0  
  0 32768 8 lo0
2002:e000::/20 ::1UGRS   0  
  0 32768 8 lo0
2002:ff00::/24 ::1UGRS   0  
  0 32768 8 lo0
fd97:1c82:9447::/64fd97:1c82:9447::1  UCn1  
  2 - 4 tap0
fd97:1c82:9447::   fd97:1c82:9447::   UHLc   0  
890 - 4 tap0
fd97:1c82:9447::1  fe:e1:ba:d0:a8:dd  UHLl   0  
 15 - 1 tap0
fe80::/10  ::1UGRS   0  
  2 32768 8 lo0
fec0::/10  ::1UGRS   0  
  0 32768 8 lo0
fe80::1%lo0fe80::1%lo0UHl0  
  0 32768 1 lo0
fe80::%tap0/64 fe80::fce1:baff:fed0:a8dd%tap0 UCn0  
  0 - 4 tap0
fe80::fce1:baff:fed0:a8dd%tap0 fe:e1:ba:d0:a8:dd  UHLl   0  
  0 - 1 tap0
fe80::%trunk0/64   fe80::82fa:5bff:fe33:76b3%trunk0 UCn
12 - 4 trunk0
fe80::2a0:57ff:fe24:807d%trunk000:a0:57:24:80:7d  UHLch  1  
328 - 4 trunk0
fe80::82fa:5bff:fe33:76b3%trunk0   80:fa:5b:33:76:b3  UHLl   0  
 51 - 1 trunk0
ff01::/16  ::1UGRS   2  
  4 32768 8 lo0
ff01::%lo0/32  ::1Um 0  
  1 32768 4 lo0
ff01::%tap0/32 fe80::fce1:baff:fed0:a8dd%tap0 Um 0  
  2 - 4 tap0
ff01::%trunk0/32   fe80::82fa:5bff:fe33:76b3%trunk0 Um 
02 - 4 trunk0
ff02::/16  ::1UGRS   2  
  4 32768 8 lo0
ff02::%lo0/32  ::1Um 0  
  1 32768 4 lo0
ff02::%tap0/32 fe80::fce1:baff:fed0:a8dd%tap0 Um 0  
  2 - 4 tap0
ff02::%trunk0/32   fe80::82fa:5bff:fe33:76b3%trunk0 Um 
13 - 4 trunk0

As before, if you need any more info or pcaps or anything, I'd be more
than happy to assist.

[0]: http://unobtanium.de/static/rtmsg-v6only.txt
[1]: http://unobtanium.de/static/rtmsg-complete.txt

-- 
Gregor



signature.asc
Description: PGP signature

Re: The end of nd6_output()

[Gregor Best]

Hi,

On Mon, Nov 07, 2016 at 09:12:12AM +0100, Martin Pieuchot wrote:
> [...]
> Could you capture the route changes via "# route monitor"?  I'd like
> to know if the 'bad gateway value' message is triggered by userland
> or the kernel.
> [...]

I can't reproduce the problem anymore. If it does turn up again, I'll
collect the output of route monitor. In the mean time, thanks a bunch
for your help :)

-- 
Gregor

Re: The end of nd6_output()

[Gregor Best]

Hi Martin,

On Fri, Nov 04, 2016 at 11:44:14AM +0100, Martin Pieuchot wrote:
> 
> That's the problem.  The entry is flagged as RTF_LLINFO but contains an
> IPv6 address.
> 
> Do you see any other errors in /log/messages?
> 

Only

nd6_rtrequest: bad gateway value: tap0

immediately before the printf gets triggered. I tried reproducing the
problem in a cleaner environment, since the one I'm seeing this in is a
bit convoluted.

tap0 is usually managed by tinc. Immediately after starting it,
everything looks fine:

$ route -n show -inet6 | grep tap0
2001:470:74bb::/64 2001:470:74bb::1   UCn 0
0 - 4 tap0
2001:470:74bb::1   fe:e1:ba:d4:0f:e3  UHLl 0
0 - 1 tap0
fd97:1c82:9447::/64fd97:1c82:9447::1  UCn 0
0 - 4 tap0
fd97:1c82:9447::1  fe:e1:ba:d4:0f:e3  UHLl 0
0 - 1 tap0
fe80::%tap0/64 fe80::fce1:baff:fed4:fe3%tap0  UCn 0
0 - 4 tap0
fe80::fce1:baff:fed4:fe3%tap0  fe:e1:ba:d4:0f:e3  UHLl 0
0 - 1 tap0
ff01::%tap0/32 fe80::fce1:baff:fed4:fe3%tap0  Um 02 
- 4 tap0
ff02::%tap0/32 fe80::fce1:baff:fed4:fe3%tap0  Um 02 
- 4 tap0

$ ifconfig tap0
tap0: flags=8843 mtu 1500
lladdr fe:e1:ba:d4:0f:e3
index 14 priority 15 llprio 3
groups: tap tinc unobtanium
status: active
inet 172.22.127.2 netmask 0xff00 broadcast 172.22.127.255
inet6 fe80::fce1:baff:fed4:fe3%tap0 prefixlen 64 scopeid 0xe
inet6 2001:470:74bb::1 prefixlen 64 deprecated pltime 0 vltime infty
inet6 fd97:1c82:9447::1 prefixlen 64 deprecated pltime 0 vltime infty

Pinging across the tunnel (the other side has fd97:1c82:9447:: as one of
its addresses on the tunnel) doesn't work:

$ ping6 -n -c1 fd97:1c82:9447::
PING fd97:1c82:9447:: (fd97:1c82:9447::): 56 data bytes

--- fd97:1c82:9447:: ping statistics ---
1 packets transmitted, 0 packets received, 100.0% packet loss

and causes the 'bad gateway value' message to appear, followed by a few
'something odd happens'. Now the routing table looks like this:

$ route -n show -inet6 | grep tap0
2001:470:74bb::/64 2001:470:74bb::1   UCn0  
  0 - 4 tap0
2001:470:74bb::1   fe:e1:ba:d4:0f:e3  UHLl   0  
  0 - 1 tap0
fd97:1c82:9447::/64fd97:1c82:9447::1  UCn1  
  0 - 4 tap0
fd97:1c82:9447::   fe:e1:ba:d0:26:57  UHLc   1  
  2 - 4 tap0
   ^
fd97:1c82:9447::1  fe:e1:ba:d4:0f:e3  UHLl   0  
  0 - 1 tap0
fe80::%tap0/64 fe80::fce1:baff:fed4:fe3%tap0  UCn1  
  3 - 4 tap0
fe80::fce1:baff:fed0:2657%tap0 fe:e1:ba:d0:26:57  UHLc   0  
 10 - 4 tap0
fe80::fce1:baff:fed4:fe3%tap0  fe:e1:ba:d4:0f:e3  UHLl   0  
  3 - 1 tap0
ff01::%tap0/32 fe80::fce1:baff:fed4:fe3%tap0  Um 0  
  2 - 4 tap0
ff02::%tap0/32 fe80::fce1:baff:fed4:fe3%tap0  Um 0  
  3 - 4 tap0

This is what shows up on tap0 when I do the ping6:

$ doas tcpdump -ni tap0 ip6
tcpdump: listening on tap0, link-type EN10MB
19:23:45.315411 fe80::fce1:baff:fed9:9d3f > ff02::1:ff00:0: icmp6: neighbor 
sol: who has fd97:1c82:9447::
19:23:45.373281 fe80::fce1:baff:fed0:2657 > fe80::fce1:baff:fed9:9d3f: icmp6: 
neighbor adv: tgt is fd97:1c82:9447::
19:23:45.373477 fd00::82fa:5bff:fe33:76b3 > fd97:1c82:9447::: icmp6: echo 
request

I can't reproduce the problem when I configure a tap device similar to
how tinc does it and use `cat /dev/tap0 >/dev/null` to keep the device
open, which leads me to assume that the neighbour advertisement received
from fe80::fce1:baff:fed9:9d3f leads to this weird new route.

If I can do anything else to be of assistance, please let me know.

-- 
Gregor

Re: The end of nd6_output()

[Gregor Best]

Hi,

On Mon, Jun 06, 2016 at 07:16:20PM +0200, Martin Pieuchot wrote:
> [...]
> + if (rt->rt_gateway->sa_family != AF_LINK) {
> + printf("%s: something odd happens\n", __func__);
> + m_freem(m);
> + return (EINVAL);
> + }
> [...]

I noticed that since a week or two ago, this printfs gets triggered on
my laptops and relatively quickly floods my dmesg. One is running a
snapshot from two weeks ago, the other one runs a snapshot from about a
month ago. On both, I have IPv6 routes that look like this:

Routing tables

Internet6:
DestinationGatewayFlags   Refs  
Use   Mtu  Prio Iface
defaultfe80::203:2dff:fe20:cf85%trunk0 UG 0 
  22 -56 trunk0
::/96  ::1UGRS   0  
  0 32768 8 lo0  
::/104 ::1UGRS   0  
  0 32768 8 lo0  
::1::1UHhl  14  
   9118 32768 1 lo0  
::127.0.0.0/104::1UGRS   0  
  0 32768 8 lo0  
::224.0.0.0/100::1UGRS   0  
  0 32768 8 lo0  
::255.0.0.0/104::1UGRS   0  
  0 32768 8 lo0  
:::0.0.0.0/96  ::1UGRS   0  
  0 32768 8 lo0  
2001:470:7193:10::/64  2001:470:7193:10:82fa:5bff:fe33:76b3 UCn 
   2   19 - 4 trunk0
2001:470:7193:10::100:03:2d:20:cf:85  UHLc   0  
   7682 - 4 trunk0
2001:470:7193:10:187d:de60:2580:663b link#7 UHLc   
0   19 - 4 trunk0
2001:470:7193:10:82fa:5bff:fe33:76b3 80:fa:5b:33:76:b3  UHLl   
0  819 - 1 trunk0
2001:470:7193:10:f093:17b2:7503:d4cf 80:fa:5b:33:76:b3  UHLl   
0  133 - 1 trunk0
2001:470:74bb::/64 2001:470:74bb::1   UCn0  
  0 - 4 tap0 
2001:470:74bb::1   fe:e1:ba:d0:35:0a  UHLl   0  
  0 - 1 tap0 
2002::/24  ::1UGRS   0  
  0 32768 8 lo0  
2002:7f00::/24 ::1UGRS   0  
  0 32768 8 lo0  
2002:e000::/20 ::1UGRS   0  
  0 32768 8 lo0  
2002:ff00::/24 ::1UGRS   0  
  0 32768 8 lo0  
fd97:1c82:9447::/64fd97:1c82:9447::1  UCn1  
  0 - 4 tap0 
fd97:1c82:9447::   fd97:1c82:9447::   UHLc   0  
   7408 - 4 tap0 
fd97:1c82:9447::1  fe:e1:ba:d0:35:0a  UHLl   0  
  4 - 1 tap0 
fe80::/10  ::1UGRS   0  
  2 32768 8 lo0  
fec0::/10  ::1UGRS   0  
  0 32768 8 lo0  
fe80::1%lo0fe80::1%lo0UHl0  
  0 32768 1 lo0  
fe80::%tap0/64 fe80::fce1:baff:fed0:350a%tap0 UCn0  
  0 - 4 tap0 
fe80::fce1:baff:fed0:350a%tap0 fe:e1:ba:d0:35:0a  UHLl   0  
  0 - 1 tap0 
fe80::%trunk0/64   fe80::82fa:5bff:fe33:76b3%trunk0 UCn
13 - 4 trunk0
fe80::203:2dff:fe20:cf85%trunk000:03:2d:20:cf:85  UHLch  1  
 436623 - 4 trunk0
fe80::82fa:5bff:fe33:76b3%trunk0   80:fa:5b:33:76:b3  UHLl   0  
 130445 - 1 trunk0
ff01::/16  ::1UGRS   2  
  4 32768 8 lo0  
ff01::%lo0/32  ::1Um 0  
  1 32768 4 lo0  
ff01::%tap0/32 fe80::fce1:baff:fed0:350a%tap0 Um 0  
  2 - 4 tap0 
ff01::%trunk0/32   fe80::82fa:5bff:fe33:76b3%trunk0 Um 
08 - 4 trunk0
ff02::/16  ::1UGRS   2  
  4 32768 8 lo0  
ff02::%lo0/32  ::1Um 0  
  1 32768 4 lo0  
ff02::%tap0/32 fe80::fce1:baff:fed0:350a%tap0 Um 0  
  2 - 4 tap0 
ff02::%trunk0/32   fe80::82fa:5bff:fe33:76b3%trunk0 Um 
19 - 4 trunk0

tap0 is managed and configured by a tinc daemon. I do have a BGP daemon
running on both laptops that adds routes that go over tap0, but at the
moment the only active sessions are IPv4.

How can I go about finding out 

Re: Quirks for pkcbc?

[Gregor Best]

On Sun, Oct 23, 2016 at 03:42:59PM -0600, Theo de Raadt wrote:
> [...]
> I ask you to figure out logical conditions under which this should
> happen, or if some interaction is wrong.
> [...]

Understood. I'll try tracking down the exact circumstances of the issue
and come back with a better diff.

-- 
Gregor


signature.asc
Description: PGP signature

Quirks for pkcbc?

[Gregor Best]

Hi people,

the patch below the signature makes the touchpad on my new laptop work.
pms(4) didnt' attach previously because the AUX slot on the keyboard was
not enabled.

Since the patch isn't a proper solution, I was wondering whether there's
a quirks mechanism for pckbc, similar to what e.g. some of the USB HID
drivers do for things like joysticks with weird button mappings.

-- 
Gregor

Index: dev/ic/pckbc.c
===
RCS file: /mnt/media/cvs/src/sys/dev/ic/pckbc.c,v
retrieving revision 1.49
diff -u -p -r1.49 pckbc.c
--- dev/ic/pckbc.c  24 May 2015 10:57:47 -  1.49
+++ dev/ic/pckbc.c  23 Oct 2016 21:19:56 -
@@ -378,6 +378,8 @@ pckbc_attach(struct pckbc_softc *sc, int
bus_space_write_1(iot, ioh_d, 0, 0x5a); /* a random value */
res = pckbc_poll_data1(iot, ioh_d, ioh_c, PCKBC_AUX_SLOT, 1);

+   t->t_flags |= PCKBC_NEED_AUXWRITE;
+
if (ISSET(t->t_flags, PCKBC_NEED_AUXWRITE)) {
/*
 * The following code is necessary to find the aux port on the

Re: video(1): Don't limit maximum frame size to display size

[Gregor Best]

Hi,

> [...]
> This seems to work fine with inteldrm, a 1280x800 display and
> [...]

Good to hear I didn't break anything :)

> [...]
> No idea either... if you wanted to reduce the risk of breakage, I
> guess you could limit the resolution only if -O is not passed.
> [...]

I've read up on Xv a bit and I think it's okay to just give it larger
images, so this kind of precaution doesn't seem necessary.

-- 
Gregor

video(1): Don't limit maximum frame size to display size

[Gregor Best]

Hi,

this is another patch to video(1). It removes the logic that forces the
video grab frame size to be <= the size of the Xv adaptor. This allows
me to grab and view frames that are 1280x1024 on my 1440x900 screen. Xv
properly scales and stretches the window content, so there's nothing
that gets cut off from the video feed.

The camera I have here has the following resolutions:

160x120: 30
176x144: 30
320x240: 30
352x288: 30
640x480: 30
1280x1024: 9

Without this patch, the maximum resolution I can grab and view at the
same time is 640x480, which is a bit too tiny. I haven't noticed any
downsides of the patch, but I've only tested it with my laptop and not
other graphics cards, so I'm not sure how Xv handles frames larger than
the display size there.

-- 
Gregor

Index: video.c
===
RCS file: /mnt/media/cvs/xenocara/app/video/video.c,v
retrieving revision 1.19
diff -u -p -r1.19 video.c
--- video.c 6 Jun 2016 19:31:22 -   1.19
+++ video.c 18 Sep 2016 14:00:06 -
@@ -1162,13 +1162,6 @@ choose_size(struct video *vid)
else if (vid->width && !vid->height)
vid->height = vid->width * 3 / 4;
 
-   if (vid->mode & M_OUT_XV) {
-   if (vid->width > x->max_width)
-   vid->width = x->max_width;
-   if (vid->height > x->max_height)
-   vid->height = x->max_height;
-   }
-
if (vid->mode & M_IN_DEV) {
i = 0;
while (i < d->nsizes &&

Re: video(1): Use read(2) to read file specified with -i

[Gregor Best]

On Thu, Sep 15, 2016 at 02:57:16PM +0200, Jeremie Courreges-Anglas wrote:
> [...]
> I think this is the right way to work around the problem and make
> video(1) more user-friendly.  However, I doubt that the manpage bits are
> relevant.  So I'd like to commit only the .c diff.
> 
> Thoughts?
> [...]

Fine with me. On second thought, adding the manpage bits was overkill.

-- 
Gregor

video(1): Use read(2) to read file specified with -i

[Gregor Best]

Hi,

video(1) fails to read files that were previously recorded with -o
somefile, unless -g (to select read(2) as the input method) is also
specified:

   $ video -o foo
   ^C
   $ video -i foo
   video: ioctl VIDIOC_REQBUFS: Bad file descriptor
   $ video -g -i foo
   [ plays the file ]

mmap-mode doesn't work here because it uses a few v4l2-specific ioctls
to talk to the video device.

The patch below fixes that by always using read(2) when the -i option is
used.

-- 
Gregor

Index: video.1
===
RCS file: /mnt/media/cvs/xenocara/app/video/video.1,v
retrieving revision 1.13
diff -u -p -r1.13 video.1
--- video.1 4 Jun 2016 07:44:32 -   1.13
+++ video.1 14 Sep 2016 19:47:52 -
@@ -113,6 +113,10 @@ If
 is
 .Ql - ,
 frames will be read from standard input.
+This will use
+.Xr read 2
+to grab frames instead of
+.Xr mmap 2 .
 .It Fl O Ar output
 File to which frames will be written.
 If
Index: video.c
===
RCS file: /mnt/media/cvs/xenocara/app/video/video.c,v
retrieving revision 1.19
diff -u -p -r1.19 video.c
--- video.c 6 Jun 2016 19:31:22 -   1.19
+++ video.c 14 Sep 2016 19:46:39 -
@@ -1805,6 +1805,7 @@ main(int argc, char *argv[])
err++;
} else {
vid.mode = (vid.mode & ~M_IN_DEV) | M_IN_FILE;
+   vid.mmap_on = 0; /* mmap mode does not work for 
files */
snprintf(vid.iofile, sizeof(vid.iofile),
optarg);
}

Re: Futexes for OpenBSD

[Gregor Best]

On Fri, Sep 02, 2016 at 03:36:50PM +0200, Michal Mazurek wrote:
> Here is a working futex implementation for OpenBSD. This diff touches
> the kernel and librthread.
> 
> * get rid of tickets from rthreads, they were getting in the way and are
> unused anyway
> * replace all struct _spinlock with int
> * use futexes instead of spinlocks everywhere within librthread
> * librthread no longer calls sched_yield(), nor does it spin
> 
> Any comments?
> [...]

There's a tiny bit missing from the patch:

Index: libc/Symbols.list
===
RCS file: /mnt/media/cvs/src/lib/libc/Symbols.list,v
retrieving revision 1.49
diff -u -p -r1.49 Symbols.list
--- libc/Symbols.list   1 Sep 2016 10:41:02 -   1.49
+++ libc/Symbols.list   3 Sep 2016 09:54:58 -
@@ -272,6 +272,7 @@ fstatat
 fstatfs
 fsync
 ftruncate
+futex
 futimens
 futimes
 getdents
Index: libc/sys/Makefile.inc
===
RCS file: /mnt/media/cvs/src/lib/libc/sys/Makefile.inc,v
retrieving revision 1.146
diff -u -p -r1.146 Makefile.inc
--- libc/sys/Makefile.inc   4 Jul 2016 18:01:44 -   1.146
+++ libc/sys/Makefile.inc   3 Sep 2016 09:53:03 -
@@ -87,6 +87,7 @@ DASM= ${ASM:.o=.do}
 # syscalls that CANNOT FAIL.  They can return whatever value they want,
 # they just never want to set errno.
 ASM_NOERR=__get_tcb.o __set_tcb.o __threxit.o __thrsleep.o __thrwakeup.o \
+   futex.o \
getdtablecount.o getegid.o geteuid.o getgid.o getlogin_r.o \
getpgrp.o getpid.o getppid.o getrtable.o getthrid.o getuid.o \
issetugid.o \

Otherwise, the  calls to  futex() in librthread  can't be  resolved. I'm
currently building Firefox to see how it works out.

-- 
Gregor
--

Honesty is the best policy, but insanity is a better defense.

Re: multi-pool malloc wip diff

[Gregor Best]

On Mon, Aug 22, 2016 at 05:03:34PM +0200, Otto Moerbeek wrote:
> On Mon, Aug 22, 2016 at 05:00:12PM +0200, Otto Moerbeek wrote:
> 
> > Hmm, indeed, looking into it.
> 
> Fixed diff now online,
> [...]

With that one, Firefox and Chromium work fine. There's a problem with
Gimp though:

$ gimp
gimp(51103) in free(): error: bogus pointer (double free?) 0x127da3e84400
gimp(51103) in malloc(): error: recursive call
GLib (gthread-posix.c): Unexpected error from C library during 'malloc':
Resource deadlock avoided.  Aborting.

This doesn't happen when starting Gimp for the first time, so the
process to reproduce it (on my machine at least) is:

- install gimp
- move ~/.gimp-2.8 out of the way if it exists to make sure it's a clean
  start
- launch gimp
- (gimp works fine now)
- close gimp, start it again
- the above error message appears during startup while starting the
  extension "extension-script-fu" and gimp doesn't continue starting

How can I debug this further? At first glance, I don't really see a way
for malloc to be called recursively :/

-- 
Gregor

Re: multi-pool malloc wip diff

[Gregor Best]

Hi,

On Mon, Aug 22, 2016 at 08:21:08AM +0200, Otto Moerbeek wrote:
> [...]
> New diff posted in http://www.drijf.net/openbsd/malloc.
> 
> The intention is that this is close to commitable. But while a
> straight merge of most recent diff with the current src, a bug
> might have crept in. So beware etc.
> [...]

After applying this to a clean /usr/src/lib/libc, I get

cc -O2 -pipe -g -Wall -g -Werror -Wshadow -Werror-implicit-function-declaration 
-Wsign-compare -I/usr/src/lib/librthread -include namespace.h  
-I/usr/src/lib/librthread/../libc/arch/amd64 
-I/usr/src/lib/librthread/../libc/include   -c rthread.c -o rthread.o
cc1: warnings being treated as errors
rthread.c: In function '_rthread_init':
rthread.c:212: warning: assignment from incompatible pointer type
rthread.c:213: warning: assignment from incompatible pointer type

when building librthread. libc builds fine but stuff like firefox and
chrome die with

chrome(97224) in unknown error: free() called before allocation
Abort trap (core dumped)

and stack traces that look like this:

(gdb) bt
#0  0x0c27475c9aaa in thrkill () at :2
#1  0x0c27475e6589 in *_libc_abort () at /usr/src/lib/libc/stdlib/abort.c:52
#2  0x0c27475b8239 in wrterror (d=0x0, msg=0xc274773b2d8 "free() called 
before allocation", p=0x0)
at /usr/src/lib/libc/stdlib/malloc.c:307
#3  0x0c27475b9746 in free (ptr=Variable "ptr" is not available.) at 
/usr/src/lib/libc/stdlib/malloc.c:1390
#4  0x0c2760446c70 in pthread_attr_destroy (attrp=0x7f7c3850) at 
/usr/src/lib/librthread/rthread_attr.c:64
[... other stuff omitted from here on ...]

Is the diff (I chose malloc-20160822.dif) missing a librthread change?

-- 
Gregor
--

For those who like this sort of thing, this is the sort of thing they like.
-- Abraham Lincoln

Re: Patch for man to ignore trailing spaces in man.conf

[Gregor Best]

Hi Mayukh,

On Sun, May 22, 2016 at 11:17:18PM -0700, Mayukh Bose wrote:
> [...]
> Here's my patch to fix this:
> [...]

Ironically, your patch about whitespace handling has mangled whitespace.
Can you send it again? Maybe your MUA tried sending it as some sort of
formatted text instead of plain text.

-- 
Gregor

Re: Document inet4/prefix in hostname.if(5)

[Gregor Best]

On Mon, May 02, 2016 at 01:25:22PM +0100, Jason McIntyre wrote:
> On Mon, May 02, 2016 at 01:27:50PM +0200, Henning Brauer wrote:
> > [...]
> > technically, hostname.if  doesn't support  ip/len notation. It  is a
> > notation that the hostname parser doesn't grok and just passes on to
> > ifconfig. That is the modus  operandi for almost everything actually
> > - except  the classic  "inet [addr]  [mask] [bcast]"  notation. This
> > "dual" approach, parsing by netstart vs just passing on to ifconfig,
> > is the source of this slightly confusing behaviour.
> > 
> 
> yep. and someone went  to the trouble of trying to  make that all nice
> and clear, at the top of  hostname.if(5). so i don;t see that anything
> needs to be done, doc-fix-wise.
> [...]

Fair enough, I retract my patch then :)

-- 
Gregor

Document inet4/prefix in hostname.if(5)

[Gregor Best]

Hi,

/etc/hostname.if supports IPv4 addresses with a CIDR prefix length:

inet 10.0.0.1/16

which is not documented in hostname.if(5). The attached patch fixes
that. I'm not sure whether describing '/prefixlen' before 'netmask' is a
good idea, but it matches the order things have to be specified in and
'netmask' is the next paragraph after '/prefixlen'

-- 
Gregor

Index: hostname.if.5
===
RCS file: /mnt/media/cvs/src/share/man/man5/hostname.if.5,v
retrieving revision 1.64
diff -u -p -r1.64 hostname.if.5
--- hostname.if.5   6 Jun 2015 13:13:07 -   1.64
+++ hostname.if.5   1 May 2016 17:17:22 -
@@ -82,7 +82,9 @@ Regular IPv4 network setup:
 .Bd -ragged -offset indent
 .Li inet
 .Op Li alias
-.Va addr
+.Sm
+.Va addr Op / Va prefixlen
+.Sm
 .Va netmask
 .Va broadcast_addr
 .Va options
@@ -117,6 +119,7 @@ inet alias 10.0.1.13 255.255.255.255 10.
 inet alias 10.0.1.14 255.255.255.255 NONE
 inet alias 10.0.1.15 255.255.255.255
 inet alias 10.0.1.16 0x
+inet alias 10.0.1.17/29
 # This is an example comment line.
 inet6 alias fec0::1 64
 inet6 alias fec0::2 64 anycast
@@ -152,6 +155,12 @@ If no address is specified, the
 and
 .Va dest_addr
 options are invalid and will be ignored.
+.Sm
+.It / Va prefixlen
+.Sm
+The optional CIDR prefix length for the interface, e.g.,
+/29.
+If both a netmask and a prefix length are specified, the netmask is used.
 .It Va netmask
 The optional network mask for the interface, e.g.,
 255.255.255.0.

Re: Make uftdi(4) support aftermarket FTDI devices

[Gregor Best]

On Sun, Feb 21, 2016 at 10:56:43PM +0200, li...@wrant.com wrote:
> [...]
> Others followed suit too, HL_340 bricked  clones here. Not sure how to
> resolve the 0x mapping uniformly.  Have to invent a separate twerp
> category.
> [...]

USB  product IDs  only  need to  be  unique under  the  vendor ID.  It's
perfectly fine for vendor 0x and  vendor 0x to have devices with
ID 0x1234.

> [...]
> I can't even  remember what they were using originally  when they used
> to work,  electrically the  device is fine.  Just got  reprogrammed to
> comply with the FTDI clones in the 0x device ID.
> [...]

That's why simply adding the product ID is enough. Once they do that to
more than one device with different drivers, things are going to become
interesting, but I don't think that's going to happen after the initial
backlash.

-- 
Gregor

Re: Make uftdi(4) support aftermarket FTDI devices

[Gregor Best]

On Sun, Feb 21, 2016 at 12:41:06PM -0700, Theo de Raadt wrote:
> It makes no sense to renumber the FT232_1 entry.  That is just creating
> churn.
> 
> As to the 0x entry, I'm wondering whether it should be named something
> like the following, as a historical reminder:
> 
> +product FTDI FT232_JERKS   0xSerial
> [...]

Nice  idea. I've  added  the  "bricked" device  as  FT232_JERKS, with  a
slightly longer description that hints at the reasoning behind the name:


Index: dev/usb/uftdi.c
===
RCS file: /mnt/media/cvs/src/sys/dev/usb/uftdi.c,v
retrieving revision 1.74
diff -u -p -r1.74 uftdi.c
--- dev/usb/uftdi.c 18 Jun 2015 09:47:16 -  1.74
+++ dev/usb/uftdi.c 21 Feb 2016 22:10:28 -
@@ -236,6 +236,7 @@ static const struct usb_devno uftdi_devs
{ USB_VENDOR_FTDI, USB_PRODUCT_FTDI_FT232_4 },
{ USB_VENDOR_FTDI, USB_PRODUCT_FTDI_FT232_5 },
{ USB_VENDOR_FTDI, USB_PRODUCT_FTDI_FT232_6 },
+   { USB_VENDOR_FTDI, USB_PRODUCT_FTDI_FT232_JERKS },
{ USB_VENDOR_FTDI, USB_PRODUCT_FTDI_FT4232H },
{ USB_VENDOR_FTDI, USB_PRODUCT_FTDI_FTX },
{ USB_VENDOR_FTDI, USB_PRODUCT_FTDI_GAMMASCOUT },
Index: dev/usb/usbdevs
===
RCS file: /mnt/media/cvs/src/sys/dev/usb/usbdevs,v
retrieving revision 1.662
diff -u -p -r1.662 usbdevs
--- dev/usb/usbdevs 8 Jan 2016 09:31:32 -   1.662
+++ dev/usb/usbdevs 21 Feb 2016 22:12:57 -
@@ -1761,6 +1761,7 @@ product FOXCONN PIRELLI_DP_L100xe003  Pi
 product FREECOM DVD0xfc01  Connector for DVD drive
 
 /* Future Technology Devices products */
+product FTDI FT232_JERKS   0x  Serial (\"bricked\" by Windows driver)
 product FTDI FT232_1   0x0232  Serial
 product FTDI SERIAL_8U232AM0x6001  8U232AM Serial
 product FTDI SERIAL_8U232AM4   0x6004  8U232AM Serial
Index: dev/usb/usbdevs.h
===
RCS file: /mnt/media/cvs/src/sys/dev/usb/usbdevs.h,v
retrieving revision 1.674
diff -u -p -r1.674 usbdevs.h
--- dev/usb/usbdevs.h   8 Jan 2016 09:31:57 -   1.674
+++ dev/usb/usbdevs.h   21 Feb 2016 22:13:04 -
@@ -1,4 +1,4 @@
-/* $OpenBSD: usbdevs.h,v 1.674 2016/01/08 09:31:57 mpi Exp $   */
+/* $OpenBSD$   */
 
 /*
  * THIS FILE IS AUTOMATICALLY GENERATED.  DO NOT EDIT.
@@ -1768,6 +1768,7 @@
 #defineUSB_PRODUCT_FREECOM_DVD 0xfc01  /* Connector for DVD 
drive */
 
 /* Future Technology Devices products */
+#defineUSB_PRODUCT_FTDI_FT232_JERKS0x  /* Serial 
(\"bricked\" by Windows driver) */
 #defineUSB_PRODUCT_FTDI_FT232_10x0232  /* Serial */
 #defineUSB_PRODUCT_FTDI_SERIAL_8U232AM 0x6001  /* 8U232AM 
Serial */
 #defineUSB_PRODUCT_FTDI_SERIAL_8U232AM40x6004  /* 
8U232AM Serial */
Index: dev/usb/usbdevs_data.h
===
RCS file: /mnt/media/cvs/src/sys/dev/usb/usbdevs_data.h,v
retrieving revision 1.668
diff -u -p -r1.668 usbdevs_data.h
--- dev/usb/usbdevs_data.h  8 Jan 2016 09:31:57 -   1.668
+++ dev/usb/usbdevs_data.h  21 Feb 2016 22:13:04 -
@@ -1,4 +1,4 @@
-/* $OpenBSD: usbdevs_data.h,v 1.668 2016/01/08 09:31:57 mpi Exp $  */
+/* $OpenBSD$   */
 
 /*
  * THIS FILE IS AUTOMATICALLY GENERATED.  DO NOT EDIT.
@@ -3168,6 +3168,10 @@ const struct usb_known_product usb_known
{
USB_VENDOR_FREECOM, USB_PRODUCT_FREECOM_DVD,
"Connector for DVD drive",
+   },
+   {
+   USB_VENDOR_FTDI, USB_PRODUCT_FTDI_FT232_JERKS,
+   "Serial (\"bricked\" by Windows driver)",
},
{
USB_VENDOR_FTDI, USB_PRODUCT_FTDI_FT232_1,

Make uftdi(4) support aftermarket FTDI devices

[Gregor Best]

Hi people,

some time back, FTDI released a driver for their USB RS232 adaptors that
changed the USB device ID of aftermarket devices to 0x, so that they
wouldn't work  on any machine,  even with  the older FTDI  drivers, from
then on ([0] has further info on that).

The fix for that  is relatively simple: Add USB device  ID 0x to our
uftdi(4).  The patch  below the  signature  does just  that. I've  added
0x as  USB_PRODUCT_FTDI_FT232_1 and  moved the previous  _FT232_1 to
the vacant _FT232_2 slot to preserve the device ID ordering.

[0]: http://hackaday.com/2014/10/22/w/

-- 
Gregor
--

Index: dev/usb/uftdi.c
===
RCS file: /mnt/media/cvs/src/sys/dev/usb/uftdi.c,v
retrieving revision 1.74
diff -u -p -r1.74 uftdi.c
--- dev/usb/uftdi.c 18 Jun 2015 09:47:16 -  1.74
+++ dev/usb/uftdi.c 21 Feb 2016 16:33:51 -
@@ -232,6 +232,7 @@ static const struct usb_devno uftdi_devs
{ USB_VENDOR_FTDI, USB_PRODUCT_FTDI_FISCO },
{ USB_VENDOR_FTDI, USB_PRODUCT_FTDI_FT232RL },
{ USB_VENDOR_FTDI, USB_PRODUCT_FTDI_FT232_1 },
+   { USB_VENDOR_FTDI, USB_PRODUCT_FTDI_FT232_2 },
{ USB_VENDOR_FTDI, USB_PRODUCT_FTDI_FT232_3 },
{ USB_VENDOR_FTDI, USB_PRODUCT_FTDI_FT232_4 },
{ USB_VENDOR_FTDI, USB_PRODUCT_FTDI_FT232_5 },
Index: dev/usb/usbdevs
===
RCS file: /mnt/media/cvs/src/sys/dev/usb/usbdevs,v
retrieving revision 1.662
diff -u -p -r1.662 usbdevs
--- dev/usb/usbdevs 8 Jan 2016 09:31:32 -   1.662
+++ dev/usb/usbdevs 21 Feb 2016 16:19:45 -
@@ -1761,7 +1761,8 @@ product FOXCONN PIRELLI_DP_L100xe003  Pi
 product FREECOM DVD0xfc01  Connector for DVD drive
 
 /* Future Technology Devices products */
-product FTDI FT232_1   0x0232  Serial
+product FTDI FT232_1   0x  Serial
+product FTDI FT232_2   0x0232  Serial
 product FTDI SERIAL_8U232AM0x6001  8U232AM Serial
 product FTDI SERIAL_8U232AM4   0x6004  8U232AM Serial
 product FTDI FT232_3   0x6006  Serial
Index: dev/usb/usbdevs.h
===
RCS file: /mnt/media/cvs/src/sys/dev/usb/usbdevs.h,v
retrieving revision 1.674
diff -u -p -r1.674 usbdevs.h
--- dev/usb/usbdevs.h   8 Jan 2016 09:31:57 -   1.674
+++ dev/usb/usbdevs.h   21 Feb 2016 16:19:59 -
@@ -1,4 +1,4 @@
-/* $OpenBSD: usbdevs.h,v 1.674 2016/01/08 09:31:57 mpi Exp $   */
+/* $OpenBSD$   */
 
 /*
  * THIS FILE IS AUTOMATICALLY GENERATED.  DO NOT EDIT.
@@ -1768,7 +1768,8 @@
 #defineUSB_PRODUCT_FREECOM_DVD 0xfc01  /* Connector for DVD 
drive */
 
 /* Future Technology Devices products */
-#defineUSB_PRODUCT_FTDI_FT232_10x0232  /* Serial */
+#defineUSB_PRODUCT_FTDI_FT232_10x  /* Serial */
+#defineUSB_PRODUCT_FTDI_FT232_20x0232  /* Serial */
 #defineUSB_PRODUCT_FTDI_SERIAL_8U232AM 0x6001  /* 8U232AM 
Serial */
 #defineUSB_PRODUCT_FTDI_SERIAL_8U232AM40x6004  /* 
8U232AM Serial */
 #defineUSB_PRODUCT_FTDI_FT232_30x6006  /* Serial */
Index: dev/usb/usbdevs_data.h
===
RCS file: /mnt/media/cvs/src/sys/dev/usb/usbdevs_data.h,v
retrieving revision 1.668
diff -u -p -r1.668 usbdevs_data.h
--- dev/usb/usbdevs_data.h  8 Jan 2016 09:31:57 -   1.668
+++ dev/usb/usbdevs_data.h  21 Feb 2016 16:19:59 -
@@ -1,4 +1,4 @@
-/* $OpenBSD: usbdevs_data.h,v 1.668 2016/01/08 09:31:57 mpi Exp $  */
+/* $OpenBSD$   */
 
 /*
  * THIS FILE IS AUTOMATICALLY GENERATED.  DO NOT EDIT.
@@ -3171,6 +3171,10 @@ const struct usb_known_product usb_known
},
{
USB_VENDOR_FTDI, USB_PRODUCT_FTDI_FT232_1,
+   "Serial",
+   },
+   {
+   USB_VENDOR_FTDI, USB_PRODUCT_FTDI_FT232_2,
"Serial",
},
{

Re: Make em(4) more mpsafe again

[Gregor Best]

Hi David and tech@,

I just tried the patch on a December 28 snapshot and got a watchdog
timeout while running iperf. Just the snapshot without the patch
survives iperf without a timeout.

The device in question is this one:

em0 at pci1 dev 0 function 0 "Intel 82583V" rev 0x00: msi, address 
00:03:2d:20:cf:84

This is on i386.

Do you need a full dmesg with/without the patch? Is there anything else
I can do to aid in debugging? I'd also be more than happy to provide a
shell on the router and stand by with a console cable to aid in
debugging.

-- 
Gregor

Re: Make em(4) more mpsafe again

[Gregor Best]

On Fri, Jan 01, 2016 at 12:08:53AM +1000, David Gwynne wrote:
> [...]
> tests? ok?
> [...]

I'll test it tonight in my hackerspace. There's never a better time for
testing network patches than new years eve, since people will be drunk
enough to ignore occasional glitches when I restart the router :)

-- 
Gregor

Re: initial 11n support for iwn (n, not m)

[Gregor Best]

Hi Stefan,

On Sun, Dec 20, 2015 at 07:59:19PM +0100, Stefan Sperling wrote:
> On Sat, Dec 19, 2015 at 01:08:26PM +0100, Stefan Sperling wrote:
> > On Fri, Dec 18, 2015 at 05:40:39PM -0500, David Hill wrote:
> > > With sthen@'s patch I can associate, dhcp, and use net.
> > 
> > Here's an updated iwn diff with a better approach for Stuart's fix.
> > 
> > Thanks for helping, Stuart, and to everyone who sent beacons which
> > allowed us to narrow this problem down to protection settings being
> > set up the wrong way in iwn_run().
> 
> And another update (hopefully) fixing some reported issues, with some
> uncommitted net80211 changes included.
> 
> I haven't put these diffs in yet because I'm still hearing about regressions
> in some form or another. Sometimes it's unclear what people are running,
> so I hope this version will linger for a bit and get tested.
> Thanks for all the help so far from more people than I expected!

I've been  running a  kernel with  this patch  for a  few hours  and I'm
seeing a few fatal firmware errors in my dmesg:

iwn0: fatal firmware error
firmware error log:
  error type  = "SYSASSERT" (0x0005)
  program counter = 0x0001DFB0
  source line = 0x01FB
  error data  = 0x01FB000A
  branch link = 0x0001DF940001DF94
  interrupt link  = 0x0916
  time= 55706156
driver status:
  tx ring  0: qid=0  cur=2   queued=0
  tx ring  1: qid=1  cur=0   queued=0
  tx ring  2: qid=2  cur=0   queued=0
  tx ring  3: qid=3  cur=0   queued=0
  tx ring  4: qid=4  cur=30  queued=0
  tx ring  5: qid=5  cur=0   queued=0
  tx ring  6: qid=6  cur=0   queued=0
  tx ring  7: qid=7  cur=0   queued=0
  tx ring  8: qid=8  cur=0   queued=0
  tx ring  9: qid=9  cur=0   queued=0
  tx ring 10: qid=10 cur=0   queued=0
  tx ring 11: qid=11 cur=0   queued=0
  tx ring 12: qid=12 cur=0   queued=0
  tx ring 13: qid=13 cur=0   queued=0
  tx ring 14: qid=14 cur=0   queued=0
  tx ring 15: qid=15 cur=0   queued=0
  tx ring 16: qid=16 cur=0   queued=0
  tx ring 17: qid=17 cur=0   queued=0
  tx ring 18: qid=18 cur=0   queued=0
  tx ring 19: qid=19 cur=0   queued=0
  rx ring: cur=46
  802.11 state 4

These seem  to happen infrequently (the  last one was 3  hours ago), and
I've just noticed them so I don't have a pcap yet. I'm dumping right now
to see if it turns up again.

Apart from the  firmware errors, bandwidth is okay (3  Mbit/sec, but I'm
not the only  person in this WLAN) and scanning/attaching  seems to work
fine.

dmesg follows after the signature.

-- 
Gregor

OpenBSD 5.9-beta (GENERIC.MP) #153: Sun Dec 20 20:09:37 CET 2015
g...@hydrogen.unobtanium.de:/usr/src/sys/arch/amd64/compile/GENERIC.MP
real mem = 6314201088 (6021MB)
avail mem = 6118682624 (5835MB)
mpath0 at root
scsibus0 at mpath0: 256 targets
mainbus0 at root
bios0 at mainbus0: SMBIOS rev. 2.4 @ 0xe0010 (80 entries)
bios0: vendor LENOVO version "7UET94WW (3.24 )" date 10/17/2012
bios0: LENOVO 6474B84
acpi0 at bios0: rev 2
acpi0: sleep states S0 S3 S4 S5
acpi0: tables DSDT FACP SSDT ECDT APIC MCFG HPET SLIC BOOT ASF! SSDT TCPA DMAR 
SSDT SSDT SSDT
acpi0: wakeup devices LID_(S3) SLPB(S3) UART(S3) IGBE(S4) EXP0(S4) EXP1(S4) 
EXP2(S4) EXP3(S4) EXP4(S4) PCI1(S4) USB0(S3) USB3(S3) USB5(S3) EHC0(S3) 
EHC1(S3) HDEF(S4)
acpitimer0 at acpi0: 3579545 Hz, 24 bits
acpiec0 at acpi0
acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
cpu0 at mainbus0: apid 0 (boot processor)
cpu0: Intel(R) Core(TM)2 Duo CPU P8600 @ 2.40GHz, 2394.42 MHz
cpu0: 
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,SSE4.1,NXE,LONG,LAHF,PERF,SENSOR
cpu0: 3MB 64b/line 8-way L2 cache
cpu0: smt 0, core 0, package 0
mtrr: Pentium Pro MTRR support, 7 var ranges, 88 fixed ranges
cpu0: apic clock running at 266MHz
cpu0: mwait min=64, max=64, C-substates=0.2.2.2.2.1.3, IBE
cpu1 at mainbus0: apid 1 (application processor)
cpu1: Intel(R) Core(TM)2 Duo CPU P8600 @ 2.40GHz, 2394.01 MHz
cpu1: 
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,SSE4.1,NXE,LONG,LAHF,PERF,SENSOR
cpu1: 3MB 64b/line 8-way L2 cache
cpu1: smt 0, core 1, package 0
ioapic0 at mainbus0: apid 1 pa 0xfec0, version 20, 24 pins
ioapic0: misconfigured as apic 2, remapped to apid 1
acpimcfg0 at acpi0 addr 0xe000, bus 0-63
acpihpet0 at acpi0: 14318179 Hz
acpiprt0 at acpi0: bus 0 (PCI0)
acpiprt1 at acpi0: bus -1 (AGP_)
acpiprt2 at acpi0: bus 2 (EXP0)
acpiprt3 at acpi0: bus 3 (EXP1)
acpiprt4 at acpi0: bus -1 (EXP2)
acpiprt5 at acpi0: bus 5 (EXP3)
acpiprt6 at acpi0: 

Re: initial 11n support for iwn (n, not m)

[Gregor Best]

Hi Stefan,

On Wed, Dec 16, 2015 at 03:35:22PM +0100, Stefan Sperling wrote:
> This diff  adds 11n MCS  0-7 with A-MPDU and  A-MSDU Rx to  the iwn(4)
> driver.
> [...]

Whoo! Thanks a lot for your hard work :)

> [...]
> Please post  here or  let me  know in  private which  hardware you're.
> testing on Thanks.
> [...]

Works for me on:

iwn0 at pci2 dev 0 function 0 "Intel WiFi Link 5100" rev 0x00: msi, MIMO 1T2R, 
MoW, address 00:22:fa:d0:2f:a0

I have done some speed testing,  but with inconclusive results. I used a
Macbook Pro with  OS X as the  other side, testing was  done with iperf,
both machines connected to the same WiFi:

$ iperf -i 2 -c 192.168.178.54

Client connecting to 192.168.178.54, TCP port 5001
TCP window size: 17.0 KByte (default)

[  3] local 192.168.178.49 port 30131 connected with 192.168.178.54 port 5001
[ ID] Interval   Transfer Bandwidth
[  3]  0.0- 2.0 sec   768 KBytes  3.15 Mbits/sec
[  3]  2.0- 4.0 sec   640 KBytes  2.62 Mbits/sec
[  3]  4.0- 6.0 sec   640 KBytes  2.62 Mbits/sec
[  3]  6.0- 8.0 sec   512 KBytes  2.10 Mbits/sec
[  3]  8.0-10.0 sec   640 KBytes  2.62 Mbits/sec
[  3]  0.0-10.3 sec  3.25 MBytes  2.64 Mbits/sec

I assume the low  bandwidth is due to the two  thick walls separating my
laptops and the  access point. Everything else seems to  be fine though.
I'll  retry the  speed  measurement in  a  few days  when  I'm home  for
christmas.

> Note that if you'd like to test monitor mode you'll need to apply this
> to a -current source tree from today.
> [...]

Haven't  tested monitor  mode so  far, except  for the  IFF_PROMISC that
comes with the device being a trunkport. Works fine as far as I can see.

-- 
Gregor
--

BLISS is ignorance.

[vi/ex] Tilde expansion without forking off a shell

[Gregor Best]

Hi people,

the following  patch allows vi  (and ex)  to do tilde  expansion without
forking off a shell.  The algorithm is similar to the  one in mg, modulo
adaptions for  the way  vi handles  line buffers  and such.  This allows
editing files like  `~/foobar` in secure (-S) mode, where  fork and exec
are disabled.

There is  a slight difference in  behaviour compared to vi  without this
patch, which  is that the  old vi  allowed disabling tilde  expansion by
setting the `shellmeta` option to something that does not contain a `~`.
This can be re-added if it's needed though.

I sent  the same  patch to  Anthony a few  weeks back,  but I  assume he
hasn't gotten to taking a look at it yet.

-- 
Gregor

Index: common/options.c
===
RCS file: /mnt/media/cvs/src/usr.bin/vi/common/options.c,v
retrieving revision 1.19
diff -u -p -r1.19 options.c
--- common/options.c24 Nov 2015 10:28:14 -  1.19
+++ common/options.c9 Dec 2015 17:26:18 -
@@ -362,7 +362,7 @@ opts_init(SCR *sp, int *oargs)
(void)snprintf(b1, sizeof(b1),
"shell=%s", (s = getenv("SHELL")) == NULL ? _PATH_BSHELL : s);
OI(O_SHELL, b1);
-   OI(O_SHELLMETA, "shellmeta=~{[*?$`'\"\\");
+   OI(O_SHELLMETA, "shellmeta={[*?$`'\"\\");
OI(O_SHIFTWIDTH, "shiftwidth=8");
OI(O_SIDESCROLL, "sidescroll=16");
OI(O_TABSTOP, "tabstop=8");
Index: ex/ex_argv.c
===
RCS file: /mnt/media/cvs/src/usr.bin/vi/ex/ex_argv.c,v
retrieving revision 1.17
diff -u -p -r1.17 ex_argv.c
--- ex/ex_argv.c7 Dec 2015 20:39:19 -   1.17
+++ ex/ex_argv.c9 Dec 2015 17:27:57 -
@@ -11,6 +11,7 @@
 
 #include "config.h"
 
+#include 
 #include 
 #include 
 
@@ -19,6 +20,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -288,6 +290,58 @@ argv_exp3(SCR *sp, EXCMD *excp, char *cm
return (0);
 }
 
+/* Logic and code similar to mg:
+ * - expand tilde at beginning of file name
+ * - if ./~foo exists, don't expand
+ * - expand only one tilde
+ * - if file name matches ~foo/bar and foo is a user, replace ~foo by users' 
home dir
+ * - else replace ~ with current users home dir
+ */
+int
+expand_tilde(SCR *sp, char *cmd, char **p, char **bpp, size_t *blen, size_t 
*len) {
+   size_t tlen, off, ulen;
+   struct stat statbuf;
+   struct passwd *pw;
+   char un[LOGIN_NAME_MAX];
+   char *tmp;
+
+   if (cmd[0] != '~' || stat(cmd, ) == 0)
+   goto out;
+
+   if ((tmp = strchr(cmd, '/')) == NULL)
+   tmp = cmd + strlen(cmd); /* point to end of string */
+
+   ulen = tmp - [1];
+   if (ulen >= sizeof(un)) {
+   goto out;
+   }
+   if (ulen == 0) {
+   if ((tmp = getlogin()) == NULL)
+   goto out;
+   (void) strlcpy(un, tmp, sizeof(un));
+   } else {
+   memcpy(un, [1], ulen);
+   un[ulen] = '\0';
+   }
+
+   if ((pw = getpwnam(un)) == NULL)
+   goto out; /* XXX: print a warning message? */
+
+   tlen = strlen(pw->pw_dir);
+   *len += tlen;
+   off = *p - *bpp;
+   ADD_SPACE_GOTO(sp, *bpp, *blen, *len);
+   *p = *bpp + off;
+   memcpy(*p, pw->pw_dir, tlen);
+   *p += tlen;
+
+   return ulen + 1;
+
+out:
+alloc_err: /* ADD_SPACE_GOTO jumps here */
+   return 0;
+}
+
 /*
  * argv_fexp --
  * Do file name and bang command expansion.
@@ -299,6 +353,10 @@ argv_fexp(SCR *sp, EXCMD *excp, char *cm
EX_PRIVATE *exp;
char *bp, *t;
size_t blen, len, off, tlen;
+
+   tlen = expand_tilde(sp, cmd, , bpp, blenp, lenp);
+   cmd += tlen;
+   cmdlen -= tlen;
 
/* Replace file name characters. */
for (bp = *bpp, blen = *blenp, len = *lenp; cmdlen > 0; --cmdlen, ++cmd)

Pledge `dns' in httpd(8)

[Gregor Best]

Hi people,

httpd needs to pledge `dns' for name resolution to work while loading
the configuration:

# cat /tmp/test.conf
server "default" {
listen on imnotlocal port 80
}
# httpd -dnvf /tmp/test.conf
Abort trap
# dmesg | tail -n1
httpd(18331): syscall 97 "dns"

The issue is that `imnotlocal' is not a hostname that can be looked
up without DNS requests. `localhost' and entries in /etc/hosts work
fine for example. The attached patch adds `dns' to the pledge list
in httpd.c.

-- 
Gregor

Index: httpd.c
===
RCS file: /mnt/media/cvs/src/usr.sbin/httpd/httpd.c,v
retrieving revision 1.50
diff -u -p -r1.50 httpd.c
--- httpd.c 23 Nov 2015 20:56:14 -  1.50
+++ httpd.c 2 Dec 2015 21:11:49 -
@@ -251,7 +251,8 @@ main(int argc, char *argv[])
setproctitle("parent");
log_procinit("parent");
 
-   if (pledge("stdio rpath wpath cpath inet proc ioctl sendfd",
+   /* dns is required for load_config */
+   if (pledge("stdio rpath wpath cpath inet proc ioctl dns sendfd",
NULL) == -1)
fatal("pledge");
 

Re: vmm update

[Gregor Best]

Hi Mike,

on amd64 with a snapshot from today, I'm getting (transcribed):

kernel: page fault trap, code=0
ddb{1}> trace
vm_writepage() at vm_writepage+0x158
VOP_IOCTL() at VOP_IOCTL+0x44
vn_ioctl() at vn_ioctl+0x77
sys_ioctl() at sys_ioctl+0x196
syscall() at syscall+0x368
--- syscall (number 54) ---

when I try to start a VM with

vmmctl start "foo" memory 64M interfaces 1 disk `pwd`/test.img kernel 
/bsd.rd

That address is line 502 of arch/amd64/amd64/vmm.c. I played around
a bit with printfs, it looks like vm->vm_map has a weird value. The
printfs didn't output anything, but the fault moved to one that
essentially did

printf("%p\n", vm->vm_map->pmap);

A full dmesg for reference is attached below the signature. What
can I do to debug this further?

-- 
Gregor


OpenBSD 5.8-current (GENERIC.MP) #147: Wed Nov 25 21:21:13 CET 2015
g...@hydrogen.unobtanium.de:/usr/src/sys/arch/amd64/compile/GENERIC.MP
real mem = 6314201088 (6021MB)
avail mem = 6118686720 (5835MB)
mpath0 at root
scsibus0 at mpath0: 256 targets
mainbus0 at root
bios0 at mainbus0: SMBIOS rev. 2.4 @ 0xe0010 (80 entries)
bios0: vendor LENOVO version "7UET94WW (3.24 )" date 10/17/2012
bios0: LENOVO 6474B84
acpi0 at bios0: rev 2
acpi0: sleep states S0 S3 S4 S5
acpi0: tables DSDT FACP SSDT ECDT APIC MCFG HPET SLIC BOOT ASF! SSDT TCPA DMAR 
SSDT SSDT SSDT
acpi0: wakeup devices LID_(S3) SLPB(S3) UART(S3) IGBE(S4) EXP0(S4) EXP1(S4) 
EXP2(S4) EXP3(S4) EXP4(S4) PCI1(S4) USB0(S3) USB3(S3) USB5(S3) EHC0(S3) 
EHC1(S3) HDEF(S4)
acpitimer0 at acpi0: 3579545 Hz, 24 bits
acpiec0 at acpi0
acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
cpu0 at mainbus0: apid 0 (boot processor)
cpu0: Intel(R) Core(TM)2 Duo CPU P8600 @ 2.40GHz, 798.16 MHz
cpu0: 
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,SSE4.1,NXE,LONG,LAHF,PERF,SENSOR
cpu0: 3MB 64b/line 8-way L2 cache
cpu0: smt 0, core 0, package 0
mtrr: Pentium Pro MTRR support, 7 var ranges, 88 fixed ranges
cpu0: apic clock running at 266MHz
cpu0: mwait min=64, max=64, C-substates=0.2.2.2.2.1.3, IBE
cpu1 at mainbus0: apid 1 (application processor)
cpu1: Intel(R) Core(TM)2 Duo CPU P8600 @ 2.40GHz, 798.00 MHz
cpu1: 
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,SSE4.1,NXE,LONG,LAHF,PERF,SENSOR
cpu1: 3MB 64b/line 8-way L2 cache
cpu1: smt 0, core 1, package 0
ioapic0 at mainbus0: apid 1 pa 0xfec0, version 20, 24 pins
ioapic0: misconfigured as apic 2, remapped to apid 1
acpimcfg0 at acpi0 addr 0xe000, bus 0-63
acpihpet0 at acpi0: 14318179 Hz
acpiprt0 at acpi0: bus 0 (PCI0)
acpiprt1 at acpi0: bus -1 (AGP_)
acpiprt2 at acpi0: bus 2 (EXP0)
acpiprt3 at acpi0: bus 3 (EXP1)
acpiprt4 at acpi0: bus -1 (EXP2)
acpiprt5 at acpi0: bus 5 (EXP3)
acpiprt6 at acpi0: bus 13 (EXP4)
acpiprt7 at acpi0: bus 21 (PCI1)
acpicpu0 at acpi0: !C3(100@162 mwait.3@0x50), !C2(500@1 mwait.1@0x10), 
C1(1000@1 mwait.1), PSS
acpicpu1 at acpi0: !C3(100@162 mwait.3@0x50), !C2(500@1 mwait.1@0x10), 
C1(1000@1 mwait.1), PSS
acpipwrres0 at acpi0: PUBS, resource for USB0, USB3, USB5, EHC0, EHC1
acpitz0 at acpi0: critical temperature is 127 degC
acpitz1 at acpi0: critical temperature is 100 degC
acpibtn0 at acpi0: LID_
acpibtn1 at acpi0: SLPB
acpibat0 at acpi0: BAT0 model "42T4645" serial   597 type LION oem "Panasonic"
acpibat1 at acpi0: BAT1 not present
acpiac0 at acpi0: AC unit offline
acpithinkpad0 at acpi0
acpidock0 at acpi0: GDCK not docked (0)
cpu0: Enhanced SpeedStep 798 MHz: speeds: 2401, 2400, 1600, 800 MHz
pci0 at mainbus0 bus 0
pchb0 at pci0 dev 0 function 0 "Intel GM45 Host" rev 0x07
inteldrm0 at pci0 dev 2 function 0 "Intel GM45 Video" rev 0x07
drm0 at inteldrm0
intagp0 at inteldrm0
agp0 at intagp0: aperture at 0xd000, size 0x1000
inteldrm0: msi
inteldrm0: 1440x900
wsdisplay0 at inteldrm0 mux 1: console (std, vt100 emulation)
wsdisplay0: screen 1-5 added (std, vt100 emulation)
"Intel GM45 Video" rev 0x07 at pci0 dev 2 function 1 not configured
"Intel GM45 HECI" rev 0x07 at pci0 dev 3 function 0 not configured
em0 at pci0 dev 25 function 0 "Intel ICH9 IGP M AMT" rev 0x03: msi, address 
00:21:86:a1:1f:2b
uhci0 at pci0 dev 26 function 0 "Intel 82801I USB" rev 0x03: apic 1 int 20
uhci1 at pci0 dev 26 function 1 "Intel 82801I USB" rev 0x03: apic 1 int 21
uhci2 at pci0 dev 26 function 2 "Intel 82801I USB" rev 0x03: apic 1 int 22
ehci0 at pci0 dev 26 function 7 "Intel 82801I USB" rev 0x03: apic 1 int 23
usb0 at ehci0: USB revision 2.0
uhub0 at usb0 "Intel EHCI root hub" rev 2.00/1.00 addr 1
azalia0 at pci0 dev 27 function 0 "Intel 82801I HD Audio" rev 0x03: msi
azalia0: codecs: Conexant CX20561
audio0 at azalia0
ppb0 at pci0 dev 28 function 0 "Intel 82801I PCIE" rev 0x03: msi
pci1 at ppb0 

Re: vi: default to tab for filename completion

[Gregor Best]

On Mon, Nov 23, 2015 at 01:36:00AM -0700, Anthony J. Bentley wrote:
> [...]

In addition to this, my ~/.exrc also sets cedit to tab. Would this
make sense here as well? Currently it's disabled by default, but
IMHO it's a useful feature for longer editing sessions.

-- 
Gregor

Re: vi: don't escape backspace with backslash

[Gregor Best]

On Mon, Nov 23, 2015 at 01:31:11AM -0700, Anthony J. Bentley wrote:
> [...]
> I've passed this diff around privately before and gotten a tepid
> response, but it was pointed out to me that it would fit better on tech@.
> [...]

Yes, please.

-- 
Gregor

Re: em(4) watchdog timeouts

[Gregor Best]

On Mon, Nov 16, 2015 at 12:05:12AM +1000, David Gwynne wrote:
> On Fri, Nov 13, 2015 at 10:18:51AM -0500, Sonic wrote:
> > On Wed, Nov 11, 2015 at 9:20 AM, Gregor Best <g...@unobtanium.de> wrote:
> > > I've done some further testing and I think I've narrowed it down to the
> > > "Unlocking em(4) a bit further"-patch [0].
> 
> could you try this? its not written with the wdog stuff in mind,
> but it does touch that stuff so it might help.
> [...]

Just tried it, sadly it doesn't seem to help :/

To be sure, I enabled debug on the routers em's, but apart from the watchdog 
timeout, there's nothing in there.

-- 
Gregor

Pledge for Vi and Ex

[Gregor Best]

Hi people,

inspired by someone on Hackernews talking about how hard it would be to
properly pledge an editor, here's a patch to pledge Vi and Ex.

I'd like to go a bit deeper than this patch though: In addition to the
-S option which enables "secure mode", Vi and Ex have a -R switch, which
enables read-only mode. Currently, read-only mode can be overridden with
the `:w!` command or with `:set noro`, so it's more of a "set the
initial mode to be read-only" switch.

I'd like to make this switch a permanent "never ever write a file that's
not in /tmp or /var/tmp"-mode.  Would a patch that does this get
accepted?

Related:

- pledge("tmppath") currently allows writing and what not to
  files in /tmp. Would it make sense to expand this to /var/tmp? On
  normal OpenBSD systems, these are the same directory anyway and Vi for
  example stores its recovery files in /var/tmp.
- If you pledge("tmppath"), you can only open(2) files in /tmp if you
  supply the O_CREAT flag. Is this intentional? Opening existing files
  (even reopening files I've just created with O_CREAT) without the
  O_CREAT flag for writing requires pledge("wpath"), which I'd like to
  avoid for the hypothetical "Don't write anywhere" mode.
  Would a patch removing this restriction be accepted?

-- 
Gregor

Index: common/main.c
===
RCS file: /mnt/media/cvs/src/usr.bin/vi/common/main.c,v
retrieving revision 1.26
diff -u -p -u -r1.26 main.c
--- common/main.c   20 Nov 2014 08:50:53 -  1.26
+++ common/main.c   11 Nov 2015 13:01:34 -
@@ -17,6 +17,7 @@
 #include 
 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -229,6 +230,14 @@ editor(GS *gp, int argc, char *argv[])
}
if (LF_ISSET(SC_EX) && F_ISSET(gp, G_SCRIPTED))
silent = 1;
+
+   if (secure) {
+   if (pledge("stdio rpath wpath cpath fattr flock tty", NULL))
+   err(1, "pledge");
+   } else {
+   if (pledge("stdio rpath wpath cpath fattr flock tty proc exec", 
NULL))
+   err(1, "pledge");
+   }
 
/*
 * Build and initialize the first/current screen.  This is a bit

Re: em(4) watchdog timeouts

[Gregor Best]

I've done some further testing and I think I've narrowed it down to the
"Unlocking em(4) a bit further"-patch [0]. With the patch reverted, I
haven't seen any watchdog timeouts yet. I'm currently running the router
with the patch reverted to make sure the timeouts don't happen again.

[0]: https://www.marc.info/?l=openbsd-tech=144347723907388=4

-- 
Gregor

Re: em(4) watchdog timeouts

[Gregor Best]

Hi Alexis,

On Wed, Nov 11, 2015 at 08:11:15PM +, Alexis VACHETTE wrote:
> [...]
> Even with heavy network load ?
> [...]

So far, yes. I've saturated the device for about 45 Minutes with
something like this (the other end is my laptop):

## on the router
$ dd if=/dev/zero bs=8k | nc 172.31.64.174 55000
## on my laptop
$ nc -l 55000 | dd of=/dev/null bs=8k

(with two or three streams in parallel). There were about 6k
interrupts per second and bandwidth was about 250Mbps, which seems
to be the maximum the tiny CPU in this router can do. No watchdog
timeouts appeared, where previously something relatively low bandwidth
(the SSDs in router and laptop suck) like this caused one every 20
or 30 seconds:

## on the router
$ pax -w /home | nc 172.31.64.174 55000

I'll keep an eye on things, but so far it looks good. Regular usage
works out so far as well. If you need me to run some special workload
for you, I'd be more than happy to do that.

-- 
Gregor

Re: em(4) watchdog timeouts

[Gregor Best]

On Mon, Nov 02, 2015 at 09:29:20PM +0100, Gregor Best wrote:
> [...]
> Looks good so far. I've run a few light tests and the usual load that
> caused the timeouts before, haven't seen any yet.
> [...]

I just checked back on the router and it seems that the patch doesn't
help after all :( The number of watchdog timeouts went down, but they
are still there, about 35 in the last two days with network (and other)
load on the router almost nonexistant.

If it helps debugging this, I can give SSH access to the router,
provided that reboots don't happen between 18:00 and 02:00 German time
too often, since that's when we have larger amounts of visitors in our
hackerspace.

-- 
Gregor

Re: em(4) watchdog timeouts

[Gregor Best]

On Sun, Nov 08, 2015 at 06:57:23PM +0100, Gregor Best wrote:
> [...]
> If it helps debugging this, I can give SSH access to the router,
> provided that reboots don't happen between 18:00 and 02:00 German time
> too often, since that's when we have larger amounts of visitors in our
> hackerspace.
> [...]

Forgot to mention, the SSH access includes a push button monkey with a
console cable at hand (me) in case something goes wrong.

-- 
Gregor

Re: em(4) watchdog timeouts

[Gregor Best]

On Mon, Nov 02, 2015 at 08:11:30PM +0100, Mark Kettenis wrote:
> Can those that are experiencing watchdog timeouts check if the diff
> below gets rid of them?
> [...]

Looks good so far. I've run a few light tests and the usual load that
caused the timeouts before, haven't seen any yet.

For the record, this is with

em0 at pci1 dev 0 function 0 "Intel 82583V" rev 0x00: msi, address 
00:03:2d:20:cf:84
em1 at pci2 dev 0 function 0 "Intel 82583V" rev 0x00: msi, address 
00:03:2d:20:cf:85
em2 at pci3 dev 0 function 0 "Intel 82583V" rev 0x00: msi, address 
00:03:2d:20:cf:86
em3 at pci4 dev 0 function 0 "Intel 82583V" rev 0x00: msi, address 
00:03:2d:20:cf:87

on i386 (GENERIC.MP).

-- 
Gregor

Re: inteldrm(4) diff that needs testing

[Gregor Best]

On Sun, Oct 25, 2015 at 08:20:50AM -0700, Philip Guenther wrote:
> [...]
> This looks like the result of applying the diff but not running config
> [...]



Thanks for the clue bat. It's working fine on a Thinkpad T400.

-- 
Gregor

Pledge "id" for identd

[Gregor Best]

Hi people,

identd's parent process needs to pledge "id" so it can call setgroups
and friends later.

-- 
Gregor

Index: identd.c
===
RCS file: /mnt/media/cvs/src/usr.sbin/identd/identd.c,v
retrieving revision 1.32
diff -u -p -u -r1.32 identd.c
--- identd.c16 Oct 2015 05:55:23 -  1.32
+++ identd.c21 Oct 2015 19:50:23 -
@@ -314,7 +314,7 @@ main(int argc, char *argv[])
lerr(1, "signal(SIGPIPE)");
 
if (parent) {
-   if (pledge("stdio proc getpw rpath", NULL) == -1)
+   if (pledge("id stdio proc getpw rpath", NULL) == -1)
err(1, "pledge");
 
SIMPLEQ_INIT();

Re: smtpd: pledge, chmod and deliver_maildir

[Gregor Best]

Nice to see rubber duck debugging working. The attached patch seems to
be enough

-- 
Gregor
--

Index: smtpd.c
===
RCS file: /home/cvs/src/usr.sbin/smtpd/smtpd.c,v
retrieving revision 1.250
diff -u -p -u -r1.250 smtpd.c
--- smtpd.c 17 Oct 2015 16:03:20 -  1.250
+++ smtpd.c 21 Oct 2015 20:35:35 -
@@ -690,7 +690,7 @@ main(int argc, char *argv[])
 
purge_task();
 
-   if (pledge("stdio rpath wpath cpath flock tmppath "
+   if (pledge("fattr stdio rpath wpath cpath flock tmppath "
"getpw sendfd proc exec id inet unix", NULL) == -1)
err(1, "pledge");

smtpd: pledge, chmod and deliver_maildir

[Gregor Best]

Hi people,

I've noticed smtpd's deliver_maildir getting killed on syscall 15
(chmod) with the latest snapshot. I've rebuilt and core dumped it as
described by Sebastien and this is the backtrace I got:

#0  0x1d7e8175149a in chmod () at :2
#1  0x1d7c72744ffe in mkdirs (path=0x7f7dd0d0 "/home/gbe/Maildir", 
mode=448)
at /usr/src/usr.sbin/smtpd/smtpd/../util.c:223
#2  0x1d7c727471d0 in delivery_maildir_open
(deliver=0x7f7dd0d0) at 
/usr/src/usr.sbin/smtpd/smtpd/../delivery_maildir.c:99
#3  0x1d7c7273dd1e in parent_imsg (p=0x1d7e87f6a000,
imsg=Variable "imsg" is not available.)
at /usr/src/usr.sbin/smtpd/smtpd/../smtpd.c:1003
#4  0x1d7c7273afeb in imsg_dispatch (p=0x1d7e87f6a000,
imsg=0x7f7df270)
at /usr/src/usr.sbin/smtpd/smtpd/../smtpd.c:1283
#5  0x1d7c7271ed3c in mproc_dispatch (fd=Variable
"fd" is not available.
) at /usr/src/usr.sbin/smtpd/smtpd/../mproc.c:213
#6  0x1d7ec1d22008 in event_base_loop
(base=0x1d7ee286d800, flags=Variable "flags" is not
available.) at /usr/src/lib/libevent/event.c:350
#7  0x1d7c7273bf64 in main (argc=Variable "argc"
is not available.) at /usr/src/usr.sbin/smtpd/smtpd/../smtpd.c:697

smtpd's output looks like this when this happens:
[... noise omitted ...]
delivery: TempFail for 361bd1ee4342b3f8: from=,
to=, user=gbe, method=maildir, delay=0s, stat=Error
(terminated; signal 6)
debug: mda: session 757ea75d406dfe65 done
[... noise omitted ...]
(this is with "abort" added to all pledges)

The weird thing is that as far as I can see the process handling the
delivery seems to correctly pledge wpath. If I remove the pledge from
smtpd.c, line 693, everything works fine.

Any hints on how to debug this further? I can provide core files if
needed.

-- 
Gregor

Re: tame userland diff

[Gregor Best]

On Fri, Oct 02, 2015 at 01:49:13PM +0200, Tim Kuijsten wrote:
> [...]
> that's a 403..

Whoops, fixed.

-- 
Gregor
--

Kirkland, Illinois, law forbids bees to fly over the village or through
any of its streets.

Re: tame userland diff

[Gregor Best]

On Thu, Oct 01, 2015 at 06:55:21AM -0600, Theo de Raadt wrote:
> For those who are curious, this is the tame diff which is currently
> in snapshots.  Yes, we are asking for testing and feedback.
> [...]

I'm getting

ntpd(): syscall 97

with the patch applied. Kernel and ntpd sources are from a CVS checkout
I did yesterday.

I've ktrace'd ntpd, the trace file is at

http://unobtanium.de/static/ktrace-ntpd.out

-- 
Gregor

Re: Black screen with inteldrm and recent snapshots

[Gregor Best]

On Fri, Sep 25, 2015 at 01:32:07PM +0200, Mark Kettenis wrote:
> [...]
> I'm already onto that one.  For some reason the G45/GM45 chipset goes
> down a codepath that does a null-pointer dereference.
> [...]

If there's any way I can help, please let me know.

-- 
Gregor

Black screen with inteldrm and recent snapshots

[Gregor Best]

Hi people,

I just updated to a recent snapshot and once inteldrm attaches to my

vga1 at pci0 dev 2 function 0 "Intel GM45 Video" rev 0x07

the screen turns blank. Disabling inteldrm with boot -c prevents that,
but then of course X won't start. I have already tried reverting the
"Enable MSI on devices that support it"-commit, but that doesn't seem to
be the culprit. The next one seems to be the "update inteldrm"-commit.

How can I debug this?

-- 
Gregor

dmesg follows:

OpenBSD 5.8-current (GENERIC.MP) #117: Fri Sep 25 12:37:29 CEST 2015
g...@hydrogen.unobtanium.de:/usr/src/sys/arch/amd64/compile/GENERIC.MP
real mem = 6314201088 (6021MB)
avail mem = 6118731776 (5835MB)
User Kernel Config
UKC> disable inteldrm
213 inteldrm* disabled
UKC> boot
Unknown command, try help
UKC> exit
Continuing...
mpath0 at root
scsibus0 at mpath0: 256 targets
mainbus0 at root
bios0 at mainbus0: SMBIOS rev. 2.4 @ 0xe0010 (80 entries)
bios0: vendor LENOVO version "7UET94WW (3.24 )" date 10/17/2012
bios0: LENOVO 6474B84
acpi0 at bios0: rev 2
acpi0: sleep states S0 S3 S4 S5
acpi0: tables DSDT FACP SSDT ECDT APIC MCFG HPET SLIC BOOT ASF! SSDT TCPA DMAR 
SSDT SSDT SSDT
acpi0: wakeup devices LID_(S3) SLPB(S3) UART(S3) IGBE(S4) EXP0(S4) EXP1(S4) 
EXP2(S4) EXP3(S4) EXP4(S4) PCI1(S4) USB0(S3) USB3(S3) USB5(S3) EHC0(S3) 
EHC1(S3) HDEF(S4)
acpitimer0 at acpi0: 3579545 Hz, 24 bits
acpiec0 at acpi0
acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
cpu0 at mainbus0: apid 0 (boot processor)
cpu0: Intel(R) Core(TM)2 Duo CPU P8600 @ 2.40GHz, 2394.34 MHz
cpu0: 
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,SSE4.1,NXE,LONG,LAHF,PERF,SENSOR
cpu0: 3MB 64b/line 8-way L2 cache
cpu0: smt 0, core 0, package 0
mtrr: Pentium Pro MTRR support, 7 var ranges, 88 fixed ranges
cpu0: apic clock running at 265MHz
cpu0: mwait min=64, max=64, C-substates=0.2.2.2.2.1.3, IBE
cpu1 at mainbus0: apid 1 (application processor)
cpu1: Intel(R) Core(TM)2 Duo CPU P8600 @ 2.40GHz, 2394.00 MHz
cpu1: 
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,SSE4.1,NXE,LONG,LAHF,PERF,SENSOR
cpu1: 3MB 64b/line 8-way L2 cache
cpu1: smt 0, core 1, package 0
ioapic0 at mainbus0: apid 1 pa 0xfec0, version 20, 24 pins
ioapic0: misconfigured as apic 2, remapped to apid 1
acpimcfg0 at acpi0 addr 0xe000, bus 0-63
acpihpet0 at acpi0: 14318179 Hz
acpiprt0 at acpi0: bus 0 (PCI0)
acpiprt1 at acpi0: bus -1 (AGP_)
acpiprt2 at acpi0: bus 2 (EXP0)
acpiprt3 at acpi0: bus 3 (EXP1)
acpiprt4 at acpi0: bus -1 (EXP2)
acpiprt5 at acpi0: bus 5 (EXP3)
acpiprt6 at acpi0: bus 13 (EXP4)
acpiprt7 at acpi0: bus 21 (PCI1)
acpicpu0 at acpi0: !C3(100@57 mwait.3@0x30), !C2(500@1 mwait.1@0x10), C1(1000@1 
mwait.1), PSS
acpicpu1 at acpi0: !C3(100@57 mwait.3@0x30), !C2(500@1 mwait.1@0x10), C1(1000@1 
mwait.1), PSS
acpipwrres0 at acpi0: PUBS, resource for USB0, USB3, USB5, EHC0, EHC1
acpitz0 at acpi0: critical temperature is 127 degC
acpitz1 at acpi0: critical temperature is 100 degC
acpibtn0 at acpi0: LID_
acpibtn1 at acpi0: SLPB
acpibat0 at acpi0: BAT0 model "42T4645" serial   597 type LION oem "Panasonic"
acpibat1 at acpi0: BAT1 not present
acpiac0 at acpi0: AC unit online
acpithinkpad0 at acpi0
acpidock0 at acpi0: GDCK not docked (0)
cpu0: Enhanced SpeedStep 2394 MHz: speeds: 2401, 2400, 1600, 800 MHz
pci0 at mainbus0 bus 0
pchb0 at pci0 dev 0 function 0 "Intel GM45 Host" rev 0x07
vga1 at pci0 dev 2 function 0 "Intel GM45 Video" rev 0x07
intagp0 at vga1
agp0 at intagp0: aperture at 0xd000, size 0x1000
wsdisplay0 at vga1 mux 1: console (80x25, vt100 emulation)
wsdisplay0: screen 1-5 added (80x25, vt100 emulation)
"Intel GM45 Video" rev 0x07 at pci0 dev 2 function 1 not configured
"Intel GM45 HECI" rev 0x07 at pci0 dev 3 function 0 not configured
em0 at pci0 dev 25 function 0 "Intel ICH9 IGP M AMT" rev 0x03: msi, address 
00:21:86:a1:1f:2b
uhci0 at pci0 dev 26 function 0 "Intel 82801I USB" rev 0x03: apic 1 int 20
uhci1 at pci0 dev 26 function 1 "Intel 82801I USB" rev 0x03: apic 1 int 21
uhci2 at pci0 dev 26 function 2 "Intel 82801I USB" rev 0x03: apic 1 int 22
ehci0 at pci0 dev 26 function 7 "Intel 82801I USB" rev 0x03: apic 1 int 23
usb0 at ehci0: USB revision 2.0
uhub0 at usb0 "Intel EHCI root hub" rev 2.00/1.00 addr 1
azalia0 at pci0 dev 27 function 0 "Intel 82801I HD Audio" rev 0x03: msi
azalia0: codecs: Conexant CX20561
audio0 at azalia0
ppb0 at pci0 dev 28 function 0 "Intel 82801I PCIE" rev 0x03: msi
pci1 at ppb0 bus 2
ppb1 at pci0 dev 28 function 1 "Intel 82801I PCIE" rev 0x03: msi
pci2 at ppb1 bus 3
iwn0 at pci2 dev 0 function 0 "Intel WiFi Link 5100" rev 0x00: msi, MIMO 1T2R, 
MoW, address 00:22:fa:d0:2f:a0
ppb2 at pci0 dev 28 function 3 "Intel 82801I PCIE" rev 0x03: msi
pci3 at ppb2 bus 5
ppb3 at pci0 dev 28 

[patch] fdisk: show value range for partition offset/size

[Gregor Best]

Hi people,

the following patch changes the prompt for the 'Partition size' and
'Partition offset' prompts in fdisk to show the range of allowed values
and display the raw value as well when showing an error for out of
bounds values.

Index: misc.c
===
RCS file: /mnt/media/cvs/src/sbin/fdisk/misc.c,v
retrieving revision 1.52
diff -u -p -u -r1.52 misc.c
--- misc.c  27 Aug 2015 20:58:27 -  1.52
+++ misc.c  5 Sep 2015 14:22:13 -
@@ -213,7 +213,7 @@ getuint64(char *prompt, u_int64_t oval, 
secpercyl = disk.sectors * disk.heads;
 
do {
-   printf("%s: [%llu] ", prompt, oval);
+   printf("%s [0 - %llu]: [%llu] ", prompt, maxval, oval);
 
if (fgets(buf, sizeof(buf), stdin) == NULL)
errx(1, "eof");
@@ -302,8 +302,8 @@ getuint64(char *prompt, u_int64_t oval, 
}
 
if (saveerr == ERANGE || d > maxval || d < 0 || d < d2) {
-   printf("%s is out of range: %c%s%c\n", prompt, operator,
-   p, unit);
+   printf("%s is out of range: %c%s%c (%lld)\n", prompt, 
operator,
+   p, unit, (int64_t)d);
} else if (*endptr != '\0') {
printf("%s is invalid: %c%s%c\n", prompt, operator,
p, unit);

-- 
Gregor

Re: doas authentication type

[Gregor Best]

On Wed, Aug 26, 2015 at 08:42:31AM +0200, Renaud Allard wrote:
 [...]
 + fprintf(stderr, usage: doas [-ans] [-C config] [-u user] command
 [args]\n);
 [...]

The usage string should probably be

   usage: doas [-ns] [-a style] [-C config] [-u user] command [args]

and the new option should appear in doas(1).

-- 
Gregor

[patch] update unbound forwards with dhclient nameservers

[Gregor Best]

Hello,

the following is a patch that adds an option called `update_unbound' to
dhclient.conf. With this option enabled, dhclient will call

unbound-control forwards ns1 ns2 ns3

instead of rewriting /etc/resolv.conf.

My usage scenario is that I'm running unbound on my laptop as a local
resolver. /etc/resolv.conf is configured to only use 127.0.0.1 as the
nameserver.

I use this because I have a few VPN connections that have custom DNS
namespaces, which I manage with Unbound's forward zones.  Since
sometimes I am in networks that have a split horizon DNS (e.g.
University, hackerspace, etc...), I can't use a statically configured
fallback forward zone for all my requests. Manually calling using
unbound-control to change the forward DNS became too annoying, so I
wrote this patch.

Does the patch make sense in OpenBSD or should I keep it as a local
change?

-- 
Gregor Best
--

Index: clparse.c
===
RCS file: /mnt/media/cvs/src/sbin/dhclient/clparse.c,v
retrieving revision 1.92
diff -u -p -r1.92 clparse.c
--- clparse.c   18 May 2015 17:51:21 -  1.92
+++ clparse.c   9 Jul 2015 15:00:05 -
@@ -75,6 +75,7 @@ read_client_conf(void)
config-backoff_cutoff = 15;
config-initial_interval = 3;
config-bootp_policy = ACCEPT;
+   config-update_unbound = 0;
config-requested_options
[config-requested_option_count++] = DHO_SUBNET_MASK;
config-requested_options
@@ -269,6 +270,10 @@ parse_client_statement(FILE *cfile)
case TOK_NEXT_SERVER:
if (parse_ip_addr(cfile, config-next_server))
parse_semi(cfile);
+   break;
+   case TOK_UPDATE_UNBOUND:
+   config-update_unbound = 1;
+   parse_semi(cfile);
break;
default:
parse_warn(expecting a statement.);
Index: conflex.c
===
RCS file: /mnt/media/cvs/src/sbin/dhclient/conflex.c,v
retrieving revision 1.32
diff -u -p -r1.32 conflex.c
--- conflex.c   18 May 2015 17:51:21 -  1.32
+++ conflex.c   9 Jul 2015 14:54:56 -
@@ -341,7 +341,8 @@ static const struct keywords {
{ send,   TOK_SEND },
{ server-name,TOK_SERVER_NAME },
{ supersede,  TOK_SUPERSEDE },
-   { timeout,TOK_TIMEOUT }
+   { timeout,TOK_TIMEOUT },
+   { update_unbound, TOK_UPDATE_UNBOUND }
 };
 
 intkw_cmp(const void *k, const void *e);
Index: dhclient.c
===
RCS file: /mnt/media/cvs/src/sbin/dhclient/dhclient.c,v
retrieving revision 1.361
diff -u -p -r1.361 dhclient.c
--- dhclient.c  18 May 2015 14:59:42 -  1.361
+++ dhclient.c  9 Jul 2015 15:52:41 -
@@ -97,6 +97,7 @@ intres_hnok(const char *dn);
 
 voidfork_privchld(int, int);
 voidget_ifname(char *);
+voidupdate_unbound_forwards(struct option_data *);
 char   *resolv_conf_contents(struct option_data  *,
 struct option_data *);
 voidwrite_resolv_conf(u_int8_t *, size_t);
@@ -903,8 +904,12 @@ bind_lease(void)
goto newlease;
}
 
-   client-new-resolv_conf = resolv_conf_contents(
-   options[DHO_DOMAIN_NAME], options[DHO_DOMAIN_NAME_SERVERS]);
+   if (config-update_unbound) {
+   update_unbound_forwards(options[DHO_DOMAIN_NAME_SERVERS]);
+   } else {
+   client-new-resolv_conf = resolv_conf_contents(
+   options[DHO_DOMAIN_NAME], 
options[DHO_DOMAIN_NAME_SERVERS]);
+   }
 
/* Replace the old active lease with the new one. */
client-active = client-new;
@@ -2042,6 +2047,88 @@ get_ifname(char *arg)
close(s);
} else if (strlcpy(ifi-name, arg, IFNAMSIZ) = IFNAMSIZ)
error(Interface name too long);
+}
+
+/*
+ * Update unbound forwarder list
+ */
+void
+update_unbound_forwards(struct option_data *nameservers)
+{
+   char *ns;
+   int rslt;
+
+   if (!nameservers-len) {
+   return;
+   }
+
+   ns = pretty_print_option(DHO_DOMAIN_NAME_SERVERS, nameservers, 0);
+
+   rslt = imsg_compose(unpriv_ibuf, IMSG_UPDATE_UNBOUND_FORWARDS,
+   0, 0, -1, ns, strlen(ns) + 1);
+
+   if (rslt == -1) {
+   warning(update_unbound_forwards: imsg_compose: %s,
+   strerror(errno));
+   }
+
+   flush_unpriv_ibuf(update_unbound_forwards);
+}
+
+void
+priv_update_unbound_forwards(struct imsg *imsg)
+{
+   char *args[MAXNS + 3]; /* `unbound-control', `forward', final NULL */
+   char *ns, *p;
+   int i, rslt;
+   size_t sz;
+   pid_t child;
+
+   if (imsg-hdr.len

Re: [patch] update unbound forwards with dhclient nameservers

[Gregor Best]

On Sun, Jul 19, 2015 at 07:03:59PM +0100, Stuart Henderson wrote:
 [...]
 I'm uncertain about whether dhclient should do this at all, it seems
 to be the opposite of the direction dhclient has been going in
 recently,
 [...]

I've had a similar intuition at first, but it's one less thing to run
versus the monitor lease file approach and it only calls one static
external command with relatively fixed parameters instead of what the
removed `script' option did. In the end, it's a matter of personal
taste, I think.

 [...]
 but if it is added, it probably wants to be disabled for the ramdisk.
 [...]

I've attached an updated patch, in case this is still interesting to
someone. Do I need to add anything other than `#ifdef SMALL' in the
appropriate places?

-- 
Gregor Best
--

Index: clparse.c
===
RCS file: /mnt/media/cvs/src/sbin/dhclient/clparse.c,v
retrieving revision 1.92
diff -u -p -r1.92 clparse.c
--- clparse.c   18 May 2015 17:51:21 -  1.92
+++ clparse.c   19 Jul 2015 18:44:12 -
@@ -75,6 +75,9 @@ read_client_conf(void)
config-backoff_cutoff = 15;
config-initial_interval = 3;
config-bootp_policy = ACCEPT;
+#ifndef SMALL
+   config-update_unbound = 0;
+#endif
config-requested_options
[config-requested_option_count++] = DHO_SUBNET_MASK;
config-requested_options
@@ -270,6 +273,12 @@ parse_client_statement(FILE *cfile)
if (parse_ip_addr(cfile, config-next_server))
parse_semi(cfile);
break;
+#ifndef SMALL
+   case TOK_UPDATE_UNBOUND:
+   config-update_unbound = 1;
+   parse_semi(cfile);
+   break;
+#endif
default:
parse_warn(expecting a statement.);
if (token != ';')
Index: conflex.c
===
RCS file: /mnt/media/cvs/src/sbin/dhclient/conflex.c,v
retrieving revision 1.32
diff -u -p -r1.32 conflex.c
--- conflex.c   18 May 2015 17:51:21 -  1.32
+++ conflex.c   19 Jul 2015 18:48:00 -
@@ -341,7 +341,10 @@ static const struct keywords {
{ send,   TOK_SEND },
{ server-name,TOK_SERVER_NAME },
{ supersede,  TOK_SUPERSEDE },
-   { timeout,TOK_TIMEOUT }
+   { timeout,TOK_TIMEOUT },
+#ifndef SMALL
+   { update-unbound, TOK_UPDATE_UNBOUND }
+#endif
 };
 
 intkw_cmp(const void *k, const void *e);
Index: dhclient.c
===
RCS file: /mnt/media/cvs/src/sbin/dhclient/dhclient.c,v
retrieving revision 1.361
diff -u -p -r1.361 dhclient.c
--- dhclient.c  18 May 2015 14:59:42 -  1.361
+++ dhclient.c  19 Jul 2015 18:45:28 -
@@ -97,6 +97,9 @@ intres_hnok(const char *dn);
 
 voidfork_privchld(int, int);
 voidget_ifname(char *);
+#ifndef SMALL
+voidupdate_unbound_forwards(struct option_data *);
+#endif
 char   *resolv_conf_contents(struct option_data  *,
 struct option_data *);
 voidwrite_resolv_conf(u_int8_t *, size_t);
@@ -903,8 +906,15 @@ bind_lease(void)
goto newlease;
}
 
-   client-new-resolv_conf = resolv_conf_contents(
-   options[DHO_DOMAIN_NAME], options[DHO_DOMAIN_NAME_SERVERS]);
+#ifndef SMALL
+   if (config-update_unbound) {
+   update_unbound_forwards(options[DHO_DOMAIN_NAME_SERVERS]);
+   } else
+#endif
+   {
+   client-new-resolv_conf = resolv_conf_contents(
+   options[DHO_DOMAIN_NAME], 
options[DHO_DOMAIN_NAME_SERVERS]);
+   }
 
/* Replace the old active lease with the new one. */
client-active = client-new;
@@ -2043,6 +2053,91 @@ get_ifname(char *arg)
} else if (strlcpy(ifi-name, arg, IFNAMSIZ) = IFNAMSIZ)
error(Interface name too long);
 }
+
+#ifndef SMALL
+/*
+ * Update unbound forwarder list
+ */
+void
+update_unbound_forwards(struct option_data *nameservers)
+{
+   char *ns;
+   int rslt;
+
+   if (!nameservers-len) {
+   return;
+   }
+
+   ns = pretty_print_option(DHO_DOMAIN_NAME_SERVERS, nameservers, 0);
+
+   rslt = imsg_compose(unpriv_ibuf, IMSG_UPDATE_UNBOUND_FORWARDS,
+   0, 0, -1, ns, strlen(ns) + 1);
+
+   if (rslt == -1) {
+   warning(update_unbound_forwards: imsg_compose: %s,
+   strerror(errno));
+   }
+
+   flush_unpriv_ibuf(update_unbound_forwards);
+}
+
+void
+priv_update_unbound_forwards(struct imsg *imsg)
+{
+   char *args[MAXNS + 3]; /* `unbound-control', `forward', final NULL */
+   char *ns, *p, **srv;
+   int rslt, i = 0;
+   size_t sz;
+   pid_t child

Re: [patch] update unbound forwards with dhclient nameservers

[Gregor Best]

On Sun, Jul 19, 2015 at 03:31:33PM +, Florian Obser wrote:
 [...]
 Oh god, yes please. I always wanted to write this diff myself ;)
 More comments in the diff below.
 [...]

Great to read. I've attached an updated patch.

-- 
Gregor Best

Index: clparse.c
===
RCS file: /mnt/media/cvs/src/sbin/dhclient/clparse.c,v
retrieving revision 1.92
diff -u -p -r1.92 clparse.c
--- clparse.c   18 May 2015 17:51:21 -  1.92
+++ clparse.c   9 Jul 2015 15:00:05 -
@@ -75,6 +75,7 @@ read_client_conf(void)
config-backoff_cutoff = 15;
config-initial_interval = 3;
config-bootp_policy = ACCEPT;
+   config-update_unbound = 0;
config-requested_options
[config-requested_option_count++] = DHO_SUBNET_MASK;
config-requested_options
@@ -269,6 +270,10 @@ parse_client_statement(FILE *cfile)
case TOK_NEXT_SERVER:
if (parse_ip_addr(cfile, config-next_server))
parse_semi(cfile);
+   break;
+   case TOK_UPDATE_UNBOUND:
+   config-update_unbound = 1;
+   parse_semi(cfile);
break;
default:
parse_warn(expecting a statement.);
Index: conflex.c
===
RCS file: /mnt/media/cvs/src/sbin/dhclient/conflex.c,v
retrieving revision 1.32
diff -u -p -r1.32 conflex.c
--- conflex.c   18 May 2015 17:51:21 -  1.32
+++ conflex.c   19 Jul 2015 17:31:13 -
@@ -341,7 +341,8 @@ static const struct keywords {
{ send,   TOK_SEND },
{ server-name,TOK_SERVER_NAME },
{ supersede,  TOK_SUPERSEDE },
-   { timeout,TOK_TIMEOUT }
+   { timeout,TOK_TIMEOUT },
+   { update-unbound, TOK_UPDATE_UNBOUND }
 };
 
 intkw_cmp(const void *k, const void *e);
Index: dhclient.c
===
RCS file: /mnt/media/cvs/src/sbin/dhclient/dhclient.c,v
retrieving revision 1.361
diff -u -p -r1.361 dhclient.c
--- dhclient.c  18 May 2015 14:59:42 -  1.361
+++ dhclient.c  19 Jul 2015 17:48:11 -
@@ -97,6 +97,7 @@ intres_hnok(const char *dn);
 
 voidfork_privchld(int, int);
 voidget_ifname(char *);
+voidupdate_unbound_forwards(struct option_data *);
 char   *resolv_conf_contents(struct option_data  *,
 struct option_data *);
 voidwrite_resolv_conf(u_int8_t *, size_t);
@@ -903,8 +904,12 @@ bind_lease(void)
goto newlease;
}
 
-   client-new-resolv_conf = resolv_conf_contents(
-   options[DHO_DOMAIN_NAME], options[DHO_DOMAIN_NAME_SERVERS]);
+   if (config-update_unbound) {
+   update_unbound_forwards(options[DHO_DOMAIN_NAME_SERVERS]);
+   } else {
+   client-new-resolv_conf = resolv_conf_contents(
+   options[DHO_DOMAIN_NAME], 
options[DHO_DOMAIN_NAME_SERVERS]);
+   }
 
/* Replace the old active lease with the new one. */
client-active = client-new;
@@ -2042,6 +2047,89 @@ get_ifname(char *arg)
close(s);
} else if (strlcpy(ifi-name, arg, IFNAMSIZ) = IFNAMSIZ)
error(Interface name too long);
+}
+
+/*
+ * Update unbound forwarder list
+ */
+void
+update_unbound_forwards(struct option_data *nameservers)
+{
+   char *ns;
+   int rslt;
+
+   if (!nameservers-len) {
+   return;
+   }
+
+   ns = pretty_print_option(DHO_DOMAIN_NAME_SERVERS, nameservers, 0);
+
+   rslt = imsg_compose(unpriv_ibuf, IMSG_UPDATE_UNBOUND_FORWARDS,
+   0, 0, -1, ns, strlen(ns) + 1);
+
+   if (rslt == -1) {
+   warning(update_unbound_forwards: imsg_compose: %s,
+   strerror(errno));
+   }
+
+   flush_unpriv_ibuf(update_unbound_forwards);
+}
+
+void
+priv_update_unbound_forwards(struct imsg *imsg)
+{
+   char *args[MAXNS + 3]; /* `unbound-control', `forward', final NULL */
+   char *ns, *p, **srv;
+   int rslt, i = 0;
+   size_t sz;
+   pid_t child;
+
+   if (imsg-hdr.len  IMSG_HEADER_SIZE) {
+   warning(short IMSG_UPDATE_UNBOUND_FORWARDS);
+   return;
+   }
+
+   ns = imsg-data;
+   sz = imsg-hdr.len - IMSG_HEADER_SIZE;
+   ns[sz] = '\0'; /* Make sure we're terminated properly */
+
+   /* Construct unbound-control arguments */
+   memset(args, 0, sizeof(args));
+   args[0] = unbound-control;
+   args[1] = forward;
+   srv = args[2];
+   while (i  MAXNS) {
+   p = strsep(ns,  );
+   if (p == NULL)
+   break;
+   if (*p == '\0')
+   continue;
+   rslt

Re: Fix for segfault in find(1)

[Gregor Best]

On Tue, Jul 14, 2015 at 09:57:45AM -0600, Todd C. Miller wrote:
 [...]
 Shouldn't this be:
 
   p = (p - *store) + newstore;
 [...]

Of course, that makes way more sense. An amended patch is attached.

-- 
Gregor

Index: misc.c
===
RCS file: /mnt/media/cvs/src/usr.bin/find/misc.c,v
retrieving revision 1.12
diff -u -p -u -r1.12 misc.c
--- misc.c  18 May 2014 08:10:00 -  1.12
+++ misc.c  14 Jul 2015 16:07:28 -
@@ -65,6 +65,7 @@ brace_subst(char *orig, char **store, ch
 
if (!(newstore = realloc(*store, newlen)))
err(1, NULL);
+   p = (p - *store) + newstore;
*store = newstore;
len = newlen;
}

Re: important audio simplifications to test and review

[Gregor Best]

On Thu, Jun 11, 2015 at 09:20:54AM +0200, Alexandre Ratchov wrote:
 [...]
 To test this diff, simply run your regular audio stuff and let us
 know if you notice any difference. I'd suggest to keep a copy of
 the old kernel in order to be able to compare easily.
 [...]

I've been listening to music all day and am currently watching a movie
with this, no regressions so far. This is with

 $ dmesg | grep -E '(audio|azalia)'
 azalia0 at pci0 dev 27 function 0 Intel 82801I HD Audio rev 0x03: msi
 azalia0: codecs: Conexant CX20561
 audio0 at azalia0

-- 
Gregor Best
--

Opinions are like assholes -- everyone's got one, but nobody wants to
look at the other guy's.
-- Hal Hickman

Re: Add support for Arduino Leonardo to umodem(4)

[Gregor Best]

On Mon, Feb 16, 2015 at 02:20:06PM +, Stuart Henderson wrote:
 [...]
 It's Arduino SA isn't it? The rest looks good to me.
 [...]

The controller reports itself as made by 'Arduino LLC' in the usbdevs
output, but according to http://www.linux-usb.org/usb.ids, you're right.
I think going with the established name is a better idea. I've attached
an amended patch.

-- 
Gregor Best

Index: dev/usb/umodem.c
===
RCS file: /mnt/media/cvs/src/sys/dev/usb/umodem.c,v
retrieving revision 1.57
diff -u -p -u -r1.57 umodem.c
--- dev/usb/umodem.c12 Jul 2014 20:26:33 -  1.57
+++ dev/usb/umodem.c13 Feb 2015 19:36:39 -
@@ -250,6 +250,10 @@ umodem_match(struct device *parent, void
id-bInterfaceNumber == 0)
ret = UMATCH_VENDOR_PRODUCT;
 
+   if (UGETW(dd-idVendor) == USB_VENDOR_ARDUINO 
+   UGETW(dd-idProduct) == USB_PRODUCT_ARDUINO_LEONARDO)
+   ret = UMATCH_VENDOR_PRODUCT;
+
if (ret == UMATCH_NONE 
id-bInterfaceClass == UICLASS_CDC 
id-bInterfaceSubClass == UISUBCLASS_ABSTRACT_CONTROL_MODEL 
Index: dev/usb/usbdevs
===
RCS file: /mnt/media/cvs/src/sys/dev/usb/usbdevs,v
retrieving revision 1.644
diff -u -p -u -r1.644 usbdevs
--- dev/usb/usbdevs 9 Jan 2015 20:41:48 -   1.644
+++ dev/usb/usbdevs 13 Feb 2015 19:36:40 -
@@ -54,6 +54,7 @@ vendor PLANEX40x0053  Planex Communicat
 vendor UNKNOWN20x0105  Unknown vendor
 vendor EGALAX2 0x0123  eGalax
 vendor UNKNOWN60x01e1  Unknown vendor
+vendor ARDUINO 0x2341  Arduino SA
 vendor HUMAX   0x02ad  HUMAX
 vendor BWCT0x03da  Bernd Walter Computer Technology
 vendor AOX 0x03e8  AOX
@@ -977,6 +978,9 @@ product APPLE ISIGHT0x8502  iSight
 
 /* Araneus Information Systems products */
 product ARANEUS ALEA   0x0001  True Random Number Generator
+
+/* Arduino SA products */
+product ARDUINO LEONARDO   0x8036  Arduino Lenoardo
 
 /* Arkmicro products */
 product ARKMICRO ARK3116   0x0232  ARK3116 Serial
Index: dev/usb/usbdevs.h
===
RCS file: /mnt/media/cvs/src/sys/dev/usb/usbdevs.h,v
retrieving revision 1.656
diff -u -p -u -r1.656 usbdevs.h
--- dev/usb/usbdevs.h   9 Jan 2015 20:42:40 -   1.656
+++ dev/usb/usbdevs.h   13 Feb 2015 19:36:44 -
@@ -1,4 +1,4 @@
-/* $OpenBSD: usbdevs.h,v 1.656 2015/01/09 20:42:40 kettenis Exp $  */
+/* $OpenBSD$   */
 
 /*
  * THIS FILE IS AUTOMATICALLY GENERATED.  DO NOT EDIT.
@@ -61,6 +61,7 @@
 #defineUSB_VENDOR_UNKNOWN2 0x0105  /* Unknown vendor */
 #defineUSB_VENDOR_EGALAX2  0x0123  /* eGalax */
 #defineUSB_VENDOR_UNKNOWN6 0x01e1  /* Unknown vendor */
+#defineUSB_VENDOR_ARDUINO  0x2341  /* Arduino SA */
 #defineUSB_VENDOR_HUMAX0x02ad  /* HUMAX */
 #defineUSB_VENDOR_BWCT 0x03da  /* Bernd Walter Computer 
Technology */
 #defineUSB_VENDOR_AOX  0x03e8  /* AOX */
@@ -984,6 +985,9 @@
 
 /* Araneus Information Systems products */
 #defineUSB_PRODUCT_ARANEUS_ALEA0x0001  /* True Random 
Number Generator */
+
+/* Arduino SA products */
+#defineUSB_PRODUCT_ARDUINO_LEONARDO0x8036  /* Arduino 
Lenoardo */
 
 /* Arkmicro products */
 #defineUSB_PRODUCT_ARKMICRO_ARK31160x0232  /* ARK3116 
Serial */
Index: dev/usb/usbdevs_data.h
===
RCS file: /mnt/media/cvs/src/sys/dev/usb/usbdevs_data.h,v
retrieving revision 1.650
diff -u -p -u -r1.650 usbdevs_data.h
--- dev/usb/usbdevs_data.h  9 Jan 2015 20:42:40 -   1.650
+++ dev/usb/usbdevs_data.h  13 Feb 2015 19:36:44 -
@@ -1,4 +1,4 @@
-/* $OpenBSD: usbdevs_data.h,v 1.650 2015/01/09 20:42:40 kettenis Exp $ 
*/
+/* $OpenBSD$   */
 
 /*
  * THIS FILE IS AUTOMATICALLY GENERATED.  DO NOT EDIT.
@@ -962,6 +962,10 @@ const struct usb_known_product usb_known
True Random Number Generator,
},
{
+   USB_VENDOR_ARDUINO, USB_PRODUCT_ARDUINO_LEONARDO,
+   Arduino Lenoardo,
+   },
+   {
USB_VENDOR_ARKMICRO, USB_PRODUCT_ARKMICRO_ARK3116,
ARK3116 Serial,
},
@@ -11248,6 +11252,10 @@ const struct usb_known_vendor usb_known_
{
USB_VENDOR_UNKNOWN6,
Unknown vendor,
+   },
+   {
+   USB_VENDOR_ARDUINO,
+   Arduino SA,
},
{
USB_VENDOR_HUMAX,

Add support for Arduino Leonardo to umodem(4)

[Gregor Best]

Hi,

Arduino Leonardos emulate a CDC ACM modem for their serial port. The
following patch adds explicit matching for those in umodem_match,
because apparently the emulation done by the Leonardo is not complete
enough to make umodem attach automatically.

I've tested a kernel with this patch for a few days now, but only with a
baudrate of 115200, which seems to work fine.

-- 
Gregor Best

Index: dev/usb/umodem.c
===
RCS file: /mnt/media/cvs/src/sys/dev/usb/umodem.c,v
retrieving revision 1.57
diff -u -p -u -r1.57 umodem.c
--- dev/usb/umodem.c12 Jul 2014 20:26:33 -  1.57
+++ dev/usb/umodem.c13 Feb 2015 19:36:39 -
@@ -250,6 +250,10 @@ umodem_match(struct device *parent, void
id-bInterfaceNumber == 0)
ret = UMATCH_VENDOR_PRODUCT;
 
+   if (UGETW(dd-idVendor) == USB_VENDOR_ARDUINO 
+   UGETW(dd-idProduct) == USB_PRODUCT_ARDUINO_LEONARDO)
+   ret = UMATCH_VENDOR_PRODUCT;
+
if (ret == UMATCH_NONE 
id-bInterfaceClass == UICLASS_CDC 
id-bInterfaceSubClass == UISUBCLASS_ABSTRACT_CONTROL_MODEL 
Index: dev/usb/usbdevs
===
RCS file: /mnt/media/cvs/src/sys/dev/usb/usbdevs,v
retrieving revision 1.644
diff -u -p -u -r1.644 usbdevs
--- dev/usb/usbdevs 9 Jan 2015 20:41:48 -   1.644
+++ dev/usb/usbdevs 13 Feb 2015 19:36:40 -
@@ -54,6 +54,7 @@ vendor PLANEX40x0053  Planex Communicat
 vendor UNKNOWN20x0105  Unknown vendor
 vendor EGALAX2 0x0123  eGalax
 vendor UNKNOWN60x01e1  Unknown vendor
+vendor ARDUINO 0x2341  Arduino LLC
 vendor HUMAX   0x02ad  HUMAX
 vendor BWCT0x03da  Bernd Walter Computer Technology
 vendor AOX 0x03e8  AOX
@@ -977,6 +978,9 @@ product APPLE ISIGHT0x8502  iSight
 
 /* Araneus Information Systems products */
 product ARANEUS ALEA   0x0001  True Random Number Generator
+
+/* Arduino LLC products */
+product ARDUINO LEONARDO   0x8036  Arduino Lenoardo
 
 /* Arkmicro products */
 product ARKMICRO ARK3116   0x0232  ARK3116 Serial
Index: dev/usb/usbdevs.h
===
RCS file: /mnt/media/cvs/src/sys/dev/usb/usbdevs.h,v
retrieving revision 1.656
diff -u -p -u -r1.656 usbdevs.h
--- dev/usb/usbdevs.h   9 Jan 2015 20:42:40 -   1.656
+++ dev/usb/usbdevs.h   13 Feb 2015 19:36:44 -
@@ -1,4 +1,4 @@
-/* $OpenBSD: usbdevs.h,v 1.656 2015/01/09 20:42:40 kettenis Exp $  */
+/* $OpenBSD$   */
 
 /*
  * THIS FILE IS AUTOMATICALLY GENERATED.  DO NOT EDIT.
@@ -61,6 +61,7 @@
 #defineUSB_VENDOR_UNKNOWN2 0x0105  /* Unknown vendor */
 #defineUSB_VENDOR_EGALAX2  0x0123  /* eGalax */
 #defineUSB_VENDOR_UNKNOWN6 0x01e1  /* Unknown vendor */
+#defineUSB_VENDOR_ARDUINO  0x2341  /* Arduino LLC */
 #defineUSB_VENDOR_HUMAX0x02ad  /* HUMAX */
 #defineUSB_VENDOR_BWCT 0x03da  /* Bernd Walter Computer 
Technology */
 #defineUSB_VENDOR_AOX  0x03e8  /* AOX */
@@ -984,6 +985,9 @@
 
 /* Araneus Information Systems products */
 #defineUSB_PRODUCT_ARANEUS_ALEA0x0001  /* True Random 
Number Generator */
+
+/* Arduino LLC products */
+#defineUSB_PRODUCT_ARDUINO_LEONARDO0x8036  /* Arduino 
Lenoardo */
 
 /* Arkmicro products */
 #defineUSB_PRODUCT_ARKMICRO_ARK31160x0232  /* ARK3116 
Serial */
Index: dev/usb/usbdevs_data.h
===
RCS file: /mnt/media/cvs/src/sys/dev/usb/usbdevs_data.h,v
retrieving revision 1.650
diff -u -p -u -r1.650 usbdevs_data.h
--- dev/usb/usbdevs_data.h  9 Jan 2015 20:42:40 -   1.650
+++ dev/usb/usbdevs_data.h  13 Feb 2015 19:36:44 -
@@ -1,4 +1,4 @@
-/* $OpenBSD: usbdevs_data.h,v 1.650 2015/01/09 20:42:40 kettenis Exp $ 
*/
+/* $OpenBSD$   */
 
 /*
  * THIS FILE IS AUTOMATICALLY GENERATED.  DO NOT EDIT.
@@ -962,6 +962,10 @@ const struct usb_known_product usb_known
True Random Number Generator,
},
{
+   USB_VENDOR_ARDUINO, USB_PRODUCT_ARDUINO_LEONARDO,
+   Arduino Lenoardo,
+   },
+   {
USB_VENDOR_ARKMICRO, USB_PRODUCT_ARKMICRO_ARK3116,
ARK3116 Serial,
},
@@ -11248,6 +11252,10 @@ const struct usb_known_vendor usb_known_
{
USB_VENDOR_UNKNOWN6,
Unknown vendor,
+   },
+   {
+   USB_VENDOR_ARDUINO,
+   Arduino LLC,
},
{
USB_VENDOR_HUMAX,

Re: bgpctl: enlarge columns for 4-byte ASN display

[Gregor Best]

On Sun, Jul 27, 2014 at 10:06:12PM +0100, Stuart Henderson wrote:
 [...]
 Nice, I like that a lot. What do you think Claudio?
 [...]

Ping. Are there remaining issues with the patch?

-- 
Gregor Best

Re: bgpctl: enlarge columns for 4-byte ASN display

[Gregor Best]

Ping.

-- 
Gregor Best

Re: bgpctl: enlarge columns for 4-byte ASN display

[Gregor Best]

Ping? Are there remaining issues with the patch or should I leave
you guys alone until the release stress is over?

-- 
Gregor Best

Re: bgpctl: enlarge columns for 4-byte ASN display

[Gregor Best]

On Sun, Jul 27, 2014 at 11:15:41AM +0200, Claudio Jeker wrote:
 Not a big fan since this makes the bgpctl show output no longer fit 80
 chars and so will wrap lines on default terminals.
 [...]

Agreed, that's not good.

 While it is OK to
 increase the size it should be taken away from other fields in some whay.
 An option would be to drop the OutQ since that field has only limited
 value IMO.
 [...]

Right. I dare say on most links the OutQ column is 0 most of the
time anyway, or the link has problems that are visible in other
ways as well.

 [...]
 PS: you only need 11 chars and not 12 for AS-DOT notation
 [...]

Whoops, off by one.

The attached patch addresses the issues you pointed out by removing the
OutQ field and increasing the AS column width by 3 characters. The
output fits into 77 characters now.

-- 
Gregor Best
Index: bgpctl.c
===
RCS file: /mnt/media/cvs/src/usr.sbin/bgpctl/bgpctl.c,v
retrieving revision 1.174
diff -u -p -u -r1.174 bgpctl.c
--- bgpctl.c18 Mar 2014 13:47:14 -  1.174
+++ bgpctl.c27 Jul 2014 09:53:18 -
@@ -508,8 +508,8 @@ fmt_peer(const char *descr, const struct
 void
 show_summary_head(void)
 {
-   printf(%-20s %8s %10s %10s %5s %-8s %s\n, Neighbor, AS,
-   MsgRcvd, MsgSent, OutQ, Up/Down, State/PrfRcvd);
+   printf(%-20s %11s %10s %10s %-8s %s\n, Neighbor, AS,
+   MsgRcvd, MsgSent, Up/Down, State/PrfRcvd);
 }
 
 int
@@ -525,7 +525,7 @@ show_summary_msg(struct imsg *imsg, int 
p-conf.remote_masklen, nodescr);
if (strlen(s) = 20)
s[20] = 0;
-   printf(%-20s %8s %10llu %10llu %5u %-8s ,
+   printf(%-20s %11s %10llu %10llu %-8s ,
s, log_as(p-conf.remote_as),
p-stats.msg_rcvd_open + p-stats.msg_rcvd_notification +
p-stats.msg_rcvd_update + p-stats.msg_rcvd_keepalive +
@@ -533,7 +533,6 @@ show_summary_msg(struct imsg *imsg, int 
p-stats.msg_sent_open + p-stats.msg_sent_notification +
p-stats.msg_sent_update + p-stats.msg_sent_keepalive +
p-stats.msg_sent_rrefresh,
-   p-wbuf.queued,
fmt_timeframe(p-stats.last_updown));
if (p-state == STATE_ESTABLISHED) {
printf(%6u, p-stats.prefix_cnt);

Re: bgpctl: enlarge columns for 4-byte ASN display

[Gregor Best]

On Sun, Jul 27, 2014 at 03:36:06PM +0100, Stuart Henderson wrote:
 On 2014/07/27 11:15, Claudio Jeker wrote:
  Not a big fan since this makes the bgpctl show output no longer fit 80
  chars and so will wrap lines on default terminals. While it is OK to
  increase the size it should be taken away from other fields in some whay.
  An option would be to drop the OutQ since that field has only limited
  value IMO.
 
 oh, I would miss not having OutQ, it's totally useless when things are
 working correctly, but I have had a couple of situations (one with openbgp,
 one with *cough* bay BCN some time ago...) where this has been helpful.
 It gives quite a clear pointer to problems transmitting to that particular
 peer without having to look in netstat output and work out which peer is
 which (some physical layer problems, MTU problems etc).
 
 I think the most usable display would be to have neighbor and AS share
 a column, with priority to AS... i.e.
 
 somepeer12345  16419  89603 0 09:42:06100/8000
 somepeer-with-long-name  567816049401367282 0 13:39:28100/8000
 otherpeer16584484  16420  89606 0 1d00h58m Active
 otherpeer-with-long- 1658448516049401367282 0 13:40:17100/8000
 

The attached patch does just that. Maximum line length is now 80
characters (excluding the trailing newline), and the Neighbor and AS
columns now take a combined maximum of 29 characters, including the
blank separating peer name and AS. The result looks like this:

$ bgpctl show
Neighbor   ASMsgRcvdMsgSent  OutQ Up/Down  State/PrfRcvd
other-peer-with-l 16581.44851  0  0 0 NeverConnect
other-peer 1658.44841  0  0 0 NeverActive
some-peer-with-long-name 5678  0  0 0 NeverActive
some-peer   12345  0  0 0 NeverActive

Where before it was

$ bgpctl show
Neighbor   ASMsgRcvdMsgSent  OutQ Up/Down  State/PrfRcvd
other-peer-with-long 16581.44851  0  0 0 NeverConnect
other-peer   1658.44841  0  0 0 NeverActive
some-peer-with-long- 5678  0  0 0 NeverActive
some-peer   12345  0  0 0 NeverConnect


-- 
Gregor Best
Index: bgpctl.c
===
RCS file: /mnt/media/cvs/src/usr.sbin/bgpctl/bgpctl.c,v
retrieving revision 1.174
diff -u -p -u -r1.174 bgpctl.c
--- bgpctl.c18 Mar 2014 13:47:14 -  1.174
+++ bgpctl.c27 Jul 2014 15:20:59 -
@@ -517,16 +517,26 @@ show_summary_msg(struct imsg *imsg, int 
 {
struct peer *p;
char*s;
+   const char  *a;
+   char*pa;
+   size_t  alen;
 
switch (imsg-hdr.type) {
case IMSG_CTL_SHOW_NEIGHBOR:
p = imsg-data;
s = fmt_peer(p-conf.descr, p-conf.remote_addr,
p-conf.remote_masklen, nodescr);
-   if (strlen(s) = 20)
-   s[20] = 0;
-   printf(%-20s %8s %10llu %10llu %5u %-8s ,
-   s, log_as(p-conf.remote_as),
+
+   a = log_as(p-conf.remote_as);
+   alen = strlen(a);
+
+   if (asprintf(pa, %-28s, s) == -1)
+   err(1, NULL);
+   if (strlen(pa)  28 - alen)
+   pa[28 - alen] = 0;
+
+   printf(%s %s %10llu %10llu %5u %-8s ,
+   pa, a,
p-stats.msg_rcvd_open + p-stats.msg_rcvd_notification +
p-stats.msg_rcvd_update + p-stats.msg_rcvd_keepalive +
p-stats.msg_rcvd_rrefresh,
@@ -544,6 +554,7 @@ show_summary_msg(struct imsg *imsg, int 
else
printf(%s, statenames[p-state]);
printf(\n);
+   free(pa);
free(s);
break;
case IMSG_CTL_END:

bgpctl: enlarge columns for 4-byte ASN display

[Gregor Best]

Hi people,

I'm running OpenBGPD with a few peers that have large 4-byte AS numbers.
Displaying the table of peers with `bgpctl show` shows the stats just
fine, but the length of the AS number shifts the content of the
statistics confusingly far to the right, such as in the following
example:

  $ bgpctl show
  Neighbor   ASMsgRcvdMsgSent  OutQ Up/Down  
State/PrfRcvd
  peer 1   64734.12580316466 0 00:07:04364
  peer 2   64734.12578251293 0 00:40:06365
  peer 3  64828  17545  13466 0 3d17h35m325

The attached patch makes the 'AS' column 4 characters larger, with the
following result:

  $ bgpctl show
  Neighbor   ASMsgRcvdMsgSent  OutQ Up/Down  
State/PrfRcvd
  peer 164734.12580317468 0 00:07:51364
  peer 264734.12578252295 0 00:40:53365
  peer 3  64828  17547  13467 0 3d17h36m325

-- 
Gregor Best
Index: bgpctl.c
===
RCS file: /mnt/media/cvs/src/usr.sbin/bgpctl/bgpctl.c,v
retrieving revision 1.174
diff -u -p -u -r1.174 bgpctl.c
--- bgpctl.c18 Mar 2014 13:47:14 -  1.174
+++ bgpctl.c26 Jul 2014 13:49:17 -
@@ -508,7 +508,7 @@ fmt_peer(const char *descr, const struct
 void
 show_summary_head(void)
 {
-   printf(%-20s %8s %10s %10s %5s %-8s %s\n, Neighbor, AS,
+   printf(%-20s %12s %10s %10s %5s %-8s %s\n, Neighbor, AS,
MsgRcvd, MsgSent, OutQ, Up/Down, State/PrfRcvd);
 }
 
@@ -525,7 +525,7 @@ show_summary_msg(struct imsg *imsg, int 
p-conf.remote_masklen, nodescr);
if (strlen(s) = 20)
s[20] = 0;
-   printf(%-20s %8s %10llu %10llu %5u %-8s ,
+   printf(%-20s %12s %10llu %10llu %5u %-8s ,
s, log_as(p-conf.remote_as),
p-stats.msg_rcvd_open + p-stats.msg_rcvd_notification +
p-stats.msg_rcvd_update + p-stats.msg_rcvd_keepalive +

[Patch] Update the ifconfig(8) manpage

[Gregor Best]

Hi people,

the attached patch fixes two minor issues with the ifconfig(8) manpage.

The first part makes the operation of the `delete' option without an
argument a bit more obvious.

The second is a simple fix for the range of the `priority' option.

-- 
Gregor Best
Index: ifconfig.8
===
RCS file: /usr/src/cvs/src/sbin/ifconfig/ifconfig.8,v
retrieving revision 1.242
diff -u -p -u -r1.242 ifconfig.8
--- ifconfig.8  23 Jun 2014 18:55:29 -  1.242
+++ ifconfig.8  30 Jun 2014 17:28:08 -
@@ -185,6 +185,9 @@ Disable driver-dependent debugging code.
 .It Cm delete
 Remove the specified network address,
 including any netmask or destination address configured with this address.
+If no address is specified, the inet(4) address of the interface is assumed
+if it exists.
+If the interface has no inet(4) address, this option is a no-op.
 .It Cm description Ar value
 Specify a description of the interface.
 This can be used to label interfaces in situations where they may
@@ -403,7 +406,7 @@ Set the interface routing priority to
 This will influence the default routing priority of new static routes added to
 the kernel.
 .Ar n
-is in the range of 0 to 16 with smaller numbers being better.
+is in the range of 0 to 15 with smaller numbers being better.
 .It Cm rdomain Ar rdomainid
 Attach the interface to the routing domain with the specified
 .Ar rdomainid .

Patch: correct sysctl parameter in /sbin/route

[Gregor Best]

Hi people,

according to sysctl(3), AF_ROUTE is incorrect as a second level name for
the CTL_NET sysctl. The attached patch corrects this. Since PF_ROUTE is
defined to AF_ROUTE, there are no functional changes, but the style
stays consistent this way.

I have also noticed that sysctl(3) does not document the NET_RT_TABLE
fifth-level name for CTL_NET/PF_ROUTE. Is this intentional or should I
write another patch correcting that?

Sincerely,

Gregor Best
Index: route.c
===
RCS file: /usr/src/cvs/src/sbin/route/route.c,v
retrieving revision 1.167
diff -u -p -r1.167 route.c
--- route.c 8 May 2014 09:28:08 -   1.167
+++ route.c 17 Jun 2014 13:20:08 -
@@ -1678,7 +1678,7 @@ gettable(const char *s)
errx(1, invalid table id: %s, errstr);
 
mib[0] = CTL_NET;
-   mib[1] = AF_ROUTE;
+   mib[1] = PF_ROUTE;
mib[2] = 0;
mib[3] = 0;
mib[4] = NET_RT_TABLE;

Re: inteldrm/radeondrm suspend/resume diff

[Gregor Best]

On Thu, Mar 13, 2014 at 10:31:18AM +0100, Mark Kettenis wrote:
  [...]
  P.S. This seems to make hibernation (ZZZ) work with both inteldrm(4)
  and radeondrm(4) on my t400.
 
 Here's a slightly better diff that should eleminate a (largely
 theoretical) deadlock.  If you didn't test yet, try this version
 instead.
 [...]

Suspend (to RAM) and resume works fine here with

vga1 at pci0 dev 2 function 0 Intel GM965 Video rev 0x0c

Couldn't test hibernate yet because my system has root on a softraid
crypto device and the swap is outside the crypto area.

-- 
Gregor Best

Re: inteldrm/radeondrm suspend/resume diff

[Gregor Best]

On Thu, Mar 13, 2014 at 11:16:42AM +0100, Gregor Best wrote:
 [...]
 Couldn't test hibernate yet because my system has root on a softraid
 crypto device and the swap is outside the crypto area.
 [...]

David gave me a hint on how to hardwire my kernel for swap on sd0b.

With that, hibernate works slowly, but it works. The full hibernate +
resume cycle takes about one or two minutes, which I guess is fine.

I'm not sure whether hibernation working is a direct consequence of this
diff, but I think that's OK since the diff didn't break it either.

--
Gregor Best

Re: inteldrm suspend/resume regression (Was: Suspend/resume in Gnome)

[Gregor Best]

On Fri, Mar 07, 2014 at 05:00:43PM -0700, Theo de Raadt wrote:
 Any feedback?
 [...]

A current CVS checkout + cold=2 suspends fine and hangs on resume. By
hang, I mean the display stays black and the little halfmoon LED
continues blinking instead of turning off. I suppose that means the
kernel is busy printing a shitton of TSLEEP and takes a _very_ long
time to come up again.

Sadly, I don't have a serial console on my laptop, so I can't verify
that.

For the record, I have

vga1 at pci0 dev 2 function 0 Intel GM965 Video rev 0x0c

Is there anything I can do to further assist?

Thanks a lot by the way for the explanation of DVACT_RESUME vs. DVACT_WAKEUP.

-- 
Gregor Best

Re: top(1) interactive commands after SIGWINCH

[Gregor Best]

On Mon, Jan 13, 2014 at 05:04:28PM +, Stuart Henderson wrote:
 If anyone is interested in looking at a signal problem in top,
 here's a small but annoying bug..
 
 - run top in an xterm
 - resize the window
 - try to use an interactive command that takes an argument, e.g. s
 or g (doesn't happen with commands like S or H that work immediately)
 
 Often, pressing the command key just refreshes the screen, it takes
 multiple attempts for the command to take effect (sometimes just a
 couple, sometimes loads of attempts).
 [...]

The patch below seems to fix that for me. resizeterm() does a
putchar(KEY_RESIZE), part of which then gets interpreted as a command parameter
in rundisplay().

I'm not too sure on the cast to char, but since isascii() makes sure the
value passed is below 0177, i figured that would be okay.

-- 
Gregor Best

--- top.c.old   Mon Jan 13 20:49:28 2014
+++ top.c   Mon Jan 13 20:49:11 2014
@@ -39,6 +39,7 @@
 #include stdlib.h
 #include limits.h
 #include unistd.h
+#include ctype.h
 
 /* includes specific to top */
 #include display.h   /* interface to display package */
@@ -548,7 +549,7 @@
static char tempbuf[TEMPBUFSIZE];
sigset_t mask;
char ch, *iptr;
-   int change, i;
+   int change, i, cch;
struct pollfd pfd[1];
uid_t uid, huid;
static char command_chars[] = \f qh?en#sdkriIuSopCHg+P1;
@@ -612,14 +613,12 @@
 * now read it and convert to
 * command strchr
 */
-   while (1) {
-   len = read(STDIN_FILENO, ch, 1);
-   if (len == -1  errno == EINTR)
-   continue;
-   if (len == 0)
-   exit(1);
-   break;
-   }
+   cch = getch();
+   /* If the terminal is resized, curses does putchar(KEY_RESIZE) 
*/
+   if (!isascii(cch))
+   return 0;
+   ch = (char) cch;
+
if ((iptr = strchr(command_chars, ch)) == NULL) {
/* illegal command */
new_message(MT_standout,  Command not understood);

Re: top(1) interactive commands after SIGWINCH

[Gregor Best]

On Mon, Jan 13, 2014 at 12:41:19PM -0800, Philip Guenther wrote:
 [...]
 I think you meant ungetch(KEY_RESIZE),
 [...]

You're right.

 [...]
 seems to fix the problem in my testing.
 [...]

Works for me too.

-- 
Gregor Best

Hangs with Fuse

[Gregor Best]

Hi Sylvestre,

while playing around with sshfs, I noticed a peculiar behaviour. If I
mount it somewhere and run something like

find /mnt/fuse -type f -name '*.core'

on it, everything seems to work fine until the network connection is
interrupted. The system then hangs, with only the keyboard LEDs like the
caps lock indicator working (i.e. pressing caps lock turns the LED on
and off, but nothing else seems to work). The simplest way to reproduce
this is via something like the following:

sshfs user@somehost:/foo /mnt/fuse
while true; do find /mnt/fuse -type f; done 
while sleep 1; date; done

While that is running, the date is printed once every second. After
interrupting the network connection, for example by pulling the cable,
the date continues to get printed for a few second and then stops.

Is there a way to properly debug this? Are there typical spots in fuse
where adding one or two printfs() might yield further insight?

Thanks in advance,
Gregor Best

Re: Hangs with Fuse

[Gregor Best]

Hi Sylvestre,

 [...]
 Did you use the last snapshots ? If yes you need to recompile your
 libfuse and your kernel to get the last changes.
 [...]

thanks for the clue bat. Not upgrading libfuse was indeed the problem.

-- 
Gregor Best

Re: Stop printing excessive numbers of ACPI wakeup devices

[Gregor Best]

On Sat, Jun 01, 2013 at 06:35:24AM -0700, Mike Larkin wrote:
 [...]
   SIMPLEQ_FOREACH(wentry, sc-sc_wakedevs, q_next) {
 - printf( %.4s(S%d), wentry-q_node-name,
 - wentry-q_state);
 + if (wakeup_dev_ct  16)
 + printf( %.4s(S%d), wentry-q_node-name,
 + wentry-q_state);
 + else if (wakeup_dev_ct == 16)
 + printf( [...]);
 [...]

Would it make sense to break the loop once the [...] has been printed
instead of iterating over the queue without doing anything?

-- 
Gregor Best

Re: Stop printing excessive numbers of ACPI wakeup devices

[Gregor Best]

On Sat, Jun 01, 2013 at 06:57:21AM -0700, Mike Larkin wrote:
 [...]
 Sure, go ahead.
 [...]

Then I propose the following variant of the patch:

Index: dev/acpi/acpi.c
===
RCS file: /cvs/src/sys/dev/acpi/acpi.c,v
retrieving revision 1.245
diff -u -p -u -r1.245 acpi.c
--- dev/acpi/acpi.c 31 May 2013 22:43:43 -  1.245
+++ dev/acpi/acpi.c 1 Jun 2013 17:57:45 -
@@ -629,7 +629,7 @@ acpi_attach(struct device *parent, struc
struct acpi_rsdp *rsdp;
struct acpi_q *entry;
struct acpi_dsdt *p_dsdt;
-   int idx;
+   int idx, wakeup_dev_ct;
 #ifndef SMALL_KERNEL
struct acpi_wakeq *wentry;
struct device *dev;
@@ -796,8 +796,13 @@ acpi_attach(struct device *parent, struc
 
 #ifndef SMALL_KERNEL
/* Display wakeup devices and lowest S-state */
+   wakeup_dev_ct = 0;
printf(%s: wakeup devices, DEVNAME(sc));
SIMPLEQ_FOREACH(wentry, sc-sc_wakedevs, q_next) {
+   if (wakeup_dev_ct++ == 16) {
+   printf( [...]);
+   break;
+   }
printf( %.4s(S%d), wentry-q_node-name,
wentry-q_state);
}

Re: Somewhat important ACPI diff

[Gregor Best]

On Tue, May 21, 2013 at 10:15:02AM +0400, Vadim Zhukov wrote:
 [...]
 ThinkPad X201i, fine here for an half a day (running since the time you
 posted the diff). dmesg doesn't have any borked stuff, suspend/resume works
 fine, both for short and long periods.
 [...]

Likewise with my Thinkpad R61i.

-- 
Gregor Best

Re: Fuse (and sshfs) support for OpenBSD

[Gregor Best]

Hi,

 [...]
 I will spend the next days working on the NetBSD librefuse, I will try
 to get it working with my kernel code and will come back here when I
 have something that works.
 [...]

Are there any news on this? If you need a hand testing stuff and
tracking down bugs, I'd be very happy to help.

-- 
Gregor Best


pgps3nCas5Iq2.pgp
Description: PGP signature

Re: WPA Enterprise on OpenBSD

[Gregor Best]

On Mon, Jan 28, 2013 at 11:29:21AM +0100, Mark Kettenis wrote:
 [...]
 Looks like you and Gregor duplicated some effort.  Anyway, this looks
 fine with to me.  I'll submit my diff upstream later today.
 [...]

That's okay, my diff to the port only contains a version bump to 2.0 and
the WPA enterprise patch. I guess using Stuart's effort would be better.

-- 
Gregor Best

Re: WPA Enterprise on OpenBSD

[Gregor Best]

I just rolled an update to the wpa_supplicant port that updates it to
2.0 and includes your patch. I'm trying it out right now but it seems to
work flawlessly. Thanks a lot for the work :)

-- 
Gregor Best

Re: Scheduler improvements, take 1001, Patch 2/5

[Gregor Best]

On Sun, Oct 14, 2012 at 11:05:36AM +0200, David Coppa wrote:
 On Tue, Oct 9, 2012 at 6:21 PM, Gregor Best g...@ring0.de wrote:
  This patch simply halves the timeslice processes get until they are
  preempted. This patch is standalone and the rest of the patches does not
  depend on it, but I figured I'd throw it in anyway.
 
  --
  Gregor Best
 
 
 Didn't get this patch. Is it me or the patch is missing?
 

The patch was the message my mail was in reply to. There's no Patch 2/5
subject line because I forgot to change that after sending out Patch
1/5.

-- 
Gregor Best

Scheduler improvements, take 1001

[Gregor Best]

(By popular request as a new thread).

Hi people,

I've tried splitting my scheduler patch into smaller fragments, and
here's the result.

I changed a few things people mentioned over the last few days, such as
the following:

1) sys/proc.h now includes sys/tree.h, which should make libc builds
work again.
2) deadline generation now takes process priorities into account, as
suggested by ratchov@. The way it's done now, processes can use their
sleep priority as a way to lower their nice value for short periods of
time. I didn't notice any real changes, but I'd love to hear from people
with more demanding applications.
3) schedstate_percpu is private to the kernel now, as I couldn't find a
single occurrence of `struct schedstate_percpu` outside of /usr/src/sys
and it seemed cleaner not to expose kernel data to userland in such a
broad way.

The patches will follow as single emails.

-- 
Gregor Best

Re: Scheduler improvements, take 1001, Patch 1/5

[Gregor Best]

diff --git a/kern/sched_bsd.c b/kern/sched_bsd.c
index 172bb8f..c7121dc 100644
--- a/kern/sched_bsd.c
+++ b/kern/sched_bsd.c
@@ -77,12 +77,12 @@ scheduler_start(void)
 
timeout_set(schedcpu_to, schedcpu, schedcpu_to);
 
-   rrticks_init = hz / 10;
+   rrticks_init = hz / 20;
schedcpu(schedcpu_to);
 }
 
 /*
- * Force switch among equal priority processes every 100ms.
+ * Force switch among equal priority processes every 50ms.
  */
 void
 roundrobin(struct cpu_info *ci)
-- 
1.7.6

Re: Scheduler improvements, take 1001, Patch 1/5

[Gregor Best]

diff --git a/kern/kern_clock.c b/kern/kern_clock.c
index 843965b..f598afc 100644
--- a/kern/kern_clock.c
+++ b/kern/kern_clock.c
@@ -233,7 +233,7 @@ hardclock(struct clockframe *frame)
if (stathz == 0)
statclock(frame);
 
-   if (--ci-ci_schedstate.spc_rrticks = 0)
+   if (p  (--(p-p_rrticks) = 0))
roundrobin(ci);
 
/*
diff --git a/kern/kern_proc.c b/kern/kern_proc.c
index ad861c8..e0d5536 100644
--- a/kern/kern_proc.c
+++ b/kern/kern_proc.c
@@ -398,8 +398,6 @@ proc_printit(struct proc *p, const char *modif, int 
(*pr)(const char *, ...))
p-p_comm, p-p_pid, pst, p-p_flag, P_BITS);
(*pr)(pri=%u, usrpri=%u, nice=%d\n,
p-p_priority, p-p_usrpri, p-p_p-ps_nice);
-   (*pr)(forw=%p, list=%p,%p\n,
-   TAILQ_NEXT(p, p_runq), p-p_list.le_next, p-p_list.le_prev);
(*pr)(process=%p user=%p, vmspace=%p\n,
p-p_p, p-p_addr, p-p_vmspace);
(*pr)(estcpu=%u, cpticks=%d, pctcpu=%u.%u, swtime=%u\n,
diff --git a/kern/kern_sched.c b/kern/kern_sched.c
index 253226a..79eb28c 100644
--- a/kern/kern_sched.c
+++ b/kern/kern_sched.c
@@ -24,11 +24,22 @@
 #include sys/resourcevar.h
 #include sys/signalvar.h
 #include sys/mutex.h
+#include sys/tree.h
 
 #include uvm/uvm_extern.h
 
 #include sys/malloc.h
 
+static int
+sched_cmp_proc(struct proc *a, struct proc *b) {
+   if (a == b)
+   return 0;
+   if (timercmp((a-p_deadline), (b-p_deadline), ))
+   return -1;
+   return 1;
+}
+
+RB_GENERATE_STATIC(prochead, proc, p_runq, sched_cmp_proc);
 
 void sched_kthreads_create(void *);
 
@@ -79,10 +90,8 @@ void
 sched_init_cpu(struct cpu_info *ci)
 {
struct schedstate_percpu *spc = ci-ci_schedstate;
-   int i;
 
-   for (i = 0; i  SCHED_NQS; i++)
-   TAILQ_INIT(spc-spc_qs[i]);
+   RB_INIT(spc-spc_runq);
 
spc-spc_idleproc = NULL;
 
@@ -158,18 +167,19 @@ sched_idle(void *v)
 
cpuset_add(sched_idle_cpus, ci);
cpu_idle_enter();
-   while (spc-spc_whichqs == 0) {
+
+   while (curcpu_is_idle()) {
if (spc-spc_schedflags  SPCF_SHOULDHALT 
-   (spc-spc_schedflags  SPCF_HALTED) == 0) {
+(spc-spc_schedflags  SPCF_HALTED) == 0) {
cpuset_del(sched_idle_cpus, ci);
SCHED_LOCK(s);
-   atomic_setbits_int(spc-spc_schedflags,
-   spc-spc_whichqs ? 0 : SPCF_HALTED);
+   atomic_setbits_int(spc-spc_schedflags, 
SPCF_HALTED);
SCHED_UNLOCK(s);
wakeup(spc);
}
cpu_idle_cycle();
}
+
cpu_idle_leave();
cpuset_del(sched_idle_cpus, ci);
}
@@ -222,14 +232,13 @@ void
 setrunqueue(struct proc *p)
 {
struct schedstate_percpu *spc;
-   int queue = p-p_priority  2;
 
SCHED_ASSERT_LOCKED();
spc = p-p_cpu-ci_schedstate;
spc-spc_nrun++;
 
-   TAILQ_INSERT_TAIL(spc-spc_qs[queue], p, p_runq);
-   spc-spc_whichqs |= (1  queue);
+   KASSERT(!RB_FIND(prochead, spc-spc_runq, p));
+   RB_INSERT(prochead, spc-spc_runq, p);
cpuset_add(sched_queued_cpus, p-p_cpu);
 
if (cpuset_isset(sched_idle_cpus, p-p_cpu))
@@ -240,38 +249,29 @@ void
 remrunqueue(struct proc *p)
 {
struct schedstate_percpu *spc;
-   int queue = p-p_priority  2;
 
SCHED_ASSERT_LOCKED();
spc = p-p_cpu-ci_schedstate;
spc-spc_nrun--;
 
-   TAILQ_REMOVE(spc-spc_qs[queue], p, p_runq);
-   if (TAILQ_EMPTY(spc-spc_qs[queue])) {
-   spc-spc_whichqs = ~(1  queue);
-   if (spc-spc_whichqs == 0)
-   cpuset_del(sched_queued_cpus, p-p_cpu);
-   }
+   KASSERT(RB_REMOVE(prochead, spc-spc_runq, p));
+   if (RB_EMPTY(spc-spc_runq))
+   cpuset_del(sched_queued_cpus, p-p_cpu);
 }
 
 struct proc *
 sched_chooseproc(void)
 {
struct schedstate_percpu *spc = curcpu()-ci_schedstate;
-   struct proc *p;
-   int queue;
+   struct proc *p, *p_tmp = NULL;
 
SCHED_ASSERT_LOCKED();
 
if (spc-spc_schedflags  SPCF_SHOULDHALT) {
-   if (spc-spc_whichqs) {
-   for (queue = 0; queue  SCHED_NQS; queue++) {
-   TAILQ_FOREACH(p, spc-spc_qs[queue], p_runq) {
-   remrunqueue(p);
-   p-p_cpu = sched_choosecpu(p);
-   setrunqueue(p);
-   }
-   }
+   RB_FOREACH_SAFE(p, prochead, spc-spc_runq, p_tmp) {
+   remrunqueue(p);
+   

Re: Scheduler improvements, take 1001, Patch 5/5

[Gregor Best]

diff --git a/sys/sched.h b/sys/sched.h
index fb01f21..1784ee2 100644
--- a/sys/sched.h
+++ b/sys/sched.h
@@ -69,8 +69,10 @@
 #ifndef_SYS_SCHED_H_
 #define_SYS_SCHED_H_
 
+#ifdef _KERNEL
 #include sys/queue.h
 #include sys/tree.h
+#endif
 
 /*
  * Posix defines a sched.h which may want to include sys/sched.h
@@ -88,11 +90,9 @@
 #define CP_IDLE4
 #define CPUSTATES  5
 
-#defineSCHED_NQS   32  /* 32 run queues. */
-
+#ifdef _KERNEL
 /*
  * Per-CPU scheduler state.
- * XXX - expose to userland for now.
  */
 struct schedstate_percpu {
struct timeval spc_runtime; /* time curproc started running */
@@ -107,15 +107,13 @@ struct schedstate_percpu {
u_int spc_nrun; /* procs on the run queues */
fixpt_t spc_ldavg;  /* shortest load avg. for this cpu */
 
-   RB_HEAD(prochead, proc) spc_runq;
-
 #ifdef notyet
struct proc *spc_reaper;/* dead proc reaper */
 #endif
LIST_HEAD(,proc) spc_deadproc;
-};
 
-#ifdef _KERNEL
+   RB_HEAD(prochead, proc) spc_runq;
+};
 
 /* spc_flags */
 #define SPCF_SEENRR 0x0001  /* process has seen roundrobin() */
-- 
1.7.6

Re: Scheduler improvements, take 1001, Patch 4/5

[Gregor Best]

diff --git a/arch/amd64/include/cpu.h b/arch/amd64/include/cpu.h
index 12e48d6..99501a1 100644
--- a/arch/amd64/include/cpu.h
+++ b/arch/amd64/include/cpu.h
@@ -102,9 +102,11 @@ struct cpu_info {
u_int32_t   ci_cflushsz;
u_int64_t   ci_tsc_freq;
 
+#define ARCH_HAVE_CPU_TOPOLOGY
u_int32_t   ci_smt_id;
u_int32_t   ci_core_id;
u_int32_t   ci_pkg_id;
+
struct cpu_functions *ci_func;
void (*cpu_setup)(struct cpu_info *);
void (*ci_info)(struct cpu_info *);
diff --git a/kern/kern_sched.c b/kern/kern_sched.c
index 79eb28c..072ef38 100644
--- a/kern/kern_sched.c
+++ b/kern/kern_sched.c
@@ -496,6 +496,10 @@ int sched_cost_load = 1;
 int sched_cost_priority = 1;
 int sched_cost_runnable = 3;
 int sched_cost_resident = 1;
+#ifdef ARCH_HAVE_CPU_TOPOLOGY
+int sched_cost_diffcore = 2; /* cost for moving to a different core */
+int sched_cost_diffpkg = 3; /* cost for moving to a different package */
+#endif
 
 int
 sched_proc_to_cpu_cost(struct cpu_info *ci, struct proc *p)
@@ -536,6 +540,13 @@ sched_proc_to_cpu_cost(struct cpu_info *ci, struct proc *p)
cost -= l2resident * sched_cost_resident;
}
 
+#ifdef ARCH_HAVE_CPU_TOPOLOGY
+   if (p-p_cpu-ci_pkg_id != ci-ci_pkg_id)
+   cost *= sched_cost_diffpkg;
+   else if (p-p_cpu-ci_core_id != ci-ci_core_id)
+   cost *= sched_cost_diffcore;
+#endif
+
return (cost);
 }
 
-- 
1.7.6

Re: Scheduler improvements, take 1001, Patch 3/5

[Gregor Best]

diff --git a/arch/amd64/amd64/identcpu.c b/arch/amd64/amd64/identcpu.c
index c597bb0..982c2bb 100644
--- a/arch/amd64/amd64/identcpu.c
+++ b/arch/amd64/amd64/identcpu.c
@@ -210,6 +210,8 @@ void (*setperf_setup)(struct cpu_info *);
 
 void via_nano_setup(struct cpu_info *ci);
 
+void cpu_topology(struct cpu_info *ci);
+
 void
 via_nano_setup(struct cpu_info *ci)
 {
@@ -479,4 +481,123 @@ identifycpu(struct cpu_info *ci)
sensordev_install(ci-ci_sensordev);
 #endif
}
+
+   cpu_topology(ci);
+}
+
+/*
+ * Base 2 logarithm of an int. returns 0 for 0 (yeye, I know).
+ */
+static int
+log2(unsigned int i)
+{
+   int ret = 0;
+
+   while (i = 1)
+   ret++;
+
+   return (ret);
+}
+
+static int
+mask_width(u_int x)
+{
+   int bit;
+   int mask;
+   int powerof2;
+
+   powerof2 = ((x - 1)  x) == 0;
+   mask = (x  (1 - powerof2)) - 1;
+
+   /* fls */
+   if (mask == 0)
+   return (0);
+   for (bit = 1; mask != 1; bit++)
+   mask = (unsigned int)mask  1;
+
+   return (bit);
+}
+
+/*
+ * Build up cpu topology for given cpu, must run on the core itself.
+ */
+void
+cpu_topology(struct cpu_info *ci)
+{
+   u_int32_t eax, ebx, ecx, edx;
+   u_int32_t apicid, max_apicid, max_coreid;
+   u_int32_t smt_bits, core_bits, pkg_bits;
+   u_int32_t smt_mask, core_mask, pkg_mask;
+
+   /* We need at least apicid at CPUID 1 */
+   CPUID(0, eax, ebx, ecx, edx);
+   if (eax  1)
+   goto no_topology;
+
+   /* Initial apicid */
+   CPUID(1, eax, ebx, ecx, edx);
+   apicid = (ebx  24)  0xff;
+
+   if (strcmp(cpu_vendor, AuthenticAMD) == 0) {
+   /* We need at least apicid at CPUID 0x8008 */
+   CPUID(0x8000, eax, ebx, ecx, edx);
+   if (eax  0x8008)
+   goto no_topology;
+
+   CPUID(0x8008, eax, ebx, ecx, edx);
+   core_bits = (ecx  12)  0xf;
+   if (core_bits == 0)
+   goto no_topology;
+   /* So coreidsize 2 gives 3, 3 gives 7... */
+   core_mask = (1  core_bits) - 1;
+   /* Core id is the least significant considering mask */
+   ci-ci_core_id = apicid  core_mask;
+   /* Pkg id is the upper remaining bits */
+   ci-ci_pkg_id = apicid  ~core_mask;
+   ci-ci_pkg_id = core_bits;
+   } else if (strcmp(cpu_vendor, GenuineIntel) == 0) {
+   /* We only support leaf 1/4 detection */
+   CPUID(0, eax, ebx, ecx, edx);
+   if (eax  4)
+   goto no_topology;
+   /* Get max_apicid */
+   CPUID(1, eax, ebx, ecx, edx);
+   max_apicid = (ebx  16)  0xff;
+   /* Get max_coreid */
+   CPUID2(4, 0, eax, ebx, ecx, edx);
+   max_coreid = ((eax  26)  0x3f) + 1;
+   /* SMT */
+   smt_bits = mask_width(max_apicid / max_coreid);
+   smt_mask = (1  smt_bits) - 1;
+   /* Core */
+   core_bits = log2(max_coreid);
+   core_mask = (1  (core_bits + smt_bits)) - 1;
+   core_mask ^= smt_mask;
+   /* Pkg */
+   pkg_bits = core_bits + smt_bits;
+   pkg_mask = -1  core_bits;
+
+   ci-ci_smt_id = apicid  smt_mask;
+   ci-ci_core_id = (apicid  core_mask)  smt_bits;
+   ci-ci_pkg_id = (apicid  pkg_mask)  pkg_bits;
+   } else
+   goto no_topology;
+#ifdef DEBUG
+   printf(cpu%d: smt %u, core %u, pkg %u 
+   (apicid 0x%x, max_apicid 0x%x, max_coreid 0x%x, smt_bits 0x%x, 
smt_mask 0x%x, 
+   core_bits 0x%x, core_mask 0x%x, pkg_bits 0x%x, pkg_mask 
0x%x)\n,
+   ci-ci_cpuid, ci-ci_smt_id, ci-ci_core_id, ci-ci_pkg_id,
+   apicid, max_apicid, max_coreid, smt_bits, smt_mask, core_bits,
+   core_mask, pkg_bits, pkg_mask);
+#else
+   printf(cpu%d: smt %u, core %u, package %u\n, ci-ci_cpuid,
+   ci-ci_smt_id, ci-ci_core_id, ci-ci_pkg_id);
+
+#endif
+   return;
+   /* We can't map, so consider ci_core_id as ci_cpuid */
+no_topology:
+   ci-ci_smt_id  = 0;
+   ci-ci_core_id = ci-ci_cpuid;
+   ci-ci_pkg_id  = 0;
 }
diff --git a/arch/amd64/include/cpu.h b/arch/amd64/include/cpu.h
index 9ce437a..12e48d6 100644
--- a/arch/amd64/include/cpu.h
+++ b/arch/amd64/include/cpu.h
@@ -102,6 +102,9 @@ struct cpu_info {
u_int32_t   ci_cflushsz;
u_int64_t   ci_tsc_freq;
 
+   u_int32_t   ci_smt_id;
+   u_int32_t   ci_core_id;
+   u_int32_t   ci_pkg_id;
struct cpu_functions *ci_func;
void (*cpu_setup)(struct cpu_info *);
void (*ci_info)(struct cpu_info *);
diff --git a/arch/amd64/include/specialreg.h b/arch/amd64/include/specialreg.h
index 142fbbc..cab0985 100644
--- 

Re: Scheduler improvements, take 1001, Patch 2/5

[Gregor Best]

This patch simply halves the timeslice processes get until they are
preempted. This patch is standalone and the rest of the patches does not
depend on it, but I figured I'd throw it in anyway.

-- 
Gregor Best

Re: Scheduler improvements, take 1001, Patch 3/5

[Gregor Best]

This patch simply imports Christiano's code for detecting CPU topology,
as posted on tech@ a while (more than two months) ago. I took it
verbatim and didn't change anything yet.

-- 
Gregor Best

Re: Scheduler improvements, take 1001, Patch 4/5

[Gregor Best]

This patch uses the previous one to take CPU topology into account when
calculating the cost of moving a process between CPUs. This is only done
on amd64 at the moment, and the cost factors are guesses right now, but
it's a start.

-- 
Gregor Best

Re: Scheduler improvements, take 1001, Patch 5/5

[Gregor Best]

This patch moves struct schedstate_percpu to kernel land, which I think
is cleaner than exposing structures for scheduler state to userland,
especially since grepping for 'schedstate' in /usr/src yielded no
results outside of /usr/src/sys.

I have not seen negative impact from this, but I haven't yet run a full
userland build (it's running at the moment but the machine I'm building
on is a bit slower than my laptop).

-- 
Gregor Best

Re: Scheduler improvements

[Gregor Best]

On Mon, Oct 08, 2012 at 06:28:53PM +0200, Alexandre Ratchov wrote:
 [...]
 AFAIU, when a process waits for an event (with tsleep(9)), it
 provides the priority of the event it's waiting for (eg an audio
 interrupt). When the event occurs, the process is put in the
 runnable queue calculated from the priority. This way, interactive
 processes (i.e. waiting for external events) are prioritized during
 the event processing.
 [...]

I haven't noticed any degradation in performance with media-stuff (quite
the contrary, actually), but you have a point. I'll change the
deadline-calculation to also take the sleep priority into account.
Thanks for the explanation :)

--
Gregor Best

[demime 1.01d removed an attachment of type application/pgp-signature]

Re: Scheduler improvements

[Gregor Best]

On Mon, Oct 08, 2012 at 07:42:13PM +0200, Marc Espie wrote:
 [...]
 Your diff doesn't pass userland compiles.
 You're adding a dependency on tree.h in proc.h.
 
 In kernel land on amd64, that's okay, since machine/param.h will pull
 machine/cpu.h which pulls sys/sched.h which now pulls sys/tree.h,
 
 but it definitely doesn't fly in userland... my build crashed  burned
 in libc...
 
 assuming that's okay (not usually a kernel guy), you can go include 
 sys/tree.h directly in proc.h...
 [...]

I think wrapping all the things that need sys/tree.h in #ifdef KERNEL
should do the trick since they don't really make sense in userland
anyway.

 Please, please, please, don't vanish into the woods for the next 6 months.
 [...]

Since I now have way more space time on my hands than before, that
should not be an issue anymore, don't worry :)

 Try splitting up your diff and working them into pieces kernel hackers can
 work with...
 [...]

I will. Actually, the diff is a bunch of seperate git commits on my
machine, so that shouldn't be too hard to do.

-- 
Gregor Best

Re: Scheduler improvements

[Gregor Best]

 [...]
 I don't think changing the idle loop like this is ok.  You want to
 continue checking whether the runqueue is empty in between
 cpu_idle_enter() and cpu_idle_leave().
 [...]

Fair point. I'll change that :)

-- 
Gregor Best

Re: Scheduler improvements

[Gregor Best]

Hi Alexandre,

 [...]
 This change is unclear for me; AFAIU, it removes the mechanism
 which makes processes wake up with a priority depending on what  
 they are blocked on.
 [...]

Where do you see that? The code I removed/changed simply calulated the queue 
from
which to remove `p` and removed it from there (similar for insertion). That 
needed
to be changed to modify the RB tree used as a new runqueue.

 [...]
 For instance processes waking up from poll(2) or audio read/write
 won't be prioritized any longer. If so, this would hurt audio and
 other interactive processes but would improve cpu-intesive
 bloatware.
 [...]

They weren't prioritised with the old version of this code either.

 [...]
 this change is unrelated to the rest isn't it?
 [...]

Yes, it is. I changed it because 100ms time slices felt a bit too large,
but the rest of the patch will of course work without this bit.

Thanks for taking your time to look at this :)

-- 
Gregor Best

Re: Build cpu topology on amd64.

[Gregor Best]

On Sun, Jul 08, 2012 at 11:47:42AM +0200, Christiano F. Haesbaert wrote:
 [...]
 Do we want this ?
 [...]

I definitely want it, at least for my EEVDF experiments (maybe that patch is
the kick in the butt I needed to finally get that into
some sensible shape). So yeah, even if it won't get into the tree, I'll have a
use for it. Thanks :)

--
Gregor Best

[demime 1.01d removed an attachment of type application/pgp-signature]

Re: [PATCH] uvideo(4): fix kernel crash when enumerating non-existant formats

[Gregor Best]

On Mon, Jun 18, 2012 at 05:46:00PM +0200, Martin Pieuchot wrote:
 [...]
 Thanks. Out of curiosity with which application did you find this?
 [...]

I tried playing around with my new webcam and used an uninitialized fmtdesc
(mainly because I didn't understand the API then), which had a rather high
index
value (IIRC something around 2000). I was rather surprised when my little
test
program crashed my laptop repeatably :)

--
Gregor Best

[demime 1.01d removed an attachment of type application/pgp-signature]

[PATCH] uvideo(4): fix kernel crash when enumerating non-existant formats

[Gregor Best]

Hi people,

the attached patch fixes a little bug in uvideo(4), where using VIDIOC_ENUM_FMT
with fmtdesc-index strictly larger than the number of available video formats
crashes the kernel (I forgot the exact error message, but a crash is a crash and
the attached patch fixes it).

-- 
Gregor Best
Index: dev/usb/uvideo.c
===
RCS file: /cvs/src/sys/dev/usb/uvideo.c,v
retrieving revision 1.166
diff -u -p -r1.166 uvideo.c
--- dev/usb/uvideo.c28 Oct 2011 12:48:31 -  1.166
+++ dev/usb/uvideo.c16 Jun 2012 19:15:58 -
@@ -2775,7 +2775,7 @@ uvideo_enum_fmt(void *v, struct v4l2_fmt
/* type not supported */
return (EINVAL);
 
-   if (fmtdesc-index == sc-sc_fmtgrp_num) 
+   if (fmtdesc-index = sc-sc_fmtgrp_num)
/* no more formats left */
return (EINVAL);
idx = fmtdesc-index;

Re: wpi: add sensor for rfkill

[Gregor Best]

On Wed, May 23, 2012 at 09:12:20AM +0200, Tobias Ulmer wrote:
 [...]
 This a read-only sensor, it has no effect on misbehaving
 hardware as far as I can tell.
 [...]

That is right. If I recall correctly, the very reason for introducing real 
hardware killswitches was so that the OS could not
interfere with and override the kill switch in case the device needs to operate 
in RF-sensitive environments.

 [...]
 Gregor: try adding '-p' to cvs diff
 [...]

Thanks for the hint. An updated patch is attached.

-- 
Gregor Best
Index: dev/pci/if_wpi.c
===
RCS file: /cvs/src/sys/dev/pci/if_wpi.c,v
retrieving revision 1.110
diff -u -p -r1.110 if_wpi.c
--- dev/pci/if_wpi.c2 Jun 2011 18:36:53 -   1.110
+++ dev/pci/if_wpi.c23 May 2012 15:17:34 -
@@ -33,6 +33,9 @@
 #include sys/conf.h
 #include sys/device.h
 #include sys/workq.h
+#ifndef SMALL_KERNEL
+#include sys/sensors.h
+#endif
 
 #include machine/bus.h
 #include machine/endian.h
@@ -149,6 +152,9 @@ voidwpi_hw_stop(struct wpi_softc *);
 intwpi_init(struct ifnet *);
 void   wpi_stop(struct ifnet *, int);
 
+#ifndef SMALL_KERNEL
+void wpi_sensor_refresh(void *);
+#endif
 #ifdef WPI_DEBUG
 #define DPRINTF(x) do { if (wpi_debug  0) printf x; } while (0)
 #define DPRINTFN(n, x) do { if (wpi_debug = (n)) printf x; } while (0)
@@ -326,6 +332,19 @@ wpi_attach(struct device *parent, struct
wpi_radiotap_attach(sc);
 #endif
timeout_set(sc-calib_to, wpi_calib_timeout, sc);
+
+#ifndef SMALL_KERNEL
+   strlcpy(sc-sc_sensor.desc, Radio enabled, sizeof(Radio enabled));
+   sc-sc_sensor.type = SENSOR_INDICATOR;
+   sc-sc_sensor.status = SENSOR_S_UNSPEC;
+
+   strlcpy(sc-sc_sensordev.xname, sc-sc_dev.dv_xname, 
sizeof(sc-sc_sensordev.xname));
+   sensordev_install(sc-sc_sensordev);
+   sensor_attach(sc-sc_sensordev, sc-sc_sensor);
+   if (sc-sc_sensor_task == NULL)
+   sc-sc_sensor_task = sensor_task_register(sc, 
wpi_sensor_refresh, 10);
+#endif
+
return;
 
/* Free allocated memory if something failed during attachment. */
@@ -380,6 +399,12 @@ wpi_detach(struct device *self, int flag
ieee80211_ifdetach(ifp);
if_detach(ifp);
 
+#ifndef SMALL_KERNEL
+   sensor_detach(sc-sc_sensordev, sc-sc_sensor);
+   if (sc-sc_sensor_task != NULL)
+   sensor_task_unregister(sc-sc_sensor_task);
+   sensordev_deinstall(sc-sc_sensordev);
+#endif
return 0;
 }
 
@@ -489,6 +514,15 @@ wpi_prph_write_region_4(struct wpi_softc
for (; count  0; count--, data++, addr += 4)
wpi_prph_write(sc, addr, *data);
 }
+
+#ifndef SMALL_KERNEL
+void
+wpi_sensor_refresh(void *arg)
+{
+   struct wpi_softc *sc = arg;
+   sc-sc_sensor.value = wpi_prph_read(sc, WPI_APMG_RFKILL)  1;
+}
+#endif
 
 static __inline uint32_t
 wpi_mem_read(struct wpi_softc *sc, uint32_t addr)
Index: dev/pci/if_wpivar.h
===
RCS file: /cvs/src/sys/dev/pci/if_wpivar.h,v
retrieving revision 1.23
diff -u -p -r1.23 if_wpivar.h
--- dev/pci/if_wpivar.h 7 Sep 2010 16:21:45 -   1.23
+++ dev/pci/if_wpivar.h 23 May 2012 15:17:35 -
@@ -199,4 +199,7 @@ struct wpi_softc {
 #define sc_txtap   sc_txtapu.th
int sc_txtap_len;
 #endif
+   struct ksensor sc_sensor;
+   struct ksensordev sc_sensordev;
+   struct sensor_task *sc_sensor_task;
 };

Re: wpi: add sensor for rfkill

[Gregor Best]

On Thu, May 24, 2012 at 01:42:36AM +1000, Jonathan Gray wrote:
 [...]
 Could you explain why you have need of this sensor I don't
 quite see it?
 [...]

I usually manage the network connections on my laptop with an ifstated
configuration. If the wireless device's link went down, it could be for two
reasons: a) the connection dropped but I want it re-established as soon as
possible and b) the device was turned off with the RFkill switch. Before
adding
this sensor, there was no way to distinguish both without having a look at
the
machine and telling ifstated via e.g. some sort of temporary file that it
should
not attempt to bring up wpi0 because I _want_ it to be down instead of it
being
down because I went out of reach of the AP.

 [...]
 And it could perhaps be a better fit for ifmedia, adding a type for when the
radio is disabled.
 [...]

You mean like IEEE802 ... (radio off)? Or like a third state for the wifi
device, so It coudl be active, no network and no network (rfkill)?


--
Gregor Best

[demime 1.01d removed an attachment of type application/pgp-signature]