[parisc-linux] arch/parisc/kernel/realmode_setup.c Question

[parisc-linux] arch/parisc/kernel/realmode_setup.c Question

[Ryan Bradetich]

Paul,

I have started working on getting the kernel to boot on the PA2.0
architecture again, and I see the you and others have been doing
lots of work with the initialization code.  (Nice job to everyone btw,
the code is a lot easier to figure out for a newbie like me! :)

I was looking at the following section of code and I have a
discrepancy that I wanted to make you aware of.  I don't know how
to fix it yet, but I will continue to look.

I am working on a C200+ which has the PA2.0 processor, so in the
the following section of code it should give me an error during the
BTLB initialization, but during the PDC_BTLB_INSERT pret is set
to 0, so the check for non-PA1.1 architecture's fail.

I will continue to look through the documentation that has been
previously pointed out, and the devresource page  pointed out by
Frank Rowand to see if I can find a solution to the problem.

Thanks,

Ryan Bradetich


[Taken from arch/parisc/kernel/realmode_setup.c]

 /* This whole VM setup stuff may be removed ultimately.  It seems
   * to me that once the TLB miss handlers are ready, we just switch
   * to VM and let them handle TLB population -PB
   */

  pret = (*PAGE0->mem_pdc)(
  PDC_BLOCK_TLB,
  PDC_BTLB_INSERT,
  0x00000000,  /* MS bits, virt page number */
  0xc0000,  /* LS bits, virt page number */
  0x00000000,  /* Physical page number */
  4096,   /* # pages to map */
  0x03000000,  /* access rights, etc... */
  0);   /* slot number */

  if (pret != 0)
 {
       mprintf("PDC_BTLB_INSERT returned %d\n", pret);
      if (pret == -1)
     {
        mprintf("Looks like there's no BTLB on this box, so it's
probably\n"
                       "either PA1.0 or PA2.0.  In any case we're
screwed for now\n");
        led_flash();
     }
}

Re: [parisc-linux] arch/parisc/kernel/realmode_setup.c Question

[Alex deVries]

On Sun, 14 Nov 1999, Ryan Bradetich wrote:
> I have started working on getting the kernel to boot on the PA2.0
> architecture again, and I see the you and others have been doing
> lots of work with the initialization code.  (Nice job to everyone btw,
> the code is a lot easier to figure out for a newbie like me! :)

Same here.

> I am working on a C200+ which has the PA2.0 processor, so in the
> the following section of code it should give me an error during the
> BTLB initialization, but during the PDC_BTLB_INSERT pret is set
> to 0, so the check for non-PA1.1 architecture's fail.

It's a bit unclear to me which processor is actually in there, but I
believe it's an 8000, so it and the firmware may in fact support
PDC_BTLB_INSERT, which means that the kernel might work properly.

I have a C3000 which does *NOT* implement PDC_BTLB functions.

It sounds like the error message is actually a bit misleading.

Instead of:

         mprintf("Looks like there's no BTLB on this box, so it's > probably\n"
                       "either PA1.0 or PA2.0.  In any case we're screwed for now\n");

it should be:

"Looks like there's no BTLB on this box, so it's either a PA1.0 or a PA2.0
that doesn't implement BTLBs"

How far does it actually boot though?

- Alex

Re: [parisc-linux] arch/parisc/kernel/realmode_setup.c Question

[Ryan Bradetich]

Alex deVries wrote:

> On Sun, 14 Nov 1999, Ryan Bradetich wrote:
> > I have started working on getting the kernel to boot on the PA2.0
> > architecture again, and I see the you and others have been doing
> > lots of work with the initialization code.  (Nice job to everyone btw,
> > the code is a lot easier to figure out for a newbie like me! :)
>
> Same here.
>
> > I am working on a C200+ which has the PA2.0 processor, so in the
> > the following section of code it should give me an error during the
> > BTLB initialization, but during the PDC_BTLB_INSERT pret is set
> > to 0, so the check for non-PA1.1 architecture's fail.
>
> It's a bit unclear to me which processor is actually in there, but I
> believe it's an 8000, so it and the firmware may in fact support
> PDC_BTLB_INSERT, which means that the kernel might work properly.
>
> I have a C3000 which does *NOT* implement PDC_BTLB functions.
>
> It sounds like the error message is actually a bit misleading.
>
> Instead of:
>
>          mprintf("Looks like there's no BTLB on this box, so it's > probably\n"
>                        "either PA1.0 or PA2.0.  In any case we're screwed for now\n");
>
> it should be:
>
> "Looks like there's no BTLB on this box, so it's either a PA1.0 or a PA2.0
> that doesn't implement BTLBs"
>
> How far does it actually boot though?

Same as always (their is just more console output before it hangs).  Here is a cut/paste
of the console messages from the serial console.


Firmware Version  5.2

Duplex Console IO Dependent Code (IODC) revision 1

------------------------------------------------------------------------------
   (c) Copyright 1995-1998, Hewlett-Packard Company, All rights reserved
------------------------------------------------------------------------------

  Processor   Speed            State           Coprocessor State  I/D Cache
  ---------  --------   ---------------------  -----------------  -------------
      0      200 MHz    Active                 Functional         512 KB/1 MB

  Central Bus Speed (in MHz) :        120

  Available memory (bytes)    : 268435456
  Good memory required (bytes):   21827584

  Primary boot path:    FWSCSI.5.0
  Alternate boot path:  SESCSI.6.0
  Console path:         SERIAL_1.9600.8.none
  Keyboard path:        PS2

CPU 0
WARNING:  Self tests have been disabled as a result of FASTBOOT
          being enabled.  To enable self tests, use the FASTBOOT
          command in the CONFIGURATION menu and reboot the system.
WARNING:  Memory has been initialized, but not tested as a result of
          FASTBOOT being enabled.  To test memory, use the FASTBOOT
          command in the CONFIGURATION menu and reboot the system.


Processor is booting from first available device.

To discontinue, press any key within 10 seconds.

Boot terminated.


------- Main Menu -------------------------------------------------------------

        Command                         Description
        -------                         -----------
        BOot [PRI|ALT|<path>]           Boot from specified path
        PAth [PRI|ALT|CON|KEY] [<path>] Display or modify a path
        SEArch [DIsplay|IPL] [<path>]   Search for boot devices

        COnfiguration [<command>]       Access Configuration menu/commands
        INformation [<command>]         Access Information menu/commands
        SERvice [<command>]             Access Service menu/commands


        DIsplay                         Redisplay the current menu
        HElp [<menu>|<command>]         Display help for menu or command
        RESET                           Restart the system
-------
Main Menu: Enter command > bo lan <ip>
Interact with IPL (Y, N, Q)?> n

Booting...
Network Station Address 0060b0-ea9875
System IP Address  <ip>
Server IP Address <ip>

Boot IO Dependent Code (IODC) revision 2


HARD Booted.

------------------------------------------------------------------------------

PARISC/Linux Bootstrap Version 0.6 (non-interactive)
By Helge Deller & Jason Eckhardt
Built Sat Nov 13 17:17:38 MST 1999 by root@vega

Reading parameters...done.

Loading PA-RISC/Linux Kernel...
SOM-Kernel:
aux_header_location: 00000080
som       : 00200080
exec_dfile: 000C8000
exec_dsize: 00082000
exec_dmem : C009A000
exec_tfile: 0003E000
exec_tsize: 00089008
exec_tmem : C0010000
Code at 0x00010000, size=0x00089008
Data at 0x0009A000, size=0x00082000
BSS  at 0x0011C000.

Transferring control to kernel. (At entry point 0x00010000)
kernel(0x00148C80, 0x00504010, 0x00148C80, 0x00016640)
Clear BSS 0x0011B048 --> 0x0013D690
Boot loader: PA/Linux, maybe PALO
realmode_setup exiting

... At this point it hangs.  Before, it always used to hang at:
Transferring control to kernel. (At entry point 0x00010000)

I still do not believe it ever successfully finished the rfi in head.S :(
I still need to do some more research to verify this, but that is my
gut feeling right now.

Ryan Bradetich

>
> - Alex
>
> ---------------------------------------------------------------------------
> To unsubscribe: send e-mail to parisc-linux-request@thepuffingroup.com with
> `unsubscribe' as the subject.

Re: [parisc-linux] arch/parisc/kernel/realmode_setup.c Question

[Alex deVries]

On Sun, 14 Nov 1999, Ryan Bradetich wrote:
> > How far does it actually boot though?
> 
> Same as always (their is just more console output before it hangs).  Here is a cut/paste
> of the console messages from the serial console.

Hm.  I'm working on inserting a bazillion chassis_write() calls so that I
can see exactly where it dies...

- Alex

Re: [parisc-linux] arch/parisc/kernel/realmode_setup.c Question

[Philipp Rumpf]

> > How far does it actually boot though?

> Transferring control to kernel. (At entry point 0x00010000)
> kernel(0x00148C80, 0x00504010, 0x00148C80, 0x00016640)
> Clear BSS 0x0011B048 --> 0x0013D690
> Boot loader: PA/Linux, maybe PALO
> realmode_setup exiting
> 
> ... At this point it hangs.  Before, it always used to hang at:
> Transferring control to kernel. (At entry point 0x00010000)
> 
> I still do not believe it ever successfully finished the rfi in head.S :(
> I still need to do some more research to verify this, but that is my
> gut feeling right now.

This sounds right.  It is indeed possible we cannot install a BTLB entry on
your CPU (and the firmware just reports success as it is free to according to
the documentation) or the BTLB entry gets removed before we get the chance to
do our first printk.

For both problems, the answer is within reach, and is called "a separate direc-
tory for real-mode code".  Being able to debug unexpected TLB insertion handler
calls is one of the immediate advantages of having this directory, and sure is
going to be useful in the future (and would have been useful in the past).

Wanna bet we're going to get that machine to a sash prompt this week ?

	Philipp Rumpf

Re: [parisc-linux] arch/parisc/kernel/realmode_setup.c Question

[Matthew Wilcox]

On Mon, Nov 15, 1999 at 08:20:44AM +0100, Philipp Rumpf wrote:
> Wanna bet we're going to get that machine to a sash prompt this week ?

Double-or-nothing on that beer I owe you at LinuxTag?  :-)

[I bet it would take at least 6 boots for him to get task switching
 working.  He did it in 2.]

-- 
Matthew Wilcox <willy@bofh.ai>
"Windows and MacOS are products, contrived by engineers in the service of
specific companies. Unix, by contrast, is not so much a product as it is a
painstakingly compiled oral history of the hacker subculture." - N Stephenson

Re: [parisc-linux] arch/parisc/kernel/realmode_setup.c Question

[Ryan Bradetich]

Philipp Rumpf wrote:

> > > How far does it actually boot though?
>
> > Transferring control to kernel. (At entry point 0x00010000)
> > kernel(0x00148C80, 0x00504010, 0x00148C80, 0x00016640)
> > Clear BSS 0x0011B048 --> 0x0013D690
> > Boot loader: PA/Linux, maybe PALO
> > realmode_setup exiting
> >
> > ... At this point it hangs.  Before, it always used to hang at:
> > Transferring control to kernel. (At entry point 0x00010000)
> >
> > I still do not believe it ever successfully finished the rfi in head.S :(
> > I still need to do some more research to verify this, but that is my
> > gut feeling right now.
>
> This sounds right.  It is indeed possible we cannot install a BTLB entry on
> your CPU (and the firmware just reports success as it is free to according to
> the documentation) or the BTLB entry gets removed before we get the chance to
> do our first printk.

Ahh, ok.  I think I'm begining to understand what is happening now (finally).  Is
their
a way to check the BTLB entry and see if it is their right after we we insert the
entry?
or will th real-mode code take care of that?  (I would still like to know what is
happening, I've spent a lot of time tring to figure this out :))

>
> For both problems, the answer is within reach, and is called "a separate direc-
> tory for real-mode code".  Being able to debug unexpected TLB insertion handler
> calls is one of the immediate advantages of having this directory, and sure is
> going to be useful in the future (and would have been useful in the past).

Great!  Anything I can do to help?  I am just learning how this all works, but I
am very
interested in helping.

>
> Wanna bet we're going to get that machine to a sash prompt this week ?

Very, Very nice. Then hopefully I'll be able to contribute more.  I've been
wanting to get
this port to boot on this machine for a long time now :)  This is going to be a
great week!!

- Ryan


>
>         Philipp Rumpf
>
> ---------------------------------------------------------------------------
> To unsubscribe: send e-mail to parisc-linux-request@thepuffingroup.com with
> `unsubscribe' as the subject.

Re: [parisc-linux] arch/parisc/kernel/realmode_setup.c Question

[bame]

I don't work Mondays, but I saw this by chance and thought I should
respond as the culprit :-)

Don't knock yourself out figuring out where a C3000 is dying now
(this can be a TREMENDOUS time sink!).  If you want to get a better PIM
dump of the problem, comment out the 'mtctl ??, %cr14' in head.S.

But logic is all that's required here.  The RFI attempts to
"resume" executaion at 0xC<something> which isn't mapped, and there's
no TLB handler (that I know of, haven't studied it yet though), so this
will generate an immediate fault.

I'm glad folks are finding the C setup code easier to grok, but I
warn that the most innocent-seeming change can cause the compiler to
generate something which will lead to a mysterious death while booting!
This fragility is unacceptable.

The "best" solution to this which I've come up with is to segregate the
realmode code like Phillip suggests, and link it into a small separate
executable, so that vmlinux is logically two executables in one.  This
design is a bit twisted and will mainly impact a couple of Makefiles as well
as head.S, realmode_setup.c, setup.c, and cosmetic changes to traps.c
However once it's done it'll be easy to understand, change, and maintain
the realmode startup code.

I'm planning to start this tomorrow so somebody stop me if it seems stupid.
Very rough notes -- very rough -- about the twisted design can be found at
http://puffin.external.hp.com/~bame/boot.html  I'd like to be shown there's
an easier way...

	-Paul Bame

Re: [parisc-linux] arch/parisc/kernel/realmode_setup.c Question

[Frank Rowand]

Ryan Bradetich wrote:
> 
> Paul,
> 
> I have started working on getting the kernel to boot on the PA2.0
> architecture again, and I see the you and others have been doing
> lots of work with the initialization code.  (Nice job to everyone btw,
> the code is a lot easier to figure out for a newbie like me! :)
> 
> I was looking at the following section of code and I have a
> discrepancy that I wanted to make you aware of.  I don't know how
> to fix it yet, but I will continue to look.
> 
> I am working on a C200+ which has the PA2.0 processor, so in the
> the following section of code it should give me an error during the
> BTLB initialization, but during the PDC_BTLB_INSERT pret is set
> to 0, so the check for non-PA1.1 architecture's fail.
> 
> I will continue to look through the documentation that has been
> previously pointed out, and the devresource page  pointed out by
> Frank Rowand to see if I can find a solution to the problem.
> 
> Thanks,
> 
> Ryan Bradetich
> 
> [Taken from arch/parisc/kernel/realmode_setup.c]
> 
>  /* This whole VM setup stuff may be removed ultimately.  It seems
>    * to me that once the TLB miss handlers are ready, we just switch
>    * to VM and let them handle TLB population -PB
>    */
> 
>   pret = (*PAGE0->mem_pdc)(
>   PDC_BLOCK_TLB,
>   PDC_BTLB_INSERT,
>   0x00000000,  /* MS bits, virt page number */
>   0xc0000,  /* LS bits, virt page number */
>   0x00000000,  /* Physical page number */
>   4096,   /* # pages to map */
>   0x03000000,  /* access rights, etc... */
>   0);   /* slot number */
> 
>   if (pret != 0)
>  {
>        mprintf("PDC_BTLB_INSERT returned %d\n", pret);
>       if (pret == -1)
>      {
>         mprintf("Looks like there's no BTLB on this box, so it's
> probably\n"
>                        "either PA1.0 or PA2.0.  In any case we're
> screwed for now\n");
>         led_flash();
>      }
> }


Ryan,


This might not solve your problem, but it's worth checking out.  The
procedure calling convention for PA 2.0 PDC is different than for 1.0.
See http://thepuffingroup.com/parisc/documentation.html, pdc.pdf,
p 2-8 defines the return status as a 64-bit, not 32 bit.  You might
also want to look at the neighboring pages of the document for other
changes (eg, arg4 through arg7 are passed in registers).

I don't know if your system has wide or narrow PDC - you have to call
PDC_MODEL(Return Capabilities), and check bit 63 of caps (the field
called OS64).

-Frank

[parisc-linux] use of (*PAGE0->mem_pdc)()

[Frank Rowand]

Ryan Bradetich wrote:

< stuff deleted >

> [Taken from arch/parisc/kernel/realmode_setup.c]
> 
>  /* This whole VM setup stuff may be removed ultimately.  It seems
>    * to me that once the TLB miss handlers are ready, we just switch
>    * to VM and let them handle TLB population -PB
>    */
> 
>   pret = (*PAGE0->mem_pdc)(
>   PDC_BLOCK_TLB,
>   PDC_BTLB_INSERT,


A comment that is totally unrelated to the question Ryan was asking...

I would recommend that we quit using the pointer to PDCE_PROC() that
is in page zero, because the newer machines have a PDC procedure,
PDC_RELOCATE(), that copies PDCE_PROC into real memory, where it
executes much faster.  The page zero pointer to PDCE_PROC() is not
updated by PDC_RELOCATE(), but instead a pointer to the in-memory
PDCE_PROC() is returned.

I recommend using a global variable to hold the pointer to PDCE_PROC(),
which would be the value from page zero initially, then updated to
the value returned by PDC_RELOCATE().

-Frank

Re: [parisc-linux] arch/parisc/kernel/realmode_setup.c Question

[Frank Rowand]

Alex deVries wrote:
> 
> On Mon, 15 Nov 1999, Frank Rowand wrote:
> > This might not solve your problem, but it's worth checking out.  The
> > procedure calling convention for PA 2.0 PDC is different than for 1.0.
> > See http://thepuffingroup.com/parisc/documentation.html, pdc.pdf,
> > p 2-8 defines the return status as a 64-bit, not 32 bit.  You might
> 
> However, we are running this in narrow mode, so we should be able to use
> 32 bit PDC.


You don't get to choose.  The PDC is either 32 bit or 64 bit.  It's not
a question of what mode the OS is running in, but what the PDC was
compiled for.


> > I don't know if your system has wide or narrow PDC - you have to call
> > PDC_MODEL(Return Capabilities), and check bit 63 of caps (the field
> > called OS64).
> 
> That's worth checking out.
> 
> - Alex

-Frank

Re: [parisc-linux] arch/parisc/kernel/realmode_setup.c Question

[Frank Rowand]

Alex deVries wrote:
> 
> On Mon, 15 Nov 1999, Frank Rowand wrote:
> > You don't get to choose.  The PDC is either 32 bit or 64 bit.  It's not
> > a question of what mode the OS is running in, but what the PDC was
> > compiled for.
> 
> Hm.  I'm pretty sure that a 32 bit version of HPUX has run on that box as
> well, so wouldn't that mean that it'd have to be a 32 bit PDC?
> 
> - Alex

Nope.  The OS has to figure out what type of PDC it is calling, and properly
marshall the arguments for the call.

-Frank

Re: [parisc-linux] arch/parisc/kernel/realmode_setup.c Question

[Alex deVries]

On Mon, 15 Nov 1999, Frank Rowand wrote:
> This might not solve your problem, but it's worth checking out.  The
> procedure calling convention for PA 2.0 PDC is different than for 1.0.
> See http://thepuffingroup.com/parisc/documentation.html, pdc.pdf,
> p 2-8 defines the return status as a 64-bit, not 32 bit.  You might

However, we are running this in narrow mode, so we should be able to use
32 bit PDC.

> I don't know if your system has wide or narrow PDC - you have to call
> PDC_MODEL(Return Capabilities), and check bit 63 of caps (the field
> called OS64).

That's worth checking out.

- Alex

Re: [parisc-linux] arch/parisc/kernel/realmode_setup.c Question

[Alex deVries]

On Mon, 15 Nov 1999, Frank Rowand wrote:
> You don't get to choose.  The PDC is either 32 bit or 64 bit.  It's not
> a question of what mode the OS is running in, but what the PDC was
> compiled for.

Hm.  I'm pretty sure that a 32 bit version of HPUX has run on that box as
well, so wouldn't that mean that it'd have to be a 32 bit PDC?

- Alex

Re: [parisc-linux] arch/parisc/kernel/realmode_setup.c Question

[Ryan Bradetich]

Frank Rowand wrote:

> Alex deVries wrote:
> >
> > On Mon, 15 Nov 1999, Frank Rowand wrote:
> > > You don't get to choose.  The PDC is either 32 bit or 64 bit.  It's not
> > > a question of what mode the OS is running in, but what the PDC was
> > > compiled for.
> >
> > Hm.  I'm pretty sure that a 32 bit version of HPUX has run on that box as
> > well, so wouldn't that mean that it'd have to be a 32 bit PDC?
> >
> > - Alex
>
> Nope.  The OS has to figure out what type of PDC it is calling, and properly
> marshall the arguments for the call.
>
> -Frank

Time for me to show off my ignorance again. :)  As I understand it, the PDC is
firmware, which all the CPU (in a multiple CPU box) share.  I know that when
I installed 11.X on this C200 that I was given the choice to install it in 32
bit or
64 bit mode.  Does this mean the install disk updates the PDC firmware to boot
into either 32-bit or 64-bit mode?

Also looking at the PSW definition for the W bit on page 2-7 and
page 2-8 of PA-RISC 2.0 Architecture by Gerry Kane:

W: Wide 64-bit address formation enabled.  When 1, full 64-bit-offset
addressing
is enabled.  When 0, addresses are truncated to 32-bit offsets, for
compatibility
with existing PA-RISC 1.0 and 1.1 applications.

Re: [parisc-linux] arch/parisc/kernel/realmode_setup.c Question

[Frank Rowand]

Ryan Bradetich wrote:
> 
> Frank Rowand wrote:
> 
> > Alex deVries wrote:
> > >
> > > On Mon, 15 Nov 1999, Frank Rowand wrote:
> > > > You don't get to choose.  The PDC is either 32 bit or 64 bit.  It's not
> > > > a question of what mode the OS is running in, but what the PDC was
> > > > compiled for.
> > >
> > > Hm.  I'm pretty sure that a 32 bit version of HPUX has run on that box as
> > > well, so wouldn't that mean that it'd have to be a 32 bit PDC?
> > >
> > > - Alex
> >
> > Nope.  The OS has to figure out what type of PDC it is calling, and properly
> > marshall the arguments for the call.
> >
> > -Frank
> 
> Time for me to show off my ignorance again. :)  As I understand it, the PDC is
> firmware, which all the CPU (in a multiple CPU box) share.  I know that when
> I installed 11.X on this C200 that I was given the choice to install it in 32
> bit or
> 64 bit mode.  Does this mean the install disk updates the PDC firmware to boot
> into either 32-bit or 64-bit mode?


The PDC is either 32-bit or 64-bit.  The OS has to deal with whatever version
of the firmware is on the box.

HP-UX is smart enough to switch into wide or narrow mode, as needed, before
calling PDC.  It also passes the arguments differently for 64 bit PDC than
for 32 bit PDC.

Page zero is also different for PA2.0 systems.  HP-UX has to deal with those
differences even when it's a 32 bit OS.


> Also looking at the PSW definition for the W bit on page 2-7 and
> page 2-8 of PA-RISC 2.0 Architecture by Gerry Kane:
> 
> W: Wide 64-bit address formation enabled.  When 1, full 64-bit-offset
> addressing
> is enabled.  When 0, addresses are truncated to 32-bit offsets, for
> compatibility
> with existing PA-RISC 1.0 and 1.1 applications.
> 
> >From PIM dumps, I know all the registers are 64 bit, and the PSW is also 64 bit
> on
> this C200..  So it looks like I should be able to switch between 32-bit and
> 64-bit by
> changing the W bit in the PSW?
> 
> Thanks,
> Ryan Bradetich
> 
> P.S.  I will try to query the PDC_MODEL as you suggested as in a previous email
> 
> in this thread and post the result when I get home tonight.


-Frank

Re: [parisc-linux] use of (*PAGE0->mem_pdc)()

[Philipp Rumpf]

> >   pret = (*PAGE0->mem_pdc)(
> >   PDC_BLOCK_TLB,
> >   PDC_BTLB_INSERT,

> I would recommend that we quit using the pointer to PDCE_PROC() that
> is in page zero, because the newer machines have a PDC procedure,
> PDC_RELOCATE(), that copies PDCE_PROC into real memory, where it
> executes much faster.  The page zero pointer to PDCE_PROC() is not
> updated by PDC_RELOCATE(), but instead a pointer to the in-memory
> PDCE_PROC() is returned.
> 
> I recommend using a global variable to hold the pointer to PDCE_PROC(),
> which would be the value from page zero initially, then updated to
> the value returned by PDC_RELOCATE().

Not only is it is a potential performance problem to use (PAGE0->mem_pdc),
it's arguably ugly and problematic for SMP as well.  There is an interface
in place to call pdc (even for real-mode code now) and there shouldn't be
a problem using that.

	Philipp Rumpf