Loading drivers via kldload

[Andriy Gapon]

on 16/08/2011 22:09 John Baldwin said the following:
> On Tuesday, August 16, 2011 12:26:11 pm Andriy Gapon wrote:
>>
>> The following are pure speculations, I'd rather let David speak, but just in case;
>>
>> on 16/08/2011 18:45 John Baldwin said the following:
>>> Well, that would seem odd, still.  It only returns BUS_PROBE_GENERIC (not 0), so
>>> David's driver's probe routine should still be called to get a chance to attach to
>>> the device.
>>
>> Maybe it doesn't do that exactly because device and vendor ID are zeroes as David
>> described earlier.
> 
> Eh?  device_probe_and_attach()'s loop to probe drivers is not PCI-specific, it
> has no idea if a given device is PCI device or not let alone if it has non-zero
> subvendor IDs.  Also, ata_pci_probe() doesn't look at the subvendor IDs at all.
> 
>>> Also, the ATA driver only allocates its BAR once, so it shouldn't
>>> trigger the panic in question in that case (the panic is only triggered when you
>>> try to double-allocate a BAR).
>>
>> This makes only if the BAR has sane values.  Not sure what happens if the BAR has
>> some junk that duplicates other PCI device, or something like that.
> 
> The panic in question is due to a resource that was reserved by the parent
> bus (i.e. either ACPI or PCI) using resource_list_reserve(), then a driver
> called resource_list_alloc() on it once successfully, and
> resource_list_alloc() is being called a second time to allocate an already-
> allocated resource.  That won't happen due to junk in a BAR (and BARs are
> all standard config header registers anyway).
> 

Thanks for straightening me on both accounts.

-- 
Andriy Gapon