Hi Ali,
I have a different panic now(not sure about the old one, that is also
there). I had modified e1000_clean_rx_irq function to check for the
skb_dev_name and match it with eth0 and process the packet only if it
matched, just for a check.. The panic comes in the first line of code in
strcmp:
fffffc00004e8ff0 <strcmp>:
fffffc00004e8ff0: 00 00 70 2c ldq_u t2,0(a0)
This is because a0($16) holds 000032b25000ada8 which is not a valid
address. I tried to trace back when a0 was last loaded:
stq $16,168($30) # adapter, adapter
stq $18,176($30) # work_done, work_done
stq $19,184($30) # work_to_do, work_to_do
This is at the beginning of the function e1000_clean_rx_irq :
static bool e1000_clean_rx_irq(struct e1000_adapter *adapter,
struct e1000_rx_ring *rx_ring,
int *work_done, int work_to_do)
I am not sure how to fix this.. Is there a problem during compiling, a0
should have been loaded but it is not? I followed the instructions in this
site to match the assembly code and c code :
http://kerneltrap.org/node/3648
I added the assembly comments after each line to trace the flow of the code
and made sure I went through all the parts of the code till before the
strcmp call to check if a0 is loaded.. Do you have any suggestion about
what I can do next?
Thanks,
Pritha
On Tue, Jun 19, 2012 at 7:03 PM, Pritha Ghoshal <pritha9...@neo.tamu.edu>wrote:
> 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
