soft lockup

very weird my beagle was idling doing nothing and bang

kernel:[262260.025009] BUG: soft lockup - CPU#0 stuck for 21s! [mmcqd/0:73]

cat /proc/version
Linux version 3.8.13-bone70 (root@a5-imx6q-wandboard-2gb) (gcc version
4.6.3 (Debian 4.6.3-14) ) #1 SMP Fri Jan 23 02:15:42 UTC 2015

latest version from

any ideas ?

It's the mmc card with v3.8.x..

If you don't need capemgr, upgrade to 3.14.x

sudo apt-get update ; sudo apt-get install linux-image-3.14.39-ti-r61
; sudo reboot

if you need capemgr... try a different brand microSD card..


i am using the cancape from logic supply i am unsure if it uses the capemgr
it is just plug and play

You can use v3.14.x with that, but you'll have to use dtb-rebuilder to
build the *.dtb:

sudo apt-get update ; sudo apt-get install linux-image-3.14.39-ti-r61
; sudo reboot

Then on your bbb:

git clone -b 3.14-ti
cd dtb-rebuilder/


For Can1, uncomment:

/* #include "am335x-bone-can1.dtsi" */ -> #include "am335x-bone-can1.dtsi"

usart 2:

/* #include "am335x-bone-ttyO2.dtsi" */ -> #include "am335x-bone-ttyO2.dtsi"

usart 4:

/* #include "am335x-bone-ttyO4.dtsi" */ -> #include "am335x-bone-ttyO4.dtsi"

Sorry, i don't have the cts/rts pins enabled yet..


sudo make install


can1 + usart2 + usart 4 should be active..


hmmm after just enabling can1 and make install i got this

"#include" is a pre-processor command.. don't drop the #

Just remove the /* */...

see this git diff:

diff --git a/src/arm/am335x-boneblack.dts b/src/arm/am335x-boneblack.dts
index 7dd5b5b..8a47b56 100644
--- a/src/arm/am335x-boneblack.dts
+++ b/src/arm/am335x-boneblack.dts
@@ -56,7 +56,7 @@

/* can1: P9_24, P9_26 */
#include "am335x-can1.dtsi"
-/* #include "am335x-bone-can1.dtsi" */
+#include "am335x-bone-can1.dtsi"

/* i2c2: cape eeprom */
/* P9.19 P9.20 */
@@ -88,10 +88,10 @@
/* #include "am335x-bone-ttyO1.dtsi" */
/* uart2: P9.21, P9.22 */
#include "am335x-ttyO2.dtsi"
-/* #include "am335x-bone-ttyO2.dtsi" */
+#include "am335x-bone-ttyO2.dtsi"
/* uart4: P9.11, P9.13 */
#include "am335x-ttyO4.dtsi"
-/* #include "am335x-bone-ttyO4.dtsi" */
+#include "am335x-bone-ttyO4.dtsi"
/* uart5: P8.37, P8.38 boneblack: hdmi has to be disabled for ttyO5 */
#include "am335x-ttyO5.dtsi"
/* #include "am335x-bone-ttyO5.dtsi" */


oh my bad been too many years since i programmed C

did my first c programming on a univac 1100 at a place i worked at

i am a hardware person

ok all installed correctly but what used to work now does not

ip link set can0 up type can bitrate 250000

then i was able to use candump

candump can0

now i get

root@xanbustester:~# ip link set can0 up type can bitrate 250000
RTNETLINK answers: Device or resource busy

as they say beware of programmers carrying screwdrivers
for me beware of hardware engineers with a laptop ssh session open.

use "can1".... can0 is there, but it's pinmux isn't setup. (and with
the i2c2 enabled, can0 isn't going to work either. :wink: )


must be a difference with logical addressing on new kernel as on old
kernel the last command worked and i got a dump

as per logic supplys manual

" Note that the pins on the serial cape are marked as CAN1, but we used
CAN0 here. The AM335x microprocessor’s
CAN modules are numbered starting at 1, and the Linux kernel numbers the
CAN interfaces starting at 0. The serial
cape is labeled to match the AM335x numbering scheme to be consistent
with the datasheet and schematic symbols"

Yeah, the gpio #'s get funny after v3.8.x...

Which is: P9_24, P9_26, which is can1 in v3.14.x kernel land. :wink:


as usual you are a Linux god among men

thank you kind sir

Odd, I’ve been using the same sdcard for the last couple years running various images and have never seen that. BTW I have access to the same BBB there as wulf, and was greeted with that message on my puTTY session this morning.

The changing of interface is also mildly annoying . . .

Like the serial port re-change (back to /dev/ttySx)... But if you
blinked between say (2.6.33? -> 3.19.x (3.14.x-ti)) you wouldn't have


It’s more of a pet peeve sort of thing with me. Just like eth1 instead of eth0 would bug me . . . I’m sure I can deal with it though.

On the more important side of things trying to reverse a high level protocol ( modbus + some odd byte encoding ) is turning out to be far more annoying . . .

I am seeing similar soft lockup issues running kernel 3.12.50 (on our AM335x platform). In general, what was the soft lockup issue with respect to the mmc-related code? Was the issue fixed earlier than 3.14.x, perhaps?