After much time investment and uncertainty, I managed to install
Ubuntu 6.0.6 on a system which has its only hard drive connected via
the P-ATA channel of a Promise FastTrack 387 controller in UDMA7 mode
(aka ATA 133).
However, the only way I was able to make that
Live CD complete its boot (which is essential to double-clicking the
"Install to HDD" icon on the desktop), was by specifying the "irqpoll"
kernel option at the boot prompt. Thereafter, installation proceeded
without a hassle and, in fact, I am posting this message from this
newly installed Linux-based system.
My question is: once I
specified the "irqpoll" option to boot the installation CD, is the
system doomed to always work in "IRQ polling mode" (which is much more
CPU wasteful if I understand this correctly)? Am I really using my
hardware now in less than optimal manner (like in PIO vs. DMA, for
example)?
I am enclosing some relevant lines from my system's dmesg:
[17179569.184000] Kernel command line: root=/dev/sda3 ro quiet splash irqpoll
[17179569.184000] Misrouted IRQ fixup and polling support enabled
[17179569.184000] This may significantly impact system performance
[17179569.184000] mapped APIC to ffffd000 (fee00000)
[17179569.184000] mapped IOAPIC to ffffc000 (fec00000)
[17179579.472000] irq 177: nobody cared (try booting with the "irqpoll" option)
[17179579.472000] [<c014fc8a>] __report_bad_irq+0x2a/0xa0
[17179579.472000] [<c014fda7>] note_interrupt+0x87/0xf0
[17179579.472000] [<c014f57d>] __do_IRQ+0xfd/0x110
[17179579.472000] [<c0105c79>] do_IRQ+0x19/0x30
[17179579.472000] [<c0103eb6>] common_interrupt+0x1a/0x20
[17179579.472000] [<f88f44f4>] ehci_irq+0x34/0x1c0 [ehci_hcd]
[17179579.472000] [<f891f1f9>] usb_hcd_irq+0x39/0x70 [usbcore]
[17179579.472000] [<c014f44d>] handle_IRQ_event+0x3d/0x70
[17179579.472000] [<c014f51d>] __do_IRQ+0x9d/0x110
[17179579.472000] [<c0105c79>] do_IRQ+0x19/0x30
[17179579.472000] [<c0103eb6>] common_interrupt+0x1a/0x20
[17179579.472000] [<c03100e3>] _read_unlock+0x3/0x20
[17179579.472000] [<c0184fc2>] path_lookup+0x82/0x170
[17179579.472000] [<c0185403>] __user_walk+0x33/0x60
[17179579.472000] [<c017ed2f>] vfs_stat+0x1f/0x60
[17179579.472000] [<c017f458>] sys_stat64+0x18/0x40
[17179579.472000] [<c017323c>] put_unused_fd+0x2c/0x60
[17179579.472000] [<c01733b6>] do_sys_open+0xd6/0x100
[17179579.472000] [<c0103471>] syscall_call+0x7/0xb
[17179579.472000] handlers:
[17179579.472000] [<c02737f0>] (ide_intr+0x0/0x1f0)
[17179579.472000] [<c02737f0>] (ide_intr+0x0/0x1f0)
[17179579.472000] Disabling IRQ #177
Thanks for any tip or insight!
Alex
Ar Iau, 2006-11-02 am 21:37 -0800, ysgrifennodd xp newbie:
> specified the "irqpoll" option to boot the installation CD, is the
> system doomed to always work in "IRQ polling mode" (which is much more
> CPU wasteful if I understand this correctly)? Am I really using my
> hardware now in less than optimal manner (like in PIO vs. DMA, for
> example)?
irqpoll has a small impact, how big depends what the box does (on a
gigabit network firewall its bad news, on a typical desktop its not
measurable).
IRQ problems of the form you report can arise from a couple of places -
one is vendors getting IRQ routing tables wrong (suprisingly common),
the other may be a Linux bug.
Checking for a BIOS update may therefore be useful.
Is this a VIA chipset machine ?
Alan
--- Alan Cox <[email protected]> wrote:
> irqpoll has a small impact, how big depends what the
> box does (on a
> gigabit network firewall its bad news, on a typical
> desktop its not
> measurable).
Thank you, Alan. Indeed, it is a desktop machine so I
guess I should not be too concerned. I should note
hoever that while downloading an ISO image from the
Internet and doing nothing else (not even moving the
mouse), the System Monitor showed CPU usage of 15%.
The same machine booting to Windows 2000, shows in
such circumstances 0% CPU use (something lesser than
1% to be more exact).
> IRQ problems of the form you report can arise from a
> couple of places -
> one is vendors getting IRQ routing tables wrong
> (suprisingly common),
> the other may be a Linux bug.
>
I first heard of that IRQ table misrouting when I
tried to install Ubuntu on an older ASUS motherboard
(P2B-S) and the Ubuntu installer would simply exit
with an error message, saying that the P2B-S is
blacklisted due to its incorrect routing table.
But that board, again, was running Windows 2000
without any performance sacrifices... How does Windows
achieve that trick?
Is it possible that it is only a question of well
tweaked device drivers?
> Checking for a BIOS update may therefore be useful.
I have it updated to the latest & greatest (still, it
is a year old motherboard).
> Is this a VIA chipset machine ?
Funny that you ask, since after having nightmarish
experience with VIA chipsets on various Windows
machines, I vowed to never buy again any motherboard
that has a VIA chipset. So, the two particular ASUS
motherboards that I mentioned above are not VIA-based.
The motherboard for which I posted the original
message is an ASUS P4P800-E Deluxe (P4 3GHz, 1GB RAM,
nVidia chipset, Promise FastTrack 387 P-ATA
controller).
In fact, searching and researching for a solution to
my problem, I discovered that no one was able to
install Linux on this motherboard without a problem or
needing to compromise on performance. The most common
solution was to instruct the BIOS to use the FastTrack
387 P-ATA controller in "compatible mode" rather than
the "enhanced mode" that works so well in W2K. Here is
a posting related to the subject:
http://ubuntuforums.org/showthread.php?t=289523
And if you notice, it seems that other users are not
aware of the implications of various "tricks" they use
to make Linux install.
I know that there is an issue with Promise
controllers, as Promise releases only binaries of its
drivers for Linux, not the source code. :(
I was thinking however that among the wonderful talent
in this newsgroup, perhaps I could find a *good*
workaround for this problem. By "good workaround" I
mean "that does not hurt performance".
Thank you so much!
Alex
____________________________________________________________________________________
Everyone is raving about the all-new Yahoo! Mail
(http://advision.webevents.yahoo.com/mailbeta/)
Ar Gwe, 2006-11-03 am 07:10 -0800, ysgrifennodd xp newbie:
> Thank you, Alan. Indeed, it is a desktop machine so I
> guess I should not be too concerned. I should note
> hoever that while downloading an ISO image from the
> Internet and doing nothing else (not even moving the
> mouse), the System Monitor showed CPU usage of 15%.
> The same machine booting to Windows 2000, shows in
> such circumstances 0% CPU use (something lesser than
> 1% to be more exact).
The two systems don't measure performance the same way. That makes
comparisons using their own monitoring tools a bit dubious and can make
either OS look better in cases where it isn't
> But that board, again, was running Windows 2000
> without any performance sacrifices... How does Windows
> achieve that trick?
I wish I knew. One possibility - especially as this appears to be the
USB 2.0 is that it provides different rules for different OS's (thats
intended to be a feature so it can hide EHCI from old windows etc)
You might want to see if booting with the kernel option "acpi_noirq" has
any effect for the better, you can also spoof different versions of
windows for ACPI using
acpi_os_name="Microsoft Windows"
(Not sure how you spoof XP etc offhand but it should be documented
somewhere)
Various things are going on to improve the poor state of PC BIOSes
including a firmware test kit from Intel.
> I know that there is an issue with Promise
> controllers, as Promise releases only binaries of its
> drivers for Linux, not the source code. :(
Actually promise are generally providing both docs and their own binary
driver.
--- Alan Cox <[email protected]> wrote:
> The two systems don't measure performance the same
> way. That makes
> comparisons using their own monitoring tools a bit
> dubious and can make
> either OS look better in cases where it isn't
OK, but in this case Linux kernel itself tells me that
something is wrong (via the demsg log). So I am trying
to optimize the system *before* intalling the tons of
tools that I need and discovering later that I may
have use the incorrect boot option during
installation, requiring me to re-install again.
> I wish I knew. One possibility - especially as this
> appears to be the
> USB 2.0 is that it provides different rules for
> different OS's (thats
> intended to be a feature so it can hide EHCI from
> old windows etc)
>
> You might want to see if booting with the kernel
> option "acpi_noirq" has
> any effect for the better, you can also spoof
I just tried that:
Once replacing the 'irqpoll' option (which froze boot
completely, sending tons of lines of the following
error message:
[17179576.748000] hda: cdrom_pc_intr: The drive
appears confused (ireason = 0x01)
And only a hard reset could get me out of there...
The second trial was appending acpi_noirq to the boot
options (i.e. in addition to 'irqpoll') and this time,
it booted. However, demsg still shows that something
is wrong with the system:
[17179569.184000] Kernel command line: root=/dev/sda3
ro quiet splash irqpoll acpi_noirq
[17179569.184000] Misrouted IRQ fixup and polling
support enabled
[17179569.184000] This may significantly impact system
performance
[17179569.184000] mapped APIC to ffffd000 (fee00000)
[17179569.184000] mapped IOAPIC to ffffc000 (fec00000)
But a few lines later:
[17179577.600000] irq 177: nobody cared (try booting
with the "irqpoll" option)
[17179577.600000] [<c014fc8a>]
__report_bad_irq+0x2a/0xa0
[17179577.600000] [<c014fda7>]
note_interrupt+0x87/0xf0
[17179577.600000] [<c014f57d>] __do_IRQ+0xfd/0x110
[17179577.600000] [<c0105c79>] do_IRQ+0x19/0x30
[17179577.600000] [<c0103eb6>]
common_interrupt+0x1a/0x20
[17179577.600000] [<c014f428>]
handle_IRQ_event+0x18/0x70
[17179577.600000] [<c014fde6>]
note_interrupt+0xc6/0xf0
[17179577.600000] [<c014f51d>] __do_IRQ+0x9d/0x110
[17179577.600000] [<c0105c79>] do_IRQ+0x19/0x30
[17179577.600000] [<c0103eb6>]
common_interrupt+0x1a/0x20
[17179577.600000] [<c01fd0a9>] vsnprintf+0x499/0x640
[17179577.600000] [<f88f9000>] handshake+0x0/0x60
[ehci_hcd]
[17179577.600000] [<c01994e8>] seq_printf+0x38/0x60
[17179577.600000] [<c0146404>] m_show+0x44/0xc0
[17179577.600000] [<c0198fef>] seq_read+0x28f/0x2f0
[17179577.600000] [<c0173ea6>] vfs_read+0xd6/0x1b0
[17179577.600000] [<c01742ab>] sys_read+0x4b/0x80
[17179577.600000] [<c0103471>] syscall_call+0x7/0xb
[17179577.600000] handlers:
[17179577.600000] [<c02737f0>] (ide_intr+0x0/0x1f0)
[17179577.600000] [<c02737f0>] (ide_intr+0x0/0x1f0)
[17179577.600000] [<f891f1c0>] (usb_hcd_irq+0x0/0x70
[usbcore])
[17179577.600000] Disabling IRQ #177
And my question is: if the kernel recognizes that the
irqpoll options has been specified, why does it say
"(try booting with the irqpoll option"?
Could this be a kernel bug?
Thanks,
Alex
____________________________________________________________________________________
We have the perfect Group for you. Check out the handy changes to Yahoo! Groups
(http://groups.yahoo.com)