From owner-freebsd-hardware Wed May 20 10:43:46 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id KAA09904 for freebsd-hardware-outgoing; Wed, 20 May 1998 10:43:46 -0700 (PDT) (envelope-from owner-freebsd-hardware@FreeBSD.ORG) Received: from dingo.cdrom.com (dingo.cdrom.com [204.216.28.145]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id KAA09898; Wed, 20 May 1998 10:43:39 -0700 (PDT) (envelope-from mike@dingo.cdrom.com) Received: from dingo.cdrom.com (localhost [127.0.0.1]) by dingo.cdrom.com (8.8.8/8.8.5) with ESMTP id JAA00695; Wed, 20 May 1998 09:38:54 -0700 (PDT) Message-Id: <199805201638.JAA00695@dingo.cdrom.com> X-Mailer: exmh version 2.0zeta 7/24/97 To: Bruce Evans cc: mike@smith.net.au, current@FreeBSD.ORG, grog@lemis.com, hardware@FreeBSD.ORG, tarkhil@asteroid.svib.ru Subject: Re: IWill and sio, again and again In-reply-to: Your message of "Thu, 21 May 1998 03:11:11 +1000." <199805201711.DAA19337@godzilla.zeta.org.au> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 20 May 1998 09:38:53 -0700 From: Mike Smith Sender: owner-freebsd-hardware@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > >> >> I don't know of any correct patch, but the problem can be worked around > >> >> by ignoring the results of tests 5 and 7. > >> > >> Actually tests 5 and 8. > >> > >> >On what hardware did you try this? I tried exactly this approach on > >> >an IWill P55XB2, and it didn't work. > >> > >> IForget. The probe can't possibly not work if you ignore the failures > >> in it. > > > >The probe works, but the port doesn't, due to the attach making > >assumptions about the results of the probe. This is a basic failure in > >implementation of many probe/attach pairs, which will be exacerbated if/ > >when the probes are obsoleted by PnP detection. > > The port worked fine on the system I debugged it on. Do you mean to say that you've assessed the problem with the ACER UART (or the PIC arrangement used with it)? What is your prognosis? > The attach makes > no assumptions about the results of the probe, but it assumes that a > successful probe leaves a couple of registers in a certain state. > Butchery of the probe to do more than ignore the failures could easily > break this. Butchery of the probe to merely ignore the failures results in a nonworking port. Butchery of the probe to include the bogus-but-functional probe code on Greg's page results in a working port. The inference here is that the attach assumes some port state that is not achieved by the normal probe. If we were to use the PnP BIOS data to determine the port's configuration and ignored the probe, it would be interesting to know if the attach would result in a working port. -- \\ Sometimes you're ahead, \\ Mike Smith \\ sometimes you're behind. \\ mike@smith.net.au \\ The race is long, and in the \\ msmith@freebsd.org \\ end it's only with yourself. \\ msmith@cdrom.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hardware" in the body of the message