Allocator MAX_ORDER exceeds SECTION_SIZE
I get the following compilation failure, if 64k pages is selected on 2.6.32.3 on a PowerMAC config: include/linux/mmzone.h:947:2: error: #error Allocator MAX_ORDER exceeds SECTION_SIZE Any idea? -- Greetings, Michael. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: Allocator MAX_ORDER exceeds SECTION_SIZE
On Sunday 10 January 2010 14:31:09 Michael Buesch wrote: I get the following compilation failure, if 64k pages is selected on 2.6.32.3 on a PowerMAC config: include/linux/mmzone.h:947:2: error: #error Allocator MAX_ORDER exceeds SECTION_SIZE Any idea? Ok, I figured out that lowering CONFIG_FORCE_MAX_ZONEORDER from 13 to 9 seems to fix the problem. That error message could really need some improvement and at least a hint on what to do and why. I'm also wondering, if the kconfig entry for CONFIG_FORCE_MAX_ZONEORDER could somehow be limited to 9, if 64k pages is enabled. -- Greetings, Michael. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: Accessing flash directly from User Space [SOLVED]
On Saturday 31 October 2009 14:26:48 Joakim Tjernlund wrote: On Friday 30 October 2009 16:08:55 Alessandro Rubini wrote: asm(eieio; sync); Hmm... : : : memory And, doesn't ; start a comment in assembly? (no, not on powerpc it seems) Yes, I think the barrier is wrong. Please try with #define mb() __asm__ __volatile__(eieio\n sync\n : : : memory) That definition worked great. I must have missed the : : : memory bit when I was digging through code. Thanks, that gives me about a 2x speedup over the msync() calls. Exactly when should you use the barrier? At every access, every read or when changing from write to read? Well, it depends on the device you are accessing. I'll give you a small pseudo example. mmio[0] = address; mmio[1] = data; mb(); mmio[3] |= 0x01; /* This triggers an operation - address=data */ /* probably also need an mb() here, if the following code * depends on the operation to be triggered. */ -- Greetings, Michael. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: Accessing flash directly from User Space [SOLVED]
On Saturday 31 October 2009 21:14:07 Joakim Tjernlund wrote: Michael Buesch m...@bu3sch.de wrote on 31/10/2009 17:42:54: On Saturday 31 October 2009 14:26:48 Joakim Tjernlund wrote: On Friday 30 October 2009 16:08:55 Alessandro Rubini wrote: asm(eieio; sync); Hmm... : : : memory And, doesn't ; start a comment in assembly? (no, not on powerpc it seems) Yes, I think the barrier is wrong. Please try with #define mb() __asm__ __volatile__(eieio\n sync\n : : : memory) That definition worked great. I must have missed the : : : memory bit when I was digging through code. Thanks, that gives me about a 2x speedup over the msync() calls. Exactly when should you use the barrier? At every access, every read or when changing from write to read? Well, it depends on the device you are accessing. I'll give you a small pseudo example. mmio[0] = address; mmio[1] = data; mb(); mmio[3] |= 0x01; /* This triggers an operation - address=data */ /* probably also need an mb() here, if the following code * depends on the operation to be triggered. */ So anything that depends on the previous accesses needs a mb() No, not really. I would always put an mb() where the comment is. Imagine you have two instances of the above (probably in a loop): mmio[0] = address; mmio[1] = data; mb(); mmio[3] |= 0x01; /* This triggers an operation - address=data */ mb(); mmio[0] = address; mmio[1] = data; mb(); mmio[3] |= 0x01; /* This triggers an operation - address=data */ mb(); hmm, the mmio[0] and mmio[1] are written in order I hope? We do not care in this example, as the write to [3] does trigger the device operation. We do only care that [0] and [1] are set when [3] is written. We do not care in what order [0] and [1] are written. This is just an artificial example, but I think you get my point. My point just being is that an mb() does only belong where it matters. And what matters is defined by your device specifications. -- Greetings, Michael. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: Accessing flash directly from User Space [SOLVED]
On Friday 30 October 2009 16:08:55 Alessandro Rubini wrote: asm(eieio; sync); Hmm... : : : memory And, doesn't ; start a comment in assembly? (no, not on powerpc it seems) Yes, I think the barrier is wrong. Please try with #define mb()__asm__ __volatile__(eieio\n sync\n : : : memory) -- Greetings, Michael. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: Network Stack SKB Reallocation
On Monday 26 October 2009 19:43:00 Jonathan Haws wrote: Quick question about the network stack in general: Does the stack itself release an SKB allocated by the device driver back to the heap upstream, or does it require that the device driver handle that? There's the concept of passing responsibilities for the frames between the networking layers. So the driver passes the frame and all responsibilities to the networking stack. So if the networking stack accepts the packet in the first place, it needs to free it (or pass it to somebody else to take care of). -- Greetings, Michael. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 01/10] Add support for GCC-4.5's __builtin_unreachable() to compiler.h
On Friday 11 September 2009 01:56:42 David Daney wrote:
+/* Unreachable code */
+#ifndef unreachable
+# define unreachable() do { for (;;) ; } while (0)
+#endif
# define unreachable() do { } while (1)
? :)
--
Greetings, Michael.
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] viotape: Fix memory and semaphore leak
On Thursday 13 August 2009 07:00:03 Benjamin Herrenschmidt wrote: On Sat, 2009-07-18 at 15:06 +0200, Michael Buesch wrote: This patch fixes a memory and semaphore leak in the viotape driver's char device write op. It leaks the DMA memory and the semaphore lock in case the device was opened with O_NONBLOCK. This patch is only compile tested, because I do not have the hardware. Signed-off-by: Michael Buesch m...@bu3sch.de (going trough my backlog ...) Thanks Michael, but I don't think that's right... IE. We aren't waiting for the write to complete, which means that it can be happening asynchronously, thus we must not free the DMA memory until it has actually complete. Now, if you look at vioHandleTapeEvent(), it does appear that when the completion happens, the DMA memory will eventually be released and the mutex up'ed. Or am I missing something ? I think you are right. -- Greetings, Michael. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH] viotape: Fix memory and semaphore leak
This patch fixes a memory and semaphore leak in the viotape driver's
char device write op. It leaks the DMA memory and the semaphore lock
in case the device was opened with O_NONBLOCK.
This patch is only compile tested, because I do not have the hardware.
Signed-off-by: Michael Buesch m...@bu3sch.de
---
drivers/char/viotape.c | 19 ++-
1 file changed, 10 insertions(+), 9 deletions(-)
--- linux-2.6.orig/drivers/char/viotape.c
+++ linux-2.6/drivers/char/viotape.c
@@ -401,30 +401,31 @@ static ssize_t viotap_write(struct file
viopath_targetinst(viopath_hostLp),
(u64)(unsigned long)op, VIOVERSION 16,
((u64)devi.devno 48) | op-dmaaddr, count, 0, 0);
if (hvrc != HvLpEvent_Rc_Good) {
printk(VIOTAPE_KERN_WARN hv error on op %d\n,
(int)hvrc);
ret = -EIO;
goto free_dma;
}
- if (noblock)
- return count;
-
- wait_for_completion(op-com);
+ if (noblock) {
+ ret = count;
+ } else {
+ wait_for_completion(op-com);
- if (op-rc)
- ret = tape_rc_to_errno(op-rc, write, devi.devno);
- else {
- chg_state(devi.devno, VIOT_WRITING, file);
- ret = op-count;
+ if (op-rc)
+ ret = tape_rc_to_errno(op-rc, write, devi.devno);
+ else {
+ chg_state(devi.devno, VIOT_WRITING, file);
+ ret = op-count;
+ }
}
free_dma:
dma_free_coherent(op-dev, count, op-buffer, op-dmaaddr);
up_sem:
up(reqSem);
free_op:
free_op_struct(op);
return ret;
}
--
Greetings, Michael.
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: Random crashes with 2.6.27-rc3 on PPC
On Sunday 24 August 2008 00:52:49 Benjamin Herrenschmidt wrote: On Sat, 2008-08-23 at 16:10 +0200, Michael Buesch wrote: I am seeing random kernel and userland application crashes on a Powerbook running a 2.6.27-rc3 based kernel (wireless-testing.git). The crashes did recently appear. It might be the case that they were introduced with the merge of 2.6.27-rc1 into wireless-testing. I'm not sure on that one, however. Just a guess. I still need to do more testing (also on vanilla upstream kernels). The crashes are completely random and they look like bad hardware. However I cannot reproduce on 2.6.25.9 (That's a kernel I still had installed, so I tried that one). So it most likely is _not_ caused by faulty hardware. The crashes are hard to reproduce, and happen about every 20 minutes when compiling a kernel tree. (gcc segfaults). Sometimes the kernel oopses in random places with pointer dereference faults. Is this a known issue? I'm going to bisect this one, but it will take a lot of time, as reproducing takes about 20 minutes. So that's about an hour for one test round. The kernel configuration is the following: Random guess: CONFIG_FRAME_POINTER=y CONFIG_SCHED_NO_NO_OMIT_FRAME_POINTER=y Note sure what those together do, check if you have any file compiled with -fno-omit-frame-pointer and if you do, try to change things so that you don't ... we found some miscompiles when that is set, exposed by FTRACE typically (which you don't have enabled) but possibly by other things. Ok, thanks for the suggestion. I could reproduce the crash with 2.6.26, so this is not a regression between 2.6.26 and 2.6.27-rcX. I'm currently running longer tests on 2.6.25 again to make sure it really isn't hardware related. NO_NO_OMIT is a brain screwer, btw :) -- Greetings Michael. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Random crashes with 2.6.27-rc3 on PPC
On Sunday 24 August 2008, Benjamin Herrenschmidt wrote:
Random guess:
CONFIG_FRAME_POINTER=y
CONFIG_SCHED_NO_NO_OMIT_FRAME_POINTER=y
Note sure what those together do, check if you have any file compiled
with -fno-omit-frame-pointer and if you do, try to change things so
that you don't ... we found some miscompiles when that is set, exposed
by FTRACE typically (which you don't have enabled) but possibly by other
things.
Thanks for your random guess.
The following workaround seems to fix the crashes on powerpc.
However, this patch is clearly not what we want for other architectures,
as they might need -fno-omit-frame-pointer to function properly.
I reproduced the random crashes of kernel and userspace applications
(without the following patch) on a vanilla 2.6.26 and 2.6.27-rc{1-4}
kernel. I did _not_ try a 2.6.25 kernel with -fno-omit-frame-pointer, so
I don't know if it would also crash then.
I'm currently running more tests on a patched 2.6.27-rc4 kernel, but it
didn't crash, yet. I already did 5 complete kernel tree compilations. It
should have crashed by now, but it didn't :)
The compiler is:
gcc (GCC) 4.1.3 20070929 (prerelease) (Ubuntu 4.1.2-16ubuntu2)
Index: linux-2.6/Makefile
===
--- linux-2.6.orig/Makefile 2008-08-24 11:49:53.0 +0200
+++ linux-2.6/Makefile 2008-08-24 12:16:42.0 +0200
@@ -523,13 +523,13 @@ endif
# Force gcc to behave correct even for buggy distributions
# Arch Makefiles may override this setting
KBUILD_CFLAGS += $(call cc-option, -fno-stack-protector)
ifdef CONFIG_FRAME_POINTER
-KBUILD_CFLAGS += -fno-omit-frame-pointer -fno-optimize-sibling-calls
+KBUILD_CFLAGS += -fno-optimize-sibling-calls
else
KBUILD_CFLAGS += -fomit-frame-pointer
endif
ifdef CONFIG_DEBUG_INFO
KBUILD_CFLAGS += -g
Index: linux-2.6/kernel/Makefile
===
--- linux-2.6.orig/kernel/Makefile 2008-08-24 11:50:23.0 +0200
+++ linux-2.6/kernel/Makefile 2008-08-24 12:15:54.0 +0200
@@ -92,13 +92,13 @@ obj-$(CONFIG_SMP) += sched_cpupri.o
ifneq ($(CONFIG_SCHED_NO_NO_OMIT_FRAME_POINTER),y)
# According to Alan Modra [EMAIL PROTECTED], the -fno-omit-frame-pointer is
# needed for x86 only. Why this used to be enabled for all architectures is
beyond
# me. I suspect most platforms don't need this, but until we know that for
sure
# I turn this off for IA-64 only. Andreas Schwab says it's also needed on m68k
# to get a correct value for the wait-channel (WCHAN in ps). --davidm
-CFLAGS_sched.o := $(PROFILING) -fno-omit-frame-pointer
+CFLAGS_sched.o := $(PROFILING)
endif
$(obj)/configs.o: $(obj)/config_data.h
# config_data.h contains the same information as ikconfig.h but gzipped.
# Info from config_data can be extracted from /proc/config*
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Random crashes with 2.6.27-rc3 on PPC
On Sunday 24 August 2008 16:46:38 Andreas Schwab wrote: Michael Buesch [EMAIL PROTECTED] writes: The following workaround seems to fix the crashes on powerpc. However, this patch is clearly not what we want for other architectures, as they might need -fno-omit-frame-pointer to function properly. This has a better chance to be accepted. :-) diff --git a/lib/Kconfig.debug b/lib/Kconfig.debug index 8b5a7d3..f9a2e48 100644 --- a/lib/Kconfig.debug +++ b/lib/Kconfig.debug @@ -394,7 +394,7 @@ config LOCKDEP bool depends on DEBUG_KERNEL TRACE_IRQFLAGS_SUPPORT STACKTRACE_SUPPORT LOCKDEP_SUPPORT select STACKTRACE - select FRAME_POINTER if !X86 !MIPS + select FRAME_POINTER if !X86 !MIPS !PPC select KALLSYMS select KALLSYMS_ALL This is not what my patch is doing. Your patch always forces FRAME_POINTER off. At least as far as lockdep is concerned. What about other parts of the kernel that enable FRAME_POINTER? I think this should be fixed in the makefile by substitution of -fno-omit-frame-pointer on PPC (and probably depending on the compiler version). Otherwise, if somebody else decides to do select FRAME_POINTER in some other code, the bug will reappear. I'm also not sure if it's desired to always force FRAME_POINTER off. -- Greetings Michael. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Random crashes with 2.6.27-rc3 on PPC
I am seeing random kernel and userland application crashes on a Powerbook running a 2.6.27-rc3 based kernel (wireless-testing.git). The crashes did recently appear. It might be the case that they were introduced with the merge of 2.6.27-rc1 into wireless-testing. I'm not sure on that one, however. Just a guess. I still need to do more testing (also on vanilla upstream kernels). The crashes are completely random and they look like bad hardware. However I cannot reproduce on 2.6.25.9 (That's a kernel I still had installed, so I tried that one). So it most likely is _not_ caused by faulty hardware. The crashes are hard to reproduce, and happen about every 20 minutes when compiling a kernel tree. (gcc segfaults). Sometimes the kernel oopses in random places with pointer dereference faults. Is this a known issue? I'm going to bisect this one, but it will take a lot of time, as reproducing takes about 20 minutes. So that's about an hour for one test round. The kernel configuration is the following: # # Automatically generated make config: don't edit # Linux kernel version: 2.6.27-rc3 # Fri Aug 22 18:57:55 2008 # # CONFIG_PPC64 is not set # # Processor support # CONFIG_6xx=y # CONFIG_PPC_85xx is not set # CONFIG_PPC_8xx is not set # CONFIG_40x is not set # CONFIG_44x is not set # CONFIG_E200 is not set CONFIG_PPC_FPU=y CONFIG_ALTIVEC=y CONFIG_PPC_STD_MMU=y CONFIG_PPC_STD_MMU_32=y # CONFIG_PPC_MM_SLICES is not set # CONFIG_SMP is not set CONFIG_PPC32=y CONFIG_WORD_SIZE=32 CONFIG_PPC_MERGE=y CONFIG_MMU=y CONFIG_GENERIC_CMOS_UPDATE=y CONFIG_GENERIC_TIME=y CONFIG_GENERIC_TIME_VSYSCALL=y CONFIG_GENERIC_CLOCKEVENTS=y CONFIG_GENERIC_HARDIRQS=y # CONFIG_HAVE_SETUP_PER_CPU_AREA is not set CONFIG_IRQ_PER_CPU=y CONFIG_STACKTRACE_SUPPORT=y CONFIG_HAVE_LATENCYTOP_SUPPORT=y CONFIG_LOCKDEP_SUPPORT=y CONFIG_RWSEM_XCHGADD_ALGORITHM=y CONFIG_ARCH_HAS_ILOG2_U32=y CONFIG_GENERIC_HWEIGHT=y CONFIG_GENERIC_CALIBRATE_DELAY=y CONFIG_GENERIC_FIND_NEXT_BIT=y CONFIG_GENERIC_GPIO=y # CONFIG_ARCH_NO_VIRT_TO_BUS is not set CONFIG_PPC=y CONFIG_EARLY_PRINTK=y CONFIG_GENERIC_NVRAM=y CONFIG_SCHED_NO_NO_OMIT_FRAME_POINTER=y CONFIG_ARCH_MAY_HAVE_PC_FDC=y CONFIG_PPC_OF=y CONFIG_OF=y # CONFIG_PPC_UDBG_16550 is not set # CONFIG_GENERIC_TBSYNC is not set CONFIG_AUDIT_ARCH=y CONFIG_GENERIC_BUG=y # CONFIG_DEFAULT_UIMAGE is not set CONFIG_HIBERNATE_32=y CONFIG_ARCH_HIBERNATION_POSSIBLE=y CONFIG_ARCH_SUSPEND_POSSIBLE=y # CONFIG_PPC_DCR_NATIVE is not set # CONFIG_PPC_DCR_MMIO is not set CONFIG_DEFCONFIG_LIST=/lib/modules/$UNAME_RELEASE/.config # # General setup # CONFIG_EXPERIMENTAL=y CONFIG_BROKEN_ON_SMP=y CONFIG_LOCK_KERNEL=y CONFIG_INIT_ENV_ARG_LIMIT=32 CONFIG_LOCALVERSION=-wltest # CONFIG_LOCALVERSION_AUTO is not set CONFIG_SWAP=y CONFIG_SYSVIPC=y CONFIG_SYSVIPC_SYSCTL=y CONFIG_POSIX_MQUEUE=y CONFIG_BSD_PROCESS_ACCT=y # CONFIG_BSD_PROCESS_ACCT_V3 is not set # CONFIG_TASKSTATS is not set # CONFIG_AUDIT is not set CONFIG_IKCONFIG=y CONFIG_IKCONFIG_PROC=y CONFIG_LOG_BUF_SHIFT=19 # CONFIG_CGROUPS is not set CONFIG_GROUP_SCHED=y CONFIG_FAIR_GROUP_SCHED=y # CONFIG_RT_GROUP_SCHED is not set CONFIG_USER_SCHED=y # CONFIG_CGROUP_SCHED is not set # CONFIG_SYSFS_DEPRECATED_V2 is not set # CONFIG_RELAY is not set # CONFIG_NAMESPACES is not set # CONFIG_BLK_DEV_INITRD is not set CONFIG_CC_OPTIMIZE_FOR_SIZE=y CONFIG_SYSCTL=y CONFIG_EMBEDDED=y CONFIG_SYSCTL_SYSCALL=y CONFIG_SYSCTL_SYSCALL_CHECK=y CONFIG_KALLSYMS=y CONFIG_KALLSYMS_ALL=y # CONFIG_KALLSYMS_EXTRA_PASS is not set CONFIG_HOTPLUG=y CONFIG_PRINTK=y CONFIG_BUG=y CONFIG_ELF_CORE=y # CONFIG_COMPAT_BRK is not set CONFIG_BASE_FULL=y CONFIG_FUTEX=y CONFIG_ANON_INODES=y CONFIG_EPOLL=y CONFIG_SIGNALFD=y CONFIG_TIMERFD=y CONFIG_EVENTFD=y CONFIG_SHMEM=y CONFIG_VM_EVENT_COUNTERS=y CONFIG_SLUB_DEBUG=y # CONFIG_SLAB is not set CONFIG_SLUB=y # CONFIG_SLOB is not set CONFIG_PROFILING=y # CONFIG_MARKERS is not set CONFIG_OPROFILE=y CONFIG_HAVE_OPROFILE=y # CONFIG_KPROBES is not set CONFIG_HAVE_EFFICIENT_UNALIGNED_ACCESS=y CONFIG_HAVE_IOREMAP_PROT=y CONFIG_HAVE_KPROBES=y CONFIG_HAVE_KRETPROBES=y CONFIG_HAVE_ARCH_TRACEHOOK=y # CONFIG_HAVE_DMA_ATTRS is not set # CONFIG_USE_GENERIC_SMP_HELPERS is not set CONFIG_HAVE_CLK=y CONFIG_PROC_PAGE_MONITOR=y # CONFIG_HAVE_GENERIC_DMA_COHERENT is not set CONFIG_SLABINFO=y CONFIG_RT_MUTEXES=y # CONFIG_TINY_SHMEM is not set CONFIG_BASE_SMALL=0 CONFIG_MODULES=y # CONFIG_MODULE_FORCE_LOAD is not set CONFIG_MODULE_UNLOAD=y CONFIG_MODULE_FORCE_UNLOAD=y # CONFIG_MODVERSIONS is not set # CONFIG_MODULE_SRCVERSION_ALL is not set CONFIG_KMOD=y CONFIG_BLOCK=y # CONFIG_LBD is not set # CONFIG_BLK_DEV_IO_TRACE is not set # CONFIG_LSF is not set # CONFIG_BLK_DEV_BSG is not set # CONFIG_BLK_DEV_INTEGRITY is not set # # IO Schedulers # CONFIG_IOSCHED_NOOP=y # CONFIG_IOSCHED_AS is not set # CONFIG_IOSCHED_DEADLINE is not set CONFIG_IOSCHED_CFQ=y # CONFIG_DEFAULT_AS is not set # CONFIG_DEFAULT_DEADLINE is not set CONFIG_DEFAULT_CFQ=y # CONFIG_DEFAULT_NOOP is not set CONFIG_DEFAULT_IOSCHED=cfq #
Re: [PATCH v2] powerpc: Do not fail build if mkimage is not available
On Thursday 27 December 2007 11:14:04 Wolfgang Denk wrote: In message [EMAIL PROTECTED] you wrote: On Wednesday 26 December 2007 17:03:43 Andreas Schwab wrote: Michael Buesch [EMAIL PROTECTED] writes: +set +e mkimage -A ppc -O linux -T kernel -C gzip -a -e \ $uboot_version -d $vmz $ofile +[ $? -eq 0 ] || exit 0 +set -e mkimage ... || exit 0 Could you PLEASE increase your verbosity? Why is mkimage || exit 0 any better than my test? Because it works, while your's doesn't. Make runs each command in a new shell. Your set +e is in vain, and so is your test of the return code. Um... doesn't make throw an error anyway when the execution of mkimage fails? I'm not sure what you are talking about at all, sorry. set +e simply disables the abortion of the shell script if the mkimage command fails. The test after that checks whether it failed and returns success in that event, so the calling makefile does _not_ interrupt. It only gives you a mkimage not found message. I did test this patch on my machine where there is no mkimage and it correctly aborts the shell script and throws an error, while it does not abort the makefile process. And that is what we want. -- Greetings Michael. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH] powerpc: Do not fail build if mkimage is not available
This fixes the boot image wrapper script to not fail the kernel build if mkimage is not available. As some distributions don't ship the mkimage program and some people are not interested in uboot images anyway, we don't want to fail the whole kernel build process because of this unneeded dependency. Simply drop an error message, but don't fail the build. Signed-off-by: Michael Buesch [EMAIL PROTECTED] --- Josh Boyer is working on merging mkimage into the kernel tree. Until that happened, please merge the patch below into the mainline kernel to avoid build breakage for people without installed uboot tools. Index: wireless-2.6/arch/powerpc/boot/wrapper === --- wireless-2.6.orig/arch/powerpc/boot/wrapper 2007-12-23 20:10:07.0 +0100 +++ wireless-2.6/arch/powerpc/boot/wrapper 2007-12-23 20:22:41.0 +0100 @@ -195,6 +195,14 @@ if [ -n $version ]; then fi case $platform in +cuboot* | uboot) +if ! [ -x mkimage ]; then +echo mkimage not available. Can not create $platform image. +exit 0 +fi +esac + +case $platform in uboot) rm -f $ofile mkimage -A ppc -O linux -T kernel -C gzip -a -e \ ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] powerpc: Do not fail build if mkimage is not available
On Wednesday 26 December 2007 15:47:05 Andreas Schwab wrote: Michael Buesch [EMAIL PROTECTED] writes: +if ! [ -x mkimage ]; then What is this supposed to test? from man test: -x FILE FILE exists and execute (or search) permission is granted -- Greetings Michael. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] powerpc: Do not fail build if mkimage is not available
On Wednesday 26 December 2007 16:33:57 Andreas Schwab wrote: Michael Buesch [EMAIL PROTECTED] writes: On Wednesday 26 December 2007 15:47:05 Andreas Schwab wrote: Michael Buesch [EMAIL PROTECTED] writes: +if ! [ -x mkimage ]; then What is this supposed to test? from man test: You didn't answer my question. I'm not sure how I can make the manual text any clearer -x FILE FILE exists and execute (or search) permission is granted It tests if the program exists and is executable. Could you please be more specific about what you don't understand? That would help a lot not wasting my time. -- Greetings Michael. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH v2] powerpc: Do not fail build if mkimage is not available
This fixes the boot image wrapper script to not fail the kernel build if mkimage is not available. As some distributions don't ship the mkimage program and some people are not interested in uboot images anyway, we don't want to fail the whole kernel build process because of this unneeded dependency. Simply drop an error message, but don't fail the build. Signed-off-by: Michael Buesch [EMAIL PROTECTED] --- Josh Boyer is working on merging mkimage into the kernel tree. Until that happened, please merge the patch below into the mainline kernel to avoid build breakage for people without installed uboot tools. Index: wireless-2.6/arch/powerpc/boot/wrapper === --- wireless-2.6.orig/arch/powerpc/boot/wrapper 2007-12-26 16:48:47.0 +0100 +++ wireless-2.6/arch/powerpc/boot/wrapper 2007-12-26 16:52:58.0 +0100 @@ -197,8 +197,11 @@ fi case $platform in uboot) rm -f $ofile +set +e mkimage -A ppc -O linux -T kernel -C gzip -a -e \ $uboot_version -d $vmz $ofile +[ $? -eq 0 ] || exit 0 +set -e if [ -z $cacheit ]; then rm -f $vmz fi @@ -254,8 +257,11 @@ coff) ;; cuboot*) gzip -f -9 $ofile +set +e mkimage -A ppc -O linux -T kernel -C gzip -a $base -e $entry \ $uboot_version -d $ofile.gz $ofile +[ $? -eq 0 ] || exit 0 +set -e ;; treeboot*) mv $ofile $ofile.elf ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] powerpc: Do not fail build if mkimage is not available
On Wednesday 26 December 2007 16:56:57 Andreas Schwab wrote: That would help a lot not wasting my time. How about testing your changes first? Stop the bullshit, please. I tested this and it obviously works very well for me. I even posted it for review on this list and nobody complained, including you. But I see what you are complaining about, now. It would also error out, if mkimage was installed (which is not the case for me. That's the whole reason for me making this patch!). Are you OK with the new version I just sent? -- Greetings Michael. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] powerpc: Do not fail build if mkimage is not available
On Wednesday 26 December 2007 17:08:55 Andreas Schwab wrote: I even posted it for review on this list and nobody complained, including you. ??? I did point out an error in your patch just now. I posted it for review a few days ago and the only response I got was This is probably OK for now... from Josh. -- Greetings Michael. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH v2] powerpc: Do not fail build if mkimage is not available
On Wednesday 26 December 2007 17:03:43 Andreas Schwab wrote: Michael Buesch [EMAIL PROTECTED] writes: +set +e mkimage -A ppc -O linux -T kernel -C gzip -a -e \ $uboot_version -d $vmz $ofile +[ $? -eq 0 ] || exit 0 +set -e mkimage ... || exit 0 Could you PLEASE increase your verbosity? Why is mkimage || exit 0 any better than my test? -- Greetings Michael. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH] Do not fail build if mkimage is not available
This fixes the boot image wrapper script to not fail the kernel build if mkimage is not available. As some distributions don't ship the mkimage program and I am not interested in uboot images anyway, I don't want to fail the whole kernel build process because of this unneeded dependency. Simply drop an error message, but don't fail the build. Signed-off-by: Michael Buesch [EMAIL PROTECTED] Index: wireless-2.6/arch/powerpc/boot/wrapper === --- wireless-2.6.orig/arch/powerpc/boot/wrapper 2007-12-23 20:10:07.0 +0100 +++ wireless-2.6/arch/powerpc/boot/wrapper 2007-12-23 20:22:41.0 +0100 @@ -195,6 +195,14 @@ if [ -n $version ]; then fi case $platform in +cuboot* | uboot) +if ! [ -x mkimage ]; then +echo mkimage not available. Can not create $platform image. +exit 0 +fi +esac + +case $platform in uboot) rm -f $ofile mkimage -A ppc -O linux -T kernel -C gzip -a -e \ ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] Do not fail build if mkimage is not available
On Sunday 23 December 2007 21:05:16 Josh Boyer wrote: On Sun, 23 Dec 2007 20:31:08 +0100 Michael Buesch [EMAIL PROTECTED] wrote: This fixes the boot image wrapper script to not fail the kernel build if mkimage is not available. As some distributions don't ship the mkimage program and I am not interested in uboot images anyway, I don't want to fail the whole kernel build process because of this unneeded dependency. Simply drop an error message, but don't fail the build. This is probably OK for now, but I'm working on getting mkimage merged into the kernel so it will just get ripped back out later if I'm successful. Yeah, cool. I am fine with this. :) I just don't want to install a tool into my operating system that I do not need. Shipping it with the kernel is the best option. -- Greetings Michael. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
radeon boot hot-crash
Hi,
I'm wondering how we are finally going to fix my radeon
hot-crash issue.
Fact is, applying the patch below fixes the issue.
Though, I see that this is not the correct patch to fix it.
Other devices might need the register write which is removed here.
So what about the following:
We add a specialcase for the exact type (and revision and so on)
for my chip here.
How do find out what's my chiprevision?
What exactly should be checked for here, so that only this chip
is affected by the workaround?
Index: wireless-2.6/drivers/video/aty/radeon_i2c.c
===
--- wireless-2.6.orig/drivers/video/aty/radeon_i2c.c2007-10-17
18:03:10.0 +0200
+++ wireless-2.6/drivers/video/aty/radeon_i2c.c 2007-10-17 18:18:52.0
+0200
@@ -137,13 +137,7 @@ void radeon_delete_i2c_busses(struct rad
int radeon_probe_i2c_connector(struct radeonfb_info *rinfo, int conn,
u8 **out_edid)
{
- u32 reg = rinfo-i2c[conn-1].ddc_reg;
- u8 *edid;
-
- OUTREG(reg, INREG(reg)
- ~(VGA_DDC_DATA_OUTPUT | VGA_DDC_CLK_OUTPUT));
-
- edid = fb_ddc_read(rinfo-i2c[conn-1].adapter);
+ u8 *edid = fb_ddc_read(rinfo-i2c[conn-1].adapter);
if (out_edid)
*out_edid = edid;
--
Greetings Michael.
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
arch/powerpc/boot/wrapper broken
It calls the mkimage command, which does not exist in my $PATH. -- Greetings Michael. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: arch/powerpc/boot/wrapper broken
On Saturday 27 October 2007 14:55:49 Vitaly Bordug wrote: On Sat, 27 Oct 2007 14:42:49 +0200 Michael Buesch wrote: It calls the mkimage command, which does not exist in my $PATH. well, mkImage is a part of u-boot and there was some talk to make it part of kernel too, since it does not take alot of place but still mandatory for a number of platforms to work. I think, Paul will clarify the details, meanwhile you can install mkImage say building u-boot, and some distros may have such a package. Ubuntu doesn't seem to, though. In any case, I think that the name mkimage is bad for a tool installed globally in /usr. Does it make a iso9660 image? (No it doesn't, I know :) ) I'd vote for shipping it with the kernel in /scripts or something like that. -- Greetings Michael. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Powerbook shuts down hard when hot, patch found
On Sunday 30 September 2007 12:13:36 Michael Buesch wrote: On Sunday 30 September 2007 00:49:05 Benjamin Herrenschmidt wrote: Well, it's possible that they have a too weak pull-up resistor on those lines, and thus when asserted to 0, a significant current goes through causing the whole thing to heat up. That heat added to the residual heat of a hot boot becomes then enough to trigger the temperature sensor threshold... just one possible explanation. Possible, yes. That's why I thought about some silicon bug. Why only when it's hot? :) Also, the other change I made you do turns these into inputs, thus the The _EN bits are already all cleared, as you can see in my printk dump. So clearing them has no effect, of course. So the ports are Inputs as default on boot. Hrm, that's weird then, because in that case, changing the output bits shouldn't have any effect, unless maybe on some chips, the EN bits are flipped. I don't have anything specific about the rv350 tho. Can you print which specific DDC register is doing that (it's called twice right ?) and maybe do a patch preventing that write only for one of them and let me know if it makes a difference. Here's the log of a working kernel. As you can see, I only removed the write for register 0x60 here. So it only crashes when I clear the bits in this register. (makes sense, as there's nothing to clear in the other one). [0.453703] PCI: Enabling device :00:10.0 (0006 - 0007) [0.649319] radeonfb (:00:10.0): Invalid ROM signature 303 should be 0xaa55 [0.649329] radeonfb: Retrieved PLL infos from Open Firmware [0.649340] radeonfb: Reference=27.00 MHz (RefDiv=12) Memory=203.00 Mhz, System=392.00 MHz [0.649350] radeonfb: PLL min 12000 max 35000 [0.650146] DDC REG 0x0060 IS 0x0303 [0.793754] i2c-adapter i2c-2: unable to read EDID block. [1.013748] i2c-adapter i2c-2: unable to read EDID block. [1.233748] i2c-adapter i2c-2: unable to read EDID block. [1.310002] DDC REG 0x006C IS 0x [1.310007] WRITING [1.650506] ieee1394: Host added: ID:BUS[0-00:1023] GUID[001124fffed98036] [1.700986] radeonfb: Monitor 1 type LCD found [1.700995] radeonfb: EDID probed [1.701001] radeonfb: Monitor 2 type no found [1.701015] radeonfb: Using Firmware dividers 0x0002008e from PPLL 0 [1.701130] radeonfb: Dynamic Clock Power Management enabled [1.742608] Console: switching to colour frame buffer device 160x53 [1.765577] radeonfb: Backlight initialized (radeonbl0) [1.765767] radeonfb (:00:10.0): ATI Radeon NP [1.776757] Generic RTC Driver v1.07 [1.777085] Macintosh non-volatile memory driver v1.1 [1.777429] Linux agpgart interface v0.102 [1.39] agpgart: Detected Apple UniNorth 2 chipset Ah, forgot to say. It does not crash immediately when the register is written. It takes about two seconds to crash. And when the machine is colder to begin with, it takes slightly longer to trigger. That _might_ support your overheating theory. Though, it does not trigger when it's up and running, no matter how hot you drive it. -- Greetings Michael. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Powerbook shuts down hard when hot, patch found
On Saturday 29 September 2007 13:06:59 Michael Buesch wrote: This is very strange... Can you try also clearing VGA_DDC_CLK_OUT_EN and VGA_DDC_DATA_OUT_EN and the same time and see if that helps ? It still triggers the bug then. I tried something else. I removed the write and only added a printk with a register read to print the contents (DDC REG IS 0x...) . This is the result: [0.431304] PCI: Enabling device :00:10.0 (0006 - 0007) [0.626866] radeonfb (:00:10.0): Invalid ROM signature 303 should be 0xaa55 [0.626877] radeonfb: Retrieved PLL infos from Open Firmware [0.626887] radeonfb: Reference=27.00 MHz (RefDiv=12) Memory=203.00 Mhz, System=392.00 MHz [0.626897] radeonfb: PLL min 12000 max 35000 [0.627194] DDC REG IS 0x0303 [0.763751] i2c-adapter i2c-2: unable to read EDID block. [0.983746] i2c-adapter i2c-2: unable to read EDID block. [1.203745] i2c-adapter i2c-2: unable to read EDID block. [1.280001] DDC REG IS 0x [1.620189] ieee1394: Host added: ID:BUS[0-00:1023] GUID[001124fffed98036] [1.670984] radeonfb: Monitor 1 type LCD found [1.670992] radeonfb: EDID probed [1.670997] radeonfb: Monitor 2 type no found [1.671012] radeonfb: Using Firmware dividers 0x0002008e from PPLL 0 [1.671075] radeonfb: Dynamic Clock Power Management enabled [1.712658] Console: switching to colour frame buffer device 160x53 [1.73] radeonfb: Backlight initialized (radeonbl0) [1.735746] radeonfb (:00:10.0): ATI Radeon NP [1.738776] Generic RTC Driver v1.07 [1.738995] Macintosh non-volatile memory driver v1.1 ... Note that the function is called twice. Is that correct? -- Greetings Michael. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Powerbook shuts down hard when hot, patch found
On Sunday 30 September 2007 00:19:53 Benjamin Herrenschmidt wrote: This all smells to me like a silicon bug, so I'd start searching in the silicon erratas. But I'm not sure, of course. It's also strange that it depends on temperature. (That's why I first expected the PMU would cause this). Thanks for your help. Could be that we are creating a short by driving the output low, thus causing the silicon to heat up, but that's strange. Well. The machine needs to be hot in the first place to trigger it. If it's cold it boots and runs fine even with that patch. Even if I run it hot after boot it does not shutdown. It only shuts down on boot when this register is written and when it's hot at this point. That's why I thought about some silicon bug. Why only when it's hot? :) Also, the other change I made you do turns these into inputs, thus the The _EN bits are already all cleared, as you can see in my printk dump. So clearing them has no effect, of course. So the ports are Inputs as default on boot. DDL lines should be pulled up, unless ... the board doesn't have pullups. Well, I can't tell you :) -- Greetings Michael. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Powerbook shuts down hard when hot, patch found
Hi,
some time ago I already mailed you about this problem.
I will quickly describe what's going on, again:
My powerbook boots fine when it's cold. You can work with
it and you can also run it hot (compile something, etc...).
But when you try to boot it while it is hot, it will
automatically shutdown hard inside of the boot process.
Some part of the hardware is shutting it down.
This does not happen when it's getting hot _after_ boot.
Only while boot when it's hot.
I bisected the problem and found out that the following patch
is responsible for this. Yeah, this sounds a little bit
crazy, as this patch does not seem to be related to
this at all. But I confirmed it by booting kernel
4f71c5de19c27f2198105d3b26b398494d5c353b
That kernel triggered the bug. Then I patch -R the patch below
and it booted properly, even when hot. I also rechecked
that it really was hot enough to trigger the event by
immediately rebooting into a known bad kernel, that immediately
shut down the pbook, as expected.
So I'm pretty sure it's the patch below causing this weird
behaviour. Any idea why?
commit 4f71c5de19c27f2198105d3b26b398494d5c353b
Author: Benjamin Herrenschmidt [EMAIL PROTECTED]
Date: Fri Nov 17 15:35:00 2006 +1100
[PATCH] Fix radeon DDC regression
When radeonfb was changed to use the new generic ddc, a bit of
code initializing the GPIO lines was lost, causing it to not work
if the firmware didn't configure them properly, which seems to
happen on some cards.
Signed-off-by: Benjamin Herrenschmidt [EMAIL PROTECTED]
Signed-off-by: Linus Torvalds [EMAIL PROTECTED]
diff --git a/drivers/video/aty/radeon_i2c.c b/drivers/video/aty/radeon_i2c.c
index 6767545..869725a 100644
--- a/drivers/video/aty/radeon_i2c.c
+++ b/drivers/video/aty/radeon_i2c.c
@@ -139,7 +139,13 @@ void radeon_delete_i2c_busses(struct rad
int radeon_probe_i2c_connector(struct radeonfb_info *rinfo, int conn,
u8 **out_edid)
{
- u8 *edid = fb_ddc_read(rinfo-i2c[conn-1].adapter);
+ u32 reg = rinfo-i2c[conn-1].ddc_reg;
+ u8 *edid;
+
+ OUTREG(reg, INREG(reg)
+ ~(VGA_DDC_DATA_OUTPUT | VGA_DDC_CLK_OUTPUT));
+
+ edid = fb_ddc_read(rinfo-i2c[conn-1].adapter);
if (out_edid)
*out_edid = edid;
--
Greetings Michael.
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH] via-pmu: Fix typo in printk
This fixes a typo in a printk message.
Signed-off-by: Michael Buesch [EMAIL PROTECTED]
Index: linux-2.6/drivers/macintosh/via-pmu.c
===
--- linux-2.6.orig/drivers/macintosh/via-pmu.c 2007-05-26 19:56:27.0
+0200
+++ linux-2.6/drivers/macintosh/via-pmu.c 2007-08-12 22:36:27.0
+0200
@@ -410,7 +410,7 @@ static int __init via_pmu_start(void)
irq = irq_of_parse_and_map(vias, 0);
if (irq == NO_IRQ) {
- printk(KERN_ERR via-pmu: can't map interruptn);
+ printk(KERN_ERR via-pmu: can't map interrupt\n);
return -ENODEV;
}
if (request_irq(irq, via_pmu_interrupt, 0, VIA-PMU, (void *)0)) {
--
Greetings Michael.
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [patch] powerpc: sysfs fix compiler warning
On Friday 29 June 2007 16:50:10 Christian Krafft wrote:
From: Christian Krafft [EMAIL PROTECTED]
This patch fixes the following compiler warning:
arch/powerpc/kernel/sysfs.c:385: warning: ignoring return value of
`sysfs_create_group',
Signed-off-by: Christian Krafft [EMAIL PROTECTED]
--- linux-2.6.orig/arch/powerpc/kernel/sysfs.c
+++ linux-2.6/arch/powerpc/kernel/sysfs.c
@@ -380,16 +380,25 @@ int cpu_add_sysdev_attr_group(struct att
{
int cpu;
struct sys_device *sysdev;
+ int error = 0;
mutex_lock(cpu_mutex);
for_each_possible_cpu(cpu) {
sysdev = get_cpu_sysdev(cpu);
- sysfs_create_group(sysdev-kobj, attrs);
+ error = sysfs_create_group(sysdev-kobj, attrs);
+
+ if (error) {
+ for_each_possible_cpu(cpu) {
+ sysdev = get_cpu_sysdev(cpu);
+ sysfs_remove_group(sysdev-kobj, attrs);
Is sysfs_remove_group() safe to call on kobjs for which
we did not call sysfs_create_group()?
+ }
+ break;
+ }
}
mutex_unlock(cpu_mutex);
- return 0;
+ return error;
}
EXPORT_SYMBOL_GPL(cpu_add_sysdev_attr_group);
--
Greetings Michael.
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
