On Thu, Feb 14, 2008 at 02:48:09PM -0800, Michael Chan wrote: > On Thu, 2008-02-14 at 17:12 -0500, Andy Gospodarek wrote: > > On Thu, Feb 14, 2008 at 01:25:27PM -0800, Michael Chan wrote: > > > On Thu, 2008-02-14 at 13:56 -0500, Andy Gospodarek wrote: > > > > That should be a simple matter of adding the right pci-ids to > > > > tg3_get_invariants -- hopefully Ralf will respond and we can get that > > > > knocked out quickly. > > > > > > > > > > > > > > It doesn't look like it was re-ordered IO. If it was, it should have > > > self-recovered without hitting the BUG(). > > > > > > > Good catch, Michael! I missed that it paniced since I expect to see > > some sort of backtrace when that happens. We should try and get that > > bridge added to the list though, to avoid repeated complaints that there > > is a tg3 bug. > > > > > > Andy, I think you still missed my point. I don't believe this problem > was caused by the bridge or the chipset at all. Some corruption caused > us to not find the SKB in the TX ring where it was expected. So the > driver assumed it was the bridge re-ordering I/O and printed that > warning message and took recovery action. The recovery action had no > effect in this case since apparently it was caused by something else and > the corruption happened again later. This 2nd time, we hit the BUG_ON() > seeing that the recovery action did not work. > >
Ah, I see. Due to at leat a 2 second delay between the message and the panic, I figured it would be good data to gather.... -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
