GENERIC still failing?

GENERIC still failing?

[David Mosberger]

According to this page:

	http://www.gelato.unsw.edu.au/kerncomp/

GENERIC builds are still failing:

  gcc -Wp,-MD,fs/ext2/.balloc.o.d -nostdinc -iwithprefix include -D__KERNEL__ -Iinclude   -D__KERNEL__ -Iinclude   -Wall -Wstrict-prototypes -Wno-trigraphs -O2 -fno-strict-aliasing -fno-common -pipe  -ffixed-r13 -mfixed-rangeñ2-f15,f32-f127 -falign-functions2 -frename-registers -fomit-frame-pointer    -mconstant-gp -DKBUILD_BASENAMEºlloc -DKBUILD_MODNAME=ext2 -c -o fs/ext2/balloc.o fs/ext2/balloc.c
arch/ia64/sn/kernel/setup.c:94: error: `MAX_PHYSNODE_ID' undeclared here (not in a function)
arch/ia64/sn/kernel/setup.c:94: error: conflicting types for `physical_node_map'
include/asm/sn/sn_cpuid.h:126: error: previous declaration of `physical_node_map'

Anybody care to send me a fix for this?

	--david

Re: GENERIC still failing?

[Jesse Barnes]

On Tue, Oct 14, 2003 at 05:05:14PM -0700, David Mosberger wrote:
> According to this page:
> 
> 	http://www.gelato.unsw.edu.au/kerncomp/
> 
> GENERIC builds are still failing:
> 
>   gcc -Wp,-MD,fs/ext2/.balloc.o.d -nostdinc -iwithprefix include -D__KERNEL__ -Iinclude   -D__KERNEL__ -Iinclude   -Wall -Wstrict-prototypes -Wno-trigraphs -O2 -fno-strict-aliasing -fno-common -pipe  -ffixed-r13 -mfixed-rangeñ2-f15,f32-f127 -falign-functions2 -frename-registers -fomit-frame-pointer    -mconstant-gp -DKBUILD_BASENAMEºlloc -DKBUILD_MODNAME=ext2 -c -o fs/ext2/balloc.o fs/ext2/balloc.c
> arch/ia64/sn/kernel/setup.c:94: error: `MAX_PHYSNODE_ID' undeclared here (not in a function)
> arch/ia64/sn/kernel/setup.c:94: error: conflicting types for `physical_node_map'
> include/asm/sn/sn_cpuid.h:126: error: previous declaration of `physical_node_map'
> 
> Anybody care to send me a fix for this?

Which tree is this?  Your to-linus-2.5 tree?  Let me know and I'll fix
it.

Jesse

Re: GENERIC still failing?

[Jesse Barnes]

On Tue, Oct 14, 2003 at 05:12:17PM -0700, jbarnes wrote:
> On Tue, Oct 14, 2003 at 05:05:14PM -0700, David Mosberger wrote:
> > According to this page:
> > 
> > 	http://www.gelato.unsw.edu.au/kerncomp/
> > 
> > GENERIC builds are still failing:
> > 
> >   gcc -Wp,-MD,fs/ext2/.balloc.o.d -nostdinc -iwithprefix include -D__KERNEL__ -Iinclude   -D__KERNEL__ -Iinclude   -Wall -Wstrict-prototypes -Wno-trigraphs -O2 -fno-strict-aliasing -fno-common -pipe  -ffixed-r13 -mfixed-rangeñ2-f15,f32-f127 -falign-functions2 -frename-registers -fomit-frame-pointer    -mconstant-gp -DKBUILD_BASENAMEºlloc -DKBUILD_MODNAME=ext2 -c -o fs/ext2/balloc.o fs/ext2/balloc.c
> > arch/ia64/sn/kernel/setup.c:94: error: `MAX_PHYSNODE_ID' undeclared here (not in a function)
> > arch/ia64/sn/kernel/setup.c:94: error: conflicting types for `physical_node_map'
> > include/asm/sn/sn_cpuid.h:126: error: previous declaration of `physical_node_map'
> > 
> > Anybody care to send me a fix for this?

Looks like CONFIG_NUMA and CONFIG_DISCONTIGMEM are missing from the
config being built.  A generic kernel won't work without them.

Jesse

Re: GENERIC still failing?

[David Mosberger]

>>>>> On Tue, 14 Oct 2003 17:12:17 -0700, jbarnes@sgi.com (Jesse Barnes) said:

  Jesse> On Tue, Oct 14, 2003 at 05:05:14PM -0700, David Mosberger
  Jesse> wrote:

  >> According to this page:
  >> http://www.gelato.unsw.edu.au/kerncomp/
  >> GENERIC builds are still failing:
  >> Anybody care to send me a fix for this?

  Jesse> Which tree is this?  Your to-linus-2.5 tree?  Let me know and
  Jesse> I'll fix it.

That's for the official Linus tree.  It shouldn't matter though: Linus
recently pulled my tree, so he should have all of your fixes already.

	--david

Re: GENERIC still failing?

[David Mosberger]

>>>>> On Tue, 14 Oct 2003 17:22:05 -0700, jbarnes@sgi.com (Jesse Barnes) said:

  Jesse> Looks like CONFIG_NUMA and CONFIG_DISCONTIGMEM are missing
  Jesse> from the config being built.  A generic kernel won't work
  Jesse> without them.

Shouldn't they be forced for GENERIC, then?

	--david

Re: GENERIC still failing?

[Ian Wienand]

[-- Attachment #1: Type: text/plain, Size: 962 bytes --]

On Tue, Oct 14, 2003 at 05:22:05PM -0700, Jesse Barnes wrote:
> Looks like CONFIG_NUMA and CONFIG_DISCONTIGMEM are missing from the
> config being built.  A generic kernel won't work without them.

mea culpa, as usual. Is there some way to make it when you select
generic it always requires CONFIG_NUMA/DISCONTIGMEM?

Also, trying to look at the help text, it seems that the sub-items of
a 'choice' in Kconfig can't have individual help texts?

For example 
 
choice
	prompt "IA-64 processor type"
	---help---
	 this will show when you select help on 'IA-64 processor type'
config ITANIUM
	bool "Itanium"
	---help---
	 this text appears not to show when you select help on 'Itanium' 
	 in the choice.
endchoice

I'm not sure if this is the desired effect, but certainly some of the
help texts appear mis-placed under an option of the choice rather than
at the choice it's self (see attached for example).

-i
ianw@gelato.unsw.edu.au
http://www.gelato.unsw.edu.au

[-- Attachment #2: Kconfig.patch --]
[-- Type: text/plain, Size: 1778 bytes --]

===== arch/ia64/Kconfig 1.47 vs edited =====
--- 1.47/arch/ia64/Kconfig	Sat Oct 11 09:17:05 2003
+++ edited/arch/ia64/Kconfig	Wed Oct 15 12:07:07 2003
@@ -36,27 +36,22 @@
 choice
 	prompt "IA-64 processor type"
 	default ITANIUM
-
-config ITANIUM
-	bool "Itanium"
 	help
 	  Select your IA-64 processor type.  The default is Intel Itanium.
 	  This choice is safe for all IA-64 systems, but may not perform
 	  optimally on systems with, say, Itanium 2 or newer processors.
 
+config ITANIUM
+	bool "Itanium"
+
 config MCKINLEY
 	bool "Itanium 2"
-	help
-	  Select this to configure for an Itanium 2 (McKinley) processor.
 
 endchoice
 
 choice
 	prompt "IA-64 system type"
 	default IA64_GENERIC
-
-config IA64_GENERIC
-	bool "generic"
 	---help---
 	  This selects the system type of your hardware.  A "generic" kernel
 	  will run on any supported IA-64 system.  However, if you configure
@@ -74,7 +69,12 @@
 	  DIG-compliant  For DIG ("Developer's Interface Guide") compliant
 	  systems.
 
-	  If you don't know what to do, choose "generic".
+	  If you don't know what to do, choose "generic".  Note that
+	  "generic" also requires  you enable NUMA support and Discontiguous 
+	  memory support.
+
+config IA64_GENERIC
+	bool "generic"
 
 config IA64_DIG
 	bool "DIG-compliant"
@@ -97,9 +97,6 @@
 choice
 	prompt "Kernel page size"
 	default IA64_PAGE_SIZE_16KB
-
-config IA64_PAGE_SIZE_4KB
-	bool "4KB"
 	---help---
 	  This lets you select the page size of the kernel.  For best IA-64
 	  performance, a page size of 8KB or 16KB is recommended.  For best
@@ -114,6 +111,9 @@
 	  64KB               Requires Itanium 2 or newer processor.
 
 	  If you don't know what to do, choose 16KB.
+
+config IA64_PAGE_SIZE_4KB
+	bool "4KB"
 
 config IA64_PAGE_SIZE_8KB
 	bool "8KB"

Re: GENERIC still failing?

[Randy.Dunlap]

On Wed, 15 Oct 2003 12:15:48 +1000 Ian Wienand <ianw@gelato.unsw.edu.au> wrote:

| On Tue, Oct 14, 2003 at 05:22:05PM -0700, Jesse Barnes wrote:
| > Looks like CONFIG_NUMA and CONFIG_DISCONTIGMEM are missing from the
| > config being built.  A generic kernel won't work without them.
| 
| mea culpa, as usual. Is there some way to make it when you select
| generic it always requires CONFIG_NUMA/DISCONTIGMEM?

Yes, use "select" (see Documentation/kbuild/kconfig-language.txt).
E.g.,

config GENERIC
	bool "blah"
	select NUMA
	select DISCONTIGMEM
	---help---


| Also, trying to look at the help text, it seems that the sub-items of
| a 'choice' in Kconfig can't have individual help texts?
| 
| For example 
|  
| choice
| 	prompt "IA-64 processor type"
| 	---help---
| 	 this will show when you select help on 'IA-64 processor type'
| config ITANIUM
| 	bool "Itanium"
| 	---help---
| 	 this text appears not to show when you select help on 'Itanium' 
| 	 in the choice.
| endchoice
| 
| I'm not sure if this is the desired effect, but certainly some of the
| help texts appear mis-placed under an option of the choice rather than
| at the choice it's self (see attached for example).

--
~Randy

Re: GENERIC still failing?

[Jesse Barnes]

On Tue, Oct 14, 2003 at 07:40:44PM -0700, Randy.Dunlap wrote:
> On Wed, 15 Oct 2003 12:15:48 +1000 Ian Wienand <ianw@gelato.unsw.edu.au> wrote:
> 
> | On Tue, Oct 14, 2003 at 05:22:05PM -0700, Jesse Barnes wrote:
> | > Looks like CONFIG_NUMA and CONFIG_DISCONTIGMEM are missing from the
> | > config being built.  A generic kernel won't work without them.
> | 
> | mea culpa, as usual. Is there some way to make it when you select
> | generic it always requires CONFIG_NUMA/DISCONTIGMEM?
> 
> Yes, use "select" (see Documentation/kbuild/kconfig-language.txt).
> E.g.,
> 
> config GENERIC
> 	bool "blah"
> 	select NUMA
> 	select DISCONTIGMEM
> 	---help---

Ok, thanks.  I'll send out a patch tomorrow unless someone beats me to
it.

Jesse

Re: GENERIC still failing?

[Matthew Wilcox]

On Wed, Oct 15, 2003 at 12:15:48PM +1000, Ian Wienand wrote:
> Also, trying to look at the help text, it seems that the sub-items of
> a 'choice' in Kconfig can't have individual help texts?
> 
> For example 
>  
> choice
> 	prompt "IA-64 processor type"
> 	---help---
> 	 this will show when you select help on 'IA-64 processor type'
> config ITANIUM
> 	bool "Itanium"
> 	---help---
> 	 this text appears not to show when you select help on 'Itanium' 
> 	 in the choice.
> endchoice
> 
> I'm not sure if this is the desired effect, but certainly some of the
> help texts appear mis-placed under an option of the choice rather than
> at the choice it's self (see attached for example).

Which *config tool are you using?  make config/oldconfig/defconfig have
a bug which Roman hasn't got round to pushing upstream yet.

This whitespace-damaged diff shows what needs to be fixed:

Index: scripts//kconfig/conf.c
=================================RCS file: /var/cvs/linux-2.6/scripts/kconfig/conf.c,v
retrieving revision 1.3.2.1
retrieving revision 1.3
diff -u -p -r1.3.2.1 -r1.3
--- scripts//kconfig/conf.c     8 Oct 2003 20:38:32 -0000       1.3.2.1
+++ scripts//kconfig/conf.c     28 Sep 2003 04:06:34 -0000      1.3
@@ -175,7 +175,7 @@ int conf_string(struct menu *menu)
                        break;
                case '?':
                        /* print help */
-                       if (line[1] = 0) {
+                       if (line[1] = '\n') {
                                help = nohelp_text;
                                if (menu->sym->help)
                                        help = menu->sym->help;

-- 
"It's not Hollywood.  War is real, war is primarily not about defeat or
victory, it is about death.  I've seen thousands and thousands of dead bodies.
Do you think I want to have an academic debate on this subject?" -- Robert Fisk

Re: GENERIC still failing?

[Ian Wienand]

On Wed, Oct 15, 2003 at 12:24:30PM +0100, Matthew Wilcox wrote:
> Which *config tool are you using?  make config/oldconfig/defconfig have
> a bug which Roman hasn't got round to pushing upstream yet.
> 
> This whitespace-damaged diff shows what needs to be fixed:

Thanks but that patch didn't seem to make any difference; a make
config seems to work as expected.

I'm using menuconfig; the problems I see appear two fold.

Firstly, I would have expected that when I selected 'Help' on, say,

IA-64 system type (generic)  ---> 

I would get the help text that says something like what is actually
assocated with the IA64_GENERIC option.  This seems to be an ordering
decision in the ia64 Kconfig file.

But, as that help text is associated with IA64_GENERIC, I would have
expected as I when I was in the choice and selected help for 

 (X) generic  

I would have got that big spiel  

"This selects the system type of your hardware.  A "generic" kernel
..."

If I use make config, when I select '1?' in the IA-64 system type
choice, I receive the help text associated with it.  But with make
config, I can't see a way to get help for the choice overall.

-i
ianw@gelato.unsw.edu.au
http://www.gelato.unsw.edu.au