View previous topic :: View next topic |
Author |
Message |
YPenguin Apprentice
Joined: 26 Apr 2014 Posts: 278 Location: Kenzingen, Germany
|
Posted: Fri Feb 01, 2019 11:10 am Post subject: Kernelpatch=Problemursache? |
|
|
Was macht man, wenn ein Kernelpatch die Kompatibilität mit älterer Hardware bricht? _________________ Languages: English, German |
|
Back to top |
|
|
YPenguin Apprentice
Joined: 26 Apr 2014 Posts: 278 Location: Kenzingen, Germany
|
Posted: Fri Feb 01, 2019 11:14 am Post subject: Mein konkretes Problem |
|
|
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 |
|
|
mike155 Advocate
Joined: 17 Sep 2010 Posts: 4438 Location: Frankfurt, Germany
|
Posted: Fri Feb 01, 2019 12:38 pm Post subject: |
|
|
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 |
|
|
YPenguin Apprentice
Joined: 26 Apr 2014 Posts: 278 Location: Kenzingen, Germany
|
Posted: Fri Feb 01, 2019 1:23 pm Post subject: Neue Hardware |
|
|
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 |
|
|
schmidicom Veteran
Joined: 09 Mar 2006 Posts: 1921 Location: Schweiz
|
Posted: Fri Feb 01, 2019 2:50 pm Post subject: |
|
|
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. _________________ Lenovo - ThinkPad P16s Gen 2 - 21K9CTO1WW |
|
Back to top |
|
|
YPenguin Apprentice
Joined: 26 Apr 2014 Posts: 278 Location: Kenzingen, Germany
|
|
Back to top |
|
|
schmidicom Veteran
Joined: 09 Mar 2006 Posts: 1921 Location: Schweiz
|
Posted: Fri Feb 01, 2019 4:02 pm Post subject: |
|
|
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. _________________ Lenovo - ThinkPad P16s Gen 2 - 21K9CTO1WW |
|
Back to top |
|
|
YPenguin Apprentice
Joined: 26 Apr 2014 Posts: 278 Location: Kenzingen, Germany
|
Posted: Fri Feb 01, 2019 4:24 pm Post subject: |
|
|
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 |
|
|
YPenguin Apprentice
Joined: 26 Apr 2014 Posts: 278 Location: Kenzingen, Germany
|
|
Back to top |
|
|
YPenguin Apprentice
Joined: 26 Apr 2014 Posts: 278 Location: Kenzingen, Germany
|
Posted: Fri Feb 01, 2019 4:35 pm Post subject: |
|
|
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 |
|
|
schmidicom Veteran
Joined: 09 Mar 2006 Posts: 1921 Location: Schweiz
|
Posted: Fri Feb 01, 2019 5:02 pm Post subject: |
|
|
Ich meinte damit nicht die USB-Firmware sondern die des Mainboards (aka BIOS oder UEFI) denn dort steckt das offensichtlich veraltete ACPI. _________________ Lenovo - ThinkPad P16s Gen 2 - 21K9CTO1WW |
|
Back to top |
|
|
toralf Developer
Joined: 01 Feb 2004 Posts: 3920 Location: Hamburg
|
Posted: Fri Feb 01, 2019 6:00 pm Post subject: Re: Kernelpatch=Problemursache? |
|
|
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 |
|
|
YPenguin Apprentice
Joined: 26 Apr 2014 Posts: 278 Location: Kenzingen, Germany
|
Posted: Fri Feb 01, 2019 6:30 pm Post subject: |
|
|
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 |
|
|
YPenguin Apprentice
Joined: 26 Apr 2014 Posts: 278 Location: Kenzingen, Germany
|
Posted: Fri Feb 01, 2019 7:33 pm Post subject: "acpi_osi=!Windows 2006" |
|
|
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 |
|
|
schmidicom Veteran
Joined: 09 Mar 2006 Posts: 1921 Location: Schweiz
|
Posted: Sat Feb 02, 2019 8:43 am Post subject: |
|
|
Und was passiert bei den folgenden beiden (bitte 1 und 2 einzeln/getrennt testen):
1. Code: | acpi_osi=! acpi_os_name=Linux |
2. _________________ Lenovo - ThinkPad P16s Gen 2 - 21K9CTO1WW |
|
Back to top |
|
|
YPenguin Apprentice
Joined: 26 Apr 2014 Posts: 278 Location: Kenzingen, Germany
|
Posted: Sat Feb 02, 2019 10:10 am Post subject: |
|
|
@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 |
|
|
schmidicom Veteran
Joined: 09 Mar 2006 Posts: 1921 Location: Schweiz
|
Posted: Sat Feb 02, 2019 1:09 pm Post subject: |
|
|
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... _________________ Lenovo - ThinkPad P16s Gen 2 - 21K9CTO1WW |
|
Back to top |
|
|
YPenguin Apprentice
Joined: 26 Apr 2014 Posts: 278 Location: Kenzingen, Germany
|
Posted: Sat Feb 02, 2019 9:11 pm Post subject: |
|
|
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 |
|
|
YPenguin Apprentice
Joined: 26 Apr 2014 Posts: 278 Location: Kenzingen, Germany
|
Posted: Mon Feb 04, 2019 9:51 am Post subject: Karte |
|
|
Für die Vollständigkeit des Threads: Die Karte heißt Renkforce 986823 und wird noch neu verkauft. _________________ Languages: English, German |
|
Back to top |
|
|
Christian99 Veteran
Joined: 28 May 2009 Posts: 1668
|
Posted: Mon Feb 04, 2019 12:25 pm Post subject: |
|
|
wird denn überhaupt von Linux noch eine weitere firmware geladen?
wenn ja, dann lösche/umbenenne die Datei doch einfach mal. |
|
Back to top |
|
|
YPenguin Apprentice
Joined: 26 Apr 2014 Posts: 278 Location: Kenzingen, Germany
|
Posted: Mon Feb 04, 2019 2:51 pm Post subject: C-Quelltext |
|
|
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 |
|
|
YPenguin Apprentice
Joined: 26 Apr 2014 Posts: 278 Location: Kenzingen, Germany
|
Posted: Mon Feb 04, 2019 4:07 pm Post subject: |
|
|
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 |
|
|
YPenguin Apprentice
Joined: 26 Apr 2014 Posts: 278 Location: Kenzingen, Germany
|
Posted: Mon Feb 04, 2019 4:47 pm Post subject: Fehlermeldung mit Kernel 5.0 |
|
|
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 |
|
|
YPenguin Apprentice
Joined: 26 Apr 2014 Posts: 278 Location: Kenzingen, Germany
|
|
Back to top |
|
|
YPenguin Apprentice
Joined: 26 Apr 2014 Posts: 278 Location: Kenzingen, Germany
|
Posted: Tue Feb 05, 2019 10:49 am Post subject: Quirks im Bootvorgang? |
|
|
Im dmesg-Protokoll werden im Bootvorgang keine Quirks erwähnt - werden sie beim Booten nicht angewendet? _________________ Languages: English, German |
|
Back to top |
|
|
|