This is my first discussion. I received my three beagleboard xm
modules and all 3 exhibit a kernel panic upon loading either the user
image or the verification image. Below is the uboot version, angstrom
version, and oops printout of the event. How can I fix this problem?
Thanks.
U-Boot 2010.03-dirty (Aug 20 2010 - 20:50:46)
Booting from ramdisk ...
## Booting kernel from Legacy Image at 80200000 ...
Image Name: Angstrom/2.6.32/beagleboard
Image Type: ARM Linux Kernel Image (uncompressed)
Data Size: 3190504 Bytes = 3 MB
Load Address: 80008000
Entry Point: 80008000
Verifying Checksum ... OK
Loading Kernel Image ... OK
OK
[ 50.772216] Unable to handle kernel NULL pointer dereference at
virtual addre
ss 00000014
[ 50.780364] pgd = c0004000
[ 50.783111] [00000014] *pgd=00000000
[ 50.786712] Internal error: Oops: 5 [#1] PREEMPT
[ 50.791351] last sysfs file:
[ 50.794342] Modules linked in:
[ 50.797424] CPU: 0 Not tainted (2.6.32 #3)
[ 50.801910] PC is at musb_interrupt+0x9f8/0xbb8
[ 50.806457] LR is at musb_interrupt+0x9e4/0xbb8
[ 50.811004] pc : [<c033df94>] lr : [<c033df80>] psr: 60000193
[ 50.811035] sp : df825e10 ip : df825e48 fp : 000000f0
[ 50.822570] r10: 00000000 r9 : 00000099 r8 : 00000009
[ 50.827819] r7 : 00000000 r6 : df81f108 r5 : 00000001 r4 :
00000000
[ 50.834411] r3 : 00000000 r2 : 00000000 r1 : fa0ab000 r0 :
df81f108
[ 50.840972] Flags: nZCv IRQs off FIQs on Mode SVC_32 ISA ARM
Segment ker
nel
[ 50.848419] Control: 10c5387d Table: 80004019 DAC: 00000017
[ 50.854187] Process swapper (pid: 1, stack limit = 0xdf8242f0)
[ 50.860076] Stack: (0xdf825e10 to 0xdf826000)
[ 50.864440] 5e00: df825e58
00000000 00000
001 00000004
[ 50.872680] 5e20: df825e78 df81f108 60000113 df892900 df824000
0000005c 00000
000 00000000
[ 50.880920] 5e40: c0667ac0 c033e1b8 0000000a df892900 c0635148
c00a33a0 00000
001 df892900
[ 50.889160] 5e60: c0635148 0000005c 00000003 00000002 df824000
df825f0d df825
efe c00a5498
[ 50.897399] 5e80: 0000005c 00000000 df825f0d c003b074 c0630fe0
ffffffff fa200
000 c003bb44
[ 50.905639] 5ea0: 00000001 80000013 c0630fac c0630fac 00000001
0000000b df825
f0d c067da23
[ 50.913848] 5ec0: 0000001c 00000031 df825f0d df825efe df825ec0
df825ee8 c006d
254 c006d904
[ 50.922088] 5ee0: 60000013 ffffffff c06290d8 00000036 00000000
80000013 c0628
218 205b0b58
[ 50.930328] 5f00: 30352020 3836372e 5d313433 c0050020 c0628840
c0628a98 c0628
a4c c0050b58
[ 50.938568] 5f20: c0628840 c0628a34 c06282e0 c0050b58 c0629844
0000014c 00000
000 13c9eb00
[ 50.946807] 5f40: 0000001a 3b9aca00 c0628200 c062819c c0628264
c04838b0 c0050
ebc c0010d54
[ 50.955047] 5f60: c056b73e 00000320 00000320 00000040 000003e8
c0040c50 c004d
534 c0629268
[ 50.963256] 5f80: c0050ea4 c0626894 c06268d8 c0010668 00000001
00000000 00000
000 00000000
[ 50.971496] 5fa0: 00000000 c0010748 c002fa10 0800fb70 00000001
c002f9b0 c002f
a10 c003b374
[ 50.979736] 5fc0: 00000000 00000192 c0633484 00000000 00000000
c002f9b0 c002f
a10 00000000
[ 50.987976] 5fe0: 00000000 c0008414 00000000 00000000 00000000
c003c9dc dffff
fff efffffff
[ 50.996215] [<c033df94>] (musb_interrupt+0x9f8/0xbb8) from
[<c033e1b8>] (gene
ric_interrupt+0x64/0x98)
[ 51.005523] [<c033e1b8>] (generic_interrupt+0x64/0x98) from
[<c00a33a0>] (han
dle_IRQ_event+0xac/0x1ec)
[ 51.014892] [<c00a33a0>] (handle_IRQ_event+0xac/0x1ec) from
[<c00a5498>] (han
dle_level_irq+0xbc/0x148)
[ 51.024261] [<c00a5498>] (handle_level_irq+0xbc/0x148) from
[<c003b074>] (asm
_do_IRQ+0x74/0x98)
[ 51.033020] [<c003b074>] (asm_do_IRQ+0x74/0x98) from [<c003bb44>]
(__irq_svc+
0x44/0xa8)
[ 51.041076] Exception stack(0xdf825ea0 to 0xdf825ee8)
[ 51.046173] 5ea0: 00000001 80000013 c0630fac c0630fac 00000001
0000000b df825
f0d c067da23
[ 51.054412] 5ec0: 0000001c 00000031 df825f0d df825efe df825ec0
df825ee8 c006d
254 c006d904
[ 51.062652] 5ee0: 60000013 ffffffff
[ 51.066162] [<c003bb44>] (__irq_svc+0x44/0xa8) from [<c006d904>]
(vprintk+0x3
94/0x428)
[ 51.074157] [<c006d904>] (vprintk+0x394/0x428) from [<c04838b0>]
(printk+0x18
/0x28)
[ 51.081878] [<c04838b0>] (printk+0x18/0x28) from [<c0010d54>]
(omap2_clk_set_
freq+0x370/0x410)
[ 51.090545] [<c0010d54>] (omap2_clk_set_freq+0x370/0x410) from
[<c0010748>] (
omap3_sr_init+0xe0/0x174)
[ 51.099914] [<c0010748>] (omap3_sr_init+0xe0/0x174) from
[<c003b374>] (do_one
_initcall+0x5c/0x1bc)
[ 51.108947] [<c003b374>] (do_one_initcall+0x5c/0x1bc) from
[<c0008414>] (kern
el_init+0xa4/0x128)
[ 51.117797] [<c0008414>] (kernel_init+0xa4/0x128) from [<c003c9dc>]
(kernel_t
hread_exit+0x0/0x8)
[ 51.126647] Code: e3530003 13a02000 05963078 05933018 (05d33014)
[ 51.132843] ---[ end trace d072b4fd05b77e06 ]---
[ 51.137481] Kernel panic - not syncing: Fatal exception in
interrupt
Are you powering the board via the USB OTG port? If you are there are two issues.
- There is not enough power to power the board form the OTG port because of the onboard USB hub. You will need to use a double ended USB connector or a DC power supply.
- If you have the OTG cable plugged in you will get a kernel panic no matter how you have the board power. There is an issue with the validation image supporting the OTG port. It will result in a kernel panic.
Gerald
Are you powering the board via the USB OTG port? If you are there are two
issues.
1) There is not enough power to power the board form the OTG port because of
the onboard USB hub. You will need to use a double ended USB connector or a
DC power supply.
2) If you have the OTG cable plugged in you will get a kernel panic no
matter how you have the board power. There is an issue with the validation
image supporting the OTG port. It will result in a kernel panic.
It is possible to hack around that issue by compiling in a kernel
module for the OTG port. I'm not sure where this issue got introduced
into the Linux kernel, but it appears there is no proper default
interrupt handler. Koen has implemented that hack at
http://www.angstrom-distribution.org/demo/beagleboard/ where he's
supplied kernels that compile in the gadget Ethernet (g_ether) kernel
module.
That also enabled cpuidle, which should give people a change to power it over usb.
regards,
Koen
It is introduced by the patch that makes OTG roleswitching work without reloading modules. Ajay created it specifically for the beagleboard after much badgering from Roger and me. The mainline usb maintainers refuse to make role switching work without reloading modules, so that's why we carry this patch. The sad side-effect is that you can't have a cable plugged in at boot if you want modular gadget drivers 
regards,
Koen
Are you powering the board via the USB OTG port? If you are there are two
issues.
1) There is not enough power to power the board form the OTG port because of
the onboard USB hub. You will need to use a double ended USB connector or a
DC power supply.
2) If you have the OTG cable plugged in you will get a kernel panic no
matter how you have the board power. There is an issue with the validation
image supporting the OTG port. It will result in a kernel panic.
It is possible to hack around that issue by compiling in a kernel
module for the OTG port. I'm not sure where this issue got introduced
into the Linux kernel, but it appears there is no proper default
interrupt handler. Koen has implemented that hack at
http://www.angstrom-distribution.org/demo/beagleboard/ where he's
supplied kernels that compile in the gadget Ethernet (g_ether) kernel
module.
That also enabled cpuidle, which should give people a change to power it over usb.
modules is out-of-date relative to the kernel. Can you build -r87 of modules?
Also, conf/machine/include/omap3.inc shows that we are now up to r88,
which I think might be necessary to support the xM.
Koen Kooi wrote:
It is possible to hack around that issue by compiling in a kernel module for the OTG port. I'm not sure where this
issue got introduced into the Linux kernel, but it appears there is no proper default interrupt handler.
It is introduced by the patch that makes OTG roleswitching work without reloading modules. Ajay created it
specifically for the beagleboard after much badgering from Roger and me. The mainline usb maintainers refuse to make
role switching work without reloading modules, so that's why we carry this patch. The sad side-effect is that you
can't have a cable plugged in at boot if you want modular gadget drivers 
pardon my ignorance, but this kernel panic due to not having a driver loaded cannot be fixed somehow?
Sure it can, just noone wants to
Yes...
Thanks Gerald. That fixed the problem. The kernel came up properly
once I powered it separately and with the miniUSB port disconnected.
Jerad
Great! Glad you got it working!
Gerald
I was just about to post the same sort of problems when I saw this
thread - I got hangs when initializing the USB hub if something was
plugged in and then again when the Ethernet port is initialized.
Changing to an external 5v supply fixed the problem for me too.
Perhaps it's a good idea to alway recommend at least starting by
powering the board with an external power supply? Section 5.16 of the
xM Reference Manual is sort of written the other way round.
BTW congrats on producing a nice board - it's got pretty much
everything needed to get up to speed quickly. I am looking forward to
putting it to good use!
Richard.
I will look at adding that in the next version. It is already mentioned in section 5.5, but I will look at putting it in several different places.
Gerald
i was just going to suggest the very same thing -- there's simply
too much traffic generated by people trying to power their boards via
USB. can we just agree that a *huge* amount of pain can be avoided
by just buying a 5V power supply?
rday
But, if you choose to read the System Reference Manual, you can see that using two USB ports will allow you to power the board via USB, just as you do with some USB based external HDD. Let’s not just throw that feature out because the software can’t handle it.
Gerald
i wasn't suggesting *not* ever doing something like that -- only
that that's one less issue you have to worry about during validation.
rday
Yes, that may be the case, but I want the OTG working. It makes for addtional test time in production. I prefer to have it working.
Gerald
Hi,
I got the same kernel panic with the latest Angstrom image and BB
revC3 when the OTG was plugged in to my PC during boot. To be exact I
get this panic any time (even when linux is booted) when I connect the
OTG port to a PC, _unless_ a gadget driver is loaded.
So I:
- unplug the OTG during boot
- after boot: modprobe g_ether
- replug OTG
After this it works like charm (untill the next reboot 
Regards,
Gyorgy