Thread: 5.6 crashes
View Single Post
  #8   (View Single Post)  
Old 25th December 2014
hulten hulten is offline
Port Guard
 
Join Date: Dec 2014
Posts: 25
Default

The crashes happen again. I was probably just lucky that I could use my system several hours instead of mostly a minute (which is usually the case).

First some standard bug report information:
Code:
...
DHCPACK from 192.168.0.11 (00:a):24:f0:fb:11)
kernel: type 692267296 trap, code=1
Stopped at      0x6f43204140444056:panic: attempt to execute user adé   s 0xb in
 sup _  É(  %       ä    >           _ ...
        panic: attempt to execute user address 0xb in supervisor mode       Pß
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 INCUDING THAT INFORMATION!
ddb{0}> trace
Debugger() at Debugger+0x9
panic() at panic+0xfe
trap() at trap+0x85d
--- trap (number 6) ---
end of kernel
end trace frame: 0x176e176f17691774, count: -3
0xb:
ddb{0}> machine ddbcpu 1
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 INCUDING THAT INFORMATION!
ddb{1}> 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: 0xffff8000212e2f10
end trace frame: 0xffff8000212e2f10, count: -3
cpu_idle_cycle+0x13:
ddb{1}> show panic
attempt to execute user address 0xb in supervisor mode
ddb{1}> ps
   PID   PPID   PGRP    UID  S       FLAGS  WAIT         COMMAND
 16610      1  16610      0  3        0x80  poll         dhclient
 15412  18760  18760     77  3        0x13  biowait      dhclient
 18760      1  18760      0  3        0x8b  pause        sh
  1024      0      0      0  3     0x14200  aiodoned     aiodoned
  5077      0      0      0  3     0x14200  syncer       update
 19163      0      0      0  3     0x14200  cleaner      cleaner
 10500      0      0      0  3     0x14200  reaper       reaper
 14850      0      0      0  3     0x14200  pgdaemon     pagedaemon
  7097      0      0      0  3     0x14200  bored        crypto
 29987      0      0      0  3     0x14200  pftm         pfpurge
    98      0      0      0  3     0x14200  bored        sensors
 27672      0      0      0  3     0x14200  usbtsk       usbtask
 28808      0      0      0  3     0x14200  usbatsk      usbatsk
 31061      0      0      0  3  0x40014200  acpi0        acpi0
*16000      0      0      0  7  0x40014200               idle1
 15840      0      0      0  3     0x14200  bored        systqmp
 28757      0      0      0  3     0x14200  bored        systq
 19413      0      0      0  3     0x14200  bored        syswq
 11589      0      0      0  3     0x14200               idle0
     1      0      0      0  3     0x14200  wait         init
     0      0      0      0  3     0x14200  scheduler    swapper
ddb {1}>
Now, for the core dump, I tried this:
Code:
...
DHCPACK from 192.168.0.11 (00:a):24:f0:fb:11)
kernel: type 692267296 trap, code=1
Stopped at      0x6f43204140444056:     kernel: protection fault trap, code=0
Stopped at      db_read_bytes+0x22:     movzbl  0(%rdi,%rcx,1)c%eax
ddb{0}> boot dump
°(   (  πë  s...ä       `\    (     itok: want -1 have 2
splassert: aä   twaitok: ~  ...
        t: assertwaitok: want -1 have 2
...
kernel: type 269 trap, code=0
Faulted in DDB; continuing...
ddb{0}> boot sync
Faulted in DDB ...
If I understand crash(8) correctly, it should save files in /var/crash/ (which it didn't) if "boot dump" were to be executed correctly.

I have local access to this machine now.

The machine ran/runs without notable problems with several versions of Debian GNU/Linux.

Last edited by hulten; 25th December 2014 at 10:13 PM. Reason: quick additions
Reply With Quote