And also I get the same panic with 'acpidump -dt', tested with the
yesterday's image from releng -
http://nycdn.netbsd.org/pub/NetBSD-daily/HEAD/201711212310Z/images/NetBSD-8.99.7-amd64.iso
 .

Chavdar


On Wed, 22 Nov 2017 at 09:17 Chavdar Ivanov <ci4...@gmail.com> wrote:

> Interesting - I reported earlier exactly the same sequence -
> ...
> pmap_enter_ma() at pmap_enter_ma+0xe2a
> pmap_enter_default() at pmap_enter_default+0x1d
> udv_fault() at udv_fault+0x151
> uvm_fault_internal() at uvm_fault_internal+0x6d4
> trap() at trap+0x3f0
> --- trap (number 6) ---
> ...
>
> when starting Xorg under VirtualBox (it works on real hardware).
>
> Chavdar
>
> On Wed, 22 Nov 2017 at 02:10 Kengo NAKAHARA <k-nakah...@iij.ad.jp> wrote:
>
>> Hi,
>>
>> I met a panic when I do "acpidump -dt" on -current(Nov 22). The specific
>> version is the following commit.
>>
>> https://mail-index.netbsd.org/source-changes/2017/11/21/msg089839.html
>> # It includes chs@n.o's fix of pmap_enter_ma() and
>> uvm_fault_upper_enter().
>>
>> Here is the panic message and backtrace.
>> ====================
>> panic: prevented access to 0x10 (SMAP)
>> fatal breakpoint trap in supervisor mode
>> trap type 1 code 0 rip 0xffffffff8021d2d5 cs 0x8 rflags 0x246 cr2 0x10
>> ilevel 0 rsp 0xffffe40110c4b7e0
>> curlwp 0xffffe4027b7cd220 pid 866.1 lowest kstack 0xffffe40110c482c0
>> Stopped in pid 866.1 (acpidump) at      netbsd:breakpoint+0x5:  leave
>> db{6}> bt
>> breakpoint() at netbsd:breakpoint+0x5
>> vpanic() at netbsd:vpanic+0x140
>> panic() at netbsd:panic+0x3c
>> trap() at netbsd:trap+0xbf0
>> --- trap (number 6) ---
>> pmap_enter_ma() at netbsd:pmap_enter_ma+0xe2a
>> pmap_enter_default() at netbsd:pmap_enter_default+0x1d
>> udv_fault() at netbsd:udv_fault+0x151
>> uvm_fault_internal() at netbsd:uvm_fault_internal+0x6d4
>> trap() at netbsd:trap+0x3f0
>> --- trap (number 6) ---
>> 1568033cf:
>> ====================
>>
>> Here is dmesg.
>>     http://netbsd.org/~knakahara/20171122-acpidump-panic-dmesg
>>
>> msaitoh@n.o met the same panic on other machine.
>>
>> Does anyone meet this issue?
>>
>>
>> Thanks,
>>
>> --
>> //////////////////////////////////////////////////////////////////////
>> Internet Initiative Japan Inc.
>>
>> Device Engineering Section,
>> IoT Platform Development Department,
>> Network Division,
>> Technology Unit
>>
>> Kengo NAKAHARA <k-nakah...@iij.ad.jp>
>>
>

Reply via email to