From jorton at redhat.com Wed Jan 7 15:18:12 2009 From: jorton at redhat.com (Joe Orton) Date: Wed, 7 Jan 2009 15:18:12 +0000 Subject: /proc/sys/fs/epoll/max_user_instances=128 considered harmful Message-ID: <20090107151812.GA12074@redhat.com> The F10 kernel has /proc/sys/fs/epoll/max_user_instances set to 128 by default. Apache httpd uses one epoll fd ("instance") per child process, so this sets a hard limit on 128 children (i.e. 100 concurrent clients) out of the box. 1) shouldn't this be an rlimit so that we can bump it appropriately in the parent as root? 2) can we get it tweaked in the default sysctl.conf to be something more sane, e.g. 1024? Regards, Joe From davej at redhat.com Wed Jan 7 22:01:22 2009 From: davej at redhat.com (Dave Jones) Date: Wed, 7 Jan 2009 17:01:22 -0500 Subject: /proc/sys/fs/epoll/max_user_instances=128 considered harmful In-Reply-To: <20090107151812.GA12074@redhat.com> References: <20090107151812.GA12074@redhat.com> Message-ID: <20090107220122.GB17904@redhat.com> On Wed, Jan 07, 2009 at 03:18:12PM +0000, Joe Orton wrote: > The F10 kernel has /proc/sys/fs/epoll/max_user_instances set to 128 by > default. Apache httpd uses one epoll fd ("instance") per child process, > so this sets a hard limit on 128 children (i.e. 100 concurrent clients) > out of the box. > > 1) shouldn't this be an rlimit so that we can bump it appropriately in > the parent as root? possibly. It's a question better asked on linux-kernel really. This does sound like a better change to me than forcing the sysctl change on everyone. Dave -- http://www.codemonkey.org.uk From fedora at leemhuis.info Thu Jan 8 06:17:30 2009 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Thu, 08 Jan 2009 07:17:30 +0100 Subject: Enabling drivers in staging tree in rawhide In-Reply-To: <496569B6.1090204@fedoraproject.org> References: <496569B6.1090204@fedoraproject.org> Message-ID: <49659A7A.8020804@leemhuis.info> CCing fedora-kernel On 08.01.2009 03:49, Rahul Sundaram wrote: > Quite a bit of new drivers in > http://lwn.net/Articles/313730/ Related: I raised the staging problem already in https://bugzilla.redhat.com/show_bug.cgi?id=477927 as rawhide contained the at76 driver as separate patch http://cvs.fedora.redhat.com/viewvc/rpms/kernel/devel/linux-2.6-at76.patch?view=markup -- but the same driver (with two small changes) also was part of the upstream kernel since October/2.6.28-rc as one of the staging drivers: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=99e06e372378c5833a0c60274b645dfb2e4a4b08 (for more details see bug). That sounds wrong to me, as - it's duplicated work - the at76 staging driver from upstream taints the kernel; the driver from our patch doesn't. > The ralink wireless drivers for example would hopefully make the newer > EEE PC model would out of the box. Does it make sense to enable the > drivers in staging tree by default and bring more exposure to them > atleast via rawhide if not in general releases? +1 to the "I think providing hardware support in rawhide and then removing it before release would be somewhat user-hostile." comment from mjg59. IOW: Either enable or disable them. I'm unsure myself what to do but I tend to say that disabling the whole staging drivers might be the best for Fedora (Greg calls himself as "maintainer of crap" for a good reason). @Davej, Cebbert and Kylem: What's your position on this? If they are disabled completely in Fedora then I'll nevertheless consider to create a "kmod-staging" package for RPM Fusion. CU knurd From jorton at redhat.com Thu Jan 8 10:47:21 2009 From: jorton at redhat.com (Joe Orton) Date: Thu, 8 Jan 2009 10:47:21 +0000 Subject: /proc/sys/fs/epoll/max_user_instances=128 considered harmful In-Reply-To: <20090107220122.GB17904@redhat.com> References: <20090107151812.GA12074@redhat.com> <20090107220122.GB17904@redhat.com> Message-ID: <20090108104721.GA5804@redhat.com> On Wed, Jan 07, 2009 at 05:01:22PM -0500, Dave Jones wrote: > On Wed, Jan 07, 2009 at 03:18:12PM +0000, Joe Orton wrote: > > The F10 kernel has /proc/sys/fs/epoll/max_user_instances set to 128 by > > default. Apache httpd uses one epoll fd ("instance") per child process, > > so this sets a hard limit on 128 children (i.e. 100 concurrent clients) > > out of the box. > > > > 1) shouldn't this be an rlimit so that we can bump it appropriately in > > the parent as root? > > possibly. It's a question better asked on linux-kernel really. > > This does sound like a better change to me than forcing the sysctl change > on everyone. Well, it's effectively a regression as-is. Any chance someone from the kernel team can chase this upstream? Regards, Joe From kyle at mcmartin.ca Thu Jan 8 15:31:54 2009 From: kyle at mcmartin.ca (Kyle McMartin) Date: Thu, 8 Jan 2009 10:31:54 -0500 Subject: Enabling drivers in staging tree in rawhide In-Reply-To: <49659A7A.8020804@leemhuis.info> References: <496569B6.1090204@fedoraproject.org> <49659A7A.8020804@leemhuis.info> Message-ID: <20090108153154.GB15684@bombadil.infradead.org> On Thu, Jan 08, 2009 at 07:17:30AM +0100, Thorsten Leemhuis wrote: > IOW: Either enable or disable them. I'm unsure myself what to do but I > tend to say that disabling the whole staging drivers might be the best > for Fedora (Greg calls himself as "maintainer of crap" for a good > reason). > > @Davej, Cebbert and Kylem: What's your position on this? > I was largely ignoring staging/ for maintainability reasons, but if there's sufficient demand I can take a look at enabling some of it on a case by case basis, as long as it won't cause a tragic amount of grief for everyone. regards, Kyle From davej at redhat.com Thu Jan 8 15:35:42 2009 From: davej at redhat.com (Dave Jones) Date: Thu, 8 Jan 2009 10:35:42 -0500 Subject: Enabling drivers in staging tree in rawhide In-Reply-To: <49659A7A.8020804@leemhuis.info> References: <496569B6.1090204@fedoraproject.org> <49659A7A.8020804@leemhuis.info> Message-ID: <20090108153542.GA14702@redhat.com> On Thu, Jan 08, 2009 at 07:17:30AM +0100, Thorsten Leemhuis wrote: > Related: I raised the staging problem already in > https://bugzilla.redhat.com/show_bug.cgi?id=477927 > as rawhide contained the at76 driver as separate patch > http://cvs.fedora.redhat.com/viewvc/rpms/kernel/devel/linux-2.6-at76.patch?view=markup > -- but the same driver (with two small changes) also was part of the > upstream kernel since October/2.6.28-rc as one of the staging drivers: > http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=99e06e372378c5833a0c60274b645dfb2e4a4b08 > (for more details see bug). > > That sounds wrong to me, as > > - it's duplicated work > > - the at76 staging driver from upstream taints the kernel; the driver > from our patch doesn't. The wireless stuff, I've pretty much deferred to the wireless maintainer, John Linville. I don't know the backstory behind at76, but it's been lingering for quite a while, and it would be nice to see it go away yes. I'm not clear on why this is going through -staging instead of wireless-dev either. > > The ralink wireless drivers for example would hopefully make the newer > > EEE PC model would out of the box. Does it make sense to enable the > > drivers in staging tree by default and bring more exposure to them > > atleast via rawhide if not in general releases? > > +1 to the "I think providing hardware support in rawhide and then > removing it before release would be somewhat user-hostile." comment > from mjg59. > > IOW: Either enable or disable them. I'm unsure myself what to do but I > tend to say that disabling the whole staging drivers might be the best > for Fedora (Greg calls himself as "maintainer of crap" for a good reason). > @Davej, Cebbert and Kylem: What's your position on this? I don't think we can make a carte-blanche statement to say "no we won't do this ever". The quality of the drivers that end up there are going to vary, and for some, if it's for a piece of hardware that's really popular, it may make sense to enable it. As long as doing so doesn't cause us headaches down the line. I'm not overly against the idea of enabling something with the caveat that we have someone responsible for working on it, with the goal of getting it out of staging, and dealing with bugs etc. Not unlike the same reasoning for us adding various not-yet-upstream drivers to the Fedora kernel really. But it's really going to be a case-by-case thing I think. Dave -- http://www.codemonkey.org.uk From dcbw at redhat.com Thu Jan 8 16:14:04 2009 From: dcbw at redhat.com (Dan Williams) Date: Thu, 08 Jan 2009 11:14:04 -0500 Subject: Enabling drivers in staging tree in rawhide In-Reply-To: <20090108153542.GA14702@redhat.com> References: <496569B6.1090204@fedoraproject.org> <49659A7A.8020804@leemhuis.info> <20090108153542.GA14702@redhat.com> Message-ID: <1231431244.21643.18.camel@localhost.localdomain> On Thu, 2009-01-08 at 10:35 -0500, Dave Jones wrote: > On Thu, Jan 08, 2009 at 07:17:30AM +0100, Thorsten Leemhuis wrote: > > > Related: I raised the staging problem already in > > https://bugzilla.redhat.com/show_bug.cgi?id=477927 > > as rawhide contained the at76 driver as separate patch > > http://cvs.fedora.redhat.com/viewvc/rpms/kernel/devel/linux-2.6-at76.patch?view=markup > > -- but the same driver (with two small changes) also was part of the > > upstream kernel since October/2.6.28-rc as one of the staging drivers: > > http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=99e06e372378c5833a0c60274b645dfb2e4a4b08 > > (for more details see bug). > > > > That sounds wrong to me, as > > > > - it's duplicated work > > > > - the at76 staging driver from upstream taints the kernel; the driver > > from our patch doesn't. > > The wireless stuff, I've pretty much deferred to the wireless maintainer, John Linville. > I don't know the backstory behind at76, but it's been lingering for > quite a while, and it would be nice to see it go away yes. > I'm not clear on why this is going through -staging instead of wireless-dev either. I would *not* recommend adding RTL staging driver at this time. There's a reason it wasn't imported into the actual kernel in the first place. -staging is a bad idea for precisely the reason we're talking about this now: it gives legitimacy to drivers of questionable quality. While it may make peoples hardware somewhat work, it certainly doesn't help make the system as a whole work *better*, because the drivers don't necessarily implement everything that, for example, wpa_supplicant or NetworkManager expect, or v4l2, or whatever. Does it use the in-kernel rfkill layer? Does it have correct locking and everything? Does it use the *standard kernel wireless stack*? The answer to at least two of these is "no", which is why it's not approved by the wireless developers yet, and never will be. Just because a driver makes hardware work, doesn't mean it makes hardware work *well* or play well with everything else. Dan > > > The ralink wireless drivers for example would hopefully make the newer > > > EEE PC model would out of the box. Does it make sense to enable the > > > drivers in staging tree by default and bring more exposure to them > > > atleast via rawhide if not in general releases? > > > > +1 to the "I think providing hardware support in rawhide and then > > removing it before release would be somewhat user-hostile." comment > > from mjg59. > > > > IOW: Either enable or disable them. I'm unsure myself what to do but I > > tend to say that disabling the whole staging drivers might be the best > > for Fedora (Greg calls himself as "maintainer of crap" for a good reason). > > @Davej, Cebbert and Kylem: What's your position on this? > > I don't think we can make a carte-blanche statement to say "no we won't do this ever". > The quality of the drivers that end up there are going to vary, and for some, > if it's for a piece of hardware that's really popular, it may make sense > to enable it. As long as doing so doesn't cause us headaches down the line. > > I'm not overly against the idea of enabling something with the caveat > that we have someone responsible for working on it, with the goal of > getting it out of staging, and dealing with bugs etc. > Not unlike the same reasoning for us adding various not-yet-upstream drivers > to the Fedora kernel really. > > But it's really going to be a case-by-case thing I think. > > Dave > > -- > http://www.codemonkey.org.uk > From dcbw at redhat.com Thu Jan 8 16:17:09 2009 From: dcbw at redhat.com (Dan Williams) Date: Thu, 08 Jan 2009 11:17:09 -0500 Subject: Enabling drivers in staging tree in rawhide In-Reply-To: <20090108153154.GB15684@bombadil.infradead.org> References: <496569B6.1090204@fedoraproject.org> <49659A7A.8020804@leemhuis.info> <20090108153154.GB15684@bombadil.infradead.org> Message-ID: <1231431429.21643.22.camel@localhost.localdomain> On Thu, 2009-01-08 at 10:31 -0500, Kyle McMartin wrote: > On Thu, Jan 08, 2009 at 07:17:30AM +0100, Thorsten Leemhuis wrote: > > IOW: Either enable or disable them. I'm unsure myself what to do but I > > tend to say that disabling the whole staging drivers might be the best > > for Fedora (Greg calls himself as "maintainer of crap" for a good > > reason). > > > > @Davej, Cebbert and Kylem: What's your position on this? > > > > I was largely ignoring staging/ for maintainability reasons, but if > there's sufficient demand I can take a look at enabling some of it on a > case by case basis, as long as it won't cause a tragic amount of grief > for everyone. The rtl driver has it's own 802.11 stack, just like linux-wlan-usb does (p80211), which is also in staging. I don't think we really want to be maintaining twice as many wireless stacks going forward, do we? Basically, I'm going to ignore any issues that come in from these drivers because they aren't accepted upstream wireless drivers, despite what gregkh (who's not a wireless developer) tries to make them. The upstream wireless people have made it clear that these drivers aren't acceptable in their current form, and it's unlikely either of these will be, given that they will essentially need a complete rewrite to use mac80211 (for rtl2860) and hostap (for linux-wlan-ng). Dan From linville at redhat.com Thu Jan 8 16:45:22 2009 From: linville at redhat.com (John W. Linville) Date: Thu, 8 Jan 2009 11:45:22 -0500 Subject: Enabling drivers in staging tree in rawhide In-Reply-To: <20090108153542.GA14702@redhat.com> References: <496569B6.1090204@fedoraproject.org> <49659A7A.8020804@leemhuis.info> <20090108153542.GA14702@redhat.com> Message-ID: <20090108164522.GA6069@redhat.com> On Thu, Jan 08, 2009 at 10:35:42AM -0500, Dave Jones wrote: > On Thu, Jan 08, 2009 at 07:17:30AM +0100, Thorsten Leemhuis wrote: > > > Related: I raised the staging problem already in > > https://bugzilla.redhat.com/show_bug.cgi?id=477927 > > as rawhide contained the at76 driver as separate patch > > http://cvs.fedora.redhat.com/viewvc/rpms/kernel/devel/linux-2.6-at76.patch?view=markup > > -- but the same driver (with two small changes) also was part of the > > upstream kernel since October/2.6.28-rc as one of the staging drivers: > > http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=99e06e372378c5833a0c60274b645dfb2e4a4b08 > > (for more details see bug). > > > > That sounds wrong to me, as > > > > - it's duplicated work > > > > - the at76 staging driver from upstream taints the kernel; the driver > > from our patch doesn't. > > The wireless stuff, I've pretty much deferred to the wireless maintainer, John Linville. > I don't know the backstory behind at76, but it's been lingering for > quite a while, and it would be nice to see it go away yes. > I'm not clear on why this is going through -staging instead of wireless-dev either. at76 looked like it was going to have a working mac80211-based version some time ago. The mac80211 port happened, but it broke the driver... :-( The version in -staging actually came from the Fedora kernel, so enabling it and dropping our patch isn't such a bad idea. I was concerned that the busted mac80211 port of it might come back (and it seem to have done so for now in 2.6.29), so I was leaning against it. (I'm still mostly against that unless we can get the mac80211 port backed-out of 2.6.29...) Now Kalle Valo says he is working on a new mac80211 port of that driver, and that he intends to rename it to avoid confusion. I presume that will get to Linus through my trees when it becomes available and hopefully at76_usb will disappear from -staging then. Does that clear-up anything? :-) John -- John W. Linville linville at redhat.com From kyle at mcmartin.ca Thu Jan 8 17:00:58 2009 From: kyle at mcmartin.ca (Kyle McMartin) Date: Thu, 8 Jan 2009 12:00:58 -0500 Subject: A really "big" kernel (in a dead weight) In-Reply-To: <20090108062020.GA6824@mail.harddata.com> References: <20090108062020.GA6824@mail.harddata.com> Message-ID: <20090108170058.GA15334@bombadil.infradead.org> On Wed, Jan 07, 2009 at 11:20:20PM -0700, Michal Jaegermann wrote: > I tried to install kernel-2.6.29-0.12.rc0.git7.fc11.x86_64. Its rpm > package is quite reasonable 24M in size. Only rpm started to complain > about insufficient space on /. A check with 'rpm -qip ...' revealed > that the package claims to expand to 1035938542 bytes. Around 1 gig! > > Unpacking this in some other place revealed that indeed > lib/modules/2.6.29-0.12.rc0.git7.fc11.x86_64/ eats 997M of disk. > Only this is heavily padded with null bytes. With > 'cp -a --sparse=always ...' aplied to that tree a target drops > in size to 76M. More than a thirteenfold reduction. > > It is true that the same operation performed on > lib/modules/2.6.29-0.9.rc0.git4.fc11.x86_64 reduces that from 188M > to 78M, which is still quite a lot, but what 2.6.29-0.12.rc0.git7.fc11 > is doing seems to be somewhat excessive. Is this is a side effect > of some changes in a build process? Something seems to be a tad > pushy. > > That "module fattening" surely adds a lot of extra time to kernel > installation scripts but other than that a kernel for which modules > were made sparse boots as any other one. The latest updates caused > other serious and so far mysterious breakage, and in particular > haldaemon does not run for me anymore, but that does look like a > kernel dependent. > Hitting up fedora-kernel-list would be helpful. ;-) Any idea which revision this was introduced in? If not, I'll start poking koji. cheers, Kyle From ahmad221284 at yahoo.com Fri Jan 9 16:32:25 2009 From: ahmad221284 at yahoo.com (Ahmad Al-Yaman) Date: Fri, 9 Jan 2009 08:32:25 -0800 (PST) Subject: Custom Kernel USB Boot Problem Message-ID: <310360.39550.qm@web51110.mail.re2.yahoo.com> Hi everyone, I'm building a custom kernel optimized for the Eee PC netbook. The kernel works without problems when installed on the main SSD but when I tried installing it on a USB flash disk, or SD card, and booted, I got the following error: Unable to access resume device (UUID=) mount: error mounting /dev/root on /sysroot as ext3: No such file or directory I'm assuming there are some packages necessary to boot from USB devices that need to be included in the kernel config which I didn't include. Can anyone give me an idea what those packages might be? Thank you. From snecklifter at gmail.com Fri Jan 9 23:11:24 2009 From: snecklifter at gmail.com (Christopher Brown) Date: Fri, 9 Jan 2009 23:11:24 +0000 Subject: Custom Kernel USB Boot Problem In-Reply-To: <310360.39550.qm@web51110.mail.re2.yahoo.com> References: <310360.39550.qm@web51110.mail.re2.yahoo.com> Message-ID: <364d303b0901091511t7ff92650p9611dfe05d60a1e4@mail.gmail.com> 2009/1/9 Ahmad Al-Yaman : > Hi everyone, I'm building a custom kernel optimized for the Eee PC netbook. The kernel works without problems when installed on the main SSD but when I tried installing it on a USB flash disk, or SD card, and booted, I got the following error: > > Unable to access resume device (UUID=) > mount: error mounting /dev/root on /sysroot as ext3: No such file or directory > > I'm assuming there are some packages necessary to boot from USB devices that need to be included in the kernel config which I didn't include. Can anyone give me an idea what those packages might be? Isn't this problems with mkinitrd? http://fedoraproject.org/wiki/Common_F10_bugs#Unbootable_new_installation_of_F10 There's not much point using journalled file systems on SSD btw - you should use ext2 to save your drive some unnecessary writes. Turn off swap too if you have it enabled. Regards -- Christopher Brown From notting at redhat.com Fri Jan 9 21:45:11 2009 From: notting at redhat.com (Bill Nottingham) Date: Fri, 9 Jan 2009 16:45:11 -0500 Subject: config changes Message-ID: <20090109214511.GA32637@nostromo.devel.redhat.com> Here's some proposed config changes. Bill -------------- next part -------------- ? diff ? kernel-2.6.27 ? linux-2.6.26.tar.bz2 ? linux-2.6.27.tar.bz2 ? patch-2.6.27-rc7-git3.bz2 ? patch-2.6.27-rc7.bz2 ? patch-2.6.28-rc9-git1.bz2 ? patch-2.6.28-rc9.bz2 Index: config-generic =================================================================== RCS file: /cvs/extras/rpms/kernel/devel/config-generic,v retrieving revision 1.217 diff -u -r1.217 config-generic --- config-generic 9 Jan 2009 21:33:41 -0000 1.217 +++ config-generic 9 Jan 2009 21:44:06 -0000 @@ -311,7 +311,7 @@ CONFIG_BLK_DEV=y CONFIG_BLK_DEV_FD=m # CONFIG_BLK_DEV_XD is not set -CONFIG_PARIDE=m +# CONFIG_PARIDE is not set CONFIG_PARIDE_PD=m CONFIG_PARIDE_PCD=m CONFIG_PARIDE_PF=m @@ -1480,7 +1480,7 @@ # # Amateur Radio support # -CONFIG_HAMRADIO=y +# CONFIG_HAMRADIO is not set CONFIG_AX25=m CONFIG_AX25_DAMA_SLAVE=y CONFIG_CAN=m From davej at redhat.com Sat Jan 10 06:44:13 2009 From: davej at redhat.com (Dave Jones) Date: Sat, 10 Jan 2009 01:44:13 -0500 Subject: Custom Kernel USB Boot Problem In-Reply-To: <310360.39550.qm@web51110.mail.re2.yahoo.com> References: <310360.39550.qm@web51110.mail.re2.yahoo.com> Message-ID: <20090110064413.GA15025@redhat.com> On Fri, Jan 09, 2009 at 08:32:25AM -0800, Ahmad Al-Yaman wrote: > Hi everyone, I'm building a custom kernel optimized for the Eee PC netbook. The kernel works without problems when installed on the main SSD but when I tried installing it on a USB flash disk, or SD card, and booted, I got the following error: > > Unable to access resume device (UUID=) > mount: error mounting /dev/root on /sysroot as ext3: No such file or directory > > I'm assuming there are some packages necessary to boot from USB devices that need to be included in the kernel config which I didn't include. Can anyone give me an idea what those packages might be? some random guesses.. mkinitrd probably doesn't support booting off of the mmc device. or if it does, perhaps the mmc modules are missing from the initrd. Dave -- http://www.codemonkey.org.uk From ahmad221284 at yahoo.com Sat Jan 10 08:56:17 2009 From: ahmad221284 at yahoo.com (Ahmad Al-Yaman) Date: Sat, 10 Jan 2009 00:56:17 -0800 (PST) Subject: Custom Kernel USB Boot Problem References: <310360.39550.qm@web51110.mail.re2.yahoo.com> <20090110064413.GA15025@redhat.com> Message-ID: <260963.91314.qm@web51107.mail.re2.yahoo.com> Well, I considered that, but the standard F10 kernel boots without any problems from both the USB flash disk and the SD card. It is only when I use my optimized kernel that I face problems booting. I enabled all the options that I could find in the kernel config which I thought were related to booting from USB devices but apparently I missed some. Ahmad ________________________________ From: Dave Jones To: Ahmad Al-Yaman Cc: fedora-kernel-list at redhat.com Sent: Saturday, January 10, 2009 8:44:13 AM Subject: Re: Custom Kernel USB Boot Problem On Fri, Jan 09, 2009 at 08:32:25AM -0800, Ahmad Al-Yaman wrote: > Hi everyone, I'm building a custom kernel optimized for the Eee PC netbook. The kernel works without problems when installed on the main SSD but when I tried installing it on a USB flash disk, or SD card, and booted, I got the following error: > > Unable to access resume device (UUID=) > mount: error mounting /dev/root on /sysroot as ext3: No such file or directory > > I'm assuming there are some packages necessary to boot from USB devices that need to be included in the kernel config which I didn't include. Can anyone give me an idea what those packages might be? some random guesses.. mkinitrd probably doesn't support booting off of the mmc device. or if it does, perhaps the mmc modules are missing from the initrd. Dave -- http://www.codemonkey.org.uk _______________________________________________ Fedora-kernel-list mailing list Fedora-kernel-list at redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list From sandeen at redhat.com Sun Jan 11 14:31:01 2009 From: sandeen at redhat.com (Eric Sandeen) Date: Sun, 11 Jan 2009 08:31:01 -0600 Subject: turn SND_HDA_POWER_SAVE_DEFAULT back on? Message-ID: <496A02A5.1020801@redhat.com> Can we turn the sound powersave options back on in rawhide? Based on http://git.kernel.org/git/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=02834f112d159eb87b584c7df56bddc5beeff5b3 http://git.kernel.org/git/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=36adba1fc79851949c4792f2e9b4d0dddbc6d5e4 (thanks to Thorsten Leemhuis for those pointers) it's no longer "experimental...." Thanks, -Eric From mjg at redhat.com Mon Jan 12 10:01:22 2009 From: mjg at redhat.com (Matthew Garrett) Date: Mon, 12 Jan 2009 10:01:22 +0000 Subject: turn SND_HDA_POWER_SAVE_DEFAULT back on? In-Reply-To: <496A02A5.1020801@redhat.com> References: <496A02A5.1020801@redhat.com> Message-ID: <20090112100122.GA17241@srcf.ucam.org> On Sun, Jan 11, 2009 at 08:31:01AM -0600, Eric Sandeen wrote: > (thanks to Thorsten Leemhuis for those pointers) it's no longer > "experimental...." It may no longer be functionally experimental, but does it still lead to popping on some hardware when the codec's powered up? -- Matthew Garrett | mjg59 at srcf.ucam.org From fedora at leemhuis.info Mon Jan 12 12:18:59 2009 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Mon, 12 Jan 2009 13:18:59 +0100 Subject: turn SND_HDA_POWER_SAVE_DEFAULT back on? In-Reply-To: <20090112100122.GA17241@srcf.ucam.org> References: <496A02A5.1020801@redhat.com> <20090112100122.GA17241@srcf.ucam.org> Message-ID: <496B3533.50906@leemhuis.info> On 12.01.2009 11:01, Matthew Garrett wrote: > On Sun, Jan 11, 2009 at 08:31:01AM -0600, Eric Sandeen wrote: > >> (thanks to Thorsten Leemhuis for those pointers) it's no longer >> "experimental...." > It may no longer be functionally experimental, but does it still lead to > popping on some hardware when the codec's powered up? Sure, that's the big question. But isn't now the best time to simply give it a try in rawhide as F11 is still a few month away? CU knurd From fedora at romal.de Mon Jan 12 18:26:56 2009 From: fedora at romal.de (Robert M. Albrecht) Date: Mon, 12 Jan 2009 19:26:56 +0100 Subject: 2.6.29 rc1 crashlog Message-ID: <496B8B70.2000300@romal.de> Hi, I updated the kernel and this crash is new. The systems boots, but it takes several minutes. Also the systems overall is very slow. This is running on an Asus EEE PC901 with Fedora 10 (not Rawhide). cu romal Jan 12 18:57:19 durin kernel: Linux version 2.6.29-0.28.rc1.fc11.i686 (mockbuild at x86-2.fedora.phx.redhat.com) (gcc version 4.3.2 20081105 (Red Hat 4.3.2-7) (GCC) ) #1 SMP Sun Jan 11 21:09:22 EST 2009 Jan 12 18:57:19 durin kernel: hpet0: at MMIO 0xfed00000, IRQs 2, 8, 0 Jan 12 18:57:19 durin kernel: hpet0: 3 comparators, 64-bit 14.318180 MHz counter Jan 12 18:57:19 durin kernel: ODEBUG: object is on stack, but not annotated Jan 12 18:57:19 durin kernel: ------------[ cut here ]------------ Jan 12 18:57:19 durin kernel: WARNING: at lib/debugobjects.c:253 __debug_object_init+0x25c/0x2f1() Jan 12 18:57:19 durin kernel: Hardware name: 901 Jan 12 18:57:19 durin kernel: Modules linked in: Jan 12 18:57:19 durin kernel: Pid: 1, comm: swapper Not tainted 2.6.29-0.28.rc1.fc11.i686 #1 Jan 12 18:57:19 durin kernel: Call Trace: Jan 12 18:57:19 durin kernel: [] warn_slowpath+0x71/0xa8 Jan 12 18:57:19 durin kernel: [] ? release_console_sem+0x5/0x1e0 Jan 12 18:57:19 durin kernel: [] ? trace_hardirqs_off_caller+0x18/0xa3 Jan 12 18:57:19 durin kernel: [] ? trace_hardirqs_off_caller+0x18/0xa3 Jan 12 18:57:19 durin kernel: [] ? trace_hardirqs_off+0xb/0xd Jan 12 18:57:19 durin kernel: [] ? _spin_unlock_irqrestore+0x39/0x50 Jan 12 18:57:19 durin kernel: [] ? release_console_sem+0x1b3/0x1e0 Jan 12 18:57:19 durin kernel: [] ? sched_clock+0x8/0xb Jan 12 18:57:19 durin kernel: [] ? lock_release_holdtime+0x30/0x131 Jan 12 18:57:19 durin kernel: [] ? __debug_object_init+0x164/0x2f1 Jan 12 18:57:19 durin kernel: [] __debug_object_init+0x25c/0x2f1 Jan 12 18:57:19 durin kernel: [] debug_object_init+0x13/0x16 Jan 12 18:57:19 durin kernel: [] init_timer+0x11/0x47 Jan 12 18:57:19 durin kernel: [] hpet_cpuhp_notify+0x78/0xca Jan 12 18:57:19 durin kernel: [] ? hpet_work+0x0/0x1b9 Jan 12 18:57:19 durin kernel: [] ? parse_args+0x69/0x1d2 Jan 12 18:57:19 durin kernel: [] ? hpet_alloc+0x337/0x37f Jan 12 18:57:19 durin kernel: [] hpet_late_init+0x14a/0x181 Jan 12 18:57:19 durin kernel: [] ? hpet_late_init+0x0/0x181 Jan 12 18:57:19 durin kernel: [] _stext+0x65/0x17a Jan 12 18:57:19 durin kernel: [] ? put_dec+0x2a/0xff Jan 12 18:57:19 durin kernel: [] ? register_lock_class+0x17/0x290 Jan 12 18:57:19 durin kernel: [] ? register_lock_class+0x17/0x290 Jan 12 18:57:19 durin kernel: [] ? mark_lock+0x1e/0x349 Jan 12 18:57:19 durin kernel: [] ? sched_clock+0x8/0xb Jan 12 18:57:19 durin kernel: [] ? lock_release_holdtime+0x30/0x131 Jan 12 18:57:19 durin kernel: [] ? check_valid_pointer+0x1f/0x4e Jan 12 18:57:19 durin kernel: [] ? mark_lock+0x1e/0x349 Jan 12 18:57:19 durin kernel: [] ? trace_hardirqs_on+0xb/0xd Jan 12 18:57:19 durin kernel: [] ? sched_clock+0x8/0xb Jan 12 18:57:19 durin kernel: [] ? lock_release_holdtime+0x30/0x131 Jan 12 18:57:19 durin kernel: [] ? proc_register+0x146/0x157 Jan 12 18:57:19 durin kernel: [] ? _raw_spin_unlock+0x74/0x78 Jan 12 18:57:19 durin kernel: [] ? _spin_unlock+0x1d/0x20 Jan 12 18:57:19 durin kernel: [] ? proc_register+0x146/0x157 Jan 12 18:57:19 durin kernel: [] ? create_proc_entry+0x7b/0x91 Jan 12 18:57:19 durin kernel: [] ? register_irq_proc+0x7f/0x9b Jan 12 18:57:19 durin kernel: [] ? init_irq_proc+0x53/0x60 Jan 12 18:57:19 durin kernel: [] kernel_init+0x17e/0x1cf Jan 12 18:57:19 durin kernel: [] ? kernel_init+0x0/0x1cf Jan 12 18:57:19 durin kernel: [] kernel_thread_helper+0x7/0x10 Jan 12 18:57:19 durin kernel: ---[ end trace 4eaa2a86a8e2da22 ]--- Jan 12 18:57:19 durin kernel: pnp: PnP ACPI init Jan 12 18:57:19 durin kernel: ACPI: bus type pnp registered Jan 12 18:57:19 durin kernel: pnp: PnP ACPI: found 13 devices -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: crash.log URL: From sandeen at redhat.com Mon Jan 12 21:26:30 2009 From: sandeen at redhat.com (Eric Sandeen) Date: Mon, 12 Jan 2009 15:26:30 -0600 Subject: turn SND_HDA_POWER_SAVE_DEFAULT back on? In-Reply-To: <496B3533.50906@leemhuis.info> References: <496A02A5.1020801@redhat.com> <20090112100122.GA17241@srcf.ucam.org> <496B3533.50906@leemhuis.info> Message-ID: <496BB586.8070204@redhat.com> Thorsten Leemhuis wrote: > On 12.01.2009 11:01, Matthew Garrett wrote: >> On Sun, Jan 11, 2009 at 08:31:01AM -0600, Eric Sandeen wrote: >> >>> (thanks to Thorsten Leemhuis for those pointers) it's no longer >>> "experimental...." >> It may no longer be functionally experimental, but does it still lead to >> popping on some hardware when the codec's powered up? > > Sure, that's the big question. But isn't now the best time to simply > give it a try in rawhide as F11 is still a few month away? Is there any reason to think that it has been fixed? If nothing has changed no reason to blow out someone's amp just for testing. :) I asked only because I was trying to make my mythbox power-efficient and noticed it was off; I can let the folks who've actually followed the issue make the change if appropriate, but wanted to bring it up at least. Thanks, -Eric From cebbert at redhat.com Mon Jan 12 21:55:24 2009 From: cebbert at redhat.com (Chuck Ebbert) Date: Mon, 12 Jan 2009 16:55:24 -0500 Subject: config changes In-Reply-To: <20090109214511.GA32637@nostromo.devel.redhat.com> References: <20090109214511.GA32637@nostromo.devel.redhat.com> Message-ID: <20090112165524.5c29d12d@dhcp-100-2-144.bos.redhat.com> On Fri, 9 Jan 2009 16:45:11 -0500 Bill Nottingham wrote: > Here's some proposed config changes. > >-CONFIG_HAMRADIO=y >+# CONFIG_HAMRADIO is not set hamradio was enabled because of user request. From fedora at leemhuis.info Tue Jan 13 06:11:44 2009 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Tue, 13 Jan 2009 07:11:44 +0100 Subject: turn SND_HDA_POWER_SAVE_DEFAULT back on? In-Reply-To: <496BB586.8070204@redhat.com> References: <496A02A5.1020801@redhat.com> <20090112100122.GA17241@srcf.ucam.org> <496B3533.50906@leemhuis.info> <496BB586.8070204@redhat.com> Message-ID: <496C30A0.8000707@leemhuis.info> On 12.01.2009 22:26, Eric Sandeen wrote: > Thorsten Leemhuis wrote: >> On 12.01.2009 11:01, Matthew Garrett wrote: >>> On Sun, Jan 11, 2009 at 08:31:01AM -0600, Eric Sandeen wrote: >>> >>>> (thanks to Thorsten Leemhuis for those pointers) it's no longer >>>> "experimental...." >>> It may no longer be functionally experimental, but does it still lead to >>> popping on some hardware when the codec's powered up? >> Sure, that's the big question. But isn't now the best time to simply >> give it a try in rawhide as F11 is still a few month away? > Is there any reason to think that it has been fixed? [...] I'm not that close to alsa development to tell; maybe someone else on this list is? But I tend to think the "it mature now" statements in the two commits that removed the experimental bit in 2.6.29-rc are a strong hint that they improved it after we tried it (which was soon after it was merged). > I asked only because I was trying to make my mythbox power-efficient and > noticed it was off; I can let the folks who've actually followed the > issue make the change if appropriate, but wanted to bring it up at least. And I would like the power management features on my machines to just work automatically. CU knurd From hdegoede at redhat.com Tue Jan 13 08:27:56 2009 From: hdegoede at redhat.com (Hans de Goede) Date: Tue, 13 Jan 2009 09:27:56 +0100 Subject: Change set acpi_enforce_resources default to strict ? Message-ID: <496C508C.10704@redhat.com> Hi Dave, The ACPI subsystem has a kernelcmdline setting called acpi_enforce_resources which defaults to lax, I would like to propose to change this the default to strict in *rawhide*. As you may (not) know I'm an active contributor to the lm_sensors project both to the userspace tools as to the kernel part (I've written and maintained numerous hwmon drivers, and yes feel free to assign any hwmon Fedora kernel bugs to me like you're doing with webcams :) Anyways back to changing the acpi_enforce_resources default, this change effects only the following 3 functions: acpi_check_resource_conflict() acpi_check_region() acpi_check_mem_region() These 3 methods only get used by smbus controller drivers and superio hwmon drivers. Actually they were added on our (lm_sensors project) request. The problem these functions try to fix is that sometimes the ACPI (byte)code touches hwmon IC's for doing things like thermalmanagement while we are banging the same IO's from native drivers. This is not good! So know all hwmon drivers which do direct IO (i2c drivers go through the smbus controller) call these functions to check if the ACPI tables claim the IO resources the smbus controller or superio hwmon driver touches. The idea here is that if ACPI claims the IO, the driver refuses to load. However this could be seen as a regression by users, as they were able to read their sensors using the native hwmon drivers before and now no longer will. Not loading however ofcourse is the safe and thus sane thing to do. As not loading could be seen as a regression the acpi_enforce_resources default is lax, which only causes a warning when ACPI claims the same resources as the driver is using, changing this to strict will outright make the driver not load. We would like to probe the water with how hard this change will make people scream, hence I would like to make this change in rawhide (and yes you may redirect all blame to me). So are you ok with giving this a try? Regards, Hans From kraxel at redhat.com Tue Jan 13 20:55:27 2009 From: kraxel at redhat.com (Gerd Hoffmann) Date: Tue, 13 Jan 2009 21:55:27 +0100 Subject: config changes In-Reply-To: <20090109214511.GA32637@nostromo.devel.redhat.com> References: <20090109214511.GA32637@nostromo.devel.redhat.com> Message-ID: <496CFFBF.5010503@redhat.com> Bill Nottingham wrote: > Here's some proposed config changes. Jumping on the wagon ;) Can we enable CONFIG_DMAR please? This turns on the IOMMU on intel boxes, using VT-d. Called "DMA Remapping" in intel speak, this is where the config option name comes from. Advantages: (1) 32bit PCI devices can DMA to memory above 4G, thus the need for swiotlb (i.e. bounce buffers) is gone. (2) It allows kvm to pass through PCI devices to guests securely. thanks, Gerd From davej at redhat.com Tue Jan 13 21:09:02 2009 From: davej at redhat.com (Dave Jones) Date: Tue, 13 Jan 2009 16:09:02 -0500 Subject: config changes In-Reply-To: <496CFFBF.5010503@redhat.com> References: <20090109214511.GA32637@nostromo.devel.redhat.com> <496CFFBF.5010503@redhat.com> Message-ID: <20090113210902.GA13927@redhat.com> On Tue, Jan 13, 2009 at 09:55:27PM +0100, Gerd Hoffmann wrote: > Bill Nottingham wrote: > > Here's some proposed config changes. > > Jumping on the wagon ;) > > Can we enable CONFIG_DMAR please? This turns on the IOMMU on intel > boxes, using VT-d. Called "DMA Remapping" in intel speak, this is where > the config option name comes from. Advantages: > > (1) 32bit PCI devices can DMA to memory above 4G, thus the need for > swiotlb (i.e. bounce buffers) is gone. > (2) It allows kvm to pass through PCI devices to guests securely. The last time we tried this, it blew up a lot due to broken BIOSes. Maybe it's been improved enough to tolerate them, so we can probably give it a spin in rawhide for a while to see what happens. Dave -- http://www.codemonkey.org.uk From kraxel at redhat.com Tue Jan 13 21:21:52 2009 From: kraxel at redhat.com (Gerd Hoffmann) Date: Tue, 13 Jan 2009 22:21:52 +0100 Subject: config changes In-Reply-To: <20090113210902.GA13927@redhat.com> References: <20090109214511.GA32637@nostromo.devel.redhat.com> <496CFFBF.5010503@redhat.com> <20090113210902.GA13927@redhat.com> Message-ID: <496D05F0.9090404@redhat.com> Dave Jones wrote: > On Tue, Jan 13, 2009 at 09:55:27PM +0100, Gerd Hoffmann wrote: > > Bill Nottingham wrote: > > > Here's some proposed config changes. > > > > Jumping on the wagon ;) > > > > Can we enable CONFIG_DMAR please? This turns on the IOMMU on intel > > boxes, using VT-d. Called "DMA Remapping" in intel speak, this is where > > the config option name comes from. Advantages: > > > > (1) 32bit PCI devices can DMA to memory above 4G, thus the need for > > swiotlb (i.e. bounce buffers) is gone. > > (2) It allows kvm to pass through PCI devices to guests securely. > > The last time we tried this, it blew up a lot due to broken BIOSes. Do you have bug numbers at hand? Searching for CONFIG_DMAR gives me "Zarro Boogs found". > Maybe it's been improved enough to tolerate them, so we can probably > give it a spin in rawhide for a while to see what happens. Well, it works for me. Single test box only though. As the machine in question actually has memory above 4G it is a nice speedup for kernel builds (sys time going down from ~15min to ~5min). cheers, Gerd From kyle at infradead.org Tue Jan 13 21:24:30 2009 From: kyle at infradead.org (Kyle McMartin) Date: Tue, 13 Jan 2009 16:24:30 -0500 Subject: config changes In-Reply-To: <496D05F0.9090404@redhat.com> References: <20090109214511.GA32637@nostromo.devel.redhat.com> <496CFFBF.5010503@redhat.com> <20090113210902.GA13927@redhat.com> <496D05F0.9090404@redhat.com> Message-ID: <20090113212430.GE25103@bombadil.infradead.org> On Tue, Jan 13, 2009 at 10:21:52PM +0100, Gerd Hoffmann wrote: > Dave Jones wrote: > > On Tue, Jan 13, 2009 at 09:55:27PM +0100, Gerd Hoffmann wrote: > > > Bill Nottingham wrote: > > > > Here's some proposed config changes. > > > > > > Jumping on the wagon ;) > > > > > > Can we enable CONFIG_DMAR please? This turns on the IOMMU on intel > > > boxes, using VT-d. Called "DMA Remapping" in intel speak, this is where > > > the config option name comes from. Advantages: > > > > > > (1) 32bit PCI devices can DMA to memory above 4G, thus the need for > > > swiotlb (i.e. bounce buffers) is gone. > > > (2) It allows kvm to pass through PCI devices to guests securely. > > > > The last time we tried this, it blew up a lot due to broken BIOSes. > > Do you have bug numbers at hand? > Searching for CONFIG_DMAR gives me "Zarro Boogs found". > > > Maybe it's been improved enough to tolerate them, so we can probably > > give it a spin in rawhide for a while to see what happens. > > Well, it works for me. Single test box only though. As the machine in > question actually has memory above 4G it is a nice speedup for kernel > builds (sys time going down from ~15min to ~5min). > I've just enabled it (and GFX_WA and FLOPPY_WA on x86_64.) (I'm suprised it's x86_64 only, surely virtualization enabled i386 could benefit from DMA protection?) From chrisw at redhat.com Tue Jan 13 21:39:13 2009 From: chrisw at redhat.com (Chris Wright) Date: Tue, 13 Jan 2009 13:39:13 -0800 Subject: config changes In-Reply-To: <20090113210902.GA13927@redhat.com> References: <20090109214511.GA32637@nostromo.devel.redhat.com> <496CFFBF.5010503@redhat.com> <20090113210902.GA13927@redhat.com> Message-ID: <20090113213913.GE3422@acer.localdomain> * Dave Jones (davej at redhat.com) wrote: > On Tue, Jan 13, 2009 at 09:55:27PM +0100, Gerd Hoffmann wrote: > > Bill Nottingham wrote: > > > Here's some proposed config changes. > > > > Jumping on the wagon ;) > > > > Can we enable CONFIG_DMAR please? This turns on the IOMMU on intel > > boxes, using VT-d. Called "DMA Remapping" in intel speak, this is where > > the config option name comes from. Advantages: > > > > (1) 32bit PCI devices can DMA to memory above 4G, thus the need for > > swiotlb (i.e. bounce buffers) is gone. > > (2) It allows kvm to pass through PCI devices to guests securely. > > The last time we tried this, it blew up a lot due to broken BIOSes. > Maybe it's been improved enough to tolerate them, so we can probably > give it a spin in rawhide for a while to see what happens. Upstream was still broken as recently as Friday for bad BIOSes (x200s in this case). Wonder if opt-in via cmdline would be helpful? thanks, -chris From tibbs at math.uh.edu Tue Jan 13 21:44:01 2009 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: 13 Jan 2009 15:44:01 -0600 Subject: config changes In-Reply-To: <20090113210902.GA13927@redhat.com> References: <20090109214511.GA32637@nostromo.devel.redhat.com> <496CFFBF.5010503@redhat.com> <20090113210902.GA13927@redhat.com> Message-ID: >>>>> "DJ" == Dave Jones writes: DJ> The last time we tried this, it blew up a lot due to broken DJ> BIOSes. Yes, this used to kill a bunch of my machines dead. It may be better now; I'm quite willing to boot test kernels if someone wants to point me at one. - J< From kraxel at redhat.com Tue Jan 13 21:59:10 2009 From: kraxel at redhat.com (Gerd Hoffmann) Date: Tue, 13 Jan 2009 22:59:10 +0100 Subject: config changes In-Reply-To: <20090113213913.GE3422@acer.localdomain> References: <20090109214511.GA32637@nostromo.devel.redhat.com> <496CFFBF.5010503@redhat.com> <20090113210902.GA13927@redhat.com> <20090113213913.GE3422@acer.localdomain> Message-ID: <496D0EAE.9090402@redhat.com> Chris Wright wrote: > Upstream was still broken as recently as Friday for bad BIOSes (x200s in > this case). Wonder if opt-in via cmdline would be helpful? Like the attached patch? Disclaimer: untested, build still running ... thanks, Gerd -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: patch URL: From Matt_Domsch at dell.com Tue Jan 13 22:00:41 2009 From: Matt_Domsch at dell.com (Matt Domsch) Date: Tue, 13 Jan 2009 16:00:41 -0600 Subject: config changes In-Reply-To: <20090113213913.GE3422@acer.localdomain> References: <20090109214511.GA32637@nostromo.devel.redhat.com> <496CFFBF.5010503@redhat.com> <20090113210902.GA13927@redhat.com> <20090113213913.GE3422@acer.localdomain> Message-ID: <20090113220041.GA14852@auslistsprd01.us.dell.com> On Tue, Jan 13, 2009 at 01:39:13PM -0800, Chris Wright wrote: > Upstream was still broken as recently as Friday for bad BIOSes (x200s in > this case). Wonder if opt-in via cmdline would be helpful? Do you know enough about the failure cases to DMI quirk it, plus an opt-out command line option, with it enabled as default? Thanks, Matt -- Matt Domsch Linux Technology Strategist, Dell Office of the CTO linux.dell.com & www.dell.com/linux From kyle at infradead.org Tue Jan 13 22:04:09 2009 From: kyle at infradead.org (Kyle McMartin) Date: Tue, 13 Jan 2009 17:04:09 -0500 Subject: config changes In-Reply-To: <20090113213913.GE3422@acer.localdomain> References: <20090109214511.GA32637@nostromo.devel.redhat.com> <496CFFBF.5010503@redhat.com> <20090113210902.GA13927@redhat.com> <20090113213913.GE3422@acer.localdomain> Message-ID: <20090113220409.GI25103@bombadil.infradead.org> On Tue, Jan 13, 2009 at 01:39:13PM -0800, Chris Wright wrote: > * Dave Jones (davej at redhat.com) wrote: > > On Tue, Jan 13, 2009 at 09:55:27PM +0100, Gerd Hoffmann wrote: > > > Bill Nottingham wrote: > > > > Here's some proposed config changes. > > > > > > Jumping on the wagon ;) > > > > > > Can we enable CONFIG_DMAR please? This turns on the IOMMU on intel > > > boxes, using VT-d. Called "DMA Remapping" in intel speak, this is where > > > the config option name comes from. Advantages: > > > > > > (1) 32bit PCI devices can DMA to memory above 4G, thus the need for > > > swiotlb (i.e. bounce buffers) is gone. > > > (2) It allows kvm to pass through PCI devices to guests securely. > > > > The last time we tried this, it blew up a lot due to broken BIOSes. > > Maybe it's been improved enough to tolerate them, so we can probably > > give it a spin in rawhide for a while to see what happens. > > Upstream was still broken as recently as Friday for bad BIOSes (x200s in > this case). Wonder if opt-in via cmdline would be helpful? > A patch from Dirk Hohndel fixes this (looks like it got merged Sundayish, after floating around linux-pci for a week.) AFAIK, at least. regards, Kyle From chrisw at redhat.com Tue Jan 13 22:47:18 2009 From: chrisw at redhat.com (Chris Wright) Date: Tue, 13 Jan 2009 14:47:18 -0800 Subject: config changes In-Reply-To: <20090113220409.GI25103@bombadil.infradead.org> References: <20090109214511.GA32637@nostromo.devel.redhat.com> <496CFFBF.5010503@redhat.com> <20090113210902.GA13927@redhat.com> <20090113213913.GE3422@acer.localdomain> <20090113220409.GI25103@bombadil.infradead.org> Message-ID: <20090113224718.GF3422@acer.localdomain> * Kyle McMartin (kyle at infradead.org) wrote: > On Tue, Jan 13, 2009 at 01:39:13PM -0800, Chris Wright wrote: > > Upstream was still broken as recently as Friday for bad BIOSes (x200s in > > this case). Wonder if opt-in via cmdline would be helpful? > > A patch from Dirk Hohndel fixes this (looks like it got merged > Sundayish, after floating around linux-pci for a week.) AFAIK, at least. Yeah, that's the case I was referring to. Mostly thinking that any feature like VT-d relying on BIOS will have some time to get defensive enough for all the ways BIOS can screw up the feature. thanks, -chris From kyle at infradead.org Tue Jan 13 22:50:13 2009 From: kyle at infradead.org (Kyle McMartin) Date: Tue, 13 Jan 2009 17:50:13 -0500 Subject: config changes In-Reply-To: <20090113224718.GF3422@acer.localdomain> References: <20090109214511.GA32637@nostromo.devel.redhat.com> <496CFFBF.5010503@redhat.com> <20090113210902.GA13927@redhat.com> <20090113213913.GE3422@acer.localdomain> <20090113220409.GI25103@bombadil.infradead.org> <20090113224718.GF3422@acer.localdomain> Message-ID: <20090113225013.GJ25103@bombadil.infradead.org> On Tue, Jan 13, 2009 at 02:47:18PM -0800, Chris Wright wrote: > * Kyle McMartin (kyle at infradead.org) wrote: > > On Tue, Jan 13, 2009 at 01:39:13PM -0800, Chris Wright wrote: > > > Upstream was still broken as recently as Friday for bad BIOSes (x200s in > > > this case). Wonder if opt-in via cmdline would be helpful? > > > > A patch from Dirk Hohndel fixes this (looks like it got merged > > Sundayish, after floating around linux-pci for a week.) AFAIK, at least. > > Yeah, that's the case I was referring to. Mostly thinking that any > feature like VT-d relying on BIOS will have some time to get defensive > enough for all the ways BIOS can screw up the feature. > No doubt it's going to end up like MSI. :( regards, Kyle From chrisw at redhat.com Tue Jan 13 23:06:13 2009 From: chrisw at redhat.com (Chris Wright) Date: Tue, 13 Jan 2009 15:06:13 -0800 Subject: config changes In-Reply-To: <20090113220041.GA14852@auslistsprd01.us.dell.com> References: <20090109214511.GA32637@nostromo.devel.redhat.com> <496CFFBF.5010503@redhat.com> <20090113210902.GA13927@redhat.com> <20090113213913.GE3422@acer.localdomain> <20090113220041.GA14852@auslistsprd01.us.dell.com> Message-ID: <20090113230613.GG3422@acer.localdomain> * Matt Domsch (Matt_Domsch at dell.com) wrote: > On Tue, Jan 13, 2009 at 01:39:13PM -0800, Chris Wright wrote: > > Upstream was still broken as recently as Friday for bad BIOSes (x200s in > > this case). Wonder if opt-in via cmdline would be helpful? > > Do you know enough about the failure cases to DMI quirk it, plus an > opt-out command line option, with it enabled as default? There is opt-out already. As Kyle pointed out, that particular issue has been fixed (as was another one w/ busted BIOS about a week ago). It's just an arms race ;-) FWIW, I'm in favor of enabling it (particularly to help aid KVM device assignement in rawhide). thanks, -chris From notting at redhat.com Wed Jan 14 18:17:38 2009 From: notting at redhat.com (Bill Nottingham) Date: Wed, 14 Jan 2009 13:17:38 -0500 Subject: [PATCH] build in microcode driver on x86 Message-ID: <20090114181738.GA26357@nostromo.devel.redhat.com> It doesn't really gain anything from being static, aside from requiring odd udev rules and/or init scripts to load it. Bill -------------- next part -------------- ? diff ? kernel-2.6.27 ? linux-2.6.26.tar.bz2 ? linux-2.6.27.tar.bz2 ? patch-2.6.27-rc7-git3.bz2 ? patch-2.6.27-rc7.bz2 ? patch-2.6.28-rc9-git1.bz2 ? patch-2.6.28-rc9.bz2 Index: config-x86-generic =================================================================== RCS file: /cvs/extras/rpms/kernel/devel/config-x86-generic,v retrieving revision 1.60 diff -u -r1.60 config-x86-generic --- config-x86-generic 13 Jan 2009 21:22:54 -0000 1.60 +++ config-x86-generic 14 Jan 2009 18:16:20 -0000 @@ -64,7 +64,7 @@ CONFIG_I8K=m CONFIG_SONYPI=m CONFIG_SONYPI_COMPAT=y -CONFIG_MICROCODE=m +CONFIG_MICROCODE=y CONFIG_X86_MSR=m CONFIG_X86_CPUID=m CONFIG_EDD=m Index: config-x86_64-generic =================================================================== RCS file: /cvs/extras/rpms/kernel/devel/config-x86_64-generic,v retrieving revision 1.63 diff -u -r1.63 config-x86_64-generic --- config-x86_64-generic 13 Jan 2009 21:22:54 -0000 1.63 +++ config-x86_64-generic 14 Jan 2009 18:16:20 -0000 @@ -18,7 +18,7 @@ # CONFIG_IA32_AOUT is not set # CONFIG_IOMMU_DEBUG is not set CONFIG_DEBUG_RODATA=y -CONFIG_MICROCODE=m +CONFIG_MICROCODE=y CONFIG_SWIOTLB=y CONFIG_CALGARY_IOMMU=y CONFIG_CALGARY_IOMMU_ENABLED_BY_DEFAULT=y From davej at redhat.com Wed Jan 14 18:49:57 2009 From: davej at redhat.com (Dave Jones) Date: Wed, 14 Jan 2009 13:49:57 -0500 Subject: [PATCH] build in microcode driver on x86 In-Reply-To: <20090114181738.GA26357@nostromo.devel.redhat.com> References: <20090114181738.GA26357@nostromo.devel.redhat.com> Message-ID: <20090114184957.GA10849@redhat.com> On Wed, Jan 14, 2009 at 01:17:38PM -0500, Bill Nottingham wrote: > It doesn't really gain anything from being static, aside from requiring > odd udev rules and/or init scripts to load it. We had this discussion yesterday on irc, but I never really got this in my head. It works ok with microcode.dat, but what happens if Intel release an update in /lib/firmware/intel-ucode/$f-$m-$s format ? The driver will do a request_firmware, but if we build the driver in, we'll be in the initrd, where that file won't exist. To make it work, we'll either have to.. - have the firmware in the initramfs or - pretend the request_firmware didn't happen, and have the initscript continue to do the microcode_ctl Which direction are we moving in ? Dave -- http://www.codemonkey.org.uk From notting at redhat.com Wed Jan 14 20:20:01 2009 From: notting at redhat.com (Bill Nottingham) Date: Wed, 14 Jan 2009 15:20:01 -0500 Subject: [PATCH] build in microcode driver on x86 In-Reply-To: <20090114184957.GA10849@redhat.com> References: <20090114181738.GA26357@nostromo.devel.redhat.com> <20090114184957.GA10849@redhat.com> Message-ID: <20090114202000.GA32395@nostromo.devel.redhat.com> Dave Jones (davej at redhat.com) said: > On Wed, Jan 14, 2009 at 01:17:38PM -0500, Bill Nottingham wrote: > > It doesn't really gain anything from being static, aside from requiring > > odd udev rules and/or init scripts to load it. > > We had this discussion yesterday on irc, but I never really got this in my head. > > It works ok with microcode.dat, but what happens if Intel release > an update in /lib/firmware/intel-ucode/$f-$m-$s format ? > > The driver will do a request_firmware, but if we build the driver in, > we'll be in the initrd, where that file won't exist. > To make it work, we'll either have to.. > > - have the firmware in the initramfs > > or > > - pretend the request_firmware didn't happen, and have the initscript > continue to do the microcode_ctl > > Which direction are we moving in ? AIUI, the driver's firmware request will get kicked off again when udev triggers all the normal coldplug events. So, that should be handled OK. Bill From davej at redhat.com Wed Jan 14 20:23:58 2009 From: davej at redhat.com (Dave Jones) Date: Wed, 14 Jan 2009 15:23:58 -0500 Subject: [PATCH] build in microcode driver on x86 In-Reply-To: <20090114202000.GA32395@nostromo.devel.redhat.com> References: <20090114181738.GA26357@nostromo.devel.redhat.com> <20090114184957.GA10849@redhat.com> <20090114202000.GA32395@nostromo.devel.redhat.com> Message-ID: <20090114202358.GB3767@redhat.com> On Wed, Jan 14, 2009 at 03:20:01PM -0500, Bill Nottingham wrote: > AIUI, the driver's firmware request will get kicked off again when > udev triggers all the normal coldplug events. So, that should be handled > OK. groovy. Should be safe to do then. Given we're always loading this on Intel (and I think AMD), might as well build it in. Dave -- http://www.codemonkey.org.uk From ajax at redhat.com Wed Jan 14 20:24:43 2009 From: ajax at redhat.com (Adam Jackson) Date: Wed, 14 Jan 2009 15:24:43 -0500 Subject: [PATCH] build in microcode driver on x86 In-Reply-To: <20090114184957.GA10849@redhat.com> References: <20090114181738.GA26357@nostromo.devel.redhat.com> <20090114184957.GA10849@redhat.com> Message-ID: <1231964683.28012.517.camel@atropine.boston.devel.redhat.com> On Wed, 2009-01-14 at 13:49 -0500, Dave Jones wrote: > On Wed, Jan 14, 2009 at 01:17:38PM -0500, Bill Nottingham wrote: > > It doesn't really gain anything from being static, aside from requiring > > odd udev rules and/or init scripts to load it. > > We had this discussion yesterday on irc, but I never really got this in my head. > > It works ok with microcode.dat, but what happens if Intel release > an update in /lib/firmware/intel-ucode/$f-$m-$s format ? Just to be clear, by "works ok" you mean "we request_firmware() for f/m/s and get nothing, and then some time later an initscript loads microcode.dat instead". If you actually need the microcode to get out of initramfs, you have already lost, and this move won't change anything. > The driver will do a request_firmware, but if we build the driver in, > we'll be in the initrd, where that file won't exist. > To make it work, we'll either have to.. > > - have the firmware in the initramfs Do we have any way of querying the kernel for firmware requests it will itself make? I don't think we do, let alone the ability to notice pattern matches like f/m/s. - ajax From notting at redhat.com Wed Jan 14 20:26:59 2009 From: notting at redhat.com (Bill Nottingham) Date: Wed, 14 Jan 2009 15:26:59 -0500 Subject: [PATCH] build in microcode driver on x86 In-Reply-To: <1231964683.28012.517.camel@atropine.boston.devel.redhat.com> References: <20090114181738.GA26357@nostromo.devel.redhat.com> <20090114184957.GA10849@redhat.com> <1231964683.28012.517.camel@atropine.boston.devel.redhat.com> Message-ID: <20090114202659.GC32395@nostromo.devel.redhat.com> Adam Jackson (ajax at redhat.com) said: > Do we have any way of querying the kernel for firmware requests it will > itself make? I don't think we do, let alone the ability to notice > pattern matches like f/m/s. There's the MODULE_FIRMWARE tag, but it obviously doesn't handle runtime-generated firmware names. Bill From davej at redhat.com Wed Jan 14 20:43:04 2009 From: davej at redhat.com (Dave Jones) Date: Wed, 14 Jan 2009 15:43:04 -0500 Subject: [PATCH] build in microcode driver on x86 In-Reply-To: <1231964683.28012.517.camel@atropine.boston.devel.redhat.com> References: <20090114181738.GA26357@nostromo.devel.redhat.com> <20090114184957.GA10849@redhat.com> <1231964683.28012.517.camel@atropine.boston.devel.redhat.com> Message-ID: <20090114204304.GC3767@redhat.com> On Wed, Jan 14, 2009 at 03:24:43PM -0500, Adam Jackson wrote: > Just to be clear, by "works ok" you mean "we request_firmware() for > f/m/s and get nothing, and then some time later an initscript loads > microcode.dat instead". sure. > If you actually need the microcode to get out > of initramfs, you have already lost, and this move won't change > anything. We've only ever had one case where an updated microcode was required to boot, and that was on pre-production hardware, so I don't think it's really that critical. Dave -- http://www.codemonkey.org.uk From ajax at redhat.com Wed Jan 14 22:19:19 2009 From: ajax at redhat.com (Adam Jackson) Date: Wed, 14 Jan 2009 17:19:19 -0500 Subject: [PATCH] build in microcode driver on x86 In-Reply-To: <20090114202659.GC32395@nostromo.devel.redhat.com> References: <20090114181738.GA26357@nostromo.devel.redhat.com> <20090114184957.GA10849@redhat.com> <1231964683.28012.517.camel@atropine.boston.devel.redhat.com> <20090114202659.GC32395@nostromo.devel.redhat.com> Message-ID: <1231971559.28012.571.camel@atropine.boston.devel.redhat.com> On Wed, 2009-01-14 at 15:26 -0500, Bill Nottingham wrote: > Adam Jackson (ajax at redhat.com) said: > > Do we have any way of querying the kernel for firmware requests it will > > itself make? I don't think we do, let alone the ability to notice > > pattern matches like f/m/s. > > There's the MODULE_FIRMWARE tag, but it obviously doesn't handle > runtime-generated firmware names. Hmm. Wrap all firmware in ELF EM_NONE headers, add modinfo sections so we can pattern match? - ajax From zaitcev at redhat.com Thu Jan 15 00:06:13 2009 From: zaitcev at redhat.com (Pete Zaitcev) Date: Wed, 14 Jan 2009 17:06:13 -0700 Subject: [PATCH] build in microcode driver on x86 In-Reply-To: <20090114184957.GA10849@redhat.com> References: <20090114181738.GA26357@nostromo.devel.redhat.com> <20090114184957.GA10849@redhat.com> Message-ID: <20090114170613.4de33e60.zaitcev@redhat.com> On Wed, 14 Jan 2009 13:49:57 -0500, Dave Jones wrote: > On Wed, Jan 14, 2009 at 01:17:38PM -0500, Bill Nottingham wrote: > > It doesn't really gain anything from being static, aside from requiring > > odd udev rules and/or init scripts to load it. > The driver will do a request_firmware, but if we build the driver in, > we'll be in the initrd, where that file won't exist. > To make it work, we'll either have to.. A trick exists to go around it: http://people.redhat.com/zaitcev/linux/linux-2.6.27-204396-5.diff If you recall, libusual has the same problem if it's built in. -- Pete From kyle at mcmartin.ca Thu Jan 15 08:19:45 2009 From: kyle at mcmartin.ca (Kyle McMartin) Date: Thu, 15 Jan 2009 03:19:45 -0500 Subject: applypatch.sh script Message-ID: <20090115081945.GB7488@bombadil.infradead.org> I dislike looking at those C=`wc -l ..` if [ -gt ... ] things in the spec-file... How about something like this? ? prep2.log Index: kernel.spec =================================================================== RCS file: /cvs/pkgs/rpms/kernel/devel/kernel.spec,v retrieving revision 1.1218 diff -u -p -r1.1218 kernel.spec --- kernel.spec 15 Jan 2009 07:41:04 -0000 1.1218 +++ kernel.spec 15 Jan 2009 08:16:29 -0000 @@ -862,19 +862,12 @@ exit 1 %endif %endif -patch_command='patch -p1 -F1 -s' ApplyPatch() { local patch=$1 shift - if [ ! -f $RPM_SOURCE_DIR/$patch ]; then - exit 1; - fi - case "$patch" in - *.bz2) bunzip2 < "$RPM_SOURCE_DIR/$patch" | $patch_command ${1+"$@"} ;; - *.gz) gunzip < "$RPM_SOURCE_DIR/$patch" | $patch_command ${1+"$@"} ;; - *) $patch_command ${1+"$@"} < "$RPM_SOURCE_DIR/$patch" ;; - esac + + $RPM_SOURCE_DIR/scripts/applypatch.sh "$RPM_SOURCE_DIR/$patch" ${1+"$@"} } # First we unpack the kernel tarball. @@ -998,18 +991,12 @@ ApplyPatch linux-2.6-makefile-after_link # # misc small stuff to make things compile # -C=$(wc -l $RPM_SOURCE_DIR/linux-2.6-compile-fixes.patch | awk '{print $1}') -if [ "$C" -gt 10 ]; then ApplyPatch linux-2.6-compile-fixes.patch -fi %if !%{nopatches} # revert patches from upstream that conflict or that we get via other means -C=$(wc -l $RPM_SOURCE_DIR/linux-2.6-upstream-reverts.patch | awk '{print $1}') -if [ "$C" -gt 10 ]; then ApplyPatch linux-2.6-upstream-reverts.patch -R -fi #ApplyPatch git-cpufreq.patch @@ -1151,10 +1138,7 @@ ApplyPatch linux-2.6-net-tulip-interrupt # linux1394 git patches #ApplyPatch linux-2.6-firewire-git-update.patch -C=$(wc -l $RPM_SOURCE_DIR/linux-2.6-firewire-git-pending.patch | awk '{print $1}') -if [ "$C" -gt 10 ]; then ApplyPatch linux-2.6-firewire-git-pending.patch -fi # silence the ACPI blacklist code ApplyPatch linux-2.6-silence-acpi-blacklist.patch Index: scripts/applypatch.sh =================================================================== RCS file: scripts/applypatch.sh diff -N scripts/applypatch.sh --- /dev/null 1 Jan 1970 00:00:00 -0000 +++ scripts/applypatch.sh 15 Jan 2009 08:16:29 -0000 @@ -0,0 +1,28 @@ +#!/bin/bash + +patch=$1 +shift + +# echo "<< applying $patch " + +if [ ! -f $patch ]; then + echo "applypatch: $patch was missing!"; + exit 1; +fi + +# ignore empty patches, culls the ugly wc -l checks we had +# around applypatch formerly... +if [[ `diffstat $patch | grep " 0 files changed"` ]]; then + echo "applypatch: $patch is empty"; + exit 0; +fi + +patchcmd='patch -p1 -F1 -s' + +case "$patch" in + *.bz2) bunzip2 < "$patch" | $patchcmd ${1+"$@"} ;; + *.gz) gunzip < "$patch" | $patchcmd ${1+"$@"} ;; + *) $patchcmd ${1+"$@"} < "$patch" ;; +esac + +# echo ">> " From jwboyer at gmail.com Thu Jan 15 12:48:30 2009 From: jwboyer at gmail.com (Josh Boyer) Date: Thu, 15 Jan 2009 07:48:30 -0500 Subject: applypatch.sh script In-Reply-To: <20090115081945.GB7488@bombadil.infradead.org> References: <20090115081945.GB7488@bombadil.infradead.org> Message-ID: <20090115124830.GB2582@yoda.jdub.homelinux.org> On Thu, Jan 15, 2009 at 03:19:45AM -0500, Kyle McMartin wrote: >I dislike looking at those >C=`wc -l ..` >if [ -gt ... ] > >things in the spec-file... > >How about something like this? Neat. Although if you're going to bust it out into a separate script, I'm not sure why you don't just use quilt and be done with it. Also, any reason we don't use -F0 for the patch arguments? josh From jwboyer at gmail.com Fri Jan 16 14:29:35 2009 From: jwboyer at gmail.com (Josh Boyer) Date: Fri, 16 Jan 2009 09:29:35 -0500 Subject: PPC kernel build times Message-ID: <20090116142935.GA14516@yoda.jdub.homelinux.org> So I poked around at why ppc builds seem so slow. Net result: I still have no idea. On a quad-970 machine with 2GiB of DRAM running the latest F-9, I did a 'make ppc64' build of the devel kernel with a modified kernel.spec file that spit out some basic timestamps on the RPM sections. Results: Total time: real 65m58.701s user 89m53.501s sys 11m4.737s Each section: Prep: 52 seconds Build: ~33 minutes Install: 38 seconds [jwboyer at yoda devel]$ grep -e Prep -e Build -e Install .build-2.6.29-0.39.rc1.git5.fc11.log | grep -v + Building target platforms: ppc64 Building for target ppc64 Prep Start: Thu Jan 15 15:48:16 EST 2009 Prep End: Thu Jan 15 15:49:08 EST 2009 Build Start: Thu Jan 15 15:49:08 EST 2009 Build End: Thu Jan 15 16:22:57 EST 2009 Install Start: Thu Jan 15 16:22:57 EST 2009 Install End: Thu Jan 15 16:23:35 EST 2009 The overall time is slightly faster than the koji builds I've seen by a few minutes. This is somewhat expected, as my box wasn't really doing much else at the time and some of the builders are blades with fewer cores and slower hard drives. Since I had nothing better to do in my sad life, I was watching the top output a bit during one of my builds. I noticed that when rpmbuild got to the part where it was writing out the -debuginfo RPM, it took almost 18 minutes. Why this is, I have no idea. For gits and shiggles, I grabbed the config from the resulting RPM and used it with a 'time make -j4' on Linus' latest git tree: real 28m46.829s user 70m30.520s sys 7m43.533s So the build time seems roughly equivalent. Yay for doing stuff that garners no new insight! josh From avi at redhat.com Mon Jan 19 13:49:20 2009 From: avi at redhat.com (Avi Kivity) Date: Mon, 19 Jan 2009 15:49:20 +0200 Subject: Switching Fedora to pae kernel by default? Message-ID: <497484E0.7080000@qumranet.com> This probably comes up once in a while, thought I'd raise it again. I'd like to suggest switching the default kernel to -PAE on machines that support it, for the following reasons: - many machines have 4GB+ these days, even desktops - NX is only available with -PAE, improves security - kvm is significantly faster on AMD when PAE is selected (since we don't support NPT on non-PAE) Not subscribed - please copy. -- error compiling committee.c: too many arguments to function From davej at redhat.com Mon Jan 19 16:03:37 2009 From: davej at redhat.com (Dave Jones) Date: Mon, 19 Jan 2009 11:03:37 -0500 Subject: Switching Fedora to pae kernel by default? In-Reply-To: <497484E0.7080000@qumranet.com> References: <497484E0.7080000@qumranet.com> Message-ID: <20090119160337.GB7270@redhat.com> On Mon, Jan 19, 2009 at 03:49:20PM +0200, Avi Kivity wrote: > This probably comes up once in a while, thought I'd raise it again. > > I'd like to suggest switching the default kernel to -PAE on machines > that support it, for the following reasons: > > - many machines have 4GB+ these days, even desktops > - NX is only available with -PAE, improves security > - kvm is significantly faster on AMD when PAE is selected (since we > don't support NPT on non-PAE) What's needed to set this by default is changes in anaconda. They have their own list at anaconda-list at redhat.com Dave -- http://www.codemonkey.org.uk From notting at redhat.com Mon Jan 19 16:23:26 2009 From: notting at redhat.com (Bill Nottingham) Date: Mon, 19 Jan 2009 11:23:26 -0500 Subject: Switching Fedora to pae kernel by default? In-Reply-To: <20090119160337.GB7270@redhat.com> References: <497484E0.7080000@qumranet.com> <20090119160337.GB7270@redhat.com> Message-ID: <20090119162325.GA3822@nostromo.devel.redhat.com> Dave Jones (davej at redhat.com) said: > On Mon, Jan 19, 2009 at 03:49:20PM +0200, Avi Kivity wrote: > > This probably comes up once in a while, thought I'd raise it again. > > > > I'd like to suggest switching the default kernel to -PAE on machines > > that support it, for the following reasons: > > > > - many machines have 4GB+ these days, even desktops > > - NX is only available with -PAE, improves security > > - kvm is significantly faster on AMD when PAE is selected (since we > > don't support NPT on non-PAE) > > What's needed to set this by default is changes in anaconda. > They have their own list at anaconda-list at redhat.com anaconda-devel-list, actually. But I could have sworn we already did this. Bill From kyle at infradead.org Mon Jan 19 16:40:41 2009 From: kyle at infradead.org (Kyle McMartin) Date: Mon, 19 Jan 2009 11:40:41 -0500 Subject: Switching Fedora to pae kernel by default? In-Reply-To: <20090119162325.GA3822@nostromo.devel.redhat.com> References: <497484E0.7080000@qumranet.com> <20090119160337.GB7270@redhat.com> <20090119162325.GA3822@nostromo.devel.redhat.com> Message-ID: <20090119164041.GB24251@bombadil.infradead.org> On Mon, Jan 19, 2009 at 11:23:26AM -0500, Bill Nottingham wrote: > Dave Jones (davej at redhat.com) said: > > On Mon, Jan 19, 2009 at 03:49:20PM +0200, Avi Kivity wrote: > > > This probably comes up once in a while, thought I'd raise it again. > > > > > > I'd like to suggest switching the default kernel to -PAE on machines > > > that support it, for the following reasons: > > > > > > - many machines have 4GB+ these days, even desktops > > > - NX is only available with -PAE, improves security > > > - kvm is significantly faster on AMD when PAE is selected (since we > > > don't support NPT on non-PAE) > > > > What's needed to set this by default is changes in anaconda. > > They have their own list at anaconda-list at redhat.com > > anaconda-devel-list, actually. But I could have sworn we already did this. > Unless we keep the non-PAE i586 kernel around as a fallback, we're not going to be able to boot on a whole raft of crappy i386 chips (original Pentium M most notably...) regards, Kyle From katzj at redhat.com Mon Jan 19 17:05:28 2009 From: katzj at redhat.com (Jeremy Katz) Date: Mon, 19 Jan 2009 12:05:28 -0500 Subject: Switching Fedora to pae kernel by default? In-Reply-To: <20090119162325.GA3822@nostromo.devel.redhat.com> References: <497484E0.7080000@qumranet.com> <20090119160337.GB7270@redhat.com> <20090119162325.GA3822@nostromo.devel.redhat.com> Message-ID: <20090119170527.GA6090@redhat.com> On Monday, January 19 2009, Bill Nottingham said: > Dave Jones (davej at redhat.com) said: > > On Mon, Jan 19, 2009 at 03:49:20PM +0200, Avi Kivity wrote: > > > This probably comes up once in a while, thought I'd raise it again. > > > > > > I'd like to suggest switching the default kernel to -PAE on machines > > > that support it, for the following reasons: > > > > > > - many machines have 4GB+ these days, even desktops > > > - NX is only available with -PAE, improves security > > > - kvm is significantly faster on AMD when PAE is selected (since we > > > don't support NPT on non-PAE) > > > > What's needed to set this by default is changes in anaconda. > > They have their own list at anaconda-list at redhat.com > > anaconda-devel-list, actually. But I could have sworn we already did this. Well, we're not going to make the change unless kernel guys want us to. That said, we currently do install the PAE kernel if you have 4 GB+ of RAM[1]. Switching to it by default is problematic because then we're back to using different kernels for different cases and it also makes the 'what do you with the live image' case a lot more complex. The _real_ fix here is to get PAE runtime much like was finally done with SMP :-) Jeremy [1] Well, any memory above 4 GB actually -- so if you have a machine with a large hole and only 3 GB of RAM, you could end up with the PAE kernel From avi at redhat.com Mon Jan 19 17:07:26 2009 From: avi at redhat.com (Avi Kivity) Date: Mon, 19 Jan 2009 19:07:26 +0200 Subject: Switching Fedora to pae kernel by default? In-Reply-To: <20090119162325.GA3822@nostromo.devel.redhat.com> References: <497484E0.7080000@qumranet.com> <20090119160337.GB7270@redhat.com> <20090119162325.GA3822@nostromo.devel.redhat.com> Message-ID: <4974B34E.5070208@redhat.com> Bill Nottingham wrote: > Dave Jones (davej at redhat.com) said: > >> On Mon, Jan 19, 2009 at 03:49:20PM +0200, Avi Kivity wrote: >> > This probably comes up once in a while, thought I'd raise it again. >> > >> > I'd like to suggest switching the default kernel to -PAE on machines >> > that support it, for the following reasons: >> > >> > - many machines have 4GB+ these days, even desktops >> > - NX is only available with -PAE, improves security >> > - kvm is significantly faster on AMD when PAE is selected (since we >> > don't support NPT on non-PAE) >> >> What's needed to set this by default is changes in anaconda. >> They have their own list at anaconda-list at redhat.com >> > > anaconda-devel-list, actually. But I could have sworn we already did this. > Just tested; F10 i386 still installs a non-PAE kernel. -- error compiling committee.c: too many arguments to function From avi at redhat.com Mon Jan 19 17:14:30 2009 From: avi at redhat.com (Avi Kivity) Date: Mon, 19 Jan 2009 19:14:30 +0200 Subject: Switching Fedora to pae kernel by default? In-Reply-To: <20090119170527.GA6090@redhat.com> References: <497484E0.7080000@qumranet.com> <20090119160337.GB7270@redhat.com> <20090119162325.GA3822@nostromo.devel.redhat.com> <20090119170527.GA6090@redhat.com> Message-ID: <4974B4F6.8010002@redhat.com> Jeremy Katz wrote: > That said, we currently do install the PAE kernel if you have 4 GB+ of > RAM[1]. Switching to it by default is problematic because then we're > back to using different kernels for different cases You have that now, don't you? One case for <4GB and one for >=4GB. Worse, if you install more memory, the kernel doesn't see it. Downgrading your CPU to one which does not support PAE should be rare. > and it also makes > the 'what do you with the live image' case a lot more complex. I'd just go with PAE here. > The _real_ fix here is to get PAE runtime much like was finally done > with SMP :-) > Patches, as they say, are welcome. But you could install both kernels and have the bootloaded choose (sticks wax balls into ears). -- error compiling committee.c: too many arguments to function From avi at redhat.com Mon Jan 19 17:31:12 2009 From: avi at redhat.com (Avi Kivity) Date: Mon, 19 Jan 2009 19:31:12 +0200 Subject: Switching Fedora to pae kernel by default? In-Reply-To: <20090119164041.GB24251@bombadil.infradead.org> References: <497484E0.7080000@qumranet.com> <20090119160337.GB7270@redhat.com> <20090119162325.GA3822@nostromo.devel.redhat.com> <20090119164041.GB24251@bombadil.infradead.org> Message-ID: <4974B8E0.8050301@redhat.com> Kyle McMartin wrote: > On Mon, Jan 19, 2009 at 11:23:26AM -0500, Bill Nottingham wrote: > >> Dave Jones (davej at redhat.com) said: >> >>> On Mon, Jan 19, 2009 at 03:49:20PM +0200, Avi Kivity wrote: >>> > This probably comes up once in a while, thought I'd raise it again. >>> > >>> > I'd like to suggest switching the default kernel to -PAE on machines >>> > that support it, for the following reasons: >>> > >>> > - many machines have 4GB+ these days, even desktops >>> > - NX is only available with -PAE, improves security >>> > - kvm is significantly faster on AMD when PAE is selected (since we >>> > don't support NPT on non-PAE) >>> >>> What's needed to set this by default is changes in anaconda. >>> They have their own list at anaconda-list at redhat.com >>> > Unless we keep the non-PAE i586 kernel around as a fallback, we're not > going to be able to boot on a whole raft of crappy i386 chips (original > Pentium M most notably...) I'm not suggesting dropping non-PAE. Simply defaulting to PAE where possible. Are Pentium Ms (really the memory that comes with them) actually capable of running recent Fedoras? I'm talking desktop, not I'm-using-my-laptop-as-a-firewall-just-because-I-can. -- error compiling committee.c: too many arguments to function From katzj at redhat.com Mon Jan 19 17:39:19 2009 From: katzj at redhat.com (Jeremy Katz) Date: Mon, 19 Jan 2009 12:39:19 -0500 Subject: Switching Fedora to pae kernel by default? In-Reply-To: <4974B4F6.8010002@redhat.com> References: <497484E0.7080000@qumranet.com> <20090119160337.GB7270@redhat.com> <20090119162325.GA3822@nostromo.devel.redhat.com> <20090119170527.GA6090@redhat.com> <4974B4F6.8010002@redhat.com> Message-ID: <20090119173919.GB6090@redhat.com> On Monday, January 19 2009, Avi Kivity said: > Jeremy Katz wrote: >> That said, we currently do install the PAE kernel if you have 4 GB+ of >> RAM[1]. Switching to it by default is problematic because then we're >> back to using different kernels for different cases > > You have that now, don't you? One case for <4GB and one for >=4GB. > Worse, if you install more memory, the kernel doesn't see it. > > Downgrading your CPU to one which does not support PAE should be rare. Yes, but at least the "running a different kernel" case is currently the relatively rare one. >> and it also makes >> the 'what do you with the live image' case a lot more complex. > > I'd just go with PAE here. Can't do so -- the live image is definitely used on a lot of hardware that isn't PAE capable. Many/most Pentium M's didn't support it, the OLPC doesn't[1]. And those are common hardware targets for the live image >> The _real_ fix here is to get PAE runtime much like was finally done >> with SMP :-) > > Patches, as they say, are welcome. Low-level x86 setup code isn't quite my forte... Hence I go for goading others into doing it ;-) > But you could install both kernels > and have the bootloaded choose (sticks wax balls into ears). Want to write code for syslinux and grub to do the auto-choosing? Then we also have to figure out a way to shoe-horn another 50 MB of stuff into the already full live image Jeremy From eparis at redhat.com Mon Jan 19 17:53:24 2009 From: eparis at redhat.com (Eric Paris) Date: Mon, 19 Jan 2009 12:53:24 -0500 Subject: Switching Fedora to pae kernel by default? In-Reply-To: <4974B8E0.8050301@redhat.com> References: <497484E0.7080000@qumranet.com> <20090119160337.GB7270@redhat.com> <20090119162325.GA3822@nostromo.devel.redhat.com> <20090119164041.GB24251@bombadil.infradead.org> <4974B8E0.8050301@redhat.com> Message-ID: <1232387604.3942.17.camel@localhost.localdomain> On Mon, 2009-01-19 at 19:31 +0200, Avi Kivity wrote: > Kyle McMartin wrote: > > On Mon, Jan 19, 2009 at 11:23:26AM -0500, Bill Nottingham wrote: > > > >> Dave Jones (davej at redhat.com) said: > >> > >>> On Mon, Jan 19, 2009 at 03:49:20PM +0200, Avi Kivity wrote: > >>> > This probably comes up once in a while, thought I'd raise it again. > >>> > > >>> > I'd like to suggest switching the default kernel to -PAE on machines > >>> > that support it, for the following reasons: > >>> > > >>> > - many machines have 4GB+ these days, even desktops > >>> > - NX is only available with -PAE, improves security > >>> > - kvm is significantly faster on AMD when PAE is selected (since we > >>> > don't support NPT on non-PAE) > >>> > >>> What's needed to set this by default is changes in anaconda. > >>> They have their own list at anaconda-list at redhat.com > >>> > > Unless we keep the non-PAE i586 kernel around as a fallback, we're not > > going to be able to boot on a whole raft of crappy i386 chips (original > > Pentium M most notably...) > > I'm not suggesting dropping non-PAE. Simply defaulting to PAE where > possible. > > Are Pentium Ms (really the memory that comes with them) actually capable > of running recent Fedoras? I'm talking desktop, not > I'm-using-my-laptop-as-a-firewall-just-because-I-can. I've got a P3 (Coppermine) with 256M memory running F10. My significant other took it with her to Antarctica (Well F9 has been to Antarctica but it'll be F10 in Antarctica next month). You can only run one app at a time and have to be patient, but it's perfectly usable (and noone cares if this laptop is lost, stolen or destroyed [aside from her being pissed she lost all her research data]). I wouldn't/couldn't to use it as a daily machine, so while I'm in favor of -PAE default, F10 is "usable" on such small machines. I don't care if old machines need some bit twiddling to get to work, but we aren't dead yet :) -Eric From notting at redhat.com Mon Jan 19 18:01:32 2009 From: notting at redhat.com (Bill Nottingham) Date: Mon, 19 Jan 2009 13:01:32 -0500 Subject: Switching Fedora to pae kernel by default? In-Reply-To: <4974B8E0.8050301@redhat.com> References: <497484E0.7080000@qumranet.com> <20090119160337.GB7270@redhat.com> <20090119162325.GA3822@nostromo.devel.redhat.com> <20090119164041.GB24251@bombadil.infradead.org> <4974B8E0.8050301@redhat.com> Message-ID: <20090119180131.GF3822@nostromo.devel.redhat.com> Avi Kivity (avi at redhat.com) said: > Are Pentium Ms (really the memory that comes with them) actually capable > of running recent Fedoras? I'm talking desktop, not > I'm-using-my-laptop-as-a-firewall-just-because-I-can. Sure, I had a T40 that had 1.5GB of memory in it, and it could have taken more. Bill From zaitcev at redhat.com Mon Jan 19 18:24:14 2009 From: zaitcev at redhat.com (Pete Zaitcev) Date: Mon, 19 Jan 2009 11:24:14 -0700 Subject: Switching Fedora to pae kernel by default? In-Reply-To: <4974B8E0.8050301@redhat.com> References: <497484E0.7080000@qumranet.com> <20090119160337.GB7270@redhat.com> <20090119162325.GA3822@nostromo.devel.redhat.com> <20090119164041.GB24251@bombadil.infradead.org> <4974B8E0.8050301@redhat.com> Message-ID: <20090119112414.e764f4d5.zaitcev@redhat.com> On Mon, 19 Jan 2009 19:31:12 +0200, Avi Kivity wrote: > Are Pentium Ms (really the memory that comes with them) actually capable > of running recent Fedoras? I'm talking desktop, not > I'm-using-my-laptop-as-a-firewall-just-because-I-can. If only it were laptops. I think they still sell systems like this: [zaitcev at mallorn ~]$ more /proc/cpuinfo processor : 0 vendor_id : CentaurHauls cpu family : 6 model : 7 model name : VIA Samuel 2 stepping : 3 cpu MHz : 800.065 cache size : 64 KB fdiv_bug : no hlt_bug : no f00f_bug : no coma_bug : no fpu : yes fpu_exception : yes cpuid level : 1 wp : yes flags : fpu de tsc msr cx8 mtrr pge mmx 3dnow bogomips : 1601.64 clflush size : 32 [zaitcev at mallorn ~]$ You point about non-default kernel is well taken though. I'm not against making PAE default as long as some king of alternative is provided. BTW, does anyone know if the Geode in OLPC XO has PAE? -- Pete From davej at redhat.com Mon Jan 19 18:34:13 2009 From: davej at redhat.com (Dave Jones) Date: Mon, 19 Jan 2009 13:34:13 -0500 Subject: Switching Fedora to pae kernel by default? In-Reply-To: <20090119112414.e764f4d5.zaitcev@redhat.com> References: <497484E0.7080000@qumranet.com> <20090119160337.GB7270@redhat.com> <20090119162325.GA3822@nostromo.devel.redhat.com> <20090119164041.GB24251@bombadil.infradead.org> <4974B8E0.8050301@redhat.com> <20090119112414.e764f4d5.zaitcev@redhat.com> Message-ID: <20090119183413.GA30365@redhat.com> On Mon, Jan 19, 2009 at 11:24:14AM -0700, Pete Zaitcev wrote: > On Mon, 19 Jan 2009 19:31:12 +0200, Avi Kivity wrote: > > > Are Pentium Ms (really the memory that comes with them) actually capable > > of running recent Fedoras? I'm talking desktop, not > > I'm-using-my-laptop-as-a-firewall-just-because-I-can. > > If only it were laptops. I think they still sell systems like this: > > [zaitcev at mallorn ~]$ more /proc/cpuinfo > processor : 0 > vendor_id : CentaurHauls > cpu family : 6 > model : 7 > model name : VIA Samuel 2 The samuel 2 stopped being made ~5 years ago. VIA have been PAE capable since the Nehemiah generation. Dave -- http://www.codemonkey.org.uk From kyle at infradead.org Mon Jan 19 18:38:39 2009 From: kyle at infradead.org (Kyle McMartin) Date: Mon, 19 Jan 2009 13:38:39 -0500 Subject: Switching Fedora to pae kernel by default? In-Reply-To: <20090119112414.e764f4d5.zaitcev@redhat.com> References: <497484E0.7080000@qumranet.com> <20090119160337.GB7270@redhat.com> <20090119162325.GA3822@nostromo.devel.redhat.com> <20090119164041.GB24251@bombadil.infradead.org> <4974B8E0.8050301@redhat.com> <20090119112414.e764f4d5.zaitcev@redhat.com> Message-ID: <20090119183839.GA25464@bombadil.infradead.org> On Mon, Jan 19, 2009 at 11:24:14AM -0700, Pete Zaitcev wrote: > BTW, does anyone know if the Geode in OLPC XO has PAE? > The PAE bit in %cr4 is listed as reserved in the geode databook the olpc site links to, so my guess is no. :\ regards, Kyle From nhorman at redhat.com Mon Jan 19 18:36:08 2009 From: nhorman at redhat.com (Neil Horman) Date: Mon, 19 Jan 2009 13:36:08 -0500 Subject: Switching Fedora to pae kernel by default? In-Reply-To: <4974B8E0.8050301@redhat.com> References: <497484E0.7080000@qumranet.com> <20090119160337.GB7270@redhat.com> <20090119162325.GA3822@nostromo.devel.redhat.com> <20090119164041.GB24251@bombadil.infradead.org> <4974B8E0.8050301@redhat.com> Message-ID: <20090119183608.GA6565@hmsendeavour.rdu.redhat.com> On Mon, Jan 19, 2009 at 07:31:12PM +0200, Avi Kivity wrote: > Kyle McMartin wrote: >> On Mon, Jan 19, 2009 at 11:23:26AM -0500, Bill Nottingham wrote: >> >>> Dave Jones (davej at redhat.com) said: >>>> On Mon, Jan 19, 2009 at 03:49:20PM +0200, Avi Kivity wrote: >>>> > This probably comes up once in a while, thought I'd raise it again. >>>> > > I'd like to suggest switching the default kernel to -PAE on >>>> machines > that support it, for the following reasons: >>>> > > - many machines have 4GB+ these days, even desktops >>>> > - NX is only available with -PAE, improves security >>>> > - kvm is significantly faster on AMD when PAE is selected (since >>>> we > don't support NPT on non-PAE) >>>> >>>> What's needed to set this by default is changes in anaconda. >>>> They have their own list at anaconda-list at redhat.com >>>> >> Unless we keep the non-PAE i586 kernel around as a fallback, we're not >> going to be able to boot on a whole raft of crappy i386 chips (original >> Pentium M most notably...) > > I'm not suggesting dropping non-PAE. Simply defaulting to PAE where > possible. > > Are Pentium Ms (really the memory that comes with them) actually capable > of running recent Fedoras? I'm talking desktop, not > I'm-using-my-laptop-as-a-firewall-just-because-I-can. > Absolutely, I've got a Thinkpad T42 here that does just fine on fedora 10. Unless of course, I try to load a PAE enabled kernel on it. I've not looked into it at all, but this thread got me thinking, is there any particular reason that we can't merge the pae and non-pae kernels using the same alternatives approach we used to merge smp & up? Neil /***************************************** *Neil Horman *919-754-4323 ****************************************/ From kyle at infradead.org Mon Jan 19 18:47:02 2009 From: kyle at infradead.org (Kyle McMartin) Date: Mon, 19 Jan 2009 13:47:02 -0500 Subject: Switching Fedora to pae kernel by default? In-Reply-To: <20090119183608.GA6565@hmsendeavour.rdu.redhat.com> References: <497484E0.7080000@qumranet.com> <20090119160337.GB7270@redhat.com> <20090119162325.GA3822@nostromo.devel.redhat.com> <20090119164041.GB24251@bombadil.infradead.org> <4974B8E0.8050301@redhat.com> <20090119183608.GA6565@hmsendeavour.rdu.redhat.com> Message-ID: <20090119184702.GA20921@bombadil.infradead.org> On Mon, Jan 19, 2009 at 01:36:08PM -0500, Neil Horman wrote: > Absolutely, I've got a Thinkpad T42 here that does just fine on fedora 10. > Unless of course, I try to load a PAE enabled kernel on it. > > I've not looked into it at all, but this thread got me thinking, is there any > particular reason that we can't merge the pae and non-pae kernels using the same > alternatives approach we used to merge smp & up? > I looked into this several years ago, it's actually fairly gnarly since depending on PAE we set up the swapper page tables differently, and other ugly differences. I should resurrect the patch set, though I think rationalizing it with the Xen merge might be more pain than it's worth... last time I looked at it there was a ridiculous amount of rejects. It was pretty close to booting (though I had to hack the bootloader to get a PAE enable bit so people without the bit could turn it off.) regards, Kyle From ivazqueznet at gmail.com Mon Jan 19 21:09:07 2009 From: ivazqueznet at gmail.com (Ignacio Vazquez-Abrams) Date: Mon, 19 Jan 2009 16:09:07 -0500 Subject: Switching Fedora to pae kernel by default? In-Reply-To: <20090119112414.e764f4d5.zaitcev@redhat.com> References: <497484E0.7080000@qumranet.com> <20090119160337.GB7270@redhat.com> <20090119162325.GA3822@nostromo.devel.redhat.com> <20090119164041.GB24251@bombadil.infradead.org> <4974B8E0.8050301@redhat.com> <20090119112414.e764f4d5.zaitcev@redhat.com> Message-ID: <1232399347.30871.38.camel@ignacio.lan> On Mon, 2009-01-19 at 11:24 -0700, Pete Zaitcev wrote: > BTW, does anyone know if the Geode in OLPC XO has PAE? This is off a C2: [olpc at xo-10-DD-46 ~]$ cat /proc/cpuinfo processor : 0 vendor_id : AuthenticAMD cpu family : 5 model : 10 model name : Geode(TM) Integrated Processor by AMD PCS stepping : 2 cpu MHz : 430.931 cache size : 128 KB fdiv_bug : no hlt_bug : no f00f_bug : no coma_bug : no fpu : yes fpu_exception : yes cpuid level : 1 wp : yes flags : fpu de pse tsc msr cx8 sep pge cmov clflush mmx mmxext 3dnowext 3dnow bogomips : 863.19 clflush size : 32 -- Ignacio Vazquez-Abrams PLEASE don't CC me; I'm already subscribed From clalance at redhat.com Tue Jan 20 07:05:44 2009 From: clalance at redhat.com (Chris Lalancette) Date: Tue, 20 Jan 2009 08:05:44 +0100 Subject: Switching Fedora to pae kernel by default? In-Reply-To: <20090119184702.GA20921@bombadil.infradead.org> References: <497484E0.7080000@qumranet.com> <20090119160337.GB7270@redhat.com> <20090119162325.GA3822@nostromo.devel.redhat.com> <20090119164041.GB24251@bombadil.infradead.org> <4974B8E0.8050301@redhat.com> <20090119183608.GA6565@hmsendeavour.rdu.redhat.com> <20090119184702.GA20921@bombadil.infradead.org> Message-ID: <497577C8.8040607@redhat.com> Kyle McMartin wrote: > On Mon, Jan 19, 2009 at 01:36:08PM -0500, Neil Horman wrote: >> Absolutely, I've got a Thinkpad T42 here that does just fine on fedora 10. >> Unless of course, I try to load a PAE enabled kernel on it. >> >> I've not looked into it at all, but this thread got me thinking, is there any >> particular reason that we can't merge the pae and non-pae kernels using the same >> alternatives approach we used to merge smp & up? >> > > I looked into this several years ago, it's actually fairly gnarly since > depending on PAE we set up the swapper page tables differently, and > other ugly differences. > > I should resurrect the patch set, though I think rationalizing it with the > Xen merge might be more pain than it's worth... last time I looked at it > there was a ridiculous amount of rejects. Well, it depends on if you are talking about the non-upstream Xen patch, or the current upstream pv_ops. The former is all but dead, so you don't have to worry about that, and the latter *should* (famous last words) mostly stay out of your way through pv_ops. Though I haven't gone in and implemented it myself, so it's easy for me to say :). I think choosing PAE at runtime would be the ideal situation, if we can get there. -- Chris Lalancette From avi at redhat.com Tue Jan 20 09:04:23 2009 From: avi at redhat.com (Avi Kivity) Date: Tue, 20 Jan 2009 11:04:23 +0200 Subject: Switching Fedora to pae kernel by default? In-Reply-To: <20090119173919.GB6090@redhat.com> References: <497484E0.7080000@qumranet.com> <20090119160337.GB7270@redhat.com> <20090119162325.GA3822@nostromo.devel.redhat.com> <20090119170527.GA6090@redhat.com> <4974B4F6.8010002@redhat.com> <20090119173919.GB6090@redhat.com> Message-ID: <49759397.6010403@redhat.com> Jeremy Katz wrote: > On Monday, January 19 2009, Avi Kivity said: > >> Jeremy Katz wrote: >> >>> That said, we currently do install the PAE kernel if you have 4 GB+ of >>> RAM[1]. Switching to it by default is problematic because then we're >>> back to using different kernels for different cases >>> >> You have that now, don't you? One case for <4GB and one for >=4GB. >> Worse, if you install more memory, the kernel doesn't see it. >> >> Downgrading your CPU to one which does not support PAE should be rare. >> > > Yes, but at least the "running a different kernel" case is currently the > relatively rare one. > It will become more and more frequent as machines get beefier. If we switch to PAE, it will be the non-PAE case which is rare. btw, what's wrong with running a different kernel? So long as the configs match, there shouldn't be a difference in reliability. >>> and it also makes >>> the 'what do you with the live image' case a lot more complex. >>> >> I'd just go with PAE here. >> > > Can't do so -- the live image is definitely used on a lot of hardware > that isn't PAE capable. Many/most Pentium M's didn't support it, the OLPC > doesn't[1]. And those are common hardware targets for the live image > So either put both kernels there, or the non-PAE kernel. >>> The _real_ fix here is to get PAE runtime much like was finally done >>> with SMP :-) >>> >> Patches, as they say, are welcome. >> > > Low-level x86 setup code isn't quite my forte... Hence I go for > goading others into doing it ;-) > I meant, "this requires a monumental amount of work". > >> But you could install both kernels >> and have the bootloaded choose (sticks wax balls into ears). >> > > Want to write code for syslinux and grub to do the auto-choosing? Not really. I don't see it as particularly difficult. With grub, you could use multiboot to add a module to select the correct kernel, maybe. I think Windows works this way, with the /PAE switch on the kernel command line causing a different kernel to be loaded. > Then > we also have to figure out a way to shoe-horn another 50 MB of stuff > into the already full live image Cut away the drivers for Infiniband and similarly useless hardware (for livecds, that is). Put them in a separate subpackage or use steam-powered rm -rf. -- error compiling committee.c: too many arguments to function From avi at redhat.com Tue Jan 20 09:06:17 2009 From: avi at redhat.com (Avi Kivity) Date: Tue, 20 Jan 2009 11:06:17 +0200 Subject: Switching Fedora to pae kernel by default? In-Reply-To: <1232387604.3942.17.camel@localhost.localdomain> References: <497484E0.7080000@qumranet.com> <20090119160337.GB7270@redhat.com> <20090119162325.GA3822@nostromo.devel.redhat.com> <20090119164041.GB24251@bombadil.infradead.org> <4974B8E0.8050301@redhat.com> <1232387604.3942.17.camel@localhost.localdomain> Message-ID: <49759409.9080200@redhat.com> Eric Paris wrote: > I've got a P3 (Coppermine) with 256M memory running F10. My significant > other took it with her to Antarctica (Well F9 has been to Antarctica but > it'll be F10 in Antarctica next month). You can only run one app at a > time and have to be patient, but it's perfectly usable (and noone cares > if this laptop is lost, stolen or destroyed [aside from her being pissed > she lost all her research data]). I wouldn't/couldn't to use it as a > daily machine, so while I'm in favor of -PAE default, F10 is "usable" on > such small machines. I don't care if old machines need some bit > twiddling to get to work, but we aren't dead yet :) > By F12 you'll be down to zero apps at the same time, and slow... We can keep the non-PAE kernel, but as non-default in recognition that technology has moved on. -- error compiling committee.c: too many arguments to function From konrad at tylerc.org Tue Jan 20 09:27:56 2009 From: konrad at tylerc.org (Conrad Meyer) Date: Tue, 20 Jan 2009 01:27:56 -0800 Subject: Switching Fedora to pae kernel by default? In-Reply-To: <49759409.9080200@redhat.com> References: <497484E0.7080000@qumranet.com> <1232387604.3942.17.camel@localhost.localdomain> <49759409.9080200@redhat.com> Message-ID: <200901200127.56879.konrad@tylerc.org> On Tuesday 20 January 2009 01:06:17 am Avi Kivity wrote: > Eric Paris wrote: > > I've got a P3 (Coppermine) with 256M memory running F10. My significant > > other took it with her to Antarctica (Well F9 has been to Antarctica but > > it'll be F10 in Antarctica next month). You can only run one app at a > > time and have to be patient, but it's perfectly usable (and noone cares > > if this laptop is lost, stolen or destroyed [aside from her being pissed > > she lost all her research data]). I wouldn't/couldn't to use it as a > > daily machine, so while I'm in favor of -PAE default, F10 is "usable" on > > such small machines. I don't care if old machines need some bit > > twiddling to get to work, but we aren't dead yet :) > > By F12 you'll be down to zero apps at the same time, and slow... > > We can keep the non-PAE kernel, but as non-default in recognition that > technology has moved on. I have a P1 with 128M of memory running F9 just fine, I just keep it at runlevel 3. It works great. -- Conrad Meyer From kyle at infradead.org Tue Jan 20 15:54:56 2009 From: kyle at infradead.org (Kyle McMartin) Date: Tue, 20 Jan 2009 10:54:56 -0500 Subject: Switching Fedora to pae kernel by default? In-Reply-To: <49759409.9080200@redhat.com> References: <497484E0.7080000@qumranet.com> <20090119160337.GB7270@redhat.com> <20090119162325.GA3822@nostromo.devel.redhat.com> <20090119164041.GB24251@bombadil.infradead.org> <4974B8E0.8050301@redhat.com> <1232387604.3942.17.camel@localhost.localdomain> <49759409.9080200@redhat.com> Message-ID: <20090120155456.GA17452@bombadil.infradead.org> On Tue, Jan 20, 2009 at 11:06:17AM +0200, Avi Kivity wrote: > Eric Paris wrote: >> I've got a P3 (Coppermine) with 256M memory running F10. My significant >> other took it with her to Antarctica (Well F9 has been to Antarctica but >> it'll be F10 in Antarctica next month). You can only run one app at a >> time and have to be patient, but it's perfectly usable (and noone cares >> if this laptop is lost, stolen or destroyed [aside from her being pissed >> she lost all her research data]). I wouldn't/couldn't to use it as a >> daily machine, so while I'm in favor of -PAE default, F10 is "usable" on >> such small machines. I don't care if old machines need some bit >> twiddling to get to work, but we aren't dead yet :) >> > > By F12 you'll be down to zero apps at the same time, and slow... > > We can keep the non-PAE kernel, but as non-default in recognition that > technology has moved on. > Look, I'm sorry if I'm just not thinking big picture enough here, but what exactly is the use case for a PAE kernel these days? The compat code in x86_64 should be more than good enough for the apps that require an i686 chroot. I just don't see the status quo as doing any real harm, as the only generations of CPU that benefit are really P4 (which aren't worth the electricity used to power them) or Core (One) Duo (which didn't exist for a particularly long time...) Neither of which actually supported more than 3GB of RAM on their northbridges except for the Xeon chipsets anyway. I have no idea what the installer and livecd do, but to me, it would seem to be a waste of space to carry two sets of installable kernels on the discs, when one would do. That said again, I'm suprised we aren't installing i586 kernels by default... Odd. I think the ideal solution here is to support x86_64 kernel, i686 userspace more actively. What, honestly, are the odds of someone with a bunch of P4 Xeons these days with 32GB of ram running Fedora? Are there really enough of them that it's worth caring? ;-) Of course, take what I say with a grain of salt. I don't particularly care at all, I'm just trying to play the pragmatist. Another question is what's the perf penalty of going to PAE on a 2GB of ram machine versus the vanilla HIGHMEM4G config? The only argument I really buy into is the NX one, honestly... What about a yum plugin that recommends a kernel that the user could override? I'll poke at it this afternoon (hey, I've always wanted to learn python...) cheers, Kyle From kraxel at redhat.com Tue Jan 20 09:56:44 2009 From: kraxel at redhat.com (Gerd Hoffmann) Date: Tue, 20 Jan 2009 10:56:44 +0100 Subject: Switching Fedora to pae kernel by default? In-Reply-To: <4974B8E0.8050301@redhat.com> References: <497484E0.7080000@qumranet.com> <20090119160337.GB7270@redhat.com> <20090119162325.GA3822@nostromo.devel.redhat.com> <20090119164041.GB24251@bombadil.infradead.org> <4974B8E0.8050301@redhat.com> Message-ID: <49759FDC.40503@redhat.com> Avi Kivity wrote: > Kyle McMartin wrote: >> Unless we keep the non-PAE i586 kernel around as a fallback, we're not >> going to be able to boot on a whole raft of crappy i386 chips (original >> Pentium M most notably...) > > I'm not suggesting dropping non-PAE. Simply defaulting to PAE where > possible. > > Are Pentium Ms (really the memory that comes with them) actually capable > of running recent Fedoras? Well, we can switch the default for F11, then watch the smolt statistics to figure ;) cheers, Gerd From avi at redhat.com Tue Jan 20 17:28:10 2009 From: avi at redhat.com (Avi Kivity) Date: Tue, 20 Jan 2009 19:28:10 +0200 Subject: Switching Fedora to pae kernel by default? In-Reply-To: <20090120155456.GA17452@bombadil.infradead.org> References: <497484E0.7080000@qumranet.com> <20090119160337.GB7270@redhat.com> <20090119162325.GA3822@nostromo.devel.redhat.com> <20090119164041.GB24251@bombadil.infradead.org> <4974B8E0.8050301@redhat.com> <1232387604.3942.17.camel@localhost.localdomain> <49759409.9080200@redhat.com> <20090120155456.GA17452@bombadil.infradead.org> Message-ID: <497609AA.7070009@redhat.com> Kyle McMartin wrote: > Look, I'm sorry if I'm just not thinking big picture enough here, but > what exactly is the use case for a PAE kernel these days? The compat > code in x86_64 should be more than good enough for the apps that require > an i686 chroot. > It's certainly very good. I converted my i386 install to an x86_64 one, and the intermediate step of running the i386 userspace on x86_64 kernel worked well. > I just don't see the status quo as doing any real harm, as the only > generations of CPU that benefit are really P4 (which aren't worth the > electricity used to power them) or Core (One) Duo (which didn't exist > for a particularly long time...) Neither of which actually supported > more than 3GB of RAM on their northbridges except for the Xeon chipsets > anyway. > > I have no idea what the installer and livecd do, but to me, it would > seem to be a waste of space to carry two sets of installable kernels on > the discs, when one would do. That said again, I'm suprised we aren't > installing i586 kernels by default... Odd. > > I think the ideal solution here is to support x86_64 kernel, i686 > userspace more actively. > I'm all in favor of pushing x86_64. But I think currently most installs are i386. > What, honestly, are the odds of someone with a bunch of P4 Xeons these > days with 32GB of ram running Fedora? Are there really enough of them > that it's worth caring? ;-) > > Of course, take what I say with a grain of salt. I don't particularly > care at all, I'm just trying to play the pragmatist. > > Another question is what's the perf penalty of going to PAE on a > 2GB of ram machine versus the vanilla HIGHMEM4G config? > I'm guessing, pretty low. > The only argument I really buy into is the NX one, honestly... > > What about a yum plugin that recommends a kernel that the user could > override? I'll poke at it this afternoon (hey, I've always wanted to > learn python...) > Users won't be running yum. They're running that applet thing. -- error compiling committee.c: too many arguments to function From kyle at infradead.org Tue Jan 20 17:44:24 2009 From: kyle at infradead.org (Kyle McMartin) Date: Tue, 20 Jan 2009 12:44:24 -0500 Subject: Switching Fedora to pae kernel by default? In-Reply-To: <497609AA.7070009@redhat.com> References: <497484E0.7080000@qumranet.com> <20090119160337.GB7270@redhat.com> <20090119162325.GA3822@nostromo.devel.redhat.com> <20090119164041.GB24251@bombadil.infradead.org> <4974B8E0.8050301@redhat.com> <1232387604.3942.17.camel@localhost.localdomain> <49759409.9080200@redhat.com> <20090120155456.GA17452@bombadil.infradead.org> <497609AA.7070009@redhat.com> Message-ID: <20090120174424.GC17452@bombadil.infradead.org> On Tue, Jan 20, 2009 at 07:28:10PM +0200, Avi Kivity wrote: > Users won't be running yum. They're running that applet thing. > Which just shells out to yum... ;-) From avi at redhat.com Tue Jan 20 17:48:51 2009 From: avi at redhat.com (Avi Kivity) Date: Tue, 20 Jan 2009 19:48:51 +0200 Subject: Switching Fedora to pae kernel by default? In-Reply-To: <20090120174424.GC17452@bombadil.infradead.org> References: <497484E0.7080000@qumranet.com> <20090119160337.GB7270@redhat.com> <20090119162325.GA3822@nostromo.devel.redhat.com> <20090119164041.GB24251@bombadil.infradead.org> <4974B8E0.8050301@redhat.com> <1232387604.3942.17.camel@localhost.localdomain> <49759409.9080200@redhat.com> <20090120155456.GA17452@bombadil.infradead.org> <497609AA.7070009@redhat.com> <20090120174424.GC17452@bombadil.infradead.org> Message-ID: <49760E83.9000103@redhat.com> Kyle McMartin wrote: > On Tue, Jan 20, 2009 at 07:28:10PM +0200, Avi Kivity wrote: > >> Users won't be running yum. They're running that applet thing. >> >> > > Which just shells out to yum... ;-) > Great, but any 'suggestions' need to find their way to the user. I'd prefer to do the right thing in the first place rather than offer suggestions about the kernel. What's a kernel anyway? -- error compiling committee.c: too many arguments to function From snecklifter at gmail.com Wed Jan 21 09:15:24 2009 From: snecklifter at gmail.com (Christopher Brown) Date: Wed, 21 Jan 2009 09:15:24 +0000 Subject: Switching Fedora to pae kernel by default? In-Reply-To: <20090120155456.GA17452@bombadil.infradead.org> References: <497484E0.7080000@qumranet.com> <20090119160337.GB7270@redhat.com> <20090119162325.GA3822@nostromo.devel.redhat.com> <20090119164041.GB24251@bombadil.infradead.org> <4974B8E0.8050301@redhat.com> <1232387604.3942.17.camel@localhost.localdomain> <49759409.9080200@redhat.com> <20090120155456.GA17452@bombadil.infradead.org> Message-ID: <364d303b0901210115u6fa246d2y4e6fd59f8d35cece@mail.gmail.com> 2009/1/20 Kyle McMartin : > On Tue, Jan 20, 2009 at 11:06:17AM +0200, Avi Kivity wrote: >> Eric Paris wrote: >>> I've got a P3 (Coppermine) with 256M memory running F10. My significant >>> other took it with her to Antarctica (Well F9 has been to Antarctica but >>> it'll be F10 in Antarctica next month). You can only run one app at a >>> time and have to be patient, but it's perfectly usable (and noone cares >>> if this laptop is lost, stolen or destroyed [aside from her being pissed >>> she lost all her research data]). I wouldn't/couldn't to use it as a >>> daily machine, so while I'm in favor of -PAE default, F10 is "usable" on >>> such small machines. I don't care if old machines need some bit >>> twiddling to get to work, but we aren't dead yet :) >>> >> >> By F12 you'll be down to zero apps at the same time, and slow... >> >> We can keep the non-PAE kernel, but as non-default in recognition that >> technology has moved on. >> > > Look, I'm sorry if I'm just not thinking big picture enough here, but > what exactly is the use case for a PAE kernel these days? The compat > code in x86_64 should be more than good enough for the apps that require > an i686 chroot. > > I just don't see the status quo as doing any real harm, as the only > generations of CPU that benefit are really P4 (which aren't worth the > electricity used to power them) or Core (One) Duo (which didn't exist > for a particularly long time...) Neither of which actually supported > more than 3GB of RAM on their northbridges except for the Xeon chipsets > anyway. > > I have no idea what the installer and livecd do, but to me, it would > seem to be a waste of space to carry two sets of installable kernels on > the discs, when one would do. That said again, I'm suprised we aren't > installing i586 kernels by default... Odd. > > I think the ideal solution here is to support x86_64 kernel, i686 > userspace more actively. > > What, honestly, are the odds of someone with a bunch of P4 Xeons these > days with 32GB of ram running Fedora? Are there really enough of them > that it's worth caring? ;-) > > Of course, take what I say with a grain of salt. I don't particularly > care at all, I'm just trying to play the pragmatist. > > Another question is what's the perf penalty of going to PAE on a > 2GB of ram machine versus the vanilla HIGHMEM4G config? > > The only argument I really buy into is the NX one, honestly... > > What about a yum plugin that recommends a kernel that the user could > override? I'll poke at it this afternoon (hey, I've always wanted to > learn python...) May I point out that those that care enough to want PAE usually know how to go about getting it enabled whereas those that have install failure because they're running non-PAE hardware probably wont know how to go about getting it disabled. The fall-out from this going onto the livecd makes me shudder. The original argument that many machines have 4GB of memory is simply false. Manufacturers aren't shipping anything more than 2GB on desktops at most unless you have oodles of money to throw at a Alienware box or something. Sure, servers come with more but Fedora is not really a reality for a long term server O.S. -- Christopher Brown From avi at redhat.com Wed Jan 21 09:41:04 2009 From: avi at redhat.com (Avi Kivity) Date: Wed, 21 Jan 2009 11:41:04 +0200 Subject: Switching Fedora to pae kernel by default? In-Reply-To: <364d303b0901210115u6fa246d2y4e6fd59f8d35cece@mail.gmail.com> References: <497484E0.7080000@qumranet.com> <20090119160337.GB7270@redhat.com> <20090119162325.GA3822@nostromo.devel.redhat.com> <20090119164041.GB24251@bombadil.infradead.org> <4974B8E0.8050301@redhat.com> <1232387604.3942.17.camel@localhost.localdomain> <49759409.9080200@redhat.com> <20090120155456.GA17452@bombadil.infradead.org> <364d303b0901210115u6fa246d2y4e6fd59f8d35cece@mail.gmail.com> Message-ID: <4976EDB0.7050407@redhat.com> Christopher Brown wrote: > May I point out that those that care enough to want PAE usually know > how to go about getting it enabled whereas those that have install > failure because they're running non-PAE hardware probably wont know > how to go about getting it disabled. > You mean, ordinary users don't care about security? Because that's one of the advantages that PAE brings. You're right, they don't care, we have to care for them. > The fall-out from this going onto the livecd makes me shudder. > You're pushing out a development problem to the users. > The original argument that many machines have 4GB of memory is simply > false. My ~3yo home box has 4GB. I'm not an ordinary user (or it would be a computer, not a "box"), but I don't think you can claim 4GB is rare. > Manufacturers aren't shipping anything more than 2GB on > desktops at most unless you have oodles of money to throw at a > Alienware box or something. Sure, servers come with more but Fedora is > not really a reality for a long term server O.S Servers should use x86_64 anyway. But I strongly disagree about penalizing the future to cater for the past. -- error compiling committee.c: too many arguments to function From jwboyer at gmail.com Wed Jan 21 13:16:15 2009 From: jwboyer at gmail.com (Josh Boyer) Date: Wed, 21 Jan 2009 08:16:15 -0500 Subject: Switching Fedora to pae kernel by default? In-Reply-To: <364d303b0901210115u6fa246d2y4e6fd59f8d35cece@mail.gmail.com> References: <497484E0.7080000@qumranet.com> <20090119160337.GB7270@redhat.com> <20090119162325.GA3822@nostromo.devel.redhat.com> <20090119164041.GB24251@bombadil.infradead.org> <4974B8E0.8050301@redhat.com> <1232387604.3942.17.camel@localhost.localdomain> <49759409.9080200@redhat.com> <20090120155456.GA17452@bombadil.infradead.org> <364d303b0901210115u6fa246d2y4e6fd59f8d35cece@mail.gmail.com> Message-ID: <20090121131615.GA28503@yoda.jdub.homelinux.org> On Wed, Jan 21, 2009 at 09:15:24AM +0000, Christopher Brown wrote: >The original argument that many machines have 4GB of memory is simply >false. Manufacturers aren't shipping anything more than 2GB on >desktops at most unless you have oodles of money to throw at a >Alienware box or something. Sure, servers come with more but Fedora is >not really a reality for a long term server O.S. Actually, it works fine. I have a server that has only ever run Fedora. josh From jwboyer at gmail.com Wed Jan 21 13:17:17 2009 From: jwboyer at gmail.com (Josh Boyer) Date: Wed, 21 Jan 2009 08:17:17 -0500 Subject: Switching Fedora to pae kernel by default? In-Reply-To: <4976EDB0.7050407@redhat.com> References: <497484E0.7080000@qumranet.com> <20090119160337.GB7270@redhat.com> <20090119162325.GA3822@nostromo.devel.redhat.com> <20090119164041.GB24251@bombadil.infradead.org> <4974B8E0.8050301@redhat.com> <1232387604.3942.17.camel@localhost.localdomain> <49759409.9080200@redhat.com> <20090120155456.GA17452@bombadil.infradead.org> <364d303b0901210115u6fa246d2y4e6fd59f8d35cece@mail.gmail.com> <4976EDB0.7050407@redhat.com> Message-ID: <20090121131717.GB28503@yoda.jdub.homelinux.org> On Wed, Jan 21, 2009 at 11:41:04AM +0200, Avi Kivity wrote: > Servers should use x86_64 anyway. But I strongly disagree about No they shouldn't. They should use PowerPC. Then this whole stupid argument wouldn't even matter. /me stops antagonizing people now. josh From kyle at infradead.org Wed Jan 21 14:27:20 2009 From: kyle at infradead.org (Kyle McMartin) Date: Wed, 21 Jan 2009 09:27:20 -0500 Subject: Switching Fedora to pae kernel by default? In-Reply-To: <364d303b0901210115u6fa246d2y4e6fd59f8d35cece@mail.gmail.com> References: <497484E0.7080000@qumranet.com> <20090119160337.GB7270@redhat.com> <20090119162325.GA3822@nostromo.devel.redhat.com> <20090119164041.GB24251@bombadil.infradead.org> <4974B8E0.8050301@redhat.com> <1232387604.3942.17.camel@localhost.localdomain> <49759409.9080200@redhat.com> <20090120155456.GA17452@bombadil.infradead.org> <364d303b0901210115u6fa246d2y4e6fd59f8d35cece@mail.gmail.com> Message-ID: <20090121142720.GA27998@bombadil.infradead.org> On Wed, Jan 21, 2009 at 09:15:24AM +0000, Christopher Brown wrote: > The fall-out from this going onto the livecd makes me shudder. > Jesse explained this to me, To clarify: the anaconda installer is i586, and all 3 kernel flavours are shipped on the disc. I would imagine the livecd is i586 and will remain that way. So it's really a moot point, and the only difference is installing PAE by default on machines which support it versus the i686 kernel. Since we're not giving anything up on the disc, then there's no big deal. The NX argument is alright, but we still ship execshield anyway, so it's (somewhat) mitigated. Anyway, cheers. Kyle From katzj at redhat.com Wed Jan 21 15:52:14 2009 From: katzj at redhat.com (Jeremy Katz) Date: Wed, 21 Jan 2009 10:52:14 -0500 Subject: Switching Fedora to pae kernel by default? In-Reply-To: <20090121142720.GA27998@bombadil.infradead.org> References: <497484E0.7080000@qumranet.com> <20090119160337.GB7270@redhat.com> <20090119162325.GA3822@nostromo.devel.redhat.com> <20090119164041.GB24251@bombadil.infradead.org> <4974B8E0.8050301@redhat.com> <1232387604.3942.17.camel@localhost.localdomain> <49759409.9080200@redhat.com> <20090120155456.GA17452@bombadil.infradead.org> <364d303b0901210115u6fa246d2y4e6fd59f8d35cece@mail.gmail.com> <20090121142720.GA27998@bombadil.infradead.org> Message-ID: <20090121155214.GA14011@redhat.com> On Wednesday, January 21 2009, Kyle McMartin said: > On Wed, Jan 21, 2009 at 09:15:24AM +0000, Christopher Brown wrote: > > The fall-out from this going onto the livecd makes me shudder. > > Jesse explained this to me, > > To clarify: the anaconda installer is i586, and all 3 kernel flavours > are shipped on the disc. I would imagine the livecd is i586 and will > remain that way. No, the livecd is i686. Because due to other things about the livecd, you have to have more ram than most i586s would support. The number of i586 users we have is minimal. The number of non-pae i686 users we have is much more significant. Jeremy From snecklifter at gmail.com Wed Jan 21 18:37:57 2009 From: snecklifter at gmail.com (Christopher Brown) Date: Wed, 21 Jan 2009 18:37:57 +0000 Subject: Switching Fedora to pae kernel by default? In-Reply-To: <4976EDB0.7050407@redhat.com> References: <497484E0.7080000@qumranet.com> <20090119160337.GB7270@redhat.com> <20090119162325.GA3822@nostromo.devel.redhat.com> <20090119164041.GB24251@bombadil.infradead.org> <4974B8E0.8050301@redhat.com> <1232387604.3942.17.camel@localhost.localdomain> <49759409.9080200@redhat.com> <20090120155456.GA17452@bombadil.infradead.org> <364d303b0901210115u6fa246d2y4e6fd59f8d35cece@mail.gmail.com> <4976EDB0.7050407@redhat.com> Message-ID: <364d303b0901211037w57609af3n3832aff887041f3a@mail.gmail.com> 2009/1/21 Avi Kivity : > Christopher Brown wrote: >> >> May I point out that those that care enough to want PAE usually know >> how to go about getting it enabled whereas those that have install >> failure because they're running non-PAE hardware probably wont know >> how to go about getting it disabled. >> > > You mean, ordinary users don't care about security? Because that's one of > the advantages that PAE brings. No, I meant ordinary users don't care about anything over 2GB. > You're right, they don't care, we have to care for them. They do care about security but want it to be easy. Or simply don't want to have to care. >> The fall-out from this going onto the livecd makes me shudder. >> > > You're pushing out a development problem to the users. Um, no. I'm simply against cutting out a tranche of people because of the needs of the few. We have x86_64 Live anyway. >> The original argument that many machines have 4GB of memory is simply >> false. > > My ~3yo home box has 4GB. I'm not an ordinary user (or it would be a > computer, not a "box"), but I don't think you can claim 4GB is rare. Rare for this use case, yes. >> Manufacturers aren't shipping anything more than 2GB on >> desktops at most unless you have oodles of money to throw at a >> Alienware box or something. Sure, servers come with more but Fedora is >> not really a reality for a long term server O.S > > Servers should use x86_64 anyway. But I strongly disagree about penalizing > the future to cater for the past. I'm not sure you're penalizing the past, I think this is penalizing the present. -- Christopher Brown From Ted.Nzuonkwelle at Colorado.EDU Wed Jan 21 23:22:14 2009 From: Ted.Nzuonkwelle at Colorado.EDU (Ted Sume Nzuonkwelle) Date: Wed, 21 Jan 2009 16:22:14 -0700 (MST) Subject: F10 EDAC Errors on intel based server Message-ID: <20090121162214.AGO46832@robin.int.colorado.edu> Hi, Just did a new install of Fedora 10 on an 8 core intel server (2 quad cores) and i got the following messages during first boot. They are continuosly being printed to the terminal just about every second. I originally had an install of Fedora 9 on this server and did not see any such errors. kernel version 2.6.27.5-117.fc10.x86_64 Below are the errors EDAC i5000 MCO: NON-FATAL ERRORS Found!!! 1st NON-FATAL Err Reg= 0x40000 EDAC i5000: SPD Protocol Error, bits=0x40000 Any thoughts why this is happening? - Ted From jkeating at redhat.com Thu Jan 22 00:11:54 2009 From: jkeating at redhat.com (Jesse Keating) Date: Wed, 21 Jan 2009 16:11:54 -0800 Subject: Switching Fedora to pae kernel by default? In-Reply-To: <20090121142720.GA27998@bombadil.infradead.org> References: <497484E0.7080000@qumranet.com> <20090119160337.GB7270@redhat.com> <20090119162325.GA3822@nostromo.devel.redhat.com> <20090119164041.GB24251@bombadil.infradead.org> <4974B8E0.8050301@redhat.com> <1232387604.3942.17.camel@localhost.localdomain> <49759409.9080200@redhat.com> <20090120155456.GA17452@bombadil.infradead.org> <364d303b0901210115u6fa246d2y4e6fd59f8d35cece@mail.gmail.com> <20090121142720.GA27998@bombadil.infradead.org> Message-ID: <1232583114.3539.260.camel@localhost.localdomain> On Wed, 2009-01-21 at 09:27 -0500, Kyle McMartin wrote: > On Wed, Jan 21, 2009 at 09:15:24AM +0000, Christopher Brown wrote: > > The fall-out from this going onto the livecd makes me shudder. > > > > Jesse explained this to me, > > To clarify: the anaconda installer is i586, and all 3 kernel flavours > are shipped on the disc. I would imagine the livecd is i586 and will > remain that way. Sorry to disappoint. The live image is a different beast than the installer. The live image is explicitly i686. It will not run anywhere else as there is only one kernel image there to boot. Since live install is essentially a dd of the image to your new filesystem, there is only one kernel there as well. So without some more context, I can't tell you what kind of doom the live image is in for... (: > > So it's really a moot point, and the only difference is installing > PAE by default on machines which support it versus the i686 kernel. > > Since we're not giving anything up on the disc, then there's no big > deal. > > The NX argument is alright, but we still ship execshield anyway, so > it's (somewhat) mitigated. > > Anyway, cheers. > Kyle -- Jesse Keating Fedora -- Freedom? is a feature! identi.ca: http://identi.ca/jkeating From kedars at marvell.com Thu Jan 22 05:12:02 2009 From: kedars at marvell.com (Kedar Sovani) Date: Thu, 22 Jan 2009 10:42:02 +0530 Subject: [PATCH] kernel: only build kernel-headers on ARM Message-ID: <1232601122.2814.79.camel@pe-lt019> Since kernels for different ARM CPUs differ wildly, and since embedded folks tend to provide their own kernels, this patch makes the Fedora kernel package only build kernel-headers when built for ARM. Please consider for inclusion. Signed-off-by: Lennert Buytenhek Signed-off-by: Kedar Sovani --- Makefile.config | 5 ++++- config-arm | 15 +++++++++++++++ kernel.spec | 16 +++++++++++++--- 3 files changed, 32 insertions(+), 4 deletions(-) create mode 100644 config-arm diff --git a/Makefile.config b/Makefile.config index 09adc2e..bc1420a 100644 --- a/Makefile.config +++ b/Makefile.config @@ -9,7 +9,7 @@ CONFIGFILES = \ $(CFG)-i686.config $(CFG)-i686-PAE.config \ $(CFG)-i686-debug.config $(CFG)-i686-PAEdebug.config \ $(CFG)-x86_64.config $(CFG)-x86_64-debug.config \ - $(CFG)-s390x.config \ + $(CFG)-s390x.config $(CFG)-arm.config \ $(CFG)-ppc.config $(CFG)-ppc-smp.config \ $(CFG)-sparc64.config $(CFG)-sparc64-smp.config \ $(CFG)-ppc64.config $(CFG)-ppc64-kdump.config $(CFG)-ppc64-debug.config \ @@ -102,6 +102,9 @@ kernel-$(VERSION)-ppc64-debug.config: config-powerpc64 temp-powerpc-debug-generi kernel-$(VERSION)-s390x.config: config-s390x temp-s390-generic perl merge.pl $^ s390 > $@ +kernel-$(VERSION)-arm.config: config-arm temp-generic + perl merge.pl $^ arm > $@ + kernel-$(VERSION)-ppc.config: /dev/null temp-powerpc32-generic perl merge.pl $^ powerpc > $@ diff --git a/config-arm b/config-arm new file mode 100644 index 0000000..692f205 --- /dev/null +++ b/config-arm @@ -0,0 +1,15 @@ +CONFIG_ARM=y +CONFIG_SYS_SUPPORTS_APM_EMULATION=y +# CONFIG_SMP is not set + +CONFIG_CC_OPTIMIZE_FOR_SIZE=y + +CONFIG_ARCH_VERSATILE=y + +CONFIG_ARM_THUMB=y + +CONFIG_AEABI=y +CONFIG_OABI_COMPAT=y + +CONFIG_CMDLINE="console=ttyAM0,115200 root=/dev/sda1 rootdelay=20" + diff --git a/kernel.spec b/kernel.spec index 04fc5ee..2ce025d 100644 --- a/kernel.spec +++ b/kernel.spec @@ -347,6 +347,14 @@ Summary: The Linux kernel %define kernel_image vmlinux %endif +%ifarch %{arm} +%define all_arch_configs kernel-%{version}-arm*.config +%define image_install_path boot +%define hdrarch arm +%define make_target vmlinux +%define kernel_image vmlinux +%endif + %if %{nopatches} # XXX temporary until last vdso patches are upstream %define vdso_arches ppc ppc64 @@ -367,8 +375,8 @@ Summary: The Linux kernel # Which is a BadThing(tm). # We don't build a kernel on i386; we only do kernel-headers there, -# and we no longer build for 31bit S390. Same for 32bit sparc. -%define nobuildarches i386 s390 sparc +# and we no longer build for 31bit S390. Same for 32bit sparc and arm. +%define nobuildarches i386 s390 sparc %{arm} %ifarch %nobuildarches %define with_up 0 @@ -463,7 +471,7 @@ Version: %{rpmversion} Release: %{pkg_release} # DO NOT CHANGE THE 'ExclusiveArch' LINE TO TEMPORARILY EXCLUDE AN ARCHITECTURE BUILD. # SET %%nobuildarches (ABOVE) INSTEAD -ExclusiveArch: noarch %{all_x86} x86_64 ppc ppc64 ia64 sparc sparc64 s390x alpha alphaev56 +ExclusiveArch: noarch %{all_x86} x86_64 ppc ppc64 ia64 sparc sparc64 s390x alpha alphaev56 %{arm} ExclusiveOS: Linux %kernel_reqprovconf @@ -562,6 +570,8 @@ Patch00: patch-2.6.%{base_sublevel}-git%{gitrev}.bz2 %endif %endif +Source100: config-arm + %if %{using_upstream_branch} ### BRANCH PATCH ### %endif -- 1.5.3.3 From oliver at linux-kernel.at Thu Jan 22 07:28:11 2009 From: oliver at linux-kernel.at (Oliver Falk) Date: Thu, 22 Jan 2009 08:28:11 +0100 Subject: F10 EDAC Errors on intel based server In-Reply-To: <20090121162214.AGO46832@robin.int.colorado.edu> References: <20090121162214.AGO46832@robin.int.colorado.edu> Message-ID: <4978200B.3080909@linux-kernel.at> Ted Sume Nzuonkwelle wrote: > Hi, > > Just did a new install of Fedora 10 on an 8 core intel server (2 quad cores) and i got the following messages during first boot. They are continuosly being printed to the terminal just about every second. > > I originally had an install of Fedora 9 on this server and did not see any such errors. > > kernel version 2.6.27.5-117.fc10.x86_64 > > Below are the errors > > EDAC i5000 MCO: NON-FATAL ERRORS Found!!! 1st NON-FATAL Err Reg= 0x40000 > EDAC i5000: SPD Protocol Error, bits=0x40000 > > Any thoughts why this is happening? Well.... Google is your friend, isn't it? http://faq.aslab.com/index.php?sid=8574&lang=en&action=artikel&cat=93&id=154&artlang=en -of From oliver at linux-kernel.at Thu Jan 22 07:28:11 2009 From: oliver at linux-kernel.at (Oliver Falk) Date: Thu, 22 Jan 2009 08:28:11 +0100 Subject: F10 EDAC Errors on intel based server In-Reply-To: <20090121162214.AGO46832@robin.int.colorado.edu> References: <20090121162214.AGO46832@robin.int.colorado.edu> Message-ID: <4978200B.3080909@linux-kernel.at> Ted Sume Nzuonkwelle wrote: > Hi, > > Just did a new install of Fedora 10 on an 8 core intel server (2 quad cores) and i got the following messages during first boot. They are continuosly being printed to the terminal just about every second. > > I originally had an install of Fedora 9 on this server and did not see any such errors. > > kernel version 2.6.27.5-117.fc10.x86_64 > > Below are the errors > > EDAC i5000 MCO: NON-FATAL ERRORS Found!!! 1st NON-FATAL Err Reg= 0x40000 > EDAC i5000: SPD Protocol Error, bits=0x40000 > > Any thoughts why this is happening? Well.... Google is your friend, isn't it? http://faq.aslab.com/index.php?sid=8574&lang=en&action=artikel&cat=93&id=154&artlang=en -of From Ted.Nzuonkwelle at Colorado.EDU Thu Jan 22 17:02:22 2009 From: Ted.Nzuonkwelle at Colorado.EDU (Ted Sume Nzuonkwelle) Date: Thu, 22 Jan 2009 10:02:22 -0700 Subject: F10 EDAC Errors on intel based server In-Reply-To: <4978200B.3080909@linux-kernel.at> References: <20090121162214.AGO46832@robin.int.colorado.edu> <4978200B.3080909@linux-kernel.at> Message-ID: <1232643742.6253.3.camel@localhost.localdomain> On Thu, 2009-01-22 at 08:28 +0100, Oliver Falk wrote: > Ted Sume Nzuonkwelle wrote: > > Hi, > > > > Just did a new install of Fedora 10 on an 8 core intel server (2 quad cores) and i got the following messages during first boot. They are continuosly being printed to the terminal just about every second. > > > > I originally had an install of Fedora 9 on this server and did not see any such errors. > > > > kernel version 2.6.27.5-117.fc10.x86_64 > > > > Below are the errors > > > > EDAC i5000 MCO: NON-FATAL ERRORS Found!!! 1st NON-FATAL Err Reg= 0x40000 > > EDAC i5000: SPD Protocol Error, bits=0x40000 > > > > Any thoughts why this is happening? > > Well.... Google is your friend, isn't it? > > http://faq.aslab.com/index.php?sid=8574?=en&action=artikel&cat=93&id=154&artlang=en > > -of Thanks much. Some people are just much much better at using GOOG that others. - Ted From kyle at infradead.org Thu Jan 22 18:01:54 2009 From: kyle at infradead.org (Kyle McMartin) Date: Thu, 22 Jan 2009 13:01:54 -0500 Subject: [PATCH] kernel: only build kernel-headers on ARM In-Reply-To: <1232601122.2814.79.camel@pe-lt019> References: <1232601122.2814.79.camel@pe-lt019> Message-ID: <20090122180154.GB3184@bombadil.infradead.org> On Thu, Jan 22, 2009 at 10:42:02AM +0530, Kedar Sovani wrote: > Since kernels for different ARM CPUs differ wildly, and since > embedded folks tend to provide their own kernels, this patch makes > the Fedora kernel package only build kernel-headers when built for > ARM. > > Signed-off-by: Lennert Buytenhek > Signed-off-by: Kedar Sovani Groovy! Just one comment that jwb brought up: > +%ifarch %{arm} > +%define nobuildarches i386 s390 sparc %{arm} > I assume the %arm is defined by rpm to expand to the arm5xxxx bits? Is this in upstream rpm now? regards, Kyle From kedars at marvell.com Fri Jan 23 04:36:41 2009 From: kedars at marvell.com (Kedar Sovani) Date: Fri, 23 Jan 2009 10:06:41 +0530 Subject: [PATCH] kernel: only build kernel-headers on ARM In-Reply-To: <20090122180154.GB3184@bombadil.infradead.org> References: <1232601122.2814.79.camel@pe-lt019> <20090122180154.GB3184@bombadil.infradead.org> Message-ID: <1232685401.13606.4.camel@pe-dt032> On Thu, 2009-01-22 at 13:01 -0500, Kyle McMartin wrote: > On Thu, Jan 22, 2009 at 10:42:02AM +0530, Kedar Sovani wrote: > > Since kernels for different ARM CPUs differ wildly, and since > > embedded folks tend to provide their own kernels, this patch makes > > the Fedora kernel package only build kernel-headers when built for > > ARM. > > > > Signed-off-by: Lennert Buytenhek > > Signed-off-by: Kedar Sovani > > Groovy! Just one comment that jwb brought up: > > > +%ifarch %{arm} > > +%define nobuildarches i386 s390 sparc %{arm} > > > > I assume the %arm is defined by rpm to expand to the arm5xxxx > bits? Is this in upstream rpm now? > Yes, it is available. # grep -nrs \%arm /usr/lib/rpm/* macros:1195:%arm armv3l armv4b armv4l armv4tl armv5tel armv5tejl armv6l > regards, Kyle Thanks, Kedar. From gilboad at gmail.com Sat Jan 24 17:46:08 2009 From: gilboad at gmail.com (Gilboa Davara) Date: Sat, 24 Jan 2009 19:46:08 +0200 Subject: Semi-OT: Profiling 10GbE devices... Help? Message-ID: <1232819168.30663.281.camel@gilboa-home-dev.localdomain> Hello all, I'm almost certain that is the not the right place to ask this question, but if RedHat/Fedora's kernel engineers can't help me, I'm truly screwed. I'm are using two Intel 10GbE (ixgbe) cards to passively monitor 10GbE lines (Under RHEL 5.2) either using the in-kernel dev_add_pack interface (built-in ixgbe driver) or using a slightly modified ixgbe driver. (built around Intel's latest ixgbe driver) However, I'm experiencing odd performance issues - namely, once I configure the driver to use MSI-X w/ multi-queue [MQ] (forcing pci=msi) and assign each IRQ to one CPU core (irq cpu affinity), my software requires -10x- more CPU cycles (measured using rdtsc; compared to multiple GbE links and/or w/ MSI-X/MQ disabled) to process each packet, causing massive missed IRQs (rx_missed_errors) induced packet loss. Looking at mpstat I can see the each CPU core is handling a fairly low number of interrupts (200-1000) while spending most of its time in softIRQ. (>90%, most likely within my own code) I decided to check newer kernels so I've installed F10 (24C Xeon-MP Intel S7000FC4U) and F9 (16C Opteron DL585G5, *) on two machines, but even with 2.6.27 kernels and I'm experiencing the same performance issues. Given the fact that the same code is used to process packets - no matter what type of links are being used, my first instinct was to look at the CPU cores themselves. (E.g. L1 & L2 dcache miss rates; TLB flushes; etc). I tried using oprofile, but I failed to make it work. On one machine (Xeon-MP, F10), oprofile failed to identify the Dunnington CPU (switching to timer mode) and on the other (Barcelona 8354, F9), even though it was configured to report dcache statistics [1,2] opreport returns empty reports. In-order to verify that oprofile indeed works on Opteron machine, I reconfigured oprofile to report CPU usage [3], but even than, oprofile either returns empty results to hard-locks the machine. So: A. Anyone else seeing the same odd behavior once MSI-X/MQ is enabled on Intel's 10G cards? (P.S. MQ cannot be enabled on both machines unless I add pci=msi to the kernel's command line) B. Any idea why oprofile refuses to generate cache statistics and/or what did I do wrong? C. Before I dive into AMD's and Intel's MSR/PMC documentation and spend the next five days trying to decipher which architectural / non-architectural counter needs to set/used and how, do you have any idea how I can access the performance counters without writing the code myself? - Gilboa [1] opcontrol --setup --vmlinux /usr/lib/debug/lib/modules/2.6.27.9-73.fc9.x86_64/vmlinux --event=DATA_CACHE_ACCESS:1000:0:1:1 [2] opcontrol --setup --vmlinux /usr/lib/debug/lib/modules/2.6.27.9-73.fc9.x86_64/vmlinux --event=L2_CACHE_MISS:1000:0:1:1 [3] opcontrol --setup --vmlinux /usr/lib/debug/lib/modules/2.6.27.9-73.fc9.x86_64/vmlinux --event=CPU_CLK_UNHALTED:10000000:0:1:1 * F10 seems to dislike the DL585G5; Issue already reported against anaconda. (#480638) From gilboad at gmail.com Sat Jan 24 17:54:22 2009 From: gilboad at gmail.com (Gilboa Davara) Date: Sat, 24 Jan 2009 19:54:22 +0200 Subject: Semi-OT: Profiling 10GbE devices... Help? In-Reply-To: <1232819168.30663.281.camel@gilboa-home-dev.localdomain> References: <1232819168.30663.281.camel@gilboa-home-dev.localdomain> Message-ID: <1232819662.30663.287.camel@gilboa-home-dev.localdomain> On Sat, 2009-01-24 at 19:46 +0200, Gilboa Davara wrote: > Hello all, > ... P.S. Too much work, way-too-much coffee, no enough sleep == lousy English. Sorry for that. - Gilboa From brong at fastmail.fm Sat Jan 24 03:56:45 2009 From: brong at fastmail.fm (Bron Gondwana) Date: Sat, 24 Jan 2009 14:56:45 +1100 Subject: /proc/sys/fs/epoll/max_user_instances=128 considered harmful Message-ID: <20090124035645.GA9068@brong.net> Hi, I'm chasing this up on the kernel mailing list now. We hit exactly the same issue on a production Postfix machine, which also uses epoll in this way. I've taken your suggestions of 1024 as a good point - I've also seen that value suggested elsewhere on the internet, so that sounds reasonable. We've set 4096 in /etc/sysctl.conf to be certain we're OK! Bron. From kamezawa.hiroyu at jp.fujitsu.com Mon Jan 26 05:07:45 2009 From: kamezawa.hiroyu at jp.fujitsu.com (KAMEZAWA Hiroyuki) Date: Mon, 26 Jan 2009 14:07:45 +0900 Subject: Question: Is memory resource controller (cgroup) available in Fedora11 ? Message-ID: <20090126140745.dadfe3d1.kamezawa.hiroyu@jp.fujitsu.com> Hi, I thought there was a request to make memroy resource controller (CONFIG_CGROUP_MEM_RES_CTLR) availele in Fedora10 age. (But not configured.) I'd like to request memory cgroup configured in Fedora 11. (I'm sorry if too late.) Comapring current implementation(2.6.28) with the version half year ago, - There is no pointer from struct page. IIRC, this pointer was a big obstacle for the merge request. BTW, what kernel version Fedora11 will be based on ? I prefer 2.6.29-rc version of memory cgroup rather than 2.6.28 ;) Thanks, -Kame From kyle at infradead.org Mon Jan 26 05:15:44 2009 From: kyle at infradead.org (Kyle McMartin) Date: Mon, 26 Jan 2009 00:15:44 -0500 Subject: Question: Is memory resource controller (cgroup) available in Fedora11 ? In-Reply-To: <20090126140745.dadfe3d1.kamezawa.hiroyu@jp.fujitsu.com> References: <20090126140745.dadfe3d1.kamezawa.hiroyu@jp.fujitsu.com> Message-ID: <20090126051544.GC6190@bombadil.infradead.org> On Mon, Jan 26, 2009 at 02:07:45PM +0900, KAMEZAWA Hiroyuki wrote: > Hi, > Hi! > I thought there was a request to make memroy resource controller > (CONFIG_CGROUP_MEM_RES_CTLR) availele in Fedora10 age. > (But not configured.) > > I'd like to request memory cgroup configured in Fedora 11. > (I'm sorry if too late.) > This is what we currently have enabled in Fedora 11's generic config: kyle at minerva ~/rpms/kernel/devel $ grep CGROUP config-generic CONFIG_NET_CLS_CGROUP=y CONFIG_CGROUP_SCHED=y CONFIG_CGROUP_MEM_RES_CTLR=y CONFIG_CGROUP_MEM_RES_CTLR_SWAP=y CONFIG_CGROUPS=y # CONFIG_CGROUP_DEBUG is not set CONFIG_CGROUP_NS=y CONFIG_CGROUP_CPUACCT=y CONFIG_CGROUP_DEVICE=y CONFIG_CGROUP_FREEZER=y CONFIG_CGROUP_MEM_CONT=y kyle at minerva ~/rpms/kernel/devel $ > Comapring current implementation(2.6.28) with the version half year ago, > > - There is no pointer from struct page. > > IIRC, this pointer was a big obstacle for the merge request. Right, we were concerned it would impact performance because it pushed struct page passed the size of a single cacheline. > BTW, what kernel version Fedora11 will be based on ? > I prefer 2.6.29-rc version of memory cgroup rather than 2.6.28 ;) > The current plan is for F11 to be based on 2.6.29, but it's possible (though extremely unlikely) that if .29 stabilizes very quickly that we might end up on .30, but I wouldn't bet on it. :) > Thanks, > -Kame cheers, Kyle From kamezawa.hiroyu at jp.fujitsu.com Mon Jan 26 05:20:56 2009 From: kamezawa.hiroyu at jp.fujitsu.com (KAMEZAWA Hiroyuki) Date: Mon, 26 Jan 2009 14:20:56 +0900 Subject: Question: Is memory resource controller (cgroup) available in Fedora11 ? In-Reply-To: <20090126051544.GC6190@bombadil.infradead.org> References: <20090126140745.dadfe3d1.kamezawa.hiroyu@jp.fujitsu.com> <20090126051544.GC6190@bombadil.infradead.org> Message-ID: <20090126142056.240ab50a.kamezawa.hiroyu@jp.fujitsu.com> On Mon, 26 Jan 2009 00:15:44 -0500 Kyle McMartin wrote: > On Mon, Jan 26, 2009 at 02:07:45PM +0900, KAMEZAWA Hiroyuki wrote: > > Hi, > > > > Hi! > > > I thought there was a request to make memroy resource controller > > (CONFIG_CGROUP_MEM_RES_CTLR) availele in Fedora10 age. > > (But not configured.) > > > > I'd like to request memory cgroup configured in Fedora 11. > > (I'm sorry if too late.) > > > > This is what we currently have enabled in Fedora 11's generic config: > > kyle at minerva ~/rpms/kernel/devel $ grep CGROUP config-generic > CONFIG_NET_CLS_CGROUP=y > CONFIG_CGROUP_SCHED=y > CONFIG_CGROUP_MEM_RES_CTLR=y > CONFIG_CGROUP_MEM_RES_CTLR_SWAP=y > CONFIG_CGROUPS=y > # CONFIG_CGROUP_DEBUG is not set > CONFIG_CGROUP_NS=y > CONFIG_CGROUP_CPUACCT=y > CONFIG_CGROUP_DEVICE=y > CONFIG_CGROUP_FREEZER=y > CONFIG_CGROUP_MEM_CONT=y > kyle at minerva ~/rpms/kernel/devel $ > Wow, thanks ! (I wonder CONFIG_CGROUP_MEM_CONT may be stale config name..) > > Comapring current implementation(2.6.28) with the version half year ago, > > > > - There is no pointer from struct page. > > > > IIRC, this pointer was a big obstacle for the merge request. > > Right, we were concerned it would impact performance because it pushed > struct page passed the size of a single cacheline. > > > BTW, what kernel version Fedora11 will be based on ? > > I prefer 2.6.29-rc version of memory cgroup rather than 2.6.28 ;) > > > > The current plan is for F11 to be based on 2.6.29, but it's possible > (though extremely unlikely) that if .29 stabilizes very quickly that we > might end up on .30, but I wouldn't bet on it. :) > Thank you for quick response, very informative! Regards, -Kame > > Thanks, > > -Kame > > cheers, Kyle > From kyle at infradead.org Mon Jan 26 05:42:45 2009 From: kyle at infradead.org (Kyle McMartin) Date: Mon, 26 Jan 2009 00:42:45 -0500 Subject: Question: Is memory resource controller (cgroup) available in Fedora11 ? In-Reply-To: <20090126142056.240ab50a.kamezawa.hiroyu@jp.fujitsu.com> References: <20090126140745.dadfe3d1.kamezawa.hiroyu@jp.fujitsu.com> <20090126051544.GC6190@bombadil.infradead.org> <20090126142056.240ab50a.kamezawa.hiroyu@jp.fujitsu.com> Message-ID: <20090126054245.GD6190@bombadil.infradead.org> On Mon, Jan 26, 2009 at 02:20:56PM +0900, KAMEZAWA Hiroyuki wrote: > Wow, thanks ! > > (I wonder CONFIG_CGROUP_MEM_CONT may be stale config name..) > Entirely possible... sadly we don't prune the config as often as we should so stale config options linger for a while. :) cheers, Kyle From balbir at linux.vnet.ibm.com Mon Jan 26 06:08:51 2009 From: balbir at linux.vnet.ibm.com (Balbir Singh) Date: Mon, 26 Jan 2009 11:38:51 +0530 Subject: Question: Is memory resource controller (cgroup) available in Fedora11 ? In-Reply-To: <20090126054245.GD6190@bombadil.infradead.org> References: <20090126140745.dadfe3d1.kamezawa.hiroyu@jp.fujitsu.com> <20090126051544.GC6190@bombadil.infradead.org> <20090126142056.240ab50a.kamezawa.hiroyu@jp.fujitsu.com> <20090126054245.GD6190@bombadil.infradead.org> Message-ID: <20090126060851.GA504@balbir.in.ibm.com> * Kyle McMartin [2009-01-26 00:42:45]: > On Mon, Jan 26, 2009 at 02:20:56PM +0900, KAMEZAWA Hiroyuki wrote: > > Wow, thanks ! > > > > (I wonder CONFIG_CGROUP_MEM_CONT may be stale config name..) > > > > Entirely possible... sadly we don't prune the config as often as we > should so stale config options linger for a while. :) I had requested Dave Jones for enablement and he added the memory resource controller. It is enabled in F11. -- Balbir From markmc at redhat.com Mon Jan 26 09:05:44 2009 From: markmc at redhat.com (Mark McLoughlin) Date: Mon, 26 Jan 2009 09:05:44 +0000 Subject: rpms/kernel/devel linux-2.6-defaults-intel_iommu-off.patch, NONE, 1.1 kernel.spec, 1.1225, 1.1226 In-Reply-To: <20090123184913.62D9E700FE@cvs1.fedora.phx.redhat.com> References: <20090123184913.62D9E700FE@cvs1.fedora.phx.redhat.com> Message-ID: <1232960744.3724.29.camel@blaa> Hi Kyle, On Fri, 2009-01-23 at 18:49 +0000, Kyle McMartin wrote: > * Fri Jan 23 2009 Kyle McMartin > - disable intel_iommu by default (enable with "intel_iommu=on") Why so? We're pretty much guaranteed that no-one will enable this ... do we know of specific hardware that this is breaking? One of the major virt features in F11 needs this: https://fedoraproject.org/wiki/Features/KVM_PCI_Device_Assignment Thanks, Mark. From markmc at redhat.com Mon Jan 26 09:32:28 2009 From: markmc at redhat.com (Mark McLoughlin) Date: Mon, 26 Jan 2009 09:32:28 +0000 Subject: intel_iommu=off default [was Re: rpms/kernel/devel linux-2.6-defaults-intel_iommu-off.patch, NONE, 1.1 kernel.spec, 1.1225, 1.1226] In-Reply-To: <1232960744.3724.29.camel@blaa> References: <20090123184913.62D9E700FE@cvs1.fedora.phx.redhat.com> <1232960744.3724.29.camel@blaa> Message-ID: <1232962348.3724.53.camel@blaa> On Mon, 2009-01-26 at 09:05 +0000, Mark McLoughlin wrote: > Hi Kyle, > > On Fri, 2009-01-23 at 18:49 +0000, Kyle McMartin wrote: > > > * Fri Jan 23 2009 Kyle McMartin > > - disable intel_iommu by default (enable with "intel_iommu=on") > > Why so? > > We're pretty much guaranteed that no-one will enable this ... do we know > of specific hardware that this is breaking? Okay, yaneti pointed out the fedora-test-list discussion: https://www.redhat.com/archives/fedora-test-list/2009-January/msg00380.html Is this the only known issue right now? https://bugzilla.redhat.com/show_bug.cgi?id=479996 I've sent on some details to: https://lists.linux-foundation.org/pipermail/iommu/2009-January/001028.html Cheers, Mark. From kyle at infradead.org Mon Jan 26 20:26:26 2009 From: kyle at infradead.org (Kyle McMartin) Date: Mon, 26 Jan 2009 15:26:26 -0500 Subject: [PATCH] kernel: only build kernel-headers on ARM In-Reply-To: <1232685401.13606.4.camel@pe-dt032> References: <1232601122.2814.79.camel@pe-lt019> <20090122180154.GB3184@bombadil.infradead.org> <1232685401.13606.4.camel@pe-dt032> Message-ID: <20090126202626.GD7500@bombadil.infradead.org> On Fri, Jan 23, 2009 at 10:06:41AM +0530, Kedar Sovani wrote: > I applied it, but there wasn't enough in config-arm to make it build. Rather than just ignore it, I filled in some of the blanks that seemed relevant. I have no idea what your specific machtype is, but I assumed the versatile thingy so I turned things on/off as Kconfig help text seemed to indicate were for this platform. Here's a diff, shout or plz send a diff against devel/config-arm if anything seems out of place to you folks. cheers, Kyle Index: config-arm =================================================================== RCS file: /cvs/pkgs/rpms/kernel/devel/config-arm,v retrieving revision 1.1 diff -u -p -r1.1 config-arm --- config-arm 26 Jan 2009 07:19:13 -0000 1.1 +++ config-arm 26 Jan 2009 20:23:45 -0000 @@ -5,6 +5,31 @@ CONFIG_SYS_SUPPORTS_APM_EMULATION=y CONFIG_CC_OPTIMIZE_FOR_SIZE=y CONFIG_ARCH_VERSATILE=y +CONFIG_ARCH_VERSATILE_PB=y +CONFIG_MACH_VERSATILE_AB=y + +# CONFIG_CPU_ICACHE_DISABLE is not set +# CONFIG_CPU_DCACHE_DISABLE is not set +# CONFIG_CPU_DCACHE_WRITETHROUGH is not set +# CONFIG_CPU_CACHE_ROUND_ROBIN is not set + +CONFIG_ZBOOT_ROM_TEXT=0 +CONFIG_ZBOOT_ROM_BSS=0 + +# CONFIG_XIP_KERNEL is not set + +CONFIG_ATAGS_PROC=y + +# CONFIG_FPE_NWFPE is not set +CONFIG_FPE_FASTFPE=y +CONFIG_VFP=y + +CONFIG_PM=y +# CONFIG_PM_DEBUG is not set +# CONFIG_PM_TRACE is not set +CONFIG_SUSPEND=y +# CONFIG_PM_TEST_SUSPEND is not set +CONFIG_APM_EMULATION=y CONFIG_ARM_THUMB=y @@ -13,3 +38,56 @@ CONFIG_OABI_COMPAT=y CONFIG_CMDLINE="console=ttyAM0,115200 root=/dev/sda1 rootdelay=20" +CONFIG_NO_HZ=y +CONFIG_HIGH_RES_TIMERS=y + +# CONFIG_CPU_IDLE is not set + +CONFIG_LEDS=y +CONFIG_LEDS_CPU=y + +CONFIG_MTD_AFS_PARTS=y +CONFIG_MTD_ARM_INTEGRATOR=y +CONFIG_MTD_IMPA7=y + +CONFIG_AX88796=m +CONFIG_AX88796_93CX6=y +CONFIG_SMC91X=m +CONFIG_DM9000=m +CONFIG_DM9000_DEBUGLEVEL=4 +# CONFIG_DM9000_FORCE_SIMPLE_PHY_POLL is not set +CONFIG_SMC911X=m +CONFIG_SMSC911X=m + +CONFIG_SERIO_AMBAKMI=m + +CONFIG_SERIAL_AMBA_PL011=y +CONFIG_SERIAL_AMBA_PL011_CONSOLE=y + +CONFIG_I2C_VERSATILE=y + +CONFIG_THERMAL=y + +# CONFIG_MFD_T7L66XB is not set +# CONFIG_MFD_TC6387XB is not set + +CONFIG_FB_ARMCLCD=m + +CONFIG_SND_ARM=y +CONFIG_SND_ARMAACI=m + +CONFIG_USB_MUSB_HDRC=m +# CONFIG_MUSB_PIO_ONLY is not set +CONFIG_USB_TUSB6010=y +# CONFIG_USB_MUSB_DEBUG is not set + +CONFIG_MMC_ARMMMCI=m + +CONFIG_RTC_DRV_PL030=m +CONFIG_RTC_DRV_PL031=m + +# CONFIG_SGI_IOC4 is not set + +# CONFIG_DEBUG_USER is not set +# CONFIG_DEBUG_ERRORS is not set +# CONFIG_DEBUG_LL is not set From cebbert at redhat.com Tue Jan 27 22:40:10 2009 From: cebbert at redhat.com (Chuck Ebbert) Date: Tue, 27 Jan 2009 17:40:10 -0500 Subject: Skipping 2.6.28 for F8 and F9 Message-ID: <20090127174010.1d8f2e58@dhcp-100-2-144.bos.redhat.com> 2.6.28 has turned out to be a bit buggy. Also 2.6.27 has been chosen to be a long-term supported kernel upstream. This means we can leave F9 and F10 on .27 and concentrate on getting .29 into shape for F10 and F11. With the extra resources available from not trying to fix up .28 we can make .29 even better. Comments? From tjd at mit.edu Wed Jan 28 01:05:27 2009 From: tjd at mit.edu (Tom Davidson) Date: Tue, 27 Jan 2009 17:05:27 -0800 Subject: crash with iwl3945/iwlagn; fix is in 2.6.28, can it be provided to 2.6.27? Message-ID: <811d74850901271705y23b7f3b8m24202b69edc3ab5c@mail.gmail.com> Hi all, Bug 470225 crashes systems with Intel 3945/4965/5300 wireless cards on busy networks. The kernel warning generated is currently the #1 most-reported item at kerneloops (www.kerneloops.org -- several k reports mostly from FC10 machines) Intel has produced a patch, and John Linville has applied this to the 2.6.28 kernel (available from koji), but it now sounds like 2.6.28 might not make it out soon, or ever. Can this fix be applied to the 2.6.27 branch? Thanks much! Tom References: https://bugzilla.redhat.com/show_bug.cgi?id=470225 (Bug at Redhat) http://www.intellinuxwireless.org/bugzilla/show_bug.cgi?id=1822 (Bug at Intel) http://kerneloops.org/searchweek.php?search=rs_get_rate (Counts of warnings reported to kerneloops) From zaitcev at redhat.com Wed Jan 28 01:12:33 2009 From: zaitcev at redhat.com (Pete Zaitcev) Date: Tue, 27 Jan 2009 18:12:33 -0700 Subject: crash with iwl3945/iwlagn; fix is in 2.6.28, can it be provided to 2.6.27? In-Reply-To: <811d74850901271705y23b7f3b8m24202b69edc3ab5c@mail.gmail.com> References: <811d74850901271705y23b7f3b8m24202b69edc3ab5c@mail.gmail.com> Message-ID: <20090127181233.c72099a8.zaitcev@redhat.com> On Tue, 27 Jan 2009 17:05:27 -0800, Tom Davidson wrote: > Intel has produced a patch, and John Linville has applied this to the 2.6.28 > kernel (available from koji), but it now sounds like 2.6.28 might not make > it out soon, or ever. Can this fix be applied to the 2.6.27 branch? Maybe the -stable team will pick it, so we'd get it automatically? -- Pete From oliver at linux-kernel.at Wed Jan 28 07:41:25 2009 From: oliver at linux-kernel.at (Oliver Falk) Date: Wed, 28 Jan 2009 08:41:25 +0100 Subject: Skipping 2.6.28 for F8 and F9 In-Reply-To: <20090127174010.1d8f2e58@dhcp-100-2-144.bos.redhat.com> References: <20090127174010.1d8f2e58@dhcp-100-2-144.bos.redhat.com> Message-ID: <49800C25.1080503@linux-kernel.at> Hi Chuck! Chuck Ebbert wrote: > 2.6.28 has turned out to be a bit buggy. Also 2.6.27 has been chosen to be > a long-term supported kernel upstream. This means we can leave F9 and F10 > on .27 and concentrate on getting .29 into shape for F10 and F11. With the > extra resources available from not trying to fix up .28 we can make .29 even > better. Do you have any upstream resources at hand, describing the problems? -of From markmc at redhat.com Wed Jan 28 09:31:47 2009 From: markmc at redhat.com (Mark McLoughlin) Date: Wed, 28 Jan 2009 09:31:47 +0000 Subject: Package: kernel-2.6.29-0.59.rc2.git3.fc11 Tag: dist-f11 Status: failed Built by: markmc In-Reply-To: <20090128080919.8B791208201@bastion.fedora.phx.redhat.com> References: <20090128080919.8B791208201@bastion.fedora.phx.redhat.com> Message-ID: <1233135107.22103.12.camel@blaa> Hey, I enabled CONFIG_PCI_STUB (#482792), but the build failed on ppc: drivers/gpu/drm/nouveau/nouveau_state.c: In function 'nouveau_load': drivers/gpu/drm/nouveau/nouveau_state.c:487: error: implicit declaration of function '___swab32' make[4]: *** [drivers/gpu/drm/nouveau/nouveau_state.o] Error 1 http://koji.fedoraproject.org/koji/getfile?taskID=1088040&name=build.log I considered disabling nouveau again, but I see the last few commits haven't been built so I just left it be. Cheers, Mark. From notting at redhat.com Wed Jan 28 15:20:03 2009 From: notting at redhat.com (Bill Nottingham) Date: Wed, 28 Jan 2009 10:20:03 -0500 Subject: crash with iwl3945/iwlagn; fix is in 2.6.28, can it be provided to 2.6.27? In-Reply-To: <20090127181233.c72099a8.zaitcev@redhat.com> References: <811d74850901271705y23b7f3b8m24202b69edc3ab5c@mail.gmail.com> <20090127181233.c72099a8.zaitcev@redhat.com> Message-ID: <20090128152003.GD3606@nostromo.devel.redhat.com> Pete Zaitcev (zaitcev at redhat.com) said: > > Intel has produced a patch, and John Linville has applied this to the 2.6.28 > > kernel (available from koji), but it now sounds like 2.6.28 might not make > > it out soon, or ever. Can this fix be applied to the 2.6.27 branch? > > Maybe the -stable team will pick it, so we'd get it automatically? We should still add it in the meantime (there are other dups in bugzilla, such as #480701) - it's very common hardware, and at least when I was seeing it I was repeatedly getting hard panics requiring reboot within 1-2 minutes of the wireless interface being enabled. Bill From linville at redhat.com Wed Jan 28 15:30:27 2009 From: linville at redhat.com (John W. Linville) Date: Wed, 28 Jan 2009 10:30:27 -0500 Subject: crash with iwl3945/iwlagn; fix is in 2.6.28, can it be provided to 2.6.27? In-Reply-To: <20090128152003.GD3606@nostromo.devel.redhat.com> References: <811d74850901271705y23b7f3b8m24202b69edc3ab5c@mail.gmail.com> <20090127181233.c72099a8.zaitcev@redhat.com> <20090128152003.GD3606@nostromo.devel.redhat.com> Message-ID: <20090128153027.GA28849@redhat.com> On Wed, Jan 28, 2009 at 10:20:03AM -0500, Bill Nottingham wrote: > Pete Zaitcev (zaitcev at redhat.com) said: > > > Intel has produced a patch, and John Linville has applied this to the 2.6.28 > > > kernel (available from koji), but it now sounds like 2.6.28 might not make > > > it out soon, or ever. Can this fix be applied to the 2.6.27 branch? > > > > Maybe the -stable team will pick it, so we'd get it automatically? > > We should still add it in the meantime (there are other dups in bugzilla, > such as #480701) - it's very common hardware, and at least when I was seeing > it I was repeatedly getting hard panics requiring reboot within 1-2 minutes > of the wireless interface being enabled. IIRC, it will take some porting for 2.6.27. Is there an F-10-2_6_27 fork somewhere? John -- John W. Linville Linux should be at the core linville at redhat.com of your literate lifestyle. From kyle at infradead.org Wed Jan 28 17:50:44 2009 From: kyle at infradead.org (Kyle McMartin) Date: Wed, 28 Jan 2009 12:50:44 -0500 Subject: Package: kernel-2.6.29-0.59.rc2.git3.fc11 Tag: dist-f11 Status: failed Built by: markmc In-Reply-To: <1233135107.22103.12.camel@blaa> References: <20090128080919.8B791208201@bastion.fedora.phx.redhat.com> <1233135107.22103.12.camel@blaa> Message-ID: <20090128175044.GA21753@bombadil.infradead.org> On Wed, Jan 28, 2009 at 09:31:47AM +0000, Mark McLoughlin wrote: > Hey, > > I enabled CONFIG_PCI_STUB (#482792), but the build failed on ppc: > > drivers/gpu/drm/nouveau/nouveau_state.c: In function 'nouveau_load': > drivers/gpu/drm/nouveau/nouveau_state.c:487: error: implicit declaration of > function '___swab32' > make[4]: *** [drivers/gpu/drm/nouveau/nouveau_state.o] Error 1 > fixt. From kyle at infradead.org Wed Jan 28 17:53:12 2009 From: kyle at infradead.org (Kyle McMartin) Date: Wed, 28 Jan 2009 12:53:12 -0500 Subject: crash with iwl3945/iwlagn; fix is in 2.6.28, can it be provided to 2.6.27? In-Reply-To: <20090128153027.GA28849@redhat.com> References: <811d74850901271705y23b7f3b8m24202b69edc3ab5c@mail.gmail.com> <20090127181233.c72099a8.zaitcev@redhat.com> <20090128152003.GD3606@nostromo.devel.redhat.com> <20090128153027.GA28849@redhat.com> Message-ID: <20090128175312.GB21753@bombadil.infradead.org> On Wed, Jan 28, 2009 at 10:30:27AM -0500, John W. Linville wrote: > On Wed, Jan 28, 2009 at 10:20:03AM -0500, Bill Nottingham wrote: > > Pete Zaitcev (zaitcev at redhat.com) said: > > > > Intel has produced a patch, and John Linville has applied this to the 2.6.28 > > > > kernel (available from koji), but it now sounds like 2.6.28 might not make > > > > it out soon, or ever. Can this fix be applied to the 2.6.27 branch? > > > > > > Maybe the -stable team will pick it, so we'd get it automatically? > > > > We should still add it in the meantime (there are other dups in bugzilla, > > such as #480701) - it's very common hardware, and at least when I was seeing > > it I was repeatedly getting hard panics requiring reboot within 1-2 minutes > > of the wireless interface being enabled. > > IIRC, it will take some porting for 2.6.27. Is there an F-10-2_6_27 > fork somewhere? > I started this last night, so I could submit it to stable... The F10 2.6.27 branch is private-fedora-10-2_6_27. cheers, Kyle From kyle at infradead.org Thu Jan 29 02:23:11 2009 From: kyle at infradead.org (Kyle McMartin) Date: Wed, 28 Jan 2009 21:23:11 -0500 Subject: crash with iwl3945/iwlagn; fix is in 2.6.28, can it be provided to 2.6.27? In-Reply-To: <20090128175312.GB21753@bombadil.infradead.org> References: <811d74850901271705y23b7f3b8m24202b69edc3ab5c@mail.gmail.com> <20090127181233.c72099a8.zaitcev@redhat.com> <20090128152003.GD3606@nostromo.devel.redhat.com> <20090128153027.GA28849@redhat.com> <20090128175312.GB21753@bombadil.infradead.org> Message-ID: <20090129022311.GB11255@bombadil.infradead.org> On Wed, Jan 28, 2009 at 12:53:12PM -0500, Kyle McMartin wrote: > I started this last night, so I could submit it to stable... > Forgot to mention this here: http://koji.fedoraproject.org/koji/taskinfo?taskID=1089515 From tjd at mit.edu Thu Jan 29 07:38:56 2009 From: tjd at mit.edu (Tom Davidson) Date: Wed, 28 Jan 2009 23:38:56 -0800 Subject: crash with iwl3945/iwlagn; fix is in 2.6.28, can it be provided to 2.6.27? In-Reply-To: <20090129022311.GB11255@bombadil.infradead.org> References: <811d74850901271705y23b7f3b8m24202b69edc3ab5c@mail.gmail.com> <20090127181233.c72099a8.zaitcev@redhat.com> <20090128152003.GD3606@nostromo.devel.redhat.com> <20090128153027.GA28849@redhat.com> <20090128175312.GB21753@bombadil.infradead.org> <20090129022311.GB11255@bombadil.infradead.org> Message-ID: <811d74850901282338r6787a608qea2ff81dfadb945b@mail.gmail.com> Alas, Kyle's patched kernel does not fix the problem--I continue to get oopses and hard panics. Also, the problem is fixed by an unpatched build of 2.6.28 (2.6.28-3.fc10.i686). A closer read of the comments at the original bug reveals that no one was actually testing just the patch. So while this remains a serious crasher, it's no longer just a packaging request. I'll retreat back to bugzilla until there is a better idea of the fix. Thanks very much to Kyle for producing a test kernel so quickly, and sorry for the wild goose chase. If anyone has additional debugging tips/requests, please share them, as I have access to a network here that reliably triggers the issue. -Tom On Wed, Jan 28, 2009 at 6:23 PM, Kyle McMartin wrote: > On Wed, Jan 28, 2009 at 12:53:12PM -0500, Kyle McMartin wrote: >> I started this last night, so I could submit it to stable... >> > > Forgot to mention this here: > > http://koji.fedoraproject.org/koji/taskinfo?taskID=1089515 > > _______________________________________________ > Fedora-kernel-list mailing list > Fedora-kernel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-kernel-list > From markmc at redhat.com Thu Jan 29 18:35:02 2009 From: markmc at redhat.com (Mark McLoughlin) Date: Thu, 29 Jan 2009 18:35:02 +0000 Subject: [PATCH] Disable kvmclock for non constant tsc cpus. Message-ID: <1233254102.6470.77.camel@blaa> Hi, We've a pretty gnarly issue with KVM paravirt clock at the moment. Basically, cpufreq can kick the TSC out of sync on CPUs and that confuses the hell out of guests because the current code assumes the same TSC rate on all CPUs. The problem manifests itself as completely random hangs and guest crashes, with the current workaround being to boot the guest with clocksource=acpi_pm. See: https://bugzilla.redhat.com/475598 Glommer, Gerd, Juan and Marcelo are all trying to figure out the best fix, with the latest candidate being: https://bugzilla.redhat.com/attachment.cgi?id=329812 But we'd really like to add this temporary patch to rawhide (and maybe F10 if we don't fix it soon) ... any objections? Thanks, Mark. From: Glauber Costa Date: Thu, 29 Jan 2009 12:39:22 -0500 Subject: [PATCH] Disable kvmclock for non constant tsc cpus. Currently, this code path is posing us big troubles, and we won't have a decent patch in time. So, temporarily disable it. See: https://bugzilla.redhat.com/475598 There's a module parameter for the adventurous who want to force it. Signed-off-by: Glauber Costa Signed-off-by: Marcelo Tosatti Signed-off-by: Mark McLoughlin --- arch/x86/kvm/x86.c | 7 ++++++- 1 files changed, 6 insertions(+), 1 deletions(-) diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c index cc17546..2e22ac9 100644 --- a/arch/x86/kvm/x86.c +++ b/arch/x86/kvm/x86.c @@ -957,6 +957,9 @@ out: return r; } +static int force_kvmclock = 0; +module_param(force_kvmclock, bool, 0644); + int kvm_dev_ioctl_check_extension(long ext) { int r; @@ -967,7 +970,6 @@ int kvm_dev_ioctl_check_extension(long ext) case KVM_CAP_MMU_SHADOW_CACHE_CONTROL: case KVM_CAP_SET_TSS_ADDR: case KVM_CAP_EXT_CPUID: - case KVM_CAP_CLOCKSOURCE: case KVM_CAP_PIT: case KVM_CAP_NOP_IO_DELAY: case KVM_CAP_MP_STATE: @@ -992,6 +994,9 @@ int kvm_dev_ioctl_check_extension(long ext) case KVM_CAP_IOMMU: r = iommu_found(); break; + case KVM_CAP_CLOCKSOURCE: + r = force_kvmclock || boot_cpu_has(X86_FEATURE_CONSTANT_TSC); + break; default: r = 0; break; -- 1.6.1 From Axel.Thimm at ATrpms.net Sat Jan 31 00:20:30 2009 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Sat, 31 Jan 2009 02:20:30 +0200 Subject: alsa forth and back? Message-ID: <20090131002030.GB5277@victor.nirvana> Hi, alsa was demoted from 1.0.18 to 1.0.17 in the latest kernel packages. Could someone explain why? Thanks! -- Axel.Thimm at ATrpms.net From konrad at tylerc.org Sat Jan 31 00:30:02 2009 From: konrad at tylerc.org (Conrad Meyer) Date: Fri, 30 Jan 2009 16:30:02 -0800 Subject: alsa forth and back? In-Reply-To: <20090131002030.GB5277@victor.nirvana> References: <20090131002030.GB5277@victor.nirvana> Message-ID: <200901301630.03031.konrad@tylerc.org> On Friday 30 January 2009 04:20:30 pm Axel Thimm wrote: > Hi, > > alsa was demoted from 1.0.18 to 1.0.17 in the latest kernel > packages. Could someone explain why? > > Thanks! If you follow fedora-devel-list, you'll notice there were some regressions in 1.0.18 that broke sound for some users. They decided to revert to 1.0.17 instead of waiting for 1.0.19 release. Regards, -- Conrad Meyer From ozan at pardus.org.tr Sat Jan 31 01:01:48 2009 From: ozan at pardus.org.tr (=?UTF-8?B?T3phbiDDh2HEn2xheWFu?=) Date: Sat, 31 Jan 2009 03:01:48 +0200 Subject: alsa forth and back? In-Reply-To: <200901301630.03031.konrad@tylerc.org> References: <20090131002030.GB5277@victor.nirvana> <200901301630.03031.konrad@tylerc.org> Message-ID: <4983A2FC.6080103@pardus.org.tr> Conrad Meyer wrote: > On Friday 30 January 2009 04:20:30 pm Axel Thimm wrote: >> Hi, >> >> alsa was demoted from 1.0.18 to 1.0.17 in the latest kernel >> packages. Could someone explain why? >> >> Thanks! > > If you follow fedora-devel-list, you'll notice there were some regressions in > 1.0.18 that broke sound for some users. They decided to revert to 1.0.17 > instead of waiting for 1.0.19 release. > > Regards, 1.0.19 is already out. -- Ozan ?a?layan From konrad at tylerc.org Sat Jan 31 01:21:26 2009 From: konrad at tylerc.org (Conrad Meyer) Date: Fri, 30 Jan 2009 17:21:26 -0800 Subject: alsa forth and back? In-Reply-To: <4983A2FC.6080103@pardus.org.tr> References: <20090131002030.GB5277@victor.nirvana> <200901301630.03031.konrad@tylerc.org> <4983A2FC.6080103@pardus.org.tr> Message-ID: <200901301721.26447.konrad@tylerc.org> On Friday 30 January 2009 05:01:48 pm Ozan ?a?layan wrote: > Conrad Meyer wrote: > > On Friday 30 January 2009 04:20:30 pm Axel Thimm wrote: > >> Hi, > >> > >> alsa was demoted from 1.0.18 to 1.0.17 in the latest kernel > >> packages. Could someone explain why? > >> > >> Thanks! > > > > If you follow fedora-devel-list, you'll notice there were some > > regressions in 1.0.18 that broke sound for some users. They decided to > > revert to 1.0.17 instead of waiting for 1.0.19 release. > > > > Regards, > > 1.0.19 is already out. s/waiting for 1.0.19 release/waiting to test 1.0.19 for regressions/ -- Conrad Meyer From Axel.Thimm at ATrpms.net Sat Jan 31 07:42:23 2009 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Sat, 31 Jan 2009 09:42:23 +0200 Subject: alsa forth and back? In-Reply-To: <200901301630.03031.konrad@tylerc.org> References: <20090131002030.GB5277@victor.nirvana> <200901301630.03031.konrad@tylerc.org> Message-ID: <20090131074223.GA10044@victor.nirvana> On Fri, Jan 30, 2009 at 04:30:02PM -0800, Conrad Meyer wrote: > On Friday 30 January 2009 04:20:30 pm Axel Thimm wrote: > > Hi, > > > > alsa was demoted from 1.0.18 to 1.0.17 in the latest kernel > > packages. Could someone explain why? > > > > Thanks! > > If you follow fedora-devel-list, you'll notice there were some > regressions in 1.0.18 that broke sound for some users. They decided > to revert to 1.0.17 instead of waiting for 1.0.19 release. I think that whatever I saw on fedora-devel was accompanied with a patch. -- Axel.Thimm at ATrpms.net