Skip to content

Releases: Deniz-Eren/dev-can-linux

Release version 1.5.0

18 Sep 04:24
Compare
Choose a tag to compare

Update driver and harmonize with Linux kernel v6.11

  • Bumped PROGRAM_VERSION to 1.5.0
  • Bumped HARMONIZED_LINUX_VERSION to 6.11
  • Minor changes pulled from Linux kernel v6.11

Release version 1.4.0

15 Jul 07:27
Compare
Choose a tag to compare

Update driver and harmonize with Linux kernel v6.10

  • Bumped PROGRAM_VERSION to 1.4.0
  • Bumped HARMONIZED_LINUX_VERSION to 6.10
  • Minor changes pulled from Linux kernel v6.10

Release version 1.3.5

10 Jul 02:29
Compare
Choose a tag to compare

Fix for bug #73

  • Implemented command-line option '-R' to allow for Bus error state recovery; particularly for Error Passive State issues.
  • Removed legacy debug asserts in netif_wake_queue() and netif_stop_queue(); these were only active for Debug builds.
  • Fixed a bug in command-line help option '-r'; it was still '-b' from prior changes.
  • Moved Jenkins CI from docker-compose package to docker-compose-v2 package
  • Fixed comment block issue in startup-properties.groovy

Release version 1.3.4

29 May 06:37
Compare
Choose a tag to compare

Fix for bug #71

  • When no CAN-bus device is detected, the driver will nicely exit, giving the message no devices detected

Release version 1.3.3

28 May 23:57
Compare
Choose a tag to compare

Fix for bug #68

Support module parameters

  • Option -m added to manage kernel module parameters.
  • Implemented external_clk configuration of driver drivers/net/can/sja1000/f81601.
  • Fixed a logging issue that can happen only during the parsing of command-line arguments.
  • Reworded some error messages to be more helpful.

Release version 1.3.2

21 May 05:16
Compare
Choose a tag to compare

Fix for bug #66

Rare race condition found in void* rx_loop (void* arg) impacting cleaning up blocked clients during file close.

Release version 1.3.1

19 May 01:59
Compare
Choose a tag to compare

Added full support for Fintek F81601 PCIe to 2 CAN controller driver.

Release version 1.3.0

17 May 06:54
Compare
Choose a tag to compare

Update driver and harmonize with Linux kernel v6.9

  • Bumped PROGRAM_VERSION to 1.3.0
  • Bumped HARMONIZED_LINUX_VERSION to 69 (v6.9)
  • Some improvements to CAN device restart for bus-off recovery.
  • Some changes to include/linux/minmax.h
  • Other minor improvements and code clean-up.

Release version 1.2.4

17 May 03:26
Compare
Choose a tag to compare

Fix for bug #56

No specific or hardcoded limits of 65536 or 2^16 exist in the code base.

Initial suspicion was that open/close results in a client session being created and destroyed. Client sessions have with them an RX thread per connection client (via open) to deliver the received messages. The QNX OS limit of maximum number of threads per process is known to be 32767, so we investigated whether the threads were not being cleaned up properly. This wasn't the case however, and all the threads created are detached and cleanly shutdown.

The further test this theory an experiment was done. Driver dev-can-linux was started and while monitoring the number of threads active using command "pidin -p pid" messages were sent using command "cansend -u0,tx0 -m0x1234,1,0xABCD". No increase in the number of threads noted.

Next to replicate the example code given in #57, i.e. "void *fctThreadCan3( void *arg )", we wrote a new unit test SingleSendReceiveAfterManyOpenClose in tests/driver/io/driver-io-tests.cpp to perform the same test as test SingleSendReceive but only after opening and closing the file descriptors 100,000 times.

Exact problem described was successfully replicated by test SingleSendReceiveAfterManyOpenClose. After running the test the command "candump -u0,rx0" no longer recieves messages from command "cansend -u0,tx0 -m0x1234,1,0xABCD".

The error message "rx_loop exit: Unable to attach to channel." was noted during the test produced from src/resmgr.c#L656

The problem was identified to be in rx_loop whereby the message_connect() was never being disconnected. After adding the correct disconnection the problem is shown to be fixed.

Further improvements added by making the rx_loop thread non-detached so that on close we can pthread_join() to clean-up smoother.

Release version 1.2.3

16 May 07:05
Compare
Choose a tag to compare

Recommendations from QNX support implemented regarding interrupt handling of different types of devices.

  • When working with regular IRQ or legacy MSI devices that are handled at the regular IRQ level, we use InterruptAttachEvent to minimize Kernel called ISR code. Additionally, InterruptAttachEvent will already mask the regular IRQ.
  • When working with MSI supported (with PVM) or MSI-X supported devices, we want to use InterruptAttach. This is because InterruptAttachEvent would mask the regular IRQ assoicated with the device. We definitely want to avoid doing that and instead we want to benefit from the MSI/MSI-X PVM support. As such, in this case we cannot avoid implementing an ISR, which the Kernel will call.
  • Deleted configuration options CONFIG_QNX_INTERRUPT_ATTACH and CONFIG_QNX_INTERRUPT_ATTACH_EVENT after resolving the ambiguity with QNX support regarding the question of which type of interrupt attach function should be used for different types of devices.
  • Furthermore, removed the deprecated code for when the ISR implementation performs the work of interrupt handling; i.e. use of intrspin_t, InterruptLock and InterruptUnlock all removed.
  • Fixed regression in building scripts to allow project to be developed and built using Momentics. Removed IRQ_SCHED_PRIORITY_BOOST definition from CMakeLists.txt and instead introduced the shared config CONFIG_IRQ_SCHED_PRIORITY_BOOST to handle the schedule priority of transmission and interrupt processing value.
  • Refactored regular IRQ and legacy MSI IRQ mask/unmask functions.
  • Updated workspace to include PCI MSI capability enabled devices to emulation environment.