Bug 26466
| Summary: | devfs panics | ||
|---|---|---|---|
| Product: | Base System | Reporter: | Mikhail Teterin <mi> |
| Component: | kern | Assignee: | freebsd-bugs (Nobody) <bugs> |
| Status: | Closed FIXED | ||
| Severity: | Affects Only Me | CC: | julian |
| Priority: | Normal | ||
| Version: | Unspecified | ||
| Hardware: | Any | ||
| OS: | Any | ||
|
Description
Mikhail Teterin
2001-04-09 21:30:01 UTC
> 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. 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 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. 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 rx0, 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 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. 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 Needs feedback. It seems to me that this must be for the now deprecated older devfs, if for that at all. State Changed From-To: feedback->closed This is for the old and non-functional DEVFS. It has already been removed from LINT. |
