Re: Loading drivers via kldload

on 13/08/2011 00:20 David Somayajulu said the following:
> This is pretty bizarre. I have been experimenting with a very simple driver
> (see source below) which essentially checks the PCI vendor and Device ID's in
> the probe routine. The attach and detach are empty functions. When I run
> kldload and load the driver in a system with HBAs which have a valid Subsytem
> Vendor and Device ID's, the driver loads and attaches to the functions.
> 
> However when the Subsystem Vendor and Device ID's are zero, the system panics
> and the stack trace is as shown below(FreeBSD 8.2 on amd64 machine). I don't
> understand why ata_pci_attach() is getting invoked.

This is because ata_pci_probe returns BUS_PROBE_GENERIC for any pci device that
has PCIC_STORAGE class and PCIS_STORAGE_IDE subclass.  So I'd guess that it tries
to attach to your non-trivial hardware in this case and gets some incorrect
resource configuration (e.g. BARs) from the hardware.

Whether we actually have to panic in such situation is a different question.

> I even put a panic() call
> at the top of qla_pci_probe(), and noticed that it wasn't getting invoked!
> 
> 
> ============== panic: resource_list_alloc: resource_ entry is busy
> 
> 0xFFFFFFFF805F4E0E      at kdb_backtrace+0x5E 0xFFFFFFFF805C2D07      at
> panic+0x187 0xFFFFFFFF805F0616      at resource_list_alloc+0x1C6 
> 0xFFFFFFFF804450F7      at pci_alloc_resource+0x147 0xFFFFFFFF805F0439      at
> bus_alloc_resource+0x89 0xFFFFFFFF8027A467      at ata_pci_attach+0xE7 
> 0xFFFFFFFF805EEA09      at device_attach+0x69 0xFFFFFFFF80447ACA      at
> pci_driver_added+0xDA 0xFFFFFFFF805ECD55      at devclass_driver_added+0x75 
> 0xFFFFFFFF805EE715      at driver_module_handler+0x165 0xFFFFFFFF805B24B8
> at module_register_init+0xB8 0xFFFFFFFF805AADB6      at
> linker_load_module+0x996 0xFFFFFFFF805AB6C4      at kern_kldload+0xB4 
> 0xFFFFFFFF805AB894      at kldload+0x84 0xFFFFFFFF80600DD5      at
> syscallenter+0x1E5 0xFFFFFFFF808ACA5B      at syscall+0x4B 0xFFFFFFFF80895292
> at Xfast_syscall+0xE2

-- 
Andriy Gapon