Re: [TEST/REVIEW/HEADSUP] tty drivers mega-patch

On Wed, Jul 14, 2004 at 12:09:47AM +0200, Poul-Henning Kamp wrote:
> 
> http://phk.freebsd.dk/patch/tty.patch
> 
> This patch removes 2500 lines of copy&paste insanity in tty drivers
> and generally tries to get things to be less confused & confusing.
> 
> I need testers for all the different kinds of serial hardware we support.
> 
> Please help test!

I think NL->CRNL translation is off by default. On an i386 with uart(4)
as the system console I get the following:

\begin{console}
Timecounters tick every 10.000 msec
acpi_cpu: throttling enabled, 2 steps (100% to 50.0%), currently 100.0%
ad0: 19574MB <WDC WD205BA> [39770/16/63] at ata0-master UDMA66
ata1-master: FAILURE - ATAPI_RESET no interrupt
acd0: DVDROM <HL-DT-STDVD-ROM GDR8160B> at ata1-master UDMA66
Mounting root from ufs:/dev/ad0s1a
Pre-seeding PRNG: kickstart.
                            Loading configuration files.
                                                        Entropy harvesting: interrupts ethernet point_to_point kickstart.
                                         kernel dumps on /dev/ad0s1b
\end{console}

When getty(8) gets started everything gets back to normal, but as soon
as the system console kicks in again, CR doesn't happen.

\begin{console}
FreeBSD/i386 (athlon.pn.xcllnt.net) (ttyu0)

login: marcel
Password:
Last login: Tue Jul 13 17:16:28 on ttyu0
Copyright (c) 1992-2004 The FreeBSD Project.
Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994
        The Regents of the University of California. All rights reserved.

Never worry about theory as long as the machinery does what it's
supposed to do.
                -- R. A. Heinlein
athlon% sudo shutdown -r now
Shutdown NOW!
shutdown: [pid 518]
athlon% 
*** FINAL System shutdown message from marcel_at_athlon.pn.xcllnt.net ***
System going down IMMEDIATELY


Jul 13 17:18:55 athlon shutdown: reboot by marcel:

System shutdown time has arrived
dc0: TX underrun -- increasing TX threshold
Stopping inetd.
               Shutting down daemon processes:.
                                               Stopping cron.
                                                             Shutting down local daemons:.
          Writing entropy file:.
                                Terminated
                                          .
                                           JWaiting (max 60 seconds) for system process `vnlru' to stop...stopped
Waiting (max 60 seconds) for system process `bufdaemon' to stop...stopped
Waiting (max 60 seconds) for system process `syncer' to stop...2 1 dc0: watchdog
\end{console}

I see the same behaviour on ia64 with uart(4), plus also a panic:

\begin{console}
              Tue Jul 13 17:29:42 PDT 2004
                                          panic: foo
KDB: enter: panic
\end{console}

#0  kdb_enter (msg=0xe00000000459f1c8 "panic") at cpufunc.h:47
#1  0xe000000004279f80 in panic (fmt=0xe00000000458b528 "foo")
    at ../../../kern/kern_shutdown.c:525
#2  0xe0000000041aaa60 in uart_tty_close (tp=0xe000000000712000)
    at ../../../dev/uart/uart_tty.c:309
#3  0xe0000000042eff20 in ttyclose (dev=0xe0000000046a73c8, flag=6532608,
    mode=7413760, td=0xe0000000041fc950) at ../../../kern/tty.c:2973
#4  0xe0000000041fc950 in spec_close (ap=0xa000000031173310)
    at ../../../fs/specfs/spec_vnops.c:637
#5  0xe0000000041f9d10 in spec_vnoperate (ap=0xa000000031173310)
    at ../../../fs/specfs/spec_vnops.c:118
#6  0xe00000000435af70 in vn_close (vp=0xe000000003ca8b40, flags=6,
    file_cred=0xe00000000029bc00, td=0xe00000007c6a66f0) at vnode_if.h:262
#7  0xe0000000042f44d0 in cnclose (dev=0xe0000000046a4ea0, flag=4, mode=8192,
    td=0xe00000007c6a66f0) at ../../../kern/tty_cons.c:441
#8  0xe0000000041fc950 in spec_close (ap=0xa0000000311733a0)
    at ../../../fs/specfs/spec_vnops.c:637
#9  0xe0000000041f9d10 in spec_vnoperate (ap=0xa0000000311733a0)
    at ../../../fs/specfs/spec_vnops.c:118
#10 0xe000000004345ba0 in vclean (vp=0xe000000003ca8d20, flags=8,
    td=0xe00000007c6a66f0) at vnode_if.h:262
#11 0xe000000004346900 in vgonel (vp=0xe000000003ca8d20, td=0xe00000007c6a66f0)
    at ../../../kern/vfs_subr.c:2699
#12 0xe000000004346580 in vgone (vp=0xe000000003ca8d20)
    at ../../../kern/vfs_subr.c:2631
#13 0xe0000000043463f0 in vop_revoke (ap=0xe0000000046a4f10)
    at ../../../kern/vfs_subr.c:2592
#14 0xe0000000041d7580 in devfs_revoke (ap=0xe0000000046a4f10)
    at ../../../fs/devfs/devfs_vnops.c:720
#15 0xe0000000042461a0 in exit1 (td=0xe00000007c6a66f0, rv=0) at vnode_if.h:593
#16 0xe000000004245210 in sys_exit (td=0xe00000007c6a66f0,
    uap=0xa0000000311734e8) at ../../../kern/kern_exit.c:94
#17 0xe000000004555f20 in syscall (tf=0xa000000031173400)
    at ../../../ia64/ia64/trap.c:998
(gdb) frame 2
#2  0xe0000000041aaa60 in uart_tty_close (tp=0xe000000000712000)
    at ../../../dev/uart/uart_tty.c:309
309             sc->sc_opened = 0;
(gdb) l
304             if (sc->sc_sysdev == NULL)
305                     UART_SETSIG(sc, SER_DDTR | SER_DRTS);
306
307             wakeup(sc);
308             KASSERT(!(tp->t_state & TS_ISOPEN), ("foo"));
309             sc->sc_opened = 0;
310             return;
311     }
312
313     void

Also: it's probably better to not force serial drivers to get cua*
(slave) device names. I rather prefer to have uart* for uart(4) and
foo* for foo(4). I see no advantage to have all TTY devices have
cua* names. It seems that the only reason for this is that we have
the initial and lock devices named rather crypticly.
There's also a bug there: For uart(4) the suffix is "r", which creates
cuar0, cuair0 and cualr0 as well as ttyir0 and ttylr0.
However, the TTY device for uart(4) is ttyu0. Maybe something like:

	ttymakeslaves(sc->sc_u.u_tty.si, unit, "uart", "u");

Which gives us something like:
	/dev/ttyu0
	/dev/ttyu0.init
	/dev/ttyu0.lock
	/dev/uart0
	/dev/uart0.init
	/dev/uart0.lock

Much friendlier, not so arcane and easier on automation and the likes.

-- 
 Marcel Moolenaar	  USPA: A-39004		 marcel_at_xcllnt.net