From linas at austin.ibm.com Fri Aug 1 06:50:37 2003 From: linas at austin.ibm.com (linas at austin.ibm.com) Date: Thu, 31 Jul 2003 15:50:37 -0500 Subject: SMP-efficient timer patch Message-ID: <20030731155037.A22910@forte.austin.ibm.com> The patch below makes kernel-2.4.21 ever so slightly more efficient by running cpu-local timers from the local cpu timer interrupt. (This is how timers are run on kernel-2.6, and is how they are run on x86. Note that the timer code changed significantly in 2.4.21; its a partial back-port of the 2.6 timer code. That is why this issue is coming up for the first time only now). This patch was suggested by Andrea Arcangeli during the course of the Re: PATCH: Race in 2.6.0-test2 timer code LKML discussion thread. (30 July 2003) --linas Index: kernel/timer.c =================================================================== RCS file: /home/linas/cvsroot/linux24/kernel/timer.c,v retrieving revision 1.1.1.1.4.1 diff -u -p -u -r1.1.1.1.4.1 timer.c --- kernel/timer.c 15 Jul 2003 18:43:52 -0000 1.1.1.1.4.1 +++ kernel/timer.c 31 Jul 2003 15:30:26 -0000 @@ -764,7 +764,7 @@ void do_timer(struct pt_regs *regs) /* SMP process accounting uses the local APIC timer */ update_process_times(user_mode(regs)); -#if defined(CONFIG_X86) || defined(CONFIG_IA64) /* x86-64 is also included by CONFIG_X86 */ +#if defined(CONFIG_X86) || defined(CONFIG_IA64) || defined(CONFIG_PPC64) /* x86-64 is also included by CONFIG_X86 */ mark_bh(TIMER_BH); #endif #endif @@ -772,7 +772,7 @@ void do_timer(struct pt_regs *regs) * Right now only x86-SMP calls run_local_timers() from a * per-CPU interrupt. */ -#if !defined(CONFIG_X86) && !defined(CONFIG_IA64) /* x86-64 is also included by CONFIG_X86 */ +#if !defined(CONFIG_X86) && !defined(CONFIG_IA64) && !defined(CONFIG_PPC64) /* x86-64 is also included by CONFIG_X86 */ mark_bh(TIMER_BH); #endif update_times(); Index: arch/ppc64/kernel/smp.c =================================================================== RCS file: /home/linas/cvsroot/linux24/arch/ppc64/kernel/smp.c,v retrieving revision 1.2.4.1 diff -u -p -u -r1.2.4.1 smp.c --- arch/ppc64/kernel/smp.c 15 Jul 2003 18:41:56 -0000 1.2.4.1 +++ arch/ppc64/kernel/smp.c 31 Jul 2003 15:21:35 -0000 @@ -398,6 +398,8 @@ void smp_local_timer_interrupt(struct pt update_process_times(user_mode(regs)); (get_paca()->prof_counter)=get_paca()->prof_multiplier; } + + run_local_timers(); } void smp_message_recv(int msg, struct pt_regs *regs) ** Sent via the linuxppc64-dev mail list. See http://lists.linuxppc.org/ From akpm at osdl.org Sun Aug 3 07:21:25 2003 From: akpm at osdl.org (Andrew Morton) Date: Sat, 2 Aug 2003 14:21:25 -0700 Subject: patches for current -mm kernels Message-ID: <20030802142125.213e36ff.akpm@osdl.org> I had to hack some fixes together to get a working ppc64 kernel with current Linus plus current me. I'll do 2.6.0-test2-mm3 today. It works on ppc64. Implement local.h for ppc64. It's only 32-bit at present. ppc64 doesn't seem to support atomic64_t. include/asm-ppc64/local.h | 40 ++++++++++++++++++++++++++++++++++++++++ 1 files changed, 40 insertions(+) diff -puN /dev/null include/asm-ppc64/local.h --- /dev/null 2002-08-30 16:31:37.000000000 -0700 +++ 25-power4-akpm/include/asm-ppc64/local.h 2003-08-02 13:28:41.000000000 -0700 @@ -0,0 +1,40 @@ +#ifndef _ARCH_PPC6464_LOCAL_H +#define _ARCH_PPC6464_LOCAL_H + +#include +#include + +typedef atomic_t local_t; + +#define LOCAL_INIT(i) ATOMIC64_INIT(i) +#define local_read(v) atomic_read(v) +#define local_set(v,i) atomic_set(v,i) + +#define local_inc(v) atomic_inc(v) +#define local_dec(v) atomic_inc(v) +#define local_add(i, v) atomic_add(i, v) +#define local_sub(i, v) atomic_sub(i, v) + +#define __local_inc(v) ((v)->counter++) +#define __local_dec(v) ((v)->counter++) +#define __local_add(i,v) ((v)->counter+=(i)) +#define __local_sub(i,v) ((v)->counter-=(i)) + +/* Use these for per-cpu local_t variables: on some archs they are + * much more efficient than these naive implementations. Note they take + * a variable, not an address. + */ +#define cpu_local_read(v) local_read(&__get_cpu_var(v)) +#define cpu_local_set(v, i) local_set(&__get_cpu_var(v), (i)) + +#define cpu_local_inc(v) local_inc(&__get_cpu_var(v)) +#define cpu_local_dec(v) local_dec(&__get_cpu_var(v)) +#define cpu_local_add(i, v) local_add((i), &__get_cpu_var(v)) +#define cpu_local_sub(i, v) local_sub((i), &__get_cpu_var(v)) + +#define __cpu_local_inc(v) __local_inc(&__get_cpu_var(v)) +#define __cpu_local_dec(v) __local_dec(&__get_cpu_var(v)) +#define __cpu_local_add(i, v) __local_add((i), &__get_cpu_var(v)) +#define __cpu_local_sub(i, v) __local_sub((i), &__get_cpu_var(v)) + +#endif /* _ARCH_PPC6464_LOCAL_H */ _ ** Sent via the linuxppc64-dev mail list. See http://lists.linuxppc.org/ From akpm at osdl.org Sun Aug 3 07:22:15 2003 From: akpm at osdl.org (Andrew Morton) Date: Sat, 2 Aug 2003 14:22:15 -0700 Subject: patches for current -mm kernels In-Reply-To: <20030802142125.213e36ff.akpm@osdl.org> References: <20030802142125.213e36ff.akpm@osdl.org> Message-ID: <20030802142215.2adc623f.akpm@osdl.org> Need this to compile kernel/profile.c include/asm-ppc64/sections.h | 7 +++++++ 1 files changed, 7 insertions(+) diff -puN /dev/null include/asm-ppc64/sections.h --- /dev/null 2002-08-30 16:31:37.000000000 -0700 +++ 25-power4-akpm/include/asm-ppc64/sections.h 2003-08-02 13:35:52.000000000 -0700 @@ -0,0 +1,7 @@ +#ifndef _PPC64_SECTIONS_H +#define _PPC64_SECTIONS_H + +/* nothing to see, move along */ +#include + +#endif _ ** Sent via the linuxppc64-dev mail list. See http://lists.linuxppc.org/ From akpm at osdl.org Sun Aug 3 07:22:57 2003 From: akpm at osdl.org (Andrew Morton) Date: Sat, 2 Aug 2003 14:22:57 -0700 Subject: patches for current -mm kernels In-Reply-To: <20030802142125.213e36ff.akpm@osdl.org> References: <20030802142125.213e36ff.akpm@osdl.org> Message-ID: <20030802142257.14f2c415.akpm@osdl.org> Ingo's CPU scheduler update (in -mm kernels) needs a new sched_clock() function which returns nanoseconds. Stupid implementation which only gets it right on 1GHz CPUs. I assume. It's an undocumented miasma down there and if they can't be bothered describing it then I can't be bothered decrypting it. So there. arch/ppc64/kernel/time.c | 9 +++++++++ 1 files changed, 9 insertions(+) diff -puN arch/ppc64/kernel/time.c~ppc64-sched_clock arch/ppc64/kernel/time.c --- 25-power4/arch/ppc64/kernel/time.c~ppc64-sched_clock 2003-08-02 13:40:46.000000000 -0700 +++ 25-power4-akpm/arch/ppc64/kernel/time.c 2003-08-02 13:44:43.000000000 -0700 @@ -308,6 +308,15 @@ int timer_interrupt(struct pt_regs * reg return 1; } +/* + * Scheduler clock - returns current time in nanosec units. + * + * This is wrong, but my CPUs run at 1GHz, so nyer nyer. + */ +unsigned long long sched_clock(void) +{ + return get_tb(); +} /* * This version of gettimeofday has microsecond resolution. _ ** Sent via the linuxppc64-dev mail list. See http://lists.linuxppc.org/ From akpm at osdl.org Sun Aug 3 07:23:26 2003 From: akpm at osdl.org (Andrew Morton) Date: Sat, 2 Aug 2003 14:23:26 -0700 Subject: patches for current -mm kernels In-Reply-To: <20030802142125.213e36ff.akpm@osdl.org> References: <20030802142125.213e36ff.akpm@osdl.org> Message-ID: <20030802142326.6ae89445.akpm@osdl.org> arch/ppc64/boot/prom.c doesn't compile. Because there is no definition of BITS_PER_LONG for div64.h. Hack one up. arch/ppc64/boot/prom.c | 2 ++ 1 files changed, 2 insertions(+) diff -puN arch/ppc64/boot/prom.c~ppc64-prom-compile-fix arch/ppc64/boot/prom.c --- 25-power4/arch/ppc64/boot/prom.c~ppc64-prom-compile-fix 2003-08-02 13:53:53.000000000 -0700 +++ 25-power4-akpm/arch/ppc64/boot/prom.c 2003-08-02 13:54:25.000000000 -0700 @@ -11,6 +11,8 @@ #include #include +#define BITS_PER_LONG 64 /* do_div() needs this */ + #include int (*prom)(void *); _ ** Sent via the linuxppc64-dev mail list. See http://lists.linuxppc.org/ From anton at samba.org Wed Aug 6 04:30:56 2003 From: anton at samba.org (Anton Blanchard) Date: Wed, 6 Aug 2003 04:30:56 +1000 Subject: patches for current -mm kernels In-Reply-To: <20030802142125.213e36ff.akpm@osdl.org> References: <20030802142125.213e36ff.akpm@osdl.org> Message-ID: <20030805183056.GA22263@krispykreme> Hi Andrew, > I had to hack some fixes together to get a working ppc64 kernel with > current Linus plus current me. Sorry about that, I havent pushed to Linus in a while. Looks like he did pull last night so most things should be OK now. > Implement local.h for ppc64. It's only 32-bit at present. ppc64 doesn't > seem to support atomic64_t. Yeah Im the slacker, I need to implement atomic64. > Need this to compile kernel/profile.c Got it. I also went through and fixed up all our abuses of _stext etc. > Ingo's CPU scheduler update (in -mm kernels) needs a new sched_clock() > function which returns nanoseconds. > Stupid implementation which only gets it right on 1GHz CPUs. > I assume. It's an undocumented miasma down there and if they can't be > bothered describing it then I can't be bothered decrypting it. So > there. Heh what are you having a swipe at here? > arch/ppc64/boot/prom.c doesn't compile. Because there is no definition > of BITS_PER_LONG for div64.h. Hack one up. Got this one too. It turns out the boot wrapper is 32bit so I modified the definition to suit. Anton ** Sent via the linuxppc64-dev mail list. See http://lists.linuxppc.org/ From nathanl at austin.ibm.com Wed Aug 6 09:11:01 2003 From: nathanl at austin.ibm.com (Nathan Lynch) Date: Tue, 05 Aug 2003 18:11:01 -0500 Subject: patch - remove find_pci_device_OFnode declaration Message-ID: <3F303985.6080100@austin.ibm.com> Hi- find_pci_device_OFnode() (declared in include/asm-ppc64/prom.h) has no implementation. The only instance I could find of its still being called is in drivers/video/pm3fb.c. The attached patch (against 2.6.0-test2) removes the declaration. Nathan -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: find_pci_device_OFnode_2.6_patch Url: http://ozlabs.org/pipermail/linuxppc64-dev/attachments/20030805/292dac33/attachment.txt From jeremyrodriguez at cmsmechanical.com Wed Aug 6 23:32:49 2003 From: jeremyrodriguez at cmsmechanical.com (Jeremy Rodriguez) Date: Wed, 6 Aug 2003 09:32:49 -0400 Subject: RS/6000 44P Model 270 44P Message-ID: I have a IBM RS/6000 44P Model 270 with a WYSE WY-60 hooked up to it. What version of linux will definitely work on it? I have tried Mandrake and received the error below. I posted to their groups but had no success. Has anybody installed linux on this box before? I am trying to install 9.1 PPC on an IBM RS/6000 44P Model 270 with a WYSE WY-60 hooked up to it. I have made the boot floppies and changed the prom: setenv boot-device boot floppy:\zimage setenv boot-file fake_initrd root=/dev/fd0 rw load_ramdisk=1 ramdisk_size=36000 boot After it starts to boot itgoes to > boot chrpboot starting: loaded at 0x00400000 gunzipping (0x000100000 <- 0x004062b8:0x00400000 49112 bytes of heap consumed, max in use 41064 start address = 0x10000 instantinating rtas at 00600000 ... done copying of device tree...done returning 0x00010000 from prom_init The system is in a hung state. I have no X so I need to do a text install. Has anyone had these errors occur? I am not really sure where to go from here, so any help would be greatly appreciated. ** Sent via the linuxppc64-dev mail list. See http://lists.linuxppc.org/ From tom_gall at vnet.ibm.com Thu Aug 7 01:35:42 2003 From: tom_gall at vnet.ibm.com (Tom Gall) Date: Wed, 6 Aug 2003 10:35:42 -0500 Subject: RS/6000 44P Model 270 44P In-Reply-To: Message-ID: On Wednesday, August 6, 2003, at 08:32 AM, Jeremy Rodriguez wrote: > > I have a IBM RS/6000 44P Model 270 with a WYSE WY-60 hooked up to it. > What > version of linux will definitely work on it? SuSE SLES8 as well as Redhat. Debian is possible but requires some effort on your part. Mandrake is probably possible too but you'd need to build yourself a ppc32 kernel with power3 support and even then make sure you don't have a box with > 3 gig of memory. > I have tried Mandrake and received the error below. I posted to their > groups > but had no success. > Has anybody installed linux on this box before? Yup have one in my office ... runs great. Regards, Tom Tom Gall - [Embedded] [PPC64 | PPC32] Linux Peace, Love & Linux "Where's the kaboom? There was Technology Center supposed to be an earth shattering (w) tom_gall at vnet.ibm.com kaboom! " -- Marvin Martian (h) tgall at rochcivictheatre.org ** Sent via the linuxppc64-dev mail list. See http://lists.linuxppc.org/ From streeter at redhat.com Thu Aug 7 01:51:01 2003 From: streeter at redhat.com (Guy M. Streeter) Date: 06 Aug 2003 10:51:01 -0500 Subject: RS/6000 44P Model 270 44P In-Reply-To: <3F312975.7090500@tossell.net> References: <3F312975.7090500@tossell.net> Message-ID: <1060185061.5115.0.camel@jarjar.hsv.redhat.com> The 44p/270 can run a 32bit kernel. --Guy On Wed, 2003-08-06 at 11:14, Ken Tossell wrote: > Jeremy Rodriguez wrote: > > >I have a IBM RS/6000 44P Model 270 with a WYSE WY-60 hooked up to it. What > >version of linux will definitely work on it? > >I have tried Mandrake and received the error below. I posted to their groups > >but had no success. > >Has anybody installed linux on this box before? > > > >I am trying to install 9.1 PPC on an IBM RS/6000 44P Model 270 with a WYSE > >WY-60 hooked up to it. I have made the boot floppies and changed the prom: > > > >setenv boot-device boot floppy:\zimage > >setenv boot-file fake_initrd root=/dev/fd0 rw load_ramdisk=1 > >ramdisk_size=36000 > >boot > > > >After it starts to boot itgoes to > > >boot chrpboot starting: loaded at 0x00400000 > >gunzipping (0x000100000 <- 0x004062b8:0x00400000 > >49112 bytes of heap consumed, max in use 41064 > >start address = 0x10000 > >instantinating rtas at 00600000 ... done > >copying of device tree...done > >returning 0x00010000 from prom_init > > > >The system is in a hung state. I have no X so I need to do a text install. > >Has anyone had these errors occur? I am not really sure where to go from > >here, so any help would be greatly appreciated. > > > > > It looks like your box has just figured out that it's trying to boot a > ppc32 kernel :) > > You'll have to start the installation under a 64bit kernel somehow... > Maybe you could burn a new Mandrake boot cd, replacing the kernel... > > > > > > > > > ** Sent via the linuxppc64-dev mail list. See http://lists.linuxppc.org/ From ken at tossell.net Thu Aug 7 02:14:45 2003 From: ken at tossell.net (Ken Tossell) Date: Wed, 06 Aug 2003 12:14:45 -0400 Subject: RS/6000 44P Model 270 44P In-Reply-To: References: Message-ID: <3F312975.7090500@tossell.net> Jeremy Rodriguez wrote: >I have a IBM RS/6000 44P Model 270 with a WYSE WY-60 hooked up to it. What >version of linux will definitely work on it? >I have tried Mandrake and received the error below. I posted to their groups >but had no success. >Has anybody installed linux on this box before? > >I am trying to install 9.1 PPC on an IBM RS/6000 44P Model 270 with a WYSE >WY-60 hooked up to it. I have made the boot floppies and changed the prom: > >setenv boot-device boot floppy:\zimage >setenv boot-file fake_initrd root=/dev/fd0 rw load_ramdisk=1 >ramdisk_size=36000 >boot > >After it starts to boot itgoes to > >boot chrpboot starting: loaded at 0x00400000 >gunzipping (0x000100000 <- 0x004062b8:0x00400000 >49112 bytes of heap consumed, max in use 41064 >start address = 0x10000 >instantinating rtas at 00600000 ... done >copying of device tree...done >returning 0x00010000 from prom_init > >The system is in a hung state. I have no X so I need to do a text install. >Has anyone had these errors occur? I am not really sure where to go from >here, so any help would be greatly appreciated. > > It looks like your box has just figured out that it's trying to boot a ppc32 kernel :) You'll have to start the installation under a 64bit kernel somehow... Maybe you could burn a new Mandrake boot cd, replacing the kernel... > > > ** Sent via the linuxppc64-dev mail list. See http://lists.linuxppc.org/ From rajuraghava at yahoo.com Thu Aug 7 11:04:25 2003 From: rajuraghava at yahoo.com (Raghava Vatsavayi) Date: Wed, 6 Aug 2003 18:04:25 -0700 (PDT) Subject: pci_single_map for large buffer???? Message-ID: <20030807010425.28177.qmail@web20208.mail.yahoo.com> Hi, Is there any limit on size of buffer that "pci_map_single" can map on linux ppc64 2.4.19 kernels???? For me pci_map_single is failing if I map a buffer of size more than 4K. Please mail me the pointers on how to map buffers of large size. Mail back at rajuraghava at yahoo.com Regards Raghava ** Sent via the linuxppc64-dev mail list. See http://lists.linuxppc.org/ From SVakkalankarao at covansys.com Thu Aug 7 13:58:27 2003 From: SVakkalankarao at covansys.com (VAKKALANKA RAO Sridhar) Date: Thu, 7 Aug 2003 09:28:27 +0530 Subject: RS/6000 44P Model 270 44P Message-ID: <207D6ADFC044A84686D44CA11B297EEA02018A83@chn-ex02.cvns.corp.covansys.com> > Debian is possible but requires some effort on your part. I have been very happy with the Debian installation on my p630 (which, I read is an upgrade over the 270). It is true that Debian requires some effort as it looks very broken to first time users, but once you read the documentation patiently and get accustomed to it, it becomes very easy. I installed only the first CD and the features (especially the graphics) are dazzling. For features that are not present (such as texinfo and ncurses), it is not difficult to download the source tarball, compile and install them. The reason why I recommend Debian is that Florian Weps has already documented his efforts and posted them on the web. Refer to the linuxppc64-dev posting he made on 20030528, "Debian Installation on an IBM p630 LPAR". Jeremy, if you do choose to follow instructions on Florian's URL, you will very likely end up getting a printout of Rolf Brudeseth's URL, "Debian network installation on IBM RS/6000 44P-170". On that (Brudeseth's) URL, it is very important that you avoid performing the step "Install Driver Modules (but not Kernel yet)". Needless to say, the "vmlinux" and "zImage.initrd" will be your own ppc64 ones (compiled by you) and not the 32-bit ones Brudeseth talks about. Cheers Sri ** Sent via the linuxppc64-dev mail list. See http://lists.linuxppc.org/ From linas at austin.ibm.com Fri Aug 8 02:09:33 2003 From: linas at austin.ibm.com (linas at austin.ibm.com) Date: Thu, 7 Aug 2003 11:09:33 -0500 Subject: PPC timer scalability patch Message-ID: <20030807110933.A24616@forte.austin.ibm.com> The patch below makes kernel-2.4.21 ever so slightly more efficient by running cpu-local timers from the local cpu timer interrupt. (This is how timers are run on kernel-2.6, and is how they are run on x86. Note that the timer code changed significantly in 2.4.21; its a partial back-port of the 2.6 timer code. That is why this issue is coming up for the first time only now). This patch was suggested by Andrea Arcangeli during disucussions w/ Andrew Morton on the Re: PATCH: Race in 2.6.0-test2 timer code LKML discussion thread. (30 July 2003) --linas Index: kernel/timer.c =================================================================== RCS file: /home/linas/cvsroot/linux24/kernel/timer.c,v retrieving revision 1.1.1.1.4.1 diff -u -p -u -r1.1.1.1.4.1 timer.c --- kernel/timer.c 15 Jul 2003 18:43:52 -0000 1.1.1.1.4.1 +++ kernel/timer.c 31 Jul 2003 15:30:26 -0000 @@ -764,7 +764,7 @@ void do_timer(struct pt_regs *regs) /* SMP process accounting uses the local APIC timer */ update_process_times(user_mode(regs)); -#if defined(CONFIG_X86) || defined(CONFIG_IA64) /* x86-64 is also included by CONFIG_X86 */ +#if defined(CONFIG_X86) || defined(CONFIG_IA64) || defined(CONFIG_PPC64) /* x86-64 is also included by CONFIG_X86 */ mark_bh(TIMER_BH); #endif #endif @@ -772,7 +772,7 @@ void do_timer(struct pt_regs *regs) * Right now only x86-SMP calls run_local_timers() from a * per-CPU interrupt. */ -#if !defined(CONFIG_X86) && !defined(CONFIG_IA64) /* x86-64 is also included by CONFIG_X86 */ +#if !defined(CONFIG_X86) && !defined(CONFIG_IA64) && !defined(CONFIG_PPC64) /* x86-64 is also included by CONFIG_X86 */ mark_bh(TIMER_BH); #endif update_times(); Index: arch/ppc64/kernel/smp.c =================================================================== RCS file: /home/linas/cvsroot/linux24/arch/ppc64/kernel/smp.c,v retrieving revision 1.2.4.1 diff -u -p -u -r1.2.4.1 smp.c --- arch/ppc64/kernel/smp.c 15 Jul 2003 18:41:56 -0000 1.2.4.1 +++ arch/ppc64/kernel/smp.c 31 Jul 2003 15:21:35 -0000 @@ -398,6 +398,8 @@ void smp_local_timer_interrupt(struct pt update_process_times(user_mode(regs)); (get_paca()->prof_counter)=get_paca()->prof_multiplier; } + + run_local_timers(); } void smp_message_recv(int msg, struct pt_regs *regs) ** Sent via the linuxppc64-dev mail list. See http://lists.linuxppc.org/ From everson at webcable.com.br Sat Aug 9 00:09:25 2003 From: everson at webcable.com.br (Everson Todoroki) Date: 08 Aug 2003 11:09:25 -0300 Subject: SSA? Message-ID: <1060351766.1916.17.camel@darkmage> Hello friends, Is there any news about SSA/SerialRaid support on linux? Regards Everson ** Sent via the linuxppc64-dev mail list. See http://lists.linuxppc.org/ From jeremyrodriguez at cmsmechanical.com Sat Aug 9 00:51:34 2003 From: jeremyrodriguez at cmsmechanical.com (Jeremy Rodriguez) Date: Fri, 8 Aug 2003 10:51:34 -0400 Subject: RS/6000 44P Model 270 44P In-Reply-To: <3F312975.7090500@tossell.net> Message-ID: Any suggestions on how to get a 64-bit kernel? or "You'll have to start the installation under a 64bit kernel somehow... Maybe you could burn a new Mandrake boot cd, replacing the kernel..." -----Original Message----- From: Ken Tossell [mailto:ken at tossell.net] Sent: Wednesday, August 06, 2003 12:15 PM To: jeremyrodriguez at cmsmechanical.com Cc: linuxppc64-dev at lists.linuxppc.org Subject: Re: RS/6000 44P Model 270 44P Jeremy Rodriguez wrote: >I have a IBM RS/6000 44P Model 270 with a WYSE WY-60 hooked up to it. What >version of linux will definitely work on it? >I have tried Mandrake and received the error below. I posted to their groups >but had no success. >Has anybody installed linux on this box before? > >I am trying to install 9.1 PPC on an IBM RS/6000 44P Model 270 with a WYSE >WY-60 hooked up to it. I have made the boot floppies and changed the prom: > >setenv boot-device boot floppy:\zimage >setenv boot-file fake_initrd root=/dev/fd0 rw load_ramdisk=1 >ramdisk_size=36000 >boot > >After it starts to boot itgoes to > >boot chrpboot starting: loaded at 0x00400000 >gunzipping (0x000100000 <- 0x004062b8:0x00400000 >49112 bytes of heap consumed, max in use 41064 >start address = 0x10000 >instantinating rtas at 00600000 ... done >copying of device tree...done >returning 0x00010000 from prom_init > >The system is in a hung state. I have no X so I need to do a text install. >Has anyone had these errors occur? I am not really sure where to go from >here, so any help would be greatly appreciated. > > It looks like your box has just figured out that it's trying to boot a ppc32 kernel :) You'll have to start the installation under a 64bit kernel somehow... Maybe you could burn a new Mandrake boot cd, replacing the kernel... > > > ** Sent via the linuxppc64-dev mail list. See http://lists.linuxppc.org/ From anton at samba.org Sat Aug 9 01:10:00 2003 From: anton at samba.org (Anton Blanchard) Date: Sat, 9 Aug 2003 01:10:00 +1000 Subject: pci_single_map for large buffer???? In-Reply-To: <20030807010425.28177.qmail@web20208.mail.yahoo.com> References: <20030807010425.28177.qmail@web20208.mail.yahoo.com> Message-ID: <20030808151000.GA1291@krispykreme> Hi, > Is there any limit on size of buffer that > "pci_map_single" can map on linux ppc64 2.4.19 > kernels???? For me pci_map_single is failing > if I map a buffer of size more than 4K. Please > mail me the pointers on how to map buffers of large > size. Yes there is a maximum size, in include/asm-ppc64/pci_dma.h: /* * NUM_TCE_LEVELS defines the largest contiguous block * of dma (tce) space we can get. NUM_TCE_LEVELS = 10 * allows up to 2**9 pages (512 * 4096) = 2 MB */ #define NUM_TCE_LEVELS 10 Anton ** Sent via the linuxppc64-dev mail list. See http://lists.linuxppc.org/ From anton at samba.org Sat Aug 9 01:33:44 2003 From: anton at samba.org (Anton Blanchard) Date: Sat, 9 Aug 2003 01:33:44 +1000 Subject: DMA alignment???? In-Reply-To: <20030728065834.53933.qmail@web20205.mail.yahoo.com> References: <20030728065834.53933.qmail@web20205.mail.yahoo.com> Message-ID: <20030808153344.GB1291@krispykreme> > Our ethernet driver performance is not so good in > powerpc machines. I have attached a link for a patch > and brief description below, which talks about > alignment of dma memory for rx and tx buffers. > So my question is, Will there be increase in > performance on powerpc machines if I also align my > tx/rx dma pointers????? Is your card PCI or PCI-X? The problem is much less of an issue on PCI-X so long as the MMRBC is at a sufficiently high value. Anton ** Sent via the linuxppc64-dev mail list. See http://lists.linuxppc.org/ From anton at samba.org Sat Aug 9 03:18:50 2003 From: anton at samba.org (Anton Blanchard) Date: Sat, 9 Aug 2003 03:18:50 +1000 Subject: SSA? In-Reply-To: <1060351766.1916.17.camel@darkmage> References: <1060351766.1916.17.camel@darkmage> Message-ID: <20030808171850.GE1291@krispykreme> Hi, > Is there any news about SSA/SerialRaid support on linux? Unfortunately there are no plans. I have a bunch of SSA lying around just waiting for a linux driver :) Anton ** Sent via the linuxppc64-dev mail list. See http://lists.linuxppc.org/ From SVakkalankarao at covansys.com Tue Aug 12 17:58:24 2003 From: SVakkalankarao at covansys.com (VAKKALANKA RAO Sridhar) Date: Tue, 12 Aug 2003 13:28:24 +0530 Subject: DMA alignment???? Message-ID: <207D6ADFC044A84686D44CA11B297EEA02018A8D@chn-ex02.cvns.corp.covansys.com> Is your card PCI or PCI-X? The problem is much less of an issue on PCI-X so long as the MMRBC is at a sufficiently high value. I have the same problem. How do I determine if my card is a PCI or PCI-X. In addition, the graphics on my machine is also very slow. Is it possible that I need a realignment of DMA with the frame buffer of my video card (/dev/fb0)? The command "lspci" stopped working after the pci names were updated! Thanks Sri ** Sent via the linuxppc64-dev mail list. See http://lists.linuxppc.org/ From anton at samba.org Fri Aug 15 10:07:57 2003 From: anton at samba.org (Anton Blanchard) Date: Fri, 15 Aug 2003 10:07:57 +1000 Subject: patch - remove find_pci_device_OFnode declaration In-Reply-To: <3F303985.6080100@austin.ibm.com> References: <3F303985.6080100@austin.ibm.com> Message-ID: <20030815000757.GB23565@krispykreme> > find_pci_device_OFnode() (declared in include/asm-ppc64/prom.h) has no > implementation. The only instance I could find of its still being > called is in drivers/video/pm3fb.c. > > The attached patch (against 2.6.0-test2) removes the declaration. Thanks Nathan, this is in the BK tree. Anton ** Sent via the linuxppc64-dev mail list. See http://lists.linuxppc.org/ From lxie at us.ibm.com Sat Aug 16 06:17:11 2003 From: lxie at us.ibm.com (Linda Xie) Date: Fri, 15 Aug 2003 15:17:11 -0500 Subject: XIVE.patch - XIVE needs to be set to 0xFF before deconfiguring a slot Message-ID: Hi, When attempting to remove an I/O slot, RTAS isolation is complaining that there are still XIVE(Extend Interrupt Vector) entries associated with the slot. Setting the priority of 0xFF(lthe lowest) effectively disables the XIVEs in firmware. The attached patch set XIVE to 0xFF, so an I/O slot can be deconfigured. Linda diff -urpN linux-2.6-orig/arch/ppc64/kernel/xics.c linux-2.6 /arch/ppc64/kernel/xics.c --- linux-2.6-orig/arch/ppc64/kernel/xics.c 2003-07-29 14:23:55.000000000 -0500 +++ linux-2.6/arch/ppc64/kernel/xics.c 2003-07-29 14:32:03.000000000 -0500 @@ -255,6 +255,7 @@ void xics_disable_irq(u_int virq) { u_int irq; long call_status; + unsigned int server; virq -= XICS_IRQ_OFFSET; irq = virt_irq_to_real(virq); @@ -267,6 +268,24 @@ void xics_disable_irq(u_int virq) irq, call_status); return; } +#ifdef CONFIG_IRQ_ALL_CPUS + if (smp_threads_ready) + server = default_distrib_server; + else + server = default_server; +#else + server = default_server; +#endif + + call_status = rtas_call(ibm_set_xive, 3, 1, NULL, irq, server, + 0xff); + + if (call_status != 0) { + printk("xics_disable_irq: irq=%x: ibm_set_xive(0xff) returned %lx\n", + irq, call_status); + return; + } + } void xics_end_irq(u_int irq) ** Sent via the linuxppc64-dev mail list. See http://lists.linuxppc.org/ From anton at samba.org Sat Aug 16 07:15:54 2003 From: anton at samba.org (Anton Blanchard) Date: Sat, 16 Aug 2003 07:15:54 +1000 Subject: XIVE.patch - XIVE needs to be set to 0xFF before deconfiguring a slot In-Reply-To: References: Message-ID: <20030815211553.GA1503@krispykreme> Hi Linda, > When attempting to remove an I/O slot, RTAS isolation is complaining that > there are still XIVE(Extend Interrupt Vector) entries associated with the > slot. Setting the priority of 0xFF(lthe lowest) effectively disables the > XIVEs in firmware. Looks good, I checked it into BK. I added a small comment so we wouldnt forget why that line is there :) I also removed the distrib_server stuff since we dont care at that point. Anton ** Sent via the linuxppc64-dev mail list. See http://lists.linuxppc.org/ From olh at suse.de Sun Aug 17 23:19:32 2003 From: olh at suse.de (Olaf Hering) Date: Sun, 17 Aug 2003 15:19:32 +0200 Subject: some code cleanup for 2.4.21 Message-ID: <20030817131932.GA30720@suse.de> This patch removes some compile warnings, cmd_line is printed by the generic code, no need to print it 3 times. The embedded_sysmap_end is unused. diff -p -purNX /suse/olh/kernel/kernel_exclude.txt linuxppc64-2.4/arch/ppc64/kernel/chrp_setup.c linuxppc64-2.4.less_warnings/arch/ppc64/kernel/chrp_setup.c --- linuxppc64-2.4/arch/ppc64/kernel/chrp_setup.c 2003-06-12 18:34:52.000000000 +0200 +++ linuxppc64-2.4.less_warnings/arch/ppc64/kernel/chrp_setup.c 2003-08-17 14:37:29.000000000 +0200 @@ -137,7 +137,6 @@ void __init chrp_request_regions(void) { void __init chrp_setup_arch(void) { - extern char cmd_line[]; struct device_node *root; unsigned int *opprop; @@ -158,8 +157,6 @@ chrp_setup_arch(void) #endif ROOT_DEV = to_kdev_t(0x0802); /* sda2 (sda1 is for the kernel) */ - printk("Boot arguments: %s\n", cmd_line); - fwnmi_init(); #ifndef CONFIG_PPC_ISERIES diff -p -purNX /suse/olh/kernel/kernel_exclude.txt linuxppc64-2.4/arch/ppc64/kernel/pci_dma.c linuxppc64-2.4.less_warnings/arch/ppc64/kernel/pci_dma.c --- linuxppc64-2.4/arch/ppc64/kernel/pci_dma.c 2003-07-15 19:04:12.000000000 +0200 +++ linuxppc64-2.4.less_warnings/arch/ppc64/kernel/pci_dma.c 2003-08-17 15:15:12.000000000 +0200 @@ -554,7 +554,7 @@ static inline dma_addr_t get_tces( struc the bus address to the IOA */ __asm__ __volatile__ ("sync" : : : "memory"); } else { - panic("get_tces: TCE allocation failed. 0x%p 0x%lx\n", + panic("get_tces: TCE allocation failed. 0x%p 0x%x\n", tbl, order); } @@ -1339,7 +1339,7 @@ static dma_addr_t create_tces_sg(struct numTces, (unsigned)(tcenum - starttcenum)); } else { - panic("PCI_DMA: TCE allocation failure in create_tces_sg. 0x%p 0x%lx\n", + panic("PCI_DMA: TCE allocation failure in create_tces_sg. 0x%p 0x%x\n", tbl, order); } diff -p -purNX /suse/olh/kernel/kernel_exclude.txt linuxppc64-2.4/arch/ppc64/kernel/ppc_ksyms.c linuxppc64-2.4.less_warnings/arch/ppc64/kernel/ppc_ksyms.c --- linuxppc64-2.4/arch/ppc64/kernel/ppc_ksyms.c 2003-06-10 16:34:57.000000000 +0200 +++ linuxppc64-2.4.less_warnings/arch/ppc64/kernel/ppc_ksyms.c 2003-08-17 14:39:31.000000000 +0200 @@ -81,8 +81,8 @@ extern struct pci_dev * iSeries_vio_dev; #ifdef CONFIG_SHARED_MEMORY_ADDRESSING extern void shared_malloc(unsigned long); extern void shared_free(void *); -extern int shared_task_mark(); -extern int shared_task_unmark(); +extern int shared_task_mark(void); +extern int shared_task_unmark(void); #endif EXPORT_SYMBOL(do_signal); diff -p -purNX /suse/olh/kernel/kernel_exclude.txt linuxppc64-2.4/arch/ppc64/kernel/prom.c linuxppc64-2.4.less_warnings/arch/ppc64/kernel/prom.c --- linuxppc64-2.4/arch/ppc64/kernel/prom.c 2003-06-10 16:34:58.000000000 +0200 +++ linuxppc64-2.4.less_warnings/arch/ppc64/kernel/prom.c 2003-08-17 14:37:06.000000000 +0200 @@ -168,7 +168,6 @@ char *of_stdout_device = 0; extern struct rtas_t rtas; extern unsigned long klimit; -extern unsigned long embedded_sysmap_end; extern struct lmb lmb; #ifdef CONFIG_MSCHUNKS extern struct msChunks msChunks; @@ -363,7 +362,7 @@ prom_initialize_naca(unsigned long mem) * d-cache and i-cache sizes... -Peter */ if ( num_cpus == 1 ) { - u32 size, lsize, sets; + u32 size, lsize; call_prom(RELOC("getprop"), 4, 1, node, RELOC("d-cache-size"), @@ -631,7 +630,6 @@ prom_instantiate_rtas(void) unsigned long offset = reloc_offset(); struct prom_t *_prom = PTRRELOC(&prom); struct rtas_t *_rtas = PTRRELOC(&rtas); - struct naca_struct *_naca = RELOC(naca); struct systemcfg *_systemcfg = RELOC(systemcfg); ihandle prom_rtas; u32 getprop_rval; @@ -1060,7 +1058,6 @@ prom_hold_cpus(unsigned long mem) unsigned long *spinloop = __v2a(&__secondary_hold_spinloop); unsigned long *acknowledge = __v2a(&__secondary_hold_acknowledge); unsigned long secondary_hold = (unsigned long)__v2a(*PTRRELOC((unsigned long *)__secondary_hold)); - struct naca_struct *_naca = RELOC(naca); struct systemcfg *_systemcfg = RELOC(systemcfg); struct paca_struct *_xPaca = PTRRELOC(&paca[0]); struct prom_t *_prom = PTRRELOC(&prom); @@ -1359,7 +1356,6 @@ prom_init(unsigned long r3, unsigned lon char *p, *d; unsigned long phys; u32 getprop_rval; - struct naca_struct *_naca = RELOC(naca); struct systemcfg *_systemcfg = RELOC(systemcfg); struct paca_struct *_xPaca = PTRRELOC(&paca[0]); struct prom_t *_prom = PTRRELOC(&prom); @@ -1367,9 +1363,6 @@ prom_init(unsigned long r3, unsigned lon /* Default machine type. */ _systemcfg->platform = PLATFORM_PSERIES; - /* Reset klimit to take into account the embedded system map */ - if (RELOC(embedded_sysmap_end)) - RELOC(klimit) = __va(PAGE_ALIGN(RELOC(embedded_sysmap_end))); /* Get a handle to the prom entry point before anything else */ _prom->entry = pp; @@ -2425,7 +2418,7 @@ print_properties(struct device_node *np) void __init -abort() +abort(void) { #ifdef CONFIG_XMON xmon(NULL); diff -p -purNX /suse/olh/kernel/kernel_exclude.txt linuxppc64-2.4/arch/ppc64/kernel/setup.c linuxppc64-2.4.less_warnings/arch/ppc64/kernel/setup.c --- linuxppc64-2.4/arch/ppc64/kernel/setup.c 2003-08-15 19:09:33.000000000 +0200 +++ linuxppc64-2.4.less_warnings/arch/ppc64/kernel/setup.c 2003-08-17 14:38:27.000000000 +0200 @@ -150,7 +150,7 @@ void setup_system(unsigned long r3, unsi printk("-----------------------------------------------------\n"); printk("naca = 0x%p\n", naca); printk("naca->pftSize = 0x%lx\n", naca->pftSize); - printk("naca->paca = 0x%lx\n\n", naca->paca); + printk("naca->paca = 0x%p\n\n", naca->paca); printk("systemcfg = 0x%p\n", systemcfg); printk("systemcfg->platform = 0x%x\n", systemcfg->platform); printk("systemcfg->processor = 0x%x\n", systemcfg->processor); @@ -332,7 +332,6 @@ struct seq_operations cpuinfo_op = { void parse_cmd_line(unsigned long r3, unsigned long r4, unsigned long r5, unsigned long r6, unsigned long r7) { - struct device_node *chosen; char *p; #ifdef CONFIG_BLK_DEV_INITRD @@ -375,8 +374,7 @@ void parse_cmd_line(unsigned long r3, un "AUTOCONSOLE console=%s %s", val, cmd_line); memcpy(cmd_line, tmp_cmd_line, 512); - printk("console= not found, add console=%s\ncmd_line is now %s\n", - val, cmd_line); + printk("console= not found, add console=%s\n", val); } } } @@ -406,6 +404,7 @@ void parse_cmd_line(unsigned long r3, un } +#if 0 char *bi_tag2str(unsigned long tag) { switch (tag) { @@ -427,6 +426,7 @@ char *bi_tag2str(unsigned long tag) return "BI_UNKNOWN"; } } +#endif int parse_bootinfo(void) { diff -p -purNX /suse/olh/kernel/kernel_exclude.txt linuxppc64-2.4/arch/ppc64/mm/init.c linuxppc64-2.4.less_warnings/arch/ppc64/mm/init.c --- linuxppc64-2.4/arch/ppc64/mm/init.c 2003-06-10 16:34:59.000000000 +0200 +++ linuxppc64-2.4.less_warnings/arch/ppc64/mm/init.c 2003-08-17 15:12:23.000000000 +0200 @@ -30,6 +30,7 @@ #include #include #include +#include #include #include #include @@ -682,7 +683,6 @@ void *shared_malloc(unsigned long size) void shared_free(void *addr) { struct vm_struct **p, *tmp; - unsigned long size = 0; if (!addr) return; @@ -693,7 +693,7 @@ void shared_free(void *addr) { } spin_lock(&shared_malloc_lock); - printk("shared_free: addr = 0x%lx\n", addr); + printk("shared_free: addr = 0x%p\n", addr); /* Scan the memory list for an entry matching * the address to be freed, get the size (in bytes) @@ -755,14 +755,14 @@ static struct vm_struct *get_shared_area return area; } -int shared_task_mark() { +int shared_task_mark(void) { current->thread.flags |= PPC_FLAG_SHARED; printk("current->thread.flags = 0x%lx\n", current->thread.flags); return 0; } -int shared_task_unmark() { +int shared_task_unmark(void) { if(current->thread.flags & PPC_FLAG_SHARED) { current->thread.flags &= (~PPC_FLAG_SHARED); return 0; -- USB is for mice, FireWire is for men! sUse lINUX ag, n?RNBERG ** Sent via the linuxppc64-dev mail list. See http://lists.linuxppc.org/ From olh at suse.de Thu Aug 21 07:41:14 2003 From: olh at suse.de (Olaf Hering) Date: Wed, 20 Aug 2003 23:41:14 +0200 Subject: possible deadlock in pipes Message-ID: <20030820214114.GA20395@suse.de> I see random dead locks in pipe_wait() on power4 (p630, p650). I dont have a simple testcase to trigger it. The userland code its either 32bit or 64bit, new or (very) old. It happens with 2.4.19 and with 2.4.21. This patch seems to fix it, maybe it is only a workaround. Is the 2.4 pipe code supposed to work on power4 (enough sync accross cpus etc.)? diff -p -purN linux-2.4.21/arch/ppc64/kernel/semaphore.c linux-2.4.21.ppc64/arch/ppc64/kernel/semaphore.c --- linux-2.4.21/arch/ppc64/kernel/semaphore.c 2002-08-03 02:39:43.000000000 +0200 +++ linux-2.4.21.ppc64/arch/ppc64/kernel/semaphore.c 2003-08-09 19:11:32.000000000 +0200 @@ -34,6 +34,11 @@ static inline int __sem_update_count(str { int old_count, tmp; + /* make the update visible to others + * should fix races in pipes + */ + wmb(); + __asm__ __volatile__("\n" "1: lwarx %0,0,%3\n" " srawi %1,%0,31\n" On Tue, Aug 05, Olaf Hering wrote: > The find, sed and rpm2cpio hangs since a hour or two. No idea if I got that right, sem.count is always 1, the inodes differ. ************************************************************************ Stack traceback for pid 11015 0xc000000073324000 00011015 00010992 0 003 stop 0xc0000000733245d8 find SP(esp) PC(eip) Function(args) 0xc000000073327810 0x0000000000000000 NO_SYMBOL 0xc0000000733278a0 0xc00000000005bdd4 .do_schedule +0x258 0xc000000073327950 0xc00000000001a624 .__down +0xe8 0xc000000073327a20 0xc0000000000bb148 .pipe_wait +0x104 0xc000000073327b00 0xc0000000000bbf50 .pipe_write +0x4a0 0xc000000073327bc0 0xc0000000000a8158 .sys_write +0xe4 0xc000000073327c60 0xc0000000000101a8 .ret_from_syscall_1 [exception: c00:(System Call) regs 0xc000000073327cd0] nip:[0xe014a9ac] gpr[1]:[0x7fffddc0] kdb: Not a kernel-space address 0x1ff7fffddd0 [0]kdb> mds c000000073327950 0xc000000073327950 c000000073327a20 #...s2z 0xc000000073327958 c000000003f68000 #....#.. 0xc000000073327960 c00000000001a624 .__down+0xe8 kernel .text 0xc000000000000000 0xc00000000001a53c 0xc00000000001a670 0xc000000073327968 c000000073327970 #...s2yp 0xc000000073327970 c000000073327a20 #...s2z 0xc000000073327978 0000007fe0020000 ....#... 0xc000000073327980 c00000000005bde0 .do_schedule+0x264 kernel .text 0xc000000000000000 0xc00000000005bb7c 0xc00000000005bfa8 0xc000000073327988 0000000000001000 ........ 0xc000000073327990 0000000000001000 ........ 0xc000000073327998 0000000000001000 ........ 0xc0000000733279a0 c0000001afe7eb00 #...###. 0xc0000000733279a8 c0000001afe7ebc8 #...#### 0xc0000000733279b0 c000000073327a20 #...s2z 0xc0000000733279b8 c000000183ff16a8 #....#.# 0xc0000000733279c0 0000000100000000 ........ 0xc0000000733279c8 c000000073324000 #...s2 at . 0xc0000000733279d0 c0000001afe7ebd8 #...#### 0xc0000000733279d8 c0000001afe7ebd8 #...#### 0xc0000000733279e0 0000000000000000 ........ 0xc0000000733279e8 c000000000703000 irq_dir+0x128 kernel .bss 0xc000000000701000 0xc000000000702ed8 0xc000000000703ed8 0xc0000000733279f0 c000000073327a80 #...s2z. 0xc0000000733279f8 0000000000001000 ........ 0xc000000073327a00 0000000000001000 ........ 0xc000000073327a08 0000000000001000 ........ 0xc000000073327a10 c0000001afe7eb00 #...###. 0xc000000073327a18 c0000001afe7ebc8 #...#### struct inode [0]kdb> mds c0000001afe7eb00 0xc0000001afe7eb00 c0000001afe7eb00 #...###. 0xc0000001afe7eb08 c0000001afe7eb00 #...###. 0xc0000001afe7eb10 c0000001965f1510 #...._.. 0xc0000001afe7eb18 c0000001b7ca4c10 #...##L. 0xc0000001afe7eb20 c0000000017bac40 #....{#@ 0xc0000001afe7eb28 c0000000017bac40 #....{#@ 0xc0000001afe7eb30 c0000001afe7eb30 #...###0 0xc0000001afe7eb38 c0000001afe7eb30 #...###0 0xc0000001afe7eb40 c0000001afe7eb40 #...###@ 0xc0000001afe7eb48 c0000001afe7eb40 #...###@ 0xc0000001afe7eb50 0000000000fc5c17 .....#\. 0xc0000001afe7eb58 0000000100060000 ........ 0xc0000001afe7eb60 0000118000000000 ........ 0xc0000001afe7eb68 0000000000000001 ........ 0xc0000001afe7eb70 0000000000000000 ........ 0xc0000001afe7eb78 0000000000000000 ........ 0xc0000001afe7eb80 0000000000000000 ........ 0xc0000001afe7eb88 000000003f2fd06e ....?/#n 0xc0000001afe7eb90 000000003f2fb1de ....?/## 0xc0000001afe7eb98 000000003f2fb1de ....?/## 0xc0000001afe7eba0 0000000a00000000 ........ 0xc0000001afe7eba8 0000000000001000 ........ 0xc0000001afe7ebb0 0000000000000000 ........ 0xc0000001afe7ebb8 0000000008708c5e .....p.^ 0xc0000001afe7ebc0 0000000000000000 ........ 0xc0000001afe7ebc8 0000000100000000 ........ .sem 0xc0000001afe7ebd0 0000000000000000 ........ 0xc0000001afe7ebd8 c0000000733279d0 #...s2y# 0xc0000001afe7ebe0 c0000000733279d0 #...s2y# 0xc0000001afe7ebe8 0000000000000000 ........ 0xc0000001afe7ebf0 0000000000000000 ........ 0xc0000001afe7ebf8 c0000001afe7ebf8 #...#### 0xc0000001afe7ec00 c0000001afe7ebf8 #...#### 0xc0000001afe7ec08 0000000100000000 ........ 0xc0000001afe7ec10 0000000000000000 ........ 0xc0000001afe7ec18 c0000001afe7ec18 #...###. 0xc0000001afe7ec20 c0000001afe7ec18 #...###. 0xc0000001afe7ec28 c000000000823548 empty_iops.2 kernel .bss 0xc000000000701000 0xc000000000823548 0xc0000000008235e8 0xc0000001afe7ec30 c0000000004359f0 rdwr_pipe_fops kernel .data 0xc0000000003d7000 0xc0000000004359f0 0xc000000000435ab0 0xc0000001afe7ec38 c0000003ffcb4800 #...##H. ************************************************************************ Stack traceback for pid 2628 0xc00000017d6bc000 00002628 00000894 0 002 stop 0xc00000017d6bc5d8 sed SP(esp) PC(eip) Function(args) 0xc00000017d6bf810 0x0000000000000000 NO_SYMBOL 0xc00000017d6bf8a0 0xc00000000005bdd4 .do_schedule +0x258 0xc00000017d6bf950 0xc00000000001a624 .__down +0xe8 0xc00000017d6bfa20 0xc0000000000bb148 .pipe_wait +0x104 0xc00000017d6bfb00 0xc0000000000bbf50 .pipe_write +0x4a0 0xc00000017d6bfbc0 0xc0000000000a8158 .sys_write +0xe4 0xc00000017d6bfc60 0xc0000000000101a8 .ret_from_syscall_1 [exception: c00:(System Call) regs 0xc00000017d6bfcd0] nip:[0xe014a9ac] gpr[1]:[0x7fffd730] kdb: Not a kernel-space address 0x1ff7fffd740 [0]kdb> mds c00000017d6bf950 0xc00000017d6bf950 c00000017d6bfa20 #...}k# 0xc00000017d6bf958 c000000003f6c000 #....##. 0xc00000017d6bf960 c00000000001a624 .__down+0xe8 kernel .text 0xc000000000000000 0xc00000000001a53c 0xc00000000001a670 0xc00000017d6bf968 c00000017d6bf970 #...}k#p 0xc00000017d6bf970 c00000017d6bfa20 #...}k# 0xc00000017d6bf978 0000007fe0021000 ....#... 0xc00000017d6bf980 c00000000005bde0 .do_schedule+0x264 kernel .text 0xc000000000000000 0xc00000000005bb7c 0xc00000000005bfa8 0xc00000017d6bf988 0000000000001000 ........ 0xc00000017d6bf990 0000000000001000 ........ 0xc00000017d6bf998 0000000000001000 ........ 0xc00000017d6bf9a0 c0000001817f0180 #....... 0xc00000017d6bf9a8 c0000001817f0248 #......H 0xc00000017d6bf9b0 c00000017d6bfa20 #...}k# 0xc00000017d6bf9b8 c000000000703000 irq_dir+0x128 kernel .bss 0xc000000000701000 0xc000000000702ed8 0xc000000000703ed8 0xc00000017d6bf9c0 0000000100000000 ........ 0xc00000017d6bf9c8 c00000017d6bc000 #...}k#. 0xc00000017d6bf9d0 c0000001817f0258 #......X 0xc00000017d6bf9d8 c0000001817f0258 #......X 0xc00000017d6bf9e0 0000000000000000 ........ 0xc00000017d6bf9e8 c00000008cd21790 #....#.. 0xc00000017d6bf9f0 c00000017d6bfa80 #...}k#. 0xc00000017d6bf9f8 0000000000001000 ........ 0xc00000017d6bfa00 0000000000001000 ........ 0xc00000017d6bfa08 0000000000001000 ........ 0xc00000017d6bfa10 c0000001817f0180 #....... 0xc00000017d6bfa18 c0000001817f0248 #......H struct inode [0]kdb> mds c0000001817f0180 0xc0000001817f0180 c0000001817f0180 #....... 0xc0000001817f0188 c0000001817f0180 #....... 0xc0000001817f0190 c0000001817f0510 #....... 0xc0000001817f0198 c00000017d36c490 #...}6#. 0xc0000001817f01a0 c00000017ff8c2a0 #....#? 0xc0000001817f01a8 c00000017ff8c2a0 #....#? 0xc0000001817f01b0 c0000001817f01b0 #......# 0xc0000001817f01b8 c0000001817f01b0 #......# 0xc0000001817f01c0 c0000001817f01c0 #......# 0xc0000001817f01c8 c0000001817f01c0 #......# 0xc0000001817f01d0 000000000059cc18 .....Y#. 0xc0000001817f01d8 0000000100060000 ........ 0xc0000001817f01e0 0000118000000000 ........ 0xc0000001817f01e8 0000000000000001 ........ 0xc0000001817f01f0 0000000000000000 ........ 0xc0000001817f01f8 0000000000000000 ........ 0xc0000001817f0200 0000000000000000 ........ 0xc0000001817f0208 000000003f2edeab ....?.# 0xc0000001817f0210 000000003f2edea9 ....?.# 0xc0000001817f0218 000000003f2edea9 ....?.# 0xc0000001817f0220 0000000a00000000 ........ 0xc0000001817f0228 0000000000001000 ........ 0xc0000001817f0230 0000000000000000 ........ 0xc0000001817f0238 0000000000000000 ........ 0xc0000001817f0240 0000000000000000 ........ 0xc0000001817f0248 0000000100000000 ........ .sem 0xc0000001817f0250 0000000000000000 ........ 0xc0000001817f0258 c00000017d6bf9d0 #...}k## 0xc0000001817f0260 c00000017d6bf9d0 #...}k## 0xc0000001817f0268 0000000000000000 ........ 0xc0000001817f0270 0000000000000000 ........ 0xc0000001817f0278 c0000001817f0278 #......x 0xc0000001817f0280 c0000001817f0278 #......x 0xc0000001817f0288 0000000100000000 ........ 0xc0000001817f0290 0000000000000000 ........ 0xc0000001817f0298 c0000001817f0298 #....... 0xc0000001817f02a0 c0000001817f0298 #....... 0xc0000001817f02a8 c000000000823548 empty_iops.2 kernel .bss 0xc000000000701000 0xc000000000823548 0xc0000000008235e8 0xc0000001817f02b0 c0000000004359f0 rdwr_pipe_fops kernel .data 0xc0000000003d7000 0xc0000000004359f0 0xc000000000435ab0 0xc0000001817f02b8 c0000003ffcb4800 #...##H. ************************************************************************ Stack traceback for pid 22801 0xc0000000f8350000 00022801 00022797 0 002 stop 0xc0000000f83505d8 rpm2cpio SP(esp) PC(eip) Function(args) 0xc0000000f8353810 0x0000000000000000 NO_SYMBOL 0xc0000000f83538a0 0xc00000000005bdd4 .do_schedule +0x258 0xc0000000f8353950 0xc00000000001a624 .__down +0xe8 0xc0000000f8353a20 0xc0000000000bb148 .pipe_wait +0x104 0xc0000000f8353b00 0xc0000000000bbe80 .pipe_write +0x3d0 0xc0000000f8353bc0 0xc0000000000a8158 .sys_write +0xe4 0xc0000000f8353c60 0xc0000000000101a8 .ret_from_syscall_1 [exception: c00:(System Call) regs 0xc0000000f8353cd0] nip:[0x1007f7ac] gpr[1]:[0xffffa888] kdb: Not a kernel-space address 0xffffa898 [0]kdb> mds c0000000f8353950 0xc0000000f8353950 c0000000f8353a20 #...#5: 0xc0000000f8353958 c000000003f6c000 #....##. 0xc0000000f8353960 c00000000001a624 .__down+0xe8 kernel .text 0xc000000000000000 0xc00000000001a53c 0xc00000000001a670 0xc0000000f8353968 c0000000f8353970 #...#59p 0xc0000000f8353970 c0000000f8353a20 #...#5: 0xc0000000f8353978 c0000000f8353980 #...#59. 0xc0000000f8353980 c00000000005bde0 .do_schedule+0x264 kernel .text 0xc000000000000000 0xc00000000005bb7c 0xc00000000005bfa8 0xc0000000f8353988 0000000000002000 ...... . 0xc0000000f8353990 c00000000005a7c8 .try_to_wake_up+0x2b4 kernel .text 0xc000000000000000 0xc00000000005a514 0xc00000000005a88c 0xc0000000f8353998 0000000000000000 ........ 0xc0000000f83539a0 c0000000000bbcd4 .pipe_write+0x224 kernel .text 0xc000000000000000 0xc0000000000bbab0 0xc0000000000bbfe0 0xc0000000f83539a8 0000000020000000 .... ... 0xc0000000f83539b0 0000000024044480 ....$.D. 0xc0000000f83539b8 0000000000000000 ........ 0xc0000000f83539c0 0000000100000000 ........ 0xc0000000f83539c8 c0000000f8350000 #...#5.. 0xc0000000f83539d0 c0000000962915d8 #....).# 0xc0000000f83539d8 c0000000962915d8 #....).# 0xc0000000f83539e0 0000000000000000 ........ 0xc0000000f83539e8 c0000000265ca8c0 #...&\## 0xc0000000f83539f0 9000000000001032 .......2 0xc0000000f83539f8 0000000000002000 ...... . 0xc0000000f8353a00 0000000000000800 ........ 0xc0000000f8353a08 0000000000000800 ........ 0xc0000000f8353a10 c000000096291500 #....).. 0xc0000000f8353a18 c0000000962915c8 #....).# struct inode [0]kdb> mds c000000096291500 0xc000000096291500 c000000096291500 #....).. 0xc000000096291508 c000000096291500 #....).. 0xc000000096291510 c00000004d1f1890 #...M... 0xc000000096291518 c0000000244e2490 #...$N$. 0xc000000096291520 c000000091e6b7e0 #....## 0xc000000096291528 c000000091e6b7e0 #....## 0xc000000096291530 c000000096291530 #....).0 0xc000000096291538 c000000096291530 #....).0 0xc000000096291540 c000000096291540 #....).@ 0xc000000096291548 c000000096291540 #....).@ 0xc000000096291550 000000000023310c .....#1. 0xc000000096291558 0000000100060000 ........ 0xc000000096291560 0000118000000000 ........ 0xc000000096291568 0000000000000001 ........ 0xc000000096291570 0000000000000000 ........ 0xc000000096291578 0000000000000000 ........ 0xc000000096291580 0000000000000000 ........ 0xc000000096291588 000000003f2eab79 ....?.#y 0xc000000096291590 000000003f2eab79 ....?.#y 0xc000000096291598 000000003f2eab79 ....?.#y 0xc0000000962915a0 0000000a00000000 ........ 0xc0000000962915a8 0000000000001000 ........ 0xc0000000962915b0 0000000000000000 ........ 0xc0000000962915b8 00000000013d4ec2 .....=N# 0xc0000000962915c0 0000000000000000 ........ 0xc0000000962915c8 0000000100000000 ........ .sem 0xc0000000962915d0 0000000000000000 ........ 0xc0000000962915d8 c0000000f83539d0 #...#59# 0xc0000000962915e0 c0000000f83539d0 #...#59# 0xc0000000962915e8 0000000000000000 ........ 0xc0000000962915f0 0000000000000000 ........ 0xc0000000962915f8 c0000000962915f8 #....).# 0xc000000096291600 c0000000962915f8 #....).# 0xc000000096291608 0000000100000000 ........ 0xc000000096291610 0000000000000000 ........ 0xc000000096291618 c000000096291618 #....).. 0xc000000096291620 c000000096291618 #....).. 0xc000000096291628 c000000000823548 empty_iops.2 kernel .bss 0xc000000000701000 0xc000000000823548 0xc0000000008235e8 0xc000000096291630 c0000000004359f0 rdwr_pipe_fops kernel .data 0xc0000000003d7000 0xc0000000004359f0 0xc000000000435ab0 0xc000000096291638 c0000003ffcb4800 #...##H. 0xc000000096291640 0000000000000000 ........ 0xc000000096291648 c000000096291648 #....).H 0xc000000096291650 c000000096291648 #....).H 0xc000000096291658 0000000000000000 ........ 0xc000000096291660 c000000096291668 #....).h 0xc000000096291668 c000000096291668 #....).h 0xc000000096291670 c000000096291668 #....).h 0xc000000096291678 c000000096291678 #....).x -- USB is for mice, FireWire is for men! sUse lINUX ag, n?RNBERG ** Sent via the linuxppc64-dev mail list. See http://lists.linuxppc.org/ From anton at samba.org Fri Aug 22 07:54:33 2003 From: anton at samba.org (Anton Blanchard) Date: Fri, 22 Aug 2003 07:54:33 +1000 Subject: possible deadlock in pipes In-Reply-To: <20030820214114.GA20395@suse.de> References: <20030820214114.GA20395@suse.de> Message-ID: <20030821215433.GE29476@krispykreme> Hi Olaf, > I see random dead locks in pipe_wait() on power4 (p630, p650). > I dont have a simple testcase to trigger it. The userland code its > either 32bit or 64bit, new or (very) old. > It happens with 2.4.19 and with 2.4.21. > > This patch seems to fix it, maybe it is only a workaround. Is the 2.4 > pipe code supposed to work on power4 (enough sync accross cpus etc.)? How hard is it to hit? I think we should be using set_task_state() which includes a memory barrier. I also updated the other open coded statements to use __set_task_state. Finally I got rid of some redundant wmb()s and added unlikely() to force the slow path out of line Note in 2.5 we have each way barriers on our atomics that return values (like atomic_dec_and_test). It doesnt look like we have that in 2.4. Anton ===== arch/ppc64/kernel/semaphore.c 1.2 vs edited ===== --- 1.2/arch/ppc64/kernel/semaphore.c Mon Apr 8 15:56:10 2002 +++ edited/arch/ppc64/kernel/semaphore.c Fri Aug 22 07:11:26 2003 @@ -75,9 +75,8 @@ struct task_struct *tsk = current; DECLARE_WAITQUEUE(wait, tsk); - tsk->state = TASK_UNINTERRUPTIBLE; + __set_task_state(tsk, TASK_UNINTERRUPTIBLE); add_wait_queue_exclusive(&sem->wait, &wait); - smp_wmb(); /* * Try to get the semaphore. If the count is > 0, then we've @@ -87,10 +86,10 @@ */ while (__sem_update_count(sem, -1) <= 0) { schedule(); - tsk->state = TASK_UNINTERRUPTIBLE; + set_task_state(tsk, TASK_UNINTERRUPTIBLE); } remove_wait_queue(&sem->wait, &wait); - tsk->state = TASK_RUNNING; + __set_task_state(tsk, TASK_RUNNING); /* * If there are any more sleepers, wake one of them up so @@ -106,9 +105,8 @@ struct task_struct *tsk = current; DECLARE_WAITQUEUE(wait, tsk); - tsk->state = TASK_INTERRUPTIBLE; + __set_task_state(tsk, TASK_INTERRUPTIBLE); add_wait_queue_exclusive(&sem->wait, &wait); - smp_wmb(); while (__sem_update_count(sem, -1) <= 0) { if (signal_pending(current)) { @@ -122,10 +120,11 @@ break; } schedule(); - tsk->state = TASK_INTERRUPTIBLE; + set_task_state(tsk, TASK_INTERRUPTIBLE); } - tsk->state = TASK_RUNNING; remove_wait_queue(&sem->wait, &wait); + __set_task_state(tsk, TASK_RUNNING); + wake_up(&sem->wait); return retval; } ===== include/asm-ppc64/semaphore.h 1.5 vs edited ===== --- 1.5/include/asm-ppc64/semaphore.h Mon Feb 17 14:22:35 2003 +++ edited/include/asm-ppc64/semaphore.h Fri Aug 22 07:26:44 2003 @@ -82,9 +82,8 @@ /* * Try to get the semaphore, take the slow path if we fail. */ - if (atomic_dec_return(&sem->count) < 0) + if (unlikely(atomic_dec_return(&sem->count) < 0)) __down(sem); - smp_wmb(); } static inline int down_interruptible(struct semaphore * sem) @@ -96,23 +95,18 @@ #endif might_sleep(); - if (atomic_dec_return(&sem->count) < 0) + if (unlikely(atomic_dec_return(&sem->count) < 0)) ret = __down_interruptible(sem); - smp_wmb(); return ret; } static inline int down_trylock(struct semaphore * sem) { - int ret; - #ifdef WAITQUEUE_DEBUG CHECK_MAGIC(sem->__magic); #endif - ret = atomic_dec_if_positive(&sem->count) < 0; - smp_wmb(); - return ret; + return atomic_dec_if_positive(&sem->count) < 0; } static inline void up(struct semaphore * sem) @@ -121,8 +115,7 @@ CHECK_MAGIC(sem->__magic); #endif - smp_wmb(); - if (atomic_inc_return(&sem->count) <= 0) + if (unlikely(atomic_inc_return(&sem->count) <= 0)) __up(sem); } ** Sent via the linuxppc64-dev mail list. See http://lists.linuxppc.org/ From anton at samba.org Fri Aug 22 08:39:17 2003 From: anton at samba.org (Anton Blanchard) Date: Fri, 22 Aug 2003 08:39:17 +1000 Subject: possible deadlock in pipes In-Reply-To: <20030821215433.GE29476@krispykreme> References: <20030820214114.GA20395@suse.de> <20030821215433.GE29476@krispykreme> Message-ID: <20030821223917.GF29476@krispykreme> > How hard is it to hit? I think we should be using set_task_state() > which includes a memory barrier. I also updated the other open coded > statements to use __set_task_state. Finally I got rid of some redundant > wmb()s and added unlikely() to force the slow path out of line FYI one issue with our semaphonres is that they are unfair. The x86 semaphores force everyone into the slow path once there are waiters which serialises them. Our semaphores dont so you could have one task stuck in the slow path while another one continuously drops and takes the lock faster than the other one can wake up. Anton ** Sent via the linuxppc64-dev mail list. See http://lists.linuxppc.org/ From olof at austin.ibm.com Tue Aug 26 06:18:44 2003 From: olof at austin.ibm.com (olof at austin.ibm.com) Date: Mon, 25 Aug 2003 15:18:44 -0500 (CDT) Subject: [PATCH] [ACENIC] Add check for EEH slot frozen in watchdog handler Message-ID: The below patch adds functionality for IBM pSeries machines, where a PCI slot can be frozen when the hardware detects a problem with the board (or a card-initiated read/write to a protected/nonexistent memory area). The way the EEH handling is architected in ppc64 is by hooking into the read{b,w,l} macros and friends. The watchdog handler doesn't ever go down that path, so there were two choices available: 1. Add a piece of code that will read a register on the board 2. Add an explicit check (this is somewhat expensive, computation-wise). (2) was chosen since this is not in a common path, and it would seem pretty random to just read any register (besides the risk that someone would ask "Why's this here?" and rip it out later. :-) Patch is against file revision 1.27 in BK, it should apply to 2.4.22 with a couple of lines offset. Thanks, Olof Olof Johansson Office: 4E002/905 pSeries Linux Development IBM Systems Group Email: olof at austin.ibm.com Phone: 512-838-9858 All opinions are my own and not those of IBM --- linux-2.4/drivers/net/acenic.c.orig 2003-08-25 15:04:37.000000000 -0500 +++ linux-2.4/drivers/net/acenic.c 2003-08-25 15:05:25.000000000 -0500 @@ -67,6 +67,10 @@ #include #include +#ifdef CONFIG_PPC_PSERIES +#include +#endif + #if defined(CONFIG_VLAN_8021Q) || defined(CONFIG_VLAN_8021Q_MODULE) #include #endif @@ -1867,6 +1871,15 @@ static void ace_watchdog(struct net_devi dev->name); netif_wake_queue(dev); } + +#ifdef CONFIG_PPC_PSERIES + /* IBM pSeries (ppc64) has a feature called EEH, in which a slot is + * frozen if the bridge detects a parity error or DMA access violation. + * It's possible that the watchdog triggers because the slot got frozen, + * verify that this is not the case. + */ + eeh_check_failure(regs, 0); +#endif } ** Sent via the linuxppc64-dev mail list. See http://lists.linuxppc.org/ From paulus at samba.org Tue Aug 26 21:24:27 2003 From: paulus at samba.org (Paul Mackerras) Date: Tue, 26 Aug 2003 21:24:27 +1000 Subject: ameslab linux-2.4 at 2.4.22 Message-ID: <16203.17259.216711.90413@cargo.ozlabs.ibm.com> I just merged the linux-2.4 tree on ameslab to 2.4.22 and fixed a compile error in arch/ppc64/kernel/sys_ppc32.c. Paul. ** Sent via the linuxppc64-dev mail list. See http://lists.linuxppc.org/ From hollisb at us.ibm.com Wed Aug 27 08:16:25 2003 From: hollisb at us.ibm.com (Hollis Blanchard) Date: Tue, 26 Aug 2003 17:16:25 -0500 Subject: cpus_in_xmon questions Message-ID: Hey, I noticed a build break with CONFIG_SMP off. cpus_in_xmon is only defined if CONFIG_SMP is on... this is the fix. --- drivers/char/hvc_console.c 26 Jun 2003 14:32:53 -0000 1.13 +++ drivers/char/hvc_console.c 26 Aug 2003 21:58:44 -0000 @@ -223,7 +223,7 @@ spin_unlock_irqrestore(&hp->lock, flags); } -#if defined (CONFIG_XMON) +#if defined (CONFIG_XMON) && defined (CONFIG_SMP) extern unsigned long cpus_in_xmon; #else unsigned long cpus_in_xmon=0; Also, what is cpus_in_xmon used for? In xmon/xmon.c, it looks like it's used to prevent a CPU from recursively entering xmon. What could cause that, and would an oops or some sort of message be better there? What prevents a UP CPU from doing the same thing? In hvc_console.c, if any CPU is in xmon, the thread skips polling for any data. Why? Also, the hvc_console.c cpus_in_xmon redefinition looks like a code-cleanliness feature, but if it's made const the compiler will optimize it out altogether: --- drivers/char/hvc_console.c 26 Jun 2003 14:32:53 -0000 1.13 +++ drivers/char/hvc_console.c 26 Aug 2003 22:14:00 -0000 @@ -223,10 +223,10 @@ spin_unlock_irqrestore(&hp->lock, flags); } -#if defined (CONFIG_XMON) +#if defined (CONFIG_XMON) && defined (CONFIG_SMP) extern unsigned long cpus_in_xmon; #else -unsigned long cpus_in_xmon=0; +const unsigned long cpus_in_xmon=0; #endif -- Hollis Blanchard IBM Linux Technology Center ** Sent via the linuxppc64-dev mail list. See http://lists.linuxppc.org/ From anton at samba.org Wed Aug 27 10:27:31 2003 From: anton at samba.org (Anton Blanchard) Date: Wed, 27 Aug 2003 10:27:31 +1000 Subject: cpus_in_xmon questions In-Reply-To: References: Message-ID: <20030827002731.GA28041@krispykreme> Hi, > Also, what is cpus_in_xmon used for? In xmon/xmon.c, it looks like it's > used to prevent a CPU from recursively entering xmon. What could cause > that, and would an oops or some sort of message be better there? What > prevents a UP CPU from doing the same thing? That area of code should probably be looked over. Entering xmon recursively is bad stuff but we should not lock up silently. > In hvc_console.c, if any CPU is in xmon, the thread skips polling for > any data. Why? Because otherwise both hvc_console and xmon poll for characters. The result is you get maybe every second character through to xmon and every other gets sucked up by hvc_console running on another cpu. Its a hack to use cpus_in_xmon, we should have something more generic so kdb can do the right thing here too. Anton ** Sent via the linuxppc64-dev mail list. See http://lists.linuxppc.org/ From SVakkalankarao at covansys.com Wed Aug 27 17:53:39 2003 From: SVakkalankarao at covansys.com (VAKKALANKA RAO Sridhar) Date: Wed, 27 Aug 2003 13:23:39 +0530 Subject: Websphere on POWER4 Message-ID: <207D6ADFC044A84686D44CA11B297EEA02018AA3@chn-ex02.cvns.corp.covansys.com> Hello, I am trying to install a trial version of Websphere on my p630. My plan is to put a maximum load on the machine as a web server when it is individually running AIX 5.1L and linux-2.6.0-test. My plan is to compare the performance for both installations. I managed to download a trial version of Websphere 4.0 and the binaries are genuinely POWER4 compatible. However, I am not able to execute them as they expect glibc 2.2.5. On my part, I built my toolchain with glibc 2.3.2 after downloading the source code using CVS. Does anybody have Websphere 4.0 for POWER4 that are compatible with glibc 2.3.2? Can someone please tell me how to acquire it? Thanks Sri ** Sent via the linuxppc64-dev mail list. See http://lists.linuxppc.org/ From willschm at us.ibm.com Wed Aug 27 23:56:28 2003 From: willschm at us.ibm.com (Will Schmidt) Date: Wed, 27 Aug 2003 08:56:28 -0500 Subject: cpus_in_xmon questions Message-ID: Hi, Kdb tries to drop all processors into the debugger, and keeps track of the state of each, so only one is the controlling processor, and thus has not run into the problems with hvc_console pulling characters away. > Hi, > > > Also, what is cpus_in_xmon used for? In xmon/xmon.c, it looks like it's > > used to prevent a CPU from recursively entering xmon. What could cause > > that, and would an oops or some sort of message be better there? What > > prevents a UP CPU from doing the same thing? > > That area of code should probably be looked over. Entering xmon > recursively is bad stuff but we should not lock up silently. > > > In hvc_console.c, if any CPU is in xmon, the thread skips polling for > > any data. Why? > > Because otherwise both hvc_console and xmon poll for characters. The > result is you get maybe every second character through to xmon and every > other gets sucked up by hvc_console running on another cpu. > > Its a hack to use cpus_in_xmon, we should have something more generic so > kdb can do the right thing here too. > > Anton > willschm at us.ibm.com Linux on PowerPC-64 Development IBM Rochester ** Sent via the linuxppc64-dev mail list. See http://lists.linuxppc.org/ From linas at austin.ibm.com Thu Aug 28 00:54:57 2003 From: linas at austin.ibm.com (linas at austin.ibm.com) Date: Wed, 27 Aug 2003 09:54:57 -0500 Subject: cpus_in_xmon questions In-Reply-To: ; from willschm@us.ibm.com on Wed, Aug 27, 2003 at 08:56:28AM -0500 References: Message-ID: <20030827095457.A37382@forte.austin.ibm.com> On Wed, Aug 27, 2003 at 08:56:28AM -0500, Will Schmidt wrote: > > Hi, > Kdb tries to drop all processors into the debugger, and keeps track of > the state of each, so only one is the controlling processor, and thus has > not run into the problems with hvc_console pulling characters away. xmon should do something similar. When a machine croaks on one CPU, its often/usually interesting to know what the other CPU's are doing. That is, typically all the cpu's in the complex are involved in some sort lock contention, and its pointless to let the other cpus 'keep going' while one is stopped. --linas ** Sent via the linuxppc64-dev mail list. See http://lists.linuxppc.org/ From anton at samba.org Thu Aug 28 01:10:45 2003 From: anton at samba.org (Anton Blanchard) Date: Thu, 28 Aug 2003 01:10:45 +1000 Subject: cpus_in_xmon questions In-Reply-To: <20030827095457.A37382@forte.austin.ibm.com> References: <20030827095457.A37382@forte.austin.ibm.com> Message-ID: <20030827151045.GA7852@krispykreme> > xmon should do something similar. When a machine croaks on one CPU, its > often/usually interesting to know what the other CPU's are doing. That is, > typically all the cpu's in the complex are involved in some sort lock > contention, and its pointless to let the other cpus 'keep going' while > one is stopped. You can always stop all other cpus if required with ci and jump between them with c0, c1 etc. I disagree its pointless to let the other cpus keep going, Ive debugged problems where the other cpus continue on fine :) I prefer to poke around on the local cpu before doing the IPI to stop all cpus. Its safer that way, and xmon is all about being simple so its hopefully bulletproof. (A number of changes in the ppc64 version have made it less so, but those bits are slowly being fixed) Anton ** Sent via the linuxppc64-dev mail list. See http://lists.linuxppc.org/ From hollisb at us.ibm.com Thu Aug 28 02:37:12 2003 From: hollisb at us.ibm.com (Hollis Blanchard) Date: Wed, 27 Aug 2003 11:37:12 -0500 Subject: cpus_in_xmon questions In-Reply-To: <20030827002731.GA28041@krispykreme> Message-ID: On Tuesday, Aug 26, 2003, at 19:27 US/Central, Anton Blanchard wrote: > >> In hvc_console.c, if any CPU is in xmon, the thread skips polling for >> any data. Why? > > Because otherwise both hvc_console and xmon poll for characters. The > result is you get maybe every second character through to xmon and > every > other gets sucked up by hvc_console running on another cpu. > > Its a hack to use cpus_in_xmon, we should have something more generic > so > kdb can do the right thing here too. How about stopping khvcd entirely while in xmon? I.E. instead of calling schedule_timeout() from khvcd(), make a "static struct timer_list hvc_timer" and add_timer()/schedule()/del_timer() directly in khvcd(). Then xmon could call khvcd_stop/start() functions on enter/exit, which just del_timer/add_timer(&hvc_timer). Or does that rely on too much external working code from xmon? -- Hollis Blanchard IBM Linux Technology Center ** Sent via the linuxppc64-dev mail list. See http://lists.linuxppc.org/ From hollisb at us.ibm.com Thu Aug 28 02:40:40 2003 From: hollisb at us.ibm.com (Hollis Blanchard) Date: Wed, 27 Aug 2003 11:40:40 -0500 Subject: cpus_in_xmon questions In-Reply-To: <20030827002731.GA28041@krispykreme> Message-ID: <31CEB1DB-D8AD-11D7-B5D6-000A95A0560C@us.ibm.com> On Tuesday, Aug 26, 2003, at 19:27 US/Central, Anton Blanchard wrote: > >> Also, what is cpus_in_xmon used for? In xmon/xmon.c, it looks like >> it's >> used to prevent a CPU from recursively entering xmon. What could cause >> that, and would an oops or some sort of message be better there? What >> prevents a UP CPU from doing the same thing? > > That area of code should probably be looked over. Entering xmon > recursively is bad stuff but we should not lock up silently. You've seen it happen? How? And could it happen on UP? AFAICS only SMP is guarded against the possibility. -- Hollis Blanchard IBM Linux Technology Center ** Sent via the linuxppc64-dev mail list. See http://lists.linuxppc.org/ From olof at austin.ibm.com Thu Aug 28 05:48:31 2003 From: olof at austin.ibm.com (Olof Johansson) Date: Wed, 27 Aug 2003 14:48:31 -0500 Subject: [PATCH] Specify right base address/IRQ for ttyS0{2,3} Message-ID: <3F4D0B0F.3070701@austin.ibm.com> Attached patch sets valid default values for the 3rd and 4th serial port on pSeries systems. On the systems I have checked, they're always at 0x890/0xf and 0x898/0xe. I suppose that in a perfect world we'd get the values out of the device tree, but with the current serial code it'll be more work that it's potentially worth. Patch is against ~2.4.21, I'll check it into 2.4/2.5 BK tomorrow unless I get suggestions for changes. -Olof -- Olof Johansson Office: 4E002/905 pSeries Linux Development IBM Systems Group Email: olof at austin.ibm.com Phone: 512-838-9858 All opinions are my own and not those of IBM -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: serial-patch Url: http://ozlabs.org/pipermail/linuxppc64-dev/attachments/20030827/0b5fbe39/attachment.txt From hollisb at us.ibm.com Thu Aug 28 06:25:41 2003 From: hollisb at us.ibm.com (Hollis Blanchard) Date: Wed, 27 Aug 2003 15:25:41 -0500 Subject: [PATCH] Specify right base address/IRQ for ttyS0{2,3} In-Reply-To: <3F4D0B0F.3070701@austin.ibm.com> Message-ID: On Wednesday, Aug 27, 2003, at 14:48 US/Central, Olof Johansson wrote: > Attached patch sets valid default values for the 3rd and 4th serial > port on pSeries systems. While you're at it, what about removing the ASYNC_SKIP_TEST flag? This could cause phantom serial port detection. See http://lists.linuxppc.org/linuxppc-dev/200308/msg00090.html for details... -- Hollis Blanchard IBM Linux Technology Center ** Sent via the linuxppc64-dev mail list. See http://lists.linuxppc.org/ From olof at austin.ibm.com Thu Aug 28 07:06:19 2003 From: olof at austin.ibm.com (Olof Johansson) Date: Wed, 27 Aug 2003 16:06:19 -0500 Subject: [PATCH] Specify right base address/IRQ for ttyS0{2,3} In-Reply-To: References: Message-ID: <3F4D1D4B.6010701@austin.ibm.com> Hollis Blanchard wrote: > While you're at it, what about removing the ASYNC_SKIP_TEST flag? This > could cause phantom serial port detection. See > http://lists.linuxppc.org/linuxppc-dev/200308/msg00090.html for details... Good idea, thanks for catching that. Updated patch attached. I couldn't find any reason to keep the STD_COM4_FLAGS, I couldn't find any external references to them. Thanks, -Olof -- Olof Johansson Office: 4E002/905 pSeries Linux Development IBM Systems Group Email: olof at austin.ibm.com Phone: 512-838-9858 All opinions are my own and not those of IBM -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: serial-patch2 Url: http://ozlabs.org/pipermail/linuxppc64-dev/attachments/20030827/823b11d1/attachment.txt From linas at austin.ibm.com Thu Aug 28 09:57:06 2003 From: linas at austin.ibm.com (linas at austin.ibm.com) Date: Wed, 27 Aug 2003 18:57:06 -0500 Subject: cpus_in_xmon questions In-Reply-To: ; from hollisb@us.ibm.com on Wed, Aug 27, 2003 at 11:37:12AM -0500 References: <20030827002731.GA28041@krispykreme> Message-ID: <20030827185706.A9162@forte.austin.ibm.com> On Wed, Aug 27, 2003 at 11:37:12AM -0500, Hollis Blanchard wrote: > Then xmon could call khvcd_stop/start() functions on enter/exit, which > just del_timer/add_timer(&hvc_timer). > > Or does that rely on too much external working code from xmon? Why, just last week, I worked a bug involving corrupted timers. All the cpu's had spinlocked or otherwise deadlocked on a bad pointer in a timer. Rare, maybe, but true. Never say 'never again'. --linas ** Sent via the linuxppc64-dev mail list. See http://lists.linuxppc.org/ From olh at suse.de Thu Aug 28 21:08:29 2003 From: olh at suse.de (Olaf Hering) Date: Thu, 28 Aug 2003 13:08:29 +0200 Subject: possible deadlock in pipes In-Reply-To: <20030821215433.GE29476@krispykreme> References: <20030820214114.GA20395@suse.de> <20030821215433.GE29476@krispykreme> Message-ID: <20030828110829.GB1482@suse.de> On Fri, Aug 22, Anton Blanchard wrote: > > Hi Olaf, > > > I see random dead locks in pipe_wait() on power4 (p630, p650). > > I dont have a simple testcase to trigger it. The userland code its > > either 32bit or 64bit, new or (very) old. > > It happens with 2.4.19 and with 2.4.21. > > > > This patch seems to fix it, maybe it is only a workaround. Is the 2.4 > > pipe code supposed to work on power4 (enough sync accross cpus etc.)? > > How hard is it to hit? I think we should be using set_task_state() > which includes a memory barrier. I also updated the other open coded > statements to use __set_task_state. Finally I got rid of some redundant > wmb()s and added unlikely() to force the slow path out of line I'm running with this patch since a while, no problems. It happens after a while, hours, sometimes days. But I do not have a simple testcase. Thanks for the patch. -- USB is for mice, FireWire is for men! sUse lINUX ag, n?RNBERG ** Sent via the linuxppc64-dev mail list. See http://lists.linuxppc.org/ From anton at samba.org Fri Aug 29 01:42:48 2003 From: anton at samba.org (Anton Blanchard) Date: Fri, 29 Aug 2003 01:42:48 +1000 Subject: possible deadlock in pipes In-Reply-To: <20030828110829.GB1482@suse.de> References: <20030820214114.GA20395@suse.de> <20030821215433.GE29476@krispykreme> <20030828110829.GB1482@suse.de> Message-ID: <20030828154248.GB12541@krispykreme> Hi, > I'm running with this patch since a while, no problems. > It happens after a while, hours, sometimes days. But I do not have a > simple testcase. Thanks for testing Olaf, I have checked the fix into 2.5. Anton ** Sent via the linuxppc64-dev mail list. See http://lists.linuxppc.org/ From olh at suse.de Fri Aug 29 01:45:42 2003 From: olh at suse.de (Olaf Hering) Date: Thu, 28 Aug 2003 17:45:42 +0200 Subject: possible deadlock in pipes In-Reply-To: <20030828154248.GB12541@krispykreme> References: <20030820214114.GA20395@suse.de> <20030821215433.GE29476@krispykreme> <20030828110829.GB1482@suse.de> <20030828154248.GB12541@krispykreme> Message-ID: <20030828154542.GA12971@suse.de> On Fri, Aug 29, Anton Blanchard wrote: > > Hi, > > > I'm running with this patch since a while, no problems. > > It happens after a while, hours, sometimes days. But I do not have a > > simple testcase. > > Thanks for testing Olaf, I have checked the fix into 2.5. Hmm, I tested 2.4.21, but anyway :) -- USB is for mice, FireWire is for men! sUse lINUX ag, n?RNBERG ** Sent via the linuxppc64-dev mail list. See http://lists.linuxppc.org/ From anton at samba.org Fri Aug 29 01:50:00 2003 From: anton at samba.org (Anton Blanchard) Date: Fri, 29 Aug 2003 01:50:00 +1000 Subject: interrupt stacks Message-ID: <20030828155000.GC12541@krispykreme> Hi, In 2.4 we have interrupt stacks. It turns out there were a number of issues with the xics irq routines, Milton and I weeded them out in 2.5 over the last few months. There were windows where we could take irqs recursively, resulting in excessive stack usage. In 2.5 interrupt stacks are disabled because the thread_info changes broke it. The thread_info by default lives at the bottom of the kernel stack, and switching stacks on the fly confuses it greatly. Our options are: 1 fix thread_info. Some recent changes pushed by ia64 should allow us to move the thread_info into the task_struct. 2 remove interrupt stacks. We have done very heavy testing of 2.5 in the lab and have not seen any stack overflow problems. Now that we cant take recursive irqs we shouldnt be able to overflow a tasks stack. Im leaning towards option 2, if we dont need interrupt stacks then there is no need for that complexity. Thoughts? Anton ** Sent via the linuxppc64-dev mail list. See http://lists.linuxppc.org/ From anton at samba.org Fri Aug 29 01:51:05 2003 From: anton at samba.org (Anton Blanchard) Date: Fri, 29 Aug 2003 01:51:05 +1000 Subject: possible deadlock in pipes In-Reply-To: <20030828154542.GA12971@suse.de> References: <20030820214114.GA20395@suse.de> <20030821215433.GE29476@krispykreme> <20030828110829.GB1482@suse.de> <20030828154248.GB12541@krispykreme> <20030828154542.GA12971@suse.de> Message-ID: <20030828155105.GD12541@krispykreme> > Hmm, I tested 2.4.21, but anyway :) Should be similar in this area :) Im hoping Paul or Dave can pick this change up for 2.4. Anton ** Sent via the linuxppc64-dev mail list. See http://lists.linuxppc.org/ From linas at austin.ibm.com Fri Aug 29 04:07:51 2003 From: linas at austin.ibm.com (linas at austin.ibm.com) Date: Thu, 28 Aug 2003 13:07:51 -0500 Subject: IDE patches for 2.6 Message-ID: <20030828130750.B50758@forte.austin.ibm.com> Hi, I just had some write to me that there are some IDE patches that haven't gotten applied to the 2.6 ppc64 tree, resulting in a build-break when IDE is turned on. Specifically, they're the patches in http://lists.linuxppc.org/linuxppc64-dev/200305/msg00016.html Those patches were for 2.4.21 but casual inspection shows they're needed for 2.6 too, although I haven't actually tried (yet). I don't suppose anyone will commit these without actually making me go off and actually check thier validity for 2.6, right? ;-> --linas ** Sent via the linuxppc64-dev mail list. See http://lists.linuxppc.org/ From benh at kernel.crashing.org Fri Aug 29 04:19:33 2003 From: benh at kernel.crashing.org (Benjamin Herrenschmidt) Date: Thu, 28 Aug 2003 20:19:33 +0200 Subject: possible deadlock in pipes In-Reply-To: <20030828155105.GD12541@krispykreme> References: <20030820214114.GA20395@suse.de> <20030821215433.GE29476@krispykreme> <20030828110829.GB1482@suse.de> <20030828154248.GB12541@krispykreme> <20030828154542.GA12971@suse.de> <20030828155105.GD12541@krispykreme> Message-ID: <1062094772.612.156.camel@gaston> On Thu, 2003-08-28 at 17:51, Anton Blanchard wrote: > > Hmm, I tested 2.4.21, but anyway :) > > Should be similar in this area :) Im hoping Paul or Dave can pick this > change up for 2.4. I suppose ppc32 is affected as well ? Ben. ** Sent via the linuxppc64-dev mail list. See http://lists.linuxppc.org/ From olof at austin.ibm.com Fri Aug 29 04:53:26 2003 From: olof at austin.ibm.com (Olof Johansson) Date: Thu, 28 Aug 2003 13:53:26 -0500 Subject: [PATCH] EEH detection in acenic watchdog Message-ID: <3F4E4FA6.90901@austin.ibm.com> There's no code in the acenic watchdog that reads the registers on the board (i.e. readb/w/l), so EEH freeze will never be detected. Attached patch adds a call to eeh_check_failure in the watchdog function. This is an expensive call, but watchdog timeouts shouldn't happen (often) on a healthy system. (Same procedure as yesterday: I'll check this into BK in a bit unless I get comments). -Olof -- Olof Johansson Office: 4E002/905 pSeries Linux Development IBM Systems Group Email: olof at austin.ibm.com Phone: 512-838-9858 All opinions are my own and not those of IBM -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: acenic-eeh-patch Url: http://ozlabs.org/pipermail/linuxppc64-dev/attachments/20030828/c6d93302/attachment.txt From hollisb at us.ibm.com Fri Aug 29 05:12:57 2003 From: hollisb at us.ibm.com (Hollis Blanchard) Date: Thu, 28 Aug 2003 14:12:57 -0500 Subject: [PATCH] EEH detection in acenic watchdog In-Reply-To: <3F4E4FA6.90901@austin.ibm.com> Message-ID: On Thursday, Aug 28, 2003, at 13:53 US/Central, Olof Johansson wrote: > --- linux-2.4/drivers/net/acenic.c.orig 2003-08-25 15:04:37.000000000 > -0500 > +++ linux-2.4/drivers/net/acenic.c 2003-08-25 15:05:25.000000000 -0500 > @@ -67,6 +67,10 @@ > #include > #include > > +#ifdef CONFIG_PPC_PSERIES > +#include > +#endif > + > #if defined(CONFIG_VLAN_8021Q) || defined(CONFIG_VLAN_8021Q_MODULE) > #include > #endif > @@ -1867,6 +1871,15 @@ static void ace_watchdog(struct net_devi > dev->name); > netif_wake_queue(dev); > } > + > +#ifdef CONFIG_PPC_PSERIES > + /* IBM pSeries (ppc64) has a feature called EEH, in which a slot is > + * frozen if the bridge detects a parity error or DMA access > violation. > + * It's possible that the watchdog triggers because the slot got > frozen, > + * verify that this is not the case. > + */ > + eeh_check_failure(regs, 0); > +#endif > } I haven't followed this whole EEH thing at all, but how do the Acenic people feel about this patch? -- Hollis Blanchard IBM Linux Technology Center ** Sent via the linuxppc64-dev mail list. See http://lists.linuxppc.org/ From olof at austin.ibm.com Fri Aug 29 05:15:39 2003 From: olof at austin.ibm.com (Olof Johansson) Date: Thu, 28 Aug 2003 14:15:39 -0500 Subject: [PATCH] EEH detection in acenic watchdog In-Reply-To: References: Message-ID: <3F4E54DB.10307@austin.ibm.com> Hollis Blanchard wrote: > I haven't followed this whole EEH thing at all, but how do the Acenic > people feel about this patch? I submitted it to linux-acenic at sunsite.dk and jes at wildopensource.com, no word from them so far. I subscribed to the list at the same time, and haven't seen any traffic on it. -Olof -- Olof Johansson Office: 4E002/905 pSeries Linux Development IBM Systems Group Email: olof at austin.ibm.com Phone: 512-838-9858 All opinions are my own and not those of IBM ** Sent via the linuxppc64-dev mail list. See http://lists.linuxppc.org/ From taj.subhani at oracle.com Fri Aug 29 09:18:51 2003 From: taj.subhani at oracle.com (Mohammed Tajuddin) Date: Thu, 28 Aug 2003 16:18:51 -0700 Subject: TOC overflow on linuxppc64 Message-ID: <3F4E8DDB.C6EAABE5@oracle.com> Hello, Can someone guide me to fix the problem with TOC overflow on linux ppc64. After my various attempts building binutils/gcc/glibc following instructions on linuxppc64.org, I continue to get the same error. gnu/local/lib/gcc-lib/powerpc64-linux/3.2.3/crtend.o(.text+0xa): In function `.__do_global_ctors_aux': : relocation truncated to fit: R_PPC64_TOC16_DS .toc I don't have any problems building binutils etc. Somehow I am unable to get the correct patch although its their on the internet. Following are the different versions I have tried so far. a. binutils 2.14, gcc 3.2 and glibc 2.3 with the patch gcc-20030611-ppc64.diff b. binutils 2.14, gcc 3.1 and glibc 2.3 with the above patch c. binutils 2.14, gcc 3.3 and glibc 2.3 with the above patch d. binutils 2.14, gcc 3.2 and glibc 2.2.5 with the above patch e. binutils 2.14, gcc 3.2 and glibc 2.3 with all the gcc patches on linuxppc64.org although there were failures while applying the patch. Appreciate your feedback with the problem of multiple TOC. Please let me know if anyone has tried, the exact versions of the different tools to fix this problem. Regards, TAJ ** Sent via the linuxppc64-dev mail list. See http://lists.linuxppc.org/ From paulus at samba.org Fri Aug 29 09:19:48 2003 From: paulus at samba.org (Paul Mackerras) Date: Fri, 29 Aug 2003 09:19:48 +1000 (EST) Subject: [PATCH] EEH detection in acenic watchdog In-Reply-To: <3F4E4FA6.90901@austin.ibm.com> References: <3F4E4FA6.90901@austin.ibm.com> Message-ID: <16206.36372.514506.800484@nanango.paulus.ozlabs.org> Olof Johansson writes: > Attached patch adds a call to eeh_check_failure in the watchdog function. This is an expensive call, > but watchdog timeouts shouldn't happen (often) on a healthy system. This is OK for our local ppc64 trees, but it's a bit ugly. It's an extra ifdef and it is putting something very pSeries-specific into a driver that otherwise is platform-agnostic. Maybe what we should propose is to add a "platform_error_check()" function which can be called in these kinds of circumstances, with null definitions on most architectures. BTW, I think Jes Sorensen did the acenic driver in the context of his work for a previous employer. I don't know if he has any interest in the acenic now (or even any acenic hardware to work on). Paul. ** Sent via the linuxppc64-dev mail list. See http://lists.linuxppc.org/ From amodra at bigpond.net.au Fri Aug 29 11:18:59 2003 From: amodra at bigpond.net.au (Alan Modra) Date: Fri, 29 Aug 2003 10:48:59 +0930 Subject: TOC overflow on linuxppc64 In-Reply-To: <3F4E8DDB.C6EAABE5@oracle.com> References: <3F4E8DDB.C6EAABE5@oracle.com> Message-ID: <20030829011859.GS1320@bubble.sa.bigpond.net.au> Use mainline CVS binutils. -- Alan Modra IBM OzLabs - Linux Technology Centre ** Sent via the linuxppc64-dev mail list. See http://lists.linuxppc.org/ From olof at austin.ibm.com Fri Aug 29 12:36:34 2003 From: olof at austin.ibm.com (Olof Johansson) Date: Thu, 28 Aug 2003 21:36:34 -0500 (CDT) Subject: [PATCH] EEH detection in acenic watchdog In-Reply-To: <16206.36372.514506.800484@nanango.paulus.ozlabs.org> Message-ID: <200308290236.VAA53982@forte.austin.ibm.com> Paul Mackerras wrote: > This is OK for our local ppc64 trees, but it's a bit ugly. It's an > extra ifdef and it is putting something very pSeries-specific into a > driver that otherwise is platform-agnostic. Ok, so no shortcut this time then. :-) I wasn't sure what the prevailing attitude was against adding such specific hooks. The acenic driver is fairly clean as it is, so I suppose I should make an effort to keep it that way. > Maybe what we should propose is to add a "platform_error_check()" > function which can be called in these kinds of circumstances, with > null definitions on most architectures. I've added a pci_check_error(), since EEH is currently limited to PCI on our machines (and the driver in question is PCI-only. This also required a minor shuffle in arch/ppc64/kernel/eeh.c to take a struct pci_dev *. I also chose to #ifndef a dummy definition to be less intrusive on other architectures. On 2.6 it could probably make sense to modify all asm-*/pci.h instead, I'm not sure. See attachment for the patch. Is this more like what you had in mind? > BTW, I think Jes Sorensen did the acenic driver in the context of his > work for a previous employer. I don't know if he has any interest > in the acenic now (or even any acenic hardware to work on). Ack, I guess that makes LKML the best venue for patches then? He's still the official maintainer. Thanks, Olof -- Olof Johansson Office: 4E002/905 pSeries Linux Development IBM Systems Group Email: olof at austin.ibm.com Phone: 512-838-9858 All opinions are my own and not those of IBM -------------- next part -------------- ===== arch/ppc64/kernel/eeh.c 1.7 vs edited ===== --- 1.7/arch/ppc64/kernel/eeh.c Mon Aug 25 23:47:43 2003 +++ edited/arch/ppc64/kernel/eeh.c Thu Aug 28 21:11:51 2003 @@ -76,8 +76,6 @@ { unsigned long addr; struct pci_dev *dev; - struct device_node *dn; - unsigned long ret, rets[2]; /* IO BAR access could get us here...or if we manually force EEH * operation on even if the hardware won't support it. @@ -94,9 +92,21 @@ printk("EEH: no pci dev found for addr=0x%lx\n", addr); return val; } + return eeh_check_failure_dev(dev, val); +} + +/* Same as eeh_check_failure(), but takes a pci_dev instead of a + * token address. + */ + +unsigned long eeh_check_failure_dev(struct pci_dev *dev, unsigned long val) +{ + struct device_node *dn; + unsigned long ret, rets[2]; + dn = pci_device_to_OF_node(dev); if (!dn) { - printk("EEH: no pci dn found for addr=0x%lx\n", addr); + printk("EEH: no pci dn found for device %s\n", dev->name); return val; } @@ -133,7 +143,6 @@ } eeh_false_positives++; return val; /* good case */ - } struct eeh_early_enable_info { ===== drivers/net/acenic.c 1.29 vs edited ===== --- 1.29/drivers/net/acenic.c Fri Jun 20 01:00:08 2003 +++ edited/drivers/net/acenic.c Thu Aug 28 21:27:34 2003 @@ -1863,6 +1863,10 @@ dev->name, (unsigned int)readl(®s->HostCtrl)); /* This can happen due to ieee flow control. */ } else { + if (pci_check_error(ap->pdev)) { + printk(KERN_WARNING "%s: PCI error detected\n", dev->name); + } + printk(KERN_DEBUG "%s: BUG... transmitter died. Kicking it.\n", dev->name); #if 0 ===== include/asm-ppc64/eeh.h 1.6 vs edited ===== --- 1.6/include/asm-ppc64/eeh.h Mon Aug 25 23:47:51 2003 +++ edited/include/asm-ppc64/eeh.h Thu Aug 28 20:45:56 2003 @@ -46,6 +46,7 @@ void eeh_init(void); int eeh_get_state(unsigned long ea); unsigned long eeh_check_failure(void *token, unsigned long val); +unsigned long eeh_check_failure_dev(struct pci_dev *dev, unsigned long val); void *eeh_ioremap(unsigned long addr, void *vaddr); #define EEH_DISABLE 0 ===== include/asm-ppc64/pci.h 1.3 vs edited ===== --- 1.3/include/asm-ppc64/pci.h Fri May 10 19:46:04 2002 +++ edited/include/asm-ppc64/pci.h Thu Aug 28 21:02:10 2003 @@ -145,6 +145,14 @@ * this boolean for bounce buffer decisions. */ #define PCI_DMA_BUS_IS_PHYS (0) + +#define HAVE_PCI_CHECK_ERROR +static inline int pci_check_error(struct pci_dev *dev) +{ + /* eeh_check_failure returns the second argument on non-failures */ + return eeh_check_failure_dev(dev, 1); +} + #endif /* __KERNEL__ */ ===== include/linux/pci.h 1.32 vs edited ===== --- 1.32/include/linux/pci.h Mon Aug 25 23:47:53 2003 +++ edited/include/linux/pci.h Thu Aug 28 20:47:37 2003 @@ -806,5 +806,16 @@ #define PCIPCI_VSFX 16 #define PCIPCI_ALIMAGIK 32 +/* Some architectures have additional hardware support to detect problems + * with a PCI device, and puts the slot in a frozen state. This is the + * generic way to access that functionality. + * + * Return value is 0 for "no error detected" + */ + +#ifndef HAVE_PCI_CHECK_ERROR +static inline int pci_check_error(struct pci_dev *dev) { return 0; } +#endif /* HAVE_PCI_CHECK_ERROR */ + #endif /* __KERNEL__ */ #endif /* LINUX_PCI_H */ From olof at austin.ibm.com Fri Aug 29 13:06:20 2003 From: olof at austin.ibm.com (olof at austin.ibm.com) Date: Thu, 28 Aug 2003 22:06:20 -0500 (CDT) Subject: [PATCH] Specify right base address/IRQ for ttyS0{2,3} In-Reply-To: <3F4D1D4B.6010701@austin.ibm.com> Message-ID: Hmm, an interesting observation: When I boot with this patch on a 7044-270, it also finds 4 serial ports. One of them is the tablet port (which is a serial port). I suppose there is be hardware for 4 ports, but only 2+1 actually have connectors. This brings a bit more urgency to doing the "nice" fix: Looking at the device tree to find the serial ports, and patch the table early in the boot. Detecting them doesn't do much harm, but it's misleading. -Olof Olof Johansson Office: 4E002/905 pSeries Linux Development IBM Systems Group Email: olof at austin.ibm.com Phone: 512-838-9858 All opinions are my own and not those of IBM ** Sent via the linuxppc64-dev mail list. See http://lists.linuxppc.org/ From SVakkalankarao at covansys.com Fri Aug 29 18:18:55 2003 From: SVakkalankarao at covansys.com (VAKKALANKA RAO Sridhar) Date: Fri, 29 Aug 2003 13:48:55 +0530 Subject: IDE patches for 2.6 Message-ID: <207D6ADFC044A84686D44CA11B297EEA02018AAE@chn-ex02.cvns.corp.covansys.com> > I just had some write to me that there are some IDE patches that > haven't gotten applied to the 2.6 ppc64 tree, resulting in a build-break > when IDE is turned on. Specifically, they're the patches in > > http://lists.linuxppc.org/linuxppc64-dev/200305/msg00016.html Well, we had known this for some time. We had applied the changes as per the recommendations of http://lists.linuxppc.org/linuxppc64-dev/200305/msg00016.html. That fixed the build break when IDE was turned on for 2.6.0-test. However, that didn't bring the CD drive to life in spite of the fact that the kernel grew by more than 20K. Today, we received a break. In the past, even though we had turned on the "IDE/ATAPI cdrom support", we had omitted turning on the "PCI IDE chipset support" followed by "Winbond SL82c105 support" & "Generic PCI bus-master DMA support". That was the reason why the CD was not activating. We fixed that today and our CD drive has been working fine for the past few hours now. Anton (Blanchard), Recollect that we have been exchanging emails about it. Now, there is no more to do but test the new changes. After completing the code changes recommended by Linas, the following flags must be turned on in the file arch/ppc64/defconfig. ATA/ATAPI/MFM/RLL support Enhanced IDE/MFM/RLL disk/cdrom/tape/floppy support IDE/ATAPI cdrom support PCI IDE chipset support Winbond SL82c105 support Generic PCI bus-master DMA support Thanks Sri ** Sent via the linuxppc64-dev mail list. See http://lists.linuxppc.org/ From jakub at redhat.com Fri Aug 29 23:24:47 2003 From: jakub at redhat.com (Jakub Jelinek) Date: Fri, 29 Aug 2003 15:24:47 +0200 Subject: TOC overflow on linuxppc64 In-Reply-To: <20030829162103.A29782@infradead.org> References: <20030829162103.A29782@infradead.org> Message-ID: <20030829132447.GL12344@sunsite.ms.mff.cuni.cz> On Fri, Aug 29, 2003 at 04:21:03PM +0100, Christoph Hellwig wrote: > On Fri, Aug 29, 2003 at 10:07:47AM -0500, Steve Munroe wrote: > > For compatability with the current SLES 8 and xlc you should use the > > glibc-2.2.5 plus patches from > > what about current cvs HEAD? For that you need suitable GCC (e.g. one of): - gcc-3_2-branch with Alan's patchset - gcc-3_2-rhl8-branch - gcc-3_3-branch with Alan's patchset - gcc-3_3-rhl-branch - gcc HEAD recent binutils (CVS, hjl's) and CVS glibc. Jakub ** Sent via the linuxppc64-dev mail list. See http://lists.linuxppc.org/ From sjmunroe at us.ibm.com Sat Aug 30 01:07:47 2003 From: sjmunroe at us.ibm.com (Steve Munroe) Date: Fri, 29 Aug 2003 10:07:47 -0500 Subject: TOC overflow on linuxppc64 Message-ID: For compatability with the current SLES 8 and xlc you should use the glibc-2.2.5 plus patches from ftp://ftp.linuxppc64.org/pub/people/sjmunroe/glibc225-ppc64-20021120.patch ** Sent via the linuxppc64-dev mail list. See http://lists.linuxppc.org/ From hch at infradead.org Sat Aug 30 01:21:03 2003 From: hch at infradead.org (Christoph Hellwig) Date: Fri, 29 Aug 2003 16:21:03 +0100 Subject: TOC overflow on linuxppc64 In-Reply-To: ; from sjmunroe@us.ibm.com on Fri, Aug 29, 2003 at 10:07:47AM -0500 References: Message-ID: <20030829162103.A29782@infradead.org> On Fri, Aug 29, 2003 at 10:07:47AM -0500, Steve Munroe wrote: > For compatability with the current SLES 8 and xlc you should use the > glibc-2.2.5 plus patches from what about current cvs HEAD? ** Sent via the linuxppc64-dev mail list. See http://lists.linuxppc.org/