Messages in this thread | | | From | Brian Schau <> | Subject | FW: PCI changes -- SCSI reordering question | Date | Fri, 10 Apr 1998 12:51:32 +0200 |
| |
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] | |