Ok so i have reached that point.... i have searched and googled but to no avail so i come to you guys. Basically i have a triple boot setup on a mac pro tower. windows /osx /centos 5.3 everything was great until i tried setting up my Wacom. I did get it setup but in the process revealed a problem i was having that i didn't notice until this point. Mind you my system boots perfectly everything runs perfectly except i belive my DVDrom and rear usb ports are trying to share the same IRQ.... and from what it looks like they don't want to play nice with each other. Eventually CentOS kills the IRQ thus killing both devices. everything works fine on the windows and mac osx side.

I have tried unpluging and repluging the DVDROM, I wanted to try another ide channel but the motherboard only has one. I have changed the device from auto to master to slave. When the DVDROM is removed i have no IRQ errors in my dmesg. I forgot to add that adding IRQpoll to my grub boot pretty much destroys the system.... hard lock within 20 seconds of loging in. I have tried loading a different distro Fedora and there seems to be no IRQ conflict but i would really like to stay with CentOS. Does anyone know why this may be?

in CentOS, is there anyway that i can force the DVDROM to it's own IRQ? I would really appreciate any help! thank you so much!

Also Mac Pro dosn't have a bios like a pc it uses EFI.....

-Onedigital

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

Download Dmesg Log

How do you know that CentOS is doing this?Please quote the bits of your syslog (dmesg output) that is important to this problem.Perhaps fedora is using a more recent kernel? Perhaps it's kernel has been configured differently? uname -rSometimes it is possible to force the systems configuration to use a different interrupt for different devices - googled this but not a lot of luck so far. Meantime - see if your symptoms look like this:

http://www.mail-archive.com/mactel-l.../msg00129.html
... suggests: acpi=force on your kernel line.

But the long-term fix looks to be an updated kernel - which means waiting for redhat to build one or building one yourself. (Or changing distro for a bit.)

From my experience - I have seen this when a mixture of SATA and IDE devices are used.

But all this is guesswork - we need to see those logs.

In my first message i attached the whole dmessage log as a link "download dmessage log". Thank you so much for responding to my post i haven't gotten much response anywhere so every little bit helps! I will do some poking around about kernel versions see what i come up with. Anyway thanks so much again for responding!

handlers:
[<ffffffff8000d346>] (ide_intr+0x0/0x1df)
[<ffffffff801e65ca>] (usb_hcd_irq+0x0/0x55)
Disabling IRQ #98
hda: lost interrupt
ide-cd: cmd 0x3 timed out
hda: lost interrupt
hda: request sense failure: status=0x51 { DriveReady SeekComplete Error }
hda: request sense failure: error=0x54 { AbortedCommand LastFailedSense=0x05 }

I have tried that but with no luck i have tried just about every relevant kernel flag but nothing...

cat /proc/interrupts


from your dmesg appended post#1: all mentions of irq98 in order.

ACPI: PCI Interrupt 0000:00:1f.1[A] -> GSI 20 (level, low) -> IRQ 98
ESB2: 100% native mode on irq 98
ide0 at 0x30e8-0x30ef,0x30fe on irq 98
ACPI: PCI Interrupt 0000:00:1d.1[B] -> GSI 20 (level, low) -> IRQ 98
uhci_hcd 0000:00:1d.1: irq 98, io base 0x00003080
irq 98: nobody cared (try booting with the "irqpoll" option)
Disabling IRQ #98



Do you have a mix of sata and pata devices?

esb2 is for the sata controller
uhci is indeed usb

looks indeed like an irq conflict between usb and a sata device.

That this goes away in another distro suggests it is something which has been fixed in a later kernel.
The kernel you are using is 2.6.18-128.1.10.el5 - which is quite old so this is likely.


Even though you don't have a bios you still get bios messages -
BIOS-provided physical RAM map:
... so it is odd that irqpoll is not working.

Have you tried noapic noacpi ??

Have you tried pci=routeirq ??

There are indirect things to think about - like have you tried switching SELinux off?
If a new device was added since install, have you tried reinstalling with all devices attached?
(This last should never be needed - it's just that it is often simpler to let the installers detection magic figure out where everything goes.)

I still think your solution is to upgrade the kernel.