Bug 4940 - Repeatable Kernel Panic on Adaptec 2015S I20 device on bootup
Repeatable Kernel Panic on Adaptec 2015S I20 device on bootup
Status: CLOSED CODE_FIX
Product: Drivers
Classification: Unclassified
Component: I2O
i386 Linux
: P2 high
Assigned To: Alan
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2005-07-25 14:13 UTC by Joshua McClintock
Modified: 2006-01-13 10:56 UTC (History)
4 users (show)

See Also:
Kernel Version: 2.6.12.3
Tree: Mainline
Regression: ---


Attachments
Added request_region() call to find out if device is already in use (1.76 KB, patch)
2005-08-08 05:00 UTC, Markus Lidel
Details | Diff
Use pci_request_regions() instead of request_region() (1.17 KB, patch)
2005-08-08 06:30 UTC, Markus Lidel
Details | Diff
move pci_request_regions() just behind pci_enable_device() (1.57 KB, patch)
2006-01-11 23:49 UTC, Ryoji Kamei
Details | Diff
If the PCI device is enabled already don't disable it at failure (998 bytes, patch)
2006-01-13 10:56 UTC, Markus Lidel
Details | Diff

Description Joshua McClintock 2005-07-25 14:13:06 UTC
Distribution: Debian (custom kernel - source from kernel.org)
Hardware Environment: Dual board, single Xeon 2.6 proc
Software Environment:
Problem Description:  Kernel panic on every bootup

Steps to reproduce:  Boot machine

Here is the Kernel output:

Linux version 2.6.12.3 (root@graviton.krk0) (gcc version 3.3.5 (Debian
1:3.3.5-
)) #2 SMP Fri Jul 22 14:52:48 PDT 2005
BIOS-provided physical RAM map:
 BIOS-e820: 0000000000000000 - 000000000009e400 (usable)
 BIOS-e820: 000000000009e400 - 00000000000a0000 (reserved)
 BIOS-e820: 00000000000e0000 - 0000000000100000 (reserved)
 BIOS-e820: 0000000000100000 - 000000001fef0000 (usable)
 BIOS-e820: 000000001fef0000 - 000000001fef8000 (ACPI data)
 BIOS-e820: 000000001fef8000 - 000000001ff00000 (ACPI NVS)
 BIOS-e820: 000000001ff00000 - 000000001ff80000 (usable)
 BIOS-e820: 000000001ff80000 - 0000000
 BIOS-e820: 00000000fec00000 - 00000000fec10000 (reserved)
 BIOS-e820: 00000000fee00000 - 00000000fee01000 (reserved)
 BIOS-e820: 00000000ff800000 - 00000000ffc00000 (reserved)
 BIOS-e820: 00000000fff00000 - 0000000100000000 (reserved)
0MB HIGHMEM available.
511MB LOWMEM available.
found SMP MP-table at 000f6ca0
DMI present.
Intel MultiProcessor Specification v1.4
    Virtual Wire compatibility mode.
OEM ID:   Product ID: Kings Canyon APIC at: 0xFEE00000
Processor #0 15:2 APIC version 20
Processor #1 15:2 APIC ve
I/O APIC #2 Version 32 at 0xFEC00000.
I/O APIC #3 Version 32 at 0xFEC80000.
I/O APIC #4 Version 32 at 0xFEC80400.
Enabling APIC mode:  Flat.  Using 3 I/O APICs
Processors: 2
Allocating PCI resources starting at 20000000 (gap: 20000000:dec00000)
Built 1 zonelists
Kernel command line: vga=normal initrd=/install/initrd.gz
ramdisk_size=10240 roo
t=/dev/ram0 devfs=mount,dall rw -- BOOT_IMAGE=/install/vmlinuz
console=ttyS0,576
00
Initializing CPU#0
PID hash table entries: 2048 (order: 11, 32768 bytes)
Detected 2399.779
Using tsc for high-res timesource
Console: colour VGA+ 80x25
Dentry cache hash table entries: 131072 (order: 7, 524288 bytes)
Inode-cache hash table entries: 65536 (order: 6, 262144 bytes)
Memory: 505948k/523776k available (4467k kernel code, 17108k reserved,
2100k dat
a, 296k init, 0k highmem)
Checking if this processor honours the WP bit even in supervisor mode... Ok.
Security Framework v1.0.0 initialized
Capability LSM initialized
Mount-cache hash table entries: 512
CPU: Trace cache: 12K uops, L1 D cache: 8K
CPU: L2 cache: 512K
CPU: Physical Processor ID: 0
Enabling fast FPU save and restore... done.
Enabling unmasked SIMD FPU exception support... done.
Checking 'hlt' instruction... OK.
Checking for popad bug... OK.
CPU0: Intel(R) Xeon(TM) CPU 2.40GHz stepping 05
Booting processor 1/1 eip 2000
Initializing CPU#1
CPU: Trace cache: 12K uops, L1 D cache: 8K
CPU: L2 cache: 512K
CPU: Physical Processor ID: 0
CPU1: Intel(R) Xeon(TM) CPU 2.40GHz stepping 05
Total of 2 processors activated (9519.10 BogoMIPS).
ENABLING IO-APIC
..TIMER: vector=0x31 pin1=2 pin2=0
checking TSC synchronization across 2 CPUs: passed.
Brought up 2 CPUs
checking if image is initramfs...it isn't (no cpio magic); looks like an
initrd
Freeing initrd memory: 3874k freed
NET: Registered protocol family 16
PCI: PCI BIOS revision 2.10 entry at 0xfd8c5, last bus=4
PCI: Using configuration type 1
mtrr: v2.0 (20020519)
Linux Plug and Play Support v0.97 (c) Adam Belay
SCSI subsystem initialized
usbcore: registered new driver usbfs
usbcore: registered new driver hub
PCI: Probing PCI hardware
PCI: Probing PCI hardware (bus 00)
PCI: Ignoring BAR0-3 of IDE controller 0000:00:1f.1
PCI: Transparent bridge - 0000:00:1e.0
PCI: Discovered primary peer bus 10 [IRQ]
PCI: Discovered primary peer bus 11 [IRQ]
PCI: Discovered primary peer bus 12 [IRQ]
PCI: Using IRQ router PIIX/ICH [8086/2480] at 0000:00:1f.0
PCI->APIC IRQ transform: 0000:00:1d.0[A] -> IRQ 16
PCI->APIC IRQ transform: 0000:00:1d.1[B] -> IRQ 19
PCI->APIC IRQ transform: 0000:00:1d.2[C] -> IRQ 18
PCI->APIC IRQ transform: 000
PCI->APIC IRQ transform: 0000:02:03.1[B] -> IRQ 55
PCI->APIC IRQ transform: 0000:03:03.0[A] -> IRQ 30
PCI->APIC IRQ transform: 0000:04:01.0[A] -> IRQ 16
apm: BIOS not found.
VFS: Disk quotas dquot_6.5.1
Dquot-cache hash table entries: 1024 (order 0, 4096 bytes)
devfs: 2004-01-31 Richard Gooch (rgooch@atnf.csiro.au)
devfs: boot_options: 0x1
Installing knfsd (copyright (C) 1996 okir@monad.swb.de).
NTFS driver 2.1.22 [Flags: R/W].
SGI XFS with ACLs, security attributes, large block numbers, no debug enabled
SGI XFS Quota Management subsystem
Initializing Cryptographic API
vga16fb: mapped to 0xc00a0000
fb0: VGA16 VGA frame buffer device
isapnp: Scanning for PnP cards...
isapnp: No Plug & Play device found
lp: driver loaded but no devices found
Real Time Clock Driver v1.12
hw_random hardware driver 1.0.0 loaded
Linux agpgart interface v0.101 (c) Dave Jones
[drm] Initialized drm 1.0.0 20040925
ipmi message handler version v33
ipmi device interface version v33
IPMI System Interface driver version v33, KCS version v33, SM
version v33
ipmi_si: Trying "kcs" at I/O port 0xca2
ipmi_si: Trying "smic" at I/O port 0xca9
ipmi_si: Trying "bt" at I/O port 0xe4
ipmi_si: Unable to find any System Interface(s)
IPMI Watchdog: driver version v33
Copyright (C) 2004 MontaVista Software - IPMI Powerdown via sys_reboot
version v
33.
intelfb: Framebuffer driver for Intel(R) 830M/845G/852GM/855GM/865G/915G
chipset
s
intelfb: Version 0.9.2
PNP: No PS/2 controller found. Probing ports directly.
serio: i8042 AUX port at 0x60,0x64 irq 12
serio: i8042 KBD port at 0x60,0x64 irq 1
Serial: 8250/16550 driver $Revision: 1.90 $ 8 ports, IRQ sharing disabled
ttyS0 at I/O 0x3f8 (irq = 4) is a 16550A
ttyS1 at I/O 0x2f8 (irq = 3) is a 16550A
io scheduler noop registered
io scheduler anticipatory registered
io scheduler deadline registered
io scheduler cfq registered
Floppy drive(s): fd0 is 1.44M
FDC 0 is a post-1991 82077
RAMDISK driver initialized: 16 RAM disks of 10240K size 1024 blocksize
loop: loaded (max 8 devices)
pktcdvd: v0.2.0a 2004-07-14 Jens Axboe (axboe@suse.de) and petero2@telia.com
Intel(R) PRO/1000 Network Driver - version 6.0.54-k2
Copyright (c) 1999-2004 Intel Corporation.
e1000: eth0: e1000_probe: Intel(R) PRO/1000 Network Connection
e1000: eth1: e1000_probe: Intel(R) PRO/1000 Network Connection
e100: Intel(R) PRO/100 Network Driver, 3.4.8-k2-NAPI
e100: Copyright(c) 1999-2005 Intel Corporation
PPP generic driver version 2.4.2
PPP Deflate Compression module registered
PPP BSD Compression module registered
NET: Registered protocol family 24
tun: Universal TUN/TAP device driver, 1.6
tun: (C) 1999-2004 Max Krasnyansky <maxk@qualcomm.com>
Cronyx Ltd, Synchronous PPP and CISCO HDLC (c) 1994
Linux port (c) 1998 Building Number Three Ltd & Jan "Yenya" Kasprzak.
DLCI driver v0.35, 4 Jan 1997, mike.mclagan@linux.org.
HDLC support module revision 1.17
Uniform Multi-Platform E-IDE driver Revision: 7.00alpha2
ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx
ICH3: IDE controller at PCI slot 0000:00:
ICH3: chipset revision 2
ICH3: not 100% native mode: will probe irqs later
    ide0: BM-DMA at 0x2060-0x2067, BIOS settings: hda:pio, hdb:pio
    ide1: BM-DMA at 0x2068-0x206f, BIOS settings: hdc:pio, hdd:pio
hdc: CD-224E, ATAPI CD/DVD-ROM drive
ide1 at 0x170-0x177,0x376 on irq 15
hdc: ATAPI 24X CD-ROM drive, 128kB Cache, UDMA(33)
Uniform CD-ROM driver Revision: 3.20
Loading Adaptec I2O RAID: Version 2.4 Build 5go
Detecting Adaptec I2O RAID controllers...
Adaptec I2O RAID controller 0 irq=30
     BAR0 e0900000 -
     BAR1 e0a80000 - size= 1000000
dpti: If you have a lot of devices this could take a few minutes.
dpti0: Reading the hardware resource table.
TID 008  Vendor: ADAPTEC      Device: AIC-7902     Rev: 00000001
TID 009  Vendor: ADAPTEC      Device: AIC-7902     Rev: 00000001
TID 513  Vendor: SUPER   G    Device: GEM318       Rev: 0   0
scsi0 : Vendor: Adaptec  Model: 2015S            FW:3B0A
  Vendor: SUPER     Model: GEM318            Rev: 0
  Type:   Processor                          ANSI SCSI revision: 02
megaraid cmm: 2.20.2.5 (Release Date: Fri Jan 21 00:01:03 EST 2005)
megaraid: 2.20.4.5 (Release Date: Thu Feb 03 12:27:22 EST 2005)
3ware Storage Controller device driver for Linux v1.26.02.001.
3ware 9000 Storage Controller device driver for Linux v2.26.02.002.
Attached scsi generic sg0 at scsi0, channel 0, id 6, lun 0,  type 3
I2O subsystem v$Rev$
i2o: max drivers = 8
i2o: Checking for PCI I2O controllers...
i2o: I2O controller found on bus 3 at 24.
iop0: PCI I2O controller
     BAR0 at 0xF8300000 size=1048576
     BAR1 at 0xFB000000 size=16777216
iop0: using write combining MTRR
iop0: Installed at IRQ 30
iop0: Activating I2O controller...
iop0: This may take a few minutes if there are many devices
Unable to handle kernel paging request at virtual address 8000002c
 printing eip:
c03f1037
*pde = 00000000
Oops: 0000 [#1]
SMP
Modules linked in:
CPU:    0
EIP:    0060:[<c03f1037>]    Not tainted VLI
EFLAGS: 00010086   (2.6.12.3)
EIP is at adpt_isr+0x12f/0x1f8
eax: 80000000   ebx: dfcd0000   ecx: c17e0000   edx: c17e0000
esi: c17e0000   edi: 00000000   ebp: 1fcd0000   esp: c076df48
ds: 007b   es: 007b   ss: 0068
Process swapper (pid: 0, threadinfo=c076c000 task=c0673bc0)
Stack: 00000000 00000286 00000000 dfc48ec0 00000000 c076dfac 0000001e
c01358ff
       0000001e c17e0000 c076dfac 00000000 0000001e c07687b0 000003c0
c07687cc
       c01359f5 dfc48ec0 c076dfac ffffe000 c076c000 c07b4380 c07b4300
c0104dd5
Call Trace:
 [<c01358ff>] handle_IRQ_event+0x23/0x58
 [<c01359f5>] __do_IRQ+0xc1/0x10c
 [<c0104dd5>] do_IRQ+0x19/0x24
 [<c01037d2>] common_interrupt+0x1a/0x20
 [<c01009e0>] default_idle+0x0/0x2c
 [<c0100a03>] default_idle+0x23/0x2c
 [<c0100aa2>] cpu_idle+0x62/0x74
 [<c076e81b>] start_kernel+0x17f/0x1b4
Code: 00 00 00 40 89 44 24 08 74 12 8b 7b 0c 85 ff 74 0b b9 11 00 00 00 89
de f3
 a5 89 f6 8b 7c 24 08 85 ff 78 34 8b 43 0c 85 c0 74 07 <8b> 70 2c 85 f6 75
1a 8b
 54 24 24 8b 82 88 00 00 00 89 28 0f ae
 <0>Kernel panic - not syncing: Fatal exception in interrupt
Comment 1 Joshua McClintock 2005-07-25 15:28:57 UTC
A kind person on the list told me that I have 2 drivers trying to load and this
is what's causing my problem.  I removed I2O support while leaving support for
the card itself and viola!  I'm not sure if there is anyway around it, but maybe
having some code in there to check for the existance of a previously loaded
driver and skip if it's already loaded?
Comment 2 Andrew Morton 2005-08-04 14:43:02 UTC
I spoke to Markus Lidel about this and I think we agreed that yes,
the i2o drivers should be fixed up so they don't both diddle with
the same hardware.  That means that both of them need to be taught
about request_region() so the second-to-be-loaded driver will fail
to allocate its I/O resources and will correctly bale out.

I'll ask Mark Salyzyn to create a bugzilla account and to take a look
at this.
Comment 3 Mark Salyzyn 2005-08-05 04:32:56 UTC
Markus what do you suggest as a means to check for the other driver's 
existence?
Comment 4 Mark Salyzyn 2005-08-05 04:59:21 UTC
So, tentatively based on request_region:

--- dpt_i2o.c.orig	2005-08-05 07:52:21.057255479 -0400
+++ dpt_i2o.c	2005-08-05 07:51:47.471030222 -0400
@@ -1228,6 +1228,10 @@
 			hba_map0_area_size = 524288;
 	}
 
+	if (!request_region(base_addr0_phys, hba_map0_area_size, DPT_DRIVER)) {
+		PERROR("dpti: adpt_config_hba: BAR0 region already claimed\n");
+		return -ENODEV;
+	}
 	base_addr_virt = ioremap(base_addr0_phys,hba_map0_area_size);
 	if(!base_addr_virt) {
 		PERROR("dpti: adpt_config_hba: io remap failed\n");
@@ -1235,10 +1239,17 @@
 	}
 
         if(raptorFlag == 1) {
+		if (!request_region(base_addr1_phys, hba_map1_area_size, 
DPT_DRIVER)) {
+			PERROR("dpti: adpt_config_hba: BAR1 region already 
claimed\n");
+			iounmap(base_addr_virt);
+			release_region(base_addr0_phys,hba_map0_area_size);
+			return -ENODEV;
+		}
 		msg_addr_virt = ioremap(base_addr1_phys, hba_map1_area_size );
 		if(!msg_addr_virt) {
 			PERROR("dpti: adpt_config_hba: io remap failed on BAR1
\n");
 			iounmap(base_addr_virt);
+			release_region(base_addr0_phys,hba_map0_area_size);
 			return -EINVAL;
 		}
 	} else {
@@ -1250,8 +1261,10 @@
 	if( pHba == NULL) {
 		if(msg_addr_virt != base_addr_virt){
 			iounmap(msg_addr_virt);
+			release_region(base_addr1_phys,hba_map1_area_size);
 		}
 		iounmap(base_addr_virt);
+		release_region(base_addr0_phys,hba_map0_area_size);
 		return -ENOMEM;
 	}
 	memset(pHba, 0, sizeof(adpt_hba));
@@ -1321,7 +1334,11 @@
 	int j;
 	struct adpt_device* pDev;
 	struct adpt_device* pNext;
-
+	ulong base_addr0_phys = 0;
+	ulong base_addr1_phys = 0;
+	u32 hba_map0_area_size = 0;
+	u32 hba_map1_area_size = 0;
+	int raptorFlag = 0;
 
 	down(&adpt_configuration_lock);
 	// scsi_unregister calls our adpt_release which
@@ -1344,9 +1364,40 @@
 	hba_count--;
 	up(&adpt_configuration_lock);
 
+	base_addr0_phys = pci_resource_start(pHba->pDev,0);
+	hba_map0_area_size = pci_resource_len(pHba->pDev,0);
+
+	// Check if standard PCI card or single BAR Raptor
+	if(pHba->pDev->device == PCI_DPT_DEVICE_ID){
+		if(pHba->pDev->subsystem_device >=0xc032 && pHba->pDev-
>subsystem_device <= 0xc03b){
+			// Raptor card with this device id needs 4M
+			hba_map0_area_size = 0x400000;
+		} else { // Not Raptor - it is a PCI card
+			if(hba_map0_area_size > 0x100000 ){ 
+				hba_map0_area_size = 0x100000;
+			}
+		}
+	} else {// Raptor split BAR config
+		// Use BAR1 in this configuration
+		base_addr1_phys = pci_resource_start(pHba->pDev,1);
+		hba_map1_area_size = pci_resource_len(pHba->pDev,1);
+		raptorFlag = 1;
+	}
+	/* x86_64 machines need more optimal mappings */
+        if(raptorFlag == 1) {
+		if (hba_map0_area_size > 128)
+			hba_map0_area_size = 128;
+		if (hba_map1_area_size > 524288)
+			hba_map1_area_size = 524288;
+	} else {
+		if (hba_map0_area_size > 524288)
+			hba_map0_area_size = 524288;
+	}
 	iounmap(pHba->base_addr_virt);
+	release_region(base_addr0_phys,hba_map0_area_size);
 	if(pHba->msg_addr_virt != pHba->base_addr_virt){
 		iounmap(pHba->msg_addr_virt);
+		release_region(base_addr1_phys,hba_map1_area_size);
 	}
 	if(pHba->hrt_va) {
 		pci_free_consistent(pHba->pDev, le32_to_cpu(pHba->hrt_va-
>num_entries) * le32_to_cpu(pHba->hrt_va->entry_len) << 2, pHba->hrt_va, pHba-
>hrt_pa);
Comment 5 Andrew Morton 2005-08-05 11:24:12 UTC
sweet, thanks Mark.  Could you please email me that patch when
you're happy with it so I can add it to my collection?

Comment 6 Markus Lidel 2005-08-08 05:00:06 UTC
Created attachment 5546 [details]
Added request_region() call to find out if device is already in use

Patch to avoid that dpt_i2o and I2O subsystem both claim the same controller at
the same time.
Comment 7 Mark Salyzyn 2005-08-08 05:35:33 UTC
Comments from Alan and Markus simplifies and fixes this patch to:

--- dpt_i2o.c.orig	2005-08-08 08:25:46.888900616 -0400
+++ dpt_i2o.c	2005-08-08 08:30:48.062596580 -0400
@@ -1228,8 +1228,13 @@
 			hba_map0_area_size = 524288;
 	}
 
+	if (pci_request_regions(pDev)) {
+		PERROR("dpti: adpt_config_hba: pci request region failed\n");
+		return -EINVAL;
+	}
 	base_addr_virt = ioremap(base_addr0_phys,hba_map0_area_size);
 	if(!base_addr_virt) {
+		pci_release_regions(pDev);
 		PERROR("dpti: adpt_config_hba: io remap failed\n");
 		return -EINVAL;
 	}
@@ -1239,6 +1244,7 @@
 		if(!msg_addr_virt) {
 			PERROR("dpti: adpt_config_hba: io remap failed on BAR1
\n");
 			iounmap(base_addr_virt);
+			pci_release_regions(pDev);
 			return -EINVAL;
 		}
 	} else {
@@ -1252,6 +1258,7 @@
 			iounmap(msg_addr_virt);
 		}
 		iounmap(base_addr_virt);
+		pci_release_regions(pDev);
 		return -ENOMEM;
 	}
 	memset(pHba, 0, sizeof(adpt_hba));
@@ -1345,6 +1352,7 @@
 	up(&adpt_configuration_lock);
 
 	iounmap(pHba->base_addr_virt);
+	pci_release_regions(pHba->pDev);
 	if(pHba->msg_addr_virt != pHba->base_addr_virt){
 		iounmap(pHba->msg_addr_virt);
 	}
Comment 8 Markus Lidel 2005-08-08 06:30:38 UTC
Created attachment 5548 [details]
Use pci_request_regions() instead of request_region()

Use pci_request_regions() instead of request_region(), which is much easier to
use (thanks to Alan Cox and Mark Salyzyn).
Comment 9 Andrew Morton 2005-08-08 10:01:20 UTC
Thanks, Markus.  Could you please email me that patch
when it's ready to go?  And cc Mark?
Comment 10 Adrian Bunk 2005-08-19 13:37:45 UTC
This patch is now in Linus' tree and will therefore be included in 2.6.13-rc7.
Comment 11 Felix Seeger 2005-12-12 10:47:02 UTC
I have a problem with 2.6.14.3 and the dpti driver with an Adaptec 2100S card.  
  
During boot I get:  
iop0: controller found  
PCI: Unable to reserv mem region ... for device ...(iop0)  
iop0: device already claimed  
iop0: DMA/IO allocation fopr I2O controller failed  
...  
...  
dpti0: Trying to abort cmd=56  
 
The system hangs here, bootup with 2.6.8 debian stable works fine, I will now  
try older kernel versions.  The raid array and disks where detected correctly 
prior to the messages above. 
 
 
Comment 12 Adrian Bunk 2005-12-12 10:59:12 UTC
Hi Felix,

you seem to have a different problem.

Please open a new bug for it.
Comment 13 Mark Salyzyn 2005-12-12 11:31:42 UTC
Adrian is partially right in that the dpt_i2o driver is failing even despite 
the code that prevents both drivers from loading to attach to the Adapter 
(iop0: device already claimed; meaning the dpt_i2o driver loaded first).

However, I would like to ask if anyone *tested* this code to make sure that 
the i2o_block driver failing to load did not somehow result in some 
interference with the previously loaded dpt_i2o driver?

Please remove the i2o_block driver from your 2.6.14.3 configuration and see if 
the dpt_i2o driver functions correctly. If it continues to be dysfunctional, 
then open a different bug report. If it springs to life, then we need to look 
further into this.
Comment 14 Felix Seeger 2005-12-12 16:25:23 UTC
Mark, I haven't tested as you sad but already opened a new report. I will try 
to test other configurations/kernels tomorrow. 
Comment 15 Ryoji Kamei 2006-01-11 23:49:09 UTC
Created attachment 6995 [details]
move pci_request_regions() just behind pci_enable_device()

In linux 2.6.15, data transfer does hang when both drivers are loaded. 
It seems that location of pci_request_regions() are wrong.
I moved it just behind pci_enable_device() like other drivers,
and it becomes fine.
Comment 16 Andrew Morton 2006-01-12 00:04:23 UTC
whee, we fixed a bug!

Could the reporters please test this?

Kamei, could you please mail that bug to myself and to Mark Salyzyn
<aacraid@adaptec.com> with the abvove description and a Signed-off-by: as
per section 11 of Documentation/SubmittingPatches?

Thanks.

Comment 17 Markus Lidel 2006-01-13 10:42:50 UTC
Hello,

probably the reason why this works, is because in the "old" version disables the
PCI device if it fails to load, independent if the device is enabled or not. So
IMHO it would be better to not disable the device if it is enabled before, or?

Thanks you very much!
Comment 18 Markus Lidel 2006-01-13 10:56:39 UTC
Created attachment 7009 [details]
If the PCI device is enabled already don't disable it at failure

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