Re: Alpha compile problem solved by Andrea (pte_alloc)
> I assume you are maintaining them as separate patches anyway in order to > be able to feed them to Linus. Nope - the dependancies between them are too complex - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Alpha compile problem solved by Andrea (pte_alloc)
Hi, On Mon, Apr 30, Alan Cox wrote: > > OTOH x86 is racy and there's no workaround available at the moment. > > -ac fixes all known problems there Is there some place from where one can download all the patches in -ac kernels as separate patches, not just one monster patch (same way Andrea is doing)? I assume you are maintaining them as separate patches anyway in order to be able to feed them to Linus. > Alan -o) Hubert Mantel Goodbye, dots... /\\ _\_v - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Alpha compile problem solved by Andrea (pte_alloc)
Hi, On Mon, Apr 30, Alan Cox wrote: OTOH x86 is racy and there's no workaround available at the moment. -ac fixes all known problems there Is there some place from where one can download all the patches in -ac kernels as separate patches, not just one monster patch (same way Andrea is doing)? I assume you are maintaining them as separate patches anyway in order to be able to feed them to Linus. Alan -o) Hubert Mantel Goodbye, dots... /\\ _\_v - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Alpha compile problem solved by Andrea (pte_alloc)
I assume you are maintaining them as separate patches anyway in order to be able to feed them to Linus. Nope - the dependancies between them are too complex - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Alpha compile problem solved by Andrea (pte_alloc)
On Mon, Apr 30, 2001 at 07:07:47PM +0200, Andrea Arcangeli wrote:
> On Mon, Apr 30, 2001 at 05:56:41PM +0100, Alan Cox wrote:
> > > On alpha it's racy if you set CONFIG_ALPHA_LARGE_VMALLOC y (so don't do
> > > that as you don't need it). As long as you use only 1 entry of the pgd
> > > for the whole vmalloc space (CONFIG_ALPHA_LARGE_VMALLOC n) alpha is
> > > safe.
> >
> > Its racy for all cases on the Alpha because the exception table fixes are
> > not done.
>
> you're talking about the module races, I was only talking only about
here the fix for your module race (still untested though):
diff -urN 2.4.4/arch/alpha/mm/extable.c alpha-modrace/arch/alpha/mm/extable.c
--- 2.4.4/arch/alpha/mm/extable.c Thu Nov 16 15:37:26 2000
+++ alpha-modrace/arch/alpha/mm/extable.c Mon Apr 30 19:28:21 2001
@@ -45,20 +45,25 @@
/* There is only the kernel to search. */
ret = search_one_table(__start___ex_table, __stop___ex_table - 1,
addr - gp);
- if (ret) return ret;
#else
+ unsigned long flags;
/* The kernel is the last "module" -- no need to treat it special. */
struct module *mp;
+
+ ret = 0;
+ spin_lock_irqsave(_lock, flags);
for (mp = module_list; mp ; mp = mp->next) {
- if (!mp->ex_table_start)
+ if (!mp->ex_table_start || !(mp->flags&(MOD_RUNNING|MOD_INITIALIZING)))
continue;
ret = search_one_table(mp->ex_table_start,
mp->ex_table_end - 1, addr - mp->gp);
- if (ret) return ret;
+ if (ret)
+ break;
}
+ spin_unlock_irqrestore(_lock, flags);
#endif
- return 0;
+ return ret;
}
unsigned
For the large-vmalloc races I'd take a very lazy approch:
--- alpha-modrace/arch/alpha/config.in.~1~ Sat Apr 28 05:24:29 2001
+++ alpha-modrace/arch/alpha/config.in Mon Apr 30 19:31:24 2001
@@ -211,13 +211,15 @@
# The machine must be able to support more than 8GB physical memory
# before large vmalloc might even pretend to be an issue.
-if [ "$CONFIG_ALPHA_GENERIC" = "y" -o "$CONFIG_ALPHA_DP264" = "y" \
- -o "$CONFIG_ALPHA_WILDFIRE" = "y" -o "$CONFIG_ALPHA_TITAN" = "y" ]
-then
- bool 'Large VMALLOC support' CONFIG_ALPHA_LARGE_VMALLOC
-else
- define_bool CONFIG_ALPHA_LARGE_VMALLOC n
-fi
+#if [ "$CONFIG_ALPHA_GENERIC" = "y" -o "$CONFIG_ALPHA_DP264" = "y" \
+# -o "$CONFIG_ALPHA_WILDFIRE" = "y" -o "$CONFIG_ALPHA_TITAN" = "y" ]
+#then
+# bool 'Large VMALLOC support' CONFIG_ALPHA_LARGE_VMALLOC
+#else
+# define_bool CONFIG_ALPHA_LARGE_VMALLOC n
+#fi
+# LARGE_VMALLOC is racy, if you *really* need it then fix it first
+define_bool CONFIG_ALPHA_LARGE_VMALLOC n
source drivers/pci/Config.in
I mean: I certainly don't need it, not even on the 256G boxes, the non
LARGE_VMALLOC is simpler and _faster_ (it drops a branch from the page
fault handler fast path) and so I'd prefer to spend my time on other
things than fixing LARGE_VMALLOC races, but still the above will avoid
people to get bitten by such race until somebody fixes it. If anybody
has a rasonable example for which I may need more than 8giga of kernel
vmalloc memory then I can change my mind of course.
Andrea
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Alpha compile problem solved by Andrea (pte_alloc)
On Mon, Apr 30, 2001 at 05:56:41PM +0100, Alan Cox wrote: > > On alpha it's racy if you set CONFIG_ALPHA_LARGE_VMALLOC y (so don't do > > that as you don't need it). As long as you use only 1 entry of the pgd > > for the whole vmalloc space (CONFIG_ALPHA_LARGE_VMALLOC n) alpha is > > safe. > > Its racy for all cases on the Alpha because the exception table fixes are > not done. you're talking about the module races, I was only talking only about vmalloc lazy pgd mapping, they're different things even if they are both related to the page fault hanlder. I don't use modules on the alpha so... > > OTOH x86 is racy and there's no workaround available at the moment. > > -ac fixes all known problems there I will check that shortly, thanks. (so far all the fixes I seen floating around for such races were wrong) Andrea - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Alpha compile problem solved by Andrea (pte_alloc)
> On alpha it's racy if you set CONFIG_ALPHA_LARGE_VMALLOC y (so don't do > that as you don't need it). As long as you use only 1 entry of the pgd > for the whole vmalloc space (CONFIG_ALPHA_LARGE_VMALLOC n) alpha is > safe. Its racy for all cases on the Alpha because the exception table fixes are not done. > OTOH x86 is racy and there's no workaround available at the moment. -ac fixes all known problems there Alan - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Alpha compile problem solved by Andrea (pte_alloc)
On Sun, Apr 29, 2001 at 09:55:06PM -0600, Eric W. Biederman wrote: > Hmm. I was having problems reproducible with > CONFIG_ALPHA_LARGE_VMALLOC n. > > Enabling the large vmalloc was my work around, because the large > vmalloc whet back to the prelazy allocation code. I don't have a clue about your problems but certainly the CONFIG_ALPHA_LARGE_VMALLOC n is not racy while the CONFIG_ALPHA_LARGE_VMALLOC y is racy. > problem I had was entries failed to propagate across different tasks. With CONFIG_ALPHA_LARGE_VMALLOC n the entry is propagated before starting using the new pgd so it cannot race, there's no special page fault case for that beacuse you will never get a page fault because of an unmapped pgd entry in the vmalloc space in first place. Andrea - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Alpha compile problem solved by Andrea (pte_alloc)
On Sun, Apr 29, 2001 at 09:55:06PM -0600, Eric W. Biederman wrote: Hmm. I was having problems reproducible with CONFIG_ALPHA_LARGE_VMALLOC n. Enabling the large vmalloc was my work around, because the large vmalloc whet back to the prelazy allocation code. I don't have a clue about your problems but certainly the CONFIG_ALPHA_LARGE_VMALLOC n is not racy while the CONFIG_ALPHA_LARGE_VMALLOC y is racy. problem I had was entries failed to propagate across different tasks. With CONFIG_ALPHA_LARGE_VMALLOC n the entry is propagated before starting using the new pgd so it cannot race, there's no special page fault case for that beacuse you will never get a page fault because of an unmapped pgd entry in the vmalloc space in first place. Andrea - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Alpha compile problem solved by Andrea (pte_alloc)
On alpha it's racy if you set CONFIG_ALPHA_LARGE_VMALLOC y (so don't do that as you don't need it). As long as you use only 1 entry of the pgd for the whole vmalloc space (CONFIG_ALPHA_LARGE_VMALLOC n) alpha is safe. Its racy for all cases on the Alpha because the exception table fixes are not done. OTOH x86 is racy and there's no workaround available at the moment. -ac fixes all known problems there Alan - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Alpha compile problem solved by Andrea (pte_alloc)
On Mon, Apr 30, 2001 at 05:56:41PM +0100, Alan Cox wrote: On alpha it's racy if you set CONFIG_ALPHA_LARGE_VMALLOC y (so don't do that as you don't need it). As long as you use only 1 entry of the pgd for the whole vmalloc space (CONFIG_ALPHA_LARGE_VMALLOC n) alpha is safe. Its racy for all cases on the Alpha because the exception table fixes are not done. you're talking about the module races, I was only talking only about vmalloc lazy pgd mapping, they're different things even if they are both related to the page fault hanlder. I don't use modules on the alpha so... OTOH x86 is racy and there's no workaround available at the moment. -ac fixes all known problems there I will check that shortly, thanks. (so far all the fixes I seen floating around for such races were wrong) Andrea - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Alpha compile problem solved by Andrea (pte_alloc)
On Mon, Apr 30, 2001 at 07:07:47PM +0200, Andrea Arcangeli wrote:
On Mon, Apr 30, 2001 at 05:56:41PM +0100, Alan Cox wrote:
On alpha it's racy if you set CONFIG_ALPHA_LARGE_VMALLOC y (so don't do
that as you don't need it). As long as you use only 1 entry of the pgd
for the whole vmalloc space (CONFIG_ALPHA_LARGE_VMALLOC n) alpha is
safe.
Its racy for all cases on the Alpha because the exception table fixes are
not done.
you're talking about the module races, I was only talking only about
here the fix for your module race (still untested though):
diff -urN 2.4.4/arch/alpha/mm/extable.c alpha-modrace/arch/alpha/mm/extable.c
--- 2.4.4/arch/alpha/mm/extable.c Thu Nov 16 15:37:26 2000
+++ alpha-modrace/arch/alpha/mm/extable.c Mon Apr 30 19:28:21 2001
@@ -45,20 +45,25 @@
/* There is only the kernel to search. */
ret = search_one_table(__start___ex_table, __stop___ex_table - 1,
addr - gp);
- if (ret) return ret;
#else
+ unsigned long flags;
/* The kernel is the last module -- no need to treat it special. */
struct module *mp;
+
+ ret = 0;
+ spin_lock_irqsave(modlist_lock, flags);
for (mp = module_list; mp ; mp = mp-next) {
- if (!mp-ex_table_start)
+ if (!mp-ex_table_start || !(mp-flags(MOD_RUNNING|MOD_INITIALIZING)))
continue;
ret = search_one_table(mp-ex_table_start,
mp-ex_table_end - 1, addr - mp-gp);
- if (ret) return ret;
+ if (ret)
+ break;
}
+ spin_unlock_irqrestore(modlist_lock, flags);
#endif
- return 0;
+ return ret;
}
unsigned
For the large-vmalloc races I'd take a very lazy approch:
--- alpha-modrace/arch/alpha/config.in.~1~ Sat Apr 28 05:24:29 2001
+++ alpha-modrace/arch/alpha/config.in Mon Apr 30 19:31:24 2001
@@ -211,13 +211,15 @@
# The machine must be able to support more than 8GB physical memory
# before large vmalloc might even pretend to be an issue.
-if [ $CONFIG_ALPHA_GENERIC = y -o $CONFIG_ALPHA_DP264 = y \
- -o $CONFIG_ALPHA_WILDFIRE = y -o $CONFIG_ALPHA_TITAN = y ]
-then
- bool 'Large VMALLOC support' CONFIG_ALPHA_LARGE_VMALLOC
-else
- define_bool CONFIG_ALPHA_LARGE_VMALLOC n
-fi
+#if [ $CONFIG_ALPHA_GENERIC = y -o $CONFIG_ALPHA_DP264 = y \
+# -o $CONFIG_ALPHA_WILDFIRE = y -o $CONFIG_ALPHA_TITAN = y ]
+#then
+# bool 'Large VMALLOC support' CONFIG_ALPHA_LARGE_VMALLOC
+#else
+# define_bool CONFIG_ALPHA_LARGE_VMALLOC n
+#fi
+# LARGE_VMALLOC is racy, if you *really* need it then fix it first
+define_bool CONFIG_ALPHA_LARGE_VMALLOC n
source drivers/pci/Config.in
I mean: I certainly don't need it, not even on the 256G boxes, the non
LARGE_VMALLOC is simpler and _faster_ (it drops a branch from the page
fault handler fast path) and so I'd prefer to spend my time on other
things than fixing LARGE_VMALLOC races, but still the above will avoid
people to get bitten by such race until somebody fixes it. If anybody
has a rasonable example for which I may need more than 8giga of kernel
vmalloc memory then I can change my mind of course.
Andrea
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Alpha compile problem solved by Andrea (pte_alloc)
Andrea Arcangeli <[EMAIL PROTECTED]> writes: > On Sun, Apr 29, 2001 at 05:27:10PM -0600, Eric W. Biederman wrote: > > > > Do you know if anyone has fixed the lazy vmalloc code? I know of > > as of early 2.4 it was broken on alpha. At the time I noticed it I didn't > > have time to persue it, but before I forget to even put in a bug > > report I thought I'd ask if you know anything about it? > > On alpha it's racy if you set CONFIG_ALPHA_LARGE_VMALLOC y (so don't do > that as you don't need it). As long as you use only 1 entry of the pgd > for the whole vmalloc space (CONFIG_ALPHA_LARGE_VMALLOC n) alpha is > safe. Hmm. I was having problems reproducible with CONFIG_ALPHA_LARGE_VMALLOC n. Enabling the large vmalloc was my work around, because the large vmalloc whet back to the prelazy allocation code. I was getting repeatable problems inside of an mtd driver. The problem I had was entries failed to propagate across different tasks. I think it was something like the first pgd was lazily allocated and not propagated. I don't have a SRM on my 264 alpha so alpha (for reference on which code paths were followed. > > OTOH x86 is racy and there's no workaround available at the moment. GH Well racy is easier to work with than just plain non-functional. Eric - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Alpha compile problem solved by Andrea (pte_alloc)
On Sun, Apr 29, 2001 at 05:27:10PM -0600, Eric W. Biederman wrote: > > Do you know if anyone has fixed the lazy vmalloc code? I know of > as of early 2.4 it was broken on alpha. At the time I noticed it I didn't > have time to persue it, but before I forget to even put in a bug > report I thought I'd ask if you know anything about it? On alpha it's racy if you set CONFIG_ALPHA_LARGE_VMALLOC y (so don't do that as you don't need it). As long as you use only 1 entry of the pgd for the whole vmalloc space (CONFIG_ALPHA_LARGE_VMALLOC n) alpha is safe. OTOH x86 is racy and there's no workaround available at the moment. Andrea - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Alpha compile problem solved by Andrea (pte_alloc)
Do you know if anyone has fixed the lazy vmalloc code? I know of as of early 2.4 it was broken on alpha. At the time I noticed it I didn't have time to persue it, but before I forget to even put in a bug report I thought I'd ask if you know anything about it? Eric - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Alpha compile problem solved by Andrea (pte_alloc)
Do you know if anyone has fixed the lazy vmalloc code? I know of as of early 2.4 it was broken on alpha. At the time I noticed it I didn't have time to persue it, but before I forget to even put in a bug report I thought I'd ask if you know anything about it? Eric - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Alpha compile problem solved by Andrea (pte_alloc)
On Sun, Apr 29, 2001 at 05:27:10PM -0600, Eric W. Biederman wrote: Do you know if anyone has fixed the lazy vmalloc code? I know of as of early 2.4 it was broken on alpha. At the time I noticed it I didn't have time to persue it, but before I forget to even put in a bug report I thought I'd ask if you know anything about it? On alpha it's racy if you set CONFIG_ALPHA_LARGE_VMALLOC y (so don't do that as you don't need it). As long as you use only 1 entry of the pgd for the whole vmalloc space (CONFIG_ALPHA_LARGE_VMALLOC n) alpha is safe. OTOH x86 is racy and there's no workaround available at the moment. Andrea - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Alpha compile problem solved by Andrea (pte_alloc)
Andrea Arcangeli [EMAIL PROTECTED] writes: On Sun, Apr 29, 2001 at 05:27:10PM -0600, Eric W. Biederman wrote: Do you know if anyone has fixed the lazy vmalloc code? I know of as of early 2.4 it was broken on alpha. At the time I noticed it I didn't have time to persue it, but before I forget to even put in a bug report I thought I'd ask if you know anything about it? On alpha it's racy if you set CONFIG_ALPHA_LARGE_VMALLOC y (so don't do that as you don't need it). As long as you use only 1 entry of the pgd for the whole vmalloc space (CONFIG_ALPHA_LARGE_VMALLOC n) alpha is safe. Hmm. I was having problems reproducible with CONFIG_ALPHA_LARGE_VMALLOC n. Enabling the large vmalloc was my work around, because the large vmalloc whet back to the prelazy allocation code. I was getting repeatable problems inside of an mtd driver. The problem I had was entries failed to propagate across different tasks. I think it was something like the first pgd was lazily allocated and not propagated. I don't have a SRM on my 264 alpha so alpha (for reference on which code paths were followed. OTOH x86 is racy and there's no workaround available at the moment. GH Well racy is easier to work with than just plain non-functional. Eric - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Alpha compile problem solved by Andrea (pte_alloc)
From: "Andrea Arcangeli" <[EMAIL PROTECTED]> [snip] > > Is there any other patches you recommend me to apply to my kernel? > > specifically for the alpha (but of course ok for x86 kernels too) in > order against pre7: > > ftp://ftp.us.kernel.org/pub/linux/kernel/people/andrea/kernels/v2.4/2.4.4pre 7aa1/00_alpha-numa-6 > ftp://ftp.us.kernel.org/pub/linux/kernel/people/andrea/kernels/v2.4/2.4.4pre 7aa1/00_numa-sched-5 > ftp://ftp.us.kernel.org/pub/linux/kernel/people/andrea/kernels/v2.4/2.4.4pre 7aa1/00_alpha-tlb-page-sym-1 > ftp://ftp.us.kernel.org/pub/linux/kernel/people/andrea/kernels/v2.4/2.4.4pre 7aa1/00_softirq-SMP-fixes-2 > ftp://ftp.us.kernel.org/pub/linux/kernel/people/andrea/kernels/v2.4/2.4.4pre 7aa1/00_rwsem-10 > > Andrea > Thanks... Will apply them.. Magnus - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Alpha compile problem solved by Andrea (pte_alloc)
On Fri, Apr 27, 2001 at 05:34:01AM +0200, Magnus Naeslund(f) wrote: > Hello yesterday i installed redhat6.2 on our little alpha server over here. > It's an Ruffian EV56 system, and a hand upgraded redhat to be able to cope > with 2.4. > > I got an compile error that told me that pte_alloc was declared wrong in > some files.. > Then in the back of my mind i figured that Andrea does a lot of alpha work, > so i grepped after pte_alloc in his patches. > > I found: > ftp://ftp.kernel.org/pub/linux/kernel/people/andrea/patches/v2.4/2.4.3/alpha > -numa-2 > > Now my kernel compiled, and it works great. (Thanks Andrea :)) > Just a little gotcha if anyone gets this problem (now it's in the mail > archives, where i didnt find it). > > Andrea: > Is that patch harmless, or is it experimental? The patch is ready for production. I just submitted it two times to Linus but no luck so far. However alternate patches are been merged in Linus's tree recently and they fix the compile problems at least. > Is there any other patches you recommend me to apply to my kernel? specifically for the alpha (but of course ok for x86 kernels too) in order against pre7: ftp://ftp.us.kernel.org/pub/linux/kernel/people/andrea/kernels/v2.4/2.4.4pre7aa1/00_alpha-numa-6 ftp://ftp.us.kernel.org/pub/linux/kernel/people/andrea/kernels/v2.4/2.4.4pre7aa1/00_numa-sched-5 ftp://ftp.us.kernel.org/pub/linux/kernel/people/andrea/kernels/v2.4/2.4.4pre7aa1/00_alpha-tlb-page-sym-1 ftp://ftp.us.kernel.org/pub/linux/kernel/people/andrea/kernels/v2.4/2.4.4pre7aa1/00_softirq-SMP-fixes-2 ftp://ftp.us.kernel.org/pub/linux/kernel/people/andrea/kernels/v2.4/2.4.4pre7aa1/00_rwsem-10 Andrea - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Alpha compile problem solved by Andrea (pte_alloc)
On Fri, Apr 27, 2001 at 05:34:01AM +0200, Magnus Naeslund(f) wrote: Hello yesterday i installed redhat6.2 on our little alpha server over here. It's an Ruffian EV56 system, and a hand upgraded redhat to be able to cope with 2.4. I got an compile error that told me that pte_alloc was declared wrong in some files.. Then in the back of my mind i figured that Andrea does a lot of alpha work, so i grepped after pte_alloc in his patches. I found: ftp://ftp.kernel.org/pub/linux/kernel/people/andrea/patches/v2.4/2.4.3/alpha -numa-2 Now my kernel compiled, and it works great. (Thanks Andrea :)) Just a little gotcha if anyone gets this problem (now it's in the mail archives, where i didnt find it). Andrea: Is that patch harmless, or is it experimental? The patch is ready for production. I just submitted it two times to Linus but no luck so far. However alternate patches are been merged in Linus's tree recently and they fix the compile problems at least. Is there any other patches you recommend me to apply to my kernel? specifically for the alpha (but of course ok for x86 kernels too) in order against pre7: ftp://ftp.us.kernel.org/pub/linux/kernel/people/andrea/kernels/v2.4/2.4.4pre7aa1/00_alpha-numa-6 ftp://ftp.us.kernel.org/pub/linux/kernel/people/andrea/kernels/v2.4/2.4.4pre7aa1/00_numa-sched-5 ftp://ftp.us.kernel.org/pub/linux/kernel/people/andrea/kernels/v2.4/2.4.4pre7aa1/00_alpha-tlb-page-sym-1 ftp://ftp.us.kernel.org/pub/linux/kernel/people/andrea/kernels/v2.4/2.4.4pre7aa1/00_softirq-SMP-fixes-2 ftp://ftp.us.kernel.org/pub/linux/kernel/people/andrea/kernels/v2.4/2.4.4pre7aa1/00_rwsem-10 Andrea - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Alpha compile problem solved by Andrea (pte_alloc)
From: Andrea Arcangeli [EMAIL PROTECTED] [snip] Is there any other patches you recommend me to apply to my kernel? specifically for the alpha (but of course ok for x86 kernels too) in order against pre7: ftp://ftp.us.kernel.org/pub/linux/kernel/people/andrea/kernels/v2.4/2.4.4pre 7aa1/00_alpha-numa-6 ftp://ftp.us.kernel.org/pub/linux/kernel/people/andrea/kernels/v2.4/2.4.4pre 7aa1/00_numa-sched-5 ftp://ftp.us.kernel.org/pub/linux/kernel/people/andrea/kernels/v2.4/2.4.4pre 7aa1/00_alpha-tlb-page-sym-1 ftp://ftp.us.kernel.org/pub/linux/kernel/people/andrea/kernels/v2.4/2.4.4pre 7aa1/00_softirq-SMP-fixes-2 ftp://ftp.us.kernel.org/pub/linux/kernel/people/andrea/kernels/v2.4/2.4.4pre 7aa1/00_rwsem-10 Andrea Thanks... Will apply them.. Magnus - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
