Arch Linux

AHCI -> Festplatte super langsam!

david86

Hallo,

Mit Kernel 2.6.27 und AHCI läuft meine Festplatte extrem langsam.

Lösung:

pci=nomsi

als Bootparameter übergeben
(leider quitscht mein Prozessor damit auch wieder in den höchsten Tönen)
----

hdparm -t /dev/sda liefert:
 Timing buffered disk reads: 34 MB in 3.20 seconds = 7.53 MB/sec

und weniger!

Das war mal mehr als viermal soviel. Das booten und Programmstarts dauern eine gefühlte Ewigkeit. Das HDD-LED flackert. Manchmal tut sich sogar gar nichts mehr (HDD LED aus!) bis ich dann auf eine beliebige Taste drücke (HDD LED geht an). Solange ich eine Taste gedrückt halte ist alles normal, die HDD LED stabil (an bzw aus).

Edit:

scheint an meinen Sytemeinstellungen zu liegen. hab ne Bekannte mit fast dem selben Rechner, auf dem fast das gleiche System läuft, ausser dass dort wie bei fs4000 AHCI keine Probleme macht.

Ich hoffe jemand weis was ich tun kann (ausser AHCI im Bios abstellen)

lspci:
00:00.0 Host bridge: Intel Corporation Mobile PM965/GM965/GL960 Memory Controller Hub (rev 0c)
00:02.0 VGA compatible controller: Intel Corporation Mobile GM965/GL960 Integrated Graphics Controller (rev 0c)
00:02.1 Display controller: Intel Corporation Mobile GM965/GL960 Integrated Graphics Controller (rev 0c)
00:1a.0 USB Controller: Intel Corporation 82801H (ICH8 Family) USB UHCI Controller #4 (rev 03)
00:1a.1 USB Controller: Intel Corporation 82801H (ICH8 Family) USB UHCI Controller #5 (rev 03)
00:1a.7 USB Controller: Intel Corporation 82801H (ICH8 Family) USB2 EHCI Controller #2 (rev 03)
00:1b.0 Audio device: Intel Corporation 82801H (ICH8 Family) HD Audio Controller (rev 03)
00:1c.0 PCI bridge: Intel Corporation 82801H (ICH8 Family) PCI Express Port 1 (rev 03)
00:1c.1 PCI bridge: Intel Corporation 82801H (ICH8 Family) PCI Express Port 2 (rev 03)
00:1c.2 PCI bridge: Intel Corporation 82801H (ICH8 Family) PCI Express Port 3 (rev 03)
00:1c.3 PCI bridge: Intel Corporation 82801H (ICH8 Family) PCI Express Port 4 (rev 03)
00:1c.4 PCI bridge: Intel Corporation 82801H (ICH8 Family) PCI Express Port 5 (rev 03)
00:1c.5 PCI bridge: Intel Corporation 82801H (ICH8 Family) PCI Express Port 6 (rev 03)
00:1d.0 USB Controller: Intel Corporation 82801H (ICH8 Family) USB UHCI Controller #1 (rev 03)
00:1d.1 USB Controller: Intel Corporation 82801H (ICH8 Family) USB UHCI Controller #2 (rev 03)
00:1d.2 USB Controller: Intel Corporation 82801H (ICH8 Family) USB UHCI Controller #3 (rev 03)
00:1d.7 USB Controller: Intel Corporation 82801H (ICH8 Family) USB2 EHCI Controller #1 (rev 03)
00:1e.0 PCI bridge: Intel Corporation 82801 Mobile PCI Bridge (rev f3)
00:1f.0 ISA bridge: Intel Corporation 82801HEM (ICH8M) LPC Interface Controller (rev 03)
00:1f.1 IDE interface: Intel Corporation 82801HBM/HEM (ICH8M/ICH8M-E) IDE Controller (rev 03)
00:1f.2 SATA controller: Intel Corporation 82801HBM/HEM (ICH8M/ICH8M-E) SATA AHCI Controller (rev 03)
00:1f.3 SMBus: Intel Corporation 82801H (ICH8 Family) SMBus Controller (rev 03)
04:00.0 Ethernet controller: Broadcom Corporation NetLink BCM5906M Fast Ethernet PCI Express (rev 02)
0c:00.0 Network controller: Intel Corporation PRO/Wireless 4965 AG or AGN Network Connection (rev 61)
0e:06.0 FireWire (IEEE 1394): Ricoh Co Ltd R5C832 IEEE 1394 Controller (rev 05)
0e:06.1 SD Host controller: Ricoh Co Ltd R5C822 SD/SDIO/MMC/MS/MSPro Host Adapter (rev 22)
0e:06.2 System peripheral: Ricoh Co Ltd R5C843 MMC Host Controller (rev 12)
0e:06.3 System peripheral: Ricoh Co Ltd R5C592 Memory Stick Bus Host Adapter (rev ff)

fs4000

Seltsam, wir haben doch das selbe Notebook. Zepto Znote 3215W, korrekt?
Ich habe keine Probleme:

# hdparm -t /dev/sda

/dev/sda:
 Timing buffered disk reads:  102 MB in  3.00 seconds =  33.97 MB/sec

AHCI ist aktiviert, Architektur ist x86_64, System ist aktuell.

david86

Ja, (Compal IFL91), x86_64 und aktuell. Mit AHCI im Bios habe ich Probleme, sonst ist alles normal. Hatte dasselbe schon mal bei einem der ersten 2.6.26 Kernel, aber pacman -Syu hat das dann nach ca ner Woche behoben.

fs4000

Also ich kann im Moment nur vorschlagen, dass du ein Test-System frisch installierst und da mal testest. Ich hatte nie Probleme mit der Festplatte, ob mit oder ohne AHCI, und das seit
[2008-04-11 01:22] installed kernel26 (2.6.24.4-1)

Hier noch die Infos von der Festplatte, ich hab die 160 GB:

# hdparm -i /dev/sda                                 

/dev/sda:

 Model=SAMSUNG HM160HI                         , FwRev=HH100-08, SerialNo=S10UJD0PB37736      
 Config={ HardSect NotMFM HdSw>15uSec Fixed DTR>10Mbs }                                       
 RawCHS=16383/16/63, TrkSize=34902, SectSize=554, ECCbytes=4                                  
 BuffType=DualPortCache, BuffSize=8192kB, MaxMultSect=16, MultSect=?16?                       
 CurCHS=16383/16/63, CurSects=16514064, LBA=yes, LBAsects=312581808                           
 IORDY=on/off, tPIO={min:120,w/IORDY:120}, tDMA={min:120,rec:120}                             
 PIO modes:  pio0 pio1 pio2 pio3 pio4                                                         
 DMA modes:  mdma0 mdma1 mdma2                                                                
 UDMA modes: udma0 udma1 udma2 udma3 udma4 udma5 *udma6                                       
 AdvancedPM=yes: disabled (255) WriteCache=enabled                                            
 Drive conforms to: ATA/ATAPI-7 T13 1532D revision 0:  ATA/ATAPI-1,2,3,4,5,6,7                

 * signifies the current active mode

Solltest du noch irgendwas wissen wollen, kein Problem. Ich hab dich ja auch genügend mit dem fehlenden C3-State genervt. 😉

david86

Ich frag mich grade welche Systemeinstellung AHCI dermaßen ausbremsen kann, und im IDE Modus überhaubt keine Auswirkungen hat.

So nebenbei, hab rausgefunden, dass wenn ich erstaml nichts tue, und dann hdparm -t /dev/sda
starte, und dann wieder nichts tue, kommt es manchmal vor, dass ich buffered disk reads im zweistelligen Kilobyte bereich bekomme!

 hdparm -i /dev/sda 

/dev/sda:

 Model=TOSHIBA MK8046GSX                       , FwRev=LB311A  , SerialNo=           183NQ11ET
 Config={ Fixed }
 RawCHS=16383/16/63, TrkSize=0, SectSize=0, ECCbytes=0
 BuffType=unknown, BuffSize=8192kB, MaxMultSect=16, MultSect=?16?
 CurCHS=16383/16/63, CurSects=16514064, LBA=yes, LBAsects=156301488
 IORDY=on/off, tPIO={min:120,w/IORDY:120}, tDMA={min:120,rec:120}
 PIO modes:  pio0 pio1 pio2 pio3 pio4 
 DMA modes:  sdma0 sdma1 sdma2 mdma0 mdma1 mdma2 
 UDMA modes: udma0 udma1 udma2 udma3 udma4 *udma5 
 AdvancedPM=yes: unknown setting WriteCache=enabled
 Drive conforms to: Unspecified:  ATA/ATAPI-3,4,5,6,7

 * signifies the current active mode

jean-paul

Bekommst du irgendwelche Meldungen in dmesg ?

dmesg | grep ahci

dmesg | grep ata

Jean-Paul

david86

dmesg | grep ahci

ahci 0000:00:1f.2: version 3.0
ahci 0000:00:1f.2: PCI INT B -> GSI 19 (level, low) -> IRQ 19
ahci 0000:00:1f.2: AHCI 0001.0100 32 slots 3 ports 3 Gbps 0x7 impl SATA mode
ahci 0000:00:1f.2: flags: 64bit ncq sntf pm led clo pio slum part 
ahci 0000:00:1f.2: setting latency timer to 64
scsi0 : ahci
scsi1 : ahci
scsi2 : ahci

dmesg | grep ata

ACPI: SSDT 7F6D988C, 02C5 (r1 SataRe SataAhci     1000 INTL 20050624)
  #0 [0000000000 - 0000001000]   BIOS data page ==> [0000000000 - 0000001000]
PERCPU: Allocating 47648 bytes of per cpu data
Memory: 2049244k/2087744k available (2526k kernel code, 37596k reserved, 1038k data, 336k init)
ACPI: EC: GPE = 0x1c, I/O: command/status = 0x66, data = 0x62
libata version 3.00 loaded.
pata_acpi 0000:00:1f.1: PCI INT A -> GSI 19 (level, low) -> IRQ 19
pata_acpi 0000:00:1f.1: setting latency timer to 64
pata_acpi 0000:00:1f.1: PCI INT A disabled
ata1: SATA max UDMA/133 abar m2048@0xf8604000 port 0xf8604100 irq 761
ata2: SATA max UDMA/133 abar m2048@0xf8604000 port 0xf8604180 irq 761
ata3: SATA max UDMA/133 abar m2048@0xf8604000 port 0xf8604200 irq 761
ata1: SATA link up 3.0 Gbps (SStatus 123 SControl 300)
ata1.00: _GTF unexpected object type 0x1
ata1.00: ATA-8: TOSHIBA MK8046GSX, LB311A, max UDMA/100
ata1.00: 156301488 sectors, multi 16: LBA48 NCQ (depth 31/32)
ata1.00: _GTF unexpected object type 0x1
ata1.00: configured for UDMA/100
ata2: SATA link down (SStatus 0 SControl 300)
ata3: SATA link down (SStatus 0 SControl 300)
ata_piix 0000:00:1f.1: version 2.12
ata_piix 0000:00:1f.1: PCI INT A -> GSI 19 (level, low) -> IRQ 19
ata_piix 0000:00:1f.1: setting latency timer to 64
scsi3 : ata_piix
scsi4 : ata_piix
ata4: PATA max UDMA/100 cmd 0x1f0 ctl 0x3f6 bmdma 0x1810 irq 14
ata5: PATA max UDMA/100 cmd 0x170 ctl 0x376 bmdma 0x1818 irq 15
ata4.00: ATAPI: TSSTcorpCDW/DVD SN-M242D, SB01, max UDMA/33
ata4.00: configured for UDMA/33
EXT3-fs: mounted filesystem with writeback data mode.
EXT3-fs: mounted filesystem with writeback data mode.
ata1.00: configured for UDMA/100
ata1: EH complete
ata1.00: configured for UDMA/100
ata1: EH complete

fs4000

Nichts Auffälliges, bei mir steht nahezu dasselbe. Du kannst ja mal mit disablemodules=pata_acpi in der Kernel-Boot-Zeile in Grub starten. Vll. macht dir ja auch das pata_acpi Modul Probleme, das hatten wir erst: https://forum.archlinux.de/?page=Postings;id=20;thread=10519

GerBra

Schau dir mal diesen Thread an.

Ich vermute, daß bei dir ebenfalls das Modul pata_acpi "schuld" ist.
pata_acpi 0000:00:1f.1: PCI INT A -> GSI 19 (level, low) -> IRQ 19
während dein Modul für IDE das ata_piix ist:
ata_piix 0000:00:1f.1: PCI INT A -> GSI 19 (level, low) -> IRQ 19==
ata_piix 0000:00:1f.1: setting latency timer to 64
scsi3 : ata_piix
scsi4 : ata_piix

Teste also mal indem du pata_acpi wie beschrieben disablest.

fs4000

Hab eben auch mal ohne AHCI gebootet:

# hdparm -t /dev/sda

/dev/sda:
 Timing buffered disk reads:  192 MB in  3.01 seconds =  63.84 MB/sec

Also bin ich auch betroffen, aber bei weitem nicht so extrem, wie es bei dir ist. Ich würde doch glatt mal wieder vorschlagen einen Kernel-Bug zu melden.

EDIT: pata_acpi ist übrigens nicht schuld. Und was mich echt total wundert: Wenn ich das Laptop in Suspend-toDisk fahre, wird mir 60 MB/s angezeigt. Also irgendwas ist da faul.

EDIT2: Selbst der Kernel 2.6.25 vom ISO ist nicht ganz bugfrei. Mal bekomm ich 51 MB/sec und dann wieder 63 MB/sec, aber immerhin mehr als die 35 MB/sec mit aktuellem Kernel.

ata1.00: _GTF unexpected object type 0x1
ata1.00: _GTF unexpected object type 0x1

Das taucht beim 2.6.25 nicht auf.

EDIT3: Doch kein Kernel-Bug. Laptop Mode Tools sind bei mir schuld. Hab wohl was falsches eingestellt. Jetzt hab ich konstant 63 - 64 MB/sec.

EDIT4: read-ahead war schuld. Probier mal hdparm -a 256 /dev/sda.

[gelöscht]

ich weiss nicht ob es euch was nützt: mit AHCI ist ein Dell Vostro 1400

hdparm -tT /dev/sda

/dev/sda:
 Timing cached reads: 2364 MB in 2.00 seconds = 1183.11 MB/sec
 Timing buffered disk reads: 194 MB in 3.01 seconds = 64.48 MB/sec

 hdparm -i /dev/sda

/dev/sda:

 Model=SAMSUNG HM160HI                         , FwRev=HH100-11, SerialNo=      S14QJF0Q401884
 Config={ HardSect NotMFM HdSw>15uSec Fixed DTR>10Mbs }
 RawCHS=16383/16/63, TrkSize=34902, SectSize=554, ECCbytes=4
 BuffType=DualPortCache, BuffSize=8192kB, MaxMultSect=16, MultSect=?8?
 CurCHS=16383/16/63, CurSects=16514064, LBA=yes, LBAsects=312581808
 IORDY=on/off, tPIO={min:120,w/IORDY:120}, tDMA={min:120,rec:120}
 PIO modes:  pio0 pio1 pio2 pio3 pio4 
 DMA modes:  mdma0 mdma1 mdma2 
 UDMA modes: udma0 udma1 udma2 udma3 udma4 udma5 *udma6 
 AdvancedPM=yes: unknown setting WriteCache=enabled
 Drive conforms to: ATA/ATAPI-7 T13 1532D revision 0:  ATA/ATAPI-1,2,3,4,5,6,7

 * signifies the current active mode

david86

pata_acpi bringt tasächlich keine Besserung.

hdparm -a 256 /dev/sda aber auch nicht.
Allerdings kann readahead wirklich was damit zu tun zu haben, wenn ja, dann aber nicht alleine, denn

[root@myhost ~]# hdparm -a 0 /dev/sda

/dev/sda:
 setting fs readahead to 0
 readahead     =  0 (off)
[root@myhost ~]# hdparm -t /dev/sda

/dev/sda:
 Timing buffered disk reads:    2 MB in 12.60 seconds = 162.52 kB/sec
[root@myhost ~]# hdparm -a 2048 /dev/sda

/dev/sda:
 setting fs readahead to 2048
 readahead     = 2048 (on)
[root@myhost ~]# hdparm -t /dev/sda

/dev/sda:
 Timing buffered disk reads:   30 MB in  3.13 seconds =   9.57 MB/sec
[root@myhost ~]# hdparm -a 2049 /dev/sda
  -a: bad/missing filesystem-read-ahead value (0..2048)

Zum Vergleich das Gleiche im IDE Modus

[root@myhost ~]# hdparm -a 0 /dev/sda

/dev/sda:
 setting fs readahead to 0
 readahead     =  0 (off)
[root@myhost ~]# hdparm -t /dev/sda

/dev/sda:
 Timing buffered disk reads:   76 MB in  3.02 seconds =  25.14 MB/sec
[root@myhost ~]# hdparm -a 2048 /dev/sda

/dev/sda:
 setting fs readahead to 2048
 readahead     = 2048 (on)
[root@myhost ~]# hdparm -t /dev/sda

/dev/sda:
 Timing buffered disk reads:  142 MB in  3.01 seconds =  47.15 MB/sec
[root@myhost ~]# hdparm -a 2049 /dev/sda
  -a: bad/missing filesystem-read-ahead value (0..2048)

fs4000

Vll. gibt es irgendwelche Probleme im 3.0 Gbps Modus, meine Samsung Festplatte läuft nur mit 1.5 Gbps.
dmesg | grep ata

ACPI: SSDT 3F6D988C, 02C5 (r1 SataRe SataAhci     1000 INTL 20050624)
  #0 [0000000000 - 0000001000]   BIOS data page ==> [0000000000 - 0000001000]
PERCPU: Allocating 47648 bytes of per cpu data
Memory: 1016544k/1039168k available (2526k kernel code, 21644k reserved, 1038k data, 336k init)
ACPI: EC: GPE = 0x1c, I/O: command/status = 0x66, data = 0x62
libata version 3.00 loaded.
pata_acpi 0000:00:1f.1: PCI INT A -> GSI 19 (level, low) -> IRQ 19
pata_acpi 0000:00:1f.1: setting latency timer to 64
pata_acpi 0000:00:1f.1: PCI INT A disabled
ata_piix 0000:00:1f.1: version 2.12
ata_piix 0000:00:1f.1: PCI INT A -> GSI 19 (level, low) -> IRQ 19
ata_piix 0000:00:1f.1: setting latency timer to 64
scsi0 : ata_piix
scsi1 : ata_piix
ata1: PATA max UDMA/100 cmd 0x1f0 ctl 0x3f6 bmdma 0x1810 irq 14
ata2: PATA max UDMA/100 cmd 0x170 ctl 0x376 bmdma 0x1818 irq 15
ata1.00: ATAPI: TSSTcorp CDDVDW SN-S082H, SB00, max UDMA/33
ata1.00: configured for UDMA/33
ata3: SATA max UDMA/133 abar m2048@0xf8604000 port 0xf8604100 irq 761
ata4: SATA max UDMA/133 abar m2048@0xf8604000 port 0xf8604180 irq 761
ata5: SATA max UDMA/133 abar m2048@0xf8604000 port 0xf8604200 irq 761
ata3: SATA link up 1.5 Gbps (SStatus 113 SControl 300)
ata3.00: _GTF unexpected object type 0x1
ata3.00: ATA-8: SAMSUNG HM160HI, HH100-08, max UDMA7
ata3.00: 312581808 sectors, multi 16: LBA48 NCQ (depth 31/32)
ata3.00: _GTF unexpected object type 0x1
ata3.00: configured for UDMA/133
ata4: SATA link down (SStatus 0 SControl 300)
ata5: SATA link down (SStatus 0 SControl 300)
EXT3-fs: mounted filesystem with ordered data mode.

dmesg | grep ahci

ahci 0000:00:1f.2: version 3.0
ahci 0000:00:1f.2: PCI INT B -> GSI 19 (level, low) -> IRQ 19
ahci 0000:00:1f.2: AHCI 0001.0100 32 slots 3 ports 3 Gbps 0x7 impl SATA mode
ahci 0000:00:1f.2: flags: 64bit ncq sntf pm led clo pio slum part
ahci 0000:00:1f.2: setting latency timer to 64
scsi2 : ahci
scsi3 : ahci
scsi4 : ahci

Dass bei mir zuerst die IDE-Anschlüsse erkannt werden, sollte nicht das Problem sein, manchmal ist es auch andersrum.
Wenn du dich entschließt, einen Bug zu melden, kann ich dir gern auch sämtliche Debugausgaben als möglichst ähnliches, funktionierendes Beispiel geben. So sollte man das Problem ja relativ schnell eingrenzen können, wenn man jemanden hat, der mit der Materie vertraut ist. 😉

david86

Wenn ich mit

nohz=off

boote, dann läuft alles einwandfrei.
(Nur dass der Prozessor dann nicht mehr tiefer als C1 geht, was das ganze auf einem Notebook sinnlos macht).

Hab zwei Möglichkeiten:
1. AHCI aus -> Merhverbrauch unter 1Watt.
2. nohz=off -> Mehrverbrauch über 4 Watt! und über 300 Wakeups/s

Wenn das Problem was mit den C states zu tun hat, ist klar warum mein System (4-8 Wakeups/s) stärker betroffen ist als zb das von fs4000: Es VERschläft mehr!

fs4000

Probier mal Folgendes:

Update den Kernel auf kernel26 2.6.27.8-1
Enpacke das angehängte Archiv
Kopiere processor.ko nach

*
Das Ganze hat den Grund, dass seit Kernel 2.6.27 MWAIT auf IFL91-Boards deaktiviert ist, weil es ja Probleme mit den C-States gab. Das kannst du auch überprüfen:

$ dmesg | grep -i mwait
using mwait in idle threads.
ACPI: IFL91 board detected - disabling mwait for CPU C-states

In meinem Modul hab ich das Board aus der Liste rausgenommen, damit MWAIT wieder geht. Bei mir hat das dann zur Folge, dass ich nur noch max. C2 hab.

Sollte es dann gehen, müssen wir den Bug wohl nochmal aufrollen: http://bugzilla.kernel.org/show_bug.cgi?id=10807

david86

Ausgabe mit deinem Modul:

# dmesg | grep -i mwait
using mwait in idle threads.
Monitor-Mwait will be used to enter C-1 state
Monitor-Mwait will be used to enter C-2 state
Monitor-Mwait will be used to enter C-3 state

Ergebinis:
1. powertop zeig mir den C6 Modus wieder an.
2. Festplatte bleibt extrem träge im AHCI Modus.
3. Der XServer hängt sich jetzt nach längerer Inaktivität nicht mehr auf.

Ansonsten gilt:
Je aktiver ich in die Tasten haue oder die Maus bewege, desto schneller ist auch die Festplatte bei hdparm, und auch das System ist dann viel weniger träge.

fs4000

Also ist das ohne den nomwait-Patch besser für dich?
Mal zu den Wakeups: Wenn ich auf der Konsole bin, hab ich nur 2.5 Wapups und 400 ms Verweildauer im C3. Die Festplatte läuft aber perfekt mit nahezu 64 MB/sec.
Du kannst ja mal das probieren:
/etc/modprobe.conf

options processor max_cstate=3

david86

Hm,
also 3 ändert nichts genausowenig wie 2.

options processor max_cstate=1

Macht der Platte "feuer unterm Hintern", nur leider auch dem Prozessor.

Offtopic:
nomwait scheint bei deinem Prozessor besser zu sein. Bei meinem dafür mwait.
Wäre schön, wenn nicht das Board sondern der Prozessor auf die schwarze Liste kommt, oder wenigstens eine Auswahl möglich ist.

Ontopic:
Mir kommt das ganze so vor als ob irgendwas prüft ob das Gerät gerade bedient wird, und falls das für wenige Sekunden nicht der Fall ist, dann wird alles erst mal viel langsamer angegangen, bis das System zum Stillstand kommt. Nur um dann, so als ob der Chef grade zur Tür reinplatzt, wieder mit voller Geschwindigkeit weiter zu machen, bis er wieder weg ist.

fs4000

Ja, ist irgendwie dumm, dass man mwait nicht mehr erzwingen kann, wenn es gesperrt ist. Ich habs mal versucht (Kernelparameter idle=mwait), aber dann wars gar nichts mehr mit irgendeinem C-State. Ich frag mal, ob man das prozessorabhängig machen kann, ansonsten wärs mir auch lieber, das Board einfach von der Liste zu streichen. idle=nomwait tuts für mich auch.

Also das mit der Festplatte ist echt extrem seltsam. Hat denn das andere Laptop auch einen Core 2 Duo Prozessor. Sonst hängts ja wohl irgendwie mit diesem zusammen. Vll. kannst du dir ja mal das Image laden und damit testen: https://forum.archlinux.de/?page=Postings;id=20;thread=10697

david86

Ontopic:
Hab ein Bios Update auf 1.18 gemacht.
Hat leider auch keine Besserung gebracht.
Da das 1.19 noch beta ist lass ich da mal die Finger von.
Im IDE-Modus scheint ja alles einwandfrei zu laufen.
Darum geht meine Motivation das System neu aufzusetzen gegen null.
Ein workaround ist also vorhanden und ich betrachte die Sache damit als erledigt.

Offtopic:
Der andere Rechner hat einen T7700 (Merom). Dort zeigt powertop mit dem 2.6.27 Kernel den C4 Modus nicht mehr an. Dh für:
- Core 2 Duo der Penryn und Merom Serie ist mwait das Maß der Dinge.
- Für Pentium Dual Core ist nomwait zwingend erforderlich.
- Von Usern mit dem Standart Celeron (540???) hab ich bisher noch nichts gehört.

Mögliche Erklärung:
Bei der Biosprogrammierung wurde auf den möglichen Einbau von Core 2 Duo und Celeron eingagangen. Core 2 Duo weil defakto Standart für Notebook. Und Celeron weil Standart für low cost Notebook. An den Pentium Dualcore (in unserem Fall der T2330, aber sicher auch 2310 und 2370), der zwar einen Merom Kern hat, aber ganz böse kastriert wurde hat wohl keiner gedacht oder die Unterstützung wurde schlampig implementiert.

Ich hoffe, dass das IFL91 so schnell wie möglich von der schwarzen Liste runter kommt.
Ansonsten sollten, wenn man das blacklisten vom Prozessor abhängig machen kann auch alle anderen Modelle die mit dem BIOS für das IFL91 laufen berücksichtigt werden. Das wäre nur konsequent. Also zb (I)FL90, JHL92, ... (andere Modelle hab ich bisher nicht zu Gesicht bekommen, aber in den *txt Dateinen im Bios-Ziparchiv finden sich noch weitere). Darüber hinaus hat nicht nur Zepto das FL91 von Compal weiterverkauft, sondern auch Sager, Clevo, Orion, OCZ und andere.

Du könntest mir nicht zufällig den patch zukommen lassen, mit dem man mwait wieder freischaltet?
(mit 2.6.27.9 hilft dein Modul nicht mehr )
Hab den betrefenden Block in processor_core.c entfernt und dann versucht mit diff -u mir nen patch nach Vorbild des dmi_idle.patch zu basteln. Damit hängt sich makepkg dann aber leider auf.

Nächste Seite »