Hallo,
ich habe auf einem PC DEBIAN Etch installiert. Beim
Booten bleibt es an einer Stelle recht lang hängen
und scheint etwas zu suchen, bis es weitergeht. Hier
ein Auszug aus dem dmesg:
Hier bleibt das Booten hängen.
Beim Booten scheint während ein "Device 0000:02:00.0"
gesucht zu werden.
lspci sagt:
woraus ich aber das "Device 000:02:00.0" nicht ersehe. Ich bin mir aber
auch nicht sicher, ob es daran hakt. Immerhin zeigt lspci einige
"unknown devices", nur wie umgehe ich die? "Unknown" heißt ja nicht,
dass diese nicht gebraucht werden.
Ich habe in /boot/grub/menu.lst versuchsweise eingetragen:
was das Ausbremsen beim Booten wohl abstellte, nun aber auch den PC
am Ende nicht mehr selbständig abschalten ließ. Andere Kernel-Para-
meter hatten keine Auswirkung.
Im BIOS etwas abschalten, was ohnehin nicht da zu sein
scheint, halte ich für widersinnig. Ebenso kann lspci
nicht das anzeigen, was fehlt.
Das Kernel-Problem scheint bekannt zu sein:
http://www.mail-archive.com/linux-kernel@vger.kernel.org/msg244746.html
Ich finde hier aber keine Lösung meines Problems.
Wer kennt sich hier in den Tiefen des ACPI-Problems aus? Gibt des
vielleicht doch eine Möglichkeit, im /boot/grub/menu. lst etwas
einzustellen, das ACPI nicht ganz abschaltet, das Suchen nach
etwas nicht Vorhandenem aber verhindert.
Dank für einen Hinweis,
Werner.
ich habe auf einem PC DEBIAN Etch installiert. Beim
Booten bleibt es an einer Stelle recht lang hängen
und scheint etwas zu suchen, bis es weitergeht. Hier
ein Auszug aus dem dmesg:
Code:
...
ACPI: PCI Root Bridge [PCI0] (0000:00)
PCI: Probing PCI hardware (bus 00)
ACPI: Assume root bridge [\_SB_.PCI0] bus is 0
PCI: Ignoring BAR0-3 of IDE controller 0000:00:14.1
Code:
Boot video device is 0000:01:05.0
Device 0000:02:00.0 not responding
PCI: Transparent bridge - 0000:00:14.4
ACPI: PCI Interrupt Routing Table [\_SB_.PCI0._PRT]
ACPI: PCI Interrupt Link [LNKA] (IRQs 3 4 5 6 7 10 11) *0, disabled.
...
gesucht zu werden.
lspci sagt:
Code:
00:00.0 Host bridge: ATI Technologies Inc Unknown device 7930
00:01.0 PCI bridge: ATI Technologies Inc Unknown device 7932
00:06.0 PCI bridge: ATI Technologies Inc Unknown device 7936
00:12.0 SATA controller: ATI Technologies Inc SB600 Non-Raid-5 SATA
00:13.0 USB Controller: ATI Technologies Inc SB600 USB (OHCI0)
00:13.1 USB Controller: ATI Technologies Inc SB600 USB (OHCI1)
00:13.2 USB Controller: ATI Technologies Inc SB600 USB (OHCI2)
00:13.3 USB Controller: ATI Technologies Inc SB600 USB (OHCI3)
00:13.4 USB Controller: ATI Technologies Inc SB600 USB (OHCI4)
00:13.5 USB Controller: ATI Technologies Inc SB600 USB Controller (EHCI)
00:14.0 SMBus: ATI Technologies Inc SB600 SMBus (rev 13)
00:14.1 IDE interface: ATI Technologies Inc SB600 IDE
00:14.2 Audio device: ATI Technologies Inc SB600 Azalia
00:14.3 ISA bridge: ATI Technologies Inc SB600 PCI to LPC Bridge
00:14.4 PCI bridge: ATI Technologies Inc SB600 PCI to PCI Bridge
01:05.0 VGA compatible controller: ATI Technologies Inc Unknown device 7941
03:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd.
RTL-8139/8139C/8139C+ (rev 10)
auch nicht sicher, ob es daran hakt. Immerhin zeigt lspci einige
"unknown devices", nur wie umgehe ich die? "Unknown" heißt ja nicht,
dass diese nicht gebraucht werden.
Ich habe in /boot/grub/menu.lst versuchsweise eingetragen:
Code:
title Debian GNU/Linux, ohne ACPI
root (hd0,1)
kernel /boot/vmlinuz-2.6.18-5-686 root=/dev/sda2 ro acpi=off
initrd /boot/initrd.img-2.6.18-5-686
savedefault
am Ende nicht mehr selbständig abschalten ließ. Andere Kernel-Para-
meter hatten keine Auswirkung.
Im BIOS etwas abschalten, was ohnehin nicht da zu sein
scheint, halte ich für widersinnig. Ebenso kann lspci
nicht das anzeigen, was fehlt.
Das Kernel-Problem scheint bekannt zu sein:
http://www.mail-archive.com/linux-kernel@vger.kernel.org/msg244746.html
Ich finde hier aber keine Lösung meines Problems.
Wer kennt sich hier in den Tiefen des ACPI-Problems aus? Gibt des
vielleicht doch eine Möglichkeit, im /boot/grub/menu. lst etwas
einzustellen, das ACPI nicht ganz abschaltet, das Suchen nach
etwas nicht Vorhandenem aber verhindert.
Dank für einen Hinweis,
Werner.