Matthew Wilcox wrote:
Bad deduction. What's happening is that the write to the BAR is causing
it to overlap the decode for mmconfig space. So the mmconfig write to
set the BAR back never gets through.
I have a different idea to fix this problem. Instead of writing
0xffffffff, we could look for an unused bit of space in the E820 map and
write, say, 0xdfffffff to the low 32-bits of a BAR. Then it wouldn't
overlap, and we could find its size using MMCONFIG.
Let me see if I understand this correctly.
Writing this BAR with 0xffffffff causes it to decode all further mmconfig
references based at addr 0xfxxxxxxx as its own?
If I've got that right, then why don't any of the other BARs do that? Is
it because this one's a 64-bit BAR?
AFIK, there are no devices out there that require 32-bits of address
space, so using 0xdfffffff in the low register would certainly work.
However, the PCI spec says that we should be able to write 0xffffffff
to the BAR, buggy BIOS and hardware notwithstanding.
Does anybody see that change as being within the purview of the patch-set
I am proposing? Or is that another patch for another time?
--
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]
