2.5.72 for ia64 released

2.5.72 for ia64 released

[David Mosberger]

A patch to make 2.5.72 work on ia64 is now available in the usual
place:

  ftp://ftp.kernel.org/pub/linux/kernel/ports/ia64/v2.5/
	linux-2.5.72-ia64-030619.diff.bz2

This patch Works for Me.  This particular patch was tested on rx5670
only, but slightly earlier versions worked on all zx1-based machines,
Big Sur, and HP Ski simulator.

There are four outstanding issues that I know of:

 - modules may or may not work properly (I had some problems with
   a load of tg3 hanging when the kernel daemon was invoking
   /sbin/hotplug)
 - hp-agp is currently broken because some generic AGP code once
   again thinks that all AGP bridges have to be PCI devices (which
   isn't true)
 - sigaltstack and ar.bspstore issue pointed out by Matt Chapman
 - problems with bio-level block merging forced me to turn off
   this kind of merging for now (primary suspect is sba_iommu.c)

Since I'm spread pretty thin already, I'd definitely appreciate if
someone else could look into the module loader issue.  It shouldn't be
hard to figure out what's going wrong.  I'd also appreciate help with
the hp-agp code.

We're inching ever closer to the point where 2.5 will build for ia64
out-of-the-box.  Not quite there yet, but hopefully it will only be a
matter of months (just kidding, really!).

Enjoy,

	--david

<chadt:sgi.com>:
  o ia64: early_printk for SGI SN2

David Mosberger:
  o More ppc64 bad merge fixing
  o Drop export of init_thread_union alltogether
  o Simplify the irq_desc[] patch to make it more acceptable for the main tree.
  o io.h
  o Fix weird PPC64 merge errors
  o defconfig
  o io.h
  o Kconfig
  o ia64: Simplify the script to use only $CC and $OBJDUMP.  Besides being
    simpler, this also ensure we really do test the linker which will be used
    when building the gate DSO.
  o Revert back to adjusting RPCSVC_MAXPAGES
  o Don't declare init_thread_union in sched.h if there is an architecture-
    specific task-struct-allocator.
  o ia64: Minor cleanups; fix non-SMP build
  o ia64: Two more minor cleanups for 2.5.72
  o ia64: Drop obsolete ACPI SPCR support
  o More 2.5.72 cleanup/syncing
  o ia64: Initial sync with 2.5.72
  o Merge conflicts with 2.5.72
  o ia64: Sync with 2.5.71
  o Make hp-agp.c compile again.  It's still broken, because the generic AGP
    code once again thinks all AGP bridges must be PCI devices.
  o Add back /proc/sys/kernel/cache_decay_ticks
  o Fix <linux/pci.h> so it can be used on platforms with CONFIG_PCI off
  o Fix serial HCDP and ACPI support for serial driver
  o Merge with 2.5.71
  o memory.c
  o Allow read accesses to the entire FIXMAP range.  This lets gdb see the
    instructions in the gate page (there is no security issue, because the gate
    page only contains instructions or non-security-sensitive data such as the
    ELF headers, etc.).
  o Remove include of <asm/unistd.h> now that force_successful_syscall() is
    back in ptrace.h.
  o Fix gratuitous PPC64 changes (were probably caused by a bad bk merge with
    Linus' tree).
  o Clean up tg3 driver to avoid relying on PCI-DMA implementation internals. 
    This removes code and gets rid of the (incorrect) dependence on
    PCI_DMA_BUS_IS_PHYS.
  o Adjust for force_successful_syscall_return() having moved back to ptrace.h.
  o Don't try to support uncached accesses via read()/write()
  o More small cleanups to /dev/mem driver and for stack dumping
  o Fix up drivers/char/mem.c some more
  o Clean up drivers/char/mem.c to reduce #ifdef bloat.  Make it work better on
    ia64
  o fork.c
  o Fix task creation/destruction to make it possible for the thread_info and
    the task_struct to be next to each other.
  o Add force_successful_syscall_return() to remaining platforms
  o Adjust show_trace()/show_stack() interfce to make them truly portable
  o fix TCP roundtrip time update code
  o ia64: Fix backtrace printing so it doesn't output tabs anymore
  o Fix locking comments for time interpolator routines
  o Overhaul time-interpolation support.  Platforms that do not ever wish to
    use time-interpolation should NOT define CONFIG_TIME_INTERPOLATION.
  o Undo previous pasting-operator "fix".  Code was right and pre3.4 compiler
    was (temporarily) broken.
  o Add two hooks for high-precision time-interpolation.  Based on patch by Jes
    Sorensen.
  o Small driver fixes
  o Undo timer breakage.  Makes profil() work again
  o Change last_time_offset into last_nsec_offset and make it work for real
  o Misc fixes: PCI ids and prefetch in page-table tear-down
  o Add /proc/sys/kernel/cache_decay_ticks
  o Fix off-by-one error to make NFSd work with PAGE_SIZE = 64KB
  o Add MM_VM_SIZE() support
  o Add EARLY_PRINTK support
  o Minor build fixes/enhancements
  o select() speedup
  o Various minor driver fixes
  o Support serial ports in ACPI namespace and serial consoles via HCDP
  o Toolchain bug workarounds
  o AGP fixes for ia64
  o Make ACPI work on ia64
  o Generic DRM support for platforms that cant_use_aperture
  o Add module_arch_cleanup() callback

Jesse Barnes:
  o ia64: generic kernel support for sn2
  o ia64: PCI fixes for sn2
  o ia64: hwgfs fix for sn2
  o ia64: mark_idle() fixes for sn2
  o ia64: bitshift fix

Peter Chubb:
  o Fix ps/2 mouse and keyboard on I2000

Roland McGrath:
  o make FIXMAP user page reading more portable

Tony Luck:
  o ia64: add missing __exit_p() to i460-agp.c

Re: 2.5.72 for ia64 released

[Andreas Schwab]

David Mosberger <davidm@napali.hpl.hp.com> writes:

|> A patch to make 2.5.72 work on ia64 is now available in the usual
|> place:
|> 
|>   ftp://ftp.kernel.org/pub/linux/kernel/ports/ia64/v2.5/
|> 	linux-2.5.72-ia64-030619.diff.bz2

A generic kernel does not compile.  Any idea how to fix?

  CC      arch/ia64/sn/io/sgi_io_sim.o
In file included from include/asm/nodedata.h:17,
                 from include/asm/sn/sn_cpuid.h:20,
                 from include/asm/sn/sn_sal.h:17,
                 from arch/ia64/sn/io/sgi_io_sim.c:13:
include/asm/mmzone.h:51:1: warning: "kern_addr_valid" redefined
In file included from include/asm/uaccess.h:36,
                 from include/asm/sn/sgi.h:17,
                 from arch/ia64/sn/io/sgi_io_sim.c:12:
include/asm/pgtable.h:191:1: warning: this is the location of the previous definition
In file included from include/asm/sn/sn_cpuid.h:20,
                 from include/asm/sn/sn_sal.h:17,
                 from arch/ia64/sn/io/sgi_io_sim.c:13:
include/asm/nodedata.h:27: error: `NR_NODES' undeclared here (not in a function)
include/asm/nodedata.h:28: error: `NR_BANKS' undeclared here (not in a function)
include/asm/nodedata.h:29: error: `NR_NODES' undeclared here (not in a function)
include/asm/nodedata.h:30: error: `NR_BANKS' undeclared here (not in a function)
In file included from include/asm/sn/sn_cpuid.h:21,
                 from include/asm/sn/sn_sal.h:17,
                 from arch/ia64/sn/io/sgi_io_sim.c:13:
include/asm/sn/pda.h:59: error: `NR_NODES' undeclared here (not in a function)
include/asm/sn/pda.h:63: confused by earlier errors, bailing out
make[2]: *** [arch/ia64/sn/io/sgi_io_sim.o] Error 1
make[1]: *** [arch/ia64/sn/io] Error 2
make: *** [arch/ia64/sn] Error 2

Andreas.

-- 
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux AG, Deutschherrnstr. 15-19, D-90429 Nürnberg
Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: 2.5.72 for ia64 released

[Jesse Barnes]

Shoot.  Can you try compiling with the discontig patch I posted
yesterday?

Thanks,
Jesse

On Fri, Jun 20, 2003 at 01:38:05PM +0200, Andreas Schwab wrote:
> David Mosberger <davidm@napali.hpl.hp.com> writes:
> 
> |> A patch to make 2.5.72 work on ia64 is now available in the usual
> |> place:
> |> 
> |>   ftp://ftp.kernel.org/pub/linux/kernel/ports/ia64/v2.5/
> |> 	linux-2.5.72-ia64-030619.diff.bz2
> 
> A generic kernel does not compile.  Any idea how to fix?
> 
>   CC      arch/ia64/sn/io/sgi_io_sim.o
> In file included from include/asm/nodedata.h:17,
>                  from include/asm/sn/sn_cpuid.h:20,
>                  from include/asm/sn/sn_sal.h:17,
>                  from arch/ia64/sn/io/sgi_io_sim.c:13:
> include/asm/mmzone.h:51:1: warning: "kern_addr_valid" redefined
> In file included from include/asm/uaccess.h:36,
>                  from include/asm/sn/sgi.h:17,
>                  from arch/ia64/sn/io/sgi_io_sim.c:12:
> include/asm/pgtable.h:191:1: warning: this is the location of the previous definition
> In file included from include/asm/sn/sn_cpuid.h:20,
>                  from include/asm/sn/sn_sal.h:17,
>                  from arch/ia64/sn/io/sgi_io_sim.c:13:
> include/asm/nodedata.h:27: error: `NR_NODES' undeclared here (not in a function)
> include/asm/nodedata.h:28: error: `NR_BANKS' undeclared here (not in a function)
> include/asm/nodedata.h:29: error: `NR_NODES' undeclared here (not in a function)
> include/asm/nodedata.h:30: error: `NR_BANKS' undeclared here (not in a function)
> In file included from include/asm/sn/sn_cpuid.h:21,
>                  from include/asm/sn/sn_sal.h:17,
>                  from arch/ia64/sn/io/sgi_io_sim.c:13:
> include/asm/sn/pda.h:59: error: `NR_NODES' undeclared here (not in a function)
> include/asm/sn/pda.h:63: confused by earlier errors, bailing out
> make[2]: *** [arch/ia64/sn/io/sgi_io_sim.o] Error 1
> make[1]: *** [arch/ia64/sn/io] Error 2
> make: *** [arch/ia64/sn] Error 2
> 
> Andreas.
> 
> -- 
> Andreas Schwab, SuSE Labs, schwab@suse.de
> SuSE Linux AG, Deutschherrnstr. 15-19, D-90429 N?rnberg
> Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
> "And now for something completely different."
> -
> To unsubscribe from this list: send the line "unsubscribe linux-ia64" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: 2.5.72 for ia64 released

[Sam Ravnborg]

diff -Nru a/arch/ia64/lib/Makefile b/arch/ia64/lib/Makefile
--- a/arch/ia64/lib/Makefile    Thu Jun 19 14:19:14 2003
+++ b/arch/ia64/lib/Makefile    Thu Jun 19 14:19:14 2003
@@ -13,6 +13,12 @@
 lib-$(CONFIG_MCKINLEY) += copy_page_mck.o memcpy_mck.o
 lib-$(CONFIG_PERFMON)  += carta_random.o

+ifeq ($(CONFIG_MD_RAID5),m)
+       lib-y += xor.o
+else
+       lib-$(CONFIG_MD_RAID5)  += xor.o
+endif
+

No need for this ifeq ....
lib-m should work as well as lib-y.
If this is not the case then let me know - I will fix kbuild then.

lib-m is actually documented!



diff -Nru a/usr/Makefile b/usr/Makefile
....
+$(obj)/initramfs_data.S: $(obj)/initramfs_data.cpio.gz
+       echo '.section ".init.ramfs", "a"' > $@
+       od -v -An -t x1 -w8 $^ | cut -c2- | sed -e s"/ /,0x/g" -e s"/^/.byte 0x"/ >> $@

Will .incbin really replace the above magic?
I have the following patch ready - but not submitted:
[Deleted trivial changes that just removed LDFLAGS_BLOB]

# This is a BitKeeper generated patch for the following project:
# Project Name: Linux kernel tree
# This patch format is intended for GNU patch command version 2.5 or higher.
# This patch includes the following deltas:
#	           ChangeSet	1.1414  -> 1.1415 
#	   arch/ppc/Makefile	1.39    -> 1.40   
#	 arch/ppc64/Makefile	1.26    -> 1.27   
#	 arch/sparc/Makefile	1.23    -> 1.24   
#	 arch/h8300/Makefile	1.1     -> 1.2    
#	  arch/s390/Makefile	1.25    -> 1.26   
#	usr/initramfs_data.scr	1.1     ->         (deleted)      
#	  arch/i386/Makefile	1.52    -> 1.53   
#	        usr/Makefile	1.6     -> 1.7    
#	 arch/alpha/Makefile	1.24    -> 1.25   
#	    arch/sh/Makefile	1.16    -> 1.17   
#	arch/m68knommu/Makefile	1.7     -> 1.8    
#	arch/x86_64/Makefile	1.27    -> 1.28   
#	arch/parisc/Makefile	1.20    -> 1.21   
#	  arch/m68k/Makefile	1.11    -> 1.12   
#	arch/sparc64/Makefile	1.26    -> 1.27   
#	  arch/v850/Makefile	1.6     -> 1.7    
#	               (new)	        -> 1.1     usr/initramfs_data.S
#
# The following is the BitKeeper ChangeSet Log
# --------------------------------------------
# 03/06/18	sam@mars.ravnborg.org	1.1415
# usr: Create objectfile for usr filesystem using .incbin
# 
# Patch originally by HJ Lu.
# 
# The filesystem was previously embedded in a .o file using ld.
# Embedding the filesystem using ld broke as a result ia64 and maybe more
# architectures.
# 
# The better way to do this is to use the .incbin feature, as already
# used for vsyscall for i386. .incbin has the advantage that ELH header
# is correct, as required by ia64 - and maybe other archs.
# This change will break architectures relying on binutils older than
# 2.11.90.0.23 released on 2001-07-14.
# Most notably arm will break in some configurations due to this.
# The rationale behing introducing .incbin is that ia64 needs this change
# and the .incbin feature has been present in binutils for a number
# of years now.
# arm will thus have to catch up with binutils - or patch usr/Makefile
# to stay compatible with the 2.5 kernel.
# 
# The definition of LDFLAGS_BLOB removed for all architectures - it was 
# obsoleted by this change.
# Except for arm - that may require it due to the tool compatibility issue.
# --------------------------------------------
#
diff -Nru a/usr/Makefile b/usr/Makefile
--- a/usr/Makefile	Fri Jun 20 19:45:26 2003
+++ b/usr/Makefile	Fri Jun 20 19:45:26 2003
@@ -5,11 +5,10 @@
 
 clean-files := initramfs_data.cpio.gz
 
-LDFLAGS_initramfs_data.o := $(LDFLAGS_BLOB) -r -T
-
-$(obj)/initramfs_data.o: $(src)/initramfs_data.scr \
-			 $(obj)/initramfs_data.cpio.gz FORCE
-	$(call if_changed,ld)
+# initramfs_data.o contains the initramfs_data.cpio.gz image.
+# The image is included using .incbin, a dependency which is not
+# tracked automatically.
+$(obj)/initramfs_data.o: $(obj)/initramfs_data.cpio.gz FORCE
 
 # initramfs-y are the programs which will be copied into the CPIO
 # archive. Currently, the filenames are hardcoded in gen_init_cpio,
diff -Nru a/usr/initramfs_data.S b/usr/initramfs_data.S
--- /dev/null	Wed Dec 31 16:00:00 1969
+++ b/usr/initramfs_data.S	Fri Jun 20 19:45:26 2003
@@ -0,0 +1,30 @@
+/*
+  initramfs_data includes the compressed binary that is the
+  filesystem used for early user space.
+  Note: Older versions of "as" (prior to binutils 2.11.90.0.23
+  released on 2001-07-14) dit not support .incbin.
+  If you are forced to use older binutils than that then the
+  following trick can be applied to create the resulting binary:
+
+
+  ld -m elf_i386  --format binary --oformat elf32-i386 -r \
+  -T initramfs_data.scr initramfs_data.cpio.gz -o initramfs_data.o
+   ld -m elf_i386  -r -o built-in.o initramfs_data.o
+
+  initramfs_data.scr looks like this:
+SECTIONS
+{
+       .init.ramfs : { *(.data) }
+}
+
+  The above example is for i386 - the parameters vary from architectures.
+  Eventually look up LDFLAGS_BLOB in an older version of the
+  arch/$(ARCH)/Makefile to see the flags used before .incbin was introduced.
+
+  Using .incbin has the advantage over ld that the correct flags are set
+  in the ELF header, as required by certain architectures.
+*/
+
+.section .init.ramfs,"a"
+.incbin "usr/initramfs_data.cpio.gz"
+
diff -Nru a/usr/initramfs_data.scr b/usr/initramfs_data.scr
--- a/usr/initramfs_data.scr	Fri Jun 20 19:45:26 2003
+++ /dev/null	Wed Dec 31 16:00:00 1969
@@ -1,4 +0,0 @@
-SECTIONS
-{
-	.init.ramfs : { *(.data) }
-}

Re: 2.5.72 for ia64 released

[David Mosberger]

>>>>> On Fri, 20 Jun 2003 19:47:44 +0200, Sam Ravnborg <sam@ravnborg.org> said:

  Sam> diff -Nru a/arch/ia64/lib/Makefile b/arch/ia64/lib/Makefile
  Sam> --- a/arch/ia64/lib/Makefile    Thu Jun 19 14:19:14 2003
  Sam> +++ b/arch/ia64/lib/Makefile    Thu Jun 19 14:19:14 2003
  Sam> @@ -13,6 +13,12 @@
  Sam> lib-$(CONFIG_MCKINLEY) += copy_page_mck.o memcpy_mck.o
  Sam> lib-$(CONFIG_PERFMON)  += carta_random.o

  Sam> +ifeq ($(CONFIG_MD_RAID5),m)
  Sam> +       lib-y += xor.o
  Sam> +else
  Sam> +       lib-$(CONFIG_MD_RAID5)  += xor.o
  Sam> +endif

  Sam> No need for this ifeq ....
  Sam> lib-m should work as well as lib-y.
  Sam> If this is not the case then let me know - I will fix kbuild then.

  Sam> lib-m is actually documented!

I don't use RAID5 myself.  Can someone else test this and send me a
patch if it works?


  Sam> diff -Nru a/usr/Makefile b/usr/Makefile
  Sam> ....
  Sam> +$(obj)/initramfs_data.S: $(obj)/initramfs_data.cpio.gz
  Sam> +       echo '.section ".init.ramfs", "a"' > $@
  Sam> +       od -v -An -t x1 -w8 $^ | cut -c2- | sed -e s"/ /,0x/g" -e s"/^/.byte 0x"/ >> $@

  Sam> Will .incbin really replace the above magic?

It should.  The ony thing the above commands do is to convert
initramfs_data.cpio.gz into a hexdump which can then be assembled.

	--david

Re: 2.5.72 for ia64 released

[Jesse Barnes]

It doesn't look like my discontig patch will fix it.  I'll try to send
out a patch to fix arch/ia64/Kconfig and drivers/acpi/Kconfig shortly...

DISCONTIGMEM, NUMA, and ACPI_NUMA have to be turned on automatically for
generic kernels...

Jesse

On Fri, Jun 20, 2003 at 10:11:50AM -0700, Jesse Barnes wrote:
> Shoot.  Can you try compiling with the discontig patch I posted
> yesterday?
> 
> Thanks,
> Jesse
> 
> On Fri, Jun 20, 2003 at 01:38:05PM +0200, Andreas Schwab wrote:
> > David Mosberger <davidm@napali.hpl.hp.com> writes:
> > 
> > |> A patch to make 2.5.72 work on ia64 is now available in the usual
> > |> place:
> > |> 
> > |>   ftp://ftp.kernel.org/pub/linux/kernel/ports/ia64/v2.5/
> > |> 	linux-2.5.72-ia64-030619.diff.bz2
> > 
> > A generic kernel does not compile.  Any idea how to fix?
> > 
> >   CC      arch/ia64/sn/io/sgi_io_sim.o
> > In file included from include/asm/nodedata.h:17,
> >                  from include/asm/sn/sn_cpuid.h:20,
> >                  from include/asm/sn/sn_sal.h:17,
> >                  from arch/ia64/sn/io/sgi_io_sim.c:13:
> > include/asm/mmzone.h:51:1: warning: "kern_addr_valid" redefined
> > In file included from include/asm/uaccess.h:36,
> >                  from include/asm/sn/sgi.h:17,
> >                  from arch/ia64/sn/io/sgi_io_sim.c:12:
> > include/asm/pgtable.h:191:1: warning: this is the location of the previous definition
> > In file included from include/asm/sn/sn_cpuid.h:20,
> >                  from include/asm/sn/sn_sal.h:17,
> >                  from arch/ia64/sn/io/sgi_io_sim.c:13:
> > include/asm/nodedata.h:27: error: `NR_NODES' undeclared here (not in a function)
> > include/asm/nodedata.h:28: error: `NR_BANKS' undeclared here (not in a function)
> > include/asm/nodedata.h:29: error: `NR_NODES' undeclared here (not in a function)
> > include/asm/nodedata.h:30: error: `NR_BANKS' undeclared here (not in a function)
> > In file included from include/asm/sn/sn_cpuid.h:21,
> >                  from include/asm/sn/sn_sal.h:17,
> >                  from arch/ia64/sn/io/sgi_io_sim.c:13:
> > include/asm/sn/pda.h:59: error: `NR_NODES' undeclared here (not in a function)
> > include/asm/sn/pda.h:63: confused by earlier errors, bailing out
> > make[2]: *** [arch/ia64/sn/io/sgi_io_sim.o] Error 1
> > make[1]: *** [arch/ia64/sn/io] Error 2
> > make: *** [arch/ia64/sn] Error 2
> > 
> > Andreas.
> > 
> > -- 
> > Andreas Schwab, SuSE Labs, schwab@suse.de
> > SuSE Linux AG, Deutschherrnstr. 15-19, D-90429 N?rnberg
> > Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
> > "And now for something completely different."
> > -
> > To unsubscribe from this list: send the line "unsubscribe linux-ia64" in
> > the body of a message to majordomo@vger.kernel.org
> > More majordomo info at  http://vger.kernel.org/majordomo-info.html
> -
> To unsubscribe from this list: send the line "unsubscribe linux-ia64" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: 2.5.72 for ia64 released

[David Mosberger]

>>>>> On Fri, 20 Jun 2003 11:35:31 -0700, jbarnes@sgi.com (Jesse Barnes) said:

  Jesse> DISCONTIGMEM, NUMA, and ACPI_NUMA have to be turned on
  Jesse> automatically for generic kernels...

I thought the DISCONTIGMEM support is making assumptions about the
physical memory layout.  If this is still true, DISCONTIGMEM and
GENERIC cannot go together.

I suspect it would be more preferable if you could make it possible
for a non-NUMA kernel to boot on your machine.

	--david

Re: 2.5.72 for ia64 released

[Jesse Barnes]

On Fri, Jun 20, 2003 at 11:41:55AM -0700, David Mosberger wrote:
> >>>>> On Fri, 20 Jun 2003 11:35:31 -0700, jbarnes@sgi.com (Jesse Barnes) said:
> 
>   Jesse> DISCONTIGMEM, NUMA, and ACPI_NUMA have to be turned on
>   Jesse> automatically for generic kernels...
> 
> I thought the DISCONTIGMEM support is making assumptions about the
> physical memory layout.  If this is still true, DISCONTIGMEM and
> GENERIC cannot go together.

No, the discontig patch I posted earlier should allow this.  We've
tested it quite a bit in 2.4.

> I suspect it would be more preferable if you could make it possible
> for a non-NUMA kernel to boot on your machine.

That might be nice, but I'd rather have CONFIG_GENERIC turn on
CONFIG_NUMA.  It shouldn't get in the way of non-NUMA machines...

Thanks,
Jesse

Re: 2.5.72 for ia64 released

[David Mosberger]

>>>>> On Fri, 20 Jun 2003 11:45:19 -0700, jbarnes@sgi.com (Jesse Barnes) said:

  >> I thought the DISCONTIGMEM support is making assumptions about the
  >> physical memory layout.  If this is still true, DISCONTIGMEM and
  >> GENERIC cannot go together.

  Jesse> No, the discontig patch I posted earlier should allow this.  We've
  Jesse> tested it quite a bit in 2.4.

I'm not questioning whether it works on SGI, what I'm asking is
whether it will work on _all_ possible NUMA architectures, or just on
SN2.

  >> I suspect it would be more preferable if you could make it possible
  >> for a non-NUMA kernel to boot on your machine.

  Jesse> That might be nice, but I'd rather have CONFIG_GENERIC turn on
  Jesse> CONFIG_NUMA.  It shouldn't get in the way of non-NUMA machines...

What I worry about is that some distributions may end up shipping
GENERIC kernels, with no easy way to build an optimized kernel.  It's
reasonable to expect highend customers to build their own kernels, but
I don't think that's quite as reasonable to expect the same from
someone who buys a workstation.

	--david

Re: 2.5.72 for ia64 released

[Jesse Barnes]

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

This one Works For Me (tm).  Does it look ok?

Thanks,
Jesse

On Fri, Jun 20, 2003 at 11:45:19AM -0700, Jesse Barnes wrote:
> On Fri, Jun 20, 2003 at 11:41:55AM -0700, David Mosberger wrote:
> > >>>>> On Fri, 20 Jun 2003 11:35:31 -0700, jbarnes@sgi.com (Jesse Barnes) said:
> > 
> >   Jesse> DISCONTIGMEM, NUMA, and ACPI_NUMA have to be turned on
> >   Jesse> automatically for generic kernels...
> > 
> > I thought the DISCONTIGMEM support is making assumptions about the
> > physical memory layout.  If this is still true, DISCONTIGMEM and
> > GENERIC cannot go together.
> 
> No, the discontig patch I posted earlier should allow this.  We've
> tested it quite a bit in 2.4.
> 
> > I suspect it would be more preferable if you could make it possible
> > for a non-NUMA kernel to boot on your machine.
> 
> That might be nice, but I'd rather have CONFIG_GENERIC turn on
> CONFIG_NUMA.  It shouldn't get in the way of non-NUMA machines...
> 
> Thanks,
> Jesse
> -
> To unsubscribe from this list: send the line "unsubscribe linux-ia64" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

[-- Attachment #2: ia64-kconfig-2.5.72-ia64-bk.patch --]
[-- Type: text/plain, Size: 3380 bytes --]

===== drivers/acpi/Kconfig 1.9 vs edited =====
--- 1.9/drivers/acpi/Kconfig	Tue Mar 25 13:32:08 2003
+++ edited/drivers/acpi/Kconfig	Fri Jun 20 11:34:15 2003
@@ -133,7 +133,7 @@
 
 config ACPI_NUMA
 	bool "NUMA support" if NUMA && (IA64 && !IA64_HP_SIM || X86 && ACPI && !ACPI_HT_ONLY && !X86_64)
-	default y if IA64 && IA64_SGI_SN
+	default y if IA64_GENERIC || IA64_SGI_SN2
 
 config ACPI_TOSHIBA
 	tristate "Toshiba Laptop Extras"
===== arch/ia64/Kconfig 1.33 vs edited =====
--- 1.33/arch/ia64/Kconfig	Thu Jun 19 00:54:35 2003
+++ edited/arch/ia64/Kconfig	Fri Jun 20 11:41:52 2003
@@ -210,8 +210,8 @@
 	  system with an A0 or A1 stepping CPU.
 
 config NUMA
-	bool "Enable NUMA support" if IA64_GENERIC || IA64_DIG || IA64_HP_ZX1
-	default y if IA64_SGI_SN2
+	bool
+	default y if IA64_SGI_SN2 || IA64_GENERIC
 	help
 	  Say Y to compile the kernel to support NUMA (Non-Uniform Memory
 	  Access).  This option is for configuring high-end multiprocessor
@@ -235,8 +235,7 @@
 
 config DISCONTIGMEM
 	bool
-	depends on IA64_SGI_SN2 || (IA64_GENERIC || IA64_DIG || IA64_HP_ZX1) && NUMA
-	default y
+	default y if IA64_SGI_SN2 || IA64_GENERIC
 	help
 	  Say Y to support efficient handling of discontiguous physical memory,
 	  for architectures which are either NUMA (Non-Uniform Memory Access)
@@ -245,8 +244,7 @@
 
 config VIRTUAL_MEM_MAP
 	bool "Enable Virtual Mem Map"
-	depends on !NUMA
-	default y if IA64_GENERIC || IA64_DIG || IA64_HP_ZX1
+	default y if !IA64_HP_SIM
 	help
 	  Say Y to compile the kernel with support for a virtual mem map.
 	  This is an alternate method of supporting large holes in the
@@ -259,8 +257,8 @@
 	  are unsure, say Y.
 
 config IA64_MCA
-	bool "Enable IA-64 Machine Check Abort" if IA64_GENERIC || IA64_DIG || IA64_HP_ZX1
-	default y if IA64_SGI_SN2
+	bool "Enable IA-64 Machine Check Abort"
+	default y if !IA64_HP_SIM
 	help
 	  Say Y here to enable machine check support for IA-64.  If you're
 	  unsure, answer Y.
@@ -292,43 +290,12 @@
 	depends on IA64_GENERIC || IA64_DIG || IA64_HP_ZX1 || IA64_SGI_SN2
 	default y
 
-config IA64_SGI_SN_DEBUG
-	bool "Enable extra debugging code"
-	depends on IA64_SGI_SN2
-	help
-	  Turns on extra debugging code in the SGI SN (Scalable NUMA) platform
-	  for IA-64.  Unless you are debugging problems on an SGI SN IA-64 box,
-	  say N.
-
 config IA64_SGI_SN_SIM
 	bool "Enable SGI Medusa Simulator Support"
 	depends on IA64_SGI_SN2
 	help
 	  If you are compiling a kernel that will run under SGI's IA-64
 	  simulator (Medusa) then say Y, otherwise say N.
-
-config IA64_SGI_AUTOTEST
-	bool "Enable autotest (llsc). Option to run cache test instead of booting"
-	depends on IA64_SGI_SN2
-	help
-	  Build a kernel used for hardware validation. If you include the
-	  keyword "autotest" on the boot command line, the kernel does NOT boot.
-	  Instead, it starts all cpus and runs cache coherency tests instead.
-
-	  If unsure, say N.
-
-config SERIAL_SGI_L1_PROTOCOL
-	bool "Enable protocol mode for the L1 console"
-	depends on IA64_SGI_SN2
-	help
-	  Uses protocol mode instead of raw mode for the level 1 console on the
-	  SGI SN (Scalable NUMA) platform for IA-64.  If you are compiling for
-	  an SGI SN box then Y is the recommended value, otherwise say N.
-
-config PERCPU_IRQ
-	bool
-	depends on IA64_SGI_SN2
-	default y
 
 # On IA-64, we always want an ELF /proc/kcore.
 config KCORE_ELF

Re: 2.5.72 for ia64 released

[Jesse Barnes]

On Fri, Jun 20, 2003 at 11:49:33AM -0700, David Mosberger wrote:
> >>>>> On Fri, 20 Jun 2003 11:45:19 -0700, jbarnes@sgi.com (Jesse Barnes) said:
> 
>   >> I thought the DISCONTIGMEM support is making assumptions about the
>   >> physical memory layout.  If this is still true, DISCONTIGMEM and
>   >> GENERIC cannot go together.
> 
>   Jesse> No, the discontig patch I posted earlier should allow this.  We've
>   Jesse> tested it quite a bit in 2.4.
> 
> I'm not questioning whether it works on SGI, what I'm asking is
> whether it will work on _all_ possible NUMA architectures, or just on
> SN2.

Yeah, that's what I meant.  Jack's patch to 2.4 has been tested on sn2,
DIG, zx1, NEC, and Bull machines, as a generic kernel for the first
three at least (don't know what NEC and Bull did for their testing).

>   >> I suspect it would be more preferable if you could make it possible
>   >> for a non-NUMA kernel to boot on your machine.
> 
>   Jesse> That might be nice, but I'd rather have CONFIG_GENERIC turn on
>   Jesse> CONFIG_NUMA.  It shouldn't get in the way of non-NUMA machines...
> 
> What I worry about is that some distributions may end up shipping
> GENERIC kernels, with no easy way to build an optimized kernel.  It's
> reasonable to expect highend customers to build their own kernels, but
> I don't think that's quite as reasonable to expect the same from
> someone who buys a workstation.

So you're worried about the performance penalty of turning on NUMA for
generic kernels?

Jesse

Re: 2.5.72 for ia64 released

[David Mosberger]

>>>>> On Fri, 20 Jun 2003 11:53:03 -0700, jbarnes@sgi.com (Jesse Barnes) said:

  Jesse> Yeah, that's what I meant.  Jack's patch to 2.4 has been
  Jesse> tested on sn2, DIG, zx1, NEC, and Bull machines, as a generic
  Jesse> kernel for the first three at least (don't know what NEC and
  Jesse> Bull did for their testing).

But which ones are NUMA with node-scattered physical memory?  sn2 for
sure.  DIG, zx1 are not, for sure.  I'm not certain about NEC or Bull.
So I'm not convinced that it works for all possible physical memory
layouts.

  Jesse> So you're worried about the performance penalty of turning on NUMA for
  Jesse> generic kernels?

Yes.  Actually, I'm concerned about size, too.  It would be good to
have an init-mem-like approach so that we can free all the code/data
for unused machvec code.

	--david

Re: 2.5.72 for ia64 released

[Jesse Barnes]

On Fri, Jun 20, 2003 at 12:02:03PM -0700, David Mosberger wrote:
> >>>>> On Fri, 20 Jun 2003 11:53:03 -0700, jbarnes@sgi.com (Jesse Barnes) said:
> 
>   Jesse> Yeah, that's what I meant.  Jack's patch to 2.4 has been
>   Jesse> tested on sn2, DIG, zx1, NEC, and Bull machines, as a generic
>   Jesse> kernel for the first three at least (don't know what NEC and
>   Jesse> Bull did for their testing).
> 
> But which ones are NUMA with node-scattered physical memory?  sn2 for

Do you mean discontiguous memory within a node?  Jack has the memory
maps for those other machines, so he might know.

>   Jesse> So you're worried about the performance penalty of turning on NUMA for
>   Jesse> generic kernels?
> 
> Yes.  Actually, I'm concerned about size, too.  It would be good to
> have an init-mem-like approach so that we can free all the code/data
> for unused machvec code.

That would be a nice thing to add, hmm...

Jesse

Re: 2.5.72 for ia64 released

[Andreas Schwab]

jbarnes@sgi.com (Jesse Barnes) writes:

|> This one Works For Me (tm).  Does it look ok?

Does it require other patches?

  CC      arch/ia64/kernel/asm-offsets.s
In file included from include/asm/processor.h:99,
                 from include/asm/thread_info.h:9,
                 from include/linux/thread_info.h:21,
                 from include/linux/spinlock.h:12,
                 from include/linux/capability.h:45,
                 from include/linux/sched.h:7,
                 from arch/ia64/kernel/asm-offsets.c:9:
include/asm/nodedata.h:27: error: `NR_NODES' undeclared here (not in a function)
include/asm/nodedata.h:28: error: `NR_BANKS' undeclared here (not in a function)
include/asm/nodedata.h:29: error: `NR_NODES' undeclared here (not in a function)
include/asm/nodedata.h:30: error: `NR_BANKS' undeclared here (not in a function)
In file included from include/linux/gfp.h:4,
                 from include/linux/slab.h:15,
                 from include/linux/percpu.h:4,
                 from include/linux/sched.h:30,
                 from arch/ia64/kernel/asm-offsets.c:9:
include/linux/mmzone.h:163: error: `NR_NODES' undeclared here (not in a function)
include/linux/mmzone.h:191: confused by earlier errors, bailing out

Andreas.

-- 
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux AG, Deutschherrnstr. 15-19, D-90429 Nürnberg
Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: 2.5.72 for ia64 released

[Jesse Barnes]

What's your .config look like?  Is CONFIG_NUMA=y?  I'm trying a fresh
build now...

Jesse

On Fri, Jun 20, 2003 at 09:44:13PM +0200, Andreas Schwab wrote:
> jbarnes@sgi.com (Jesse Barnes) writes:
> 
> |> This one Works For Me (tm).  Does it look ok?
> 
> Does it require other patches?
> 
>   CC      arch/ia64/kernel/asm-offsets.s
> In file included from include/asm/processor.h:99,
>                  from include/asm/thread_info.h:9,
>                  from include/linux/thread_info.h:21,
>                  from include/linux/spinlock.h:12,
>                  from include/linux/capability.h:45,
>                  from include/linux/sched.h:7,
>                  from arch/ia64/kernel/asm-offsets.c:9:
> include/asm/nodedata.h:27: error: `NR_NODES' undeclared here (not in a function)
> include/asm/nodedata.h:28: error: `NR_BANKS' undeclared here (not in a function)
> include/asm/nodedata.h:29: error: `NR_NODES' undeclared here (not in a function)
> include/asm/nodedata.h:30: error: `NR_BANKS' undeclared here (not in a function)
> In file included from include/linux/gfp.h:4,
>                  from include/linux/slab.h:15,
>                  from include/linux/percpu.h:4,
>                  from include/linux/sched.h:30,
>                  from arch/ia64/kernel/asm-offsets.c:9:
> include/linux/mmzone.h:163: error: `NR_NODES' undeclared here (not in a function)
> include/linux/mmzone.h:191: confused by earlier errors, bailing out
> 
> Andreas.
> 
> -- 
> Andreas Schwab, SuSE Labs, schwab@suse.de
> SuSE Linux AG, Deutschherrnstr. 15-19, D-90429 N?rnberg
> Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
> "And now for something completely different."
> -
> To unsubscribe from this list: send the line "unsubscribe linux-ia64" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: 2.5.72 for ia64 released

[Andreas Schwab]

jbarnes@sgi.com (Jesse Barnes) writes:

|> What's your .config look like?  Is CONFIG_NUMA=y?

Yes, also CONFIG_DISCONTIGMEM=y, CONFIG_VIRTUAL_MEM_MAP=y and
CONFIG_ACPI_NUMA=y.

Andreas.

-- 
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux AG, Deutschherrnstr. 15-19, D-90429 Nürnberg
Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: 2.5.72 for ia64 released

[Jesse Barnes]

On Fri, Jun 20, 2003 at 09:44:13PM +0200, Andreas Schwab wrote:
> jbarnes@sgi.com (Jesse Barnes) writes:
> 
> |> This one Works For Me (tm).  Does it look ok?
> 
> Does it require other patches?

Yes, as it turns out.  You'll need the discontig patch I posted earlier.
2.5.69 used to build for me just fine without the patch, because it had
the right stuff in mmzone.h (or at least, some earlier version had it).
Don't know where that code went...

Jesse

Re: 2.5.72 for ia64 released

[Alex Tsariounov]

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

On Fri, Jun 20, 2003 at 11:01:30AM -0700, David Mosberger wrote:
>   Sam> No need for this ifeq ....
>   Sam> lib-m should work as well as lib-y.
>   Sam> If this is not the case then let me know - I will fix kbuild then.
> 
>   Sam> lib-m is actually documented!
> 
> I don't use RAID5 myself.  Can someone else test this and send me a
> patch if it works?

The workaround was needed for 2.5.69 but it looks like it works as
it originally should on 2.5.72.  Attached is a patch that goes back
to lib-m.

Thanks,
Alex

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

diff -Naur -X dontdiff linux-2.5.72-030619/arch/ia64/lib/Makefile linux-2.5.72-030619-fix/arch/ia64/lib/Makefile
--- linux-2.5.72-030619/arch/ia64/lib/Makefile	2003-06-20 13:54:00.000000000 -0600
+++ linux-2.5.72-030619-fix/arch/ia64/lib/Makefile	2003-06-20 13:48:24.000000000 -0600
@@ -12,12 +12,7 @@
 lib-$(CONFIG_ITANIUM)	+= copy_page.o copy_user.o memcpy.o
 lib-$(CONFIG_MCKINLEY)	+= copy_page_mck.o memcpy_mck.o
 lib-$(CONFIG_PERFMON)	+= carta_random.o
-
-ifeq ($(CONFIG_MD_RAID5),m)
-	lib-y += xor.o
-else
-	lib-$(CONFIG_MD_RAID5)	+= xor.o
-endif
+lib-$(CONFIG_MD_RAID5)	+= xor.o
 
 IGNORE_FLAGS_OBJS =	__divsi3.o __udivsi3.o __modsi3.o __umodsi3.o \
 			__divdi3.o __udivdi3.o __moddi3.o __umoddi3.o

Re: 2.5.72 for ia64 released

[David Mosberger]

>>>>> On Fri, 20 Jun 2003 14:03:14 -0600, alext@fc.hp.com (Alex Tsariounov) said:

  Alex> The workaround was needed for 2.5.69 but it looks like it works as
  Alex> it originally should on 2.5.72.  Attached is a patch that goes back
  Alex> to lib-m.

The original code used obj-$(CONFIG_MD_RAID5), not lib-m, which probably
explains the problem.

I'll apply your new patch now.

Thanks,

	--david

Re: 2.5.72 for ia64 released

[Andreas Schwab]

jbarnes@sgi.com (Jesse Barnes) writes:

|> On Fri, Jun 20, 2003 at 09:44:13PM +0200, Andreas Schwab wrote:
|> > jbarnes@sgi.com (Jesse Barnes) writes:
|> > 
|> > |> This one Works For Me (tm).  Does it look ok?
|> > 
|> > Does it require other patches?
|> 
|> Yes, as it turns out.  You'll need the discontig patch I posted earlier.

These patches overlap.  I had to delete the arch/ia64/Kconfig patch from
the discontig patch.  Unfortunately, there are more problems
(devfs_handle_t is private to devfs):

  CC      arch/ia64/sn/io/drivers/ifconfig_net.o
arch/ia64/sn/io/drivers/ifconfig_net.c:40: error: parse error before "ifconfig_net_handle"
arch/ia64/sn/io/drivers/ifconfig_net.c:40: warning: type defaults to `int' in declaration of `ifconfig_net_handle'
arch/ia64/sn/io/drivers/ifconfig_net.c:40: warning: data definition has no type or storage class
arch/ia64/sn/io/drivers/ifconfig_net.c: In function `init_ifconfig_net':
arch/ia64/sn/io/drivers/ifconfig_net.c:285: warning: assignment makes integer from pointer without a cast
arch/ia64/sn/io/drivers/ifconfig_net.c:290: warning: assignment makes integer from pointer without a cast
arch/ia64/sn/io/drivers/ifconfig_net.c:292: warning: comparison between pointer and integer
make[3]: *** [arch/ia64/sn/io/drivers/ifconfig_net.o] Error 1

Thanks, Andreas.

-- 
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux AG, Deutschherrnstr. 15-19, D-90429 Nürnberg
Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: 2.5.72 for ia64 released

[Jesse Barnes]

On Fri, Jun 20, 2003 at 10:25:06PM +0200, Andreas Schwab wrote:
> jbarnes@sgi.com (Jesse Barnes) writes:
> 
> |> On Fri, Jun 20, 2003 at 09:44:13PM +0200, Andreas Schwab wrote:
> |> > jbarnes@sgi.com (Jesse Barnes) writes:
> |> > 
> |> > |> This one Works For Me (tm).  Does it look ok?
> |> > 
> |> > Does it require other patches?
> |> 
> |> Yes, as it turns out.  You'll need the discontig patch I posted earlier.
> 
> These patches overlap.  I had to delete the arch/ia64/Kconfig patch from
> the discontig patch.  Unfortunately, there are more problems
> (devfs_handle_t is private to devfs):
> 
>   CC      arch/ia64/sn/io/drivers/ifconfig_net.o
> arch/ia64/sn/io/drivers/ifconfig_net.c:40: error: parse error before "ifconfig_net_handle"
> arch/ia64/sn/io/drivers/ifconfig_net.c:40: warning: type defaults to `int' in declaration of `ifconfig_net_handle'
> arch/ia64/sn/io/drivers/ifconfig_net.c:40: warning: data definition has no type or storage class
> arch/ia64/sn/io/drivers/ifconfig_net.c: In function `init_ifconfig_net':
> arch/ia64/sn/io/drivers/ifconfig_net.c:285: warning: assignment makes integer from pointer without a cast
> arch/ia64/sn/io/drivers/ifconfig_net.c:290: warning: assignment makes integer from pointer without a cast
> arch/ia64/sn/io/drivers/ifconfig_net.c:292: warning: comparison between pointer and integer
> make[3]: *** [arch/ia64/sn/io/drivers/ifconfig_net.o] Error 1

Ugg, it never ends! :)  Yes, the patches overlap because I seperated out
and fixed the Kconfig changes from the discontig patch and posted them
in the last one, but haven't posted a new discontig yet.  It looks like
David hasn't applied my last sn2 update either, so you'll need that as
well (I posted it yesterday too, I think).

Thanks for trying to test this out!

Jesse

Re: 2.5.72 for ia64 released

[David Mosberger]

>>>>> On Fri, 20 Jun 2003 13:28:23 -0700, jbarnes@sgi.com (Jesse Barnes) said:

  Jesse> It looks like David hasn't applied my last sn2 update either,
  Jesse> so you'll need that as well (I posted it yesterday too, I
  Jesse> think).

I thought I had applied pretty much everything you sent.  If I missed
something, please resend.

	--david

Re: 2.5.72 for ia64 released

[Jesse Barnes]

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

Oops, maybe I didn't Cc: you.  Here it is again, but maybe
arch/ia64/Makefile shouldn't turn on sn2 for generic builds until the
discontig stuff gets resolved?

Thanks,
Jesse

On Fri, Jun 20, 2003 at 01:34:08PM -0700, David Mosberger wrote:
> >>>>> On Fri, 20 Jun 2003 13:28:23 -0700, jbarnes@sgi.com (Jesse Barnes) said:
> 
>   Jesse> It looks like David hasn't applied my last sn2 update either,
>   Jesse> so you'll need that as well (I posted it yesterday too, I
>   Jesse> think).
> 
> I thought I had applied pretty much everything you sent.  If I missed
> something, please resend.
> 
> 	--david
> -
> To unsubscribe from this list: send the line "unsubscribe linux-ia64" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

[-- Attachment #2: misc-sn2-fixes-2.5.72-ia64-bk.patch --]
[-- Type: text/plain, Size: 9899 bytes --]

# This is a BitKeeper generated patch for the following project:
# Project Name: Linux kernel tree
# This patch format is intended for GNU patch command version 2.5 or higher.
# This patch includes the following deltas:
#	           ChangeSet	1.1341  -> 1.1342 
#	arch/ia64/sn/io/machvec/pci_dma.c	1.10    -> 1.11   
#	arch/ia64/sn/io/drivers/ifconfig_net.c	1.6     ->         (deleted)      
#	arch/ia64/sn/io/hwgfs/hcl.c	1.3     -> 1.4    
#	arch/ia64/sn/io/drivers/Makefile	1.3     -> 1.4    
#
# The following is the BitKeeper ChangeSet Log
# --------------------------------------------
# 03/06/19	jbarnes@tomahawk.engr.sgi.com	1.1342
# remove persistent net device naming and remove devfs flag
# --------------------------------------------
#
diff -Nru a/arch/ia64/sn/io/drivers/Makefile b/arch/ia64/sn/io/drivers/Makefile
--- a/arch/ia64/sn/io/drivers/Makefile	Thu Jun 19 17:04:11 2003
+++ b/arch/ia64/sn/io/drivers/Makefile	Thu Jun 19 17:04:11 2003
@@ -9,4 +9,4 @@
 
 EXTRA_CFLAGS    := -DLITTLE_ENDIAN
 
-obj-y				+= ioconfig_bus.o ifconfig_net.o
+obj-y				+= ioconfig_bus.o
diff -Nru a/arch/ia64/sn/io/drivers/ifconfig_net.c b/arch/ia64/sn/io/drivers/ifconfig_net.c
--- a/arch/ia64/sn/io/drivers/ifconfig_net.c	Thu Jun 19 17:04:11 2003
+++ /dev/null	Wed Dec 31 16:00:00 1969
@@ -1,298 +0,0 @@
-/* $Id: ifconfig_net.c,v 1.1 2002/02/28 17:31:25 marcelo Exp $
- *
- * This file is subject to the terms and conditions of the GNU General Public
- * License.  See the file "COPYING" in the main directory of this archive
- * for more details.
- *
- *  ifconfig_net - SGI's Persistent Network Device names.
- *
- * Copyright (C) 1992-1997, 2000-2003 Silicon Graphics, Inc.  All rights reserved.
- */
-
-#include <linux/types.h>
-#include <linux/config.h>
-#include <linux/slab.h>
-#include <linux/ctype.h>
-#include <linux/module.h>
-#include <linux/init.h>
-
-#include <linux/pci.h>
-#include <linux/netdevice.h>
-#include <linux/etherdevice.h>
-#include <linux/skbuff.h>
-
-#include <asm/sn/sgi.h>
-#include <linux/devfs_fs.h>
-#include <linux/devfs_fs_kernel.h>
-#include <asm/io.h>
-#include <asm/sn/iograph.h>
-#include <asm/sn/invent.h>
-#include <asm/sn/hcl.h>
-#include <asm/sn/labelcl.h>
-#include <asm/sn/ifconfig_net.h>
-
-#define SGI_IFCONFIG_NET "SGI-PERSISTENT NETWORK DEVICE NAME DRIVER"
-#define SGI_IFCONFIG_NET_VERSION "1.0"
-
-/*
- * Some Global definitions.
- */
-static devfs_handle_t ifconfig_net_handle;
-static unsigned long ifconfig_net_debug;
-
-/*
- * ifconfig_net_open - Opens the special device node "/devhw/.ifconfig_net".
- */
-static int ifconfig_net_open(struct inode * inode, struct file * filp)
-{
-	if (ifconfig_net_debug) {
-        	printk("ifconfig_net_open called.\n");
-	}
-
-        return(0);
-
-}
-
-/*
- * ifconfig_net_close - Closes the special device node "/devhw/.ifconfig_net".
- */
-static int ifconfig_net_close(struct inode * inode, struct file * filp)
-{
-
-	if (ifconfig_net_debug) {
-        	printk("ifconfig_net_close called.\n");
-	}
-
-        return(0);
-}
-
-/*
- * assign_ifname - Assign the next available interface name from the persistent list.
- */
-void
-assign_ifname(struct net_device *dev,
-		  struct ifname_num *ifname_num)
-
-{
-
-	/*
-	 * Handle eth devices.
-	 */
-        if ( (memcmp(dev->name, "eth", 3) == 0) ) {
-		if (ifname_num->next_eth != -1) {
-			/*
-			 * Assign it the next available eth interface number. 
-			 */
-			memset(dev->name, 0, strlen(dev->name));
-			sprintf(dev->name, "eth%d", (int)ifname_num->next_eth);
-			ifname_num->next_eth++;
-		} 
-
-                return;
-        }
-
-	/*
-	 * Handle fddi devices.
-	 */
-	if ( (memcmp(dev->name, "fddi", 4) == 0) ) {
-		if (ifname_num->next_fddi != -1) {
-			/*
-			 * Assign it the next available fddi interface number.
-			 */
-			memset(dev->name, 0, strlen(dev->name));
-			sprintf(dev->name, "fddi%d", (int)ifname_num->next_fddi);
-			ifname_num->next_fddi++;
-		}
-
-		return;
-	}
-
-	/*
-	 * Handle hip devices.
-	 */
-	if ( (memcmp(dev->name, "hip", 3) == 0) ) {
-		if (ifname_num->next_hip != -1) {
-			/*
-			 * Assign it the next available hip interface number.
-			 */
-			memset(dev->name, 0, strlen(dev->name));
-			sprintf(dev->name, "hip%d", (int)ifname_num->next_hip);
-			ifname_num->next_hip++;
-		}
-
-		return;
-	}
-
-	/*
-	 * Handle tr devices.
-	 */
-	if ( (memcmp(dev->name, "tr", 2) == 0) ) {
-		if (ifname_num->next_tr != -1) {
-			/*
-			 * Assign it the next available tr interface number.
-			 */
-			memset(dev->name, 0, strlen(dev->name));
-			sprintf(dev->name, "tr%d", (int)ifname_num->next_tr);
-			ifname_num->next_tr++;
-		}
-
-		return;
-	}
-
-	/*
-	 * Handle fc devices.
-	 */
-	if ( (memcmp(dev->name, "fc", 2) == 0) ) {
-		if (ifname_num->next_fc != -1) {
-			/*
-			 * Assign it the next available fc interface number.
-			 */
-			memset(dev->name, 0, strlen(dev->name));
-			sprintf(dev->name, "fc%d", (int)ifname_num->next_fc);
-			ifname_num->next_fc++;
-		}
-
-		return;
-	}
-}
-
-/*
- * find_persistent_ifname: Returns the entry that was seen in previous boot.
- */
-struct ifname_MAC *
-find_persistent_ifname(struct net_device *dev,
-	struct ifname_MAC *ifname_MAC)
-
-{
-
-	while (ifname_MAC->addr_len) {
-		if (memcmp(dev->dev_addr, ifname_MAC->dev_addr, dev->addr_len) == 0)
-			return(ifname_MAC);
-
-		ifname_MAC++;
-	}
-
-	return(NULL);
-}
-
-/*
- * ifconfig_net_ioctl: ifconfig_net driver ioctl interface.
- */
-static int ifconfig_net_ioctl(struct inode * inode, struct file * file,
-        unsigned int cmd, unsigned long arg)
-{
-
-	extern struct net_device *__dev_get_by_name(const char *);
-#ifdef CONFIG_NET
-	struct net_device *dev;
-	struct ifname_MAC *found;
-	char temp[64];
-#endif
-	struct ifname_MAC *ifname_MAC;
-	struct ifname_MAC *new_devices, *temp_new_devices;
-	struct ifname_num *ifname_num;
-	unsigned long size;
-
-
-	if (ifconfig_net_debug) {
-		printk("HCL: hcl_ioctl called.\n");
-	}
-
-	/*
-	 * Read in the header and see how big of a buffer we really need to 
-	 * allocate.
-	 */
-	ifname_num = (struct ifname_num *) kmalloc(sizeof(struct ifname_num), 
-			GFP_KERNEL);
-	copy_from_user( ifname_num, (char *) arg, sizeof(struct ifname_num));
-	size = ifname_num->size;
-	kfree(ifname_num);
-	ifname_num = (struct ifname_num *) kmalloc(size, GFP_KERNEL);
-	ifname_MAC = (struct ifname_MAC *) ((char *)ifname_num + (sizeof(struct ifname_num)) );
-
-	copy_from_user( ifname_num, (char *) arg, size);
-	new_devices =  kmalloc(size - sizeof(struct ifname_num), GFP_KERNEL);
-	temp_new_devices = new_devices;
-
-	memset(new_devices, 0, size - sizeof(struct ifname_num));
-
-#ifdef CONFIG_NET
-	/*
-	 * Go through the net device entries and make them persistent!
-	 */
-	for (dev = dev_base; dev != NULL; dev = dev->next) {
-		/*
-		 * Skip NULL entries or "lo"
-		 */
-		if ( (dev->addr_len == 0) || ( !strncmp(dev->name, "lo", strlen(dev->name))) ){
-			continue;
-		}
-
-		/*
-		 * See if we have a persistent interface name for this device.
-		 */
-		found = NULL;
-		found = find_persistent_ifname(dev, ifname_MAC);
-		if (found) {
-			strcpy(dev->name, found->name);
-		} else {
-			/* Never seen this before .. */
-			assign_ifname(dev, ifname_num);
-
-			/* 
-			 * Save the information for the next boot.
-			 */
- 			sprintf(temp,"%s %02x:%02x:%02x:%02x:%02x:%02x\n", dev->name,
-				dev->dev_addr[0],  dev->dev_addr[1],  dev->dev_addr[2],
-				dev->dev_addr[3],  dev->dev_addr[4],  dev->dev_addr[5]);
-			strcpy(temp_new_devices->name, dev->name);
-			temp_new_devices->addr_len = dev->addr_len;
-			memcpy(temp_new_devices->dev_addr, dev->dev_addr, dev->addr_len);
-			temp_new_devices++;
-		}
-		
-	}
-#endif
-
-	/*
-	 * Copy back to the User Buffer area any new devices encountered.
-	 */
-	copy_to_user((char *)arg + (sizeof(struct ifname_num)), new_devices, 
-			size - sizeof(struct ifname_num));
-
-	return(0);
-
-}
-
-struct file_operations ifconfig_net_fops = {
-	ioctl:ifconfig_net_ioctl,	/* ioctl */
-	open:ifconfig_net_open,		/* open */
-	release:ifconfig_net_close	/* release */
-};
-
-
-/*
- * init_ifconfig_net() - Boot time initialization.  Ensure that it is called 
- *	after devfs has been initialized.
- *
- */
-#ifdef MODULE
-int init_module (void)
-#else
-int __init init_ifconfig_net(void)
-#endif
-{
-	ifconfig_net_handle = NULL;
-	ifconfig_net_handle = hwgraph_register(hwgraph_root, ".ifconfig_net",
- 		        0, 0,
-			0, 0,
-			S_IFCHR | S_IRUSR | S_IWUSR | S_IRGRP, 0, 0,
-			&ifconfig_net_fops, NULL);
-
-	if (ifconfig_net_handle == NULL) {
-		panic("Unable to create SGI PERSISTENT NETWORK DEVICE Name Driver.\n");
-	}
-
-	return(0);
-
-}
diff -Nru a/arch/ia64/sn/io/hwgfs/hcl.c b/arch/ia64/sn/io/hwgfs/hcl.c
--- a/arch/ia64/sn/io/hwgfs/hcl.c	Thu Jun 19 17:04:11 2003
+++ b/arch/ia64/sn/io/hwgfs/hcl.c	Thu Jun 19 17:04:11 2003
@@ -128,7 +128,6 @@
 {
 	extern void string_table_init(struct string_table *);
 	extern struct string_table label_string_table;
-	extern int init_ifconfig_net(void);
 	extern int init_ioconfig_bus(void);
 	extern int init_hwgfs_fs(void);
 	int rv = 0;
@@ -183,7 +182,6 @@
 	 * Initialize the ifconfgi_net driver that does network devices 
 	 * Persistent Naming.
 	 */
-	init_ifconfig_net();
 	init_ioconfig_bus();
 
 	return(0);
@@ -557,7 +555,7 @@
 	 * In this case the vertex was previous created with a REAL pathname.
 	 */
 	rv = hwgfs_mk_symlink (from, (const char *)name,
-			       DEVFS_FL_DEFAULT, link,
+			       0, link,
 			       &handle, NULL);
 	kfree(path);
 	kfree(link);
diff -Nru a/arch/ia64/sn/io/machvec/pci_dma.c b/arch/ia64/sn/io/machvec/pci_dma.c
--- a/arch/ia64/sn/io/machvec/pci_dma.c	Thu Jun 19 17:04:11 2003
+++ b/arch/ia64/sn/io/machvec/pci_dma.c	Thu Jun 19 17:04:11 2003
@@ -587,7 +587,7 @@
 {
 	BUG_ON(dev->bus != &pci_bus_type);
 
-	if (!sn_dma_supported(to_pci_dev(dev), dma_mask))
+	if (!sn_dma_supported(dev, dma_mask))
 		return 0;
 
 	dev->dma_mask = dma_mask;

Re: 2.5.72 for ia64 released

[Andreas Schwab]

jbarnes@sgi.com (Jesse Barnes) writes:

|> Ugg, it never ends! :)  Yes, the patches overlap because I seperated out
|> and fixed the Kconfig changes from the discontig patch and posted them
|> in the last one, but haven't posted a new discontig yet.  It looks like
|> David hasn't applied my last sn2 update either, so you'll need that as
|> well (I posted it yesterday too, I think).

Please note I don't use bk, just David's latest patch.

Andreas.

-- 
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux AG, Deutschherrnstr. 15-19, D-90429 Nürnberg
Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: 2.5.72 for ia64 released

[David Mosberger]

>>>>> On Fri, 20 Jun 2003 13:39:44 -0700, jbarnes@sgi.com (Jesse Barnes) said:

  Jesse> maybe arch/ia64/Makefile shouldn't turn on sn2 for generic
  Jesse> builds until the discontig stuff gets resolved?

Yes, this sounds like the right thing to do for now.

	--david

Re: 2.5.72 for ia64 released

[Sam Ravnborg]

On Fri, Jun 20, 2003 at 01:39:44PM -0700, Jesse Barnes wrote:
> #	arch/ia64/sn/io/drivers/Makefile	1.3     -> 1.4    

Related topic.
Why do you put drivers hare.
Kernel policy is to put even architecture specific drivers in drivers/,
not somewhere below arch/.

	Sam

Re: 2.5.72 for ia64 released

[Jack Steiner]

    Jesse> Yeah, that's what I meant.  Jack's patch to 2.4 has been
    Jesse> tested on sn2, DIG, zx1, NEC, and Bull machines, as a generic
    Jesse> kernel for the first three at least (don't know what NEC and
    Jesse> Bull did for their testing).

  David> But which ones are NUMA with node-scattered physical memory?  sn2 for
  David> sure.  DIG, zx1 are not, for sure.  I'm not certain about NEC or Bull.
  David> So I'm not convinced that it works for all possible physical memory
  David> layouts.



Takayoshi tested it on an NEC numa system & had no problems with the final
version of the patch.. The memory map for his system was:

	mem00: type=4, attr=0x9, range=[0x0000000000000000-0x0000000000001000) (0MB)
	mem01: type=7, attr=0x9, range=[0x0000000000001000-0x0000000000088000) (0MB)
	mem02: type=4, attr=0x9, range=[0x0000000000088000-0x00000000000a0000) (0MB)
	...
	mem67: type=4, attr=0x9, range=[0x000000041f90d000-0x000000041f9fe000) (0MB)
	mem68: type=7, attr=0x9, range=[0x000000041f9fe000-0x000000041fda4000) (3MB)
	mem69: type=5, attr=0x8000000000000009, range=[0x000000041fda4000-0x000000041fe10000) (0MB)
	mem70: type=7, attr=0x9, range=[0x000000041fe10000-0x000000041ffb2000) (1MB)
	mem71: type=6, attr=0x8000000000000009, range=[0x000000041ffb2000-0x0000000420000000) (0MB)
	mem72: type\x12, attr=0x8000000000000001, range=[0x00000ffffc000000-0x0000100000000000) (64MB)

	SRAT revision 1
	SRAT Processor (id[0x60] eid[0x00]) in proximity domain 6 enabled
	SRAT Processor (id[0x61] eid[0x00]) in proximity domain 6 enabled
	SRAT Processor (id[0x62] eid[0x00]) in proximity domain 6 enabled
	SRAT Processor (id[0x63] eid[0x00]) in proximity domain 6 enabled
	SRAT Processor (id[0x70] eid[0x00]) in proximity domain 7 enabled
	SRAT Processor (id[0x71] eid[0x00]) in proximity domain 7 enabled
	SRAT Processor (id[0x72] eid[0x00]) in proximity domain 7 enabled
	SRAT Processor (id[0x73] eid[0x00]) in proximity domain 7 enabled
	SRAT Memory (0x0000000000000000 length 0x000000000009fc00 type 0x1) in proximity domain 6 enabled
	SRAT Memory (0x0000000000100000 length 0x00000001fff00000 type 0x1) in proximity domain 6 enabled
	SRAT Memory (0x0000000200000000 length 0x0000000200000000 type 0x1) in proximity domain 7 enabled
	SRAT Memory (0x0000000400000000 length 0x0000000020000000 type 0x1) in proximity domain 6 enabled


This testing was on the 2.4.20 version of the patch but I think the 2.5 version is the same - at
least as far as the memmap is concerned.

I dont know if the BULL system was numa but they verified the final version of
the 2.4.20 patch.

No guarantee that it works for everything though...
	



-- 
Thanks

Jack Steiner    (651-683-5302)   (vnet 233-5302)      steiner@sgi.com

Re: 2.5.72 for ia64 released

[David Mosberger]

  Jesse> Oops, maybe I didn't Cc: you.  Here it is again, ...

OK, it _was_ my fault after all: I applied it in the to-linus-2.5 tree
but then forgot to pull it into the linux-ia64-2.5 tree before making
the new patch.  Sorry about that.

I just pushed out the latest linux-ia64-2.5 stuff, so if you could
verify that it's all there, that would be great (won't help with the
current 2.5.72 patch, but the next one should be OK).

	--david

Re: 2.5.72 for ia64 released

[Jesse Barnes]

On Fri, Jun 20, 2003 at 10:51:00PM +0200, Sam Ravnborg wrote:
> On Fri, Jun 20, 2003 at 01:39:44PM -0700, Jesse Barnes wrote:
> > #	arch/ia64/sn/io/drivers/Makefile	1.3     -> 1.4    
> 
> Related topic.
> Why do you put drivers hare.
> Kernel policy is to put even architecture specific drivers in drivers/,
> not somewhere below arch/.

Yeah, I know, it's misnamed really.  They're not really drivers.