Crash at init time of Cobalt 8.20698 - cobalt

The latest version of Cobalt(8.20698) will crash at init time on arm linux platform, the backtrace is as follows, but the old version doesn't has this issue, could anyone help to have a look?
[00000000] *pgd=0dce6831, *pte=00000000, *ppte=00000000
CPU: 0 PID: 4268 Comm: cobalt_qa Tainted: P O 3.10.79 #2
task: cf33b400 ti: d24bc000 task.ti: d24bc000
PC is at 0xb5d12180
LR is at 0x161610
pc : [<b5d12180>] lr : [<00161610>] psr: 600f0010
sp : bed2fc20 ip : b5d12180 fp : 00000000
r10: bed30088 r9 : bed2ff78 r8 : bed2fe84
r7 : 00000002 r6 : 00000000 r5 : 00000000 r4 : 01027e68
r3 : 00000043 r2 : 00000049 r1 : 0000002e r0 : 00000000
Flags: nZCv IRQs on FIQs on Mode USER_32 ISA ARM Segment user
Control: 10c5387d Table: 124d406a DAC: 00000015
CPU: 0 PID: 4268 Comm: cobalt_qa Tainted: P O 3.10.79 #2
[<c0012c20>] (unwind_backtrace+0x0/0xdc) from [<c0010ef8>] (show_stack+0x10/0x14)
[<c0010ef8>] (show_stack+0x10/0x14) from [<c0014204>] (__do_user_fault+0x13c/0x1ac)
[<c0014204>] (__do_user_fault+0x13c/0x1ac) from [<c001449c>] (do_page_fault+0x228/0x268)
[<c001449c>] (do_page_fault+0x228/0x268) from [<c0008328>] (do_DataAbort+0x34/0x120)
[<c0008328>] (do_DataAbort+0x34/0x120) from [<c000dab4>] (__dabt_usr+0x34/0x40)
Exception stack(0xd24bdfb0 to 0xd24bdff8)
dfa0: 00000000 0000002e 00000049 00000043
dfc0: 01027e68 00000000 00000000 00000002 bed2fe84 bed2ff78 bed30088 00000000
dfe0: b5d12180 bed2fc20 00161610 b5d12180 600f0010 ffffffff
Caught signal: SIGSEGV (11)
<unknown> [0xb5d12180]
uprv_getDefaultLocaleID_56 [0x161610]
icu_56::locale_set_default_internal() [0x15a114]
icu_56::Locale::getDefault() [0x159ca0]
locale_get_default_56 [0x159cb0]
EzTimeValueExplode [0xb4d10]
EzTimeTExplode [0xb5048]
EzTimeTExplodeLocal [0xb5838]
logging::LogMessage::Init() [0x7b7cc]
logging::LogMessage::LogMessage() [0x7bcf4]
base::UserLog::IsRegistrationSupported() [0x6b108]
cobalt::browser::Application::RegisterUserLogs() [0x2c608]
cobalt::browser::Application::Application() [0x2d998]
cobalt::browser::CreateApplication() [0x2b278]
SbEventHandle [0x2b0c0]
starboard::shared::starboard::Application::DispatchStart() [0xbadec]
starboard::shared::starboard::Application::Run() [0xbb4e0]
main [0x21c24]
<unknown> [0xb5cb2278]

After tracing the code of Cobalt, the cobalt need to get the posix_id by SbSystemGetLocaledId() in system_get_locale_id.cc, but the system didn't set the clang environment variable yet, and it get null which made the Crash, after setting the LANG environment variable(export LANG="en_US.UTF-8"), it works.
Add CLANG environment variable

Related

Raspberry PI 4 hardware registers access

I'm working on an embedded Linux training with Raspberry PI 4B and in order to create I2C bus driver I need to access hardware registers. The problem is when I try to read any of them I get "Unhandled fault: unknown 3 (0x203) at 0xf08c5000".
Here is the code I'm using to read register:
void i2cHandler_init(void)
{
const u32 rpiPeriphBase = 0xfe000000;
const u32 rpiGpioOffset = 0x200000;
const void *rpiGpioAddress = rpiPeriphBase + rpiGpioOffset;
__iomem u32 *ioMemory;
ioMemory = ioremap(rpiGpioAddress, 0x40 * 8);
pr_info("%s: rpiGpioAddress = 0x%x\r\n", __func__, rpiGpioAddress);
pr_info("%s: ioMemory = 0x%x\r\n", __func__, ioMemory);
pr_info("%s: Register value = 0x%x\r\n", __func__, readl(ioMemory));
if(ioMemory != NULL)
iounmap(ioMemory);
}
Yes, I'm trying to read GPIO GPFSEL0 register here, but changing offset to read I2C Control register changes nothing.
Kernel log output looks like this:
[ 1467.677279] i2cHandler_init: rpiGpioAddress = 0xfe200000
[ 1467.677289] i2cHandler_init: ioMemory = 0xf08c5000
[ 1467.677308] 8<--- cut here ---
[ 1467.677325] Unhandled fault: unknown 3 (0x203) at 0xf08c5000
[ 1467.677340] pgd = f812a8c9
[ 1467.677353] [f08c5000] *pgd=80000000007003, *pmd=2ff5b003, *pte=c00ffffe200713
[ 1467.677385] Internal error: : 203 [#1] SMP ARM
[ 1467.677400] Modules linked in: rpi_driver_I2C(O+) rfcomm cmac algif_hash aes_arm_bs crypto_simd cryptd algif_skcipher af_alg bnep hci_uart btbcm bluetooth ecdh_generic ecc spidev snd_soc_hdmi_codec 8021q garp stp llc brcmfmac brcmutil v3d cfg80211 gpu_sched rfkill raspberrypi_hwmon i2c_brcmstb vc4 spi_bcm2835 cec bcm2835_codec(C) bcm2835_v4l2(C) bcm2835_isp(C) v4l2_mem2mem bcm2835_mmal_vchiq(C) videobuf2_dma_contig videobuf2_vmalloc videobuf2_memops videobuf2_v4l2 videobuf2_common vc_sm_cma(C) drm_kms_helper videodev snd_bcm2835(C) snd_soc_core mc snd_compress snd_pcm_dmaengine snd_pcm rpivid_mem snd_timer snd syscopyarea sysfillrect sysimgblt fb_sys_fops uio_pdrv_genirq uio nvmem_rmem i2c_dev drm drm_panel_orientation_quirks backlight fuse ip_tables x_tables ipv6 [last unloaded: rpi_driver_I2C]
[ 1467.677744] CPU: 0 PID: 2059 Comm: insmod Tainted: G C O 5.15.32-v7l+ #1538
[ 1467.677764] Hardware name: BCM2711
[ 1467.677775] PC is at i2cHandler_init+0xc4/0x178 [rpi_driver_I2C]
[ 1467.677808] LR is at irq_work_queue+0x14/0x2c
[ 1467.677833] pc : [<bf3fe464>] lr : [<c0358054>] psr: 60000013
[ 1467.677846] sp : c3e57d68 ip : 00000000 fp : c3e57d7c
[ 1467.677859] r10: c1205048 r9 : bf400380 r8 : 00000000
[ 1467.677871] r7 : 00000002 r6 : bf3fe5a8 r5 : c1205048 r4 : f08c5000
[ 1467.677884] r3 : 3391a86e r2 : 3391a86e r1 : 00000027 r0 : 00000029
[ 1467.677898] Flags: nZCv IRQs on FIQs on Mode SVC_32 ISA ARM Segment user
[ 1467.677914] Control: 30c5383d Table: 041e1e40 DAC: fffffffd
[ 1467.677926] Register r0 information: non-paged memory
[ 1467.677943] Register r1 information: non-paged memory
[ 1467.677958] Register r2 information: non-paged memory
[ 1467.677973] Register r3 information: non-paged memory
[ 1467.677988] Register r4 information: 0-page vmalloc region starting at 0xf08c5000 allocated at i2cHandler_init+0x80/0x178 [rpi_driver_I2C]
[ 1467.678024] Register r5 information: non-slab/vmalloc memory
[ 1467.678041] Register r6 information: 4-page vmalloc region starting at 0xbf3fe000 allocated at load_module+0xb94/0x2840
[ 1467.678069] Register r7 information: non-paged memory
[ 1467.678084] Register r8 information: NULL pointer
[ 1467.678099] Register r9 information: 4-page vmalloc region starting at 0xbf3fe000 allocated at load_module+0xb94/0x2840
[ 1467.678124] Register r10 information: non-slab/vmalloc memory
[ 1467.678140] Register r11 information: non-slab/vmalloc memory
[ 1467.678155] Register r12 information: NULL pointer
[ 1467.678170] Process insmod (pid: 2059, stack limit = 0x91bbcd6e)
[ 1467.678185] Stack: (0xc3e57d68 to 0xc3e58000)
[ 1467.678199] 7d60: bf400380 c1205048 c3e57d8c c3e57d80 bf3fe5fc bf3fe3ac
[ 1467.678217] 7d80: c3e57d9c c3e57d90 bf3fe5cc bf3fe5e4 c3e57e14 c3e57da0 c02021c4 bf3fe5b4
[ 1467.678234] 7da0: c0439ca0 c0bd5bf4 c1401180 00000000 c3e57dd4 c3e57dc0 c0bd5bf4 c029f244
[ 1467.678251] 7dc0: c1401180 c043ade4 c3e57e14 c3e57dd8 c043ade4 c03f4518 c041c20c c043997c
[ 1467.678269] 7de0: 00000008 c02d056c f097d000 3391a86e 00000002 bf400380 00000002 c3c36d80
[ 1467.678286] 7e00: 00000002 c4ad01c8 c3e57e3c c3e57e18 c02d058c c0202180 c3e57e3c c3e57e28
[ 1467.678303] 7e20: c041c394 c3e57f30 00000002 c4ad0180 c3e57f14 c3e57e40 c02d2dac c02d0544
[ 1467.678320] 7e40: bf40038c 00007fff bf400380 c02cf240 c1205048 c0e3b448 c0e3b460 c0e3b3f0
[ 1467.678337] 7e60: bf0c609a c0e3b4b0 c0c03df0 c3e57f30 bf400594 c4dc6418 bf4003c8 c4ad0188
[ 1467.678354] 7e80: c0e3afcc 00000001 00000000 c0efea84 c0ee67d0 00000000 00000000 00000000
[ 1467.678371] 7ea0: 00000000 00000000 6e72656b 00006c65 00000000 00000000 00000000 00000000
[ 1467.678388] 7ec0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
[ 1467.678405] 7ee0: 00000000 3391a86e c3e57f2c c1205048 00000000 0002de04 00000003 c0200244
[ 1467.678423] 7f00: c3e56000 0000017b c3e57fa4 c3e57f18 c02d33b0 c02d0900 c3e57f2c 7fffffff
[ 1467.678439] 7f20: 00000000 00000002 c3e57f24 f097d000 f097db9e f097e5c0 f097d000 000033ac
[ 1467.678456] 7f40: f097ff9c f097fea8 f097f3a0 00003000 000036e0 00002018 00003aab 00000000
[ 1467.678474] 7f60: 00000000 00000000 00002008 00000017 00000018 00000010 0000000d 0000000a
[ 1467.678491] 7f80: 00000000 3391a86e 00000000 00000002 f9957800 0000017b 00000000 c3e57fa8
[ 1467.678508] 7fa0: c0200040 c02d32f4 00000000 00000002 00000003 0002de04 00000000 b6f68074
[ 1467.678535] 7fc0: 00000000 00000002 f9957800 0000017b 00e9acc8 00000002 bee367d4 00000000
[ 1467.678554] 7fe0: bee36600 bee365f0 00023bc0 b6c459e0 60000010 00000003 00000000 00000000
[ 1467.678568] Backtrace:
[ 1467.678582] [<bf3fe3a0>] (i2cHandler_init [rpi_driver_I2C]) from [<bf3fe5fc>] (mainCycle_init+0x24/0x38 [rpi_driver_I2C])
[ 1467.678632] r5:c1205048 r4:bf400380
[ 1467.678643] [<bf3fe5d8>] (mainCycle_init [rpi_driver_I2C]) from [<bf3fe5cc>] (init_module+0x24/0x30 [rpi_driver_I2C])
[ 1467.678687] [<bf3fe5a8>] (init_module [rpi_driver_I2C]) from [<c02021c4>] (do_one_initcall+0x50/0x244)
[ 1467.678726] [<c0202174>] (do_one_initcall) from [<c02d058c>] (do_init_module+0x54/0x23c)
[ 1467.678760] r8:c4ad01c8 r7:00000002 r6:c3c36d80 r5:00000002 r4:bf400380
[ 1467.678776] [<c02d0538>] (do_init_module) from [<c02d2dac>] (load_module+0x24b8/0x2840)
[ 1467.678807] r6:c4ad0180 r5:00000002 r4:c3e57f30
[ 1467.678824] [<c02d08f4>] (load_module) from [<c02d33b0>] (sys_finit_module+0xc8/0xfc)
[ 1467.678857] r10:0000017b r9:c3e56000 r8:c0200244 r7:00000003 r6:0002de04 r5:00000000
[ 1467.678876] r4:c1205048
[ 1467.678892] [<c02d32e8>] (sys_finit_module) from [<c0200040>] (ret_fast_syscall+0x0/0x1c)
[ 1467.678925] Exception stack(0xc3e57fa8 to 0xc3e57ff0)
[ 1467.678943] 7fa0: 00000000 00000002 00000003 0002de04 00000000 b6f68074
[ 1467.678969] 7fc0: 00000000 00000002 f9957800 0000017b 00e9acc8 00000002 bee367d4 00000000
[ 1467.678986] 7fe0: bee36600 bee365f0 00023bc0 b6c459e0
[ 1467.679007] r7:0000017b r6:f9957800 r5:00000002 r4:00000000
[ 1467.679030] Code: e1a02004 e30f0360 e34b0f3f eb5f37d6 (e5942000)
[ 1467.679052] ---[ end trace b887a2abb18bba14 ]---
Also I'm sure peripherals base address is correct because output of "sudo cat /proc/iomem" looks like this:
00000000-3b3fffff : System RAM
00008000-00ffffff : Kernel code
01200000-013ef203 : Kernel data
40000000-7fffffff : System RAM
fd500000-fd50930f : fd500000.pcie pcie#7d500000
fd580000-fd58ffff : fd580000.ethernet ethernet#7d580000
fd580e14-fd580e1c : unimac-mdio.-19
fe004000-fe00401f : fe004000.txp txp#7e004000
fe007000-fe007aff : fe007000.dma dma#7e007000
fe007b00-fe007eff : fe007b00.dma dma#7e007b00
fe00a000-fe00a023 : fe100000.watchdog watchdog#7e100000
fe00b840-fe00b87b : fe00b840.mailbox mailbox#7e00b840
fe00b880-fe00b8bf : fe00b880.mailbox mailbox#7e00b880
fe100000-fe100113 : fe100000.watchdog watchdog#7e100000
fe101000-fe102fff : fe101000.cprman cprman#7e101000
fe104000-fe104027 : fe104000.rng rng#7e104000
**fe200000-fe2000b3 : fe200000.gpio gpio#7e200000**
fe201000-fe2011ff : serial#7e201000
fe201000-fe2011ff : fe201000.serial serial#7e201000
fe204000-fe2041ff : fe204000.spi spi#7e204000
fe206000-fe2060ff : fe206000.pixelvalve pixelvalve#7e206000
fe207000-fe2070ff : fe207000.pixelvalve pixelvalve#7e207000
fe20a000-fe20a0ff : fe20a000.pixelvalve pixelvalve#7e20a000
fe215000-fe215007 : fe215000.aux aux#7e215000
fe216000-fe2160ff : fe216000.pixelvalve pixelvalve#7e216000
fe300000-fe3000ff : fe300000.mmcnr mmcnr#7e300000
fe340000-fe3400ff : fe340000.mmc mmc#7e340000
fe400000-fe407fff : fe400000.hvs hvs#7e400000
fec00000-fec03fff : fec00000.v3d hub
fec04000-fec07fff : fec00000.v3d core0
fec11000-fec1101f : fe100000.watchdog watchdog#7e100000
fec12000-fec120ff : fec12000.pixelvalve pixelvalve#7ec12000
fef00000-fef0000f : fef00000.clock clock#7ef00000
fef00b00-fef00dff : fef04500.i2c auto-i2c
fef04500-fef045ff : fef04500.i2c bsc
fef05b00-fef05dff : fef09500.i2c auto-i2c
fef09500-fef095ff : fef09500.i2c bsc
600000000-63fffffff : pcie#7d500000
600000000-6000fffff : PCI Bus 0000:01
600000000-600000fff : 0000:01:00.0
600000000-600000fff : xhci-hcd
Raspbeerry PI works under the Raspbian OS 32-bit version. Kernel version is 5.15.32-v7l+.
I tried different base addresses found from different sources:
0x20000000 - ioremap returns 0.
0x3e000000 - ioremap works, no errors, but values there make no sense and writing with this base address leads to no reaction at all.
0x7e000000 - ioremap returns 0.
0x7e000000 without ioremap - error "Unable to handle kernel paging request at virtual address ...".
According to different forums topics and examples my piece of code should just work, but it is not, so I'm out of ideas right now. Does anyone have any thoughts? Is this my error or something else is wrong?
Problem is solved. Nothing seems wrong with my code, 64-bit OS helped.
I didn't actually install 64-bit system, I added "arm_64bit=1" to my /boot/config.txt and updated all packages, because this was just for testing purposes, but this worked.

Debugging u-boot crash

I am facing some data abort in u-boot and not able to find the root cause the issue. Can some tell me the ways how we can trace logs here or how to debug and decode these logs.
In u-boot which file gives the required details-
Below is the crash logs-:
data abort
pc : [<fff3fcb8>] lr : [<1a000018>]
reloc pc : [<B30017cb8>] lr : [<4a0d8018>]
sp : fdf17e5c ip : fff88a6c fp : 00000017
r10: 30061f88 r9 : fdf17ef8 r8 : fdf18a78
r7 : 00000010 r6 : 00000028 r5 : fdf3d138 r4 : 17f18ab8
r3 : fdf18a88 r2 : 00000018 r1 : fdf18aa0 r0 : 00000000
Flags: nzCv IRQs off FIQs off Mode SVC_32
Resetting CPU ...
BR,Abhi
First you need to disassemble the U-Boot file. Which version of objdump you need depends on your host and destination architecture, e.g.
arm-linux-gnueabihf-objdump -sD u-boot > u-boot.txt
Then look for the reloc pc address.

system call hacking in linux for arm

I am trying to write a kernel module that will replace system calls for linux 4.9. All the solutions on the Internet are specific to x86 but I am working on Beaglebone Black that has an arm cortex A8.
This is what I have done so far.
static unsigned long *sys_call_table; // this is a global
The module when insmoded appears as a device in /dev which the user can open and give an ioctl command. In ioctl I use
sys_call_table=(void*)kallsyms_lookup_name("sys_call_table");
which obtains the same address as given in System.map file. But the moment I try to change system call using
*(sys_call_table + __NR_open) = (unsigned long)custom_open;
It gives errors. they are
[ 155.354417] Unable to handle kernel paging request at virtual address c01079f8
[ 155.361959] pgd = de6c0000
[ 155.364780] [c01079f8] *pgd=8000041e(bad)
[ 155.368981] Internal error: Oops: 80d [#1] SMP ARM
[ 155.373980] Modules linked in: intercept(O) [last unloaded: intercept]
[ 155.380821] CPU: 0 PID: 120 Comm: test Tainted: G O 4.9.39 #1
[ 155.387991] Hardware name: Generic AM33XX (Flattened Device Tree)
[ 155.394342] task: de6b2380 task.stack: de664000
[ 155.399089] PC is at my_ioctl+0x64/0x94 [intercept]
[ 155.404180] LR is at my_ioctl+0x58/0x94 [intercept]
[ 155.409269] pc : [<bf0040dc>] lr : [<bf0040d0>] psr: 60000013
[ 155.409269] sp : de665f08 ip : 00000001 fp : bedb0c54
[ 155.421258] r10: 00000000 r9 : 00000003 r8 : 00000003
[ 155.426711] r7 : c02b354c r6 : de6293c0 r5 : de6dc2f0 r4 : bf004580
[ 155.433522] r3 : c01079e4 r2 : bf004000 r1 : ffffe000 r0 : bf004294
[ 155.440334] Flags: nZCv IRQs on FIQs on Mode SVC_32 ISA ARM Segment none
[ 155.447773] Control: 10c5387d Table: 9e6c0019 DAC: 00000051
[ 155.453772] Process test (pid: 120, stack limit = 0xde664218)
[ 155.459771] Stack: (0xde665f08 to 0xde666000)
[ 155.464321] 5f00: bedb0dac c02b2aec 00000000 de6b2670 de665f7c c07ddc98
[ 155.472862] 5f20: 60000013 c0c0512c c0cbfe80 c0192d10 c0c8311c de611000 c029ddd8 c0cbf624
[ 155.481401] 5f40: 2ae98e92 00000024 2b36fb89 00000024 c07de574 df947010 de6293c8 de664000
[ 155.489938] 5f60: 00000000 00000000 de6293c0 de6293c0 00000005 bedb0dac 00000003 00000000
[ 155.498469] 5f80: bedb0c54 c02b354c 00000000 00000000 0001036c 00000036 c01079e4 de664000
[ 155.507005] 5fa0: 00000000 c0107840 00000000 00000000 00000003 00000005 bedb0dac 00010494
[ 155.515541] 5fc0: 00000000 00000000 0001036c 00000036 00000000 00000000 b6f12000 bedb0c54
[ 155.524075] 5fe0: b6e74d90 bedb0c44 000104bc b6e74d9c 60000010 00000003 00000000 00000000
[ 155.532633] [<bf0040dc>] (my_ioctl [intercept]) from [<c02b2aec>] (do_vfs_ioctl+0x90/0xa84)
[ 155.541357] [<c02b2aec>] (do_vfs_ioctl) from [<c02b354c>] (SyS_ioctl+0x6c/0x7c)
[ 155.548992] [<c02b354c>] (SyS_ioctl) from [<c0107840>] (ret_fast_syscall+0x0/0x1c)
[ 155.556898] Code: eb48ce6e e5943004 e59f2028 e59f0028 (e5832014)
[ 155.563276] ---[ end trace 0529de7e48dd6bb4 ]---
[ 155.571707] MyDevice closed
Segmentation fault
Please give me a solution specific to arm.

How can I see the full backtrace using kgdb to debug an ARM Linux module?

I worked my way through all of the free Linux training materials created by Free Electrons. In the last lab, we learn to use kgdb to remotely debug a simple crash in a loadable module. The crash is caused by a null pointer dereference in a memzero function call.
I am using Linux kernel 4.9 and a BeagleBone Black as the target, all according to the recommendations for the labs, and I've had no problems up to this point. My host is Ubuntu xenial and I am using standard packages for the ARM toolchain (Ubuntu/Linaro 5.4.0-6ubuntu1~16.04.4) and gdb (7.11.1-0ubuntu1~16.04) debugger.
gdb is able to read the symbol tables from vmlinux and from the module with the bug in it, which is called drvbroken.ko. The module has a bug in its init function, so it crashes immediately when I insmod it.
gdb output:
(gdb) backtrace
#0 __memzero () at arch/arm/lib/memzero.S:69
#1 0x00000000 in ?? ()
Backtrace stopped: previous frame identical to this frame (corrupt stack?)
(gdb) list 69
64 ldmeqfd sp!, {pc} # 1/2 quick exit
65 /*
66 * No need to correct the count; we're only testing bits from now on
67 */
68 tst r1, #32 # 1
69 stmneia r0!, {r2, r3, ip, lr} # 4
70 stmneia r0!, {r2, r3, ip, lr} # 4
71 tst r1, #16 # 1 16 bytes or more?
72 stmneia r0!, {r2, r3, ip, lr} # 4
73 ldr lr, [sp], #4 # 1
The result is the same whether I build the kernel with CONFIG_ARM_UNWIND (the default) or disable that and use CONFIG_FRAME_POINTER (the old method recommended by the lab notes).
I tried the same procedure in kdb, and here I see a very long backtrace that includes the calling functions. The caller of memzero is cdev_init.
kdb output:
Entering kdb (current=0xde616240, pid 106) on processor 0 Oops: (null)
due to oops # 0xc04c2be0
CPU: 0 PID: 106 Comm: insmod Tainted: G O 4.9.0-dirty #1
Hardware name: Generic AM33XX (Flattened Device Tree)
task: de616240 task.stack: de676000
PC is at __memzero+0x40/0x7c
LR is at 0x0
pc : [<c04c2be0>] lr : [<00000000>] psr: 00000013
sp : de677da4 ip : 00000000 fp : de677dbc
r10: bf000240 r9 : 219a3868 r8 : 00000000
r7 : de65c7c0 r6 : de6420c0 r5 : bf0000b4 r4 : 00000000
r3 : 00000000 r2 : 00000000 r1 : fffffffc r0 : 00000000
Flags: nzcv IRQs on FIQs on Mode SVC_32 ISA ARM Segment none
Control: 10c5387d Table: 9e69c019 DAC: 00000051
CPU: 0 PID: 106 Comm: insmod Tainted: G O 4.9.0-dirty #1
Hardware name: Generic AM33XX (Flattened Device Tree)
Backtrace:
... pruned function calls related to kdb itself ...
[<c08326cc>] (do_page_fault) from [<c010138c>] (do_DataAbort+0x3c/0xbc)
r10:bf000240 r9:de676000 r8:de677d50 r7:00000000 r6:c08326cc r5:00000817
r4:c0d0bb2c
[<c0101350>] (do_DataAbort) from [<c0831d04>] (__dabt_svc+0x64/0xa0)
Exception stack(0xde677d50 to 0xde677d98)
7d40: 00000000 fffffffc 00000000 00000000
7d60: 00000000 bf0000b4 de6420c0 de65c7c0 00000000 219a3868 bf000240 de677dbc
7d80: 00000000 de677da4 00000000 c04c2be0 00000013 ffffffff
r8:00000000 r7:de677d84 r6:ffffffff r5:00000013 r4:c04c2be0
[<c02bf44c>] (cdev_init) from [<bf002048>] (init_module+0x48/0xb4 [drvbroken])
r5:bf002000 r4:bf000480
[<bf002000>] (init_module [drvbroken]) from [<c01018d4>] (do_one_initcall+0x44/0x180)
r5:bf002000 r4:ffffe000
[<c0101890>] (do_one_initcall) from [<c024fa2c>] (do_init_module+0x64/0x1d8)
r8:00000001 r7:de65c7c0 r6:de6420c0 r5:c0dbfa84 r4:bf000240
[<c024f9c8>] (do_init_module) from [<c01e10e8>] (load_module+0x1d6c/0x23d8)
r6:c0d0512c r5:c0dbfa84 r4:c0d4c70f
[<c01df37c>] (load_module) from [<c01e18ac>] (SyS_init_module+0x158/0x17c)
r10:00000051 r9:de676000 r8:e0a95100 r7:00000000 r6:000ac118 r5:00004100
It is pretty easy to figure out where to look for the bug with this information, but alas, it is not possible to get a line number or list the source directly from kdb. This is much easier in gdb, assuming that I can get a full backtrace.

How to read a Windows 10 BSOD mini dump analysis

I'm hoping someone here can help.
I have a new Windows 10 machine (all parts by EVGA).
I get random BSOD, so I've grabbed a mini dump, installed the SDK and looked into it. I just don't understand what it is reporting.
Can someone point me in the direction of a guide, or decode this mini dump.
Note : Each dump looks very similar. e.g. almost the same report from 'irp'
Here is the dump....
Microsoft (R) Windows Debugger Version 10.0.10586.567 X86
Copyright (c) Microsoft Corporation. All rights reserved.
Loading Dump File [C:\Windows\Minidump\033016-4718-01.dmp]
Mini Kernel Dump File: Only registers and stack trace are available
Symbol search path is: srv*
Executable search path is:
Windows 10 Kernel Version 10586 MP (8 procs) Free x64
Product: WinNt, suite: TerminalServer SingleUserTS
Built by: 10586.162.amd64fre.th2_release_sec.160223-1728
Machine Name:
Kernel base = 0xfffff8018d674000 PsLoadedModuleList = 0xfffff8018d952cd0
Debug session time: Wed Mar 30 18:15:33.639 2016 (UTC + 1:00)
System Uptime: 0 days 2:47:26.264
Loading Kernel Symbols
.
Press ctrl-c (cdb, kd, ntsd) or ctrl-break (windbg) to abort symbol loads that take too long.
Run !sym noisy before .reload to track down problems loading symbols.
..............................................................
................................................................
................................
Loading User Symbols
Loading unloaded module list
.............
*
Bugcheck Analysis *
*
Use !analyze -v to get detailed debugging information.
BugCheck 9F, {3, ffffe000935ea880, fffff8018f25a890, ffffe00092718bd0}
Probably caused by : ACPI.sys
Followup: MachineOwner
0: kd> !analyze -v
*
Bugcheck Analysis *
*
DRIVER_POWER_STATE_FAILURE (9f)
A driver has failed to complete a power IRP within a specific time.
Arguments:
Arg1: 0000000000000003, A device object has been blocking an Irp for too long a time
Arg2: ffffe000935ea880, Physical Device Object of the stack
Arg3: fffff8018f25a890, nt!TRIAGE_9F_POWER on Win7 and higher, otherwise the Functional Device Object of the stack
Arg4: ffffe00092718bd0, The blocked IRP
Debugging Details:
DUMP_CLASS: 1
DUMP_QUALIFIER: 400
BUILD_VERSION_STRING: 10586.162.amd64fre.th2_release_sec.160223-1728
SYSTEM_MANUFACTURER: EVGA INTERNATIONAL CO.,LTD
SYSTEM_PRODUCT_NAME: Default string
SYSTEM_SKU: Default string
SYSTEM_VERSION: Default string
BIOS_VENDOR: American Megatrends Inc.
BIOS_VERSION: 1.07
BIOS_DATE: 01/04/2016
BASEBOARD_MANUFACTURER: EVGA INTERNATIONAL CO.,LTD
BASEBOARD_PRODUCT: 111-SS-E172
BASEBOARD_VERSION: 1.0
DUMP_TYPE: 2
DUMP_FILE_ATTRIBUTES: 0x8
Kernel Generated Triage Dump
BUGCHECK_P1: 3
BUGCHECK_P2: ffffe000935ea880
BUGCHECK_P3: fffff8018f25a890
BUGCHECK_P4: ffffe00092718bd0
DRVPOWERSTATE_SUBCODE: 3
IMAGE_NAME: ACPI.sys
DEBUG_FLR_IMAGE_TIMESTAMP: 56cbf9c9
MODULE_NAME: ACPI
FAULTING_MODULE: fffff800d5de0000 ACPI
CPU_COUNT: 8
CPU_MHZ: d50
CPU_VENDOR: GenuineIntel
CPU_FAMILY: 6
CPU_MODEL: 5e
CPU_STEPPING: 3
CPU_MICROCODE: 6,5e,3,0 (F,M,S,R) SIG: 33'00000000 (cache) 33'00000000 (init)
CUSTOMER_CRASH_COUNT: 1
DEFAULT_BUCKET_ID: WIN8_DRIVER_FAULT
BUGCHECK_STR: 0x9F
PROCESS_NAME: System
CURRENT_IRQL: 2
ANALYSIS_SESSION_HOST: Q-PC
ANALYSIS_SESSION_TIME: 03-30-2016 20:04:47.0460
ANALYSIS_VERSION: 10.0.10586.567 x86fre
STACK_TEXT:
fffff8018f25a858 fffff8018d854e42 : 000000000000009f 0000000000000003 ffffe000935ea880 fffff8018f25a890 : nt!KeBugCheckEx
fffff8018f25a860 fffff8018d854d62 : ffffe00096133010 fffff8018f252070 0000000000000000 fffff8018d73e0a6 : nt!PopIrpWatchdogBugcheck+0xde
fffff8018f25a8c0 fffff8018d6e22c6 : ffffe00096133048 fffff8018f25aa10 0000000000000001 0000000000000002 : nt!PopIrpWatchdog+0x32
fffff8018f25a910 fffff8018d7b951a : 0000000000000000 fffff8018d991180 fffff8018da07740 ffffe00096723800 : nt!KiRetireDpcList+0x5f6
fffff8018f25ab60 0000000000000000 : fffff8018f25b000 fffff8018f254000 0000000000000000 0000000000000000 : nt!KiIdleLoop+0x5a
STACK_COMMAND: kb
THREAD_SHA1_HASH_MOD_FUNC: 81a7ba75a791115b4f55c8910c64a260d525502e
THREAD_SHA1_HASH_MOD_FUNC_OFFSET: 936d5c51c0ad2157bf4c85af575dd55cea2c0947
THREAD_SHA1_HASH_MOD: f08ac56120cad14894587db086f77ce277bfae84
FOLLOWUP_NAME: MachineOwner
IMAGE_VERSION: 10.0.10586.122
FAILURE_BUCKET_ID: 0x9F_3_POWER_DOWN_i8042prt_IMAGE_ACPI.sys
BUCKET_ID: 0x9F_3_POWER_DOWN_i8042prt_IMAGE_ACPI.sys
PRIMARY_PROBLEM_CLASS: 0x9F_3_POWER_DOWN_i8042prt_IMAGE_ACPI.sys
TARGET_TIME: 2016-03-30T17:15:33.000Z
OSBUILD: 10586
OSSERVICEPACK: 0
SERVICEPACK_NUMBER: 0
OS_REVISION: 0
SUITE_MASK: 272
PRODUCT_TYPE: 1
OSPLATFORM_TYPE: x64
OSNAME: Windows 10
OSEDITION: Windows 10 WinNt TerminalServer SingleUserTS
OS_LOCALE:
USER_LCID: 0
OSBUILD_TIMESTAMP: 2016-02-24 05:48:00
BUILDDATESTAMP_STR: 160223-1728
BUILDLAB_STR: th2_release_sec
BUILDOSVER_STR: 10.0.10586.162.amd64fre.th2_release_sec.160223-1728
ANALYSIS_SESSION_ELAPSED_TIME: 3d7
ANALYSIS_SOURCE: KM
FAILURE_ID_HASH_STRING: km:0x9f_3_power_down_i8042prt_image_acpi.sys
FAILURE_ID_HASH: {22a3ff34-49ca-8d37-715b-ae023b6cc9fb}
Followup: MachineOwner
0: kd> !irp ffffe00092718bd0
Irp is active with 8 stacks 6 is current (= 0xffffe00092718e08)
No Mdl: No System Buffer: Thread 00000000: Irp stack trace. Pending has been returned
cmd flg cl Device File Completion-Context
[N/A(0), N/A(0)]
0 0 00000000 00000000 00000000-00000000
Args: 00000000 00000000 00000000 00000000
[N/A(0), N/A(0)]
0 0 00000000 00000000 00000000-00000000
Args: 00000000 00000000 00000000 00000000
[N/A(0), N/A(0)]
0 0 00000000 00000000 00000000-00000000
Args: 00000000 00000000 00000000 00000000
[N/A(0), N/A(0)]
0 0 00000000 00000000 00000000-00000000
Args: 00000000 00000000 00000000 00000000
[IRP_MJ_POWER(16), IRP_MN_WAIT_WAKE(0)]
0 0 ffffe000935ea880 00000000 fffff800d6a81ec0-00000000
\Driver\ACPI i8042prt!I8xPowerUpToD0Complete
Args: 00000000 00000000 00000000 00000002
[IRP_MJ_POWER(16), IRP_MN_SET_POWER(2)]
0 e1 ffffe00093f936f0 00000000 fffff800d6ab1060-00000000 Success Error Cancel pending
\Driver\i8042prt kbdclass!KeyboardClassPowerComplete
Args: 00051100 00000001 00000001 00000002
[IRP_MJ_POWER(16), IRP_MN_SET_POWER(2)]
0 e1 ffffe00093dc95f0 00000000 fffff8018d7840b8-ffffe00096133010 Success Error Cancel pending
\Driver\kbdclass nt!PopRequestCompletion
Args: 00051100 00000001 00000001 00000002
[N/A(0), N/A(0)]
0 0 00000000 00000000 00000000-ffffe00096133010
Args: 00000000 00000000 00000000 00000000
I'm also adding a BlueScreen screen shot, incase that helps.
Now adding output from some extra commands after Martins comments...
0: kd> !devstack ffffe000935ea880
!DevObj !DrvObj !DevExt ObjectName
ffffe00093dc95f0 \Driver\kbdclass ffffe00093dc9740 InfoMask field not found for _OBJECT_HEADER at ffffe00093dc95c0
ffffe00093f936f0 \Driver\i8042prt ffffe00093f93840 InfoMask field not found for _OBJECT_HEADER at ffffe00093f936c0
> ffffe000935ea880 \Driver\ACPI ffffe000923fa8d0 Cannot read info offset from nt!ObpInfoMaskToOffset
!DevNode ffffe000935d6af0 :
DeviceInst is "ACPI\PNP0303\0"
ServiceName is "i8042prt"
!process 0 7
**** NT ACTIVE PROCESS DUMP ****
GetPointerFromAddress: unable to read from fffff8018d9f3200
Error in reading nt!_EPROCESS at 0000000000000000
0: kd> !poaction
PopAction: fffff8018d94efe0
State..........: 0 - Idle
Updates........: 0
Action.........: None
Lightest State.: Unspecified
Flags..........: 10000003 QueryApps|UIAllowed
Irp minor......: ??
System State...: Unspecified
Hiber Context..: 0000000000000000
Allocated power irps (PopIrpList - fffff8018d94f4f0)
IRP: ffffe00092718bd0 (set/D0,), PDO: ffffe000935ea880, CURRENT: ffffe00093f936f0
IRP: ffffe000971aa990
Irp worker threads (PopIrpThreadList - fffff8018d94e100)
THREAD: ffffe00091515040 (static)
THREAD: ffffe00091501800 (static)
Error resolving nt!_POP_CURRENT_BROADCAST...
Summary: Error was caused by my 10 year old Razor mouse with Windows 10.
The driver when entering power save state was freaking out and causing the blue screen.
I purchased a new mouse, removed the driver & 2 months in no more BSOD.
I usually use BlueScreenView by Nirsoft. It will get you a list of last BSOD and will show a nice view of the components. "Normally" the first mentioned component could be the reason.
Not sure, if you are looking for a solution on a specific problem or the minidump usage in general.
Some driver got problems with power state change. Make sure, you have the current Drivers installed.

Resources