Re: The tale of a TCP bug
Hi, I just subscribed to this list, so sorry if I missed some previous discussion on this. On Thu, Mar 24, 2011 at 16:15 -0400, John Baldwin wrote: [...] > Otherwise, something like this may apply instead: > > Index: tcp_input.c > === > --- tcp_input.c (revision 219911) > +++ tcp_input.c (working copy) > @@ -1694,7 +1694,10 @@ tcp_do_segment(struct mbuf *m, struct tcphdr *th, > win = sbspace(&so->so_rcv); > if (win < 0) > win = 0; > - tp->rcv_wnd = imax(win, (int)(tp->rcv_adv - tp->rcv_nxt)); > + if (SEQ_GEQ(tp->rcv_adv, tp->rcv_nxt)) > + tp->rcv_wnd = imax(win, (int)(tp->rcv_adv - tp->rcv_nxt)); > + else > + tp->rcv_wnd = win; > > /* Reset receive buffer auto scaling when not in bulk receive mode. */ > tp->rfbuf_ts = 0; > > I think that will fix tp->rcv_wnd to be correct in this case thus fixing > further uses of it. I just quickly tested it on my bug scenario, and it still generates adv=-1 in tcp_output That is because win=65536, which is bigger than the actually advertised window (65535, the max that can be advertised without window scaling). CU, Sec -- To paraphrase RFC1925: Time, talent, willingness: Pick any two. ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: The tale of a TCP bug
On Thursday, March 24, 2011 3:51:14 pm John Baldwin wrote: > On Thursday, March 24, 2011 3:21:24 pm Doug Barton wrote: > > http://blogmal.42.org/tidbits/tcp-bug.story > > > > $someone really needs to take a look at this. :) > > This is the same bug I reported back in February in this e-mail: > > http://lists.freebsd.org/pipermail/freebsd-net/2011-February/027892.html > > His patch may be the more correct fix though. I have two other TCP bugs also > awaiting review that I posted on the same day. Actually, I retract that a bit. I saw the problem with window updates for an established connection and his proposed change doesn't cover that. Also, I think the root problem is that tp->rcv_wnd is calculated incorrectly in this case. However, I'd be curious to see if the patch from my original e-mail fixes the issue first. Otherwise, something like this may apply instead: Index: tcp_input.c === --- tcp_input.c (revision 219911) +++ tcp_input.c (working copy) @@ -1694,7 +1694,10 @@ tcp_do_segment(struct mbuf *m, struct tcphdr *th, win = sbspace(&so->so_rcv); if (win < 0) win = 0; - tp->rcv_wnd = imax(win, (int)(tp->rcv_adv - tp->rcv_nxt)); + if (SEQ_GEQ(tp->rcv_adv, tp->rcv_nxt)) + tp->rcv_wnd = imax(win, (int)(tp->rcv_adv - tp->rcv_nxt)); + else + tp->rcv_wnd = win; /* Reset receive buffer auto scaling when not in bulk receive mode. */ tp->rfbuf_ts = 0; I think that will fix tp->rcv_wnd to be correct in this case thus fixing further uses of it. -- John Baldwin ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: The tale of a TCP bug
On Thursday, March 24, 2011 3:21:24 pm Doug Barton wrote: > http://blogmal.42.org/tidbits/tcp-bug.story > > $someone really needs to take a look at this. :) This is the same bug I reported back in February in this e-mail: http://lists.freebsd.org/pipermail/freebsd-net/2011-February/027892.html His patch may be the more correct fix though. I have two other TCP bugs also awaiting review that I posted on the same day. -- John Baldwin ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
The tale of a TCP bug
http://blogmal.42.org/tidbits/tcp-bug.story $someone really needs to take a look at this. :) Doug -- Nothin' ever doesn't change, but nothin' changes much. -- OK Go Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/ ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
The tale of a TCP bug
http://blogmal.42.org/tidbits/tcp-bug.story $someone really needs to take a look at this. :) Doug -- Nothin' ever doesn't change, but nothin' changes much. -- OK Go Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/ ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: CFT: IPv6 DNS autoconfiguration (RFC6106 RDNSS and DNSSL)
On Thu, 17 Mar 2011 13:45:14 -0400, "J.R. Oldroyd" wrote: > > I have implemented IPv6 DNS autoconfiguration using the method > described in RFC6106 which describes RDNSS and DNSSL options on > ICMPv6 router advertisements. > I see this has been downloaded a bunch of times in the last week. Any discussion? Suggestions for improvement? If not, I will file a PR to have this committed. -jr ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: kern/155597: [panic] Kernel panics with "sbdrop" message
The following reply was made to PR kern/155597; it has been noted by GNATS. From: Vladimir Kutakov To: bug-follo...@freebsd.org, v...@ashmanov.com Cc: Subject: Re: kern/155597: [panic] Kernel panics with "sbdrop" message Date: Thu, 24 Mar 2011 12:35:34 +0300 We are looking into this problem a bit. The panic is reproducible easily by means of big http trafic. We ran apache benchmark on 3 next servers: ab -c40 -n2000 'http://thehost/somesmallfile'. After just some minutes panic occurs. However, after decreasing hw.igb.num_queues to 4 (default value is 8), it occurs only after 2 hours. Finally, the server with hw.igb.num_queues=1 works good already 7 days. It seems that some problem happens during parallel tcp processing. -- WBR, Vladimir mailto:v...@ashmanov.com ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: panic in dummynet
On Thu, Mar 24, 2011 at 12:02:03PM +0300, Sergey Kandaurov wrote: > On 21 March 2011 12:43, Sergey Kandaurov wrote: > > Hi. > > > > This is a 8.1 box, not very much loaded. > > It has two simple dummynet rules. > > That's the first time it panics there. Any hints? > > > > db> x/s *panicstr > > 0: ? ? ?*** error reading from address 0 *** > > db> bt > > Tracing pid 0 tid 100116 td 0xff000ab057c0 > > m_copym() at m_copym+0x37 > > ip_fragment() at ip_fragment+0x132 > > ip_output() at ip_output+0xeef > > dummynet_send() at dummynet_send+0x14c > > dummynet_task() at dummynet_task+0x1b7 > > taskqueue_run() at taskqueue_run+0x93 > > taskqueue_thread_loop() at taskqueue_thread_loop+0x46 > > fork_exit() at fork_exit+0x118 > > fork_trampoline() at fork_trampoline+0xe > > --- trap 0, rip = 0, rsp = 0xff8399222d30, rbp = 0 --- > > > > Hmm.. Another crash today. > Looks like it might be due to race with bce intr handler. it is possible, but i wonder if this is a device-specific issue. Otherwise this kind of race would be present in every machine using dummynet -- all packets delayed by dummynet are sent out from the taskqueue using the above path. cheers luigi > Fatal trap 12: page fault while in kernel mode > cpuid = 0; apic id = 00 > fault virtual address = 0x18 > fault code = supervisor read data, page not present > instruction pointer = 0x20:0x80611587 > stack pointer = 0x28:0xff82b41da960 > frame pointer = 0x28:0xff82b41da9c0 > code segment= base 0x0, limit 0xf, type 0x1b > = DPL 0, pres 1, long 1, def32 0, gran 1 > processor eflags= interrupt enabled, resume, IOPL = 0 > current process = 0 (dummynet) > > db> bt > Tracing pid 0 tid 100121 td 0xff00094177c0 > m_copym() at m_copym+0x37 > ip_fragment() at ip_fragment+0x132 > ip_output() at ip_output+0xeef > dummynet_send() at dummynet_send+0x14c > dummynet_task() at dummynet_task+0x1b7 > taskqueue_run() at taskqueue_run+0x93 > taskqueue_thread_loop() at taskqueue_thread_loop+0x46 > fork_exit() at fork_exit+0x118 > fork_trampoline() at fork_trampoline+0xe > --- trap 0, rip = 0, rsp = 0xff82b41dad30, rbp = 0 --- > > cpuid= 0 > curthread= 0xff00094177c0: pid 0 "dummynet" > cpuid= 1 > curthread= 0xff00029a23e0: pid 12 "irq257: bce1" > cpuid= 2 > curthread= 0xff00026fc3e0: pid 12 "swi4: clock" > > 100039 Run CPU 1 [irq257: bce1] > 100038 RunQ[irq256: bce0] > 100012 Run CPU 2 [swi4: clock] > > db> bt 100039 > Tracing pid 12 tid 100039 td 0xff00029a23e0 > cpustop_handler() at cpustop_handler+0x40 > ipi_nmi_handler() at ipi_nmi_handler+0x30 > trap() at trap+0x175 > nmi_calltrap() at nmi_calltrap+0x8 > --- trap 0x13, rip = 0x805c62e4, rsp = 0xff852fe0, rbp = > 0xf > f82b155d7b0 --- > callout_lock() at callout_lock+0x54 > callout_reset_on() at callout_reset_on+0x43 > tcp_do_segment() at tcp_do_segment+0x508 > tcp_input() at tcp_input+0xd22 > ip_input() at ip_input+0xad > netisr_dispatch_src() at netisr_dispatch_src+0x7e > ether_demux() at ether_demux+0x14d > ether_input() at ether_input+0x17b > ether_demux() at ether_demux+0x6f > ether_input() at ether_input+0x17b > bce_intr() at bce_intr+0x3b0 > intr_event_execute_handlers() at intr_event_execute_handlers+0xfd > ithread_loop() at ithread_loop+0x8e > fork_exit() at fork_exit+0x118 > fork_trampoline() at fork_trampoline+0xe > --- trap 0, rip = 0, rsp = 0xff82b155dd30, rbp = 0 --- > > db> bt 100038 > Tracing pid 12 tid 100038 td 0xff00029a27c0 > sched_switch() at sched_switch+0xea > mi_switch() at mi_switch+0x16f > ithread_loop() at ithread_loop+0x1d0 > fork_exit() at fork_exit+0x118 > fork_trampoline() at fork_trampoline+0xe > --- trap 0, rip = 0, rsp = 0xff82b1554d30, rbp = 0 --- > > db> bt 100012 > Tracing pid 12 tid 100012 td 0xff00026fc3e0 > cpustop_handler() at cpustop_handler+0x40 > ipi_nmi_handler() at ipi_nmi_handler+0x30 > trap() at trap+0x175 > nmi_calltrap() at nmi_calltrap+0x8 > --- trap 0x13, rip = 0x808a8270, rsp = 0xff859fe0, rbp > = 0xff8c9bd0 --- > Xinvlpg() at Xinvlpg > ithread_loop() at ithread_loop+0x142 > fork_exit() at fork_exit+0x118 > fork_trampoline() at fork_trampoline+0xe > --- trap 0, rip = 0, rsp = 0xff8c9d30, rbp = 0 --- > > > -- > wbr, > pluknet > ___ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org" ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: panic in dummynet
On 21 March 2011 12:43, Sergey Kandaurov wrote: > Hi. > > This is a 8.1 box, not very much loaded. > It has two simple dummynet rules. > That's the first time it panics there. Any hints? > > db> x/s *panicstr > 0: *** error reading from address 0 *** > db> bt > Tracing pid 0 tid 100116 td 0xff000ab057c0 > m_copym() at m_copym+0x37 > ip_fragment() at ip_fragment+0x132 > ip_output() at ip_output+0xeef > dummynet_send() at dummynet_send+0x14c > dummynet_task() at dummynet_task+0x1b7 > taskqueue_run() at taskqueue_run+0x93 > taskqueue_thread_loop() at taskqueue_thread_loop+0x46 > fork_exit() at fork_exit+0x118 > fork_trampoline() at fork_trampoline+0xe > --- trap 0, rip = 0, rsp = 0xff8399222d30, rbp = 0 --- > Hmm.. Another crash today. Looks like it might be due to race with bce intr handler. Fatal trap 12: page fault while in kernel mode cpuid = 0; apic id = 00 fault virtual address = 0x18 fault code = supervisor read data, page not present instruction pointer = 0x20:0x80611587 stack pointer = 0x28:0xff82b41da960 frame pointer = 0x28:0xff82b41da9c0 code segment= base 0x0, limit 0xf, type 0x1b = DPL 0, pres 1, long 1, def32 0, gran 1 processor eflags= interrupt enabled, resume, IOPL = 0 current process = 0 (dummynet) db> bt Tracing pid 0 tid 100121 td 0xff00094177c0 m_copym() at m_copym+0x37 ip_fragment() at ip_fragment+0x132 ip_output() at ip_output+0xeef dummynet_send() at dummynet_send+0x14c dummynet_task() at dummynet_task+0x1b7 taskqueue_run() at taskqueue_run+0x93 taskqueue_thread_loop() at taskqueue_thread_loop+0x46 fork_exit() at fork_exit+0x118 fork_trampoline() at fork_trampoline+0xe --- trap 0, rip = 0, rsp = 0xff82b41dad30, rbp = 0 --- cpuid= 0 curthread= 0xff00094177c0: pid 0 "dummynet" cpuid= 1 curthread= 0xff00029a23e0: pid 12 "irq257: bce1" cpuid= 2 curthread= 0xff00026fc3e0: pid 12 "swi4: clock" 100039 Run CPU 1 [irq257: bce1] 100038 RunQ[irq256: bce0] 100012 Run CPU 2 [swi4: clock] db> bt 100039 Tracing pid 12 tid 100039 td 0xff00029a23e0 cpustop_handler() at cpustop_handler+0x40 ipi_nmi_handler() at ipi_nmi_handler+0x30 trap() at trap+0x175 nmi_calltrap() at nmi_calltrap+0x8 --- trap 0x13, rip = 0x805c62e4, rsp = 0xff852fe0, rbp = 0xf f82b155d7b0 --- callout_lock() at callout_lock+0x54 callout_reset_on() at callout_reset_on+0x43 tcp_do_segment() at tcp_do_segment+0x508 tcp_input() at tcp_input+0xd22 ip_input() at ip_input+0xad netisr_dispatch_src() at netisr_dispatch_src+0x7e ether_demux() at ether_demux+0x14d ether_input() at ether_input+0x17b ether_demux() at ether_demux+0x6f ether_input() at ether_input+0x17b bce_intr() at bce_intr+0x3b0 intr_event_execute_handlers() at intr_event_execute_handlers+0xfd ithread_loop() at ithread_loop+0x8e fork_exit() at fork_exit+0x118 fork_trampoline() at fork_trampoline+0xe --- trap 0, rip = 0, rsp = 0xff82b155dd30, rbp = 0 --- db> bt 100038 Tracing pid 12 tid 100038 td 0xff00029a27c0 sched_switch() at sched_switch+0xea mi_switch() at mi_switch+0x16f ithread_loop() at ithread_loop+0x1d0 fork_exit() at fork_exit+0x118 fork_trampoline() at fork_trampoline+0xe --- trap 0, rip = 0, rsp = 0xff82b1554d30, rbp = 0 --- db> bt 100012 Tracing pid 12 tid 100012 td 0xff00026fc3e0 cpustop_handler() at cpustop_handler+0x40 ipi_nmi_handler() at ipi_nmi_handler+0x30 trap() at trap+0x175 nmi_calltrap() at nmi_calltrap+0x8 --- trap 0x13, rip = 0x808a8270, rsp = 0xff859fe0, rbp = 0xff8c9bd0 --- Xinvlpg() at Xinvlpg ithread_loop() at ithread_loop+0x142 fork_exit() at fork_exit+0x118 fork_trampoline() at fork_trampoline+0xe --- trap 0, rip = 0, rsp = 0xff8c9d30, rbp = 0 --- -- wbr, pluknet ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
