Bug 237376 - HD5500 (cx88) IRQ Disabled (Nobody Cared) - GA-M59SLI-S5
HD5500 (cx88) IRQ Disabled (Nobody Cared) - GA-M59SLI-S5
Status: CLOSED NOTABUG
Product: Fedora
Classification: Fedora
Component: kernel (Show other bugs)
7
All Linux
medium Severity high
: ---
: ---
Assigned To: Kernel Maintainer List
Brian Brock
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2007-04-21 11:33 EDT by Gerald Cox
Modified: 2007-11-30 17:12 EST (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2007-09-18 09:29:59 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
Output from dmesg (25.28 KB, text/plain)
2007-04-21 11:33 EDT, Gerald Cox
no flags Details
Output from lspci (27.10 KB, text/plain)
2007-04-21 11:35 EDT, Gerald Cox
no flags Details

  None (edit)
Description Gerald Cox 2007-04-21 11:33:53 EDT
Description of problem:
HD5500 HDTV Card not functioning.  After boot, IRQ is disabled with
nobody cared message.  Tried using IRQPOLL option as suggested in log, however
when used, system hangs during boot.
Call Trace:
 <IRQ>  [<ffffffff802bcff4>] __report_bad_irq+0x38/0x7c
 [<ffffffff802bd1fb>] note_interrupt+0x1c3/0x209
 [<ffffffff802bdd70>] handle_level_irq+0xc5/0x100
 [<ffffffff8026bf7f>] do_IRQ+0xf6/0x166
 [<ffffffff8026a666>] default_idle+0x0/0x51
 [<ffffffff8025c666>] ret_from_intr+0x0/0xf
 <EOI>  [<ffffffff80260eba>] __sched_text_start+0x92a/0x962
 [<ffffffff8026a69b>] default_idle+0x35/0x51
 [<ffffffff8026a69d>] default_idle+0x37/0x51
 [<ffffffff8026a69b>] default_idle+0x35/0x51
 [<ffffffff8024884f>] cpu_idle+0xa1/0xc4
 [<ffffffff80275541>] start_secondary+0x2bb/0x2ca

handlers:
[<ffffffff88339739>] (cx8800_irq+0x0/0x232 [cx8800])
[<ffffffff88353f2d>] (cx8802_irq+0x0/0x291 [cx8802])
Disabling IRQ #7



Version-Release number of selected component (if applicable):


How reproducible:
Boot System

Steps to Reproduce:
1.  Boot System


Actual results:
Receive IRQ disabled message


Expected results:
Properly functioning card.

Additional info:
Comment 1 Gerald Cox 2007-04-21 11:33:53 EDT
Created attachment 153240 [details]
Output from dmesg
Comment 2 Gerald Cox 2007-04-21 11:35:11 EDT
Created attachment 153241 [details]
Output from lspci
Comment 3 Jarod Wilson 2007-04-24 14:19:39 EDT
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...
Comment 4 Jarod Wilson 2007-04-24 17:19:31 EDT
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?
Comment 5 Gerald Cox 2007-04-24 20:18:43 EDT
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
Comment 6 Jarod Wilson 2007-04-25 09:30:30 EDT
(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?
Comment 7 Gerald Cox 2007-04-25 10:02:38 EDT
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.
Comment 8 Gerald Cox 2007-07-04 19:08:00 EDT
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
Comment 9 Gerald Cox 2007-09-13 23:43:31 EDT
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.
Comment 10 Gerald Cox 2007-09-17 19:15:03 EDT
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.  
Comment 11 Jarod Wilson 2007-09-18 09:29:59 EDT
Excellent, so it was indeed a bios problem, glad to hear you've got a fix in hand.
Comment 12 Edgaras 2007-10-02 14:58:33 EDT
(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.
Comment 13 Gerald Cox 2007-10-02 15:52:54 EDT
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.
Comment 14 Gerald Cox 2007-10-02 17:18:29 EDT
Correction:  
The correct string is "acpi_use_timer_override" not ..._user_...
Comment 15 Edgaras 2007-10-09 17:45:01 EDT
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!"
Comment 16 Chuck Ebbert 2007-10-09 17:53:06 EDT
If you use "noapic noirqdebug" the interrupt won't be disabled even though IRQ7
is still being hit with spurious interrupts.
Comment 17 Edgaras 2007-10-10 17:42:12 EDT
"Acpi_use_timer_override" parameter worked with Fedora 7, so I will try 
Gigabyte to help me out with HPET support.

Note You need to log in before you can comment on or make changes to this bug.