2.4.9-ac17 Adaptec AIC7XXX problems (new driver, old one works fine)

2.4.9-ac17 Adaptec AIC7XXX problems (new driver, old one works fine)

[Ookhoi]

Hi Justin, Alan,

The new driver for the Adaptec 7892B gives me the following problems
(see dmesg) on a asus a7v mobo with kernel 2.4.9-ac17.

I have to run the system underclocked to make it boot at all. As soon as
I run it at 1000 or 1200 MHz, it does a Kernel panic: for safety during
the scsi boot part. It is a 1200MHz processor. The system runs fine
after the (long) boot.

The old driver doesn't compile with -ac17, it does with -ac16.

2.4.9-ac17:
[blabla]
aic7xxx_old.c:11965: parse error before string constant
aic7xxx_old.c:11965: warning: type defaults to `int' in declaration of `MODULE_LICENSE'
aic7xxx_old.c:11965: warning: function declaration isn't a prototype
aic7xxx_old.c:11965: warning: data definition has no type or storage class
make[3]: *** [aic7xxx_old.o] Error 1
make[2]: *** [first_rule] Error 2
make[1]: *** [_subdir_scsi] Error 2
make: *** [_dir_drivers] Error 2


With the old AIC7XXX driver, the system boots normal (-ac16 dmesg below
-ac17 dmesg).

Is there something wrong with the driver? Or settings I have to look for
in the scsi bios?

Tia!

	Ookhoi


Linux version 2.4.9-ac17 (root@tranquil) (gcc version 2.95.4 20010902 (Debian prerelease)) #1 Sat Sep 29 13:15:37 UTC 2001
BIOS-provided physical RAM map:
 BIOS-e820: 0000000000000000 - 000000000009f800 (usable)
 BIOS-e820: 000000000009f800 - 00000000000a0000 (reserved)
 BIOS-e820: 00000000000f0000 - 0000000000100000 (reserved)
 BIOS-e820: 0000000000100000 - 000000002ffec000 (usable)
 BIOS-e820: 000000002ffec000 - 000000002ffef000 (ACPI data)
 BIOS-e820: 000000002ffef000 - 000000002ffff000 (reserved)
 BIOS-e820: 000000002ffff000 - 0000000030000000 (ACPI NVS)
 BIOS-e820: 00000000ffff0000 - 0000000100000000 (reserved)
On node 0 totalpages: 196588
zone(0): 4096 pages.
zone(1): 192492 pages.
zone(2): 0 pages.
Local APIC disabled by BIOS -- reenabling.
Found and enabled local APIC!
Kernel command line: auto BOOT_IMAGE=2.4.9-ac17 ro root=901
Initializing CPU#0
Detected 807.224 MHz processor.
Console: colour VGA+ 80x25
Calibrating delay loop... 1608.90 BogoMIPS
Memory: 770956k/786352k available (1129k kernel code, 15008k reserved, 318k data, 204k init, 0k highmem)
Dentry-cache hash table entries: 131072 (order: 8, 1048576 bytes)
Inode-cache hash table entries: 65536 (order: 7, 524288 bytes)
Mount-cache hash table entries: 16384 (order: 5, 131072 bytes)
Buffer-cache hash table entries: 65536 (order: 6, 262144 bytes)
Page-cache hash table entries: 262144 (order: 8, 1048576 bytes)
CPU: Before vendor init, caps: 0183fbff c1c7fbff 00000000, vendor = 2
CPU: L1 I Cache: 64K (64 bytes/line), D cache 64K (64 bytes/line)
CPU: L2 Cache: 256K (64 bytes/line)
CPU: After vendor init, caps: 0183fbff c1c7fbff 00000000 00000000
Intel machine check architecture supported.
Intel machine check reporting enabled on CPU#0.
CPU:     After generic, caps: 0183fbff c1c7fbff 00000000 00000000
CPU:             Common caps: 0183fbff c1c7fbff 00000000 00000000
CPU: AMD Athlon(tm) Processor stepping 02
Enabling fast FPU save and restore... done.
Checking 'hlt' instruction... OK.
POSIX conformance testing by UNIFIX
enabled ExtINT on CPU#0
ESR value before enabling vector: 00000000
ESR value after enabling vector: 00000000
Using local APIC timer interrupts.
calibrating APIC timer ...
..... CPU clock speed is 807.2539 MHz.
..... host bus clock speed is 201.8134 MHz.
cpu: 0, clocks: 2018134, slice: 1009067
CPU0<T0:2018128,T1:1009056,D:5,S:1009067,C:2018134>
mtrr: v1.40 (20010327) Richard Gooch (rgooch@atnf.csiro.au)
mtrr: detected mtrr type: Intel
PCI: PCI BIOS revision 2.10 entry at 0xf1150, last bus=1
PCI: Using configuration type 1
PCI: Probing PCI hardware
PCI: Using IRQ router VIA [1106/0686] at 00:04.0
Applying VIA southbridge workaround.
PCI: Disabling Via external APIC routing
PnP: PNP BIOS installation structure at 0xc00fc2b0
PnP: PNP BIOS version 1.0, entry at f0000:c2e0, dseg at f0000
PnPBIOS: PNP0c02: request 0xe400-0xe480 ok
PnPBIOS: PNP0c02: request 0xe800-0xe840
PnP: 12 devices detected total
Linux NET4.0 for Linux 2.4
Based upon Swansea University Computer Society NET3.039
Simple Boot Flag extension found and enabled.
Starting kswapd v1.8
pty: 256 Unix98 ptys configured
Serial driver version 5.05c (2001-07-08) with MANY_PORTS SHARE_IRQ SERIAL_PCI enabled
ttyS00 at 0x03f8 (irq = 4) is a 16550A
Software Watchdog Timer: 0.05, timer margin: 60 sec
block: queued sectors max/low 511730kB/380658kB, 1536 slots per queue
Floppy drive(s): fd0 is 1.44M
FDC 0 is a post-1991 82077
PCI: Found IRQ 11 for device 00:0c.0
3c59x: Donald Becker and others. www.scyld.com/network/vortex.html
00:0c.0: 3Com PCI 3c905C Tornado at 0x9400. Vers LK1.1.16
Linux agpgart interface v0.99 (c) Jeff Hartmann
agpgart: Maximum main memory to use for agp memory: 690M
agpgart: unsupported bridge
agpgart: no supported devices found.

---

SCSI subsystem driver Revision: 1.00
PCI: Found IRQ 12 for device 00:0d.0
PCI: Sharing IRQ 12 with 00:04.3
scsi0: PCI error Interrupt at seqaddr = 0x44
scsi0: Signaled a Target Abort
scsi0 : Adaptec AIC7XXX EISA/VLB/PCI SCSI HBA DRIVER, Rev 6.2.1
        <Adaptec 19160B Ultra160 SCSI adapter>
        aic7892: Ultra160 Wide Channel A, SCSI Id=7, 32/255 SCBs

  Vendor: IBM       Model: DDYS-T18350N      Rev: S96H
  Type:   Direct-Access                      ANSI SCSI revision: 03
scsi0: PCI error Interrupt at seqaddr = 0x18
scsi0: Signaled a Target Abort
scsi0:0:5:0: Attempting to queue an ABORT message
scsi0:0:5:0: Cmd aborted from QINFIFO
aic7xxx_abort returns 8194
scsi0:0:5:0: Attempting to queue an ABORT message
scsi0:0:5:0: Cmd aborted from QINFIFO
aic7xxx_abort returns 8194
scsi0:0:5:0: Attempting to queue a TARGET RESET message
scsi0:0:5:0: Is not an active device
aic7xxx_dev_reset returns 8194
scsi0:0:5:0: Attempting to queue an ABORT message
scsi0:0:5:0: Cmd aborted from QINFIFO
aic7xxx_abort returns 8194
scsi0: PCI error Interrupt at seqaddr = 0x44
scsi0: Signaled a Target Abort
scsi: device set offline - not ready or command retry failed after bus reset: host 0 channel 0 id 5 lun 0
  Vendor: IBM       Model: DDYS-T18350N      Rev: S96H
  Type:   Direct-Access                      ANSI SCSI revision: 03
scsi0: PCI error Interrupt at seqaddr = 0x18
scsi0: Signaled a Target Abort
scsi0:0:9:0: Attempting to queue an ABORT message
scsi0:0:9:0: Cmd aborted from QINFIFO
aic7xxx_abort returns 8194
scsi0:0:9:0: Attempting to queue an ABORT message
scsi0:0:9:0: Cmd aborted from QINFIFO
aic7xxx_abort returns 8194
scsi0:0:9:0: Attempting to queue a TARGET RESET message
scsi0:0:9:0: Is not an active device
aic7xxx_dev_reset returns 8194
scsi0:0:9:0: Attempting to queue an ABORT message
scsi0:0:9:0: Cmd aborted from QINFIFO
aic7xxx_abort returns 8194
scsi0: PCI error Interrupt at seqaddr = 0x3
scsi0: Signaled a Target Abort
spurious 8259A interrupt: IRQ7.
scsi: device set offline - not ready or command retry failed after bus reset: host 0 channel 0 id 9 lun 0
scsi0: PCI error Interrupt at seqaddr = 0x18
scsi0: Signaled a Target Abort
scsi0:0:15:0: Attempting to queue an ABORT message
scsi0:0:15:0: Cmd aborted from QINFIFO
aic7xxx_abort returns 8194
scsi0:0:15:0: Attempting to queue an ABORT message
scsi0:0:15:0: Cmd aborted from QINFIFO
aic7xxx_abort returns 8194
scsi0:0:15:0: Attempting to queue a TARGET RESET message
scsi0:0:15:0: Is not an active device
aic7xxx_dev_reset returns 8194
scsi0:0:15:0: Attempting to queue an ABORT message
scsi0:0:15:0: Cmd aborted from QINFIFO
aic7xxx_abort returns 8194
scsi0: PCI error Interrupt at seqaddr = 0x44
scsi0: Signaled a Target Abort
scsi: device set offline - not ready or command retry failed after bus reset: host 0 channel 0 id 15 lun 0
scsi0:0:3:0: Tagged Queuing enabled.  Depth 253
scsi0:0:6:0: Tagged Queuing enabled.  Depth 253
Attached scsi disk sda at scsi0, channel 0, id 3, lun 0
Attached scsi disk sdb at scsi0, channel 0, id 6, lun 0
(scsi0:A:3): 160.000MB/s transfers (80.000MHz DT, offset 63, 16bit)
SCSI device sda: 35843670 512-byte hdwr sectors (18352 MB)
Partition check:
 sda: sda1 sda2
(scsi0:A:6): 160.000MB/s transfers (80.000MHz DT, offset 63, 16bit)
SCSI device sdb: 35843670 512-byte hdwr sectors (18352 MB)
 sdb: sdb1 sdb2

---

md: raid1 personality registered as nr 3
md: multipath personality registered as nr 7
md: md driver 0.90.0 MAX_MD_DEVS=256, MD_SB_DISKS=27
md: Autodetecting RAID arrays.
(read) sda1's sb offset: 1049472 [events: 0000001c]
(read) sda2's sb offset: 16871360 [events: 00000019]
(read) sdb1's sb offset: 1049472 [events: 0000001c]
(read) sdb2's sb offset: 16871360 [events: 00000019]
md: autorun ...
md: considering sdb2 ...
md:  adding sdb2 ...
md:  adding sda2 ...
md: created md1
md: bind<sda2,1>
md: bind<sdb2,2>
md: running: <sdb2><sda2>
md: sdb2's event counter: 00000019
md: sda2's event counter: 00000019
RAID level 1 does not need chunksize! Continuing anyway.
md1: max total readahead window set to 124k
md1: 1 data-disks, max readahead per data-disk: 124k
raid1: device sdb2 operational as mirror 1
raid1: device sda2 operational as mirror 0
raid1: raid set md1 active with 2 out of 2 mirrors
md: updating md1 RAID superblock on device
md: sdb2 [events: 0000001a](write) sdb2's sb offset: 16871360
md: sda2 [events: 0000001a](write) sda2's sb offset: 16871360
md: considering sdb1 ...
md:  adding sdb1 ...
md:  adding sda1 ...
md: created md0
md: bind<sda1,1>
md: bind<sdb1,2>
md: running: <sdb1><sda1>
md: sdb1's event counter: 0000001c
md: sda1's event counter: 0000001c
RAID level 1 does not need chunksize! Continuing anyway.
md0: max total readahead window set to 124k
md0: 1 data-disks, max readahead per data-disk: 124k
raid1: device sdb1 operational as mirror 1
raid1: device sda1 operational as mirror 0
raid1: raid set md0 active with 2 out of 2 mirrors
md: updating md0 RAID superblock on device
md: sdb1 [events: 0000001d](write) sdb1's sb offset: 1049472
md: sda1 [events: 0000001d](write) sda1's sb offset: 1049472
md: ... autorun DONE.
NET4: Linux TCP/IP 1.0 for NET4.0
IP Protocols: ICMP, UDP, TCP
IP: routing cache hash table of 8192 buckets, 64Kbytes
TCP: Hash tables configured (established 262144 bind 65536)
ip_conntrack (6143 buckets, 49144 max)
ip_tables: (c)2000 Netfilter core team
NET4: Unix domain sockets 1.0/SMP for Linux NET4.0.
FAT: bogus logical sector size 0
FAT: bogus logical sector size 0
md: swapper(pid 1) used obsolete MD ioctl, upgrade your software to use new ictls.
reiserfs: checking transaction log (device 09:01) ...
Using r5 hash to sort names
ReiserFS version 3.6.25
VFS: Mounted root (reiserfs filesystem) readonly.
Freeing unused kernel memory: 204k freed
Adding Swap: 1049464k swap-space (priority -1)


===


Linux version 2.4.9-ac16 (root@tranquil) (gcc version 2.95.4 20010902 (Debian prerelease)) #1 Sat Sep 29 15:10:58 UTC 2001
BIOS-provided physical RAM map:
 BIOS-e820: 0000000000000000 - 000000000009f800 (usable)
 BIOS-e820: 000000000009f800 - 00000000000a0000 (reserved)
 BIOS-e820: 00000000000f0000 - 0000000000100000 (reserved)
 BIOS-e820: 0000000000100000 - 000000002ffec000 (usable)
 BIOS-e820: 000000002ffec000 - 000000002ffef000 (ACPI data)
 BIOS-e820: 000000002ffef000 - 000000002ffff000 (reserved)
 BIOS-e820: 000000002ffff000 - 0000000030000000 (ACPI NVS)
 BIOS-e820: 00000000ffff0000 - 0000000100000000 (reserved)
On node 0 totalpages: 196588
zone(0): 4096 pages.
zone(1): 192492 pages.
zone(2): 0 pages.
Local APIC disabled by BIOS -- reenabling.
Found and enabled local APIC!
Kernel command line: auto BOOT_IMAGE=2.4.9-ac16 ro root=901
Initializing CPU#0
Detected 807.195 MHz processor.
Console: colour VGA+ 80x25
Calibrating delay loop... 1608.90 BogoMIPS
Memory: 770956k/786352k available (1133k kernel code, 15008k reserved, 321k data, 204k init, 0k highmem)
Dentry-cache hash table entries: 131072 (order: 8, 1048576 bytes)
Inode-cache hash table entries: 65536 (order: 7, 524288 bytes)
Mount-cache hash table entries: 16384 (order: 5, 131072 bytes)
Buffer-cache hash table entries: 65536 (order: 6, 262144 bytes)
Page-cache hash table entries: 262144 (order: 8, 1048576 bytes)
CPU: Before vendor init, caps: 0183fbff c1c7fbff 00000000, vendor = 2
CPU: L1 I Cache: 64K (64 bytes/line), D cache 64K (64 bytes/line)
CPU: L2 Cache: 256K (64 bytes/line)
CPU: After vendor init, caps: 0183fbff c1c7fbff 00000000 00000000
Intel machine check architecture supported.
Intel machine check reporting enabled on CPU#0.
CPU:     After generic, caps: 0183fbff c1c7fbff 00000000 00000000
CPU:             Common caps: 0183fbff c1c7fbff 00000000 00000000
CPU: AMD Athlon(tm) Processor stepping 02
Enabling fast FPU save and restore... done.
Checking 'hlt' instruction... OK.
POSIX conformance testing by UNIFIX
enabled ExtINT on CPU#0
ESR value before enabling vector: 00000000
ESR value after enabling vector: 00000000
Using local APIC timer interrupts.
calibrating APIC timer ...
..... CPU clock speed is 807.1718 MHz.
..... host bus clock speed is 201.7929 MHz.
cpu: 0, clocks: 2017929, slice: 1008964
CPU0<T0:2017920,T1:1008944,D:12,S:1008964,C:2017929>
mtrr: v1.40 (20010327) Richard Gooch (rgooch@atnf.csiro.au)
mtrr: detected mtrr type: Intel
PCI: PCI BIOS revision 2.10 entry at 0xf1150, last bus=1
PCI: Using configuration type 1
PCI: Probing PCI hardware
PCI: Using IRQ router VIA [1106/0686] at 00:04.0
Applying VIA southbridge workaround.
PCI: Disabling Via external APIC routing
PnP: PNP BIOS installation structure at 0xc00fc2b0
PnP: PNP BIOS version 1.0, entry at f0000:c2e0, dseg at f0000
PnPBIOS: PNP0c02: request 0xe400-0xe480 ok
PnPBIOS: PNP0c02: request 0xe800-0xe840
PnP: 12 devices detected total
Linux NET4.0 for Linux 2.4
Based upon Swansea University Computer Society NET3.039
Simple Boot Flag extension found and enabled.
Starting kswapd v1.8
pty: 256 Unix98 ptys configured
Serial driver version 5.05c (2001-07-08) with MANY_PORTS SHARE_IRQ SERIAL_PCI enabled
ttyS00 at 0x03f8 (irq = 4) is a 16550A
Software Watchdog Timer: 0.05, timer margin: 60 sec
block: queued sectors max/low 511730kB/380658kB, 1536 slots per queue
Floppy drive(s): fd0 is 1.44M
FDC 0 is a post-1991 82077
PCI: Found IRQ 11 for device 00:0c.0
3c59x: Donald Becker and others. www.scyld.com/network/vortex.html
00:0c.0: 3Com PCI 3c905C Tornado at 0x9400. Vers LK1.1.16
Linux agpgart interface v0.99 (c) Jeff Hartmann
agpgart: Maximum main memory to use for agp memory: 690M
agpgart: unsupported bridge
agpgart: no supported devices found.
SCSI subsystem driver Revision: 1.00
PCI: Found IRQ 12 for device 00:0d.0
PCI: Sharing IRQ 12 with 00:04.3
(scsi0) <Adaptec AIC-7892 Ultra 160/m SCSI host adapter> found at PCI 0/13/0
(scsi0) Wide Channel, SCSI ID=7, 32/255 SCBs
(scsi0) Downloading sequencer code... 396 instructions downloaded
scsi0 : Adaptec AHA274x/284x/294x (EISA/VLB/PCI-Fast SCSI) 5.2.4/5.2.0
       <Adaptec AIC-7892 Ultra 160/m SCSI host adapter>
  Vendor: IBM       Model: DDYS-T18350N      Rev: S96H
  Type:   Direct-Access                      ANSI SCSI revision: 03
  Vendor: IBM       Model: DDYS-T18350N      Rev: S96H
  Type:   Direct-Access                      ANSI SCSI revision: 03
Attached scsi disk sda at scsi0, channel 0, id 3, lun 0
Attached scsi disk sdb at scsi0, channel 0, id 6, lun 0
(scsi0:0:3:0) Synchronous at 160.0 Mbyte/sec, offset 63.
SCSI device sda: 35843670 512-byte hdwr sectors (18352 MB)
Partition check:
 sda: sda1 sda2
(scsi0:0:6:0) Synchronous at 160.0 Mbyte/sec, offset 63.
SCSI device sdb: 35843670 512-byte hdwr sectors (18352 MB)
 sdb: sdb1 sdb2
md: raid1 personality registered as nr 3
md: multipath personality registered as nr 7
md: md driver 0.90.0 MAX_MD_DEVS=256, MD_SB_DISKS=27
md: Autodetecting RAID arrays.
(read) sda1's sb offset: 1049472 [events: 00000020]
(read) sda2's sb offset: 16871360 [events: 0000001d]
(read) sdb1's sb offset: 1049472 [events: 00000020]
(read) sdb2's sb offset: 16871360 [events: 0000001d]
md: autorun ...
md: considering sdb2 ...
md:  adding sdb2 ...
md:  adding sda2 ...
md: created md1
md: bind<sda2,1>
md: bind<sdb2,2>
md: running: <sdb2><sda2>
md: sdb2's event counter: 0000001d
md: sda2's event counter: 0000001d
RAID level 1 does not need chunksize! Continuing anyway.
md1: max total readahead window set to 124k
md1: 1 data-disks, max readahead per data-disk: 124k
raid1: device sdb2 operational as mirror 1
raid1: device sda2 operational as mirror 0
raid1: raid set md1 active with 2 out of 2 mirrors
md: updating md1 RAID superblock on device
md: sdb2 [events: 0000001e](write) sdb2's sb offset: 16871360
md: sda2 [events: 0000001e](write) sda2's sb offset: 16871360
md: considering sdb1 ...
md:  adding sdb1 ...
md:  adding sda1 ...
md: created md0
md: bind<sda1,1>
md: bind<sdb1,2>
md: running: <sdb1><sda1>
md: sdb1's event counter: 00000020
md: sda1's event counter: 00000020
RAID level 1 does not need chunksize! Continuing anyway.
md0: max total readahead window set to 124k
md0: 1 data-disks, max readahead per data-disk: 124k
raid1: device sdb1 operational as mirror 1
raid1: device sda1 operational as mirror 0
raid1: raid set md0 active with 2 out of 2 mirrors
md: updating md0 RAID superblock on device
md: sdb1 [events: 00000021](write) sdb1's sb offset: 1049472
md: sda1 [events: 00000021](write) sda1's sb offset: 1049472
md: ... autorun DONE.
NET4: Linux TCP/IP 1.0 for NET4.0
IP Protocols: ICMP, UDP, TCP
IP: routing cache hash table of 8192 buckets, 64Kbytes
TCP: Hash tables configured (established 262144 bind 65536)
ip_conntrack (6143 buckets, 49144 max)
ip_tables: (c)2000 Netfilter core team
NET4: Unix domain sockets 1.0/SMP for Linux NET4.0.
FAT: bogus logical sector size 0
FAT: bogus logical sector size 0
md: swapper(pid 1) used obsolete MD ioctl, upgrade your software to use new ictls.
reiserfs: checking transaction log (device 09:01) ...
Using r5 hash to sort names
ReiserFS version 3.6.25
VFS: Mounted root (reiserfs filesystem) readonly.
Freeing unused kernel memory: 204k freed
Adding Swap: 1049464k swap-space (priority -1)

Re: 2.4.9-ac17 Adaptec AIC7XXX problems (new driver, old one works fine)

[arjan]

In article <20010929162224.E9327@humilis> you wrote:
> Hi Justin, Alan,

> aic7xxx_old.c:11965: parse error before string constant
> aic7xxx_old.c:11965: warning: type defaults to `int' in declaration of `MODULE_LICENSE'
> aic7xxx_old.c:11965: warning: function declaration isn't a prototype
> aic7xxx_old.c:11965: warning: data definition has no type or storage class


Yet another driver with bogus #ifdef around the module.h include.. sigh


--- linux/drivers/scsi/aic7xxx/aic7xxx_linux.c~	Fri Sep 28 13:02:13 2001
+++ linux/drivers/scsi/aic7xxx/aic7xxx_linux.c	Sat Sep 29 15:41:52 2001
@@ -120,9 +120,7 @@
  * under normal conditions.
  */
 
-#if defined(MODULE)
 #include <linux/module.h>
-#endif
 
 #include "aic7xxx_osm.h"
 #include "aic7xxx_inline.h"

Re: 2.4.9-ac17 Adaptec AIC7XXX problems (new driver, old one works fine)

[Ookhoi]

> In article <20010929162224.E9327@humilis> you wrote:
> > Hi Justin, Alan,
> 
> > aic7xxx_old.c:11965: parse error before string constant
> > aic7xxx_old.c:11965: warning: type defaults to `int' in declaration of `MODULE_LICENSE'
> > aic7xxx_old.c:11965: warning: function declaration isn't a prototype
> > aic7xxx_old.c:11965: warning: data definition has no type or storage class
> 
> 
> Yet another driver with bogus #ifdef around the module.h include.. sigh

You mean linux/drivers/scsi/aic7xxx_old.c ? The old one is the one that
fails to compile with -ac17


> --- linux/drivers/scsi/aic7xxx/aic7xxx_linux.c~	Fri Sep 28 13:02:13 2001
> +++ linux/drivers/scsi/aic7xxx/aic7xxx_linux.c	Sat Sep 29 15:41:52 2001
> @@ -120,9 +120,7 @@
>   * under normal conditions.
>   */
>  
> -#if defined(MODULE)
>  #include <linux/module.h>
> -#endif
>  
>  #include "aic7xxx_osm.h"
>  #include "aic7xxx_inline.h"

Re: 2.4.9-ac17 Adaptec AIC7XXX problems (new driver, old one works fine)

[Justin T. Gibbs]

>Hi Justin, Alan,
>
>The new driver for the Adaptec 7892B gives me the following problems
>(see dmesg) on a asus a7v mobo with kernel 2.4.9-ac17.
>
>I have to run the system underclocked to make it boot at all. As soon as
>I run it at 1000 or 1200 MHz, it does a Kernel panic: for safety during
>the scsi boot part. It is a 1200MHz processor. The system runs fine
>after the (long) boot.

IIRC, the a7v is an AMD processor with VIA chipset.  If you go into the
MB BIOS and disable all of the "Make my PCI bus go as fast as possible even
if this means violating the spec" options, the "new" aic7xxx driver should
work fine.  I wish VIA would get a clue.

--
Justin

Re: 2.4.9-ac17 Adaptec AIC7XXX problems (new driver, old one works fine)

[Justin T. Gibbs]

>Yet another driver with bogus #ifdef around the module.h include.. sigh

I believe that this was fixed in v6.2.3 of the aic7xxx driver, but
I'm not in front of a machine right now where I can check.

--
Justin

Re: 2.4.9-ac17 Adaptec AIC7XXX problems (new driver, old one works fine) (solved)

[Ookhoi]

Hi Justin,

> >The new driver for the Adaptec 7892B gives me the following problems
> >(see dmesg) on a asus a7v mobo with kernel 2.4.9-ac17.
> >
> >I have to run the system underclocked to make it boot at all. As soon
> >as I run it at 1000 or 1200 MHz, it does a Kernel panic: for safety
> >during the scsi boot part. It is a 1200MHz processor. The system runs
> >fine after the (long) boot.
> 
> IIRC, the a7v is an AMD processor with VIA chipset. If you go into the
> MB BIOS and disable all of the "Make my PCI bus go as fast as possible
> even if this means violating the spec" options, the "new" aic7xxx
> driver should work fine. I wish VIA would get a clue.

It is indeed an AMD system with the VIA KT133 chipset.

I played with the bios settings to find out with which option it would
or would not give trouble. Under Advanced, CHIP Configuration the option
Byte Merge has to be disabled to make the kernel boot fine with the new
aic7xxx driver. This is with kernel 2.4.9-ac18

The bios manual says:
Byte Merge [Enabled by default]
To optimize the data transfer on PCI, this merges a sequence of
individual memory writes (bytes or words) into a single 32-bit block of
data. However, byte merging may only be done when the bytes within a
data phase are in a prefetchable address range. Configuration options:
[Disabled] [Enabled]

Why does the old driver boot fine with this enabled, and has the new
driver troubles booting then? The system seemed to run fine after the
long boot with the new driver and byte merge enabled, so it seemes that
only the boot gives troubles. The system didn't always boot till the end
with the new kernel and byte merge enabled btw, as it sometimes stopped
with the message: Kernel panic: for safety

Anyway, thank you for the hint! It all works fine now. :-)

	Ookhoi

Re: 2.4.9-ac17 Adaptec AIC7XXX problems (new driver, old one works fine) (solved)

[Matthew Dharm]

[-- Attachment #1: Type: text/plain, Size: 2732 bytes --]

Hrm... this makes me wonder if the Byte Merge option is keeping the PCI
consistancy rules, or perhaps the aic7xxx driver is making assumptions
about when PCI writes are actually occuring, without doing a read cycle
between critical writes to make sure they actually happen.

Matt

On Sun, Sep 30, 2001 at 08:57:31AM +0200, Ookhoi wrote:
> Hi Justin,
> 
> > >The new driver for the Adaptec 7892B gives me the following problems
> > >(see dmesg) on a asus a7v mobo with kernel 2.4.9-ac17.
> > >
> > >I have to run the system underclocked to make it boot at all. As soon
> > >as I run it at 1000 or 1200 MHz, it does a Kernel panic: for safety
> > >during the scsi boot part. It is a 1200MHz processor. The system runs
> > >fine after the (long) boot.
> > 
> > IIRC, the a7v is an AMD processor with VIA chipset. If you go into the
> > MB BIOS and disable all of the "Make my PCI bus go as fast as possible
> > even if this means violating the spec" options, the "new" aic7xxx
> > driver should work fine. I wish VIA would get a clue.
> 
> It is indeed an AMD system with the VIA KT133 chipset.
> 
> I played with the bios settings to find out with which option it would
> or would not give trouble. Under Advanced, CHIP Configuration the option
> Byte Merge has to be disabled to make the kernel boot fine with the new
> aic7xxx driver. This is with kernel 2.4.9-ac18
> 
> The bios manual says:
> Byte Merge [Enabled by default]
> To optimize the data transfer on PCI, this merges a sequence of
> individual memory writes (bytes or words) into a single 32-bit block of
> data. However, byte merging may only be done when the bytes within a
> data phase are in a prefetchable address range. Configuration options:
> [Disabled] [Enabled]
> 
> Why does the old driver boot fine with this enabled, and has the new
> driver troubles booting then? The system seemed to run fine after the
> long boot with the new driver and byte merge enabled, so it seemes that
> only the boot gives troubles. The system didn't always boot till the end
> with the new kernel and byte merge enabled btw, as it sometimes stopped
> with the message: Kernel panic: for safety
> 
> Anyway, thank you for the hint! It all works fine now. :-)
> 
> 	Ookhoi
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/

-- 
Matthew Dharm                              Home: mdharm-usb@one-eyed-alien.net 
Maintainer, Linux USB Mass Storage Driver

It was a new hope.
					-- Dust Puppy
User Friendly, 12/25/1998

[-- Attachment #2: Type: application/pgp-signature, Size: 232 bytes --]

Re: 2.4.9-ac17 Adaptec AIC7XXX problems (new driver, old one works fine) (solved)

[Gérard Roudier]

On Sun, 30 Sep 2001, Matthew Dharm wrote:

> Hrm... this makes me wonder if the Byte Merge option is keeping the PCI
> consistancy rules, or perhaps the aic7xxx driver is making assumptions
> about when PCI writes are actually occuring, without doing a read cycle
> between critical writes to make sure they actually happen.

If the VIA PCI byte merging way is the one described by the PCI
specifications, then it may only happen when the data phase is targetted
to a _prefectchable_ address range (implied should never happen when
targetted to a non-prefetechable range). If some VIA chipsets perform byte
merging for non-prefetchable range then the are HIGHLY bogus in my opinion
and stink a LOT absolutely.

May-be, the old aic7xxx driver does enforce a read cycle after each MMIO
write shorter than a DWORD. This obviously prevents Bogus Byte Merging to
non-prefetchable from occurring, but also affects PCI performances of all
systems using this driver.

Should we blindly kill performances for good hardware due to a couple of
brain-damagedly designed ones? I think *NO*, and for example, the drivers
for SYMBIOS chips I maintain donnot do so, never did so and will never do
so.

> Matt
>
> On Sun, Sep 30, 2001 at 08:57:31AM +0200, Ookhoi wrote:
> > Hi Justin,
> >
> > > >The new driver for the Adaptec 7892B gives me the following problems
> > > >(see dmesg) on a asus a7v mobo with kernel 2.4.9-ac17.
> > > >
> > > >I have to run the system underclocked to make it boot at all. As soon
> > > >as I run it at 1000 or 1200 MHz, it does a Kernel panic: for safety
> > > >during the scsi boot part. It is a 1200MHz processor. The system runs
> > > >fine after the (long) boot.
> > >
> > > IIRC, the a7v is an AMD processor with VIA chipset. If you go into the
> > > MB BIOS and disable all of the "Make my PCI bus go as fast as possible
> > > even if this means violating the spec" options, the "new" aic7xxx
> > > driver should work fine. I wish VIA would get a clue.
> >
> > It is indeed an AMD system with the VIA KT133 chipset.
> >
> > I played with the bios settings to find out with which option it would
> > or would not give trouble. Under Advanced, CHIP Configuration the option
> > Byte Merge has to be disabled to make the kernel boot fine with the new
> > aic7xxx driver. This is with kernel 2.4.9-ac18
> >
> > The bios manual says:
> > Byte Merge [Enabled by default]
> > To optimize the data transfer on PCI, this merges a sequence of
> > individual memory writes (bytes or words) into a single 32-bit block of
> > data. However, byte merging may only be done when the bytes within a
> > data phase are in a prefetchable address range. Configuration options:
> > [Disabled] [Enabled]

The wording seems to indicate that VIA ingenieers read the specifications.
May-be they misunderstood the 'may only be done' statement.

> > Why does the old driver boot fine with this enabled, and has the new
> > driver troubles booting then? The system seemed to run fine after the
> > long boot with the new driver and byte merge enabled, so it seemes that
> > only the boot gives troubles. The system didn't always boot till the end
> > with the new kernel and byte merge enabled btw, as it sometimes stopped
> > with the message: Kernel panic: for safety
> >
> > Anyway, thank you for the hint! It all works fine now. :-)
> >
> > 	Ookhoi


  Gérard.

Re: 2.4.9-ac17 Adaptec AIC7XXX problems (new driver, old one works fine) (solved)

[Justin T. Gibbs]

>> IIRC, the a7v is an AMD processor with VIA chipset. If you go into the
>> MB BIOS and disable all of the "Make my PCI bus go as fast as possible
>> even if this means violating the spec" options, the "new" aic7xxx
>> driver should work fine. I wish VIA would get a clue.
>
>It is indeed an AMD system with the VIA KT133 chipset.
>
>I played with the bios settings to find out with which option it would
>or would not give trouble. Under Advanced, CHIP Configuration the option
>Byte Merge has to be disabled to make the kernel boot fine with the new
>aic7xxx driver. This is with kernel 2.4.9-ac18
>
>The bios manual says:
>Byte Merge [Enabled by default]
>To optimize the data transfer on PCI, this merges a sequence of
>individual memory writes (bytes or words) into a single 32-bit block of
>data. However, byte merging may only be done when the bytes within a
>data phase are in a prefetchable address range. Configuration options:
>[Disabled] [Enabled]

The aic7xxx's register space only supports 8byte accesses.  The driver
only uses 8 byte accesses, but *may* touch consecutive registers with
consecutive accesses.  As the manual suggests, PCI only allows you to
merge these kinds of requests IFF the memory region is marked as
prefetchable.  The aic7xxx BAR register does not set the prefetchable
bit, and thus should never be placed in a prefetchable region.  If the
BIOS or Linux is putting these registers into a prefetchable region, then
that is the root of the bug.  If byte merging occurs regardless of the
type of region the registers are mapped into, then the byte merging
feature is broken.

>Why does the old driver boot fine with this enabled, and has the new
>driver troubles booting then?

The old driver issues a PCI read after every write to a register.  Writes
can be posted.  Reads cannot.  This forces the transactions to be executed
individually, but also has a tremendous performance impact (perhaps as much
as 10x the cost per write transaction).  There are times where a read is
required to synchronize state (e.g. ensure the chip has seen a write prior
to referring to some in-core data structures) and the new driver will issue
the extra reads only in that case.

--
Justin

Re: 2.4.9-ac17 Adaptec AIC7XXX problems (new driver, old one works fine) (solved)

[Justin T. Gibbs]

>Hrm... this makes me wonder if the Byte Merge option is keeping the PCI
>consistancy rules, or perhaps the aic7xxx driver is making assumptions
>about when PCI writes are actually occuring, without doing a read cycle
>between critical writes to make sure they actually happen.

See my other post on this subject.  The driver knows that a read is
required to ensure that a write is posted, but assumes that 8bit
transactions are forwarded as such, writes are issued in the order
retired (we use a memory barrier to avoid the compiler using a
different order), and that reads cannot pass posted writes.

--
Justin

Re: 2.4.9-ac17 Adaptec AIC7XXX problems (new driver, old one works fine) (solved)

[Justin T. Gibbs]

>The aic7xxx's register space only supports 8byte accesses.  The driver
					     ^byte^bit

--
Justin