On Thu, 8 Feb 2001, Alan Cox wrote:
> > It's the printk that gets it wrong, although that's harmless.
> > Intel's documentation states that the bug does NOT exist if the
> > bits 0 and 1 in eeprom[3] are 1. Thus, the workaround is correct,
> > the printk is wrong.
>
> So why does it fix the problem for him. His report and your reply don't
> make sense viewed together
I don't think it fixes *this* bug. However, the bug workaround effectively
reinitializes the chip, so it might serve as a generic 'reset and try
again' kind of workaround. In that case, we might as well enable it
unconditionally... but I don't see it as a good solution. It's a stop-gap
measure at best.
We need to find out what exactly happens. Until he tells us more about how
his boxes "were failing before", there really isn't much we can diagnose.
I happen to also have an Intel ISP1100 box here, and I know what's inside
-- i82559 C-step chips which definitely don't have this bug. The bug is an
i82557-only bug; what makes things confusing is Intel idea of giving
multiple chips the same PCI id. They can be identified via the PCI rev:
i82557 step A-C: rev 1-3
i82558 step A-B: rev 4-5
i82559 step A-C: rev 6-8
Ion
--
It is better to keep your mouth shut and be thought a fool,
than to open it and remove all doubt.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Thu Feb 15 2001 - 21:00:11 EST