Jesse Barnes wrote:
On Tuesday, May 22, 2007 6:06 pm Robert Hancock wrote:
There was a big discussion about this back in 2002, in which Linus
wasn't overly enthused about disabling the decode during probing due
to risk of causing problems with some devices:
http://lkml.org/lkml/2002/12/19/145
In this particular case (64-bit BAR) we might be able to avoid the
problem by changing the order in which we probe the two halves of the
address, i.e. change the top half to 0xffffffff before messing with
the bottom half and then change it back last. That way, we end up
mapping it way to the top of 64-bit address space, which hopefully is
less likely to conflict..
Fixed it (finally). I don't think moving the 64 bit probing around
would make a difference, since we'd restore its original value anyway
before moving on to the 32 bit probe which is where I think the problem
is.
You couldn't just reorder the code the way it is now, you'd have to
rearrange the way we do things for 64-bit BARs:
-write FFFFFFFF to high part of 64-bit address (we end up moving the BAR
to 0xFFFFFFFFC0000000 for example)
-If any bits stick, we know what the size is now (more than 4GB of
decode), so just change it back, we're done
-If not, we need to check the low part, so write FFFFFFFF to low part of
64-bit address (BAR moves to 0xFFFFFFFFFFFFFFFF)
-Check which bits stick and calculate the address
-Change the low part of the address back (BAR moves to 0xFFFFFFFFC000000)
-Change the high part of the address back (BAR moves to the original
0xC0000000 address)
This means that at no point do we map the BAR anywhere near the top of
32-bit memory, so we should avoid this issue in this particular case. I
don't think this strategy is too likely to break anything, surely less
likely than disabling command bits. Jesse, you might want to try hacking
up something like this and see what happens.
--
Robert Hancock Saskatoon, SK, Canada
To email, remove "nospam" from [email protected]
Home Page: http://www.roberthancock.com/
-
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]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
