Linux kernel releases

[megahead13]

ΓΤΠΚ

[calcvita]

ξερει κανεις να μου πει αν ο rtl8821ce wifi adapter θα υποστηριζεται απο τον επερχομενο 5,8 kernel? βρηκα αυτο εδω και λενε οτι ειναι work in progress https://bugzilla.kernel.org/show_bug.cgi?id=201875
απλα ειπα να ρωτησω μηπως εχετε ακουσει κατι πιο συγκεκριμενο

[imitheos]

Αν στο relevant bug δεν έχει πληροφορίες εμείς τι παραπάνω μπορούμε να έχουμε ακούσει;

Εδώ είναι οι όλες οι αλλαγές από τον 5.7 μέχρι τον 5.8-rc5 αν θέλεις να το ψάξεις. Με μια γρήγορη ματιά, η μόνη αλλαγή που βλέπω είναι ένα αρχείο σε ένα κατάλογο rtl8821ae οπότε θα έλεγα όχι αλλά ίσως να υποστηριχθεί μέσω κάποιου υπάρχοντα οδηγού με άλλο όνομα. Ξέρεις μέσω ποιου οδηγού θα υποστηριχτεί;

Αν δεν βαριέσαι μπορείς να πάρεις το config της διανομής σου για τον 5.7 και να χτίσεις τον 5.8-rc5 για να δεις από πρώτο χέρι αν παίζει ή όχι.

Edit: Είδα ότι γράφεις στο νήμα του ubuntu. Αυτό βέβαια δεν σημαίνει ότι τρέχεις ubuntu, αλλά σε περίπτωση που το κάνεις, εδώ έχει έτοιμο χτισμένο τον 5.8-rc5 αν θέλεις να τον δοκιμάσεις.

[calcvita]

Αν στο relevant bug δεν έχει πληροφορίες εμείς τι παραπάνω μπορούμε να έχουμε ακούσει;

ε ειπα μηπως εχετε καποιες insider πληροφοριες
τεραστια η σελιδα imitheos
μεχρι στιγμης δουλευει με τον driver απο τον tomaspinho (https://github.com/tomaspinho/rtl8821ce)

- - - Updated - - -

Edit: Είδα ότι γράφεις στο νήμα του ubuntu. Αυτό βέβαια δεν σημαίνει ότι τρέχεις ubuntu, αλλά σε περίπτωση που το κάνεις, εδώ έχει έτοιμο χτισμένο τον 5.8-rc5 αν θέλεις να τον δοκιμάσεις.

οντως ετρεχα ubuntu. ειχα ακολουθησει αυτη εδω την διαδικασια https://github.com/pimlie/ubuntu-mainline-kernel.sh αλλα ειχα καποια θεματακια με το gui του ubuntu και ετσι δεν το επιχειρησα ξανα.
τωρα pop os πλεον (οχι γιαννης, γιαννακης δλδ ). την μονη αλλαγη που εκανα ειναι μια τροποποιηση στο sources list να κανουν point στο development branch του ubuntu

[jim_p]

5.8 σημερα
https://kernelnewbies.org/Linux_5.8

[calcvita]

δεν ειδα κατι για rtl8821ce, εκτος κι αν ειμαι γκαβος
δεν πειραζει, maybe next time

[imitheos]

δεν ειδα κατι για rtl8821ce, εκτος κι αν ειμαι γκαβος
δεν πειραζει, maybe next time

Οτιδήποτε νέο μπαίνει όταν ανοίγει το "merge window" και μετά στις rcX διορθώνονται bugs. Εφόσον δοκίμασες τον rc5 και δεν υπήρχε οδηγός δεν υπήρχε περίπτωση να υπάρχει στον τελικό.

[giorgosts]

δεν ειδα κατι για rtl8821ce, εκτος κι αν ειμαι γκαβος
δεν πειραζει, maybe next time

Γιατί αυτό https://github.com/tomaspinho/rtl8821ce δεν δουλεύει; Το out-of-tree δεν είναι κάτι ασυνήθιστο, απλώς δηλώνει την απροθυμία των kernel developers να διατηρούν τον κώδικα, διότι η ευθύνη για τη συντήρησή του πέφτει σε αυτούς (λόγω ίσως περιορισμένων ανθρώπινων πόρων).

Εγώ έχω out-of-tree εκτός από τον nvidia driver, έναν exfat driver και έναν για το Driving Force Pro που έχει περισσότερες δυνατότητες από τον ενσωματωμένο (Force Feedback, Autocenter, Spring Force, Damper Force, Friction κλπ).

george@george:~$ dkms status
exfat, 2.2.0-3arter97-0~201910290835~ubuntu18.04.1, 5.4.0-42-generic, x86_64: installed (original_module exists)
new-lg4ff, 0.3.1, 5.4.0-42-generic, x86_64: installed (original_module exists)
nvidia, 450.51.06, 5.4.0-42-generic, x86_64: installed

Με το DKMS framework, εφόσον υπάρχει το source, το module χτίζεται ξανά όταν μπαίνει καινούργιος πυρήνας.
https://en.wikipedia.org/wiki/Dynami...Module_Support

[calcvita]

Γιατί αυτό https://github.com/tomaspinho/rtl8821ce δεν δουλεύει;

δουλευει, αλλα μια native υποστηριξη θα ηταν καλυτερη. πιστευω οτι τα "θαμετακια" που εχω με pulseaudio και τα bluetooth ηχεια (μικρες διακοπες στον ηχο) θα ειναι και θεμα driver. απλα ειχα διαβασει οτι ειναι work in progress και ειπα μηπως μπηκε τελικα στον 5.8

[giorgosts]

δουλευει, αλλα μια native υποστηριξη θα ηταν καλυτερη. πιστευω οτι τα "θαμετακια" που εχω με pulseaudio και τα bluetooth ηχεια (μικρες διακοπες στον ηχο) θα ειναι και θεμα driver. απλα ειχα διαβασει οτι ειναι work in progress και ειπα μηπως μπηκε τελικα στον 5.8

https://github.com/tomaspinho/rtl8821ce#disclaimer

Λένε ότι αν αν δημοσιεύσει κώδικα ή ίδια η realtek το πράμα θα προχωρήσει περαιτέρω.

Και εδώ η realtek λέει ότι υποστηρίζει μόνο windows. https://www.realtek.com/en/component...821ce-software

[imitheos]

TL;DR Αν κάποιος έχει intel μηχάνημα (sandybridge <= X < broadwell) και διαπιστώσει ότι με τον 5.8 σέρνονται τα πάντα, να κοιτάξει τον scheduler cpufreq governor.

[Intro]

Spoiler:

Πήγα να παίξω ένα παιχνίδι μέσω wine και ενώ την προηγούμενη ημέρα έπαιζε τζάμι, τώρα έκανε μια ώρα να ξεκινήσει. Η πλάκα είναι ότι έπεσε στην αναβάθμιση 5.13 -> 5.14 οπότε θεώρησα ότι κάτι χάλασε στο wine. Είδα όμως ότι όταν ξεκινούσε ο X, πριν να εμφανιστεί το desktop, εμφανίζονταν κάτι κίτρινα-πράσινα-κτλ. Επίσης, σερνόταν και ο firefox. Έκανε 3 δευτερόλεπτα να πάει από την μία καρτέλα στην άλλη. Μια και ο firefox χρησιμοποιεί hardware acceleration, σκέφτηκα ότι κάτι φταίει στον amdgpu οδηγό. Κάτι θα χάλασε από τον 5.7 στον 5.8.

Έψαξα σε όλα τα σχετικά φόρα και bugzilla και δεν ανέφερε κανείς τίποτα οπότε σκέφτηκα να κάνω bisect. Ξεκίνησα λοιπόν να κάνω compile το 1ο βήμα της bisect και είδα ότι ο επεξεργαστής δεν ανέβαινε πάνω από 47 βαθμούς ενώ κανονικά πηγαίνει 62-67 όταν κάνω compile με -j4. Πώς ώρες-ώρες κολλάει το μυαλό σου και δεν σκέφτεσαι το προφανές. Με παραξένεψε που δεν ανέβασε θερμοκρασία αλλά είπα "θα είναι επειδή άνοιξα το a/c".

Αφού τελείωσε το 1ο compile, δεν θυμάμαι γιατί αλλά έτρεξα less /proc/cpuinfo για να δω κάτι. Και ντόινγκ, βλέπω ότι ο επεξεργαστής είχε συχνότητα 798MHz η οποία δεν άλλαζε με τίποτα.

[/Intro]

[Τεχνικές λεπτομέρειες]

Spoiler:

Οι επεξεργαστές των λάπτοπ (και εδώ και κάμποσο καιρό και αυτοί των desktop) υποστηρίζουν διάφορες συχνότητες ώστε να μην καταναλώνεται ρεύμα και να μην ανεβαίνουν θερμοκρασίες άδικα (υπάρχει και το σύστημα idle πέρα από το cpufreq αλλά ας μην πάμε εκεί).

Οι κλασικοί cpufreq οδηγοί, λοιπόν, υλοποιούν κάποιους governors οι οποίοι διέπουν πότε θα αλλάζει η συχνότητα στις διάφορες σκάλες:

• Performance: Πάντα θα χρησιμοποιείται η μεγαλύτερη σκάλα σαν να μην υποστηριζόταν άλλη συχνότητα
• Powersave: Πάντα θα χρησιμοποιείται η μικρότερη σκάλα
• Ondemand: Η αλλαγή γίνεται με βάση το load οπότε η μικρότερη σκάλα σε idle και σταδιακό ανέβασμα όσο ανεβαίνει το load.
• Userspace: Η αλλαγή γίνεται από κάποιον από τους πολλούς userspace δαίμονες με βάση κριτήρια που έβαλε ο χρήστης. Στις περισσότερες περιπτώσεις έχουμε ίδιο αποτέλεσμα με τον ondemand.
• Schedutil: Σχετικά πιο νέος governor ο οποίος συννενοείται με τον scheduler για να πάρει αποφάσεις. Παρόμοιο αποτέλεσμα με τον ondemand αλλά εν δυνάμει πιο έξυπνο.

Ως εδώ όλα καλά. Το υποσύστημα χρησιμοποιούταν για χρόνια και η συμπεριφορά ήταν γνωστή. Μετά ήρθε ο οδηγός intel-pstate για να εκμεταλλευτεί τις παραπάνω δυνατότητες που έδιναν οι PStates των επεξεργαστών >=
sandybridge. Και που είναι το πρόβλημα θα μου πεις; Ο οδηγός αυτός υλοποιούσε μόνο δύο governors:

• Performance: Πάντα θα χρησιμοποιείται η μεγαλύτερη σκάλα σαν να μην υποστηριζόταν άλλη συχνότητα. Μπορείς όμως να ορίσεις όρια πχ μέχρι 90% αντί για 100%.
• Powersave: Ισοδυναμεί με τον κλασικό ondemand. Η αλλαγή γίνεται με βάση το load αλλά πιο έξυπνα εκμετεαλλευόμενο τις παραπάνω πληροφορίες που παρέχει η υποδομή pstates.

Ωραίαααα Δηλαδή ενώ έχουμε ίδιο όνομα, έχουμε τελείως διαφορετική συμπεριφορά. Το είχα διαβάσει τότε αυτό, και γύρισα από τον ondemand στον powersave και όλα δούλευαν τζάμι. Έλα όμως που η κατάσταση δεν είναι ακριβώς έτσι. Ή κάποια στιγμή υλοποιήθηκαν διαφορετικές καταστάσεις λειτουργίας ή ήταν πάντα έτσι και δεν το είχα προσέξει εγώ αλλά υπάρχουν τρεις διαφορετικές καταστάσεις λειτουργίας. Όλα αυτά που ανέφερα πριν είναι για την κατάσταση "Active".

Η μία κατάσταση είναι η "Active with HWP". Οι επεξεργαστές >=broadwell έχουν hardware-managed-states δηλαδή όλα τα κάνει αυτόματα ο ίδιος ο επεξεργαστής και ο cpufreq οδηγός απλά δίνει hints.

Η επόμενη κατάσταση είναι η "Active" στην οποία δούλευαν οι επεξεργαστές sandybridge <= X < broadwell και στην οποία ίσχυαν όσα ανέφερα παραπάνω. Όταν είμαστε σε αυτή την κατάσταση, το αρχείο /sys/bus/cpu/devices/cpu0/cpufreq/scaling_driver θα έχει τιμή intel_pstate.

Η τελευταία κατάσταση είναι η "Passive" στην οποία το παραπάνω αρχείο έχει τιμή intel_cpufreq. Σε αυτή την κατάσταση, ο οδηγός συμπεριφέρεται στο περίπου όπως οι κλασικοί οδηγοί δηλαδή ο powersave κρατάει την χαμηλότερη συχνότητα πάντα.

commit 33aa46f252c703e42c81a76696cd0c240f2281e4
Commit: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
CommitDate: Fri Apr 17 17:04:38 2020 +0200

cpufreq: intel_pstate: Use passive mode by default without HWP

After recent changes allowing scale-invariant utilization to be
used on x86, the schedutil governor on top of intel_pstate in the
passive mode should be on par with (or better than) the active mode
"powersave" algorithm of intel_pstate on systems in which
hardware-managed P-states (HWP) are not used, so it should not be
necessary to use the internal scaling algorithm in those cases.

Εδώ και καιρό προωθείται ο schedutil governor επειδή συννενοείται με τον scheduler και έτσι παίρνει καλύτερες αποφάσεις. Στον 5.8 πέρασε το παραπάνω commit το οποίο γύρισε όλους τους επεξεργαστές που δεν έχουν HWP (<broadwell) στην passive κατάσταση από την active που χρησιμοποιούσαν ως τώρα και χωρίς να το καταλάβω άλλαξε την συμπεριφορά του governor.

Οπότε λοιπόν, οι λύσεις που έχω είναι: α) να αφήσω την passive που όρισαν σαν default και να γυρίσω στον schedutil, β) να αφήσω τον powersave και να βάλω boot παράμετρο intel_pstate=active ώστε να παρακάμψω την απόφασή τους. Ο schedutil υποτίθεται είναι ανώτερος αλλά σε εμένα βλέπω να ρίχνει μόνο μέχρι 2GHz την συχνότητα. Ο ondemand την ρίχνει μέχρι 1200Mhz. Ο powersave σε active την έριχνε μέχρι 800Mhz και γενικά νομίζω ότι δούλευε πολύ καλύτερα αλλά ίσως είναι ιδέα μου.

Δεν είναι και τόσο πιθανό να αντιμετωπίσεις το πρόβλημα αλλά το αναφέρω μήπως το πάθει κάποιος και ψάχνεται τσάμπα. Όσοι χρησιμοποιούν τον πυρήνα της διανομής τους ίσως να μην αντιμετωπίσουν το πρόβλημα ανάλογα με τις επιλογές που έχει κάνει η διανομή. Το Archlinux βλέπω ότι, από τον 4.9 πυρήνα ακόμη, γύρισε από τον ondemand στον schedutil. Το fedora χρησιμοποιεί τον ondemand (δεν ξέρω σε ποιον μεταφράζεται σε όσους χρησιμοποιούν intel_pstate).

Αυτά Δωρεάν αναβράζοντα χάπια για τον πονοκέφαλο σε όσους έφτασαν ως εδώ.

[/Τεχνικές λεπτομέρειες]

[GoofyX]

TL;DR Αν κάποιος έχει intel μηχάνημα (sandybridge <= X < broadwell) και διαπιστώσει ότι με τον 5.8 σέρνονται τα πάντα, να κοιτάξει τον scheduler cpufreq governor.

[Intro]

Spoiler:

Πήγα να παίξω ένα παιχνίδι μέσω wine και ενώ την προηγούμενη ημέρα έπαιζε τζάμι, τώρα έκανε μια ώρα να ξεκινήσει. Η πλάκα είναι ότι έπεσε στην αναβάθμιση 5.13 -> 5.14 οπότε θεώρησα ότι κάτι χάλασε στο wine. Είδα όμως ότι όταν ξεκινούσε ο X, πριν να εμφανιστεί το desktop, εμφανίζονταν κάτι κίτρινα-πράσινα-κτλ. Επίσης, σερνόταν και ο firefox. Έκανε 3 δευτερόλεπτα να πάει από την μία καρτέλα στην άλλη. Μια και ο firefox χρησιμοποιεί hardware acceleration, σκέφτηκα ότι κάτι φταίει στον amdgpu οδηγό. Κάτι θα χάλασε από τον 5.7 στον 5.8.

Έψαξα σε όλα τα σχετικά φόρα και bugzilla και δεν ανέφερε κανείς τίποτα οπότε σκέφτηκα να κάνω bisect. Ξεκίνησα λοιπόν να κάνω compile το 1ο βήμα της bisect και είδα ότι ο επεξεργαστής δεν ανέβαινε πάνω από 47 βαθμούς ενώ κανονικά πηγαίνει 62-67 όταν κάνω compile με -j4. Πώς ώρες-ώρες κολλάει το μυαλό σου και δεν σκέφτεσαι το προφανές. Με παραξένεψε που δεν ανέβασε θερμοκρασία αλλά είπα "θα είναι επειδή άνοιξα το a/c".

Αφού τελείωσε το 1ο compile, δεν θυμάμαι γιατί αλλά έτρεξα less /proc/cpuinfo για να δω κάτι. Και ντόινγκ, βλέπω ότι ο επεξεργαστής είχε συχνότητα 798MHz η οποία δεν άλλαζε με τίποτα.

[/Intro]

[Τεχνικές λεπτομέρειες]

Spoiler:

Οι επεξεργαστές των λάπτοπ (και εδώ και κάμποσο καιρό και αυτοί των desktop) υποστηρίζουν διάφορες συχνότητες ώστε να μην καταναλώνεται ρεύμα και να μην ανεβαίνουν θερμοκρασίες άδικα (υπάρχει και το σύστημα idle πέρα από το cpufreq αλλά ας μην πάμε εκεί).

Οι κλασικοί cpufreq οδηγοί, λοιπόν, υλοποιούν κάποιους governors οι οποίοι διέπουν πότε θα αλλάζει η συχνότητα στις διάφορες σκάλες:

• Performance: Πάντα θα χρησιμοποιείται η μεγαλύτερη σκάλα σαν να μην υποστηριζόταν άλλη συχνότητα
• Powersave: Πάντα θα χρησιμοποιείται η μικρότερη σκάλα
• Ondemand: Η αλλαγή γίνεται με βάση το load οπότε η μικρότερη σκάλα σε idle και σταδιακό ανέβασμα όσο ανεβαίνει το load.
• Userspace: Η αλλαγή γίνεται από κάποιον από τους πολλούς userspace δαίμονες με βάση κριτήρια που έβαλε ο χρήστης. Στις περισσότερες περιπτώσεις έχουμε ίδιο αποτέλεσμα με τον ondemand.
• Schedutil: Σχετικά πιο νέος governor ο οποίος συννενοείται με τον scheduler για να πάρει αποφάσεις. Παρόμοιο αποτέλεσμα με τον ondemand αλλά εν δυνάμει πιο έξυπνο.

Ως εδώ όλα καλά. Το υποσύστημα χρησιμοποιούταν για χρόνια και η συμπεριφορά ήταν γνωστή. Μετά ήρθε ο οδηγός intel-pstate για να εκμεταλλευτεί τις παραπάνω δυνατότητες που έδιναν οι PStates των επεξεργαστών >=
sandybridge. Και που είναι το πρόβλημα θα μου πεις; Ο οδηγός αυτός υλοποιούσε μόνο δύο governors:

• Performance: Πάντα θα χρησιμοποιείται η μεγαλύτερη σκάλα σαν να μην υποστηριζόταν άλλη συχνότητα. Μπορείς όμως να ορίσεις όρια πχ μέχρι 90% αντί για 100%.
• Powersave: Ισοδυναμεί με τον κλασικό ondemand. Η αλλαγή γίνεται με βάση το load αλλά πιο έξυπνα εκμετεαλλευόμενο τις παραπάνω πληροφορίες που παρέχει η υποδομή pstates.

Ωραίαααα Δηλαδή ενώ έχουμε ίδιο όνομα, έχουμε τελείως διαφορετική συμπεριφορά. Το είχα διαβάσει τότε αυτό, και γύρισα από τον ondemand στον powersave και όλα δούλευαν τζάμι. Έλα όμως που η κατάσταση δεν είναι ακριβώς έτσι. Ή κάποια στιγμή υλοποιήθηκαν διαφορετικές καταστάσεις λειτουργίας ή ήταν πάντα έτσι και δεν το είχα προσέξει εγώ αλλά υπάρχουν τρεις διαφορετικές καταστάσεις λειτουργίας. Όλα αυτά που ανέφερα πριν είναι για την κατάσταση "Active".

Η μία κατάσταση είναι η "Active with HWP". Οι επεξεργαστές >=broadwell έχουν hardware-managed-states δηλαδή όλα τα κάνει αυτόματα ο ίδιος ο επεξεργαστής και ο cpufreq οδηγός απλά δίνει hints.

Η επόμενη κατάσταση είναι η "Active" στην οποία δούλευαν οι επεξεργαστές sandybridge <= X < broadwell και στην οποία ίσχυαν όσα ανέφερα παραπάνω. Όταν είμαστε σε αυτή την κατάσταση, το αρχείο /sys/bus/cpu/devices/cpu0/cpufreq/scaling_driver θα έχει τιμή intel_pstate.

Η τελευταία κατάσταση είναι η "Passive" στην οποία το παραπάνω αρχείο έχει τιμή intel_cpufreq. Σε αυτή την κατάσταση, ο οδηγός συμπεριφέρεται στο περίπου όπως οι κλασικοί οδηγοί δηλαδή ο powersave κρατάει την χαμηλότερη συχνότητα πάντα.



Εδώ και καιρό προωθείται ο schedutil governor επειδή συννενοείται με τον scheduler και έτσι παίρνει καλύτερες αποφάσεις. Στον 5.8 πέρασε το παραπάνω commit το οποίο γύρισε όλους τους επεξεργαστές που δεν έχουν HWP (<broadwell) στην passive κατάσταση από την active που χρησιμοποιούσαν ως τώρα και χωρίς να το καταλάβω άλλαξε την συμπεριφορά του governor.

Οπότε λοιπόν, οι λύσεις που έχω είναι: α) να αφήσω την passive που όρισαν σαν default και να γυρίσω στον schedutil, β) να αφήσω τον powersave και να βάλω boot παράμετρο intel_pstate=active ώστε να παρακάμψω την απόφασή τους. Ο schedutil υποτίθεται είναι ανώτερος αλλά σε εμένα βλέπω να ρίχνει μόνο μέχρι 2GHz την συχνότητα. Ο ondemand την ρίχνει μέχρι 1200Mhz. Ο powersave σε active την έριχνε μέχρι 800Mhz και γενικά νομίζω ότι δούλευε πολύ καλύτερα αλλά ίσως είναι ιδέα μου.

Δεν είναι και τόσο πιθανό να αντιμετωπίσεις το πρόβλημα αλλά το αναφέρω μήπως το πάθει κάποιος και ψάχνεται τσάμπα. Όσοι χρησιμοποιούν τον πυρήνα της διανομής τους ίσως να μην αντιμετωπίσουν το πρόβλημα ανάλογα με τις επιλογές που έχει κάνει η διανομή. Το Archlinux βλέπω ότι, από τον 4.9 πυρήνα ακόμη, γύρισε από τον ondemand στον schedutil. Το fedora χρησιμοποιεί τον ondemand (δεν ξέρω σε ποιον μεταφράζεται σε όσους χρησιμοποιούν intel_pstate).

Αυτά Δωρεάν αναβράζοντα χάπια για τον πονοκέφαλο σε όσους έφτασαν ως εδώ.

[/Τεχνικές λεπτομέρειες]

Επειδή ο πονοκέφαλος όντως είναι στα κοντά... Κι επειδή γύρισα από τις διακοπές κι ένα να κάνω ενημέρωση 3 συστήματα, το πιο παλιό από αυτά είναι με Haswell (i5 4590), θα έχω θέμα σύμφωνα με τα παραπάνω; Μάλλον όχι...;

[imitheos]

Gentoo είναι όλα ή άλλες διανομές με τον μανίσιο πυρήνα της διανομής; Είναι ανάλογα τι επιλογές τρέχεις στον πυρήνα. Σε 3-4 διανομές που είδα, οι μανίσιες επιλογές είναι έτσι που δεν θα συμβεί το πρόβλημα.

Τρέξε

% cat /sys/bus/cpu/devices/cpu0/cpufreq/scaling_{driver,governor}

Αν ο driver λέει intel_pstate και ο governor λέει powersave, τότε θα πρέπει να κάνεις μία από τις δύο λύσεις που έγραψα. Αν δεν είναι ο συγκεκριμένος συνδυασμός, τότε δεν χρειάζεται να κάνεις τίποτα. Ο περισσότερος κόσμος δεν νοιάζεται για powersaving και τρέχει συνέχεια τον performance governor οπότε δεν έχει κανένα πρόβλημα. Οι υπόλοιποι συνήθως τρέχουν κάποιο userspace δαίμονα που χειρίζεται τις αλλαγές οπότε πάλι δεν υπάρχει θέμα. Μόνο αν είσαι σαν και εμένα και δεν είδες ποτέ κάποιο λόγο ύπαρξης στους συγκεκριμένους δαίμονες όταν ο πυρήνας έχει εγγενή υποστήριξη και άλλαξες χειροκίνητα την επιλογή του governor θα μπορούσες να πέσεις στο συγκεκριμένο πρόβλημα.

[GoofyX]

Gentoo είναι όλα ή άλλες διανομές με τον μανίσιο πυρήνα της διανομής; Είναι ανάλογα τι επιλογές τρέχεις στον πυρήνα. Σε 3-4 διανομές που είδα, οι μανίσιες επιλογές είναι έτσι που δεν θα συμβεί το πρόβλημα.

Τρέξε

% cat /sys/bus/cpu/devices/cpu0/cpufreq/scaling_{driver,governor}

Αν ο driver λέει intel_pstate και ο governor λέει powersave, τότε θα πρέπει να κάνεις μία από τις δύο λύσεις που έγραψα. Αν δεν είναι ο συγκεκριμένος συνδυασμός, τότε δεν χρειάζεται να κάνεις τίποτα. Ο περισσότερος κόσμος δεν νοιάζεται για powersaving και τρέχει συνέχεια τον performance governor οπότε δεν έχει κανένα πρόβλημα.

Όλα Gentoo. Και στα 3 μηχανήματα βγάζει:

intel_pstate
powersave

Δε θα ήθελα όμως να είμαι σε performance συνέχεια. Στο μηχάνημα με τον Haswell επίτηδες δεν έκανα upgrade σε 5.8 για να διευθετήσω το παραπάνω θέμα. Από αυτά που γράφεις, καταλαβαίνω ότι το πρόβλημα υφίσταται σε επεξεργαστές Sandy Bridge και κάτω, έτσι δεν είναι;

[imitheos]

Όλα Gentoo. Και στα 3 μηχανήματα βγάζει:

intel_pstate
powersave

Παράξενο. Άρα είσαι στην ίδια κατάσταση με εμένα. Επέλεξες στο config του πυρήνα να είναι μανίσιος ο powersave ή τον άλλαξες σε κάποιο init αρχείο;

Στο μηχάνημα με τον Haswell επίτηδες δεν έκανα upgrade σε 5.8 για να διευθετήσω το παραπάνω θέμα. Από αυτά που γράφεις, καταλαβαίνω ότι το πρόβλημα υφίσταται σε επεξεργαστές Sandy Bridge και κάτω, έτσι δεν είναι;

Όχι. Η κατάσταση είναι ως εξής:

• PC < Sandybridge: Δεν υποστηρίζεται ο intel_pstate οπότε δουλεύεις με τους παλιούς οδηγούς και δεν έχεις θέμα.
• Sandybridge <= PC < Broadwell: Εδώ εμφανίζεται το πρόβλημα στον 5.8 λόγω της αλλαγής.
• Broadwell <= PC: Εδώ ο επεξεργαστής υποστηρίζει στο hardware τα pstates οπότε και εδώ δεν έχει θέμα.

Κάνε το εξής:

% cat /sys/bus/cpu/devices/cpu0/cpufreq/cpuinfo_*_freq
3600000
800000

για να δεις τι συχνότητες υποστηρίζει ο επεξεργαστής σου. Έπειτα κάνε κανονικά compile τον πυρήνα 5.8 και εκκίνησε με αυτόν. Δεν έχεις να πάθει κάτι το pc απλά θα είναι αργό. Κάνε less /proc/cpuinfo και δες τι συχνότητα λέει. Αν είναι κολλημένη στην μικρότερη (σε εμένα ήταν 798MHz) όπως βλέπεις από το παραπάνω (επίσης το αρχείο scaling_driver που είδες πριν, θα έχει αλλάξει από intel_pstate σε intel_cpufreq), τότε θα κάνεις ένα από τα δύο workarounds.

Ή πειράζεις τον bootloader σου ώστε να ορίζει την παράμετρο intel_pstate=active οπότε στο επόμενο boot, ο powersave θα παίζει όπως μέχρι τώρα ή αλλάζεις τον scaling governor σε schedutil. Εγώ τον άφησα σε schedutil ακόμη για να δω μήπως έχουν δίκιο και παίζει καλύτερα. Κάνοντας cat /proc/cpuinfo δεν είδα ποτέ να ρίχνει την συχνότητα όσο τήν έριχνε ο powersave αλλά το powertop δείχνει ότι πέφτει σε όλες τις γκάμες οπότε λογικά παίζει σωστά ο schedutil.

Αν θέλεις να αλλάξεις τον governor σε schedutil, ή το κάνεις στο config του πυρήνα ή το κάνεις σε κάποιο init αρχείο

for pol in /sys/devices/system/cpu/cpufreq/policy*; do
	echo schedutil > ${pol}/scaling_governor
done

(Έχω παρατηρήσει ότι και μόνο στο ένα πυρήνα να το αλλάξω, αλλάζει σε όλους αλλά παρόλα αυτά το ορίζω σε όλους)