[PATCH: NEW SUBARCHITECTURE FOR 2.5.21] support for NCR voyager (3/4/5xxx series)

[PATCH: NEW SUBARCHITECTURE FOR 2.5.21] support for NCR voyager (3/4/5xxx series)

[James Bottomley]

This patch adds SMP (and UP) support for voyager which is an (up to 32 way) 
SMP microchannel non-PC architecture.

There's basically nothing different from the 2.5.15 one except for updates and 
changes to the arch-split and a few #include file additions.

The patch is in two parts:  The i386 sub-architecture split is separated from 
the addition of the voyager components

http://www.hansenpartnership.com/voyager/files/arch-split-2.5.21.diff (165k)
http://www.hansenpartnership.com/voyager/files/voyager-2.5.21.diff (148k)

(The split diff is pretty huge because it's actually moving files about).  You 
must apply the split diff before applying the voyager one.

These two patches are also available as separate bitkeeper trees (the voyager 
tree is a superset of the arch-split one):

http://linux-voyager.bkbits.net/voyager-2.5
http://linux-voyager.bkbits.net/arch-split-2.5

James Bottomley

Re: [PATCH: NEW SUBARCHITECTURE FOR 2.5.21] support for NCR voyager (3/4/5xxx series)

[Andrey Panin]

[-- Attachment #1.1: Type: text/plain, Size: 608 bytes --]


Attached patch is needed to compile kernel with Voyager patch applied
for the SMP PC machine.

Also some questions, mostly related to arch-split patch:

[Q1] Will it be better to  create separate directory for PC architecture
and split some PC'isms from arch/i386/generic ? Right now it contains
acpi.c, bootflag.c and dmi_scan.c which are not generic in any way :)

[Q2] May be directory naming like mach-visws, mach-voyager and possible 
mach-pc will be more convinent ?

-- 
Andrey Panin            | Embedded systems software engineer
pazke@orbita1.ru        | PGP key: wwwkeys.eu.pgp.net

[-- Attachment #1.2: patch-voyager --]
[-- Type: text/plain, Size: 1253 bytes --]

diff -urN -X /usr/share/dontdiff linux.vanilla/arch/i386/config.in linux/arch/i386/config.in
--- linux.vanilla/arch/i386/config.in	Thu Jun 13 00:30:57 2002
+++ linux/arch/i386/config.in	Wed Jun 12 20:25:15 2002
@@ -425,11 +425,6 @@
    fi
 fi
 
-if [ "$CONFIG_X86_LOCAL_APIC" = "y" ]; then
-   define_bool CONFIG_X86_EXTRA_IRQS y
-   define_bool CONFIG_X86_FIND_SMP_CONFIG y
-fi
-
 endmenu
 
 source lib/Config.in
@@ -443,6 +438,13 @@
    if [ "$CONFIG_SMP" = "y" ]; then
       define_bool CONFIG_X86_SMP y
       define_bool CONFIG_X86_HT y
+      define_bool CONFIG_X86_IO_APIC y
+      define_bool CONFIG_X86_LOCAL_APIC y
    fi
    define_bool CONFIG_X86_BIOS_REBOOT y
+fi
+
+if [ "$CONFIG_X86_LOCAL_APIC" = "y" ]; then
+   define_bool CONFIG_X86_EXTRA_IRQS y
+   define_bool CONFIG_X86_FIND_SMP_CONFIG y
 fi
diff -urN -X /usr/share/dontdiff linux.vanilla/arch/i386/generic/Makefile linux/arch/i386/generic/Makefile
--- linux.vanilla/arch/i386/generic/Makefile	Thu Jun 13 00:30:50 2002
+++ linux/arch/i386/generic/Makefile	Thu Jun 13 00:38:25 2002
@@ -18,7 +18,6 @@
 
 obj-y				:= setup.o
 
-obj-$(CONFIG_PCI)		+= pci-pc.o pci-irq.o
 obj-$(CONFIG_X86_LOCAL_APIC)	+= mpparse.o
 
 include $(TOPDIR)/Rules.make

[-- Attachment #2: Type: application/pgp-signature, Size: 232 bytes --]

Re: [PATCH: NEW SUBARCHITECTURE FOR 2.5.21] support for NCR voyager (3/4/5xxx series)

[James Bottomley]

pazke@orbita1.ru said:
> Attached patch is needed to compile kernel with Voyager patch applied
> for the SMP PC machine. 

I've applied it to my repository, thanks.  I forgot to keep track of these 
issues in the voyager tree when I separated the arch-split stuff.

> [Q1] Will it be better to  create separate directory for PC
> architecture and split some PC'isms from arch/i386/generic ? Right now
> it contains acpi.c, bootflag.c and dmi_scan.c which are not generic in
> any way :) 

The thinking currently is that arch/i386 is really PC plus a few exceptions 
rather than a truly generic x86 plus additonal machine architectures, so it 
makes sense under this view that `generic' and PC be the same thing.

> [Q2] May be directory naming like mach-visws, mach-voyager and
> possible  mach-pc will be more convinent ? 

To be more consistent with the way arch/arm does it?  Certainly the renames 
can be done easily enough, what does the rest of the list think?

James

Re: [PATCH: NEW SUBARCHITECTURE FOR 2.5.21] support for NCR voyager (3/4/5xxx series)

[Dave Jones]

On Thu, Jun 13, 2002 at 11:48:57AM -0400, James Bottomley wrote:
 > > [Q1] Will it be better to  create separate directory for PC
 > > architecture and split some PC'isms from arch/i386/generic ? Right now
 > > it contains acpi.c, bootflag.c and dmi_scan.c which are not generic in
 > > any way :) 
 > The thinking currently is that arch/i386 is really PC plus a few exceptions 
 > rather than a truly generic x86 plus additonal machine architectures, so it 
 > makes sense under this view that `generic' and PC be the same thing.

Would it make sense for the subarchs to use the generic code where possible,
and only reimplement it's own (for eg) apic.c as and when it actually
*needs* to be different ?

For the most part, I'd expect the existing subarchs we know about
(sgi visws, voyager, numaq), the amount of "own version" copies of
files would be quite low.

The big advantage of doing it this way, is that it reduces the overhead
of having to update every subarch when someone changes function
parameters. The downside is possibly slightly ickier Makefile's.

 > > [Q2] May be directory naming like mach-visws, mach-voyager and
 > > possible  mach-pc will be more convinent ? 
 > To be more consistent with the way arch/arm does it?  Certainly the renames 
 > can be done easily enough, what does the rest of the list think?

Sounds quite logical. What does the current patches you have do ?
I've not had chance to look at them yet.

        Dave

-- 
| Dave Jones.        http://www.codemonkey.org.uk
| SuSE Labs

Re: [PATCH: NEW SUBARCHITECTURE FOR 2.5.21] support for NCR voyager (3/4/5xxx series)

[James Bottomley]

davej@suse.de said:
> Would it make sense for the subarchs to use the generic code where
> possible, and only reimplement it's own (for eg) apic.c as and when it
> actually *needs* to be different ? 

That is really the way I've implemented it.  The only PC specific file in the 
generic directory is mpparse.c (since neither visws nor voyager has an MP 
compliant bios).  All the shareable files are kept in `kernel' and activated 
by config options.

I can certainly move mpparse.c back to kernel and add an extra (non user 
visible) config option.

> Sounds quite logical. What does the current patches you have do ? I've
> not had chance to look at them yet. 

It creates directories `generic' for the standard pc and `visws'.  The voyager 
patch creates a `voyager' directory.  Alternatively, these could be `mach-pc', 
`mach-visws' and `mach-voyager'.

James

Re: [PATCH: NEW SUBARCHITECTURE FOR 2.5.21] support for NCR voyager (3/4/5xxx series)

[Dave Jones]

On Thu, Jun 13, 2002 at 08:13:26PM -0400, James Bottomley wrote:
 > > Would it make sense for the subarchs to use the generic code where
 > > possible, and only reimplement it's own (for eg) apic.c as and when it
 > > actually *needs* to be different ? 
 > That is really the way I've implemented it.

Ah, good.

 >  The only PC specific file in the 
 > generic directory is mpparse.c (since neither visws nor voyager has an MP 
 > compliant bios).  All the shareable files are kept in `kernel' and activated 
 > by config options.

Another piece of low hanging fruit is probably dmi_scan.c
There are no workarounds there for either (are they even DMI compliant?)
so compiling it in doesn't make much sense.

 > I can certainly move mpparse.c back to kernel and add an extra (non user 
 > visible) config option.

if neither visws or voyager need it, I'd say it doesn't belong in the
respective subarch directories period.

 > > Sounds quite logical. What does the current patches you have do ? I've
 > > not had chance to look at them yet. 
 > It creates directories `generic' for the standard pc and `visws'.  The voyager 
 > patch creates a `voyager' directory.  Alternatively, these could be `mach-pc', 
 > `mach-visws' and `mach-voyager'.

Yeah, I think mach-foo would be more aesthetically pleasing, so I'll
cast my vote for that one. If nothing else, it makes it obvious that
the subdir isn't important if you don't care about $subarch

        Dave.

-- 
| Dave Jones.        http://www.codemonkey.org.uk
| SuSE Labs

Re: [PATCH: NEW SUBARCHITECTURE FOR 2.5.21] support for NCR voyager (3/4/5xxx series)

[Matthew D. Pitts]

>  > > Sounds quite logical. What does the current patches you have do ?
I've
>  > > not had chance to look at them yet.
>  > It creates directories `generic' for the standard pc and `visws'.  The
voyager
>  > patch creates a `voyager' directory.  Alternatively, these could be
`mach-pc',
>  > `mach-visws' and `mach-voyager'.
>
> Yeah, I think mach-foo would be more aesthetically pleasing, so I'll
> cast my vote for that one. If nothing else, it makes it obvious that
> the subdir isn't important if you don't care about $subarch
>
I think it would be a good idea as well.

Matthew

SCSI host/channel/lun/part to /dev/sd* or maj/minor mapping

[Mark Atwood]

Is there a mapping between the Host,Channel,Id,Lun of a SCSI device as
reported in /proc/scsi/scsi, and the the /dev/sd* names and/or the
major/minor device numbers?

I've done some experamentation, and the more obvious ways of doing
the mapping dont seem to be 100%.

Re: [PATCH: NEW SUBARCHITECTURE FOR 2.5.21] support for NCR voyager (3/4/5xxx series)

[Andrey Panin]

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

On Птн, Июн 14, 2002 at 02:45:47 +0200, Dave Jones wrote:
> On Thu, Jun 13, 2002 at 08:13:26PM -0400, James Bottomley wrote:
>  > > Would it make sense for the subarchs to use the generic code where
>  > > possible, and only reimplement it's own (for eg) apic.c as and when it
>  > > actually *needs* to be different ? 
>  > That is really the way I've implemented it.
> 
> Ah, good.
> 
>  >  The only PC specific file in the 
>  > generic directory is mpparse.c (since neither visws nor voyager has an MP 
>  > compliant bios).  All the shareable files are kept in `kernel' and activated 
>  > by config options.
> 
> Another piece of low hanging fruit is probably dmi_scan.c
> There are no workarounds there for either (are they even DMI compliant?)
> so compiling it in doesn't make much sense.

We also have apm.c, bootflag.c and acpi.c which are definetely PC specific.

>  > I can certainly move mpparse.c back to kernel and add an extra (non user 
>  > visible) config option.
> 
> if neither visws or voyager need it, I'd say it doesn't belong in the
> respective subarch directories period.

"Latest" (2.4.17) visws patch which i'm planning to convert for 2.5, uses
function MP_processor_info() from generic mpparse.c. May be it makes sence
to move to some generic file ?

>  > > Sounds quite logical. What does the current patches you have do ? I've
>  > > not had chance to look at them yet. 
>  > It creates directories `generic' for the standard pc and `visws'.  The voyager 
>  > patch creates a `voyager' directory.  Alternatively, these could be `mach-pc', 
>  > `mach-visws' and `mach-voyager'.
> 
> Yeah, I think mach-foo would be more aesthetically pleasing, so I'll
> cast my vote for that one. If nothing else, it makes it obvious that
> the subdir isn't important if you don't care about $subarch
> 
>         Dave.

-- 
Andrey Panin            | Embedded systems software engineer
pazke@orbita1.ru        | PGP key: wwwkeys.eu.pgp.net

[-- Attachment #2: Type: application/pgp-signature, Size: 232 bytes --]

Re: [PATCH: NEW SUBARCHITECTURE FOR 2.5.21] support for NCR voyager (3/4/5xxx series)

[Dave Jones]

On Fri, Jun 14, 2002 at 05:41:52PM +0400, Andrey Panin wrote:

 > We also have apm.c, bootflag.c and acpi.c which are definetely PC specific.

apm may be present on the others (need visws/voyager folks to comment on
that I guess), but bootflag and acpi I'd suspect not.

 > "Latest" (2.4.17) visws patch which i'm planning to convert for 2.5, uses
 > function MP_processor_info() from generic mpparse.c. May be it makes sence
 > to move to some generic file ?

Is that the one from the visws sourceforge project ?

        Dave

-- 
| Dave Jones.        http://www.codemonkey.org.uk
| SuSE Labs

Re: [PATCH: NEW SUBARCHITECTURE FOR 2.5.21] support for NCR voyager (3/4/5xxx series)

[Andrey Panin]

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

On Fri, Jun 14, 2002 at 03:49:45PM +0200, Dave Jones wrote:
> On Fri, Jun 14, 2002 at 05:41:52PM +0400, Andrey Panin wrote:
> 
>  > We also have apm.c, bootflag.c and acpi.c which are definetely PC specific.
> 
> apm may be present on the others (need visws/voyager folks to comment on
> that I guess), but bootflag and acpi I'd suspect not.

IMHO Voyagers are too old and big machines to get (working) APM,
and visws have no BIOS or limited BIOS emulation.
 
>  > "Latest" (2.4.17) visws patch which i'm planning to convert for 2.5, uses
>  > function MP_processor_info() from generic mpparse.c. May be it makes sence
>  > to move to some generic file ?
> 
> Is that the one from the visws sourceforge project ?

Yes it is.

-- 
Andrey Panin            | Embedded systems software engineer
pazke@orbita1.ru        | PGP key: wwwkeys.eu.pgp.net

[-- Attachment #2: Type: application/pgp-signature, Size: 232 bytes --]

Re: [PATCH: NEW SUBARCHITECTURE FOR 2.5.21] support for NCR voyager (3/4/5xxx series)

[James Bottomley]

pazke@orbita1.ru said:
> IMHO Voyagers are too old and big machines to get (working) APM, and
> visws have no BIOS or limited BIOS emulation. 

That depends what you mean by `apm'.  In kernel/apm.c, it's tied to the 
existence of the APM bios and since voyagers have no bios per say (they 
actually have a SUS, which is an actively running boot OS on a tiny i386 
processor which can emulate a minimal PC bios when in PC mode) then you're 
correct.

Running Linux on a voyager, I can power off the machine, read the internal 
power source, the status of the front panel switch and even trigger a power 
management shutdown after the AC power is lost for a certain length of time 
(voyagers usually have internal lead acid batteries).  The way it's currently 
set up, if I turn off the front panel switch, the machine will execute a clean 
shutdown and power itself off when the shutdown is finished.  (this is mainly 
done in the voyager_thread.c file, where it keeps a kernel daemon permanently 
monitoring the machine status, if you're interested).

The above are all traditional APM functions, I just don't need apm.c to do 
them.

However, apm.c is still in arch/i386/kernel, just in case, so I think 
mpparse.c should join it, and we should keep all the other pieces (bootflag.c 
and acpi.c) in there just in case.

James

Re: [PATCH: NEW SUBARCHITECTURE FOR 2.5.21] support for NCR voyager (3/4/5xxx series)

[Dave Jones]

On Fri, Jun 14, 2002 at 05:52:29PM +0400, Andrey Panin wrote:

 > >  > "Latest" (2.4.17) visws patch which i'm planning to convert for 2.5, uses
 > >  > function MP_processor_info() from generic mpparse.c. May be it makes sence
 > >  > to move to some generic file ?
 > > Is that the one from the visws sourceforge project ?
 > Yes it is.

Ah good. *cross item off TODO list*

        Dave

-- 
| Dave Jones.        http://www.codemonkey.org.uk
| SuSE Labs

Re: [PATCH: NEW SUBARCHITECTURE FOR 2.5.21] support for NCR voyager (3/4/5xxx series)

[Andrey Panin]

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

On Птн, Июн 14, 2002 at 04:16:27 +0200, Dave Jones wrote:
> On Fri, Jun 14, 2002 at 05:52:29PM +0400, Andrey Panin wrote:
> 
>  > >  > "Latest" (2.4.17) visws patch which i'm planning to convert for 25, uses
>  > >  > function MP_processor_info() from generic mpparse.c. May be it makes sence
>  > >  > to move to some generic file ?
>  > > Is that the one from the visws sourceforge project ?
>  > Yes it is.
> 
> Ah good. *cross item off TODO list*
 
Does it make sense to submit it right now before i386 arch split will
be completed ?

-- 
Andrey Panin            | Embedded systems software engineer
pazke@orbita1.ru        | PGP key: wwwkeys.eu.pgp.net

[-- Attachment #2: Type: application/pgp-signature, Size: 232 bytes --]

Re: [PATCH: NEW SUBARCHITECTURE FOR 2.5.21] support for NCR voyager (3/4/5xxx series)

[Dave Jones]

On Mon, Jun 17, 2002 at 05:36:32PM +0400, Andrey Panin wrote:

 > >  > >  > "Latest" (2.4.17) visws patch which i'm planning to convert for 25, uses
 > >  > >  > function MP_processor_info() from generic mpparse.c. May be it makes sence
 > >  > >  > to move to some generic file ?
 > >  > > Is that the one from the visws sourceforge project ?
 > >  > Yes it is.
 > > 
 > > Ah good. *cross item off TODO list*
 >  
 > Does it make sense to submit it right now before i386 arch split will
 > be completed ?

I took a quick look over James' current patch last night. In it's
current state, I think it's quite large already, and as it touches
so many areas, I'm wondering if it's possible to split it up into
chunks and merge it gradually.

merging visws now would mean a large part of James' current work
would be out of sync.

        Dave

-- 
| Dave Jones.        http://www.codemonkey.org.uk
| SuSE Labs

Re: [PATCH: NEW SUBARCHITECTURE FOR 2.5.21] support for NCR voyager (3/4/5xxx series)

[James Bottomley]

pazke@orbita1.ru said:
> "Latest" (2.4.17) visws patch which i'm planning to convert for 2.5,
> uses function MP_processor_info() from generic mpparse.c. May be it
> makes sence to move to some generic file ? 

OK, I moved mpparse back into kernel (and gated it on CONFIG_X86_MPPARSE).  It 
probably makes sense to split it up so that you only get the piece you need 
for visws.

I've also done the mach-* renames by popular request.  The new patch is at:

http://www.hansenpartnership.com/voyager/files/arch-split-2.5.21-II.diff

and also in the bitkeeper repository:

http://linux-voyager.bkbits.net/arch-split-2.5

James

Re: SCSI host/channel/lun/part to /dev/sd* or maj/minor mapping

[Douglas Gilbert]

Mark Atwood write:
> Is there a mapping between the Host,Channel,Id,Lun of a SCSI device as
> reported in /proc/scsi/scsi, and the the /dev/sd* names and/or the
> major/minor device numbers?
> 
> I've done some experamentation, and the more obvious ways of doing
> the mapping dont seem to be 100%.

Mark,
There are several utilities discussed at this url:
http://www.torque.net/sg/u_index.html
including scsidev and sg_map. Devfs shows you this mapping
via its hierarchy:
$ ls -l
total 0
brw-------    1 root     root       8,   0 Dec 31  1969 disc
crw-r-----    1 root     root      21,   0 Dec 31  1969 generic
brw-------    1 root     root       8,   1 Dec 31  1969 part1
$ pwd
/dev/scsi/host1/bus0/target0/lun0/


None of these approaches is completely satisfactory. Kurt Garloff
is working on a patch that seems to address this problem quite
cleanly:

$ cat /proc/scsi/map
# C,B,T,U	Type	onl	sg_nm	sg_dev	nm	dev
0,0,00,00	05	1	sg0	c:15:00	sr0	b:0b:00
1,0,01,00	05	1	sg1	c:15:01	sr1	b:0b:01
1,0,03,00	05	1	sg3	c:15:03	sr2	b:0b:02
1,0,05,00	00	1	sg4	c:15:04	sda	b:08:00
1,0,09,00	00	1	sg5	c:15:05	sdb	b:08:10
1,0,02,00	01	1	sg2	c:15:02	osst0	c:ce:00
2,0,01,00	05	1	sg6	c:15:06	sr3	b:0b:03
2,0,02,00	01	1	sg7	c:15:07	osst1	c:ce:01
2,0,03,00	05	1	sg8	c:15:08	sr4	b:0b:04
2,0,09,00	00	1	sg10	c:15:0a	sdd	b:08:30
3,0,10,00	00	1	sg11	c:15:0b	sde	b:08:40
3,0,12,00	00	1	sg12	c:15:0c	sdf	b:08:50


Doug Gilbert