[Problem] usb Devices werden nach Freetz-Installation nicht mehr erkannt

[Al_]

Hallo

Ich verwende eine FritzBox 7390 als Switch. Nun habe Freetz mit ffmpeg kompiliert und auf diese Box geladen. Aus Platzgründen musste ich einige Teile entfernen ('removal patches', Liste unten). Seither gehen die USB-Anschlüsse an der Box nicht mehr. Wenn ich mit telnet auf die Box zugreife, sehe ich, dass USB-sticks nicht gemounted werden, ein USB video capture device legt kein /dev/video0 an, lsusb zeigt keine Geräte (aber drei Anschlüsse). Vor Freetz hat dies funktioniert. Habe ich etwas zu viel weggelassen; welchen removal patch?

Angaben vom Freetz Webinterface (.config Datei ist angehängt):
Boxtyp 7390
AVM-Firmwareversion 06.20
Sprache en
Kernelversion 2.6.28.10 (gcc version 4.8.1 (Buildroot 2013.05) )
Freetz-Version freetz-devel-12752
Entfernte Teile ('removal patches'): aha avm_e2fsprogs avm_vpn dtrace help kids ntfs samba showdsldstat umtsd

Hat jemand eine Idee?

Anhang anzeigen config.txt

 

[PeterPawn]

Ich habe bei der 7390 im Moment auch ein merkwürdiges Phänomen, wenn es um USB-Devices geht ... bei mir wird sd_mod nicht auf Anhieb geladen (noch keine Ahung, warum nicht ... keine Zeit zur Suche).

Ein "modprobe sd_mod" nachträglich regelt das bei mir ... als Workaround in der rc.custom könnte das auch bei Dir helfen.

Ich mache mich auch noch an die Suche nach der Ursache, aber es eilt für mich nicht.

 

[gismotro]

Das macht remove telephony. Hatte ich auch als Ticket gemeldet

http://freetz.org/ticket/2636

 

[Al_]

Danke für die Vorschläge.

@PeterPawn: modprobe sd_mod hilft leider nicht (lsmod zeigt dann zwar an, dass sd_mod geladen ist, aber die USB Anschlüsse funktionieren weiterhin nicht)
@gismotro: 'telephony' hatte ich gar nicht abgewählt. Nur folgende: aha avm_e2fsprogs avm_vpn dtrace help kids ntfs samba showdsldstat umtsd. Hängt eines davon eng zusammen mit telephony. Und hast Du ausprobiert, ob es bei Dir (nur) telephony war, oder eventuall (auch) ein anderes removal?

 

[PeterPawn]

Das hat weder Al_ in seiner config.txt, noch habe ich es ausgewählt. Der einzige Remove-Patch, der bei mir automatisch ausgewählt wird, weil ich das eigene davfs2 haben will, ist REMOVE_WEBDAV.

Ich glaube eher daran, daß da aus irgendeinem Grund usb_storage zu früh geladen ist und dann in der /etc/hotplug/storage das folgende Code-Fragment nicht ausgeführt wird:

start)
passeeren
touch /var/STORAGE_STARTING
if ! lsmod | grep -q usb_storage ; then
modprobe sd_mod
modprobe usb-storage
if ! test -d $FTPDIR; then
mkdir -p $FTPDIR
## be sure only root is allowed to write to $FTPDIR
chmod 755 $FTPDIR
fi
touch $DEVMAP
#tune write behaviour
echo 2 > /proc/sys/vm/laptop_mode
echo 100 > /proc/sys/vm/dirty_expire_centisecs
echo 100 > /proc/sys/vm/dirty_writeback_centisecs
local SPINDOWN_SECONDS=0
local SPINDOWN_ALLOWED="`echo usbhost.spindown_enabled|usbcfgctl -s`"
if [ "$SPINDOWN_ALLOWED" = "yes" ] ; then
SPINDOWN_SECONDS="`echo usbhost.spindown_time|usbcfgctl -s`"
fi
hd_spindown_control "$SPINDOWN_SECONDS"
fi
vrijgeven
;;

Da das die einzige Stelle ist, wo sd_mod geladen werden könnte, tippe ich auf ein früheres Laden von usb_storage, womit dann sd_mod am Ende fehlt. Das ist aber nur durch einen richtigen Test (z.B. das Protokollieren des lsmod vor dem grep) festzustellen und dann geht die Suche nach der Ursache wahrscheinlich erst richtig los (wenn die Vermutung stimmt und usb_storage schon geladen ist). Ein einfacher Workaround wäre es natürlich, das modprobe auch im else-Zweig noch einmal zu machen.

Es besteht jedenfalls an dieser Stelle (storage start) keine Code-Differenz zum AVM-Original, trotzdem wird vermutlich Freetz für das frühe Laden (immer vorausgesetzt, der Verdacht stimmt) verantwortlich sein. Aber das ist kein 10-Minuten-Problem, das braucht seine Zeit ...

@Al_:
Dann schau doch einfach mal nach, welche Module da bei Dir nicht geladen sind bzw. sieh in dmesg/syslog nach, was da beim Anstecken der Geräte passiert.

 

[gismotro]

ich hatte nur telephony ausgewählt bei meinem test damals. Bei alle anderen remove patchen lief USB bei mir noch.

# FREETZ_REMOVE_BRANDING_otwo is not set
138 FREETZ_REMOVE_CAPIOVERTCP=y
139 # FREETZ_REMOVE_CHRONYD is not set
140 FREETZ_REMOVE_DECT=y
141 # FREETZ_REMOVE_DSLD is not set
142 # FREETZ_REMOVE_SHOWDSLDSTAT is not set
143 FREETZ_REMOVE_DTRACE=y
144 # FREETZ_REMOVE_FTPD is not set
145 # FREETZ_REMOVE_HELP is not set
146 # FREETZ_REMOVE_RAMZSWAP is not set
147 # FREETZ_REMOVE_LSOF is not set
148 # FREETZ_REMOVE_NTFS is not set
149 # FREETZ_REMOVE_PRINTSERV is not set
150 # FREETZ_REMOVE_RUNCLOCK is not set
151 # FREETZ_REMOVE_SAMBA is not set
152 # FREETZ_REMOVE_SUPPORT is not set
153 # FREETZ_REMOVE_TR069 is not set
154 # FREETZ_REMOVE_UMTSD is not set
155 # FREETZ_REMOVE_UPNP is not set
156 # FREETZ_REMOVE_KIDS is not set
157 # FREETZ_REMOVE_QOS is not set
158 FREETZ_REMOVE_AVM_E2FSPROGS=y
159 FREETZ_REMOVE_VOIPD=y
160 FREETZ_REMOVE_TELEPHONY=y
161 # FREETZ_REMOVE_WEBDAV is not set
162 # FREETZ_REMOVE_WLAN is not set

 

[Al_]

@PeterPawn: Danke, ich habe gemäss Deinen Empfehlungen weiter gesucht.
Nach einem reboot der FritzBox is sd_mod nicht geladen (Ausgabe von lsmod: Anhang anzeigen Freetz_fresh-boot.txt), nach einstecken eines USB Sticks sind ein paar zusätzliche Module geladen (zweite Ausgabe von lsmod: Anhang anzeigen Freetz_usb-plugged.txt). Die Unterschiede:

2a3,5
> usb_storage            34688  0 
> sd_mod                 24896  0 
> scsi_mod               87504  2 usb_storage,sd_mod
17c20
< usbcore               119552  3 ohci_hcd,ehci_hcd
---
> usbcore               119552  4 usb_storage,ohci_hcd,ehci_hcd

Und die Ausgabe von dmesg (Anfang abgeschnitten):

# dmesg
...
usb 1-2: new high speed USB device using fusiv-ehci-hcd and address 2
Port#2 config: AVM Powermeter changed to 200 mA
usb 1-2: configuration #1 chosen from 1 choice
[module-alloc-by-name] no kseg0-space for module 'scsi_mod' (0x16000 bytes) -> use ksseg
[0]system-load 2  loadavg 0.1 0.1 0.0 - 76 tasks:0 % curr:busybox(0 %) max:vdsld(0 %, pid:672), readytorun: 8, pgfault 2/s (max 1 avg 1.0)
SCSI subsystem initialized
[module-alloc-by-name] give 0x7000 bytes at 0x8167e000 to module 'sd_mod'
[COLOR="#FF0000"]Driver 'sd' needs updating - please use bus_type methods[/COLOR]
[module-alloc-by-name] give 0x9000 bytes at 0x81685000 to module 'usb_storage'
Initializing USB Mass Storage driver...
scsi0 : SCSI emulation for USB Mass Storage devices
usbcore: registered new interface driver usb-storage
USB Mass Storage support registered.
usb-storage: device found at 2
usb-storage: waiting for device to settle before scanning
scsi 0:0:0:0: Direct-Access     Generic  Flash Disk       8.07 PQ: 0 ANSI: 2
sd 0:0:0:0: [sda] 2067968 512-byte hardware sectors: (1.05 GB/1009 MiB)
sd 0:0:0:0: [sda] Write Protect is off
sd 0:0:0:0: [sda] Mode Sense: 03 00 00 00
sd 0:0:0:0: [sda] Assuming drive cache: write through
sd 0:0:0:0: [sda] 2067968 512-byte hardware sectors: (1.05 GB/1009 MiB)
sd 0:0:0:0: [sda] Write Protect is off
sd 0:0:0:0: [sda] Mode Sense: 03 00 00 00
sd 0:0:0:0: [sda] Assuming drive cache: write through
 sda: sda1
sd 0:0:0:0: [sda] Attached SCSI removable disk
usb-storage: device scan complete
usb 1-2: USB disconnect, address 2
Port#2 disconnect: AVM Powermeter changed to 0 mA

Das sieht so aus, als würde der USB Stick als sda oder sda1 erkannt, aber es sda weder in /dev noch in einem Unterverzeichnis von /dev ("ls /dev -R -l | grep sda" gibt nichts aus). Es könnte schon etwas mit sd_mod zu tun haben: was muss ich von der Zeile halten, welche ich rot markiert habe?

 

[PeterPawn]

was muss ich von der Zeile halten, welche ich rot markiert habe?

Die ist harmlos, was mich mehr irritiert ist dieser Teil:

usb-storage: device scan complete
usb 1-2: USB disconnect, address 2
Port#2 disconnect: AVM Powermeter changed to 0 mA

Das sieht ja so aus, als wenn der Stick aus irgendeinem unerfindlichen Grund wieder abgezogen/deaktiviert wurde. Wenn es kein Hardware-Defekt ist (Test an anderem Gerät), ist das ja eher nicht "normal".

Wenn es sich auch nicht um einen Stick handelt, der eine der VIDs eines Herstellers von GSM-Sticks hat (und wo der dann beim Versuch des Umschaltens ins temporäre Nirwana eingeht, was ich aber so auch noch nicht erlebt habe, ich will eigentlich nur sicher sein, daß es kein UMTS-/GSM-Stick mit µSD-Karte ist - was aber das Initialisieren eigentlich schon zeigt, weil 200 mA imho etwas wenig ist für einen Mobilfunk-Stick), dann würde ich am ehesten auf ein rmmod für einen der benötigten Treiber tippen ... das sieht man im dmesg aber normalerweise nicht.

Ich würde noch einmal ein lsmod nach der Erkennung machen und dann in den udev-Rules und im hotplug-Verzeichnis nach der Stelle suchen, wo die Treiber wieder entladen werden (natürlich nur, wenn die Vermutung stimmt). Notfalls mal ein 'udevadm monitor' miitlaufen lassen beim Anstecken des Speichers, da müßte sich dann auch das "Abziehen" (egal ob physikalisch oder logisch) wiederfinden lassen.

Vielleicht wird ja wirklich durch irgendeinen Patch (nachdem zuvor schon ein anderer da dran war) eine Abbruchbedingung in /etc/hotplug/storage zuviel entfernt und bei Dir rennt der Code nach dem Laden von Modulen dann gleich in das Entladen weiter ... das "USB disconnect" gehört da jedenfalls nicht hin und ob es sich durch Entladen eines Modules auslösen läßt, kann ich gerade nicht selbst testen.

 

[gismotro]

Ich hab an meiner 7390 eine SATA-USB-Platte, einen Cardreader und diverse Sticks getestet.

Hardware defekt kann man ausschließen, weil wenn ich remove telephony nicht benutze, werden ja alle Geräte an beiden USB-Ports wieder erkannt.

 

[Al_]

@PeterPaawn
Oops, Entschuldigung, war copy-paste Fehler. Ich hatte den USB später wieder abgezogen und nochmals versucht. Die Meldung 'disconnect' kam erst dann. Hier nochmals ein weiterer Versuch:

# dmesg
...
usb 1-2: new high speed USB device using fusiv-ehci-hcd and address 4
Port#2 config: AVM Powermeter changed to 200 mA
usb 1-2: configuration #1 chosen from 1 choice
scsi2 : SCSI emulation for USB Mass Storage devices
usb-storage: device found at 4
usb-storage: waiting for device to settle before scanning
scsi 2:0:0:0: Direct-Access     Generic  Flash Disk       8.07 PQ: 0 ANSI: 2
sd 2:0:0:0: [sda] 2067968 512-byte hardware sectors: (1.05 GB/1009 MiB)
sd 2:0:0:0: [sda] Write Protect is off
sd 2:0:0:0: [sda] Mode Sense: 03 00 00 00
sd 2:0:0:0: [sda] Assuming drive cache: write through
sd 2:0:0:0: [sda] 2067968 512-byte hardware sectors: (1.05 GB/1009 MiB)
sd 2:0:0:0: [sda] Write Protect is off
sd 2:0:0:0: [sda] Mode Sense: 03 00 00 00
sd 2:0:0:0: [sda] Assuming drive cache: write through
 sda: sda1
sd 2:0:0:0: [sda] Attached SCSI removable disk
usb-storage: device scan complete

mit der Zeit kommt dann

[0]system-load 4  loadavg 0.1 0.0 0.0 - 77 tasks:0 % curr:sh(0 %) max:vdsld(0 %, pid:672), readytorun: 2, pgfault 4/s (max 1 avg 1.0)
[0]system-load 8  loadavg 0.2 0.3 0.0 - 76 tasks:1 % curr:sh(0 %) max:vdsld(0 %, pid:672), readytorun: 1, pgfault 9/s (max 1 avg 1.0)
[0]system-load 7  loadavg 0.15 0.6 0.1 - 77 tasks:18 % curr:sh(4 %) max:telnetd(12 %, pid:997), readytorun: 1, pgfault 51/s (max 1 avg 1.0)

nach abziehen des USB sticks

usb 1-2: USB disconnect, address 4
Port#2 disconnect: AVM Powermeter changed to 0 mA

 

[PeterPawn]

@gismotro:
Bei Dir tippe ich ja auch eher auf einen Seiteneffekt zwischen zwei verschiedenen Patches ... einfach aufgrund der Art und Weise, wie das modsed da verwendet wird. Bei Dir wäre es ja Kaffeesatz-Leserei, wenn man da auf dieselbe Ursache tippen würde, denn von Dir liegt so ein Protokoll (wo das Gerät offenbar noch vor dem Mounten wieder "abgeschaltet" wird) nicht vor.

Daß es exakt am "FREETZ_REMOVE_TELEPHONY" liegt, bestreite ich ja gar nicht ... aber Dir ist sicherlich auch aufgefallen, daß "remove telephony" eine Kombination aus mehreren Patches (u.a. auch DECT, daher dann auch AHA, usw.) ist und insofern ist das Reduzieren auf "remove telephony" natürlich richtig, aber zur Lokalisierung des exakten Fehlers nicht zielführend.

Jedoch kann man eben nicht jede Hardware-Konfiguration nachstellen und auch nicht mit jedem .config-File selbst eine Firmware bauen, nur um solche Fehler zu reproduzieren und zu suchen ...

Da muß also derjenige, der solche Fehler bei sich hat, dann noch etwas selbst testen und z.B. mal - so wie Al_ es ja auch macht - das Laden der USB-Treiber genauer untersuchen ... mach doch mal Deinerseits ein dmesg, wenn Du nachträglich erst die USB-Geräte verbindest und lasse dabei parallel in einer Console (mit setconsole auch /dev/console mit den AVM-Ausgaben an Bord holen) noch "udevadm monitor" mitlaufen. Anhand dieser Ausgaben müßte man ja schon mal sehen können, wo es dann klemmt und wo man mal die originalen AVM-Skripte mit denen nach der ganzen Patcherei vergleichen sollte, um den Fehler zu umzingeln.

 

[RalfFriedl]

Das sieht so aus, als würde der USB Stick als sda oder sda1 erkannt, aber es sda weder in /dev noch in einem Unterverzeichnis von /dev ("ls /dev -R -l | grep sda" gibt nichts aus). Es könnte schon etwas mit sd_mod zu tun haben: was muss ich von der Zeile halten, welche ich rot markiert habe?

Es könnte sich um ein Problem mit udevd handeln, das dazu führt, dass die Einträge nicht angelegt werden.
Was wird bei "cat /proc/partitions" angezeigt, wenn der USB Stick angeschlossen ist?

 

[PeterPawn]

@Al_:
Mach mal bitte noch ein "cat /proc/diskstats" nach dem Anstecken. Das "udevadm monitor"-Log beim Anstecken zeigt die Reihenfolge der Abarbeitung der verschiedenen udev-Skripte in /etc/hotplug an und wäre auch nützlich.

Auch ein "diff -Naur build/original/filesystem/etc/udev build/modified/filesystem/etc/udev" (und dasselbe auch noch für das hotplug-Verzeichnis) kann nicht schaden ... irgendwo klemmt da meines Erachtens der udev. Es kann aber ebenso gut am blkid oder an irgendetwas anderem in der libmodmount.sh liegen ... das muß man langsam einkreisen.

EDIT:
/proc/partitions geht natürlich auch, mach aber bitte beides und nicht nur entweder/oder ...
Die "diff"-Kommandos beziehen sich natürlich auf Dein Build-System und nicht auf die Box selbst.

 

[gismotro]

@PeterPawn: Werde die Ausgaben mal am Mittwoch plotten. Vorher schaffe ich es nicht. Wenn man mir sagt wie ich helfen kann, dann bin ich immer dabei.

 

[gismotro]

Ich hab jetzt extra mal ein Image Gebaut wo nur die Pakete ausgewählt wurden die durch remove telephony zusätzlich gesetzt werden. Bei diesem Image ist USB noch verfügbar.
Werde mich jetzt mal um die von Dir gesuchten Ausgaben kümmern.

cat /proc/partitions:

root@fritz:/var/mod/root# cat /proc/partitions
major minor #blocks name

31 0 13880 mtdblock0
31 1 1352 mtdblock1
31 2 128 mtdblock2
31 3 512 mtdblock3
31 4 512 mtdblock4
31 5 1024 mtdblock5
31 6 524288 mtdblock6
254 0 16384 ramzswap0
root@fritz:/var/mod/root#

root@fritz:/var/mod/root# cat /proc/diskstats
31 0 mtdblock0 385 6428 13626 672 0 0 0 0 0 672 672
31 1 mtdblock1 0 0 0 0 0 0 0 0 0 0 0
31 2 mtdblock2 0 0 0 0 0 0 0 0 0 0 0
31 3 mtdblock3 0 0 0 0 0 0 0 0 0 0 0
31 4 mtdblock4 0 0 0 0 0 0 0 0 0 0 0
31 5 mtdblock5 0 0 0 0 0 0 0 0 0 0 0
31 6 mtdblock6 0 0 0 0 0 0 0 0 0 0 0
254 0 ramzswap0 0 0 0 0 0 0 0 0 0 0 0
root@fritz:/var/mod/root#

 

[Al_]

@PeterPawn: hier einmal die von Dir empfohlenen Tests auf der FritzBox:
1) cat /proc/partitions und cat /proc/diskstats zeigen beide, dass sda und sda1 erscheinen (aber ein Device sda oder sda1 finde ich nicht in /dev); ganze Ausgabe der beiden Befehle, vor und nach Einstecken eines USB Sticks:Anhang anzeigen usb-plugged_2014-12-07.txt. Anhang anzeigen Fresh-boot_2014-12-07.txt
2) Ausgabe von udevadm monitor während der USB Stick eingesteckt wird: Anhang anzeigen udevadm_monitor_2014-12-07.txt
3) diff vom Ubuntu Desktop:

$ diff -Naur build/original/filesystem/etc/udev build/modified/filesystem/etc/udev
diff -Naur build/original/filesystem/etc/udev/rules.d/50-udev-default.rules build/modified/filesystem/etc/udev/rules.d/50-udev-default.rules
--- build/original/filesystem/etc/udev/rules.d/50-udev-default.rules	2014-10-29 14:28:34.000000000 +0000
+++ build/modified/filesystem/etc/udev/rules.d/50-udev-default.rules	2014-11-23 10:19:36.693975274 +0000
@@ -100,7 +100,7 @@
 SUBSYSTEM=="aoe", KERNEL=="err", MODE="0440"
 
 # network
-KERNEL=="tun",			MODE="0666"
+KERNEL=="tun",			MODE="0666", SYMLINK+="net/tun"
 KERNEL=="rfkill",		MODE="0644"
 
 # CPU

 

[PeterPawn]

@gismotro:
Bei Dir würde ich behaupten, daß die Treiber nicht geladen sind -> lsmod -> wenn kein usb_storage, sd_mod, scsi_mod geladen ist, dann einfach mal manuell mit "modprobe" laden, wenn dann die Devices da sind, liegt es am fehlenden Laden der Treiber -> Workaround möglich, Suche aufwendiger.

@Al_:
Das heißt ja schon mal, daß da zumindest die notwendigen Treiber bei Dir sauber geladen werden und nur an irgendeiner anderen Stelle im udev (bzw. den hotplug-Skripten) die Verarbeitung entweder abgebrochen wird oder gar nicht erst beginnt.

Ich habe im Moment etwas das 'lsusb'-Kommando im Verdacht, das von AVM in den Skripten mal explizit als /sbin/lsusb und mal nur als lsusb aufgerufen wird.

hotplug/storage:if ! lsusb | grep -e 'ICLS.=08' > /dev/null ; then
hotplug/udev-printer-lp:for var in `/sbin/lsusb -s -h $DEVICE|tr " " "_"`; do
hotplug/create_handle.sh:COUNT=`/sbin/lsusb -n`
hotplug/create_handle.sh:HUBCOUNT=`/sbin/lsusb -N 9`
hotplug/create_handle.sh:DUMMYCOUNT=`/sbin/lsusb -N 0`
hotplug/create_handle.sh:for var in `/sbin/lsusb -th $DEVICE`; do
hotplug/udev-mount-sd:local VIDPID=`lsusb -h $DEVICE|sed -n 's/^.ID=\(.*\)$/\1/p'|tr '\n' ':'`
hotplug/udev-mount-sd:VIDPID=`lsusb -h $DEVICE|sed -n 's/^.ID=\(.*\)$/\1/p'|tr '\n' ':'`
hotplug/aura:eval `/sbin/lsusb -tsh $DEVICE | tr -dc "\\\'\.\ ,;:#+*\~\-!&▒$%/()=?a-zA-Z0-9\n"`
hotplug/udev-avmwlan-usb:MAC_CLIENT=`lsusb -s -h $DEVICE | grep SNUM | tr -d SNUM= | tr -d "\'"`

Wenn man jetzt eine Busybox mit lsusb baut und dabei auch ein entsprechender Link angelegt wird (/usr/bin/lsusb), hat man schnell das Busybox-lsusb erwischt und das kennt keine Optionen.

Als Test (nach der Prüfung mit "find / -name lsusb" und zwei Fundstellen - /sbin/lsusb und /usr/bin/lsusb) würde ich eine Änderung der lsusb-Aufrufe in hotplug/storage, hotplug/udev-mount-sd und (nicht kriegsentscheidend) hotplug/udev-avmwlan-usb empfehlen. Weißt Du, wie Du das anstellen müßtest ?

EDIT: Das diff vom udev-Verzeichnis belegt ja schon mal, daß da von Freetz nichts geändert ist ... im hotplug sieht das definitiv anders aus, aber das kann man erst mal bis nach dem o.a. Test vertagen.

 

[gismotro]

lsmod:

root@fritz:/var/mod/root# lsmod
Module Size Used by Tainted: P
avm_pa_fusiv 20768 0
kdsldmod 1541840 4
ohci_hcd 17712 0
ehci_hcd 30896 0
usbcore 119552 3 ohci_hcd,ehci_hcd
ramzswap 16288 1
lzo_decompress 2272 1 ramzswap
lzo_compress 2016 1 ramzswap
nls_utf8 1344 0
vfat 10336 0
fat 49776 1 vfat
bmedrv 7376 0
opensrc_lkm 1632 1 bmedrv
aclap_driver_lkm 19536 1 avm_pa_fusiv
sysKCode_lkm 23248 0
ethdriver_lkm 43824 1 aclap_driver_lkm
periap_driver_lkm 15456 1 ethdriver_lkm
timers_lkm 5200 1 ethdriver_lkm
bmdriver_lkm 12880 0
ap2ap_lkm 23808 5 kdsldmod,aclap_driver_lkm,sysKCode_lkm,ethdriver_lkm,bmdriver_lkm
fusivlib_lkm 59152 9 avm_pa_fusiv,kdsldmod,bmedrv,aclap_driver_lkm,sysKCode_lkm,ethdriver_lkm,periap_driver_lkm,bmdriver_lkm,ap2ap_lkm
rtc_avm 5264 0
rtc_core 13520 1 rtc_avm
led_modul_Fritz_Box_7390 79824 2

root@fritz:/var/mod/root# lsmod
Module Size Used by Tainted: P
sd_mod 24896 0
usb_storage 34688 0
scsi_mod 87504 2 sd_mod,usb_storage
avm_pa_fusiv 20768 0
kdsldmod 1541840 4
ohci_hcd 17712 0
ehci_hcd 30896 0
usbcore 119552 4 usb_storage,ohci_hcd,ehci_hcd
ramzswap 16288 1
lzo_decompress 2272 1 ramzswap
lzo_compress 2016 1 ramzswap
nls_utf8 1344 0
vfat 10336 0
fat 49776 1 vfat
bmedrv 7376 0
opensrc_lkm 1632 1 bmedrv
aclap_driver_lkm 19536 1 avm_pa_fusiv
sysKCode_lkm 23248 0
ethdriver_lkm 43824 1 aclap_driver_lkm
periap_driver_lkm 15456 1 ethdriver_lkm
timers_lkm 5200 1 ethdriver_lkm
bmdriver_lkm 12880 0
ap2ap_lkm 23808 5 kdsldmod,aclap_driver_lkm,sysKCode_lkm,ethdriver_lkm,bmdriver_lkm
fusivlib_lkm 59152 9 avm_pa_fusiv,kdsldmod,bmedrv,aclap_driver_lkm,sysKCode_lkm,ethdriver_lkm,periap_driver_lkm,bmdriver_lkm,ap2ap_lkm
rtc_avm 5264 0
rtc_core 13520 1 rtc_avm
led_modul_Fritz_Box_7390 79824 2

Treiber lassen sich starten, aber trotzdem kein USB-Device

 

[PeterPawn]

Treiber lassen sich starten, aber trotzdem kein USB-Device

Kein USB-Device an sich (lsusb -vs,/proc/diskstats und/oder /proc/partitions) oder "USB-Devices funktionieren trotzdem nicht" ?

Dann klemmt es also schon mal ganz vorne bei Dir, die Treiber für die Hubs werden zwar noch geladen:

ohci_hcd 17712 0
ehci_hcd 30896 0
usbcore 119552 3 ohci_hcd,ehci_hcd

danach dann aber offenbar keine weiteren Treiber. Eigentlich müßte nach dem Laden der Hub-Treiber die Device-Enumeration am USB starten und dann die richtigen Treiber für die vorhandenen Geräte gestartet werden. Da ist dann eben "udevadm monitor" (siehst Du oben bei Al_) eine gewisse Hilfestellung, damit man erst einmal sieht, was der udevd da überhaupt macht.

Nach dem Laden den Treiber sollten aber auch bei Dir zumindest die Partitionen/Geräte sichtbar sein und dann läuft es event. auf dasselbe Problem wie bei Al_ hinaus ... mit derselben Test-Empfehlung und einer einfachen Prüfung, ob die Vermutung stimmen könnte (2x lsusb vorhanden bzw. 'lsusb' liefert dasselbe wie 'lsusb -vs', was dann das Busybox-lsusb sein müßte).

 

[gismotro]

Device wird nicht gefunden :

root@fritz:/var/mod/root# lsusb -vs /proc/diskstats
lsusb, mini USB device lister 1.1.1
Compiled on Aug 26 2014, 12:39:36
Reading /proc/bus/usb/devices

New device on line 2
Dev #1 on bus #2
Interface 0, class 09, subclass 00
BUS=002
DEV=001
VID=1d6b
PID=0001
CLS=09
SCL=00
SPEED='full'
VER='1.1'
MANU='Linux 2.6.28.10 ohci_hcd'
PROD='Ikanos On-Chip OHCI Host Controller'
SNUM='ikf68xx ohci'
ISOC=0
INUM=1
ICLS1=09
ISCL1=00

New device on line 13
Dev #1 on bus #1
Interface 0, class 09, subclass 00
BUS=001
DEV=001
VID=1d6b
PID=0002
CLS=09
SCL=00
SPEED='hi'
VER='2.0'
MANU='Linux 2.6.28.10 ehci_hcd'
PROD='Ikanos On-Chip EHCI Host Controller'
SNUM='ikf68xx ehci'
ISOC=0
INUM=1
ICLS1=09
ISCL1=00

root@fritz:/var/mod/root#

root@fritz:/var/mod/root# lsusb -vs /proc/partitions
lsusb, mini USB device lister 1.1.1
Compiled on Aug 26 2014, 12:39:36
Reading /proc/bus/usb/devices

New device on line 2
Dev #1 on bus #2
Interface 0, class 09, subclass 00
BUS=002
DEV=001
VID=1d6b
PID=0001
CLS=09
SCL=00
SPEED='full'
VER='1.1'
MANU='Linux 2.6.28.10 ohci_hcd'
PROD='Ikanos On-Chip OHCI Host Controller'
SNUM='ikf68xx ohci'
ISOC=0
INUM=1
ICLS1=09
ISCL1=00

New device on line 13
Dev #1 on bus #1
Interface 0, class 09, subclass 00
BUS=001
DEV=001
VID=1d6b
PID=0002
CLS=09
SCL=00
SPEED='hi'
VER='2.0'
MANU='Linux 2.6.28.10 ehci_hcd'
PROD='Ikanos On-Chip EHCI Host Controller'
SNUM='ikf68xx ehci'
ISOC=0
INUM=1
ICLS1=09
ISCL1=00

root@fritz:/var/mod/root#

Kann man an den scripten erkennen was der remove telephony patch macht ? Die Patche die in Abhängigkeit zum remove telephony gesetzt werden, verursachen den Fehler ja nicht.