From: Brian Geisel <[EMAIL PROTECTED]>
Date: Thu, 16 Sep 1999 08:46:40 -0400
I'm having trouble with a system booting with an Intel SC450NX
motherboard. The board has Quad Xeon 450Mhz with a built-in Symbios 53C896
dual SCSI3 Ultra2 and a Symbios 5353C810AE Narrow Fast SCSI controller. It
is also using the 0-Channel Mylex AcceleRAID 200 card.
I'm quite familiar with the SC450NX. Have you disabled the Symbios BIOS in the
S450NX motherboard BIOS Configuration? If not, then the onboard chips will
attempt to access the drives, as will the AcceleRAID 200, and you will have
serious problems. After you've done that, you also need to be sure you're
running new enough AcceleRAID firmware (4.06-0-60 or above, I believe), so that
the AcceleRAID will "mark" the Symbios chips as in use by the AcceleRAID so
that the ncr53c8xx driver will ignore them.
The System boots fine normally. The Symbios is built into the kernel and
I believe the DAC960 is as well (I believe because I can't actually get my
hands on the system - That's the catch to the whole thing). The problem
occurs when they use boot disks. I work for Microlite Corporation and we
make a boot/recovery solution that builds custom boot disks. Now we're
booting with LILO (just like they normally do) and have checked their
lilo.conf file for any special command line parameters. There are none.
We're also using the same kernel they use to boot with, and have grabbed
any loadable modules they may have installed.
When the system starts to boot it gets to the NCR/Symbios. It then finds
three drives on that card (which I'm told it doesn't do from the HD, they
appear instead as a RAID drive on the AcceleRAID). This is in the midst of
several error messages, all of which come from an assert line in the NCR
driver (line 7780 - while it's looking up the ccb in ncr_int_sir).
This problem doesn't occur when booting from the HD which is what is
really confusing me.
Ok, so here's the information I'm really looking for:
Should this be using the sym53c8xx driver instead of the ncr53c8xx driver?
What might be the differences there, or what they should be used for?
Is there any chance this is modified by the SMP stuff? My first thought is
no, but I have heard stuff floating around about problems with LILO booting
Symbios cards on SMP systems. (Something about it taking part of the 640k
that LILO expects is unused).
Anything I should know about the boot process between these two cards?
Should the NCR/Symbios find the drives and then the DAC960 'take' them, or
should this have already happened in hardware? Does one need to be loaded
before the other? Anything else that might be special under this
configuration, parameters, etc?
The standard version of LILO has problems on the SC450NX due to the location of
the Extended BIOS Data Area. Apply the following patch the the LILO 21 source
and you should get a LILO that will work correctly.
Leonard
--- lilo/Makefile- Fri Dec 4 15:35:07 1998
+++ lilo/Makefile Wed Mar 17 01:04:07 1999
@@ -24,7 +24,7 @@
# VARSETUP Enables use of variable-size setup segments.
# XL_SECS=n Support for extra large (non-standard) floppies.
-CONFIG=-DIGNORECASE -DVARSETUP -DREWRITE_TABLE
+CONFIG=-DIGNORECASE -DVARSETUP -DREWRITE_TABLE -DLARGE_EBDA
# End of configuration variables
@@ -39,12 +39,12 @@
GO=-DGO=0x`sed '/go/s/^.*go 0 \(....\) A.*$$/\1/p;d' first.lis`
SHELL=/bin/sh
-CC=cc
+CC=gcc
CPP=$(CC) -E
AS86=as86 -0 -a
LD86=ld86 -0
-CFLAGS=-Wall -g $(PCONFIG)
+CFLAGS=-Wall $(DD_CFLAGS) $(PCONFIG)
LDFLAGS=#-Xlinker -qmagic
OBJS=lilo.o map.o geometry.o boot.o device.o common.o bsect.o cfg.o temp.o \
--- lilo/second.S- Fri Dec 4 15:20:07 1998
+++ lilo/second.S Wed Mar 17 01:03:53 1999
@@ -830,9 +830,20 @@
call load1
seg es
mov CL_MAGIC_ADDR,#CL_MAGIC ! set magic number
+#ifndef LCF_LARGE_EBDA
seg es
mov word ptr CL_OFFSET,#PARMLINE+SECOND_SS
! set parameter line offset
+#else
+ mov di,#0x8000
+ mov si,#PARMLINE
+ mov cx,#CL_LENGTH
+ rep
+ movsb
+ seg es
+ mov word ptr CL_OFFSET,#0x8000
+ ! set parameter line offset
+#endif
pop si ! restore SI
lodsw ! get flags bit map
mov bx,ax
-
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to [EMAIL PROTECTED]
