From owner-freebsd-hackers@FreeBSD.ORG Wed Oct 29 22:30:49 2008 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CC1501065676; Wed, 29 Oct 2008 22:30:49 +0000 (UTC) (envelope-from bahamasfranks@gmail.com) Received: from wf-out-1314.google.com (wf-out-1314.google.com [209.85.200.170]) by mx1.freebsd.org (Postfix) with ESMTP id 9806E8FC25; Wed, 29 Oct 2008 22:30:49 +0000 (UTC) (envelope-from bahamasfranks@gmail.com) Received: by wf-out-1314.google.com with SMTP id 24so221765wfg.7 for ; Wed, 29 Oct 2008 15:30:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:reply-to :sender:to:subject:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references :x-google-sender-auth; bh=qSmySDDFTVGEJEdvUeYdOJb4XzplEM0QQTDVwAdyH1Q=; b=MbW1Vw+p28QKSVcraE/NG2G+l4mnLmUp/n2eLthIFxHk1byJNlGIyUyF0L93TTUo6K 12HVRnbUWaOTm5gyUCnsFsNU6DYRcUEXoVVWy5BsFTgwchzQFfHi83108jjUcx/dFayJ lh+RISLZErzFTiaKoekPbBHWDfUT0LBPRFfD0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:reply-to:sender:to:subject:cc:in-reply-to :mime-version:content-type:content-transfer-encoding :content-disposition:references:x-google-sender-auth; b=JdHJdHjerM08TOhR+HZrQKRKGchWSKIzzhkxVMj22lTqxwczWO88/qtPfPYAmM4uMX zRmmfwifaBgldg4LW69IaOuoHbvjQzB3vm75xYxpJMqrbRUOOBG1l8nDaZz2C1jaOijc x9AsnTc2vy24dPWgLW0bKVwCSvWDCABaGt+SI= Received: by 10.142.185.13 with SMTP id i13mr4271710wff.219.1225319449137; Wed, 29 Oct 2008 15:30:49 -0700 (PDT) Received: by 10.142.141.5 with HTTP; Wed, 29 Oct 2008 15:30:49 -0700 (PDT) Message-ID: <539c60b90810291530v54712qe801c094ebcdecd1@mail.gmail.com> Date: Wed, 29 Oct 2008 15:30:49 -0700 From: "Steve Franks" Sender: bahamasfranks@gmail.com To: "Jeremy Chadwick" In-Reply-To: <20081025081305.GA55683@icarus.home.lan> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <539c60b90810241534l6bedc5e3s1c2e3162c2a7ff38@mail.gmail.com> <4902CC86.8030408@bokey.mine.nu> <20081025075648.GB55339@icarus.home.lan> <4902D1FA.3070003@bokey.mine.nu> <20081025081305.GA55683@icarus.home.lan> X-Google-Sender-Auth: 660b5b83d23a1f28 Cc: freebsd-hackers Subject: Re: neophyte: tcsetattr() gives 22 error in i386, not in amd64? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: stevefranks@ieee.org List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Oct 2008 22:30:49 -0000 >> >>>> Hi, >> >>>> >> >>>> I'm getting a 22 errno from tcsetattr() on 7-STABLE i386 in code which >> >>>> was working under 7-STABLE amd64. Serial device is a ucom (silabs >> >>>> cp2103). Permissions on /dev/cuaU0 look fine. Cutecom/Minicom >> >>>> appears to open the port without error... >> >>> I don't see anything obviously wrong, but I'd bet a bug related to >> >>> 32/64-bit types. Can you post a complete piece of code that can be >> >>> compiled and run and demonstrates the problem? Also, try compiling with >> >>> -Wall -W and investigate any warnings that are produced. >> >>> >> >>> By the way, errno 22 is EINVAL, "Invalid argument". perror() is your >> >>> friend. >> >> Strange freebsd doesnt document error numbers. On POSIX, errno 22 is >> >> EINVAL as well (documented in errno(3)). Is this applicable to freebsd? >> > >> > /usr/include/errno.h isn't documentation of error numbers? >> > If you're wanting to track down how/why tcsetattr(3) results in EINVAL, > using truss or ktrace might come in handy. Otherwise, you literally > will have to throw some debugging code into the ucom(4) driver to > try and figure out what function is kicking out code 22. Wow! truss is quite handy. I've located the problem, and am posting it for posterity: Someone was memset()'ing the termios struct to zero's, then setting the baudrate (setcfspeed) and a couple other things. Apparently this was not a canonical set of required members of the struct, because adding a tcgetattr(f, termio) right after the memset apparently pre-populated the thing correctly and now it works fine... Thanks for the leg up, Jeremy. Best, Steve