Badness in 2.6.15-rc1 on 8xx

Badness in 2.6.15-rc1 on 8xx

[Joakim Tjernlund]

Anyone seen this when booting 2.6.15-rc1 on 8xx?
  Mount-cache hash table entries: 512
  Badness in dma_alloc_init at arch/ppc/kernel/dma-mapping.c:346
  Call trace:
   [c00039e8] check_bug_trap+0x80/0xa8
   [c0003c1c] program_check_exception+0x20c/0x480
   [c00031e0] ret_from_except_full+0x0/0x4c
   [c01b86b8] dma_alloc_init+0x40/0xcc
   [c000225c] init+0x8c/0x288
   [c00050ac] kernel_thread+0x44/0x60
  NET: Registered protocol family 16
The kernel boots just fine into user space so it seems harmless, but I
suspect it will bite me later.

Something anoying:
Why did the new cpm_uart driver change major and minor number for the
tty?
As it is now I can't boot my 2.4 rootfs as init think it should find the
console on ttyS0.
Would be great if major and minor could be configurable.

  Jocke

RE: Badness in 2.6.15-rc1 on 8xx

[Demke Torsten-atd012]

=20

> -----Original Message-----
> From: linuxppc-embedded-bounces@ozlabs.org=20
> [mailto:linuxppc-embedded-bounces@ozlabs.org] On Behalf Of=20
> Joakim Tjernlund
> Sent: Freitag, 25. November 2005 14:28
> To: linuxppc-embedded@ozlabs.org
> Subject: Badness in 2.6.15-rc1 on 8xx
>=20
> Anyone seen this when booting 2.6.15-rc1 on 8xx?
>   Mount-cache hash table entries: 512
>   Badness in dma_alloc_init at arch/ppc/kernel/dma-mapping.c:346
>   Call trace:
>    [c00039e8] check_bug_trap+0x80/0xa8
>    [c0003c1c] program_check_exception+0x20c/0x480
>    [c00031e0] ret_from_except_full+0x0/0x4c
>    [c01b86b8] dma_alloc_init+0x40/0xcc
>    [c000225c] init+0x8c/0x288
>    [c00050ac] kernel_thread+0x44/0x60
>   NET: Registered protocol family 16
> The kernel boots just fine into user space so it seems=20
> harmless, but I suspect it will bite me later.
>=20
> Something anoying:
> Why did the new cpm_uart driver change major and minor number=20
> for the tty?
> As it is now I can't boot my 2.4 rootfs as init think it=20
> should find the console on ttyS0.
> Would be great if major and minor could be configurable.
Because it's a new driver...with a new name (ttyCPM0) and a new
device number. It shared the device number and name in 2.4=20
with the "standard" device driver (8250/16550), and that made
it very difficult to use both in 2.4.=20
Maybe you should use console=3DttyCPM0 in your boot parameters for 2.6.

Regards,
Torsten
>=20
>   Jocke
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
>=20

RE: Badness in 2.6.15-rc1 on 8xx

[Joakim Tjernlund]

 > 
> > -----Original Message----- 
> > From: linuxppc-embedded-bounces@ozlabs.org 
> > [mailto:linuxppc-embedded-bounces@ozlabs.org] On Behalf Of 
> > Joakim Tjernlund 
> > Sent: Freitag, 25. November 2005 14:28 
> > To: linuxppc-embedded@ozlabs.org 
> > Subject: Badness in 2.6.15-rc1 on 8xx 
> > 
> > Anyone seen this when booting 2.6.15-rc1 on 8xx? 
> >   Mount-cache hash table entries: 512 
> >   Badness in dma_alloc_init at arch/ppc/kernel/dma-mapping.c:346 
> >   Call trace: 
> >    [c00039e8] check_bug_trap+0x80/0xa8 
> >    [c0003c1c] program_check_exception+0x20c/0x480 
> >    [c00031e0] ret_from_except_full+0x0/0x4c 
> >    [c01b86b8] dma_alloc_init+0x40/0xcc 
> >    [c000225c] init+0x8c/0x288 
> >    [c00050ac] kernel_thread+0x44/0x60 
> >   NET: Registered protocol family 16 
> > The kernel boots just fine into user space so it seems 
> > harmless, but I suspect it will bite me later. 
> > 
> > Something anoying: 
> > Why did the new cpm_uart driver change major and minor number 
> > for the tty? 
> > As it is now I can't boot my 2.4 rootfs as init think it 
> > should find the console on ttyS0. 
> > Would be great if major and minor could be configurable. 
> Because it's a new driver...with a new name (ttyCPM0) and a new 
> device number. It shared the device number and name in 2.4 
> with the "standard" device driver (8250/16550), and that made 
> it very difficult to use both in 2.4. 

To me it makes more sense to let a major number represent a function, not a driver.
Shouldn't be that hard to make these drivers cooperate wrt. minor number.

To allow for easy customization one could instead do:
#ifndef SERIAL_CPM_MAJOR
#define SERIAL_CPM_MAJOR        204
#endif
#ifndef SERIAL_CPM_MINOR
#define SERIAL_CPM_MINOR        46
#endif

Each platform could then define major and minor as they like.

 Jocke
  
> Maybe you should use console=ttyCPM0 in your boot parameters for 2.6. 
> 
> Regards, 
> Torsten 
> > 
> >   Jocke 

RE: Badness in 2.6.15-rc1 on 8xx

[Chris Down]

From: linuxppc-embedded-bounces@ozlabs.org
[mailto:linuxppc-embedded-bounces@ozlabs.org] On Behalf Of Joakim Tjernlund
Sent: 25 November 2005 13:28
To: linuxppc-embedded@ozlabs.org
Subject: Badness in 2.6.15-rc1 on 8xx

Anyone seen this when booting 2.6.15-rc1 on 8xx?
  Mount-cache hash table entries: 512
  Badness in dma_alloc_init at arch/ppc/kernel/dma-mapping.c:346
  Call trace:
   [c00039e8] check_bug_trap+0x80/0xa8
   [c0003c1c] program_check_exception+0x20c/0x480
   [c00031e0] ret_from_except_full+0x0/0x4c
   [c01b86b8] dma_alloc_init+0x40/0xcc
   [c000225c] init+0x8c/0x288
   [c00050ac] kernel_thread+0x44/0x60
  NET: Registered protocol family 16
The kernel boots just fine into user space so it seems harmless, but I
suspect it will bite me later.


I am currently working with 2.6.15-rc1 on MPC852 and I am seeing a similar
problem.

Badness in dma_alloc_init at arch/ppc/kernel/dma-mapping.c:346
Call trace:
 [c00036f8] check_bug_trap+0xa4/0xb8
 [c0003f9c] program_check_exception+0x2f0/0x4c4
 [c0003320] ret_from_except_full+0x0/0x4c
 [c024c530] dma_alloc_init+0x3c/0xbc
 [c0002280] init+0xbc/0x25c
 [c000538c] kernel_thread+0x44/0x60

Have not had time to look at it yet, however I was not getting this on
2.6.11.

Chris

RE: Badness in 2.6.15-rc1 on 8xx

[Ingo Hornberger]

Hi Joakim,

I was recently faced with the same problem. It's right that it boots
fine into user land. But the bad 'consistent' start address would cause
trouble as soon as you try to initiate some dma transfer. 

It is configurable under [Advanced setup].
I now use a value, seen on another 8xx board (it was some siemens board)
which was 0xf0000000. It works just fine.
As far as I understood the exact address isn't important, only that it
is unused in the kernel.


regards,
	Ingo

On Fri, 2005-11-25 at 22:41 +0100, Joakim Tjernlund wrote:
>  > 
> > > -----Original Message----- 
> > > From: linuxppc-embedded-bounces@ozlabs.org 
> > > [mailto:linuxppc-embedded-bounces@ozlabs.org] On Behalf Of 
> > > Joakim Tjernlund 
> > > Sent: Freitag, 25. November 2005 14:28 
> > > To: linuxppc-embedded@ozlabs.org 
> > > Subject: Badness in 2.6.15-rc1 on 8xx 
> > > 
> > > Anyone seen this when booting 2.6.15-rc1 on 8xx? 
> > >   Mount-cache hash table entries: 512 
> > >   Badness in dma_alloc_init at arch/ppc/kernel/dma-mapping.c:346 
> > >   Call trace: 
> > >    [c00039e8] check_bug_trap+0x80/0xa8 
> > >    [c0003c1c] program_check_exception+0x20c/0x480 
> > >    [c00031e0] ret_from_except_full+0x0/0x4c 
> > >    [c01b86b8] dma_alloc_init+0x40/0xcc 
> > >    [c000225c] init+0x8c/0x288 
> > >    [c00050ac] kernel_thread+0x44/0x60 
> > >   NET: Registered protocol family 16 
> > > The kernel boots just fine into user space so it seems 
> > > harmless, but I suspect it will bite me later. 
> > > 
> > > Something anoying: 
> > > Why did the new cpm_uart driver change major and minor number 
> > > for the tty? 
> > > As it is now I can't boot my 2.4 rootfs as init think it 
> > > should find the console on ttyS0. 
> > > Would be great if major and minor could be configurable. 
> > Because it's a new driver...with a new name (ttyCPM0) and a new 
> > device number. It shared the device number and name in 2.4 
> > with the "standard" device driver (8250/16550), and that made 
> > it very difficult to use both in 2.4. 
> 
> To me it makes more sense to let a major number represent a function, not a driver.
> Shouldn't be that hard to make these drivers cooperate wrt. minor number.
> 
> To allow for easy customization one could instead do:
> #ifndef SERIAL_CPM_MAJOR
> #define SERIAL_CPM_MAJOR        204
> #endif
> #ifndef SERIAL_CPM_MINOR
> #define SERIAL_CPM_MINOR        46
> #endif
> 
> Each platform could then define major and minor as they like.
> 
>  Jocke
>   
> > Maybe you should use console=ttyCPM0 in your boot parameters for 2.6. 
> > 
> > Regards, 
> > Torsten 
> > > 
> > >   Jocke 
> 
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
> 

RE: Badness in 2.6.15-rc1 on 8xx

[Joakim Tjernlund]

=20

> -----Original Message-----
> From: Chris Down [mailto:chris@alcor.co.uk]=20
> Sent: 28 November 2005 11:01
> To: Joakim Tjernlund; linuxppc-embedded@ozlabs.org
> Subject: RE: Badness in 2.6.15-rc1 on 8xx
>=20
> From: linuxppc-embedded-bounces@ozlabs.org
> [mailto:linuxppc-embedded-bounces@ozlabs.org] On Behalf Of=20
> Joakim Tjernlund
> Sent: 25 November 2005 13:28
> To: linuxppc-embedded@ozlabs.org
> Subject: Badness in 2.6.15-rc1 on 8xx
>=20
> Anyone seen this when booting 2.6.15-rc1 on 8xx?
>   Mount-cache hash table entries: 512
>   Badness in dma_alloc_init at arch/ppc/kernel/dma-mapping.c:346
>   Call trace:
>    [c00039e8] check_bug_trap+0x80/0xa8
>    [c0003c1c] program_check_exception+0x20c/0x480
>    [c00031e0] ret_from_except_full+0x0/0x4c
>    [c01b86b8] dma_alloc_init+0x40/0xcc
>    [c000225c] init+0x8c/0x288
>    [c00050ac] kernel_thread+0x44/0x60
>   NET: Registered protocol family 16
> The kernel boots just fine into user space so it seems harmless, but I
> suspect it will bite me later.
>=20
>=20
> I am currently working with 2.6.15-rc1 on MPC852 and I am=20
> seeing a similar
> problem.
>=20
> Badness in dma_alloc_init at arch/ppc/kernel/dma-mapping.c:346
> Call trace:
>  [c00036f8] check_bug_trap+0xa4/0xb8
>  [c0003f9c] program_check_exception+0x2f0/0x4c4
>  [c0003320] ret_from_except_full+0x0/0x4c
>  [c024c530] dma_alloc_init+0x3c/0xbc
>  [c0002280] init+0xbc/0x25c
>  [c000538c] kernel_thread+0x44/0x60
>=20
> Have not had time to look at it yet, however I was not getting this on
> 2.6.11.
>=20
> Chris

Let me guess you have IMAP_ADDR set to 0xff000000? Then you need to
change
CONSISTENT_START to something else(like 0xffa00000). Its somwhere in the
Advanced setup.

 Jocke

RE: Badness in 2.6.15-rc1 on 8xx

[Ingo Hornberger]

Hi Joakim,

I was recently faced with the same problem. It's right that it boots
fine into user land. But the bad 'consistent' start address would cause
trouble as soon as you try to initiate some dma transfer. 

It is configurable under [Advanced setup].
I now use a value, seen on another 8xx board (it was some siemens board)
which was 0xf0000000. It works just fine.
As far as I understood the exact address isn't important, only that it
is unused in the kernel.


regards,
	Ingo

On Fri, 2005-11-25 at 22:41 +0100, Joakim Tjernlund wrote:
>  > 
> > > -----Original Message----- 
> > > From: linuxppc-embedded-bounces@ozlabs.org 
> > > [mailto:linuxppc-embedded-bounces@ozlabs.org] On Behalf Of 
> > > Joakim Tjernlund 
> > > Sent: Freitag, 25. November 2005 14:28 
> > > To: linuxppc-embedded@ozlabs.org 
> > > Subject: Badness in 2.6.15-rc1 on 8xx 
> > > 
> > > Anyone seen this when booting 2.6.15-rc1 on 8xx? 
> > >   Mount-cache hash table entries: 512 
> > >   Badness in dma_alloc_init at arch/ppc/kernel/dma-mapping.c:346 
> > >   Call trace: 
> > >    [c00039e8] check_bug_trap+0x80/0xa8 
> > >    [c0003c1c] program_check_exception+0x20c/0x480 
> > >    [c00031e0] ret_from_except_full+0x0/0x4c 
> > >    [c01b86b8] dma_alloc_init+0x40/0xcc 
> > >    [c000225c] init+0x8c/0x288 
> > >    [c00050ac] kernel_thread+0x44/0x60 
> > >   NET: Registered protocol family 16 
> > > The kernel boots just fine into user space so it seems 
> > > harmless, but I suspect it will bite me later. 
> > > 
> > > Something anoying: 
> > > Why did the new cpm_uart driver change major and minor number 
> > > for the tty? 
> > > As it is now I can't boot my 2.4 rootfs as init think it 
> > > should find the console on ttyS0. 
> > > Would be great if major and minor could be configurable. 
> > Because it's a new driver...with a new name (ttyCPM0) and a new 
> > device number. It shared the device number and name in 2.4 
> > with the "standard" device driver (8250/16550), and that made 
> > it very difficult to use both in 2.4. 
> 
> To me it makes more sense to let a major number represent a function, not a driver.
> Shouldn't be that hard to make these drivers cooperate wrt. minor number.
> 
> To allow for easy customization one could instead do:
> #ifndef SERIAL_CPM_MAJOR
> #define SERIAL_CPM_MAJOR        204
> #endif
> #ifndef SERIAL_CPM_MINOR
> #define SERIAL_CPM_MINOR        46
> #endif
> 
> Each platform could then define major and minor as they like.
> 
>  Jocke
>   
> > Maybe you should use console=ttyCPM0 in your boot parameters for 2.6. 
> > 
> > Regards, 
> > Torsten 
> > > 
> > >   Jocke 
> 
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
> 

RE: Badness in 2.6.15-rc1 on 8xx

[Chris Down]

-----Original Message-----
From: Joakim Tjernlund [mailto:joakim.tjernlund@transmode.se] 
Sent: 28 November 2005 10:53
To: Chris Down; linuxppc-embedded@ozlabs.org
Subject: RE: Badness in 2.6.15-rc1 on 8xx
 

> Anyone seen this when booting 2.6.15-rc1 on 8xx?
>   Mount-cache hash table entries: 512
>   Badness in dma_alloc_init at arch/ppc/kernel/dma-mapping.c:346
>   Call trace:
>    [c00039e8] check_bug_trap+0x80/0xa8
>    [c0003c1c] program_check_exception+0x20c/0x480
>    [c00031e0] ret_from_except_full+0x0/0x4c
>    [c01b86b8] dma_alloc_init+0x40/0xcc
>    [c000225c] init+0x8c/0x288
>    [c00050ac] kernel_thread+0x44/0x60
>   NET: Registered protocol family 16
> The kernel boots just fine into user space so it seems harmless, but I
> suspect it will bite me later.
> 
> 
> I am currently working with 2.6.15-rc1 on MPC852 and I am 
> seeing a similar
> problem.
> 
> Badness in dma_alloc_init at arch/ppc/kernel/dma-mapping.c:346
> Call trace:
>  [c00036f8] check_bug_trap+0xa4/0xb8
>  [c0003f9c] program_check_exception+0x2f0/0x4c4
>  [c0003320] ret_from_except_full+0x0/0x4c
>  [c024c530] dma_alloc_init+0x3c/0xbc
>  [c0002280] init+0xbc/0x25c
>  [c000538c] kernel_thread+0x44/0x60
> 
> Have not had time to look at it yet, however I was not getting this on
> 2.6.11.
> 
> Chris

Let me guess you have IMAP_ADDR set to 0xff000000? Then you need to
change
CONSISTENT_START to something else(like 0xffa00000). Its somwhere in the
Advanced setup.

 Jocke
 
You are correct I do have IMAP_ADDR set to 0xff000000 and setting
CONSISTENT_START to 0xffa00000 solves the problem. 

Chris