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: <1303566747.12067.10.camel@localhost.localdomain>
Date:	Sat, 23 Apr 2011 15:52:27 +0200
From:	Thomas Meyer <thomas@...3r.de>
To:	Yuhong Bao <yuhongbao_386@...mail.com>
Cc:	hpa@...or.com, chris@...muel.org, alan@...rguk.ukuu.org.uk,
	tglx@...utronix.de, mingo@...hat.com, x86@...nel.org,
	linux-kernel@...r.kernel.org
Subject: Re: FW: 2.6.38.3 and 2.6.39-rc4 hangs after "Booting the kernel"
 on quad Pentium Pro system

Am Samstag, den 23.04.2011, 03:47 -0700 schrieb Yuhong Bao:
> FYI, I walked Chris on how to use DOS DEBUG via private email, and below is the results after the INT 15, using the instruction sequence I posted on the mailing list.Notice HIMEM was not loaded. 
> 
> ----------------------------------------
> > From: chris@...muel.org
> > To: yuhongbao_386@...mail.com
> > Subject: Re: 2.6.38.3 and 2.6.39-rc4 hangs after "Booting the kernel" on quad Pentium Pro system
> > Date: Sat, 23 Apr 2011 18:55:44 +1000
> >
> > On Sat, 23 Apr 2011 06:28:26 PM Yuhong Bao wrote:
> >
> >> Actually, execute with G instead, and do it without HIMEM.SYS
> >> loaded.
> >
> > I couldn't see any HIMEM.SYS on the FreeDOS floppy (including
> > looking for hidden files) so I'm presuming it's not there. There
> > was a HIMEM.EXE so I've renamed it to NOHIMEM.OFF in the hope
> > that it won't get executed, even in the safe mode I was using.
> >
> > Using G instead of A I now get:
> >
> > -G
> > Unexpected breakpoint interrupt.
> > AX=3C00 BX=0F00 CX=0000 DX=0000 SP=FFFE BP=0000 SI=0000 DI=0000
> > DS=2890 ES=2890 SS=2890 CS=2890 IP=0106 NV UP DI PL NZ NA PE NC
> > 2890:0106 0000 ADD [BX+SI], AL D:0F00=00
> > -
> >

so your bios seems to report the size in AX/BX. the code in
arch/x86/boot/memory.c move the return sizes from CX/DX into AX/BX, when
CX or DX is not zero.

Could you try to change the line:

	} else if (oreg.ax == 15*1024) {
		boot_params.alt_mem_k = (oreg.dx << 6) + oreg.ax;

to
	} else if (oreg.ax == 15*1024) {
		boot_params.alt_mem_k = (oreg.bx << 6) + oreg.ax;

That should fix your misdetection.

The assembler code in arch/i386/boot/setup.S seemed to move AX/BX into
CX/DX, when CX and(!) DX were zero. Then used CX/DX to calc the memory
size.

PS: gitk --follow arch/x86/boot/memory.c seems to react strangley...


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