Re: Does FreeRTOS works on Linux?
On 6. 05. 21 18:00, kernelnewbies-requ...@kernelnewbies.org wrote: Subject: Does FreeRTOS works on Linux? From: Raul Piper Date: 5. 05. 21 20:07 To: kernelnewbies Hello, I am having an embedded linux system and wanted to use any RTOS on it. Can I use Free RTOS? My project has 2 tasks , one is producer and another is consumer working parallely. I have seen Free RTOS used in microcontrollers handling this , how can this be done in Linux(which such APIs if not Free RTOS). Regards, R Open AMP project (www.openampproject.org) ? WBR Primoz ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: read the memory mapped address - pcie - kernel hangs
Hi,
Have read also other replays to this topic.
I have seen-debug such deadlock problems with FPGA based PCIe endpoint
devices (Xilinx chips) and usually (if not signal integrity problems),
the problem was in wrong AXI master/slave bus handling in FPGA design.
I guess you have FPGA Xilinx PCIe endpoint IP core attached as AXI
master to FPGA internal AXI bus (access to AXI slaves inside FPGA design).
If FPGA code in your design does not handle correctly AXI master
read/write requests, e.g. FPGA AXI slave does not generate bus ACK in
correct way, the PCIe bus will stay locked (no PCIe completion sent
back), resulting in complete system lock. Some PCIe root chips have
diagnostic LEDs to help decode PCIe problems.
From your notice about doing two 32bit reads on 64bit CPU, I would
guess the problem is in handling AXI transfer size signals in FPGA slave
code.
I would suggest you to check the code in FPGA design. You can use FPGA
test bench simulation to check the behaviour of PCIe endpoint originated
AXI read/write requests.
Xilinx provides test bench simulation code for their PCIe IP's.
They provide also PCIe root port model, so you can simulate AXI
read/writes accesses as they would come from CPU I/O memory requests via
PCIe TLPs.
WBR Primoz
On 8. 01. 20 20:00, Muni Sekhar wrote:
Hi All,
I have module with Xilinx FPGA. It implements UART(s), SPI(s),
parallel I/O and interfaces them to the Host CPU via PCI Express bus.
I see that my system freezes without capturing the crash dump for certain tests.
I debugged this issue and it was tracked down to the ‘readl()’ in
interrupt handler code
In ISR, first reads the Interrupt Status register using ‘readl()’ as
given below.
status = readl(ctrl->reg + INT_STATUS);
And then clears the pending interrupts using ‘writel()’ as given blow.
writel(status, ctrl->reg + INT_STATUS);
I've noticed a kernel hang if INT_STATUS register read again after
clearing the pending interrupts.
My system freezes only after executing the same ISR code after
millions of interrupts. Basically reading the memory mapped register
in ISR resulting this behavior.
If I comment “status = readl(ctrl->reg + INT_STATUS);” after clearing
the pending interrupts then system is stable .
As a temporary workaround I avoided reading the INT_STATUS register
after clearing the pending bits, and this code change works fine.
Can someone clarify me why the kernel hangs without crash dump incase
if I read the INT_STATUS register using readl() after
clearing(writel()) the pending bits?
To read the memory mapped IO kernel provides {read}{b,w,l,q}() API’s.
If PCIe card is not responsive , can call to readl() from interrupt
context makes system freeze?
Thanks for any suggestions and solutions to this problem!
Snippet of the ISR code is given blow:
https://pastebin.com/as2tSPwE
static irqreturn_t pcie_isr(int irq, void *data)
{
struct test_device *ctrl = (struct test_device *)data;
u32 status;
…
status = readl(ctrl->reg + INT_STATUS);
/*
* Check to see if it was our interrupt
*/
if (!(status & 0x000C))
return IRQ_NONE;
/* Clear the interrupt */
writel(status, ctrl->reg + INT_STATUS);
if (status & 0x0004) {
/*
* Tx interrupt pending.
*/
}
if (status & 0x0008) {
/* Rx interrupt Pending */
/* The system freezes if I read again the INT_STATUS
register as given below */
status = readl(ctrl->reg + INT_STATUS);
}
..
return IRQ_HANDLED;
}
___
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: I2C bus driver TIMEDOUT because of PM autosuspend
On 3. 12. 19 02:30, anish singh wrote: On Fri, Nov 29, 2019 at 12:53 PM Primoz Beltram wrote: I am analysing a problem with I2C bus driver where the problem shows up as I2C bus completely blocked. The LX driver in question is /drivers/i2c/busses/i2c-xiic.c. Problem is difficult to reproduce, it happens very rarely. So far I saw that the main precondition is to have very heavy I2C traffic on bus. In my case this is achieved/reproduced via netdev driving SFP LEDs via /sys/class/leds/ (via gpio-pca953x). I generate traffic with iperf3. Network traffic is on 10Gbps EMAC. LX kernel is 4.14.0. What I saw from debugging this problem is that I2C bus get blocked when wait_event_timeout() completes because of timeout. The timeout handling in this driver is probably not robust enough (bus should not remain blocked), but at this moment this are just my speculations (don't know enough details). Check with salea logic analyzer what happens to the i2c bus. Looking the driver code and data on oscilloscope, I saw that SCL in single I2C data transfer sequence can be interrupted for very long delays, e.g up to hundredths of usec (SCL is 100kHz). I started to suspect that PM autosuspend delay could play some role here. There are only two delays in driver code, first in wait_event_timeout and second in set autosuspend delay. Case is a bit strange because in very busy I2C traffic, PM autosuspend should not be triggered at all. Additionally, if I lower PM timeout, e.g. from 1000 (default) to 100, I hit the problem sooner (waits for problem hit are in order of n*10minutes). It looks to me that PM autosupend is playing some role here. Power management options in my .config: # CONFIG_SUSPEND is not set # CONFIG_PM is not set CONFIG_ARCH_SUSPEND_POSSIBLE=y I intentionally did not put all detail descriptions of embedded system and test setup here (long list), because the main reason of this post is: The workaround that works for me/customer (at the moment) is to disable PM autosuspend in the driver code, either by incerementing PM delay from 1000 to 1 or by disabling autosuspend (comment out call to pm_runtime_put_autosuspend() in xiic_xfer()). But, I would like to expose/discuss this issue (maintainer of the code, or others). The reason/source of the problem can be much more complex and in some other place. So my question is who should I contact, is this the M: in the MAINTAINERS list, the MODULE_AUTHOR, ...? You can certainly add the author in loop but I am afraid you won't get any help as this would be specific to your board. So, best is to check soc vendor who has written your i2c bus driver or it could be a issue with your i2c client in that case show them your salea logic analyzer logs to see if they can figure out anything wrong. Thanks for reply and suggestions. My first suspicion was signal integrity on PCB, but if I add some debug prints in i2c-xiic driver (e.g. build with DEBUG define), the problem is no longer reproducible (not a single timeout completion in wait_event_timeout()). Signal integrity problem does not look credible to me. For my system I fixed the problem in i2c-xiic driver (in handIing timeout, not leave bus blocked). Found also a contact and fill report for SoC vendor. WBR Primoz How to proceed. WBR Primoz ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
I2C bus driver TIMEDOUT because of PM autosuspend
I am analysing a problem with I2C bus driver where the problem shows up as I2C bus completely blocked. The LX driver in question is /drivers/i2c/busses/i2c-xiic.c. Problem is difficult to reproduce, it happens very rarely. So far I saw that the main precondition is to have very heavy I2C traffic on bus. In my case this is achieved/reproduced via netdev driving SFP LEDs via /sys/class/leds/ (via gpio-pca953x). I generate traffic with iperf3. Network traffic is on 10Gbps EMAC. LX kernel is 4.14.0. What I saw from debugging this problem is that I2C bus get blocked when wait_event_timeout() completes because of timeout. The timeout handling in this driver is probably not robust enough (bus should not remain blocked), but at this moment this are just my speculations (don't know enough details). Looking the driver code and data on oscilloscope, I saw that SCL in single I2C data transfer sequence can be interrupted for very long delays, e.g up to hundredths of usec (SCL is 100kHz). I started to suspect that PM autosuspend delay could play some role here. There are only two delays in driver code, first in wait_event_timeout and second in set autosuspend delay. Case is a bit strange because in very busy I2C traffic, PM autosuspend should not be triggered at all. Additionally, if I lower PM timeout, e.g. from 1000 (default) to 100, I hit the problem sooner (waits for problem hit are in order of n*10minutes). It looks to me that PM autosupend is playing some role here. Power management options in my .config: # CONFIG_SUSPEND is not set # CONFIG_PM is not set CONFIG_ARCH_SUSPEND_POSSIBLE=y I intentionally did not put all detail descriptions of embedded system and test setup here (long list), because the main reason of this post is: The workaround that works for me/customer (at the moment) is to disable PM autosuspend in the driver code, either by incerementing PM delay from 1000 to 1 or by disabling autosuspend (comment out call to pm_runtime_put_autosuspend() in xiic_xfer()). But, I would like to expose/discuss this issue (maintainer of the code, or others). The reason/source of the problem can be much more complex and in some other place. So my question is who should I contact, is this the M: in the MAINTAINERS list, the MODULE_AUTHOR, ...? How to proceed. WBR Primoz ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Update: I2C bus driver TIMEDOUT because of PM autosuspend
I must update my report. It is not PM autosuspend (void calls do nothing, no miracle here). This morning I reproduced the I2C timeout error also with XIIC_PM_TIMEOUT=1 delay. For several days some other change was misleading me to PM autosuspend conclusion. What looks to me now is that just slight change in driver code (e.g. add or remove dev_info() call) changes the execution timing pattern of driver and this then determine if the problem probability window is hit or not. Probability to hit the problem is very low. The driver timeout error and its result to I2C bus blocked is still a problem. I would still like to let the maintainer aware of this problem. ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
I2C bus driver TIMEDOUT because of PM autosuspend
I am analysing a problem with I2C bus driver where the problem shows up as I2C bus completely blocked. The LX driver in question is /drivers/i2c/busses/i2c-xiic.c. This driver is for FPGA based I2C controller. Problem is difficult to reproduce, it happens very rarely. So far I saw that the main precondition is to have very heavy I2C traffic on bus. In my case this is achieved/reproduced via netdev driving SFP LEDs via /sys/class/leds/ (via gpio-pca953x). I generate traffic with iperf3. Network traffic is on 10Gbps EMAC. LX kernel is 4.14.0, ARM64, dual core CPU, 2Gbyte mem. What I saw from debugging this problem, is that I2C bus gets in this blocked state when wait_event_timeout() completes because of timeout. The timeout error handling in this driver is probably not robust enough (bus should not remain blocked because of error), but at this moment this are just my speculations (don't know enough details). Looking the data on oscilloscope, I saw that SCL in single I2C data transfer (several messages) sequence can be interrupted for very long delays, e.g up to hundredths of usec (SCL is 100kHz). There are only two delays in driver code, first in wait_event_timeout and second in set autosuspend delay. I started to suspect that PM autosuspend delay could play some role here. Case is a bit strange because in very busy I2C traffic, PM autosuspend should not be triggered at all. Additionally, if I lower PM timeout, e.g. from 1000 (default) to 100, I hit the problem sooner (waits for problem hit are in order of n*10minutes). It looks like PM autosupend is playing some role here. Power management options in my Linux kernel build .config: # CONFIG_SUSPEND is not set # CONFIG_PM is not set CONFIG_ARCH_SUSPEND_POSSIBLE=y It is not logical (PM is not configured, PM runtime calls are void/empty calls), but this case is repeatedly reproduced on my test setup: XIIC_PM_TIMEOUT=1000 (or less) -> I2C timeout error, bus blocked XIIC_PM_TIMEOUT=1 -> No I2C timeout error I tried also to build i2c-xiic driver with kernel build defaults and without optimizations (ccflags-y += -O0 -g) and also as in-kernel and as loadable module. Always the same test results. The workaround that works at the moment is to change PM delay from 1000 (default) to 1. Doing so I don't reproduce the problem (24h runs ok), but honestly I don't believe this is fix. More likely the problem is some coincidence timing issue, somewhere. I intentionally did not put all detail descriptions of embedded system and test setup here (long list), because the main reason of this post is: I would like to expose/discuss this issue (maintainer of the code, or others). The reason/source of the problem can be much more complex and in some other place. So my question is who should I contact, is this the M: in the MAINTAINERS list, the MODULE_AUTHOR, ...? How to proceed. WBR Primoz ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
