lkml.org 
[lkml]   [1998]   [Apr]   [10]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectFW: PCI changes -- SCSI reordering question
Date
Hi,


I have been in exactly the same situation as the two gentlemen below.
I (and my colleagues at Fleggaard) tried to add an extern disk-array to
an onboard controller (aic7xxx) in a machine which had to boot on
devices connected to a DPT card .... (that was a long sentence!).
A look into linux/drivers/scsi/hosts.c reveals that the scsi-codes tries
to register the hosts in a strict order. Too bad for us ...
eata_dma (DPT) is detected after the aic7xxx --- bye, bye root disk!


Solution: Apply the attached hack/patch. It patches cleanly
against 2.0.33.

How to patch:

1) cd /into/dir/where/linux/is/stored
# ie. if the path to your linux-source tree is /usr/src/linux,
you should cd into /usr/src
2) copy the osd_patch.diff.gz into this 'base-linux-source'
directory
3) gunzip osd_patch.diff.gz
4) patch -p0 < osd_patch.diff
5) now recompile your kernel (2.0.33) as usual




What files have been touched?

1) linux/init/main.c (a couple of lines)
2) linux/drivers/scsi/hosts.c (a lot of lines)
3) linux/drivers/scsi/hosts.h (a couple of lines)
4) linux/drivers/scsi/scsi_syms.c (a couple of lines)




What will it give you?

You can now specify the 'scsi_order' option in lilo:

append = "scsi_order=eata_dma,aic7xxx"

The 'scsi_order' tells the kernel the order it should register the
hosts. This should guarantee that disks on 'eata_dma' at any time
will be named /dev/sdaX, and that disks on 'aic7xxx' will be named
/dev/sdbX.




Other examples.

Consider the following setup. (in the following, 'advansys-card' is a
card driven by the advansys-driver. Likewise for 'aic7xxx-card' and
'eata_dma-card'). A server is equipped with three scsi-cards:

1) Advansys-card. Attached: Flatbed-scanner.
2) Aic7xxx-card. Attached: Nothing.
3) Eata_dma-card. Attached: Bootdisk.

The boot disk is on the eata_dma card. Under normal circumstances
the eata_dma-card will be detected last (list order is advansys,
aic7xxx, eata_dma). Here it doesn't matter as there are no disks on
the other cards. Now add a disk to the aic7xxx-card:

1) Advansys-card. Attached: Flatbed-scanner.
2) Aic7xxx-card. Attached: Disk.
3) Eata_dma-card. Attached: Bootdisk.

Kaboom?!?! The aic7xxx-card is detected before the eata_dma-card.
Normally this would mean "Bye, bye, root/boot disk!". Write one of
these in lilo.conf:

1) append = "scsi_order=eata_dma,aic7xxx,advansys"
2) append = "scsi_order=eata_dma,advansys,aic7xxx"
3) append = "scsi_order=eata_dma,aic7xxx"
4) append = "scsi_order=eata_dma,advansys"
5) append = "scsi_order=eata_dma"


If the kernel is compiled with, say, support for 3 scsi-cards, and
they're not all listed as argument to the 'scsi_order' option, the
detection-order will be:

1) cards listed as arguments to the 'scsi_order' option
2) the rest, from the start of the 'builtin' scsi-list




What cards can be specified & what are their names?

Have a look at linux/drivers/scsi/hosts.c (2.0.33, line 222). This is
the 'builtin' list. It starts like this:

scsi_list builtin_scsi_hosts[] =
{
#ifdef CONFIG_AMIGA
#ifdef CONFIG_A3000_SCSI
{ "a3000", 0,
A3000_SCSI },
#endif
...

First entry ("a3000") is the name of the card. This is also the name
you should supply to 'scsi_order'. Scroll down to line 332
("eata_dma") or line 352 ("ppa") --- you get the idea.




What platforms have the patch been tested on?

Linux-i586 (Suse 5.0): eata_dma & aic7xxx NO_SMP!
Linux-i686 (Unifix 2.0): eata_dma & aic7xxx SMP!

... both platforms runs 2.0.33.




Todo.

1) It would be nice if the patch went into the kernel source
tree ( :o).
2) It would be nice if the Scsi_Host_Template were extended
with the following two fields:

char scsi_name[40];
int position;

# (this would place the responsibility of naming the cards
at the developers of these cards. 'builtin_scsi_hosts[]' would then
look as in the older days ...)




Last words.

I don't think/hope this is considered a 'final' solution. The only
'right' thing to do, is to implement what is described below (HP-UX &
Solaris works this way --- why shouldn't linux?). But until then,
I think my solution will keep the crowd happy?



Thank you for your time & have a nice easter-holiday! (... I will!)



Sincerely,


Brian Schau



> -----Original Message-----
> From: Jon Lewis [SMTP:jlewis@inorganic5.fdt.net]
> Sent: Friday, April 10, 1998 6:18 AM
> To: Manuel J. Galan
> Cc: Linux Kernel List
> Subject: Re: PCI changes -- SCSI reordering question
>
> On Thu, 9 Apr 1998, Manuel J. Galan wrote:
>
> > New SCSI reordering can be a real mess, I was lucky not having
> > disks on second adapter, else sde -> sda, sda -> sdb, etc.
> > Nice cycle ;-), mad /etc/fstab, and panic on boot.
>
> I've not kept up with the talk on devfs...but has it been considered
> that
> a naming scheme sort of like the following be used?
>
> /dev/scsi/ncr53c8xx/0/d0l0s0
>
> i.e. controler / number / id lun partition
> type within
> type
>
> That would remove the ambiguity of having a controller0, controller1,
> etc...since SCSI host probing order can change, but the driver name is
> less likely to, and you wouldn't have to worry about device names
> changing
> just because you add a device or controller.
>
> Adding 2 disks to separate controllers on a 2.0.x system that already
> had
> several disks on each, I managed to really confuse myself.
>
> ------------------------------------------------------------------
> Jon Lewis <jlewis@fdt.net> | http://noagent.com/?jl1 for cheap
> Network Administrator | life insurance over the net.
> Florida Digital Turnpike |
> ______http://inorganic5.fdt.net/~jlewis/pgp for PGP public key____
>
>
> -
> To unsubscribe from this list: send the line "unsubscribe
> linux-kernel" in
> the body of a message to majordomo@vger.rutgers.edu
[unhandled content-type:application/octet-stream]
\
 
 \ /
  Last update: 2005-03-22 13:42    [W:0.026 / U:1.864 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site