linux-kernel - Re: 3.2.38 most of the time has 100% cpu use reported

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: <1360991890.5374.414.camel@deadeye.wl.decadent.org.uk>
Date:	Sat, 16 Feb 2013 05:18:10 +0000
From:	Ben Hutchings <ben@...adent.org.uk>
To:	tmhikaru@...il.com
Cc:	linux-kernel@...r.kernel.org,
	Zhenzhong Duan <zhenzhong.duan@...cle.com>
Subject: Re: 3.2.38 most of the time has 100% cpu use reported

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

If not, can you report back the 'SMBIOS entry:' and 'DMI entry:' log
lines this produces.

Ben.

-- 
Ben Hutchings
Computers are not intelligent.	They only think they are.

Download attachment "signature.asc" of type "application/pgp-signature" (829 bytes)