[BUG] I2C & SPI Tool crash system with SMP enabled

[MainframeReboot]

Description / Steps to reproduce the issue

Using the MPFS Icicle-kit with NuttX in Kernel mode, the I2C and SPI tools cause a full system crash when these tools are run and SMP is enabled.

Below is an image of the I2C bus scan performed on NuttX 12.9 (tagged release) with SMP disabled:

When SMP is enabled, the same command results in:

This issue has been present since release 12.8 but I managed to hack around the problem in the I2C tool by replacing the following function:

static int mpfs_i2c_sem_waitdone(struct mpfs_i2c_priv_s *priv)
{
  uint32_t timeout = mpfs_i2c_timeout(priv->msgc, priv->msgv);
  return nxsem_tickwait_uninterruptible(&priv->sem_isr, USEC2TICK(timeout));
}

With one that avoids the nxsem_tickwait_uninterruptible call and uses an atomic variable to lock out the driver:

static int mpfs_i2c_sem_waitdone(struct mpfs_i2c_priv_s *priv)
{
  int32_t timeout = mpfs_i2c_timeout(priv->msgc, priv->msgv);
  clock_t end = clock_systime_ticks() + timeout + 1;
  int ret;

  for (; ; )
  {
      if (atomic_load(&priv->transfer_lock))
      {
        ret = OK;
        break;
      }

      timeout = end - clock_systime_ticks();
      if (timeout < 0)
      {
          ret = -EINTR;
          break;
      }
    }

  atomic_store(&priv->transfer_lock, false);
  return ret;
}

I get that this is a dirty hack but I just needed a quick way to poke around in registers of an I2C device from the nsh terminal and as such it did the job. However, since moving to NuttX 12.9, the issue is not only still present, but it has now also manifested itself in the SPI tool, The dirty hack above also no longer works.

Can anyone shed light on what is going on here? Am I possibly missing a config value? I'm concerned that everything is set up correctly but something isn't working quite right deeper in NuttX, I just haven't had much time to dive into all of the changes between the versions.

On which OS does this issue occur?

[OS: Linux]

What is the version of your OS?

Ubuntu 22.04.4

NuttX Version

12.9, 12.8

Issue Architecture

[Arch: risc-v]

Issue Area

[Area: OS Components]

Host information

No response

Verification

• I have verified before submitting the report.

[acassis]

@MainframeReboot the exception 0x0d means "load page fault", so I suggest you to find the root cause using GDB. Also you can try older version than 12.8 (I think MPFS I2C support was present in previous versions as well) and you can use git bisect applying your workaround between 12.8 and 12.9 to spot which modification prevented it from working.

[MainframeReboot]

It's been a while since this ticket was posted but I have come across the solution to this issue, although it may impact more than just the mpfs boards and risc-v architecture.

Essentially what is happening is that in kernel mode, the I2C tool is running in user space and passing down user space read and write buffers. When the I2C transaction occurs on the mpfs platform, it is interrupt driven but still uses the user space buffers. This still worked with no SMP enabled in my test cases as it was the only application running and the CPU sat waiting for the transaction to complete. Once SMP was enabled, the moment the interaction started and the semwait was called, CPU0 ran off to do other work and once the interrupt for the I2C was received, CPU1 took over. Since CPU1 has no idea about the read and write buffers passed down to the I2C driver from the I2C tool, it would throw the load page fault.

The interim solution to fix this was to have kernel space buffers that copied the read and write data from user space. This ensured no matter which CPU ended up servicing the interrupt, the data was always available.

However, this is something can occur on any platform/driver if NuttX is run in kernel mode and an application passes down a user space buffer. In Unix, copy_to_user() and copy_from_user() functions exist for this reason. Is this something that should be added to NuttX or is the current approach to just ensure the kernel drivers contain their own buffers that they copy data from user space to?