Klare Antwort zum AMD SB600 Bug gesucht.

angares · Beitrag von **angares** » 20.08.2008 23:31:53

Hallo zusammen,

der SB600 hat ja folgenden Hardware Bug:

Der SB600 hat hat einen Hardware-Bug, der den Betrieb im 64 Bit Mode verhindert, sofern der Controller auf Speicherbereiche ueber 4GB zugreift. Aufgrund des Hardware-Bugs werden Daten im hohen Speicherbreich über 4Gb nie direkt übertragen (DMA), sondern über den Zwischenschritt CPU /IOMMU).

Nun meine Frage: Tritt dieses Problem auch auf, wenn ich nur 2 GB Ram, aber 4 Festplatten â 1 TB verbaue? Es werden bis auf eine PCIe Steckkarte keine weiteren Komponenten auf das Board gebaut.

ODER

Wenn ich 4 GB Ram und die 4 x 1 TB HDDs einbaue und das aktuelle "Etch-and-a-half" nehme, welches ja den Kernel 2.6.24 mitbringt ("Seit Kernel 2.6.22-rc2 ist in Linux ein Patch drin, der den SB600 in den 32 Bit Mode zwingt") - ist die einzige Auswirkung, dass die Datenübertragungsrate in den Keller geht?

Ich muss das möglichst genau wissen, denn es wäre ein großer Aufwand, das Board nun wieder umzutauschen, ein neues zu suchen, etc.

Gruß,
Nils

rendegast · Beitrag von **rendegast** » 21.08.2008 00:54:13

Den Bug gibt es nicht, denn auf heise ist er nicht erwähnt.

Das "blacklisting" in ahci.c 2.6.25.16:

Code: Alles auswählen

...
...
	board_ahci		= 0,
	board_ahci_vt8251	= 1,
	board_ahci_ign_iferr	= 2,
	board_ahci_sb600	= 3,
	board_ahci_mv		= 4,
	board_ahci_sb700	= 5,

...
...
	/* board_ahci_sb600 */
	{
		AHCI_HFLAGS	(AHCI_HFLAG_IGN_SERR_INTERNAL |
				 AHCI_HFLAG_32BIT_ONLY |
				 AHCI_HFLAG_SECT255 | AHCI_HFLAG_NO_PMP),
		.flags		= AHCI_FLAG_COMMON,
		.link_flags	= AHCI_LFLAG_COMMON,
		.pio_mask	= 0x1f, /* pio0-4 */
		.udma_mask	= ATA_UDMA6,
		.port_ops	= &ahci_ops,
	},
	/* board_ahci_mv */
	{
		AHCI_HFLAGS	(AHCI_HFLAG_NO_NCQ | AHCI_HFLAG_NO_MSI |
				 AHCI_HFLAG_MV_PATA),
		.flags		= ATA_FLAG_SATA | ATA_FLAG_NO_LEGACY |
				  ATA_FLAG_MMIO | ATA_FLAG_PIO_DMA,
		.link_flags	= AHCI_LFLAG_COMMON,
		.pio_mask	= 0x1f, /* pio0-4 */
		.udma_mask	= ATA_UDMA6,
		.port_ops	= &ahci_ops,
	},
	/* board_ahci_sb700 */
	{
		AHCI_HFLAGS	(AHCI_HFLAG_IGN_SERR_INTERNAL |
				 AHCI_HFLAG_NO_PMP),
		.flags		= AHCI_FLAG_COMMON,
		.link_flags	= AHCI_LFLAG_COMMON,
		.pio_mask	= 0x1f, /* pio0-4 */
		.udma_mask	= ATA_UDMA6,
		.port_ops	= &ahci_ops,
	},
};

static const struct pci_device_id ahci_pci_tbl[] = {
	/* Intel */
	{ PCI_VDEVICE(INTEL, 0x2652), board_ahci }, /* ICH6 */
	{ PCI_VDEVICE(INTEL, 0x2653), board_ahci }, /* ICH6M */
	{ PCI_VDEVICE(INTEL, 0x27c1), board_ahci }, /* ICH7 */
	{ PCI_VDEVICE(INTEL, 0x27c5), board_ahci }, /* ICH7M */
	{ PCI_VDEVICE(INTEL, 0x27c3), board_ahci }, /* ICH7R */
	{ PCI_VDEVICE(AL, 0x5288), board_ahci_ign_iferr }, /* ULi M5288 */
	{ PCI_VDEVICE(INTEL, 0x2681), board_ahci }, /* ESB2 */
	{ PCI_VDEVICE(INTEL, 0x2682), board_ahci }, /* ESB2 */
	{ PCI_VDEVICE(INTEL, 0x2683), board_ahci }, /* ESB2 */
	{ PCI_VDEVICE(INTEL, 0x27c6), board_ahci }, /* ICH7-M DH */
	{ PCI_VDEVICE(INTEL, 0x2821), board_ahci }, /* ICH8 */
	{ PCI_VDEVICE(INTEL, 0x2822), board_ahci }, /* ICH8 */
	{ PCI_VDEVICE(INTEL, 0x2824), board_ahci }, /* ICH8 */
	{ PCI_VDEVICE(INTEL, 0x2829), board_ahci }, /* ICH8M */
	{ PCI_VDEVICE(INTEL, 0x282a), board_ahci }, /* ICH8M */
	{ PCI_VDEVICE(INTEL, 0x2922), board_ahci }, /* ICH9 */
	{ PCI_VDEVICE(INTEL, 0x2923), board_ahci }, /* ICH9 */
	{ PCI_VDEVICE(INTEL, 0x2924), board_ahci }, /* ICH9 */
	{ PCI_VDEVICE(INTEL, 0x2925), board_ahci }, /* ICH9 */
	{ PCI_VDEVICE(INTEL, 0x2927), board_ahci }, /* ICH9 */
	{ PCI_VDEVICE(INTEL, 0x2929), board_ahci }, /* ICH9M */
	{ PCI_VDEVICE(INTEL, 0x292a), board_ahci }, /* ICH9M */
	{ PCI_VDEVICE(INTEL, 0x292b), board_ahci }, /* ICH9M */
	{ PCI_VDEVICE(INTEL, 0x292c), board_ahci }, /* ICH9M */
	{ PCI_VDEVICE(INTEL, 0x292f), board_ahci }, /* ICH9M */
	{ PCI_VDEVICE(INTEL, 0x294d), board_ahci }, /* ICH9 */
	{ PCI_VDEVICE(INTEL, 0x294e), board_ahci }, /* ICH9M */
	{ PCI_VDEVICE(INTEL, 0x502a), board_ahci }, /* Tolapai */
	{ PCI_VDEVICE(INTEL, 0x502b), board_ahci }, /* Tolapai */
	{ PCI_VDEVICE(INTEL, 0x3a05), board_ahci }, /* ICH10 */
	{ PCI_VDEVICE(INTEL, 0x3a25), board_ahci }, /* ICH10 */

	/* JMicron 360/1/3/5/6, match class to avoid IDE function */
	{ PCI_VENDOR_ID_JMICRON, PCI_ANY_ID, PCI_ANY_ID, PCI_ANY_ID,
	  PCI_CLASS_STORAGE_SATA_AHCI, 0xffffff, board_ahci_ign_iferr },

	/* ATI */
	{ PCI_VDEVICE(ATI, 0x4380), board_ahci_sb600 }, /* ATI SB600 */
	{ PCI_VDEVICE(ATI, 0x4390), board_ahci_sb700 }, /* ATI SB700/800 */
	{ PCI_VDEVICE(ATI, 0x4391), board_ahci_sb700 }, /* ATI SB700/800 */
	{ PCI_VDEVICE(ATI, 0x4392), board_ahci_sb700 }, /* ATI SB700/800 */
	{ PCI_VDEVICE(ATI, 0x4393), board_ahci_sb700 }, /* ATI SB700/800 */
	{ PCI_VDEVICE(ATI, 0x4394), board_ahci_sb700 }, /* ATI SB700/800 */
	{ PCI_VDEVICE(ATI, 0x4395), board_ahci_sb700 }, /* ATI SB700/800 */

	/* VIA */
	{ PCI_VDEVICE(VIA, 0x3349), board_ahci_vt8251 }, /* VIA VT8251 */
	{ PCI_VDEVICE(VIA, 0x6287), board_ahci_vt8251 }, /* VIA VT8251 */

	/* NVIDIA */
	{ PCI_VDEVICE(NVIDIA, 0x044c), board_ahci },		/* MCP65 */
	{ PCI_VDEVICE(NVIDIA, 0x044d), board_ahci },		/* MCP65 */
	{ PCI_VDEVICE(NVIDIA, 0x044e), board_ahci },		/* MCP65 */
	{ PCI_VDEVICE(NVIDIA, 0x044f), board_ahci },		/* MCP65 */
	{ PCI_VDEVICE(NVIDIA, 0x045c), board_ahci },		/* MCP65 */
	{ PCI_VDEVICE(NVIDIA, 0x045d), board_ahci },		/* MCP65 */
	{ PCI_VDEVICE(NVIDIA, 0x045e), board_ahci },		/* MCP65 */
	{ PCI_VDEVICE(NVIDIA, 0x045f), board_ahci },		/* MCP65 */
	{ PCI_VDEVICE(NVIDIA, 0x0550), board_ahci },		/* MCP67 */
	{ PCI_VDEVICE(NVIDIA, 0x0551), board_ahci },		/* MCP67 */
	{ PCI_VDEVICE(NVIDIA, 0x0552), board_ahci },		/* MCP67 */
	{ PCI_VDEVICE(NVIDIA, 0x0553), board_ahci },		/* MCP67 */
	{ PCI_VDEVICE(NVIDIA, 0x0554), board_ahci },		/* MCP67 */
	{ PCI_VDEVICE(NVIDIA, 0x0555), board_ahci },		/* MCP67 */
	{ PCI_VDEVICE(NVIDIA, 0x0556), board_ahci },		/* MCP67 */
	{ PCI_VDEVICE(NVIDIA, 0x0557), board_ahci },		/* MCP67 */
	{ PCI_VDEVICE(NVIDIA, 0x0558), board_ahci },		/* MCP67 */
	{ PCI_VDEVICE(NVIDIA, 0x0559), board_ahci },		/* MCP67 */
	{ PCI_VDEVICE(NVIDIA, 0x055a), board_ahci },		/* MCP67 */
	{ PCI_VDEVICE(NVIDIA, 0x055b), board_ahci },		/* MCP67 */
	{ PCI_VDEVICE(NVIDIA, 0x07f0), board_ahci },		/* MCP73 */
	{ PCI_VDEVICE(NVIDIA, 0x07f1), board_ahci },		/* MCP73 */
	{ PCI_VDEVICE(NVIDIA, 0x07f2), board_ahci },		/* MCP73 */
	{ PCI_VDEVICE(NVIDIA, 0x07f3), board_ahci },		/* MCP73 */
	{ PCI_VDEVICE(NVIDIA, 0x07f4), board_ahci },		/* MCP73 */
	{ PCI_VDEVICE(NVIDIA, 0x07f5), board_ahci },		/* MCP73 */
	{ PCI_VDEVICE(NVIDIA, 0x07f6), board_ahci },		/* MCP73 */
	{ PCI_VDEVICE(NVIDIA, 0x07f7), board_ahci },		/* MCP73 */
	{ PCI_VDEVICE(NVIDIA, 0x07f8), board_ahci },		/* MCP73 */
	{ PCI_VDEVICE(NVIDIA, 0x07f9), board_ahci },		/* MCP73 */
	{ PCI_VDEVICE(NVIDIA, 0x07fa), board_ahci },		/* MCP73 */
	{ PCI_VDEVICE(NVIDIA, 0x07fb), board_ahci },		/* MCP73 */
	{ PCI_VDEVICE(NVIDIA, 0x0ad0), board_ahci },		/* MCP77 */
	{ PCI_VDEVICE(NVIDIA, 0x0ad1), board_ahci },		/* MCP77 */
	{ PCI_VDEVICE(NVIDIA, 0x0ad2), board_ahci },		/* MCP77 */
	{ PCI_VDEVICE(NVIDIA, 0x0ad3), board_ahci },		/* MCP77 */
	{ PCI_VDEVICE(NVIDIA, 0x0ad4), board_ahci },		/* MCP77 */
	{ PCI_VDEVICE(NVIDIA, 0x0ad5), board_ahci },		/* MCP77 */
	{ PCI_VDEVICE(NVIDIA, 0x0ad6), board_ahci },		/* MCP77 */
	{ PCI_VDEVICE(NVIDIA, 0x0ad7), board_ahci },		/* MCP77 */
	{ PCI_VDEVICE(NVIDIA, 0x0ad8), board_ahci },		/* MCP77 */
	{ PCI_VDEVICE(NVIDIA, 0x0ad9), board_ahci },		/* MCP77 */
	{ PCI_VDEVICE(NVIDIA, 0x0ada), board_ahci },		/* MCP77 */
	{ PCI_VDEVICE(NVIDIA, 0x0adb), board_ahci },		/* MCP77 */
	{ PCI_VDEVICE(NVIDIA, 0x0ab4), board_ahci },		/* MCP79 */
	{ PCI_VDEVICE(NVIDIA, 0x0ab5), board_ahci },		/* MCP79 */
	{ PCI_VDEVICE(NVIDIA, 0x0ab6), board_ahci },		/* MCP79 */
	{ PCI_VDEVICE(NVIDIA, 0x0ab7), board_ahci },		/* MCP79 */
	{ PCI_VDEVICE(NVIDIA, 0x0ab8), board_ahci },		/* MCP79 */
	{ PCI_VDEVICE(NVIDIA, 0x0ab9), board_ahci },		/* MCP79 */
	{ PCI_VDEVICE(NVIDIA, 0x0aba), board_ahci },		/* MCP79 */
	{ PCI_VDEVICE(NVIDIA, 0x0abb), board_ahci },		/* MCP79 */
	{ PCI_VDEVICE(NVIDIA, 0x0abc), board_ahci },		/* MCP79 */
	{ PCI_VDEVICE(NVIDIA, 0x0abd), board_ahci },		/* MCP79 */
	{ PCI_VDEVICE(NVIDIA, 0x0abe), board_ahci },		/* MCP79 */
	{ PCI_VDEVICE(NVIDIA, 0x0abf), board_ahci },		/* MCP79 */
	{ PCI_VDEVICE(NVIDIA, 0x0bc8), board_ahci },		/* MCP7B */
	{ PCI_VDEVICE(NVIDIA, 0x0bc9), board_ahci },		/* MCP7B */
	{ PCI_VDEVICE(NVIDIA, 0x0bca), board_ahci },		/* MCP7B */
	{ PCI_VDEVICE(NVIDIA, 0x0bcb), board_ahci },		/* MCP7B */
	{ PCI_VDEVICE(NVIDIA, 0x0bcc), board_ahci },		/* MCP7B */
	{ PCI_VDEVICE(NVIDIA, 0x0bcd), board_ahci },		/* MCP7B */
	{ PCI_VDEVICE(NVIDIA, 0x0bce), board_ahci },		/* MCP7B */
	{ PCI_VDEVICE(NVIDIA, 0x0bcf), board_ahci },		/* MCP7B */
	{ PCI_VDEVICE(NVIDIA, 0x0bd0), board_ahci },		/* MCP7B */
	{ PCI_VDEVICE(NVIDIA, 0x0bd1), board_ahci },		/* MCP7B */
	{ PCI_VDEVICE(NVIDIA, 0x0bd2), board_ahci },		/* MCP7B */
	{ PCI_VDEVICE(NVIDIA, 0x0bd3), board_ahci },		/* MCP7B */

	/* SiS */
	{ PCI_VDEVICE(SI, 0x1184), board_ahci }, /* SiS 966 */
	{ PCI_VDEVICE(SI, 0x1185), board_ahci }, /* SiS 966 */
	{ PCI_VDEVICE(SI, 0x0186), board_ahci }, /* SiS 968 */

	/* Marvell */
	{ PCI_VDEVICE(MARVELL, 0x6145), board_ahci_mv },	/* 6145 */
	{ PCI_VDEVICE(MARVELL, 0x6121), board_ahci_mv },	/* 6121 */

	/* Generic, PCI class code for AHCI */
	{ PCI_ANY_ID, PCI_ANY_ID, PCI_ANY_ID, PCI_ANY_ID,
	  PCI_CLASS_STORAGE_SATA_AHCI, 0xffffff, board_ahci },

	{ }	/* terminate list */
};

...
...

(Die board_ahci_* im Gegensatz zu den board_ahci haben workarounds für irgendwelche Macken)

Der SB600 hat also AHCI_HFLAG_32BIT_ONLY,
und soweit ich das erkenne, gibt es keine Prüfung auf die verbaute Speichermenge
(ob weniger oder mehr als 4GB).
Also wird auf den 64bit-Modus ganz verzichtet.

Bei weniger verbautem Ram müßtest Du dennoch den Kernel bearbeiten.
Oder reiche einen Patch ein, der auf die RAM-Menge prüft

Bleibt dann immer noch der AHCI_HFLAG_SECT255, den es für die anderen auch nicht gibt.
(Obwohl mensch das vermutlich nicht wahrnehmen wird. (?))

Soll ich jetzt böse sein und intel/intel oder auch amd/nvidia bevorzugen?

angares · Beitrag von **angares** » 21.08.2008 10:16:07

@ rendegast

rendegast hat geschrieben:Den Bug gibt es nicht, denn auf heise ist er nicht erwähnt.

pff *grins*

Vielen Dank für deine Ausführung, ich muss nur leider gestehen, dass ich es noch nicht ganz verstanden habe ^^
Was bedeutet das letzten Endes für mich?

Sind 4GB Ram sinnvoll zu nutzen? Kann ich meine 4 TB HDD Kapazität problemlos fahren? Bin ich ebenfalls von dem Problem betroffen, wenn ich eine HighPoint RocketRAID 2300 Karte benutzen würde für meine Sata Platten?

Ich hab gestern "Etch-and-a-half" in der amd64 Version installiert und 4x 250GB Samsung Platten an eine PCI Karte mit SiliconImage 0680 Chipsatz gehängt.
Darauf habe ich ein Raid 1 für die root-Partition und ein Raid 5 mit LVM für die Daten-Partition und swap erstellt. Damit gabs keine Probleme und die Geschwindigkeit ist (für 4 Festplatten an einer PCI Karte) annehmbar. Debian erkennt laut "cat /proc/meminfo" die 4GB Ram.

Kannst du mir vielleicht noch ein paar Erklärungen geben, was der Code bedeutet?

Grüße,
Nils

rendegast · Beitrag von **rendegast** » 21.08.2008 16:44:08

angares hat geschrieben:Sind 4GB Ram sinnvoll zu nutzen? Kann ich meine 4 TB HDD Kapazität problemlos fahren?

rendegast hat geschrieben:Der SB600 hat also AHCI_HFLAG_32BIT_ONLY,
und soweit ich das erkenne, gibt es keine Prüfung auf die verbaute Speichermenge
(ob weniger oder mehr als 4GB).
Also wird auf den 64bit-Modus ganz verzichtet.

Nicht eindeutig?
Egal wieviel RAM du verbaust, bei Verwendung des ahci-Treibers wird der SB600 wird im 32bit-Modus benutzt.
(in dieser Form. Anders, wenn du einen RAM-Test-Patch erstellst

)

Bin ich ebenfalls von dem Problem betroffen, wenn ich eine HighPoint RocketRAID 2300 Karte benutzen würde für meine Sata Platten?

Wenn die Karte einen SB600-Chipsatz benutzt. Tut sie das?

Code: Alles auswählen

lspci -nn

SiliconImage 0680

pci.ids :

Code: Alles auswählen

0095  Silicon Image, Inc. (Wrong ID)
        0680  Ultra ATA/133 IDE RAID CONTROLLER CARD
...
...
1095  Silicon Image, Inc.
        0240  Adaptec AAR-1210SA SATA HostRAID Controller
        0640  PCI0640
        0643  PCI0643
        0646  PCI0646
        0647  PCI0647
        0648  PCI0648
                1043 8025  CUBX motherboard
        0649  SiI 0649 Ultra ATA/100 PCI to ATA Host Controller
                0e11 005d  Integrated Ultra ATA-100 Dual Channel Controller
                0e11 007e  Integrated Ultra ATA-100 IDE RAID Controller
                101e 0649  AMI MegaRAID IDE 100 Controller
        0650  PBC0650A
        0670  USB0670
                1095 0670  USB0670
        0673  USB0673
        0680  PCI0680 Ultra ATA-133 Host Controller
                1095 3680  Winic W-680 (Silicon Image 680 based)
        3112  SiI 3112 [SATALink/SATARaid] Serial ATA Controller
                1095 3112  SiI 3112 SATALink Controller
                1095 6112  SiI 3112 SATARaid Controller
                9005 0250  SATAConnect 1205SA Host Controller
        3114  SiI 3114 [SATALink/SATARaid] Serial ATA Controller
                1095 3114  SiI 3114 SATALink Controller
                1095 6114  SiI 3114 SATARaid Controller
        3124  SiI 3124 PCI-X Serial ATA Controller
                1095 3124  SiI 3124 PCI-X Serial ATA Controller
        3132  SiI 3132 Serial ATA Raid II Controller
        3512  SiI 3512 [SATALink/SATARaid] Serial ATA Controller
                1095 3512  SiI 3512 SATALink Controller
                1095 6512  SiI 3512 SATARaid Controller
        3531  Sil 3531 [SATALink/SATARaid] Serial ATA Controller

'/sbin/modinfo ahci': Weder die "0095"-ID noch eine "1095"-ID taucht auf,
die Karte würde nicht mit dem ahci-Treiber benutzt.

Kannst du mir vielleicht noch ein paar Erklärungen geben, was der Code bedeutet?

Der erste snip-snap ("board_ahci = 0" ...) ist eine Art Index der workarounds.
"board_ahci = 0" bedeutet IMO keine Einschränkung, bzw. läßt sich so lesen.
Der zweite snip-snap fängt mit dem Ende der Auflistung der Besonderheiten der workarounds an: "sb600", "mv" und "sb700".
Danach kommt eine Zuordnung von Chipsätzen (über deren PCI-ID) zu den entsprechenden workarounds.
(Remark: es handelt sich hier um den Treiber aus vanilla-2.6.25.16, nicht um den aus debian)

angares · Beitrag von **angares** » 21.08.2008 19:07:21

Abermals Danke

Naja, mein Problem war eher: Was bedeutet die Verwendung des 32bit-Modus für mich. Da habe ich mich unverständlich ausgedrückt, entschuldige.
Heißt das dann, dass ein Teil des RAMs nicht genutzt wird? (Wie wenn man beispielsweise WinXP 32bit installiert, 4GB RAM verbaut hat aber mit diesem Betriebssystem nicht den ganzen RAM verwenden kann, sondern vielleicht nur 3,3GB).

Oder geht "einfach nur" die Geschwindigkeit der an den SB600 angeschloßenen Festplatten in den Keller, weil sie alle über den "Zwischenschritt CPU /IOMMU" anstatt über DMA (wie es auf "derjohn vs ATI/AMD sb600 Chipset" steht) angesteuert werden?

Und wenn eines von beiden der Fall ist, lässt sich das ganze Problem nicht einfach umgehen, indem man nur 2 GB RAM einbaut? (Oder macht es dann keinen Sinn mehr, ein 64bit Betriebssystem zu installieren?)

Naja, vielleicht kann man diese Fragen auch nicht so pauschal beantworten, ich weiß es leider nicht.

Viele Grüße,
Nils

rendegast · Beitrag von **rendegast** » 21.08.2008 21:43:04

Zur Antwort wieder snip-snaps aus ahci.c :
Die speziell SB600 betreffenden Flags:

Code: Alles auswählen

	HOST_CAP_64		= (1 << 31), /* PCI DAC (64-bit DMA) support */
--
	AHCI_HFLAG_IGN_SERR_INTERNAL	= (1 << 2), /* ignore SERR_INTERNAL */
	AHCI_HFLAG_32BIT_ONLY		= (1 << 3), /* force 32bit */
..
	AHCI_HFLAG_NO_PMP		= (1 << 6), /* no PMP */
..
	AHCI_HFLAG_SECT255		= (1 << 8), /* max 255 sectors */

Und hier wird das Set für den SB600 zusammengestellt:

Code: Alles auswählen

	/* board_ahci_sb600 */
	{
		AHCI_HFLAGS	(AHCI_HFLAG_IGN_SERR_INTERNAL |
				 AHCI_HFLAG_32BIT_ONLY |
				 AHCI_HFLAG_SECT255 | AHCI_HFLAG_NO_PMP),
		.flags		= AHCI_FLAG_COMMON,
		.link_flags	= AHCI_LFLAG_COMMON,
		.pio_mask	= 0x1f, /* pio0-4 */
		.udma_mask	= ATA_UDMA6,

Der AHCI_HFLAG_32BIT_ONLY sorgt dann hier dafür, daß HOST_CAP_64 nicht mehr berücksichtigt wird:
(nur im Fall des SB600, alle anderen scheinen das hinzukriegen)

Code: Alles auswählen

	/* some chips have errata preventing 64bit use */
	if ((cap & HOST_CAP_64) && (hpriv->flags & AHCI_HFLAG_32BIT_ONLY)) {
		dev_printk(KERN_INFO, &pdev->dev,
			   "controller can't do 64bit DMA, forcing 32bit\n");
		cap &= ~HOST_CAP_64;
	}

http://en.wikipedia.org/wiki/Advanced_H ... _Interface :

AHCI controller on AMD/ATI SB600 HBA can't do 64-bit DMA transfers. 64-bit addressing is optional in AHCI 1.1 and the chip claims it can do them, but in reality it can't, so it is disabled. After that it will be forced to do 32-bit DMA transfers. Thus DMA transfers will occur in the lower 4 GiB region of the memory, and bounce buffers must be used sometimes if there is more than 4 GiB of RAM.

Demnach hat es Performance-Auswirkungen bei Verwendung von mehr als 4GB RAM.
Frage ist aber, ob das im Realbetrieb am Ende nicht doch nur ein paar Prozent vom Durchsatz sind?
Oder einfach nur höhere CPU-Last?
Schlimmer dürfte bei weitem sein, wenn den virtuellen Maschinen der RAM ausgeht und swapping einsetzt.

-----------------------------------------------------------------------------------------------------------------------------------
Hier wären die "Auswirkungen" durch HOST_CAP_64 :

Code: Alles auswählen

	/* set FIS registers */
	if (hpriv->cap & HOST_CAP_64)
		writel((pp->cmd_slot_dma >> 16) >> 16,
		       port_mmio + PORT_LST_ADDR_HI);
	writel(pp->cmd_slot_dma & 0xffffffff, port_mmio + PORT_LST_ADDR);

	if (hpriv->cap & HOST_CAP_64)
		writel((pp->rx_fis_dma >> 16) >> 16,
		       port_mmio + PORT_FIS_ADDR_HI);
	writel(pp->rx_fis_dma & 0xffffffff, port_mmio + PORT_FIS_ADDR);

(ich kann zwar lesen, aber was heißt das?)

Seit wann im Kernel:

AHCI_HFLAG_32BIT_ONLY 2.6.22-rc1-git7 hat geschrieben:Re: [PATCH] ahci: disable 64bit dma on sb600
Jeff Garzik
Mon, 21 May 2007 17:00:39 -0700
...
applied

Steve_McGarrett · Beitrag von **Steve_McGarrett** » 23.08.2008 12:08:57

Hallo,

ich klinke mich hier mal ein, da mein Board auch eine SB600 verwendet.

Ich habe noch nicht genau verstanden, was die Auswirkungen dieses Bugs sind. Ich habe 8GB RAM verbaut und AHCI im BIOS aktiviert.

Heißt das jetzt, dass der Rechner abstürzt, wenn mehr als 4GB RAM adressiert werden sollen?
Oder habe ich einfach nur (leichte?) performance Einbußen?
Falls ja, habe ich die dann immer oder nur wenn auf Speicher >4GB zugegriffen wird?
Sollte ich AHCI besser deaktivieren?

Danke für eure Antworten.

rendegast · Beitrag von **rendegast** » 24.08.2008 01:48:53

@Steve_McGarrett

, and bounce buffers must be used sometimes if there is more than 4 GiB of RAM.

Ich lese das so, daß der Bug darin besteht, daß der Chipsatz beim Aushandeln vorgibt, 64bit-DMA zu beherrschen,
und durch die Beschränkung des ahci-Treibers auf 32bit-DMA bei Zugriff auf >4GB treten Performance-Probleme auf, die durch die "bounce buffers" kommen.

Das hieße dann letztendlich:
Bei Verwendung von <=4GB keine Auswirkungen durch das AHCI_HFLAG_32BIT_ONLY.

-----------------------------------

Steve_McGarrett hat geschrieben:Sollte ich AHCI besser deaktivieren?

http://expertester.wordpress.com/2008/0 ... advantage/
(nvidia, intel)
Die Unterschiede sind nicht so der Brüller.
Der Vorteil liegt wohl großteils auf der gleichmäßigeren Belastung durch NCQ, aber dafür hat linux ja sowieso die I/O-Scheduler:
http://chemnitzer.linux-tage.de/2008/vo ... _final.pdf
(S.34 Scheduler, S.48 NCQ):
Entweder anti/cfq oder NCQ+noop/dead.
Bei NCQ + RAID1/SW-RAID1: anti/cfq für RAID1, noop/dead für SW-RAID1
Die Kombination macht also den (für mich nicht allzu großen) Unterschied.

-----------------------------------
Kristallkugel:
Daß bei heise nix steht ("Das Ende der Welt ist nahe: SB600 beherrscht im ahci-Modus kein 64bit-DMA!"),
liegt wohl daran, daß bei Windows (XP) kein generischer ahci-Treiber vorkommt, der so etwas hätte berücksichtigen müssen (Bei Vista wohl stillschweigend eingebaut).
Die Treiber kommen gerätespezifisch und hatten ab release den workaround eingebaut.
Also hat niemand was gemerkt.

debianforum.de

Klare Antwort zum AMD SB600 Bug gesucht.

Klare Antwort zum AMD SB600 Bug gesucht.

Re: Klare Antwort zum AMD SB600 Bug gesucht.

Re: Klare Antwort zum AMD SB600 Bug gesucht.

Re: Klare Antwort zum AMD SB600 Bug gesucht.

Re: Klare Antwort zum AMD SB600 Bug gesucht.

Re: Klare Antwort zum AMD SB600 Bug gesucht.

Re: Klare Antwort zum AMD SB600 Bug gesucht.

Re: Klare Antwort zum AMD SB600 Bug gesucht.