Bug 101519

Can you post the output of 'dmidecode' and 'acpidmp'?

*** Bug 101520 has been marked as a duplicate of this bug. ***

Created attachment 93395 [details]
Output of acpidmp

Created attachment 93396 [details]
Output of dmidecode

I tweaked the boot scripts for allowing me to load USB modules manually
(obviously in normal boot not on install) and found that I could load usbcore
but that loading usb-ohci locked the machine (no response to keyboard).

A quick and dirty fix for the problem could be to disable acpi if nforce2 is
detected.  Could be done either through a patch or trough the post-install
scripts forcing acpi=off in the bootloader conf.

Does the ISO install kernel boot if you use pci=noacpi ? 
Can you attach /proc/interrupts from the working system & lspci output? 
 
 

Created attachment 93413 [details]
The /proc/interrupts after booting with pci=noacpi

Created attachment 93414 [details]
Output of lspci -vv

Booting the install kernel without "apm=off" but with "pci=noacpi" no longer
freezes on "loading installer".

Booting the normal kernel without "apm=off" but with "pci=noacpi" no longer
freezes when loading the USB modules.   

ACPI interrupt is active but quiesence in the pci=noacpi case, at least that much is 
normal. 
 
curious that /proc/interrupts shows the 3 USB controllers, but doesn't show the 
integrated Ethernet or Audio seen by lspci -- are they disabled? 
 
can you attach dmesg -s40000 output for the default acpi, as well as pci=noacpi 
cases?  You'll need to use your trick of disabling the usb-ohci module load for the acpi 
case so you can get the system up. 
 
What USB devices are attached to the system -- does it boot if you remove them? 
 
 
 
 
 
 

Theree is one peripheral connected to the USB port: a Logitec optic mouse. 
Removing it doesn't bring changes: it still doesn't boot.

For the integrated ethernet and audio the drivers haven't been probably loaded.
It is certain for the ethernet since the driver is proprietary and I want to
keep the kernel in pristine state as long as I am in bug reporting.  I am not 
sure about the integrated audio but I know it works.

BTW do you object if I install the redhat 2.6 kernel to see how acpi works on
my box?  It requires some changes to user space tools so perhaps this could
cause trouble for debugging present problem.

I will post the dmesg files in couple hours.

Created attachment 93437 [details]
dmesg after booting with pci=noacpi

I loaded the sound module manually so you will find messages about it in the
submitted file.  After that the audio device showed up at interrupt 12.

Created attachment 93438 [details]
dmesg after boot without disabling acpi (and USB disabled)

Due to a problem with kudzu I had to boot single user.	I didn't load sound
this time.  But I manually started acpid.

Created attachment 93837 [details]
ACPI VT86/Award PCI interrupt patch. 


This patch has fixed the ACPI interrupt problem for similar systems.
Please try applying it to a copy of your Severn BETA1 kernel to
see if works for you too:

~/src/linux-2.4.21-20.1.2024.2.1.nptl> patch -Np1 < ./pci_link-severn.patch
patching file arch/i386/kernel/io_apic.c
patching file arch/i386/kernel/mpparse.c
patching file drivers/acpi/pci_irq.c
patching file drivers/acpi/pci_link.c
patching file include/acpi/acpi_drivers.h

The patch doesn't compile.  I tried by compiling from the tree set by the
kernel-source (after copying the kernel-athlon config file, make menuconfig
(without modification), make dep, make clean, make bziMage, make modules: it
chokes during make modules in the acpi part), I thought it would be better to
use the SRPM in order to get the exact same options you had used so I hacked
the SRPM, rpmbuild --target=athlon myspecfile and goty the same results (ie
failing to compile an acpi file during make modules)

Did the patch apply cleanly to your Severn Beta1 source tree? 
Does the tree build w/ this config file _before_ the patch is applied? 
If you can attach your .config and the build output, i'll try it here. 
 

It applied cleanly.  I discovered that the RPM build was crashing while
compiling the SMP kernel so I disabled it and the UP kernel built nicely.

This solved the problem (ie the kernel no longer freezes when loading USB
modules) but... the kernel freezes when kudzu tries to probe
the hardware.  I rebooted in runlevel 2 (where kudzu is not started) and started
it by hand: it froze again and since I was unable to switch consoles or
CTRL-ALT-DEL I had the proof it was a kernel problem, not a kudzu one.

Then I tried rebooting with pci=noacpi and this time it worked, just like the
previous kernel.

Can you re-test against Fedora Core 1 or FC2 (with acpi=on)?

Fedora Core 1 worked with acpi=on.  kernel is not the vanilla one but
an  official bugfix.  Don't have number here.

Thanks for verifying that acpi=on works.
closing.

-Len