#3170: Microzed libtest/block08 fails to print end of test correctly.
------------------------------+--------------------------
Reporter: Chris Johns | Owner: Chris Johns
Type: defect | Status: assigned
Priority: high | Milestone: 4.12.0
Component: unspecified | Version: 4.12
Severity: critical | Resolution:
Keywords: zedboard testing |
------------------------------+--------------------------
Comment (by Chris Johns):
Replying to [comment:10 Sebastian Huber]:
> Replying to [comment:9 Chris Johns]:
> > Replying to [comment:8 Sebastian Huber]:
> > > Replying to [comment:7 Chris Johns]:
> > > > I have always assumed the default configuration for '''any''' BSP
lets the tests run. Is this not the case?
> > > No, this is not the case for the real hardware BSPs which usually
use an interrupt driven console driver.
> >
> > This seems like a new requirement. Has something changed in RTEMS to
cause this? I do not remember having this problem with previous versions.
>
> At least since I use RTEMS, this was the case. I asked questions about
this on the mailing list.
The beaglebone black does not have the same problems as the Zynq. I
checked the drivers for the BBB and there is an interrupt version so I
wonder if the polled driver is used by default. I did not check this.
> The console drivers are a real mess. We have no link-time configuration
options/mechanism for drivers. Its not so easy.
If consoles provide interrupt and poll devs, why have the test close the
console and reopen it with the polled driver? Yeah ok It is easy to say
this and no I have not looked into the detail and what complexity there
is. :)
> Changing the tests so that they work with an interrupt driven console
driver is hard. I don't think it makes sense. What we need is a non-
blocking test output support.
Agreed, I was not considering changing the tests to do this rather how
output is handled. There is the `TESTS_BUFFER_OUTPUT` and
`TESTS_USE_PRINTK` can they be forced on and all `stdout` and `stderr`
paths switched to what is used?
> If you consider this as a blocker, then you possibly delay the release
for several months.
This is being a little dramatic. I am not after a rewrite, I am looking
for a simple pragmatic solution. We need the ability to test on hardware
in a repeatable manner for the life of the release branch.
--
Ticket URL: <http://devel.rtems.org/ticket/3170#comment:13>
RTEMS Project <http://www.rtems.org/>
RTEMS Project
_______________________________________________
bugs mailing list
[email protected]
http://lists.rtems.org/mailman/listinfo/bugs
