Downloading linux-2.6.31.tar.bz2...
That is the make sources part. Just try it again.
IIRC it just runs curl from some fedoraproject.org site.
So if that is hanging, then talk to the Fedora infrastructure folks.
___
Fedora-kernel-list mailing list
$ make git/utrace/prep
it hung here witout any output
No such problem for me. Look with ps what is hanging. Note that since
this weekend Fedora pkgs checkouts using cvs.fedora.redhat.com no longer
work and cvs will tend to hang for a long time if you use them. Try a
fresh checkout being sure
On Thu, Sep 17, 2009 at 09:31:52PM +0200, Jakub Jelinek wrote:
I've noticed the dot in front of the symbol, is kernel using still the for
years deprecated oldish ppc64 ABI instead of the new one (i.e. uses
-mcall-aixdesc instead of not using this option at all)? Maybe it is broken
only
I reproduced what jwb reported on the powerstation.
Mine is with F10 + updates userland, only the kernel seems to matter.
The test case is:
# modprobe iscsi_tcp
Illegal Instruction
#
On -16[278], same oops that jwb saw, wrong text appearing at a page boundary.
This
Great. I ended up having lots of other issues with vanilla build. At
some point during the build, the make oldconfig becomes interactive
during the %install phase.
%install?? Weird. That should not be happening. Maybe a V=1 on the make
command would make kbuild explain why it decided
You should always specify an arch.
make prep uses noarch and generally works fine. You can just ignore the
strange assembler messages in the 'make configs' phase and the .config
files come out fine, in my experience.
___
Fedora-kernel-list mailing
- Should we be using the PAE kernel *regardless* of memory size (as
implied above) or do we want some memory requirements?
It's always preferable on hardware (where pae actually works) that also has
the nx cpu feature. True PROT_EXEC enforcement (NX) is only available in
PAE mode.
Thanks,
Patch below seems to dtrt.. comments?
Why kill the configs, instead of just changing the spec settings?
@@ -1477,7 +1481,9 @@ mkdir -p $RPM_BUILD_ROOT/boot
cd linux-%{kversion}.%{_target_cpu}
%if %{with_debug}
+%ifnarch i686
BuildKernel %make_target %kernel_image debug
+%endif
%if
I've been thinking for a while execshield.patch could be split into two or
three cleaner patches. Some of those might even be upstreamable as config
options or something. It really isn't that big a patch at this point.
___
Fedora-kernel-list mailing
Fedora kernel folks don't really pay attention to utrace innards except to
make sure that I get the flames about them. The place dedicated to
discussion of those innards is [EMAIL PROTECTED]. (It's fine to
mention the Fedora kernel versions and bugzilla links on that list.)
That fix is one that
Have you also looked at the kerneloops.org data? That tends to have a
nice collection of utrace oopses/warnings...
I typed utrace in the Function Search box. The only common one (many
many hits) was fixed a while ago (on 9/15 around lunch time, it so happens).
The other ones for non-ancient
What's this about?
___
Fedora-kernel-list mailing list
Fedora-kernel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-kernel-list
linux-2.6-acpi-video-dos.patch
linux-2.6-defaults-acpi-video.patch
These are policy decisions. Probably not going usptream.
Can they be turned into upstream config options?
___
Fedora-kernel-list mailing list
Fedora-kernel-list@redhat.com
I reenabled kernel-doc and tweaked it up.
* Make htmldocs too. Some pithy bits are only in the .tmpl stuff and it is
nice to be able to point people at install kernel-doc and point your
browser at file:///..., etc.
* make in %build, only install in %install. Pure rpm anality.
* Use
Running rebase.sh was so much fun that I for some reason decided to do
Dave's job today and once I'd run it then I had to cope with the kconfig
changes upstream.
I hacked linux-2.6-build-nonintconfig.patch and is seems to be about
right again. But I never did try to really understand that
I find myself doing a lot of make prep lately in the days of frequent
new upstream base patches. The untar still takes a lot longer than
the big patch. So I committed this to speed it up for the repeated
rebase case.
Thanks,
Roland
Index: kernel.spec
All sounds fairly reasonable to me, but why not have make vdso_install
install the file?
Yeah, that will be the right thing for upstream eventually.
Probably for upstream it is preferred to install files only
in $INSTALL_MOD_PATH and not go touching /etc.
So I think the norm will be something
I added these to config-generic to keep building with -git11.
I have no idea if these are the right settings.
+# CONFIG_MFD_TC6393XB is not set
+# CONFIG_BOOTPARAM_SOFTLOCKUP_PANIC is not set
+CONFIG_DMADEVICES=y
+CONFIG_INTEL_IOATDMA=m
+# CONFIG_DMATEST is not set
Thanks,
Roland
Why bother? If it comes up in the future, the macro will be handy.
___
Fedora-kernel-list mailing list
Fedora-kernel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-kernel-list
If you try and use e.g. kernel_obsoletes, you'll soon find
that it's actually kernel__obsoletes you currently need :-)
So you want kernel to have an Obsoletes: that kernel-foo do not get?
___
Fedora-kernel-list mailing list
On Wed, 2008-07-23 at 12:44 -0700, Roland McGrath wrote:
If you try and use e.g. kernel_obsoletes, you'll soon find
that it's actually kernel__obsoletes you currently need :-)
So you want kernel to have an Obsoletes: that kernel-foo do not get?
Yes; kernel-PAE.i686 obsoletes kernel
We should really only install ld.so.conf files from packages
that actually have CONFIG_XEN enabled, but it would be
slightly messy to have only kernel-PAE.i686 and kernel.x86_64
include it.
It wouldn't really be so hard to conditionalize it at least for the arch's
that ever need it. (The
BTW, see http://koji.fedoraproject.org/scratch/roland/task_714174/
for a kernel-vanilla build I did of 2.6.26.
This gives a baseline for regression testing any problems to see if they
are caused by some Fedora patches (e.g. utrace) or are also upstream.
I think koji scratch only stays around for
very simply put:
it's between getting this level of information:
http://www.kerneloops.org/raw.php?rawid=32356
with pointing at the exact code, and only getting this
http://www.kerneloops.org/raw.php?rawid=32287
Thanks. I'd like to help improve the tools so that we can close this
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
Is there an alternate Koji or some other means by which I can try
rawhide/ia64 rpm builds?
This is caused by the change of
#define TIF_RESTORE_SIGMASK 5
to
#define TIF_RESTORE_SIGMASK 22
Is there a need to change this bit from 5 to 22? If that really is
needed we are going to
I will probably continue to find it desireable to make a dozen different
100-200M partitions to use as /boot for installs, so I don't really care
about the name noncollision. But it sure would make it a little simpler
to use (hd0,N)/ TAB in GRUB to remind me which partition is which, as
I'm
I've put the 2.6.25 rebase of utrace back in and kicked off a build.
I'll pick up the pieces if it comes out all broken.
(It already did, cause I forgot to test the ppc32 build upstream.)
For the moment it's applied as one big patch instead of a series.
I haven't figured out the arrangement for
Huh? debugfiles.list populates kernel-debuginfo-common.
debuginfo.list populates kernel-debuginfo.
Thanks,
Roland
___
Fedora-kernel-list mailing list
Fedora-kernel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-kernel-list
M linux-2.6-i386-vdso-install-unstripped-copies-on-disk.patch
needs a bit of inspection, looks right (and builds ok)
This one should be upstream now. If anything is still missing, I should be
able to get it in for 2.6.25.
M linux-2.6-utrace-core.patch
M linux-2.6-utrace-tracehook.patch
I needed the following patch to be able to build the fedora rpms
on i386. This is likely a case of the new code doing the right thing,
but me not being able to figure out the debug stuff in the spec file
at the time though.
I sent a fix upstream for that.
Thanks,
Roland
Your attachment was empty.
The execshield patch has gotten much smaller than it was in the beginning.
It still hasn't gotten all the cleanup it could get though. The patch does
a few different things that ideally would be in separate patches.
1. Segment-based PAGE_EXEC for no-NX hardware (and
David is correct that eu-elfcmp is meant to see the stripped and unstripped
files as matching. Josh is correct that the .gnu.attributes section is the
new thing that is provoking the problem, owing to GCC 4.3.
I'm doing three things:
1. elfcmp's bug is that it sees the .gnu.attribute sections
Could this be yet another problem caused by the switch to GCC 4.3?
Hard to see what it could have done to cp. ;-)
+ cp vmlinux /var/tmp/kernel-2.6.24-14.fc9-root-ppc/boot/vmlinuz-2.6.24-14.fc9
...
+ cp vmlinux
/var/tmp/kernel-2.6.24-14.fc9-root-ppc/usr/lib/debug/lib/modules/2.6.24-14.fc9
Oh wait, the copied not linked warning probaby explains the whole thing.
The /usr/lib/debug copy is not stripped, so it's not identical.
Yeah, ok. I wonder why this wasn't happening before.
I think it is just fixed by resolving the problems with too many copies of
vmlinux.
Thanks,
Roland
Why are we building kernels with this broken compiler?
http://bugzilla.kernel.org/show_bug.cgi?id=8501
http://koji.fedoraproject.org/koji/getfile?taskID=388196name=build.log
Why are we building these broken kernels with our shiny new compiler?
Roland, I don't suppose any of the recent changes I seem to recall
hearing you were going to make to debuginfo might have anything to do
with this...
Seems unlikely since I haven't actually made any yet.
___
Fedora-kernel-list mailing list
Maybe this is because even after we strip out the debuginfo, file was
reporting not stripped, so someone decided to override that and always
report them as stripped? I just used eu-unstrip to reassemble a module
with the full debuginfo and file still doesn't say anything about it...
file's
Is F-[78] going to stay on 2.6.23 for a while, or switch to 2.6.24 fairly soon?
Thanks,
Roland
___
Fedora-kernel-list mailing list
Fedora-kernel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Ok, thanks for the info. If it's not likely to be weeks and weeks, then I
don't think I'll update the utrace/2.6.23 backport any more with recent fixes.
utrace/2.6-current is now on 2.6.24, and I won't rebase it for a few days.
When it breaks rawhide or when I get to it, I'll branch utrace/2.6.24
On Wed, 23 Jan 2008 23:03:15 -0800 (PST)
Roland McGrath [EMAIL PROTECTED] wrote:
It is probably a better solution not to have a vmlinux.debug but instead
keep the simple cp, and avoid the vmlinu[xz].debug files by explicitly
stripping the /boot copy of vmlinux.
I wish you wouldn't
I browsed a few of the internals, and it looks like the ppc variant includes
a complete source tree
in /usr/src/debug
It's normal to have every source file referenced by any binary's DWARF info.
for x in */debug/kernel-debuginfo-2*.rpm; do for y in $x `echo $x | sed
I may have hashed this out with davej only in private before, so perhaps
you aren't aware of the normal plan for utrace updates. You disabled
utrace when you should have just run ./scripts/pull-upstreams.sh to get the
current patch set. The 2008-1-3 version of the patches already applied
fine.
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
The reasons against it in the past were that it slowed down
the common case (people who aren't using the feature)
It doesn't look like it should.
___
Fedora-kernel-list mailing list
Fedora-kernel-list@redhat.com
On Fri, 2007-08-17 at 12:29 -0700, Roland McGrath wrote:
I'd like to help figure out what the specific problem is, so we can solve
it properly.
OK, but how do we start? :)
I've CC'd Jakub, who has a tendency to know every corner of this sort of thing.
If that alone doesn't do
I fixed this in rawhide kernel.spec over the weekend and left a somewhat
detailed comment in the changed bit. But I thought I'd bring this up
directly and explain the story.
The short version of What Broke is what, you sha1 on me? no, i sha1 on you!
Module signing works by feeding all the
Is there a reason to add a hack to the kernel %post in particular,
instead of just making people use rpm triggers? I mean, horror and all that.
But at least it's generic SEP horror, and not new hair for the kernel rpm
itself (i.e. our problem).
Thanks,
Roland
I put in the macroified kernel.spec last night. It also has some new magic
changes to play well with the new find-debuginfo.sh. It hasn't built yet
since I threw in some other broken changes at the same time, which are
probably fixed by now for the next build Dave does.
I made the bits that
I propose we change the release format for snapshot kernels.
Now we get e.g.:
kernel-2.6.23-0.89.rc2.git2.fc8
and I suggest instead:
kernel-2.6.23-0.rc2.git2.89.fc8
That is, put the spec file version number last, not first. This way, when
we forget to reset fedora_cvs_origin after a rebase,
On Thu, 2007-08-09 at 13:59 -0700, Roland McGrath wrote:
I propose we change the release format for snapshot kernels.
Now we get e.g.:
kernel-2.6.23-0.89.rc2.git2.fc8
and I suggest instead:
kernel-2.6.23-0.rc2.git2.89.fc8
That is, put the spec file version number last
On Thu, Aug 09, 2007 at 01:59:49PM -0700, Roland McGrath wrote:
I propose we change the release format for snapshot kernels.
Now we get e.g.:
kernel-2.6.23-0.89.rc2.git2.fc8
and I suggest instead:
kernel-2.6.23-0.rc2.git2.89.fc8
That is, put the spec file version
Do -debuginfo packages for variants get produced automatically?
Yes. The %kernel_variant_package macro uses %kernel_debuginfo_package (and
%kernel_devel_package). The main package (kernel) uses those two macros,
but not %kernel_variant_package. I didn't define a separate
The patch below revamps kernel.spec using macros to minimize duplication.
There is now very little boilerplate to write/update for each variant
built. It's now just a few %kernel_variant_foo macro lines for each flavor
(plus %description, which is unchanged). When the common boilerplate
details
It's non-obvious to me what %{?buildid} is, but it seems to
auto-increment.
buildid is the please set this to .me one.
fedora_build is the one to bump on commit.
___
Fedora-kernel-list mailing list
Fedora-kernel-list@redhat.com
On Tue, Jul 03, 2007 at 03:56:45PM -0300, Eduardo Habkost wrote:
On Tue, Jul 03, 2007 at 11:52:00AM -0700, Roland McGrath wrote:
It's non-obvious to me what %{?buildid} is, but it seems to
auto-increment.
buildid is the please set this to .me one.
fedora_build
What about before the first -rcN tag?
___
Fedora-kernel-list mailing list
Fedora-kernel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-kernel-list
I presume you're referring to the likes of say kernel 2.6.21-gitX, which
was post-2.6.21, but pre-2.6.22-rc1? Crap. Hadn't thought about that
case. Okay, will have to do some further twiddling to cover that case...
Yes, that's what I meant. Faking it as rc0 might be the easiest thing to
keep
What's Patch5?
___
Fedora-kernel-list mailing list
Fedora-kernel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-kernel-list
to be a mapping of
an ELF file. Including these pages in the core dump may give sufficient
identifying information to associate the original DSO and executable file
images and their debugging information with a core file in a generic way
just from its contents.
Signed-off-by: Roland McGrath [EMAIL PROTECTED
Dave disabled utrace because sched-cfs has a line that conflicts. It only
conflicts under -F1, and with default patching (-F2) utrace applies fine
after sched-cfs. This tweak to the spec file's ApplyPatch makes it easy to
make one patch use -F2 when you need it, instead of disabling a patch
There was some complaining here about problems dealing with separate
debuginfo files. In elfutils-0.128, in an f6 and fc7 update near you,
there is now eu-strip. This doesn't improve any non-elfutils tools you
were using that weren't handling separate debuginfo well, but it makes it
easy to
In FC6 kernel 2959, building now. Please test soon, I do need to get a kernel
out but really want to get this update in. If it's broken I can revert.
I haven't gotten folks to test that build yet, but already I have a few
more fixes (242694, 244162). The updated patches are on the web (all
Same goes for F-7 I guess. For devel however, it's a bit of a pain to
have to disable a dozen ApplyPatch's during the (brief) window
Really? Inserting true || { before and } after seems not much worse than
commenting out a line or two.
when I rebase, and you haven't rediffed utrace yet (if
Here I am again with those hacks to do alternate builds from the kernel
spec file. Can I commit at least the spec parts to rawhide now?
The diff is only this:
--- kernel-2.6.spec 08 Jun 2007 12:55:12 -0700 1.3213
+++ kernel-2.6.spec 08 Jun 2007 12:55:05 -0700
@@ -63,7
On Fri, Jun 08, 2007 at 12:59:26PM -0700, Roland McGrath wrote:
Here I am again with those hacks to do alternate builds from the kernel
spec file. Can I commit at least the spec parts to rawhide now?
The diff is only this:
# This patch adds a make nonint_oldconfig which
66 matches
Mail list logo
