Bug 214598 - head -r333594 and -r358510: dump from ddb unsuccessful on a powerpc64 PowerMac G5. . .
Summary: head -r333594 and -r358510: dump from ddb unsuccessful on a powerpc64 PowerMa...
Status: New
Alias: None
Product: Base System
Classification: Unclassified
Component: kern (show other bugs)
Version: CURRENT
Hardware: powerpc Any
: --- Affects Only Me
Assignee: freebsd-ppc mailing list
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2016-11-17 07:25 UTC by Mark Millard
Modified: 2020-03-10 06:27 UTC (History)
0 users

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Mark Millard 2016-11-17 07:25:58 UTC
[This was on a PowerMac11,3 (PowerMac G5 "Quad Core" --dual socket-each dual core actually).]

head -r308247: As close to a successful dump from ddb as I've ever had on a powerpc64 PowerMac G5. . . but it still fails. . .

Transcribed from a camera picture of the screen. . .
(I will drop off various leading zeros and some formatting will be different.)

KDB: enter: manual escape to debugger
[ thread pid 12 tid 10018 ]
Stopped at       .kdb_enter+0x70:       ori r0, r0, 0x0
db> dump
Dumping 9 MB (3 chunks)
  chunk 0: 10MB (2510 pages) ... ok
  chunk 1: 1MB (24 pages) ... ok
  chunk 2: 1MB (2 pages)panic: vm_fault: fault on nofault entry, addr: c000000000022000
cpuid = 1
KDB: stack backtrace:
0xf93cd0: at .kdb_backtrace+0x6c
0xf93df0: at .vpanic+0x178
0xf93eb0: at .panic+0x34
0xf93f30: at .vm_fault_hold+0x1ac
0xf94120: at .vm_fault+0x98
0xf941c0: at .trap_pfault+0xe8
0xf94240: at .trap+0x1e44
0xf944b0: at .powerpc_interrupt+0x1e0
0xf94550: at kernel DSI read trap 0 0xc000000000022ff8
          by .memcpy+0x144:
          ssr1=0x9000000000001032
          r1  =  0xf94800
          cr  =0x40000424
          xer =0x20000000
          ctr =     0x200
          r2  = 0x10de000
          sr  =0x40000000
0xf94800: at .moea64_kextract+0x124
0xf94840: at tmpstk+0x297c
0xf948c0: at ._bus_dmamap_sync+0x124
0xf94960: at .ata_dmaload+0x1e8
0xf94a00: at .ata_begin_transaction+0x240
0xf94aa0: at .ataaction+0x4e0
0xf94b50: at .xpt_run_devq+0x934
0xf94c40: at .xpt_action_default+0x3a8
0xf94cf0: at .ata_action+0x3c8
0xf94d80: at .xpt_actino+0x44
0xf94e00: at .xpt_polled_action+0x60c
0xf94ec0: at .adadump+0x33c
0xf954e0: at .dump_write+0x88
0xf954e0: at .dump_sys_cb_dumpdata+0x124
0xf955c0: at .dumpsys_foreach_chunk+0x68
0xf95660: at .dumpsys_generic+0x26c
0xf95770: at .doadump+0xbc
0xf95800: at .db_dump+0x44
0xf95880: at .db_command+0x3f4

(I omit the rest going back to blocked_loop+0x38.)



Historical note:

I probably last tried this under some 10.x vintage and did just reported that the DMA request size was too large and stopped.
Comment 1 Mark Millard 2016-11-23 01:34:59 UTC
(In reply to Mark Millard from comment #0)

FYI: I eventually tried causing a dump on a TARGET_ARCH=powerpc build used on a "Quad Core" PowerMac G5. It worked.

So the "fault on nofault entry" problem seems to be specific to TARGET_ARCH=powerpc64 builds.
Comment 2 Mark Millard 2018-05-19 00:57:52 UTC
A more modern version of head ( -r333594 ) gets the following
backtrace (again hand typed from a screen shot and with
leading zeros frequently omitted and the like):

db> dump
Dumping 11 MB (3 chunks)
  chunk 0: 12MB (2868 pages) ... ok
  chunk 1: 1MB (24 pages) ... ok
  chunk 2: 1MB (2 pages)KDB: reentering
KDB: stack backtrace:
0xe7c930: at kdb_backtrace+0x68
0xe7ca40: at kdb_reenter+0x54
0xe7cab0: at trap+0x8f0
0xe7cbd0: at powerpc_interrupt+0x74
0xe7cc20: kernel DSI read trap @0xe000000000022ff8
          by memcpy+0x148:
          srr1=0x9000000000001032
          r1  =          0xe7ced0
          cr  =        0x40002224
          xer =        0x20000000
          ctr =             0x200
          r2  =         0x11e4000
          sr  =        0x40000000
0xe7ced0: at 0xc00000006ab17fc
0xe7cf00: at bus_dmamap_load_ccb+0xb0
0xe7cf30: at bus_dmamap_load_sync+0xb0
0xe7cf80: at ata_dmaload+0x200
0xe7d010: at ata_begin_transaction+0x250
0xe7d0a0: at ataaction+0x4b8
0xe7d140: at xpt_run_devq+0x334
0xe7d210: at xpt_action_default+0x63c
0xe7d2c0: at ata_action+0x58
0xe7d300: at xpt_action+0x40
0xe7d330: at cam_periph_runccb+0xbc
0xe7d3c0: at adadump+0x27c
0xe7d580: at dump_write+0x110
0xe7d5f0: at _dump_append+0x34
0xe7d630: at dump_append+0x9c
0xe7d670: at dumpsys_cb_dumpdata+0x144
0xe7d750: at dumpsys_foreach_chunk+0x68
0xe7d7a0: at dumpsys_generic+0x2a0
0xe7d880: at doadump+0xc8
0xe7d8c0: at db_dump+0x38
0xe7d930: at db_command+0x13c
0xe7da60: at db_command_loop+0x9c
0xe7dae0: at db_trap+0xfc
0xe7dc50: at kdb_trap+0x1a8
0xe7dd10: at db_trap_glue+0x70
0xe7dd40: at dbtrap+0x134
0x0a3390: at kdb_enter+0x60
0x0a3410: at kdb_break+0x3c
0x0a3440: at scgetc+0x978
0x0a34f0: at sckdbevent+0x1ec
0x0a3580: at kdbmux_intr+0x8c
0x0a35c0: at kdbmux_kdb_intr+0x4c
0x0a35f0: at taskqueue_run_locked+0xb0
0x0a3690: at taskqueue_run+0x9c
0x0a36e0: at taskqueue_swi_giant_run+0x28
0x0a3710: at intr_event_execute_handlers+0x224
0x0a3790: at ithread_loop+0x138
0x0a3860: at fork_exit+0xb0
0x0a38f0: at fork_trampoline+0x18
0x0a3920: at -0x4
Comment 3 Mark Millard 2018-05-19 01:07:10 UTC
(In reply to Mark Millard from comment #2)

Looks like I missed a 0 in:

0xe7ced0: at 0xc00000006ab17fc

it should be:

0xe7ced0: at 0xc000000006ab17fc

I've no clue why this address has no symbol.
Comment 4 Mark Millard 2020-03-10 06:27:51 UTC
I tested head -r358510 on the old PowerMac G5 (2 sockets,
2 cores each) and . . .

debug.minidump=1 mode had dump hang before even reporting
it was doing anything.

debug.minidump=0 reported writing part of chunk 0 before
hanging. It reported chunk 0 being something like 524288
pages but stopped before finishing it. (That size is
very different than the original report.)

In both cases, the hangup was silent, not reporting any
problems (no panics or such).

Both ways no dump was recognized in the swap partition on
reboot.

The drive is an SSD, which it was historically as well.