Re: ARP input path without KERNEL_LOCK

[mxb]

No regression here.

> On 4 dec. 2015, at 11:54, Martin Pieuchot  wrote:
> 
> Now that in_arpinput() only uses the routing table, if_get()/if_put()
> and carp_iamatch being already mpsafe we can kill the ARP input queue.
> 
> This moves the ARP input path processing from the softnet interrupt
> context (under KERNEL_LOCK) to the sofnettask (without KERNEL_LOCK).
> 
> ok?
> 
> Index: net/if_ethersubr.c
> ===
> RCS file: /cvs/src/sys/net/if_ethersubr.c,v
> retrieving revision 1.231
> diff -u -p -r1.231 if_ethersubr.c
> --- net/if_ethersubr.c2 Dec 2015 08:47:00 -   1.231
> +++ net/if_ethersubr.c4 Dec 2015 10:42:14 -
> @@ -372,14 +372,14 @@ decapsulate:
>   case ETHERTYPE_ARP:
>   if (ifp->if_flags & IFF_NOARP)
>   goto dropanyway;
> - inq = 
> - break;
> + arpinput(m);
> + return (1);
> 
>   case ETHERTYPE_REVARP:
>   if (ifp->if_flags & IFF_NOARP)
>   goto dropanyway;
> - inq = 
> - break;
> + revarpinput(m);
> + return (1);
> 
> #ifdef INET6
>   /*
> Index: net/netisr.c
> ===
> RCS file: /cvs/src/sys/net/netisr.c,v
> retrieving revision 1.8
> diff -u -p -r1.8 netisr.c
> --- net/netisr.c  3 Dec 2015 12:22:51 -   1.8
> +++ net/netisr.c  4 Dec 2015 10:43:35 -
> @@ -20,7 +20,6 @@
> 
> #include 
> 
> -#include "ether.h"
> #include "ppp.h"
> #include "bridge.h"
> #include "pppoe.h"
> @@ -39,10 +38,6 @@ netintr(void *unused) /* ARGSUSED */
>   while ((n = netisr) != 0) {
>   atomic_clearbits_int(, n);
> 
> -#if NETHER > 0
> - if (n & (1 << NETISR_ARP))
> - arpintr();
> -#endif
>   if (n & (1 << NETISR_IP))
>   ipintr();
> #ifdef INET6
> Index: net/netisr.h
> ===
> RCS file: /cvs/src/sys/net/netisr.h,v
> retrieving revision 1.43
> diff -u -p -r1.43 netisr.h
> --- net/netisr.h  3 Dec 2015 12:27:33 -   1.43
> +++ net/netisr.h  4 Dec 2015 10:44:01 -
> @@ -53,7 +53,6 @@
> #define   NETISR_IP   2   /* same as AF_INET */
> #define   NETISR_TX   3   /* for if_snd processing */
> #define   NETISR_PFSYNC   5   /* for pfsync "immediate" tx */
> -#define  NETISR_ARP  18  /* same as AF_LINK */
> #define   NETISR_IPV6 24  /* same as AF_INET6 */
> #define   NETISR_ISDN 26  /* same as AF_E164 */
> #define   NETISR_PPP  28  /* for PPP processing */
> @@ -64,7 +63,6 @@
> #ifdef _KERNEL
> extern intnetisr; /* scheduling bits for network */
> 
> -void arpintr(void);
> void  ipintr(void);
> void  ip6intr(void);
> void  pppintr(void);
> Index: netinet/if_ether.c
> ===
> RCS file: /cvs/src/sys/netinet/if_ether.c,v
> retrieving revision 1.197
> diff -u -p -r1.197 if_ether.c
> --- netinet/if_ether.c2 Dec 2015 22:02:18 -   1.197
> +++ netinet/if_ether.c4 Dec 2015 10:44:17 -
> @@ -88,14 +88,10 @@ void arptfree(struct rtentry *);
> void arptimer(void *);
> struct rtentry *arplookup(u_int32_t, int, int, u_int);
> void in_arpinput(struct mbuf *);
> -void revarpinput(struct mbuf *);
> void in_revarpinput(struct mbuf *);
> 
> LIST_HEAD(, llinfo_arp) arp_list;
> structpool arp_pool;  /* pool for llinfo_arp structures */
> -/* XXX hate magic numbers */
> -struct   niqueue arpintrq = NIQUEUE_INITIALIZER(50, NETISR_ARP);
> -struct   niqueue rarpintrq = NIQUEUE_INITIALIZER(50, NETISR_ARP);
> int   arp_inuse, arp_allocated;
> int   arp_maxtries = 5;
> int   arpinit_done;
> @@ -426,43 +422,40 @@ bad:
>  * then the protocol-specific routine is called.
>  */
> void
> -arpintr(void)
> +arpinput(struct mbuf *m)
> {
> - struct mbuf *m;
>   struct arphdr *ar;
>   int len;
> 
> - while ((m = niq_dequeue()) != NULL) {
> #ifdef DIAGNOSTIC
> - if ((m->m_flags & M_PKTHDR) == 0)
> - panic("arpintr");
> + if ((m->m_flags & M_PKTHDR) == 0)
> + panic("%s", __func__);
> #endif
> 
> - len = sizeof(struct arphdr);
> - if (m->m_len < len && (m = m_pullup(m, len)) == NULL)
> - continue;
> -
> - ar = mtod(m, struct arphdr *);
> - if (ntohs(ar->ar_hrd) != ARPHRD_ETHER) {
> - m_freem(m);
> - continue;
> - }
> + len = sizeof(struct arphdr);
> + if (m->m_len < len && (m = m_pullup(m, len)) == NULL)
> + return;
> 
> - len += 2 * (ar->ar_hln + ar->ar_pln);
> - if 

Re: [patch] Convert modulus to arc4random_uniform

[Theo Buehler]

I've now committed most of your diff, thanks once again.

o I asked for further review on the kernel parts
o I'm going to skip hack for now

Here's a patch for libc, based on the previous discussion.
I think this is easier to read and understand.  No binary change on
amd64.

ok?

Index: lib/libc/stdlib/rand.c
===
RCS file: /var/cvs/src/lib/libc/stdlib/rand.c,v
retrieving revision 1.15
diff -u -p -r1.15 rand.c
--- lib/libc/stdlib/rand.c  13 Sep 2015 08:31:47 -  1.15
+++ lib/libc/stdlib/rand.c  16 Dec 2015 08:02:41 -
@@ -37,7 +37,7 @@ int
 rand_r(u_int *seed)
 {
*seed = *seed * 1103515245 + 12345;
-   return (*seed % ((u_int)RAND_MAX + 1));
+   return (*seed & RAND_MAX);
 }
 DEF_WEAK(rand_r);
 
@@ -50,7 +50,7 @@ int
 rand(void)
 {
if (rand_deterministic == 0)
-   return (arc4random() % ((u_int)RAND_MAX + 1));
+   return (arc4random() & RAND_MAX);
return (rand_r());
 }
 

Re: rtdeletemsg & KASSERT

[Martin Pieuchot]

On 16/12/15(Wed) 23:57, Alexander Bluhm wrote:
> On Wed, Dec 16, 2015 at 09:46:26PM +0100, Alexander Bluhm wrote:
> > 10.188.70.17   fe:e1:ba:d0:d5:6d  UHLS   03 - 8 vio0
> 
> This is this route that crashed the machine when the arp entry expired.
> 
> When I move the rtref()/rtfree() calls into rtdeletemsg() it also
> protects the calls from arptfree().
> 
> > __assert() at __assert+0x25
> > rtfree() at rtfree+0x11e
> > rtable_delete() at rtable_delete+0x5d
> > rt_delete() at rt_delete+0x6e
> > rtdeletemsg() at rtdeletemsg+0x2d
> > arptfree() at arptfree+0x4f
> > arptimer() at arptimer+0x63
> 
> After rt_delete() has called rtable_delete(), the route is still
> used and should not be destroyed.

The diff below indeed corrects that, but I found another bug in it.  The
problem is that rtable_lookup() might return a non perfect match so we
would now end up deleting the RTF_CLONING route instead of failing.

The proper solution would be to always pass a mask (or prefix length) to
rtable_lookup().

> Index: net/route.c
> ===
> RCS file: /data/mirror/openbsd/cvs/src/sys/net/route.c,v
> retrieving revision 1.292
> diff -u -p -r1.292 route.c
> --- net/route.c   11 Dec 2015 08:58:23 -  1.292
> +++ net/route.c   16 Dec 2015 22:42:34 -
> @@ -159,8 +159,7 @@ struct sockaddr *rt_plentosa(sa_family_t
>  
>  struct   ifaddr *ifa_ifwithroute(int, struct sockaddr *, struct sockaddr 
> *,
>   u_int);
> -int  rtrequest_delete(struct rt_addrinfo *, u_int8_t, struct ifnet *,
> - struct rtentry **, u_int);
> +int  rt_delete(struct rtentry *, struct ifnet *, unsigned int);
>  
>  #ifdef DDB
>  void db_print_sa(struct sockaddr *);
> @@ -613,34 +612,22 @@ out:
>  }
>  
>  /*
> - * Delete a route and generate a message
> + * Delete a route and generate a message.  The caller must hold a reference
> + * on ``rt''.
>   */
>  int
> -rtdeletemsg(struct rtentry *rt, struct ifnet *ifp, u_int tableid)
> +rtdeletemsg(struct rtentry *rt, struct ifnet *ifp, unsigned int rtableid)
>  {
>   int error;
> - struct rt_addrinfo  info;
> - unsigned intifidx;
> - struct sockaddr_in6 sa_mask;
>  
>   KASSERT(rt->rt_ifidx == ifp->if_index);
>  
> - /*
> -  * Request the new route so that the entry is not actually
> -  * deleted.  That will allow the information being reported to
> -  * be accurate (and consistent with route_output()).
> -  */
> - bzero((caddr_t), sizeof(info));
> - info.rti_info[RTAX_DST] = rt_key(rt);
> - if (!ISSET(rt->rt_flags, RTF_HOST))
> - info.rti_info[RTAX_NETMASK] = rt_plen2mask(rt, _mask);
> - info.rti_info[RTAX_GATEWAY] = rt->rt_gateway;
> - info.rti_flags = rt->rt_flags;
> - ifidx = rt->rt_ifidx;
> - error = rtrequest_delete(, rt->rt_priority, ifp, , tableid);
> - rt_missmsg(RTM_DELETE, , info.rti_flags, ifidx, error, tableid);
> + rtref(rt);
> + error = rt_delete(rt, ifp, rtableid);
>   if (error == 0)
> - rtfree(rt);
> + rt_sendmsg(rt, RTM_DELETE, rtableid);
> + rtfree(rt);
> +
>   return (error);
>  }
>  
> @@ -671,10 +658,10 @@ rtflushclone1(struct rtentry *rt, void *
>* the routes are being purged by rt_if_remove().
>*/
>   if (ifp == NULL)
> - return 0;
> + return 0;
>  
>   if (ISSET(rt->rt_flags, RTF_CLONED) && rtequal(rt->rt_parent, parent))
> - rtdeletemsg(rt, ifp, id);
> + rtdeletemsg(rt, ifp, id);
>  
>   if_put(ifp);
>   return 0;
> @@ -818,60 +805,20 @@ rt_getifa(struct rt_addrinfo *info, u_in
>  }
>  
>  int
> -rtrequest_delete(struct rt_addrinfo *info, u_int8_t prio, struct ifnet *ifp,
> -struct rtentry **ret_nrt, u_int tableid)
> +rt_delete(struct rtentry *rt, struct ifnet *ifp, unsigned int rtableid)
>  {
> - struct rtentry  *rt;
> - int  error;
> -
> - splsoftassert(IPL_SOFTNET);
> -
> - if (!rtable_exists(tableid))
> - return (EAFNOSUPPORT);
> - rt = rtable_lookup(tableid, info->rti_info[RTAX_DST],
> - info->rti_info[RTAX_NETMASK], info->rti_info[RTAX_GATEWAY], prio);
> - if (rt == NULL)
> - return (ESRCH);
> -
> - /* Make sure that's the route the caller want to delete. */
> - if (ifp != NULL && ifp->if_index != rt->rt_ifidx) {
> - rtfree(rt);
> - return (ESRCH);
> - }
> + struct sockaddr_in6  sa_mask;
>  
> -#ifndef SMALL_KERNEL
> - /*
> -  * If we got multipath routes, we require users to specify
> -  * a matching gateway.
> -  */
> - if ((rt->rt_flags & RTF_MPATH) &&
> - info->rti_info[RTAX_GATEWAY] == NULL) {
> - rtfree(rt);
> - return (ESRCH);
> - }
> -#endif
> + KASSERT(ifp->if_index == rt->rt_ifidx);
>  
> - /*
> -  * Since RTP_LOCAL 

Re: Fix csqrt(3)

[Theo Buehler]

On Thu, Nov 26, 2015 at 09:02:17PM +0500, Alexandr Shadchin wrote:
> From http://en.cppreference.com/w/c/numeric/complex/csqrt :
> 
> csqrt(conj(z)) == conj(csqrt(z))
> 
> Before patch
>  csqrt(-4.0 + -0.0i) = 0.0 + 2.0j
> but should be
>  csqrt(-4.0 + -0.0i) = 0.0 - 2.0j

This, too, looks right to me.
FWIW: ok tb@

> 
> -- 
> Alexandr Shadchin
> 
> Index: lib/libm/src/s_csqrt.c
> ===
> RCS file: /cvs/src/lib/libm/src/s_csqrt.c,v
> retrieving revision 1.6
> diff -u -p -r1.6 s_csqrt.c
> --- lib/libm/src/s_csqrt.c3 Jul 2013 04:46:36 -   1.6
> +++ lib/libm/src/s_csqrt.c24 Nov 2015 08:45:25 -
> @@ -79,7 +79,7 @@ csqrt(double complex z)
>   r = fabs (x);
>   r = sqrt (r);
>   if (x < 0.0) {
> - w = 0.0 + r * I;
> + w = 0.0 + copysign(r, y) * I;
>   }
>   else {
>   w = r + y * I;
> Index: lib/libm/src/s_csqrtf.c
> ===
> RCS file: /cvs/src/lib/libm/src/s_csqrtf.c,v
> retrieving revision 1.2
> diff -u -p -r1.2 s_csqrtf.c
> --- lib/libm/src/s_csqrtf.c   18 Jul 2010 18:42:26 -  1.2
> +++ lib/libm/src/s_csqrtf.c   24 Nov 2015 08:45:25 -
> @@ -72,7 +72,7 @@ csqrtf(float complex z)
>  
>   if(y == 0.0f) {
>   if (x < 0.0f) {
> - w = 0.0f + sqrtf(-x) * I;
> + w = 0.0f + copysign(sqrtf(-x), y) * I;
>   return (w);
>   }
>   else if (x == 0.0f) {
> Index: lib/libm/src/s_csqrtl.c
> ===
> RCS file: /cvs/src/lib/libm/src/s_csqrtl.c,v
> retrieving revision 1.2
> diff -u -p -r1.2 s_csqrtl.c
> --- lib/libm/src/s_csqrtl.c   20 Jul 2011 19:28:33 -  1.2
> +++ lib/libm/src/s_csqrtl.c   24 Nov 2015 08:45:25 -
> @@ -72,7 +72,7 @@ csqrtl(long double complex z)
>  
>   if (y == 0.0L) {
>   if (x < 0.0L) {
> - w = 0.0L + sqrtl(-x) * I;
> + w = 0.0L + copysign(sqrtl(-x), y) * I;
>   return (w);
>   }
>   else {
> 

Re: Fix casin(3)

[Theo Buehler]

On Fri, Nov 27, 2015 at 03:14:52PM +0500, Alexandr Shadchin wrote:
> Fix wrong answer if the imaginary part is zero.
> NetBSD also turn off this piece of code.
> 
> See
> http://en.cppreference.com/w/c/numeric/complex/casin
> http://www.wolframalpha.com/input/?i=asin%28-2.0%29

Makes complete sense to me.
FWIW: ok tb@

> 
> -- 
> Alexandr Shadchin
> 
> Index: s_casin.c
> ===
> RCS file: /cvs/src/lib/libm/src/s_casin.c,v
> retrieving revision 1.6
> diff -u -p -r1.6 s_casin.c
> --- s_casin.c 3 Jul 2013 04:46:36 -   1.6
> +++ s_casin.c 27 Nov 2015 09:59:45 -
> @@ -63,6 +63,7 @@ casin(double complex z)
>   x = creal (z);
>   y = cimag (z);
>  
> +#if 0
>   if (y == 0.0) {
>   if (fabs(x) > 1.0) {
>   w = M_PI_2 + 0.0 * I;
> @@ -73,6 +74,7 @@ casin(double complex z)
>   }
>   return (w);
>   }
> +#endif
>  
>   /* Power series expansion */
>   /*
> Index: s_casinf.c
> ===
> RCS file: /cvs/src/lib/libm/src/s_casinf.c,v
> retrieving revision 1.3
> diff -u -p -r1.3 s_casinf.c
> --- s_casinf.c20 Jul 2011 19:28:33 -  1.3
> +++ s_casinf.c27 Nov 2015 09:59:45 -
> @@ -65,6 +65,7 @@ casinf(float complex z)
>   x = crealf(z);
>   y = cimagf(z);
>  
> +#if 0
>   if(y == 0.0f) {
>   if(fabsf(x) > 1.0f) {
>   w = (float)M_PI_2 + 0.0f * I;
> @@ -75,6 +76,7 @@ casinf(float complex z)
>   }
>   return (w);
>   }
> +#endif
>  
>   /* Power series expansion */
>   /*
> Index: s_casinl.c
> ===
> RCS file: /cvs/src/lib/libm/src/s_casinl.c,v
> retrieving revision 1.3
> diff -u -p -r1.3 s_casinl.c
> --- s_casinl.c20 Jul 2011 21:02:51 -  1.3
> +++ s_casinl.c27 Nov 2015 09:59:45 -
> @@ -71,6 +71,7 @@ casinl(long double complex z)
>   x = creall(z);
>   y = cimagl(z);
>  
> +#if 0
>   if (y == 0.0L) {
>   if (fabsl(x) > 1.0L) {
>   w = PIO2L + 0.0L * I;
> @@ -81,6 +82,7 @@ casinl(long double complex z)
>   }
>   return (w);
>   }
> +#endif
>  
>   /* Power series expansion */
>   b = cabsl(z);
> 

Re: initial 11n support for iwn - defunc: Intel WiFi Link 5300 rev 0x00

[Stuart Henderson]

On 2015/12/17 13:22, Stefan Sperling wrote:
> On Thu, Dec 17, 2015 at 12:40:48PM +0100, Marcus MERIGHI wrote:
> > iwn0: sending auth to 80:1f:02:c1:fd:86 on channel 5 mode 11b
> > iwn0: sending assoc_req to 80:1f:02:c1:fd:86 on channel 5 mode 11b
> > iwn0: received auth from 80:1f:02:c1:fd:86 rssi -54 mode 11b
> > iwn0: association failed (status 18) for 80:1f:02:c1:fd:86
> 
>   IEEE80211_STATUS_BASIC_RATE = 18,
> 
> This could mean we're sending a bad basic rate element in
> association requests while in 11n mode. I'll investigate.
> 
> Is your AP restricting clients to a particular mode, like 11g-only?
> Perhaps it means your AP requires clients to support MCS higher
> than MCS 7, which we don't support yet?
> 
> Can you somehow change AP settings in this regard?
> 

It seems that some APs get upset if you send rates that are not in their
advertised list.

https://supportforums.cisco.com/document/141136/80211-association-status-80211-deauth-reason-codes
says "Will happen if the rates in the assoc request are not in the
BasicRateSet in the beacon" for this.

We don't do much decode of assoc requests in tcpdump at the moment.
Marcus, it might be useful to get a pcap file (tcpdump -s1500 -iiwn0
-yIEEE802_11_RADIO -w /tmp/iwn.pcap) from while it's trying to
associate - if you send it to me off list (and probably best to
cc stsp) I can take a look and see if I spot anything.

Re: [patch] kern/exec_script: return error when the shell name is not specified

[Ted Unangst]

Maxim Pugachev wrote:
> Ping?
> 
> On Sun, Dec 13, 2015 at 12:28 AM, Maxim Pugachev  
> wrote:
> > Hi,
> >
> > In a case when the shell name is not specified (i.e. just "#!" without
> > a path), don't run the heavy logic that checks shell, simply return
> > ENOENT.
> >
> > Also, as a tiny improvement: avoid a loop when calculating shell's args 
> > length.

Not forgotten. Just not a very pretty file to look at. :)

Re: Allocation type in kern/exec_elf.c

[Ted Unangst]

Maxim Pugachev wrote:
> Hey all,
> 
> I'm wondering, why an allocation type in kern/exec_elf.c is equal to
> M_TEMP? For instance, kern/exec_script.c and kern/kern_exec.c allocate
> memory as M_EXEC, and it looks more reasonable to me.
> 
> What's the reason for this?

I think the reason is M_TEMP is for any data that is short lived (will be
freed in the same function) and other types like M_EXEC are for data that
lasts longer. But this policy is not consistent, so there's lots of
counterexamples.

Re: [patch] malloc: size that was passed to free() should land into the same bucket

[Ted Unangst]

Maxim Pugachev wrote:
> On Sun, Dec 13, 2015 at 10:38 PM, Ted Unangst  wrote:
> > Maxim Pugachev wrote:
> >> Currently two checks in free() function confirm the correctness of
> >> freedsize argument. I think that it's better to check that provided
> >> freedsize fall into the same bucket that was recorded in kmemusage
> >> struct: it covers both cases.
> >
> > I don't know. This doesn't seem clearer to me. An error message with
> > bucket numbers isn't any more helpful.
> 
> Ted, thank you for your comments!
> 
> I can compare the buckets to generate a clearer message, but you're
> right, it'll look a bit complicated.
> 
> I've read this code again and I think there is an error in a second
> check ("size too small"). For example, if freedsize = 2048 and size =
> 4096, then panic will not fire because "freedsize < size / 2" is
> false. But I guess it should, because BUCKETINDX(2048) == 11, but
> BUCKETINDX(4096) == 12.
> 
> What do you think?

I remember thinking about this before. I forgot what I thought though.

Is there some case where the correct size is 1/2? I can't think of any.

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

[Frank Groeneveld]

On 12/16/15 15:35, Stefan Sperling wrote:

This diff adds 11n MCS 0-7 with A-MPDU and A-MSDU Rx to the iwn(4) driver.

It also tweaks replay detection for CCMP encrypted frames, which needed
tweaking for A-MPDU anyway (see comments in code). Even in non-11n modes
this driver was discarding some retransmitted frames for no good reason.

This driver supports a very wide range of hardware so please test this
with as many iwn(4) adapters as possible. If we don't get enough tests
this change may not be able to make the 5.9 release.

Works for me on:
iwn0 at pci3 dev 0 function 0 "Intel Centrino Advanced-N 6200" rev 0x35: msi, 
MIMO 2T2R, MoW

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

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


Thanks for you work on this! I've tested it on my laptop and it gives me 
firmware errors. I've attached dmesg from both a the working and the 
patched, non-working kernels. Let me know if you need any other information.


Frank
OpenBSD 5.8-current (GENERIC.MP) #1737: Thu Dec 10 23:29:07 MST 2015
dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
real mem = 4157837312 (3965MB)
avail mem = 4027703296 (3841MB)
mpath0 at root
scsibus0 at mpath0: 256 targets
mainbus0 at root
bios0 at mainbus0: SMBIOS rev. 2.7 @ 0xeba60 (23 entries)
bios0: vendor American Megatrends Inc. version "UX31A.219" date 06/14/2013
bios0: ASUSTeK COMPUTER INC. UX31A
acpi0 at bios0: rev 2
acpi0: sleep states S0 S3 S4 S5
acpi0: tables DSDT FACP APIC FPDT ECDT MCFG SSDT SSDT SSDT SSDT HPET SSDT SSDT 
SSDT SSDT DMAR MSDM
acpi0: wakeup devices P0P1(S4) PEG0(S4) PEG1(S4) PEG2(S4) PEG3(S4) USB1(S3) 
USB2(S3) USB3(S3) USB4(S3) EHC2(S3) USB5(S3) USB6(S3) USB7(S3) HDEF(S4) 
RP01(S4) RP02(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) i7-3517U CPU @ 1.90GHz, 1796.22 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,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,POPCNT,DEADLINE,AES,XSAVE,OSXSAVE,AVX,F16C,RDRAND,NXE,LONG,LAHF,PERF,ITSC,FSGSBASE,SMEP,ERMS,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 99MHz
cpu0: mwait min=64, max=64, C-substates=0.2.1.1.2, IBE
cpu1 at mainbus0: apid 2 (application processor)
cpu1: Intel(R) Core(TM) i7-3517U CPU @ 1.90GHz, 1795.92 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,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,POPCNT,DEADLINE,AES,XSAVE,OSXSAVE,AVX,F16C,RDRAND,NXE,LONG,LAHF,PERF,ITSC,FSGSBASE,SMEP,ERMS,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) i7-3517U CPU @ 1.90GHz, 1795.92 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,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,POPCNT,DEADLINE,AES,XSAVE,OSXSAVE,AVX,F16C,RDRAND,NXE,LONG,LAHF,PERF,ITSC,FSGSBASE,SMEP,ERMS,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) i7-3517U CPU @ 1.90GHz, 1795.92 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,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,POPCNT,DEADLINE,AES,XSAVE,OSXSAVE,AVX,F16C,RDRAND,NXE,LONG,LAHF,PERF,ITSC,FSGSBASE,SMEP,ERMS,SENSOR,ARAT
cpu3: 256KB 64b/line 8-way L2 cache
cpu3: smt 1, core 1, package 0
ioapic0 at mainbus0: apid 2 pa 0xfec0, version 20, 24 pins
acpiec0 at acpi0
acpimcfg0 at acpi0 addr 0xf800, bus 0-63
acpihpet0 at acpi0: 14318179 Hz
acpiprt0 at acpi0: bus 0 (PCI0)
acpiprt1 at acpi0: bus -1 (P0P1)
acpiprt2 at acpi0: bus -1 (PEG0)
acpiprt3 at acpi0: bus -1 (PEG1)
acpiprt4 at acpi0: bus -1 (PEG2)
acpiprt5 at acpi0: bus -1 (PEG3)
acpiprt6 at acpi0: bus 1 (RP01)
acpiprt7 at acpi0: bus 2 (RP02)
acpiprt8 at acpi0: bus -1 (RP03)
acpiprt9 at acpi0: bus -1 (RP04)
acpiprt10 at acpi0: bus -1 (RP05)
acpiprt11 at acpi0: bus -1 (RP06)
acpiprt12 at acpi0: bus -1 (RP07)
acpiprt13 at acpi0: bus -1 (RP08)
acpicpu0 at acpi0: C3(200@87 mwait.1@0x30), C2(500@59 mwait.1@0x10), C1(1000@1 
mwait.1), PSS
acpicpu1 at acpi0: C3(200@87 mwait.1@0x30), C2(500@59 mwait.1@0x10), C1(1000@1 
mwait.1), PSS
acpicpu2 at acpi0: C3(200@87 mwait.1@0x30), C2(500@59 mwait.1@0x10), C1(1000@1 
mwait.1), PSS
acpicpu3 at acpi0: C3(200@87 

scan regression fixes

[Stefan Sperling]

This should fix the infinite scanning loops people have been
reporting with 11n-enabled iwn(4), as well as the issue where
clients associating to 11g APs end up in 11b mode and can't
use OFDM data rates.

ok?

Index: ieee80211.c
===
RCS file: /cvs/src/sys/net80211/ieee80211.c,v
retrieving revision 1.52
diff -u -p -r1.52 ieee80211.c
--- ieee80211.c 16 Dec 2015 12:52:03 -  1.52
+++ ieee80211.c 17 Dec 2015 18:35:27 -
@@ -874,6 +874,14 @@ ieee80211_next_mode(struct ifnet *ifp)
/* Wrap around and ignore turbo mode */
if (ic->ic_curmode == IEEE80211_MODE_TURBO)
continue;
+#ifndef IEEE80211_NO_HT
+   /* 
+* Skip 11n mode while scanning. Its set of channels is
+* the superset of all channels supported by other modes.
+*/
+   if (ic->ic_curmode == IEEE80211_MODE_11N)
+   continue;
+#endif
if (ic->ic_curmode >= IEEE80211_MODE_MAX) {
ic->ic_curmode = IEEE80211_MODE_AUTO;
break;
@@ -893,6 +901,11 @@ ieee80211_next_mode(struct ifnet *ifp)
  * caller can select a rate set.  This is problematic and the
  * work here assumes how things work elsewhere in this code.
  *
+ * Because the result of this function is ultimately used to select
+ * a rate from the rate set of the returned mode, it must not return
+ * IEEE802_MODE_11N. This funcion may be called in 11n mode to find
+ * a non-MCS rate to use for sending frames to non-HT STAs.
+ *
  * XXX never returns turbo modes -dcy
  */
 enum ieee80211_phymode
@@ -911,11 +924,6 @@ ieee80211_chan2mode(struct ieee80211com 
 * characteristics.  We assume that turbo-only channels
 * are not considered when the channel set is constructed.
 */
-#ifndef IEEE80211_NO_HT
-   if (IEEE80211_IS_CHAN_N(chan))
-   return IEEE80211_MODE_11N;
-   else
-#endif
if (IEEE80211_IS_CHAN_T(chan))
return IEEE80211_MODE_TURBO;
else if (IEEE80211_IS_CHAN_5GHZ(chan))
Index: ieee80211_input.c
===
RCS file: /cvs/src/sys/net80211/ieee80211_input.c,v
retrieving revision 1.145
diff -u -p -r1.145 ieee80211_input.c
--- ieee80211_input.c   12 Dec 2015 13:56:10 -  1.145
+++ ieee80211_input.c   17 Dec 2015 18:42:06 -
@@ -2257,16 +2257,8 @@ ieee80211_recv_assoc_resp(struct ieee802
 
/* Hop out of 11n mode after associating to a non-HT AP. */
if (ic->ic_curmode == IEEE80211_MODE_11N &&
-   (ni->ni_flags & IEEE80211_NODE_HT) == 0) {
-   if (IEEE80211_IS_CHAN_T(ni->ni_chan))
-   ieee80211_setmode(ic, IEEE80211_MODE_TURBO);
-   else if (IEEE80211_IS_CHAN_A(ni->ni_chan))
-   ieee80211_setmode(ic, IEEE80211_MODE_11A);
-   else if (IEEE80211_IS_CHAN_G(ni->ni_chan))
-   ieee80211_setmode(ic, IEEE80211_MODE_11G);
-   else
-   ieee80211_setmode(ic, IEEE80211_MODE_11B);
-   }
+   (ni->ni_flags & IEEE80211_NODE_HT) == 0)
+   ieee80211_setmode(ic, ieee80211_chan2mode(ic, ni->ni_chan));
 #endif
/*
 * Configure state now that we are associated.

Re: [patch] malloc: size that was passed to free() should land into the same bucket

[Maxim Pugachev]

On Thu, Dec 17, 2015 at 9:01 PM, Ted Unangst  wrote:
> Maxim Pugachev wrote:
>> On Sun, Dec 13, 2015 at 10:38 PM, Ted Unangst  wrote:
>> > Maxim Pugachev wrote:
>> >> Currently two checks in free() function confirm the correctness of
>> >> freedsize argument. I think that it's better to check that provided
>> >> freedsize fall into the same bucket that was recorded in kmemusage
>> >> struct: it covers both cases.
>> >
>> > I don't know. This doesn't seem clearer to me. An error message with
>> > bucket numbers isn't any more helpful.
>>
>> Ted, thank you for your comments!
>>
>> I can compare the buckets to generate a clearer message, but you're
>> right, it'll look a bit complicated.
>>
>> I've read this code again and I think there is an error in a second
>> check ("size too small"). For example, if freedsize = 2048 and size =
>> 4096, then panic will not fire because "freedsize < size / 2" is
>> false. But I guess it should, because BUCKETINDX(2048) == 11, but
>> BUCKETINDX(4096) == 12.
>>
>> What do you think?
>
> I remember thinking about this before. I forgot what I thought though.
>
> Is there some case where the correct size is 1/2? I can't think of any.

I'm sorry, but I think I don't understand your question.

Re: Allocation type in kern/exec_elf.c

[Maxim Pugachev]

On Thu, Dec 17, 2015 at 8:21 PM, Ted Unangst  wrote:
> Maxim Pugachev wrote:
>> Hey all,
>>
>> I'm wondering, why an allocation type in kern/exec_elf.c is equal to
>> M_TEMP? For instance, kern/exec_script.c and kern/kern_exec.c allocate
>> memory as M_EXEC, and it looks more reasonable to me.
>>
>> What's the reason for this?
>
> I think the reason is M_TEMP is for any data that is short lived (will be
> freed in the same function) and other types like M_EXEC are for data that
> lasts longer. But this policy is not consistent, so there's lots of
> counterexamples.

Now it's clear, thank you!

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

[Glenn Faustino]

Thanks Stefan!

Works on my Thinkpad X220.

iwn0 at pci2 dev 0 function 0 "Intel WiFi Link 1000" rev 0x00: msi, MIMO
1T2R, BGS, address 74:e5:0b:c6:3c:c8



dmesg:

OpenBSD 5.8-current (GENERIC.MP) #1752: Thu Dec 17 01:17:05 MST 2015
dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
RTC BIOS diagnostic error 80
real mem = 8451125248 (8059MB)
avail mem = 8190865408 (7811MB)
mpath0 at root
scsibus0 at mpath0: 256 targets
mainbus0 at root
bios0 at mainbus0: SMBIOS rev. 2.6 @ 0xdae9c000 (64 entries)
bios0: vendor LENOVO version "8DET69WW (1.39 )" date 07/18/2013
bios0: LENOVO 4291G36
acpi0 at bios0: rev 2
acpi0: sleep states S0 S3 S4 S5
acpi0: tables DSDT FACP SLIC SSDT SSDT SSDT HPET APIC MCFG ECDT ASF! TCPA
SSDT SSDT DMAR UEFI UEFI UEFI
acpi0: wakeup devices LID_(S3) SLPB(S3) IGBE(S4) EXP4(S4) EXP7(S4) EHC1(S3)
EHC2(S3) HDEF(S4)
acpitimer0 at acpi0: 3579545 Hz, 24 bits
acpihpet0 at acpi0: 14318179 Hz
acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
cpu0 at mainbus0: apid 0 (boot processor)
cpu0: Intel(R) Core(TM) i5-2520M CPU @ 2.50GHz, 2492.24 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,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,POPCNT,DEADLINE,AES,XSAVE,AVX,NXE,LONG,LAHF,PERF,ITSC,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 99MHz
cpu0: mwait min=64, max=64, C-substates=0.2.1.1.2, IBE
cpu1 at mainbus0: apid 1 (application processor)
cpu1: Intel(R) Core(TM) i5-2520M CPU @ 2.50GHz, 2491.92 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,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,POPCNT,DEADLINE,AES,XSAVE,AVX,NXE,LONG,LAHF,PERF,ITSC,SENSOR,ARAT
cpu1: 256KB 64b/line 8-way L2 cache
cpu1: smt 1, core 0, package 0
cpu2 at mainbus0: apid 2 (application processor)
cpu2: Intel(R) Core(TM) i5-2520M CPU @ 2.50GHz, 2491.92 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,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,POPCNT,DEADLINE,AES,XSAVE,AVX,NXE,LONG,LAHF,PERF,ITSC,SENSOR,ARAT
cpu2: 256KB 64b/line 8-way L2 cache
cpu2: smt 0, core 1, package 0
cpu3 at mainbus0: apid 3 (application processor)
cpu3: Intel(R) Core(TM) i5-2520M CPU @ 2.50GHz, 2491.92 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,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,POPCNT,DEADLINE,AES,XSAVE,AVX,NXE,LONG,LAHF,PERF,ITSC,SENSOR,ARAT
cpu3: 256KB 64b/line 8-way L2 cache
cpu3: smt 1, core 1, package 0
ioapic0 at mainbus0: apid 2 pa 0xfec0, version 20, 24 pins
acpimcfg0 at acpi0 addr 0xf800, bus 0-63
acpiec0 at acpi0
acpiprt0 at acpi0: bus 0 (PCI0)
acpiprt1 at acpi0: bus -1 (PEG_)
acpiprt2 at acpi0: bus 2 (EXP1)
acpiprt3 at acpi0: bus 3 (EXP2)
acpiprt4 at acpi0: bus 5 (EXP4)
acpiprt5 at acpi0: bus 13 (EXP5)
acpiprt6 at acpi0: bus -1 (EXP7)
acpicpu0 at acpi0: C3(350@104 io@0x415), C1(1000@1 halt), PSS
acpicpu1 at acpi0: C3(350@104 io@0x415), C1(1000@1 halt), PSS
acpicpu2 at acpi0: C3(350@104 io@0x415), C1(1000@1 halt), PSS
acpicpu3 at acpi0: C3(350@104 io@0x415), C1(1000@1 halt), PSS
acpipwrres0 at acpi0: PUBS, resource for EHC1, EHC2
acpitz0 at acpi0: critical temperature is 99 degC
acpibtn0 at acpi0: LID_
acpibtn1 at acpi0: SLPB
acpibat0 at acpi0: BAT0 model "42T4940" serial  4448 type LION oem "SANYO"
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 2492 MHz: speeds: 2501, 2500, 2200, 2000, 1800,
1600, 1400, 1200, 1000, 800 MHz
pci0 at mainbus0 bus 0
pchb0 at pci0 dev 0 function 0 "Intel Core 2G Host" rev 0x09
inteldrm0 at pci0 dev 2 function 0 "Intel HD Graphics 3000" rev 0x09
drm0 at inteldrm0
inteldrm0: msi
inteldrm0: 1366x768
wsdisplay0 at inteldrm0 mux 1: console (std, vt100 emulation)
wsdisplay0: screen 1-5 added (std, vt100 emulation)
"Intel 6 Series MEI" rev 0x04 at pci0 dev 22 function 0 not configured
em0 at pci0 dev 25 function 0 "Intel 82579LM" rev 0x04: msi, address
f0:de:f1:d1:94:39
ehci0 at pci0 dev 26 function 0 "Intel 6 Series USB" rev 0x04: apic 2 int 16
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 6 Series HD Audio" rev 0x04: msi
azalia0: codecs: Conexant CX20590, Intel/0x2805, using Conexant CX20590
audio0 at azalia0
ppb0 at pci0 dev 28 function 0 "Intel 6 Series PCIE" rev 0xb4: msi
pci1 at ppb0 bus 2
ppb1 at pci0 dev 28 function 1 "Intel 6 Series PCIE" rev 0xb4: 

Re: Thinkpad display brightness control

[Mark Kettenis]

> From: Christian Weisgerber 
> Date: Thu, 17 Dec 2015 11:50:53 + (UTC)
> 
> On 2015-12-16, Mark Kettenis  wrote:
> 
> > The downside of this diff is that number of levels is limited to 16
> > whereas we currently have much finer granularity.  But I think that is
> > acceptable.  The levels are probably better calibrated and we now have
> > proper coordination between the OS and the firmware when it comes to
> > brightness changes.
> 
> I'm in favor of this change since it fixes various niggling problems.
> 
> FWIW, the 16 levels also scale differently than the previous range.
> Stepping through with the brightness keys on my X230, I get
> respectively this:
> 
>new old
>   0.00%   1.17%  min
>   6.66%   2.34%
>  13.33%   3.51%
>  20.00%   4.68%
>  26.66%   5.88%
>  33.33%   7.43%
>  40.00%   9.01%
>  46.66%  10.97%
>  53.33%  12.93%
>  60.00%  15.68%
>  66.66%  19.60%
>  73.33%  25.49%
>  80.00%  34.50%
>  86.66%  49.01%
>  93.33%  72.54%
> 100.00% 100.00%  max
> 
> For instance, if you previously used wsconsctl display.brightness=20%,
> you'd now find your display much darker and would want to use 67%
> instead.

Indeed.  As far as the brightness keys are concerned, the actual
levels should be the same, but they translate into different
percentages.

Also thanks for pointing out the issue with the thinkpad_get_param()
code.  I've committed a version with that fixed.

Re: initial 11n support for iwn - defunc: Intel WiFi Link 5300 rev 0x00

[Marcus MERIGHI]

s...@stsp.name (Stefan Sperling), 2015.12.16 (Wed) 15:35 (CET):
> This diff adds 11n MCS 0-7 with A-MPDU and A-MSDU Rx to the iwn(4) driver.
> 
> It also tweaks replay detection for CCMP encrypted frames, which needed
> tweaking for A-MPDU anyway (see comments in code). Even in non-11n modes
> this driver was discarding some retransmitted frames for no good reason.
> 
> This driver supports a very wide range of hardware so please test this
> with as many iwn(4) adapters as possible. If we don't get enough tests
> this change may not be able to make the 5.9 release.
> 
> Works for me on:
> iwn0 at pci3 dev 0 function 0 "Intel Centrino Advanced-N 6200" rev 0x35: msi, 
> MIMO 2T2R, MoW
> 
> Please post here or let me know in private which hardware you're
> testing on. Thanks.

iwn0 at pci2 dev 0 function 0 "Intel WiFi Link 5300" rev 0x00: msi, MIMO
  3T3R, MoW, address 00:21:6a:8c:3d:9c

Does not link up with my access point as usual. 
An usb wifi dongle (run) does, contents of hostname.if are the same.

iwn0 in debug mode says:

iwn0: sending auth to 80:1f:02:c1:fd:86 on channel 5 mode 11b
iwn0: sending assoc_req to 80:1f:02:c1:fd:86 on channel 5 mode 11b
iwn0: received auth from 80:1f:02:c1:fd:86 rssi -54 mode 11b
iwn0: association failed (status 18) for 80:1f:02:c1:fd:86

Fetched bsd.rd from ftp.openbsd.org directly. No mirror had the Dec 17 
1:17 build already. Booted from SSD/bsd.rd and installed onto USB Stick.
Booted from USB, ran fw_update -a. 

dmesg of three boots: install, normal boot, normal boot with iwn debug.
followed by pcidump and usbdevs. acpidump available.

Bye, Marcus

OpenBSD 5.8-current (RAMDISK_CD) #1587: Thu Dec 17 01:22:12 MST 2015
dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/RAMDISK_CD
real mem = 4166717440 (3973MB)
avail mem = 4038721536 (3851MB)
mainbus0 at root
bios0 at mainbus0: SMBIOS rev. 2.4 @ 0xe0010 (68 entries)
bios0: vendor LENOVO version "6DET72WW (3.22 )" date 10/25/2012
bios0: LENOVO 7470W1W
acpi0 at bios0: rev 2
acpi0: tables DSDT FACP SSDT ECDT APIC MCFG HPET SLIC BOOT ASF! SSDT TCPA DMAR 
SSDT SSDT SSDT
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 L9400 @ 1.86GHz, 1862.29 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,XSAVE,NXE,LONG,LAHF,PERF,SENSOR
cpu0: 6MB 64b/line 16-way L2 cache
cpu0: apic clock running at 265MHz
cpu0: mwait min=64, max=64, C-substates=0.2.2.2.2.1.3, IBE
cpu at mainbus0: not configured
ioapic0 at mainbus0: apid 1 pa 0xfec0, version 20, 24 pins
ioapic0: misconfigured as apic 2, remapped to apid 1
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)
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
wsdisplay1 at vga1 mux 1: console (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:1f:16:32:df:5c
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
"Intel 82801I HD Audio" rev 0x03 at pci0 dev 27 function 0 not configured
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 5300" rev 0x00: msi, MIMO 3T3R, 
MoW, address 00:21:6a:8c:3d:9c
ppb2 at pci0 dev 28 function 3 "Intel 82801I PCIE" rev 0x03: msi
pci3 at ppb2 bus 5
uhci3 at pci0 dev 29 function 0 "Intel 82801I USB" rev 0x03: apic 1 int 16
uhci4 at pci0 dev 29 function 1 "Intel 82801I USB" rev 0x03: apic 1 int 17
uhci5 at pci0 dev 29 function 2 "Intel 82801I USB" rev 0x03: apic 1 int 18
ehci1 at pci0 dev 29 function 7 "Intel 82801I USB" rev 0x03: apic 1 int 19
usb1 at ehci1: USB revision 2.0
uhub1 at usb1 "Intel EHCI root hub" rev 2.00/1.00 addr 1
ppb3 at pci0 dev 30 function 0 "Intel 82801BAM Hub-to-PCI" rev 0x93
pci4 at ppb3 bus 13
"Intel 82801IEM LPC" rev 0x03 at pci0 dev 31 function 0 not configured
ahci0 at pci0 dev 31 function 2 "Intel 82801I AHCI" rev 0x03: msi, AHCI 1.2
ahci0: port 0: 3.0Gb/s
scsibus0 at ahci0: 32 targets
sd0 at scsibus0 targ 0 lun 0:  SCSI3 0/direct 
fixed naa.5001b44e1d7ef244

bus_dma: Size for free

[Mathieu -]

Here is a diff to pass around the size to free(9) in amd64's _bus_dmamap
allocations.

i386 is symmetric but I don't have the hardware currently to test it.

Index: bus_dma.c
===
RCS file: /cvs/src/sys/arch/amd64/amd64/bus_dma.c,v
retrieving revision 1.48
diff -u -p -r1.48 bus_dma.c
--- bus_dma.c   27 Jan 2015 05:10:30 -  1.48
+++ bus_dma.c   17 Dec 2015 11:16:34 -
@@ -149,8 +149,11 @@ _bus_dmamap_create(bus_dma_tag_t t, bus_
 void
 _bus_dmamap_destroy(bus_dma_tag_t t, bus_dmamap_t map)
 {
-
-   free(map, M_DEVBUF, 0);
+   size_t mapsize;
+   
+   mapsize = sizeof(struct bus_dmamap) +
+   (sizeof(bus_dma_segment_t) * (map->_dm_segcnt - 1));
+   free(map, M_DEVBUF, mapsize);
 }
 
 /*

Re: Thinkpad display brightness control

[Christian Weisgerber]

On 2015-12-16, Mark Kettenis  wrote:

> The downside of this diff is that number of levels is limited to 16
> whereas we currently have much finer granularity.  But I think that is
> acceptable.  The levels are probably better calibrated and we now have
> proper coordination between the OS and the firmware when it comes to
> brightness changes.

I'm in favor of this change since it fixes various niggling problems.

FWIW, the 16 levels also scale differently than the previous range.
Stepping through with the brightness keys on my X230, I get
respectively this:

   new old
  0.00%   1.17%  min
  6.66%   2.34%
 13.33%   3.51%
 20.00%   4.68%
 26.66%   5.88%
 33.33%   7.43%
 40.00%   9.01%
 46.66%  10.97%
 53.33%  12.93%
 60.00%  15.68%
 66.66%  19.60%
 73.33%  25.49%
 80.00%  34.50%
 86.66%  49.01%
 93.33%  72.54%
100.00% 100.00%  max

For instance, if you previously used wsconsctl display.brightness=20%,
you'd now find your display much darker and would want to use 67%
instead.

-- 
Christian "naddy" Weisgerber  na...@mips.inka.de