Re: [PATCH 1/3] sh: dynamic ftrace support.
On Thu, Nov 20, 2008 at 03:34:16PM -0500, Steven Rostedt wrote: +} elsif ($arch eq sh) { +$section_regex = Disassembly of section\\s+(\\S+):; +$function_regex = ^([0-9a-fA-F]+)\\s+(.*?):; +$mcount_regex = ^\\s*([0-9a-fA-F]+):.*\\smcount\$; +$type = .long; + +# force flags for this arch +$ld .= -m shlelf_linux; +$objcopy .= -O elf32-sh-linux; +$cc .= -m32; + Note that if the $alignment changes are in this version, you will also need to add an $alignment = 2; for sh. That was in Matt's original patch, but I stripped the alignment line out in the commit given that it was not yet present in the mainline version of the script. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: times(2) sys call bug?
On Fri, 2008-11-21 at 10:52 +1100, Paul Mackerras wrote: Joakim Tjernlund writes: This little hack changes the kernel sys call handling in an crude way and then it works. Apperently the kernel thinks is an error if the syscall returns a value between -_LAST_ERRNO and -1. Try this patch and let me if it fixes it. If it does I'll push it upstream. It does fix the problem, thanks. You might want to do the same to time(2)? This workaround lets you get around the times(2) problem. Perhaps you want to mention it in the commit msg: static clock_t our_times(void)/* Make times(2) behave rationally on Linux */ { clock_t ret; errno = 0; ret = times(NULL); if (errno != 0) ret = (clock_t) (-errno); return ret; } ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: times(2) sys call bug?
On Fri, Nov 21, 2008 at 10:52:14AM +1100, Paul Mackerras wrote: Joakim Tjernlund writes: This little hack changes the kernel sys call handling in an crude way and then it works. Apperently the kernel thinks is an error if the syscall returns a value between -_LAST_ERRNO and -1. Try this patch and let me if it fixes it. If it does I'll push it upstream. With your patch, you won't get EFAULT if you pass a bad address, but a constant, time independent value, unless I miss something. Of course there are peoaple who claim that EFAULT is a bad idea to start with and that you should send a SIGSEGV instead, and I can see their point. But with the current implementation, it is a game that you can't win: any syscall that wants to return an arbitrary integer multiplexed with an error value is broken beyond repair, by design. Oh, well. Gabriel ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: times(2) sys call bug?
On Fri, 2008-11-21 at 09:41 +0100, Gabriel Paubert wrote: On Fri, Nov 21, 2008 at 10:52:14AM +1100, Paul Mackerras wrote: Joakim Tjernlund writes: This little hack changes the kernel sys call handling in an crude way and then it works. Apperently the kernel thinks is an error if the syscall returns a value between -_LAST_ERRNO and -1. Try this patch and let me if it fixes it. If it does I'll push it upstream. With your patch, you won't get EFAULT if you pass a bad address, but a constant, time independent value, unless I miss something. Not so, look again: asmlinkage long sys_times(struct tms __user * tbuf) { ... if (tbuf) { ... if (copy_to_user(tbuf, tmp, sizeof(struct tms))) return -EFAULT; } force_successful_syscall_return(); return (long) jiffies_64_to_clock_t(get_jiffies_64()); } ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: times(2) sys call bug?
Gabriel Paubert writes: On Fri, Nov 21, 2008 at 10:52:14AM +1100, Paul Mackerras wrote: Joakim Tjernlund writes: This little hack changes the kernel sys call handling in an crude way and then it works. Apperently the kernel thinks is an error if the syscall returns a value between -_LAST_ERRNO and -1. Try this patch and let me if it fixes it. If it does I'll push it upstream. With your patch, you won't get EFAULT if you pass a bad address, but a constant, time independent value, unless I miss something. I think you are missing something, namely that I put the call to force_successful_syscall_return() AFTER the return -EFAULT. You should get an EFAULT error if the address is bad, i.e. on return to userspace with cr0.SO = 1 and r3 = EFAULT (note, not -EFAULT). On a non-error return you should get cr0.SO = 0 and r3 containing the return value (even if it's -EFAULT). It's possible that glibc will stuff it up again after that but I hope not. Paul. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Kernel completely crashes after accessing an unmapped area.
On Wed, 2008-11-19 at 13:59 +0100, Ricardo wrote: Hello All: I am using the paulus tree popwerpc linux kernel for a ppc440 cpu located in a Virtex5 FPGA. While developing some drivers (a simple gpio device) I have notice that if I try to access an unmapped area (an address without any register/device attached), the system completely crashes... I remember that doing the same with a ppc400 cpu the system showed a Instruction/Data bus error and continue working. My question: The ppc440 cannot recover from this types of errors or is a kernel missing feature/bug? You may want to look at the patch I posted recently: powerpc: Fix 460EX/460GT machine check handling From the look of your log, we aren't using the right type of machine check handler for your core and it may need a similar treatement as the above processors. There are two kind of 440 cores vs. machine checks. On the old kind, machine checks used to be critical interrupts (and thus used CSRR0 and CSRR1 to save the context) while on the new kind, machine checks are their own type of exception with a dedicated pair of context save registers MCSRR0 and MCSRR1. It -looks- like the problem might be that the kernel isn't using the right set for your core. It uses by default the old style unless you change the machine check IVOR to point to MachineCheckA which is done by calling __fixup_440A_mcheck() in your CPU init routine for example, as we do for other 440 cores. So you would have to hook up a setup_cpu routine in cputable for those guys (I can see the virtex cores seem to not have any at this stage) and also change their machine check pointer to use machine_check_440A instead of machine_check_4xx so the machine check details are properly decoded. Of course check your Virtex user manual to make sure that's indeed what is happening :-) Cheers, Ben. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: times(2) sys call bug?
On Fri, 2008-11-21 at 20:03 +1100, Paul Mackerras wrote: Gabriel Paubert writes: On Fri, Nov 21, 2008 at 10:52:14AM +1100, Paul Mackerras wrote: Joakim Tjernlund writes: This little hack changes the kernel sys call handling in an crude way and then it works. Apperently the kernel thinks is an error if the syscall returns a value between -_LAST_ERRNO and -1. Try this patch and let me if it fixes it. If it does I'll push it upstream. With your patch, you won't get EFAULT if you pass a bad address, but a constant, time independent value, unless I miss something. I think you are missing something, namely that I put the call to force_successful_syscall_return() AFTER the return -EFAULT. You should get an EFAULT error if the address is bad, i.e. on return to userspace with cr0.SO = 1 and r3 = EFAULT (note, not -EFAULT). On a non-error return you should get cr0.SO = 0 and r3 containing the return value (even if it's -EFAULT). It's possible that glibc will stuff it up again after that but I hope not. With your patch: t1 = times((void*) 1); if (t1 == -1) { my_err = errno; printf(Errno:%d, %s\n, my_err, strerror(my_err)); } prints: Errno:14, Bad address ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: times(2) sys call bug?
On Fri, 2008-11-21 at 10:52 +1100, Paul Mackerras wrote: Joakim Tjernlund writes: This little hack changes the kernel sys call handling in an crude way and then it works. Apperently the kernel thinks is an error if the syscall returns a value between -_LAST_ERRNO and -1. Try this patch and let me if it fixes it. If it does I'll push it upstream. Paul. [SNIP] + force_successful_syscall_return(); return (long) jiffies_64_to_clock_t(get_jiffies_64()); Why is 64 bits ops used here when you only use 32 bits? BTW, I think time(2) needs this: diff --git a/kernel/time.c b/kernel/time.c index 6a08660..1627910 100644 --- a/kernel/time.c +++ b/kernel/time.c @@ -37,6 +37,7 @@ #include linux/fs.h #include linux/slab.h #include linux/math64.h +#include linux/ptrace.h #include asm/uaccess.h #include asm/unistd.h @@ -65,8 +66,9 @@ asmlinkage long sys_time(time_t __user * tloc) if (tloc) { if (put_user(i,tloc)) - i = -EFAULT; + return -EFAULT; } + force_successful_syscall_return(); return i; } ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: times(2) sys call bug?
On Fri, Nov 21, 2008 at 08:03:06PM +1100, Paul Mackerras wrote: Gabriel Paubert writes: On Fri, Nov 21, 2008 at 10:52:14AM +1100, Paul Mackerras wrote: Joakim Tjernlund writes: This little hack changes the kernel sys call handling in an crude way and then it works. Apperently the kernel thinks is an error if the syscall returns a value between -_LAST_ERRNO and -1. Try this patch and let me if it fixes it. If it does I'll push it upstream. With your patch, you won't get EFAULT if you pass a bad address, but a constant, time independent value, unless I miss something. I think you are missing something, namely that I put the call to force_successful_syscall_return() AFTER the return -EFAULT. Indeed, it may be time to update the syscall documentation, saying that you need to clear errno before the syscall and check errno and not the return value since -1 is valid. Who does this? I have spotted some errors in other places on my man pages too, especially in the networking area (they were correct once upon a time, but have not been updated). Regards, Gabriel ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: times(2) sys call bug?
Joakim Tjernlund writes: + force_successful_syscall_return(); return (long) jiffies_64_to_clock_t(get_jiffies_64()); Why is 64 bits ops used here when you only use 32 bits? If HZ is 1000, jiffies_64_to_clock_t is going to divide jiffies by 10, so we need to start with 64 bits in order to get the top few bits of a 32-bit result correct. BTW, I think time(2) needs this: In principle you are correct, but it's only going to matter for a little over an hour some time in the year 2106. :) Paul. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: times(2) sys call bug?
On Fri, 2008-11-21 at 10:31 +0100, Joakim Tjernlund wrote: On Fri, 2008-11-21 at 10:52 +1100, Paul Mackerras wrote: Joakim Tjernlund writes: This little hack changes the kernel sys call handling in an crude way and then it works. Apperently the kernel thinks is an error if the syscall returns a value between -_LAST_ERRNO and -1. Try this patch and let me if it fixes it. If it does I'll push it upstream. Paul. [SNIP] + force_successful_syscall_return(); return (long) jiffies_64_to_clock_t(get_jiffies_64()); Why is 64 bits ops used here when you only use 32 bits? BTW, I think time(2) needs this: diff --git a/kernel/time.c b/kernel/time.c [SNIP] Oh, and compat needs fixing too. For both my patches: Signed-off-by: Joakim Tjernlund [EMAIL PROTECTED] BTW, why is sys_time() impl. differently in compat: do_gettimeofday(tv); vs. get_seconds(); same for sys_times(): compat_jiffies_to_clock_t(jiffies); vs. jiffies_64_to_clock_t(get_jiffies_64()); diff --git a/kernel/compat.c b/kernel/compat.c index 32c254a..c6346ec 100644 --- a/kernel/compat.c +++ b/kernel/compat.c @@ -23,6 +23,7 @@ #include linux/timex.h #include linux/migrate.h #include linux/posix-timers.h +#include linux/ptrace.h #include asm/uaccess.h @@ -196,6 +197,7 @@ asmlinkage long compat_sys_times(struct compat_tms __user *tbuf) if (copy_to_user(tbuf, tmp, sizeof(tmp))) return -EFAULT; } + force_successful_syscall_return(); return compat_jiffies_to_clock_t(jiffies); } @@ -850,8 +852,9 @@ asmlinkage long compat_sys_time(compat_time_t __user * tloc) if (tloc) { if (put_user(i,tloc)) - i = -EFAULT; + return -EFAULT; } + force_successful_syscall_return(); return i; } ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: times(2) sys call bug?
Gabriel Paubert writes: Who does this? I have spotted some errors in other places on my man pages too, especially in the networking area (they were correct once upon a time, but have not been updated). Michael Kerrisk [EMAIL PROTECTED], I believe. Paul. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: times(2) sys call bug?
On Fri, 2008-11-21 at 20:51 +1100, Paul Mackerras wrote: Joakim Tjernlund writes: + force_successful_syscall_return(); return (long) jiffies_64_to_clock_t(get_jiffies_64()); Why is 64 bits ops used here when you only use 32 bits? If HZ is 1000, jiffies_64_to_clock_t is going to divide jiffies by 10, so we need to start with 64 bits in order to get the top few bits of a 32-bit result correct. I see, thanks. BTW, I think time(2) needs this: In principle you are correct, but it's only going to matter for a little over an hour some time in the year 2106. :) I know, but I figured it should be fixed to serve as an template for other similar sys calls(not that I know of any offhand). Perhaps add it commented? Jocke ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: times(2) sys call bug?
On Fri, 2008-11-21 at 10:50 +0100, Gabriel Paubert wrote: On Fri, Nov 21, 2008 at 08:03:06PM +1100, Paul Mackerras wrote: Gabriel Paubert writes: On Fri, Nov 21, 2008 at 10:52:14AM +1100, Paul Mackerras wrote: Joakim Tjernlund writes: This little hack changes the kernel sys call handling in an crude way and then it works. Apperently the kernel thinks is an error if the syscall returns a value between -_LAST_ERRNO and -1. Try this patch and let me if it fixes it. If it does I'll push it upstream. With your patch, you won't get EFAULT if you pass a bad address, but a constant, time independent value, unless I miss something. I think you are missing something, namely that I put the call to force_successful_syscall_return() AFTER the return -EFAULT. Indeed, it may be time to update the syscall documentation, saying that you need to clear errno before the syscall and check errno and not the return value since -1 is valid. And perhaps mention that times(NULL) never returns an error. And that times() is broken in 2.6.27 and earlier and needs the workaround posted earlier. Jocke ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 1/3] sh: dynamic ftrace support.
On Fri, Nov 21, 2008 at 04:44:29PM +0900, Paul Mundt wrote: On Thu, Nov 20, 2008 at 03:34:16PM -0500, Steven Rostedt wrote: +} elsif ($arch eq sh) { +$section_regex = Disassembly of section\\s+(\\S+):; +$function_regex = ^([0-9a-fA-F]+)\\s+(.*?):; +$mcount_regex = ^\\s*([0-9a-fA-F]+):.*\\smcount\$; +$type = .long; + +# force flags for this arch +$ld .= -m shlelf_linux; +$objcopy .= -O elf32-sh-linux; +$cc .= -m32; + Note that if the $alignment changes are in this version, you will also need to add an $alignment = 2; for sh. That was in Matt's original patch, but I stripped the alignment line out in the commit given that it was not yet present in the mainline version of the script. I've sent a patch to steven for his tip/devel branch that adds this line. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
MPC5200B: Trouble with config pins
Hi all, we have trouble with the eth based config pins (ETH0...ETH6) of the MPC5200B CPU. These pins act as the interface to an external phy and also act as configurations pins to configure the size of the flash and other things. While the reset is active these pins should be in their high impedance state and the externally connected pull down resistors should define wire's voltage level. With the rising edge of the reset signal these levels will be latched into internal config registers. We are in trouble when we want to reboot the system (also watchdog based) or the internal watchdog barks and generates the CPU internal reset signal. In these cases these config pins will not change their level! So the wrong settings are latched in and our CPU is dead (misconfigured), sometimes a second reset helps, but most of the time only power cycling helps. What we see is: - at the pins ETH_0 and ETH_3 (both are output only, when used for ethernet) * With an external 10k pulldown these lines never change their 3.3V level even if the reset is active! * With an external 1k pulldown these lines change their 3.3V level down to something about 2.5V when the falling edge of the reset signal occurs. * This level decreases slowly to 1.2V in about 1.2ms and than a falling edge to 0V occures. Problem here is, the internal watchdog's generated reset signal is much shorter, so the rising edge of this reset signal also latches in the wrong settings and the CPU is dead. Some other things we see. A reset while: - a running tftp command in U-Boot with disconnected network - system is always dead - a running tftp command in U-Boot with connected network - system restarts We can see in this case, the ETH_0 and ETH_3 are switching to low level *immediatly* with the falling edge of the reset signal - an activated interface (ifconfig up) in Linux with *disconnected* network - system is always dead - an activated interface (ifconfig up) in Linux with *connected* network - system is always dead Does anybody see a behaviour like ours on his/her MPC5200B based system? Does anybody have an idea what the difference between U-Boot und Linux could be? Bug? Feature? Regards, Juergen -- Dipl.-Ing. Juergen Beisert | http://www.pengutronix.de Pengutronix - Linux Solutions for Science and Industry Handelsregister: Amtsgericht Hildesheim, HRA 2686 Vertretung Sued/Muenchen, Germany Phone: +49-8766-939 228 | Fax: +49-5121-206917-9 ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] ftrace: mcountrecord.pl for arm
On Fri, 21 Nov 2008, Russell King - ARM Linux wrote: On Thu, Nov 20, 2008 at 02:11:49PM -0800, Jim Radford wrote: Ingo and Steven, Here's an updated version of the arch/arm changes for dynamic ftrace based on top of your latest tip/master. Excuse me if I'm rather confused, but... When ftrace for ARM was originally merged, neither linux-arm-kernel nor myself were copied with the patches. Now, I'm being sent updates to code that I've no understanding of and haven't seen before. I mean, yes, it's nice to be copied with patches which are relevent. It would've been even nicer to have been copied with the patches adding ftrace in the first place, so people knew something about it and were aware of the changes. It seems to me like there's been a total breakdown of communication when ftrace was initially merged... Yes I totally agree that in the beginning there was a breakdown of communication. I myself just learned of the ARM port. So, questions: has ftrace actually been tested on ARM at all? Has it been reviewed? Which ARM platforms has it been tried on? How stable is it? How has it been implemented on ARM? Does it rely on any CPU specific behaviour? Looking at the git history, ftrace was merged via Ingo, so I assume that Ingo has some understanding of this code. So, for the time being if these are urgent updates, I suggest that updates go through Ingo's tree rather than mine. I would suggest that they at least get an ACK from you. The original code should have too. And looking at arch/arm/kernel/ftrace.c, it's incompatible with Thumb2 which we've been working towards supporting. What about SMP? ARM is a SMP capable architecture now, and I see no locking in there - what I do see is static data with pointers to it being returned to other code... Yuck. Some of this code will be redesigned in 29. But as for the locking, this code is run under kstop_machine. Which means that even on SMP architectures, this acts like a UP box. Some of the code can be run outside of kstop_machine, but it is protected by locks in the module code. I'll take a look at the ftrace.c arm code and see if there's any problems with it. I wrote the x86 version as well as the coming PowerPC port. Thanks, -- Steve ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] ftrace: mcountrecord.pl for arm
On Thu, Nov 20, 2008 at 02:11:49PM -0800, Jim Radford wrote: Ingo and Steven, Here's an updated version of the arch/arm changes for dynamic ftrace based on top of your latest tip/master. Excuse me if I'm rather confused, but... When ftrace for ARM was originally merged, neither linux-arm-kernel nor myself were copied with the patches. Now, I'm being sent updates to code that I've no understanding of and haven't seen before. I mean, yes, it's nice to be copied with patches which are relevent. It would've been even nicer to have been copied with the patches adding ftrace in the first place, so people knew something about it and were aware of the changes. It seems to me like there's been a total breakdown of communication when ftrace was initially merged... So, questions: has ftrace actually been tested on ARM at all? Has it been reviewed? Which ARM platforms has it been tried on? How stable is it? How has it been implemented on ARM? Does it rely on any CPU specific behaviour? Looking at the git history, ftrace was merged via Ingo, so I assume that Ingo has some understanding of this code. So, for the time being if these are urgent updates, I suggest that updates go through Ingo's tree rather than mine. And looking at arch/arm/kernel/ftrace.c, it's incompatible with Thumb2 which we've been working towards supporting. What about SMP? ARM is a SMP capable architecture now, and I see no locking in there - what I do see is static data with pointers to it being returned to other code... Yuck. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re :Re: [Ltib] ltib error -linux2.6.20.6 with MPC8360E MDS
Hi Stuart,nbsp;nbsp; Thanks for the information.nbsp;nbsp; gpp access was resolved. nbsp;nbsp; I was successful in building the linux 2.6.11 using the ltib and able to bring up the MPC8360 EMDS.But, I stillnbsp;face the problem for linux kernel 2.6.19 and 2.6.20.nbsp;nbsp;nbsp;When I tried using ltib in thenbsp;bringing up the board.nbsp;nbsp;nbsp;The MPC 8360 board keeps rebooting after downloading the image Power PC Kernel Image(uImage) and Power PC RAMDisk Image(rootfs.ext2.gz.uboot)nbsp;nbsp;build by the ltibnbsp;nbsp; nbsp; Please clarrify on the same.Thanks in advance.Regards,Nandanbsp;nbsp;On Thu, 20 Nov 2008 18:40:36 Stuart Hughes wroteHi Nanda,This is happening because you don't have access tohttp://www.bitshrine.org/gpp for some reason.If LTIB needs to download sources to build a package, it will get themfrom bitshrine.org. Can you check that you are able to access this URLfrom the command line with wget.Regards, StuartOn Thu, 2008-11-20 at 18:30 , nanda wrote:gt; Hi All,gt; Iam forwarding the mail which I have posted to powerpc linux listgt; Linuxppc-dev@ozlabs.orggt; ===gt; gt; Iam getting the below error during the generation ofgt; rootfs.ext2.gz.uboot (Power PC Linux RAM Disk Image) and uImage (Powergt; PC Linux Kernel Image) for linux-2.6.20.6 kernel on the power PC MPCgt; 8360E MDS using ltib tool.gt; gt; Testing ppp_url connectivity: FAIL, disabling gt; gt; Testing gpp_url connectivity: FAIL, disabling gt; gt; No network download connection availablegt; gt; I did the following steps, but Iam unable to generate thegt; rootfs.ext2.gz.uboot gt; gt; - In the ltib directory gt; gt; ./ltib --configuregt; gt; In the configure menu, I specified the following, before saving thegt; configsgt; gt; - Tool chain as (gcc-3.4.3/glibc-2.3.3)gt; gt; - uboot 1.1.3gt; gt; - Kernel (local linux directory build) which refers to the loca lgt; directory where linux-2.6.20.6 is placedgt; gt; - Kernel config filespecified as mpc8360emds_defconfig, which is thegt; file copiedgt; from /home/nanda/linux2.6.20.6/arch/powerpc/configs/mpc8360emds_defconfig to the ltib/config/platform/mpc8360epb directory) gt; gt; - Linux Target Architecture as powerpcgt; gt; After the above process by saving the configuration (it startedgt; building kernel and generated uImage) and failed in the below placegt; (Refer also the attached build.txt file)gt; gt; gt; gt; Processing: skell gt; gt; === gt; gt; Testing ppp_url connectivity: FAIL, disabling gt; gt; Testing gpp_url connectivity: FAIL, disabling gt; gt; No network download connection availablegt; gt; Started: Thu Nov 20 14:44:45 2008 gt; gt; Ended: Thu Nov 20 14:57:32 2008 gt; gt; Elapsed: 767 seconds gt; gt; Build Failedgt; gt; =gt; gt; I have attached the below files for boot and build logs with thisgt; mail, gt; gt; 1) defconfig.dev - default config generated for ./ltib configuregt; from config/platform/mpc8360epb gt; gt; 2) build.txt - Error build during ./ltib configure outputgt; gt; 3) mpc8360emds_defconfig - Default config filegt; from /home/nanda/linux2.6.20.6/arch/powerpc/configs/ gt; gt; The end result was I could only see the uImage generated withoutgt; rootfs.ext2.gz.uboot. Please clarify on the same gt; gt; Thanks in advance,gt; gt; Regards,gt; gt; Nandagt; ___Linuxppc-dev mailing [EMAIL PROTECTED]://ozlabs.org/mailman/listinfo/linuxppc-dev___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Re :Re: [Ltib] ltib error -linux2.6.20.6 with MPC8360E MDS
Hi Nanda, You'll need to get help from the kernel experts with this issue. Regards, Stuart On Fri, 2008-11-21 at 14:16 +, nanda wrote: Hi Stuart, Thanks for the information. gpp access was resolved. I was successful in building the linux 2.6.11 using the ltib and able to bring up the MPC8360 EMDS. But, I still face the problem for linux kernel 2.6.19 and 2.6.20. When I tried using ltib in the bringing up the board. The MPC 8360 board keeps rebooting after downloading the image Power PC Kernel Image(uImage) and Power PC RAMDisk Image(rootfs.ext2.gz.uboot) build by the ltib Please clarrify on the same. Thanks in advance. Regards, Nanda On Thu, 20 Nov 2008 18:40:36 Stuart Hughes wrote Hi Nanda, This is happening because you don't have access to http://www.bitshrine.org/gpp for some reason. If LTIB needs to download sources to build a package, it will get them from bitshrine.org. Can you check that you are able to access this URL from the command line with wget. Regards, Stuart On Thu, 2008-11-20 at 18:30 , nanda wrote: Hi All, Iam forwarding the mail which I have posted to powerpc linux list Linuxppc-dev@ozlabs.org === Iam getting the below error during the generation of rootfs.ext2.gz.uboot (Power PC Linux RAM Disk Image) and uImage (Power PC Linux Kernel Image) for linux-2.6.20.6 kernel on the power PC MPC 8360E MDS using ltib tool. Testing ppp_url connectivity: FAIL, disabling Testing gpp_url connectivity: FAIL, disabling No network download connection available I did the following steps, but Iam unable to generate the rootfs.ext2.gz.uboot - In the ltib directory ./ltib --configure In the configure menu, I specified the following, before saving the configs - Tool chain as (gcc-3.4.3/glibc-2.3.3) - uboot 1.1.3 - Kernel (local linux directory build) which refers to the local directory where linux-2.6.20.6 is placed - Kernel config filespecified as mpc8360emds_defconfig, which is the file copied from /home/nanda/linux2.6.20.6/arch/powerpc/configs/mpc8360emds_defconfig to the ltib/config/platform/mpc8360epb directory) - Linux Target Architecture as powerpc After the above process by saving the configuration (it started building kernel and generated uImage) and failed in the below place (Refer also the attached build.txt file) Processing: skell === Testing ppp_url connectivity: FAIL, disabling Testing gpp_url connectivity: FAIL, disabling No network download connection available Started: Thu Nov 20 14:44:45 2008 Ended: Thu Nov 20 14:57:32 2008 Elapsed: 767 seconds Build Failed = I have attached the below files for boot and build logs with this mail, 1) defconfig.dev - default config generated for ./ltib configure from config/platform/mpc8360epb 2) build.txt - Error build during ./ltib configure output 3) mpc8360emds_defconfig - Default config file from /home/nanda/linux2.6.20.6/arch/powerpc/configs/ The end result was I could only see the uImage generated without rootfs.ext2.gz.uboot. Please clarify on the same Thanks in advance, Regards, Nanda ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev Rediff Shopping ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] powerpc/mpic: don't reset affinity for secondary MPIC on boot
On Friday 21 November 2008, Benjamin Herrenschmidt wrote: Oh just that for powermac for example, I know I'm resetting the thing, so can't rely on init values, and on some BML embedded boxes too, while on things like cell I don't off hand know what the right CPU number is to hit the right C3PO interrupt, so I'm better off reading what SLOF did :-) The current code will always use destination 0 for any MPIC, because mpic_init is run befew smp_init and it currently uses the local CPU. If an SMP powermac requires a specific destination setting in the secondary MPIC, either the current mpic_init code is broken there in the same way as on cell, or more broken if it requires something other than destination 0. But if you think on Cell we can just hard wire in the platform code, then I'm ok. On cell, I know that destination 0 is always correct because of the wiring inside of Axon. Arnd ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH] IB/ehca: Fix lockdep failures for shca_list_lock
From: Michael Ellerman [EMAIL PROTECTED] shca_list_lock is taken from softirq context in ehca_poll_eqs, so we need to lock IRQ safe elsewhere. Signed-off-by: Michael Ellerman [EMAIL PROTECTED] Acked-by: Joachim Fenkes [EMAIL PROTECTED] --- drivers/infiniband/hw/ehca/ehca_main.c | 17 ++--- 1 files changed, 10 insertions(+), 7 deletions(-) diff --git a/drivers/infiniband/hw/ehca/ehca_main.c b/drivers/infiniband/hw/ehca/ehca_main.c index bb02a86..021c454 100644 --- a/drivers/infiniband/hw/ehca/ehca_main.c +++ b/drivers/infiniband/hw/ehca/ehca_main.c @@ -717,6 +717,7 @@ static int __devinit ehca_probe(struct of_device *dev, const u64 *handle; struct ib_pd *ibpd; int ret, i, eq_size; + u64 flags; handle = of_get_property(dev-node, ibm,hca-handle, NULL); if (!handle) { @@ -830,9 +831,9 @@ static int __devinit ehca_probe(struct of_device *dev, ehca_err(shca-ib_device, Cannot create device attributes ret=%d, ret); - spin_lock(shca_list_lock); + spin_lock_irqsave(shca_list_lock, flags); list_add(shca-shca_list, shca_list); - spin_unlock(shca_list_lock); + spin_unlock_irqrestore(shca_list_lock, flags); return 0; @@ -878,6 +879,7 @@ probe1: static int __devexit ehca_remove(struct of_device *dev) { struct ehca_shca *shca = dev-dev.driver_data; + u64 flags; int ret; sysfs_remove_group(dev-dev.kobj, ehca_dev_attr_grp); @@ -915,9 +917,9 @@ static int __devexit ehca_remove(struct of_device *dev) ib_dealloc_device(shca-ib_device); - spin_lock(shca_list_lock); + spin_lock_irqsave(shca_list_lock, flags); list_del(shca-shca_list); - spin_unlock(shca_list_lock); + spin_unlock_irqrestore(shca_list_lock, flags); return ret; } @@ -975,6 +977,7 @@ static int ehca_mem_notifier(struct notifier_block *nb, unsigned long action, void *data) { static unsigned long ehca_dmem_warn_time; + unsigned long flags; switch (action) { case MEM_CANCEL_OFFLINE: @@ -985,12 +988,12 @@ static int ehca_mem_notifier(struct notifier_block *nb, case MEM_GOING_ONLINE: case MEM_GOING_OFFLINE: /* only ok if no hca is attached to the lpar */ - spin_lock(shca_list_lock); + spin_lock_irqsave(shca_list_lock, flags); if (list_empty(shca_list)) { - spin_unlock(shca_list_lock); + spin_unlock_irqrestore(shca_list_lock, flags); return NOTIFY_OK; } else { - spin_unlock(shca_list_lock); + spin_unlock_irqrestore(shca_list_lock, flags); if (printk_timed_ratelimit(ehca_dmem_warn_time, 30 * 1000)) ehca_gen_err(DMEM operations are not allowed -- 1.5.5 ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: powerpc: udbg based backend for hvc_console
On Nov 20, 2008, at 1:16 PM, Timur Tabi wrote: Milton Miller wrote: Stated differently, if your routine (1) fundamently works one character at a time and (2) is not interrupt driven, and (3) only supports one channel, what avantage is there to an explicit hvc driver? I think it's because HVC has the ability to use HVC client drivers for console and TTY, but udbg does not. So if you have a udbg-only driver, it will cease to function when the kernel switches to the normal console. Perhaps it would make more sense to have the kernel continue to use udbg if there is no normal console driver, instead of relying on David's driver. First, we have that option: just specify udbg-imortal on the command line, and the udbg console driver removes CON_BOOT from its flags. Second, as David said in his reply, that doesn't let your userspace have a tty, which means no job control. I too challanged the necessity of that change. I carefully designed the hvc_console layer to find the selected console weither it was registered before or after the console_initcall of hvc_console. I'm just pointing out the patch that was committed in 2006 to address this issue. I discovered the same bug that the patch mentioned, and only after a long time searching did I find this patch. And sure enough, re-arranging the Makefile made the problem I was seeing go away. Now, it's possible that this bug in hvc_console no longer exists. However, I have seen nothing to indicate it. Unfortunately, I don't remember enough of the details to reproduce the problem, so I can't verify it. As I said, I conceeded then the patch was required the way things worked. There was another propsed patch a few months ago (3-9) that I pointed out they needed to be fixing the common console code; I don't remember seeing anything related after that but I could have missed it. However, I think the bottom line was that add_preferred_console is suppsoed to be called by architecture setup code. Doing it the console_initcall is almost abuse. But if the console_initcall is going to call add_preferred_console, then it must link before the hvc_console driver. I would have to go back and find the discussion to remember the exact details. (maybe it only needed to call add_preferreed_console before registering itself if its the only hvc backend). Well, I can't comment on your theory, but I do know that the add_preferred_console() call should be made from the HVC client driver, or at least HVC itself. It should not be in the platform code, because then we have a dependency between the driver and the platform code. I prefer my drivers to initialize everything on their own, without the help of the platform code. Think about this for a second. If every console driver said prefer me, what point is there in having add_preferred_console? The second reason is its too late. We have already started scanning for drivers. We are asking the console layer to adjust its choices after it has started scanning. We want the last console= parameter on the command line to win. So if that implys the last call to add_preferred_console wins, then you have code overriding the command line. We have code that searches the device tree for the stdout that firmware used. That code then tells the console layer which driver to choose when it recognises it. The pSeries platform also has code that says when it finds vterm channels under lpar, then it should choose it. I think we should have the code that sets the udbg method indicate that the console should be preferred. While its not really arch code, it is architecture code in that its hooked from early discovrey based not cosole_initcall based (which runs before arch_initcall). This is also the point where we know if the udbg method is sharing hardware with a full driver and therefore udbg_hvc should not be used. milton ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] cpm2: Round the baud-rate clock divider to the nearest integer.
Hi Scott, On Thursday 20 November 2008, Scott Wood wrote: On Thu, Nov 20, 2008 at 01:32:23PM +0100, Laurent Pinchart wrote: Instead of rounding the divider down, improve the baud-rate generators accuracy by rounding to the nearest integer. Signed-off-by: Laurent Pinchart [EMAIL PROTECTED] This makes things worse on mpc8272ads -- the result of the division is 13.56, but I only get error-free serial output when rounding down. I don't think the remote end has timing problems, as I don't see this with any other board. I get exactly the opposite here with an mpc8248 base board. Rounding down makes 115200bds completely unreliable :-/ Could you measure the serial baudrate with and without the patch using an oscilloscope ? Possibly the crystal is a little off, That's always possible. or maybe it's just better to be a little too fast than a little too slow for some reason? Maybe we should change CPM_CLK to be MAIN_CLK/4 rather than MAIN_CLK/16 when the BRG clock is below a certain frequency. Isn't that the job of the boot loader ? Accuracy would be improved, but power consumption will raise as well :-/ Best regards, Laurent Pinchart ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: powerpc: udbg based backend for hvc_console
Milton Miller wrote: We want the last console= parameter on the command line to win. So if that implys the last call to add_preferred_console wins, then you have code overriding the command line. Hmm, good point. However, how likely is it that we'll have more than one console driver? Also, without calling add_preferred_console(), the kernel needs to have a console= on the command line. In my case, my driver only calls add_preferred_console() if the device tree contains a specific property that it looks for. In effect, this property override the console= line. However, the console= line goes to the HVC subsystem, and not my driver, and I can't use it to send the configuration data the driver needs. Unfortunately, my driver hasn't been published yet, so it's hard to explain the details. I guess I need to think about this more. -- Timur Tabi Linux kernel developer at Freescale ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH] IB/ehca: Fix locking for shca_list_lock
shca_list_lock is taken from softirq context in ehca_poll_eqs, so we need to lock IRQ safe elsewhere. Signed-off-by: Michael Ellerman [EMAIL PROTECTED] Signed-off-by: Joachim Fenkes [EMAIL PROTECTED] --- On Friday 21 November 2008 17:02, Johannes Berg wrote: On Fri, 2008-11-21 at 16:37 +0100, Joachim Fenkes wrote: + u64 flags; - spin_lock(shca_list_lock); + spin_lock_irqsave(shca_list_lock, flags); That's wrong and I think will give a warning on all machines where u64 != unsigned long. Might not particularly matter in this case. Doesn't matter for a ppc64 only driver, but you're right nonetheless. Thanks. Also, generally it seems wrong to say fix lockdep failure when the patch really fixes a bug that lockdep happened to find. Whatever -- changed. Here's the updated patch. Regards, Joachim drivers/infiniband/hw/ehca/ehca_main.c | 17 ++--- 1 files changed, 10 insertions(+), 7 deletions(-) diff --git a/drivers/infiniband/hw/ehca/ehca_main.c b/drivers/infiniband/hw/ehca/ehca_main.c index bb02a86..169aa1a 100644 --- a/drivers/infiniband/hw/ehca/ehca_main.c +++ b/drivers/infiniband/hw/ehca/ehca_main.c @@ -717,6 +717,7 @@ static int __devinit ehca_probe(struct of_device *dev, const u64 *handle; struct ib_pd *ibpd; int ret, i, eq_size; + unsigned long flags; handle = of_get_property(dev-node, ibm,hca-handle, NULL); if (!handle) { @@ -830,9 +831,9 @@ static int __devinit ehca_probe(struct of_device *dev, ehca_err(shca-ib_device, Cannot create device attributes ret=%d, ret); - spin_lock(shca_list_lock); + spin_lock_irqsave(shca_list_lock, flags); list_add(shca-shca_list, shca_list); - spin_unlock(shca_list_lock); + spin_unlock_irqrestore(shca_list_lock, flags); return 0; @@ -878,6 +879,7 @@ probe1: static int __devexit ehca_remove(struct of_device *dev) { struct ehca_shca *shca = dev-dev.driver_data; + unsigned long flags; int ret; sysfs_remove_group(dev-dev.kobj, ehca_dev_attr_grp); @@ -915,9 +917,9 @@ static int __devexit ehca_remove(struct of_device *dev) ib_dealloc_device(shca-ib_device); - spin_lock(shca_list_lock); + spin_lock_irqsave(shca_list_lock, flags); list_del(shca-shca_list); - spin_unlock(shca_list_lock); + spin_unlock_irqrestore(shca_list_lock, flags); return ret; } @@ -975,6 +977,7 @@ static int ehca_mem_notifier(struct notifier_block *nb, unsigned long action, void *data) { static unsigned long ehca_dmem_warn_time; + unsigned long flags; switch (action) { case MEM_CANCEL_OFFLINE: @@ -985,12 +988,12 @@ static int ehca_mem_notifier(struct notifier_block *nb, case MEM_GOING_ONLINE: case MEM_GOING_OFFLINE: /* only ok if no hca is attached to the lpar */ - spin_lock(shca_list_lock); + spin_lock_irqsave(shca_list_lock, flags); if (list_empty(shca_list)) { - spin_unlock(shca_list_lock); + spin_unlock_irqrestore(shca_list_lock, flags); return NOTIFY_OK; } else { - spin_unlock(shca_list_lock); + spin_unlock_irqrestore(shca_list_lock, flags); if (printk_timed_ratelimit(ehca_dmem_warn_time, 30 * 1000)) ehca_gen_err(DMEM operations are not allowed -- 1.5.5 ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: MPC5200B: Trouble with config pins
Jürgen, Have a look at the manual chapter 4 (=Reset + Config). SRESET (issued by gpt0 - watchdog) isn't supposed to do a full hardware reset. Looks like you should make use of the SRESET and trigger HRESET accordingly. I could solve this with _not_ using the internal watchdog but an external one (TPS3828), i.e. watchdog timeouts and reboots are always issued by PORESET. regards, Andre Juergen Beisert schrieb: Hi all, we have trouble with the eth based config pins (ETH0...ETH6) of the MPC5200B CPU. These pins act as the interface to an external phy and also act as configurations pins to configure the size of the flash and other things. While the reset is active these pins should be in their high impedance state and the externally connected pull down resistors should define wire's voltage level. With the rising edge of the reset signal these levels will be latched into internal config registers. We are in trouble when we want to reboot the system (also watchdog based) or the internal watchdog barks and generates the CPU internal reset signal. In these cases these config pins will not change their level! So the wrong settings are latched in and our CPU is dead (misconfigured), sometimes a second reset helps, but most of the time only power cycling helps. What we see is: - at the pins ETH_0 and ETH_3 (both are output only, when used for ethernet) * With an external 10k pulldown these lines never change their 3.3V level even if the reset is active! * With an external 1k pulldown these lines change their 3.3V level down to something about 2.5V when the falling edge of the reset signal occurs. * This level decreases slowly to 1.2V in about 1.2ms and than a falling edge to 0V occures. Problem here is, the internal watchdog's generated reset signal is much shorter, so the rising edge of this reset signal also latches in the wrong settings and the CPU is dead. Some other things we see. A reset while: - a running tftp command in U-Boot with disconnected network - system is always dead - a running tftp command in U-Boot with connected network - system restarts We can see in this case, the ETH_0 and ETH_3 are switching to low level *immediatly* with the falling edge of the reset signal - an activated interface (ifconfig up) in Linux with *disconnected* network - system is always dead - an activated interface (ifconfig up) in Linux with *connected* network - system is always dead Does anybody see a behaviour like ours on his/her MPC5200B based system? Does anybody have an idea what the difference between U-Boot und Linux could be? Bug? Feature? Regards, Juergen MATRIX VISION GmbH, Talstraße 16, DE-71570 Oppenweiler - Registergericht: Amtsgericht Stuttgart, HRB 271090 Geschäftsführer: Gerhard Thullner, Werner Armingeon, Uwe Furtner ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: MPC5200B: Trouble with config pins
Hi Andre, On Freitag, 21. November 2008, Andre Schwarz wrote: Have a look at the manual chapter 4 (=Reset + Config). SRESET (issued by gpt0 - watchdog) isn't supposed to do a full hardware reset. Looks like you should make use of the SRESET and trigger HRESET accordingly. I could solve this with _not_ using the internal watchdog but an external one (TPS3828), i.e. watchdog timeouts and reboots are always issued by PORESET. We are using an external watchdog now. But same behaviour. It hurts less, because we increase the length of the active reset signal to add more time to let the pin find its low level. But I'm not really happy about this solution... Regards, Juergen -- Dipl.-Ing. Juergen Beisert | http://www.pengutronix.de Pengutronix - Linux Solutions for Science and Industry Handelsregister: Amtsgericht Hildesheim, HRA 2686 Vertretung Sued/Muenchen, Germany Phone: +49-8766-939 228 | Fax: +49-5121-206917-9 ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] cpm2: Round the baud-rate clock divider to the nearest integer.
Laurent Pinchart wrote: On Thursday 20 November 2008, Scott Wood wrote: This makes things worse on mpc8272ads -- the result of the division is 13.56, but I only get error-free serial output when rounding down. I don't think the remote end has timing problems, as I don't see this with any other board. I get exactly the opposite here with an mpc8248 base board. Rounding down makes 115200bds completely unreliable :-/ Hmm... In that case, I'm OK with the patch as it's technically more correct, and clearly what we want if the quotient comes out to something like 13.95. Maybe mpc8272ads board code could apply some sort of tweak to the brg frequency. The right answer is probably that if you want reliable standard baud rates, the board designer should ensure a suitable clock is available, rather than picking some random clock and hoping it divides nicely. Could you measure the serial baudrate with and without the patch using an oscilloscope ? Not easily; I'm a software person and would have to track down someone to lend me one and show me how to use it. I may try using ntpdate to measure timebase drift, as it should be off by the same percentage. Maybe we should change CPM_CLK to be MAIN_CLK/4 rather than MAIN_CLK/16 when the BRG clock is below a certain frequency. Isn't that the job of the boot loader ? Sure, I didn't necessarily mean linux by we. :-) Accuracy would be improved, but power consumption will raise as well :-/ Granted... though it's actually BRG_CLK and not CPM_CLK that I meant, so hopefully it wouldn't make too much of a difference in power. -Scott ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [spi-devel-general] [PATCH v4] spi: Add PPC4xx SPI driver
Dave, On Friday 21 November 2008, David Brownell wrote: On Friday 31 October 2008, Stefan Roese wrote: + dev_dbg(spi-dev, %s: mode %d, %u bpw, %d hz\n, + __FUNCTION__, spi-mode, spi-bits_per_word, + spi-max_speed_hz); Oh, and checkpatch.pl would warn about __FUNCTION__ vs __func__ ... Thanks for the review. I'll address the issues in an updated patch next week. Best regards, Stefan ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] IB/ehca: Fix locking for shca_list_lock
Looks good... I'll add this for 2.6.29, since as far as I can tell this bug has been there approximately forever already. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: powerpc: udbg based backend for hvc_console
On Nov 21, 2008, at 10:13 AM, Timur Tabi wrote: Milton Miller wrote: We want the last console= parameter on the command line to win. So if that implys the last call to add_preferred_console wins, then you have code overriding the command line. Hmm, good point. However, how likely is it that we'll have more than one console driver? For anything than custom embedded configs, quite likely. As I said, I have 3 hvc clients, but that is unusual. But frame buffer, vterm, rtas, and serial console would be a typical mix for a distribution. Also, without calling add_preferred_console(), the kernel needs to have a console= on the command line. I'm not arguing against the call, I'm arguing when/from where it should be made. In my case, my driver only calls add_preferred_console() if the device tree contains a specific property that it looks for. In effect, this property override the console= line. However, the console= line goes to the HVC subsystem, and not my driver, and I can't use it to send the configuration data the driver needs. Discovering the hardware from the device tree and triggering your regitration is the right approach. I think if you discover from an early setup then you can go before the command line. As far as getting parameters, you are talking like ttyS0,9600,8,n,1 ? If you go after hvc_console then you could add a patch for hvc_console to remember the setup and return it to possible clients. Unfortunately, my driver hasn't been published yet, so it's hard to explain the details. I guess I need to think about this more. I dont' know what details you would want on the console= command line that you should not have in the device tree. If its which hypervisor channel, then I would think just choosing your hvc number accordingly would work. But I can only make wild guesses without details. milton ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: powerpc: udbg based backend for hvc_console
On Nov 20, 2008, at 6:35 PM, David Gibson wrote: On Thu, Nov 20, 2008 at 01:07:11PM -0600, Milton Miller wrote: David Gibson wrote at 2008-11-18 00:28:28: On Mon, Nov 17, 2008 at 01:41:24PM -0600, Timur Tabi wrote: On Thu, Oct 23, 2008 at 9:54 PM, David Gibson [EMAIL PROTECTED] wrote: This patch adds a new backend for the hvc console based on the low-level udbg callbacks. This effectively implements a working runtime console in terms of the simple udbg primitives. This is kind of a hack - since udbg isn't something you really want to be using routinely - but it's really useful during bringup. Why is udbg hvc something you want to not use routinely? Well.. because the udbg methods themselves are not sometimes (not always, but reasonably often), something you don't really want to use except during bringup. A number of them use various hacks that lets them work very early, and very reliably even when much of the kernel is borked, but aren't the sort of thing you want to do except during bringup. e.g. being mapped by special bolted TLB entries established very early, rather than using ioremap(); polled access for interrupt capable devices; hard-coded device addresses, meaning the kernel will only work on one precise type of system. You are describing the CONFIG_PPC_DEBUG_EARLY udbg methods, but they are far from all of the available methods. Several methods use the standard kernel apis, or do not need them (rtas, vterm). If we had this, would we need hvc_rtas? Stated differently, if your routine (1) fundamently works one character at a time and (2) is not interrupt driven, and (3) only supports one channel, what avantage is there to an explicit hvc driver? Using standard kernel interfaces, instead of random early debug hacks. I was thinking of the less hackish udbg hooks that registsered in the platform setup timeframe. Not requiring a pinned tlb that you would not want for io performance anyways I can see. Actually it looks remarkably similar to a cleaned up version of a patch i've been using since hvc_console was split to be a hookable shell. Or was it the motivation for adding the hooks? Heh, ok. ... Um.. well.. if you have both activated, I think you can select which HVC console backend will be used by using console=/dev/hvcNN on the commandline, where values of NN correspond to different backends, in order depending on link order in some complex fashion. It doesn't just work that way because of the way the hvc_console shell implements the console hooks. If the drivers request different hvc channel numbers, then yes, you can select which hvc backend is used by choosing console=hvcNN. If all request 0, then which ever one registers with hvc_console first wins the slot, and the others get a busy error return. They can still register their tty later, at which point they get a dynamically determined /dev/hvcN slot, above all registered console slots. Ah, ok, my mistake. There are multiple reasons for this design. The original user, pseries vterm, wants to assign the channel number based on what the hypervisor tells it the channel should be. There are two loops though the device tree, searching for different protocols (and consequently different backends), so they need to be able to specify the number and not just use the order they are found. The platform describes not only the protocol, but which instance that is, and the backend currently registers with that number. Another reason is its a bad idea to have console=/dev/hvc0 depend on link order instead of knowing which driver is selected. If a user is specifing what the console is, it should not depend on other linked drivers. Until this point, all mainline drivers have been exclusive in that only one will actually register with hvc_console midlayer on any given platform. This is the first backend that is not exclusive, and therefore its coexistence needs special attention. In my internal tree, I register (my version of) this not as hvc0 but as hvc4. hvc0 is rtas, hvc1-3 are an internal backend, and this one is hvc4. The order I chose is arbitrary, but the main point is it does't compete with hvc_rtas for slot 0. (All of these drivers coexist, and I can choose which one I want to use based on my needs for that boot.) We could make it configurable via Kconfig, or just choose a slot. (I think vterm can have 2 channels on some boxes where they drive real serial ports on the box.) Hrm, ok. Not sure what the sensible way to do this for my case would be. But if you already have a working HVC console driver, I don't see why you'd want to use HVC_UDBG - it's essentially a bringup hack. As I said, why should we need a fancier hvc_console backend if you are polling and gain no efficency processing multiple characters at once. The udbg drivers know if they are sharing the interface with a hvc_console some other driver. If we trigger the registration of this backend on the
Re: [PATCH] powerpc/mpic: don't reset affinity for secondary MPIC on boot
On Fri, 2008-11-21 at 15:40 +0100, Arnd Bergmann wrote: On Friday 21 November 2008, Benjamin Herrenschmidt wrote: Oh just that for powermac for example, I know I'm resetting the thing, so can't rely on init values, and on some BML embedded boxes too, while on things like cell I don't off hand know what the right CPU number is to hit the right C3PO interrupt, so I'm better off reading what SLOF did :-) The current code will always use destination 0 for any MPIC, because mpic_init is run befew smp_init and it currently uses the local CPU. If an SMP powermac requires a specific destination setting in the secondary MPIC, either the current mpic_init code is broken there in the same way as on cell, or more broken if it requires something other than destination 0. But if you think on Cell we can just hard wire in the platform code, then I'm ok. On cell, I know that destination 0 is always correct because of the wiring inside of Axon. Ok so -all- existing instances only care about destination 0, we may just hard code that in MPIC for now :-) Cheers, Ben. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Nodes with no memory
I was handed off a bug report about a blade not booting with a, um newer kernel. After turning on some debugging messages, I got this ominous message: node 1 NODE_DATA() = c000 Which obviously comes from here: arch/powerpc/mm/numa.c for_each_online_node(nid) { unsigned long start_pfn, end_pfn; unsigned long bootmem_paddr; unsigned long bootmap_pages; get_pfn_range_for_nid(nid, start_pfn, end_pfn); /* Allocate the node structure node local if possible */ NODE_DATA(nid) = careful_allocation(nid, sizeof(struct pglist_data), SMP_CACHE_BYTES, end_pfn); NODE_DATA(nid) = __va(NODE_DATA(nid)); memset(NODE_DATA(nid), 0, sizeof(struct pglist_data)); ... careful_allocation() returns a NULL physical address, but we go ahead and run __va() on it, stick it in NODE_DATA(), and memset it. Yay! I seem to recall that we fixed some issues with memoryless nodes a few years ago, like around the memory hotplug days, but I don't see the patches anywhere. I'm thinking that we need to at least fix careful_allocation() to oops and not return NULL, or check to make sure all it callers check its return code. Plus, we probably also need to ensure that all ppc code doing for_each_online_node() does not assume a valid NODE_DATA() for all those nodes. Any other thoughts? I'll have a patch for the above issue sometime soon. -- Dave ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Nodes with no memory
Dave Hansen wrote: I was handed off a bug report about a blade not booting with a, um newer kernel. If you're unable to provide basic information such as the kernel version then perhaps this isn't the best forum for discussing this. :) I'm thinking that we need to at least fix careful_allocation() to oops and not return NULL, or check to make sure all it callers check its return code. Well, careful_allocation() in current mainline tries pretty hard to panic if it can't satisfy the request. Why isn't that happening? ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev