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