linux-kernel - Re: [patch 2.6.26-rc5] make HPET_RTC_IRQ track HPET_EMULATE

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] [day] [month] [year] [list]

Date:	Wed, 11 Jun 2008 19:37:34 +0300
From:	Maxim Levitsky <maximlevitsky@...il.com>
To:	David Brownell <david-b@...bell.net>
CC:	Andrew Morton <akpm@...ux-foundation.org>,
	lkml <linux-kernel@...r.kernel.org>,
	Thomas Gleixner <tglx@...utronix.de>
Subject: Re: [patch 2.6.26-rc5] make HPET_RTC_IRQ track HPET_EMULATE_RTC

David Brownell wrote:
> On Friday 06 June 2008, Maxim Levitsky wrote:
> 
>> Remember long ago I had a discussion with you about HPET that
>> steals RTC irq in 'legacy replacement' mode, and rtc driver thus
>> implements rtc on 'top' of hpet.
>>
>> New rtc-cmos driver doesn't do this emulation, thus it isn't compatible
>> with hpet driver.
> 
> That was fixed in 9d8af78b07976d4d84e0df491abd4e9db848d0ad (February)
> by Bernhard Walle <bwalle@...e.de> ... if you look at the bug report
> associated with this patch, you'll see that rtc-cmos was working OK
> with HPET, it's just the legacy RTC driver which got confused after
> the recent updates to clock handling.
> 
> 
>> But there is a solution,  I didn't agree with firstly, but then I did, and
>> I do agree now, and that to put hpet in normal mode.
>>
>> What happened with patches that put hpet in normal independent mode?
> 
> The story from either Ingo or Thomas (I forget who) was that this is
> another case where we have to cope with BIOS braindamage.  Not enough
> BIOS vendors expose the relevant IRQ routing that Linux could default
> to using HPET in what I'd call "sane" mode.
> 
> Now, that still kind of implies there could be an option to use sane
> HPET IRQ configuration (doesn't hijack RTC and other IRQs, and there
> could be a per-CPU HPET) on at least the systems where that IRQ routing
> is available.  Over time I'd hope that systems like that could become
> the common case.  But ... someone else would have to do that work.  :)
> 
> - Dave

Thanks a lot, next time I compile the kernel, I will enable hpet

Best regards,
	Maxim Levitsky

PS:

This is a question to ubuntu devs, I need to ask them, when
they will switch to new rtc driver....

Old driver has some bugs, including no support for suspend/resume, some
troubles with alarm (it sets the alarm when writing to /proc/acpi/alarm, 
but it can be cleared by even just reading the time. New driver 
correctly sets the alarm at actual suspend time)
Even hpet emulation has some bugs, I even wrote some patches to fix this
and add suspend/resume, but I guess that newer driver is way better, so 
no need to fix old one.



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