ack_canary within current task_struct from there.
>
> fixes: 6533b7c16ee57 ("powerpc: Initial stack protector
> (-fstack-protector) support")
> Reported-by: Christian Kujau
>
> Signed-off-by: Christophe Leroy
> ---
> Christian, can you test it ?
>
> arch/powe
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
Thanks for the fix!
Christian.
$ gcc --version | head -1
gcc-4.9.real (Debian 4.9.2-10) 4.9.2
$ g
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 -fn
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: s
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
com
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
/usr/local/src/linux-git/kern
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 arch/powerpc/ke
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
Thank you!
Christian.
>
> cheers
>
&
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 w
ed for 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
@M
On Wed, 10 Aug 2016, Michael Ellerman wrote:
> Benjamin Herrenschmidt writes:
> > 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-
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 devic
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 st
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
[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
On August 8, 2015 1:57:05 AM PDT, Denis Kirjanov wrote:
>On 8/7/15, Christian Kujau wrote:
>> Hi,
>>
>> this PowerBook G4 was running 3.16 for a while but now I wanted to
>upgrade
>> to latest mainline. However, durin
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
[
r.c:86:2: note: in expansion of
macro 'do_div'
do_div(tmp, node_size);
^
LD [M] fs/hfsplus/hfsplus.o
==
Signed-off-by: Christian Kujau
Fixed-by: Geert Uytterhoeven
Acked-by: Sergei Antonov
---
diff --git a/fs/hfsplus/xattr.c b/fs/hfsplus/xa
ation!
> As inode sizes are positive, it should be safe to change the type of "tmp"
> to "u64". Does that make the warning go away?
Yes, this helped! Compile-tested only:
Signed-off-by: Christian Kujau
Fixed-by: Geert Uytterhoeven
Commit a99b7069aab8fc3fb4f26d15
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
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] fs/hf
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 answ
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://nerdbynatur
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
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
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] show_stack+0x4
p. Let me try again:
Signed-off-by: Christian Kujau
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
clean" defconfig for this Powerbook G5.
Signed-off-by: Christian Kujau
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
only available when IDE_GD_ATA is actually selected
and thus eliminates the warning.
Signed-off-by: Christian Kujau
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 @@
t_adjust=-3
$ dmesg
[...]
adt746x: Lowering max temperatures from 73, 80, 109 to 67, 47, 67
Thanks!
Tested-by: Christian Kujau
Christian.
> From: Jean Delvare
> Subject: kernel/params: Fix handling of signed integer types
>
> Commit 6072ddc8520b86adfac6939ca32fb6e6c4de017a brok
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 t
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
__
he fix! Ran into this as well, with your patch 3.9-rc1
compiles again (and it even boots :-))
Tested-by: Christian Kujau
$ grep -A10 sha1 /proc/crypto
name : sha1
driver : sha1-powerpc
module : kernel
priority : 0
refcnt : 1
selftest : passed
type : sha
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 a
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
>
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/
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 t
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 o
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/bit
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] ==
[ 97.803
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 o
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,
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,
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] [c9a61c10]
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] show_stack+0x70
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
I sure hope that other people will benefit from this as well.
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
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 %SRR
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 yo
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/
The
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 d
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 initializ
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 ?
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: logged
Jean Delvare 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 but it
>>
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
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
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 st
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://n
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 reproduc
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
devic
> 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
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: e
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 12:51, Benjamin Herrenschmidt wrote:
> BTW. SLUB or SLAB ? Mine was SLUB with SLUB_DEBUG enabled (tho the debug
> didn't seem to catch anything).
SLUB, and SLUB_DEBUG=y (but w/o SLUB_DEBUG_ON and SLUB_STATS). Full config
here: http://nerdbynature.de/bits/3.2.0-rc1/oops/conf
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 oop
On Tue, 15 Nov 2011 at 00:44, Christian Kujau wrote:
> 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
&
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:
h
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
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 a
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 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.
t git tree the machine
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
However, shortly after boot and loggin in to the box remotely, the bux d
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 t
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-
(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-r
ld not find it documented anywhere in the sources.
This patch adds it to Documentation/kernel-parameters.txt.
Signed-off-by: Christian Kujau
diff --git a/Documentation/kernel-parameters.txt
b/Documentation/kernel-parameters.txt
index cc85a92..5d0df23 100644
--- a/Documentation/kernel-parameter
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
> >
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" be
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
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
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
On Wed, 12 May 2010 at 00:22, Christian Kujau wrote:
> # kexec -e
> Starting new kernel
> Bye!
>
> but then the system just hung there, no more messages, I had to
> powercycle it.
Are there any debug flags (or kernel options?) I can set, to find out why
it hangs here?
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 sys
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 k
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
kexec/arch/ppc/
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 l
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
> Date : 2010-03-13 23:53 (58 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’
make[
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
> Date : 2010-03-13 23:53 (38 days old)
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
[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 --append="
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,
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: c01fb970
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] http://lists.ozlabs.org/pipermail/linuxppc-
1 - 100 of 113 matches
Mail list logo
