From: Gerald Britton <gbritton@alum.mit.edu>
To: Jamie Lokier <jamie@shareable.org>
Cc: Gerald Britton <gbritton@alum.mit.edu>,
Alan Cox <alan@lxorguk.ukuu.org.uk>,
emperor@EmperorLinux.com, LKML <linux-kernel@vger.kernel.org>,
EmperorLinux Research <research@EmperorLinux.com>,
"Theodore Ts'o" <tytso@mit.edu>
Subject: Re: Linux and IBM : "unauthorized" mini-PCI : Cisco mpi350 _way_ sub-optimal
Date: Wed, 9 Jul 2003 18:35:41 -0400 [thread overview]
Message-ID: <20030709183541.C10882@light-brigade.mit.edu> (raw)
In-Reply-To: <20030708205809.GA18307@mail.jlokier.co.uk>; from jamie@shareable.org on Tue, Jul 08, 2003 at 09:58:09PM +0100
On Tue, Jul 08, 2003 at 09:58:09PM +0100, Jamie Lokier wrote:
> You may be able to identify devices which are very unlikely to be
> touched by the SMI handler, and just allow those to be moved.
> E.g. video cards, USB, IDE, "system", ISA bridge etc. may all be
> touched by the SMI (for power management), but the sound, modem and
> network are much less unlikely.
Often the problem bridges contain such devices, and are surrounded by
them as well, so moving them isn't really all that safe.
Here's another datapoint I found today:
(numbers represent resources).
-+-[host 05]
+-[ide 08]
+-[usb 04]
+-[vga 03]
+-[audio 02]
+-[pci bridge 02-06]
+-[ethernet 07]
+-[device in slot 01]
The bridge is setup completely wrong, and appears to be entirely transparent
regardless of the resource ranges programmed into it. X was complaining about
the vga device having an invalid I/O resource (since it was a resource which
is supposedly behind the bridge). And the devices behind the bridge were
working just fine even with resource allocations outside the range of the
bridge. Using setpci to edit the bridge configuration made X stop being
concerned about the resources.
-- Gerald
prev parent reply other threads:[~2003-07-09 22:21 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2003-06-03 16:49 Linux and IBM : "unauthorized" mini-PCI : TCPA updates Lincoln Durey
2003-06-03 16:34 ` Alan Cox
2003-06-03 18:29 ` Josh Litherland
2003-06-03 17:04 ` Michael Frank
2003-06-03 17:42 ` Timothy Miller
2003-06-04 12:39 ` Derek Fawcus
2003-06-06 22:59 ` Martin List-Petersen
2003-06-09 12:57 ` Dana Lacoste
2003-06-09 16:56 ` Martin List-Petersen
2003-06-10 23:35 ` Theodore Ts'o
2003-07-07 18:12 ` Linux and IBM : "unauthorized" mini-PCI : Cisco mpi350 _way_ sub-optimal Lincoln D. Durey
2003-07-08 14:02 ` Alan Cox
2003-07-08 15:20 ` Gerald Britton
2003-07-08 15:42 ` Alan Cox
2003-07-08 17:24 ` Gerald Britton
2003-07-08 17:44 ` Russell King
2003-07-08 20:58 ` Jamie Lokier
2003-07-09 22:35 ` Gerald Britton [this message]
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=20030709183541.C10882@light-brigade.mit.edu \
--to=gbritton@alum.mit.edu \
--cc=alan@lxorguk.ukuu.org.uk \
--cc=emperor@EmperorLinux.com \
--cc=jamie@shareable.org \
--cc=linux-kernel@vger.kernel.org \
--cc=research@EmperorLinux.com \
--cc=tytso@mit.edu \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®