# Kernelpatch=Problemursache?

## YPenguin

Was macht man, wenn ein Kernelpatch die Kompatibilität mit älterer Hardware bricht?

----------

## YPenguin

Ich habe eine PCI-USB3-Karte von Conrad mit einem NEC/Renesas µPD720201 Chip, die auch ein eigenes Firmware-ROM besitzt.

Im Sommer 2016 wurde ein Patch geschrieben für Karten mit 720201-Chip ohne eigenes Firmware-ROM - für diese wird die Firmware aus dem Firmwareverzeichnis geladen.

Firmware-Lader-Patch: https://lore.kernel.org/lkml/2306904.Kcdlk4rPkL@debian64/

Etwa zur gleichen Zeit traten bei mir Probleme mit meiner Karte auf, die auch mit Kernel 5.0 rc4 noch bestehen.

----------

## mike155

Hallo YPengiun,

das ist der dritte Thread zu diesem Thema:

https://forums.gentoo.org/viewtopic-t-1059240-start-0.html

https://forums.gentoo.org/viewtopic-t-1079998-start-0.html

Irgendwann ist es dann mal Zeit, eine neue Karte bzw. ein neues Motherboard zu kaufen. Das ist mir auch schon ein paar Mal passiert. Das ist dann zwar ärgerlich - aber besser, als  sich weiter zu ärgern...

Mike

----------

## YPenguin

Neue Hardware - ich denke, so machen es die meisten User, die weiter mit neuen Kerneln arbeiten wollen.

Andere benutzen ältere Kernel, die noch funktionieren, mit der bisherigen Hardware - meine derzeitige Lösung.

Die dritte Möglichkeit - den Patch zu korrigieren - wird wohl kaum genutzt, weil man sich dazu mehr oder weniger unter die Kernel-Programmierer begeben muss - oder sehe ich das falsch?

Mir fällt noch eine Möglichkeit 4 ein: Die Applikation des Patches verhindern - wie steht es damit?

----------

## schmidicom

Ich sehe das ähnlich wie mike155, irgendwann kommt man eben an den Punkt wo man akzeptieren muss das die eigene Hardware nicht mit Linux kompatibel ist. Ob und wann dieser Punkt erreicht ist muss natürlich jeder selber wissen.

Zum Thema "Die Applikation des Patches verhindern - wie steht es damit?":

Würde es sich um eine kleine Änderung in einem einzigen Treiber handeln dann wäre das sicher eine Möglichkeit aber in deinem Fall vermute ich eher grösseres. Es ist zwar nur ein Schuss ins blaue aber anhand dessen was du so alles gepostet hast würde ich eher ein Fehlverhalten im ACPI und dem Umgang damit vermuten welcher entstand (oder: erst bemerkbar wurde) als die Kernel-Devs ihre ACPICA-Implementation aktualisierten. Das rückgängig zu machen dürfte eine ziemliche Mammutaufgabe sein die hier ganz sicher keiner auf sich nimmt.

Zum Thema "Eine Idee für eine mögliche Lösung":

Wenn ich mit meiner Vermutung richtig liege würde es vielleicht auch helfen den Kernel beim boot anzuweisen sich gegenüber der Firmware als etwas anderes auszugeben als er es Standardmäßig machen würde (über "acpi_os_name=" und "acpi_osi="). Aber um diese Möglichkeit auszuloten müsstest du (wie bereits per PN nachgefragt) erst einmal deine "/sys/firmware/acpi/tables/DSDT" als ZIP öffentlich zur Verfügung stellen. Dann könnte man diese mit iasl dekompilieren und im SourceCode nachsehen was das ACPI deiner Firmware diesbezüglich überhaupt akzeptieren würde.

----------

## YPenguin

Ein ZIP meiner DSDT habe ich bereits hochgeladen - hier:

https://bugs.gentoo.org/attachment.cgi?id=562860&action=edit

----------

## schmidicom

Boote mal mit einem acpi_osi="!Windows 2006" in den Kernelparametern und schau was passiert.

PS: Wenn möglich wäre ein Firmware-Update auch nicht verkehrt, diese DSDT-Tabelle sieht aus als wäre sie im Vista-Zeitalter stecken geblieben.

----------

## YPenguin

Für µPD720201-Chips habe ich keine neuere Firmware als 2.0.2.6 gefunden - das Update habe ich unter Windows 7 gemacht und auch nochmal überprüft - angeblich alles OK laut Update-Utility.

Mein Update für das Firmware-ROM stammt von Station Drivers.

----------

## YPenguin

Relevante Links dazu:

1. Kernel 4.9 Patch-Homepage von Christian Lamparter:

https://github.com/chunkeey/apm82181-lede/blob/master/target/linux/apm821xx/patches-4.9/801-usb-xhci-add-firmware-loader-for-uPD720201-and-uPD72.patch

2. Renesas-Firmware aufbereitet von ebenfalls Christian Lamparter:

https://github.com/chunkeey/renesas-fw

----------

## YPenguin

Mir wäre es ja egal, ob die Firmware vom ROM benutzt wird oder die zum Laden - wenn es funktioniert.

----------

## schmidicom

Ich meinte damit nicht die USB-Firmware sondern die des Mainboards (aka BIOS oder UEFI) denn dort steckt das offensichtlich veraltete ACPI.

----------

## toralf

 *YPenguin wrote:*   

> Was macht man, wenn ein Kernelpatch die Kompatibilität mit älterer Hardware bricht?

 

Mail mit Problembeschreibung und möglichst der commit id (git bisect) an die LKML.

Der Grundsatz des Kernel Developmentpozesses ist unverändert: "Don't break userspace !" - Du hast also gute Karten.

----------

## YPenguin

 *schmidicom wrote:*   

> Ich meinte damit nicht die USB-Firmware sondern die des Mainboards (aka BIOS oder UEFI) denn dort steckt das offensichtlich veraltete ACPI.

 

Es ist ein ASUS P7P55D mit BIOS 2101 - da lässt sich nach meiner Kenntnis ASUS-seitig nichts mehr machen - neuestes BIOS, das verfügbar ist.

----------

## YPenguin

Ich habe "acpi_osi=!Windows 2006" als Bootparameter mit Kernel 5.0 rc4 ausprobiert, aber es reicht offenbar nicht, um das Problem zu lösen.

----------

## schmidicom

Und was passiert bei den folgenden beiden (bitte 1 und 2 einzeln/getrennt testen):

1. 

```
acpi_osi=!  acpi_os_name=Linux
```

2. 

```
acpi_osi=!!
```

----------

## YPenguin

@schmidicom

Ich bin mir nicht sicher, ob wir da auf der richtigen Spur sind.

Wenn der Fehler darin besteht, dass erst die Firmware aus dem ROM geladen wird und später die andere Firmware (des o. g. Patches), dann könnte die Karte dadurch in einen Zustand kommen, der irgendwie undefiniert ist, da so etwas normalerweise nicht gemacht wird.

Auch die Fehlermeldungen von einer Karte mit Firmwareproblem wären möglicherweise nicht aussagekräftig.

----------

## schmidicom

Keine Ahnung was du damit sagen willst aber auf die Reihenfolge wann und wie welche Hardwarekomponente initialisiert wird hast du genau null Einfluss, die Einstellungen von oben verändern lediglich das Verhalten des ACPI. Aber wenn du das nicht weiter verfolgen willst schön, ich kann dir dabei jedoch nicht weiterhelfen. Viel Glück...

----------

## YPenguin

Wenn man in ein Gerät zwei unterschiedliche Firmware-Versionen nacheinander lädt (ohne Ausschalten dazwischen), dann tut man etwas, was der Hardware-Hersteller wahrscheinlich nicht vorgesehen und auch nicht getestet hat.

Ob das Gerät dann noch funktioniert ist nicht sicher.

----------

## YPenguin

Für die Vollständigkeit des Threads: Die Karte heißt Renkforce 986823 und wird noch neu verkauft.

----------

## Christian99

wird denn überhaupt von Linux noch eine weitere firmware geladen?

wenn ja, dann lösche/umbenenne die Datei doch einfach mal.

----------

## YPenguin

Ich habe mir mal den Quelltext von Kernel 5.0 im Vergleich zu 4.1 angesehen. Da sind bei xhc-pci.c und pci-quirks.c einige neue Zeilen mit Bezug auf Renesas-Karten hinzugekommen.

Es werden offenbar einige Quirks gemacht (Auszug aus xhci-pci.c):

Aktuell:

```

   if (pdev->vendor == PCI_VENDOR_ID_RENESAS &&

       pdev->device == 0x0014) {

      xhci->quirks |= XHCI_TRUST_TX_LENGTH;

      xhci->quirks |= XHCI_ZERO_64B_REGS;

   }

   if (pdev->vendor == PCI_VENDOR_ID_RENESAS &&

       pdev->device == 0x0015) {

      xhci->quirks |= XHCI_RESET_ON_RESUME;

      xhci->quirks |= XHCI_ZERO_64B_REGS;

   }

```

Kernel 4.1:

```

        if (pdev->vendor == PCI_VENDOR_ID_RENESAS &&

                        pdev->device == 0x0015)

                xhci->quirks |= XHCI_RESET_ON_RESUME;

```

----------

## YPenguin

In Kernel 5.0 xhci.c:

```

        if (xhci->quirks & XHCI_NEC_HOST) {

                struct xhci_command *command;

                command = xhci_alloc_command(xhci, false, GFP_KERNEL);

                if (!command)

                        return -ENOMEM;

                ret = xhci_queue_vendor_command(xhci, command, 0, 0, 0,

                                TRB_TYPE(TRB_NEC_GET_FW));

                if (ret)

                        xhci_free_command(xhci, command);

        }

```

und:

```

        /*

         * Some Renesas controllers get into a weird state if they are

         * reset while programmed with 64bit addresses (they will preserve

         * the top half of the address in internal, non visible

         * registers). You end up with half the address coming from the

         * kernel, and the other half coming from the firmware. Also,

         * changing the programming leads to extra accesses even if the

         * controller is supposed to be halted. The controller ends up with

         * a fatal fault, and is then ripe for being properly reset.

         *

         * Special care is taken to only apply this if the device is behind

         * an iommu. Doing anything when there is no iommu is definitely

         * unsafe...

         */

```

----------

## YPenguin

modprobe -r xhci_pci und modprobe xhci_pci:

[  185.054867] xhci_hcd 0000:08:00.0: Refused to change power state, currently in D3

[  185.105290] xhci_hcd 0000:08:00.0: xHCI Host Controller

[  185.105377] xhci_hcd 0000:08:00.0: new USB bus registered, assigned bus number 3

[  185.165751] hrtimer: interrupt took 30173943 ns

[  185.256273] xhci_hcd 0000:08:00.0: Host halt failed, -19

[  185.256276] xhci_hcd 0000:08:00.0: can't setup: -19

[  185.256280] xhci_hcd 0000:08:00.0: USB bus 3 deregistered

[  185.276570] xhci_hcd 0000:08:00.0: init 0000:08:00.0 fail, -19

----------

## YPenguin

Bei Arch-Linux gibt es einen ähnlichen Thread: https://bbs.archlinux.org/viewtopic.php?id=236806

----------

## YPenguin

Im dmesg-Protokoll werden im Bootvorgang keine Quirks erwähnt - werden sie beim Booten nicht angewendet?

----------

## YPenguin

Quirks werden sonst in dmesg protokolliert wie dies Beispiel:

xhci_hcd 0000:45:00.0: hcc params 0x014051cf hci version 0x100 quirks 0x01000090

----------

## YPenguin

Ich habe in der Vergangenheit aus Neugier mal Powertop installiert und dann auf dem System gelassen (wie es auch bei einigen der Arch-Linux-User der Fall war).

----------

## YPenguin

Ich glaube mittlerweile nicht mehr, dass der Patch von Christian Lamparter das Problem verursacht hat, obwohl er zeitlich passen würde (Kernel 4.9). Es sieht ja aus, als ob dieser Patch nur bei LEDE und OpenWRT integriert wurde.

----------

## YPenguin

Das der Bootvorgang mit einer 2019er Gentoo-Minimal-CD bei xhci hängen bleibt, spricht aber für ein echtes Kernelproblem. Vielleicht wird der Renesas-Controller in den seltsamen Zustand versetzt, von dem im Kommentar die Rede war.

----------

