2011/6/11 Christian Kujau :
> 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...
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 Sun, 2011-06-05 at 19:11 -0700, Christian Kujau wrote:
> 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 flu
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 Wed, 2011-06-01 at 21:27 -0700, Christian Kujau wrote:
> 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.
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 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
The weird thing is that:
1) You didn't see (like Andres):
Machine check in kernel mode.
Caused by (fr
2011/6/2 Christian Kujau :
> 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.
OK, with your patch applied to Linus' latest git tree the machin
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 Wed, 2011-06-01 at 17:16 -0700, Christian Kujau wrote:
> 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 gi
On Wed, 2011-06-01 at 17:16 -0700, Christian Kujau wrote:
> ccc7c28af205888798b51b6cbc0b557ac1170a49 is the first bad commit
> commit ccc7c28af205888798b51b6cbc0b557ac1170a49
> Author: Rafał Miłecki
> Date: Fri Apr 1 13:26:52 2011 +0200
>
> ssb: pci: implement serdes workaround
>
>
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:
---
ccc7c28af205888798b51b6cb
On Tue, 2011-05-31 at 20:02 -0700, Christian Kujau wrote:
> (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.
(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 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 outp
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
On Tue, 2011-05-31 at 16:50 -0700, Christian Kujau wrote:
> 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 w
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
19 matches
Mail list logo
