TTY Driver Question

TTY Driver Question

Post by kentrop » Fri, 08 Nov 2002 01:39:02



The data you showed are insufficient to debug the application, where is
struct definition ?
 
 
 

TTY Driver Question

Post by H.Nestle » Sat, 09 Nov 2002 18:07:58


Hello!

Lock into driver for gerneric_serial.c and ser_a2232.c, this code have good
commends.
Using of generic_serial is veriy good for new drivers.

Henry
---------------------------------------
SSV SOFTWARE SYSTEMS GmbH
Heisterbergallee 72
D-30453 Hannover
http://www.ssv-embedded.de
Phone: +49(0)511/40 000-0
Fax:   +49(0)511/40 000-40

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


Quote:> Hi!
> Trying to write a simple tty (low-level) driver I'm now experiencing
problems
> due to lack of information about how to handle the flip buffers an stuff.

> I tried the following:

> 1) initialisation of the tty driver data structure

> memset(&mytty_driver,0,sizeof(struct tty_driver));
> mytty_driver.magic           =   TTY_DRIVER_MAGIC;
> mytty_driver.driver_name     =   "mytty";
> mytty_driver.name            =   "mytty%d";
> mytty_driver.major           =   CRUMODEM_MAJOR;
> mytty_driver.minor_start     =   CRUMODEM_MINOR_START;
> mytty_driver.num             =   CRUMODEM_NR_PORTS;
> mytty_driver.type            =   TTY_DRIVER_TYPE_SERIAL;
> mytty_driver.subtype         =   SERIAL_TYPE_NORMAL;
> mytty_driver.init_termios    =   tty_std_termios;
> mytty_driver.init_termios.c_cflag    =   B9600 | CS8 | CREAD | CLOCAL;
> mytty_driver.init_termios.c_oflag    |=  OPOST;
> mytty_driver.flags           =   TTY_DRIVER_REAL_RAW |

TTY_DRIVER_NO_DEVFS;

- Show quoted text -

Quote:> mytty_driver.refcount        =   &mytty_driver_refcount;
> mytty_driver.table           =   &mytty_driver_table;
> mytty_driver.termios         =   &mytty_driver_termios;
> mytty_driver.termios_locked  =   &mytty_driver_termios_locked;
> mytty_driver.open            =   mytty_open;
> mytty_driver.close           =   mytty_close;
> mytty_driver.write           =   NULL; // mytty_write;
> tty_register_driver(&mytty_driver);

> 2) mytty_open and mytty_close do nothing to the above data structure and
call
> no function (is this correct?)

> 3) when a char is received in an interrupt handler, the interrupt handler
does
> the following:

> (tty is the one mytty_open has been called with!)

> while (chars_left()) {
>   if (tty->flip.count >= TTY_FLIPBUF_SIZE) {
>     tty->flip.tqueue.routine((void *) tty);
>     if (tty->flip.count >= TTY_FLIPBUF_SIZE)
>       break;      // if TTY_DONT_FLIP is set
>   }
>   *tty->flip.char_buf_ptr++ = the_char;
>   *tty->flip.flag_buf_ptr++ = 0;
>   tty->flip.count++;
> }
> tty_flip_buffer_push(tty);

> NOW THE PROBLEM: the write access to the flip buffer as shown above
> seems to cause that:

> Unable to handle kernel NULL pointer dereference at virtual address
00000000
>  printing eip:
> 00000000
> *pde = 00000000
> Oops: 0000
> CPU:    0
> EIP:    0010:[<00000000>]    Not tainted
> EFLAGS: 00010292
> eax: 00000000   ebx: 00000031   ecx: c02e8000   edx: c02e8000
> esi: c02e8000   edi: 00000000   ebp: 00000004   esp: c01bde38
> ds: 0018   es: 0018   ss: 0018
> Process swapper (pid: 0, stackpage=c01bd000)
> Stack: bla bla
> Code:  Bad EIP value.
>  <0>Kernel panic: Aiee, killing interrupt handler!
> In interrupt handler - not syncing

> NOW THE QUESTIONS:
> 1. What's wrong here?
> 2. Is it true that after calling tty_register_driver() no other function
has
> to be called prior to writing to the flip buffer?
> 3. Where is this mechanism documented (besides the source code).

> Thank you very much in advance.

> Oliver


 
 
 

1. tty driver questions...

The setup: CCI power6/32, VIOC tty controllers, Sytek LAN hardware.

The scenario: occasionally, our Sytek SMUX will get reset and users
will be disconnected from their power6/32 ports.  Now _usually_, these
users' processes will receive the necessary signals which cause them
to clean themselves up and go away.

The problem: sometimes they don't.  When this happens, a new user
can connect to the port from which an old user has been thrown off,
and, without having to log in, can gain control of the old user's
processes.

My questions: I've compared our tty driver to drivers written for
DH-11s and DZ-11s.  In the situation I've described, both of these
drivers signal (SIGHUP and SIGCONT) the process group _before_
clearing the TS_CARR_ON flag in the tty struct; but our VIOC driver
clears the flag first, and then signals the process group.

Is this significant? Is there a race in the VIOC driver?
If not, would it help (or hurt) to raise the
processor priority level while cleaning up a detached line?

/dave

--


2. Linux preinstalled on a disk?

3. S: tty driver or tty filter

4. Samba Printer Setup Problem in RedHat 7.2

5. How to map a tty port to another tty port

6. The grand make

7. creating tty's, mknod, stuck after boot with wrong tty - help

8. stupid problem with CC

9. problems with tty, U469036 - bos.rte.tty.4.3.2.9

10. - can one change tty modes for tty not stdio ?

11. tty, tty... where art thou ...?

12. tty problem: only root and non-X get tty!

13. Good book on tty, pseudo tty, termio etc ?