From: "Yu, Luming" <luming.yu@intel.com>
To: linux-ia64@vger.kernel.org
Subject: RE: Latest 2.4 IA64 Baseline (Bjorn) + Latest ACPI testing report
Date: Tue, 16 Dec 2003 09:37:35 +0000 [thread overview]
Message-ID: <marc-linux-ia64-107156747626547@msgid-missing> (raw)
In-Reply-To: <marc-linux-ia64-106863619315583@msgid-missing>
>> > >> 3.alloc 0x0-0xcf7 from PCI IO for PCI Bus 00:00 failed (Known issue)
>> >
>> > Since VGA console driver faile to allocate that port range, why it still can work?
>> > Does it mean 0x3c0-0x3df is inessential to VGA console driver.
>>
>> No, I think those ports are essential. The driver just uses them,
>> even if the allocation fails. I have a 2.6 patch that cleans this
>> up. It doesn't change any functionality; it just gets rid of the
>> message and makes /proc/ioports more correct. I'll submit it as
>> soon as it makes sense to put non-critical changes into 2.6.
>I didn't answer this quite right. The VGA driver allocates ports
>0x3c0-0x3df early, and that allocation succeeds. Later, we
>discover the PCI root bridges, and try to allocate the port ranges
>for each. It's the PCI root bridge allocation that fails, because
>it's trying to allocate a range that includes the VGA ports.
>So we end up with something like this in /proc/ioports (this is a
>made-up example, but same idea):
>
> 000003c0-000003df : vga+
> 00004000-00009fff : PCI Bus 00:00
> 00004000-000040ff : sym53c8xx
> 00004100-000041ff : sym53c8xx
>
>when we should have this:
>
> 00000000-00000cf7 : PCI Bus 00:00
> 000003c0-000003df : vga+
> 00004000-00009fff : PCI Bus 00:00
> 00004000-000040ff : sym53c8xx
> 00004100-000041ff : sym53c8xx
>
>The patch just changes the PCI root bridge allocation so that
>instead of failing if part of the range has already been allocated,
>it inserts a new range up one level, so it encloses the previous
>VGA allocation.
Could you let me see what are you patch doing.
I think "To bus device, resources returned from _CRS method means that bus device will
supply those resouces to its children devices. So it's unreasonable to call
request_resource for them."
I have a patch for above statement. Please take http://bugzilla.kernel.org/show_bug.cgi?id\x1685 a look.
Thanks,
Luming
next prev parent reply other threads:[~2003-12-16 9:37 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2003-11-12 11:22 Latest 2.4 IA64 Baseline (Bjorn) + Latest ACPI testing report Yu, Luming
2003-11-19 13:08 ` Yu, Luming
2003-11-20 0:33 ` Bjorn Helgaas
2003-11-20 3:28 ` Matthew Wilcox
2003-11-20 17:09 ` Bjorn Helgaas
2003-11-20 17:29 ` Luck, Tony
2003-12-10 10:29 ` Yu, Luming
2003-12-11 0:34 ` Bjorn Helgaas
2003-12-11 19:32 ` Bjorn Helgaas
2003-12-16 9:37 ` Yu, Luming [this message]
2003-12-16 12:17 ` Matthew Wilcox
2003-12-16 16:23 ` Bjorn Helgaas
2003-12-17 2:54 ` Yu, Luming
2003-12-17 3:07 ` Yu, Luming
2003-12-17 12:23 ` Matthew Wilcox
2003-12-18 2:42 ` Yu, Luming
2003-12-18 12:14 ` Matthew Wilcox
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=marc-linux-ia64-107156747626547@msgid-missing \
--to=luming.yu@intel.com \
--cc=linux-ia64@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.