mediaclient haengt sporadisch beim Tunen

[sparkie]

Hallo Sundtek Support,

ein kleines Problem, das ich seit Monaten beobachte. Es scheint aber mit der halbwegs aktuellen Installation 'sundtek_installer_120720.2210.sh' noch schlimmer geworden zu sein.

Wie hier etwas naeher beschrieben nutze ich einen Sundtek MediaTV Pro (USB 2.0) um die Auslastung im Kabelsegment zu monitoren. Das funktioniert an sich alles hervorragend.

Dabei stelle ich mit mediaclient erst eine der moeglichen Frequenzen (546.0 554.0 562.0 570.0 578.0 586.0 594.0 602.0)  ein und messe anschliessend mit 'dvbtraffic' die Auslastung.

Dabei kommt es oft nach Stunden sporadisch vor, dass der Aufruf von '/opt/bin/mediaclient' aus meinem Script heraus haengt.

Gerade ist es wieder aufgereten:

CMD: /bin/bash -c '/opt/bin/mediaclient -d /dev/dvb/adapter0/frontend0 -m DVBC -f 562000000 -M Q256 -S 6952000' 2>&1
scanning output for: <(\[LOCKED\]|unable to open device node:|doesn't support the extended media)>
first match: <[LOCKED]>

###
### dieses Frequenz 562000000 liess sich noch tunen (er bekommt also ein LOCKED)
###

CMD: /bin/bash -c 'LD_PRELOAD=/opt/lib/libmediaclient.so /bin/dvbtraffic -oa 0' 2>&1
scanning output for: <^2000 .* ([0-9]+) kbit$>
first match: <33613>

###
### Auslastung auslesen
###

CMD: /bin/bash -c '/opt/bin/mediaclient -d /dev/dvb/adapter0/frontend0 -m DVBC -f 570000000 -M Q256 -S 6952000' 2>&1
scanning output for: <(\[LOCKED\]|unable to open device node:|doesn't support the extended media)>

###
### und hier beim Tunen auf die naechste Frequenz (570000000) haengt der mediaclient. Es kommt kein LOCKED mehr
###

im Logfile ist dabei folgendes zu sehen:

/var/log/mediasrv.log:
2012-08-04 16:23:39 [23320] Enabling standby
2012-08-04 16:24:08 [23320] SETTING DVB-C
2012-08-04 16:24:08 [23320] reinitializing previous digital TV parameters
2012-08-04 16:24:08 [23320] Setting Frequency: 602000000
2012-08-04 16:24:08 [23320] Setting Symbolrate: 6952000
2012-08-04 16:24:08 [23320] Setting Modulation: 5
2012-08-04 16:24:10 [23320] Setting Frequency: 546000000
2012-08-04 16:24:10 [23320] Setting Symbolrate: 6952000
2012-08-04 16:24:10 [23320] Setting Modulation: 5
2012-08-04 16:24:13 [23320] Channel found (546000000)
2012-08-04 16:24:13 [23320] =============
2012-08-04 16:24:13 [23320] Symbol rate: 6951998
2012-08-04 16:24:13 [23320] Constellation: QAM256
2012-08-04 16:24:13 [23320] Mirroring: Mirrored
2012-08-04 16:24:13 [23320] Disabling HW PID Filter
2012-08-04 16:24:13 [23320] TS Sync byte not aligned, realigning stream (0 // 0)
2012-08-04 16:24:13 [23320] TS Sync byte not aligned, realigning stream (0 // 0)
2012-08-04 16:24:14 [23320] Setting Frequency: 554000000
2012-08-04 16:24:14 [23320] Setting Symbolrate: 6952000
2012-08-04 16:24:14 [23320] Setting Modulation: 5
2012-08-04 16:24:19 [23320] Channel found (554000000)
2012-08-04 16:24:19 [23320] =============
2012-08-04 16:24:19 [23320] Symbol rate: 6951997
2012-08-04 16:24:19 [23320] Constellation: QAM256
2012-08-04 16:24:19 [23320] Mirroring: Mirrored
2012-08-04 16:24:19 [23320] Disabling HW PID Filter
2012-08-04 16:24:19 [23320] TS Sync byte not aligned, realigning stream (0 // 0)
2012-08-04 16:24:19 [23320] TS Sync byte not aligned, realigning stream (0 // 64)
2012-08-04 16:24:19 [23320] TS Sync byte not aligned, realigning stream (224 // 64)
2012-08-04 16:24:21 [23320] Setting Frequency: 562000000
2012-08-04 16:24:21 [23320] Setting Symbolrate: 6952000
2012-08-04 16:24:21 [23320] Setting Modulation: 5
2012-08-04 16:24:23 [23320] Channel found (562000000)
2012-08-04 16:24:23 [23320] =============
2012-08-04 16:24:23 [23320] Symbol rate: 6951998
2012-08-04 16:24:23 [23320] Constellation: QAM256
2012-08-04 16:24:23 [23320] Mirroring: Mirrored
2012-08-04 16:24:23 [23320] Disabling HW PID Filter
2012-08-04 16:24:23 [23320] TS Sync byte not aligned, realigning stream (0 // 0)
2012-08-04 16:24:23 [23320] TS Sync byte not aligned, realigning stream (189 // 0)
2012-08-04 16:24:23 [23320] TS Sync byte not aligned, realigning stream (0 // 64)
2012-08-04 16:24:23 [23320] TS Sync byte not aligned, realigning stream (202 // 64)
2012-08-04 16:24:24 [23320] Setting Frequency: 570000000
2012-08-04 16:24:24 [23320] Setting Symbolrate: 6952000
2012-08-04 16:24:24 [23320] Setting Modulation: 5
2012-08-04 16:24:35 [23320] Channel found (570000000)
2012-08-04 16:24:35 [23320] =============
2012-08-04 16:24:35 [23320] Symbol rate: 6951997
2012-08-04 16:24:35 [23320] Constellation: QAM256
2012-08-04 16:24:35 [23320] Mirroring: Mirrored
--- ende ---
###
### hier haengt das Teil
### der Stick geht auch nicht mehr in den Standby wenn das Ganze hier mal haengt.
###

vielleicht weiss jemand Rat. Danke schon mal im Vorus.

- sparkie

[Sundtek]

Was zeigt denn dmesg an?

Woran steckt der Stick denn?

Wenn sich der USB Stack vom jeweiligen Kernel weghängt kann es durchaus zu Hängern kommen.
Die Treiber wurden um diesen Zeitpunkt 120720 umgestellt damit wir sie auch in Zukunft weiter unterstützen können.


Mittlerweile wird das Treiberpaket mit mehreren verschiedenen Treibern ausgeliefert, wenn du mir das Skript lieferst kann ich das bei uns mal eine Zeit lang laufen lassen.

[sparkie]

WOW - Samstag Support - danke

Was zeigt denn dmesg an?

da ist schon 3 Stunden (vor dem Haenger) kein Eintrag mehr erfolgt. Auch in sonstigen Logfiles keine Auffaelligkeiten.

Woran steckt der Stick denn?

in einem Asus P8H61-I mit Debian Squeeze. System laeuft seit Wochen rockstable.

- sparkie

[sparkie]

achja, das ist ja witzig. Wenn ich einen 'strace -p #' auf den mediaclient starte dann detached er sich vom strace und alles geht ganz normal weiter

mit diesen Log-Lines:

2012-08-04 16:24:35 [23320] Constellation: QAM256
2012-08-04 16:24:35 [23320] Mirroring: Mirrored

###
### letzte Zeile vor dem Hang (siehe oben)
###

2012-08-04 16:43:06 [23320] Channel found (570000000)
2012-08-04 16:43:06 [23320] =============
2012-08-04 16:43:06 [23320] Symbol rate: 6951987
2012-08-04 16:43:06 [23320] Constellation: QAM256
2012-08-04 16:43:06 [23320] Mirroring: Mirrored
2012-08-04 16:43:06 [23320] Disabling HW PID Filter
2012-08-04 16:43:06 [23320] TS Sync byte not aligned, realigning stream (0 // 0)
2012-08-04 16:43:07 [23320] Setting Frequency: 578000000
2012-08-04 16:43:07 [23320] Setting Symbolrate: 6952000
2012-08-04 16:43:07 [23320] Setting Modulation: 5
2012-08-04 16:43:08 [23320] Channel found (578000000)
2012-08-04 16:43:08 [23320] =============
2012-08-04 16:43:08 [23320] Symbol rate: 6951987

[Sundtek]

Versuch das mal mit dem aktuellen Treiber.

[sparkie]

Versuch das mal mit dem aktuellen Treiber.

ok, alles klar! Ich werde das leider heute nicht mehr schaffen. Aber ich werde das Ergebnis dann hier demnaechst posten.

Vielen Dank und schoenen Samstag noch!

- sparkie

[Sundtek]

Lässt sich der Treiber denn einfach Stoppen? (ohne den Stick neu anzuschliessen!)

[sparkie]

Lässt sich der Treiber denn einfach Stoppen? (ohne den Stick neu anzuschliessen!)

zu welchem Zeitpunkt ist das gemeint? Das System haengt ja nun nach dem strace leider nicht mehr. Aber stimmt, es verhaelt sich alles etwas eigenartig.
Wenn ich jetzt mache:

/opt/bin/mediaclient --shutdown

dann haengt der auch.

/opt/bin/mediaclient --shutdown
Shutting down Multimedia Stack
###
### haengt hier, laesst sich aber z.B. mit SIGTERM beenden.
###


Stick wechselt nicht mehr in den Standby. Und die beiden '/opt/bin/mediasrv' laufen munter weiter. Dabei habe ich meine Applikation vorher gestoppt.

Der Stick steckt seit Tagen. Den haenge ich normal nicht ab. Kann es bei Bedarf aber machen.

Mittlerweile wird das Treiberpaket mit mehreren verschiedenen Treibern ausgeliefert, wenn du mir das Skript lieferst kann ich das bei uns mal eine Zeit lang laufen lassen.

das wuerde ich gerne machen. Aber das Script ist Bestandteil einer groesseren Umgebung mit awk-Libraries etc. Das kann man nicht einfach nur starten. Ich glaube das waere zu aufwaendig, wenn ihr das bei euch zum Laufen bringen wollt. Aber ich kann euch die Sourcen schon ueberspielen wenn ihr euch das antun wollt

[Sundtek]

kann man mediasrv noch mittels killall -9 mediasrv stoppen (wie erwähnt ohne den Stick neu anzuschliessen)?

Sieht sehr nach einem Problem des USB Stacks auf dem System aus, was für ein Kernel wird dort denn verwendet?

[sparkie]

kann man mediasrv noch mittels killall -9 mediasrv stoppen (wie erwähnt ohne den Stick neu anzuschliessen)?

das hatte ich gestern noch gemacht, bevor ich weg musste. Der mediasrv ist dabei noch als Zombie '<defunct>' herumgehangen. Das System war aber kurze Zeit spaeter nicht mehr zu gebrauchen. Ping ging noch aber aber kein login mehr. Xserver war ohne Reaktion.

Sieht sehr nach einem Problem des USB Stacks auf dem System aus, was für ein Kernel wird dort denn verwendet?

es ist der aktuelle Standard debian 6.0 (squeeze) Kernel ("2.6.32-5-amd64").

ich habe erst mal noch keinen neuen sundtek Treiber installiert. Ich beobachte das Ganze noch ein wenig.

Wenn ihr noch eine Todo-Liste habt was ich machen soll wenn das Ganze wieder haengt (kann aber durchaus Tage dauern), bitte hier posten.

Zu meinem Script. Ich mache eigentlich nichts anderes als der Reihe nach alle 8 Frequenzen einzustellen. Der dvbsnoop/dvbtraffic dawischen ist vermutlich nicht interessant. Wenn alle 8 Frequenzen durch sind geht der STick noch kurz in den powersave. Das Ganze wiederholt sich minuetlich. Sinngemaess sind das Script so aus:

Code: [Auswählen]

while :; do
    /opt/bin/mediaclient -d /dev/dvb/adapter0/frontend0 -m DVBC -f 546000000 -M Q256 -S 6952000
    LD_PRELOAD=/opt/lib/libmediaclient.so /bin/dvbtraffic -oa 0
    /opt/bin/mediaclient -d /dev/dvb/adapter0/frontend0 -m DVBC -f 554000000 -M Q256 -S 6952000
    LD_PRELOAD=/opt/lib/libmediaclient.so /bin/dvbtraffic -oa 0
    /opt/bin/mediaclient -d /dev/dvb/adapter0/frontend0 -m DVBC -f 562000000 -M Q256 -S 6952000
    LD_PRELOAD=/opt/lib/libmediaclient.so /bin/dvbtraffic -oa 0
    /opt/bin/mediaclient -d /dev/dvb/adapter0/frontend0 -m DVBC -f 570000000 -M Q256 -S 6952000
    LD_PRELOAD=/opt/lib/libmediaclient.so /bin/dvbtraffic -oa 0
    /opt/bin/mediaclient -d /dev/dvb/adapter0/frontend0 -m DVBC -f 578000000 -M Q256 -S 6952000
    LD_PRELOAD=/opt/lib/libmediaclient.so /bin/dvbtraffic -oa 0
    /opt/bin/mediaclient -d /dev/dvb/adapter0/frontend0 -m DVBC -f 586000000 -M Q256 -S 6952000
    LD_PRELOAD=/opt/lib/libmediaclient.so /bin/dvbtraffic -oa 0
    /opt/bin/mediaclient -d /dev/dvb/adapter0/frontend0 -m DVBC -f 594000000 -M Q256 -S 6952000
    LD_PRELOAD=/opt/lib/libmediaclient.so /bin/dvbtraffic -oa 0
    /opt/bin/mediaclient -d /dev/dvb/adapter0/frontend0 -m DVBC -f 602000000 -M Q256 -S 6952000
    LD_PRELOAD=/opt/lib/libmediaclient.so /bin/dvbtraffic -oa 0
    sleep 45
done

das laeuft im Schnitt vielleicht 15 Stunden bis es haengt. Ist aber auch schon 2 Tage durchgelaufen.

- sparkie

[Sundtek]

Beobachte mal den aktuellen Treiber. Aktuell wurde das Problem nur von dir gemeldet.

Wichtig ist die Frage ob sich der Treiber komplett stoppen lässt (killall -9 mediasrv eventuell mehrfach). Falls nicht hat sich der USB Controller weggehangen und blockiert den USB Stick. Falls die Sticks noch auf Iso eingestellt sind schalte sie auf Bulk um "/opt/bin/mediaclient --dtvtransfermode=bulk" da dieser Modus unter Linux besser zu funktionieren scheint (falls es bereits auf Bulk eingestellt wurde, dann eventuell den Iso Modus einstellen "--dtvtransfermode=iso" (anschließend muss das Gerät neu angeschlossen werden.
Auch bei den USB Controller Treibern tut sich unter Linux immer wieder etwas, gerade bei 2.6.32.9 wurden Fehler behoben welche in den vorigen Releases von Suse hinzugefügt wurden.

[sparkie]

Beobachte mal den aktuellen Treiber. Aktuell wurde das Problem nur von dir gemeldet.

ok, die 120803.2038 ist jetzt installiert.

Wichtig ist die Frage ob sich der Treiber komplett stoppen lässt (killall -9 mediasrv eventuell mehrfach). Falls nicht hat sich der USB Controller weggehangen und blockiert den USB Stick.

werde ich pruefen, falls er nochmal haengen sollte

Falls die Sticks noch auf Iso eingestellt sind schalte sie auf Bulk um "/opt/bin/mediaclient --dtvtransfermode=bulk" da dieser Modus unter Linux besser zu funktionieren scheint (falls es bereits auf Bulk eingestellt wurde, dann eventuell den Iso Modus einstellen "--dtvtransfermode=iso" (anschließend muss das Gerät neu angeschlossen werden.

aktuell laufen die  noch auf "bulk" wie immer schon auf diesem System.  Ich moechte nicht zu viel auf einmal aendern. Aber habe es vorgemerkt.

wenn es was neues gibt poste  ich  wieder hier. Danke fuer den prompten Support!

- sparkie

[sparkie]

so, die "120803.2038" hat bis jetzt ueber 24 Stunden ohne Probleme durchgehalten. Wobei ich zum Installationszeitpunkt auch rebooten musste. Was die Situation vielleicht sowieso entschaerft hat.

Sieht also bis jetzt gut aus  Ich melde mich wieder wenn's was Neues gibt...

- sparkie

[sparkie]

leider gibt's jetzt was Neues, aber leider nichts Gutes. Nachdem die Kiste fast
7Tage ohne Probleme durchgelaufen ist, faengt es wieder an:

mediaclient haengt sporadisch.

Jetzt bin ich auf die Idee gekommen diesen mit Timeout aufzurufen, z.B:

Code: [Auswählen]

timeout 7 /opt/bin/mediaclient -d /dev/dvb/adapter0/frontend0...

das ging eine Weile sogar gut bis  dann  diese Meldungen im log auftreten:

Code: [Auswählen]

Aug 13 02:04:49 mach kernel: [387338.682111] INFO: task mediasrv:2174 blocked for more than 120 seconds.
Aug 13 02:04:49 mach kernel: [387338.682113] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
Aug 13 02:04:49 mach kernel: [387338.682115] mediasrv      D 0000000000000000     0  2174      1 0x00000000
Aug 13 02:04:49 mach kernel: [387338.682118]  ffffffff814891f0 0000000000000086 0000000000000000 0000000000000292
Aug 13 02:04:49 mach kernel: [387338.682120]  0000000000000292 ffffffff8119c24f 000000000000f9e0 ffff8802280e7fd8
Aug 13 02:04:49 mach kernel: [387338.682122]  0000000000015780 0000000000015780 ffff88023ac83170 ffff88023ac83468
Aug 13 02:04:49 mach kernel: [387338.682125] Call Trace:
Aug 13 02:04:49 mach kernel: [387338.682130]  [<ffffffff8119c24f>] ? map_single+0x17b/0x1e8
Aug 13 02:04:49 mach kernel: [387338.682133]  [<ffffffff8119c52b>] ? swiotlb_map_page+0x93/0xc4
Aug 13 02:04:49 mach kernel: [387338.682136]  [<ffffffff812fbe2d>] ? schedule_timeout+0x2e/0xdd
Aug 13 02:04:49 mach kernel: [387338.682154]  [<ffffffffa000def7>] ? usb_hcd_submit_urb+0x77e/0x86b [usbcore]
Aug 13 02:04:49 mach kernel: [387338.682156]  [<ffffffff812fbce4>] ? wait_for_common+0xde/0x15b
Aug 13 02:04:49 mach kernel: [387338.682160]  [<ffffffff8104a46c>] ? default_wake_function+0x0/0x9
Aug 13 02:04:49 mach kernel: [387338.682165]  [<ffffffffa000f576>] ? usb_start_wait_urb+0x71/0xb7 [usbcore]
Aug 13 02:04:49 mach kernel: [387338.682169]  [<ffffffffa000f7fa>] ? usb_control_msg+0x112/0x135 [usbcore]
Aug 13 02:04:49 mach kernel: [387338.682173]  [<ffffffffa00169d3>] ? usbdev_ioctl+0x31d/0x13ba [usbcore]
Aug 13 02:04:49 mach kernel: [387338.682176]  [<ffffffff8104828d>] ? finish_task_switch+0x3a/0xaf
Aug 13 02:04:49 mach kernel: [387338.682178]  [<ffffffff812fba70>] ? thread_return+0x79/0xe0
Aug 13 02:04:49 mach kernel: [387338.682180]  [<ffffffff81192d88>] ? rb_insert_color+0x66/0xe2
Aug 13 02:04:49 mach kernel: [387338.682183]  [<ffffffff81067c59>] ? lock_hrtimer_base+0x1b/0x3c
Aug 13 02:04:49 mach kernel: [387338.682185]  [<ffffffff81067cf2>] ? hrtimer_try_to_cancel+0x3a/0x43
Aug 13 02:04:49 mach kernel: [387338.682189]  [<ffffffff810faec3>] ? vfs_ioctl+0x56/0x6c
Aug 13 02:04:49 mach kernel: [387338.682190]  [<ffffffff810fb3dc>] ? do_vfs_ioctl+0x48d/0x4cb
Aug 13 02:04:49 mach kernel: [387338.682192]  [<ffffffff8106750f>] ? hrtimer_wakeup+0x0/0x22
Aug 13 02:04:49 mach kernel: [387338.682194]  [<ffffffff812fc52f>] ? do_nanosleep+0x4a/0xa3
Aug 13 02:04:49 mach kernel: [387338.682196]  [<ffffffff810fb46b>] ? sys_ioctl+0x51/0x70
Aug 13 02:04:49 mach kernel: [387338.682198]  [<ffffffff81010b42>] ? system_call_fastpath+0x16/0x1b
Aug 13 02:04:49 mach kernel: [387338.682200] INFO: task mediasrv:2175 blocked for more than 120 seconds.
Aug 13 02:04:49 mach kernel: [387338.682201] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
Aug 13 02:04:49 mach kernel: [387338.682202] mediasrv      D ffff880008a0fa20     0  2175      1 0x00000000
Aug 13 02:04:49 mach kernel: [387338.682204]  ffffffff814891f0 0000000000000086 0000000000000000 0000000000000292
Aug 13 02:04:49 mach kernel: [387338.682206]  0000000000000292 ffffffff8119c24f 000000000000f9e0 ffff8802280ebfd8
Aug 13 02:04:49 mach kernel: [387338.682208]  0000000000015780 0000000000015780 ffff88023ac846a0 ffff88023ac84998
Aug 13 02:04:49 mach kernel: [387338.682210] Call Trace:
Aug 13 02:04:49 mach kernel: [387338.682212]  [<ffffffff8119c24f>] ? map_single+0x17b/0x1e8
Aug 13 02:04:49 mach kernel: [387338.682214]  [<ffffffff8119c52b>] ? swiotlb_map_page+0x93/0xc4
Aug 13 02:04:49 mach kernel: [387338.682216]  [<ffffffff812fbe2d>] ? schedule_timeout+0x2e/0xdd
Aug 13 02:04:49 mach kernel: [387338.682220]  [<ffffffffa000def7>] ? usb_hcd_submit_urb+0x77e/0x86b [usbcore]
Aug 13 02:04:49 mach kernel: [387338.682222]  [<ffffffff812fbce4>] ? wait_for_common+0xde/0x15b
Aug 13 02:04:49 mach kernel: [387338.682224]  [<ffffffff8104a46c>] ? default_wake_function+0x0/0x9
Aug 13 02:04:49 mach kernel: [387338.682229]  [<ffffffffa000f576>] ? usb_start_wait_urb+0x71/0xb7 [usbcore]
Aug 13 02:04:49 mach kernel: [387338.682233]  [<ffffffffa000f7fa>] ? usb_control_msg+0x112/0x135 [usbcore]
Aug 13 02:04:49 mach kernel: [387338.682237]  [<ffffffffa00169d3>] ? usbdev_ioctl+0x31d/0x13ba [usbcore]
Aug 13 02:04:49 mach kernel: [387338.682239]  [<ffffffff8104828d>] ? finish_task_switch+0x3a/0xaf
Aug 13 02:04:49 mach kernel: [387338.682241]  [<ffffffff812fba70>] ? thread_return+0x79/0xe0
Aug 13 02:04:49 mach kernel: [387338.682244]  [<ffffffff8102462a>] ? lapic_next_event+0x18/0x1d
Aug 13 02:04:49 mach kernel: [387338.682246]  [<ffffffff81067c59>] ? lock_hrtimer_base+0x1b/0x3c
Aug 13 02:04:49 mach kernel: [387338.682248]  [<ffffffff81067cf2>] ? hrtimer_try_to_cancel+0x3a/0x43
Aug 13 02:04:49 mach kernel: [387338.682250]  [<ffffffff810faec3>] ? vfs_ioctl+0x56/0x6c
Aug 13 02:04:49 mach kernel: [387338.682253]  [<ffffffff810fb3dc>] ? do_vfs_ioctl+0x48d/0x4cb
Aug 13 02:04:49 mach kernel: [387338.682256]  [<ffffffff810fb46b>] ? sys_ioctl+0x51/0x70
Aug 13 02:04:49 mach kernel: [387338.682257]  [<ffffffff81010b42>] ? system_call_fastpath+0x16/0x1b

dieser Stack steht genau 5x in 2 Minuten abstaenden im Log.

Jetzt laeuft gar nichts mehr. Beide "mediasrv" haben sich beendet. Wobei ich dazu sagen muss ich bin gezwungen beide "80-mediasrv-eeti.rules" wegen [workaround] Option '--scan-network' funktioniert leider nicht  zu loeschen. Vielleicht wuerde  sich der "mediasrv" ansonsten selbst wieder neu starten. ABer ok ist das natuerlich alles nicht.

Gibt es einen Workaround? Oder irgendetwas was ich noch tun koennte? Kann hier bulk/iso Umstellung tatsaechlich was bewirken?

Wie gesagt Debian aktueller Standard-64bit-Kernel "squeeze" und "120803.2038" und  ganz normale PC Hardware (Asus P8H61-I ).

- sparkie

[Sundtek]

Das ist ein eindeutiges Zuverlaessigkeitsproblem des USB Stacks des Raspberry PIs

Eventuell kannst du ir_disabled=1 in /etc/sundtek.conf schreiben um die USB Message Last etwas zu senken damit der Controllertreiber nicht so schnell über den Bug stolpert.