walaw
(Themenstarter)
Anmeldungsdatum: 18. Februar 2014
Beiträge: 54
|
Kellerkind_2009 schrieb: Das war dieser Befehl 😉 inxi -Fv 6 wie dem aus sei – mir gehen dann so langsam.... Zeige mal noch dmesg | grep hpet
| [ 0.218798] clocksource: hpet: mask: 0xffffffff max_cycles: 0xffffffff, max_idle_ns: 133484882848 ns
[ 0.218806] hpet clockevent registered
[ 0.335348] hpet0: at MMIO 0xfed00000, IRQs 2, 8, 24, 25, 26, 27, 28, 0
[ 0.335351] hpet0: 8 comparators, 64-bit 14.318180 MHz counter
[ 0.337374] hpet: hpet2 irq 24 for MSI
[ 0.337382] hpet: hpet3 irq 25 for MSI
[ 0.337384] hpet: hpet4 irq 26 for MSI
[ 0.337384] hpet: hpet5 irq 27 for MSI
[ 0.337384] hpet: hpet6 irq 28 for MSI
[ 1.400692] rtc_cmos 00:01: alarms up to one month, 242 bytes nvram, hpet irqs
|
|
Kellerkind_2009
Anmeldungsdatum: 26. November 2009
Beiträge: 19610
Wohnort: Schleswig-Holstein
|
Schalte im Bios mal den HPET auf 32 Bit runter.Zur Zeit steht er auf 64 Bit [ 0.335351] hpet0: 8 comparators, 64-bit 14.318180 MHz counter Dann wieder Testen.Wenn das auch scheitert muss ich passen 😳
|
walaw
(Themenstarter)
Anmeldungsdatum: 18. Februar 2014
Beiträge: 54
|
Kellerkind_2009 schrieb: Schalte im Bios mal den HPET auf 32 Bit runter.Zur Zeit steht er auf 64 Bit [ 0.335351] hpet0: 8 comparators, 64-bit 14.318180 MHz counter Dann wieder Testen.Wenn das auch scheitert muss ich passen 😳
Komisch, hab ich im BIOS auf 32Bit gesetzt, wird nach dem Reboot in Linux immer noch als 64Bit angezeigt!? Knarzt weiterhin. | [ 0.218527] clocksource: hpet: mask: 0xffffffff max_cycles: 0xffffffff, max_idle_ns: 133484882848 ns
[ 0.218535] hpet clockevent registered
[ 0.335074] hpet0: at MMIO 0xfed00000, IRQs 2, 8, 24, 25, 26, 27, 28, 0
[ 0.335077] hpet0: 8 comparators, 64-bit 14.318180 MHz counter
[ 0.337101] hpet: hpet2 irq 24 for MSI
[ 0.337109] hpet: hpet3 irq 25 for MSI
[ 0.337110] hpet: hpet4 irq 26 for MSI
[ 0.337110] hpet: hpet5 irq 27 for MSI
[ 0.337110] hpet: hpet6 irq 28 for MSI
[ 1.412239] rtc_cmos 00:01: alarms up to one month, 242 bytes nvram, hpet irqs
stu
|
|
Kellerkind_2009
Anmeldungsdatum: 26. November 2009
Beiträge: 19610
Wohnort: Schleswig-Holstein
|
Gespeichert hast du die Einstellung aber im Bios.. 😬 Kannst du es ganz abschalten im Bios?
|
walaw
(Themenstarter)
Anmeldungsdatum: 18. Februar 2014
Beiträge: 54
|
Kellerkind_2009 schrieb: Gespeichert hast du die Einstellung aber im Bios.. 😬 Kannst du es ganz abschalten im Bios?
Es ist gespeichert im BIOS und steht dort auch auf 32Bit. Ich hatte es tatsächlich von 32Bit auf 64 Bit gesetzt - jetzt nach deiner Aufforderung wieder zurück - das scheint irgendwie aber nicht an Linux weitergereicht worden zu sein. ABER: Ich habe an dem Mainboard nur 2 USB 3.0 Ports, wenn ich meine USB-Soundkarten daran anschließe, habe ich KEIN Knarzen. Wenn ich an dem einen USB-3-Port einen USB-3.0-Hub anschließe um daran die EDIROL anschließe, habe ich wieder Knarzen. Wenn ich die Soundkarten - auch bei nicht angeschlossenem HUB an irgend einem der USB 2.0 Ports anschließen habe ich IMMER Knarzen. Also - ich hätte da schon ganz gerne einen USB-3.0 HUB, da ich eine USB-3.0-Videocaptere-Card betreiben will, eine USB-Soundkarte und MINDESTENS eine USB-3.0-Festplatte um die Streams zu sichern (ohne dass das Jahre dauert über USB 2.0). Aber meine Soundkarten sind eigentlich USB 2.0 - scheinen sich aber nur mit dem 3.0-Port zu vertragen. Kann das auch ein Stromproblem sein?
|
Kellerkind_2009
Anmeldungsdatum: 26. November 2009
Beiträge: 19610
Wohnort: Schleswig-Holstein
|
Dann weist du ja schon etwas mehr 😎 Warum kann Windows damit aber umgehen?? Power ermitteln lsusb -v|egrep "^Bus|MaxPower"
|
walaw
(Themenstarter)
Anmeldungsdatum: 18. Februar 2014
Beiträge: 54
|
Kellerkind_2009 schrieb: Dann weist du ja schon etwas mehr 😎
Ja - und im Nachhinein denkt man dann immer - "Warum hab ich nicht gleich die Ports ALLE mal durchgecheckt". Das Phänomen das nicht alle Ports gleich gut funktionieren habe ich oft schon gehabt. Also an diversen Rechnern.
Warum kann Windows damit aber umgehen??
Hm... "bessere" Treiber? Das alte Leid mit X86-Hardware und Herstellern die Linux-Entwicklern nicht transparent alle Infos zur sauberen Treiberentwicklung geben? Wenn dann müsste sich dass ja irgendwie auf das USB 2.0 Subsystem unter Linux beziehen. 2.0 stirbt ja eh weg. Aber die alte Möhre hier funktioniert ja "im Prinzip" - und solange sie das tut, seh ich das nicht ganz ein, sie einzuschrotten. Wenn möglich würde ich gerne unter Linux oder Mac arbeiten. Win ist echt nur ne Notlösung. Reicht mir dass ich beruflich immer mit nem Win10 Laptop hantieren muss. :/
Power ermitteln
lsusb -v|egrep "^Bus|MaxPower"
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48 | Couldn't open device, some information will be missing
Couldn't open device, some information will be missing
Couldn't open device, some information will be missing
Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
MaxPower 0mA
Bus 009 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
MaxPower 0mA
Bus 008 Device 003: ID 258a:0001
MaxPower 100mA
Couldn't open device, some information will be missing
Couldn't open device, some information will be missing
Bus 008 Device 002: ID 046d:c05a Logitech, Inc. M90/M100 Optical Mouse
MaxPower 100mA
Bus 008 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Couldn't open device, some information will be missing
Couldn't open device, some information will be missing
MaxPower 0mA
Bus 007 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Couldn't open device, some information will be missing
MaxPower 0mA
Bus 006 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
MaxPower 0mA
Couldn't open device, some information will be missing
Bus 011 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
MaxPower 0mA
Bus 010 Device 003: ID 08bb:2902 Texas Instruments PCM2902 Audio Codec
MaxPower 100mA
Couldn't open device, some information will be missing
Couldn't open device, some information will be missing
Bus 010 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
MaxPower 0mA
Couldn't open device, some information will be missing
Bus 001 Device 002: ID 0bda:8172 Realtek Semiconductor Corp. RTL8191SU 802.11n WLAN Adapter
MaxPower 500mA
Couldn't open device, some information will be missing
Couldn't open device, some information will be missing
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
MaxPower 0mA
Bus 005 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
MaxPower 0mA
Bus 004 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Couldn't open device, some information will be missing
MaxPower 0mA
Bus 003 Device 002: ID 0582:0074 Roland Corp. EDIROL UA-25
MaxPower 480mA
Couldn't open device, some information will be missing
Bus 003 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
MaxPower 0mA
|
|
Kellerkind_2009
Anmeldungsdatum: 26. November 2009
Beiträge: 19610
Wohnort: Schleswig-Holstein
|
Die Stromaufnahmen der einzelnen Porte liegt im Bereich des zumutbaren ☺ Würde gerne nochmal auf den HPET zurück kommen.Du kannst dem Kernel anweisen HPET zu ignorieren. Ob es damit besser ist kann ich aber nicht sagen.Du kannst es dem Kernel "Einmalig" mit auf dem Weg geben Bootoptionen (Abschnitt „Start-eines-installierten-Systems-einmalig“) oder du trägst folgendes in die /etc/default/grub ein von z.b.
GRUB_CMDLINE_LINUX_DEFAULT="quiet splash"
in
GRUB_CMDLINE_LINUX_DEFAULT="quiet splash hpet=disable" Danach sudo update-grub Neustart. Kontrolle wieder mit dmesg | grep hpet
|
walaw
(Themenstarter)
Anmeldungsdatum: 18. Februar 2014
Beiträge: 54
|
Kellerkind_2009 schrieb: Die Stromaufnahmen der einzelnen Porte liegt im Bereich des zumutbaren ☺ Würde gerne nochmal auf den HPET zurück kommen.Du kannst dem Kernel anweisen HPET zu ignorieren. Ob es damit besser ist kann ich aber nicht sagen.Du kannst es dem Kernel "Einmalig" mit auf dem Weg geben Bootoptionen (Abschnitt „Start-eines-installierten-Systems-einmalig“) oder du trägst folgendes in die /etc/default/grub ein von z.b.
GRUB_CMDLINE_LINUX_DEFAULT="quiet splash"
in
GRUB_CMDLINE_LINUX_DEFAULT="quiet splash hpet=disable" Danach sudo update-grub Neustart. Kontrolle wieder mit dmesg | grep hpet
Hallo. Ich habe das heute an meinem neuen USB3.0 Hub getestet. Erst nur der neue Hub = Knarzen. Dann HPET disabled, reboot - wieder am neuen 3.0 Hub - scheinbar kein Knarzen. Ich muss jetzt noch die USB 2.0 Ports checken - wenn es da dann klappt - scheint die Sache gesolved zu sein. Es sei denn HPET ist super wichtig?
|
Kellerkind_2009
Anmeldungsdatum: 26. November 2009
Beiträge: 19610
Wohnort: Schleswig-Holstein
|
Das ist doch schon mal ein positives Ergebnis 😉 HPET ist nicht zwingend erforderlich, https://de.wikipedia.org/wiki/High_Precision_Event_Timer gibt sogar viele die damit große Probleme haben (Speziell bei AMD). Es werden/sollten auch keine anderen Probleme mit deaktivierten HPET auftreten ☺
|