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?
>
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
Li
On Saturday 31 October 2009 21:14:07 Joakim Tjernlund wrote:
> Michael Buesch 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 Ru
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
> > > i
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
On Friday 30 October 2009 15:50:22 Jonathan Haws wrote:
> > I suspect that the msync() was merely serving as a very heavyweight
> > memory barrier.
>
> I did try hacking the mb() calls from the kernel source to use them in user
> space, but they had no effect. I still had to include the calls to
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
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-d
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
> &
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 B
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 n
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 d
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).
>
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.
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
>
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
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&quo
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,
i
s 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 breaka
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 !
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 i
s 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 breaka
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 dis
y.
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:1
t; to just merge it up through the powerpc merge path since the changes
> are trivial.
>
> (Michael, Doug, if you disagree let me know and I can submit separate
> patches. This is 2.6.25 material anyway).
Acked-by: Michael Buesch <[EMAIL PROTECTED]>
--
Greetings Michael.
_
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 spe
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 so
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
On Monday 01 October 2007 10:00:02 Michel Dänzer wrote:
>
> On Sun, 2007-09-30 at 12:16 +0200, Michael Buesch wrote:
> >
> > Ah, forgot to say.
> > It does not crash immediately when the register is written. It takes about
> > two seconds
> > to crash. And
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 thr
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
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
> > wou
On Saturday 29 September 2007 23:51:55 Benjamin Herrenschmidt wrote:
>
> On Sat, 2007-09-29 at 13:22 +0200, Michael Buesch wrote:
> > On Saturday 29 September 2007 13:06:59 Michael Buesch wrote:
> > > > This is very strange... Can you try also clearin
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
On Saturday 29 September 2007 01:04:13 Benjamin Herrenschmidt wrote:
>
> On Fri, 2007-09-28 at 23:32 +0200, Michael Buesch wrote:
> > Hi,
> >
> > some time ago I already mailed you about this problem.
> > I will quickly describe what's going on, again:
> &g
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 shutd
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
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 PROTEC
38 matches
Mail list logo
