1.1.92 kernel: What does this message mean?

1.1.92 kernel: What does this message mean?

Post by Denby Won » Fri, 17 Feb 1995 23:55:23



Hi,

I've been trying out the 1.1.92 kernel patch. All seems well
functionally (though the set up here is very vanilla). I noticed that the
following message occurs very frequently.

Feb 16 09:34:30 lowry kernel: TIOCLINUX (0/8/9) ioctl is gone - use /dev/vcs
Feb 16 09:34:30 lowry kernel: TIOCLINUX (0/8/9) ioctl is gone - use /dev/vcs
Feb 16 09:42:17 lowry kernel: TIOCLINUX (0/8/9) ioctl is gone - use /dev/vcs

What does this mean?  Where does it come from?  Do I need to be
concerned about it (no functional problems so far).

Thanks,
--
Denby Wong

 
 
 

1.1.92 kernel: What does this message mean?

Post by Jon Thackr » Sat, 18 Feb 1995 06:42:23


Quote:Denby Wong writes:
>Feb 16 09:42:17 lowry kernel: TIOCLINUX (0/8/9) ioctl is gone - use /dev/vcs

>What does this mean?  Where does it come from?  Do I need to be
>concerned about it (no functional problems so far).

From /usr/src/linux/drivers/char/vc_screen.c of 1.1.92:

/*
 * Provide access to virtual console memory.
 * /dev/vcs0: the screen as it is being viewed right now (possibly scrolled)
 * /dev/vcsN: the screen of /dev/ttyN (1 <= N <= 63)
 *            [minor: N]
 *
 * /dev/vcsaN: idem, but including attributes, and prefixed with
 *      the 4 bytes lines,columns,x,y (as screendump used to give)
 *            [minor: N+128]
 *
 * This replaces screendump and part of selection, so that the system
 * administrator can control access using file system permissions.
 *

 */

So:
      mknod /dev/vcs[0-63]  c 7 [0-63]
      mknod /dev/vcsa[0-63] c 7 [128-191]

for the number of VC's you plan to support.

Cheers,
Jon.
--



 
 
 

1.1.92 kernel: What does this message mean?

Post by Jim Van Zan » Sat, 18 Feb 1995 02:09:25



Quote:

>Feb 16 09:34:30 lowry kernel: TIOCLINUX (0/8/9) ioctl is gone - use /dev/vcs

>What does this mean?

grep for the message text, or just for TIOCLINUX, in
linux/drivers/char.  I'll bet the comments will tell you that some of
the ioctl's are deprecated, and the message is telling you that some
application is using those deprecated ioctl's.

Why didn't the message include the process number of the offending
application?

                           - Jim Van Zandt

 
 
 

1.1.92 kernel: What does this message mean?

Post by Jason B. Faultle » Sun, 19 Feb 1995 06:02:34



: Denby Wong writes:

: >What does this mean?  Where does it come from?  Do I need to be

: From /usr/src/linux/drivers/char/vc_screen.c of 1.1.92:
:  * This replaces screendump and part of selection, so that the system
:  * administrator can control access using file system permissions.

Very good for an alleged code freeze, don't you think :)

--
---------------------------------------------------------------------------

---------------------------------------------------------------------------

 
 
 

1.1.92 kernel: What does this message mean?

Post by Andries Brouw » Sun, 19 Feb 1995 18:58:11



: Denby Wong writes:

:: Feb 16 09:42:17 lowry kernel: TIOCLINUX (0/8/9) ioctl is gone - use /dev/vcs
::
:: What does this mean?  Where does it come from?  Do I need to be
:: concerned about it (no functional problems so far).

: From /usr/src/linux/drivers/char/vc_screen.c of 1.1.92:

: /*
:  * Provide access to virtual console memory.
:  * /dev/vcs0: the screen as it is being viewed right now (possibly scrolled)
:  * /dev/vcsN: the screen of /dev/ttyN (1 <= N <= 63)
:  *            [minor: N]
:  *
:  * /dev/vcsaN: idem, but including attributes, and prefixed with
:  *      the 4 bytes lines,columns,x,y (as screendump used to give)
:  *            [minor: N+128]
:  *
:  * This replaces screendump and part of selection, so that the system
:  * administrator can control access using file system permissions.
:  *

:  */

: So:
:       mknod /dev/vcs[0-63]  c 7 [0-63]
:       mknod /dev/vcsa[0-63] c 7 [128-191]

: for the number of VC's you plan to support.

Yes. Maybe I should provide a small replacement screendump utility,
as long as the updated setterm is not out yet. Keeping with standard
Unix conventions, it writes to stdout, not to a file "screen.dump".

------------------ cut here ------------------------------------------
/*
 * screendump.c - aeb 950214
 *
 * Call: "screendump N" when the screen of /dev/ttyN has to be dumped
 *
 * On Linux up to 1.1.91 there is an ioctl that will do the dumping.
 * Because of problems with security this has been scrapped.
 * From 1.1.92 on, make devices "virtual console screen" and
 * "virtual console screen with attributes" by (fill in the ellipses):
 *      cd /dev
 *      for i in 0 1 2 3 ...; do
 *              mknod vcs$i c 7 $i
 *              mknod vcsa$i c 7 `expr 128 + $i`
 *      done
 * and give them your favourite owners and permissions.
 */
#include <stdio.h>
#include <linux/termios.h>
extern char *malloc();

main(int argc, char **argv) {
    int cons = 0;
    char infile[20];
    unsigned char header[4];
    unsigned int rows, cols;
    int fd, i, j;
    char *inbuf, *outbuf, *p, *q;

    if (argc == 2)
      cons = atoi(argv[1]);

    sprintf(infile, "/dev/vcsa%d", cons);
    fd = open(infile, 0);
    if (fd < 0 || read(fd, header, 4) != 4)
      goto try_ioctl;
    rows = header[0];
    cols = header[1];
    if (rows * cols == 0)
      goto try_ioctl;
    inbuf = malloc(rows*cols*2);
    outbuf = malloc(rows*(cols+1));
    if(!inbuf || !outbuf) {
        fprintf(stderr, "Out of memory?\n");
        exit(1);
    }
    if (read(fd, inbuf, rows*cols*2) != rows*cols*2) {
        fprintf(stderr, "Error reading %s\n", infile);
        exit(1);
    }
    p = inbuf;
    q = outbuf;
    for(i=0; i<rows; i++) {
        for(j=0; j<cols; j++) {
            *q++ = *p;
            p += 2;
        }
        while(j-- > 0 && q[-1] == ' ')
          q--;
        *q++ = '\n';
    }
    goto done;

try_ioctl:
    {
        /* bug in the old ioctl: there is no way to guess
           the size of its output */
#define NUM_COLS 200
#define NUM_ROWS 100
        unsigned char screenbuf[2 + NUM_ROWS*NUM_COLS];
        screenbuf[0] = 0;
        screenbuf[1] = (unsigned char) cons;
        if (ioctl(0,TIOCLINUX,screenbuf) < 0) {
            fprintf(stderr,"couldn't read %s, and cannot ioctl dump\n",
                    infile);
            exit(1);
        }
        rows = screenbuf[0];
        cols = screenbuf[1];
        outbuf = malloc(rows*(cols+1));
        if(!outbuf) {
            fprintf(stderr, "Out of memory?\n");
            exit(1);
        }
        p = screenbuf + 2;
        q = outbuf;
        for (i=0; i<rows; i++) {
            for (j=0; j<cols; j++)
              *q++ = *p++;
            while (j-- > 0 && (q[-1] == ' '))
              q--;
            *q++ = '\n';
        }
    }
done:
    if (write(1, outbuf, q-outbuf) != q-outbuf) {
        fprintf(stderr, "Error writing screendump\n");
        exit(1);
    }
    return;

Quote:}

 
 
 

1.1.92 kernel: What does this message mean?

Post by Peter Berg » Mon, 20 Feb 1995 01:05:01


 > From /usr/src/linux/drivers/char/vc_screen.c of 1.1.92:
 > [...]

 > So:
 >       mknod /dev/vcs[0-63]  c 7 [0-63]
 >       mknod /dev/vcsa[0-63] c 7 [128-191]

 > for the number of VC's you plan to support.

Thanks for telling in advance.. - what a service! ;-)

Compilation of 1.1.92 ist not yet finished.. - left to look where the
stuff of uni*437 has gone..

bye,
    Peter

 
 
 

1.1.92 kernel: What does this message mean?

Post by Martin v. Loew » Mon, 20 Feb 1995 07:19:33




Quote:>Hi,

>I've been trying out the 1.1.92 kernel patch. All seems well
>functionally (though the set up here is very vanilla). I noticed that the
>following message occurs very frequently.

>Feb 16 09:34:30 lowry kernel: TIOCLINUX (0/8/9) ioctl is gone - use /dev/vcs
>Feb 16 09:34:30 lowry kernel: TIOCLINUX (0/8/9) ioctl is gone - use /dev/vcs
>Feb 16 09:42:17 lowry kernel: TIOCLINUX (0/8/9) ioctl is gone - use /dev/vcs

>What does this mean?  Where does it come from?  Do I need to be
>concerned about it (no functional problems so far).

As I understand it, these ioctls were used for direct access to the video
memory (e.g. for screen dumps), which is now done by a special device vcs,
major number 7. selection is probably the tool that tried the invalid
access.

Enjoy,
Martin

 
 
 

1. Kernel 1.1.89 & 1.1.92 ptrace vs 1.0.9 and ups debugger

I recently upgraded (on 1.0.9) to gcc 2.6.2 and libc 4.6.27 and then
upgraded to kernel 1.1.89. The ups debugger worked until the 1.1.89
upgrade. Further kernel upgrading (directly) to 1.1.92 still displays
the ups crash. I get the crash in all three of: 1) my original X11R5
version I compiled myself (with Linux patches), 2) the very new X11R6
binary from sunsite.unc.edu, and 3) from my own compile of the sources
yesterday (with -O and with -g).

Using gdb to watch ups execute while it was debugging lead me to find
the problem is when ups attempts to get a stack backtrace (in routine
build_stack_trace() in file ups/stack.c). Here's what i found

        For some number of single source line steps through the code
        build_stack_trace() follows the "fp" (REG_FP) as
        fp=3221224232 --> fp=3221223744 --> fp=0
        and all is fine as fp==0 is a backtrace termination condition.
        However, after about 5 steps (it is reproducable**), things change:
        fp=3221224232 --> fp=3221223744 --> fp=137221
        and all backtrace hell follows.
        The problem happens on both C and f2c executables. I was able
        to make things work with C executables by changing the Linux
        specific code in build_stack_trace() where it tests for the
        backtraced function name being "_entry" to testing for
        "__crt_dummy__". I also found I could fix the f2c code by
        adding an additional test for the backtraced function name
        being "main".

** Its so reproducable, that lets say the problem is seen after 5 steps.
If I then use ups to delete the debugged image and start a new one,
the stack trace goes fine 5 steps, then bad. This can be reproduced
over and over so it doesn't sound like a corruption of ups' data
structures (since ups is never exited and restarted).

Booting 1.0.9 and using ups works fine with NO "fixes" necessary. But
under 1.1.89 and 1.1.92, the stack backtrace won't terminate with fp==0.
Using gdb I found the the problem is that "dread()" is the routine
that all of a sudden starts returning fp=137221 instead of 0 when
given 3221223744 (yes, I know these are specific to my executable, I'm
just using specific numbers for clarity). dread() bottoms out calling
ptrace() for the 8 bytes at addr = fp. This, combined with the fact that
it works under 1.0.9 and not under 1.1.89 and 1.1.92 makes me wonder if
something has changed (maybe a subtle bug introduced) into the newer
kernels?

Has anybody else seen anything like this?

                                                Hal Brand

2. network backup

3. FTAPE 2.02 with Kernel 1.1.92....

4. no root login through modem

5. Kernel change summary 1.1.91 -> 1.1.92

6. Error 0x09

7. Help: AT1700TB, Kernel 1.1.92

8. Adminsuite User Manager: NIS+ credential problem

9. Compiler error with 1.1.92+ kernel

10. ftape 2.02 and kernel 1.1.92

11. Ftape 2.02 and kernel 1.1.92

12. Kernel change summary 1.1.92 -> 1.1.93

13. 1.1.92 kernel error on ifconfig