Skip site navigation (1)Skip section navigation (2)
Date:      Mon, 19 Apr 2004 18:08:12 +0200 (CEST)
From:      Rudolf Cejka <cejkar@fit.vutbr.cz>
To:        FreeBSD-gnats-submit@FreeBSD.org
Subject:   kern/65769: Call to tcflush(x, TCIFLUSH) stops input on usb-serial forever
Message-ID:  <200404191608.i3JG8C7o073305@kazi.fit.vutbr.cz>
Resent-Message-ID: <200404191610.i3JGAJl7033221@freefall.freebsd.org>

next in thread | raw e-mail | index | archive | help

>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:



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200404191608.i3JG8C7o073305>