I was able to use 1 core with the remote gdb.. With the 4 cores though, even after connecting remote gdb-s to each of the cores, I get the same output even after a kernel panic: (gdb) c Continuing. Watchdog has expired. Target detached.
I am not able to get a backtrace on any of the connected gdb-s.. Pritha On Tue, Jun 19, 2012 at 2:38 PM, Ali Saidi <sa...@umich.edu> wrote: > ** > > I think i missed that post, but you might need to connect 4 instances of > gdb to the four cpus. This doesn't happen with 1, 2 or 3 cores? > > > > You can go to every cache and add code to the inbound port or dram port > that has an explicit check on that address in the packet (cache block > aligned). Every time it sees a read or write you should print out the fact > that the write happened and at some point hopefully you'll find the bad > piece of data. > > > > Ali > > > > On 19.06.2012 14:31, Pritha Ghoshal wrote: > > Hi Ali, > > I am having some troubles using the gdb on a 4 core machine (I had posted > a previous mail to the group about that), I'll try it out once more and > see.. > > How could I add the memory checks? > > Thanks, > Pritha > > On Tue, Jun 19, 2012 at 2:02 PM, Ali Saidi <sa...@umich.edu> wrote: > >> >> >> On 19.06.2012 13:06, Pritha Ghoshal wrote: >> >> Hi, >> I am getting a kernel panic which I am not able to debug. The pc itself >> is getting polluted.. I have added the trace of the panic at the end of the >> email. >> This is a snippet from the object dump of the kernel code. >> fffffc00005d51e8: 00 00 69 a7 ldq t12,0(s0) >> fffffc00005d51ec: 00 40 5b 6b jsr ra,(t12),fffffc00005d51f0 >> fffffc00005d51f0: 2a 00 ba 27 ldah gp,42(ra) >> The panic is when ra = fffffc00005d51f0. Therefore the jsr should have >> jumped to the address in t12 which is 0000000002969588. t12 gets loaded >> from s0 in the previous step. I was unable to trace back the memory address >> content, is there a way to do it? The last function in the trace is given >> in the following link: >> http://lxr.free-electrons.com/source/net/core/neighbour.c?v=2.6.28#L1187 >> Could someone suggest how I go about debugging this kernel panic? Thanks >> in advance.. >> Thanks, >> Pritha >> >> You'll need to either use the gdb support in gem5 or maybe put some >> checks in the memory system for that specific address and print as it gets >> changed. >> Ali >> >> >> _______________________________________________ >> gem5-users mailing list >> gem5-users@gem5.org >> http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users > > > >
_______________________________________________ gem5-users mailing list gem5-users@gem5.org http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
