linux-kernel - Re: [PATCH] quiet MMCONFIG related printks

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

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-Id: <1167843673.3127.162.camel@laptopd505.fenrus.org>
Date:	Wed, 03 Jan 2007 09:01:13 -0800
From:	Arjan van de Ven <arjan@...radead.org>
To:	Jesse Barnes <jbarnes@...tuousgeek.org>
Cc:	linux-kernel@...r.kernel.org, Andrew Morton <akpm@...l.org>
Subject: Re: [PATCH] quiet MMCONFIG related printks

On Wed, 2007-01-03 at 08:49 -0800, Jesse Barnes wrote:
> On Wednesday, January 3, 2007 5:53 am, Arjan van de Ven wrote:
> > On Mon, 2007-01-01 at 21:01 -0800, Jesse Barnes wrote:
> > > Using MMCONFIG for PCI config space access is simply an
> > > optimization, not a requirement.  Therefore, when it can't be used,
> > > there's no need for KERN_ERR level message.  This patch makes the
> > > message a KERN_INFO instead to reduce some of the noise in a kernel
> > > boot with the 'quiet' option. (Note that this has no effect on a
> > > normal boot, which is ridiculously verbose these days.)
> >
> > this is wrong, please leave this loud complaint in...
> 
> So the issues as I understand them:
>   o some BIOSes are broken and don't properly map MCFG space (though
>     according to Petr V. reserving MCFG space in e820 is optional, so
>     the test may be slightly wrong as-is)

it's optional but it's the best test we have for "is the bios total
crap" ;(

>   o MCFG space is required for (many) PCIe devices (any regular PCI
>     devices?)

it's not required for *many* (it can't be, windows XP doesn't use MCFG),
but it's required for some of the advanced PCI-E features

>   o often, there's nothing the user can do to address the points above

other than complain to the vendor.

> 
> So where does that leave us?  I've got what I consider to be a stupid 
> error message in my log.

contact your bios vendor.

>   My system behavior isn't affected in any way 
> (at least that I can tell), yet I get a loud complaint at boot time.
> 
> I guess I just have to live with it?

We really really should complain about bios issues. If only to make sure
vendors who do pay attention to linux have a chance of finding and
fixing them (and via the firmware kit, several big vendors pay attention
early on nowadays)

-- 
if you want to mail me at work (you don't), use arjan (at) linux.intel.com
Test the interaction between Linux and your BIOS via http://www.linuxfirmwarekit.org

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