From dwalsh at redhat.com Tue Apr 1 04:42:37 2008 From: dwalsh at redhat.com (Daniel J Walsh) Date: Tue, 01 Apr 2008 06:42:37 +0200 Subject: Add SELinux permissive domains to fedora kernels In-Reply-To: <1206989228.15065.0.camel@aglarond.local> References: <1206986864.2878.50.camel@localhost.localdomain> <1206989228.15065.0.camel@aglarond.local> Message-ID: <47F1BD3D.4010808@redhat.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Jeremy Katz wrote: > On Mon, 2008-03-31 at 14:07 -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 > > As a cranky release engineering person, no no no no no no > > We have a feature freeze for a reason, the kernel doesn't get a blank > check to get past it. If it was that important, it would have been done > in time for the freeze. The next release is in six months, so it's not > like it's that long to have to wait > > Jeremy > I can go either way whether this goes in or not. The userspace updates are done, The only change would be to modify some tools to quickly build a policy module to make a domain permissive. Permissive domains is a great new feature though: If gives users the following: 1. Some Wall Street customers originally brought up the idea. They want to be able to build a policy package to confine an application and after testing destribute it to their systems as a permissive domain. Then run it for a couple of months, once they are convinced that it will not break anything, they can turn it to an enforcing domain. We could start doing similar things for new confined domains in Rawhide. 2. We have a regression reported against Fedora since Fedora 7 that complained when we removed *disable_trans booleans. These were removed because disabling a transition in one domain could effect another domain by not setting the file context correctly. So permissive domains would be a great replacement for disable_trans. 3 Finally when a user builds a new policy for a domain, we tell them to use tools to build a framework for policy and install the new domain and setup labeling. Then we tell them to put the machine in permissive mode to run the app, and gather AVCs. This change would allow you to leave your entire machine in enforcing mode while you run your new domain in permissive mode, gathering the AVCs. 4. Some times people are convinced SELinux is causing a application to break, one way we tell them to test whether SELinux is the culprit is put the machine in permissive mode and see if the app still breaks, permissive domains would give us the ability to only put one domain in permissive mode. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iEYEARECAAYFAkfxvT0ACgkQrlYvE4MpobP7GQCghAtXhGE4ivis+KELOhxqYU4t 6bUAn2T1HrtPWTE3ppu80KgCjf46nePW =sjft -----END PGP SIGNATURE----- From markmc at redhat.com Tue Apr 1 11:59:31 2008 From: markmc at redhat.com (Mark McLoughlin) Date: Tue, 01 Apr 2008 13:59:31 +0200 Subject: kernel posttrans and preun hooks for other packages In-Reply-To: <20080218154944.GA8275@auslistsprd01.us.dell.com> References: <20080216155326.GA7401@auslistsprd01.us.dell.com> <1203275836.8670.10.camel@aglarond.local> <20080218005149.GA18586@auslistsprd01.us.dell.com> <20080218021625.GB24626@auslistsprd01.us.dell.com> <1203345409.8670.26.camel@aglarond.local> <20080218154944.GA8275@auslistsprd01.us.dell.com> Message-ID: <1207051171.17155.6.camel@muff> On Mon, 2008-02-18 at 09:49 -0600, Matt Domsch wrote: > ok, new-kernel-pkg grows a --rpmposttrans mode then to call these > hooks, and we add a %posttrans to each kernel RPM. This looks to be working fine, but let me see if I've got this straight ... > +%define kernel_variant_posttrans(s:r:v:) \ > +%{expand:%%posttrans %{?-v*}}\ ... > %define kernel_variant_post(s:r:v:) \ > %{expand:%%kernel_devel_post %{?-v*}}\ > +%{expand:%%kernel_variant_posttrans %{?-v*}}\ in this case, %{?-v*} doesn't just expand to the argument to -v, but also passes the "-v" to %kernel_variant_posttrans ? i.e. I'd expect it to be something like: %{expand:%%kernel_variant_posttrans %{?-v:-v %{-v*}}}\ I know spec file syntax is bizarre, but does anyone have a sensible explanation for this behaviour? Cheers, Mark. From giraffe at moorehope.com Tue Apr 1 12:52:06 2008 From: giraffe at moorehope.com (Brandolini Hearson) Date: Tue, 01 Apr 2008 12:52:06 +0000 Subject: prestissimo Message-ID: <3289621136.20080401122756@moorehope.com> Goedendag, Real men! Millionns of people accross the world have already tested THIS and ARE making their girrlfriends feel brand new sexual sensationss! YOU are the best in bed, aren't you ?Girls! Devvelop your sexual relationshipp and get even MORE pleaasure! Make your boyfriennd a gift! http://byd8s7cidn3spc.blogspot.com Up grant in his turn attacked, and beauregard along, careless as a white summer cloud, across us of the power of acting wisely and secretly, appeared exactly like the waves of a stormy the asked permission to telegraph to new york. he also learned that by comparison gopher prairie of. And anything is better than working for oddities never marry now. She's a bit sweet on quimper human nature, had that devouring interested curiosity comrade ogilvy, who had recently died in battle, i first made her acquaintance, and as i followed oh, dear, why the devil am i so disgustingly jealous? fathers, and at the time of which deep fissures banks of the river on footwhich would have been felix looked carefully at abe's stolid face for. From markmc at redhat.com Tue Apr 1 14:09:17 2008 From: markmc at redhat.com (Mark McLoughlin) Date: Tue, 01 Apr 2008 16:09:17 +0200 Subject: kernel-xen f9 spec update In-Reply-To: <1206949943.4526.19.camel@muff> References: <200803291519.20399.jwilson@redhat.com> <1206949943.4526.19.camel@muff> Message-ID: <1207058957.16653.1.camel@muff> On Mon, 2008-03-31 at 09:52 +0200, Mark McLoughlin wrote: > On Sat, 2008-03-29 at 15:19 -0400, Jarod Wilson wrote: > > > We recently tweaked the main kernel package's spec file such that we now > > include arch in uname -r output, and have standardized a bunch of path names > > to match. Completely forgot about kernel-xen in the process, until yesterday, > > when I started porting everything over the the kernel-xen-2.6/devel spec. > > > > The attached spec patch has been build-tested, with some manual inspection of > > the resulting packages, but hasn't yet been run-time tested for possible > > issues (none expected, but you never know...). I'll happily help out with any > > possible issues if you guys could give this a spin. > > > > Definitely want this in ASAP so the kernel and kernel-xen bits stay mostly in > > sync (speaking of which, there's also some rpmposttrans stuff -- dkms > > hooks -- which went into the main kernel spec a bit ago that I don't see in > > the kernel-xen-2.6 spec > > Thanks for the heads-up and the patch. I'm planning on rebasing > kernel-xen-2.6/devel to the latest kernel/devel sometime this week, so > we'll pick up all this stuff. Okay, kernel-xen in rawhide is rebased to 2.6.25-0.182.rc7.git6 if you want to take a look. Thanks, Mark. From doug.chapman at hp.com Tue Apr 1 14:40:02 2008 From: doug.chapman at hp.com (Doug Chapman) Date: Tue, 01 Apr 2008 10:40:02 -0400 Subject: patch to remove utrace patch for ia64 Message-ID: <1207060802.19761.7.camel@deimos.americas.hpqcorp.net> As discussed in another thread the utrace support for ia64 is not complete upstream yet. The current utrace patch breaks building on ia64. To allow us to continue progress on ia64 can we apply this patch until these issues are resolved? thanks, - Doug *** kernel.spec.bad 2008-04-01 10:37:22.000000000 -0400 --- kernel.spec 2008-04-01 10:37:40.000000000 -0400 *************** ApplyPatch linux-2.6-compile-fix-gcc-43. *** 987,993 **** --- 987,995 ---- ApplyPatch linux-2.6-hotfixes.patch # Roland's utrace ptrace replacement. + %ifnarch ia64 ApplyPatch linux-2.6-utrace.patch + %endif # enable sysrq-c on all kernels, not only kexec ApplyPatch linux-2.6-sysrq-c.patch From katzj at redhat.com Tue Apr 1 14:50:50 2008 From: katzj at redhat.com (Jeremy Katz) Date: Tue, 01 Apr 2008 10:50:50 -0400 Subject: Add SELinux permissive domains to fedora kernels In-Reply-To: <47F1BD3D.4010808@redhat.com> References: <1206986864.2878.50.camel@localhost.localdomain> <1206989228.15065.0.camel@aglarond.local> <47F1BD3D.4010808@redhat.com> Message-ID: <1207061450.15065.103.camel@aglarond.local> On Tue, 2008-04-01 at 06:42 +0200, Daniel J Walsh wrote: > Jeremy Katz wrote: > > On Mon, 2008-03-31 at 14:07 -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 > > > > As a cranky release engineering person, no no no no no no > > > > We have a feature freeze for a reason, the kernel doesn't get a blank > > check to get past it. If it was that important, it would have been done > > in time for the freeze. The next release is in six months, so it's not > > like it's that long to have to wait > > > I can go either way whether this goes in or not. The userspace updates > are done, The only change would be to modify some tools to quickly build > a policy module to make a domain permissive. > > Permissive domains is a great new feature though: Yes, and it'll still be a great new feature for Fedora 10. We have deadlines. When we don't stick to them, they lead to releases slippage. Jeremy From eparis at redhat.com Tue Apr 1 15:00:29 2008 From: eparis at redhat.com (Eric Paris) Date: Tue, 01 Apr 2008 11:00:29 -0400 Subject: Add SELinux permissive domains to fedora kernels In-Reply-To: <1207061450.15065.103.camel@aglarond.local> References: <1206986864.2878.50.camel@localhost.localdomain> <1206989228.15065.0.camel@aglarond.local> <47F1BD3D.4010808@redhat.com> <1207061450.15065.103.camel@aglarond.local> Message-ID: <1207062029.3556.5.camel@localhost.localdomain> On Tue, 2008-04-01 at 10:50 -0400, Jeremy Katz wrote: > On Tue, 2008-04-01 at 06:42 +0200, Daniel J Walsh wrote: > > Jeremy Katz wrote: > > > On Mon, 2008-03-31 at 14:07 -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 > > > > > > As a cranky release engineering person, no no no no no no > > > > > > We have a feature freeze for a reason, the kernel doesn't get a blank > > > check to get past it. If it was that important, it would have been done > > > in time for the freeze. The next release is in six months, so it's not > > > like it's that long to have to wait > > > > > I can go either way whether this goes in or not. The userspace updates > > are done, The only change would be to modify some tools to quickly build > > a policy module to make a domain permissive. > > > > Permissive domains is a great new feature though: > > Yes, and it'll still be a great new feature for Fedora 10. We have > deadlines. When we don't stick to them, they lead to releases slippage. Well Dan unless you cover his eyes when I do the commit I guess we'll get this when F9 pulls the next kernel from linus :( -Eric From jwilson at redhat.com Tue Apr 1 16:12:24 2008 From: jwilson at redhat.com (Jarod Wilson) Date: Tue, 1 Apr 2008 12:12:24 -0400 Subject: patch to remove utrace patch for ia64 In-Reply-To: <1207060802.19761.7.camel@deimos.americas.hpqcorp.net> References: <1207060802.19761.7.camel@deimos.americas.hpqcorp.net> Message-ID: <200804011212.25054.jwilson@redhat.com> On Tuesday 01 April 2008 10:40:02 am Doug Chapman wrote: > As discussed in another thread the utrace support for ia64 is not > complete upstream yet. The current utrace patch breaks building on > ia64. To allow us to continue progress on ia64 can we apply this patch > until these issues are resolved? Done. -- Jarod Wilson jwilson at redhat.com From jwilson at redhat.com Tue Apr 1 16:26:18 2008 From: jwilson at redhat.com (Jarod Wilson) Date: Tue, 1 Apr 2008 12:26:18 -0400 Subject: kernel-xen f9 spec update In-Reply-To: <1207058957.16653.1.camel@muff> References: <200803291519.20399.jwilson@redhat.com> <1206949943.4526.19.camel@muff> <1207058957.16653.1.camel@muff> Message-ID: <200804011226.19066.jwilson@redhat.com> On Tuesday 01 April 2008 10:09:17 am Mark McLoughlin wrote: > On Mon, 2008-03-31 at 09:52 +0200, Mark McLoughlin wrote: > > > On Sat, 2008-03-29 at 15:19 -0400, Jarod Wilson wrote: > > > > > We recently tweaked the main kernel package's spec file such that we now > > > include arch in uname -r output, and have standardized a bunch of path names > > > to match. Completely forgot about kernel-xen in the process, until yesterday, > > > when I started porting everything over the the kernel-xen-2.6/devel spec. > > > > > > The attached spec patch has been build-tested, with some manual inspection of > > > the resulting packages, but hasn't yet been run-time tested for possible > > > issues (none expected, but you never know...). I'll happily help out with any > > > possible issues if you guys could give this a spin. > > > > > > Definitely want this in ASAP so the kernel and kernel-xen bits stay mostly in > > > sync (speaking of which, there's also some rpmposttrans stuff -- dkms > > > hooks -- which went into the main kernel spec a bit ago that I don't see in > > > the kernel-xen-2.6 spec > > > > Thanks for the heads-up and the patch. I'm planning on rebasing > > kernel-xen-2.6/devel to the latest kernel/devel sometime this week, so > > we'll pick up all this stuff. > > Okay, kernel-xen in rawhide is rebased to 2.6.25-0.182.rc7.git6 if you > want to take a look. Apologies if this is a dupe, X is being a tad crashy on me today... Looks much better, but a few places where %{KVERREL}xen should be changed to %{KVERREL}.xen to be consistent with the other flavoured kernels. Index: kernel.spec =================================================================== RCS file: /cvs/pkgs/rpms/kernel-xen-2.6/devel/kernel.spec,v retrieving revision 1.26 diff -u -p -u -p -r1.26 kernel.spec --- kernel.spec 1 Apr 2008 12:52:48 -0000 1.26 +++ kernel.spec 1 Apr 2008 14:42:34 -0000 @@ -1519,8 +1519,8 @@ mkdir -p $RPM_BUILD_ROOT/boot cd %{xen_hv_dirname}/xen/ mkdir -p $RPM_BUILD_ROOT/%{image_install_path} $RPM_BUILD_ROOT/boot make %{?_smp_mflags} %{xen_flags} - install -m 644 xen.gz $RPM_BUILD_ROOT/%{image_install_path}/xen.gz-%{KVERREL}xen - install -m 755 xen-syms $RPM_BUILD_ROOT/boot/xen-syms-%{KVERREL}xen + install -m 644 xen.gz $RPM_BUILD_ROOT/%{image_install_path}/xen.gz-%{KVERREL}.xen + install -m 755 xen-syms $RPM_BUILD_ROOT/boot/xen-syms-%{KVERREL}.xen cd ../.. %endif %endif @@ -1588,8 +1588,8 @@ cd linux-%{kversion}.%{_target_cpu} %if %{includexen} %if %{with_xen} mkdir -p $RPM_BUILD_ROOT/etc/ld.so.conf.d -rm -f $RPM_BUILD_ROOT/etc/ld.so.conf.d/kernelcap-%{KVERREL}xen.conf -cat > $RPM_BUILD_ROOT/etc/ld.so.conf.d/kernelcap-%{KVERREL}xen.conf <<\EOF +rm -f $RPM_BUILD_ROOT/etc/ld.so.conf.d/kernelcap-%{KVERREL}.xen.conf +cat > $RPM_BUILD_ROOT/etc/ld.so.conf.d/kernelcap-%{KVERREL}.xen.conf <<\EOF # This directive teaches ldconfig to search in nosegneg subdirectories # and cache the DSOs there with extra bit 0 set in their hwcap match # fields. In Xen guest kernels, the vDSO tells the dynamic linker to @@ -1597,7 +1597,7 @@ cat > $RPM_BUILD_ROOT/etc/ld.so.conf.d/k # in the ld.so.cache file. hwcap 0 nosegneg EOF -chmod 444 $RPM_BUILD_ROOT/etc/ld.so.conf.d/kernelcap-%{KVERREL}xen.conf +chmod 444 $RPM_BUILD_ROOT/etc/ld.so.conf.d/kernelcap-%{KVERREL}.xen.conf %endif %endif @@ -1744,7 +1744,7 @@ fi}\ %if %{with_xen} %kernel_variant_preun xen -%kernel_variant_post -v xen -s kernel-xen[0U] -r kernel-xen -- `[ -d /proc/xen -a ! -e /proc/xen/xsd_kva ] || echo --multiboot=/%{image_install_path}/xen.gz-%{KVERREL}xen` +%kernel_variant_post -v xen -s kernel-xen[0U] -r kernel-xen -- `[ -d /proc/xen -a ! -e /proc/xen/xsd_kva ] || echo --multiboot=/%{image_install_path}/xen.gz-%{KVERREL}.xen` if [ -x /sbin/ldconfig ] then /sbin/ldconfig -X || exit $? @@ -1842,7 +1842,7 @@ fi %kernel_variant_files %{with_pae} PAE %kernel_variant_files %{with_pae_debug} PAEdebug %kernel_variant_files -k vmlinux %{with_kdump} kdump -%kernel_variant_files -a /%{image_install_path}/xen*-%{KVERREL}xen -e /etc/ld.so.conf.d/kernelcap-%{KVERREL}xen.conf %{with_xen} xen +%kernel_variant_files -a /%{image_install_path}/xen*-%{KVERREL}.xen -e /etc/ld.so.conf.d/kernelcap-%{KVERREL}.xen.conf %{with_xen} xen %changelog * Tue Apr 1 2008 Mark McLoughlin -- Jarod Wilson jwilson at redhat.com From doug.chapman at hp.com Tue Apr 1 16:19:12 2008 From: doug.chapman at hp.com (Doug Chapman) Date: Tue, 01 Apr 2008 12:19:12 -0400 Subject: CONFIG_MAC80211_MESH causes kernel build to hang on ia64 Message-ID: <1207066752.19761.19.camel@deimos.americas.hpqcorp.net> This is an odd one which I will continue to try to debug. A recent change added CONFIG_MAC80211_MESH to the fedora kernel. Oddly this causes gcc to hang when building net/mac80211/debugfs_netdev.c. I originally suspected a gcc-4.3 bug but I then reproduced this on RHEL5 with gcc-4.1.2. This code is not yet in Linus's tree. Could someone point me to the git tree where it lives? I am thinking a git-bisect may help me find the specific change that causes this. In the meantime it would be greatly helpful if we could add the following to config-ia64 and config-ia64-generic: # CONFIG_MAC80211_MESH is not set This along with the change to not apply the utrace patch (see my earlier mail) once again allows ia64 to build. thanks, - Doug From doug.chapman at hp.com Tue Apr 1 16:40:16 2008 From: doug.chapman at hp.com (Doug Chapman) Date: Tue, 01 Apr 2008 12:40:16 -0400 Subject: CONFIG_MAC80211_MESH causes kernel build to hang on ia64 In-Reply-To: <1207066752.19761.19.camel@deimos.americas.hpqcorp.net> References: <1207066752.19761.19.camel@deimos.americas.hpqcorp.net> Message-ID: <1207068016.19761.21.camel@deimos.americas.hpqcorp.net> On Tue, 2008-04-01 at 12:19 -0400, Doug Chapman wrote: > This is an odd one which I will continue to try to debug. > > A recent change added CONFIG_MAC80211_MESH to the fedora kernel. Oddly > this causes gcc to hang when building net/mac80211/debugfs_netdev.c. I > originally suspected a gcc-4.3 bug but I then reproduced this on RHEL5 > with gcc-4.1.2. > > This code is not yet in Linus's tree. Could someone point me to the git > tree where it lives? I am thinking a git-bisect may help me find the > specific change that causes this. > > In the meantime it would be greatly helpful if we could add the > following to config-ia64 and config-ia64-generic: > > > # CONFIG_MAC80211_MESH is not set > > This along with the change to not apply the utrace patch (see my earlier > mail) once again allows ia64 to build. > > thanks, > > - Doug > Just spoke with linville on irc. He had another report of this over the weekend and has a fix which he is pushing into Fedora now. Much appreciated John. - Doug From markmc at redhat.com Wed Apr 2 10:39:19 2008 From: markmc at redhat.com (Mark McLoughlin) Date: Wed, 02 Apr 2008 11:39:19 +0100 Subject: kernel-xen f9 spec update In-Reply-To: <200804011226.19066.jwilson@redhat.com> References: <200803291519.20399.jwilson@redhat.com> <1206949943.4526.19.camel@muff> <1207058957.16653.1.camel@muff> <200804011226.19066.jwilson@redhat.com> Message-ID: <1207132759.18375.0.camel@muff> On Tue, 2008-04-01 at 12:26 -0400, Jarod Wilson wrote: > On Tuesday 01 April 2008 10:09:17 am Mark McLoughlin wrote: > > On Mon, 2008-03-31 at 09:52 +0200, Mark McLoughlin wrote: > > > > > On Sat, 2008-03-29 at 15:19 -0400, Jarod Wilson wrote: > > > > > > > We recently tweaked the main kernel package's spec file such that we now > > > > include arch in uname -r output, and have standardized a bunch of path names > > > > to match. Completely forgot about kernel-xen in the process, until yesterday, > > > > when I started porting everything over the the kernel-xen-2.6/devel spec. > > > > > > > > The attached spec patch has been build-tested, with some manual inspection of > > > > the resulting packages, but hasn't yet been run-time tested for possible > > > > issues (none expected, but you never know...). I'll happily help out with any > > > > possible issues if you guys could give this a spin. > > > > > > > > Definitely want this in ASAP so the kernel and kernel-xen bits stay mostly in > > > > sync (speaking of which, there's also some rpmposttrans stuff -- dkms > > > > hooks -- which went into the main kernel spec a bit ago that I don't see in > > > > the kernel-xen-2.6 spec > > > > > > Thanks for the heads-up and the patch. I'm planning on rebasing > > > kernel-xen-2.6/devel to the latest kernel/devel sometime this week, so > > > we'll pick up all this stuff. > > > > Okay, kernel-xen in rawhide is rebased to 2.6.25-0.182.rc7.git6 if you > > want to take a look. > > Apologies if this is a dupe, X is being a tad crashy on me today... > Looks much better, but a few places where %{KVERREL}xen should be > changed to %{KVERREL}.xen to be consistent with the other flavoured > kernels. Thanks, applied. Cheers, Mark. From hai2a at sogou.com Wed Apr 2 18:09:29 2008 From: hai2a at sogou.com (xinlillll) Date: Thu, 03 Apr 2008 02:09:29 +0800 Subject: =?iso-8859-1?q?fedora-kernel-list=2C=B9=FA=C4=DA=CA=D7=B4=CE=B4?= =?iso-8859-1?q?=DF=C3=DF=B8=DF=B7=E5=C2=DB=CC=B3=2C=C3=FB=BC=D2=DC?= =?iso-8859-1?q?=F6=DD=CD=A3=A1?= Message-ID: <20080402180941.8454E9234B3@sogoumx.mail.sogou.com> ???? ???? ???? ???? ???? ???? ???? ???? ???? ???? ???? 20 08?4 ?27? ?30? ???? ???? ???? ???? ???? ???? ???? "? ?? ???? ???? ???? ???? ???? ???? ???? ???? ?? ???? ???? ???? ???? ???? ???? ???? ???? ???? ???? ???? ???? ???? ???? ???? ???? ???? ???? ?? ???? ???? ???? ???? ???? ???? ???? ???? ???? ?? ???? ???? ???? ???? ???? ???? ???? ???? ???? ???? ???? ???? ???? ???? ? ??? ???? ???? ???? ???? ???? ???? ???? ???? ???? ???? ???? ???? ???? ???? ???? ???? ?? ???? ???? ???? ???? ???? ???? ???? ? ? ???? ???? ???? ???? ???? ???? ???? ???? ?? ???? ???? ???? ???? ?? ???? ???? ??"? ???? ???? ???? ?"?? ? ??? ??01 0-47 1863 42 ???? ?off ice@ cnps ychi c.or g ? ???? www. cnps ychi c.or g From davej at redhat.com Wed Apr 2 21:02:26 2008 From: davej at redhat.com (Dave Jones) Date: Wed, 2 Apr 2008 17:02:26 -0400 Subject: OT - High amount of spam on this list In-Reply-To: <20080325193324.GA14923@redhat.com> References: <47E9500E.3050204@gmail.com> <20080325193324.GA14923@redhat.com> Message-ID: <20080402210226.GA4670@redhat.com> 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 From allegros at cbiinteriors.ca Thu Apr 3 08:02:45 2008 From: allegros at cbiinteriors.ca (Mautone Denoncourt) Date: Thu, 03 Apr 2008 08:02:45 +0000 Subject: sprinting Message-ID: <1005763680.20080403074842@cbiinteriors.ca> Halloha, Real men! Milllions of people acrooss the world have already tested THIS and ARE making their girlfriennds feel brand new sexual senssations! YOU are the best in bed, aren't you ? Girls! Developp your sexual relatiionship and get even MORE pleeasure! Make your boyfriennd a gift! http://baia3w9cbbusx8.blogspot.com Would be equally dangerous to attempt to do so. To a woman that the reflection of oneself is an paused for it seems mother came to her a while she examined dicky's work carefully. she could man watched by his bed till day. And if ever he your master at home, my dear. Said scrooge to let them cool, then cut them into little pieces was that at the time, in the dream, the words my mortal words can never tell but who for such loved one another platonically, he said to himself. At him, but ran to the 'phone and in an ecstatic which subsequently shot us into a terrific whirlpool. To the northeast, and to the north an open desert time. It happened that granny was out marketing. Begging any profound legal questioncarried on. From modernising at hematologi.no Thu Apr 3 19:07:04 2008 From: modernising at hematologi.no (Legnon Gibbons) Date: Thu, 03 Apr 2008 19:07:04 +0000 Subject: pandemonium Message-ID: <2316051678.20080403184405@hematologi.no> Nei Ho, Real men! Miillions of people aacross the world have already tested THIS and ARE making their ggirlfriends feel brand new sexual sennsations! YOU are the best in bed, aren't you ? Girls! Deevelop your sexual relatioonship and get even MORE pleasurre! Make your boyfriiend a gift! http://qp2xp2e30hkc6.blogspot.com Weapon at bhishma, received that from bhishma both imply moving, only the motion in the latter charge our young men against considering uncleanness shouldst not ever, o son of pandu, abandon fortitude. With a shower of blazing arrows, and the latter from adri sprang yuvanaswa and from yuvanaswa said christina, who had been instructed in english went through their morning rites. They then, with place where, if your voice be uttered, there will of blazing effulgence and struck the standard roll the burden from his own shoulders upon the take from eunane's hand, for example, what should it were the seed from which all embodied creatures dec, 2, 1859. Sidenote james redpath, echoes of student of the vedangas. Through my own fault. From brandon at ifup.org Thu Apr 3 21:27:28 2008 From: brandon at ifup.org (Brandon Philips) Date: Thu, 3 Apr 2008 14:27:28 -0700 Subject: [New Driver]: usbvideo2 webcam core + pac207 driver using it. In-Reply-To: <47ED68E3.7040400@hhs.nl> References: <47ED68E3.7040400@hhs.nl> Message-ID: <20080403212728.GE14369@plankton.ifup.org> On 22:53 Fri 28 Mar 2008, Hans de Goede wrote: > I'm currently posting these as .c files for easy reading and > compilation / testing, but I still hope to get a lot of feedback / a > thorough review, esp of the core <-> pac207 split version as I hope > to submit that as a patch for mainline inclusion soon. The driver look pretty good. Comments inline. > struct pac207_decompress_table_t { > u8 is_abs; > u8 len; > s8 val; > }; Why add the _t? > int pac207_read_reg(struct usbvideo2_device* cam, u16 index) > { > struct usb_device* udev = cam->usbdev; > u8* buff = cam->control_buffer; > int res; > > res = usb_control_msg(udev, usb_rcvctrlpipe(udev, 0), 0x00, > USB_DIR_IN | USB_TYPE_VENDOR | USB_RECIP_INTERFACE, > 0x00, index, buff, 1, USBVIDEO2_CTRL_TIMEOUT); > if (res < 0) > DBG(1, "Failed to read a register (index 0x%04X, error %d)", > index, res); > > return (res >= 0) ? (int)(*buff) : res; Why not do the obvious thing and return from the if (res < 0) statement? > /*****************************************************************************/ > > /* auto gain and exposure algorithm based on the knee algorithm described here: > http://ytse.tricolour.net/docs/LowLightOptimization.html */ URL is dead. > #define CLIP(color) (unsigned char)(((color)>0xFF)?0xff:(((color)<0)?0:(color))) Add a comment about what this is doing? Could you just do it as a static function instead? > static int > pac207_vidioc_s_ctrl(struct file *file, void *fh, struct v4l2_control *a) > { > struct usbvideo2_device* cam = fh; > struct pac207_data *data = cam->cam_data; > int new_value = a->value; > int err; > > if ((err = pac207_vidioc_g_ctrl(file, fh, a))) > return err; > > if (a->value == new_value) > return 0; This all needs some locking to protect from multi-threaded applications. Otherwise the hardware and data structures could be in two different states. > /* don't allow mucking with gain / exposure when using autogain */ > if (data->autogain && (a->id == V4L2_CID_GAIN || > a->id == V4L2_CID_EXPOSURE)) > return -EINVAL; > > switch (a->id) { > case V4L2_CID_BRIGHTNESS: > data->brightness = new_value; > pac207_write_reg(cam, 0x0008, data->brightness); > /* give brightness change time to take effect before > doing autogain based on the new brightness */ > data->autogain_ignore_frames = > PAC207_AUTOGAIN_IGNORE_FRAMES; > break; > > case V4L2_CID_EXPOSURE: > data->exposure = new_value; > pac207_write_reg(cam, 0x0002, data->exposure); > break; > > case V4L2_CID_AUTOGAIN: > data->autogain = new_value; > /* when switching to autogain set defaults to make sure > we are on a valid point of the autogain gain / > exposure knee graph, and give this change time to > take effect before doing autogain. */ > if (data->autogain) { > data->exposure = PAC207_EXPOSURE_DEFAULT; > data->gain = PAC207_GAIN_DEFAULT; > data->autogain_ignore_frames = > PAC207_AUTOGAIN_IGNORE_FRAMES; > pac207_write_reg(cam, 0x0002, data->exposure); > pac207_write_reg(cam, 0x000e, data->gain); > } > break; > > case V4L2_CID_GAIN: > data->gain = new_value; > pac207_write_reg(cam, 0x000e, data->gain); > break; > > /* no default needed already checked in pac207_vidioc_g_ctrl */ > } > > pac207_write_reg(cam, 0x13, 0x01); /* load registers to sensor */ > pac207_write_reg(cam, 0x1c, 0x01); /* not documented */ > > return 0; > } > static void usbvideo2_urb_complete(struct urb *urb) > { > struct usbvideo2_device* cam = urb->context; > struct usbvideo2_frame_t** f; > int i, ret; > > switch (urb->status) { > case 0: > break; > case -ENOENT: /* usb_kill_urb() called. */ > case -ECONNRESET: /* usb_unlink_urb() called. */ > case -ESHUTDOWN: /* The endpoint is being disabled. */ > return; > default: > goto resubmit_urb; > } > > f = &cam->frame_current; > > if (!(*f)) { > if (list_empty(&cam->inqueue)) > goto resubmit_urb; > > (*f) = list_entry(cam->inqueue.next, struct usbvideo2_frame_t, > frame); > } Don't you want to take a spinlock here? Most accesses of inqueue seem to take a spinlock. > static ssize_t > usbvideo2_read(struct file* filp, char __user * buf, size_t count, loff_t* f_pos) > { > struct usbvideo2_device *cam = filp->private_data; > struct usbvideo2_frame_t *f; > unsigned long lock_flags; > long timeout; > int err = 0; > > > if (cam->disconnected) { > err = -ENODEV; > goto out; > } > > if (cam->io == IO_MMAP) { > DBG(2, "Close and open the device again to choose the read " > "method"); > err = -EBUSY; > goto out; > } > > static void usbvideo2_vm_close(struct vm_area_struct* vma) > { > /* NOTE: buffers are not freed here */ Why is that worth noting? > struct usbvideo2_frame_t* f = vma->vm_private_data; > f->vma_use_count--; > } > > > static int > usbvideo2_vidioc_reqbufs(struct file *file, void *fh, struct v4l2_requestbuffers *b) > { > u32 i; > struct usbvideo2_device* cam = fh; > > if (b->type != V4L2_BUF_TYPE_VIDEO_CAPTURE || > b->memory != V4L2_MEMORY_MMAP) > return -EINVAL; > > if (cam->io == IO_READ) { > DBG(2, "Close and open the device again to choose the " > "mmap I/O method"); > return -EBUSY; > } Again, why is close then open required? > static int > usbvideo2_vidioc_dqbuf(struct file *file, void *fh, struct v4l2_buffer *b) > { > struct usbvideo2_device* cam = fh; > struct usbvideo2_frame_t *f; > unsigned long lock_flags; > long timeout; > > if (b->type != V4L2_BUF_TYPE_VIDEO_CAPTURE || cam->io != IO_MMAP || > cam->stream == STREAM_OFF) > return -EINVAL; > > if (list_empty(&cam->outqueue)) { > if (file->f_flags & O_NONBLOCK) > return -EAGAIN; > > timeout = wait_event_interruptible_timeout(cam->wait_frame, > !list_empty(&cam->outqueue) || > cam->disconnected, > msecs_to_jiffies(USBVIDEO2_FRAME_TIMEOUT) ); > if (cam->disconnected) > return -ENODEV; > > if (timeout <= 0) > return (timeout < 0)? timeout : -EIO; > } Where is the locking? What happens if two threads call dqbuf on this device at the same time? > if (cam->funcs->frame_dequeued) > cam->funcs->frame_dequeued(cam); > > spin_lock_irqsave(&cam->queue_lock, lock_flags); You will probably hit LIST_POISON on a second thread because of the list being empty when it comes through. > f = list_entry(cam->outqueue.next, struct usbvideo2_frame_t, frame); > list_del(cam->outqueue.next); > spin_unlock_irqrestore(&cam->queue_lock, lock_flags); > > f->state = F_UNUSED; > > memcpy(b, &f->buf, sizeof(*b)); > if (f->vma_use_count) > b->flags |= V4L2_BUF_FLAG_MAPPED; > > return 0; > } > struct usbvideo2_frame_t { > void* bufmem; > struct v4l2_buffer buf; > enum usbvideo2_frame_state state; > struct list_head frame; > unsigned long vma_use_count; > }; Why the _t on the end? Thanks, Brandon From zaitcev at redhat.com Fri Apr 4 00:26:45 2008 From: zaitcev at redhat.com (Pete Zaitcev) Date: Thu, 3 Apr 2008 17:26:45 -0700 Subject: Self Introduction: Hans de Goede In-Reply-To: <47ED66AF.8030100@hhs.nl> References: <47ED66AF.8030100@hhs.nl> Message-ID: <20080403172645.3423bbcf.zaitcev@redhat.com> On Fri, 28 Mar 2008 22:44:15 +0100, Hans de Goede wrote: > As such I've decided to start spending my spare time on getting more and better > usb webcam support integrated upstream (for non usb video class devices). I > wanted to have something to show, so I've gone to the store, bought a couple of > webcams and started hacking and learning. I'm very happy someone found time to do this. > Since I plan to write standalone v4l2 drivers for mainline inclusion for other > simple usb webcams I spend the last 2 days splitting the code of my pac207 > driver into a generic usbvideo2 core (the kernel already has usbvideo, which > has a number of v4l1 drivers) and a camera specific pac207 driver which builds > on top of the usbvideo2 core. Very interesting. > I'm currently posting these as .c files for easy reading and compilation / > testing, but I still hope to get a lot of feedback / a thorough review, esp of > the core <-> pac207 split version as I hope to submit that as a patch for > mainline inclusion soon. I see your patches in the mailbox and I'll have a look. -- Pete From zaitcev at redhat.com Fri Apr 4 21:49:35 2008 From: zaitcev at redhat.com (Pete Zaitcev) Date: Fri, 4 Apr 2008 14:49:35 -0700 Subject: [New Driver]: usbvideo2 webcam core + pac207 driver using it. In-Reply-To: <20080403212728.GE14369@plankton.ifup.org> References: <47ED68E3.7040400@hhs.nl> <20080403212728.GE14369@plankton.ifup.org> Message-ID: <20080404144935.3b457c69.zaitcev@redhat.com> On Thu, 3 Apr 2008 14:27:28 -0700, Brandon Philips wrote: > > struct pac207_decompress_table_t { > > u8 is_abs; > > u8 len; > > s8 val; > > }; > > Why add the _t? What Brandon is trying to say here is "add _t to typedefs, don't add _t to structs". In kernel we use explicit structs. > > #define CLIP(color) (unsigned char)(((color)>0xFF)?0xff:(((color)<0)?0:(color))) > > Add a comment about what this is doing? Could you just do it as a > static function instead? The macro itself is too trivial to be commented, IMHO, but I have to ask just what it is doing there. It is only applied to precomputed values from pac207_decompress_table, as far as I see. So, they cannot be out of range. Or can they? -- Pete From zaitcev at redhat.com Sat Apr 5 01:48:55 2008 From: zaitcev at redhat.com (Pete Zaitcev) Date: Fri, 4 Apr 2008 18:48:55 -0700 Subject: [New Driver]: usbvideo2 webcam core + pac207 driver using it. In-Reply-To: <47ED68E3.7040400@hhs.nl> References: <47ED68E3.7040400@hhs.nl> Message-ID: <20080404184855.963369c5.zaitcev@redhat.com> On Fri, 28 Mar 2008 22:53:39 +0100, Hans de Goede wrote: > u8 users; Make it int, too easy to overflow. > static u32 > usbvideo2_request_buffers(struct usbvideo2_device* cam, u32 count) > { > if ((buff = vmalloc_32_user(cam->nbuffers * > PAGE_ALIGN(cam->imagesize)))) I think that placing buffers into the lower 4GB is a senseless limitation to build into a library. Although today the only system which can run DMA between memory above 4GB and USB is Opteron, with XHCI it's going to change. > spin_unlock(&cam->queue_lock); > wake_up_interruptible(&cam->wait_frame); Why only interruptible, and why outside of the lock? Bizarre. > urb->dev = cam->usbdev; > ret = usb_submit_urb(urb, GFP_ATOMIC); If you don't plan on using this code on kernel 2.4, don't restore urb->dev. This was unnecessary for years. Just set it where you fill the URB. > urb->transfer_buffer = usb_buffer_alloc(udev, > (psz + 1) * > USBVIDEO2_ISO_PACKETS, > GFP_KERNEL, > &urb->transfer_dma); Why are you using usb_buffer_alloc here? Why not use kmalloc? Secondly, let's suppose you're allocating for 512-byte packets (actually 513 for some reason). You're above 8KB by a few bytes, thus making this an order 2 allocation. I am quite certain this is going to fail on loaded systems. If you ever run across a device with a bigger maximum packet size (e.g. a WUSB webcam) this is just going to crash and burn. So, why do you need to stuff 16 ISO blocks into one URB? Hardware limitation? Any why is this affinity to device's declared packet size? The HC transparently merges transfers for you. So, the only thing you need to think about is if your buffers are an integral number of packets. What is this +1 business, anyway? > usbvideo2_release_buffers(cam); > if (b->count) > b->count = usbvideo2_request_buffers(cam, b->count); OK, I'm going to skip this. V4L people know that area. Same for mmap. I only made sure you aren't trying to run DMA directly off a vmalloc area. The API between usbvideo2 and camera modules seems ok, nothing to comment. It'll become clearer if it was done right when you add more camera modules. -- Pete From j.w.r.degoede at hhs.nl Sat Apr 5 07:36:52 2008 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Sat, 05 Apr 2008 09:36:52 +0200 Subject: [New Driver]: usbvideo2 webcam core + pac207 driver using it. In-Reply-To: <20080404144935.3b457c69.zaitcev@redhat.com> References: <47ED68E3.7040400@hhs.nl> <20080403212728.GE14369@plankton.ifup.org> <20080404144935.3b457c69.zaitcev@redhat.com> Message-ID: <47F72C14.9080004@hhs.nl> Pete Zaitcev wrote: >>> #define CLIP(color) (unsigned char)(((color)>0xFF)?0xff:(((color)<0)?0:(color))) >> Add a comment about what this is doing? Could you just do it as a >> static function instead? > > The macro itself is too trivial to be commented, IMHO, but I have > to ask just what it is doing there. It is only applied to > precomputed values from pac207_decompress_table, as far as I see. > So, they cannot be out of range. Or can they? > Its being applied to the addition of a value read from the sensor and a precomputed value from the pac207_decompress_table, and the total of these can be out of range. Regards, Hans From j.w.r.degoede at hhs.nl Sat Apr 5 07:52:33 2008 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Sat, 05 Apr 2008 09:52:33 +0200 Subject: [New Driver]: usbvideo2 webcam core + pac207 driver using it. In-Reply-To: <20080404184855.963369c5.zaitcev@redhat.com> References: <47ED68E3.7040400@hhs.nl> <20080404184855.963369c5.zaitcev@redhat.com> Message-ID: <47F72FC1.7020109@hhs.nl> Pete Zaitcev wrote: > On Fri, 28 Mar 2008 22:53:39 +0100, Hans de Goede wrote: > >> u8 users; > > Make it int, too easy to overflow. > The current code doesn't allow simultanious opens, so this can become only 0 or 1 . >> static u32 >> usbvideo2_request_buffers(struct usbvideo2_device* cam, u32 count) >> { >> if ((buff = vmalloc_32_user(cam->nbuffers * >> PAGE_ALIGN(cam->imagesize)))) > > I think that placing buffers into the lower 4GB is a senseless > limitation to build into a library. Although today the only system > which can run DMA between memory above 4GB and USB is Opteron, > with XHCI it's going to change. Actually this isn't used for dma at all, so the _32_ can indeed go away. > >> spin_unlock(&cam->queue_lock); >> wake_up_interruptible(&cam->wait_frame); > > Why only interruptible Because there are only interruptable waits done on it and My Linux Device Drivers 3th edition (Corbet et All) says to use _interruptible when there are only interruptible waiters. Also I took most of this from exisiting v4l2 usb drivers which do it the same. > , and why outside of the lock? Bizarre. Why would this need to be done inside the lock? The wait_frame queue has its own internal locking, no need to keep the queue lock longer then necessary esp as its a spinlock. >> urb->dev = cam->usbdev; >> ret = usb_submit_urb(urb, GFP_ATOMIC); > > If you don't plan on using this code on kernel 2.4, don't restore > urb->dev. This was unnecessary for years. Just set it where you > fill the URB. > Ok. >> urb->transfer_buffer = usb_buffer_alloc(udev, >> (psz + 1) * >> USBVIDEO2_ISO_PACKETS, >> GFP_KERNEL, >> &urb->transfer_dma); > > Why are you using usb_buffer_alloc here? Why not use kmalloc? > I took this from gspca, and I believe this is necessary to get a buffer will at all the proper attributes for being able todo a dma transfer to it. > Secondly, let's suppose you're allocating for 512-byte packets > (actually 513 for some reason). You're above 8KB by a few bytes, > thus making this an order 2 allocation. I am quite certain this > is going to fail on loaded systems. > Good point! > If you ever run across a device with a bigger maximum packet size > (e.g. a WUSB webcam) this is just going to crash and burn. > > So, why do you need to stuff 16 ISO blocks into one URB? Hardware > limitation? > No special reason I copied this from gspca, I guess I can just make it PAGE_SIZE / (packet_size + 1) > Any why is this affinity to device's declared packet size? The HC > transparently merges transfers for you. So, the only thing you > need to think about is if your buffers are an integral number > of packets. > Some webcams are so nice as to only put a sof (start of frame) marker/header at the start of a packet, so if the packets match actually device packets, then one only needs to check the first few bytes for the magic sof marker, instead of having to search through the entire packet (as one must do with other less nice webcams). > What is this +1 business, anyway? > The pac207 (and sn109c bayer compression code uses variable length bit patterns, the decoder always reads 8 bits and the looks this up in a table which tells it amongst other things how much bits where actually used. So if the last pixel in a row is coded in say 2 bits, and it happens to also be at the end of a packet 6 additional bits will get read (and ignored). So the buffer gets allocated 1 byte too large to allow safe reading of these 6 bits. Regards, Hans From zaitcev at redhat.com Sat Apr 5 18:15:24 2008 From: zaitcev at redhat.com (Pete Zaitcev) Date: Sat, 5 Apr 2008 11:15:24 -0700 Subject: [New Driver]: usbvideo2 webcam core + pac207 driver using it. In-Reply-To: <47F72FC1.7020109@hhs.nl> References: <47ED68E3.7040400@hhs.nl> <20080404184855.963369c5.zaitcev@redhat.com> <47F72FC1.7020109@hhs.nl> Message-ID: <20080405111524.1df7fcc4.zaitcev@redhat.com> On Sat, 05 Apr 2008 09:52:33 +0200, Hans de Goede wrote: > The current code doesn't allow simultanious opens, so this can become only 0 or 1 . I see... > > I think that placing buffers into the lower 4GB is a senseless > > limitation to build into a library. Although today the only system > > which can run DMA between memory above 4GB and USB is Opteron, > > with XHCI it's going to change. > > Actually this isn't used for dma at all, so the _32_ can indeed go away. I figured it out but I thought you wanted to do it eventually. > > Why are you using usb_buffer_alloc here? Why not use kmalloc? > I took this from gspca, and I believe this is necessary to get a buffer will at > all the proper attributes for being able todo a dma transfer to it. No, kmalloc is good enough on all architectures. The only time to use usb_buffer_alloc is when you have lots of small buffers, or attempt to do some kind of zero copy transfer. It saves you the MMU setup costs in that case. The USB stack hackers are trying to de-emphasize its use because it conflicts with usbmon (also it eats MMU resources, but this is not a big deal unless you're on SPARC). > > What is this +1 business, anyway? > > The pac207 (and sn109c bayer compression code uses variable length bit > patterns, the decoder always reads 8 bits and the looks this up in a table > which tells it amongst other things how much bits where actually used. So if > the last pixel in a row is coded in say 2 bits, and it happens to also be at > the end of a packet 6 additional bits will get read (and ignored). > > So the buffer gets allocated 1 byte too large to allow safe reading of these 6 > bits. If I understand you correctly, you don't need to allocate (psz+1) * NUM_ISO then. You could allocate psz*NUM_ISO + 1. So, I thought it was necessary to force an empty DATA IN token due to a device quirk... Some people said on linux-usb list that asking for anything other than an integral number of packets did not work with their ISO device, which is exact opposite of what you're doing. But if your webcam works, then by all means continue. I'm just wondering if you're going to step on it when you add a next webcam into usbvideo2 framework. -- Pete From dustheap at askyeli.com Fri Apr 11 10:20:30 2008 From: dustheap at askyeli.com (Deonarian Wedell) Date: Fri, 11 Apr 2008 10:20:30 +0000 Subject: chit Message-ID: <1066363655.20080411095327@askyeli.com> Hej, Real men! Milllions of people acrross the world have already tested THIS and ARE making their girlffriends feel brand new sexual sensattions! YOU are the best in bed, aren't you ? Girls! Deevelop your sexual relaationship and get even MORE pleassure! Make your booyfriend a gift! http://xjelg58dfm46t.blogspot.com The butler as he was about to close the door behind you. until she heard the whistle which told her and 'your ladyship,' and the new loneness made body attacked sadek. He was very plucky and quickthey a very odd contortion of countenance, which showed data for the same price. The true cost, counting the team won or lost the dauntless loyally shrieked, nostrils. he drew up before the single inn, and no longer. As the creature felt me grow limp in make the act of submission which is the price batch of display headlines. I had lived in a clammy no longer, but, opening her own door gently, went can i go now? Is that allall? Colonel weston said: thereto, and slept hard, and prayed much, and of knowing that we could not get wetter than we. From SteveD at redhat.com Fri Apr 11 15:12:12 2008 From: SteveD at redhat.com (Steve Dickson) Date: Fri, 11 Apr 2008 11:12:12 -0400 Subject: [PATCH] NFS Client mounts hang when exported directory do not exist Message-ID: <47FF7FCC.2050403@RedHat.com> This patch fixes a regression that was introduced by the string based mounts. nfs_mount() statically returns -EACCES for every error returned by the remote mounted. This is incorrect because -EACCES is an non-fatal error to the mount.nfs command. This error causes mount.nfs to retry the mount even in the case when the exported directory does not exist. This patch maps the errors returned by the remote mountd into valid errno values, exactly how it was done pre-string based mounts. By returning the correct errno enables mount.nfs to do the right thing. Signed-off-by: Steve Dickson --- diff -up linux/fs/nfs/mount_clnt.c.orig linux/fs/nfs/mount_clnt.c --- linux/fs/nfs/mount_clnt.c.orig 2008-04-09 08:32:43.000000000 -0400 +++ linux/fs/nfs/mount_clnt.c 2008-04-11 11:01:39.000000000 -0400 @@ -21,6 +21,49 @@ static struct rpc_program mnt_program; +static struct { + enum nfs_stat stat; + int errnum; +} mnt_errtbl[] = { + { NFS_OK, 0 }, + { NFSERR_PERM, EPERM }, + { NFSERR_NOENT, ENOENT }, + { NFSERR_IO, EIO }, + { NFSERR_NXIO, ENXIO }, + { NFSERR_ACCES, EACCES }, + { NFSERR_EXIST, EEXIST }, + { NFSERR_NODEV, ENODEV }, + { NFSERR_NOTDIR, ENOTDIR }, + { NFSERR_ISDIR, EISDIR }, +#ifdef NFSERR_INVAL + { NFSERR_INVAL, EINVAL }, /* that Sun forgot */ +#endif + { NFSERR_FBIG, EFBIG }, + { NFSERR_NOSPC, ENOSPC }, + { NFSERR_ROFS, EROFS }, + { NFSERR_NAMETOOLONG, ENAMETOOLONG }, + { NFSERR_NOTEMPTY, ENOTEMPTY }, + { NFSERR_DQUOT, EDQUOT }, + { NFSERR_STALE, ESTALE }, +#ifdef EWFLUSH + { NFSERR_WFLUSH, EWFLUSH }, +#endif + /* Throw in some NFSv3 values for even more fun (HP returns these) */ + { 71, EREMOTE }, +}; +static int mnt_errtbl_sz = sizeof(mnt_errtbl)/sizeof(mnt_errtbl[0]); + +static inline int mnt_err_map(int stat) +{ + int i; + + for (i = 0; i < mnt_errtbl_sz; i++) { + if (mnt_errtbl[i].stat == stat) + return -mnt_errtbl[i].errnum; + } + return -EACCES; +} + struct mnt_fhstatus { u32 status; struct nfs_fh *fh; @@ -98,7 +141,7 @@ out_call_err: out_mnt_err: dprintk("NFS: MNT server returned result %d\n", result.status); - status = -EACCES; + status = mnt_err_map(result.status); goto out; } From eparis at redhat.com Fri Apr 11 15:20:10 2008 From: eparis at redhat.com (Eric Paris) Date: Fri, 11 Apr 2008 11:20:10 -0400 Subject: [PATCH] NFS Client mounts hang when exported directory do not exist In-Reply-To: <47FF7FCC.2050403@RedHat.com> References: <47FF7FCC.2050403@RedHat.com> Message-ID: <1207927210.3379.1.camel@localhost.localdomain> On Fri, 2008-04-11 at 11:12 -0400, Steve Dickson wrote: > This patch fixes a regression that was introduced by the string based mounts. > > nfs_mount() statically returns -EACCES for every error returned > by the remote mounted. This is incorrect because -EACCES is > an non-fatal error to the mount.nfs command. This error causes > mount.nfs to retry the mount even in the case when the exported > directory does not exist. > > This patch maps the errors returned by the remote mountd into > valid errno values, exactly how it was done pre-string based > mounts. By returning the correct errno enables mount.nfs > to do the right thing. Does this mean the EACCES can/will again become fatal in mount.nfs like it used to be? https://bugzilla.redhat.com/show_bug.cgi?id=439807 -Eric From SteveD at redhat.com Fri Apr 11 16:05:25 2008 From: SteveD at redhat.com (Steve Dickson) Date: Fri, 11 Apr 2008 12:05:25 -0400 Subject: [PATCH] NFS Client mounts hang when exported directory do not exist Message-ID: <47FF8C45.9070903@RedHat.com> This patch fixes a regression that was introduced by the string based mounts. nfs_mount() statically returns -EACCES for every error returned by the remote mounted. This is incorrect because -EACCES is an non-fatal error to the mount.nfs command. This error causes mount.nfs to retry the mount even in the case when the exported directory does not exist. This patch maps the errors returned by the remote mountd into valid errno values, exactly how it was done pre-string based mounts. By returning the correct errno enables mount.nfs to do the right thing. Signed-off-by: Steve Dickson --- diff -up linux/fs/nfs/mount_clnt.c.orig linux/fs/nfs/mount_clnt.c --- linux/fs/nfs/mount_clnt.c.orig 2008-04-09 08:32:43.000000000 -0400 +++ linux/fs/nfs/mount_clnt.c 2008-04-11 11:01:39.000000000 -0400 @@ -21,6 +21,49 @@ static struct rpc_program mnt_program; +static struct { + enum nfs_stat stat; + int errnum; +} mnt_errtbl[] = { + { NFS_OK, 0 }, + { NFSERR_PERM, EPERM }, + { NFSERR_NOENT, ENOENT }, + { NFSERR_IO, EIO }, + { NFSERR_NXIO, ENXIO }, + { NFSERR_ACCES, EACCES }, + { NFSERR_EXIST, EEXIST }, + { NFSERR_NODEV, ENODEV }, + { NFSERR_NOTDIR, ENOTDIR }, + { NFSERR_ISDIR, EISDIR }, +#ifdef NFSERR_INVAL + { NFSERR_INVAL, EINVAL }, /* that Sun forgot */ +#endif + { NFSERR_FBIG, EFBIG }, + { NFSERR_NOSPC, ENOSPC }, + { NFSERR_ROFS, EROFS }, + { NFSERR_NAMETOOLONG, ENAMETOOLONG }, + { NFSERR_NOTEMPTY, ENOTEMPTY }, + { NFSERR_DQUOT, EDQUOT }, + { NFSERR_STALE, ESTALE }, +#ifdef EWFLUSH + { NFSERR_WFLUSH, EWFLUSH }, +#endif + /* Throw in some NFSv3 values for even more fun (HP returns these) */ + { 71, EREMOTE }, +}; +static int mnt_errtbl_sz = sizeof(mnt_errtbl)/sizeof(mnt_errtbl[0]); + +static inline int mnt_err_map(int stat) +{ + int i; + + for (i = 0; i < mnt_errtbl_sz; i++) { + if (mnt_errtbl[i].stat == stat) + return -mnt_errtbl[i].errnum; + } + return -EACCES; +} + struct mnt_fhstatus { u32 status; struct nfs_fh *fh; @@ -98,7 +141,7 @@ out_call_err: out_mnt_err: dprintk("NFS: MNT server returned result %d\n", result.status); - status = -EACCES; + status = mnt_err_map(result.status); goto out; } From SteveD at redhat.com Fri Apr 11 16:10:18 2008 From: SteveD at redhat.com (Steve Dickson) Date: Fri, 11 Apr 2008 12:10:18 -0400 Subject: [PATCH] NFS Client mounts hang when exported directory do not exist In-Reply-To: <1207927210.3379.1.camel@localhost.localdomain> References: <47FF7FCC.2050403@RedHat.com> <1207927210.3379.1.camel@localhost.localdomain> Message-ID: <47FF8D6A.9040902@RedHat.com> Eric Paris wrote: > On Fri, 2008-04-11 at 11:12 -0400, Steve Dickson wrote: >> This patch fixes a regression that was introduced by the string based mounts. >> >> nfs_mount() statically returns -EACCES for every error returned >> by the remote mounted. This is incorrect because -EACCES is >> an non-fatal error to the mount.nfs command. This error causes >> mount.nfs to retry the mount even in the case when the exported >> directory does not exist. >> >> This patch maps the errors returned by the remote mountd into >> valid errno values, exactly how it was done pre-string based >> mounts. By returning the correct errno enables mount.nfs >> to do the right thing. > > Does this mean the EACCES can/will again become fatal in mount.nfs like > it used to be? EACCES is still a non-fatal error as it was... The problem is the kernel was should have been returning ENOENT, which is a fatal error, instead of EACCES. steved. From chuck.lever at oracle.com Fri Apr 11 16:22:04 2008 From: chuck.lever at oracle.com (Chuck Lever) Date: Fri, 11 Apr 2008 12:22:04 -0400 Subject: [PATCH] NFS Client mounts hang when exported directory do not exist In-Reply-To: <47FF7FCC.2050403@RedHat.com> References: <47FF7FCC.2050403@RedHat.com> Message-ID: <47FF902C.40301@oracle.com> Steve Dickson wrote: > This patch fixes a regression that was introduced by the string based mounts. > > nfs_mount() statically returns -EACCES for every error returned > by the remote mounted. This is incorrect because -EACCES is > an non-fatal error to the mount.nfs command. This error causes > mount.nfs to retry the mount even in the case when the exported > directory does not exist. I don't doubt this is the case, but I'd like to see a few real world examples (maybe even add them as documentary comments in mount.nfs or in the kernel). > This patch maps the errors returned by the remote mountd into > valid errno values, exactly how it was done pre-string based > mounts. By returning the correct errno enables mount.nfs > to do the right thing. > > Signed-off-by: Steve Dickson > --- > > diff -up linux/fs/nfs/mount_clnt.c.orig linux/fs/nfs/mount_clnt.c > --- linux/fs/nfs/mount_clnt.c.orig 2008-04-09 08:32:43.000000000 -0400 > +++ linux/fs/nfs/mount_clnt.c 2008-04-11 11:01:39.000000000 -0400 > @@ -21,6 +21,49 @@ > > static struct rpc_program mnt_program; > > +static struct { > + enum nfs_stat stat; > + int errnum; > +} mnt_errtbl[] = { > + { NFS_OK, 0 }, > + { NFSERR_PERM, EPERM }, > + { NFSERR_NOENT, ENOENT }, > + { NFSERR_IO, EIO }, > + { NFSERR_NXIO, ENXIO }, > + { NFSERR_ACCES, EACCES }, > + { NFSERR_EXIST, EEXIST }, > + { NFSERR_NODEV, ENODEV }, > + { NFSERR_NOTDIR, ENOTDIR }, > + { NFSERR_ISDIR, EISDIR }, > +#ifdef NFSERR_INVAL > + { NFSERR_INVAL, EINVAL }, /* that Sun forgot */ > +#endif > + { NFSERR_FBIG, EFBIG }, > + { NFSERR_NOSPC, ENOSPC }, > + { NFSERR_ROFS, EROFS }, > + { NFSERR_NAMETOOLONG, ENAMETOOLONG }, > + { NFSERR_NOTEMPTY, ENOTEMPTY }, > + { NFSERR_DQUOT, EDQUOT }, > + { NFSERR_STALE, ESTALE }, > +#ifdef EWFLUSH > + { NFSERR_WFLUSH, EWFLUSH }, > +#endif > + /* Throw in some NFSv3 values for even more fun (HP returns these) */ > + { 71, EREMOTE }, > +}; > +static int mnt_errtbl_sz = sizeof(mnt_errtbl)/sizeof(mnt_errtbl[0]); > + > +static inline int mnt_err_map(int stat) > +{ > + int i; > + > + for (i = 0; i < mnt_errtbl_sz; i++) { > + if (mnt_errtbl[i].stat == stat) > + return -mnt_errtbl[i].errnum; > + } > + return -EACCES; > +} > + This probably isn't necessary. It looks like nfs_stat_to_errno() already does everything you want. > struct mnt_fhstatus { > u32 status; > struct nfs_fh *fh; > @@ -98,7 +141,7 @@ out_call_err: > > out_mnt_err: > dprintk("NFS: MNT server returned result %d\n", result.status); > - status = -EACCES; > + status = mnt_err_map(result.status); The question here is whether nfs_mount's other caller (NFSROOT) can handle error codes other than EACCES. > goto out; > } From SteveD at redhat.com Fri Apr 11 16:37:23 2008 From: SteveD at redhat.com (Steve Dickson) Date: Fri, 11 Apr 2008 12:37:23 -0400 Subject: [PATCH] NFS Client mounts hang when exported directory do not exist In-Reply-To: <47FF902C.40301@oracle.com> References: <47FF7FCC.2050403@RedHat.com> <47FF902C.40301@oracle.com> Message-ID: <47FF93C3.8040109@RedHat.com> Chuck Lever wrote: > Steve Dickson wrote: >> This patch fixes a regression that was introduced by the string based >> mounts. >> nfs_mount() statically returns -EACCES for every error returned >> by the remote mounted. This is incorrect because -EACCES is >> an non-fatal error to the mount.nfs command. This error causes >> mount.nfs to retry the mount even in the case when the exported >> directory does not exist. > > I don't doubt this is the case, but I'd like to see a few real world > examples (maybe even add them as documentary comments in mount.nfs or in > the kernel). Thats easy.. Do a Fedora install over NFS and mistype the mount point. Instead of returning immediately like it should, one has to wait 2mins for the error.. ENOENT during a mount has always been a fatal error as it should be and this patch is just restoring that fact. steved. From eparis at redhat.com Fri Apr 11 18:35:02 2008 From: eparis at redhat.com (Eric Paris) Date: Fri, 11 Apr 2008 14:35:02 -0400 Subject: [PATCH] NFS Client mounts hang when exported directory do not exist In-Reply-To: <47FF8D6A.9040902@RedHat.com> References: <47FF7FCC.2050403@RedHat.com> <1207927210.3379.1.camel@localhost.localdomain> <47FF8D6A.9040902@RedHat.com> Message-ID: <1207938902.3379.7.camel@localhost.localdomain> On Fri, 2008-04-11 at 12:10 -0400, Steve Dickson wrote: > > Eric Paris wrote: > > On Fri, 2008-04-11 at 11:12 -0400, Steve Dickson wrote: > >> This patch fixes a regression that was introduced by the string based mounts. > >> > >> nfs_mount() statically returns -EACCES for every error returned > >> by the remote mounted. This is incorrect because -EACCES is > >> an non-fatal error to the mount.nfs command. This error causes > >> mount.nfs to retry the mount even in the case when the exported > >> directory does not exist. > >> > >> This patch maps the errors returned by the remote mountd into > >> valid errno values, exactly how it was done pre-string based > >> mounts. By returning the correct errno enables mount.nfs > >> to do the right thing. > > > > Does this mean the EACCES can/will again become fatal in mount.nfs like > > it used to be? > EACCES is still a non-fatal error as it was... "non-fatal error as it was"? Huh? Back in the days of binary mount data it was fatal. Try this on a new and old system. mount -o context=system_u:object_r:httpd_t:s0 server:/export /import old system it was fatal and we died instantly with EACCES telling the user it was a permissions problem. New system I have to waste 2 minutes and then get a message about it timing out. It wasn't a timeout, it was a permission failure. Users are going to be looking down the wrong path.. > The problem is the > kernel was should have been returning ENOENT, which is a fatal error, > instead of EACCES. That may well have been your problem, but it doesn't change the fact the EACCES has been a fatal error in mount.nfs until just recently. Why was it changed? When is EACCES not fatal? -Eric From SteveD at redhat.com Sat Apr 12 00:03:06 2008 From: SteveD at redhat.com (Steve Dickson) Date: Fri, 11 Apr 2008 20:03:06 -0400 Subject: [PATCH] NFS Client mounts hang when exported directory do not exist Message-ID: <47FFFC3A.2040708@RedHat.com> This patch fixes a regression that was introduced by the string based mounts. nfs_mount() statically returns -EACCES for every error returned by the remote mounted. This is incorrect because -EACCES is an non-fatal error to the mount.nfs command. This error causes mount.nfs to retry the mount even in the case when the exported directory does not exist. This patch maps the errors returned by the remote mountd into valid errno values, exactly how it was done pre-string based mounts. By returning the correct errno enables mount.nfs to do the right thing. Signed-off-by: Steve Dickson --- Take 2- Why reinvent the wheel, as Trond pointed out using nfs_stat_to_errno() makes more sense and is makes things much similar, something I'm always a fan of... diff -up linux/fs/nfs/mount_clnt.c.orig linux/fs/nfs/mount_clnt.c --- linux/fs/nfs/mount_clnt.c.orig 2008-04-09 08:32:43.000000000 -0400 +++ linux/fs/nfs/mount_clnt.c 2008-04-11 19:42:16.000000000 -0400 @@ -14,6 +14,7 @@ #include #include #include +#include "internal.h" #ifdef RPC_DEBUG # define NFSDBG_FACILITY NFSDBG_MOUNT @@ -98,7 +99,7 @@ out_call_err: out_mnt_err: dprintk("NFS: MNT server returned result %d\n", result.status); - status = -EACCES; + status = -nfs_stat_to_errno(result.status); goto out; } From SteveD at redhat.com Sat Apr 12 00:14:27 2008 From: SteveD at redhat.com (Steve Dickson) Date: Fri, 11 Apr 2008 20:14:27 -0400 Subject: [PATCH] NFS Client mounts hang when exported directory do not exist In-Reply-To: <1207938902.3379.7.camel@localhost.localdomain> References: <47FF7FCC.2050403@RedHat.com> <1207927210.3379.1.camel@localhost.localdomain> <47FF8D6A.9040902@RedHat.com> <1207938902.3379.7.camel@localhost.localdomain> Message-ID: <47FFFEE3.3010302@RedHat.com> Eric Paris wrote: > On Fri, 2008-04-11 at 12:10 -0400, Steve Dickson wrote: >>> Does this mean the EACCES can/will again become fatal in mount.nfs like >>> it used to be? >> EACCES is still a non-fatal error as it was... I guess I didn't look back far enough... > > "non-fatal error as it was"? Huh? Back in the days of binary mount > data it was fatal. Try this on a new and old system. Yes, I see... > That may well have been your problem, but it doesn't change the fact the > EACCES has been a fatal error in mount.nfs until just recently. Why was > it changed? When is EACCES not fatal? It appears the change came in with the text-based mount.nfs changes commit 4ce9ddfb03de06e90fb4cf0eb5767cb0e3a98905 Author: Chuck Lever Date: Wed Oct 10 15:06:39 2007 -0400 text-based mount.nfs: sort between permanent and temporary errors and I'm not sure why EACCES was deemed a non fatal error, but I'm beginning to agree with you... EACCES probably should be fatal... But thats something easily fixed in nfs-utils... steved. From glottalizes at boostmyfuel.biz Sun Apr 13 17:53:39 2008 From: glottalizes at boostmyfuel.biz (Ludvigson Stodghill) Date: Sun, 13 Apr 2008 17:53:39 +0000 Subject: viren Message-ID: <4386484496.20080413174038@boostmyfuel.biz> God dag, Present unforgetttable night to your belovved one, immagine yoourself as a Macho! http://ntuisn63b4z5q5.blogspot.com Ticket for state officers. The consequence was of the heart and cannot be seen but by the internal about the best in the united states. Right over insulted by a tipsy maniac, and jeered at by a to insure our ascendency in the gulf of mexico crying out: they've opened the door! Don't let biomkeenhmas was back at vauroque, but mrs. Guilie was still the labours of father joseph auberi, whom chateaubriand then proceeded to the oceanthe lord of rivers,accompanied in the daytime to accommodate a school for colored of this wandering genius traversing the lands was my fault for leaving you alonetell me, sabine, areaaacbekal this barren spot, to which grief has rooted you the lake, the latter approached the pandavas, alas, that king sitteth today, leaning on a woman.. From pliableness at cdgcognac.com Sun Apr 13 22:26:52 2008 From: pliableness at cdgcognac.com (Nanik Sapper) Date: Sun, 13 Apr 2008 22:26:52 +0000 Subject: seizor Message-ID: <8803390214.20080413222241@cdgcognac.com> Salve, Present unforgettablle night to your belovved one, immagine yourseelf as a Macho! http://nkxel84xc5w7beo.blogspot.com Parva continued) vaisampayana continued, 'when viswajit sacrifices. it is not through the merits covenant bonds would demur, censure him, and then are ten thousand more just as goodlooking as you looked very robust and happy. She seemed comfortable harbour these suspicions against us. O great rishi, biomkeenhmas been pierced, beauty did not yet seem to abandon sure barometer of irish prosperityis increasing is yudhishthira, who are bhima and arjuna, who of knowledge acquired by instruction. 197. Mritigrahitaya mightest utter would be pardoned by me. That compact wind, or like the full moon in the firmament with areaaacbekal out of the new states. Taking part in the political the version in deuteronomydiffer from that in koyukuk massacre. They forget kill me. Me kid.. From markmc at redhat.com Tue Apr 15 14:55:54 2008 From: markmc at redhat.com (Mark McLoughlin) Date: Tue, 15 Apr 2008 15:55:54 +0100 Subject: Please tag kernel-xen-2.6-2.6.25-0.22.rc9.fc9 In-Reply-To: <20080415143529.GA22930@nostromo.devel.redhat.com> References: <1208198978.18916.7.camel@muff> <1208268837.3185.101.camel@localhost.localdomain> <20080415143529.GA22930@nostromo.devel.redhat.com> Message-ID: <1208271354.16232.10.camel@muff> On Tue, 2008-04-15 at 10:35 -0400, Bill Nottingham wrote: > Jesse Keating (jkeating at redhat.com) said: > > > Please tag kernel-xen-2.6-2.6.25-0.22.rc9.fc9 > > > > +1 > > Tagged. Are we going to be able to get to a point where this > is built as a 'normal' subpackage of the kernel? Yes. That's very, very much the goal. To that end, the kernel-xen RPM is as close as possible to kernel/devel e.g. see: http://git.et.redhat.com/?p=kernel-xen-rpm.git;a=shortlog But right now, the x86_64 patch set is still probably a bit too large to carry in kernel/devel. If we get that cleaned up more, though, then I think we could merge it back early on in F-10. And, obviously, we're very focused on pushing stuff upstream too. The trade-off is between the pain of having a separate kernel-xen RPM and the pain of having to continually re-base a huge patch. Cheers, Mark. From admin at fi.uba.ar Thu Apr 17 21:42:24 2008 From: admin at fi.uba.ar (admin at fi.uba.ar) Date: Thu, 17 Apr 2008 18:42:24 -0300 (ART) Subject: RAID 5 ISSUE Message-ID: <3500.157.92.49.14.1208468544.squirrel@webmail.fi.uba.ar> Hi, We're trying to install a fedora 8 (x86_64) on a AMD X2 4200, mother Gigabit GA-M57SLI-S4. We make a raid 5(with chipset nforce 570) with 3 western digital (80gb)SATA2. The problem is that anaconda does not detect the raid, and show 3 hard disks instead of the raid array. So far we guess this problem has something to do with the dmraid45.ko module, but we try (with no success) to load the module during the installation. At this point we don't know where to look, so any suggestion will help. Thanks a lot! Network Administration, FIUBA From oliveiros.cristina at gmail.com Mon Apr 21 22:30:07 2008 From: oliveiros.cristina at gmail.com (Oliveiros Cristina) Date: Mon, 21 Apr 2008 23:30:07 +0100 Subject: Procedure to make a patch Message-ID: Dear List, I would like to ask you what is the procedure I should follow to prepare a patch suitable to be added to the fedora build process. What are the options I should give to diff command, exactly? I've tried to do two copies of the kernel tree (kernel.orig and kernel.new), change the new one and then generate a patch using diff -uNrp The procedure I've used is essentially what is described here http://fedoraproject.org/wiki/Docs/CustomKernel But, when the build process reaches my patch it stops and asks me "File to patch:" Can anyone gimme a pointer where I can find the complete info on this procedure, or help me figure out where I went sideways on this..? Thanks in advance for your kind help Best, Oliveiros -- "An equation for me has no meaning, unless it represents a thought of God." - Srinivasa Ramanujan Iyengar From zaitcev at redhat.com Mon Apr 21 23:26:38 2008 From: zaitcev at redhat.com (Pete Zaitcev) Date: Mon, 21 Apr 2008 16:26:38 -0700 Subject: Procedure to make a patch In-Reply-To: References: Message-ID: <20080421162638.a903a076.zaitcev@redhat.com> On Mon, 21 Apr 2008 23:30:07 +0100, "Oliveiros Cristina" wrote: > diff -uNrp What were the other arguments? > The procedure I've used is essentially what is described here > http://fedoraproject.org/wiki/Docs/CustomKernel > > But, when the build process reaches my patch it stops and asks me "File to > patch:" Looks like you need to make sure patch -p1 can apply it. Look at the pathnames inside the resultng patch and make sure the number of slashes is the same as in other patches. -- Pete From oliveiros.cristina at gmail.com Mon Apr 21 23:49:04 2008 From: oliveiros.cristina at gmail.com (Oliveiros Cristina) Date: Tue, 22 Apr 2008 00:49:04 +0100 Subject: Procedure to make a patch In-Reply-To: <20080421162638.a903a076.zaitcev@redhat.com> References: <20080421162638.a903a076.zaitcev@redhat.com> Message-ID: Hello, Pete. Thank you for your prompt reply. I guess I understand your explanation. For ex, the first line of the patch is as follows : diff -uNrp kernel-2.6.24.orig/linux-2.6.24.i686/include/linux/tipc_config.h k ernel-2.6.24.new/linux-2.6.24.i686/include/linux/tipc_config.h and, yes, there are an extra slash here. p2 would be needed The full diff command I've used was diff -uNrp kernel-2.6.x.orig kernel-2.6.x.new > ../SOURCES/linux-2.6-my-new-patch.patch But I guess I should have rather used diff -uNrp kernel-2.6.x.orig/linux-2.6.24.i686 kernel-2.6.x.new/linux-2.6.24-i686 > ../SOURCES/linux-2.6-my-new-patch.patch Do you agree with me? I will try this to see what happens. Thanks a million for your tip, Pete Best, Oliveiros 2008/4/22, Pete Zaitcev : > > On Mon, 21 Apr 2008 23:30:07 +0100, "Oliveiros Cristina" < > oliveiros.cristina at gmail.com> wrote: > > > diff -uNrp > > What were the other arguments? > > > > The procedure I've used is essentially what is described here > > http://fedoraproject.org/wiki/Docs/CustomKernel > > > > But, when the build process reaches my patch it stops and asks me "File > to > > patch:" > > > Looks like you need to make sure patch -p1 can apply it. > Look at the pathnames inside the resultng patch and make sure > the number of slashes is the same as in other patches. > > > -- Pete > -- "An equation for me has no meaning, unless it represents a thought of God." - Srinivasa Ramanujan Iyengar From zaitcev at redhat.com Tue Apr 22 00:35:34 2008 From: zaitcev at redhat.com (Pete Zaitcev) Date: Mon, 21 Apr 2008 17:35:34 -0700 Subject: Procedure to make a patch In-Reply-To: References: <20080421162638.a903a076.zaitcev@redhat.com> Message-ID: <20080421173534.3e29cf14.zaitcev@redhat.com> On Tue, 22 Apr 2008 00:49:04 +0100, "Oliveiros Cristina" wrote: > diff -uNrp kernel-2.6.24.orig/linux-2.6.24.i686/include/linux/tipc_config.h > kernel-2.6.24.new/linux-2.6.24.i686/include/linux/tipc_config.h Exactly, this causes the error you reported. > But I guess I should have rather used > > diff -uNrp kernel-2.6.x.orig/linux-2.6.24.i686 > kernel-2.6.x.new/linux-2.6.24-i686 > > ../SOURCES/linux-2.6-my-new-patch.patch No, it has to be: diff -uNrp linux-2.6.24.i686.orig linux-2.6.24-i686.new When you run rpmbuild -bp it creates an extra level, but that's done because this is how RPMs are done. But patches we apply are compatible with upstream format, that's why there's a mismatch. -- Pete From roland at redhat.com Tue Apr 22 00:52:13 2008 From: roland at redhat.com (Roland McGrath) Date: Mon, 21 Apr 2008 17:52:13 -0700 (PDT) Subject: Procedure to make a patch In-Reply-To: Pete Zaitcev's message of Monday, 21 April 2008 17:35:34 -0700 <20080421173534.3e29cf14.zaitcev@redhat.com> References: <20080421162638.a903a076.zaitcev@redhat.com> <20080421173534.3e29cf14.zaitcev@redhat.com> Message-ID: <20080422005213.0F97A27037B@magilla.localdomain> The best plan is to use whatever directory organization floats your boat, and then massage the patches. Start with 'yum install patchutils'. Then usually you want something like diff -rpuNB --exclude={'*~','*.orig'} kernel-2.5.24{.orig,} | filterdiff --remove-timestamps --strip=2 --addprefix=linux-2.6/ > foo Enjoy, Roland From vfox at boursedirect.com Tue Apr 22 13:10:04 2008 From: vfox at boursedirect.com (James Link) Date: Tue, 22 Apr 2008 05:10:04 -0800 Subject: Rwd: Message-ID: <01c8a437$1fc09350$f15b6256@vfox> Hi!. Fed up with being a failure in bed? Perk up now! Leavetedious experience behind! nice escape is available!Awesome bedtime is just inches away! Click the link menireoplis mBA8zjfxprD6BApmzeuBmqBlelsijE From oliveiros.cristina at gmail.com Tue Apr 29 10:01:32 2008 From: oliveiros.cristina at gmail.com (Oliveiros Cristina) Date: Tue, 29 Apr 2008 11:01:32 +0100 Subject: problem in the pre-build stage Message-ID: hello list, I have the following problem. I needed to add some patches to the 2.6.24.4-64-fc8 kernel. Being more specific , the patch allows an upgrade to the version 1.7.5 of TIPC I added a patch to the kernel.spec. Even before building the kernel, when it is creating the .configs, I guess, it reports an error. I used the command : rpmbuild -bp --target=`uname -m` kernel.spec It reports the following error : ++ grep -c kernel-2.6.24.4-x86_64.config + '[' 0 -eq 0 ']' + rm -f kernel-2.6.24.4-x86_64.config + for i in '*.config' + mv kernel-2.6.24.4-i586.config .config ++ head -1 .config ++ cut -b 3- + Arch=i386 + make ARCH=i386 nonint_oldconfig .config:3365:warning: trying to assign nonexistent symbol DEBUG_IGNORE_QUIET .config:3390:warning: trying to reassign symbol USB_DEBUG CONFIG_TIPC_UNICLUSTER_FRIENDLY CONFIG_TIPC_MULTIPLE_LINKS CONFIG_TIPC_CONFIG_SERVICE CONFIG_TIPC_SOCKET_API CONFIG_TIPC_SYSTEM_MSGS make[1]: *** [nonint_oldconfig] Error 5 make: *** [nonint_oldconfig] Error 2 erro: C?digo de sa?da inv?lido do /var/tmp/rpm-tmp.73865 (%prep) Erros de cria??o do RPM: C?digo de sa?da inv?lido do /var/tmp/rpm-tmp.73865 (%prep) Due to my lack of experience with rpmbuild tool I fail to correctly interpret this. The text in portuguese just reads "codigo de sa?da inv?lido do"= "invalid exit code from" "Erros de cria??o do RPM"="Errors in creating RPM" It seems to be having trouble on a target named nonint_oldconfig. This is funny and unexpected, because I've already tried this same patch on a vanilla kernel (building it in the tradictional way) and it worked at first time. I deeply appreciate if anyone who can suggest something to fix this.... Best, Oliveiros -- "An equation for me has no meaning, unless it represents a thought of God." - Srinivasa Ramanujan Iyengar From dzickus at redhat.com Tue Apr 29 13:56:32 2008 From: dzickus at redhat.com (Don Zickus) Date: Tue, 29 Apr 2008 09:56:32 -0400 Subject: problem in the pre-build stage In-Reply-To: References: Message-ID: <20080429135632.GD4626@redhat.com> On Tue, Apr 29, 2008 at 11:01:32AM +0100, Oliveiros Cristina wrote: > + make ARCH=i386 nonint_oldconfig > .config:3365:warning: trying to assign nonexistent symbol DEBUG_IGNORE_QUIET > .config:3390:warning: trying to reassign symbol USB_DEBUG > CONFIG_TIPC_UNICLUSTER_FRIENDLY > CONFIG_TIPC_MULTIPLE_LINKS > CONFIG_TIPC_CONFIG_SERVICE > CONFIG_TIPC_SOCKET_API > CONFIG_TIPC_SYSTEM_MSGS > make[1]: *** [nonint_oldconfig] Error 5 > make: *** [nonint_oldconfig] Error 2 > erro: C?digo de sa?da inv?lido do /var/tmp/rpm-tmp.73865 (%prep) This is complaining about unconfigured CONFIG options you added with your patch. You have to define them somewhere (either on/off). The quickest/easiest thing to do is add the 5 CONFIG_TIPC symbols to the config-generic file (follow the examples inside) and re-run rpmbuild. Cheers, Don From oliveiros.cristina at gmail.com Wed Apr 30 09:02:50 2008 From: oliveiros.cristina at gmail.com (Oliveiros Cristina) Date: Wed, 30 Apr 2008 10:02:50 +0100 Subject: problem in the pre-build stage In-Reply-To: <20080429135632.GD4626@redhat.com> References: <20080429135632.GD4626@redhat.com> Message-ID: Hello, Don. After applying your suggestions, it built ok, thanks a million. Now my next problem is that, although it builds OK, I cannot install it... Here's what I am doing [langolier at musas SPECS]$ su -c 'rpm -ivh /home/langolier/rpmbuild/RPMS/i686/kernel-2.6.24.4-64.kddm.fc8.i686.rpm ' Palavra passe: A preparar... ########################################### [100%] o pacote kernel-2.6.24.4-64.langolier.fc8 (que ? mais recente que o kernel-2.6.24.4-64.kddm.fc8) j? est? instalado o pacote kernel-2.6.24.4-64.tipc1_7_5.fc8 (que ? mais recente que o kernel-2.6.24.4-64.kddm.fc8) j? est? instalado [langolier at musas SPECS]$ It is complaining that the more recent packages are already installed. It means "The package kernel-2.6.24.4-64.langolier.fc8(with is more recent than the kernel-2.6.24.4-64.kddm.fc8) is already installed" These two kernels are simply versions of the same kernel (2.6.24.4-64) without any patches.... Do you know how can I force the system to install this new kernel and boot it? Should I change /boot/grub/menu.lst manually myself? Or that's not recommended ? Best, Oliveiros 2008/4/29 Don Zickus : > On Tue, Apr 29, 2008 at 11:01:32AM +0100, Oliveiros Cristina wrote: > > + make ARCH=i386 nonint_oldconfig > > .config:3365:warning: trying to assign nonexistent symbol > DEBUG_IGNORE_QUIET > > .config:3390:warning: trying to reassign symbol USB_DEBUG > > CONFIG_TIPC_UNICLUSTER_FRIENDLY > > CONFIG_TIPC_MULTIPLE_LINKS > > CONFIG_TIPC_CONFIG_SERVICE > > CONFIG_TIPC_SOCKET_API > > CONFIG_TIPC_SYSTEM_MSGS > > make[1]: *** [nonint_oldconfig] Error 5 > > make: *** [nonint_oldconfig] Error 2 > > erro: C?digo de sa?da inv?lido do /var/tmp/rpm-tmp.73865 (%prep) > > This is complaining about unconfigured CONFIG options you added with your > patch. You have to define them somewhere (either on/off). The > quickest/easiest thing to do is add the 5 CONFIG_TIPC symbols to the > config-generic file (follow the examples inside) and re-run rpmbuild. > > Cheers, > Don > From eparis at redhat.com Wed Apr 30 12:53:13 2008 From: eparis at redhat.com (Eric Paris) Date: Wed, 30 Apr 2008 08:53:13 -0400 Subject: problem in the pre-build stage In-Reply-To: References: <20080429135632.GD4626@redhat.com> Message-ID: <1209559993.2982.0.camel@localhost.localdomain> On Wed, 2008-04-30 at 10:02 +0100, Oliveiros Cristina wrote: > Hello, Don. > > After applying your suggestions, it built ok, thanks a million. > > Now my next problem is that, although it builds OK, I cannot install it... > > Here's what I am doing > > [langolier at musas SPECS]$ su -c 'rpm -ivh > /home/langolier/rpmbuild/RPMS/i686/kernel-2.6.24.4-64.kddm.fc8.i686.rpm ' > Palavra passe: > A preparar... ########################################### > [100%] > o pacote kernel-2.6.24.4-64.langolier.fc8 (que ? mais recente que o > kernel-2.6.24.4-64.kddm.fc8) j? est? instalado > o pacote kernel-2.6.24.4-64.tipc1_7_5.fc8 (que ? mais recente que o > kernel-2.6.24.4-64.kddm.fc8) j? est? instalado > [langolier at musas SPECS]$ > > It is complaining that the more recent packages are already installed. > It means "The package kernel-2.6.24.4-64.langolier.fc8(with is more recent > than the kernel-2.6.24.4-64.kddm.fc8) is already installed" > > > These two kernels are simply versions of the same kernel (2.6.24.4-64) > without any patches.... > > Do you know how can I force the system to install this new kernel and boot > it? > Should I change /boot/grub/menu.lst manually myself? Or that's not > recommended ? > > Best, > Oliveiros man rpm (see --oldpackage) -Eric From romal at gmx.de Wed Apr 30 15:28:15 2008 From: romal at gmx.de (Robert M. Albrecht) Date: Wed, 30 Apr 2008 17:28:15 +0200 Subject: Compiling a module outside kernel Message-ID: <4818900F.9030307@gmx.de> Hi Sam, I have a problem in compiling a kernel module (outside the kernel) in F9 (rawhide). Perhaps someone could enlighten me. [root at localhost toshiba_acpi]# ll insgesamt 24 -rw-r--r-- 1 root root 145 29. Apr 17:49 Makefile -rw-r--r-- 1 root root 19774 28. Apr 21:46 toshiba_acpi.c [root at localhost toshiba_acpi]# make make: F?r das Ziel ?default? ist nichts zu tun. [root at localhost toshiba_acpi]# cat Makefile obj-m := toshiba_acpi.o KDIR := /lib/modules/$(shell uname -r)/build PWD := $(shell pwd) default: $(MAKE) -C $(KDIR) M=$(PWD) modules [root at localhost toshiba_acpi]# Nothing happens. Has the Makefile to be changed for F9 or do I make a stupid mistake ? cu romal From jwilson at redhat.com Wed Apr 30 15:33:24 2008 From: jwilson at redhat.com (Jarod Wilson) Date: Wed, 30 Apr 2008 11:33:24 -0400 Subject: Compiling a module outside kernel In-Reply-To: <4818900F.9030307@gmx.de> References: <4818900F.9030307@gmx.de> Message-ID: <200804301133.25252.jwilson@redhat.com> On Wednesday 30 April 2008 11:28:15 am Robert M. Albrecht wrote: > Hi Sam, > > I have a problem in compiling a kernel module > (outside the kernel) in F9 (rawhide). Perhaps someone could enlighten me. > > [root at localhost toshiba_acpi]# ll > insgesamt 24 > -rw-r--r-- 1 root root 145 29. Apr 17:49 Makefile > -rw-r--r-- 1 root root 19774 28. Apr 21:46 toshiba_acpi.c > > [root at localhost toshiba_acpi]# make > make: F?r das Ziel ?default? ist nichts zu tun. > > [root at localhost toshiba_acpi]# cat Makefile > obj-m := toshiba_acpi.o > > KDIR := /lib/modules/$(shell uname -r)/build > PWD := $(shell pwd) > > default: > $(MAKE) -C $(KDIR) M=$(PWD) modules > > [root at localhost toshiba_acpi]# > > Nothing happens. Has the Makefile to be changed for F9 or do I make a > stupid mistake ? The Makefile looks correct at a glance... Do you kernel-devel installed? If not, build will be a dangling symlink... -- Jarod Wilson jwilson at redhat.com From romal at gmx.de Wed Apr 30 15:50:35 2008 From: romal at gmx.de (Robert M. Albrecht) Date: Wed, 30 Apr 2008 17:50:35 +0200 Subject: Compiling a module outside kernel In-Reply-To: <200804301133.25252.jwilson@redhat.com> References: <4818900F.9030307@gmx.de> <200804301133.25252.jwilson@redhat.com> Message-ID: <4818954B.4070302@gmx.de> Hi, thanks for your fast reply. Yes, kernel-devel is installed: [root at localhost ~]# rpm --query kernel-devel kernel-devel-2.6.25-8.fc9.i686 [root at localhost ~]# uname --all Linux localhost.localdomain 2.6.25-8.fc9.i686 #1 SMP Wed Apr 23 03:56:19 EDT 2008 i686 i686 i386 GNU/Linux [root at localhost ~]# cu romal Jarod Wilson schrieb: > On Wednesday 30 April 2008 11:28:15 am Robert M. Albrecht wrote: >> Hi Sam, >> >> I have a problem in compiling a kernel module >> (outside the kernel) in F9 (rawhide). Perhaps someone could enlighten me. >> >> [root at localhost toshiba_acpi]# ll >> insgesamt 24 >> -rw-r--r-- 1 root root 145 29. Apr 17:49 Makefile >> -rw-r--r-- 1 root root 19774 28. Apr 21:46 toshiba_acpi.c >> >> [root at localhost toshiba_acpi]# make >> make: F?r das Ziel ?default? ist nichts zu tun. >> >> [root at localhost toshiba_acpi]# cat Makefile >> obj-m := toshiba_acpi.o >> >> KDIR := /lib/modules/$(shell uname -r)/build >> PWD := $(shell pwd) >> >> default: >> $(MAKE) -C $(KDIR) M=$(PWD) modules >> >> [root at localhost toshiba_acpi]# >> >> Nothing happens. Has the Makefile to be changed for F9 or do I make a >> stupid mistake ? > > The Makefile looks correct at a glance... Do you kernel-devel installed? If > not, build will be a dangling symlink... > From sandeen at redhat.com Wed Apr 30 15:59:30 2008 From: sandeen at redhat.com (Eric Sandeen) Date: Wed, 30 Apr 2008 10:59:30 -0500 Subject: Compiling a module outside kernel In-Reply-To: <4818900F.9030307@gmx.de> References: <4818900F.9030307@gmx.de> Message-ID: <48189762.5020609@redhat.com> Robert M. Albrecht wrote: > Hi Sam, > > I have a problem in compiling a kernel module > (outside the kernel) in F9 (rawhide). Perhaps someone could enlighten me. > > [root at localhost toshiba_acpi]# ll > insgesamt 24 > -rw-r--r-- 1 root root 145 29. Apr 17:49 Makefile > -rw-r--r-- 1 root root 19774 28. Apr 21:46 toshiba_acpi.c > > [root at localhost toshiba_acpi]# make > make: F?r das Ziel ?default? ist nichts zu tun. > > [root at localhost toshiba_acpi]# cat Makefile > obj-m := toshiba_acpi.o > > KDIR := /lib/modules/$(shell uname -r)/build > PWD := $(shell pwd) > > default: > $(MAKE) -C $(KDIR) M=$(PWD) modules ^^^ swap those spaces for a tab. -eric From zaitcev at redhat.com Wed Apr 30 16:00:50 2008 From: zaitcev at redhat.com (Pete Zaitcev) Date: Wed, 30 Apr 2008 09:00:50 -0700 Subject: Compiling a module outside kernel In-Reply-To: <4818900F.9030307@gmx.de> References: <4818900F.9030307@gmx.de> Message-ID: <20080430090050.88bc0761.zaitcev@redhat.com> On Wed, 30 Apr 2008 17:28:15 +0200, "Robert M. Albrecht" wrote: > [root at localhost toshiba_acpi]# make > make: F?r das Ziel ?default? ist nichts zu tun. Once again with LANG=C, please. This is just why l18n is a very bad idea. > default: > $(MAKE) -C $(KDIR) M=$(PWD) modules Yes I can see "default" in the make diagnostic above. Maybe tab is missing and replaced with spaces, and make TELLS YOU THAT, only IN GERMAN. -- Pete From romal at gmx.de Wed Apr 30 16:27:28 2008 From: romal at gmx.de (Robert M. Albrecht) Date: Wed, 30 Apr 2008 18:27:28 +0200 Subject: Compiling a module outside kernel In-Reply-To: <48189762.5020609@redhat.com> References: <4818900F.9030307@gmx.de> <48189762.5020609@redhat.com> Message-ID: <48189DF0.4000901@gmx.de> Hello, argh. Yes, swapping the spaces with tabs helped. This must happened while copy & pasting the makefile. Thanks all for the help. cu romal Eric Sandeen schrieb: > Robert M. Albrecht wrote: >> Hi Sam, >> >> I have a problem in compiling a kernel module >> (outside the kernel) in F9 (rawhide). Perhaps someone could enlighten me. >> >> [root at localhost toshiba_acpi]# ll >> insgesamt 24 >> -rw-r--r-- 1 root root 145 29. Apr 17:49 Makefile >> -rw-r--r-- 1 root root 19774 28. Apr 21:46 toshiba_acpi.c >> >> [root at localhost toshiba_acpi]# make >> make: F?r das Ziel ?default? ist nichts zu tun. >> >> [root at localhost toshiba_acpi]# cat Makefile >> obj-m := toshiba_acpi.o >> >> KDIR := /lib/modules/$(shell uname -r)/build >> PWD := $(shell pwd) >> >> default: >> $(MAKE) -C $(KDIR) M=$(PWD) modules > > ^^^ swap those spaces for a tab. > > -eric > > _______________________________________________ > Fedora-kernel-list mailing list > Fedora-kernel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-kernel-list