My name is Adrian Joian and I'm a fedora ambassador  for the
Romanian community. This is my first time that I'm addressing the devel
list so please be patient with me.
I plan to write an article that will speak about Fedora 9 on laptops
on our local site . My question is why the 184.108.40.206-55.fc9.i686
kernel is not compiled whit the following options, as they have big
impact on laptop "cpu sleep" : CONFIG_HPET_TIMER CONFIG_NO_HZ
Are this values replaced by new ones, if yes what are the new options,
and forgive my lack of knowledge?
Do the above values cause some problems, if yes where can I find the bug
reports, again and forgive my lack of knowledge ?
Thank you very much for your time.
 - https://fedoraproject.org/wiki/AdrianJoian
 - http://www.fedoraproject.ro/ Best regards, Adrian JOIAN
Would be some native German speaker interested in maintaining
man-pages-de? The upstream is dead and they are no open bugs on them,
I've just prefer native speakers for manuals.
BaseOS team Brno
Eric Sandeen wrote:
>It looks like it's already underway, at least as far as the author
>concerned. From http://gaugusch.at/kernel.shtml :
>Update as of 2008-03-15: Several maintainers in the Linux kernel
>started to reconsider their position on the feature. The patch as
>made a brief appearance in some development versions of the kernel
>2.6.25 (it has been reverted because deemed too likely to bring
>but a new approach, patch v0.9, is already available for next
then it is up to whether the patch is "clean" enough to go in the
I think the decision about a custom dsdt table in the kernel has
been taken long time ago. and the answer is the option that enables
the kernel to load a custom table. what the patch does is that it
pospones the loading of the table until the initram is loaded. so
the custom dsdt can be read from it.
If someone thinks the patch isn't good enough, then he should
suggest his own patch. but for now this is the only one available.
Either in the kernel or in the initram, in both cases we can load
our custom dsdt table. the only difference is that the kernel
recompilation takes about 30 mins (compared to the 2mins for the
repacking of the initram). I really don't see any objections to
simplifying this process.
Please, prove me wrong, but I'm just trying to make it easier to
run linux on my machine. And the patch simlifies this process.
PS: There is one more option:
Email the acpi-dev-team my custom dsdt so that they can include it
in the mainline kernel :). Since this is the "missing" code that
breaks my machine, it should be send as a patch for inclussion. And
this is the only way to make my hardware work. So maybe I should
email the kernel-acpi-dev-team :). As you can see, this is a lot
"dirtier" than the above solution. Any other ideas how to make my
hardware work? :)
Shop & save on the supplements you want. Click now!
On Wed, 25 Jun 2008 04:42:24 +0200 Eric Sandeen
>Joshua C. wrote:
>> ok guys,
>> then it is up to whether the patch is "clean" enough to go in
>> mainstream kernel.
>Yes, that is basically it.
>> I think the decision about a custom dsdt table in the kernel has
>> been taken long time ago. and the answer is the option that
>> the kernel to load a custom table. what the patch does is that
>> pospones the loading of the table until the initram is loaded.
>> the custom dsdt can be read from it.
>> If someone thinks the patch isn't good enough, then he should
>> suggest his own patch. but for now this is the only one
>> Either in the kernel or in the initram, in both cases we can
>> our custom dsdt table. the only difference is that the kernel
>> recompilation takes about 30 mins (compared to the 2mins for the
>> repacking of the initram). I really don't see any objections to
>> simplifying this process.
>> Please, prove me wrong, but I'm just trying to make it easier to
>> run linux on my machine. And the patch simlifies this process.
>There's really nothing to prove. Fedora isn't in the business of
>maintaining patches not in upstream for long periods of time; it
>Fedora because of the maintenance load, and it hurts the kernel in
>general because the problem isn't being fixed at the source.
>So if there's something you need, find a way to help it get
>Probably the best thing you could do would be to email the patch
>test the patch he plans to submit next time, and when he does,
>with the fact that it works well for you. If people have concerns
>ways it might break, see if you can break it in those ways, etc.
>I do understand that the functionality provided by the patch makes
>life easier, but these things have to be done in maintainable
>looks like there's a decent chance the patch will be upstream
>we can all be happy. :)
>fedora-devel-list mailing list
I tried it (v.0.9) and it worked for me without any issues.
Smart Girls Secret Weapon
Read Unbiased Beauty Product Reviews, Get Helpful Tips, Tricks and Sam
On Wed, 25 Jun 2008 04:38:03 +0200 Arjan van de Ven
>as someone who works for Intel near the ACPI dev team (yes one
>away)... lets put it this way:
>If Windows works with the BIOS, and Linux does not, that is a bug
>needs fixing in Linux. The ACPI team takes this and other bugs
>seriously; especially if the impact is severe functional
>Windows does work. I would strongly suggest you file a bug in
>bugzilla.kernel.org attaching your dsdt....
Thank you for the advice. I filed a bugreport at
bugzilla.kernel.org and this is how we got the bad dsdt table
(vista and xp never expirienced this problem). the report is here:
As you can see all works well now. But I have to manually insert
the dsdt in the kernel and recompile it for every kernel. :(
I think the acpi-dev-team did a great job finding and repairing
this bug but there is nothing else they could do. Inclusion of my
dsdt in the mainstream kernel is a bad idea because:
1. in the future the table could be repaired but i don't believe
2. en extra code will be needed to chack for the machine version
and the bios and apply the patch only on my machine type. :(
3. the kernel shouldn't be a place to put working dsdt tables
Now I'm waiting for another solution to save the 30 min (+ config
time) for recompilation.
Enter for Your Chance to WIN*
The TotalBeauty.com Summer Spa Sweepstakes!
Dear OLPC & Fedora folk:
In response to conversation at Fudcon, I've thrown up OLPC's packaging
OLPC folks: please check to make sure that your work is listed. Also,
please assist Fedora volunteers in any way you can, for example, by
working with them to provide any missing information that is necessary
Fedora folks: please let us know where you need more information! Also,
don't be shy about joining #olpc-devel on irc.oftc.net and asking if it
looks like we're doing something dumb.
One thing you will soon notice in F10 rawhide is that rhgb is no
longer around. We've blocked it and plan on replacing it for F10.
This is a continuation of our "BetterStartup" feature from a few
Fedoras ago (I would post a link but the wiki seems to be down). The
replacement for rhgb will be a mixture of two things:
1) Starting gdm as early as possible and fitting it to give boot
progress before asking for login. This is somewhat in line with the
early-login prototype feature some of you may remember from several
fedora releases ago.
2) Hiding boot messages before gdm unless escape key is pressed. For
graphics hardware that has drm modesetting, we'll be able to show some
sort of pretty graphics, and for everyone else we'll show a very
simple text mode progress.
Just a heads up,