linux-kernel - Re: 2.6.24-rc8 hangs at mfgpt-timer

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]

Date:	Tue, 22 Jan 2008 12:27:57 -0700
From:	"Jordan Crouse" <jordan.crouse@....com>
To:	"Arnd Hannemann" <hannemann@...informatik.rwth-aachen.de>
cc:	"Lars Heete" <hel@...in.de>,
	"Andres Salomon" <dilinger@...ued.net>,
	"Linux Kernel Mailing List" <linux-kernel@...r.kernel.org>
Subject: Re: 2.6.24-rc8 hangs at mfgpt-timer

> Indeed.
> Strange, it works at least with mfgpt_irq=8 (rtc) and mfgpt_irq=5 (audio):

I have most excellent news.  I was able to get tinyBIOS booting on my
development platform.  I looked at the problem with the debugger and
I think I might have found something.  It looks like the interrupt is
firing immediately before the clock is enabled.  In the handler, we
were returning immediately if the clock wasn't enabled (and not clearing
the event), so we were caught in a classic interrupt storm.

The attached patch rearranges the code so that the handler is installed
before we setup the interrupt (so we have somebody to listen to the
immediate interrupt), and it makes sure that we clear the event in the IRQ
handler regardless of the state of the timer tick.

I'm not 100% sure why this happens on IRQ7 but not on 5 or 8, but it might
have something to do with the interrupts already being enabled on the other
vectors.  Anyway, please try this test patch and let me know what happens.

Jordan

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

View attachment "fix-mfgpt-race.patch" of type "text/plain" (2132 bytes)