Messages in this thread | | | Date | Fri, 25 Jul 2008 11:04:38 +0200 | From | Bernhard Walle <> | Subject | Re: Solid freezes with 2.6.25 |
| |
* Gabor Gombas [2008-07-25 10:52]: > > On Sun, Jun 15, 2008 at 07:11:41PM +0200, Gabor Gombas wrote: > > On Tue, May 13, 2008 at 04:39:29PM +0200, Gabor Gombas wrote: > > > On Mon, May 12, 2008 at 02:21:46PM +0200, Bernhard Walle wrote: > > > > > > > Well, can you try if that really not happens without > > > > CONFIG_HPET_EMULATE_RTC? The question is if that 64 interrupts per second really > > > > cause a machine hang ... > > > > > > I'll try when I have a little time... > > > > Ok, it took much more time than I'd have liked, but now I'm having: > > > > $ uname -a > > Linux boogie 2.6.25 #3 SMP Thu Jun 12 13:32:35 CEST 2008 x86_64 GNU/Linux > > $ grep EMULATE_RTC /boot/config-2.6.25 > > # CONFIG_HPET_EMULATE_RTC is not set > > $ uptime > > 19:07:17 up 3 days, 4:07, 12 users, load average: 0.14, 0.31, 0.20 > > > > So I'd say it works. > > FYI, the bug is still present in 2.6.26. I also got the same hang on a > Dell PowerEdge 850 using a Debian-provided kernel (based on 2.6.25.6); > that is the 3rd distinct HW configuration that hangs.
Did you try that patch?
-------------- 8< --------------------------------------------------- From: David Brownell <dbrownell@users.sourceforge.net>
Resolve http://bugzilla.kernel.org/show_bug.cgi?id=11051 and other bugs related to the way the HPET glue code in rtc-cmos was incomplete and inconsistent:
* Switch the approach so that the basic driver code flow isn't changed by having HPET ... instead, just have HPET shadow the RTC_CONTROL irq enables and RTC_FREQ_SELECT data. It's only coping with IRQ thievery, after all.
* Do that consistently (!!) to avoid problems when the HPET code is out of sync with the real RTC intent. Examples include:
- cmos_procfs(), which now reports correct data
- cmos_irq_set_state() ... also removing the previous PIE_{ON,OFF} ioctl support so only one code path manages "periodic" IRQs
- cmos_do_shutdown() ... currently a "just in case" change.
- cmos_suspend() and cmos_resume() ... also handling a bug that was specific to HPET's IRQ thievery, where the alarm wasn't disabled after waking the system
* Always call that HPET code under the RTC spinlock (it doesn't do its own locking) -------------- >8 ---------------------------------------------------
Bernhard -- Bernhard Walle, SUSE LINUX Products GmbH, Architecture Development
| |