Re: CONFIG_INTEL_TXT
2009/10/23 Arjan van de Ven : > On Thu, 22 Oct 2009 18:39:53 +0100 > Jon Masters wrote: > >> Don't forget to mention the more paranoid hand-waving about removing >> RAM chips at runtime with liquid nitrogen after going into suspend and >> hax0ring. I think there will be more upstream discussion anyway. > > I'm sorry but this argument makes no sense whatsoever. > > Claiming that a feature should not be enabled because someone is talking > about a mythical attack that is waaay outside the scope of what a > technology wants to protect is not solid reasoning, it's fear mongering > instead. All the same, it was disappointing news to me to read that Intel are even pushing stuff that leverages binary blobs with no source code. There would be nothing to fear and no need for fear mongering if it was an open blob. It would make the whole argument moot. -- Christopher Brown ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: [RHEL6 PATCH] internal: properly define %{dist} and compute correct pkg_release from Makefile
; s/%%GITREV%%/$GITREV/
> diff --git a/redhat/kernel.spec.template b/redhat/kernel.spec.template
> index cbe88e4..bbe1369 100644
> --- a/redhat/kernel.spec.template
> +++ b/redhat/kernel.spec.template
> @@ -15,10 +15,11 @@ Summary: The Linux kernel
> # that the kernel isn't the stock distribution kernel, for example,
> # by setting the define to ".local" or ".bz123456"
> #
> -# % define buildid .local
> +#% define buildid .local
>
> %define rhel 1
> %if %{rhel}
> +%define dist %%DIST%%
> %define distro_build %%BUILD%%
> %define signmodules 1
> %else
> @@ -154,7 +155,7 @@ Summary: The Linux kernel
> %if 0%{?stable_rc}
> %define stable_rctag .rc%{stable_rc}
> %endif
> -%define pkg_release %{distro_build}%{?stable_rctag}%{?buildid}%{?dist}
> +%define pkg_release %{distro_build}%{?stable_rctag}%{?dist}%{?buildid}
>
> %else
>
> @@ -168,7 +169,7 @@ Summary: The Linux kernel
> %define rctag .rc0
> %endif
> %endif
> -%define pkg_release 0.%{distro_build}%{?rctag}%{?gittag}%{?buildid}%{?dist}
> +%define pkg_release 0.%{distro_build}%{?rctag}%{?gittag}%{?dist}%{?buildid}
>
> %endif
>
> --
> 1.6.2.5
Could you indicate how emails regarding RHEL5 & RHEL6 kernel Makefile
and spec files (and starting with "internal:") are appropriate for
fedora-kernel development lists please.
I believe patches aimed at supporting internal build systems are not
appropriate for Fedora. I thought you guys were moving to Koji for
RHEL6 anyway?
Thanks
--
Christopher Brown
___
Fedora-kernel-list mailing list
Fedora-kernel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: Compiling kernel-2.6.30.5-43.fc11.src.rpm
2009/9/8 Markus Kesaromous : > > > > >> Date: Mon, 7 Sep 2009 18:17:38 -0400 >> From: jwbo...@gmail.com >> To: remotes...@live.com >> CC: fedora-kernel-list@redhat.com >> Subject: Re: Compiling kernel-2.6.30.5-43.fc11.src.rpm >> >> On Mon, Sep 07, 2009 at 02:27:24PM -0700, Markus Kesaromous wrote: >>> >>>Still not fixed: >>> >>>arch/x86/kernel/pvclock.c:63:7: warning: "__x86_64__" is not defined >> >> Please stop posting such messages here. >> >> josh > > Why? > What gives you the right to say what gets posted or does not get posted here > ? > > This is the fedora kernel list. I posted an issue with the latest fedora > kernel source. No, you didn't. The latest fedora kernel source is found in rawhide. > If you have a problem with that, I strongly encourage you to unsubscribe from > this list. The problem Markus is that you have already had your query responded to and it took me a very small amount of time to discover the problem was fixed in 2.6.31. Messages like the ones above detract from people's time spent developing the kernel and as such you were asked to not post messages of this nature. Please respect that - contributions such as patches to enable the kernel to build are most welcome however. Regards -- Christopher Brown ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: Compiling kernel-2.6.30.5-43.fc11.src.rpm
2009/9/7 Markus Kesaromous : > > Still not fixed: > > arch/x86/kernel/pvclock.c:63:7: warning: "__x86_64__" is not defined Correct. You will see this in 2.6.31. http://lkml.org/lkml/2009/7/14/164 Regards -- Christopher Brown ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: (no subject)
2009/8/13 Markus Kesaromous : > > >> Date: Thu, 13 Aug 2009 00:01:25 +0100 >> Subject: Re: (no subject) >> From: snecklif...@gmail.com >> To: remotes...@live.com >> >> Hi Markus, >> >> 2009/8/12 Markus Kesaromous : >>> >>> Dear List, >>> I searched the ath9k source directory >>> /usr/src/redhat/BUILD/kernel-2.6.29/linux-2.6.29.i586/drivers/net/wireless/ath9k >>> for any strings that would hint/suggest support for the Atheros 9220/9223 >>> chipset. I saw no such strings. >> >> What strings were you looking for? > > I stated:>> for any strings that would hint/suggest support for the Atheros > 9220/9223 (meaning 9220 or 9223 ala grep '922[0-9]' * (within the ath9k > directory). > >> >>> So, I emailed Atheros.com sales dept. and asked if they intend to provide >>> an open >>> source driver for the AR9000 series chipsets, esp. the AR9220/AR9223. They >>> replied that they already DO support the AR92xx chipset in the ath9k driver. >>> >>> Before I go out and purchase the mini-pci card, is it true that the ath9k >>> driver >>> has ineed been tested to fully support AR9220/AR9223 chipsets?? >> >> Your thought process intrigues me. If you have communication from the >> manufacturer advising it is supported then you have your answer (and a >> waterproof returns policy if they are wrong). > > I have learned never to trust sales people. When it comes to dealing with > online > > merchants, what the sales contact at the manufacturer says will not be > sufficient > reason for return for a full refund, of a device which turns out to be > unsupported. Then why contact them? > My question to you is - why do you have to resort to assuming such a pompous > attitude via questions like "Your thought process intrigues me." I'm afraid this is your interpretation. > There is a fitting description for such attitude, but I will not spam this > mailing list with such a vivid description. Then please reply off-list, as I did. >> Some basic investigation >> on the web will tell you what you need to know: >> >> http://wiki.debian.org/ath9k#supported No really, that's my pleasure. -- Christopher Brown ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: kernel 2.6.29.6-217.2.3.fc11 compile d from source will not boot
2009/8/10 Markus Kesaromous : > > Dear list, > There is something seriously wrong with this kernel release. > It compiles - but will not boot all the way. It hangs somewhere. > I even tried to boot into single user mode. I never get to the shell > prompt when booting in single user mode, nor to the > gnome login banner when letting it boot in multiuser mode. > After some 30-45 minutes I Ctrl-Alt_Del and the kernel > pops the message > > Stopping all md devices > .. > and the pc reboots. > > I did not have this problem with these kernels > 2.6.29.6-213.fc11 > 2.6.29.5-191.fc11 > > Are there others who have tried to build 2.6.29.6-217.2.3.fc11 > from source rpm and configured the kernel in any way before > building? > Did you see any errors when running make modules_install > as I did? Did the resulting kernel boot up all the way? > > If you need more info, please let me know. The main piece of information you appear to have missed off is the modifications you have made in your build. I would suggest the following for further reading: http://fedoraproject.org/wiki/Docs/CustomKernel http://fedoraproject.org/wiki/KernelCommonProblems Regards -- Christopher Brown ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: Switching Fedora to pae kernel by default?
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 ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: Switching Fedora to pae kernel by default?
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 ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: Custom Kernel USB Boot Problem
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 ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: kernel-vanilla builds for 2.6.27-rc1
2008/8/8 Josh Boyer <[EMAIL PROTECTED]>: > On Fri, 2008-08-08 at 00:39 +0100, Christopher Brown wrote: >> 2008/8/7 Josh Boyer <[EMAIL PROTECTED]>: >> > On Mon, 2008-08-04 at 23:01 -0400, Josh Boyer wrote: >> >> http://jwboyer.fedorapeople.org/pub/ >> >> >> >> Let the kernel installs begin. >> >> >> >> Hopefully I didn't fsck something up horridly. If I did, then I'll fix >> >> it for -rc2. >> > >> > Updated to -rc2 builds now. And the kernel-firmware Requires issue >> > should be fixed up thanks to Jarod. >> >> It looks all good from here. I'll be posting a diff of the vanilla and >> ummm ... blueberry ... dmesg in a moment. Any caveats, gotchas, test >> suites? > > As for gotchas, well, it's a -rc2 kernel so be warned. But the same is > true of rawhide in general. > > My current plan is to only do vanilla builds for -rc and final releases, > unless a particular -rc is really badly broken and a git snapshot fixes > quite a bit. A few caveats below. > > The intention isn't to provide an "alternative" kernel. It's more for > those that want to test something and see if it works on vanilla as > opposed to a patched Fedora kernel. That should be quite rare, as the > Fedora kernels are fairly top notch and don't differ much from vanilla > anyway. Then I suppose this begs the question - why aren't we shipping a vanilla kernel to begin with? I'm sure there are excellent answers and I'm aware of some of them already. I do think it would be good to pimp this a bit more and that it could be offered as a viable alternative. Or do I have my head in clouds I don't understand? Probably. > I'm sure some will use it as a "primary" kernel, but they should realize > there is no support for these and the likely response will be "try > rawhide" and/or "please report it to the Linux kernel mailing list". On the contrary would this not bring greater support. At the moment mainline ask people with bugs to test with mainline which your average joe has difficulty with. > Also, due to quota limitations I can really only host one kernel version > at a time. That means as soon as -rc3 comes out, the current builds are > replaced. Understood, but if there was some way to get this added into the official repositories do the Fedora kernel bods see an opportunity? Cheers -- Christopher Brown http://www.chruz.com ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: kernel-vanilla builds for 2.6.27-rc1
2008/8/7 Josh Boyer <[EMAIL PROTECTED]>: > On Mon, 2008-08-04 at 23:01 -0400, Josh Boyer wrote: >> http://jwboyer.fedorapeople.org/pub/ >> >> Let the kernel installs begin. >> >> Hopefully I didn't fsck something up horridly. If I did, then I'll fix >> it for -rc2. > > Updated to -rc2 builds now. And the kernel-firmware Requires issue > should be fixed up thanks to Jarod. It looks all good from here. I'll be posting a diff of the vanilla and ummm ... blueberry ... dmesg in a moment. Any caveats, gotchas, test suites? -- Christopher Brown http://www.chruz.com ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: [PATCH] be less annoying on boot
2008/8/2 Eric Paris <[EMAIL PROTECTED]>: > On Sat, 2008-08-02 at 14:59 +0100, Christopher Brown wrote: >> On Friday 01 August 2008 3:51:05 pm Bill Nottingham wrote: >> > As long as we're printing mostly useless messages on every boot >> > regardless of debug level, make them 5% more amusing. >> >> Sometimes I think a Frankenstein quote more appropriate: > > NAK, does not apply. Yeah, gmail's interface does this fantastic "Watch while I f*** with your coding style" as soon as you hit send. I think its called a WYSIWLLAA editor - What You See Is What Looks Like Ascii Art. It's a sad day when I can't submit a single one-liner -- Christopher Brown http://www.chruz.com ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: [PATCH] be less annoying on boot
On Friday 01 August 2008 3:51:05 pm Bill Nottingham wrote:
> As long as we're printing mostly useless messages on every boot
> regardless of debug level, make them 5% more amusing.
Sometimes I think a Frankenstein quote more appropriate:
--- linux-2.6.26.noarch/arch/x86/kernel/head64.c.foo2008-08-01
15:44:28.0 -0400
+++ linux-2.6.26.noarch/arch/x86/kernel/head64.c2008-08-01
15:46:53.0 -0400
@@ -109,11 +109,11 @@
early_printk("Kernel alive\n");
x86_64_init_pda();
- early_printk("Kernel really alive\n");
+ early_printk("And now, with the world before me, "
"whither should I
bend my steps?\n");
x86_64_start_reservations(real_mode_data);
}
void __init x86_64_start_reservations(char *real_mode_data)
--
Christopher Brown
http://www.chruz.com
___
Fedora-kernel-list mailing list
Fedora-kernel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: When will we stop shipping WLAN improvements ahead of upstream in released Fedora version?
2008/7/5 Thorsten Leemhuis <[EMAIL PROTECTED]>: > Hi all > > John (CCed), I really appreciate your work in the wireless area and would > like to use the opportunity to say "thanks for all you work", as support for > WLAN hardware in the Linux kernel improved a lot in the upstream kernel and > Fedora thx to your (and other linux wireless developers) work over the last > two years. > > > But we now for at least the second time in the past few weeks had/have > a more-than-minor wireless breakage in a Fedora kernel for a released distro > (bug #453390 now; http://lwn.net/Articles/286558/ is discussing the one some > weeks ago; I think there was one more breakage not that long ago, but I > can't remember). I and many users (see for example #453390) got hit by those > problems. That's why I was wondering: what are we at Fedora doing to prevent > similar problems in the future? > > > Three things spring to my mind and I just propose then here for discussion; > maybe something good comes out of it in the end: > > - a karama of "+3" in bodhi seems not enough for a auto-move from testing to > stable (or even worse: straight to stable if enough people tested the kernel > and gave their +1 after the update got filed in bodhi but *before* it > actually hit fedora-testing) if there are no other pressing issues (like > security fixes). The kernel is a to complex beast; more then 3 people should > be needed to give a +1. And a bit of time needs to pass to give enough > people the opportunity to install, test and report problems with new > kernels. For the latest kernel it seems to me that "to less time" really was > the problem, otherwise the problem from #453390 would have been noticed > earlier > > - should we separate security updates and other kernel fixes in a better > way to make sure those "other fixes" get proper testing before they get > send out to the users? > > - John, having all those pending and not-yet-upstream-merged improvements > for wireless hardware in the Fedora kernel was something good in the past > when WLAN support in the kernel was quite bad/incomplete. But the main and > most important bits for proper wireless hardware support seem to be in the > upstream kernel now; sure, there will always be improvements in the queue, > but that's the same in most other linux subsystems with drivers as well. So > I'm wondering: isn't it time now to finally stop shipping all those > wireless-next bits (currently quite some big patches; see: > -rw-rw-r-- 1 thl thl2484 14. Mär 17:06 > linux-2.6-ms-wireless-receiver.patch > -rw-rw-r-- 1 thl thl 39874 4. Jul 22:21 linux-2.6-wireless-fixups.patch > -rw-rw-r-- 1 thl thl 2656652 4. Jul 22:21 linux-2.6-wireless-pending.patch > -rw-rw-r-- 1 thl thl 4165718 4. Jul 22:21 linux-2.6-wireless.patch > ) in released Fedora Version (e.g. 8 and 9 currently) when we start shipping > 2.6.26? Wireless breakage occurs almost exclusively on desktop machines. If a newer kernel breaks, roll back to the old one. I have experienced zero wireless breakage since Fedora 9 was released (this on three separate chipsets) and am happy for development to take place (in this one particular area) ahead of kernel as it is still an area that lags behind a Windows desktop environment. Besides, I'm willing to bet removing the above patches will break even more stuff than the occasional wireless tree pull-age. Regards -- Christopher Brown http://www.chruz.com ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: gspca as part of the rawhide kernel?
2008/7/3 Hans de Goede <[EMAIL PROTECTED]>: > Hi all, > > As some of you know I've been working on improving webcam support under > Fedora, see: > http://fedoraproject.org/wiki/Features/BetterWebcamSupport > http://hansdegoede.livejournal.com/ > > One of the things I've been working on is in beating gspcav2 (a v4l2 port of > gspca) into shape, although I must admit most of the work has been done by > Jean-François Moine, the latest version is available from his mercurial tree > and it has been pulled into the official v4l-dvb tree for wider testing. > Once it has been in the v4l-dvb tree it will make its way into the mainline > hopefuly for 2.6.27, if not then certainly fotr 2.6.28. > > To check it out see: > http://linuxtv.org/hg/~jfrancois/gspca/ > > Some time ago I've already done a review of the gspca_core and there are > some locking issues to solve (I already know how, I just need to code them > out). > > Once this is done I would like to see gspcav2 be added to the Fedora kernel, > as to make the: > http://fedoraproject.org/wiki/Features/BetterWebcamSupport > > Feature a reality (also needs userspace work, I'm on this). > > So my questions are: > 1) would it be acceptable to cary the gspca driver as a patch (only new > files > and makefile / kconfig changes doesn't touch anything else) until it is > merged upstream. Note that this is much needed for wider webcam support > and > that gspca is on its way to the mainline now, and I'll personally will be > working on ironing out any issues upstream may have with gspca as is. > > 2) Assuming the answer to 1 is yes, how do I move forward, can I get be > added > to the kernel package acl, what are the procedures for adding a patch and > building a new kernel, etc? Personally I'd love to see this in rawhide. If you have a patch that applies against the current rawhide kernel then scratch-building one in koji isn't too much of a greater leap. Maybe DaveJ and the other kernel bods would be happier if i's cleanly applying and won't need much maintenance. Just note in the kernel.spec to append a buildid (e.g. gspca) - more info here: http://fedoraproject.org/wiki/Docs/CustomKernel Cheers -- Christopher Brown http://www.chruz.com ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: rawhide & -debug
On 13/02/2008, Dave Jones <[EMAIL PROTECTED]> wrote: > A discussion came up at LCA about the fact that we have debugging > 'always on' in rawhide kernel builds, and that it causes some people > pain, because anyone wanting to do performance testing for eg needs > to rebuild their kernel without all the debugging bits. > > An idea that was tossed around was to do something similar to what > we do in release builds, and offer separate debug/nodebug builds. > But instead of how we do it in releases, do the opposite, and have > a -nodebug build, whilst keeping the regular kernel debug-turned-on > to maximise coverage testing. > > Downside being that we have one extra flavor to build each day. > (more disk space used, more buildsys time etc). > > Another option is that we do something like turning debug on/off > periodically (though this idea wasn't well recieved, unless it > was really easy to determine if a debug-enabled kernel was running. > Some people want to run automated perf-tests) > > comments? I'm a newbie in this but http://fedoraproject.org/wiki/KernelCommonProblems indicates slab debugging can be disabled using: slub_debug=- Is this true and if so does this affect things at all? The barrier to getting a debug variant is pretty low so I'm really not fussed either way. Cheers -- Christopher Brown http://www.chruz.com ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: RFC: Minor specfile rework for rawhide
On 21/01/2008, Adam Jackson <[EMAIL PROTECTED]> wrote: > http://people.freedesktop.org/~ajax/kernel-autopatch.patch > > Based on something I did for the xserver specfile. Essentially this > makes it so you only have to name the patches once, in the order you > want to apply them, which makes it both easier to work with and harder > to forget things. > > I've tried to make this as friendly and robust as possible, including > bailing out appropriately when faced with a bad patch, and explicitly > naming patches that fail to apply right at the end of build output. > Feedback would be appreciated, even if it's of the form "no, that's > gross." Can't speak from an implementation point of view but you must be a mind-reader. Several people will appreciate the thought behind it, myself included. On #fedora-kernel recently: i really find it irritating that i need to edit Patchxx: *and* add an ApplyPatch. * kylem ponders converting the spec file to use quilt. fark not a fan of that either why not j-rod ? I think he meant he's not a fan of editing twice. not that he wasn't a fan of quilt. oh i always forget to do one or the other :\ Cheers! -- Christopher Brown http://www.chruz.com ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Bug triage - next step
Hello Dave, Chuck et al, I'm back from the extended break and intend to review F7 bugs once more with a view to closing those that have not responded to gentle nudging for more info. In general these will have been dormant for 2-3 months. Unless there are any objections I intend to start this process within the next few days. Hopefully then the bug count will rapidly start to look less manic and the important stuff will bubble to the surface a little more clearly. Cheers -- Christopher Brown http://www.chruz.com ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: How to build smp kernel
On 11/11/2007, Feng Xian <[EMAIL PROTECTED]> wrote: > Hi, > > I had a 16-core machine and tried to build a smp version of > linux-2.6.23 kernel. I did the following steps: > > 1. make menuconfig ( actually I didt change the configuration since it > builds SMP support by default) > > 2. make; make modules; make modules_install; make install > > But the final image file is vmlinuz-2.6.23, not vmlinuz-2.6.23smp. Is > this final image a real smp kernel? If not, do i need to apply > patches. Thanks! Multiprocessor support is provided by default - there is no separate smp kernel (from Fedora 7 onwards I think). You should not need to apply additional patches. O/T : I'm back from vacation though extremely jet-lagged. Cheers Chris -- http://www.chruz.com ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Vacation
Hi folks, As per http://fedoraproject.org/wiki/Vacation I'm away for a little under a month from tomorrow, pretty much out of contact. I have been through most of the Fedora 7 kernel bugs and will resume these duties on my return. I hope I have been of some help but for now, Australia awaits! Cheers Chris -- http://www.chruz.com ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
RFE: Switch usbhid.pb_fnmode to 2 for Macbook Pro users
Hello, It would appear Macbook Pro users need to additionally press the fn key to make F1 - F10 work as expected under Linux. Therefore to switch to a vt they have to perform a wierd kind of hand twister to get it to work as it now requires Ctrl+Alt+Fn+F1. Macbook user Alexey Kuznetsov wrote to me and said: To solve this problem i send echo "2" to /sys/module/hid/parameters/pb_fnmode every time on boot. But i this is a good idea to set this feature by default for all fedora 7 users. I solve it by small startup service here is ti: #!/bin/bash # # chkconfig: 12345 90 01 # description: fix apple fn keys . /etc/init.d/functions echo "2">/sys/module/hid/parameters/pb_fnmode action "Starting the Mac Function keys fix:" to which I replied: " ... you can also just add: options usbhid pb_fnmode=2 to modprobe.conf and I think: usbhid.pb_fnmode=2 being added to the kernel parameters as well. I will post an RFE to the fedora-kernel list." Is it possible to enable this by default - the green lizards seem to have done so: https://bugzilla.novell.com/show_bug.cgi?id=220266 Cheers Chris -- http://www.chruz.com ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: IRC.
On 21/09/2007, Dave Jones <[EMAIL PROTECTED]> wrote: > > I've created a #fedora-kernel channel on freenode in response > to the large number of /msg's I continue to get which really > should be going to a wider audience. > > I expect it to be low-traffic, but it may be a worthwhile experiment > to see if it helps any for triage, coordination etc. Is there any value is punting out a message to fedora-test to get more people on the case with triaging? I'm getting to the point now where bugs aren't so old any more therefore people remember why they filed, can still replicate the bug so the process rate is slowing somewhat. When you say /msg do you mean people in IRC or bugzilla emails about bug status changes. Is it worth setting up a bugzilla monitor to show status changes to kernel bugs? Also, is it worth setting mailman to change the reply-to address so it goes to the list rather than the poster a-la -devel and -test? Cheers Chris -- http://www.chruz.com ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: bugzilla triage.
On 29/08/2007, Dave Jones <[EMAIL PROTECTED]> wrote: > > In an attempt to disperse some of the 'triage' type work to volunteers, > I've started a page at http://fedoraproject.org/wiki/KernelBugTriage > with some simple things that people can do to help out. As folks may have noticed I've started on this, specifically those opened against F7 since release. Please let me know if I'm treading on toes or some such. One thing I would like to know whether bugs that are resolved by adding boot flags are to be considered resolved or do they still need to be open. I will add the answer to the triage page on the wiki. Other than that you can expect to see the bug count start to drop quite rapidly now and hopefully the issues that have not been resolved will be more visible and to that end I'm considering a "These are some of the bugs that _really_ need looking at" post once a week or so. Those in favour, speak now. Cheers Chris -- http://www.chruz.com ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
