
Hallo ! Ich habe am S-ATA-Anschluß eines Asus A7N8X-E eine (1) S-ATA-Platte hängen. Von dieser einzelnen Platte soll Suse 9.1 booten. Nun habe ich das Problem, das dies zwar funktioniert, aber das der Treiber (Modul SATA-SIL) beim booten anscheinend laaange auf die zweite Platte wartet bzw. danach sucht, bis nach einem Timeout normal gebootet wird. Kann man dieses Verhalten, z.B. durch einen Modul-Parameter, irgendwie abstellen ? Das BIOS des Controlles teilt meine feste Überzeugung, das da nut eine Platte eingebaut ist - daher kann der Treiber also seine Weisheit nicht bekommen haben - er sucht wohl aus eigenem Antrieb nach einer zweiten Platte. Diese Latenz beim Booten ist nun aber soch etwas nervig... mfg Th. Bruns

Am Sonntag, 18. Juli 2004 23:51 schrieb Thomas Bruns:
Hallo !
Ich habe am S-ATA-Anschluß eines Asus A7N8X-E eine (1) S-ATA-Platte hängen. Von dieser einzelnen Platte soll Suse 9.1 booten. Nun habe ich das Problem, das dies zwar funktioniert, aber das der Treiber (Modul SATA-SIL) beim booten anscheinend laaange auf die zweite Platte wartet bzw. danach sucht, bis nach einem Timeout normal gebootet wird.
Der Treiber , der zu lange wartet, ist nicht SATA_SIL sondern SIIMAGE. Wenn, du dafür sorgst, das wirklich SATA_SIL benutzt wird, indem du SIIMAGE nicht fest in den Kernel einbaust (CONFIG_BLK_DEV_SIIMAGE=m statt CONFIG_BLK_DEV_SIIMAGE=y im .config des Kernels ), verschwindet das Problem. Achtung, das hat aber zur Folge, das deine Platte von einer IDE-PLATTE zur SCSI-Platte mutiert. D.h. du must dafür sorgen, das in der initrd neben SATA_SIL auch sd_mod und scsi_mod geladen wird und du must /etc/fstab und die Konfiguration des Bootloaders anpassen.

Markus Kossmann wrote:
Der Treiber , der zu lange wartet, ist nicht SATA_SIL sondern SIIMAGE. Wenn, du dafür sorgst, das wirklich SATA_SIL benutzt wird, indem du SIIMAGE nicht fest in den Kernel einbaust (CONFIG_BLK_DEV_SIIMAGE=m statt CONFIG_BLK_DEV_SIIMAGE=y im .config des Kernels ), verschwindet das Problem.
Es hat zwar etwas gedauert, aber genau so habe ich das Problem jetzt lösen können. Nun läuft es besser. Natürlich benötigt die o.g. Lösung jeweils einen selbstgebauten Kernel - das ist im Prinzip OK, aber mir stellt sich die Frage ob ich auch bei einer Neuinstallation die Möglichkeit habe eben bei der Installation den einen anstelle das anderen Treibers auszuwählen ?!? mfg Th. Bruns

Hi Thomas, bei 2.4er Linux funktionierte bei mir der hdg=none Bootparameter (Abit NF7-S mit einer Sata Platte). Gruss Michael

Hallo, Am Mon, 19 Jul 2004, Michael Born schrieb:
bei 2.4er Linux funktionierte bei mir der hdg=none Bootparameter (Abit NF7-S mit einer Sata Platte).
Geht auch mit 2.6: ==== Documentation/ide.txt ==== "hdx=noprobe" : drive may be present, but do not probe for it "hdx=none" : drive is NOT present, ignore cmos and do not probe ==== -dnh -- Textverarbeitungsprogramme haben gegenueber der Gesellschaft einen Vorteil: Man kann den rechten Rand einstellen.
participants (4)
-
David Haller
-
Markus Kossmann
-
Michael Born
-
Thomas Bruns