Messages in this thread | | | Date | Fri, 5 Aug 2005 16:59:37 -0700 | From | Grant Grundler <> | Subject | Re: [openib-general] Re: mthca and LinuxBIOS |
| |
On Fri, Aug 05, 2005 at 04:06:06PM -0700, Linus Torvalds wrote: > > > On Fri, 5 Aug 2005, Greg KH wrote: > > On Fri, Aug 05, 2005 at 01:38:37PM -0700, Linus Torvalds wrote: > > > > But what's the real problem we are trying to fix here? > > We're screwing up the top 32 bits of the BAR when you resume it. Look at > the patch, you'll see the fix (the other part of the patch looks fine, but > then in order to not overwrite the upper bits with zero again when doing > the _next_ - nonexistent - BAR update, we need to have something that > avoids writing the next BAR).
ISTR making comments before about the offending patch on linux-pci mailing list. Is this the same patch that assumes pci_dev->resource[i] == BAR[i] ? That's not true for 64-bit bars.
> Remember: a 64-bit BAR puts the upper 32 bits in what would otherwise be > the low 32 bits of the next BAR. Which is why we need to mark the next BAR > resource as _not_ being valid some way - so that we don't try to > (incorrectly) "restore" it and overwrite the high bits of the previous > BAR.
> Of course, this only hits the (very few) people who not only have 64-bit > PCI devices, but literally have them mapped in the 4GB+ region.
*lots* of PCI device now have 64-bit BAR. The first I'm aware of was LSI 53c896 card (Ultra 2 SCSI).
> Quite uncommon.
Assigning 4GB+ regions is uncommon because too often either the HW, the OS, or the driver would break. firmware keeps having to worry about legacy OSs.
grant - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |