On 07/25/2011 07:47 PM, Mulyadi Santosa wrote:

On Tue, Jul 26, 2011 at 00:18, andi[off-list ref]  wrote:
   

quoted

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!