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: <47965806.6080903@i4.informatik.rwth-aachen.de>
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/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ