On Tue, Dec 18, 2007 at 10:21:50AM -0800, Linus Torvalds wrote:
> > https://bugzilla.redhat.com/show_bug.cgi?id=425794#c0
>
> That bugzilla entry doesn't even have a dmesg output or anything like
> that. I'd really like to see what the
I've added dmesg, /proc/iomem, and lspci -v output to that bug.
Basically, we have
c0000000-cfffffff : free
ddf00000-dfefffff : PCI Bus #04
e0000000-efffffff : pnp 00:0b
f0000000-fedfffff : less than 256MB
The annoying part is that there's no device (that I can see)
behind PCI Bus #04, so it might as well be disabled and that
entire d0000000-dfffffff area reclaimed.
> That patch might as well just do
>
> pci_mem_start = gapstart;
>
> and get rid of all that rounding code entirely, since the patch just
> assumes that it's safe to use memory after gapstart (which is known to not
> be true, and is the whole and only reason for that code in the first
> place: BIOSes *invariably* get resource allocation wrong, and forget to
> tell us about some resource they set up).
That would have been an excellent comment to add to that code then,
rather than just "rounding up to the next 1MB area", because purely
as rounding code it is erroneous.
> The *other* patch in the bugzilla entry seems more correct, in that yes,
> we should make sure that we don't allocate resources over 4G if the
> resource won't fit. That said, I think that patch is wrong too: we should
> just fix pcibios_align_resource() to check that case for MEM resouces (the
> same way it already knows about the magic rules for IO resources).
I'll give that patch a try, modified a tad to still include the
force_32_bit quirk.
> So I'd suggest just fixing pcibios_align_resource() instead. Something
> like the appended might work (and then you could perhaps quirk it to
> always clear the PCI_BASE_ADDRESS_MEM_TYPE_64 thing for VGA controllers,
That won't work, because PCI_BASE_ADDRESS_MEM_TYPE_64 controls how
many bits need to be written back to the BAR. If we changed that
to PCI_BASE_ADDRESS_MEM_TYPE_32, we wouldn't clear the high 32-bits
of the BAR.
> ... and that would be an X server issue!).
Of course, fixing the X server to *handle* 64-bit BARs is the correct
solution. I've no idea how involved that is, but I have a sneeking
suspicion that it uses that damned CARD32 datatype for everything.
r~
--
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]
