SATA Hotplugging auf Linux Mint 21

Log?

In welchem Log müsste darüber was stehen?

Boote doch einfach mal mit dem vorherigen Kernel. Dann siehst Du was los ist.

Jack V. schrieb:

Log?

+1

Moriz schrieb:

In welchem Log müsste darüber was stehen?

/var/log/syslog

Hier das Ende von syslog:

1

Feb 12 15:01:08 mint-21 ntpd[2673]: 185.232.69.65 local addr 192.168.178.108 -> <null>

2

Feb 12 15:05:01 mint-21 CRON[23976]: (root) CMD (command -v debian-sa1 > /dev/null && debian-sa1 1 1)

3

Feb 12 15:08:39 mint-21 rtkit-daemon[1874]: Supervising 4 threads of 3 processes of 1 users.

4

Feb 12 15:10:28 mint-21 rtkit-daemon[1874]: message repeated 13 times: [ Supervising 4 threads of 3 processes of 1 users.]

5

Feb 12 15:15:01 mint-21 CRON[24852]: (root) CMD (command -v debian-sa1 > /dev/null && debian-sa1 1 1)

6

Feb 12 15:17:01 mint-21 CRON[25112]: (root) CMD (   cd / && run-parts --report /etc/cron.hourly)

7

Feb 12 15:25:01 mint-21 CRON[25864]: (root) CMD (command -v debian-sa1 > /dev/null && debian-sa1 1 1)

8

Feb 12 15:30:01 mint-21 CRON[26167]: (root) CMD ([ -x /etc/init.d/anacron ] && if [ ! -d /run/systemd/system ]; then /usr/sbin/invoke-rc.d anacron start >/dev/null; fi)

9

Feb 12 15:30:45 mint-21 rtkit-daemon[1874]: Supervising 4 threads of 3 processes of 1 users.

10

Feb 12 15:31:11 mint-21 rtkit-daemon[1874]: message repeated 7 times: [ Supervising 4 threads of 3 processes of 1 users.]

11

Feb 12 15:31:37 mint-21 systemd[1]: Started Run anacron jobs.

12

Feb 12 15:31:37 mint-21 anacron[26401]: Anacron 2.3 started on 2024-02-12

13

Feb 12 15:31:37 mint-21 anacron[26401]: Normal exit (0 jobs run)

14

Feb 12 15:31:37 mint-21 systemd[1]: anacron.service: Deactivated successfully.

15

Feb 12 15:35:01 mint-21 CRON[26593]: (root) CMD (command -v debian-sa1 > /dev/null && debian-sa1 1 1)

16

Feb 12 15:45:01 mint-21 CRON[26939]: (root) CMD (command -v debian-sa1 > /dev/null && debian-sa1 1 1)

Wenn ich das recht sehe, steht dort nichts von der Platte. Seit 15:00 habe ich die Platte mehrfach in den Wechselrahmen reingeschoben und wieder raus geholt.

Syslog ist heutzutage nicht mehr Default. Am einfachsten geht’s wohl, wenn du als Root ›journalctl -f‹ eingibst, und dann die Platte anschließt – dann sollte Text dazukommen, der wäre von Interesse.

Das kam nach dem Einlegen dazu:

1

$ sudo journalctl -f

2

[sudo] password for inet:       

3

Feb 12 16:15:01 mint-21 CRON[28879]: pam_unix(cron:session): session closed for user root

4

Feb 12 16:15:26 mint-21 rtkit-daemon[1874]: Supervising 4 threads of 3 processes of 1 users.

5

Feb 12 16:15:26 mint-21 rtkit-daemon[1874]: Supervising 4 threads of 3 processes of 1 users.

6

Feb 12 16:17:01 mint-21 CRON[28949]: pam_unix(cron:session): session opened for user root(uid=0) by (uid=0)

7

Feb 12 16:17:01 mint-21 CRON[28950]: (root) CMD (   cd / && run-parts --report /etc/cron.hourly)

8

Feb 12 16:17:01 mint-21 CRON[28949]: pam_unix(cron:session): session closed for user root

9

Feb 12 16:17:25 mint-21 rtkit-daemon[1874]: Supervising 4 threads of 3 processes of 1 users.

10

Feb 12 16:17:25 mint-21 rtkit-daemon[1874]: Supervising 4 threads of 3 processes of 1 users.

11

Feb 12 16:19:27 mint-21 sudo[29130]:     inet : TTY=pts/3 ; PWD=/home/inet ; USER=root ; COMMAND=/usr/bin/journalctl -f

12

Feb 12 16:19:27 mint-21 sudo[29130]: pam_unix(sudo:session): session opened for user root(uid=0) by (uid=1000)

Dasselbe, wie in syslog weiter oben…

Nach dem Platte wieder rausziehen kam gar nichts

Für die Vertreter der ›old school‹ Bewegung: dmesg -w

Ganz generell würde ich aber auch mal nach LPM schauen.

Den Wechselrahmen kann man wohl auch als Fehlerquelle ausschließen: Das ist ein 4-fach-Wechselrahmen, im ersten Slot hatte ich die home-Platte, die beim Boot auf die SSD gemountet wird, im 2. Slot üblicherweise bei Bedarf die andere Platte.

Ich habe versuchsweise die Home-Platte in Slot 2 gebootet und die Wechselplatte in Slot 1 – geändert hat sich am Gesamtbild nichts.

Norbert schrieb:

Für die Vertreter der ›old school‹ Bewegung: dmesg -w

Old school scheint auch Ferien zu haben: Null Reaktion, wenn ich die Platte einschiebe.

Ganz generell würde ich aber auch mal nach LPM schauen.

Ich habe auf die Schnelle nur gefunden, wie man die Einstellungen ändern kann. Wie kann man den aktuellen Zustand abfragen?

Mal in

1

/sys/devices/pci………/link_power_management_policy

schauen. Ein

1

find /sys -name "link_power_management_policy"

hilft bei der Suche.

Edit: Meine sagen:›max_performance‹

Edit2:

1

# find /sys -iname "link_power_management_policy" -exec cat {} \;

max_performance max_performance max_performance max_performance max_performance max_performance

Alle 8 SATA-Ports sind auf med_power_with_dipm

Moriz schrieb:

Alle 8 SATA-Ports sind auf med_power_with_dipm

Na dann würde ich nur zum Spaß mal ein ›max_performance‹ mittels echo -n hinein massieren.

Ist das persistent, oder geht es nach dem Boot wieder auf med_power_with_dipm?

Moriz schrieb:

Ist das persistent, oder geht es nach dem Boot wieder auf med_power_with_dipm?

Isses nicht. Dafür gibt's andere Stellen. Müsste ich aber auch erst einmal suchen.

Ich probiere erst mal den vorherigen Kernel, ehe ich da an Einstellungen rum schraube.

Moriz schrieb:

Ich probiere erst mal den vorherigen Kernel, ehe ich da an Einstellungen rum schraube.

ThumbUp PS. Kann es sein das in deinem System ein mobile Prozessor werkelt?

Steve van de Grens schrieb:

Wenn die Festplatte vor dem Booten angeschlossen ist, wird sie dann erkannt?

Ja

Spielt Kaltstart vs. Warmstart eine Rolle?

Nein

Norbert schrieb:

Moriz schrieb:

Ich probiere erst mal den vorherigen Kernel, ehe ich da an Einstellungen rum schraube.

ThumbUp PS. Kann es sein das in deinem System ein mobile Prozessor werkelt?

Nein:

1

   description: Desktop Computer

2

    product: Z690 AORUS ELITE DDR4 (Default string)

3

    vendor: Gigabyte Technology Co., Ltd.

4

    version: Default string

5

    serial: Default string

6

    width: 64 bits

7

    capabilities: smbios-3.5.0 dmi-3.5.0 smp vsyscall32

8

    configuration: boot=normal chassis=desktop family=Z690 MB sku=Default string uuid=035e02d8-04d3-0532-8106-670700080009

9

10

          description: CPU

11

          product: 12th Gen Intel(R) Core(TM) i5-12600T

12

          vendor: Intel Corp.

13

          physical id: 4e

14

          bus info: cpu@0

15

          version: 6.151.5

16

          serial: To Be Filled By O.E.M.

17

          slot: U3E1

18

          size: 1534MHz

19

          capacity: 4600MHz

20

          width: 64 bits

21

          clock: 100MHz

22

          capabilities: lm fpu fpu_exception wp vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx pdpe1gb rdtscp x86-64 constant_tsc art arch_perfmon pebs bts rep_good nopl xtopology nonstop_tsc cpuid aperfmperf tsc_known_freq pni pclmulqdq dtes64 monitor ds_cpl vmx smx est tm2 ssse3 sdbg fma cx16 xtpr pdcm sse4_1 sse4_2 x2apic movbe popcnt tsc_deadline_timer aes xsave avx f16c rdrand lahf_lm abm 3dnowprefetch cpuid_fault ssbd ibrs ibpb stibp ibrs_enhanced tpr_shadow vnmi flexpriority ept vpid ept_ad fsgsbase tsc_adjust bmi1 avx2 smep bmi2 erms invpcid rdseed adx smap clflushopt clwb intel_pt sha_ni xsaveopt xsavec xgetbv1 xsaves split_lock_detect avx_vnni dtherm ida arat pln pts hwp hwp_notify hwp_act_window hwp_epp hwp_pkg_req umip pku ospke waitpkg gfni vaes vpclmulqdq tme rdpid movdiri movdir64b fsrm md_clear serialize pconfig arch_lbr flush_l1d arch_capabilities cpufreq

23

          configuration: cores=6 enabledcores=6 microcode=50 threads=12

Nachdem im Log augenscheinlich rein gar nichts dazu aufgetaucht, würde mein nächster Blick nun in Richtung udev gehen: ›udevadm monitor‹ starten, HDD anschließen und schauen.

Auch da ist tote Hose:

1

$ udevadm monitor

2

monitor will print the received events for:

3

UDEV - the event which udev sends out after rule processing

4

KERNEL - the kernel uevent

Wenn ich aber einen USB-Stick anstecke, dann geht ein wahres Gewitter los.

Moriz schrieb:

Wenn ich aber einen USB-Stick anstecke, dann geht ein wahres Gewitter los.

Darum filtert man ja normalerweise auch ein wenig vor.

Was macht denn LPM? ;-)

Eben habe ich mit der Vorgänger-Version des aktuellen Mint gebootet: Hotplugging funktioniert damit, ich konnte die Platte mounten.

Moriz schrieb:

Eben habe ich mit der Vorgänger-Version des aktuellen Mint gebootet: Hotplugging funktioniert damit, ich konnte die Platte mounten.

Na das wäre doch eine wundervolle Gelegenheit erneut LPM zu überprüfen. (Und dann zu staunen)

Norbert schrieb:

Na das wäre doch eine wundervolle Gelegenheit erneut LPM zu überprüfen. (Und dann zu staunen)

Die stehen jetzt alle auf max_performance – staun…

Moriz schrieb:

Norbert schrieb:

Na das wäre doch eine wundervolle Gelegenheit erneut LPM zu überprüfen. (Und dann zu staunen)

Die stehen jetzt alle auf max_performance – staun…

Darum gibt's die folgende allgemeingültige Regel: Wenn man seine Schlüssel verloren hat, dann sucht man sie nicht da wo die Laterne am hellsten scheint, sondern da wo man sie vermutlich verloren hat, ;-)

Moriz schrieb:

Eben habe ich mit der Vorgänger-Version des aktuellen Mint gebootet: Hotplugging funktioniert damit, ich konnte die Platte mounten.

Dann würde ich nun das Log vom Boot mit diesem Kernel mit dem des Boots mit dem anderen Kernel vergleichen.

Norbert schrieb:

Wenn man seine Schlüssel verloren hat, dann sucht man sie nicht da wo die Laterne am hellsten scheint, sondern da wo man sie vermutlich verloren hat, ;-)

Also man bootet mit der Vorgängerversion ;-)

Moriz schrieb:

Norbert schrieb:

Wenn man seine Schlüssel verloren hat, dann sucht man sie nicht da wo die Laterne am hellsten scheint, sondern da wo man sie vermutlich verloren hat, ;-)

Also man bootet mit der Vorgängerversion ;-)

Kneifzange -> Hose ;-)

Edit: ahci.mobile_lpm_policy=1

Norbert schrieb:

ahci.mobile_lpm_policy=1

???

Kernel-Bootparameter. https://wiki.ubuntuusers.de/Bootoptionen/

Nichtsdestotrotz ist da die grundlegende Vorgehensweise der Mitgabe von Kernelparametern beim Boot beschrieben.

Moriz schrieb:

Norbert schrieb:

ahci.mobile_lpm_policy=1

???

Sorry, da war ich ein wenig kryptisch.

Also, wenn man diesen Parameter direkt beim Booten übergibt, sollte das Power-Mismanagement ausgeschaltet werden.

Wenn du's nur mal kurz ausprobieren möchtest, kannst du den Bootvorgang im Grub unterbrechen und das da oben von Hand an die kernel Zeile anhängen.

Wenn's gut ist, dann kann man das so im System verewigen, das es jedes Mal automagisch passiert.

ahci.mobile_lpm_policy=1 in die Boot-Kommandozeile eingetragen behebt das Problem. Fragt sich nur, wen welcher Teufel geritten hat, die Standard-Einstellung zu ändern…

Vielen Dank für die Hilfe!

Moriz schrieb:

ahci.mobile_lpm_policy=1 in die Boot-Kommandozeile eingetragen behebt das Problem. Fragt sich nur, wen welcher Teufel geritten hat, die Standard-Einstellung zu ändern…

Vielen Dank für die Hilfe!

Danke für die Rückmeldung.

Was den Teufel angeht, der ist möglicherweise Bündnis90-Grün gekleidet, hat oftmals keine abgeschlossene Berufsausbildung und möchte als Ministerin*in unbedingt Energie sparen. Gelegentlich auch mal etwas zu viel.

Norbert schrieb:

Gelegentlich auch mal etwas zu viel.

Das macht sie dann durch eine Pilgerfahrt in die Ost-Kokaine wieder wett…