Why do we probe option roms at 2K boundaries?

Why do we probe option roms at 2K boundaries?

[Dan Williams]

Hi Alan,

I developed support for mdadm to enumerate the capabilities of an
Intel(r) Matrix Storage Technology (software RAID) platform by
interrogating a data structure stored in option-rom memory.  My initial
implementation involved blindly scanning from c0000 to f0000 in 512 byte
increments.  Neil and others pointed out that this may not be a safe
operation, so I decided to grab the kernel's probe_roms() implementation
under the assumption that it is safe by virtue of its exposure.

Recently Hans has been working to get Fedora up and running on a recent
Intel software RAID platform and noticed that the option-rom is no
longer visible with the 2K aligned scan.  I.e. he needed to make the
following changes to the mdadm probe_roms() routine:

diff -up mdadm-3.0/probe_roms.c~ mdadm-3.0/probe_roms.c
--- mdadm-3.0/probe_roms.c~	2009-06-02 07:48:29.000000000 +0200
+++ mdadm-3.0/probe_roms.c	2009-07-13 16:24:21.000000000 +0200
@@ -220,7 +220,7 @@ void probe_roms(void)
 
 	/* video rom */
 	upper = adapter_rom_resources[0].start;
-	for (start = video_rom_resource.start; start < upper; start += 2048) {
+	for (start = video_rom_resource.start; start < upper; start += 512) {
 		rom = isa_bus_to_virt(start);
 		if (!romsignature(rom))
 			continue;
@@ -239,7 +239,7 @@ void probe_roms(void)
 		break;
 	}
 
-	start = (video_rom_resource.end + 1 + 2047) & ~2047UL;
+	start = (video_rom_resource.end + 1 + 511) & ~511UL;
 	if (start < upper)
 		start = upper;
 
@@ -255,7 +255,7 @@ void probe_roms(void)
 	}
 
 	/* check for adapter roms on 2k boundaries */
-	for (i = 0; i < ARRAY_SIZE(adapter_rom_resources) && start < upper; start += 2048) {
+	for (i = 0; i < ARRAY_SIZE(adapter_rom_resources) && start < upper; start += 512) {
 		rom = isa_bus_to_virt(start);
 		if (!romsignature(rom))
 			continue;
@@ -273,7 +273,7 @@ void probe_roms(void)
 		adapter_rom_resources[i].start = start;
 		adapter_rom_resources[i].end = start + length - 1;
 
-		start = adapter_rom_resources[i++].end & ~2047UL;
+		start = adapter_rom_resources[i++].end & ~511UL;
 	}
 }
 
Is this safe?  Should the kernel be updated as well?  I am assuming that
you were the one that originally introduced the 2K aligned scan with
this commit from the historical git:

commit 3bcbf341ca4e71b93be52eac6f6f5f698c70f0d9
Author: alan <alan>
Date:   Tue Apr 8 16:42:23 2003 +0000

    [PATCH] add but do not yet use mach specific definitions for ports etc on PC
    
    BKrev: 3e92fbefFSaWWI1bUJHNKOjfyZlfkQ

It was subsequently updated here but the alignment constraints remained
intact.

commit 8cc489a8f5a7aa83ac370480784af0206f2ce57b
Author: akpm <akpm>
Date:   Mon Apr 12 21:57:08 2004 +0000

    [PATCH] i386 probe_roms(): fixes
    
    From: Rene Herman <rene.herman@keyaccess.nl>
    
    This patch tries to improve the i386/mach-default probe_roms().  This also
    c99ifies the data, adds an IORESOURCE_IO flag for the I/O port resources,
    an IORESOURCE_MEM flag for the VRAM resource, IORESOURCE_READONLY |
    IORESOURCE_MEM for the ROM resources and adds two additional "adapter ROM
    slots" (for a total of 6) since it now also scans the 0xe0000 segment.
    
    BKrev: 407b10b4nrXSAT3lFi4Io1Kpp4Q8Jw


Thanks for the help,
Dan

Re: Why do we probe option roms at 2K boundaries?

[Alan Cox]

> interrogating a data structure stored in option-rom memory.  My initial
> implementation involved blindly scanning from c0000 to f0000 in 512 byte
> increments.  Neil and others pointed out that this may not be a safe

It isn't safe. If you hit certain ISA devices your system will drop dead.
OTOH I doubt anyone has an intel matrix raid controller and a WD80x3 on
the same box ;)

> Recently Hans has been working to get Fedora up and running on a recent
> Intel software RAID platform and noticed that the option-rom is no
> longer visible with the 2K aligned scan.  I.e. he needed to make the
> following changes to the mdadm probe_roms() routine:

Option ROMs should be 2K aligned. Is your data structure part of a ROM or
an actual ROM header ?

> Is this safe?  Should the kernel be updated as well?  I am assuming that
> you were the one that originally introduced the 2K aligned scan with
> this commit from the historical git:

Actually I don't think that was me, don't remember it anyway.

The man to bug at the moment on ROM magic is probably H Peter Anvin
however.

Re: Why do we probe option roms at 2K boundaries?

[Jon Smirl]

On Wed, Jul 15, 2009 at 7:10 PM, Alan Cox<alan@lxorguk.ukuu.org.uk> wrote:
>> interrogating a data structure stored in option-rom memory.  My initial
>> implementation involved blindly scanning from c0000 to f0000 in 512 byte
>> increments.  Neil and others pointed out that this may not be a safe
>
> It isn't safe. If you hit certain ISA devices your system will drop dead.
> OTOH I doubt anyone has an intel matrix raid controller and a WD80x3 on
> the same box ;)

Random link from google, slide 21
http://download.microsoft.com/download/9/8/f/98f3fe47-dfc3-4e74-92a3-088782200fe7/TWAR05005_WinHEC05.ppt

PCI 3.0+ allows 512b alignment, but you must first make sure you are
on a PCI 3.0+ system.

>
>> Recently Hans has been working to get Fedora up and running on a recent
>> Intel software RAID platform and noticed that the option-rom is no
>> longer visible with the 2K aligned scan.  I.e. he needed to make the
>> following changes to the mdadm probe_roms() routine:
>
> Option ROMs should be 2K aligned. Is your data structure part of a ROM or
> an actual ROM header ?
>
>> Is this safe?  Should the kernel be updated as well?  I am assuming that
>> you were the one that originally introduced the 2K aligned scan with
>> this commit from the historical git:
>
> Actually I don't think that was me, don't remember it anyway.
>
> The man to bug at the moment on ROM magic is probably H Peter Anvin
> however.
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
>



-- 
Jon Smirl
jonsmirl@gmail.com

Re: Why do we probe option roms at 2K boundaries?

[Dan Williams]

On Wed, 2009-07-15 at 16:13 -0700, Jon Smirl wrote:
> On Wed, Jul 15, 2009 at 7:10 PM, Alan Cox<alan@lxorguk.ukuu.org.uk> wrote:
> >> interrogating a data structure stored in option-rom memory.  My initial
> >> implementation involved blindly scanning from c0000 to f0000 in 512 byte
> >> increments.  Neil and others pointed out that this may not be a safe
> >
> > It isn't safe. If you hit certain ISA devices your system will drop dead.
> > OTOH I doubt anyone has an intel matrix raid controller and a WD80x3 on
> > the same box ;)
> 
> Random link from google, slide 21
> http://download.microsoft.com/download/9/8/f/98f3fe47-dfc3-4e74-92a3-088782200fe7/TWAR05005_WinHEC05.ppt
> 
> PCI 3.0+ allows 512b alignment, but you must first make sure you are
> on a PCI 3.0+ system.

Thanks, I believe this may be the missing difference between my test
system and Hans'.

Re: Why do we probe option roms at 2K boundaries?

[Hans de Goede]

Hi all,

On 07/16/2009 02:08 AM, Dan Williams wrote:
> On Wed, 2009-07-15 at 16:13 -0700, Jon Smirl wrote:
>> On Wed, Jul 15, 2009 at 7:10 PM, Alan Cox<alan@lxorguk.ukuu.org.uk>  wrote:
>>>> interrogating a data structure stored in option-rom memory.  My initial
>>>> implementation involved blindly scanning from c0000 to f0000 in 512 byte
>>>> increments.  Neil and others pointed out that this may not be a safe
>>> It isn't safe. If you hit certain ISA devices your system will drop dead.
>>> OTOH I doubt anyone has an intel matrix raid controller and a WD80x3 on
>>> the same box ;)
>> Random link from google, slide 21
>> http://download.microsoft.com/download/9/8/f/98f3fe47-dfc3-4e74-92a3-088782200fe7/TWAR05005_WinHEC05.ppt
>>
>> PCI 3.0+ allows 512b alignment, but you must first make sure you are
>> on a PCI 3.0+ system.
>
> Thanks, I believe this may be the missing difference between my test
> system and Hans'.
>

Probably, I'll happily test any patches for this you come up with, note that I'm
leaving for a week of vacation tomorrow, so it might take some time for me to
get back to you.

Regards,

Hans