USB,kernel2.6.x, mass-storage. /dev/sdax gibts nich mehr

Hi,

sichewrlich gibts hier schon threads zum thema.. ich bin aber selten hier, und deshalb fehlt mir bissl der überblick.. ggf. genügt mir schon ein link zum betreffenden thread..

also.

hab ein prob mit usb-stroga-geräten (z.B. usb-platten und -sticks)

früher waren die auf /dev/sda1 anzusprechen (bzw. sda2, sda3.. je nach partitionstabelle..)

irgendwie gibts das aber nich mehr..
mein pc erkennt unter dieser adresse jene laufwerke nich mehr..

vor paar wochen hab ich schon mal bissl gebastelt und geflickt..
irgendwie wollen die jetzt als /dev/uba1 usw.. angesprochen werden,
zusätzlich musste ich entsprechende gerätedateien erst mit mknod anlegen..

zusätzlich hab ich nun das prob,
dass das mounten nich mehr richtig funzt..
umount friert ein..

irgendwie wurden wohl verschiedne USB-sachen grundlegend in den 2.6er kernel geändert..

wo find ich was, wie das nun mit usb gehandhabt wird?

Also ich benutze den 2.6.10er und habe immernoch meine /dev/sdX-Namen für USB-Devices.
Evtl solltest du mal prüfen, ob du in deinem Kernel SCSI, SCSI-disk, SCSI-generic und natürlich das Ganze USB-Zeug inklusive storage in deinem Kernel hast.
Ausserdem ist Hotplugging und ein Hotplugging-Daemon auch äußerst vorteilhaft wenns um sowas geht. ;)

Shutdown

Bei mir laufen Sticks und externe USB2.0-Platten ebenfalls nach wie vor
mit dem SCSI-Interface (Kernel 2.6.9, Debian).
Ohne detailliertere Angaben zu Deinem System wird kaum jemand helfen
können.

Gruß,
Wolfgang

nun ja,

ich verwende die vorkompilierten debian-kernel
(debian testing)
derzeit 2.6.9-1-k7
da dürfte doch alles nötige mit dabei sein, oder?

welche module müssen geladen sein,

damit usb-massenspeicherzeugs richtig funzt? (usb 2.0)

(bzw. welche module müsste ich nachladen?)

2.) wenn man die module manuell lädt,
wann ist der beste zeitpunkt?

erst laden, dann platte/stick anstecken, oder umgekehrt?

desweiteren scheints mir,
als würden usb-1.1-treiber bevorzugt werden..
..als ich noch keine probs mit der geräteerkennung und dem mounten hatte,
hatte ich trotzdem das prob, dass erstmal alles in 1.1er geschwindigkeit lief.. was aber grade bei speichergeräten ungünstig ist...

Die Module müssen geladen sein bevor du irgendwas einstöpselst, da die Erkennung sonst evtl nicht funktioniert.
Die benötigten Module wären auf jeden Fall mal scsi_mod, sd_mod, usbcore, ehci-hcd / ohci-hcd / uhci-hdc und usb-storage.
Falls ich irgendwas vergessen hätte bitte ergänzen.

Shutdown

Zitat:

---

Zitat von roburfreak

ich verwende die vorkompilierten debian-kernel
(debian testing)
derzeit 2.6.9-1-k7
da dürfte doch alles nötige mit dabei sein, oder?

---

Den benutze ich auch auf einem Rechner (wenn auch nicht k7-Version).
Ich lade keine Module manuell, die Debian Hotplug-Skripte funktionieren
bei mir. Einer der Rechner hat 2 USB Kontroller onboard (1.1 + 2.0)
und ein Stick funktioniert an beiden (jeweils mit uhci_hcd oder ehci_hcd
+ usb_storage).
Auf einem Notebook mit CARDBUS-USB2-Karte (NEC) funktioniert das
auch ohne manuelles Laden von Modulen (Kernel ist Standard Debian
2.6.9-1-686) auf Sarge (gerade noch mit Transcend-Stick getestet).
Geladene relevante Module sind hier (wie auch von Shutdown genannt):
usbcore, ehci_hcd, uhci_hcd, usb_storage, scsi_mod, sd_mod.

Es hängt evtl. auch von Deiner Hardware ab (wie die USB-Hubs/Busse
registriert werden, die Kennung die USB-Geräte liefert).
Vielleicht hilft lsusb (evtl. mit -t oder -v) bei Problemen damit.

Falls das USB1-Modul bevorzugt wird, und Du es sonst nicht benutzt,
kannst Du es für hotplug "blacklisten": trage den Modulnamen in
/etc/hotplug/blacklist ein.

Ebenfalls zum Thema Massenspeicher: für den USB2.0-Brenner mußte
ich bei diesem Debian-Kernel das Modul ub manuell entfernen, da
damit das Gerät erkannt wurde, beim Betrieb jedoch I/O-Errors auftraten
(ub ist der USB Blockgerätetreiber für "langsame" Geräte).

Was wichtig sein könnte: USB-Storage-Geräte erst nach dem Booten
anstöpseln.
HTH
Wolfgang

...hmm.

geht immer noch nicht.

der kernel erkennt zwar etwas,
aber nich als /dev/sda, sondern als /dev/ub

hier: (var/log/messages)

Code:

---

Jan  7 10:52:11 localhost kernel: Initializing USB Mass Storage driver...
Jan  7 10:52:11 localhost kernel: usbcore: registered new driver usb-storage
Jan  7 10:52:11 localhost kernel: USB Mass Storage support registered.
Jan  7 10:52:21 localhost kernel: usb 4-6: new high speed USB device using addres
s 3
Jan  7 10:52:22 localhost kernel: ub: sizeof ub_scsi_cmd 60 ub_dev 924
Jan  7 10:52:22 localhost kernel: uba: device 3 capacity nsec 128384 bsize 512
Jan  7 10:52:22 localhost kernel: uba: was not changed
Jan  7 10:52:22 localhost kernel:  /dev/ub/a: p1
Jan  7 10:52:22 localhost kernel: usbcore: registered new driver ub
Jan  7 10:52:22 localhost usb.agent[8889]:      ub: loaded successfully
Jan  7 10:54:00 localhost kernel: usb 4-6: USB disconnect, address 3
Jan  7 10:54:05 localhost kernel: usb 4-6: new high speed USB device using addres
s 4
Jan  7 10:54:06 localhost usb.agent[8997]:      ub: already loaded
Jan  7 10:54:06 localhost kernel: uba: device 4 capacity nsec 128384 bsize 512
Jan  7 10:54:06 localhost kernel: uba: was not changed
Jan  7 10:54:06 localhost kernel:  /dev/ub/a: p1

---

..irgendwie muss das doch trotzdem gehen..

viele andere leute haben bei gleichem kernel dieses Prob nicht.
und früher gings auch..

kann ich irgendwie ne erkennung als /dev/sda erzwingen?

-------------
wenn ich ub in etc/hotplug/blacklist reinschreibe,
erschein lediglich
Jan 7 xx:xx:xx localhost usb.agent[xxxx]: ub: blacklisted
(statt ub: loaded)

Gib uns mal bitte direkt nach deim Einstöpseln von dem Device die paar letzen Zeilen von dmesg...
Vielleicht lässt sich da noch was sehen.

Shutdown

dmesg:

Code:

---

input irq status -84 received
drivers/usb/input/hid-core.c: input irq status -84 received

#-----
#immer die gleiche zeile.. ca. 100x.. gekürzt *schnipp*
#-----

drivers/usb/input/hid-core.c: input irq status -84 received
ehci_hcd 0000:00:10.3: remove, state 1
usb usb4: USB disconnect, address 1
usb 4-6: USB disconnect, address 3
ehci_hcd 0000:00:10.3: USB bus 4 deregistered
uhci_hcd 0000:00:10.0: remove, state 1
usb usb1: USB disconnect, address 1
uhci_hcd 0000:00:10.0: USB bus 1 deregistered
uhci_hcd 0000:00:10.1: remove, state 1
usb usb2: USB disconnect, address 1
uhci_hcd 0000:00:10.1: USB bus 2 deregistered
uhci_hcd 0000:00:10.2: remove, state 1
hub 3-0:1.0: hub_port_status failed (err = -19)
hub 3-0:1.0: connect-debounce failed, port 2 disabled
hub 3-0:1.0: cannot disable port 2 (err = -19)
usb usb3: USB disconnect, address 1
usb 3-1: USB disconnect, address 2
uhci_hcd 0000:00:10.2: USB bus 3 deregistered
ACPI: PCI interrupt 0000:00:10.3[D] -> GSI 21 (level, low) -> IRQ 177
ehci_hcd 0000:00:10.3: VIA Technologies, Inc. USB 2.0
ehci_hcd 0000:00:10.3: irq 177, pci mem e09c8f00
ehci_hcd 0000:00:10.3: new USB bus registered, assigned bus number 1
ehci_hcd 0000:00:10.3: USB 2.0 enabled, EHCI 1.00, driver 2004-May-10
hub 1-0:1.0: USB hub found
hub 1-0:1.0: 6 ports detected
ohci_hcd: 2004 Feb 02 USB 1.1 'Open' Host Controller (OHCI) Driver (PCI)
USB Universal Host Controller Interface driver v2.2
ACPI: PCI interrupt 0000:00:10.0[A] -> GSI 21 (level, low) -> IRQ 177
uhci_hcd 0000:00:10.0: VIA Technologies, Inc. VT82xxxxx UHCI USB 1.1 Controller
uhci_hcd 0000:00:10.0: irq 177, io base 0000e000
uhci_hcd 0000:00:10.0: new USB bus registered, assigned bus number 2
hub 2-0:1.0: USB hub found
hub 2-0:1.0: 2 ports detected
ACPI: PCI interrupt 0000:00:10.1[B] -> GSI 21 (level, low) -> IRQ 177
uhci_hcd 0000:00:10.1: VIA Technologies, Inc. VT82xxxxx UHCI USB 1.1 Controller(#2)
uhci_hcd 0000:00:10.1: irq 177, io base 0000e400
uhci_hcd 0000:00:10.1: new USB bus registered, assigned bus number 3
usb 1-6: new high speed USB device using address 3
hub 3-0:1.0: USB hub found
hub 3-0:1.0: 2 ports detected
ACPI: PCI interrupt 0000:00:10.2[C] -> GSI 21 (level, low) -> IRQ 177
uhci_hcd 0000:00:10.2: VIA Technologies, Inc. VT82xxxxx UHCI USB 1.1 Controller(#3)
uba: device 3 capacity nsec 128384 bsize 512
uba: was not changed
 /dev/ub/a: unknown partition table
uhci_hcd 0000:00:10.2: irq 177, io base 0000e800
uhci_hcd 0000:00:10.2: new USB bus registered, assigned bus number 4
hub 4-0:1.0: USB hub found
hub 4-0:1.0: 2 ports detected
usb 4-1: new low speed USB device using address 2
input: USB HID v1.10 Mouse [Logitech USB Mouse] on usb-0000:00:10.2-1
usb 1-6: USB disconnect, address 3

#--------------
# an dieser stelle hatte ich den stick rausgenommen (.s.letzte zeile)
#und wieder eingestöpselt

usb 1-6: new high speed USB device using address 5
uba: device 5 capacity nsec 128384 bsize 512
uba: was not changed
 /dev/ub/a: unknown partition table

---

nochn prob..

hab ja weiterhin rumprobiert.. dabei /dev/uba und /dev/uba1 gelöscht und wieder angelegt..

nach nem neustart waren die von selber wieder verschwunden..

es gab da noch nen befehl mit irgend ner option,
womit ich die datei "unlöschbar" machen konnte.. bzw. so, dass sie nich einfach so vom system gelöscht wird..
weiß das einer, wie das hieß.. ich bin vergesslich..

..noch ne ergänzung..
den betreffenden stick hatte ich vor kurzem versehentlich in der waschmaschine,
hab ihn bissl getestet,
scheint noch zu funzen..
grade hab ich ihn per winblows frisch partitioniert und formatiert und gescandiskt
...
aber es liegt nich am stick..
das eigentl. prob tritt auch mit meinem anderen stick (1.1er) und meiner externen usb-platte (120GB 3,5") auf.
konnt ich alles früher per /dev/sdax ansprechen.. nun nich mehr..

Hallo,

Anscheinend hast Du den gleichen VIA USB2.0-onboard wie ich in einem ASUS P4XP-X.
Mit dieser Kombination (VIA+USB2.0+USB1.1+ ub-Treiber) hatte ich ich auch Probleme,
die ich durch Entfernen des Moduls ub aus dem Kernel beseitigt habe
(allerdings lief der Stick bei mir damit, nur der Brenner nicht).
Ich weiß nicht, wieso bei Dir ohci_hcd geladen wird. Der VIA-Controller
braucht den nicht.

Versuche mal folgendes: finde das Modul ub.ko in /lib/modules/<kernel_version>
und verschiebe es irgendwohin (weg aus /lib/modules).
Führe danach aus: update-modules und teste nochmal.
Wenn dann die SCSI-Emulation beim anstecken des USB-Stick nicht geladen
wird, lade die Modules manuell.
Ansonsten würde eine Kernelkompilierung ohne ub helfen (zumindest war
das bei mir auf jenem Board so).

Gruß,
Wolfgang

PS: manuelles Löschen in /dev bringt nichts, wenn udev läuft.
Die /dev-Dateien werden nach den Regeln von udev (-> /etc/udev)
beim Laden der Treiber erstellt.

board ist msi kt400.

..ach was solls..

hab weiterhin rumgegoogelt.
prob scheint mit 2.6.9 zusammenzuhängen,
ab da wurde das anders gehandhabt..
prob sei bekannt..

vermutlich ist dann im 2.6.10er das prob gelöst..
noch gibts keine kernel-images von debian.. auf die wart ich noch.

kernel selber backen is mir zu aufwändig..
(hab ich schon öfters mal gemacht)
nun ja, wenn die debian-images von 2.6.10 raus sind und nich funzen,
dann werd ich doch wohl mal wieder backen müssen..

ub.ko hatt ich umbenannt.
hat nix gebracht.

immer noch will ich wissen:
wie "konservier" ich die gerätedateien, die ich selber anlege?

Zitat:

---

Zitat von roburfreak

immer noch will ich wissen:
wie "konservier" ich die gerätedateien, die ich selber anlege?

---

kopiere die Gerätedateien nach /etc/udev/devices.
(die binären NVidia-Treiber machen das auf Debian so)

Ich hatte mit dem 2.6.9er keine solchen Probleme...und mit dem 2.6.10 hab ich ja auch keine :D
Ich weiss aber auch nicht an was es sonst so liegen könnte...sorry :(

Shutdown

hallo, ich habe derzeit ein ähnliches Problem. Ich habe auch den kernel 2.6.10 und mein usb lief bis ich meinen KDE aktualisiert habe. Weil ich noch ein altes udev packet hatte habe ich jetzt das 050 packet und seid dem habe auf dem desktop eine /sys partition aber nun zu meinem eigenentlichen problem:

Ich stecke den USB-Stick an und dmesg bringt keine fehler weder als SCSI Emulation noch als UBA und im /sys/blocks findet man da dann auch ein uba ider sda. Doch seid dem ich nun die KDE-Packete drauf habe wird in /dev weder ub noch sda rein geschrieben. Hat jemand eine Idee wo das Problem liegen könnte? Ich muss im kernel noch mal die nervigen debug messages ausschalten dann kann ich auch noch mal die dmesg message posten.

also ich kann da auch noch was beitragen bei mir war es so das auch ganz viele fehler im demsg erschienen wenn ich den usbstick einsteckte. Alle 20 mal probieren ging er auch. ganz komisch. nach langem probieren kam ich darauf das sich ehci und uhci nicht mit einander vertragen. das ehci lief äußerst fehler haft. mal gins mal gings nicht. also entschied ich mich auf usb2.0 zu verzichten udn nutze nun wieder usb1.1. für meinen Stick reicht das allemale.

mfg nana