Last night/this morning, I've rebased FC6 and F7 CVS to 2.6.22 There are a few things worth mentioning.
* I neglected to note that Xen still built from kernel/ in FC-6. kernel-xen was only F-7 aparently. As it would have likely needed decoupling anyway, I'll leave the Xen team to fix this in kernel-xen in whatever manner they see fit.
* nouveau needs rebasing. Ajax? Not sure where to pull that from right now. (add url to scripts/pull-upstreams.sh)
* No idea just how solid the wireless stuff is right now. I picked up whatever we had in rawhide as of yesterday, so it's "shiny and new", but for all I know that could translate to "shiny and broken".
* Some of the experimental bits (like tickless), I've left enabled right now. Depending on how things look from the first round of testing will decide whether we keep it on for release.
* There's a bunch of 'new bits' scheduled for .23 that we had in rawhide at the time of rebase that I feel are "ready", and make for nice bonus goodies. So there's CFS and cpuidle in there too for good measure.
As always, RPMs will appear on http://people.redhat.com/davej/ periodically. (right now just F7/rawhide, but I'll see if I have enough quota to squeeze FC6 there too).
When will they hit updates-testing? I anticipate we'll do a couple of builds before it goes out just to work out the really stupid bugs, but hopefully in the next few days.
Dave
On 7/10/07, Dave Jones davej@redhat.com wrote:
[...]
- nouveau needs rebasing. Ajax? Not sure where to pull that from right now. (add url to scripts/pull-upstreams.sh)
I might be wrong but from xorg git? git://anongit.freedesktop.org/git/nouveau/xf86-video-nouveau
* No idea just how solid the wireless stuff is right now.
I picked up whatever we had in rawhide as of yesterday, so it's "shiny and new", but for all I know that could translate to "shiny and broken".
it seems that it was broken for many people so I doubt that this will cause regressions.
* Some of the experimental bits (like tickless), I've left enabled
right now. Depending on how things look from the first round of testing will decide whether we keep it on for release.
what about the x86_64 hpet issue? (or is x86_64 tickless not included yet?)
* There's a bunch of 'new bits' scheduled for .23 that we had in
rawhide at the time of rebase that I feel are "ready", and make for nice bonus goodies. So there's CFS and cpuidle in there too for good measure.
great :)
On Tue, Jul 10, 2007 at 09:48:57PM +0200, dragoran wrote:
- Some of the experimental bits (like tickless), I've left enabled
right now. Depending on how things look from the first round of testing will decide whether we keep it on for release.
what about the x86_64 hpet issue? (or is x86_64 tickless not included yet?)
You mean the force-enable stuff? it's disabled.
Dave
Hi.
On Wednesday 11 July 2007 07:34:10 Dave Jones wrote:
On Tue, Jul 10, 2007 at 09:48:57PM +0200, dragoran wrote:
- Some of the experimental bits (like tickless), I've left enabled
right now. Depending on how things look from the first round of testing will decide whether we keep it on for release.
what about the x86_64 hpet issue? (or is x86_64 tickless not included
yet?)
No, it's not in vanilla yet, and we don't have the patch in our tree.
FWIW, I'm running x86_64 tickless. I had some initial issues with hibernating and suspending, but worked them through with Thomas. It shouldn't cause any issues on that front if/when it does go in.
Regards,
Nigel
On Wed, Jul 11, 2007 at 10:07:05AM +1000, Nigel Cunningham wrote:
Hi.
On Wednesday 11 July 2007 07:34:10 Dave Jones wrote:
On Tue, Jul 10, 2007 at 09:48:57PM +0200, dragoran wrote:
- Some of the experimental bits (like tickless), I've left enabled
right now. Depending on how things look from the first round of testing will decide whether we keep it on for release.
what about the x86_64 hpet issue? (or is x86_64 tickless not included
yet?)
No, it's not in vanilla yet, and we don't have the patch in our tree.
actually x86-64 tickless has been in rawhide about 2 weeks, and is now in this rebase for FC6/F7. Whether we roll with it for a proper update depends on how it fares during it's trial in updates-testing. So far the forced-hpet part was the only bit that's caused trouble afaics, so with that disabled, it should be (hopefully) boring.
Also, Thomas is usually really on the ball at fixing up silly stuff, so if the initial cut doesn't look so good, it shouldn't be too long before we can get it back into peoples hands.
FWIW, I'm running x86_64 tickless. I had some initial issues with hibernating and suspending, but worked them through with Thomas. It shouldn't cause any issues on that front if/when it does go in.
Once this is out there, and the worse of the fallout has been dealt with we really should try and organise some concerted effort to getting suspend/resume regressions under control, because since FC5, we've more or less just ignored those bugs due to being buried in other stuff.
Dave
Hi.
On Wednesday 11 July 2007 10:53:06 Dave Jones wrote:
On Wed, Jul 11, 2007 at 10:07:05AM +1000, Nigel Cunningham wrote:
Hi.
On Wednesday 11 July 2007 07:34:10 Dave Jones wrote:
On Tue, Jul 10, 2007 at 09:48:57PM +0200, dragoran wrote:
- Some of the experimental bits (like tickless), I've left enabled
right now. Depending on how things look from the first round of testing will decide whether we keep it on for release.
what about the x86_64 hpet issue? (or is x86_64 tickless not
included
yet?)
No, it's not in vanilla yet, and we don't have the patch in our tree.
actually x86-64 tickless has been in rawhide about 2 weeks, and is now in this rebase for FC6/F7. Whether we roll with it for a proper update depends on how it fares during it's trial in updates-testing. So far the forced-hpet part was the only bit that's caused trouble afaics, so with that disabled, it should be (hopefully) boring.
Ah. Now I see it. I was looking for 'hz', not 'hires-timers'. I haven't tried forced hpet support yet. Am I right in thinking that's only for Intels? (Mine's an AMD based Mitac).
Also, Thomas is usually really on the ball at fixing up silly stuff, so if the initial cut doesn't look so good, it shouldn't be too long before we can get it back into peoples hands.
Yeah. He was really good to deal with when I had some interaction with him.
FWIW, I'm running x86_64 tickless. I had some initial issues with
hibernating
and suspending, but worked them through with Thomas. It shouldn't cause
any
issues on that front if/when it does go in.
Once this is out there, and the worse of the fallout has been dealt with we really should try and organise some concerted effort to getting suspend/resume regressions under control, because since FC5, we've more or less just ignored those bugs due to being buried in other stuff.
That would be good. I've been trying to get some of them dealt with, but one day a week makes it slow going. Hughsie has been having a go too, so we're making progress. Nevertheless....
Regards,
Nigel
On Wed, Jul 11, 2007 at 01:50:45PM +1000, Nigel Cunningham wrote:
actually x86-64 tickless has been in rawhide about 2 weeks, and is now in this rebase for FC6/F7. Whether we roll with it for a proper update depends on how it fares during it's trial in updates-testing. So far the forced-hpet part was the only bit that's caused trouble afaics, so with that disabled, it should be (hopefully) boring.
Ah. Now I see it. I was looking for 'hz', not 'hires-timers'. I haven't tried forced hpet support yet. Am I right in thinking that's only for Intels? (Mine's an AMD based Mitac).
So far, yes.
+//DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_ESB2_0, +// ich_force_enable_hpet); +DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_ICH6_1, + ich_force_enable_hpet); +//DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_ICH7_1, +// ich_force_enable_hpet); +//DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_ICH7_31, +// ich_force_enable_hpet); +//DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_ICH8_1, +// ich_force_enable_hpet);
however on some other chipsets, mainline already does force-enabling.. For example on my VIA EPIA ...
[ 28.152336] Force enabled HPET at base address 0xfed00000
Dave
On 11.07.2007 02:53, Dave Jones wrote:
On Wed, Jul 11, 2007 at 10:07:05AM +1000, Nigel Cunningham wrote: [...] actually x86-64 tickless has been in rawhide about 2 weeks, and is now in this rebase for FC6/F7. Whether we roll with it for a proper update depends on how it fares during it's trial in updates-testing. So far the forced-hpet part was the only bit that's caused trouble afaics, so with that disabled, it should be (hopefully) boring.
Well, for me and dragoran it's still causing trouble *afaics*; look closer at
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=247346
Problems start to appear when the hpet stuff for x86_64 went it, and did not vanish when you disabled the forced-hpet for some of the recent ICH's from Intel (which afaics [would need the lspci data to be sure] are in both our machines).
/me will later update the bug with the lspci output when I'm in front of my laptop again.
[...]
CU thl
Thorsten Leemhuis wrote:
On 11.07.2007 02:53, Dave Jones wrote:
On Wed, Jul 11, 2007 at 10:07:05AM +1000, Nigel Cunningham wrote: [...] actually x86-64 tickless has been in rawhide about 2 weeks, and is now in this rebase for FC6/F7. Whether we roll with it for a proper update depends on how it fares during it's trial in updates-testing. So far the forced-hpet part was the only bit that's caused trouble afaics, so with that disabled, it should be (hopefully) boring.
Well, for me and dragoran it's still causing trouble *afaics*; look closer at
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=247346
Problems start to appear when the hpet stuff for x86_64 went it, and did not vanish when you disabled the forced-hpet for some of the recent ICH's from Intel (which afaics [would need the lspci data to be sure] are in both our machines).
/me will later update the bug with the lspci output when I'm in front of my laptop again.
For the record, with 2.6.22-1.fc8 on what appears to be an ICH5 box of mine, nohpet is still required to get the thing booting.
00:00.0 Host bridge: Intel Corporation E7525 Memory Controller Hub (rev 09) 00:00.1 Class ff00: Intel Corporation E7525/E7520 Error Reporting Registers (rev 09) 00:02.0 PCI bridge: Intel Corporation E7525/E7520/E7320 PCI Express Port A (rev 09) 00:03.0 PCI bridge: Intel Corporation E7525/E7520/E7320 PCI Express Port A1 (rev 09) 00:04.0 PCI bridge: Intel Corporation E7525/E7520 PCI Express Port B (rev 09) 00:1d.0 USB Controller: Intel Corporation 82801EB/ER (ICH5/ICH5R) USB UHCI Controller #1 (rev 02) 00:1d.1 USB Controller: Intel Corporation 82801EB/ER (ICH5/ICH5R) USB UHCI Controller #2 (rev 02) 00:1d.2 USB Controller: Intel Corporation 82801EB/ER (ICH5/ICH5R) USB UHCI Controller #3 (rev 02) 00:1d.3 USB Controller: Intel Corporation 82801EB/ER (ICH5/ICH5R) USB UHCI Controller #4 (rev 02) 00:1d.7 USB Controller: Intel Corporation 82801EB/ER (ICH5/ICH5R) USB2 EHCI Controller (rev 02) 00:1e.0 PCI bridge: Intel Corporation 82801 PCI Bridge (rev c2) 00:1f.0 ISA bridge: Intel Corporation 82801EB/ER (ICH5/ICH5R) LPC Interface Bridge (rev 02) 00:1f.1 IDE interface: Intel Corporation 82801EB/ER (ICH5/ICH5R) IDE Controller (rev 02) 00:1f.2 IDE interface: Intel Corporation 82801EB (ICH5) SATA Controller (rev 02) 00:1f.3 SMBus: Intel Corporation 82801EB/ER (ICH5/ICH5R) SMBus Controller (rev 02) 00:1f.5 Multimedia audio controller: Intel Corporation 82801EB/ER (ICH5/ICH5R) AC'97 Audio Controller (rev 02) 01:00.0 PCI bridge: Intel Corporation 6700PXH PCI Express-to-PCI Bridge A 01:00.2 PCI bridge: Intel Corporation 6700PXH PCI Express-to-PCI Bridge B 03:0e.0 Ethernet controller: Intel Corporation 82545GM Gigabit Ethernet Controller (rev 04) 05:00.0 VGA compatible controller: nVidia Corporation NV37GL [Quadro PCI-E Series] (rev a2)
Apologies for the icky line wrapping.
On Wed, Jul 11, 2007 at 06:44:11AM +0200, Thorsten Leemhuis wrote:
On 11.07.2007 02:53, Dave Jones wrote:
On Wed, Jul 11, 2007 at 10:07:05AM +1000, Nigel Cunningham wrote: [...] actually x86-64 tickless has been in rawhide about 2 weeks, and is now in this rebase for FC6/F7. Whether we roll with it for a proper update depends on how it fares during it's trial in updates-testing. So far the forced-hpet part was the only bit that's caused trouble afaics, so with that disabled, it should be (hopefully) boring.
Well, for me and dragoran it's still causing trouble *afaics*; look closer at
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=247346
Problems start to appear when the hpet stuff for x86_64 went it, and did not vanish when you disabled the forced-hpet for some of the recent ICH's from Intel (which afaics [would need the lspci data to be sure] are in both our machines).
/me will later update the bug with the lspci output when I'm in front of my laptop again.
Yeah, I'm picking over that bug now. Will try and find a box I can reproduce this on tomorrow.
Dave
Dave Jones wrote:
On Wed, Jul 11, 2007 at 06:44:11AM +0200, Thorsten Leemhuis wrote:
On 11.07.2007 02:53, Dave Jones wrote:
On Wed, Jul 11, 2007 at 10:07:05AM +1000, Nigel Cunningham wrote: [...] actually x86-64 tickless has been in rawhide about 2 weeks, and is now in this rebase for FC6/F7. Whether we roll with it for a proper update depends on how it fares during it's trial in updates-testing. So far the forced-hpet part was the only bit that's caused trouble afaics, so with that disabled, it should be (hopefully) boring.
Well, for me and dragoran it's still causing trouble *afaics*; look closer at
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=247346
Problems start to appear when the hpet stuff for x86_64 went it, and did not vanish when you disabled the forced-hpet for some of the recent ICH's from Intel (which afaics [would need the lspci data to be sure] are in both our machines).
/me will later update the bug with the lspci output when I'm in front of my laptop again.
Yeah, I'm picking over that bug now. Will try and find a box I can reproduce this on tomorrow.
I've got yer reproducer right here: dhcp83-31.boston.redhat.com, which is a Dell Precision 470 workstation w/an ICH5 chipset.
On 07/11/2007 01:23 AM, Dave Jones wrote:
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=247346
Problems start to appear when the hpet stuff for x86_64 went it, and did not vanish when you disabled the forced-hpet for some of the recent ICH's from Intel (which afaics [would need the lspci data to be sure] are in both our machines).
/me will later update the bug with the lspci output when I'm in front of my laptop again.
Yeah, I'm picking over that bug now. Will try and find a box I can reproduce this on tomorrow.
The Fedora 6 kernel doesn't boot either, at least on a Dell Workstation 490, without "nohpet".
AND it requires a version of mkinitrd (6.something) that's not available for Fedora 6. (I installed with --nodeps and it seems okay but there's no 'symvers' file in /boot/grub for the new kernel.)
On Wed, Jul 11, 2007 at 10:45:13AM -0400, Chuck Ebbert wrote:
On 07/11/2007 01:23 AM, Dave Jones wrote:
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=247346
Problems start to appear when the hpet stuff for x86_64 went it, and did not vanish when you disabled the forced-hpet for some of the recent ICH's from Intel (which afaics [would need the lspci data to be sure] are in both our machines).
/me will later update the bug with the lspci output when I'm in front of my laptop again.
Yeah, I'm picking over that bug now. Will try and find a box I can reproduce this on tomorrow.
The Fedora 6 kernel doesn't boot either, at least on a Dell Workstation 490, without "nohpet".
Lets just drop the 64bit tickless stuff for now, it clearly isn't baked, and isn't going to get much better by the end of the week (which I want to get something into updates-testing by).
AND it requires a version of mkinitrd (6.something) that's not available for Fedora 6. (I installed with --nodeps and it seems okay but there's no 'symvers' file in /boot/grub for the new kernel.)
Oops, that part of the specfile update needs fixing. The require: in F6 went too far forward, and I probably pushed F7 back a rev.
Dave
Hi.
On Thursday 12 July 2007 02:25:45 Dave Jones wrote:
On Wed, Jul 11, 2007 at 10:45:13AM -0400, Chuck Ebbert wrote:
On 07/11/2007 01:23 AM, Dave Jones wrote:
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=247346
Problems start to appear when the hpet stuff for x86_64 went it, and
did
not vanish when you disabled the forced-hpet for some of the recent ICH's from Intel (which afaics [would need the lspci data to be
sure]
are in both our machines).
/me will later update the bug with the lspci output when I'm in
front of
my laptop again.
Yeah, I'm picking over that bug now. Will try and find a box I can reproduce this on tomorrow.
The Fedora 6 kernel doesn't boot either, at least on a Dell Workstation 490, without "nohpet".
Lets just drop the 64bit tickless stuff for now, it clearly isn't baked, and isn't going to get much better by the end of the week (which I want to get something into updates-testing by).
AND it requires a version of mkinitrd (6.something) that's not available for Fedora 6. (I installed with --nodeps and it seems okay but there's no 'symvers' file in /boot/grub for the new kernel.)
Oops, that part of the specfile update needs fixing. The require: in F6 went too far forward, and I probably pushed F7 back a
rev.
Do you (or does anyone else) know if Thomas is aware of these issues? I haven't noticed anything on LKML.
Regards,
Nigel
On Thu, Jul 12, 2007 at 11:56:41AM +1000, Nigel Cunningham wrote:
Hi.
On Thursday 12 July 2007 02:25:45 Dave Jones wrote:
On Wed, Jul 11, 2007 at 10:45:13AM -0400, Chuck Ebbert wrote:
On 07/11/2007 01:23 AM, Dave Jones wrote:
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=247346
Problems start to appear when the hpet stuff for x86_64 went it, and
did
not vanish when you disabled the forced-hpet for some of the recent ICH's from Intel (which afaics [would need the lspci data to be
sure]
are in both our machines).
/me will later update the bug with the lspci output when I'm in
front of
my laptop again.
Yeah, I'm picking over that bug now. Will try and find a box I can reproduce this on tomorrow.
The Fedora 6 kernel doesn't boot either, at least on a Dell Workstation 490, without "nohpet".
Lets just drop the 64bit tickless stuff for now, it clearly isn't baked, and isn't going to get much better by the end of the week (which I want to get something into updates-testing by).
Do you (or does anyone else) know if Thomas is aware of these issues? I haven't noticed anything on LKML.
I've been talking with him. The hpet related stuff is on hold though until Venki gets back from vacation.
Dave
Dave Jones wrote:
On Thu, Jul 12, 2007 at 11:56:41AM +1000, Nigel Cunningham wrote:
Hi.
On Thursday 12 July 2007 02:25:45 Dave Jones wrote:
On Wed, Jul 11, 2007 at 10:45:13AM -0400, Chuck Ebbert wrote:
On 07/11/2007 01:23 AM, Dave Jones wrote:
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=247346
Problems start to appear when the hpet stuff for x86_64 went it, and
did
not vanish when you disabled the forced-hpet for some of the recent ICH's from Intel (which afaics [would need the lspci data to be
sure]
are in both our machines).
/me will later update the bug with the lspci output when I'm in
front of
my laptop again.
Yeah, I'm picking over that bug now. Will try and find a box I can reproduce this on tomorrow.
The Fedora 6 kernel doesn't boot either, at least on a Dell Workstation 490, without "nohpet".
Lets just drop the 64bit tickless stuff for now, it clearly isn't baked, and isn't going to get much better by the end of the week (which I want to get something into updates-testing by).
Do you (or does anyone else) know if Thomas is aware of these issues? I haven't noticed anything on LKML.
I've been talking with him. The hpet related stuff is on hold though until Venki gets back from vacation.
tglx fixed the nohpet bug see https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=247346
So can we merge back hrtimers + this patch and give it another try?
dragoran wrote:
Dave Jones wrote:
On Thu, Jul 12, 2007 at 11:56:41AM +1000, Nigel Cunningham wrote:
Hi.
On Thursday 12 July 2007 02:25:45 Dave Jones wrote: On Wed, Jul 11, 2007 at 10:45:13AM -0400, Chuck Ebbert wrote:
On 07/11/2007 01:23 AM, Dave Jones wrote:
> https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=247346 > > > > > > Problems start to appear when the hpet
stuff for x86_64 went it, and > did
> not vanish when you disabled the forced-hpet for some of
the recent
> ICH's from Intel (which afaics [would need the lspci
data to be > sure]
> are in both our machines). > > > > > > /me will later update the bug with the
lspci output when I'm in > front of
> my laptop again. > > > > Yeah, I'm picking over that bug now. Will try
and find a box I can
reproduce this on tomorrow. > > The Fedora 6 kernel doesn't boot either, at least on
a Dell Workstation
490, without "nohpet".
Lets just drop the 64bit tickless stuff for now, it clearly
isn't baked,
and isn't going to get much better by the end of the week (which
I want
to get something into updates-testing by).
Do you (or does anyone else) know if Thomas is aware of
these issues? I > haven't noticed anything on LKML.
I've been talking with him. The hpet related stuff is on hold though until Venki gets back from vacation.
tglx fixed the nohpet bug see https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=247346
So can we merge back hrtimers + this patch and give it another try?
and also one more idea: we could also merge back the force hpet patches. maybe there where just affected by this bug (hpet hang).
On Thu, Jul 12, 2007 at 09:49:30AM +0200, dragoran wrote:
I've been talking with him. The hpet related stuff is on hold though until Venki gets back from vacation.
tglx fixed the nohpet bug see https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=247346
So can we merge back hrtimers + this patch and give it another try?
and also one more idea: we could also merge back the force hpet patches. maybe there where just affected by this bug (hpet hang).
At this point, I'm going to skip that feature for F6/F7, or we'll never get this update out. Hopefully it'll be in good enough shape to get at least something that'll work for most people into updates-testing by the weekend. I'll add Thomas' stuff back to rawhide once he has patches against latest -git.
Dave
On 10.07.2007 18:47, Dave Jones wrote:
Last night/this morning, I've rebased FC6 and F7 CVS to 2.6.22 There are a few things worth mentioning. [...]
- There's a bunch of 'new bits' scheduled for .23 that we had in rawhide at the time of rebase that I feel are "ready", and make for nice bonus goodies. So there's CFS and cpuidle in there too for good measure.
Cpuspeed afaics needs an adjustment if cpuidle stays:
$ LC_ALL=C sudo /etc/init.d/cpuspeed restart Disabling ondemand cpu frequency scaling: /etc/init.d/cpuspeed: line 212: /sys/devices/system/cpu/cpuidle/cpufreq/scaling_governor: No such file or directory /etc/init.d/cpuspeed: line 213: /sys/devices/system/cpu/cpuidle/cpufreq/scaling_setspeed: No such file or directory [ OK ] /etc/init.d/cpuspeed: line 62: /sys/devices/system/cpu/cpuidle/cpufreq/scaling_governor: No such file or directory Enabling ondemand cpu frequency scaling: [ OK ] $ uname -r 2.6.22-2.fc7 $ rpm -q fedora-release fedora-release-7-3 $
Cu knurd
On Wed, Jul 11, 2007 at 06:26:26PM +0200, Thorsten Leemhuis wrote:
On 10.07.2007 18:47, Dave Jones wrote:
Last night/this morning, I've rebased FC6 and F7 CVS to 2.6.22 There are a few things worth mentioning. [...]
- There's a bunch of 'new bits' scheduled for .23 that we had in rawhide at the time of rebase that I feel are "ready", and make for nice bonus goodies. So there's CFS and cpuidle in there too for good measure.
Cpuspeed afaics needs an adjustment if cpuidle stays:
$ LC_ALL=C sudo /etc/init.d/cpuspeed restart Disabling ondemand cpu frequency scaling: /etc/init.d/cpuspeed: line 212: /sys/devices/system/cpu/cpuidle/cpufreq/scaling_governor: No such file or directory /etc/init.d/cpuspeed: line 213: /sys/devices/system/cpu/cpuidle/cpufreq/scaling_setspeed: No such file or directory [ OK ] /etc/init.d/cpuspeed: line 62: /sys/devices/system/cpu/cpuidle/cpufreq/scaling_governor: No such file or directory Enabling ondemand cpu frequency scaling: [ OK ]
Jarod checked a fix in a day or so ago, might be working its way through koji somewhere.
Dave
Dave Jones wrote:
On Wed, Jul 11, 2007 at 06:26:26PM +0200, Thorsten Leemhuis wrote:
On 10.07.2007 18:47, Dave Jones wrote:
Last night/this morning, I've rebased FC6 and F7 CVS to 2.6.22 There are a few things worth mentioning. [...]
- There's a bunch of 'new bits' scheduled for .23 that we had in rawhide at the time of rebase that I feel are "ready", and make for nice bonus goodies. So there's CFS and cpuidle in there too for good measure.
Cpuspeed afaics needs an adjustment if cpuidle stays:
$ LC_ALL=C sudo /etc/init.d/cpuspeed restart Disabling ondemand cpu frequency scaling: /etc/init.d/cpuspeed: line 212: /sys/devices/system/cpu/cpuidle/cpufreq/scaling_governor: No such file or directory /etc/init.d/cpuspeed: line 213: /sys/devices/system/cpu/cpuidle/cpufreq/scaling_setspeed: No such file or directory [ OK ] /etc/init.d/cpuspeed: line 62: /sys/devices/system/cpu/cpuidle/cpufreq/scaling_governor: No such file or directory Enabling ondemand cpu frequency scaling: [ OK ]
Jarod checked a fix in a day or so ago, might be working its way through koji somewhere.
Yep, it was sitting for a day or two waiting for someone to notice my bodhi push request. It just got pushed over to stable updates a few hours ago.
On 07/11/2007 12:35 PM, Jarod Wilson wrote:
Cpuspeed afaics needs an adjustment if cpuidle stays:
$ LC_ALL=C sudo /etc/init.d/cpuspeed restart Disabling ondemand cpu frequency scaling: /etc/init.d/cpuspeed: line 212: /sys/devices/system/cpu/cpuidle/cpufreq/scaling_governor: No such file or directory /etc/init.d/cpuspeed: line 213: /sys/devices/system/cpu/cpuidle/cpufreq/scaling_setspeed: No such file or directory [ OK ] /etc/init.d/cpuspeed: line 62: /sys/devices/system/cpu/cpuidle/cpufreq/scaling_governor: No such file or directory Enabling ondemand cpu frequency scaling: [ OK ]
Jarod checked a fix in a day or so ago, might be working its way through koji somewhere.
Yep, it was sitting for a day or two waiting for someone to notice my bodhi push request. It just got pushed over to stable updates a few hours ago.
Fedora 6 too?
Chuck Ebbert wrote:
On 07/11/2007 12:35 PM, Jarod Wilson wrote:
Cpuspeed afaics needs an adjustment if cpuidle stays:
$ LC_ALL=C sudo /etc/init.d/cpuspeed restart Disabling ondemand cpu frequency scaling: /etc/init.d/cpuspeed: line 212: /sys/devices/system/cpu/cpuidle/cpufreq/scaling_governor: No such file or directory /etc/init.d/cpuspeed: line 213: /sys/devices/system/cpu/cpuidle/cpufreq/scaling_setspeed: No such file or directory [ OK ] /etc/init.d/cpuspeed: line 62: /sys/devices/system/cpu/cpuidle/cpufreq/scaling_governor: No such file or directory Enabling ondemand cpu frequency scaling: [ OK ]
Jarod checked a fix in a day or so ago, might be working its way through koji somewhere.
Yep, it was sitting for a day or two waiting for someone to notice my bodhi push request. It just got pushed over to stable updates a few hours ago.
Fedora 6 too?
I submitted a push request for the FC6 update I did w/the other pre-F7 update system, but haven't got any notice about it being pushed just yet. I'll ping someone in rel-eng.
Can't wait for FC-6 to die now, so we don't have two different ways of doing things (er, make that three w/the RHEL stuff I do too)...
On 07/11/2007 12:48 PM, Jarod Wilson wrote:
I submitted a push request for the FC6 update I did w/the other pre-F7 update system, but haven't got any notice about it being pushed just yet. I'll ping someone in rel-eng.
Can't wait for FC-6 to die now, so we don't have two different ways of doing things (er, make that three w/the RHEL stuff I do too)...
Not until December...
I wonder if we shouldn't just be very conservative with FC6 and drop the cpuidle there patch as well. Then that update wouldn't be needed. Otherwise we've got to add another 'requires' to the kernel package.
(And I assume the cpuspeed update still works with old 2.6.18 kernels in case someone updates cpuspeed but not the kernel?)
Chuck Ebbert wrote:
On 07/11/2007 12:48 PM, Jarod Wilson wrote:
I submitted a push request for the FC6 update I did w/the other pre-F7 update system, but haven't got any notice about it being pushed just yet. I'll ping someone in rel-eng.
Can't wait for FC-6 to die now, so we don't have two different ways of doing things (er, make that three w/the RHEL stuff I do too)...
Not until December...
Yeah, I know. Damned users wanting us to support stuff for more than 6mo... ;)
I wonder if we shouldn't just be very conservative with FC6 and drop the cpuidle there patch as well. Then that update wouldn't be needed. Otherwise we've got to add another 'requires' to the kernel package.
worksforme, but I don't really run fc6 anywhere anymore either.
(And I assume the cpuspeed update still works with old 2.6.18 kernels in case someone updates cpuspeed but not the kernel?)
Yep, the change is really minor (just a slightly stricter pattern match when looking for per-cpu cpufreq bits in /sys -- match cpu[0-9]* instead of cpu*), works just fine with older kernels.
On Wed, Jul 11, 2007 at 12:55:49PM -0400, Chuck Ebbert wrote:
On 07/11/2007 12:48 PM, Jarod Wilson wrote:
I submitted a push request for the FC6 update I did w/the other pre-F7 update system, but haven't got any notice about it being pushed just yet. I'll ping someone in rel-eng.
Can't wait for FC-6 to die now, so we don't have two different ways of doing things (er, make that three w/the RHEL stuff I do too)...
Not until December...
I wonder if we shouldn't just be very conservative with FC6 and drop the cpuidle there patch as well. Then that update wouldn't be needed. Otherwise we've got to add another 'requires' to the kernel package.
Oh good point, cpuidle is part of that massive -hrt update, so when we drop 64bit tickless it goes away anyway..
(And I assume the cpuspeed update still works with old 2.6.18 kernels in case someone updates cpuspeed but not the kernel?)
it would, it's just tightening a check for files in sysfs to not pick up the new cpuidle dir, just the cpuN dirs.
Dave
On 11.07.2007 18:35, Jarod Wilson wrote:
Dave Jones wrote:
On Wed, Jul 11, 2007 at 06:26:26PM +0200, Thorsten Leemhuis wrote:
On 10.07.2007 18:47, Dave Jones wrote:
Last night/this morning, I've rebased FC6 and F7 CVS to 2.6.22 There are a few things worth mentioning. [...]
- There's a bunch of 'new bits' scheduled for .23 that we had in rawhide at the time of rebase that I feel are "ready", and make for nice bonus goodies. So there's CFS and cpuidle in there too for good measure.
Cpuspeed afaics needs an adjustment if cpuidle stays:
$ LC_ALL=C sudo /etc/init.d/cpuspeed restart Disabling ondemand cpu frequency scaling: /etc/init.d/cpuspeed: line 212: /sys/devices/system/cpu/cpuidle/cpufreq/scaling_governor: No such file or directory /etc/init.d/cpuspeed: line 213: /sys/devices/system/cpu/cpuidle/cpufreq/scaling_setspeed: No such file or directory [ OK ] /etc/init.d/cpuspeed: line 62: /sys/devices/system/cpu/cpuidle/cpufreq/scaling_governor: No such file or directory Enabling ondemand cpu frequency scaling: [ OK ]
Jarod checked a fix in a day or so ago, might be working its way through koji somewhere.
Yep, it was sitting for a day or two waiting for someone to notice my bodhi push request. It just got pushed over to stable updates a few hours ago.
Sorry for the noise and thx for your work.
/me will look at cvs/koji first next time and not only at the repos
Cu thl
kernel@lists.fedoraproject.org
-
Chuck Ebbert -
Dave Jones -
drago01 -
Jarod Wilson -
Nigel Cunningham -
Thorsten Leemhuis