| 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: <20080514162015.GA6713@us.ibm.com> Date: Wed, 14 May 2008 09:20:15 -0700 From: Gary Hade <garyhade@...ibm.com> To: Gary Hade <garyhade@...ibm.com> Cc: Yinghai Lu <yhlu.kernel@...il.com>, Jesse Barnes <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 05:07:02PM -0700, Gary Hade wrote: > On Tue, May 13, 2008 at 04:23:55PM -0700, Yinghai Lu wrote: > > On Tue, May 13, 2008 at 3:28 PM, Jesse Barnes <jbarnes@...tuousgeek.org> wrote: > > > > > 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... > > > > > > On graphics devices it's used for more than just POSTing (in fact POSTing is > > > the least of its uses these days). The ROM often contains tables describing > > > the specific hardware configuration of a given board, including output > > > information, extra supported modes, etc. > > > > > > On other devices, it can be used to store default settings (this is common for > > > SCSI cards iirc, though I'm not sure how much Linux drivers use this info). > > > > > > > > > > so could disable them all, and use pci-quirks to enable that for the > > > > device/driver need it. > > > > > > Since it's probably only big systems that really need the extra address space, > > > I'd rather to the opposite: allocate ROM space by default and let a boot > > > option avoid it. > > > > that boot option will get rid of that ROM BAR for all devices... > > big system could use several graphical cards that need ROM BAR and > > several cards that don't need ROM BAR. > > Correct, not a perfect solution but better than we have right now. ...but don't let this comment make you think that I am not in favor of something like you are suggesting. I am interested in getting the 'pci=norom' change into mainline quickly but it is obviously less than ideal for the long term. Jesse, any idea how many different devices absolutely need memory allocated for their expansion ROMs? Gary -- Gary Hade System x Enablement IBM Linux Technology Center 503-578-4503 IBM T/L: 775-4503 garyhade@...ibm.com http://www.ibm.com/linux/ltc -- 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