On Wed, Mar 27, 2013 at 7:04 PM, Peter Stuge <pe...@stuge.se> wrote: > 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. >
It wasn't that it could not handle the reset a time 1 but that the reset at time 2 was causing the issue that Michael explained with hanging the EEPROM. So it is not that either reset was more appropriate than the other but that for this BIOS implementation it was better to remove time 1 and keep time 2 since one reset really was needed. > 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. > The vendor never mentioned whether this was out of spec or if the card was not compliant but I can say that this was not the first issue we had run into with a BIOS. Another instance was making assumptions that no one would ever have more than 20 PCIe devices connected to the bus. This was an artificial limit imposed by the BIOS writter that did technically violate the spec. 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 >
_______________________________________________ ath9k-devel mailing list ath9k-devel@lists.ath9k.org https://lists.ath9k.org/mailman/listinfo/ath9k-devel
