[PATCH 0/2] 2.6.5-rc2{,-mm1} i386 probe_roms() damage

[Rene Herman]

Hi Andrew,

sending this to you because, well, I guess it's sort of mm-ish. Patch is
against 2.6.5-rc2-mm1, but applies (with two offsets) to 2.6.5-rc2 as
well. Please advice if you want me to pester someone else instead.

The i386 probe_roms() function has a fair number of problems currently:

- When you actually have an adapter ROM in the machine, your video ROM
  disappears. This is due to the pc9800 subarch merge that split it up
  in probe_video_rom(int roms) and probe_extension_roms(int roms), but
  expects a "roms++" in probe_video_roms() to have an effect outside of
  that function.

- The majority of VGA adapters these days host a ROM larger then 32K,
  yet the current code hardcodes a 32K ROM. The VGA BIOS "length" byte
  is normally valid (it in fact needs to be for a regular mainboard BIOS
  to accept it) and I've verified on a few dozen very new to very old
  VGAs that it is. However, assuming someone actually did not check for
  the length and checksum there for a reason, the safe thing to do here
  is accept the length byte when we also get a valid checksum.

- The current code scans 0xc0000 to 0xdffff for a video ROM while the
  standard PC thing to do (that which the BIOS does) is only scan for a
  video ROM starting between 0xc0000 and 0xc7fff. This means that on a
  headless- (or BIOS-less monochrome adapter-) box, the first adapter
  ROM found triggers the registration of a 32K "Video ROM" at hardcoded
  address 0xc0000, even when _nothing_ is present between 0xc0000 and
  0xc7fff.

- The current adapter ROM scan stops at 0xdffff, whether or not an
  extension ROM is present at 0xe0000. The PC thing to do is scan
  0xc8000 upto 0xdffff if an extension ROM is present, and upto 0xeffff
  when it's not (it's not/hardly ever).

- Adapter ROMs are called "Extension ROM", but the latter term is really
  better reserved for a motherboard extension ROM.

- Currently, the code happily starts scanning through a ROM it just
  registered looking for the next one (just does += 2048, even when
  that's inside the previous ROM) which is at least silly.

Unfortunately, this code is "subarched" between mach-default and
mach-pc9800, meaning the patch got a bit involved. Currently all this
code, and gobs of data, is defined (not just declared) in the header:

  include/asm-i386/mach-{default,pc9800}/mach_resources.h

which isn't nice. That .h really wants to be a .c. The first patch, in
the next message, does not change any code but only undoes the
probe_video_rom / probe_extension_roms split and moves the code to a new
file

  arch/i386/mach-{default,pc9800}/std_resources.c

with a header

  include/asm-i386/std_resources.h

for the prototypes only. The second patch overhauls the code itself for
mach-default. Please see comments on top of that patch for (yet more)
comments. It's tested on various machines, with and without adapter ROMs.

I haven't touched pc9800. Nothing should have changed though. The pc9800
author, as given in the code, is CCed.

Also, x86-64 inherits the probe_roms() code from 2.4, and while it
doesn't have the subarch specific problems, it has all others. I'll
convert it to if this i386 version is deemed desirable.

Rene.


-
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/