Date: Wed, 29 Oct 2008 15:30:49 -0700 From: "Steve Franks" <stevefranks@ieee.org> To: "Jeremy Chadwick" <koitsu@freebsd.org> Cc: freebsd-hackers <freebsd-hackers@freebsd.org> Subject: Re: neophyte: tcsetattr() gives 22 error in i386, not in amd64? Message-ID: <539c60b90810291530v54712qe801c094ebcdecd1@mail.gmail.com> In-Reply-To: <20081025081305.GA55683@icarus.home.lan> References: <539c60b90810241534l6bedc5e3s1c2e3162c2a7ff38@mail.gmail.com> <Pine.GSO.4.64.0810241626430.16737@zeno.ucsd.edu> <4902CC86.8030408@bokey.mine.nu> <20081025075648.GB55339@icarus.home.lan> <4902D1FA.3070003@bokey.mine.nu> <20081025081305.GA55683@icarus.home.lan>
next in thread | previous in thread | raw e-mail | index | archive | help
>> >>>> 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?539c60b90810291530v54712qe801c094ebcdecd1>