• State Not Answered
  • Locked Locked
  • Replies 2 replies
  • Subscribers 120 subscribers
  • Views 8750 views
  • Users 0 members are here
Options
Related
How was your experience today?
This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

Unhandled prefetch abort error when loading kernel module

Andrei Parvu

Hello,

I've been trying to use DS-5 to debug a Linux kernel module on a Pandaboard. The connection to the target goes smoothly, both vmlinux and modex.ko symbol files being loaded.

Unfortunately, when I enter the command "insmod modex.ko" I get the following error:

[  863.838684] Unhandled prefetch abort: breakpoint debug exception (0x002) at 0xb6f0f930

[  863.850189] Internal error: : 2 [#2] SMP ARM

[  863.850189] Modules linked in: arc4 ipv6 wl12xx wlcore mac80211 snd_soc_omap_abe_twl6040 snd_soc_omap_mcpdm snd_soc_omap_mcbsp snd_soc_twl6040 snd_soc_omap snd_soc_core smsc95xx usbnet snd_compress snd_pcm_dmaengine snd_pcm_oss cfg80211 snd_mixer_oss snd_pcm omap2430 musb_hdrc snd_timer ohci_omap3 ehci_omap ehci_hcd udc_core ohci_hcd wlcore_sdio usbcore omapfb cfbfillrect pwm_twl_led cfbimgblt connector_hdmi cfbcopyarea encoder_tpd12s015 encoder_tfp410 pwm_twl connector_dvi rtc_twl snd ti_soc_thermal phy_omap_usb2 omapdss cpufreq_dt usb_common omap4_keypad thermal_sys matrix_keymap omap_wdt emif soundcore leds_gpio led_class hwmon

[  863.913970] CPU: 1 PID: 857 Comm: insmod Tainted: G      D         4.2.0-rc1-g0d518b8 #1

[  863.913970] Hardware name: Generic OMAP4 (Flattened Device Tree)

[  863.922485] task: ed190140 ti: ee7d2000 task.ti: ee7d2000

[  863.922485] PC is at SyS_init_module+0x0/0x134

[  863.939208] LR is at ret_fast_syscall+0x0/0x54

[  863.939208] pc : [<c00c4dd4>]    lr : [<c000f680>]    psr: 80000113

[  863.939208] sp : ee7d3fa8  ip : 10c5387d  fp : 00000000

[  863.939208] r10: 00000000  r9 : ee7d2000  r8 : c000f864

[  863.939208] r7 : 00000080  r6 : bee0b968  r5 : 00001698  r4 : 00000002

[  863.961456] r3 : b6f6a250  r2 : 00013008  r1 : 00001698  r0 : 00013018

[  863.961456] Flags: Nzcv  IRQs on  FIQs on  Mode SVC_32  ISA ARM  Segment user

[  863.982696] Control: 10c5387d  Table: ad35c04a  DAC: 00000015

[  863.982696] Process insmod (pid: 857, stack limit = 0xee7d2218)

[  863.990570] Stack: (0xee7d3fa8 to 0xee7d4000)

[  863.998413] 3fa0:                   00000002 00001698 00013018 00001698 00013008 b6f6a250

[  863.998413] 3fc0: 00000002 00001698 bee0b968 00000080 00000003 00004000 b6f98000 00000000

[  864.016784] 3fe0: 00011f80 bee0b6d8 00008c01 b6f1aae0 00000110 00013018 af7fd821 af7fdc21

[  864.016784] Code: e58d3018 ebfef1c9 e59d3018 eaffffc1 (e120be70)

[  864.031951] ---[ end trace f4200d9b4f49b679 ]---

Can anyone help me understand why this is happening and how could I fix it?

Thank you,

Andrei

Parents
  • 0

    "breakpoint debug exception" is your biggest clue here -- we assume you're following the module example and did "break -p modex_init" in your debug session, so the real question is.. how did a DS-5 breakpoint get handled by the Linux kernel?

    If you're loading the module without DS-5 attached, then how did the breakpoint get set in the first place? Have you modified the modex.c code at all or just built it verbatim?

Reply
  • 0

    "breakpoint debug exception" is your biggest clue here -- we assume you're following the module example and did "break -p modex_init" in your debug session, so the real question is.. how did a DS-5 breakpoint get handled by the Linux kernel?

    If you're loading the module without DS-5 attached, then how did the breakpoint get set in the first place? Have you modified the modex.c code at all or just built it verbatim?

Children
No data