T.XYZ symbols

T.XYZ symbols

[Andreas Platschek]

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

T.XYZ symbols

[Mulyadi Santosa]

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

T.XYZ symbols

[andi]

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

T.XYZ symbols

[Mulyadi Santosa]

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

T.XYZ symbols

[Andreas Platschek]

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 at 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 at 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!

T.XYZ symbols

[Mulyadi Santosa]

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 at 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

T.XYZ symbols

[Dave Hylands]

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 at 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