| lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
|
Open Source and information security mailing list archives
| ||
|
Message-ID: <86802c440805131444y2c295a5ew6cb739350632a731@mail.gmail.com>
Date: Tue, 13 May 2008 14:44:10 -0700
From: "Yinghai Lu" <yhlu.kernel@...il.com>
To: "Gary Hade" <garyhade@...ibm.com>
Cc: jbarnes@...tuousgeek.org, linux-kernel@...r.kernel.org,
linux-pci@...r.kernel.org
Subject: Re: [PATCH] PCI: boot parameter to avoid expansion ROM memory allocation
On Tue, May 13, 2008 at 2:11 PM, Yinghai Lu <yhlu.kernel@...il.com> wrote:
>
> On Tue, May 13, 2008 at 2:00 PM, Gary Hade <garyhade@...ibm.com> wrote:
> >
> > On Tue, May 13, 2008 at 10:48:03AM -0700, Yinghai Lu wrote:
> > > On Mon, May 12, 2008 at 3:30 PM, Gary Hade <garyhade@...ibm.com> wrote:
> > > > On Mon, May 12, 2008 at 02:43:44PM -0700, Yinghai Lu wrote:
> > > > > On Mon, May 12, 2008 at 1:57 PM, Gary Hade <garyhade@...ibm.com> wrote:
> > > > <snip>
> > > >
> > > > > > --- linux-2.6.26-rc2/arch/x86/pci/common.c.orig 2008-05-12 10:59:58.000000000 -0700
> > > > > > +++ linux-2.6.26-rc2/arch/x86/pci/common.c 2008-05-12 11:22:05.000000000 -0700
> > > > > > @@ -121,6 +121,21 @@ void __init dmi_check_skip_isa_align(voi
> > > > > > dmi_check_system(can_skip_pciprobe_dmi_table);
> > > > > > }
> > > > > >
> > > > > > +static void __devinit pcibios_fixup_device_resources(struct pci_dev *dev)
> > > > > > +{
> > > > > > + struct resource *rom_r = &dev->resource[PCI_ROM_RESOURCE];
> > > > > > +
> > > > > > + if (pci_probe & PCI_NOASSIGN_ROMS) {
> > > > > > + if (rom_r->parent)
> > > > > > + return;
> > > > > > + if (rom_r->start) {
> > > > > > + /* we deal with BIOS assigned ROM later */
> > > > > > + return;
> > > > > > + }
> > > > > > + rom_r->start = rom_r->end = rom_r->flags = 0;
> > > > > > + }
> > > > > > +}
> > > > > > +
> > > > > > /*
> > > > > > * Called after each bus is probed, but before its children
> > > > > > * are examined.
> > > > > > @@ -128,7 +143,11 @@ void __init dmi_check_skip_isa_align(voi
> > > > > >
> > > > > > void __devinit pcibios_fixup_bus(struct pci_bus *b)
> > > > > > {
> > > > > > + struct pci_dev *dev;
> > > > > > +
> > > > > > pci_read_bridge_bases(b);
> > > > > > + list_for_each_entry(dev, &b->devices, bus_list)
> > > > > > + pcibios_fixup_device_resources(dev);
> > > > > > }
> > > > >
> > > > > or put check
> > > > > + if (pci_probe & PCI_NOASSIGN_ROMS) {
> > > > >
> > > > > out of loop?
> > > >
> > > > I could certainly do that but I had intended that the new
> > > > pcibios_fixup_device_resources function act as a container where
> > > > other kinds of fixups could be added later. Do you (or others)
> > > > think the additional cycles consumed by this approach are an
> > > > issue here?
> > >
> > > ok, then wonder if we can don't assign roms for x86_64 by default.
> >
> > No, I don't think so. ..at least not by me! :)
> >
> > There were some lkml/linux-pci visible discussions back in
> > November-December of last year where I floated the idea
> > of making PCI expansion ROM memory non-assignment the default:
> > http://marc.info/?l=linux-kernel&m=119742188215024&w=2
> > http://marc.info/?l=linux-kernel&m=119689499508369&w=2
> > I did not hear any objections so I went ahead and submitted
> > the change which entered mainline at 2.6.25-rc1 but it was
> > sternly evicted last week because of a reported regression
> > that it had caused:
> > http://marc.info/?l=linux-kernel&m=121029093331908&w=2
> > Attachments to http://bugs.freedesktop.org/show_bug.cgi?id=15523
> > indicate that a 2.6.25-rc2 x86_64 kernel was being used.
> >
> >
> > >
> > > can we use pci rom in 64 bit kernel?
> >
> > Sorry, not sure if I understand this question. I hope the
> > above answers it.
>
> ok, i think the driver could reload fw in the option rom to reset the
> controlller in pci card.
> i don't think there is other usage for the option rom after OS loaded,
> except option rom contain other run-time code...
>
> so could disable them all, and use pci-quirks to enable that for the
> device/driver need it.
interesting x log
good:
(II) RADEON(3): RADEONScreenInit e8000000 67108864 0
(==) RADEON(3): Write-combining range (0xec000000,0x4000000)
(WW) RADEON(3): Cannot read colourmap from VGA. Will restore with default
Entering TV Save
Save TV timing tables
saveTimingTables: reading timing tables
TV Save done
disable montype: 1
(II) RADEON(3): RADEONInitMemoryMap() :
(II) RADEON(3): mem_size : 0x08000000
(II) RADEON(3): MC_FB_LOCATION : 0xefffe800
(II) RADEON(3): MC_AGP_LOCATION : 0xffffffc0
(II) RADEON(3): Depth moves disabled by default
(II) RADEON(3): Memory manager initialized to (0,0) (1280,8191)
(II) RADEON(3): Reserved area from (0,1200) to (1280,1202)
(II) RADEON(3): Largest offscreen area available: 1280 x 6989
bad:
(II) RADEON(2): RADEONScreenInit e8000000 0 0
(==) RADEON(2): Write-combining range (0xe8000000,0x400000)
Entering TV Save
Save TV timing tables
saveTimingTables: reading timing tables
TV Save done
disable montype: 3
(II) RADEON(2): RADEONInitMemoryMap() :
(II) RADEON(2): mem_size : 0x04000000
(II) RADEON(2): MC_FB_LOCATION : 0xebffe800
(II) RADEON(2): MC_AGP_LOCATION : 0xffffffc0
(II) RADEON(2): Depth moves disabled by default
(EE) RADEON(2): Memory manager initialization to (0,0) (1280,819) failed
Fatal server error:
AddScreen/ScreenInit failed for driver 2
so what is 67108864? the rom BAR?
YH
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists