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 http://beagleboard.org/latest-images
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..
Regards,
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:
First:
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 https://github.com/RobertCNelson/dtb-rebuilder.git
cd dtb-rebuilder/
open:
./src/arm/am335x-boneblack.dts
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..
build/install
make
sudo make install
reboot:
can1 + usart2 + usart 4 should be active..
Regards,
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" */
Regards,
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. 
)
Regards,
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...
http://elinux.org/BeagleBone_Serial_CAN_RS485_RS232_Cape
Which is: P9_24, P9_26, which is can1 in v3.14.x kernel land.
Regards,
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
noticed...
Regards,
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 . . .
Robert,
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?
Thanks,
John