* [ECOS] dOUG lEE'S MALLOC @ 2007-09-13 19:40 Rick Davis 2007-09-13 20:32 ` [ECOS] Question on serial ports Scott Moore 2007-09-13 20:59 ` [ECOS] dOUG lEE'S MALLOC Andrew Lunn 0 siblings, 2 replies; 11+ messages in thread From: Rick Davis @ 2007-09-13 19:40 UTC (permalink / raw) To: Ecos-Discuss I am porting to a new Power-PC platform that has 256M of DDR on it. I am using the latest snapshot (today as a matter of fact). If I call setvbuf (stdout, NULL, _IONBF, 0), Doug's code complains throwing some sort of size assertion. If I don't call setvbuf but call show_memory, that complains about other issues. If I use the simple malloc routines instead, everything works fine. Is there a memory size issue? Is something not being called in the right order during initialization? I was also having issue programming my 64M of 32 bit wide Spansion FLASH with Doug's routines. The issue seems to have disappeared using the simple malloc functions. Rick Davis -- Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss ^ permalink raw reply [flat|nested] 11+ messages in thread
* [ECOS] Question on serial ports 2007-09-13 19:40 [ECOS] dOUG lEE'S MALLOC Rick Davis @ 2007-09-13 20:32 ` Scott Moore 2007-09-13 21:03 ` Andrew Lunn 2007-09-13 20:59 ` [ECOS] dOUG lEE'S MALLOC Andrew Lunn 1 sibling, 1 reply; 11+ messages in thread From: Scott Moore @ 2007-09-13 20:32 UTC (permalink / raw) To: Ecos-Discuss, Steve Gaskill Hi, I am working with a Keil MCB2300 board. I had a question on serial port implementations. Our installation was derived from the ARM/MCB2100 board which comes with ECOS, using the lpc2xxx structures. Included with the standard build is the diagnostic port haldiag, which is layered as ttydiag. The hal for the board includes code to access both ports, 0 and 1 on the board. However, the code does not appear to support more than a single port at the device level. The code does not appear to support interrupts, and uses the SERIAL_CHANNEL macro as opposed to the SERIAL_CHANNEL_USING_INTERRUPTS macro. Basically it appears that this installation was only designed to support a single diagnostics serial port which doubles as a GDB access port. under /packages/devs/serial, there is a directory for arm/lpc2xxx, but it contains the single file arm_lpc2xxx_ser.inl, which appears to just contain the headers for a possible driver. The functions defined in this file don't appear to go anywhere, for example "pc_serial_init", etc. The questions are: 1. Does this indeed indicate that a full (not diagnostic) serial port implementation was never completed for the MCB2100 board? 2. What was the purpose of the directory ../packages/devs/serial/arm/lpc2xxx/..? Was this just a placeholder for where a device might go? Thank you, Scott Moore Powerfile --- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.762 / Virus Database: 510 - Release Date: 9/13/2004 -- Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [ECOS] Question on serial ports 2007-09-13 20:32 ` [ECOS] Question on serial ports Scott Moore @ 2007-09-13 21:03 ` Andrew Lunn 2007-09-13 21:12 ` Scott Moore 0 siblings, 1 reply; 11+ messages in thread From: Andrew Lunn @ 2007-09-13 21:03 UTC (permalink / raw) To: Scott Moore; +Cc: Ecos-Discuss, Steve Gaskill > The questions are: > > 1. Does this indeed indicate that a full (not diagnostic) serial port > implementation was never completed for the MCB2100 board? > > 2. What was the purpose of the directory > ../packages/devs/serial/arm/lpc2xxx/..? Was this just a placeholder for > where a device might go? Take a look at the targets which use this: target p2106 { alias { "Olimex evaluation board LPC-P2106" p2106 } packages { CYGPKG_HAL_ARM CYGPKG_HAL_ARM_LPC2XXX CYGPKG_HAL_ARM_LPC2XXX_P2106 CYGPKG_IO_SERIAL_GENERIC_16X5X CYGPKG_IO_SERIAL_ARM_LPC2XXX CYGPKG_DEVICES_WATCHDOG_ARM_LPC2XXX } description " The p2106 target provides the packages needed to run eCos on the LPC-P2106 evaluation board from Olimex." } target lpcmt { alias { "Olimex evaluation board LPC-LPCMT" lpcmt } packages { CYGPKG_HAL_ARM CYGPKG_HAL_ARM_LPC2XXX CYGPKG_HAL_ARM_LPC2XXX_LPCMT CYGPKG_IO_SERIAL_GENERIC_16X5X CYGPKG_IO_SERIAL_ARM_LPC2XXX CYGPKG_DEVICES_WATCHDOG_ARM_LPC2XXX } description " The lpcmt target provides the packages needed to run eCos on the LPC-LPCMT evaluation board from Olimex." } Looking at this suggests that the LPC2XXX serial driver is just what is needed to make the generic 16x5x serial driver work on LPC targets. Take a closer look at one of the these targets and all should become clear... Andrew -- Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss ^ permalink raw reply [flat|nested] 11+ messages in thread
* RE: [ECOS] Question on serial ports 2007-09-13 21:03 ` Andrew Lunn @ 2007-09-13 21:12 ` Scott Moore 2007-09-14 21:05 ` Scott Moore 0 siblings, 1 reply; 11+ messages in thread From: Scott Moore @ 2007-09-13 21:12 UTC (permalink / raw) To: Andrew Lunn; +Cc: Ecos-Discuss, Steve Gaskill Thank you. -----Original Message----- From: Andrew Lunn [mailto:andrew@lunn.ch] Sent: Thursday, September 13, 2007 2:04 PM To: Scott Moore Cc: Ecos-Discuss; Steve Gaskill Subject: Re: [ECOS] Question on serial ports > The questions are: > > 1. Does this indeed indicate that a full (not diagnostic) serial port > implementation was never completed for the MCB2100 board? > > 2. What was the purpose of the directory > ../packages/devs/serial/arm/lpc2xxx/..? Was this just a placeholder > for where a device might go? Take a look at the targets which use this: target p2106 { alias { "Olimex evaluation board LPC-P2106" p2106 } packages { CYGPKG_HAL_ARM CYGPKG_HAL_ARM_LPC2XXX CYGPKG_HAL_ARM_LPC2XXX_P2106 CYGPKG_IO_SERIAL_GENERIC_16X5X CYGPKG_IO_SERIAL_ARM_LPC2XXX CYGPKG_DEVICES_WATCHDOG_ARM_LPC2XXX } description " The p2106 target provides the packages needed to run eCos on the LPC-P2106 evaluation board from Olimex." } target lpcmt { alias { "Olimex evaluation board LPC-LPCMT" lpcmt } packages { CYGPKG_HAL_ARM CYGPKG_HAL_ARM_LPC2XXX CYGPKG_HAL_ARM_LPC2XXX_LPCMT CYGPKG_IO_SERIAL_GENERIC_16X5X CYGPKG_IO_SERIAL_ARM_LPC2XXX CYGPKG_DEVICES_WATCHDOG_ARM_LPC2XXX } description " The lpcmt target provides the packages needed to run eCos on the LPC-LPCMT evaluation board from Olimex." } Looking at this suggests that the LPC2XXX serial driver is just what is needed to make the generic 16x5x serial driver work on LPC targets. Take a closer look at one of the these targets and all should become clear... Andrew --- Incoming mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.762 / Virus Database: 510 - Release Date: 9/13/2004 --- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.762 / Virus Database: 510 - Release Date: 9/13/2004 -- Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss ^ permalink raw reply [flat|nested] 11+ messages in thread
* RE: [ECOS] Question on serial ports 2007-09-13 21:12 ` Scott Moore @ 2007-09-14 21:05 ` Scott Moore 2007-09-14 21:13 ` Andrew Lunn 0 siblings, 1 reply; 11+ messages in thread From: Scott Moore @ 2007-09-14 21:05 UTC (permalink / raw) To: Scott Moore, Andrew Lunn; +Cc: Ecos-Discuss, Steve Gaskill Hi, sorry to post on this yet again, but I built both the p2106 and lpcmt targets, and both appear to have the same (forgive me) braindamaged I/O as the mcb2100 board target. I tried: C:\projects\testbuild>ecosconfig add CYGPKG_IO_SERIAL_GENERIC_16X5X Package `CYGPKG_IO_SERIAL_GENERIC_16X5X' is already loaded. And the configurator appears to believe that this is already selected. However, after building, I don't see the ser_16x5x.o file anywhere in the build. ser_16x5x.c is the file ../ecos/packages/devs/serial/generic/16x5x/current/src/ser_16x5x which contains the 16x5x general support. Instead it is including: 09/14/2007 01:47 PM 23,264 io_serial_haldiag.o 09/14/2007 01:47 PM 26,808 io_serial_serial.o 09/14/2007 01:47 PM 21,488 io_serial_tty.o haldiag is the package that includes the stripped down, polling mode only I/O. What's the trick to getting this package (really) included in the build? Thank you, Scott Moore -----Original Message----- From: ecos-discuss-owner@ecos.sourceware.org [mailto:ecos-discuss-owner@ecos.sourceware.org] On Behalf Of Scott Moore Sent: Thursday, September 13, 2007 2:12 PM To: Andrew Lunn Cc: Ecos-Discuss; Steve Gaskill Subject: RE: [ECOS] Question on serial ports Thank you. -----Original Message----- From: Andrew Lunn [mailto:andrew@lunn.ch] Sent: Thursday, September 13, 2007 2:04 PM To: Scott Moore Cc: Ecos-Discuss; Steve Gaskill Subject: Re: [ECOS] Question on serial ports > The questions are: > > 1. Does this indeed indicate that a full (not diagnostic) serial port > implementation was never completed for the MCB2100 board? > > 2. What was the purpose of the directory > ../packages/devs/serial/arm/lpc2xxx/..? Was this just a placeholder > for where a device might go? Take a look at the targets which use this: target p2106 { alias { "Olimex evaluation board LPC-P2106" p2106 } packages { CYGPKG_HAL_ARM CYGPKG_HAL_ARM_LPC2XXX CYGPKG_HAL_ARM_LPC2XXX_P2106 CYGPKG_IO_SERIAL_GENERIC_16X5X CYGPKG_IO_SERIAL_ARM_LPC2XXX CYGPKG_DEVICES_WATCHDOG_ARM_LPC2XXX } description " The p2106 target provides the packages needed to run eCos on the LPC-P2106 evaluation board from Olimex." } target lpcmt { alias { "Olimex evaluation board LPC-LPCMT" lpcmt } packages { CYGPKG_HAL_ARM CYGPKG_HAL_ARM_LPC2XXX CYGPKG_HAL_ARM_LPC2XXX_LPCMT CYGPKG_IO_SERIAL_GENERIC_16X5X CYGPKG_IO_SERIAL_ARM_LPC2XXX CYGPKG_DEVICES_WATCHDOG_ARM_LPC2XXX } description " The lpcmt target provides the packages needed to run eCos on the LPC-LPCMT evaluation board from Olimex." } Looking at this suggests that the LPC2XXX serial driver is just what is needed to make the generic 16x5x serial driver work on LPC targets. Take a closer look at one of the these targets and all should become clear... Andrew --- Incoming mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.762 / Virus Database: 510 - Release Date: 9/13/2004 --- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.762 / Virus Database: 510 - Release Date: 9/13/2004 -- Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss --- Incoming mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.762 / Virus Database: 510 - Release Date: 9/13/2004 --- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.762 / Virus Database: 510 - Release Date: 9/13/2004 -- Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [ECOS] Question on serial ports 2007-09-14 21:05 ` Scott Moore @ 2007-09-14 21:13 ` Andrew Lunn 2007-09-14 21:40 ` Scott Moore 0 siblings, 1 reply; 11+ messages in thread From: Andrew Lunn @ 2007-09-14 21:13 UTC (permalink / raw) To: Scott Moore; +Cc: Andrew Lunn, Ecos-Discuss, Steve Gaskill On Fri, Sep 14, 2007 at 05:04:17PM -0400, Scott Moore wrote: > Hi, sorry to post on this yet again, but I built both > the p2106 and lpcmt targets, and both appear to have the > same (forgive me) braindamaged I/O as the mcb2100 board > target. I tried: > > C:\projects\testbuild>ecosconfig add CYGPKG_IO_SERIAL_GENERIC_16X5X > Package `CYGPKG_IO_SERIAL_GENERIC_16X5X' is already loaded. > > And the configurator appears to believe that this is already selected. > However, after building, I don't see the ser_16x5x.o file anywhere > in the build. ser_16x5x.c is the file > ../ecos/packages/devs/serial/generic/16x5x/current/src/ser_16x5x which > contains the 16x5x general support. Instead it is including: > > 09/14/2007 01:47 PM 23,264 io_serial_haldiag.o > 09/14/2007 01:47 PM 26,808 io_serial_serial.o > 09/14/2007 01:47 PM 21,488 io_serial_tty.o > > haldiag is the package that includes the stripped down, polling > mode only I/O. > > What's the trick to getting this package (really) included in the > build? Do you have CYGPKG_IO_SERIAL_DEVICES enabled? That catches a lot of people out. Andrew -- Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss ^ permalink raw reply [flat|nested] 11+ messages in thread
* RE: [ECOS] Question on serial ports 2007-09-14 21:13 ` Andrew Lunn @ 2007-09-14 21:40 ` Scott Moore 0 siblings, 0 replies; 11+ messages in thread From: Scott Moore @ 2007-09-14 21:40 UTC (permalink / raw) To: Andrew Lunn; +Cc: Ecos-Discuss, Steve Gaskill That's got it, sorry I missed that. Thanks so much for the help. -----Original Message----- From: Andrew Lunn [mailto:andrew@lunn.ch] Sent: Friday, September 14, 2007 2:13 PM To: Scott Moore Cc: Andrew Lunn; Ecos-Discuss; Steve Gaskill Subject: Re: [ECOS] Question on serial ports On Fri, Sep 14, 2007 at 05:04:17PM -0400, Scott Moore wrote: > Hi, sorry to post on this yet again, but I built both the p2106 and > lpcmt targets, and both appear to have the same (forgive me) > braindamaged I/O as the mcb2100 board target. I tried: > > C:\projects\testbuild>ecosconfig add CYGPKG_IO_SERIAL_GENERIC_16X5X > Package `CYGPKG_IO_SERIAL_GENERIC_16X5X' is already loaded. > > And the configurator appears to believe that this is already selected. > However, after building, I don't see the ser_16x5x.o file anywhere in > the build. ser_16x5x.c is the file > ../ecos/packages/devs/serial/generic/16x5x/current/src/ser_16x5x which > contains the 16x5x general support. Instead it is including: > > 09/14/2007 01:47 PM 23,264 io_serial_haldiag.o > 09/14/2007 01:47 PM 26,808 io_serial_serial.o > 09/14/2007 01:47 PM 21,488 io_serial_tty.o > > haldiag is the package that includes the stripped down, polling mode > only I/O. > > What's the trick to getting this package (really) included in the > build? Do you have CYGPKG_IO_SERIAL_DEVICES enabled? That catches a lot of people out. Andrew --- Incoming mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.762 / Virus Database: 510 - Release Date: 9/13/2004 --- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.762 / Virus Database: 510 - Release Date: 9/13/2004 -- Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [ECOS] dOUG lEE'S MALLOC 2007-09-13 19:40 [ECOS] dOUG lEE'S MALLOC Rick Davis 2007-09-13 20:32 ` [ECOS] Question on serial ports Scott Moore @ 2007-09-13 20:59 ` Andrew Lunn 2007-09-27 0:21 ` [ECOS] Doug Lea's malloc Rick Davis 1 sibling, 1 reply; 11+ messages in thread From: Andrew Lunn @ 2007-09-13 20:59 UTC (permalink / raw) To: Rick Davis; +Cc: Ecos-Discuss On Thu, Sep 13, 2007 at 03:42:36PM -0400, Rick Davis wrote: > I am porting to a new Power-PC platform that has 256M of DDR on it. I am > using the latest snapshot (today as a matter of fact). If I call setvbuf > (stdout, NULL, _IONBF, 0), Doug's code complains throwing some sort of size > assertion. If I don't call setvbuf but call show_memory, that complains > about other issues. If I use the simple malloc routines instead, everything > works fine. Is there a memory size issue? Is something not being called in > the right order during initialization? Do you have a simple test case? I just tried running the synthetic target which a big heap. All the malloc tests pass. eg malloc4 produces: INFO:<Starting malloc4 test> INFO:<Iteration 0, arenasize=276507344, space free=276507324, maxfree=276507324> INFO:<Iteration 10, arenasize=276507344, space free=31489948, maxfree=29058556> INFO:<Iteration 20, arenasize=276507344, space free=108284148, maxfree=58859852> INFO:<Iteration 30, arenasize=276507344, space free=69580420, maxfree=65494596> INFO:<Iteration 40, arenasize=276507344, space free=1714036, maxfree=1714036> INFO:<Iteration 50, arenasize=276507344, space free=92251804, maxfree=38098124> INFO:<Iteration 60, arenasize=276507344, space free=111664980, maxfree=58928772> INFO:<Iteration 70, arenasize=276507344, space free=47689060, maxfree=36578764> INFO:<Iteration 80, arenasize=276507344, space free=77573924, maxfree=77573924> INFO:<Iteration 90, arenasize=276507344, space free=34070540, maxfree=23496868> INFO:<Iteration 100, arenasize=276507344, space free=29280524, maxfree=29280524> INFO:<Iteration 110, arenasize=276507344, space free=142085116, maxfree=100678860> INFO:<Iteration 120, arenasize=276507344, space free=92516524, maxfree=39697388> INFO:<Iteration 130, arenasize=276507344, space free=178518644, maxfree=110641924> INFO:<Iteration 140, arenasize=276507344, space free=95249636, maxfree=95249636> INFO:<Iteration 150, arenasize=276507344, space free=58732380, maxfree=31240340> INFO:<Iteration 160, arenasize=276507344, space free=154251700, maxfree=109160292> INFO:<Iteration 170, arenasize=276507344, space free=8964580, maxfree=5096676> INFO:<Iteration 180, arenasize=276507344, space free=129668932, maxfree=106951988> INFO:<Iteration 190, arenasize=276507344, space free=89131924, maxfree=89131924> INFO:<Iteration 200, arenasize=276507344, space free=198999364, maxfree=140538356> INFO:<Iteration 203, arenasize=276507344, space free=276507324, maxfree=276507324> PASS:<malloc4 test completed successfully> EXIT:<done> Here the heap is around 263Mbytes. What exactly are the assertion failures you are getting? Andrew -- Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss ^ permalink raw reply [flat|nested] 11+ messages in thread
* RE: [ECOS] Doug Lea's malloc 2007-09-13 20:59 ` [ECOS] dOUG lEE'S MALLOC Andrew Lunn @ 2007-09-27 0:21 ` Rick Davis 2007-09-27 7:38 ` Johan Cederbom 0 siblings, 1 reply; 11+ messages in thread From: Rick Davis @ 2007-09-27 0:21 UTC (permalink / raw) To: 'Andrew Lunn'; +Cc: 'Ecos-Discuss' Andrew, Sorry it took so long to get back. Here is the dump I get when calling setvbuf (stdout, NULL, _IONBUF, 0); ASSERT FAIL: <5>dlmalloc.cxx[815]void Cyg_Mempool_dlmalloc_Implementation::do_check_inuse_chunk() ((((mchunkptr)(((char*)(p))+((p)->size & ~0x1)))->size) & 0x1) ASSERT FAIL: dlmalloc.cxx [ 815] void Cyg_Mempool_dlmalloc_Implementation::do_check_inuse_chunk() ((((mchunkptr)(((char*)(p))+((p)->size & ~0x1)))->size) & 0x1) Rick -----Original Message----- From: Andrew Lunn [mailto:andrew@lunn.ch] Sent: Thursday, September 13, 2007 4:59 PM To: Rick Davis Cc: Ecos-Discuss Subject: Re: [ECOS] dOUG lEE'S MALLOC On Thu, Sep 13, 2007 at 03:42:36PM -0400, Rick Davis wrote: > I am porting to a new Power-PC platform that has 256M of DDR on it. I am > using the latest snapshot (today as a matter of fact). If I call setvbuf > (stdout, NULL, _IONBF, 0), Doug's code complains throwing some sort of size > assertion. If I don't call setvbuf but call show_memory, that complains > about other issues. If I use the simple malloc routines instead, everything > works fine. Is there a memory size issue? Is something not being called in > the right order during initialization? Do you have a simple test case? I just tried running the synthetic target which a big heap. All the malloc tests pass. eg malloc4 produces: INFO:<Starting malloc4 test> INFO:<Iteration 0, arenasize=276507344, space free=276507324, maxfree=276507324> INFO:<Iteration 10, arenasize=276507344, space free=31489948, maxfree=29058556> INFO:<Iteration 20, arenasize=276507344, space free=108284148, maxfree=58859852> INFO:<Iteration 30, arenasize=276507344, space free=69580420, maxfree=65494596> INFO:<Iteration 40, arenasize=276507344, space free=1714036, maxfree=1714036> INFO:<Iteration 50, arenasize=276507344, space free=92251804, maxfree=38098124> INFO:<Iteration 60, arenasize=276507344, space free=111664980, maxfree=58928772> INFO:<Iteration 70, arenasize=276507344, space free=47689060, maxfree=36578764> INFO:<Iteration 80, arenasize=276507344, space free=77573924, maxfree=77573924> INFO:<Iteration 90, arenasize=276507344, space free=34070540, maxfree=23496868> INFO:<Iteration 100, arenasize=276507344, space free=29280524, maxfree=29280524> INFO:<Iteration 110, arenasize=276507344, space free=142085116, maxfree=100678860> INFO:<Iteration 120, arenasize=276507344, space free=92516524, maxfree=39697388> INFO:<Iteration 130, arenasize=276507344, space free=178518644, maxfree=110641924> INFO:<Iteration 140, arenasize=276507344, space free=95249636, maxfree=95249636> INFO:<Iteration 150, arenasize=276507344, space free=58732380, maxfree=31240340> INFO:<Iteration 160, arenasize=276507344, space free=154251700, maxfree=109160292> INFO:<Iteration 170, arenasize=276507344, space free=8964580, maxfree=5096676> INFO:<Iteration 180, arenasize=276507344, space free=129668932, maxfree=106951988> INFO:<Iteration 190, arenasize=276507344, space free=89131924, maxfree=89131924> INFO:<Iteration 200, arenasize=276507344, space free=198999364, maxfree=140538356> INFO:<Iteration 203, arenasize=276507344, space free=276507324, maxfree=276507324> PASS:<malloc4 test completed successfully> EXIT:<done> Here the heap is around 263Mbytes. What exactly are the assertion failures you are getting? Andrew -- Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [ECOS] Doug Lea's malloc 2007-09-27 0:21 ` [ECOS] Doug Lea's malloc Rick Davis @ 2007-09-27 7:38 ` Johan Cederbom 2007-09-27 11:54 ` Rick Davis 0 siblings, 1 reply; 11+ messages in thread From: Johan Cederbom @ 2007-09-27 7:38 UTC (permalink / raw) To: Rick Davis; +Cc: 'Andrew Lunn', 'Ecos-Discuss' Hi Andrew, I've just spent a week with a similar problem (on another system). You get the assertion because someone has written over the memory allocation structures, and the ASSERT/DEBUG flag in "dynamic memory allocation" -> ".. implemetations" -> "Doug Lea's" is enabled. All allocated memory areas are separated by a simple "memchunk" structure. If a task wites more bytes than allocated, it will destroy theese "memchunk" structures. The assertion comes when trying to use the bad struct and that is always too late, the memory has already been trashed. The tricky part is to find out who did it ! /Johan Rick Davis wrote: > Andrew, > > Sorry it took so long to get back. > > Here is the dump I get when calling setvbuf (stdout, NULL, _IONBUF, 0); > > ASSERT FAIL: <5>dlmalloc.cxx[815]void > Cyg_Mempool_dlmalloc_Implementation::do_check_inuse_chunk() > ((((mchunkptr)(((char*)(p))+((p)->size & ~0x1)))->size) & 0x1) > ASSERT FAIL: dlmalloc.cxx [ 815] void > Cyg_Mempool_dlmalloc_Implementation::do_check_inuse_chunk() > ((((mchunkptr)(((char*)(p))+((p)->size & ~0x1)))->size) & 0x1) > > Rick > > > -----Original Message----- > From: Andrew Lunn [mailto:andrew@lunn.ch] > Sent: Thursday, September 13, 2007 4:59 PM > To: Rick Davis > Cc: Ecos-Discuss > Subject: Re: [ECOS] dOUG lEE'S MALLOC > > On Thu, Sep 13, 2007 at 03:42:36PM -0400, Rick Davis wrote: > >> I am porting to a new Power-PC platform that has 256M of DDR on it. I am >> using the latest snapshot (today as a matter of fact). If I call setvbuf >> (stdout, NULL, _IONBF, 0), Doug's code complains throwing some sort of >> > size > >> assertion. If I don't call setvbuf but call show_memory, that complains >> about other issues. If I use the simple malloc routines instead, >> > everything > >> works fine. Is there a memory size issue? Is something not being called in >> the right order during initialization? >> > > Do you have a simple test case? > > I just tried running the synthetic target which a big heap. All the > malloc tests pass. eg malloc4 produces: > > INFO:<Starting malloc4 test> > INFO:<Iteration 0, arenasize=276507344, space free=276507324, > maxfree=276507324> > INFO:<Iteration 10, arenasize=276507344, space free=31489948, > maxfree=29058556> > INFO:<Iteration 20, arenasize=276507344, space free=108284148, > maxfree=58859852> > INFO:<Iteration 30, arenasize=276507344, space free=69580420, > maxfree=65494596> > INFO:<Iteration 40, arenasize=276507344, space free=1714036, > maxfree=1714036> > INFO:<Iteration 50, arenasize=276507344, space free=92251804, > maxfree=38098124> > INFO:<Iteration 60, arenasize=276507344, space free=111664980, > maxfree=58928772> > INFO:<Iteration 70, arenasize=276507344, space free=47689060, > maxfree=36578764> > INFO:<Iteration 80, arenasize=276507344, space free=77573924, > maxfree=77573924> > INFO:<Iteration 90, arenasize=276507344, space free=34070540, > maxfree=23496868> > INFO:<Iteration 100, arenasize=276507344, space free=29280524, > maxfree=29280524> > INFO:<Iteration 110, arenasize=276507344, space free=142085116, > maxfree=100678860> > INFO:<Iteration 120, arenasize=276507344, space free=92516524, > maxfree=39697388> > INFO:<Iteration 130, arenasize=276507344, space free=178518644, > maxfree=110641924> > INFO:<Iteration 140, arenasize=276507344, space free=95249636, > maxfree=95249636> > INFO:<Iteration 150, arenasize=276507344, space free=58732380, > maxfree=31240340> > INFO:<Iteration 160, arenasize=276507344, space free=154251700, > maxfree=109160292> > INFO:<Iteration 170, arenasize=276507344, space free=8964580, > maxfree=5096676> > INFO:<Iteration 180, arenasize=276507344, space free=129668932, > maxfree=106951988> > INFO:<Iteration 190, arenasize=276507344, space free=89131924, > maxfree=89131924> > INFO:<Iteration 200, arenasize=276507344, space free=198999364, > maxfree=140538356> > INFO:<Iteration 203, arenasize=276507344, space free=276507324, > maxfree=276507324> > PASS:<malloc4 test completed successfully> > EXIT:<done> > > Here the heap is around 263Mbytes. > > What exactly are the assertion failures you are getting? > > Andrew > > > -- Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss ^ permalink raw reply [flat|nested] 11+ messages in thread
* RE: [ECOS] Doug Lea's malloc 2007-09-27 7:38 ` Johan Cederbom @ 2007-09-27 11:54 ` Rick Davis 0 siblings, 0 replies; 11+ messages in thread From: Rick Davis @ 2007-09-27 11:54 UTC (permalink / raw) To: 'Johan Cederbom'; +Cc: 'Andrew Lunn', 'Ecos-Discuss' Johan, I found it! Stupid logic error trying to align my buffer to the HAL_DCACHE_LINE_SIZE. I allocated enough but forgot to add (HAL_DCACHE_LINE_SIZE-1) before anding with ~(HAL_DCACHE_LINE_SIZE-1). Thanks for the response, Rick -----Original Message----- From: Johan Cederbom [mailto:jcederbom@logopak.se] Sent: Thursday, September 27, 2007 3:37 AM To: Rick Davis Cc: 'Andrew Lunn'; 'Ecos-Discuss' Subject: Re: [ECOS] Doug Lea's malloc Hi Andrew, I've just spent a week with a similar problem (on another system). You get the assertion because someone has written over the memory allocation structures, and the ASSERT/DEBUG flag in "dynamic memory allocation" -> ".. implemetations" -> "Doug Lea's" is enabled. All allocated memory areas are separated by a simple "memchunk" structure. If a task wites more bytes than allocated, it will destroy theese "memchunk" structures. The assertion comes when trying to use the bad struct and that is always too late, the memory has already been trashed. The tricky part is to find out who did it ! /Johan Rick Davis wrote: > Andrew, > > Sorry it took so long to get back. > > Here is the dump I get when calling setvbuf (stdout, NULL, _IONBUF, 0); > > ASSERT FAIL: <5>dlmalloc.cxx[815]void > Cyg_Mempool_dlmalloc_Implementation::do_check_inuse_chunk() > ((((mchunkptr)(((char*)(p))+((p)->size & ~0x1)))->size) & 0x1) > ASSERT FAIL: dlmalloc.cxx [ 815] void > Cyg_Mempool_dlmalloc_Implementation::do_check_inuse_chunk() > ((((mchunkptr)(((char*)(p))+((p)->size & ~0x1)))->size) & 0x1) > > Rick > > > -----Original Message----- > From: Andrew Lunn [mailto:andrew@lunn.ch] > Sent: Thursday, September 13, 2007 4:59 PM > To: Rick Davis > Cc: Ecos-Discuss > Subject: Re: [ECOS] dOUG lEE'S MALLOC > > On Thu, Sep 13, 2007 at 03:42:36PM -0400, Rick Davis wrote: > >> I am porting to a new Power-PC platform that has 256M of DDR on it. I am >> using the latest snapshot (today as a matter of fact). If I call setvbuf >> (stdout, NULL, _IONBF, 0), Doug's code complains throwing some sort of >> > size > >> assertion. If I don't call setvbuf but call show_memory, that complains >> about other issues. If I use the simple malloc routines instead, >> > everything > >> works fine. Is there a memory size issue? Is something not being called in >> the right order during initialization? >> > > Do you have a simple test case? > > I just tried running the synthetic target which a big heap. All the > malloc tests pass. eg malloc4 produces: > > INFO:<Starting malloc4 test> > INFO:<Iteration 0, arenasize=276507344, space free=276507324, > maxfree=276507324> > INFO:<Iteration 10, arenasize=276507344, space free=31489948, > maxfree=29058556> > INFO:<Iteration 20, arenasize=276507344, space free=108284148, > maxfree=58859852> > INFO:<Iteration 30, arenasize=276507344, space free=69580420, > maxfree=65494596> > INFO:<Iteration 40, arenasize=276507344, space free=1714036, > maxfree=1714036> > INFO:<Iteration 50, arenasize=276507344, space free=92251804, > maxfree=38098124> > INFO:<Iteration 60, arenasize=276507344, space free=111664980, > maxfree=58928772> > INFO:<Iteration 70, arenasize=276507344, space free=47689060, > maxfree=36578764> > INFO:<Iteration 80, arenasize=276507344, space free=77573924, > maxfree=77573924> > INFO:<Iteration 90, arenasize=276507344, space free=34070540, > maxfree=23496868> > INFO:<Iteration 100, arenasize=276507344, space free=29280524, > maxfree=29280524> > INFO:<Iteration 110, arenasize=276507344, space free=142085116, > maxfree=100678860> > INFO:<Iteration 120, arenasize=276507344, space free=92516524, > maxfree=39697388> > INFO:<Iteration 130, arenasize=276507344, space free=178518644, > maxfree=110641924> > INFO:<Iteration 140, arenasize=276507344, space free=95249636, > maxfree=95249636> > INFO:<Iteration 150, arenasize=276507344, space free=58732380, > maxfree=31240340> > INFO:<Iteration 160, arenasize=276507344, space free=154251700, > maxfree=109160292> > INFO:<Iteration 170, arenasize=276507344, space free=8964580, > maxfree=5096676> > INFO:<Iteration 180, arenasize=276507344, space free=129668932, > maxfree=106951988> > INFO:<Iteration 190, arenasize=276507344, space free=89131924, > maxfree=89131924> > INFO:<Iteration 200, arenasize=276507344, space free=198999364, > maxfree=140538356> > INFO:<Iteration 203, arenasize=276507344, space free=276507324, > maxfree=276507324> > PASS:<malloc4 test completed successfully> > EXIT:<done> > > Here the heap is around 263Mbytes. > > What exactly are the assertion failures you are getting? > > Andrew > > > -- Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss ^ permalink raw reply [flat|nested] 11+ messages in thread
end of thread, other threads:[~2007-09-27 11:54 UTC | newest] Thread overview: 11+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2007-09-13 19:40 [ECOS] dOUG lEE'S MALLOC Rick Davis 2007-09-13 20:32 ` [ECOS] Question on serial ports Scott Moore 2007-09-13 21:03 ` Andrew Lunn 2007-09-13 21:12 ` Scott Moore 2007-09-14 21:05 ` Scott Moore 2007-09-14 21:13 ` Andrew Lunn 2007-09-14 21:40 ` Scott Moore 2007-09-13 20:59 ` [ECOS] dOUG lEE'S MALLOC Andrew Lunn 2007-09-27 0:21 ` [ECOS] Doug Lea's malloc Rick Davis 2007-09-27 7:38 ` Johan Cederbom 2007-09-27 11:54 ` Rick Davis
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 read-only IMAP folder(s) and NNTP newsgroup(s).