| 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
| ||
|
Date: Sat, 16 Feb 2013 07:55:36 -0800 (PST)
From: Zhenzhong Duan <zhenzhong.duan@...cle.com>
To: <ben@...adent.org.uk>
Cc: <tmhikaru@...il.com>, <linux-kernel@...r.kernel.org>
Subject: Re: Re: 3.2.38 most of the time has 100% cpu use reported
On Sat, Feb 16, 2013 at 05:18:10AM +0000, Ben Hutchings wrote：
> On Fri, 2013-02-15 at 22:23 -0500, tmhikaru@...il.com wrote:
> > On Thu, Feb 14, 2013 at 05:04:07AM +0000, Ben Hutchings wrote:
> > > On Tue, 2013-02-12 at 00:01 -0500, tmhikaru@...il.com wrote:
> > > > Okay, I finally have located the patch causing this bizzare
> problem
> > > > for me. Before I discuss it, I'm going to drag out the kernel
> bug reporting
> > > > guidelines and try to make a proper bug report out of this.
> > > >
> > > > [1.] One line summary of the problem:
> > > > 3.2.38 most of the time has 100% cpu use reported
> > > >
> > > > [2.] Full description of the problem/report:
> > > > Reverse applying the patch for
> > > >
> > > > [9a1f08a1a192f9177d7063d903773aed800b840f]
> drivers/firmware/dmi_scan.c: fetch dmi version from SMBIOS if it
> exists
> > > >
> > > > on top of a clean 3.2.38 tree makes the problem go away.
> > > [...]
> > > > I have to admit I have no idea what the patch I'm reversing
> actually does,
> > >
> > > It changes how we look for the version of a BIOS interface (DMI
> or
> > > SMBIOS). All the code that it touches, and the version number
> variable,
> > > are discarded after boot and therefore can have very limited
> effect on
> > > what happens later!
> >
> > Actually upon poking about, I noticed something VERY different about
> what
> > the patch does to my computer during the boot process. Let me show
> you
> > dmesg output from a good kernel without the patch, then a bad one
> with the
> > patch, then I'll point out the important differences I noticed:
> [...]
> > Important bits I noticed: The 'bad' kernel initially boots with
> acpi
> > disabled, then later turns it back on, whereas the 'good' one boots
> with
> > acpi completely enabled with no problems.
> >
> > Also, very early on just after yelling about the NX bit not existing
> in my
> > cpu, it says this: (-good/+bad)
> >
> > -[ 0.000000] DMI 2.3 present.
> > -[ 0.000000] DMI: ECS M848A/M848A, BIOS 07.00T 04/02/01
> > +[ 0.000000] Legacy DMI 0.0 present.
> > +[ 0.000000] DMI: , BIOS
>
> Oh wow, this has really gone very wrong.
>
> > The 'good' kernel without the patch finds something for DMI (That is
> in fact
> > my motherboard model number, so I know it's doing *something* right)
> whereas
> > the bad one with the patch... Does not.
> >
> > Anyway, I suppose I could try using acpi=force as the kernel
> suggests for a
> > workaround for now, but I'm still convinced something went wrong
> with that
> > patch now more than ever. Due to the fact that ACPI gets reenabled
> I didn't
> > catch on that something was going wrong so early in the boot process
> with it
> > until now.
> >
> > One thing I want to emphasize is that the only difference between
> the two
> > kernels is that lone patch.
> >
> > As for perf top, I tried running it as you suggested, but I honestly
> can't
> > figure out how to get this thing to dump output to a file. Every
> time I
> > redirect stdio/stderr I get a empty file, I don't know what I'm
> doing wrong.
> > Any tips?
> [...]
>
> Don't worry about it - I think the log messages are a pretty good
> clue.
>
> Does this patch fix the log messages and/or the other issues?
>
> --- a/drivers/firmware/dmi_scan.c
> +++ b/drivers/firmware/dmi_scan.c
> @@ -416,6 +416,9 @@ static int __init dmi_present(const char __iomem
> *p)
>
> memcpy_fromio(buf, p, 15);
> if (dmi_checksum(buf, 15)) {
> + print_hex_dump(KERN_INFO, "DMI entry: ", DUMP_PREFIX_NONE,
> + 16, 1, buf, 15, false);
> +
> dmi_num = (buf[13] << 8) | buf[12];
> dmi_len = (buf[7] << 8) | buf[6];
> dmi_base = (buf[11] << 24) | (buf[10] << 16) |
> @@ -442,10 +445,12 @@ static int __init dmi_present(const char __iomem
> *p)
> static int __init smbios_present(const char __iomem *p)
> {
> u8 buf[32];
> - int offset = 0;
>
> memcpy_fromio(buf, p, 32);
> if ((buf[5] < 32) && dmi_checksum(buf, buf[5])) {
> + print_hex_dump(KERN_INFO, "SMBIOS entry: ", DUMP_PREFIX_NONE,
> + 16, 1, buf, 16, false);
> +
> dmi_ver = (buf[6] << 8) + buf[7];
>
> /* Some BIOS report weird SMBIOS version, fix that up */
> @@ -461,9 +466,9 @@ static int __init smbios_present(const char
> __iomem *p)
> dmi_ver = 0x0206;
> break;
> }
> - offset = 16;
> + return dmi_present(p + 16);
> }
> - return dmi_present(buf + offset);
> + return 1;
> }
>
> void __init dmi_scan_machine(void)
> --- END ---
Thanks Ben fix it.
Acked-by: Zhenzhong Duan <zhenzhong.duan@...cle.com>
--
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