[discuss] BAD TRAP: type=7 (#nm Device not available) rp=fffffe0019e3d780 addr=0

[discuss] BAD TRAP: type=7 (#nm Device not available) rp=fffffe0019e3d780 addr=0

[Carsten Grzemba via illumos-discuss]

[-- Attachment #1: Type: text/plain, Size: 2785 bytes --]

Recently I see an crash dump with

NOTICE: SAM-QFS: samfs1: Initiated mount filesystem

panic[cpu3]/thread=fffffe0019e3dc20: 
BAD TRAP: type=7 (#nm Device not available) rp=fffffe0019e3d780 addr=0

looking on the stack of the faulted thread

fffffe0019e3d690 unix:die+d3 ()
fffffe0019e3d770 unix:trap+855 ()
fffffe0019e3d780 unix:cmntrap+e9 ()
fffffe0019e3da10 samfs:sam_map_block+6f ()
fffffe0019e3dc00 samfs:sam_block_thread+1574 ()
fffffe0019e3dc10 unix:thread_start+b ()

and the the disassembled function sam_map_block

> sam_map_block::dis
sam_map_block:                  pushq  %rbp
sam_map_block+1:                movl   %ecx,%eax
sam_map_block+3:                shrl   $0xc,%ecx
sam_map_block+6:                andb   $0xef,%ah
sam_map_block+9:                andl   $0x1,%ecx
sam_map_block+0xc:              xorl   $0x1,%ecx
sam_map_block+0xf:              movq   %rsp,%rbp
sam_map_block+0x12:             pushq  %r15
sam_map_block+0x14:             pushq  %r14
sam_map_block+0x16:             movq   %rsi,%r14
sam_map_block+0x19:             pushq  %r13
sam_map_block+0x1b:             movq   %r8,%r13
sam_map_block+0x1e:             pushq  %r12
sam_map_block+0x20:             pushq  %rbx
sam_map_block+0x21:             subq   $0x178,%rsp
sam_map_block+0x28:             movl   %eax,0xfffffffffffffecc(%rbp)
sam_map_block+0x2e:             leaq   (%rsi,%rdx),%rax
sam_map_block+0x32:             movq   0x3e8(%rdi),%r12
sam_map_block+0x39:             movq   %rdx,0xfffffffffffffec0(%rbp)
sam_map_block+0x40:             movq   %r9,0xfffffffffffffea8(%rbp)
sam_map_block+0x47:             movb   %cl,0xfffffffffffffecb(%rbp)
sam_map_block+0x4d:             movq   %rax,0xfffffffffffffe98(%rbp)
sam_map_block+0x54:             movq   %r12,0xfffffffffffffe70(%rbp)
sam_map_block+0x5b:             movq   %rdi,%r12
sam_map_block+0x5e:             nop    
sam_map_block+0x60:             testq  %r13,%r13
sam_map_block+0x63:             je     +0x18    <sam_map_block+0x7d>
sam_map_block+0x65:             xorl   %esi,%esi
sam_map_block+0x67:             movq   $0x0,0x30(%r13)
sam_map_block+0x6f:             pxor   %xmm0,%xmm0

I build this kernel module with GCC14.

I have no clear understanding what "Bad trap: type=7 (#nm Device not available) " means. Looking on the assembler instruction "pxor   %xmm0,%xmm0" seems that here special multimedia registers are used.

Is it possible the show the contents of this registers in mdb?
What does "Bad trap: type=7" means?

------------------------------------------
illumos: illumos-discuss
Permalink: https://illumos.topicbox.com/groups/discuss/Te2d5885af4d3b9f6-M732651bbffbab2e45832feb0
Delivery options: https://illumos.topicbox.com/groups/discuss/subscription

[-- Attachment #2: Type: text/html, Size: 3637 bytes --]

Re: [discuss] BAD TRAP: type=7 (#nm Device not available) rp=fffffe0019e3d780 addr=0

[Andy Fiddaman]

On Tue, 11 Mar 2025, Carsten Grzemba via illumos-discuss wrote:

> Recently I see an crash dump with
>
> NOTICE: SAM-QFS: samfs1: Initiated mount filesystem
>
> panic[cpu3]/thread=fffffe0019e3dc20:
> BAD TRAP: type=7 (#nm Device not available) rp=fffffe0019e3d780 addr=0
>
...
> sam_map_block+0x6f:             pxor   %xmm0,%xmm0
>
> I build this kernel module with GCC14.
>
> I have no clear understanding what "Bad trap: type=7 (#nm Device not available) " means. Looking on the assembler instruction "pxor   %xmm0,%xmm0" seems that here special multimedia registers are used.

nm - No Math(s) Co-processor
(or at least that's what I've always read it as.)
This is a result of trying to use a floating-point or SIMD instruction (which
`pxor` is) when the CR0.TS bit is set. There's a good theory statement on
kernel FPU use in:

https://github.com/illumos/illumos-gate/blob/master/usr/src/uts/intel/os/fpu.c#L124-L126

In general kernel code cannot use FPU/SIMD instructions unless they make
use of kernel_fpu_begin() and kernel_fpu_end() around them. In this case,
I suspect you need to tell the compiler to avoid such instructions.

Regards,

Andy


------------------------------------------
illumos: illumos-discuss
Permalink: https://illumos.topicbox.com/groups/discuss/Te2d5885af4d3b9f6-M1ef829f6547a474f98d1f851
Delivery options: https://illumos.topicbox.com/groups/discuss/subscription

Re: [discuss] BAD TRAP: type=7 (#nm Device not available) rp=fffffe0019e3d780 addr=0

[Toomas Soome via illumos-discuss]

[-- Attachment #1: Type: text/plain, Size: 3477 bytes --]



> On 11. Mar 2025, at 12:08, Carsten Grzemba via illumos-discuss <discuss@lists.illumos.org> wrote:
> 
> Recently I see an crash dump with
> 
> NOTICE: SAM-QFS: samfs1: Initiated mount filesystem
> 
> panic[cpu3]/thread=fffffe0019e3dc20: 
> BAD TRAP: type=7 (#nm Device not available) rp=fffffe0019e3d780 addr=0
> 
> looking on the stack of the faulted thread
> 
> fffffe0019e3d690 unix:die+d3 ()
> fffffe0019e3d770 unix:trap+855 ()
> fffffe0019e3d780 unix:cmntrap+e9 ()
> fffffe0019e3da10 samfs:sam_map_block+6f ()
> fffffe0019e3dc00 samfs:sam_block_thread+1574 ()
> fffffe0019e3dc10 unix:thread_start+b ()
> 
> and the the disassembled function sam_map_block
> 
> > sam_map_block::dis
> sam_map_block:                  pushq  %rbp
> sam_map_block+1:                movl   %ecx,%eax
> sam_map_block+3:                shrl   $0xc,%ecx
> sam_map_block+6:                andb   $0xef,%ah
> sam_map_block+9:                andl   $0x1,%ecx
> sam_map_block+0xc:              xorl   $0x1,%ecx
> sam_map_block+0xf:              movq   %rsp,%rbp
> sam_map_block+0x12:             pushq  %r15
> sam_map_block+0x14:             pushq  %r14
> sam_map_block+0x16:             movq   %rsi,%r14
> sam_map_block+0x19:             pushq  %r13
> sam_map_block+0x1b:             movq   %r8,%r13
> sam_map_block+0x1e:             pushq  %r12
> sam_map_block+0x20:             pushq  %rbx
> sam_map_block+0x21:             subq   $0x178,%rsp
> sam_map_block+0x28:             movl   %eax,0xfffffffffffffecc(%rbp)
> sam_map_block+0x2e:             leaq   (%rsi,%rdx),%rax
> sam_map_block+0x32:             movq   0x3e8(%rdi),%r12
> sam_map_block+0x39:             movq   %rdx,0xfffffffffffffec0(%rbp)
> sam_map_block+0x40:             movq   %r9,0xfffffffffffffea8(%rbp)
> sam_map_block+0x47:             movb   %cl,0xfffffffffffffecb(%rbp)
> sam_map_block+0x4d:             movq   %rax,0xfffffffffffffe98(%rbp)
> sam_map_block+0x54:             movq   %r12,0xfffffffffffffe70(%rbp)
> sam_map_block+0x5b:             movq   %rdi,%r12
> sam_map_block+0x5e:             nop    
> sam_map_block+0x60:             testq  %r13,%r13
> sam_map_block+0x63:             je     +0x18    <sam_map_block+0x7d>
> sam_map_block+0x65:             xorl   %esi,%esi
> sam_map_block+0x67:             movq   $0x0,0x30(%r13)
> sam_map_block+0x6f:             pxor   %xmm0,%xmm0
> 
> I build this kernel module with GCC14.
> 
> I have no clear understanding what "Bad trap: type=7 (#nm Device not available) " means. Looking on the assembler instruction "pxor %xmm0,%xmm0" seems that here special multimedia registers are used.
> 
> Is it possible the show the contents of this registers in mdb?
> What does "Bad trap: type=7" means?
> 

We do build kernel with:

Makefile.uts:CFLAGS_uts         += $(STAND_FLAGS_$(CLASS))

Makefile.master:STAND_FLAGS_64 = $($(MACH64)_STAND_FLAGS)
Makefile.master:amd64_STAND_FLAGS=      -xmodel=kernel $(NO_SIMD)
Makefile.master:NO_SIMD=                -_gcc=-mno-mmx -_gcc=-mno-sse

Which does switch off the use of FP registers. If you actually do need those registers, then you need to use in kernel API to handle the FP context properly.

rgds,
toomas


------------------------------------------
illumos: illumos-discuss
Permalink: https://illumos.topicbox.com/groups/discuss/Te2d5885af4d3b9f6-M8832f9c60aeebd52c0efa001
Delivery options: https://illumos.topicbox.com/groups/discuss/subscription

[-- Attachment #2: Type: text/html, Size: 9218 bytes --]