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: <47229121.2010806@ct.jp.nec.com>
Date:	Fri, 26 Oct 2007 18:15:13 -0700
From:	Hiroshi Shimamoto <h-shimamoto@...jp.nec.com>
To:	Thomas Gleixner <tglx@...utronix.de>
Cc:	vgoyal@...ibm.com, hbabu@...ibm.com,
	LKML <linux-kernel@...r.kernel.org>, kexec@...ts.infradead.org,
	Venkatesch Pallipadi <venkatesh.pallipadi@...el.com>
Subject: Re: [PATCH 0/3] x86: unify crash_32/64.c

Hiroshi Shimamoto wrote:
> Thomas Gleixner wrote:
>> On Fri, 26 Oct 2007, Hiroshi Shimamoto wrote:
>>
>> Added Venki to CC
>>
>>>> I'm now testing crash on 32bit, but there is an issue before
>>>> applying the patches. My machine stopped at checking 'hlt'
>>>> after kexec, showing below message.
>>>>
>>>> CPU: Intel(R) Xeon(TM) CPU 3.80GHz stepping 0a
>>>> Checking 'hlt' instruction...
>>>>
>>> v2.6.23.1 works fine for 1st kernel.
>>>> I'm investigating it..
>>> I found that the following patch makes my machine stopped.
>>> bfe0c1cc6456bba1f4e3cc1fe29c0ea578ac763a
>>> x86: HPET force enable for ICH5
>>>
>>> It means that after applied this patch, HPET is enabled
>>> automatically on 1st kernel and after crash/kexec the 2nd
>>> kernel stopped at checking 'hlt'.
>>>
>>> I also tested the latest kernel(2.6.24-rc1-gec3b67c1).
>>> Boot parameter "nohpet" resolves this issue and kdump
>>> works well on 32bit.
>>> So I guess HPET affects this.
>>> But I don't know why 64bit kernel with HPET is OK.
>> Hmm. Does the 64 bit code shutdown HPET and restore the IRQ routing to
>> PIT and 32 bit is missing this ?
> 
> Sorry, I'm not sure how I can get these informations.
> Can you please tell me what I should do?
> I'll continue to dig the issue.

I attached the .config files and console logs.
config32/64 are for 1st kernel, and cap32/64 are for 2nd capture kernel.
kdump1.log is boot with nohpet on 32bit.
kdump2.log is boot without nohpet on 32bit and the 2nd kernel hangs.
kdump3.log is on 64bit. And the first kdump is failed because of
without noapic.

Thanks
Hiroshi Shimamoto

Download attachment "configs.tar.bz2" of type "application/octet-stream" (11849 bytes)

Download attachment "consolelog.tar.bz2" of type "application/octet-stream" (13358 bytes)

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ