Date: Tue, 28 May 2002 23:08:55 -0700 From: Brooks Davis <brooks@one-eyed-alien.net> To: Brooks Davis <brooks@one-eyed-alien.net> Cc: Warner Losh <imp@FreeBSD.ORG>, cvs-committers@FreeBSD.ORG, cvs-all@FreeBSD.ORG Subject: Re: cvs commit: src/sys/i386/pci pci_cfgreg.c Message-ID: <20020528230855.A21041@Odin.AC.HMC.Edu> In-Reply-To: <20020527150933.A18324@Odin.AC.HMC.Edu>; from brooks@one-eyed-alien.net on Mon, May 27, 2002 at 03:09:33PM -0700 References: <200204241530.g3OFUCL52082@freefall.freebsd.org> <20020527150933.A18324@Odin.AC.HMC.Edu>
next in thread | previous in thread | raw e-mail | index | archive | help
--sm4nu43k4a2Rpi4c
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
On Mon, May 27, 2002 at 03:09:33PM -0700, Brooks Davis wrote:
> On Wed, Apr 24, 2002 at 08:30:12AM -0700, Warner Losh wrote:
> > imp 2002/04/24 08:30:12 PDT
> >=20
> > Modified files:
> > sys/i386/pci pci_cfgreg.c=20
> > Log:
> > o Work around bugs in the powerof2 macro: It thinks that 0 is a power=
of
> > 2, but that's not the case. This fixes the case where there were s=
lots
> > in the PIR table that had no bits set, but we assumed they did and =
used
> > strange results as a result.
> > o Map invalid INTLINE registers to 255 in pci_cfgreg.c. This should =
allow
> > us to remove the bogus checks in MI code for non-255 values.
> > =20
> > I put these changes out for review a while ago, but no one responded
> > to them, so into current they go.
>=20
> After a month of not having time to do anything about it and looking down
> the wrong path several times, I found that the second part of this commit
> hoses my HP Omnibook 500. The symptom is that the console doesn't flush
> except when the kernel prints something and other timers don't seem to
> fire so dhcp hangs forever. Any idea how to debug this?
Ok, I think I've figured out the problem. The issue appears to be ath
that mapping 0 to 255 in pci_cfgregread() isn't enough. We need to
restore the hack in pci_cfgintr_search() as well because that grovels
around in the pci tables rather then using an indirect method that calls
pci_cfgregread().
I'm current up and running with the following patch to HEAD. If you
think this is OK, I'd be happy to commit it.
Index: pci_cfgreg.c
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
RCS file: /usr/cvs/src/sys/i386/pci/pci_cfgreg.c,v
retrieving revision 1.84
diff -u -p -r1.84 pci_cfgreg.c
--- pci_cfgreg.c 24 Apr 2002 15:30:11 -0000 1.84
+++ pci_cfgreg.c 29 May 2002 05:50:02 -0000
@@ -408,6 +408,14 @@ pci_cfgintr_search(struct PIR_entry *pe,
(pci_get_slot(*childp) =3D=3D device) &&
(pci_get_intpin(*childp) =3D=3D matchpin)) {
irq =3D pci_get_irq(*childp);
+ /*
+ * Some BIOS writers seem to want to ignore the spec and put
+ * 0 in the intline rather than 255 to indicate none. Once
+ * we've found one that matches, we break because there can
+ * be no others (which is why test looks a little odd).
+ */
+ if (irq =3D=3D 0)
+ irq =3D 255;
if (irq !=3D 255)
PRVERB(("pci_cfgintr_search: linked (%x) to configured irq %d at %d:=
%d:%d\n",
pe->pe_intpin[pin - 1].link, irq,
-- Brooks
--=20
Any statement of the form "X is the one, true Y" is FALSE.
PGP fingerprint 655D 519C 26A7 82E7 2529 9BF0 5D8E 8BE9 F238 1AD4
--sm4nu43k4a2Rpi4c
Content-Type: application/pgp-signature
Content-Disposition: inline
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: For info see http://www.gnupg.org
iD8DBQE89HB2XY6L6fI4GtQRAiPIAJsG01nPwKFnuN9qFzmUgyCNL28ZawCgglEu
jxZdmsPqyH410q0YUFZLzoY=
=XHVu
-----END PGP SIGNATURE-----
--sm4nu43k4a2Rpi4c--
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe cvs-all" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20020528230855.A21041>