cvs commit: src/sys/dev/acpica acpi.c

[Nate Lawson]

John Baldwin wrote:
> On Wednesday 25 April 2007 05:47:47 pm Nate Lawson wrote:
>> Nate Lawson wrote:
>>> John Baldwin wrote:
>>>> jhb         2007-04-25 16:22:18 UTC
>>>>
>>>>   FreeBSD src repository
>>>>
>>>>   Modified files:
>>>>     sys/dev/acpica       acpi.c 
>>>>   Log:
>>>>   Use a tighter check to see if a resource allocation request is for a
>>>>   specific request and thus should first try to be allocated from the
>>>>   sys_resource pool.  This avoids using the sys_resource pool for 
> wildcard
>>>>   requests that have bounded ranges coming from cbb(4) and Host-PCI 
> pcib(4)
>>>>   drivers.
>>>>   
>>>>   Tested by:      Andrea Bittau <a.bittau of cs.ucl.ac.uk fame>
>>>>   Sleuthing by:   Andrea Bittau as well
>>>>   
>>>>   Revision  Changes    Path
>>>>   1.235     +1 -1      src/sys/dev/acpica/acpi.c
>>> I think I'll test this to see if it helps my via 8235 ata survive boot.
>> Yay, my laptop now boots with this change.  Thanks!
>>
>> BTW, I've been thinking about sysres issues in general.  One is that 
>> sometimes ACPI tables define regions that are actually split with nexus. 
>>   Would it make sense to change rman to have a split model where if a 
>> request can be partially satisfied by this pool and a parent pool, we 
>> can split the request while returning a struct resource *?  struct 
>> resource would probably have to be changed to allow a linked list of 
>> internal storage with pointers to parent pools.
>>
>> What do you think?
> 
> Those allocations should fail.  You shouldn't have a single resource cross 
> both a fixed-address system-resource and a variable "free" address.

Tell that to the BIOS authors that got it wrong.  A lot of it is
off-by-one errors that the Windows AML interpreter (2K or below) once
allowed.  We're not like MS in terms of being able to qualify hardware
before people run our OS on it.  7-current is still running on machines
from the 90's.

I'm not sure how prevalent this is so I'm ok with finding an example
before attacking the problem.

-- 
Nate