Re: Kernel panic probably linked to inteldrm

[Jérôme FRGACIC]

Ok, after further investigations, my problem does not seems to be linked 
with inteldrm. The kernel panic seems to happen randomly with or without 
inteldrm enabled.


Nevertheless, if I disable inteldrm, I can access ddb when the panic 
happen (I don't know why, BTW) and I get this.


kernel: double fault trap, code=0
Stopped at restore_saved+0x1e: xorq 0x30(%rsp),%r11

I have no stack trace with the ???trace??? command and the command ???show 
panic??? tells me that the kernel do not panic (which is... strange?). If 
I correctly look at the kernel sources, restore_saved seems to be called 
by cpu_switchto which is responsible to switch processes between the 
different processors.


Any idea about this problem?

Re: kernel panic while reproducing video with mpv

[Walter Alejandro Iglesias]

Hi Visa,

On Sun, Jun 24, 2018 at 05:54:15PM +, Visa Hankala wrote:
> On Sun, Jun 24, 2018 at 12:37:45PM +0200, Walter Alejandro Iglesias wrote:
> > panic: mtx 0x81c86470: locking against myself
> > Stopped at  db_enter+0x12:  popq%r11
> > TIDPIDUID PRFLAGS PFLAGS  CPU  COMMAND
> >  104021  96401   1000 0x3  0x4002  mpv
> > *402610  50624   10000x32  00K Xorg
> >   
> > db_enter() at db_enter+0x12
> > panic() at panic+0x138
> > __mtx_enter_try(53b9235709d40154) at __mtx_enter_try+0xb5
> > _mtx_enter(81cf3e60,81a5d6a2,0) at _mtx_enter+0x5a
> > printf(c9ef1007dec621e0) at printf+0x70
> > witness_checkorder(2e4447d1b3cbb9af,81c2ac7c,32a,0,81da6d00)
> >  at 
> > witness_checkorder+0x943
> > ___mp_lock(8000330cd760,d,7) at ___mp_lock+0x70
> > selwakeup(e80faaebded7c1a2) at selwakeup+0x9c
> > ptsstart(8ce5939828d5e23) at ptsstart+0x79
> > tputchar(174549bf676e909c,80afa400) at tputchar+0x85
> > kputchar(75d50501b895e9e4,0,81a5d6a2) at kputchar+0x91
> > kprintf() at kprintf+0xe8
> > printf(c9ef1007dec621e0) at printf+0x85
> > witness_checkorder(2e4447d1b3cba2fe,81af9df1,298,81c8a678,ff
> > ff81c8a688) at witness_checkorder+0x943
> > end trace frame: 0x80003302e978, count: 0
> 
> If the panic happens again, please run the following commands in ddb(4)
> and post the output:
> 
> show locks
> show all locks

The true is it happend twice.  On the first one fsck(8) couldn't recover
my root file system.  After rebooting I couldn't even log in (as user or
root) and I had to reinstall.  That's way I'm not confident about
"voluntary" reproducing the bug. :-)  But if it happens again take for
sure I'll send you the output of those commands (and per cpu traces).

> 
> It is not clear from the stack trace why the system begins to report
> a lock order problem in the first place (the first witness_checkorder
> and the printf at the end of the stack trace).
> 
> The panic itself is related to the problem of using other kernel
> subsystems from WITNESS. I will try to make a fix that should prevent
> the panic in most cases.


Thanks!

Walter

Re: kernel panic while reproducing video with mpv

[Visa Hankala]

On Sun, Jun 24, 2018 at 12:37:45PM +0200, Walter Alejandro Iglesias wrote:
> panic: mtx 0x81c86470: locking against myself
> Stopped at  db_enter+0x12:  popq%r11
> TIDPIDUID PRFLAGS PFLAGS  CPU  COMMAND
>  104021  96401   1000 0x3  0x4002  mpv
> *402610  50624   10000x32  00K Xorg
>   
> db_enter() at db_enter+0x12
> panic() at panic+0x138
> __mtx_enter_try(53b9235709d40154) at __mtx_enter_try+0xb5
> _mtx_enter(81cf3e60,81a5d6a2,0) at _mtx_enter+0x5a
> printf(c9ef1007dec621e0) at printf+0x70
> witness_checkorder(2e4447d1b3cbb9af,81c2ac7c,32a,0,81da6d00) 
> at 
> witness_checkorder+0x943
> ___mp_lock(8000330cd760,d,7) at ___mp_lock+0x70
> selwakeup(e80faaebded7c1a2) at selwakeup+0x9c
> ptsstart(8ce5939828d5e23) at ptsstart+0x79
> tputchar(174549bf676e909c,80afa400) at tputchar+0x85
> kputchar(75d50501b895e9e4,0,81a5d6a2) at kputchar+0x91
> kprintf() at kprintf+0xe8
> printf(c9ef1007dec621e0) at printf+0x85
> witness_checkorder(2e4447d1b3cba2fe,81af9df1,298,81c8a678,ff
> ff81c8a688) at witness_checkorder+0x943
> end trace frame: 0x80003302e978, count: 0

If the panic happens again, please run the following commands in ddb(4)
and post the output:

show locks
show all locks

It is not clear from the stack trace why the system begins to report
a lock order problem in the first place (the first witness_checkorder
and the printf at the end of the stack trace).

The panic itself is related to the problem of using other kernel
subsystems from WITNESS. I will try to make a fix that should prevent
the panic in most cases.

Re: kernel panic with cmp

[Krzysztof Strzeszewski]

Hardware was bad, now it's ok.


W dniu 17.02.2018 o 08:23, Krzysztof Strzeszewski pisze:
> Hi,
>
> I have kernel panic in OpenBSD 6.1 end 6.2 on the same machine. Command
> "cmp" is in my script , it starts every minute. When I don't use "cmp"
> command with my script, is ok. This kernel panic is after the last path
> of February 2, 2018. Kernel is default from upgrade.
>
>
> Links:
>
> #--
>
> https://nroot.pl/kernel/kernel_panic_openbsd_6.1.JPG
>
> https://nroot.pl/kernel/kernel_panic_openbsd_6.2.JPG
>
> https://nroot.pl/kernel/mem_test.JPG
>
> #--
>
>
> 
> Regards,
> Krzych
>
>
>

Re: Kernel panic with openbsd 6.2

[Tom Smyth]

Hello lads,

I have about 15 OpenBSD 6.x servers 4x 6.2 servers on
Vmware and  vmxnet net drivers,
Im running on Vmware 6.0 Update 2
( the earlier vmware 6.0 with out updates was very problmeatic)
I dont do much on Snapshots,
but I use a LSI Logic Paralell Storage Driver (SCSI)
and vmxnet3
I havent encountered any kernel panics
(when I create the VM I use the Freebsd 64 Bit OS as the installed OS
setting in vmware)
 and amd64 OpenBSD
Im using Vm virtual hardware version 11

the Nics on physical servers are a mix between Broadcom Netxtreme and
intel pro 1000

I hope this helps

Tom Smyth


On 25 January 2018 at 21:08, Rupert Gallagher  wrote:
> esxi 5.5.0 dates back to 2013.
> obsd runs better on qemu nowadays.
> To avoid the mess with x86/amd64,
> perhaps qemu-sparc with obsd-sparc
> will serve you better.
>
> Sent from ProtonMail Mobile
>
> On Fri, Jan 19, 2018 at 21:50, Mik J  wrote:
>
>> Hello, I had many kernel panic these past days. This is a 6.2 openbsd VM 
>> running on esxi 5.5

Re: Kernel panic with openbsd 6.2

[Rupert Gallagher]

esxi 5.5.0 dates back to 2013.
obsd runs better on qemu nowadays.
To avoid the mess with x86/amd64,
perhaps qemu-sparc with obsd-sparc
will serve you better.

Sent from ProtonMail Mobile

On Fri, Jan 19, 2018 at 21:50, Mik J  wrote:

> Hello, I had many kernel panic these past days. This is a 6.2 openbsd VM 
> running on esxi 5.5

Re: Kernel panic with openbsd 6.2

[trondd]

On Thu, January 25, 2018 4:29 am, Maxim Bourmistrov wrote:
> As Stuart mentioned, em(4) on top of e1000 proven to be more stable.
> Even under higher load.
> Vmx starting to misbehave under high load, resulting for ex. with unstable
> CARP setup.
>
> //mxb
>
>> 25 jan. 2018 kl. 02:40 skrev trondd :
>>
>> I am running about a dozen 6.2 -stable VMs on ESXi 6.5.  I have exactly
>> one VM that panics with vmxnet3_getbuf but only when it's being
>> snapshotted.  And not every time, but usually.
>>
>> I think once it paniced when I was snapshotting a lot of other VMs in
>> the
>> cluster but I don't trust that memory now.  I've not seen that again.
>>
>> Tim.
>>
>

I should have also said that these VMs all run postgreSQL servers.  The
busiest nears 200 simultanious connections which may be well below the
load other's are handling on their effected systems.

Tim.

Re: Kernel panic with openbsd 6.2

[Maxim Bourmistrov]

As Stuart mentioned, em(4) on top of e1000 proven to be more stable.
Even under higher load.
Vmx starting to misbehave under high load, resulting for ex. with unstable CARP 
setup.

//mxb

> 25 jan. 2018 kl. 02:40 skrev trondd :
> 
> On Mon, January 22, 2018 10:47 am, Mik J wrote:
>> Hello Stuart,
>> For me it takes just a few days...
>> I have a crash every 3/4 days maybe (2 crashes so far) and my server does
>> not handle load.
>> Yes I read your reports this morning, although you wrote that there was a
>> combination with snmpd, I have it with nginx on my side.
>> 
>> Regards
>> 
>>Le lundi 22 janvier 2018 Ã
 10:35:47 UTC+1, Stuart Henderson
>>  a écrit :
>> 
>> On 2018/01/22 00:22, Mik J wrote:
>>> Le dimanche 21 janvier 2018 Ã
 11:48:00 UTC+1, Stuart Henderson
>>>  a écrit :
>>> On 2018-01-19, Mik J  wrote:
 I had many kernel panic these past days. This is a 6.2 openbsd VM
>>> running o=
 n esxi 5.5
 
 # grep "" /tmp/if_vmx.dis
>>> 
>>> I've reported a lot of vmxnet3_getbuf panics, nobody seems interested.
>>> I suggest switching to e1000 in the vmx file, this works with the em(4)
>>> driver and has been stable so far.
>>> 
>>> 
>>> Hello Stuart,
>>> Thank you for your answer.
>>> I had my VM running for months in version 6.1 and had not problem but I
>>> reinstalled it in
>>> version 6.2 and the problem is happening.
>>> It seems to me that something in version 6.2 is producing the error.
>>> One crash today again
>> 
>> I hit this in last April, which was either 6.1 or -current from soon
>> after.
>> It can take weeks to run into it though so bisecting to find a working
>> kernel
>> is futile.
>> 
>> 
> 
> I am running about a dozen 6.2 -stable VMs on ESXi 6.5.  I have exactly
> one VM that panics with vmxnet3_getbuf but only when it's being
> snapshotted.  And not every time, but usually.
> 
> I think once it paniced when I was snapshotting a lot of other VMs in the
> cluster but I don't trust that memory now.  I've not seen that again.
> 
> Tim.
> 

Re: Kernel panic with openbsd 6.2

[trondd]

On Mon, January 22, 2018 10:47 am, Mik J wrote:
> Hello Stuart,
> For me it takes just a few days...
> I have a crash every 3/4 days maybe (2 crashes so far) and my server does
> not handle load.
> Yes I read your reports this morning, although you wrote that there was a
> combination with snmpd, I have it with nginx on my side.
>
>  Regards
>
> Le lundi 22 janvier 2018 Ã
 10:35:47 UTC+1, Stuart Henderson
>  a écrit :
>
>  On 2018/01/22 00:22, Mik J wrote:
>> Le dimanche 21 janvier 2018 Ã
 11:48:00 UTC+1, Stuart Henderson
>>  a écrit :
>> On 2018-01-19, Mik J  wrote:
>> > I had many kernel panic these past days. This is a 6.2 openbsd VM
>> running o=
>> > n esxi 5.5
>> >
>> > # grep "" /tmp/if_vmx.dis
>>
>> I've reported a lot of vmxnet3_getbuf panics, nobody seems interested.
>> I suggest switching to e1000 in the vmx file, this works with the em(4)
>> driver and has been stable so far.
>>
>>
>> Hello Stuart,
>> Thank you for your answer.
>> I had my VM running for months in version 6.1 and had not problem but I
>> reinstalled it in
>> version 6.2 and the problem is happening.
>> It seems to me that something in version 6.2 is producing the error.
>> One crash today again
>
> I hit this in last April, which was either 6.1 or -current from soon
> after.
> It can take weeks to run into it though so bisecting to find a working
> kernel
> is futile.
>
>

I am running about a dozen 6.2 -stable VMs on ESXi 6.5.  I have exactly
one VM that panics with vmxnet3_getbuf but only when it's being
snapshotted.  And not every time, but usually.

I think once it paniced when I was snapshotting a lot of other VMs in the
cluster but I don't trust that memory now.  I've not seen that again.

Tim.

Re: Kernel panic with openbsd 6.2

[Stuart Henderson]

On 2018-01-24, who one  wrote:
> Could it be related to: 
> https://newsroom.intel.com/news/root-cause-of-reboot-issue-identified-updated-guidance-for-customers-and-partners/

No.


> ?
>
>> Sent: Friday, January 19, 2018 at 9:50 PM
>> From: "Mik J" 
>> To: Misc 
>> Subject: Kernel panic with openbsd 6.2
>>
>> Hello,
>> 
>> I had many kernel panic these past days. This is a 6.2 openbsd VM running on 
>> esxi 5.5
>> 
>> I took screenshots then followed
>> https://www.openbsd.org/ddb.html
>> 
>> # objdump -dlr /sys/arch/amd64/compile/GENERIC.MP/obj/if_vmx.o > 
>> /tmp/if_vmx.dis
>> 
>> # grep "" /tmp/if_vmx.dis
>>     10f6:   e8 d5 00 00 00  callq  11d0 
>>     1176:   e8 55 00 00 00  callq  11d0 
>> 11d0 :
>>     1857:   e8 74 f9 ff ff  callq  11d0 
>> 
>> # grep -n 10f6 /tmp/if_vmx.dis
>> 1667:    10f6:  e8 d5 00 00 00  callq  11d0 
>> 
>> # grep ":" /tmp/if_vmx.dis
>> 11d0 :
>> 
>> # printf '%x\n' $((0x11d0 + 0x263))
>> 1433
>> 
>> vi /tmp/if_vmx.dis
>>    2040 1433:   ba 01 00 00 00  mov    $0x1,%edx
>> I find is on line 2040
>> 
>> => But the file is only 1251 line long
>> nl -ba /sys/dev/pci/if_vmx.c | sed -n 2040p
>> 
>> => So that last command gives me nothing
>> 
>> Do you have an idea of what mistake I did so that I can make a report ?
>> 
>> Thank you
>> 
>>
>
>

Re: Kernel panic with openbsd 6.2

[who one]

Could it be related to: 
https://newsroom.intel.com/news/root-cause-of-reboot-issue-identified-updated-guidance-for-customers-and-partners/

?

> Sent: Friday, January 19, 2018 at 9:50 PM
> From: "Mik J" 
> To: Misc 
> Subject: Kernel panic with openbsd 6.2
>
> Hello,
> 
> I had many kernel panic these past days. This is a 6.2 openbsd VM running on 
> esxi 5.5
> 
> I took screenshots then followed
> https://www.openbsd.org/ddb.html
> 
> # objdump -dlr /sys/arch/amd64/compile/GENERIC.MP/obj/if_vmx.o > 
> /tmp/if_vmx.dis
> 
> # grep "" /tmp/if_vmx.dis
>     10f6:   e8 d5 00 00 00  callq  11d0 
>     1176:   e8 55 00 00 00  callq  11d0 
> 11d0 :
>     1857:   e8 74 f9 ff ff  callq  11d0 
> 
> # grep -n 10f6 /tmp/if_vmx.dis
> 1667:    10f6:  e8 d5 00 00 00  callq  11d0 
> 
> # grep ":" /tmp/if_vmx.dis
> 11d0 :
> 
> # printf '%x\n' $((0x11d0 + 0x263))
> 1433
> 
> vi /tmp/if_vmx.dis
>    2040 1433:   ba 01 00 00 00  mov    $0x1,%edx
> I find is on line 2040
> 
> => But the file is only 1251 line long
> nl -ba /sys/dev/pci/if_vmx.c | sed -n 2040p
> 
> => So that last command gives me nothing
> 
> Do you have an idea of what mistake I did so that I can make a report ?
> 
> Thank you
> 
>

Re: Kernel panic with openbsd 6.2

[Mik J]

Hello Stuart,
For me it takes just a few days...
I have a crash every 3/4 days maybe (2 crashes so far) and my server does not 
handle load.
Yes I read your reports this morning, although you wrote that there was a 
combination with snmpd, I have it with nginx on my side.

 Regards

Le lundi 22 janvier 2018 à 10:35:47 UTC+1, Stuart Henderson 
 a écrit :  
 
 On 2018/01/22 00:22, Mik J wrote:
> Le dimanche 21 janvier 2018 à 11:48:00 UTC+1, Stuart Henderson 
>  a écrit :
> On 2018-01-19, Mik J  wrote:
> > I had many kernel panic these past days. This is a 6.2 openbsd VM running o=
> > n esxi 5.5
> >
> > # grep "" /tmp/if_vmx.dis
> 
> I've reported a lot of vmxnet3_getbuf panics, nobody seems interested.
> I suggest switching to e1000 in the vmx file, this works with the em(4)
> driver and has been stable so far.
> 
> 
> Hello Stuart,
> Thank you for your answer.
> I had my VM running for months in version 6.1 and had not problem but I 
> reinstalled it in
> version 6.2 and the problem is happening.
> It seems to me that something in version 6.2 is producing the error.
> One crash today again

I hit this in last April, which was either 6.1 or -current from soon after.
It can take weeks to run into it though so bisecting to find a working kernel
is futile.

  

Re: Kernel panic with openbsd 6.2

[Stuart Henderson]

On 2018/01/22 00:22, Mik J wrote:
> Le dimanche 21 janvier 2018 à 11:48:00 UTC+1, Stuart Henderson 
>  a écrit :
> On 2018-01-19, Mik J  wrote:
> > I had many kernel panic these past days. This is a 6.2 openbsd VM running o=
> > n esxi 5.5
> >
> > # grep "" /tmp/if_vmx.dis
> 
> I've reported a lot of vmxnet3_getbuf panics, nobody seems interested.
> I suggest switching to e1000 in the vmx file, this works with the em(4)
> driver and has been stable so far.
> 
> 
> Hello Stuart,
> Thank you for your answer.
> I had my VM running for months in version 6.1 and had not problem but I 
> reinstalled it in
> version 6.2 and the problem is happening.
> It seems to me that something in version 6.2 is producing the error.
> One crash today again

I hit this in last April, which was either 6.1 or -current from soon after.
It can take weeks to run into it though so bisecting to find a working kernel
is futile.

Re: Kernel panic with openbsd 6.2

[Mik J]

Hello Stuart,Thank you for your answer.I had my VM running for months in 
version 6.1 and had not problem but I reinstalled it in version 6.2 and the 
problem is happening.It seems to me that something in version 6.2 is producing 
the error.One crash today again
 

Le dimanche 21 janvier 2018 à 11:48:00 UTC+1, Stuart Henderson 
 a écrit :  
 
 On 2018-01-19, Mik J  wrote:
> I had many kernel panic these past days. This is a 6.2 openbsd VM running o=
> n esxi 5.5
>
> # grep "" /tmp/if_vmx.dis

I've reported a lot of vmxnet3_getbuf panics, nobody seems interested.
I suggest switching to e1000 in the vmx file, this works with the em(4)
driver and has been stable so far.


  

Re: Kernel panic with openbsd 6.2

[Stuart Henderson]

On 2018-01-19, Mik J  wrote:
> I had many kernel panic these past days. This is a 6.2 openbsd VM running o=
> n esxi 5.5
>
> # grep "" /tmp/if_vmx.dis

I've reported a lot of vmxnet3_getbuf panics, nobody seems interested.
I suggest switching to e1000 in the vmx file, this works with the em(4)
driver and has been stable so far.

Re: kernel panic i386

[Philip Guenther]

On Sat, Oct 14, 2017 at 6:57 AM, Krzysztof Strzeszewski 
wrote:

> This is very interested "the kernel did non panic".


panic() is an explicit call in the kernel, made when some sanity or
consistency check fails.  Dereferencing a bogus pointer results in a failed
page fault trap and goes to ddb directly without going through panic(), so
there's no "panic message".

(Someone looking for a kernel change to hack on?  How about this: figure
out how to make ddb's "show panic" report something useful when you entered
ddb via a kernel page fault where uvm_fault() returned EFAULT.)



> Where is memcmp in sys? When I run bsd.rd end mount filesystem I can't
> find memcmp.
>

memcmp() is a function inside the kernel, so I'm not sure what your last
statement means.

...

> ddb> trace
> memcmp(d3182800,681,9,1b) at memcmp+0x11
> k7_powernow_init(d31810c0,d0ec2f08,d022931e,d0c70730,d0a217fd) at
> k7_powernow_init+0xf8
> amd_family6_setperf_setup(d0c70730) at amd_family6_setperf_setup+0x1c
> mainbus_attach(0,d31810c0,0) at mainbus_attach+0x15e
> ...


This trace is kinda weird:  k7_powernow_init+0xf8 matches with it being a
call to k7pnow_states(), which does calls memcmp(), but where did the
intermediate stack frame go?  And why are the args to memcmp() so odd?

On top of it, nothing has really changed in the K7 code since 6.1, so the
only real change is the change in compilers from gcc to clang.  The
resulting object code is _substantially_ different: that clang doesn't
inline the memcmp() call is just one aspect.  Is there something in that
code which clang is deciding to optimize in ways that break it?

Philip Guenther

Re: kernel panic i386

[Krzysztof Strzeszewski]

This is very interested "the kernel did non panic". Where is memcmp in 
sys? When I run bsd.rd end mount filesystem I can't find memcmp.



http://wklej.org/hash/e5591ccc88f/

.
.
.
cpu0 at mainbus0: (uniprocessor)
mtrr: Pentium Pro MTRR support, 8 var ranges, 88 fixed ranges
uvm_fault(0xd0c230c0, 0xd0f2f000, 0, 1) -> e
kernel: page fault trap, code=0
Stopped at  memcmp+0x11:    repe cmpsl  (%esi),%es:(%edi)


ddb> show panic
the kernel did not panic

ddb> trace
memcmp(d3182800,681,9,1b) at memcmp+0x11
k7_powernow_init(d31810c0,d0ec2f08,d022931e,d0c70730,d0a217fd) at 
k7_powernow_i

nit+0xf8
amd_family6_setperf_setup(d0c70730) at amd_family6_setperf_setup+0x1c
mainbus_attach(0,d31810c0,0) at mainbus_attach+0x15e
config_attach(0,d0c0335c,0,0) at config_attach+0x184
config_rootfound(d09cb92c,0) at config_rootfound+0xc0
cpu_configure(944dfcd2,ec,ecf000,0,d02004ce) at cpu_configure+0x29
main(0,0,0,0,0) at main+0x478
ddb>




Regards,
Krzych


W dniu 14.10.2017 o 11:58, Philip Guenther pisze:
On Fri, Oct 13, 2017 at 12:21 PM, Krzysztof Strzeszewski 
> wrote:


When I upgrade 6.1 to 6.2 in my futro s400 i have kernel panic.


It's unfortunate that no one has submitted to dm...@openbsd.org 
 the dmesg from that hardware since February 
2016.  Please consider doing so every time you upgrade your kernel, so 
that we have a record of what is working.


 ...

cpu0 at mainbus0: (uniprocessor)
mtrr: Pentium Pro MTRR support, 8 var ranges, 88 fixed ranges
uvm_fault(0xd0c589b0, 0xd0f32000, 0, 1) -> e
kernel: page fault trap, code=0
Stopped at      memcmp+0x11:    repe cmpsl (%esi),%es:(%edi)
ddb>


https://www.openbsd.org/ddb.html

Without a backtrace, all we can see is that a copy operation in the 
kernel faulted, with no indication of *which* copy operation did so.



Philip Guenther

Re: kernel panic i386

[Philip Guenther]

On Fri, Oct 13, 2017 at 12:21 PM, Krzysztof Strzeszewski 
wrote:

> When I upgrade 6.1 to 6.2 in my futro s400 i have kernel panic.
>

It's unfortunate that no one has submitted to dm...@openbsd.org the dmesg
from that hardware since February 2016.  Please consider doing so every
time you upgrade your kernel, so that we have a record of what is working.

 ...

> cpu0 at mainbus0: (uniprocessor)
> mtrr: Pentium Pro MTRR support, 8 var ranges, 88 fixed ranges
> uvm_fault(0xd0c589b0, 0xd0f32000, 0, 1) -> e
> kernel: page fault trap, code=0
> Stopped at  memcmp+0x11:repe cmpsl  (%esi),%es:(%edi)
> ddb>
>

 https://www.openbsd.org/ddb.html

Without a backtrace, all we can see is that a copy operation in the kernel
faulted, with no indication of *which* copy operation did so.


Philip Guenther

Re: kernel panic i386

[Krzysztof Strzeszewski]

I changed only name kernel :)


W dniu 14.10.2017 o 01:13, Mike Larkin pisze:

On Fri, Oct 13, 2017 at 09:21:37PM +0200, Krzysztof Strzeszewski wrote:

Hi,
When I upgrade 6.1 to 6.2 in my futro s400 i have kernel panic.


Try 6.1 stock kernel and see if that works. Then at least we know if we
introduced a regression.

Nobody knows (or cares) what NROOT is.

-ml




http://wklej.org/hash/e590382de31/

boot>
booting hd0a:/bsd: 8154312+2282500+166852+0+1097728
[680614+82+489520+501323]=0xcc233c
entry point at 0x2000d4

[ using 1671996 bytes of bsd ELF symbol table ]
Copyright (c) 1982, 1986, 1989, 1991, 1993
 The Regents of the University of California.  All rights reserved.
Copyright (c) 1995-2017 OpenBSD. All rights reserved.
https://www.OpenBSD.org

OpenBSD 6.2 (GENERIC) #163: Tue Oct  3 19:51:20 MDT 2017
dera...@i386.openbsd.org:/usr/src/sys/arch/i386/compile/GENERIC
cpu0: AMD Athlon(tm) Processor ("AuthenticAMD" 686-class, 256KB L2
cache) 1.01 GHz
cpu0:
FPU,V86,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,MMX,FXSR,SSE,MPC,MMXX,3DNOW2,3DNOW
real mem  = 1039613952 (991MB)
avail mem = 1005654016 (959MB)
mpath0 at root
scsibus0 at mpath0: 256 targets
mainbus0 at root
bios0 at mainbus0: date 02/14/07, BIOS32 rev. 0 @ 0xfaa30, SMBIOS rev.
2.2 @ 0xf (31 entries)
bios0: vendor Phoenix Technologies, LTD version "6.00PG Rev. 4.00.0H"
date 02/14/2007
bios0: FUJITSU SIEMENS FUTRO S400
acpi0 at bios0: rev 0
acpi0: sleep states S0 S1 S4 S5
acpi0: tables DSDT FACP SSDT
acpi0: wakeup devices USB0(S5) USB1(S5) USB2(S5) USB3(S5) AMR0(S4)
UAR1(S5) PCI0(S5)
acpitimer0 at acpi0: 3579545 Hz, 24 bits
acpiprt0 at acpi0: bus 0 (PCI0)
acpicpu0 at acpi0: C1(@1 halt!), PSS
acpitz0 at acpi0: critical temperature is 100 degC
acpibtn0 at acpi0: PWRB
"PNP0401" at acpi0 not configured
"PNP0C0B" at acpi0 not configured
bios0: ROM list: 0xc/0xc000 0xcc000/0x4000! 0xd/0x1000
cpu0 at mainbus0: (uniprocessor)
mtrr: Pentium Pro MTRR support, 8 var ranges, 88 fixed ranges
uvm_fault(0xd0c589b0, 0xd0f32000, 0, 1) -> e
kernel: page fault trap, code=0
Stopped at  memcmp+0x11:repe cmpsl  (%esi),%es:(%edi)
ddb>







http://wklej.org/hash/e590382de31/

# dmesg
OpenBSD 6.1-stable (NROOT) #12: Fri Oct 13 17:15:13 CEST 2017
 krz...@nroot.pl:/usr/src/sys/arch/i386/compile/NROOT
cpu0: AMD Athlon(tm) Processor ("AuthenticAMD" 686-class, 256KB L2
cache) 1.01 GHz
cpu0:
FPU,V86,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,MMX,FXSR,SSE,MPC,MMXX,3DNOW2,3DNOW
real mem  = 1039613952 (991MB)
avail mem = 1006993408 (960MB)
mpath0 at root
scsibus0 at mpath0: 256 targets
mainbus0 at root
bios0 at mainbus0: date 05/14/08, BIOS32 rev. 0 @ 0xfaa30, SMBIOS rev.
2.2 @ 0xf (31 entries)
bios0: vendor Phoenix Technologies, LTD version "6.00PG Rev. 4.00.0Q"
date 05/14/2008
bios0: FUJITSU SIEMENS FUTRO S400
acpi0 at bios0: rev 0
acpi0: sleep states S0 S1 S4 S5
acpi0: tables DSDT FACP SSDT
acpi0: wakeup devices USB0(S5) USB1(S5) USB2(S5) USB3(S5) AMR0(S4) PCI0(S5)
acpitimer0 at acpi0: 3579545 Hz, 24 bits
acpiprt0 at acpi0: bus 0 (PCI0)
acpicpu0 at acpi0: C1(@1 halt!), PSS
acpitz0 at acpi0: critical temperature is 100 degC
acpibtn0 at acpi0: PWRB
"PNP0C0B" at acpi0 not configured
bios0: ROM list: 0xc/0xc000 0xcc000/0x4000! 0xd/0x1800
0xd2000/0x1000
cpu0 at mainbus0: (uniprocessor)
mtrr: Pentium Pro MTRR support, 8 var ranges, 88 fixed ranges
cpu0: PowerNow! K7 1001 MHz: speeds: 1000 800 667 MHz
pci0 at mainbus0 bus 0: configuration mode 1 (bios)
pchb0 at pci0 dev 0 function 0 "SiS 741 PCI" rev 0x03
sisagp0 at pchb0
agp0 at sisagp0: aperture at 0xe800, size 0x400
ppb0 at pci0 dev 1 function 0 "SiS 86C202 AGP" rev 0x00
pci1 at ppb0 bus 1
vga1 at pci1 dev 0 function 0 "SiS 6330 VGA" rev 0x00
wsdisplay0 at vga1 mux 1: console (80x25, vt100 emulation)
wsdisplay0: screen 1-5 added (80x25, vt100 emulation)
pcib0 at pci0 dev 2 function 0 "SiS 85C503 System" rev 0x25
pciide0 at pci0 dev 2 function 5 "SiS 5513 EIDE" rev 0x00: 741: DMA,
channel 0 configured to compatibility, channel 1 configured to compatibility
wd0 at pciide0 channel 0 drive 0: 
wd0: 16-sector PIO, LBA48, 57231MB, 117210240 sectors
wd0(pciide0:0:0): using PIO mode 4, Ultra-DMA mode 2
pciide0: channel 1 ignored (disabled)
ohci0 at pci0 dev 3 function 0 "SiS 5597/5598 USB" rev 0x0f: irq 4,
version 1.0, legacy support
ohci1 at pci0 dev 3 function 1 "SiS 5597/5598 USB" rev 0x0f: irq 3,
version 1.0, legacy support
ehci0 at pci0 dev 3 function 3 "SiS 7002 USB" rev 0x00: irq 7
ehci0: timed out waiting for BIOS
usb0 at ehci0: USB revision 2.0
uhub0 at usb0 configuration 1 interface 0 "SiS EHCI root hub" rev
2.00/1.00 addr 1
em0 at pci0 dev 7 function 0 "Intel 82546EB" rev 0x01: irq 10, address
00:11:0a:5b:69:e8
em1 at pci0 dev 7 function 1 "Intel 82546EB" rev 0x01: irq 11, address

Re: kernel panic i386

[Mike Larkin]

On Fri, Oct 13, 2017 at 09:21:37PM +0200, Krzysztof Strzeszewski wrote:
> Hi,
> When I upgrade 6.1 to 6.2 in my futro s400 i have kernel panic.
> 

Try 6.1 stock kernel and see if that works. Then at least we know if we
introduced a regression.

Nobody knows (or cares) what NROOT is.

-ml

> 
> 
> http://wklej.org/hash/e590382de31/
> 
> boot>
> booting hd0a:/bsd: 8154312+2282500+166852+0+1097728
> [680614+82+489520+501323]=0xcc233c
> entry point at 0x2000d4
> 
> [ using 1671996 bytes of bsd ELF symbol table ]
> Copyright (c) 1982, 1986, 1989, 1991, 1993
> The Regents of the University of California.  All rights reserved.
> Copyright (c) 1995-2017 OpenBSD. All rights reserved.
> https://www.OpenBSD.org
> 
> OpenBSD 6.2 (GENERIC) #163: Tue Oct  3 19:51:20 MDT 2017
> dera...@i386.openbsd.org:/usr/src/sys/arch/i386/compile/GENERIC
> cpu0: AMD Athlon(tm) Processor ("AuthenticAMD" 686-class, 256KB L2
> cache) 1.01 GHz
> cpu0:
> FPU,V86,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,MMX,FXSR,SSE,MPC,MMXX,3DNOW2,3DNOW
> real mem  = 1039613952 (991MB)
> avail mem = 1005654016 (959MB)
> mpath0 at root
> scsibus0 at mpath0: 256 targets
> mainbus0 at root
> bios0 at mainbus0: date 02/14/07, BIOS32 rev. 0 @ 0xfaa30, SMBIOS rev.
> 2.2 @ 0xf (31 entries)
> bios0: vendor Phoenix Technologies, LTD version "6.00PG Rev. 4.00.0H"
> date 02/14/2007
> bios0: FUJITSU SIEMENS FUTRO S400
> acpi0 at bios0: rev 0
> acpi0: sleep states S0 S1 S4 S5
> acpi0: tables DSDT FACP SSDT
> acpi0: wakeup devices USB0(S5) USB1(S5) USB2(S5) USB3(S5) AMR0(S4)
> UAR1(S5) PCI0(S5)
> acpitimer0 at acpi0: 3579545 Hz, 24 bits
> acpiprt0 at acpi0: bus 0 (PCI0)
> acpicpu0 at acpi0: C1(@1 halt!), PSS
> acpitz0 at acpi0: critical temperature is 100 degC
> acpibtn0 at acpi0: PWRB
> "PNP0401" at acpi0 not configured
> "PNP0C0B" at acpi0 not configured
> bios0: ROM list: 0xc/0xc000 0xcc000/0x4000! 0xd/0x1000
> cpu0 at mainbus0: (uniprocessor)
> mtrr: Pentium Pro MTRR support, 8 var ranges, 88 fixed ranges
> uvm_fault(0xd0c589b0, 0xd0f32000, 0, 1) -> e
> kernel: page fault trap, code=0
> Stopped at  memcmp+0x11:repe cmpsl  (%esi),%es:(%edi)
> ddb>
> 
> 
> 
> 
> 
> 
> 
> http://wklej.org/hash/e590382de31/
> 
> # dmesg
> OpenBSD 6.1-stable (NROOT) #12: Fri Oct 13 17:15:13 CEST 2017
> krz...@nroot.pl:/usr/src/sys/arch/i386/compile/NROOT
> cpu0: AMD Athlon(tm) Processor ("AuthenticAMD" 686-class, 256KB L2
> cache) 1.01 GHz
> cpu0:
> FPU,V86,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,MMX,FXSR,SSE,MPC,MMXX,3DNOW2,3DNOW
> real mem  = 1039613952 (991MB)
> avail mem = 1006993408 (960MB)
> mpath0 at root
> scsibus0 at mpath0: 256 targets
> mainbus0 at root
> bios0 at mainbus0: date 05/14/08, BIOS32 rev. 0 @ 0xfaa30, SMBIOS rev.
> 2.2 @ 0xf (31 entries)
> bios0: vendor Phoenix Technologies, LTD version "6.00PG Rev. 4.00.0Q"
> date 05/14/2008
> bios0: FUJITSU SIEMENS FUTRO S400
> acpi0 at bios0: rev 0
> acpi0: sleep states S0 S1 S4 S5
> acpi0: tables DSDT FACP SSDT
> acpi0: wakeup devices USB0(S5) USB1(S5) USB2(S5) USB3(S5) AMR0(S4) PCI0(S5)
> acpitimer0 at acpi0: 3579545 Hz, 24 bits
> acpiprt0 at acpi0: bus 0 (PCI0)
> acpicpu0 at acpi0: C1(@1 halt!), PSS
> acpitz0 at acpi0: critical temperature is 100 degC
> acpibtn0 at acpi0: PWRB
> "PNP0C0B" at acpi0 not configured
> bios0: ROM list: 0xc/0xc000 0xcc000/0x4000! 0xd/0x1800
> 0xd2000/0x1000
> cpu0 at mainbus0: (uniprocessor)
> mtrr: Pentium Pro MTRR support, 8 var ranges, 88 fixed ranges
> cpu0: PowerNow! K7 1001 MHz: speeds: 1000 800 667 MHz
> pci0 at mainbus0 bus 0: configuration mode 1 (bios)
> pchb0 at pci0 dev 0 function 0 "SiS 741 PCI" rev 0x03
> sisagp0 at pchb0
> agp0 at sisagp0: aperture at 0xe800, size 0x400
> ppb0 at pci0 dev 1 function 0 "SiS 86C202 AGP" rev 0x00
> pci1 at ppb0 bus 1
> vga1 at pci1 dev 0 function 0 "SiS 6330 VGA" rev 0x00
> wsdisplay0 at vga1 mux 1: console (80x25, vt100 emulation)
> wsdisplay0: screen 1-5 added (80x25, vt100 emulation)
> pcib0 at pci0 dev 2 function 0 "SiS 85C503 System" rev 0x25
> pciide0 at pci0 dev 2 function 5 "SiS 5513 EIDE" rev 0x00: 741: DMA,
> channel 0 configured to compatibility, channel 1 configured to compatibility
> wd0 at pciide0 channel 0 drive 0: 
> wd0: 16-sector PIO, LBA48, 57231MB, 117210240 sectors
> wd0(pciide0:0:0): using PIO mode 4, Ultra-DMA mode 2
> pciide0: channel 1 ignored (disabled)
> ohci0 at pci0 dev 3 function 0 "SiS 5597/5598 USB" rev 0x0f: irq 4,
> version 1.0, legacy support
> ohci1 at pci0 dev 3 function 1 "SiS 5597/5598 USB" rev 0x0f: irq 3,
> version 1.0, legacy support
> ehci0 at pci0 dev 3 function 3 "SiS 7002 USB" rev 0x00: irq 7
> ehci0: timed out waiting for BIOS
> usb0 at ehci0: USB revision 2.0
> uhub0 at usb0 configuration 1 interface 0 "SiS EHCI root hub" rev
> 2.00/1.00 addr 1
> em0 at 

Re: Kernel panic on Dell R210 with OpenBSD 6.0 (relayd related ?)

[Mathieu BLANC]

On Tue, May 02, 2017 at 05:03:20PM +, Stuart Henderson wrote:
> Probably the best thing to do at this point is to write a mail to bugs@:
> 
> 1. describe what the machine is doing in detail. carp? ipsec? pfsync?
> what sort of relays? include config (sanitized if necessary, but do that
> consistently).
> 
> 2. copy in the panic message and stack trace as text (re-type it,
> don't attach a picture or send a link to a picture).
> 
> 3. make it a self-contained report with description etc all in the one
> message, don't rely on people having message history.
> 
> 4. include dmesg.

Hi Stuart, 

Thx for your answer !
I didn't have the time to work on this since early may.
But from time to time, I check the commit on pf.c and I saw this one which
seemed to perfectly match my bug :
http://cvsweb.openbsd.org/cgi-bin/cvsweb/src/sys/net/pf.c?rev=1.1035=text/x-cvsweb-markup

I tried the diff, and it seems to be OK ! I can't trigger the bug right now (it
was 100% before).

So, thx you again, and special thx to bluhm@ who made the patch ! 

-- 
Mathieu

Re: Kernel panic on Dell R210 with OpenBSD 6.0 (relayd related ?)

[Stuart Henderson]

On 2017-05-02, Mathieu BLANC  wrote:
> On Wed, Mar 29, 2017 at 02:06:23PM +0200, Mathieu BLANC wrote:
>> It also kernel panics with just this pf rules :
>> # cat pf_minimal.conf 
>> set limit { states 10 }  
>> set skip on lo   
>> anchor "relayd/*"
>> pass 
>> 
>
> I upgraded the system to 6.1 release last week, the kernel panic is still here
> (with the same logs).

Probably the best thing to do at this point is to write a mail to bugs@:

1. describe what the machine is doing in detail. carp? ipsec? pfsync?
what sort of relays? include config (sanitized if necessary, but do that
consistently).

2. copy in the panic message and stack trace as text (re-type it,
don't attach a picture or send a link to a picture).

3. make it a self-contained report with description etc all in the one
message, don't rely on people having message history.

4. include dmesg.

Re: Kernel panic on Dell R210 with OpenBSD 6.0 (relayd related ?)

[Mathieu BLANC]

On Tue, May 02, 2017 at 03:44:43PM +0200, Andre Ruppert wrote:
> Hi,
> 
> Im running 6.0 amd64 on a pair of R210 with relayd, but these are R210 (II).
> 
> No kernel panics at all, and these systems are working in a live
> environment...
> 
> Regards
> Andre

Hi,

Yes, i have also several OpenBSD on R210 + 6.0 (or 6.1) + relayd and it works
like a charm. 

The only problem appeared when an admin did a REJECT (iptables) on one on the
host checked by relayd with check tcp (i tried to put all the details i could
in the previous mails).

The next step is to try with current (until now i've waited for the 6.1 release
which was very close to be released).

-- 
Mathieu

Re: Kernel panic on Dell R210 with OpenBSD 6.0 (relayd related ?)

[Andre Ruppert]

Hi,

Im running 6.0 amd64 on a pair of R210 with relayd, but these are R210 (II).

No kernel panics at all, and these systems are working in a live 
environment...


Regards
Andre



Am 02.05.17 um 15:03 schrieb Mathieu BLANC:

On Wed, Mar 29, 2017 at 02:06:23PM +0200, Mathieu BLANC wrote:

It also kernel panics with just this pf rules :
# cat pf_minimal.conf
set limit { states 10 }
set skip on lo
anchor "relayd/*"
pass



I upgraded the system to 6.1 release last week, the kernel panic is still here
(with the same logs).





smime.p7s
Description: S/MIME Cryptographic Signature

Re: Kernel panic on Dell R210 with OpenBSD 6.0 (relayd related ?)

[Mathieu BLANC]

On Wed, Mar 29, 2017 at 02:06:23PM +0200, Mathieu BLANC wrote:
> It also kernel panics with just this pf rules :
> # cat pf_minimal.conf 
> set limit { states 10 }  
> set skip on lo   
> anchor "relayd/*"
> pass 
> 

I upgraded the system to 6.1 release last week, the kernel panic is still here
(with the same logs).

-- 
Mathieu

Re: kernel panic question

[Alexei Malinin]

On 04/04/17 20:40, Stuart Henderson wrote:
>>> I have a case of OpenBSD-5.9 (i386) kernel panic.
> Upgrade.

I suspect that this kernel panic could be caused by hardware problems so
upgrade will not be a cure.
I sent the problem report to b...@openbsd.org
(http://marc.info/?l=openbsd-bugs=149130924005169=2).
Can anybody say about possible causes of this panic?


--
Alexei Malinin

Re: kernel panic question

[Stuart Henderson]

It looks more like a bug than a hw fault. Upgrading (preferably to a 
-current snapshot) means we will know whether the problem still exists or 
whether it has been fixed already and gives an easier base for anyone 
trying to track it down if it's still there.


--
 Sent from a phone, apologies for poor formatting.



On 4 April 2017 19:16:13 Alexei Malinin  wrote:


On 04/04/17 20:40, Stuart Henderson wrote:

I have a case of OpenBSD-5.9 (i386) kernel panic.

Upgrade.


I suspect that this kernel panic could be caused by hardware problems so
upgrade will not be a cure.
I sent the problem report to b...@openbsd.org
(http://marc.info/?l=openbsd-bugs=149130924005169=2).
Can anybody say about possible causes of this panic?


--
Alexei Malinin

Re: kernel panic question

[Stuart Henderson]

>> I have a case of OpenBSD-5.9 (i386) kernel panic.

Upgrade.

Re: Kernel panic during boot on Dell Inspiron 15-5558

[Stuart Henderson]

On 2017-04-02, Niko Pavlinek  wrote:
> On 2. 04. 2017 14:08, Stuart Henderson wrote:
>>
>> Please try a -current snapshot and report back. If you get it now (before
>> the kernel version moves to 6.1-current) you'll be able to safely update
>> to the proper 6.1 release when it's out.
>>
>> ACPI is really required for modern PC hardware, it is tied up with many
>> aspects of the system including cooling, I would not run a machine for
>> longer than a quick test without it.
>>
>
> Hello,
>
> No luck.  I've tried the -current snapshot released on Friday
> (31.03.2017) and the one released on Saturday (01.04.2017), but
> both have yielded the same error.
>
> If I can provide any more info I would be happy to do so.
>
>

In that case, the best option is probably to boot -current with acpi disabled
and run "sendbug" as root. It's probably simplest to use "sendbug -P >
/tmp/sendbug.txt" and copy that to another machine, then edit (please include
the information from your previous report) and send it to b...@openbsd.org.
This will include PCI tables and a base64-encoded copy of the ACPI tables.

Re: kernel panic question

[Edgar Pettijohn]

Is it a soekris? If so http://wiki.soekris.info/Installing_OpenBSD.

If not https://www.openbsd.org/report.html

Sent from my iPhone

> On Apr 3, 2017, at 8:34 AM, Alexei Malinin  wrote:
> 
> Hello.
> 
> I have a case of OpenBSD-5.9 (i386) kernel panic. I'd like to be pointed
> out to possible causes of the problem. Please tell me what info should I
> include to send useful kernel panic report.
> 
> Now I have this:
> 
> uvm_fault(0xd0ba6660, 0xdaf25000, 0, 1) -> e
> kernel: page fault trap, code=0
> Stopped at  uvm_km_doputpage+0x12:  movl0(%ebx),%edi
> ddb{0}>
> 
> 
> --
> Alexei Malinin

Re: Kernel panic during boot on Dell Inspiron 15-5558

[Niko Pavlinek]

On 2. 04. 2017 14:08, Stuart Henderson wrote:
>
> Please try a -current snapshot and report back. If you get it now (before
> the kernel version moves to 6.1-current) you'll be able to safely update
> to the proper 6.1 release when it's out.
>
> ACPI is really required for modern PC hardware, it is tied up with many
> aspects of the system including cooling, I would not run a machine for
> longer than a quick test without it.
>

Hello,

No luck.  I've tried the -current snapshot released on Friday
(31.03.2017) and the one released on Saturday (01.04.2017), but
both have yielded the same error.

If I can provide any more info I would be happy to do so.

Re: Kernel panic during boot on Dell Inspiron 15-5558

[Stuart Henderson]

On 2017-03-31, Niko Pavlinek  wrote:
> Hello,
>
> I am new to OpenBSD and am trying to install OpenBSD on my Dell laptop,
> specifically Dell Inspiron 15-5558. When I boot the installation, the
> kernel panics with pci_make_tag: bad request.  I am able to install if I
> disable acpi during boot though.
>
> I am new to this, so if I forgot something please tell me.
> Below I am including dmesg, ps and trace outputs.

Please try a -current snapshot and report back. If you get it now (before
the kernel version moves to 6.1-current) you'll be able to safely update
to the proper 6.1 release when it's out.

ACPI is really required for modern PC hardware, it is tied up with many
aspects of the system including cooling, I would not run a machine for
longer than a quick test without it.

Re: Kernel panic on Dell R210 with OpenBSD 6.0 (relayd related ?)

[Mathieu BLANC]

On Wed, Mar 29, 2017 at 10:40:08AM +0200, Mathieu BLANC wrote:
> On Tue, Mar 28, 2017 at 05:58:02PM +0200, Hiltjo Posthuma wrote:
> > On Tue, Mar 28, 2017 at 02:39:44PM +0200, Mathieu BLANC wrote:
> > > On Tue, Mar 28, 2017 at 02:22:28PM +0200, Mathieu BLANC wrote:
> > > > I can reproduce the bug (on the slave firewall) as many times as I want.
> > > > 
> > > 
> > > I've just read https://www.openbsd.org/ddb.html and saw that you need a 
> > > trace
> > > for all cpu.
> > > 
> > > http://www.hostingpics.net/viewer.php?id=238876panic9.jpg
> > > http://www.hostingpics.net/viewer.php?id=275943panic10.jpg
> > > http://www.hostingpics.net/viewer.php?id=375143panic11.jpg
> > > http://www.hostingpics.net/viewer.php?id=220012panic12.jpg
> > > 
> > > (it's a different crash from the last screenshots i've made, if it's not 
> > > good i
> > > can provide a full new set of pics)
> > > 
> > > -- 
> > > Mathieu
> > > 
> > 
> > Hey,
> > 
> > Can you also provide your pf.conf ?
> > 
> > Can you test if it also happens on -current?
> > 
> > -- 
> > Kind regards,
> > Hiltjo
> 
> Hello,
> 
> Unfortunately, i can't provide pf.conf as is (too many references to 
> customers,
> ips, etc...). But i think i can work on a minimal file which triggers the bug.
> I'll see that.
> 

It also kernel panics with just this pf rules :
# cat pf_minimal.conf 
set limit { states 10 }  
set skip on lo   
anchor "relayd/*"
pass 

-- 
Mathieu

Re: Kernel panic on Dell R210 with OpenBSD 6.0 (relayd related ?)

[Mathieu BLANC]

On Tue, Mar 28, 2017 at 05:58:02PM +0200, Hiltjo Posthuma wrote:
> On Tue, Mar 28, 2017 at 02:39:44PM +0200, Mathieu BLANC wrote:
> > On Tue, Mar 28, 2017 at 02:22:28PM +0200, Mathieu BLANC wrote:
> > > I can reproduce the bug (on the slave firewall) as many times as I want.
> > > 
> > 
> > I've just read https://www.openbsd.org/ddb.html and saw that you need a 
> > trace
> > for all cpu.
> > 
> > http://www.hostingpics.net/viewer.php?id=238876panic9.jpg
> > http://www.hostingpics.net/viewer.php?id=275943panic10.jpg
> > http://www.hostingpics.net/viewer.php?id=375143panic11.jpg
> > http://www.hostingpics.net/viewer.php?id=220012panic12.jpg
> > 
> > (it's a different crash from the last screenshots i've made, if it's not 
> > good i
> > can provide a full new set of pics)
> > 
> > -- 
> > Mathieu
> > 
> 
> Hey,
> 
> Can you also provide your pf.conf ?
> 
> Can you test if it also happens on -current?
> 
> -- 
> Kind regards,
> Hiltjo

Hello,

Unfortunately, i can't provide pf.conf as is (too many references to customers,
ips, etc...). But i think i can work on a minimal file which triggers the bug.
I'll see that.

Fur -current, my idea was to try if i didn't get any response on the list for
-stable. 

But for now, we don't have any -current in production so i'm not sure :) 

I know there are plenty of people who have -current, i'm pretty confident with
it, but it's more a question of procedure, for example how to follow -current
efficiently over time. With -release and -stable it's pretty simple, upgrade
every 6 months + a few patch and it's ok :)

-- 
Mathieu

Re: Kernel panic on Dell R210 with OpenBSD 6.0 (relayd related ?)

[Hiltjo Posthuma]

On Tue, Mar 28, 2017 at 02:39:44PM +0200, Mathieu BLANC wrote:
> On Tue, Mar 28, 2017 at 02:22:28PM +0200, Mathieu BLANC wrote:
> > I can reproduce the bug (on the slave firewall) as many times as I want.
> > 
> 
> I've just read https://www.openbsd.org/ddb.html and saw that you need a trace
> for all cpu.
> 
> http://www.hostingpics.net/viewer.php?id=238876panic9.jpg
> http://www.hostingpics.net/viewer.php?id=275943panic10.jpg
> http://www.hostingpics.net/viewer.php?id=375143panic11.jpg
> http://www.hostingpics.net/viewer.php?id=220012panic12.jpg
> 
> (it's a different crash from the last screenshots i've made, if it's not good 
> i
> can provide a full new set of pics)
> 
> -- 
> Mathieu
> 

Hey,

Can you also provide your pf.conf ?

Can you test if it also happens on -current?

-- 
Kind regards,
Hiltjo

Re: Kernel panic on Dell R210 with OpenBSD 6.0 (relayd related ?)

[Mathieu BLANC]

On Tue, Mar 28, 2017 at 02:22:28PM +0200, Mathieu BLANC wrote:
> I can reproduce the bug (on the slave firewall) as many times as I want.
> 

I've just read https://www.openbsd.org/ddb.html and saw that you need a trace
for all cpu.

http://www.hostingpics.net/viewer.php?id=238876panic9.jpg
http://www.hostingpics.net/viewer.php?id=275943panic10.jpg
http://www.hostingpics.net/viewer.php?id=375143panic11.jpg
http://www.hostingpics.net/viewer.php?id=220012panic12.jpg

(it's a different crash from the last screenshots i've made, if it's not good i
can provide a full new set of pics)

-- 
Mathieu

Re: Kernel panic on Dell R210 with OpenBSD 6.0 (relayd related ?)

[Mathieu BLANC]

On Tue, Mar 28, 2017 at 12:05:56PM +0300, Mihai Popescu wrote:
> Isn't there a CAPSLOOK written message at panic time on the screen?
> If not, look here:
> http://www.openbsd.org/report.html
> 

I can reproduce the bug (on the slave firewall) as many times as I want.

I made some screenshots. Sorry, I didn't manage to provide text logs (i'm in
DRAC). 

In http://man.openbsd.org/OpenBSD-6.0/crash i saw that i might be able to have
the ddb logs in dmesg after a warm reboot but it didn't work for me.

I don't know if you prefer http links or attached files. I have uploaded the
jpg here : 
http://www.hostingpics.net/viewer.php?id=835545panic1.jpg
http://www.hostingpics.net/viewer.php?id=149061panic2.jpg
http://www.hostingpics.net/viewer.php?id=328015panic3.jpg
http://www.hostingpics.net/viewer.php?id=730910panic4.jpg
http://www.hostingpics.net/viewer.php?id=607164panic5.jpg
http://www.hostingpics.net/viewer.php?id=272177panic6.jpg
http://www.hostingpics.net/viewer.php?id=689399panic7.jpg
http://www.hostingpics.net/viewer.php?id=499214panic8.jpg

I can attach the files if you want.

Here is my relayd conf :

_front_vip="A.B.C.D"

_front1="E.F.G.H"
_front2="I.J.K.L"

table  { $_front1 $_front2 }

redirect _http_vip {
listen on $_front_vip port http
forward to  mode source-hash check tcp
pftag RELAYD_VIP_NAT
}

On front1, if i made this command, my openbsd system crash. With DROP instead
of REJECT it's OK (tested 5-6 times) :
iptables -I INPUT -j REJECT -p tcp --dport 80 -s 

-- 
Mathieu

Re: Kernel panic on Dell R210 with OpenBSD 6.0 (relayd related ?)

[Mihai Popescu]

Isn't there a CAPSLOOK written message at panic time on the screen?
If not, look here:
http://www.openbsd.org/report.html

Re: Kernel panic on Dell R210 with OpenBSD 6.0 (relayd related ?)

[Mathieu BLANC]

On Mon, Mar 27, 2017 at 02:42:23PM +0200, Mathieu BLANC wrote:
> Hello all,
> 
> I have a pair of firewalls running 6.0 (patched with openup in october, no 
> patch
> applied since then). 
> 
> Since the upgrade, this pair has some problem with kernel
> panics (4 times since the upgrade in october).
> 
> The last one was this morning. The two firewall crashed at the same time with
> these logs :
> 
> /bsd: panic: kernel diagnostic assertion "(sk->inp == NULL) || 
> (sk->inp->inp_pf_sk == NULL)" failed: file "../../../../net/pf.c", line 6891
> /bsd: Starting stack trace...
> /bsd: panic() at panic+0x10b
> /bsd: __assert() at __assert+0x25
> /bsd: pf_state_key_unref() at pf_state_key_unref+0xc6
> /bsd: pf_pkt_unlink_state_key() at pf_pkt_unlink_state_key+0x15
> /bsd: m_free() at m_free+0xa0
> /bsd: sbdroprecord() at sbdroprecord+0x61
> /bsd: soreceive() at soreceive+0xb4f
> /bsd: recvit() at recvit+0x139
> /bsd: sys_recvfrom() at sys_recvfrom+0x9d
> /bsd: syscall() at syscall+0x27b
> /bsd: --- syscall (number 29) ---
> /bsd: end of kernel
> /bsd: end trace frame: 0x7f7dc870, count: 247
> /bsd: 0x18ccb3b21ada:
> /bsd: End of stack trace. 
> 

Hello,

This morning, another crash.

I found in daemon.log something very interesting. At the same second the
firewall crashed, i had the same resource checked by relayd which was gone down 
:

Yesterday :
Mar 27 11:51:48 fw5 relayd[94179]: host W.X.Y.Z, check tcp (16010ms,tcp connect 
timeout), state up -> down, availability 99.94%
Mar 27 11:51:48 fw5 relayd[89662]: table _http_vip: 0 added, 1 deleted, 0 
changed, 0 killed

This morning :
Mar 28 09:08:54 fw5 relayd[46733]: host W.X.Y.Z, check tcp (16010ms,tcp connect 
timeout), state up -> down, availability 99.95%
Mar 28 09:08:54 fw5 relayd[29633]: table _http_vip: 0 added, 1 deleted, 0 
changed, 0 killed

I called the admin in charge of host W.X.Y.Z. What he did on W.X.Y.Z was an
iptables REJECT command on the host (to remove it from relayd). We have tested
with DROP and it seems to not trigger the bug (i'll try to make more tests).

Re: kernel panic in OpenBSD 6.0-stable

[Infoomatic]

> At least two bugs leading to this panic have been fixed post 6.0.  I'd
> suggest you to upgrade to -current where it should work as expected.  If
> not, please send a new bug report to bugs@.

Thanks a lot! This is awesome, you manage to fix bugs faster than I can report 
them ;-)
I guess I won't have problems with -current, otherwise I will report!

Re: kernel panic in OpenBSD 6.0-stable

[Martin Pieuchot]

On 27/02/17(Mon) 19:36, Infoomatic wrote:
> Hi,
> 
> I have "managed" go get a kernel panic in OpenBSD 6.0 -stable (from 
> GENERIC.MP). Unfortunately I cannot provide you with lots of information, but 
> here is what I have:
> 
> The panic occured twice on an IBM X3550 server (CPU: Intel(R) Xeon(R) CPU 
> E5-2603 0 @ 1.80GHz, with 4GB RAM and Intel I350 Gigabit Network chips 
> onboard) and once in a VM which was
> hosted inside Linux KVM with the e1000 as network interface.
> The IBM server was configured to act as bridged and routed firewall, so we 
> had a hostname.bridge0 (with blocknonip) with em0 and em1 interfaces and 
> vether0 (having the main external ip-address of the firewall and some alias 
> addresses that are routed through into the internal network) and vether1 
> (having the primary internal ip-adress) - some hosts on the network are not 
> of my responsibility so they stayed with an external ip address (and thus we 
> need bridging).
> We carefully planned the migration from Linux/iptables to OpenBSD/PF (which 
> is really a joy to use, kudos to you devs for making me happy and enjoying 
> the time spent with PF and the rest of the system), but after we switched, 
> the hardware got a panic at night (and so did I). I could not even type via 
> USB-keyboard in ddb. And since it was already in production I did not have 
> time to fiddle around and get it working, a restart was needed. See picture 
> [1]
> 
> The second crash occured when I did a "ifconfig vether0 alias EX.TE.RN.IP 
> netmask 255.255.255.240", this time I have switched on ddb.panic=0, but the 
> server did not restart and was hung - no USB keyboard again. See pic [2]
> 
> The third crash was in a VM, where I was playing around. Here, I did not have 
> a bridge configuration, but a "ifconfig em1 alias XX.XX.XX.XX netmask 
> 255.255.255.0" resulted in picture [3], this time again without being able to 
> type in the VM. We had to switch back to the old Linux based firewall, but in 
> the VM I have not managed to reproduce this.
> 
> I would appreciate any tipps, comments or info in this matter, I am willing 
> to help if more information is needed or if I can do anything to support a 
> dev to fix this problem.

At least two bugs leading to this panic have been fixed post 6.0.  I'd
suggest you to upgrade to -current where it should work as expected.  If
not, please send a new bug report to bugs@.

Thanks,
Martin

Re: Kernel panic after upgrade -CURRENT

[Hrvoje Popovski]

On 29.1.2017. 4:13, kayasaman wrote:
> Hi,
> A very strange issue...
> After the previous update of CURRENT I started to have issues with ftpproxy 
> not loading some directories, an example being shrubbery.net rancid directory.
> Today I attempted an upgrade to see if that might kick things into gear and 
> now my OBSD machine won't boot and Kernel panics upon starting network 
> services.
> Here is an image of the hang:
> https://www.dropbox.com/s/74e5mjg7sn8jrck/20170129_025823.jpg?dl=0
> As instructed by the terminal I read through:
> https://www.openbsd.org/ddb.html
> However, I am unable to input anything on the keyboard post hang?? Basically 
> my keyboard becomes unresponsive and any key pressed does nothing.
> I am able to boot into Single User mode without panic but that's about it.
> What can I do to resolve this? Or what more info could I provide that is 
> useful, considering that I am unable to run any ddb commands??
> Thanks.
> Kaya 
> 
> 
> Sent from my Samsung Galaxy smartphone.
> 

Hi,

send this report to b...@openbsd.org. Please see this mail thread

https://www.mail-archive.com/tech@openbsd.org/msg36980.html

Re: KERNEL PANIC: HP 250 G5 Notebook PC (W4M67EA)

[James Hastings]

On Sat, Jan 07, 2017 at 03:32:22PM -0800, Mike Larkin wrote:
> Also, this is the third time (that I recall) that HP has thrown us a curveball
> in their ACPI implementation (although at least this time they seem to be
> spec-compliant and it's us missing stuff). Toshiba is another vendor that
> tends to do bizarre things.
>
> -ml
>

I own many buggy HP machines; This is a starting point / placeholder.

Index: dev/acpi/acpi.c
===
RCS file: /cvs/src/sys/dev/acpi/acpi.c,v
retrieving revision 1.317
diff -u -p -r1.317 acpi.c
--- dev/acpi/acpi.c 25 Oct 2016 06:48:58 -  1.317
+++ dev/acpi/acpi.c 8 Jan 2017 18:10:22 -
@@ -419,6 +419,10 @@ acpi_gasio(struct acpi_softc *sc, int io
else
acpiec_write(sc->sc_ec, (u_int8_t)address, len, buffer);
break;
+
+   case GAS_CMOS:
+   printf("Unsupported RegionSpace CMOS\n");
+   break;
}
return (0);
 }
Index: dev/acpi/acpireg.h
===
RCS file: /cvs/src/sys/dev/acpi/acpireg.h,v
retrieving revision 1.36
diff -u -p -r1.36 acpireg.h
--- dev/acpi/acpireg.h  10 Jul 2016 20:36:41 -  1.36
+++ dev/acpi/acpireg.h  8 Jan 2017 18:10:23 -
@@ -86,6 +86,7 @@ struct acpi_gas {
 #define GAS_PCI_CFG_SPACE  2
 #define GAS_EMBEDDED   3
 #define GAS_SMBUS  4
+#define GAS_CMOS   5
 #define GAS_FUNCTIONAL_FIXED   127
u_int8_tregister_bit_width;
u_int8_tregister_bit_offset;
Index: dev/acpi/dsdt.c
===
RCS file: /cvs/src/sys/dev/acpi/dsdt.c,v
retrieving revision 1.228
diff -u -p -r1.228 dsdt.c
--- dev/acpi/dsdt.c 18 Dec 2016 15:59:22 -  1.228
+++ dev/acpi/dsdt.c 8 Jan 2017 18:10:25 -
@@ -2470,6 +2470,7 @@ aml_rwfield(struct aml_value *fld, int b
case ACPI_OPREG_SYSIO:
case ACPI_OPREG_PCICFG:
case ACPI_OPREG_EC:
+   case ACPI_OPREG_CMOS:
aml_rwgas(ref1, fld->v_field.bitpos + bpos, blen,
val, mode, fld->v_field.flags);
break;

Re: KERNEL PANIC: HP 250 G5 Notebook PC (W4M67EA)

[Mike Larkin]

On Sat, Jan 07, 2017 at 03:32:22PM -0800, Mike Larkin wrote:
> On Mon, Jan 02, 2017 at 06:55:28AM +0900, Kyoung Jae Seo wrote:
> > On Sun, Jan 01, 2017 at 02:00:44PM +0300, Özgür Kazancci wrote:
> > > Hello,
> > > 
> > > Mike, just wanted to ask if you've had any chance of committing anything
> > > regarding the issue? Few months have passed and I'm just curious about the
> > > issue:
> > > 
> > > http://marc.info/?l=openbsd-bugs=147626115403928=2
> > > 
> > > Thanks,
> > > Happy New Year OpenBSD!
> > > 
> > 
> > Hi
> > 
> > OpenBSD stock kernel might not be able to boot in most of newer HP
> > laptops. My pavilion also fails to boot because OpenBSD kernel does not
> > have ACPI CMOS RTC handler.
> > 
> > Can you try booting kernel with ec disabled? You don't have to disable
> > it in laptop's bios just configure kernel before booting.
> > 
> > To have better idea of what is actually causing the problem you can
> > compile kernel with #define ACPI_DEBUG and boot with it. If it's indeed
> > hp ACPI CMOS issue it will fail with message : Unsupported region space
> > 5 when kernel crashes.
> > 
> > I have a wip patch based on linux's implementation but it's too
> > invasive and hacky right now for sharing. As soon as I get more time
> > I'll open up discussion in tech@ after tidying things up.
> > 
> > There was discussion on FreeBSD bugs lists of how to handle hp laptop's
> > acpi cmos some time ago but developers could not agree on resolution.
> > 
> > For those interested : 
> > https://lists.freebsd.org/pipermail/freebsd-amd64/2016-February/016620.html
> > https://wiki.freebsd.org/Laptops/HP_Envy_6Z-1100
> > 
> > Thanks.
> > 
> 
> Looks like we do need something like what Kyoung Jae Seo says. I'm happy
> to look at a diff but at the moment I don't have the hardware to look into
> this (or much free time). Even if the diff is rough, it's probably better
> to see what you have earlier rather than later.
> 
> -ml
> 

Also, this is the third time (that I recall) that HP has thrown us a curveball
in their ACPI implementation (although at least this time they seem to be
spec-compliant and it's us missing stuff). Toshiba is another vendor that
tends to do bizarre things.

-ml

Re: KERNEL PANIC: HP 250 G5 Notebook PC (W4M67EA)

[Mike Larkin]

On Mon, Jan 02, 2017 at 06:55:28AM +0900, Kyoung Jae Seo wrote:
> On Sun, Jan 01, 2017 at 02:00:44PM +0300, Özgür Kazancci wrote:
> > Hello,
> > 
> > Mike, just wanted to ask if you've had any chance of committing anything
> > regarding the issue? Few months have passed and I'm just curious about the
> > issue:
> > 
> > http://marc.info/?l=openbsd-bugs=147626115403928=2
> > 
> > Thanks,
> > Happy New Year OpenBSD!
> > 
> 
> Hi
> 
> OpenBSD stock kernel might not be able to boot in most of newer HP
> laptops. My pavilion also fails to boot because OpenBSD kernel does not
> have ACPI CMOS RTC handler.
> 
> Can you try booting kernel with ec disabled? You don't have to disable
> it in laptop's bios just configure kernel before booting.
> 
> To have better idea of what is actually causing the problem you can
> compile kernel with #define ACPI_DEBUG and boot with it. If it's indeed
> hp ACPI CMOS issue it will fail with message : Unsupported region space
> 5 when kernel crashes.
> 
> I have a wip patch based on linux's implementation but it's too
> invasive and hacky right now for sharing. As soon as I get more time
> I'll open up discussion in tech@ after tidying things up.
> 
> There was discussion on FreeBSD bugs lists of how to handle hp laptop's
> acpi cmos some time ago but developers could not agree on resolution.
> 
> For those interested : 
> https://lists.freebsd.org/pipermail/freebsd-amd64/2016-February/016620.html
> https://wiki.freebsd.org/Laptops/HP_Envy_6Z-1100
> 
> Thanks.
> 

Looks like we do need something like what Kyoung Jae Seo says. I'm happy
to look at a diff but at the moment I don't have the hardware to look into
this (or much free time). Even if the diff is rough, it's probably better
to see what you have earlier rather than later.

-ml

Re: KERNEL PANIC: HP 250 G5 Notebook PC (W4M67EA)

[Kyoung Jae Seo]

On Sun, Jan 01, 2017 at 02:00:44PM +0300, Özgür Kazancci wrote:
> Hello,
> 
> Mike, just wanted to ask if you've had any chance of committing anything
> regarding the issue? Few months have passed and I'm just curious about the
> issue:
> 
> http://marc.info/?l=openbsd-bugs=147626115403928=2
> 
> Thanks,
> Happy New Year OpenBSD!
> 

Hi

OpenBSD stock kernel might not be able to boot in most of newer HP
laptops. My pavilion also fails to boot because OpenBSD kernel does not
have ACPI CMOS RTC handler.

Can you try booting kernel with ec disabled? You don't have to disable
it in laptop's bios just configure kernel before booting.

To have better idea of what is actually causing the problem you can
compile kernel with #define ACPI_DEBUG and boot with it. If it's indeed
hp ACPI CMOS issue it will fail with message : Unsupported region space
5 when kernel crashes.

I have a wip patch based on linux's implementation but it's too
invasive and hacky right now for sharing. As soon as I get more time
I'll open up discussion in tech@ after tidying things up.

There was discussion on FreeBSD bugs lists of how to handle hp laptop's
acpi cmos some time ago but developers could not agree on resolution.

For those interested : 
https://lists.freebsd.org/pipermail/freebsd-amd64/2016-February/016620.html
https://wiki.freebsd.org/Laptops/HP_Envy_6Z-1100

Thanks.

Re: Kernel panic on 6.0-stable

[Martin Pieuchot]

On 20/11/16(Sun) 18:34, Frank Groeneveld wrote:
> On Sun, Nov 20, 2016 at 03:21:32PM +0100, Martin Pieuchot wrote:
> > On 20/11/16(Sun) 13:58, Frank Groeneveld wrote:
> > > A few week back there was an outage at my ISP. Afterwards, I kept
> > > getting crashed on igmpproxy after changing channels on the tv a few
> > > times:
> > 
> > This has been fixed in -current.
> 
> Thanks for the pointer. Does it fix both the igmpproxy crash and the
> kernel crash? Or just the igmpproxy crash?

Kernel crash.

Re: Kernel panic on 6.0-stable

[Frank Groeneveld]

On Sun, Nov 20, 2016 at 03:21:32PM +0100, Martin Pieuchot wrote:
> On 20/11/16(Sun) 13:58, Frank Groeneveld wrote:
> > A few week back there was an outage at my ISP. Afterwards, I kept
> > getting crashed on igmpproxy after changing channels on the tv a few
> > times:
> 
> This has been fixed in -current.

Thanks for the pointer. Does it fix both the igmpproxy crash and the
kernel crash? Or just the igmpproxy crash?

Frank

Re: Kernel panic on 6.0-stable

[Martin Pieuchot]

On 20/11/16(Sun) 13:58, Frank Groeneveld wrote:
> A few week back there was an outage at my ISP. Afterwards, I kept
> getting crashed on igmpproxy after changing channels on the tv a few
> times:

This has been fixed in -current.

Re: Kernel Panic

[Chris Cappuccio]

arrowscr...@mail.com [arrowscr...@mail.com] wrote:
> I login on root to restart the network and the system crashed.
> What I did:
> - Login with root on ttyC0
> - Tell dhcp that I wanted dns to localhost:
> 
> # echo "supersede domain-name-servers 127.0.0.1;" >> /etc/dhclient.conf
> 
> - Then restarted the net:
> 
> # sh /etc/netstart
> 

Can you reliably reproduce this?

> OpenBSD 5.9 (GENERIC) #1761: Fri Feb 26 01:15:04 MST 2016
> dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC

Can you reliably reproduce it with the latest snapshot?

Re: Kernel panic while fiddling with route add/delete

[DarkSoul]

I am running OpenBSD 5.8 with a GENERIC SMP kernelon a Soekris 6501.

Here is the dmesg trace immediately following the kernel panic :

panic: kernel diagnostic assertion "(t->rn_flags & RNF_ROOT) == 0"
failed: file "../../../../net/radix.c", line 294
Stopped at
OpenBSD 5.8 (GENERIC.MP) #1236: Sun Aug 16 02:31:04 MDT 2015
dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
real mem = 519962624 (495MB)
avail mem = 500367360 (477MB)
mpath0 at root
scsibus0 at mpath0: 256 targets
mainbus0 at root
bios0 at mainbus0
acpi at bios0 not configured
mpbios0 at bios0: Intel MP Specification 1.4
cpu0 at mainbus0: apid 0 (boot processor)
cpu0: Genuine Intel(R) CPU @ 600MHz, 600.08 MHz
cpu0:
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,CFLUSH,DS,A
CPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE
3,CX16,xTPR,PDCM,MOVBE,N
cpu0: 512KB 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 99MHz
cpu0: mwait min=64, max=64, C-substates=0.2.2.0.2.0.3, IBE
cpu1 at mainbus0: apid 1 (application processor)
cpu1: Genuine Intel(R) CPU @ 600MHz, 600.00 MHz
cpu1:
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,CFLUSH,DS,A
CPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE
3,CX16,xTPR,PDCM,MOVBE,N
cpu1: 512KB 64b/line 8-way L2 cache
cpu1: smt 1, core 0, package 0
mpbios0: bus 0 is type PCI
mpbios0: bus 64 is type ISA
ioapic0 at mainbus0: apid 0 pa 0xfec0, version 20, 24 pins
pci0 at mainbus0 bus 0
pchb0 at pci0 dev 0 function 0 vendor "Intel", unknown product 0x4115
rev 0x05
pchb1 at pci0 dev 1 function 0 "Intel E600 Config" rev 0x00
ppb0 at pci0 dev 23 function 0 "Intel E600 PCIE" rev 0x00
pci1 at ppb0 bus 1
ppb1 at pci1 dev 0 function 0 "Intel EG20T PCIE" rev 0x01
pci2 at ppb1 bus 2
"Intel EG20T Packet Hub" rev 0x01 at pci2 dev 0 function 0 not configured
"Intel EG20T Ethernet" rev 0x02 at pci2 dev 0 function 1 not configured
"Intel EG20T GPIO" rev 0x01 at pci2 dev 0 function 2 not configured
ohci0 at pci2 dev 2 function 0 "Intel EG20T USB" rev 0x02: apic 0 int
19, version 1.0
ohci1 at pci2 dev 2 function 1 "Intel EG20T USB" rev 0x02: apic 0 int
19, version 1.0
ohci2 at pci2 dev 2 function 2 "Intel EG20T USB" rev 0x02: apic 0 int
19, version 1.0
ehci0 at pci2 dev 2 function 3 "Intel EG20T USB" rev 0x02: apic 0 int 19
usb0 at ehci0: USB revision 2.0
uhub0 at usb0 "Intel EHCI root hub" rev 2.00/1.00 addr 1
"Intel EG20T USB Client" rev 0x02 at pci2 dev 2 function 4 not configured
sdhc0 at pci2 dev 4 function 0 "Intel EG20T SDIO" rev 0x01: apic 0 int 18
sdmmc0 at sdhc0
sdhc1 at pci2 dev 4 function 1 "Intel EG20T SDIO" rev 0x01: apic 0 int 18
sdmmc1 at sdhc1
ahci0 at pci2 dev 6 function 0 "Intel EG20T AHCI" rev 0x02: msi, AHCI 1.1
ahci0: port 0: 3.0Gb/s
scsibus1 at ahci0: 32 targets
sd0 at scsibus1 targ 0 lun 0:  SCSI3
0/direct fixed naa.5002538043584d30
sd0: 30533MB, 512 bytes/sector, 62533296 sectors, thin
ohci3 at pci2 dev 8 function 0 "Intel EG20T USB" rev 0x02: apic 0 int
16, version 1.0
ohci4 at pci2 dev 8 function 1 "Intel EG20T USB" rev 0x02: apic 0 int
16, version 1.0
ohci5 at pci2 dev 8 function 2 "Intel EG20T USB" rev 0x02: apic 0 int
16, version 1.0
ehci1 at pci2 dev 8 function 3 "Intel EG20T USB" rev 0x02: apic 0 int 16
usb1 at ehci1: USB revision 2.0
uhub1 at usb1 "Intel EHCI root hub" rev 2.00/1.00 addr 1
"Intel EG20T DMA" rev 0x00 at pci2 dev 10 function 0 not configured
puc0 at pci2 dev 10 function 1 "Intel EG20T Serial" rev 0x01: ports: 1 com
com4 at puc0 port 0 apic 0 int 19: ti16750, 64 byte fifo
puc1 at pci2 dev 10 function 2 "Intel EG20T Serial" rev 0x00: ports: 1 com
com5 at puc1 port 0 apic 0 int 19: ti16750, 64 byte fifo
puc2 at pci2 dev 10 function 3 "Intel EG20T Serial" rev 0x00: ports: 1 com
com6 at puc2 port 0 apic 0 int 19: ti16750, 64 byte fifo
puc3 at pci2 dev 10 function 4 "Intel EG20T Serial" rev 0x00: ports: 1 com
com7 at puc3 port 0 apic 0 int 19: ti16750, 64 byte fifo
"Intel EG20T DMA" rev 0x00 at pci2 dev 12 function 0 not configured
"Intel EG20T SPI" rev 0x00 at pci2 dev 12 function 1 not configured
"Intel EG20T I2C" rev 0x00 at pci2 dev 12 function 2 not configured
"Intel EG20T CAN" rev 0x00 at pci2 dev 12 function 3 not configured
"Intel EG20T 1588" rev 0x01 at pci2 dev 12 function 4 not configured
usb2 at ohci0: USB revision 1.0
uhub2 at usb2 "Intel OHCI root hub" rev 1.00/1.00 addr 1
usb3 at ohci1: USB revision 1.0
uhub3 at usb3 "Intel OHCI root hub" rev 1.00/1.00 addr 1
usb4 at ohci2: USB revision 1.0
uhub4 at usb4 "Intel OHCI root hub" rev 1.00/1.00 addr 1
usb5 at ohci3: USB revision 1.0
uhub5 at usb5 "Intel OHCI root hub" rev 1.00/1.00 addr 1
usb6 at ohci4: USB revision 1.0
uhub6 at usb6 "Intel OHCI root hub" rev 1.00/1.00 addr 1
usb7 at ohci5: USB revision 1.0
uhub7 at usb7 "Intel OHCI root hub" rev 1.00/1.00 addr 1
ppb2 at pci0 dev 24 function 0 "Intel 

Re: Kernel panic while fiddling with route add/delete

[Martin Pieuchot]

On 20/03/16(Sun) 03:59, DarkSoul wrote:
> Hello list,
> 
> I was testing out a beta IPv6 service over PPPoE that our ISP is
> developping,
> and playing around with kernel PPPoE.
> 
> My configuration is as follows :
> - pppoe0 for IPv4 internet
> - gif0 for IPv6 internet (Hurricane Electric tunnel)
> - pppoe1 for test IPv6 internet (and only IPv6)
> 
> It was kind of tricky since I played with route add/delete in succession,
> along with destroying and rebuilding the interface (with /etc/netstart)
> in order to find out what configuration could work :
> - automatic ?
> - static ? (By giving my own alias definition)
> 
> I was also testing what IPv6 routes would work as a default route :
>   route add -inet6 default -ifp pppoe1 
> With ADDR being fe80:: or ff02::1%pppoe1, and such.
> (Some site even suggested ::0.0.0.1 but I think there is no way this
> could work since this translates to ::1 ultimately)
> 
> I also tested adding dummy IPv4 configuration lines like :
> inet 0.0.0.0 255.255.255.255 NONE
> dest 0.0.0.1
> 
> At one point, when trying out the above, "sh /etc/netstart pppoe1" just
> hanged on me,
> and upon rebooting, dmesg contained the following :
> panic: kernel diagnostic assertion "(t->rn_flags & RNF_ROOT) == 0"
> failed: file "../../../../net/radix.c", line 294
> 
> Since I was caught off-guard, I had no serial console lined up to catch
> the full trace.
> I'm just posting this in hopes this rings a bell to anyone.
> 
> Sorry for not having more info,
> I will try to reproduce it and post further findings.

Which version of OpenBSD are you running?  Could you at least post a
dmesg?

Re: Kernel panic during installation

[Stuart Henderson]

On 2016-02-12, Donald Allen  wrote:
> On Fri, Feb 12, 2016 at 3:42 PM, Stefan Sperling  wrote:
>
>> On Fri, Feb 12, 2016 at 03:03:46PM -0500, Donald Allen wrote:
>> > I just used this exchange as an example to a friend who buys everything
>> > Apple and then complains when their software is buggy. This is a perfect
>> > example of how a direct negative feedback path makes software converge
>> > quickly to correctness, something you don't get with the big proprietary
>> > players like Apple, Microsoft, etc.
>>
>> That's correct, and it's why we're all here.
>>
>> Make sure your friend understands that we're not trying to provide a
>> drop-in replacement for Apple, to avoid potential disappointment ;-)
>>
>
> Now *I'm* disappointed. I was looking forward to the OpenBSD equivalent of
> Siri, which I expected would be called Theo. Can you imagine the response
> to "Theo -- where is the nearest good pizza place?".

mg
(esc) x theo

Re: Kernel panic during installation

[Ingo Schwarze]

Stuart Henderson wrote on Sat, Feb 13, 2016 at 08:45:35PM +:
> On 2016-02-12, Donald Allen  wrote:
>> On Fri, Feb 12, 2016 at 3:42 PM, Stefan Sperling  wrote:
>>> On Fri, Feb 12, 2016 at 03:03:46PM -0500, Donald Allen wrote:

 I just used this exchange as an example to a friend who buys everything
 Apple and then complains when their software is buggy. This is a perfect
 example of how a direct negative feedback path makes software converge
 quickly to correctness, something you don't get with the big proprietary
 players like Apple, Microsoft, etc.

>>> That's correct, and it's why we're all here.
>>> Make sure your friend understands that we're not trying to provide a
>>> drop-in replacement for Apple, to avoid potential disappointment ;-)

>> Now *I'm* disappointed. I was looking forward to the OpenBSD equivalent
>> of Siri, which I expected would be called Theo. Can you imagine the
>> response to "Theo -- where is the nearest good pizza place?".

> mg
> (esc) x theo

But, but,...  he neither talks about The Hose And Hound in Inglewood
in that mode, nor do they serve pizza!

SCNR,
  Ingo

Re: Kernel panic during installation

[Stefan Sperling]

On Thu, Feb 11, 2016 at 08:42:21PM -0500, Donald Allen wrote:
> When attempting to install the 2/8 snapshot on my Thinkpad x-250, I chose
> to configure the wireless network interface (iwm). This resulted in the
> following:
> 
> iwm0: could not read firmware iwm-7265-9 (error 2)
> panic: attempt to execute user address 0x0 in supervisor mode

Do you have a trace from ddb please?

Re: Kernel panic during installation

[Donald Allen]

On Feb 12, 2016 05:08, "Stefan Sperling"  wrote:
>
> On Thu, Feb 11, 2016 at 08:42:21PM -0500, Donald Allen wrote:
> > When attempting to install the 2/8 snapshot on my Thinkpad x-250, I
chose
> > to configure the wireless network interface (iwm). This resulted in the
> > following:
> >
> > iwm0: could not read firmware iwm-7265-9 (error 2)
> > panic: attempt to execute user address 0x0 in supervisor mode
>
> Do you have a trace from ddb please?

There was no entry to ddb. There was one additional message after the above:

syncing disks... done

and that was all she wrote. (I took a photo of the screen.)

If you have a suggestion for how to get the trace, I will certainly try to
help. Or maybe build a kernel with some additional printfs to try to
isolate where this is happening?

Re: Kernel panic during installation

[Stefan Sperling]

On Fri, Feb 12, 2016 at 10:47:16AM -0500, Donald Allen wrote:
> On Fri, Feb 12, 2016 at 10:45 AM, Chris Cappuccio  wrote:
> 
> > Donald Allen [donaldcal...@gmail.com] wrote:
> > > On Feb 12, 2016 05:08, "Stefan Sperling"  wrote:
> > > >
> > > > On Thu, Feb 11, 2016 at 08:42:21PM -0500, Donald Allen wrote:
> > > > > When attempting to install the 2/8 snapshot on my Thinkpad x-250, I
> > > chose
> > > > > to configure the wireless network interface (iwm). This resulted in
> > the
> > > > > following:
> > > > >
> > > > > iwm0: could not read firmware iwm-7265-9 (error 2)
> > > > > panic: attempt to execute user address 0x0 in supervisor mode
> > > >
> > > > Do you have a trace from ddb please?
> > >
> > > There was no entry to ddb. There was one additional message after the
> > above:
> > >
> > > syncing disks... done
> > >
> > > and that was all she wrote. (I took a photo of the screen.)
> > >
> > > If you have a suggestion for how to get the trace, I will certainly try
> > to
> > > help. Or maybe build a kernel with some additional printfs to try to
> > > isolate where this is happening?
> >
> > sysctl ddb.panic=1 ??
> >
> 
> Ah .. thank you. I'll give it a try.
> 

No need. I could reproduce locally. The problem also shows up with
a GENERIC kernel when the firmware is not installed.

For some reason, the callbacks into the wireless stack aren't hooked
up until after the firmware is loaded. There is no reason not do hook
them up ealier. This diff fixes the crash for me.

Index: if_iwm.c
===
RCS file: /cvs/src/sys/dev/pci/if_iwm.c,v
retrieving revision 1.77
diff -u -p -r1.77 if_iwm.c
--- if_iwm.c5 Feb 2016 16:08:44 -   1.77
+++ if_iwm.c12 Feb 2016 16:10:48 -
@@ -6642,18 +6642,6 @@ iwm_preinit(struct iwm_softc *sc)
printf("%s: could not set MAC address (error %d)\n",
DEVNAME(sc), error);
 
-   ic->ic_node_alloc = iwm_node_alloc;
-
-   /* Override 802.11 state transition machine. */
-   sc->sc_newstate = ic->ic_newstate;
-   ic->ic_newstate = iwm_newstate;
-   ic->ic_update_htprot = iwm_update_htprot;
-   ic->ic_ampdu_rx_start = iwm_ampdu_rx_start;
-   ic->ic_ampdu_rx_stop = iwm_ampdu_rx_stop;
-#ifdef notyet
-   ic->ic_ampdu_tx_start = iwm_ampdu_tx_start;
-   ic->ic_ampdu_tx_stop = iwm_ampdu_tx_stop;
-#endif
ieee80211_media_init(ifp, iwm_media_change, ieee80211_media_status);
 
return 0;
@@ -6886,6 +6874,18 @@ iwm_attach(struct device *parent, struct
task_set(>ba_task, iwm_ba_task, sc);
task_set(>htprot_task, iwm_htprot_task, sc);
 
+   ic->ic_node_alloc = iwm_node_alloc;
+
+   /* Override 802.11 state transition machine. */
+   sc->sc_newstate = ic->ic_newstate;
+   ic->ic_newstate = iwm_newstate;
+   ic->ic_update_htprot = iwm_update_htprot;
+   ic->ic_ampdu_rx_start = iwm_ampdu_rx_start;
+   ic->ic_ampdu_rx_stop = iwm_ampdu_rx_stop;
+#ifdef notyet
+   ic->ic_ampdu_tx_start = iwm_ampdu_tx_start;
+   ic->ic_ampdu_tx_stop = iwm_ampdu_tx_stop;
+#endif
/*
 * We cannot read the MAC address without loading the
 * firmware from disk. Postpone until mountroot is done.

Re: Kernel panic during installation

[Chris Cappuccio]

Donald Allen [donaldcal...@gmail.com] wrote:
> On Feb 12, 2016 05:08, "Stefan Sperling"  wrote:
> >
> > On Thu, Feb 11, 2016 at 08:42:21PM -0500, Donald Allen wrote:
> > > When attempting to install the 2/8 snapshot on my Thinkpad x-250, I
> chose
> > > to configure the wireless network interface (iwm). This resulted in the
> > > following:
> > >
> > > iwm0: could not read firmware iwm-7265-9 (error 2)
> > > panic: attempt to execute user address 0x0 in supervisor mode
> >
> > Do you have a trace from ddb please?
> 
> There was no entry to ddb. There was one additional message after the above:
> 
> syncing disks... done
> 
> and that was all she wrote. (I took a photo of the screen.)
> 
> If you have a suggestion for how to get the trace, I will certainly try to
> help. Or maybe build a kernel with some additional printfs to try to
> isolate where this is happening?

sysctl ddb.panic=1 ??

Re: Kernel panic during installation

[Donald Allen]

On Fri, Feb 12, 2016 at 10:45 AM, Chris Cappuccio  wrote:

> Donald Allen [donaldcal...@gmail.com] wrote:
> > On Feb 12, 2016 05:08, "Stefan Sperling"  wrote:
> > >
> > > On Thu, Feb 11, 2016 at 08:42:21PM -0500, Donald Allen wrote:
> > > > When attempting to install the 2/8 snapshot on my Thinkpad x-250, I
> > chose
> > > > to configure the wireless network interface (iwm). This resulted in
> the
> > > > following:
> > > >
> > > > iwm0: could not read firmware iwm-7265-9 (error 2)
> > > > panic: attempt to execute user address 0x0 in supervisor mode
> > >
> > > Do you have a trace from ddb please?
> >
> > There was no entry to ddb. There was one additional message after the
> above:
> >
> > syncing disks... done
> >
> > and that was all she wrote. (I took a photo of the screen.)
> >
> > If you have a suggestion for how to get the trace, I will certainly try
> to
> > help. Or maybe build a kernel with some additional printfs to try to
> > isolate where this is happening?
>
> sysctl ddb.panic=1 ??
>

Ah .. thank you. I'll give it a try.

Re: Kernel panic during installation

[Donald Allen]

On Fri, Feb 12, 2016 at 11:17 AM, Stefan Sperling  wrote:

> On Fri, Feb 12, 2016 at 10:47:16AM -0500, Donald Allen wrote:
> > On Fri, Feb 12, 2016 at 10:45 AM, Chris Cappuccio 
> wrote:
> >
> > > Donald Allen [donaldcal...@gmail.com] wrote:
> > > > On Feb 12, 2016 05:08, "Stefan Sperling"  wrote:
> > > > >
> > > > > On Thu, Feb 11, 2016 at 08:42:21PM -0500, Donald Allen wrote:
> > > > > > When attempting to install the 2/8 snapshot on my Thinkpad
> x-250, I
> > > > chose
> > > > > > to configure the wireless network interface (iwm). This resulted
> in
> > > the
> > > > > > following:
> > > > > >
> > > > > > iwm0: could not read firmware iwm-7265-9 (error 2)
> > > > > > panic: attempt to execute user address 0x0 in supervisor mode
> > > > >
> > > > > Do you have a trace from ddb please?
> > > >
> > > > There was no entry to ddb. There was one additional message after the
> > > above:
> > > >
> > > > syncing disks... done
> > > >
> > > > and that was all she wrote. (I took a photo of the screen.)
> > > >
> > > > If you have a suggestion for how to get the trace, I will certainly
> try
> > > to
> > > > help. Or maybe build a kernel with some additional printfs to try to
> > > > isolate where this is happening?
> > >
> > > sysctl ddb.panic=1 ??
> > >
> >
> > Ah .. thank you. I'll give it a try.
> >
>
> No need. I could reproduce locally. The problem also shows up with
> a GENERIC kernel when the firmware is not installed.
>
> For some reason, the callbacks into the wireless stack aren't hooked
> up until after the firmware is loaded. There is no reason not do hook
> them up ealier. This diff fixes the crash for me.
>

Thanks.

I just used this exchange as an example to a friend who buys everything
Apple and then complains when their software is buggy. This is a perfect
example of how a direct negative feedback path makes software converge
quickly to correctness, something you don't get with the big proprietary
players like Apple, Microsoft, etc.

>
> Index: if_iwm.c
> ===
> RCS file: /cvs/src/sys/dev/pci/if_iwm.c,v
> retrieving revision 1.77
> diff -u -p -r1.77 if_iwm.c
> --- if_iwm.c5 Feb 2016 16:08:44 -   1.77
> +++ if_iwm.c12 Feb 2016 16:10:48 -
> @@ -6642,18 +6642,6 @@ iwm_preinit(struct iwm_softc *sc)
> printf("%s: could not set MAC address (error %d)\n",
> DEVNAME(sc), error);
>
> -   ic->ic_node_alloc = iwm_node_alloc;
> -
> -   /* Override 802.11 state transition machine. */
> -   sc->sc_newstate = ic->ic_newstate;
> -   ic->ic_newstate = iwm_newstate;
> -   ic->ic_update_htprot = iwm_update_htprot;
> -   ic->ic_ampdu_rx_start = iwm_ampdu_rx_start;
> -   ic->ic_ampdu_rx_stop = iwm_ampdu_rx_stop;
> -#ifdef notyet
> -   ic->ic_ampdu_tx_start = iwm_ampdu_tx_start;
> -   ic->ic_ampdu_tx_stop = iwm_ampdu_tx_stop;
> -#endif
> ieee80211_media_init(ifp, iwm_media_change,
> ieee80211_media_status);
>
> return 0;
> @@ -6886,6 +6874,18 @@ iwm_attach(struct device *parent, struct
> task_set(>ba_task, iwm_ba_task, sc);
> task_set(>htprot_task, iwm_htprot_task, sc);
>
> +   ic->ic_node_alloc = iwm_node_alloc;
> +
> +   /* Override 802.11 state transition machine. */
> +   sc->sc_newstate = ic->ic_newstate;
> +   ic->ic_newstate = iwm_newstate;
> +   ic->ic_update_htprot = iwm_update_htprot;
> +   ic->ic_ampdu_rx_start = iwm_ampdu_rx_start;
> +   ic->ic_ampdu_rx_stop = iwm_ampdu_rx_stop;
> +#ifdef notyet
> +   ic->ic_ampdu_tx_start = iwm_ampdu_tx_start;
> +   ic->ic_ampdu_tx_stop = iwm_ampdu_tx_stop;
> +#endif
> /*
>  * We cannot read the MAC address without loading the
>  * firmware from disk. Postpone until mountroot is done.

Re: Kernel panic during installation

[Stefan Sperling]

On Fri, Feb 12, 2016 at 03:03:46PM -0500, Donald Allen wrote:
> I just used this exchange as an example to a friend who buys everything
> Apple and then complains when their software is buggy. This is a perfect
> example of how a direct negative feedback path makes software converge
> quickly to correctness, something you don't get with the big proprietary
> players like Apple, Microsoft, etc.

That's correct, and it's why we're all here.

Make sure your friend understands that we're not trying to provide a
drop-in replacement for Apple, to avoid potential disappointment ;-)

Re: Kernel panic during installation

[Donald Allen]

On Fri, Feb 12, 2016 at 3:42 PM, Stefan Sperling  wrote:

> On Fri, Feb 12, 2016 at 03:03:46PM -0500, Donald Allen wrote:
> > I just used this exchange as an example to a friend who buys everything
> > Apple and then complains when their software is buggy. This is a perfect
> > example of how a direct negative feedback path makes software converge
> > quickly to correctness, something you don't get with the big proprietary
> > players like Apple, Microsoft, etc.
>
> That's correct, and it's why we're all here.
>
> Make sure your friend understands that we're not trying to provide a
> drop-in replacement for Apple, to avoid potential disappointment ;-)
>

Now *I'm* disappointed. I was looking forward to the OpenBSD equivalent of
Siri, which I expected would be called Theo. Can you imagine the response
to "Theo -- where is the nearest good pizza place?".

Re: kernel panic - panic: ehci_device_clear_toggle: queue active

[Martin Pieuchot]

On 30/11/15(Mon) 18:28, Björn Ketelaars wrote:
> Hello,
> 
> I repeatedly hit the kernel panic below. Easy to reproduce as it happens over
> and over again within 60 minutes after rebooting. Root cause is not known.
> 
> I'm running snapshot on an USB stick. I tried different USB ports with the 
> same
> result. Next step will be an attempt with a different USB stick.
> 
> I think this issue has been mentioned before:
> 
> https://marc.info/?t=14184059141=1=3
> http://openbsd-archive.7691.n7.nabble.com/panic-ehci-device-clear-toggle-queue-active-td231729.html
> http://article.gmane.org/gmane.os.openbsd.bugs/19812/
> 
> Any ideas on how to tackle this issue?

You can try the diff below and tell me if it helps.

Index: ehci.c
===
RCS file: /cvs/src/sys/dev/usb/ehci.c,v
retrieving revision 1.187
diff -u -p -r1.187 ehci.c
--- ehci.c  26 Jun 2015 11:17:34 -  1.187
+++ ehci.c  14 Oct 2015 14:24:19 -
@@ -188,12 +188,11 @@ int   ehci_alloc_sitd_chain(struct ehci_s
 void   ehci_abort_isoc_xfer(struct usbd_xfer *xfer,
usbd_status status);
 
-usbd_statusehci_device_setintr(struct ehci_softc *, struct ehci_soft_qh *,
-   int ival);
+struct ehci_soft_qh * ehci_intr_get_sqh(struct usbd_pipe *);
 
-void   ehci_add_qh(struct ehci_soft_qh *, struct ehci_soft_qh *);
-void   ehci_rem_qh(struct ehci_softc *, struct ehci_soft_qh *);
-void   ehci_set_qh_qtd(struct ehci_soft_qh *, struct ehci_soft_qtd *);
+void   ehci_add_qh(struct usbd_pipe *, struct ehci_soft_qh *,
+   struct ehci_soft_qtd *);
+void   ehci_rem_qh(struct ehci_softc *, struct usbd_pipe *);
 void   ehci_sync_hc(struct ehci_softc *);
 
 void   ehci_close_pipe(struct usbd_pipe *);
@@ -413,7 +412,6 @@ ehci_init(struct ehci_softc *sc)
sqh->qh.qh_qtd.qtd_next = htole32(EHCI_LINK_TERMINATE);
sqh->qh.qh_qtd.qtd_altnext = htole32(EHCI_LINK_TERMINATE);
sqh->qh.qh_qtd.qtd_status = htole32(EHCI_QTD_HALTED);
-   sqh->sqtd = NULL;
usb_syncmem(>dma, sqh->offs, sizeof(sqh->qh),
BUS_DMASYNC_PREWRITE | BUS_DMASYNC_PREREAD);
}
@@ -444,7 +442,6 @@ ehci_init(struct ehci_softc *sc)
sqh->qh.qh_qtd.qtd_next = htole32(EHCI_LINK_TERMINATE);
sqh->qh.qh_qtd.qtd_altnext = htole32(EHCI_LINK_TERMINATE);
sqh->qh.qh_qtd.qtd_status = htole32(EHCI_QTD_HALTED);
-   sqh->sqtd = NULL;
usb_syncmem(>dma, sqh->offs, sizeof(sqh->qh),
BUS_DMASYNC_PREWRITE | BUS_DMASYNC_PREREAD);
 
@@ -729,6 +726,7 @@ ehci_check_qh_intr(struct ehci_softc *sc
return;
}
  done:
+   ehci_rem_qh(sc, xfer->pipe);
TAILQ_REMOVE(>sc_intrhead, ex, inext);
timeout_del(>timeout_handle);
usb_rem_task(xfer->pipe->device, >abort_task);
@@ -861,7 +859,7 @@ ehci_idone(struct usbd_xfer *xfer)
 {
struct ehci_xfer *ex = (struct ehci_xfer *)xfer;
struct ehci_soft_qtd *sqtd;
-   u_int32_t status = 0, nstatus = 0;
+   uint32_t status = 0, nstatus = 0;
int actlen, cerr;
 
 #ifdef DIAGNOSTIC
@@ -1171,13 +1169,7 @@ ehci_freex(struct usbd_bus *bus, struct 
 void
 ehci_device_clear_toggle(struct usbd_pipe *pipe)
 {
-   struct ehci_pipe *epipe = (struct ehci_pipe *)pipe;
-
-#ifdef DIAGNOSTIC
-   if ((epipe->sqh->qh.qh_qtd.qtd_status & htole32(EHCI_QTD_ACTIVE)) != 0)
-   panic("ehci_device_clear_toggle: queue active");
-#endif
-   epipe->sqh->qh.qh_qtd.qtd_status &= htole32(~EHCI_QTD_TOGGLE_MASK);
+   pipe->endpoint->savedtoggle = 0;
 }
 
 #ifdef EHCI_DEBUG
@@ -1374,29 +1366,17 @@ ehci_open(struct usbd_pipe *pipe)
struct usbd_device *dev = pipe->device;
struct ehci_softc *sc = (struct ehci_softc *)dev->bus;
usb_endpoint_descriptor_t *ed = pipe->endpoint->edesc;
-   u_int8_t addr = dev->address;
u_int8_t xfertype = ed->bmAttributes & UE_XFERTYPE;
struct ehci_pipe *epipe = (struct ehci_pipe *)pipe;
struct ehci_soft_qh *sqh;
usbd_status err;
-   int s;
-   int ival, speed, naks;
-   int hshubaddr, hshubport;
 
-   DPRINTFN(1, ("ehci_open: pipe=%p, addr=%d, endpt=%d\n",
+   DPRINTFN(1, ("%s: pipe=%p, addr=%d, endpt=%d\n", __func__,
pipe, addr, ed->bEndpointAddress));
 
if (sc->sc_bus.dying)
return (USBD_IOERROR);
 
-   if (dev->myhsport) {
-   hshubaddr = dev->myhsport->parent->address;
-   hshubport = dev->myhsport->portno;
-   } else {
-   hshubaddr = 0;
-   hshubport = 0;
-   }
-
/* Root Hub */
if (pipe->device->depth == 0) {
switch (ed->bEndpointAddress) {
@@ -1412,55 +1392,11 @@ ehci_open(struct usbd_pipe *pipe)
return (USBD_NORMAL_COMPLETION);
  

Re: kernel panic - panic: ehci_device_clear_toggle: queue active

[Björn Ketelaars]

On Thu 03/12/2015 09:54, Martin Pieuchot wrote:
> On 30/11/15(Mon) 18:28, Björn Ketelaars wrote:
> > Hello,
> > 
> > I repeatedly hit the kernel panic below. Easy to reproduce as it happens 
> > over
> > and over again within 60 minutes after rebooting. Root cause is not known.
> > 
> > I'm running snapshot on an USB stick. I tried different USB ports with the 
> > same
> > result. Next step will be an attempt with a different USB stick.
> > 
> > I think this issue has been mentioned before:
> > 
> > https://marc.info/?t=14184059141=1=3
> > http://openbsd-archive.7691.n7.nabble.com/panic-ehci-device-clear-toggle-queue-active-td231729.html
> > http://article.gmane.org/gmane.os.openbsd.bugs/19812/
> > 
> > Any ideas on how to tackle this issue?
> 
> You can try the diff below and tell me if it helps.
> 
> Index: ehci.c
> ===
> RCS file: /cvs/src/sys/dev/usb/ehci.c,v
> retrieving revision 1.187
> diff -u -p -r1.187 ehci.c
> --- ehci.c26 Jun 2015 11:17:34 -  1.187
> +++ ehci.c14 Oct 2015 14:24:19 -
>

Yes, it helps!

I build and installed a new kernel using your diff and tested it with a couple
of USB-sticks on different USB-ports. No panics...
Reverting to an old (unpatched) kernel, using the above routine, soon resulted
in a hang.

I'm currently running a kernel with your diff. As stated: it helps.

Thanks!

Re: kernel panic - panic: ehci_device_clear_toggle: queue active

[Donald Allen]

The crash I reported a few days ago is the same:
ehci_device_clear_toggle: queue active

Re: kernel panic

[Dariusz Swiderski]

> On 9 paź 2015, at 13:54, Mike Larkin  wrote:
>
> On Fri, Oct 09, 2015 at 04:35:48AM -0700, Mike Larkin wrote:
>> On Fri, Oct 09, 2015 at 09:53:16AM +0200, Holger Glaess wrote:
 On Fri, Oct 09, 2015 at 06:22:53AM +0200, Holger Glaess wrote:
> hi
>
> what kind of information you need more ?
>

 uhm. this machine is very very strange. It has devices I've never
 seen before and many other devices not even recognized. Without access
 to the hardware there's not much we can do here.

 You've posted about this machine in the past, and we've done our best
 to help you but I think this may be a losing battle.

>>>
>>> hi
>>> you mean physikal access or is connection by ssh also ok ?
>>>
>>> ssh access  i can give you.
>>>
>>
>> I meant getting one of these boards in hand.
>>
>
> PS that wasn't me volunteering. It was just a statement that debugging
strange
> hardware usually goes faster with physical access.
>

Hi,

I know that i’m late to the party, but could you describe what you did? Or
does this just trigger
with -current?

greets
--
Maciej 'sfires' Swiderski
---
SysAdm | SecOff  | DS14145-RIPE| DS11-6BONE
193.178.161.0/24 | 3ffe:8010:7:2a::/64 | AS16288
---
A mouse is a device used to point at the xterm you want to type in.

>>>
>>> Holger
>>>
>>>
> holger
>
>
> Stopped at  0:ehci0: unrecoverable error, controller halted
> panic: kernel diagnostic assertion "ci->ci_fpcurproc == p" failed: file
> "../../../../arch/i386/isa/npx.c", line 881
>  Stopped at  Debugger+0x7:   leave
>   TIDPIDUID PRFLAGS PFLAGS  CPU  COMMAND
> Debugger(d09fe02c,f51cfdd4,d09d8f30,f51cfdd4,d709bfc8) at Debugger+0x7
> panic(d09d8f30,d0957746,d0b0522f,d0b0532c,371) at panic+0x71
> __assert(d0957746,d0b0532c,371,d0b0522f,d0bbb160) at __assert+0x2e
> npxsave_proc(d7216744,0,f51cfe58,d03b9029,40) at npxsave_proc+0x5a
> cpu_exit(d7216744,d7215000,d709b00c,0,1) at cpu_exit+0x2a
> exit1(d7216744,4,1,d03b3844,40,4,1,0) at exit1+0x22c
> sigexit(d7216744,4,0,0,21fc000) at sigexit+0x76
> postsig(4,0,808f05d0,63,21de800) at postsig+0x28a
> userret(d7216744) at userret+0x49
> alltraps(,,,,) at alltraps+0x2e
> uvm_fault(0xd0bbb0a0, 0xd000, 0, 1) -> e
> kernel: page fault trap, code=0
> Stopped at  trap+0x18:  movl0x2c(%esi),%edi
>   TIDPIDUID PRFLAGS PFLAGS  CPU  COMMAND
> trap() at trap+0x18
> --- trap (number 32) ---
> 0:
> http://www.openbsd.org/ddb.html describes the minimum info required in
> bug
> reports.  Insufficient info makes it difficult to find and fix bugs.
> ddb>
>
>
> OpenBSD 5.8-current (GENERIC) #1219: Thu Oct  8 07:55:22 MDT 2015
>dera...@i386.openbsd.org:/usr/src/sys/arch/i386/compile/GENERIC
> cpu0: Genuine Intel(R) processor 1.20GHz ("GenuineIntel" 686-class)
1.21
> GHz
> cpu0:
>
FPU,V86,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,CFLUSH,DS,A
CPI,MMX,FXSR,SSE,SSE2,SS,TM,PBE,PERF
> real mem  = 1072041984 (1022MB)
> avail mem = 1038999552 (990MB)
> mpath0 at root
> scsibus0 at mpath0: 256 targets
> mainbus0 at root
> bios0 at mainbus0: date 07/06/09, BIOS32 rev. 0 @ 0xfa530, SMBIOS rev.
> 2.2 @
> 0xf0800 (39 entries)
> bios0: vendor Phoenix Technologies, LTD version "ANSA 3020 R01
> Jul,2,2009" date 07/06/2009
> acpi0 at bios0: rev 0
> acpi0: sleep states S0 S3 S4 S5
> acpi0: tables DSDT FACP MCFG APIC
> acpi0: wakeup devices EPA0(S3) EPA1(S3) PEX0(S5) PEX1(S5) PEX2(S5)
> PEX3(S5)
> HUB0(S5) PCI0(S5)
> acpitimer0 at acpi0: 3579545 Hz, 24 bits
> acpimcfg0 at acpi0 addr 0xe000, bus 0-255
> 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 133MHz
> ioapic0 at mainbus0: apid 2 pa 0xfec0, version 20, 40 pins
> acpiprt0 at acpi0: bus 0 (PCI0)
> acpiprt1 at acpi0: bus 2 (EPA1)
> acpiprt2 at acpi0: bus -1 (BR10)
> acpiprt3 at acpi0: bus -1 (BR11)
> acpiprt4 at acpi0: bus -1 (BR12)
> acpiprt5 at acpi0: bus -1 (BR13)
> acpiprt6 at acpi0: bus -1 (BR14)
> acpiprt7 at acpi0: bus 3 (P0P1)
> acpiprt8 at acpi0: bus -1 (PEX0)
> acpiprt9 at acpi0: bus -1 (PEX1)
> acpiprt10 at acpi0: bus -1 (PEX2)
> acpiprt11 at acpi0: bus -1 (PEX3)
> acpiprt12 at acpi0: bus -1 (HUB0)
> acpicpu0 at acpi0: C1(@1 halt!)
> acpitz0 at acpi0: critical temperature is 75 degC
> acpibtn0 at acpi0: PWRB
> bios0: ROM list: 0xc8000/0x4000! 0xcc000/0x2200! 0xef000/0x1000!
> pci0 at mainbus0 bus 0: configuration mode 1 (bios)
> pchb0 

Re: kernel panic

[Holger Glaess]

> On Fri, Oct 09, 2015 at 06:22:53AM +0200, Holger Glaess wrote:
>> hi
>>
>> what kind of information you need more ?
>>
>
> uhm. this machine is very very strange. It has devices I've never
> seen before and many other devices not even recognized. Without access
> to the hardware there's not much we can do here.
>
> You've posted about this machine in the past, and we've done our best
> to help you but I think this may be a losing battle.
>

hi
 you mean physikal access or is connection by ssh also ok ?

ssh access  i can give you.


Holger


>> holger
>>
>>
>> Stopped at  0:ehci0: unrecoverable error, controller halted
>> panic: kernel diagnostic assertion "ci->ci_fpcurproc == p" failed: file
>> "../../../../arch/i386/isa/npx.c", line 881
>>   Stopped at  Debugger+0x7:   leave
>>TIDPIDUID PRFLAGS PFLAGS  CPU  COMMAND
>> Debugger(d09fe02c,f51cfdd4,d09d8f30,f51cfdd4,d709bfc8) at Debugger+0x7
>> panic(d09d8f30,d0957746,d0b0522f,d0b0532c,371) at panic+0x71
>> __assert(d0957746,d0b0532c,371,d0b0522f,d0bbb160) at __assert+0x2e
>> npxsave_proc(d7216744,0,f51cfe58,d03b9029,40) at npxsave_proc+0x5a
>> cpu_exit(d7216744,d7215000,d709b00c,0,1) at cpu_exit+0x2a
>> exit1(d7216744,4,1,d03b3844,40,4,1,0) at exit1+0x22c
>> sigexit(d7216744,4,0,0,21fc000) at sigexit+0x76
>> postsig(4,0,808f05d0,63,21de800) at postsig+0x28a
>> userret(d7216744) at userret+0x49
>> alltraps(,,,,) at alltraps+0x2e
>> uvm_fault(0xd0bbb0a0, 0xd000, 0, 1) -> e
>> kernel: page fault trap, code=0
>> Stopped at  trap+0x18:  movl0x2c(%esi),%edi
>>TIDPIDUID PRFLAGS PFLAGS  CPU  COMMAND
>> trap() at trap+0x18
>> --- trap (number 32) ---
>> 0:
>> http://www.openbsd.org/ddb.html describes the minimum info required in
>> bug
>> reports.  Insufficient info makes it difficult to find and fix bugs.
>> ddb>
>>
>>
>> OpenBSD 5.8-current (GENERIC) #1219: Thu Oct  8 07:55:22 MDT 2015
>> dera...@i386.openbsd.org:/usr/src/sys/arch/i386/compile/GENERIC
>> cpu0: Genuine Intel(R) processor 1.20GHz ("GenuineIntel" 686-class) 1.21
>> GHz
>> cpu0:
>> FPU,V86,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,TM,PBE,PERF
>> real mem  = 1072041984 (1022MB)
>> avail mem = 1038999552 (990MB)
>> mpath0 at root
>> scsibus0 at mpath0: 256 targets
>> mainbus0 at root
>> bios0 at mainbus0: date 07/06/09, BIOS32 rev. 0 @ 0xfa530, SMBIOS rev.
>> 2.2 @
>> 0xf0800 (39 entries)
>> bios0: vendor Phoenix Technologies, LTD version "ANSA 3020 R01
>> Jul,2,2009" date 07/06/2009
>> acpi0 at bios0: rev 0
>> acpi0: sleep states S0 S3 S4 S5
>> acpi0: tables DSDT FACP MCFG APIC
>> acpi0: wakeup devices EPA0(S3) EPA1(S3) PEX0(S5) PEX1(S5) PEX2(S5)
>> PEX3(S5)
>> HUB0(S5) PCI0(S5)
>> acpitimer0 at acpi0: 3579545 Hz, 24 bits
>> acpimcfg0 at acpi0 addr 0xe000, bus 0-255
>> 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 133MHz
>> ioapic0 at mainbus0: apid 2 pa 0xfec0, version 20, 40 pins
>> acpiprt0 at acpi0: bus 0 (PCI0)
>> acpiprt1 at acpi0: bus 2 (EPA1)
>> acpiprt2 at acpi0: bus -1 (BR10)
>> acpiprt3 at acpi0: bus -1 (BR11)
>> acpiprt4 at acpi0: bus -1 (BR12)
>> acpiprt5 at acpi0: bus -1 (BR13)
>> acpiprt6 at acpi0: bus -1 (BR14)
>> acpiprt7 at acpi0: bus 3 (P0P1)
>> acpiprt8 at acpi0: bus -1 (PEX0)
>> acpiprt9 at acpi0: bus -1 (PEX1)
>> acpiprt10 at acpi0: bus -1 (PEX2)
>> acpiprt11 at acpi0: bus -1 (PEX3)
>> acpiprt12 at acpi0: bus -1 (HUB0)
>> acpicpu0 at acpi0: C1(@1 halt!)
>> acpitz0 at acpi0: critical temperature is 75 degC
>> acpibtn0 at acpi0: PWRB
>> bios0: ROM list: 0xc8000/0x4000! 0xcc000/0x2200! 0xef000/0x1000!
>> pci0 at mainbus0 bus 0: configuration mode 1 (bios)
>> pchb0 at pci0 dev 0 function 0 "Intel EP80579 Host" rev 0x01
>> "Intel EP80579 Memory" rev 0x01 at pci0 dev 0 function 1 not configured
>> "Intel EP80579 EDMA" rev 0x01 at pci0 dev 1 function 0 not configured
>> ppb0 at pci0 dev 2 function 0 "Intel EP80579 PCIE" rev 0x01: apic 2 int
>> 16
>> pci1 at ppb0 bus 1
>> em0 at pci1 dev 0 function 0 "Intel 82574L" rev 0x00: msi, address
>> 00:14:b7:00:61:63
>> ppb1 at pci0 dev 3 function 0 "Intel EP80579 PCIE" rev 0x01: apic 2 int
>> 16
>> pci2 at ppb1 bus 2
>> ppb2 at pci0 dev 4 function 0 "Intel EP80579" rev 0x01
>> pci3 at ppb2 bus 3
>> em1 at pci3 dev 0 function 0 "Intel EP80579 LAN" rev 0x01: apic 2 int
>> 16,
>> address 00:14:b7:00:61:65
>> em2 at pci3 dev 1 function 0 "Intel EP80579 LAN" rev 0x01: apic 2 int
>> 17,
>> address 00:14:b7:00:61:66
>> em3 at pci3 dev 2 function 0 "Intel EP80579 LAN" rev 0x01: apic 2 int
>> 18,
>> address ff:ff:ff:ff:ff:ff
>> gcu0 at pci3 dev 3 function 0 "Intel EP80579 GCU" rev 0x01
>> "Intel EP80579 CANbus" rev 0x01 at pci3 dev 4 function 0 not configured
>> "Intel EP80579 CANbus" rev 0x01 at pci3 dev 5 function 0 not configured
>> "Intel 

Re: kernel panic

[Mike Larkin]

On Fri, Oct 09, 2015 at 04:35:48AM -0700, Mike Larkin wrote:
> On Fri, Oct 09, 2015 at 09:53:16AM +0200, Holger Glaess wrote:
> > > On Fri, Oct 09, 2015 at 06:22:53AM +0200, Holger Glaess wrote:
> > >> hi
> > >>
> > >> what kind of information you need more ?
> > >>
> > >
> > > uhm. this machine is very very strange. It has devices I've never
> > > seen before and many other devices not even recognized. Without access
> > > to the hardware there's not much we can do here.
> > >
> > > You've posted about this machine in the past, and we've done our best
> > > to help you but I think this may be a losing battle.
> > >
> > 
> > hi
> >  you mean physikal access or is connection by ssh also ok ?
> > 
> > ssh access  i can give you.
> > 
> 
> I meant getting one of these boards in hand.
> 

PS that wasn't me volunteering. It was just a statement that debugging strange
hardware usually goes faster with physical access.

> > 
> > Holger
> > 
> > 
> > >> holger
> > >>
> > >>
> > >> Stopped at  0:ehci0: unrecoverable error, controller halted
> > >> panic: kernel diagnostic assertion "ci->ci_fpcurproc == p" failed: file
> > >> "../../../../arch/i386/isa/npx.c", line 881
> > >>   Stopped at  Debugger+0x7:   leave
> > >>TIDPIDUID PRFLAGS PFLAGS  CPU  COMMAND
> > >> Debugger(d09fe02c,f51cfdd4,d09d8f30,f51cfdd4,d709bfc8) at Debugger+0x7
> > >> panic(d09d8f30,d0957746,d0b0522f,d0b0532c,371) at panic+0x71
> > >> __assert(d0957746,d0b0532c,371,d0b0522f,d0bbb160) at __assert+0x2e
> > >> npxsave_proc(d7216744,0,f51cfe58,d03b9029,40) at npxsave_proc+0x5a
> > >> cpu_exit(d7216744,d7215000,d709b00c,0,1) at cpu_exit+0x2a
> > >> exit1(d7216744,4,1,d03b3844,40,4,1,0) at exit1+0x22c
> > >> sigexit(d7216744,4,0,0,21fc000) at sigexit+0x76
> > >> postsig(4,0,808f05d0,63,21de800) at postsig+0x28a
> > >> userret(d7216744) at userret+0x49
> > >> alltraps(,,,,) at alltraps+0x2e
> > >> uvm_fault(0xd0bbb0a0, 0xd000, 0, 1) -> e
> > >> kernel: page fault trap, code=0
> > >> Stopped at  trap+0x18:  movl0x2c(%esi),%edi
> > >>TIDPIDUID PRFLAGS PFLAGS  CPU  COMMAND
> > >> trap() at trap+0x18
> > >> --- trap (number 32) ---
> > >> 0:
> > >> http://www.openbsd.org/ddb.html describes the minimum info required in
> > >> bug
> > >> reports.  Insufficient info makes it difficult to find and fix bugs.
> > >> ddb>
> > >>
> > >>
> > >> OpenBSD 5.8-current (GENERIC) #1219: Thu Oct  8 07:55:22 MDT 2015
> > >> dera...@i386.openbsd.org:/usr/src/sys/arch/i386/compile/GENERIC
> > >> cpu0: Genuine Intel(R) processor 1.20GHz ("GenuineIntel" 686-class) 1.21
> > >> GHz
> > >> cpu0:
> > >> FPU,V86,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,TM,PBE,PERF
> > >> real mem  = 1072041984 (1022MB)
> > >> avail mem = 1038999552 (990MB)
> > >> mpath0 at root
> > >> scsibus0 at mpath0: 256 targets
> > >> mainbus0 at root
> > >> bios0 at mainbus0: date 07/06/09, BIOS32 rev. 0 @ 0xfa530, SMBIOS rev.
> > >> 2.2 @
> > >> 0xf0800 (39 entries)
> > >> bios0: vendor Phoenix Technologies, LTD version "ANSA 3020 R01
> > >> Jul,2,2009" date 07/06/2009
> > >> acpi0 at bios0: rev 0
> > >> acpi0: sleep states S0 S3 S4 S5
> > >> acpi0: tables DSDT FACP MCFG APIC
> > >> acpi0: wakeup devices EPA0(S3) EPA1(S3) PEX0(S5) PEX1(S5) PEX2(S5)
> > >> PEX3(S5)
> > >> HUB0(S5) PCI0(S5)
> > >> acpitimer0 at acpi0: 3579545 Hz, 24 bits
> > >> acpimcfg0 at acpi0 addr 0xe000, bus 0-255
> > >> 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 133MHz
> > >> ioapic0 at mainbus0: apid 2 pa 0xfec0, version 20, 40 pins
> > >> acpiprt0 at acpi0: bus 0 (PCI0)
> > >> acpiprt1 at acpi0: bus 2 (EPA1)
> > >> acpiprt2 at acpi0: bus -1 (BR10)
> > >> acpiprt3 at acpi0: bus -1 (BR11)
> > >> acpiprt4 at acpi0: bus -1 (BR12)
> > >> acpiprt5 at acpi0: bus -1 (BR13)
> > >> acpiprt6 at acpi0: bus -1 (BR14)
> > >> acpiprt7 at acpi0: bus 3 (P0P1)
> > >> acpiprt8 at acpi0: bus -1 (PEX0)
> > >> acpiprt9 at acpi0: bus -1 (PEX1)
> > >> acpiprt10 at acpi0: bus -1 (PEX2)
> > >> acpiprt11 at acpi0: bus -1 (PEX3)
> > >> acpiprt12 at acpi0: bus -1 (HUB0)
> > >> acpicpu0 at acpi0: C1(@1 halt!)
> > >> acpitz0 at acpi0: critical temperature is 75 degC
> > >> acpibtn0 at acpi0: PWRB
> > >> bios0: ROM list: 0xc8000/0x4000! 0xcc000/0x2200! 0xef000/0x1000!
> > >> pci0 at mainbus0 bus 0: configuration mode 1 (bios)
> > >> pchb0 at pci0 dev 0 function 0 "Intel EP80579 Host" rev 0x01
> > >> "Intel EP80579 Memory" rev 0x01 at pci0 dev 0 function 1 not configured
> > >> "Intel EP80579 EDMA" rev 0x01 at pci0 dev 1 function 0 not configured
> > >> ppb0 at pci0 dev 2 function 0 "Intel EP80579 PCIE" rev 0x01: apic 2 int
> > >> 16
> > >> pci1 at ppb0 bus 1
> > >> em0 at pci1 dev 0 function 0 "Intel 82574L" rev 0x00: msi, address
> > >> 

Re: kernel panic

[Mike Larkin]

On Fri, Oct 09, 2015 at 09:53:16AM +0200, Holger Glaess wrote:
> > On Fri, Oct 09, 2015 at 06:22:53AM +0200, Holger Glaess wrote:
> >> hi
> >>
> >> what kind of information you need more ?
> >>
> >
> > uhm. this machine is very very strange. It has devices I've never
> > seen before and many other devices not even recognized. Without access
> > to the hardware there's not much we can do here.
> >
> > You've posted about this machine in the past, and we've done our best
> > to help you but I think this may be a losing battle.
> >
> 
> hi
>  you mean physikal access or is connection by ssh also ok ?
> 
> ssh access  i can give you.
> 

I meant getting one of these boards in hand.

> 
> Holger
> 
> 
> >> holger
> >>
> >>
> >> Stopped at  0:ehci0: unrecoverable error, controller halted
> >> panic: kernel diagnostic assertion "ci->ci_fpcurproc == p" failed: file
> >> "../../../../arch/i386/isa/npx.c", line 881
> >>   Stopped at  Debugger+0x7:   leave
> >>TIDPIDUID PRFLAGS PFLAGS  CPU  COMMAND
> >> Debugger(d09fe02c,f51cfdd4,d09d8f30,f51cfdd4,d709bfc8) at Debugger+0x7
> >> panic(d09d8f30,d0957746,d0b0522f,d0b0532c,371) at panic+0x71
> >> __assert(d0957746,d0b0532c,371,d0b0522f,d0bbb160) at __assert+0x2e
> >> npxsave_proc(d7216744,0,f51cfe58,d03b9029,40) at npxsave_proc+0x5a
> >> cpu_exit(d7216744,d7215000,d709b00c,0,1) at cpu_exit+0x2a
> >> exit1(d7216744,4,1,d03b3844,40,4,1,0) at exit1+0x22c
> >> sigexit(d7216744,4,0,0,21fc000) at sigexit+0x76
> >> postsig(4,0,808f05d0,63,21de800) at postsig+0x28a
> >> userret(d7216744) at userret+0x49
> >> alltraps(,,,,) at alltraps+0x2e
> >> uvm_fault(0xd0bbb0a0, 0xd000, 0, 1) -> e
> >> kernel: page fault trap, code=0
> >> Stopped at  trap+0x18:  movl0x2c(%esi),%edi
> >>TIDPIDUID PRFLAGS PFLAGS  CPU  COMMAND
> >> trap() at trap+0x18
> >> --- trap (number 32) ---
> >> 0:
> >> http://www.openbsd.org/ddb.html describes the minimum info required in
> >> bug
> >> reports.  Insufficient info makes it difficult to find and fix bugs.
> >> ddb>
> >>
> >>
> >> OpenBSD 5.8-current (GENERIC) #1219: Thu Oct  8 07:55:22 MDT 2015
> >> dera...@i386.openbsd.org:/usr/src/sys/arch/i386/compile/GENERIC
> >> cpu0: Genuine Intel(R) processor 1.20GHz ("GenuineIntel" 686-class) 1.21
> >> GHz
> >> cpu0:
> >> FPU,V86,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,TM,PBE,PERF
> >> real mem  = 1072041984 (1022MB)
> >> avail mem = 1038999552 (990MB)
> >> mpath0 at root
> >> scsibus0 at mpath0: 256 targets
> >> mainbus0 at root
> >> bios0 at mainbus0: date 07/06/09, BIOS32 rev. 0 @ 0xfa530, SMBIOS rev.
> >> 2.2 @
> >> 0xf0800 (39 entries)
> >> bios0: vendor Phoenix Technologies, LTD version "ANSA 3020 R01
> >> Jul,2,2009" date 07/06/2009
> >> acpi0 at bios0: rev 0
> >> acpi0: sleep states S0 S3 S4 S5
> >> acpi0: tables DSDT FACP MCFG APIC
> >> acpi0: wakeup devices EPA0(S3) EPA1(S3) PEX0(S5) PEX1(S5) PEX2(S5)
> >> PEX3(S5)
> >> HUB0(S5) PCI0(S5)
> >> acpitimer0 at acpi0: 3579545 Hz, 24 bits
> >> acpimcfg0 at acpi0 addr 0xe000, bus 0-255
> >> 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 133MHz
> >> ioapic0 at mainbus0: apid 2 pa 0xfec0, version 20, 40 pins
> >> acpiprt0 at acpi0: bus 0 (PCI0)
> >> acpiprt1 at acpi0: bus 2 (EPA1)
> >> acpiprt2 at acpi0: bus -1 (BR10)
> >> acpiprt3 at acpi0: bus -1 (BR11)
> >> acpiprt4 at acpi0: bus -1 (BR12)
> >> acpiprt5 at acpi0: bus -1 (BR13)
> >> acpiprt6 at acpi0: bus -1 (BR14)
> >> acpiprt7 at acpi0: bus 3 (P0P1)
> >> acpiprt8 at acpi0: bus -1 (PEX0)
> >> acpiprt9 at acpi0: bus -1 (PEX1)
> >> acpiprt10 at acpi0: bus -1 (PEX2)
> >> acpiprt11 at acpi0: bus -1 (PEX3)
> >> acpiprt12 at acpi0: bus -1 (HUB0)
> >> acpicpu0 at acpi0: C1(@1 halt!)
> >> acpitz0 at acpi0: critical temperature is 75 degC
> >> acpibtn0 at acpi0: PWRB
> >> bios0: ROM list: 0xc8000/0x4000! 0xcc000/0x2200! 0xef000/0x1000!
> >> pci0 at mainbus0 bus 0: configuration mode 1 (bios)
> >> pchb0 at pci0 dev 0 function 0 "Intel EP80579 Host" rev 0x01
> >> "Intel EP80579 Memory" rev 0x01 at pci0 dev 0 function 1 not configured
> >> "Intel EP80579 EDMA" rev 0x01 at pci0 dev 1 function 0 not configured
> >> ppb0 at pci0 dev 2 function 0 "Intel EP80579 PCIE" rev 0x01: apic 2 int
> >> 16
> >> pci1 at ppb0 bus 1
> >> em0 at pci1 dev 0 function 0 "Intel 82574L" rev 0x00: msi, address
> >> 00:14:b7:00:61:63
> >> ppb1 at pci0 dev 3 function 0 "Intel EP80579 PCIE" rev 0x01: apic 2 int
> >> 16
> >> pci2 at ppb1 bus 2
> >> ppb2 at pci0 dev 4 function 0 "Intel EP80579" rev 0x01
> >> pci3 at ppb2 bus 3
> >> em1 at pci3 dev 0 function 0 "Intel EP80579 LAN" rev 0x01: apic 2 int
> >> 16,
> >> address 00:14:b7:00:61:65
> >> em2 at pci3 dev 1 function 0 "Intel EP80579 LAN" rev 0x01: apic 2 int
> >> 17,
> >> address 

Re: kernel panic

[Mike Larkin]

On Fri, Oct 09, 2015 at 06:22:53AM +0200, Holger Glaess wrote:
> hi
> 
> what kind of information you need more ?
> 

uhm. this machine is very very strange. It has devices I've never
seen before and many other devices not even recognized. Without access
to the hardware there's not much we can do here.

You've posted about this machine in the past, and we've done our best
to help you but I think this may be a losing battle.

> holger
> 
> 
> Stopped at  0:ehci0: unrecoverable error, controller halted
> panic: kernel diagnostic assertion "ci->ci_fpcurproc == p" failed: file
> "../../../../arch/i386/isa/npx.c", line 881
>   Stopped at  Debugger+0x7:   leave
>TIDPIDUID PRFLAGS PFLAGS  CPU  COMMAND
> Debugger(d09fe02c,f51cfdd4,d09d8f30,f51cfdd4,d709bfc8) at Debugger+0x7
> panic(d09d8f30,d0957746,d0b0522f,d0b0532c,371) at panic+0x71
> __assert(d0957746,d0b0532c,371,d0b0522f,d0bbb160) at __assert+0x2e
> npxsave_proc(d7216744,0,f51cfe58,d03b9029,40) at npxsave_proc+0x5a
> cpu_exit(d7216744,d7215000,d709b00c,0,1) at cpu_exit+0x2a
> exit1(d7216744,4,1,d03b3844,40,4,1,0) at exit1+0x22c
> sigexit(d7216744,4,0,0,21fc000) at sigexit+0x76
> postsig(4,0,808f05d0,63,21de800) at postsig+0x28a
> userret(d7216744) at userret+0x49
> alltraps(,,,,) at alltraps+0x2e
> uvm_fault(0xd0bbb0a0, 0xd000, 0, 1) -> e
> kernel: page fault trap, code=0
> Stopped at  trap+0x18:  movl0x2c(%esi),%edi
>TIDPIDUID PRFLAGS PFLAGS  CPU  COMMAND
> trap() at trap+0x18
> --- trap (number 32) ---
> 0:
> http://www.openbsd.org/ddb.html describes the minimum info required in bug
> reports.  Insufficient info makes it difficult to find and fix bugs.
> ddb>
> 
> 
> OpenBSD 5.8-current (GENERIC) #1219: Thu Oct  8 07:55:22 MDT 2015
> dera...@i386.openbsd.org:/usr/src/sys/arch/i386/compile/GENERIC
> cpu0: Genuine Intel(R) processor 1.20GHz ("GenuineIntel" 686-class) 1.21 GHz
> cpu0: 
> FPU,V86,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,TM,PBE,PERF
> real mem  = 1072041984 (1022MB)
> avail mem = 1038999552 (990MB)
> mpath0 at root
> scsibus0 at mpath0: 256 targets
> mainbus0 at root
> bios0 at mainbus0: date 07/06/09, BIOS32 rev. 0 @ 0xfa530, SMBIOS rev. 2.2 @
> 0xf0800 (39 entries)
> bios0: vendor Phoenix Technologies, LTD version "ANSA 3020 R01
> Jul,2,2009" date 07/06/2009
> acpi0 at bios0: rev 0
> acpi0: sleep states S0 S3 S4 S5
> acpi0: tables DSDT FACP MCFG APIC
> acpi0: wakeup devices EPA0(S3) EPA1(S3) PEX0(S5) PEX1(S5) PEX2(S5) PEX3(S5)
> HUB0(S5) PCI0(S5)
> acpitimer0 at acpi0: 3579545 Hz, 24 bits
> acpimcfg0 at acpi0 addr 0xe000, bus 0-255
> 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 133MHz
> ioapic0 at mainbus0: apid 2 pa 0xfec0, version 20, 40 pins
> acpiprt0 at acpi0: bus 0 (PCI0)
> acpiprt1 at acpi0: bus 2 (EPA1)
> acpiprt2 at acpi0: bus -1 (BR10)
> acpiprt3 at acpi0: bus -1 (BR11)
> acpiprt4 at acpi0: bus -1 (BR12)
> acpiprt5 at acpi0: bus -1 (BR13)
> acpiprt6 at acpi0: bus -1 (BR14)
> acpiprt7 at acpi0: bus 3 (P0P1)
> acpiprt8 at acpi0: bus -1 (PEX0)
> acpiprt9 at acpi0: bus -1 (PEX1)
> acpiprt10 at acpi0: bus -1 (PEX2)
> acpiprt11 at acpi0: bus -1 (PEX3)
> acpiprt12 at acpi0: bus -1 (HUB0)
> acpicpu0 at acpi0: C1(@1 halt!)
> acpitz0 at acpi0: critical temperature is 75 degC
> acpibtn0 at acpi0: PWRB
> bios0: ROM list: 0xc8000/0x4000! 0xcc000/0x2200! 0xef000/0x1000!
> pci0 at mainbus0 bus 0: configuration mode 1 (bios)
> pchb0 at pci0 dev 0 function 0 "Intel EP80579 Host" rev 0x01
> "Intel EP80579 Memory" rev 0x01 at pci0 dev 0 function 1 not configured
> "Intel EP80579 EDMA" rev 0x01 at pci0 dev 1 function 0 not configured
> ppb0 at pci0 dev 2 function 0 "Intel EP80579 PCIE" rev 0x01: apic 2 int 16
> pci1 at ppb0 bus 1
> em0 at pci1 dev 0 function 0 "Intel 82574L" rev 0x00: msi, address
> 00:14:b7:00:61:63
> ppb1 at pci0 dev 3 function 0 "Intel EP80579 PCIE" rev 0x01: apic 2 int 16
> pci2 at ppb1 bus 2
> ppb2 at pci0 dev 4 function 0 "Intel EP80579" rev 0x01
> pci3 at ppb2 bus 3
> em1 at pci3 dev 0 function 0 "Intel EP80579 LAN" rev 0x01: apic 2 int 16,
> address 00:14:b7:00:61:65
> em2 at pci3 dev 1 function 0 "Intel EP80579 LAN" rev 0x01: apic 2 int 17,
> address 00:14:b7:00:61:66
> em3 at pci3 dev 2 function 0 "Intel EP80579 LAN" rev 0x01: apic 2 int 18,
> address ff:ff:ff:ff:ff:ff
> gcu0 at pci3 dev 3 function 0 "Intel EP80579 GCU" rev 0x01
> "Intel EP80579 CANbus" rev 0x01 at pci3 dev 4 function 0 not configured
> "Intel EP80579 CANbus" rev 0x01 at pci3 dev 5 function 0 not configured
> "Intel EP80579 Serial" rev 0x01 at pci3 dev 6 function 0 not configured
> "Intel EP80579 1588" rev 0x01 at pci3 dev 7 function 0 not configured
> "Intel EP80579 LEB" rev 0x01 at pci3 dev 8 function 0 not configured
> vendor "Intel", unknown product 

Re: kernel panic in OpenBSD 5.6 release

[Josh Grosse]

On 2015-03-03 11:37, someone wrote:


1) If I run transmission-gtk with ex.: 20 torrent files and I'm on a
50 mbit/sec network, after ~10-15 minutes (network fully used,
ethernet, not wifi) my OpenBSD 5.6 64bit on a T61 will always crash
and brings up the gdb. Is that normal?


Do you mean *ddb*, rather than gdb?  If so, its normal when the
kernel panics, yes.


How can I help debug it? ...


Post the panic message, your dmesg(8), and the output from trace and
ps commands in the ddb(4) kernel debugger.

See crash(8) and ddb(4), and for the kind of information needed when
problem reporting, see http://www.openbsd.org/report.html

It's not clear if you are running 5.6-release or if you are running
with any of the errata patches, or 5.6-stable.  If you are running
-release, please note there are 15 errata patches, two of which are
for kernel panics.

Re: kernel panic in OpenBSD 5.6 release

[someone]

Only running -release without patches. Ok, then I will try out newer
versions before reporting anything, thanks!

On Tue, Mar 3, 2015 at 5:56 PM, Josh Grosse j...@jggimi.homeip.net wrote:

 On 2015-03-03 11:37, someone wrote:

  1) If I run transmission-gtk with ex.: 20 torrent files and I'm on a
 50 mbit/sec network, after ~10-15 minutes (network fully used,
 ethernet, not wifi) my OpenBSD 5.6 64bit on a T61 will always crash
 and brings up the gdb. Is that normal?


 Do you mean *ddb*, rather than gdb?  If so, its normal when the
 kernel panics, yes.

  How can I help debug it? ...


 Post the panic message, your dmesg(8), and the output from trace and
 ps commands in the ddb(4) kernel debugger.

 See crash(8) and ddb(4), and for the kind of information needed when
 problem reporting, see http://www.openbsd.org/report.html

 It's not clear if you are running 5.6-release or if you are running
 with any of the errata patches, or 5.6-stable.  If you are running
 -release, please note there are 15 errata patches, two of which are
 for kernel panics.

Re: kernel panic athn0

[Alexey Kurinnij]

Sorry, in first message ddb only for one processor. This is fresh for both:

# ifconfig athn0 up
panic: kernel diagnostic assertion pin  sc-ngpiopins failed: file
../../../../dev/ic/ar9003.c, line 512
Stopped at  Debugger+0x9:   leave
RUN AT LEAST 'trace' AND 'ps' AND INCLUDE OUTPUT WHEN REPORTING THIS PANIC!
IF RUNNING SMP, USE 'mach ddbcpu #' AND 'trace' ON OTHER PROCESSORS, TOO.
DO NOT EVEN BOTHER REPORTING THIS WITHOUT INCLUDING THAT INFORMATION!
ddb{1} trace
Debugger() at Debugger+0x9
panic() at panic+0xfe
__assert() at __assert+0x25
ar9003_gpio_write() at ar9003_gpio_write+0x9d
athn_init() at athn_init+0xfb
athn_ioctl() at athn_ioctl+0x1e6
ifioctl() at ifioctl+0xb18
sys_ioctl() at sys_ioctl+0x169
syscall() at syscall+0x297
--- syscall (number 54) ---
end of kernel
end trace frame: 0x7f7bcca0, count: -9
acpi_pdirpa+0x3fc50a:
ddb{1} mach ddbcpu 0
Stopped at  Debugger+0x9:   leave
RUN AT LEAST 'trace' AND 'ps' AND INCLUDE OUTPUT WHEN REPORTING THIS PANIC!
IF RUNNING SMP, USE 'mach ddbcpu #' AND 'trace' ON OTHER PROCESSORS, TOO.
DO NOT EVEN BOTHER REPORTING THIS WITHOUT INCLUDING THAT INFORMATION!
ddb{0} trace
Debugger() at Debugger+0x9
x86_ipi_handler() at x86_ipi_handler+0x64
Xresume_lapic_ipi() at Xresume_lapic_ipi+0x1b
--- interrupt ---
Bad frame pointer: 0x80001ce45c08
end trace frame: 0x80001ce45c08, count: -3
__mp_lock+0x42:
ddb{0} ps
   PID   PPID   PGRPUID  S   FLAGS  WAIT  COMMAND
 19450  13014  19450  0  7 0x3ifconfig
 13014  1  13014  0  30x8b  pause ksh
 25598  1  25598  0  30x83  ttyin getty
 18456  1  18456  0  30x83  ttyin getty
 11661  1  11661  0  30x83  ttyin getty
   916  1916  0  30x83  ttyin getty
  6800  1   6800  0  30x83  ttyin getty
 26728  1  26728  0  30x80  selectcron
  3038  1   3038  0  30x80  nanosleep sensorsd
 19379  1  19379  0  30x80  kqreadapmd
 12318  1  12318 99  30x90  poll  sndiod
 10631  30214  30214 95  30x90  kqreadsmtpd
  9723  30214  30214 95  30x90  kqreadsmtpd
 20447  30214  30214 95  30x90  kqreadsmtpd
 32443  30214  30214 95  30x90  kqreadsmtpd
 10158  30214  30214 95  30x90  kqreadsmtpd
 26620  30214  30214103  30x90  kqreadsmtpd
 30214  1  30214  0  30x80  kqreadsmtpd
 25074  1  25074 77  30x90  poll  dhcpd
  5058  1   5058  0  30x80  selectsshd
 13567  28172 22 83  30x90  poll  ntpd
 28172 22 22 83  30x90  poll  ntpd
22  1 22  0  30x80  poll  ntpd
 12313  17356  17356 70  30x90  selectnamed
 17356  1  17356  0  30x90  netio named
 13591  11643  11643 74  30x90  bpf   pflogd
 11643  1  11643  0  30x80  netio pflogd
 22160  30463  30463 73  30x90  poll  syslogd
 30463  1  30463  0  30x80  netio syslogd
*16977  1  16977 77  70x90dhclient
 26597  1  26597  0  30x80  poll  dhclient
 27019  0  0  0  3 0x14200  bored ttm_swap
 27833  0  0  0  3 0x14200  aiodoned  aiodoned
 13860  0  0  0  3 0x14200  syncerupdate
 12987  0  0  0  3 0x14200  cleaner   cleaner
 29718  0  0  0  3 0x14200  reaperreaper
  9873  0  0  0  3 0x14200  pgdaemon  pagedaemon
 30462  0  0  0  3 0x14200  bored crypto
 2  0  0  0  3 0x14200  pftm  pfpurge
 31001  0  0  0  3 0x14200  bored sensors
 14441  0  0  0  3 0x14200  usbtskusbtask
 13312  0  0  0  3 0x14200  usbatsk   usbatsk
 16136  0  0  0  3  0x40014200  acpi0 acpi0
 27548  0  0  0  3  0x40014200idle1
 20115  0  0  0  3 0x14200  bored systqmp
 11558  0  0  0  3 0x14200  bored systq
 14960  0  0  0  3 0x14200  bored syswq
 14541  0  0  0  3  0x40014200idle0
 1  0  1  0  30x82  wait  init
 0 -1  0  0  3 0x10200  scheduler swapper
ddb{0}

Re: kernel panic athn0

[Stefan Sperling]

On Tue, Nov 11, 2014 at 01:44:57PM +0200, Alexey Kurinnij wrote:
 Sorry, in first message ddb only for one processor. This is fresh for both:

athn0 at pci3 dev 0 function 0 Atheros AR9300 rev 0x01: apic 0 int 16

Sorry, this chip isn't supported. See the man page -- it's not listed.

Damien committed untested code for this chip years ago and made the
driver use that code (see r1.1 in CVS log for dev/ic/ar9003.c).
There have been various crashes as a result, some already fixed,
some not fixed.

Since this problem keeps coming up, and ar9003 cards are known to be
broken, and nobody is working on fixing them I believe we should
simply stop the kernel from attaching them for now.

Index: if_athn_pci.c
===
RCS file: /cvs/src/sys/dev/pci/if_athn_pci.c,v
retrieving revision 1.16
diff -u -p -r1.16 if_athn_pci.c
--- if_athn_pci.c   8 Jul 2014 08:55:33 -   1.16
+++ if_athn_pci.c   11 Nov 2014 11:58:33 -
@@ -97,8 +97,7 @@ static const struct pci_matchid athn_pci
{ PCI_VENDOR_ATHEROS, PCI_PRODUCT_ATHEROS_AR9285 },
{ PCI_VENDOR_ATHEROS, PCI_PRODUCT_ATHEROS_AR2427 },
{ PCI_VENDOR_ATHEROS, PCI_PRODUCT_ATHEROS_AR9227 },
-   { PCI_VENDOR_ATHEROS, PCI_PRODUCT_ATHEROS_AR9287 },
-   { PCI_VENDOR_ATHEROS, PCI_PRODUCT_ATHEROS_AR9300 }
+   { PCI_VENDOR_ATHEROS, PCI_PRODUCT_ATHEROS_AR9287 }
 };
 
 int
 
 # ifconfig athn0 up
 panic: kernel diagnostic assertion pin  sc-ngpiopins failed: file
 ../../../../dev/ic/ar9003.c, line 512
 Stopped at  Debugger+0x9:   leave
 RUN AT LEAST 'trace' AND 'ps' AND INCLUDE OUTPUT WHEN REPORTING THIS PANIC!
 IF RUNNING SMP, USE 'mach ddbcpu #' AND 'trace' ON OTHER PROCESSORS, TOO.
 DO NOT EVEN BOTHER REPORTING THIS WITHOUT INCLUDING THAT INFORMATION!
 ddb{1} trace
 Debugger() at Debugger+0x9
 panic() at panic+0xfe
 __assert() at __assert+0x25
 ar9003_gpio_write() at ar9003_gpio_write+0x9d
 athn_init() at athn_init+0xfb
 athn_ioctl() at athn_ioctl+0x1e6
 ifioctl() at ifioctl+0xb18
 sys_ioctl() at sys_ioctl+0x169
 syscall() at syscall+0x297
 --- syscall (number 54) ---
 end of kernel
 end trace frame: 0x7f7bcca0, count: -9
 acpi_pdirpa+0x3fc50a:
 ddb{1} mach ddbcpu 0
 Stopped at  Debugger+0x9:   leave
 RUN AT LEAST 'trace' AND 'ps' AND INCLUDE OUTPUT WHEN REPORTING THIS PANIC!
 IF RUNNING SMP, USE 'mach ddbcpu #' AND 'trace' ON OTHER PROCESSORS, TOO.
 DO NOT EVEN BOTHER REPORTING THIS WITHOUT INCLUDING THAT INFORMATION!
 ddb{0} trace
 Debugger() at Debugger+0x9
 x86_ipi_handler() at x86_ipi_handler+0x64
 Xresume_lapic_ipi() at Xresume_lapic_ipi+0x1b
 --- interrupt ---
 Bad frame pointer: 0x80001ce45c08
 end trace frame: 0x80001ce45c08, count: -3
 __mp_lock+0x42:
 ddb{0} ps
PID   PPID   PGRPUID  S   FLAGS  WAIT  COMMAND
  19450  13014  19450  0  7 0x3ifconfig
  13014  1  13014  0  30x8b  pause ksh
  25598  1  25598  0  30x83  ttyin getty
  18456  1  18456  0  30x83  ttyin getty
  11661  1  11661  0  30x83  ttyin getty
916  1916  0  30x83  ttyin getty
   6800  1   6800  0  30x83  ttyin getty
  26728  1  26728  0  30x80  selectcron
   3038  1   3038  0  30x80  nanosleep sensorsd
  19379  1  19379  0  30x80  kqreadapmd
  12318  1  12318 99  30x90  poll  sndiod
  10631  30214  30214 95  30x90  kqreadsmtpd
   9723  30214  30214 95  30x90  kqreadsmtpd
  20447  30214  30214 95  30x90  kqreadsmtpd
  32443  30214  30214 95  30x90  kqreadsmtpd
  10158  30214  30214 95  30x90  kqreadsmtpd
  26620  30214  30214103  30x90  kqreadsmtpd
  30214  1  30214  0  30x80  kqreadsmtpd
  25074  1  25074 77  30x90  poll  dhcpd
   5058  1   5058  0  30x80  selectsshd
  13567  28172 22 83  30x90  poll  ntpd
  28172 22 22 83  30x90  poll  ntpd
 22  1 22  0  30x80  poll  ntpd
  12313  17356  17356 70  30x90  selectnamed
  17356  1  17356  0  30x90  netio named
  13591  11643  11643 74  30x90  bpf   pflogd
  11643  1  11643  0  30x80  netio pflogd
  22160  30463  30463 73  30x90  poll  syslogd
  30463  1  30463  0  30x80  netio syslogd
 *16977  1  16977 77  70x90dhclient
  26597  1  26597  0  30x80  poll  dhclient
  27019  0  0  0  3 0x14200  bored ttm_swap
  27833  0  0  0  3 0x14200  aiodoned  aiodoned

Re: kernel panic athn0

[David Coppa]

On Tue, Nov 11, 2014 at 1:04 PM, Stefan Sperling s...@stsp.name wrote:
 On Tue, Nov 11, 2014 at 01:44:57PM +0200, Alexey Kurinnij wrote:
 Sorry, in first message ddb only for one processor. This is fresh for both:

 athn0 at pci3 dev 0 function 0 Atheros AR9300 rev 0x01: apic 0 int 16

 Sorry, this chip isn't supported. See the man page -- it's not listed.

 Damien committed untested code for this chip years ago and made the
 driver use that code (see r1.1 in CVS log for dev/ic/ar9003.c).
 There have been various crashes as a result, some already fixed,
 some not fixed.

 Since this problem keeps coming up, and ar9003 cards are known to be
 broken, and nobody is working on fixing them I believe we should
 simply stop the kernel from attaching them for now.

Indeed.
ok with me.

Ciao,
David

 Index: if_athn_pci.c
 ===
 RCS file: /cvs/src/sys/dev/pci/if_athn_pci.c,v
 retrieving revision 1.16
 diff -u -p -r1.16 if_athn_pci.c
 --- if_athn_pci.c   8 Jul 2014 08:55:33 -   1.16
 +++ if_athn_pci.c   11 Nov 2014 11:58:33 -
 @@ -97,8 +97,7 @@ static const struct pci_matchid athn_pci
 { PCI_VENDOR_ATHEROS, PCI_PRODUCT_ATHEROS_AR9285 },
 { PCI_VENDOR_ATHEROS, PCI_PRODUCT_ATHEROS_AR2427 },
 { PCI_VENDOR_ATHEROS, PCI_PRODUCT_ATHEROS_AR9227 },
 -   { PCI_VENDOR_ATHEROS, PCI_PRODUCT_ATHEROS_AR9287 },
 -   { PCI_VENDOR_ATHEROS, PCI_PRODUCT_ATHEROS_AR9300 }
 +   { PCI_VENDOR_ATHEROS, PCI_PRODUCT_ATHEROS_AR9287 }
  };

  int

 # ifconfig athn0 up
 panic: kernel diagnostic assertion pin  sc-ngpiopins failed: file
 ../../../../dev/ic/ar9003.c, line 512
 Stopped at  Debugger+0x9:   leave
 RUN AT LEAST 'trace' AND 'ps' AND INCLUDE OUTPUT WHEN REPORTING THIS PANIC!
 IF RUNNING SMP, USE 'mach ddbcpu #' AND 'trace' ON OTHER PROCESSORS, TOO.
 DO NOT EVEN BOTHER REPORTING THIS WITHOUT INCLUDING THAT INFORMATION!
 ddb{1} trace
 Debugger() at Debugger+0x9
 panic() at panic+0xfe
 __assert() at __assert+0x25
 ar9003_gpio_write() at ar9003_gpio_write+0x9d
 athn_init() at athn_init+0xfb
 athn_ioctl() at athn_ioctl+0x1e6
 ifioctl() at ifioctl+0xb18
 sys_ioctl() at sys_ioctl+0x169
 syscall() at syscall+0x297
 --- syscall (number 54) ---
 end of kernel
 end trace frame: 0x7f7bcca0, count: -9
 acpi_pdirpa+0x3fc50a:
 ddb{1} mach ddbcpu 0
 Stopped at  Debugger+0x9:   leave
 RUN AT LEAST 'trace' AND 'ps' AND INCLUDE OUTPUT WHEN REPORTING THIS PANIC!
 IF RUNNING SMP, USE 'mach ddbcpu #' AND 'trace' ON OTHER PROCESSORS, TOO.
 DO NOT EVEN BOTHER REPORTING THIS WITHOUT INCLUDING THAT INFORMATION!
 ddb{0} trace
 Debugger() at Debugger+0x9
 x86_ipi_handler() at x86_ipi_handler+0x64
 Xresume_lapic_ipi() at Xresume_lapic_ipi+0x1b
 --- interrupt ---
 Bad frame pointer: 0x80001ce45c08
 end trace frame: 0x80001ce45c08, count: -3
 __mp_lock+0x42:
 ddb{0} ps
PID   PPID   PGRPUID  S   FLAGS  WAIT  COMMAND
  19450  13014  19450  0  7 0x3ifconfig
  13014  1  13014  0  30x8b  pause ksh
  25598  1  25598  0  30x83  ttyin getty
  18456  1  18456  0  30x83  ttyin getty
  11661  1  11661  0  30x83  ttyin getty
916  1916  0  30x83  ttyin getty
   6800  1   6800  0  30x83  ttyin getty
  26728  1  26728  0  30x80  selectcron
   3038  1   3038  0  30x80  nanosleep sensorsd
  19379  1  19379  0  30x80  kqreadapmd
  12318  1  12318 99  30x90  poll  sndiod
  10631  30214  30214 95  30x90  kqreadsmtpd
   9723  30214  30214 95  30x90  kqreadsmtpd
  20447  30214  30214 95  30x90  kqreadsmtpd
  32443  30214  30214 95  30x90  kqreadsmtpd
  10158  30214  30214 95  30x90  kqreadsmtpd
  26620  30214  30214103  30x90  kqreadsmtpd
  30214  1  30214  0  30x80  kqreadsmtpd
  25074  1  25074 77  30x90  poll  dhcpd
   5058  1   5058  0  30x80  selectsshd
  13567  28172 22 83  30x90  poll  ntpd
  28172 22 22 83  30x90  poll  ntpd
 22  1 22  0  30x80  poll  ntpd
  12313  17356  17356 70  30x90  selectnamed
  17356  1  17356  0  30x90  netio named
  13591  11643  11643 74  30x90  bpf   pflogd
  11643  1  11643  0  30x80  netio pflogd
  22160  30463  30463 73  30x90  poll  syslogd
  30463  1  30463  0  30x80  netio syslogd
 *16977  1  16977 77  70x90dhclient
  26597  1  26597  0  30x80  poll  dhclient
  

Re: Kernel Panic __mp_lock_held in kern_lock.c when using vmt0

[Ville Valkonen]

Hello,

On 4 September 2014 11:30,  s.sm...@gmx.ch wrote:
 Hi all,
 ...
 [demime 1.01d removed an attachment of type image/png which had a name of 
 PS_1_2014-09-01 15_14_25-UI-SRV-MCR-01-test-FC.PNG]

 [demime 1.01d removed an attachment of type image/png which had a name of 
 PS_2_2014-09-01 15_14_25-UI-SRV-MCR-01-test-FC.PNG]

 [demime 1.01d removed an attachment of type image/png which had a name of 
 trace_2014-09-01 15_13_55-UI-SRV-MCR-01-test-FC.PNG]

attachments are be stripped in this mailing list. Mind to upload and
paste link(s), thanks.

--
Kind regards,
Ville Valkonen

Re: kernel panic radeon HD 8570D

[romook]

 Hello, 

Hello

 When startig X on the latest snapshot the kernel paniced, I was stupid
enough not to run the suggested
 command at the ddb prompt because I forgot. 
 
 Here's the error it reported: 
 
 uvm_fault(0xfe823cb0c468, 0x278, 0, 1) - e 
 kernel: page fault trap, code=0
 Stopped at radeon_vm_bo_add+0xaa: movq 0x278(%r15), %rax
 
 I can confirm that the card used to work fine with a snapshot from around
halloween.
 
 On a related note I know that fan control has been enabled on linux 3.13
for this and other radeon cards, would
 it be possible to eventually port it  ?
 
 
have you try :

http://firmware.openbsd.org/firmware/

with fw_update ?

Re: kernel panic from sys/dev/acpi/dsdt.c rev1.210 change

[Jason Crawford]

I can also confirm that newest snapshot works now.

On Thu, Jun 26, 2014 at 7:45 AM, Nils R m...@hxgn.net wrote:
 Works now with the latest snapshot (dsdt.c rev. 1.211), thanks!

Re: kernel panic from sys/dev/acpi/dsdt.c rev1.210 change

[Jason Crawford]

I know on my laptop no acpi meant doesn't work. My saving grace is I
always keep a kernel from the previous snapshot I tried as obsd. So if
bsd doesn't work, I just boot from that. Do you have an older snapshot
kernel you can tell tech support to boot into?

On Thu, Jun 26, 2014 at 7:36 PM, Scott Vanderbilt li...@datagenic.com wrote:
 Having done a little man page reading on boot-time configuration, I learned
 about the existence of ukc. I'm wondering whether something like

   ukc disable acpi0

 might circumvent the kernel panic and allow the boot to successfully
 complete. I'm hoping that since this is a server, ACPI is non-essential.
 Just grasping at straws in an effort to get this machine up and running
 again.

 Thanks.




 On 6/26/2014 4:21 PM, Scott Vanderbilt wrote:

 I have this exact same kernel panic. Unfortunately, it's occurring on a
 host at a remote co-lo. Does anyone know a way that I can get the
 on-site tech to suppress the assertion by way of some boot-time
 configuration? Then at least I can get this machine up and running so I
 can immediately upgrade to the latest snapshot, which apparently fixes
 this issue.

 Thanks.


 On 6/25/2014 8:05 AM, Jason Crawford wrote:

 My system panic's from the KASSERT() call at line 2269 after dsdt.c was
 updated to 1.210.

 All I have is the basic panic message and the dmesg from the last known
 working snapshot kernel. I tried to get more information but my USB
 keyboard does not work in the kernel debugger, and my on-board keyboard
 no longer works at all (I use the laptop as a desktop now). I typed up
 everything I could see of that panic message by hand.

 Any patches that need to be tested I will be glad to try out.

 Here's the panic message and dmesg output.

 --- panic ---
 acpi0 at bios0: rev 2panic: kernel diagnostic assertion
 rgn-v_opregion.iobase % sz == 0 failed: file
 ../../../../dev/acpi/dsdt.c, line 2269
 Stopped atDebugger+0x9:leave
 panic() at panic+0xfe
 __assert() at __assert+0x25
 aml_rwgas() at aml_rwgas+0x1fd
 aml_rwfield() at aml_rwfield+0x205
 aml_eval() at aml_eval+0x1ae
 aml_parse() at aml_parse+0x183d
 aml_parse() at aml_parse+0x1ff
 aml_parse() at aml_parse+0x1ff
 aml_parse() at aml_parse+0x1ff
 end trace frame: 0x81ef48f0, count: 0
 RUN AT LEAST 'trace' AND 'ps' AND INCLUDE OUTPUT WHEN REPORTING THIS
 PANIC!
 IF RUNNING SMP, USE 'mach ddbcpu #' AND 'trace' ON OTHER PROCESSORS,
 TOO.
 DO NOT EVEN BOTHER REPORTING THIS WITHOUT INCLUDING THAT INFORMATION!


 --- dmesg ---
 OpenBSD 5.5-current (GENERIC.MP) #219: Thu Jun 19 22:16:22 MDT 2014
  dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
 real mem = 4209770496 (4014MB)
 avail mem = 4088930304 (3899MB)
 mpath0 at root
 scsibus0 at mpath0: 256 targets
 mainbus0 at root
 bios0 at mainbus0: SMBIOS rev. 2.6 @ 0xdbeda000 (35 entries)
 bios0: vendor Phoenix Technologies LTD version V1.04 date 10/22/2009
 bios0: Gateway NV53
 acpi0 at bios0: rev 2
 acpi0: sleep states S0 S3 S4 S5
 acpi0: tables DSDT FACP SLIC SSDT APIC MCFG HPET
 acpi0: wakeup devices LID0(S3) SLPB(S3) PB2_(S4) PB3_(S4) PB4_(S4)
 PB5_(S4) PB6_(S4) PB7_(S4) PB9_(S4) PB10(S4) OHC0(S3) OHC1(S3) OHC2(S3)
 OHC3(S3) OHC4(S3) EHC0(S3) [...]
 acpitimer0 at acpi0: 3579545 Hz, 32 bits
 acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
 cpu0 at mainbus0: apid 0 (boot processor)
 cpu0: AMD Athlon(tm) II Dual-Core M300, 2000.97 MHz
 cpu0:

 FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,HTT,SSE3,MWAIT,CX16,POPCNT,NXE,MMXX,FFXSR,LONG,3DNOW2,3DNOW,LAHF,CMPLEG,SVM,EAPICSP,AMCR8,ABM,SSE4A,3DNOWP,OSVW,IBS,SKINI

 T,ITSC
 cpu0: 64KB 64b/line 2-way I-cache, 64KB 64b/line 2-way D-cache, 512KB
 64b/line 16-way L2 cache
 cpu0: ITLB 32 4KB entries fully associative, 16 4MB entries fully
 associative
 cpu0: DTLB 48 4KB entries fully associative, 48 4MB entries fully
 associative
 cpu0: AMD erratum 721 detected and fixed
 cpu0: smt 0, core 0, package 0
 mtrr: Pentium Pro MTRR support, 8 var ranges, 88 fixed ranges
 cpu0: apic clock running at 200MHz
 cpu0: mwait min=64, max=64, C-substates=0.0.0.0.0, IBE
 cpu1 at mainbus0: apid 1 (application processor)
 cpu1: AMD Athlon(tm) II Dual-Core M300, 2000.03 MHz
 cpu1:

 FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,HTT,SSE3,MWAIT,CX16,POPCNT,NXE,MMXX,FFXSR,LONG,3DNOW2,3DNOW,LAHF,CMPLEG,SVM,EAPICSP,AMCR8,ABM,SSE4A,3DNOWP,OSVW,IBS,SKINI

 T,ITSC
 cpu1: 64KB 64b/line 2-way I-cache, 64KB 64b/line 2-way D-cache, 512KB
 64b/line 16-way L2 cache
 cpu1: ITLB 32 4KB entries fully associative, 16 4MB entries fully
 associative
 cpu1: DTLB 48 4KB entries fully associative, 48 4MB entries fully
 associative
 cpu1: AMD erratum 721 detected and fixed
 cpu1: smt 0, core 1, package 0
 ioapic0 at mainbus0: apid 2 pa 0xfec0, version 21, 24 pins
 acpimcfg0 at acpi0 addr 0xe000, bus 0-9
 acpihpet0 at acpi0: 14318180 Hz
 acpi0: unable to load 

Re: kernel panic from sys/dev/acpi/dsdt.c rev1.210 change

[Scott Vanderbilt]

Unfortunately, not. It was a fresh install from a CD image to a hard 
drive which I then shipped to the ISP for installation, which replaced a 
failing drive in my machine co-located there.


In any event, bypassing acpi in ukc got the machine up again, and I was 
able to upgrade to the latest snapshot which does indeed resolve the 
issue. All is well again.


Thanks to Chris for confirming the boot-time config option.

On 6/27/2014 6:44 AM, Jason Crawford wrote:

I know on my laptop no acpi meant doesn't work. My saving grace is I
always keep a kernel from the previous snapshot I tried as obsd. So if
bsd doesn't work, I just boot from that. Do you have an older snapshot
kernel you can tell tech support to boot into?

On Thu, Jun 26, 2014 at 7:36 PM, Scott Vanderbilt li...@datagenic.com wrote:

Having done a little man page reading on boot-time configuration, I learned
about the existence of ukc. I'm wondering whether something like

   ukc disable acpi0

might circumvent the kernel panic and allow the boot to successfully
complete. I'm hoping that since this is a server, ACPI is non-essential.
Just grasping at straws in an effort to get this machine up and running
again.

Thanks.




On 6/26/2014 4:21 PM, Scott Vanderbilt wrote:


I have this exact same kernel panic. Unfortunately, it's occurring on a
host at a remote co-lo. Does anyone know a way that I can get the
on-site tech to suppress the assertion by way of some boot-time
configuration? Then at least I can get this machine up and running so I
can immediately upgrade to the latest snapshot, which apparently fixes
this issue.

Thanks.


On 6/25/2014 8:05 AM, Jason Crawford wrote:


My system panic's from the KASSERT() call at line 2269 after dsdt.c was
updated to 1.210.

All I have is the basic panic message and the dmesg from the last known
working snapshot kernel. I tried to get more information but my USB
keyboard does not work in the kernel debugger, and my on-board keyboard
no longer works at all (I use the laptop as a desktop now). I typed up
everything I could see of that panic message by hand.

Any patches that need to be tested I will be glad to try out.

Here's the panic message and dmesg output.

--- panic ---
acpi0 at bios0: rev 2panic: kernel diagnostic assertion
rgn-v_opregion.iobase % sz == 0 failed: file
../../../../dev/acpi/dsdt.c, line 2269
Stopped atDebugger+0x9:leave
panic() at panic+0xfe
__assert() at __assert+0x25
aml_rwgas() at aml_rwgas+0x1fd
aml_rwfield() at aml_rwfield+0x205
aml_eval() at aml_eval+0x1ae
aml_parse() at aml_parse+0x183d
aml_parse() at aml_parse+0x1ff
aml_parse() at aml_parse+0x1ff
aml_parse() at aml_parse+0x1ff
end trace frame: 0x81ef48f0, count: 0
RUN AT LEAST 'trace' AND 'ps' AND INCLUDE OUTPUT WHEN REPORTING THIS
PANIC!
IF RUNNING SMP, USE 'mach ddbcpu #' AND 'trace' ON OTHER PROCESSORS,
TOO.
DO NOT EVEN BOTHER REPORTING THIS WITHOUT INCLUDING THAT INFORMATION!


--- dmesg ---
OpenBSD 5.5-current (GENERIC.MP) #219: Thu Jun 19 22:16:22 MDT 2014
  dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
real mem = 4209770496 (4014MB)
avail mem = 4088930304 (3899MB)
mpath0 at root
scsibus0 at mpath0: 256 targets
mainbus0 at root
bios0 at mainbus0: SMBIOS rev. 2.6 @ 0xdbeda000 (35 entries)
bios0: vendor Phoenix Technologies LTD version V1.04 date 10/22/2009
bios0: Gateway NV53
acpi0 at bios0: rev 2
acpi0: sleep states S0 S3 S4 S5
acpi0: tables DSDT FACP SLIC SSDT APIC MCFG HPET
acpi0: wakeup devices LID0(S3) SLPB(S3) PB2_(S4) PB3_(S4) PB4_(S4)
PB5_(S4) PB6_(S4) PB7_(S4) PB9_(S4) PB10(S4) OHC0(S3) OHC1(S3) OHC2(S3)
OHC3(S3) OHC4(S3) EHC0(S3) [...]
acpitimer0 at acpi0: 3579545 Hz, 32 bits
acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
cpu0 at mainbus0: apid 0 (boot processor)
cpu0: AMD Athlon(tm) II Dual-Core M300, 2000.97 MHz
cpu0:

FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,HTT,SSE3,MWAIT,CX16,POPCNT,NXE,MMXX,FFXSR,LONG,3DNOW2,3DNOW,LAHF,CMPLEG,SVM,EAPICSP,AMCR8,ABM,SSE4A,3DNOWP,OSVW,IBS,SKINI

T,ITSC
cpu0: 64KB 64b/line 2-way I-cache, 64KB 64b/line 2-way D-cache, 512KB
64b/line 16-way L2 cache
cpu0: ITLB 32 4KB entries fully associative, 16 4MB entries fully
associative
cpu0: DTLB 48 4KB entries fully associative, 48 4MB entries fully
associative
cpu0: AMD erratum 721 detected and fixed
cpu0: smt 0, core 0, package 0
mtrr: Pentium Pro MTRR support, 8 var ranges, 88 fixed ranges
cpu0: apic clock running at 200MHz
cpu0: mwait min=64, max=64, C-substates=0.0.0.0.0, IBE
cpu1 at mainbus0: apid 1 (application processor)
cpu1: AMD Athlon(tm) II Dual-Core M300, 2000.03 MHz
cpu1:

FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,HTT,SSE3,MWAIT,CX16,POPCNT,NXE,MMXX,FFXSR,LONG,3DNOW2,3DNOW,LAHF,CMPLEG,SVM,EAPICSP,AMCR8,ABM,SSE4A,3DNOWP,OSVW,IBS,SKINI

T,ITSC
cpu1: 64KB 64b/line 2-way I-cache, 64KB 64b/line 2-way D-cache, 512KB
64b/line 16-way L2 cache
cpu1: ITLB 32 4KB entries fully 

Re: kernel panic from sys/dev/acpi/dsdt.c rev1.210 change

[Stuart Henderson]

On 2014-06-26, Scott Vanderbilt li...@datagenic.com wrote:
 Having done a little man page reading on boot-time configuration, I 
 learned about the existence of ukc. I'm wondering whether something like

ukc disable acpi0

 might circumvent the kernel panic and allow the boot to successfully 
 complete. I'm hoping that since this is a server, ACPI is non-essential. 
 Just grasping at straws in an effort to get this machine up and running 
 again.

I think you should consider ACPI essential on pretty much any x86
machine from the last 4-5 years or so - servers, laptops, standard PCs.

In an emergency such as this you might get away with it briefly, but
some devices are likely not to work, and it's not recommended leaving
it like that for any length of time, ACPI is involved in a lot of
system controls (thermal controls, power etc) and most modern machines
are just not designed/tested to work without it.

Re: kernel panic from sys/dev/acpi/dsdt.c rev1.210 change

[Theo de Raadt]

 On 2014-06-26, Scott Vanderbilt li...@datagenic.com wrote:
  Having done a little man page reading on boot-time configuration, I 
  learned about the existence of ukc. I'm wondering whether something like
 
 ukc disable acpi0
 
  might circumvent the kernel panic and allow the boot to successfully 
  complete. I'm hoping that since this is a server, ACPI is non-essential. 
  Just grasping at straws in an effort to get this machine up and running 
  again.
 
 I think you should consider ACPI essential on pretty much any x86
 machine from the last 4-5 years or so - servers, laptops, standard PCs.

Yes, ACPI is essential.  It is the modern way to interface to the hardware;
it is the modern BIOS API.

The other BIOS interfaces (MPBIOS and PCIBIOS) are totally unreliable and
rotting on most machines these days.   The vendors include support, but they
do not verify their correctness.

 In an emergency such as this you might get away with it briefly, but
 some devices are likely not to work, and it's not recommended leaving
 it like that for any length of time, ACPI is involved in a lot of
 system controls (thermal controls, power etc) and most modern machines
 are just not designed/tested to work without it.

Stuart is correct.  Those of you turning off ACPI are relying on an
interface model we have repeatedly described as broken.

Re: kernel panic from sys/dev/acpi/dsdt.c rev1.210 change

[Scott Vanderbilt]

On 6/27/2014 12:10 PM, Stuart Henderson wrote:

On 2014-06-26, Scott Vanderbilt li...@datagenic.com wrote:

Having done a little man page reading on boot-time configuration, I
learned about the existence of ukc. I'm wondering whether something like

ukc disable acpi0

might circumvent the kernel panic and allow the boot to successfully
complete. I'm hoping that since this is a server, ACPI is non-essential.
Just grasping at straws in an effort to get this machine up and running
again.


I think you should consider ACPI essential on pretty much any x86
machine from the last 4-5 years or so - servers, laptops, standard PCs.

In an emergency such as this you might get away with it briefly, but
some devices are likely not to work, and it's not recommended leaving
it like that for any length of time, ACPI is involved in a lot of
system controls (thermal controls, power etc) and most modern machines
are just not designed/tested to work without it.



Thanks for clarifying.

Disabling acpi was only meant to be a stopgap measure so I could get 
around the assertion in the kernel that caused a panic on boot. Once I 
was able to boot the machine, I upgraded to a later snapshot in which 
the assertion was removed. I never intended to permanently disable acpi. 
As the machine was at a remote co-lo, I felt had no other choice.


Is there some better way that I should have handled this situation?

Re: kernel panic from sys/dev/acpi/dsdt.c rev1.210 change

[Mike Larkin]

On Fri, Jun 27, 2014 at 01:15:59PM -0600, Theo de Raadt wrote:
  On 2014-06-26, Scott Vanderbilt li...@datagenic.com wrote:
   Having done a little man page reading on boot-time configuration, I 
   learned about the existence of ukc. I'm wondering whether something like
  
  ukc disable acpi0
  
   might circumvent the kernel panic and allow the boot to successfully 
   complete. I'm hoping that since this is a server, ACPI is non-essential. 
   Just grasping at straws in an effort to get this machine up and running 
   again.
  
  I think you should consider ACPI essential on pretty much any x86
  machine from the last 4-5 years or so - servers, laptops, standard PCs.
 
 Yes, ACPI is essential.  It is the modern way to interface to the hardware;
 it is the modern BIOS API.
 
 The other BIOS interfaces (MPBIOS and PCIBIOS) are totally unreliable and
 rotting on most machines these days.   The vendors include support, but they
 do not verify their correctness.
 
  In an emergency such as this you might get away with it briefly, but
  some devices are likely not to work, and it's not recommended leaving
  it like that for any length of time, ACPI is involved in a lot of
  system controls (thermal controls, power etc) and most modern machines
  are just not designed/tested to work without it.
 
 Stuart is correct.  Those of you turning off ACPI are relying on an
 interface model we have repeatedly described as broken.
 

 I have some hardware that doesn't work. Should I just disable mainbus? That
way it doesn't attach.

Maybe that would fix the problem.

-ml

Re: kernel panic from sys/dev/acpi/dsdt.c rev1.210 change

[Mike Larkin]

On Fri, Jun 27, 2014 at 12:37:33PM -0700, Scott Vanderbilt wrote:
 On 6/27/2014 12:10 PM, Stuart Henderson wrote:
 On 2014-06-26, Scott Vanderbilt li...@datagenic.com wrote:
 Having done a little man page reading on boot-time configuration, I
 learned about the existence of ukc. I'm wondering whether something like
 
 ukc disable acpi0
 
 might circumvent the kernel panic and allow the boot to successfully
 complete. I'm hoping that since this is a server, ACPI is non-essential.
 Just grasping at straws in an effort to get this machine up and running
 again.
 
 I think you should consider ACPI essential on pretty much any x86
 machine from the last 4-5 years or so - servers, laptops, standard PCs.
 
 In an emergency such as this you might get away with it briefly, but
 some devices are likely not to work, and it's not recommended leaving
 it like that for any length of time, ACPI is involved in a lot of
 system controls (thermal controls, power etc) and most modern machines
 are just not designed/tested to work without it.
 
 
 Thanks for clarifying.
 
 Disabling acpi was only meant to be a stopgap measure so I could get
 around the assertion in the kernel that caused a panic on boot. Once
 I was able to boot the machine, I upgraded to a later snapshot in
 which the assertion was removed. I never intended to permanently
 disable acpi. As the machine was at a remote co-lo, I felt had no
 other choice.
 
 Is there some better way that I should have handled this situation?
 

Keep another kernel in / that is known working.

-ml

Re: kernel panic from sys/dev/acpi/dsdt.c rev1.210 change

[patrick keshishian]

On 6/27/14, Theo de Raadt dera...@cvs.openbsd.org wrote:
 On 2014-06-26, Scott Vanderbilt li...@datagenic.com wrote:
  Having done a little man page reading on boot-time configuration, I
  learned about the existence of ukc. I'm wondering whether something
  like
 
 ukc disable acpi0
 
  might circumvent the kernel panic and allow the boot to successfully
  complete. I'm hoping that since this is a server, ACPI is non-essential.
 
  Just grasping at straws in an effort to get this machine up and running
 
  again.

 I think you should consider ACPI essential on pretty much any x86
 machine from the last 4-5 years or so - servers, laptops, standard PCs.

 Yes, ACPI is essential.  It is the modern way to interface to the hardware;
 it is the modern BIOS API.

viva pragmatism!
http://www.openbsd.org/lyrics.html#45
:)
--patrick


 The other BIOS interfaces (MPBIOS and PCIBIOS) are totally unreliable and
 rotting on most machines these days.   The vendors include support, but
 they
 do not verify their correctness.

 In an emergency such as this you might get away with it briefly, but
 some devices are likely not to work, and it's not recommended leaving
 it like that for any length of time, ACPI is involved in a lot of
 system controls (thermal controls, power etc) and most modern machines
 are just not designed/tested to work without it.

 Stuart is correct.  Those of you turning off ACPI are relying on an
 interface model we have repeatedly described as broken.

Re: kernel panic from sys/dev/acpi/dsdt.c rev1.210 change

[Nils R]

Works now with the latest snapshot (dsdt.c rev. 1.211), thanks!

Re: kernel panic from sys/dev/acpi/dsdt.c rev1.210 change

[Scott Vanderbilt]

I have this exact same kernel panic. Unfortunately, it's occurring on a 
host at a remote co-lo. Does anyone know a way that I can get the 
on-site tech to suppress the assertion by way of some boot-time 
configuration? Then at least I can get this machine up and running so I 
can immediately upgrade to the latest snapshot, which apparently fixes 
this issue.


Thanks.


On 6/25/2014 8:05 AM, Jason Crawford wrote:

My system panic's from the KASSERT() call at line 2269 after dsdt.c was
updated to 1.210.

All I have is the basic panic message and the dmesg from the last known
working snapshot kernel. I tried to get more information but my USB
keyboard does not work in the kernel debugger, and my on-board keyboard
no longer works at all (I use the laptop as a desktop now). I typed up
everything I could see of that panic message by hand.

Any patches that need to be tested I will be glad to try out.

Here's the panic message and dmesg output.

--- panic ---
acpi0 at bios0: rev 2panic: kernel diagnostic assertion
rgn-v_opregion.iobase % sz == 0 failed: file
../../../../dev/acpi/dsdt.c, line 2269
Stopped atDebugger+0x9:leave
panic() at panic+0xfe
__assert() at __assert+0x25
aml_rwgas() at aml_rwgas+0x1fd
aml_rwfield() at aml_rwfield+0x205
aml_eval() at aml_eval+0x1ae
aml_parse() at aml_parse+0x183d
aml_parse() at aml_parse+0x1ff
aml_parse() at aml_parse+0x1ff
aml_parse() at aml_parse+0x1ff
end trace frame: 0x81ef48f0, count: 0
RUN AT LEAST 'trace' AND 'ps' AND INCLUDE OUTPUT WHEN REPORTING THIS PANIC!
IF RUNNING SMP, USE 'mach ddbcpu #' AND 'trace' ON OTHER PROCESSORS, TOO.
DO NOT EVEN BOTHER REPORTING THIS WITHOUT INCLUDING THAT INFORMATION!


--- dmesg ---
OpenBSD 5.5-current (GENERIC.MP) #219: Thu Jun 19 22:16:22 MDT 2014
 dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
real mem = 4209770496 (4014MB)
avail mem = 4088930304 (3899MB)
mpath0 at root
scsibus0 at mpath0: 256 targets
mainbus0 at root
bios0 at mainbus0: SMBIOS rev. 2.6 @ 0xdbeda000 (35 entries)
bios0: vendor Phoenix Technologies LTD version V1.04 date 10/22/2009
bios0: Gateway NV53
acpi0 at bios0: rev 2
acpi0: sleep states S0 S3 S4 S5
acpi0: tables DSDT FACP SLIC SSDT APIC MCFG HPET
acpi0: wakeup devices LID0(S3) SLPB(S3) PB2_(S4) PB3_(S4) PB4_(S4)
PB5_(S4) PB6_(S4) PB7_(S4) PB9_(S4) PB10(S4) OHC0(S3) OHC1(S3) OHC2(S3)
OHC3(S3) OHC4(S3) EHC0(S3) [...]
acpitimer0 at acpi0: 3579545 Hz, 32 bits
acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
cpu0 at mainbus0: apid 0 (boot processor)
cpu0: AMD Athlon(tm) II Dual-Core M300, 2000.97 MHz
cpu0:
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,HTT,SSE3,MWAIT,CX16,POPCNT,NXE,MMXX,FFXSR,LONG,3DNOW2,3DNOW,LAHF,CMPLEG,SVM,EAPICSP,AMCR8,ABM,SSE4A,3DNOWP,OSVW,IBS,SKINI
T,ITSC
cpu0: 64KB 64b/line 2-way I-cache, 64KB 64b/line 2-way D-cache, 512KB
64b/line 16-way L2 cache
cpu0: ITLB 32 4KB entries fully associative, 16 4MB entries fully
associative
cpu0: DTLB 48 4KB entries fully associative, 48 4MB entries fully
associative
cpu0: AMD erratum 721 detected and fixed
cpu0: smt 0, core 0, package 0
mtrr: Pentium Pro MTRR support, 8 var ranges, 88 fixed ranges
cpu0: apic clock running at 200MHz
cpu0: mwait min=64, max=64, C-substates=0.0.0.0.0, IBE
cpu1 at mainbus0: apid 1 (application processor)
cpu1: AMD Athlon(tm) II Dual-Core M300, 2000.03 MHz
cpu1:
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,HTT,SSE3,MWAIT,CX16,POPCNT,NXE,MMXX,FFXSR,LONG,3DNOW2,3DNOW,LAHF,CMPLEG,SVM,EAPICSP,AMCR8,ABM,SSE4A,3DNOWP,OSVW,IBS,SKINI
T,ITSC
cpu1: 64KB 64b/line 2-way I-cache, 64KB 64b/line 2-way D-cache, 512KB
64b/line 16-way L2 cache
cpu1: ITLB 32 4KB entries fully associative, 16 4MB entries fully
associative
cpu1: DTLB 48 4KB entries fully associative, 48 4MB entries fully
associative
cpu1: AMD erratum 721 detected and fixed
cpu1: smt 0, core 1, package 0
ioapic0 at mainbus0: apid 2 pa 0xfec0, version 21, 24 pins
acpimcfg0 at acpi0 addr 0xe000, bus 0-9
acpihpet0 at acpi0: 14318180 Hz
acpi0: unable to load \\_SB_.PCI0._INI.EXH2
acpiprt0 at acpi0: bus 0 (PCI0)
acpiprt1 at acpi0: bus -1 (PB2_)
acpiprt2 at acpi0: bus -1 (PB3_)
acpiprt3 at acpi0: bus 3 (PB4_)
acpiprt4 at acpi0: bus -1 (PB5_)
acpiprt5 at acpi0: bus 9 (PB6_)
acpiprt6 at acpi0: bus -1 (PB7_)
acpiprt7 at acpi0: bus -1 (PB9_)
acpiprt8 at acpi0: bus -1 (PB10)
acpiprt9 at acpi0: bus 10 (P2P_)
acpiprt10 at acpi0: bus 1 (AGP_)
acpiec0 at acpi0
acpicpu0 at acpi0: PSS
acpicpu1 at acpi0: PSS
acpitz0 at acpi0: critical temperature is 95 degC
acpitz1 at acpi0: critical temperature is 95 degC
acpibtn0 at acpi0: PWRB
acpibtn1 at acpi0: LID0
acpibtn2 at acpi0: SLPB
acpibat0 at acpi0: BAT0 model AS09A61 serial  4548 type LION oem 494453
acpiac0 at acpi0: AC unit online
acpivideo0 at acpi0: VGA_
acpivideo1 at acpi0: VGA_
acpivout0 at acpivideo1: LCD_
cpu0: 2000 MHz: speeds: 2000 1400 800 MHz
pci0 at mainbus0 bus 0
pchb0 at pci0 dev 0 

Re: kernel panic from sys/dev/acpi/dsdt.c rev1.210 change

[Scott Vanderbilt]

Having done a little man page reading on boot-time configuration, I 
learned about the existence of ukc. I'm wondering whether something like


  ukc disable acpi0

might circumvent the kernel panic and allow the boot to successfully 
complete. I'm hoping that since this is a server, ACPI is non-essential. 
Just grasping at straws in an effort to get this machine up and running 
again.


Thanks.



On 6/26/2014 4:21 PM, Scott Vanderbilt wrote:

I have this exact same kernel panic. Unfortunately, it's occurring on a
host at a remote co-lo. Does anyone know a way that I can get the
on-site tech to suppress the assertion by way of some boot-time
configuration? Then at least I can get this machine up and running so I
can immediately upgrade to the latest snapshot, which apparently fixes
this issue.

Thanks.


On 6/25/2014 8:05 AM, Jason Crawford wrote:

My system panic's from the KASSERT() call at line 2269 after dsdt.c was
updated to 1.210.

All I have is the basic panic message and the dmesg from the last known
working snapshot kernel. I tried to get more information but my USB
keyboard does not work in the kernel debugger, and my on-board keyboard
no longer works at all (I use the laptop as a desktop now). I typed up
everything I could see of that panic message by hand.

Any patches that need to be tested I will be glad to try out.

Here's the panic message and dmesg output.

--- panic ---
acpi0 at bios0: rev 2panic: kernel diagnostic assertion
rgn-v_opregion.iobase % sz == 0 failed: file
../../../../dev/acpi/dsdt.c, line 2269
Stopped atDebugger+0x9:leave
panic() at panic+0xfe
__assert() at __assert+0x25
aml_rwgas() at aml_rwgas+0x1fd
aml_rwfield() at aml_rwfield+0x205
aml_eval() at aml_eval+0x1ae
aml_parse() at aml_parse+0x183d
aml_parse() at aml_parse+0x1ff
aml_parse() at aml_parse+0x1ff
aml_parse() at aml_parse+0x1ff
end trace frame: 0x81ef48f0, count: 0
RUN AT LEAST 'trace' AND 'ps' AND INCLUDE OUTPUT WHEN REPORTING THIS
PANIC!
IF RUNNING SMP, USE 'mach ddbcpu #' AND 'trace' ON OTHER PROCESSORS,
TOO.
DO NOT EVEN BOTHER REPORTING THIS WITHOUT INCLUDING THAT INFORMATION!


--- dmesg ---
OpenBSD 5.5-current (GENERIC.MP) #219: Thu Jun 19 22:16:22 MDT 2014
 dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
real mem = 4209770496 (4014MB)
avail mem = 4088930304 (3899MB)
mpath0 at root
scsibus0 at mpath0: 256 targets
mainbus0 at root
bios0 at mainbus0: SMBIOS rev. 2.6 @ 0xdbeda000 (35 entries)
bios0: vendor Phoenix Technologies LTD version V1.04 date 10/22/2009
bios0: Gateway NV53
acpi0 at bios0: rev 2
acpi0: sleep states S0 S3 S4 S5
acpi0: tables DSDT FACP SLIC SSDT APIC MCFG HPET
acpi0: wakeup devices LID0(S3) SLPB(S3) PB2_(S4) PB3_(S4) PB4_(S4)
PB5_(S4) PB6_(S4) PB7_(S4) PB9_(S4) PB10(S4) OHC0(S3) OHC1(S3) OHC2(S3)
OHC3(S3) OHC4(S3) EHC0(S3) [...]
acpitimer0 at acpi0: 3579545 Hz, 32 bits
acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
cpu0 at mainbus0: apid 0 (boot processor)
cpu0: AMD Athlon(tm) II Dual-Core M300, 2000.97 MHz
cpu0:
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,HTT,SSE3,MWAIT,CX16,POPCNT,NXE,MMXX,FFXSR,LONG,3DNOW2,3DNOW,LAHF,CMPLEG,SVM,EAPICSP,AMCR8,ABM,SSE4A,3DNOWP,OSVW,IBS,SKINI

T,ITSC
cpu0: 64KB 64b/line 2-way I-cache, 64KB 64b/line 2-way D-cache, 512KB
64b/line 16-way L2 cache
cpu0: ITLB 32 4KB entries fully associative, 16 4MB entries fully
associative
cpu0: DTLB 48 4KB entries fully associative, 48 4MB entries fully
associative
cpu0: AMD erratum 721 detected and fixed
cpu0: smt 0, core 0, package 0
mtrr: Pentium Pro MTRR support, 8 var ranges, 88 fixed ranges
cpu0: apic clock running at 200MHz
cpu0: mwait min=64, max=64, C-substates=0.0.0.0.0, IBE
cpu1 at mainbus0: apid 1 (application processor)
cpu1: AMD Athlon(tm) II Dual-Core M300, 2000.03 MHz
cpu1:
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,HTT,SSE3,MWAIT,CX16,POPCNT,NXE,MMXX,FFXSR,LONG,3DNOW2,3DNOW,LAHF,CMPLEG,SVM,EAPICSP,AMCR8,ABM,SSE4A,3DNOWP,OSVW,IBS,SKINI

T,ITSC
cpu1: 64KB 64b/line 2-way I-cache, 64KB 64b/line 2-way D-cache, 512KB
64b/line 16-way L2 cache
cpu1: ITLB 32 4KB entries fully associative, 16 4MB entries fully
associative
cpu1: DTLB 48 4KB entries fully associative, 48 4MB entries fully
associative
cpu1: AMD erratum 721 detected and fixed
cpu1: smt 0, core 1, package 0
ioapic0 at mainbus0: apid 2 pa 0xfec0, version 21, 24 pins
acpimcfg0 at acpi0 addr 0xe000, bus 0-9
acpihpet0 at acpi0: 14318180 Hz
acpi0: unable to load \\_SB_.PCI0._INI.EXH2
acpiprt0 at acpi0: bus 0 (PCI0)
acpiprt1 at acpi0: bus -1 (PB2_)
acpiprt2 at acpi0: bus -1 (PB3_)
acpiprt3 at acpi0: bus 3 (PB4_)
acpiprt4 at acpi0: bus -1 (PB5_)
acpiprt5 at acpi0: bus 9 (PB6_)
acpiprt6 at acpi0: bus -1 (PB7_)
acpiprt7 at acpi0: bus -1 (PB9_)
acpiprt8 at acpi0: bus -1 (PB10)
acpiprt9 at acpi0: bus 10 (P2P_)
acpiprt10 at acpi0: bus 1 (AGP_)
acpiec0 at acpi0
acpicpu0 at acpi0: PSS
acpicpu1 at acpi0: PSS

Re: kernel panic from sys/dev/acpi/dsdt.c rev1.210 change

[Chris Cappuccio]

Scott Vanderbilt [li...@datagenic.com] wrote:
 Having done a little man page reading on boot-time configuration, I learned
 about the existence of ukc. I'm wondering whether something like
 
   ukc disable acpi0
 

That or disable acpi

 might circumvent the kernel panic and allow the boot to successfully
 complete. I'm hoping that since this is a server, ACPI is non-essential.
 Just grasping at straws in an effort to get this machine up and running
 again.
 
 Thanks.

Yeah, try it. More likely to work without an MP kernel. Maybe disable acpi; 
boot bsd.sp ?

Re: kernel panic from sys/dev/acpi/dsdt.c rev1.210 change

[Nils R]

Am 25.06.2014 17:05 schrieb Jason Crawford ja...@purebsd.net:

 My system panic's from the KASSERT() call at line 2269 after dsdt.c was 
 updated to 1.210. 

 All I have is the basic panic message and the dmesg from the last known 
 working snapshot kernel. I tried to get more information but my USB 
 keyboard does not work in the kernel debugger, and my on-board keyboard 
 no longer works at all (I use the laptop as a desktop now). I typed up 
 everything I could see of that panic message by hand. 

 Any patches that need to be tested I will be glad to try out. 

 Here's the panic message and dmesg output. 

 --- panic --- 
 acpi0 at bios0: rev 2panic: kernel diagnostic assertion 
 rgn-v_opregion.iobase % sz == 0 failed: file 
 ../../../../dev/acpi/dsdt.c, line 2269 
 Stopped at    Debugger+0x9:    leave 
 panic() at panic+0xfe 
 __assert() at __assert+0x25 
 aml_rwgas() at aml_rwgas+0x1fd 
 aml_rwfield() at aml_rwfield+0x205 
 aml_eval() at aml_eval+0x1ae 
 aml_parse() at aml_parse+0x183d 
 aml_parse() at aml_parse+0x1ff 
 aml_parse() at aml_parse+0x1ff 
 aml_parse() at aml_parse+0x1ff 
 end trace frame: 0x81ef48f0, count: 0 
 RUN AT LEAST 'trace' AND 'ps' AND INCLUDE OUTPUT WHEN REPORTING THIS PANIC! 
 IF RUNNING SMP, USE 'mach ddbcpu #' AND 'trace' ON OTHER PROCESSORS, TOO. 
 DO NOT EVEN BOTHER REPORTING THIS WITHOUT INCLUDING THAT INFORMATION! 


 --- dmesg --- 
 OpenBSD 5.5-current (GENERIC.MP) #219: Thu Jun 19 22:16:22 MDT 2014 
     dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP 
 real mem = 4209770496 (4014MB) 
 avail mem = 4088930304 (3899MB) 
 mpath0 at root 
 scsibus0 at mpath0: 256 targets 
 mainbus0 at root 
 bios0 at mainbus0: SMBIOS rev. 2.6 @ 0xdbeda000 (35 entries) 
 bios0: vendor Phoenix Technologies LTD version V1.04 date 10/22/2009 
 bios0: Gateway NV53 
 acpi0 at bios0: rev 2 
 acpi0: sleep states S0 S3 S4 S5 
 acpi0: tables DSDT FACP SLIC SSDT APIC MCFG HPET 
 acpi0: wakeup devices LID0(S3) SLPB(S3) PB2_(S4) PB3_(S4) PB4_(S4) 
 PB5_(S4) PB6_(S4) PB7_(S4) PB9_(S4) PB10(S4) OHC0(S3) OHC1(S3) OHC2(S3) 
 OHC3(S3) OHC4(S3) EHC0(S3) [...] 
 acpitimer0 at acpi0: 3579545 Hz, 32 bits 
 acpimadt0 at acpi0 addr 0xfee0: PC-AT compat 
 cpu0 at mainbus0: apid 0 (boot processor) 
 cpu0: AMD Athlon(tm) II Dual-Core M300, 2000.97 MHz 
 cpu0: 
 FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,HTT,SSE3,MWAIT,CX16,POPCNT,NXE,MMXX,FFXSR,LONG,3DNOW2,3DNOW,LAHF,CMPLEG,SVM,EAPICSP,AMCR8,ABM,SSE4A,3DNOWP,OSVW,IBS,SKINI
  
 T,ITSC 
 cpu0: 64KB 64b/line 2-way I-cache, 64KB 64b/line 2-way D-cache, 512KB 
 64b/line 16-way L2 cache 
 cpu0: ITLB 32 4KB entries fully associative, 16 4MB entries fully 
 associative 
 cpu0: DTLB 48 4KB entries fully associative, 48 4MB entries fully 
 associative 
 cpu0: AMD erratum 721 detected and fixed 
 cpu0: smt 0, core 0, package 0 
 mtrr: Pentium Pro MTRR support, 8 var ranges, 88 fixed ranges 
 cpu0: apic clock running at 200MHz 
 cpu0: mwait min=64, max=64, C-substates=0.0.0.0.0, IBE 
 cpu1 at mainbus0: apid 1 (application processor) 
 cpu1: AMD Athlon(tm) II Dual-Core M300, 2000.03 MHz 
 cpu1: 
 FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,HTT,SSE3,MWAIT,CX16,POPCNT,NXE,MMXX,FFXSR,LONG,3DNOW2,3DNOW,LAHF,CMPLEG,SVM,EAPICSP,AMCR8,ABM,SSE4A,3DNOWP,OSVW,IBS,SKINI
  
 T,ITSC 
 cpu1: 64KB 64b/line 2-way I-cache, 64KB 64b/line 2-way D-cache, 512KB 
 64b/line 16-way L2 cache 
 cpu1: ITLB 32 4KB entries fully associative, 16 4MB entries fully 
 associative 
 cpu1: DTLB 48 4KB entries fully associative, 48 4MB entries fully 
 associative 
 cpu1: AMD erratum 721 detected and fixed 
 cpu1: smt 0, core 1, package 0 
 ioapic0 at mainbus0: apid 2 pa 0xfec0, version 21, 24 pins 
 acpimcfg0 at acpi0 addr 0xe000, bus 0-9 
 acpihpet0 at acpi0: 14318180 Hz 
 acpi0: unable to load \\_SB_.PCI0._INI.EXH2 
 acpiprt0 at acpi0: bus 0 (PCI0) 
 acpiprt1 at acpi0: bus -1 (PB2_) 
 acpiprt2 at acpi0: bus -1 (PB3_) 
 acpiprt3 at acpi0: bus 3 (PB4_) 
 acpiprt4 at acpi0: bus -1 (PB5_) 
 acpiprt5 at acpi0: bus 9 (PB6_) 
 acpiprt6 at acpi0: bus -1 (PB7_) 
 acpiprt7 at acpi0: bus -1 (PB9_) 
 acpiprt8 at acpi0: bus -1 (PB10) 
 acpiprt9 at acpi0: bus 10 (P2P_) 
 acpiprt10 at acpi0: bus 1 (AGP_) 
 acpiec0 at acpi0 
 acpicpu0 at acpi0: PSS 
 acpicpu1 at acpi0: PSS 
 acpitz0 at acpi0: critical temperature is 95 degC 
 acpitz1 at acpi0: critical temperature is 95 degC 
 acpibtn0 at acpi0: PWRB 
 acpibtn1 at acpi0: LID0 
 acpibtn2 at acpi0: SLPB 
 acpibat0 at acpi0: BAT0 model AS09A61 serial  4548 type LION oem 494453 
 acpiac0 at acpi0: AC unit online 
 acpivideo0 at acpi0: VGA_ 
 acpivideo1 at acpi0: VGA_ 
 acpivout0 at acpivideo1: LCD_ 
 cpu0: 2000 MHz: speeds: 2000 1400 800 MHz 
 pci0 at mainbus0 bus 0 
 pchb0 at pci0 dev 0 function 0 AMD RS880 Host rev 0x00 
 ppb0 at pci0 dev 1 function 0 vendor Acer, unknown product 0x9602 rev 0x00 
 pci1 at ppb0 bus 1 
 radeondrm0 

Re: kernel panic assistance

[Philip Guenther]

On Mon, Apr 7, 2014 at 9:49 AM, sangdrax8 sangdr...@gmail.com wrote:
 I have had a kernel panic that took down my system, and I was wondering if 
 someone
 can provide some insight into where I can begin with this.  I had to reboot 
 the machine
 to get it back up, but I did run a trace and grabbed the output from dmesg 
 before I
 rebooted.

 If this isn't enough information, can someone help me out with what I should 
 capture
 before rebooting to get the machine back up and running? Unfortunately, I 
 can't
 consistently cause this crash so testing is a bit difficult.
...
 mode = 0100644, inum = 415786, fs = /var
 panic: ffs_valloc: dup alloc
 Stopped at  Debugger+0x5:   leave
 RUN AT LEAST 'trace' AND 'ps' AND INCLUDE OUTPUT WHEN REPORTING THIS PANIC!
 IF RUNNING SMP, USE 'mach ddbcpu #' AND 'trace' ON OTHER PROCESSORS, TOO.
 DO NOT EVEN BOTHER REPORTING THIS WITHOUT INCLUDING THAT INFORMATION!
 ddb{0} ddb{0} Debugger() at Debugger+0x5
 panic() at panic+0xe4
 ffs1_reallocblks() at ffs1_reallocblks

This means that a free inode was not correctly zeroed out previously.
This indicates that serious filesystem damage occurred previously; did
this machine crash in the middle of writes in the past and not get
fsck'ed?

At this point, I think the way to make this machine reliable again is
to newfs all the partitions.  I would back up the config files and
reinstall, or rather, install a newer version.


Philip Guenther

Re: Kernel panic with jme driver

[Comète]

Hi,

In March, i reported this bug on jme driver and hopefully Brad Smith 
answered with the following patch which work nicely, many thanks to him 
! Now two releases later, this patch is still not included. I sent him 2 
or 3 mails to ask why but didn't get any answer.
Do you know any particular reason for this patch not being applied ?

Thanks a lot !


Le 24/03/2013 15:46, Comète a écrit :
 Hello,
 
 i own a Shuttle XS35v2 and actually run OpenBSD 5.2 amd64 (SMP) on it.
 I run OpenBSD on this hardware since 4.9 and i always encountered the
 following problem, sorry for the late report it took me some time to
 identify it:
 
 The NIC uses the jme driver which run in a kernel panic each time i
 upload data from the XS35v2 to any other machine with a transfer rate
 above 7 Mbits/s (XS35v2 - other PC). No problem at all when
 downloading.
 
 I made some tests that you can follow to easily reproduce the crash:
 
 On the XS35:
 
 iperf -s
 
 On the other machine:
 
 iperf -c IP_XS35 -n 2048M -d
 
 This is a screenshot of the kernel panic message:
 
 https://cloud.geekandfree.org/public.php?service=filest=06ff6a95949e392989191588d360b875download
 
 and i join the dmesg:
 
 
 OpenBSD 5.2 (GENERIC.MP) #368: Wed Aug  1 10:04:49 MDT 2012
 dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
 real mem = 2136670208 (2037MB)
 avail mem = 2057482240 (1962MB)
 mainbus0 at root
 bios0 at mainbus0: SMBIOS rev. 2.6 @ 0xfc8b0 (23 entries)
 bios0: vendor American Megatrends Inc. version 080015 date 06/23/2011
 bios0: Standard XS35
 acpi0 at bios0: rev 2
 acpi0: sleep states S0 S3 S4 S5
 acpi0: tables DSDT FACP APIC MCFG SLIC OEMB HPET GSCI
 acpi0: wakeup devices P0P1(S4) AZAL(S3) P0P4(S4) P0P5(S4) JLAN(S3)
 P0P6(S4) P0P7(S4) P0P8(S4) P0P9(S4) USB0(S3) USB1(S3) USB2(S3)
 USB3(S3) EUSB(S3)
 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) Atom(TM) CPU D525 @ 1.80GHz, 2154.83 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,SBF,SSE3,MWAIT,DS-CPL,TM2,SSSE3,CX16,xTPR,PDCM,MOVBE,NXE,LONG,LAHF
 cpu0: 512KB 64b/line 8-way L2 cache
 cpu0: apic clock running at 199MHz
 cpu1 at mainbus0: apid 2 (application processor)
 cpu1: Intel(R) Atom(TM) CPU D525 @ 1.80GHz, 1795.50 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,SBF,SSE3,MWAIT,DS-CPL,TM2,SSSE3,CX16,xTPR,PDCM,MOVBE,NXE,LONG,LAHF
 cpu1: 512KB 64b/line 8-way L2 cache
 cpu2 at mainbus0: apid 1 (application processor)
 cpu2: Intel(R) Atom(TM) CPU D525 @ 1.80GHz, 1795.50 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,SBF,SSE3,MWAIT,DS-CPL,TM2,SSSE3,CX16,xTPR,PDCM,MOVBE,NXE,LONG,LAHF
 cpu2: 512KB 64b/line 8-way L2 cache
 cpu3 at mainbus0: apid 3 (application processor)
 cpu3: Intel(R) Atom(TM) CPU D525 @ 1.80GHz, 1795.50 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,SBF,SSE3,MWAIT,DS-CPL,TM2,SSSE3,CX16,xTPR,PDCM,MOVBE,NXE,LONG,LAHF
 cpu3: 512KB 64b/line 8-way L2 cache
 ioapic0 at mainbus0: apid 4 pa 0xfec0, version 20, 24 pins
 ioapic0: misconfigured as apic 3, remapped to apid 4
 acpimcfg0 at acpi0 addr 0xe000, bus 0-255
 acpihpet0 at acpi0: 14318179 Hz
 acpiprt0 at acpi0: bus 0 (PCI0)
 acpiprt1 at acpi0: bus 4 (P0P1)
 acpiprt2 at acpi0: bus 1 (P0P4)
 acpiprt3 at acpi0: bus 2 (P0P5)
 acpiprt4 at acpi0: bus -1 (P0P6)
 acpiprt5 at acpi0: bus 3 (P0P7)
 acpiprt6 at acpi0: bus -1 (P0P8)
 acpiprt7 at acpi0: bus -1 (P0P9)
 acpiec0 at acpi0
 acpicpu0 at acpi0
 acpicpu1 at acpi0
 acpicpu2 at acpi0
 acpicpu3 at acpi0
 acpitz0 at acpi0: critical temperature is 104 degC
 acpibtn0 at acpi0: SLPB
 acpibtn1 at acpi0: PWRB
 acpivideo0 at acpi0: GFX0
 acpivout0 at acpivideo0: LCD_
 pci0 at mainbus0 bus 0
 pchb0 at pci0 dev 0 function 0 Intel Pineview DMI rev 0x02
 vga1 at pci0 dev 2 function 0 Intel Pineview Video rev 0x02
 wsdisplay0 at vga1 mux 1: console (80x25, vt100 emulation)
 wsdisplay0: screen 1-5 added (80x25, vt100 emulation)
 intagp0 at vga1
 agp0 at intagp0: aperture at 0xd000, size 0x1000
 inteldrm0 at vga1: apic 4 int 16
 drm0 at inteldrm0
 Intel Pineview Video rev 0x02 at pci0 dev 2 function 1 not configured
 azalia0 at pci0 dev 27 function 0 Intel 82801GB HD Audio rev 0x02: 
 msi
 azalia0: codecs: IDT 92HD81B1X
 audio0 at azalia0
 ppb0 at pci0 dev 28 function 0 Intel 82801GB PCIE rev 0x02: msi
 pci1 at ppb0 bus 1
 ppb1 at pci0 dev 28 function 1 Intel 82801GB PCIE rev 0x02: msi
 pci2 at ppb1 bus 2
 JMicron SD/MMC rev 0x80 at pci2 dev 0 function 0 not configured
 sdhc0 at pci2 dev 0 function 2 JMicron SD Host Controller rev 0x80:
 apic 4 int 18
 sdmmc0 at sdhc0
 JMicron Memory Stick rev 0x80 at pci2 dev 0 function 3 not configured
 jme0 

Re: Kernel panic with jme driver

[Comète]

Sorry i forgot to include the patch:

Index: if_jme.c
===
RCS file: /home/cvs/src/sys/dev/pci/if_jme.c,v
retrieving revision 1.29
diff -u -p -r1.29 if_jme.c
--- if_jme.c29 Nov 2012 21:10:32 -  1.29
+++ if_jme.c29 Mar 2013 05:45:44 -
@@ -1058,48 +1058,31 @@ jme_encap(struct jme_softc *sc, struct m
struct jme_txdesc *txd;
struct jme_desc *desc;
struct mbuf *m;
-   int maxsegs;
int error, i, prod;
uint32_t cflags;

prod = sc-jme_cdata.jme_tx_prod;
txd = sc-jme_cdata.jme_txdesc[prod];

-   maxsegs = (JME_TX_RING_CNT - sc-jme_cdata.jme_tx_cnt) -
- (JME_TXD_RSVD + 1);
-   if (maxsegs  JME_MAXTXSEGS)
-   maxsegs = JME_MAXTXSEGS;
-   if (maxsegs  (sc-jme_txd_spare - 1))
-   panic(%s: not enough segments %d, sc-sc_dev.dv_xname,
-   maxsegs);
-
error = bus_dmamap_load_mbuf(sc-sc_dmat, txd-tx_dmamap,
 *m_head, BUS_DMA_NOWAIT);
+   if (error != 0  error != EFBIG)
+   goto drop;
if (error != 0) {
-   bus_dmamap_unload(sc-sc_dmat, txd-tx_dmamap);
-   error = EFBIG;
-   }
-   if (error == EFBIG) {
if (m_defrag(*m_head, M_DONTWAIT)) {
-   printf(%s: can't defrag TX mbuf\n,
-   sc-sc_dev.dv_xname);
-   m_freem(*m_head);
-   *m_head = NULL;
-   return (ENOBUFS);
+   error = ENOBUFS;
+   goto drop;
}
-   error = bus_dmamap_load_mbuf(sc-sc_dmat,
-txd-tx_dmamap, *m_head,
-BUS_DMA_NOWAIT);
-   if (error != 0) {
-   printf(%s: could not load defragged TX mbuf\n,
-   sc-sc_dev.dv_xname);
-   m_freem(*m_head);
-   *m_head = NULL;
-   return (error);
-   }
-   } else if (error) {
-   printf(%s: could not load TX mbuf\n, sc-sc_dev.dv_xname);
-   return (error);
+   error = bus_dmamap_load_mbuf(sc-sc_dmat, txd-tx_dmamap,
+*m_head, BUS_DMA_NOWAIT);
+   if (error != 0)
+   goto drop;
+   }
+
+   if (sc-jme_cdata.jme_tx_cnt + txd-tx_dmamap-dm_nsegs +
+   1  JME_TX_RING_CNT - 1) {
+   bus_dmamap_unload(sc-sc_dmat, txd-tx_dmamap);
+   return (ENOBUFS);
}

m = *m_head;
@@ -1127,7 +1110,6 @@ jme_encap(struct jme_softc *sc, struct m
desc-addr_hi = htole32(m-m_pkthdr.len);
desc-addr_lo = 0;
sc-jme_cdata.jme_tx_cnt++;
-   KASSERT(sc-jme_cdata.jme_tx_cnt  JME_TX_RING_CNT - JME_TXD_RSVD);
JME_DESC_INC(prod, JME_TX_RING_CNT);
for (i = 0; i  txd-tx_dmamap-dm_nsegs; i++) {
desc = sc-jme_rdata.jme_tx_ring[prod];
@@ -1137,10 +1119,7 @@ jme_encap(struct jme_softc *sc, struct m
htole32(JME_ADDR_HI(txd-tx_dmamap-dm_segs[i].ds_addr));
desc-addr_lo =
htole32(JME_ADDR_LO(txd-tx_dmamap-dm_segs[i].ds_addr));
-
sc-jme_cdata.jme_tx_cnt++;
-   KASSERT(sc-jme_cdata.jme_tx_cnt =
-JME_TX_RING_CNT - JME_TXD_RSVD);
JME_DESC_INC(prod, JME_TX_RING_CNT);
}

@@ -1163,6 +1142,11 @@ jme_encap(struct jme_softc *sc, struct m
 sc-jme_cdata.jme_tx_ring_map-dm_mapsize, BUS_DMASYNC_PREWRITE);

return (0);
+
+  drop:
+   m_freem(*m_head);
+   *m_head = NULL;
+   return (error);
}

void
@@ -1204,13 +1188,15 @@ jme_start(struct ifnet *ifp)
 * for the NIC to drain the ring.
 */
if (jme_encap(sc, m_head)) {
-   if (m_head == NULL) {
+   if (m_head == NULL)
ifp-if_oerrors++;
-   break;
+   else {
+   IF_PREPEND(ifp-if_snd, m_head);
+   ifp-if_flags |= IFF_OACTIVE;
}
-   ifp-if_flags |= IFF_OACTIVE;
break;
}
+
enq++;

#if NBPFILTER  0



Le 11/11/2013 18:22, Comète a écrit :

Hi,

In March, i reported this bug on jme driver and hopefully Brad Smith
answered with the following patch which work nicely, many thanks to
him ! Now two releases later, this patch is still not included. I sent
him 2 or 3 mails to ask why but didn't get any answer.
Do you know any particular reason for this patch not being applied ?

Thanks a lot !


Le 24/03/2013 15:46, Comète a écrit :
Hello,

i own 

Re: Kernel panic with jme driver

[Vigdis]

On Mon, 11 Nov 2013 18:22:36 +0100,
Comète com...@daknet.org wrote:

 Hi,
 
 In March, i reported this bug on jme driver and hopefully Brad Smith 
 answered with the following patch which work nicely, many thanks to

I've been using the patch on the same hardware since March and never
had any problem.
Thanks!

 him ! Now two releases later, this patch is still not included. I
 sent him 2 or 3 mails to ask why but didn't get any answer.
 Do you know any particular reason for this patch not being applied ?
 
 Thanks a lot !
 
 
 Le 24/03/2013 15:46, Comète a écrit :
  Hello,
  
  i own a Shuttle XS35v2 and actually run OpenBSD 5.2 amd64 (SMP) on
  it. I run OpenBSD on this hardware since 4.9 and i always
  encountered the following problem, sorry for the late report it
  took me some time to identify it:
  
  The NIC uses the jme driver which run in a kernel panic each time i
  upload data from the XS35v2 to any other machine with a transfer
  rate above 7 Mbits/s (XS35v2 - other PC). No problem at all
  when downloading.
  
  I made some tests that you can follow to easily reproduce the crash:
  
  On the XS35:
  
  iperf -s
  
  On the other machine:
  
  iperf -c IP_XS35 -n 2048M -d
  
  This is a screenshot of the kernel panic message:
  
  https://cloud.geekandfree.org/public.php?service=filest=06ff6a95949e392989191588d360b875download
  
  and i join the dmesg:
  
  
  OpenBSD 5.2 (GENERIC.MP) #368: Wed Aug  1 10:04:49 MDT 2012
  dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
  real mem = 2136670208 (2037MB)
  avail mem = 2057482240 (1962MB)
  mainbus0 at root
  bios0 at mainbus0: SMBIOS rev. 2.6 @ 0xfc8b0 (23 entries)
  bios0: vendor American Megatrends Inc. version 080015 date
  06/23/2011 bios0: Standard XS35
  acpi0 at bios0: rev 2
  acpi0: sleep states S0 S3 S4 S5
  acpi0: tables DSDT FACP APIC MCFG SLIC OEMB HPET GSCI
  acpi0: wakeup devices P0P1(S4) AZAL(S3) P0P4(S4) P0P5(S4) JLAN(S3)
  P0P6(S4) P0P7(S4) P0P8(S4) P0P9(S4) USB0(S3) USB1(S3) USB2(S3)
  USB3(S3) EUSB(S3)
  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) Atom(TM) CPU D525 @ 1.80GHz, 2154.83 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,SBF,SSE3,MWAIT,DS-CPL,TM2,SSSE3,CX16,xTPR,PDCM,MOVBE,NXE,LONG,LAHF
  cpu0: 512KB 64b/line 8-way L2 cache
  cpu0: apic clock running at 199MHz
  cpu1 at mainbus0: apid 2 (application processor)
  cpu1: Intel(R) Atom(TM) CPU D525 @ 1.80GHz, 1795.50 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,SBF,SSE3,MWAIT,DS-CPL,TM2,SSSE3,CX16,xTPR,PDCM,MOVBE,NXE,LONG,LAHF
  cpu1: 512KB 64b/line 8-way L2 cache
  cpu2 at mainbus0: apid 1 (application processor)
  cpu2: Intel(R) Atom(TM) CPU D525 @ 1.80GHz, 1795.50 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,SBF,SSE3,MWAIT,DS-CPL,TM2,SSSE3,CX16,xTPR,PDCM,MOVBE,NXE,LONG,LAHF
  cpu2: 512KB 64b/line 8-way L2 cache
  cpu3 at mainbus0: apid 3 (application processor)
  cpu3: Intel(R) Atom(TM) CPU D525 @ 1.80GHz, 1795.50 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,SBF,SSE3,MWAIT,DS-CPL,TM2,SSSE3,CX16,xTPR,PDCM,MOVBE,NXE,LONG,LAHF
  cpu3: 512KB 64b/line 8-way L2 cache
  ioapic0 at mainbus0: apid 4 pa 0xfec0, version 20, 24 pins
  ioapic0: misconfigured as apic 3, remapped to apid 4
  acpimcfg0 at acpi0 addr 0xe000, bus 0-255
  acpihpet0 at acpi0: 14318179 Hz
  acpiprt0 at acpi0: bus 0 (PCI0)
  acpiprt1 at acpi0: bus 4 (P0P1)
  acpiprt2 at acpi0: bus 1 (P0P4)
  acpiprt3 at acpi0: bus 2 (P0P5)
  acpiprt4 at acpi0: bus -1 (P0P6)
  acpiprt5 at acpi0: bus 3 (P0P7)
  acpiprt6 at acpi0: bus -1 (P0P8)
  acpiprt7 at acpi0: bus -1 (P0P9)
  acpiec0 at acpi0
  acpicpu0 at acpi0
  acpicpu1 at acpi0
  acpicpu2 at acpi0
  acpicpu3 at acpi0
  acpitz0 at acpi0: critical temperature is 104 degC
  acpibtn0 at acpi0: SLPB
  acpibtn1 at acpi0: PWRB
  acpivideo0 at acpi0: GFX0
  acpivout0 at acpivideo0: LCD_
  pci0 at mainbus0 bus 0
  pchb0 at pci0 dev 0 function 0 Intel Pineview DMI rev 0x02
  vga1 at pci0 dev 2 function 0 Intel Pineview Video rev 0x02
  wsdisplay0 at vga1 mux 1: console (80x25, vt100 emulation)
  wsdisplay0: screen 1-5 added (80x25, vt100 emulation)
  intagp0 at vga1
  agp0 at intagp0: aperture at 0xd000, size 0x1000
  inteldrm0 at vga1: apic 4 int 16
  drm0 at inteldrm0
  Intel Pineview Video rev 0x02 at pci0 dev 2 function 1 not
  configured azalia0 at pci0 dev 27 function 0 Intel 82801GB HD
  Audio rev 0x02: msi
  azalia0: codecs: IDT 92HD81B1X
  audio0 at azalia0
  ppb0 at pci0 dev 28 function 0 Intel 82801GB PCIE rev 0x02: msi
  pci1 at ppb0 bus 1
  ppb1 at pci0 dev 28 function 1 Intel 82801GB PCIE 

Re: kernel panic avrdude, usb related?

[Byron Klippert]

Same problem exits on Nov 7 snapshot.

On Sat, Nov 9, 2013, at 23:57, Byron Klippert wrote:
 Hello,
 
 
 Fresh install of 5.4, pkg_add avr, avrdragon programmer plugged in via
 usb, invoked `sudo avrdude -c dragon_isp -p attiny4313 -P usb` causes
 the machine to panic.
 
 Tried different avrdragon programmers same thing.
 
 Tried bsd.sp and bsd.mp same thing.
 
 
 Perhaps unrelated but my /etc/motd seems to be missing the last two
 characters .\n Didn't consciously change that from installation
 default.
 
 
 Can't pull ps output at this time, will try a -current and see if
 problem exists there.
 
 
 avrdude version 5.11
 
 
 panic: ehci_device_clear_toggle: queue active
 Stopped at Debugger+0x5; leave
 
 
 trace output handtyped:
 
 Debugger() at Debugger+0x5
 panic() at panic+0xe4
 ehci_device_clear_toggle() at ehci_device_clear_toggle+0x27
 usbd_clear_endpoint_stall() at usbd_clear_endpoint_stall+0x19
 usbd_bulk_transfer() at usbd_bulk_transfer+0xe2
 ugen_do_read() at ugen_do_read+0x384
 ugenread() at ugenread+0x44
 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+0x249
 --- syscall (number 3) ---
 end of kernel
 end trace frame: 0x86a643339b8, count: -13
 0x86a63c74a1a:
 
 
 dmesg:
 
 OpenBSD 5.4 (GENERIC.MP) #41: Tue Jul 30 15:30:02 MDT 2013
 dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
 real mem = 8254582784 (7872MB)
 avail mem = 8027119616 (7655MB)
 mainbus0 at root
 bios0 at mainbus0: SMBIOS rev. 2.7 @ 0xdae9d000 (70 entries)
 bios0: vendor LENOVO version G2ET82WW (2.02 ) date 09/11/2012
 bios0: LENOVO 2306CTO
 acpi0 at bios0: rev 2
 acpi0: sleep states S0 S3 S4 S5
 acpi0: tables DSDT FACP SLIC TCPA SSDT SSDT SSDT HPET APIC MCFG ECDT
 FPDT ASF! UEFI UEFI POAT SSDT SSDT UEFI DBG2
 acpi0: wakeup devices LID_(S4) SLPB(S3) IGBE(S4) EXP3(S4) XHCI(S3)
 EHC1(S3) EHC2(S3) HDEF(S4)
 acpitimer0 at acpi0: 3579545 Hz, 24 bits
 acpihpet0 at acpi0: 14318179 Hz
 acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
 cpu0 at mainbus0: apid 0 (boot processor)
 cpu0: Intel(R) Core(TM) i5-3360M CPU @ 2.80GHz, 1197.49 MHz
 cpu0:
 FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,POPCNT,DEADLINE,AES,XSAVE,AVX,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
 cpu1 at mainbus0: apid 1 (application processor)
 cpu1: Intel(R) Core(TM) i5-3360M CPU @ 2.80GHz, 1197.29 MHz
 cpu1:
 FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,POPCNT,DEADLINE,AES,XSAVE,AVX,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-3360M CPU @ 2.80GHz, 1197.28 MHz
 cpu2:
 FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,POPCNT,DEADLINE,AES,XSAVE,AVX,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-3360M CPU @ 2.80GHz, 1197.29 MHz
 cpu3:
 FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,POPCNT,DEADLINE,AES,XSAVE,AVX,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
 acpiec0 at acpi0
 acpiprt0 at acpi0: bus 0 (PCI0)
 acpiprt1 at acpi0: bus -1 (PEG_)
 acpiprt2 at acpi0: bus 2 (EXP1)
 acpiprt3 at acpi0: bus 3 (EXP2)
 acpiprt4 at acpi0: bus 4 (EXP3)
 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: PUBS
 acpitz0 at acpi0: critical temperature is 103 degC
 acpibtn0 at acpi0: LID_
 acpibtn1 at acpi0: SLPB
 acpibat0 at acpi0: BAT0 model 45N1029 serial  4430 type LION oem LGC
 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: 2801, 2800, 2700, 2600, 2500,
 2300, 2200, 2100, 2000, 1900, 1800, 1700, 1500, 1400, 1300, 1200 MHz
 

Re: Kernel Panic with Mon May 13 snapshot

[Атанас Владимиров]

Hi,
I built a kernel that include the fix in pf.c and everything is fine now.
Thanks,
Atanas Vladimirov

[ns]~$ uptime
 5:37PM  up 3 days,  3:44, 1 user, load averages: 1.23, 0.74, 0.64

[ns]~$ dmesg
OpenBSD 5.3-current (GENERIC) #0: Wed May 15 23:59:01 EEST 2013

vl...@ns.bsdbg.net:/usr/src/sys/arch/i386/compile/GENERIC
cpu0: AMD Athlon(TM) XP1600+ (AuthenticAMD 686-class, 256KB L2 cache)
1.42 GHz
cpu0:
FPU,V86,DE,PSE,TSC,MSR,PAE,MCE,CX8,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,MMX,FXSR,SSE,MMXX,3DNOW2,3DNOW
real mem  = 804765696 (767MB)
avail mem = 780185600 (744MB)
mainbus0 at root
bios0 at mainbus0: AT/286+ BIOS, date 03/03/03, BIOS32 rev. 0 @ 0xf0d00,
SMBIOS rev. 2.3 @ 0xf2bc0 (46 entries)
bios0: vendor Award Software, Inc. version ASUS A7V266-C ACPI BIOS Rev
1014 date 03/03/2003
bios0: ASUSTeK Computer INC. A7V266-C
apm0 at bios0: Power Management spec V1.2 (BIOS management disabled)
apm0: APM power management enable: unrecognized device ID (9)
apm0: APM engage (device 1): power management disabled (1)
acpi at bios0 function 0x0 not configured
pcibios0 at bios0: rev 2.1 @ 0xf/0x1572
pcibios0: PCI IRQ Routing Table rev 1.0 @ 0xf14b0/192 (10 entries)
pcibios0: PCI Interrupt Router at 000:17:0 (VIA VT82C586 ISA rev 0x00)
pcibios0: PCI bus #1 is the last bus
bios0: ROM list: 0xc/0x8000 0xc8000/0x1000 0xcc000/0x1000
cpu0 at mainbus0: (uniprocessor)
pci0 at mainbus0 bus 0: configuration mode 1 (bios)
pchb0 at pci0 dev 0 function 0 VIA VT8366 PCI rev 0x00
viaagp0 at pchb0: v2
agp0 at viaagp0: aperture at 0xfe80, size 0xe40
ppb0 at pci0 dev 1 function 0 VIA VT8366 AGP rev 0x00
pci1 at ppb0 bus 1
vga1 at pci0 dev 12 function 0 S3 ViRGE DX/GX rev 0x01
wsdisplay0 at vga1 mux 1: console (80x25, vt100 emulation)
wsdisplay0: screen 1-5 added (80x25, vt100 emulation)
em0 at pci0 dev 13 function 0 Intel PRO/1000MT (82540EM) rev 0x02: irq
11, address 00:07:e9:10:32:a8
em1 at pci0 dev 15 function 0 Intel PRO/1000MT (82540EM) rev 0x02: irq
10, address 00:07:e9:10:2a:20
viapm0 at pci0 dev 17 function 0 VIA VT8233A ISA rev 0x00: SMI
iic0 at viapm0
lm1 at iic0 addr 0x2d: AS99127F
viapm0: 24-bit timer at 3579545Hz
pciide0 at pci0 dev 17 function 1 VIA VT82C571 IDE rev 0x06: ATA133,
channel 0 configured to compatibility, channel 1 confi
gured to compatibility
wd0 at pciide0 channel 0 drive 0: WDC WD800JB-00ETA0
wd0: 16-sector PIO, LBA48, 76319MB, 156301488 sectors
wd0(pciide0:0:0): using PIO mode 4, Ultra-DMA mode 5
pciide0: channel 1 disabled (no drives)
uhci0 at pci0 dev 17 function 2 VIA VT83C572 USB rev 0x23: irq 12
uhci1 at pci0 dev 17 function 3 VIA VT83C572 USB rev 0x23: irq 12
usb0 at uhci0: USB revision 1.0
uhub0 at usb0 VIA UHCI root hub rev 1.00/1.00 addr 1
usb1 at uhci1: USB revision 1.0
uhub1 at usb1 VIA UHCI root hub rev 1.00/1.00 addr 1
isa0 at mainbus0
isadma0 at isa0
com0 at isa0 port 0x3f8/8 irq 4: ns16550a, 16 byte fifo
com0: console
com1 at isa0 port 0x2f8/8 irq 3: ns16550a, 16 byte fifo
pckbc0 at isa0 port 0x60/5
pckbd0 at pckbc0 (kbd slot)
pckbc0: using irq 1 for kbd slot
wskbd0 at pckbd0: console keyboard, using wsdisplay0
pcppi0 at isa0 port 0x61
spkr0 at pcppi0
npx0 at isa0 port 0xf0/16: reported by CPUID; using exception 16
mtrr: Pentium Pro MTRR support
vscsi0 at root
scsibus0 at vscsi0: 256 targets
softraid0 at root
scsibus1 at softraid0: 256 targets
root on wd0a (b198b672451a33ab.a) swap on wd0b dump on wd0b
WARNING: / was not properly unmounted

Re: Kernel Panic with Mon May 13 snapshot

[Ted Unangst]

On Wed, May 15, 2013 at 22:31, ?? ?? wrote:
 Hi,
 I had a kernel panic after upgrade to latest snapshot.
 `trace` and `ps` follows, dmesg at bottom
 
 OpenBSD/i386 (ns.bsdbg.net) (tty00)
 
 login:pool_do_get: pfstatekeypl: curpage NULL, nitems 1

There was a fix to pf.c made yesterday that I would guess fixes this.

Re: Kernel Panic with Mon May 13 snapshot

[Атанас Владимиров]

2013/5/15 Ted Unangst t...@tedunangst.com

 On Wed, May 15, 2013 at 22:31, ?? ?? wrote:
  Hi,
  I had a kernel panic after upgrade to latest snapshot.
  `trace` and `ps` follows, dmesg at bottom
 
  OpenBSD/i386 (ns.bsdbg.net) (tty00)
 
  login:pool_do_get: pfstatekeypl: curpage NULL, nitems 1

 There was a fix to pf.c made yesterday that I would guess fixes this.


May I try to build and install a new kernel with that fix, or to wait for a
new snapshot?
Thank you.

Atanas Vladimirov

Re: Kernel Panic with Mon May 13 snapshot

[Chris Cappuccio]

?? ?? [don.na...@gmail.com] wrote:
 
 May I try to build and install a new kernel with that fix, or to wait for a
 new snapshot?
 Thank you.
 

That depends on your preference.