Hi! I got a bunch of Call-Traces like this: 8312.002483] Call Trace: [ 8312.002502] [<c101eaff>] __might_sleep+0xd7/0xde [ 8312.002517] [<c1053478>] T.396+0x17/0x21 [ 8312.002531] [<c129edf3>] rt_spin_lock+0xb/0x28 [ 8312.002578] [<f966cf92>] b43_interrupt_handler+0x1a/0x34 [b43] [ 8312.002594] [<c106df92>] handle_irq_event_percpu+0x82/0x1bd [ 8312.002609] [<c106e0f9>] handle_irq_event+0x2c/0x43 <snip> and was wondering about the second symbol T.396. greping over the kernel tree only finds it in binaries and the System.map. I have been searching around without a real plan. any hints on that? thx! andi
On Mon, Jul 25, 2011 at 16:47, Andreas Platschek <andi.platschek@gmail.com> wrote:
Hi!
I got a bunch of Call-Traces like this:
8312.002483] Call Trace: [ 8312.002502] [<c101eaff>] __might_sleep+0xd7/0xde [ 8312.002517] [<c1053478>] T.396+0x17/0x21 [ 8312.002531] [<c129edf3>] rt_spin_lock+0xb/0x28 [ 8312.002578] [<f966cf92>] b43_interrupt_handler+0x1a/0x34 [b43] [ 8312.002594] [<c106df92>] handle_irq_event_percpu+0x82/0x1bd [ 8312.002609] [<c106e0f9>] handle_irq_event+0x2c/0x43 <snip>
b43? broadcomm's? -- regards, Mulyadi Santosa Freelance Linux trainer and consultant blog: the-hydra.blogspot.com training: mulyaditraining.blogspot.com
On 07/25/2011 06:51 PM, Mulyadi Santosa wrote:
On Mon, Jul 25, 2011 at 16:47, Andreas Platschek <andi.platschek@gmail.com> wrote:
Hi!
I got a bunch of Call-Traces like this:
8312.002483] Call Trace: [ 8312.002502] [<c101eaff>] __might_sleep+0xd7/0xde [ 8312.002517] [<c1053478>] T.396+0x17/0x21 [ 8312.002531] [<c129edf3>] rt_spin_lock+0xb/0x28 [ 8312.002578] [<f966cf92>] b43_interrupt_handler+0x1a/0x34 [b43] [ 8312.002594] [<c106df92>] handle_irq_event_percpu+0x82/0x1bd [ 8312.002609] [<c106e0f9>] handle_irq_event+0x2c/0x43 <snip>
b43? broadcomm's?
yeah, but that's not the problem, this does not happen in mainline, but only with rt_preempt ... I am just confused about those T.XYZ symbols (here: T.396) thx! andi
On Tue, Jul 26, 2011 at 00:18, andi <andi.platschek@gmail.com> wrote:
yeah, but that's not the problem, this does not happen in mainline, but only with rt_preempt ... I am just confused about those T.XYZ symbols (here: T.396)
hm well, I just thought maybe it's a procedure inside broadcomm's binary object. btw, sometimes rt_preempt introduce situations that might confuse drivers. Maybe that's locking...and that T.396 is the suspect...but I can't explain what that function is... have you tried to run readelf on broadcomm's generated objects? -- regards, Mulyadi Santosa Freelance Linux trainer and consultant blog: the-hydra.blogspot.com training: mulyaditraining.blogspot.com
On 07/25/2011 07:47 PM, Mulyadi Santosa wrote:
On Tue, Jul 26, 2011 at 00:18, andi<andi.platschek@gmail.com> wrote:
yeah, but that's not the problem, this does not happen in mainline, but only with rt_preempt ... I am just confused about those T.XYZ symbols (here: T.396)
hm well, I just thought maybe it's a procedure inside broadcomm's binary object.
doesn't look like that, the brute force way says: andi@ideapad:~/linux-3.0-rt2$ egrep -R T.396 * Binary file arch/x86/boot/compressed/vmlinux.bin matches Binary file crypto/gf128mul.ko matches Binary file crypto/gf128mul.o matches Binary file kernel/built-in.o matches Binary file kernel/rtmutex.o matches System.map:c1053461 t T.396 Binary file vmlinux matches Binary file vmlinux.o matches and also, there is a lot of those T.# symbols: andi@ideapad:~/linux-3.0-rt2$ egrep "T\." System.map | wc -l 259
btw, sometimes rt_preempt introduce situations that might confuse drivers. Maybe that's locking...and that T.396 is the suspect...but I can't explain what that function is... have you tried to run readelf on broadcomm's generated objects no, but if it were, it should have been in the above list. right?
hmmm. Maybe I'll just post the call-trace on the linux-rt list and hope for the best, and not getting hit by tglx's "Kantholz" (== square timber) for posting a stupid bug coming out of some binary blob :-) thx!
On Tue, Jul 26, 2011 at 01:37, Andreas Platschek <andi.platschek@gmail.com> wrote:
doesn't look like that, the brute force way says:
andi@ideapad:~/linux-3.0-rt2$ egrep -R T.396 * Binary file arch/x86/boot/compressed/vmlinux.bin matches Binary file crypto/gf128mul.ko matches Binary file crypto/gf128mul.o matches Binary file kernel/built-in.o matches Binary file kernel/rtmutex.o matches System.map:c1053461 t T.396 Binary file vmlinux matches Binary file vmlinux.o matches
tried checking via lxr.linux.no on any strings that match "396" on 3.0 tree. So far no luck...so maybe that -rt specific code... -- regards, Mulyadi Santosa Freelance Linux trainer and consultant blog: the-hydra.blogspot.com training: mulyaditraining.blogspot.com
Hi guys, On Mon, Jul 25, 2011 at 2:48 PM, Mulyadi Santosa <mulyadi.santosa@gmail.com> wrote:
On Tue, Jul 26, 2011 at 01:37, Andreas Platschek <andi.platschek@gmail.com> wrote:
doesn't look like that, the brute force way says:
andi@ideapad:~/linux-3.0-rt2$ egrep -R T.396 * Binary file arch/x86/boot/compressed/vmlinux.bin matches Binary file crypto/gf128mul.ko matches Binary file crypto/gf128mul.o matches Binary file kernel/built-in.o matches Binary file kernel/rtmutex.o matches System.map:c1053461 t T.396 Binary file vmlinux matches Binary file vmlinux.o matches
tried checking via lxr.linux.no on any strings that match "396" on 3.0 tree. So far no luck...so maybe that -rt specific code...
Since it shows with a little 't' this means that its a local symbol. If I had to guess, it's probably a compiler generated symbol. It's possible that T.396 just happens to be the closest symbol to the call location. The only way to know for sure is to disassemble the module in question and examine what's going on to see if that's the case. -- Dave Hylands Shuswap, BC, Canada http://www.davehylands.com
participants (4)
-
andi -
Andreas Platschek
-
Dave Hylands -
Mulyadi Santosa