I get this when patch'ing in test13-pre4-ac2 (with ReiserFS and Netfilter
patches, none of which touch SMP).
patching file arch/i386/kernel/smp.c
Reversed (or previously applied) patch detected! Assume -R? [n]
Apply anyway? [n] y
Hunk #1 FAILED at 278.
Hunk #2 succeeded at 511 (offset 9 lines).
1 out of 2 hunks FAILED -- saving rejects to file arch/i386/kernel/smp.c.rej
Works fine if I reverse it and then put it back in. ?
d
> patching file arch/i386/kernel/smp.c
> Reversed (or previously applied) patch detected! Assume -R? [n]
> Apply anyway? [n] y
> Hunk #1 FAILED at 278.
> Hunk #2 succeeded at 511 (offset 9 lines).
> 1 out of 2 hunks FAILED -- saving rejects to file arch/i386/kernel/smp.c.rej
>
> Works fine if I reverse it and then put it back in. ?
Its a bug in my patch - get 13pre4ac2 ..
> > patching file arch/i386/kernel/smp.c
> > Reversed (or previously applied) patch detected! Assume -R? [n]
> > Apply anyway? [n] y
> > Hunk #1 FAILED at 278.
> > Hunk #2 succeeded at 511 (offset 9 lines).
> > 1 out of 2 hunks FAILED -- saving rejects to file arch/i386/kernel/smp.c.rej
> >
> > Works fine if I reverse it and then put it back in. ?
>
> Its a bug in my patch - get 13pre4ac2 ..
Um.
Subject: Re: test13-pre4-ac2 - part of diff fails
It's _IN_ 13-4ac2.
d
On 23-Dec-2000 Daniel Stone wrote:
>> > patching file arch/i386/kernel/smp.c
>> > Reversed (or previously applied) patch detected! Assume -R? [n]
>> > Apply anyway? [n] y
>> > Hunk #1 FAILED at 278.
>> > Hunk #2 succeeded at 511 (offset 9 lines).
>> > 1 out of 2 hunks FAILED -- saving rejects to file
>> > arch/i386/kernel/smp.c.rej
>> >
>> > Works fine if I reverse it and then put it back in. ?
>>
>> Its a bug in my patch - get 13pre4ac2 ..
>
> Um.
> Subject: Re: test13-pre4-ac2 - part of diff fails
> It's _IN_ 13-4ac2.
I applied test13-pre4-ac2 here, and it applied cleanly.
Are you applying it to a clean tree? Are your using
patch v2.5.4 ? (that's the version I have)
FWIW, I was getting smp.c patch failures (well, it said the
patch was previously applied) along with a bunch of
IPTables stuff -- that was a couple of -ac's ago.
AC1 and AC2 applied cleanly, tho AC1 wouldnt compile
uniprocessor/no-quotas unless you added a
#include <linux/smp_lock.h> to fs/ext2/balloc.c
(i.e. it left some hanging refs to lock_kernel and
unlock_kernel in fs.o, and I think there was also
one in the UDF module. It's fixed in -ac2.
--
Mark Orr
[email protected]
In some parts of the kernel code I find expression like
len = (len + ~PAGE_MASK) & PAGE_MASK ;
Whats happening to len?
~sourav
>
> On 23-Dec-2000 Daniel Stone wrote:
> >> > patching file arch/i386/kernel/smp.c
> >> > Reversed (or previously applied) patch detected! Assume -R? [n]
> >> > Apply anyway? [n] y
> >> > Hunk #1 FAILED at 278.
> >> > Hunk #2 succeeded at 511 (offset 9 lines).
> >> > 1 out of 2 hunks FAILED -- saving rejects to file
> >> > arch/i386/kernel/smp.c.rej
> >> >
> >> > Works fine if I reverse it and then put it back in. ?
> >>
> >> Its a bug in my patch - get 13pre4ac2 ..
> >
> > Um.
> > Subject: Re: test13-pre4-ac2 - part of diff fails
> > It's _IN_ 13-4ac2.
>
> I applied test13-pre4-ac2 here, and it applied cleanly.
> Are you applying it to a clean tree? Are your using
> patch v2.5.4 ? (that's the version I have)
linux-2.4.0-test12 + reiserfs + test13-pre4 + reiserfs makefile fix (only
changes fs/reiserfs/Makefile) + netfilter patch-o-matic stuff (only touches
net/ipv4/netfilter) + test13-pre4-ac2.
also seen on just linux-2.4.0-test12 + test13-pre4 + test13-pre4-ac2.
> FWIW, I was getting smp.c patch failures (well, it said the
> patch was previously applied) along with a bunch of
> IPTables stuff -- that was a couple of -ac's ago.
same here, just forgot to report it.
> AC1 and AC2 applied cleanly, tho AC1 wouldnt compile
> uniprocessor/no-quotas unless you added a
> #include <linux/smp_lock.h> to fs/ext2/balloc.c
> (i.e. it left some hanging refs to lock_kernel and
> unlock_kernel in fs.o, and I think there was also
> one in the UDF module. It's fixed in -ac2.
ac1 came out while I was asleep, and I woke up to ac2 being released.
d
Daniel Stone wrote:
>linux-2.4.0-test12 + reiserfs + test13-pre4 + reiserfs makefile fix (only
>changes fs/reiserfs/Makefile) + netfilter patch-o-matic stuff (only touches
>net/ipv4/netfilter) + test13-pre4-ac2.
I was able to patch and build 2.4.0test13pre4-ac2. I did not see the problem
with smp.c which existed with the earlier test13pre3-ac3.
[root@localhost src]# date;uname -a
Sat Dec 23 07:33:48 MST 2000
Linux localhost.localdomain 2.4.0-test13pre4-ac2 #3 Fri Dec 22 22:06:06 MST
2000 i686 unknown
1 Script started on Fri Dec 22 18:28:38 2000
2 [root@localhost linux]# patch -p1 <patch-2.4.0test13pre4-ac2
3 patching file CREDITS
[snipped]
28 patching file arch/i386/kernel/setup.c
29 patching file arch/i386/kernel/smp.c
30 patching file arch/i386/kernel/smpboot.c
I did things in this order:
tar zxvf linux-2.4.0-test12.tar.gz
patch -p0 <test13-pre4
cd linux
patch -p1 <patch-2.4.0test13pre4-ac2
Found problem with build, fixed it, submitted patch.
cd /usr/src
patch -p0 <linux-2.4.0-test12-reiserfs-3.6.23-patch
patch -p0 <reiserfs-Makefile-patch
I then built a kernel with reiserfs-3.6.23 which I'm running now.
Steven
On Sat, 23 Dec 2000, Sourav Sen wrote:
> In some parts of the kernel code I find expression like
>
> len = (len + ~PAGE_MASK) & PAGE_MASK ;
>
> Whats happening to len?
It's being aligned properly.
if you have a continuous array of objects that are each 8 bytes, you
create a mask that's FFFFFFF8, then if len=7, instead of doing an
operation on the last byte of the first thing and the first 7 bytes of the
second, the above expression will add 7, making len 14, then normalize it
to the last valid object address, 8. And if you start with a valid
address, you get that same address back.
justin
--
To summon a demon you must first know its name.