/dev permissions after reboot (and panic)

[Peter Avalos]

On Sun, Jul 17, 2005 at 02:08:31AM -0700, Peter Avalos wrote:
> On Sun, Jul 17, 2005 at 12:47:41AM -0700, Matthew Dillon wrote:
> > 
> > :
> > :I applied the SOCKBUF_DEBUG patch and rebooted.  After the machine came up,
> > :I tried a MAKEDEV, sync, waited about a mintue, then rebooted.  I then got
> > :this panic:
> > :
> > :panic: assertion: sb->sb_mb =3D=3D m in sbunlinkmbuf
> > :mp_lock =3D 00000000; cpuid =3D 0; lapic.id =3D 00000000
> > :boot() called on cpu#0
> > :Uptime: 3m22s
> > :
> > :Matt, as you know my remote console really sucks, so I wasn't able to
> > :get everything, but I did get a sucessfuly dump.  That's uploading to
> > :leaf right now (*.12).
> > :
> > :Hopefully it's useful.
> > :
> > :--Peter
> > 
> >     Dump looks good.  The sockbuf has clearly been corrupted.  Not only
> >     that, but the debug code checked that the sockbuf was valid at 
> >     the beginning of the sbdrop() call and it was fine.
> > 
> >     This is very encouraging!
> > 
> >     That patch set did not entirely solve the blocking problem with
> >     m_free().  There are still several places where I am calling m_free()
> >     without resynchronizing the sockbuf state and I broke a record
> >     delimiter in soreceive().  Here is a new patch to try.  In this patch
> >     I defer all m_free() calls to the end of the routine to avoid the
> >     blocking issue.  It also appears that sbdrop() was being called without
> >     a critical section.  This should not have caused a problem but
> >     clearly something has raced the sbdrop() call so I'm adding one for
> >     good measure.
> > 
> 
> Ok, that fixed the m_free() warning and subsequent panic on reboot.  It
> may take a few days to figure out if it fixes my previously reported panics.
> 
> I am still getting a "busy buffer problem" on reboot, and then the /dev
> permission problem.  Sometimes I don't even have time to type "cont" at
> the db> prompt.  It hard-locks.  Also, attempts to get a dump by typing
> 'panic' have failed.
> 

Forgot to mention that this happens with and without softupdates enabled.

--Peter
Attachment:
pgp00011.pgp
-------------- next part --------------
A non-text attachment was scrubbed...
Name: pgp00011.pgp
Type: application/octet-stream
Size: 189 bytes
Desc: "Description: PGP signature"
URL: <http://lists.dragonflybsd.org/pipermail/bugs/attachments/20050717/3aacb1e3/attachment-0022.obj>