Kernel Linux: udelay() restituisce troppo presto?

Question

Ho un driver che richiede ritardi al microsecondo. Per creare questo ritardo, il mio driver sta usando la funzione udelay del kernel. Nello specifico, c'è una chiamata a udelay (90):

iowrite32(data, addr + DATA_OFFSET); 
iowrite32(trig, addr + CONTROL_OFFSET); 

udelay(30); 

trig |= 1; 
iowrite32(trig, addr + CONTROL_OFFSET); 

udelay(90); // This is the problematic call 

Abbiamo riscontrato problemi di affidabilità con il dispositivo. Dopo un sacco di debug, abbiamo rintracciato il problema alla ripresa del driver prima che sia passato 90 secondi. (Vedere "prova" di seguito.)

Sto eseguendo la versione del kernel 2.6.38-11 SMP generico (Kubuntu 11.04, x86_64) su un Intel Pentium Dual Core (E5700).

Per quanto ne so, la documentazione afferma che udelay ritarderà l'esecuzione di almeno il ritardo specificato ed è ininterrotta. C'è un bug in questa versione del kernel o ho frainteso qualcosa sull'uso di udelay?

---

Per convincerci che il problema è stato causato da udelay ritorno troppo presto, abbiamo alimentato un orologio 100kHz a una delle porte di I/O e implementato il nostro ritardo come segue:

// Wait until n number of falling edges 
// are observed 
void clk100_delay(void *addr, u32 n) { 
    int i; 

    for (i = 0; i < n; i++) { 
     u32 prev_clk = ioread32(addr); 
     while (1) { 
      u32 clk = ioread32(addr); 
      if (prev_clk && !clk) { 
       break; 
      } else { 
       prev_clk = clk; 
      } 
     } 
    } 
} 

... e l'autista ora funziona perfettamente.

---

Come nota finale, ho trovato a discussion che indica che l'adattamento della frequenza potrebbe essere la causa della famiglia * ritardo() di funzioni a comportarsi male, ma questo era su un braccio mailing list - ho ammesso questi problemi sarebbe non- esistente su un PC Linux x86.

Answer 1

E5700 ha X86_FEATURE_CONSTANT_TSC ma non X86_FEATURE_NONSTOP_TSC. Il TSC è la probabile sorgente di clock per lo udelay. A meno che non sia associato a uno dei core con una maschera di affinità, il tuo compito potrebbe essere stato preventivato e ripianificato su un'altra CPU durante lo udelay. Oppure il TSC potrebbe non essere stabile durante le modalità di CPU a potenza più bassa.

Si può provare a disabilitare gli interrupt o disabilitare la prelazione durante il udelay? Inoltre, prova a leggere il TSC prima e dopo.

Answer 2

Non conosco alcun bug in quella versione del kernel (ma ciò non significa che non ce ne sia uno).

udelay() non è "uninterruptible" - non disabilita la prelazione, quindi il task può essere preimpostato da un task RT durante il ritardo. Tuttavia, lo stesso vale per l'implementazione del ritardo alternativo, quindi è improbabile che questo sia il problema.

Il tuo problema potrebbe essere un problema di coerenza DMA/ordine di memoria? L'implementazione del ritardo alternativo accede al bus, quindi questo potrebbe nascondere il problema reale come un effetto collaterale.