Bug 58635 - RFE: kernel RPM script to remove option aacraid lines from modules.conf
Summary: RFE: kernel RPM script to remove option aacraid lines from modules.conf
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: kernel   
(Show other bugs)
Version: 7.2
Hardware: i386 Linux
Target Milestone: ---
Assignee: Arjan van de Ven
QA Contact: Brian Brock
Keywords: FutureFeature
Depends On:
TreeView+ depends on / blocked
Reported: 2002-01-21 22:49 UTC by Matt Domsch
Modified: 2007-04-18 16:39 UTC (History)
0 users

Fixed In Version:
Doc Type: Enhancement
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2002-01-22 14:26:07 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

Description Matt Domsch 2002-01-21 22:49:27 UTC
Description of Problem:
With Red Hat Linux 7.2, kernels 2.4.7-10, 2.4.9-7, 2.4.9-13 (and the kernel in 
rawhide, 2.4.9-20), there's the option and ability for the aacraid driver to be 
passed a parameter specifying new PCI IDs to load on.  Problem is, (this is 
unconfirmed, but I highly suspect it'll break), if the PCI IDs are later added 
to the driver, but not removed as an option line from modules.conf, the driver 
will try to load on the same device twice.  Bad.

I'd like the kernel SRPM, in %post (for all sections) to comment out lines like:
options aacraid aacraid_pciid=%x,%x,%x,%x
for cases where new device IDs have been added to the driver proper, so they no 
longer need to be added via an options line.

The two in specific that 2.4.9-20 have that the earlier kernels don't are:
PE1650(Dagger)		0x1028,0x0A,0x1028,0x011B
PE2650(Boxster)		0x1028,0x0A,0x1028,0x0121

These two platforms are shipping in Feb. and March respectively.

We had similar logic in the 2.2.x-based kernels when aacraid first went open-
source to change {perc|hpn}raid -> aacraid. That's where I would have expected 
to put this change also, but that's since been dropped from the kernel SRPM I 
see. :-(

Version-Release number of selected component (if applicable):

How Reproducible:

Steps to Reproduce:

Actual Results:

Expected Results:

Additional Information:

Comment 1 Arjan van de Ven 2002-01-22 14:06:30 UTC
It's not quite dropped, but made more generic. In the 2.2 -> 2.4 migration
several drivers changed name, so there is a /usr/sbin/module_upgrade script that
converts modules.conf driver names....
How to strip such options is a different matter though; the PCI ones shouldn't
have actually existed in the first place ;(

Comment 2 Matt Domsch 2002-01-22 14:26:01 UTC
We didn't have a choice - the hardware teams didn't set their PCI IDs until 
*after* the 7.2 kernel went gold - and we needed *something* to let us install 

I'm going to write up a patch against Alan's driver that, when options are 
passed, the table is scanned to see if it's a duplicate, and then warn and not 
use as an option.  Can you hold off on any errata kernel release till I can get 
this done today?

BTW - received a test patch (but probably correct) from Chris Pascoe which 
solves the 150,000 interrupts/sec problem on ROMBs.  I append it below.  We're 
going to test this today too.

From: Chris Pascoe [mailto:c.pascoe@itee.uq.edu.au]
Sent: Tuesday, January 22, 2002 6:58 AM

Hi Alan,

The problem with millions of interrupts being generated by the aacraid
driver on some hardware is caused by reversed arguments to time_before in
rx_sync_cmd.  This causes every synchronous command sent to the controller
to miss acknowledgement, including our one to start the adapter.  When
interrupts are subsequently re-enabled, we get a continuous stream of
interrupts as the command has actually completed, and there is no path in
aac_rx_intr to acknowledge the command.

The following patch corrects the described problem.

--- linux/drivers/scsi/aacraid/rx.c.orig	Tue Jan 22 22:40:58 2002
+++ linux/drivers/scsi/aacraid/rx.c	Tue Jan 22 22:41:19 2002
@@ -199,7 +199,7 @@
 	 *	Wait up to 30 seconds
-	while (time_before(start+30*HZ, jiffies))
+	while (time_before(jiffies, start+30*HZ))
 		udelay(5);	/* Delay 5 microseconds to let Mon960 get info. 


Comment 3 Matt Domsch 2002-01-22 15:21:06 UTC
The driver in 2.4.9-20 and above doesn't have (and likely won't ever need) the 
patch which implements MODULE_PARMs for passing in PCI IDs.  Since that driver 
already has all the PCI IDs that Dell cares about, I'm closing this RFE - it 
won't affect us.

Note You need to log in before you can comment on or make changes to this bug.