* RE: Badness in 2.6.15-rc1 on 8xx
@ 2005-11-28 10:52 Joakim Tjernlund
2005-11-28 11:33 ` Chris Down
0 siblings, 1 reply; 8+ messages in thread
From: Joakim Tjernlund @ 2005-11-28 10:52 UTC (permalink / raw)
To: Chris Down, linuxppc-embedded
=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
^ permalink raw reply [flat|nested] 8+ messages in thread
* RE: Badness in 2.6.15-rc1 on 8xx
2005-11-28 10:52 Badness in 2.6.15-rc1 on 8xx Joakim Tjernlund
@ 2005-11-28 11:33 ` Chris Down
0 siblings, 0 replies; 8+ messages in thread
From: Chris Down @ 2005-11-28 11:33 UTC (permalink / raw)
To: 'Joakim Tjernlund', linuxppc-embedded
-----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
^ permalink raw reply [flat|nested] 8+ messages in thread
* RE: Badness in 2.6.15-rc1 on 8xx
@ 2005-11-25 21:41 Joakim Tjernlund
2005-11-28 10:08 ` Ingo Hornberger
2005-11-28 10:57 ` Ingo Hornberger
0 siblings, 2 replies; 8+ messages in thread
From: Joakim Tjernlund @ 2005-11-25 21:41 UTC (permalink / raw)
To: 'Demke Torsten-atd012', linuxppc-embedded
>
> > -----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
^ permalink raw reply [flat|nested] 8+ messages in thread
* RE: Badness in 2.6.15-rc1 on 8xx
2005-11-25 21:41 Joakim Tjernlund
@ 2005-11-28 10:08 ` Ingo Hornberger
2005-11-28 10:57 ` Ingo Hornberger
1 sibling, 0 replies; 8+ messages in thread
From: Ingo Hornberger @ 2005-11-28 10:08 UTC (permalink / raw)
To: linuxppc-embedded
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
>
^ permalink raw reply [flat|nested] 8+ messages in thread
* RE: Badness in 2.6.15-rc1 on 8xx
2005-11-25 21:41 Joakim Tjernlund
2005-11-28 10:08 ` Ingo Hornberger
@ 2005-11-28 10:57 ` Ingo Hornberger
1 sibling, 0 replies; 8+ messages in thread
From: Ingo Hornberger @ 2005-11-28 10:57 UTC (permalink / raw)
To: linuxppc-embedded
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
>
^ permalink raw reply [flat|nested] 8+ messages in thread
* RE: Badness in 2.6.15-rc1 on 8xx
@ 2005-11-25 14:21 Demke Torsten-atd012
0 siblings, 0 replies; 8+ messages in thread
From: Demke Torsten-atd012 @ 2005-11-25 14:21 UTC (permalink / raw)
To: Joakim Tjernlund, linuxppc-embedded
=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
^ permalink raw reply [flat|nested] 8+ messages in thread
* Badness in 2.6.15-rc1 on 8xx
@ 2005-11-25 13:28 Joakim Tjernlund
2005-11-28 10:01 ` Chris Down
0 siblings, 1 reply; 8+ messages in thread
From: Joakim Tjernlund @ 2005-11-25 13:28 UTC (permalink / raw)
To: linuxppc-embedded
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
^ permalink raw reply [flat|nested] 8+ messages in thread
* RE: Badness in 2.6.15-rc1 on 8xx
2005-11-25 13:28 Joakim Tjernlund
@ 2005-11-28 10:01 ` Chris Down
0 siblings, 0 replies; 8+ messages in thread
From: Chris Down @ 2005-11-28 10:01 UTC (permalink / raw)
To: 'Joakim Tjernlund', linuxppc-embedded
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
^ permalink raw reply [flat|nested] 8+ messages in thread
end of thread, other threads:[~2005-11-28 11:33 UTC | newest]
Thread overview: 8+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2005-11-28 10:52 Badness in 2.6.15-rc1 on 8xx Joakim Tjernlund
2005-11-28 11:33 ` Chris Down
-- strict thread matches above, loose matches on Subject: below --
2005-11-25 21:41 Joakim Tjernlund
2005-11-28 10:08 ` Ingo Hornberger
2005-11-28 10:57 ` Ingo Hornberger
2005-11-25 14:21 Demke Torsten-atd012
2005-11-25 13:28 Joakim Tjernlund
2005-11-28 10:01 ` Chris Down
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).