anary within current task_struct from there.
>
> fixes: 6533b7c16ee57 ("powerpc: Initial stack protector
> (-fstack-protector) support")
> Reported-by: Christian Kujau <li...@nerdbynature.de>
>
> Signed-off-by: Christophe Leroy <christophe.le...@c-s.fr>
> ---
> C
ing the same with GCC 5.2.0 works, even for
CC_STACKPROTECTOR_STRONG=y and the system boots just fine.
So, with that limitation, feel free to add:
Tested-by: Christian Kujau <li...@nerdbynature.de>
Thanks for the fix!
Christian.
$ gcc --version | head -1
gcc-4.9.real (Debian 4.9.2-
On Mon, 9 Jan 2017, Benjamin Herrenschmidt wrote:
> On Mon, 2017-01-09 at 18:11 -0800, Christian Kujau wrote:
> > So, with -fno-stack-protector my GCC 4.9.2 compiles with
> > CC_STACKPROTECTOR_STRONG=y but panics during boot:
>
> How can it make any sense to have
On Wed, 4 Jan 2017, Christian Kujau wrote:
> So, would the following be sufficient? It compiles, but I haven't had a
> chance to boot yet.
>
So, with -fno-stack-protector my GCC 4.9.2 compiles with
CC_STACKPROTECTOR_STRONG=y but panics during boot:
Kernel panic - not syncing: stack-
On Wed, 4 Jan 2017, Christophe LEROY wrote:
> Using GCC 5.4.0, I don't have that issue. bootx_init.o only contains reference
> to __stack_chk_fail
FWIW, building with a GCC 5.2 crosscompiler succeeds (with
CONFIG_CC_STACKPROTECTOR_STRONG=y), but I don't know if it will boot
though, see my other
On Wed, 4 Jan 2017, Christophe LEROY wrote:
> Looking a bit over internet, some people have reported having encountered that
> issue due to old object files not properly cleaned.
> Have you tried a 'make clean' or 'distclean' ?
I'm compiling with O=$DIR and I've deleted the entire $DIR before
Hi,
booting v4.10-rc2 on this PowerPC G4 machine prints the following early
on, but then continues to boot and the machine is running fine so far:
BUG: key ef0ba7d0 not in .data!
DEBUG_LOCKS_WARN_ON(1)
[ cut here ]
WARNING: CPU: 0 PID: 1 at
On Wed, 4 Jan 2017, Benjamin Herrenschmidt wrote:
> On Tue, 2017-01-03 at 07:25 -0800, Christian Kujau wrote:
> > Hi,
> >
> > when compiling v4.10-rc2 with CONFIG_CC_STACKPROTECTOR_STRONG=y, the
> > linker fails with:
>
> The way gcc implements the
On Tue, 3 Jan 2017, Christian Kujau wrote:
> when compiling v4.10-rc2 with CONFIG_CC_STACKPROTECTOR_STRONG=y, the
> linker fails with:
FWIW, compiling with CONFIG_CC_STACKPROTECTOR_REGULAR=y instead works
just fine.
C.
>
>
> + ld -EB -m el
Hi,
when compiling v4.10-rc2 with CONFIG_CC_STACKPROTECTOR_STRONG=y, the
linker fails with:
+ ld -EB -m elf32ppc -Bstatic --build-id -X -o .tmp_vmlinux1 -T
./arch/powerpc/kernel/vmlinux.lds arch/powerpc/kernel/head_32.o
arch/powerpc/kernel/fpu.o
On Wed, 23 Nov 2016, Michael Ellerman wrote:
> That's nothing powerpc specific AFAICS, does this fix it?
Hm, so s/printk/pr_cont/ - but not in all places? But yeah, this fixes it
for me, at least on x86.
Tested-by: Christian Kujau <li...@nerdbynature.de>
Thank you!
Christian.
&g
The "Locking API testsuite" output during bootup (with
CONFIG_DEBUG_LOCKING_API_SELFTESTS=y) on this PowerPC system looks
mangled, possibly related to the recent printk changes (4bcc595ccd80,
"printk: reinstate KERN_CONT for printing continuation lines"). Before
(e.g. with v4.6) it looked like
On Wed, 10 Aug 2016, Gabriel Paubert wrote:
> Just a question, does sleep work on your PowerBook?
Oh, this PowerBook is on 24/7, it's a small home server and I don't think
I ever used any sleep or hibernation modes on this machine. Sorry :\
C.
--
BOFH excuse #145:
Flat tire on station wagon
r any global accesss.
>
> Instead, split them into a separtate steup_feature_keys() function
> which is called in a more suitable spot on ppc32.
Wow, cool. With that applied (on top of mainline from some minutes ago),
this PowerPC G4 boots again. Thanks!
Tested-by: Christian Kujau &
On Wed, 10 Aug 2016, Michael Ellerman wrote:
> Benjamin Herrenschmidt <b...@kernel.crashing.org> writes:
> > On Tue, 2016-08-09 at 02:06 -0700, Christian Kujau wrote:
> >> On Mon, 8 Aug 2016, Christian Kujau wrote:
> >> >
> >> > while trying to u
On Tue, 9 Aug 2016, Benjamin Herrenschmidt wrote:
> On Tue, 2016-08-09 at 02:06 -0700, Christian Kujau wrote:
> > On Mon, 8 Aug 2016, Christian Kujau wrote:
> > >
> > > while trying to upgrade this PowerBook G4 from 4.7-rc7 to 4.8-rc1,
> > > it's
> >
On Mon, 8 Aug 2016, Christian Kujau wrote:
> while trying to upgrade this PowerBook G4 from 4.7-rc7 to 4.8-rc1, it's
> unable to boot the Yaboot (v1.3.16 from Debian/stable) boot loader:
>
>
> copying OF device tre
Hi,
while trying to upgrade this PowerBook G4 from 4.7-rc7 to 4.8-rc1, it's
unable to boot the Yaboot (v1.3.16 from Debian/stable) boot loader:
copying OF device tree...
Building dt strings...
Building dt stucture...
Device tree
On Sat, 8 Aug 2015, Christian Kujau wrote:
[Adding linux-...@vger.kernel.org]
On Fri, 7 Aug 2015, Christian Kujau wrote:
this PowerBook G4 was running 3.16 for a while but now I wanted to upgrade
to latest mainline. However, during bootup the following happens
On August 8, 2015 1:57:05 AM PDT, Denis Kirjanov k...@linux-powerpc.org wrote:
On 8/7/15, Christian Kujau li...@nerdbynature.de wrote:
Hi,
this PowerBook G4 was running 3.16 for a while but now I wanted to
upgrade
to latest mainline. However, during bootup the following happens
[Adding linux-...@vger.kernel.org]
On Fri, 7 Aug 2015, Christian Kujau wrote:
this PowerBook G4 was running 3.16 for a while but now I wanted to upgrade
to latest mainline. However, during bootup the following happens:
===
[2.237102] ata1: PATA max UDMA/100
Hi,
this PowerBook G4 was running 3.16 for a while but now I wanted to upgrade
to latest mainline. However, during bootup the following happens:
===
[2.237102] ata1: PATA max UDMA/100 irq 39
[2.401708] ata1.00: ATA-8: SAMSUNG HM061GC, LR100-10, max UDMA/100
[
of tmp
to u64. Does that make the warning go away?
Yes, this helped! Compile-tested only:
Signed-off-by: Christian Kujau li...@nerdbynature.de
Fixed-by: Geert Uytterhoeven ge...@linux-m68k.org
Commit a99b7069aab8fc3fb4f26d15795dc280b52e38b1 introduced do_div() to
xattr.c and the warning
==
Signed-off-by: Christian Kujau li...@nerdbynature.de
Fixed-by: Geert Uytterhoeven ge...@linux-m68k.org
Acked-by: Sergei Antonov sap...@gmail.com
---
diff --git a/fs/hfsplus/xattr.c b/fs/hfsplus/xattr.c
index 4e27edc..cd9ed4c 100644
--- a/fs/hfsplus/xattr.c
Hi,
while compiling 3.15-rc6 for powerpc (gcc-4.8.1 crosscompiler on x86_64),
a warning popped up:
WARNING: modpost: Found 1 section mismatch(es).
Compiling with CONFIG_DEBUG_SECTION_MISMATCH=y gives:
---
LD drivers/macintosh/built-in.o
CC [M]
Hi,
while compiling 3.15-rc6 for powerpc (gcc-4.8.1 crosscompiling on x86_64),
this happens:
---
CC [M] fs/hfsplus/xattr_user.o
CC [M] fs/hfsplus/xattr_security.o
CC [M] fs/hfsplus/xattr.o
CC [M] fs/hfsplus/xattr_trusted.o
I noticed that my machine locks up quite often with 3.13.-rc3.
PowerPC G4 again, but this machine was pretty much rock solid until now:
when there's lots of disk I/O going on, the system locks up, but not
entirely: the calltrace is still written to netconsole (but not to its
local disk) and
On Sat, 30 Nov 2013 at 23:05, Andreas Schwab wrote:
[...]
Freeing unused kernel memory: 204K (c06ea000 - c071d000)
eth0: hw csum failure
CPU: 0 PID: 0 Comm: swapper Not tainted 3.13.0-rc2 #1
Call Trace:
Btw, full dmesg .config: http://nerdbynature.de/bits/3.13-rc1/
Hi,
while trying to upgrade from 3.12.0 to 3.13-rc1 or -rc2, the following
happens early during bootup:
[...]
Freeing unused kernel memory: 204K (c06ea000 - c071d000)
eth0: hw csum failure
CPU: 0 PID: 0 Comm: swapper Not tainted 3.13.0-rc2 #1
Call Trace:
[effefd00] [c0008b3c]
On Sat, 30 Nov 2013 at 02:07, Christian Kujau wrote:
while trying to upgrade from 3.12.0 to 3.13-rc1 or -rc2, the following
happens early during bootup:
[...]
Freeing unused kernel memory: 204K (c06ea000 - c071d000)
eth0: hw csum failure
CPU: 0 PID: 0 Comm: swapper Not tainted 3.13.0
On Sat, 30 Nov 2013 at 02:11, Christian Kujau wrote:
On Sat, 30 Nov 2013 at 02:07, Christian Kujau wrote:
while trying to upgrade from 3.12.0 to 3.13-rc1 or -rc2, the following
happens early during bootup:
[...]
Freeing unused kernel memory: 204K (c06ea000 - c071d000)
eth0: hw
-off-by: Christian Kujau li...@nerdbynature.de
diff --git a/drivers/macintosh/Kconfig b/drivers/macintosh/Kconfig
index 696238b..d26a312 100644
--- a/drivers/macintosh/Kconfig
+++ b/drivers/macintosh/Kconfig
@@ -103,6 +103,7 @@ config ADB_PMU_LED_IDE
bool Use front LED as IDE LED by default
-off-by: Christian Kujau li...@nerdbynature.de
diff --git a/drivers/macintosh/Kconfig b/drivers/macintosh/Kconfig
index 696238b..f30ac9d 100644
--- a/drivers/macintosh/Kconfig
+++ b/drivers/macintosh/Kconfig
@@ -90,6 +90,7 @@ config ADB_PMU
config ADB_PMU_LED
bool Support for the Power/iBook
G5.
Signed-off-by: Christian Kujau li...@nerdbynature.de
diff --git a/arch/powerpc/configs/ppc6xx_defconfig
b/arch/powerpc/configs/ppc6xx_defconfig
index 20ebfaf..c2353bf 100644
--- a/arch/powerpc/configs/ppc6xx_defconfig
+++ b/arch/powerpc/configs/ppc6xx_defconfig
@@ -71,7 +71,7
Hi,
after upgrading from 3.11 to 3.12-rc2, the therm_adt746x module could not
be loaded any more:
therm_adt746x: `-2' invalid for parameter `limit_adjust'
I've alwasy passed limit_adjust=-3 (negative 3) to the module via
modprobe.conf, to lower the max temperature. Up until 3.11, loading
: Lowering max temperatures from 73, 80, 109 to 67, 47, 67
Thanks!
Tested-by: Christian Kujau li...@nerdbynature.de
Christian.
From: Jean Delvare kh...@linux-fr.org
Subject: kernel/params: Fix handling of signed integer types
Commit 6072ddc8520b86adfac6939ca32fb6e6c4de017a broke
On Wed, 6 Mar 2013 at 15:09, Michael Ellerman wrote:
Thanks Christian. What hardware are you on?
This is a PowerBook G4, 32bit, uni-processor. Full dmesg, e.g.:
http://nerdbynature.de/bits/3.9.0-rc1/dmesg.txt
C.
--
BOFH excuse #88:
Boss' kid fucked up the machine
patch 3.9-rc1
compiles again (and it even boots :-))
Tested-by: Christian Kujau li...@nerdbynature.de
$ grep -A10 sha1 /proc/crypto
name : sha1
driver : sha1-powerpc
module : kernel
priority : 0
refcnt : 1
selftest : passed
type : shash
blocksize: 64
On Sun, 27 Jan 2013 at 14:56, Christian Kujau wrote:
Hm, is there no chance to get this into 3.8? I've been running with this
patch applied since 3.7-rc7 and it got rid of this
MAX_STACK_TRACE_ENTRIES too low message. I've just upgraded to 3.8-rc5
and it's still not in mainline :-\
Hah! I
Hi,
similar to what I reported earlier [0] for 3.8.0-rc1, this happens during
ifup wlan0 (which in effect starts wpa_supplicant to bring up a Broadcom
b43 wifi network interface). The interface is working though and continues
to work over several ifup/ifdown iterations.
The backtrace looks
On Tue, 15 Jan 2013 at 14:59, Li Zhong wrote:
FYI, it is already in the next of ppc tree
http://git.kernel.org/?p=linux/kernel/git/benh/powerpc.git;a=shortlog;h=refs/heads/next
I guess it would get into 3.9, at least.
Hm, is there no chance to get this into 3.8? I've been running with this
On Sun, 23 Dec 2012 at 13:34, Christian Kujau wrote:
On Sat, 22 Dec 2012 at 16:28, Maciej Rutecki wrote:
Got during suspend to disk:
I got a similar message on a powerpc G4 system, right after bootup (no
suspend involved):
http://nerdbynature.de/bits/3.8.0-rc1/
This is still
On Wed, 28 Nov 2012 at 16:41, Li Zhong wrote:
On Tue, 2012-11-27 at 19:22 -0800, Christian Kujau wrote:
On Tue, 27 Nov 2012 at 19:06, Christian Kujau wrote:
the same thing[0] happened again in 3.7-rc7, after ~20h uptime:
I found the following on patchwork, but this seems to deal
On Sun, 23 Dec 2012 at 13:34, Christian Kujau wrote:
On Sat, 22 Dec 2012 at 16:28, Maciej Rutecki wrote:
Got during suspend to disk:
I got a similar message on a powerpc G4 system, right after bootup (no
suspend involved):
http://nerdbynature.de/bits/3.8.0-rc1/
FWIW, this is still
On Sat, 22 Dec 2012 at 16:28, Maciej Rutecki wrote:
Got during suspend to disk:
I got a similar message on a powerpc G4 system, right after bootup (no
suspend involved):
http://nerdbynature.de/bits/3.8.0-rc1/
[ 97.803049] ==
[
On Wed, 28 Nov 2012 at 16:41, Li Zhong wrote:
On Tue, 2012-11-27 at 19:22 -0800, Christian Kujau wrote:
On Tue, 27 Nov 2012 at 19:06, Christian Kujau wrote:
the same thing[0] happened again in 3.7-rc7, after ~20h uptime:
I found the following on patchwork, but this seems to deal
On Wed, 28 Nov 2012 at 16:41, Li Zhong wrote:
Would you please help to try the following fix? I don't have a powerpc32
machine for test...
I've just applied this to 3.7-rc7 and booted the machine. I don't know how
to trigger this bug, so it might take a while until it happens again - or
not,
Hi,
the same thing[0] happened again in 3.7-rc7, after ~20h uptime:
[40007.339487] [sched_delayed] sched: RT throttling activated
[69731.388717] BUG: MAX_STACK_TRACE_ENTRIES too low!
[69731.390371] turning off the locking correctness validator.
[69731.391942] Call Trace:
[69731.393525]
On Tue, 27 Nov 2012 at 19:06, Christian Kujau wrote:
the same thing[0] happened again in 3.7-rc7, after ~20h uptime:
I found the following on patchwork, but this seems to deal with powerpc64
only, while this PowerBook G4 of mine is powerpc32:
http://patchwork.ozlabs.org/patch/193414
Hi,
after upgrading from 3.6.0-08492-gd43 to 3.7.0-rc4 and running it for a
day or so, this happened:
[27148.965634] BUG: MAX_STACK_TRACE_ENTRIES too low!
[27148.967356] turning off the locking correctness validator.
[27148.968967] Call Trace:
[27148.970577] [ec633d00] [c0009064]
On Mon, 30 Jul 2012 at 22:46, Christian Kujau wrote:
when trying to upgrade from 3.5 (final) to today's git checkout from
Linus' tree, yaboot cannot boot and the following is printed:
[...]
returning from prom_init
Invalid memory access at %SRR0: 00c62fd4 %SRR1: 3030
Finally
On Tue, 4 Sep 2012 at 16:51, Michael Ellerman wrote:
My guess would be we're calling that quite early and the __put_user()
check is getting confused and failing. That means we'll have left some
code unpatched, which then fails.
Can you try with the patch applied, but instead of returning if
On Wed, 5 Sep 2012 at 11:08, Benjamin Herrenschmidt wrote:
Try this:
powerpc: Don't use __put_user() in patch_instruction
Perfect! With this patch applied, the machine boots again.
Tested-by: Christian Kujau li...@nerdbynature.de
I sure hope that other people will benefit from
On Wed, 1 Aug 2012 at 12:02, Tony Breeds wrote:
1) can you also upload you vmlinux so we can poke at it.
I've uploaded the vmlinx (and System.map) to the same location:
http://nerdbynature.de/bits/3.5.0/yaboot/
2) What is the dmseg.txt file there? If you're unable to boot 3.5 how
did you
Hi,
when trying to upgrade from 3.5 (final) to today's git checkout from
Linus' tree, yaboot cannot boot and the following is printed:
[...]
returning from prom_init
Invalid memory access at %SRR0: 00c62fd4 %SRR1: 3030
The whole message: http://nerdbynature.de/bits/3.5.0/yaboot/
On Mon, 2 Jul 2012 at 14:50, Benjamin Herrenschmidt wrote:
Interesting... I observed something roughly similar on a dual G4
the other day associated with a 30s to 1mn pause during boot. RCU
was complaining loudly.
In my case, it did continue booting normally, is that the case for you ?
No,
On Mon, 2 Jul 2012 at 14:50, Benjamin Herrenschmidt wrote:
while trying to upgrade from 3.4.0 to 3.5.0-rc5 on this Powerbook G4
(powerpc 32 bit), this happens during booting:
--
usb 2-1: new full-speed USB device number 4 using ohci_hcd
SCSI subsystem initialized
scsi0
On Mon, 2 Jul 2012 at 09:45, Paul E. McKenney wrote:
On Sun, Jul 01, 2012 at 11:30:40PM -0700, Christian Kujau wrote:
On Mon, 2 Jul 2012 at 14:50, Benjamin Herrenschmidt wrote:
Interesting... I observed something roughly similar on a dual G4
the other day associated with a 30s to 1mn
Hi,
while trying to upgrade from 3.4.0 to 3.5.0-rc5 on this Powerbook G4
(powerpc 32 bit), this happens during booting:
--
usb 2-1: new full-speed USB device number 4 using ohci_hcd
SCSI subsystem initialized
scsi0 : SBP-2 IEEE-1394
scsi1 : SBP-2 IEEE-1394
firewire_sbp2 fw1.0:
Jean Delvare kh...@linux-fr.org wrote:
On Thu, 19 Apr 2012 18:16:41 +1000, Benjamin Herrenschmidt wrote:
The goal of this series is to convert a bulk of PowerMac i2c drivers
to the new proper i2c driver registration model. This series is
not complete in that there are still a few drivers to do
On Tue, 10 Apr 2012 at 17:23, Benjamin Herrenschmidt wrote:
can you test the patch below ?
When applied to 3.4-rc2, Linux boots again, yay! :-)
Tested-by: Christian Kujau li...@nerdbynature.de
Thanks!
Christian.
From 08f1ec8a594c60bf3856e3c45b6d15fd691d90bb Mon Sep 17 00:00:00 2001
From
On Tue, 3 Apr 2012 at 18:08, Benjamin Herrenschmidt wrote:
On Tue, 2012-04-03 at 00:20 -0700, Christian Kujau wrote:
Going from 3.3-rc7 to 3.4-rc1 (with make oldconfig inbetween) did not
go well on this PowerBook G4 machine:
Apr 2 15:18:23 [ 8.318816] EXT4-fs (hda6): mounted
On Wed, 4 Apr 2012 at 18:06, Suzuki K. Poulose wrote:
INFO: Uncompressed kernel (size 0x6d4b80) overlaps the address of the
wrapper(0x40)
INFO: Fixing the link_address of wrapper to (0x70)
Building modules, stage 2.
MODPOST 24 modules
I started to see
Going from 3.3-rc7 to 3.4-rc1 (with make oldconfig inbetween) did not
go well on this PowerBook G4 machine:
Apr 2 15:18:23 [ 8.318816] EXT4-fs (hda6): mounted filesystem with ordered
data mode. Opts: (null)
Apr 2 15:18:23 [ 8.320286] VFS: Mounted root (ext4 filesystem) readonly on
device
On Tue, 3 Apr 2012 at 18:08, Benjamin Herrenschmidt wrote:
I have observed this randomly on the G5 ... sometimes, if I try again,
it works... it's very very odd. There is some kind of race maybe with
async startup ? Or a problem with the vfs path walking ? It's certainly
not easily
On Tue, 3 Apr 2012 at 10:18, Christian Kujau wrote:
PS: Unfortunately I cannot boot into the old (3.3-rc7) kernel
right now (which is still installed via yaboot and present in
/boot), because of this:
http://nerdbynature.de/bits/3.4.0-rc1/init/mac-invalid-memory.JPG
On Tue, 17 Jan 2012 at 20:13, Christian Kujau wrote:
compiling today's git (mainline, a25a2b8) on powerpc32 gives:
CC arch/powerpc/kernel/crash.o
cc1: warnings being treated as errors
/usr/local/src/linux-2.6-git/arch/powerpc/kernel/crash.c:49: error:
‘cpus_in_crash
Hi,
compiling today's git (mainline, a25a2b8) on powerpc32 gives:
CC arch/powerpc/kernel/crash.o
cc1: warnings being treated as errors
/usr/local/src/linux-2.6-git/arch/powerpc/kernel/crash.c:49: error:
‘cpus_in_crash’ defined but not used
make[2]: *** [arch/powerpc/kernel/crash.o] Error
On Mon, 21 Nov 2011 at 11:58, Benjamin Herrenschmidt wrote:
I've seen something similar with 3.2-rc2 at cfcfc9ec, unfortunately I
couldn't capture the oops log at the time.
It just happened again today, after heavy CPU IO load (rsyncing from/to
external disks on dm-crypt). This time the oops
Hi,
I noticed a few crashes on this PowerBook G4 lately, starting somewhere in
3.2.0-rc1. The crashes are really rare and as I'm not on the system all
the time I did not notice most of them. By the time I did, the screen was
blank already and I had to hard-reset the box. But not this time:
On Thu, 2 Jun 2011 at 12:57, Benjamin Herrenschmidt wrote:
John, care to send the patch below to Linus ASAP ? I could reproduce and
verify it fixes it. Thanks !
ssb: pci: Don't call PCIe specific workarounds on PCI cores
Otherwise it can/will crash
The patch did not make it into -rc2,
On Thu, 2 Jun 2011 at 17:33, Benjamin Herrenschmidt wrote:
It -looks- to me that something goes wrong in the tty code when a large
file is piped through a pty, causing the kernel to hang for minutes in
the workqueue / ldisk flush code. I've just sent an initial report to
Alan Cox about it and
On Thu, 2 Jun 2011 at 08:07, Rafał Miłecki wrote:
1) You didn't see (like Andres):
Machine check in kernel mode.
Caused by (from SRR1=149030): Transfer error ack signal
Oops: Machine check, sig: 7 [#1]
But, OK, maybe machine check requires something additional in kernel,
I don't know...
On Thu, 2 Jun 2011 at 08:13, Rafał Miłecki wrote:
John, I'm afraid more and more people get angry at me because of this ;)
Erm, I'm not angry at anyone :-) On the contrary, I'm happy about the fix
so quickly available!
Though I'm a bit afraid of the next git bisect session, as it might not be
On Tue, 31 May 2011 at 16:50, Christian Kujau wrote:
trying to boot 3.0-rc1 on powerpc32 only progresses until:
Kernel virtual memory layout:
* 0xfffcf000..0xf000 : fixmap
After hours (and hours!) of git-bisecting, it said
On Thu, 2 Jun 2011 at 12:57, Benjamin Herrenschmidt wrote:
Ok, thanks a lot, It looks rather trivial actually: That new workaround
is PCIe specific but is called unconditionally, and will do bad things
non-PCIe implementations.
Indeed. This PowerBook G4 does not has PCIe, yet the whole SSB
continues to boot. Also, with the latest tree, the machine is stuck after
ide-cd init problem[0] went away.
For this particular problem and patch, feel free to add:
Tested-by: Christian Kujau li...@nerdbynature.de
However, shortly after boot and loggin in to the box remotely, the bux did
Hi,
trying to boot 3.0-rc1 on powerpc32 only progresses until:
Kernel virtual memory layout:
* 0xfffcf000..0xf000 : fixmap
And then the system hangs, does not respond to keyboard (sysrq does not
seem to work on this PowerBook G4). But after a while the system reboots
itself, so I
On Wed, 1 Jun 2011 at 10:25, Benjamin Herrenschmidt wrote:
Hrm, I had it working on a pair of powerbooks yesterday. Can you try
something like udbg-immortal on your kernel command line to see if
that makes a difference in the output ?
I'll try in a minute.
In the meantime, git bisect behaves
On Tue, 31 May 2011 at 17:48, Christian Kujau wrote:
On Wed, 1 Jun 2011 at 10:25, Benjamin Herrenschmidt wrote:
Hrm, I had it working on a pair of powerbooks yesterday. Can you try
something like udbg-immortal on your kernel command line to see if
that makes a difference in the output
it documented anywhere in the sources.
This patch adds it to Documentation/kernel-parameters.txt.
Signed-off-by: Christian Kujau li...@nerdbynature.de
diff --git a/Documentation/kernel-parameters.txt
b/Documentation/kernel-parameters.txt
index cc85a92..5d0df23 100644
--- a/Documentation/kernel
(Cc'in Linus)
On Tue, 31 May 2011 at 17:48, Christian Kujau wrote:
In the meantime, git bisect behaves kinda weird, I don't know what went
wrong here:
$ git bisect start
$ git bisect good # Linux 2.6.39
$ git bisect bad v3.0-rc1 # Linux 3.0-rc1
$ git bisect bad
On Wed, 19 May 2010 at 22:32, Michael Ellerman wrote:
Some bogus firmwares include properties with / in their name. This
causes problems when creating the /proc/device-tree file system,
because the slash is taken to indicate a directory.
We don't care about those properties, and we don't
On Thu, 13 May 2010 at 15:50, Maxim Uvarov wrote:
zImage should not work with kexec. Only vmlinux.
should?
PPC64 has something nice there:
kexec/arch/ppc64/kexec-zImage-ppc64.c:
fprintf(stderr, zImage support is still broken\n);
but I could not figure out where this is called from.
On Wed, 12 May 2010 at 10:31, Maxim Uvarov wrote:
Yes, that is expected result for old tool chains. New tool chains (from code
sourcery ) need this crt.S.
I think we can have --with-oldtoolchain option to configure to point to old
tool chains. (or even rename it to --with-crts,
I don't know
On Tue, 11 May 2010 at 21:47, Maxim Uvarov wrote:
This patch is required in case if you are using new toolchains.
After kexec-tools compiled, I actually tried it:
# kexec -l /boot/2.6/zImage --command-line=root=/dev/hda6 ro
# echo $?
0
# kexec -e
Starting new kernel
Bye!
but then the
On Tue, 11 May 2010 at 21:47, Maxim Uvarov wrote:
This patch is required in case if you are using new toolchains.
Ah, thanks I was missing (and looking for) crashdump-powerpc.h
already :-)
Christian
--
make bzImage, not war
___
Linuxppc-dev mailing
Maxim Uvarov wrote on 2010-05-11 10:47 :
This patch is required in case if you are using new toolchains.
I'm on Debian/stable (binutils 2.18, gcc 4.3.2), so I applied your patches
to the latest -git checkout:
First, compilation fails with:
cc1: warnings being treated as errors
On Sun, 9 May 2010 at 23:17, Rafael J. Wysocki wrote:
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=15589
Subject : 2.6.34-rc1: Badness at fs/proc/generic.c:316
Submitter : Christian Kujau li...@nerdbynature.de
Date : 2010-03-13 23:53 (58 days old
On Tue, 20 Apr 2010 at 05:19, Rafael J. Wysocki wrote:
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=15589
Subject : 2.6.34-rc1: Badness at fs/proc/generic.c:316
Submitter : Christian Kujau li...@nerdbynature.de
Date : 2010-03-13 23:53 (38 days old
On Tue, 20 Apr 2010 at 22:18, Michael Ellerman wrote:
Try this 100% unbuilt, 100% untested patch.
I added GFP_KERNEL to kstrdup to make the compile error go away:
fs/proc/proc_devtree.c: In function ‘unslash_name’:
fs/proc/proc_devtree.c:183: error: too few arguments to function ‘kstrdup’
[please CC me as I am not subscribed]
Hi,
when building a kernel for powerpc32 (PowerBook6,8 / 7447A) I can select
CONFIG_KEXEC. However, after booting I can't convince kexec (from
kexec-tools, latest git checkout) to load the kernel:
# /opt/kexec-tools/sbin/kexec -l /boot/2.6/zImage
On Wed, 31 Mar 2010 at 17:23, Anton Vorontsov wrote:
Kernel has all needed for kexec, but kexec-tools are broken for
powerpc32.
http://www.mail-archive.com/linuxppc-dev@lists.ozlabs.org/msg22498.html
Oh :-\
I've just asked around, and it seems that Maxim (Cc'ed) will start
working on
On Sun, 14 Mar 2010 at 08:55, Alexey Dobriyan wrote:
device-tree: Duplicate name in /cpus/PowerPC,g...@0, renamed to l2-cache#1
name 'pulses/rev'
Uh-oh.
Uh-oh? :-)
Is this something to worry about? The machine seems to run fine so far...
Runtime behaviour remains the same, it's just
Hi,
after upgrading from 2.6.33 to today's latest mainline (daf9fe2...), I'm
getting this during bootup on a powerpc machine (Powerbook G4):
[0.002187] [ cut here ]
[0.002197] Badness at fs/proc/generic.c:316
[0.002207] NIP: c00e1130 LR: c00e1130 CTR:
Ben,
I cannot find those two patches from Jean [0] in your tree, I take it
they'll be included and pushed to Linus in 2.6.34 then?
(Although I had hoped to see them in 2.6.33, I'm testing[1] them since
-rc2 on my PowerBook)
Thanks,
Christian.
[0]
On Fri, 29 Jan 2010 at 22:03, Christian Kujau wrote:
On Fri, 29 Jan 2010 at 09:18, Jean Delvare wrote:
Christian, did you ever test this second patch of mine? If you did,
what was the outcome?
OK, I've now applied both the drivers/hwmon/ams/ patches and your earlier
one for drivers
On Fri, 29 Jan 2010 at 09:18, Jean Delvare wrote:
Christian, did you ever test this second patch of mine? If you did,
what was the outcome?
Sorry, I must've missed that 2nd patch of yours. I'll test this now and
report back.
Thanks,
Christian.
--
BOFH excuse #112:
The monitor is plugged
On Wed, 6 Jan 2010 at 17:37, Jean Delvare wrote:
Christian, did you happen to try removing the i2c-powermac driver
before?
Well, I definitely removed the driver before, but I'm not sure if I ever
read the /sys files after doing this :-\
I am curious if this is a recent problem, possibly
Hi Jean,
On Wed, 6 Jan 2010 at 17:37, Jean Delvare wrote:
I think that sysfs files creation should be moved to the end of
probe_thermostat() and sysfs files removal should be moved to the
beginning of remove_thermostat(). Something like the totally untested
patch below (no ppc machine at
1 - 100 of 106 matches
Mail list logo
