NetBSD Problem Report #46616

From mlr@rterm.rse.com  Tue Jun 19 23:00:54 2012
Return-Path: <mlr@rterm.rse.com>
Received: from mail.netbsd.org (mail.netbsd.org [149.20.53.66])
	by www.NetBSD.org (Postfix) with ESMTP id 7EE3D63B8CC
	for <gnats-bugs@gnats.NetBSD.org>; Tue, 19 Jun 2012 23:00:54 +0000 (UTC)
Message-Id: <20120619214013.807BE2181EE@rterm.rse.com>
Date: Tue, 19 Jun 2012 17:40:13 -0400 (EDT)
From: mlr@rse.com
Reply-To: mlr@rse.com
To: gnats-bugs@gnats.NetBSD.org
Subject: Copy, echo, cat to /dev/ttyU0 ends badly, with "cp: /dev/ttyU0: Invalid argument"
X-Send-Pr-Version: 3.95

>Number:         46616
>Category:       kern
>Synopsis:       Copy, echo, cat to /dev/ttyU0 ends badly, with "cp: /dev/ttyU0: Invalid argument"
>Confidential:   no
>Severity:       non-critical
>Priority:       high
>Responsible:    kern-bug-people
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Tue Jun 19 23:05:00 +0000 2012
>Last-Modified:  Sun Jul 15 22:15:09 +0000 2012
>Originator:     Michael L. Riechers
>Release:        NetBSD 6.0_BETA
>Organization:
M L Riechers Systems Engineering
>Environment:


System: NetBSD rterm.rse.com 6.0_BETA NetBSD 6.0_BETA (GENERIC) #0: Mon Mar 26 16:43:30 EDT 2012 root@cterm.rse.com:/usr/local/src/usr/usr.201203110000Z/src/sys/arch/amd64/compile/obj/GENERIC amd64
Architecture: x86_64
Machine: amd64
>Description:

1. Attach a FTDI USB HS Serial Converter to a USB port.  Attach the other end
   to your favorite serial device (mine is a TA microBDM12XG BDM pod).

2. On the console, watch the USB device attach:

Jun 19 16:51:04 rterm /netbsd: ehci0: handing over full speed device on port 2 to ohci0
Jun 19 16:51:06 rterm /netbsd: uftdi0 at uhub0 port 2
Jun 19 16:51:06 rterm /netbsd: uftdi0: FTDI USB HS Serial Converter, rev 2.00/6.00, addr 4
Jun 19 16:51:06 rterm /netbsd: ucom0 at uftdi0 portno 1

3. Run CU, to set up the Serial Device, and to access the BDM:

Tue Jun 19 16:45:34 on rterm.rse.com ~ A)cu -l /dev/ttyU0 -s 115200 dir

Connected

Can't Communicate With Target CPU

1.) Set Target Speed (16000 KHz)
2.) Reset Target
3.) Reattempt Communication
4.) Erase & Unsecure
5.) Enter BDM debugger
? 

Which is all well and good, because the cpu's memory needs to be erased
before the BDM facility on the cpu will allow to "Communicate With Target CPU."

4. From another window, and with cu still running in the first (or not, both ways),
   Run the "unsec" script, which you don't have, but that doesn't matter. I get
   "./unsec: cannot create /dev/ttyU0: error 22" over and over, everytime
   the script executes something like "echo 'reset ' |tr '\n' '\r' >>"/dev/ttyU0";"

   So, alternatively, you can just do something like "cp fload3f0000 /dev/ttyU0"
   and get "cp: /dev/ttyU1: Invalid argument"

   Strangely, exactly the same thing happens if I "cp fload3f0000 /dev/ttyU1":
   "cp: /dev/ttyU1: Invalid argument", which is weird, because there ought not
   to be anything hung on ttyU1.  There's nothing physically there.

   If I "cp fload3f0000 /dev/tty00" it completes normally, even though there's
   a serial mouse hung on tty00.

   Here's a copy of my screen:

rterm\d \t on rterm.rse.com \w A) ls -al /dev/tty00 /dev/ttyU*
crw-------  1 uucp  wheel   8, 0 Jun 19 16:52 /dev/tty00
crw-rw-rw-  1 uucp  wheel  66, 0 Jun 19 16:55 /dev/ttyU0
crw-------  1 uucp  wheel  66, 1 Sep 14  2011 /dev/ttyU1

rterm\d \t on rterm.rse.com \w A) cp fload3f0000 /dev/tty00
rterm\d \t on rterm.rse.com \w A) cp fload3f0000 /dev/ttyU0
cp: /dev/ttyU0: Invalid argument
rterm\d \t on rterm.rse.com \w A) cp fload3f0000 /dev/ttyU1
cp: /dev/ttyU1: Invalid argument
rterm\d \t on rterm.rse.com \w A) 

5. This same procedure works fine on:

Tue Jun 19 17:27:08 on jterm.rse.com ~ A) uname -a
NetBSD jterm.rse.com 5.1 NetBSD 5.1 (GENERIC) #0: Sun Nov  7 14:39:56 UTC 2010  builds@b6.netbsd.org:/home/builds/ab/netbsd-5-1-RELEASE/i386/201011061943Z-obj/home/builds/ab/netbsd-5-1-RELEASE/src/sys/arch/i386/compile/GENERIC i386

>How-To-Repeat:


1.  Initially, do a "cp somefile /dev/ttyU0".  This may give you an indication.

2.  Go through steps similar to what I outline above, using a serial emulation
    device such as the FTDI USB HS Serial Converter.

3.  Ask me to do something.  I'm willing.

>Fix:


>Audit-Trail:
From: M L Riechers <mlr@rse.com>
To: gnats-bugs@NetBSD.org
Cc: mlr@rse.com
Subject: Re: kern/46616: Copy, echo, cat to /dev/ttyU0 ends badly, with "cp: /dev/ttyU0: Invalid argument"
Date: Sun, 15 Jul 2012 16:43:17 -0400 (EDT)

 fix:

 --- ucom.c.ori  2012-02-02 14:43:07.000000000 -0500
 +++ ucom.c      2012-07-14 17:48:57.000000000 -0400
 @@ -365,10 +365,6 @@
         int s, i;
         int error;

 -       /* XXX This is a hopefully temporary stopgap for kern/42848. */
 -       if ((flag & (FREAD|FWRITE)) != (FREAD|FWRITE))
 -               return (EINVAL);
 -
         if (sc == NULL)
                 return (ENXIO);

 I applied the patch, re-compiled the kernal, and now I can "Copy, echo,
 and cat to /dev/ttyU0."

 This "temporary stopgap" was introduced 14 Jan as:

 diff -u src/sys/dev/usb/ucom.c:1.95 src/sys/dev/usb/ucom.c:1.96
 --- src/sys/dev/usb/ucom.c:1.95 Sat Jan 14 20:41:49 2012
 +++ src/sys/dev/usb/ucom.c      Sat Jan 14 20:51:00 2012
 @@ -1,4 +1,4 @@
 -/*     $NetBSD: ucom.c,v 1.95 2012/01/14 20:41:49 jakllsch Exp $       */
 +/*     $NetBSD: ucom.c,v 1.96 2012/01/14 20:51:00 jakllsch Exp $       */


 This seems to stem from a temporary fix to PR/45013 and PR/42848:


 > From: "Jonathan A. Kollasch" <jakllsch@netbsd.org>
 > To: gnats-bugs@gnats.NetBSD.org
 > Cc: 
 > Subject: PR/42848 CVS commit: src/sys/dev/usb
 > Date: Sat, 14 Jan 2012 20:51:00 +0000
 > 
 > 
 >  Module Name:	src
 >  Committed By:	jakllsch
 >  Date:		Sat Jan 14 20:51:00 UTC 2012
 > 
 >  
 >  Modified Files:
 >  	src/sys/dev/usb: ucom.c
 > 
 >  
 >  Log Message:
 >  Stopgap XXX kludge for PR kern/42848 and PR kern/45013.
 > 
 >  
 >  Someone should really find and fix the real problem,
 >  but it's better to not crash in the meantime.
 > 

 I heartily agree that "Someone should really find and fix
 the real problem", and hope someone with more knowledge than
 I fixes it.

 Meanwhile, I'm backing out the stopgap on my systems, and
 hoping for the best. I really can't live with the stopgap.

 Should this PR be closed, or left open as a reminder of the
 consequences of this stopgap?

 Yours,

 -Mike

>Unformatted:
 <synopsis of the problem (one line)>

NetBSD Home
NetBSD PR Database Search

(Contact us) $NetBSD: query-full-pr,v 1.39 2013/11/01 18:47:49 spz Exp $
$NetBSD: gnats_config.sh,v 1.8 2006/05/07 09:23:38 tsutsui Exp $
Copyright © 1994-2007 The NetBSD Foundation, Inc. ALL RIGHTS RESERVED.