4.14: bad mode in data abort handler detected

[maxnet]

On Pi 3+, 4.14 branch, I occasionally get a kernel panic on boot.
With a "bad mode in data abort handler detected" message, and PC at dwc_otg_fiq_fsm

Probably some rare timing specific problem, as:

• it only happens occasionally.
• can no longer reproduce it when I attach a serial console cable and set enable_uart=1
• nor when having "quiet" in cmdline.txt

(Images are a bit blurry as it's moving text, and cannot scroll back after kernel panic.)

[P33M]

Related: #2382

Are you using the latest 4.14?

[maxnet]

Are you using the latest 4.14?

I am not using the very latest, but it was latest when I build the kernel last Wednesday, so recent enough to have your patch.
(And yes, it's a custom kernel. But it's just bcm2709_defconfig + aufs patch, not anything that could remotely affect your dwc stuff)

[paul-1]

I've seen this in as late as 4.14.26 kernel. (As reported https://www.raspberrypi.org/forums/viewtopic.php?f=29&t=197689&start=25#p1265214) But as soon as I try to reproduce with pause_on_oops=20 in the command line, it becomes elusive.

It is definitely improved since your patch in #2382, but not eliminated.

[maxnet]

But as soon as I try to reproduce with pause_on_oops=20 in the command line, it becomes elusive.

Not so elusive to me.
Here's with pause_on_oops with today's latest code (4.14.31 / b36f4e9 )

[maxnet]

In the forum thread jdb mentions:

I note that the USB register offset (xx98xxxx) appears nowhere in the stack or in the register dump.

However -at least in my case- r3 does actually point to the virtual address of the USB register offset.

It is 0xb88b0000
And that does happen to be the address ioremap returns here: https://github.com/raspberrypi/linux/blob/rpi-4.14.y/drivers/usb/host/dwc_otg/dwc_otg_driver.c#L735

On a kernel that has dynamic debugging enabled, I verified that by putting dyndbg="file dwc_otg_driver.c +p" in cmdline.txt
It prints out:

[    4.555697] dwc_otg 3f980000.usb: dwc_otg_driver_probe(b4a74000)
[    4.555708] dwc_otg 3f980000.usb: start=0x3f980000 (len 0xffff)
[    4.555748] dwc_otg 3f980000.usb: base=0xb88b0000

I think the problem is that you are not supposed to be accessing memory in your FIQ that has been remapped after other kernel thread have started though, due to the issue described here: https://www.spinics.net/lists/arm-kernel/msg325250.html

[Nilpo]

I'm using berryboot-20180405-pi2-pi3 on a new Raspberry Pi 3 B+ and it will not boot at all. Tried several known working good cards. It won't even intialize video which means that a bootable OS isn't found. (Just black screen). An older version of BerryBoot booted to the rainbow screen but no further. I tried the same working card with the current version and got nowhere.

[maxnet]

It won't even intialize video

If you won't even get rainbow screen that would be a firmware issue, or something with power, partitioning/filesystem or SD card.
In any case not related to the Linux kernel issue described here.

[Nilpo]

The same cards boot fine with Raspbian image. It's specific to the latest BerryBoot release. I'm using the same format utility for both.

[maxnet]

The same cards boot fine with Raspbian image.

Does Raspbian still work if you run rpi-update to update the firmware files to a newer version?

Note that the rainbow screen is drawn by the Raspberry Pi firmware files, not by the Linux kernel, nor by the Berryboot program.

[Nilpo]

I may have spoken too quickly. I'm unable to get the same Raspbian image to boot again. The same problem. The first time it booted must have been a fluke.

Note that the rainbow screen is drawn by the Raspberry Pi firmware files, not by the Linux kernel, nor by the Berryboot program.

Correct, but unless I'm misunderstanding, the firmware will not draw the rainbow screen unless it first recognizes a bootable SD card. (That's why it's one of the official troubleshooting steps.)

Specifically it indicates "The Raspberry Pi cannot find a valid image on the SD card." This means bad card, bad image, bad formatting, or in a worst-case a bad Pi/SD card reader.

I'm strongly leaning toward a hardware/firmware issue with the Pi itself at this point.

[Nilpo]

Walking away and coming back again allowed the Pi to boot. Heat? There are so many variables with inconsistent boots, but it does appear to be a problem in the Pi itself now.

[maxnet]

Correct, but unless I'm misunderstanding, the firmware will not draw the rainbow screen unless it first
recognizes a bootable SD card.

Only to the extend that it must be able to find and boot the bootcode.bin and start.elf firmware files located on the SD card.
Regardless what shape the kernel and berryboot.img files are in, it should display rainbow.

You can upgrade/downgrade to different firmware versions with rpi-update
If you find a specific versions which causes problems, report it to https://github.com/raspberrypi/firmware
In any case this thread is about a Linux kernel problem, and that does not apply if you do not get to rainbow.

[derykmarl]

I'm getting this too, but only if running an initramfs (which I was doing for overlay support, so that the Pi can be switched off at the wall without risking a corrupt filesystem). When that's disabled, it boots consistently.

I just re-imaged and set it up again with the same result... also the same after manually running rpi-update.

[derykmarl]

So far (after about 16 boots, and it was a lot less stable before) adding the kernel parameters dwc_otg.fiq_enable=0 and dwc_otg.fiq_fsm_enable=0 has worked around the bug, as per this post https://www.raspberrypi.org/forums/viewtopic.php?p=1273852#p1273852