Re: Sources file audit - 2010-01-05
On Wed, Jan 06, 2010 at 11:38:20AM -0700, Kevin Fenzi wrote:
- BADURL:base-file-name:$PACKAGENAME
This means that the URI provided in the Source(s) line didn't result in
a download of the source. This could be any of: URL changed, version
changed and URL wasn't updated, Site is down, Site is gone, etc.
Also there are a number of packages with incorrect sourceforge links.
(BTW, there are still some packages with ftp://people.redhat.com/
URLs). This could also be a transitory network failure from my checking
host or the project hosting.
davej:BADURL:midisport-firmware-1.2.tar.gz:midisport-firmware
so %{version} in the Source: line isn't allowed any more ?
Dave
--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Sources file audit - 2010-01-05
On Wed, Jan 06, 2010 at 09:59:06PM +0200, Kalev Lember wrote:
On 01/06/2010 09:24 PM, Dave Jones wrote:
On Wed, Jan 06, 2010 at 11:38:20AM -0700, Kevin Fenzi wrote:
- BADURL:base-file-name:$PACKAGENAME
This means that the URI provided in the Source(s) line didn't result in
a download of the source. This could be any of: URL changed, version
changed and URL wasn't updated, Site is down, Site is gone, etc.
Also there are a number of packages with incorrect sourceforge links.
(BTW, there are still some packages with ftp://people.redhat.com/
URLs). This could also be a transitory network failure from my checking
host or the project hosting.
davej:BADURL:midisport-firmware-1.2.tar.gz:midisport-firmware
so %{version} in the Source: line isn't allowed any more ?
See the logs [1], what really happened was that sourceforge replied
with 504 Gateway Time-out.
[1]
http://www.scrye.com/~kevin/fedora/sourcecheck/sourcecheck-20100105/midisport-firmware-dl.txt
Looks like some genius at sourceforge moved stuff to a different host, with a
different dir structure.
If you go to the project pages, you see all the tarballs have been moved.
Before..
Source0:
http://download.sourceforge.net/usb-midi-fw/midisport-firmware-%{version}.tar.gz
After
Source0:
http://downloads.sourceforge.net/project/usb-midi-fw/midisport-firmware/%{version}.tar.gz
sigh.
Dave
--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: dist-git proof of concept phase 1 complete
On Mon, Dec 14, 2009 at 08:22:09PM -0800, Jesse Keating wrote: On Mon, 2009-12-14 at 19:21 -0800, Jesse Keating wrote: git clone git://publictest5.fedoraproject.org/git/pkgs/kernel This was the wrong path: git clone git://publictest5.fedoraproject.org/pkgs/kernel I'm on vacation, but I couldn't resist taking a look-see. Something looks odd. It appears to have collapsed every CVS branch onto the master git branch instead of making a new branch for each CVS branch. Running git log on the master branch should only show the commits that happened to HEAD in cvs. This might not matter much for most packages, but the kernel does have a lot of (mostly useless) branches, so the history looks a bit messy. Dave -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: dist-git proof of concept phase 1 complete
On Tue, Dec 15, 2009 at 12:54:44PM -0800, Jesse Keating wrote: On Tue, 2009-12-15 at 15:49 -0500, Dave Jones wrote: I'm on vacation, but I couldn't resist taking a look-see. Something looks odd. It appears to have collapsed every CVS branch onto the master git branch instead of making a new branch for each CVS branch. Running git log on the master branch should only show the commits that happened to HEAD in cvs. This might not matter much for most packages, but the kernel does have a lot of (mostly useless) branches, so the history looks a bit messy. That's strange, when I clone and do a git branch -r, I see 142 branches, lots of those private-* branches. Right I see those too. But locally, there's just '* master', and all the private-* commits seem to have been squashed onto that. What things that were CVS branches are you seeing on origin/master ? run git log, and see all the myoung commits for example. Dave -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
memset bugs.
There's some obvious bugs below in a bunch of packages. The 2nd and 3rd arguments to memset calls are the wrong way around. I found these after grepping through a make prep'd devel/ tree. 15 hits out of 100G of source code isn't that bad, but we can do better! Dave Checking ./afflib/afflib-3.5.2/lib/s3_glue.cpp Found memset with swapped arguments. 303:memset(b64str,sizeof(b64str),0); Checking ./afflib/afflib-3.5.2/lib/vnode_s3.cpp Found memset with swapped arguments. 205:memset(segname,segname_len,0); Checking ./afflib/afflib-3.5.2/lib/crypto.cpp Found memset with swapped arguments. 975:memset(decrypted,total_encrypted_bytes,0); // overwrite our temp buffer Checking ./panoglview/panoglview-0.2.2/src/panocanvas.cpp Found memset with swapped arguments. 160: memset(tmp,m_maxsize*m_maxsize,0); Checking ./condor/condor-7.2.4/src/condor_c++_util/read_user_log_state.cpp Found memset with swapped arguments. 497:memset( istate-m_base_path, sizeof(istate-m_base_path), 0 ); Checking ./milkytracker/milkytracker-0.90.80/src/milkyplay/LoaderPSM.cpp Found memset with swapped arguments. 999:memset(packed,size-4+5,0); Checking ./sim/sim/sim/sockfactory.cpp Found memset with swapped arguments. 546:memset(addr, sizeof(addr), 0); Checking ./commoncpp2/commoncpp2-1.7.3/src/thread.cpp Found memset with swapped arguments. 525:memset(act, sizeof(act), 0); Checking ./commoncpp2/commoncpp2-1.7.3/src/socket.cpp Found memset with swapped arguments. 1571: memset(group, sizeof(group), 0); Checking ./celestia/celestia-1.5.1/src/celestia/winmain.cpp Found memset with swapped arguments. 2181:memset(info, sizeof(info), 0); Checking ./scummvm/scummvm-0.13.1/engines/tinsel/scene.cpp Found memset with swapped arguments. 132:memset(tempStruc, sizeof(SCENE_STRUC), 0); Checking ./aqsis/aqsis-1.6.0/tools/displays/sdcWin32/d_sdcWin32.cpp Found memset with swapped arguments. 250:memset(g_Data, sizeof(AppData), 0); Checking ./aqsis/aqsis-1.6.0/tools/displays/sdcBMP/d_sdcBMP.cpp Found memset with swapped arguments. 172:memset(g_Data, sizeof(AppData), 0); Checking ./arm4/arm4-0.8.2/src/libarm4db/berkeleydb/BerkeleyDB_report.cpp Found memset with swapped arguments. 1603: memset (summary_ptr, sizeof (*summary_ptr), 0); Checking ./arm4/arm4-0.8.2/src/libarm4db/Arm4dbDaemonSharedMemory.cpp Found memset with swapped arguments. 558:memset (stats_ptr, sizeof (*stats_ptr), 0); -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: memset bugs.
On Wed, Nov 25, 2009 at 01:58:38PM -0500, Jakub Jelinek wrote: On Wed, Nov 25, 2009 at 01:43:13PM -0500, Dave Jones wrote: There's some obvious bugs below in a bunch of packages. The 2nd and 3rd arguments to memset calls are the wrong way around. I found these after grepping through a make prep'd devel/ tree. 15 hits out of 100G of source code isn't that bad, but we can do better! glibc headers warn about this (when -D_FORTIFY_SOURCE=2), so a faster way would be just grep through all packages' build.log files (preferrably on the box where they are stored to avoid downloading it all). Can we make it fail the build instead of warning ? A zero sized memset is always a bug. Dave -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Promoting i386 version over x86_64?
On Thu, Nov 19, 2009 at 04:13:39PM -0500, Casey Dahlin wrote: Most recent 32-bit Intels can address 32GB of system memory. It might be possible, but it's really not a good idea. Even 16GB is pushing it. At that point, your lower 1GB of memory is so full of page structs, that quickly invoking the oom-killer is inevitable. Dave -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: drop SECURITY_FILE_CAPABILITIES? (fwd)
On Wed, Nov 11, 2009 at 09:52:02AM -0500, Adam Jackson wrote: On Tue, 2009-11-10 at 18:00 -0500, Dave Jones wrote: On Wed, Nov 11, 2009 at 09:56:57AM +1100, James Morris wrote: How might this affect the Fedora kernel? We set it =y, so it wouldn't affect us if I understand correctly. Also, I'm not sure that anything in userspace is actually using this feature yet anyway. google codesearch to the rescue: http://google.com/codesearch?hl=ensa=Nfilter=0q=prctl.*PR_CAPBSET_DROP afaik, that prctl is available regardless of the option being set. I meant I don't think anything we ship is using the file capabilities, which is a way of marking executable files with the caps they need instead of having them be setuid. (I'm not even sure what tool we would use to set those capabilities, or if we ship it) Dave ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: drop SECURITY_FILE_CAPABILITIES? (fwd)
On Wed, Nov 11, 2009 at 09:56:57AM +1100, James Morris wrote: How might this affect the Fedora kernel? We set it =y, so it wouldn't affect us if I understand correctly. Also, I'm not sure that anything in userspace is actually using this feature yet anyway. Dave ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: Should installkernel be passing --dracut to new-kernel-pkg?
On Thu, Oct 22, 2009 at 08:48:03AM -0400, Stephen Smalley wrote: Hi, /sbin/installkernel doesn't pass --dracut to /sbin/new-kernel-pkg, so a make install from a kernel.org kernel tree tries to invoke /sbin/mkinitrd rather than dracut. Is that intentional? Also, any ideas on why a dracut-generated initramfs image generated for a kernel.org kernel tree would be so much larger than the Fedora kernel one (same .config)? 12M /boot/initramfs-2.6.31.1-56.fc12.x86_64.img 82M /boot/initramfs-2.6.32-rc2.img Do you have CONFIG_DEBUG_INFO set ? The kernel specfile strips the debug info out to separate debuginfo packages. If you build it by hand, that doesn't happen, so you get all the symbols etc attached to every module in your initramfs. Dave -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: [PATCH] update f12 fcoe related kernel code
On Tue, Sep 15, 2009 at 01:05:53PM -0500, Mike Christie wrote: Hi, Sorry for the large patch. I was not sure how I should do this. I am trying to update the fcoe related (fcoe, libfc, ixgbe, fnic and dcb) kernel code that is going into fedora 12. The attached patch updates the fedora 12 kernel to what is in the SCSI maintainer and network maintainer's trees for 2.6.32-rc1. For scsi this is the scsi-misc tree http://git.kernel.org/?p=linux/kernel/git/jejb/scsi-misc-2.6.git;a=summary and for networking this is the net-next tree http://git.kernel.org/?p=linux/kernel/git/davem/net-next-2.6.git;a=summary. This scares me. We're shipping 2.6.31 because we can't justify the risk of shipping rc code in a final release. With huge amounts of change like this, we're essentially doing the same thing. What justification is there for this ? (If the answer involves the acronym 'RHEL' there are better ways than shoving it into Fedora at the last minute) Dave ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: [PATCH 3/3] dracut has initrd-generic-version instead of initrd-version (#519185)
On Fri, Sep 04, 2009 at 10:53:19AM -0400, Jon Masters wrote: The problem I have is that some folks want to include additional drivers into their initrd. examples please. Dave -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: clang static analyzer: use it!
On Fri, Sep 04, 2009 at 08:30:14AM +0200, Jim Meyering wrote: Quick summary: use this tool: http://clang-analyzer.llvm.org/ If you're not using its scan-build tool, then start. Right now. Really. It's that good. Recently I've run it on a variety of packages, from coreutils (of course) to libvirt -- and libxml2 on request by the maintainer. To use them, build the tools described here, from source: (currently, there is no fedora package, afaik) http://clang-analyzer.llvm.org/ I ran them like this for libxml2: scan-build -o clang ./autogen.sh scan-build -o clang make This does look neat. When I tried it though, I ended up with .. scan-build: Removing directory '/mnt/data/src/git-trees/kernel/linux-2.6/clang/2009-09-04-1' because it contains no reports. While I'd love to believe the kernel is bug free, I have a hard time convincing myself that clang is doing the right thing. I added a path to the clang bin/ dir, and copied scan-build to my ~/bin and then ran with 'make defconfig ; scan-build -o clang make bzImage' Am I missing something obvious ? Dave -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: clang static analyzer: use it!
On Fri, Sep 04, 2009 at 01:15:40PM -0400, Jeff Moyer wrote: I added a path to the clang bin/ dir, and copied scan-build to my ~/bin and then ran with 'make defconfig ; scan-build -o clang make bzImage' Am I missing something obvious ? It may be that the kernel defines $(CC) to gcc, at which point you lose. Try doing a make with CC=/path/to/ccc-analyzer. That was exactly it. Nice. Dave -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: CONFIG_CC_OPTIMIZE_FOR_SIZE?
On Thu, Sep 03, 2009 at 01:01:55PM -0300, Arnaldo Carvalho de Melo wrote: Em Thu, Sep 03, 2009 at 11:48:42AM -0400, Aristeu Rozanski escreveu: Hi, does anyone know why CONFIG_CC_OPTIMIZE_FOR_SIZE is enabled in fedora kernel? I thought that option was useful for embedded systems only. IIRC because it makes the kernel faster :-) The reduced icache pressure makes it a win. As a bonus some non-performance-sensitive code (like the acpi interpretor) gets a _lot_ smaller on-disk. Dave ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: rawhide report: 20090902 changes
On Wed, Sep 02, 2009 at 08:44:00AM -0400, James Laska wrote: top post Heads up for anyone installing from rawhide today. A fix didn't land in time for anaconda-12.19 (see bug#520791), I've built an updates.img (http://jlaska.fedorapeople.org/520791-updates.img) for anyone interested in testing the installer today. Information on using an updates.img with anaconda is available at http://fedoraproject.org/wiki/Anaconda/Updates#Updates_from_the_Network. Thanks, James Even with this, it tracebacked during the tz selection screen for me on 2 separate installs.. https://bugzilla.redhat.com/show_bug.cgi?id=520826 kickstart installs seem to be the path to success for todays rawhide. Dave -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Policy on removing %changelog entries?
On Thu, Aug 27, 2009 at 01:36:26PM -0400, Tom spot Callaway wrote: On 08/27/2009 01:21 PM, Jeff Garzik wrote: What is the policy regarding deletion of individual entries in the middle of %changelog? A developer added a %changelog entry to each of my cloud daemons' packages, on the main fedora-cvs devel branch of each. Then, a day or so later, after other %changelog entries had been added by me... the same developer removed one %changelog entry from the middle of %changelog, and added another entry at the top. I thought the policy was to never delete %changelog entries, ever? Yeah, you really shouldn't delete %changelog entries. The only reasonable exception is that if you wanted to archive really old entries to keep the spec file small, I think that has been done in the past. We generally cull the kernel.spec once per release, because that thing grows to ridiculous length. For any kind of archaeology, hitting up the cvs server will tell you a lot more than the specfile will anyway. Dave -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Kernel 2.6.29 for F10
On Tue, Aug 18, 2009 at 10:13:10AM -0500, Joe Nall wrote: On Aug 18, 2009, at 5:16 AM, Reindl Harald wrote: Hi Is there a reason that since longer time 2.6.29-Kernels for Fedora 10 landing in Updates-testing followed with 2.6.27-Builds in the meantime? On machines with kmods this is a real problem because yum detetects the kmod for 2.6.27-Build and wants to install the 2.6.27 kernel which conflicts with the installed one I use the 2.6.29 since months in the meantime, F11 has it since the release and i do not realize why F10 does not get him I tried to ask this on the fedora kernel list and the moderator never approved the message. Odd, I don't recall seeing it, and there's no non-spam messages in the queue right now. I too would like to see F10 move up to 2.6.29+ prior to end-of-life. In days of old, we were able to get rebases out pretty quickly after their upstream release. These days, we're hindered by the kernel modesetting stuff we're carrying. It's closely tied to the userspace X drivers, and isn't easy to retrofit to a different kernel. One of the reasons we haven't pushed them as proper updates is that getting the regressions fixed is pretty time consuming, and the limited X/KMS manpower we have is better focused on making the F12 stuff work right, and getting it upstream. I really can't wait for the day that it all gets upstream, and we can get back to the old routine of rebasing. Until then, we're kinda stuck. Dave -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Recompile kernel without SMP
On Mon, Aug 17, 2009 at 08:17:29PM -0400, Paul Grinberg wrote: Josh, I have a good reason for that. I use Cisco VPN client for Linux, and it does not work with SMP kernel. Have you tried the vpnc package ? The binary cisco module has an hurrendous track record of problems with the Fedora kernel, as it seemingly makes assumptions about networking internals that constantly change upstream, leading to all sorts of horrible corruption bugs. vpnc isn't perfect, but for many cisco setups, it's adequate, and does all the complicated stuff in userspace. Dave ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: Annoying kmemleak scans
On Tue, Aug 11, 2009 at 04:53:54PM +0200, Fabian Deutsch wrote: Hello. Starting with F11 kmemleak is part of the kernel huh? It's never been on in F11. In fact, the code isn't even present as an option there. (It's a post 2.6.30 feature) In rawhide, it was switched on for about a week a month or so back, and turned off because of the number of false positives being too high to make it useful. It might come back on for a short time periodically in rawhide, but generally, it's off. Dave -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Announcing 11 packages as orphaned
On Fri, Jul 24, 2009 at 04:41:46AM +0530, Rahul Sundaram wrote: On 07/24/2009 04:37 AM, Michał Bentkowski wrote: Hi, due to lack of time and losing some enthusiasm, I want to orphan following packages: aria2 -- High speed download utility with resuming and segmented downloading cowsay -- Configurable speaking/thinking cow Taken these two. Co-maintainers welcome. Thank you for all the time you spend on maintaining these packages and good luck. I'm glad someone picked up cowsay. It's critical to kernel development. Dave -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: [PATCH] build a 'full' package on i686
On Mon, Jul 20, 2009 at 10:12:06AM -0400, Bill Nottingham wrote: Dave Jones (da...@redhat.com) said: +# We only build -PAE on 686. %ifarch i686 -%define with_up 0 %define with_pae 1 %else %define with_pae 0 The naming of 'with_up' is subtle here. With this change, we'll try building a '686' kernel as well as a '686-PAE'. That was the intent, as the i586 package would be going away. Oh, I thought that proposal got shot down. We're really dropping support for all those old systems? I'm ok with it if it's been approved, but want to be sure before I start gutting the kernel of 586isms. Dave ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: [PATCH] build a 'full' package on i686
On Fri, Jul 17, 2009 at 01:01:54PM -0400, Bill Nottingham wrote: This is needed for the i686-by-default feature. Bill Index: kernel.spec === RCS file: /cvs/extras/rpms/kernel/devel/kernel.spec,v retrieving revision 1.1634 diff -u -r1.1634 kernel.spec --- kernel.spec 17 Jul 2009 02:07:24 - 1.1634 +++ kernel.spec 17 Jul 2009 17:01:15 - @@ -195,9 +195,8 @@ %endif %define debuginfodir /usr/lib/debug -# We only build -PAE for 686 as of Fedora 11. +# We only build -PAE on 686. %ifarch i686 -%define with_up 0 %define with_pae 1 %else %define with_pae 0 The naming of 'with_up' is subtle here. With this change, we'll try building a '686' kernel as well as a '686-PAE'. (which no longer exists, in favour of using the 586 kernel) Dave ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: Fw: Kernel Loading Sequence
On Sun, Jul 12, 2009 at 01:43:36PM +0200, drago01 wrote: On Sun, Jul 12, 2009 at 1:32 PM, Ahmad Al-Yamanahmad221...@yahoo.com wrote: Thank you, I adjusted the config file as you recommended and the messages are gone. Where should I report this lockdep? Depends on which kernel / patches do you use. If it is a vanilla tarball then upstream (lkml / bugzilla.kernel.org) if you are using the fedora kernel bugzilla.redhat.com It's already fixed in 2.6.31rc2 Fedora 11 will pick it up when we rebase, it's not a critical patch. Rawhide is already fixed. Dave ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: rawhide report: 20090705 changes
On Sun, Jul 05, 2009 at 11:21:58AM +, Rawhide Report wrote: kernel-2.6.31-0.42.rc2.fc12 --- * Sat Jul 04 2009 Chuck Ebbert cebb...@redhat.com - 2.6.31-rc1-git11 * Sat Jul 04 2009 Dave Jones da...@redhat.com 2.6.31-0.42.rc2 - 2.6.31-rc2 * Fri Jul 03 2009 Hans de Goede hdego...@redhat.com - Disable v4l1 ov511 and quickcam_messenger drivers (obsoleted by v4l2 gspca subdrivers) Why is the changelog out of order in the rawhide report? It's the right way around in CVS. Dave -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: more debugging enabled in rawhide kernels.
On Thu, Jun 25, 2009 at 04:53:27PM +0100, Richard W.M. Jones wrote: On Wed, Jun 24, 2009 at 08:08:40PM -0400, Dave Jones wrote: In tomorrows rawhide kernel, I've enabled a debugging option called kmemleak. As the name suggests, this tracks memory allocations, and prints backtraces in cases where the memory is believed to be lost. As a general comment, I see many backtraces when I run the libguestfs testsuite. Most are harmless, in that they don't appear to affect the running of programs, so I don't report them. But is it helpful to report these? If so how - open BZs for each variation that I see? Everything I've seen so far looks like a false positive. The next build should reduce the number of these (hopefully dramatically). So for now, just hold off on filing anything. Dave -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Changing the default 32-bit x86 arch for Fedora 12 (#2)
On Sun, Jun 21, 2009 at 11:24:35PM +0930, Glen Turner wrote: F12 x86 will not work on i586 (or i686 without CMOV) Intel Pentium Intel Pentium Pro VIA Cyrix III VIA C3 and C3-M (Samuel 2) VIA C3 and C3-M (Ezra) VIA C3 and C3-M (Ezra-T) VIA Eden ESP (Samuel 2) .. Although this is the best I could do, the VIA situation is complex and errors in the above would not shock me. The original Samuel won't work either. Other than this omission, your table looks correct to me. There's also the AMD K5, K6, K6-2, K6-3 that won't work. And all the older Cyrix 6x86/MX/MII/MediaGX CPUs. (Though those things sucked even in 1990's, and I doubt they've improved with age) Dave -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Why do we need FC version attached to the package name?
On Sun, Jun 21, 2009 at 04:56:07PM -0600, Nathanael D. Noblet wrote: I *wish* it made a difference. I did an upgrade am an left with a host of fc10 packages because the fc11 ones weren't considered newer. For example people with updates-testing enabled on fc10 got a non-upgraded yum because the versions were the same (except for fc10/fc11) and it stopped working because python went from 2.5 to 2.6. That's messed up. We used to check just before release time that this situation never occured. It should probably be added to the rel-eng release checklist if it isn't there already. Dave -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Orphaned packages fxload, unison*
On Fri, Jun 19, 2009 at 08:37:40PM -0600, Stephen Warren wrote: I've orphaned the fxload, unison213, unison227 packages. unison* have reverted ownership to gemi. fxload now has no maintainer. Unfortunately, with a young child, busy job, and the fact I switched my PC to Ubuntu, I'm not able to maintain these anymore. All of these packages are very low maintenance; since the initial creation, about the only activity has been mass rebuilds. fxload one of my packages (midisport-firmware) depends on this, so I'll take this one. Dave -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Changing the default 32-bit x86 arch for Fedora 12
On Mon, Jun 15, 2009 at 01:53:13PM -0400, Bill Nottingham wrote: Way back when in February [1], FESCo decided that for Fedora 11, i586 would be the default architecture, and for Fedora 12, it would be some variant of i686. It's time to follow through on that action item. I've submitted https://fedoraproject.org/wiki/Features/F12X86Support. It defines the default arch as i686 + SSE2. Why? - Faster and more consistent FP math by using SSE2 registers - Allows for autovectorization by GCC where necessary - More clearly delineates our support set of targets, sticking true to forwards innovation, not necessarily legacy support What CPUs do we lose that F11 supports? - Intel i586 (all) judging by the number of 586 users who register with smolt (less than 0.1% our entire userbase), not that big a deal. - Intel Pentium Pro - Intel Pentium II - Intel Pentium III - 32-bit AMD Athlon These are more of a concern. It's difficult to tell from smolt just how big a deal these are. P3 Athlon especially. I poked Mike privately in the hope that we're gathering enough of /proc/cpuinfo that we can perhaps get some info on how much our userbase we'd be shutting off. I still have two machines that would be affected (one in actual production use as a backup server, the other just a testbox which is tbh rarely powered on) and I'm not even a good representation of our userbase (I ditched all my ancient junk a while back). - VIA C3 Some of the later C3's have SSE2, so wouldn't be affected. - AMD Geode - Transmeta Crusoe Running the shiny latest bits on these CPUs means you're already used to living with pain, so a secondary arch seems like the way forward. Does this lose the PAE/non-PAE kernel split? - Alas, no. Will a Fedora rebuilt in this manner work on ... - OLPC 1.0? No. - OLPC 1.5? Yes. - Atom? Yes. A seconday arch could be done for these older CPUs, if someone is interested enough. Comments? Flames? Predictions of doom? If we 2nd-arch these, I'm wondering if we should still do the kernel builds from the main package. If it's a significant number of users, we're going to end up with the bug reports anyway so it might as well be something we know we built etc.. Dave -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: What I HATE about F11
On Sun, Jun 14, 2009 at 09:57:56PM -0500, Mike McGrath wrote: On Sun, 14 Jun 2009, Mike McGrath wrote: On Mon, 15 Jun 2009, Lennart Poettering wrote: On Mon, 15.06.09 09:15, James Morris (jmor...@namei.org) wrote: On Sun, 14 Jun 2009, Lennart Poettering wrote: much broken. It's a bit like SELinux: it's one of the first features most people disable. False. Most people leave SELinux enabled, according to the smolt stats which have been collecting since the F8 era. Are you speaking of the same smolt that lists es1371 as most popular sound card? i.e. a sound card that has been out of production since about 10 years now? Somehow I have serious doubts about the validity of the smolt data. Based on actual data research or your gut? Sidenote on this specific device, seems vmware emulates it so we should probably continue to support it :) The percentage column seems odd to me. Only 6% of users have the most popular sound device? I'm also surprised that the majority of our users that submit smolt data don't seem have any sound device at all. I always expected the server/desktop balance to be quite heavily skewed towards desktop. Dave -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: ia64 no longer should set CONFIG_SYSFS_DEPRECATED=y
On Wed, Apr 22, 2009 at 04:33:22PM -0400, Doug Chapman wrote: Back in the F9 timeframe we had recommended that CONFIG_SYSFS_DEPRECATED=y be set for the ia64 config. It appears that recent anaconda changes no longer work at all with that set. Can we get this removed? It was set only for ia64 so it will have no affect on other arches. Done. Dave ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: [PATCH] FC11: fix rh#491625 (Unable to run RHEL-5 Xen within KVM guest)
On Wed, Apr 08, 2009 at 07:00:15PM -0300, Marcelo Tosatti wrote: Following adds a fix for $subject. Please review. Looks fine to me, as long as it's been tested. Don't have commit access yet so unable to commit myself. https://fedoraproject.org/wiki/Kernel#Contributing_to_the_Fedora_kernel has all the details. We can hook you up. Dave ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: Alpha platform support for kernel package (WAS: Re: [pkgdb] kernel: oliver has requested commit)
On Wed, Mar 11, 2009 at 09:52:44AM +0100, Oliver Falk wrote: Oliver Falk wrote: Hi! Changed the subject, as happens that I oversee the mails :-( And this subject is more descriptive, isn't it? Kyle McMartin wrote: [ ... ] This all looks fine to me. May I interpret this as a *GO*? :-) Sorry to have been so blunt, but I'm fairly new to Fedora, so I didn't know you were actually working on stuff, and not just someone asking for random commit access. Don't worry. I didn't get this wrong. I can understand you where worrying. If I'd be in your position, I would react differently. I wouldn't worry too much about the linux-2.6- namespace for patches, I'd prefer if they were just alpha-$patch.patch. davej, thoughts? Whatever you prefer. Let me know, so I start working on this today... Did I miss the answer to my mail!? Sorry, I was on vacation, and it fell off my radar when I got back. Looked ok to commit to me though iirc. I've no really preference on patch naming. If you want to do alpha-*, go ahead. but don't feel that you have to. Dave -- http://www.codemonkey.org.uk ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: [pkgdb] kernel: oliver has requested commit
On Thu, Feb 26, 2009 at 11:46:08AM -0600, Jason L Tibbitts III wrote: KM == Kyle McMartin k...@infradead.org writes: KM Uh, who are you again? Oliver Falk, works on the Alpha port if I'm not mistaken. I'm not averse to adding him to committers, but I'd like to see the patches go by fedora-kernel-list first. Dave -- http://www.codemonkey.org.uk ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: Module request: IB700_WDT (IB700 watchdog timer)
On Wed, Feb 25, 2009 at 07:53:08PM +, Richard W.M. Jones wrote: On Wed, Feb 25, 2009 at 01:19:21PM -0500, Dave Jones wrote: On Wed, Feb 25, 2009 at 04:13:22PM +, Richard W.M. Jones wrote: I assume this is the right place to request drivers for the Fedora kernel? I'd like to request that the in-tree IB700 watchdog driver be enabled. The config option is IB700_WDT. looks like it already is ? $ grep IB700 config-* config-generic:CONFIG_IB700_WDT=m I don't understand the way the config files get generated fully, but in current Rawhide CVS I see: $ grep IB700 config* config-generic:# CONFIG_IB700_WDT is not set config-x86-generic:CONFIG_IB700_WDT=m I replied to your mail before I noticed another mail that showed Kyle turned it on earlier today. He added it to config-generic, which is what my grep turned up. I moved it to x86-generic, as it seems pointless turning it on on other architectures given it's for a SBC. The driver doesn't seem to be built even on x86, eg in this build from today: Yeah, no builds have been done today yet. It'll be in the next one that goes out. Dave -- http://www.codemonkey.org.uk ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: arch fun.
On Fri, Feb 06, 2009 at 06:07:13AM -0500, Prarit Bhargava wrote: Dave Jones wrote: 2. Will we eventually rename kernel-PAE.686 to kernel.686? I don't think we can, otherwise someone with non-PAE 686's who does an update will suddenly find themselves unable to boot. Hi Dave, I was thinking about this for a little while. Can't we do this instead: 1. move kernel-PAE.686 config options to kernel.686 (I'm going to refer to this as the new kernel.686) 2. kill kernel-PAE.686 3. modify the spec file for the new kernel.686 to obsolete kernel-PAE.686 ? I'm probably missing something obvious but having PAE in there seems strange to me. It's still the same upgrade problem. Someone will be going from 'kernel' with no PAE to 'kernel' with PAE, and on a CPU without PAE, that means they can't boot any more. In that situation they need to go 'kernel'(i686) to 'kernel'(i586) which aparently the tools already handle. Dave -- http://www.codemonkey.org.uk ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: arch fun.
On Fri, Feb 06, 2009 at 12:23:51PM -0500, Jon Masters wrote: On Fri, 2009-02-06 at 11:39 -0500, Dave Jones wrote: It's still the same upgrade problem. Someone will be going from 'kernel' with no PAE to 'kernel' with PAE, and on a CPU without PAE, that means they can't boot any more. In that situation they need to go 'kernel'(i686) to 'kernel'(i586) which aparently the tools already handle. I'm missing something... Is there really that much additional work that we can't keep the UP/SMP kernel around for the time being? ?? We haven't shipped a UP x86 kernel in about 3 years. If PAE were default installed in F11 for everyone and it were publicly announced that support for non-PAE was dying in F12 Part of the problem with that idea is that the Pentium M laptops without PAE aren't that old. This might upset quite a few people. Dave -- http://www.codemonkey.org.uk ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: arch fun.
On Fri, Feb 06, 2009 at 12:34:04PM -0500, Prarit Bhargava wrote: Given the other information coming through (about dynamic kernel PAE enable), should we really being doing this right now? it's vaporware. Why not wait for the dynamic PAE stuff to settle upstream and then make the change? no-one seems to actually be doing anything. Then we can properly (IMO) drop kernel-PAE.686 and stick with kernel.686. What happens if we postpone this until F12? I bet nothing will have changed. Dave -- http://www.codemonkey.org.uk ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: arch fun.
On Fri, Feb 06, 2009 at 12:38:56PM -0500, Prarit Bhargava wrote: dynamic PAE ? Uh -- I can see how that is confusing :) Sorry, let me make another attempt at that. What I should have said was that there are patches floating around to make PAE dynamically selectable -- I think the example that was referenced was the smp alternatives code. The idea has been floated, but no patches ever happened afaik. Dave -- http://www.codemonkey.org.uk ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: arch fun.
On Fri, Feb 06, 2009 at 01:01:43PM -0500, Jon Masters wrote: Not quite though from what I hear (trying to reconcile what Thorsten said). But perhaps he was solely complaining that most people would run PAE and thus have to type kmod-crud-PAE. The kmod thing is a non-argument afaics. If you currently use kernel-686, you'll be running kernel-586 in F11, so you have 'kmod-foo' to go with it. If you currently use kernel-686-PAE, you'll be running the _same_ thing in F11. The only possible change, is that with anaconda recognising PAE and installing the PAE kernel by default, more people will be running it. So it's just exposing it to more people. I don't see how this is a problem. said to Prarit that I'd kill off the PAE kernel and find out who complains about having a 32GB i686 non-x86_64 system around...but that's just my Friday sense of humo[u]r. PAE also gets you NX support, so it's not just a 4G thing. (Which means you won't need to run the nasty execshield segment limit hacks -- One more nail in execshields coffin) Dave -- http://www.codemonkey.org.uk ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
arch fun.
As per the discussion in #fedora-meeting today,
we're killing off kernel-i686, and just shipping..
* kernel.i586
* kernel-PAE.686
Patch below seems to dtrt.. comments?
Looking at the generated config files, the biggest difference
seems to be that kernel-PAE enables Xen and all it's related
dependancies.
Dave
Index: Makefile.config
===
RCS file: /cvs/pkgs/rpms/kernel/devel/Makefile.config,v
retrieving revision 1.69
diff -u -p -r1.69 Makefile.config
--- Makefile.config 26 Jan 2009 07:19:13 - 1.69
+++ Makefile.config 5 Feb 2009 20:09:20 -
@@ -6,7 +6,7 @@ CFG = kernel-$(VERSION)
CONFIGFILES= \
$(CFG)-i586.config \
- $(CFG)-i686.config $(CFG)-i686-PAE.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)-arm.config \
@@ -63,9 +63,6 @@ temp-s390-generic: config-s390x temp-gen
temp-ia64-generic: config-ia64-generic temp-generic
perl merge.pl $^ $@
-kernel-$(VERSION)-i686.config: config-i686 temp-x86-generic
- perl merge.pl $^ i386 $@
-
kernel-$(VERSION)-i686-debug.config: config-i686 temp-x86-debug-generic
perl merge.pl $^ i386 $@
Index: config-i586
===
RCS file: /cvs/pkgs/rpms/kernel/devel/config-i586,v
retrieving revision 1.5
diff -u -p -r1.5 config-i586
--- config-i586 14 Feb 2008 19:56:06 - 1.5
+++ config-i586 5 Feb 2009 20:09:20 -
@@ -6,4 +6,3 @@ CONFIG_HIGHMEM4G=y
CONFIG_X86_POWERNOW_K6=m
-# CONFIG_KVM is not set
Index: config-i686
===
RCS file: config-i686
diff -N config-i686
--- config-i686 12 Jul 2007 19:15:37 - 1.1
+++ /dev/null 1 Jan 1970 00:00:00 -
@@ -1,8 +0,0 @@
-CONFIG_M686=y
-# CONFIG_NOHIGHMEM is not set
-CONFIG_HIGHMEM4G=y
-# CONFIG_HIGHMEM64G is not set
-
-CONFIG_CRYPTO_DEV_PADLOCK=m
-CONFIG_CRYPTO_DEV_PADLOCK_AES=m
-CONFIG_CRYPTO_DEV_PADLOCK_SHA=m
Index: config-x86-generic
===
RCS file: /cvs/pkgs/rpms/kernel/devel/config-x86-generic,v
retrieving revision 1.63
diff -u -p -r1.63 config-x86-generic
--- config-x86-generic 30 Jan 2009 00:08:01 - 1.63
+++ config-x86-generic 5 Feb 2009 20:09:20 -
@@ -205,9 +205,9 @@ CONFIG_NVRAM=y
CONFIG_IBM_ASM=m
CONFIG_CRYPTO_AES_586=m
CONFIG_CRYPTO_TWOFISH_586=m
-# CONFIG_CRYPTO_DEV_PADLOCK is not set
-# CONFIG_CRYPTO_DEV_PADLOCK_AES is not set
-# CONFIG_CRYPTO_DEV_PADLOCK_SHA is not set
+CONFIG_CRYPTO_DEV_PADLOCK=m
+CONFIG_CRYPTO_DEV_PADLOCK_AES=m
+CONFIG_CRYPTO_DEV_PADLOCK_SHA=m
CONFIG_GENERIC_ISA_DMA=y
CONFIG_SCHED_SMT=y
Index: kernel.spec
===
RCS file: /cvs/pkgs/rpms/kernel/devel/kernel.spec,v
retrieving revision 1.1263
diff -u -p -r1.1263 kernel.spec
--- kernel.spec 5 Feb 2009 18:55:52 - 1.1263
+++ kernel.spec 5 Feb 2009 20:09:20 -
@@ -241,6 +241,11 @@ Summary: The Linux kernel
%define with_kdump 0
#endif
+# We only build -PAE for 686 as of Fedora 11.
+%ifarch i686
+%define with_up 0
+%endif
+
# don't do debug builds on anything but i686 and x86_64
%ifnarch i686 x86_64
%define with_debug 0
@@ -522,8 +527,7 @@ Source24: config-rhel-generic
Source30: config-x86-generic
Source31: config-i586
-Source32: config-i686
-Source33: config-i686-PAE
+Source32: config-i686-PAE
Source40: config-x86_64-generic
@@ -1477,7 +1481,9 @@ mkdir -p $RPM_BUILD_ROOT/boot
cd linux-%{kversion}.%{_target_cpu}
%if %{with_debug}
+%ifnarch i686
BuildKernel %make_target %kernel_image debug
+%endif
%if %{with_pae}
BuildKernel %make_target %kernel_image PAEdebug
%endif
--
http://www.codemonkey.org.uk
___
Fedora-kernel-list mailing list
Fedora-kernel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: arch fun.
On Thu, Feb 05, 2009 at 03:11:40PM -0500, Dave Jones wrote: As per the discussion in #fedora-meeting today, we're killing off kernel-i686, and just shipping.. * kernel.i586 * kernel-PAE.686 Patch below seems to dtrt.. comments? Looking at the generated config files, the biggest difference seems to be that kernel-PAE enables Xen and all it's related dependancies. Better version of the Makefile.config with changes Josh pointed out.. Dave Index: Makefile.config === RCS file: /cvs/pkgs/rpms/kernel/devel/Makefile.config,v retrieving revision 1.69 diff -u -p -r1.69 Makefile.config --- Makefile.config 26 Jan 2009 07:19:13 - 1.69 +++ Makefile.config 5 Feb 2009 20:27:40 - @@ -5,9 +5,8 @@ CFG= kernel-$(VERSION) CONFIGFILES= \ - $(CFG)-i586.config \ - $(CFG)-i686.config $(CFG)-i686-PAE.config \ - $(CFG)-i686-debug.config $(CFG)-i686-PAEdebug.config \ + $(CFG)-i586.config $(CFG)-i586-debug.config \ + $(CFG)-i686-PAE.config $(CFG)-i686-PAEdebug.config \ $(CFG)-x86_64.config $(CFG)-x86_64-debug.config \ $(CFG)-s390x.config $(CFG)-arm.config \ $(CFG)-ppc.config $(CFG)-ppc-smp.config \ @@ -63,12 +62,6 @@ temp-s390-generic: config-s390x temp-gen temp-ia64-generic: config-ia64-generic temp-generic perl merge.pl $^ $@ -kernel-$(VERSION)-i686.config: config-i686 temp-x86-generic - perl merge.pl $^ i386 $@ - -kernel-$(VERSION)-i686-debug.config: config-i686 temp-x86-debug-generic - perl merge.pl $^ i386 $@ - kernel-$(VERSION)-i686-PAE.config: config-i686-PAE temp-x86-generic perl merge.pl $^ i386 $@ @@ -78,6 +71,9 @@ kernel-$(VERSION)-i686-PAEdebug.config: kernel-$(VERSION)-i586.config: config-i586 temp-x86-generic perl merge.pl $^ i386 $@ +kernel-$(VERSION)-i586-debug.config: config-i586 temp-x86-debug-generic + perl merge.pl $^ i386 $@ + kernel-$(VERSION)-x86_64.config: /dev/null temp-x86_64-generic perl merge.pl $^ x86_64 $@ -- http://www.codemonkey.org.uk ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: arch fun.
On Thu, Feb 05, 2009 at 03:22:55PM -0500, Prarit Bhargava wrote: Two quick questions Dave. 1. This is for F11? yes 2. Will we eventually rename kernel-PAE.686 to kernel.686? I don't think we can, otherwise someone with non-PAE 686's who does an update will suddenly find themselves unable to boot. Dave -- http://www.codemonkey.org.uk ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: arch fun.
On Thu, Feb 05, 2009 at 12:23:07PM -0800, Roland McGrath wrote:
Patch below seems to dtrt.. comments?
Why kill the configs, instead of just changing the spec settings?
@@ -1477,7 +1481,9 @@ mkdir -p $RPM_BUILD_ROOT/boot
cd linux-%{kversion}.%{_target_cpu}
%if %{with_debug}
+%ifnarch i686
BuildKernel %make_target %kernel_image debug
+%endif
%if %{with_pae}
BuildKernel %make_target %kernel_image PAEdebug
%endif
Why not %if !%{with_up} here?
that works too.
Dave
--
http://www.codemonkey.org.uk
___
Fedora-kernel-list mailing list
Fedora-kernel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: Library address randomization
On Mon, Jan 26, 2009 at 12:14:10AM -0300, Ricardo Rolim wrote:
Hi there,
Apparently I'm not getting library address randomization for any
programs (compiled or not as PIE). Whereas the binary itself, stack
and heap are randomly getting their addresses changed from one
execution to the next, the library stands still at a predictable
location. Strangely enough I've got the expected results out of Ubuntu
8.10. Here's one example:
[rica...@localhost ~]$ cat /proc/sys/kernel/randomize_va_space
2
[rica...@localhost ~]$ cat /proc/sys/kernel/exec-shield
1
[rica...@localhost ~]$ echo 'int main(){}' dummy.c
[rica...@localhost ~]$ gcc -fpie -pie -o dummy dummy.c
[rica...@localhost ~]$ ldd dummy
linux-gate.so.1 = (0x0013)
libc.so.6 = /lib/libc.so.6 (0x00133000)
/lib/ld-linux.so.2 (0x0011)
[rica...@localhost ~]$ ldd dummy
linux-gate.so.1 = (0x0013)
libc.so.6 = /lib/libc.so.6 (0x00133000)
/lib/ld-linux.so.2 (0x0011)
What kernel version are you running? Kyle fixed up some
of this code last week.
Dave
--
http://www.codemonkey.org.uk
--
Fedora-security-list mailing list
Fedora-security-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-security-list
Re: Switching Fedora to pae kernel by default?
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-l...@redhat.com Dave -- http://www.codemonkey.org.uk ___ 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?
On Mon, Jan 19, 2009 at 11:24:14AM -0700, Pete Zaitcev wrote: On Mon, 19 Jan 2009 19:31:12 +0200, Avi Kivity a...@redhat.com 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: [zait...@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 ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: [PATCH] build in microcode driver on x86
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 ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: config changes
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 ___ 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
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=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@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: Enabling drivers in staging tree in rawhide
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 ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: /proc/sys/fs/epoll/max_user_instances=128 considered harmful
On Wed, Jan 07, 2009 at 03:18:12PM +, 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 ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: Problem booting F10 from 3ware 9650SE controller
On Mon, Dec 08, 2008 at 11:28:09AM -0700, Ted Sume Nzuonkwelle wrote: Hi, I just installed Fedora 10 on a 9650SE raid controller with a Raid 1 configuration. The installation was successful. I have not been able to boot yet. Looks like initrd cannot access swap event though it loads 3w-9xxx properly. details follow. The first boot attempt complained that the resume device did not exist, so i booted into rescue, but none of the partitions were mounted. Then i booted into rescue again, and mounted /, modified fstab by replacing labels, UUIDs, with corresponding partition names.../dev/sda[1-9]. Then i rebooted into rescue and all partitions were mounted and i was able to chroot /mnt/sysimage, and then regenerated initrd so it picks up changes in fstab. When i try to boot the system again from disk i get the following error. sda: Setting up hotplug Creating block device nodes Creating character device nodes Loading 3w-9xxx module Loading shpchp module Unable to access resume device (/dev/sda2) Creating root device mount: error mounting /dev/root on /sysroot as ext3, No such file or directory sda1 sda2 sda3 sda4 sda5 sda6 sda7 sda8 sda9 --- This was my first attempt at installing and booting from a raid controller. Any thoughts.?? There have been a few similar reports to this in bugzilla. I think mkinitrd isn't waiting long enough for the device to settle before it tries to mount it. Dave -- http://www.codemonkey.org.uk ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: execshield rebase
On Thu, Dec 04, 2008 at 02:05:03PM -0800, Roland McGrath wrote: I've been thinking for a while execshield.patch could be split into two or three cleaner patches. Some of those might even be upstreamable as config options or something. It really isn't that big a patch at this point. I tried back in July when I got the diff down to under a thousand lines. Linus wasn't really enthusiastic. http://www.codemonkey.org.uk/junk/linus-es.txt has the interesting bits.. The get_wchan bit that he mentions definitly should be factored out. It's completely unrelated to the NX-emulation. Dave -- http://www.codemonkey.org.uk ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: Allow debug kernels for ppc64
On Tue, Oct 21, 2008 at 08:57:27AM -0400, Josh Boyer wrote: While I'm certainly not advocating for building them normally, it would be handy to actually be able to build a debug kernel for ppc64 from time to time. I had to make the following changes for this to work (outside of adding ppc64 to the arch list for debug kernels in kernel.spec). Anyone have a problem with me committing this? That bit is fine, as it won't build it without the specfile fragment. If the ppc64 builders weren't so damned slow, I'd have no problem with enabling it along with the x86 ones. Dave -- http://www.codemonkey.org.uk ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
patch naming scheme.
For a while, diffs in the Fedora kernel have followed the form linux-2.6-*.patch Then, we started seeing some git snapshots show up as git-*.diff and lately, everything seems to have gone bananas, with no particular scheme at all.. nvidia-agp.patch, percpu_counter_sum_cleanup.patch, xfs-barrier-fix.patch etc etc. Maybe I'm being overly anal. The linux-2.6- prefix is kind of pointless (given that duh, they're all going to be against Linux 2.6), but it does group things nicely in an ls output if nothing else. So, what are peoples thoughts on this? Dave -- http://www.codemonkey.org.uk ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: patch naming scheme.
On Fri, Oct 10, 2008 at 03:14:42PM -0400, Adam Jackson wrote: In the X server I try to keep the original version the patch was against in the name, to give some idea of how old a patch is. Admittedly this is less useful with the kernel because you guys have ridiculous version numbers, but even just being able to see the difference between linux-2.6.9-foo.patch and linux-2.6.27-bar.patch might be useful. Way back when, we used to do that. But that kind of loses its meaning too. For stuff that's never going upstream, you end up with linux-2.6.5-execshield And for other patches older than 1 version, why aren't they upstream again? Dave -- http://www.codemonkey.org.uk ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: patch naming scheme.
On Fri, Oct 10, 2008 at 05:55:50PM -0400, Jarod Wilson wrote: On Friday 10 October 2008 17:27:00 Chris Snook wrote: Dave Jones wrote: For a while, diffs in the Fedora kernel have followed the form linux-2.6-*.patch Then, we started seeing some git snapshots show up as git-*.diff and lately, everything seems to have gone bananas, with no particular scheme at all.. nvidia-agp.patch, percpu_counter_sum_cleanup.patch, xfs-barrier-fix.patch etc etc. Maybe I'm being overly anal. The linux-2.6- prefix is kind of pointless (given that duh, they're all going to be against Linux 2.6), but it does group things nicely in an ls output if nothing else. So, what are peoples thoughts on this? Dave If we'd prefix them with the source package name, in this case kernel, it would make it a lot easier to find things in /usr/src/redhat/SOURCES when we've got SRPMs from different packages installed. We should probably avoid using names that refer to a specific upstream version, because the name becomes misleading once we rebase. When there's a suitable upstream patch name, like the names Andrew Morton uses in -mm, we should probably use those (perhaps prepended with kernel-) to make it clear what it corresponds to upstream. Yeah, I'd be happy with pkgname-tree id-description.patch, omitting the tree id portion if there isn't one, or some variant thereof. Being able to do an 'ls kernel*.patch' is definitely useful. kernel-* is sacred. Tab completion ftw. :) Dave -- http://www.codemonkey.org.uk ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: patch naming scheme.
On Fri, Oct 10, 2008 at 08:43:34PM -0500, Eric Sandeen wrote: As an aside - but maybe relevant - how much description / lineage / whatever should go into the spec file comments vs. into the TODO file? The TODO is pretty free form, put whatever you want in there. Pointers to upstream discussion (if any exists) is a good start, as is any other info on its upstream progress. The specfile - One liners are fine. Think about the sort of thing that goes in the git shortlog upstream. If bugzillas exist, referencing them with (#123456) at the end seems to be the standard way of mentioning them. I don't want to get beurocratic about all this (hey, it's Fedora, not RHEL :) so I'm not going to be imposing any kind of enforcement on the above. Just go with what feels 'right'. General rule of thumb: Some info is better than no info. Dave -- http://www.codemonkey.org.uk ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: turning on -fno-inline-functions-called-once
On Mon, Oct 06, 2008 at 02:56:04PM -0400, Steve Dickson wrote: A while back, I believe back during the last FUDCon in Raleigh I talked with kylem and davej about turning off the inline-functions-called-once which inlines functions that are only called once. Turning off this optimization would allow SystemTap to work much better, especially in the NFS code... Kyle/Dave (or anybody else) remember if anything came out from that conversation? I forgot all about that conversation. Is there any reason we should not remove this optimization? I'd be really surprised if it's actually even measurable on modern CPUs. Dave -- http://www.codemonkey.org.uk ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: de-modularising for the win!
On Fri, Oct 03, 2008 at 11:25:49AM -0400, Peter Jones wrote: Bill Nottingham wrote: See various and sundry plumber's conf discussions. Comments? (The netfilter stuff needs further investigation.) Also, please add these, since they're nearly always loaded (patch is on top of yours): I think this makes sense to do now as a stop-gap, but one day, I hope we can get to a situation where we do modprobe of such things based on a config file instead of always doing it. Dave -- http://www.codemonkey.org.uk ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: de-modularising for the win!
On Fri, Oct 03, 2008 at 01:25:50PM -0400, Bill Nottingham wrote: Dave Jones ([EMAIL PROTECTED]) said: On Fri, Oct 03, 2008 at 11:25:49AM -0400, Peter Jones wrote: Bill Nottingham wrote: See various and sundry plumber's conf discussions. Comments? (The netfilter stuff needs further investigation.) Also, please add these, since they're nearly always loaded (patch is on top of yours): I think this makes sense to do now as a stop-gap, but one day, I hope we can get to a situation where we do modprobe of such things based on a config file instead of always doing it. Ideally the DM layer would be able to request_module() the map type whenever necessary. Wherever possible, yes that would be even better. Dave -- http://www.codemonkey.org.uk ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: rawhide patches.
On Mon, Sep 29, 2008 at 06:59:00PM +0100, Matthew Garrett wrote: On Mon, Sep 29, 2008 at 10:47:05AM -0700, Roland McGrath wrote: linux-2.6-acpi-video-dos.patch linux-2.6-defaults-acpi-video.patch These are policy decisions. Probably not going usptream. Can they be turned into upstream config options? They're already runtime settable, so it's primarily a convenience thing - they're the sensible defaults given our userland. I think Rolands point was that if we had for eg CONFIG_ACPI_VIDEO_DEFAULT we'd get to carry one less patch. Dave -- http://www.codemonkey.org.uk ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
IA64 ATA patch.
We've had this in Fedora since 2007/02/27
Can anyone recall why? and more importantly, why it isn't upstream?
Dave
--- linux-2.6.20/arch/ia64/kernel/quirks.c 1969-12-31 19:00:00.0
-0500
+++ linux-2.6.20_fix/arch/ia64/kernel/quirks.c 2007-02-13 13:56:34.0
-0500
@@ -0,0 +1,45 @@
+/*
+ * This file contains work-arounds for ia64 platform bugs.
+ */
+#include linux/pci.h
+
+/*
+ * quirk_intel_ide_controller: If an ide/ata controller is
+ * at legacy mode, BIOS might initiates BAR(bar 0~3 and 5)
+ * with incorrect value. This quirk will reset the incorrect
+ * value to 0.
+ */
+static void __devinit quirk_intel_ide_controller(struct pci_dev *dev)
+{
+ unsigned int pos;
+ struct resource *res;
+ int fixed = 0;
+ u8 tmp8;
+
+ if ((dev-class 8) != PCI_CLASS_STORAGE_IDE)
+ return;
+
+ /* TODO: What if one channel is in native mode ... */
+ pci_read_config_byte(dev, PCI_CLASS_PROG, tmp8);
+ if ((tmp8 5) == 5)
+ return;
+
+ for( pos = 0; pos 6; pos ++ ) {
+ res = dev-resource[pos];
+ if (!(res-flags (IORESOURCE_IO | IORESOURCE_MEM)))
+ continue;
+
+ if (!res-start res-end) {
+ res-start = res-end = 0;
+ res-flags = 0;
+ fixed = 1;
+ }
+ }
+ if (fixed)
+ printk(KERN_WARNING
+ PCI device %s: BIOS resource configuration fixed.\n,
+ pci_name(dev));
+}
+
+DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_82801DB_11,
quirk_intel_ide_controller);
+
--- linux-2.6.21.noarch/arch/ia64/kernel/Makefile~ 2007-05-27
23:23:36.0 -0400
+++ linux-2.6.21.noarch/arch/ia64/kernel/Makefile 2007-05-27
23:23:48.0 -0400
@@ -33,6 +33,7 @@ obj-$(CONFIG_CRASH_DUMP) += crash_dump.o
obj-$(CONFIG_IA64_UNCACHED_ALLOCATOR) += uncached.o
obj-$(CONFIG_AUDIT)+= audit.o
obj-$(CONFIG_PCI_MSI) += msi_ia64.o
+obj-$(CONFIG_PCI) += quirks.o
mca_recovery-y += mca_drv.o mca_drv_asm.o
obj-$(CONFIG_IA64_MC_ERR_INJECT)+= err_inject.o
___
Fedora-kernel-list mailing list
Fedora-kernel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-kernel-list
rawhide patches.
I just sifted through what we had in rawhide, after noticing that ls *.patch was starting to scroll my terminal (which is never a good sign). In doing so, I found a bunch of patches that weren't applied any more that we forgot to remove, and a bunch that were applied that shouldn't have been. Sifting through the remnants gave me a list that I've added to cvs as the file 'TODO' in devel. Hopefully we can keep this up to date as patches are introduced/removed. At the least it should serve as reasoning for why the hell we're carrying some patches for years (some of the CVS changelogs are pretty crappy, including some from yours truly). Here's what it looks like today.. Dave drm-modesetting-i915.patch drm-modesetting-radeon.patch linux-2.6-export-shmem-bits-for-gem.patch Intel/Radeon kernel mode-setting. Won't go upstream for a while. drm-nouveau.patch Nouveau DRM driver. Won't go upstream until ABI confirmed. linux-2.6-acpi-clear-wake-status.patch linux-2.6-acpi-video-dos.patch linux-2.6-defaults-acpi-video.patch linux-2.6-input-dell-keyboard-keyup.patch linux-2.6-eeepc-laptop-update.patch mjg59 ACPI/laptop bits. Upstreamable for 2.6.28 ? linux-2.6-at76.patch linux-2.6-iwlwifi-use-dma_alloc_coherent.patch linux-2.6-wireless.patch linux-2.6-wireless-pending.patch Linville. Wireless bits. Most should be upstream for 2.6.28 linux-2.6-ata-quirk.patch IA64 oddness. Query sent to f-k-l linux-2.6-build-nonintconfig.patch linux-2.6-debug-nmi-timeout.patch linux-2.6-debug-spinlock-taint.patch linux-2.6-debug-taint-vm.patch linux-2.6-debug-vm-would-have-oomkilled.patch linux-2.6-scsi-cpqarray-set-master.patch linux-2.6-usb-ehci-hcd-respect-nousb.patch Push for 2.6.28 linux-2.6-compile-fixes.patch linux-2.6-hotfixes.patch Empty linux-2.6-crash-driver.patch Not upstreamable. linux-2.6-debug-always-inline-kzalloc.patch Sent upstream Sep 25 2008 linux-2.6-debug-sizeof-structs.patch Fedora local debug stuff. linux-2.6-default-mmf_dump_elf_headers.patch linux-2.6-utrace.patch linux-2.6-x86-tracehook.patch Roland magick utrace linux-2.6-defaults-fat-utf8.patch Drop? linux-2.6-defaults-pci_no_msi.patch linux-2.6-input-kill-stupid-messages.patch linux-2.6-x86-tune-generic.patch Fedora local choices uninteresting to upstream linux-2.6-e1000e-add-support-for-82567LM-3-and-82567LF-3-ICH10D-parts.patch linux-2.6-e1000e-add-support-for-new-82574L-part.patch linux-2.6-e1000e-add-support-for-the-82567LM-4-device.patch linux-2.6-e1000-ich9.patch linux-2.6-firewire-git-update.patch linux-2.6-netdev-atl2.patch Should go upstream for .28 linux-2.6-efika-not-chrp.patch linux-2.6-g5-therm-shutdown.patch linux-2.6-imac-transparent-bridge.patch linux-2.6-ps3-ehci-iso.patch linux-2.6-ps3-legacy-bootloader-hack.patch linux-2.6-ps3-storage-alias.patch linux-2.6-vio-modalias.patch ppc bits. dwmw2. linux-2.6-execshield.patch linux-2.6-xen-execshield-add-xen-specific-load_user_cs_desc.patch linux-2.6-xen-execshield-fix-endless-gpf-fault-loop.patch linux-2.6-xen-execshield-only-define-load_user_cs_desc-on-32-bit.patch Not interesting to upstream. linux-2.6-lirc.patch jarod working on upstreaming linux-2.6-merge-efifb-imacfb.patch pjones. merge for 2.6.28 ? linux-2.6-nfs-client-mounts-hang.patch SteveD. Sent ping on Sep 25 to find out status. linux-2.6-net-silence-noisy-printks.patch linux-2.6-piix3-silence-quirk.patch linux-2.6-quiet-iommu.patch linux-2.6-silence-acpi-blacklist.patch linux-2.6-silence-fbcon-logo.patch linux-2.6-silence-noise.patch Fedora local 'hush' patches. linux-2.6-selinux-mprotect-checks.patch linux-2.6-sparc-selinux-mprotect-checks.patch Not upstreamable. linux-2.6-serial-460800.patch Probably not upstreamable. http://marc.theaimsgroup.com/?l=linux-kernelm=112687270832687w=2 https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=126403 http://lkml.org/lkml/2006/8/2/208 linux-2.6-squashfs.patch Sigh. Who the hell knows when this will go upstream. linux-2.6-sysrq-c.patch Que? -- http://www.codemonkey.org.uk ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: rawhide patches.
On Thu, Sep 25, 2008 at 03:07:04PM -0400, Bill Nottingham wrote: Dave Jones ([EMAIL PROTECTED]) said: linux-2.6-defaults-fat-utf8.patch Drop? Isn't this a local choice similar to the later ones? The problem is this is a who do we want to screw over patch. Some people have disks which aren't UTF8, and get crazy moon language instead of their expected charset. linux-2.6-net-silence-noisy-printks.patch linux-2.6-piix3-silence-quirk.patch linux-2.6-quiet-iommu.patch linux-2.6-silence-acpi-blacklist.patch linux-2.6-silence-fbcon-logo.patch linux-2.6-silence-noise.patch Fedora local 'hush' patches. Speaking of 'hush' patches - .. ALSA sound/pci/hda/hda_intel.c:1404: azx_pcm_prepare: bufsize=0x1, format=0x4011 ALSA sound/pci/hda/hda_codec.c:716: hda_codec_setup_stream: NID=0x2, stream=0x5, channel=0, format=0x4011 .. Is this a config option, or do we need to patch this stuff out? Probably one of the many ALSA debug options. CONFIG_SND_VERBOSE_PRINTK=y CONFIG_SND_DEBUG=y CONFIG_SND_DEBUG_DETECT=y CONFIG_SND_DEBUG_VERBOSE=y CONFIG_SND_PCM_XRUN_DEBUG=y Dave -- http://www.codemonkey.org.uk ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: chcorefilter
On Thu, Sep 25, 2008 at 05:32:50PM -0700, Roland McGrath wrote: Content-Description: message body text The /proc/PID/coredump_filter mechanism makes it easy to tweak the per-process setting to control ELF core dump style details. This setting is per-process (per-mm) and inherited by children. But as a user, the /proc interface is insane. It prints a magical hex value (without a leading 0x, to make it sneaky), which you'll be damn lucky to figure out from reading Documentation/filesystems/proc.txt. Then you get to set it to another such magical value, which is in decimal unless you add a leading 0x (cat /proc/x/coredump_filter /proc/y/coredump_filter does not copy the setting, go team). I have kicking around this half-assed bash script that I don't care to bother making really presentable. Where should it live? In the upstream kernel's scripts/? (Then noone would ever see it for sure.) In util-linux-ng? Or what? Someone want to take it off my hands? either util-linux or procps is my suggestion. Dave -- http://www.codemonkey.org.uk ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: de-modularising for the win!
On Fri, Sep 19, 2008 at 08:02:47AM -0400, Josh Boyer wrote: -CONFIG_IEEE80211=m +CONFIG_IEEE80211=y CONFIG_IEEE80211_DEBUG=y CONFIG_IEEE80211_CRYPT_WEP=m CONFIG_IEEE80211_CRYPT_CCMP=m Do we have a way to _not_ do this on secondary architectures? the per-arch config fragments will always override options in config-generic, so yes. -CONFIG_SND_HDA_INTEL=m +CONFIG_SND_HDA_INTEL=y CONFIG_SND_HDA_HWDEP=y CONFIG_SND_HDA_CODEC_REALTEK=y CONFIG_SND_HDA_CODEC_ANALOG=y @@ -2545,7 +2545,7 @@ CONFIG_SND_HIFIER=m CONFIG_SND_ICE1712=m CONFIG_SND_ICE1724=m -CONFIG_SND_INTEL8X0=m +CONFIG_SND_INTEL8X0=y See... like these two. Not going to be in any ppc box, ever. Why include them in the generic kernel config? I think they should be moved to config-x86-generic.config instead. They got dumped in config-generic instead of duping them in config-x86[64] and config-ia64, but yeah, could do. if the options don't exist on an arch though it's competely benign regardless of what they get set to. Dave -- http://www.codemonkey.org.uk ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: de-modularising for the win!
On Thu, Sep 18, 2008 at 05:14:14PM -0400, Tom spot Callaway wrote: On Thu, 2008-09-18 at 12:13 -0700, Bill Nottingham wrote: See various and sundry plumber's conf discussions. Comments? (The netfilter stuff needs further investigation.) Fly on the wall here, but wouldn't demodularizing the SCSI stack cause problems down the road for RHEL, for third party SCSI/FC drivers? if a vendor is shipping their own scsi_mod or other part of the scsi layer to replace modules we ship, they may be DOING IT WRONG. Dave -- http://www.codemonkey.org.uk ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: de-modularising for the win!
On Thu, Sep 18, 2008 at 04:27:50PM -0500, Matt Domsch wrote: This _is_ Fedora we're talking about, not RHEL, right? :-) /me has had to replace way too many kernel modules from RHEL, which can't be done if it's built-in. The thing is, Dell or any other vendor having to ship their own module is to me a sign of a failing in the RHEL process that we can't get fastpath pre-next-U release packages out fast enough. THAT should be fixed rather than holding back Fedora (or even RHEL, as it would be a shame that it couldn't take advantage of these wins) Dave -- http://www.codemonkey.org.uk ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: de-modularising for the win!
On Thu, Sep 18, 2008 at 12:13:55PM -0700, Bill Nottingham wrote: See various and sundry plumber's conf discussions. Comments? (The netfilter stuff needs further investigation.) looks like some of the lower-hanging fruit. definite room for further expansion. how well will mkinitrd cope when modules it always loads don't exist any more? any nasty hardcoded bits there? Dave -- http://www.codemonkey.org.uk ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: de-modularising for the win!
On Thu, Sep 18, 2008 at 07:42:15PM -0400, Jeremy Katz wrote: On Thu, 2008-09-18 at 12:13 -0700, Bill Nottingham wrote: See various and sundry plumber's conf discussions. If we build in the loop module, we need to bump the default of number of loopdevs[1] to keep things happier for live images. Right now, we just set maxloop in modprobe.conf does it not appear configurable in sysfs someplace? Dave -- http://www.codemonkey.org.uk ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: de-modularising for the win!
On Thu, Sep 18, 2008 at 07:49:33PM -0400, Jeremy Katz wrote: On Thu, 2008-09-18 at 19:47 -0400, Dave Jones wrote: On Thu, Sep 18, 2008 at 07:42:15PM -0400, Jeremy Katz wrote: On Thu, 2008-09-18 at 12:13 -0700, Bill Nottingham wrote: See various and sundry plumber's conf discussions. If we build in the loop module, we need to bump the default of number of loopdevs[1] to keep things happier for live images. Right now, we just set maxloop in modprobe.conf does it not appear configurable in sysfs someplace? Unless something has changed from when I looked last, no. The devices are statically allocated on module(/built-in) load and that's as many as you get. ok, should be easy enough hack in anyway. Dave -- http://www.codemonkey.org.uk ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: RFC: split changelog out of spec
On Mon, Aug 18, 2008 at 01:13:26PM -0400, Jarod Wilson wrote:
Hey all,
Been toying with the idea of splitting the changelog out of the kernel spec
itself, to reduce the size of the spec file. Basically, instead of
%changelog
followed by all the entries, it'd be %include %{SOURCE1}, which is a file
'fedora-kernel-changelog', which carries all the usual changelog entries.
Its
reasonably trivial to implement, though my current hack-around for 'make
clog'
complains about me redefining the clog target. Is shaving 800+ lines out of
the spec file (only to put them in another file) worth the hassle though?
Probably not until we move away from CVS to an SCM that doesn't suck.
It'd be nice if 'make build' slurped the changelog out of the SCM.
Dave
--
http://www.codemonkey.org.uk
___
Fedora-kernel-list mailing list
Fedora-kernel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: perfmon2 on fedora kernels
On Thu, Jul 31, 2008 at 02:26:10PM -0400, Chuck Ebbert wrote: We could put it in fedora but it's not upstream and nobody can say when or if it will go in. After the long drawn out pain that utrace has been, I'm somewhat reluctant. Especially for something that's providing additional userspace interfaces that aren't upstream. Dave -- http://www.codemonkey.org.uk ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: git11 new config items
On Thu, Jul 24, 2008 at 02:31:04AM -0700, Roland McGrath wrote: I added these to config-generic to keep building with -git11. I have no idea if these are the right settings. +# CONFIG_MFD_TC6393XB is not set +# CONFIG_BOOTPARAM_SOFTLOCKUP_PANIC is not set +CONFIG_DMADEVICES=y +CONFIG_INTEL_IOATDMA=m +# CONFIG_DMATEST is not set All ok, except that CONFIG_INTEL_IOATDMA is already in config-x86[64].config I just nuked the dupe. Dave -- http://www.codemonkey.org.uk ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: kernel-vanilla-2.6.26-137.fc10
On Mon, Jul 14, 2008 at 01:03:39PM -0700, Roland McGrath wrote: BTW, see http://koji.fedoraproject.org/scratch/roland/task_714174/ for a kernel-vanilla build I did of 2.6.26. This gives a baseline for regression testing any problems to see if they are caused by some Fedora patches (e.g. utrace) or are also upstream. I think koji scratch only stays around for a couple of days. Maybe there is a better place to put these. put them on roland.fedoraproject.org ? Was there ever a plan to put kernel-vanilla rpms up for public consumption on a regular basis? There was. The question largely came down to 'where do we host them?'. The best answer right now does seem to be $personal.fedoraproject.org I think it's worth doing this on a semi-regular basis. Probably not for every -git, but at least for every -rc and point release. Dave -- http://www.codemonkey.org.uk ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: kernel-vanilla-2.6.26-137.fc10
On Mon, Jul 14, 2008 at 04:28:50PM -0400, Josh Boyer wrote: On Mon, 2008-07-14 at 16:12 -0400, Dave Jones wrote: On Mon, Jul 14, 2008 at 01:03:39PM -0700, Roland McGrath wrote: BTW, see http://koji.fedoraproject.org/scratch/roland/task_714174/ for a kernel-vanilla build I did of 2.6.26. This gives a baseline for regression testing any problems to see if they are caused by some Fedora patches (e.g. utrace) or are also upstream. I think koji scratch only stays around for a couple of days. Maybe there is a better place to put these. put them on roland.fedoraproject.org ? Was there ever a plan to put kernel-vanilla rpms up for public consumption on a regular basis? There was. The question largely came down to 'where do we host them?'. The best answer right now does seem to be $personal.fedoraproject.org I think it's worth doing this on a semi-regular basis. Probably not for every -git, but at least for every -rc and point release. I'd be more than happy to host them on my fedorapeople page. I don't have anything else there. I really don't mind who does it, and takes care of the building/uploading of them (it can mostly be automated anyway). I've not got around to doing it myself due to well, everything else. It's probably best if someone other than the usual suspects (me, kyle, chuck) did it anyway, so we can keep doing what we do normally.. Dave -- http://www.codemonkey.org.uk ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: Enabling PARAVIRT stuff in Fedora kernels
On Tue, Jul 08, 2008 at 09:28:43PM -0700, Roland Dreier wrote: And actually the options I'm really hoping for are KVM_GUEST and KVM_CLOCK -- sorry for my confusion and sloppy grep for VIRT. Umm, they're also all enabled. $ grep KVM /boot/config-2.6.26-0.115.rc9.git2.fc10.x86_64 CONFIG_HAVE_KVM=y CONFIG_KVM=m CONFIG_KVM_INTEL=m CONFIG_KVM_AMD=m CONFIG_KVM_TRACE=y $ grep PARAVIRT /boot/config-2.6.26-0.115.rc9.git2.fc10.x86_64 # CONFIG_PARAVIRT_GUEST is not set Ah, yeah. See my note about x86-64 in the other mail. I'll flip it on tomorrow, and we'll see if it builds now.. Dave -- http://www.codemonkey.org.uk ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: kernel module options for cpufreq
On Fri, Jun 27, 2008 at 09:01:34PM +0100, Richard Hughes wrote: On Fri, 2008-06-27 at 21:16 +0200, drago01 wrote: On Fri, Jun 27, 2008 at 6:13 PM, Richard Hughes [EMAIL PROTECTED] wrote: You really don't want to be using USERSPACE at all. seems like cpufreq-applet uses it Sure, it shouldn't. If you're using userspace for thermal or latency reasons, then a setuid applet is totally the wrong way to achieve both of these :-) Maybe we can just use these as loadable modules (i.e. not built default) rather than built-in and loaded by default. DaveJ, do these suggestions seem acceptable? Having the userspace governor built-in means absolutely nothing in terms of overhead, until something in userspace actually uses it. When the cpuspeed init script starts up, the first thing it does is check if the CPU is on the whitelist for using ondemand, and if so, it starts up ondemand. Not a single line of the userspace governor code gets run in this case. The only time the above isn't true is when the CPU isn't on that whitelist, when it's incapable of running ondemand, in which case we need to use.. ta-da... userspace, and then we start the cpuspeed process. Again, if you're seeing overhead from using userspace, it's due to your CPU being crap. There's nothing we can do about it. Whilst ondemand will load on some of these CPUs, the associated overhead of switching is very noticable on benchmarks. Even 'conservative' was too demanding for some of the challenged CPUs. 'crap' here doesn't mean really old stuff too. Any pre-centrino Intel CPU, any VIA CPU before Nehemiah generation, all mobile Athlons. We're using ondemand on all K8's too, but the first generation also sucked iirc, but we're just sucking it up because a) it makes the already convoluted startup script even more messy and b) no-one can remember which stepping/models were affected. Dave -- http://www.codemonkey.org.uk ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: revisit: turning some of the always used modules to built-in
On Sun, Jun 22, 2008 at 11:42:18AM -0700, Arjan van de Ven wrote: Category 1: Always loaded anyway Rationale: Since we load these always anyway, why bother making it modules - ata_generic, pata_acpi These ones make me hrmm a bit. I'd like to know that our initrd isn't going to do something silly before we change these. Peter ? - libata Sure. Done in CVS. - sg, sd_mod Ditto. , scsi_mod This one is tricky. It seems to become modular because it's dependant upon the bool SCSI_NETLINK. A bunch of other scsi modules enable SCSI_NETLINK, like the fibrechannel stuff. I'm not convinced we want to build all that stuff in. - ext3, jbd, mbcache I'm torn on these. Mostly for the reasons both Eric and Matt suggested. The flipside being that Eric knows how to build his own kernels, and can do so, but at the same time, if it means he spends less time fixing ext bugs each day and more time staring at compiler output, I'm not sure it's a net win. Matts argument, whilst RHEL specific, does have an element of validity for Fedora too. We always push the 'Fedora isn't a test vehicle for RHEL' angle, but at the same time, there's no denying that doing something completely different does take away a certain amount of 'in the field' testing. (In this case, I'm primarily thinking about the knock-on effects changes like this have on the kernel periphery packages like mkinitrd/anaconda which now have to support two separate cases). Category 2: Always loaded in default install Rationale: yes you can turn off your firewall.. but nobody should do that. The others are default-loaded as well - ip_tables, iptable_filter - ip6_tables, ip6table_filter Hm. Could be swayed either way on these ones. - dm_mod Yeah, I guess. - ipv6 A lot of people alias this to off if they don't use it. I think we'd get quite a few complaints if we broke that. - battery, ac, button, video, output Some of these are a bit crap in the case of 'the hardware/bios doesnt support this'. Ie, ac will register proc entries even if there aren't any ACPI objects to register underneath it. Somewhat benign, but on the whole, not really a problem per-se. I suppose we could flip these on. - ahci (default storage for all new systems; means that there the system always has the / device driver) Same thing as above. The mkinitrd logic surrounding ordering of storage modules is fragile at best.. - ehci_hcd (means you have a USB keyboard early) ISTR there was some issue with this. I'm sure we even tried it once in the FC2 era. Lets give it a shot, and see what happens. - cpufreq_ondemand (means the cpu can slow down for power/thermal) - acpi_cpufreq (means the cpu can slow down for power/thermal) On Intel this is a good idea. On other CPUs, acpi-cpufreq is considered a fallback 'last resort' driver. Rationale: pretty much always loaded in default installs - snd_seq_dummy, snd_seq, snd_seq_device, snd_pcm, snd_timer, snd_page_alloc, snd The only concern here seems to be the one of memory bloat. ALSA isn't the smallest part of the kernel, and if some folks are currently aliasing that off in their modules.conf, we'll probably upset them with such a change. Dave -- http://www.codemonkey.org.uk ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
rawhide / F10
Now that rawhide has opened up again for F10, I've moved CVS forward to 2.6.26-rc2-git5. In doing so, there were the usual ton of rejects, some of the trivial ones I fixed up, but some of the larger patches (especially the git tree snapshots) failed so much that it was easier to just disable them until their owners can find time to update them. Here's what's disabled so far: utrace assorted ppc patches selinux deferred contexts wireless at76 linux-2.6-smarter-relatime.patch atl2 drm/nouveau/modesetting uvcvideo efifb/imacfb merging lirc Execshield may need some more attention. I got it building locally, but it hasn't been boot tested at all yet, and touching that thing always makes me nervous. Oh, and the usual debugging-and-then-some config options are all back on. Now to try and get it to survive a trip through koji ... Dave -- http://www.codemonkey.org.uk ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: [Fedora-music-list] ardour 2.4 was out
On Wed, Apr 09, 2008 at 07:42:02PM +0200, Hans de Goede wrote: I believe this is easily feasible given enough manpower, most ccrma packages are pretty clean, they just need someone to push them through the review process, then the biggest hurdle left is ... the rt-kernel. Well since I seem to be talking to the right person now, I know you hate this question, but ... how strongly would you object to having an rt kernel variant within Fedora? Not incredibly keen tbh. I'd sooner just add -rt to the regular kernel package and suck it up, but that obviously takes us further from our 'upstream first' mantra. Ingo Thomas are getting sizable chunks of it merged upstream, but I don't think we'll be seeing it all merged soon, but then again, F10 is quite a ways off, and with a few more kernel releases, who knows. Depends how objectionable the remaining bits are I guess. Given that so many people are now distributing products based on this work, getting it all in mainline is obviously important, and there's no shortage of manpower helping drive it there. All this said, I personally haven't hit any issues with things like MIDI in Fedora where the -rt kernel would have helped me. Maybe my gear is special, but latency between me hitting a key on a synth and having that note show up in rosegarden, and a sound being created is well below perceivable. I'm interested to hear any test cases you guys may have that justify why you need -rt. Right now the guys working on that stuff typically have a bunch of 'boring' test cases more tailored towards replicating situations like stock trades and the like. If we can construct additional use-cases I'm sure Ingo, Thomas co would be very interested to hear about them. Especially if these cases are triggering different latency paths. Dave -- http://www.codemonkey.org.uk ___ Fedora-music-list mailing list Fedora-music-list@redhat.com http://www.redhat.com/mailman/listinfo/fedora-music-list
Re: [Fedora-music-list] ardour 2.4 was out
On Wed, Apr 09, 2008 at 02:24:34PM -0700, Fernando Lopez-Lezcano wrote: On Wed, 2008-04-09 at 13:48 -0400, Greg DeKoenigsberg wrote: On Wed, 9 Apr 2008, Hans de Goede wrote: Well since I seem to be talking to the right person now, I know you hate this question, but ... how strongly would you object to having an rt kernel variant within Fedora? LOL. I asked this question two years ago. I doubt the answer has changed. :) But the situation HAS changed. A LOT. There is now (or is going to be) a realtime kernel in _RedHat Enterprise_ of all places. If it is good and stable for RHEL why wouldn't it be good for Fedora? Largely a manpower thing. We have staff we can throw at RHEL projects. Fedora, not so much. Supporting an extra kernel variant is a big deal. Given how understaffed the Fedora kernel team is in comparison to the workload dealing with incoming bugs etc, it's not something we should just do and hope for the best. Even with the recent growth within our team, we're still totally buried with stuff to do with the non-rt kernel. In the latest spins of my rt kernel I have actually used the patch set of the RHEL beta realtime kernel _and_ the patch set of the latest Fedora kernels [NOT fun to integrate!] That's also an additional reason why we shy away from it for Fedora. Fedora needs to be lightweight enough that we can quickly move to newer upstream releases. We lost a lot of agility when we were carrying Xen for exactly the same reason. And the idea of 'well have kernel-rt be based on an earlier version' doesn't fly because then userspace has to deal with two possible environments (Another case where Xen burned us). Dave -- http://www.codemonkey.org.uk ___ Fedora-music-list mailing list Fedora-music-list@redhat.com http://www.redhat.com/mailman/listinfo/fedora-music-list
Re: [Fedora-music-list] ardour 2.4 was out
On Wed, Apr 09, 2008 at 02:40:04PM -0700, Fernando Lopez-Lezcano wrote: All this said, I personally haven't hit any issues with things like MIDI in Fedora where the -rt kernel would have helped me. Maybe my gear is special, but latency between me hitting a key on a synth and having that note show up in rosegarden, and a sound being created is well below perceivable. And that would be how many milliseconds? I honestly couldn't say (it's been some time, and I'm a few thousand miles from home right now). What could seem below the perception level to you (caveat: I don't know if you are a musician and what instrument you play) may bother a professional percussionist using the computer as an instrument. It all depends on your demands as a performer. musician may be stretching my abilities somewhat :) But yes, I understand that I'm probably not pushing things perhaps as far as some others may be. Besides realtime performance, all the audio-over-the-network being done at CCRMA needs it (see: http://ccrma.stanford.edu/groups/soundwire/). This is, in a nutshell, multichannel (between 4 and 8 channels) non-compressed high quality bidirectional audio being sent between 2 or 3 geographically separate locations to create a virtual concert hall and jam session or concert. You don't want to add _any_ latency to the one that speed of light already gives us :-) We routinely run at 64 frames (or 128 if the links are not good). The stock Fedora kernel is just not good enough although I'm sure it is getting better all the time. *nod*. A while ago, I was tempted to add the latency-tracer part of -rt to Fedora kernels just to see what would show up, but Ingo wasn't really interested because he felt that we'd get a lot of reports we'd already fixed in -rt. The fundamental changes to spinlocks is probably the real controversial stuff that's left to go upstream. How well that goes remains to be seemn over the coming months. Right now the guys working on that stuff typically have a bunch of 'boring' test cases more tailored towards replicating situations like stock trades and the like. If we can construct additional use-cases I'm sure Ingo, Thomas co would be very interested to hear about them. Especially if these cases are triggering different latency paths. The apps being worked on at CCRMA (jacktrip) would touch both the network drivers and drivers for pro audio cards. Probably disk as well if the same host is being used to record the performance in Ardour. Ok, that's an interesting use-case and in honesty, I don't think it's too different to the use-cases like the stock trading stuff that people have been focusing on, so it's understandable why you're reaping the same rewards. Dave -- http://www.codemonkey.org.uk ___ Fedora-music-list mailing list Fedora-music-list@redhat.com http://www.redhat.com/mailman/listinfo/fedora-music-list
Re: OT - High amount of spam on this list
On Tue, Mar 25, 2008 at 03:33:24PM -0400, Dave Jones wrote: On Tue, Mar 25, 2008 at 12:18:38PM -0700, Andrew Farris wrote: Rui Tiago Cação Matos wrote: Hi, Is it just me that is receiving a lot of spam on this list? Other fedora lists I'm subscribed to don't seem to suffer from this. Can anyone have a look at it? No its actually going to the whole list, I get it too and they are in the archive if you go look for them. I'm on 4 redhat lists and this is the only one I get spam on though, and it comes from various people so its not just one compromised machine. I only see one spam message every couple days, so its not really that bad, but less spam is always a good thing. I've not seen anything make to to my inbox from the list that hasn't been caught by spamassassin. The posting rules to the list aren't as restricted as they are to other lists, as it's already been really useful to Cc: upstream developers (who aren't necessarily on the list) into discussions here, without having to go approve messages for every post. I just added some more taboo subjects to the mailman filter, so that might catch some of those that are slipping through. I just tweaked it some more, apologies for the last few that made it through. This time for sure.. Dave -- http://www.codemonkey.org.uk ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: Add SELinux permissive domains to fedora kernels
On Mon, Mar 31, 2008 at 02:07:44PM -0400, Eric Paris wrote: I know its way late but I'd like to add a new SELinux concept to the F9 kernels. Its going to be a backport of a couple of my changesets headed upstream http://git.kernel.org/?p=linux/kernel/git/jmorris/selinux-2.6.git;a=commitdiff;h=32021b669089eb9b264e6b26af4d9a47eb50d4f1 http://git.kernel.org/?p=linux/kernel/git/jmorris/selinux-2.6.git;a=commitdiff;h=70d212ebfdd5e39a9d4fb0f8f7ea5c38486f6b04 http://git.kernel.org/?p=linux/kernel/git/jmorris/selinux-2.6.git;a=commitdiff;h=559dbbc87d0a5d2eb88bbbea5f2b66ee2dfd55d6 Only the third patch is truly interesting. A permissive domain is a new concept in which a sysadmin can say that a given domain is free to do anything it wants. Lets say a user seriously customized httpd and they want httpd to just be allowed to run wild while still keeping enforcing for everything else in the system. With the kernel patch I want to commit and the userspace changes dan has already pushed this week they just need a simple policy which says permissive httpd_t and all their httpd_t denials become allows! One of the upstream patches adds a BUG_ON() but I'm still a teensy bit scared of it so in the F9 patch I'll probably make it a WARN_ON since it isn't really deadly to the kernel... anyway. Chances of regression here are very very low. I would just jam this in myself but we are getting really late and I wanted people to be able to tell me no before I did it. If noone strongly objects quickly expect to see a commit message early this week It is indeed, very late. I'm concerned by just how much busted stuff we have[*], so shovelling in more features after the feature freeze is making me wince. From a quick look at the patches, this is a fairly small amount of code that's changing, that looks harmless. What userspace changes are necessary for this? Are they in place already? We'll pick this up anyway in 2-3 months as an F9 update when we rebase to 2.6.26, so I guess the userspace bits will have to be done at some point, but I'd rather we spent effort beating what we have already into shape than forward planning right now. (That said, selinux is pretty solid from a kernel pov. Still some warts in policy, but Dan is nailing those pretty quickly as usual). I dunno. Dave [*] The top kerneloops.org regressions right now are all in code that's been added to Fedora that isn't upstream (yet). This is not a good sign. -- http://www.codemonkey.org.uk ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: WebCam drivers ...
On Sat, Mar 29, 2008 at 08:42:22AM +0200, Clinton Lee Taylor wrote: Greetings Hans de Goede ... I can't comment on the code, but I, and I'm sure many others welcome any effort to improve the WebCam drivers in Fedora. Many thanks. I have three USB WebCam's myself - 05a9:a511 OmniVision Technologies, Inc. OV511+ WebCam (Creative ) This one has been working for many years now with the ov511 module. - 05a9:8519 OmniVision Technologies, Inc. OV519 WebCam (D-Link) This one probably works with the out of tree variant of the same driver. (For some reason, the author stopped updating the kernel.org variant) http://ovcam.org/ov511/ (Note it may need some work to run on the latest versions of the kernel) - 046d:08c2 Logitech, Inc. should be supported by the uvcvideo module. Dave -- http://www.codemonkey.org.uk ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: OT - High amount of spam on this list
On Tue, Mar 25, 2008 at 12:18:38PM -0700, Andrew Farris wrote: Rui Tiago Cação Matos wrote: Hi, Is it just me that is receiving a lot of spam on this list? Other fedora lists I'm subscribed to don't seem to suffer from this. Can anyone have a look at it? No its actually going to the whole list, I get it too and they are in the archive if you go look for them. I'm on 4 redhat lists and this is the only one I get spam on though, and it comes from various people so its not just one compromised machine. I only see one spam message every couple days, so its not really that bad, but less spam is always a good thing. I've not seen anything make to to my inbox from the list that hasn't been caught by spamassassin. The posting rules to the list aren't as restricted as they are to other lists, as it's already been really useful to Cc: upstream developers (who aren't necessarily on the list) into discussions here, without having to go approve messages for every post. I just added some more taboo subjects to the mailman filter, so that might catch some of those that are slipping through. Dave -- http://www.codemonkey.org.uk ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
shared /boot support. bz 197065
I took a stab at bz 197065 and arrived at the patch below.
Would appreciate some eyeballs before I commit from people
familiar with the macro goo in the specfile. (Hi Roland!)
Aparently pm-utils will need a change to cope with the changed
filename, but I think that should be the limit of the damage.
(oprofile will need to append the archname on the end of System.map-$ver
filenames, but they're user-passed anyway, and not coded anywhere afaik
Hmm. Not sure about Systemtap).
Comments?
Index: kernel.spec
===
RCS file: /cvs/pkgs/rpms/kernel/devel/kernel.spec,v
retrieving revision 1.521
diff -u -p -r1.521 kernel.spec
--- kernel.spec 21 Mar 2008 15:27:16 - 1.521
+++ kernel.spec 24 Mar 2008 19:20:58 -
@@ -1268,15 +1268,15 @@ BuildKernel() {
mkdir -p $RPM_BUILD_ROOT%{debuginfodir}/%{image_install_path}
%endif
mkdir -p $RPM_BUILD_ROOT/%{image_install_path}
-install -m 644 .config $RPM_BUILD_ROOT/boot/config-$KernelVer
-install -m 644 System.map $RPM_BUILD_ROOT/boot/System.map-$KernelVer
-touch $RPM_BUILD_ROOT/boot/initrd-$KernelVer.img
+install -m 644 .config $RPM_BUILD_ROOT/boot/config-$KernelVer.%{_arch}
+install -m 644 System.map
$RPM_BUILD_ROOT/boot/System.map-$KernelVer.%{_arch}
+touch $RPM_BUILD_ROOT/boot/initrd-$KernelVer.img.%{_arch}
if [ -f arch/$Arch/boot/zImage.stub ]; then
cp arch/$Arch/boot/zImage.stub
$RPM_BUILD_ROOT/%{image_install_path}/zImage.stub-$KernelVer || :
fi
$CopyKernel $KernelImage \
- $RPM_BUILD_ROOT/%{image_install_path}/$InstallName-$KernelVer
-chmod 755 $RPM_BUILD_ROOT/%{image_install_path}/$InstallName-$KernelVer
+
$RPM_BUILD_ROOT/%{image_install_path}/$InstallName-$KernelVer.%{_arch}
+chmod 755
$RPM_BUILD_ROOT/%{image_install_path}/$InstallName-$KernelVer.%{_arch}
mkdir -p $RPM_BUILD_ROOT/lib/modules/$KernelVer
make -s ARCH=$Arch INSTALL_MOD_PATH=$RPM_BUILD_ROOT modules_install
KERNELRELEASE=$KernelVer
@@ -1570,7 +1570,7 @@ fi\
#
%define kernel_variant_posttrans(s:r:v:) \
%{expand:%%posttrans %{?-v*}}\
-/sbin/new-kernel-pkg --package kernel%{?-v:-%{-v*}} --rpmposttrans %{?1}
%{KVERREL}%{?-v*} || exit $?\
+/sbin/new-kernel-pkg --package kernel%{?-v:-%{-v*}} --rpmposttrans %{?1}
%{KVERREL}%{?-v*}.%{_arch} || exit $?\
%{nil}
#
@@ -1587,7 +1587,7 @@ if [ `uname -i` == x86_64 -o `uname -i
[ -f /etc/sysconfig/kernel ]; then\
/bin/sed -i -e 's/^DEFAULTKERNEL=%{-s*}$/DEFAULTKERNEL=%{-r*}/'
/etc/sysconfig/kernel || exit $?\
fi}\
-/sbin/new-kernel-pkg --package kernel%{?-v:-%{-v*}} --mkinitrd --depmod
--install %{?1} %{KVERREL}%{?-v*} || exit $?\
+/sbin/new-kernel-pkg --package kernel%{?-v:-%{-v*}} --mkinitrd --depmod
--install %{?1} %{KVERREL}%{?-v*}.%{_arch} || exit $?\
#if [ -x /sbin/weak-modules ]\
#then\
#/sbin/weak-modules --add-kernel %{KVERREL}%{?-v*} || exit $?\
@@ -1600,7 +1600,7 @@ fi}\
#
%define kernel_variant_preun() \
%{expand:%%preun %{?1}}\
-/sbin/new-kernel-pkg --rminitrd --rmmoddep --remove %{KVERREL}%{?1} || exit $?\
+/sbin/new-kernel-pkg --rminitrd --rmmoddep --remove %{KVERREL}%{?1}.%{_arch}
|| exit $?\
#if [ -x /sbin/weak-modules ]\
#then\
#/sbin/weak-modules --remove-kernel %{KVERREL}%{?1} || exit $?\
@@ -1668,10 +1668,9 @@ fi
%if %{1}\
%{expand:%%files %{?2}}\
%defattr(-,root,root)\
-/%{image_install_path}/%{?-k:%{-k*}}%{!?-k:vmlinuz}-%{KVERREL}%{?2}\
-/boot/System.map-%{KVERREL}%{?2}\
-#/boot/symvers-%{KVERREL}%{?2}.gz\
-/boot/config-%{KVERREL}%{?2}\
+/%{image_install_path}/%{?-k:%{-k*}}%{!?-k:vmlinuz}-%{KVERREL}%{?2}.%{_arch}\
+/boot/System.map-%{KVERREL}%{?2}.%{_arch}\
+/boot/config-%{KVERREL}%{?2}.%{_arch}\
%{?-a:%{-a*}}\
%dir /lib/modules/%{KVERREL}%{?2}\
/lib/modules/%{KVERREL}%{?2}/kernel\
--
http://www.codemonkey.org.uk
___
Fedora-kernel-list mailing list
Fedora-kernel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: shared /boot support. bz 197065
On Mon, Mar 24, 2008 at 03:46:44PM -0400, Kyle McMartin wrote: On Mon, Mar 24, 2008 at 03:38:38PM -0400, Jeremy Katz wrote: On Mon, 2008-03-24 at 15:32 -0400, Dave Jones wrote: I took a stab at bz 197065 and arrived at the patch below. Would appreciate some eyeballs before I commit from people familiar with the macro goo in the specfile. (Hi Roland!) Aparently pm-utils will need a change to cope with the changed filename, but I think that should be the limit of the damage. (oprofile will need to append the archname on the end of System.map-$ver filenames, but they're user-passed anyway, and not coded anywhere afaik Hmm. Not sure about Systemtap). I have this sinking suspicion that more things depend on the filenames, although I'm not coming up with what at the moment... We could use systemtap to run for a while with this set and watch to see if anything boinks the wrong file? I'm running a tree-wide grep right now, and it's already picked up anaconda, bootchart, booty apt. I expect kexec-tools, and yum will probably be in the list too. I'm starting to wonder if this is worth it for such a small use-case. Dave -- http://www.codemonkey.org.uk ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: vfat filesystem fix breaks rpm kernel install on ia64
On Fri, Feb 29, 2008 at 10:16:00AM -0600, Matt Domsch wrote:
On Thu, Feb 28, 2008 at 10:00:32PM -0500, Doug Chapman wrote:
Actually I came up with what I think is a cleaner fix for this. Since
the default file permission on files on vfat are 755 anyway if the
kernel is mode 755 rpm doesn't complain.
Anybody have thoughts on this specfile change? I build this as a
scratch build on our ia64 koji server and it installs cleanly.
- Doug
*** kernel.spec.bad2008-02-28 19:58:55.0 -0500
--- kernel.spec2008-02-28 21:39:57.0 -0500
*** BuildKernel() {
*** 1301,1306
--- 1301,1310
$CopyKernel $KernelImage \
$RPM_BUILD_ROOT/%{image_install_path}/$InstallName-$KernelVer
+ %ifarch ia64
+ chmod 755
$RPM_BUILD_ROOT/%{image_install_path}/$InstallName-$KernelVer
+ %endif
+
mkdir -p $RPM_BUILD_ROOT/lib/modules/$KernelVer
make -s ARCH=$Arch INSTALL_MOD_PATH=$RPM_BUILD_ROOT modules_install
KERNELRELEASE=$KernelVer
%ifarch %{vdso_arches}
There are systems with EFI32 and EFI64 out there, that aren't ia64,
but that will likewise be dropping files into a vfat file system.
I don't see any problem in unconditionally doing the chmod. Anyone else?
Dave
--
http://www.codemonkey.org.uk
___
Fedora-kernel-list mailing list
Fedora-kernel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: vfat filesystem fix breaks rpm kernel install on ia64
On Fri, Feb 29, 2008 at 01:23:02PM -0500, Doug Chapman wrote:
+ chmod 755
$RPM_BUILD_ROOT/%{image_install_path}/$InstallName-$KernelVer
There are systems with EFI32 and EFI64 out there, that aren't ia64,
but that will likewise be dropping files into a vfat file system.
I don't see any problem in unconditionally doing the chmod. Anyone else?
I can't actually think of any reason this would break on other
platforms. I added the %ifarch ia64 just in case because I really
don't want to be that ia64 guy who breaks everyone else's stuff.
I just committed the change to devel. We'll see tomorrow, but I'll be
really surprised if anything at all cares that the vmlinuz grew an x bit.
Dave
--
http://www.codemonkey.org.uk
___
Fedora-kernel-list mailing list
Fedora-kernel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: rpms/kernel/devel kernel.spec,1.445,1.446
On Thu, Feb 21, 2008 at 01:08:19PM -0500, Peter Jones wrote: Author: pjones Update of /cvs/extras/rpms/kernel/devel In directory cvs-int.fedora.redhat.com:/tmp/cvs-serv30850 Modified Files: kernel.spec Log Message: * Thu Feb 21 2008 Peter Jones [EMAIL PROTECTED] - Require newer mkinitrd version. Bah. Given rawhide has been perpetually fscked for months on end, a lot of us have been running the F9 kernel on F8. This change breaks that unless we --nodeps. Any chance you can backport that mkinitrd to F8 ? Dave -- http://www.codemonkey.org.uk ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: Disable CONFIG_ACPI_SYSFS_POWER?
On Mon, Feb 18, 2008 at 11:25:40AM -0500, Kyle McMartin wrote: On Sun, Feb 17, 2008 at 09:08:02PM -0500, Chuck Ebbert wrote: On 02/16/2008 06:53 AM, drago01 wrote: Hi, I tested the kernel-2.6.24.2-3.fc8 (downloaded the x86_64 build directly) on my laptop. Hal detects two batteries because it looks in sysfs and in procfs for the battery info. I tryed to apply the patch from the hal-list which causes hal to not look in procfs but in sysfs only when the sysfs info is available. The problem with this is that the info in sysfs is broken (capcity 3.0 Wh etc while the procfs info is correct 45Wh). I would suggest to set CONFIG_ACPI_SYSFS_POWER to n because the procfs info already provides this data for userspace and does not report broken values. We should be enabling either one or the other, not both. my logic was people could be running rawhide kernels on old userspace (i do this, for instance.) actually that's a really good point, given how bad rawhide has been lately at being installable. I do the same thing btw (f9 kernel on f8) because of this, and hadn't picked up on this breakage because my laptop runs f8 kernel. For Fedora 9 maybe it should be the sysfs interface if it works. i don't really see a harm in having both. I imagine that eventually someone upstream will make the decision a no-brainer by removing the proc stuff. Not shipping it does mean that nothing new will start depending on it. (Unlikely I know, but still...) For 8 it should be only procfs to be backwards compatible. I'll do that. agreed, don't want to tempt fate on f8... ACK. Dave -- http://www.codemonkey.org.uk ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: Disable CONFIG_ACPI_SYSFS_POWER?
On Sun, Feb 17, 2008 at 09:08:02PM -0500, Chuck Ebbert wrote: On 02/16/2008 06:53 AM, drago01 wrote: Hi, I tested the kernel-2.6.24.2-3.fc8 (downloaded the x86_64 build directly) on my laptop. Hal detects two batteries because it looks in sysfs and in procfs for the battery info. I tryed to apply the patch from the hal-list which causes hal to not look in procfs but in sysfs only when the sysfs info is available. The problem with this is that the info in sysfs is broken (capcity 3.0 Wh etc while the procfs info is correct 45Wh). I would suggest to set CONFIG_ACPI_SYSFS_POWER to n because the procfs info already provides this data for userspace and does not report broken values. We should be enabling either one or the other, not both. For Fedora 9 maybe it should be the sysfs interface if it works. For 8 it should be only procfs to be backwards compatible. I'll do that. Yeah, you need a new enough hal aparently, which I guess f8 didn't have. F9 should be safe to be using just the sysfs stuff. Dave -- http://www.codemonkey.org.uk ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: enable CONFIG_SECURITY_MMAP_MIN_ADDR
On Thu, Feb 14, 2008 at 12:29:18PM -0500, Eric Paris wrote: My (minimal) testing of wine indicated that it did try to make use of mapping the low pages but it still worked when it couldn't map them Hmm. Graceful fallback is good, but I wonder if it's now using a slower path or something. I guess I should bring it up with the wine community to get a better understanding of exactly why they are trying to map those pages and how it handles those failures (in my case it handled them quite nicely) Well lets set it to 0 across all archs, and see if anything else stops working. Hopefully this is the extent of the breakage. Dave -- http://www.codemonkey.org.uk ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
rawhide -debug
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? Dave -- http://www.codemonkey.org.uk ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: rawhide -debug
On Wed, Feb 13, 2008 at 11:53:34PM +, Christopher Brown wrote: 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. This only recently became a runtime thing, but there's still a bunch of performance impacting options that aren't runtime selectable (like lockdep for example). Dave -- http://www.codemonkey.org.uk ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
