Re: Kernel und Module

On Thu, Nov 08, 2012 at 09:43:10AM +0100, Gerhard Brauer wrote:
> 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.

Bei meinem T61 habe ich das Resumen noch nicht ganz hinbekommen. Hier
läfut der Rechner nach dem Aufwachen zwar normal, aber die Grafik ist
durcheinander, nur der Mauszeiger sieht noch okay aus und lässt sich wie
gewohnt bewegen.
Da macht's auch keinen Unterschied, ob ich
hw.acpi.reset_video auf 0 oder 1 setze. (PCBSD 9.1-RC3, amd64, Intel
Grafik und WITH_NEW_XORG=yes).

Das T60 ist AFAIK aber ein etwas älteres Modell, vielleicht hast du da
mehr Glück.

Zum USB Problem: Da habe ich auf meinem TP X200, dass es beim ersten
Aufwachen alles gut, ist, aber ab dem 2. Aufwachen sind die externen USB
Ports tot, nur noch die beiden Geräte, die intern verbaut sind (3G
Modem, Webcam) sind noch ansprechbar.
Jegliche Kombination von unload / load der [eux]hci Module hat keinen
Erfolg gebracht, hps, der Entwickler des USB Stacks schiebt es auf
Lenovo.
Komisch ist nur, dass externe Geräte, solange sie noch funktionieren,
beim Suspend weiter eingeschaltet bleiben und erst beim Resume ausgehen.

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 - 14:30:39 CET