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 [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
| |
 |