Administrace komentářů

Hele tohle naopak s přerušením souvisí. Sice nemusí být ty errory s přerušením zdroj chyby ale jen symptom, ale souviset to IMO bude. BTW chování, kdy je na jednom přerušení jen jedno zařízení se může teoreticky zpracovávat jinak (a hláška nebude vypisována).

Poslední řádky logu bude nějaké hlášení o obsazenosti nějakého FIFO na komunikaci s jádry na GPU. "Head" bude start platných dat a "Count" obsazenost té fronty. Jak vidíš, tak obsazenost roste a na hodnotě nejspíš 0x9fff se to zasekne. Vypadá to, že maximální délka té fronty bude 0xa000. Zároveň to vypadá, že nic z té fronty není odebíráno, protože to by pak rostla i "Head" hodnota. Obvykle jsou nová data ve frontě oznamována přerušením, takže pokud to přerušení něco ignoruje, tak nic ty data nebude odebírat.

Je to teda jen hypotéza, ale něco podobnýho dělala i nějaká prehistorická ATI radeon (se kterým jsem si tuhle hrál) a ručně se jí vypne IRQ (její opensource driver má ale dost ochranných mechanismů aby se nesekl systém).

Jestli to pravidelně mrzne do třeba 10 minut, tak zkus ukládat výpisy z /proc/interrupts. Podle zběžného pohledu do kernelu by tam měly být obrovské hodnoty u spurious interrupts (ta hláška ze začátku se vypíše snad až při 10k ignorovanejch přerušení).

P.S. Sice tohle je jen hypotéza, ale alespoň by to mohlo pomoct při nahlašování té chyby nějakému maintaineru nvidia blobu.