Re: panic: tcp_input: TCPS_LISTEN in netinet/tcp_input.c:2370

From: Peter Holm (peter_at_holm.cc)
Date: 12/26/04

  • Next message: Giorgos Keramidas: "Re: witness found wanting (was Re: LORs in ipfilter)" 
    Date: Sun, 26 Dec 2004 21:33:38 +0100
To: Andre Oppermann <andre@freebsd.org>

    On Mon, Dec 20, 2004 at 09:57:32PM +0100, Andre Oppermann wrote:
    > Peter Holm wrote:
    > >During stress test with GENERIC HEAD from Dec 20 12:18 UTC I got:
    > >
    > >panic(c08374d0,8,c08f46e0,c1523170,3e0) at panic+0x190
    > >tcp_input(c2877900,14,2,c082b363,246) at tcp_input+0x2689
    > >ip_input(c2877900,18,c091a0b8,cbc7fcf4,c0681867) at ip_input+0xd6
    > >netisr_processqueue(c154a080,c154c180,c1523170,cbc7fd1c,c05ffa66)
    > > at netisr_processqueue+0xf
    > >swi_net(0,0,0,c1554bd0,0) at swi_net+0x8b
    > >ithread_loop(c154c180,cbc7fd48,c154c180,c05ff8c8,0) at
    > >ithread_loop+0x19e
    > >fork_exit(c05ff8c8,c154c180,cbc7fd48) at fork_exit+0x7e
    > >fork_trampoline() at fork_trampoline+0x8
    > >
    > >http://www.holm.cc/stress/log/cons96.html
    >
    > Duh. This is really strange. t_state is 0x1 which is TCPS_LISTEN.
    > Listen is only checked on the socket not on the tcpcb. However there
    > is a panic after "after_listen:" that checks for exactly TCPS_LISTEN.
    > It should never have made it past this one. That it did suggests
    > some kind of race condition wrt. sockets and the tcpcb creation for
    > the listening socket. Though even more strange is how this KASSERT
    > can be reached; Only if the segment has FIN set. /me puzzled.
    >
    > Ok, we know the segment had FIN set. We know the tcpcb is in LISTEN
    > state. We know in_pcblookup_hash() found this inpcb. We don't know
    > how the segment processing made it past all the checks prior to this
    > KASSERT.
    >
    > --
    > Andre

    Here's a new one: http://www.holm.cc/stress/log/cons98.html 

    -- 
Peter Holm
_______________________________________________
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org"
  • Next message: Giorgos Keramidas: "Re: witness found wanting (was Re: LORs in ipfilter)"

    Relevant Pages

    • Re: !EventConnect Problem
      ... the June roll-up is available somewhere, although there's not been the usual ... The socket is not in a listening state. ... The incoming connection queue has no room for connections. ...
      (microsoft.public.windowsce.app.development)
    • Re: !EventConnect Problem
      ... the June roll-up is available somewhere, ... The socket is not in a listening state. ... The incoming connection queue has no room for connections. ...
      (microsoft.public.windowsce.app.development)
    • Re: !EventConnect Problem
      ... poll time of 500mS we get a break in communication approx once a day, ... The socket is not in a listening state. ... There's a problem with the connection address, ...
      (microsoft.public.windowsce.app.development)
    • Re: !EventConnect Problem
      ... You'll probably want to know whether the socket ... server we are using is multi-threaded, however this only seens to have ... The socket is not in a listening state. ... The incoming connection queue has no room for connections. ...
      (microsoft.public.windowsce.app.development)
    • Re: !EventConnect Problem
      ... you're going to have to contact MS and use one of the Platform Builder ... You'll probably want to know whether the socket is ... The socket is not in a listening state. ... The incoming connection queue has no room for connections. ...
      (microsoft.public.windowsce.app.development)