Gentoo Forums
Gentoo Forums
Gentoo Forums
Quick Search: in
Kernelpatch=Problemursache?
View unanswered posts
View posts from last 24 hours
View posts from last 7 days

Goto page 1, 2  Next  
Reply to topic    Gentoo Forums Forum Index Deutsches Forum (German)
View previous topic :: View next topic  
Author Message
YPenguin
Apprentice
Apprentice


Joined: 26 Apr 2014
Posts: 278
Location: Kenzingen, Germany

PostPosted: Fri Feb 01, 2019 11:10 am    Post subject: Kernelpatch=Problemursache? Reply with quote

Was macht man, wenn ein Kernelpatch die Kompatibilität mit älterer Hardware bricht?
_________________
Languages: English, German
Back to top
View user's profile Send private message
YPenguin
Apprentice
Apprentice


Joined: 26 Apr 2014
Posts: 278
Location: Kenzingen, Germany

PostPosted: Fri Feb 01, 2019 11:14 am    Post subject: Mein konkretes Problem Reply with quote

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.
_________________
Languages: English, German
Back to top
View user's profile Send private message
mike155
Veteran
Veteran


Joined: 17 Sep 2010
Posts: 1452
Location: Frankfurt, Germany

PostPosted: Fri Feb 01, 2019 12:38 pm    Post subject: Reply with quote

Hallo YPengiun,

das ist der dritte Thread zu diesem Thema:
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
Back to top
View user's profile Send private message
YPenguin
Apprentice
Apprentice


Joined: 26 Apr 2014
Posts: 278
Location: Kenzingen, Germany

PostPosted: Fri Feb 01, 2019 1:23 pm    Post subject: Neue Hardware Reply with quote

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?
_________________
Languages: English, German
Back to top
View user's profile Send private message
schmidicom
Veteran
Veteran


Joined: 09 Mar 2006
Posts: 1579
Location: Schweiz

PostPosted: Fri Feb 01, 2019 2:50 pm    Post subject: Reply with quote

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.
_________________
GPG: 0x3FC78AEE51E5FB95
Back to top
View user's profile Send private message
YPenguin
Apprentice
Apprentice


Joined: 26 Apr 2014
Posts: 278
Location: Kenzingen, Germany

PostPosted: Fri Feb 01, 2019 3:05 pm    Post subject: /sys/firmware/acpi/tables/DSDT Reply with quote

Ein ZIP meiner DSDT habe ich bereits hochgeladen - hier:
https://bugs.gentoo.org/attachment.cgi?id=562860&action=edit
_________________
Languages: English, German
Back to top
View user's profile Send private message
schmidicom
Veteran
Veteran


Joined: 09 Mar 2006
Posts: 1579
Location: Schweiz

PostPosted: Fri Feb 01, 2019 4:02 pm    Post subject: Reply with quote

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.
_________________
GPG: 0x3FC78AEE51E5FB95
Back to top
View user's profile Send private message
YPenguin
Apprentice
Apprentice


Joined: 26 Apr 2014
Posts: 278
Location: Kenzingen, Germany

PostPosted: Fri Feb 01, 2019 4:24 pm    Post subject: Reply with quote

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.
_________________
Languages: English, German


Last edited by YPenguin on Fri Feb 01, 2019 4:31 pm; edited 1 time in total
Back to top
View user's profile Send private message
YPenguin
Apprentice
Apprentice


Joined: 26 Apr 2014
Posts: 278
Location: Kenzingen, Germany

PostPosted: Fri Feb 01, 2019 4:29 pm    Post subject: Reply with quote

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
_________________
Languages: English, German
Back to top
View user's profile Send private message
YPenguin
Apprentice
Apprentice


Joined: 26 Apr 2014
Posts: 278
Location: Kenzingen, Germany

PostPosted: Fri Feb 01, 2019 4:35 pm    Post subject: Reply with quote

Mir wäre es ja egal, ob die Firmware vom ROM benutzt wird oder die zum Laden - wenn es funktioniert.
_________________
Languages: English, German
Back to top
View user's profile Send private message
schmidicom
Veteran
Veteran


Joined: 09 Mar 2006
Posts: 1579
Location: Schweiz

PostPosted: Fri Feb 01, 2019 5:02 pm    Post subject: Reply with quote

Ich meinte damit nicht die USB-Firmware sondern die des Mainboards (aka BIOS oder UEFI) denn dort steckt das offensichtlich veraltete ACPI.
_________________
GPG: 0x3FC78AEE51E5FB95
Back to top
View user's profile Send private message
toralf
Developer
Developer


Joined: 01 Feb 2004
Posts: 3698
Location: Hamburg

PostPosted: Fri Feb 01, 2019 6:00 pm    Post subject: Re: Kernelpatch=Problemursache? Reply with quote

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.
Back to top
View user's profile Send private message
YPenguin
Apprentice
Apprentice


Joined: 26 Apr 2014
Posts: 278
Location: Kenzingen, Germany

PostPosted: Fri Feb 01, 2019 6:30 pm    Post subject: Reply with quote

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.
_________________
Languages: English, German
Back to top
View user's profile Send private message
YPenguin
Apprentice
Apprentice


Joined: 26 Apr 2014
Posts: 278
Location: Kenzingen, Germany

PostPosted: Fri Feb 01, 2019 7:33 pm    Post subject: "acpi_osi=!Windows 2006" Reply with quote

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.
_________________
Languages: English, German
Back to top
View user's profile Send private message
schmidicom
Veteran
Veteran


Joined: 09 Mar 2006
Posts: 1579
Location: Schweiz

PostPosted: Sat Feb 02, 2019 8:43 am    Post subject: Reply with quote

Und was passiert bei den folgenden beiden (bitte 1 und 2 einzeln/getrennt testen):
1.
Code:
acpi_osi=!  acpi_os_name=Linux

2.
Code:
acpi_osi=!!

_________________
GPG: 0x3FC78AEE51E5FB95
Back to top
View user's profile Send private message
YPenguin
Apprentice
Apprentice


Joined: 26 Apr 2014
Posts: 278
Location: Kenzingen, Germany

PostPosted: Sat Feb 02, 2019 10:10 am    Post subject: Reply with quote

@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.
_________________
Languages: English, German


Last edited by YPenguin on Sat Feb 02, 2019 1:17 pm; edited 1 time in total
Back to top
View user's profile Send private message
schmidicom
Veteran
Veteran


Joined: 09 Mar 2006
Posts: 1579
Location: Schweiz

PostPosted: Sat Feb 02, 2019 1:09 pm    Post subject: Reply with quote

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...
_________________
GPG: 0x3FC78AEE51E5FB95
Back to top
View user's profile Send private message
YPenguin
Apprentice
Apprentice


Joined: 26 Apr 2014
Posts: 278
Location: Kenzingen, Germany

PostPosted: Sat Feb 02, 2019 9:11 pm    Post subject: Reply with quote

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.
_________________
Languages: English, German
Back to top
View user's profile Send private message
YPenguin
Apprentice
Apprentice


Joined: 26 Apr 2014
Posts: 278
Location: Kenzingen, Germany

PostPosted: Mon Feb 04, 2019 9:51 am    Post subject: Karte Reply with quote

Für die Vollständigkeit des Threads: Die Karte heißt Renkforce 986823 und wird noch neu verkauft.
_________________
Languages: English, German
Back to top
View user's profile Send private message
Christian99
Veteran
Veteran


Joined: 28 May 2009
Posts: 1178

PostPosted: Mon Feb 04, 2019 12:25 pm    Post subject: Reply with quote

wird denn überhaupt von Linux noch eine weitere firmware geladen?
wenn ja, dann lösche/umbenenne die Datei doch einfach mal.
Back to top
View user's profile Send private message
YPenguin
Apprentice
Apprentice


Joined: 26 Apr 2014
Posts: 278
Location: Kenzingen, Germany

PostPosted: Mon Feb 04, 2019 2:51 pm    Post subject: C-Quelltext Reply with quote

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:
Code:

   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:
Code:

        if (pdev->vendor == PCI_VENDOR_ID_RENESAS &&
                        pdev->device == 0x0015)
                xhci->quirks |= XHCI_RESET_ON_RESUME;

_________________
Languages: English, German


Last edited by YPenguin on Mon Feb 04, 2019 7:03 pm; edited 1 time in total
Back to top
View user's profile Send private message
YPenguin
Apprentice
Apprentice


Joined: 26 Apr 2014
Posts: 278
Location: Kenzingen, Germany

PostPosted: Mon Feb 04, 2019 4:07 pm    Post subject: Reply with quote

In Kernel 5.0 xhci.c:
Code:

        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:
Code:

        /*
         * 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...
         */

_________________
Languages: English, German
Back to top
View user's profile Send private message
YPenguin
Apprentice
Apprentice


Joined: 26 Apr 2014
Posts: 278
Location: Kenzingen, Germany

PostPosted: Mon Feb 04, 2019 4:47 pm    Post subject: Fehlermeldung mit Kernel 5.0 Reply with quote

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

_________________
Languages: English, German
Back to top
View user's profile Send private message
YPenguin
Apprentice
Apprentice


Joined: 26 Apr 2014
Posts: 278
Location: Kenzingen, Germany

PostPosted: Tue Feb 05, 2019 10:02 am    Post subject: Ähnlicher Thread Reply with quote

Bei Arch-Linux gibt es einen ähnlichen Thread: https://bbs.archlinux.org/viewtopic.php?id=236806
_________________
Languages: English, German
Back to top
View user's profile Send private message
YPenguin
Apprentice
Apprentice


Joined: 26 Apr 2014
Posts: 278
Location: Kenzingen, Germany

PostPosted: Tue Feb 05, 2019 10:49 am    Post subject: Quirks im Bootvorgang? Reply with quote

Im dmesg-Protokoll werden im Bootvorgang keine Quirks erwähnt - werden sie beim Booten nicht angewendet?
_________________
Languages: English, German
Back to top
View user's profile Send private message
Display posts from previous:   
Reply to topic    Gentoo Forums Forum Index Deutsches Forum (German) All times are GMT
Goto page 1, 2  Next
Page 1 of 2

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum