Date: Sun, 04 Jan 2004 01:06:17 -0700 (MST) From: "M. Warner Losh" <imp@bsdimp.com> To: nate@root.org Cc: jhb@FreeBSD.org Subject: Re: Power Patches Message-ID: <20040104.010617.103670865.imp@bsdimp.com> In-Reply-To: <20040102151458.P10254@root.org> References: <200401022034.i02KYt7E002661@gw.catspoiler.org> <20040102151458.P10254@root.org>
next in thread | previous in thread | raw e-mail | index | archive | help
In message: <20040102151458.P10254@root.org>
Nate Lawson <nate@root.org> writes:
: I get a panic on my T23 due to the ATA driver not being detected so no
: rootvp. Attached are dmesg both before and after the patch. The cbb0
: issue is a regression since I have specified it to use an unused IO range
: via this tunable (the same range Windows uses):
:
: hw.cbb.start_memory=0xc0203000
:
: I commented out that tunable while testing the power kernel.
Yes. I think I understand why unsupported ranges is needed for some
bridges and not others.
We need to learn about subtractive decoders in pci_pci.c, which is
what I'm working on. Subtractive decoders should allow allocations
through mostly untouched. If the range of the nominally decoded area
is a subset of the requested range, however, we should clip it. If it
isn't a superset, then it should pass through w/o molestation. This
should allow things to work w/o these ugly hacks. It gives people
that don't care (0, ~0) a sensible range, while allowing the BIOS to
preallocate 'weird' locations for the cardbus bridge. Linux recently
grew this ability and more recently got the Intel mobile quirks:
/*
* For some reasons Intel decided that certain parts of their
* 815, 845 and some other chipsets must look like PCI-to-PCI bridges
* while they are obviously not. The 82801 family (AA, AB, BAM/CAM,
* BA/CA/DB and E) PCI bridges are actually HUB-to-PCI ones, according
* to Intel terminology. These devices do forward all addresses from
* system to PCI bus no matter what are their window settings, so they are
* "transparent" (or subtractive decoding) from programmers point of view.
*/
This quirk is what we need to implement. Most of the pciconf dumps
people have sent me have these parts in common and it wasn't until I
went searching for information about them that I ran across a very
extensive discussion about the issues which happened a few months ago.
Of course, this explains what I thought was unexplainable: how a
non-subtractive bridge could pass cycles. It really is a subtractive
one, it just lies in its ProgIf.
In addition, I'm starting to think that the cardbus bridge might want
to reserve a certain amount of resources for possible children. This
would obviate the need for the start_memory tunable as well (or at
least make it a footnote rather than a checklist item in
troubleshooting). However, this issue is orthogonal to the other
issues and can be dealt with on its own.
At some point we'll also have to deal with bus numbering too. I have
a machine (my FIVA) that has no working cardbus as all, and I've had
at least one other report of this on a new DELL laptop.
: One thing you should fix is calling the acpi set methods with a NULL
: pointer:
:
: pci2: Failed to set ACPI power state D3 on (null): AE_BAD_PARAMETER
:
: You should probably just skip the call to the acpi set power state if it's
: null.
I didn't write that part of the code. It exists solely in the p4
power tree. It isn't in my p4 newcard tree. I suspect that null
functions shouldn't be called. I also hope that integrating it into
my newcard tree will make my dell happier on suspend/resume (right now
it really really cranky when I suspend/resume). I'll look into fixing
it if someone else doesn't beat me to it.
Despite the negative reports, the testing has been good in a number of
ways.
Warner
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20040104.010617.103670865.imp>