Re: fxp EEPROM checksum mismatch in recent -CURRENT

From: Peter Edwards <peadar.edwards_at_gmail.com>
Date: Wed, 29 Dec 2004 12:44:33 +0000
On Sat, 25 Dec 2004 19:26:57 +0100, Dag-Erling Smørgrav <des_at_des.no> wrote:
> Yesterday's -CURRENT fails to attach the onboard fxp on my Gigabyte
> motherboard:
> 
> fxp0: <Intel 82801BA (D865) Pro/100 VE Ethernet> port 0xb000-0xb03f mem 0xfb050000-0xfb050fff irq 20 at device 8.0 on pci2
> fxp0: Disabling dynamic standby mode in EEPROM
> fxp0: New EEPROM ID: 0xfffd
> fxp0: EEPROM checksum _at_ 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?
-- 
peadar

Received on Wed Dec 29 2004 - 11:44:34 UTC

This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:38:25 UTC