Kernel 2.4.3 and new aic7xxx

Kernel 2.4.3 and new aic7xxx

[Rafael E. Herrera]

This is just to report on a the behavior of this driver. I've a dual
channel Adaptec 7895 controller. The adapter BIOS is configured to boot
from devices in channel B. I boot from  a disk connected to channel B
and when the kernel loads the driver the disks from channel A are seen
first, resulting in the drive names changing from, say sda to sdb. This
does not happen with 2.2.18 or 2.4.2. Is there an option to reverse the
order? I saw some of the options in the code, but none about this.

In any case, booting halts since the root file system can't be mounted.
It didn't fry my disks, either :)

-- 
     Rafael

Re: Kernel 2.4.3 and new aic7xxx

[Alan Cox]

> from devices in channel B. I boot from  a disk connected to channel B
> and when the kernel loads the driver the disks from channel A are seen
> first, resulting in the drive names changing from, say sda to sdb. This
> does not happen with 2.2.18 or 2.4.2. Is there an option to reverse the
> order? I saw some of the options in the code, but none about this.

at the moment the option to reverse the order is called using the old driver.

Re: Kernel 2.4.3 and new aic7xxx

[Justin T. Gibbs]

>This is just to report on a the behavior of this driver. I've a dual
>channel Adaptec 7895 controller. The adapter BIOS is configured to boot
>from devices in channel B. I boot from  a disk connected to channel B
>and when the kernel loads the driver the disks from channel A are seen
>first, resulting in the drive names changing from, say sda to sdb. This
>does not happen with 2.2.18 or 2.4.2. Is there an option to reverse the
>order? I saw some of the options in the code, but none about this.
>
>In any case, booting halts since the root file system can't be mounted.
>It didn't fry my disks, either :)

There is code in the driver to handle the channel B primary setting,
but I must have broken it recently.  I'll reproduce this today
and get you a patch.

--
Justin

Re: Kernel 2.4.3 and new aic7xxx

[Justin T. Gibbs]

>This is just to report on a the behavior of this driver. I've a dual
>channel Adaptec 7895 controller. The adapter BIOS is configured to boot
>from devices in channel B. I boot from  a disk connected to channel B
>and when the kernel loads the driver the disks from channel A are seen
>first, resulting in the drive names changing from, say sda to sdb. This
>does not happen with 2.2.18 or 2.4.2. Is there an option to reverse the
>order? I saw some of the options in the code, but none about this.

Can you provide me with a dmesg from a boot with aic7xxx=verbose?
I just tested this on a 3940AUW and the behavior was as expected.
Perhaps you have a motherboard based controller that has no seeprom?
I don't know how to detect flipped channels in that configuration
but I'll see what I can find out.

--
Justin

Re: Kernel 2.4.3 and new aic7xxx

[Doug Ledford]

"Justin T. Gibbs" wrote:
> 
> >This is just to report on a the behavior of this driver. I've a dual
> >channel Adaptec 7895 controller. The adapter BIOS is configured to boot
> >from devices in channel B. I boot from  a disk connected to channel B
> >and when the kernel loads the driver the disks from channel A are seen
> >first, resulting in the drive names changing from, say sda to sdb. This
> >does not happen with 2.2.18 or 2.4.2. Is there an option to reverse the
> >order? I saw some of the options in the code, but none about this.
> 
> Can you provide me with a dmesg from a boot with aic7xxx=verbose?
> I just tested this on a 3940AUW and the behavior was as expected.
> Perhaps you have a motherboard based controller that has no seeprom?
> I don't know how to detect flipped channels in that configuration
> but I'll see what I can find out.

Your driver uses the new PCI probe code, so there is no gaurantee that you'll
see channel A before channel B.  So, if you haven't seen channel A yet, you
won't already have read the Channel B Primary bit in the SEEPROM.  So, my
guess would be that you should modify the code so that when presented with the
B or C channel of a device, maybe you should make a call to load_seeprom() (or
whatever it is in your driver) for Channel A, grab the bits you need that are
only on channel A's SEEPROM, save them off, then read the Channel B/C SEEPROM
entry as needed.  That should solve the problem anyway.  Of course, it could
simply be something else that is wrong and I could be smoking crack ;-)



-- 

 Doug Ledford <dledford@redhat.com>  http://people.redhat.com/dledford
      Please check my web site for aic7xxx updates/answers before
                      e-mailing me about problems

Re: Kernel 2.4.3 and new aic7xxx

[Justin T. Gibbs]

>> Can you provide me with a dmesg from a boot with aic7xxx=verbose?
>> I just tested this on a 3940AUW and the behavior was as expected.
>> Perhaps you have a motherboard based controller that has no seeprom?
>> I don't know how to detect flipped channels in that configuration
>> but I'll see what I can find out.
>
>Your driver uses the new PCI probe code, so there is no gaurantee that you'll
>see channel A before channel B.

Unless he's actually hot-plugging the card, I am guarnateed to see both
the A and the B channel prior to actually registering with the SCSI subsystem
and from looking at the PCI probe code, function 0 is always added to the
pci device list before function 1.  It is true that my adapter sorting
code assumes that function 0 is seen prior to function 1, but I don't see
(yet) how that assumption is violated.  Since getting rid of the assumption
is easy enough, I'll do that.  All of the sorting stuff only works for devices
in the system at driver initialization.  In the hot plug case, you don't know
that more adapters will show up, so there is no way to defer registration like
you can on initial driver startup.

--
Justin

Re: Kernel 2.4.3 and new aic7xxx

[Rafael E. Herrera]

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

"Justin T. Gibbs" wrote:
> Can you provide me with a dmesg from a boot with aic7xxx=verbose?
> I just tested this on a 3940AUW and the behavior was as expected.
> Perhaps you have a motherboard based controller that has no seeprom?
> I don't know how to detect flipped channels in that configuration
> but I'll see what I can find out.

I've a Super P6SBS motherboard with a builtin dual channel Adaptec 7890
Ultra II scsi controller. I'm attaching the console grab when booting
2.4.3-pre2. The controller BIOS is configured to boot off the disk with
scsi id 0 on channel B.

-- 
     Rafael

[-- Attachment #2: log --]
[-- Type: text/plain, Size: 9962 bytes --]

                                                                    
Linux version 2.4.3-pre2 (raffo@inca) (gcc version 2.95.2 19991024 (release)) #1 Mon Mar 5 12:54:06 EST 2001
BIOS-provided physical RAM map:                                     
 BIOS-e820: 000000000009fc00 @ 0000000000000000 (usable)            
 BIOS-e820: 0000000000000400 @ 000000000009fc00 (reserved)          
 BIOS-e820: 0000000000020000 @ 00000000000e0000 (reserved)
 BIOS-e820: 000000000ff00000 @ 0000000000100000 (usable)
 BIOS-e820: 0000000000040000 @ 00000000fffc0000 (reserved)
On node 0 totalpages: 65536
zone(0): 4096 pages.
zone(1): 61440 pages.
zone(2): 0 pages.
Kernel command line: BOOT_IMAGE=linux_243 ro root=803 BOOT_FILE=/boot/vmlinuz_243 1 aic7xxx=verbose console=t8
Initializing CPU#0
Detected 701.600 MHz processor.
Console: colour VGA+ 80x25
Calibrating delay loop... 1399.19 BogoMIPS
Memory: 255488k/262144k available (1064k kernel code, 6268k reserved, 416k data, 188k init, 0k highmem)
Dentry-cache hash table entries: 32768 (order: 6, 262144 bytes)
Buffer-cache hash table entries: 16384 (order: 4, 65536 bytes)
Page-cache hash table entries: 65536 (order: 6, 262144 bytes)
Inode-cache hash table entries: 16384 (order: 5, 131072 bytes)
CPU: Before vendor init, caps: 0383fbff 00000000 00000000, vendor = 0
CPU: L1 I cache: 16K, L1 D cache: 16K
CPU: L2 cache: 256K
Intel machine check architecture supported.
Intel machine check reporting enabled on CPU#0.
CPU: After vendor init, caps: 0383fbff 00000000 00000000 00000000
CPU: After generic, caps: 0383fbff 00000000 00000000 00000000
CPU: Common caps: 0383fbff 00000000 00000000 00000000
CPU: Intel Pentium III (Coppermine) stepping 03
Enabling fast FPU save and restore... done.
Enabling unmasked SIMD FPU exception support... done.
Checking 'hlt' instruction... OK.
POSIX conformance testing by UNIFIX
mtrr: v1.37 (20001109) Richard Gooch (rgooch@atnf.csiro.au)
mtrr: detected mtrr type: Intel
PCI: PCI BIOS revision 2.10 entry at 0xfdb81, last bus=1
PCI: Using configuration type 1
PCI: Probing PCI hardware
Limiting direct PCI/PCI transfers.
isapnp: Scanning for Pnp cards...
isapnp: No Plug & Play device found
Linux NET4.0 for Linux 2.4
Based upon Swansea University Computer Society NET3.039
Initializing RT netlink socket
apm: BIOS version 1.2 Flags 0x03 (Driver version 1.14)
Starting kswapd v1.8
pty: 256 Unix98 ptys configured
block: queued sectors max/low 169725kB/56575kB, 512 slots per queue
RAMDISK driver initialized: 16 RAM disks of 4096K size 1024 blocksize
Uniform Multi-Platform E-IDE driver Revision: 6.31
ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx
PIIX4: IDE controller on PCI bus 00 dev 39
PIIX4: chipset revision 1
PIIX4: not 100% native mode: will probe irqs later
    ide0: BM-DMA at 0xffa0-0xffa7, BIOS settings: hda:DMA, hdb:pio
    ide1: BM-DMA at 0xffa8-0xffaf, BIOS settings: hdc:DMA, hdd:pio
hda: WDC AC310100B, ATA DISK drive
hdc: TOSHIBA DVD-ROM SD-M1212, ATAPI CD/DVD-ROM drive
ide0 at 0x1f0-0x1f7,0x3f6 on irq 14
ide1 at 0x170-0x177,0x376 on irq 15
hda: 19807200 sectors (10141 MB) w/512KiB Cache, CHS=1232/255/63, UDMA(33)
Partition check:
 /dev/ide/host0/bus0/target0/lun0: p1 p2 < p5 p6 > p3
Floppy drive(s): fd0 is 1.44M
FDC 0 is a post-1991 82077
Serial driver version 5.02 (2000-08-09) with MANY_PORTS SHARE_IRQ SERIAL_PCI ISAPNP enabled
ttyS00 at 0x03f8 (irq = 4) is a 16550A
ttyS01 at 0x02f8 (irq = 3) is a 16550A
Real Time Clock Driver v1.10d
SCSI subsystem driver Revision: 1.00
request_module[scsi_hostadapter]: Root fs not mounted
ahc_pci:0:14:1: Reading SEEPROM...done.
ahc_pci:0:14:1: Low byte termination Enabled
ahc_pci:0:14:1: High byte termination Enabled
ahc_pci:0:14:1: Downloading Sequencer Program... 404 instructions downloaded
ahc_pci:0:14:0: Reading SEEPROM...done.
ahc_pci:0:14:0: Low byte termination Enabled
ahc_pci:0:14:0: High byte termination Enabled
ahc_pci:0:14:0: Downloading Sequencer Program... 404 instructions downloaded
scsi0 : Adaptec AIC7XXX EISA/VLB/PCI SCSI HBA DRIVER, Rev 6.1.5
        <Adaptec aic7895 Ultra SCSI adapter>
        aic7895C: Wide Channel A, SCSI Id=7, 32/255 SCBs

scsi1 : Adaptec AIC7XXX EISA/VLB/PCI SCSI HBA DRIVER, Rev 6.1.5
        <Adaptec aic7895 Ultra SCSI adapter>
        aic7895C: Wide Channel B, SCSI Id=7, 32/255 SCBs

  Vendor: SEAGATE   Model: ST15150N          Rev: 4611
  Type:   Direct-Access                      ANSI SCSI revision: 02
Detected scsi disk sda at scsi0, channel 0, id 2, lun 0
(scsi0:A:2:1): Sending SDTR period c, offset f
(scsi0:A:2:1): Received SDTR period 19, offset f
        Filtered to period 19, offset f
(scsi0:A:2): 10.000MB/s transfers (10.000MHz, offset 15)
scsi0: target 2 synchronous at 10.0MHz, offset = 0xf
  Vendor: NAKAMICH  Model: MJ-5.16S          Rev: 1.02
  Type:   CD-ROM                             ANSI SCSI revision: 02
(scsi0:A:4:1): Sending SDTR period c, offset f
(scsi0:A:4:1): Received SDTR period 19, offset f
        Filtered to period 19, offset f
(scsi0:A:4): 10.000MB/s transfers (10.000MHz, offset 15)
scsi0: target 4 synchronous at 10.0MHz, offset = 0xf
  Vendor: NAKAMICH  Model: MJ-5.16S          Rev: 1.02
  Type:   CD-ROM                             ANSI SCSI revision: 02
(scsi0:A:4:2): Sending SDTR period c, offset f
(scsi0:A:4:2): Received SDTR period 19, offset f
        Filtered to period 19, offset f
  Vendor: NAKAMICH  Model: MJ-5.16S          Rev: 1.02
  Type:   CD-ROM                             ANSI SCSI revision: 02
(scsi0:A:4:3): Sending SDTR period c, offset f
(scsi0:A:4:3): Received SDTR period 19, offset f
        Filtered to period 19, offset f
  Vendor: NAKAMICH  Model: MJ-5.16S          Rev: 1.02
  Type:   CD-ROM                             ANSI SCSI revision: 02
(scsi0:A:4:4): Sending SDTR period c, offset f
(scsi0:A:4:4): Received SDTR period 19, offset f
        Filtered to period 19, offset f
  Vendor: NAKAMICH  Model: MJ-5.16S          Rev: 1.02
  Type:   CD-ROM                             ANSI SCSI revision: 02
(scsi0:A:4:5): Sending SDTR period c, offset f
(scsi0:A:4:5): Received SDTR period 19, offset f
        Filtered to period 19, offset f
  Vendor: TEAC      Model: CD-R56S4          Rev: 1.0P
  Type:   CD-ROM                             ANSI SCSI revision: 02
(scsi0:A:5:1): Sending SDTR period c, offset f
(scsi0:A:5:1): Received SDTR period 19, offset f
        Filtered to period 19, offset f
(scsi0:A:5): 10.000MB/s transfers (10.000MHz, offset 15)
scsi0: target 5 synchronous at 10.0MHz, offset = 0xf
(scsi0:A:2): 10.000MB/s transfers (10.000MHz, offset 15)
scsi0:0:2:0: Tagged Queuing enabled.  Depth 16
  Vendor: SEAGATE   Model: ST39173LW         Rev: 6246
  Type:   Direct-Access                      ANSI SCSI revision: 02
Detected scsi disk sdb at scsi1, channel 0, id 0, lun 0
(scsi1:A:0:1): Sending WDTR 1
(scsi1:A:0:1): Received WDTR 1 filtered to 1
(scsi1:A:0): 6.600MB/s transfers (16bit)
scsi1: target 0 using 16bit transfers
(scsi1:A:0:1): Sending SDTR period 2b, offset 8
(scsi1:A:0:1): Received SDTR period 2b, offset 8
        Filtered to period 2b, offset 8
(scsi1:A:0): 11.626MB/s transfers (5.813MHz, offset 8, 16bit)
scsi1: target 0 synchronous at 5.7MHz, offset = 0x8
  Vendor: COMPAQ    Model: WDE4360W          Rev: 1.52
  Type:   Direct-Access                      ANSI SCSI revision: 02
Detected scsi disk sdc at scsi1, channel 0, id 8, lun 0
(scsi1:A:8:1): Sending WDTR 1
(scsi1:A:8:1): Received WDTR 1 filtered to 1
(scsi1:A:8): 6.600MB/s transfers (16bit)
scsi1: target 8 using 16bit transfers
(scsi1:A:8:1): Sending SDTR period 2b, offset 8
(scsi1:A:8:1): Received SDTR period 2d, offset 8
        Filtered to period 2d, offset 8
(scsi1:A:8): 11.110MB/s transfers (5.555MHz, offset 8, 16bit)
scsi1: target 8 synchronous at 5.0MHz, offset = 0x8
(scsi1:A:0): 11.626MB/s transfers (5.813MHz, offset 8, 16bit)
scsi1:0:0:0: Tagged Queuing enabled.  Depth 16
(scsi1:A:8): 11.110MB/s transfers (5.555MHz, offset 8, 16bit)
scsi1:0:8:0: Tagged Queuing enabled.  Depth 16
(scsi0:A:2:0): Sending SDTR period c, offset f
(scsi0:A:2:0): Received SDTR period 19, offset f
        Filtered to period 19, offset f
(scsi0:A:2:0): Sending SDTR period 19, offset f
(scsi0:A:2:0): Received SDTR period 19, offset f
        Filtered to period 19, offset f
SCSI device sda: 8388315 512-byte hdwr sectors (4295 MB)
 /dev/scsi/host0/bus0/target2/lun0: p1
(scsi1:A:0:0): Sending WDTR 1
(scsi1:A:0:0): Received WDTR 1 filtered to 1
(scsi1:A:0): 6.600MB/s transfers (16bit)
scsi1: target 0 using asynchronous transfers
(scsi1:A:0:0): Sending SDTR period 2b, offset 8
(scsi1:A:0:0): Received SDTR period 2b, offset 8
        Filtered to period 2b, offset 8
(scsi1:A:0): 11.626MB/s transfers (5.813MHz, offset 8, 16bit)
scsi1: target 0 synchronous at 5.7MHz, offset = 0x8
SCSI device sdb: 17783240 512-byte hdwr sectors (9105 MB)
 /dev/scsi/host1/bus0/target0/lun0: p1 p2 p3 p4
(scsi1:A:8:0): Sending WDTR 1
(scsi1:A:8:0): Received WDTR 1 filtered to 1
(scsi1:A:8): 6.600MB/s transfers (16bit)
scsi1: target 8 using asynchronous transfers
(scsi1:A:8:0): Sending SDTR period 2d, offset 8
(scsi1:A:8:0): Received SDTR period 2d, offset 8
        Filtered to period 2d, offset 8
(scsi1:A:8): 11.110MB/s transfers (5.555MHz, offset 8, 16bit)
scsi1: target 8 synchronous at 5.0MHz, offset = 0x8
SCSI device sdc: 8386000 512-byte hdwr sectors (4294 MB)
 /dev/scsi/host1/bus0/target8/lun0: p1 p2
LVM version 0.9.1_beta2  by Heinz Mauelshagen  (18/01/2001)
lvm -- Driver successfully initialized
NET4: Linux TCP/IP 1.0 for NET4.0
IP Protocols: ICMP, UDP, TCP, IGMP
IP: routing cache hash table of 2048 buckets, 16Kbytes
TCP: Hash tables configured (established 16384 bind 16384)
NET4: Unix domain sockets 1.0/SMP for Linux NET4.0.
devfs: v0.102 (20000622) Richard Gooch (rgooch@atnf.csiro.au)
devfs: boot_options: 0x2
VFS: Cannot open root device "803" or 08:03
Please append a correct "root=" boot option
Kernel panic: VFS: Unable to mount root fs on 08:03

Re: Kernel 2.4.3 and new aic7xxx

[Justin T. Gibbs]

>I've a Super P6SBS motherboard with a builtin dual channel Adaptec 7890
>Ultra II scsi controller. I'm attaching the console grab when booting
>2.4.3-pre2. The controller BIOS is configured to boot off the disk with
>scsi id 0 on channel B.

It looks like Doug was right to think that the functions can be
presented to the device driver in reverse order.  I should have
a patch for you early tomorrow.

--
Justin

Re: Kernel 2.4.3 and new aic7xxx

[Linus Torvalds]

In article <200103070546.f275keO22502@aslan.scsiguy.com>,
Justin T. Gibbs <gibbs@scsiguy.com> wrote:
>>I've a Super P6SBS motherboard with a builtin dual channel Adaptec 7890
>>Ultra II scsi controller. I'm attaching the console grab when booting
>>2.4.3-pre2. The controller BIOS is configured to boot off the disk with
>>scsi id 0 on channel B.
>
>It looks like Doug was right to think that the functions can be
>presented to the device driver in reverse order.  I should have
>a patch for you early tomorrow.

It should be easy enough to make the PCI layer sort the devices, and you
might not be the only driver that wants to see subfunction 0 before
subfunction 1.

I suspect it's easier to just make the PCI layer call the probe function
in that order, instead of working around it in your driver. Jeff?

		Linus

Re: Kernel 2.4.3 and new aic7xxx

[Aaron Tiensivu]

> I suspect it's easier to just make the PCI layer call the probe function
> in that order, instead of working around it in your driver. Jeff?

Would 'pci=reverse' do the trick already?

Re: Kernel 2.4.3 and new aic7xxx

[Rafael E. Herrera]

Aaron Tiensivu wrote:
> 
> > I suspect it's easier to just make the PCI layer call the probe function
> > in that order, instead of working around it in your driver. Jeff?
> 
> Would 'pci=reverse' do the trick already?

Get a unknown option warning message when using that.

-- 
     Rafael

Re: Kernel 2.4.3 and new aic7xxx

[Jeff Garzik]

Linus Torvalds wrote:
> I suspect it's easier to just make the PCI layer call the probe function
> in that order, instead of working around it in your driver.

That seems like a really good idea, especially in light of the fact that
some drivers are doing (have to do?) -reverse- order PCI scanning.

I would prefer to sort the list at probe not boot time.  That makes it
easy to reverse the order on the fly, depending on what the driver
requests at runtime.  It's SMP-friendly, because I can grab a private
copy of the PCI device list, sort it, and scan it.  You don't have to
re-sort at every pci_insert_device, for hotplug machines.  The only
potential downside is I need to check and see if the bootmem case needs
to be handled, when making a private copy of the pci devices list for
sorting.

-- 
Jeff Garzik       | "You see, in this world there's two kinds of
Building 1024     |  people, my friend: Those with loaded guns
MandrakeSoft      |  and those who dig. You dig."  --Blondie

Re: Kernel 2.4.3 and new aic7xxx

[Justin T. Gibbs]

>I would prefer to sort the list at probe not boot time.  That makes it
>easy to reverse the order on the fly, depending on what the driver
>requests at runtime.  It's SMP-friendly, because I can grab a private
>copy of the PCI device list, sort it, and scan it.  You don't have to
>re-sort at every pci_insert_device, for hotplug machines.  The only
>potential downside is I need to check and see if the bootmem case needs
>to be handled, when making a private copy of the pci devices list for
>sorting.

How often is the list manipulated?  My guess is not very often.
You can allow people to read the list without taking a spinlock and
only acquire the spinlock on list manipulations.  Inserting an
element can be performed atomically so there isn't an SMP issue
so long as you don't allow more than one processor to insert at
the same time.  This would allow you to perform insertion sort
meaning that everything from /proc to device drivers auto-magically
sees the devices in the order they were probed.  For hot plug devices
you might want to insert them at the end to follow the "order probed"
motif.

--
Justin

Re: Kernel 2.4.3 and new aic7xxx

[Jeff Garzik]

"Justin T. Gibbs" wrote:
> How often is the list manipulated?  My guess is not very often.

Modified very infrequently...  at boot, and for each hotplug insertion
or removal.  It's not even read very often.


> You can allow people to read the list without taking a spinlock and
> only acquire the spinlock on list manipulations.  Inserting an
> element can be performed atomically so there isn't an SMP issue
> so long as you don't allow more than one processor to insert at
> the same time.  This would allow you to perform insertion sort
> meaning that everything from /proc to device drivers auto-magically
> sees the devices in the order they were probed.

I was just thinking the same thing.  list_splice and an insertion sort
can be used instead of all that allocation crap.


> For hot plug devices
> you might want to insert them at the end to follow the "order probed"
> motif.

hmmm..  Is there a reason why this would be -needed-?  It wouldn't be
hard to implement, but I would rather not have drivers dealing with a
list whose normal state is defined as "mostly sorted"...

-- 
Jeff Garzik       | "You see, in this world there's two kinds of
Building 1024     |  people, my friend: Those with loaded guns
MandrakeSoft      |  and those who dig. You dig."  --Blondie

Re: Kernel 2.4.3 and new aic7xxx

[Justin T. Gibbs]

>hmmm..  Is there a reason why this would be -needed-?  It wouldn't be
>hard to implement, but I would rather not have drivers dealing with a
>list whose normal state is defined as "mostly sorted"...

That's the wrong definition.  The list is "sorted by probe order".

--
Justin