On 4/24/06, Matthew Reppert <[email protected]> wrote:
> > I've also got a Promise PDC20268 whose expansion ROM seems to have made a
> > similar move (from ff8f8000 to c6920000), but the ATA devices attached to
> > that controller seem to work fine under 2.6.17-rc2.
>
> Also, on 2.6.17-rc2, if I do a hexdump of the PCI config space for the
> RADEON 7000 via sysfs once Linux boots, it still says the ROM is located
> at ff8c0000, even though I get this message during boot:
>
> PCI: pbus will assign resource 0000:01:0c.0
> PCI: assigning resource #6 for 0000:01:0c.0 (start 0)
> got res [c6900000:c691ffff] bus [c6900000:c691ffff] flags 7200 for BAR 6 of
> 0000:01:0c.0
To make the sysfs rom attribute work, "echo 1 >rom". Then use 'hexdump
-C rom | more' to see the ROM contents. If you get the video ROM
contents when you do this, then the ROM is where the kernel thinks it
is. If you get FFFF or some other ROM then something like X has moved
the ROM without the kernel's knowledge. Obviously, moving ROMs
without telling the kernel is a good way to mess up your system.
If your system locks up after "echo 1 >rom" on a disk controller, then
you have one of the few disk controllers that didn't bother to
implement full address decoding for the ROM. "echo 1 >rom". should
always work for video ROMs.
Read http://people.freedesktop.org/~jonsmirl/graphics.html if you want
to know more about the evils of X and it's use of the PCI bus.
--
Jon Smirl
[email protected]
-
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]
