Very Computer

by **Rusty Russel** » Thu, 05 Sep 2002 11:40:04

Frankly, I'm amazed the kernel worked for long without this.

Every linker script thinks the section is called .data.percpu.
Without this patch, every CPU ends up sharing the same "per-cpu"
variable.

This might explain the wierd per-cpu problem reports from Andrew and
Dave, and also that nagging feeling that I'm an idiot...

Rusty.
--
Anyone who quotes me in their sig is an idiot. -- Rusty Russell.

--- working-2.5.33-hotcpu-cpudown-i386/include/asm-generic/percpu.h.~1~ Wed Aug 28 09:29:50 2002

/* Separate out the type, so (int[3], foo) works. */
#ifndef MODULE
#define DEFINE_PER_CPU(type, name) \
- __attribute__((__section__(".percpu"))) __typeof__(type) name##__per_cpu
+ __attribute__((__section__(".data.percpu"))) __typeof__(type) name##__per_cpu
#endif

/* var is in discarded region: offset to particular copy we want */
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in

More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

by **Andrew Morto** » Thu, 05 Sep 2002 11:50:05

> Frankly, I'm amazed the kernel worked for long without this.

> Every linker script thinks the section is called .data.percpu.
> Without this patch, every CPU ends up sharing the same "per-cpu"
> variable.

wow. Either this was working by fluke, or Bill's softirq problem
just got solved.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in

More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

by **William Lee Irwin II** » Thu, 05 Sep 2002 12:00:05

>> Frankly, I'm amazed the kernel worked for long without this.
>> Every linker script thinks the section is called .data.percpu.
>> Without this patch, every CPU ends up sharing the same "per-cpu"
>> variable.

> wow. Either this was working by fluke, or Bill's softirq problem
> just got solved.

It's pretty easy to find out, my machines don't get past
execve("/sbin/init", argv_init, envp_init); without some kind of softirq
fix. The boot cycle is not swift though... in progress.

Cheers,
Bill
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in

More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

by **David S. Mille** » Thu, 05 Sep 2002 12:10:05

Date: Wed, 04 Sep 2002 12:35:41 +1000

This might explain the wierd per-cpu problem reports from Andrew and
Dave, and also that nagging feeling that I'm an idiot...

Verifying... no without the explicit initializers the per-cpu stuff
still ends up in the BSS with egcs-2.9X, even with your fix applied.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in

More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

by **William Lee Irwin II** » Thu, 05 Sep 2002 13:00:06

> Frankly, I'm amazed the kernel worked for long without this.
> Every linker script thinks the section is called .data.percpu.
> Without this patch, every CPU ends up sharing the same "per-cpu"
> variable.
> This might explain the wierd per-cpu problem reports from Andrew and
> Dave, and also that nagging feeling that I'm an idiot...

Hmm, 2.5.33 is doing some *really* weird crap. OTOH it doesn't appear
to be tripping the BUG() in softirq.c, and disks seem to be doing okay.
It survived 4 parallel mkfs's. I'll follow up with some kind of
bugreport on the PCI and/or starfire.c front in a separate post.

Cheers,
Bill
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in

More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

by **Rusty Russel** » Thu, 05 Sep 2002 13:30:05

> Date: Wed, 04 Sep 2002 12:35:41 +1000

> This might explain the wierd per-cpu problem reports from Andrew and
> Dave, and also that nagging feeling that I'm an idiot...

> Verifying... no without the explicit initializers the per-cpu stuff
> still ends up in the BSS with egcs-2.9X, even with your fix applied.

OK. I really hate working around wierd toolchain bugs (I use 2.95.4
here and it's fine), and adding an initializer to the macro is ugly.

If you're not going to upgrade your compiler, will you accept a gcc
patch to fix this? If so, where can I get the source to your exact
version?

Thanks,
Rusty.
--
Anyone who quotes me in their sig is an idiot. -- Rusty Russell.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in

More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

by **H. Peter Anvi** » Thu, 05 Sep 2002 14:00:07

In newsgroup: linux.dev.kernel

> > Date: Wed, 04 Sep 2002 12:35:41 +1000

> > This might explain the wierd per-cpu problem reports from Andrew and
> > Dave, and also that nagging feeling that I'm an idiot...

> > Verifying... no without the explicit initializers the per-cpu stuff
> > still ends up in the BSS with egcs-2.9X, even with your fix applied.

> OK. I really hate working around wierd toolchain bugs (I use 2.95.4
> here and it's fine), and adding an initializer to the macro is ugly.

> If you're not going to upgrade your compiler, will you accept a gcc
> patch to fix this? If so, where can I get the source to your exact
> version?

gcc puts all uninitialized variables in .bss, and it apparently can't
be overridden. This seems to be a side effect of the way gcc handles
common variables.

-hpa
--

"Unix gives you enough rope to shoot yourself in the foot."

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in

More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

by **David S. Mille** » Thu, 05 Sep 2002 14:20:04

Date: Wed, 04 Sep 2002 14:04:22 +1000

OK. I really hate working around wierd toolchain bugs (I use 2.95.4
here and it's fine), and adding an initializer to the macro is ugly.

Mine is 2.92.11

If you're not going to upgrade your compiler, will you accept a gcc
patch to fix this? If so, where can I get the source to your exact
version?

Oh, "I'm" willing to upgrade "my" compiler, it's my users
that are the problem. If you impose 3.1 or whatever, I get less
people testing on sparc64 as a result.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in

More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

by **David S. Mille** » Thu, 05 Sep 2002 14:30:07

Date: Tue, 3 Sep 2002 22:17:39 -0700 (PDT)

Well, I don't think you have to go to 3.1.x.

Yes I do, anything after our standard sparc64 (ie. egcs-2.92.11)
compiler up until 3.1.x is seriously unusable for kernel builds.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in

More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

by **Linus Torvald** » Thu, 05 Sep 2002 14:30:06

> Oh, "I'm" willing to upgrade "my" compiler, it's my users
> that are the problem. If you impose 3.1 or whatever, I get less
> people testing on sparc64 as a result.

Well, I don't think you have to go to 3.1.x.

gcc-2.96 at least seems to do all right. Apparently 2.95 does too. It's
only the truly ancient compilers that don't work.

Linus

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in

More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

by **Rusty Russel** » Thu, 05 Sep 2002 15:10:05

Quote:> If you're not going to upgrade your compiler, will you accept a gcc
> patch to fix this? If so, where can I get the source to your exact
> version?

> Oh, "I'm" willing to upgrade "my" compiler, it's my users
> that are the problem. If you impose 3.1 or whatever, I get less
> people testing on sparc64 as a result.

I understand. It's OK to*off one Sparc64 Linux user, but if you
*off both of them, you're in trouble 8)

I was actually proposing to provide a patch to an egcs version of your
choice which you could provide as kgcc to your users. But RH seem to
have taken down the SRPM for 2.92.11 (egcs64-19980921-4.src.rpm).

Rusty.
--
Anyone who quotes me in their sig is an idiot. -- Rusty Russell.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in

More majordomo info at http://www.veryComputer.com/
Please read the FAQ at http://www.veryComputer.com/

by **David S. Mille** » Thu, 05 Sep 2002 15:20:05

Date: Wed, 04 Sep 2002 16:00:35 +1000

I was actually proposing to provide a patch to an egcs version of your
choice which you could provide as kgcc to your users. But RH seem to
have taken down the SRPM for 2.92.11 (egcs64-19980921-4.src.rpm).

The last sparc64 Red Hat distribution was 6.2 And it still works
unchanged with current kernels. :-)
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in

More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

by **David S. Mille** » Thu, 05 Sep 2002 15:30:08

Actually Rusty what's the big deal, add an "initializer"
arg to the macro. It doesn't hurt anyone, it doesn't lose
any space in the kernel image, and the macro arg reminds
people to do it.

I think it's a small price to pay to keep a longer range
of compilers supported :-)
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in

More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

by **Rusty Russel** » Thu, 05 Sep 2002 16:50:06

Quote:
> Actually Rusty what's the big deal, add an "initializer"
> arg to the macro. It doesn't hurt anyone, it doesn't lose
> any space in the kernel image, and the macro arg reminds
> people to do it.

> I think it's a small price to pay to keep a longer range
> of compilers supported :-)

I disagree. They might not have a convenient (static) initializer, in
which case it's simply cruel and unusual, to work around an obscure
compiler bug.

Rusty.
--
Anyone who quotes me in their sig is an idiot. -- Rusty Russell.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in

More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

by **Thunder from the hil** » Fri, 06 Sep 2002 00:50:07

Hi,

> Oh, "I'm" willing to upgrade "my" compiler, it's my users that are the
> problem. If you impose 3.1 or whatever, I get less people testing on
> sparc64 as a result.

Oh, well. I couldn't use gcc 3.* on sparc64 for some weird reason, gcc
2.95* is unable to handle all that crap, and the egcs hackup can't handle
the current kernel code. So what?

Thunder
--
--./../...-/. -.--/---/..-/.-./..././.-../..-. .---/..-/.../- .-
--/../-./..-/-/./--..-- ../.----./.-../.-.. --./../...-/. -.--/---/..-
.- -/---/--/---/.-./.-./---/.--/.-.-.-
--./.-/-.../.-./.././.-../.-.-.-

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in

More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

Very Computer

Important per-cpu fix.

Important per-cpu fix.

Important per-cpu fix.

Important per-cpu fix.

Important per-cpu fix.

Important per-cpu fix.

Important per-cpu fix.

Important per-cpu fix.

Important per-cpu fix.

Important per-cpu fix.

Important per-cpu fix.

Important per-cpu fix.

Important per-cpu fix.

Important per-cpu fix.

Important per-cpu fix.

Important per-cpu fix.