https://bugzilla.novell.com/show_bug.cgi?id=436895
User herrmarder@googlemail.com added comment
https://bugzilla.novell.com/show_bug.cgi?id=436895#c25
--- Comment #25 from Tobias Lippert
Why do you need pci=noacpi? If I do not use pci=noacpi, the machine reboots during the boot procedure. I have it from a ACPI faq page.
Then, I booted with 1 acpi_debug_level=0x1f pci=noacpi This worked, but I could not insert the modules, because it rebooted. What means it worked? If it rebooted it did not work and it is the same as with booting without pci=noacpi?!? I can only get to a shell if I use that parameter. Else the system reboots during initialization.
I installed the current kernel and booted with 1 acpi_debug_level=0x1f Booting was only possible for runlevel "s", else the reboot problem was there. That's great. Now we can debug a bit there... Did this only work with processor, fan and thermal blacklisted? I very much expect that a kernel driver is causing the reboot. If processor, fan and thermal had been blacklisted, I'd try to load them manually. The first task now is to find out which driver/module causes the reboot. If I modprobe these modules, the system reboots. I cannot get any dmesg output with modprobe fan; modprobe processor; modprobe thermal; dmesg >/tmp/dmesg
Hmm, maybe this is related to something else. If pci=noacpi changes the reboot behaviour it could be related to something else. Can you separately try to boot (without additional boot params, only these): pcie_aspm=off noaer
There is no output in /tmp/dmesg If it's too early for dmesg you could try to do: cat /proc/kmsg >/tmp/kmsg the command will block and /proc/kmsg will be empty afterwards, but that should not matter.
-- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.