Kernelspace - SPI Write/Read Funktion - Mutex

[Markus R. (mark989)]

Hallo,
bei meinem Netzwerk/SPI Linuxtreibermodul wird die Funktion die die SPI 
Zugriffe ausführt von mehreren Threads aufgerufen. Mit welcher 
Technologie ist es am besten sie zu schützen(Mutex/Semaphore...)?  , 
heißt damit nicht gleichzeitig, sondern nacheinander zugegriffen wird?
Mein erster Anzatz:

int TPS_SendRecv(u8* transmit, unsigned short length, u8* receive){

  struct spi_message msg;
  int ret = 0;
  int i;
  mutex_lock(&tpsmutex);
  for(i = 0; i < length; i++){

          struct spi_transfer t = {
                   .tx_buf = transmit +i,
                   .rx_buf = receive  +i,
                   .len = 1,
         };

          spi_message_init(&msg);
          spi_message_add_tail(&t, &msg);

          ret = spi_sync(tps->spi, &msg);

          gpio_set_value(HOST_SFRN, 1);
          gpio_set_value(HOST_SFRN, 0);

          if (ret){
                  printk( "SPI transmission failed: ret = %d\n", ret);
                  break;
          }
    }
    mutex_unlock(&tpsmutex);
    return 0;
}

So bekommen ich bei mehrfachen Zugriff folgenden Fehler:
BUG: scheduling while atomic: dhclient

Danke für jede Hilfe

[Funko B. (funkobongrip)]

"A successful call for a mutex lock by way of mutex_lock() will cause 
another thread that is also trying to lock  the same  mutex  to  block 
until  the  owner  thread  unlocks it by way of mutex_unlock(). Threads 
within the same process or  within  other  processes can share mutexes."

Ergo wird so beim zweiten Call der Kernelthread geblockt, was natürlich 
keine gute Idee ist. Ist zwar lange her, aber wenn ich mich recht 
erinnere willst du da eher mutex_trylock benutzen und dann später 
nochmal versuchen. (Daten ggfs. queuen)

[Andreas H. (ahz)]

David Brandt schrieb:
> Ergo wird so beim zweiten Call der Kernelthread geblockt, was natürlich
> keine gute Idee ist.

Aber genau das ist doch dass, was man hier will. Der zweite Thread 
wartet bis der erste fertig ist und gibt den Mutex freigibt.
Ein TryLock würde ja nur feststellen, dass der Mutex schon benutzt wird 
und dann müsste man selber immer wieder nachfragen.

Oder steh ich da gerade auf dem Schlauch ?

Grüße
Andreas

[Postix (Gast)]

Zuerst einmal musst du feststellen, wo genau der Fehler "BUG: scheduling 
while atomic: dhclient" auftritt. Ist es der mutex_lock den du hier 
machst der in einer der von dir aufgerufenen Funktionen? Zur 
Fehlermeldung hilft ein wenig googeln, da kommt zum Beispiel das hier 
raus: 
http://stackoverflow.com/questions/3537252/how-to-solve-bug-scheduling-while-atomic-swapper-0x00000103-0-cpu0-in-ts

Wenn wir dem folgen kommt die Frage auf: In welchem Kontext laeuft deine 
Funktion? Ist da mitunter schon ein Spinlock oder Aehnliches aktiv? Und 
so weiter...

[Hans Ulli K. (Gast)]

Markus R. schrieb:
>
> So bekommen ich bei mehrfachen Zugriff folgenden Fehler:
> BUG: scheduling while atomic: dhclient
>
> Danke für jede Hilfe

Kommt der Fehler nihct aus dem Userspace ??
dhclient ??

[Andreas B. (andreas_b77)]

Hans Ulli Kroll schrieb:
> Kommt der Fehler nihct aus dem Userspace ??
> dhclient ??

Definitiv nicht. dhclient ist der aktuell laufende Prozess beim 
Auftreten des Bugs. In diesem Fall wird es wohl durch einen Systemaufruf 
von dhclient ausgelöst worden sein, ist aber immer noch ein Bug im 
Kernel-Code.

[Hans Ulli K. (Gast)]

Andreas B. schrieb:
> Definitiv nicht. dhclient ist der aktuell laufende Prozess beim
> Auftreten des Bugs. In diesem Fall wird es wohl durch einen Systemaufruf
> von dhclient ausgelöst worden sein, ist aber immer noch ein Bug im
> Kernel-Code.

Habe ich jetzt auch selber gefunden ...

Lesefutter
http://ubuntuforums.org/showthread.php?t=1718667
http://stackoverflow.com/questions/3537252/how-to-solve-bug-scheduling-while-atomic-swapper-0x00000103-0-cpu0-in-ts

Im Endeffekt den kompletten Code nochmal genau duchlesen