Re: Kernel und Module

On Wed, Nov 07, 2012 at 04:26:54PM +0100, Oliver Fromme wrote:
>
> Insofern ist es durchaus keine schlechte Idee, jene Treiber,
> die nicht so richtig mitspielen wollen, unmittelbar vor dem
> Suspend zu entladen und nach dem Resume wieder zu laden.
> Dies ist im rc-Framework auch bereits vorgesehen; usb steht
> dort sogar als Beispiel drin.

Ich kam nun dazu etwas ausführlicher zu testen, auch und gerade hinsichtlich
Fabians Hinweis auf usbconfig. Das alles noch mit dem GENERIC-Kernel.

Das ist der Auszug aus messages nach einem Suspend/Resume:
------------
Nov 8 07:56:02 bsd acpi: suspend at 20121108 07:56:02
Nov 8 07:56:23 bsd kernel: re0: link state changed to DOWN
Nov 8 07:56:29 bsd kernel: ukbd0: at uhub0, port 2, addr 3 (disconnected)
Nov 8 07:56:29 bsd kernel: ums1: at uhub0, port 2, addr 3 (disconnected)
Nov 8 07:56:29 bsd kernel: usbd_req_re_enumerate: addr=3, set address failed! (USB_ERR_IOERROR, ignored)
Nov 8 07:56:29 bsd kernel: usbd_setup_device_desc: getting device descriptor at addr 3 failed, USB_ERR_IOERROR
Nov 8 07:56:29 bsd kernel: re0: link state changed to UP
Nov 8 07:56:29 bsd kernel: usbd_req_re_enumerate: addr=3, set address failed! (USB_ERR_IOERROR, ignored)
Nov 8 07:56:29 bsd kernel: usbd_setup_device_desc: getting device descriptor at addr 3 failed, USB_ERR_IOERROR
Nov 8 07:56:29 bsd kernel: ums0: at uhub0, port 1, addr 2 (disconnected)
Nov 8 07:56:29 bsd kernel: ums2: at uhub3, port 1, addr 2 (disconnected)
Nov 8 07:56:29 bsd kernel: usbd_req_re_enumerate: addr=2, set address failed! (USB_ERR_IOERROR, ignored)
Nov 8 07:56:29 bsd kernel: usbd_setup_device_desc: getting device descriptor at addr 2 failed, USB_ERR_IOERROR
Nov 8 07:56:29 bsd kernel: usbd_req_re_enumerate: addr=2, set address failed! (USB_ERR_IOERROR, ignored)
Nov 8 07:56:29 bsd kernel: usbd_setup_device_desc: getting device descriptor at addr 2 failed, USB_ERR_IOERROR
Nov 8 07:56:29 bsd kernel: usbd_req_re_enumerate: addr=2, set address failed! (USB_ERR_IOERROR, ignored)
Nov 8 07:56:29 bsd kernel: usbd_setup_device_desc: getting device descriptor at addr 2 failed, USB_ERR_IOERROR
Nov 8 07:56:29 bsd kernel: ugen0.3: <USB Composite Keyboard> at usbus0 (disconnected)
Nov 8 07:56:29 bsd kernel: ugen0.2: <PIXART> at usbus0 (disconnected)
Nov 8 07:56:29 bsd kernel: usbd_req_re_enumerate: addr=2, set address failed! (USB_ERR_IOERROR, ignored)
Nov 8 07:56:29 bsd kernel: usbd_setup_device_desc: getting device descriptor at addr 2 failed, USB_ERR_IOERROR
Nov 8 07:56:29 bsd kernel: ugen3.2: <Logitech> at usbus3 (disconnected)
Nov 8 07:56:29 bsd acpi: resumed at 20121108 07:56:29
--------------

Das ist die Ausgabe von usbconfig (also die Geräte). Die normale Tastatur und
Maus sind 0.2 und 0.3, ugen2.3 ist eine Testmaus an einem zusätzlichen USB-Hub:
--------
ugen0.1: <OHCI root HUB ATI> at usbus0, cfg=0 md=HOST spd=FULL (12Mbps) pwr=SAVE
ugen1.1: <OHCI root HUB ATI> at usbus1, cfg=0 md=HOST spd=FULL (12Mbps) pwr=SAVE
ugen2.1: <EHCI root HUB ATI> at usbus2, cfg=0 md=HOST spd=HIGH (480Mbps) pwr=SAVE
ugen3.1: <OHCI root HUB ATI> at usbus3, cfg=0 md=HOST spd=FULL (12Mbps) pwr=SAVE
ugen4.1: <OHCI root HUB ATI> at usbus4, cfg=0 md=HOST spd=FULL (12Mbps) pwr=SAVE
ugen5.1: <EHCI root HUB ATI> at usbus5, cfg=0 md=HOST spd=HIGH (480Mbps) pwr=SAVE
ugen6.1: <OHCI root HUB ATI> at usbus6, cfg=0 md=HOST spd=FULL (12Mbps) pwr=SAVE
ugen0.2: <USB OPTICAL MOUSE PIXART> at usbus0, cfg=0 md=HOST spd=LOW (1.5Mbps) pwr=ON
ugen2.2: <USB2.0 Hub vendor 0x05e3> at usbus2, cfg=0 md=HOST spd=HIGH (480Mbps) pwr=SAVE
ugen0.3: <USB KB USB Composite Keyboard> at usbus0, cfg=0 md=HOST spd=LOW (1.5Mbps) pwr=ON
ugen2.3: <USB Optical Mouse Logitech> at usbus2, cfg=0 md=HOST spd=LOW (1.5Mbps) pwr=ON
-----------

Was jetzt spannend ist: Außer mit USB habe ich an dem PC keinerlei Probleme
mit Suspend/resume, ich verwende ACPI und leite den Suspend mit: acpiconf -s 3
ein. Nach dem Resume funktionieren Netzwerk und Grafik(nvidia) ohne Probleme.
Mit USB ist es insofern interessant:

a) es betrifft scheinbar nur die Root-Hubs, also die internen Anschlüsse auf
dem Mainboard. nach dem Resume sind ugen0.2 und 0.3 weg und auch durch
Umstecken nicht wieder zu erwecken. Stecke ich hingegen egal wo einen
USB-Speicherstick an (oder war dieser gesteckt), dann ist dieses Gerät auch
nach einem Resume wieder/noch voll funktionstüchtig. der USB-Bus ist also
nicht vollkommen "tot". Lediglich die Eingabegeräte klappen nicht mehr, bzw.
evtl. die USB1/low-speed Geräte(?).

b) Die Zusatzmaus am externen USB-Hub(ugen2.2) hingegen ist nach dem Resume
mit usbconfig noch sichtbar, hakelt allerdings und löst willkürliche
Button-Events aus. Das kann ich allerdings durch ein: usbconfig -d 2.2 reset
wieder beheben. Mit einer Tastatur wäre es sicher das Gleiche. Diesen Reset
kann ich leider auf die Root-Hubs nicht ausführen, auch andere
usbconfig-Aktionen bringen die Eigabegeräte an den internen Anschlüssen nicht
wieder zum Leben. Auch die diversen quirks bei usbconfig schienen mir dafür
keine Hilfe.
Mit sysctl habe ich (außer ggf. die Debug-Optionen) nichts
gesehen, wo ich sagen würde: daß und daß setze ich mal so.

c) Mit einer PS/2-Tastatur klappt der Resume problemlos. Wenn ich meine
USB-Eingabegeräte an den externen USB-Hub hängen würde, dann könnte ich auf
diesen wohl in /etc/rc.resume mittels usbconfig einen Reset anstoßen. So
könnte ich mich kurzfristig wohl "durchmogeln".

Generell ist mein Fazit: Suspend/resume klappt auch unter FreeBSD. Auch unter
Linux hatte ich früher manches Problem (von Kernelversion zu Kernelversion,
wobei das meist die Grafiktreiber waren). Das Problem wird sich wohl am Besten
in den Griff kriegen lassen mit Modulen für usb/ehci/ohci etc., dann sind die
über die rc.*-Skripte ent-/wiederladbar. Das wird wohl auch die
Onboard-Root-Hubs wieder erwecken. Ich werde also wirklich mal an den
Kernelbau gehen, wobei Suspend jetzt aktuell für mich noch nicht die primäre
Baustelle ist. Aber ich bin mir sicher daß es funktionieren wird, ich hatte
eher im Bereich Grafiktreiber mit Problemen gerechnet.

Wenn allerdings noch jemand wüßte, wie ich die internen-USB-Root-Hubs mit dem
GENERIC-Kernel "resetten" könnte, dann würde ich das gerne noch versuchen.

Später steht irgendwann noch ein T60 Thinkpad für FreeBSSD an, dort erwarte
ich z.B. dieses Problem nicht. So ein USB-Problem ist ja ggf. auch Chipsatz
und Board-Hersteller abhängig.

So, das war's erstmal von der USB-Front. Muß mir dringend meine vimrc
rüberholen, der vi-Modus bringt mich noch ins Grab ;-)

Gruß
        Gerhard

To Unsubscribe: send mail to majordomo(at)de.FreeBSD.org
with "unsubscribe de-bsd-questions" in the body of the message
Received on Thu 08 Nov 2012 - 09:48:59 CET