Re: Memory leak in rip engine (ripd)

[Remi Locherer]

On Mon, Dec 09, 2019 at 03:16:20PM +1100, Jason Tubnor wrote:
> On Mon, 9 Dec 2019 at 10:44, Remi Locherer  wrote:
> 
> >
> > >
> > > I can reproduce this issue. But only when I combine the use of
> > > "interface XY { passive }" and "redistribute connected". When I remove
> > > the passive interfaces from ripd.conf memory consumption is stable.
> > >
> > > Why do you combine these configs?
> >
> > Below diff fixes the memory leak for me.
> >
> > In addition to clear r_list I also moved the check for passive interface
> > a bit up so that the function can return as soon as possible.
> >
> > OK?
> >
> > Remi
> >
> >
> >
> >
> This patch applied cleanly and has fixed the memory leak issue when
> interfaces are configured 'passive'.  Tested with 1 active and 6 passive
> interfaces on one host and with a little memory consumption on startup
> [expected], it settled back down to 984KB of consumed RAM for 391 subnets
> and didn't move over 1.5 hours.
> 
> As /cvs/src/usr.sbin/ripd/message.c hasn't been touched since 2014, this
> patch would apply cleanly to 6.5 and 6.6 if an errata notice needed to be
> created (I can test on these if validation is required - will just take a
> little time to spin them up).
> 
> Thanks for your help Remi.
> 
> Cheers,
> 
> Jason.

Any OKs for this?

Below again the patch.

Remi




Index: message.c
===
RCS file: /cvs/src/usr.sbin/ripd/message.c,v
retrieving revision 1.12
diff -u -p -r1.12 message.c
--- message.c   25 Oct 2014 03:23:49 -  1.12
+++ message.c   8 Dec 2019 23:35:42 -
@@ -105,15 +105,15 @@ send_triggered_update(struct iface *ifac
u_int16_tafi, route_tag;
u_int32_taddress, netmask, nexthop, metric;
 
+   if (iface->passive)
+   return (0);
+
inet_aton(ALL_RIP_ROUTERS, _addr);
 
dst.sin_port = htons(RIP_PORT);
dst.sin_family = AF_INET;
dst.sin_len = sizeof(struct sockaddr_in);
 
-   if (iface->passive)
-   return (0);
-
if ((buf = ibuf_open(iface->mtu - sizeof(struct ip) -
sizeof(struct udphdr))) == NULL)
fatal("send_triggered_update");
@@ -166,13 +166,15 @@ send_request(struct packet_head *r_list,
port = htons(RIP_PORT);
}
 
+   if (iface->passive) {
+   clear_list(r_list);
+   return (0);
+   }
+
dst.sin_port = port;
dst.sin_family = AF_INET;
dst.sin_len = sizeof(struct sockaddr_in);
 
-   if (iface->passive)
-   return (0);
-
while (!TAILQ_EMPTY(r_list)) {
if ((buf = ibuf_open(iface->mtu - sizeof(struct ip) -
sizeof(struct udphdr))) == NULL)
@@ -240,13 +242,15 @@ send_response(struct packet_head *r_list
port = htons(RIP_PORT);
}
 
+   if (iface->passive) {
+   clear_list(r_list);
+   return (0);
+   }
+
dst.sin_port = port;
dst.sin_family = AF_INET;
dst.sin_len = sizeof(struct sockaddr_in);
 
-   if (iface->passive)
-   return (0);
-
while (!TAILQ_EMPTY(r_list)) {
if ((buf = ibuf_open(iface->mtu - sizeof(struct ip) -
sizeof(struct udphdr))) == NULL)

Re: Memory leak in rip engine (ripd)

[Remi Locherer]

On Sun, Dec 08, 2019 at 11:34:15PM +0100, Remi Locherer wrote:
> On Thu, Dec 05, 2019 at 12:07:25PM +1100, Jason Tubnor wrote:
> > I have been trying to track down a memory leak that has been observed for
> > quite a number of years over multiple releases without success.  I feel
> > that I have exhausted all potential configuration items that may have
> > caused this issue so now filing a bug.
> > 
> > >Synopsis:  ripd engine develops memory leak over time
> > >Category:  system
> > >Environment:
> > System  : OpenBSD 6.6
> > Details : OpenBSD 6.6-current (GENERIC.MP) #492: Wed Nov 27
> > 00:21:04 MST 2019
> >  dera...@amd64.openbsd.org:
> > /usr/src/sys/arch/amd64/compile/GENERIC.MP
> > 
> > Architecture: OpenBSD.amd64
> > Machine : amd64
> > >Description:
> >  When ripd isn't configured to redistribute anything, memory usage
> > remains static, once something is set for redistribution, that is when
> > memory begins to be consumed.  The config below (minus security - but
> > without security yields the same result) is loaded and the engine process
> > [below] is the memory behavior over a 3 hour period.  I have been able to
> > expedite memory consumption by increasing the interfaces and endpoints that
> > participate.  I have witnessed the engine grow to over 10GB in size with no
> > change in the routing table (393 routes).  Once memory is exhausted and
> > pressure put on swap, the host falls over.
> > 
> > >How-To-Repeat:
> > Various version 5.8 - 6.6 exhibit this problem.  Below is a simple
> > configuration and the resulting engine process being monitored over 3 hours:
> > 
> > # cat /etc/ripd.conf
> > no redistribute /22
> > redistribute connected
> > split-horizon simple
> > 
> > interface vxlan32 {
> > }
> > interface vio0 {
> > passive
> > }
> > interface vio1 {
> > passive
> > }
> > interface vio2 {
> > passive
> > }
> > interface vio3 {
> > passive
> > }
> > interface vio4 {
> > passive
> > }
> > interface vio5 {
> > passive
> > }
> > 
> 
> I can reproduce this issue. But only when I combine the use of
> "interface XY { passive }" and "redistribute connected". When I remove
> the passive interfaces from ripd.conf memory consumption is stable.
> 
> Why do you combine these configs?

Below diff fixes the memory leak for me.

In addition to clear r_list I also moved the check for passive interface
a bit up so that the function can return as soon as possible.

OK?

Remi



Index: message.c
===
RCS file: /cvs/src/usr.sbin/ripd/message.c,v
retrieving revision 1.12
diff -u -p -r1.12 message.c
--- message.c   25 Oct 2014 03:23:49 -  1.12
+++ message.c   8 Dec 2019 23:35:42 -
@@ -105,15 +105,15 @@ send_triggered_update(struct iface *ifac
u_int16_tafi, route_tag;
u_int32_taddress, netmask, nexthop, metric;
 
+   if (iface->passive)
+   return (0);
+
inet_aton(ALL_RIP_ROUTERS, _addr);
 
dst.sin_port = htons(RIP_PORT);
dst.sin_family = AF_INET;
dst.sin_len = sizeof(struct sockaddr_in);
 
-   if (iface->passive)
-   return (0);
-
if ((buf = ibuf_open(iface->mtu - sizeof(struct ip) -
sizeof(struct udphdr))) == NULL)
fatal("send_triggered_update");
@@ -166,13 +166,15 @@ send_request(struct packet_head *r_list,
port = htons(RIP_PORT);
}
 
+   if (iface->passive) {
+   clear_list(r_list);
+   return (0);
+   }
+
dst.sin_port = port;
dst.sin_family = AF_INET;
dst.sin_len = sizeof(struct sockaddr_in);
 
-   if (iface->passive)
-   return (0);
-
while (!TAILQ_EMPTY(r_list)) {
if ((buf = ibuf_open(iface->mtu - sizeof(struct ip) -
sizeof(struct udphdr))) == NULL)
@@ -240,13 +242,15 @@ send_response(struct packet_head *r_list
port = htons(RIP_PORT);
}
 
+   if (iface->passive) {
+   clear_list(r_list);
+   return (0);
+   }
+
dst.sin_port = port;
dst.sin_family = AF_INET;
dst.sin_len = sizeof(struct sockaddr_in);
 
-   if (iface->passive)
-   return (0);
-
while (!TAILQ_EMPTY(r_list)) {
if ((buf = ibuf_open(iface->mtu - sizeof(struct ip) -
sizeof(struct udphdr))) == NULL)

Re: Memory leak in rip engine (ripd)

[Remi Locherer]

On Thu, Dec 05, 2019 at 12:07:25PM +1100, Jason Tubnor wrote:
> I have been trying to track down a memory leak that has been observed for
> quite a number of years over multiple releases without success.  I feel
> that I have exhausted all potential configuration items that may have
> caused this issue so now filing a bug.
> 
> >Synopsis:  ripd engine develops memory leak over time
> >Category:  system
> >Environment:
> System  : OpenBSD 6.6
> Details : OpenBSD 6.6-current (GENERIC.MP) #492: Wed Nov 27
> 00:21:04 MST 2019
>  dera...@amd64.openbsd.org:
> /usr/src/sys/arch/amd64/compile/GENERIC.MP
> 
> Architecture: OpenBSD.amd64
> Machine : amd64
> >Description:
>  When ripd isn't configured to redistribute anything, memory usage
> remains static, once something is set for redistribution, that is when
> memory begins to be consumed.  The config below (minus security - but
> without security yields the same result) is loaded and the engine process
> [below] is the memory behavior over a 3 hour period.  I have been able to
> expedite memory consumption by increasing the interfaces and endpoints that
> participate.  I have witnessed the engine grow to over 10GB in size with no
> change in the routing table (393 routes).  Once memory is exhausted and
> pressure put on swap, the host falls over.
> 
> >How-To-Repeat:
> Various version 5.8 - 6.6 exhibit this problem.  Below is a simple
> configuration and the resulting engine process being monitored over 3 hours:
> 
> # cat /etc/ripd.conf
> no redistribute /22
> redistribute connected
> split-horizon simple
> 
> interface vxlan32 {
> }
> interface vio0 {
> passive
> }
> interface vio1 {
> passive
> }
> interface vio2 {
> passive
> }
> interface vio3 {
> passive
> }
> interface vio4 {
> passive
> }
> interface vio5 {
> passive
> }
> 

I can reproduce this issue. But only when I combine the use of
"interface XY { passive }" and "redistribute connected". When I remove
the passive interfaces from ripd.conf memory consumption is stable.

Why do you combine these configs?

> -
> Memory growth over 3 hours ( 26.8 MB ) - 214.6 MB per day
> ---
> 
> Thu Dec  5 08:07:09 AEDT 2019
> _ripd23284  0.0  1.9 146104 154956 ??  Sp Wed04PM0:18.02 ripd:
> rip engine (ripd)
> Thu Dec  5 08:17:09 AEDT 2019
> _ripd23284  0.0  1.9 147588 156440 ??  Sp Wed04PM0:18.21 ripd:
> rip engine (ripd)
> Thu Dec  5 08:27:09 AEDT 2019
> _ripd23284  0.0  1.9 149056 157908 ??  Sp Wed04PM0:18.40 ripd:
> rip engine (ripd)
> Thu Dec  5 08:37:10 AEDT 2019
> _ripd23284  0.0  1.9 150524 159376 ??  Sp Wed04PM0:18.58 ripd:
> rip engine (ripd)
> Thu Dec  5 08:47:10 AEDT 2019
> _ripd23284  0.0  1.9 152064 160916 ??  Sp Wed04PM0:18.77 ripd:
> rip engine (ripd)
> Thu Dec  5 08:57:10 AEDT 2019
> _ripd23284  0.1  1.9 153544 162396 ??  Sp Wed04PM0:18.96 ripd:
> rip engine (ripd)
> Thu Dec  5 09:07:10 AEDT 2019
> _ripd23284  0.0  2.0 155116 163968 ??  Sp Wed04PM0:19.15 ripd:
> rip engine (ripd)
> Thu Dec  5 09:17:10 AEDT 2019
> _ripd23284  0.0  2.0 156656 165508 ??  Sp Wed04PM0:19.34 ripd:
> rip engine (ripd)
> Thu Dec  5 09:27:10 AEDT 2019
> _ripd23284  0.0  2.0 158152 167004 ??  Sp Wed04PM0:19.53 ripd:
> rip engine (ripd)
> Thu Dec  5 09:37:10 AEDT 2019
> _ripd23284  0.0  2.0 159680 168532 ??  Sp Wed04PM0:19.72 ripd:
> rip engine (ripd)
> Thu Dec  5 09:47:10 AEDT 2019
> _ripd23284  0.0  2.0 161164 170016 ??  Sp Wed04PM0:19.91 ripd:
> rip engine (ripd)
> Thu Dec  5 09:57:10 AEDT 2019
> _ripd23284  0.0  2.0 162624 171476 ??  Sp Wed04PM0:20.09 ripd:
> rip engine (ripd)
> Thu Dec  5 10:07:10 AEDT 2019
> _ripd23284  0.1  2.1 164100 172952 ??  Sp Wed04PM0:20.28 ripd:
> rip engine (ripd)
> Thu Dec  5 10:17:10 AEDT 2019
> _ripd23284  0.0  2.1 165648 174500 ??  Sp Wed04PM0:20.46 ripd:
> rip engine (ripd)
> Thu Dec  5 10:27:10 AEDT 2019
> _ripd23284  0.1  2.1 167128 175980 ??  Sp Wed04PM0:20.65 ripd:
> rip engine (ripd)
> Thu Dec  5 10:37:10 AEDT 2019
> _ripd23284  0.0  2.1 168608 177460 ??  Sp Wed04PM0:20.84 ripd:
> rip engine (ripd)
> Thu Dec  5 10:47:10 AEDT 2019
> _ripd23284  0.0  2.1 170060 178912 ??  Sp Wed04PM0:21.03 ripd:
> rip engine (ripd)
> Thu Dec  5 10:57:10 AEDT 2019
> _ripd23284  0.0  2.2 171532 180384 ??  Sp Wed04PM0:21.21 ripd:
> rip engine (ripd)
> Thu Dec  5 11:07:10 AEDT 2019
> _ripd23284  0.0  2.2 172932 181784 ??  Sp Wed04PM0:21.40 ripd:
> rip engine (ripd)
> Thu Dec  5 11:17:10 AEDT 2019
> _ripd23284  0.0  2.2 174480 183332 ??  Sp Wed04PM0:21.59 ripd:
> rip engine (ripd)
> 
> >Fix:
> Current workaround once memory gets to a specific level is to
> restart the ripd process (not ideal):
> 
>  - rcctl 

Re: ospfd: passive p2p interfaces don't work

[Remi Locherer]

Hi Stefan

On Tue, Apr 09, 2019 at 04:16:32PM +0200, Stefan Sperling wrote:
> I want to announce a host-route to the address of a tun0 interface
> over OSPF. The config snippet I use for this looks like:
> 
> interface tun0:217.197.85.96 {
> passive
> depend on carp0
> }
> 
> With this configuration, the tun interface is permanently marked DOWN
> and the route is not announced:
> 
> Interface   AddressState  HelloTimer Linkstate  Uptimenc  ac
> tun0217.197.85.96/32   DOWN   -  active 00:00:00   0   0
> 
> If I omit 'passive' it works as expected:
> 
> interface tun0:217.197.85.96 {
> depend on carp0
> }
> 
> Interface   AddressState  HelloTimer Linkstate  Uptimenc  ac
> tun0217.197.85.96/32   P2P00:00:06   active 00:02:13   0   0
> 
> However, osfpd now sends useless OSPF packets, and my logs are being
> spammed with the message:
> send_packet: error sending packet on interface tun0: Permission denied
> 
> I believe this is a bug. I expect to be able to announce the address
> of a passive point-to-point interface with ospfd.
> 

The problem is that ospfd only originates the LSA you need when the interface
is in state IF_STA_POINTTOPOINT. But when the interface is passive it is in
state IF_STA_DOWN.

I think we should check the status of the link instead.

The diff below does that and adds the "depend on" logic.

OK?

Remi


Index: ospfe.c
===
RCS file: /cvs/src/usr.sbin/ospfd/ospfe.c,v
retrieving revision 1.103
diff -u -p -r1.103 ospfe.c
--- ospfe.c 27 Sep 2018 12:34:06 -  1.103
+++ ospfe.c 22 Apr 2019 09:08:53 -
@@ -900,7 +900,8 @@ orig_rtr_lsa(struct area *area)
if (ibuf_add(buf, _link, sizeof(rtr_link)))
fatalx("orig_rtr_lsa: ibuf_add failed");
}
-   if (iface->state & IF_STA_POINTTOPOINT) {
+   if ((iface->flags & IFF_UP) && 
+   LINK_STATE_IS_UP(iface->linkstate)) {
log_debug("orig_rtr_lsa: stub net, "
"interface %s", iface->name);
bzero(_link, sizeof(rtr_link));
@@ -912,7 +913,11 @@ orig_rtr_lsa(struct area *area)
rtr_link.data = iface->mask.s_addr;
}
rtr_link.type = LINK_TYPE_STUB_NET;
-   rtr_link.metric = htons(iface->metric);
+   if (iface->dependon[0] != '\0' &&
+   iface->depend_ok == 0)
+   rtr_link.metric = MAX_METRIC;
+   else
+   rtr_link.metric = htons(iface->metric);
num_links++;
if (ibuf_add(buf, _link, sizeof(rtr_link)))
fatalx("orig_rtr_lsa: ibuf_add failed");

Re: axen Ethernet device errors on both USB3.0 and USB2.0 ports

[Remi Locherer]

On Fri, Aug 24, 2018 at 06:02:20AM +, sc.dy...@gmail.com wrote:
> On 2018/08/19 09:40, Stefan Sperling wrote:
> > On Sun, Aug 19, 2018 at 11:05:04AM +0200, Stefan Sperling wrote:
> >> On Sun, Aug 19, 2018 at 09:56:33AM +0200, Remi Locherer wrote:
> >>> It would help if you could send a clean version that applies to -current.
> >>
> >> One of the attachments was in fact clean but yes, this
> >> thread has been much too noisy to follow easily.
> >>
> >> Try this.
> > 
> > Unfortunately, while this diff does indeed work on xhci(4), I've just
> > found that this diff breaks axen(4) attached to ehci(4) completely.
> > 
> > I see several "axen0: rxeof: too short transfer" in dmesg and
> > almost all packets are lost. Even my Ethernet switch gives up
> > eventually and disables the port.
> > 
> > So this diff is not ready to be committed.
> 
> I didn't check if axen works on ehci.
> On my ehci (intel PCH) that bug is reproduced, and
> I found that it works on ehci with 16kB RX buffer.
> I preserve the original bufsz decision code.

I applied axen5.diff and xhci.diff and tested the resulting kernel on
an old Samsung notebook that has ehci and xhci (demesg and usbdevs below).

When the axen dongle is attached via xhci it gets link but dhclient
never gets a lease. This works when attached via ehci. But after some
light traffic (browsing with netsurf) the systme panics. Here the output
from ddb (copied by hand):


kernel: page fault trap, code=0
Stopped at  memcpy+0x15:repe movsq  (%rsi),%es:(rdi)
ddb{1}> show panic
kernel page fault
uvm_fault(0xffdef19438, 0x0, 0, 1) -> e
memcpy(79e3..) at memcpy+0x15
end trace frame: 0x800032e06cd0, cound: 0
ddb{1} trace
memcpy(79e...) at memcpy+0x15
ptcread(5b11cd.) at ptcread+0x1eb
spec_read(70e.) at spec_read+0xab
VOP_READ(4b037..) at VOP_RAED+0x49
vn_read(af8b.) at dofilereadv+0xe0
sys_read(9862) at sys_read+0x5c
syscall(822b.) at syscall+0x32a
Xsyscall(0,3,0,3,f,1954e...) at Xsyscall+0x128
end of kernel
end trace frame 0x7f7d3430, count: -9
ddb{1}> mach ddb 0
Stopped at  x86_ipi_db+0x12:  popq%r11
ddb{0}> trace
x86_ipi_db(5d...) at x86_ipi_db+0x12
x86_ipi_handler() at x86_ipi_handler+0x80
Xresume_lapic_ipi(9,ff.) at Xresume_lapic_ipi+0x23
___mp_lock(58ifaff) at ___mp_lock+0x68
intr_handler(a26f9) at intr_handler+0x40
Xintr_ioapic_edge12_untramp(6,fff...) at Xintr_ioapic_edge12_untramp+0x19f
___mp_lock(58faff...) at___mp_lock+0x68
intr_handler(a26f9) at intr_handler+040
Xintr_ioapic_edge25_untramp(0,3,..) at Xintr_ioapic_edge25_untramp+0x19f
acpicpu_idle() at acpicpu_idle+0x166
sched_idle(0) at sced_idle+0x245
end trace frame: 0x0, count: -11
ddb{0}


This does not happen when running a snapshot kernel.

dmesg + usbdevs -vvv

OpenBSD 6.4-beta (GENERIC.MP) #0: Sat Aug 25 19:45:29 CEST 2018
r...@530u.relo.ch:/usr/src/sys/arch/amd64/compile/GENERIC.MP
real mem = 8462659584 (8070MB)
avail mem = 8196993024 (7817MB)
mpath0 at root
scsibus0 at mpath0: 256 targets
mainbus0 at root
bios0 at mainbus0: SMBIOS rev. 2.6 @ 0xe0840 (63 entries)
bios0: vendor Phoenix Technologies Ltd. version "05XK" date 02/10/2012
bios0: SAMSUNG ELECTRONICS CO., LTD. 530U3BI/530U4BI/530U4BH
acpi0 at bios0: rev 2
acpi0: sleep states S0 S1 S3 S4 S5
acpi0: tables DSDT FACP SLIC SSDT ASF! HPET APIC MCFG SSDT SSDT UEFI UEFI UEFI
acpi0: wakeup devices P0P1(S4) GLAN(S4) HDEF(S4) PXSX(S4) RP01(S4) PXSX(S4) 
RP02(S4) PXSX(S4) RP03(S4) PXSX(S4) RP04(S4) PXSX(S4) RP06(S4) PXSX(S4) 
RP07(S4) PXSX(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-2467M CPU @ 1.60GHz, 1597.58 MHz, 06-2a-07
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,AVX,NXE,RDTSCP,LONG,LAHF,PERF,ITSC,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,MELTDOWN
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) i5-2467M CPU @ 1.60GHz, 1895.69 MHz, 06-2a-07
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,AVX,NXE,RDTSCP,LONG,LAHF,PERF,ITSC,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,MELTDOWN
cpu1: 256K

Re: openBGPd crashes in 6.2 and 6.3: "a politician in the decision process"

[Remi Locherer]

Hi Pietro,

On Thu, Aug 23, 2018 at 10:05:30AM +0200, Pietro Stäheli wrote:
> Hi,
> 
> openBGPd is running at an internet exchange, two openBSD route servers
> (rs3 on openBSD 6.3 and rs4 on openBSD 6.2, both virtual machines on
> different hypervisors in different locations) connect with peering
> customers.
> 
> We've experienced crashes in openBGPd twice in the past two weeks. Both
> times with the same error message: "fatal in RDE: Uh, oh a politician in
> the decision process". These error messages are logged on both route
> servers right before they crash within seconds of each other.
> 
> The route servers had been running quite reliably for a long time before
> the recent incidents. The daemon can then be restarted without an issue.
> CPU usage prior to the crash is minimal (<5%).
> 
> In the minutes before the crash we're seeing error messages like the
> following in daemon.log:
> 
> bgpd[23099]: no such peer: id=4294967037
> 
> 
> Sample of logs just before the crash:
> 
> Aug 22 15:38:58 rs3 bgpd[43763]: Rib Loc-RIB: neighbor 91.206.52.170
> AS6939: update 81.163.124.0/24 via 91.206.52.170
> Aug 22 15:38:58 rs3 bgpd[23099]: no such peer: id=4294967037
> Aug 22 15:38:59 rs3 bgpd[43763]: Rib Loc-RIB: neighbor 2001:7f8:24::11
> AS31424: withdraw 2a01:6a8::/32
> Aug 22 15:38:59 rs3 bgpd[43763]: Rib Loc-RIB: neighbor 2001:7f8:24::bf
> AS33891: withdraw 2a01:6a8::/32
> Aug 22 15:38:59 rs3 bgpd[43763]: Rib Loc-RIB: neighbor 2001:7f8:24::aa
> AS6939: withdraw 2804:364c::/33
> Aug 22 15:38:59 rs3 bgpd[43763]: Rib Loc-RIB: neighbor 2001:7f8:24::aa
> AS6939: withdraw 2804:364c:8000::/33
> Aug 22 15:38:59 rs3 bgpd[43763]: Rib Loc-RIB: neighbor 2001:7f8:24::11
> AS31424: update 2a01:6a8::/32 via 2001:7f8:24::11
> Aug 22 15:38:59 rs3 bgpd[43763]: Rib Loc-RIB: neighbor 2001:7f8:24::aa
> AS6939: update 2804:364c::/33 via 2001:7f8:24::aa
> Aug 22 15:38:59 rs3 bgpd[43763]: Rib Loc-RIB: neighbor 2001:7f8:24::aa
> AS6939: update 2804:364c:8000::/33 via 2001:7f8:24::aa
> Aug 22 15:38:59 rs3 bgpd[43763]: Rib Loc-RIB: neighbor 2001:7f8:24::bf
> AS33891: update 2a01:6a8::/32 via 2001:7f8:24::bf
> Aug 22 15:39:00 rs3 bgpd[23099]: Connection attempt from neighbor
> 91.206.52.139 while session is in state Idle
> Aug 22 15:39:01 rs3 bgpd[43763]: Rib Loc-RIB: neighbor 91.206.52.96
> AS31042: update 185.64.172.0/24 via 91.206.52.96
> Aug 22 15:39:01 rs3 bgpd[43763]: fatal in RDE: Uh, oh a politician in
> the decision process
> Aug 22 15:39:01 rs3 bgpd[99961]: peer closed imsg connection
> Aug 22 15:39:01 rs3 bgpd[99961]: main: Lost connection to RDE
> Aug 22 15:39:01 rs3 bgpd[23099]: peer closed imsg connection
> Aug 22 15:39:01 rs3 bgpd[23099]: SE: Lost connection to parent
> 
> 
> Logs just before the "no such peer" messages appear:
> 
> Aug 22 15:36:43 rs3 bgpd[43763]: Rib Loc-RIB: neighbor 91.206.52.54
> AS34554: update 80.75.112.0/20 via 91.206.52.54
> Aug 22 15:36:43 rs3 bgpd[43763]: Rib Loc-RIB: neighbor 2001:7f8:24::36
> AS34554: update 2a01:6a8::/32 via 2001:7f8:24::36
> Aug 22 15:36:44 rs3 bgpd[43763]: Rib Loc-RIB: neighbor 2001:7f8:24::bf
> AS33891: update 2a0d:8d80::/32 via 2001:7f8:24::bf
> Aug 22 15:36:47 rs3 bgpd[23099]: neighbor 91.206.52.96: graceful restart
> of IPv4 unicast, keeping routes
> Aug 22 15:36:47 rs3 bgpd[23099]: neighbor 91.206.52.96: state change
> Established -> Idle, reason: Connection closed
> Aug 22 15:36:47 rs3 bgpd[23099]: neighbor 91.206.52.96: removed
> Aug 22 15:36:49 rs3 bgpd[43763]: Rib Loc-RIB: neighbor 2001:7f8:24::11
> AS31424: withdraw 2a01:6a8::/32
> Aug 22 15:36:49 rs3 bgpd[43763]: Rib Loc-RIB: neighbor 2001:7f8:24::bf
> AS33891: withdraw 2a01:6a8::/32
> Aug 22 15:36:49 rs3 bgpd[43763]: Rib Loc-RIB: neighbor 2001:7f8:24::11
> AS31424: update 2a01:6a8::/32 via 2001:7f8:24::11
> Aug 22 15:36:49 rs3 bgpd[43763]: Rib Loc-RIB: neighbor 2001:7f8:24::bf
> AS33891: update 2a01:6a8::/32 via 2001:7f8:24::bf
> Aug 22 15:36:54 rs3 bgpd[43763]: Rib Loc-RIB: neighbor 2001:7f8:24::bf
> AS33891: update 2a0d:8d80::/32 via 2001:7f8:24::bf
> Aug 22 15:36:55 rs3 bgpd[43763]: Rib Loc-RIB: neighbor 91.206.52.170
> AS6939: update 197.249.160.0/19 via 91.206.52.170
> Aug 22 15:36:55 rs3 bgpd[23099]: no such peer: id=4294967037
> 
> 
> 
> I haven't found much about the error message apart from this mailing
> list thread: https://www.mail-archive.com/misc@openbsd.org/msg04565.html
> 
> The thread suggests that invoking bgpctl may cause the failure. 'bgpctl
> show' is invoked every few minutes through our monitoring system to
> check on the status of peer connections.
> 
> Can anybody point me to a possible cause or troubleshooting regarding
> this issue? Could a misconfigured/broken peer be the cause?  Has anybody
> dealt with a similar problem?
> 
> I can provide bgpd.conf and full logs of both incidents if necessary.

I move this over to bugs@ which feels more appropriate to me. Chances that
a bgpd developer sees it is higher.

Somehow there where two identical paths and bgpd could not figure out

Re: axen Ethernet device errors on both USB3.0 and USB2.0 ports

[Remi Locherer]

On Sun, Aug 19, 2018 at 11:40:50AM +0200, Stefan Sperling wrote:
> On Sun, Aug 19, 2018 at 11:05:04AM +0200, Stefan Sperling wrote:
> > On Sun, Aug 19, 2018 at 09:56:33AM +0200, Remi Locherer wrote:
> > > It would help if you could send a clean version that applies to -current.
> > 
> > One of the attachments was in fact clean but yes, this
> > thread has been much too noisy to follow easily.
> > 
> > Try this.
> 
> Unfortunately, while this diff does indeed work on xhci(4), I've just
> found that this diff breaks axen(4) attached to ehci(4) completely.
> 
> I see several "axen0: rxeof: too short transfer" in dmesg and
> almost all packets are lost. Even my Ethernet switch gives up
> eventually and disables the port.
> 
> So this diff is not ready to be committed.

By now I verified that this is an improvement on xhci. Before I could
panic my machine by unplugging axen while transfering date. Also without
this diff after some time axen got "stuck" and I needed to unplug (dangerous)
to get it working again.

I'll prepare machine with ehci to be able to test the next diff. ;-)

Remi

Re: axen Ethernet device errors on both USB3.0 and USB2.0 ports

[Remi Locherer]

On Sat, Aug 18, 2018 at 10:38:36AM +0200, Stefan Sperling wrote:
> Thank you for taking care of axen(4).
> The problems with this driver have been known for some time.
> 
> On Tue, Aug 07, 2018 at 02:04:24PM +, sc.dy...@gmail.com wrote:
> >  - header: fix comments
> >  - header: fix unused L3 type mask definition
> >  - rxeof: Avoid allocating mbuf if checksum errors are detected.
> >  - rxeof: Avoid loop to extract packets if pkt_count is 0.
> >  - rxeof: Add more sanity checks.
> >  - rxeof: Increament if_ierror in some error paths.
> >  - qctrl: Apply queuing control parameters from FreeBSD axge(4).
> >  - qctrl: Set qctrl in miireg_statchg dynamically, not statically.
> >  - Use DMA buffer aligned at 64KB boundary to avoid xhci bug.
> 
> You're actually switching to a 64KB buffer size as well, not only to
> 64KB alignment. That is a relatively large size. The previous code
> was using 8KB, 16KB, and 24KB buffers. Do I understand correctly
> that the qctrl configuration allows hardware to provide only up
> to 0x18*1024 = 24KB bytes of packet data per Rx interrupt?
> 
> Regardless, in my opinion your diff improves this driver which
> has not seen any regular maintainance in a long time.
> If another developer (remi? mlarkin?) provides an OK I will commit it.
> 

I wanted to test this. Unfortunately the axen4.diff does not apply
to my -current tree. Is it because of the white space issue mentioned
in the thread? Or do I need to first apply one of the other patches?

It would help if you could send a clean version that applies to -current.

Thank you for looking at improving axen(4)!

Remi

> > --- sys/dev/usb/if_axenreg.hFri Sep 16 22:17:07 2016
> > +++ sys/dev/usb/if_axenreg.hMon Jun 19 10:54:28 2017
> > @@ -26,8 +26,8 @@
> >   * || ++-L3_type (1:ipv4, 0/2:ipv6)
> >   *pkt_len(13)  || ||+ ++-L4_type(0: icmp, 1: UDP, 4: TCP)
> >   * |765|43210 76543210|7654 3210 7654 3210|
> > - *  ||+-crc_err  |+-L4_err |+-L4_CSUM_ERR
> > - *  |+-mii_err   +--L3_err +--L3_CSUM_ERR
> > + *  ||+-crc_err   |+-L4_err |+-L4_CSUM_ERR
> > + *  |+-mii_err+--L3_err +--L3_CSUM_ERR
> >   *  +-drop_err
> >   *
> >   * ex) pkt_hdr 0x00680820
> > @@ -70,7 +70,7 @@
> >  #define   AXEN_RXHDR_L4_TYPE_TCP   0x4
> >  
> >  /* L3 packet type (2bit) */
> > -#define AXEN_RXHDR_L3_TYPE_MASK0x0600
> > +#define AXEN_RXHDR_L3_TYPE_MASK0x0060
> >  #define AXEN_RXHDR_L3_TYPE_OFFSET  5
> >  #define   AXEN_RXHDR_L3_TYPE_UNDEF 0x0
> >  #define   AXEN_RXHDR_L3_TYPE_IPV4  0x1
> > --- sys/dev/usb/if_axen.c.orig  Tue Jun 12 15:36:59 2018
> > +++ sys/dev/usb/if_axen.c   Sun Jul 29 01:53:43 2018
> > @@ -53,6 +53,7 @@
> >  #include 
> >  #include 
> >  #include 
> > +#include 
> >  
> >  #include 
> >  
> > @@ -121,6 +122,13 @@ void   axen_unlock_mii(struct axen_softc *sc);
> >  
> >  void   axen_ax88179_init(struct axen_softc *);
> >  
> > +struct axen_qctrl axen_bulk_size[] = {
> > +   { 7, 0x4f, 0x00, 0x12, 0xff },
> > +   { 7, 0x20, 0x03, 0x16, 0xff },
> > +   { 7, 0xae, 0x07, 0x18, 0xff },
> > +   { 7, 0xcc, 0x4c, 0x18, 0x08 }
> > +};
> > +
> >  /* Get exclusive access to the MII registers */
> >  void
> >  axen_lock_mii(struct axen_softc *sc)
> > @@ -238,6 +246,8 @@ axen_miibus_statchg(struct device *dev)
> > int err;
> > uint16_tval;
> > uWord   wval;
> > +   uint8_t linkstat = 0;
> > +   int qctrl;
> >  
> > ifp = GET_IFP(sc);
> > if (mii == NULL || ifp == NULL ||
> > @@ -265,27 +275,49 @@ axen_miibus_statchg(struct device *dev)
> > return;
> >  
> > val = 0;
> > -   if ((IFM_OPTIONS(mii->mii_media_active) & IFM_FDX) != 0)
> > +   if ((IFM_OPTIONS(mii->mii_media_active) & IFM_FDX) != 0) {
> > val |= AXEN_MEDIUM_FDX;
> > +   if ((IFM_OPTIONS(mii->mii_media_active) & IFM_ETH_TXPAUSE) != 0)
> > +   val |= AXEN_MEDIUM_TXFLOW_CTRL_EN;
> > +   if ((IFM_OPTIONS(mii->mii_media_active) & IFM_ETH_RXPAUSE) != 0)
> > +   val |= AXEN_MEDIUM_RXFLOW_CTRL_EN;
> > +   }
> >  
> > -   val |= (AXEN_MEDIUM_RECV_EN | AXEN_MEDIUM_ALWAYS_ONE);
> > -   val |= (AXEN_MEDIUM_RXFLOW_CTRL_EN | AXEN_MEDIUM_TXFLOW_CTRL_EN);
> > +   val |= AXEN_MEDIUM_RECV_EN;
> >  
> > +   /* bulkin queue setting */
> > +   axen_lock_mii(sc);
> > +   axen_cmd(sc, AXEN_CMD_MAC_READ, 1, AXEN_USB_UPLINK, );
> > +   axen_unlock_mii(sc);
> > +
> > switch (IFM_SUBTYPE(mii->mii_media_active)) {
> > case IFM_1000_T:
> > val |= AXEN_MEDIUM_GIGA | AXEN_MEDIUM_EN_125MHZ;
> > +   if (linkstat & AXEN_USB_SS)
> > +   qctrl = 0;
> > +   else if (linkstat & AXEN_USB_HS)
> > +   qctrl = 1;
> > +   else
> > +   qctrl = 3;
> > break;
> > case IFM_100_TX:
> > val |= 

Re: rdomain/rtable 255 BGPd routes -> leaking to rdomain/rtable 0

[Remi Locherer]

On Thu, Apr 12, 2018 at 07:14:57PM +0200, Sebastian Benoit wrote:
> Nicolas Pence(nico...@pence.com.uy) on 2018.04.12 13:03:39 -0300:
> > Thinking about it a little more, I've configured sshd_rtable=255 on 
> > /etc/rc.conf.local,
> > on the non-working boxes, I'm re-checking this doing:
> > 
> > rcctl set sshd rtable 0
> > 
> > and changing sshd_config:
> > 
> > ListenAddress $IP rdomain 255
> 
> just to make sure: changing the sshd configuration fixes your problem as
> well? i.e. there is no bug?
> 
> For you convinience, this lets you display the rdomain on your shell prompt:
> 
>   rdomain=`ps -o rtable -p $$ | tail -n+2`

or:
rdomain=`id -R`

>   export PS1="[\u@$\h:\w]($rdomain)\$ " 
> 
> /Benno

Re: OpenBSD 6.2 IKED IPv6 Connections and address dropped

[Remi Locherer]

On Thu, Feb 15, 2018 at 06:52:46PM -0200, R0me0 *** wrote:
> Hello guys!
> 
> I have a very weird issue, not sure if a bug, but seems.
> 
> Here my iked.conf
> 
> ikev2 "pufferfish"  passive esp from 0.0.0.0/0 to 192.10.10.0/24 \
>  local 10.10.10.10 peer any  \
>  ikesa enc aes-256 auth hmac-sha2-256 group modp2048 \
>  childsa enc aes-256 auth hmac-sha2-256 group modp2048 \
>  dstid pufferfish psk "mypsk" config address 192.10.10.15
> 
> My default gateway is fe80::1%vmx0
> 
> 
> If I run:
> 
> 
> /etc/rc.d/iked start
> 
> All IPV6 connections are dropped immediately .


iked does that to prevent traffic leakages. Either add IPv6 flows
to your iked.conf or start iked with "-6".


> 
> Even if I remove all IPV6 address from all interfaces I cant back
> 
> OpenBSD reboot is needed !
> 
> all patches applied using syspatch.
> 
> 
> 
> ping6 ::1
> PING ::1 (::1): 56 data bytes
> ping6: sendmsg: No route to host
> ping: wrote ::1 64 chars, ret=-1
> ^C
> --- ::1 ping statistics ---
> 1 packets transmitted, 0 packets received, 100.0% packet loss
> 
> 
> ping6 fe80::1%vmx0
> PING fe80::1%vmx0 (fe80::1%vmx0): 56 data bytes
> ping6: sendmsg: No route to host
> ping: wrote fe80::1%vmx0 64 chars, ret=-1
> ^C
> --- fe80::1%vmx0 ping statistics ---
> 1 packets transmitted, 0 packets received, 100.0% packet loss
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> *rebooting...OpenBSD 6.2 (GENERIC.MP ) #5: Fri Feb  2
> 23:02:19 CET 2018
> r...@syspatch-62-amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
> real mem = 1056899072 (1007MB)avail mem = 1017901056
> (970MB)mpath0 at rootscsibus0 at mpath0: 256 targetsmainbus0 at rootbios0
> at mainbus0: SMBIOS rev. 2.7 @ 0xe0010 (242 entries)bios0: vendor Phoenix
> Technologies LTD version "6.00" date 04/05/2016bios0: VMware, Inc. VMware
> Virtual Platformacpi0 at bios0: rev 2acpi0: sleep states S0 S1 S4 S5acpi0:
> tables DSDT FACP BOOT APIC MCFG SRAT HPET WAETacpi0: wakeup devices
> PCI0(S3) USB_(S1) P2P0(S3) S1F0(S3) S2F0(S3) S8F0(S3) S16F(S3) S17F(S3)
> S18F(S3) S22F(S3) S23F(S3) S24F(S3) S25F(S3) PE40(S3) S1F0(S3) PE50(S3)
> [...]acpitimer0 at acpi0: 3579545 Hz, 24 bitsacpimadt0 at acpi0 addr
> 0xfee0: PC-AT compatcpu0 at mainbus0: apid 0 (boot processor)cpu0:
> Intel(R) Xeon(R) CPU E5-1650 v2 @ 3.50GHz, 3500.11 MHzcpu0:
> FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,MMX,FXSR,SSE,SSE2,SS,SSE3,PCLMUL,SSSE3,CX16,PCID,SSE4.1,SSE4.2,x2APIC,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,HV,NXE,RDTSCP,LONG,LAHF,PERF,ITSC,FSGSBASE,SMEP,ERMS,ARATcpu0:
> 256KB 64b/line 8-way L2 cachecpu0: TSC frequency 3500112670 Hzcpu0: smt 0,
> core 0, package 0mtrr: Pentium Pro MTRR support, 8 var ranges, 88 fixed
> rangescpu0: apic clock running at 65MHzcpu1 at mainbus0: apid 2
> (application processor)cpu1: Intel(R) Xeon(R) CPU E5-1650 v2 @ 3.50GHz,
> 3499.85 MHzcpu1:
> FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,MMX,FXSR,SSE,SSE2,SS,SSE3,PCLMUL,SSSE3,CX16,PCID,SSE4.1,SSE4.2,x2APIC,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,HV,NXE,RDTSCP,LONG,LAHF,PERF,ITSC,FSGSBASE,SMEP,ERMS,ARATcpu1:
> 256KB 64b/line 8-way L2 cachecpu1: smt 0, core 0, package 2ioapic0 at
> mainbus0: apid 1 pa 0xfec0, version 11, 24 pinsacpimcfg0 at acpi0 addr
> 0xf000, bus 0-127acpihpet0 at acpi0: 14318179 Hzacpiprt0 at acpi0: bus
> 0 (PCI0)acpicpu0 at acpi0: C1(@1 halt!)acpicpu1 at acpi0: C1(@1
> halt!)"PNP0001" at acpi0 not configured"VMW0003" at acpi0 not
> configured"PNP0A05" at acpi0 not configuredacpiac0 at acpi0: AC unit
> onlinepvbus0 at mainbus0: VMwarevmt0 at pvbus0pci0 at mainbus0 bus 0pchb0
> at pci0 dev 0 function 0 "Intel 82443BX AGP" rev 0x01ppb0 at pci0 dev 1
> function 0 "Intel 82443BX AGP" rev 0x01pci1 at ppb0 bus 1pcib0 at pci0 dev
> 7 function 0 "Intel 82371AB PIIX4 ISA" rev 0x08pciide0 at pci0 dev 7
> function 1 "Intel 82371AB IDE" rev 0x01: DMA, channel 0 configured to
> compatibility, channel 1 configured to compatibilitypciide0: channel 0
> disabled (no drives)pciide0: channel 1 disabled (no drives)piixpm0 at pci0
> dev 7 function 3 "Intel 82371AB Power" rev 0x08: SMBus disabled"VMware
> VMCI" rev 0x10 at pci0 dev 7 function 7 not configuredvga1 at pci0 dev 15
> function 0 "VMware SVGA II" rev 0x00wsdisplay0 at vga1 mux 1: console
> (80x25, vt100 emulation)wsdisplay0: screen 1-5 added (80x25, vt100
> emulation)mpi0 at pci0 dev 16 function 0 "Symbios Logic 53c1030" rev 0x01:
> apic 1 int 17mpi0: 0, firmware 1.3.41.32scsibus1 at 

Re: wrong if used after adding new route - affects syslog, dhcrelay and more

[Remi Locherer]

On Mon, Jan 29, 2018 at 07:33:47PM +0100, Remi Locherer wrote:
> > Problem Description
> Local originating traffic leaves the system on the wrong interface
> after a more specific route was added. This is problematic for services
> like dhcrelay and syslogd.
> 
> I verified this on iced this on OpenBSD 6.1 but do not know how if was with
> older versions. The behaviour is still the same with current.

What I wanted to write:
I verified this behaviour on OpenBSD 6.1, 6.2 and -current. I do not know
if it was different with older releases.

> 
> > Workaround:
> Monitor the routing socket and restart affected services when the routing
> table changes.
> 
> > How to reproduce:
> mistral ~# route -n show -inet
> Routing tables
> 
> Internet:
> DestinationGatewayFlags   Refs  Use   Mtu  Prio Iface
> default172.18.35.1UGS7  408 -12 iwm0 
> 224/4  127.0.0.1  URS0 1898 32768 8 lo0  
> 127/8  127.0.0.1  UGRS   00 32768 8 lo0  
> 127.0.0.1  127.0.0.1  UHhl   14 32768 1 lo0  
> 172.18.35/24   172.18.35.87   UCn1  634 - 8 iwm0 
> 172.18.35.1cc:4e:24:82:88:42  UHLch  1  312 - 7 iwm0 
> 172.18.35.87   5c:e0:c5:1f:ad:c4  UHLl   0   14 - 1 iwm0 
> 172.18.35.255  172.18.35.87   UHb0  633 - 1 iwm0 
> 172.30.1/24192.168.250.18 UGS00 - 8 
> vether0
> 192.168.250/24 192.168.250.1  UCn10 - 4 
> vether0
> 192.168.250.1  fe:e1:ba:d0:05:e2  UHLl   05 - 1 
> vether0
> 192.168.250.18 fe:e1:bb:d1:a2:b9  UHLch  2   37 - 3 
> vether0
> 192.168.250.255192.168.250.1  UHb1  105 - 1 
> vether0
> mistral ~#
> 
> $mistral 130 ~$ nc -u 172.30.1.1  
> adsfsa
> 
> --> do not press ^C, keep it open to generate traffic over the same
> socket after changing routes
> 
> --> as expected traffic leaves on vether0
> 16:24:00.676256 rule 0/(match) match out on vether0: 192.168.250.1.28812 > 
> 172.30.1.1.: udp 7
> 
> mistral ~# route del 172.30.1.0/24
> 
> --> now traffic leaves on iwm0. makes sense because of the default route.
> 16:24:51.078621 rule 0/(match) match out on iwm0: 192.168.250.1.28812 > 
> 172.30.1.1.: udp 3
> 
> mistral ~# route add 172.30.1.0/24 192.168.250.18
> 
> --> traffic still leaves iwm0. expectations: vether0
> 16:28:09.440038 rule 0/(match) match out on iwm0: 192.168.250.1.28812 > 
> 172.30.1.1.: udp 4
> 
> 
> > dmesg
> 
> OpenBSD 6.2-current (GENERIC.MP) #107: Tue Jan 16 21:58:15 CET 2018
> r...@mistral.relo.ch:/usr/src/sys/arch/amd64/compile/GENERIC.MP
> real mem = 8473632768 (8081MB)
> avail mem = 8209895424 (7829MB)
> mpath0 at root
> scsibus0 at mpath0: 256 targets
> mainbus0 at root
> bios0 at mainbus0: SMBIOS rev. 2.8 @ 0xe (84 entries)
> bios0: vendor Dell Inc. version "A13" date 06/16/2017
> bios0: Dell Inc. XPS 13 9343
> acpi0 at bios0: rev 2
> acpi0: sleep states S0 S3 S4 S5
> acpi0: tables DSDT FACP APIC FPDT FIDT MCFG HPET SSDT UEFI SSDT ASF! SSDT 
> SSDT SSDT SSDT PCCT SSDT SSDT SSDT SLIC MSDM DMAR CSRT BGRT
> acpi0: wakeup devices PEGP(S4) PEG0(S4) PEGP(S4) PEG1(S4) PEGP(S4) PEG2(S4) 
> PXSX(S4) RP01(S4) PXSX(S4) RP02(S4) PXSX(S4) RP03(S4) PXSX(S4) RP04(S4) 
> PXSX(S4) RP05(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-5200U CPU @ 2.20GHz, 2494.62 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,RDTSCP,LONG,LAHF,ABM,3DNOWP,PERF,ITSC,FSGSBASE,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,RDSEED,ADX,SMAP,PT,SENSOR,ARAT
> cpu0: 256KB 64b/line 8-way L2 cache
> acpitimer0: recalibrated TSC frequency 2194928041 Hz
> cpu0: smt 0, core 0, package 0
> mtrr: Pentium Pro MTRR support, 10 var ranges, 88 fixed ranges
> cpu0: apic clock running at 99MHz
> cpu0: mwait min=64, max=64, C-substates=0.2.1.2.4.1.1.1, IBE
> cpu1 at mainbus0: apid 2 (application processor)
> cpu1: Intel(R) Core(TM) i5-5200U CPU @ 2.20GHz, 2494.22 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,C

wrong if used after adding new route - affects syslog, dhcrelay and more

[Remi Locherer]

> Problem Description
Local originating traffic leaves the system on the wrong interface
after a more specific route was added. This is problematic for services
like dhcrelay and syslogd.

I verified this on iced this on OpenBSD 6.1 but do not know how if was with
older versions. The behaviour is still the same with current.

> Workaround:
Monitor the routing socket and restart affected services when the routing
table changes.

> How to reproduce:
mistral ~# route -n show -inet
Routing tables

Internet:
DestinationGatewayFlags   Refs  Use   Mtu  Prio Iface
default172.18.35.1UGS7  408 -12 iwm0 
224/4  127.0.0.1  URS0 1898 32768 8 lo0  
127/8  127.0.0.1  UGRS   00 32768 8 lo0  
127.0.0.1  127.0.0.1  UHhl   14 32768 1 lo0  
172.18.35/24   172.18.35.87   UCn1  634 - 8 iwm0 
172.18.35.1cc:4e:24:82:88:42  UHLch  1  312 - 7 iwm0 
172.18.35.87   5c:e0:c5:1f:ad:c4  UHLl   0   14 - 1 iwm0 
172.18.35.255  172.18.35.87   UHb0  633 - 1 iwm0 
172.30.1/24192.168.250.18 UGS00 - 8 vether0
192.168.250/24 192.168.250.1  UCn10 - 4 vether0
192.168.250.1  fe:e1:ba:d0:05:e2  UHLl   05 - 1 vether0
192.168.250.18 fe:e1:bb:d1:a2:b9  UHLch  2   37 - 3 vether0
192.168.250.255192.168.250.1  UHb1  105 - 1 vether0
mistral ~#

$mistral 130 ~$ nc -u 172.30.1.1  
adsfsa

--> do not press ^C, keep it open to generate traffic over the same
socket after changing routes

--> as expected traffic leaves on vether0
16:24:00.676256 rule 0/(match) match out on vether0: 192.168.250.1.28812 > 
172.30.1.1.: udp 7

mistral ~# route del 172.30.1.0/24

--> now traffic leaves on iwm0. makes sense because of the default route.
16:24:51.078621 rule 0/(match) match out on iwm0: 192.168.250.1.28812 > 
172.30.1.1.: udp 3

mistral ~# route add 172.30.1.0/24 192.168.250.18

--> traffic still leaves iwm0. expectations: vether0
16:28:09.440038 rule 0/(match) match out on iwm0: 192.168.250.1.28812 > 
172.30.1.1.: udp 4


> dmesg

OpenBSD 6.2-current (GENERIC.MP) #107: Tue Jan 16 21:58:15 CET 2018
r...@mistral.relo.ch:/usr/src/sys/arch/amd64/compile/GENERIC.MP
real mem = 8473632768 (8081MB)
avail mem = 8209895424 (7829MB)
mpath0 at root
scsibus0 at mpath0: 256 targets
mainbus0 at root
bios0 at mainbus0: SMBIOS rev. 2.8 @ 0xe (84 entries)
bios0: vendor Dell Inc. version "A13" date 06/16/2017
bios0: Dell Inc. XPS 13 9343
acpi0 at bios0: rev 2
acpi0: sleep states S0 S3 S4 S5
acpi0: tables DSDT FACP APIC FPDT FIDT MCFG HPET SSDT UEFI SSDT ASF! SSDT SSDT 
SSDT SSDT PCCT SSDT SSDT SSDT SLIC MSDM DMAR CSRT BGRT
acpi0: wakeup devices PEGP(S4) PEG0(S4) PEGP(S4) PEG1(S4) PEGP(S4) PEG2(S4) 
PXSX(S4) RP01(S4) PXSX(S4) RP02(S4) PXSX(S4) RP03(S4) PXSX(S4) RP04(S4) 
PXSX(S4) RP05(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-5200U CPU @ 2.20GHz, 2494.62 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,RDTSCP,LONG,LAHF,ABM,3DNOWP,PERF,ITSC,FSGSBASE,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,RDSEED,ADX,SMAP,PT,SENSOR,ARAT
cpu0: 256KB 64b/line 8-way L2 cache
acpitimer0: recalibrated TSC frequency 2194928041 Hz
cpu0: smt 0, core 0, package 0
mtrr: Pentium Pro MTRR support, 10 var ranges, 88 fixed ranges
cpu0: apic clock running at 99MHz
cpu0: mwait min=64, max=64, C-substates=0.2.1.2.4.1.1.1, IBE
cpu1 at mainbus0: apid 2 (application processor)
cpu1: Intel(R) Core(TM) i5-5200U CPU @ 2.20GHz, 2494.22 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,RDTSCP,LONG,LAHF,ABM,3DNOWP,PERF,ITSC,FSGSBASE,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,RDSEED,ADX,SMAP,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-5200U CPU @ 2.20GHz, 2494.22 MHz
cpu2: 

[solved] ifconfig carpX a.b.c.d -> arpresolve: route contains no arp information

[Remi Locherer]

On Mon, Jul 24, 2017 at 02:22:33PM +0200, Martin Pieuchot wrote:
> On 21/07/17(Fri) 12:13, Remi Locherer wrote:
> > [...] 
> > Somebody suggested in a private mail to use /32 masks for carp interfaces.
> > This fix/workaround helps indeed!
> 
> Good to know!  However from my developer's chair there's still a bug.
> Nothing should happen to a route attached to vio1 when you modify
> something on carp1.
> 

If somebody stumbles over this mail thread: the issue is fixed!

I just tested with OpenBSD-6.2 and -current (from today) and the behaviour
is the same again as with OpenBSD-6.0.

Re: ifconfig carpX a.b.c.d -> arpresolve: route contains no arp information

[Remi Locherer]

On Mon, Jul 24, 2017 at 02:22:33PM +0200, Martin Pieuchot wrote:
> On 21/07/17(Fri) 12:13, Remi Locherer wrote:
> > [...] 
> > Somebody suggested in a private mail to use /32 masks for carp interfaces.
> > This fix/workaround helps indeed!
> 
> Good to know!  However from my developer's chair there's still a bug.
> Nothing should happen to a route attached to vio1 when you modify
> something on carp1.
> 
> Could you repeat the "route monitor" steps with a kernel containing the
> diff below? 

here you go:

gw1# route monitor
got message of size 192 on Mon Jul 24 19:32:43 2017
RTM_DELETE: Delete Route: len 192, priority 3, table 0, ifidx 3, pid: 0, seq 0, 
errno 0
flags:<HOST,DONE,CLONED,CACHED>
fmask:
use:0   mtu:0expire:0
locks:  inits:
sockaddrs: <DST,GATEWAY,IFP,IFA>
 10.0.20.10 08:00:27:6b:9a:c1 08:00:27:7e:f3:d5 10.0.20.2
got message of size 192 on Mon Jul 24 19:32:43 2017
RTM_DELETE: Delete Route: len 192, priority 19, table 0, ifidx 7, pid: 0, seq 
0, errno 0
flags:<DONE,CLONING,CONNECTED>
fmask:
use:0   mtu:0expire:0
locks:  inits:
sockaddrs: <DST,GATEWAY,NETMASK,IFP,IFA>
 10.0.20.0 10.0.20.1 255.255.255.0 00:00:5e:00:01:17 10.0.20.1
got message of size 176 on Mon Jul 24 19:32:43 2017
RTM_DELETE: Delete Route: len 176, priority 1, table 0, ifidx 7, pid: 0, seq 0, 
errno 0
flags:<HOST,DONE,BROADCAST>
fmask:
use:0   mtu:0expire:0
locks:  inits:
sockaddrs: <DST,GATEWAY,IFP,IFA>
 10.0.20.255 10.0.20.1 00:00:5e:00:01:17 10.0.20.1
got message of size 192 on Mon Jul 24 19:32:43 2017
RTM_DELETE: Delete Route: len 192, priority 1, table 0, ifidx 7, pid: 0, seq 0, 
errno 0
flags:<HOST,DONE,LOCAL>
fmask:
use:0   mtu:0expire:0
locks:  inits:
sockaddrs: <DST,GATEWAY,IFP,IFA>
 10.0.20.1 00:00:5e:00:01:17 00:00:5e:00:01:17 10.0.20.1
got message of size 96 on Mon Jul 24 19:32:43 2017
RTM_DELADDR: address being removed from iface: len 96, metric 0, flags:
sockaddrs: <NETMASK,IFP,IFA,BRD>
 255.255.255.0 00:00:5e:00:01:17 10.0.20.1 10.0.20.255
got message of size 168 on Mon Jul 24 19:32:43 2017
RTM_IFINFO: iface status change: len 168, if# 7, name: carp2, link: invalid, 
mtu: 1500, flags:<BROADCAST,SIMPLEX,MULTICAST>
got message of size 104 on Mon Jul 24 19:32:43 2017
RTM_NEWADDR: address being added to iface: len 104, metric 0, flags:
sockaddrs: <NETMASK,IFP,IFA,BRD>
 255.255.255.0 00:00:5e:00:01:17 10.0.20.1 default
got message of size 192 on Mon Jul 24 19:32:43 2017
RTM_ADD: Add Route: len 192, priority 1, table 0, ifidx 7, pid: 0, seq 0, errno 0
flags:<UP,HOST,DONE,LLINFO,LOCAL>
fmask:
use:0   mtu:0expire:0
locks:  inits:
sockaddrs: <DST,GATEWAY,IFP,IFA>
 10.0.20.1 00:00:5e:00:01:17 00:00:5e:00:01:17 10.0.20.1
got message of size 192 on Mon Jul 24 19:32:43 2017
RTM_ADD: Add Route: len 192, priority 147, table 0, ifidx 7, pid: 0, seq 0, 
errno 0
flags:<DONE,CLONING,CONNECTED>
fmask:
use:0   mtu:0expire:0
locks:  inits:
sockaddrs: <DST,GATEWAY,NETMASK,IFP,IFA>
 10.0.20.0 10.0.20.1 255.255.255.0 00:00:5e:00:01:17 10.0.20.1
got message of size 176 on Mon Jul 24 19:32:43 2017
RTM_ADD: Add Route: len 176, priority 129, table 0, ifidx 7, pid: 0, seq 0, 
errno 0
flags:<HOST,DONE,BROADCAST>
fmask:
use:0   mtu:0expire:0
locks:  inits:
sockaddrs: <DST,GATEWAY,IFP,IFA>
 10.0.20.255 10.0.20.1 00:00:5e:00:01:17 10.0.20.1
got message of size 168 on Mon Jul 24 19:32:43 2017
RTM_IFINFO: iface status change: len 168, if# 7, name: carp2, link: backup, 
mtu: 1500, flags:<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST>
got message of size 168 on Mon Jul 24 19:32:46 2017
RTM_IFINFO: iface status change: len 168, if# 7, name: carp2, link: master, 
mtu: 1500, flags:<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST>

Re: ifconfig carpX a.b.c.d -> arpresolve: route contains no arp information

[Remi Locherer]

On 2017-07-10 17:52, Remi Locherer wrote:
Synopsis:	ifconfig carpX a.b.c.d -> arpresolve: route contains no arp 
information

Category:   kernel
Environment:

System  : OpenBSD 6.1
	Details : OpenBSD 6.1 (GENERIC.MP) #20: Sat Apr  1 13:45:56 MDT 
2017
			 
dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP


Architecture: OpenBSD.amd64
Machine : amd64


Description:

After reconfiguring an existing carp interface with the same ip the
gateway stops forwarding traffic (forwarding to directly connected
hosts still works).
In /var/log/messages this can be found:

Jul 10 12:54:27 gw1 /bsd: arpresolve: 10.0.20.10: route contains no
arp information



How-To-Repeat:


[...]


I can reproduce this problem with:
- OpenBSD 6.1 -release
- OpenBSD 6.1 -stable (all patches applied with syspatch)
- OpenBSD 6.1 -current (7.7.2017)

With OpenBSD 6.0 3 pings are lost after executing ifconfig and then 
packages

are forwarded again as expected.




Fix:

unknown. Workaround: route change 10.0.200.0/24 10.0.20.10



Somebody suggested in a private mail to use /32 masks for carp 
interfaces.

This fix/workaround helps indeed!

Re: ifconfig carpX a.b.c.d -> arpresolve: route contains no arp information

[Remi Locherer]

On 2017-07-12 11:34, Martin Pieuchot wrote:

On 11/07/17(Tue) 13:55, Remi Locherer wrote:

On 2017-07-11 13:23, Remi Locherer wrote:
> On 2017-07-11 11:32, Martin Pieuchot wrote:
> > Hello and thanks for the detailed bug report.
> >
> > On 10/07/17(Mon) 17:52, Remi Locherer wrote:
> > > >Synopsis:ifconfig carpX a.b.c.d -> arpresolve: route contains no arp 
information
> > > >Category:kernel
> > > >Environment:
> > >  System  : OpenBSD 6.1
> > >  Details : OpenBSD 6.1 (GENERIC.MP) #20: Sat Apr  1 13:45:56
> > > MDT 2017
> > >
> > > dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
> > >
> > >  Architecture: OpenBSD.amd64
> > >  Machine : amd64
> > >
> > > >Description:
> > >  After reconfiguring an existing carp interface with the same ip
> > > the gateway stops forwarding traffic (forwarding to directly
> > > connected hosts still works).
> > > In /var/log/messages this can be found:
> > >
> > > Jul 10 12:54:27 gw1 /bsd: arpresolve: 10.0.20.10: route contains
> > > no arp information
> >
> > How does the routing table looks like when you see such message?  And
> > the ARP table?


Somehow a route attached to vio2 is removed from the routing table when
you modify carp2.

Could you run 'route monitor' then do 'ifconfig carp2 delete'?  This
should hopefully reproduce the problem and the output of 'route 
monitor'

will give us more infos.


This is the output captured on 6.1-stable:

gw1# route monitor
got message of size 144 on Wed Jul 12 16:02:07 2017
RTM_DELETE: Delete Route: len 144, priority 3, table 0, ifidx 3, pid: 0, 
seq 0, errno 0

flags:<UP,HOST,DONE,LLINFO,CLONED,CACHED>
fmask:
use:0   mtu:0expire:0
locks:  inits:
sockaddrs: <DST,GATEWAY>
 10.0.20.10 08:00:27:6b:9a:c1
got message of size 192 on Wed Jul 12 16:02:07 2017
RTM_DELETE: Delete Route: len 192, priority 19, table 0, ifidx 7, pid: 
0, seq 0, errno 0

flags:<DONE,CLONING,CONNECTED>
fmask:
use:0   mtu:0expire:0
locks:  inits:
sockaddrs: <DST,GATEWAY,NETMASK,IFP,IFA>
 10.0.20.0 10.0.20.1 255.255.255.0 00:00:5e:00:01:17 10.0.20.1
got message of size 176 on Wed Jul 12 16:02:07 2017
RTM_DELETE: Delete Route: len 176, priority 1, table 0, ifidx 7, pid: 0, 
seq 0, errno 0

flags:<HOST,DONE,BROADCAST>
fmask:
use:0   mtu:0expire:0
locks:  inits:
sockaddrs: <DST,GATEWAY,IFP,IFA>
 10.0.20.255 10.0.20.1 00:00:5e:00:01:17 10.0.20.1
got message of size 192 on Wed Jul 12 16:02:07 2017
RTM_DELETE: Delete Route: len 192, priority 1, table 0, ifidx 7, pid: 0, 
seq 0, errno 0

flags:<HOST,DONE,LOCAL>
fmask:
use:0   mtu:0expire:0
locks:  inits:
sockaddrs: <DST,GATEWAY,IFP,IFA>
 10.0.20.1 00:00:5e:00:01:17 00:00:5e:00:01:17 10.0.20.1
got message of size 96 on Wed Jul 12 16:02:07 2017
RTM_DELADDR: address being removed from iface: len 96, metric 0, flags:
sockaddrs: <NETMASK,IFP,IFA,BRD>
 255.255.255.0 00:00:5e:00:01:17 10.0.20.1 10.0.20.255
got message of size 168 on Wed Jul 12 16:02:08 2017
RTM_IFINFO: iface status change: len 168, if# 7, name: carp2, link: 
invalid, mtu: 1500, flags:<BROADCAST,SIMPLEX,MULTICAST>

Re: ifconfig carpX a.b.c.d -> arpresolve: route contains no arp information

[Remi Locherer]

On 2017-07-11 13:23, Remi Locherer wrote:

On 2017-07-11 11:32, Martin Pieuchot wrote:

Hello and thanks for the detailed bug report.

On 10/07/17(Mon) 17:52, Remi Locherer wrote:

>Synopsis:   ifconfig carpX a.b.c.d -> arpresolve: route contains no arp 
information
>Category:   kernel
>Environment:
System  : OpenBSD 6.1
	Details : OpenBSD 6.1 (GENERIC.MP) #20: Sat Apr  1 13:45:56 MDT 
2017
			 
dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP


Architecture: OpenBSD.amd64
Machine : amd64

>Description:
	After reconfiguring an existing carp interface with the same ip the 
gateway stops forwarding traffic (forwarding to directly connected 
hosts still works).

In /var/log/messages this can be found:

Jul 10 12:54:27 gw1 /bsd: arpresolve: 10.0.20.10: route contains no 
arp information


How does the routing table looks like when you see such message?  And
the ARP table?


gw1# route -nv show -inet
Routing tables

Internet:
DestinationGatewayFlags   Refs  Use   Mtu
Prio Iface Label
default10.0.2.2   UGS0   22 - 8 
vio0
224/4  127.0.0.1  URS00 32768 8 
lo0
10.0.2/24  10.0.2.15  UCn10 - 4 
vio0
10.0.2.2   52:54:00:12:35:02  UHLch  2   16 - 3 
vio0
10.0.2.15  08:00:27:23:af:65  UHLl   04 - 1 
vio0
10.0.2.255 10.0.2.15  UHb00 - 1 
vio0
10.0.10/24 10.0.10.2  UCn11 - 4 
vio1
10.0.10/24 10.0.10.1  UCn00 -19 
carp1
10.0.10.1  00:00:5e:00:01:17  UHLl   00 - 1 
carp1
10.0.10.2  08:00:27:7d:87:23  UHLl   01 - 1 
vio1
10.0.10.10 08:00:27:1e:30:02  UHLc   0   93 - 3 
vio1
10.0.10.25510.0.10.2  UHb00 - 1 
vio1
10.0.10.25510.0.10.1  UHb00 - 1 
carp1
10.0.20/24 10.0.20.2  UCn02 - 4 
vio2
10.0.20/24 10.0.20.1  UCn00 -19 
carp2
10.0.20.1  00:00:5e:00:01:17  UHLl   00 - 1 
carp2
10.0.20.2  08:00:27:7e:f3:d5  UHLl   01 - 1 
vio2
10.0.20.25510.0.20.2  UHb00 - 1 
vio2
10.0.20.25510.0.20.1  UHb00 - 1 
carp2
10.0.200/2410.0.20.10 UGS0   89 - 8 
vio2
127/8  127.0.0.1  UGRS   00 32768 8 
lo0
127.0.0.1  127.0.0.1  UHhl   12 32768 1 
lo0

gw1# arp -an
Host Ethernet AddressNetif Expire   
 Flags

10.0.2.2 52:54:00:12:35:02vio0 19m32s
10.0.2.1508:00:27:23:af:65vio0 
permanent l
10.0.10.100:00:5e:00:01:17   carp1 
permanent l
10.0.10.208:00:27:7d:87:23vio1 
permanent l

10.0.10.10   08:00:27:1e:30:02vio1 18m31s
10.0.20.100:00:5e:00:01:17   carp2 
permanent l
10.0.20.208:00:27:7e:f3:d5vio2 
permanent l

gw1#


What happen if you destroy carp2 instead of re-adding the same 
address?

Do you see the same problem?


Not 100% the same. My ping also stops and the same message is printed
to /var/log/mesages.
But the gateway does not send "icmp: host 10.0.200.1 unreachable" to 
10.0.10.10.


I missed something here: In my test setup I have only a single gateway. 
After
destroying carp2 the ip 10.0.20.1 is not configured anywhere. But that 
ip is the
defautl gateway of the test client. That is why I do not see icmp 
unreachable

messages sent by the gw1.



The routing and arp table after destroying carp2:

gw1# ifconfig carp2 destroy
gw1# route -nv show -inet
Routing tables

Internet:
DestinationGatewayFlags   Refs  Use   Mtu
Prio Iface Label
default10.0.2.2   UGS0   26 - 8 
vio0
224/4  127.0.0.1  URS00 32768 8 
lo0
10.0.2/24  10.0.2.15  UCn10 - 4 
vio0
10.0.2.2   52:54:00:12:35:02  UHLch  2   20 - 3 
vio0
10.0.2.15  08:00:27:23:af:65  UHLl   04 - 1 
vio0
10.0.2.255 10.0.2.15  UHb00 - 1 
vio0
10.0.10/24 10.0.10.2  UCn11 - 4 
vio1
10.0.10/24 10.0.10.1  UCn00 -19 
carp1
10.0.10.1  00:00:5e:00:01:17  UHLl   00 - 1 
carp1
10.0.10.2  08:00:27:7d:87:23  UHLl   01 - 1 
vio1
10.0.10.

Re: ifconfig carpX a.b.c.d -> arpresolve: route contains no arp information

[Remi Locherer]

On 2017-07-11 11:32, Martin Pieuchot wrote:

Hello and thanks for the detailed bug report.

On 10/07/17(Mon) 17:52, Remi Locherer wrote:

>Synopsis:   ifconfig carpX a.b.c.d -> arpresolve: route contains no arp 
information
>Category:   kernel
>Environment:
System  : OpenBSD 6.1
	Details : OpenBSD 6.1 (GENERIC.MP) #20: Sat Apr  1 13:45:56 MDT 
2017
			 
dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP


Architecture: OpenBSD.amd64
Machine : amd64

>Description:
	After reconfiguring an existing carp interface with the same ip the 
gateway stops forwarding traffic (forwarding to directly connected 
hosts still works).

In /var/log/messages this can be found:

Jul 10 12:54:27 gw1 /bsd: arpresolve: 10.0.20.10: route contains no 
arp information


How does the routing table looks like when you see such message?  And
the ARP table?


gw1# route -nv show -inet
Routing tables

Internet:
DestinationGatewayFlags   Refs  Use   Mtu  Prio 
Iface Label
default10.0.2.2   UGS0   22 - 8 
vio0
224/4  127.0.0.1  URS00 32768 8 
lo0
10.0.2/24  10.0.2.15  UCn10 - 4 
vio0
10.0.2.2   52:54:00:12:35:02  UHLch  2   16 - 3 
vio0
10.0.2.15  08:00:27:23:af:65  UHLl   04 - 1 
vio0
10.0.2.255 10.0.2.15  UHb00 - 1 
vio0
10.0.10/24 10.0.10.2  UCn11 - 4 
vio1
10.0.10/24 10.0.10.1  UCn00 -19 
carp1
10.0.10.1  00:00:5e:00:01:17  UHLl   00 - 1 
carp1
10.0.10.2  08:00:27:7d:87:23  UHLl   01 - 1 
vio1
10.0.10.10 08:00:27:1e:30:02  UHLc   0   93 - 3 
vio1
10.0.10.25510.0.10.2  UHb00 - 1 
vio1
10.0.10.25510.0.10.1  UHb00 - 1 
carp1
10.0.20/24 10.0.20.2  UCn02 - 4 
vio2
10.0.20/24 10.0.20.1  UCn00 -19 
carp2
10.0.20.1  00:00:5e:00:01:17  UHLl   00 - 1 
carp2
10.0.20.2  08:00:27:7e:f3:d5  UHLl   01 - 1 
vio2
10.0.20.25510.0.20.2  UHb00 - 1 
vio2
10.0.20.25510.0.20.1  UHb00 - 1 
carp2
10.0.200/2410.0.20.10 UGS0   89 - 8 
vio2
127/8  127.0.0.1  UGRS   00 32768 8 
lo0
127.0.0.1  127.0.0.1  UHhl   12 32768 1 
lo0

gw1# arp -an
Host Ethernet AddressNetif Expire
Flags

10.0.2.2 52:54:00:12:35:02vio0 19m32s
10.0.2.1508:00:27:23:af:65vio0 permanent 
l
10.0.10.100:00:5e:00:01:17   carp1 permanent 
l
10.0.10.208:00:27:7d:87:23vio1 permanent 
l

10.0.10.10   08:00:27:1e:30:02vio1 18m31s
10.0.20.100:00:5e:00:01:17   carp2 permanent 
l
10.0.20.208:00:27:7e:f3:d5vio2 permanent 
l

gw1#



What happen if you destroy carp2 instead of re-adding the same address?
Do you see the same problem?


Not 100% the same. My ping also stops and the same message is printed to 
/var/log/mesages.
But the gateway does not send "icmp: host 10.0.200.1 unreachable" to 
10.0.10.10.


The routing and arp table after destroying carp2:

gw1# ifconfig carp2 destroy
gw1# route -nv show -inet
Routing tables

Internet:
DestinationGatewayFlags   Refs  Use   Mtu  Prio 
Iface Label
default10.0.2.2   UGS0   26 - 8 
vio0
224/4  127.0.0.1  URS00 32768 8 
lo0
10.0.2/24  10.0.2.15  UCn10 - 4 
vio0
10.0.2.2   52:54:00:12:35:02  UHLch  2   20 - 3 
vio0
10.0.2.15  08:00:27:23:af:65  UHLl   04 - 1 
vio0
10.0.2.255 10.0.2.15  UHb00 - 1 
vio0
10.0.10/24 10.0.10.2  UCn11 - 4 
vio1
10.0.10/24 10.0.10.1  UCn00 -19 
carp1
10.0.10.1  00:00:5e:00:01:17  UHLl   00 - 1 
carp1
10.0.10.2  08:00:27:7d:87:23  UHLl   01 - 1 
vio1
10.0.10.10 08:00:27:1e:30:02  UHLc   0  247 - 3 
vio1
10.0.10.25510.0.10.2  UHb00 - 1 
vio1
10.0.10.25510.0.10.1  UHb00 - 1 
carp1
10.0.20/24 10.0.20.2  UCn08 - 4 
vio2
10

ifconfig carpX a.b.c.d -> arpresolve: route contains no arp information

[Remi Locherer]

>Synopsis:  ifconfig carpX a.b.c.d -> arpresolve: route contains no arp 
>information
>Category:  kernel
>Environment:
System  : OpenBSD 6.1
Details : OpenBSD 6.1 (GENERIC.MP) #20: Sat Apr  1 13:45:56 MDT 2017
 
dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP

Architecture: OpenBSD.amd64
Machine : amd64

>Description:
After reconfiguring an existing carp interface with the same ip the 
gateway stops forwarding traffic (forwarding to directly connected hosts still 
works).
In /var/log/messages this can be found:

Jul 10 12:54:27 gw1 /bsd: arpresolve: 10.0.20.10: route contains no arp 
information


>How-To-Repeat:

Gateway configuration:

# pfctl -d
(it doesn't matter if pf is enabled or not to reproduce the problem)

# ifconfig
lo0: flags=8049 mtu 32768
index 5 priority 0 llprio 3
groups: lo
inet6 ::1 prefixlen 128
inet6 fe80::1%lo0 prefixlen 64 scopeid 0x5
inet 127.0.0.1 netmask 0xff00
vio0: flags=8843 mtu 1500
lladdr 08:00:27:23:af:65
index 1 priority 0 llprio 3
groups: egress
media: Ethernet autoselect
status: active
inet 10.0.2.15 netmask 0xff00 broadcast 10.0.2.255
vio1: flags=8b43 mtu 
1500
lladdr 08:00:27:7d:87:23
index 2 priority 0 llprio 3
media: Ethernet autoselect
status: active
inet 10.0.10.2 netmask 0xff00 broadcast 10.0.10.255
vio2: flags=8b43 mtu 
1500
lladdr 08:00:27:7e:f3:d5
index 3 priority 0 llprio 3
media: Ethernet autoselect
status: active
inet 10.0.20.2 netmask 0xff00 broadcast 10.0.20.255
enc0: flags=0<>
index 4 priority 0 llprio 3
groups: enc
status: active
carp1: flags=8843 mtu 1500
lladdr 00:00:5e:00:01:17
index 6 priority 15 llprio 3
carp: MASTER carpdev vio1 vhid 23 advbase 1 advskew 0
groups: carp
status: master
inet 10.0.10.1 netmask 0xff00 broadcast 10.0.10.255
carp2: flags=8843 mtu 1500
lladdr 00:00:5e:00:01:17
index 7 priority 15 llprio 3
carp: MASTER carpdev vio2 vhid 23 advbase 1 advskew 0
groups: carp
status: master
inet 10.0.20.1 netmask 0xff00 broadcast 10.0.20.255
pflog0: flags=141 mtu 33144
index 8 priority 0 llprio 3
groups: pflog

# route -n show -inet

Routing tables

Internet:
DestinationGatewayFlags   Refs  Use   Mtu  Prio Iface
default10.0.2.2   UGS0  514 - 8 vio0 
224/4  127.0.0.1  URS00 32768 8 lo0  
10.0.2/24  10.0.2.15  UCn10 - 4 vio0 
10.0.2.2   52:54:00:12:35:02  UHLch  2  412 - 3 vio0 
10.0.2.15  08:00:27:23:af:65  UHLl   04 - 1 vio0 
10.0.2.255 10.0.2.15  UHb00 - 1 vio0 
10.0.10/24 10.0.10.2  UCn11 - 4 vio1 
10.0.10/24 10.0.10.1  UCn00 -19 carp1
10.0.10.1  00:00:5e:00:01:17  UHLl   0   10 - 1 carp1
10.0.10.2  08:00:27:7d:87:23  UHLl   0   72 - 1 vio1 
10.0.10.10 08:00:27:1e:30:02  UHLc   0  320 - 3 vio1 
10.0.10.25510.0.10.2  UHb00 - 1 vio1 
10.0.10.25510.0.10.1  UHb00 - 1 carp1
10.0.20/24 10.0.20.2  UCn1   37 - 4 vio2 
10.0.20/24 10.0.20.1  UCn00 -19 carp2
10.0.20.1  00:00:5e:00:01:17  UHLl   00 - 1 carp2
10.0.20.2  08:00:27:7e:f3:d5  UHLl   02 - 1 vio2 
10.0.20.10 08:00:27:6b:9a:c1  UHLch  1   75 - 3 vio2 
10.0.20.25510.0.20.2  UHb00 - 1 vio2 
10.0.20.25510.0.20.1  UHb00 - 1 carp2
10.0.200/2410.0.20.10 UGS0  618 - 8 vio2 
127/8  127.0.0.1  UGRS   00 32768 8 lo0  
127.0.0.1  127.0.0.1  UHhl   12 32768 1 lo0  

# arp -an

Host Ethernet AddressNetif ExpireFlags
10.0.2.2 52:54:00:12:35:02vio0 19m59s
10.0.2.1508:00:27:23:af:65vio0 permanent l
10.0.10.100:00:5e:00:01:17   carp1 permanent l
10.0.10.2

ospf6d exits after ospf6ctl reload

[Remi Locherer]

Hi,

ospf6d does not like beeing reloaded and exits.

Below an example on -current running in VMM. I first noticed it
on an OpenBSD 6.0 amd64 router on real hardware.

Remi



r1# ifconfig -A
lo0: flags=8049 mtu 32768
index 3 priority 0 llprio 3
groups: lo
inet6 ::1 prefixlen 128
inet6 fe80::1%lo0 prefixlen 64 scopeid 0x3
inet 127.0.0.1 netmask 0xff00
vio0: flags=8b43 mtu 
1500
lladdr fe:e1:bb:d1:10:e1
index 1 priority 0 llprio 3
groups: egress
media: Ethernet autoselect
status: active
inet 192.168.250.101 netmask 0xff00 broadcast 192.168.250.255
inet6 fe80::fce1:bbff:fed1:10e1%vio0 prefixlen 64 scopeid 0x1
inet6 2001:db8::101 prefixlen 64
enc0: flags=0<>
index 2 priority 0 llprio 3
groups: enc
status: active
vether0: flags=8843 mtu 1500
lladdr fe:e1:ba:d0:08:cf
index 5 priority 0 llprio 3
groups: vether
media: Ethernet autoselect
status: active
inet6 fe80::fce1:baff:fed0:8cf%vether0 prefixlen 64 scopeid 0x5
inet6 2001:db8:a::101 prefixlen 64
r1#
r1# sysctl net.inet6.ip6.forwarding
net.inet6.ip6.forwarding=1
r1#
r1# cat /etc/ospf6d.conf
router-id 192.168.250.101

area 0.0.0.0 {
interface vio0
interface vether0 { passive }
}
r1#
r1#
r1# ospf6d -dv
if_newaddr: ifindex 3, addr fe80::1/64, dest ::
if_newaddr: ifindex 1, addr fe80::fce1:bbff:fed1:10e1/64
if_newaddr: ifindex 1, addr 2001:db8::101/64
if_newaddr: ifindex 5, addr fe80::fce1:baff:fed0:8cf/64
if_newaddr: ifindex 5, addr 2001:db8:a::101/64
startup
if_set_ipv6_checksum setting cksum offset to 12
orig_rtr_lsa: area 0.0.0.0
if_fsm: event UP resulted in action START and changing state for interface 
vether0 from DOWN to DOWN
if_join_group: interface vio0 addr ff02::5
orig_rtr_lsa: area 0.0.0.0
orig_link_lsa: interface vio0
if_fsm: event UP resulted in action START and changing state for interface vio0 
from DOWN to WAIT
orig_intra_lsa_net: area 0.0.0.0, interface vether0
orig_intra_lsa_net: area 0.0.0.0, interface vio0
orig_intra_lsa_rtr: area 0.0.0.0, interface vether0: 2001:db8:a::101/64
spf_calc: area 0.0.0.0 calculated
*(192.168.250.101, 0x2001, 0.0.0.0) cost 0 has nexthops []
nbr_fsm: event HELLO_RECEIVED resulted in action START_INACTIVITY_TIMER and 
changing state for neighbor ID 192.168.250.102 from DOWN to INIT
nbr_fsm: event 2_WAY_RECEIVED resulted in action EVAL and changing state for 
neighbor ID 192.168.250.102 from INIT to 2-WAY
if_act_elect: interface vio0 old dr none new dr 192.168.250.102, old bdr none 
new bdr 192.168.250.101
if_join_group: interface vio0 addr ff02::6
nbr_fsm: event ADJ_OK resulted in action EVAL and changing state for neighbor 
ID 192.168.250.102 from 2-WAY to EXSTA
orig_rtr_lsa: area 0.0.0.0
orig_rtr_lsa: area 0.0.0.0
orig_link_lsa: interface vio0
orig_link_lsa: link local address fe80::fce1:bbff:fed1:10e1
orig_link_lsa: prefix 2001:db8::
if_fsm: event BACKUPSEEN resulted in action ELECT and changing state for 
interface vio0 from WAIT to BCKUP
if_act_elect: interface vio0 old dr 192.168.250.102 new dr 192.168.250.102, old 
bdr 192.168.250.101 new bdr 192.168.250.101
if_fsm: event NEIGHBORCHANGE resulted in action ELECT and changing state for 
interface vio0 from BCKUP to BCKUP
orig_intra_lsa_net: area 0.0.0.0, interface vether0
orig_intra_lsa_net: area 0.0.0.0, interface vio0
orig_intra_lsa_rtr: area 0.0.0.0, interface vether0: 2001:db8:a::101/64
orig_intra_lsa_net: area 0.0.0.0, interface vether0
orig_intra_lsa_net: area 0.0.0.0, interface vio0
orig_intra_lsa_rtr: area 0.0.0.0, interface vether0: 2001:db8:a::101/64
orig_intra_lsa_rtr: area 0.0.0.0, interface vio0: 2001:db8::101/64
nbr_fsm: event NEGOTIATION_DONE resulted in action SNAPSHOT and changing state 
for neighbor ID 192.168.250.102 from EXSTA to SNAP
nbr_fsm: event SNAPSHOT_DONE resulted in action SNAPSHOT_DONE and changing 
state for neighbor ID 192.168.250.102 from SNAP to EXCHG
nbr_fsm: event EXCHANGE_DONE resulted in action EXCHANGE_DONE and changing 
state for neighbor ID 192.168.250.102 from EXCHG to LOAD
spf_calc: area 0.0.0.0 calculated
*(192.168.250.101, 0x2001, 0.0.0.0) cost 0 has nexthops []
 (192.168.250.102, 0x2001, 0.0.0.0) cost 16777215 has nexthops []
ospf6d: rt_calc: Intra-Area-Prefix LSA (192.168.250.102, 1) references 
non-existent Network LSA (192.168.250.102, 1)
orig_intra_lsa_net: area 0.0.0.0, interface vether0
orig_intra_lsa_net: area 0.0.0.0, interface vio0
orig_intra_lsa_rtr: area 0.0.0.0, interface vether0: 2001:db8:a::101/64
orig_intra_lsa_rtr: area 0.0.0.0, interface vio0: 2001:db8::101/64
orig_rtr_lsa: area 0.0.0.0
orig_rtr_lsa: transit net, interface vio0
nbr_fsm: event LOADING_DONE resulted in action NOTHING and changing state for 
neighbor ID 192.168.250.102 from LOAD to FULL
orig_intra_lsa_net: 

Fwd: Re: relayd's icmp check only works for a small number of hosts

[Remi Locherer]

forgot to add bugs@openbsd.org

Subject: Re: relayd's icmp check only works for a small number of hosts
Date: 2016-09-02 17:50
From: Remi Locherer <remi.loche...@relo.ch>
To: Reyk Floeter <r...@openbsd.org>

On 2016-09-02 16:51, Reyk Floeter wrote:

On Fri, Aug 19, 2016 at 04:31:10PM +0200, Remi Locherer wrote:

>Synopsis:   relayd's icmp check only works for a small number of hosts
>Category:   relayd
>Environment:
System  : OpenBSD 5.9
	Details : OpenBSD 5.9 (GENERIC.MP) #10: Wed Aug  3 13:46:07 CEST 
2016
			 
r...@stable-59-amd64.mtier.org:/binpatchng/work-binpatch59-amd64/src/sys/arch/amd64/compile/GENERIC.MP


Architecture: OpenBSD.amd64
Machine : amd64

>Description:
	relayd says 70 out of 104 hosts are not reachable via icmp. But ping 
on
the same host where relayd runs can reach all hosts with a rtt below 
1ms.


In the logs I see "210ms,icmp read timeout". But in relayd.conf a 
timeout

of 1000 is set.



All checks have to be completed before the next check interval.  With
that many tests, it can happen that relayd is not finished
sending/receiving all individual checks before the next interval;
missed hosts will be marked down.

You could try the following:

1. Increase the global interval.


With this in relayd.conf:
interval 300
timeout 6

relayd successfully checked 36 hosts and reported icmp response times 
between
4 and 6 ms. After 60s relayd reports "icmp read timeout" for the other 
68 hosts.


Sep  2 17:29:13 lb2 relayd[31358]: host 192.168.63.48, check icmp 
(60008ms,icmp read timeout), state unknown -> down, availability 0.00%


While it's true that a few hosts are down the majority of hosts answer
my manual pings within 0.600 ms.



2. Instead of testing the same hosts multiple times, you can use the
"parent" keyword to interhit the state from a tested hosts, eg.

table  {
10.1.1.1
}

table  {
10.1.1.1 parent 1
}

table  {
10.1.1.1 parent 1
}


I'll try this one. It's a bit tricky since I can only reference the
parent table by index and not by name. My relayd.conf is generated
and deployed with Ansible.

Re: relayd's icmp check only works for a small number of hosts

[Remi Locherer]

On 2016-09-01 00:27, Sebastian Benoit wrote:

Remi Locherer(remi.loche...@relo.ch) on 2016.08.19 16:31:10 +0200:

>Synopsis:   relayd's icmp check only works for a small number of hosts
>Category:   relayd
>Environment:
System  : OpenBSD 5.9
	Details : OpenBSD 5.9 (GENERIC.MP) #10: Wed Aug  3 13:46:07 CEST 
2016
			 
r...@stable-59-amd64.mtier.org:/binpatchng/work-binpatch59-amd64/src/sys/arch/amd64/compile/GENERIC.MP


Architecture: OpenBSD.amd64
Machine : amd64

>Description:
	relayd says 70 out of 104 hosts are not reachable via icmp. But ping 
on
the same host where relayd runs can reach all hosts with a rtt below 
1ms.


In the logs I see "210ms,icmp read timeout". But in relayd.conf a 
timeout

of 1000 is set.

Could this be related to the problem mentioned in the commit message 
of

src/usr.sbin/relayd/check_icmp.c rev 1.41?


i think you mean 1.40?


yes


try to increase

usr.sbin/relayd/relayd.h:93:#define ICMP_RCVBUF_SIZE 262144

and see if you can have more checks then.


I tried the values 524288 and 393216 for ICMP_RCVBUF_SIZE. For both 
values relayd tells me:


relayd_icmp_patch: icmp_setup: setsockopt: No buffer space available

And then it exits.

relayd's icmp check only works for a small number of hosts

[Remi Locherer]

>Synopsis:  relayd's icmp check only works for a small number of hosts
>Category:  relayd
>Environment:
System  : OpenBSD 5.9
Details : OpenBSD 5.9 (GENERIC.MP) #10: Wed Aug  3 13:46:07 CEST 
2016
 
r...@stable-59-amd64.mtier.org:/binpatchng/work-binpatch59-amd64/src/sys/arch/amd64/compile/GENERIC.MP

Architecture: OpenBSD.amd64
Machine : amd64

>Description:
relayd says 70 out of 104 hosts are not reachable via icmp. But ping on
the same host where relayd runs can reach all hosts with a rtt below 1ms.

In the logs I see "210ms,icmp read timeout". But in relayd.conf a timeout
of 1000 is set.

Could this be related to the problem mentioned in the commit message of
src/usr.sbin/relayd/check_icmp.c rev 1.41?

The latest errata patches for 5.9 are applied via the mtier pkgs.


relayd.conf:
# Global Options
interval 10
timeout 1000
log updates

# Tables
table  {
192.168.63.32
}
table  {
192.168.63.33
}
table  {
192.168.63.32
}
table  {
192.168.63.33
}
table  {
192.168.63.35
}
table  {
192.168.63.36
}
table  {
192.168.63.35
}
table  {
192.168.63.36
}
table  {
192.168.63.38
}
table  {
192.168.63.39
}
table  {
192.168.63.38
}
table  {
192.168.63.39
}
table  {
192.168.63.41
}
table  {
192.168.63.42
}
table  {
192.168.63.41
}
table  {
192.168.63.42
}
table  {
192.168.63.44
}
table  {
192.168.63.45
}
table  {
192.168.63.44
}
table  {
192.168.63.45
}
table  {
192.168.63.47
}
table  {
192.168.63.48
}
table  {
192.168.63.47
}
table  {
192.168.63.48
}
table  {
192.168.63.50
}
table  {
192.168.63.51
}
table  {
192.168.63.50
}
table  {
192.168.63.51
}
table  {
192.168.63.84
}
table  {
192.168.63.85
}
table  {
192.168.63.84
}
table  {
192.168.63.85
}
table  {
192.168.63.84
}
table  {
192.168.63.85
}
table  {
192.168.63.84
}
table  {
192.168.63.85
}
table  {
192.168.63.104
}
table  {
192.168.63.105
}
table  {
192.168.63.104
}
table  {
192.168.63.105
}
table  {
192.168.63.124
}
table  {
192.168.63.125
}
table  {
192.168.63.124
}
table  {
192.168.63.125
}
table  {
192.168.63.124
}
table  {
192.168.63.125
}
table  {
192.168.63.124
}
table  {
192.168.63.125
}
table  {
192.168.63.114
}
table  {
192.168.63.115
}
table  {
192.168.63.114
}
table  {
192.168.63.115
}
table  {
192.168.63.114
}
table  {
192.168.63.115
}
table  {
192.168.63.114
}
table  {
192.168.63.115
}
table  {
192.168.63.132
}
table  {
192.168.63.133
}
table  {
192.168.63.132
}
table  {
192.168.63.133
}
table  {
192.168.63.135
}
table  {
192.168.63.136
}
table  {
192.168.63.135
}
table  {
192.168.63.136
}
table  {
192.168.63.138
}
table  {
192.168.63.139
}
table  {
192.168.63.138
}
table  {
192.168.63.139
}
table  {
192.168.63.141
}
table  {
192.168.63.142
}
table  {
192.168.63.141
}
table  {
192.168.63.142
}
table  {
192.168.63.184
}
table  {
192.168.63.185
}
table  {
192.168.63.184
}
table  {
192.168.63.185
}
table  {
192.168.63.184
}
table  {
192.168.63.185
}
table  {
192.168.63.184
}
table  {
192.168.63.185
}
table  {
192.168.63.184
}
table  {
192.168.63.185
}
table  {
192.168.63.224
}
table  {
192.168.63.225
}
table  {
192.168.63.224
}
table  {
192.168.63.225
}
table  {
192.168.63.224
}
table  {
192.168.63.225
}
table  {
192.168.63.224
}
table  {
192.168.63.225
}
table  {
192.168.63.224
}
table  {
192.168.63.225
}
table  {
192.168.63.204
}
table  {
192.168.63.205
}
table  {
192.168.63.204
}
table  {
192.168.63.205
}
table  {
192.168.63.214
}
table  {
192.168.63.215
}
table  {
192.168.63.214
}
table  {
192.168.63.215
}
table  {
192.168.63.214
}
table  {
192.168.63.215
}
table  {
192.168.63.214
}
table  {
192.168.63.215
}

# Redirects
redirect test_acc_a_443 {
listen on 192.168.62.2 tcp port 443
session timeout 600
forward to  check icmp
forward to  check icmp
match pftag test_acc_a
}
redirect test_acc_a_9727 {
listen on 192.168.62.2 tcp port 9727
session timeout 600
forward to  check icmp
forward to  check icmp
match pftag test_acc_a
}
redirect test_acc_b_443 {
listen on 192.168.62.3 tcp port 443
session timeout 600
forward to  check icmp
forward to  

gzip does not set uid and gid anymore (because of pledge)

[Remi Locherer]

Hi

After upgrading a firewall to 5.9 I noticed that the ownership of logfiles
is not as I specified in newsyslog.conf. After newsyslog compressed the files
the ownership is always root:wheel.

I figured out that this is because gzip can not chown anymore since it was
pledged. The below patch fixes this.

Remi


Index: main.c
===
RCS file: /cvs/src/usr.bin/compress/main.c,v
retrieving revision 1.90
diff -u -p -r1.90 main.c
--- main.c  17 Oct 2015 21:34:07 -  1.90
+++ main.c  14 Jul 2016 05:40:35 -
@@ -167,7 +167,7 @@ main(int argc, char *argv[])
char outfile[PATH_MAX], _infile[PATH_MAX], suffix[16];
int bits, ch, error, rc, cflag, oflag;
 
-   if (pledge("stdio rpath wpath cpath fattr", NULL) == -1)
+   if (pledge("stdio rpath wpath cpath fattr chown", NULL) == -1)
err(1, "pledge");
 
bits = cflag = oflag = 0;

Re: bsd.rd from May 31 fails to load the firmware for iwm-7265-16

[Remi Locherer]

On Mon, Jun 20, 2016 at 12:18:30AM +0200, Stefan Sperling wrote:
> On Tue, Jun 07, 2016 at 01:10:34AM +0200, Theo Buehler wrote:
> > On Mon, Jun 06, 2016 at 03:09:34PM +0200, Stefan Sperling wrote:
> > > On Mon, Jun 06, 2016 at 02:15:35PM +0200, Remi Locherer wrote:
> > > > Today I built a bsd.rd with IWM_DEBUG. Now the iwm0 works as expected.
> > > 
> > > This indicates there is a race condition bug which is avoided
> > > by the additional time spent on printing data to the console.
> > > 
> > 
> > I could not get my 
> > 
> > iwm0 at pci2 dev 0 function 0 "Intel Dual Band Wireless AC 7265" rev 0x59, 
> > msi
> > 
> > to find a network, let alone associate with one at all (from bsd.rd).
> > 
> > Contrary to what kettenis@ reports, repeated up/down/up/scan/scan/scan
> > doesn't help.
> > 
> > As Remi reports, things work just fine when IWM_DEBUG is enabled.
> > 
> > I did some bisecting and it turns out that the last version that works
> > on bsd.rd is if_iwm.c -r1.81 (with the old firmware), -r1.82 which
> > made the transition to the new firmware stops working.
> > 
> > No problems whatsoever with GENERIC and GENERIC.MP
> 
> Remi, Mark, can you confirm that this diff fixes the problem for you?

I noticed that this is allready commited. So I did cvs up and built a
new release (with r 1.89 of if_iwm.c). iwm0 now works fine in bsd.rd.
Thanks!

Remi

Re: bsd.rd from May 31 fails to load the firmware for iwm-7265-16

[Remi Locherer]

On Sun, Jun 05, 2016 at 07:25:30PM +0200, Stefan Sperling wrote:
> On Sun, Jun 05, 2016 at 01:26:41PM +0200, Remi Locherer wrote:
> > On Sun, Jun 05, 2016 at 09:48:47AM +0200, Stefan Sperling wrote:
> > > On Sat, Jun 04, 2016 at 11:16:32PM +0200, Remi Locherer wrote:
> > > > On my installation the upgrade process looks like this (snapshot bsd.rd
> > > > from Jun 2):
> > >  
> > > > [...]
> > > 
> > > > iwm0: no link ... sleeping
> > > 
> > > > My /etc/hostname.iwm0:
> > > > 
> > > > nwid tsunami wpakey 
> > > > dhcp
> > > > inet6 autoconf
> > > > !pkill -9 -lf wifinwid
> > > > !/etc/wifinwid \$if &
> > > 
> > > Please add a 'debug' line at the top of your hostname.iwm0 file.
> > > That might reveal more of what's going on.
> > 
> > There is no additional output with debug in hostname.iwm0 when
> > booting bsd.rd (snapshot Jun 2). When booting bsd.mp I see that iwm0
> > does scanning and receives beacons and more.
> 
> Strange. ifconfig iwm0 debug definitely works in the ramdisk for me.
> 
> Can we set aside the install script and hostname.if magic for a while,
> and just determine whether your device works at all in bsd.rd?
> 
> Try the following:
> 
>   Boot bsd.rd
>   Select the (S)hell option
>   cd /dev
>   sh MAKEDEV sd1
>   mount /dev/sd1a /mnt   # for firmware
>   ifconfig iwm0 debug
>   ifconfig iwm0 scan
> 
> Repeat the scan command a few times. I expect that, at least after a few
> tries, you should see the same behaviour you would see with GENERIC.
> Is that not the case?
> 
> If the scan works, can you manually associate to a network and
> run dhclient iwm0? Does that work?
> 
> All of the above works for me.
> 
> > > Additionally, could you build a release with IWM_DEBUG defined
> > > in if_iwm.c and try bsd.rd from that? This would again print more.
> > 
> > I'll try that next. Is it correct that I need to put the below line
> > in sys/arch/amd64/conf/RAMDISK_CD?
> > 
> > option  IWM_DEBUG=1
> 
> I believe it would be just 'option IWM_DEBUG'.
> 
> You could also apply this patch.
> 
> Index: if_iwm.c
> ===
> RCS file: /cvs/src/sys/dev/pci/if_iwm.c,v
> retrieving revision 1.86
> diff -u -p -r1.86 if_iwm.c
> --- if_iwm.c  3 Jun 2016 16:16:25 -   1.86
> +++ if_iwm.c  5 Jun 2016 17:23:44 -
> @@ -148,6 +148,7 @@
>  #define le16_to_cpup(_a_) (le16toh(*(const uint16_t *)(_a_)))
>  #define le32_to_cpup(_a_) (le32toh(*(const uint32_t *)(_a_)))
>  
> +#define IWM_DEBUG
>  #ifdef IWM_DEBUG
>  #define DPRINTF(x)   do { if (iwm_debug > 0) printf x; } while (0)
>  #define DPRINTFN(n, x)   do { if (iwm_debug >= (n)) printf x; } while (0)

Today I built a bsd.rd with IWM_DEBUG. Now the iwm0 works as expected.
(dmesg below). These commands are what produced the below dmesg:

ifconfig iwm0
ifconfig iwm0 up
ifconfig iwm0
ifconfig iwm0 scan
ifconfig iwm0 nwid tsunami wpakey XXX
dhclient iwm0


So iwm0 did not work on my notebook with bsd.rd from snapshots (May 31 and 
Jun 2 tested).

It works fine with bsd.rd I built today (CVS up from Jun 6).

I have 1 modification in my local tree (Which I hope does not influence iwm
behaviour.):

Index: dsdt.c
===
RCS file: /cvs/src/sys/dev/acpi/dsdt.c,v
retrieving revision 1.223
diff -u -p -r1.223 dsdt.c
--- dsdt.c  8 May 2016 11:08:01 -   1.223
+++ dsdt.c  6 Jun 2016 12:04:27 -
@@ -1457,7 +1457,7 @@ struct aml_defval {
struct aml_value**gval;
 } aml_defobj[] = {
{ "_OS_", AML_OBJTYPE_STRING, -1, osstring },
-   { "_REV", AML_OBJTYPE_INTEGER, 2, NULL },
+   { "_REV", AML_OBJTYPE_INTEGER, 5, NULL },
{ "_GL", AML_OBJTYPE_MUTEX, 1, NULL, _global_lock },
{ "_OSI", AML_OBJTYPE_METHOD, 1, aml_callosi },



dmesg from bsd.rd:

OpenBSD 6.0-beta (RAMDISK_CD) #2: Mon Jun  6 13:16:55 CEST 2016
r...@mistral.relo.ch:/usr/src/sys/arch/amd64/compile/RAMDISK_CD
real mem = 8473636864 (8081MB)
avail mem = 8215109632 (7834MB)
mainbus0 at root
bios0 at mainbus0: SMBIOS rev. 2.8 @ 0xed7d0 (84 entries)
bios0: vendor Dell Inc. version "A07" date 11/11/2015
bios0: Dell Inc. XPS 13 9343
acpi0 at bios0: rev 2
acpi0: tables DSDT FACP APIC FPDT FIDT MCFG HPET SSDT UEFI SSDT ASF! SSDT SSDT 
SSDT SSDT PCCT SSDT SSDT SSDT SLIC MSDM DMAR CSRT BGRT
acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
cpu0 at mainbus0: apid 0 (boot processor)
cpu0: Intel(R) Core(TM) i5-5200U CPU @ 2.20GHz, 2494.58 MHz
cpu0

Re: bsd.rd from May 31 fails to load the firmware for iwm-7265-16

[Remi Locherer]

On Sun, Jun 05, 2016 at 09:48:47AM +0200, Stefan Sperling wrote:
> On Sat, Jun 04, 2016 at 11:16:32PM +0200, Remi Locherer wrote:
> > On my installation the upgrade process looks like this (snapshot bsd.rd
> > from Jun 2):
>  
> > [...]
> 
> > iwm0: no link ... sleeping
> 
> > My /etc/hostname.iwm0:
> > 
> > nwid tsunami wpakey 
> > dhcp
> > inet6 autoconf
> > !pkill -9 -lf wifinwid
> > !/etc/wifinwid \$if &
> 
> Please add a 'debug' line at the top of your hostname.iwm0 file.
> That might reveal more of what's going on.

There is no additional output with debug in hostname.iwm0 when
booting bsd.rd (snapshot Jun 2). When booting bsd.mp I see that iwm0
does scanning and receives beacons and more.

> Additionally, could you build a release with IWM_DEBUG defined
> in if_iwm.c and try bsd.rd from that? This would again print more.

I'll try that next. Is it correct that I need to put the below line
in sys/arch/amd64/conf/RAMDISK_CD?

option  IWM_DEBUG=1

> Is there a difference between cold boots (i.e. power up) and warm
> boots (i.e. reboots) to bsd.rd?

I could not find a difference.

Re: screen brightness resets

[Remi Locherer]

On Wed, Dec 16, 2015 at 09:32:14PM -0500, Ted Unangst wrote:
> Mark Kettenis wrote:
> > > From: "Ted Unangst" 
> > > Date: Wed, 09 Dec 2015 06:49:42 -0500
> > > 
> > > Thinkpad X1 2015 (broadwell). This is a recent regression, though I'm not 
> > > sure
> > > when it was introduced. I have lidsuspend=0. When I close the lid and 
> > > open it
> > > again, the screen comes back at 100% brightness. As in, far too bright.
> > > 
> > > Previously, the screen would always open back up at the same brightness 
> > > level
> > > I closed it at. kettenis mentioned that the keyboard brightness keys work
> > > (they do) but that's a recent addition. For many months, they did not. I
> > > wonder if the changes are correlated.
> > 
> > They probably are.  And probably the weird behaviour of the brightness
> > keys is related as well.  See my rants about ACPI being fucked because
> > we claim to support both Windows 7 and Windows 8.  My suggestion would
> > be to comment out most of the Windows versions in the "aml_valid_osi"
> > array and see how the behaviour changes if you only enable the
> > "Windows 2012", "Windows 2009" or "Windows 2006" entry.
> 
> It took a while to get around to it, but I'm now running with the diff below
> and things seem much more sensible. The brightness controls still work, but
> things don't reset every time I add or remove power.
> 
> 
> Index: acpi/dsdt.c
> ===
> RCS file: /cvs/src/sys/dev/acpi/dsdt.c,v
> retrieving revision 1.218
> diff -u -p -r1.218 dsdt.c
> --- acpi/dsdt.c   20 Aug 2015 20:50:10 -  1.218
> +++ acpi/dsdt.c   9 Dec 2015 14:06:50 -
> @@ -1,4 +1,4 @@
> -/* $OpenBSD: dsdt.c,v 1.218 2015/08/20 20:50:10 kettenis Exp $ */
> +/* $OpenBSD: dsdt.c,v 1.217 2015/05/04 10:42:06 jmatthew Exp $ */
>  /*
>   * Copyright (c) 2005 Jordan Hargrave 
>   *
> @@ -1476,18 +1476,7 @@ struct aml_defval {
>   * We return True for Windows to fake out nasty bad AML
>   */
>  char *aml_valid_osi[] = {
> - "Windows 2000",
> - "Windows 2001",
> - "Windows 2001.1",
> - "Windows 2001 SP0",
> - "Windows 2001 SP1",
> - "Windows 2001 SP2",
> - "Windows 2001 SP3",
> - "Windows 2001 SP4",
> - "Windows 2006",
>   "Windows 2009",
> - "Windows 2012",
> - "Windows 2013",
>   NULL
>  };
>  

With this patch the brightnes keys on Dell XPS 13 9343 work. Also
audio works with this patch.

Before I had a different patch applied to make audio work on this notebook.
See https://marc.info/?l=openbsd-misc=144277570223298=2

Remi


OpenBSD 5.8-current (GENERIC.MP) #18: Thu Dec 17 07:49:38 CET 2015
r...@mistral.relo.ch:/usr/src/sys/arch/amd64/compile/GENERIC.MP
real mem = 8168812544 (7790MB)
avail mem = 7917084672 (7550MB)
mpath0 at root
scsibus0 at mpath0: 256 targets
mainbus0 at root
bios0 at mainbus0: SMBIOS rev. 2.8 @ 0xed7d0 (84 entries)
bios0: vendor Dell Inc. version "A07" date 11/11/2015
bios0: Dell Inc. XPS 13 9343
acpi0 at bios0: rev 2
acpi0: sleep states S0 S3 S4 S5
acpi0: tables DSDT FACP APIC FPDT FIDT MCFG HPET SSDT UEFI SSDT ASF! SSDT SSDT 
SSDT SSDT PCCT SSDT SSDT SSDT SLIC MSDM DMAR CSRT
acpi0: wakeup devices PEGP(S4) PEG0(S4) PEGP(S4) PEG1(S4) PEGP(S4) PEG2(S4) 
PXSX(S4) RP01(S4) PXSX(S4) RP02(S4) PXSX(S4) RP03(S4) PXSX(S4) RP04(S4) 
PXSX(S4) RP05(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-5200U CPU @ 2.20GHz, 2494.61 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,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,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,RDSEED,ADX,SMAP,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 99MHz
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-5200U CPU @ 2.20GHz, 2494.23 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,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,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,RDSEED,ADX,SMAP,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-5200U CPU @ 2.20GHz, 2494.23 MHz
cpu2: 

Elantech Clickpad (pms0) stopped working on current

[Remi Locherer]

Synopsis:  Elantech Clickpad (pms0) stopped working on current
Category:  kernel
Environment:
System  : OpenBSD 5.7
Details : OpenBSD 5.7-current (GENERIC.MP) #1046: Fri Jun  5 
13:25:01 MDT 2015
 
dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP

Architecture: OpenBSD.amd64
Machine : amd64
Description:
When I try to use the touchpad on my noteboot the below messages are
shown in xconsole and dmesg. The mouse pointer does not react anymore to
movements on the touchpad.

Affected devic:
pms0: Elantech Clickpad, version 4, firmware 0x575f03

I first noticed this with the snapshot kernel from May 31. With the kernel
from June 5 it's the same. The touchpad was working fine with the snapshot
from May 23.

pms0: not in sync yet, discard input (state 0)
pms0: not in sync yet, discard input (state 0)
pms0: unknown packet type 0x1
pms0: unknown packet type 0x1
pms0: unknown packet type 0x1
pms0: unknown packet type 0x1
pms0: unknown packet type 0x1
pms0: unknown packet type 0x1
pms0: not in sync yet, discard input (state 0)
pms0: unknown packet type 0x3
pms0: unknown packet type 0x3
pms0: unknown packet type 0x3
pms0: unknown packet type 0x13
pms0: unknown packet type 0x3
pms0: unknown packet type 0x3
pms0: unknown packet type 0x3
pms0: unknown packet type 0x13
pms0: unknown packet type 0x3
pms0: not in sync yet, discard input (state 0)
pms0: not in sync yet, discard input (state 0)
pms0: not in sync yet, discard input (state 0)
pms0: not in sync yet, discard input (state 0)
pms0: not in sync yet, discard input (state 0)
pms0: unknown packet type 0x18
pms0: unknown packet type 0x18
pms0: unknown packet type 0x18
pms0: unknown packet type 0x8
pms0: unknown packet type 0x18
pms0: unknown packet type 0x18
pms0: unknown packet type 0x8
pms0: unknown packet type 0x18
pms0: not in sync yet, discard input (state 0)
pms0: not in sync yet, discard input (state 0)
pms0: unknown packet type 0x5
pms0: unknown packet type 0x5
pms0: unknown packet type 0x5
pms0: unknown packet type 0x5
pms0: unknown packet type 0x5
pms0: unknown packet type 0x5
pms0: unknown packet type 0x5
pms0: unknown packet type 0x5
pms0: not in sync yet, discard input (state 0)
pms0: not in sync yet, discard input (state 0)
pms0: unknown packet type 0x15
pms0: unknown packet type 0x15
pms0: unknown packet type 0x1
pms0: unknown packet type 0x1
pms0: unknown packet type 0x1
pms0: not in sync yet, discard input (state 0)
pms0: not in sync yet, discard input (state 0)
pms0: not in sync yet, discard input (state 0)



How-To-Repeat:
Use an Elantech Clickpad, version 4, firmware 0x575f03 with
snapshot from June 5.

Fix:
Workaround: use snapshot from May 23.


dmesg:
OpenBSD 5.7-current (GENERIC.MP) #1046: Fri Jun  5 13:25:01 MDT 2015
dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
real mem = 3881746432 (3701MB)
avail mem = 3760226304 (3586MB)
mpath0 at root
scsibus0 at mpath0: 256 targets
mainbus0 at root
bios0 at mainbus0: SMBIOS rev. 2.7 @ 0xe0970 (63 entries)
bios0: vendor Phoenix Technologies Ltd. version P00ACX date 04/26/2013
bios0: SAMSUNG ELECTRONICS CO., LTD. 900X3F
acpi0 at bios0: rev 2
acpi0: sleep states S0 S3 S4 S5
acpi0: tables DSDT FACP SLIC SSDT ASF! HPET APIC MCFG FPDT SSDT SSDT UEFI MSDM 
UEFI UEFI
acpi0: wakeup devices P0P1(S4) GLAN(S4) XHC_(S4) HDEF(S4) PXSX(S4) RP01(S4) 
PXSX(S4) RP02(S4) PXSX(S4) RP03(S4) PXSX(S4) RP04(S4) PXSX(S4) RP06(S4) 
PXSX(S4) RP07(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-3337U CPU @ 1.80GHz, 1696.39 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,XSAVE,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 1 (application processor)
cpu1: Intel(R) Core(TM) i5-3337U CPU @ 1.80GHz, 1696.15 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,XSAVE,AVX,F16C,RDRAND,NXE,LONG,LAHF,PERF,ITSC,FSGSBASE,SMEP,ERMS,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-3337U CPU @ 1.80GHz, 1696.15 MHz
cpu2: 

Re: Elantech Clickpad (pms0) stopped working on current

[Remi Locherer]

On Sat, Jun 06, 2015 at 10:47:19AM +0200, Stefan Sperling wrote:
 On Sat, Jun 06, 2015 at 10:21:59AM +0200, Remi Locherer wrote:
  Synopsis:  Elantech Clickpad (pms0) stopped working on current
  Category:  kernel
  Environment:
  System  : OpenBSD 5.7
  Details : OpenBSD 5.7-current (GENERIC.MP) #1046: Fri Jun  5 
  13:25:01 MDT 2015
   
  dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
  
  Architecture: OpenBSD.amd64
  Machine : amd64
  Description:
  When I try to use the touchpad on my noteboot the below messages are
  shown in xconsole and dmesg. The mouse pointer does not react anymore to
  movements on the touchpad.
  
  Affected devic:
  pms0: Elantech Clickpad, version 4, firmware 0x575f03
  
  I first noticed this with the snapshot kernel from May 31. With the kernel
  from June 5 it's the same. The touchpad was working fine with the snapshot
  from May 23.
 
 This was probably caused by pms.c commit r1.61 which enabled touchpad
 support for newer elantech devices using firmware versions 0xX8.
 
 Your device (firmware version 0xX7) was not matched before but matches
 now because of the way the new matching check was written. Can you try this
 diff to see if it restores previous behaviour for your device?


After applying this patch I can use the touchpad again. Thanks!


 Index: pms.c
 ===
 RCS file: /cvs/src/sys/dev/pckbc/pms.c,v
 retrieving revision 1.61
 diff -u -p -r1.61 pms.c
 --- pms.c 25 May 2015 15:04:26 -  1.61
 +++ pms.c 6 Jun 2015 08:37:41 -
 @@ -1840,7 +1840,8 @@ elantech_get_hwinfo_v4(struct pms_softc 
   if (synaptics_query(sc, ELANTECH_QUE_FW_VER, fw_version))
   return (-1);
  
 - if (((fw_version  0x0f)  16)  6)
 + if (((fw_version  0x0f)  16) != 6 
 + (fw_version  0x0f)  16 != 8)
   return (-1);
  
   elantech-fw_version = fw_version;
 

system freeze: acpicpu setperf failed to alter frequency

[Remi Locherer]

Synopsis:  system freeze: acpicpu setperf failed to alter frequency
Category:  kernel
Environment:
System  : OpenBSD 5.7
Details : OpenBSD 5.7 (GENERIC) #0: Thu Apr 30 22:01:01 CEST 2015
 
r...@stable-57-amd64.mtier.org:/binpatchng/work-binpatch57-amd64/src/sys/arch/amd64/compile/GENERIC

Architecture: OpenBSD.amd64
Machine : amd64

Description:
After executing the command sysctl hw the server freezes without
dropping me to ddb. With OpenBSD 5.6 sysctl hw was working fine on this
hardware. It happens with 5.7 and -current mp kernels. sp kernels work as
expected.

Output from the serial console (with different kernel versions):

OpenBSD 5.7 (GENERIC.MP) #0: Thu Apr 30 21:56:27 CEST 2015
r...@stable-57-amd64.mtier.org:/binpatchng/work-binpatch57-amd64/src/sys/arc
h/amd64/compile/GENERIC.MP

root@hurricane# sysctl hw
hw.machine=amd64CPU3: acpicpu setperf failed to alter frequency

hw.model=Intel
--
root@hurricane# sysctl kern.version
kern.version=OpenBSD 5.7 (GENERIC.MP) #881: Sun Mar  8 11:04:17 MDT 2015
dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP

root@hurricane# sysctl hw
hw.machine=amd64
hCw.model=IntelPU1: acpicpu setperf failed to alter frequency
(R)
--
dtse9# sysctl kern.version
kern.version=OpenBSD 5.7-current (GENERIC.MP) #1021: Thu May 28 19:38:27 MDT 201
5
dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP

dtse9# sysctl hw
hw.machine=amd64
hw.model=Intel(R) Xeon(R) CPU E5440 @ 2.83GHz
hw.ncpu=8
hw.byteorder=1234
hw.pagesize=4096
hw.disknames=sd


I have access to a similar server: HP ProLiant DL360 G5 with only one 
quadcore cpu installed (Intel Xeon E5335). There this problem does not
appear.


How-To-Repeat:
Install OpenBSD 5.7 amd64 on a HP ProLiant DL360 G5 with two 
Intel Xeon E5440 cpus. Then do sysctl hw.

Workaround:
Run an sp kernel instead of mp.

dmesg:
OpenBSD 5.7 (GENERIC) #0: Thu Apr 30 22:01:01 CEST 2015

r...@stable-57-amd64.mtier.org:/binpatchng/work-binpatch57-amd64/src/sys/arch/amd64/compile/GENERIC
real mem = 25751203840 (24558MB)
avail mem = 25061834752 (23900MB)
mpath0 at root
scsibus0 at mpath0: 256 targets
mainbus0 at root
bios0 at mainbus0: SMBIOS rev. 2.4 @ 0xee000 (69 entries)
bios0: vendor HP version P58 date 05/02/2011
bios0: HP ProLiant DL360 G5
acpi0 at bios0: rev 2
acpi0: sleep states S0 S4 S5
acpi0: tables DSDT FACP SPCR MCFG HPET SPMI ERST APIC  BERT HEST SSDT
acpi0: wakeup devices PCI0(S5)
acpitimer0 at acpi0: 3579545 Hz, 24 bits
acpimcfg0 at acpi0 addr 0xe000, bus 0-255
acpihpet0 at acpi0: 14318179 Hz
acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
cpu0 at mainbus0: apid 0 (boot processor)
cpu0: Intel(R) Xeon(R) CPU E5440 @ 2.83GHz, 2833.77 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,EST,TM2,SSSE3,CX16,xTPR,PDCM,DCA,SSE4.1,XSAVE,NXE,LONG,LAHF,PERF
cpu0: 6MB 64b/line 16-way L2 cache
cpu0: smt 0, core 0, package 0
mtrr: Pentium Pro MTRR support, 8 var ranges, 88 fixed ranges
cpu0: apic clock running at 333MHz
cpu at mainbus0: not configured
cpu at mainbus0: not configured
cpu at mainbus0: not configured
cpu at mainbus0: not configured
cpu at mainbus0: not configured
cpu at mainbus0: not configured
cpu at mainbus0: not configured
ioapic0 at mainbus0: apid 8 pa 0xfec0, version 20, 24 pins
ioapic1 at mainbus0: apid 9 pa 0xfec8, version 20, 24 pins
acpiprt0 at acpi0: bus 1 (IP2P)
acpiprt1 at acpi0: bus 11 (IPE1)
acpiprt2 at acpi0: bus 10 (IPE4)
acpiprt3 at acpi0: bus 16 (P2P2)
acpiprt4 at acpi0: bus 9 (PT02)
acpiprt5 at acpi0: bus 6 (PT03)
acpiprt6 at acpi0: bus 19 (PT04)
acpiprt7 at acpi0: bus 3 (NB01)
acpiprt8 at acpi0: bus 5 (NB02)
acpiprt9 at acpi0: bus 0 (PCI0)
acpicpu0 at acpi0: C3, C1, FVS, 2832, 2332, 1999 MHz
acpitz0 at acpi0: critical temperature is 31 degC
ipmi at mainbus0 not configured
pci0 at mainbus0 bus 0
pchb0 at pci0 dev 0 function 0 Intel 5000P Host rev 0xb1
ppb0 at pci0 dev 2 function 0 Intel 5000 PCIE rev 0xb1
pci1 at ppb0 bus 9
ppb1 at pci1 dev 0 function 0 Intel 6321ESB PCIE rev 0x01
pci2 at ppb1 bus 10
ppb2 at pci2 dev 0 function 0 Intel 6321ESB PCIE rev 0x01
pci3 at ppb2 bus 11
ppb3 at pci2 dev 1 function 0 Intel 6321ESB PCIE rev 0x01
pci4 at ppb3 bus 14
ppb4 at pci2 dev 2 function 0 Intel 6321ESB PCIE rev 0x01
pci5 at ppb4 bus 15
ppb5 at pci1 dev 0 function 3 Intel 6321ESB PCIE-PCIX rev 0x01
pci6 at ppb5 bus 16
ppb6 at pci0 dev 3 function 0 Intel 5000 PCIE rev 0xb1
pci7 at ppb6 bus 6
ciss0 at pci7 dev 0 function 0 Hewlett-Packard Smart Array rev 0x04: apic 8 
int 16
ciss0: 1 LD, HW rev 4, FW 7.24/7.24, 64bit fifo
scsibus1 at ciss0: 1 targets
sd0 at scsibus1 targ 0 lun 0: HP, LOGICAL VOLUME, 7.24 SCSI3 0/direct fixed
sd0: 2861512MB, 512 bytes/sector, 5860378032 sectors
ppb7 at pci0 dev 4 function 0 Intel 5000 PCIE x8 rev 0xb1
pci8 at ppb7 bus 19
ppb8 at 

Re: crash on urtwn removal

[Remi Locherer]

On Tue, Apr 28, 2015 at 01:41:29PM +0200, Martin Pieuchot wrote:
 On 28/04/15(Tue) 13:15, Remi Locherer wrote:
  On Tue, Apr 28, 2015 at 10:17:16AM +0200, Martin Pieuchot wrote:
   On 27/04/15(Mon) 22:45, Remi Locherer wrote:
On Mon, Apr 27, 2015 at 03:13:06PM +0200, Martin Pieuchot wrote:
 This trace tells use that the pipe is no longer valid, which means 
 that
 the device has been removed but a xfer is still referenced by ehci.
 
 The output of ps could help understand what's going wrong in such
 case.  If you can, please get it next time :)
 
 If you think you can reproduce this bug too, here's a diff that would
 get us a useful trace:

It seams to be easier to trigger this bug than the first one.
   
   What did you do to trigger it?
  
  While lynx was loading a website (via ipv6) I unplugged the urtwn device.
  The panic doesn't happen every time I try this. Maybe every 10th time.
 
 What I don't understand is that your trace shows that the process
 triggering the panic is doing an ioctl(2).  In your ps output you
 have ifconfig running, but since you did ps on CPU3 I can only
 guess that that's the program who triggered the panic.

Should I run ps on all CPUs next time? Or better on the cpu that is 
active at the beginning of the ddb session?
 
 So did you unplugged the device while doing anything with ifconfig?

I'm using Bob's wifinwid script which does this:

while :; do
(ifconfig $1 | grep 'status: active'  /dev/null)
if [ $? -ne 0 ]; then
[...]
sleep 2
fi
done

Full script: http://foad2.obtuse.com/beck/wifinwid

 Where you able to use your device before the kernel crashes?  Did you
 see anything in the dmesg before?  

Before I unplugged the urtwn I could use it normaly. I didn't noticed
any messages on the console but didn't check dmesg befor I unplugged urtwn.

 I understand that you unplugged the device, but the important parts
 are what did you do *before* or *during* 8)
 
Besides lynx in the foreground on the console the wifinwid script and
offlineimap (python) were active in the background.

Re: crash on urtwn removal

[Remi Locherer]

On Tue, Apr 28, 2015 at 10:17:16AM +0200, Martin Pieuchot wrote:
 On 27/04/15(Mon) 22:45, Remi Locherer wrote:
  On Mon, Apr 27, 2015 at 03:13:06PM +0200, Martin Pieuchot wrote:
   This trace tells use that the pipe is no longer valid, which means that
   the device has been removed but a xfer is still referenced by ehci.
   
   The output of ps could help understand what's going wrong in such
   case.  If you can, please get it next time :)
   
   If you think you can reproduce this bug too, here's a diff that would
   get us a useful trace:
  
  It seams to be easier to trigger this bug than the first one.
 
 What did you do to trigger it?

While lynx was loading a website (via ipv6) I unplugged the urtwn device.
The panic doesn't happen every time I try this. Maybe every 10th time.

  ddb trace and ps output:
  
  https://relo.ch/urtwncrash_trace_part1.jpg
  https://relo.ch/urtwncrash_trace_part2.jpg
  https://relo.ch/urtwncrash_ps_part1.jpg
  https://relo.ch/urtwncrash_ps_part2.jpg
  
  Unfortunately boot reboot in ddb did not work so I had to upload 
  the photos. But at least one line number appeared in the output so now I
  know how to build a kernel with debug symbols ;)
  
  
   
   Index: usbdi.c
   ===
   RCS file: /cvs/src/sys/dev/usb/usbdi.c,v
   retrieving revision 1.81
   diff -u -p -r1.81 usbdi.c
   --- usbdi.c   14 Mar 2015 03:38:50 -  1.81
   +++ usbdi.c   27 Apr 2015 13:08:33 -
   @@ -824,10 +824,8 @@ usb_insert_transfer(struct usbd_xfer *xf
 DPRINTFN(5,(usb_insert_transfer: pipe=%p running=%d timeout=%d\n,
 pipe, pipe-running, xfer-timeout));
#ifdef DIAGNOSTIC
   - if (xfer-busy_free != XFER_FREE) {
   - printf(%s: xfer=%p not free\n, __func__, xfer);
   - return (USBD_INVAL);
   - }
   + if (xfer-busy_free != XFER_FREE)
   + panic(%s: xfer=%p not free\n, __func__, xfer);
 xfer-busy_free = XFER_ONQU;
#endif
 s = splusb();
   
  
 

Re: crash on urtwn removal

[Remi Locherer]

On Mon, Apr 27, 2015 at 03:13:06PM +0200, Martin Pieuchot wrote:
 On 27/04/15(Mon) 13:55, Remi Locherer wrote:
  On Sun, Apr 26, 2015 at 10:07:19AM +0200, Stefan Sperling wrote:
   On Sun, Apr 26, 2015 at 09:36:06AM +0200, Remi Locherer wrote:
  With a series of removals and insertions of the urtwn device I could
  provoke another panic. I didn't wait for a timeout message to apear.
 
 Great !  You found another bug :)

Hmmm 
 
  [...]
  urtwn0 detached
  urtwn0 at uhub2 port 2 Realtek 802.11n WLAN Adapter rev 2.00/2.00 addr 3
  urtwn0: MAC/BB RTL8188CUS, RF 6052 1T1R, address 80:1f:02:da:13:e3
  usb_transfer_complete: actlen  len 4294951948  4
  usb_transfer_complete: actlen  len 4294951180  4
  usb_insert_transfer: xfer=0xff011a23e118 not free
 
 That's the real problem, some code path tries to reuse a xfer that's
 still on the ring.
 
  kernel: protection fault trap, code=0
  Stopped at  ehci_check_intr+0xb:movq0x10(%rax),%rax
  ddb{0} ehci_check_intr() at ehci_check_intr+0xb
  ehci_softintr() at ehci_softintr+0x3f
  softintr_dispatch() at softintr_dispatch+0x7f
  Xsoftnet() at Xsoftnet+0x2d
 
 This trace tells use that the pipe is no longer valid, which means that
 the device has been removed but a xfer is still referenced by ehci.
 
 The output of ps could help understand what's going wrong in such
 case.  If you can, please get it next time :)
 
 If you think you can reproduce this bug too, here's a diff that would
 get us a useful trace:

It seams to be easier to trigger this bug than the first one.
ddb trace and ps output:

https://relo.ch/urtwncrash_trace_part1.jpg
https://relo.ch/urtwncrash_trace_part2.jpg
https://relo.ch/urtwncrash_ps_part1.jpg
https://relo.ch/urtwncrash_ps_part2.jpg

Unfortunately boot reboot in ddb did not work so I had to upload 
the photos. But at least one line number appeared in the output so now I
know how to build a kernel with debug symbols ;)


 
 Index: usbdi.c
 ===
 RCS file: /cvs/src/sys/dev/usb/usbdi.c,v
 retrieving revision 1.81
 diff -u -p -r1.81 usbdi.c
 --- usbdi.c   14 Mar 2015 03:38:50 -  1.81
 +++ usbdi.c   27 Apr 2015 13:08:33 -
 @@ -824,10 +824,8 @@ usb_insert_transfer(struct usbd_xfer *xf
   DPRINTFN(5,(usb_insert_transfer: pipe=%p running=%d timeout=%d\n,
   pipe, pipe-running, xfer-timeout));
  #ifdef DIAGNOSTIC
 - if (xfer-busy_free != XFER_FREE) {
 - printf(%s: xfer=%p not free\n, __func__, xfer);
 - return (USBD_INVAL);
 - }
 + if (xfer-busy_free != XFER_FREE)
 + panic(%s: xfer=%p not free\n, __func__, xfer);
   xfer-busy_free = XFER_ONQU;
  #endif
   s = splusb();
 

Re: crash on urtwn removal

[Remi Locherer]

On Sun, Apr 26, 2015 at 10:07:19AM +0200, Stefan Sperling wrote:
 On Sun, Apr 26, 2015 at 09:36:06AM +0200, Remi Locherer wrote:
  Since a couple of month every now and then I'm getting a 
  urtwn0: device timeout. Usually I deal with it by unlugging the 
  urtwn device and plug it in again, then run sh /etc/netstart urtwn0.
 
 Is ifconfig down/up (or just 'sh /etc/netstart urtwn0') not enough?
 That is essentially what the driver should be doing in this situation.
 However, USB wifi drivers which need to load firmware currently don't
 reset properly when transmit times out -- they simply do nothing instead
 of resetting the interface.
 
 
  Sometimes the systems crashes when I unplug the urtwn device. 
  
  Photos from ddb after such a crash:
  
  https://relo.ch/crash_on_urtwn_removal-trace_part1.jpg
  https://relo.ch/crash_on_urtwn_removal-trace_part2.jpg
  https://relo.ch/crash_on_urtwn_removal-ps_part1.jpg
  https://relo.ch/crash_on_urtwn_removal-ps_part2.jpg
  https://relo.ch/crash_on_urtwn_removal-ps_part3.jpg
 
 Can you please recompile your kernel with
   makeoptions DEBUG=-g
 in the config when reproducing crashes? That's slightly more convenient
 for us to debug since ddb output will contain line numbers.

I rebuilt a kernel with /etc/mk.conf containing this:

SUDO=/usr/bin/sudo
DEBUG=-g
#DEBUGLIB=-g

But there are no line numbers in the ddb output (see end of dmesg). Is there
another why to build a kernel with debug symbols?
 
 Something is going wrong in the IPv6 code. This problem is not specific
 to urtwn(4). The relevant part of the trace is:

With a series of removals and insertions of the urtwn device I could
provoke another panic. I didn't wait for a timeout message to apear.

This time no nd6_* or in6_* are visible in the trace.

I updated kernel sources short before building the kernel.


OpenBSD 5.7-current (GENERIC.MP) #9: Sun Apr 26 21:27:24 CEST 2015
r...@mistral.relo.ch:/usr/src/sys/arch/amd64/compile/GENERIC.MP
real mem = 3881746432 (3701MB)
avail mem = 3760246784 (3586MB)
mpath0 at root
scsibus0 at mpath0: 256 targets
mainbus0 at root
bios0 at mainbus0: SMBIOS rev. 2.7 @ 0xe0970 (63 entries)
bios0: vendor Phoenix Technologies Ltd. version P00ACX date 04/26/2013
bios0: SAMSUNG ELECTRONICS CO., LTD. 900X3F
acpi0 at bios0: rev 2
acpi0: sleep states S0 S3 S4 S5
acpi0: tables DSDT FACP SLIC SSDT ASF! HPET APIC MCFG FPDT SSDT SSDT UEFI MSDM 
UEFI UEFI
acpi0: wakeup devices P0P1(S4) GLAN(S4) XHC_(S4) HDEF(S4) PXSX(S4) RP01(S4) 
PXSX(S4) RP02(S4) PXSX(S4) RP03(S4) PXSX(S4) RP04(S4) PXSX(S4) RP06(S4) 
PXSX(S4) RP07(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-3337U CPU @ 1.80GHz, 1696.44 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,XSAVE,AVX,F16C,RDRAND,NXE,LONG,LAHF,PERF,ITSC,FSGSBASE,SMEP,ERMS
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-3337U CPU @ 1.80GHz, 1696.15 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,XSAVE,AVX,F16C,RDRAND,NXE,LONG,LAHF,PERF,ITSC,FSGSBASE,SMEP,ERMS
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-3337U CPU @ 1.80GHz, 1696.15 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,XSAVE,AVX,F16C,RDRAND,NXE,LONG,LAHF,PERF,ITSC,FSGSBASE,SMEP,ERMS
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-3337U CPU @ 1.80GHz, 1696.15 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,XSAVE,AVX,F16C,RDRAND,NXE,LONG,LAHF,PERF,ITSC,FSGSBASE,SMEP,ERMS
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
acpiprt0 at acpi0: bus 0 (PCI0)
acpiprt1 at acpi0: bus -1 (P0P1)
acpiprt2 at acpi0: bus 1

crash on urtwn removal

[Remi Locherer]

Synopsis:  crash on urtwn removal
Environment:
System  : OpenBSD 5.7
Details : OpenBSD 5.7-current (GENERIC.MP) #955: Sat Apr 25 
20:12:31 MDT 2015
 
dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP

Architecture: OpenBSD.amd64
Machine : amd64

Description:
Since a couple of month every now and then I'm getting a 
urtwn0: device timeout. Usually I deal with it by unlugging the 
urtwn device and plug it in again, then run sh /etc/netstart urtwn0.

Sometimes the systems crashes when I unplug the urtwn device. 

Photos from ddb after such a crash:

https://relo.ch/crash_on_urtwn_removal-trace_part1.jpg
https://relo.ch/crash_on_urtwn_removal-trace_part2.jpg
https://relo.ch/crash_on_urtwn_removal-ps_part1.jpg
https://relo.ch/crash_on_urtwn_removal-ps_part2.jpg
https://relo.ch/crash_on_urtwn_removal-ps_part3.jpg


dmesg:
OpenBSD 5.7-current (GENERIC.MP) #955: Sat Apr 25 20:12:31 MDT 2015
dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
real mem = 3881746432 (3701MB)
avail mem = 3760242688 (3586MB)
mpath0 at root
scsibus0 at mpath0: 256 targets
mainbus0 at root
bios0 at mainbus0: SMBIOS rev. 2.7 @ 0xe0970 (63 entries)
bios0: vendor Phoenix Technologies Ltd. version P00ACX date 04/26/2013
bios0: SAMSUNG ELECTRONICS CO., LTD. 900X3F
acpi0 at bios0: rev 2
acpi0: sleep states S0 S3 S4 S5
acpi0: tables DSDT FACP SLIC SSDT ASF! HPET APIC MCFG FPDT SSDT SSDT UEFI MSDM 
UEFI UEFI
acpi0: wakeup devices P0P1(S4) GLAN(S4) XHC_(S4) HDEF(S4) PXSX(S4) RP01(S4) 
PXSX(S4) RP02(S4) PXSX(S4) RP03(S4) PXSX(S4) RP04(S4) PXSX(S4) RP06(S4) 
PXSX(S4) RP07(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-3337U CPU @ 1.80GHz, 1696.41 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,XSAVE,AVX,F16C,RDRAND,NXE,LONG,LAHF,PERF,ITSC,FSGSBASE,SMEP,ERMS
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-3337U CPU @ 1.80GHz, 1696.16 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,XSAVE,AVX,F16C,RDRAND,NXE,LONG,LAHF,PERF,ITSC,FSGSBASE,SMEP,ERMS
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-3337U CPU @ 1.80GHz, 1696.15 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,XSAVE,AVX,F16C,RDRAND,NXE,LONG,LAHF,PERF,ITSC,FSGSBASE,SMEP,ERMS
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-3337U CPU @ 1.80GHz, 1696.15 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,XSAVE,AVX,F16C,RDRAND,NXE,LONG,LAHF,PERF,ITSC,FSGSBASE,SMEP,ERMS
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
acpiprt0 at acpi0: bus 0 (PCI0)
acpiprt1 at acpi0: bus -1 (P0P1)
acpiprt2 at acpi0: bus 1 (RP01)
acpiprt3 at acpi0: bus -1 (RP02)
acpiprt4 at acpi0: bus -1 (RP03)
acpiprt5 at acpi0: bus 2 (RP04)
acpiprt6 at acpi0: bus 3 (RP05)
acpiprt7 at acpi0: bus -1 (RP06)
acpiprt8 at acpi0: bus -1 (RP07)
acpiprt9 at acpi0: bus -1 (RP08)
acpiprt10 at acpi0: bus -1 (PEG0)
acpiprt11 at acpi0: bus -1 (PEG1)
acpiprt12 at acpi0: bus -1 (PEG2)
acpiprt13 at acpi0: bus -1 (PEG3)
acpiec0 at acpi0
acpicpu0 at acpi0: C3, C2, C1, PSS
acpicpu1 at acpi0: C3, C2, C1, PSS
acpicpu2 at acpi0: C3, C2, C1, PSS
acpicpu3 at acpi0: C3, C2, C1, PSS
acpipwrres0 at acpi0: FN00, resource for FAN0
acpipwrres1 at acpi0: FN01, resource for FAN1
acpipwrres2 at acpi0: FN02, resource for FAN2
acpipwrres3 at acpi0: FN03, resource for FAN3
acpipwrres4 at acpi0: FN04, resource for FAN4
acpitz0 at acpi0: critical temperature is 106 degC
acpitz1 at acpi0: critical temperature is 106 degC
acpibat0 at acpi0: 

Re: crash on urtwn removal

[Remi Locherer]

On Sun, Apr 26, 2015 at 10:07:19AM +0200, Stefan Sperling wrote:
 On Sun, Apr 26, 2015 at 09:36:06AM +0200, Remi Locherer wrote:
  Since a couple of month every now and then I'm getting a 
  urtwn0: device timeout. Usually I deal with it by unlugging the 
  urtwn device and plug it in again, then run sh /etc/netstart urtwn0.
 
 Is ifconfig down/up (or just 'sh /etc/netstart urtwn0') not enough?

No, it's not enough. After the first timeout message on the console I
executed sh /etc/netstart urtwn0. The result was:

Console log for mistral.relo.ch
urtwn0: device timeout
usb_transfer_complete: actlen  len 4294951684  4
usb_transfer_complete: actlen  len 4294951044  4
usb_transfer_complete: actlen  len 4294951300  4
usb_transfer_complete: actlen  len 4294951308  4
urtwn0: device timeout
usb_transfer_complete: actlen  len 4294951300  4
urtwn0: device timeout
usb_transfer_complete: actlen  len 4294951308  4
urtwn0: device timeout
usb_transfer_complete: actlen  len 4294951948  4
usb_transfer_complete: actlen  len 4294951684  4
urtwn0: device timeout
usb_transfer_complete: actlen  len 4294951304  2
urtwn0: device timeout
usb_transfer_complete: actlen  len 4294951300  4
urtwn0: device timeout
usb_transfer_complete: actlen  len 4294951682  2
usb_transfer_complete: actlen  len 4294951300  4
urtwn0: device timeout
usb_transfer_complete: actlen  len 4294951300  4
usb_transfer_complete: actlen  len 4294951172  4
urtwn0: device timeout

My /etc/hostname.urtwn0:

nwid tsunami wpakey XXX
dhcp
inet6 autoconf
!pkill -9 -lf wifinwid
!/etc/wifinwid \$if 

The script is the one from here:
http://undeadly.org/cgi?action=articlesid=20130208141628


 That is essentially what the driver should be doing in this situation.
 However, USB wifi drivers which need to load firmware currently don't
 reset properly when transmit times out -- they simply do nothing instead
 of resetting the interface.
 
 
  Sometimes the systems crashes when I unplug the urtwn device. 
  
  Photos from ddb after such a crash:
  
  https://relo.ch/crash_on_urtwn_removal-trace_part1.jpg
  https://relo.ch/crash_on_urtwn_removal-trace_part2.jpg
  https://relo.ch/crash_on_urtwn_removal-ps_part1.jpg
  https://relo.ch/crash_on_urtwn_removal-ps_part2.jpg
  https://relo.ch/crash_on_urtwn_removal-ps_part3.jpg
 
 Can you please recompile your kernel with
   makeoptions DEBUG=-g
 in the config when reproducing crashes? That's slightly more convenient
 for us to debug since ddb output will contain line numbers.

I'll do that and report back.

 
 Something is going wrong in the IPv6 code. This problem is not specific
 to urtwn(4). The relevant part of the trace is:
 
 Stopped at find_pfxlist_reachable_router+0x15: movq 0x10(%eax),%rdi
 
 find_pfxlist_reachable_router()
 pfxlist_onlink_check()
 prelist_remove()
 nd6_purge()
 in6_ifdetach()
 if_detach()
 urtwn_detach()
 config_detach()
 usbd_detach()
 uhub_explore()
 uhub_explore()
 usb_explore()
 usb_task_thread()

Re: panic when using tun(4) with openvpn on current

[Remi Locherer]

On Wed, Apr 15, 2015 at 11:32:56AM +0200, Martin Pieuchot wrote:
 On 14/04/15(Tue) 22:49, Remi Locherer wrote:
  Synopsis:  panic when using tun(4) with openvpn on current
  Category:  kernel
  Environment:
  System  : OpenBSD 5.7
  Details : OpenBSD 5.7-current (GENERIC.MP) #919: Mon Apr 13 
  21:03:43 MDT 2015
   
  dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
  
  Architecture: OpenBSD.amd64
  Machine : amd64
  
  Description:
  
  I use openvpn which sets up a tun(4) interface. As soon as I start
  using the vpn (eg. with Firefox or lynx) the system panics.
 
 Thanks for the report, could you tell me if the fix below fix this
 regression?
 

I can now confirm that this patch fixes the panic.
Thank you for looking into this!

Remi

 
 Index: net/if_tun.c
 ===
 RCS file: /cvs/src/sys/net/if_tun.c,v
 retrieving revision 1.136
 diff -u -p -r1.136 if_tun.c
 --- net/if_tun.c  10 Apr 2015 13:58:20 -  1.136
 +++ net/if_tun.c  15 Apr 2015 09:29:52 -
 @@ -897,7 +897,7 @@ tunwrite(dev_t dev, struct uio *uio, int
   return (EAFNOSUPPORT);
   }
  
 - if (niq_enqueue(ifq, m) != 0) {
 + if (niq_enqueue(ifq, top) != 0) {
   ifp-if_collisions++;
   return (ENOBUFS);
   }
 

panic when using tun(4) with openvpn on current

[Remi Locherer]

Synopsis:  panic when using tun(4) with openvpn on current
Category:  kernel
Environment:
System  : OpenBSD 5.7
Details : OpenBSD 5.7-current (GENERIC.MP) #919: Mon Apr 13 
21:03:43 MDT 2015
 
dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP

Architecture: OpenBSD.amd64
Machine : amd64

Description:

I use openvpn which sets up a tun(4) interface. As soon as I start
using the vpn (eg. with Firefox or lynx) the system panics.

A trace from cpu3 in ddb showed this:

ddb{3} trace
Debugger() at Debugger+0x9
panic() at panic+0xfe
ipintr() at ipintr+0x3f
netintr() at netintr+0x85
softintr_dispatch() at softintr_dispatch+0x7f
Xsoftnet() at Xsoftnet+0x2d
--- interrupt ---
end trace frame: 0x0, count: -6
__ALLIGN_SIZE+0x1801:
ddb{3}

Pictures from ddb:
ps (part 1): https://relo.ch/tun-panic-ps1.jpg
ps (part 2): https://relo.ch/tun-panic-ps2.jpg
trace from all 4 cpus: https://relo.ch/tun-panic-trace.jpg

I first noticed it while running the snapshot from April 11.

After I start openvpn the active network configuration looks
like this:

# ifconfig
lo0: flags=8049UP,LOOPBACK,RUNNING,MULTICAST mtu 32768
priority: 0
groups: lo
inet6 fe80::1%lo0 prefixlen 64 scopeid 0x3
inet6 ::1 prefixlen 128
inet 127.0.0.1 netmask 0xff00
re0: flags=8802BROADCAST,SIMPLEX,MULTICAST mtu 1500
lladdr 18:67:b0:3e:b4:8f
priority: 0
media: Ethernet autoselect (none)
status: no carrier
enc0: flags=0
priority: 0
groups: enc
status: active
urtwn0: flags=208843UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST,AUTOCONF6 mtu 1500
lladdr 80:1f:02:da:13:e3
priority: 4
groups: wlan egress
media: IEEE802.11 autoselect (OFDM54 mode 11g)
status: active
ieee80211: nwid tsunami chan 6 bssid 4c:9e:ff:90:d8:c0 -82dBm wpakey 
not displayed wpaprotos wpa1,wpa2 wpaakms psk wpaciphers tkip,ccmp 
wpagroupcipher tkip
inet6 fe80::821f:2ff:feda:13e3%urtwn0 prefixlen 64 scopeid 0x4
inet6 2001:470:b70c:0:821f:2ff:feda:13e3 prefixlen 64 autoconf pltime 
604778 vltime 2591978
inet6 2001:470:b70c:0:846b:a4cc:8aa:5a1e prefixlen 64 autoconf 
autoconfprivacy pltime 85961 vltime 604590
inet 192.168.201.25 netmask 0xff00 broadcast 192.168.201.255
pflog0: flags=141UP,RUNNING,PROMISC mtu 33144
priority: 0
groups: pflog
tun1: flags=8051UP,POINTOPOINT,RUNNING,MULTICAST mtu 1500
priority: 0
groups: tun
status: active
inet 172.19.3.65 -- 172.19.3.66 netmask 0x

# route -n show

Routing tables

Internet:
DestinationGatewayFlags   Refs  Use   Mtu  Prio Iface
default192.168.201.1  UGS8  586 -12 urtwn0
127/8  127.0.0.1  UGRS   00 32768 8 lo0  
127.0.0.1  127.0.0.1  UHl10 32768 1 lo0  
172.16/16  172.19.3.66UGS00 - 8 tun1 
172.17/16  172.19.3.66UGS00 - 8 tun1 
172.18/16  172.19.3.66UGS00 - 8 tun1 
172.19/16  172.19.3.66UGS00 - 8 tun1 
172.19.3.65172.19.3.65UHl00 - 1 lo0  
172.19.3.66172.19.3.65UH100 - 4 tun1 
172.20/16  172.19.3.66UGS00 - 8 tun1 
192.168.7/24   172.19.3.66UGS00 - 8 tun1 
192.168.26/24  172.19.3.66UGS00 - 8 tun1 
192.168.32/24  172.19.3.66UGS00 - 8 tun1 
192.168.33/24  172.19.3.66UGS00 - 8 tun1 
192.168.101/24 172.19.3.66UGS00 - 8 tun1 
192.168.201/24 link#4 UC 20 - 4 urtwn0
192.168.201.1  00:0d:b9:32:fa:18  UHLc   1   28 - 4 urtwn0
192.168.201.20 84:7a:88:07:3f:30  UHLc   0 2295 - 4 urtwn0
192.168.201.25 80:1f:02:da:13:e3  UHLl   00 - 1 lo0  
192.168.201.255link#4 UHLb   00 - 1 urtwn0
224/4  127.0.0.1  URS00 32768 8 lo0  

Internet6:
DestinationGatewayFlags   Refs  
Use   Mtu  Prio Iface
::/104 ::1UGRS   0  
  0 32768 8 lo0  
::/96  ::1UGRS   0  
  0 32768 8 lo0  
defaultfe80::20d:b9ff:fe32:fa18%urtwn0 UG 0 
 

Re: urtwn timeout and system freez

[Remi Locherer]

On Fri, Mar 06, 2015 at 11:24:27PM +0100, Martin Pieuchot wrote:
 On 06/03/15(Fri) 22:06, Remi Locherer wrote:
  On Fri, Mar 06, 2015 at 09:15:23AM +0100, Stefan Sperling wrote:
   On Fri, Mar 06, 2015 at 08:45:20AM +0100, Remi Locherer wrote:
Hi,

Since about fall 2014 I see urtwn0 timeout every now an then like 
others that reported it. An unplug and replut of the urtwn device
usually helped.

But with the snapshots from March 1st and 3rd the system just freezes
when I unplug the urtwn device after I see the timeout message in
xconsole. The system just freezes and does not drop to ddb.

With the snapshot from February 20 I did not observe these freezes.

Outputs of lsusb -v and dmesg below.

Remi

   
   Hi Remi,
   
   I've discussed this with mpi. We're unsure what's going on exactly. 
   
   Can you please really make sure you're not dropping into ddb (i.e.
   don't detach the device while in X, but when on console)?
  
  Your assumption is right! Switching from X to console _before_ unplugging
  the urtwn device gives me an ddb promt. I made photos from trace and ps:
  
  * page fault trap: https://relo.ch/urtwn_freeze/IMG_20150306_184105.jpg
  * trace cpu 0 - 3: https://relo.ch/urtwn_freeze/IMG_20150306_192412.jpg
  * ps part 1: https://relo.ch/urtwn_freeze/IMG_20150306_192537.jpg
  * ps part 2: https://relo.ch/urtwn_freeze/IMG_20150306_192708.jpg
 
 It looks like we're trying to remove a transfer from the list of pending
 xfers when it has not yet been added to it.
 
 Could you tell me if the diff below fixes your issue?

I built a kernel with this diff and the diff from Stefan applied on a
cvs checkout from yesterday. I could provoke an urtwn0 timeout with running
speedtest-cli.

* TX status and page fault trap: 
  https://relo.ch/urtwn_freeze/IMG_20150307_134913.jpg
* trace cpu 2,0,1,3: 
  https://relo.ch/urtwn_freeze/IMG_20150307_135150.jpg

I tested the same with urtwn plugged to the xhci port. The timeout also
happens but I can unplug the device without the system dropping to ddb.

Re: urtwn timeout and system freez

[Remi Locherer]

On Fri, Mar 06, 2015 at 09:15:23AM +0100, Stefan Sperling wrote:
 On Fri, Mar 06, 2015 at 08:45:20AM +0100, Remi Locherer wrote:
  Hi,
  
  Since about fall 2014 I see urtwn0 timeout every now an then like 
  others that reported it. An unplug and replut of the urtwn device
  usually helped.
  
  But with the snapshots from March 1st and 3rd the system just freezes
  when I unplug the urtwn device after I see the timeout message in
  xconsole. The system just freezes and does not drop to ddb.
  
  With the snapshot from February 20 I did not observe these freezes.
  
  Outputs of lsusb -v and dmesg below.
  
  Remi
  
 
 Hi Remi,
 
 I've discussed this with mpi. We're unsure what's going on exactly. 
 
 Can you please really make sure you're not dropping into ddb (i.e.
 don't detach the device while in X, but when on console)?

Your assumption is right! Switching from X to console _before_ unplugging
the urtwn device gives me an ddb promt. I made photos from trace and ps:

* page fault trap: https://relo.ch/urtwn_freeze/IMG_20150306_184105.jpg
* trace cpu 0 - 3: https://relo.ch/urtwn_freeze/IMG_20150306_192412.jpg
* ps part 1: https://relo.ch/urtwn_freeze/IMG_20150306_192537.jpg
* ps part 2: https://relo.ch/urtwn_freeze/IMG_20150306_192708.jpg

I'll apply the below diff and report back with the results.

 Can you please apply this diff and let us know if you see any STATUS=?
 lines with it when the problem happens (again, console, not X)?
 
 Thanks.
 
 Index: if_urtwn.c
 ===
 RCS file: /cvs/src/sys/dev/usb/if_urtwn.c,v
 retrieving revision 1.42
 diff -u -p -r1.42 if_urtwn.c
 --- if_urtwn.c10 Feb 2015 23:25:46 -  1.42
 +++ if_urtwn.c6 Mar 2015 08:12:23 -
 @@ -1635,7 +1635,7 @@ urtwn_rxeof(struct usbd_xfer *xfer, void
   int len, totlen, pktlen, infosz, npkts;
  
   if (__predict_false(status != USBD_NORMAL_COMPLETION)) {
 - DPRINTF((RX status=%d\n, status));
 + printf(RX status=%d\n, status);
   if (status == USBD_STALLED)
   usbd_clear_endpoint_stall_async(sc-rx_pipe);
   if (status != USBD_CANCELLED)
 @@ -1703,7 +1703,7 @@ urtwn_txeof(struct usbd_xfer *xfer, void
   TAILQ_INSERT_TAIL(sc-tx_free_list, data, next);
  
   if (__predict_false(status != USBD_NORMAL_COMPLETION)) {
 - DPRINTF((TX status=%d\n, status));
 + printf(TX status=%d\n, status);
   if (status == USBD_STALLED)
   usbd_clear_endpoint_stall_async(data-pipe);
   ifp-if_oerrors++;
 

urtwn timeout and system freez

[Remi Locherer]

Hi,

Since about fall 2014 I see urtwn0 timeout every now an then like 
others that reported it. An unplug and replut of the urtwn device
usually helped.

But with the snapshots from March 1st and 3rd the system just freezes
when I unplug the urtwn device after I see the timeout message in
xconsole. The system just freezes and does not drop to ddb.

With the snapshot from February 20 I did not observe these freezes.

Outputs of lsusb -v and dmesg below.

Remi


Bus 000 Device 001: ID 1912:  
Device Descriptor:
  bLength18
  bDescriptorType 1
  bcdUSB   3.00
  bDeviceClass9 Hub
  bDeviceSubClass 0 Unused
  bDeviceProtocol 1 Single TT
  bMaxPacketSize0 9
  idVendor   0x1912 
  idProduct  0x 
  bcdDevice1.00
  iManufacturer   1 Renesas
  iProduct2 xHCI root hub
  iSerial 0 
  bNumConfigurations  1
  Configuration Descriptor:
bLength 9
bDescriptorType 2
wTotalLength   25
bNumInterfaces  1
bConfigurationValue 1
iConfiguration  0 
bmAttributes 0x40
  (Missing must-be-set bit!)
  Self Powered
MaxPower0mA
Interface Descriptor:
  bLength 9
  bDescriptorType 4
  bInterfaceNumber0
  bAlternateSetting   0
  bNumEndpoints   1
  bInterfaceClass 9 Hub
  bInterfaceSubClass  0 Unused
  bInterfaceProtocol  0 Full speed (or root) hub
  iInterface  0 
  Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x81  EP 1 IN
bmAttributes3
  Transfer TypeInterrupt
  Synch Type   None
  Usage Type   Data
wMaxPacketSize 0x0002  1x 2 bytes
bInterval 255
Hub Descriptor:
  bLength  13
  bDescriptorType  42
  nNbrPorts 4
  wHubCharacteristic 0x
Ganged power switching
Ganged overcurrent protection
TT think time 8 FS bits
  bPwrOn2PwrGood   10 * 2 milli seconds
  bHubContrCurrent  0 milli Ampere
  DeviceRemovable0x00
  PortPwrCtrlMask0x00
 Hub Port Status:
   Port 1: .0900 Unknown Speed Recovery
   Port 2: .0900 Unknown Speed Recovery
   Port 3: .0900 Unknown Speed Recovery
   Port 4: .0900 Unknown Speed Recovery
Device Status: 0x0001
  Self Powered

Bus 001 Device 001: ID 8086: Intel Corp. 
Device Descriptor:
  bLength18
  bDescriptorType 1
  bcdUSB   2.00
  bDeviceClass9 Hub
  bDeviceSubClass 0 Unused
  bDeviceProtocol 1 Single TT
  bMaxPacketSize064
  idVendor   0x8086 Intel Corp.
  idProduct  0x 
  bcdDevice1.00
  iManufacturer   1 Intel
  iProduct2 EHCI root hub
  iSerial 0 
  bNumConfigurations  1
  Configuration Descriptor:
bLength 9
bDescriptorType 2
wTotalLength   25
bNumInterfaces  1
bConfigurationValue 1
iConfiguration  0 
bmAttributes 0x40
  (Missing must-be-set bit!)
  Self Powered
MaxPower0mA
Interface Descriptor:
  bLength 9
  bDescriptorType 4
  bInterfaceNumber0
  bAlternateSetting   0
  bNumEndpoints   1
  bInterfaceClass 9 Hub
  bInterfaceSubClass  0 Unused
  bInterfaceProtocol  0 Full speed (or root) hub
  iInterface  0 
  Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x81  EP 1 IN
bmAttributes3
  Transfer TypeInterrupt
  Synch Type   None
  Usage Type   Data
wMaxPacketSize 0x0008  1x 8 bytes
bInterval  12
Hub Descriptor:
  bLength  10
  bDescriptorType  41
  nNbrPorts 3
  wHubCharacteristic 0x0002
No power switching (usb 1.0)
Ganged overcurrent protection
TT think time 8 FS bits
  bPwrOn2PwrGood  200 * 2 milli seconds
  bHubContrCurrent  0 milli Ampere
  DeviceRemovable0x00
  PortPwrCtrlMask0x00
 Hub Port Status:
   Port 1: .0503 highspeed power enable connect
   Port 2: .0500 highspeed power
   Port 3: .0500 highspeed power
Device Status: 0x0001
  Self Powered

Bus 001 Device 002: ID 8087:0024 Intel Corp. Integrated Rate Matching Hub
Device Descriptor:
  bLength18
  bDescriptorType 1
  bcdUSB   2.00
  bDeviceClass9 Hub
  bDeviceSubClass 0 Unused
  bDeviceProtocol 1 Single TT
  bMaxPacketSize0

Re: xhci dead after resume

[Remi Locherer]

On Mon, Jan 05, 2015 at 01:40:10PM +0100, Martin Pieuchot wrote:
 On 02/01/15(Fri) 13:42, Martin Pieuchot wrote:
  On 02/01/15(Fri) 09:47, Remi Locherer wrote:
   On Thu, Jan 01, 2015 at 09:32:20PM +0100, Remi Locherer wrote:
Synopsis:  xhci dead after resume
Category:  kernel
Environment:
System  : OpenBSD 5.6
Details : OpenBSD 5.6-current (GENERIC.MP) #735: Sat Dec 27 
13:55:58 MST 2014
 
dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP

Architecture: OpenBSD.amd64
Machine : amd64

Description:
After resuming the notebook devices do not attach to the xhci 
port
anymore while devices on the ehci port still work fine. I tried
a mouse, usb stick and cdrom. The cdrom gets power from the port
so I can open the tray but it does not attach.

Fix:
After a reboot the xhci port works again

   dmesg from a kernel compiled with XHCI_DEBUG including a suspend-resume
   cycle:
  
  Apparently Renesas HC need to be completely reconfigure upon resume.
  Linux have a quirk for such piece of hardware.  I'll try to bake a diff
  unless someone... ok I can dream :)
 
 I just committed a workaround for this issue as I couldn't find any
 documentation for a proper fix.  Anyway I can no longer reproduce the
 problem.
 
 Let me know if it still does not work on your machine.
 
 Regards,
 Martin
 
I tested with the snapshot from January 7. Now the xhci port works fine
after resume. Thanks!

Remi

Re: xhci dead after resume

[Remi Locherer]

On Thu, Jan 01, 2015 at 09:32:20PM +0100, Remi Locherer wrote:
 Synopsis:xhci dead after resume
 Category:kernel
 Environment:
   System  : OpenBSD 5.6
   Details : OpenBSD 5.6-current (GENERIC.MP) #735: Sat Dec 27 
 13:55:58 MST 2014

 dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
 
   Architecture: OpenBSD.amd64
   Machine : amd64
 
 Description:
   After resuming the notebook devices do not attach to the xhci port
   anymore while devices on the ehci port still work fine. I tried
   a mouse, usb stick and cdrom. The cdrom gets power from the port
   so I can open the tray but it does not attach.
 
 Fix:
   After a reboot the xhci port works again
 
dmesg from a kernel compiled with XHCI_DEBUG including a suspend-resume
cycle:

OpenBSD 5.7-beta (GENERIC.MP.XHCI_DEBUG) #0: Fri Jan  2 09:16:12 CET 2015
r...@mistral.relo.ch:/usr/src/sys/arch/amd64/compile/GENERIC.MP.XHCI_DEBUG
real mem = 3881746432 (3701MB)
avail mem = 3774537728 (3599MB)
mpath0 at root
scsibus0 at mpath0: 256 targets
mainbus0 at root
bios0 at mainbus0: SMBIOS rev. 2.7 @ 0xe0970 (63 entries)
bios0: vendor Phoenix Technologies Ltd. version P00ACX date 04/26/2013
bios0: SAMSUNG ELECTRONICS CO., LTD. 900X3F
acpi0 at bios0: rev 2
acpi0: sleep states S0 S3 S4 S5
acpi0: tables DSDT FACP SLIC SSDT ASF! HPET APIC MCFG FPDT SSDT SSDT UEFI MSDM 
UEFI UEFI
acpi0: wakeup devices P0P1(S4) GLAN(S4) XHC_(S4) HDEF(S4) PXSX(S4) RP01(S4) 
PXSX(S4) RP02(S4) PXSX(S4) RP03(S4) PXSX(S4) RP04(S4) PXSX(S4) RP06(S4) 
PXSX(S4) RP07(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-3337U CPU @ 1.80GHz, 1696.41 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,XSAVE,AVX,F16C,RDRAND,NXE,LONG,LAHF,PERF,ITSC,FSGSBASE,SMEP,ERMS
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-3337U CPU @ 1.80GHz, 1696.15 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,XSAVE,AVX,F16C,RDRAND,NXE,LONG,LAHF,PERF,ITSC,FSGSBASE,SMEP,ERMS
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-3337U CPU @ 1.80GHz, 1696.15 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,XSAVE,AVX,F16C,RDRAND,NXE,LONG,LAHF,PERF,ITSC,FSGSBASE,SMEP,ERMS
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-3337U CPU @ 1.80GHz, 1696.15 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,XSAVE,AVX,F16C,RDRAND,NXE,LONG,LAHF,PERF,ITSC,FSGSBASE,SMEP,ERMS
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
acpiprt0 at acpi0: bus 0 (PCI0)
acpiprt1 at acpi0: bus -1 (P0P1)
acpiprt2 at acpi0: bus 1 (RP01)
acpiprt3 at acpi0: bus -1 (RP02)
acpiprt4 at acpi0: bus -1 (RP03)
acpiprt5 at acpi0: bus 2 (RP04)
acpiprt6 at acpi0: bus 3 (RP05)
acpiprt7 at acpi0: bus -1 (RP06)
acpiprt8 at acpi0: bus -1 (RP07)
acpiprt9 at acpi0: bus -1 (RP08)
acpiprt10 at acpi0: bus -1 (PEG0)
acpiprt11 at acpi0: bus -1 (PEG1)
acpiprt12 at acpi0: bus -1 (PEG2)
acpiprt13 at acpi0: bus -1 (PEG3)
acpiec0 at acpi0
acpicpu0 at acpi0: C3, C2, C1, PSS
acpicpu1 at acpi0: C3, C2, C1, PSS
acpicpu2 at acpi0: C3, C2, C1, PSS
acpicpu3 at acpi0: C3, C2, C1, PSS
acpipwrres0 at acpi0: FN00, resource for FAN0
acpipwrres1 at acpi0: FN01, resource for FAN1
acpipwrres2 at acpi0: FN02, resource for FAN2
acpipwrres3 at acpi0: FN03, resource for FAN3
acpipwrres4 at acpi0: FN04, resource for FAN4
acpitz0 at acpi0: critical temperature is 106 degC
acpitz1 at acpi0: critical temperature is 106 degC
acpibat0 at acpi0: BAT1 type LION oem SAMSUNG Electronics
acpiac0 at acpi0: AC unit offline
acpibtn0 at acpi0: LID0
acpibtn1 at acpi0: PWRB
acpivideo0 at acpi0

xhci dead after resume

[Remi Locherer]

Synopsis:  xhci dead after resume
Category:  kernel
Environment:
System  : OpenBSD 5.6
Details : OpenBSD 5.6-current (GENERIC.MP) #735: Sat Dec 27 
13:55:58 MST 2014
 
dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP

Architecture: OpenBSD.amd64
Machine : amd64

Description:
After resuming the notebook devices do not attach to the xhci port
anymore while devices on the ehci port still work fine. I tried
a mouse, usb stick and cdrom. The cdrom gets power from the port
so I can open the tray but it does not attach.

Fix:
After a reboot the xhci port works again,§

dmesg:
OpenBSD 5.6-current (GENERIC.MP) #735: Sat Dec 27 13:55:58 MST 2014
dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
real mem = 3881746432 (3701MB)
avail mem = 3774541824 (3599MB)
mpath0 at root
scsibus0 at mpath0: 256 targets
mainbus0 at root
bios0 at mainbus0: SMBIOS rev. 2.7 @ 0xe0970 (63 entries)
bios0: vendor Phoenix Technologies Ltd. version P00ACX date 04/26/2013
bios0: SAMSUNG ELECTRONICS CO., LTD. 900X3F
acpi0 at bios0: rev 2
acpi0: sleep states S0 S3 S4 S5
acpi0: tables DSDT FACP SLIC SSDT ASF! HPET APIC MCFG FPDT SSDT SSDT UEFI MSDM 
UEFI UEFI
acpi0: wakeup devices P0P1(S4) GLAN(S4) XHC_(S4) HDEF(S4) PXSX(S4) RP01(S4) 
PXSX(S4) RP02(S4) PXSX(S4) RP03(S4) PXSX(S4) RP04(S4) PXSX(S4) RP06(S4) 
PXSX(S4) RP07(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-3337U CPU @ 1.80GHz, 1696.40 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,XSAVE,AVX,F16C,RDRAND,NXE,LONG,LAHF,PERF,ITSC,FSGSBASE,SMEP,ERMS
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-3337U CPU @ 1.80GHz, 1696.15 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,XSAVE,AVX,F16C,RDRAND,NXE,LONG,LAHF,PERF,ITSC,FSGSBASE,SMEP,ERMS
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-3337U CPU @ 1.80GHz, 1696.15 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,XSAVE,AVX,F16C,RDRAND,NXE,LONG,LAHF,PERF,ITSC,FSGSBASE,SMEP,ERMS
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-3337U CPU @ 1.80GHz, 1696.15 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,XSAVE,AVX,F16C,RDRAND,NXE,LONG,LAHF,PERF,ITSC,FSGSBASE,SMEP,ERMS
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
acpiprt0 at acpi0: bus 0 (PCI0)
acpiprt1 at acpi0: bus -1 (P0P1)
acpiprt2 at acpi0: bus 1 (RP01)
acpiprt3 at acpi0: bus -1 (RP02)
acpiprt4 at acpi0: bus -1 (RP03)
acpiprt5 at acpi0: bus 2 (RP04)
acpiprt6 at acpi0: bus 3 (RP05)
acpiprt7 at acpi0: bus -1 (RP06)
acpiprt8 at acpi0: bus -1 (RP07)
acpiprt9 at acpi0: bus -1 (RP08)
acpiprt10 at acpi0: bus -1 (PEG0)
acpiprt11 at acpi0: bus -1 (PEG1)
acpiprt12 at acpi0: bus -1 (PEG2)
acpiprt13 at acpi0: bus -1 (PEG3)
acpiec0 at acpi0
acpicpu0 at acpi0: C3, C2, C1, PSS
acpicpu1 at acpi0: C3, C2, C1, PSS
acpicpu2 at acpi0: C3, C2, C1, PSS
acpicpu3 at acpi0: C3, C2, C1, PSS
acpipwrres0 at acpi0: FN00, resource for FAN0
acpipwrres1 at acpi0: FN01, resource for FAN1
acpipwrres2 at acpi0: FN02, resource for FAN2
acpipwrres3 at acpi0: FN03, resource for FAN3
acpipwrres4 at acpi0: FN04, resource for FAN4
acpitz0 at acpi0: critical temperature is 106 degC
acpitz1 at acpi0: critical temperature is 106 degC
acpibat0 at acpi0: BAT1 type LION oem SAMSUNG Electronics
acpiac0 at acpi0: AC unit online
acpibtn0 at acpi0: LID0
acpibtn1 at acpi0: PWRB
acpivideo0 at acpi0: GFX0
acpivout0 at acpivideo0: DD02
cpu0: Enhanced SpeedStep 1696 MHz: speeds: 1801, 1800, 1700, 1600, 1500, 1400, 
1300, 1200, 1100, 1000, 900, 

USB nix axen not working reliable

[Remi Locherer]

Synopsis:  USB nic axen not working reliable
Category:  kernel
Environment:
System  : OpenBSD 5.6
Details : OpenBSD 5.6-current (GENERIC.MP) #607: Mon Nov 24 
14:23:38 MST 2014
 
dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP

Architecture: OpenBSD.amd64
Machine : amd64
Description:
My USB3 Edimax Gigabit Ethernet adapter (axen) does not work reliable
anymore.

When plugged in into the USB 2 port ifconfig shows status: active
for a few seconds. Then it changes to status: no carrier while still
connected and does not changes its status anymore. If dhclient configures 
axen0 during the first few seconds it stays active and works fine. 

When connected to the USB 3 port it also shows status: active for the
first few seconds. If it then gets configured with dhclient it either
freezes the hole system or fills dmesg with checksum err and does not
work. Somethimes the system panics instead.

o The details when attached to the USB 2 port:

# dmesg | grep axen | tail -3
axen0 at uhub2 port 2 configuration 1 interface 0 ASIX Elec. Corp. AX88179 
rev 2.10/1.00 addr 3
axen0: AX88179, address 80:1f:02:75:cc:86
rgephy1 at axen0 phy 3: RTL8169S/8110S PHY, rev. 5

# usbdevs
addr 1: xHCI root hub, Renesas
addr 1: EHCI root hub, Intel
 addr 2: Rate Matching Hub, Intel
  addr 3: AX88179, ASIX Elec. Corp.
  addr 4: product 0x3004, Atheros Communications
  addr 5: WebCam SC-13HDL11624N, Namugaÿ

ifconfig output immediately after plugging in the axen nic. Ethernet
cable allready connected (no STP involved).
# ifconfig axen0 
axen0: flags=28802BROADCAST,SIMPLEX,MULTICAST,NOINET6 mtu 1500
lladdr 80:1f:02:75:cc:86
priority: 0
media: Ethernet autoselect (none)
status: no carrier

After about 1 second:
# ifconfig axen0 
axen0: flags=28802BROADCAST,SIMPLEX,MULTICAST,NOINET6 mtu 1500
lladdr 80:1f:02:75:cc:86
priority: 0
media: Ethernet autoselect (1000baseT full-duplex)
status: active

After a few seconds:
# ifconfig axen0 
axen0: flags=28802BROADCAST,SIMPLEX,MULTICAST,NOINET6 mtu 1500
lladdr 80:1f:02:75:cc:86
priority: 0
media: Ethernet autoselect (10baseT half-duplex)
status: no carrier

Starting dhclient immediately after plugging in the axen nic (via hotplugd):
# ifconfig axen0
axen0: flags=28843UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST,NOINET6 mtu 1500
lladdr 80:1f:02:75:cc:86
priority: 0
groups: egress
media: Ethernet autoselect (1000baseT full-duplex,master)
status: active
inet 192.168.201.28 netmask 0xff00 broadcast 192.168.201.255


o Details when plugged into the USB 3 port.

# dmesg | grep axen
axen0 at uhub0 port 1 configuration 1 interface 0 ASIX Elec. Corp. AX88179 
rev 3.00/1.00 addr 2
axen0: AX88179, address 80:1f:02:75:cc:86
rgephy1 at axen0 phy 3: RTL8169S/8110S PHY, rev. 5

# usbdevs
addr 1: xHCI root hub, Renesas
 addr 2: AX88179, ASIX Elec. Corp.
addr 1: EHCI root hub, Intel
 addr 2: Rate Matching Hub, Intel
  addr 3: 802.11n WLAN Adapter, Realtek
  addr 4: product 0x3004, Atheros Communications
  addr 5: WebCam SC-13HDL11624N, Namugaÿ

# ifconfig axen0
axen0: flags=28802BROADCAST,SIMPLEX,MULTICAST,NOINET6 mtu 1500
lladdr 80:1f:02:75:cc:86
priority: 0
media: Ethernet autoselect (10baseT half-duplex)
status: no carrier

Xconsole quickly filled with the message below and the pc did not react
anymore.
splassert: asserwaitok: want -1 have 1

Output from kernel debugger:

ddb ps screen 1
https://relo.ch/axen_usb3_panic/IMG_20141125_221425.jpg
ddb ps screen 2
https://relo.ch/axen_usb3_panic/IMG_20141125_221443.jpg
ddb ps screen 3
https://relo.ch/axen_usb3_panic/IMG_20141125_221456.jpg
ddb ps screen 4
https://relo.ch/axen_usb3_panic/IMG_20141125_221507.jpg
ddb trace cpu 0
https://relo.ch/axen_usb3_panic/IMG_20141125_221531.jpg
ddb trace cpu 1, 2, 3
https://relo.ch/axen_usb3_panic/IMG_20141125_221816.jpg

After a reboot and starting dhclient immediately when plugging in the
axen nic (via hotplugd):

axen0: flags=28843UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST,NOINET6 mtu 1500
lladdr 80:1f:02:75:cc:86
priority: 0
groups: egress
media: Ethernet autoselect (1000baseT full-duplex)
status: active
inet 192.168.201.28 netmask 0xff00 broadcast 192.168.201.255

dmesg is then full of the following, network does not work anymore: 

invalid buffer(pkt#65535), continue
checksum err (pkt#0)
invalid buffer(pkt#65535), continue
checksum err (pkt#0)
invalid buffer(pkt#65535), continue
checksum err (pkt#0)
invalid buffer(pkt#65535), continue
checksum err (pkt#0)
invalid buffer(pkt#65535), continue
checksum err (pkt#0)
invalid buffer(pkt#65535), continue



dmesg:
OpenBSD 5.6-current (GENERIC.MP) #607: Mon Nov 24 14:23:38 MST 2014

Re: Samsung Notebook: acpitz0 critical temp since sept 25 snapshot

[Remi Locherer]

On Thu, Oct 09, 2014 at 04:26:42PM -0700, Mike Larkin wrote:
 On Thu, Oct 09, 2014 at 11:42:59PM +0200, Remi Locherer wrote:
  On Tue, Oct 07, 2014 at 10:10:54PM +0200, Remi Locherer wrote:
   Synopsis: Samsung Notebook: acpitz0 critical temp since sept 25 snapshot 
   Environment:
 System  : OpenBSD 5.6
 Details : OpenBSD 5.6-current (GENERIC.MP) #399: Sun Oct  5 
   21:53:59 MDT 2014
  
   dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
   
 Architecture: OpenBSD.amd64
 Machine : amd64
   
   Description:
 The Samsung 900X3F shuts down after boot with the message:
   acpitz0: critical temperature exceeded 144C, shutting down. The snapshot
   from September 17 was working fine. Since snapshot September 25 I'm seeing
   this.
   
   Strange thing: when I'm now booting the sept 17 snapshot kernel the 
   notebook
   also shuts itselfe down with the above message. Does th kernel modify the
   acpi tables?
   
  
  Now this is really strange: today I booted the Samsung notebook several
  times with the kernel from snapshot oct 5. The problem with acpitz0
  never occured. Can it be that the kernel sometimes is using a wrong
  address to read acpi stuff? Or is Samsung using a strange acpi
  implementation?
  
  Remi 
  
 
 Try turning on debug and see what it's really reading. There are some 
 dprintfs in there
 that will likely help.
 
 -ml
 

I figured out that to fix this issue once such a shutdown happens I have
to leave the notebook turned off for some hours (usually I just suspend it).
Should it happen again I'll compile a kernel with option ACPI_DEBUG and 
post the resulting dmesg.

Remi

Re: Samsung Notebook: acpitz0 critical temp since sept 25 snapshot

[Remi Locherer]

On Tue, Oct 07, 2014 at 10:10:54PM +0200, Remi Locherer wrote:
 Synopsis: Samsung Notebook: acpitz0 critical temp since sept 25 snapshot 
 Environment:
   System  : OpenBSD 5.6
   Details : OpenBSD 5.6-current (GENERIC.MP) #399: Sun Oct  5 
 21:53:59 MDT 2014

 dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
 
   Architecture: OpenBSD.amd64
   Machine : amd64
 
 Description:
   The Samsung 900X3F shuts down after boot with the message:
 acpitz0: critical temperature exceeded 144C, shutting down. The snapshot
 from September 17 was working fine. Since snapshot September 25 I'm seeing
 this.
 
 Strange thing: when I'm now booting the sept 17 snapshot kernel the notebook
 also shuts itselfe down with the above message. Does th kernel modify the
 acpi tables?
 

Now this is really strange: today I booted the Samsung notebook several
times with the kernel from snapshot oct 5. The problem with acpitz0
never occured. Can it be that the kernel sometimes is using a wrong
address to read acpi stuff? Or is Samsung using a strange acpi
implementation?

Remi 

Samsung Notebook: acpitz0 critical temp since sept 25 snapshot

[Remi Locherer]

Synopsis: Samsung Notebook: acpitz0 critical temp since sept 25 snapshot   
Environment:
System  : OpenBSD 5.6
Details : OpenBSD 5.6-current (GENERIC.MP) #399: Sun Oct  5 
21:53:59 MDT 2014
 
dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP

Architecture: OpenBSD.amd64
Machine : amd64

Description:
The Samsung 900X3F shuts down after boot with the message:
acpitz0: critical temperature exceeded 144C, shutting down. The snapshot
from September 17 was working fine. Since snapshot September 25 I'm seeing
this.

Strange thing: when I'm now booting the sept 17 snapshot kernel the notebook
also shuts itselfe down with the above message. Does th kernel modify the
acpi tables?

Remi


dmesg:
OpenBSD 5.6-current (GENERIC.MP) #399: Sun Oct  5 21:53:59 MDT 2014
dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
real mem = 3881746432 (3701MB)
avail mem = 3769696256 (3595MB)
mpath0 at root
scsibus0 at mpath0: 256 targets
mainbus0 at root
bios0 at mainbus0: SMBIOS rev. 2.7 @ 0xe0970 (63 entries)
bios0: vendor Phoenix Technologies Ltd. version P00ACX date 04/26/2013
bios0: SAMSUNG ELECTRONICS CO., LTD. 900X3F
acpi0 at bios0: rev 2
acpi0: sleep states S0 S3 S4 S5
acpi0: tables DSDT FACP SLIC SSDT ASF! HPET APIC MCFG FPDT SSDT SSDT UEFI MSDM 
UEFI UEFI
acpi0: wakeup devices P0P1(S4) GLAN(S4) XHC_(S4) HDEF(S4) PXSX(S4) RP01(S4) 
PXSX(S4) RP02(S4) PXSX(S4) RP03(S4) PXSX(S4) RP04(S4) PXSX(S4) RP06(S4) 
PXSX(S4) RP07(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-3337U CPU @ 1.80GHz, 1696.37 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,XSAVE,AVX,F16C,RDRAND,NXE,LONG,LAHF,PERF,ITSC,FSGSBASE,SMEP,ERMS
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-3337U CPU @ 1.80GHz, 1696.15 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,XSAVE,AVX,F16C,RDRAND,NXE,LONG,LAHF,PERF,ITSC,FSGSBASE,SMEP,ERMS
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-3337U CPU @ 1.80GHz, 1696.15 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,XSAVE,AVX,F16C,RDRAND,NXE,LONG,LAHF,PERF,ITSC,FSGSBASE,SMEP,ERMS
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-3337U CPU @ 1.80GHz, 1696.15 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,XSAVE,AVX,F16C,RDRAND,NXE,LONG,LAHF,PERF,ITSC,FSGSBASE,SMEP,ERMS
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
acpiprt0 at acpi0: bus 0 (PCI0)
acpiprt1 at acpi0: bus -1 (P0P1)
acpiprt2 at acpi0: bus 1 (RP01)
acpiprt3 at acpi0: bus -1 (RP02)
acpiprt4 at acpi0: bus -1 (RP03)
acpiprt5 at acpi0: bus 2 (RP04)
acpiprt6 at acpi0: bus 3 (RP05)
acpiprt7 at acpi0: bus -1 (RP06)
acpiprt8 at acpi0: bus -1 (RP07)
acpiprt9 at acpi0: bus -1 (RP08)
acpiprt10 at acpi0: bus -1 (PEG0)
acpiprt11 at acpi0: bus -1 (PEG1)
acpiprt12 at acpi0: bus -1 (PEG2)
acpiprt13 at acpi0: bus -1 (PEG3)
acpiec0 at acpi0
acpicpu0 at acpi0: C3, C2, C1, PSS
acpicpu1 at acpi0: C3, C2, C1, PSS
acpicpu2 at acpi0: C3, C2, C1, PSS
acpicpu3 at acpi0: C3, C2, C1, PSS
acpipwrres0 at acpi0: FN00, resource for FAN0
acpipwrres1 at acpi0: FN01, resource for FAN1
acpipwrres2 at acpi0: FN02, resource for FAN2
acpipwrres3 at acpi0: FN03, resource for FAN3
acpipwrres4 at acpi0: FN04, resource for FAN4
acpitz0 at acpi0: critical temperature is 106 degC
acpitz1 at acpi0: critical temperature is 106 degC
acpibat0 at acpi0: BAT1 not present
acpiac0 at acpi0: AC unit offline
acpibtn0 at acpi0: LID0
acpibtn1 at acpi0: PWRB
acpivideo0 at acpi0: GFX0
acpivout0 at acpivideo0: DD02
cpu0: Enhanced SpeedStep 1696 MHz: speeds: 1801, 

[SOLVED] Samsung900X3F: wrong acpitz temperature, acpibat0 not detecting battery

[Remi Locherer]

On Sat, Feb 22, 2014 at 04:04:40PM +0100, Remi Locherer wrote:
 Synopsis:wrong acpitz temperature and acpibat0 not detecting battery
 Category:acpi
 Environment:
   System  : OpenBSD 5.5
   Details : OpenBSD 5.5-beta (GENERIC.MP) #2: Fri Feb 21 08:50:33 CET 
 2014

 r...@samsung.relo.ch:/usr/src/sys/arch/amd64/compile/GENERIC.MP
 
   Architecture: OpenBSD.amd64
   Machine : amd64
 Description:
 On the Samsung 900X3F acpitz0 reports wrong temperature which
 leads to a shutdown. The battery is not recognized by acpibat.
 
 I also tested on OpenBSD 5.3 and 5.3: same result.
 
 # sysctl hw.sensors
 hw.sensors.cpu0.temp0=45.00 degC
 hw.sensors.cpu1.temp0=45.00 degC
 hw.sensors.cpu2.temp0=45.00 degC
 hw.sensors.cpu3.temp0=45.00 degC
 hw.sensors.acpitz0.temp0=144.00 degC (zone temperature)
 hw.sensors.acpitz1.temp0=29.80 degC (zone temperature)
 hw.sensors.acpiac0.indicator0=Off (power supply)
 hw.sensors.acpibtn0.indicator0=Off (lid open)
 hw.sensors.softraid0.drive0=online (sd1), OK
 
 Whyle the notebook runs on battery:
 # apm
 Battery state: absent, 0% remaining, unknown life estimate
 A/C adapter state: not connected
 Performance adjustment mode: cool running (774 MHz
 

After not looking into this for a while I tested the snapshot from July
20 on the Samsung 900X3F. The Problem described in the bug report does
not happen anymore. Thanks for fixing this!

(now I only wait for xhci and Atheros AR9462 support ;) )


OpenBSD 5.6-beta (GENERIC.MP) #292: Sun Jul 20 05:27:41 MDT 2014
dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
real mem = 3881746432 (3701MB)
avail mem = 3769630720 (3595MB)
mpath0 at root
scsibus0 at mpath0: 256 targets
mainbus0 at root
bios0 at mainbus0: SMBIOS rev. 2.7 @ 0xe0970 (63 entries)
bios0: vendor Phoenix Technologies Ltd. version P00ACX date 04/26/2013
bios0: SAMSUNG ELECTRONICS CO., LTD. 900X3F
acpi0 at bios0: rev 2
acpi0: sleep states S0 S3 S4 S5
acpi0: tables DSDT FACP SLIC SSDT ASF! HPET APIC MCFG FPDT SSDT SSDT UEFI MSDM 
UEFI UEFI
acpi0: wakeup devices P0P1(S4) GLAN(S4) XHC_(S4) HDEF(S4) PXSX(S4) RP01(S4) 
PXSX(S4) RP02(S4) PXSX(S4) RP03(S4) PXSX(S4) RP04(S4) PXSX(S4) RP06(S4) 
PXSX(S4) RP07(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-3337U CPU @ 1.80GHz, 1696.38 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,XSAVE,AVX,F16C,RDRAND,NXE,LONG,LAHF,PERF,ITSC,FSGSBASE,SMEP,ERMS
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-3337U CPU @ 1.80GHz, 1696.15 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,XSAVE,AVX,F16C,RDRAND,NXE,LONG,LAHF,PERF,ITSC,FSGSBASE,SMEP,ERMS
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-3337U CPU @ 1.80GHz, 1696.15 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,XSAVE,AVX,F16C,RDRAND,NXE,LONG,LAHF,PERF,ITSC,FSGSBASE,SMEP,ERMS
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-3337U CPU @ 1.80GHz, 1696.15 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,XSAVE,AVX,F16C,RDRAND,NXE,LONG,LAHF,PERF,ITSC,FSGSBASE,SMEP,ERMS
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
acpiprt0 at acpi0: bus 0 (PCI0)
acpiprt1 at acpi0: bus -1 (P0P1)
acpiprt2 at acpi0: bus 1 (RP01)
acpiprt3 at acpi0: bus -1 (RP02)
acpiprt4 at acpi0: bus -1 (RP03)
acpiprt5 at acpi0: bus 2 (RP04)
acpiprt6 at acpi0: bus 3 (RP05)
acpiprt7 at acpi0: bus -1 (RP06)
acpiprt8 at acpi0: bus -1 (RP07)
acpiprt9 at acpi0: bus -1 (RP08)
acpiprt10 at acpi0: bus -1 (PEG0)
acpiprt11 at acpi0: bus -1 (PEG1)
acpiprt12 at acpi0: bus -1 (PEG2)
acpiprt13 at acpi0: bus -1 (PEG3)
acpiec0

Re: Samsung900X3F: wrong acpitz temperature, acpibat0 not detecting battery

[Remi Locherer]

On Fri, Apr 18, 2014 at 12:34:44PM +0300, Paul Irofti wrote:
 Closing in... what does this button do?
 

Shut down with lot of output of course ;)


OpenBSD 5.5-current (GENERIC.MP) #3: Fri Apr 18 12:05:40 CEST 2014
r...@mistral.relo.ch:/usr/src/sys/arch/amd64/compile/GENERIC.MP
real mem = 3881746432 (3701MB)
avail mem = 3769647104 (3595MB)
mpath0 at root
scsibus0 at mpath0: 256 targets
mainbus0 at root
bios0 at mainbus0: SMBIOS rev. 2.7 @ 0xe0970 (63 entries)
bios0: vendor Phoenix Technologies Ltd. version P00ACX date 04/26/2013
bios0: SAMSUNG ELECTRONICS CO., LTD. 900X3F
acpi0 at bios0: rev 2
acpi0: sleep states S0 S3 S4 S5
acpi0: tables DSDT FACP SLIC SSDT ASF! HPET APIC MCFG FPDT SSDT SSDT UEFI MSDM 
UEFI UEFI
acpi0: wakeup devices P0P1(S4) GLAN(S4) XHC_(S4) HDEF(S4) PXSX(S4) RP01(S4) 
PXSX(S4) RP02(S4) PXSX(S4) RP03(S4) PXSX(S4) RP04(S4) PXSX(S4) RP06(S4) 
PXSX(S4) RP07(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-3337U CPU @ 1.80GHz, 1696.41 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,XSAVE,AVX,F16C,RDRAND,NXE,LONG,LAHF,PERF,ITSC,FSGSBASE,SMEP,ERMS
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-3337U CPU @ 1.80GHz, 1696.15 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,XSAVE,AVX,F16C,RDRAND,NXE,LONG,LAHF,PERF,ITSC,FSGSBASE,SMEP,ERMS
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-3337U CPU @ 1.80GHz, 1696.15 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,XSAVE,AVX,F16C,RDRAND,NXE,LONG,LAHF,PERF,ITSC,FSGSBASE,SMEP,ERMS
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-3337U CPU @ 1.80GHz, 1696.15 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,XSAVE,AVX,F16C,RDRAND,NXE,LONG,LAHF,PERF,ITSC,FSGSBASE,SMEP,ERMS
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
acpiprt0 at acpi0: bus 0 (PCI0)
acpiprt1 at acpi0: bus -1 (P0P1)
acpiprt2 at acpi0: bus 1 (RP01)
acpiprt3 at acpi0: bus -1 (RP02)
acpiprt4 at acpi0: bus -1 (RP03)
acpiprt5 at acpi0: bus 2 (RP04)
acpiprt6 at acpi0: bus 3 (RP05)
acpiprt7 at acpi0: bus -1 (RP06)
acpiprt8 at acpi0: bus -1 (RP07)
acpiprt9 at acpi0: bus -1 (RP08)
acpiprt10 at acpi0: bus -1 (PEG0)
acpiprt11 at acpi0: bus -1 (PEG1)
acpiprt12 at acpi0: bus -1 (PEG2)
acpiprt13 at acpi0: bus -1 (PEG3)
acpiec0 at acpi0
acpicpu0 at acpi0: C3, C2, C1, PSS
acpicpu1 at acpi0: C3, C2, C1, PSS
acpicpu2 at acpi0: C3, C2, C1, PSS
acpicpu3 at acpi0: C3, C2, C1, PSS
acpipwrres0 at acpi0: FN00, resource for FAN0
acpipwrres1 at acpi0: FN01, resource for FAN1
acpipwrres2 at acpi0: FN02, resource for FAN2
acpipwrres3 at acpi0: FN03, resource for FAN3
acpipwrres4 at acpi0: FN04, resource for FAN4
acpitz0 at acpi0: critical temperature is 106 degC
acpitz1 at acpi0: critical temperature is 106 degC
acpibat0 at acpi0: BAT1 not present
acpiac0 at acpi0: AC unit offline
acpibtn0 at acpi0: LID0
acpibtn1 at acpi0: PWRB
acpivideo0 at acpi0: GFX0
acpivout0 at acpivideo0: DD02
cpu0: Enhanced SpeedStep 1696 MHz: speeds: 1801, 1800, 1700, 1600, 1500, 1400, 
1300, 1200, 1100, 1000, 900, 800, 774 MHz
pci0 at mainbus0 bus 0
pchb0 at pci0 dev 0 function 0 Intel Core 3G Host rev 0x09
vga1 at pci0 dev 2 function 0 Intel HD Graphics 4000 rev 0x09
intagp0 at vga1
agp0 at intagp0: aperture at 0xe000, size 0x1000
inteldrm0 at vga1
drm0 at inteldrm0
inteldrm0: 1920x1080
wsdisplay0 at vga1 mux 1: console (std, vt100 emulation)
wsdisplay0: screen 1-5 added (std, vt100 emulation)
Intel 7 Series MEI rev 0x04 at pci0 dev 22 function 0 not configured
azalia0 at pci0 dev 27 function 0 Intel 7 Series HD Audio rev 0x04: msi
azalia0: codecs: Realtek ALC269, Intel/0x2806, using 

Re: Samsung900X3F: wrong acpitz temperature, acpibat0 not detecting battery

[Remi Locherer]

On Fri, Apr 18, 2014 at 06:43:25PM +0300, Paul Irofti wrote:
 This is the important part of the trace:
 
  4e10 Store
  4e11 \\_SB_.PCI0.LPCB.H_EC.CTMP
  locking
  field: aml_rwgas bitpos 1536 bpos 0 blen 8,flags 0x11
read 03 00c0 0008 [\\_SB_.PCI0.LPCB.H_EC.ECR_]
  gasio rd: 3 0xc0 1 1 851728760
  aml_bufcpy: 0x90
  unlocking
  4e28 Local0
  4e29 If
  4e2b LNotEqual
  4e2d Local0
  4e2e 0xff
  4e30 Return
  4e31 Add
  4e32 0x0aac
  4e35 Multiply
  4e36 Local0
  4e37 0x0a
  acpitz0: critical temperature exceeded 144C, shutting down
 
 What happens is that we read 8 bits from bit-position (bitpos) 1536
 from the ECR field from the EC and then store it in Local0.
 
 What we read from there is 0x90, which is 144 in decimal.
 
 The revelant AML code looks like this:
 
 Store (\_SB.PCI0.LPCB.H_EC.CTMP, Local0)
 If (LNotEqual (Local0, 0xFF))
   Return (Add (0x0AAC, Multiply (Local0, 0x0A)))
 
 CTMP is supposed to keep the temperature in Celsius, thus it needs a
 conversion to Kelvin.
 
 So what this does is check if the value it just read is different from
 0xFF and if so it converts the value to Kelvin degrees and returns them
 to the upper layers as required by the ACPI spec.
 
 Local0 * 10 + 2732 = 4172 which is 417.2K as dictated by the spec.
 
 Then userland transforms it back to Celsius and freaks out.
 
 
 The field, from your AML dump, looks like the following:
 
 Field (ECR, ByteAcc, Lock, Preserve) {
   [...]
   Offset (0xC0),
   CTMP,   8,
   [...] }
 
 Offset 0xC0 is the offset in bytes from the beginning of the field and
 it's 192 in decimal which translates to 192 * 4 = 1536 bits.
 This matches the bitpos from which the temperature was read, so the
 position is correct.
 
 Thus the bad news is that the bug is not a bitpos parsing bug...
 
 This happens only with OpenBSD? Linux or Windows runs fine, right?

Both Windows and Linux run fine. I can not test Windows anymore but I
just started Fedora 20 and verified that the two thermal zones present
temperatur values that make sense.

Re: Samsung900X3F: wrong acpitz temperature, acpibat0 not detecting battery

[Remi Locherer]

On Mon, Apr 14, 2014 at 07:09:47PM +0300, Paul Irofti wrote:
 Thanks for testing!
 
 I need a bit more info, could you tell me what the output is when
 applying the following diff on top of -current?

Here you go:


OpenBSD 5.5-current (GENERIC.MP) #2: Mon Apr 14 22:45:53 CEST 2014
r...@mistral.relo.ch:/usr/src/sys/arch/amd64/compile/GENERIC.MP
real mem = 3881746432 (3701MB)
avail mem = 3769651200 (3595MB)
mpath0 at root
scsibus0 at mpath0: 256 targets
mainbus0 at root
bios0 at mainbus0: SMBIOS rev. 2.7 @ 0xe0970 (63 entries)
bios0: vendor Phoenix Technologies Ltd. version P00ACX date 04/26/2013
bios0: SAMSUNG ELECTRONICS CO., LTD. 900X3F
acpi0 at bios0: rev 2
acpi0: sleep states S0 S3 S4 S5
acpi0: tables DSDT FACP SLIC SSDT ASF! HPET APIC MCFG FPDT SSDT SSDT UEFI MSDM 
UEFI UEFI
acpi0: wakeup devices P0P1(S4) GLAN(S4) XHC_(S4) HDEF(S4) PXSX(S4) RP01(S4) 
PXSX(S4) RP02(S4) PXSX(S4) RP03(S4) PXSX(S4) RP04(S4) PXSX(S4) RP06(S4) 
PXSX(S4) RP07(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-3337U CPU @ 1.80GHz, 1696.41 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,XSAVE,AVX,F16C,RDRAND,NXE,LONG,LAHF,PERF,ITSC,FSGSBASE,SMEP,ERMS
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-3337U CPU @ 1.80GHz, 1696.15 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,XSAVE,AVX,F16C,RDRAND,NXE,LONG,LAHF,PERF,ITSC,FSGSBASE,SMEP,ERMS
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-3337U CPU @ 1.80GHz, 1696.15 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,XSAVE,AVX,F16C,RDRAND,NXE,LONG,LAHF,PERF,ITSC,FSGSBASE,SMEP,ERMS
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-3337U CPU @ 1.80GHz, 1696.15 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,XSAVE,AVX,F16C,RDRAND,NXE,LONG,LAHF,PERF,ITSC,FSGSBASE,SMEP,ERMS
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
acpiprt0 at acpi0: bus 0 (PCI0)
acpiprt1 at acpi0: bus -1 (P0P1)
acpiprt2 at acpi0: bus 1 (RP01)
acpiprt3 at acpi0: bus -1 (RP02)
acpiprt4 at acpi0: bus -1 (RP03)
acpiprt5 at acpi0: bus 2 (RP04)
acpiprt6 at acpi0: bus 3 (RP05)
acpiprt7 at acpi0: bus -1 (RP06)
acpiprt8 at acpi0: bus -1 (RP07)
acpiprt9 at acpi0: bus -1 (RP08)
acpiprt10 at acpi0: bus -1 (PEG0)
acpiprt11 at acpi0: bus -1 (PEG1)
acpiprt12 at acpi0: bus -1 (PEG2)
acpiprt13 at acpi0: bus -1 (PEG3)
acpiec0 at acpi0
acpicpu0 at acpi0: C3, C2, C1, PSS
acpicpu1 at acpi0: C3, C2, C1, PSS
acpicpu2 at acpi0: C3, C2, C1, PSS
acpicpu3 at acpi0: C3, C2, C1, PSS
acpipwrres0 at acpi0: FN00, resource for FAN0
acpipwrres1 at acpi0: FN01, resource for FAN1
acpipwrres2 at acpi0: FN02, resource for FAN2
acpipwrres3 at acpi0: FN03, resource for FAN3
acpipwrres4 at acpi0: FN04, resource for FAN4
acpitz0 at acpi0: critical temperature is 106 degC
acpitz1 at acpi0: critical temperature is 106 degC
acpibat0 at acpi0: BAT1 not present
acpiac0 at acpi0: AC unit offline
acpibtn0 at acpi0: LID0
acpibtn1 at acpi0: PWRB
acpivideo0 at acpi0: GFX0
acpivout0 at acpivideo0: DD02
cpu0: Enhanced SpeedStep 1696 MHz: speeds: 1801, 1800, 1700, 1600, 1500, 1400, 
1300, 1200, 1100, 1000, 900, 800, 774 MHz
pci0 at mainbus0 bus 0
pchb0 at pci0 dev 0 function 0 Intel Core 3G Host rev 0x09
vga1 at pci0 dev 2 function 0 Intel HD Graphics 4000 rev 0x09
intagp0 at vga1
agp0 at intagp0: aperture at 0xe000, size 0x1000
inteldrm0 at vga1
drm0 at inteldrm0
inteldrm0: 1920x1080
wsdisplay0 at vga1 mux 1: console (std, vt100 emulation)
wsdisplay0: screen 1-5 added (std, vt100 emulation)
Intel 7 Series MEI rev 0x04 at pci0 dev 22 function 0 not configured
azalia0 at pci0 dev 27 function 0 Intel 7 Series HD Audio 

Re: Samsung900X3F: wrong acpitz temperature, acpibat0 not detecting battery

[Remi Locherer]

On Sat, Apr 12, 2014 at 04:00:40PM +0300, Paul Irofti wrote:
  I'll send a tracing diff your way soon because I'm curious what the
  AML path is inside _TMP once your machine resumes.
 
 Here it is. Careful it might be really noisy and further tweaks might be
 needed. Let me know what the output is and I'll see what needs to be
 done next.
 
 Note, I'm interested first in the diff I sent earlier and afterwards in
 this one.

Here the dmesg from a kernel with your tracing diff applied.

Thanks a lot for your time you're putting into this!

Remi



OpenBSD 5.5-current (GENERIC.MP) #1: Sun Apr 13 07:24:17 CEST 2014
r...@mistral.relo.ch:/usr/src/sys/arch/amd64/compile/GENERIC.MP
real mem = 3881746432 (3701MB)
avail mem = 3769651200 (3595MB)
mpath0 at root
scsibus0 at mpath0: 256 targets
mainbus0 at root
bios0 at mainbus0: SMBIOS rev. 2.7 @ 0xe0970 (63 entries)
bios0: vendor Phoenix Technologies Ltd. version P00ACX date 04/26/2013
bios0: SAMSUNG ELECTRONICS CO., LTD. 900X3F
acpi0 at bios0: rev 2
acpi0: sleep states S0 S3 S4 S5
acpi0: tables DSDT FACP SLIC SSDT ASF! HPET APIC MCFG FPDT SSDT SSDT UEFI MSDM 
UEFI UEFI
acpi0: wakeup devices P0P1(S4) GLAN(S4) XHC_(S4) HDEF(S4) PXSX(S4) RP01(S4) 
PXSX(S4) RP02(S4) PXSX(S4) RP03(S4) PXSX(S4) RP04(S4) PXSX(S4) RP06(S4) 
PXSX(S4) RP07(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-3337U CPU @ 1.80GHz, 1696.41 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,XSAVE,AVX,F16C,RDRAND,NXE,LONG,LAHF,PERF,ITSC,FSGSBASE,SMEP,ERMS
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-3337U CPU @ 1.80GHz, 1696.15 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,XSAVE,AVX,F16C,RDRAND,NXE,LONG,LAHF,PERF,ITSC,FSGSBASE,SMEP,ERMS
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-3337U CPU @ 1.80GHz, 1696.15 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,XSAVE,AVX,F16C,RDRAND,NXE,LONG,LAHF,PERF,ITSC,FSGSBASE,SMEP,ERMS
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-3337U CPU @ 1.80GHz, 1696.15 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,XSAVE,AVX,F16C,RDRAND,NXE,LONG,LAHF,PERF,ITSC,FSGSBASE,SMEP,ERMS
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
acpiprt0 at acpi0: bus 0 (PCI0)
acpiprt1 at acpi0: bus -1 (P0P1)
acpiprt2 at acpi0: bus 1 (RP01)
acpiprt3 at acpi0: bus -1 (RP02)
acpiprt4 at acpi0: bus -1 (RP03)
acpiprt5 at acpi0: bus 2 (RP04)
acpiprt6 at acpi0: bus 3 (RP05)
acpiprt7 at acpi0: bus -1 (RP06)
acpiprt8 at acpi0: bus -1 (RP07)
acpiprt9 at acpi0: bus -1 (RP08)
acpiprt10 at acpi0: bus -1 (PEG0)
acpiprt11 at acpi0: bus -1 (PEG1)
acpiprt12 at acpi0: bus -1 (PEG2)
acpiprt13 at acpi0: bus -1 (PEG3)
acpiec0 at acpi0
acpicpu0 at acpi0: C3, C2, C1, PSS
acpicpu1 at acpi0: C3, C2, C1, PSS
acpicpu2 at acpi0: C3, C2, C1, PSS
acpicpu3 at acpi0: C3, C2, C1, PSS
acpipwrres0 at acpi0: FN00, resource for FAN0
acpipwrres1 at acpi0: FN01, resource for FAN1
acpipwrres2 at acpi0: FN02, resource for FAN2
acpipwrres3 at acpi0: FN03, resource for FAN3
acpipwrres4 at acpi0: FN04, resource for FAN4
acpitz0 at acpi0: critical temperature is 106 degC
acpitz1 at acpi0: critical temperature is 106 degC
acpibat0 at acpi0: BAT1 not present
acpiac0 at acpi0: AC unit offline
acpibtn0 at acpi0: LID0
acpibtn1 at acpi0: PWRB
acpivideo0 at acpi0: GFX0
acpivout0 at acpivideo0: DD02
cpu0: Enhanced SpeedStep 1696 MHz: speeds: 1801, 1800, 1700, 1600, 1500, 1400, 
1300, 1200, 1100, 1000, 900, 800, 774 MHz
pci0 at mainbus0 bus 0
pchb0 at pci0 dev 0 function 0 Intel Core 3G Host rev 0x09
vga1 at pci0 dev 2 function 0 Intel HD Graphics 4000 rev 0x09
intagp0 at vga1
agp0 at 

Re: Samsung900X3F: wrong acpitz temperature, acpibat0 not detecting battery

[Remi Locherer]

On Sat, Apr 12, 2014 at 04:00:40PM +0300, Paul Irofti wrote:
  I'll send a tracing diff your way soon because I'm curious what the
  AML path is inside _TMP once your machine resumes.
 
 Here it is. Careful it might be really noisy and further tweaks might be
 needed. Let me know what the output is and I'll see what needs to be
 done next.

This time the system didn't shut down after boot and I could do a
suspend / resume cycle. It halted during resume because of acpitz.


OpenBSD 5.5-current (GENERIC.MP) #1: Sun Apr 13 07:24:17 CEST 2014
r...@mistral.relo.ch:/usr/src/sys/arch/amd64/compile/GENERIC.MP
real mem = 3881746432 (3701MB)
avail mem = 3769651200 (3595MB)
mpath0 at root
scsibus0 at mpath0: 256 targets
mainbus0 at root
bios0 at mainbus0: SMBIOS rev. 2.7 @ 0xe0970 (63 entries)
bios0: vendor Phoenix Technologies Ltd. version P00ACX date 04/26/2013
bios0: SAMSUNG ELECTRONICS CO., LTD. 900X3F
acpi0 at bios0: rev 2
acpi0: sleep states S0 S3 S4 S5
acpi0: tables DSDT FACP SLIC SSDT ASF! HPET APIC MCFG FPDT SSDT SSDT UEFI MSDM 
UEFI UEFI
acpi0: wakeup devices P0P1(S4) GLAN(S4) XHC_(S4) HDEF(S4) PXSX(S4) RP01(S4) 
PXSX(S4) RP02(S4) PXSX(S4) RP03(S4) PXSX(S4) RP04(S4) PXSX(S4) RP06(S4) 
PXSX(S4) RP07(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-3337U CPU @ 1.80GHz, 1696.40 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,XSAVE,AVX,F16C,RDRAND,NXE,LONG,LAHF,PERF,ITSC,FSGSBASE,SMEP,ERMS
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-3337U CPU @ 1.80GHz, 1696.15 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,XSAVE,AVX,F16C,RDRAND,NXE,LONG,LAHF,PERF,ITSC,FSGSBASE,SMEP,ERMS
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-3337U CPU @ 1.80GHz, 1696.15 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,XSAVE,AVX,F16C,RDRAND,NXE,LONG,LAHF,PERF,ITSC,FSGSBASE,SMEP,ERMS
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-3337U CPU @ 1.80GHz, 1696.15 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,XSAVE,AVX,F16C,RDRAND,NXE,LONG,LAHF,PERF,ITSC,FSGSBASE,SMEP,ERMS
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
acpiprt0 at acpi0: bus 0 (PCI0)
acpiprt1 at acpi0: bus -1 (P0P1)
acpiprt2 at acpi0: bus 1 (RP01)
acpiprt3 at acpi0: bus -1 (RP02)
acpiprt4 at acpi0: bus -1 (RP03)
acpiprt5 at acpi0: bus 2 (RP04)
acpiprt6 at acpi0: bus 3 (RP05)
acpiprt7 at acpi0: bus -1 (RP06)
acpiprt8 at acpi0: bus -1 (RP07)
acpiprt9 at acpi0: bus -1 (RP08)
acpiprt10 at acpi0: bus -1 (PEG0)
acpiprt11 at acpi0: bus -1 (PEG1)
acpiprt12 at acpi0: bus -1 (PEG2)
acpiprt13 at acpi0: bus -1 (PEG3)
acpiec0 at acpi0
acpicpu0 at acpi0: C3, C2, C1, PSS
acpicpu1 at acpi0: C3, C2, C1, PSS
acpicpu2 at acpi0: C3, C2, C1, PSS
acpicpu3 at acpi0: C3, C2, C1, PSS
acpipwrres0 at acpi0: FN00, resource for FAN0
acpipwrres1 at acpi0: FN01, resource for FAN1
acpipwrres2 at acpi0: FN02, resource for FAN2
acpipwrres3 at acpi0: FN03, resource for FAN3
acpipwrres4 at acpi0: FN04, resource for FAN4
acpitz0 at acpi0: critical temperature is 106 degC
acpitz1 at acpi0: critical temperature is 106 degC
acpibat0 at acpi0: BAT1 not present
acpiac0 at acpi0: AC unit offline
acpibtn0 at acpi0: LID0
acpibtn1 at acpi0: PWRB
acpivideo0 at acpi0: GFX0
acpivout0 at acpivideo0: DD02
cpu0: Enhanced SpeedStep 1696 MHz: speeds: 1801, 1800, 1700, 1600, 1500, 1400, 
1300, 1200, 1100, 1000, 900, 800, 774 MHz
pci0 at mainbus0 bus 0
pchb0 at pci0 dev 0 function 0 Intel Core 3G Host rev 0x09
vga1 at pci0 dev 2 function 0 Intel HD Graphics 4000 rev 0x09
intagp0 at vga1
agp0 at intagp0: aperture at 0xe000, size 0x1000
inteldrm0 at vga1
drm0 at 

Re: Samsung900X3F: wrong acpitz temperature, acpibat0 not detecting battery

[Remi Locherer]

On Sat, Apr 12, 2014 at 01:47:15PM +0300, Paul Irofti wrote:
 Very strange...
 
 I'm still investigating the issue and glancing at your acpidump.
 I'll send a tracing diff your way soon because I'm curious what the
 AML path is inside _TMP once your machine resumes.
 
 Until then I wanted to ask you if you're also testing with the glk diff
 when you're testing my acpiec_clear_events diff?

I applied the previous patch to a fresh checked out source tree which didn't
contain below changes. Should I have applied several patches together?

Applying this patch to a freshly checked out source tree results in the
same behaviour as with last tests: the system shuts down right after
boot because of wrong temperator for acpitz0 and sometimes it's getting it
right. Ususally battery data is absent or only partly there. 


 You should have the following in /sys/dev/acpi:
 
 
 Index: dsdt.c
 ===
 RCS file: /cvs/src/sys/dev/acpi/dsdt.c,v
 retrieving revision 1.205
 diff -u -p -r1.205 dsdt.c
 --- dsdt.c12 Dec 2013 20:56:01 -  1.205
 +++ dsdt.c12 Apr 2014 10:45:02 -
 @@ -736,72 +736,58 @@ static long global_lock_count = 0;
  void
  acpi_glk_enter(void)
  {
 - acpi_acquire_glk(acpi_softc-sc_facs-global_lock);
 -}
 -
 -void
 -acpi_glk_leave(void)
 -{
 - int x;
 -
 - if (acpi_release_glk(acpi_softc-sc_facs-global_lock)) {
 - /*
 -  * If pending, notify the BIOS that the lock was released
 -  * by the OSPM. No locking is needed because nobody outside
 -  * the ACPI thread is touching this register.
 -  */
 - x = acpi_read_pmreg(acpi_softc, ACPIREG_PM1_CNT, 0);
 - x |= ACPI_PM1_GBL_RLS;
 - acpi_write_pmreg(acpi_softc, ACPIREG_PM1_CNT, 0, x);
 - }
 -}
 -
 -void
 -aml_lockfield(struct aml_scope *scope, struct aml_value *field)
 -{
   int st = 0;
  
 - if (AML_FIELD_LOCK(field-v_field.flags) != AML_FIELD_LOCK_ON)
 - return;
 -
 - /* If lock is already ours, just continue */
 + /* If lock is already ours, just continue. */
   if (global_lock_count++)
   return;
  
 - /* Spin to acquire lock */
 + /* Spin to acquire the lock. */
   while (!st) {
   st = acpi_acquire_glk(acpi_softc-sc_facs-global_lock);
   /* XXX - yield/delay? */
   }
 -
 - return;
  }
  
  void
 -aml_unlockfield(struct aml_scope *scope, struct aml_value *field)
 +acpi_glk_leave(void)
  {
 - int st, x, s;
 + int st, x;
  
 - if (AML_FIELD_LOCK(field-v_field.flags) != AML_FIELD_LOCK_ON)
 - return;
 -
 - /* If we are the last ones, turn out the lights */
 + /* If we are the last one, turn out the lights. */
   if (--global_lock_count)
   return;
  
 - /* Release lock */
   st = acpi_release_glk(acpi_softc-sc_facs-global_lock);
   if (!st)
   return;
  
 - /* Signal others if someone waiting */
 - s = spltty();
 + /*
 +  * If pending, notify the BIOS that the lock was released by
 +  * OSPM.  No locking is needed because nobody outside the ACPI
 +  * thread is supposed to touch this register.
 +  */
   x = acpi_read_pmreg(acpi_softc, ACPIREG_PM1_CNT, 0);
   x |= ACPI_PM1_GBL_RLS;
   acpi_write_pmreg(acpi_softc, ACPIREG_PM1_CNT, 0, x);
 - splx(s);
 +}
 +
 +void
 +aml_lockfield(struct aml_scope *scope, struct aml_value *field)
 +{
 + if (AML_FIELD_LOCK(field-v_field.flags) != AML_FIELD_LOCK_ON)
 + return;
 +
 + acpi_glk_enter();
 +}
 +
 +void
 +aml_unlockfield(struct aml_scope *scope, struct aml_value *field)
 +{
 + if (AML_FIELD_LOCK(field-v_field.flags) != AML_FIELD_LOCK_ON)
 + return;
  
 - return;
 + acpi_glk_leave();
  }
  
  /*
 Index: acpiec.c
 ===
 RCS file: /cvs/src/sys/dev/acpi/acpiec.c,v
 retrieving revision 1.48
 diff -u -p -r1.48 acpiec.c
 --- acpiec.c  2 Jul 2013 18:37:47 -   1.48
 +++ acpiec.c  12 Apr 2014 10:45:03 -
 @@ -34,6 +34,7 @@
  
  int  acpiec_match(struct device *, void *, void *);
  void acpiec_attach(struct device *, struct device *, void *);
 +int  acpiec_activate(struct device *, int);
  
  u_int8_t acpiec_status(struct acpiec_softc *);
  u_int8_t acpiec_read_data(struct acpiec_softc *);
 @@ -54,6 +55,7 @@ int acpiec_getregister(const u_int8_t *
  
  void acpiec_wait(struct acpiec_softc *, u_int8_t, u_int8_t);
  void acpiec_sci_event(struct acpiec_softc *);
 +void acpiec_clear_events(struct acpiec_softc *);
  
  void acpiec_get_events(struct acpiec_softc *);
  
 @@ -82,7 +84,8 @@ voidacpiec_unlock(struct acpiec_softc 
  int  acpiec_reg(struct acpiec_softc *);
  
  struct cfattach acpiec_ca = {
 - sizeof(struct acpiec_softc), acpiec_match, 

Re: Samsung900X3F: wrong acpitz temperature, acpibat0 not detecting battery

[Remi Locherer]

Hi Paul

On Wed, Apr 02, 2014 at 06:22:35PM +0300, Paul Irofti wrote:
 Hi Remi,
 
 thank you for the detailed report and for your patience.
 
 I was wondering if you could test the following diff and let me know
 what happens.

I applied this patch to a freshly checked out source tree on April 2
and tested a few boot sequences:

#1
https://relo.ch/dmesg-samsung900X3F/dmesg-samsung900X3F-201404032101.txt
acpitz0 ok, battery sensors partly
zzz: imediate shutdown after resume: acpitz0  144

#2
https://relo.ch/dmesg-samsung900X3F/dmesg-samsung900X3F-201404032104.txt
immediate shutdown, acpitz0  144

#3
https://relo.ch/dmesg-samsung900X3F/dmesg-samsung900X3F-201404032136.txt
acpitz0 ok, battery sensors partly
zzz: imediate shutdown after resume: acpitz0  144

#4
https://relo.ch/dmesg-samsung900X3F/dmesg-samsung900X3F-201404032138.txt
immediate shutdown, acpitz0  144

#5
https://relo.ch/dmesg-samsung900X3F/dmesg-samsung900X3F-201404032140.txt
immediate shutdown, acpitz0  144

#6
https://relo.ch/dmesg-samsung900X3F/dmesg-samsung900X3F-201404032147.txt
acpitz0 ok, battery sensors partly, keyboard illumination on
zzz: imediate shutdown after resume: acpitz0  144, 
 keyboard illumination stays off during and after resume


Thank you for having a look into this!
Remi

 
 Thanks,
 Paul
 
 Index: dev/acpi/acpiec.c
 ===
 RCS file: /cvs/src/sys/dev/acpi/acpiec.c,v
 retrieving revision 1.48
 diff -u -p -r1.48 acpiec.c
 --- dev/acpi/acpiec.c 2 Jul 2013 18:37:47 -   1.48
 +++ dev/acpi/acpiec.c 2 Apr 2014 15:21:00 -
 @@ -34,6 +34,7 @@
  
  int  acpiec_match(struct device *, void *, void *);
  void acpiec_attach(struct device *, struct device *, void *);
 +int  acpiec_activate(struct device *, int);
  
  u_int8_t acpiec_status(struct acpiec_softc *);
  u_int8_t acpiec_read_data(struct acpiec_softc *);
 @@ -54,6 +55,7 @@ int acpiec_getregister(const u_int8_t *
  
  void acpiec_wait(struct acpiec_softc *, u_int8_t, u_int8_t);
  void acpiec_sci_event(struct acpiec_softc *);
 +void acpiec_clear_events(struct acpiec_softc *);
  
  void acpiec_get_events(struct acpiec_softc *);
  
 @@ -82,7 +84,8 @@ voidacpiec_unlock(struct acpiec_softc 
  int  acpiec_reg(struct acpiec_softc *);
  
  struct cfattach acpiec_ca = {
 - sizeof(struct acpiec_softc), acpiec_match, acpiec_attach
 + sizeof(struct acpiec_softc), acpiec_match, acpiec_attach,
 + NULL, acpiec_activate
  };
  
  struct cfdriver acpiec_cd = {
 @@ -296,6 +299,8 @@ acpiec_attach(struct device *parent, str
   acpi_set_gpehandler(sc-sc_acpi, sc-sc_gpe, acpiec_gpehandler,
   sc, 1);
  #endif
 +
 + /* acpiec_clear_events(sc); */
   
   if (aml_evalname(sc-sc_acpi, sc-sc_devnode, _GLK, 0, NULL, res))
   sc-sc_glk = 0;
 @@ -307,6 +312,20 @@ acpiec_attach(struct device *parent, str
   printf(\n);
  }
  
 +int
 +acpiec_activate(struct device *self, int act)
 +{
 + struct acpiec_softc *sc = (struct acpiec_softc *)self;
 +
 +
 + switch (act) {
 + case DVACT_RESUME:
 + acpiec_clear_events(sc);
 + break;
 + }
 + return (0);
 +}
 +
  void
  acpiec_get_events(struct acpiec_softc *sc)
  {
 @@ -552,4 +571,19 @@ acpiec_unlock(struct acpiec_softc *sc)
   }
  
   sc-sc_ecbusy = 0;
 +}
 +
 +void
 +acpiec_clear_events(struct acpiec_softc *sc)
 +{
 + int i;
 +
 + for (i = 0; i  100; i++) {
 + /*acpiec_write_cmd(sc, EC_CMD_QR);*/
 + bus_space_write_1(sc-sc_cmd_bt, sc-sc_cmd_bh, 0, EC_CMD_QR);
 + sc-sc_gotsci = 0;
 + if ((acpiec_status(sc)  EC_STAT_SCI_EVT) != EC_STAT_SCI_EVT) {
 + break;
 + }
 + }
  }

Re: volume keys not working on thinkpad x201

[Remi Locherer]

On Sun, Mar 23, 2014 at 07:06:51PM +0100, Alexandre Ratchov wrote:
 On Sun, Mar 23, 2014 at 11:38:11AM -0600, Theo de Raadt wrote:
So we should take all our hardware mixers, and crank them to full
volume right at boot time.
   
IMO, this is the best option.
   Do you have a stereo system connected to your PC? I would not
   made this the default. Start low and if you want a loud default
   setting, use mixerctl.conf
  
  So that is the reason why my car stereo has two sets of volume control
  knobs. with the second set located inside the engine compartment,
  so I have to stop at the side of the road, pop open the hood, and
  reach down along the hot engine to near where the oil filter is.
  
  It is ridiculous to have two layers of volume control.
  
  It is unfriendly.
 
 100% agreed. We should have one mixer only.
 

I installed the snapshot from March 29 and the volume keys now work as
before (changing outputs.master). Thank you!

Re: volume keys not working on thinkpad x201

[Remi Locherer]

On Sun, Mar 23, 2014 at 02:27:57PM +0100, Alexandre Ratchov wrote:
 On Sun, Mar 23, 2014 at 10:50:21AM +0100, Remi Locherer wrote:
  On Sat, Mar 22, 2014 at 04:31:22PM -0600, Theo de Raadt wrote:
 Date: Sat, 22 Mar 2014 21:49:19 +0100 (CET)
 From: remi.loche...@relo.ch
 
   With the snapshot from March 22 the volume keys on my ThinkPad
   x201 do not work anymore. mixerctl still works. Before I was
   running the snapshot from Feb 3 with which the volume keys
   worked.

The volume keys still work.  What changed is that the volume keys no
longer control the hardware mixer directly anymore when you're running
X.  Instead the volume key events are passed to whatever X application
is running.  If you're running mplayer, you'll see that the volume
keys still control the volume and give you feedback on the screen.  If
you run gnome, you'll see something similar.

The problem you might experience is that the x201 boots up with the
hardware mixer set to a fairly low level.  And the software volume
control in most X applications won't change it so you won't be able to
go any higher by just pressing the volume keys.
   
  When several X applications are running which one should get the event?
  
  I cranked outputs.master to 200 and tested with smplayer and aqualung
  both playing something. The volume keys had no audible nor visual effect.
 
 Do volume keys work when smplayer and aqualung have the keyboard
 focus ?

No, it does not work with smplayer and aqualung. But it works with
mplayer when it has the focus.

   So we should take all our hardware mixers, and crank them to full
   volume right at boot time.
   
   Except that would be bad.  So this indicates that the new mixer layer
   has a problem.
  
  The old behaviour where the volume keys manipulated outputs.master was
  more intuitive to me. 
 
 yes but it doesn't work in all cases :(

volume keys not working on thinkpad x201

[remi . locherer]

Synopsis:  volume keys not working on thinkpad x201 
Category:  kernel
Environment:
System  : OpenBSD 5.5
Details : OpenBSD 5.5-current (GENERIC.MP) #16: Sat Mar 22 01:04:40 
MDT 2014
 
dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP

Architecture: OpenBSD.amd64
Machine : amd64
Description:
With the snapshot from March 22 the volume keys on my ThinkPad x201 do
not work anymore. mixerctl still works. Before I was running the 
snapshot
from Feb 3 with which the volume keys worked.

I tried to revert sys/dev/acpi/dsdt.c to revision 1.205 but that did not
help (the commit message noted that it might break brightness keys)

How-To-Repeat:
Install the snapshot from Mar 22 on a ThinkPad x201 and try to use the
volume buttons.



dmesg:
OpenBSD 5.5-current (GENERIC.MP) #16: Sat Mar 22 01:04:40 MDT 2014
dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
real mem = 8357658624 (7970MB)
avail mem = 8126451712 (7749MB)
mainbus0 at root
bios0 at mainbus0: SMBIOS rev. 2.6 @ 0xe0010 (78 entries)
bios0: vendor LENOVO version 6QET61WW (1.31 ) date 10/26/2010
bios0: LENOVO 3626GN8
acpi0 at bios0: rev 2
acpi0: sleep states S0 S3 S4 S5
acpi0: tables DSDT FACP SSDT ECDT APIC MCFG HPET ASF! BOOT SSDT TCPA DMAR SSDT 
SSDT SSDT
acpi0: wakeup devices LID_(S3) SLPB(S3) IGBE(S4) EXP1(S4) EXP2(S4) EXP3(S4) 
EXP4(S4) EXP5(S4) EHC1(S3) EHC2(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) i5 CPU M 560 @ 2.67GHz, 1197.20 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,POPCNT,AES,NXE,LONG,LAHF,PERF,ITSC
cpu0: 256KB 64b/line 8-way L2 cache
cpu0: smt 0, core 0, package 0
mtrr: Pentium Pro MTRR support, 8 var ranges, 88 fixed ranges
cpu0: apic clock running at 132MHz
cpu0: mwait min=64, max=64, C-substates=0.2.1.1.0, IBE
cpu1 at mainbus0: apid 1 (application processor)
cpu1: Intel(R) Core(TM) i5 CPU M 560 @ 2.67GHz, 1197.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,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,POPCNT,AES,NXE,LONG,LAHF,PERF,ITSC
cpu1: 256KB 64b/line 8-way L2 cache
cpu1: smt 1, core 0, package 0
cpu2 at mainbus0: apid 4 (application processor)
cpu2: Intel(R) Core(TM) i5 CPU M 560 @ 2.67GHz, 1197.00 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,POPCNT,AES,NXE,LONG,LAHF,PERF,ITSC
cpu2: 256KB 64b/line 8-way L2 cache
cpu2: smt 0, core 2, package 0
cpu3 at mainbus0: apid 5 (application processor)
cpu3: Intel(R) Core(TM) i5 CPU M 560 @ 2.67GHz, 1197.00 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,POPCNT,AES,NXE,LONG,LAHF,PERF,ITSC
cpu3: 256KB 64b/line 8-way L2 cache
cpu3: smt 1, core 2, 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-255
acpihpet0 at acpi0: 14318179 Hz
acpiprt0 at acpi0: bus 0 (PCI0)
acpiprt1 at acpi0: bus -1 (PEG_)
acpiprt2 at acpi0: bus 13 (EXP1)
acpiprt3 at acpi0: bus -1 (EXP2)
acpiprt4 at acpi0: bus -1 (EXP3)
acpiprt5 at acpi0: bus 5 (EXP4)
acpiprt6 at acpi0: bus 2 (EXP5)
acpicpu0 at acpi0: C3, C1, PSS
acpicpu1 at acpi0: C3, C1, PSS
acpicpu2 at acpi0: C3, C1, PSS
acpicpu3 at acpi0: C3, C1, PSS
acpipwrres0 at acpi0: PUBS, resource for EHC1, EHC2
acpitz0 at acpi0: critical temperature is 100 degC
acpibtn0 at acpi0: LID_
acpibtn1 at acpi0: SLPB
acpibat0 at acpi0: BAT0 model 42T4694 serial  1523 type LION oem SANYO
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 1197 MHz: speeds: 2667, 2666, 2533, 2399, 2266, 2133, 
1999, 1866, 1733, 1599, 1466, 1333, 1199 MHz
pci0 at mainbus0 bus 0
pchb0 at pci0 dev 0 function 0 Intel Core Host rev 0x02
vga1 at pci0 dev 2 function 0 Intel HD Graphics rev 0x02
intagp0 at vga1
agp0 at intagp0: aperture at 0xd000, size 0x1000
inteldrm0 at vga1
drm0 at inteldrm0
inteldrm0: 1280x800
wsdisplay0 at vga1 mux 1: console (std, vt100 emulation)
wsdisplay0: screen 1-5 added (std, vt100 emulation)
Intel 3400 MEI rev 0x06 at pci0 dev 22 function 0 not configured
em0 at pci0 dev 25 function 0 Intel 82577LM rev 0x06: msi, 

[solved] strange artefacts with inteldrm on samsung 900X3F

[Remi Locherer]

I installed the snapshot from February 17 and the artefacts in X are
gone. X now works fine on the Samsung 900X3F. Thanks!

On Mon, Oct 28, 2013 at 08:36:14AM +0100, Remi Locherer wrote:
 Synopsis:strange artefacts with inteldrm on samsung 900X3F
 
 Environment:
 System  : OpenBSD 5.4
 Details : OpenBSD 5.4-current (GENERIC.MP) #92: Sat Oct 26 20:22:52 MDT 
 2013

 dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
 Architecture: OpenBSD.amd64
 Machine : amd64
 
 Description:
 Strange lines apear when running X. The longer X is running the worse 
 it gets. Sometimes the artefacts are even visible in the console  after
 terminating X. It looks the same as this bugreport for Linux that was fixed
 with Linux 3.10: https://bugs.freedesktop.org/show_bug.cgi?id=64332
 Here a picture how it looks: http://picpaste.com/D7Uf2OrP.png (also at the 
 end of the mail base64 encoded).
 
 
 dmesg:
 OpenBSD 5.4-current (GENERIC.MP) #92: Sat Oct 26 20:22:52 MDT 2013
 dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
 real mem = 3881746432 (3701MB)
 avail mem = 3770277888 (3595MB)
 User Kernel Config
 UKC disable acpitz
 357 acpitz* disabled
 UKC quit
 Continuing...
 mainbus0 at root
 bios0 at mainbus0: SMBIOS rev. 2.7 @ 0xe0970 (63 entries)
 bios0: vendor Phoenix Technologies Ltd. version P00ACX date 04/26/2013
 bios0: SAMSUNG ELECTRONICS CO., LTD. 900X3F
 acpi0 at bios0: rev 2
 acpi0: sleep states S0 S3 S4 S5
 acpi0: tables DSDT FACP SLIC SSDT ASF! HPET APIC MCFG FPDT SSDT SSDT UEFI 
 MSDM UEFI UEFI
 acpi0: wakeup devices P0P1(S4) GLAN(S4) XHC_(S4) HDEF(S4) PXSX(S4) RP01(S4) 
 PXSX(S4) RP02(S4) PXSX(S4) RP03(S4) PXSX(S4) RP04(S4) PXSX(S4) RP06(S4) 
 PXSX(S4) RP07(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-3337U CPU @ 1.80GHz, 1696.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,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,POPCNT,DEADLINE,XSAVE,AVX,F16C,RDRAND,NXE,LONG,LAHF,PERF,ITSC,FSGSBASE,SMEP,ERMS
 cpu0: 256KB 64b/line 8-way L2 cache
 cpu0: smt 0, core 0, package 0
 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-3337U CPU @ 1.80GHz, 1696.15 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,XSAVE,AVX,F16C,RDRAND,NXE,LONG,LAHF,PERF,ITSC,FSGSBASE,SMEP,ERMS
 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-3337U CPU @ 1.80GHz, 1696.15 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,XSAVE,AVX,F16C,RDRAND,NXE,LONG,LAHF,PERF,ITSC,FSGSBASE,SMEP,ERMS
 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-3337U CPU @ 1.80GHz, 1696.15 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,XSAVE,AVX,F16C,RDRAND,NXE,LONG,LAHF,PERF,ITSC,FSGSBASE,SMEP,ERMS
 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
 acpiprt0 at acpi0: bus 0 (PCI0)
 acpiprt1 at acpi0: bus -1 (P0P1)
 acpiprt2 at acpi0: bus 1 (RP01)
 acpiprt3 at acpi0: bus -1 (RP02)
 acpiprt4 at acpi0: bus -1 (RP03)
 acpiprt5 at acpi0: bus 2 (RP04)
 acpiprt6 at acpi0: bus 3 (RP05)
 acpiprt7 at acpi0: bus -1 (RP06)
 acpiprt8 at acpi0: bus -1 (RP07)
 acpiprt9 at acpi0: bus -1 (RP08)
 acpiprt10 at acpi0: bus -1 (PEG0)
 acpiprt11 at acpi0: bus -1 (PEG1)
 acpiprt12 at acpi0: bus -1 (PEG2)
 acpiprt13 at acpi0: bus -1 (PEG3)
 acpiec0 at acpi0
 acpicpu0 at acpi0: C3, C2, C1, PSS
 acpicpu1 at acpi0: C3, C2, C1, PSS
 acpicpu2 at acpi0: C3, C2, C1, PSS
 acpicpu3 at acpi0: C3, C2, C1, PSS
 acpipwrres0 at acpi0: FN00
 acpipwrres1 at acpi0: FN01
 acpipwrres2 at acpi0: FN02
 acpipwrres3 at acpi0: FN03
 acpipwrres4 at acpi0: FN04
 acpitz at acpi0 not configured
 acpitz at acpi0 not configured
 acpibat0 at acpi0: BAT1 not present
 acpiac0 at acpi0: AC unit offline
 acpibtn0 at acpi0: LID0
 acpibtn1 at acpi0: PWRB
 acpivideo0 at acpi0: GFX0

Re: panic: timeout_add: to_ticks (-1) 0

[Remi Locherer]

On Fri, Nov 15, 2013 at 08:42:07AM +0100, Remi Locherer wrote:
 On Mon, Nov 11, 2013 at 04:22:47PM +, Stuart Henderson wrote:
  On 2013/11/11 09:53, RD Thrush wrote:
   Synopsis:Firewall panic with Nov 10 snapshot
   Category:kernel
   Environment:
 System  : OpenBSD 5.4
 Details : OpenBSD 5.4-current (GENERIC) #142: Sun Nov 10 22:52:49 
   MST 2013
  
   dera...@i386.openbsd.org:/usr/src/sys/arch/i386/compile/GENERIC
 Architecture: OpenBSD.i386
 Machine : i386
   Description:
 Soekris 5501 firewall panics an hour after booting new snapshot.  
   Appended is
 some ddb info as well as normal sendbug details.
   How-To-Repeat:
 Don't know.
   Fix:
 Revert to Nov 7 kernel
  
  I've reverted the bpf commit for now, it looks like the change is 
  invalidating
  assumptions of the conditional around bpf_read()'s tsleep in bpf.c:439 ..
 
 The panic is still there with snapshot from Nov 14. It's easy to reproduce:
 Start darkstat and surf the web with lynx.

I'm running now the snapshot from Dec 27 and do not see the panic anymore. 
I don't try every snapshot so maybe it was fixed with an earlyer one.

Remi

Re: panic: timeout_add: to_ticks (-1) 0

[Remi Locherer]

On Mon, Nov 11, 2013 at 04:22:47PM +, Stuart Henderson wrote:
 On 2013/11/11 09:53, RD Thrush wrote:
  Synopsis:  Firewall panic with Nov 10 snapshot
  Category:  kernel
  Environment:
  System  : OpenBSD 5.4
  Details : OpenBSD 5.4-current (GENERIC) #142: Sun Nov 10 22:52:49 
  MST 2013
   
  dera...@i386.openbsd.org:/usr/src/sys/arch/i386/compile/GENERIC
  Architecture: OpenBSD.i386
  Machine : i386
  Description:
  Soekris 5501 firewall panics an hour after booting new snapshot.  
  Appended is
  some ddb info as well as normal sendbug details.
  How-To-Repeat:
  Don't know.
  Fix:
  Revert to Nov 7 kernel
 
 I've reverted the bpf commit for now, it looks like the change is invalidating
 assumptions of the conditional around bpf_read()'s tsleep in bpf.c:439 ..

The panic is still there with snapshot from Nov 14. It's easy to reproduce:
Start darkstat and surf the web with lynx.

ddb output (typed by hand):

panic: timeout_add: to_ticks (-1)  0
Stopped at Debugger+0x5: leave 
RUN AT LEAST
DO NOT EVEN BOTHER...
ddb trace
Debugger() at Debugger+0x5
panic() at panic+0xee
timeout_add() at timeout_add+0xc8
tsleep() at tsleep+0x88
bpfread() at bpfread+0x1a4
spec_read() at spec_read+0x2a8
VOP_READ() at VOP_READ+0x32
vn_read() at vn_read+0xa1
dofilereadv() at dofilereadv+0x18a
sys_read() at sys_read+0x8f
syscall() at syscall+0x162
--- sysall (number 3) ---
end of kernel
end trace frame: 0x7f7ce6a8, count: -11
0x17d859eed17a:
ddb ps
   PID   PPID   PGRPUID  S  FLAGS  WAIT   COMMAND
 15845  24519  15845  0  2   0x83 lynx
 25272  32420  25272587  3   0x90  netio  darkstat
*32420  1  32420587  7   0x10  bpfdarkstat
  6638  1   6638  0  3   0x83  ttyin  getty
..

dmesg:

OpenBSD 5.4-current (GENERIC) #129: Thu Nov 14 00:24:28 MST 2013
dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC
real mem = 8357658624 (7970MB)
avail mem = 8127086592 (7750MB)
mainbus0 at root
bios0 at mainbus0: SMBIOS rev. 2.6 @ 0xe0010 (78 entries)
bios0: vendor LENOVO version 6QET61WW (1.31 ) date 10/26/2010
bios0: LENOVO 3626GN8
acpi0 at bios0: rev 2
acpi0: sleep states S0 S3 S4 S5
acpi0: tables DSDT FACP SSDT ECDT APIC MCFG HPET ASF! BOOT SSDT TCPA DMAR SSDT 
SSDT SSDT
acpi0: wakeup devices LID_(S3) SLPB(S3) IGBE(S4) EXP1(S4) EXP2(S4) EXP3(S4) 
EXP4(S4) EXP5(S4) EHC1(S3) EHC2(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) i5 CPU M 560 @ 2.67GHz, 2926.58 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,POPCNT,AES,NXE,LONG,LAHF,PERF,ITSC
cpu0: 256KB 64b/line 8-way L2 cache
cpu0: smt 0, core 0, package 0
cpu0: apic clock running at 133MHz
cpu at mainbus0: not configured
cpu at mainbus0: not configured
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
acpimcfg0 at acpi0 addr 0xe000, bus 0-255
acpihpet0 at acpi0: 14318179 Hz
acpiprt0 at acpi0: bus 0 (PCI0)
acpiprt1 at acpi0: bus -1 (PEG_)
acpiprt2 at acpi0: bus 13 (EXP1)
acpiprt3 at acpi0: bus -1 (EXP2)
acpiprt4 at acpi0: bus -1 (EXP3)
acpiprt5 at acpi0: bus 5 (EXP4)
acpiprt6 at acpi0: bus 2 (EXP5)
acpicpu0 at acpi0: C3, C1, PSS
acpipwrres0 at acpi0: PUBS: resource for EHC1, EHC2
acpitz0 at acpi0: critical temperature is 100 degC
acpibtn0 at acpi0: LID_
acpibtn1 at acpi0: SLPB
acpibat0 at acpi0: BAT0 model 42T4694 serial  1523 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 2926 MHz: speeds: 2667, 2666, 2533, 2399, 2266, 2133, 
1999, 1866, 1733, 1599, 1466, 1333, 1199 MHz
pci0 at mainbus0 bus 0
pchb0 at pci0 dev 0 function 0 Intel Core Host rev 0x02
vga1 at pci0 dev 2 function 0 Intel HD Graphics rev 0x02
intagp0 at vga1
agp0 at intagp0: aperture at 0xd000, size 0x1000
inteldrm0 at vga1
drm0 at inteldrm0
inteldrm0: 1280x800
wsdisplay0 at vga1 mux 1: console (std, vt100 emulation)
wsdisplay0: screen 1-5 added (std, vt100 emulation)
Intel 3400 MEI rev 0x06 at pci0 dev 22 function 0 not configured
em0 at pci0 dev 25 function 0 Intel 82577LM rev 0x06: msi, address 
f0:de:f1:44:58:45
ehci0 at pci0 dev 26 function 0 Intel 3400 USB rev 0x06: 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 3400 HD Audio rev 0x06: msi
azalia0: codecs: Conexant/0x5069, Intel/0x2804, using Conexant/0x5069
audio0 at azalia0
ppb0 at pci0 dev 28 function 0 Intel 3400 PCIE rev 0x06: msi
pci1 at ppb0 bus