From owner-freebsd-bugs@FreeBSD.ORG Mon Apr 19 09:10:19 2004 Return-Path: Delivered-To: freebsd-bugs@hub.freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 909B316A4D0 for ; Mon, 19 Apr 2004 09:10:19 -0700 (PDT) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6F7BA43D55 for ; Mon, 19 Apr 2004 09:10:19 -0700 (PDT) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (gnats@localhost [127.0.0.1]) i3JGAJbv033222 for ; Mon, 19 Apr 2004 09:10:19 -0700 (PDT) (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.12.10/8.12.10/Submit) id i3JGAJl7033221; Mon, 19 Apr 2004 09:10:19 -0700 (PDT) (envelope-from gnats) Resent-Date: Mon, 19 Apr 2004 09:10:19 -0700 (PDT) Resent-Message-Id: <200404191610.i3JGAJl7033221@freefall.freebsd.org> Resent-From: FreeBSD-gnats-submit@FreeBSD.org (GNATS Filer) Resent-To: freebsd-bugs@FreeBSD.org Resent-Reply-To: FreeBSD-gnats-submit@FreeBSD.org, Rudolf Cejka Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8F4F316A4CE for ; Mon, 19 Apr 2004 09:08:24 -0700 (PDT) Received: from kazi.fit.vutbr.cz (kazi.fit.vutbr.cz [147.229.8.12]) by mx1.FreeBSD.org (Postfix) with ESMTP id 742DD43D46 for ; Mon, 19 Apr 2004 09:08:23 -0700 (PDT) (envelope-from cejkar@fit.vutbr.cz) Received: from kazi.fit.vutbr.cz (localhost [127.0.0.1]) by kazi.fit.vutbr.cz (8.12.11/8.12.11) with ESMTP id i3JG8C2m073307 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO) for ; Mon, 19 Apr 2004 18:08:12 +0200 (CEST) Received: (from cejkar@localhost) by kazi.fit.vutbr.cz (8.12.11/8.12.5/Submit) id i3JG8C7o073305; Mon, 19 Apr 2004 18:08:12 +0200 (CEST) Message-Id: <200404191608.i3JG8C7o073305@kazi.fit.vutbr.cz> Date: Mon, 19 Apr 2004 18:08:12 +0200 (CEST) From: Rudolf Cejka To: FreeBSD-gnats-submit@FreeBSD.org X-Send-Pr-Version: 3.113 Subject: kern/65769: Call to tcflush(x, TCIFLUSH) stops input on usb-serial forever X-BeenThere: freebsd-bugs@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: Rudolf Cejka List-Id: Bug reports List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Apr 2004 16:10:19 -0000 >Number: 65769 >Category: kern >Synopsis: Call to tcflush(x, TCIFLUSH) stops input on usb-serial forever >Confidential: no >Severity: non-critical >Priority: medium >Responsible: freebsd-bugs >State: open >Quarter: >Keywords: >Date-Required: >Class: sw-bug >Submitter-Id: current-users >Arrival-Date: Mon Apr 19 09:10:19 PDT 2004 >Closed-Date: >Last-Modified: >Originator: Rudolf Cejka >Release: FreeBS-current >Organization: FIT, Brno University of Technology, Czech Republic >Environment: Tested on -current, but it seems that -stable has the same problem. >Description: I have tried remote kernel debugging over serial line with usb-to-serial converter on local debugging machine. However, it does not work. I have found, that gdb calls tcflush(x, TCIFLUSH) in contrib/gdb/gdb/ser-unix.c and tcflush() itself calls t_stop() in both read and write cases, which is function ucomstop() for USB code. However, ucomstop() hardware-disables receiver, which is not expected from tcflush() side, because there is no place, which would enable receiver again. It means that caling tcflush(x, TCIFLUSH) or tcflush(x, TCIOFLUSH) flushes and disables input, but it should just flush it. It seems that function t_stop() should not be called in tcflush() at all as is in NetBSD case, however I tried just partial thing - I have tried to remove t_stop() just from the read path (as was for revisions 1.1 - 1.15 of sys/kern/tty.c), which does work for me and remote kernel debugging works again for me. However, it still does not solve anything, if tcflush(x, TCIOFLUSH) is called. >How-To-Repeat: Simply try remote debugging session with gdb over serial line with usb-to-serial converter - it does not work, because there is not input from target machine, however it is possible to read the input with tip utility, because tip does not call tcflush(). >Fix: >Release-Note: >Audit-Trail: >Unformatted: