Adrian Chadd wrote:
> the "quick" fix is to re-reset the PCI slot or the PCI bus.

Read the quote from Daniel's email again. It explains how that caused
the problem.

In his bad case there was a reset at time 1 and another reset at time 2.

Removing the reset at time 1 and keeping an unchanged reset at time 2
made the problem disappear.

It seems that the hardware could not handle the reset at time 1,
presumably because the reset was incorrect per the specification.

The reset at time 2 is presumably correct, since things work with it.

If something (the reset at time 1) is able to screw up hardware so
badly that even a correct reset (time 2) does not *actually* reset
the hardware then I would consider that a very serious bus IP
problem in the hardware.

It would be interesting to know if this is *really* the problem. I'm
not at all sure.


> PCI device resource allocation and enumeration; which the Linux
> kernel may or may not do.

It does not.


> The real fix is to smack the heck out of BIOS writers who do
> strange and wonderful crap in their BIOS when resetting

Enumeration comes much later. The only two possibilities are a. the
reset at time 1 violated the specification and b. the hardware
doesn't handle multiple resets reliably.

It would be good to get more detail about what exactly makes the
hardware fail to initialize registers from the EEPROM.

I don't think there's such a thing as "best practise" on a bus.
Either the spec is followed (by everyone) or it isn't. :)


//Peter
_______________________________________________
ath9k-devel mailing list
ath9k-devel@lists.ath9k.org
https://lists.ath9k.org/mailman/listinfo/ath9k-devel

Reply via email to