cancel
Showing results for 
Search instead for 
Did you mean: 

Akoya S15450 : Ubuntu 20.04 Live64 nach dem Booten von USB-Stick keine Tastatureingebe möglich

23 REPLIES 23
noodles
New Voice
Message 1 of 24
10,611 Views
Message 1 of 24
10,611 Views

Akoya S15450 : Ubuntu 20.04 Live64 nach dem Booten von USB-Stick keine Tastatureingebe möglich

S15450    MSN:  30030203

Win 10 Home x64 build 19041.685

AMI Aptio 2.21.1278  11/10/2020

 

secure boot diabled

 

Habe es mit Rufus 3.9, UEFI Yumi0.0.3.2, UNetbootin versucht. Die Livesysteme (gparted, boot-repair-disk, Ubuntu 20.14) wurden gebootet, auch mit FullHD-Auflösung, Maus funktioniert, aber Tastatur funktioniert nicht.

 

Hat jemand eine Idee?  Vielen Dank für Rückmeldung(en) im Voraus.

 

PS: bei meinem 11 Jahre alten ACER  mit uraltem BIOS InsydeH20 Rev. 3.5 funktioniert alles bestens.

 

23 REPLIES 23
Andi
Master Moderator
Message 11 of 24
4,713 Views
Message 11 of 24
4,713 Views

Hallo @EAE.

 

Hier der Link zum 209 er BIOS (24.11.2020) für das S15450 (MD 63650) mit der MSN 30030203. Für eventuellen Datenverlust, sowie Fehler an Hard- oder Software, die aufgrund der Ausführung des Updates auftreten, übernimmt die Medion AG keinerlei Haftung. Dies erkennt der Kunde bei Ausführung des Updates an.

 

 

Gruß - Andi


MEDION. LÄUFT BEI MIR.
• Web: www.medion.de • Community: community.medion.com • Facebook: MEDIONDeutschland • Instagram: @medion.de


Bitte belohne hilfreiche Antworten mit Kudos und markiere die beste Antwort/Lösung mit Als Lösung akzeptieren.
EAE
Trainee
Message 12 of 24
4,706 Views
Message 12 of 24
4,706 Views

Schon drauf und Computer läuft, Danke Dir.

Und weiter geht's.....

 

C.

ggstefan
Newcomer
Message 13 of 24
4,604 Views
Message 13 of 24
4,604 Views

Hallo Zusammen,

habe das gleiche Problem, dachte nicht das es in der heutigen Zeit einen Geräte Hersteller gibt der es hinbekommt das eine lumpige Tastatur (wie reden nicht einmal von Sondertasten) unter einem aktuellem bekannten Linux (Ubuntu 20.04/20.10) nicht geht. Habe alles mögliche versucht vorher zu beachten und zu schauen ob es geht, aber an die Tastatur habe ich nicht gedacht.

 

Habe das hier erwähnte BIOS-Update auf Version 2.09 gemacht jedoch geht die Tastatur immer noch nicht.

 

Jemand noch eine Idee was ich probieren könnte? Sonst ist es wohl eher Elektroschrott!

 

EAE
Trainee
Message 14 of 24
4,590 Views
Message 14 of 24
4,590 Views

Nein, es wird nicht funktionierern. Mir haben genug Leute noch Links und andere Lösungsansätze geschickt, Ich habe Kernel Changelogs gelesen, Canonical das Notebook gemeldet mit diesen Bug, einfach keine Chance.

Mach mal: dmesg | grep i8042, oder wenn Du einen neueren Kernel verwendest: sudo dmesg | grep i8042, da wirds Du schon sehen, das der Klapprechner die interne Tastatur nicht erkennt.

So wie es aussieht, wird der Klapprechner als Tablet erkannt, weil der Treiber intel_vbtn eine Macke hat, obwohl er sich auf Github gut liest.

Vergiss nicht, MEDION verkauft nur die funktionierende Hardware, die Jungs können hier garnichts dafür, wenn andere BS außer WIN nicht laufen.

 

C.

thago
New Voice
Message 15 of 24
4,224 Views
Message 15 of 24
4,224 Views

Hallo

 

Gibts eine Stelle wo man Ein neues Bios fuer S15450 kann downloaden in der Zukunft? > 209

Andi
Master Moderator
Message 16 of 24
4,215 Views
Message 16 of 24
4,215 Views

Hallo @thago und herzlich willkommen in der Community.

 

Falls es zukünftig BIOS- Updates geben wird, würden diese über den Gerätemanager kommen. Siehe Nachricht 8. Einen offiziellen separaten Download gibt es nicht.

 

 

Gruß - Andi


MEDION. LÄUFT BEI MIR.
• Web: www.medion.de • Community: community.medion.com • Facebook: MEDIONDeutschland • Instagram: @medion.de


Bitte belohne hilfreiche Antworten mit Kudos und markiere die beste Antwort/Lösung mit Als Lösung akzeptieren.
dudenkov
New Voice
Message 17 of 24
3,823 Views
Message 17 of 24
3,823 Views

@EAE

Da ich hier newbie bin, erstmal: Hallo an die community!

Vorab die salvatorische Klausel: Sollte für diesen Hinweis ein neuer thread nötig sein, bitte ich die Moderatoren dieses zu ermöglichen, da ich die Regeln hier noch nicht gut genug kenne!

 

Ich klinke mich also hier in diesen alten thread ein, weil er meine erste Fundstelle war, als ich nach Lösungen für eine nicht mehr funktionierende Tastatur meines neuen Akojas S15449 war. Ich stellte beim setup des Dualboots mit ubuntu 21.04 und win 10 fest, dass nur noch das touchpad funktionierte, aber nicht mehr die Tastatur. Mit externer das setup beendet und ubuntu hochgefahren, gleiches Resultat. Also genauso, wie hier und an anderen Stellen mit ähnlichen Medion NBs, die wohl alle mit dem gleichen tiger lake chipset und dem Intel Core i5-1135G7 der 11.gen bestückt sind. Entgegen den häufig geäußerten Annahmen, so auch hier, gibt es wahrscheinlich eine Lösung: https://bugzilla.kernel.org/show_bug.cgi?id=213031

Leider ist unklar ob die kernel.org people diesen o.g. bugfix in die allgemeinen Update-Releases des kernels implementieren. Wer selbst kompilieren kann, ist besser dran als ich.

Deshalb bin ich auch nicht ganz einverstanden mit der Haltung sowohl der Medion-Moderatoren, die bestimmt sonst einen guten job machen, und einigen Beiträgern. Medion hat gewiss eine große Mitverantwortung an so schlecht konfigurieten Efi-biosen und Treiberkonstellationen, die nur mit win 10 laufen. Und gewiss auch an dem sehr schlechten support, wenn dann solche Probleme auftreten. Denn eine fehlende interne Tastatur ist ja keine Petittesse! Und die linux-community die ganze bugfix Arbeit ohne Unterstützung alleine machen zu lassen, ist vielleicht sogar zynisch zu nennen. Mich hat es viele Stunden Suche gekostet, um ein System konfigurieren zu können mit dem ich angstfrei im Netz surfen kann.

EAE
Trainee
Message 18 of 24
3,801 Views
Message 18 of 24
3,801 Views

Wie jetzt, geht deine Tastatur nun?

Hast du die XML-Dateien aus den Workaround übernommen, z.B diese hier(warum gibts hier kein Codeblock?):

--- a/drivers/acpi/resource.c
+++ b/drivers/acpi/resource.c
@@ -401,10 +401,16 @@ static void acpi_dev_get_irqresource(str
* using extended IRQ descriptors we take the IRQ configuration
* from _CRS directly.
*/
+ printk("wwwwwwwhhhhhhhhhhhhh gsi = %d triggering = %d polarity = %d\n",
+ gsi, triggering, polarity);
if (legacy && !acpi_get_override_irq(gsi, &t, &p)) {
u8 trig = t ? ACPI_LEVEL_SENSITIVE : ACPI_EDGE_SENSITIVE;
u8 pol = p ? ACPI_ACTIVE_LOW : ACPI_ACTIVE_HIGH;

+ if (gsi == 1) {
+ trig = ACPI_EDGE_SENSITIVE;
+ pol = ACPI_ACTIVE_LOW;
+ }
if (triggering != trig || polarity != pol) {
pr_warn("ACPI: IRQ %d override to %s, %s\n", gsi,
t ? "level" : "edge", p ? "low" : "high");

 

Ich hab 13 Tage dran gesessen, mit Hilfe eines Redakteurs einer Computerzeitschrift, der hauptsächlich für Linux schreibt und einen Linuxblog hat, vergeblich.

Für mich kommt das o.g. leider zu spät, sonst hät ich mal eben sudoedit gemacht.

Das die Linuxtreiber nicht funzen, liegt eindeutig an INTEL, warum auch immer, obwohl die der Kernel.org genug zuspielen. Ich werde es sowieso nie kapieren, warum die CPU-Hersteller teilweise sehr dilettantisch mit der Treiberversorgung sind, da das meiste im Serverbereich mit LINUX/UNIX-Derivaten läuft, deren Hauptgeschäft. Selbst MICROSOFT setzt in seinen Cloud's ein UNIX-Derivat ein und spielt der Kernel.org zu.

 

C.

dudenkov
New Voice
Message 19 of 24
3,774 Views
Message 19 of 24
3,774 Views

@EAE 

Nein, noch nicht! Da mir die Fähigkeiten fehlen, Codezeilen in meinen aktuellen kernel selbst zu implementieren, muss ich warten bis dieser patch von Hui Wang von Canonical und Rui Zhang von Intel es in die offiziellen Releases geschafft hat.

Da ich aber auf vielen Umwegen nach zwanzig Stunden Suchmaschinen Recherche auf diesen bug report von Manuel Krause im bugzilla der kernel.org gestoßen war und vorher natürlich auch diesen thread gelesen hatte, wollte ich mich mit diesem Hinweis revanchieren. Mit Manuel Krause stehe ich in Mailkontakt und er glaubt das vielleicht  in 3-4 Wochen die Distributionen den fix übernehmen können.

ManuelKrause
New Voice
Message 20 of 24
3,653 Views
Message 20 of 24
3,653 Views

Na, hier geht's ja hoch her... Endlich tut sich mal was.  😉

 

Grundlage des Problems ist, einfach gesagt, dass das BIOS eine Signalinterpretation vom Keyboard falsch vorschlägt und der Linux-Kernel da bisher einen "override" Modus für i8042 benutzt. Warum UNIX oder Windows das anders handhaben, bleibt wohl deren ewiges Geheimnis.

 

Die erste Fix-Generation ( ~Juni 2021) wurde aus dem Linux-Kernel schnell wieder zurückgezogen, weil ältere Server-Systeme dadurch angeblich unbootbar wurden. Frustrierend, weil nur eine Evidenz vorlag.

Die zweite Generation (ab September) prüft jetzt anhand der DMI Informationen, welches System infrage kommt und lässt alle anderen unbehelligt.

Konkret: In "sudo dmesg | grep DMI:" müssen 'MEDION' als SYS_VENDOR und 'M15T' als BOARD_NAME vorkommen. Bei mir sieht das so aus:

[ 0.000000] DMI: MEDION P15651/M15T, BIOS 209 11/24/2020

 

Alle, bei denen, die hier noch dabei sind und von dem Keyboard-Fehler betroffen sind, und bei denen vor allem MEDION und M15T nicht zusammen angezeigt werden, möchte ich bitten, ihre Angaben hier zu posten. Ich würde die Daten direkt an Hui Wang weiterleiten.

Das neue Fix-Patch hat den Riesenvorteil, es ist erweiterbar für alle Eventualitäten früherer oder zukünftiger BIOS- / Hardware-Kapriolen von welchem Hersteller auch immer.

 

Also, das generelle Fix-Patch ist in der Pipeline für den Linux-Kernel, abgenommen vom Verantwortlichen, aber leider erst für 5.16 eingetaktet. Ich habe höflichst darum gebeten, das evtl. zu beschleunigen. Mal gucken. Bis es in den Distros landet, wird ja auch nicht sofort passieren.

Für Ubuntu 20.04, 20.10 and 21.04 will Hui Wang das Fix baldmöglichst "backporten", wenn es im Kernel-Code aufschlägt. Zeit-Prognose von meiner Seite bisher unmöglich.

 

Euch alles Gute, bleibt freundlich, es ist Licht am Ende des Tunnels,

aber der MEDION Support für Linux ist unterirdisch-sch****,

 

Manuel

23 REPLIES 23