Re: New ASUS 1701 bios for M2N SLI DELUXE

From: Robert Hancock
Date: Fri Mar 13 2009 - 22:32:35 EST


Gene Heskett wrote:
Hi Robin, David and lkml list;

I said I would report.

I just reinstalled the 1502 version bios after spending the last 2 days trying to get an hours worth of uptime without an oops. Gave up.

David Newell and I have been trying to find the cause of the oops, but when the compile instructions David is sending me don't work, its a bit difficult to troubleshoot beyond renaming the function just to see if the oops follows the rename, which it does. And with the boot girations
to get a working radeonhd driver now broken again, apparently by the 'make mrproper' that David had me do, I'm now stuck on issue drivers for drm, radeon, and radeonhd and those are noticably slower.

So I'm back on the 1502 version of the bios, it does an oops as I sent before right at entering vmlinuz, which marks me tainted, but the machine is dead stable after that.

Here is another snip of that to refresh memories:
[ 0.000000] DMI 2.4 present.
[ 0.000000] Phoenix BIOS detected: BIOS may corrupt low RAM, working it around.
[ 0.000000] last_pfn = 0x120000 max_arch_pfn = 0x1000000
[ 0.000000] x86 PAT enabled: cpu 0, old 0x7040600070406, new 0x7010600070106
[ 0.000000] ------------[ cut here ]------------
[ 0.000000] WARNING: at arch/x86/kernel/cpu/mtrr/generic.c:404 generic_get_mtrr+0xea/0x120()
[ 0.000000] mtrr: your BIOS has set up an incorrect mask, fixing it up.
[ 0.000000] Modules linked in:
[ 0.000000] Pid: 0, comm: swapper Not tainted 2.6.28.7 #7
[ 0.000000] Call Trace:
[ 0.000000] [<c042858f>] warn_slowpath+0x6f/0x90
[ 0.000000] [<c05193b0>] vsnprintf+0x3c0/0x7e0
[ 0.000000] [<c0627a00>] panic+0x15/0xee
[ 0.000000] [<c041a78c>] pat_init+0x7c/0xa0
[ 0.000000] [<c040f9fc>] post_set+0x1c/0x50
[ 0.000000] [<c0733f35>] dmi_string_nosave+0x4c/0x6d
[ 0.000000] [<c0441031>] up+0x11/0x40
[ 0.000000] [<c040f7ea>] generic_get_mtrr+0xea/0x120
[ 0.000000] [<c071f91f>] mtrr_trim_uncached_memory+0x7d/0x374
[ 0.000000] [<c042e583>] request_resource+0xa3/0x150
[ 0.000000] [<c0627af0>] printk+0x17/0x1f
[ 0.000000] [<c071be82>] e820_end_pfn+0xb5/0xd3
[ 0.000000] [<c0719fc9>] setup_arch+0x501/0xb68
[ 0.000000] [<c0428d89>] release_console_sem+0x189/0x1d0
[ 0.000000] [<c071d027>] reserve_early_overlap_ok+0x3f/0x47
[ 0.000000] [<c07138a4>] start_kernel+0x58/0x314
[ 0.000000] ---[ end trace 4eaa2a86a8e2da22 ]---

That's not an oops, it's a warning. Those do normally taint the kernel. I don't think this should really be a WARN, IMHO, as it's a BIOS bug and not the kernel's fault, and it's fixed up the problem. CCing Yinghai Lu, which it looks like wrote this warning.


So based on that, I'll now go build a 2.6.29-rc8 and see how that runs.

The biggest problem with the 2.6.29 series is that apparently, for security reasons, they are now doing a PHY disable in a graceful shutdown, which none of the previous kernels knows how to re-enable.

So to reboot to the 2.6.28.7 stable, you have to use the front panel reset button to reboot or you will not have any onboard ethernet until you do a full, pull ALL the power plugs for at least 30 seconds (I go make a cup of tea, about 3 minutes) to reset the PHY's back to operational status. TBT,
the reset button is easier.

Frankly, that seems like a thoroughly busted security idea, but I suppose we're stuck with it.

I doubt it's for security reasons. Could be due to power management or suspend/resume changes?


It also seems to me, that to mark my kernel as tainted over a fix-up that makes the system dead stable, is executing the messenger. IMNSHO, its ASUS who ought to be shot for not having any method of filing a bug report against their crappy bios. 3 emails sent to the only address I was able to find for ASUS have had the same effect as sending them to /dev/null.

If anyone on the LKML knows how to contact ASUS, please advise them that there is at least one VERY unhappy camper/user of the $285 USD M2N SLI DELUXE motherboard, I'm sorry I ever laid eyes on it. The newly released version 1701 bios (it unzips as M2N-SLI-Deluxe-1701.BIN) still doesn't get it right AFAIAC. The kernel writers at least know what
to do about the older version bios. Maybe ASUS coded the new bios to get
past your test, but is it still fscked? That is certainly my opinion...

Thanks everybody. Now back to your regularly scheduled programming. :)


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/