http://www.pro-linux.de/news/1/25456/desktop-dvd-von-ubuntu-1710-nach-bios-problemen-zur%C3%BCckgezogen.html

[inne]

Scheint - vorerst - doch eher ein Ubuntu-ding zu sein:

Code: Alles auswählen

$ grep INTEL_SPI /boot/config-`uname -r`
# CONFIG_SPI_INTEL_SPI_PLATFORM is not set
$

Puh, Glück gehabt

Sehr gut, aber mal blöd quer reingefragt:

Ich habe ein Lenovo B50-70 (das wäre akut betroffen) und ein T530. Reicht es und welches Kernelmodul müsste ich Blacklisten?

[Lohengrin]

Dein bleeding edge Arch hat keine Unterstützung mehr für so antiquierte Leuchtmittel, schießt dir das Glühobst durch und dann soll Debian schuld sein?

An Arch wirst du dich nicht rangewagt haben, da du ja keine bebilderte Anleitung in Deutsch bekommen hast.

Wir haben doch aufgepasst. Es war Decke drüber und dunkel. (Bülbül Hekmek)

[Ellison]

*seufz

[dufty2]

Scheint - vorerst - doch eher ein Ubuntu-ding zu sein:

Code: Alles auswählen

$ grep INTEL_SPI /boot/config-`uname -r`
# CONFIG_SPI_INTEL_SPI_PLATFORM is not set
$

Puh, Glück gehabt

Sehr gut, aber mal blöd quer reingefragt:

Ich habe ein Lenovo B50-70 (das wäre akut betroffen) und ein T530. Reicht es und welches Kernelmodul müsste ich Blacklisten?

Das Modul heisst dann "intel-spi-platform", vgl. auch z. B. https://cateee.net/lkddb/web-lkddb/SPI_ ... TFORM.html

[inne]

Danke! Auch wenns eher unwahrscheinlich ist, ich habe das Modul geblacklistet. Bis ich es dann mal brauche, um dann ein BIOS Update zu tun.

[jph]

Capslock-Andy

GRÖHL

[rendegast]

https://lwn.net/Articles/742067/

Posted Dec 22, 2017 6:22 UTC (Fri) by Otus (subscriber, #67685) [Link]
Thanks,

$ grep INTEL_SPI /boot/config-*
/boot/config-4.13.0-19-generic:CONFIG_SPI_INTEL_SPI=m
/boot/config-4.13.0-19-generic:CONFIG_SPI_INTEL_SPI_PLATFORM=m
/boot/config-4.13.0-21-generic:# CONFIG_SPI_INTEL_SPI_PLATFORM is not set

Das Problem scheint bei ubuntu insoweit erstmal "gefixt".


Gerademal ein Bauen der Module für 4.13 und 4.14

Code: Alles auswählen

CONFIG_MTD_SPI_NOR=m
# CONFIG_MTD_MT81xx_NOR is not set
CONFIG_MTD_SPI_NOR_USE_4K_SECTORS=y
CONFIG_SPI_INTEL_SPI=m
CONFIG_SPI_INTEL_SPI_PCI=m                                          nur 4.14
CONFIG_SPI_INTEL_SPI_PLATFORM=m

erstellt Module
intel-spi-pci.ko                                          nur 4.14
intel-spi-platform.ko
intel-spi.ko
spi-nor.ko

Nur das Modul intel-spi hat einen Parameter,
'writeable=#' (default=0).
(Nur) das Modul intel-spi-pci (kernel 4.14) hat eine Hardware-Abhängigkeit:
alias: pci:v00008086d000019E0sv*sd*bc*sc*i*

Reicht es und welches Kernelmodul müsste ich Blacklisten?

Das Modul heisst dann "intel-spi-platform",

Es sollte wohl besser alle 4 obigen Module erstmal auf die blacklist.
(Obwohl das Problem in 4.14 wohl wirklich gefixt sein soll(?)
EDIT gemeint ist ein wirklicher Fix des Moduls, nicht das einfache Nicht -Auswählen.)
Aber: Da die Module (4.13) ja nicht hardwareabhängig sind, ist das blacklist (-> udev) wohl nutzlos.
Im problematischen ubuntu wurden sie wohl explizit geladen, zBsp. per /etc/modules.

[inne]

Aber: Da die Module (4.13) ja nicht hardwareabhängig sind, ist das blacklist (-> udev) wohl nutzlos.

D.h. die Module würde trotz Blacklist von udev (dynamisch ) nach-geladen?

[Ellison]

Mir leuchtet eh nicht ein, wieso ein Canonical Mitarbeiter das ganze trotz Warnung "Say N here unless you know what you are doing." im Kernel aktiviert.

[rendegast]

Aber: Da die Module (4.13) ja nicht hardwareabhängig sind, ist das blacklist (-> udev) wohl nutzlos.

D.h. die Module würde trotz Blacklist von udev (dynamisch ) nach-geladen?

udev erkennt Hardware und lädt die entsprechenden Module (nach ihren alias:-Listen).
Eine solche Liste haben diese Module (intel-spi-pci des 4.14 abgesehen) nicht, udev ist also nicht involviert.
Es passiert wohl explizit ala loop, eeprom, tun, cpuid, msr zBsp. per
/etc/modules oder
/etc/initramfs-tools/modules
Das! hätten sie so besser nicht gemacht.
Denn dann wären nur vereinzelte Meldungen von Benutzern gekommen,
die das tatsächlich unter Linux versuchen -> normale Bugreports über ein problematisches Modul.

Mir leuchtet eh nicht ein, wieso ein Canonical Mitarbeiter das ganze trotz Warnung "Say N here unless you know what you are doing." im Kernel aktiviert.

Diese Module werden erst bei Einstellung EXPERT=yes verfügbar.
Das trifft auf viele Module zu. Weiterhin gibt es zahlreiche aktivierte Module unterhalb staging/.
Ist also gängige Praxis, nur ein Modul mehr oder weniger aus Sicht des ubuntu-kernel-Maintainers.

Nach der Beschreibung "ermöglicht flashen des bios"
("Using this driver it is possible to upgrade BIOS directly from Linux.") auch nachvollziehbar.
Wunschziel/Vorstellung war wohl, das Flashen im laufenden Betrieb zu ermöglichen ala windows.

[dufty2]

Obwohl das Problem in 4.14 wohl wirklich gefixt sein soll(?)

Das Problem wurde in 4.14.rc1 gefixed somit sind 4.14.0-1-amd64 und 4.14.0-2-amd64 aus sid sauber.
Habe mir letzteres heut' früh schon mal auf mein testing-Kistchen aufgespielt, aber nicht wegen diesem Problem, sondern wegen der eBPF-Lücke (vgl. https://lwn.net/Articles/742170/ ).

[rendegast]

Obwohl das Problem in 4.14 wohl wirklich gefixt sein soll(?)

Das Problem wurde in 4.14.rc1 gefixed somit sind 4.14.0-1-amd64 und 4.14.0-2-amd64 aus sid sauber.

Nicht so ganz, das eigentliche Problem ist die Auswirkung des Moduls.
EDIT Umformulierung:
Gut, jedoch umgehen die beiden genannten debian-kernel das Problem auch,
denn die fraglichen Module sind schlicht nicht mitgebaut ("# CONFIG_SPI_INTEL_SPI_* is not set").

[Ellison]

Nach der Beschreibung "ermöglicht flashen des bios"
("Using this driver it is possible to upgrade BIOS directly from Linux.") auch nachvollziehbar.
Wunschziel/Vorstellung war wohl, das Flashen im laufenden Betrieb zu ermöglichen ala windows.

Schon klar, aber die Kombination: Intel-Entwickler, der einfach mal so bei der Initialisierung versucht, Schreibzugriff auf das Flash des BIOS zu bekommen plus einen Bug im BIOS von Insyde Software, und eben einen Canonical Mitarbeiter, der das ganze trotz Warnung "Say N here unless you know what you are doing." im Kernel aktiviert, macht mir durchaus Kopfzerbrechen.
Vor allem, es wird nicht groß kommuniziert, wenn man jetzt mal von Ubuntu absieht. Die Einträge auf launchpad und bugzilla.kernel.org zeigen ja, dass es auch Distributionsübergreifend passiert.

Das Zeitfenster ist auch irre. Der Bug wurde Anfang Juni das erste Mal gemeldet und Ende Juli behoben. Damals blieb das ganze noch recht ruhig, wobei ich die Auswirkungen, dass sich ein BIOS auf default zurücksetzen kann, schon als nicht zwingend harmlos bezeichnen würde. Ende November taucht es wieder auf und trotzdem dauert es Wochen, bis man sich dem ganzen mal annimmt. Bis dahin ist die besagte DVD aber schon x Mal geladen worden und diverse Rechner abgeraucht. Wie gesagt, für mich ist das ganze nicht zwingend nachvollziehbar und wie man eben an den Einträgen liest, betrifft es nicht nur Ubuntu.

[dufty2]

Obwohl das Problem in 4.14 wohl wirklich gefixt sein soll(?)

Das Problem wurde in 4.14.rc1 gefixed somit sind 4.14.0-1-amd64 und 4.14.0-2-amd64 aus sid sauber.

Nicht so ganz, das eigentliche Problem ist die Auswirkung des Moduls.
In den genannten debian-kerneln ist es schlicht nicht mitgebaut ("# CONFIG_SPI_INTEL_SPI_* is not set").

Nö, das Problem wurde gefixt in 4.14-rc1+ gemäß Mika Westerberg lt. https://bugzilla.kernel.org/show_bug.cgi?id=195951
(Ich hab' das jetzt mal nicht verifiziert und glaub' ihn mal.)

Die rc-Kernels sind die release candidates, die erscheinen vor dem 4.14.0-Kernel.
Die beiden o. g. sid-kernels sind 4.14.2 und 4.14.7 und damit neuer & gefixt.

[rendegast]

... und eben einen Canonical Mitarbeiter, der das ganze trotz Warnung "Say N here unless you know what you are doing." im Kernel aktiviert, macht mir durchaus Kopfzerbrechen.

Ich mußte etwas suchen, beim SBC_EPX_C3_WATCHDOG gleichartige Warnung,
und der ist in den debian-kerneln aktiviert.
Hat diese Warnung zusätzlich im 'modinfo'.

[Ellison]

Eben schlug der 4.14 bei mir auf

Code: Alles auswählen

mark@debian:~$ cat /boot/config-$(uname -r) | grep -iE 'intel_spi|intel-spi'
# CONFIG_SPI_INTEL_SPI_PCI is not set
# CONFIG_SPI_INTEL_SPI_PLATFORM is not set

Alles gut.

[rendegast]

Nö, das Problem wurde gefixt in 4.14-rc1+ gemäß Mika Westerberg lt. https://bugzilla.kernel.org/show_bug.cgi?id=195951
(Ich hab' das jetzt mal nicht verifiziert und glaub' ihn mal.)

Ich habe mal eine Probe gemacht, kernel vanilla 4.14.0 und 4.14.3,
Der aufgeführte Patch

Created attachment 257715 [details] https://bugzilla.kernel.org/attachment. ... ction=diff

betrifft eine Stelle in
drivers/mfd/lpc_ich.c
drivers/mtd/spi-nor/intel_spi_pci.c.
In den obigen beiden kerneln ist aber das

Code: Alles auswählen

#if 0
...
#endif

so in keiner der Dateien der kernel enthalten.

Jedoch ist in der lpc_ich aus der dev-Aktion eine bus-Aktion geworden,
in der intel_spi_pci aus dem dev ein pdev.
Ob das der patch in feinerer Form ist?

[dufty2]

dieser rendegast gibt doch keine Ruhe

Also, im stable (4.14.9) nachgeschaut:
https://git.kernel.org/pub/scm/linux/ke ... ?h=v4.14.9
https://git.kernel.org/pub/scm/linux/ke ... ?h=v4.14.9
https://git.kernel.org/pub/scm/linux/ke ... c9661b08a7
https://git.kernel.org/pub/scm/linux/ke ... ?h=v4.14.9

Im Vergleich zum bugzilla-attachment hat er ihn jetzt ein bischen verändert.

[rendegast]

@dufty2,
Danke für die Erläuterung.