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 21:54:30 +0100
From:	Arnd Hannemann <hannemann@...informatik.rwth-aachen.de>
To:	Jordan Crouse <jordan.crouse@....com>
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

Hi,

Jordan Crouse schrieb:
>> 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.

This patch indeed solves the problem. The board boots fine. Great work!

  0:         48    XT-PIC-XT        timer
  2:          0    XT-PIC-XT        cascade
  4:        493    XT-PIC-XT        serial
  7:      25875    XT-PIC-XT        mfgpt-timer
  8:          3    XT-PIC-XT        rtc
 10:      56963    XT-PIC-XT        eth0
 15:          1    XT-PIC-XT        ehci_hcd:usb1, ohci_hcd:usb2
NMI:          0   Non-maskable interrupts
TRM:          0   Thermal event interrupts
SPU:          0   Spurious interrupts
ERR:          0

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

Congratulations for this long but successful remote debugging ;-)

Greetings,
Arnd

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