Date: Tue, 13 Jul 2004 18:11:56 -0700 From: Marcel Moolenaar <marcel@xcllnt.net> To: Poul-Henning Kamp <phk@phk.freebsd.dk> Cc: current@freebsd.org Subject: Re: [TEST/REVIEW/HEADSUP] tty drivers mega-patch Message-ID: <20040714011156.GA14310@dhcp50.pn.xcllnt.net> In-Reply-To: <26867.1089756587@critter.freebsd.dk> References: <7482.1089588386@critter.freebsd.dk> <26867.1089756587@critter.freebsd.dk>
next in thread | previous in thread | raw e-mail | index | archive | help
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@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@xcllnt.net
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20040714011156.GA14310>