tinydrm: page allocation failure

Noralf Trønnes noralf at tronnes.org
Thu Dec 14 19:55:31 UTC 2017


Den 14.12.2017 17.25, skrev David Lechner:
> On 12/11/2017 06:45 AM, Noralf Trønnes wrote:
>>
>> Den 11.12.2017 04.28, skrev David Lechner:
>>> I'm using drm-misc/drm-misc-next and occasionally getting errors as 
>>> seen in the stack traces below. I'm not really sure what to make of 
>>> it. Any ideas?
>>>
>
> I'm starting to wonder if there is some sort of race condition 
> involved. I only get this warning on some boots, but when I do, it 
> happens multiple times. Also, when I was debugging a an unrelated 
> problem, I enabled some of the spin lock checking kernel options that 
> really slow down the kernel. When I did this, I got this warning all 
> of the time.
>
> Would it be sensible to allocate a dummy RX buffer once instead of 
> letting SPI allocate a new one for every transfer?
>

I have looked at the code and the dummy buffer is needed by some
drivers for DMA transfers. They need both tx and rx buffers to do the
transfer. A solution might be to let tinydrm allocate a dummy rx buffer
and attach it to every spi_transfer.

We could check if it's really needed:

     if (spi->controller->flags & (SPI_CONTROLLER_MUST_RX | 
SPI_CONTROLLER_MUST_TX))
         // allocate dummy rx buffer

And maybe something like this:

+ * @dummy_rx_buf: Optional dummy rx buffer to avoid per transfer 
allocation of
+ *                dummy rx buffers in the spi core.

  int tinydrm_spi_transfer(struct spi_device *spi, u32 speed_hz,
               struct spi_transfer *header, u8 bpw, const void *buf,
-             size_t len)
+             size_t len, void dummy_rx_buf)
  {
      struct spi_transfer tr = {
          .bits_per_word = bpw,
          .speed_hz = speed_hz,
+        .rx_buf = dummy_rx_buf,
      };

Noralf.

>>
>> The spi controller driver has told the spi core to allocate dummy
>> buffers for tx/rx: spi_sync -> __spi_pump_messages -> spi_map_msg
>> -> krealloc -> __do_krealloc -> kmalloc_track_caller
>>
>> order:4 means it's trying to allocate 2^4*PAGE_SIZE = 64kB, which
>> probably is the max DMA limit. So this is a pixel data transfer.
>>
>> On my Raspberry Pi I've got 43 chunks of 64kB available if I have
>> understood this right:
>>
>> $ sudo cat /proc/buddyinfo
>> Node 0, zone   Normal     40     68     66     51     43     46 13 
>> 1      3      3     75
>>
>> I don't know what those dummy buffers are used for.
>>
>> Noralf.
>>



More information about the dri-devel mailing list