Bug 117560

Created attachment 50208 [details]
Hardware information log file.

Saved via YaST2 Hardware Information module (YaST Control Center > Hardware >
Hardware Information).

"Could not find SuSE Linux installation" - looks like YaST didn't even started -
Steffen, any idea?

Sounds like a hardware or kernel problem to me.  
 
BTW, at least in the first case you can switch to console 4 _before_ it 
locks up and watch the kernel messages. 
  
Assigning to our notebook people.  

Huh, this is hard to debug remotely.

Please switch to console 4 early and watch the messages. What are the last lines?
Do that in bothe cases normal and safe mode. (Can you attach a serial console?)

Did it boot with Beta3 CDs?

What do you mean with "clean install button"?

I finally got the final DVD version to fail, and I was able to look at screen
four to find the following errors:

ACPI-0325: *** Warning: No handler for Region [ERAM] (dfff6800) [EmbeddedControl]
ACPI-0287: *** Error: Region EmbeddedControl(3) has no handler
ACPI-1174: *** Method execution failed [\_PR_.CPU0._PPC] (Node dffea480),
AE_NOT_EXIST
ACPI-0132: *** Warning: Error evaluating _PPC

At this point SuSE 10 is unable to access the DVD drive. I believe this is the
same problem that plagued SuSE 10 RC1 with regular CDROM, but I can't be sure
because it locked up sooner and more completely.

Did you try the "failsafe" boot option ?! 

Cc'ing the acpi wizard... 

Who are you talking about?!?

Hopefully the machine is booting with acpi=off?
Also try to boot pci=noacpi.
The DSDT exported by BIOS is probably totally broken (warning messages). However
these messages above should not be fatal. I expect something is also going wrong
when ACPI processes devices and tries to assign ressources (just a guess), so
pci=noacpi could help.

You should first try to install with pci=noacpi.
If this works attach dmesg and acpidmp, please.

If you can boot/install only with acpi=off, then:
Edit /etc/sysconfig/kernel and remove the modules processor thermal fan from
INITRD_MODULES="..." variable. Now call mkinitrd.
Also set ACPI_MODULES="" to ACPI_MODULES="NONE" in /etc/sysconfig/powersave/common.
Try to reboot without acpi=off, but with pci=noacpi (maybe it's even possible
without?) and attach dmesg and acpidmp.

If both is not working/installing we have a problem (probably should try to get
the system up with an older kernel then, was there already a Linux running on
this machine?) ...

In answer to Klaus Kaempf: Booting in failsafe did allow the system to boot into
the graphical installer but resulted in a complete lockup of the system after
packages were selected and the installation button was clicked.

Yes, SuSE 10 Beta 3 is currently running on this machine. The Beta 3
installation went very smooth with no problems at all. And I have built and run
kernels up to 2.6.13.2 on the machine as well under Beta 3. 

So it's possbily ec_burst mode, could you try with ec_burst=0 boot param.
Can you attach whole dmesg and acpidmp output of booting distribution, please.

While on holiday Monday, October 11 (Columbus Day, the American celebration of a
European navigation error) I managed to install SuSE 10 final with ACPI=off.
After installation the system booted, and with acpi=off as a boot option in
grub. Enabling ACPI causes the notebook to fail. I've attached the output from
dmesg and acpidmp.

Created attachment 53649 [details]
Output of acpidmp from system booted with ACPI=off

Created attachment 53650 [details]
Output of dmesg from system booted with ACPI=off

pci=noacpi does not work instead of acpi=off?

If you can boot with pci=noacpi this kernel (no idea whether it is already
available as YOU update) you should also be able to boot without pci=noacpi with
this kernel:
ftp.suse.com/pub/people/trenn/10_0_kernel_reboot_fix/kernel-default-2.6.13-2.i586.rpm

If you cannot boot with acpi=noacpi, please stay tuned,  I try to look into
acpidump output ASAP.

Yes, the systen with the stock kernel boots with pci=noacpi. I just rebooted the
system, and the kernel is now behaving much better with regards to power
management. The notebook fan is now off (it was on constantly before the reboot)
and only comes on when I'm pushing the notebook.

Thank you.

kernel version:
Linux version 2.6.13-15-default (geeko@buildhost) (gcc version 4.0.2 20050901
(prerelease) (SUSE Linux)) #1 Tue Sep 13 14:56:15 UTC 2005

So with the next YOU update kernel or the one I stated above, you possibly could
also boot without pci=noacpi (what should not make much a difference in
functionality for you). It might be needed if some device gets a wrong irq
assigned, but this shouldn't be the case.

Do you still get these ACPI errors you stated in #5?
I think no, as if your system runs cooler now, you probably have cpufreq running.
And error #5 should prevent the system of cpufreq running correctly.
If still see these errors, please provide dmesg with pci=noacpi again.
If no, could we close this one?

I can't tell if I still get the ACPI messages in comment #5. I am going to
attach the latest dmesg output for you to look at. And yes, it looks like the
thermal stuff is running. Since there seems to be nothing else, I'll let you
decide after reviewing the latest dmesg if this issue needs to be closed.

Created attachment 53906 [details]
Latest dmesg with pci=noacpi

This bug looks like it belongs to the acpi wizard himself. Have fun ;)

This is really strange..., you should still get the ACPI errors from comment #5
if the powersave daemon tries to activate cpufreq. Have enabled cpufreq
(speedstep/powernow) in BIOS now or deactivated cpufreq in
/etc/sysconfig/powersave/cpufreq? That would make sense.

If you encounter IRQ problems with a device you should try as mentioned in dmesg:
PCI: No IRQ known for interrupt pin A of device 0000:00:01.0. Please try using
pci=biosirq.

With the next YOU update kernel you possibly are also able to boot without
acpi=noacpi, then the above IRQ message should also vanish in dmesg.

Can we close this one?

Yes, close it. If there are still issues after the next YOU kernel update then I will open another bug report. Right now the system is working fine. It's my primary development system and I do not have too much time to reboot and retest in the middle of an ongoing effort. Everything is working right now: video (1680x1050 hardware accelerated via the ATI driver), wired and wireless, full USB, and the CPU. I appreciate everyone's help and comments, but I have a looming deadline. I'll be free again in November to look at this final issue. But I am not going to mess with a working stable system at this particular moment.

Thanks for your help.