Date: Wed, 29 Dec 2004 12:44:33 +0000 From: Peter Edwards <peadar.edwards@gmail.com> To: =?ISO-8859-1?Q?Dag-Erling_Sm=F8rgrav?= <des@des.no>, "Li-Lun Wang (Leland Wang)" <llwang@infor.org> Cc: current@freebsd.org Subject: Re: fxp EEPROM checksum mismatch in recent -CURRENT Message-ID: <34cb7c840412290444497d2dd7@mail.gmail.com> In-Reply-To: <xzpu0qa2pzi.fsf@dwp.des.no> References: <xzpu0qa2pzi.fsf@dwp.des.no>
next in thread | previous in thread | raw e-mail | index | archive | help
------=_Part_487_11899736.1104324273433
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline
On Sat, 25 Dec 2004 19:26:57 +0100, Dag-Erling Sm=F8rgrav <des@des.no> wrot=
e:
> Yesterday's -CURRENT fails to attach the onboard fxp on my Gigabyte
> motherboard:
>=20
> fxp0: <Intel 82801BA (D865) Pro/100 VE Ethernet> port 0xb000-0xb03f mem 0=
xfb050000-0xfb050fff irq 20 at device 8.0 on pci2
> fxp0: Disabling dynamic standby mode in EEPROM
> fxp0: New EEPROM ID: 0xfffd
> fxp0: EEPROM checksum @ 0xff: 0xffff -> 0xbbb9
> fxp0: MII without any PHY!
> device_attach: fxp0 attach returned 6
I had this problem, but had put it down to dodgy hardware. Seeing as a few =
other
people saw it, I had a look: It turns out that the problems are due to
the base address register for the device's memory range being bogus
when you get into fxp_attach.
Tracing further, it looks like on waking up from D3 into D0, the fxp
device needs some time to settle, or the config write to restore the
BAR doesn't "take". That explains why it works if it's dragged in from
the loader: the device probes without ever going to sleep.
The attached ugly hack makes my fxp module behave. I'm not sure if
this is a good idea for the general case, or if a quirk entry of some
sort might be preferrable. I'd imagine this is probably an issue that
might happen with other devices.
Any PCI gurus have an opinion?
--=20
peadar
------=_Part_487_11899736.1104324273433
Content-Type: text/plain; name="pcipatch.txt"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment; filename="pcipatch.txt"
? sys/dev/pci/.pci.c.swp
? sys/dev/pci/.swp
Index: sys/dev/pci/pci.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/FreeBSD-CVS/src/sys/dev/pci/pci.c,v
retrieving revision 1.273
diff -u -r1.273 pci.c
--- sys/dev/pci/pci.c=098 Dec 2004 04:35:19 -0000=091.273
+++ sys/dev/pci/pci.c=0929 Dec 2004 12:38:48 -0000
@@ -534,9 +534,11 @@
=09=09default:
=09=09=09result =3D EINVAL;
=09=09}
-=09=09if (result =3D=3D 0)
+=09=09if (result =3D=3D 0) {
=09=09=09PCI_WRITE_CONFIG(dev, child, cfg->pp.pp_status, status,
=09=09=09=09=09 2);
+=09=09=09DELAY(10);
+=09=09}
=09} else {
=09=09result =3D ENXIO;
=09}
------=_Part_487_11899736.1104324273433--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?34cb7c840412290444497d2dd7>