Date: Tue, 8 Jan 2008 20:36:52 -0500 From: John Baldwin <jhb@freebsd.org> To: freebsd-stable@freebsd.org Cc: re@freebsd.org Subject: Re: RELENG7 using lpt causes panic Message-ID: <200801082036.52847.jhb@freebsd.org> In-Reply-To: <200801081032.57681.jhb@freebsd.org> References: <20080108030857.GA93021@steerpike.hanley.stade.co.uk> <478391D5.3010203@samsco.org> <200801081032.57681.jhb@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tuesday 08 January 2008 10:32:56 am John Baldwin wrote: > On Tuesday 08 January 2008 10:08:05 am Scott Long wrote: > > John Baldwin wrote: > > > On Monday 07 January 2008 10:08:57 pm Adrian Wontroba wrote: > > >> I've recently switched some of my home systems to RELENG7. > > >> > > >> All seemed fairly well until I tried printing a CUPS test page on my > > >> backup and print server to an elderly Laserjet IIIp, where I seem to > > >> have a reproducible panic. It has happened twice. This is painful, as > > >> I have a big home fileystem (striped over two mirrors over most of two > > >> 500 GB disks). The gmirror syncronisation and background fsck leave the > > >> system close to unusable for hours while they fight over the disks. > > >> > > >> I was somewhat startled that something so basic as printing causes a > > >> panic. There have been no hardware changes since I last printed under > > >> RELENG6, but I don't print often, so hardware decay is a possibility. > > >> > > >> Is this a known problem? If not, I'll take the time to try various tests > > >> (with /home unmounted) and raise a PR. > > >> > > >> I envisage tests such as: > > >> * Does switching to a kernel without SMP and apic make a difference? > > >> * Does direct output cause a crash? > > >> * Does polling make a difference? > > >> * Does the parallel port mode (I think extended at present) make a > > >> difference? > > >> > > >> Some detail below. > > > > > > This is a known issue and it has to do with some changes in the interrupt > > > code in 7.x that interact badly with the lpt(4) driver (which tears down its > > > interrupt handler and sets it back up again for each character, and the > > > panic you see is because an interrupt came when it wasn't expecting it). > > > The lpt(4) driver does this weird dance to allow coexisting with vpo so you > > > can have lpd running and unplug your printer and plug up a Zip drive w/o > > > having to stop lpd. I think the way I want to fix it is to change the lpt > > > driver to not release the bus (and thus remove its interrupt handler) for > > > every char but to keep the bus while /dev/lpt0 is open (which would be all > > > the time with lpd running). > > > > > > > My guess is that LPT ZIP drives all died a clicking death many, many > > years ago. I usually don't advocate for the removal of hardware > > support, but these drives were so pitiful and so poorly engineered that > > I honestly doubt there is any value in keeping the driver around. > > It's not a matter of removing vpo(4) so much as reworking the various ppbus > drivers to not be so fancy with trying to drop and release the ppbus but > only do that in open/close. As mentioned on current@, there is a sort of quick-hack patch available for testing at http://www.freebsd.org/~jhb/patches/ppbus_intr.patch and you can see the post to current@ for more details. I chose a quick-hack approach for now as it is less risky than more proper fixes for ppbus/lpt/etc. -- John Baldwin
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200801082036.52847.jhb>