Re: [PATCH rtems-libbsd] waf_libbsd: Account for library check results

hi Kinsey, This change looks OK to me. Nice work. Thanks Chris On 6/10/21 7:55 am, Kinsey Moore wrote: > Conditionally compiled tests (consisting only of debugger01) were not > compiling as expected when libdebugger was present. This appears to have > occurred during the transition from header d

[PATCH rtems-libbsd] waf_libbsd: Account for library check results

Conditionally compiled tests (consisting only of debugger01) were not compiling as expected when libdebugger was present. This appears to have occurred during the transition from header detection or due to an intervening change in the waf internal libraries. The result of check_cc() is the only loc

RE: Help with RTEMS Tester Results for uC5282

ms.org Subject: Re: Help with RTEMS Tester Results for uC5282 On Tue, Jul 20, 2021, 12:22 AM Sebastian Huber mailto:sebastian.hu...@embedded-brains.de> > wrote: Hello, On 20/07/2021 00:43, gerberh...@gmail.com <mailto:gerberh...@gmail.com> wrote: > Dr. Bloom mentioned that some o

Re: Help with RTEMS Tester Results for uC5282

On Tue, Jul 20, 2021, 12:22 AM Sebastian Huber < sebastian.hu...@embedded-brains.de> wrote: > Hello, > > On 20/07/2021 00:43, gerberh...@gmail.com wrote: > > Dr. Bloom mentioned that some of these results could likely be due to > > flawed TLS implementation of m68k

Re: Help with RTEMS Tester Results for uC5282

Hello, On 20/07/2021 00:43, gerberh...@gmail.com wrote: Dr. Bloom mentioned that some of these results could likely be due to flawed TLS implementation of m68k. this could be also an issue with the linker command file. If I can run the test myself on Qemu I could try to debug the sptls02

Re: Help with RTEMS Tester Results for uC5282

On Mon, Jul 19, 2021, 5:43 PM wrote: > Hello all, > > > > I’ve been working on getting support into Qemu for the uC5282 board > recently, and today got the rtems-test tool running with this Qemu > emulation for that board. The results with the first run of the full t

Help with RTEMS Tester Results for uC5282

Hello all, I've been working on getting support into Qemu for the uC5282 board recently, and today got the rtems-test tool running with this Qemu emulation for that board. The results with the first run of the full test suite since the emulation has been operational appears very prom

Re: BSP Builder Results :(

On 26/2/21 8:33 am, junkes wrote: > With RTEMS6, frozen CPU even with the ubuntu mkimage: Thanks Heinz. We need to isolate and resolve this issue before removing autoconf. I do not think the powerpc bsps build with autotools at the moment so it is hard to say if there is an issue in the BSP or in

Re: BSP Builder Results :(

at 0x2000 Loading Kernel Image ... OK OK Loading Device Tree to 03ff9000, end 03fff04a ... OK -> no more output ... frozen target On 2021-02-25 14:45, Joel Sherrill wrote: Hi Just passing along that the need to switch the BSP builder to waf is becoming more obvious i

Re: BSP Builder Results :(

o 03ff9000, end 03fff04a ... OK -> no more output ... frozen target On 2021-02-25 14:45, Joel Sherrill wrote: Hi Just passing along that the need to switch the BSP builder to waf is becoming more obvious in the BSP Builder results

Re: BSP Builder Results :(

d Address: 4000 > Entry Point: 4000 > Verifying Checksum ... OK > ## Flattened Device Tree blob at 2000 > Booting using the fdt blob at 0x2000 > Loading Kernel Image ... OK > OK > Loading Device Tree to 03ff9000, end 03fff04a ... OK > > -> no m

Re: BSP Builder Results :(

i Just passing along that the need to switch the BSP builder to waf is becoming more obvious in the BSP Builder results https://lists.rtems.org/pipermail/build/2021-February/026054.html 467 of 1615 configurations now fail to build. -joel ___ devel

BSP Builder Results :(

Hi Just passing along that the need to switch the BSP builder to waf is becoming more obvious in the BSP Builder results https://lists.rtems.org/pipermail/build/2021-February/026054.html 467 of 1615 configurations now fail to build. -joel ___ devel

Re: [PATCH 00/10] Add build and target hash for test results

24, 2021 at 6:57 AM Sebastian Huber > >>>wrote: > >>>> This patch set adds the new directives rtems_get_build_hash() and > >>>> rtems_get_target_hash() which can be used to differentiate test suite > >>>> results. See also the following discuss

Re: [PATCH 00/10] Add build and target hash for test results

() which can be used to differentiate test suite results. See also the following discussion: https://lists.rtems.org/pipermail/devel/2020-November/063226.html Sebastian Huber (10): build: Generate build hash rtems: Add rtems_get_build_hash() libtest: Report build hash score: Add

Re: [PATCH 00/10] Add build and target hash for test results

_get_target_hash() which can be used to differentiate test suite > >> results. See also the following discussion: > >> > >> https://lists.rtems.org/pipermail/devel/2020-November/063226.html > >> > >> Sebastian Huber (10): > >>build: Generate build ha

Re: [PATCH 00/10] Add build and target hash for test results

On 24/02/2021 19:22, Gedare Bloom wrote: On Wed, Feb 24, 2021 at 6:57 AM Sebastian Huber wrote: This patch set adds the new directives rtems_get_build_hash() and rtems_get_target_hash() which can be used to differentiate test suite results. See also the following discussion: https

Re: [PATCH 00/10] Add build and target hash for test results

On Wed, Feb 24, 2021 at 11:22 AM Gedare Bloom wrote: > > On Wed, Feb 24, 2021 at 6:57 AM Sebastian Huber > wrote: > > > > This patch set adds the new directives rtems_get_build_hash() and > > rtems_get_target_hash() which can be used to differentiate test suite

Re: [PATCH 00/10] Add build and target hash for test results

On Wed, Feb 24, 2021 at 6:57 AM Sebastian Huber wrote: > > This patch set adds the new directives rtems_get_build_hash() and > rtems_get_target_hash() which can be used to differentiate test suite > results. See also the following discussion: > > https://lists.rtems.org/pi

[PATCH 00/10] Add build and target hash for test results

This patch set adds the new directives rtems_get_build_hash() and rtems_get_target_hash() which can be used to differentiate test suite results. See also the following discussion: https://lists.rtems.org/pipermail/devel/2020-November/063226.html Sebastian Huber (10): build: Generate build

Recent rtems-bsp-builder results

Hi Has anyone run this lately? I got all failures on my sweep over the weekend. That doesn't match my results by hand where I built and ran tests on some. --joel ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel

Re: BSP Test Results

On 9/9/20 6:49 pm, Sebastian Huber wrote: > On 09/09/2020 02:29, Chris Johns wrote: >>> This would be enough to address my "HW or which simulator" question. >> I had created #4072, please update adding the items you would like. We can >> add >> anything you like and they can be mandated. There alr

Re: BSP Test Results

On 9/9/20 6:47 pm, Sebastian Huber wrote: > On 09/09/2020 02:36, Chris Johns wrote: >> On 9/9/20 3:13 am, Gedare Bloom wrote: >>> On Sun, Sep 6, 2020 at 8:55 PM Chris Johns  wrote: >>>> An example using Joel's recent test run (thanks Joel :)). The sparc/leo

Re: BSP Test Results

On 09/09/2020 02:29, Chris Johns wrote: [...] > >> > Also I am not sure but hopefully the test reports do accurately reflect >> host OS. >> >> There is a "Host" section at the top of the results log? It is just >> `uname -a`. >

Re: BSP Test Results

On 09/09/2020 02:29, Chris Johns wrote: This would be enough to address my "HW or which simulator" question. I had created #4072, please update adding the items you would like. We can add anything you like and they can be mandated. There already exist a number of fields for various transports so

Re: BSP Test Results

On 09/09/2020 02:36, Chris Johns wrote: On 9/9/20 3:13 am, Gedare Bloom wrote: On Sun, Sep 6, 2020 at 8:55 PM Chris Johns wrote: An example using Joel's recent test run (thanks Joel :)). The sparc/leon2 results show no regressions: Summary === Passed:580 Failed: 0

Re: BSP Test Results

Hello Chris, On 07/09/2020 04:55, Chris Johns wrote: Hello, I would like to discuss BSP Test results early in the release cycle in the hope we avoid the last minute issues we encountered with RTEMS 5 and the "expected" failure state ticket. I would like to update this section

Re: BSP Test Results

On 9/9/20 3:13 am, Gedare Bloom wrote: > On Sun, Sep 6, 2020 at 8:55 PM Chris Johns wrote: >> An example using Joel's recent test run (thanks Joel :)). The sparc/leon2 >> results show no regressions: >> >> Summary >> === >> >> Passed:

Re: BSP Test Results

;mailto:chr...@rtems.org <mailto:chr...@rtems.org>>> wrote: > > > >     Hello, > > > >     I would like to discuss BSP Test results early in the release cycle > in > the hope > >     we avoid the last minute issues w

Re: BSP Test Results

On Mon, Sep 7, 2020 at 12:44 AM Chris Johns wrote: > On 7/9/20 2:16 pm, Joel Sherrill wrote: > > > > > > On Sun, Sep 6, 2020, 9:55 PM Chris Johns > <mailto:chr...@rtems.org>> wrote: > > > > Hello, > > > > I would like to discuss

Re: BSP Test Results

On Sun, Sep 6, 2020 at 8:55 PM Chris Johns wrote: > > Hello, > > I would like to discuss BSP Test results early in the release cycle in the > hope > we avoid the last minute issues we encountered with RTEMS 5 and the "expected" > failure state ticket. > >

Re: BSP Test Results

On 7/9/20 2:16 pm, Joel Sherrill wrote: > > > On Sun, Sep 6, 2020, 9:55 PM Chris Johns <mailto:chr...@rtems.org>> wrote: > > Hello, > > I would like to discuss BSP Test results early in the release cycle in > the hope > we avoid the last minut

Re: BSP Test Results

On Sun, Sep 6, 2020, 9:55 PM Chris Johns wrote: > Hello, > > I would like to discuss BSP Test results early in the release cycle in the > hope > we avoid the last minute issues we encountered with RTEMS 5 and the > "expected" > failure state ticket. > >

BSP Test Results

Hello, I would like to discuss BSP Test results early in the release cycle in the hope we avoid the last minute issues we encountered with RTEMS 5 and the "expected" failure state ticket. I would like to update this section ... https://docs.rtems.org/branches/master/user/testing/

Re: RISC-V BSP Test Results

On 2020-03-27 18:49, Joel Sherrill wrote: I wanted to pass along that Spike appears to be working now from the RSB. Test results are in the build archive show that 5 or 7 fail on sis but the other BSPs tend to have 20-24 failures with some timeouts and invalids. No idea why. It would be

RISC-V BSP Test Results

Hi I wanted to pass along that Spike appears to be working now from the RSB. Test results are in the build archive show that 5 or 7 fail on sis but the other BSPs tend to have 20-24 failures with some timeouts and invalids. No idea why. It would be appreciated if anyone who knows the RISC-V could

Re: Where are results of rtems-tester test results archived?

l implementation listed the failing tests by name but this added little > value and you could not track the state of the run so it was removed. > > > it is exactly this summary (the end result) that helps. > > Great, this is the important bit. > > > If we had regular t

Re: Where are results of rtems-tester test results archived?

not track the state of the run so it was removed. > it is exactly this summary (the end result) that helps. Great, this is the important bit. > If we had regular testing, > parsing the results and producing a status matrix could help for understanding > the tiers. I'm not sa

Re: Where are results of rtems-tester test results archived?

>>> On Sat, Sep 21, 2019, 9:55 AM Peter Dufault wrote: > >>>> I’ve searched but can’t find anywhere. I’d like to see the results > of the tests on all architectures to compare to what I see on > PowerPC-beatnik. > >>>> There is a build@ mailing list and t

Re: Where are results of rtems-tester test results archived?

; I’ve searched but can’t find anywhere. I’d like to see the results of the >>>> tests on all architectures to compare to what I see on PowerPC-beatnik. >>>> There is a build@ mailing list and the archives are at >>>> https://lists.rtems.org/pipermail/build/ &

Re: Where are results of rtems-tester test results archived?

ote: >> > I’ve searched but can’t find anywhere. I’d like to see the results of the >> > tests on all architectures to compare to what I see on PowerPC-beatnik. >> > >> > There is a build@ mailing list and the archives are at >> > https://lists.rtems

Re: Where are results of rtems-tester test results archived?

>> > >>> On 22/9/19 1:18 am, dufa...@hda.com wrote: > >>>>> On Sep 21, 2019, at 11:03 , Joel Sherrill wrote: > >>>>> On Sat, Sep 21, 2019, 9:55 AM Peter Dufault wrote: > >>>>> I’ve searched but can’t find anywhere. I’d like t

Re: Where are results of rtems-tester test results archived?

19, at 11:03 , Joel Sherrill wrote: >>>>> On Sat, Sep 21, 2019, 9:55 AM Peter Dufault wrote: >>>>> I’ve searched but can’t find anywhere. I’d like to see the results of >>>>> the tests on all architectures to compare to what I see on >>>>>

Re: Where are results of rtems-tester test results archived?

eter Dufault wrote: >>>> I’ve searched but can’t find anywhere. I’d like to see the results of the >>>> tests on all architectures to compare to what I see on PowerPC-beatnik. >>>> >>>> There is a build@ mailing list and the archives are at >

Re: Where are results of rtems-tester test results archived?

> On Sep 21, 2019, at 16:41 , Chris Johns wrote: > > On 22/9/19 1:18 am, dufa...@hda.com wrote: >>> On Sep 21, 2019, at 11:03 , Joel Sherrill wrote: >>> On Sat, Sep 21, 2019, 9:55 AM Peter Dufault wrote: >>> I’ve searched but can’t find anywhere.

Re: Where are results of rtems-tester test results archived?

On 22/9/19 1:18 am, dufa...@hda.com wrote: >> On Sep 21, 2019, at 11:03 , Joel Sherrill wrote: >> On Sat, Sep 21, 2019, 9:55 AM Peter Dufault wrote: >> I’ve searched but can’t find anywhere. I’d like to see the results of the >> tests on all architectures to compare

Re: Where are results of rtems-tester test results archived?

On Sat, Sep 21, 2019, 10:18 AM wrote: > > > On Sep 21, 2019, at 11:03 , Joel Sherrill wrote: > > > > > > > > On Sat, Sep 21, 2019, 9:55 AM Peter Dufault wrote: > > I’ve searched but can’t find anywhere. I’d like to see the results of > the tests on

Re: Where are results of rtems-tester test results archived?

> On Sep 21, 2019, at 11:03 , Joel Sherrill wrote: > > > > On Sat, Sep 21, 2019, 9:55 AM Peter Dufault wrote: > I’ve searched but can’t find anywhere. I’d like to see the results of the > tests on all architectures to compare to what I see on PowerPC-beatnik. > >

Re: Where are results of rtems-tester test results archived?

On Sat, Sep 21, 2019, 9:55 AM Peter Dufault wrote: > I’ve searched but can’t find anywhere. I’d like to see the results of the > tests on all architectures to compare to what I see on PowerPC-beatnik. > There is a build@ mailing list and the archives are at https://lists.rtems.org/

Where are results of rtems-tester test results archived?

I’ve searched but can’t find anywhere. I’d like to see the results of the tests on all architectures to compare to what I see on PowerPC-beatnik. Peter - Peter Dufault HD Associates, Inc. Software and System Engineering This email is delivered through the public internet

Re: RISC-V Test Results

On 9/8/19 9:47 pm, Sebastian Huber wrote: > On 08/08/2019 15:33, Joel Sherrill wrote: >> Hi >> >> If you are subscribed to the build@ mailing list, then you saw the flurry of >> test >> results from over night. I built every variant and ran the test suite with &g

Re: RISC-V Test Results

On 8/8/19 3:33 PM, Joel Sherrill wrote: > Hi > > If you are subscribed to the build@ mailing list, then you saw the > flurry of test > results from over night. I built every variant and ran the test suite > with RTEMS  > debug on and off.  Here are some observations: > &g

Re: RISC-V Test Results

On 08/08/2019 15:33, Joel Sherrill wrote: Hi If you are subscribed to the build@ mailing list, then you saw the flurry of test results from over night. I built every variant and ran the test suite with RTEMS debug on and off.  Here are some observations: + rv64imafd only has one test pass

Re: RISC-V Test Results

On Fri, Aug 9, 2019, 5:39 AM Hesham Almatary wrote: > Hi Joel, > > > On Thu, 8 Aug 2019 at 14:34, Joel Sherrill wrote: > > > > Hi > > > > If you are subscribed to the build@ mailing list, then you saw the > flurry of test > > results from over night.

Re: RISC-V Test Results

Hi Joel, On Thu, 8 Aug 2019 at 14:34, Joel Sherrill wrote: > > Hi > > If you are subscribed to the build@ mailing list, then you saw the flurry of > test > results from over night. I built every variant and ran the test suite with > RTEMS > debug on and off. He

RISC-V Test Results

Hi If you are subscribed to the build@ mailing list, then you saw the flurry of test results from over night. I built every variant and ran the test suite with RTEMS debug on and off. Here are some observations: + rv64imafd only has one test pass + rv64_iamd_medany only has one test pass

Re: New Coverity Scan Results

Hello Joel, could you please do a new scan since I committed a couple of FTP server patches which should address some Coverity issues. -- Sebastian Huber, embedded brains GmbH Address : Dornierstr. 4, D-82178 Puchheim, Germany Phone : +49 89 189 47 41-16 Fax : +49 89 189 47 41-09 E-Mail

New Coverity Scan Results

Hi I submitted a build this morning and 6 were noted as resolved. https://scan.coverity.com/projects/rtems Still multiple outstanding. --joel ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel

Re: New Coverity Scan Results for RTEMS Available

On 27/09/2018 17:59, Gedare Bloom wrote: On Thu, Sep 27, 2018 at 3:00 AM, Sebastian Huber wrote: On 26/09/2018 15:42, Joel Sherrill wrote: On Wed, Sep 26, 2018 at 7:04 AM Sebastian Huber mailto:sebastian.hu...@embedded-brains.de>> wrote: On 26/09/2018 14:02, Sebastian Huber wrote:

Re: New Coverity Scan Results for RTEMS Available

On Thu, Sep 27, 2018 at 3:00 AM, Sebastian Huber wrote: > > > On 26/09/2018 15:42, Joel Sherrill wrote: >> >> >> >> On Wed, Sep 26, 2018 at 7:04 AM Sebastian Huber >> > > wrote: >> >> On 26/09/2018 14:02, Sebastian Huber wrote: >> > void rtems_tas

Re: New Coverity Scan Results for RTEMS Available

On 26/09/2018 15:42, Joel Sherrill wrote: On Wed, Sep 26, 2018 at 7:04 AM Sebastian Huber > wrote: On 26/09/2018 14:02, Sebastian Huber wrote: > void rtems_task_delete_self() RTEMS_NORETURN; Alternative would be void rtems_task_e

Re: New Coverity Scan Results for RTEMS Available

I agree. It is a semantic issue. 2018-09-26 20:04 GMT+08:00 Sebastian Huber < sebastian.hu...@embedded-brains.de>: > On 26/09/2018 14:02, Sebastian Huber wrote: > >> void rtems_task_delete_self() RTEMS_NORETURN; >> > > Alternative would be > > void rtems_task_exit(void) RTEMS_NORETURN; > > > -- >

Re: New Coverity Scan Results for RTEMS Available

On Wed, Sep 26, 2018 at 7:04 AM Sebastian Huber < sebastian.hu...@embedded-brains.de> wrote: > On 26/09/2018 14:02, Sebastian Huber wrote: > > void rtems_task_delete_self() RTEMS_NORETURN; > > Alternative would be > > void rtems_task_exit(void) RTEMS_NORETURN; > I don't want to change APIs to mak

Re: New Coverity Scan Results for RTEMS Available

On 26/09/2018 14:02, Sebastian Huber wrote: void rtems_task_delete_self() RTEMS_NORETURN; Alternative would be void rtems_task_exit(void) RTEMS_NORETURN; -- Sebastian Huber, embedded brains GmbH Address : Dornierstr. 4, D-82178 Puchheim, Germany Phone : +49 89 189 47 41-16 Fax : +49 89

Re: New Coverity Scan Results for RTEMS Available

How can we teach Coverity that rtems_task_delete(RTEMS_SELF); is a function call which doesn't return? Maybe we should add a void rtems_task_delete_self() RTEMS_NORETURN; this would also help the compiler. -- Sebastian Huber, embedded brains GmbH Address : Dornierstr. 4, D-82178 Puchheim, G

Re: GR740-SMP BSP test results (gcc-7.2)

> On 26 Sep 2018, at 6:44 pm, Sebastian Huber > wrote: > > Hello Daniel, > >> On 20/09/2018 08:59, Daniel Hellstrom wrote: >>> On 2018-09-20 07:32, Sebastian Huber wrote: >>> Hello Daniel, >>> >>> thanks for your status report. The RSB uses currently GCC 7.3.0 without >>> patches and the Newl

Re: GR740-SMP BSP test results (gcc-7.2)

Hello Daniel, On 20/09/2018 08:59, Daniel Hellstrom wrote: On 2018-09-20 07:32, Sebastian Huber wrote: Hello Daniel, thanks for your status report. The RSB uses currently GCC 7.3.0 without patches and the Newlib commit d13c84eb07e35984bf7a974cd786a6cdac29e6b9. Thanks for the information, our

Re: GR740-SMP BSP test results (gcc-7.2)

st failures (686 >>> tests produced the begin/end of test message). >> Nice. >> >> Could the rtems-test results please be posted to bui...@rtems.org so the >> BSP’s >> tier 1 can be recorded? > > I didn't run the tests with rtems-test, but I work on

Re: GR740-SMP BSP test results (gcc-7.2)

On 21/09/2018 10:57, Chris Johns wrote: On 21 Sep 2018, at 5:23 pm, Sebastian Huber wrote: I did a test run on a N2X of RTEMS version 4221d932b43094f3aaf4a8dca1aa6bd4db13df4e. There are no test failures (686 tests produced the begin/end of test message). Nice. Could the rtems-test results

Re: GR740-SMP BSP test results (gcc-7.2)

> On 21 Sep 2018, at 5:23 pm, Sebastian Huber > wrote: > I did a test run on a N2X of RTEMS version > 4221d932b43094f3aaf4a8dca1aa6bd4db13df4e. There are no test failures (686 > tests produced the begin/end of test message). Nice. Could the rtems-test results please b

Re: GR740-SMP BSP test results (gcc-7.2)

On 20/09/2018 08:59, Daniel Hellstrom wrote: Hello Sebastian, On 2018-09-20 07:32, Sebastian Huber wrote: Hello Daniel, thanks for your status report. The RSB uses currently GCC 7.3.0 without patches and the Newlib commit d13c84eb07e35984bf7a974cd786a6cdac29e6b9. Thanks for the information,

Re: GR740-SMP BSP test results (gcc-7.2)

test have been run both on TSIM and hardware. Current test results for the RTEMS test-suite with GCC-7.2 toolchain for the GR740 quad-core LEON4 BSP in SMP driver manager configuration:   ###   # RTEMS TESTSUITE FAILURE SUMMARY   #   # Result

Re: GR740-SMP BSP test results (gcc-7.2)

the todays master with some additional test fixes which I plan to submit shortly. The test have been run both on TSIM and hardware. Current test results for the RTEMS test-suite with GCC-7.2 toolchain for the GR740 quad-core LEON4 BSP in SMP driver manager configuration

GR740-SMP BSP test results (gcc-7.2)

Hi, I just wanted to share the current test status for the GR740 I have today, using the todays master with some additional test fixes which I plan to submit shortly. The test have been run both on TSIM and hardware. Current test results for the RTEMS test-suite with GCC-7.2 toolchain for

Re: New Coverity Scan Results for RTEMS Available

On Wed, Sep 12, 2018 at 10:38 AM 李MY wrote: > Hi Joel, > > I have experiences on verifying reports produced by static analysis tools. > I would like to help this. > Awesome! Please request access. Looking at the current issues, I think a fair number are in code we merged from upstream projects

Re: New Coverity Scan Results for RTEMS Available

Hi Joel, I have experiences on verifying reports produced by static analysis tools. I would like to help this. Mingyu Li 2018-09-12 23:08 GMT+08:00 Joel Sherrill : > Hi > > It would be very helpful to have folks look at the outstanding > issues and help resolve them. > > https://scan.coverity.c

New Coverity Scan Results for RTEMS Available

Hi It would be very helpful to have folks look at the outstanding issues and help resolve them. https://scan.coverity.com/projects/rtems Thanks. --joel ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel

Gsoc Results announced

Hello mentors Thanks a lot for providing me this awesome opportunity to work with rtems. I will try to do my best for the project Thanks Salil ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel

[PATCH 4.10] Back port changes to post builds results to mailing lists.

This change lets the 4.10 branch post build results to bu...@rtems.org. ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel

Re: Couverture-Qemu Testing Results

On 12/06/2017 04:53, Joel Sherrill wrote: > > File individual tickets on the bsps with unique failures on qemu. And one to > cover the "no exit" case. I know Chris has been hesitant to look at test > output > and kill tests but I think it is necessary unless you can find a way to make > qemu auto

Re: Couverture-Qemu Testing Results

output and kill tests but I think it is necessary unless you can find a way to make qemu automatically exit from the BSP. Anyway, you have two BSPs which work well enough to continue on with the framework. Think of it as a skyscraper with only some floors ready for occupancy. We need the building

Re: Couverture-Qemu Testing Results

. BIOS execution exception nip=0x0580 msr=0x2000 dar=0x dsisr=0x Stopping execution qemu: terminating on signal 2 > But if it turns out that not exiting is the issue, that's a separate problem > and you should file a ticket a few move along. Ok, so I should t

Re: Couverture-Qemu Testing Results

On Jun 11, 2017 4:13 AM, "Cillian O'Donnell" wrote: > Does pc386 look similar? I haven't been able to get a decent set of results for PC386. For RSB-Qemu all the tests time out. Using command qemu-system-i386 -m 128 -boot b -hda path_to/rtems-boot.img -no-reboot -mon

Re: Couverture-Qemu Testing Results

> Does pc386 look similar? I haven't been able to get a decent set of results for PC386. For RSB-Qemu all the tests time out. Using command qemu-system-i386 -m 128 -boot b -hda path_to/rtems-boot.img -no-reboot -monitor null -serial stdio -nographic -append "--cons

Re: Couverture-Qemu Testing Results

almost time to look at switching the rsb On Jun 10, 2017 1:25 PM, "Cillian O'Donnell" wrote: Hi, I'm testing Couverture-Qemu against the RSB-Qemu to check if it is working correctly. So far I have good results for ARM bsps xilinx_zynq_a9_qemu and realview_pbx_a9_qemu and Sp

Couverture-Qemu Testing Results

Hi, I'm testing Couverture-Qemu against the RSB-Qemu to check if it is working correctly. So far I have good results for ARM bsps xilinx_zynq_a9_qemu and realview_pbx_a9_qemu and Sparc Leon3. They show identical results for the samples and almost identical results for the full testsuite.

Re: RTEMS 4.12 gcc-7.1.0/binutils-2.28 test results

werpc-7.1 \ --arch=powerpc --build=standard --jobs=7/6 Results summary: Total: Warnings:2410 exes:582 objs:74236 libs:3500 Failures: 1 standard powerpc/mcp750 build: configure: /opt/work/chris/rtems/kernel/rtems.git/configure --target\ =powerpc-rtems4.12 --enable-rtemsbsp=m

Re: RTEMS 4.12 gcc-7.1.0/binutils-2.28 test results

On 01/06/2017 07:33, Sebastian Huber wrote: - Chris Johns schrieb: On 31/5/17 5:00 pm, Joel Sherrill wrote> On Wednesday, May 31, 2017, Chris Johns > wrote: I am happy to push the patches to update to gcc-7.1.0 and binutils-2.28 and keep SH on the curr

Re: RTEMS 4.12 gcc-7.1.0/binutils-2.28 test results

- Chris Johns schrieb: > On 31/5/17 5:00 pm, Joel Sherrill wrote> On Wednesday, May 31, 2017, Chris > Johns > > > wrote: > > > > I am happy to push the patches to update to gcc-7.1.0 and binutils-2.28 > > and keep > > SH on the current tools and the PowerP

Re: RTEMS 4.12 gcc-7.1.0/binutils-2.28 test results

On 31/5/17 5:00 pm, Joel Sherrill wrote> On Wednesday, May 31, 2017, Chris Johns > wrote: > > I am happy to push the patches to update to gcc-7.1.0 and binutils-2.28 > and keep > SH on the current tools and the PowerPC on binutils-2.27. > > > This sounds reason

Re: RTEMS 4.12 gcc-7.1.0/binutils-2.28 test results

On Wednesday, May 31, 2017, Chris Johns wrote: > Hi, > > I am testing RSB patches to move 4.12 to gcc 7.1.0/binutils-2.28. > > The SH arch fails to build on FreeBSD 11.0. The issue is > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80923. > > RTEMS BSP Builder results summ

RTEMS 4.12 gcc-7.1.0/binutils-2.28 test results

Hi, I am testing RSB patches to move 4.12 to gcc 7.1.0/binutils-2.28. The SH arch fails to build on FreeBSD 11.0. The issue is https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80923. RTEMS BSP Builder results summary for: $ rtems-bsp-builder --rtems-tools=/build/rtems/tools/4.12-7.1 --rtems=/opt

Re: 4.11.2rc1 Build Results

On 03/04/2017 23:10, Joel Sherrill wrote: Hi Looks good except for the architectures that toolsets did not build for. + avr (don't care) + lm32 + moxie + m32c moxie has the binutils mismatch ticket but after that is fixed, there is a missing gcc support library to track down why it isn't built

4.11.2rc1 Build Results

Hi Looks good except for the architectures that toolsets did not build for. + avr (don't care) + lm32 + moxie + m32c moxie has the binutils mismatch ticket but after that is fixed, there is a missing gcc support library to track down why it isn't built. lm32 can build the toolset but since rtem

Re: Results

I will try to model this test case environment soon and get back to you. @gedare - you are absolutely correct about the description of project On Friday, June 26, 2015, Gedare Bloom wrote: > On Fri, Jun 26, 2015 at 9:42 AM, Sebastian Huber > > wrote: > > On 26/06/15 15:28, Gedare Bloom wrote: >

Re: Results

On Fri, Jun 26, 2015 at 9:42 AM, Sebastian Huber wrote: > On 26/06/15 15:28, Gedare Bloom wrote: >> >> Since this thread got migrated to devel a bit prematurely, I'll >> back-stop some of the details and how I understand the state of this >> project. >> >> Saurabh is working toward solving https:/

Re: Results

On 26/06/15 15:28, Gedare Bloom wrote: Since this thread got migrated to devel a bit prematurely, I'll back-stop some of the details and how I understand the state of this project. Saurabh is working toward solving https://devel.rtems.org/ticket/2124 (so yes there is a ticket already, and it sh

Re: Results

Since this thread got migrated to devel a bit prematurely, I'll back-stop some of the details and how I understand the state of this project. Saurabh is working toward solving https://devel.rtems.org/ticket/2124 (so yes there is a ticket already, and it should be referenced by patches accordingly

Re: Results

On 26/06/15 02:33, Saurabh Gadia wrote: @joel: It essentially means finding out the highest priority thread (or ceiling) of any remaining mutex held, right? If you are talking this in context of nested mutex problem ---> We never go and find the highest priority thread waiting on held mutex.

Re: Results

rsely highest priority thread will recursively make changes to top >>>> >of stack of held mutexes by the holder. We don't search. >>>> >>>> True recursion? Or implemented with loop? >>>> >>>> Ok. Still an O(n) operation. Discus

  1   2   >