| Summary: | head -r333594 and -r358510: dump from ddb unsuccessful on a powerpc64 PowerMac G5. . . | ||
|---|---|---|---|
| Product: | Base System | Reporter: | Mark Millard <marklmi26-fbsd> |
| Component: | kern | Assignee: | freebsd-ppc (Nobody) <ppc> |
| Status: | New --- | ||
| Severity: | Affects Only Me | ||
| Priority: | --- | ||
| Version: | CURRENT | ||
| Hardware: | powerpc | ||
| OS: | Any | ||
(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. 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
(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. 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. |
[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.