On Sat, 23 Nov 1996, Tom T. Thai wrote:

> Nov 23 03:22:50 jupiter /netbsd: panic: accept
> 
> What does this mean?  jupiter has a P90, 64mb RAM, 5Gig HD (2g + 2g via 
> CCD--mounted from 1.0a, and the other 1g for /usr etc.)
> 
> I'm not sure what could of gone wrong but I have been worried about CCD 
> that was build back in 1.0A days.

No, it's nothing to do with the disks. Accept struck me as being
most likely in the networking code. A quick grep of /sys/*/* for
'panic("accept' shows it to be in kern/uipc_syscalls.c. Looking in
there, we see it's in the function sys_accept() (the accept(2)
system call), in a fragment of code that looks like this:

        { struct socket *aso = so->so_q;
          if (soqremque(aso, 1) == 0)
                panic("accept");
          so = aso;
        }

Looks like we're trying to remove something from a queue and there's
nothing on the queue, doesn't it?

But what the heck, since this is in the networking code, and we've
all got a copy of _TCP/IP Illustrated Vol. 2_ sitting beside our
desks at all times, we can look it up. There's no sys_accept in
the function index, but there is an accept, and tht takes us to
page 458, which shows us some code bearing a remarkable resemblence
to sys_accept. It's even got that exact same chunk in the middle,
in lines 156-160.

So we trundle on to the notes, which for this section are on the
next page. The only mention of the panic() call is `Exercise 15.4
discusses the call to panic.' Exercise 15.4 merely asks `Why is
panic called when soqremque returns a null pointer in Figure 15.26?'

*** WARNING: SPOILER ALERT ***

So we turn to the answers in the back of the book (oh, how naughty
we are!) and it says: `The call to soqremque is only made when
so_qlen is not equal to 0. If soqremque returns a null pointer
there must be an error in the socket queuing code so the kernel
panics.'

So with kernel source code and a couple of minutes of simple
analysis, we've made good progress on finding the problem here.
But I don't want to do *all* the work for you, so I'll leave tracking
down the bug in the queuing code as an exercise for the reader. :-)

cjs

Curt Sampson    cjs@portal.ca		Info at http://www.portal.ca/
Internet Portal Services, Inc.	
Vancouver, BC   (604) 257-9400		De gustibus, aut bene aut nihil.