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, &dst.sin_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, &dst.sin_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, &rtr_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(&rtr_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, &rtr_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

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
whi

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, &linkstat);
> > +   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 |= AX

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 mpi

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: 
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,

[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:
fmask:
use:0   mtu:0expire:0
locks:  inits:
sockaddrs: 
 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:
fmask:
use:0   mtu:0expire:0
locks:  inits:
sockaddrs: 
 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:
fmask:
use:0   mtu:0expire:0
locks:  inits:
sockaddrs: 
 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:
fmask:
use:0   mtu:0expire:0
locks:  inits:
sockaddrs: 
 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: 
 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:
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: 
 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:
fmask:
use:0   mtu:0expire:0
locks:  inits:
sockaddrs: 
 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:
fmask:
use:0   mtu:0expire:0
locks:  inits:
sockaddrs: 
 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:
fmask:
use:0   mtu:0expire:0
locks:  inits:
sockaddrs: 
 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:
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:

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:
fmask:
use:0   mtu:0expire:0
locks:  inits:
sockaddrs: 
 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:
fmask:
use:0   mtu:0expire:0
locks:  inits:
sockaddrs: 
 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:
fmask:
use:0   mtu:0expire:0
locks:  inits:
sockaddrs: 
 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:
fmask:
use:0   mtu:0expire:0
locks:  inits:
sockaddrs: 
 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: 
 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:

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.208:00:27:7d:87:23vio1 permanent l
10.0.10.10   08:00:27:1e:30:02vio1 14m55s
10.0.20.100:00:5e:00:01:17   carp2 permanent l
10.0.20.208:00:27:7e:f3:d5vio2 permanent l
10.0.20.10  

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: 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 vet

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 
To: Reyk Floeter 

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  chec

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, &aml_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-520

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: bsd.rd from May 31 fails to load the firmware for iwm-7265-16

[Remi Locherer]

On Fri, Jun 03, 2016 at 03:38:44PM +0200, Stefan Sperling wrote:
> On Thu, Jun 02, 2016 at 11:04:48PM +0200, Remi Locherer wrote:
> > On Thu, Jun 02, 2016 at 08:23:24PM +0200, Stefan Sperling wrote:
> > > On Wed, Jun 01, 2016 at 11:12:25PM +0200, Remi Locherer wrote:
> > > > >Synopsis:  bsd.rd from May 31 fails to load the firmware for 
> > > > >iwm-7265-16
> > > > >Category:  kernel
> > > > >Environment:
> > > > System  : OpenBSD 6.0
> > > > Details : OpenBSD 6.0-beta (GENERIC.MP) #26: Wed May 25 
> > > > 07:34:23 CEST 2016
> > > >  
> > > > r...@mistral.relo.ch:/usr/src/sys/arch/amd64/compile/GENERIC.MP
> > > > 
> > > > Architecture: OpenBSD.amd64
> > > > Machine : amd64
> > > > 
> > > > >Description
> > > > 
> > > > bsd.rd from May 31 fails to load the iwm firmware during an upgrade.
> > > > dmesg says:
> > > > 
> > > > iwm0: could not read firmware iwm-7265-16 (error 2)
> > > > iwm0: failed to load init firmware
> > > 
> > > The ramdisk kernel tries two directories, /etc/firmware and 
> > > /mnt/etc/firmware.
> > > 
> > > Perhaps the above failure is the attempt to load firmware from 
> > > /etc/firmware,
> > > which does not exist on the ramdisk? I've added the 'failed to load init
> > > firmware' message in the commit which made the dirver use newer firmware.
> > > Before that commit, this failure case was silent. So it is possible that
> > > nothing has changed, except for this message now being printed.
> > > 
> > > The following line indicates that the second attempt (from 
> > > /mnt/etc/firmware)
> > > works. It is only printed if firmware could be loaded successfully:
> > > 
> > > > iwm0: hw rev 0x210, fw ver 16.242414.0, address 5c:e0:c5:1f:ad:c4
> > > 
> > > > A generic kernel (not bsd.rd!) I built from source on May 31 can load 
> > > > the
> > > > iwm firmware and it works fine.
> > > 
> > > Are you implying that the device does not work in the ramdisk?
> > 
> > Yes. With the ramdisk kernel the status of iwm0 does not go to active 
> > anymore.
> > Last time I did a snapshot upgrade on this notebook it worked as expected.
> > That was on May 25.
> 
> Works for me with -current built today.
> This is what the upgrade process looks like over here (hand-copied
> from very small font on UEFI console, beware of typos):
> 
> root on rd0a swap on rd0b dump on rd0b
> iwm0: could not read firmware: iwm-7265-16 (error 2)
> iwm0: failed to load init firmware
> erase ^?, werase ^W, kill ^U, intr ^C, status ^T
> 
> Welcome to the OpenBSD/amd64 6.0 installation program.
> (I)nstall, (U)pgrade, (A)utoinstall, (S)hell? u
> At any prompt you can 
> 
> Choose your keyboard layout('?' or 'L' for list) [default]
> Available disks are: sd0 sd1 sd2.
> Which disk the root disk? ('?' for details): [sd0] sd2
> Root filesystem? [sd2a]
> Checking root filesystem (fsck -fp /dev/sd2a)...OK.
> Mounting root filesystem (mount -o ro /dev/sd2a /mnt)...OK.
> iwm0: hw rev 0x210, fw ver 16.242414.0, address 34:13:e8:37:4d:51
> iwm0: no link  got link
> DHCPDISCOVER on iwm0 - interval 3
> DHCPOFFER from 217.197.84.34 (fe:e1:54:e3:c3:90)
> DHCPREQUEST on iwm0 to 255.255.255.255
> DHCPACK from 217.197.84.34 (fe:e1:54:e3:c3:90)
> bound to 217.197.84.45 -- renewal in 18000 seconds
> Force checking fo clean non-root filesystems? [no]
> 
> It has trouble finding firmware at first, which is expected since the
> ramdisk does not have it. When the system's root filesystem is mounted,
> the firmware is loaded and the device works OK.
> 
> What's different in your case?

I don't know.

On my installation the upgrade process looks like this (snapshot bsd.rd
from Jun 2):

[...]
root on rd0a swap on rd0b dump on rd0b
iwm0: could not read firmware iwm-7265-16 (error2)
iwm0: failed to load init firmware
erase ^?, werase ^W, kill Û, intr ^C, status ^T

Welcome to the OpenBSD/amd64 6.0 installation program.
(I)nstall, (U)pgrade, (A)utoinstall or (S)hell? u
[...]

Choose your keyboard layout ('?' or 'L' for list) [default] sg
kbd: keyboard mapping set to sg
Available disks are: sd0 sd1.
Which disk is the root disk? ('?' for details) [sd0] sd1
Root filesystem? [sd1a]
Checking root filesystem [...]
Mounting root filesystem [...]
iwm0: hw rev 0x210, fw ver 16.242414.0, address 5c:e0:c5:1f:ad:c3
iwm0: no link ... sleeping
Force checking of clean non-root filesystems? [no]
fsck -p [...]

Let's upgrade the sets!
Location of sets? (disk http or 'done') [http] !
Type 'exit' to return to install.
# ifconfig iwm0
iwm0: flags=208802 mtu 1500
lladr 5c:e0:c5:1f:ad:c4
groups: wlan
media IEEE802.11 autoselect
status: unknown
ieee80211: nwid tsunami wpakey 0x136...
 wpaprotos wpa1,wpa2 wpaakms psk wpaciphers tkip,ccmp wpagroupcipher tkip
#


My /etc/hostname.iwm0:

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

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

[Remi Locherer]

On Thu, Jun 02, 2016 at 08:23:24PM +0200, Stefan Sperling wrote:
> On Wed, Jun 01, 2016 at 11:12:25PM +0200, Remi Locherer wrote:
> > >Synopsis:  bsd.rd from May 31 fails to load the firmware for iwm-7265-16
> > >Category:  kernel
> > >Environment:
> > System  : OpenBSD 6.0
> > Details : OpenBSD 6.0-beta (GENERIC.MP) #26: Wed May 25 07:34:23 
> > CEST 2016
> >  
> > r...@mistral.relo.ch:/usr/src/sys/arch/amd64/compile/GENERIC.MP
> > 
> > Architecture: OpenBSD.amd64
> > Machine : amd64
> > 
> > >Description
> > 
> > bsd.rd from May 31 fails to load the iwm firmware during an upgrade.
> > dmesg says:
> > 
> > iwm0: could not read firmware iwm-7265-16 (error 2)
> > iwm0: failed to load init firmware
> 
> The ramdisk kernel tries two directories, /etc/firmware and /mnt/etc/firmware.
> 
> Perhaps the above failure is the attempt to load firmware from /etc/firmware,
> which does not exist on the ramdisk? I've added the 'failed to load init
> firmware' message in the commit which made the dirver use newer firmware.
> Before that commit, this failure case was silent. So it is possible that
> nothing has changed, except for this message now being printed.
> 
> The following line indicates that the second attempt (from /mnt/etc/firmware)
> works. It is only printed if firmware could be loaded successfully:
> 
> > iwm0: hw rev 0x210, fw ver 16.242414.0, address 5c:e0:c5:1f:ad:c4
> 
> > A generic kernel (not bsd.rd!) I built from source on May 31 can load the
> > iwm firmware and it works fine.
> 
> Are you implying that the device does not work in the ramdisk?

Yes. With the ramdisk kernel the status of iwm0 does not go to active anymore.
Last time I did a snapshot upgrade on this notebook it worked as expected.
That was on May 25.

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&m=144277570223298&w=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: 
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,

Re: mouse pointer jumps - pms0: not in sync yet, discard input (state 3)

[Remi Locherer]

On Mon, Dec 07, 2015 at 09:35:16AM -0600, joshua stein wrote:
> On Mon, 07 Dec 2015 at 15:35:06 +0100, Remi Locherer wrote:
> > >Synopsis:  mouse pointer jumps - pms0: not in sync yet, discard input 
> > >(state 3)
> > >Category:  kernel
> > >Environment:
> > System  : OpenBSD 5.8
> > Details : OpenBSD 5.8-current (GENERIC.MP) #13: Sat Dec  5 23:06:36 
> > CET 2015
> >  
> > r...@mistral.relo.ch:/usr/src/sys/arch/amd64/compile/GENERIC.MP
> > 
> > Architecture: OpenBSD.amd64
> > Machine : amd64
> > >Description:
> > When using the touch pad on the Dell XPS 13 the mouse pointer 
> > sometimes makes unexpected jumps. xconsole fills with these messages:
> > 
> > pms0: not in sync yet, discard input (state 0)
> > pms0: not in sync yet, discard input (state 3)
> > 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)
> 
> > bios0 at mainbus0: SMBIOS rev. 2.8 @ 0xed840 (84 entries)
> > bios0: vendor Dell Inc. version "A05" date 07/14/2015
> > bios0: Dell Inc. XPS 13 9343
> 
> The Dell XPS 13 had/has numerous BIOS bugs related to is trackpad
> and keyboard that affected its developer edition (same hardware,
> just running Ubuntu) pretty badly, to the point that they stopped
> selling it for a while so they could work out the bugs.
> 
> http://bartongeorge.net/2015/08/28/recent-fixes-for-xps-13-developer-edition/
> 
> https://bugzilla.redhat.com/show_bug.cgi?id=1188439
> 
> I would recommend first updating to the latest BIOS available to see
> if they have finally fixed these problems, but if not, this will
> probably need a machine-specific hack in pms to work around this.

Thanks for the BIOS hint. I upgraded to version A07 which was released
November 26. With that I did not experience the pointer jumps. But maybe
I did not try hard enough ;). dmesg still fills up with pms0 error messages.

dmesg with new BIOS version:
OpenBSD 5.8-current (GENERIC.MP) #13: Sat Dec  5 23:06:36 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.59 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,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,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: 
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,SENSOR,ARAT
cpu2: 256KB 64b/line 8-way L2 cache
cpu2: smt 1, core 0, package 0
cpu3 at mainbus0: apid 3 (application processor)
cpu3: Intel(R) Core(TM) i5-5200U CPU @ 2.20GHz, 24

Re: On resuming from sleep, laptop with urtwn(4) USB WiFi dongle doesn't have Internet

[Remi Locherer]

On Mon, Nov 16, 2015 at 09:07:26PM -0800, aaron.mille...@gmail.com wrote:
> >Synopsis:On resuming from sleep, laptop with urtwn(4) USB WiFi dongle 
> >doesn't have Internet
> >Category:system kernel amd64
> >Environment:
>   System  : OpenBSD 5.8
>   Details : OpenBSD 5.8-current (GENERIC.MP) #1616: Sun Nov 15 
> 20:58:13 MST 2015
>
> dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
> 
>   Architecture: OpenBSD.amd64
>   Machine : amd64
> >Description:
>   I started up my laptop without ever starting X, closed the lid to
>   suspend it, and then opened it. There was no wifi even after a few 
> minutes.
>   I had to run "doas sh /etc/netstart urtwn0" to start it.

Hi Aaron

The reason for this is USB devices are detached during suspend.

You can use hotplugd(8) to automatically run the netstart script if
urtwn is inserted (which is also the case when you resume). You can find
an example attach scrip in the manual.

Remi

[SOLVED] system freeze: acpicpu setperf failed to alter frequency

[Remi Locherer]

On Sat, Jun 06, 2015 at 05:18:32PM +0200, Remi Locherer wrote:
> >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.
 
I could "fix" this problem with changing a BIOS setting. Befor the option
"Power Regulator for ProLiant" was set to 4 which means the OS is in 
controll. I now changed it to 1 which means the Hardware/BIOS takes care.

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:  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
pp

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;
> 

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: 
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,

Re: crash on urtwn removal

[Remi Locherer]

On Tue, Apr 28, 2015 at 02:10:15PM +0200, Remi Locherer wrote:
> 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.
> 

I didn't experience this bug during the last 3 weeks. But now it happened
again. Or maybe it's something different that just looks similar to a
user. 

This time "urtwn0: timeout waiting for MAC auto ON" was showed in xconsole
just after booting and before I logged in. I detached urtwn and nothing
happened. I inserted it and landed in ddb.

dmesg, ps and trace from all 4 cpus:


OpenBSD 5.7-current (GENERIC.MP) #974: Thu May 14 06:04:59 MDT 2015
dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
real mem = 3881746432 (3701MB)
avail mem = 3760259072 (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.15 MHz
cpu1: 
FPU,VME,DE,PSE,TSC,MSR,PA

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 L

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=article&sid=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()

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 a

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=8049 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=8802 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=208843 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 
 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=141 mtu 33144
priority: 0
groups: pflog
tun1: flags=8051 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 
 729 -56 urtwn0
::1::1UHl   14  
  0 32768 1 lo0  
::1 

Re: urtwn timeout and system freez

[Remi Locherer]

On Mon, Mar 09, 2015 at 11:31:56AM +0100, Martin Pieuchot wrote:
> On 07/03/15(Sat) 14:13, Remi Locherer wrote:
> > On Fri, Mar 06, 2015 at 11:24:27PM +0100, Martin Pieuchot wrote:
> > > [...]
> > > 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.
> 
> Thanks Remi, the problem is that when a pipe is aborted the stack call
> the corresponding *_abort() function even if the transfer has not yet
> been transfered.  In this case it is not in the list of pending transfer
> and we should not try to remove it.
> 
> Updated diff below to apply on top of a -current checkout.

This diff fixes the issue for me. I can now remove the urtwn device
once the "urtwn0 timeout" happens and the system continuous to work.

Remi

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 "SAMSUN

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, 100

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=28802 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=28802 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=28802 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=28843 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=28802 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=28843 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
dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
real mem = 3881746432 (3701MB)
avail mem = 3774570496 (3599MB)
mpath0 at root
scsibus0 at mpath0: 256 targets
mainbus0 at root
bios0 at mainbus0: SMBIOS rev. 2.7 @ 0xe0970 (63 entries

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: 1

Re: bgpd(8) dies when accepting phessler's spam feed

[Remi Locherer]

On Tue, Sep 23, 2014 at 06:34:50PM -0500, athom...@athompso.net wrote:
> >Synopsis:bgpd(8) dies when accepting phessler's spam feed
> >Category:user
> >Environment:
>   System  : OpenBSD 5.5
>   Details : OpenBSD 5.5 (GENERIC) #0: Fri Apr 25 13:07:59 CEST 2014
>
> r...@stable-55-amd64.mtier.org:/binpatchng/work-binpatch55-amd64/src/sys/arch/amd64/compile/GENERIC

Today bgpd also failed on my 5.5 i386 box.

>From /var/log/damon:
Oct  2 14:08:07 typhoon bgpd[7906]: neighbor 64.142.121.62: state change 
Connect -> Active, reason: Connection open failed
Oct  2 14:10:07 typhoon bgpd[7906]: neighbor 64.142.121.62: state change 
Connect -> OpenSent, reason: Connection opened
Oct  2 14:10:07 typhoon bgpd[7906]: neighbor 64.142.121.62: graceful restart of 
IPv4 unicast, not restarted, flushing
Oct  2 14:10:07 typhoon bgpd[7906]: neighbor 64.142.121.62: state change 
OpenSent -> OpenConfirm, reason: OPEN message received
Oct  2 14:10:07 typhoon bgpd[7906]: neighbor 64.142.121.62: state change 
OpenConfirm -> Established, reason: KEEPALIVE message received
Oct  2 14:10:07 typhoon bgpd[11293]: fatal in RDE: peer_up: bad state Oct  2 
14:10:07 typhoon bgpd[3779]: Lost child: route decision engine exited
Oct  2 14:10:07 typhoon bgpd[7906]: fatal in SE: session_dispatch_imsg: pipe 
closed
Oct  2 14:10:07 typhoon bgpd[3779]: Terminating


The config:
spamdAS="65066"

AS 65371
fib-update no# Mandatory, to not update the local routing table

group "spamd-bgp" {
remote-as $spamdAS
multihop 64
announce none   # Do not send Route Server any information

# rs.bgp-spamd.net
neighbor 64.142.121.62
}

# 'match' is required, to remove entries when routes are withdrawn
match from group spamd-bgp community $spamdAS:42  set pftable "bgp-spamd-bypass"


I was capturing the bgp traffic. The pcap file can be downloaded here:
https://relo.ch/bgp.pcap.gz


OpenBSD 5.5 (GENERIC) #0: Fri Apr 25 15:04:32 CEST 2014

r...@stable-55-i386.mtier.org:/binpatchng/work-binpatch55-i386/src/sys/arch/i386/compile/GENERIC
cpu0: AMD Athlon(tm) 64 Processor 3700+ ("AuthenticAMD" 686-class, 1024KB L2 
cache) 2.20 GHz
cpu0: 
FPU,V86,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,NXE,MMXX,FFXSR,LONG,3DNOW2,3DNOW,SSE3,LAHF
real mem  = 2145873920 (2046MB)
avail mem = 2098520064 (2001MB)
mainbus0 at root
bios0 at mainbus0: AT/286+ BIOS, date 10/12/06, BIOS32 rev. 0 @ 0xfb020, SMBIOS 
rev. 2.3 @ 0xf (36 entries)
bios0: vendor Phoenix Technologies, LTD version "V3.6" date 10/12/2006
bios0: MICRO-STAR INTERNATIONAL CO., LTD MS-7094
acpi0 at bios0: rev 0
acpi0: sleep states S0 S1 S4 S5
acpi0: tables DSDT FACP SRAT APIC
acpi0: wakeup devices PCI0(S5) USB0(S1) USB1(S1) USB2(S1) USB3(S1) USB4(S1) 
USB5(S1) USB6(S1) USB7(S1) LAN0(S5) AC97(S5) UAR1(S5)
acpitimer0 at acpi0: 3579545 Hz, 24 bits
acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
cpu0 at mainbus0: apid 0 (boot processor)
mtrr: Pentium Pro MTRR support, 8 var ranges, 88 fixed ranges
cpu0: apic clock running at 199MHz
ioapic0 at mainbus0: apid 2 pa 0xfec0, version 3, 24 pins
acpiprt0 at acpi0: bus 0 (PCI0)
acpicpu0 at acpi0
acpibtn0 at acpi0: PWRB
bios0: ROM list: 0xc/0xa800 0xcc000/0x1000 0xcd000/0x4c00!
cpu0: Cool'n'Quiet K8 2200 MHz: speeds: 2200 2000 1800 1000 MHz
pci0 at mainbus0 bus 0: configuration mode 1 (bios)
pchb0 at pci0 dev 0 function 0 "VIA K8HTB Host" rev 0x00
agp at pchb0 not configured
pchb1 at pci0 dev 0 function 1 "VIA K8HTB Host" rev 0x00
pchb2 at pci0 dev 0 function 2 "VIA K8HTB Host" rev 0x00
pchb3 at pci0 dev 0 function 3 "VIA K8HTB Host" rev 0x00
pchb4 at pci0 dev 0 function 4 "VIA K8HTB Host" rev 0x00
pchb5 at pci0 dev 0 function 7 "VIA K8HTB Host" rev 0x00
ppb0 at pci0 dev 1 function 0 "VIA K8HTB AGP" rev 0x00
pci1 at ppb0 bus 1
vga1 at pci1 dev 0 function 0 "ATI Rage Fury" rev 0x00
wsdisplay0 at vga1 mux 1: console (80x25, vt100 emulation)
wsdisplay0: screen 1-5 added (80x25, vt100 emulation)
rl0 at pci0 dev 9 function 0 "Realtek 8139" rev 0x10: apic 2 int 17, address 
00:e0:4c:c2:69:7c
rlphy0 at rl0 phy 0: RTL internal PHY
pciide0 at pci0 dev 15 function 0 "VIA VT6420 SATA" rev 0x80: DMA
pciide0: using apic 2 int 20 for native-PCI interrupt
wd0 at pciide0 channel 0 drive 0: 
wd0: 16-sector PIO, LBA48, 305245MB, 625142448 sectors
wd0(pciide0:0:0): using PIO mode 4, Ultra-DMA mode 6
wd1 at pciide0 channel 1 drive 0: 
wd1: 16-sector PIO, LBA48, 305245MB, 625142448 sectors
wd1(pciide0:1:0): using PIO mode 4, Ultra-DMA mode 6
pciide1 at pci0 dev 15 function 1 "VIA VT82C571 IDE" rev 0x06: ATA133, channel 
0 configured to compatibility, channel 1 configured to compatibility
pciide1: channel 0 disabled (no drives)
pciide1: channel 1 disabled (no drives)
uhci0 at pci0 dev 16 function 0 "VIA VT83C572 USB" rev 0x81: apic 2 int 21
uhci1 at pci0 dev 16 function 1 "VIA VT83C572 USB" rev 0x81: apic 2 int 21
uhci2 at pci0 dev 16 function 2 "VIA VT83C572

[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 

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 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/0x28

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 Serie

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
d

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 vga

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_

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: Samsung900X3F: wrong acpitz temperature, acpibat0 not detecting battery

[Remi Locherer]

On Fri, Mar 28, 2014 at 08:55:44AM +0100, Remi Locherer wrote:
> On Sun, Feb 23, 2014 at 03:01:14PM +0100, Mark Kettenis wrote:
> > > Date: Sun, 23 Feb 2014 13:31:10 +
> > > From: Stuart Henderson 
> > > 
> > > On 2014/02/23 10:40, Remi Locherer wrote:
> > > > On Sat, Feb 22, 2014 at 07:14:01PM +0100, Mark Kettenis wrote:
> > > > > > From: Theo de Raadt 
> > > > > > Date: Sat, 22 Feb 2014 09:55:41 -0700
> > > > > > 
> > > > > > This menas the acpitz bug must be found, and fixed.  You need to 
> > > > > > reach
> > > > > > out to an acpi hacker, like pirofti, to help diagnose the AML issue
> > > > > > which underlies this.
> > > > > 
> > > > > I had a quick look at the AML and it looks is if the embedded
> > > > > controller is involved in reading the temperature.  Perhaps SMM is
> > > > > touching it behind our back, so I looked at the global lock code again
> > > > > that is supposed to protect against that happening.
> > > > > 
> > > > > Noticed that acpiec(4) tries to acquire the global lock, but doesn't
> > > > > actually check whether it got it.  The diff below fixes this by
> > > > > unifying the code that checks for recursion and does the spinning.
> > > > > Might fix things, or might lock up the machine solidly.  Only one way
> > > > > to find out...
> > > > 
> > > > Thanks for having a look. I didn't notice any difference after I applied
> > > > your patch:
> > > > - no lock up 
> > > > - same wrong value for acpitz0 
> > > > - battery not detected
> > > > - no diff in dmesg (beside the build time of the kernel)
> > > > 
> > > > > If this doesn't help, you should check whether memory at the following
> > > > > addresses:
> > > > > 
> > > > > 0xDAF7CE18
> > > > > 0xDAF9EF18
> > > > > 0xDAF7ADC0
> > > > > 0xDAF79F98
> > > > > 
> > > > > isn't actually marked as available by the BIOS.  ACPI apparently
> > > > > stored important data at those addresses, but if OpenBSD thinks that
> > > > > memory is available and overwrites things, bad things will happen.
> > > > > 
> > > > > I believe the easiest way to find out is to type "machine memory" at
> > > > > the boot> prompt.
> > > > 
> > > > I can't see the first few lines of the "machine memory" output. Is there
> > > > a way to scroll back or use some sort of paging? Since I'm not sure how 
> > > > to
> > > > interprete the numbers I uploaded a photo from the output:
> > > > http://picpaste.com/samsung900X3F-machine-memory.png
> > > > 
> > > > Remi
> > > > 
> > > 
> > > I think you've got enough of it; the addresses above are covered
> > > by this region
> > > 
> > > Region 11: type 4 at 0xdaeef000 for 704KB
> > > 
> > > $ moo 0xdaeef000+(704*1024)
> > > 0xdaf9f0003673812992
> > > 
> > > i.e. marked as available.
> > 
> > Well Type 4 is "ACPI NVS", which means it isn't regarded as free
> > memory by OpenBSD.
> > 
> > Everything seems to point into the direction of a bug in apciec(4).
> > 
> 
> I applied the acpiec patch [1] and tested on the Samsung 900X3F. In one
> out of about 10 boots it gets the temperature and battery facts
> (or at least partly). But most of the time the behaviour is still the same
> and it just reboots because it gets the temp wrong for acpitz0 and no
> info for the battery.
> 
> Below dmesg, sysctl hw, pcidump and acpidump from a successful boot.
> 
> [1] http://marc.info/?l=openbsd-tech&m=139586828926337&w=2

I updated to a new snapshot and rebooted the notebook a couple of times
with strange effects. This time it often recognized acpitz0 correctly and 
didn't shut down imediately. But it never recognized when I connected the
A/C adapter (or removed it). Also the details about the battery where not
always (or only partly) displayd with sysctl hw.sensors or apm.

Each time the acpitz sensors were recognized correctly the keyboard back lit
was switched on. When rebooting with the reboot command after the sensors 
were recognized correctly it also worked afterwards. But when I halted the
notebook and switched it on after waiting a bit the 

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 :(

Re: volume keys not working on thinkpad x201

[Remi Locherer]

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.

I'm using cwm. Does this make a difference?

The mute key works as expected tough mixerctl said outputs.master.mute=off
while the speaker was muted.

> 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. 

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"

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

[Remi Locherer]

On Sat, Feb 22, 2014 at 07:14:01PM +0100, Mark Kettenis wrote:
> > From: Theo de Raadt 
> > Date: Sat, 22 Feb 2014 09:55:41 -0700
> > 
> > This menas the acpitz bug must be found, and fixed.  You need to reach
> > out to an acpi hacker, like pirofti, to help diagnose the AML issue
> > which underlies this.
> 
> I had a quick look at the AML and it looks is if the embedded
> controller is involved in reading the temperature.  Perhaps SMM is
> touching it behind our back, so I looked at the global lock code again
> that is supposed to protect against that happening.
> 
> Noticed that acpiec(4) tries to acquire the global lock, but doesn't
> actually check whether it got it.  The diff below fixes this by
> unifying the code that checks for recursion and does the spinning.
> Might fix things, or might lock up the machine solidly.  Only one way
> to find out...

Thanks for having a look. I didn't notice any difference after I applied
your patch:
- no lock up 
- same wrong value for acpitz0 
- battery not detected
- no diff in dmesg (beside the build time of the kernel)

> If this doesn't help, you should check whether memory at the following
> addresses:
> 
> 0xDAF7CE18
> 0xDAF9EF18
> 0xDAF7ADC0
> 0xDAF79F98
> 
> isn't actually marked as available by the BIOS.  ACPI apparently
> stored important data at those addresses, but if OpenBSD thinks that
> memory is available and overwrites things, bad things will happen.
> 
> I believe the easiest way to find out is to type "machine memory" at
> the boot> prompt.

I can't see the first few lines of the "machine memory" output. Is there
a way to scroll back or use some sort of paging? Since I'm not sure how to
interprete the numbers I uploaded a photo from the output:
http://picpaste.com/samsung900X3F-machine-memory.png

Remi

[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

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 pci