You're going to have to get gdb hooked up to gem5 and see where that address is coming from and why its bad. With alpha all the kernel addresses should start with ffffc, so some how something is going wrong. You can also try sprinking printks or dprintks through the code to see where the address is being generated. Once you track how it's computed, you can see where it is loaded from and then go looking for who wrote that last and why it was wrong.
Ali On 15.05.2012 01:08, Pritha Ghoshal wrote: > Hi, > > I am trying to use two e1000 drivers to simulate an incoming port and an outgoing port. I have the iptables setup in between to regulate traffic and let only some packets proceed to the outgoing port. I have modified the networking part of the kernel as follows: > 1. I added a virtual device driver which sits on top of eth0 and eth1. > 2. This device calls the iptable functions by using the NF_HOOK mechanism for all three hooks - PRE_ROUTING, FORWARD, POST_ROUTING. > 3. I have removed the NF_HOOK calls from places like ip_rcv, ip_forward and ip_output, the functions that were being called through NF_HOOKS are being called directly now. > > When I try to run packets through this setup, it works well till 1000 packets. In the experiment where I try to send 10,000 packets, I get a kernel panic: > Unable to handle kernel paging request at virtual address 0000074a7b000000^M > CPU 0 ksoftirqd/0(4): Oops 0^M > pc = [] ra = [] ps = 0000 Tainted: G W^M > pc is at put_page+0x28/0x190^M > ra is at skb_release_data+0xe8/0x120^M > v0 = 0000000000000000 t0 = fffffc001da7e350 t1 = 0000000000006000^M > t2 = 0000000000000001 t3 = 0000000000000068 t4 = 0008000400000000^M > t5 = 0000000000000000 t6 = 0000000000000002 t7 = fffffc001f04c000^M > s0 = 0000074a7b000000 s1 = fffffc001e40bbc0 s2 = 0000000000000069^M > s3 = fffffc001f248000 s4 = 0000000000000068 s5 = fffffc001f37e680^M > s6 = 0000000000000001^M > a0 = 0000074a7b000000 a1 = 000000009da7e2d2 a2 = 0000000000000068^M > a3 = 0000000000000001 a4 = fffffc001f2f6800 a5 = fffffc001da897c0^M > t8 = 0000000000000000 t9 = 0000000000000000 t10= 0000000002000000^M > t11= ffffffffffffffff pv = fffffc000037ddc0 at = 0000000000000020^M > gp = fffffc000086fc60 sp = fffffc001f04fc38^M > Trace:^M > [] skb_release_data+0xe8/0x120^M > [] __kfree_skb+0x1c/0x120^M > [] dev_kfree_skb_any+0x40/0x70^M > [] e1000_unmap_and_free_tx_resource+0x30/0x80^M > [] e1000_clean+0xec/0x720^M > [] net_rx_action+0x1d8/0x2c0^M > [] __do_softirq+0x13c/0x170^M > [] do_softirq+0x74/0x80^M > [] kthread+0x0/0xc0^M > [] ksoftirqd+0xb0/0x170^M > [] kthread+0x70/0xc0^M > [] ksoftirqd+0x0/0x170^M > [] kernel_thread+0x28/0x90^M > > It is giving an error in put_page call in the skb_release_data function. Could someone help me in this? I am not sure how to proceed to debug this.. > > Thanks, > Pritha > > _______________________________________________ > 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
