Messages in this thread | | | From | Mark_H_Johnson@raytheon ... | Subject | Re: [patch] Real-Time Preemption, -RT-2.6.10-rc1-mm2-V0.7.1 | Date | Thu, 4 Nov 2004 10:04:39 -0600 |
| |
>does the ping phenomenon go away if you chrt both the networking IRQ >thread and both ksoftirqd's to above the RT task's priority?
For the most part, yes. I reran the test with -V0.7.7 and had continuous ping responses until the system locked up with yet another deadlock. This did NOT fix the display / mouse movement lockups. All IRQ and ksoftirqd tasks were RT 99 priority for this test. latencytest ran at RT 30 priority.
The response time while RT was active looked like this...
# ping dws77 PING dws77 (192.52.216.87) from 192.52.215.17 : 56(84) bytes of data. 64 bytes from dws77 (192.52.216.87): icmp_seq=1 ttl=63 time=0.590 ms 64 bytes from dws77 (192.52.216.87): icmp_seq=2 ttl=63 time=0.468 ms 64 bytes from dws77 (192.52.216.87): icmp_seq=3 ttl=63 time=0.542 ms 64 bytes from dws77 (192.52.216.87): icmp_seq=4 ttl=63 time=0.492 ms
Note the response times are about 2x what I saw with the other kernels. The max delay was about 200 msec.
The deadlock was between the two ksoftirqd tasks...
=============================================== BUG: circular semaphore deadlock detected! ----------------------------------------------- ksoftirqd/1/6 is deadlocking current task ksoftirqd/0/3
1) ksoftirqd/0/3 is trying to acquire this lock: [cb4640c0] {r:0,a:-1,&((sk)->sk_lock.slock)} .. held by: ksoftirqd/1/ 6 [dff866f0, 0] ... acquired at: tcp_delack_timer+0x22/0x220 ... trying at: tcp_v4_rcv+0x69b/0xb00
2) ksoftirqd/1/6 is blocked on this lock: [c03c8900] {r:2,a:-1,ptype_lock} .. held by: ksoftirqd/0/ 3 [dffe8020, 0] ... acquired at: net_rx_action+0x8e/0x200
------------------------------ | showing all locks held by: | (ksoftirqd/0/3 [dffe8020, 0]): ------------------------------
#001: [d84a7c30] {r:0,a:-1,&tp->rx_lock} ... acquired at: rtl8139_poll+0x48/0x180 [8139too]
------------------------------ | showing all locks held by: | (ksoftirqd/1/6 [dff866f0, 0]): ------------------------------
#001: [cb4640c0] {r:0,a:-1,&((sk)->sk_lock.slock)} ... acquired at: tcp_delack_timer+0x22/0x220
Appears that both were working on network operations concurrently. Will send the full serial console log separately.
--Mark
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |