From mi@misha.privatelabs.com  Mon Apr  9 13:22:52 2001
Return-Path: <mi@misha.privatelabs.com>
Received: from privatecube.privatelabs.com (privatecube.privatelabs.com [63.114.185.254])
	by hub.freebsd.org (Postfix) with ESMTP
	id 23FBD37B422; Mon,  9 Apr 2001 13:22:51 -0700 (PDT)
	(envelope-from mi@misha.privatelabs.com)
Received: from misha.privatelabs.com (root@misha.plten [10.0.0.106])
	by privatecube.privatelabs.com (8.9.3/8.9.2) with ESMTP id QAA22794;
	Mon, 9 Apr 2001 16:43:10 -0400
Received: (from mi@localhost)
	by misha.privatelabs.com (8.11.3/8.11.1) id f39KMmv16963;
	Mon, 9 Apr 2001 16:22:48 -0400 (EDT)
	(envelope-from mi)
Message-Id: <200104092022.f39KMmv16963@misha.privatelabs.com>
Date: Mon, 9 Apr 2001 16:22:48 -0400 (EDT)
From: Mikhail Teterin <mi@misha.privatelabs.com>
Reply-To: mi@aldan.algebra.com
To: FreeBSD-gnats-submit@freebsd.org
Cc: julian@freebsd.org, jkh@freebsd.org
Subject: devfs panics
X-Send-Pr-Version: 3.113
X-GNATS-Notify:

>Number:         26466
>Category:       kern
>Synopsis:       devfs panics
>Confidential:   no
>Severity:       serious
>Priority:       high
>Responsible:    freebsd-bugs
>State:          closed
>Quarter:        
>Keywords:       
>Date-Required:  
>Class:          sw-bug
>Submitter-Id:   current-users
>Arrival-Date:   Mon Apr 09 13:30:01 PDT 2001
>Closed-Date:    Tue Oct 2 00:52:28 PDT 2001
>Last-Modified:  Tue Oct 02 00:52:55 PDT 2001
>Originator:     
>Release:        FreeBSD 4.2-RC i386
>Organization:
Virtual Estates, Inc.
>Environment:

	A dual PIII-1GHz with 1Gb of RAM.

>Description:

	The usual /dev/ad8e and the devfs /devs/rad8e are supposed to be
	the same. Major number is 116, minor -- 68. The drive is "dangerously
	allocated".


	The /dev/ad8e can be used properly and houses my /home partition.
	However, attempts to use /devs/rad8e, even for something as minor
	as ``tunefs -n enable /devs/rad8e'' causes an instant panic.

	May be, someone will address the naming problem in devfs too :)

	Ultimately, I'd like to be able to mount devfs as /dev, so I can
	mount the / as read-only.

>How-To-Repeat:

	See description.

>Fix:
>Release-Note:
>Audit-Trail:

From: Poul-Henning Kamp <phk@critter.freebsd.dk>
To: mi@aldan.algebra.com
Cc: FreeBSD-gnats-submit@FreeBSD.ORG, julian@FreeBSD.ORG,
	jkh@FreeBSD.ORG
Subject: Re: kern/26466: devfs panics 
Date: Mon, 09 Apr 2001 22:34:50 +0200

 >	The usual /dev/ad8e and the devfs /devs/rad8e are supposed to be
 >	the same. Major number is 116, minor -- 68. The drive is "dangerously
 >	allocated".
 >
 >
 >	The /dev/ad8e can be used properly and houses my /home partition.
 >	However, attempts to use /devs/rad8e, even for something as minor
 >	as ``tunefs -n enable /devs/rad8e'' causes an instant panic.
 
 Please send us the details of the kernel panic (see the handbook
 for how to report usefull info.
 
 >	May be, someone will address the naming problem in devfs too :)
 >
 >	Ultimately, I'd like to be able to mount devfs as /dev, so I can
 >	mount the / as read-only.
 
 Uhm, you need to be much more specific here...
 
 --
 Poul-Henning Kamp       | UNIX since Zilog Zeus 3.20
 phk@FreeBSD.ORG         | TCP/IP since RFC 956
 FreeBSD committer       | BSD since 4.3-tahoe    
 Never attribute to malice what can adequately be explained by incompetence.

From: mi@aldan.algebra.com
To: Poul-Henning Kamp <phk@critter.freebsd.dk>
Cc: FreeBSD-gnats-submit@FreeBSD.ORG, julian@FreeBSD.ORG,
	jkh@FreeBSD.ORG
Subject: Re: kern/26466: devfs panics 
Date: Mon, 9 Apr 2001 17:31:05 -0400 (EDT)

 On  9 Apr, Poul-Henning Kamp wrote:
 = 
 = > The usual /dev/ad8e and the devfs /devs/rad8e are supposed to be the
 = > same. Major  number is 116, minor  -- 68. The drive  is "dangerously
 = > allocated".
 = >
 = >
 = > The /dev/ad8e  can be used  properly and houses my  /home partition.
 = > However, attempts to use /devs/rad8e, even for something as minor as
 = > ``tunefs -n enable /devs/rad8e'' causes an instant panic.
 =
 = Please send us  the details of the kernel panic  (see the handbook for
 = how to report usefull info.
 
 I know how. It is just fairly  difficult to do in this case. The machine
 has 1Gb of  RAM and a total of  4Gb of virtual memory. I  was hoping, it
 would be easy to reproduce, but if  you insist, I'll look around for the
 dump-device, that is big enough.
  
 = >	May be, someone will address the naming problem in devfs too :)
 = >
 = >	Ultimately, I'd like to be able to mount devfs as /dev, so I can
 = >	mount the / as read-only.
  
 = Uhm, you need to be much more specific here...
 
 Well, it  seems, that  the only  thing, that prevents  me from  having a
 read-only / is the  stuff in /dev. For example, sshd  will want to chown
 the tty to me when I login an close the session if it can not.
 
 If I could  mount the devfs' /devs  over /dev, I could mount  the / read
 only...  I think,  that is...  This is  an "appliance"  like setup,  and
 changes to  the / are  not anticipated  (/var/log and /tmp  are separate
 partitions, no  e-mail, no  news). Keeping /  mount to  will, hopefully,
 decrease the danger of it getting corrupted by power outages and bugs.
 
 	-mi
 
 

From: Poul-Henning Kamp <phk@critter.freebsd.dk>
To: mi@aldan.algebra.com
Cc: FreeBSD-gnats-submit@FreeBSD.ORG, julian@FreeBSD.ORG,
	jkh@FreeBSD.ORG
Subject: Re: kern/26466: devfs panics 
Date: Mon, 09 Apr 2001 23:33:53 +0200

 In message <200104092131.f39LV6C17200@misha.privatelabs.com>, mi@aldan.algebra.
 com writes:
 >On  9 Apr, Poul-Henning Kamp wrote:
 >= 
 >= > The usual /dev/ad8e and the devfs /devs/rad8e are supposed to be the
 >= > same. Major  number is 116, minor  -- 68. The drive  is "dangerously
 >= > allocated".
 >= >
 >= >
 >= > The /dev/ad8e  can be used  properly and houses my  /home partition.
 >= > However, attempts to use /devs/rad8e, even for something as minor as
 >= > ``tunefs -n enable /devs/rad8e'' causes an instant panic.
 >=
 >= Please send us  the details of the kernel panic  (see the handbook for
 >= how to report usefull info.
 >
 >I know how. It is just fairly  difficult to do in this case. The machine
 >has 1Gb of  RAM and a total of  4Gb of virtual memory. I  was hoping, it
 >would be easy to reproduce, but if  you insist, I'll look around for the
 >dump-device, that is big enough.
 
 I'm not asking for a core dump, I'm asking for the panic string and
 a dump of the name table around the offending %eip
 
 >= >	May be, someone will address the naming problem in devfs too :)
 >= >
 >= >	Ultimately, I'd like to be able to mount devfs as /dev, so I can
 >= >	mount the / as read-only.
 > 
 >= Uhm, you need to be much more specific here...
 >
 >Well, it  seems, that  the only  thing, that prevents  me from  having a
 >read-only / is the  stuff in /dev. For example, sshd  will want to chown
 >the tty to me when I login an close the session if it can not.
 
 Have you tried enabling DEVFS in your kernel ?  It will automagically
 mount on /dev...
 
 --
 Poul-Henning Kamp       | UNIX since Zilog Zeus 3.20
 phk@FreeBSD.ORG         | TCP/IP since RFC 956
 FreeBSD committer       | BSD since 4.3-tahoe    
 Never attribute to malice what can adequately be explained by incompetence.

From: mi@aldan.algebra.com
To: Poul-Henning Kamp <phk@critter.freebsd.dk>
Cc: FreeBSD-gnats-submit@FreeBSD.ORG, julian@FreeBSD.ORG,
	jkh@FreeBSD.ORG
Subject: Re: kern/26466: devfs panics 
Date: Mon, 9 Apr 2001 18:06:14 -0400 (EDT)

 On  9 Apr, Poul-Henning Kamp wrote:
 = 
 = I'm not asking for a core dump, I'm asking for the panic string and
 = a dump of the name table around the offending %eip
 
 Sorry. Here:
 
 	Fatal trap 12: page fault while in kernel mode
 	mp_lock = 00000002; cpuid = 0; lapic.id = 00000000
 	fault virtual address	= 0x0
 	fault code		= supervisor read, page not present
 	instructions pointer	= 0x8:0xc01740bb
 	stack pointer		= 0x10:0xded08cc4
 	frame pointer		= 0x10:0xded08d3c
 	code segment		= base 0x0, limit 0xfffff, type 0x1b
 				= DPL 0, pres 1, def32 1, gran 1
 	processor eflags	= interrupt enabled, resume, IOPL = 0
 	current process		= 548 (mount)
 	interrupt mask		= none <- SMP; XXX
 	trap number		= 12
 
 
 	mi@pizza:~ (106) nm /kernel | grep '^c017[34]' | sort
 	c01730a0 t devfs_access
 	c0173154 t devfs_getattr
 	c017332c t devfs_setattr
 	c0173534 t devfs_xread
 	c01735fc t devfs_xwrite
 	c0173644 t devfs_remove
 	c0173764 t devfs_link
 	c0173804 t devfs_rename
 	c0173c0c t devfs_symlink
 	c0173cc4 t devfs_readdir
 	c0173e68 t devfs_readlink
 	c0173efc t devfs_reclaim
 	c0173f64 t devfs_print
 	c0173f74 T devfs_dropvnode
 	c0173fc8 t devfs_open
 	c0174154 t devfs_read
 	c0174170 t devfs_write
 	c017418c t devfs_ioctl
 	c01741ec t devfs_poll
 	c017423c t devfs_fsync
 	c01743b4 t devfs_inactive
 	c01743f4 t devfs_strategy
 	c0174470 t devfs_freeblks
 	c01744dc t devfs_bmap
 	c0174520 t devfs_close
 	c017469c t devfs_advlock
 	c01746b8 t devfs_badop
 	c01746c4 t devfs_getpages_iodone
 	c01746d8 t devfs_getpages
 	c0174a40 T fifo_vnoperate
 	c0174a58 t fifo_lookup
 	c0174a6c t fifo_open
 	c0174d30 t fifo_read
 	c0174dc8 t fifo_write
 	c0174e5c t fifo_ioctl
 	c0174ed4 t fifo_kqfilter
 	c0174f38 t filt_fifordetach
 	c0174f74 t filt_fiforead
 	c0174fa4 t filt_fifowdetach
 	c0174ff0 t filt_fifowrite
 
 Is this it?
 
 BTW, the mother board is a TYAN Tiger, and the SMP code reports:
 	APIC_IO: Testing 8254 interrupt delivery
 	APIC_IO: Broken MP table detected: 8254 is not connected to IOAPIC #0 intpin 2
 	APIC_IO: routing 8254 via 8259 and IOAPIC #0 intpin 0
 
 Not sure how relevant this is, though...
 
 = >= >	Ultimately, I'd like to be able to mount devfs as /dev, so I can
 = >= >	mount the / as read-only.
 = > 
 = >= Uhm, you need to be much more specific here...
 = >
 = >Well, it seems,  that the only thing, that prevents  me from having a
 = >read-only /  is the  stuff in  /dev. For example,  sshd will  want to
 = >chown the tty to me when I login an close the session if it can not.
 =
 = Have you tried  enabling DEVFS in your kernel ?  It will automagically
 = mount on /dev...
 
 You mean this:
 	devfs on dummy_mount (devfs, local)
 ? No, that's not it :(
 	mount -u -oro /
 says "device busy" even though ``fstat /'' only shows the r-entries (the
 pre-last column titled R/W).
 
 If I force it with
 	mount -u -f -oro /
 it succeeds, but ssh-ing does not work any more:
 	sshd[531]: fatal: chown(/dev/ttyp1, 105, 4) failed: Read-only file system
 
 	-mi
 
 

From: Poul-Henning Kamp <phk@critter.freebsd.dk>
To: mi@aldan.algebra.com
Cc: FreeBSD-gnats-submit@FreeBSD.ORG, julian@FreeBSD.ORG,
	jkh@FreeBSD.ORG
Subject: Re: kern/26466: devfs panics 
Date: Tue, 10 Apr 2001 09:10:05 +0200

 In message <200104092206.f39M6FC17272@misha.privatelabs.com>, mi@aldan.algebra.
 com writes:
 
 >You mean this:
 >	devfs on dummy_mount (devfs, local)
 
 If you are using DEVFS in -stable, you are in for some (more)
 serious trouble.
 
 It basically doesn't work.
 
 --
 Poul-Henning Kamp       | UNIX since Zilog Zeus 3.20
 phk@FreeBSD.ORG         | TCP/IP since RFC 956
 FreeBSD committer       | BSD since 4.3-tahoe    
 Never attribute to malice what can adequately be explained by incompetence.

From: Mikhail Teterin <mi@aldan.algebra.com>
To: phk@critter.freebsd.dk
Cc: FreeBSD-gnats-submit@FreeBSD.ORG, julian@FreeBSD.ORG,
	jkh@FreeBSD.ORG
Subject: Re: kern/26466: devfs panics 
Date: Tue, 10 Apr 2001 09:57:54 -0400 (EDT)

 On 10 Apr, Poul-Henning Kamp wrote:
 > In message <200104092206.f39M6FC17272@misha.privatelabs.com>, mi@aldan.algebra.
 > com writes:
 > 
 >>You mean this:
 >>	devfs on dummy_mount (devfs, local)
 > 
 > If you are using DEVFS in -stable, you are in for some (more)
 > serious trouble.
 > 
 > It basically doesn't work.
 
 Well, this comment should go (back) into LINT then. I remember there
 being troubles with devfs and avoided it until now... I was hoping it
 would help me solve the problem I described. May be, the PR will bring
 it one step closer to working...
 
 	-mi
 
State-Changed-From-To: open->feedback 
State-Changed-By: mjacob 
State-Changed-When: Mon Oct 1 22:03:36 PDT 2001 
State-Changed-Why:  
Needs feedback. It seems to me that this must be for the 
now deprecated older devfs, if for that at all. 

http://www.FreeBSD.org/cgi/query-pr.cgi?pr=26466 
State-Changed-From-To: feedback->closed 
State-Changed-By: phk 
State-Changed-When: Tue Oct 2 00:52:28 PDT 2001 
State-Changed-Why:  
This is for the old and non-functional DEVFS. 

It has already been removed from LINT. 


http://www.FreeBSD.org/cgi/query-pr.cgi?pr=26466 
>Unformatted:
