/dev permissions after reboot (and panic)

[Peter Avalos]

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.
> :
> :A copy of the kernel can be found on leaf:~pavalos/public/kernel.0713
> :or at:
> :
> :http://www.theshell.com/~pavalos/crash/kernel.0713
> :
> :Here's the ddb session (hand-typed):
> 
>     Are you rebooting just after doing the MAKEDEV or are the permissions
>     hosed after you run MAKEDEV and check them, before rebooting? 
> 
>     If the permissions are getting hosed after the reboot see if a few
>     'sync' commands and a pause before 'reboot' works around that problem.
>     I will try to reproduce the MAKEDEV issue on my test box.
> 

Yeah, I've tried a bunch of sync's before the reboot.  I've even seen this
happen hours after a MAKEDEV.

>     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.

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