Jesse Barnes wrote:
On Tuesday, May 22, 2007, Robert Hancock wrote:
Eww. I don't see where we disable the decode at all while we probe the
BARs on the device. That seems like a bad thing, especially with the way
we probe 64-bit BARs (do the low 32 bits first and then the high 32
bits). This means the base address effectively gets set to 0xfffffff0
momentarily, which might cause some issues.
I'm a bit shocked that things work as well as they do without the
disabling...
I'd try adding some code inside pci_setup_device (drivers/pci/probe.c)
to disable PCI_COMMAND_IO and PCI_COMMAND_MEMORY on the device when
probing devices with the standard header type and then restoring the
previous command bits afterwards, and see what effect that has. It'll be
interesting if it does, since obviously it seems to work as it is with
non-MMCONFIG access methods. Maybe the base address being set like that
interferes with MMCONFIG access itself somehow?
I tried that, and it seems to get past probing the graphics device at
least, but it hangs a bit later. It could be that the enable/disable I
added wasn't correct though, I didn't check to see which one I should
disable in the command word, which may be a problem (just disabled them
both every probe). I'll try again with more precise enable/disable
semantics.
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..
--
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]
