On Fri, 7 Nov 2003, Jon Smirl wrote:
>
> I should be more specific, it's mapping the ROM into PCI space that the kernel
> doesn't know about. Of course the kernel knows about the mapping from PCI space
> to user space. During a hotplug event the kernel could map the new device on top
> of the ROM in PCI space.

Indeed. This is not just a theoretical issue - it happens all the time in 
real life.

I literally have a laptop that would lock up when a CardBus card was
inserted. Guess why? The cardbus code (equivalent to PCI hotplug, it's
really just electrically different) allocated IO range 0x1000-0x10ff to
the cardbus controller, and there was a range of IO ports that had been 
allocated to that area without the kernel being told. Boom.

No, it wasn't XFree86 - it was the BIOS. The southbridge has some magic 
ACPI control registers that get mapped by firmware, and the kernel didn't 
know about them, since they weren't part of the standard PCI BAR mapping. 

But the point is that because the kernel didn't know about the allocation, 
the kernel didn't know to avoid it when a new PCI device showed up.

This was fixed by adding a proper kernel quirk to tell the kernel about
the magic APCI registers on the southbridge - there's a lot of those
around from before. Problem solved.

But this is an issue regardless of who does the configuration and whether 
it is IO or memory-mapped PCI space. You end up having strange quirks that 
hit only certain machines depending on just how the PCI range is 
allocated. And it's a _bitch_ to debug, since quite often when these 
things go wrong, the PCI bus literally locks up (ie things like NMI 
watchdogs etc won't help, and there are no kernel messages anywhere).

Not fun. 

                Linus



-------------------------------------------------------
This SF.Net email sponsored by: ApacheCon 2003,
16-19 November in Las Vegas. Learn firsthand the latest
developments in Apache, PHP, Perl, XML, Java, MySQL,
WebDAV, and more! http://www.apachecon.com/
_______________________________________________
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel

Reply via email to