I have a machine with 3 of these controllers (a 4 CPU server). The
3 controllers are:
ncr53c810a-0: rev=0x23, base=0xfa101000, io_port=0x2000, irq=58
ncr53c810a-0: ID 7, Fast-10, Parity Checking
ncr53c896-1: rev=0x01, base=0xfe004000, io_port=0x3000, irq=57
ncr53c896-1: ID 7, Fast-40, Parity Checking
ncr53c896-2: rev=0x01, base=0xfe004400, io_port=0x3400, irq=56
ncr53c896-2: ID 7, Fast-40, Parity Checking
ncr53c896-2: on-chip RAM at 0xfe002000
I'd like to be able to make a kernel with the driver compiled in and
no loadable module support. It don't see how to do this from the
documentation -- it seems to require a separate module loaded for
each controller. When I compile it in, it only see the 1st controller
and the boot partition I think is on the 3rd. Any ideas?
This problem is present in the 2.2.x series as well as 2.4.x (x up to 2).
Thanks,
-linda
--
L A Walsh | Trust Technology, Core Linux, SGI
[email protected] | Voice: (650) 933-5338
On Sat, 24 Mar 2001, LA Walsh wrote:
> I have a machine with 3 of these controllers (a 4 CPU server). The
> 3 controllers are:
> ncr53c810a-0: rev=0x23, base=0xfa101000, io_port=0x2000, irq=58
> ncr53c810a-0: ID 7, Fast-10, Parity Checking
> ncr53c896-1: rev=0x01, base=0xfe004000, io_port=0x3000, irq=57
> ncr53c896-1: ID 7, Fast-40, Parity Checking
> ncr53c896-2: rev=0x01, base=0xfe004400, io_port=0x3400, irq=56
> ncr53c896-2: ID 7, Fast-40, Parity Checking
> ncr53c896-2: on-chip RAM at 0xfe002000
>
> I'd like to be able to make a kernel with the driver compiled in and
> no loadable module support. It don't see how to do this from the
> documentation -- it seems to require a separate module loaded for
> each controller. When I compile it in, it only see the 1st controller
> and the boot partition I think is on the 3rd. Any ideas?
The driver tries to detect all controllers it supports. Since the
ncr53c8xx supports both the 810a and the 896, all your controllers should
have been detected. When loaded as a module, the driver must be loaded
once (btw, a seconf load should fail).
> This problem is present in the 2.2.x series as well as 2.4.x (x up to 2).
What hardware are you using (CPU, Core Logic and tutti quanti) ?
Is the 896 on PCI BUS #0 or on some sort of secondary PCI BUS ?
Does the sym53c8xx driver show same behaviour ?
G?rard.
Hello,
You sent me by private e-mail, the /proc/pci information of your system.
I donnot see anything wrong in these data. If the problem is PCI-related,
you would probably have better help by sending these infos to the l-k
list, in my opinion.
To be honest (I may be wrong here - sorry if I am), I am under the
impression that you may well be barking up the wrong tree.
Just quoted here an exerpt of your mail that let me think so:
> > When I compile it in, it only see the 1st controller
> > and the boot partition I think is on the 3rd.
^^^^^
Knowing instead is required, here, IMO.
1) controllers attach SCSI devices, notably hard disks
2) hard disks contain partitions
3) partitions contain file systems.
4) the kernel needs to *know* the root file system to boot your system.
What about point 4 ?
i.e : how did you tell to the boot loader the root partition name to
pass to the kernel at boot ?
If you are using lilo and have configured it for user to be prompted
before running the kernel, you may try to enter your root partition name
when you are prompted by lilo. For example if root fs is on /dev/sda5:
lilo: your_lilo_config_entry_name root=/dev/sda5 ro
Just replace the lilo_config_entry_name and the root partition name by the
values that match your configuration.
G?rard.
On Sat, 24 Mar 2001, G?rard Roudier wrote:
> On Sat, 24 Mar 2001, LA Walsh wrote:
>
> > I have a machine with 3 of these controllers (a 4 CPU server). The
> > 3 controllers are:
> > ncr53c810a-0: rev=0x23, base=0xfa101000, io_port=0x2000, irq=58
> > ncr53c810a-0: ID 7, Fast-10, Parity Checking
> > ncr53c896-1: rev=0x01, base=0xfe004000, io_port=0x3000, irq=57
> > ncr53c896-1: ID 7, Fast-40, Parity Checking
> > ncr53c896-2: rev=0x01, base=0xfe004400, io_port=0x3400, irq=56
> > ncr53c896-2: ID 7, Fast-40, Parity Checking
> > ncr53c896-2: on-chip RAM at 0xfe002000
> >
> > I'd like to be able to make a kernel with the driver compiled in and
> > no loadable module support. It don't see how to do this from the
> > documentation -- it seems to require a separate module loaded for
> > each controller. When I compile it in, it only see the 1st controller
> > and the boot partition I think is on the 3rd. Any ideas?
>
> The driver tries to detect all controllers it supports. Since the
> ncr53c8xx supports both the 810a and the 896, all your controllers should
> have been detected. When loaded as a module, the driver must be loaded
> once (btw, a seconf load should fail).
>
> > This problem is present in the 2.2.x series as well as 2.4.x (x up to 2).
>
> What hardware are you using (CPU, Core Logic and tutti quanti) ?
> Is the 896 on PCI BUS #0 or on some sort of secondary PCI BUS ?
> Does the sym53c8xx driver show same behaviour ?
>
> G?rard.
Here is the 'alternate' output when the ncr53c8xx driver is
compiled in:
SCSI subsystem driver Revision: 1.00
scsi-ncr53c7,8xx : at PCI bus 0, device 8, function 0
scsi-ncr53c7,8xx : warning : revision of 35 is greater than 2.
scsi-ncr53c7,8xx : NCR53c810 at memory 0xfa101000, io 0x2000, irq 58
scsi0 : burst length 16
scsi0 : NCR code relocated to 0x37d6c610 (virt 0xf7d6c610)
scsi0 : test 1 started
scsi0 : NCR53c{7,8}xx (rel 17)
request_module[block-major-8]: Root fs not mounted
VFS: Cannot open root device "807" or 08:07
Please append a correct "root=" boot option
Kernel panic: VFS: Unable to mount root fs on 08:07
-----
Note how this compares to the case where the driver is a module:
(note scsi0 was an IDE emulation in this setup -- something also removed in
the above setup)
ncr53c8xx: at PCI bus 0, device 8, function 0
ncr53c8xx: 53c810a detected
ncr53c8xx: at PCI bus 1, device 3, function 0
ncr53c8xx: 53c896 detected
ncr53c8xx: at PCI bus 1, device 3, function 1
ncr53c8xx: 53c896 detected
ncr53c810a-0: rev=0x23, base=0xfa101000, io_port=0x2000, irq=58
ncr53c810a-0: ID 7, Fast-10, Parity Checking
ncr53c810a-0: restart (scsi reset).
ncr53c896-1: rev=0x01, base=0xfe004000, io_port=0x3000, irq=57
ncr53c896-1: ID 7, Fast-40, Parity Checking
ncr53c896-1: on-chip RAM at 0xfe000000
ncr53c896-1: restart (scsi reset).
ncr53c896-1: Downloading SCSI SCRIPTS.
ncr53c896-2: rev=0x01, base=0xfe004400, io_port=0x3400, irq=56
ncr53c896-2: ID 7, Fast-40, Parity Checking
ncr53c896-2: on-chip RAM at 0xfe002000
ncr53c896-2: restart (scsi reset).
ncr53c896-2: Downloading SCSI SCRIPTS.
scsi1 : ncr53c8xx - version 3.2a-2
scsi2 : ncr53c8xx - version 3.2a-2
scsi3 : ncr53c8xx - version 3.2a-2
scsi : 4 hosts.
Vendor: SEAGATE Model: ST318203LC Rev: 0002
Type: Direct-Access ANSI SCSI revision: 02
Detected scsi disk sda at scsi2, channel 0, id 1, lun 0
Vendor: SGI Model: SEAGATE ST318203 Rev: 2710
Type: Direct-Access ANSI SCSI revision: 02
Detected scsi disk sdb at scsi2, channel 0, id 2, lun 0
Vendor: SGI Model: SEAGATE ST336704 Rev: 2742
--------
This is on a 4x550 PIII(Xeon) system. The 2nd two
controllers are on pci bus 1. The boot disk is sda, which is off of
scsi2 in the working example, or scsi1 in the non-working example.
It seems that compiling it in somehow causes controllers
1 and 2 (which are off of the 2nd pci bus, "1", to get missed during
scsi initialization. Is there a parameter I need to pass to the
ncr53c8xx driver to get it to scan the 2nd bus?
> Here is the 'alternate' output when the ncr53c8xx driver is
> compiled in:
>
> SCSI subsystem driver Revision: 1.00
> scsi-ncr53c7,8xx: at PCI bus 0, device 8, function 0
> scsi-ncr53c7,8xx: warning : revision of 35 is greater than 2.
> scsi-ncr53c7,8xx: NCR53c810 at memory 0xfa101000, io 0x2000, irq 58
> scsi0: burst length 16
> scsi0: NCR code relocated to 0x37d6c610 (virt 0xf7d6c610)
> scsi0: test 1 started
> scsi0: NCR53c{7,8}xx (rel 17)
> request_module[block-major-8]: Root fs not mounted
> VFS: Cannot open root device "807" or 08:07
> Please append a correct "root=" boot option
> Kernel panic: VFS: Unable to mount root fs on 08:07
> -----
I don't believe that's the ncr53c8xx driver. That looks like the
53c7,8xx driver. I don't think it's really maintained any more, or
frankly that it could ever handle a 53c896 card, which could explain
it only seeing the 810a and not the 896 your boot disk is on.
You really want to use the sym53c8xx driver anyway - it is the one
being worked on in earnest now. I believe it will pick up 810a
controllers as well.
(yes that's three ncr/symbios/lsi drivers in the kernel - "53c7,8xx",
"ncr53c8xx" and "sym53c8xx" ...)
M
LA Walsh <[email protected]> ?crit :
> Here is the 'alternate' output when the ncr53c8xx driver is
> compiled in:
>
> SCSI subsystem driver Revision: 1.00
> scsi-ncr53c7,8xx : at PCI bus 0, device 8, function 0
> scsi-ncr53c7,8xx : warning : revision of 35 is greater than 2.
> scsi-ncr53c7,8xx : NCR53c810 at memory 0xfa101000, io 0x2000, irq 58
[...]
Even if the ncr53c8xx is compiled in, these messages only appear
in 53c7,8xx.c. Did you give a try to:
<Y> SCSI support
<Y> SCSI disk support
<Y> NCR53C8XX SCSI support
with no other ncr/symbios driver ?
--
Ueimor
On Sun, 25 Mar 2001, LA Walsh wrote:
> Here is the 'alternate' output when the ncr53c8xx driver is
> compiled in:
>
> SCSI subsystem driver Revision: 1.00
> scsi-ncr53c7,8xx : at PCI bus 0, device 8, function 0
> scsi-ncr53c7,8xx : warning : revision of 35 is greater than 2.
> scsi-ncr53c7,8xx : NCR53c810 at memory 0xfa101000, io 0x2000, irq 58
> scsi0 : burst length 16
> scsi0 : NCR code relocated to 0x37d6c610 (virt 0xf7d6c610)
> scsi0 : test 1 started
> scsi0 : NCR53c{7,8}xx (rel 17)
> request_module[block-major-8]: Root fs not mounted
> VFS: Cannot open root device "807" or 08:07
> Please append a correct "root=" boot option
> Kernel panic: VFS: Unable to mount root fs on 08:07
> -----
The 53c7,8xx driver is a different driver that hasn't been updated for the
support of the 53C896. I figure out that you already have been replied
upon this point.
For your machine configuration you want to use either the NCR53C8XX driver
or the SYM53C8XX driver. The SYM53C8XX driver has a better support for the
896 as it handles phase mismatch from SCRIPTS. The both drivers share the
same kernel config options for simplicity (in fact the SYM53C8XX driver
just steals the NCR53C8XX config options).
Go to the SCSI low-level configuration form under make menuconfig for
example and configure the SYM53C8XX driver as 'Y' and the NCR53C8XX driver
as 'N'. Btw, also configure 'N' the 53c7,8xx driver to avoid conflicts.
You may also have a look at the help entries for these drivers and at the
file linux/drivers/scsi/README.ncr53c8xx (also applies to SYM53C8XX).
A driver named SYM-2 that replaces both the NCR53C8XX and the SYM53C8XX
drivers also exists. This driver is multi-platform and for now has been
added support for Linux, FreeBSD and NetBSD. It is intended to replace the
NCR53C8XX and the SYM53C8XX. It is not included in Linux for now since we
only have _stable_ kernels at the moment and the NCR+SYM driver pair is
the current _stable_ support for SYMBIOS 53C8XX controllers.
If you want to try SYM-2: ftp://ftp.tux.org/roudier/README-drivers-linux
G?rard.