I've just pushed a f15-2.6.39 branch which contains a work in progress rebase. The only thing that I'm really concerned about in this right now is X regressions. We had a drm-next backport to .38 and moving that to .39 turned up a ton of rejects. I fixed up a few by hand, but the resulting compile failures made my head hurt, so I've mostly left them disabled. If the nouveau/intel drm dudes could look over that branch and fix up whatever is necessary, we can look at getting this out to people soon.
(looking ahead, after its release pushing 3.0.x as 2.6.40 is probably going to happen, in a shorter timeframe than what took us to get .39 ready)
Dave
Hi,
2011/6/30 Dave Jones davej@redhat.com:
I've just pushed a f15-2.6.39 branch which contains a work in progress rebase. The only thing that I'm really concerned about in this right now is X regressions. We had a drm-next backport to .38 and moving that to .39 turned up a ton of rejects. I fixed up a few by hand, but the resulting compile failures made my head hurt, so I've mostly left them disabled. If the nouveau/intel drm dudes could look over that branch and fix up whatever is necessary, we can look at getting this out to people soon.
(looking ahead, after its release pushing 3.0.x as 2.6.40 is probably going to happen,
I ask out of curiosity - why 2.6.40? Is it a big problem to run 3.0 on F15?
in a shorter timeframe than what took us to get .39 ready)
Dave
kernel mailing list kernel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/kernel
On Thu, Jun 30, 2011 at 08:50:17PM +0200, Michał Piotrowski wrote:
Hi,
2011/6/30 Dave Jones davej@redhat.com:
I've just pushed a f15-2.6.39 branch which contains a work in progress rebase. The only thing that I'm really concerned about in this right now is X regressions. We had a drm-next backport to .38 and moving that to .39 turned up a ton of rejects. I fixed up a few by hand, but the resulting compile failures made my head hurt, so I've mostly left them disabled. If the nouveau/intel drm dudes could look over that branch and fix up whatever is necessary, we can look at getting this out to people soon.
(looking ahead, after its release pushing 3.0.x as 2.6.40 is probably going to happen,
I ask out of curiosity - why 2.6.40? Is it a big problem to run 3.0 on F15?
A lot of broken software is assuming version numbers are 2.6.x. We could push a load of userspace packages to fix it, but that's just the stuff we control. 3rd party add-ons would break for no good reason.
This deviates from what upstream calls it, but it's just a number, and not breaking existing code in an update is more important here. For f16 of course, we'll make the 3.0 transition, because moving to a new release has differing expectations, and by the time it ships, hopefully everything that cares will be fixed.
Dave
W dniu 30 czerwca 2011 20:58 użytkownik Dave Jones davej@redhat.com napisał:
On Thu, Jun 30, 2011 at 08:50:17PM +0200, Michał Piotrowski wrote: > Hi, > > 2011/6/30 Dave Jones davej@redhat.com: > > I've just pushed a f15-2.6.39 branch which contains a work in progress rebase. > > The only thing that I'm really concerned about in this right now is X regressions. > > We had a drm-next backport to .38 and moving that to .39 turned up a ton of rejects. > > I fixed up a few by hand, but the resulting compile failures made my head hurt, so > > I've mostly left them disabled. If the nouveau/intel drm dudes could look over > > that branch and fix up whatever is necessary, we can look at getting this out > > to people soon. > > > > (looking ahead, after its release pushing 3.0.x as 2.6.40 is probably going to > > happen, > > I ask out of curiosity - why 2.6.40? Is it a big problem to run 3.0 on F15?
A lot of broken software is assuming version numbers are 2.6.x. We could push a load of userspace packages to fix it, but that's just the stuff we control. 3rd party add-ons would break for no good reason.
This deviates from what upstream calls it, but it's just a number, and not breaking existing code in an update is more important here.
Of course you are absolutely right at this point :)
Thanks for your answer.
For f16 of course, we'll make the 3.0 transition, because moving to a new release has differing expectations, and by the time it ships, hopefully everything that cares will be fixed.
Dave
On 06/30/2011 03:04 PM, Michał Piotrowski wrote:
W dniu 30 czerwca 2011 20:58 użytkownik Dave Jones davej@redhat.com napisał:
A lot of broken software is assuming version numbers are 2.6.x. We could push a load of userspace packages to fix it, but that's just the stuff we control. 3rd party add-ons would break for no good reason.
This deviates from what upstream calls it, but it's just a number, and not breaking existing code in an update is more important here.
Of course you are absolutely right at this point :)
Thanks for your answer.
For f16 of course, we'll make the 3.0 transition, because moving to a new release has differing expectations, and by the time it ships, hopefully everything that cares will be fixed.
Dave
For what its worth - so far - running 3.0 on F15 I did need procps & mdadm updated - otherwise I've not seen too many issues that I know about.
What else do you think might be breaking / broken / grumpy ?
W dniu 30 czerwca 2011 21:49 użytkownik Genes MailLists lists@sapience.com napisał:
On 06/30/2011 03:04 PM, Michał Piotrowski wrote:
W dniu 30 czerwca 2011 20:58 użytkownik Dave Jones davej@redhat.com napisał:
A lot of broken software is assuming version numbers are 2.6.x. We could push a load of userspace packages to fix it, but that's just the stuff we control. 3rd party add-ons would break for no good reason.
This deviates from what upstream calls it, but it's just a number, and not breaking existing code in an update is more important here.
Of course you are absolutely right at this point :)
Thanks for your answer.
For f16 of course, we'll make the 3.0 transition, because moving to a new release has differing expectations, and by the time it ships, hopefully everything that cares will be fixed.
Dave
For what its worth - so far - running 3.0 on F15 I did need procps & mdadm updated - otherwise I've not seen too many issues that I know about.
What else do you think might be breaking / broken / grumpy ?
It seems to me that the answer should be - check the package requirements - but in this case probably is not so.
Requires /bin/sh /bin/sh /bin/sh /sbin/new-kernel-pkg /sbin/new-kernel-pkg dracut >= 001-7 fileutils grubby >= 7.0.10-1 initscripts >= 8.11.1-1 linux-firmware >= 20100806-2 module-init-tools rpmlib(CompressedFileNames) <= 3.0.4-1 rpmlib(FileDigests) <= 4.6.0-1 rpmlib(PayloadFilesHavePrefix) <= 4.0-1 rpmlib(PayloadIsXz) <= 5.2-1 Obsoletes No Obsoletes
Conflicts device-mapper-libs < 1.02.63-2 e2fsprogs < 1.37-4 initscripts < 7.23 iptables < 1.3.2-1 ipw2200-firmware < 2.4 isdn4k-utils < 3.2-32 iwl4965-firmware < 228.57.2 jfsutils < 1.1.7-2 mdadm < 3.2.1-5 module-init-tools < 3.13-1 nfs-utils < 1.0.7-12 oprofile < 0.9.1-2 ppp < 2.4.3-3 procps < 3.2.5-6.3 reiserfs-utils < 3.6.19-2 selinux-policy-targeted < 1.25.3-14 squashfs-tools < 4.0 udev < 063-6 util-linux < 2.12 wireless-tools < 29-3 xfsprogs < 2.6.13-4
On 06/30/2011 04:10 PM, Michał Piotrowski wrote:
What else do you think might be breaking / broken / grumpy ?
It seems to me that the answer should be - check the package requirements - but in this case probably is not so.
Requires /bin/sh /bin/sh /bin/sh /sbin/new-kernel-pkg /sbin/new-kernel-pkg dracut >= 001-7 fileutils grubby >= 7.0.10-1 initscripts >= 8.11.1-1 linux-firmware >= 20100806-2 module-init-tools rpmlib(CompressedFileNames) <= 3.0.4-1 rpmlib(FileDigests) <= 4.6.0-1 rpmlib(PayloadFilesHavePrefix) <= 4.0-1 rpmlib(PayloadIsXz) <= 5.2-1 Obsoletes No Obsoletes
These seem to be all satisfied by current F15 are they not - unless I don't understand .. which is more than likely.
On Thu, Jun 30, 2011 at 15:49:49 -0400, Genes MailLists lists@sapience.com wrote:
For what its worth - so far - running 3.0 on F15 I did need procps & mdadm updated - otherwise I've not seen too many issues that I know about.
What else do you think might be breaking / broken / grumpy ?
I have 2 different i686 (one athlon based, the other xeon based) that lock up during boots with 3.0 kernels. 2.6.39 works fine.
On 07/01/2011 10:56 AM, Bruno Wolff III wrote:
On Thu, Jun 30, 2011 at 15:49:49 -0400, Genes MailLists lists@sapience.com wrote:
For what its worth - so far - running 3.0 on F15 I did need procps & mdadm updated - otherwise I've not seen too many issues that I know about.
What else do you think might be breaking / broken / grumpy ?
I have 2 different i686 (one athlon based, the other xeon based) that lock up during boots with 3.0 kernels. 2.6.39 works fine.
could it be graphics driver related? My sandy bridge i915 works better and better with each new 3.0 kernel ... plymouth is broken for me under stock F15 ... which 2.6.39 are you using anyway?
I was really asking Dave what other user space packages may get grumpy with the new naming convention for 3.0 and may need updating from rawhide other than mdadm and procps.
On Fri, Jul 01, 2011 at 14:10:07 -0400, Genes MailLists lists@sapience.com wrote:
could it be graphics driver related? My sandy bridge i915 works better and better with each new 3.0 kernel ... plymouth is broken for me under stock F15 ... which 2.6.39 are you using anyway?
Probably not. One machine has an rv280, the other and nv28.
I was really asking Dave what other user space packages may get grumpy with the new naming convention for 3.0 and may need updating from rawhide other than mdadm and procps.
Unfortunately I can't really test that any further. At first a few things caused problems earlier in the boot than the current problem. But those got fixed and now I can't go any further on that hardware.
I did report a traceback in both the fedora and kernel.org bug trackers, but so far not much has happened.
On (Thu) 30 Jun 2011 [14:42:56], Dave Jones wrote:
I've just pushed a f15-2.6.39 branch which contains a work in progress rebase. The only thing that I'm really concerned about in this right now is X regressions.
FWIW I've been running 2.6.39-1.fc16.x86_64 on F15 for quite a while now on a ThinkPad X200, which has intel graphics. This is mainly to escape bug 684097.
Amit
On Sat, Jul 2, 2011 at 5:33 PM, Frank Ch. Eigler fche@redhat.com wrote:
davej wrote:
I've just pushed a f15-2.6.39 branch which contains a work in progress rebase. [...]
Does the "f15" part of the name reflect an intent to rebase the kernel during a stable fedora release?
That's whats the whole thread is about ...
Hi -
On Sat, Jul 02, 2011 at 07:08:03PM +0200, drago01 wrote:
I've just pushed a f15-2.6.39 branch which contains a work in progress rebase. [...]
Does the "f15" part of the name reflect an intent to rebase the kernel during a stable fedora release?
That's whats the whole thread is about ...
OK, I was asking, because I was recently reminded of the current fedora update policy's discouragement of such rebases, in connection with another package. What kind of rationale was necessary to justify a kernel rebase?
- FChE
On Sat, Jul 02, 2011 at 20:29:16 -0400, "Frank Ch. Eigler" fche@redhat.com wrote:
Hi -
On Sat, Jul 02, 2011 at 07:08:03PM +0200, drago01 wrote:
I've just pushed a f15-2.6.39 branch which contains a work in progress rebase. [...]
Does the "f15" part of the name reflect an intent to rebase the kernel during a stable fedora release?
That's whats the whole thread is about ...
OK, I was asking, because I was recently reminded of the current fedora update policy's discouragement of such rebases, in connection with another package. What kind of rationale was necessary to justify a kernel rebase?
Probably dropping of support for 2.6.38 upstream. I am not sure when that is going to happen, but most kernels stop being supported not too long after the next kernel is released, unless they are selected for long term support.
On 06/30/2011 02:42 PM, Dave Jones wrote:
I've just pushed a f15-2.6.39 branch which contains a work in progress rebase. The only thing that I'm really concerned about in this right now is X regressions. We had a drm-next backport to .38 and moving that to .39 turned up a ton of rejects. I fixed up a few by hand, but the resulting compile failures made my head hurt, so I've mostly left them disabled. If the nouveau/intel drm dudes could look over that branch and fix up whatever is necessary, we can look at getting this out to people soon.
(looking ahead, after its release pushing 3.0.x as 2.6.40 is probably going to happen, in a shorter timeframe than what took us to get .39 ready)
Dave
looking forward to 3.0 .. 2.6.40.0 .. thanks dave (and kyle et al) ... :-)
gene/
On Thu, Jun 30, 2011 at 02:42:56PM -0400, Dave Jones wrote:
I've just pushed a f15-2.6.39 branch which contains a work in progress rebase.
I did another rebase (to .3) last night, and did a scratch build. RPMs are here http://koji.fedoraproject.org/koji/taskinfo?taskID=3195520
My previous concern about X/DRM seems to have been unfounded based on my testing so far. The only thing I'm concerned about now is the block/scsi changes that are still being shaken out in 3.0. I suspect another -stable or two before that gets sorted. (The .38 update Chuck recently pushed out reverts a bunch of changes that were exposing these problems. I think it's a little more involved for .39)
Dave
2011/7/13 Dave Jones davej@redhat.com:
On Thu, Jun 30, 2011 at 02:42:56PM -0400, Dave Jones wrote: > I've just pushed a f15-2.6.39 branch which contains a work in progress rebase.
I did another rebase (to .3) last night, and did a scratch build. RPMs are here http://koji.fedoraproject.org/koji/taskinfo?taskID=3195520
My previous concern about X/DRM seems to have been unfounded based on my testing so far. The only thing I'm concerned about now is the block/scsi changes that are still being shaken out in 3.0. I suspect another -stable or two before that gets sorted. (The .38 update Chuck recently pushed out reverts a bunch of changes that were exposing these problems. I think it's a little more involved for .39)
Dave
kernel mailing list kernel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/kernel
Any chance to get to the public any time soon? The git hasn't been updated for weeks.
On 07/26/2011 06:43 AM, Joshua C. wrote:
2011/7/13 Dave Jones davej@redhat.com:
On Thu, Jun 30, 2011 at 02:42:56PM -0400, Dave Jones wrote:
I've just pushed a f15-2.6.39 branch which contains a work in progress rebase.
At this point - is there any reason not to move to 3.0 ? The F16 version seems to run better than 2.6.38.x ... and other than updating procps and mdadm is anything else needed ?
gene
On 07/26/2011 08:57 AM, Genes MailLists wrote:
On 07/26/2011 06:43 AM, Joshua C. wrote:
2011/7/13 Dave Jones davej@redhat.com:
On Thu, Jun 30, 2011 at 02:42:56PM -0400, Dave Jones wrote:
I've just pushed a f15-2.6.39 branch which contains a work in progress rebase.
At this point - is there any reason not to move to 3.0 ? The F16 version seems to run better than 2.6.38.x ... and other than updating procps and mdadm is anything else needed ?
gene
Perhaps get the rcu fixes and the usb hotplug issue patches as well but other than that :-)
On Tue, Jul 26, 2011 at 09:04:11 -0400, Genes MailLists lists@sapience.com wrote:
Perhaps get the rcu fixes and the usb hotplug issue patches as well but other than that :-)
The 3.0 kernel is crashing on reboot for me.
On one machine, 3.0.0-1 doesn't boot because raid devices aren't started and it can't find /root. This doesn't happen on another machine with root on encrypted raid devices and 3.0.0-rc7.git10 works. So I am not sure if this was the kernel or if there is a problem building the initramfs image.
I would prefer not to rush 3.0 kernels into F15 updates, but I'd certainly be willing to start testing them on my machines.
On Tue, Jul 26, 2011 at 08:32:44AM -0500, Bruno Wolff III wrote:
On Tue, Jul 26, 2011 at 09:04:11 -0400, Genes MailLists lists@sapience.com wrote:
Perhaps get the rcu fixes and the usb hotplug issue patches as well but other than that :-)
The 3.0 kernel is crashing on reboot for me.
On one machine, 3.0.0-1 doesn't boot because raid devices aren't started and it can't find /root. This doesn't happen on another machine with root on encrypted raid devices and 3.0.0-rc7.git10 works. So I am not sure if this was the kernel or if there is a problem building the initramfs image.
I would prefer not to rush 3.0 kernels into F15 updates, but I'd certainly be willing to start testing them on my machines.
3.x needs a bunch of userspace updated, which could explain things like the raid failure you're seeing. That's why we're doing a 2.6.40 for updates. It's 3.0 in all but name.
Dave
"DJ" == Dave Jones davej@redhat.com writes:
DJ> 3.x needs a bunch of userspace updated, which could explain things DJ> like the raid failure you're seeing. That's why we're doing a 2.6.40 DJ> for updates. It's 3.0 in all but name.
That work is in the f15-30-going-on-40 branch, by the say. I've been running them as they're built and they seem OK.
- J<
On Tue, Jul 26, 2011 at 02:21:52PM -0400, Dave Jones wrote:
3.x needs a bunch of userspace updated, which could explain things like the raid failure you're seeing. That's why we're doing a 2.6.40 for updates. It's 3.0 in all but name.
Very little should be broken by the x.y.z/3.0.0, most of the broken userspace was due to x.y version numbers, and strict test on the result of scanf.
--Kyle
On Jul 26, 2011, at 3:11 PM, Kyle McMartin wrote:
On Tue, Jul 26, 2011 at 02:21:52PM -0400, Dave Jones wrote:
3.x needs a bunch of userspace updated, which could explain things like the raid failure you're seeing. That's why we're doing a 2.6.40 for updates. It's 3.0 in all but name.
Very little should be broken by the x.y.z/3.0.0, most of the broken userspace was due to x.y version numbers, and strict test on the result of scanf.
Been running 3.0 rc kernels for some time on an f15 box without any problems, though its mainly for testing local kernel changes, so I wouldn't have seen much in the way of userspace breakage. But the box does have software (md) raid, and it comes up fine. I just assume push 3.0 as 3.0, starting with testing. The userspace all has to work eventually anyway, so why not fix it in f15.
On Tue, Jul 26, 2011 at 08:57:17AM -0400, Genes MailLists wrote:
On 07/26/2011 06:43 AM, Joshua C. wrote:
2011/7/13 Dave Jones davej@redhat.com:
On Thu, Jun 30, 2011 at 02:42:56PM -0400, Dave Jones wrote:
I've just pushed a f15-2.6.39 branch which contains a work in progress rebase.
At this point - is there any reason not to move to 3.0 ? The F16 version seems to run better than 2.6.38.x ... and other than updating procps and mdadm is anything else needed ?
http://koji.fedoraproject.org/koji/taskinfo?taskID=3231898
Will need some more patching before it's ready for an update, but it'll go out soon.
Dave
On 07/26/2011 02:20 PM, Dave Jones wrote:
http://koji.fedoraproject.org/koji/taskinfo?taskID=3231898
Will need some more patching before it's ready for an update, but it'll go out soon.
Dave
Ah ok that sounds good - thanks! Aside from a few bugs/patches to come still,
... curious which userspace pieces need updating .. (mdadm, procps ?)
gene/
On Tue, Jul 26, 2011 at 02:41:22PM -0400, Genes MailLists wrote:
On 07/26/2011 02:20 PM, Dave Jones wrote:
http://koji.fedoraproject.org/koji/taskinfo?taskID=3231898
Will need some more patching before it's ready for an update, but it'll go out soon.
Dave
Ah ok that sounds good - thanks! Aside from a few bugs/patches to come still,
... curious which userspace pieces need updating .. (mdadm, procps ?)
with 2.6.40, hopefully nothing.
Dave
On 07/26/2011 02:54 PM, Dave Jones wrote: t sounds good - thanks! Aside from a few bugs/patches to come
still,
... curious which userspace pieces need updating .. (mdadm, procps ?)
with 2.6.40, hopefully nothing.
And with the 3.0.0 kernels - hopefully nothing as well .. so why go back to 2.6.40 ?
3.0.0 seems to be largely ok on F15 (up to patches etc) ...
On Tue, Jul 26, 2011 at 04:00:42PM -0400, Genes MailLists wrote:
On 07/26/2011 02:54 PM, Dave Jones wrote: t sounds good - thanks! Aside from a few bugs/patches to come
still,
... curious which userspace pieces need updating .. (mdadm, procps ?)
with 2.6.40, hopefully nothing.
And with the 3.0.0 kernels - hopefully nothing as well .. so why go back to 2.6.40 ?
3.0.0 seems to be largely ok on F15 (up to patches etc) ...
fear of the unknown.
the obvious cases like "mdadm needs an update or you can't start raid" sticks out, but the more subtle breakage is harder to pinpoint, and time I'd rather not waste tracking down in f15, and having to do updates for. Those cases that need fixing will likely be fixed upstream, and we'll inherit them on f16 rebases.
Dave
On 07/26/2011 04:08 PM, Dave Jones wrote:
3.0.0 seems to be largely ok on F15 (up to patches etc) ...
fear of the unknown.
the obvious cases like "mdadm needs an update or you can't start raid" sticks out, but the more subtle breakage is harder to pinpoint, and time I'd rather not waste tracking down in f15, and having to do updates for. Those cases that need fixing will likely be fixed upstream, and we'll inherit them on f16 rebases.
Dave
:-) Fear enough :-)
(I installed mdadm and procps - but it looks like mdadm in f15 is now at same rev as rawhide ...)
Thanks for all you do .. and have done ... it is noticeable and appreciated ...
kernel@lists.fedoraproject.org
-
Amit Shah -
Bruno Wolff III -
Dave Jones -
drago01 -
Frank Ch. Eigler -
Genes MailLists -
Jarod Wilson -
Jason L Tibbitts III -
Joshua C. -
Kyle McMartin -
Michał Piotrowski