/dev permissions after reboot (and panic)

Peter Avalos pavalos at theshell.com
Sat Jul 16 21:51:54 PDT 2005


On Sat, Jul 16, 2005 at 08:23:11PM -0700, Peter Avalos wrote:
> On Sat, Jul 16, 2005 at 08:05:24PM -0700, Matthew Dillon wrote:
> > 
> > :Content-Type: text/plain; charset=us-ascii
> > :Content-Disposition: inline
> > :
> > :So every time I reboot, I get a panic (I believe someone else may
> > :be having this problem too).  I've included a capture of the ddb
> > :session at the bottom.  Unfortunately, I can't get a core dump.
> > :But, what really sucks, is if I did a 'MAKEDEV all', permissions
> > :in /dev get hosed when the machine comes back up.  MAKEDEV is doing
> > :the right thing, because I've checked to make sure the devices
> > :have the correct permissions.  When the machine comes back up,
> > :things like null, zero, tty, lose their write permissions, which
> > :hoses things up.
> > :
> 
> >     Which patch set is this with?  The m_nextpkt != NULL is a warning
> >     rather a panic, but the patch set I sent today should have fixed that.
> >     The actual panic is occuring due to the buffers not being flushable, 
> >     which sounds like a softupdates issue so if the sync commands don't
> >     fix the problem (or even if they do).  See if turning off softupdates 
> >     fixes the problem (which will tell me where to look).
> > 
> 
> That was with no patches...just straight-up HEAD.  I'm compiling up a
> new kernel with the SOCKBUF_DEBUG patchset right now, and I'll see if
> that warning goes away.  I'll also try turning off softupdates and see
> what happens.
> 

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 == m in sbunlinkmbuf
mp_lock = 00000000; cpuid = 0; lapic.id = 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
Attachment:
pgp00008.pgp
-------------- next part --------------
A non-text attachment was scrubbed...
Name: pgp00008.pgp
Type: application/octet-stream
Size: 189 bytes
Desc: "Description: PGP signature"
URL: <http://lists.dragonflybsd.org/pipermail/bugs/attachments/20050716/2182ca4b/attachment-0020.obj>


More information about the Bugs mailing list