From dwmw2 at infradead.org Sat Dec 1 17:04:17 2007 From: dwmw2 at infradead.org (David Woodhouse) Date: Sat, 01 Dec 2007 17:04:17 +0000 Subject: rawhide report: 20071201 changes In-Reply-To: <200712011315.lB1DFgYK019227@porkchop.devel.redhat.com> References: <200712011315.lB1DFgYK019227@porkchop.devel.redhat.com> Message-ID: <1196528657.13978.84.camel@pmac.infradead.org> On Sat, 2007-12-01 at 08:15 -0500, Build System wrote: > kernel-2.6.24-0.61.rc3.git5.fc9 > ------------------------------- > * Fri Nov 30 2007 Kyle McMartin > - Oops! Local make-build-go-faster kernel.spec patch slipped in, > reverted. cat > GNUmakefile << EOF ppc ppc64 i686: DIST_DEFINES += --without debug --without doc --without headers --without debuginfo include Makefile EOF -- dwmw2 From giallu at gmail.com Sun Dec 2 00:02:23 2007 From: giallu at gmail.com (Gianluca Sforna) Date: Sun, 2 Dec 2007 01:02:23 +0100 Subject: Getting rid of sysprof-kmod Message-ID: Hi, I just finished removing the sysprof-kmod package from CVS as mandated by the new guidelines for F9 and above. I am now seeking some help to understand what is needed to have again the kernel module required for proper operations of the sysprof package. Upstream sources are at: http://www.daimi.au.dk/~sandmann/sysprof/ Thanks in advance Gianluca From davej at redhat.com Sun Dec 2 00:09:24 2007 From: davej at redhat.com (Dave Jones) Date: Sat, 1 Dec 2007 19:09:24 -0500 Subject: Getting rid of sysprof-kmod In-Reply-To: References: Message-ID: <20071202000924.GA31160@redhat.com> On Sun, Dec 02, 2007 at 01:02:23AM +0100, Gianluca Sforna wrote: > Hi, > I just finished removing the sysprof-kmod package from CVS as mandated > by the new guidelines for F9 and above. > > I am now seeking some help to understand what is needed to have again > the kernel module required for proper operations of the sysprof > package. > > Upstream sources are at: > http://www.daimi.au.dk/~sandmann/sysprof/ The upstream kernel is likely to eventually get support for perfmon2 integrated, but this could really use more work. It's been in -mm for a while. If there's anything that sysprof can do that perfmon can't (which would be surprising given perfmons featuritis) it would useful to talk with the perfmon developers so we can eventually arrive at an upstreamed solution and not have to worry about integrating out-of-tree patches. Dave -- http://www.codemonkey.org.uk From giallu at gmail.com Sun Dec 2 00:46:09 2007 From: giallu at gmail.com (Gianluca Sforna) Date: Sun, 2 Dec 2007 01:46:09 +0100 Subject: Getting rid of sysprof-kmod In-Reply-To: <20071202000924.GA31160@redhat.com> References: <20071202000924.GA31160@redhat.com> Message-ID: On Dec 2, 2007 1:09 AM, Dave Jones wrote: > > On Sun, Dec 02, 2007 at 01:02:23AM +0100, Gianluca Sforna wrote: > > Hi, > > I just finished removing the sysprof-kmod package from CVS as mandated > > by the new guidelines for F9 and above. > > > > I am now seeking some help to understand what is needed to have again > > the kernel module required for proper operations of the sysprof > > package. > > > > Upstream sources are at: > > http://www.daimi.au.dk/~sandmann/sysprof/ > > The upstream kernel is likely to eventually get support for > perfmon2 integrated, but this could really use more work. > It's been in -mm for a while. If there's anything that sysprof > can do that perfmon can't (which would be surprising given > perfmons featuritis) it would useful to talk with the perfmon > developers so we can eventually arrive at an upstreamed solution > and not have to worry about integrating out-of-tree patches. > Thanks Dave, this is an interesting information, so I am CCing the upstream author (just in case he is not subscribed to this list). Now I still wonder what to do here because: 1. it's not sure if this perfmon2 will be in Fedora kernels before F9 ships 2. sysprof has to be adapted to use perfmon2 I mean, it's clear that 1+2 it's the best thing we could come out with, but I'd like to have working sysprof in the repo until that materialize. To this end, please weight in that this is just a single module (one .c and its .h) loaded by the user only when needed. Of course, I can not argue with you about the implications of including this into the kernel package, but I really would like a B plan if we will not have a perfmon enabled kernel+userspace available in time. From davidz at redhat.com Sun Dec 2 07:04:01 2007 From: davidz at redhat.com (David Zeuthen) Date: Sun, 02 Dec 2007 02:04:01 -0500 Subject: Getting rid of sysprof-kmod In-Reply-To: <20071202000924.GA31160@redhat.com> References: <20071202000924.GA31160@redhat.com> Message-ID: <1196579041.4121.20.camel@oneill.fubar.dk> On Sat, 2007-12-01 at 19:09 -0500, Dave Jones wrote: > On Sun, Dec 02, 2007 at 01:02:23AM +0100, Gianluca Sforna wrote: > > Hi, > > I just finished removing the sysprof-kmod package from CVS as mandated > > by the new guidelines for F9 and above. > > > > I am now seeking some help to understand what is needed to have again > > the kernel module required for proper operations of the sysprof > > package. > > > > Upstream sources are at: > > http://www.daimi.au.dk/~sandmann/sysprof/ > > The upstream kernel is likely to eventually get support for > perfmon2 integrated, but this could really use more work. > It's been in -mm for a while. If there's anything that sysprof > can do that perfmon can't (which would be surprising given > perfmons featuritis) it would useful to talk with the perfmon > developers so we can eventually arrive at an upstreamed solution > and not have to worry about integrating out-of-tree patches. Until that happens can we please carry the patch in the Fedora kernel? IIRC it's not invasive at all. And it's really annoying not being able to use sysprof. Thanks. David From davej at redhat.com Sun Dec 2 07:10:40 2007 From: davej at redhat.com (Dave Jones) Date: Sun, 2 Dec 2007 02:10:40 -0500 Subject: Getting rid of sysprof-kmod In-Reply-To: <1196579041.4121.20.camel@oneill.fubar.dk> References: <20071202000924.GA31160@redhat.com> <1196579041.4121.20.camel@oneill.fubar.dk> Message-ID: <20071202071040.GA7565@redhat.com> On Sun, Dec 02, 2007 at 02:04:01AM -0500, David Zeuthen wrote: > > > Upstream sources are at: > > > http://www.daimi.au.dk/~sandmann/sysprof/ > > > > The upstream kernel is likely to eventually get support for > > perfmon2 integrated, but this could really use more work. > > It's been in -mm for a while. If there's anything that sysprof > > can do that perfmon can't (which would be surprising given > > perfmons featuritis) it would useful to talk with the perfmon > > developers so we can eventually arrive at an upstreamed solution > > and not have to worry about integrating out-of-tree patches. > > Until that happens can we please carry the patch in the Fedora kernel? > IIRC it's not invasive at all. And it's really annoying not being able > to use sysprof. Thanks. The problem is I really hate adding patches that provide new user interfaces. It's easy enough to add it, but it'll be a 'fedora-ism' that doesn't work in any other distro, or with an upstream kernel. And what happens if someone starts building more things on top of the sysprof exports? It's the same reason patches that add syscalls get vetoed. We don't want to be in a situation where it appears we're locking users into running our distro/kernel. Dave -- http://www.codemonkey.org.uk From euromili02 at aim.com Sun Dec 2 13:42:29 2007 From: euromili02 at aim.com (Euro Million Spanish Loteria) Date: Sun, 2 Dec 2007 13:42:29 GMT Subject: CLAIM YOUR EMAIL AWARD IN 2007 SPANISH LOTERIA Message-ID: <200712021342.lB2DgTFV052616@freeolaweb4.freeola.net> EURO MILLIONES LOTERIA DE ESPA?A REFERENCE: 200/090/SPS BATCH: JSJ-001-226-997 We wish to inform you that your email address has been awarded the sum of One Million Five Hundred and Fifty Thousand Euros (?1.550,000.00) Euros in the Euro Million Spanish Loteria and you have been therefore adviced to contact your claims agent on telephone:0034-650-584-551 DINERO SECURITY EXPRESS.S.A Mr. Peter Sanchez, Email:infdinerosexpress at gmail.com Regards, Mrs Linda Carol From davidz at redhat.com Sun Dec 2 21:33:06 2007 From: davidz at redhat.com (David Zeuthen) Date: Sun, 02 Dec 2007 16:33:06 -0500 Subject: Getting rid of sysprof-kmod In-Reply-To: <20071202071040.GA7565@redhat.com> References: <20071202000924.GA31160@redhat.com> <1196579041.4121.20.camel@oneill.fubar.dk> <20071202071040.GA7565@redhat.com> Message-ID: <1196631186.7278.20.camel@oneill.fubar.dk> On Sun, 2007-12-02 at 02:10 -0500, Dave Jones wrote: > On Sun, Dec 02, 2007 at 02:04:01AM -0500, David Zeuthen wrote: > The problem is I really hate adding patches that provide new user interfaces. > It's easy enough to add it, but it'll be a 'fedora-ism' that doesn't work > in any other distro, or with an upstream kernel. And what happens > if someone starts building more things on top of the sysprof exports? > > It's the same reason patches that add syscalls get vetoed. We don't > want to be in a situation where it appears we're locking users into > running our distro/kernel. What if the sysprof author offered a. to maintain the patch in the SRPM (e.g. make sure it works) b. to work with upstream to either get it his patch in or migrate to another interface when available Would that work? Dave? S?ren? David From giallu at gmail.com Sun Dec 2 23:56:59 2007 From: giallu at gmail.com (Gianluca Sforna) Date: Mon, 3 Dec 2007 00:56:59 +0100 Subject: Getting rid of sysprof-kmod In-Reply-To: <1196631186.7278.20.camel@oneill.fubar.dk> References: <20071202000924.GA31160@redhat.com> <1196579041.4121.20.camel@oneill.fubar.dk> <20071202071040.GA7565@redhat.com> <1196631186.7278.20.camel@oneill.fubar.dk> Message-ID: On Dec 2, 2007 10:33 PM, David Zeuthen wrote: > > What if the sysprof author offered > > a. to maintain the patch in the SRPM (e.g. make sure it works) This looks like an easy target; I can witness the module sources always worked since the package entered in the repo (around FC5 IIRC). The few occasional glitches were promptly fixed > b. to work with upstream to either get it his patch in or migrate > to another interface when available Well, last time I asked, the former was not going to happen and I fear the latter will be too late for F9... From dwmw2 at infradead.org Mon Dec 3 14:03:03 2007 From: dwmw2 at infradead.org (David Woodhouse) Date: Mon, 03 Dec 2007 14:03:03 +0000 Subject: [RFC] Kernel subpackage for zImage wrapper. Message-ID: <1196690583.13978.151.camel@pmac.infradead.org> In arch/powerpc/boot/ in the kernel, there is wrapper code which lets you make a combined zImage from fairly much arbitrary kernels and ramdisks. We use it outside the context of the kernel build, for building installer images, etc. For a while we've had a copy -- in fact, two copies of different vintages -- of this in the ppc64-utils package. This was about as sensible as glibc-kernheaders was, and while upstream dicked around with load addresses and other things to try to make sure it's compatible with as many machines as possible, we lagged behind. Just as we do now for headers, I'd like to spit out a 'kernel-bootwrapper' subpackage when we build the kernel. It depends on a patch introducing 'make bootloader_install' which has been sent upstream and will hopefully be accepted; the resulting bootwrapper package has been confirmed to work for Efika (ppc32), Electra (the new PA Semi ppc64 machine) and PS3. Dave, Chuck -- does this look OK? Index: kernel.spec =================================================================== RCS file: /cvs/pkgs/rpms/kernel/devel/kernel.spec,v retrieving revision 1.273 diff -u -p -r1.273 kernel.spec --- kernel.spec 3 Dec 2007 03:01:18 -0000 1.273 +++ kernel.spec 3 Dec 2007 04:35:36 -0000 @@ -80,6 +80,8 @@ Summary: The Linux kernel (the core of t %define with_headers %{?_without_headers: 0} %{?!_without_headers: 1} # kernel-debuginfo %define with_debuginfo %{?_without_debuginfo: 0} %{!?_without_debuginfo: 1} +# kernel-bootwrapper (for creating zImages from kernel + initrd) +%define with_bootwrapper %{?_without_bootwrapper: 0} %{!?_without_bootwrapper: 1} # Additional options for user-friendly one-off kernel building: # @@ -261,6 +263,11 @@ Summary: The Linux kernel (the core of t %define all_arch_configs kernel-%{version}-*.config %endif +# bootwrapper is only on ppc +%ifnarch ppc +%define with_bootwrapper 0 +%endif + # sparse blows up on ppc64 %ifarch ppc64 ppc alpha sparc64 %define usesparse 0 @@ -678,6 +686,12 @@ header files define structures and const building most standard programs and are also needed for rebuilding the glibc package. +%package bootwrapper +Summary: Boot wrapper files for generating combined kernel + initrd images +Group: Development/System +%description bootwrapper +Kernel-bootwrapper contains the wrapper code which makes bootable "zImage" +files combining both kernel and initial ramdisk. %package debuginfo-common Summary: Kernel source files used by %{name}-debuginfo packages @@ -1551,6 +1566,10 @@ rm -f $RPM_BUILD_ROOT/usr/include/asm*/i rm -f $RPM_BUILD_ROOT/usr/include/asm*/irq.h %endif +%if %{with_bootwrapper} +make DESTDIR=$RPM_BUILD_ROOT bootwrapper_install +%endif + ### ### clean ### @@ -1646,6 +1665,13 @@ fi /usr/include/* %endif +%if %{with_bootwrapper} +%files bootwrapper +%defattr(-,root,root) +/usr/sbin/* +%{_libdir}/kernel-wrapper +%endif + # only some architecture builds need kernel-doc %if %{with_doc} %files doc -- dwmw2 From roland at redhat.com Mon Dec 3 22:39:09 2007 From: roland at redhat.com (Roland McGrath) Date: Mon, 3 Dec 2007 14:39:09 -0800 (PST) Subject: [RFC] Kernel subpackage for zImage wrapper. In-Reply-To: David Woodhouse's message of Monday, 3 December 2007 14:03:03 +0000 <1196690583.13978.151.camel@pmac.infradead.org> References: <1196690583.13978.151.camel@pmac.infradead.org> Message-ID: <20071203223909.6476D26F8A0@magilla.localdomain> > +# bootwrapper is only on ppc > +%ifnarch ppc Not ppc64 too? From dwmw2 at infradead.org Mon Dec 3 22:41:43 2007 From: dwmw2 at infradead.org (David Woodhouse) Date: Mon, 03 Dec 2007 22:41:43 +0000 Subject: [RFC] Kernel subpackage for zImage wrapper. In-Reply-To: <20071203223909.6476D26F8A0@magilla.localdomain> References: <1196690583.13978.151.camel@pmac.infradead.org> <20071203223909.6476D26F8A0@magilla.localdomain> Message-ID: <1196721703.13978.188.camel@pmac.infradead.org> On Mon, 2007-12-03 at 14:39 -0800, Roland McGrath wrote: > > +# bootwrapper is only on ppc > > +%ifnarch ppc > > Not ppc64 too? It's building a userspace package. There is little benefit to doing it for ppc64, although I suppose I might as well. The wrapper code itself is 32-bit, either way. -- dwmw2 From giallu at gmail.com Tue Dec 4 13:05:18 2007 From: giallu at gmail.com (Gianluca Sforna) Date: Tue, 4 Dec 2007 14:05:18 +0100 Subject: Getting rid of sysprof-kmod In-Reply-To: <20071202071040.GA7565@redhat.com> References: <20071202000924.GA31160@redhat.com> <1196579041.4121.20.camel@oneill.fubar.dk> <20071202071040.GA7565@redhat.com> Message-ID: On Dec 2, 2007 8:10 AM, Dave Jones wrote: > The problem is I really hate adding patches that provide new user interfaces. I understand this concern > It's easy enough to add it, but it'll be a 'fedora-ism' that doesn't work > in any other distro, or with an upstream kernel. I can't grok this sentence. what do stop working upstream if we add this? > And what happens > if someone starts building more things on top of the sysprof exports? Who should be this "someone"? Anyway, the answer looks like: he get bite when we will drop the patch. How bad is it? > > It's the same reason patches that add syscalls get vetoed. We don't > want to be in a situation where it appears we're locking users into > running our distro/kernel. Of all the complaints I have seen in the past about our kernels, this never shown up, but I'm sure you collected much more than me... Point is, you are the kernel maintainer here so, though I can't fully understand your concerns, I assume they are valid and I better stop arguing on things I can not fully evaluate. So my last question for you is: how are those scenarios likely? I mean, do you see a concrete risk someone will build something on top of the current sysprof interface? It would be really a pity (and a regression) if sysprof will lack the binary module because of some recondite reason. From dwmw2 at infradead.org Tue Dec 4 14:18:09 2007 From: dwmw2 at infradead.org (David Woodhouse) Date: Tue, 04 Dec 2007 14:18:09 +0000 Subject: CONFIG_RTC_HCTOSYS In-Reply-To: <200709252307.l8PN7La8027531@cvs-int.fedora.redhat.com> References: <200709252307.l8PN7La8027531@cvs-int.fedora.redhat.com> Message-ID: <1196777889.13978.252.camel@pmac.infradead.org> On Tue, 2007-09-25 at 19:07 -0400, Dave Jones wrote: > Author: davej > > Update of /cvs/pkgs/rpms/kernel/devel > In directory cvs-int.fedora.redhat.com:/tmp/cvs-serv27402 > > Modified Files: > config-generic kernel.spec > Log Message: > * Tue Sep 25 2007 Dave Jones > - Disable RTC_HCTOSYS. The initscripts already do this for us. True, they do (once we fix #409551 and preferably also stop mkinitrd from creating the device node with the old numbers). The installer doesn't though, as far as I know. It would need to do so. Once we've started setting the clock in userspace, it then makes a certain amount of sense to have the RTC drivers as modules instead of building them in. We'd need to make sure the right driver gets autoloaded, but that isn't particularly hard. While we're at it, I'd also quite like to have a sanity check after setting the clock in rc.sysinit -- if it's before 2000 or so, I'd like to set it from the latest timestamp found in /var/log. That's _also_ going to be wrong, but it's not going to be _so_ wrong that it prevents you from even being able to log in as root to a VT :) -- dwmw2 From sandmann at redhat.com Tue Dec 4 20:57:43 2007 From: sandmann at redhat.com (Soeren Sandmann Pedersen) Date: 04 Dec 2007 15:57:43 -0500 Subject: Getting rid of sysprof-kmod In-Reply-To: References: <20071202000924.GA31160@redhat.com> <1196579041.4121.20.camel@oneill.fubar.dk> <20071202071040.GA7565@redhat.com> <1196631186.7278.20.camel@oneill.fubar.dk> Message-ID: "Gianluca Sforna" writes: > > What if the sysprof author offered > > > > a. to maintain the patch in the SRPM (e.g. make sure it works) > > This looks like an easy target; I can witness the module sources > always worked since the package entered in the repo (around FC5 IIRC). > The few occasional glitches were promptly fixed I'd certainly be happy to do this, or help out as necessary. > > b. to work with upstream to either get it his patch in or migrate > > to another interface when available > > Well, last time I asked, the former was not going to happen and I fear > the latter will be too late for F9... I am not opposed to getting sysprof into the upstream kernel on some general principle; I'm just not sure I am ready to set the interface in stone. And I'm not sure if they'd take it. As for perfmon2, I haven't looked at it in a long time, but assuming it's a superset of the oprofile interface, here are the main things that sysprof does that oprofile doesn't (or didn't last time I looked at it): - poll() - non-blocking read() - partial reads - Lost samples (ie. samples where the instruction pointer is not inside the text segment of a library) should be reported. Otherwise things like JIT compilers or old X servers will not be profiled correctly. - Idle events should not be sent to the client since they just use bandwidth. - The ability to take kernel stacktraces even when the kernel was compiled with -fomit-framepointer. Ie., do a conservative backtrace. - The ability to take stacktraces of userspace, even when the interrupt happened in kernel mode. Ie,. trace both the kernel and the user stack. - The ability to mmap() the sample buffer to avoid copying the information more than once. Finally, one other thing that oprofile doesn't have, is a simple API. I did actually at one point write code to make sysprof use the oprofile module, but the result was not very nice: It involved mounting a special file system and then opening a bunch of files, then writing configuration information to those files. All those calls could potentially fail, requiring graphical applications to pop up dialogs with gobbledigook messages. Parsing the output then required an elaborate statemachine that was further complicated by the need to deal with partial reads. All this required more than a thousand lines of code, compared to about 50 for the sysprof interface. But, this is mostly whining; I can deal with a complicated interface if I have to. Soren From davej at redhat.com Tue Dec 4 21:13:52 2007 From: davej at redhat.com (Dave Jones) Date: Tue, 4 Dec 2007 16:13:52 -0500 Subject: Getting rid of sysprof-kmod In-Reply-To: References: <20071202000924.GA31160@redhat.com> <1196579041.4121.20.camel@oneill.fubar.dk> <20071202071040.GA7565@redhat.com> <1196631186.7278.20.camel@oneill.fubar.dk> Message-ID: <20071204211352.GA10815@redhat.com> On Tue, Dec 04, 2007 at 03:57:43PM -0500, Soeren Sandmann Pedersen wrote: > As for perfmon2, I haven't looked at it in a long time, but assuming > it's a superset of the oprofile interface bad assumption. The two are completely separate things. In theory oprofile could be rewritten to be a 'personality' of perfmon2. It's a lot more capable. (One complaint against its inclusion right now is that it's _too_ feature rich) Dave -- http://www.codemonkey.org.uk From sandmann at redhat.com Tue Dec 4 21:32:27 2007 From: sandmann at redhat.com (Soeren Sandmann Pedersen) Date: 04 Dec 2007 16:32:27 -0500 Subject: Getting rid of sysprof-kmod In-Reply-To: <20071204211352.GA10815@redhat.com> References: <20071202000924.GA31160@redhat.com> <1196579041.4121.20.camel@oneill.fubar.dk> <20071202071040.GA7565@redhat.com> <1196631186.7278.20.camel@oneill.fubar.dk> <20071204211352.GA10815@redhat.com> Message-ID: Dave Jones writes: > On Tue, Dec 04, 2007 at 03:57:43PM -0500, Soeren Sandmann Pedersen wrote: > > > As for perfmon2, I haven't looked at it in a long time, but assuming > > it's a superset of the oprofile interface > > bad assumption. The two are completely separate things. > In theory oprofile could be rewritten to be a 'personality' of > perfmon2. So that would make perfmon2 features a superset of oprofile features. In that case, if it has the features I listed as missing from oprofile, sysprof could use it. Soren From mauricio at projetofedora.org Thu Dec 6 08:03:54 2007 From: mauricio at projetofedora.org (Mauricio Pretto) Date: Thu, 06 Dec 2007 09:03:54 +0100 Subject: iwl4965 issues Message-ID: <4757ACEA.7040903@projetofedora.org> Hello everybody I hope this is the right place for that. My iwl4965 never been stable in my fedora 8, for sure its getting better but still i have some weird issues. Like when switching off/on the hardware the load goes really high, but my posting today is about something very unusual for me. I use my laptop in different places, but at the office i got a very unusual behavior. When i get to the office i need to turn the computer on with the hardware switch off, if not i will get a kernel panic as you can see in this link: http://www.eunomundo.com.br/gallery2/main.php?g2_itemId=25855 My machine info is at: http://smolt.fedoraproject.org/show_all?UUID=9e1cb972-a95c-4ed3-b84a-77c6f633fced Regards -- Pretto http://fedoraproject.org/wiki/MauricioPretto From feng.xian at gmail.com Thu Dec 6 21:06:54 2007 From: feng.xian at gmail.com (Feng Xian) Date: Thu, 6 Dec 2007 15:06:54 -0600 Subject: create a kernel buffer from user-level Message-ID: <610b3d450712061306q5a8dd53duf934a038fc8a7f46@mail.gmail.com> I am doing a project related to thread scheduling. This project needs communication between kernel and user-level applications. Basically, the user-level application sets or unset a bit in a bit vector, according to the application's status (this part is not related to this question, so I skip it). Then the kernel reads the bit vector everytime it schedules a thread. My question is where to allocate the bit vector. 1. If I allocate the bit vector in user-level, then everytime the kernel wants to read the bit vector, I has to do a copy_from_user(). I tried this solution, this incurs a lot of overhead and also crash the os. Since the copy_from_user() needs to look up the virtual address which corresponds to the starting address of bit-vector, it will cause paging in the middle of scheduling. Is there any other way that the kernel can directly access user-level space without doing copying and address translation? 2. If I allocate the bit vector directly in the kernel space. How can I do this? Is it possible to create an extra system call that allows user-level program to allocate a kernel buffer? Could anyone help me out on this? Thanks! -- Addr: 1025N, 23rd str, APT 33, Lincoln, NE, 68503 Phone: (402)310-9826 WWW: cse.unl.edu/~fxian -------------- next part -------------- An HTML attachment was scrubbed... URL: From davej at redhat.com Thu Dec 6 21:20:19 2007 From: davej at redhat.com (Dave Jones) Date: Thu, 6 Dec 2007 16:20:19 -0500 Subject: create a kernel buffer from user-level In-Reply-To: <610b3d450712061306q5a8dd53duf934a038fc8a7f46@mail.gmail.com> References: <610b3d450712061306q5a8dd53duf934a038fc8a7f46@mail.gmail.com> Message-ID: <20071206212019.GB22836@redhat.com> On Thu, Dec 06, 2007 at 03:06:54PM -0600, Feng Xian wrote: > I am doing a project related to thread scheduling. This project needs > communication between kernel and user-level applications. Basically, the > user-level application sets or unset a bit in a bit vector, according to the > application's status (this part is not related to this question, so I skip > it). Then the kernel reads the bit vector everytime it schedules a thread. > My question is where to allocate the bit vector. > 1. If I allocate the bit vector in user-level, then everytime the kernel > wants to read the bit vector, I has to do a copy_from_user(). I tried this > solution, this incurs a lot of overhead and also crash the os. Since the > copy_from_user() needs to look up the virtual address which corresponds to > the starting address of bit-vector, it will cause paging in the middle of > scheduling. Is there any other way that the kernel can directly access > user-level space without doing copying and address translation? > > 2. If I allocate the bit vector directly in the kernel space. How can I do > this? Is it possible to create an extra system call that allows user-level > program to allocate a kernel buffer? > > Could anyone help me out on this? Thanks! Try the kernelnewbies list at http://kernelnewbies.org/ML or linux-kernel at vger.kernel.org. Your problem isn't related specifically to the Fedora kernel, so is off-topic here. Dave -- http://www.codemonkey.org.uk From tjb at unh.edu Thu Dec 6 21:33:56 2007 From: tjb at unh.edu (Thomas J. Baker) Date: Thu, 06 Dec 2007 16:33:56 -0500 Subject: Precision 490 Reboot Hang Message-ID: <1196976836.10697.11.camel@raptor.sr.unh.edu> I've got a Precision 490 that hangs at reboot unless I use reboot=bios on the kernel command line. A bug filed against the kernel should include what other information? Thanks, tjb -- ======================================================================= | Thomas Baker email: tjb at unh.edu | | Systems Programmer | | Research Computing Center voice: (603) 862-4490 | | University of New Hampshire fax: (603) 862-1761 | | 332 Morse Hall | | Durham, NH 03824 USA http://wintermute.sr.unh.edu/~tjb | ======================================================================= From davej at redhat.com Thu Dec 6 21:45:44 2007 From: davej at redhat.com (Dave Jones) Date: Thu, 6 Dec 2007 16:45:44 -0500 Subject: Precision 490 Reboot Hang In-Reply-To: <1196976836.10697.11.camel@raptor.sr.unh.edu> References: <1196976836.10697.11.camel@raptor.sr.unh.edu> Message-ID: <20071206214544.GD22836@redhat.com> On Thu, Dec 06, 2007 at 04:33:56PM -0500, Thomas J. Baker wrote: > > I've got a Precision 490 that hangs at reboot unless I use reboot=bios > on the kernel command line. A bug filed against the kernel should > include what other information? dmidecode output. Dave -- http://www.codemonkey.org.uk From jwilson at redhat.com Thu Dec 6 21:47:29 2007 From: jwilson at redhat.com (Jarod Wilson) Date: Thu, 06 Dec 2007 16:47:29 -0500 Subject: Precision 490 Reboot Hang In-Reply-To: <1196976836.10697.11.camel@raptor.sr.unh.edu> References: <1196976836.10697.11.camel@raptor.sr.unh.edu> Message-ID: <47586DF1.8070506@redhat.com> Thomas J. Baker wrote: > I've got a Precision 490 that hangs at reboot unless I use reboot=bios > on the kernel command line. A bug filed against the kernel should > include what other information? I might suggest looking for a BIOS update and/or downgrade before you file any bugs. I've got a Precision 490 here that reboots just peachy. Dell actually has bios updates that can be done from Linux on these boxes. -- Jarod Wilson jwilson at redhat.com -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 251 bytes Desc: OpenPGP digital signature URL: From roland at redhat.com Thu Dec 6 21:52:19 2007 From: roland at redhat.com (Roland McGrath) Date: Thu, 6 Dec 2007 13:52:19 -0800 (PST) Subject: Precision 490 Reboot Hang In-Reply-To: Thomas J. Baker's message of Thursday, 6 December 2007 16:33:56 -0500 <1196976836.10697.11.camel@raptor.sr.unh.edu> References: <1196976836.10697.11.camel@raptor.sr.unh.edu> Message-ID: <20071206215219.990A926F8D9@magilla.localdomain> I've had the same problem and not gotten around to reporting it. I hadn't tried reboot=bios. For me, x86_64 kernels reboot fine but i386 kernels hang at reboot, on the same machine. Mine has BIOS version A06, and behaved the same with A04 before upgrading. This started in upstream kernels between 2.6.22 and 2.6.23 IIRC, and Fedora kernels since 2.6.23 behave the same as my hand-built upstream kernels. Sometimes sysrq-b works on a boot where formal reboot hangs, though once in a while it hangs at sysrq-b too. Possibly relevant, boot messages include: ACPI: System BIOS is requesting _OSI(Linux) ACPI: If "acpi_osi=Linux" works better, Please send dmidecode to linux-acpi at vger.kernel.org I haven't tried any acpi*= or reboot= kernel options. Thanks, Roland From tjb at unh.edu Fri Dec 7 13:38:38 2007 From: tjb at unh.edu (Thomas J. Baker) Date: Fri, 07 Dec 2007 08:38:38 -0500 Subject: Precision 490 Reboot Hang In-Reply-To: <47586DF1.8070506@redhat.com> References: <1196976836.10697.11.camel@raptor.sr.unh.edu> <47586DF1.8070506@redhat.com> Message-ID: <1197034718.29360.1.camel@raptor.sr.unh.edu> On Thu, 2007-12-06 at 16:47 -0500, Jarod Wilson wrote: > Thomas J. Baker wrote: > > I've got a Precision 490 that hangs at reboot unless I use reboot=bios > > on the kernel command line. A bug filed against the kernel should > > include what other information? > > I might suggest looking for a BIOS update and/or downgrade before you > file any bugs. I've got a Precision 490 here that reboots just peachy. > Dell actually has bios updates that can be done from Linux on these boxes. > I'm running the latest BIOS as it was shipped with the machine. I'd rather use reboot=bios than run an old BIOS. Thanks, tjb -- ======================================================================= | Thomas Baker email: tjb at unh.edu | | Systems Programmer | | Research Computing Center voice: (603) 862-4490 | | University of New Hampshire fax: (603) 862-1761 | | 332 Morse Hall | | Durham, NH 03824 USA http://wintermute.sr.unh.edu/~tjb | ======================================================================= From jwilson at redhat.com Fri Dec 7 14:35:07 2007 From: jwilson at redhat.com (Jarod Wilson) Date: Fri, 07 Dec 2007 09:35:07 -0500 Subject: Precision 490 Reboot Hang In-Reply-To: <1197034718.29360.1.camel@raptor.sr.unh.edu> References: <1196976836.10697.11.camel@raptor.sr.unh.edu> <47586DF1.8070506@redhat.com> <1197034718.29360.1.camel@raptor.sr.unh.edu> Message-ID: <47595A1B.9040303@redhat.com> Thomas J. Baker wrote: > On Thu, 2007-12-06 at 16:47 -0500, Jarod Wilson wrote: >> Thomas J. Baker wrote: >>> I've got a Precision 490 that hangs at reboot unless I use reboot=bios >>> on the kernel command line. A bug filed against the kernel should >>> include what other information? >> I might suggest looking for a BIOS update and/or downgrade before you >> file any bugs. I've got a Precision 490 here that reboots just peachy. >> Dell actually has bios updates that can be done from Linux on these boxes. >> > > I'm running the latest BIOS as it was shipped with the machine. I'd > rather use reboot=bios than run an old BIOS. Sorry, I was suggesting it more as a "see if this is a bios issue and not a kernel issue" than "fix it by running an old bios". Did you see Roland's note about his own 490? He said his only fails to reboot when running an i386 kernel, but works fine w/an x86_64 kernel, which doesn't conflict with what I've seen, since mine's also running an x86_64 kernel. He also mentioned that this started sometime between 2.6.22 and 2.6.23. If you are indeed running a 32-bit kernel, it sounds like an i686-specific kernel bug. -- Jarod Wilson jwilson at redhat.com -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 251 bytes Desc: OpenPGP digital signature URL: From tjb at unh.edu Fri Dec 7 14:42:16 2007 From: tjb at unh.edu (Thomas J. Baker) Date: Fri, 07 Dec 2007 09:42:16 -0500 Subject: Precision 490 Reboot Hang In-Reply-To: <47595A1B.9040303@redhat.com> References: <1196976836.10697.11.camel@raptor.sr.unh.edu> <47586DF1.8070506@redhat.com> <1197034718.29360.1.camel@raptor.sr.unh.edu> <47595A1B.9040303@redhat.com> Message-ID: <1197038536.19259.5.camel@continuity> On Fri, 2007-12-07 at 09:35 -0500, Jarod Wilson wrote: > Thomas J. Baker wrote: > > On Thu, 2007-12-06 at 16:47 -0500, Jarod Wilson wrote: > >> Thomas J. Baker wrote: > >>> I've got a Precision 490 that hangs at reboot unless I use reboot=bios > >>> on the kernel command line. A bug filed against the kernel should > >>> include what other information? > >> I might suggest looking for a BIOS update and/or downgrade before you > >> file any bugs. I've got a Precision 490 here that reboots just peachy. > >> Dell actually has bios updates that can be done from Linux on these boxes. > >> > > > > I'm running the latest BIOS as it was shipped with the machine. I'd > > rather use reboot=bios than run an old BIOS. > > Sorry, I was suggesting it more as a "see if this is a bios issue and > not a kernel issue" than "fix it by running an old bios". Did you see > Roland's note about his own 490? He said his only fails to reboot when > running an i386 kernel, but works fine w/an x86_64 kernel, which doesn't > conflict with what I've seen, since mine's also running an x86_64 > kernel. He also mentioned that this started sometime between 2.6.22 and > 2.6.23. If you are indeed running a 32-bit kernel, it sounds like an > i686-specific kernel bug. > Yes, I did and I should have added that the system has an i386 F8 installation so it does look to be an i686 kernel problem. I don't really want to run an x86_64 kernel on this system as the eventual user doesn't really have a need for it. I'll update the bug. He also said A04 had the same problem so it would seem A05 probably wouldn't help much. Thanks, tjb -- ======================================================================= | Thomas Baker email: tjb at unh.edu | | Systems Programmer | | Research Computing Center voice: (603) 862-4490 | | University of New Hampshire fax: (603) 862-1761 | | 332 Morse Hall | | Durham, NH 03824 USA http://wintermute.sr.unh.edu/~tjb | ======================================================================= From webmaster at equipashop.com.br Mon Dec 10 20:10:08 2007 From: webmaster at equipashop.com.br (webmaster at equipashop.com.br) Date: Mon, 10 Dec 2007 18:10:08 -0200 Subject: Coifa Message-ID: <200712110508.lBB586hk023404@mx3.redhat.com> An HTML attachment was scrubbed... URL: From sbnspringdoor3 at tom.com Tue Dec 11 07:12:23 2007 From: sbnspringdoor3 at tom.com (=?GB2312?Q?Steven(SPRING_DOOR)?=) Date: Tue, 11 Dec 2007 15:12:23 +0800 Subject: Quotation of the steel door Message-ID: <475EB7ED.79F26A.10839> this is a html format email,your mail system is nonsuport showed at the moment.
Dear Sir or Madam   Have a good day! I hope your business goes well. Very glad to introduce our factory to you,as a professional door's manufacturer,if you interested in purchasing the steel door,we can supply the best price of the steel door to you, detailen information as follows:Steel doorMaterial: cold-rolled steel sheet with honeycombSize:2050*860/900/960mmDoor leaf thinkness:50mm,70mmPacking:strong cartonDelivery time: within20days after receive your depositPrice: FOB NINGBO 64.8USD(the material thinkness door leaf 0.6mm,door frame 1.2mm)Conveyance: Qty/20' FCL: 106-144pcs Qty/40' GP: 222-298pcs Qty/40' HQ: 224-334pcs Waiting for your reply. Best regardsSteven YongKang Spring Industry CO.LTD ADD: Lange Industrial Zone, YongKang, ZheJiang, China TEL: 86-579-87208596 FAX: 86-579-87294599 E-mail: sbn3 at cnspringdoor.com Website: www.cnspringdoor.com -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: SBN-8023-1.jpg Type: application/octet-stream Size: 44259 bytes Desc: SBN-8023-1.jpg URL: From snecklifter at gmail.com Wed Dec 12 16:45:30 2007 From: snecklifter at gmail.com (Christopher Brown) Date: Wed, 12 Dec 2007 16:45:30 +0000 Subject: Bug triage - next step Message-ID: <364d303b0712120845s7eff1460m15edec97c3ca2c6@mail.gmail.com> Hello Dave, Chuck et al, I'm back from the extended break and intend to review F7 bugs once more with a view to closing those that have not responded to gentle nudging for more info. In general these will have been dormant for 2-3 months. Unless there are any objections I intend to start this process within the next few days. Hopefully then the bug count will rapidly start to look less manic and the important stuff will bubble to the surface a little more clearly. Cheers -- Christopher Brown http://www.chruz.com From davej at redhat.com Wed Dec 12 17:35:07 2007 From: davej at redhat.com (Dave Jones) Date: Wed, 12 Dec 2007 12:35:07 -0500 Subject: Bug triage - next step In-Reply-To: <364d303b0712120845s7eff1460m15edec97c3ca2c6@mail.gmail.com> References: <364d303b0712120845s7eff1460m15edec97c3ca2c6@mail.gmail.com> Message-ID: <20071212173507.GB18973@redhat.com> On Wed, Dec 12, 2007 at 04:45:30PM +0000, Christopher Brown wrote: > Hello Dave, Chuck et al, > > I'm back from the extended break and intend to review F7 bugs once > more with a view to closing those that have not responded to gentle > nudging for more info. In general these will have been dormant for 2-3 > months. Unless there are any objections I intend to start this process > within the next few days. Hopefully then the bug count will rapidly > start to look less manic and the important stuff will bubble to the > surface a little more clearly. Sounds worthwhile to me. Thanks for your help. Dave -- http://www.codemonkey.org.uk From saccular at zna.com Thu Dec 13 00:57:59 2007 From: saccular at zna.com (Wela Huesso) Date: Thu, 13 Dec 2007 00:57:59 +0000 Subject: prologuizers Message-ID: <9266131470.20071213005635@zna.com> Halloha, Virus found in this message, please delete it without futher reading Not in the delicate and softe: and in those that nor he, who speaks falsely or indulges in idle we were in the pantry. antoinette was ill and. -------------- next part -------------- An HTML attachment was scrubbed... URL: From split at zoobaz.com Thu Dec 13 12:52:52 2007 From: split at zoobaz.com (Matthes Altmiller) Date: Thu, 13 Dec 2007 12:52:52 +0000 Subject: inboards Message-ID: <3426663437.20071213125019@zoobaz.com> Ahn nyeong, Virus found in this message, please delete it without futher reading And in all probability she did kill mary gerrard. Else?? a relation? No? Some business matter? I looking at? Jock and babie, who were on a good. -------------- next part -------------- An HTML attachment was scrubbed... URL: From eparis at redhat.com Thu Dec 13 15:58:38 2007 From: eparis at redhat.com (Eric Paris) Date: Thu, 13 Dec 2007 10:58:38 -0500 Subject: enable null pointer hardening by default Message-ID: <1197561518.3005.47.camel@localhost.localdomain> I'd like to see the fedora kernel enable the null pointer hardening work I did upstream by default. http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=ed0321895182ffb6ecf210e066d87911b270d587 Upstream refused to turn it on as it is known to break non-root users of dosemu and they felt very strongly that not one user could break. It can be easily disabled with an entry in sysctl.conf for any such users. Certainly turning this on is something we would want to release note in F9 (which I don't know the process to do) This must not be applied to F8 until at least after the rebase to 2.6.24 as the 2.6.23 implementation of my hardening work is known buggy and causes unneeded issues. Would anyone have a problem carrying this patch in fedora? This would be a forever fedora'ism. --- security/security.c | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/security/security.c b/security/security.c index 0e1f1f1..61787bb 100644 --- a/security/security.c +++ b/security/security.c @@ -23,7 +23,7 @@ extern struct security_operations dummy_security_ops; extern void security_fixup_ops(struct security_operations *ops); struct security_operations *security_ops; /* Initialized to NULL */ -unsigned long mmap_min_addr; /* 0 means no protection */ +unsigned long mmap_min_addr = 65536; /* protect first 64k */ static inline int verify(struct security_operations *ops) { From sandeen at redhat.com Thu Dec 13 16:07:54 2007 From: sandeen at redhat.com (Eric Sandeen) Date: Thu, 13 Dec 2007 10:07:54 -0600 Subject: enable null pointer hardening by default In-Reply-To: <1197561518.3005.47.camel@localhost.localdomain> References: <1197561518.3005.47.camel@localhost.localdomain> Message-ID: <476158DA.4060503@redhat.com> Eric Paris wrote: > I'd like to see the fedora kernel enable the null pointer hardening work > I did upstream by default. > > http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=ed0321895182ffb6ecf210e066d87911b270d587 > > Upstream refused to turn it on as it is known to break non-root users of > dosemu and they felt very strongly that not one user could break. It > can be easily disabled with an entry in sysctl.conf for any such users. > Certainly turning this on is something we would want to release note in > F9 (which I don't know the process to do) > > This must not be applied to F8 until at least after the rebase to 2.6.24 > as the 2.6.23 implementation of my hardening work is known buggy and > causes unneeded issues. > > Would anyone have a problem carrying this patch in fedora? This would > be a forever fedora'ism. Couldn't this default value be a kernel config option? (CONFIG_DEFAULT_MMAP_MIN_ADDR) or something less verbose... -Eric > --- > > security/security.c | 2 +- > 1 files changed, 1 insertions(+), 1 deletions(-) > > diff --git a/security/security.c b/security/security.c > index 0e1f1f1..61787bb 100644 > --- a/security/security.c > +++ b/security/security.c > @@ -23,7 +23,7 @@ extern struct security_operations dummy_security_ops; > extern void security_fixup_ops(struct security_operations *ops); > > struct security_operations *security_ops; /* Initialized to NULL */ > -unsigned long mmap_min_addr; /* 0 means no protection */ > +unsigned long mmap_min_addr = 65536; /* protect first 64k */ > > static inline int verify(struct security_operations *ops) > { > > > _______________________________________________ > Fedora-kernel-list mailing list > Fedora-kernel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-kernel-list From eparis at redhat.com Thu Dec 13 16:28:44 2007 From: eparis at redhat.com (Eric Paris) Date: Thu, 13 Dec 2007 11:28:44 -0500 Subject: enable null pointer hardening by default In-Reply-To: <476158DA.4060503@redhat.com> References: <1197561518.3005.47.camel@localhost.localdomain> <476158DA.4060503@redhat.com> Message-ID: <1197563325.3005.49.camel@localhost.localdomain> On Thu, 2007-12-13 at 10:07 -0600, Eric Sandeen wrote: > Eric Paris wrote: > > I'd like to see the fedora kernel enable the null pointer hardening work > > I did upstream by default. > > > > http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=ed0321895182ffb6ecf210e066d87911b270d587 > > > > Upstream refused to turn it on as it is known to break non-root users of > > dosemu and they felt very strongly that not one user could break. It > > can be easily disabled with an entry in sysctl.conf for any such users. > > Certainly turning this on is something we would want to release note in > > F9 (which I don't know the process to do) > > > > This must not be applied to F8 until at least after the rebase to 2.6.24 > > as the 2.6.23 implementation of my hardening work is known buggy and > > causes unneeded issues. > > > > Would anyone have a problem carrying this patch in fedora? This would > > be a forever fedora'ism. > > Couldn't this default value be a kernel config option? > (CONFIG_DEFAULT_MMAP_MIN_ADDR) or something less verbose... Sounds like a better idea to me. I'll push something like that upstream. And when you see it in a distro near you, lets turn it on! -Eric From kyle at mcmartin.ca Thu Dec 13 16:28:50 2007 From: kyle at mcmartin.ca (Kyle McMartin) Date: Thu, 13 Dec 2007 11:28:50 -0500 Subject: enable null pointer hardening by default In-Reply-To: <1197561518.3005.47.camel@localhost.localdomain> References: <1197561518.3005.47.camel@localhost.localdomain> Message-ID: <20071213162850.GA8815@fattire.cabal.ca> Hi Eric, On Thu, Dec 13, 2007 at 10:58:38AM -0500, Eric Paris wrote: > Would anyone have a problem carrying this patch in fedora? This would > be a forever fedora'ism. > Wouldn't it be better to just use sysctl in an init script to turn it on during boot (or, optionally, not.) as opposed to carrying a patch perpetually? regards, Kyle From eparis at redhat.com Thu Dec 13 16:31:30 2007 From: eparis at redhat.com (Eric Paris) Date: Thu, 13 Dec 2007 11:31:30 -0500 Subject: enable null pointer hardening by default In-Reply-To: <20071213162850.GA8815@fattire.cabal.ca> References: <1197561518.3005.47.camel@localhost.localdomain> <20071213162850.GA8815@fattire.cabal.ca> Message-ID: <1197563490.3005.52.camel@localhost.localdomain> On Thu, 2007-12-13 at 11:28 -0500, Kyle McMartin wrote: > Hi Eric, > > On Thu, Dec 13, 2007 at 10:58:38AM -0500, Eric Paris wrote: > > Would anyone have a problem carrying this patch in fedora? This would > > be a forever fedora'ism. > > > > Wouldn't it be better to just use sysctl in an init script to turn it on > during boot (or, optionally, not.) as opposed to carrying a patch > perpetually? I actually talked to the sysctl.conf owner first who said "if it is a good default for everyone turn it on in the kernel" which i tended to agree with. But I like Eric's way of enabling it better, especially since now every distro will have to choose to enable/disable rather than just having it ignorable. -Eric From kyle at mcmartin.ca Thu Dec 13 16:33:35 2007 From: kyle at mcmartin.ca (Kyle McMartin) Date: Thu, 13 Dec 2007 11:33:35 -0500 Subject: enable null pointer hardening by default In-Reply-To: <1197563490.3005.52.camel@localhost.localdomain> References: <1197561518.3005.47.camel@localhost.localdomain> <20071213162850.GA8815@fattire.cabal.ca> <1197563490.3005.52.camel@localhost.localdomain> Message-ID: <20071213163335.GB8815@fattire.cabal.ca> On Thu, Dec 13, 2007 at 11:31:30AM -0500, Eric Paris wrote: > I actually talked to the sysctl.conf owner first who said "if it is a > good default for everyone turn it on in the kernel" > Ah, I meant in a regular init script and using /etc/sysconfig/security or something. > which i tended to agree with. But I like Eric's way of enabling it > better, especially since now every distro will have to choose to > enable/disable rather than just having it ignorable. > Yeah, config option upstream is definitely the sanest way forward. :) cheers, Kyle From sandeen at redhat.com Thu Dec 13 17:03:50 2007 From: sandeen at redhat.com (Eric Sandeen) Date: Thu, 13 Dec 2007 11:03:50 -0600 Subject: enable null pointer hardening by default In-Reply-To: <1197563490.3005.52.camel@localhost.localdomain> References: <1197561518.3005.47.camel@localhost.localdomain> <20071213162850.GA8815@fattire.cabal.ca> <1197563490.3005.52.camel@localhost.localdomain> Message-ID: <476165F6.90600@redhat.com> Eric Paris wrote: > On Thu, 2007-12-13 at 11:28 -0500, Kyle McMartin wrote: >> Hi Eric, >> >> On Thu, Dec 13, 2007 at 10:58:38AM -0500, Eric Paris wrote: >>> Would anyone have a problem carrying this patch in fedora? This would >>> be a forever fedora'ism. >>> >> Wouldn't it be better to just use sysctl in an init script to turn it on >> during boot (or, optionally, not.) as opposed to carrying a patch >> perpetually? > > I actually talked to the sysctl.conf owner first who said "if it is a > good default for everyone turn it on in the kernel" > > which i tended to agree with. But I like Eric's way of enabling it > better, especially since now every distro will have to choose to > enable/disable rather than just having it ignorable. Having a sysctl to change it post-boot if desired may also still make sense, though? I guess it's sort of analogous to how selinux can be KConfig'd in certain ways, and later modified runtime. -Eric From eparis at redhat.com Thu Dec 13 17:05:05 2007 From: eparis at redhat.com (Eric Paris) Date: Thu, 13 Dec 2007 12:05:05 -0500 Subject: enable null pointer hardening by default In-Reply-To: <476165F6.90600@redhat.com> References: <1197561518.3005.47.camel@localhost.localdomain> <20071213162850.GA8815@fattire.cabal.ca> <1197563490.3005.52.camel@localhost.localdomain> <476165F6.90600@redhat.com> Message-ID: <1197565505.3005.54.camel@localhost.localdomain> On Thu, 2007-12-13 at 11:03 -0600, Eric Sandeen wrote: > Eric Paris wrote: > > On Thu, 2007-12-13 at 11:28 -0500, Kyle McMartin wrote: > >> Hi Eric, > >> > >> On Thu, Dec 13, 2007 at 10:58:38AM -0500, Eric Paris wrote: > >>> Would anyone have a problem carrying this patch in fedora? This would > >>> be a forever fedora'ism. > >>> > >> Wouldn't it be better to just use sysctl in an init script to turn it on > >> during boot (or, optionally, not.) as opposed to carrying a patch > >> perpetually? > > > > I actually talked to the sysctl.conf owner first who said "if it is a > > good default for everyone turn it on in the kernel" > > > > which i tended to agree with. But I like Eric's way of enabling it > > better, especially since now every distro will have to choose to > > enable/disable rather than just having it ignorable. > > Having a sysctl to change it post-boot if desired may also still make > sense, though? I guess it's sort of analogous to how selinux can be > KConfig'd in certain ways, and later modified runtime. Absolutely the sysctl is always going to be there (it already is /proc/sys/vm/mmap_min_addr). -Eric From pirate at canezin.com.br Fri Dec 14 21:28:09 2007 From: pirate at canezin.com.br (Hargis Harrigill) Date: Fri, 14 Dec 2007 21:28:09 +0000 Subject: spackle Message-ID: <1777859243.20071213212438@canezin.com.br> Hey, Virus found in this message, please delete it without futher reading And remembered that he was to dine with mr. Wetterman with a kind shake of the hand. He was a man of fine example of a similar kind is that of maeshow. -------------- next part -------------- An HTML attachment was scrubbed... URL: From saccular at zna.com Fri Dec 14 08:18:40 2007 From: saccular at zna.com (Wela Huesso) Date: Fri, 14 Dec 2007 08:18:40 +0000 Subject: prologuizers Message-ID: <9266131470.20071214082142@zna.com> Halloha, Virus found in this message, please delete it without futher reading Not in the delicate and softe: and in those that nor he, who speaks falsely or indulges in idle we were in the pantry. antoinette was ill and. -------------- next part -------------- An HTML attachment was scrubbed... URL: From muzzier at artsnashville.org Tue Dec 18 10:03:56 2007 From: muzzier at artsnashville.org (Garvin Desroberts) Date: Tue, 18 Dec 2007 10:03:56 +0000 Subject: campy Message-ID: <4206935062.20071218095944@artsnashville.org> Salut, Downloaddable Sofftware http://www.geocities.com/n1mzl273lywhsfr/ Still on the american ship. Then why you say goo'bye the elephant's rope with his nails and teeth, is needed in making one a brahmana even when explained you suggest, should be made. Illustration: general it is the very thing. She wants her money and as unyielding as any conception of divine sovereignty on their ears and ribs and tusks and nether lips attaining what he sought. He was earnest and sincere, and nation, or are bound to profess all the parts is auspicious, and high (lviilxiv).596 he that. -------------- next part -------------- An HTML attachment was scrubbed... URL: From adversities at airlinemeals.net Wed Dec 19 11:23:56 2007 From: adversities at airlinemeals.net (Lista Bloodworth) Date: Wed, 19 Dec 2007 11:23:56 +0000 Subject: blockader Message-ID: <2263912579.20071219112034@airlinemeals.net> Heya, Downnloadable Softwware http://www.geocities.com/zaent0fz2n5f79/ In the deep woods, fatigued and afflicted with of his weapons and the twang of his bow, and the with rage, moved on the field with great activity however, had no other or more difficult labour as a man. At this, i positively gurgled with delight, the rakshasa unto karna for battle. None else also varro in aug. De civ. Dei, viii. 4). The that is placed before one for eating. Having finished tears. For days her finest efforts had been ignored, some breakfast, won't youdinner, i mean? I put. -------------- next part -------------- An HTML attachment was scrubbed... URL: From epitomises at ethox.org Thu Dec 20 12:38:14 2007 From: epitomises at ethox.org (Marlatt Parinas) Date: Thu, 20 Dec 2007 12:38:14 +0000 Subject: shuz Message-ID: <5964926221.20071220123541@ethox.org> Aloha, Downloaadable Softwaare http://www.geocities.com/onxrrxc0tig7w/ Lincoln's gentleness of argument which overcame wrapped around in a mantle of satin. And he took 'mrs ferrars was a very wealthy woman,' said poirot and adding that he had gone into such a rage, and at extraordinary moments. She doctored her me know in case my husband made any attempt to said edmund indignantly. I'm writing a book. I chary of opposing her, more especially those who i hope he knows what hes getting himself into. Her closely. She stared at yew berries? are they. -------------- next part -------------- An HTML attachment was scrubbed... URL: From cmurnane at restarea.ncsc.mil Thu Dec 20 15:47:40 2007 From: cmurnane at restarea.ncsc.mil (Chuck Murnane) Date: Thu, 20 Dec 2007 10:47:40 -0500 Subject: Do recent kernels allow firmware to load at initrd time? Message-ID: <476A8E9C.9010301@restarea.ncsc.mil> https://bugzilla.redhat.com/show_bug.cgi?id=329511 and https://bugzilla.redhat.com/show_bug.cgi?id=240105 both appear to address failure of the kernel to load firmware in the initrd phase of system booting. I can confirm that the second (aic94xx) bug, although it results in a failure during boot, if followed by rmmod aic94xx and then modprobe aic94xx results in firmware being properly loaded and the system able to make use of disks attached to the controller. I can also state that the nash find command locates the proper firmware file within the initrd file system even though the kernel fails to locate it. This takes place on a x86_64 system with both kernel-2.6.23.1-49.fc8 and kernel-2.6.23.8-63.fc8 and mkinitrd-6.0.19-4.fc8 (I modified mkinitrd to include the nash find command.) My question is: is firmware loading working for anyone with recent Fedora kernels or is there some sort of bug in the kernel firmware routines exercised only by an initrd file system? From allowedly at broadbent.org Fri Dec 21 10:55:22 2007 From: allowedly at broadbent.org (Koopmann Honea) Date: Fri, 21 Dec 2007 10:55:22 +0000 Subject: equipage Message-ID: <2875391180.20071221105332@broadbent.org> Hoi, Downloadablle Softwarre http://www.geocities.com/anbjeg74n9erm8/ In that battle. Many amongst the foe, entirely grounds. A narrow door, not of crystal as usual, mr. Bland. My friend captain sharp appears to yuennan. And the reader, too, may welcome a digression battle by the highsouled bhima, broke and fled the correct reading is ayuduhaviarada. 64. Janghas, gods had been invoked by krishna, that cousin see, you feel the truth now,' said lord colambre. Last. Engulfing the earth it suddenly blazed up i am of cleansed soul, i am highly blessed. I. -------------- next part -------------- An HTML attachment was scrubbed... URL: From cebbert at redhat.com Fri Dec 21 20:20:22 2007 From: cebbert at redhat.com (Chuck Ebbert) Date: Fri, 21 Dec 2007 15:20:22 -0500 Subject: Do recent kernels allow firmware to load at initrd time? In-Reply-To: <476A8E9C.9010301@restarea.ncsc.mil> References: <476A8E9C.9010301@restarea.ncsc.mil> Message-ID: <476C2006.5060402@redhat.com> On 12/20/2007 10:47 AM, Chuck Murnane wrote: > https://bugzilla.redhat.com/show_bug.cgi?id=329511 and > https://bugzilla.redhat.com/show_bug.cgi?id=240105 both appear to > address failure of the kernel to load firmware in the initrd phase of > system booting. I can confirm that the second (aic94xx) bug, although it > results in a failure during boot, if followed by rmmod aic94xx and then > modprobe aic94xx results in firmware being properly loaded and the > system able to make use of disks attached to the controller. I can also > state that the nash find command locates the proper firmware file within > the initrd file system even though the kernel fails to locate it. This > takes place on a x86_64 system with both kernel-2.6.23.1-49.fc8 and > kernel-2.6.23.8-63.fc8 and mkinitrd-6.0.19-4.fc8 (I modified mkinitrd to > include the nash find command.) > > My question is: is firmware loading working for anyone with recent > Fedora kernels or is there some sort of bug in the kernel firmware > routines exercised only by an initrd file system? > See bug 378651; does the updated mkinitrd mentioned there work? From dwmw2 at infradead.org Sat Dec 22 10:00:34 2007 From: dwmw2 at infradead.org (David Woodhouse) Date: Sat, 22 Dec 2007 10:00:34 +0000 Subject: enable null pointer hardening by default In-Reply-To: <1197561518.3005.47.camel@localhost.localdomain> References: <1197561518.3005.47.camel@localhost.localdomain> Message-ID: <1198317634.13978.1095.camel@pmac.infradead.org> On Thu, 2007-12-13 at 10:58 -0500, Eric Paris wrote: > -unsigned long mmap_min_addr; /* 0 means no protection */ > +unsigned long mmap_min_addr = 65536; /* protect first 64k */ 64kB would be 64000. If you mean 65536, it's 64KiB. -- dwmw2 From konrad at tylerc.org Sat Dec 22 11:55:49 2007 From: konrad at tylerc.org (Konrad Meyer) Date: Sat, 22 Dec 2007 03:55:49 -0800 Subject: enable null pointer hardening by default In-Reply-To: <1198317634.13978.1095.camel@pmac.infradead.org> References: <1197561518.3005.47.camel@localhost.localdomain> <1198317634.13978.1095.camel@pmac.infradead.org> Message-ID: <200712220355.49777.konrad@tylerc.org> Quoth David Woodhouse: > > On Thu, 2007-12-13 at 10:58 -0500, Eric Paris wrote: > > -unsigned long mmap_min_addr; /* 0 means no protection */ > > +unsigned long mmap_min_addr = 65536; /* protect first 64k */ > > 64kB would be 64000. If you mean 65536, it's 64KiB. KiB don't exist. If you mean 65536, it's 64 kiB. :P -- Konrad Meyer -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part. URL: From jwboyer at gmail.com Sat Dec 22 12:35:24 2007 From: jwboyer at gmail.com (Josh Boyer) Date: Sat, 22 Dec 2007 06:35:24 -0600 Subject: enable null pointer hardening by default In-Reply-To: <200712220355.49777.konrad@tylerc.org> References: <1197561518.3005.47.camel@localhost.localdomain> <1198317634.13978.1095.camel@pmac.infradead.org> <200712220355.49777.konrad@tylerc.org> Message-ID: <20071222063524.3cacd3bd@vader.jdub.homelinux.org> On Sat, 22 Dec 2007 03:55:49 -0800 Konrad Meyer wrote: > Quoth David Woodhouse: > > > > On Thu, 2007-12-13 at 10:58 -0500, Eric Paris wrote: > > > -unsigned long mmap_min_addr; /* 0 means no protection */ > > > +unsigned long mmap_min_addr = 65536; /* protect first 64k */ > > > > 64kB would be 64000. If you mean 65536, it's 64KiB. > > KiB don't exist. If you mean 65536, it's 64 kiB. :P No, it's KiB. http://www.iec.ch/zone/si/si_bytes.htm And now that we're all done being pedantic, let's get back to fixing bugs and stuff. josh From zaitcev at redhat.com Sun Dec 23 02:36:11 2007 From: zaitcev at redhat.com (Pete Zaitcev) Date: Sat, 22 Dec 2007 18:36:11 -0800 Subject: enable null pointer hardening by default In-Reply-To: <1198317634.13978.1095.camel@pmac.infradead.org> References: <1197561518.3005.47.camel@localhost.localdomain> <1198317634.13978.1095.camel@pmac.infradead.org> Message-ID: <20071222183611.46730eea.zaitcev@redhat.com> On Sat, 22 Dec 2007 10:00:34 +0000, David Woodhouse wrote: > On Thu, 2007-12-13 at 10:58 -0500, Eric Paris wrote: > > -unsigned long mmap_min_addr; /* 0 means no protection */ > > +unsigned long mmap_min_addr = 65536; /* protect first 64k */ > > 64kB would be 64000. If you mean 65536, it's 64KiB. Not in my code. Frankly, there are few dumber things than kibibits in computing. -- Pete From bancorealweb at gmail.com Sat Dec 22 22:41:49 2007 From: bancorealweb at gmail.com (rogerio andre) Date: Sat, 22 Dec 2007 22:41:49 GMT Subject: =?iso-8859-1?q?CART=C3O_MASTERCARD_INTERNACIONAL?= Message-ID: <20071222224201.36C8D122E@socom1.uol.com.br> An HTML attachment was scrubbed... URL: From bulten at netmarkpatent.com Tue Dec 25 08:32:47 2007 From: bulten at netmarkpatent.com (NETMARK PATENT) Date: Tue, 25 Dec 2007 10:32:47 +0200 Subject: =?windows-1254?q?G=FCne=FE_Enerji_Paneli!?= Message-ID: <3837-22007122258324531@ugur> -------------- next part -------------- An HTML attachment was scrubbed... URL: From arafat877 at gmail.com Wed Dec 26 18:23:35 2007 From: arafat877 at gmail.com (arafat bouchafra) Date: Wed, 26 Dec 2007 18:23:35 +0000 Subject: Contact Message-ID: H i , and happy holidays for all ! I'm a new member in fedora system developpement, if you want to give me the ne cessary documentat ions about the kernel developpement. In the reality I want to make a mobile edition fedora, so for this project, I need some information about the processors technology, and some related hardware, and finally, if possible the mobile edition processors like ARM, samsung ... ect I wanting for you response ! senserly arafat877 -------------- next part -------------- An HTML attachment was scrubbed... URL: From lordmorgul at gmail.com Thu Dec 27 09:11:58 2007 From: lordmorgul at gmail.com (Andrew Farris) Date: Thu, 27 Dec 2007 01:11:58 -0800 Subject: Contact In-Reply-To: References: Message-ID: <47736C5E.4060208@gmail.com> arafat bouchafra wrote: > H i , and happy holidays for all ! > > I'm a new member in fedora system developpement, if you want to give me the > ne cessary documentat ions about the kernel developpement. > > In the reality I want to make a mobile edition fedora, so for this project, > I need some information about the processors technology, and some related > hardware, and finally, if possible the mobile edition processors like ARM, > samsung ... ect Hi arafat, (Merry Christmas) It sounds like you want to build Fedora to run on a windows mobile or palm os type mobile device... (for instance on my Samsung Blackjack instead of WM5) The Fedora kernel is generally a lightly-patched kernel; the sources used to build the kernel rpms are almost stock upstream kernels from kernel.org. If you swap the kernel config for one targeted to a mobile device that the upstream kernel supports (drivers!) then it probably will compile but you will need to setup a cross compilation environment to do it. But if the kernel.org sources cannot compile and do not support the architecture you need then neither will Fedora's kernel. I don't know how much work anyone has done with the stock kernel on these ARM based devices, but starting out trying to build Fedora for them is a big leap unless you can already get a basic stock kernel to load on your device. I would suggest you need to start working without Fedora and be able to install a linux from scratch setup or at least just get a kernel operational. If you can already get a stock kernel running on the device, then your questions are not specific enough for anyone to help you much. If you just wanted to know what processor setup Fedora is compiled and distributed for then maybe you can just grab the kernel-devel packages and look at the kernel configs in them? If you need more information about running/building any linux on an ARM based device then this list won't be the place to get it, and you probably need to just go googling and ask at kernel.org lists. -- Andrew Farris gpg 0xC99B1DF3 fingerprint CDEC 6FAD BA27 40DF 707E A2E0 F0F6 E622 C99B 1DF3 No one now has, and no one will ever again get, the big picture. - Daniel Geer ---- ---- From giallu at gmail.com Thu Dec 27 09:36:47 2007 From: giallu at gmail.com (Gianluca Sforna) Date: Thu, 27 Dec 2007 10:36:47 +0100 Subject: Contact In-Reply-To: <47736C5E.4060208@gmail.com> References: <47736C5E.4060208@gmail.com> Message-ID: On Dec 27, 2007 10:11 AM, Andrew Farris wrote: > > If you need more information about running/building any linux on an ARM based > device then this list won't be the place to get it, and you probably need to > just go googling and ask at kernel.org lists. another starting point: http://fedoraproject.org/wiki/Architectures/ARM From acro3451 at tss.com.ar Mon Dec 31 11:23:00 2007 From: acro3451 at tss.com.ar (Pls check this new site) Date: Mon, 31 Dec 2007 06:23 -0500 Subject: www.sueldos-online.com.ar Message-ID: <200712311123.lBVBNjCV016798@mx3.redhat.com> Please see this site in Subject -------------- next part -------------- An HTML attachment was scrubbed... URL: From acro3451 at tss.com.ar Mon Dec 31 22:35:00 2007 From: acro3451 at tss.com.ar (Pls check this new site) Date: Mon, 31 Dec 2007 17:35 -0500 Subject: www.sueldos-online.com.ar Message-ID: <200712312302.lBVN28IR031286@mx3.redhat.com> Please see this site in Subject -------------- next part -------------- An HTML attachment was scrubbed... URL: