[parisc-linux] a pretty big change

[parisc-linux] a pretty big change

[Paul Bame]

I just committed the changes to embed real-mode code in a separate
executable inside vmlinux.  It should cause no functional changes
in theory.  Read all about it in arch/parisc/real/README and
ee.html.  If you have terrible new problems,
I've attached a list of CVS commands to check out the files before I
started hacking on them.  I haven't seen a shell prompt from this
set of hacks so beware...

	-Paul Bame

prumpf- I moved kernel_thread and friends from
	real/<something> to kernel/head.S  I also re-enabled BTLB in
	real/setup.c so I could get further in the boot.  Left some
	debugging printks in the handle_real_interrupt handler too.

cvs update -r1.25 arch/parisc/Makefile
	cvs update -A arch/parisc/Makefile
cvs update -r1.28 arch/parisc/kernel/Makefile
	cvs update -A arch/parisc/kernel/Makefile
cvs update -r1.35 arch/parisc/kernel/head.S
	cvs update -A arch/parisc/kernel/head.S
cvs update -r1.39 arch/parisc/kernel/irq.c
	cvs update -A arch/parisc/kernel/irq.c
cvs update -r1.14 arch/parisc/kernel/pdc.c
	cvs update -A arch/parisc/kernel/pdc.c
cvs update -r1.25 arch/parisc/kernel/pdc_cons.c
	cvs update -A arch/parisc/kernel/pdc_cons.c
cvs update -r1.73 arch/parisc/kernel/setup.c
	cvs update -A arch/parisc/kernel/setup.c
cvs update -r1.11 arch/parisc/kernel/traps.c
	cvs update -A arch/parisc/kernel/traps.c
cvs update -r1.2 arch/parisc/real/Makefile
	cvs update -A arch/parisc/real/Makefile
cvs update -r1.2 arch/parisc/real/head.S
	cvs update -A arch/parisc/real/head.S
cvs update -r1.2 arch/parisc/real/interruption.S
	cvs update -A arch/parisc/real/interruption.S
cvs update -r1.2 arch/parisc/real/lib.c
	cvs update -A arch/parisc/real/lib.c
cvs update -r1.2 arch/parisc/real/pdc.c
	cvs update -A arch/parisc/real/pdc.c
cvs update -r1.2 arch/parisc/real/real.h
	cvs update -A arch/parisc/real/real.h
cvs update -r1.2 arch/parisc/real/real_s.S
	cvs update -A arch/parisc/real/real_s.S
cvs update -r1.2 arch/parisc/real/setup.c
	cvs update -A arch/parisc/real/setup.c
cvs update -r1.1 arch/parisc/real/traps.c
	cvs update -A arch/parisc/real/traps.c
cvs update -r1.1 include/asm-parisc/real.h
	cvs update -A include/asm-parisc/real.h

Re: [parisc-linux] a pretty big change

[Paul Bame]

Bad failures occur (for me) with the hpux boot loader.  I have no
idea whether I introduced them, but I might have.  It looks
like the first instruction of vmlinux doesn't even get executed,
so probably something in the SOM header is telling the hpux boot loader to
do something stupid.  som_relocate may need an upgrade, but I'm
stumped about what's going wrong.

	-P

Re: [parisc-linux] a pretty big change

[John David Anglin]

I read ee.html this evening.  Having already tracked down one problem
where the real-mode code went off into never-never land when I tried to
print out a string, I agree that separate comilation, linking and conversion
is a good idea.  The size of real-mode code is limited with our current
scheme.  Thus, we may reach the point where it is impossible to link
all real-mode code.

Regarding your example, the problem is that a function address is a PLABEL.
PLABELs are stored in the text space.  I think the problem can be avoided
if the function address is put into a structure which is stored in the
data space.

> I just committed the changes to embed real-mode code in a separate
> executable inside vmlinux.  It should cause no functional changes
> in theory.  Read all about it in arch/parisc/real/README and
> ee.html.  If you have terrible new problems,
> I've attached a list of CVS commands to check out the files before I
> started hacking on them.  I haven't seen a shell prompt from this
> set of hacks so beware...
> 
> 	-Paul Bame
> 
> prumpf- I moved kernel_thread and friends from
> 	real/<something> to kernel/head.S  I also re-enabled BTLB in
> 	real/setup.c so I could get further in the boot.  Left some
> 	debugging printks in the handle_real_interrupt handler too.
> 
> cvs update -r1.25 arch/parisc/Makefile
> 	cvs update -A arch/parisc/Makefile
> cvs update -r1.28 arch/parisc/kernel/Makefile
> 	cvs update -A arch/parisc/kernel/Makefile
> cvs update -r1.35 arch/parisc/kernel/head.S
> 	cvs update -A arch/parisc/kernel/head.S
> cvs update -r1.39 arch/parisc/kernel/irq.c
> 	cvs update -A arch/parisc/kernel/irq.c
> cvs update -r1.14 arch/parisc/kernel/pdc.c
> 	cvs update -A arch/parisc/kernel/pdc.c
> cvs update -r1.25 arch/parisc/kernel/pdc_cons.c
> 	cvs update -A arch/parisc/kernel/pdc_cons.c
> cvs update -r1.73 arch/parisc/kernel/setup.c
> 	cvs update -A arch/parisc/kernel/setup.c
> cvs update -r1.11 arch/parisc/kernel/traps.c
> 	cvs update -A arch/parisc/kernel/traps.c
> cvs update -r1.2 arch/parisc/real/Makefile
> 	cvs update -A arch/parisc/real/Makefile
> cvs update -r1.2 arch/parisc/real/head.S
> 	cvs update -A arch/parisc/real/head.S
> cvs update -r1.2 arch/parisc/real/interruption.S
> 	cvs update -A arch/parisc/real/interruption.S
> cvs update -r1.2 arch/parisc/real/lib.c
> 	cvs update -A arch/parisc/real/lib.c
> cvs update -r1.2 arch/parisc/real/pdc.c
> 	cvs update -A arch/parisc/real/pdc.c
> cvs update -r1.2 arch/parisc/real/real.h
> 	cvs update -A arch/parisc/real/real.h
> cvs update -r1.2 arch/parisc/real/real_s.S
> 	cvs update -A arch/parisc/real/real_s.S
> cvs update -r1.2 arch/parisc/real/setup.c
> 	cvs update -A arch/parisc/real/setup.c
> cvs update -r1.1 arch/parisc/real/traps.c
> 	cvs update -A arch/parisc/real/traps.c
> cvs update -r1.1 include/asm-parisc/real.h
> 	cvs update -A include/asm-parisc/real.h
> 
> ---------------------------------------------------------------------------
> To unsubscribe: send e-mail to parisc-linux-request@thepuffingroup.com with
> `unsubscribe' as the subject.
> 
> 


-- 
J. David Anglin                                  dave.anglin@nrc.ca
National Research Council of Canada              (613) 990-0752 (FAX: 952-6605)

Re: [parisc-linux] a pretty big change

[John David Anglin]

After a day of hacking, I was finally able to link the kernel successfully.
It booted through to the end of realmode_setup.  Probably, further work is
needed on the TLB handler.  I wonder if calls between real and virt, and
visa versa are working.  No change to som_relocate was necessary.

There is one problem.  I now have to turn off the system power to get the
system to reboot.  Formerly, I could just press the TOC button.

It also looks like the "real_" defines and protos can be eliminated.

Dave
> 
> 
> Bad failures occur (for me) with the hpux boot loader.  I have no
> idea whether I introduced them, but I might have.  It looks
> like the first instruction of vmlinux doesn't even get executed,
> so probably something in the SOM header is telling the hpux boot loader to
> do something stupid.  som_relocate may need an upgrade, but I'm
> stumped about what's going wrong.
> 
> 	-P
> 
> ---------------------------------------------------------------------------
> To unsubscribe: send e-mail to parisc-linux-request@thepuffingroup.com with
> `unsubscribe' as the subject.
> 
> 


-- 
J. David Anglin                                  dave.anglin@nrc.ca
National Research Council of Canada              (613) 990-0752 (FAX: 952-6605)

Re: [parisc-linux] a pretty big change

[Paul Bame]

= After a day of hacking, I was finally able to link the kernel successfully.
= It booted through to the end of realmode_setup.  Probably, further work is
= needed on the TLB handler.  I wonder if calls between real and virt, and
= visa versa are working.  No change to som_relocate was necessary.

Glad you had better luck with the HPUX boot loader than I had.

= There is one problem.  I now have to turn off the system power to get the
= system to reboot.  Formerly, I could just press the TOC button.

That happens pretty frequently to me but I've not tracked down why
it happens.  Did you try holding the TOC button in for several seconds?
On some workstations I've been told that generates a hard reset.

= It also looks like the "real_" defines and protos can be eliminated.

As I merge in your changes I'll look into that.

	-P

Re: [parisc-linux] a pretty big change

[Ulrich Strelow]

Hi all,

I have build a new kernel with the CVS version
19991205 and I get the following console output when I
try to boot it on my 715/33:

PARISC/Linux Bootstrap Version 0.6 (interactive)
By Helge Deller & Jason Eckhardt
Built Mon Dec 6 11:13:34 MET 1999 by root@be5359

Reading parameters...done.

Loading PA-RISC/Linux Kernel...

Please enter the command-line:
/stand/vmlinux HOME=/ TERM=LINUX console=tty

SOM-Kernel:
aux_header_location: 00000080
som       : 00200080
exec_dfile: 000CE000
exec_dsize: 00081000
exec_dmem : C00A0000
exec_tfile: 0003E000
exec_tsize: 0008F008
exec_tmem : C0010000
Code at 0x00010000, size=0x0008F008
Data at 0x000A0000, size=0x00081000
BSS  at 0x00121000.

Transferring control to kernel. (At entry point
0x00010000)
kernel(0x146880, 0x504010, 0x146880, 0x12c30)
Boot loader: PA/Linux, maybe PALO
kernel free mem 0x00146880
realmode_setup exiting
Can't insert TLB miss handler pa 0x40000000 va
0x00000000
r0-3    0x0004fb0b      0xc0112000      0xc004a170    
 0x00000000
r4-7    0xc0112000      0x00000000      0x00000400    
 0x00000000
r8-11   0xc01db000      0x00000000      0x00000400    
 0x00000100
r12-15  0xc01a4988      0x00000000      0x00000000    
 0x00000000
r16-19  0x00000000      0x00000400      0x00001000    
 0x0000001f
r20-23  0x00000020      0xc01a001c      0x00000001    
 0xc01268b0
r24-27  0x00000000      0x00000400      0x00000000    
 0xc009f000
r28-31  0xc01db000      0x0000000b      0xc01a4f40    
 0xc007a39c
sr0-3   0x00000000      0x00000000      0x00000000    
 0x00000000
sr4-7   0x00000000      0x00000000      0x00000000    
 0x00000000
iasq 0x00000020 0x00000003
iaoq 0xc004a078 0xc004a07c
cr30 0x00000000 ksp 0x00000001 kpc 0xc01a4f80 sar
0x00000012
iir 0x48730038

The last successful booting kernel was from the CVS
version 19991123.

Any ideas ?
Ulrich

--- Paul Bame <bame@debian.fc.hp.com> wrote:
> 
> I just committed the changes to embed real-mode code
> in a separate
> executable inside vmlinux.  It should cause no
> functional changes
> in theory.  Read all about it in
> arch/parisc/real/README and
> ee.html.  If you have terrible new problems,
> I've attached a list of CVS commands to check out
> the files before I
> started hacking on them.  I haven't seen a shell
> prompt from this
> set of hacks so beware...
> 
> 	-Paul Bame
> 
> prumpf- I moved kernel_thread and friends from
> 	real/<something> to kernel/head.S  I also
> re-enabled BTLB in
> 	real/setup.c so I could get further in the boot. 
> Left some
> 	debugging printks in the handle_real_interrupt
> handler too.
> 
> cvs update -r1.25 arch/parisc/Makefile
> 	cvs update -A arch/parisc/Makefile
> cvs update -r1.28 arch/parisc/kernel/Makefile
> 	cvs update -A arch/parisc/kernel/Makefile
> cvs update -r1.35 arch/parisc/kernel/head.S
> 	cvs update -A arch/parisc/kernel/head.S
> cvs update -r1.39 arch/parisc/kernel/irq.c
> 	cvs update -A arch/parisc/kernel/irq.c
> cvs update -r1.14 arch/parisc/kernel/pdc.c
> 	cvs update -A arch/parisc/kernel/pdc.c
> cvs update -r1.25 arch/parisc/kernel/pdc_cons.c
> 	cvs update -A arch/parisc/kernel/pdc_cons.c
> cvs update -r1.73 arch/parisc/kernel/setup.c
> 	cvs update -A arch/parisc/kernel/setup.c
> cvs update -r1.11 arch/parisc/kernel/traps.c
> 	cvs update -A arch/parisc/kernel/traps.c
> cvs update -r1.2 arch/parisc/real/Makefile
> 	cvs update -A arch/parisc/real/Makefile
> cvs update -r1.2 arch/parisc/real/head.S
> 	cvs update -A arch/parisc/real/head.S
> cvs update -r1.2 arch/parisc/real/interruption.S
> 	cvs update -A arch/parisc/real/interruption.S
> cvs update -r1.2 arch/parisc/real/lib.c
> 	cvs update -A arch/parisc/real/lib.c
> cvs update -r1.2 arch/parisc/real/pdc.c
> 	cvs update -A arch/parisc/real/pdc.c
> cvs update -r1.2 arch/parisc/real/real.h
> 	cvs update -A arch/parisc/real/real.h
> cvs update -r1.2 arch/parisc/real/real_s.S
> 	cvs update -A arch/parisc/real/real_s.S
> cvs update -r1.2 arch/parisc/real/setup.c
> 	cvs update -A arch/parisc/real/setup.c
> cvs update -r1.1 arch/parisc/real/traps.c
> 	cvs update -A arch/parisc/real/traps.c
> cvs update -r1.1 include/asm-parisc/real.h
> 	cvs update -A include/asm-parisc/real.h
> 
>
---------------------------------------------------------------------------
> To unsubscribe: send e-mail to
> parisc-linux-request@thepuffingroup.com with
> `unsubscribe' as the subject.
> 
> 

__________________________________________________
Do You Yahoo!?
Thousands of Stores.  Millions of Products.  All in one place.
Yahoo! Shopping: http://shopping.yahoo.com

Re: [parisc-linux] a pretty big change

[Paul Bame]

= Hi all,
= 
= I have build a new kernel with the CVS version
= 19991205 and I get the following console output when I
= try to boot it on my 715/33:

If you'll place that kernel somewhere I can get it, I'll check
this, or you can.  Look into the kernel and/or System.map
for what's at 0xc004a078, which is inside a procedure which will
return to 0xc0112000.  It looks like a null (or small) pointer
dereference because we're trying to create a virtual mapping for address 0.

	-P

= PARISC/Linux Bootstrap Version 0.6 (interactive)
= By Helge Deller & Jason Eckhardt
= Built Mon Dec 6 11:13:34 MET 1999 by root@be5359
= 
= Reading parameters...done.
= 
= Loading PA-RISC/Linux Kernel...
= 
= Please enter the command-line:
= /stand/vmlinux HOME=/ TERM=LINUX console=tty
= 
= SOM-Kernel:
= aux_header_location: 00000080
= som       : 00200080
= exec_dfile: 000CE000
= exec_dsize: 00081000
= exec_dmem : C00A0000
= exec_tfile: 0003E000
= exec_tsize: 0008F008
= exec_tmem : C0010000
= Code at 0x00010000, size=0x0008F008
= Data at 0x000A0000, size=0x00081000
= BSS  at 0x00121000.
= 
= Transferring control to kernel. (At entry point
= 0x00010000)
= kernel(0x146880, 0x504010, 0x146880, 0x12c30)
= Boot loader: PA/Linux, maybe PALO
= kernel free mem 0x00146880
= realmode_setup exiting
= Can't insert TLB miss handler pa 0x40000000 va
= 0x00000000
= r0-3    0x0004fb0b      0xc0112000      0xc004a170    
=  0x00000000
= r4-7    0xc0112000      0x00000000      0x00000400    
=  0x00000000
= r8-11   0xc01db000      0x00000000      0x00000400    
=  0x00000100
= r12-15  0xc01a4988      0x00000000      0x00000000    
=  0x00000000
= r16-19  0x00000000      0x00000400      0x00001000    
=  0x0000001f
= r20-23  0x00000020      0xc01a001c      0x00000001    
=  0xc01268b0
= r24-27  0x00000000      0x00000400      0x00000000    
=  0xc009f000
= r28-31  0xc01db000      0x0000000b      0xc01a4f40    
=  0xc007a39c
= sr0-3   0x00000000      0x00000000      0x00000000    
=  0x00000000
= sr4-7   0x00000000      0x00000000      0x00000000    
=  0x00000000
= iasq 0x00000020 0x00000003
= iaoq 0xc004a078 0xc004a07c
= cr30 0x00000000 ksp 0x00000001 kpc 0xc01a4f80 sar
= 0x00000012
= iir 0x48730038
= 
= The last successful booting kernel was from the CVS
= version 19991123.
= 
= Any ideas ?
= Ulrich
= 
= --- Paul Bame <bame@debian.fc.hp.com> wrote:
= > 
= > I just committed the changes to embed real-mode code
= > in a separate
= > executable inside vmlinux.  It should cause no
= > functional changes
= > in theory.  Read all about it in
= > arch/parisc/real/README and
= > ee.html.  If you have terrible new problems,
= > I've attached a list of CVS commands to check out
= > the files before I
= > started hacking on them.  I haven't seen a shell
= > prompt from this
= > set of hacks so beware...
= > 
= > 	-Paul Bame
= > 
= > prumpf- I moved kernel_thread and friends from
= > 	real/<something> to kernel/head.S  I also
= > re-enabled BTLB in
= > 	real/setup.c so I could get further in the boot. 
= > Left some
= > 	debugging printks in the handle_real_interrupt
= > handler too.
= > 
= > cvs update -r1.25 arch/parisc/Makefile
= > 	cvs update -A arch/parisc/Makefile
= > cvs update -r1.28 arch/parisc/kernel/Makefile
= > 	cvs update -A arch/parisc/kernel/Makefile
= > cvs update -r1.35 arch/parisc/kernel/head.S
= > 	cvs update -A arch/parisc/kernel/head.S
= > cvs update -r1.39 arch/parisc/kernel/irq.c
= > 	cvs update -A arch/parisc/kernel/irq.c
= > cvs update -r1.14 arch/parisc/kernel/pdc.c
= > 	cvs update -A arch/parisc/kernel/pdc.c
= > cvs update -r1.25 arch/parisc/kernel/pdc_cons.c
= > 	cvs update -A arch/parisc/kernel/pdc_cons.c
= > cvs update -r1.73 arch/parisc/kernel/setup.c
= > 	cvs update -A arch/parisc/kernel/setup.c
= > cvs update -r1.11 arch/parisc/kernel/traps.c
= > 	cvs update -A arch/parisc/kernel/traps.c
= > cvs update -r1.2 arch/parisc/real/Makefile
= > 	cvs update -A arch/parisc/real/Makefile
= > cvs update -r1.2 arch/parisc/real/head.S
= > 	cvs update -A arch/parisc/real/head.S
= > cvs update -r1.2 arch/parisc/real/interruption.S
= > 	cvs update -A arch/parisc/real/interruption.S
= > cvs update -r1.2 arch/parisc/real/lib.c
= > 	cvs update -A arch/parisc/real/lib.c
= > cvs update -r1.2 arch/parisc/real/pdc.c
= > 	cvs update -A arch/parisc/real/pdc.c
= > cvs update -r1.2 arch/parisc/real/real.h
= > 	cvs update -A arch/parisc/real/real.h
= > cvs update -r1.2 arch/parisc/real/real_s.S
= > 	cvs update -A arch/parisc/real/real_s.S
= > cvs update -r1.2 arch/parisc/real/setup.c
= > 	cvs update -A arch/parisc/real/setup.c
= > cvs update -r1.1 arch/parisc/real/traps.c
= > 	cvs update -A arch/parisc/real/traps.c
= > cvs update -r1.1 include/asm-parisc/real.h
= > 	cvs update -A include/asm-parisc/real.h
= > 
= >
= ---------------------------------------------------------------------------
= > To unsubscribe: send e-mail to
= > parisc-linux-request@thepuffingroup.com with
= > `unsubscribe' as the subject.
= > 
= > 
= 
= __________________________________________________
= Do You Yahoo!?
= Thousands of Stores.  Millions of Products.  All in one place.
= Yahoo! Shopping: http://shopping.yahoo.com

Re: [parisc-linux] a pretty big change

[LaMont Jones]

> That happens pretty frequently to me but I've not tracked down why
> it happens.  Did you try holding the TOC button in for several seconds?
> On some workstations I've been told that generates a hard reset.

TOC results in (providing that the checksum passes) transfer of control
to a routine pointed at from page 0.  If something is trashing that, and
the checksum'ed length is set to 0, then you'll branch off into the ozone.

If the checksum fails, then you get the PDC default of rebooting.

Don't know if that's your problem, but it's probably worth checking into
whether something is trashing physical address 8 (TOC vector - 0xc is the
length of the checksum.)

lamont

Re: [parisc-linux] a pretty big change

[Ulrich Strelow]

Hello Paul,

thanks for the quick answer. I am sorry but I did not
understand what I see in System.map:

excerpt 1 for System.Map:
c0049f90 t $CODE$
c0049f90 t put_unused_buffer_head
c0049fd8 t L$1856
c004a004 t L$1854
c004a018 t $CODE$
c004a018 t get_unused_buffer_head
c004a110 t $CODE$
c004a110 t create_buffers
c004a320 t $CODE$
c004a320 t end_buffer_io_async

So I thought 0xc004a078 is in get_unused_buffer_head
which is in fs/buffer.c.

excerpt 2 from System.map:
c0111f14 D blkdev_inode_operations
c0111f64 D def_chr_fops
c0111fa0 D chrdev_inode_operations
c0111ff0 d L$C0008
c0111ffc d L$C0009
c011200c d L$C0010
c0112018 d L$C0011
c0112028 d L$C0012
c0112038 D nr_files
c0112038 d lock___76

So 0xc0112000 points into the data segment(?) as a
return address for that subroutine.

Unfortunately I have no anonymous ftp server here at
work, where I can put the kernel for you. And
puffin.external.hp.com has no Incoming directory...

So is it ok to send Image + System.map as a
tar.gz-file via mail to you?

If this problem is not of general interest and other
big changes will happen soon (maybe the 2.3 merge)
where the problem might go away, it is ok that you
simply say "wait for that to happen" to me. 
 
Regards
Ulrich

--- Paul Bame <bame@fc.hp.com> wrote:
> = Hi all,
> = 
> = I have build a new kernel with the CVS version
> = 19991205 and I get the following console output
> when I
> = try to boot it on my 715/33:
> 
> If you'll place that kernel somewhere I can get it,
> I'll check
> this, or you can.  Look into the kernel and/or
> System.map
> for what's at 0xc004a078, which is inside a
> procedure which will
> return to 0xc0112000.  It looks like a null (or
> small) pointer
> dereference because we're trying to create a virtual
> mapping for address 0.
> 
> 	-P
> 
> = PARISC/Linux Bootstrap Version 0.6 (interactive)
> = By Helge Deller & Jason Eckhardt
> = Built Mon Dec 6 11:13:34 MET 1999 by root@be5359
> = 
> = Reading parameters...done.
> = 
> = Loading PA-RISC/Linux Kernel...
> = 
> = Please enter the command-line:
> = /stand/vmlinux HOME=/ TERM=LINUX console=tty
> = 
> = SOM-Kernel:
> = aux_header_location: 00000080
> = som       : 00200080
> = exec_dfile: 000CE000
> = exec_dsize: 00081000
> = exec_dmem : C00A0000
> = exec_tfile: 0003E000
> = exec_tsize: 0008F008
> = exec_tmem : C0010000
> = Code at 0x00010000, size=0x0008F008
> = Data at 0x000A0000, size=0x00081000
> = BSS  at 0x00121000.
> = 
> = Transferring control to kernel. (At entry point
> = 0x00010000)
> = kernel(0x146880, 0x504010, 0x146880, 0x12c30)
> = Boot loader: PA/Linux, maybe PALO
> = kernel free mem 0x00146880
> = realmode_setup exiting
> = Can't insert TLB miss handler pa 0x40000000 va
> = 0x00000000
> = r0-3    0x0004fb0b      0xc0112000      0xc004a170
>    
> =  0x00000000
> = r4-7    0xc0112000      0x00000000      0x00000400
>    
> =  0x00000000
> = r8-11   0xc01db000      0x00000000      0x00000400
>    
> =  0x00000100
> = r12-15  0xc01a4988      0x00000000      0x00000000
>    
> =  0x00000000
> = r16-19  0x00000000      0x00000400      0x00001000
>    
> =  0x0000001f
> = r20-23  0x00000020      0xc01a001c      0x00000001
>    
> =  0xc01268b0
> = r24-27  0x00000000      0x00000400      0x00000000
>    
> =  0xc009f000
> = r28-31  0xc01db000      0x0000000b      0xc01a4f40
>    
> =  0xc007a39c
> = sr0-3   0x00000000      0x00000000      0x00000000
>    
> =  0x00000000
> = sr4-7   0x00000000      0x00000000      0x00000000
>    
> =  0x00000000
> = iasq 0x00000020 0x00000003
> = iaoq 0xc004a078 0xc004a07c
> = cr30 0x00000000 ksp 0x00000001 kpc 0xc01a4f80 sar
> = 0x00000012
> = iir 0x48730038
> = 
> = The last successful booting kernel was from the
> CVS
> = version 19991123.
> = 
> = Any ideas ?
> = Ulrich
> = 
> = --- Paul Bame <bame@debian.fc.hp.com> wrote:
> = > 
> = > I just committed the changes to embed real-mode
> code
> = > in a separate
> = > executable inside vmlinux.  It should cause no
> = > functional changes
> = > in theory.  Read all about it in
> = > arch/parisc/real/README and
> = > ee.html.  If you have terrible new problems,
> = > I've attached a list of CVS commands to check
> out
> = > the files before I
> = > started hacking on them.  I haven't seen a shell
> = > prompt from this
> = > set of hacks so beware...
> = > 
> = > 	-Paul Bame
> = > 
> = > prumpf- I moved kernel_thread and friends from
> = > 	real/<something> to kernel/head.S  I also
> = > re-enabled BTLB in
> = > 	real/setup.c so I could get further in the
> boot. 
> = > Left some
> = > 	debugging printks in the handle_real_interrupt
> = > handler too.
> = > 
> = > cvs update -r1.25 arch/parisc/Makefile
> = > 	cvs update -A arch/parisc/Makefile
> = > cvs update -r1.28 arch/parisc/kernel/Makefile
> = > 	cvs update -A arch/parisc/kernel/Makefile
> = > cvs update -r1.35 arch/parisc/kernel/head.S
> = > 	cvs update -A arch/parisc/kernel/head.S
> = > cvs update -r1.39 arch/parisc/kernel/irq.c
> = > 	cvs update -A arch/parisc/kernel/irq.c
> = > cvs update -r1.14 arch/parisc/kernel/pdc.c
> = > 	cvs update -A arch/parisc/kernel/pdc.c
> = > cvs update -r1.25 arch/parisc/kernel/pdc_cons.c
> = > 	cvs update -A arch/parisc/kernel/pdc_cons.c
> = > cvs update -r1.73 arch/parisc/kernel/setup.c
> = > 	cvs update -A arch/parisc/kernel/setup.c
> = > cvs update -r1.11 arch/parisc/kernel/traps.c
> = > 	cvs update -A arch/parisc/kernel/traps.c
> = > cvs update -r1.2 arch/parisc/real/Makefile
> = > 	cvs update -A arch/parisc/real/Makefile
> = > cvs update -r1.2 arch/parisc/real/head.S
> = > 	cvs update -A arch/parisc/real/head.S
> = > cvs update -r1.2 arch/parisc/real/interruption.S
> = > 	cvs update -A arch/parisc/real/interruption.S
> = > cvs update -r1.2 arch/parisc/real/lib.c
> = > 	cvs update -A arch/parisc/real/lib.c
> = > cvs update -r1.2 arch/parisc/real/pdc.c
> = > 	cvs update -A arch/parisc/real/pdc.c
> = > cvs update -r1.2 arch/parisc/real/real.h
> = > 	cvs update -A arch/parisc/real/real.h
> = > cvs update -r1.2 arch/parisc/real/real_s.S
> = > 	cvs update -A arch/parisc/real/real_s.S
> = > cvs update -r1.2 arch/parisc/real/setup.c
> = > 	cvs update -A arch/parisc/real/setup.c
> = > cvs update -r1.1 arch/parisc/real/traps.c
> = > 	cvs update -A arch/parisc/real/traps.c
> = > cvs update -r1.1 include/asm-parisc/real.h
> = > 	cvs update -A include/asm-parisc/real.h
> = > 
> = >
> =
>
---------------------------------------------------------------------------
> = > To unsubscribe: send e-mail to
> = > parisc-linux-request@thepuffingroup.com with
> = > `unsubscribe' as the subject.
> = > 
> = > 
> = 
> = __________________________________________________
> = Do You Yahoo!?
> = Thousands of Stores.  Millions of Products.  All
> in one place.
> = Yahoo! Shopping: http://shopping.yahoo.com
> 

__________________________________________________
Do You Yahoo!?
Thousands of Stores.  Millions of Products.  All in one place.
Yahoo! Shopping: http://shopping.yahoo.com

Re: [parisc-linux] a pretty big change

[John David Anglin]

> So I thought 0xc004a078 is in get_unused_buffer_head
> which is in fs/buffer.c.

I think the bug you are seeing is due to the inline definition for
xchg in asm/system.h.  The problem occurs in exchanges with 0 when
the address used in the ldcws instruction is not aligned on a 16 byte
boundary.  Change the define for xchg to just use the spinlock method
in all cases.

The other option is to align all the addresses that are used in xchg's
with 0.

Dave
-- 
J. David Anglin                                  dave.anglin@nrc.ca
National Research Council of Canada              (613) 990-0752 (FAX: 952-6605)

Re: [parisc-linux] a pretty big change

[Paul Bame]

Ulrich,

I apologize for suggesting you consider the
r1 value 0xc0112000 by mistake, I meant the r2 value 0xc004a170.

Re: [parisc-linux] a pretty big change

[John David Anglin]

> 
> 
> Ulrich,
> 
> I apologize for suggesting you consider the
> r1 value 0xc0112000 by mistake, I meant the r2 value 0xc004a170.
> >From the r2 and iaoq values, it looks like create_buffers():
> 
> create_buffers+4C:              STW             r0,-116(r30)
>                 LDI             4096,r4
>                 SUB             r4,r8,r4
>                 COMIB,>         0,r4,create_buffers+0x00a0
>                 LDI             0,r3
>                 ZDEPI           -1,31,16,r5
>                 BL              get_unused_buffer_head,r2
>                 OR              r9,r0,r26
>                 MOVB,=,N        r28,r26,create_buffers+0x00a8	***** %r2
>                 STW             r3,20(r26)
> 
> Just called get_unused_buffer_head, which died on the indicated line:
> 
> get_unused_buffer_head+4C:      ADDIL           L%0x73000,r27
>                 LDO             -1(r20),r20 	; nr_unused_buffer_heads--
>                 LDW             232(r1),r3	; r3 = bh
>                 STW             r20,264(r4)	; nr_unused_buffer_heads--
>                 OR              r3,r0,r28	; return value = r3
>                 LDW             28(r3),r19	*** died here
>                 B               get_unused_buffer_head+0x00e0
>                 STW             r19,232(r1)
> 
> Since %r3 is zero at this moment, we die.  I think we are dying trying
> to execute 'unused_list = bh->b_next_free;' in get_unused_buffer_head()
> with bh = 0.  No idea why.

See my mail to the list on Nov. 30, "Re: [parisc-linux] Progress - Update".  xchg has clobbered unused_list.

Dave
-- 
J. David Anglin                                  dave.anglin@nrc.ca
National Research Council of Canada              (613) 990-0752 (FAX: 952-6605)

Re: [parisc-linux] a pretty big change

[John David Anglin]

> 
> > That happens pretty frequently to me but I've not tracked down why
> > it happens.  Did you try holding the TOC button in for several seconds?
> > On some workstations I've been told that generates a hard reset.
> 
> TOC results in (providing that the checksum passes) transfer of control
> to a routine pointed at from page 0.  If something is trashing that, and
> the checksum'ed length is set to 0, then you'll branch off into the ozone.
> 
> If the checksum fails, then you get the PDC default of rebooting.
> 
> Don't know if that's your problem, but it's probably worth checking into
> whether something is trashing physical address 8 (TOC vector - 0xc is the
> length of the checksum.)

I believe that I have located the cause of the problem.  The real mode
code in the kernel startup used the stack pointer passed from the system
loader.  The initial stack pointer passed by the hpux loader is 0.
This caused some items in PAGE0 to be trashed, although it is not clear
that the TOC vector itself was being trashed.

Dave
-- 
J. David Anglin                                  dave.anglin@nrc.ca
National Research Council of Canada              (613) 990-0752 (FAX: 952-6605)