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. 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 ============= Source Code ======== //#includes deleted // file: qla_os.c static int qla_pci_probe (device_t); static int qla_pci_attach (device_t); static int qla_pci_detach (device_t); static device_method_t qla_pci_methods[] = { /* Device interface */ DEVMETHOD(device_probe, qla_pci_probe), DEVMETHOD(device_attach, qla_pci_attach), DEVMETHOD(device_detach, qla_pci_detach), { 0, 0 } }; static driver_t qla_pci_driver = { "qltest", qla_pci_methods, sizeof (uint64_t), }; static devclass_t qla_devclass; MODULE_VERSION(qltest, 1); DRIVER_MODULE(qltest, pci, qla_pci_driver, qla_devclass, 0, 0); char dev_str[50]; /* * Name: qla_pci_probe */ static int qla_pci_probe(device_t dev) { int i; // I put call to panic() here and // it did not get invoked when Subsytem Vendor/DeviceIDs were zeros switch ((pci_get_device(dev) << 16) | (pci_get_vendor(dev))) { case ((QLA_PCI_DEVICEID << 16) | 0x1077): sprintf(dev_str, "%s ","Qlogic Adapter"); device_set_desc(dev, dev_str); break; default: device_printf(dev, "%s: Invalid Device[0x%04x: 0x%04x]\n", __func__, pci_get_vendor(dev), pci_get_device(dev)); return (ENXIO); } return (0); } static int qla_pci_attach(device_t dev) { device_printf(dev, "%s: called\n", __func__); return 0; } static int qla_pci_detach(device_t dev) { device_printf(dev, "%s: called\n", __func__); return (0); } ============= Makefile ============= KMOD=qltest SRCS=qla_os.c SRCS+= device_if.h bus_if.h pci_if.h clean: rm -f opt_bdg.h device_if.h bus_if.h pci_if.h export_syms rm -f *.o *.kld *.ko rm -f _at_ machine .include <bsd.kmod.mk> ============ Thanks david S. -----Original Message----- From: Stanislav Sedov [mailto:stas_at_FreeBSD.org] Sent: Thursday, August 11, 2011 11:48 PM To: David Somayajulu Cc: freebsd-current_at_freebsd.org Subject: Re: Loading drivers via kldload On Thu, 11 Aug 2011 17:08:30 -0700 David Somayajulu <david.somayajulu_at_qlogic.com> mentioned: > Hi All, > While loading PCIe based HBA drivers via kldload, does FreeBSD expect a valid (i.e., non-zero) PCI subsystem Vendor and Device IDs? > It depends on the specific driver. FreeBSD doesn't check for the PCI ID in general. Usually, drivers contains a routine that check if this driver can be used with that hardware based on the PCI ID. -- Stanislav Sedov ST4096-RIPE () ascii ribbon campaign - against html e-mail /\ www.asciiribbon.org - against proprietary attachments This message and any attached documents contain information from QLogic Corporation or its wholly-owned subsidiaries that may be confidential. If you are not the intended recipient, you may not read, copy, distribute, or use this information. If you have received this transmission in error, please notify the sender immediately by reply e-mail and then delete this message.Received on Fri Aug 12 2011 - 19:20:30 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:40:16 UTC