#3170 closed defect (fixed)
Use BSP_output_char via RTEMS printer or simple console driver for test output by default
Reported by: | Chris Johns | Owned by: | Chris Johns |
---|---|---|---|
Priority: | high | Milestone: | 5.1 |
Component: | unspecified | Version: | 5 |
Severity: | critical | Keywords: | zedboard testing |
Cc: | Blocked By: | ||
Blocking: |
Description (last modified by Sebastian Huber)
Test runs with a interrupt driven console driver result in unreliable test outcomes.
Problem was noticed with test runs on Microzed, for example libtest/block08:
The test prints:
** END OF TEST BLOCK 8 ***
The rtems-test
command marks the result as a failure. There is a single *
missing from the start of the line. I attach the full test trace.
Attachments (1)
Change History (39)
Changed on 10/06/17 at 04:03:09 by Chris Johns
Attachment: | microzed-block8.txt added |
---|
comment:1 Changed on 10/06/17 at 21:48:30 by Chris Johns
Severity: | major → critical |
---|---|
Summary: | Microzed libtest/block8 fails to print end of test correctly. → Microzed libtest/block08 fails to print end of test correctly. |
I changed all printk
calls in the block08
test to printf
and the output from the test is now correct and rtems-test
passes the test.
There must be something wrong with the Zync UART drivers. I have escalated this to critical because I would like the Zynq to be a tier 1 device with the Beaglebone Black so we have Cortex-A9 and Cortex-A8 devices in tier 1.
There are 233 printk
references in the testsuite. I am sure some are needed however block08
's printk
calls were not needed so I am now wondering how many are?
comment:2 follow-up: 5 Changed on 10/09/17 at 07:19:29 by Sebastian Huber
Does the following patch alter the output:
diff --git a/c/src/lib/libbsp/arm/xilinx-zynq/console/zynq-uart.c b/c/src/lib/libbsp/arm/xilinx-zynq/console/zynq-uart.c index fa91f3f46e..3c42be428f 100644 --- a/c/src/lib/libbsp/arm/xilinx-zynq/console/zynq-uart.c +++ b/c/src/lib/libbsp/arm/xilinx-zynq/console/zynq-uart.c @@ -226,12 +226,18 @@ void zynq_uart_write_polled( { zynq_uart_context *ctx = (zynq_uart_context *) base; volatile zynq_uart *regs = ctx->regs; + rtems_interrupt_level level; + + rtems_interrupt_local_disable(level); while ((regs->channel_sts & ZYNQ_UART_CHANNEL_STS_TFUL) != 0) { /* Wait */ + rtems_interrupt_local_enable(level); + rtems_interrupt_local_disable(level); } regs->tx_rx_fifo = ZYNQ_UART_TX_RX_FIFO_FIFO(c); + rtems_interrupt_local_enable(level); } static void zynq_uart_write_support(
comment:3 Changed on 10/10/17 at 06:46:55 by Sebastian Huber
Component: | testing → unspecified |
---|
comment:4 Changed on 10/11/17 at 23:11:59 by Chris Johns
Owner: | changed from joel.sherrill@… to Chris Johns |
---|---|
Status: | new → assigned |
comment:5 Changed on 10/12/17 at 17:19:10 by Chris Johns
Replying to Sebastian Huber:
Does the following patch alter the output:
No it did not make a difference.
See https://lists.rtems.org/pipermail/build/2017-October/000007.html. Search for Result: invalid Time: 0:00:23.859291 dumpbuf01.exe.img
. The rtems_print_buffer()
call uses rtems_putc
and that uses printk
or the putc
equivalent.
Reviewing the failures there looks to be something wrong in the BSP. There are failures which should not or do not fail on other BSP. I cannot debug this remotely so it may have to wait. Are you able to run the tests on a Zynq?
comment:6 follow-up: 7 Changed on 10/13/17 at 06:48:49 by Sebastian Huber
Do you use a polled or interrupt driven console driver? The tests need a polled console driver.
comment:7 follow-up: 8 Changed on 10/13/17 at 12:51:02 by Chris Johns
Replying to Sebastian Huber:
Do you use a polled or interrupt driven console driver?
I use the default configuration:
configure --target=arm-rtems4.12 --prefix=/opt/work/chris/rtems/kernel/4.12 --disable-networking --enable-rtemsbsp=xilinx_zynq_zedboard --enable-maintainer-mode --enable-tests
I have always assumed the default configuration for any BSP lets the tests run. Is this not the case?
The tests need a polled console driver.
What do I do to make this happen?
comment:8 follow-up: 9 Changed on 10/13/17 at 12:54:16 by Sebastian Huber
Replying to Chris Johns:
Replying to Sebastian Huber:
Do you use a polled or interrupt driven console driver?
I use the default configuration:
configure --target=arm-rtems4.12 --prefix=/opt/work/chris/rtems/kernel/4.12 --disable-networking --enable-rtemsbsp=xilinx_zynq_zedboard --enable-maintainer-mode --enable-testsI 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.
The tests need a polled console driver.
What do I do to make this happen?
This is BSP-specific. Try, to add "ZYNQ_CONSOLE_USE_INTERRUPTS=" to the configure command line.
comment:9 follow-up: 10 Changed on 10/13/17 at 13:21:40 by Chris Johns
Replying to Sebastian Huber:
Replying to 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.
This is confusing because each BSP is different and has different options. The tests should manage this internally at runtime and not be dependent on low level BSP specific driver implementations. We have polled console driver support in BSPs, why not get the tests to use it?
Is this documented anywhere? FWIW I see adding some now as hiding the real issue.
What do I do to make this happen?
This is BSP-specific. Try, to add "ZYNQ_CONSOLE_USE_INTERRUPTS=" to the configure command line.
<sigh> I will consider the blocker status for this issue and discuss it with Joel today. He told me yesterday no tests should be using printk
unless configured to do so, ie small memory targets. There seems to be some confusion.
comment:10 follow-up: 13 Changed on 10/13/17 at 13:28:24 by Sebastian Huber
Replying to Chris Johns:
Replying to Sebastian Huber:
Replying to 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.
This is confusing because each BSP is different and has different options. The tests should manage this internally at runtime and not be dependent on low level BSP specific driver implementations. We have polled console driver support in BSPs, why not get the tests to use it?
Is this documented anywhere? FWIW I see adding some now as hiding the real issue.
The console drivers are a real mess. We have no link-time configuration options/mechanism for drivers. Its not so easy.
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.
What do I do to make this happen?
This is BSP-specific. Try, to add "ZYNQ_CONSOLE_USE_INTERRUPTS=" to the configure command line.
<sigh> I will consider the blocker status for this issue and discuss it with Joel today. He told me yesterday no tests should be using
printk
unless configured to do so, ie small memory targets. There seems to be some confusion.
Some tests must not use printf, due to execution environment constraints, e.g. interrupt context, no drivers, early system state, fatal error, etc.
If you consider this as a blocker, then you possibly delay the release for several months.
comment:11 follow-up: 15 Changed on 10/13/17 at 13:38:59 by Sebastian Huber
An short term option would be a unification of the BSP option to select a polled console driver.
comment:12 Changed on 10/13/17 at 13:41:11 by Joel Sherrill
There is a buffered test up option for the tests which will help those that use the infrastructure. Should be in testsuites/configure.ac
comment:13 follow-up: 14 Changed on 10/13/17 at 13:42:07 by Chris Johns
Replying to Sebastian Huber:
Replying to Chris Johns:
Replying to Sebastian Huber:
Replying to 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.
comment:14 Changed on 10/13/17 at 13:44:54 by Sebastian Huber
Replying to Chris Johns:
Replying to Sebastian Huber:
Replying to Chris Johns:
Replying to Sebastian Huber:
Replying to 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.
It depends also on the hardware, FIFO depth, DMA support, etc.
comment:15 Changed on 10/13/17 at 13:47:42 by Chris Johns
Replying to Sebastian Huber:
An short term option would be a unification of the BSP option to select a polled console driver.
We have an option --enable-tests=all
? Should this force polled drivers?
comment:16 Changed on 10/16/17 at 05:22:23 by Sebastian Huber
Its not really transparent to the user that --enable-tests=all
tinkers with the console driver.
comment:17 Changed on 10/23/17 at 11:49:42 by Sebastian Huber <sebastian.huber@…>
In 88e84c22/rtems:
comment:19 Changed on 10/26/17 at 12:06:21 by Sebastian Huber
Tests must be audited to ensure that they don't call the standard output functions, e.g.
nm find -name '*.exe'
| grep 'exe:\|\<f\?printf\>\|\<puts\>'
comment:20 Changed on 10/27/17 at 05:01:07 by Sebastian Huber
Description: | modified (diff) |
---|---|
Summary: | Microzed libtest/block08 fails to print end of test correctly. → Use BSP_output_char via RTEMS printer for test output by default |
If we use BSP_output_char for all tests, then the console driver is not tested. We probably need a special test for it.
We should also remove CONFIGURE_APPLICATION_NEEDS_CONSOLE_DRIVER from all other tests.
comment:22 Changed on 10/28/17 at 12:08:16 by Sebastian Huber <sebastian.huber@…>
In 7bec7f27/rtems:
comment:23 Changed on 10/28/17 at 12:08:27 by Sebastian Huber <sebastian.huber@…>
In 73d892d8/rtems:
comment:24 Changed on 10/28/17 at 12:08:39 by Sebastian Huber <sebastian.huber@…>
In 46ddc3c5/rtems:
comment:26 Changed on 10/28/17 at 12:09:02 by Sebastian Huber <sebastian.huber@…>
In acc9d064/rtems:
comment:30 Changed on 11/02/17 at 13:26:51 by Sebastian Huber <sebastian.huber@…>
In 8c1f4064/rtems:
comment:32 Changed on 11/06/17 at 06:29:41 by Sebastian Huber <sebastian.huber@…>
In c4b8b147/rtems:
comment:33 Changed on 11/07/17 at 06:09:15 by Sebastian Huber <sebastian.huber@…>
In 7b00c2fa/rtems:
comment:35 Changed on 11/09/17 at 06:27:14 by Sebastian Huber
Milestone: | 4.12.0 → 5.1 |
---|
Milestone renamed
comment:36 Changed on 11/13/17 at 09:01:06 by Sebastian Huber
Resolution: | → fixed |
---|---|
Status: | assigned → closed |
comment:37 Changed on 11/13/17 at 09:02:07 by Sebastian Huber
Summary: | Use BSP_output_char via RTEMS printer for test output by default → Use BSP_output_char via RTEMS printer or simple console driver for test output by default |
---|
RTEMS Tester test log for block8 on a Microzed.