On 07/25/2011 07:47 PM, Mulyadi Santosa wrote: > On Tue, Jul 26, 2011 at 00:18, andi<andi.platschek@xxxxxxxxx> 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! _______________________________________________ Kernelnewbies mailing list Kernelnewbies@xxxxxxxxxxxxxxxxx http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
