Re: Ignore disabled ROM resources at setup

[Linus Torvalds]

On Mon, 29 Aug 2005, Linus Torvalds wrote:
> 
> What you want is a "zombie state", where we write the partial information 
> to hardware. It's what we used to do, but it's certainly no more logical 
> than what it does now, and it led to problem reports.

Btw, the fundamental reason for the change is that x86 used to not ever 
touch any ROM resources _at_all_ by default, unless you used the "pci=rom" 
kernel command line switch.

But that got changed, and in an effort to make x86 more like all the other
architectures, it now uses the generic setup-bus stuff (which used to be
"generic, but not x86", since the BIOS tends to set up all PCI buses on
PC's) that probes all resources (including rom resources) to see how big
they are etc.

That meant that suddenly the ROM resources _did_ get sized up and written,
even if they didn't actually get enabled. So on an x86, 2.6.12 would never
touch the ROM resource at all, while for a while in 2.6.13-rc it would
write it with a disabled value by default.

And that's the thing that broke. 

So 2.6.13 is being "safe". It allocates the space for the ROM in the
resource tables, but it neither enables it nor does it write the
(disabled) address out to the device, since both of those actions have
been shown to break on PC's. And sadly (or happily, depends on your
viewpoint), PC's have a _much_ wider range of hardware, so they are the
ones we have to work around.

So yes, behaviour changed, but it changed exactly because not changing it 
leads to problems. So what you will find is that /sbin/lspci actually 
understands this situation:

	01:00.0 VGA compatible controller: ATI Technologies Inc Radeon Mobility M7 LW [Radeon Mobility 7500] (prog-if 00 [VGA])
		...
	        [virtual] Expansion ROM at 90220000 [disabled] [size=128K]
		...
	30: 00 00 00 00 58 00 00 00 00 00 00 00 0a 01 08 00

Notice how the hardware ROM base at 0x30 is set to "00 00 00 00", but 
because the resource allocation has been made and the resource shows up in 
/sys, lspci shows the disabled allocation correctly. That's really how any 
kernel user will need to understand it too: the allocation exists, but 
since it's not enabled, the hardware hasn't been told.

			Linus
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/