From: Robert Hancock <hancockr@shaw.ca>
To: linux-kernel <linux-kernel@vger.kernel.org>
Subject: Re: PROBLEM: Full CPU-usage on sis5513-chipset disc input/output-operations
Date: Fri, 03 Sep 2004 21:25:43 -0600 [thread overview]
Message-ID: <006201c4922e$dc4b9bb0$6601a8c0@northbrook> (raw)
In-Reply-To: fa.fc3clr3.71gar9@ifi.uio.no
I think that at least with relatively current motherboards it makes sense to
at least try the APIC support. Speaking of "works in Windows", I think APIC
mode has a greater chance of working these days on UP motherboards because
Microsoft is pushing motherboard/system manufacturers to support IOAPIC in
all new designs:
http://www.microsoft.com/whdc/system/sysperf/IO-APIC.mspx
----- Original Message -----
From: "Daniel Egger" <degger@fhm.edu>
Newsgroups: fa.linux.kernel
To: "Alan Cox" <alan@lxorguk.ukuu.org.uk>
Cc: "Hendrik Fehr" <s4248297@rcs.urz.tu-dresden.de>; "Linux Kernel Mailing
List" <linux-kernel@vger.kernel.org>
Sent: Friday, September 03, 2004 11:14 AM
Subject: Re: PROBLEM: Full CPU-usage on sis5513-chipset disc
input/output-operations
On 03.09.2004, at 16:07, Alan Cox wrote:
> For uniprocessor machines you should avoid building with APIC support
> in
> general anyway. A lot of systems simply don't work with APIC
> uniprocessor because nobody used to use the APIC in such a
> configuration.
This statement I don't understand. Wouldn't it be pretty stupid
not to use the APIC of modern systems if available to get all
the benefits, like additional interrupts? At least my Asus A7V600
refuses to (net-)boot at all without a somewhat recent kernel *and*
APIC enabled in BIOS and kernel because the interrupt routing is
completely messed up. I'd rather let all users who have APIC
problems report on the list and wait until someone fixes the
issue instead of having them shut up and use less advanced
techniques instead unless you want to get those "but it works in
Windows" discussions going...
Servus,
Daniel
next parent reply other threads:[~2004-09-04 3:31 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <fa.lcmvbgi.1m1iepk@ifi.uio.no>
[not found] ` <fa.fc3clr3.71gar9@ifi.uio.no>
2004-09-04 3:25 ` Robert Hancock [this message]
[not found] <Pine.GSO.4.10.10409080011370.6828-100000@rcs54.urz.tu-dresden.de>
2004-09-07 23:15 ` PROBLEM: Full CPU-usage on sis5513-chipset disc input/output-operations Hendrik Fehr
2004-09-03 13:16 Hendrik Fehr
-- strict thread matches above, loose matches on Subject: below --
2004-09-03 13:01 Hendrik Fehr
2004-09-03 14:07 ` Alan Cox
2004-09-03 15:52 ` Daniel Egger
2004-09-03 14:23 ` Mikael Pettersson
2004-09-03 10:22 Hendrik Fehr
2004-09-03 10:54 ` Mikael Pettersson
2004-09-03 10:55 ` Alan Cox
2004-09-02 17:11 Hendrik Fehr
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='006201c4922e$dc4b9bb0$6601a8c0@northbrook' \
--to=hancockr@shaw.ca \
--cc=linux-kernel@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.