Re: Today's kernel crashes on starting X
In message pine.bsf.3.95.990514121818.24898a-100...@current1.whistle.com, Julian Elischer writes: On Fri, 14 May 1999, Luoqi Chen wrote: This was due to a kludge in mfs implementation. Try change NUMCDEV in kern_conf.c to 255. Are you saying that there is a bug in the mfs implementation and a fix will be commited soon? (and change NUMCDEV until then) Or are you saying, the mfs implementation is now considered correct (but there are some kludges in there) and that changing NUMCDEV in kern_conf.c to 255 is the perminate fix? -- -- David(obr...@nuxi.com -or- obr...@freebsd.org) This is a fundamental problem with mfs' design, mfs steals bdev major 255 for its private use. One thing we could do is to have mfs legally acquire this major number, i.e., setup a devsw structure and register with device conf system. This problem probably would go away after we have a fully functional DEVFS. Actually this problem is the one that makes DEVFS explode.. It does an alias lookup on it's 'dummy' vnode and since teh sytem has been switched to use devfs routines for everything, some of it's assumptions are not longer true.. I don't expect the current DEVFS prototype to be indicative of how our real DEVFS will work. -- Poul-Henning Kamp FreeBSD coreteam member p...@freebsd.org Real hackers run -current on their laptop. FreeBSD -- It will take a long time before progress goes too far! To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: Today's kernel crashes on starting X
On Fri, May 14, 1999 at 02:17:28AM +0200, a little birdie told me that Sheldon Hearn remarked On Fri, 14 May 1999 01:13:36 +0200, Gianmarco Giovannelli wrote: Here it continues to panic with screen, same errors of yesterday... I'll try with X right now but I think it is the same story... :-) Cvsupped and maked world this afternoon (CEST). Well guesss what? I'm seeing panics too, after suggesting that everything was cool and froody. :-) I don't have to start X, I get a panic as soon as I try to mount_mfs -- 100% reproducible. Someone else posted a backtrace, the one that incriminates checkalias(), I think? I have one here with sources cvsup'd around 4am (CDT) today (as in, ~4 hours ago). Start X, start up screen in an xterm, and *bing*. However, I strut my skill in manpiluating DDB while staring at a frozen X session ; Here's some quickies from kgdb: Fatal trap 12: page fault while in kernel mode mp_lock = 0102; cpuid = 1; lapic.id = 0c00 fault virtual address = 0x14 fault code = supervisor read, page not present instruction pointer = 0x8:0xc0162490 stack pointer = 0x10:0xcb271d4c frame pointer = 0x10:0xcb271d60 code segment= base 0x0, limit 0xf, type 0x1b = DPL 0, pres 1, def32 1, gran 1 processor eflags= interrupt enabled, resume, IOPL = 0 current process = 570 (screen-3.7.6) interrupt mask = tty - SMP: XXX panic: from debugger mp_lock = 0103; cpuid = 1; lapic.id = 0c00 boot() called on cpu#1 (kgdb) where #0 0xc014f350 in boot () #1 0xc014f6ed in panic () #2 0xc012c899 in db_panic () #3 0xc012c839 in db_command () #4 0xc012c8fe in db_command_loop () #5 0xc012ea5f in db_trap () #6 0xc0213982 in kdb_trap () #7 0xc02265c2 in trap_fatal () #8 0xc0226259 in trap_pfault () #9 0xc0225ecf in trap () #10 0xc0162490 in ttyflush () #11 0xc0161bf1 in ttioctl () #12 0xc01650fe in ptyioctl () #13 0xc0181ad0 in spec_ioctl () #14 0xc01812f1 in spec_vnoperate () #15 0xc01f64c9 in ufs_vnoperatespec () #16 0xc017c045 in vn_ioctl () #17 0xc015b73f in ioctl () #18 0xc0226886 in syscall () #19 0xc02143a5 in Xint0x80_syscall () Unfortunately, it seems to be not giving me symbols. I'll try recompiling it with makeoptions=-g and see if I can't pull up one more good panic/dump real quick. -- *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-* | Matthew FullerMF4839http://www.over-yonder.net/ | * fulle...@futuresouth.com fulle...@over-yonder.net * | UNIX Systems Administrator Specializing in FreeBSD | * FutureSouth Communications ISPHelp ISP Consulting * | The only reason I'm burning my candle at both ends, | *is because I haven't figured out how to light the* | middle yet | *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-* To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: Today's kernel crashes on starting X
On Fri, 14 May 1999 07:39:29 EST, Matthew D. Fuller wrote: I have one here with sources cvsup'd around 4am (CDT) today (as in, ~4 hours ago). Start X, start up screen in an xterm, and *bing*. However, I strut my skill in manpiluating DDB while staring at a frozen X session ; Unfortunately, I'm using Soren's new ATA* driver, so I can't get crashdumps. Copying panics and backtraces is a PIAWUTA, as you can well imagine. Ciao, Sheldon. To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Panic with screen w/info (was Re: Today's kernel crashes on starting X)
Well, this apparently doesn't involve X, only screen.
(X may still be broken/flaky, but this doesn't involve it specifically)
This time I just ran screen on a vty, and *poof*
--
Looking at the trace below, does this look like a (if not the) problem?
#10 0xc0162490 in ttyflush (tp=0xc029dc20, rw=3) at ../../kern/tty.c:1192
1192(*devsw(tp-t_dev)-d_stop)(tp, rw);
(kgdb) print tp
$1 = (struct tty *) 0xc30010b2
(kgdb) print tp-t_dev
Cannot access memory at address 0xc300110a.
--
I can keep this trace and compile tree around for a good while, just let
me know what to poke at and I'll prod it. Panic msg and trace below.
--
Fatal trap 12: page fault while in kernel mode
mp_lock = 0102; cpuid = 1; lapic.id = 0c00
fault virtual address = 0x14
fault code = supervisor read, page not present
instruction pointer = 0x8:0xc0162490
stack pointer = 0x10:0xcb1c9d4c
frame pointer = 0x10:0xcb1c9d60
code segment= base 0x0, limit 0xf, type 0x1b
= DPL 0, pres 1, def32 1, gran 1
processor eflags= interrupt enabled, resume, IOPL = 0
current process = 372 (screen-3.7.6)
interrupt mask = tty - SMP: XXX
panic: from debugger
mp_lock = 0103; cpuid = 1; lapic.id = 0c00
boot() called on cpu#1
#0 boot (howto=256) at ../../kern/kern_shutdown.c:288
#1 0xc014f6ed in panic (fmt=0xc0253514 from debugger) at
../../kern/kern_shutdown.c:451
#2 0xc012c899 in db_panic (addr=-1072290672, have_addr=0, count=-1,
modif=0xcb1c9bc8 )
at ../../ddb/db_command.c:434
#3 0xc012c839 in db_command (last_cmdp=0xc027e870, cmd_table=0xc027e6d0,
aux_cmd_tablep=0xc029ac78) at ../../ddb/db_command.c:334
#4 0xc012c8fe in db_command_loop () at ../../ddb/db_command.c:456
#5 0xc012ea5f in db_trap (type=12, code=0) at ../../ddb/db_trap.c:71
#6 0xc0213982 in kdb_trap (type=12, code=0, regs=0xcb1c9d0c)
at ../../i386/i386/db_interface.c:157
#7 0xc02265c2 in trap_fatal (frame=0xcb1c9d0c, eva=20) at
../../i386/i386/trap.c:912
#8 0xc0226259 in trap_pfault (frame=0xcb1c9d0c, usermode=0, eva=20)
at ../../i386/i386/trap.c:810
#9 0xc0225ecf in trap (frame={tf_fs = -2147483624, tf_es = -1054801904,
tf_ds = 16777232,
tf_edi = -2147483648, tf_esi = 3, tf_ebp = -887317152, tf_isp =
-887317192,
tf_ebx = -1070998496, tf_edx = 0, tf_ecx = 16777217, tf_eax = 0,
tf_trapno = 12,
tf_err = 0, tf_eip = -1072290672, tf_cs = 8, tf_eflags = 66178,
tf_esp = -1070998496,
tf_ss = 3}) at ../../i386/i386/trap.c:436
#10 0xc0162490 in ttyflush (tp=0xc029dc20, rw=3) at ../../kern/tty.c:1192
#11 0xc0161bf1 in ttioctl (tp=0xc029dc20, cmd=2147775504,
data=0xcb1c9ecc, flag=3)
at ../../kern/tty.c:803
#12 0xc01650fe in ptyioctl (dev=0xf700, cmd=2147775504, data=0xcb1c9ecc
\003, flag=3,
p=0xc9d9ea20) at ../../kern/tty_pty.c:740
#13 0xc0181ad0 in spec_ioctl (ap=0xcb1c9e08) at
../../miscfs/specfs/spec_vnops.c:441
#14 0xc01812f1 in spec_vnoperate (ap=0xcb1c9e08) at
../../miscfs/specfs/spec_vnops.c:129
#15 0xc01f64c9 in ufs_vnoperatespec (ap=0xcb1c9e08) at
../../ufs/ufs/ufs_vnops.c:2327
#16 0xc017c045 in vn_ioctl (fp=0xc1196bc0, com=2147775504,
data=0xcb1c9ecc \003,
p=0xc9d9ea20) at vnode_if.h:395
#17 0xc015b73f in ioctl (p=0xc9d9ea20, uap=0xcb1c9f80) at
../../kern/sys_generic.c:564
#18 0xc0226886 in syscall (frame={tf_fs = 47, tf_es = 47, tf_ds = 47,
tf_edi = 134697096,
tf_esi = 134672224, tf_ebp = -1077951692, tf_isp = -887316524,
tf_ebx = 672221300,
tf_edx = 134697128, tf_ecx = 6, tf_eax = 54, tf_trapno = 12, tf_err
= 2,
tf_eip = 671965400, tf_cs = 31, tf_eflags = 582, tf_esp =
-1077951716, tf_ss = 47})
at ../../i386/i386/trap.c:1066
#19 0xc02143a5 in Xint0x80_syscall ()
--
--
*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*
| Matthew FullerMF4839http://www.over-yonder.net/ |
* fulle...@futuresouth.com fulle...@over-yonder.net *
| UNIX Systems Administrator Specializing in FreeBSD |
* FutureSouth Communications ISPHelp ISP Consulting *
| The only reason I'm burning my candle at both ends, |
*is because I haven't figured out how to light the*
| middle yet |
*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*
To Unsubscribe: send mail to majord...@freebsd.org
with unsubscribe freebsd-current in the body of the message
Re: Today's kernel crashes on starting X
Ilya Naumov ca...@avias.com writes: GR I'm currently running into a problem, that when I start my system, GR it spontaneously reboots when starting X. Has anyone else run into GR this? yes, i'm experiencing the same problem with today's (May, 12) kernels. Me three. The box freezes solid before switching to graphics mode. Didn't have time to grab relevant info as this is my home box and I was late for work. DES -- Dag-Erling Smorgrav - d...@flood.ping.uio.no To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: Panic with screen w/info (was Re: Today's kernel crashes on starting X)
It seems that screen was trying to flush the master pty, before the slave tty was even open. We were lucky that this didn't crash our machines before the dev_t changes, it only caused the console to be flushed instead. But after the dev_t changes, it is fatal. Try this fix (band-aid only, better fix should involve checking of TS_OPEN bit), Index: tty_pty.c === RCS file: /home/ncvs/src/sys/kern/tty_pty.c,v retrieving revision 1.57 diff -u -r1.57 tty_pty.c --- tty_pty.c 1999/05/08 06:39:43 1.57 +++ tty_pty.c 1999/05/14 16:51:58 @@ -336,6 +336,7 @@ tp = pt_tty[minor(dev)]; if (tp-t_oproc) return (EIO); + tp-t_dev = dev; tp-t_oproc = ptsstart; #ifdef sun4c tp-t_stop = ptsstop; -lq To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: Panic with screen w/info (was Re: Today's kernel crashes on starting X)
This looks a lot like the I didn't use 'config -r' to generate my
latest kernel build tree problem.
Well, this apparently doesn't involve X, only screen.
(X may still be broken/flaky, but this doesn't involve it specifically)
This time I just ran screen on a vty, and *poof*
--
Looking at the trace below, does this look like a (if not the) problem?
#10 0xc0162490 in ttyflush (tp=0xc029dc20, rw=3) at ../../kern/tty.c:1192
1192(*devsw(tp-t_dev)-d_stop)(tp, rw);
(kgdb) print tp
$1 = (struct tty *) 0xc30010b2
(kgdb) print tp-t_dev
Cannot access memory at address 0xc300110a.
--
I can keep this trace and compile tree around for a good while, just let
me know what to poke at and I'll prod it. Panic msg and trace below.
--
Fatal trap 12: page fault while in kernel mode
mp_lock = 0102; cpuid = 1; lapic.id = 0c00
fault virtual address = 0x14
fault code = supervisor read, page not present
instruction pointer = 0x8:0xc0162490
stack pointer = 0x10:0xcb1c9d4c
frame pointer = 0x10:0xcb1c9d60
code segment= base 0x0, limit 0xf, type 0x1b
= DPL 0, pres 1, def32 1, gran 1
processor eflags= interrupt enabled, resume, IOPL = 0
current process = 372 (screen-3.7.6)
interrupt mask = tty - SMP: XXX
panic: from debugger
mp_lock = 0103; cpuid = 1; lapic.id = 0c00
boot() called on cpu#1
#0 boot (howto=256) at ../../kern/kern_shutdown.c:288
#1 0xc014f6ed in panic (fmt=0xc0253514 from debugger) at
../../kern/kern_shutdown.c:451
#2 0xc012c899 in db_panic (addr=-1072290672, have_addr=0, count=-1,
modif=0xcb1c9bc8 )
at ../../ddb/db_command.c:434
#3 0xc012c839 in db_command (last_cmdp=0xc027e870, cmd_table=0xc027e6d0,
aux_cmd_tablep=0xc029ac78) at ../../ddb/db_command.c:334
#4 0xc012c8fe in db_command_loop () at ../../ddb/db_command.c:456
#5 0xc012ea5f in db_trap (type=12, code=0) at ../../ddb/db_trap.c:71
#6 0xc0213982 in kdb_trap (type=12, code=0, regs=0xcb1c9d0c)
at ../../i386/i386/db_interface.c:157
#7 0xc02265c2 in trap_fatal (frame=0xcb1c9d0c, eva=20) at
../../i386/i386/trap.c:912
#8 0xc0226259 in trap_pfault (frame=0xcb1c9d0c, usermode=0, eva=20)
at ../../i386/i386/trap.c:810
#9 0xc0225ecf in trap (frame={tf_fs = -2147483624, tf_es = -1054801904,
tf_ds = 16777232,
tf_edi = -2147483648, tf_esi = 3, tf_ebp = -887317152, tf_isp =
-887317192,
tf_ebx = -1070998496, tf_edx = 0, tf_ecx = 16777217, tf_eax = 0,
tf_trapno = 12,
tf_err = 0, tf_eip = -1072290672, tf_cs = 8, tf_eflags = 66178,
tf_esp = -1070998496,
tf_ss = 3}) at ../../i386/i386/trap.c:436
#10 0xc0162490 in ttyflush (tp=0xc029dc20, rw=3) at ../../kern/tty.c:1192
#11 0xc0161bf1 in ttioctl (tp=0xc029dc20, cmd=2147775504,
data=0xcb1c9ecc, flag=3)
at ../../kern/tty.c:803
#12 0xc01650fe in ptyioctl (dev=0xf700, cmd=2147775504, data=0xcb1c9ecc
\003, flag=3,
p=0xc9d9ea20) at ../../kern/tty_pty.c:740
#13 0xc0181ad0 in spec_ioctl (ap=0xcb1c9e08) at
../../miscfs/specfs/spec_vnops.c:441
#14 0xc01812f1 in spec_vnoperate (ap=0xcb1c9e08) at
../../miscfs/specfs/spec_vnops.c:129
#15 0xc01f64c9 in ufs_vnoperatespec (ap=0xcb1c9e08) at
../../ufs/ufs/ufs_vnops.c:2327
#16 0xc017c045 in vn_ioctl (fp=0xc1196bc0, com=2147775504,
data=0xcb1c9ecc \003,
p=0xc9d9ea20) at vnode_if.h:395
#17 0xc015b73f in ioctl (p=0xc9d9ea20, uap=0xcb1c9f80) at
../../kern/sys_generic.c:564
#18 0xc0226886 in syscall (frame={tf_fs = 47, tf_es = 47, tf_ds = 47,
tf_edi = 134697096,
tf_esi = 134672224, tf_ebp = -1077951692, tf_isp = -887316524,
tf_ebx = 672221300,
tf_edx = 134697128, tf_ecx = 6, tf_eax = 54, tf_trapno = 12, tf_err
= 2,
tf_eip = 671965400, tf_cs = 31, tf_eflags = 582, tf_esp =
-1077951716, tf_ss = 47})
at ../../i386/i386/trap.c:1066
#19 0xc02143a5 in Xint0x80_syscall ()
--
--
*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*
| Matthew FullerMF4839http://www.over-yonder.net/ |
* fulle...@futuresouth.com fulle...@over-yonder.net *
| UNIX Systems Administrator Specializing in FreeBSD |
* FutureSouth Communications ISPHelp ISP Consulting *
| The only reason I'm burning my candle at both ends, |
*is because I haven't figured out how to light the*
| middle yet |
*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*
To Unsubscribe: send mail to majord...@freebsd.org
with unsubscribe freebsd-current in the body of the message
--
\\ Sometimes you're ahead, \\ Mike Smith
\\ sometimes you're behind. \\ m...@smith.net.au
\\ The race is long, and in the \\ msm...@freebsd.org
\\ end it's only with yourself. \\ msm...@cdrom.com
To Unsubscribe: send mail to majord...@freebsd.org
with unsubscribe freebsd-current in the body of the message
Re: Panic with screen w/info (was Re: Today's kernel crashes on starting X)
It seems that screen was trying to flush the master pty, before the slave
tty was even open. We were lucky that this didn't crash our machines before
the dev_t changes, it only caused the console to be flushed instead. But
after the dev_t changes, it is fatal. Try this fix (band-aid only, better
fix should involve checking of TS_OPEN bit),
Here's the better fix, please let me know if it works,
Index: tty_pty.c
===
RCS file: /home/ncvs/src/sys/kern/tty_pty.c,v
retrieving revision 1.57
diff -u -r1.57 tty_pty.c
--- tty_pty.c 1999/05/08 06:39:43 1.57
+++ tty_pty.c 1999/05/14 17:32:33
@@ -674,8 +674,7 @@
tp-t_lflag = ~EXTPROC;
}
return(0);
- } else
- if (devsw(dev)-d_open == ptcopen)
+ } else if (devsw(dev)-d_open == ptcopen) {
switch (cmd) {
case TIOCGPGRP:
@@ -711,7 +710,16 @@
pti-pt_flags = ~PF_REMOTE;
ttyflush(tp, FREAD|FWRITE);
return (0);
+ }
+
+ /*
+* The rest of the ioctls shouldn't be called until
+* the slave is open. (Should we return an error?)
+*/
+ if ((tp-t_state TS_ISOPEN) == 0)
+ return (0);
+ switch (cmd) {
#ifdef COMPAT_43
case TIOCSETP:
case TIOCSETN:
@@ -735,6 +743,7 @@
ttyinfo(tp);
return(0);
}
+ }
error = (*linesw[tp-t_line].l_ioctl)(tp, cmd, data, flag, p);
if (error == ENOIOCTL)
error = ttioctl(tp, cmd, data, flag);
-lq
To Unsubscribe: send mail to majord...@freebsd.org
with unsubscribe freebsd-current in the body of the message
Re: Today's kernel crashes on starting X
This was due to a kludge in mfs implementation. Try change NUMCDEV in kern_conf.c to 255. Are you saying that there is a bug in the mfs implementation and a fix will be commited soon? (and change NUMCDEV until then) Or are you saying, the mfs implementation is now considered correct (but there are some kludges in there) and that changing NUMCDEV in kern_conf.c to 255 is the perminate fix? -- -- David(obr...@nuxi.com -or- obr...@freebsd.org) This is a fundamental problem with mfs' design, mfs steals bdev major 255 for its private use. One thing we could do is to have mfs legally acquire this major number, i.e., setup a devsw structure and register with device conf system. This problem probably would go away after we have a fully functional DEVFS. -lq To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: Today's kernel crashes on starting X
In message 199905141824.oaa06...@lor.watermarkgroup.com, Luoqi Chen writes: This was due to a kludge in mfs implementation. Try change NUMCDEV in kern_conf.c to 255. Are you saying that there is a bug in the mfs implementation and a fix will be commited soon? (and change NUMCDEV until then) Or are you saying, the mfs implementation is now considered correct (but there are some kludges in there) and that changing NUMCDEV in kern_conf.c to 255 is the perminate fix? -- -- David(obr...@nuxi.com -or- obr...@freebsd.org) This is a fundamental problem with mfs' design, mfs steals bdev major 255 for its private use. One thing we could do is to have mfs legally acquire this major number, i.e., setup a devsw structure and register with device conf system. This problem probably would go away after we have a fully functional DEVFS. I would prefer if somebody would make MFS register a devsw* entry now, because that would also work if/when DEVFS comes to town... -- Poul-Henning Kamp FreeBSD coreteam member p...@freebsd.org Real hackers run -current on their laptop. FreeBSD -- It will take a long time before progress goes too far! To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: Panic with screen w/info (was Re: Today's kernel crashes on starting X)
On Fri, May 14, 1999 at 01:36:41PM -0400, a little birdie told me
that Luoqi Chen remarked
Here's the better fix, please let me know if it works,
I won't be in a position to crash this box again until tomorrow, but I'll
give it a whirl then.
Thanks.
Index: tty_pty.c
===
RCS file: /home/ncvs/src/sys/kern/tty_pty.c,v
retrieving revision 1.57
diff -u -r1.57 tty_pty.c
--- tty_pty.c 1999/05/08 06:39:43 1.57
+++ tty_pty.c 1999/05/14 17:32:33
@@ -674,8 +674,7 @@
tp-t_lflag = ~EXTPROC;
}
return(0);
- } else
- if (devsw(dev)-d_open == ptcopen)
+ } else if (devsw(dev)-d_open == ptcopen) {
switch (cmd) {
case TIOCGPGRP:
@@ -711,7 +710,16 @@
pti-pt_flags = ~PF_REMOTE;
ttyflush(tp, FREAD|FWRITE);
return (0);
+ }
+
+ /*
+ * The rest of the ioctls shouldn't be called until
+ * the slave is open. (Should we return an error?)
+ */
+ if ((tp-t_state TS_ISOPEN) == 0)
+ return (0);
+ switch (cmd) {
#ifdef COMPAT_43
case TIOCSETP:
case TIOCSETN:
@@ -735,6 +743,7 @@
ttyinfo(tp);
return(0);
}
+ }
error = (*linesw[tp-t_line].l_ioctl)(tp, cmd, data, flag, p);
if (error == ENOIOCTL)
error = ttioctl(tp, cmd, data, flag);
--
*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*
| Matthew FullerMF4839http://www.over-yonder.net/ |
* fulle...@futuresouth.com fulle...@over-yonder.net *
| UNIX Systems Administrator Specializing in FreeBSD |
* FutureSouth Communications ISPHelp ISP Consulting *
| The only reason I'm burning my candle at both ends, |
*is because I haven't figured out how to light the*
| middle yet |
*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*
To Unsubscribe: send mail to majord...@freebsd.org
with unsubscribe freebsd-current in the body of the message
Re: Today's kernel crashes on starting X
On Fri, 14 May 1999, Luoqi Chen wrote: This was due to a kludge in mfs implementation. Try change NUMCDEV in kern_conf.c to 255. Are you saying that there is a bug in the mfs implementation and a fix will be commited soon? (and change NUMCDEV until then) Or are you saying, the mfs implementation is now considered correct (but there are some kludges in there) and that changing NUMCDEV in kern_conf.c to 255 is the perminate fix? -- -- David(obr...@nuxi.com -or- obr...@freebsd.org) This is a fundamental problem with mfs' design, mfs steals bdev major 255 for its private use. One thing we could do is to have mfs legally acquire this major number, i.e., setup a devsw structure and register with device conf system. This problem probably would go away after we have a fully functional DEVFS. Actually this problem is the one that makes DEVFS explode.. It does an alias lookup on it's 'dummy' vnode and since teh sytem has been switched to use devfs routines for everything, some of it's assumptions are not longer true.. -lq To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: Today's kernel crashes on starting X
On Wed, 12 May 1999, Geoff Rehmet wrote: Date: Wed, 12 May 1999 14:35:54 +0200 From: Geoff Rehmet geo...@is.co.za To: 'curr...@freebsd.org' curr...@freebsd.org Subject: Today's kernel crashes on starting X I'm currently running into a problem, that when I start my system, it spontaneously reboots when starting X. Has anyone else run into this? -- Geoff Rehmet, The Internet Solution - Infrastructure tel: +27-11-283-5462, fax: +27-11-283-5401 mobile: +27-83-292-5800 email: geo...@is.co.za URL: http://www.is.co.za To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message I think it's the recent dev_t changes causing problems. I haven't tracked it any further. Try changing: #define DEVT_FACIST 1 in kern/kern_conf.c to #undef DEVT_FACIST It has fixed my X crash. dave adkins To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: Today's kernel crashes on starting X
On Wed, 12 May 1999 14:35:54 +0200, Geoff Rehmet wrote: I'm currently running into a problem, that when I start my system, it spontaneously reboots when starting X. Has anyone else run into this? Hi Geoff, I notice you've had a lot of responses confirming similar problems with recent kernels, so I thought the following might be useful to you. I used sources supped around 07H00 GMT 12/05/99 and have not seen the problem you describe. Therefore, you'll probably need to provide more details on your kernel configuration. You may also want to look for clues in /etc/messages and .xsession-errors etc. Perhaps you'll be able to find something that you have in common with the other folks having hassles. Later, Sheldon. To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: Today's kernel crashes on starting X
I think the fix to the device-pager earlier today may have take care of this one (Many thanks to luoqi!) Poul-Henning In message 67290.926593...@axl.noc.iafrica.com, Sheldon Hearn writes: On Wed, 12 May 1999 14:35:54 +0200, Geoff Rehmet wrote: I'm currently running into a problem, that when I start my system, it spontaneously reboots when starting X. Has anyone else run into this? Hi Geoff, I notice you've had a lot of responses confirming similar problems with recent kernels, so I thought the following might be useful to you. I used sources supped around 07H00 GMT 12/05/99 and have not seen the problem you describe. Therefore, you'll probably need to provide more details on your kernel configuration. You may also want to look for clues in /etc/messages and .xsession-errors etc. Perhaps you'll be able to find something that you have in common with the other folks having hassles. Later, Sheldon. To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message -- Poul-Henning Kamp FreeBSD coreteam member p...@freebsd.org Real hackers run -current on their laptop. FreeBSD -- It will take a long time before progress goes too far! To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: Today's kernel crashes on starting X
At 13/05/99, Poul-Henning Kamp wrote: I think the fix to the device-pager earlier today may have take care of this one (Many thanks to luoqi!) Here it continues to panic with screen, same errors of yesterday... I'll try with X right now but I think it is the same story... :-) Cvsupped and maked world this afternoon (CEST). Best Regards, Gianmarco Giovannelli , Unix expert since yesterday http://www.giovannelli.it/~gmarco http://www2.masternet.it To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: Today's kernel crashes on starting X
On Fri, 14 May 1999 01:13:36 +0200, Gianmarco Giovannelli wrote: Here it continues to panic with screen, same errors of yesterday... I'll try with X right now but I think it is the same story... :-) Cvsupped and maked world this afternoon (CEST). Well guesss what? I'm seeing panics too, after suggesting that everything was cool and froody. :-) I don't have to start X, I get a panic as soon as I try to mount_mfs -- 100% reproducible. Someone else posted a backtrace, the one that incriminates checkalias(), I think? Ciao, Sheldon. To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: Today's kernel crashes on starting X
On Thu, May 13, 1999 at 05:25:54AM -0500, dave adkins wrote: I think it's the recent dev_t changes causing problems. I haven't tracked it any further. Try changing: #define DEVT_FACIST 1 in kern/kern_conf.c to #undef DEVT_FACIST It has fixed my X crash. dave adkins This also fixes the panic that I got with mfs_mount: (with options MFS in the config file, 'cvsup'ed at May 13th 19:43 UTC) Fatal trap 12: page fault while inkernel mode fault virtual address = 0x9d19fd34 fault code = supervisor read, page not present instruction pointer = 0x8:0xc016f7a0 stack pointer = 0x10:0xc494cd68 frame pointer = 0x10:0xc494cd94 code segment= base 0x0, limit 0xf, type 0x1b = DPL 0, Rres 1,def 32 1, gran 1 processor eflags= interrupt enabled, resume, IOPL=0 current process = 38 (mount_mfs) interrupt mask = kernel: type 12 trap, code: 0 stopped at checkalias+0x150:movl cdevsw(%eax), %edx db trace checkalias(c4478980, ff00, 0) at checkalias+0x150 mfs_mount(c08a3e00, bfbfde98, bfbfd7ac, c494cea0, c44804c0) at mfs_mount+0x132 mount(c44804c0, c494cf80,0,80691e0,2000) at mount+0x50e syscall(2f,2f,2f,2000,80691e0) at syscall+0x182 Xint0x80_syscall() at Xint0x80_syscall+0x30 Bye, Philipp To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: Today's kernel crashes on starting X
This also fixes the panic that I got with mfs_mount: (with options MFS in the config file, 'cvsup'ed at May 13th 19:43 UTC) Fatal trap 12: page fault while inkernel mode fault virtual address = 0x9d19fd34 fault code= supervisor read, page not present instruction pointer = 0x8:0xc016f7a0 stack pointer = 0x10:0xc494cd68 frame pointer = 0x10:0xc494cd94 code segment = base 0x0, limit 0xf, type 0x1b = DPL 0, Rres 1,def 32 1, gran 1 processor eflags = interrupt enabled, resume, IOPL=0 current process = 38 (mount_mfs) interrupt mask= kernel: type 12 trap, code: 0 stopped at checkalias+0x150: movl cdevsw(%eax), %edx db trace checkalias(c4478980, ff00, 0) at checkalias+0x150 mfs_mount(c08a3e00, bfbfde98, bfbfd7ac, c494cea0, c44804c0) at mfs_mount+0x132 mount(c44804c0, c494cf80,0,80691e0,2000) at mount+0x50e syscall(2f,2f,2f,2000,80691e0) at syscall+0x182 Xint0x80_syscall() at Xint0x80_syscall+0x30 Bye, Philipp This was due to a kludge in mfs implementation. Try change NUMCDEV in kern_conf.c to 255. -lq To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: Today's kernel crashes on starting X
On Thu, May 13, 1999 at 10:17:23PM -0400, Luoqi Chen wrote: This also fixes the panic that I got with mfs_mount: (with options MFS in the config file, 'cvsup'ed at May 13th 19:43 UTC) ..snip.. This was due to a kludge in mfs implementation. Try change NUMCDEV in kern_conf.c to 255. Are you saying that there is a bug in the mfs implementation and a fix will be commited soon? (and change NUMCDEV until then) Or are you saying, the mfs implementation is now considered correct (but there are some kludges in there) and that changing NUMCDEV in kern_conf.c to 255 is the perminate fix? -- -- David(obr...@nuxi.com -or- obr...@freebsd.org) To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: Today's kernel crashes on starting X
This also fixes the panic that I got with mfs_mount: (with options MFS in the config file, 'cvsup'ed at May 13th 19:43 UTC) Fatal trap 12: page fault while inkernel mode fault virtual address = 0x9d19fd34 fault code = supervisor read, page not present instruction pointer = 0x8:0xc016f7a0 [...] current process = 38 (mount_mfs) [...] db trace checkalias(c4478980, ff00, 0) at checkalias+0x150 mfs_mount(c08a3e00, bfbfde98, bfbfd7ac, c494cea0, c44804c0) at mfs_mount+0x132 mount(c44804c0, c494cf80,0,80691e0,2000) at mount+0x50e This was due to a kludge in mfs implementation. Try change NUMCDEV in kern_conf.c to 255. -lq Ok, with this fix MFS works (with #define DEVT_FASCIST 1 in kern_conf.c). Bye, Philipp To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: Today's kernel crashes on starting X
At 02:35 PM 5/12/99 +0200, Geoff Rehmet wrote: I'm currently running into a problem, that when I start my system, it spontaneously reboots when starting X. Has anyone else run into this? I had the same thing happen last night, after building a new kernel and rebooting. I had to go back to a kernel made yesterday morning to get a working machine. No debugger or anything just automatic reboot. INTEL PR440FX motherboard SMP with DPT controller Manfred = ||man...@pacbell.net || ||Ph. (415) 681-6235|| = To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: Today's kernel crashes on starting X
At 12/05/99, Manfred Antar wrote: At 02:35 PM 5/12/99 +0200, Geoff Rehmet wrote: I'm currently running into a problem, that when I start my system, it spontaneously reboots when starting X. Has anyone else run into this? I had the same thing happen last night, after building a new kernel and rebooting. I had to go back to a kernel made yesterday morning to get a working machine. No debugger or anything just automatic reboot. INTEL PR440FX motherboard SMP with DPT controller I had the same problem here also the program screen crashes happily... see my msg subj: panic ! Best Regards, Gianmarco Giovannelli , Unix expert since yesterday http://www.giovannelli.it/~gmarco http://www2.masternet.it To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: Today's kernel crashes on starting X
Hello Geoff, Wednesday, May 12, 1999, 4:35:54 PM, you wrote: GR I'm currently running into a problem, that when I start my system, GR it spontaneously reboots when starting X. Has anyone else run into GR this? yes, i'm experiencing the same problem with today's (May, 12) kernels. Best regards, Ilyamailto:ca...@avias.com To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
