T.XYZ symbols

Andreas Platschek andi.platschek at gmail.com
Mon Jul 25 14:37:01 EDT 2011


On 07/25/2011 07:47 PM, Mulyadi Santosa wrote:
> On Tue, Jul 26, 2011 at 00:18, andi<andi.platschek at 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!



More information about the Kernelnewbies mailing list