[Gelöst] Reboot/Absturz debuggen?

[stan23]

Hallo,

zuerst zu meiner aktuellen Konfiguration:
- FB7270v3 UI
- freetz-trunk, zuletzt 6466
- Firmware-Version 74.04.88freetz-devel-6466M
- USB-Stick mit FAT32

Außerdem steckt an meine FB ein FTDIUSB-seriell Wandler mit µC und einem RFM12B Funkmodul. Er ist der Master für meine OpenHR20 Heizkörperventile.

Der Daemon läuft mit php-cli und speichert in eine SQlite-Datenbank. Das php-cli binary und die DB liegen auf dem USB-Stick. Das binary habe ich erstellen lassen indem ich die php.mk geändert habe und dann händisch auf den USB-Stick kopiert.
Anhang anzeigen patchfile-php-cli.diff.txt

Nun habe ich das Problem, dass nach 15 Minuten bis 3 Stunden die FB neu startet,
wenn ich php-cli gestartet habe. Also cd auf den USB-Stick und dann "./php-cli -f daemon.php". Ein & um den Prozess in den Hintergrund zu schicken oder die Ausgaben nach /dev/null umzuleiten bringt scheinbar keine Veränderung.

PHP erzeugt keine Logeinträge zu dem Absturz im Syslog, zu anderen Fehlern aber schon. D.h. logging von PHP funtioniert.

Das syslog lasse ich auf den USB-Stick schreiben, damit nach einem Absturz nicht alles leer ist. Kann es sein dass die letzte Meldung nicht schnell genug geschrieben wird? Soll ich versuchen über das Netzwerk zu loggen?

Angehängt sind ein Teil des Syslogs, die .config und der patch.

Getestet habe ich die revisions 6438, 6440, 6457, 6460, 6466, auch mit make distclean und neuer config bleibt das Problem.

Das loglevel für klogd scheint keinen Einfluss zu haben, ist das normal?

Das syslog (auf USB-Stick) schaue ich auf meinem PC (Win7 Home) per Samba-Freigabe an, evtl kommen daher die vielen smbd-Fehlereldungen.

Anhang anzeigen syslog.txt
Anhang anzeigen config.txt

Welche Möglickeiten gibt es, dem Absturz/Reboot auf die Schliche zu kommen bzw. welche Informationen habe ich noch vergessen?

Viele Grüße
Marco

 

[olistudent]

Kannst du mal in Abständen von 30 Minuten das freie RAM der Box kontrollieren? Wenn es nicht das RAM sein sollte, dann gibt es noch andere Probleme mit dem ftdi-Modul und der USB-Implementierung von AVM. Da wird vom Kernel Speicher allokiert und nicht mehr frei gegeben. Dazu sollte sich über die Suche was finden lassen.

Und das ganze passiert nur, wenn PHP rennt? Auch wenn du keine Abfragen machst? Hast du es mal mit swap probiert?

Gruß
Oliver

 

[stan23]

Hallo Oliver,

das RAM siehst Du in diesem rrdstat screenshot:

Heute läuft es schon seit dem Strich bei 8 Uhr ohne Absturz, das ist neuer Rekord
Ich kann aber nicht wirklich einen Unterschied erkennen. Der Reboot davor war bei 3:30, der Zeitraum mit etwas mehr Buffer memory (das Blaue) war ohne php-cli.

Ein 128 MiB Swapfile habe ich dem USB-Stick, das wird nur benutzt wenn php-cli läuft, sonst sind es 0%. Es kommt aber nicht über 4% Füllgrad.


Was meinst Du mit Abfragen?
Der Daemon ist eine Endlosschleife, der Zeichenketten über die USB-Schnittstelle empfängt, parst und entsprechend in die DB schreibt.

Das graphische Frontend dazu läuft per lighttpd und php-cgi und greift auf die gleiche DB zu.

Reboots gibt es aber nur wenn php-cli läuft.


Nach den FTDI-Problemen werde ich jetzt mal suchen, danke soweit.

 

[stan23]

Hi,

bisher habe ich leider keine Fortschritte gemacht

Explizite Probleme mit der FTDI-Implementierung bzw. Lösungsvorschläge dazu habe ich nicht gefunden, nur dass der FTDI-Treiber etwas älter ist. Nur leider lässt sich die Version 1.5.0 wegen Abhängigkeiten nicht ohne weiteres kompilieren.

Kann man das Syslog irgendwie detaillierter machen?
Oder würde die serielle Konsole (beim crash) mehr Infos ausgeben?


Wenn ich mit dem FTDI-Treiber nicht weiterkomme, werde ich versuchen, meinen auf php basierenden Daemon nach C zu portieren, um php-cli auszuschließen...

 

[olistudent]

Oder würde die serielle Konsole (beim crash) mehr Infos ausgeben?

Das kommt darauf an was genau passiert. Manchmal startet die Box ohne Ausgabe auf der Konsole neu...

Gruß
Oliver

 

[stan23]

"was genau passiert" würde mich ja eben interessieren
Hoffentlich finde ich am WE Zeit das mal zu testen...

Danke & Grüße
Marco

 

[stan23]

Hi,

ich habe nun einen Core Dump über die serielle Konsole bekommen:

CPU 0 Unable to handle kernel paging request at virtual address 0000002c, epc == c01cb954, ra == c01cd190
Oops[#1]:
Cpu 0
$ 0   : 00000000 1000ce01 00000001 00000002
$ 4   : 00000001 968a8df4 97998500 968a8cc0
$ 8   : 968a8ce8 9799850c 00000001 00000001
$12   : 00000001 e0000009 e0000000 c01cfb04
$16   : 97998500 968a8cc0 ffffff9f 96dd0b24
$20   : 00000001 94c78480 00000000 95037a00
$24   : 00000008 c005a4a4                  
$28   : 96d54000 96d57be8 97998500 c01cd190
Hi    : 00000009
Lo    : 00000000
epc   : c01cb954 musb_start_urb+0x8c/0xfff77738 [musb_hdrc]     Tainted: P     
ra    : c01cd190 musb_urb_enqueue+0x3ac/0xfff7621c [musb_hdrc]
Status: 1000ce02    KERNEL EXL 
Cause : b0800008
BadVA : 0000002c
PrId  : 00019068
Modules linked in: rtc_avm rtc_sysfs rtc_proc rtc_dev rtc_core rtc_lib sch_sfq sch_llq sch_tbf ulpcmlink(P) wlan_scan_ap wlan_acl wlan_wep wlan_tkip wlan_ccmp wlan_xauth ath_pci ath_spectral(P) ath_rate_atheros(P) wlan ath_dfs(P) ath_hal(P) avm_ath_extensions(P) userman_mod(P) vfat fat nls_cp437 nls_iso8859_1 usb_storage sd_mod scsi_mod kdsldmod(P) musb_hdrc dect_io(P) avm_dect(P) capi_codec(P) isdn_fbox_fon5(P) pcmlink(P) dsl_ur8(P) ext2 mbcache loop jffs2 Piglet_noemif(P) led_modul_Fritz_Box_7270plus(P) ftdi_sio usbserial usbcore
Process php-cli (pid: 3736, threadinfo=96d54000, task=972c96b8)
Stack : 94007160 00000027 00000000 1000ce01 95037a10 fffffff0 95037a00 95037a00
        00000010 00000001 0000000d 00000000 00000001 00000001 00000001 e0000009
        a3400400 968a8df4 95037a00 94c78480 96dd0b24 968a8c00 97998500 968a8cc0
        ffffff9f 96dd0b24 00000001 94c78480 00000001 95037a00 96d35180 c01cd190
        96d35180 00000000 1000ce03 00000009 00000000 96d57ca0 10800400 94015b30
        ...
Call Trace:
[<c01cb954>] musb_start_urb+0x8c/0xfff77738 [musb_hdrc]
[<c01cd190>] musb_urb_enqueue+0x3ac/0xfff7621c [musb_hdrc]
[<c005ac50>] usb_hcd_submit_urb+0x7ac/0xffff8b5c [usbcore]
[<c002ae44>] ftdi_write+0x3ac/0xffffb568 [ftdi_sio]
[<c0034518>] serial_write+0xd8/0xffffdbc0 [usbserial]
[<94127bf8>] tty_default_put_char+0x20/0x2c
[<941284a8>] opost+0xc0/0x218
[<9412a73c>] write_chan+0x320/0x400
[<94124938>] tty_write+0x17c/0x234
[<9406b8d0>] vfs_write+0xb8/0x190
[<9406ba94>] sys_write+0x54/0x98
[<94010400>] stack_done+0x20/0x3c


Code: 24020001  1062000c  00000000 <08072e69> 8ec2002c  8fa20044  24050008  ac5e0024  a0e00010 
Fatal exception: panic in 5 seconds
Call Trace:
[<9400d914>] dump_stack+0x8/0x34
[<9402854c>] panic+0x34/0x1f0
[<9400e0c8>] die+0xc8/0xd0
[<94011cac>] do_page_fault+0x24c/0x3c0
[<94007168>] ret_from_exception+0x0/0x14
[<c01cb954>] musb_start_urb+0x8c/0xfff77738 [musb_hdrc]
[<c01cd190>] musb_urb_enqueue+0x3ac/0xfff7621c [musb_hdrc]
[<c005ac50>] usb_hcd_submit_urb+0x7ac/0xffff8b5c [usbcore]
[<c002ae44>] ftdi_write+0x3ac/0xffffb568 [ftdi_sio]
[<c0034518>] serial_write+0xd8/0xffffdbc0 [usbserial]
[<94127bf8>] tty_default_put_char+0x20/0x2c
[<941284a8>] opost+0xc0/0x218
[<9412a73c>] write_chan+0x320/0x400
[<94124938>] tty_write+0x17c/0x234
[<9406b8d0>] vfs_write+0xb8/0x190
[<9406ba94>] sys_write+0x54/0x98
[<94010400>] stack_done+0x20/0x3c

Kernel panic - not syncing: Fatal exception
 WARING: use tffs in panic mode (minor 96)
Rebooting in 5 seconds..

Bedeutet das die Funktion musb_start_urb hat an eine "falsche" Speicherstelle gegriffen?
Kann man beim bauen von freetz ein mapping file erzeugen lassen, in dem man erkennt welchen Code der Compiler/Linker an die oberste Adresse im Call Trace gelegt hat?

Ansonsten sieht es leider sehr nach einem Problem im USB-Stack aus

Viele Grüße
Marco

 

[RalfFriedl]

Irgendwo im Kernel-Verzeichnis ist wahrscheinlich schon eine Datei, in der die Adressen aller Funktionen aufgeführt sind.

Andererseits sieht man sowieso schon, in welcher Funktion der Fehler passiert, so daß man nicht mehr von Hand nachsehen muß.

[<c01cb954>] musb_start_urb+0x8c/0xfff77738 [musb_hdrc]
[<c01cd190>] musb_urb_enqueue+0x3ac/0xfff7621c [musb_hdrc]
[<c005ac50>] usb_hcd_submit_urb+0x7ac/0xffff8b5c [usbcore]
[<c002ae44>] ftdi_write+0x3ac/0xffffb568 [ftdi_sio]
[<c0034518>] serial_write+0xd8/0xffffdbc0 [usbserial]
[<94127bf8>] tty_default_put_char+0x20/0x2c
[<941284a8>] opost+0xc0/0x218
[<9412a73c>] write_chan+0x320/0x400
[<94124938>] tty_write+0x17c/0x234

Der Fehler tritt auf beim Ansprechen des USB-Adapters, der Aufruf kommt von FTDI. Beides kommt als Ursache für den Fehler in Frage.

 

[stan23]

Hi Ralf,

richtig, die Funktion musb_start_urb() ist die letzte im call stack.

Mich interessiert aber dann noch, welchen C-Code der Compiler/Linker an musb_start_urb+0x8c gelegt hat. Hier in der Arbeit lade ich dazu das AXF-File in dem Lauterbach T32, aber diese Möglichkeit hab ich bei der FritzBox leider nicht

Ist der USB-Stack von AVM angepasst worden? Ich hab in der Suche dazu gefunden dass die USB-HW selbergestrickt wurde, aber ich weiß nicht ob das für die 7270v3 auch noch gilt? http://www.wehavemorefun.de/fritzbox/index.php/7270#Hardware zeigt unter USB nur eine leere Zeile.

Hättest Du eine Idee wie ich an dieser Stelle weiter debuggen könnte?

 

[olistudent]

Da musb_hdrc als Modul gebaut wird könntest du ein Image mit mini_fo bauen und Änderungen ins JFFS2 schreiben lassen. Damit könntest du das Modul austauschen. Einfach entladen funktioniert nicht soweit ich weiß.

Dann müsstest du das Modul mit Debug-Infos bauen und evtl. noch ein paar printks an den möglichen Stellen einfügen.
Wie oft tritt der Fehler auf?

Gruß
Oliver

 

[RalfFriedl]

Mit Freetz ist es am einfachsten, das Modul direkt in der Firmware auszutauschen.
Die Map-Datei des Kernels enthält nur die Adressen der Funktionen, nicht weitere Einzelheiten.
Die Adresse +0x8C ist noch ziemlich am Anfang der Funktion, da bekommt man mit einem Disassembler relativ einfach heraus, welcher Anweisung das entspricht.
Ansonsten kannst Du wie von Oliver vorgeschlagen noch einige printk-Anweisungen einbauen.
Ein Kernel-Debugger ist auch ganz praktisch, aber ich weiß nicht, ob wir so etwas haben.
Wichtig ist auch, wie häufig/schnell das reproduzierbar ist.

 

[stan23]

Also, wenn php-cli meine daemon.php ausführt, und dabei die Daten über den FT232R (USB-seriell Konverter), crasht die Fritzbox nach durchschnittlich 2 Stunden. Heute lief sie allerdings 14 Stunden (neuer Rekord), der Call Trace war dann wieder der gleiche.
Man kann also in Ruhe auf den Crash "warten"...


Meine Versuche mit einem Disassembler waren leider nicht erfolgreich, d.h. ich konnte damit keine hilfreiche Zuordnung Code <--> Adresse bekommen.

Auch die Tipps von http://www.delorie.com/djgpp/v2faq/faq8_20.html halfen nicht weiter, weil musb_hdrc.ko nicht aus einem C-File erstellt sondern scheinbar aus mehreren Objekten zusammengebaut wird.


Ralf, meinst Du ich soll einfach die Debugausgaben in musb_host.c (da ist die Funktion musb_start_urb() definiert) hinzufügen und den Kernel bzw. das ganze Image neu bauen? Würde das ausreichen?



Über Google habe ich vorhin noch diesen Patch gefunden, weiß aber noch nicht wann/in welcher Version er in den Kernel gekommen ist. Den baue ich morgen mal ein und schaue wie lange es damit läuft
https://patchwork.kernel.org/patch/5866/

 

[olistudent]

Du kannst natürlich 10 Images flashen oder es so probieren wie ich weiter oben beschrieben habe...

Gruß
Oliver

 

[RalfFriedl]

REC ist auch nicht ein Disassembler, obwohl der für andere Zwecke durchaus auch interessant aussieht.

Auch wenn das fertige Modul aus mehreren Dateien zusammen gesetzt wird, gibt es auf jeden Fall eine C Datei, in der die Funktion musb_start_urb definiert wird.

Bei der Toolchain ist schon ein Disassembler dabei, mipsel-linux-objdump

mipsel-linux-objdump -d musb_hdrc.ko | grep -A $((0x8c/4+2)) 'musb_start_urb>:'

Wenn Du den Quelltext der Funktion zur Hand hast, kannst Du den auch hier posten.

 

[stan23]

Ach jetzt versteh ich erst wie Du das meinst:
ich baue die Lib neu und ersetze sie im Overlay-Teil, und spätestens beim Reboot wird die geänderte Version geladen!

Das ist der Quelltext:

/*
 * Start the URB at the front of an endpoint's queue
 * end must be claimed from the caller.
 *
 * Context: controller locked, irqs blocked
 */
static void
musb_start_urb(struct musb *musb, int is_in, struct musb_qh *qh)
{
	u16			wFrame;
	u32			dwLength;
	void			*pBuffer;
	void __iomem		*pBase =  musb->pRegs;
	struct urb		*urb = next_urb(qh);
	struct musb_hw_ep	*pEnd = qh->hw_ep;
	unsigned		nPipe = urb->pipe;
	u8			bAddress = usb_pipedevice(nPipe);
	int			bEnd = pEnd->bLocalEnd;

	/* initialize software qh state */
	qh->offset = 0;
	qh->segsize = 0;

	/* gather right source of data */
	switch (qh->type) {
	case USB_ENDPOINT_XFER_CONTROL:
		/* control transfers always start with SETUP */
		is_in = 0;
		pEnd->out_qh = qh;
		musb->bEnd0Stage = MGC_END0_START;
		pBuffer = urb->setup_packet;
		dwLength = 8;
		break;
	case USB_ENDPOINT_XFER_ISOC:
		qh->iso_idx = 0;
		qh->frame = 0;
		pBuffer = urb->transfer_buffer + urb->iso_frame_desc[0].offset;
		dwLength = urb->iso_frame_desc[0].length;
		break;
	default:		/* bulk, interrupt */
		pBuffer = urb->transfer_buffer;
		dwLength = urb->transfer_buffer_length;
	}

	DBG(4, "qh %p urb %p dev%d ep%d%s%s, hw_ep %d, %p/%d\n",
			qh, urb, bAddress, qh->epnum,
			is_in ? "in" : "out",
			({char *s; switch (qh->type) {
			case USB_ENDPOINT_XFER_CONTROL:	s = ""; break;
			case USB_ENDPOINT_XFER_BULK:	s = "-bulk"; break;
			case USB_ENDPOINT_XFER_ISOC:	s = "-iso"; break;
			default:			s = "-intr"; break;
			}; s;}),
			bEnd, pBuffer, dwLength);

	/* Configure endpoint */
	if (is_in || pEnd->bIsSharedFifo)
		pEnd->in_qh = qh;
	else
		pEnd->out_qh = qh;
	musb_ep_program(musb, bEnd, urb, !is_in, pBuffer, dwLength);

	/* transmit may have more work: start it when it is time */
	if (is_in)
		return;

	/* determine if the time is right for a periodic transfer */
	switch (qh->type) {
	case USB_ENDPOINT_XFER_ISOC:
	case USB_ENDPOINT_XFER_INT:
		DBG(3, "check whether there's still time for periodic Tx\n");
		qh->iso_idx = 0;
		wFrame = musb_readw(pBase, MGC_O_HDRC_FRAME);
		/* FIXME this doesn't implement that scheduling policy ...
		 * or handle framecounter wrapping
		 */
		if ((urb->transfer_flags & URB_ISO_ASAP)
				|| (wFrame >= urb->start_frame)) {
			/* REVISIT the SOF irq handler shouldn't duplicate
			 * this code; and we don't init urb->start_frame...
			 */
			qh->frame = 0;
			goto start;
		} else {
			qh->frame = urb->start_frame;
			/* enable SOF interrupt so we can count down */
DBG(1,"SOF for %d\n", bEnd);
#if 1 // ifndef	CONFIG_ARCH_DAVINCI
			musb_writeb(pBase, MGC_O_HDRC_INTRUSBE, 0xff);
#endif
		}
		break;
	default:
start:
		DBG(4, "Start TX%d %s\n", bEnd,
			pEnd->tx_channel ? "dma" : "pio");

		if (!pEnd->tx_channel)
			musb_h_tx_start(pEnd);
		else if (is_cppi_enabled())
			cppi_host_txdma_start(pEnd);
	}
}

aus Z:\freetz-trunk\source\kernel\ref-ur8-16mb-7270_04.86\linux\drivers\usb\musb\musb_host.c

 

[RalfFriedl]

Ich würde das Modul einfach im Image ersetzten und neu Flashen.

Debuggen mit printk oder vergleichbarem hat eine lange Tradition. Zusätzlich oder statt dessen kann man sich auch den Quelltext anschauen und nach Probleme suchen.

Aus dem Objekt-Code würde ich sagen, daß es ein Problem mit dem dritten Parameter gibt. Entweder hat dieser Parameter den Wert NULL, oder etwas, was über diesen Pointer gelesen wird, führt zu einem NULL-Pointer, der nachher referenziert wird.

PS:
Ich vermute, daß in der Zeile nach default, "pBuffer = urb->transfer_buffer", urb den Wert NULL hat, entweder weil qh schon den Wert NULL hat, oder weil next_urb(qh) den Wert NULL hat.

 

[stan23]

Hi,

ich bin leider noch nicht besonders weit gekommen. Der WAF für eine funktionierende Heizungssteuerung ist zwar hoch, für einen stundenlang debuggenden Ehemann aber nicht :?

Ich habe bisher das Kernel-Debugging für den USB-Treiber eingeschalten (make kernel-menuconfig) und noch ein paar Debug-Meldungen hinzugefügt.

Mir ist aber aufgefallen dass diese Meldungen scheinbar zwischengespeichert werden, denn beim Absturz kommt da ein ganzer Schwall, etwa so:

---- start avmdebug(suppress 61439 bytes) ----
rb 9689FB80: 0x0, 2/512, status 0
__musb_giveback 366: complete 9689FB80 (0), dev3 ep1in, 2/512
musb_urb_enqueue 1791: urb=9689FB80, dev3 ep1in hep=9689FC80 qh=9788F480
musb_advance_schedule 569: ... next ep1 RX urb 9689FB80
musb_start_urb 269: m2) qh 9788F480 urb 9689FB80 dev3 ep1in-bulk, hw_ep 1, 96AFC600/512
musb_ep_program 792: <-- hw1 urb 9689FB80 spd2 dev3 ep1in h_addr82 h_port01 bytes 512
cppi_next_rx_segment 842: RX DMA0 seg, maxp 64 onepacket bds 1 (cnt 0) dma 0x16AFC600 len 64 0/512
cppi_dump_rx 388: RX DMA0/S: 3 left, csr 0200, 00000000 H16910EC0 S16910EC0 C16910EC0, B16AFC602 L0002003E 00000002 .. 16910EC0
ur8musb_interrupt 374: <== CPPI IRQ t0 r1
musb_giveback 469: urb 9689FB80: 0x0, 2/512, status 0
__musb_giveback 366: complete 9689FB80 (0), dev3 ep1in, 2/512
<snip>
__musb_giveback 366: complete 953C2400 (0), dev3 ep2out, 1/1
musb_interrupt 1270: ** IRQ host usb0000 tx0002 rx0000
musb_host_tx 1286: extra TX1 ready, csr 3000
ur8musb_interrupt 402: unhandled? 00000000
musb_urb_enqueue 1791: urb=953C2400, dev3 ep2out hep=9689FCA4 qh=(null)
---- eof avmdebug ----
[295947]maxrun: 1

---- start avmdebug(suppress 0 bytes) ----

[00295948][pcmlink]error: trigger to late 1123143 usec (7E210F24 8A2DDDBA 8A2E3995)
[00295948]avm_DebugSignal: 0 kernel info: 0
---- eof avmdebug ----
CPU 0 Unable to handle kernel paging request at virtual address 00000021, epc == c02337d8, ra == c0235be0
Oops[#1]:
<und hier wieder der gleiche core dump wie früher>
<hier kommen weitere 500 Zeilen USB Debug-Meldungen wie oben auch>
(AVM) EVA Revision: 1.607 Version: 1607

(C) Copyright 2005 AVM Date: Feb 20 2009 Time: 17:48:20 (2) 2 0x0-0x41D

[FLASH:] ST Uniform-MirrorBit-Flash 16MB 64 Bytes WriteBuffer
[FLASH:](Eraseregion [0] 128 sectors a 128kB) 
[SYSTEM:] UR8 on 360MHz/120MHz syncron

Eva_AVM >AVM decompress Kernel:
..............................executeProgram on 0x942E9000
[prom_init] 0
<snip>
Please press Enter to activate this console.

Ist diese Zwischenspeicherung normal? HTerm zeigt mir an dass diese ganze Debug-Meldungen in nur wenigen Sekunden gesendet wurden.


Die Meldung

ur8musb_interrupt 402: unhandled? 00000000
musb_urb_enqueue 1791: urb=953C2400, dev3 ep2out hep=9689FCA4 qh=(null)

sehe ich übrigens nicht bei jedem Absturz, aber sie sieht für mich aus also ob das kein einfacher, schnell zu fixender Bug ist...

 

[olistudent]

Wenn du vorher auf der Console "cat /dev/debug &" eingibst solltest du die Meldungen direkt sehen?

Gruß
Oliver

 

[stan23]

So, leider konnte ich das Problem im Frühjahr nicht beheben, ich bin dem Fehler nicht auf die Schliche gekommen. Bis vor einer Woche habe ich dann eine abgespeckte Version des Dämons benutzt, die über libftdi und libusb zugreift, damit gab es keine Probleme mehr.

Jetzt verwende ich wieder den Dämon in php mit php-cli, aber mit Firmware .05.05, und da gibt es kein Problem mehr. Sieht aus als hätte AVM den USB-Stack repariert