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: 1. 2. 3. Actual Results: Expected Results: Additional Information:
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 ;(
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 anyhow. 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 [c.pascoe.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. */ /* Regards, Chris
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.