lkml.org 
[lkml]   [2005]   [Aug]   [5]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [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/

\
 
 \ /
  Last update: 2005-08-06 02:01    [W:0.155 / U:0.456 seconds]
©2003-2014 Jasper Spaans. Advertise on this site