This item (and more generally the precedent it sets) will soon have a
disastrous effect on the Linux community, even though it is not
_directly_ a Linux problem.
Most of you have seen my LKML posting: (most of the tech details)
http://www.ussg.iu.edu/hypermail/linux/kernel/0305.3/1538.html
"IBM T40 _refusing_ to boot with "unauthorized" mini-PCI wifi card"
As I gather more info, it becomes clear that the IBM T40 has a TCPA chip
in it with a "white list" of _allowed_ cards. Apparently IBM has made a
_policy_ decision to disallow any wifi card not on the list. (more
below). In doing this they have (perhaps unknowingly) severely limited
the usefulness of the entire T40 (and X31 by extension) laptop lines for
the many users of the Linux OS on those IBM systems. Surely this was
not intentional....
The solution is a very simple removal of the white list from the BIOS.
_telling_ your customers what they may or may not put in a standard PC
expansion slot at the BIOS level (regardless of OS) is going to be a
disaster...
In reply to my e-mail of 5-30, titled: (and my replies to them)
"IBM T40 _refusing_ to boot with "unauthorized" mini-PCI wifi card"
Kent E Yoder <[email protected]> (512) 838-8397 writes:
> (I'm copying Janice here, who is the network device driver lead in
> the LTC, perhaps she can be of more assistance.) Its really
> surprising that there would be this limitation though. The fact that
> it says "unauthorized" seems suspect here, since I doubt there's just
> a list of cards you can install... I see this model has a TCPA chip
> in it; if you've turned that on, you might want to install the card
> and then clear the TCPA ship. Let me know if this works...
I've tried several variations on this theme, to no avail. The TCPA chip
was initially not activated, and the 1802 error occurs. Activating the
chip, and then clearing its settings (all via the BIOS) does nothing.
If the "IBM High Rate Wireless" (22P7701) is in the system, you get the
1802 error before you can even access the BIOS.
So, there indeed must be a "white list" (of what can be put in a
standard expansion slot!)
Burt Silverman <[email protected]> writes:
> Sorry I have no experience with any Wireless cards at this point in
> time, and I have not seen this problem with much older PC cards that
> I used to use.
> Tim, do you know if anybody follows ThinkPad/Linux issues and that
> monitors problem areas like this? There used to be someone named
> Keith Frechette, but I cannot locate him in the directory.
PCMCIA cards are not affected, because we all _know_ these are for
peripheral expansion. But we also all know that mini-PCI is also a
technology to allow expansion of laptops.
Bradford Jones <[email protected]> writes:
> Unfortunately I have not been with the SWAT team for 3yrs, but based
> on what I know from working with development, I can tell you that
> unless you are specifically using one of the min-PCI cards listed as
> a supported option, that is the error you can expect to see. This may
> be in part because of certain FCC regulations regarding wi-fi and
> specifically 802.11a. For instance when the T40 was released, the FCC
> would not allow us to make mini-PCI cards using 802.11a technology
> customer accessible or customer upgradeable. This regulation does not
> apply to 802.11b, but there could be some other underlying reason for
> only allowing tested options to be installed. I cannot be sure though
> and will forward your inquiry to the current SWAT team.
I don't want the card to be "supported" by IBM, I just want the card
"authorized". Linux already has support for prism2 cards, but will not
have 802.11a or 802.11g support in the foreseeable future (and only "a"
and "g" cards are on the white list).
Greg KH <[email protected]> writes:
> Heh, sorry, I can't really help you out there. I have no contacts
> within the thinkpad division, and neither does anyone else within the
> LTC that I know of. The official statement is that the thinkpad
> division does not support Linux at all.
Again, the Linux community doesn't need support, just authorization.
> That being said, that is really a strange thing for the BIOS to do.
> I'll ask about it on an internal ibm linux mailing list and will let
> you know if anyone responds with anything.
The key thing to keep in mind is that while the affects Linux users
rather adversely, it is really a BIOS and _policy_ issue. This would
happen if one got a T40 with winXP and put in any 802.11b card.
Alexandre Tr?panier <[email protected]> (450) 534-7540 writes:
> It's not in my area of expertise but I took time to look in the
> intranet and I found nothing.
well Alex, perhaps you can paste this whole letter in...
-- Lincoln @ EmperorLinux
Solution: This community needs a white list of functioning hardware.
If NOBODY ever would purchase a piece of hardware unless proven
to work, there would be better support already.
How to make new hardware work? Manufacturers lend it to developers
and support development.
I suppose my notebook will last 4 years again as it took too much
effort to make work. Another 30 month to go then...
Regards
Michael
Michael Frank wrote:
> Solution: This community needs a white list of functioning hardware.
>
>
I could really use a white list for graphics cards. It's hard enough
finding something that works well in Windows. For Linux, it's
practically a lost cause unless you want to buy something more than 2
years old.
On Maw, 2003-06-03 at 17:49, Lincoln Durey wrote:
> As I gather more info, it becomes clear that the IBM T40 has a TCPA chip
> in it with a "white list" of _allowed_ cards. Apparently IBM has made a
> _policy_ decision to disallow any wifi card not on the list. (more
> below). In doing this they have (perhaps unknowingly) severely limited
> the usefulness of the entire T40 (and X31 by extension) laptop lines for
> the many users of the Linux OS on those IBM systems. Surely this was
> not intentional....
It seems remarkably incompetent if so.
Firstly IBM seem to claim the device supports mini-PCI but their public
details do not make it clear IBM only allow its use with certain
components so its not true mini-PCI - thats advertising and sales of
goods happy lawsuit time, and remarkably careless.
Secondly TCPA doesn't require such a restriction. A TCPA system can have
hardware whitelists so that the TCPA chip refuses to do any TCPA with
unknown devices present (since they may be hostile) but it doesn't have
to fail to boot in this case.
[The test is actually irrelevant not only because as you showed with the
hot plug case you can swap it but because even without its been known
since the mid 1970's how to get around that even though the 30 year old
knowledge may now not be spoken in the USSA]
So either
1. IBM got their TCPA horribly wrong
2. IBM got some kind of alleged FCC restrictions horribly wrong since
you've shown its trivially possible to swap the card.
If IBM claimed the device supported mini-PCI and the slot only works
with certain devices - and that was not made clear - that you take it
up with the relevan business/advertising standards bodies.
I suspect theregister.co.uk would be very interested in the story too 8)
In article <[email protected]> you wrote:
> Secondly TCPA doesn't require such a restriction. A TCPA system can have
> hardware whitelists so that the TCPA chip refuses to do any TCPA with
> unknown devices present (since they may be hostile) but it doesn't have
> to fail to boot in this case.
Interestingly, when the offending device is a modem, it will warn in
the BIOS but will neither disable the device nor refuse to boot. Only
when a wireless NIC is inserted will it grind to a bloody halt.
--
Josh Litherland ([email protected])
> Firstly IBM seem to claim the device supports mini-PCI but their public
> details do not make it clear IBM only allow its use with certain
> components so its not true mini-PCI - thats advertising and sales of
> goods happy lawsuit time, and remarkably careless.
Maybe there is a less evil explanation for this?
This is hypothetical, but before people go off and do something rash,
perhaps IBM prevents the card from booting for a technical reason. Maybe
it works electrically but in late testing they found it caused thermal or
electrical problems.
A quick fix would be to put a "do-not-boot" clause in the BIOS so the user
doesn't cook their machine.
Just a perspective from a (former) hardware person.
L8r,
Mark G.
On Tue, 3 Jun 2003, Mark Grosberg wrote:
> Maybe there is a less evil explanation for this?
>
> This is hypothetical, but before people go off and do something rash,
> perhaps IBM prevents the card from booting for a technical reason. Maybe
> it works electrically but in late testing they found it caused thermal or
> electrical problems.
There was a thread here(i think) recently about wirless causing problems
with other frequencies, and that you could only broadcast in a specific
set of frequencies. I assume this is related to what IBM has done.
Mike
In article <Pine.LNX.4.33.0306031538590.10095-100000@router.windsormachine.com> you wrote:
> There was a thread here(i think) recently about wirless causing problems
> with other frequencies, and that you could only broadcast in a specific
> set of frequencies. I assume this is related to what IBM has done.
The cards we were testing were 11b, so they wouldn't fall under the
banner of any evil frequency hopping device. Crippling the PCI slot to
prevent use of a card that could potentially break FCC regs provided
someone uses nonexistant published specs to develop an as-yet
nonexistant driver seems a might rash, don'tcha think ?
--
Josh Litherland ([email protected])
On Tue, 3 Jun 2003, Josh Litherland wrote:
> The cards we were testing were 11b, so they wouldn't fall under the
> banner of any evil frequency hopping device. Crippling the PCI slot to
> prevent use of a card that could potentially break FCC regs provided
> someone uses nonexistant published specs to develop an as-yet
> nonexistant driver seems a might rash, don'tcha think ?
IBM:
Left hand(linux), right hand(hardware guys). Any questions?
and to throw this in:
SCO:
Both hands in everyone elses wallet.
Mike
In article <Pine.LNX.4.33.0306031638530.6004-100000@router.windsormachine.com> you wrote:
> Left hand(linux), right hand(hardware guys).
-nod- Honestly, this is what we suspect as well. We've been climbing
the usual support ladders with IBM for several days now, so we're still
hoping for a cooperative resolution from them.
--
Josh Litherland ([email protected])
I can't say I'm too suprised.
This is fuzy recall, but I seem to remember reading that 802.11? mini-PCI
cards are not type approved (radio licence) by themselves, but only in
combination with the system they are to be fitted in.
Hence they're not supposed to be available retail (now someone'll go and
point out where they are :-)
Mind, that should just mean that the user makes changes at their own
risk, I wouldn't have thought that the PC manufacturer would have been
required to limit the choice of usable radios.
However given some of the obligations placed upon manufactures of the
radio cards, so that the user is prevented from changing configuration
of the radio cards themselves, I'm not too suprised - e.g. limits to
prevent a user from raising the TX power to illegal levels, despite
the fact that they could easily still use illegal antenna gain.
DF
On Wed, 2003-06-04 at 14:39, Derek Fawcus wrote:
> I can't say I'm too suprised.
>
> This is fuzy recall, but I seem to remember reading that 802.11? mini-PCI
> cards are not type approved (radio licence) by themselves, but only in
> combination with the system they are to be fitted in.
>
> Hence they're not supposed to be available retail (now someone'll go and
> point out where they are :-)
Eerh, dumb question here: Is this MiniPCI Wlan cards in general or how ?
I ask, because i've seen MiniPCI Wlan cards and i've seen cards that in
fact are PC-Card Wlan cards and a PC-Card-to-PCI bridge put together on
a MiniPCI card, just adding another PC-Card slot to your notebook and
inserting a Wlan card there (Dell TrueMobile 1150).
Regards,
Martin List-Petersen
martin at list-petersen dot dk
--
Operating Systems Installed:
* Debian GNU/Linux 2.1 4 CD Set ($20 from http://www.chguy.net; price includes
taxes, shipping, and a $3 donation to FSF). 2 CDs are binaries, 2 CDs
complete source code;
* Windows 98 Second Edition Upgrade Version ($136 through Megadepot.com,
price does not include taxes/shipping). Surprisingly, no source code
is included.
-- Bill Stilwell, http://linuxtoday.com/stories/8794.html
On Fri, 2003-06-06 at 18:59, Martin List-Petersen wrote:
> Eerh, dumb question here: Is this MiniPCI Wlan cards in general or how ?
> I ask, because i've seen MiniPCI Wlan cards and i've seen cards that in
> fact are PC-Card Wlan cards and a PC-Card-to-PCI bridge put together on
> a MiniPCI card, just adding another PC-Card slot to your notebook and
> inserting a Wlan card there (Dell TrueMobile 1150).
IIRC, it's the antenna PLUS the WLan card that gets FCC licensed,
so you violate FCC rules by allowing a card without an antenna,
and this is why even 'regular' pcmcia cards all have their own
'unique' antenna jacks, so you can't plug in an off the shelf antenna
and boost your signal.
So the theory that the IBM laptops with built in antennas can't
use just any mini-PCI card makes sense, even if it is stupid.
They would have been licensed for specific cards only, and would
be violating the FCC license to use other cards.
I hope that's all it is. If they had some other reason I'd be very
pissed off if I bought a stinkpad. (Wait a minute, I did buy a
stinkpad :)
Dana Lacoste
Ottawa, Canada
On Mon, 2003-06-09 at 14:57, Dana Lacoste wrote:
> On Fri, 2003-06-06 at 18:59, Martin List-Petersen wrote:
> > Eerh, dumb question here: Is this MiniPCI Wlan cards in general or how ?
> > I ask, because i've seen MiniPCI Wlan cards and i've seen cards that in
> > fact are PC-Card Wlan cards and a PC-Card-to-PCI bridge put together on
> > a MiniPCI card, just adding another PC-Card slot to your notebook and
> > inserting a Wlan card there (Dell TrueMobile 1150).
>
> IIRC, it's the antenna PLUS the WLan card that gets FCC licensed,
> so you violate FCC rules by allowing a card without an antenna,
> and this is why even 'regular' pcmcia cards all have their own
> 'unique' antenna jacks, so you can't plug in an off the shelf antenna
> and boost your signal.
>
> So the theory that the IBM laptops with built in antennas can't
> use just any mini-PCI card makes sense, even if it is stupid.
> They would have been licensed for specific cards only, and would
> be violating the FCC license to use other cards.
>
> I hope that's all it is. If they had some other reason I'd be very
> pissed off if I bought a stinkpad. (Wait a minute, I did buy a
> stinkpad :)
Ever thought that you might buy a sparepart for a notebook that you not
have ?
It can be, that you can't buy MiniPCI Wlan cards in retail. But they are
available as sparepart !
Regards,
Martin List-Petersen
martin at list-petersen dot dk
--
No matter what happens, there is always someone who knew it would.
On Tue, Jun 03, 2003 at 12:49:34PM -0400, Lincoln Durey wrote:
>
> As I gather more info, it becomes clear that the IBM T40 has a TCPA chip
> in it with a "white list" of _allowed_ cards. Apparently IBM has made a
> _policy_ decision to disallow any wifi card not on the list. (more
> below). In doing this they have (perhaps unknowingly) severely limited
> the usefulness of the entire T40 (and X31 by extension) laptop lines for
> the many users of the Linux OS on those IBM systems. Surely this was
> not intentional....
One bit of clarification here. First of all, the prohibition as
absolutely nothing to do with TCPA. Irrespective of what you might
think of the code in the BIOS which refuses to allow the machine to
boot with a unsupported card, this is completely orthoganal to the
functionality provided by the Embedded Security Subsystem chip, which
on the internal SM bus and merely is an encryption engine with some
key management magic. It encrypts and decrypts blobs of data upon
request (assuming that you have the right keys and/or encrypted key
blocks); nothing more.
Please see: http://www.research.ibm.com/gsal/tcpa/tcpa_rebuttal.pdf
For more information for some of the misinformation that's been going
around about TCPA. TCPA is completely different and frequently
confused with Microsoft's Palladium, which *IS* evil. :-)
As far as why there is a list of approved mini-PCI cards which are the
only ones accepted by BIOS, and why the BIOS refuses to boot if an
unsupported mini-PCI card is installed, I can only speculate. (And I
am **NOT** speaking for IBM here.) My initial reaction as soon as I
saw the story was FCC certification issues. Yes, other laptop vendors
may not be as careful; however, I can easily believe than an IBM
lawyer was simply being ultra-paranoid, and required the lockout code
in the BIOS. (Which, if you think about it, is very simple to
implement, and doesn't require any kind of special "chip", TCPA or
otherwise).
If the goal is simply to let a T40p laptop work with an internal
wireless card, there is a solution that works today. Simply use the
Cisco MPI 350 mini-pci card instead, which *is* a supported card and
works just fine with the T40p. The Cisco 350 wireless card is much
better than most generic Prism-2 cards anyway, since they support LEAP
(802.1x wireless authentication and encryption) and have more a
powerful transmitter (100mW) and a more sensitive receiver that most
other 802.11 cards out there.
I recently purchased a T40p with my own money (it's not a company
laptop), and knowing that there was going to be problems with the
802.11 a/b wireless, I also purchased the Cisco 350 mini-pci wireless
card. The Cisco mini-PCI card was shipped separately from the laptop,
and so I had to install it myself (which required partial disassembly
of my laptop, and the use of a security torx driver, but any competent
hardware hacker shouldn't have a problem with it). That means that I
still have the 802.11a/b mini-pci card, saved away for the day when a
driver might become available for it.
You can download the mpi350.c driver from the Cisco web page, and I
was able to drop it into a 2.4 Linux kernel tree and build it. For
more details please see http://thunk.org/tytso/linux/t40.html.
- Ted
Ted,
This is an amazingly sub-optimal solution, and will make running Linux on the
T40/X31 prohibitively difficult for most linux users. Do you want everyone
to use Linux? Then tell IBM to let them use wifi cards that are easy to use,
and support standard (and open) APIs.
(Ted)
> If the goal is simply to let a T40p laptop work with an internal
> wireless card, there is a solution that works today. Simply use the
> Cisco MPI 350 mini-pci card instead, which *is* a supported card and
> works just fine with the T40p.
(my stock answer to the _many_ who have asked me:)
... so, in short yes, I'm supporting 802.11b wifi on T40 and X31 via the Cisco
cards with backdated firmwares, and the Cisco ACU/bcard utils.
Of course this is _far_ from optimal, in that:
1) the Cisco cards must be setup by a closed-source app (then don't conform to
the Linux wireless-tools API (Wireless Extension)). Anyone here who has used
"acu" and "bcard" can step in...
2) newer Cisco cards have firmwares _so_ new, you have to boot into _windows_
to flash then back to a linux-friendly firmware. The new firmware (5th rev?)
will lock the system on "modprobe mpi350", you need to get back to the 50003
firmware. Cisco cards with firmware ver. 50001, 50003, 50220, 52017 are all
revertable in our testing. (That is Linux can load mpi350.o, so you can use
"acu" to backdate the firmware). Cisco and IBM are both now shipping mpi350
cards with a new firmware that causes the load of mpi350 to _lock_ the
system.
3) the user of Linux on a T40 or X31 will not get any choice as to which WiFi
card (s)he uses. Cisco is the only way to go, and its a damn hard way.
4) 2+3 == So, some poor sap who got a T40, but wanted to hold off on the wifi,
and he was dedicated enough to go 100% Linux, will be in a no-wifi-ever
corner (since he can't flash the firmware ...) and can't go prism2... Thanks
IBM!
5) IBM's BIOS policy of not allowing wifi cards not on their "white list" to
be in the system at boot time is a very bad thing for the Linux community.
(Ted)
> You can download the mpi350.c driver from the Cisco web page, and I
> was able to drop it into a 2.4 Linux kernel tree and build it. For
> more details please see http://thunk.org/tytso/linux/t40.html.
And just for the record, yes mpi350 drops in easily, but watch out that you
don't modprobe it with the newer firmwares, Also for the record, "ACU"
totally sucks, and "bcard" is little better.
And all these nice Linux geeks aren't happy either:
(Jimmy Leung)
> Hello Lincoln, I found your posting on google regarding your T40 & wireless
> card conflict... I was curious if you were ever able to find a fix? I am
> in somewhat the same dilemma. I purchased 2 intel wireless minipci cards
> only to find my T40 refuses to boot up unless it's an true IBM option/Intel
> card or an IBM option/Cisco card.
("McKinney, Chuck")
> Did you ever find an answer for this problem.
> I just bought one of these cards for my T40 and I get the same error.
(David Louis Richmond @ Harvard)
> I saw your LKML posting [1][2] on the IBM T40 bios refusing to boot with
> "unauthorized" wifi minipci cards thanks to a google search; I'm
> experiencing precisely the same issue myself.
("Mike Hampele")
> Just reading your posts about the 1802 errors.
> Did you manage to get any workarounds to this?
-- Lincoln @ EmperorLinux
On Llu, 2003-07-07 at 19:12, Lincoln D. Durey wrote:
> Ted,
>
> This is an amazingly sub-optimal solution, and will make running Linux on the
> T40/X31 prohibitively difficult for most linux users. Do you want everyone
> to use Linux? Then tell IBM to let them use wifi cards that are easy to use,
> and support standard (and open) APIs.
You don't have to buy IBM products. Dunno what local prices are like but
over here Comaq^WHP's come in at about two per thinkpad on price and do
work once you have all the ACPI stuff set up
On Tue, Jul 08, 2003 at 03:02:31PM +0100, Alan Cox wrote:
> On Llu, 2003-07-07 at 19:12, Lincoln D. Durey wrote:
> > Ted,
> >
> > This is an amazingly sub-optimal solution, and will make running Linux on the
> > T40/X31 prohibitively difficult for most linux users. Do you want everyone
> > to use Linux? Then tell IBM to let them use wifi cards that are easy to use,
> > and support standard (and open) APIs.
>
> You don't have to buy IBM products. Dunno what local prices are like but
> over here Comaq^WHP's come in at about two per thinkpad on price and do
> work once you have all the ACPI stuff set up
Some of them have issues with PCI resource allocation though. Their BIOSes
don't allocate resources to Cardbus bridges so insertted devices can't get
resources and last i checked, we didn't handle this fixup. On the notebooks
I worked with it required relocating the AGP bridge and several other devices
to make all the resources work out (quick hack is to just shove new resources
into the config registers prior to the kernel's initial pci scan).
-- Gerald
On Maw, 2003-07-08 at 16:20, Gerald Britton wrote:
> Some of them have issues with PCI resource allocation though. Their BIOSes
> don't allocate resources to Cardbus bridges so insertted devices can't get
> resources and last i checked, we didn't handle this fixup.
Thats actually a Linux bug.
> On the notebooks I worked with it required relocating the AGP bridge and several other devices
> to make all the resources work out (quick hack is to just shove new resources
> into the config registers prior to the kernel's initial pci scan).
Interesting. I wonder why our fixup would have failed - its not something I've
seen but we should fixup cardbus resource blocks (2.4 isnt smart enough to
handle multidevice cardbus but Rmk has 2.5 code that is), but for the normal
case it ought to have worked.
On Tue, Jul 08, 2003 at 04:42:30PM +0100, Alan Cox wrote:
> On Maw, 2003-07-08 at 16:20, Gerald Britton wrote:
> > Some of them have issues with PCI resource allocation though. Their BIOSes
> > don't allocate resources to Cardbus bridges so insertted devices can't get
> > resources and last i checked, we didn't handle this fixup.
>
> Thats actually a Linux bug.
>
> > On the notebooks I worked with it required relocating the AGP bridge and
> > several other devices to make all the resources work out (quick hack is to
> > just shove new resources into the config registers prior to the kernel's
> > initial pci scan).
>
> Interesting. I wonder why our fixup would have failed - its not something I've
> seen but we should fixup cardbus resource blocks (2.4 isnt smart enough to
> handle multidevice cardbus but Rmk has 2.5 code that is), but for the normal
> case it ought to have worked.
Is it smart enough to handle a case like this:
[device resource 00-01]
[bridge resource 01-04]
[device resource 01-02]
[cardbus bridge no resources]
[cardbus bridge no resources]
[device resource 02-04]
[bridge resoruce 04-06]
[device resource 04-06]
[device resource 06-07]
Numbers simplified for example purposes. The cardbus bridges are behind a
PCI-PCI bridge, and in this case, that bridge's resources need to be expanded
to allow the cardbus cards to have any resources since it's already full.
and the top level devices will need to be moved to allow space for the bridge
to expand. Glancing through the 2.5 pci init for i386 it doesn't look like it
does things differently from 2.4. IIRC, it's smart enough to handle things
if the cardbus bridge is at the top level (we allocate when the cardbus bridge
driver is loaded), but this will fail if it cannot allocate it (as is the case
when it's behind a full bridge).
-- Gerald
On Tue, Jul 08, 2003 at 01:24:17PM -0400, Gerald Britton wrote:
> On Tue, Jul 08, 2003 at 04:42:30PM +0100, Alan Cox wrote:
> > Interesting. I wonder why our fixup would have failed - its not something
> > I've seen but we should fixup cardbus resource blocks (2.4 isnt smart
> > enough to handle multidevice cardbus but Rmk has 2.5 code that is), but
> > for the normal case it ought to have worked.
The x86 pci setup stuff is something I'm not completely certain about
since it is handled in a different way from the "normal" (from my point
of view at least) PCI code.
However, I do have some outstanding patches which clean up the init and
resource stuff but unfortunately break it on x86. For everything to
work as expected, I'd like x86 and whatever other architectures either
handle this in the core pci code, or the architecture specific code.
I see this as a quirk of x86 platforms.
(Architectures which do a full setup of the bus in the kernel set the
cardbus bridge up as part of their normal setup.)
> Is it smart enough to handle a case like this:
>
> [device resource 00-01]
> [bridge resource 01-04]
> [device resource 01-02]
> [cardbus bridge no resources]
> [cardbus bridge no resources]
> [device resource 02-04]
> [bridge resoruce 04-06]
> [device resource 04-06]
> [device resource 06-07]
Definitely not yet, since x86 has a policy of not reallocating anything
at all. I suspect getting it to handle it will open a huge live mine
field, full of SMI ports. 8(
Any x86 PCI gurus got any ideas?
--
Russell King ([email protected]) The developer of ARM Linux
http://www.arm.linux.org.uk/personal/aboutme.html
Russell King wrote:
> Definitely not yet, since x86 has a policy of not reallocating anything
> at all. I suspect getting it to handle it will open a huge live mine
> field, full of SMI ports. 8(
>
> Any x86 PCI gurus got any ideas?
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.
Ok, it's flailing a bit...
-- Jamie
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