Skip to contentSkip to conversation

2.5.72 for ia64 released

DISCUSSION David Mosberger 6 participants 29 messages Jun 19, 2003 – Jun 20, 2003 ACPI

lore
Share & tools
lore
#0 lore raw

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

#1 lore raw

David Mosberger <[email protected]> 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.

Signature · 4 lines
Andreas Schwab, SuSE Labs, [email protected]
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."
#2 lore raw
In reply to David Mosberger

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

Thanks,
Jesse

Quoted 47 lines · Andreas Schwab

David Mosberger <[email protected]> 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.

Signature · 8 lines
Andreas Schwab, SuSE Labs, [email protected]
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 [email protected]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
#3 lore raw
In reply to David Mosberger
arch/ia64/lib/Makefile Thu Jun 19 14:19:14 2003 +6 -0
diff -Nru a/arch/ia64/lib/Makefile b/arch/ia64/lib/Makefile
@@ -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 [email protected] 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) }
-}
#4 lore raw
In reply to David Mosberger
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line · Sam Ravnborg
  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
#5 lore raw
In reply to David Mosberger

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

Quoted 58 lines · Jesse Barnes

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

Thanks,
Jesse

Quoted 30 lines · Andreas Schwab

David Mosberger <[email protected]> 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:
Quoted 17 lines

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.

Signature · 8 lines
Andreas Schwab, SuSE Labs, [email protected]
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 [email protected]
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 [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html

#6 lore raw
In reply to David Mosberger
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line · On Fri, 20 Jun 2003 11:35:31 -0700, [email protected] (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
#7 lore raw
In reply to David Mosberger
Quoted 8 lines · David Mosberger
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line · On Fri, 20 Jun 2003 11:35:31 -0700, [email protected] (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.

Quoted 2 lines

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

#8 lore raw
In reply to David Mosberger
Quoted 5 lines
Quoted 5 lines
Quoted 1 line
Quoted 1 line
Quoted 1 line · On Fri, 20 Jun 2003 11:45:19 -0700, [email protected] (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.

Quoted 2 lines
Quoted 2 lines

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
#9 lore raw
In reply to David Mosberger

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

Thanks,
Jesse

Quoted 19 lines · Jesse Barnes
Quoted 8 lines · David Mosberger
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line · On Fri, 20 Jun 2003 11:35:31 -0700, [email protected] (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.

Quoted 2 lines

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...

Quoted 6 lines

Thanks,
Jesse
-
To unsubscribe from this list: send the line "unsubscribe linux-ia64" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html

===== drivers/acpi/Kconfig 1.9 vs edited =====

drivers/acpi/Kconfig +1 -1
@@ -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 =====

arch/ia64/Kconfig +6 -39

81 lines not on this page · raw message

#10 lore raw
In reply to David Mosberger
Quoted 6 lines · David Mosberger
Quoted 5 lines
Quoted 5 lines
Quoted 1 line
Quoted 1 line
Quoted 1 line · On Fri, 20 Jun 2003 11:45:19 -0700, [email protected] (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.

Quoted 6 lines

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).

Quoted 11 lines
Quoted 2 lines
Quoted 2 lines

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

#11 lore raw
In reply to David Mosberger
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line · On Fri, 20 Jun 2003 11:53:03 -0700, [email protected] (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
#12 lore raw
In reply to David Mosberger
Quoted 8 lines · David Mosberger
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line · On Fri, 20 Jun 2003 11:53:03 -0700, [email protected] (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.

Quoted 6 lines

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

#13 lore raw
In reply to David Mosberger

[email protected] (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.

Signature · 4 lines
Andreas Schwab, SuSE Labs, [email protected]
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."
#14 lore raw
In reply to David Mosberger

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

Jesse

Quoted 37 lines · Andreas Schwab

[email protected] (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.

Signature · 8 lines
Andreas Schwab, SuSE Labs, [email protected]
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 [email protected]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
#15 lore raw
In reply to David Mosberger

[email protected] (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.

Signature · 4 lines
Andreas Schwab, SuSE Labs, [email protected]
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."
#16 lore raw
In reply to David Mosberger
Quoted 5 lines · Andreas Schwab

[email protected] (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

#17 lore raw
In reply to David Mosberger
Quoted 8 lines · David Mosberger

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

arch/ia64/lib/Makefile +1 -6
diff -Naur -X dontdiff linux-2.5.72-030619/arch/ia64/lib/Makefile linux-2.5.72-030619-fix/arch/ia64/lib/Makefile
@@ -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
#18 lore raw
In reply to David Mosberger
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line · On Fri, 20 Jun 2003 14:03:14 -0600, [email protected] (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
#19 lore raw
In reply to David Mosberger

[email protected] (Jesse Barnes) writes:

|> On Fri, Jun 20, 2003 at 09:44:13PM +0200, Andreas Schwab wrote:
|> > [email protected] (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.

Signature · 4 lines
Andreas Schwab, SuSE Labs, [email protected]
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."
#20 lore raw
In reply to David Mosberger
Quoted 15 lines · Andreas Schwab

[email protected] (Jesse Barnes) writes:

|> On Fri, Jun 20, 2003 at 09:44:13PM +0200, Andreas Schwab wrote:
|> > [email protected] (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):

Quoted 9 lines

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

#21 lore raw
In reply to David Mosberger
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line · On Fri, 20 Jun 2003 13:28:23 -0700, [email protected] (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
#22 lore raw
In reply to David Mosberger

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

Quoted 6 lines · David Mosberger
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line · On Fri, 20 Jun 2003 13:28:23 -0700, [email protected] (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).

Quoted 8 lines

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 [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html

# 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 [email protected] 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

arch/ia64/sn/io/drivers/ifconfig_net.c deleted +0 -298
diff -Nru a/arch/ia64/sn/io/drivers/ifconfig_net.c b/arch/ia64/sn/io/drivers/ifconfig_net.c
@@ -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);
-
-}
arch/ia64/sn/io/hwgfs/hcl.c +1 -3
diff -Nru a/arch/ia64/sn/io/hwgfs/hcl.c b/arch/ia64/sn/io/hwgfs/hcl.c
@@ -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);
arch/ia64/sn/io/machvec/pci_dma.c +1 -1
diff -Nru a/arch/ia64/sn/io/machvec/pci_dma.c b/arch/ia64/sn/io/machvec/pci_dma.c
@@ -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;
#23 lore raw
In reply to David Mosberger

[email protected] (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.

Signature · 4 lines
Andreas Schwab, SuSE Labs, [email protected]
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."
#24 lore raw
In reply to David Mosberger
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line · On Fri, 20 Jun 2003 13:39:44 -0700, [email protected] (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
#25 lore raw
In reply to David Mosberger
Quoted 1 line · Jesse Barnes

# 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

#26 lore raw
In reply to David Mosberger

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, 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...

Signature · 3 lines
Thanks

Jack Steiner    (651-683-5302)   (vnet 233-5302)      [email protected]
#27 lore raw
In reply to 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
#28 lore raw
In reply to David Mosberger
Quoted 7 lines · Sam Ravnborg
Quoted 1 line · Jesse Barnes

# 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.