Date: Fri, 21 Jul 2006 10:15:39 -0500 From: "Rick C. Petty" <rick-freebsd@kiwi-computer.com> To: Jo Rhett <jrhett@svcolo.com> Cc: freebsd-hardware@freebsd.org Subject: Re: device busy -- no locks? Message-ID: <20060721151539.GA69956@megan.kiwi-computer.com> In-Reply-To: <20060721004731.GC8868@svcolo.com> References: <20060721000018.GA99237@svcolo.com> <20060721001607.GA64376@megan.kiwi-computer.com> <20060721004731.GC8868@svcolo.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, Jul 20, 2006 at 05:47:31PM -0700, Jo Rhett wrote: > > Sorry, yes. Same results. And if lsof shows things that fstat doesn't, > then this is a bug in FreeBSD. Not necessarily a bug, if you consider the ports tree as "enhancements". I know they show different stuff, e.g. lsof lists shared libraries which are open and IPC stuff. I'm not sure what other differences they have. The biggest troubles I've had with fstat in the past is when I was trying to find someone who held something like /dev/dsp0.2 open and I did a search for just /dev/dsp. I wish fstat was a bit more knowledgable about related devices. > Also note that this system is pretty bone stock. Standard install, plus > mysql and apache. Nothing else would be using the port. It's something > that left it locked, and really only "login" could be the culprit. By locked do you mean someone performed flock(2) or lockf(3) on the device or that someone held the device open? I was under the impression that all open file descriptors and file locks were cleaned up when a process terminates. So I'm not sure what you mean by "left it locked" if there's no current process using that device. > > How did you disable the getty? Was this prior to or after a restart? It > > sounds like /etc/ttys is maybe running a process on it. You need to > > "killall -HUP init" after changing /etc/ttys. But you probably already > > know that. > > Yes, I change "on" to "off" in /etc/ttys and "kill -1 1" :-) I was also asking if you tried rebooting after you disabled getty. There could be a bug in the sio driver or some hardware-related glitch which doesn't fully close the device even though the process is terminated. If the problem goes away after a reboot, this is likely the problem. If not, it still sounds like a device-related problem.. Although I can't find the use of EBUSY (errno 16) in the sio source code... -- Rick C. Petty
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20060721151539.GA69956>