Hello list, Herbert! I use this two patch about 10 hours on a high loaded system, but at this point, only found this:
Aug 20 01:07:23 192.168.2.50 [42992885.040000] Aug 20 01:07:23 192.168.2.50 kernel: [42992885.040000] Unable to handle kernel paging request at virtual address a014d7a5 Aug 20 01:07:23 192.168.2.50 kernel: [42992885.040000] printing eip: Aug 20 01:07:23 192.168.2.50 kernel: [42992885.040000] c0118cee Aug 20 01:07:23 192.168.2.50 kernel: [42992885.040000] *pde = f7bedd02 Aug 20 01:07:23 192.168.2.50 kernel: [42992885.040000] Oops: 0000 [#1] Aug 20 01:07:23 192.168.2.50 kernel: [42992885.040000] SMP Aug 20 01:07:23 192.168.2.50 kernel: [42992885.040000] Modules linked in: netconsole gnbd Aug 20 01:07:23 192.168.2.50 kernel: [42992885.040000] CPU: 0 Aug 20 01:07:23 192.168.2.50 kernel: [42992885.040000] EIP: 0060:[<c0118cee>] Not tainted VLI Aug 20 01:07:23 192.168.2.50 kernel: [42992885.040000] EFLAGS: 00010296 (2.6.13-rc6) Aug 20 01:07:23 192.168.2.50 kernel: [42992885.040000] EIP is at kmap+0x1e/0x54 Aug 20 01:07:24 192.168.2.50 kernel: [42992885.040000] eax: 00000246 ebx: a014d7a5 ecx: c11ef260 edx: cabbc400 Aug 20 01:07:24 192.168.2.50 kernel: [42992885.040000] esi: 00008000 edi: 00000001 ebp: f6c7fe00 esp: f6c7fdf4 Aug 20 01:07:24 192.168.2.50 kernel: [42992885.040000] ds: 007b es: 007b ss: 0068 Aug 20 01:07:24 192.168.2.50 kernel: [42992885.040000] Process md3_raid1 (pid: 2769, threadinfo=f6c7e000 task=f7eef020) Aug 20 01:07:24 192.168.2.50 kernel: [42992885.040000] Stack: c0577800 00000006 f5f93cfc f6c7fe54 f895a9cc a014d7a5 00000001 c f793000 Aug 20 01:07:24 192.168.2.50 kernel: [42992885.040000] 00001000 00004000 d3fc3180 f73e9bf0 f895e718 cabbc400 007ea037 0 1000000 Aug 20 01:07:24 192.168.2.50 kernel: [42992885.040000] d4175a4c f895e6f0 65000000 00f03d8d 00100000 d4175a4c f895e6f0 f 895e700 Aug 20 01:07:24 192.168.2.50 kernel: [42992885.040000] Call Trace: Aug 20 01:07:24 192.168.2.50 kernel: [42992885.040000] [<c0103ca2>] show_stack+0x9a/0xd0 Aug 20 01:07:24 192.168.2.50 kernel: [42992885.040000] [<c0103e6d>] show_registers+0x175/0x209 Aug 20 01:07:24 192.168.2.50 kernel: [42992885.040000] [<c010408c>] die+0xfa/0x17c Aug 20 01:07:24 192.168.2.50 kernel: [42992885.040000] [<c0117b68>] do_page_fault+0x269/0x7bd Aug 20 01:07:24 192.168.2.50 kernel: [42992885.040000] [<c01038d7>] error_code+0x4f/0x54 Aug 20 01:07:24 192.168.2.50 kernel: [42992885.040000] [<f895a9cc>] __gnbd_send_req+0x196/0x28d [gnbd] Aug 20 01:07:24 192.168.2.50 kernel: [42992885.040000] [<f895af12>] do_gnbd_request+0xe5/0x198 [gnbd] Aug 20 01:07:24 192.168.2.50 kernel: [42992885.040000] [<c0383a0d>] __generic_unplug_device+0x28/0x2e Aug 20 01:07:24 192.168.2.50 kernel: [42992885.040000] [<c038150f>] __elv_add_request+0xaa/0xac Aug 20 01:07:24 192.168.2.50 kernel: [42992885.040000] [<c0384e5b>] __make_request+0x20d/0x512 Aug 20 01:07:24 192.168.2.50 kernel: [42992885.040000] [<c0385490>] generic_make_request+0xb2/0x27a Aug 20 01:07:24 192.168.2.50 kernel: [42992885.040000] [<c04748a2>] raid1d+0xbf/0x2cb Aug 20 01:07:24 192.168.2.50 kernel: [42992885.040000] [<c04825c9>] md_thread+0x134/0x16f Aug 20 01:07:24 192.168.2.50 kernel: [42992885.040000] [<c01010d5>] kernel_thread_helper+0x5/0xb Aug 20 01:07:24 192.168.2.50 kernel: [42992885.040000] Code: 89 c1 81 e1 ff ff 0f 00 eb b0 90 90 90 55 89 e5 53 83 ec 08 8b 5d 08 c7 44 24 04 06 00 00 00 c7 04 24 00 78 57 c0 e8 72 47 00 00 <8b> 03 c1 e8 1e 8b 14 85 14 db 73 c0 8b 82 0c 04 00 00 05 00 09 Aug 20 01:07:24 192.168.2.50 Fatal exception: panic in 5 seconds Aug 20 01:07:24 192.168.2.50 kernel: [42992885.040000] <0>Fatal exception: panic in 5 seconds Aug 20 01:07:27 192.168.2.50 [42992890.060000] Kernel panic - not syncing: Fatal exception Aug 20 01:07:27 192.168.2.50 [42992890.060000] I think is not what we waiting for.... And not the *NBD's common deadlock problem... Any idea? Thanks Janos ----- Original Message ----- From: "Herbert Xu" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Cc: <[EMAIL PROTECTED]>; <netdev@vger.kernel.org> Sent: Thursday, August 18, 2005 11:43 PM Subject: Re: Fw: [Bug 5050] New: KERNEL: assertion (cnt <= tp->packets_out) failed at net/ipv4/tcp_input.c (1476) > [EMAIL PROTECTED] wrote: > > > > I gets this problem sometimes too. > > Try this two patch in 2.6.13-rc6, and I have attached the log. > > (the log is filtered with | grep -v "last message repeated") > > Sorry, the debugging patch in the original email is wrong. Please > try this one instead. > > Thanks, > -- > Visit Openswan at http://www.openswan.org/ > Email: Herbert Xu ~{PmV>HI~} <[EMAIL PROTECTED]> > Home Page: http://gondor.apana.org.au/~herbert/ > PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt > -- > diff --git a/net/ipv4/tcp_input.c b/net/ipv4/tcp_input.c > --- a/net/ipv4/tcp_input.c > +++ b/net/ipv4/tcp_input.c > @@ -1474,6 +1474,10 @@ static void tcp_mark_head_lost(struct so > int cnt = packets; > > BUG_TRAP(cnt <= tp->packets_out); > + if (unlikely(cnt > tp->packets_out)) { > + printk("packets_out = %d, fackets_out = %d, reordering = %d, sack_ok = 0x%x, mss_cache=%d\n", tp->packets_out, tp->fackets_out, tp->reordering, tp->rx_opt.sack_ok, tp->mss_cache); > + dump_stack(); > + } > > sk_stream_for_retrans_queue(skb, sk) { > cnt -= tcp_skb_pcount(skb); > - > To unsubscribe from this list: send the line "unsubscribe netdev" in > the body of a message to [EMAIL PROTECTED] > More majordomo info at http://vger.kernel.org/majordomo-info.html - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
