2.6.0 aic7xxx and aic79xx stale pci_device list entry

Loading the aic7xxx or aic79xx modules, on a machine that did not contain the card, left a stale entry in the pci_device list. This caused an oops upon loading the next module that registered a pci_device.

The patches below will unregister the pci_device if it successfully registers the device, but does not find any cards.

Comments are appreciated.

Quoted 8 lines · Eric Kerin

Loading the aic7xxx or aic79xx modules, on a machine that did not contain the card, left a stale entry in the pci_device list. This caused an oops upon loading the next module that registered a pci_device.

The patches below will unregister the pci_device if it successfully registers the device, but does not find any cards.

Quoted 1 line

Comments are appreciated.

well in 2.6 modules are supposed to remain loaded even though no device is found (since one can be hotplugged later) so that part of the driver needs changing; other than that yes the driver needs to deregister itself....

Quoted 9 lines · Arjan van de Ven

Quoted 8 lines · Eric Kerin

Loading the aic7xxx or aic79xx modules, on a machine that did not contain the card, left a stale entry in the pci_device list. This caused an oops upon loading the next module that registered a pci_device.

The patches below will unregister the pci_device if it successfully registers the device, but does not find any cards.

Quoted 6 lines

Quoted 1 line

Comments are appreciated.

well in 2.6 modules are supposed to remain loaded even though no device is found (since one can be hotplugged later) so that part of the driver needs changing; other than that yes the driver needs to deregister itself....

Here's a new patch, now it will leave the module loaded if it successfully registers the pci device.

Eric Kerin

aic7xxx_osm.c renamed from aic7xxx_osm.c.original +7 -1

@@ -844,6 +844,7 @@ ahc_linux_detect(Scsi_Host_Template *tem
 {
 	struct	ahc_softc *ahc;
 	int     found;
+	int	pci_reg_state;
 
 #if LINUX_VERSION_CODE < KERNEL_VERSION(2,5,0)
 	/*

@@ -891,8 +892,9 @@ ahc_linux_detect(Scsi_Host_Template *tem
 	 */
 	ahc_list_lockinit();
 
+	pci_reg_state = -1;
 #ifdef CONFIG_PCI
-	ahc_linux_pci_init();
+	pci_reg_state = ahc_linux_pci_init();
 #endif
 
 #ifdef CONFIG_EISA

@@ -913,6 +915,10 @@ ahc_linux_detect(Scsi_Host_Template *tem
 	spin_lock_irq(&io_request_lock);
 #endif
 	aic7xxx_detect_complete++;
+	if(pci_reg_state == 0 && found == 0){
+		return(1); 
+	}
+
 	return (found);
 }
 

aic79xx_osm.c renamed from aic79xx_osm.c.original +7 -1

@@ -856,6 +856,7 @@ ahd_linux_detect(Scsi_Host_Template *tem
 {
 	struct	ahd_softc *ahd;
 	int     found;
+	int	pci_reg_state;
 
 #if LINUX_VERSION_CODE < KERNEL_VERSION(2,5,0)
 	/*

@@ -906,8 +907,9 @@ ahd_linux_detect(Scsi_Host_Template *tem
 	 */
 	ahd_list_lockinit();
 
+	pci_reg_state = -1;
 #ifdef CONFIG_PCI
-	ahd_linux_pci_init();
+	pci_reg_state = ahd_linux_pci_init();
 #endif
 
 	/*

@@ -924,6 +926,10 @@ ahd_linux_detect(Scsi_Host_Template *tem
 	spin_lock_irq(&io_request_lock);
 #endif
 	aic79xx_detect_complete++;
+	if(pci_reg_state == 0 && found == 0){
+		return(1); 
+	}
+
 	return (found);
 }
 

well in 2.6 modules are supposed to remain loaded even though no device is found (since one can be hotplugged later) so that part of the driver needs changing; other than that yes the driver needs to deregister itself....

Quoted 4 lines

well in 2.6 modules are supposed to remain loaded even though no device is found (since one can be hotplugged later) so that part of the driver needs changing; other than that yes the driver needs to deregister itself....

Is this policy change documented somewhere?

<snip the rest>
-----------------

There are 2 reasons to work this way, and I would very much prefer the adaptec drivers to behave like this:
1) PCI Hotplugging
2) Adding PCI ID's at runtime

While you may not care about 1), a lot of IHV/distros care about 2); eg if Adaptec puts out a card that can be driven by aic79xx but with just a new PCI ID, hardware vendors can just add the ID at runtime and have it work in the (factory) installer etc but only *if the driver is loaded* ....

Quoted 8 lines

<snip the rest>
-----------------

There are 2 reasons to work this way, and I would very much prefer the adaptec drivers to behave like this:
1) PCI Hotplugging
2) Adding PCI ID's at runtime

Quoted 4 lines

While you may not care about 1), a lot of IHV/distros care about 2); eg if Adaptec puts out a card that can be driven by aic79xx but with just a new PCI ID, hardware vendors can just add the ID at runtime and have it work in the (factory) installer etc but only *if the driver is loaded* ....

Well, if you look at the Adaptec drivers, they already attach to all possible IDs for the chips that are supported. They do this by registering a very generic PCI ID table and filtering all requests through their own tables.

Quoted 4 lines

Well, if you look at the Adaptec drivers, they already attach to all possible IDs for the chips that are supported. They do this by registering a very generic PCI ID table and filtering all requests through their own tables.

May I ask why this is done?

It sounds not the right thing that needs all
kinds of special cases in the OS userland...

Loading the aic7xxx or aic79xx modules, on a machine that did not contain the card, left a stale entry in the pci_device list. This caused an oops upon loading the next module that registered a pci_device.

The patches below will unregister the pci_device if it successfully registers the device, but does not find any cards.

Comments are appreciated.