LKML Archive on lore.kernel.org
help / color / mirror / Atom feed
From: Robert Hancock <hancockr@shaw.ca>
To: Daniel Yeisley <dan.yeisley@unisys.com>,
linux-kernel <linux-kernel@vger.kernel.org>
Cc: Greg KH <gregkh@suse.de>
Subject: Re: [PATCH] I/O space boot parameter
Date: Wed, 21 Mar 2007 17:21:55 -0600 [thread overview]
Message-ID: <4601BE13.1080500@shaw.ca> (raw)
In-Reply-To: <fa.YYUCGI1tr2Apb+hF3LEwyIhLDPM@ifi.uio.no>
Daniel Yeisley wrote:
>> Ah. Others are working on providing a fix for this too, but it is being
>> done in the drivers themselves, not in the pci core. Look in the
>> linux-pci mailing list archives for those patches (I don't think they
>> every went into mainline for some reason, but I might be wrong...)
>>
>> I suggest you work with those developers, as they have the same issue
>> that you are trying to solve here.
>>
>
> I have seen some patches that make the drivers I/O port free here:
> http://lkml.org/lkml/2006/2/26/261
>
> I checked and they still aren't in the mainline.
>
> I don't know that it matters though because I see all the disks attached
> to the system regardless of whether or not the adapters get I/O space.
> The real issue I have is with all the error messages I get at boot. I
> see 40+ messages that say "PCI: Failed to allocate I/O
> resource..." (from setup-res.c) when the kernel tries to allocate the
> I/O space and can't. The modules load fine. I see all the disks just
> fine. But that many error messages tends to raise concerns and causes
> support calls from customers.
I don't think this can be handled entirely at the driver level. Assuming
that the IO regions get allocated at bootup, and there's not enough
space for all devices' IO space to fit, there's no guarantee that the
ones that didn't fit are the ones where using the IO space is optional,
and so you could end up with some broken devices.
I suppose you could handle this by assigning the devices who had no
space assigned by the BIOS last, so that we wouldn't try to assign those
until we'd already assigned everything else..
--
Robert Hancock Saskatoon, SK, Canada
To email, remove "nospam" from hancockr@nospamshaw.ca
Home Page: http://www.roberthancock.com/
next parent reply other threads:[~2007-03-21 23:25 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <fa.GB583YHCocLIeymeVam9mpGF9CI@ifi.uio.no>
[not found] ` <fa.QhX1j7epBXZBOc8pKi+Kk+1Ry2o@ifi.uio.no>
[not found] ` <fa.236bWOhrGT0j4UCxsmp32/n8NCo@ifi.uio.no>
[not found] ` <fa.5exuGSZI65YO9pz/5yzd/gtgBJI@ifi.uio.no>
[not found] ` <fa.YYUCGI1tr2Apb+hF3LEwyIhLDPM@ifi.uio.no>
2007-03-21 23:21 ` Robert Hancock [this message]
2007-03-20 16:18 Daniel Yeisley
2007-03-20 18:00 ` Greg KH
2007-03-20 17:25 ` Daniel Yeisley
2007-03-20 20:26 ` Greg KH
2007-03-21 13:37 ` Daniel Yeisley
2007-03-21 23:57 ` Greg KH
2007-03-22 15:08 ` Daniel Yeisley
2007-03-20 20:05 ` Eric W. Biederman
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=4601BE13.1080500@shaw.ca \
--to=hancockr@shaw.ca \
--cc=dan.yeisley@unisys.com \
--cc=gregkh@suse.de \
--cc=linux-kernel@vger.kernel.org \
--subject='Re: [PATCH] I/O space boot parameter' \
/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
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).