Date: Fri, 13 Oct 2006 16:31:45 +1000 (EST) From: Bruce Evans <bde@zeta.org.au> To: Jo Rhett <jrhett@svcolo.com> Cc: "Rick C. Petty" <rick-freebsd@kiwi-computer.com>, freebsd-hardware@freebsd.org Subject: Re: Bounty offered to fix sio device lock problem Message-ID: <20061013152714.Y49451@delplex.bde.org> In-Reply-To: <452EB286.8000503@svcolo.com> References: <20060721000018.GA99237@svcolo.com> <20060721001607.GA64376@megan.kiwi-computer.com> <20060721004731.GC8868@svcolo.com> <20060724154856.I58894@delplex.bde.org> <452EB286.8000503@svcolo.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, 12 Oct 2006, Jo Rhett wrote: > Bruce -- who owns getting this fixed? Or who should own it? Or who will > take on getting it fixed if we offer a bounty on it? > > Replication scenario: > Modem on sio0 (or sio1 or any normal i386 serial port) > /etc/ttys has port enabled with "dialup" > qpage (from ports, unchanged) uses modem for dialout > ** or just write a script that periodically dials out using tip > > Within a day and often within a few hours, the serial port will go awol. You > can't talk to the modem any more. Modem is just fine. > Rebooting the system solves the problem. Rebooting the modem does not solve > it. > > 100% replicable, and sooner versus later if you call out more often. [context lost to top posting] I mentioned an old vfs refcounting bug. New ones turned up a week or two ago. They cause leaked pty masters and worse. The pty leak is caused by last-close sometimes not being called. For pty masters, the leak is permanent since reopening of the master is not permitted for security reasons so there is no way to reach the device close, but for sio devices it should be possible to fix up the problem by reopening and closing the device relevant device after ensuring that it is not already open: - for cua*, simply stty -f'ing it or just using it should be enough. I guess this is not your problem, since the fix is almost automatic. - for tty*, it may be necessary to disable getty on the port and kill the current getty, since the old vfs refcounting bug normally prevents reaching last-close if any process is sleeping in open, so if you don't disable getty on the port then you have to race with the new getty to complete the open/last-close before the new getty sleeps in open. Many nearby vfs bugs will be fixed in 6.2-RELEASE, but no fix is in sight for the main refcounting ones. Bruce
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20061013152714.Y49451>