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.
It'd be interesting to see at what access it ran into trouble next, at
least if it's consistent. Could be that some device doesn't like having
the decode disabled..
--
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]
