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 for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Date:	Thu, 20 Sep 2007 17:47:10 -0600
From:	"Jordan Crouse" <jordan.crouse@....com>
To:	pommnitz@...oo.com
cc:	cebbert@...hat.com, linux-kernel@...r.kernel.org
Subject: Re: Problems with 2.6.23-rc6 on AMD Geode LX800

Chuck Ebbert wrote:

> On 09/20/2007 08:32 AM, Joerg Pommnitz wrote:
>> Hello all,
>> yesterday I tried to boot a kernel built from the current wireless-dev git
>> tree (ath5k branch)
>> on a MSEP800/A board (see http://www.milesie.co.uk/pdf/MSEP800.pdf). The
>> board
>> contains an AMD Geode LX800 CPU.
>> The wireless-dev tree is up to date with Linus kernel 2.6.23-rc6.
>> 
>> Attached is a photographic screen shot. The EIP value of c0378dd6 seems to
>> correspond with the
>> reserve_bootmem_core from System.map:
>> 
>> c0378d51 t free_bootmem_core
>> c0378da7 T free_bootmem
>> c0378db2 T free_bootmem_node
>> c0378dba t reserve_bootmem_core
>> c0378e14 T reserve_bootmem
>> c0378e1f T reserve_bootmem_node
>>

> Can you post disassembled code for that function?

Its hitting a bug - specifically (from bootmem.c:125):
BUG_ON(PFN_DOWN(addr) >= bdata->node_low_pfn);

I hit this problem on a db800 last week.  It went away with a newer
version of the BIOS, which doesn't help Joerg any, since its a different
board (though I think it is the same BIOS vendor).  Other BIOSes work
just fine with the same kernel image (including known troublemakers like
LinuxBIOS).  I believe that 2.6.22 was good, so some change must
have come along in 2.6.23-pre to cause the pain.  Or, it may have exposed
old breakage in the BIOS that was later repaired.

I'll do the math to figure out whats happening - and I'll check the release
notes to see what changed in the BIOS between the failing and working
version.  If anybody familiar with arch/i386 can think of something
new in the kernel that may have precipitated this, do let me know. :)

Jordan
-- 
Jordan Crouse
Systems Software Development Engineer 
Advanced Micro Devices, Inc.


-
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

Powered by Openwall GNU/*/Linux Powered by OpenVZ