Re: Loading drivers via kldload
- From: Andriy Gapon <avg@xxxxxxxxxxx>
- Date: Tue, 16 Aug 2011 22:12:47 +0300
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
Maybe it doesn't do that exactly because device and vendor ID are zeroes as David
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.
freebsd-current@xxxxxxxxxxx mailing list
To unsubscribe, send any mail to "freebsd-current-unsubscribe@xxxxxxxxxxx"
- Prev by Date: Re: Loading drivers via kldload
- Next by Date: Re: gptzfsboot error using HP Smart Array P410i Controller
- Previous by thread: Re: Loading drivers via kldload
- Next by thread: upgrade to 9.0-BETA1 with geom_mirror fails