Bug 159078

Created attachment 114945 [details]
lspci -vv from the i386 installation

It appears that the two errors are from something on the PCI-Express bus and
the video card itself.

Created attachment 114946 [details]
Output of dmesg

Created attachment 114953 [details]
Logs from Xorg startup via "startx"

I booted up the system at run level 3 and executed "startx" as root.

I attempted to load 2.6.12-rc5 with the git8 patch.  There was no change to the
errors.

I also opened a ticket with ASUS in reference to the mobo.  They seem to be open
to trying to fix the issue.

This is getting some attention upstream in the last few days. See
http://lkml.org/lkml/2005/6/3/203 for details

Should I post a "me-too" to this thread from Comment #5?  I feel a bit anxious
about such a posting as I tend to be a bit light on specifics.

It looks like there is some attention, but no testers for possible fixes.

Mass update of -test bugs to update version to fc4.
(Please retest on final release, and report results if you have not already done
so).

Thanks.

Already retested.  Same failures are noted and there is no change to the output
of the attachments in either the i386 or x86_64 version.

Created attachment 116108 [details]
output of dmidecode after BIOS update(2.6.12-git10)

Created attachment 116109 [details]
Updated output of dmesg after BIOS update(2.6.12-git10)

Created attachment 116110 [details]
Outpue of lsusb after BIOS update(2.6.12-git10)

Created attachment 116111 [details]
Output of lspci after BIOS update(2.6.12-git10)

Created attachment 116112 [details]
Output of lshw after BIOS update(2.6.12-git10)

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

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

I receieved an excellent analysis of my dmesg output from a gentleman at Nvidia
who pointed the finger squarely at the BIOS from ASUS(whose Tech Support is
ridculously bad btw).

I have attempted to speak with anyone at their Tech Support to address the
issues in the BIOS and have failed miserably(ASUS TKT#44951 in case someome else
is watching).

Here is what Mr. Currid at Nvidia pointed out to me any chance some of the
RedHat Kernel devs can analyze it and comment?

Sean

I went back through the LKML archives - is the dmesg dump you posted on
6/17 from the Asus K8N-DL? I'm assuming it is. 

There are several issues immediately apparent with the BIOS.

It has an ACPI interrupt override for IRQ0 to Global System Interrupt 2
(GSI 2) that is incorrect -

ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 2 dfl dfl)

and is the root cause of the later warnings to do with the timer:

..MP-BIOS bug: 8254 timer not connected to IO-APIC
...trying to set up timer (IRQ0) through the 8259A ...  failed.
timer doesn't work through the IO-APIC - disabling NMI Watchdog!
...trying to set up timer as Virtual Wire IRQ...Uhhuh. NMI received for
unknown reason 3d.
Dazed and confused, but trying to continue
Do you have a strange power saving mode enabled?
 failed.
...trying to set up timer as ExtINT IRQ... works.

The Linux kernel (2.6.9 onwards) contains code to specifically detect
this interrupt redirect on NVIDIA hardware, and ignore it, but for some
reason it isn't kicking in on your setup. Not sure why that is.

Also, the ACPI PCI Interrupt Routing Table (PRT) contains references to
entries that don't exist elsewhere in the ACPI tables:

ACPI: Subsystem revision 20050309
    ACPI-0352: *** Error: Looking up [\_SB_.PCI0.LNK0] in namespace,
AE_NOT_FOUND
search_node ffff81013ffca240 start_node ffff81013ffca240 return_node
0000000000000000
    ACPI-0352: *** Error: Looking up [\_SB_.PCI0.APC0] in namespace,
AE_NOT_FOUND
search_node ffff81013ffca140 start_node ffff81013ffca140 return_node
0000000000000000

Linux unfortunately appears to give up on parsing the PRT when this
happens, unlike Windows, which will parse the table despite these
errors. Without parsing the PRT, Linux cannot know how to route
interrupts for various PCI devices, which results in the later errors:

...
ACPI: PCI Interrupt 0000:02:00.0[A]: no GSI - using IRQ 3
...
ACPI: PCI Interrupt 0000:00:04.0[A]: no GSI - using IRQ 11

I'm guessing that your Broadcom networking, AC97 sound and USB 1.1
controller may not be working correctly as a result of this.

The Linux kernel could be modified to continue parsing PRTs when errors
are encountered. However, it is the BIOS that is at fault here.

Andy
--
Andy Currid, NVIDIA Corporation

[This comment has been added as a mass update for all FC4 kernel bugs.
 If you have migrated this bug from an FC3 bug today, ignore this comment.]

Please retest your problem with todays 2.6.12-1.1398_FC4 update.

If your problem involved being unable to boot, or some hardware not being
detected correctly, please make sure your /etc/modprobe.conf is correct *BEFORE*
installing any kernel updates.
If in doubt, you can recreate this file using..

mv /etc/sysconfig/hwconf /etc/sysconfig/hwconf.bak
mv /etc/modprobe.conf /etc/modprobe.conf.bak
kudzu


Thank you.

Since this is an issue with ACPI and the defective System Bios of this ASUS
Motherboard, this is still an issue.

I have disabled ACPI at this time to get the system working.  If you feel this
is not an issue with FC, feel free to close this bugzilla report.  

I would like to keep it open, just so I can document changes made by ASUS (if
they ever decide to do anything).

Downgrading to low priority as there doesn't appear to be anything that the
kernel can do for an ACPI non-compliant BIOS.

Keeping it open so other users can more easily find this issue is fine.  Just as
long as nobody expects the kernel to fix it when it is Asus' problem.

The 'keep parsing the table in face of errors' sounds like something that would
be good to fix, especially if there are vendors that are a little slow at
pushing out fixed BIOS updates.

Intel folks ?

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

Well, ASUS has released a verion of the BIOS(1006) that resolves all of the ACPI
issues that are reported in this ticket.  So, I am closing this ticket.  Thanks
for your help folks.

P.S.  FC4 installs on both SATA controllers of the K8N-DL now.