Re: 16550A IRQ not enabled
On Thu, May 26, 2022 at 2:08 AM C Smith wrote: > > On Wed, May 25, 2022 at 1:07 AM Richard Weinberger > wrote: > > > > On Wed, May 25, 2022 at 2:18 AM C Smith via Xenomai > > wrote: > > > We are using Xenomai 3.1.2 on kernel 4.19.229, X86 CPU > > > We have a (Moxa CP-104ul) serial card on an isolated PCI bus interrupt 17. > > > lspci -v confirms that the serial card is isolated and that no other > > > peripheral uses this interrupt. > > > > > > We have the 16550A serial driver loaded, and an external serial device > > > trying to initiate a serial connection, but no interrupts are being > > > generated. The interrupt counter in /proc/xenomai/irq stay at 0. > > > > > > [user@device~]$ cat /proc/xenomai/irq > > > IRQ CPU0CPU1CPU2CPU3 > > >17: 0 0 0 0 rtser2 > > > rtser3 rtser4 rtser5 > > > > > > As an experiment: if we enable the Azalia sound chip in the BIOS, and > > > load its Alsa sound driver, the Serial card will then share IRQ 17 > > > with that sound chip, and then the serial card works. The serial > > > interrupt counter is incrementing in /proc/xenomai/irq and our serial > > > peripheral can utilize the serial port OK. > > > > I think enabling it in the BIOS is the key. Can you try keeping the sound > > driver > > disabled and only enable in the BIOS. > > We left the Azalia sound chip enabled in the BIOS, and disabled the > sound driver. > Interrupts in /proc/xenomai/irq are still not incrementing when serial > packets come into the po > > > > We don't want the sound driver enabled, but this test indicates that > > > 16550A somehow failed to enable its interrupt, whereas the sound > > > driver succeeded in doing so. > > > > > > How can we check a PIC, etc. to verify that the serial interrupt is > > > truly enabled when the 16550A driver is loaded alone? > > > > You can enable CONFIG_GENERIC_IRQ_DEBUGFS and then poke into > > /sys/kernel/debug/irq/. > > > > -- > > Thanks, > > //richard > > We rebuilt our kernel with CONFIG_GENERIC_IRQ_DEBUGFS enabled, booted > with the sound driver disabled and loaded xeno_16550A: > > [root@device~]# cat /sys/kernel/debug/irq/irqs/17 > cat: /sys/kernel/debug/irq/irqs/17: No such file or directory. > > We noticed that /proc/xenomai/irq is not showing IRQ17 immediately > after xeno_16550A is loaded. > proc/xenomai/irq only shows IRQ17 after the serial device is opened > for the first time. The driver requests the IRQ only upon open. So that's okay. > So /sys/kernel/debug/irq/irqs/17 doesn't become available until the > sound driver is loaded. ...or until you use the xeno_16550A driver by opening the device handle? > We also have a (Peak) CAN card installed in this system, and the > corresponding IRQ shows up immediately in > /sys/kernel/debug/irq/irqs/18 > after the xeno_can driver is loaded. > > Should we expect to see the IRQ show up in /proc/xenomai/irq > immediately after loading the xeno_16550A driver? No. It depends how the driver works. As I wrote, xeno_16550A does rtdm_irq_request() in the open, not the probe function. > How can we debug this further, since /sys/kernel/debug/irq/irqs/17 > does not exist without that sound driver? I don't really understand, didn't you write a few lines above that the IRQ shows also up when you open the device? Why do you need the IRQ earlier? -- Thanks, //richard
Re: 16550A IRQ not enabled
On Wed, May 25, 2022 at 1:07 AM Richard Weinberger wrote: > > On Wed, May 25, 2022 at 2:18 AM C Smith via Xenomai > wrote: > > We are using Xenomai 3.1.2 on kernel 4.19.229, X86 CPU > > We have a (Moxa CP-104ul) serial card on an isolated PCI bus interrupt 17. > > lspci -v confirms that the serial card is isolated and that no other > > peripheral uses this interrupt. > > > > We have the 16550A serial driver loaded, and an external serial device > > trying to initiate a serial connection, but no interrupts are being > > generated. The interrupt counter in /proc/xenomai/irq stay at 0. > > > > [user@device~]$ cat /proc/xenomai/irq > > IRQ CPU0CPU1CPU2CPU3 > >17: 0 0 0 0 rtser2 > > rtser3 rtser4 rtser5 > > > > As an experiment: if we enable the Azalia sound chip in the BIOS, and > > load its Alsa sound driver, the Serial card will then share IRQ 17 > > with that sound chip, and then the serial card works. The serial > > interrupt counter is incrementing in /proc/xenomai/irq and our serial > > peripheral can utilize the serial port OK. > > I think enabling it in the BIOS is the key. Can you try keeping the sound > driver > disabled and only enable in the BIOS. We left the Azalia sound chip enabled in the BIOS, and disabled the sound driver. Interrupts in /proc/xenomai/irq are still not incrementing when serial packets come into the po > > We don't want the sound driver enabled, but this test indicates that > > 16550A somehow failed to enable its interrupt, whereas the sound > > driver succeeded in doing so. > > > > How can we check a PIC, etc. to verify that the serial interrupt is > > truly enabled when the 16550A driver is loaded alone? > > You can enable CONFIG_GENERIC_IRQ_DEBUGFS and then poke into > /sys/kernel/debug/irq/. > > -- > Thanks, > //richard We rebuilt our kernel with CONFIG_GENERIC_IRQ_DEBUGFS enabled, booted with the sound driver disabled and loaded xeno_16550A: [root@device~]# cat /sys/kernel/debug/irq/irqs/17 cat: /sys/kernel/debug/irq/irqs/17: No such file or directory. We noticed that /proc/xenomai/irq is not showing IRQ17 immediately after xeno_16550A is loaded. proc/xenomai/irq only shows IRQ17 after the serial device is opened for the first time. So /sys/kernel/debug/irq/irqs/17 doesn't become available until the sound driver is loaded. We also have a (Peak) CAN card installed in this system, and the corresponding IRQ shows up immediately in /sys/kernel/debug/irq/irqs/18 after the xeno_can driver is loaded. Should we expect to see the IRQ show up in /proc/xenomai/irq immediately after loading the xeno_16550A driver? How can we debug this further, since /sys/kernel/debug/irq/irqs/17 does not exist without that sound driver?
Replay available - 2022 Global Xenomai Community Meetup
Replay of the Event: CSDN Chinese https://intel.csdn.net/2022GlobalXenomaiCommunityMeetup/zh CSDN English https://intel.csdn.net/2022GlobalXenomaiCommunityMeetup/en Vhall Original https://intel.vhall.com/pc/181?channel=main Vhall Chinese https://intel.vhall.com/pc/215?channel=main Vhall English https://intel.vhall.com/pc/217?channel=main Band of Automation Brothers English: https://xmd.h5.xeknow.com/sl/4vqSlo Band of Automation Brothers Chinese: https://xmd.h5.xeknow.com/sl/2fv9vj >Date: Tue, 24 May 2022 14:22:08 + >From: "Wang, Rick Y" > > >>-Original Message- >>From: Wang, Rick Y >> >>Hi all, >> >>We're excited to announce that the 2022 Global Xenomai Community Meetup >>is open for registration! >> >>Experts in Xenomai community from Europe, the United States and China >>will share Xenomai-based RTOS development, applications and best practices. >>There are 12 presentations and 2 Live Q sessions in the event. >> >>The meetup was divided into two halves to facilitate Asia-Pacific and >>European time zones. The meetup provides simultaneous interpretation in >>both Chinese and English. Attendance will be free for everyone. >> >>For detail agenda and registration, please visit: >>https://intel.csdn.net/2022GlobalXenomaiCommunityMeetup/en >> >>Please "Click to enter Vhall live" and then "live registration". >> >>Opening for part 1 is at: >>PDT 18:00 May 24 | UTC 01:00, CEST 03:00, CST 09:00 May 25 >> > >The Meetup will start on time. Looking forward to meeting you soon. > >>- Opening and Welcome >> by Jonny Rikard Klasson (Intel) >> >>- Real-time Operating Systems in Special Effects >> by Steve Rosenbluth (Concept Overdrive Inc) >> >>- IEC61131-3 platform development and optimization based on Linux >>Xenomai >> by Henry Bao (Shanghai Nxtrol Technology Co., Ltd.) >> >>- Xenomai Motion Control Solution and Tuning Based on Intel Edge >>Controls >> for Industrial >> by Wei Zhang, Yu Yan (Intel) >> >>- Industrial PC & Xenomai >> by Xiewei Wang (Shenzhen GWtech Co.,Ltd.) >> >>- Xenomai in Industry Control System >> by Yebin Liang (Han's Smart Control Technology Co., Ltd.) >> >>- Speakers Q >> by Session 1 Speakers >> >> >>Opening for part 2 is at: >>PDT 23:00 May 24 | UTC 06:00, CEST 08:00, CST 14:00 May 25 >> >>- Welcome and Keynote Speaking >> Xenomai Community: Today and Tomorrow >> by Jan Kiszka (Siemens AG) >> >>- Upgrading to Xenomai 3: Lessons learned >> by Richard Weinberger (Sigma star gmbh) >> >>- Realtime Exception Handling in Xenomai >> by Johannes Kirchmai (SIGMATEK GmbH & Co KG) >> >>- Application Development Based on Xenomai >> by Changjun Chen (SYMG(Shanghai) Intelligence System Co., Ltd) >> >>- Delivering Real-Time Performance with Intel® TCC >> by Jianbo Cao (Intel) >> >>- Running Xenomai VM on ACRN hypervisor >> by Ronnie Yang (Intel) >> >>- Speakers Q >> by Session 2 Speakers >> >> >>Pacific Daylight Time (PDT): UTC-7 hours Coordinated Universal Time >>(UTC) Central European Summer Time (CEST): UTC+2 China Standard Time >>(CST): UTC+8 hours >> >> >>Looking forward to meeting you online! >> >> >>Thanks, >>Rick >>
Re: RTNet: sendto(): EAGAIN error
Il 24/05/22 08:33, Jan Kiszka ha scritto: On 13.05.22 14:51, Mauro S. via Xenomai wrote: Il 05/05/22 17:04, Mauro S. via Xenomai ha scritto: Il 05/05/22 15:05, Jan Kiszka ha scritto: On 03.05.22 17:18, Mauro S. via Xenomai wrote: Hi all, I'm trying to use RTNet with TDMA. I succesfully set up my bus: - 1GBps speed - 3 devices - cycle time 1ms - timeslots with 200us offset I wrote a simple application that in parallel receives and sends UDP packets on TDMA bus. - sendto() is done to the broadcast address, port - recvfrom() is done on the port Application sends a small packet (5 bytes) in a periodic task with 1ms period and prio 51. Receive is done in a non-periodic task with prio 50. Application is running on all the three devices, and I can see packets are sent and received correctly by all the devices. But after a while, all send() calls on all devices fails with error EAGAIN. Could this error be related to some internal buffer/queue that becomes full? Or am I missing something? When you get EAGAIN on sender side, cleanup of TX buffers likely failed, and the socket ran out of buffers to send further frames. That may be related to TX IRQs not making it. Check the TX IRQ counter on the sender, if it increases at the same pace as you send packets. Jan Thanks Jan for your fast answer. I forgot to mention that I'm using the rt_igb driver. I have only one IRQ field in /proc/xenomai/irq, counting both TX and RX cat /proc/xenomai/irq | grep rteth0 125: 0 0 2312152 0 rteth0-TxRx-0 I did this test: * on the master I send a packet every 1ms in a periodic RT task (period 1ms, prio 51) with my test app. * on the master I see an increment of about 2000 IRQs per second: I guess 1000 are for my sent packets (1 packet every ms), and 1000 for the TDMA sync packet. In fact I see the "rtifconfig" RX counter almost stationary (only 8 packets every 2-3 seconds, refresh requests from slaves?), TX counter incrementing in about 2000 packets per second. * on the two slaves (thet are running nothing) I observe the same rate (about 2000 IRQs per second). I see the "rtifconfig" TX counter almost stationary (only 4 packets every 2-3 seconds), RX counter incrementing in about 2000 packets per second. * if I stop sending packets with my app, I can see all the rates at about 1000 per second If I start send-receive on all the three devices, I can see a IRQ rate around 4000 IRQs per second on all devices (1000 sync, 1000 send and 1000 + 1000 receive). I observed that if I only send from master and receive on slaves the problem does not appear. Or if I send/receive from all, but with a packet every 2ms, the problem does not appear. Could be a CPU performance problem (4k IRQs per second are too much for an Intel Atom x5-E8000 CPU @ 1.04GHz)? Thanks in advance, regards Hi all, I did further tests. First of all I modified my code to wait the TDMA sync event before do a send. I'm doing it with RTMAC_RTIOC_WAITONCYCLE ioctl (the .h file that defines it is not exported in userland, I need to copy kernel/drivers/net/stack/include/rtmac.h file in my project dir to include it). I send one broadcast packet each TDMA cycle (1ms) from each device (total 3 devices), and each device also receive the packets from the other two (I use two different sockets to send and receive). The first problem that I detected is that the EAGAIN error happens anyway (only with less frequency): I expected to have this error disappearing, since I send one packet synced with TDMA cycle time, then the rtskbs queue should remain empty (or at most with a single packet queued). I tried to change the cycle time (2ms, then 4ms) but the problem remains. The only mode that seems to don't have EAGAIN error (or at least have it really less frequently) is to send the packet every two TDMA cycles, independently of the cycle duration (1ms, 2ms, 4ms...). Am I missing something? Are there any benchmarks/use cases using TDMA in this manner? The second problem that happened to me is that sometimes one slave stopped to send/receive packets. Send is blocked in RTMAC_RTIOC_WAITONCYCLE, recv does receive nothing. When the lock happens, rtifconfig shows dropped and overruns counters incrementing with the TDMA cycle rate (e.g. 250 for 4ms cycle): seems that the RX queue is completely locked. Dmesg does not show errors and /proc/xenomai/irq shows that IRQ counter is still (1 irq each 2-3 seconds). A "rtnet stop && rtnet start" recovers from this situation. The strangeness is that the problematic device is always the same. Trying a different switch the problem disappears. Could be a problem caused by some switch buffering? Hmm, my first try then would be using a cross-link between two nodes and see if the issue is gone. If so, there is very likely some issue in the compatibility of the hardware and/or the current driver version. Keep in mind that the RTnet drivers are all aging. Jan Hi Jan,
[PATCH 1/2] x86: ipipe: Fix testing issue due to uninitialized FPU
On x86 fp_regs_set() expects that the FPU state was initialized by
calling the fninit instruction. When running the tests in kernel space
in task context there is no guarantee that the FPU was initialized so
under heavy load / scheduling the test might fail and report a FPU
register corruption.
The new introduced fp_init() takes care of the FPU initialization. We
call it before fp_regs_set() in task context and re-use it for the kernel
context as well.
As the affected fptest.h exists for every ipipe/dovetail architecture
combination we have to touch all of those.
Signed-off-by: Florian Bezdeka
---
.../cobalt/arch/arm/dovetail/include/asm/xenomai/fptest.h | 4
kernel/cobalt/arch/arm/ipipe/include/asm/xenomai/fptest.h | 4
.../arch/arm64/dovetail/include/asm/xenomai/fptest.h | 4
.../cobalt/arch/arm64/ipipe/include/asm/xenomai/fptest.h | 4
.../cobalt/arch/powerpc/ipipe/include/asm/xenomai/fptest.h | 4
.../cobalt/arch/x86/dovetail/include/asm/xenomai/fptest.h | 4
kernel/cobalt/arch/x86/ipipe/include/asm/xenomai/fptest.h | 7 ++-
kernel/drivers/testing/switchtest.c| 4 +++-
8 files changed, 33 insertions(+), 2 deletions(-)
diff --git a/kernel/cobalt/arch/arm/dovetail/include/asm/xenomai/fptest.h
b/kernel/cobalt/arch/arm/dovetail/include/asm/xenomai/fptest.h
index ad7814cce..4cc075223 100644
--- a/kernel/cobalt/arch/arm/dovetail/include/asm/xenomai/fptest.h
+++ b/kernel/cobalt/arch/arm/dovetail/include/asm/xenomai/fptest.h
@@ -35,6 +35,10 @@ static inline int fp_kernel_supported(void)
return 0;
}
+static inline void fp_init(void)
+{
+}
+
static inline int fp_linux_begin(void)
{
return -ENOSYS;
diff --git a/kernel/cobalt/arch/arm/ipipe/include/asm/xenomai/fptest.h
b/kernel/cobalt/arch/arm/ipipe/include/asm/xenomai/fptest.h
index b8c627bed..d3f335f86 100644
--- a/kernel/cobalt/arch/arm/ipipe/include/asm/xenomai/fptest.h
+++ b/kernel/cobalt/arch/arm/ipipe/include/asm/xenomai/fptest.h
@@ -35,6 +35,10 @@ static inline int fp_kernel_supported(void)
return 1;
}
+static inline void fp_init(void)
+{
+}
+
static inline int fp_linux_begin(void)
{
return -ENOSYS;
diff --git a/kernel/cobalt/arch/arm64/dovetail/include/asm/xenomai/fptest.h
b/kernel/cobalt/arch/arm64/dovetail/include/asm/xenomai/fptest.h
index 5f3630dda..8c4228d40 100644
--- a/kernel/cobalt/arch/arm64/dovetail/include/asm/xenomai/fptest.h
+++ b/kernel/cobalt/arch/arm64/dovetail/include/asm/xenomai/fptest.h
@@ -18,6 +18,10 @@ static inline int fp_kernel_supported(void)
return 0;
}
+static inline void fp_init(void)
+{
+}
+
static inline int fp_linux_begin(void)
{
return -ENOSYS;
diff --git a/kernel/cobalt/arch/arm64/ipipe/include/asm/xenomai/fptest.h
b/kernel/cobalt/arch/arm64/ipipe/include/asm/xenomai/fptest.h
index 291c9e5f0..39903a047 100644
--- a/kernel/cobalt/arch/arm64/ipipe/include/asm/xenomai/fptest.h
+++ b/kernel/cobalt/arch/arm64/ipipe/include/asm/xenomai/fptest.h
@@ -30,6 +30,10 @@ static inline int fp_kernel_supported(void)
return 0;
}
+static inline void fp_init(void)
+{
+}
+
static inline int fp_linux_begin(void)
{
return -ENOSYS;
diff --git a/kernel/cobalt/arch/powerpc/ipipe/include/asm/xenomai/fptest.h
b/kernel/cobalt/arch/powerpc/ipipe/include/asm/xenomai/fptest.h
index e09ca2c3b..a9d93fe87 100644
--- a/kernel/cobalt/arch/powerpc/ipipe/include/asm/xenomai/fptest.h
+++ b/kernel/cobalt/arch/powerpc/ipipe/include/asm/xenomai/fptest.h
@@ -41,6 +41,10 @@ static inline int fp_kernel_supported(void)
#endif /* !CONFIG_PPC_FPU */
}
+static inline void fp_init(void)
+{
+}
+
static inline int fp_linux_begin(void)
{
return -ENOSYS;
diff --git a/kernel/cobalt/arch/x86/dovetail/include/asm/xenomai/fptest.h
b/kernel/cobalt/arch/x86/dovetail/include/asm/xenomai/fptest.h
index 83a6413d5..463d9d370 100644
--- a/kernel/cobalt/arch/x86/dovetail/include/asm/xenomai/fptest.h
+++ b/kernel/cobalt/arch/x86/dovetail/include/asm/xenomai/fptest.h
@@ -35,6 +35,10 @@ static inline int fp_kernel_supported(void)
return 0;
}
+static inline void fp_init(void)
+{
+}
+
static inline int fp_linux_begin(void)
{
kernel_fpu_begin();
diff --git a/kernel/cobalt/arch/x86/ipipe/include/asm/xenomai/fptest.h
b/kernel/cobalt/arch/x86/ipipe/include/asm/xenomai/fptest.h
index f0ecd00e9..ccf7afa11 100644
--- a/kernel/cobalt/arch/x86/ipipe/include/asm/xenomai/fptest.h
+++ b/kernel/cobalt/arch/x86/ipipe/include/asm/xenomai/fptest.h
@@ -29,6 +29,11 @@ static inline int fp_kernel_supported(void)
return 1;
}
+static inline void fp_init(void)
+{
+ __asm__ __volatile__("fninit");
+}
+
static inline int fp_linux_begin(void)
{
#if defined(CONFIG_X86_USE_3DNOW) \
@@ -48,7 +53,7 @@ static inline int fp_linux_begin(void)
/* kernel_fpu_begin() does no re-initialize the fpu context, but
fp_regs_set() implicitely expects an initialized fpu context, so
[PATCH 2/2] x86: ipipe: Enable FPU tests unconditionally
Parts of the FPU tests were skipped when one of the following config
options was enabled, shadowing a real test issue that was triggered by
high load on the system. The options:
- CONFIG_X86_USE_3DNOW
- CONFIG_MD_RAID456
- CONFIG_MD_RAID456_MODULE
As the FPU initialization is fixed now, we can enable the tests
unconditionally.
Signed-off-by: Florian Bezdeka
---
.../arch/x86/ipipe/include/asm/xenomai/fptest.h | 13 -
1 file changed, 13 deletions(-)
diff --git a/kernel/cobalt/arch/x86/ipipe/include/asm/xenomai/fptest.h
b/kernel/cobalt/arch/x86/ipipe/include/asm/xenomai/fptest.h
index ccf7afa11..7a2b17d75 100644
--- a/kernel/cobalt/arch/x86/ipipe/include/asm/xenomai/fptest.h
+++ b/kernel/cobalt/arch/x86/ipipe/include/asm/xenomai/fptest.h
@@ -36,19 +36,6 @@ static inline void fp_init(void)
static inline int fp_linux_begin(void)
{
-#if defined(CONFIG_X86_USE_3DNOW) \
- || defined(CONFIG_MD_RAID456) || defined(CONFIG_MD_RAID456_MODULE)
- /* Ther kernel uses x86 FPU, we can not also use it in our tests. */
- static int once = 0;
- if (!once) {
- once = 1;
- printk("%s:%d: Warning: Linux is compiled to use FPU in "
- "kernel-space.\nFor this reason, switchtest can not "
- "test using FPU in Linux kernel-space.\n",
- __FILE__, __LINE__);
- }
- return -EBUSY;
-#endif /* 3DNow or RAID 456 */
kernel_fpu_begin();
/* kernel_fpu_begin() does no re-initialize the fpu context, but
fp_regs_set() implicitely expects an initialized fpu context, so
--
2.35.3
[PATCH 0/2] Backport: FPU testing / switchtest issue to 3.2 stable
Hi all, this is the backport of the previously pulished FPU testing cleanup. As 3.2 stable branch still supports ipipe and ipipe allows us to use the FPU in kernel space (in user task context) we have to deal with the problem differently. The x86 fpu test relied on getting a clean fpu state (created by fninit), but there was no guarantee that this initialization happened which was uncovered when stressing server grade hardware with stress-ng and running the xenomai testsuite in parallel. 3.1 stable is also affected. I'm currently working on an additional backport to that branch. Best regards, Florian Florian Bezdeka (2): x86: ipipe: Fix testing issue due to uninitialized FPU x86: ipipe: Enable FPU tests unconditionally .../arm/dovetail/include/asm/xenomai/fptest.h | 4 .../arm/ipipe/include/asm/xenomai/fptest.h| 4 .../dovetail/include/asm/xenomai/fptest.h | 4 .../arm64/ipipe/include/asm/xenomai/fptest.h | 4 .../ipipe/include/asm/xenomai/fptest.h| 4 .../x86/dovetail/include/asm/xenomai/fptest.h | 4 .../x86/ipipe/include/asm/xenomai/fptest.h| 20 ++- kernel/drivers/testing/switchtest.c | 4 +++- 8 files changed, 33 insertions(+), 15 deletions(-) -- 2.35.3
Re: 16550A IRQ not enabled
On Wed, May 25, 2022 at 2:18 AM C Smith via Xenomai wrote: > We are using Xenomai 3.1.2 on kernel 4.19.229, X86 CPU > We have a (Moxa CP-104ul) serial card on an isolated PCI bus interrupt 17. > lspci -v confirms that the serial card is isolated and that no other > peripheral uses this interrupt. > > We have the 16550A serial driver loaded, and an external serial device > trying to initiate a serial connection, but no interrupts are being > generated. The interrupt counter in /proc/xenomai/irq stay at 0. > > [user@device~]$ cat /proc/xenomai/irq > IRQ CPU0CPU1CPU2CPU3 >17: 0 0 0 0 rtser2 > rtser3 rtser4 rtser5 > > As an experiment: if we enable the Azalia sound chip in the BIOS, and > load its Alsa sound driver, the Serial card will then share IRQ 17 > with that sound chip, and then the serial card works. The serial > interrupt counter is incrementing in /proc/xenomai/irq and our serial > peripheral can utilize the serial port OK. I think enabling it in the BIOS is the key. Can you try keeping the sound driver disabled and only enable in the BIOS. > We don't want the sound driver enabled, but this test indicates that > 16550A somehow failed to enable its interrupt, whereas the sound > driver succeeded in doing so. > > How can we check a PIC, etc. to verify that the serial interrupt is > truly enabled when the 16550A driver is loaded alone? You can enable CONFIG_GENERIC_IRQ_DEBUGFS and then poke into /sys/kernel/debug/irq/. -- Thanks, //richard
[PATCH] switchtest: Cleanup FPU tests after ipipe -> dovetail transition
FPU usage in kernel space was allowed / enabled with ipipe, but is no
longer available for dovetail based kernels. That allows us to clean
up the FPU related tests of the switchtest utility.
fp_kernel_supported() can be removed as all supported architectures
returned 0 already. That allows us to remove the FPU feature test flag
RTTST_SWTEST_USE_FPU as well.
Signed-off-by: Florian Bezdeka
---
include/rtdm/uapi/testing.h | 1 -
.../arch/arm/include/asm/xenomai/fptest.h | 5
.../arch/arm64/include/asm/xenomai/fptest.h | 5
.../arch/x86/include/asm/xenomai/fptest.h | 11 -
kernel/drivers/testing/switchtest.c | 23 ---
testsuite/switchtest/switchtest.c | 1 -
6 files changed, 46 deletions(-)
diff --git a/include/rtdm/uapi/testing.h b/include/rtdm/uapi/testing.h
index f8207b8c7..49f0b7f25 100644
--- a/include/rtdm/uapi/testing.h
+++ b/include/rtdm/uapi/testing.h
@@ -68,7 +68,6 @@ struct rttst_swtest_task {
/* Possible values for struct rttst_swtest_task::flags. */
#define RTTST_SWTEST_FPU 0x1
-#define RTTST_SWTEST_USE_FPU 0x2 /* Only for kernel-space tasks. */
#define RTTST_SWTEST_FREEZE0x4 /* Only for kernel-space tasks. */
struct rttst_swtest_dir {
diff --git a/kernel/cobalt/arch/arm/include/asm/xenomai/fptest.h
b/kernel/cobalt/arch/arm/include/asm/xenomai/fptest.h
index ca1752206..fc177fcb5 100644
--- a/kernel/cobalt/arch/arm/include/asm/xenomai/fptest.h
+++ b/kernel/cobalt/arch/arm/include/asm/xenomai/fptest.h
@@ -30,11 +30,6 @@
#include
-static inline int fp_kernel_supported(void)
-{
- return 0;
-}
-
static inline int fp_linux_begin(void)
{
return -ENOSYS;
diff --git a/kernel/cobalt/arch/arm64/include/asm/xenomai/fptest.h
b/kernel/cobalt/arch/arm64/include/asm/xenomai/fptest.h
index bc9dc342e..0958d5e2a 100644
--- a/kernel/cobalt/arch/arm64/include/asm/xenomai/fptest.h
+++ b/kernel/cobalt/arch/arm64/include/asm/xenomai/fptest.h
@@ -13,11 +13,6 @@
#define have_fp (ELF_HWCAP & HWCAP_FP)
-static inline int fp_kernel_supported(void)
-{
- return 0;
-}
-
static inline int fp_linux_begin(void)
{
return -ENOSYS;
diff --git a/kernel/cobalt/arch/x86/include/asm/xenomai/fptest.h
b/kernel/cobalt/arch/x86/include/asm/xenomai/fptest.h
index 83a6413d5..55818f853 100644
--- a/kernel/cobalt/arch/x86/include/asm/xenomai/fptest.h
+++ b/kernel/cobalt/arch/x86/include/asm/xenomai/fptest.h
@@ -24,17 +24,6 @@
#include
#include
-/*
- * We do NOT support out-of-band FPU operations in kernel space for a
- * reason: this is a mess. Out-of-band FPU is just fine and makes a
- * lot of sense for many real-time applications, but you have to do
- * that from userland.
- */
-static inline int fp_kernel_supported(void)
-{
- return 0;
-}
-
static inline int fp_linux_begin(void)
{
kernel_fpu_begin();
diff --git a/kernel/drivers/testing/switchtest.c
b/kernel/drivers/testing/switchtest.c
index b5bc256df..9072717d5 100644
--- a/kernel/drivers/testing/switchtest.c
+++ b/kernel/drivers/testing/switchtest.c
@@ -416,9 +416,6 @@ static void rtswitch_ktask(void *cookie)
rtswitch_pend_rt(ctx, task->base.index);
while (!rtdm_task_should_stop()) {
- if (task->base.flags & RTTST_SWTEST_USE_FPU)
- fp_regs_set(fp_features, task->base.index + i * 1000);
-
switch(i % 3) {
case 0:
/* to == from means "return to last task" */
@@ -437,17 +434,6 @@ static void rtswitch_ktask(void *cookie)
rtswitch_to_rt(ctx, task->base.index, to);
}
- if (task->base.flags & RTTST_SWTEST_USE_FPU) {
- expected = task->base.index + i * 1000;
- fp_val = fp_regs_check(fp_features, expected, report);
-
- if (fp_val != expected) {
- if (task->base.flags & RTTST_SWTEST_FREEZE)
- xntrace_user_freeze(0, 0);
- handle_ktask_error(ctx, fp_val);
- }
- }
-
if (++i == 400)
i = 0;
}
@@ -465,15 +451,6 @@ static int rtswitch_create_ktask(struct rtswitch_context
*ctx,
char name[30];
int err;
- /*
-* Silently disable FP tests in kernel if FPU is not supported
-* there. Typical case is math emulation support: we can use
-* it from userland as a synthetic FPU, but there is no sane
-* way to use it from kernel-based threads (Xenomai or Linux).
-*/
- if (!fp_kernel_supported())
- ptask->flags &= ~RTTST_SWTEST_USE_FPU;
-
ptask->flags |= RTSWITCH_KERNEL;
err = rtswitch_register_task(ctx, ptask);
diff --git a/testsuite/switchtest/switchtest.c
b/testsuite/switchtest/switchtest.c
index
