* Re: kernel 2.6.15: cpm_uart driver broken?
From: Dan Malek @ 2006-04-19 19:42 UTC (permalink / raw)
To: Kenneth Poole; +Cc: David Jander, linuxppc-embedded
In-Reply-To: <4D8794260B62C940BBA7150CC5EB3BD432D4F4@bosmail.BOS.int.mrv.com>
On Apr 19, 2006, at 3:24 PM, Kenneth Poole wrote:
>
> /* get pointer */
> - cp = cpm2cpu_addr(bdp->cbd_bufaddr);
> + cp = (unsigned char *)pinfo->mem_addr +
> (bdp->cbd_bufaddr - pinfo->dma_addr);
Ummm, no. Keep the cpm2cpu_addr() and pass it
some driver data structure pointer so it does the computes,
or better, keep the phys/virt addresses in a handy data
structure you can easily access and work with offsets within
the different address spaces. The test of addr >= CPM_ADDR
is critically important to early boot and kgdb support
and can't be removed.
> - bdp->cbd_bufaddr = cpu2cpm_addr(mem_addr);
> + bdp->cbd_bufaddr = dma_addr;
This kind of initialization is broken, too. You have to test
that memory address and return the proper space.
Thanks.
-- Dan
^ permalink raw reply
* RE: kernel 2.6.15: cpm_uart driver broken?
From: Kenneth Poole @ 2006-04-19 19:24 UTC (permalink / raw)
To: Vitaly Bordug, David Jander; +Cc: linuxppc-embedded
>If there is any code to reference, I'd appreciate it (and merge to the
>driver).=20
Ok, here's a patch, below. It includes changes for DMA buffer allocation
as discussed. This is untested, because the CPM uart driver for our
platforms has many other modifications that don't apply.
It also includes a fix for sending x_char in cpm_uart_tx_pump(). This
allows the actual x_char to be sent, instead of the next regular
character.
-------------------------------------------------------------
--- cpm_uart_core.c.orig 2006-04-19 10:24:47.000000000 -0400
+++ cpm_uart_core.c 2006-04-19 10:51:43.000000000 -0400
@@ -71,20 +71,6 @@
=20
/**************************************************************/
=20
-static inline unsigned long cpu2cpm_addr(void *addr)
-{
- if ((unsigned long)addr >=3D CPM_ADDR)
- return (unsigned long)addr;
- return virt_to_bus(addr);
-}
-
-static inline void *cpm2cpu_addr(unsigned long addr)
-{
- if (addr >=3D CPM_ADDR)
- return (void *)addr;
- return bus_to_virt(addr);
-}
-
/*
* Check, if transmit buffers are processed
*/
@@ -261,7 +247,7 @@
}
=20
/* get pointer */
- cp =3D cpm2cpu_addr(bdp->cbd_bufaddr);
+ cp =3D (unsigned char *)pinfo->mem_addr +
(bdp->cbd_bufaddr - pinfo->dma_addr);
=20
/* loop through the buffer */
while (i-- > 0) {
@@ -606,11 +592,12 @@
/* Pick next descriptor and fill from buffer */
bdp =3D pinfo->tx_cur;
=20
- p =3D cpm2cpu_addr(bdp->cbd_bufaddr);
+ p =3D (unsigned char *)pinfo->mem_addr + (bdp->cbd_bufaddr
- pinfo->dma_addr);
=20
- *p++ =3D xmit->buf[xmit->tail];
+ *p =3D port->x_char;
bdp->cbd_datlen =3D 1;
bdp->cbd_sc |=3D BD_SC_READY;
+ __asm__("eieio");
/* Get next BD. */
if (bdp->cbd_sc & BD_SC_WRAP)
bdp =3D pinfo->tx_bd_base;
@@ -633,7 +620,7 @@
=20
while (!(bdp->cbd_sc & BD_SC_READY) && (xmit->tail !=3D
xmit->head)) {
count =3D 0;
- p =3D cpm2cpu_addr(bdp->cbd_bufaddr);
+ p =3D (unsigned char *)pinfo->mem_addr + (bdp->cbd_bufaddr
- pinfo->dma_addr);
while (count < pinfo->tx_fifosize) {
*p++ =3D xmit->buf[xmit->tail];
xmit->tail =3D (xmit->tail + 1) & (UART_XMIT_SIZE
- 1);
@@ -670,39 +657,37 @@
static void cpm_uart_initbd(struct uart_cpm_port *pinfo)
{
int i;
- u8 *mem_addr;
+ dma_addr_t dma_addr;
volatile cbd_t *bdp;
=20
pr_debug("CPM uart[%d]:initbd\n", pinfo->port.line);
=20
/* Set the physical address of the host memory
- * buffers in the buffer descriptors, and the
- * virtual address for us to work with.
+ * buffers in the buffer descriptors.
*/
- mem_addr =3D pinfo->mem_addr;
+ dma_addr =3D pinfo->dma_addr;
bdp =3D pinfo->rx_cur =3D pinfo->rx_bd_base;
for (i =3D 0; i < (pinfo->rx_nrfifos - 1); i++, bdp++) {
- bdp->cbd_bufaddr =3D cpu2cpm_addr(mem_addr);
+ bdp->cbd_bufaddr =3D dma_addr;
bdp->cbd_sc =3D BD_SC_EMPTY | BD_SC_INTRPT;
- mem_addr +=3D pinfo->rx_fifosize;
+ dma_addr +=3D pinfo->rx_fifosize;
}
-
- bdp->cbd_bufaddr =3D cpu2cpm_addr(mem_addr);
+=09
+ bdp->cbd_bufaddr =3D dma_addr;
bdp->cbd_sc =3D BD_SC_WRAP | BD_SC_EMPTY | BD_SC_INTRPT;
=20
/* Set the physical address of the host memory
- * buffers in the buffer descriptors, and the
- * virtual address for us to work with.
+ * buffers in the buffer descriptors.
*/
- mem_addr =3D pinfo->mem_addr + L1_CACHE_ALIGN(pinfo->rx_nrfifos *
pinfo->rx_fifosize);
+ dma_addr =3D pinfo->dma_addr + L1_CACHE_ALIGN(pinfo->rx_nrfifos *
pinfo->rx_fifosize);
bdp =3D pinfo->tx_cur =3D pinfo->tx_bd_base;
for (i =3D 0; i < (pinfo->tx_nrfifos - 1); i++, bdp++) {
- bdp->cbd_bufaddr =3D cpu2cpm_addr(mem_addr);
+ bdp->cbd_bufaddr =3D dma_addr;
bdp->cbd_sc =3D BD_SC_INTRPT;
- mem_addr +=3D pinfo->tx_fifosize;
+ dma_addr +=3D pinfo->tx_fifosize;
}
-
- bdp->cbd_bufaddr =3D cpu2cpm_addr(mem_addr);
+=09
+ bdp->cbd_bufaddr =3D dma_addr;
bdp->cbd_sc =3D BD_SC_WRAP | BD_SC_INTRPT;
}
=20
@@ -1032,7 +1017,7 @@
* If the buffer address is in the CPM DPRAM, don't
* convert it.
*/
- cp =3D cpm2cpu_addr(bdp->cbd_bufaddr);
+ cp =3D (unsigned char *)pinfo->mem_addr +
(bdp->cbd_bufaddr - pinfo->dma_addr);
=20
*cp =3D *s;
=20
@@ -1049,7 +1034,7 @@
while ((bdp->cbd_sc & BD_SC_READY) !=3D 0)
;
=20
- cp =3D cpm2cpu_addr(bdp->cbd_bufaddr);
+ cp =3D (unsigned char *)pinfo->mem_addr +
(bdp->cbd_bufaddr - pinfo->dma_addr);
=20
*cp =3D 13;
bdp->cbd_datlen =3D 1;
--- cpm_uart_cpm1.c.orig 2006-04-19 10:26:46.000000000 -0400
+++ cpm_uart_cpm1.c 2006-04-19 10:32:05.000000000 -0400
@@ -191,7 +191,7 @@
/* was hostalloc but changed cause it blows away the */
/* large tlb mapping when pinning the kernel area */
mem_addr =3D (u8 *) cpm_dpram_addr(cpm_dpalloc(memsz, 8));
- dma_addr =3D 0;
+ dma_addr =3D (dma_addr_t)mem_addr;
} else
mem_addr =3D dma_alloc_coherent(NULL, memsz, &dma_addr,
GFP_KERNEL);
----------------------------------------------------------
Ken Poole
kpoole@bos.mrv.com
=20
^ permalink raw reply
* RE: Watchdog on MPC82xx
From: Pelton, Dave @ 2006-04-19 15:23 UTC (permalink / raw)
To: linuxppc-embedded list; +Cc: Bastos Fernandez Alexandre
Alex,
I have recently been trying to get the internal watchdog timer working
with 2.6.15 on a MPC8247 custom board (@ 266MHz), and hence I have been
following this thread with great interest.
I tried the heartbeat method (setting ppc_md.heartbeat to kick the
watchdog) and I was unable to get it to work correctly. To help things
I tried sprinkling a few kicks of the watchdog through the early layers
of init code but this seemed to make no difference.
I also tried porting the mpc8xx watchdog driver to the mpc82xx
architecture (i.e. kicking the watchdog using the PIT interrupt). This
seemed to fail in the same way. I would see about 8 or 10 characters of
the initial start-up message (where it dumps the Linux version and the
build time) and then the watchdog would kick the card back to u-boot.
As a last resort I tried kicking the watchdog in the printk call (in
essentially the same way that you do below), and I found that this
worked correctly when used in conjunction with the ported version of the
mpc8xx watchdog driver. I suspect it would work equally well with the
heartbeat method.
I don't understand why kicking the watchdog from printk fixes things,
and it really seems like an ugly way to fix this problem. I did the
quick math to figure out how long it will take the watchdog to trigger,
and at my clock rate of 266MHz, the watchdog fires in about 0.5 seconds,
which means that anything that runs for longer than 0.25 seconds could
cause a watchdog trigger. My best guess is that within printk there is
something that exceeds this margin, but looking in the code I can not
see what that would be (unless draining the printk console output over
the ttyCPM0 serial port somehow takes a long time).
Perhaps some of the wise ones on the list could provide some suggestions
on why printk seems to be the sticking point for the watchdog.
- David Pelton.
-----Original Message-----
Sent: Wednesday, April 19, 2006 7:14 AM
To: linuxppc-embedded list
Subject: Re: Watchdog on MPC82xx
Well,
I have tested two different approaches which has been confirmed to be
already working on MPC82xx boards.
One, from Paul Bilke, is based on modifiying printk to service the WDT
and reload the counter during boot time.
So I have modified kernel/printk.c and tested with this:
asmlinkage int printk(const char *fmt, ...) {
va_list args;
int r;
force_wdt_reload();
[...]
}
<< snip >>
^ permalink raw reply
* RE: Watchdog on MPC82xx
From: Rune Torgersen @ 2006-04-19 14:29 UTC (permalink / raw)
To: Bastos Fernandez Alexandre, linuxppc-embedded list
On our 8265/8280 board, the max timeout of the watchdog timer was ~1.3
seconds, so it kept resetting before the heartbeat function got called
on boot.
I had to add a watchdog reset to time_init() because it woud pause there
for about 2 secondfs trying to see if there was a realtime clock.=20
> -----Original Message-----
> From: linuxppc-embedded-bounces+runet=3Dinnovsys.com@ozlabs.org=20
> [mailto:linuxppc-embedded-bounces+runet=3Dinnovsys.com@ozlabs.or
> g] On Behalf Of Bastos Fernandez Alexandre
> Sent: Wednesday, April 19, 2006 06:14
> To: linuxppc-embedded list
> Subject: Re: Watchdog on MPC82xx
>=20
> Well,
>=20
> I have tested two different approaches which has been confirmed
> to be already working on MPC82xx boards.
>=20
> One, from Paul Bilke, is based on modifiying printk to service
> the WDT and reload the counter during boot time.
> So I have modified kernel/printk.c and tested with this:
>=20
> asmlinkage int printk(const char *fmt, ...)
> {
> va_list args;
> int r;
>=20
> force_wdt_reload();
> [...]
> }
>=20
> #define SWSR_ADDR (CPM_MAP_ADDR + 0x1000E)
>=20
> void force_wdt_reload(void)
> {
> unsigned short *swsr_ptr =3D (unsigned short=20
> *)ioremap(SWSR_ADDR,0x2);
>=20
> (*swsr_ptr) =3D (unsigned short) 0x556c;
> (*swsr_ptr) =3D (unsigned short) 0xaa39;
> }
>=20
> Paul has reported changing printk works for him on several=20
> MPC82xx boards.
>=20
> Second one is from Mike Rapoport from Compulab. Is the heartbeat
> method. I have added and additional call in m82xx_board_setup()
> which should reset the WDT for the first time in setup_arch():
>=20
> static __inline__ void reset_8260_watchdog(void)
> {
> cpm2_immr->im_siu_conf.siu_82xx.sc_swsr =3D 0x556c;
> cpm2_immr->im_siu_conf.siu_82xx.sc_swsr =3D 0xaa39;
> }
>=20
> void __init
> m82xx_board_setup(void)
> {
> volatile cpm2_map_t *immap =3D cpm2_immr;
>=20
> reset_8260_watchdog();
>=20
> ppc_md.heartbeat =3D m82xx_heartbeat;
> ppc_md.heartbeat_reset =3D HZ/2;
> ppc_md.heartbeat_count =3D 1;
>=20
> }
>=20
> Mike has reported the heartbeat method is working for him
> on MPC8247 and MPC8271 boards with kernel 2.6.12.3.
>=20
>=20
> I have tested both in a MCP8248 based board, with kernel
> 2.6.15 and u-boot 1.1.4 and I have no success. I can see
> the __log_buf after the reset caused by de WDT and there
> are several printk's done. I have put printk's to the
> reset_8260_watchdog(), and I can see them also, so I
> should suppose it is executed, but the board keeps reseting.
> Furthermore, u-boot is doing OK the WDT job (with changes done
> from Compulab).
>=20
> I have dissasambled that, and for example:
>=20
> c01c93b8 <m82xx_board_setup>:
> c01c93b8: 3d 40 c0 1e lis r10,-16354
> c01c93bc: 38 00 55 6c li r0,21868
> c01c93c0: 81 2a 81 8c lwz r9,-32372(r10)
> c01c93c4: 3d 09 00 01 addis r8,r9,1
> c01c93c8: b0 08 00 0e sth r0,14(r8)
> c01c93cc: 81 68 0d 50 lwz r11,3408(r8)
> c01c93d0: 81 2a 81 8c lwz r9,-32372(r10)
> c01c93d4: 75 60 08 00 andis. r0,r11,2048
> c01c93d8: 38 00 aa 39 li r0,-21959
> c01c93dc: 3d 29 00 01 addis r9,r9,1
> c01c93e0: b0 09 00 0e sth r0,14(r9)
> c01c93e4: 41 82 00 44 beq- c01c9428 <m82xx_board_setup+0x70>
>=20
> [...]
>=20
> which looks OK for me (but I am not an expert).
>=20
> So, could someone give me some guideline about what could
> be happening?. Should I downgrade to 2.6.12.3 and test?
> Is the WDT being reloaded at least one time and then
> failing to reset? Some idea on how to debug that?
>=20
> Thanks
>=20
>=20
> Alex BASTOS
>=20
> P.S. The __log_buf
> 3c353e4c 696e7578 20766572 73696f6e <5>Linux version
> 20322e36 2e313520 28616c65 62617340 2.6.15 (alebas@
> 54523339 32292028 67636320 76657273 xxxx) (gcc vers
> 696f6e20 332e332e 32292023 33392050 ion 3.3.2) #39 P
> 5245454d 50542054 75652041 70722031 REEMPT Tue Apr 1
> 38203135 3a32353a 33392043 45535420 8 15:25:39 CEST
> 32303036 0a3c363e 54656c65 76657320 2006.<6>Televes
> 446f4338 32343820 436f6d70 75746572 XXX8248 Computer
> 2d6f6e2d 4d6f6475 6c652070 6f72740a -on-Module port.
> 3c373e4f 6e206e6f 64652030 20746f74 <7>On node 0 tot
> 616c7061 6765733a 20313633 38340a3c alpages: 16384.<
> 373e2020 444d4120 7a6f6e65 3a203136 7> DMA zone: 16
> 33383420 70616765 732c204c 49464f20 384 pages, LIFO
> 62617463 683a330a 3c373e20 20444d41 batch:3.<7> DMA
> 3332207a 6f6e653a 20302070 61676573 32 zone: 0 pages
> 2c204c49 464f2062 61746368 3a300a3c , LIFO batch:0.<
> 373e2020 4e6f726d 616c207a 6f6e653a 7> Normal zone:
> 20302070 61676573 2c204c49 464f2062 0 pages, LIFO b
> 61746368 3a300a3c 373e2020 48696768 atch:0.<7> High
> 4d656d20 7a6f6e65 3a203020 70616765 Mem zone: 0 page
> 732c204c 49464f20 62617463 683a300a s, LIFO batch:0.
> 3c343e42 75696c74 2031207a 6f6e656c <4>Built 1 zonel
> 69737473 0a3c353e 4b65726e 656c2063 ists.<5>Kernel c
> 6f6d6d61 6e64206c 696e653a 20726f6f ommand line: roo
> 743d2f64 65762f72 616d3020 72772063 t=3D/dev/ram0 rw c
> 6f6e736f 6c653d74 74794350 4d0a3c35 onsole=3DttyCPM.<5
> 3e596f75 20617265 20617420 4f6e650a >You are at One.
> 3c343e50 49442068 61736820 7461626c <4>PID hash tabl
> 6520656e 74726965 733a2035 31322028 e entries: 512 (
> 6f726465 723a2039 2c203831 00000000 order: 9, 81....
> 00000000 00000000 00000000 00000000 ................
>=20
>=20
>=20
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
>=20
>=20
^ permalink raw reply
* RE: kernel access of bad area, sig: 11 ( mpc852t)
From: Rune Torgersen @ 2006-04-19 14:33 UTC (permalink / raw)
To: Kenneth Poole, linuxppc-embedded
When I was tracking down a timing problem on our SDRAM I found that
doing a native compile of glibc over NFS seems to be a very good memory
test.
> -----Original Message-----
> From: linuxppc-embedded-bounces+runet=3Dinnovsys.com@ozlabs.org=20
> [mailto:linuxppc-embedded-bounces+runet=3Dinnovsys.com@ozlabs.or
> g] On Behalf Of Kenneth Poole
> Sent: Wednesday, April 19, 2006 07:59
> To: linuxppc-embedded@ozlabs.org
> Subject: kernel access of bad area, sig: 11 ( mpc852t)
>=20
>=20
> >>> Hi,
>=20
> >>> Im having problem porting linux kernel 2.4.21 to our=20
> mpc852T custom
>=20
> >>> board.The kernel
>=20
> >>> panics randomly with sig 11.
>=20
> >>> The board boots up fine and we also get to the=20
> prompt.When we open 3-4
>=20
> >>> telnet sessions
>=20
> >>> and try to run some command the kernel panics.This is completely
>=20
> >>> random.Sometimes it
>=20
> >>> even panics before opening the telnet session.
>=20
> >>>
>=20
>=20
> >>> <oops dump snipped>
>=20
> >>>
>=20
> >>You almost certainly have SDRAM problems. If you have=20
> thoroughly checked
>=20
> >>out the
>=20
> >>complete address range statically, remember that burst=20
> accesses will not
>=20
> >>occur until the
>=20
> >>cache is turned on, so your problem may be with bursting. =20
> But you can also
>=20
> >>have severe
>=20
> >>problems like a missing address line and linux still run=20
> for a few seconds.
>=20
> >>
>=20
> >>Mark Chambers
>=20
> >We've checked the SDRAM. The timings (UPM) look fine. The problem
>=20
> >however is that linux does not hang until after a few processes are
>=20
> >started.
>=20
> >If we boot to linux and leave it as it is, everything is fine and the
>=20
> >board remains working. However each time a few processes (4-5 telnet
>=20
> >sessions for eg.) are started the system either panics or hangs (goes
>=20
> >dead).
>=20
> >Thanks in advance,
>=20
> >Akshay
>=20
> We have been experiencing this same issue with random boards=20
> in production. The exact same version of software will run=20
> for months on other instances of the exact same board design,=20
> but a few percent get 'random' trap 300s. When they do occur,=20
> it's only after Linux has booted and address translation and=20
> caching are turned on. Examining the oops-es and memory shows=20
> that some location in SDRAM has a bogus value, but I don't=20
> have the tools to trace back how it got that way.
>=20
> I have ported a rigorous moving-inversions memory test into=20
> our firmware, and have run it extensively across the entire=20
> SDRAM address space (the test code executes from flash). I=20
> have let this test run continuously for hours and hours, but=20
> never found a memory problem. Unfortunately, I do not have=20
> test software that enables the MMU address translation or=20
> caching, so as Mark said, I can't test memory using bursting.=20
> Our hardware engineers have reviewed the designs very=20
> carefully and are quite confident that there is plenty of=20
> margin in the memory timing. Signal quality has also been=20
> carefully checked.
>=20
> Our manufacturing people have replaced the CPU on some of=20
> these boards, and the problem went away.
>=20
> If anyone else on the mailing list has experienced this=20
> issue, or has developed a virtual address memory test, please=20
> let us know.
>=20
> Ken Poole
>=20
> =20
>=20
> =20
>=20
>=20
^ permalink raw reply
* Re: kernel access of bad area, sig: 11 ( mpc852t)
From: Mark Chambers @ 2006-04-19 13:45 UTC (permalink / raw)
To: Kenneth Poole, linuxppc-embedded
In-Reply-To: <4D8794260B62C940BBA7150CC5EB3BD432D423@bosmail.BOS.int.mrv.com>
kernel access of bad area, sig: 11 ( mpc852t)>>> board.The kernel
>>> panics randomly with sig 11.
>We have been experiencing this same issue with random boards in production.
>The exact same version of software will run for months on other >instances
>of the exact same board design, but a few percent get 'random' trap 300s.
>When they do occur, it's only after Linux has booted and >address
>translation and caching are turned on. Examining the oops-es and memory
>shows that some location in SDRAM has a bogus value, >but I don't have the
>tools to trace back how it got that way.
>I have ported a rigorous moving-inversions memory test into our firmware,
>and have run it extensively across the entire SDRAM address >space (the
>test code executes from flash). I have let this test run continuously for
>hours and hours, but never found a memory problem. >Unfortunately, I do not
>have test software that enables the MMU address translation or caching, so
>as Mark said, I can't test memory using >bursting. Our hardware engineers
>have reviewed the designs very carefully and are quite confident that there
>is plenty of margin in the memory >timing. Signal quality has also been
>carefully checked.
Ouch! Yeah, these are the tough ones, the intermittent ones. You can, btw,
force a burst cycle using the RUN
command in the MCR, similar to what you do to generate a few refreshes when
configuring the DRAM. And
you can easily enable the cache for testing and then you'll get bursts (I
don't think MMU will have any effect).
A burst is not so much different from other cycles, so I don't think
bursting per se is what causes problems when
the kernel starts. I think it has more to do with the increased randomness
of accesses with multitasking and
cacheing and all that.
>Our manufacturing people have replaced the CPU on some of these boards, and
>the problem went away.
It also seems to me that the cache is the most delicate bit of logic in the
852. So if you have ground noise or
problems on the 1.8V rail it will likely show up in the cache - I had
hardware problems where I could
track it down to a mismatch between the cache line and memory (and the scope
showed the read burst to
be fine). Also look closely at the PLL circuit - it can work both ways, the
PLL can inject noise back into
the unfiltered supply (I use a ferrite instead of the inductor that
Freescale recommends).
That's my $.02 :-)
Mark C.
^ permalink raw reply
* kernel access of bad area, sig: 11 ( mpc852t)
From: Kenneth Poole @ 2006-04-19 12:58 UTC (permalink / raw)
To: linuxppc-embedded
[-- Attachment #1: Type: text/plain, Size: 2573 bytes --]
>>> Hi,
>>> Im having problem porting linux kernel 2.4.21 to our mpc852T custom
>>> board.The kernel
>>> panics randomly with sig 11.
>>> The board boots up fine and we also get to the prompt.When we open
3-4
>>> telnet sessions
>>> and try to run some command the kernel panics.This is completely
>>> random.Sometimes it
>>> even panics before opening the telnet session.
>>>
>>> <oops dump snipped>
>>>
>>You almost certainly have SDRAM problems. If you have thoroughly
checked
>>out the
>>complete address range statically, remember that burst accesses will
not
>>occur until the
>>cache is turned on, so your problem may be with bursting. But you can
also
>>have severe
>>problems like a missing address line and linux still run for a few
seconds.
>>
>>Mark Chambers
>We've checked the SDRAM. The timings (UPM) look fine. The problem
>however is that linux does not hang until after a few processes are
>started.
>If we boot to linux and leave it as it is, everything is fine and the
>board remains working. However each time a few processes (4-5 telnet
>sessions for eg.) are started the system either panics or hangs (goes
>dead).
>Thanks in advance,
>Akshay
We have been experiencing this same issue with random boards in
production. The exact same version of software will run for months on
other instances of the exact same board design, but a few percent get
'random' trap 300s. When they do occur, it's only after Linux has booted
and address translation and caching are turned on. Examining the oops-es
and memory shows that some location in SDRAM has a bogus value, but I
don't have the tools to trace back how it got that way.
I have ported a rigorous moving-inversions memory test into our
firmware, and have run it extensively across the entire SDRAM address
space (the test code executes from flash). I have let this test run
continuously for hours and hours, but never found a memory problem.
Unfortunately, I do not have test software that enables the MMU address
translation or caching, so as Mark said, I can't test memory using
bursting. Our hardware engineers have reviewed the designs very
carefully and are quite confident that there is plenty of margin in the
memory timing. Signal quality has also been carefully checked.
Our manufacturing people have replaced the CPU on some of these boards,
and the problem went away.
If anyone else on the mailing list has experienced this issue, or has
developed a virtual address memory test, please let us know.
Ken Poole
[-- Attachment #2: Type: text/html, Size: 7533 bytes --]
^ permalink raw reply
* Re: Watchdog on MPC82xx
From: Bastos Fernandez Alexandre @ 2006-04-19 14:59 UTC (permalink / raw)
To: Mark Chambers; +Cc: linuxppc-embedded list
In-Reply-To: <005401c663a9$e1fd8930$6401a8c0@CHUCK2>
Mark,
>
> I haven't been following this closely, but are you sure it's a WDT
> reset? You can tell from the Reset Status Register (RSR).
> u-boot prints out a decode of this register, which also clears the
> bits, so you have to go by the printout when u-boot starts to see
> why the last reset occurred.
U-boot is reporting the Watchdog reset. You can see:
U-Boot 1.1.4 (Apr 11 2006 - 14:39:01)
MPC8272 Reset Status: Software Watchdog, External Soft, External Hard
MPC8272 Clock Configuration
- Bus-to-Core Mult 4x, VCO Div 2, 60x Bus Freq 25-75 , Core Freq 100-300
- dfbrg 1, corecnf 0x1a, busdf 3, cpmdf 1, plldf 0, pllmf 3
- vco_out 400000000, scc_clk 100000000, brg_clk 25000000
- cpu_clk 400000000, cpm_clk 200000000, bus_clk 100000000
- pci_clk 66666666
CPU: MPC8272 (HiP7 Rev 14, Mask 1.0 1K50M) at 400 MHz
Board: Televes XXX8248
Watchdog enabled
>
> Just trying to help brainstorm...
>
> Mark Chambers
>
Thanks,
Alex Bastos
^ permalink raw reply
* Re: kernel 2.6.15: cpm_uart driver broken?
From: Vitaly Bordug @ 2006-04-19 10:21 UTC (permalink / raw)
To: David Jander; +Cc: Kenneth Poole, linuxppc-embedded
In-Reply-To: <200604191128.50138.david.jander@protonic.nl>
On Wed, 19 Apr 2006 11:28:49 +0200
David Jander <david.jander@protonic.nl> wrote:
>
> Hi Kenneth,
>
> On Tuesday 18 April 2006 21:19, Kenneth Poole wrote:
> > Regarding DMA allocation for CPM uarts, we had a similar issue with our
> > MPC857T and MPC885 boards. I think the real problem is that
> > bus_to_virt() and virt_to_bus() don't work on 8xx platforms for
> > addresses allocated using dma_alloc_coherent(). We had a previous
> > discussion Pantelis Antoniou and he agreed that the use of bus_to_virt()
> > and virt_to_bus() should be deprecated. This is also recommended in the
> > whitepaper series that discussed porting device drivers from 2.4 to 2.6.
>
> You are right! I hadn't noticed the (implicit) use of virt_to_bus() in
> cpm_uart_core.c. In the case that "((unsigned long)addr >= CPM_ADDR)", the
> address isn't translated, that's why the uart keeps sending lots of 0xff's
> instead of real data: There is empty flash at that adress (after 0xff100000)!
> This also explains why the system hangs when I set CONFIG_CONSISTENT_START to
> 0xfd100000, because then the CPM will access unadressed space.
>
> Vitaly: Is it true that your ADS boards both have
> IMMAP_ADDR < CONFIG_CONSISTENT_START ?
> That would explain why those do work.
> On the PQ2's dma_alloc_coherent(), behaves differently, so they might also
> work.
>
Right.
> In fact, bus_to_virt(), which is also used, does nothing more than adding
> KERNELBASE to the address, so a!=bus_to_virt(virt_to_bus(a)) if 'a' is
> obtained by anything other than kmalloc(). So if 'a' is obtained from
> dma_alloc_coherent(), will bus_to_virt(virt_to_bus(a)) at least yield a
> correctly mapped virtual address?
> I am asking, because line 263 of cpm_uart_core.c does exactly this, and it
> smells ;-)
>
Well I was aware about no-good there, but since it works fine with my HW, and no other complaints, there were no reason to overhaul.
> > What we did was use dma_alloc_coherent() in cpm_uart_cpm1.c, saving
> > dma_addr in the pinfo structure. The in cpm_uart_core.c, we use dma_addr
> > as the base address for the cbd_bufaddr values in each of the
> > descriptors. The software, when accessing the DMA buffers, uses mem_addr
> > as the base, applying the same offset computed previously for the dma
> > addresses. This technique is used in other drivers all over 2.6.
>
> Sounds like the correct thing to do, but do you (by any chance) have a patch
> for this change, to share?
>
If there is any code to reference, I'd appreciate it (and merge to the driver).
--
Sincerely,
Vitaly
^ permalink raw reply
* Re: kernel 2.6.15: cpm_uart driver broken?
From: David Jander @ 2006-04-19 9:28 UTC (permalink / raw)
To: linuxppc-embedded; +Cc: Kenneth Poole
In-Reply-To: <4D8794260B62C940BBA7150CC5EB3BD432D3A5@bosmail.BOS.int.mrv.com>
Hi Kenneth,
On Tuesday 18 April 2006 21:19, Kenneth Poole wrote:
> Regarding DMA allocation for CPM uarts, we had a similar issue with our
> MPC857T and MPC885 boards. I think the real problem is that
> bus_to_virt() and virt_to_bus() don't work on 8xx platforms for
> addresses allocated using dma_alloc_coherent(). We had a previous
> discussion Pantelis Antoniou and he agreed that the use of bus_to_virt()
> and virt_to_bus() should be deprecated. This is also recommended in the
> whitepaper series that discussed porting device drivers from 2.4 to 2.6.
You are right! I hadn't noticed the (implicit) use of virt_to_bus() in
cpm_uart_core.c. In the case that "((unsigned long)addr >= CPM_ADDR)", the
address isn't translated, that's why the uart keeps sending lots of 0xff's
instead of real data: There is empty flash at that adress (after 0xff100000)!
This also explains why the system hangs when I set CONFIG_CONSISTENT_START to
0xfd100000, because then the CPM will access unadressed space.
Vitaly: Is it true that your ADS boards both have
IMMAP_ADDR < CONFIG_CONSISTENT_START ?
That would explain why those do work.
On the PQ2's dma_alloc_coherent(), behaves differently, so they might also
work.
In fact, bus_to_virt(), which is also used, does nothing more than adding
KERNELBASE to the address, so a!=bus_to_virt(virt_to_bus(a)) if 'a' is
obtained by anything other than kmalloc(). So if 'a' is obtained from
dma_alloc_coherent(), will bus_to_virt(virt_to_bus(a)) at least yield a
correctly mapped virtual address?
I am asking, because line 263 of cpm_uart_core.c does exactly this, and it
smells ;-)
> What we did was use dma_alloc_coherent() in cpm_uart_cpm1.c, saving
> dma_addr in the pinfo structure. The in cpm_uart_core.c, we use dma_addr
> as the base address for the cbd_bufaddr values in each of the
> descriptors. The software, when accessing the DMA buffers, uses mem_addr
> as the base, applying the same offset computed previously for the dma
> addresses. This technique is used in other drivers all over 2.6.
Sounds like the correct thing to do, but do you (by any chance) have a patch
for this change, to share?
Thanks a lot to everyone for their comments and help.
Greetings,
--
David Jander
^ permalink raw reply
* Re: Watchdog on MPC82xx
From: Bastos Fernandez Alexandre @ 2006-04-19 11:13 UTC (permalink / raw)
To: linuxppc-embedded list
In-Reply-To: <1144842264.443ce818d6822@webmail.televes.com:443>
Well,
I have tested two different approaches which has been confirmed
to be already working on MPC82xx boards.
One, from Paul Bilke, is based on modifiying printk to service
the WDT and reload the counter during boot time.
So I have modified kernel/printk.c and tested with this:
asmlinkage int printk(const char *fmt, ...)
{
va_list args;
int r;
force_wdt_reload();
[...]
}
#define SWSR_ADDR (CPM_MAP_ADDR + 0x1000E)
void force_wdt_reload(void)
{
unsigned short *swsr_ptr = (unsigned short *)ioremap(SWSR_ADDR,0x2);
(*swsr_ptr) = (unsigned short) 0x556c;
(*swsr_ptr) = (unsigned short) 0xaa39;
}
Paul has reported changing printk works for him on several MPC82xx boards.
Second one is from Mike Rapoport from Compulab. Is the heartbeat
method. I have added and additional call in m82xx_board_setup()
which should reset the WDT for the first time in setup_arch():
static __inline__ void reset_8260_watchdog(void)
{
cpm2_immr->im_siu_conf.siu_82xx.sc_swsr = 0x556c;
cpm2_immr->im_siu_conf.siu_82xx.sc_swsr = 0xaa39;
}
void __init
m82xx_board_setup(void)
{
volatile cpm2_map_t *immap = cpm2_immr;
reset_8260_watchdog();
ppc_md.heartbeat = m82xx_heartbeat;
ppc_md.heartbeat_reset = HZ/2;
ppc_md.heartbeat_count = 1;
}
Mike has reported the heartbeat method is working for him
on MPC8247 and MPC8271 boards with kernel 2.6.12.3.
I have tested both in a MCP8248 based board, with kernel
2.6.15 and u-boot 1.1.4 and I have no success. I can see
the __log_buf after the reset caused by de WDT and there
are several printk's done. I have put printk's to the
reset_8260_watchdog(), and I can see them also, so I
should suppose it is executed, but the board keeps reseting.
Furthermore, u-boot is doing OK the WDT job (with changes done
from Compulab).
I have dissasambled that, and for example:
c01c93b8 <m82xx_board_setup>:
c01c93b8: 3d 40 c0 1e lis r10,-16354
c01c93bc: 38 00 55 6c li r0,21868
c01c93c0: 81 2a 81 8c lwz r9,-32372(r10)
c01c93c4: 3d 09 00 01 addis r8,r9,1
c01c93c8: b0 08 00 0e sth r0,14(r8)
c01c93cc: 81 68 0d 50 lwz r11,3408(r8)
c01c93d0: 81 2a 81 8c lwz r9,-32372(r10)
c01c93d4: 75 60 08 00 andis. r0,r11,2048
c01c93d8: 38 00 aa 39 li r0,-21959
c01c93dc: 3d 29 00 01 addis r9,r9,1
c01c93e0: b0 09 00 0e sth r0,14(r9)
c01c93e4: 41 82 00 44 beq- c01c9428 <m82xx_board_setup+0x70>
[...]
which looks OK for me (but I am not an expert).
So, could someone give me some guideline about what could
be happening?. Should I downgrade to 2.6.12.3 and test?
Is the WDT being reloaded at least one time and then
failing to reset? Some idea on how to debug that?
Thanks
Alex BASTOS
P.S. The __log_buf
3c353e4c 696e7578 20766572 73696f6e <5>Linux version
20322e36 2e313520 28616c65 62617340 2.6.15 (alebas@
54523339 32292028 67636320 76657273 xxxx) (gcc vers
696f6e20 332e332e 32292023 33392050 ion 3.3.2) #39 P
5245454d 50542054 75652041 70722031 REEMPT Tue Apr 1
38203135 3a32353a 33392043 45535420 8 15:25:39 CEST
32303036 0a3c363e 54656c65 76657320 2006.<6>Televes
446f4338 32343820 436f6d70 75746572 XXX8248 Computer
2d6f6e2d 4d6f6475 6c652070 6f72740a -on-Module port.
3c373e4f 6e206e6f 64652030 20746f74 <7>On node 0 tot
616c7061 6765733a 20313633 38340a3c alpages: 16384.<
373e2020 444d4120 7a6f6e65 3a203136 7> DMA zone: 16
33383420 70616765 732c204c 49464f20 384 pages, LIFO
62617463 683a330a 3c373e20 20444d41 batch:3.<7> DMA
3332207a 6f6e653a 20302070 61676573 32 zone: 0 pages
2c204c49 464f2062 61746368 3a300a3c , LIFO batch:0.<
373e2020 4e6f726d 616c207a 6f6e653a 7> Normal zone:
20302070 61676573 2c204c49 464f2062 0 pages, LIFO b
61746368 3a300a3c 373e2020 48696768 atch:0.<7> High
4d656d20 7a6f6e65 3a203020 70616765 Mem zone: 0 page
732c204c 49464f20 62617463 683a300a s, LIFO batch:0.
3c343e42 75696c74 2031207a 6f6e656c <4>Built 1 zonel
69737473 0a3c353e 4b65726e 656c2063 ists.<5>Kernel c
6f6d6d61 6e64206c 696e653a 20726f6f ommand line: roo
743d2f64 65762f72 616d3020 72772063 t=/dev/ram0 rw c
6f6e736f 6c653d74 74794350 4d0a3c35 onsole=ttyCPM.<5
3e596f75 20617265 20617420 4f6e650a >You are at One.
3c343e50 49442068 61736820 7461626c <4>PID hash tabl
6520656e 74726965 733a2035 31322028 e entries: 512 (
6f726465 723a2039 2c203831 00000000 order: 9, 81....
00000000 00000000 00000000 00000000 ................
^ permalink raw reply
* Re: Upgrading cramfs root file system
From: Wojciech Kromer @ 2006-04-19 7:42 UTC (permalink / raw)
To: linuxppc-embedded
In-Reply-To: <200604062238.17972.antonio.dibacco@aruba.it>
Dnia 2006-04-06 22:38, Użytkownik Antonio Di Bacco napisał:
> Hi,
>
> how could I upgrade my cramfs rootfs? I have a CGI in the rootfs that receives
> the new rootfs from a web interface and then tries to write it in the flash.
> While overwriting the old cramfs, the CGI will continue to work? something
> weird could happen?
>
Generally it's not a good idea to override working filesystem ( I've
tried to do it once).
You can have two separate copies of filesystem, one to work with, and
another to overwrite, it requires more flash.
Another way is working in initrd, it requires more RAM.
You can also use jffs2 or jffs3 (experimental) to have read-write
filesystem, and change applications only, not whole filesystem (be
carefull with changing busybox or libraries!)
^ permalink raw reply
* I want to use SCC3 as ethernet with SMC1 as console(mpc8xx)
From: 김영남 @ 2006-04-19 6:40 UTC (permalink / raw)
To: linuxppc-embedded
First of all, I am sorry for my poor english.
I have mpc850 custom board with followings:
SMC1 - console
SMC2 - uart
SCC2 - ethernet
I want to use SCC2 and SCC3 as ethernet(two ethernet interfaces).
As many web sites and mailing lists describe, I knew that SMC patch is
required because SMC1 and SCC3 share parameter ram.
I have DENX 2.4.25 kernel and this kernel works fine except using SCC3
as ethernet.
When apply "USE_SMC_PATCH" in arch/ppc/8xx_io/micropatch.c, kernel hang
and reset without any messages.(using u-boot 1.1.4)
I want to know that when I use "USE_SMC_PATCH", which source file is
modified and how to modify source file to use SMC1 as console.
Could you tell me useful information about that?
^ permalink raw reply
* Re: 2.6.16 backtrace at boot (Ibook G4) (related to "PowerBook5,4 -- no sound?")
From: Benjamin Herrenschmidt @ 2006-04-19 5:19 UTC (permalink / raw)
To: Paul Collins
Cc: [ATR]Dj-Death, linuxppc-dev, Michael Schmitz, debian-powerpc,
Paul Mackerras
In-Reply-To: <87r73u19b1.fsf@briny.internal.ondioline.org>
> arch/powerpc/platforms/powermac/setup.c:721: error: 'mach_powermac' undeclared here (not in a function)
> arch/powerpc/platforms/powermac/setup.c:721: warning: type defaults to 'int' in declaration of 'mach_powermac'
> make[2]: *** [arch/powerpc/platforms/powermac/setup.o] Error 1
> make[1]: *** [arch/powerpc/platforms/powermac] Error 2
> make: *** [arch/powerpc/platforms] Error 2
>
> It looks like the EXPORT_SYMBOL() needs to be after the definition.
>
> However, I tried adding "EXPORT_SYMBOL(mach_powermac);" after the
> define_machine(powermac) and now sound works for me with my original
> I2C_POWERMAC=y SND_POWERMAC=m configuration.
Yup, Paul has a working patch already, will be in 2.6.17 soonish.
Cheers,
Ben.
^ permalink raw reply
* Re: 2.6.16 backtrace at boot (Ibook G4) (related to "PowerBook5, 4 -- no sound?")
From: Paul Collins @ 2006-04-19 4:25 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: [ATR]Dj-Death, linuxppc-dev, Michael Schmitz, debian-powerpc,
Paul Mackerras
In-Reply-To: <1145397523.4705.94.camel@localhost.localdomain>
Hi Ben,
Benjamin Herrenschmidt <benh@kernel.crashing.org> writes:
> On Tue, 2006-04-18 at 17:20 +0200, Michael Schmitz wrote:
>> > > Here a trace at boot from the sound driver :
>> >
>> > I think that bug happens if the sound driver loads before i2c-powermac.
>>
>> i2c-keywest is still request-module()d in 2.6.17-rc1, FWIW.
>>
>> Regarding other sound breakage with 2.6.17-rc1, I traced that to
>>
>> machine_is(powermac)
>>
>> returning zero in sound/ppc/pmac.c:snd_pmac_detect() when loading
>> snd-powermac. The OSS driver spits -ENODEV as well on loading so I'd
>> suspect the same thing here.
>>
>> machine_is boils down to a comparison machine_id == &mach_powermac, is
>> that sort of thing illegal after kernel init?
>
> Totally untested patch, please let me know if it helps:
Results in the following.
arch/powerpc/platforms/powermac/setup.c:721: error: 'mach_powermac' undeclared here (not in a function)
arch/powerpc/platforms/powermac/setup.c:721: warning: type defaults to 'int' in declaration of 'mach_powermac'
make[2]: *** [arch/powerpc/platforms/powermac/setup.o] Error 1
make[1]: *** [arch/powerpc/platforms/powermac] Error 2
make: *** [arch/powerpc/platforms] Error 2
It looks like the EXPORT_SYMBOL() needs to be after the definition.
However, I tried adding "EXPORT_SYMBOL(mach_powermac);" after the
define_machine(powermac) and now sound works for me with my original
I2C_POWERMAC=y SND_POWERMAC=m configuration.
--
Dag vijandelijk luchtschip de huismeester is dood
^ permalink raw reply
* Re: [PATCH] Remove stale iseries global
From: Will Schmidt @ 2006-04-18 19:02 UTC (permalink / raw)
To: michael; +Cc: Olof Johansson, linuxppc-dev, paulus
In-Reply-To: <1145382862.20176.5.camel@localhost.localdomain>
On Tue, 2006-04-18 at 19:54 +0200, Michael Ellerman wrote:
> On Tue, 2006-04-18 at 12:31 -0500, Will Schmidt wrote:
> > On Tue, 2006-04-18 at 11:25 -0500, Olof Johansson wrote:
> > > Hi,
> > >
> > > Not even the iSeries maintainer seems to have access to this legendary
> > > piranha simulator. It adds a bit of ugliness in the common time init
> > > code, and if it's no longer used we might as well be done with it and
> > > remove the bloat.
> >
> > Yes, the piranha tools are no longer used with linux. I see no reason
> > why this needs to stay.
>
> So can we get rid of this from head_64.S as well? Or is that a different
> debugger?
It's likely the same (piranha) debugger. I'm not aware of any other
debuggers that would be involved here.
What I dont know is if this offset to the mschunks_map array is also
used by the hypervisor for some non debug purposes. If iSeries
continues to work without it, then it can probably go too.
Just be sure that PPC_EARLY_DEBUG_ISERIES will continue to work for
getting info out of the system. :-)
> /*
> * At offset 0x28 and 0x30 are offsets to the mschunks_map
> * array (used by the iSeries LPAR debugger to do translation
> * between physical addresses and absolute addresses) and
> * to the pidhash table (also used by the debugger)
> */
> .llong mschunks_map-KERNELBASE
> .llong 0 /* pidhash-KERNELBASE SFRXXX */
>
> cheers
>
^ permalink raw reply
* Re: [PATCH 0/7] [RFC] Sizing zones and holes in an architecture independent manner V3
From: Mel Gorman @ 2006-04-18 20:27 UTC (permalink / raw)
To: Jack Steiner
Cc: davej, tony.luck, Linux Memory Management List, ak, bob.picco,
Linux Kernel Mailing List, linuxppc-dev
In-Reply-To: <20060418195644.GA30911@sgi.com>
On Tue, 18 Apr 2006, Jack Steiner wrote:
> On Tue, Apr 18, 2006 at 02:00:15PM +0100, Mel Gorman wrote:
>> This is V3 of the patchset to size zones and memory holes in an
> ...
>
>
>
> FYI, I applied the patches to a recent kernel & booted on a large
> SGI system.
Very cool, thanks for testing. I'm glad to see the assumptions related to
the size of node_map held up for a large machine.
> No problem aside from what I assume is a very large number
> of debug messages.
>
The debug messages are all in patch 7/7 and will be dropped before I try
and push this to -mm. The patch was included here in case a machine failed
to boot so I could figure out what went wrong.
>
> ------
> Linux version 2.6.17-tony (steiner@attica) (gcc version 4.1.0 (SUSE Linux)) #5 SMP PREEMPT Tue Apr 18 14:01:54 CDT 2006
> EFI v1.10 by INTEL: SALsystab=0x6002c51df0 ACPI 2.0=0x6002c51ee0
> Number of logical nodes in system = 512
> Number of memory chunks in system = 512
> SAL 2.9: SGI SN2 version 1.10
> SAL Platform features: ITC_Drift
> SAL: AP wakeup using external interrupt vector 0x12
> No logical to physical processor mapping available
> ACPI: Local APIC address c0000000fee00000
> ACPI: Error parsing MADT - no IOSAPIC entries
> register_intr: No IOSAPIC for GSI 52
> 512 CPUs available, 512 CPUs total
> MCA related initialization done
> SGI SAL version 1.10
> add_active_range(0, 25168900, 25235456): New
> add_active_range(0, 25236375, 25419776): New
> add_active_range(0, 27262976, 27516927): New
> add_active_range(0, 29360128, 29614080): New
> add_active_range(1, 92277760, 92528640): New
> ...
> add_active_range(511, 34322242024, 34322242047): New
> add_active_range(511, 34322243072, 34322243417): New
> add_active_range(511, 34322243432, 34322243460): New
> add_active_range(511, 34322243488, 34322243500): New
> Virtual mem_map starts at 0xa0007e407d270000
> free_area_init_nodes(68719476736, 68719476736, 34322243584, 34322243584)
> free_area_init_nodes(): find_min_pfn = 25168900
> Dumping sorted node map
> entry 0: 0 25168900 -> 25235456
> entry 1: 0 25236375 -> 25419776
> entry 2: 0 27262976 -> 27516927
> entry 3: 0 29360128 -> 29614080
> entry 4: 1 92277760 -> 92528640
> entry 5: 1 94371840 -> 94625792
> entry 6: 1 96468992 -> 96722944
> ...
> entry 1536: 511 34321989632 -> 34322242001
> entry 1537: 511 34322242016 -> 34322242022
> entry 1538: 511 34322242024 -> 34322242047
> entry 1539: 511 34322243072 -> 34322243417
> entry 1540: 511 34322243432 -> 34322243460
> entry 1541: 511 34322243488 -> 34322243500
> __absent_pages_in_range(0, 25168900, 68719476736) = 3687320
> __absent_pages_in_range(0, 68719476736, 68719476736) = 0
> __absent_pages_in_range(0, 68719476736, 34322243584) = 0
> __absent_pages_in_range(0, 34322243584, 34322243584) = 0
> __absent_pages_in_range(0, 25168900, 68719476736) = 3687320
> ...
> __absent_pages_in_range(511, 34322243584, 34322243584) = 0
> __absent_pages_in_range(511, 25168900, 68719476736) = 3687485
> __absent_pages_in_range(511, 68719476736, 68719476736) = 0
> __absent_pages_in_range(511, 68719476736, 34322243584) = 0
> __absent_pages_in_range(511, 34322243584, 34322243584) = 0
> Built 512 zonelists
> Kernel command line: BOOT_IMAGE=net0:jfs/tonys ro hashdist=1 dhash_entries=2097152 ihash_entries=2097152 rhash_entries=2097152 thash_entries=2097152 console=ttySG0,38400n8 kdb=on noprobe root=/dev/sda5
> PID hash table entries: 4096 (order: 12, 32768 bytes)
> Console: colour dummy device 80x25
> Memory: 4639378784k/4655642784k available (7021k code, 16279040k reserved, 4361k data, 736k init)
> (essentially the same numbers as with a kernel w/o the patches)
> McKinley Errata 9 workaround not needed; disabling it
>
--
Mel Gorman
Part-time Phd Student Linux Technology Center
University of Limerick IBM Dublin Software Lab
^ permalink raw reply
* Re: [PATCH 0/7] [RFC] Sizing zones and holes in an architecture independent manner V3
From: Jack Steiner @ 2006-04-18 19:56 UTC (permalink / raw)
To: Mel Gorman
Cc: davej, tony.luck, linux-mm, ak, bob.picco, linux-kernel,
linuxppc-dev
In-Reply-To: <20060418130015.28928.10163.sendpatchset@skynet>
On Tue, Apr 18, 2006 at 02:00:15PM +0100, Mel Gorman wrote:
> This is V3 of the patchset to size zones and memory holes in an
...
FYI, I applied the patches to a recent kernel & booted on a large
SGI system. No problem aside from what I assume is a very large number
of debug messages.
------
Linux version 2.6.17-tony (steiner@attica) (gcc version 4.1.0 (SUSE Linux)) #5 SMP PREEMPT Tue Apr 18 14:01:54 CDT 2006
EFI v1.10 by INTEL: SALsystab=0x6002c51df0 ACPI 2.0=0x6002c51ee0
Number of logical nodes in system = 512
Number of memory chunks in system = 512
SAL 2.9: SGI SN2 version 1.10
SAL Platform features: ITC_Drift
SAL: AP wakeup using external interrupt vector 0x12
No logical to physical processor mapping available
ACPI: Local APIC address c0000000fee00000
ACPI: Error parsing MADT - no IOSAPIC entries
register_intr: No IOSAPIC for GSI 52
512 CPUs available, 512 CPUs total
MCA related initialization done
SGI SAL version 1.10
add_active_range(0, 25168900, 25235456): New
add_active_range(0, 25236375, 25419776): New
add_active_range(0, 27262976, 27516927): New
add_active_range(0, 29360128, 29614080): New
add_active_range(1, 92277760, 92528640): New
...
add_active_range(511, 34322242024, 34322242047): New
add_active_range(511, 34322243072, 34322243417): New
add_active_range(511, 34322243432, 34322243460): New
add_active_range(511, 34322243488, 34322243500): New
Virtual mem_map starts at 0xa0007e407d270000
free_area_init_nodes(68719476736, 68719476736, 34322243584, 34322243584)
free_area_init_nodes(): find_min_pfn = 25168900
Dumping sorted node map
entry 0: 0 25168900 -> 25235456
entry 1: 0 25236375 -> 25419776
entry 2: 0 27262976 -> 27516927
entry 3: 0 29360128 -> 29614080
entry 4: 1 92277760 -> 92528640
entry 5: 1 94371840 -> 94625792
entry 6: 1 96468992 -> 96722944
...
entry 1536: 511 34321989632 -> 34322242001
entry 1537: 511 34322242016 -> 34322242022
entry 1538: 511 34322242024 -> 34322242047
entry 1539: 511 34322243072 -> 34322243417
entry 1540: 511 34322243432 -> 34322243460
entry 1541: 511 34322243488 -> 34322243500
__absent_pages_in_range(0, 25168900, 68719476736) = 3687320
__absent_pages_in_range(0, 68719476736, 68719476736) = 0
__absent_pages_in_range(0, 68719476736, 34322243584) = 0
__absent_pages_in_range(0, 34322243584, 34322243584) = 0
__absent_pages_in_range(0, 25168900, 68719476736) = 3687320
...
__absent_pages_in_range(511, 34322243584, 34322243584) = 0
__absent_pages_in_range(511, 25168900, 68719476736) = 3687485
__absent_pages_in_range(511, 68719476736, 68719476736) = 0
__absent_pages_in_range(511, 68719476736, 34322243584) = 0
__absent_pages_in_range(511, 34322243584, 34322243584) = 0
Built 512 zonelists
Kernel command line: BOOT_IMAGE=net0:jfs/tonys ro hashdist=1 dhash_entries=2097152 ihash_entries=2097152 rhash_entries=2097152 thash_entries=2097152 console=ttySG0,38400n8 kdb=on noprobe root=/dev/sda5
PID hash table entries: 4096 (order: 12, 32768 bytes)
Console: colour dummy device 80x25
Memory: 4639378784k/4655642784k available (7021k code, 16279040k reserved, 4361k data, 736k init)
(essentially the same numbers as with a kernel w/o the patches)
McKinley Errata 9 workaround not needed; disabling it
^ permalink raw reply
* Re: Port Linux w/ mbxboot to PPCBoot system
From: Jessica Chen @ 2006-04-18 19:51 UTC (permalink / raw)
To: linuxppc-embedded
In-Reply-To: <20060415001224.D1551353A56@atlas.denx.de>
Thank you for your reply Wolfgang!
In u-boot-1.1.4 README "Where we come from" section, it says u-boot "provide
extended interface to Linux boot loader". Does it mean that there is still
some sort of boot loader in arch/ppc/coffboot/vmlinux.gz ? If yes, when
does it start? Does it boot the kernel?
To build u-boot, I will need to get the manual for MPC852 and check the
configurations in include/configs/TQM860L.h file.
I am trying to find the machine specific header file in linux-2.4.25
(include/asm-ppc/tqm8xx.h file in linux-2.4.4) which should have the same
definition of structure bd_info as in include/asm-ppc/u-boot.h. And you
recommend using linux-2.4 instead of linux-2.6 on your website.
So am I heading the right directions here? Because the u-boot README
doesn't have the new directories and filenames, I am a little confused.
Thanks again,
Jessica
> > I am new to embedded system, I am studying ppcboot-1.1.5 and linux
> > kernel-2.4.4 that comes with an mpc852 base board, we want to modify it
in
>
> Both PPCBoot and Linux 2.4.4 are *hoplessly* obsolete. It may be ok
> to study this to understand the workings, but please don't even dream
> of using it for any current work.
>
> > the future. In the build process, they use the zImage.initrd
> > (arch/ppc/mbxboot/zvmlinux.initrd) instead of the raw Linux kernel image
>
> Somebody didn't know what he was doing, it seems.
>
> > since ppcboot is already running, what happens when I boot the kernel
that
> > has old boot loader code in arch/ppc/mbxboot? Will some parameters be
> > overwritten? If not, why?
>
> The Linux bootstrap loader code (arch/ppc/mbxboot) will ignore the
> parameteres passed by U-Boot, will set up is own (hardwired), and
> duplicate some of the things that PPCboot did or would do.
>
> > I am very tempted to follow the README to re-build the kernel with
only
> > vmlinux.gz and port it, but I don't want to create any un-recoverable
> > results. So I am here to seek advice, maybe this is something obvious
to
> > many people.
>
> Don't change anything. Look at it, then drop it. Start using current
> code, i. e. a recent version of U-Boot and a recent Linux kernel.
^ permalink raw reply
* Re: [PATCH] powerpc: Make rtas console _much_ faster
From: Olof Johansson @ 2006-04-18 19:30 UTC (permalink / raw)
To: Michael Ellerman; +Cc: linuxppc-dev, cbe-oss-dev
In-Reply-To: <20060418185534.B1ADF679F0@ozlabs.org>
On Tue, Apr 18, 2006 at 08:55:29PM +0200, Michael Ellerman wrote:
> I'll test this on P5 LPAR, is there anyone else that uses hvc_console?
> Thoughts?
I have an out-of-tree HVC backend here for a simple simulator console
(will never make it in-tree since it's never going to see other users). So
not that it really matters, but the patch is OK for that environment.
The only other case I can think of is if the backend really needs some
time to clear out data, if we end up spinning too much in the yield()
loop. POWER4 with HVC console is a possible candidate there, since all
partitions share a 19200bps line for consoles.
> Signed-off-by: Michael Ellerman <michael@ellerman.id.au>
Assuming it's not an issue on POWER4 LPAR:
Acked-by: Olof Johansson <olof@lixom.net>
^ permalink raw reply
* Re: 7447A strange problem with MSR:POW (WAS: can't boot 2.6.17-rc1)
From: Becky Bruce @ 2006-04-18 19:29 UTC (permalink / raw)
To: paulus; +Cc: linuxppc-dev, schmitz, debian-powerpc
Paul,
This new version of the patch breaks 32-bit arch/ppc builds. The changes
to the idle_6xx code are shared between architectures, but the entry.S
code and asm-offsets.c are not.
Here's a patch that puts the changes in arch/ppc as well. Builds and
boots on 834x (which is CONFIG_6xx).
-B
ppc: Fix powersave on arch/ppc
Fix asm_offsets.c and entry.S to work with the new power save code.
Changes in arch/powerpc needed to exist in arch/ppc as well since the
idle code is shared by both ppc and powerpc..
Signed-off-by: Becky Bruce <becky.bruce@freescale.com>
---
commit c9b42c4b6ad17aea51066604b70ea7ec399d2e45
tree 38642212d6396ecad721efca967ae1fc8924e096
parent c85f35d06479bf7cb5cfc7cda0ea218a23ed2dc4
author Becky Bruce <becky.bruce@freescale.com> Tue, 18 Apr 2006 14:12:03 -0500
committer Becky Bruce <becky.bruce@freescale.com> Tue, 18 Apr 2006 14:12:03 -0500
arch/ppc/kernel/asm-offsets.c | 1 +
arch/ppc/kernel/entry.S | 33 ++++++++++++++++-----------------
2 files changed, 17 insertions(+), 17 deletions(-)
diff --git a/arch/ppc/kernel/asm-offsets.c b/arch/ppc/kernel/asm-offsets.c
index 77e4dc7..cc7c4ae 100644
--- a/arch/ppc/kernel/asm-offsets.c
+++ b/arch/ppc/kernel/asm-offsets.c
@@ -134,6 +134,7 @@ main(void)
DEFINE(TI_TASK, offsetof(struct thread_info, task));
DEFINE(TI_EXECDOMAIN, offsetof(struct thread_info, exec_domain));
DEFINE(TI_FLAGS, offsetof(struct thread_info, flags));
+ DEFINE(TI_LOCAL_FLAGS, offsetof(struct thread_info, flags));
DEFINE(TI_CPU, offsetof(struct thread_info, cpu));
DEFINE(TI_PREEMPT, offsetof(struct thread_info, preempt_count));
diff --git a/arch/ppc/kernel/entry.S b/arch/ppc/kernel/entry.S
index 5891ecb..1adc914 100644
--- a/arch/ppc/kernel/entry.S
+++ b/arch/ppc/kernel/entry.S
@@ -128,29 +128,26 @@ transfer_to_handler:
stw r12,4(r11)
#endif
b 3f
+
2: /* if from kernel, check interrupted DOZE/NAP mode and
* check for stack overflow
*/
+ lwz r9,THREAD_INFO-THREAD(r12)
+ cmplw r1,r9 /* if r1 <= current->thread_info */
+ ble- stack_ovf /* then the kernel stack overflowed */
+5:
#ifdef CONFIG_6xx
- mfspr r11,SPRN_HID0
- mtcr r11
-BEGIN_FTR_SECTION
- bt- 8,4f /* Check DOZE */
-END_FTR_SECTION_IFSET(CPU_FTR_CAN_DOZE)
-BEGIN_FTR_SECTION
- bt- 9,4f /* Check NAP */
-END_FTR_SECTION_IFSET(CPU_FTR_CAN_NAP)
+ tophys(r9,r9) /* check local flags */
+ lwz r12,TI_LOCAL_FLAGS(r9)
+ mtcrf 0x01,r12
+ bt- 31-TLF_NAPPING,4f
#endif /* CONFIG_6xx */
.globl transfer_to_handler_cont
transfer_to_handler_cont:
- lwz r11,THREAD_INFO-THREAD(r12)
- cmplw r1,r11 /* if r1 <= current->thread_info */
- ble- stack_ovf /* then the kernel stack overflowed */
3:
mflr r9
lwz r11,0(r9) /* virtual address of handler */
lwz r9,4(r9) /* where to go when done */
- FIX_SRR1(r10,r12)
mtspr SPRN_SRR0,r11
mtspr SPRN_SRR1,r10
mtlr r9
@@ -158,7 +155,9 @@ transfer_to_handler_cont:
RFI /* jump to handler, enable MMU */
#ifdef CONFIG_6xx
-4: b power_save_6xx_restore
+4: rlwinm r12,r12,0,~_TLF_NAPPING
+ stw r12,TI_LOCAL_FLAGS(r9)
+ b power_save_6xx_restore
#endif
/*
@@ -167,10 +166,10 @@ transfer_to_handler_cont:
*/
stack_ovf:
/* sometimes we use a statically-allocated stack, which is OK. */
- lis r11,_end@h
- ori r11,r11,_end@l
- cmplw r1,r11
- ble 3b /* r1 <= &_end is OK */
+ lis r12,_end@h
+ ori r12,r12,_end@l
+ cmplw r1,r12
+ ble 5b /* r1 <= &_end is OK */
SAVE_NVGPRS(r11)
addi r3,r1,STACK_FRAME_OVERHEAD
lis r1,init_thread_union@ha
^ permalink raw reply related
* Re: [patch][rfc]flattened device tree: Passing a dtb (blob) to Linux.
From: Jimi Xenidis @ 2006-04-18 18:42 UTC (permalink / raw)
To: michael; +Cc: linuxppc-dev@ozlabs.org, Michael Neuling
In-Reply-To: <1145383451.20176.9.camel@localhost.localdomain>
ok, to accept (1) means to accept (2).
AFAICT LMB is already handling overlaps.
So the first rough patch I sent should be sufficient.
On Apr 18, 2006, at 2:04 PM, Michael Ellerman wrote:
> On Tue, 2006-04-18 at 11:48 -0500, Jon Loeliger wrote:
>> On Thu, 2006-04-13 at 09:34, Michael Ellerman wrote:
>>> On Thu, 2006-04-13 at 09:19 -0400, Jimi Xenidis wrote:
>>>> Actually, is this even an issue? can the LMB handle repeated
>>>> reservations?
>>>
>>> It can, but we were thinking about adding code to check and warn if
>>> reservations overlap, because it usually indicates a bug. Although
>>> that's probably ok in this case, as long as dtc gets fixed
>>> eventually.
>>> Another option would be to not warn for identical reservations.
>>
>>>>>>>>> NOTE: that the dtc must also not generate the blob reservation
>>>>>>>>> entry.
>>
>>>>>> looking passed my own world I see:
>>>>>> - iSeries: not reserving the blob at all
>>>>>
>>>>> That sounds right. I think having the kernel do it is
>>>>> definitely the
>>>>> right option.
>>
>>
>> OK, I'm back to reading the list and beginning to catch
>> up some here...
>>
>> Let me see if I understand the consensus and direction:
>>
>> 1) DTC should NOT reserve its own blob space in the
>> memory map, as it does for generated ASM code now,
>>
>> 2) Kernel should reserve the blob space early so as
>> not to step on itself later,
>>
>> 3a) Kernel LMB handling should be modified to warn
>> for overlapping LMB reservations,
>>
>> Except that Ben says:
>>
>> 3b) We should make lmb_reserve() of redudant/overlapping
>> entries become harmless I think. We need to be
>> backward compatible with earlier blobs that do
>> contain themselves in the reserve map.
>>
>> I think we should interpret "harmless" to be "warn" and not
>> cause an error at this point in time.
>>
>> I do not think we should have the blob generate its own
>> reservation because it is possible that some post-processing
>> (like U-Boot) can modify and extend it. Only after that can
>> the blob's true size be determined. (Sure, it could update
>> on the fly too... but double blah).
>>
>> In all of this, I'm on deck for step 1) above.
>
> Nice summary :)
> I'm up for 3a, we should make redundant/overlapping reserves
> "harmless",
> by which I mean "not an error", but there should definitely be a
> warning
> in the dmesg - as it will _usually_ indicate a bug.
>
> cheers
>
> --
> Michael Ellerman
> IBM OzLabs
>
> wwweb: http://michael.ellerman.id.au
> phone: +61 2 6212 1183 (tie line 70 21183)
>
> We do not inherit the earth from our ancestors,
> we borrow it from our children. - S.M.A.R.T Person
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-dev
^ permalink raw reply
* kernel 2.6.15: cpm_uart driver broken?
From: Kenneth Poole @ 2006-04-18 19:19 UTC (permalink / raw)
To: linuxppc-embedded
[-- Attachment #1: Type: text/plain, Size: 1055 bytes --]
For David Jander and Vitaly Bordug:
Regarding DMA allocation for CPM uarts, we had a similar issue with our
MPC857T and MPC885 boards. I think the real problem is that
bus_to_virt() and virt_to_bus() don't work on 8xx platforms for
addresses allocated using dma_alloc_coherent(). We had a previous
discussion Pantelis Antoniou and he agreed that the use of bus_to_virt()
and virt_to_bus() should be deprecated. This is also recommended in the
whitepaper series that discussed porting device drivers from 2.4 to 2.6.
What we did was use dma_alloc_coherent() in cpm_uart_cpm1.c, saving
dma_addr in the pinfo structure. The in cpm_uart_core.c, we use dma_addr
as the base address for the cbd_bufaddr values in each of the
descriptors. The software, when accessing the DMA buffers, uses mem_addr
as the base, applying the same offset computed previously for the dma
addresses. This technique is used in other drivers all over 2.6.
This avoids the configuration dependencies on the conversion functions.
Ken Poole
kpoole@bos.mrv.com
[-- Attachment #2: Type: text/html, Size: 5214 bytes --]
^ permalink raw reply
* [PATCH] powerpc: Make rtas console _much_ faster
From: Michael Ellerman @ 2006-04-18 18:55 UTC (permalink / raw)
To: linuxppc-dev; +Cc: cbe-oss-dev
Currently the hvc_rtas driver is painfully slow to use. Our "benchmark" is
ls -R /etc, which spits out about 27866 characters. The theoretical maximum
speed would be about 2.2 seconds, the current code takes ~50 seconds.
The core of the problem is that sometimes when the tty layer asks us to push
characters the firmware isn't able to handle some or all of them, and so
returns an error. The current code sees this and just returns to the tty code
with the buffer half sent.
There's the khvcd thread which will eventually wake up and try to push more
characters, that will usually work because the firmware's had time to push
the characters out. But the thread only wakes up every 10 milliseconds, which
isn't fast enough.
There's already code in the hvc_console driver to make the khvcd thread do
a "quick" loop, where it just calls yield() instead of sleeping. The only code
that triggered that behaviour was recently removed though, which I don't
quite understand.
Still, if we set HVC_POLL_QUICK whenever the push hvc_push() doesn't push all
characters (ie. RTAS blocks), we can get good performance out of the hvc_rtas
backend. With this patch the "benchmark" takes ~2.8 seconds.
I'll test this on P5 LPAR, is there anyone else that uses hvc_console?
Thoughts?
Signed-off-by: Michael Ellerman <michael@ellerman.id.au>
---
drivers/char/hvc_console.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
Index: cell/drivers/char/hvc_console.c
===================================================================
--- cell.orig/drivers/char/hvc_console.c
+++ cell/drivers/char/hvc_console.c
@@ -570,7 +570,7 @@ static int hvc_poll(struct hvc_struct *h
hvc_push(hp);
/* Reschedule us if still some write pending */
if (hp->n_outbuf > 0)
- poll_mask |= HVC_POLL_WRITE;
+ poll_mask |= HVC_POLL_WRITE | HVC_POLL_QUICK;
/* No tty attached, just skip */
tty = hp->tty;
^ permalink raw reply
* Re: please pull powerpc-merge.git
From: Andy Fleming @ 2006-04-18 18:20 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev Development
In-Reply-To: <17476.55180.340464.351828@cargo.ozlabs.ibm.com>
On Apr 18, 2006, at 07:11, Paul Mackerras wrote:
> Linus,
>
> Please do a pull from
>
> git://git.kernel.org/pub/scm/linux/kernel/git/paulus/powerpc-merge.git
>
> to get the following powerpc bug-fixes.
What happened to the 85xx merge patches?
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox