Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1758943AbZCMUnT (ORCPT ); Fri, 13 Mar 2009 16:43:19 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1753773AbZCMUnJ (ORCPT ); Fri, 13 Mar 2009 16:43:09 -0400 Received: from vms173017pub.verizon.net ([206.46.173.17]:64472 "EHLO vms173017pub.verizon.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753817AbZCMUnH (ORCPT ); Fri, 13 Mar 2009 16:43:07 -0400 From: Gene Heskett Organization: Organization? very little To: Robin.Laing@drdc-rddc.gc.ca, LKML , David Newall Subject: New ASUS 1701 bios for M2N SLI DELUXE Date: Fri, 13 Mar 2009 16:42:54 -0400 User-Agent: KMail/1.11.0 (Linux/2.6.28.7; KDE/4.2.0; i686; ; ) MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7bit Content-disposition: inline Message-id: <200903131642.54925.gene.heskett@gmail.com> Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 4537 Lines: 93 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] [] warn_slowpath+0x6f/0x90 [ 0.000000] [] vsnprintf+0x3c0/0x7e0 [ 0.000000] [] panic+0x15/0xee [ 0.000000] [] pat_init+0x7c/0xa0 [ 0.000000] [] post_set+0x1c/0x50 [ 0.000000] [] dmi_string_nosave+0x4c/0x6d [ 0.000000] [] up+0x11/0x40 [ 0.000000] [] generic_get_mtrr+0xea/0x120 [ 0.000000] [] mtrr_trim_uncached_memory+0x7d/0x374 [ 0.000000] [] request_resource+0xa3/0x150 [ 0.000000] [] printk+0x17/0x1f [ 0.000000] [] e820_end_pfn+0xb5/0xd3 [ 0.000000] [] setup_arch+0x501/0xb68 [ 0.000000] [] release_console_sem+0x189/0x1d0 [ 0.000000] [] reserve_early_overlap_ok+0x3f/0x47 [ 0.000000] [] start_kernel+0x58/0x314 [ 0.000000] ---[ end trace 4eaa2a86a8e2da22 ]--- 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. 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. :) -- Cheers, Gene "There are four boxes to be used in defense of liberty: soap, ballot, jury, and ammo. Please use in that order." -Ed Howdershelt (Author) US Navy uses NT. Saddam, Gadafi, it's party time! -- Havlik Denis -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/