Bug 237376

Created attachment 153240 [details]
Output from dmesg

Created attachment 153241 [details]
Output from lspci

Need to check with upstream dvb to see if this is a known issue and if its
already fixed, just pending the updated bits trickling into the kernel...

Believed to be a generic problem with the PCI bus on this particular machine,
not a cx88 or hd5500-specific issue. Possibly related to the use of noapic on
the kernel boot line. What's the behavior if you don't throw noapic at it?

If I don't include noapic I receive a kernel panic.  I reported this problem in:
Bug 235761: MP-BIOS 8254 Timer not connected to IO-APIC - GA-M59SLI-S5

When you say "generic problem with the PCI bus" are you referring to a hardware
error on the motherboard which should be taken up with Gigabyte/NVidia or a
Linux kernel issue?  

Please let me know what I can do to assist getting this resolved.

I also have two other issues I have opened with this motherboard, just for your
information.  

Bug 230804 nVidia MCP55 loses PCM device ALC883 - GA-M59SLI-S5  	 
Bug 230838 JMB363 drives seen as both SDA and HDA DMA_BASE INVALID-GA-M59SLI-S5

(In reply to comment #5)
> If I don't include noapic I receive a kernel panic.  I reported this problem in:
> Bug 235761: MP-BIOS 8254 Timer not connected to IO-APIC - GA-M59SLI-S5
[...]
> I also have two other issues I have opened with this motherboard, just for your
> information.  
> 
> Bug 230804 nVidia MCP55 loses PCM device ALC883 - GA-M59SLI-S5  	 
> Bug 230838 JMB363 drives seen as both SDA and HDA DMA_BASE INVALID-GA-M59SLI-S5

Aiee. With that many things awry, I'd be inclined to lay a good chunk of the
blame on bad board design and/or a flaky bios...

> When you say "generic problem with the PCI bus" are you referring to a hardware
> error on the motherboard which should be taken up with Gigabyte/NVidia or a
> Linux kernel issue?  

I'm not certain if its the board or the kernel at fault. Primarily what I meant
was that it didn't look to be the cx88 driver's fault.

> Please let me know what I can do to assist getting this resolved.

Seems from the other bugs, you've already tried a number of kernels in this
system with only slight improvements in some areas, and you're already running
the latest bios... Hrm. That being the case, I got nothin' much to suggest right
now.

Were earlier kernels afflicted with this particular problem (IRQ/nobody cared)
as well, or is this a new development?

The IRQ problem has been with the board throughout all the different kernel
updates I have tried.  I just got around entering this particular problem since
I've been slugging through all the other issues.  When I purchased a few months
ago, it was hard to find the issues, but now that I know the right "key-words"
I'm able to find all kinds of issues regarding NOAPIC and the AMD AM2 chip. 
Here is a link:  http://www.linuxjournal.com/node/1000074 from August 2006 for
an ASUS AM2 board which is having major problems with the HD5500 and references
problems booting without NOAPIC.  Seems to be a recurring theme that there is
something going on with the kernel and AM2 based boards.  It doesn't appear to
be a problem with this particular board or Fedora in general.  It appears to be
processor/chipset/kernel issue since this problem is occurring in Ubuntu and
Fedora.  Is there some way this can get some additional visibility up in the
Redhat eschelon.  I would think AMD/nVidia would be very happy to cooperate
since if this isn't resolved folks are going to be running in droves to the
Intel side of the house.

Found a reference to option "pci=noacpi" tried and it appears to work much
better than using the "noapic" option.  The "noapic" option was causing problems
with my soundcard and tvtuner card.  I've only been running this way for six
hours but so far so good.  Your mileage may vary.  It appears the problem with
the motherboard is related to "acpi" and NOT "apic".  To make the change either
go into root mode or use sudo, then edit /boot/grub/grub.conf
go to the line which begins with "kernel", and add "pci=noacpi" (without quotes). 
My entries now appear as follows:

title Fedora (2.6.21-1.3228.fc7)
        root (hd0,0)
        kernel /vmlinuz-2.6.21-1.3228.fc7 ro root=LABEL=/ pci=noacpi rhgb quiet
        initrd /initrd-2.6.21-1.3228.fc7.img
title Fedora (2.6.21-1.3194.fc7)
        root (hd0,0)
        kernel /vmlinuz-2.6.21-1.3194.fc7 ro root=LABEL=/ pci=noacpi rhgb quiet
        initrd /initrd-2.6.21-1.3194.fc7.img

I did some additional searches and found that "acpi_use_timer_override" also
fixes the problem and apparently for this particular motherboard is the
workaround of choice and the only option needed.  Looks like the problem is because 
HPET (high precision event timer) support isn't correctly implemented in the BIOS.  

I also found where there is some work going on in to enable HPET support for
motherboards with a broken bios:
http://lkml.org/lkml/2007/4/20/374

Why so many different manufacturers have the same problem is curious - and looks
like it might point back to NVIDIA.  

In the meantime, in addition to changing to the above option, I've opened a bug
report with Gigabyte asking them to enable HPET support.  Looks like they have
already fixed on the GA-M57SLI-S4 BIOS.

Gigabyte has provided a test BIOS "m59slis5.f8g" which appears to have fixed the
problem.  They should be posting on their website; or you can request it
directly from them via their website.  I am now able to boot without using the
"acpi_user_timer_override" parameter.  

Excellent, so it was indeed a bios problem, glad to hear you've got a fix in hand.

(In reply to comment #10)
> Gigabyte has provided a test BIOS "m59slis5.f8g" which appears to have fixed 
the
> problem.  They should be posting on their website; or you can request it
> directly from them via their website.  I am now able to boot without using the
> "acpi_user_timer_override" parameter.  

Hi,
I wonder how you were able to convince Gigabyte to give you a beta BIOS? I have 
Gigabyte GA-M59SLI-S4 with the same problem as yours, so I wrote to a technical 
support and explained, that I have problem with booting linux without noapic 
option. Here is what I get from them... :| Any suggestions, what I should write 
them?

---------------------------------------------------------------------------

Dear Sir,

Thank you for your kindly mail and supporting GIGABYTE.
About the issue you mentioned in your earlier mail, as we mentioned on the 
driver download page of GIGABYTE website, due to different Linux support 
condition provided by chipset vendors, please download Linux driver from 
chipset vendors' website or 3rd party website. Sorry if there is any 
inconvenience.

You didn't include the email you sent them, but you have to be very specific in
what you ask.  I asked them point blank to enable HPET support in the BIOS. 
This bug report is specific to the GA-M59SLI-S5 - if you are having the same
issue, I recommend you use the "acpi_user_timer_override" and see if that solves
your problem.  If it doesn't, then HPET may not help you.

Correction:  
The correct string is "acpi_use_timer_override" not ..._user_...

Well... the kernel parameter "acpi_use_timer_override" didn't help, at least 
for Mandriva 2007 Spring (kernel2.6.17-13mdv for x86-64) Tomorrow I will try 
passing the parameter to Fedora 7.
This is that I got from Mandriva:
"ACPI: Looking for DSDT in initramfs... error, file /DSDT.aml not found.
...MP-BIOS bug: 8254 timer not connected to IO-APIC.
Kernel panic - not syncing: IO-APIC+timer doesn't work!"

If you use "noapic noirqdebug" the interrupt won't be disabled even though IRQ7
is still being hit with spurious interrupts.

"Acpi_use_timer_override" parameter worked with Fedora 7, so I will try 
Gigabyte to help me out with HPET support.