From marteaut@esiee.fr Thu, 16 Nov 2000 21:16:22 +0100 Date: Thu, 16 Nov 2000 21:16:22 +0100 From: Thomas Marteau marteaut@esiee.fr Subject: [parisc-linux] Troubles with read only file system Hi all, We have done everything well but the NFSroot and the bootable disk say that we have a read only file system ??? What is the recipe for making a bootable disk because ours can not be the good one... Thanks, Thomas From marteaut@esiee.fr Fri, 17 Nov 2000 17:59:14 +0100 Date: Fri, 17 Nov 2000 17:59:14 +0100 From: Thomas Marteau marteaut@esiee.fr Subject: [parisc-linux] Trouble with new STI This is a multi-part message in MIME format. ------=_NextPart_000_000F_01C050C0.18E3D060 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi all, We've tried the new STI driver and our 712 dies with this message: Kernel Panic: VFS: Unable to mount root fs on 01:00 We tried with Ramdisk, nfs and hard disk support and always the same = end. Also, the death happens when you 've passed bootp request... Help! Thomas ------=_NextPart_000_000F_01C050C0.18E3D060 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi all,
 
We've tried the new STI driver and our = 712 dies=20 with this message:
 
Kernel Panic: VFS: Unable to mount root = fs on=20 01:00
 
We tried with Ramdisk, nfs and hard = disk support=20 and always the same end.
Also, the death happens when you 've = passed bootp=20 request...
 
Help!
 
Thomas
------=_NextPart_000_000F_01C050C0.18E3D060-- From marteaut@esiee.fr Sun, 19 Nov 2000 13:08:45 +0100 Date: Sun, 19 Nov 2000 13:08:45 +0100 From: Thomas Marteau marteaut@esiee.fr Subject: [parisc-linux] Booting 712 STI and nfs This is a multi-part message in MIME format. ------=_NextPart_000_0047_01C05229.D8DA5D20 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi all, We managed to boot on the STI-console with a 712/80 in changing the = parameters in inittab and in securetty (if you want to login as root).=20 > cat inittab (! just the interesting thing!) # /sbin/getty invocations for the runlevels. # # The "id" field MUST be the same as the last # characters of the device (after "tty"). # # Format: # ::: 1:2345:respawn:/sbin/getty 38400 tty1 #2:23:respawn:/sbin/getty 38400 tty2 #3:23:respawn:/sbin/getty 38400 tty3 #4:23:respawn:/sbin/getty 38400 tty4 #5:23:respawn:/sbin/getty 38400 tty5 #6:23:respawn:/sbin/getty 38400 tty6 =20 > cat securetty # /etc/securetty: list of terminals on which root is allowed to login. # See securetty(5) and login(1). ttyS0 tty1 Also, in order to boot with the STI console, you need to have the module = for STI-console and not for serial console support... But, we have troubles with the rpc that print somestimes nfs: server X.X.X.165 not responding, still trying nfs: server X.X.X.165 OK nfs: server X.X.X.165 not responding, still trying nfs: server X.X.X.165 OK nfs: server X.X.X.165 not responding, still trying nfs: server X.X.X.165 OK We don't understand where comes from the problem!! Bye, ESIEE Port Team ------=_NextPart_000_0047_01C05229.D8DA5D20 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi all,
 
We managed to boot on the STI-console = with a 712/80=20 in changing the parameters in inittab and in securetty (if you want to = login as=20 root).
 
> cat inittab (! just the = interesting=20 thing!)
# /sbin/getty invocations for the=20 runlevels.
#
# The "id" field MUST be the same as the last
# = characters=20 of the device (after "tty").
#
# Format:
# =20 <id>:<runlevels>:<action>:<process>
1:2345:res= pawn:/sbin/getty=20 38400 tty1
#2:23:respawn:/sbin/getty 38400 = tty2
#3:23:respawn:/sbin/getty=20 38400 tty3
#4:23:respawn:/sbin/getty 38400 = tty4
#5:23:respawn:/sbin/getty=20 38400 tty5
#6:23:respawn:/sbin/getty 38400 tty6
 
 
 
> cat securetty
# /etc/securetty: list of terminals on = which root=20 is allowed to login.
# See securetty(5) and=20 login(1).
ttyS0
tty1
 
Also, in order to boot with the STI = console, you=20 need to have the module for STI-console and not for serial console=20 support...
 
But, we have troubles with the rpc that = print=20 somestimes
nfs: server X.X.X.165 not responding, = still=20 trying
nfs: server X.X.X.165 OK
nfs: server X.X.X.165 not responding, = still=20 trying
nfs: server X.X.X.165 OK
nfs: server X.X.X.165 not responding, = still=20 trying
nfs: server X.X.X.165 OK
We don't understand where comes from the problem!!
 
Bye,
ESIEE Port Team
------=_NextPart_000_0047_01C05229.D8DA5D20-- From marteaut@esiee.fr Mon, 20 Nov 2000 15:32:55 +0100 Date: Mon, 20 Nov 2000 15:32:55 +0100 From: Thomas Marteau marteaut@esiee.fr Subject: [parisc-linux] A new file system This is a multi-part message in MIME format. ------=_NextPart_000_0009_01C05307.27222700 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi all, Since we have the STI, we have produced a file system quite = interesting for the 712. You can have a network support till you configure the file.conf like resolv... = Also, we have noticed that the sti on B180 does not work well, it look like it can not find the = rom. But we have to work on... To download the archives go there: http://www.esiee.fr/~djoudim/code/suitable.html It is incredible what can do a 712 with it! Bye, ESIEE Port Team ------=_NextPart_000_0009_01C05307.27222700 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi all,
 
    Since we have the = STI, we have=20 produced a file system quite interesting for the 712. You = can
have a network support till you = configure the=20 file.conf like resolv... Also, we have noticed that
the sti on B180 does not work well, it = look like it=20 can not find the rom. But we have to work on...
 
To download the archives go = there:
http://www.esiee= .fr/~djoudim/code/suitable.html
 
It is incredible what can do a 712 with = it!
 
Bye,
ESIEE Port Team
------=_NextPart_000_0009_01C05307.27222700-- From kailasr@webcash.com Tue, 31 Oct 2000 12:58:41 -0800 Date: Tue, 31 Oct 2000 12:58:41 -0800 From: Kailashnath V Rampure kailasr@webcash.com Subject: [parisc-linux] unable to run palo on nfs root Hi Paul, After booting the Server from NFSroot I need to Initialize the harddisk on the server. so I copied the palo and linux in to the nfsroot. I am trying to Run the following command: $ palo -I -k /boot/vmlinux -b /boot/iplboot -c '2/boot/vmlinux TERM=linux HOME=/ root=/dev/sda2' /dev/sda fisrt partition is 10M of type f0 second partition is /dev/sda2 of type linux native. Third partition is /dev/sda3 of type linux Swap Then I get the cannot execute binary file. second question is that what is the Terminal type I should set as I am unable to open vi. Please suggest the correct steps. Thanks. Kailas At 09:54 AM 10/31/00 -0700, Paul Bame wrote: >= Hi, >= >= I have booted HP A class server from nfsroot. but when I try to run palo on >= the server to initialize boot loader to the hdd I get >= "cannot execute the binary file" >= >= can any one help me to make the hdd bootable > >It would help me to see the actual command you used and the actual >error message(s) printed. With the info you give so far it could be >"a million" things. > > -P From bame@noam.fc.hp.com Tue, 31 Oct 2000 14:26:00 -0700 Date: Tue, 31 Oct 2000 14:26:00 -0700 From: Paul Bame bame@noam.fc.hp.com Subject: [parisc-linux] NEW NATIVE PALO TARBALL - REQUIRED = Hi Paul, = = After booting the Server from NFSroot I need to Initialize the harddisk on = the server. so I copied the palo and linux in to the nfsroot. I am trying = to Run the following command: = $ palo -I -k /boot/vmlinux -b /boot/iplboot -c '2/boot/vmlinux TERM=linux = HOME=/ root=/dev/sda2' /dev/sda = fisrt partition is 10M of type f0 = second partition is /dev/sda2 of type linux native. = Third partition is /dev/sda3 of type linux Swap That looks great. = Then I get the cannot execute binary file. Ok I think we changed the kernal such that the old palo bits won't run any more (we removed the old gateway page). I uploaded a new version: ftp://puffin.external.hp.com/pub/parisc/binaries/userspace/palo-200001031.tgz -P From grundler@cup.hp.com Tue, 31 Oct 2000 13:53:04 -0800 Date: Tue, 31 Oct 2000 13:53:04 -0800 From: Grant Grundler grundler@cup.hp.com Subject: [parisc-linux] unable to run palo on nfs root Kailashnath V Rampure wrote: > fisrt partition is 10M of type f0 > second partition is /dev/sda2 of type linux native. > Third partition is /dev/sda3 of type linux Swap Kailashnath, Even though your partitioning should work fine, you really want the swap on the lowest numbered SCSI block you can get away with. Several reasons for this: o lowest block number is on the outside of the SCSI disk were data xfer rate is typically 80% faster than the inside. (someday try "time dd if=/dev/sda of=/dev/null bs=8k count=50" with and with out skip parameter). o Eventualy we will have kernel dumps to swap space - and IODC will likely have the same limitations where on the disk dump can be as we have with booting from a disk (as discussed in the PALO documentation). grant Grant Grundler Unix Systems Enablement Lab +1.408.447.7253 From taggart@carmen.fc.hp.com Tue, 31 Oct 2000 16:16:09 -0700 Date: Tue, 31 Oct 2000 16:16:09 -0700 From: Matt Taggart taggart@carmen.fc.hp.com Subject: [parisc-linux] New cross-compiler I have placed a new i386-linux -> hppa32/64-linux cross compiler (with 32bit glibc) in, ftp://puffin.external.hp.com/pub/parisc/binaries/LinuxX86/xc-20001031.tar.gz It includes Alan Modra's recent fix for the 64 bit compiler, http://puffin.external.hp.com/mailing-lists/parisc-linux-cvs/2000/10-Oct/0233.h tml -- Matt Taggart taggart@fc.hp.com From pdbeal@bealz.net Tue, 31 Oct 2000 18:43:06 -0500 Date: Tue, 31 Oct 2000 18:43:06 -0500 From: Phillip Beal pdbeal@bealz.net Subject: [parisc-linux] 735 and Thin Lan Hey, I've obtained two HP 735's and I'd like to try the linus port on them. I have compiled a kernel, but it never boots the nfsroot disk. It has the same problem that the HP 755 that I've worked with. However, it has a different ethernet connection. The 735 has a thin lan connection. What network device should be used in the kernel to be able to use the thin lan adapter? Here's the info on the Thin lan: Outfield Core LAN (802.3) (10) at 0xf0826000 versions 0x9, 0x0, 0x72, 0x0, 0x0 Thanks, -- Phillip Beal S+LUG Vice-President From deller@gmx.de Wed, 1 Nov 2000 00:57:22 +0100 Date: Wed, 1 Nov 2000 00:57:22 +0100 From: Helge Deller deller@gmx.de Subject: [parisc-linux] 735 and Thin Lan On Wednesday 01 November 2000 00:43, Phillip Beal wrote: > Hey, > > I've obtained two HP 735's and I'd like to try the linus port on them. > I have compiled a kernel, but it never boots the nfsroot disk. It has > the same problem that the HP 755 that I've worked with. However, it has > a different ethernet connection. The 735 has a thin lan connection. > What network device should be used in the kernel to be able to use the > thin lan adapter? Here's the info on the Thin lan: > > Outfield Core LAN (802.3) (10) at 0xf0826000 versions 0x9, 0x0, 0x72, > 0x0, 0x0 > > Thanks, > Phillip Beal > S+LUG Vice-President Hi Phillip, I think the "Lasi ethernet"-driver (enabled by default in our configuration) should work on both of your boxes. Helge. From deller@gmx.de Wed, 1 Nov 2000 01:45:52 +0100 Date: Wed, 1 Nov 2000 01:45:52 +0100 From: Helge Deller deller@gmx.de Subject: [parisc-linux] The new PS/2 Keyboard Driver On Friday 27 October 2000 01:50, Helge Deller wrote: > On Thursday 26 October 2000 22:05, Thomas Marteau wrote: > > > > > > Hello everyone, > > > > We've just updated the PS/2 keyboard driver. The leds and interrupt > > functions work really well on a 712 workstation and also B132 now. The > > updated driver files are available on our website. It works better than > > under HP UX for the B 132 ;-> > > > > http://www.esiee.fr/~djoudim > > > > The ESIEE Port Team in Paris. > > > > Here is the patch: > > > > diff -urN linux/drivers/char/gsc_ps2.c linux-parisc/drivers/char/gsc_ps2.c > > --- linux/drivers/char/gsc_ps2.c Thu Oct 26 21:06:54 2000 > > +++ linux-parisc/drivers/char/gsc_ps2.c Thu Oct 26 21:34:00 2000 > > @@ -7,6 +7,11 @@ > > [.............] > > > diff -urN linux/drivers/char/keyb_at.c linux-parisc/drivers/char/keyb_at.c > > --- linux/drivers/char/keyb_at.c Thu Oct 26 21:07:00 2000 > > +++ linux-parisc/drivers/char/keyb_at.c Thu Oct 26 21:23:16 2000 > > [........] > > Hi Thomas, > > Thanks for your patch. > But I don't think it's a good idea to change a common file like keyb_at.c, > which is used in most other arches too. This patch surely breaks their > keyboard support and more than that I'm sure, that Linus will not accept this > patch, when the time is come to integrate parisc into the official kernel. > > Isn't there any other solution as for example to #ifdef the code or create a > new keyb_at.c for parisc (Yes I know, both of those aren't clean too.) ? > > Helge Deller Hi folks, I need to correct myself on this topic. The ESIEE-team made a great patch and didn't changed any globally used file. keyb_at.c is just used in the current parisc-port, and so it's ok to change that file. I just committed their changes to the CVS, and in the same cycle tried to clean up the code. In the same step I renamed the original filenames to some hopefully better ones. Since I don't own myself a real HP PS/2 keyboard (it's just an PC-AT one with a small DIN to PS/2-connector), it would be great to get some feedback if I did the Right Thing. Helge. From bri@mojo.calyx.net Wed, 1 Nov 2000 02:48:02 -0500 (EST) Date: Wed, 1 Nov 2000 02:48:02 -0500 (EST) From: Brian S. Julin bri@mojo.calyx.net Subject: [parisc-linux] The new PS/2 Keyboard Driver Probably best not to worry about cleaning keyboard drivers up too much. The current USB code will be followed by linux-input style drivers at some point. In fact I started a HIL linux-input style driver, which would abstract the PS2 port/HIL ports and allow a standard keyboard module to be hooked into the abstracted serio port. I will work on it more when time permits. -- Brian S. Julin From jsm@udlkern.fc.hp.com Wed, 1 Nov 2000 02:37:58 -0700 (MST) Date: Wed, 1 Nov 2000 02:37:58 -0700 (MST) From: John Marvin jsm@udlkern.fc.hp.com Subject: Elf Header change proposal Paul and Alan pointed out that I goofed. I analyzed the vmlinux in my 64 bit build area to get the current flags, but it turns out that the vmlinux I looked at was a 32 bit version. I had recently made some 64 bit checkins, and I like to rebuild everything for 32 bit before doing that, to make sure that I haven't broken the 32 bit path by making 64 bit changes. So, the bad news is that I wasted time writing an unecessarily long design proposal. The good news is that the only thing that needs to change is value in the e_ident[EI_OSABI] field, so that we can differentiate 64 bit HP-UX binaries from 64 bit Linux binaries. We should also change the field for 32 bit Linux also. John From jsm@udlkern.fc.hp.com Wed, 1 Nov 2000 03:35:49 -0700 (MST) Date: Wed, 1 Nov 2000 03:35:49 -0700 (MST) From: John Marvin jsm@udlkern.fc.hp.com Subject: space registers Matthew Wilcox wrote: > a small optimisation just occurred to me. > > right now, when we switch to kernel space, we set all of sr4-sr7 to 0 > (for the kernel mapping). we don't need to do that since the kernel is > entirely in sr7's domain. this has the added bonus that badly written > drivers which blindly dereference userspace pointers will work on > parisc as well as x86. we can also lazily restore sr4-6 on exit from > kernel space if we're switching back to the same task which called us. > this optimisation may not be worthwhile, but i think setting sr4-6 > on entry to the kernel is unnecessary. True for now. But it won't always be true. It is a desired goal to be able to support large (~3.5 Gb) physical memory for the 32 bit port. To do this we will move the kernel down to around virtual address 0, so the kernel address space will then be controlled by sr4, and depending on the amount of physical memory in the machine, possibly sr5, sr6, and sr7. We could do this based on a test of the amount of physical memory in the machine, but once you load something from memory to do the test, and then actually do the test, you wouldn't have any advantage over just writing zero's to the space registers. This might be worth considering for the 64 bit port, since both the kernel and user space will reside entirely within the linear address space covered by sr4 (We would have to go to a 1 Mb page size to be able to support greater than a 62 bit address space with three level page tables). sr5,sr6, and sr7 will only be used when we are running 64 bit HP-UX processes (with its address space broken up into 4 segments). Note that since we just store the users space in sr3 while we are in the kernel, its not clear that any kind of test with a branch would be a performance gain, especially if it required that we load something from memory to do that test. We may be able cover this by managing sr5, sr6 and sr7 only in the HP-UX specific parts of the syscall path. John From alan@linuxcare.com.au Thu, 2 Nov 2000 00:11:11 +1100 (EST) Date: Thu, 2 Nov 2000 00:11:11 +1100 (EST) From: Alan Modra alan@linuxcare.com.au Subject: Elf Header change proposal On Wed, 1 Nov 2000, John Marvin wrote: > So, the bad news is that I wasted time writing an unecessarily long > design proposal. The good news is that the only thing that needs to > change is value in the e_ident[EI_OSABI] field, so that we can > differentiate 64 bit HP-UX binaries from 64 bit Linux binaries. > We should also change the field for 32 bit Linux also. Some other bad news is that the change isn't quite trivial, due to not wishing to break other bfd targets. The good new is I've made the change. Compiling at the moment. Alan Modra -- Linuxcare. Support for the Revolution. From bame@noam.fc.hp.com Wed, 01 Nov 2000 10:59:34 -0700 Date: Wed, 01 Nov 2000 10:59:34 -0700 From: Paul Bame bame@noam.fc.hp.com Subject: [parisc-linux] new method for 64-bit parisc tree I want to propose/discuss a new method for maintaining our 64-bit parisc tree in relation to the 32-bit tree. I have prototyped this and so far it seems pretty useful. Most of the files in the current parisc64 tree only contain one line, a #include of the same file from the parisc tree. This confuses 'make dep', causes some compile errors to have nonsense line numbers, and doesn't allow direct editing of the source files in the parisc64 tree. The method I'm proposing works like this: The future parisc64 tree ONLY contains files which are different from, or in addition to, those in the parisc tree. When you 'make config' or 'make oldconfig', each file in the parsic tree is symbolically linked as the same file in the parisc64 tree. This enables all the rest of the tools/build to work normally. 'make distclean' includes a step to remove all the symlinks. The ugliest "feature" is that even though you can edit source files in the parisc64 tree, 'cvs commit' will fail on those which are symbolic links. To reduce this problem, I'm dropping a symbolic link called '...' in each parisc64 directory which is a pointer to the corresponding parisc directory, so 'cd ...; cvs commit foo.c' will work and not be too onerous. We should additionally consider a naming convention or something so that maintainers in the parisc tree know whether files are shared with parisc64 or not. I prototyped this as a fictional new "architecture" called "p64". To try it out, grab the tarball (only about 30 files -- can be fewer) ftp://puffin.external.hp.com/pub/parisc/ and unpack in your top-level linux source tree directory. Then in your top-level Makefile, change ARCH := parisc64 to ARCH := p64, then make oldconfig or whatever you usually do. Let me know of any problems. Is this something we should adopt for the real parisc64 tree? -Paul Bame From kailasr@webcash.com Wed, 01 Nov 2000 12:30:40 -0800 Date: Wed, 01 Nov 2000 12:30:40 -0800 From: Kailashnath V Rampure kailasr@webcash.com Subject: [parisc-linux] NEW NATIVE PALO TARBALL - REQUIRED Thanks paul I was able to run the command. Can you let me know what I should type at ISL prompt as its trying to boot from /stand/vmunix instead of /boot/vmlinux. Also I am unable to open vi as it says vi:LINUX:unknown terminal type. Please suggest. Regards At 02:26 PM 10/31/00 -0700, Paul Bame wrote: >= Hi Paul, >= >= After booting the Server from NFSroot I need to Initialize the harddisk on >= the server. so I copied the palo and linux in to the nfsroot. I am trying >= to Run the following command: >= $ palo -I -k /boot/vmlinux -b /boot/iplboot -c '2/boot/vmlinux TERM=linux >= HOME=/ root=/dev/sda2' /dev/sda >= fisrt partition is 10M of type f0 >= second partition is /dev/sda2 of type linux native. >= Third partition is /dev/sda3 of type linux Swap > >That looks great. > >= Then I get the cannot execute binary file. > >Ok I think we changed the kernal such that the old palo bits won't run >any more (we removed the old gateway page). I uploaded a new version: >ftp://puffin.external.hp.com/pub/parisc/binaries/userspace/palo-200001031.tgz > > -P From matthew@wil.cx Thu, 2 Nov 2000 00:13:06 +0000 Date: Thu, 2 Nov 2000 00:13:06 +0000 From: Matthew Wilcox matthew@wil.cx Subject: linux bame On Wed, Nov 01, 2000 at 01:53:24PM -0700, Paul Bame wrote: > CVSROOT: /home/cvs/parisc > Module name: linux > Changes by: bame 00/11/01 13:53:24 > > Modified files: > include/asm-parisc64: posix_types.h > > Log message: > Don't need a separate copy of this one either err.. are you sure? we used to get a lot of prototype problems when they were the same file. what's changed that they're now able to be the same? -- Revolutions do not require corporate support. From bame@riverrock.org Wed, 01 Nov 2000 23:18:43 -0700 Date: Wed, 01 Nov 2000 23:18:43 -0700 From: bame@riverrock.org bame@riverrock.org Subject: linux bame = On Wed, Nov 01, 2000 at 01:53:24PM -0700, Paul Bame wrote: = > CVSROOT: /home/cvs/parisc = > Module name: linux = > Changes by: bame 00/11/01 13:53:24 = > = > Modified files: = > include/asm-parisc64: posix_types.h = > = > Log message: = > Don't need a separate copy of this one either = = err.. are you sure? we used to get a lot of prototype problems when they = were the same file. what's changed that they're now able to be the same? I changed the parisc version so that the data types would compile to the same size in both wide and narrow mode. Unfortunately there is at least one issue which will probably require this scheme to change :-( -P From grundler@cup.hp.com Thu, 2 Nov 2000 00:21:36 -0800 (PST) Date: Thu, 2 Nov 2000 00:21:36 -0800 (PST) From: Grant Grundler grundler@cup.hp.com Subject: [parisc-linux] a500.out16 Hi Richard (et al), I finally think I understand how pcibios_align_resource() is used... that definitely was the problem. Everything on A500 but PCI-PCI bridge seems to be assigned I/O port and MMIO addresses correctly. I'll look at tulip code tomorrow to see why it's not happy. 6 Tulips are behind PCI-PCI Bridges and that's part of the problem. But the complaints about "MMIO resource" list I/O Port addresses instead...and those look fine to me if they are treated like I/O port addresses... I'd also like to connect some more SCSI disks....but any clue what the "CACHE TEST FAILED" is about? But instead of putting out another tar ball, I'm committing my code. I haven't tested on c3k/j5k yet and it might be broken. 32-bit still builds and any fix should be simple - either cvs update back to an older date or put "if (pdc_pat) { }" around anything that I added that shouldn't be. Tell me to test/fix any brokeness you might find and I'll make time to do it. aplogies for the long delay, grant Firmware Version 40.32 Duplex Console IO Dependent Code (IODC) revision 1 ------------------------------------------------------------------------------ (c) Copyright 1995-1998, Hewlett-Packard Company, All rights reserved ------------------------------------------------------------------------------ Processor Speed State CoProcessor State Cache Size Number State Inst Data --------- -------- --------------------- ----------------- ------------ 0 440 MHz Active Functional 512 KB 1 MB 1 440 MHz Idle Functional 512 KB 1 MB Central Bus Speed (in MHz) : 111 Available Memory : 262144 KB Good Memory Required : 11468 KB Primary boot path: 0/0/1/1.15 Alternate boot path: 0/0/2/1.15 Console path: 0/0/4/0.0 Keyboard path: 0/0/4/0.0 WARNING: The non-destructive test bit was set, so memory was not tested destructively. Information only, no action required. ---- Main Menu --------------------------------------------------------------- Command Description ------- ----------- BOot [PRI|ALT|] Boot from specified path PAth [PRI|ALT] [] Display or modify a path SEArch [DIsplay|IPL] [] Search for boot devices COnfiguration menu Displays or sets boot values INformation menu Displays hardware information SERvice menu Displays service commands DIsplay Redisplay the current menu HElp [|] Display help for menu or command RESET Restart the system ---- Main Menu: Enter command or menu > bo lan Interact with IPL (Y, N, or Cancel)?> n Booting... Network Station Address 00306e-03799f System IP Address 15.8.80.78 Server IP Address 15.8.81.247 Boot IO Dependent Code (IODC) revision 2 HARD Booted. palo ipl grundler@hpisp747 Tue Oct 31 16:45:27 PST 2000 0/vmlinux 2708507 bytes @ 0x6800 0/palo-cmdline '0/vmlinux HOME=/ TERM=linux root=/dev/nfs nfsroot=15.8.81.247:/tftpboot/hppa64 ' Kernel: partition 0 file /vmlinux ELF64 executable Entry 00100000 first 00100000 n 4 Segment 0 load 00100000 size 1705408 mediaptr 0x1000 Segment 1 load 002a2000 size 407616 mediaptr 0x1a2000 Segment 2 load 00308000 size 131960 mediaptr 0x206000 Segment 3 load 0032c000 size 16384 mediaptr 0x227000 branching to kernel entry point 0x00100000 Set default PSW W bit to 1 PDC Console Initialized The 64-bit Kernel has started... Enabled FP coprocessor If this is the LAST MESSAGE YOU SEE, you're probably using 32-bit millicode by mistake. Free memory starts at: 0xc0371000 start_parisc(0x504d40,0x504d40,0x0,0x0) PALO command line: 'HOME=/ TERM=linux root=/dev/nfs nfsroot=15.8.81.247:/tftpboot/hppa64 ' PALO initrd 0-0 model 00005cb0 00000491 00000000 00000001 23355fdc 100000f0 00000008 000000b2 000000b2 vers 00000300 cpuid 0000022a CPUID vers 17 rev 10 Searching for devices in PDC firmware... processor hpa 0xfffffffffffa0000 CELL_GET_NUMBER: 0x0 0x1 PAT_ENTITY_PROC: id_eid 0xa0ff0000 PAT_ENTITY_PROC: id_eid 0xa2ff0000 PAT_ENTITY_MEM: amount 0x10000000 min_gni_base 0x0 min_gni_len 0x0 PAT_ENTITY_SBA: ranges 6 0: 0xc000000000000005 0xfffffffffed18000 0xfffffffffed2ffff 1: 0x8000000000000000 0x0000000000000000 0x000000000000003f 2: 0x8000000000000001 0xfffffffff8000000 0xfffffffffbffffff 3: 0x00040000001a1701 0xfffffffff0000000 0xfffffffff7ffffff 4: 0x00040000001a1701 0xfffffffffc000000 0xfffffffffecfffff 5: 0x8000000000000002 0xfffffff800000000 0xfffffffbffffffff PAT_ENTITY_LBA: ranges 4 0: 0x8000000000000000 0x0000000000000000 0x0000000000000007 1: 0x8000000000000001 0xfffffffff8000000 0xfffffffff87fffff 2: 0x8000000000000002 0xfffffff804000000 0xfffffff87fffffff 3: 0x8000000000000004 0xfffffff800000000 0xfffffff803ffffff PAT_ENTITY_LBA: ranges 4 0: 0x8000000000000000 0x0000000000000010 0x0000000000000017 1: 0x8000000000000001 0xfffffffff9000000 0xfffffffff97fffff 2: 0x8000000000000002 0xfffffff904000000 0xfffffff97fffffff 3: 0x8000000000000004 0xfffffff900000000 0xfffffff903ffffff PAT_ENTITY_LBA: ranges 4 0: 0x8000000000000000 0x0000000000000020 0x0000000000000027 1: 0x8000000000000001 0xfffffffffa000000 0xfffffffffa7fffff 2: 0x8000000000000002 0xfffffffa04000000 0xfffffffa7fffffff 3: 0x8000000000000004 0xfffffffa00000000 0xfffffffa03ffffff PAT_ENTITY_LBA: ranges 4 0: 0x8000000000000000 0x0000000000000030 0x0000000000000037 1: 0x8000000000000001 0xfffffffffb000000 0xfffffffffb7fffff 2: 0x8000000000000002 0xfffffffb04000000 0xfffffffb7fffffff 3: 0x8000000000000004 0xfffffffb00000000 0xfffffffb03ffffff Found devices: 1. Crescendo 440 (0) at 0xfffffffffffa0000, versions 0x5cb, 0x0, 0x4, 0x0, 0x91 2. Crescendo 440 (0) at 0xfffffffffffa2000, versions 0x5cb, 0x0, 0x4, 0x0, 0x91 3. Crescendo Memory (1) at 0xfffffffffed08000, versions 0x9b, 0x0, 0x9, 0x0, 0x0 4. Astro BC Runway Port (12) at 0xfffffffffed00000, versions 0x582, 0x0, 0xb, 0x0, 0x10 5. Elroy PCI Bridge (13) at 0xfffffffffed30000, versions 0x782, 0x0, 0xa, 0x0, 0x0 6. Elroy PCI Bridge (13) at 0xfffffffffed34000, versions 0x782, 0x0, 0xa, 0x0, 0x0 7. Elroy PCI Bridge (13) at 0xfffffffffed38000, versions 0x782, 0x0, 0xa, 0x0, 0x0 8. Elroy PCI Bridge (13) at 0xfffffffffed3c000, versions 0x782, 0x0, 0xa, 0x0, 0x0 That's a total of 8 devices. CONFIG_SMP disabled - not claiming addional CPUs Warning : device (0, 0x5cb, 0x0, 0x4, 0x0) NOT claimed by CPU PARISC CPU(s): 1 x PA8500 (PCX-W) at 440.000000 MHz Linux version 2.4.0-test6 (grundler@hpisp747) (gcc version 2.96 20000925 (experimental)) #73 Wed Nov 1 23:58:51 PST 2000 free_bootmem(0x373000, 0xfc8d000) initrd: 00000000-00000000 pagetable_init On node 0 totalpages: 65536 zone(0): 32768 pages. zone(1): 32768 pages. zone(2): 0 pages. Kernel command line: HOME=/ TERM=linux root=/dev/nfs nfsroot=15.8.81.247:/tftpboot/hppa64 trap_init Calibrating delay loop... 878.18 BogoMIPS kernel BUG at page_alloc.c:106! Memory: 248868k available Dentry-cache hash table entries: 32768 (order: 7, 524288 bytes) Buffer-cache hash table entries: 16384 (order: 5, 131072 bytes) Page-cache hash table entries: 65536 (order: 7, 524288 bytes) Inode-cache hash table entries: 16384 (order: 6, 262144 bytes) POSIX conformance testing by UNIFIX lba version TR4.0 (0x5) found at 0xfffffffffed30000 0: 0x8000000000000000 PA 0x0000000000000000,0x0000000000000007 IO 0x0000000000000000,0x0000000000000007 1: 0x8000000000000001 PA 0xfffffffff8000000,0xfffffffff87fffff IO 0x00000000f8000000,0x00000000f87fffff 2: 0x8000000000000002 PA 0xfffffff804000000,0xfffffff87fffffff IO 0x000000f804000000,0x000000f87fffffff lba range[2] : ignoring GMMIO (0xfffffff804000000) 3: 0x8000000000000004 PA 0xfffffff800000000,0xfffffff803ffffff IO 0x000000f800000000,0x000000f803ffffff lba_fixup_bus(0x00000000cffe60c0) bus 0 sysdata 0x00000000cffe9e80 cons 0x00002000 boot 0x00000000 kbd 0x00002000 claimed 00:00 0 [0,7f]/101 claimed 00:00 1 [fffffffff8020000,fffffffff80203ff]/200 claimed 00:20 0 [fffffffff8000000,fffffffff8000fff]/200 LBA PIOP resource tree 00000000cffe9ed0 [0,7ffff]/100 00000000cffe5080 [0,7f]/101 LBA pcibios_size_bridges() LBA pci_assign_unassigned_resources() pcibios_update_resource(00:08, ..., 0) [100,1ff]/101 pcibios_update_resource(00:08, ..., 1) [fffffffff8001000,fffffffff80013ff]/204 PCI: dev PCI device 1000:000b type 64-bit pcibios_update_resource(00:08, ..., 3) [fffffffff8002000,fffffffff8003fff]/204 PCI: dev PCI device 1000:000b type 64-bit pcibios_update_resource(00:09, ..., 0) [200,2ff]/101 pcibios_update_resource(00:09, ..., 1) [fffffffff8001400,fffffffff80017ff]/204 PCI: dev PCI device 1000:000b type 64-bit pcibios_update_resource(00:09, ..., 3) [fffffffff8004000,fffffffff8005fff]/204 PCI: dev PCI device 1000:000b type 64-bit pcibios_update_resource(00:10, ..., 0) [300,3ff]/101 pcibios_update_resource(00:10, ..., 1) [fffffffff8001800,fffffffff80018ff]/200 pcibios_update_resource(00:10, ..., 2) [fffffffff8006000,fffffffff8006fff]/200 pcibios_update_resource(00:11, ..., 0) [400,4ff]/101 pcibios_update_resource(00:11, ..., 1) [fffffffff8001900,fffffffff80019ff]/200 pcibios_update_resource(00:11, ..., 2) [fffffffff8007000,fffffffff8007fff]/200 pcibios_update_resource(00:20, ..., 1) [80,bf]/101 pcibios_update_resource(00:28, ..., 0) [fffffffff8008000,fffffffff8008fff]/200 pcibios_update_resource(00:28, ..., 1) [c0,ff]/101 LBA pci_set_bus_ranges() pcibios_fixup_pbus_ranges(0, [0,1000 fffffffff8000000,fffffffff8100000]) lba version TR4.0 (0x5) found at 0xfffffffffed34000 0: 0x8000000000000000 PA 0x0000000000000010,0x0000000000000017 IO 0x0000000000000010,0x0000000000000017 1: 0x8000000000000001 PA 0xfffffffff9000000,0xfffffffff97fffff IO 0x00000000f9000000,0x00000000f97fffff 2: 0x8000000000000002 PA 0xfffffff904000000,0xfffffff97fffffff IO 0x000000f904000000,0x000000f97fffffff lba range[2] : ignoring GMMIO (0xfffffff904000000) 3: 0x8000000000000004 PA 0xfffffff900000000,0xfffffff903ffffff IO 0x000000f900000000,0x000000f903ffffff lba_fixup_bus(0x00000000cffe62c0) bus 16 sysdata 0x00000000cffe61c0 cons 0x00002000 boot 0x00000000 kbd 0x00002000 LBA PIOP resource tree 00000000cffe6210 [100000,17ffff]/100 LBA pcibios_size_bridges() LBA pci_assign_unassigned_resources() pcibios_update_resource(10:00, ..., 1) [100000,1000ff]/101 pcibios_update_resource(10:00, ..., 2) [100100,1001ff]/101 pcibios_update_resource(10:00, ..., 3) [fffffffff9000000,fffffffff90001ff]/200 pcibios_update_resource(10:00, ..., 5) [fffffffff9020000,fffffffff903ffff]/200 LBA pci_set_bus_ranges() pcibios_fixup_pbus_ranges(0, [0,1000 fffffffff8000000,fffffffff8100000]) pcibios_fixup_pbus_ranges(16, [100000,101000 fffffffff9000000,fffffffff9100000]) lba version TR4.0 (0x5) found at 0xfffffffffed38000 0: 0x8000000000000000 PA 0x0000000000000020,0x0000000000000027 IO 0x0000000000000020,0x0000000000000027 1: 0x8000000000000001 PA 0xfffffffffa000000,0xfffffffffa7fffff IO 0x00000000fa000000,0x00000000fa7fffff 2: 0x8000000000000002 PA 0xfffffffa04000000,0xfffffffa7fffffff IO 0x000000fa04000000,0x000000fa7fffffff lba range[2] : ignoring GMMIO (0xfffffffa04000000) 3: 0x8000000000000004 PA 0xfffffffa00000000,0xfffffffa03ffffff IO 0x000000fa00000000,0x000000fa03ffffff lba_fixup_bus(0x00000000cffe64c0) bus 32 sysdata 0x00000000cffe63c0 cons 0x00002000 boot 0x00000000 kbd 0x00002000 LBA PIOP resource tree 00000000cffe6410 [200000,27ffff]/100 LBA pcibios_size_bridges() LBA pci_assign_unassigned_resources() pcibios_update_resource(20:00, ..., 0) [200000,2000ff]/101 pcibios_update_resource(20:00, ..., 1) [fffffffffa000000,fffffffffa0003ff]/204 PCI: dev PCI device 1000:000b type 64-bit pcibios_update_resource(20:00, ..., 3) [fffffffffa002000,fffffffffa003fff]/204 PCI: dev PCI device 1000:000b type 64-bit pcibios_update_resource(20:01, ..., 0) [200100,2001ff]/101 pcibios_update_resource(20:01, ..., 1) [fffffffffa000400,fffffffffa0007ff]/204 PCI: dev PCI device 1000:000b type 64-bit pcibios_update_resource(20:01, ..., 3) [fffffffffa004000,fffffffffa005fff]/204 PCI: dev PCI device 1000:000b type 64-bit LBA pci_set_bus_ranges() pcibios_fixup_pbus_ranges(0, [0,1000 fffffffff8000000,fffffffff8100000]) pcibios_fixup_pbus_ranges(16, [100000,101000 fffffffff9000000,fffffffff9100000]) pcibios_fixup_pbus_ranges(32, [200000,201000 fffffffffa000000,fffffffffa100000]) lba version TR4.0 (0x5) found at 0xfffffffffed3c000 0: 0x8000000000000000 PA 0x0000000000000030,0x0000000000000037 IO 0x0000000000000030,0x0000000000000037 1: 0x8000000000000001 PA 0xfffffffffb000000,0xfffffffffb7fffff IO 0x00000000fb000000,0x00000000fb7fffff 2: 0x8000000000000002 PA 0xfffffffb04000000,0xfffffffb7fffffff IO 0x000000fb04000000,0x000000fb7fffffff lba range[2] : ignoring GMMIO (0xfffffffb04000000) 3: 0x8000000000000004 PA 0xfffffffb00000000,0xfffffffb03ffffff IO 0x000000fb00000000,0x000000fb03ffffff lba_fixup_bus(0x00000000cffe66c0) bus 48 sysdata 0x00000000cffe65c0 cons 0x00002000 boot 0x00000000 kbd 0x00002000 lba_fixup_bus(0x00000000cffe67c0) bus 49 sysdata 0x00000000cffe65c0 cons 0x00002000 boot 0x00000000 kbd 0x00002000 lba_fixup_bus(0x00000000cffe68c0) bus 50 sysdata 0x00000000cffe65c0 cons 0x00002000 boot 0x00000000 kbd 0x00002000 LBA PIOP resource tree 00000000cffe6610 [300000,37ffff]/100 LBA pcibios_size_bridges() LBA pci_assign_unassigned_resources() PCI: Failed to allocate resource 0 for PCI device 1000:000b PCI: Failed to allocate resource 1 for PCI device 1000:000b PCI: Failed to allocate resource 3 for PCI device 1000:000b PCI: Failed to allocate resource 0 for PCI device 1000:000b PCI: Failed to allocate resource 1 for PCI device 1000:000b PCI: Failed to allocate resource 3 for PCI device 1000:000b PCI: Failed to allocate resource 0 for PCI device 1011:0019 PCI: Failed to allocate resource 1 for PCI device 1011:0019 PCI: Failed to allocate resource 0 for PCI device 1011:0019 PCI: Failed to allocate resource 1 for PCI device 1011:0019 PCI: Failed to allocate resource 0 for PCI device 1011:0009 PCI: Failed to allocate resource 1 for PCI device 1011:0009 PCI: Failed to allocate resource 0 for PCI device 1011:0009 PCI: Failed to allocate resource 1 for PCI device 1011:0009 PCI: Failed to allocate resource 0 for PCI device 1011:0009 PCI: Failed to allocate resource 1 for PCI device 1011:0009 PCI: Failed to allocate resource 0 for PCI device 1011:0009 PCI: Failed to allocate resource 1 for PCI device 1011:0009 LBA pci_set_bus_ranges() pcibios_fixup_pbus_ranges(0, [0,1000 fffffffff8000000,fffffffff8100000]) pcibios_fixup_pbus_ranges(16, [100000,101000 fffffffff9000000,fffffffff9100000]) pcibios_fixup_pbus_ranges(32, [200000,201000 fffffffffa000000,fffffffffa100000]) pcibios_fixup_pbus_ranges(49, [310000,311000 fffffffffb000000,fffffffffb100000]) pcibios_fixup_pbus_ranges(50, [320000,321000 fffffffffb000000,fffffffffb100000]) pcibios_fixup_pbus_ranges(48, [0,1000 fb000000,fb100000]) SBA found Astro 2.1 at 0xfffffffffed00000 lba_init_iregs() ibase 0x1 imask 0xf0000000 lba_init_iregs() base_addr fffffffffed3c000 lba_init_iregs() base_addr fffffffffed38000 lba_init_iregs() base_addr fffffffffed34000 lba_init_iregs() base_addr fffffffffed30000 lba_init_iregs() done lba: lba_bios_init Linux NET4.0 for Linux 2.4 Based upon Swansea University Computer Society NET3.039 NET4: Linux TCP/IP 1.0 for NET4.0 IP Protocols: ICMP, UDP, TCP IP: routing cache hash table of 1024 buckets, 16Kbytes TCP: Hash tables configured (established 8192 bind 8192) Starting kswapd v1.7 pty: 256 Unix98 ptys configured lp: driver loaded but no devices found RAMDISK driver initialized: 16 RAM disks of 4096K size 1024 blocksize sym53c8xx: at PCI bus 0, device 2, function 0 sym53c8xx: setting PCI_COMMAND_PARITY...(fix-up) sym53c8xx: changing PCI_LATENCY_TIMER from 0 to 80. kernel BUG at sym53c8xx.c:725! sym53c8xx: 53c876 detected sym53c8xx: at PCI bus 0, device 2, function 1 sym53c8xx: setting PCI_COMMAND_PARITY...(fix-up) sym53c8xx: changing PCI_LATENCY_TIMER from 0 to 80. kernel BUG at sym53c8xx.c:725! sym53c8xx: 53c876 detected sym53c8xx: at PCI bus 0, device 1, function 0 sym53c8xx: setting PCI_COMMAND_PARITY...(fix-up) sym53c8xx: changing PCI_LATENCY_TIMER from 0 to 80. kernel BUG at sym53c8xx.c:725! sym53c8xx: 53c896 detected sym53c8xx: at PCI bus 0, device 1, function 1 sym53c8xx: setting PCI_COMMAND_PARITY...(fix-up) sym53c8xx: changing PCI_LATENCY_TIMER from 0 to 80. kernel BUG at sym53c8xx.c:725! sym53c8xx: 53c896 detected sym53c8xx: at PCI bus 32, device 0, function 0 sym53c8xx: setting PCI_COMMAND_PARITY...(fix-up) sym53c8xx: changing PCI_LATENCY_TIMER from 0 to 80. kernel BUG at sym53c8xx.c:725! sym53c8xx: 53c896 detected sym53c8xx: at PCI bus 32, device 0, function 1 sym53c8xx: setting PCI_COMMAND_PARITY...(fix-up) sym53c8xx: changing PCI_LATENCY_TIMER from 0 to 80. kernel BUG at sym53c8xx.c:725! sym53c8xx: 53c896 detected sym53c8xx: at PCI bus 49, device 4, function 0 sym53c8xx: setting PCI_COMMAND_PARITY...(fix-up) sym53c8xx: changing PCI_LATENCY_TIMER from 0 to 80. kernel BUG at sym53c8xx.c:725! sym53c8xx: 53c896 detected sym53c8xx: at PCI bus 49, device 4, function 1 sym53c8xx: setting PCI_COMMAND_PARITY...(fix-up) sym53c8xx: changing PCI_LATENCY_TIMER from 0 to 80. kernel BUG at sym53c8xx.c:725! sym53c8xx: 53c896 detected kernel BUG at sym53c8xx.c:725! sym53c876-0: rev 0x14 on pci bus 0 device 2 function 0 irq 130 sym53c876-0: NCR clock is 40218KHz sym53c876-0: ID 7, Fast-20, Parity Checking sym53c876-0: on-chip RAM at 0xfffffffff8006000 sym53c876-0: restart (scsi reset). sym53c876-0: Downloading SCSI SCRIPTS. kernel BUG at sym53c8xx.c:725! sym53c876-1: rev 0x14 on pci bus 0 device 2 function 1 irq 131 sym53c876-1: NCR clock is 40218KHz sym53c876-1: ID 7, Fast-20, Parity Checking sym53c876-1: on-chip RAM at 0xfffffffff8007000 sym53c876-1: restart (scsi reset). sym53c876-1: Downloading SCSI SCRIPTS. kernel BUG at sym53c8xx.c:725! sym53c896-2: rev 0x7 on pci bus 0 device 1 function 0 irq 129 sym53c896-2: NCR clock is 40218KHz sym53c896-2: ID 7, Fast-40, Parity Checking sym53c896-2: on-chip RAM at 0xfffffffff8002000 sym53c896-2: restart (scsi reset). sym53c896-2: handling phase mismatch from SCRIPTS. sym53c896-2: Downloading SCSI SCRIPTS. kernel BUG at sym53c8xx.c:725! sym53c896-3: rev 0x7 on pci bus 0 device 1 function 1 irq 130 sym53c896-3: NCR clock is 40218KHz sym53c896-3: ID 7, Fast-40, Parity Checking sym53c896-3: on-chip RAM at 0xfffffffff8004000 sym53c896-3: restart (scsi reset). sym53c896-3: handling phase mismatch from SCRIPTS. sym53c896-3: Downloading SCSI SCRIPTS. kernel BUG at sym53c8xx.c:725! sym53c896-4: rev 0x1 on pci bus 32 device 0 function 0 irq 256 sym53c896-4: NCR clock is 40218KHz sym53c896-4: ID 7, Fast-40, Parity Checking sym53c896-4: on-chip RAM at 0xfffffffffa002000 sym53c896-4: restart (scsi reset). sym53c896-4: handling phase mismatch from SCRIPTS. sym53c896-4: Downloading SCSI SCRIPTS. kernel BUG at sym53c8xx.c:725! sym53c896-5: rev 0x1 on pci bus 32 device 0 function 1 irq 257 sym53c896-5: NCR clock is 40218KHz sym53c896-5: ID 7, Fast-40, Parity Checking sym53c896-5: on-chip RAM at 0xfffffffffa004000 sym53c896-5: restart (scsi reset). sym53c896-5: handling phase mismatch from SCRIPTS. sym53c896-5: Downloading SCSI SCRIPTS. kernel BUG at sym53c8xx.c:725! sym53c896-6: rev 0x5 on pci bus 49 device 4 function 0 irq 323 sym53c896-6: ID 7, Fast-40, Parity Checking sym53c896-6: on-chip RAM at 0xfffffffffb000000 CACHE TEST FAILED: reg dstat-sstat2 readback ffffffff. CACHE INCORRECTLY CONFIGURED. sym53c896-6: giving up ... kernel BUG at sym53c8xx.c:725! kernel BUG at sym53c8xx.c:725! kernel BUG at sym53c8xx.c:725! sym53c896-6: rev 0x5 on pci bus 49 device 4 function 1 irq 320 sym53c896-6: ID 7, Fast-40, Parity Checking sym53c896-6: on-chip RAM at 0xfffffffffb000000 CACHE TEST FAILED: reg dstat-sstat2 readback ffffffff. CACHE INCORRECTLY CONFIGURED. sym53c896-6: giving up ... kernel BUG at sym53c8xx.c:725! kernel BUG at sym53c8xx.c:725! scsi0 : sym53c8xx - version 1.6b scsi1 : sym53c8xx - version 1.6b scsi2 : sym53c8xx - version 1.6b scsi3 : sym53c8xx - version 1.6b scsi4 : sym53c8xx - version 1.6b scsi5 : sym53c8xx - version 1.6b scsi : 6 hosts. Vendor: SEAGATE Model: ST318404LC Rev: HP01 Type: Direct-Access ANSI SCSI revision: 03 Detected scsi disk sda at scsi3, channel 0, id 15, lun 0 sym53c896-3-<15,0>: tagged command queue depth set to 8 scsi : detected 1 SCSI disk total. sym53c896-3-<15,0>: wide msgout: 1-2-3-1. sym53c896-3-<15,0>: wide msgin: 1-2-3-1. sym53c896-3-<15,0>: wide: wide=1 chg=0. sym53c896-3-<15,0>: wide msgout: 1-2-3-1. sym53c896-3-<15,0>: wide msgin: 1-2-3-1. sym53c896-3-<15,0>: wide: wide=1 chg=0. sym53c896-3-<15,0>: sync msgout: 1-3-1-c-1f. sym53c896-3-<15,0>: sync msg in: 1-3-1-c-1f. sym53c896-3-<15,0>: sync: per=12 scntl3=0xb0 scntl4=0x0 ofs=31 fak=0 chg=0. sym53c896-3-<15,*>: FAST-20 WIDE SCSI 40.0 MB/s (50 ns, offset 31) SCSI device sda: hdwr sector= 512 bytes. Sectors= 35566480 [17366 MB] [17.4 GB] Partition check: sda: unknown partition table Serial driver version 5.01 (2000-05-29) with MANY_PORTS SHARE_IRQ SERIAL_PCI enabled Linux Tulip driver version 0.9.8 (July 13, 2000) tulip: MMIO resource (0x80@0x0) unavailable, aborting tulip: MMIO resource (0x80@0x310200) unavailable, aborting tulip: MMIO resource (0x80@0x310280) unavailable, aborting tulip: MMIO resource (0x80@0x320300) unavailable, aborting tulip: MMIO resource (0x80@0x320380) unavailable, aborting tulip: MMIO resource (0x80@0x320400) unavailable, aborting tulip: MMIO resource (0x80@0x320480) unavailable, aborting IP-Config: No network devices available. Switching from PDC console From alan@linuxcare.com.au Thu, 2 Nov 2000 19:51:19 +1100 (EST) Date: Thu, 2 Nov 2000 19:51:19 +1100 (EST) From: Alan Modra alan@linuxcare.com.au Subject: [parisc-linux] new method for 64-bit parisc tree On Wed, 1 Nov 2000, Paul Bame wrote: > The future parisc64 tree ONLY contains files which are different from, > or in addition to, those in the parisc tree. When you 'make config' > or 'make oldconfig', each file in the parsic tree is symbolically > linked as the same file in the parisc64 tree. This enables all > the rest of the tools/build to work normally. 'make distclean' includes > a step to remove all the symlinks. Instead, can't you simply play tricks with -I, and add a symbolic link asm -> ../asm-parisc in asm-parisc64)? The idea being to end up with an include path looking like "-I $(TOPDIR)/include -I $(TOPDIR)/include/asm" That way, asm/foo.h is found by the first -I if we have asm-parisc64/foo.h, and is found by the second if asm-parisc/foo.h exists but not asm-parisc64/foo.h. Hmm, you might also need -I- -- Linuxcare. Support for the Revolution. From rhirst@linuxcare.com Thu, 2 Nov 2000 10:43:06 +0000 Date: Thu, 2 Nov 2000 10:43:06 +0000 From: Richard Hirst rhirst@linuxcare.com Subject: [parisc-linux] a500.out16 On Thu, Nov 02, 2000 at 12:21:36AM -0800, Grant Grundler wrote: > Hi Richard (et al), > I finally think I understand how pcibios_align_resource() is used... > that definitely was the problem. Everything on A500 but PCI-PCI bridge > seems to be assigned I/O port and MMIO addresses correctly. > > I'll look at tulip code tomorrow to see why it's not happy. I fixed tulip_core.c to report what it means, which gave me tulip: MMIO resource (0x400@0xfffffffff8020000) unavailable, aborting Note sym53c8xx.c doesn't seem to bother with request_mem_region(), so maybe request_mem_region() is just broken. I then patched out the goto, so it ignored that error, and.... Linux Tulip driver version 0.9.8 (July 13, 2000) tulip: MMIO resource (0x400@0xfffffffff8020000) unavailable, aborting PCI: Setting latency timer of device 00:00.0 to 64 eth0: Digital DS21143 Tulip rev 65 at 0x0, 00:30:6E:03:79:A0, IRQ 128. eth0: MII transceiver #1 config 1000 status 782d advertising 01e1. Sending BOOTP requests.... OK IP-Config: Got BOOTP answer from 10.160.240.111, my address is 10.160.240.117 Switching from PDC console Wheeee! Nice work Grant! Richard From rhirst@linuxcare.com Thu, 2 Nov 2000 10:48:33 +0000 Date: Thu, 2 Nov 2000 10:48:33 +0000 From: Richard Hirst rhirst@linuxcare.com Subject: [parisc-linux] a500.out16 On Thu, Nov 02, 2000 at 12:21:36AM -0800, Grant Grundler wrote: > I'd also like to connect some more SCSI disks....but any clue > what the "CACHE TEST FAILED" is about? .... > sym53c896-6: rev 0x5 on pci bus 49 device 4 function 0 irq 323 > sym53c896-6: ID 7, Fast-40, Parity Checking > sym53c896-6: on-chip RAM at 0xfffffffffb000000 > CACHE TEST FAILED: reg dstat-sstat2 readback ffffffff. > CACHE INCORRECTLY CONFIGURED. I'd guess that the NCR registers are being cached: static int __init ncr_regtest (struct ncb* np) { register volatile u_int32 data; /* ** ncr registers may NOT be cached. ** write 0xffffffff to a read only register area, ** and try to read it back. */ data = 0xffffffff; OUTL_OFF(offsetof(struct ncr_reg, nc_dstat), data); data = INL_OFF(offsetof(struct ncr_reg, nc_dstat)); #if 1 if (data == 0xffffffff) { #else if ((data & 0xe2f0fffd) != 0x02000080) { #endif printk ("CACHE TEST FAILED: reg dstat-sstat2 readback %x.\n", (unsigned) data); return (0x10); }; return (0); } Richard From fl@fl.priv.at Thu, 02 Nov 2000 12:15:17 +0100 Date: Thu, 02 Nov 2000 12:15:17 +0100 From: Friedrich Lobenstock fl@fl.priv.at Subject: [parisc-linux] HP 3000 - 922LX ?? Hi! How about support for a HP3000-922LX? I think this should be a PA-RISC machine. PS: Please CC me, because I'm not on the list. MfG / Regards Friedrich Lobenstock From rhirst@linuxcare.com Thu, 2 Nov 2000 11:30:47 +0000 Date: Thu, 2 Nov 2000 11:30:47 +0000 From: Richard Hirst rhirst@linuxcare.com Subject: [parisc-linux] a500.out16 On Thu, Nov 02, 2000 at 10:43:06AM +0000, Richard Hirst wrote: > On Thu, Nov 02, 2000 at 12:21:36AM -0800, Grant Grundler wrote: > > Hi Richard (et al), > > I finally think I understand how pcibios_align_resource() is used... > > that definitely was the problem. Everything on A500 but PCI-PCI bridge > > seems to be assigned I/O port and MMIO addresses correctly. > > > > I'll look at tulip code tomorrow to see why it's not happy. > > I fixed tulip_core.c to report what it means, which gave me > > tulip: MMIO resource (0x400@0xfffffffff8020000) unavailable, aborting > > Note sym53c8xx.c doesn't seem to bother with request_mem_region(), so > maybe request_mem_region() is just broken. It is broken because of the following line in kernel/resource.c: struct resource iomem_resource = { "PCI mem", 0x00000000, 0xffffffff, IORESOURCE_MEM }; 'end' needs to be rather higher than 0xffffffff on 64 bit. I changed it to struct resource iomem_resource = { "PCI mem", 0x00000000, ~0, IORESOURCE_MEM }; and it works. I havn't committed that 'fix' though. Richard From matthew@wil.cx Thu, 2 Nov 2000 11:57:53 +0000 Date: Thu, 2 Nov 2000 11:57:53 +0000 From: Matthew Wilcox matthew@wil.cx Subject: [parisc-linux] HP 3000 - 922LX ?? On Thu, Nov 02, 2000 at 12:15:17PM +0100, Friedrich Lobenstock wrote: > Hi! > > How about support for a HP3000-922LX? I think this should be a PA-RISC > machine. According to the docs: http://www.thepuffingroup.com/parisc/hp9000_models.html the 922 is the same physical machine as the 822. As such, it's too old for it to be worth supporting. the official statement is... The earliest PA-RISC servers have proprietary HP devices attached to proprietary HP bus architectures. It is unlikely that documentation on these busses and devices will ever become available, since so few people are interested in spending any effort finding and releasing the docs. Machines in this category are the E, F, G, H, I class (aka Nova) and T500 series (Emerald) machines as well as some earlier, unlettered servers. I should perhaps update this to reflect the particular model numbers. -- Revolutions do not require corporate support. From rhirst@linuxcare.com Thu, 2 Nov 2000 12:07:36 +0000 Date: Thu, 2 Nov 2000 12:07:36 +0000 From: Richard Hirst rhirst@linuxcare.com Subject: [parisc-linux] a500.out16 On Thu, Nov 02, 2000 at 10:43:06AM +0000, Richard Hirst wrote: > Linux Tulip driver version 0.9.8 (July 13, 2000) > tulip: MMIO resource (0x400@0xfffffffff8020000) unavailable, aborting > PCI: Setting latency timer of device 00:00.0 to 64 > eth0: Digital DS21143 Tulip rev 65 at 0x0, 00:30:6E:03:79:A0, IRQ 128. > eth0: MII transceiver #1 config 1000 status 782d advertising 01e1. > Sending BOOTP requests.... OK > IP-Config: Got BOOTP answer from 10.160.240.111, my address is 10.160.240.117 > Switching from PDC console > > Wheeee! Nice work Grant! And if you stop it from trying to switch from pdc to ttyS0 console: Linux Tulip driver version 0.9.8 (July 13, 2000) PCI: Setting latency timer of device 00:00.0 to 64 eth0: Digital DS21143 Tulip rev 65 at 0x0, 00:30:6E:03:79:A0, IRQ 128. eth0: MII transceiver #1 config 1000 status 782d advertising 01e1. Sending BOOTP requests.... OK IP-Config: Got BOOTP answer from 10.160.240.111, my address is 10.160.240.117 kmem_create: Forcing size word alignment - nfs_fh Looking up port of RPC 100003/2 on 10.160.240.111 Looking up port of RPC 100005/2 on 10.160.240.111 VFS: Mounted root (nfs filesystem) readonly. Warning: unable to open an initial console. Kernel panic: Attempted to kill init! Richard From matthew@wil.cx Thu, 2 Nov 2000 12:01:58 +0000 Date: Thu, 2 Nov 2000 12:01:58 +0000 From: Matthew Wilcox matthew@wil.cx Subject: [parisc-linux] a500.out16 On Thu, Nov 02, 2000 at 11:30:47AM +0000, Richard Hirst wrote: > > Note sym53c8xx.c doesn't seem to bother with request_mem_region(), so > > maybe request_mem_region() is just broken. > > It is broken because of the following line in kernel/resource.c: > > struct resource iomem_resource = { "PCI mem", 0x00000000, 0xffffffff, IORESOURCE_MEM }; > > 'end' needs to be rather higher than 0xffffffff on 64 bit. I changed it to > > struct resource iomem_resource = { "PCI mem", 0x00000000, ~0, IORESOURCE_MEM }; > > and it works. I havn't committed that 'fix' though. Probably just as well... the pci_consistent interfaces were designed partly to stop 32-bit PCI cards having to do dual-address-cycle on machines with an IOMMU. if you can, this card should get mapped below the 32-bit boundary. -- Revolutions do not require corporate support. From grundler@cup.hp.com Thu, 02 Nov 2000 08:12:47 -0800 Date: Thu, 02 Nov 2000 08:12:47 -0800 From: Grant Grundler grundler@cup.hp.com Subject: [parisc-linux] a500.out16 This is why I do NOT like our current scheme of using host physical addresses to access I/O space. Richard Hirst wrote: ... > I'd guess that the NCR registers are being cached: > > > static int __init ncr_regtest (struct ncb* np) > { > register volatile u_int32 data; > /* > ** ncr registers may NOT be cached. > ** write 0xffffffff to a read only register area, > ** and try to read it back. > */ > data = 0xffffffff; > OUTL_OFF(offsetof(struct ncr_reg, nc_dstat), data); > data = INL_OFF(offsetof(struct ncr_reg, nc_dstat)); If INL_OFF and OUTL_OFF are broken, they will very likely point to something in memory - page zero. And happily scribble over it gsc_write(xxx). We don't cache I/O space. Never. Something is definitely broken on this code path. I'll look at this once I find out what I broke on the j5k/c3k boot path in lba_pci.c. jsm already restored the previous version of lba_pci.c so folks can still boot 32-bit on c3k/j5k. grant Grant Grundler Unix Systems Enablement Lab +1.408.447.7253 From bame@riverrock.org Thu, 02 Nov 2000 09:20:24 -0700 Date: Thu, 02 Nov 2000 09:20:24 -0700 From: bame@riverrock.org bame@riverrock.org Subject: [parisc-linux] new method for 64-bit parisc tree I want to hear concerns because without serious ones I'm going to make this change next week... = Instead, can't you simply play tricks with -I, and add a symbolic link = asm -> ../asm-parisc in asm-parisc64)? The idea being to end up with = an include path looking like = "-I $(TOPDIR)/include -I $(TOPDIR)/include/asm" = = That way, asm/foo.h is found by the first -I if we have asm-parisc64/foo.h, = and is found by the second if asm-parisc/foo.h exists but not = asm-parisc64/foo.h. Hmm, you might also need -I- That would function fine for header files, but not for source files where something like VPATH might work, but is not available to us. It's worth noting that both -I and VPATH tricks mean if you have an error in or need to change a file, you may have to examine two directories to figure out where it really lives. The symbolic link scheme solves some of that problem. -P From dkennedy@linuxcare.com Thu, 2 Nov 2000 12:30:32 -0800 (PST) Date: Thu, 2 Nov 2000 12:30:32 -0800 (PST) From: dkennedy dkennedy@linuxcare.com Subject: [parisc-linux] Boot Problems with 755 On Mon, 30 Oct 2000, Matthew Wilcox wrote: > This isn't tagged correctly in the hwdb. Could someone inside linuxcare > please fix this? It should be supported by the Apricot driver. I have updated the hwdb to include the Coral II Core Lan Apricot driver. -- David Kennedy, Technical Account Manager, Linuxcare, Inc. 613.562.9594 tel, 613.562.9304 fax dkennedy@linuxcare.com, http://www.linuxcare.com/ Linuxcare. Support for the revolution. From grundler@cup.hp.com Thu, 02 Nov 2000 08:42:06 -0800 Date: Thu, 02 Nov 2000 08:42:06 -0800 From: Grant Grundler grundler@cup.hp.com Subject: [parisc-linux] a500.out16 Matthew Wilcox wrote: > On Thu, Nov 02, 2000 at 11:30:47AM +0000, Richard Hirst wrote: > > > Note sym53c8xx.c doesn't seem to bother with request_mem_region(), so > > > maybe request_mem_region() is just broken. > > > > It is broken because of the following line in kernel/resource.c: > > > > struct resource iomem_resource = { "PCI mem", 0x00000000, 0xffffffff, IORES > OURCE_MEM }; > > > > 'end' needs to be rather higher than 0xffffffff on 64 bit. I changed it to > > > > struct resource iomem_resource = { "PCI mem", 0x00000000, ~0, IORESOURCE_ME > M }; > > > > and it works. I havn't committed that 'fix' though. > > Probably just as well... the pci_consistent interfaces were designed > partly to stop 32-bit PCI cards having to do dual-address-cycle on > machines with an IOMMU. if you can, this card should get mapped below > the 32-bit boundary. Mathew, That's not the whole story. The value (0xfffffffff8020000) seen by the PCI driver *is* a 32-bit PCI address - dual address cycles are not needed. pcibios_update_resource() mangles the address the PCI device driver uses to fit the BAR it's supposed to get written to. See arch/parisc/kernel/pci.c and I think you'll understand. I think you are confusing DMA with PIO (register accesses). The address above is only used to PIO to access registers and has nothing to do with DMA (or I/O MMUs). And PCI device's that can do dual address cycle *should* in order to *avoid* the I/O MMU. The I/O MMU introduces a latency in the DMA path which ideally would be avoided. Of course, there are lots of issues with making that actually work...but it can work. I haven't looked at the whole issue of 64-bit BAR's yet. Mostly because I haven't had to. 64-bit BAR's work just fine when the upper 32-bits are zero'd. :^) But also because the 896 chip (older rev's at least) has 64-bit BARs and it didn't work during N-class bringup in Feb 1999. Currently shipping revs may work. A hack needs to go into pci_quirks.c to support 896 64-bit BARs. thanks for the ideas though, grant Grant Grundler Unix Systems Enablement Lab +1.408.447.7253 From headcrusher@web.de Thu, 2 Nov 2000 19:58:51 +0100 Date: Thu, 2 Nov 2000 19:58:51 +0100 From: =?iso-8859-1?Q? Alexander=20Sch=F6ck ?= headcrusher@web.de Subject: [parisc-linux] Help!? Hallo Puffingroup-Team, I have a very important question about the installation of the linux for PARisc. I hope you can help me! OK, i have a 725/100 Unix Workstation, i tried to install the PARisc-linux on this machine. The CD is booting from this machine, but in the middle of the booting phase the system hang on following line: "request_irq(259, c01ec76c, 0x0, asp, c3rcd080)" - So, what's wrong? How can I go on with the installation? Bye, Alexander S. _______________________________________________________________________ 1.000.000 DM gewinnen - kostenlos tippen - http://millionenklick.web.de IhrName@web.de, 8MB Speicher, Verschluesselung - http://freemail.web.de From matthew@wil.cx Fri, 3 Nov 2000 00:08:06 +0000 Date: Fri, 3 Nov 2000 00:08:06 +0000 From: Matthew Wilcox matthew@wil.cx Subject: [parisc-linux] Help!? On Thu, Nov 02, 2000 at 07:58:51PM +0100, Alexander Schöck wrote: > How can I go on with the installation? question added to the FAQ: 7. I'm using the Alpha 0.1 release CD and the machine stops after printing request_irq(259, c01ec76c, 0x0, asp, c3rcd080) what's going on? This is a bug in the kernel shipped on the CD. It only affects certain machines and has been fixed in the current CVS tree. We recommend you acquire a newer kernel from the FTP site. -- Revolutions do not require corporate support. From kailasr@webcash.com Thu, 02 Nov 2000 17:29:19 -0800 Date: Thu, 02 Nov 2000 17:29:19 -0800 From: Kailashnath V Rampure kailasr@webcash.com Subject: [parisc-linux] Boot command Hi, I have run the following command to initialize the sda harddisk. The sda3 is the linux native partion. Wen I say boot on the HP server it is trying to boot from /stand/vmunix instead of vmlinux can any one help me about the command. Secondaly I want to knwo what is the term type as its not taking vt100 so I am unable to open vi. I have made nesessary changes for the /etc/fstab $ palo -I -k /boot/vmlinux -b /boot/iplboot -c '3/boot/vmlinux TERM=linux HOME=/ root=/dev/sda3' /dev/sda regards Kailas From grundler@cup.hp.com Thu, 02 Nov 2000 17:44:23 -0800 Date: Thu, 02 Nov 2000 17:44:23 -0800 From: Grant Grundler grundler@cup.hp.com Subject: [parisc-linux] Boot command Kailashnath V Rampure wrote: > Hi, > I have run the following command to initialize the sda harddisk. The sda3 > is the linux native partion. > Wen I say boot on the HP server it is trying to boot from /stand/vmunix > instead of vmlinux can any one help me about the command. Sounds like your system is booting from an existing HPUX installed disk. Ie you are not using palo. > Secondaly I want > to knwo what is the term type as its not taking vt100 so I am unable to > open vi. TERM=linux is what I've seen before. The debian ncurses package might need to be installed first though and vt100 should work too. Search the mail archive at http://puffin.external.hp.com/cgi-bin/mailgrep grant > > I have made nesessary changes for the /etc/fstab > > $ palo -I -k /boot/vmlinux -b /boot/iplboot -c '3/boot/vmlinux TERM=linux > HOME=/ root=/dev/sda3' /dev/sda > > regards > Kailas > > --------------------------------------------------------------------------- > To unsubscribe: send e-mail to parisc-linux-request@thepuffingroup.com with > `unsubscribe' as the subject. > Grant Grundler Unix Systems Enablement Lab +1.408.447.7253 From taggart@carmen.fc.hp.com Thu, 02 Nov 2000 18:47:33 -0700 Date: Thu, 02 Nov 2000 18:47:33 -0700 From: Matt Taggart taggart@carmen.fc.hp.com Subject: [parisc-linux] Boot command Kailashnath V Rampure writes... > Hi, > I have run the following command to initialize the sda harddisk. The sda3 > is the linux native partion. > Wen I say boot on the HP server it is trying to boot from /stand/vmunix > instead of vmlinux can any one help me about the command. This means that you are somehow still booting an HP-UX lifimage. Did you follow the directions on, http://www.thepuffingroup.com/parisc/install.html including the partitioning stuff? Maybe you're still booting off another disk, are you sure you're booting from the linux disk? HTH, -- Matt Taggart taggart@fc.hp.com From headcrusher@web.de Fri, 3 Nov 2000 08:04:31 +0100 Date: Fri, 3 Nov 2000 08:04:31 +0100 From: =?iso-8859-1?Q? Alexander=20Sch=F6ck ?= headcrusher@web.de Subject: [parisc-linux] Help!? I downloaded a new kernel from the ftp-site, how can i use this kernel to work with my machine? This is a image file, how can i extract this file, or must i copy it only to the boot-cd? How can i use this kernel? Matthew Wilcox schrieb am 03.11.00: > On Thu, Nov 02, 2000 at 07:58:51PM +0100, Alexander Schöck wrote: > > How can I go on with the installation? > > question added to the FAQ: > > 7. I'm using the Alpha 0.1 release CD and the machine stops after printing > request_irq(259, c01ec76c, 0x0, asp, c3rcd080) > what's going on? > > This is a bug in the kernel shipped on the CD. It only affects certain > machines and has been fixed in the current CVS tree. We recommend you > acquire a newer kernel from the FTP site. > > -- > Revolutions do not require corporate support. > _______________________________________________________________________ 1.000.000 DM gewinnen - kostenlos tippen - http://millionenklick.web.de IhrName@web.de, 8MB Speicher, Verschluesselung - http://freemail.web.de From pdbeal@louisville.edu Fri, 3 Nov 2000 10:02:39 -0500 Date: Fri, 3 Nov 2000 10:02:39 -0500 From: Phillip Beal pdbeal@louisville.edu Subject: [parisc-linux] STI Console problems on 735 and 755 Hey, After all the help I obtained from this list, both through my posts and through the archives, I've finally gotten the 735 and 755, that I have access to, to boot and run linux. However, as soon as it starts to process init, the console screen becomes garbled. The system continues to boot, and I can access the machine via serial console and minicom, but the physical console on the box, just prints garbage. Is this normal for this stage of development? I couldn't see anything in the archives, that said it was, so I'm wondering how I fix this problem, if its been fixed before. Thanks, -- Phillip Beal Electrical and Computer Engineering S+LUG Vice-President From adevries@linuxcare.com Fri, 03 Nov 2000 11:37:08 -0500 Date: Fri, 03 Nov 2000 11:37:08 -0500 From: Alex deVries adevries@linuxcare.com Subject: [parisc-linux] STI Console problems on 735 and 755 Phillip Beal wrote: > After all the help I obtained from this list, both through my posts and > through the archives, I've finally gotten the 735 and 755, that I have > access to, to boot and run linux. However, as soon as it starts to > process init, the console screen becomes garbled. The system continues > to boot, and I can access the machine via serial console and minicom, > but the physical console on the box, just prints garbage. Is this > normal for this stage of development? I couldn't see anything in the > archives, that said it was, so I'm wondering how I fix this problem, if > its been fixed before. Good to hear that your 735 and 755 start to boot! What kind of graphics hardware is sitting on a 735 or 755? I think we've only ever looked at that on a 712 and 715. Can you use serial console in the meantime? - Alex -- Alex deVries, Principal Solutions Architect, The Puffins at Linuxcare 613.562.2759 tel alex@linuxcare.com, http://www.linuxcare.com/ Linuxcare, Support for the revolution. From pdbeal@louisville.edu Fri, 3 Nov 2000 10:49:00 -0500 Date: Fri, 3 Nov 2000 10:49:00 -0500 From: Phillip Beal pdbeal@louisville.edu Subject: [parisc-linux] STI Console problems on 735 and 755 > What kind of graphics hardware is sitting on a 735 or 755? I think > we've only ever looked at that on a 712 and 715. Both the 735 and the 755 have the following device, that seems be refer to the graphics: Coral SGC Graphics (10) at 0xf8000000, version 0x4, 0x0, 0x77, 0x0, 0x0 However, the 755 is known only to use mono graphics, even though they both report the same info for the Coral SGC Grpahics. I hope this helps, > Can you use serial console in the meantime? Yeah, serial works just fine. > > - Alex > > -- > Alex deVries, Principal Solutions Architect, The Puffins at Linuxcare > 613.562.2759 tel > alex@linuxcare.com, http://www.linuxcare.com/ > Linuxcare, Support for the revolution. -- Phillip Beal Electrical and Computer Engineering S+LUG Vice-President From kailasr@webcash.com Fri, 03 Nov 2000 11:03:23 -0800 Date: Fri, 03 Nov 2000 11:03:23 -0800 From: Kailashnath V Rampure kailasr@webcash.com Subject: [parisc-linux] Boot command Yes I have been following the same Doc. its tries to boot from the sda as I can see the hard disk path. I have 2 Hdd's one sda and other sdb. the path are 8/16/5.6 and other is 8/16/5.0. Here I think /dev/sda is 8/16/5.6. It is trying to boot but give sthe following o/p: Boot IO Dependent Code (IODC) revision 144 .... SUCCEEDED! HARD Booted. palo ipl bame@noam Tue Oct 31 14:18:02 MST 2000 0/vmlinux 208896 bytes @ 0x1f78c000 0/palo-cmdline '3/boot/vmlinux TERM=linux Home=/ root=/dev/sdb3' /dev/ida1 82 62 1030688 /dev/ida2 f0 1030750 24738 /dev/ida3 83 1055488 1030750 Kernel:partition 3 file /boot/vmlinux ext2 block size 1024 ext2_mount(partition 3) returns 0 ext2_open(/boot/vmlinux)=3 Couldn't gork your kernel executabel format failed to load kernel Failed to load Kernel. please suggest. At 06:47 PM 11/2/00 -0700, Matt Taggart wrote: >Kailashnath V Rampure writes... > > > Hi, > > I have run the following command to initialize the sda harddisk. The sda3 > > is the linux native partion. > > Wen I say boot on the HP server it is trying to boot from /stand/vmunix > > instead of vmlinux can any one help me about the command. > >This means that you are somehow still booting an HP-UX lifimage. Did you >follow the directions on, > >http://www.thepuffingroup.com/parisc/install.html > >including the partitioning stuff? Maybe you're still booting off another >disk, >are you sure you're booting from the linux disk? > >HTH, > >-- >Matt Taggart >taggart@fc.hp.com From grundler@cup.hp.com Fri, 03 Nov 2000 11:19:29 -0800 Date: Fri, 03 Nov 2000 11:19:29 -0800 From: Grant Grundler grundler@cup.hp.com Subject: [parisc-linux] Boot command Kailashnath V Rampure wrote: > Yes I have been following the same Doc. > its tries to boot from the sda as I can see the hard disk path. I have 2 > Hdd's one sda and other sdb. the path are 8/16/5.6 and other is 8/16/5.0. > Here I think /dev/sda is 8/16/5.6. The lower numbered SCSI ID will be /dev/sda. SCSI devices are lettered in the order they are discovered. The order is reflected in /proc/scsi/scsi. grant Grant Grundler Unix Systems Enablement Lab +1.408.447.7253 From kailasr@webcash.com Fri, 03 Nov 2000 11:46:39 -0800 Date: Fri, 03 Nov 2000 11:46:39 -0800 From: Kailashnath V Rampure kailasr@webcash.com Subject: [parisc-linux] Boot command I have removed the 2nd HDD now the boot is trying but I get the same error: my fstab reads as : # /etc/fstab: static file system information. # # #/dev/sda1 /boot ext2 defaults,errors=remount-ro 0 0 #/dev/sda2 none swap sw 0 0 /dev/sda3 / ext2 defaults,errors=remount-ro 0 0 # proc /proc proc defaults 0 0 The erros is as follows: Boot IO Dependent Code (IODC) revision 144 .... SUCCEEDED! HARD Booted. palo ipl bame@noam Tue Oct 31 14:18:02 MST 2000 0/vmlinux 208896 bytes @ 0x1f78c000 0/palo-cmdline '3/boot/vmlinux TERM=linux Home=/ root=/dev/sda3' /dev/ida1 82 62 1030688 /dev/ida2 f0 1030750 24738 /dev/ida3 83 1055488 1030750 Kernel:partition 3 file /boot/vmlinux ext2 block size 1024 ext2_mount(partition 3) returns 0 ext2_open(/boot/vmlinux)=3 Couldn't gork your kernel executabel format failed to load kernel Failed to load Kernel. Please suggest. From dave@hiauly1.hia.nrc.ca Fri, 3 Nov 2000 15:01:17 -0500 (EST) Date: Fri, 3 Nov 2000 15:01:17 -0500 (EST) From: John David Anglin dave@hiauly1.hia.nrc.ca Subject: testcase for hppa64 gcc bug > I think I know what's going on here. The root of the problem is that > pa-64.h defines an ARG_POINTER_REGNUM that isn't a fixed reg, and isn't > eliminable. The arg_pointer isn't even a call-saved reg. That breaks a > number of places in the compiler. > > So I went down the path of trying to fix things properly by defining > ELIMINABLE_REGS and so on, but I ended in a maze of twisty little passages > labelled "Unrecognizable instruction", like this one: > > /src/parisc/gcc/gcc/libgcc2.c: In function `__moddi3': > /src/parisc/gcc/gcc/libgcc2.c:601: Unrecognizable insn: > (insn 1289 209 1298 (set (reg:SI 50 %fr22) > (subreg:SI (plus:DI (reg:DI 30 %r30) > (const_int -272 [0xfffffef0])) 0)) -1 (nil) > (nil)) > /src/parisc/gcc/gcc/libgcc2.c:601: Internal compiler error in > extract_insn, at recog.c:2134 I am making progress in trying to make the arg_pointer register eliminable. I have fixed the above problem. What was happening was that reload_as_needed was incorrectly trying to eliminate the return from millicode calls which is also register r29. I have figured out how to hide it from reload with unspec. However, the compiler is now too good at eliminating the arg_pointer. At -O3, it completely eliminates the arg_pointer. However, as I read the ABI, the call must always set the arg_pointer before calls. Dave -- J. David Anglin dave.anglin@nrc.ca National Research Council of Canada (613) 990-0752 (FAX: 952-6605) From bame@noam.fc.hp.com Fri, 03 Nov 2000 13:30:16 -0700 Date: Fri, 03 Nov 2000 13:30:16 -0700 From: Paul Bame bame@noam.fc.hp.com Subject: [parisc-linux] Boot command = ext2_open(/boot/vmlinux)=3 = Couldn't gork your kernel executabel format failed to load kernel = Failed to load Kernel. That should be "grok" :-) Apparently you're not using cut/paste for these error messages. This is PALO saying that /boot/vmlinux is neither elf32, elf64, nor SOM format. I'm guessing, based on some earlier advice I gave when you were net-booting, that you may have a lifimage there by mistake -- you need a kernel instead, for example from ftp://puffin.external.hp.com/pub/parisc/binaries/kernels To tell for sure, run 'file vmlinux' on that file. If you get vmlinux: 8086 relocatable (Microsoft) that's probably a lifimage. You should get this instead: vmlinux: ELF 32-bit MSB executable, PA-RISC, version 1, statically linked, not stripped -P From kailasr@webcash.com Fri, 03 Nov 2000 14:59:29 -0800 Date: Fri, 03 Nov 2000 14:59:29 -0800 From: Kailashnath V Rampure kailasr@webcash.com Subject: [parisc-linux] Boot command Thanks! Paul. Yes I had copied the lifImage there. Now I have downloaded the kernel from the link you mentioned. I am still unable to use vi as it says "linux:unknown terminal type" Can you help me. To add features can I add deb packages. I am not that familiar with debian. Actually I want to build an apache + mod_ssl+mod_perl on A180c. Regards Kailas At 01:30 PM 11/3/00 -0700, Paul Bame wrote: >= ext2_open(/boot/vmlinux)=3 >= Couldn't gork your kernel executabel format failed to load kernel >= Failed to load Kernel. > >That should be "grok" :-) Apparently you're not using cut/paste for >these error messages. > >This is PALO saying that /boot/vmlinux is neither elf32, elf64, nor SOM >format. I'm guessing, based on some earlier advice I gave when you >were net-booting, that you may have a lifimage there by mistake -- you >need a kernel instead, for example from >ftp://puffin.external.hp.com/pub/parisc/binaries/kernels > >To tell for sure, run 'file vmlinux' on that file. If you get > vmlinux: 8086 relocatable (Microsoft) >that's probably a lifimage. You should get this instead: > vmlinux: ELF 32-bit MSB executable, PA-RISC, version 1, statically > linked, not stripped > > > -P From randolph@tausq.org Sat, 4 Nov 2000 18:02:03 -0700 Date: Sat, 4 Nov 2000 18:02:03 -0700 From: Randolph Chung randolph@tausq.org Subject: [parisc-linux] ldd segfaulting? I think this may be related to what bdale has been seeing... frodo:~# cat test.c int main(int a, char **b) { return 0; } frodo:~# gcc -o test test.c frodo:~# ./test frodo:~# ldd ./test do_page_fault() pid=144 command='ld.so.1' YZrvWESTHLNXBCVMcbcbcbcbOGFRQPDI PSW: 00000000000001001000000100001011 r0-3 00000000 2aac367c 2aaacd67 2aaaa2f0 r4-7 2aac367c 2aaab4e8 2aac3622 2aac02b8 r8-11 20020048 2aaaccb8 2aaaa2f0 00000000 r12-15 00000081 00000080 200201e8 2001fe10 r16-19 00000000 00000000 00000000 2aac367c r20-23 00000000 2aaaa000 2aaaa000 00000041 r24-27 2aaaa000 70000021 20020048 00076b50 r28-31 00000021 20020048 200202c0 2aaacd1b sr0-4 00000000 00002003 00000000 00002003 sr4-8 00002003 00002003 00002003 00002003 IASQ: 00002003 00002003 IAOQ: 2aaadc63 2aaadc67 IIR: 0ce61280 ISR: 00002003 IOR: 2aac02b8 ORIG_R28: 00086350 do_page_fault() pid=145 command='ld.so.1' YZrvWESTHLNXBCVMcbcbcbcbOGFRQPDI PSW: 00000000000001001000000100001011 r0-3 00000000 2aac367c 2aaacd67 2aaaa2f0 r4-7 2aac367c 2aaab4e8 2aac3622 2aac02b8 r8-11 20020048 2aaaccb8 2aaaa2f0 00000000 r12-15 00000081 00000080 200201e8 2001fe10 r16-19 00000000 00000000 00000000 2aac367c r20-23 00000000 2aaaa000 2aaaa000 00000041 r24-27 2aaaa000 70000021 20020048 00076b50 r28-31 00000021 20020048 200202c0 2aaacd1b sr0-4 00000000 00002003 00000000 00002003 sr4-8 00002003 00002003 00002003 00002003 IASQ: 00002003 00002003 IAOQ: 2aaadc63 2aaadc67 IIR: 0ce61280 ISR: 00002003 IOR: 2aac02b8 ORIG_R28: 00090190 ldd: /lib/ld.so.1 exited with unknown exit code (139) frodo:~# gcc --version 2.96 frodo:~# ldd --version ldd (GNU libc) 2.1.95 Copyright (C) 1999 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. Written by Roland McGrath and Ulrich Drepper. frodo:~# Any ideas what's going on? I've tried this both with a Oct26 kernel and one that is from cvs today. Same results. randolph -- @..@ http://www.TauSq.org/ (----) ( >__< ) ^^ ~~ ^^ From alan@linuxcare.com.au Sun, 5 Nov 2000 16:02:43 +1100 (EST) Date: Sun, 5 Nov 2000 16:02:43 +1100 (EST) From: Alan Modra alan@linuxcare.com.au Subject: [parisc-linux] ldd segfaulting? On Sat, 4 Nov 2000, Randolph Chung wrote: > frodo:~# ldd ./test > > do_page_fault() pid=144 command='ld.so.1' Most likely a case of new kernel, ld.so compiled with old gcc. Old is earlier than 25th Oct. Before that gcc put plabels, which need relocating, in .rodata, which is mapped read-only. The new kernel enforces the read-only mapping, so you run into problems when ld.so tries to relocate itself. Fortunately, you only need recompile glibc with a new gcc. Older binaries with plabels in .rodata are handled OK as ld.so re-maps the segments read/write, something it doesn't manage to do for itself. Alan Modra -- Linuxcare. Support for the Revolution. From bdale@gag.com Sat, 04 Nov 2000 23:16:29 -0700 Date: Sat, 04 Nov 2000 23:16:29 -0700 From: Bdale Garbee bdale@gag.com Subject: [parisc-linux] compiler bug? In the build of util-linux, compilation of fdisk/fdiskbsdlabel.c fails as shown below. I have placed "gcc -E" output on pehc in ~bdale/fdiskbsdlabel.E for reference. Hacking the makefiles to remove "-O -O2" allows the compile to complete cleanly. I assume this means something in the compiler is broken? Bdale bdale@j5k:/space/debian/util-linux-2.10o/fdisk $ cc -c -O -O2 -fomit-frame-pointer -I../lib -Wall -Wmissing-prototypes -Wstrict-prototypes -DNCH=1 -DSBINDIR=\"/sbin\" -DUSRSBINDIR=\"/usr/sbin\" -DLOGDIR=\"/var/log\" -DVARPATH=\"/var\" -DLOCALEDIR=\"/usr/share/locale\" fdiskbsdlabel.c -o fdiskbsdlabel.o /usr/include/linux/string.h:12: parse error before "__extension__" /usr/include/linux/string.h:12: parse error before '&&' token /usr/include/linux/string.h:14: parse error before "__extension__" /usr/include/linux/string.h:14: parse error before '(' token /usr/include/linux/string.h:15: parse error before "__extension__" /usr/include/linux/string.h:15: parse error before '&&' token /usr/include/linux/string.h:24: parse error before "__extension__" /usr/include/linux/string.h:27: parse error before "__extension__" /usr/include/linux/string.h:33: parse error before "__extension__" /usr/include/linux/string.h:36: parse error before "__extension__" /usr/include/linux/string.h:36: parse error before '&&' token /usr/include/linux/string.h:36: parse error before '}' token /usr/include/linux/string.h:36: conflicting declarations of `__result' /usr/include/linux/string.h:36: `__result' previously declared here /usr/include/linux/string.h:36: parse error before ')' token /usr/include/linux/string.h:36: `__s2' undeclared here (not in a function) /usr/include/linux/string.h:36: parse error before ';' token /usr/include/linux/string.h:36: conflicting declarations of `__result' /usr/include/linux/string.h:36: `__result' previously defined here /usr/include/linux/string.h:36: parse error before '}' token /usr/include/linux/string.h:36: parse error before '}' token /usr/include/linux/string.h:36: redefinition of `__result' /usr/include/linux/string.h:36: `__result' previously defined here /usr/include/linux/string.h:36: `__s1' undeclared here (not in a function) /usr/include/linux/string.h:36: parse error before ')' token /usr/include/linux/string.h:36: parse error before ';' token /usr/include/linux/string.h:36: conflicting declarations of `__result' /usr/include/linux/string.h:36: `__result' previously defined here /usr/include/linux/string.h:36: parse error before '}' token /usr/include/linux/string.h:39: parse error before "__extension__" /usr/include/linux/string.h:39: parse error before '&&' token /usr/include/linux/string.h:39: parse error before '}' token /usr/include/linux/string.h:39: redefinition of `__result' /usr/include/linux/string.h:36: `__result' previously defined here /usr/include/linux/string.h:39: parse error before ')' token /usr/include/linux/string.h:39: `__s2' undeclared here (not in a function) /usr/include/linux/string.h:39: parse error before ';' token /usr/include/linux/string.h:39: conflicting declarations of `__result' /usr/include/linux/string.h:39: `__result' previously defined here /usr/include/linux/string.h:39: parse error before '}' token /usr/include/linux/string.h:39: parse error before '}' token /usr/include/linux/string.h:39: redefinition of `__result' /usr/include/linux/string.h:39: `__result' previously defined here /usr/include/linux/string.h:39: `__s1' undeclared here (not in a function) /usr/include/linux/string.h:39: parse error before ')' token /usr/include/linux/string.h:39: parse error before ';' token /usr/include/linux/string.h:39: conflicting declarations of `__result' /usr/include/linux/string.h:39: `__result' previously defined here /usr/include/linux/string.h:39: parse error before '}' token /usr/include/linux/string.h:45: parse error before "__extension__" /usr/include/linux/string.h:51: parse error before "__extension__" /usr/include/linux/string.h:61: parse error before "__extension__" /usr/include/linux/string.h:61: parse error before '\x0' /usr/include/linux/string.h:61: parse error before '}' token fdiskbsdlabel.c: In function `xbsd_zaplabel': fdiskbsdlabel.c:840: warning: `sector' might be used uninitialized in this function bdale@j5k:/space/debian/util-linux-2.10o/fdisk $ From alan@linuxcare.com.au Sun, 5 Nov 2000 18:41:54 +1100 (EST) Date: Sun, 5 Nov 2000 18:41:54 +1100 (EST) From: Alan Modra alan@linuxcare.com.au Subject: [parisc-linux] compiler bug? On Sat, 4 Nov 2000, Bdale Garbee wrote: > Hacking the makefiles to remove "-O -O2" allows the compile to complete > cleanly. glibc includes are "smart", and do things like `#if defined __OPTIMIZE__' > I assume this means something in the compiler is broken? No, I think it's a problem with glibc, or perhaps just your include files. > bdale@j5k:/space/debian/util-linux-2.10o/fdisk $ cc -c -O -O2 -fomit-frame-pointer -I../lib -Wall -Wmissing-prototypes -Wstrict-prototypes -DNCH=1 -DSBINDIR=\"/sbin\" -DUSRSBINDIR=\"/usr/sbin\" -DLOGDIR=\"/var/log\" -DVARPATH=\"/var\" -DLOCALEDIR=\"/usr/share/locale\" fdiskbsdlabel.c -o fdiskbsdlabel.o > /usr/include/linux/string.h:12: parse error before "__extension__" Your .i file had this in it: extern char * ___strtok; extern char * __extension__ ({ char __a0, __a1, __a2; [rest snipped] which comes from linux/string.h extern char * ___strtok; extern char * strcpy(char *,const char *); The problem being that strcpy is being replaced with an inline expansion. Dunno why this is happenning. Alan Modra -- Linuxcare. Support for the Revolution. From xam@sgate.charlysworld.de Mon, 6 Nov 2000 01:14:41 +0100 (CET) Date: Mon, 6 Nov 2000 01:14:41 +0100 (CET) From: xam@deathsdoor.com xam@sgate.charlysworld.de Subject: [parisc-linux] HP9000/730 boot problems Hi all, i have an HP9000/730 (66.6MHz, 32MB RAM, 10MBit Network, CRX graphics, HIL keyboard & mouse, HP 535MBM SCSI HD). I got the latest nfsroot, the latest xc and the palo sources from puffin.external.hp.com. the parition scheme for the HD (id 6) is /dev/sdb1 swap 128MB /dev/sdb2 f0 10MB /dev/sdb3 ext2 rest i untarred nfsroot on /dev/sdb3 and changed /etc/fstab accordingly i installed palo with the following command /opt/palinux/palo-src/palo/palo -I -k /hydra/hppa/boot/vmlinux -b /opt/palinux/palo-src/iplboot -c '3/boot/vmlinux TERM=linux HOME=/ root=/dev/sdb3' /dev/sdb well, i used /dev/sdb since there is also the scsi fd (id 0) that is /dev/sda IMHO (i tested alos to use root=/dev/sda3 btw). some of the boot messages PDC ROM rev. 2.1 IODC ROM rev. 2.1 32 MB of memory configured and tested. Selecting a system to boot. Hard booted. [...] now it prints the palo configuration as i installed it and the hd partition scheme (but /dev/idaXYZ instead of /dev/sdbXYZ [...] ext2 block size 1024 ext2_open(/boot/vmlinux) = 3 ext2_mount(partition 3) returns 0 ELF32 executable [...] now all recognized devices (SGC craphics, BA, HIL, LAN, 2x RS232, SCSI, EISA, Core Centronics, HP model 'king Cobra' ...) the kernel boots actually, but i dumps the stack register and the processor registers (not included in this mail) after ASP version 1 at ..... found thats all. no message like 'unable to boot root fs' or something ... any help ? PS: i tried to use a IBM0664 2.0GB scsi hd before (works fine on linux/ia32), but i couldn't get it work on hp (i reported this in a former mail). PPS: just FYI: the same configuration worked with HP/UX 10.10 From grundler@cup.hp.com Sun, 05 Nov 2000 17:21:12 -0800 Date: Sun, 05 Nov 2000 17:21:12 -0800 From: Grant Grundler grundler@cup.hp.com Subject: [parisc-linux] HP9000/730 boot problems "xam@deathsdoor.com" wrote: > Hi all, > > i have an HP9000/730 (66.6MHz, 32MB RAM, 10MBit Network, CRX graphics, > HIL keyboard & mouse, HP 535MBM SCSI HD). > > I got the latest nfsroot, the latest xc and the palo sources from > puffin.external.hp.com. > > the parition scheme for the HD (id 6) is > > /dev/sdb1 swap 128MB > /dev/sdb2 f0 10MB > /dev/sdb3 ext2 rest > > i untarred nfsroot on /dev/sdb3 and changed /etc/fstab accordingly > i installed palo with the following command > > /opt/palinux/palo-src/palo/palo -I -k /hydra/hppa/boot/vmlinux -b > /opt/palinux/palo-src/iplboot -c '3/boot/vmlinux TERM=linux HOME=/ > root=/dev/sdb3' /dev/sdb > > > well, i used /dev/sdb since there is also the scsi fd (id 0) > that is /dev/sda IMHO (i tested alos to use root=/dev/sda3 btw). using /dev/sdb is ok - your palo command looks "right" to me. > [...] > now it prints the palo configuration as i installed it > and the hd partition scheme (but /dev/idaXYZ instead of /dev/sdbXYZ > [...] > ext2 block size 1024 > ext2_open(/boot/vmlinux) = 3 > ext2_mount(partition 3) returns 0 > ELF32 executable This looks like palo loading the vmlinux. > [...] > > now all recognized devices (SGC craphics, BA, HIL, LAN, 2x RS232, SCSI, > EISA, Core Centronics, HP model 'king Cobra' ...) > > the kernel boots actually, but i dumps the stack register and the > processor registers (not included in this mail) after > > ASP version 1 at ..... found Sounds like ASP support may be broken. The way to find out where IOAQ and GR2 registers are pointing. They should point to functions in System.map. Who is maintaining ASP support? > PS: i tried to use a IBM0664 2.0GB scsi hd before (works fine on > linux/ia32), but i couldn't get it work on hp (i reported this > in a former mail). Right. I'm pretty sure older PDC/IODC doesn't send START_UNIT command to the disk drive. The boot drive is expected to spin up on it's own. I don't know if newer PDC does send START_UNIT either... grant Grant Grundler Unix Systems Enablement Lab +1.408.447.7253 From grundler@cup.hp.com Sun, 5 Nov 2000 18:18:35 -0800 (PST) Date: Sun, 5 Nov 2000 18:18:35 -0800 (PST) From: Grant Grundler grundler@cup.hp.com Subject: [parisc-linux] string.h warnings When linux/arch/parisc/kernel/pci.c built, I get the following warnings: /linux/kwdb64/linux/include/linux/string.h:54: warning: conflicting types for built-in function `strlen' /linux/kwdb64/linux/include/linux/string.h:61: warning: conflicting types for built-in function `memset' /linux/kwdb64/linux/include/linux/string.h:64: warning: conflicting types for built-in function `memcpy' /linux/kwdb64/linux/include/linux/string.h:73: warning: conflicting types for built-in function `memcmp' Could this be related to or shed light on the problem bdale had? thanks, grant From bri@mojo.calyx.net Sun, 5 Nov 2000 21:34:54 -0500 (EST) Date: Sun, 5 Nov 2000 21:34:54 -0500 (EST) From: Brian S. Julin bri@mojo.calyx.net Subject: [parisc-linux] string.h warnings On Sun, 5 Nov 2000, Grant Grundler wrote: > When linux/arch/parisc/kernel/pci.c built, I get the following > warnings: > /linux/kwdb64/linux/include/linux/string.h:54: warning: conflicting types for built-in function `strlen' > /linux/kwdb64/linux/include/linux/string.h:61: warning: conflicting types for built-in function `memset' > /linux/kwdb64/linux/include/linux/string.h:64: warning: conflicting types for built-in function `memcpy' > /linux/kwdb64/linux/include/linux/string.h:73: warning: conflicting types for built-in function `memcmp' For some reason I had numerous problems with string.h not being included when building ncurses natively with the nfsroot tarball. (Also the nfsroot tarball seems to not be able to find the crt* objects by default) -- Brian S. Julin From jsm@udlkern.fc.hp.com Sun, 5 Nov 2000 23:12:56 -0700 (MST) Date: Sun, 5 Nov 2000 23:12:56 -0700 (MST) From: John Marvin jsm@udlkern.fc.hp.com Subject: [parisc-linux] HP 9000/730 boot problem "xam@deathsdoor.com" wrote: > > the kernel boots actually, but i dumps the stack register and the > processor registers (not included in this mail) after > > ASP version 1 at ..... found Grant Grundler wrote: > Sounds like ASP support may be broken. > The way to find out where IOAQ and GR2 registers are pointing. > They should point to functions in System.map. > Who is maintaining ASP support? No, the parallel port support for ASP is broken. If you disable the LASI/ASP builtin parallel-port support (CONFIG_PARPORT_GSC) you will get further. I can't guarantee you will succeed, but others have reported some success on boxes almost that old. This is at least the second time this question has come up, so I guess I'll add it to the FAQ and todo lists. John Marvin jsm@fc.hp.com From marteaut@esiee.fr Tue, 7 Nov 2000 17:00:48 +0100 Date: Tue, 7 Nov 2000 17:00:48 +0100 From: Thomas Marteau marteaut@esiee.fr Subject: [parisc-linux] A browser and a new URL for the ESIEE team web site Hi all, We have succeded to compile Lynx on a 712 and it works well. Also this short mail must tell you that our website can be reached with http://www.esiee.fr/puffin You can find a cool root FS which has the terminfo directory like that you won't have the "vt100:unknown term" message, the network support and lot of thing like that... Bye, ESIEE Team Don't hesitate to visit our website From kailasr@webcash.com Tue, 07 Nov 2000 09:46:53 -0800 Date: Tue, 07 Nov 2000 09:46:53 -0800 From: Kailashnath V Rampure kailasr@webcash.com Subject: [parisc-linux] Boot command Hi, Thanks. I copied the termcap and terminfo directory froma red hat linux box. Now I am able to run VI and the TERM is vt100. Regards Kailas At 02:56 PM 11/5/00 +0100, Thierry SIMONNET wrote: >To have a suitable TERM, you must get termcap or terminfo definition; ie a >good terminfo tree from a linux box. To have a good method to install a >pa/linux box, see my student's web site at http://www.esiee.fr/~djoudim > >Th. SIMONNET > > >Kailashnath V Rampure wrote: > > > Thanks! Paul. > > Yes I had copied the lifImage there. Now I have downloaded the kernel from > > the link you mentioned. > > > > I am still unable to use vi as it says "linux:unknown terminal type" > > Can you help me. > > > > To add features can I add deb packages. I am not that familiar with debian. > > Actually I want to build an apache + mod_ssl+mod_perl on A180c. > > Regards > > Kailas > > > > At 01:30 PM 11/3/00 -0700, Paul Bame wrote: > > >= ext2_open(/boot/vmlinux)=3 > > >= Couldn't gork your kernel executabel format failed to load kernel > > >= Failed to load Kernel. > > > > > >That should be "grok" :-) Apparently you're not using cut/paste for > > >these error messages. > > > > > >This is PALO saying that /boot/vmlinux is neither elf32, elf64, nor SOM > > >format. I'm guessing, based on some earlier advice I gave when you > > >were net-booting, that you may have a lifimage there by mistake -- you > > >need a kernel instead, for example from > > >ftp://puffin.external.hp.com/pub/parisc/binaries/kernels > > > > > >To tell for sure, run 'file vmlinux' on that file. If you get > > > vmlinux: 8086 relocatable (Microsoft) > > >that's probably a lifimage. You should get this instead: > > > vmlinux: ELF 32-bit MSB executable, PA-RISC, version 1, statically > > > linked, not stripped > > > > > > > > > -P > > > > --------------------------------------------------------------------------- > > To unsubscribe: send e-mail to parisc-linux-request@thepuffingroup.com with > > `unsubscribe' as the subject. From bame@noam.fc.hp.com Tue, 07 Nov 2000 11:15:50 -0700 Date: Tue, 07 Nov 2000 11:15:50 -0700 From: Paul Bame bame@noam.fc.hp.com Subject: [parisc-linux] 64-bit BUILD CHANGES The described changes have just been committed to CVS. If you have an existing configured/built 64-bit parisc tree right now I think these are the steps to update: Save your .config file do 'make distclean' do your cvs update restore your .config make oldconfig dep and then proceed as normal The symlinks come when you do a make {old}config and go with a 'make distclean' FYI >>> You may want to start hand-editing .hdepend (following each make dep) to remove the dependency of atomic.h on spinlock.h (just remove the first line containing the string spinlock.h) -- it can cause massive unnecessary rebuilds. It's due to a parisc-specific circular dependency :-( -P = I want to propose/discuss a new method for maintaining our 64-bit parisc = tree in relation to the 32-bit tree. I have prototyped this and so = far it seems pretty useful. = = Most of the files in the current parisc64 tree only contain one = line, a #include of the same file from the parisc tree. This confuses = 'make dep', causes some compile errors to have nonsense line numbers, = and doesn't allow direct editing of the source files in the parisc64 tree. = = The method I'm proposing works like this: = = The future parisc64 tree ONLY contains files which are different from, = or in addition to, those in the parisc tree. When you 'make config' = or 'make oldconfig', each file in the parsic tree is symbolically = linked as the same file in the parisc64 tree. This enables all = the rest of the tools/build to work normally. 'make distclean' includes = a step to remove all the symlinks. = = The ugliest "feature" is that even though you can edit source files = in the parisc64 tree, 'cvs commit' will fail on those which are = symbolic links. To reduce this problem, I'm dropping a symbolic link = called '...' in each parisc64 directory which is a pointer to the = corresponding parisc directory, so 'cd ...; cvs commit foo.c' will = work and not be too onerous. = = We should additionally consider a naming convention or something so = that maintainers in the parisc tree know whether files are shared with = parisc64 or not. = = I prototyped this as a fictional new "architecture" called "p64". To = try it out, grab the tarball (only about 30 files -- can be fewer) = ftp://puffin.external.hp.com/pub/parisc/ = and unpack in your top-level linux source tree directory. Then in = your top-level Makefile, change ARCH := parisc64 to ARCH := p64, then = make oldconfig or whatever you usually do. Let me know of any problems. = = Is this something we should adopt for the real parisc64 tree? = = -Paul Bame = = --------------------------------------------------------------------------- = To unsubscribe: send e-mail to parisc-linux-request@thepuffingroup.com with = `unsubscribe' as the subject. = = = From grundler@cup.hp.com Tue, 07 Nov 2000 11:19:02 -0800 Date: Tue, 07 Nov 2000 11:19:02 -0800 From: Grant Grundler grundler@cup.hp.com Subject: [parisc-linux] Boot command Kailashnath V Rampure wrote: > Hi, > Thanks. I copied the termcap and terminfo directory froma red hat linux > box. Now I am able to run VI and the TERM is vt100. I've added a "vi is complaining" item to the FAQ. Normally the FAQ lives at http://www.thepuffingroup.com/parisc/faq.html but it's not updated yet. I've put a temporary copy at http://puffin.external.hp.com/~grundler/faq.html and will remove this once the regular location is updated. (Hint - relative links won't work from my copy) grant Grant Grundler Unix Systems Enablement Lab +1.408.447.7253 From marteaut@esiee.fr Tue, 7 Nov 2000 20:53:55 +0100 Date: Tue, 7 Nov 2000 20:53:55 +0100 From: Thomas Marteau marteaut@esiee.fr Subject: [parisc-linux] Boot command ----- Original Message ----- From: Grant Grundler To: Kailashnath V Rampure Cc: Sent: Tuesday, November 07, 2000 8:19 PM Subject: Re: [parisc-linux] Boot command > Kailashnath V Rampure wrote: > > Hi, > > Thanks. I copied the termcap and terminfo directory froma red hat linux > > box. Now I am able to run VI and the TERM is vt100. > > I've added a "vi is complaining" item to the FAQ. To use vi and all these applications like top, they need the terminfo directory in /usr/share from any distrib!! Bye, the ESIEE Team From grundler@cup.hp.com Tue, 07 Nov 2000 12:24:39 -0800 Date: Tue, 07 Nov 2000 12:24:39 -0800 From: Grant Grundler grundler@cup.hp.com Subject: [parisc-linux] Boot command "Thomas Marteau" wrote: > Grant Grundler wrote: > > Kailashnat V Rampure wrote: > > > Hi, > > > Thanks. I copied the termcap and terminfo directory froma red hat linux > > > box. Now I am able to run VI and the TERM is vt100. > > > > I've added a "vi is complaining" item to the FAQ. > > To use vi and all these applications like top, they need the terminfo > directory in /usr/share from any distrib!! I didn't say taking from RH was wrong. IMHO, doing so defeats the whole point of debian's packaging system. Please read the new FAQ entry and tell me if I've gotten that right or not. grant Grant Grundler Unix Systems Enablement Lab +1.408.447.7253 From kailasr@webcash.com Tue, 07 Nov 2000 14:50:10 -0800 Date: Tue, 07 Nov 2000 14:50:10 -0800 From: Kailashnath V Rampure kailasr@webcash.com Subject: [parisc-linux] Boot command I agree with you regarding taking from RH. I just wanted to let u all know how I solved the issue. I have gone through the faq it is fine. Regards Kailas At 12:24 PM 11/7/00 -0800, Grant Grundler wrote: >"Thomas Marteau" wrote: > > Grant Grundler wrote: > > > Kailashnat V Rampure wrote: > > > > Hi, > > > > Thanks. I copied the termcap and terminfo directory froma red hat linux > > > > box. Now I am able to run VI and the TERM is vt100. > > > > > > I've added a "vi is complaining" item to the FAQ. > > > > To use vi and all these applications like top, they need the terminfo > > directory in /usr/share from any distrib!! > >I didn't say taking from RH was wrong. >IMHO, doing so defeats the whole point of debian's packaging system. > >Please read the new FAQ entry and tell me if I've gotten >that right or not. > >grant > >Grant Grundler >Unix Systems Enablement Lab >+1.408.447.7253 > >--------------------------------------------------------------------------- >To unsubscribe: send e-mail to parisc-linux-request@thepuffingroup.com with >`unsubscribe' as the subject. From cjknoch@yahoo.com Tue, 7 Nov 2000 15:40:14 -0800 (PST) Date: Tue, 7 Nov 2000 15:40:14 -0800 (PST) From: Christian Knoch cjknoch@yahoo.com Subject: [parisc-linux] HP 9000 e25 hi. i need information about how to install linux on hp 9000 e25 what version on linux what distribution ? how many memoty i need in this machine how many space on disk i need in this machine howto boot machine for install linux Thanks __________________________________________________ Do You Yahoo!? Thousands of Stores. Millions of Products. All in one Place. http://shopping.yahoo.com/ From matthew@wil.cx Wed, 8 Nov 2000 00:28:08 +0000 Date: Wed, 8 Nov 2000 00:28:08 +0000 From: Matthew Wilcox matthew@wil.cx Subject: [parisc-linux] HP 9000 e25 On Tue, Nov 07, 2000 at 03:40:14PM -0800, Christian Knoch wrote: > hi. > i need information about how to install linux on hp > 9000 e25 *sigh*. This is in the FAQ. Where do we need to put links to the FAQ to persuade people to read it? Where did you find this mailing list address, do we need to put a link to the FAQ there? The answer given in the FAQ is: The earliest PA-RISC servers have proprietary HP devices attached to proprietary HP bus architectures. It is unlikely that documentation on these busses and devices will ever become available, since so few people are interested in spending any effort finding and releasing the docs. Machines in this category are the E, F, G, H, I class (aka Nova) and T500 series (Emerald) machines as well as some earlier, unlettered servers. -- Revolutions do not require corporate support. From matthew@wil.cx Wed, 8 Nov 2000 20:14:43 +0000 Date: Wed, 8 Nov 2000 20:14:43 +0000 From: Matthew Wilcox matthew@wil.cx Subject: [parisc-linux] webshite since the lord god alex hasn't seen fit to inform anyone, it seems like i should. the www.thepuffingroup.com website is no longer being updated and all the updates are only going to parisc-linux.org. i have been updating www.thepuffingroup.com becuase no-one told me that this site was no longer supposed to be operational and i suspect a large number of people who subscribe to this list still have it bookmarked. also, email sent to willy@thepuffingroup.com is no longer being received by me. i don't know who gets it, but the sender does not receive a bounce. yours, fucking furious, Matthew. -- "It's time for you to change your sig" -- Alex deVries From grundler@cup.hp.com Wed, 08 Nov 2000 12:31:11 -0800 Date: Wed, 08 Nov 2000 12:31:11 -0800 From: Grant Grundler grundler@cup.hp.com Subject: [parisc-linux] webshite Matthew Wilcox wrote: > > since the lord god alex hasn't seen fit to inform anyone, it seems like > i should. the www.thepuffingroup.com website is no longer being updated > and all the updates are only going to parisc-linux.org. We gave LXC's website maintainer grief about this already. > i have been > updating www.thepuffingroup.comwww.thepuffingroup.com becuase no-one told me that this site > was no longer supposed to be operational and i suspect a large number > of people who subscribe to this list still have it bookmarked. Some time today, I expect (hope?) www.thepuffingroup.com/parisc will be redirected to www.parisc-linux.org (.com works too). I've asked mail be sent to this list when it happens. > also, > email sent to willy@thepuffingroup.com is no longer being received by me. > i don't know who gets it, but the sender does not receive a bounce. This should probably bounce since it's been stale for about 11 monthes now... hope this helps, grant ps. just trying to compensate for an otherwise lack of communication. > > yours, fucking furious, Matthew. > > -- > "It's time for you to change your sig" -- Alex deVries > > --------------------------------------------------------------------------- > To unsubscribe: send e-mail to parisc-linux-request@thepuffingroup.com with > `unsubscribe' as the subject. > Grant Grundler Unix Systems Enablement Lab +1.408.447.7253 From andrew@neep.com.au Thu, 9 Nov 2000 05:13:23 +0800 Date: Thu, 9 Nov 2000 05:13:23 +0800 From: Andrew Shugg andrew@neep.com.au Subject: [parisc-linux] webshite Matthew Wilcox said: > the www.thepuffingroup.com website is no longer being updated and all > the updates are only going to parisc-linux.org. I don't know if there's some other secret mailing list I'm missing out on, but that's the first time I've heard of "parisc-linux.org" I'm sure. So thankyou for being the one to bring it up. Will the mailing list be moving as well? (Given that it belongs with the project, not the mothballed puffingroup website.) > -- > "It's time for you to change your sig" -- Alex deVries Shame, I thought your old sig was funnier. Andrew. -- Andrew Shugg http://www.neep.com.au/ "Just remember, Mr Fawlty, there's always someone worse off than yourself." "Is there? Well I'd like to meet him. I could do with a good laugh." From taggart@carmen.fc.hp.com Wed, 08 Nov 2000 14:22:03 -0700 Date: Wed, 08 Nov 2000 14:22:03 -0700 From: Matt Taggart taggart@carmen.fc.hp.com Subject: [parisc-linux] webshite Andrew Shugg writes... > I don't know if there's some other secret mailing list I'm missing out > on, but that's the first time I've heard of "parisc-linux.org" I'm sure. > So thankyou for being the one to bring it up. It was never officially announced, just setup. I guess this is the announcement. > Will the mailing list be moving as well? (Given that it belongs with > the project, not the mothballed puffingroup website.) Yes, most of the project's web/mail resources will be moving there shortly. Go ahead and update your bookmarks. I've been told there will be a pointer/redirect from the old site but I wouldn't count on it existing forever. -- Matt Taggart taggart@fc.hp.com From andrew@neep.com.au Thu, 9 Nov 2000 05:48:06 +0800 Date: Thu, 9 Nov 2000 05:48:06 +0800 From: Andrew Shugg andrew@neep.com.au Subject: [parisc-linux] HP 9000 e25 Matthew Wilcox said: > On Tue, Nov 07, 2000 at 03:40:14PM -0800, Christian Knoch wrote: > > hi. > > i need information about how to install linux on hp > > 9000 e25 > > *sigh*. This is in the FAQ. Where do we need to put links to the FAQ > to persuade people to read it? Where did you find this mailing list > address, do we need to put a link to the FAQ there? I think the fault lies in the "Contact" page, new (!) URL being: http://parisc-linux.org/contact.html "Most questions about the port should be addressed to the developer mailing list parisc-linux@thepuffingroup.com" I would suggest this page be changed a bit, like stick the mailing list down the bottom and change it to a link to the mailing list subscribe and browse-the-archives page, rather than simply the address of the list. Also a comment about reading the FAQ. Yes, the FAQ is in the left-hand side-bar but you can never over-do the help. =) One of my favourite comments along that line was on the windowmaker.org home page (sadly it has been removed). It was something like "Please bear in mind that asking questions on the mailing list that are answered in the FAQ is NOT A GOOD IDEA." The FAQ on parisc-linux.org is also missing the all-important Q/A pair: Q. I have a question that isn't answered in this FAQ? A. Please subscribe to the [mailing list] and ask. Politely. Preferably in English, or (failing that) in a recognisable pidgin. Don't hold back on the relevant information either. "It won't boot" is not good. Andrew. -- Andrew Shugg http://www.neep.com.au/ "Just remember, Mr Fawlty, there's always someone worse off than yourself." "Is there? Well I'd like to meet him. I could do with a good laugh." From jvinet@linuxcare.com Wed, 08 Nov 2000 17:41:50 -0500 Date: Wed, 08 Nov 2000 17:41:50 -0500 From: Jane Vinet jvinet@linuxcare.com Subject: [parisc-linux] HP 9000 e25 Good advice...will notify the web design folks. Jane -- jvinet@linuxcare.com Andrew Shugg wrote: > I would suggest this page be changed a bit, like stick the mailing list > down the bottom and change it to a link to the mailing list subscribe > and browse-the-archives page, rather than simply the address of the > list. Also a comment about reading the FAQ. Yes, the FAQ is in the > left-hand side-bar but you can never over-do the help. =) > > One of my favourite comments along that line was on the windowmaker.org > home page (sadly it has been removed). It was something like "Please > bear in mind that asking questions on the mailing list that are answered > in the FAQ is NOT A GOOD IDEA." > > The FAQ on parisc-linux.org is also missing the all-important Q/A pair: > > Q. I have a question that isn't answered in this FAQ? > A. Please subscribe to the [mailing list] and ask. Politely. Preferably > in English, or (failing that) in a recognisable pidgin. Don't hold back > on the relevant information either. "It won't boot" is not good. > > Andrew. > > -- > Andrew Shugg http://www.neep.com.au/ > > "Just remember, Mr Fawlty, there's always someone worse off than yourself." > "Is there? Well I'd like to meet him. I could do with a good laugh." > > --------------------------------------------------------------------------- > To unsubscribe: send e-mail to parisc-linux-request@thepuffingroup.com with > `unsubscribe' as the subject. From matthew@wil.cx Thu, 9 Nov 2000 09:59:58 +0000 Date: Thu, 9 Nov 2000 09:59:58 +0000 From: Matthew Wilcox matthew@wil.cx Subject: [parisc-linux] webshite On Thu, Nov 09, 2000 at 05:13:23AM +0800, Andrew Shugg wrote: > Matthew Wilcox said: > > the www.thepuffingroup.com website is no longer being updated and all > > the updates are only going to parisc-linux.org. > > I don't know if there's some other secret mailing list I'm missing out > on, but that's the first time I've heard of "parisc-linux.org" I'm sure. > So thankyou for being the one to bring it up. oh, alex secretly went off and registered it. the first we heard about it was in a press release a couple of months ago. for a while it's been a (broken) redirect to www.thepuffingroup.com/parisc. there's a linuxcare internal mailing list for discussions of the parisc project, but it wasn't mentioned on there either. > Will the mailing list be moving as well? (Given that it belongs with > the project, not the mothballed puffingroup website.) no idea. alex is playing politics and he's not very good at it. personally, i think everything should be moved to puffin.external.hp.com and parisc-linux.org should just redirect to it, but that wouldn't fit with the aforementioned political games. > > -- > > "It's time for you to change your sig" -- Alex deVries > > Shame, I thought your old sig was funnier. oh, i just thought that was a more appropriate sig for the circumstances, I haven't changed permanently. -- Revolutions do not require corporate support. From matthew@wil.cx Thu, 9 Nov 2000 10:06:27 +0000 Date: Thu, 9 Nov 2000 10:06:27 +0000 From: Matthew Wilcox matthew@wil.cx Subject: [parisc-linux] webshite On Wed, Nov 08, 2000 at 12:31:11PM -0800, Grant Grundler wrote: > Matthew Wilcox wrote: > > also, > > email sent to willy@thepuffingroup.com is no longer being received by me. > > i don't know who gets it, but the sender does not receive a bounce. > > This should probably bounce since it's been stale for about > 11 monthes now... um, it was my email address until about 3 months ago. at least one person still had that as their preferred email address for me. if anyone else does, they should probably change it. it's the lack of bounce which concerns me, which implies that someone's receiving it, reading mail destined for me and not forwarding it on. -- Revolutions do not require corporate support. From dave@hiauly1.hia.nrc.ca Thu, 9 Nov 2000 12:39:57 -0500 (EST) Date: Thu, 9 Nov 2000 12:39:57 -0500 (EST) From: John David Anglin dave@hiauly1.hia.nrc.ca Subject: testcase for hppa64 gcc bug > > So I went down the path of trying to fix things properly by defining > > ELIMINABLE_REGS and so on, but I ended in a maze of twisty little passages > > labelled "Unrecognizable instruction", like this one: > > > > /src/parisc/gcc/gcc/libgcc2.c: In function `__moddi3': > > /src/parisc/gcc/gcc/libgcc2.c:601: Unrecognizable insn: > > (insn 1289 209 1298 (set (reg:SI 50 %fr22) > > (subreg:SI (plus:DI (reg:DI 30 %r30) > > (const_int -272 [0xfffffef0])) 0)) -1 (nil) > > (nil)) > > /src/parisc/gcc/gcc/libgcc2.c:601: Internal compiler error in > > extract_insn, at recog.c:2134 > > I am making progress in trying to make the arg_pointer register eliminable. > I have fixed the above problem. What was happening was that reload_as_needed > was incorrectly trying to eliminate the return from millicode calls which > is also register r29. I have figured out how to hide it from reload with > unspec. > > However, the compiler is now too good at eliminating the arg_pointer. At > -O3, it completely eliminates the arg_pointer. However, as I read the ABI, > the call must always set the arg_pointer before calls. For the record, here is my final patch regarding making the arg_pointer eliminable for TARGET_64BIT. I think the code it generates is correct but it hasn't been extensively tested. However, I don't recommend it for installation since in comparing the assembler code generated with and without elimination for a couple of test cases, I didn't observe any significant improvement in the code with the patch. Possibly, the patch implicitly disables elimination when the arg_pointer is needed. I do find that Alan Modra's ARG_POINTER_INVARIANT patch needs to be installed to get correct code with his test case. There is one part of the patch below which I think needs to be installed. That is (call, call_value): Always USE the arg_pointer for TARGET_64BIT. The use for the arg_pointer needs to be pulled out of the `if (flag_pic)'. Dave -- J. David Anglin dave.anglin@nrc.ca National Research Council of Canada (613) 990-0752 (FAX: 952-6605) 2000-11-07 John David Anglin * pa-linux64.h (ARG_POINTER_INVARIANT): Define even when the arg_pointer is being eliminated. (ELIMINABLE_REGS): Enable elimination of the arg_pointer. (INITIAL_ELIMINATION_OFFSET): Revise offsets for arg_pointer. * pa.md (mulsi3, divsi3, udivsi3, modsi3, umodsi3 and canonicalize_funcptr_for_compare): Put "(reg:SI 26)" inside unspec to prevent elimination. (call, call_value): Always USE the arg_pointer for TARGET_64BIT. Use the new addmovdi3 insn to load the arg_pointer register. (addmovdi3 and mov_from_r29_si): New insn and expand which prevent r29 from being eliminated in call setups and millicode returns. --- pa-linux64.h.orig Tue Oct 31 18:38:24 2000 +++ pa-linux64.h Tue Nov 7 12:17:12 2000 @@ -209,21 +209,18 @@ that grow to lower addresses. What fun. */ #undef ARGS_GROW_DOWNWARD #undef ARG_POINTER_REGNUM -#define ARG_POINTER_INVARIANT 0 #define ARG_POINTER_REGNUM 29 +#define ARG_POINTER_INVARIANT 0 #undef STATIC_CHAIN_REGNUM #define STATIC_CHAIN_REGNUM 31 -#if 1 -#define ARG_POINTER_INVARIANT 0 -#else -/* If defined, this macro specifies a table of register pairs used to eliminate - unneeded registers that point into the stack frame. */ +/* If defined, this macro specifies a table of register pairs used to + eliminate unneeded registers that point into the stack frame. */ #define ELIMINABLE_REGS \ { \ - {ARG_POINTER_REGNUM, STACK_POINTER_REGNUM}, \ {FRAME_POINTER_REGNUM, STACK_POINTER_REGNUM}, \ + {ARG_POINTER_REGNUM, STACK_POINTER_REGNUM}, \ {ARG_POINTER_REGNUM, FRAME_POINTER_REGNUM}, \ } @@ -240,19 +237,18 @@ #define INITIAL_ELIMINATION_OFFSET(FROM, TO, OFFSET) \ do \ { \ - int fsize; \ + int fsize = compute_frame_size (get_frame_size (), 0); \ \ if ((TO) == FRAME_POINTER_REGNUM \ && (FROM) == ARG_POINTER_REGNUM) \ { \ - (OFFSET) = - current_function_pretend_args_size - 16; \ + (OFFSET) = fsize + 48 - current_function_outgoing_args_size; \ break; \ } \ \ if ((TO) != STACK_POINTER_REGNUM) \ abort (); \ \ - fsize = compute_frame_size (get_frame_size (), 0); \ switch (FROM) \ { \ case FRAME_POINTER_REGNUM: \ @@ -260,14 +256,13 @@ break; \ \ case ARG_POINTER_REGNUM: \ - (OFFSET) = - fsize - current_function_pretend_args_size - 16; \ + (OFFSET) = 48 - current_function_outgoing_args_size; \ break; \ \ default: \ abort (); \ } \ } while (0) -#endif #undef SELECT_RTX_SECTION #define SELECT_RTX_SECTION(MODE,RTX) \ --- pa.md.orig Tue Nov 7 13:50:34 2000 +++ pa.md.work Wed Nov 8 14:06:05 2000 @@ -3993,7 +3993,7 @@ (clobber (reg:SI 26)) (clobber (reg:SI 25)) (clobber (reg:SI 31))]) - (set (match_operand:SI 0 "general_operand" "") (reg:SI 29))] + (set (match_operand:SI 0 "general_operand" "") (unspec:SI [(reg:SI 29)] 0))] "" " { @@ -4139,7 +4139,7 @@ (clobber (reg:SI 26)) (clobber (reg:SI 25)) (clobber (reg:SI 31))]) - (set (match_operand:SI 0 "general_operand" "") (reg:SI 29))] + (set (match_operand:SI 0 "general_operand" "") (unspec:SI [(reg:SI 29)] 0))] "" " { @@ -4197,7 +4197,7 @@ (clobber (reg:SI 26)) (clobber (reg:SI 25)) (clobber (reg:SI 31))]) - (set (match_operand:SI 0 "general_operand" "") (reg:SI 29))] + (set (match_operand:SI 0 "general_operand" "") (unspec:SI [(reg:SI 29)] 0))] "" " { @@ -4255,7 +4255,7 @@ (clobber (reg:SI 26)) (clobber (reg:SI 25)) (clobber (reg:SI 31))]) - (set (match_operand:SI 0 "general_operand" "") (reg:SI 29))] + (set (match_operand:SI 0 "general_operand" "") (unspec:SI [(reg:SI 29)] 0))] "" " { @@ -4310,7 +4310,7 @@ (clobber (reg:SI 26)) (clobber (reg:SI 25)) (clobber (reg:SI 31))]) - (set (match_operand:SI 0 "general_operand" "") (reg:SI 29))] + (set (match_operand:SI 0 "general_operand" "") (unspec:SI [(reg:SI 29)] 0))] "" " { @@ -5785,9 +5785,9 @@ op = XEXP (operands[0], 0); if (TARGET_64BIT) - emit_move_insn (arg_pointer_rtx, - gen_rtx_PLUS (word_mode, virtual_outgoing_args_rtx, - GEN_INT (64))); + emit_insn (gen_addmovdi3 (arg_pointer_rtx, + virtual_outgoing_args_rtx, + GEN_INT (64))); /* Use two different patterns for calls to explicitly named functions and calls through function pointers. This is necessary as these two @@ -5809,13 +5809,14 @@ call_insn = emit_call_insn (gen_call_internal_reg (operands[1])); } + if (TARGET_64BIT) + use_reg (&CALL_INSN_FUNCTION_USAGE (call_insn), arg_pointer_rtx); + if (flag_pic) { use_reg (&CALL_INSN_FUNCTION_USAGE (call_insn), pic_offset_table_rtx); use_reg (&CALL_INSN_FUNCTION_USAGE (call_insn), gen_rtx_REG (word_mode, PIC_OFFSET_TABLE_REGNUM_SAVED)); - if (TARGET_64BIT) - use_reg (&CALL_INSN_FUNCTION_USAGE (call_insn), arg_pointer_rtx); /* After each call we must restore the PIC register, even if it doesn't appear to be used. @@ -5961,9 +5962,9 @@ op = XEXP (operands[1], 0); if (TARGET_64BIT) - emit_move_insn (arg_pointer_rtx, - gen_rtx_PLUS (word_mode, virtual_outgoing_args_rtx, - GEN_INT (64))); + emit_insn (gen_addmovdi3 (arg_pointer_rtx, + virtual_outgoing_args_rtx, + GEN_INT (64))); /* Use two different patterns for calls to explicitly named functions and calls through function pointers. This is necessary as these two @@ -5989,6 +5990,10 @@ call_insn = emit_call_insn (gen_call_value_internal_reg (operands[0], operands[2])); } + + if (TARGET_64BIT) + use_reg (&CALL_INSN_FUNCTION_USAGE (call_insn), arg_pointer_rtx); + if (flag_pic) { use_reg (&CALL_INSN_FUNCTION_USAGE (call_insn), pic_offset_table_rtx); @@ -7124,7 +7129,7 @@ (clobber (reg:SI 22)) (clobber (reg:SI 31))]) (set (match_operand:SI 0 "register_operand" "") - (reg:SI 29))] + (unspec:SI [(reg:SI 29)] 0))] "! TARGET_PORTABLE_RUNTIME && !TARGET_64BIT && !TARGET_ELF32" " { @@ -7236,3 +7241,48 @@ emit_insn (gen_blockage ()); DONE; }") + +;; For TARGET_64BIT, the arg_pointer register is also used for millicode +;; returns. The ABI requires that the arg_pointer be set for all calls. +;; When the arg_pointer is made an eliminable register, eliminate_regs +;; will eliminate the arg_pointer register from the function call setup and +;; millicode returns unless the arg_pointer is hidden in a use, clobber or +;; unspec. + +;; This is for loading the arg_pointer in function calls. +(define_insn "addmovdi3" + [(set (unspec:DI [(match_operand:DI 0 "register_operand" "=r,r")] 0) + (plus:DI (match_operand:DI 1 "register_operand" "r,r") + (match_operand 2 "const_int_operand" "J,i"))) + (set (match_dup 0) (match_dup 0))] + "TARGET_64BIT" + "@ + ldo %2(%1),%0 + ldil L'%G2,%0\;add,l %0,%1,%0" + [(set_attr "type" "binary,binary") + (set_attr "pa_combine_type" "addmove,none") + (set_attr "length" "4,8")]) + +;; This is for millicode return. +(define_expand "mov_from_r29_si" + [(set (match_operand:SI 0 "" "") + (unspec:SI [(reg:SI 29)] 0))] + "" + " +{ + if (!TARGET_64BIT) + { + rtx tmp = gen_rtx_REG (SImode, 29); + emit_insn (gen_movsi (operands[0], tmp)); + DONE; + } +}") + +(define_insn "" + [(set (match_operand:SI 0 "register_operand" "=r") + (unspec:SI [(reg:SI 29)] 0))] + "" + "copy %%r29,%0" + [(set_attr "type" "multi") + (set_attr "length" "4")]) + From bame@noam.fc.hp.com Thu, 09 Nov 2000 11:47:51 -0700 Date: Thu, 09 Nov 2000 11:47:51 -0700 From: Paul Bame bame@noam.fc.hp.com Subject: [parisc-linux] kernel merge We're getting ready to do a kernel merge (to -test10 I think). Anybody concerns before we get started? -P From jvinet@linuxcare.com Thu, 09 Nov 2000 14:08:20 -0500 Date: Thu, 09 Nov 2000 14:08:20 -0500 From: Jane Vinet jvinet@linuxcare.com Subject: [parisc-linux] Website Plan Recently there have been concerns about what is happening with the web site. I'd like to let everyone know what the plan is in order to address these concerns. The Development team at HP provided us with a list of where current pages are hosted and where they should be hosted in the future. Item current future ---- ------- ------ mailing lists pehc LXC parisc website puffin LXC hardware database puffin pehc ftp server pehc pehc cvs pehc pehc As per Linuxcare's agreement with Hewlett Packard, Linuxcare (formerly the Puffing Group) is responsible for all of the pages that are currently hosted at http://www.thepuffingroup.com/parisc/. Linuxcare is in the process of redesigning the existing web pages and we will be moving very soon to http://www.parisc-linux.org/. By revamping the existing web pages, we want to make things like the FAQ page and the To-Do list much more visible to the public to encourage new contributors to join us, as well as meeting the needs of current Developers. The plan is to transition from the current website to the new website with as little disruption to the public as possible. Currently, http://www.parisc-linux.org/ is set up but not active. http://www.thepuffingroup.com/parisc/ will remain the active site until everything is ready to switch over. Each of the above items is being addressed independently and have separate schedules for transition. We will make sure that notification is made on http://www.thepuffingroup.com/parisc/ and on the mailing list prior to the transition. Thanks for your patience and we apologize for any inconvenience this may have caused. Jane -- Jane Vinet, Director Professional Services/Canadian Operations Linuxcare, Inc. 613.562.9260 (tel), 613.562.9700 fax jvinet@linuxcare.com, http://www.linuxcare.com/ Linuxcare, Support for the Revolution From dave@hiauly1.hia.nrc.ca Thu, 9 Nov 2000 14:54:00 -0500 (EST) Date: Thu, 9 Nov 2000 14:54:00 -0500 (EST) From: John David Anglin dave@hiauly1.hia.nrc.ca Subject: [parisc-linux] abort in eliminate_regs compiling glob.c from glibc The following abort occurs with a relatively current version of gcc from the cvs under hpux and the parisc-linux version of the compiler: hppa-linux-gcc ../sysdeps/generic/glob.c -c -O3 -Wall -Winline -Wstrict-prototypes -Wwrite-strings -I../include -I. -I/home/dave/puffin/glibc/objdir/posix -I.. -I../libio -I/home/dave/puffin/glibc/objdir -I../sysdeps/hppa/elf -I../linuxthreads/sysdeps/unix/sysv/linux/hppa -I../linuxthreads/sysdeps/unix/sysv/linux -I../linuxthreads/sysdeps/pthread -I../linuxthreads/sysdeps/unix/sysv -I../linuxthreads/sysdeps/unix -I../linuxthreads/sysdeps/hppa -I../sysdeps/unix/sysv/linux/hppa -I../sysdeps/unix/sysv/linux -I../sysdeps/gnu -I../sysdeps/unix/common -I../sysdeps/unix/mman -I../sysdeps/unix/inet -I../sysdeps/unix/sysv -I../sysdeps/unix -I../sysdeps/posix -I../sysdeps/hppa/hppa1.1 -I../sysdeps/wordsize-32 -I../sysdeps/ieee754/flt-32 -I../sysdeps/ieee754/dbl-64 -I../sysdeps/ieee754/ldbl-128 -I../sysdeps/hppa/fpu -I../sysdeps/hppa -I../sysdeps/ieee754 -I../sysdeps/generic/elf -I../sysdeps/generic -nostdinc -isystem /usr/local/puffin/lib/gcc-lib/hppa-linux/2.96/include -isystem ! /home/dave/puffin/linux/include -D_LIBC_REENTRANT -include ../include/libc-symbols.h -o /home/dave/puffin/glibc/objdir/posix/glob.o ../sysdeps/generic/glob.c: In function `glob_in_dir': ../sysdeps/generic/glob.c:1446: Internal compiler error in , at reload1.c:2516 Please submit a full bug report. See for instructions. make[2]: *** [/home/dave/puffin/glibc/objdir/posix/glob.o] Error 1 make[2]: Leaving directory `/home/dave/puffin/glibc/posix' make[1]: *** [posix/subdir_lib] Error 2 make[1]: Leaving directory `/home/dave/puffin/glibc' make: *** [all] Error 2 The insn that causes the fault is the following: Breakpoint 2, eliminate_regs_in_insn (insn=0x406a0ba0, replace=0) at ../../gcc/reload1.c:2826 2826 if (! insn_is_asm && icode < 0) (gdb) p debug_rtx (insn) (insn/s 2711 2709 2719 (set (reg:SI 6 %r6) (reg:SI 28 %r28)) 69 {pre_ldw-4} (insn_list 2708 (insn_list:REG_DEP_ANTI 2696 (insn_list:REG_DEP_ANTI 2702 (insn_list:REG_DEP_ANTI 2697 (nil))))) (expr_list:REG_DEAD (reg:SI 28 %r28) (insn_list:REG_RETVAL 2708 (expr_list:REG_EQUAL (expr_list (use (mem:BLK (scratch) 0)) (expr_list (symbol_ref/v:SI ("@strlen")) (expr_list (reg/v:SI 4 %r4) (nil)))) (nil))))) As can be seen, there is a use in the REG notes which will cause eliminate_regs to abort if it is called to process the notes of this insn. It is called from this code which is near the end of eliminate_regs_in_insn: for (ep = reg_eliminate; ep < ®_eliminate[NUM_ELIMINABLE_REGS]; ep++) { if (ep->previous_offset != ep->offset && ep->ref_outside_mem) ep->can_eliminate = 0; ep->ref_outside_mem = 0; if (ep->previous_offset != ep->offset) val = 1; } done: /* If we changed something, perform elimination in REG_NOTES. This is needed even when REPLACE is zero because a REG_DEAD note might refer to a register that we eliminate and could cause a different number of spill registers to be needed in the final reload pass than in the pre-passes. */ if (val && REG_NOTES (insn) != 0) REG_NOTES (insn) = eliminate_regs (REG_NOTES (insn), 0, REG_NOTES (insn)); ep->previous_offset is not equal ep->offset here and thus val is 1. The use would appear to arise from the rtl generated by expand_builtin_strlen. Anybody got any thoughts on how to fix this. Dave -- J. David Anglin dave.anglin@nrc.ca National Research Council of Canada (613) 990-0752 (FAX: 952-6605) From grundler@cup.hp.com Thu, 9 Nov 2000 12:12:25 -0800 (PST) Date: Thu, 9 Nov 2000 12:12:25 -0800 (PST) From: Grant Grundler grundler@cup.hp.com Subject: [parisc-linux] tulip DMA mapping Hi all, I see a "bug" in tulip's usage of mapping services. It's not the bug I was looking for unfortunately. In line 217 of drivers/net/tulip/interrupt.c: if (tp->tx_buffers[entry].mapping) pci_unmap_single(tp->pdev, tp->tx_buffers[entry].mapping, sizeof(tp->setup_frame), PCI_DMA_TODEVICE); 0 is a valid pci_map_single() return value when the system has an IO MMU. The system will panic before pci_map_single() will fail. The driver needs to remember some other way if a buffer was mapped or not. Or the Documentation/DMA-mapping.txt should be changed - ie add this to the interface definition and I can reserve the 1st mapping entry so no-one uses it. Should I be mailing Jeff Garzik directly? Or can someone who knows Jeff point this out to him? thanks, grant From rhirst@linuxcare.com Thu, 9 Nov 2000 23:00:50 +0000 Date: Thu, 9 Nov 2000 23:00:50 +0000 From: Richard Hirst rhirst@linuxcare.com Subject: [parisc-linux] strace working I have updated the strace source in our cvs, such that it now builds a basically working binary. It requires an up-to-date kernel. Outstanding issues: a) ioctl defines in linux/hppa/ioctlent.h are probably wrong b) there is a hack in defs.h to get round a problem where the libc wrapper for ptrace() isn't getting used c) there is a struct user defined in defs.h that should probably be in the kernel source asm/user.h d) there are probably more places where we need to add HPPA specific code Richard From dave@hiauly1.hia.nrc.ca Thu, 9 Nov 2000 18:57:13 -0500 (EST) Date: Thu, 9 Nov 2000 18:57:13 -0500 (EST) From: John David Anglin dave@hiauly1.hia.nrc.ca Subject: abort in eliminate_regs compiling glob.c from glibc > Breakpoint 2, eliminate_regs_in_insn (insn=0x406a0ba0, replace=0) > at ../../gcc/reload1.c:2826 > 2826 if (! insn_is_asm && icode < 0) > (gdb) p debug_rtx (insn) > (insn/s 2711 2709 2719 (set (reg:SI 6 %r6) > (reg:SI 28 %r28)) 69 {pre_ldw-4} (insn_list 2708 (insn_list:REG_DEP_ANTI 2696 (insn_list:REG_DEP_ANTI 2702 (insn_list:REG_DEP_ANTI 2697 (nil))))) > (expr_list:REG_DEAD (reg:SI 28 %r28) > (insn_list:REG_RETVAL 2708 (expr_list:REG_EQUAL (expr_list (use (mem:BLK (scratch) 0)) > (expr_list (symbol_ref/v:SI ("@strlen")) > (expr_list (reg/v:SI 4 %r4) > (nil)))) > (nil))))) The `use' arises from the `__pure__' attribute in the prototype for strlen: extern size_t strlen (__const char *__s) __attribute__ ((__pure__)); Still haven't been able to figure out why the REG notes are processed or a simple test case. The cpp'd input is attached. Dave -- J. David Anglin dave.anglin@nrc.ca National Research Council of Canada (613) 990-0752 (FAX: 952-6605) begin 644 glob.i.gz M'XL("('T"CH``V=L;V(N:0#M??MWV[:2\._Z*]CFG%[+<1I+\BO5MO>XB9/X MJV-G;:>]W6P.#RU1-F\D4B4I.]DV^[=_>#\'("DQS6/%O9M:P&`P&`"#P6`P MN!?T@F^___YA\;X8Q_/BX76G@]S:Z^'WW;N#^[RJ;%]S??!CT$T?>"=!#$SKX?@GZDKHP=+$^6HLN_F$![R?2SU M'&,1D#I(@O?ZGLY!^=OPM.@+#/H\7*3)._SC%DWE=/'NX552%L9DVJY?0*G# M%L847DH._$O6%`QJ%XV*F57P,_O0DM*8!7W<$L1O$T&T5EDJ7!QFV6C+M!&$9EF2=7BS(.PV!C(PS1 M(EN48=CM#AU\&>S[!RA`UN@FRH/->9Y=Y]$L3-);1D681K-X"\PI;K*\)/D& M'>7[>8PF(&]JEH?ED!$VJ%Z@K,F,T1GB;IX5E/%Z)EN3[%S)FAHS$T)9JX!: MR<-%D3_$73F5H^OJX?5H]`#_]V8^CQY0#/WO'^W)YI9CQ#@^Y:BD6143P?.H M'3Q8EUH=3_.)WMO>:;EBK,[NMXD3:YIM$]GDXY-ND1;)=1J/R>PKDO^)V>2S MF=KOMS(J3*Q[K;+U;_G$DEY/+F`Q:K&;"-`P7(3XCZ&=3Z0E`2!_`1"XPW`^ M^B^0.\W2:Y*-_T`]BI8+)+E1+I+$80"#DW\XVC\6T1B/!;B@"<^AZ9RO+P$Y M/ITK".=!"+6*<\T$T)A&*4+_]O9`)"K4P@+3N(O^'?1!)+(X!7#PR<%>]._> MCIN[[FX1!05%G/=8(_@C&H]S(Y?W)/IS'-^J;6&#AZ`=PQG7=@8;6`E2/<`B MLVP3%!+L`1YW=M&.OG#8.,@V"2K5C8)-@18M_N&(68= M,@Z+&"#V;?Q>;P,H(I+YB`^W#L@GQ$)UX80A1FGI&.`TD\UJ:.A."JB\,GPY M@!?'))GZ<5``"(<`0I/>SJ<3E,YA,U<=R&&!UOS!K>0@&:/H7_G9>[H M-#:DT=B:03.S%/U"1(?GH9!R7T>@&5QTK-6,VS+-I,B(\@-@FH/`/63));]".N"19 M*KYL3M!3L837\464C_$O!0@1\I8L/$0V!@$V'^#52&1H&$@JQ?`AX$W&E@9# M+BHM=G4$7D%"RNG`X"K)NHN2,L%*JZP(KV'NBAAK%[/9>[.0I!`4%QQ4K`2^ M"F9A'A=Q?JNR>H9J6:0EV))9F-VE<:X"OTW2\=#/FAECC6S';%'&[ZI:3X`H M>J,DT$EJT[-T9"U=)GGY'54%JKHUOQ/]2JE""1@FS@N00RC[#@U?RB,HE_P6 MX\Ⴁ-NBX1Y@32N6&,1;YJ?NQA&Q^9$I;!;X+O-IE&93&.-\5S>Z,.3 M<;>"T5>1P6B4D,=_+))<'9PH<8Z'K&-\HFQ@JEU%>9[$N9,J9_-90;7]GH6> MERJ)P._MU3"4:E(>F]U=MCUUP\VWV(&YTQ9;Z\#:8G/EW]A;"W6*;ZHM98[O M@@'E26ZH92;=*`3V?D$H57SSH^61K5?`-F`ZGX6*%BBJFII-MH`!VPCJ662O M%UP+35?)HGNZ@&_M]$RVK0O$]D[/)GO+8"'1*GFTD;*-9B9IB:)6JME$)0_F M$+DD!\I@&\2@@/1UL4$+K(V:V*(%8JNF%23+1Z`N(JKNQ^U5>&_$G0%X'DY3 M,H0!64U752JDO>UZ`32ZV`XN4'9R-A#=809\H^E&1-BJ[?TRZ24=##!RV^+1E;Q_*$N9QMSA6!8(P M202J=4*?J`I084"M3TS6)R8?G3O8&6+W8U:V/D]1J>[M>)4YCQZYT%4QP(*W M\!V@+(B&5^M3-T_T_"&PS]J)BA1B6^1_'N,C]^[0+(=/&[P%GSL*XG,&;\$+ M1T&B1?D*/N$%';OD1;A,>VT4S9MNXVC.!1M'`X:HK,SCZZ0HB7;C*WR7Y6/! M3V6(ZSX6Z3B)4MU+`6VRT%[,S'H$YE&<@[XSTS8]XFG//$Z4&CCLX`"F`?:S M-)VH5'BL='EU`:FHN%IR.7)O=IN<(-59JV!P>CCHDP("! MBPJMC7ZK:7)=Q+)9-/O'/!&#)(3FG.#?)<6!PG:YEHU@7R]%?G[OZ.:QE1 MW"QI8K#!/!@FXV)+8MX,\8D`6C'):0TV9^)\,G*-SU&$F*X;EHG?C>)YZ2JD M\\HHBE.S12D5$Z6A\Y9:NE13EVMK0!Q;`T.BP&WV(9`+F5$6)1-W`GZ2K%]A ML$>KPDYL(:]DJ(>+.DL$\[34"NYX^.-E"LP6A1=:,]L:-LN-FR4'3MUI(@5^ MA2KK6OW)&'E?S*)1GDD?8;^B9Y8!E@9]E>BYW)B9")4247BJ!(;/B@%$'$4" MZ76BBU7ACA*HGBD&#'S#)4:G0@%1*E))JX)))265TE5BDZ7960= M3@(\F:["E!I/J*T#L<_`U;!AGMI`)JY8F['RRQ# M9\PFG3+&%$^P`H-/2]V+%JG,U2S7("&]AC6Q'`D/4A,;BH.M0-+/(8>=#TZB M'"M`-57UR)HN2U?5V@M7-U&KHP*[3F6-A*2?*X8$U?N(U=-3F4$%[W=\^'SH M5(P@:/6LT5OP#'&,(US'KJDC==GKXZ:I)O5(E*H7%%/M!NKJC(NCD9 MG'=4,0'U3%W>UU)-=4&[6HT--2F=VAJ*E*D6H0V+2XO2<#?4CXRR[GGO.+WQ M*DQ#Q]!S]38ELA7Y[JK8)]];$N&NJC^*"'=5UJ((;TV(RT]X0KC-[1W;,!X5 M19Q+FQ_)HVE&%C..FWG0)OI>L-NO`&8L)K?DPI`"A),HF=KLI9E)EL(JFY?1 MADT&]R:`99&.,/YN)[`]T=*,]@J/^`,2/J>!=BC]M"H<]FFM6:?G,P^8Y(CL2V<'SW"WCI?*<9*IGGK*A)@F5W@3)"'$ MD-=S.D;1M>?\VG-^[3G_E7C.#W8@6=!GN:O,]BB_5F9["YATWB@G_XMD6B9I M>!LA(4P<3Z[3Q8C_M$7NO6!_%=D#4N/[E"N2"EV!DSZ]?QZY^T='SZ_['I^% M3X]/C@+\S[`:+`P-0'UY(/^*Y6$?R%'+B)4I73P,GX7.`,;K=62]CJS7D?4UZ[\X>*"7Z@"ZCWNC2Q$;>M;J/I@D1?"D-$`8X@Y17; MTKO2%(=X6NR[`ES8=S9]:Y^QO0XZ+N`[P6[VZZ! ML>OMC=V!NZ/Q4R3N%N\Y:]QSX,0/"KB&XIYC**H=!^L71#P8[RW(XO@MADH= M!IC>W*$R#.<9#70E9R@SU-.)^RR<(`@MVJR!A5U-KH5'NK6S^:XUZQI1?:M; MR1.81 MI`;TUROO>N5=K[Q?U\H[`#5^MO#&Z6+&MAS/'I^=_AJ>_1+\&&QO*2FG9_@_ M>LJ3G_7?+XY>;'64E*,7+R]_#X]/7[ZZ5`&?OCHY"<]>71K)QRGAQ='O$\H-23HXO'Y\G*/OH_/SLG(7QMEI[?!&> M'%Y[FD8GIV>G1_1\A<?O6=-T)S?3QZX>5QOR5IE(E+&;NO>;>R+1\G(ZT>*X0J?,0O*5 M"%%C.J$4\??0`E!Z7P`J:78!1I(`9K_5QPNH`+4FHZ04`Z6HAJ%;IFM1[B'A M3=QT;]#*']Y$Z7@:4TIUU\)9-F9/'6KF?QSJ'H">Y-F,/8UH9Y99*%`I*P'Q M(->XQ+N<^`$G%A,E^P3C.I*\69(BQL2XE9@:Y=6"Z)TC0Y8H,Q"^S(9*#<1^ M.5E,24/T#G/V!1]=UGP,PVR!W9^'[JP8Q^M7ZI],H^M"2U%>IY2]HV9CW])H MBD,6,^Y+>RQSU<8J@,-02S!Y!R+Y-70\-R(Z=9+1$OL--BY+,3"TW5D535+$%O$8RZ7#`3[P`J85;AP>[\JC&.)< MS`?J66VE#/A`9M+L*DGI0P6(N$2T3`N>^&RYZ*2R[(I121&2Q5(40%CJT[+$ MAL)P*FO]BKM\\-EV4JOU*>YQ_U[,YJBO38\YP*>.>H^C?"U.OE)N%N5OXUQ[ ME4.F;K(%);!\\S;#@HBHCI`IY&`'[X6WP48228`W+&3HCN/1;8FO.)GI98(CAAF7ITLID?+*SHCI&U-VQE54Q%8.??K*DP75 M0W.@BM!:!2/#&52;-C**Z-91_U4T>KN8LSRP&%//#>49Y_+7\<_Q/[0JZ?-.J`VO>V]HC9:2@,@B779;1E=X/V=U*%G.A2N7W$ETJ/#: M#,RN-5(9NXU4SCF9K/>HF6[AUOI2)JL=J:?R7F0[);,+9;+6?Q8\1P,I0_2/ MPLQG"A%"A.>1X"0.82$WCR*DE.)4DTW'^$\>P]>*;Q:.%CGJ]^EB1N:G]E(T M[4]1G+O6&0,"UR:4/T0C>P62?9IGCB0$''^;<@!J^4(>\($F#+V\Y334EZ"0 MA;-ZW=M5@K%CRVGP`&W)9!*SS;SA0]9Y2T11?HV\<#[%SV#RFY10+OG5#WLA MOL"2AL.ZL$@VU@=&VFIH1`Z2PX:(A3$>.:X\(H==F0BWZ%#[.3"TT\_HA)RD MG*5XP)O&6,"J@\;*E;,*OWI=QT:W"2B..OE`WB0^9OSNZYUE321X1M.L@(CO6@^N2?91"/:37>750[2J7&'0[+<+ MG+>'0=.?+F!!-(-FOQ5PAP^?THA-_,>0IPIJ-\E?(IV3M8G_$*FB_DWR%S$\ M$`E!J$$`G!3-#]`)$C@*ZGLW`H)EJ77A6\&;)J6A[HABI&_5V]#TX4WQ`"ELW5%E0I@ M'2"X:IKOL;2HY*-RUW$Y4C$@ELV-1J*\^0)#,:/R5E`%/J&/HU="86,!`&?5 MC@8[?;XW'D/@2K/$")Q@<#+.0#9*N$7JAQ34EOE[!V0%BV\GQ2A*-88$,F2> MOH]0,YRS0+\52N>/$H3/IOUV,L_1WT:?P!34(<"@0`VW(I8BW&_1.+4FQI8$ MDN640@4:D48I?DHG2LGJA):$2Z)A@G[K906(=A3L+(]6*%]YI6XY@O(XYKIK MA(28-3B,F4LGW9UGUBF0:.)A2+&O"._J3#^L[YGHN9A5PQ.J'_9B&\!F4< MW=49T&+[56M,+S.H[^J,:KD+K$-%S9%]9P]MVFG@Z-:'RIUOK-">V%=-M?H- M;K%Z<\?^@/OW`[DT)+WEM^_XY,M"1C`/ZJMWD\WBAV.T%>/^2-<(;/0PN_KW M.,EYI&M4`C%N)BX!/&I>T$,=%&J$LH5QFG)25]M%FJJNBT1%35?&5Q[/T/(* M!]G"!Z/&(I631!L<[2-MK3N-[_1`,I26IY6Q<]UQ M,CT%L7@NE*:R"O-XQ2JK*W65,P5KH/(.>Z-#X2:@P4NX5B/F\"J-Z`Y!QJU8 MZ_+,JV"?Q:(Q[68U/I_EY"%M`#9[Z3Y([IY5.J/K9,0W3=X5<-FF!MZM&$LH M5*'%*)\A<4O:SC*>9_J? M&!6%-AU%C,U[4KY8_;T%<12*=HXPW2Z'"FZ2U/M4MJ8Z]Y0VH'U9:W4'BOT( M_V&%AT-5XC!H6GN=HIGK>V[BFHK;29;/(J2U??_]]\;Z(G3+90H7O#10ROD> M6=UZU(INO3RQYXV-%>XV(_`06K[S:Z.-MPTX!*+K&/C\3&N]*7J'I?[*Q2"> M1>^P0')55:L/(76(YE-O&4I*&&X%@ZU@A_K-:%:GVW;(K4O5::N`00K1Q8RRTM=FZ6O4]1_7+]LQ'D_<0P_0Q3X]) M+`55`7%`=$P83+IAXS$@?,8*&YD"K6`U:6]B`#$.>WPT5(%V3>@8/,H#4 MKE#KPVUAKU7.IL@N!BSXV&9?U;_86L]QW/E)ID,8]TWA4H(HGG3+8T+H#&&4 M2HO\N/U[X)JV"UJ%WA3EV!4PH>,3D'$\31P;=+PC]&DE_`/WZ"EO':D@0557 MXO&UTR*^#=+;(=S?/1#AF+H5Z':0[2U3`GTEH9E,JXYGY".50A$X+BWWV@^88.=#W&#/9 M(:K1<5EA6J>P#Z:&2U).^U\BPJ5K^=]09N"S"9`=+#`;Q!#+?X%RQ$:EZSN, M(2J8@R7<8\]FBLT3N`&2*XKWG]9%9#2-IG&4QWE>==I'/(HJ0*@[D6=0:#76 M5+-QS;5!R0LG]51M0LNA\O0S]A<$0%-[\O'YCJ*=A M31RAA<08M\2#NL9.@L!5\<,XP)G#!YVC;#:+4N^!F+H,.T^0+;5UA/Z>)6-` M<]7!%D6<0V`%]6[,\+4!ZL.MT,%20VZKT8&-"<92O6M$;>,$0,1M:U0L:\V0 MQ>U-NNVG26:(XL=7)>TU!SWW1HVB5=W^_"N9_KB!=%=1?5S@;%#P\P>S,,V= M6F'E8M4$IQ4NP? M_YW^8TO=;'D&EU\[](PI_JT2K&L54]?KX>O;;O; MSN4+Y>[M^A:W>\'>CMLGD^)W/"YG/<-J^]UIV6V=>-<^HJ?`#8_I]5-Z[XG0 MTD?:S0Z.JYMA'WX8O@9U3XL:'7TVH*MGT&78D>N(@@JSBV]3ASFP]('5Y]&? MBAZ[CKBZCKBZCKCZM41NK9H`PX\CAVAMS40S(*?#)(/\]X+=KT@QF#X2H7["M/C"Y#. MZJ?>A4<*S#C!1QV5E[;6,O?O_/"&I_GS\8L4:7!CXQV;>58D[[0L\32.D=4& MV;W]71"U-&XB)IMA58L@=V MA-:%X$-M<7J;Y%DZB].R,*S`=>`[4`5W63[&B_ ^]!L<2'!7XX.6+2+7( M[TM5HA;Y:.UJ`&TP_6#;S72@C[[.16V]8UGO6/Y/KI[][0;3'_R4P#MIB=0D MM'GA?PPMD`+IX%.\G0C$7[I"I=Y#&(W0]L#>-)![H7S;@C#;Q]SQ(ADW+*TS MA;U>9"W[AM?+E#KYJ/[^BM-,$9>VWXS54NDQ0K!AUPT#G_0Z<6!46LY.V3D& MW76+;2VIUYJLA/M).6-;&>69[YE]R\&!""1BWH0*F[&*WXO`V)0NCT7:J&Q( M'\H"9XK=HUH3]?[T-M)S).[!9LR_!,!*/$PJ!!962T*+10$^JDOLGN``<< M&JH+84W&M)OND-)''!-8PG6>+>:`$R[#IPZ3"AR6A)VV09/>QG$"N%UA0YGM M5\*`%2F']#?'5LWTB!_=*2Y#^GP0UZ%E=:(8#C"9(PT:F]A":@C3KHR8\$8M M-@?'B[DAI_7,OMI!_*^^"B@.6)B"/S1S9+JY/KZ+1U`P%9N\1MDD1RTNE/:((2B;M<$:21C'U,D(,Q4A@6^:$32M M8+F=N^:4KT46+4XL?F)4/&DR$OV%]%3`53*,W^%@@DRZEE&Y*+HU;+B=BKT\ M?CL"3S##FE$%RP8Y?N>+/QX1OGP4",)J%?X>/#T[-3(TT^ M-$;33@]?'!E%7QY>/C>3CE\>A3^_>JHD/7Y^]MMI>'YT<7E^_/CRZ(F*\RR\ M/']U^EA)^O7)\<7ASR='2M+%[Z>/P^,S)>703GIY?GRFIUR!6')\\,=-.?@DO'_^BI)P^.S][]?+" M@#M[>71J)"%F'!V^,!(O_\MD,DK\?V<_AX_/3B_/ST[4\H>_'CT)CY]<*&D( MX\GE,4)P_S\[/3LU<7 M"E,E(L3`)WH&+V'G/,59RN\7AR]?(AC2$6KRT8N3,XV9+"4\/SQ]=J2GGYW_ MCD@YNSQZ?'DL1R[)N[@X?':$AN;%A=[(BR-4\?.S'YX@6AO'LY_^' M$&J,0(/JY/@"56+TRB&80@;ADZ.3RT,C$Z4=_D[8;&2\^$]H=*!4@DI/_15U MDM[:EZBI>#"C)#D*+E'WFZ/MZ$5XBOXQ!R9.__7PY)4YYA"&_WQU9"6K#5!J M_!G][_#"!$:I3X[-$8X2+QX?G@"P6#J<6I/N[.0D_.WH^-GS2Y/TH_]\=?PK MFH&HG\VFG-],-SBE>9C2*W#W1#/T1-.#Y] M8B0].?I52WEZ=GX))R(9J"5>_&;!H9F`^/;DZ*E*S,OCXRWM5_BO2S,%B\&C M2R.1O@II)9]=:*41][7!62WY%\OG_7M9KQ\-H`2=]3RI.J?M6XF2;9X-08K MD@@&$$G18$[.T.J@(__M[/R)D?3BY_#$6DU/_^OH7%-5@+E[`5!Z`9!Z\?S< MI)4F:5"O`&RO[%:^(HTRTI0:9`M.L$9JM.HD/$&*D97XXL)..[52+HXNK30T MXB_-P?WSQ6YX?/)RT`_/GCX=:`-#R_KY^)F9=_)R;P=G[>W8.0A8H4VV+RR-5 MVKQ`VX9+M!%@_%!S7J&.>HG*,!&M:9RGS\`,I"B@>6Y4C%F'--'?SO&"20C3 M<+U$R["9>'[T#"F&9@(@%B^>'^EJC[69NGAY^)M6`@V$PR?'6$,Z1_B`!=H) M0)D7/CF\/#3&GY&C=2P>,6>O-&WH\O>7OGW,*U1S2/>F<*J&_^7/%_JO\/#Q MX[-7IY=Z+^`,K)9>'AF);!-FI%Z>'VJCX>)WM+T[>XD3/@PA>\7C"V)A$'N- M+9%\\A0M^T]/#I_A]\A[V]O;'"W+.WE",LW4XY_MI--+`!0)KL=P,H@9IUNX M22+##C3!E*Q*>WI:>RQ`FP0;1*<&R+>;;=LQ2;JJ(0`G8UHJM M@2XK+`NOPR*%VW$69'G3ZNXL4[POU!("SHA/@6&*,E?!7.\)36,C!BP^5!O3 M0#'S9&R'&%?S=0`0Y#J?6]',33AR@V-^G9!`&CQI3HM`*$%`TYA<@)!;2J4X MFYZS[NX>.,]93910>QSM0O"%SB&[-86C,?*HD$,NX-X0^;$#X)H#7%?DQ]=P M=[+`5^08K1#&=QS(1#EDHV$"K`,&4@B'8KZ*R5&;.)-S=MJ",H2?YBT@:A!8 M'AN`^2+1CA5C5TFSX,))"AL^-LTF*09@?DU)X;]C5TFS(,`5/C0F6?X6/O_C M$+I1VR0?/69";H:28\0 M/.*L58A-$(;2(06GV->)O1ATHZ1S!\GT5/1_\C2]6C/TX9>#VX$]JYTM]WH0)3#AP5J MS8@/>]HC]#SWUGP]BCQTB0IRMQ-\B;COX:?ZH7YQ]";V4=[O>QRV`>IOLJ+4 M+Q&Q\2>\`N$96:A%88<^[XQFY;%\5P)P6:*943G.9E&2@G3JE>@UJ,66H'%2 MO$]'EK!6(6YOHO1Z,;?5!BHI;[.WCO=Q8,^M/$-YBI<4?4@59^$Q$\WFTSBD M;P_4"9DF(+B;HNE]-8JFIG,-<_(L?3)%@%$P M,>=##9Y@8QF%01, M>$Z34*-EQ*\D'L"7,\"M*`G4H(@WE)9FJG,/0O=HQ^/"JFI^^*JDO14>S4P> M.QA,RNO,-3%(/D.;-Z._\$O)FGQ,IN/8CD_%%L/\_1P0$V_C][;264334I,= M3#(P'$+?Q@WB;8C'.(2'J?E3B7$777D#4%+5%\@H,TBL%J87M=W8$@Z6AI01 M^#:5M@;0VV%(!LCM2K!!1%<\C_*XR\:W-UJ#+!1A!\EF948WJ"=Y$3%.!X[+ M>E:(D@9._EJYAA<$+%=]-&Z7_VM;*?6!E6W=[.B28>V6&G]7FWU#D6S MKFVYZJ;UUYP_SO)+W`K21++S)@ETPP,M&#G_"\3U*LS1!:B[& MATK%HS++WU.358*OXJ10A)'R)BGP]JIRJNB?VH*&1:WK)%J#S6L?9J;SVH>N MO[1U@<-SA]VB@KK,>$ZCN28]9#CQ;,8'J'1':)-4[\;'Z M7#^CT=`N<_BB(0#.7G3)WO1@1&_U$BS[;*+Z^(R:GAGAE-;8BZ!E'3 M9J=9R%!O>&QD'=,D0)31.,7]A-7!11Z3HYF]@^HH0^L.$%W8YDJ M0P2)5,6&M8Z7LHZ7LHZ7\C7%2QGLF#+`CI3"7G/`IT)W8Q()FJYV\SNRW`W5 M!`J$D[@.A1+1'S3EFJ=YI1[)B%;#/Y>1(.S"$Y@6J?63?"_;A<)+V;DDN<-K`Q^;9M#3V3311 MRQ.[)S//J7\QSS4+W@PI`L8YU:LVXG?Z2ZB*'4TDUW;HA88P23/$]C'^[Y`E MT4WM&/^7"@><#!@PT-3#,6C2H0Y`>G9,#J!I#DO`0_QU?W?OS9#?(M*(VMN1 MMXDP->3LQZ2+)1+*/A95O+O@[N4A70\07E+`G$\Z/GJ&$`YEPEHS9>!#UD?D0#M=,8'B!15%\64;>*']L#C&-@?#MN2 M"#@I3)#/R?3M[>PZ^*KKL30CV,0F)P"1N1H:(TV4PX>64$G-/9%`AK(.9?7% MA9R/T^J4:N502OZ^9L&*]=Y!+YHIC2D.;#[5IQHH[*%9#.T_$:WL;2GX)*[\6\91XL70M0R='ZW"CY0A&LWG7]#Q_%C.VW'//D&- M^]T.<.PY7^2Q$N72YK6H1N7VZA6I=X3BO$@0BH_>%*6B=ALCJY&O"N*3=S(& M\B0N()>,6I<^U3';T$]6[.>-NJ(BGCMV$0[J=0?/9>E?H@7JWM_7"M.&J4M0 M=;>*\%7L5VW7!V#[`&])J1]$37"^QW+L1BW7%WTG2O<_5OU-]FD>LQ^TDP1J MI$VHJ-.Y.P3J=-!TO&GC*5B!B M]U-4@:]2'O%+NO3GE?,%/"D=-<2&^%T1];W@T:"9P=>G@EGO"R-5D9F"-0B: MHP$(>["99U:PWK.M]VSK/=M7LF=C/C66/+"=\KPFJ+LH*Z/48'XV%7R=^O0;=C&FZE,5Z6)3R*AU/(@($(A8CMF1I@)/%"0M> M8^Y82']ZSD-7<+9H_\FIX&NVZCW[0V]O"&9@UU2DJY2C;!S_<."!&65Y/%[, MYC_T/$#XVBM*^F%_R,GX@--1*TA6DD9E//;0WISTHLSFN$8?Z1CF-IIB&),J MG#6G)*D'9#N58]_\^)D2Z3?19;(7L7*RF)?Y4'0E2DA8`B;GM\-C'*CZ\/+5 M!:`5E'F4%O0J;TB0VMM`BQ3!83E\_EADI:0@CV>T]G%RRU[\#;\.4<5H04@,?6A=NH`*M!N7CNP^N]XUP?5A3#&=7^(F88UX!\T^QO2^#$YV`)Y2_(0'TW"&V!+JWM'M'CYX#`]DR5I M9E[?D0DOU8@B"A&R=9)X,K$\EH-CKF"NT)_%Z][@S9`H3I1I\%TLNAY>#068 MEHY&1787Y\[\"YIJV%M]`S]:C?((6M$E[799Y6-;(3' MVW^=H:F,L1:-5VR/KXM\5%`MC1$Q68V(1C3`^AL?N:NR8_4NA0CNV+JTZ#YW MQ(3FH[)ZOHE7/^%N;)&8YK3`_=DF?U;O7?:I#0!V=&)I:Y?X%0E7!8S1@%J+ M7?L]T4JS:C:PV?KW,=K:2CN];5QR170UMAGWZ;?J8*!?:T."?BZF=:1=21P[ M)CB00LSD4*>NR<.W]2<73^G3J[#83]E*Q\7C-NK-#Q9%O..CE+87HM4=*I;6JHU_]^TA=-:+?[GRR,G;I6J(;=/UFV^]516<=:U9"N M:9UQZ3([ZI3JG5[#3-+&:&W2Y?XVP$*S4]OHT\X(;C:$FW=+'=M+&RWYNSK& M;@^P'M5<7-KM&\?RXCF'4"N5JQ"MAP7MV>P&&RS(37>["TH-S!O/085:"7:M MZ2HF:4]56T&O8HWRG&E8#:M=6[,1[CWXL&AH0(2F,%#8Z=Y.I,5\3L%[.]'> M#D`1^%B[>@QC>?*\+QYB0YTXV1X\\AG>.NJQU:"/-J9YE(ZSF2/@1,%SK9". M,?R$2I+2@^P8+"(=M0B,UZM21HS"H&9P?HH'!XBCE9EXY>$HLY_2AA#[J7HD M2EBP.5%/9FE2;B<1W,KQ*<*H7+H42>/XVD@IXKF!"HF&D!_^ZB>)C$YY!UTA MO+93JJBG.GY"(2L$.PRF@G%8P2,ZWHD)6%26&`65+I)>?IF-CR7-RY!7MTI] MVA%X.>&L^>:9;082B]>;^M0T#4UC7&CGP`PBQG)CG@N<(H3ANV)QE;P>O`&% MV11&+/+3Y5'/*E#_NS%JR6E<3-T$(];=1E-9"72<@H&',WMXMK5"M;HK$ M_+6SV#S*H]GK?4HE&U2LKW2)!91^]WKPQGEC//)ECIPY6/F7>/GTEEXRZKU2 M1J846"KA<'P0QW1BP]`AM)0Z8UFGM].K+L=\'$+U-Q?:8X\8J-4,2C\Q@ZI( MU5@T^R0L^O>7Q*)"$FN+JRT7+2P*3L=<\V)?NZ4$KQDU&_*8TG!:I.4Q M0\QO7Y$]QO*$3O(XUI!I6@))'SE@S'T$J2+B-P*,VP!JI@S18N2QOEC?!%C? M!%C?!/B:;@*P]P0M62"\H3491_--\:LZ5SOD3M_&A>]J>;#="W9W]GS&#@W9 M[5+K0D=;T$A$"QR\/9JBU8R+U4V4H$IRDCF+TU*DU%TO5(*C*W)?V!7..=-)NKF5I")?@IX/XTH&,>AWEUUW]EW['K@UT M5@=2C"J&6FS1<(1'JR&A1@+\+$!Z6R,@E+!*D9#7874Y,^`J`9>VK3Q)KP'` MPH/7#CR/YL%"G'WF\7P:C9@7I,HII*_5H%:/?!7C"PJWKN?W:/G9VQ)-%MDH M_&N*QBL8.'SVMJB"!L#)W4MW`9.>L;<*E&-U)6V116(8"/371WD*F"54,-K6#&TZ32Y(CO MZN!_Q3,QBUDL_+W&<9K-JO!QXBBJ*<&EGJM0A$I*+:P.#O!:E&JLNFKYFYA% MZQ$%3_QX=(N&H?"#TT1W.DZN$_;HGSZSQ_%H#L<$L&'QKAQ:XR:?K.;K&C4K M]_U56PE-_H-R37EJE+L%>N633UGY=B.4:;,[M". M\0Y#6\>I\[N1<]%WJ&C>VNY&93:[4M3]K8!7'(;D+TUQ8(AF5P4FLO!0Z7W) MM3ZM>KT(+2:W@`].JVOT4*O6VX&V!?E\%I4C6!N>HX086E!Q0;0!*Q97F7Q$ M6J\=92"=P!E#5NK[N$Z]:)F]11I%D]NN9-I887GY*R!(\04?RP:W2==YA)]A MTEZPTB$6*7XKVP;1EX]Y6=#-B0&D[THI4*-7V*S0_:6Q2=2SIUDTCFZO%8'. M4EZ_$7(FGL8SU:ITX(AOT]?1$[<(U`^ZTXMF(@@KG%Z,O7U['B^PSXME2O"X MO&@VG2I/$M)7NJ<(%+%J!?\0#5%]!Y&E.-6`$LCK0]19'TV%`X8&N^J)=<51 MV)9^)`UTXZHGPE4$.(L9YYP`::N>Q'Y$TOSGKLO18X_&UI?H3TXP\)<77(?Q3X4=((4W2 MN*!*@NPLO;?^6"2CMZI]CZ*8:T:^,BNC:8B5#(\NJQSNF*9%'"C1;/SH710: M)S/*N0R.O\B/T/)K_J?-PA6/H/!7?>1U+^@-=BN"#]HQ!?'QA.E!X/13WG$4 M[EMG@*AIH]'\O33'CI$6;9N%BQS>CVDS>.3?U9!#EA3>*1(*E>*SZ!T>_2Z6 MVD%^%$Q%/%>V(!3UW)9(XWB:S&RI5N8XTN0(GUI85/9L+$6_`9&BBG2$YD.# M.FII:TNRB[S/#G=(K2%M8TP]*+?JT.MV'L*:X1T>LS>Y?:!1\`W,:#E.(*0I M=&MN*;S*!,LKJ*W%$V\-+5>@^BCA3M/$CQ*Q5,]3S`)K/Z6UG]+:3^EK\E,2 M$4L->:":@)B+*!)'JD*AF:2=X;1-X:4:/'-+L;!JG&6W<1T=!C)_6M1[R:^B MU+%2@Y+8]J'!]:/MCJS>(<1-8SJB6M4F1&G@40*D3>C+@7\IL+C3:*FI>OQ` M]^"MM;0WI+?AXEN38'9%#ND,>*P`5GI]K$!F_%P+\R,0IEZ,CM'EK\(=VI0;PO6F9OYODL\9C MJNF@ZMC[4C.:W_8C]R)B;I%&CNAH+L[KX:":L8A4B)F$*Y3[0VBH&BWW&E`, MDF`!`N^5ZKC.`M.N_L:KEIEBQZ'HHZS=OG,/8$D750`#>ZH&VS2$;45T,'U5 MV[ZZ..64&Q5S^$3CY3W92Y/BF[64A9GN2^ M5V\BH2-"%=0D@1I"ZXT2Q28T7V(7!A#E7?5-WBQ59\.M'R`+89OR$E*[J76Z MZ5(3YWDFSG[0CW0QKZ`GZO8.5T>DZ\V0B'-T3NR2I MPWA4JV8)HR94:JH=V4]]94%_<(YF:ON"3R'5W46*6.+;V_T9N[)6<=M;RX:G M0,U,%2Y.-=A5U=_=9#7U>.L(K"5JU#V935I]9DD553M%U`+7T`-%_YKN5,'L MFT_+G#@VD#.X+J*I8Y_O?1),]U903Q'V8(L" ML0"9UB,%55]_$((5AP#Z/@A&Q4Z_"D8A>6_'!WPOV!_40&:\1?&GC`M$6(_O MY>:O^V^&Y+6JB\OSX]-G_?#QVK(MYQ M(-Y9%?&N`_'NJHCW'(CW5D6\[T"\ORKB`P?B`P]B;0#W#K9K#W?S0_/IP#]9 MT)SN>:<<$STB=J2Q0PT+;'?D\HON3+:@25`['C4PSEU(&PU$'`.Q"B79H' M]0@L#!#P'H1HG^9!+(;G*`(^4-9D]).8#G#(.?J"(0T^Q[C&PL8YN#2*^J[\ M``GQ#>"#8\Y_E;E51Y';X>R1%^64'>D MK#QF+4?1=Z$85*$81['G0K%? MA6*?H]AWH3BH0G'`41P`*#YTE%#1:GD12QAC"N[+,:0$%7;[%#K=#H;JJC@X M>.37"G=VO``88G^_R;*IGFE(R4M35UHO5U@N5U@M5U@L5U@K5U@JFZV4M%\Z M<'>Y=HUM+8UMK8QM+8SK=;'INJA(L#87R'_\]_8_ULOC_X7E45LN+6;_L[EJO7^OU:[U^@2C6Z]='6K^4 M?5SP(.AIR]F^WP!IW!TVL__M[WJ42`3SR+I3W@H/>;@7`P+]5!(RR!_O> M-IC27/5RQ7Z)X:@'NATP6<4\$NU5@>+I-,3#G@"Z3@J$3=)"@P*@(;"-._SN M)IF2`ZGB-<]Z$WQ#IWSPW7>!E:$X3J+O_GV>.51'#D_ZT*G!DWYU6R"#)O1I MA?JU.%FK=A/QQV5M3S;6!]9OKPL&'ZL+#"2#6EU2BQJSHHZ'C,%GTF'>W$'= M[F2RZ%&_D1U+[?1J$<*\B_V]51M-#>Z[V/_CCPJ:U8=[]92G==4<[5J9*GE3 MOVX3;SO\ZP5__14XVS=^!Y"FS.E>JJHIML&M0-S178&+J%*-I$2N&%@V4H<1? MY1P1E&C4X`^F"'^\:7I5@B*5*@9>&"8?&TMP/^C)W`\=_J]37:6CRK]E]XPJ MU&YE%-3;-*OCJ+J\OL;+(53>1E,Z/@HYDG@R,)PTX6,.`]9)LKB^F=XD/=B] M?U_AO^@G7':#HS4.WO$-DF1:)BD5%E%:AG-*)T&.QY#R2Y&)7*H8T7TH@5N2 M/"0F"G&?U,I%'QZ>%B_@%FEC#^:3,HQP557K*.[=OJ]W[0U\]7!IB/#3CA^B M6X(Y_1I#BT]_B_P1G>Z\%TPAA;)U*443)%%0:E\78*.Y(<$DTJY//JDEW2-- M2B=#XL'\M818W=$W:#18:FESE783<\`VI,%O(?F,!C!CEBM_\-D-<+UW(9#! MUS@'KO7AY[AN7SV.Z^%I>;@"XW1#<%E;:_\4VYMM3%Q$+@I%_6&]59BKXIJ[ M6W=#@4*:51=IZ`Y`;15'@/\D5Y"B;=*/YEY!0G=?;[\A=&X+_=#>$F%$O4I$ M/8JHIR&JJ8]$VUP7P7\UT4.B;9<.@G*Z@OQ^)?E]2GY?)=\T.:C(:6-I!5[$ M@S=*@\P-M8V14L$:Q8,^0)I5)<@P^.#0OR!Y`$UL\[/O1/M"50;^B"8XV-UV MG:LZ=JVM157!-`SJGE7>"_K>VU!]"L$CR^[&][ZZV'ID8]^G6R24H>MM!ODI&`OU;6(S!O!5K4>\\I>U]# M'TYS-'`0B!ZCN>+=.1Y5;C*-K@MY9Z_O:C;N\_Z^MPMIG^-K/X_\761REV30 M"W\Z;V4&OHID9SCZCKFH58,V^-@]*_PIQ1$6Q`D*01JBAO<-0<Y<^ M7:C`[>V8]^,^HQ[:V_E,^P@3MFPO^>KP5T&[<&]'O#^)9CJ[-VS,7T4.XC07 M+8$B#Q41YXNMB76,.,]9S'<5+4'1=96E@\^L'*=:EZUQ(GWP71:2D+:DITQI MJ8VKM3(0/>1J*=103+Q:KJJQO$%8RW:L;K2E?RPRY=58I,>`2XD5%7"I.BP, M=I)*\PU>KH_=&XTB..,PA$$*_QTQ2L.#HE%$9C]F[%+%^ M<8SS1WF^U]]%';./:+_09EK]-61>QLK32&CHE#?<@4@M0$Q+K)0\5.JI_K;4 MSL`P(!2PL8?8A)A%:(L:HMBO#]HOS5ID(E$1X6WJGP8L_N[?)Z0,.V:R;F5B MG$&[^T6LIW_HF'\Y3YFXC4VWL&TH+?OK+\;;GP)YGE#=L`]`PQX\J-FP#P#; MQ7F:!@F9C10`FS\]THE-(C+#EW!A4B@4SM@\W8KH+// M'L*L`*-)"`7EMW_R,T!MDM,9H<+R4";F?$#"BB>SF8U2R+%SP*+QX'?K^:]L M.AYEB[0D7,5=P8@W;'AXE!`Z@/0-TKK@N^!_-S9ZP7_\!QI&?]$_>OR//O]C MT$7PY*\]GK3#_]@5>?L\Z9'`M"TR>P)K3Z#M#<1?.^R0;%L7`&Q)2S,2.`D_ MU!AL($#4F'Z?,YR/D0<]9=Q@GGPCFLA;@28*'8:$*0]^8@JX\%'"I?0R/3ZY M.$66T*M]WHB%"IG%Y(\JZYX8O@1:VO:T]*[@`::N"A5%D M#3W;O#=IZ M?>C6J6NP>EW>['Y]4G8^.BG>[$%]2G<_-:7>[)WZ#=G[S!OBS=ZMW\[]+[N= MWNR]^FPX^*K9X,W>YURRUHP?`B4J,I?A8I4WP94H6G)MP\LN6M;`O1I9;M1U M%VL*M(!#4>#*@J[1"S4+TJZ)%LGU)4O5-C<1*F*\_#/253"^_R'9WP#[%G./ MH^!169#3*WJ]KKFYP5R@93Q<<'&B16Y0COCY@]4CU#:N"-V_CQ.[U,?0&@N0 MXKO;!;I7IT$JQ,1VS7?L;I!;R#4":A'5,A&T486F\`EC@.XY:=H%)/TZ:?3E M3^I2:36MGK9'>>I4]7@_^'4\T3$>!8_"".U.=+!+K:M'?C#W$$\%Q`,&XZ0> MY_MIQQ"""W)R90K<>2W(RX]*G3NO!6UIORYM&2M*;>L*>U\^'.8L><6 MQ=3NB`84-60;)]YH@=W&]U'","J*."_#292@-?9;`/;;+=\)\E:PN[V/9^G+ M\Z/+R]_#IZ].'U\>GYV&(>KE;>7P73#)-L6:=E54/S6(P@XSFM$5>P>970T- MSBZ$:2`Q\?OGN$;N?D+MR:9+P<-_*%Z4S!U"%``,Y=*.3&Z$&50JCA[$O0,- M=E85$EUDX/ROXP(?X$(/`'FW[P6AEN&+<%WP]D"HXN8L4!1N,''I@PTIM;LA@ M)"WY;=!J/I*[!FN#2]7'3%C[:!C'MFL?C?8I7?MHM+.=^$+:N?;1J,.&>CX: M?'W0]B54<`M=B<%TB3R1@@E@L@&U=KY2:+$6(E2HS33H^5&Z9@K\L M5UM#HV:*K!)Y0E%E*_9`G#$>MP:GA[#=8(^_@U-WQ-V1J,T!T-$QB`8AO8RM M,93X)6/=HXJ/QK=)'&NSB5"SK.ZU"/%XP+`^Z&FZ[80\%4YX&218T=&I'J*! MGKC&#JGR=?+&KY.3#N8^[K;K".*+4:78KM38@[")8>Y!M#LG#*0G@Q;@^Q9Z MZD-M\^+P>K[)9C&YKH2F98PD[RW:B#X_>W'TK;;14KM'EK!<]GF6(BFJ_6** MQ6@4%X6YAV9[`548\8]Y9M-7UVE`L_<%:A2.%7+Q.#PY>W9\&IX>OC@*7QS^ MB_LA&15C=W16GD@2P#[`T?3F_"$(GAE0'@9$!$=T2[H)7*\!&$*EQ)_OS00_J4/PI[>QM]W<@ M$G@K_!W,$<$$B5BRJ)?G=ZA[92]_1TINB6JV!$TXSR--O[%6//Y!G<_9XKB@ M@JUY.^[*7!@)?WR.=?JG7):"O@^.'-%)FVCRN8HW[B88C?L"#QZ&CF(?W%;/ MN?-^B_HI4G?^X*?Y'?Z[VN]2KZE5.6S?*]H!2+=-=_33E`R@C=_^[[=#HRW6 MLF(O:7K]4F7EB$U3I+>%MFF)?TP"$JRZW8Y79(V":D.1P':?*^*6G*AG+/I. M\F5%@Y&&R6\TTD#K&HYJGFX+IGH.N3GW*@ZY):J*LVX)*!HC.JBA'4SB6OG0 MV\#D!6CC"+Q9?14`;9R+MTQ0!4`;9^9_-\45`&T*345X)TL*Z\3DWKA*DA37D"V]_)4@+*\K7SZ)*$/^)S7K'M-XQK7=, MZQW3>L>TWC%])DSYF#LF96E4W!-`%VEI[+4MMFJ4NJI#;MJ(.!V'_,BN7B2L MASP2UL,:D;#&W)&!0,M(6%JZ?LRMLGA1Q'DH'2-M`&GO-DSFLEV>(P>!'K6> ML]7P;5[!>%YM"1=$/N#5VZ;PQBZ42D,\6A%0M5<]TK#Z%20-5*A(=H5-E245 M[ZKJDHVK`J0%E6F).BM!6E"YAV2ZBD/X`*6,JO*XW5/@?57AQ5?@= M45[!'D>5OD9-O8QT;S'(N\CC553/407V)@+]B$2/0,Y$BBL1Z#%D>_8LXR4$ M^P?5\@QR^@39WD!>+R"%K1YNFJ4:NOM8CCYU7'RJG7L`?QFED(.%'YR.F#YR M/JH?C!$B%Q5Q;$G8E4>.D$.MYE@CJM6N8_&O\9Y"$+5JD#6)R+^'D'"M!UM; MFXS7)N.UR7AM,EZ;C- MQZSW,>M]S)>\C^$KHQ8<4`_,L9P+#&!+=MSE=+R6HH5AX[$-Z@978U9@Y9'J MHA2&6/WIXX(\3.T(Q\9BQJF6:_P`H`GQR#ZX^B>"VI2Q%MA#S6/N>?,=>\IB M&SAO(-H"TA?*[U&/S+)QC*,O!-N]_6WTD5(;V]L[Y(==+PG?]XZU;6,@#MU( ME7L[M%)9Q=Y.G4JZ73C:'#ZN0H.@0;`)6=:(;*&U0XWPD<%,:`A]B<_80F-$QF5IB&K`#]/7=(`.P(CC]M"RG>'A/,"S@Q+"2*(9T2Z M\3QEH'.;%5@[,B:\E!=%](BK)#]HK?H%3-BT%ZWJ\3" M9&C9$["HD`B[DL?728&P\;A`;CG]J&N>+.NO-6&LWV-1-$>K'CT%E>*)I@T! M<"2`QB8X2X/`1].LB$UXG@@5(,N3"HP3(,"I!3G503_(%0X_>6L%M((EIA7Y M!X=J$$M?(-^OK12X?\F.<`%SD+Y$W!MT7<]_BW!;V$.WT)YL94W4^YN-2O[B MKQQ71N`EP5(Z+_2P2^8"ETW'XMVM>\&C7D7$3J6T*`F]X27!M-X2C[1S#6=+ M(Q9'@*I>^7B7*M&5982Q'2>[(<[#@ MM_/AJ,S&(%"S/MAR7GL[OAFGOS/%LNQO4_.IP&0J3@_DT*E885IBEG/M$2*% M#:@?V8@ZT-WCH8#-)@_P:.&1R1SQO^P=@AGLQ6P_4T/X9#&T$9[NJF&//WAHX\\*RMYD>?"1I:K55`4P)0H8@4R\6F\KTT`0?/P1[:=Z$\H_ MYV:4;42_@3>B_$-;WF^6WY'R#]J9BEUI;0KJ;ECA*&O@ZL0_W[:-[U=X)Z%) M46].6-]]35B!(W?Y#0C_7&'2ZLP;'<[]\@'^W',,?Q_`L5MO!RQ%M_.`1>.C M=Z>LK0.>K;*$$R&P=7'Y,Z M=UX;YU.?BG)W7ALG4)]CJ]QY;1PO?6DM=N>I$4"`4R./B"5Z&R\%.L.196AE MF2N1N/+:D+EU:G'GM2%S5Z7`G=>&S/V8U+GSVI"YGXIR=UX;,O=S;)4[KPV9 M^Z6UV)TG9&YO.:^SM3J^5L?7ZOA:'?^"6K56Q_]V=1RM-5OD32"@-F'A6E4$ M&XA\^2V(XD:U^?-;$,NM4N//;T%,_ZW4^O-;$-V?56O\^2V(]"^JM?[\%L3] M5\4-?[Y8#O1#CF4V#>M3A_4V9[W-66]S/A/U>+W-66]SUJ<.ZU.']:E#NY2O M3QUDWOK40%@W7Q5U86_9"&OVW`\:3D#>*&:/HG6'Z MHU$X")HG+@;QBVOT?E#E73#]RE"MVSKP'1VSQY(WOM@1*T2.L&[G.&KF(23< M==>^H>,:).P^E'X7RB8';R>,\-M4UB'!A`JZQ#!IB'WSADG#BMLU]KV:ZILR MKCLR>ECQ>GLQ;+G?IC6IR;8MJU>3(ZCT'^9#F)&-NEW337DCR++2[FN@(H8VUCIBT3EG?H'0C,Q M2AKJ_U8PRJ;3J(S':#V9S:,\%BIR1XWT0F-L=3"A'7-IZ[#EC,5C8;%:J,XR M[/S9@:]W0QL+OHR:L5UHJGD;VU30;>7*9*?!I/L!ZD7W!H>V471.#61BS/B+ M"A83KF+=*AGAIG;,O@@VHJV`,UA=K8-H""0R;JOSB/Y=]!#7-C?LC$T*W*7X M@(+]JH)70S[<<25(+^M3#07D]U:0:JRE[6,PG+]T]T[@61)30U/*;#%463(9K?+F/AP%:RBM'S,"-H7C,K8?_X+'P!#[$U7M!K[?[J#+DC#EG4F66B'!XE-IX6NK4DD8S MA5IHJ:HJ;47M8@32J&H4G[;?]2G2J@K-7A%*]*TN,+$HB0\>*%//'%7TDU?. M93V4^C@=:R^X-`_$YH2H//T8+Q6IC0Z1BNB^P((Z5J*YM?!,HTM]D-GM/<]8 MIRYO=GM/,K9`BC>[O2<8/SZEWNSVGEO\Y`WQ9K?WK.+GWDYO=GM/)W[A;/!F MJPQ7X\EB].\R6+K%;W[P=$+9#)]=8LN9Z['R"F:[9WT=+4`L^J)>'D M<\-4Q7`M6[AQ`/<$HE47+@.1+[^%I:M1;?[\%E:O5JGQY[>P@OVMU/KS6UC& M/JO6^/-;6,R^J-;Z\UM8T[XJ;OCSY;._;!71UC8JW#FX`)*KVP?5`0#V]7;M/\41$/\*P?#\GEDRS;[N!T==AB/[,DZM%&9/)>X?PHY$X3:(B MV/C6+/ZM[H^B&I.T`W\Q@-"O>%1F^7O7B7_5V#*L3Q29,NZ8EXGXO;')*D#3 M3RV[A7/Y#`&LL,Q*6)2(P3/;U86==V/X:9*^U4U$>AXV`+TK#9.0,)I]`+#1 M_`*HE5G3)MDB'?,)-(O+B/^-GSDF8PHGDK>3G5,9"B7.#8NT-'_CP(ALO=/] MBSD*]*#HXT:,VQTAA2C5=*K3T4K]2JP:51N6>>*/J"2/1]32X?&DINHY_0L( MRA^&>72'CT)NU%%*P>F1AYW1[9IV.>24'NW3<)3/YMDP`3NR99 MP?_)0)-L$/@]S6LYFG-,U>[F'+*NP96/28=')4/7AJ.YALH/T9+3>:,:JR!: M_PS;5071DH/[%]GR*HB67.&_4MY40?@MO'*A M4+8-PM`+X5Y?7EU?7EU?7K7RUI=7UY=75[R\NMY8K#<6GUQI66\LOJQVK3<6 MZXW%E[BQ\`7_Y";'59<1'8\GNX4%I$%=WNP6UHWV2/%FM[!6_&V4>K-;6!P^ MEX9XLUM8"KZ0=GJS6Y#Z7P<;O-E"NJO'2?]GPGJNMV+KK=@G5_/66[$OJUWK MK=AZ*_8E;L5\9MGU&<_ZC,=)W?J,9WW&LS[C69_QK#<6ZXW%YZ!JK3<6ZXW% M>F/Q^6PLE#,>X=ZOF!.[:MP1?A^G(O[@/P,@^*"D`X<<5,$QN6JP0`UR;X=> M,]CN=F302N!N1<7E"NUB"HGR0]O*XZ5H=YK^[*CQ,<4=%.MV"G2%@(=*,H#U MR%`$Y8.?S`L)/")*3P,F,5#4`IZ@@M=9F>&(5JB3PSC/L]Q1*VDVO4T&`*`Y MZ`YJ*SBLQ2!D]VRVU>`I]+]:V%8U7HMRI:@BFB7[]&&%[X2-<8QWYSK)S^YP_#6*UTNNJ:4S M$1AYPPI^MM\E`2I9(#34D]NNALH66\-I3T'28TC`F-'69\7?=+/#D$@'4B+Q MCX4G`H(OVW%`]>M]2F0I[9.A3<%<*H#PV$%\WD14@TVN._DP"PV472W&+)HS M8SH?Z?QQX<'2GL&BRI\46W(5 M53_U%N#&QKC+>>$L@*AT+\#RWA]ESIW7 M@C'ADU'NSFO!4/!9MLJ=U\+V_XMKL3M/;.>!1WH!N4K_I;MY]]K#-WMNS9>B MI%L_LA%TKIQL/VS$,5:_^_=E:`;[^V"EZBG.]QFX^FT%9&!6@"X8HM0?2,#> MSK:\WZ_<5%<8`TQ=I*XYP*UM--8NJL,95"H82\O^&IOA,L7ZV`+KZEM M5+Z<<)_K$=6OJ]F/J:DKN_4R6N/5G82.&S(M1K6)$X#A?N#!H%1?/`U![ON_M"/OU+]4.JIHY1].L MB#4[)V^U9N\.!:!EY)0'4XX3`ZQZHG91/C#+O*KZ_C,88"LVSE9'``Z91]O# M(Z!Y.>-O=)TF*PVN;&YE4RE'F)$<&KQVAZE:L.M!#B,DI%*D:^K[RIR0720C .#:+Q]O\!-6U&P&H/`P!E ` end From alan@linuxcare.com.au Fri, 10 Nov 2000 11:36:56 +1100 (EST) Date: Fri, 10 Nov 2000 11:36:56 +1100 (EST) From: Alan Modra alan@linuxcare.com.au Subject: abort in eliminate_regs compiling glob.c from glibc On Thu, 9 Nov 2000, John David Anglin wrote: > > Breakpoint 2, eliminate_regs_in_insn (insn=0x406a0ba0, replace=0) > > at ../../gcc/reload1.c:2826 > > 2826 if (! insn_is_asm && icode < 0) > > (gdb) p debug_rtx (insn) > > (insn/s 2711 2709 2719 (set (reg:SI 6 %r6) > > (reg:SI 28 %r28)) 69 {pre_ldw-4} (insn_list 2708 (insn_list:REG_DEP_ANTI 2696 (insn_list:REG_DEP_ANTI 2702 (insn_list:REG_DEP_ANTI 2697 (nil))))) > > (expr_list:REG_DEAD (reg:SI 28 %r28) > > (insn_list:REG_RETVAL 2708 (expr_list:REG_EQUAL (expr_list (use (mem:BLK (scratch) 0)) > > (expr_list (symbol_ref/v:SI ("@strlen")) > > (expr_list (reg/v:SI 4 %r4) > > (nil)))) > > (nil))))) > > The `use' arises from the `__pure__' attribute in the prototype for strlen: > > extern size_t strlen (__const char *__s) __attribute__ ((__pure__)); I don't see this problem using current puffin CVS hppa64-linux gcc. Was this with your REG_ELIMINATE patch? Alan Modra -- Linuxcare. Support for the Revolution. From dave@hiauly1.hia.nrc.ca Thu, 9 Nov 2000 21:50:49 -0500 (EST) Date: Thu, 9 Nov 2000 21:50:49 -0500 (EST) From: John David Anglin dave@hiauly1.hia.nrc.ca Subject: abort in eliminate_regs compiling glob.c from glibc > > > 2826 if (! insn_is_asm && icode < 0) > > > (gdb) p debug_rtx (insn) > > > (insn/s 2711 2709 2719 (set (reg:SI 6 %r6) > > > (reg:SI 28 %r28)) 69 {pre_ldw-4} (insn_list 2708 (insn_list:REG_DEP_ANTI 2696 (insn_list:REG_DEP_ANTI 2702 (insn_list:REG_DEP_ANTI 2697 (nil))))) > > > (expr_list:REG_DEAD (reg:SI 28 %r28) > > > (insn_list:REG_RETVAL 2708 (expr_list:REG_EQUAL (expr_list (use (mem:BLK (scratch) 0)) > > > (expr_list (symbol_ref/v:SI ("@strlen")) > > > (expr_list (reg/v:SI 4 %r4) > > > (nil)))) > > > (nil))))) > > > > The `use' arises from the `__pure__' attribute in the prototype for strlen: > > > > extern size_t strlen (__const char *__s) __attribute__ ((__pure__)); > > I don't see this problem using current puffin CVS hppa64-linux gcc. Was > this with your REG_ELIMINATE patch? No. Well actually I saw it first with the patch. I see this with the 32 bit compiler. The only elimination with the 32 bit compiler is the default frame pointer elimination. I just tried the hppa64-linux-gcc compiler with the source that I posted and it didn't abort. There were lots of warnings about int to pointer conversions though. Make sure you compile with -O2 or -O3? Register elimination only occurs at -O2 or above. I see the problem both with a i686-linux cross compiler and a fairly recent native hpux compiler under hpux 10.20. The problem is not present in 2.95.2 but it doesn't support the pure atribute. Dave -- J. David Anglin dave.anglin@nrc.ca National Research Council of Canada (613) 990-0752 (FAX: 952-6605) From matthew@wil.cx Fri, 10 Nov 2000 09:49:07 +0000 Date: Fri, 10 Nov 2000 09:49:07 +0000 From: Matthew Wilcox matthew@wil.cx Subject: linux bame On Thu, Nov 09, 2000 at 03:53:48PM -0700, Paul Bame wrote: > Somebody never imported 2.4.0-test6, then I imported -test10 on the main > vendor branch and now can't (easily) undo that to import test6 and THEN > test10. This workaround sucks. don't use vendor branches. didn't you talk to mang about this? -- Revolutions do not require corporate support. From matthew@wil.cx Fri, 10 Nov 2000 10:18:08 +0000 Date: Fri, 10 Nov 2000 10:18:08 +0000 From: Matthew Wilcox matthew@wil.cx Subject: [parisc-linux] tulip DMA mapping On Thu, Nov 09, 2000 at 12:12:25PM -0800, Grant Grundler wrote: > 0 is a valid pci_map_single() return value when the system has an IO MMU. Oh dear. You can bet tulip won't be the only driver which assumes it isn't a valid return value. Can't our IOMMU code be limited in such a way that 0 is not a valid return value? Say, constrain all allocated addresses to the top half of the device bus? (um, just check me on this, map_single returns a device bus address, not a processor bus address, right?) > The system will panic before pci_map_single() will fail. > The driver needs to remember some other way if a buffer was mapped or not. > Or the Documentation/DMA-mapping.txt should be changed - ie add this > to the interface definition and I can reserve the 1st mapping > entry so no-one uses it. we should probably have a BAD_DMA_ADDR define which that array should be initialised to. it's a little late in 2.4 to go through and audit all the drivers again. > Should I be mailing Jeff Garzik directly? > Or can someone who knows Jeff point this out to him? i've cc'd jeff & dave miller on this. -- Revolutions do not require corporate support. From davem@redhat.com Fri, 10 Nov 2000 02:16:11 -0800 Date: Fri, 10 Nov 2000 02:16:11 -0800 From: David S. Miller davem@redhat.com Subject: [parisc-linux] tulip DMA mapping Date: Fri, 10 Nov 2000 10:18:08 +0000 From: Matthew Wilcox > Should I be mailing Jeff Garzik directly? > Or can someone who knows Jeff point this out to him? i've cc'd jeff & dave miller on this. In 2.4.x there is _NO_ error return from the PCI dma functions except the consistent DMA mapping ones. This was an explicit design decision, the dynamic mapping functions should never fail, and if they do it is a hard error. Therefore no drivers need to check for failure, as far as they are concerned, there is no failure. So what is the issue? In 2.5.x I'll add an error return facility (BTW: -1 ie. 0xfffffff would probably work as an error value on all platforms :-) Later, David S. Miller davem@redhat.com From rhirst@linuxcare.com Fri, 10 Nov 2000 10:55:16 +0000 Date: Fri, 10 Nov 2000 10:55:16 +0000 From: Richard Hirst rhirst@linuxcare.com Subject: [parisc-linux] parisc-linux reaches uptimes in excess of one day! Just for interest... My A180 has been up for 25 hours, the first 12 of which I had a couple of telnet sessions open running vi, gcc, etc. and since then it has been looping doing kernel builds. I also ran cvs to update its kernel source tree from pehc. So far it has completed about 23 kernel builds with one hiccup: do_page_fault() pid=2420 command='cpp0' YZrvWESTHLNXBCVMcbcbcbcbOGFRQPDI PSW: 00000000000001100000000000001011 r0-3 00000000 4013ac38 400e134f 00000004 r4-7 40138c38 ffffffb5 2002014b 00000001 r8-11 00000004 00000000 00000000 4001ada0 r12-15 4001ad7c 0001b300 2001f601 00000001 r16-19 00012000 00000023 00000020 40138c38 r20-23 20020100 4012a51c 00000000 9999999a r24-27 2002016c 2002014c 00000004 00013d34 r28-31 00000000 4013a438 200201c0 40041757 sr0-4 00000000 00000011 00000000 00000011 sr4-8 00000011 00000011 00000011 00000011 IASQ: 00000011 00000011 IAOQ: 400e13b7 400e13bb IIR: 0c601094 ISR: 00000011 IOR: 00000004 ORIG_R28: 40019450 Richard From rhirst@linuxcare.com Fri, 10 Nov 2000 11:12:20 +0000 Date: Fri, 10 Nov 2000 11:12:20 +0000 From: Richard Hirst rhirst@linuxcare.com Subject: [parisc-linux] tulip DMA mapping I've quoted the whole of Grants message below, so you can see the context. It looks like tulip is treating zero as meaning it doesn't have anything to pci_unmap... Grant Grundler wrote: > Hi all, > I see a "bug" in tulip's usage of mapping services. > It's not the bug I was looking for unfortunately. > > In line 217 of drivers/net/tulip/interrupt.c: > > if (tp->tx_buffers[entry].mapping) > pci_unmap_single(tp->pdev, > tp->tx_buffers[entry].mapping, > sizeof(tp->setup_frame), > PCI_DMA_TODEVICE); > > 0 is a valid pci_map_single() return value when the system has an IO MMU. > > The system will panic before pci_map_single() will fail. > The driver needs to remember some other way if a buffer was mapped or not. > Or the Documentation/DMA-mapping.txt should be changed - ie add this > to the interface definition and I can reserve the 1st mapping > entry so no-one uses it. Richard On Fri, Nov 10, 2000 at 02:16:11AM -0800, David S. Miller wrote: > Date: Fri, 10 Nov 2000 10:18:08 +0000 > From: Matthew Wilcox > > > Should I be mailing Jeff Garzik directly? > > Or can someone who knows Jeff point this out to him? > > i've cc'd jeff & dave miller on this. > > In 2.4.x there is _NO_ error return from the PCI dma functions except > the consistent DMA mapping ones. > > This was an explicit design decision, the dynamic mapping functions > should never fail, and if they do it is a hard error. > > Therefore no drivers need to check for failure, as far as they are > concerned, there is no failure. > > So what is the issue? In 2.5.x I'll add an error return facility > (BTW: -1 ie. 0xfffffff would probably work as an error value on all > platforms :-) > > Later, > David S. Miller > davem@redhat.com > > --------------------------------------------------------------------------- > To unsubscribe: send e-mail to parisc-linux-request@thepuffingroup.com with > `unsubscribe' as the subject. > > From davem@redhat.com Fri, 10 Nov 2000 03:26:48 -0800 Date: Fri, 10 Nov 2000 03:26:48 -0800 From: David S. Miller davem@redhat.com Subject: [parisc-linux] tulip DMA mapping Date: Fri, 10 Nov 2000 11:12:20 +0000 From: Richard Hirst I've quoted the whole of Grants message below, so you can see the context. It looks like tulip is treating zero as meaning it doesn't have anything to pci_unmap... Thank you for the clarification. Jeff, this is in fact a bug, please fix :-) Later, David S. Miller davem@redhat.com From jgarzik@mandrakesoft.com Fri, 10 Nov 2000 09:30:41 -0500 Date: Fri, 10 Nov 2000 09:30:41 -0500 From: Jeff Garzik jgarzik@mandrakesoft.com Subject: [parisc-linux] tulip DMA mapping "David S. Miller" wrote: > > Date: Fri, 10 Nov 2000 11:12:20 +0000 > From: Richard Hirst > > I've quoted the whole of Grants message below, so you can see the > context. It looks like tulip is treating zero as meaning it > doesn't have anything to pci_unmap... > > Thank you for the clarification. > > Jeff, this is in fact a bug, please fix :-) np. Like Matthew(?) hinted, this is not the only place that needs fixing. I'll take care of it. Jeff -- Jeff Garzik | Building 1024 | Would you like a Twinkie? MandrakeSoft | From bame@riverrock.org Fri, 10 Nov 2000 08:57:47 -0700 Date: Fri, 10 Nov 2000 08:57:47 -0700 From: bame@riverrock.org bame@riverrock.org Subject: linux bame = On Thu, Nov 09, 2000 at 03:53:48PM -0700, Paul Bame wrote: = > Somebody never imported 2.4.0-test6, then I imported -test10 on the mai n = > vendor branch and now can't (easily) undo that to import test6 and THEN = > test10. This workaround sucks. = = don't use vendor branches. didn't you talk to mang about this? Um, I have no information to go on from your note. All the (successful) merges I've done before have used the cookbook CVS merge method including a vendor branch. Several (N-1?) of the palinux merges have been accompanied by updating the vendor branch. And this merge is going well despite the ugly workaround, or so it appears to me. Just importing files to a vendor branch should have no effect on anything else unless CVS has some horrible bug (RCS does not). Before I make what is apparently a serious mistake ("don't use vendor branches" sounds pretty serious) please enlighten me! -P From grundler@cup.hp.com Fri, 10 Nov 2000 08:29:25 -0800 Date: Fri, 10 Nov 2000 08:29:25 -0800 From: Grant Grundler grundler@cup.hp.com Subject: [parisc-linux] tulip DMA mapping Mathew, I think the situation is clarified. This is just FYI. Matthew Wilcox wrote: > On Thu, Nov 09, 2000 at 12:12:25PM -0800, Grant Grundler wrote: > > 0 is a valid pci_map_single() return value when the system has an IO MMU. > > Oh dear. You can bet tulip won't be the only driver which assumes it > isn't a valid return value. Well, then: 1) the driver writer made a wrong assumption that the "spec" does not support. 2) that wasn't the case here - 0 was used as a flag to indicate a mapping had (or hadn't rather) been done - not that the mapping call had failed. > Can't our IOMMU code be limited in such a > way that 0 is not a valid return value? Say, constrain all allocated > addresses to the top half of the device bus? It could pretty easily by reserving the dma_map[0] entry during init time. Dave Miller already made it clear that's not desirable. > (um, just check me on this, map_single returns a device bus address, > not a processor bus address, right?) Yes. It's the address a device must use to master DMA transactions. pci_map_single() input parameters are "struct pci_dev *", virtual host memory address, and buffer size. The return is a device specific I/O DMA address - ie this mapping cannot be shared with other devices. FWIW, "I/O DMA address" are called IOVAs in HPUX (I/O Virtual Address). The HW guys prefer another name but this one stuck. grant Grant Grundler Unix Systems Enablement Lab +1.408.447.7253 From bame@riverrock.org Fri, 10 Nov 2000 14:28:33 -0700 Date: Fri, 10 Nov 2000 14:28:33 -0700 From: bame@riverrock.org bame@riverrock.org Subject: [parisc-linux] kernel merge = = We're getting ready to do a kernel merge (to -test10 I think). Anybody = concerns before we get started? = I'm getting ready to commit the changes to merge us up to 2.4.0-test10 as soon as I'm confident 64-bit kernels are OK (32-bit seems fine). Here's a brief list of changes made (and yet to be made -- if anyone has the time/energy) to our parisc code (does not include changes in common code!). While there's plenty yet to do, I think we're no worse off than before the merge. Some parts of our parisc code are getting rather moldy compared to the other ports FYI. Important tags: LINUS_240_TEST6 Linus' 2.4.0-test6 LINUS_240_TEST10 Linus' 2.4.0-test10 LINUS_240_TEST10_PREMERGE Our tree before the -test10 merge LINUS_240_TEST10_MERGED Our tree after the -test10 merge ------------ Lots of 'extern __inline__' turned into 'static __inline__' and there are more to do (TODO). Beginnings of several smp_mb*() macros -- implemented as no-ops in the non-SMP case (asm/bitops.h, asm/system.h) SET_PERSONALITY() macro in asm/elf.h needs updating (TODO). fcntl.h acquired a 'struct fcntl64' used with 64-bit offsets, implementing fcntl(fd, F_S/GETLK[W]64, ...). Several other locking-related #defines added. asm/mmu_context.h:init_new_context() now returns int (always 0), not void. Should our asm/bitops.h routines be re-coded in assembly? (TODO) Added #define RLIMIT_LOCKS to asm/resource.h Added #define CLOCKS_PER_SEC to asm/param.h (how did we miss this one?) Our asm/string.h is behind the times. Fixing it might get rid of a bunch of compiler warnings! (TODO) Removed mktime from drivers/char/genrtc.c (it's in a header file now) x86 made a bunch of changes to asm-i386/floppy.h -- should we? (TODO) looks like maybe the get/put_user_ret() functions in asm/uaccess.h are obsolete? (TODO) We'll need to add the getdents64() and fcntl64() syscall glue. (TODO!!!) Our arch/parisc/config.in is in BAD SHAPE (TODO) arch/parisc/process.c: added new argsto do_fork() and copy_thread(). IA64 seems to use the copy_thread() arg. arch/parisc/signal.c: minor change to common data structure drivers/scsi sym53c8xx_comm.h #ifdef doesn't work on parisc -- eliminates unmap_pci_mem() causing link error (TODO - rhirst) From pjlahaie@linuxcare.com Fri, 10 Nov 2000 17:14:06 -0500 Date: Fri, 10 Nov 2000 17:14:06 -0500 From: Paul J.Y. Lahaie pjlahaie@linuxcare.com Subject: [parisc-linux] Beta CD --uXxzq0nDebZQVNAZ Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Hello fellow PA-RISCers, An preliminary beta CD for PA/Linux has been uploaded to puffin.external.hp.com. If people could try it and forward any complaints or suggestions to me, it would be greatly appreciated. The URL for the image is: ftp://puffin.external.hp.com/pub/parisc/cd-images/palinux-0.5.iso.gz - Paul --uXxzq0nDebZQVNAZ Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.4 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE6DHMu8ggPQthPCzcRAgb0AJ4jJs5VOnm+9aDXUbtwht7hxAa+UwCgihAo nEE25pYQwBwCDuALcSdyCNw= =bTuw -----END PGP SIGNATURE----- --uXxzq0nDebZQVNAZ-- From randolph@tausq.org Fri, 10 Nov 2000 19:18:47 -0700 Date: Fri, 10 Nov 2000 19:18:47 -0700 From: Randolph Chung randolph@tausq.org Subject: [parisc-linux] kernel merge > Our asm/string.h is behind the times. Fixing it might get rid of a > bunch of compiler warnings! (TODO) if this is just an issue of implementing the various parisc-optimized string routines, i've been working on this, but don't have everything ready yet. randolph -- @..@ http://www.TauSq.org/ (----) ( >__< ) ^^ ~~ ^^ From crypt@ihug.co.nz Sun, 12 Nov 2000 01:47:56 +1300 Date: Sun, 12 Nov 2000 01:47:56 +1300 From: crypt@ihug.co.nz crypt@ihug.co.nz Subject: [parisc-linux] HP 9000 e25 Considering how often this question comes up is there anyone out there that is interested in tracking down the info to port linux to this class of box. Server boxes may be classed as boring to some but there seem to be a large number of people who have at least one of them sitting about doing nothing. Joe. -- ======================================================================= in real life: Joseph Skinner |There's no such thing as a wizard email: crypt@ihug.co.nz |who minds his own business Analyst/Programmer | - Berengis the Black | Court Mage to the Earls Caeline ======================================================================== From snaketails@optushome.com.au Sat, 11 Nov 2000 23:57:43 +1100 Date: Sat, 11 Nov 2000 23:57:43 +1100 From: Rod Smart snaketails@optushome.com.au Subject: [parisc-linux] PA-RISC newbie Hi there. I just purchased at a **VERY** cheap price, a HP Visualize C-180 RISC system from a CAD drafting company, this box included a 4Gb Hard disk, a video card with unknown amount of memory (& daughter board, assuming its memory upgrade) and system board RAM is fully loaded (768Megs). I would like to run this system on Linux, and found the PA-RISC web site from the www.linux.org web site :o) The system currently has HP-UX installed, but not having any usernames or passwords, I cannot access the system from the prompt. I have read how to NFS-boot the HPbox from the message board, but I couldn't figgure out where to find the kernel sources (or how I would be able to compile them on the HPbox anyway). I downloaded the vmlinux kernel file from the ftp site and the NFS-ROOT and installed both on my current Linux box (Pentium 133 pre-MMX) in the format of how it was layed out in ... LINUX/PA-RISC NFSROOT HOWTO In there it states that you have to get the latest linux-2.3 tree from CVS, but which CVS server I'm curious about as the ones on ftp.kernel.org don't have "parisc" in the /arch/ branch, so where do I find the CVS "tree" that I need to use? I seem to have the "STEP 2." section running, as from playing with the system I had found my way into the PDC prompt and have played with the "boot" function. I tried to boot the installation CD (on a drive I have borrowed from work) of HP-UX and reinstall so I have access, as I don't really care whats currently on the system.. I'm not confident enough on how to create and burn a bootable CD to try and boot the box that way, I still think the vmlinux kernel I downloaded from the PA-RISC website has something to do with my problems (or the permissions) I do know that the Hp is talking to the Linux box (apart from the lack of logged info) I get a report in /var/log/secure and messages that the HP box has attempted a bootp session, but the HP box reports something along the lines that the booting code was not found. So, if anyone has any ideas on how to help me, I would be appreciated ;o) Oh, what *is* the RAM modules in the Hp systems anyway (apart from the obvious 64Mx72-pin SIMM) Thank you for your time and help :o) PS. I would prefer replies to my E-mail address as I generally forget to surf the net reading mailing lists.... From andrew@neep.com.au Sat, 11 Nov 2000 23:12:55 +0800 Date: Sat, 11 Nov 2000 23:12:55 +0800 From: Andrew Shugg andrew@neep.com.au Subject: [parisc-linux] HP 9000 e25 > Considering how often this question comes up is there anyone out there > that is interested in tracking down the info to port linux to this class > of box. > > Server boxes may be classed as boring to some but there seem to be a > large number of people who have at least one of them sitting about doing > nothing. > > Joe. I don't perceive the problem to be a lack of willingness, or interest, but has already been stated the older systems contain a lot of proprietry stuff that isn't sufficiently documented for people to work on. Maybe as the parisc port grows more popular and attracts more resources, some enthusiastic people will get it happening. =) Andrew. -- Andrew Shugg http://www.neep.com.au/ "Just remember, Mr Fawlty, there's always someone worse off than yourself." "Is there? Well I'd like to meet him. I could do with a good laugh." From grundler@cup.hp.com Sat, 11 Nov 2000 15:29:14 -0800 Date: Sat, 11 Nov 2000 15:29:14 -0800 From: Grant Grundler grundler@cup.hp.com Subject: [parisc-linux] HP 9000 e25 Andrew Shugg wrote: > > Considering how often this question comes up is there anyone out there > > that is interested in tracking down the info to port linux to this class > > of box. > > > > Server boxes may be classed as boring to some but there seem to be a > > large number of people who have at least one of them sitting about doing > > nothing. > > > > Joe. > > I don't perceive the problem to be a lack of willingness, or interest, but > has already been stated the older systems contain a lot of proprietry stuff > that isn't sufficiently documented for people to work on. AFIAK, the chipsets for I/O devices in E25 have plenty of documentation. The issue is someone has to clean them up and get a lawyer to approve their publication. It's all about IP and avoiding lawsuits. This has been discussed before. Any HP employees interested in doing this "on their own time" can contact me and I'll help locate unpublished docs. Note that PDC is the same for Nova-Class (EFGHI-class) boxes as for the workstations for the most part. So someone could start by just trying to boot those boxes and see how far it gets before dying. > Maybe as the parisc port grows more popular and attracts more resources, > some enthusiastic people will get it happening. =) Having worked on the HPUX SCSI driver (scsi3 and scsi1) for E25 and similar boxes, I question anyone's sanity who volunteers to write drivers for SPIFI chips - even with full documentation. I would rather give folks that interested in contributing a 715/33! (or my gosh /50's!) Yes - I know folks who collect PDP's and keep them running in their garage...'nuf said. grant Grant Grundler Unix Systems Enablement Lab +1.408.447.7253 From grundler@cup.hp.com Sat, 11 Nov 2000 15:38:58 -0800 Date: Sat, 11 Nov 2000 15:38:58 -0800 From: Grant Grundler grundler@cup.hp.com Subject: [parisc-linux] PA-RISC newbie Rod Smart wrote: > Hi there. > > I just purchased at a **VERY** cheap price, a HP Visualize C-180 > RISC system from a CAD drafting company, this box included a 4Gb Hard > disk, a video card with unknown amount of memory (& daughter board, > assuming its memory upgrade) and system board RAM is fully loaded > (768Megs). > > I would like to run this system on Linux, and found the PA-RISC web > site from the www.linux.org web site :o) > > The system currently has HP-UX installed, but not having any > usernames or passwords, I cannot access the system from the prompt. Yes you can. You just need to know how. Interrupt the boot process to get a "BOOT ADMIN" prompt (or whatever it's called - Boot Console Handler). Then "boot primary isl" (shortened to bo pri isl) You should have an "ISL>" prompt now. ISL> hpux -is And you will boot to single user state with a shell. mountall and you should have the regular tools too. vi /etc/passwd to your hearts content. "There is no such thing at security with out physical security". .. > I'm not confident enough on how to create and burn a bootable CD to > try and boot the box that way, I still think the vmlinux kernel I > downloaded from the PA-RISC website has something to do with my problems > (or the permissions) > You can dd the ISO image to a regular hard disk (ie /dev/sdc) and move that disk over to the C180. Then boot from that disk. From BCH, use "sea" to locate all boot devices. grant Grant Grundler Unix Systems Enablement Lab +1.408.447.7253 From randolph@tausq.org Sat, 11 Nov 2000 17:04:29 -0700 Date: Sat, 11 Nov 2000 17:04:29 -0700 From: Randolph Chung randolph@tausq.org Subject: [parisc-linux] glibc question I'm working with bdale and taggart to try to get the Debian glibc package to compile under hppa. One of the things I saw today while playing with this is that the build dies because it tries to link in bsd-setjmp.c and bsd-_setjmp.c, which both define setjmp. Can someone enlighten me about why this may be happening? This is built from the glibc-2.2 sources, which I understand has all/most of the changes in pehc cvs. randolph -- @..@ http://www.TauSq.org/ (----) ( >__< ) ^^ ~~ ^^ From rajak@purdue.edu Sat, 11 Nov 2000 22:58:57 -0500 (EST) Date: Sat, 11 Nov 2000 22:58:57 -0500 (EST) From: Brian Poole rajak@purdue.edu Subject: [parisc-linux] Problems booting new beta CD Hello, My machine is a 715/80 with 88M of RAM, 1G HD, external 4x CD drive & floppy. Trying to get the new palinux CD working on my 715/80 here and not having too much success. Did get the CD to actually boot, but after all the normal Linux init messages (which were very nice to see btw, congratulations on how far it has already gotten ;) it stops at 'Switching from PDC console'. Looking thru the FAQ I saw a somewhat similar question, in that it had 'pdc' in it & was booting from the CD (but the 0.1 CD, not the one I am using), that said the kernel on the CD booted from/to the serial console. Is this also true of the 0.5 CD? If so, what is necessary to boot one of these from console? I've been fooling with it to no success.. I have it automatically booting from the CD, but it doesn't actually boot. I replug in the monitor & keyboard and find that it can't boot without the keyboard ('Failed to initiliaze a keyboard\n SYSTEM HALTED').. How am I supposed to boot to the console if I can't boot w/o a keyboard? I imagine if it has a keyboard it will boot to the screen like a Sun. Thanks for the help, -b From grundler@cup.hp.com Sat, 11 Nov 2000 23:31:37 -0800 Date: Sat, 11 Nov 2000 23:31:37 -0800 From: Grant Grundler grundler@cup.hp.com Subject: [parisc-linux] Problems booting new beta CD Brian Poole wrote: ... > Looking thru the FAQ Brian, Thank you for first reading the FAQ! > I saw a somewhat similar question, in that it had > 'pdc' in it & was booting from the CD (but the 0.1 CD, not the one I am > using), that said the kernel on the CD booted from/to the > serial console. Is this also true of the 0.5 CD? I think it is. Is there a way via PALO to direct the console to FBCON or STICON or whatever it's called now? I had the impression *eventually* the boot console would be whatever PDC says it is - ie graphics console for the 712. > If so, what is necessary to boot one of these from console? kernel with CONFIG_STI_CONSOLE I think....but that's not enabled by default. It may not be possible to use the graphics console unless one builds a "custom" kernel. > I've been fooling with it to no > success.. I have it automatically booting from the CD, but it doesn't > actually boot. I replug in the monitor & keyboard and find that it can't > boot without the keyboard ('Failed to initiliaze a keyboard\n SYSTEM > HALTED').. How am I supposed to boot to the console if I can't boot w/o a > keyboard? I imagine if it has a keyboard it will boot to the screen like a > Sun. AFAIK, 712's are the only parisc workstations what won't boot w/o keyboard. All others will auto-switch to use serial console if the keyboard is not connected. Both or the above questions sounds like a FAQ. Could someone who knows more update/add those to the FAQ? thanks, grant ps. The most up-to-date FAQ is at parisc-linux.org/faq.html even though that's not officially online yet. > > Thanks for the help, > > -b > > > > --------------------------------------------------------------------------- > To unsubscribe: send e-mail to parisc-linux-request@thepuffingroup.com with > `unsubscribe' as the subject. > Grant Grundler Unix Systems Enablement Lab +1.408.447.7253 From alan@linuxcare.com.au Sun, 12 Nov 2000 23:08:35 +1100 (EST) Date: Sun, 12 Nov 2000 23:08:35 +1100 (EST) From: Alan Modra alan@linuxcare.com.au Subject: [parisc-linux] glibc question On Sat, 11 Nov 2000, Randolph Chung wrote: > I'm working with bdale and taggart to try to get the Debian glibc > package to compile under hppa. One of the things I saw today while > playing with this is that the build dies because it tries to link in > bsd-setjmp.c and bsd-_setjmp.c, which both define setjmp. Can someone > enlighten me about why this may be happening? I think bsd-_setjmp.c should define _setjmp, not setjmp. Alan Modra -- Linuxcare. Support for the Revolution. From andrew@neep.com.au Mon, 13 Nov 2000 00:40:15 +0800 Date: Mon, 13 Nov 2000 00:40:15 +0800 From: Andrew Shugg andrew@neep.com.au Subject: [parisc-linux] HP 9000 e25 Grant Grundler said: > AFIAK, the chipsets for I/O devices in E25 have plenty of > documentation. The issue is someone has to clean them up and get a > lawyer to approve their publication. My bad, I should've said "public documentation". =) *prods LC FAQ maintainers* Andrew. -- Andrew Shugg http://www.neep.com.au/ "Just remember, Mr Fawlty, there's always someone worse off than yourself." "Is there? Well I'd like to meet him. I could do with a good laugh." From randolph@tausq.org Sun, 12 Nov 2000 11:06:38 -0700 Date: Sun, 12 Nov 2000 11:06:38 -0700 From: Randolph Chung randolph@tausq.org Subject: [parisc-linux] glibc build fails / bash bug Bdale, taggart and I have been looking at trying to build glibc on hppa from Debian's sources. What we saw was that it looks like a lot of the syscalls were not being reocognized as such by one part of the build, so it tries to build things from the sysdeps/generic directory and fails. After a lot of digging, I *think* what is at fault is actually bash. It looks like during the build, a shell script (make-syscalls.sh) parses through syscalls.list to generate syscall stubs that are needed for the build to happen correctly, but these are not being generated. What it boils down to, I think, is this: (on hppa - bdale's J5K) ============================= tausq@j5k:/space/tausq $ bash --version GNU bash, version 2.04.0(1)-release (hppa-unknown-linux-gnu) Copyright 1999 Free Software Foundation, Inc. tausq@j5k:/space/tausq $ dpkg -l |grep bash ii bash 2.04-7 The GNU Bourne Again SHell tausq@j5k:/space/tausq $ cat test.sh #!/bin/sh echo "1 2 3 4 5 a b c d e " | while read a b c d e; do echo $a $b $c $d $e done tausq@j5k:/space/tausq $ /bin/bash test.sh 1 2 3 4 5 ============================= (on other archs, tested with i386 and sparc) samwise[11:06] ~% bash --version GNU bash, version 2.04.0(1)-release (i386-pc-linux-gnu) Copyright 1999 Free Software Foundation, Inc. samwise[11:06] ~% dpkg -l |grep bash ii bash 2.04-7 The GNU Bourne Again SHell samwise[11:06] ~% /bin/bash test.sh 1 2 3 4 5 a b c d e This causes the parsing routines to die quite miserably.... Anyone feel like trying to fix this? :-) randolph -- @..@ http://www.TauSq.org/ (----) ( >__< ) ^^ ~~ ^^ From pdbeal@louisville.edu Sun, 12 Nov 2000 14:27:28 -0500 Date: Sun, 12 Nov 2000 14:27:28 -0500 From: Phillip D. Beal pdbeal@louisville.edu Subject: [parisc-linux] Beta CD On Fri, Nov 10, 2000 at 05:14:06PM -0500, Paul J.Y. Lahaie wrote: > Hello fellow PA-RISCers, > > An preliminary beta CD for PA/Linux has been uploaded to > puffin.external.hp.com. If people could try it and forward any complaints > or suggestions to me, it would be greatly appreciated. The URL for the > image is: ftp://puffin.external.hp.com/pub/parisc/cd-images/palinux-0.5.iso.gz > > - Paul The kernel dumps on an HP755. Actually, how do you make these CD's? I know how to use mkisofs to crerat a filesystem CD, but how you make it bootable with a kernel image? Thanks, -- Phillip Beal Electrical and Computer Engineering S+LUG Vice-President From bame@riverrock.org Sun, 12 Nov 2000 13:27:32 -0700 Date: Sun, 12 Nov 2000 13:27:32 -0700 From: bame@riverrock.org bame@riverrock.org Subject: [parisc-linux] glibc build fails / bash bug = After a lot of digging, I *think* what is at fault is actually bash. Bash has a bunch of 'set' options, some shell variables, and probably some compile-time configure options, which affect its behavior, so I'd compare all those. One possibility is that the bash configure script on hppa configures bash to be more like Posix, since that's what hp-ux shell users expect. The construct in question: echo "a b c 1 2 3" | while read x1 x2 x3 *depends* on the way echo breaks or doesn't break lines, and the way read parses them. Often scripts like that also depend on whether the shell actually makes a new subprocess for the 'while' or it doesn't, because that determines whether variables set in the loop will still be set on exit from the loop. While I didn't find a way to make the construction fail, a safer method (when you get a choice) is to use 'set': set -- a b c \ 1 2 3 while [ $# != 0 ] do echo $1 $2 $3 shift 3 done -Paul "too much shell programming" Bame From bame@riverrock.org Sun, 12 Nov 2000 17:25:45 -0700 Date: Sun, 12 Nov 2000 17:25:45 -0700 From: bame@riverrock.org bame@riverrock.org Subject: [parisc-linux] kernel merge Helge noticed SCSI fails (B160L, 712, I think it's ok on c3k) after the -test10 merge. We have MANY differences from Linus in the SCSI area. Anybody want to take a look at this? FYI to get the pre-merge kernel you can use LINUS_240_TEST10_PREMERGE. Beware that tags are sticky in CVS (use cvs update -A to fix that). -P From catfish@alltel.net Sun, 12 Nov 2000 19:05:21 -0600 Date: Sun, 12 Nov 2000 19:05:21 -0600 From: catfish@alltel.net catfish@alltel.net Subject: [parisc-linux] Project Dead???? Hello, Its been so long since I've had an email I was curious if this has become a Dead project? Just curious. Terry -- catfish: icq #20116127 From bame@riverrock.org Sun, 12 Nov 2000 18:15:07 -0700 Date: Sun, 12 Nov 2000 18:15:07 -0700 From: bame@riverrock.org bame@riverrock.org Subject: [parisc-linux] Project Dead???? = Hello, = Its been so long since I've had an email I was curious if this has = become a Dead project? You might want to check the e-mail archives to see what you've been missing. I don't know why you haven't been receiving anything. The project is quite alive. http://www.parisc-linux.org/lists.html -P From bame@riverrock.org Sun, 12 Nov 2000 19:20:50 -0700 Date: Sun, 12 Nov 2000 19:20:50 -0700 From: bame@riverrock.org bame@riverrock.org Subject: [parisc-linux] kernel merge = = Helge noticed SCSI fails (B160L, 712, I think it's ok on c3k) = after the -test10 merge. Fixed. From test6 to test10 the SCSI host registration method changed. Updated sim700.c, lasi7xx.h, zalon7xx.h -P From grundler@cup.hp.com Sun, 12 Nov 2000 21:34:08 -0800 Date: Sun, 12 Nov 2000 21:34:08 -0800 From: Grant Grundler grundler@cup.hp.com Subject: [parisc-linux] Problems booting new beta CD Brian Poole wrote: > Quoting Grant Grundler (grundler@cup.hp.com) from 11 November 2000: > > Is there a way via PALO to direct the console to FBCON or STICON or > > whatever it's called now? > > > > I had the impression *eventually* the boot console would be whatever PDC > > says it is - ie graphics console for the 712. > > Working on a 715 here.. notice you refer to 712s throughout, hopefully we are > on the same page. Maybe 712s are identical to 715s, I don't have any idea, > just noticed the irregularity. For the most part yes. I had just assumed you were using a 712. > I meant to say 'from serial console' or something of the sort.. Serial console should just work. Shouldn't need an HIL keyboard connected though. > > > > I've been fooling with it to no > > > success.. I have it automatically booting from the CD, but it doesn't > > > actually boot. I replug in the monitor & keyboard and find that it can't > > > boot without the keyboard ('Failed to initiliaze a keyboard\n SYSTEM > > > HALTED').. How am I supposed to boot to the console if I can't boot w/o a > > > keyboard? I imagine if it has a keyboard it will boot to the screen like > a > > > Sun. > > > > AFAIK, 712's are the only parisc workstations what won't boot w/o keyboard. > > All others will auto-switch to use serial console if the keyboard > > is not connected > > Hmmm.. so I have manually switch it to use serial console? No. Just disconnect the keyboard before powering on the machine. Should end up with console on the serial interface. You may want to set the keyboard/console path to the serial port. This can be done from "BOOT_ADMIN>" prompt. The default kernel has "CONFIG_HIL=y". But since I don't test on boxes with HIL interfaces, I have no idea if a keyboard is required since the driver is enabled. It sounds like a bug if the 715 can't boot from serial console w/o HIL keyboard. grant Grant Grundler Unix Systems Enablement Lab +1.408.447.7253 From dhazeghi@pacbell.net Sun, 12 Nov 2000 21:34:19 -0800 Date: Sun, 12 Nov 2000 21:34:19 -0800 From: dhazeghi@pacbell.net dhazeghi@pacbell.net Subject: [parisc-linux] [Semi OT] SOM Linker Hello, I have been watching this project for some time and wanted to thank you guys for all the great work so far. The recent announcement of a BETA CD is highly encouraging. However I would like to know what work if any has been done on the SOM linker which HP released to the public last November(?). It seems that as of right now, it has not been touched since February 14, and the FSF binutils snapshots still do not have any SOM support for ld. Has there been any movement in merging this in, or is anybody working on this? Thanks. Dara Hazeghi From deller@gmx.de Mon, 13 Nov 2000 08:32:54 +0100 Date: Mon, 13 Nov 2000 08:32:54 +0100 From: Helge Deller deller@gmx.de Subject: [parisc-linux] kernel merge On Monday 13 November 2000 03:20, bame@riverrock.org wrote: > = > = Helge noticed SCSI fails (B160L, 712, I think it's ok on c3k) > = after the -test10 merge. > > Fixed. > > >From test6 to test10 the SCSI host registration method changed. > Updated sim700.c, lasi7xx.h, zalon7xx.h > > -P Thanks Paul, sim700 (53c710) now works again, but the second built-in controller (ncr/sym 53c8xx) still doesn't. Greetings, Helge From rhirst@linuxcare.com Mon, 13 Nov 2000 10:24:03 +0000 Date: Mon, 13 Nov 2000 10:24:03 +0000 From: Richard Hirst rhirst@linuxcare.com Subject: [parisc-linux] BEWARE: Makefile changed from parisc to parisc64 Confused me for a while, anyway. If you cvs update your kernel source and expect to build a 32 bit kernel, you need to edit the top level Makefile to change the arch := line. Richard From rhirst@linuxcare.com Mon, 13 Nov 2000 12:13:49 +0000 Date: Mon, 13 Nov 2000 12:13:49 +0000 From: Richard Hirst rhirst@linuxcare.com Subject: [parisc-linux] kernel merge On Fri, Nov 10, 2000 at 02:28:33PM -0700, bame@riverrock.org wrote: > drivers/scsi sym53c8xx_comm.h #ifdef doesn't work on parisc -- eliminates > unmap_pci_mem() causing link error (TODO - rhirst) Fixed. This relates to NVRAM that some PCI scsi cards have to hold config settings over reboot. CONFIG_SCSI_NCR53C8XX_NVRAM_DETECT is normally defined in sym53c8xx_defs.h to turn that code on. When I implemented Zalon (FWD) support I guessed that the 53c720 h/w wouldn't have NVRAM implemented the same way, and turned off NVRAM detect. I've also replaced a chunk of Zalon specific code that got lost in the merge, so Zalon/FWD/53c720 support works again. There is a problem remaining when using the driver as a module; it looks like something is trying to printk() from a string in the module after the module has been removed. Havn't tracked that down yet. Richard From adevries@linuxcare.com Mon, 13 Nov 2000 13:50:24 -0500 Date: Mon, 13 Nov 2000 13:50:24 -0500 From: Alex deVries adevries@linuxcare.com Subject: [parisc-linux] [Semi OT] SOM Linker dhazeghi@pacbell.net wrote: > However I would like to know what work if any has been done on the SOM > linker which HP released to the public last November(?). It seems that > as of right now, it has not been touched since February 14, and the FSF > binutils snapshots still do not have any SOM support for ld. Has there > been any movement in merging this in, or is anybody working on this? The initial plan was to do our 32-bit userspace with SOM, worrying about ELF32 much later in the game. But ELF32 development happened a lot quicker than expected, and so nobody's really done much on the SOM linker. I suspect it'd be very hard to use the SOM linker code to incorporate it into binutils, but I could be wrong. What are you actually trying to do? - Alex -- Alex deVries, Principal Solutions Architect, The Puffins at Linuxcare 613.562.2759 tel alex@linuxcare.com, http://www.linuxcare.com/ Linuxcare, Support for the revolution. From deller@gmx.de Mon, 13 Nov 2000 23:54:29 +0100 Date: Mon, 13 Nov 2000 23:54:29 +0100 From: Helge Deller deller@gmx.de Subject: sym53c8xx-driver (was: Re: [parisc-linux] kernel merge) On Monday 13 November 2000 13:13, Richard Hirst wrote: > On Fri, Nov 10, 2000 at 02:28:33PM -0700, bame@riverrock.org wrote: > > drivers/scsi sym53c8xx_comm.h #ifdef doesn't work on parisc -- eliminates > > unmap_pci_mem() causing link error (TODO - rhirst) > > Fixed. This relates to NVRAM that some PCI scsi cards have to hold > config settings over reboot. CONFIG_SCSI_NCR53C8XX_NVRAM_DETECT > is normally defined in sym53c8xx_defs.h to turn that code on. When > I implemented Zalon (FWD) support I guessed that the 53c720 h/w > wouldn't have NVRAM implemented the same way, and turned off > NVRAM detect. > > I've also replaced a chunk of Zalon specific code that got lost in > the merge, so Zalon/FWD/53c720 support works again. > > There is a problem remaining when using the driver as a module; > it looks like something is trying to printk() from a string in > the module after the module has been removed. Havn't tracked > that down yet. > > Richard Hi Richard, I'm sorry to say that the sym53c8xx still doesn't work on my B160L (32 bit-Kernel). It looks like the controller isn't detected at all, while it worked perfectly with 2.4.0-test6. Would you mind to take a look at the code again ? Thanks, Helge. From rhirst@linuxcare.com Mon, 13 Nov 2000 23:27:52 +0000 Date: Mon, 13 Nov 2000 23:27:52 +0000 From: Richard Hirst rhirst@linuxcare.com Subject: sym53c8xx-driver (was: Re: [parisc-linux] kernel merge) Hi Helge, The problem I fixed related to the ncr53c8xx driver (which shares code with sym53c8xx), and was to make 53c720 support work again. sym53c8xx worked for me on my A180. Please can you try booting with sym53c8xx=verb:7,debug:0xffff and send me the output? Thanks, Richard On Mon, Nov 13, 2000 at 11:54:29PM +0100, Helge Deller wrote: > On Monday 13 November 2000 13:13, Richard Hirst wrote: > > On Fri, Nov 10, 2000 at 02:28:33PM -0700, bame@riverrock.org wrote: > > > drivers/scsi sym53c8xx_comm.h #ifdef doesn't work on parisc -- eliminates > > > unmap_pci_mem() causing link error (TODO - rhirst) > > > > Fixed. This relates to NVRAM that some PCI scsi cards have to hold > > config settings over reboot. CONFIG_SCSI_NCR53C8XX_NVRAM_DETECT > > is normally defined in sym53c8xx_defs.h to turn that code on. When > > I implemented Zalon (FWD) support I guessed that the 53c720 h/w > > wouldn't have NVRAM implemented the same way, and turned off > > NVRAM detect. > > > > I've also replaced a chunk of Zalon specific code that got lost in > > the merge, so Zalon/FWD/53c720 support works again. > > > > There is a problem remaining when using the driver as a module; > > it looks like something is trying to printk() from a string in > > the module after the module has been removed. Havn't tracked > > that down yet. > > > > Richard > > > Hi Richard, > > I'm sorry to say that the sym53c8xx still doesn't work on my B160L (32 > bit-Kernel). It looks like the controller isn't detected at all, while it > worked perfectly with 2.4.0-test6. > Would you mind to take a look at the code again ? > > Thanks, > Helge. > From deller@gmx.de Tue, 14 Nov 2000 01:13:58 +0100 Date: Tue, 14 Nov 2000 01:13:58 +0100 From: Helge Deller deller@gmx.de Subject: sym53c8xx-driver (was: Re: [parisc-linux] kernel merge) --------------Boundary-00=_ABNZX5KGKOOFAA0B1BIM Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 8bit Subject: On Tuesday 14 November 2000 00:27, Richard Hirst wrote: > Hi Helge, > The problem I fixed related to the ncr53c8xx driver (which shares > code with sym53c8xx), and was to make 53c720 support work again. > sym53c8xx worked for me on my A180. Please can you try booting > with > > sym53c8xx=verb:7,debug:0xffff > > and send me the output? > > Thanks, > Richard Hi Richard, the output and the relevant part of .config is attached. Greetings, Helge --------------Boundary-00=_ABNZX5KGKOOFAA0B1BIM Content-Type: text/plain; name="log1" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="log1" Ci5jb25maWc6IAotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tCiMKIyBT Q1NJIHN1cHBvcnQKIwpDT05GSUdfU0NTST15CkNPTkZJR19CTEtfREVWX1NEPXkKQ09ORklHX1NE X0VYVFJBX0RFVlM9NDAKIyBDT05GSUdfQ0hSX0RFVl9TVCBpcyBub3Qgc2V0CkNPTkZJR19CTEtf REVWX1NSPXkKQ09ORklHX0JMS19ERVZfU1JfVkVORE9SPXkKQ09ORklHX1NSX0VYVFJBX0RFVlM9 MgpDT05GSUdfQ0hSX0RFVl9TRz15CkNPTkZJR19TQ1NJX01VTFRJX0xVTj15CkNPTkZJR19TQ1NJ X0NPTlNUQU5UUz15CgojCiMgU0NTSSBsb3ctbGV2ZWwgZHJpdmVycwojCkNPTkZJR19TQ1NJX0xB U0k9eQpDT05GSUdfU0NTSV9aQUxPTj15CkNPTkZJR19TQ1NJX1NZTTUzQzhYWD15CkNPTkZJR19T Q1NJX05DUjUzQzhYWF9ERUZBVUxUX1RBR1M9OApDT05GSUdfU0NTSV9OQ1I1M0M4WFhfTUFYX1RB R1M9MzIKQ09ORklHX1NDU0lfTkNSNTNDOFhYX1NZTkM9MjAKIyBDT05GSUdfU0NTSV9OQ1I1M0M4 WFhfUFJPRklMRSBpcyBub3Qgc2V0CiMgQ09ORklHX1NDU0lfTkNSNTNDOFhYX0lPTUFQUEVEIGlz IG5vdCBzZXQKCgotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0KCmJvb3QtbG9nOgotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tCgpGaXJtd2FyZSBWZXJzaW9uICA2LjEKCkR1cGxleCBDb25zb2xlIElPIERlcGVuZGVu dCBDb2RlIChJT0RDKSByZXZpc2lvbiAxCgpNZW1vcnkgVGVzdC9Jbml0aWFsaXphdGlvbiBDb21w bGV0ZWQgCgotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0KICAgKGMpIENvcHlyaWdodCAxOTk1LTE5OTgs IEhld2xldHQtUGFja2FyZCBDb21wYW55LCBBbGwgcmlnaHRzIHJlc2VydmVkCi0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLQoKICBQcm9jZXNzb3IgICBTcGVlZCAgICAgICAgICAgIFN0YXRlICAgICAgICAg ICBDb3Byb2Nlc3NvciBTdGF0ZSAgQ2FjaGUgU2l6ZQogIC0tLS0tLS0tLSAgLS0tLS0tLS0gICAt LS0tLS0tLS0tLS0tLS0tLS0tLS0gIC0tLS0tLS0tLS0tLS0tLS0tICAtLS0tLS0tLS0tCiAgICAg IDAgICAgICAxNjAgTUh6ICAgIEFjdGl2ZSAgICAgICAgICAgICAgICAgRnVuY3Rpb25hbCAgICAg ICAgICA2NCBLQgogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgIDEgTUIgZXh0CgoKICBBdmFpbGFibGUgbWVtb3J5IChieXRl cykgICAgOiAgNTM2ODcwOTEyIAogIEdvb2QgbWVtb3J5IHJlcXVpcmVkIChieXRlcyk6ICA1MzY4 NzA5MTIgCgogIFByaW1hcnkgYm9vdCBwYXRoOiAgICBGV1NDU0kuNi4wCiAgQWx0ZXJuYXRlIGJv b3QgcGF0aDogIExBTi4wLjAuMC4wLjAuMAogIENvbnNvbGUgcGF0aDogICAgICAgICBHUkFQSElD UygyKQogIEtleWJvYXJkIHBhdGg6ICAgICAgICBQUzIKCkNQVSAwCldBUk5JTkc6ICBTZWxmIHRl c3RzIGhhdmUgYmVlbiBkaXNhYmxlZCBhcyBhIHJlc3VsdCBvZiBGQVNUQk9PVAogICAgICAgICAg YmVpbmcgZW5hYmxlZC4gIFRvIGVuYWJsZSBzZWxmIHRlc3RzLCB1c2UgdGhlIEZBU1RCT09UCiAg ICAgICAgICBjb21tYW5kIGluIHRoZSBDT05GSUdVUkFUSU9OIG1lbnUgYW5kIHJlYm9vdCB0aGUg c3lzdGVtLgoKCi0tLS0tLS0gTWFpbiBNZW51IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0KCiAgICAgICAgQ29tbWFuZCAgICAgICAg ICAgICAgICAgICAgICAgICBEZXNjcmlwdGlvbgogICAgICAgIC0tLS0tLS0gICAgICAgICAgICAg ICAgICAgICAgICAgLS0tLS0tLS0tLS0KICAgICAgICBCT290IFtQUkl8QUxUfDxwYXRoPl0gICAg ICAgICAgIEJvb3QgZnJvbSBzcGVjaWZpZWQgcGF0aAogICAgICAgIFBBdGggW1BSSXxBTFR8Q09O fEtFWV0gWzxwYXRoPl0gRGlzcGxheSBvciBtb2RpZnkgYSBwYXRoCiAgICAgICAgU0VBcmNoIFtE SXNwbGF5fElQTF0gWzxwYXRoPl0gICBTZWFyY2ggZm9yIGJvb3QgZGV2aWNlcwoKICAgICAgICBD T25maWd1cmF0aW9uIFs8Y29tbWFuZD5dICAgICAgIEFjY2VzcyBDb25maWd1cmF0aW9uIG1lbnUv Y29tbWFuZHMKICAgICAgICBJTmZvcm1hdGlvbiBbPGNvbW1hbmQ+XSAgICAgICAgIEFjY2VzcyBJ bmZvcm1hdGlvbiBtZW51L2NvbW1hbmRzCiAgICAgICAgU0VSdmljZSBbPGNvbW1hbmQ+XSAgICAg ICAgICAgICBBY2Nlc3MgU2VydmljZSBtZW51L2NvbW1hbmRzCgogICAgICAgIERJc3BsYXkgICAg ICAgICAgICAgICAgICAgICAgICAgUmVkaXNwbGF5IHRoZSBjdXJyZW50IG1lbnUKICAgICAgICBI RWxwIFs8bWVudT58PGNvbW1hbmQ+XSAgICAgICAgIERpc3BsYXkgaGVscCBmb3IgbWVudSBvciBj b21tYW5kCiAgICAgICAgUkVTRVQgICAgICAgICAgICAgICAgICAgICAgICAgICBSZXN0YXJ0IHRo ZSBzeXN0ZW0KLS0tLS0tLQpNYWluIE1lbnU6IEVudGVyIGNvbW1hbmQgPiBibyBsYW4KSW50ZXJh Y3Qgd2l0aCBJUEwgKFksIE4sIFEpPz4gbgoKQm9vdGluZy4uLiAKTmV0d29yayBTdGF0aW9uIEFk ZHJlc3MgMDgwMDA5LWVmMzRmNQpTeXN0ZW0gSVAgQWRkcmVzcyAxOTIuMTY4LjEwMC4xNjAKU2Vy dmVyIElQIEFkZHJlc3MgMTkyLjE2OC4xMDAuMTAwCgpCb290IElPIERlcGVuZGVudCBDb2RlIChJ T0RDKSByZXZpc2lvbiAyCgoKSEFSRCBCb290ZWQuCnBhbG8gaXBsIHJvb3RAUDEwMCBUaHUgTm92 ICAyIDIwOjE0OjA4IE1FVCAyMDAwCjAvdm1saW51eCAyMjc0NzcxIGJ5dGVzIEAgMHg2ODAwCjAv cGFsby1jbWRsaW5lICcwL3ZtbGludXggSE9NRT0vIFRFUk09TElOVVggcm9vdD0vZGV2L25mcyBu ZnNyb290PTE5Mi4xNjguMTAwLjEwMDovdGZ0cGJvb3QvbmZzcm9vdCBjb25zb2xlPXR0eSBzeW01 M2M4eHg9dmVyYjo3LGRlYnVnOjB4ZmZmZicKS2VybmVsOiBwYXJ0aXRpb24gMCBmaWxlIC92bWxp bnV4CkVMRjMyIGV4ZWN1dGFibGUKCkVudHJ5IDAwMTAwMTkwIGZpcnN0IDAwMTAwMDAwIG4gNApT ZWdtZW50IDAgbG9hZCAwMDEwMDAwMCBzaXplIDE1MzQ2NjggbWVkaWFwdHIgMHgxMDAwClNlZ21l bnQgMSBsb2FkIDAwMjc4MDAwIHNpemUgMTgyMzQ0IG1lZGlhcHRyIDB4MTc4MDAwClNlZ21lbnQg MiBsb2FkIDAwMmE4MDAwIHNpemUgMTM5MTMyIG1lZGlhcHRyIDB4MWE1MDAwClNlZ21lbnQgMyBs b2FkIDAwMmNjMDAwIHNpemUgODE5MiBtZWRpYXB0ciAweDFjNzAwMApicmFuY2hpbmcgdG8ga2Vy bmVsIGVudHJ5IHBvaW50IDB4MDAxMDAxOTAKU2V0IGRlZmF1bHQgUFNXIFcgYml0IHRvIDAKUERD IENvbnNvbGUgSW5pdGlhbGl6ZWQKVGhlIDMyLWJpdCBLZXJuZWwgaGFzIHN0YXJ0ZWQuLi4KRW5h YmxlZCBGUCBjb3Byb2Nlc3NvcgpGcmVlIG1lbW9yeSBzdGFydHMgYXQ6IDB4YzAyZmQwMDAKc3Rh cnRfcGFyaXNjKDB4NTA0ZDZjLDB4NTA0ZDZjLDB4MCwweDApClBBTE8gY29tbWFuZCBsaW5lOiAn SE9NRT0vIFRFUk09TElOVVggcm9vdD0vZGV2L25mcyBuZnNyb290PTE5Mi4xNjguMTAwLjEwMDov dGZ0cGJvb3QvbmZzcm9vdCBjb25zb2xlPXR0eSBzeW01M2M4eHg9dmVyYjo3LGRlYnVnOjB4ZmZm ZicKUEFMTyBpbml0cmQgMC0wCm1vZGVsICAgMDAwMDUwMjAgMDAwMDA0ODEgMDAwMDAwMDAgMDIw MjAyMDIgNzc5NGQ3ZmUgMTAwMDAwZjAgMDAwMDAwMDQgMDAwMDAwYmEgMDAwMDAwYmEKdmVycyAg ICAwMDAwMDAwOApjcHVpZCAgIDAwMDAwMWU4CkNQVUlEIHZlcnMgMTUgcmV2IDgKU2VhcmNoaW5n IGZvciBkZXZpY2VzIGluIFBEQyBmaXJtd2FyZS4uLiBwcm9jZXNzb3IgaHBhIDB4ZmZmYmUwMDAK YSBuZXdlciBib3guLi4KRm91bmQgZGV2aWNlczoKMS4gUGhhbnRvbSBQc2V1ZG9CQyBHU0MrIFBv cnQgKDcpIGF0IDB4ZmZjMDAwMDAsIHZlcnNpb25zIDB4NTA0LCAweDAsIDB4MCwgMHgwLCAweDAK Mi4gTWVybGluIDE2MCBDb3JlIEZXLVNDU0kgKDQpIGF0IDB4ZmZmOGMwMDAsIHZlcnNpb25zIDB4 M2QsIDB4MCwgMHg4OSwgMHgwLCAweDgwCjMuIE1lcmxpbiBMMiAxNjAgKDkwMDAvNzc4L0IxNjBM KSAoMCkgYXQgMHhmZmZiZTAwMCwgdmVyc2lvbnMgMHg1MDIsIDB4MCwgMHg0LCAweDAsIDB4ODEK NC4gTWVybGluIDE2MC9UaHVuZGVySGF3ayBNZW1vcnkgKDEpIGF0IDB4ZmZmYmYwMDAsIHZlcnNp b25zIDB4NjcsIDB4MCwgMHg5LCAweDAsIDB4MAo1LiBNZXJsaW4gMTYwIENvcmUgQkEgKDExKSBh dCAweGZmZDAwMDAwLCB2ZXJzaW9ucyAweDNkLCAweDAsIDB4ODEsIDB4MCwgMHgwCjYuIE1lcmxp biAxNjAgQ29yZSBSUy0yMzIgKDEwKSBhdCAweGZmZDA1MDAwLCB2ZXJzaW9ucyAweDNkLCAweDAs IDB4OGMsIDB4MCwgMHgwCjcuIE1lcmxpbiAxNjAgQ29yZSBTQ1NJICgxMCkgYXQgMHhmZmQwNjAw MCwgdmVyc2lvbnMgMHgzZCwgMHgwLCAweDgyLCAweDAsIDB4MAo4LiBNZXJsaW4gMTYwIENvcmUg TGFuICg4MDIuMykgKDEwKSBhdCAweGZmZDA3MDAwLCB2ZXJzaW9ucyAweDNkLCAweDAsIDB4OGEs IDB4MCwgMHgwCjkuIE1lcmxpbiAxNjAgQ29yZSBDZW50cm9uaWNzICgxMCkgYXQgMHhmZmQwMjAw MCwgdmVyc2lvbnMgMHgzZCwgMHgwLCAweDc0LCAweDAsIDB4MAoxMC4gTWVybGluIDE2MCBDb3Jl IEF1ZGlvICgxMCkgYXQgMHhmZmQwNDAwMCwgdmVyc2lvbnMgMHgzZCwgMHg0LCAweDdiLCAweDAs IDB4MAoxMS4gTWVybGluIDE2MCBDb3JlIFBDIEtleWJvYXJkICgxMCkgYXQgMHhmZmQwODAwMCwg dmVyc2lvbnMgMHgzZCwgMHgwLCAweDg0LCAweDAsIDB4MAoxMi4gTWVybGluIDE2MCBDb3JlIFBD IEtleWJvYXJkICgxMCkgYXQgMHhmZmQwODEwMCwgdmVyc2lvbnMgMHgzZCwgMHgwLCAweDg0LCAw eDAsIDB4MAoxMy4gTWVybGluIDE2MCBXYXggQkEgKDExKSBhdCAweGZmZTAwMDAwLCB2ZXJzaW9u cyAweDQxLCAweDAsIDB4OGUsIDB4MCwgMHgwCjE0LiBNZXJsaW4gMTYwIFdheCBFSVNBIEJBICgx MSkgYXQgMHhmYzAwMDAwMCwgdmVyc2lvbnMgMHg0MSwgMHgwLCAweDkwLCAweDAsIDB4MAoxNS4g TWVybGluIDE2MCBXYXggSElMICgxMCkgYXQgMHhmZmUwMTAwMCwgdmVyc2lvbnMgMHg0MSwgMHgw LCAweDczLCAweDAsIDB4MAoxNi4gTWVybGluIDE2MCBXYXggUlMtMjMyICgxMCkgYXQgMHhmZmUw MjAwMCwgdmVyc2lvbnMgMHg0MSwgMHgwLCAweDhjLCAweDAsIDB4MAoxNy4gQ29yYWwgU0dDIEdy YXBoaWNzICgxMCkgYXQgMHhmNDAwMDAwMCwgdmVyc2lvbnMgMHg0LCAweDAsIDB4NzcsIDB4MCwg MHgwCjE4LiBHZWNrbyBHU0MgQ29yZSBHcmFwaGljcyAoMTApIGF0IDB4ZjgwMDAwMDAsIHZlcnNp b25zIDB4MTYsIDB4MCwgMHg4NSwgMHgwLCAweDAKMTkuIERpbm8gUENJIEJyaWRnZSAoMTMpIGF0 IDB4ZmZmODAwMDAsIHZlcnNpb25zIDB4NjgwLCAweDAsIDB4YSwgMHgwLCAweDAKVGhhdCdzIGEg dG90YWwgb2YgMTkgZGV2aWNlcy4KQ1BVKHMpOiAxIHggUEE3MzAwTEMgKFBDWC1MMikgYXQgMTYw LjAwMDAwMCBNSHoKTGludXggdmVyc2lvbiAyLjQuMC10ZXN0MTAgKHJvb3RAUDEwMCkgKGdjYyB2 ZXJzaW9uIDIuOTYgMjAwMDA5MjUgKGV4cGVyaW1lbnRhbCkpICMxNSBUdWUgTm92IDE0IDAxOjAx OjMzIE1FVCAyMDAwCmZyZWVfYm9vdG1lbSgweDMwMTAwMCwgMHgxZmNmZjAwMCkKaW5pdHJkOiAw MDAwMDAwMC0wMDAwMDAwMApwYWdldGFibGVfaW5pdApPbiBub2RlIDAgdG90YWxwYWdlczogMTMx MDcyCnpvbmUoMCk6IDY1NTM2IHBhZ2VzLgp6b25lKDEpOiA2NTUzNiBwYWdlcy4Kem9uZSgyKTog MCBwYWdlcy4KS2VybmVsIGNvbW1hbmQgbGluZTogSE9NRT0vIFRFUk09TElOVVggcm9vdD0vZGV2 L25mcyBuZnNyb290PTE5Mi4xNjguMTAwLjEwMDovdGZ0cGJvb3QvbmZzcm9vdCBjb25zb2xlPXR0 eSBzeW01M2M4eHg9dmVyYjo3LGRlYnVnOjB4ZmZmZgp0cmFwX2luaXQKQ29uc29sZTogY29sb3Vy IGR1bW15IGRldmljZSA4MHgyNQpyZWdpc3Rlcl9jb25zb2xlCkNhbGlicmF0aW5nIGRlbGF5IGxv b3AuLi4gMTA2LjUwIEJvZ29NSVBTCk1lbW9yeTogNTEwOTQ0ayBhdmFpbGFibGUKRGVudHJ5LWNh Y2hlIGhhc2ggdGFibGUgZW50cmllczogNjU1MzYgKG9yZGVyOiA3LCA1MjQyODggYnl0ZXMpCkJ1 ZmZlci1jYWNoZSBoYXNoIHRhYmxlIGVudHJpZXM6IDMyNzY4IChvcmRlcjogNSwgMTMxMDcyIGJ5 dGVzKQpQYWdlLWNhY2hlIGhhc2ggdGFibGUgZW50cmllczogMTMxMDcyIChvcmRlcjogNywgNTI0 Mjg4IGJ5dGVzKQpJbm9kZS1jYWNoZSBoYXNoIHRhYmxlIGVudHJpZXM6IDMyNzY4IChvcmRlcjog NiwgMjYyMTQ0IGJ5dGVzKQpQT1NJWCBjb25mb3JtYW5jZSB0ZXN0aW5nIGJ5IFVOSUZJWApMYXNp IHZlcnNpb24gMCBhdCAweGZmZDAwMDAwIGZvdW5kLgpXYXggYXQgMHhmZmUwMDAwMCBmb3VuZC4K V2F4OiBISUwgS2V5Ym9hcmQtTk1JIHJlZ2lzdGVyZWQuCnBhcnBvcnQwOiBQQy1zdHlsZSBhdCAw eGZmZDAyODAwLCBpcnEgODggW1BDU1BQLFRSSVNUQVRFXQpGb3VuZCBpODI1OTYgYXQgMHhmZmQw NzAwMCwgSVJRIDg3CmVhcmx5IGluaXRpYWxpemF0aW9uIG9mIGRldmljZSBldGgwIGlzIGRlZmVy cmVkCkluaXRpYWxpemluZyBMYXNpIFBTLzIta2V5Ym9hcmQgcG9ydCBhdCAweGZmZDA4MDAwLi4u ClN1cHBvcnQgZm9yIExhc2kgUFMvMi1wc2F1eCBub3QgeWV0IGF2YWlsYWJsZSAhCkZvdW5kIEhJ TCBhdCAweGZmZTAxMDAwLCBJUlEgMTI2Ck5vIGhhbmRsZXIgZm9yIGludGVycnVwdCAzNSAhCkhJ TDogdGltZWQgb3V0LCBhc3N1bWluZyBubyBrZXlib2FyZCBwcmVzZW50LgpXYXJuaW5nIDogZGV2 aWNlICgxMCwgMHg0MSwgMHgwLCAweDczLCAweDApIE5PVCBjbGFpbWVkIGJ5IEhJTCA3MTIsIDcx NSBvciBzaW1pbGlhcgpEaW5vIHZlcnNpb24gMi4wIChicmlkZ2UgbW9kZSkgZm91bmQgYXQgMHhm ZmY4MDAwMAoKClRoZSBHU0N0b1BDSSAoRGlubyBocmV2IDApIGJ1cyBjb252ZXJ0ZXIgZm91bmQg bWF5IGV4aGliaXQKZGF0YSBjb3JydXB0aW9uLiAgU2VlIFNlcnZpY2UgTm90ZSBOdW1iZXJzOiBB NDE5MEEtMDEsIEE0MTkxQS0wMS4KU3lzdGVtcyBzaGlwcGVkIGFmdGVyIEF1ZyAyMCwgMTk5NyB3 aWxsIG5vdCBleGhpYml0IHRoaXMgcHJvYmxlbS4KTW9kZWxzIGFmZmVjdGVkOiBDMTgwLCBDMTYw LCBDMTYwTCwgQjE2MEwsIGFuZCBCMTMyTCB3b3Jrc3RhdGlvbnMuCgpkaW5vX2JyaWRnZV9pbml0 OiBJT19BRERSX0VOIGhhc24ndCBiZWVuIGNvbmZpZ3VyZWQuCmtlcm5lbCBCVUcgYXQgZGluby5j OjY0NiEKTGludXggTkVUNC4wIGZvciBMaW51eCAyLjQKQmFzZWQgdXBvbiBTd2Fuc2VhIFVuaXZl cnNpdHkgQ29tcHV0ZXIgU29jaWV0eSBORVQzLjAzOQpTdGFydGluZyBrc3dhcGQgdjEuOApzdGlm Yi5jOiBzZWFyY2hpbmcgZm9yIHdvcmQgbW9kZSBTVEkgUk9Ncwpmb3VuZCBwb3RlbnRpYWwgU1RJ IFJPTSBhdCBmNDAwMDAwMApTVEkgYnl0ZSBtb2RlIFJPTSBhdCBmNDAwMDAwMCwgaWdub3JlZApm b3VuZCBwb3RlbnRpYWwgU1RJIFJPTSBhdCBmODAwMDAwMApwdHk6IDI1NiBVbml4OTggcHR5cyBj b25maWd1cmVkCmxwMDogdXNpbmcgcGFycG9ydDAgKGludGVycnVwdC1kcml2ZW4pLgpSQU1ESVNL IGRyaXZlciBpbml0aWFsaXplZDogMTYgUkFNIGRpc2tzIG9mIDQwOTZLIHNpemUgMTAyNCBibG9j a3NpemUKZXRoMDogODI1OTYgYXQgMHhmZmQwNzAwMCwgMDggMDAgMDkgRUYgMzQgRjUgSVJRIDg3 Lgo4MjU5Ni5jICRSZXZpc2lvbjogMS4xNCAkClNlcmlhbCBkcml2ZXIgdmVyc2lvbiA1LjAyICgy MDAwLTA4LTA5KSB3aXRoIE1BTllfUE9SVFMgU0hBUkVfSVJRIFNFUklBTF9QQ0kgZW5hYmxlZAp0 dHlTMDAgYXQgaW9tZW0gMHhmZmQwNTgwMCAoaXJxID0gOTApIGlzIGEgMTY1NTBBCnR0eVMwMSBh dCBpb21lbSAweGZmZTAyODAwIChpcnEgPSAxMjEpIGlzIGEgMTY1NTBBCkdlbmVyaWMgUlRDIERy aXZlciB2MS4wMiAwNS8yNy8xOTk5IFNhbSBDcmVhc2V5IChzYW1teUBvaC52ZXJpby5jb20pClND U0kgc3Vic3lzdGVtIGRyaXZlciBSZXZpc2lvbjogMS4wMApzaW03MDA6IENvbmZpZ3VyaW5nIDUz YzcxMCAoU0NTSS1JRCA3KSBhdCBmZmQwNjEwMCwgSVJRIDg2CnNjc2kwOiBSZXZpc2lvbiAweDIK UG9zdCB0ZXN0MSwgaXN0YXQgMDEsIHNzdGF0MCAwMCwgZHN0YXQgODQKc2ltNzAwOiBXQVJOSU5H IElSUSBwcm9iZSBmYWlsZWQsIChyZXR1cm5lZCAwKQpzY3NpMDogR29vZCwgdGFyZ2V0IGRhdGEg YXJlYXMgYXJlIGRtYSBjb2hlcmVudApzY3NpMDogdGVzdCAxIGNvbXBsZXRlZCBvay4Kc2NzaTA6 IHNpbTcwMF9pbnRyX2hhbmRsZSgpIGNhbGxlZCB3aXRoIG5vIGludGVycnVwdApzY3NpMCA6IExB U0kvU2ltcGxlIDUzYzd4eAogIFZlbmRvcjogUElPTkVFUiAgIE1vZGVsOiBDRC1ST00gRFItVTEy WCAgICBSZXY6IDEuMDYKICBUeXBlOiAgIENELVJPTSAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgQU5TSSBTQ1NJIHJldmlzaW9uOiAwMgpEZXRlY3RlZCBzY3NpIENELVJPTSBzcjAgYXQgc2Nz aTAsIGNoYW5uZWwgMCwgaWQgMCwgbHVuIDAKc3IwOiBzY3NpMy1tbWMgZHJpdmU6IDEyeC8xMngg eGEvZm9ybTIgY2RkYSB0cmF5ClVuaWZvcm0gQ0QtUk9NIGRyaXZlciBSZXZpc2lvbjogMy4xMQpz ZWFyY2hpbmcgZm9yIHdvcmQgbW9kZSBTVEkgUk9Ncwpmb3VuZCBwb3RlbnRpYWwgU1RJIFJPTSBh dCBmNDAwMDAwMApTVEkgYnl0ZSBtb2RlIFJPTSBhdCBmNDAwMDAwMCwgaWdub3JlZApmb3VuZCBw b3RlbnRpYWwgU1RJIFJPTSBhdCBmODAwMDAwMApzZWFyY2hpbmcgZm9yIGJ5dGUgbW9kZSBTVEkg Uk9Ncwpmb3VuZCBwb3RlbnRpYWwgU1RJIFJPTSBhdCBmNDAwMDAwMApTVEkgYnl0ZSBtb2RlIFJP TSB0eXBlIDEKIHN1cHBvcnRzIDE1IG1vbml0b3JzCiBjb25mb3JtcyB0byBTVEkgUk9NIHNwZWMg cmV2aXNpb24gOC4wNwpkdW1wX3N0aV9yb206IDUwMAogZ3JhcGhpY3MgaWQgMmQwOGMwYTcwOWEw MjU4NwpkdW1wX3N0aV9yb206IDUxMAogZm9udCBzdGFydCAwMDAxODNjMwpkdW1wX3N0aV9yb206 IDUxMgogcmVnaW9uIGxpc3QgMDAwMTgzNjMKZHVtcF9zdGlfcm9tOiA1MTQKIGluaXRfZ3JhcGgg MDAwMDFhNjMKZHVtcF9zdGlfcm9tOiA1MTYKIGFsdGVybmF0ZSBjb2RlIHR5cGUgMApkdW1wX3N0 aV9yb206IDUxOApuZXh0IGZvbnQgMDAwMDQwNDAKZjQwMDAwMDAgYgpmODAwMDAwMCBiClN3aXRj aGluZyBmcm9tIFBEQyBjb25zb2xlCg== --------------Boundary-00=_ABNZX5KGKOOFAA0B1BIM-- From rhirst@linuxcare.com Tue, 14 Nov 2000 10:17:04 +0000 Date: Tue, 14 Nov 2000 10:17:04 +0000 From: Richard Hirst rhirst@linuxcare.com Subject: sym53c8xx-driver (was: Re: [parisc-linux] kernel merge) Hi Helge, On Tue, Nov 14, 2000 at 01:13:58AM +0100, Helge Deller wrote: > On Tuesday 14 November 2000 00:27, Richard Hirst wrote: > > Hi Helge, > > The problem I fixed related to the ncr53c8xx driver (which shares > > code with sym53c8xx), and was to make 53c720 support work again. > > sym53c8xx worked for me on my A180. Please can you try booting > > with > > > > sym53c8xx=verb:7,debug:0xffff > > > > and send me the output? > > > > Thanks, > > Richard > > > Hi Richard, > > the output and the relevant part of .config is attached. > > Greetings, > > Helge Thanks. I agree it doesn't look like the driver is even seeing the chip; I wonder if PCI support is broken... > dino_bridge_init: IO_ADDR_EN hasn't been configured. > kernel BUG at dino.c:646! Does it usually say that on bootup? Richard From matthew@wil.cx Tue, 14 Nov 2000 10:29:36 +0000 Date: Tue, 14 Nov 2000 10:29:36 +0000 From: Matthew Wilcox matthew@wil.cx Subject: [parisc-linux] kernel merge On Fri, Nov 10, 2000 at 02:28:33PM -0700, bame@riverrock.org wrote: > fcntl.h acquired a 'struct fcntl64' used with 64-bit offsets, implementing > fcntl(fd, F_S/GETLK[W]64, ...). Several other locking-related #defines added. > > We'll need to add the getdents64() and fcntl64() syscall glue. (TODO!!!) actually, we don't. Linux/PA-RISC has sufficiently wide data types already so we don't have the grot required in other ports to support the appropriate wide data types. > looks like maybe the get/put_user_ret() functions in asm/uaccess.h are > obsolete? (TODO) yes, they are. exterminate! exterminate! -- Revolutions do not require corporate support. From deller@gmx.de Tue, 14 Nov 2000 14:11:42 +0100 (MET) Date: Tue, 14 Nov 2000 14:11:42 +0100 (MET) From: Helge Deller deller@gmx.de Subject: sym53c8xx-driver (was: Re: [parisc-linux] kernel merge) > Hi Helge, > > On Tue, Nov 14, 2000 at 01:13:58AM +0100, Helge Deller wrote: > > On Tuesday 14 November 2000 00:27, Richard Hirst wrote: > > > Hi Helge, > > > The problem I fixed related to the ncr53c8xx driver (which shares > > > code with sym53c8xx), and was to make 53c720 support work again. > > > sym53c8xx worked for me on my A180. Please can you try booting > > > with > > > > > > sym53c8xx=verb:7,debug:0xffff > > > > > > and send me the output? > > > > > > Thanks, > > > Richard > > > > > > Hi Richard, > > > > the output and the relevant part of .config is attached. > > > > Greetings, > > > > Helge > > Thanks. I agree it doesn't look like the driver is even seeing the > chip; I wonder if PCI support is broken... > > > dino_bridge_init: IO_ADDR_EN hasn't been configured. > > kernel BUG at dino.c:646! > > Does it usually say that on bootup? Yep. Has always been there, but nevertheless the scsi-driver worked before. FYI: The non-pci sim700-driver also didn't showed up before pb fixed it in CVS with a few one-line-patches. NB: Could maybe someone (ggg?) explain me the kernel-bug mentioned above ? > > Richard > Greetings, Helge -- Sent through GMX FreeMail - http://www.gmx.net From grundler@cup.hp.com Tue, 14 Nov 2000 08:10:42 -0800 Date: Tue, 14 Nov 2000 08:10:42 -0800 From: Grant Grundler grundler@cup.hp.com Subject: [parisc-linux] dino maintainer? Anyone interested in maintaining Dino? I don't have time for it and all the docs are on the web. One of the "TODO" things is to convert dino.c to use struct pci_hba the same way lba_pci.c does.... Richard Hirst wrote: ... > Thanks. I agree it doesn't look like the driver is even seeing the > chip; I wonder if PCI support is broken... > > > dino_bridge_init: IO_ADDR_EN hasn't been configured. > > kernel BUG at dino.c:646! > > Does it usually say that on bootup? per Helge's request: The bug is normal for card-mode Dino - not for Built-in Dino. I think Helge has the GSC 100BT card which is a card-mode Dino on-board with one (or two) Tulip(s) behind it. The warning is a reminder one can NOT use MMIO accesses to those PCI devices and *only* I/O Port space (eg inb/outb). If someone wants to fix the warning so it's quiet for card-mode devices...see is_card_dino(d) in dino_driver_callback() for an example. FYI - card-mode dino was used for several different networking interfaces but not SCSI interfaces. hope this helps, grant Grant Grundler Unix Systems Enablement Lab +1.408.447.7253 From bame@noam.fc.hp.com Tue, 14 Nov 2000 09:35:01 -0700 Date: Tue, 14 Nov 2000 09:35:01 -0700 From: Paul Bame bame@noam.fc.hp.com Subject: [parisc-linux] CVS linux Vs. -test10 I've attached an overview of differences between our CVS linux sources following the -test10 merge and the upstream -test10 sources. This document is also at http://puffin.external.hp.com/~bame/diff.html The raw 'diff' output (now a bit out of date) is at http://puffin.external.hp.com/~bame/diff.out If anyone gets bored, this list is full of small (and not so small) tasks which range from very simple (drivers/block/rd.c) to fairly complex (scripts/*). -P palinux Vs. linux 2.4.0-test10 Here's a brief summary of the differences in common code between palinux (tag: LINUS_240_TEST10_MERGED) and the upstream -test10 sources. The full diff output is in diff.out. NOTE this does not include machine-depend differences * Minor changes in several locations to support GSC * Minor top-level Makefile hacks, though the CFLAGS one is quite important. * Lots of RCS $Revision$ differences in ACPI (a different 'cvs import' would've eliminated these differences). * drivers/block/rd.c: obsolete debug code for parisc64. Changed a constant from 0xffffffffL to 0xffffffffUL because of a parisc64 gcc bug initializing longs. The repaired code is probably "more correct" anyway. * drivers/char/Config.in: changes to support LASI, parisc real-time clock (CONFIG_GENRTC) * drivers/char/Makefile: Config-related changes to support HP keyboards and RTC * drivers/char/console.c: looks like dead or dying experimental parisc code -- probably should be removed. Also some parisc-specific comments and format changes which should disappear. * drivers/char/serial.c: support for GSC and A500 serial * drivers/net/Makefile,Space.c: mostly LASI LAN support * drivers/net/eepro100.c: no clue about this one * drivers/net/tulip/interrupt.c: workaround for a B180+busy-lan boot problem -- probably should be sent upstream. * drivers/net/tulip/tulip_core.c: required #ifdef for hppa, also printk() changes which appear valid * drivers/parport/Makefile: GSC * drivers/parport/parport_gsc.c: New file for palinux -- GSC parallel ports -- required * drivers/pci/pci.c: eh? Grant? * drivers/pci/setup-bus.c: function definition tweek -- Grant? * drivers/scsi: Lots of changes here -- rhirst? See for yourself. Basics: support LASI and Zalon scsi, changes to 53c8xx drivers, rename sim7x0 to sim710 * drivers/sound: support for HP "Harmony" sound * drivers/video: STI and HP FB video drivers (iodccon is probably worthless) * fs: add support for SOM executables * fs/binfmt_elf.c,exec.c: changes for stack-grows-up? * fs/nfs/read.c: probably unnecessary hack for broken parisc64 gcc * fs/proc/array.c: ?? something with signals ?? * fs/stat.c: added __hppa__ to several #ifdefs * include/linux/binfmts.h,fs.h,kernel.h,tty.h,udf_fs_sb.h: unnecessary differences? * include/linux/init.h: we use different section names -- why????, probably some unnecessary other differences too * include/linux/mm.h: VM_STACK_FLAGS difference -- jsm? * include/linux/wait.h: parisc debugging -- should be removed * init/main.c: KWDB and GSC support plus a bunch of stuff which should probably go away. * kernel/Makefile,dma.c,fork.c,printk.c: eh? * kernel/module.c: possible parisc-needed changes * kernel/signal.c: unknown signal-related differences * lib/inflate.c: changed some constants to work around parisc64 gcc bug * mm/mprotect.c: ? * scripts/*: MANY differences here. Looks like a combination of things we hacked to fix configuration problems plus MAYBE not updating these files from new Linux versions in the past. 'make menuconfig' is significantly different from upstream. Even the mkdep.c program is different. From bame@noam.fc.hp.com Tue, 14 Nov 2000 10:02:06 -0700 Date: Tue, 14 Nov 2000 10:02:06 -0700 From: Paul Bame bame@noam.fc.hp.com Subject: [parisc-linux] kernel merge = On Fri, Nov 10, 2000 at 02:28:33PM -0700, bame@riverrock.org wrote: = > fcntl.h acquired a 'struct fcntl64' used with 64-bit offsets, implementing = > fcntl(fd, F_S/GETLK[W]64, ...). Several other locking-related #defines add ed. = > = > We'll need to add the getdents64() and fcntl64() syscall glue. (TODO!!!) = = actually, we don't. Linux/PA-RISC has sufficiently wide data types = already so we don't have the grot required in other ports to support = the appropriate wide data types. Ok that sounds great but I need a clue how to see it. struct flock contains an off_t which is 32 bits on narrow (wide too at the moment, but that will probably change). Also, struct dirent contains a 32-bit inode and a __kernel_off_t offset (d_off), which is also 32 bits narrow. I did see the ... in our fcntl() syscall definition so I'll go check glibc to see what's happening there. I wouldn't be so picky except that I need to write the 32/64 syscall translators for these soon! Thanks! -P From bame@noam.fc.hp.com Tue, 14 Nov 2000 10:14:51 -0700 Date: Tue, 14 Nov 2000 10:14:51 -0700 From: Paul Bame bame@noam.fc.hp.com Subject: [parisc-linux] kernel merge = On Fri, Nov 10, 2000 at 02:28:33PM -0700, bame@riverrock.org wrote: = > fcntl.h acquired a 'struct fcntl64' used with 64-bit offsets, implementing = > fcntl(fd, F_S/GETLK[W]64, ...). Several other locking-related #defines add ed. = > = > We'll need to add the getdents64() and fcntl64() syscall glue. (TODO!!!) = = actually, we don't. Linux/PA-RISC has sufficiently wide data types = already so we don't have the grot required in other ports to support = the appropriate wide data types. Oh, and won't we have to support these syscalls anyway, because user programs will make them? I suppose we could #define them in libc headers. = > looks like maybe the get/put_user_ret() functions in asm/uaccess.h are = > obsolete? (TODO) = = yes, they are. exterminate! exterminate! Done From pdbeal@louisville.edu Tue, 14 Nov 2000 13:40:24 -0500 Date: Tue, 14 Nov 2000 13:40:24 -0500 From: Phillip D. Beal pdbeal@louisville.edu Subject: [parisc-linux] 735/755 and Kernel test10.. Hey, I've been working on the 735 and 755 that I has access to and so far the systems booted the test6 kernel, but scrambled the console as soon as init was run. So, I figured I'd try the new test10 kernel that you have added. Both system boot, and then stop at this line: branching to kernel entry point 0x00100000 Can't select default wide mode, PDC_PSW call does not work What does the above actually mean? How can I remove the PDC_PSW call from the kernel so it can boot? I have plans to test this new kernel image on a 715 later today. Thanks, -- Phillip Beal Electrical and Computer Engineering S+LUG Vice-President From grundler@cup.hp.com Tue, 14 Nov 2000 10:51:26 -0800 Date: Tue, 14 Nov 2000 10:51:26 -0800 From: Grant Grundler grundler@cup.hp.com Subject: [parisc-linux] 735/755 and Kernel test10.. "Phillip D. Beal" wrote: > Hey, > > I've been working on the 735 and 755 that I has access to and so far > the systems booted the test6 kernel, but scrambled the console as soon > as init was run. So, I figured I'd try the new test10 kernel that you > have added. Both system boot, and then stop at this line: > > branching to kernel entry point 0x00100000 > Can't select default wide mode, PDC_PSW call does not work Did you build this kernel yourself? If so, it sounds like you built a 64-bit kernel since that's the default. You need to change the ARCH line in the linux/Makefile to read "parisc" instead of "parisc64". grant > > What does the above actually mean? How can I remove the PDC_PSW call > from the kernel so it can boot? I have plans to test this new kernel > image on a 715 later today. > > Thanks, > -- > Phillip Beal > Electrical and Computer Engineering > S+LUG Vice-President > > --------------------------------------------------------------------------- > To unsubscribe: send e-mail to parisc-linux-request@thepuffingroup.com with > `unsubscribe' as the subject. > Grant Grundler Unix Systems Enablement Lab +1.408.447.7253 From grundler@cup.hp.com Tue, 14 Nov 2000 11:08:20 -0800 Date: Tue, 14 Nov 2000 11:08:20 -0800 From: Grant Grundler grundler@cup.hp.com Subject: [parisc-linux] 735/755 and Kernel test10.. Grant Grundler wrote: > If so, it sounds like you built a 64-bit kernel since that's the default. Correction. *was* the default. default ARCH was changed last night to parisc. grant Grant Grundler Unix Systems Enablement Lab +1.408.447.7253 From ian.zink@maryville.com Tue, 14 Nov 2000 13:20:05 -0600 Date: Tue, 14 Nov 2000 13:20:05 -0600 From: Ian Zink ian.zink@maryville.com Subject: [parisc-linux] Palinux on a 712/60 I have a hp 712/60 I was trying to get loaded with Pa-linux. I'm using the 0.5 version of the Pa-linux cd. If I boot right off the CD it all loads until it gets to Switching to PDC. At that point nothing happens. From I have read the list, that is because the kernel is switching the text console. However, the 712s don't have consoles. From what I have also read the CD should work if you pass the kernel the parameter console=tty. So I tried to "boot scsi.2.0 isl" from the boot_admin prompt. It gave me the PALO ISL, but I could not choose which line I wanted to edit. Further, I couldn't even type "b" to boot. I don't know if the isl is freezing or what is taking place What I am wondering is there a way to boot a 712/80 without having to get cross-compiler gcc, compile the kernel, etc. Is there someway I could add the ramdisk-sti.tgz on the ISO to make it work? If so, what would need to be done? Thanks, Ian Zink, Systems Engineer Maryville Technologies 540 Maryville Centre, Suite 300 St. Louis, MO 63141 636/519-4182 (FAX) 636/519-4141 ian.zink@maryville.com www.maryville.com From mang@subcarrier.org Tue, 14 Nov 2000 14:17:35 -0500 Date: Tue, 14 Nov 2000 14:17:35 -0500 From: Michael Ang mang@subcarrier.org Subject: linux bame bame@riverrock.org wrote: > > = On Thu, Nov 09, 2000 at 03:53:48PM -0700, Paul Bame wrote: > = > Somebody never imported 2.4.0-test6, then I imported -test10 on the mai > n > = > vendor branch and now can't (easily) undo that to import test6 and THEN > = > test10. This workaround sucks. If the sources on the linus branch have been religiously tagged every time they're updated, then reverting to a previous would have been relatively painless. I'm not sure what "this workaround" was, but I guess at this point test10 is merged so the point is moot. > = don't use vendor branches. didn't you talk to mang about this? > > Um, I have no information to go on from your note. All the (successful) > merges I've done before have used the cookbook CVS merge method including > a vendor branch. Several (N-1?) of the palinux merges have been > accompanied by updating the vendor branch. And this merge is going > well despite the ugly workaround, or so it appears to me. Just > importing files to a vendor branch should have no effect on anything > else unless CVS has some horrible bug (RCS does not). Before I make > what is apparently a serious mistake ("don't use vendor branches" sounds > pretty serious) please enlighten me! Vendor branches are evil. (When I say "vendor branch" I mean the special kind of branch created by "cvs import".) When you check in to a vendor branch your changes will also be seen on the trunk, *unless* that file has been previously modified on the trunk. This is almost never what you want and adds confusion during merging (when you least want it). Tracking third-party sources using a normal branch, as we are doing, is much simpler and gives you more control. When I did the original import of Linus' sources I converted the vendor branch to a normal branch using cvs admin magic. So none of the annoyances of vendor branches should affect us, as long as any new files are added on the linus branch using "cvs add", NOT "cvs import". When you say you "I imported -test10 on the main vendor branch" I hope you really mean that you used "cvs add" on the linus branch. From your other messages, your tags looked good. - Mike. From bame@noam.fc.hp.com Tue, 14 Nov 2000 13:00:41 -0700 Date: Tue, 14 Nov 2000 13:00:41 -0700 From: Paul Bame bame@noam.fc.hp.com Subject: linux bame = bame@riverrock.org wrote: = > = > = On Thu, Nov 09, 2000 at 03:53:48PM -0700, Paul Bame wrote: = > = > Somebody never imported 2.4.0-test6, then I imported -test10 on the mai = > n = > = > vendor branch and now can't (easily) undo that to import test6 and THEN = > = > test10. This workaround sucks. = = If the sources on the linus branch have been religiously tagged every = time they're updated, then reverting to a previous would have been = relatively painless. I'm not sure what "this workaround" was, but I = guess at this point test10 is merged so the point is moot. Like the comment said, there was no copy of plain -test6 in CVS (that I saw). Without -test6 in CVS it's much harder to use cvs diff to figure out the right way to merge files when there are conflicts. I didn't realize this until -test10 was already there, so I *then* brought in -test6. They're in the wrong order on the 1.1.1 branch, so the standard merge command 'cvs -jlinus:yesterday -jlinus:' won't work next time -- explicit names will be required. = Vendor branches are evil. (When I say "vendor branch" I mean the = special kind of branch created by "cvs import".) When you check in to a = vendor branch your changes will also be seen on the trunk, *unless* that = file has been previously modified on the trunk. Thanks for clarifying what "evil" means! That is pretty ugly indeed! = This is almost never = what you want and adds confusion during merging (when you least want = it). Tracking third-party sources using a normal branch, as we are = doing, is much simpler and gives you more control. But I've seen no cook book for it. I'm guessing that instead of cvs import you use: cvs co -rlinus linux cd linux cvs commit (make note of new files from commit) cvs add cvs commit cvs tag LINUS_NEW_REVISION perhaps with provision for removing obsolete files too. I suppose that is simpler than a single cvs import command from a certain perspective :-) = When I did the original import of Linus' sources I converted the vendor = branch to a normal branch using cvs admin magic. So none of the = annoyances of vendor branches should affect us, as long as any new files = are added on the linus branch using "cvs add", NOT "cvs import". Have you a pointer to the magic or the knowledge to recreate it? I had no idea there was a special RCS marking for the evil type of branch. = When you say you "I imported -test10 on the main vendor branch" I hope = you really mean that you used "cvs add" on the linus branch. From your = other messages, your tags looked good. I used "cvs import", and either your branch magic worked, or I finished the merge before anybody randomly updated from cvs. Since import used 1.1.1, which is the branch you "fixed", it seems possible that 'cvs import' might be rendered harmless but I don't know that for sure. -P From pjlahaie@linuxcare.com Tue, 14 Nov 2000 15:43:00 -0500 Date: Tue, 14 Nov 2000 15:43:00 -0500 From: Paul J.Y. Lahaie pjlahaie@linuxcare.com Subject: [parisc-linux] Beta CD --SkvwRMAIpAhPCcCJ Content-Type: text/plain; charset=us-ascii Content-Disposition: inline This is to answer all the questions about sti console. Currently, in the CVS tree, serial console and STI console cannot be turned on at the same time. This means that a choice between serial/sti needs to be done at compile time. At the time we cut the beta, it was decided that serial console was more important than sti console. I am also working on resolving the problem with STI/serial console and once I have a fix ready, I will make a kernel image available. The current beta CD is also expecting a console on ttyS0 and does not currently open a ttyx getty. When I have a kernel that can decide the console at runtime, I will look into the beta CD issues. If you have any more questions or suggestions, feel free to email me or post on this list. Thank you. - Paul --SkvwRMAIpAhPCcCJ Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.4 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE6EaPR8ggPQthPCzcRAhT8AKC8EU8yusyoEvPHxKAQsaM0vMGthwCgnbbC Yz6ZWjq3q9B80bI+YRxc8xo= =HhRZ -----END PGP SIGNATURE----- --SkvwRMAIpAhPCcCJ-- From raj@cerias.purdue.edu Tue, 14 Nov 2000 16:18:06 -0500 Date: Tue, 14 Nov 2000 16:18:06 -0500 From: Brian Poole raj@cerias.purdue.edu Subject: [parisc-linux] Beta CD Sounds like a plan to me. I don't suppose you know how to make a 715 boot to console? Pulling the keyboard and monitor cables off the back just make it stop at boot with the unable to initiliaze keyboard error I posted with earlier. I am assuming there is some sort of boot_admin trickery necessary, but I am unaware of what it might entail and my poking around has yielded nothing.. Any advice here would be much appreciated. -b Quoting Paul J.Y. Lahaie (pjlahaie@linuxcare.com) from 14 November 2000: > with STI/serial console and once I have a fix ready, I will make a kernel > image available. The current beta CD is also expecting a console on .. > If you have any more questions or suggestions, feel free to email me or > post on this list. Thank you. From dave@hiauly1.hia.nrc.ca Tue, 14 Nov 2000 16:40:52 -0500 (EST) Date: Tue, 14 Nov 2000 16:40:52 -0500 (EST) From: John David Anglin dave@hiauly1.hia.nrc.ca Subject: abort in eliminate_regs compiling glob.c from glibc > > Breakpoint 2, eliminate_regs_in_insn (insn=0x406a0ba0, replace=0) > > at ../../gcc/reload1.c:2826 > > 2826 if (! insn_is_asm && icode < 0) > > (gdb) p debug_rtx (insn) > > (insn/s 2711 2709 2719 (set (reg:SI 6 %r6) > > (reg:SI 28 %r28)) 69 {pre_ldw-4} (insn_list 2708 (insn_list:REG_DEP_ANTI 2696 (insn_list:REG_DEP_ANTI 2702 (insn_list:REG_DEP_ANTI 2697 (nil))))) > > (expr_list:REG_DEAD (reg:SI 28 %r28) > > (insn_list:REG_RETVAL 2708 (expr_list:REG_EQUAL (expr_list (use (mem:BLK (scratch) 0)) > > (expr_list (symbol_ref/v:SI ("@strlen")) > > (expr_list (reg/v:SI 4 %r4) > > (nil)))) > > (nil))))) > > The `use' arises from the `__pure__' attribute in the prototype for strlen: > > extern size_t strlen (__const char *__s) __attribute__ ((__pure__)); Here is a patch to fix the abort in eliminate_regs when it encounters a USE. As I understand the situation, there are three conditions needed to trigger it: 1) A function that contains insns with an eliminable register. 2) The function must call __builtin_alloca to change the frame size from its initial size. 3) After the call to __builtin_alloca, there must be a call to a pure function. With the enclosed patch, I can now build glibc for hppa-linux with -O3 optimisation. Please review carefully because I will be the first to admit that I don't understand why the use is there in the first place and all the details of what eliminate_reg does. Dave -- J. David Anglin dave.anglin@nrc.ca National Research Council of Canada (613) 990-0752 (FAX: 952-6605) 2000-11-14 John David Anglin * reload1.c (eliminate_regs): Don't abort on MEM USEs. --- reload1.c.orig Wed Sep 27 14:27:23 2000 +++ reload1.c Tue Nov 14 16:01:56 2000 @@ -2499,6 +2499,10 @@ return x; case USE: + /* Handle insn_list USE that a call to a pure functions may generate. */ + new = eliminate_regs (XEXP (x, 0), 0, insn); + if (GET_CODE (new) == MEM) + return XEXP (new, 0); case CLOBBER: case ASM_OPERANDS: case SET: From grundler@cup.hp.com Tue, 14 Nov 2000 14:32:00 -0800 Date: Tue, 14 Nov 2000 14:32:00 -0800 From: Grant Grundler grundler@cup.hp.com Subject: [parisc-linux] Palinux on a 712/60 Ian Zink wrote: > I have a hp 712/60 I was trying to get loaded with Pa-linux. I'm using the > 0.5 version of the Pa-linux cd. If I boot right off the CD it all loads > until it gets to Switching to PDC. At that point nothing happens. From I > have read the list, that is because the kernel is switching the text > console. However, the 712s don't have consoles. 712s have consoles. They have two outputs which can be used as console by linux. The STI consoles (VGA-like spigot) and serial. Connect a serial cable 9600-8-n-1 and run minicom at the other end. > From what I have also read > the CD should work if you pass the kernel the parameter console=tty. So I > tried to "boot scsi.2.0 isl" from the boot_admin prompt. It gave me the > PALO ISL, but I could not choose which line I wanted to edit. Further, I > couldn't even type "b" to boot. I don't know if the isl is freezing or what > is taking place That's a different problem...pb? > What I am wondering is there a way to boot a 712/80 without having > to get cross-compiler gcc, compile the kernel, etc. The CD was intended to also work on the 712 even though we may not have tested on it. > Is there someway I could > add the ramdisk-sti.tgz on the ISO to make it work? If so, what would need > to be done? no clue. anyone else? grant Grant Grundler Unix Systems Enablement Lab +1.408.447.7253 From mang@subcarrier.org Tue, 14 Nov 2000 17:31:22 -0500 Date: Tue, 14 Nov 2000 17:31:22 -0500 From: Michael Ang mang@subcarrier.org Subject: [parisc-linux] tracking third-party sources (was Re: linux bame) Paul Bame wrote: > > = bame@riverrock.org wrote: > = > > = > = On Thu, Nov 09, 2000 at 03:53:48PM -0700, Paul Bame wrote: > = > = > Somebody never imported 2.4.0-test6, then I imported -test10 on the > mai > = > n > = > = > vendor branch and now can't (easily) undo that to import test6 and > THEN > = > = > test10. This workaround sucks. > = > Like the comment said, there was no copy of plain -test6 in CVS (that I > saw). Without -test6 in CVS it's much harder to use cvs diff to figure > out the right way to merge files when there are conflicts. > I didn't realize this until -test10 was already there, so I *then* > brought in -test6. They're in the wrong order on the 1.1.1 branch, so > the standard merge command 'cvs -jlinus:yesterday -jlinus:' > won't work next time -- explicit names will be required. The best thing to do is to import -test10 again and move the static tag by re-tagging. > = Tracking third-party sources using a normal branch, as we are > = doing, is much simpler and gives you more control. > > But I've seen no cook book for it. I'm guessing that instead of cvs import > you use: > cvs co -rlinus linux > > cd linux > cvs commit (make note of new files from commit) > cvs add > cvs commit > cvs tag LINUS_NEW_REVISION > perhaps with provision for removing obsolete files too. I suppose that is > simpler than a single cvs import command from a certain perspective :-) I had a good chat with Paul about this, and we worked out that using "import" is marginally better. This is what the add/remove method would look like: cvs co -rlinux linux cvs rm cvs add cvs commit cvs tag LINUS_NEW_REVISION Add the import method: cd linux cvs import linux linus LINUS_NEW_REVISION cvs admin -b > = When you say you "I imported -test10 on the main vendor branch" I hope > = you really mean that you used "cvs add" on the linus branch. From your > = other messages, your tags looked good. > > I used "cvs import", and either your branch magic worked, or I finished the > merge before anybody randomly updated from cvs. Since import used 1.1.1, > which is the branch you "fixed", it seems possible that 'cvs import' might > be rendered harmless but I don't know that for sure. Using "import" to bring in new files taints them with the vendor branch badness. These files should be adjusted using "cvs admin -b". Note that "cvs admin" works directly on files in the repository at low level (without any revisioning of changes) and is thus to be avoided if at all possible. Please don't run "cvs admin" if you (the collective "you") don't know the consequences. - Mike. From ian.zink@maryville.com Tue, 14 Nov 2000 17:08:33 -0600 Date: Tue, 14 Nov 2000 17:08:33 -0600 From: Ian Zink ian.zink@maryville.com Subject: [parisc-linux] Palinux on a 712/60 Thanks for the reply, Grant. However, the 712s do not have a serial console. They do have a com port, but it does not work as a console, unfortunately. So I need do need to get a STI enabled kernel. I dropped Paul Lahaie a note to see if he could send me such a kernel so I do not have to create the entire cross-platform development environment just to boot one of these 712s. After I get it, I plan on expanding the 0.5 iso and making a new one using the STI console kernel. Ian From kailasr@webcash.com Tue, 14 Nov 2000 14:58:55 -0800 Date: Tue, 14 Nov 2000 14:58:55 -0800 From: Kailashnath V Rampure kailasr@webcash.com Subject: [parisc-linux] Boot command I have booted HP A class server through network. On that I have repartioned the system and followed the steps on http://www.parisc-linux.org/install.html. I have used the following command to initialize the hard disk. The kernel I have downloaded is vmlinux-20001018. and cpied it to /mnt/boot/vmlinux after mounting /dev/sda3. I have used the following command to initialize the HDD. palo -I -k /boot/vmlinux -b /boot/iplboot \ -c '3/boot/vmlinux TERM=linux HOME=/ root=/dev/sda3' \ /dev/sda -------------------------------- I get the following error: -------------------------------- SOFT Boot. palo ipl bame@noam Tue oct 31 14:18:02 MST 2000 0/vmlinux 2138614 bytes@ 0x1f78c000 0/palo-cmdline '3/boot/vmlinux TERM=linux HOME=/ root=/dev/sda3' /dev/ida1 82 62 1030688 /dev/ida2 f0 1030750 24738 /dev/ida3 83 1055488 1030750 Kernel:partition 3 file /boot/vmlinux ext2 block size 1024 ext2_mount(partition 3) returns 0 ext2_open(/boot/vmlinux) = -1 open /boot/vmlinux failed ------------------------------------- Please suggest. From grundler@cup.hp.com Tue, 14 Nov 2000 15:18:10 -0800 Date: Tue, 14 Nov 2000 15:18:10 -0800 From: Grant Grundler grundler@cup.hp.com Subject: [parisc-linux] Palinux on a 712/60 Ian Zink wrote: > Thanks for the reply, Grant. However, the 712s do not have a serial console. > They do have a com port, but it does not work as a console, unfortunately. It does for linux. That's what the "Switching from PDC Console" is about. Connect the serial cable to the com port and look at the output. I've done it in the past and know it worked at least once. I haven't tried it with the lasted ISO - no time to play w/712's now. > So I need do need to get a STI enabled kernel. I dropped Paul Lahaie a note > to see if he could send me such a kernel... Paul just sent mail to the list indicating he's working on console issues. Please let him work on it. Trust me, he'll tell us when he's done. :^) grant From dhazeghi@pacbell.net Tue, 14 Nov 2000 18:17:39 -0800 Date: Tue, 14 Nov 2000 18:17:39 -0800 From: dhazeghi@pacbell.net dhazeghi@pacbell.net Subject: [parisc-linux] [Semi OT] SOM Linker Alex deVries wrote: > dhazeghi@pacbell.net wrote: > > However I would like to know what work if any has been done on the SOM > > linker which HP released to the public last November(?). It seems that > > as of right now, it has not been touched since February 14, and the FSF > > binutils snapshots still do not have any SOM support for ld. Has there > > been any movement in merging this in, or is anybody working on this? > > The initial plan was to do our 32-bit userspace with SOM, worrying about > ELF32 much later in the game. But ELF32 development happened a lot > quicker than expected, and so nobody's really done much on the SOM > linker. That's what it looked like... > > > I suspect it'd be very hard to use the SOM linker code to incorporate it > into binutils, but I could be wrong. > > What are you actually trying to do? I would like to be able to set up a cross compilation environment for hpux and 32 bit PA-RISC. However without a functional cross linker, this is impossible to do, and as binutils has not got one yet, I thought perhaps the one that HP open-sourced might be some use. It would seem logical that with the sources available, it shouldn't be too difficult to fix the broken bits and get a SOM linker working in binutils, but that doesn't seem to have happened yet. Oh well, thanks for the info... Dara Hazeghi From dave@hiauly1.hia.nrc.ca Tue, 14 Nov 2000 22:00:25 -0500 (EST) Date: Tue, 14 Nov 2000 22:00:25 -0500 (EST) From: John David Anglin dave@hiauly1.hia.nrc.ca Subject: [parisc-linux] [Semi OT] SOM Linker > I would like to be able to set up a cross compilation environment for hpux and > 32 bit PA-RISC. However without a functional cross linker, this is impossible > to do, and as binutils has not got one yet, I thought perhaps the one that HP > open-sourced might be some use. It would seem logical that with the sources > available, it shouldn't be too difficult to fix the broken bits and get a SOM > linker working in binutils, but that doesn't seem to have happened yet. Oh > well, thanks for the info... You should be able to build cross compilation tools under hpux for hppa-linux. First you should install native versions of binutils and gcc under hpux (this assumes that you have the hpux C compiler and linker). The release version of gcc (2.95.2) would be a good choice. The standard hpux linker works fine with gcc/gas for C compilations. Then follow the directions at www.parisc-linux.org for building the cross compilation tools and linux. Dave -- J. David Anglin dave.anglin@nrc.ca National Research Council of Canada (613) 990-0752 (FAX: 952-6605) From dhazeghi@pacbell.net Tue, 14 Nov 2000 21:23:41 -0800 Date: Tue, 14 Nov 2000 21:23:41 -0800 From: dhazeghi@pacbell.net dhazeghi@pacbell.net Subject: [parisc-linux] [Semi OT] SOM Linker John David Anglin wrote: > > I would like to be able to set up a cross compilation environment for hpux and > > 32 bit PA-RISC. However without a functional cross linker, this is impossible > > to do, and as binutils has not got one yet, I thought perhaps the one that HP > > open-sourced might be some use. It would seem logical that with the sources > > available, it shouldn't be too difficult to fix the broken bits and get a SOM > > linker working in binutils, but that doesn't seem to have happened yet. Oh > > well, thanks for the info... > > You should be able to build cross compilation tools under hpux for hppa-linux. > First you should install native versions of binutils and gcc under hpux (this > assumes that you have the hpux C compiler and linker). The release version of > gcc (2.95.2) would be a good choice. The standard hpux linker works fine with > gcc/gas for C compilations. Then follow the directions at www.parisc-linux.org > for building the cross compilation tools and linux. This is not precisely what I mean. What I should have said is that I want to create a cross compiler --host=i686-linux --target=hppa-hpux. I asked this list, because you folks did some work on the SOM linker, which is at the moment the missing piece for a cross toolchain which targets hpux. Thanks, Dara P.S. On a different note, is the recipe fully up to date? I tried following it a few weeks ago, but glibc did not complete building successfully. From Arnaud.ATOCH@oecd.org Wed, 15 Nov 2000 10:05:04 +0100 Date: Wed, 15 Nov 2000 10:05:04 +0100 From: Arnaud.ATOCH@oecd.org Arnaud.ATOCH@oecd.org Subject: [parisc-linux] Palinux on a 712/60 Hi, I got a couple of 715 and I'd love having access to an ISO image with STI console kernel too. -----Original Message----- From: Ian Zink [mailto:ian.zink@maryville.com] Sent: Wednesday, November 15, 2000 00:09 To: 'parisc-linux@thepuffingroup.com' Subject: RE: [parisc-linux] Palinux on a 712/60 Thanks for the reply, Grant. However, the 712s do not have a serial console. They do have a com port, but it does not work as a console, unfortunately. So I need do need to get a STI enabled kernel. I dropped Paul Lahaie a note to see if he could send me such a kernel so I do not have to create the entire cross-platform development environment just to boot one of these 712s. After I get it, I plan on expanding the 0.5 iso and making a new one using the STI console kernel. Ian --------------------------------------------------------------------------- To unsubscribe: send e-mail to parisc-linux-request@thepuffingroup.com with `unsubscribe' as the subject. From rhirst@linuxcare.com Wed, 15 Nov 2000 09:58:35 +0000 Date: Wed, 15 Nov 2000 09:58:35 +0000 From: Richard Hirst rhirst@linuxcare.com Subject: [parisc-linux] dino maintainer? On Tue, Nov 14, 2000 at 08:10:42AM -0800, Grant Grundler wrote: > The bug is normal for card-mode Dino - not for Built-in Dino. > I think Helge has the GSC 100BT card which is a card-mode Dino on-board > with one (or two) Tulip(s) behind it. > > The warning is a reminder one can NOT use MMIO accesses to those > PCI devices and *only* I/O Port space (eg inb/outb). > > If someone wants to fix the warning so it's quiet for card-mode > devices...see is_card_dino(d) in dino_driver_callback() for an > example. > > FYI - card-mode dino was used for several different networking > interfaces but not SCSI interfaces. But Helge has problems with the sym53c8xx driver on a B160L. Is that a PCI card driven via Dino? And if so, are you saying he needs to build his kernel with CONFIG_SCSI_NCR53C8XX_IOMAPPED=y so it doesn't try to use MMIO? Helge, it might be worth trying to switch on CONFIG_SCSI_NCR53C8XX_IOMAPPED anyway just to see what happens. Otherwise someone needs to start adding printk debug to figure out what is happening. I can't do that as I don't have a sym53c8xx pci card. Richard From andrew@neep.com.au Wed, 15 Nov 2000 18:10:13 +0800 Date: Wed, 15 Nov 2000 18:10:13 +0800 From: Andrew Shugg andrew@neep.com.au Subject: [parisc-linux] Palinux on a 712/60 Arnaud.ATOCH@oecd.org said: > Hi, > > I got a couple of 715 and I'd love having access to an ISO image with STI > console kernel too. I've never made an El Torito CDROM, is it possible to have multiple boot images and a boot loader on a single disc? ie could the actual boot image be a boot loader (PALO) which then points at one or more kernels on the CDROM? Andrew. -- Andrew Shugg http://www.neep.com.au/ "Just remember, Mr Fawlty, there's always someone worse off than yourself." "Is there? Well I'd like to meet him. I could do with a good laugh." From marteaut@esiee.fr Wed, 15 Nov 2000 11:25:07 +0100 Date: Wed, 15 Nov 2000 11:25:07 +0100 From: Thomas Marteau marteaut@esiee.fr Subject: [parisc-linux] Palinux on a 712/60 Hi Ian, If you like to see a linux kernel booting on your 712, you can donwload a fully operationnal root file system with the STI console and an extra terminal with the RS232 port at http://www.esiee.fr/puffin You have also all the info to make a bootable hard disk so try it and give us feedback... Bye, Thomas Marteau ESIEE Team From rhirst@linuxcare.com Wed, 15 Nov 2000 11:12:20 +0000 Date: Wed, 15 Nov 2000 11:12:20 +0000 From: Richard Hirst rhirst@linuxcare.com Subject: [parisc-linux] Beta CD On Fri, Nov 10, 2000 at 05:14:06PM -0500, Paul J.Y. Lahaie wrote: > Hello fellow PA-RISCers, > > An preliminary beta CD for PA/Linux has been uploaded to > puffin.external.hp.com. If people could try it and forward any complaints > or suggestions to me, it would be greatly appreciated. The URL for the > image is: ftp://puffin.external.hp.com/pub/parisc/cd-images/palinux-0.5.iso.gz I just borrowed a CDROM drive for my 715/75 so I could try it on there [Actually this is the palinux-0.5.iso.gz that I commented on, not the final version]. I wasn't successful: Sometimes the boot hangs after "ASP version 1 at 0xf0800000 found", waits a few seconds and then HPMCs. The scsi driver always has serious problems with the CD drive but does detect other devices on the bus. The kernel always crashes after "Serial driver version 5.01...", (if it gets that far) with Data access rights fault in kernel: Code=26 regs=c5f9c940 (Addr=00000003) YZrvWESTHLNXBCVMcbcbcbcbOGFRQPDI PSW: 00000000000001000000000000001010 r0-3 00000000 c0217800 c011e9f8 c5ff64a0 r4-7 c5ff6200 c023ab20 00000008 f0823800 r8-11 00000003 00000007 c019134c c02b20a0 r12-15 fffffffc c023a800 c023a800 c02c31cc r16-19 c023a800 c023a800 c02b2024 00000000 r20-23 c5ff6234 f0823807 f0823800 0000000a r24-27 ffffffff c5ff64a0 c5ff6200 c0258000 r28-31 ffffffff 000002c0 c5f9cb80 c012dfc0 sr0-4 00000000 00000000 00000000 00000000 sr4-8 00000000 00000000 00000000 00000000 IASQ: 00000000 00000000 IAOQ: c011e710 c011e714 IIR: 0f881093 ISR: 00000000 IOR: 00000003 ORIG_R28: 00000058 I'll investigate further when I have the time. Richard From adevries@linuxcare.com Wed, 15 Nov 2000 11:50:27 -0500 Date: Wed, 15 Nov 2000 11:50:27 -0500 From: Alex deVries adevries@linuxcare.com Subject: [parisc-linux] dino maintainer? Richard Hirst wrote: > On Tue, Nov 14, 2000 at 08:10:42AM -0800, Grant Grundler wrote: > > FYI - card-mode dino was used for several different networking > > interfaces but not SCSI interfaces. > > But Helge has problems with the sym53c8xx driver on a B160L. Is > that a PCI card driven via Dino? And if so, are you saying he needs > to build his kernel with CONFIG_SCSI_NCR53C8XX_IOMAPPED=y so it > doesn't try to use MMIO? Hang on a sec... what Grant's saying is that *card-mode* dino is never used for SCSI controllers, but on the B160L it would probably be *chip-mode* dino. Does this mean that all GSC SCSI expansion cards are Zalon based? So what Helge has isn't a PCI card specifically, Dino and the 53c8xx are all on the motherboard. Does Dino handle IO memory mapping differently for chip or card mode? - Alex -- Alex deVries, Principal Solutions Architect, The Puffins at Linuxcare 613.562.2759 tel alex@linuxcare.com, http://www.linuxcare.com/ Linuxcare, Support for the revolution. From grundler@cup.hp.com Wed, 15 Nov 2000 08:06:32 -0800 Date: Wed, 15 Nov 2000 08:06:32 -0800 From: Grant Grundler grundler@cup.hp.com Subject: [parisc-linux] dino maintainer? Richard Hirst wrote: > On Tue, Nov 14, 2000 at 08:10:42AM -0800, Grant Grundler wrote: > > The bug is normal for card-mode Dino - not for Built-in Dino. > > I think Helge has the GSC 100BT card which is a card-mode Dino on-board > > with one (or two) Tulip(s) behind it. Helge confirmed he has no such card. I think the PDC simply isn't programming the Dino IO_ADDR_EN since there are no PCI devices in his B160. Helge's B160 has a old rev of Dino PCI host bus adapter chip. It's possible to have "silent" data corruption caused by older revs of dino - 3.0 and older. The latest PDC Revisions (5.x and later) know this and won't permit the system to be booted unless the only devices on the PCI bus are known graphics interface cards. > > The warning is a reminder one can NOT use MMIO accesses to those > > PCI devices and *only* I/O Port space (eg inb/outb). > > > > If someone wants to fix the warning so it's quiet for card-mode > > devices...see is_card_dino(d) in dino_driver_callback() for an > > example. This is still correct for card-mode dino. > > FYI - card-mode dino was used for several different networking > > interfaces but not SCSI interfaces. > > But Helge has problems with the sym53c8xx driver on a B160L. Is > that a PCI card driven via Dino? I doubt it now. If Helge could send richard "in io" output, I think that would clarify what's in the B160. > And if so, are you saying he needs > to build his kernel with CONFIG_SCSI_NCR53C8XX_IOMAPPED=y so it > doesn't try to use MMIO? no. no SCSI was ever implement on a card-mode dino board. No reason to since they already had Zalon or open slots. grant > Helge, it might be worth trying to switch on CONFIG_SCSI_NCR53C8XX_IOMAPPED > anyway just to see what happens. Otherwise someone needs to start > adding printk debug to figure out what is happening. I can't do > that as I don't have a sym53c8xx pci card. > > Richard From grundler@cup.hp.com Wed, 15 Nov 2000 08:17:41 -0800 Date: Wed, 15 Nov 2000 08:17:41 -0800 From: Grant Grundler grundler@cup.hp.com Subject: [parisc-linux] dino maintainer? Alex deVries wrote: > Hang on a sec... what Grant's saying is that *card-mode* dino is never > used for SCSI controllers, but on the B160L it would probably be > *chip-mode* dino. No such thing - you probably mean "Bridge Mode" and that's what the built-in Dino is using. > Does this mean that all GSC SCSI expansion cards are Zalon based? > > So what Helge has isn't a PCI card specifically, Dino and the 53c8xx are > all on the motherboard. > > Does Dino handle IO memory mapping differently for chip or card mode? yes. yes. yes (conditional). "IO memory mapping" is a confusing term. I'll assume you mean MMIO. (Memory Mapped I/O) MMIO space access is independent of I/O Port space access. MMIO space access simple isn't available for card-mode Dino since niether PDC nor the OS assigns host physical address space to the card-mode Dino (that's what IO_ADDR_EN is for). PDC does this for Bridge-mode dino (built-in) - but apperently only when it needs to. I/O Port space accesses are done the same way for both modes. I/O Port space access is implemented by poking registers on Dino. Read the Dino Spec (or source) for more details. grant Grant Grundler Unix Systems Enablement Lab +1.408.447.7253 From dave@hiauly1.hia.nrc.ca Wed, 15 Nov 2000 11:23:05 -0500 (EST) Date: Wed, 15 Nov 2000 11:23:05 -0500 (EST) From: John David Anglin dave@hiauly1.hia.nrc.ca Subject: [parisc-linux] [Semi OT] SOM Linker > This is not precisely what I mean. What I should have said is that I want to create > a cross compiler --host=i686-linux --target=hppa-hpux. I asked this list, because > you folks did some work on the SOM linker, which is at the moment the missing piece > for a cross toolchain which targets hpux. This also may be possible. The first step would be to copy the hpux headers to a i686-linux system and see if you can build the HP linker. The next step would be to try to build the cross binutils tools. I know this requires the hpux headers and likely some hacking would be required to get it to build. The linker is probably the hard part. There may be byte ordering issues and bugs in what HP contributed. Dave -- J. David Anglin dave.anglin@nrc.ca National Research Council of Canada (613) 990-0752 (FAX: 952-6605) From pdbeal@louisville.edu Wed, 15 Nov 2000 11:47:09 -0500 Date: Wed, 15 Nov 2000 11:47:09 -0500 From: Phillip D. Beal pdbeal@louisville.edu Subject: [parisc-linux] Beta CD On Fri, Nov 10, 2000 at 05:14:06PM -0500, Paul J.Y. Lahaie wrote: > Hello fellow PA-RISCers, > > An preliminary beta CD for PA/Linux has been uploaded to > puffin.external.hp.com. If people could try it and forward any complaints > or suggestions to me, it would be greatly appreciated. The URL for the > image is: ftp://puffin.external.hp.com/pub/parisc/cd-images/palinux-0.5.iso.gz > > - Paul the CD worked great on the 715 I tried, and I actually didn't have a serial console machine, so I used my Palm Pilot and a link cable. Still worked like a charm. How did you get the kernel image into the boot sector of the CD? I'd like to try to build some CD's of the kernels I'm building to test in some mahcines that are not on the same network as the machine that I'm building everything from. And I don't mind posting my CD images somewhere if they work...but most of my testing is on a 735 or 755. Thanks, -- Phillip Beal Electrical and Computer Engineering S+LUG Vice-President From bame@noam.fc.hp.com Wed, 15 Nov 2000 10:08:22 -0700 Date: Wed, 15 Nov 2000 10:08:22 -0700 From: Paul Bame bame@noam.fc.hp.com Subject: [parisc-linux] Help with posix_types.h I'm reviewing the posix_types.h to figure out what's right for 64-bit linux. I know others may have thought through this before so I'm hoping for guidance. For those unfamiliar, the type names in posix_types.h are like __kernel_dev_t and usually are used to define the corresponding "normal" type (dev_t). These should be settled before the 32/64 syscall wrappers can be completed. __kernel_ino_t: often 32 bits, currently 32 bits for parisc and som3 64-bit kernels (mips64 and ia64). 64 bits on alpha and sparc64. Seems to me this ought to be 32 bits on parisc and parisc64, or 64 bits on both, since it's a function of file system sizes not processor width. HPUX kernel seems to always use 32 bits, but 64-bit userspace uses 64 bits. I propose 32 bits on both, but willy had selected 64 bits in parisc64 for some reason. __kernel_off_t: seems to be 32 bits on 32-bit cpus, 64 on 64-bit ones. This is supposedly the offset from a beginning of a file. HPUX appears to use 64-bits *in the kernel* for both 32 and 64-bit kernels. The obvious pattern is to make ours 32 on narrow, and 64 on wide palinux so I guess I propose that, and that's the way it was before I hacked on it too. Should we consider switching to 64 bits on narrow palinux since this is related to file systems, not CPUs. Note there's also a __kernel_loff_t -> loff_t which appears to be defined as 64 bits. I'm not sure how this does/should interact with off_t (lseek vs lseek64 for example). __kernel_suseconds_t: which becomes suseconds_t which is used in struct timeval { time_t tv_sec; /* seconds */ suseconds_t tv_usec; /* microseconds */ }; I'm confused why hpux, and other systems, like for this to be 'long' (e.g., 64 bits on 64-bit processors) since it seems like values over a million are probably rare and 32 bits seems to be enough for most implementations. sparc64 chose 32 bits for this and I want to do the same for parisc64 because it will reduce the amount of syscall structure repackings. Comments? __kernel_daddr_t: which is used indirectly in struct solaris_x86_vtoc and solaris_x86_slice which *might* be an on-disk data structures (used with CONFIG_SOLARIS_X86_PARTITION). So this needs to be 32 bits if that's the case (definition from sparc) and several archs have it 64 bits! On the other hand, HPUX's man page says 'daddr_t used for disk addresses except in an inode [and partition table I would think] on disk'. So it should probably be the same type as off_t. FYI the only other place it's used is in 'struct mtio' -- used to talk to magnetic tape units. I'm guessing the sparc struct should not be using this type, and that we should define it the same as off_t. Comments? From kailasr@webcash.com Wed, 15 Nov 2000 09:55:09 -0800 Date: Wed, 15 Nov 2000 09:55:09 -0800 From: Kailashnath V Rampure kailasr@webcash.com Subject: [parisc-linux] Boot command Yes Thomas the vmlinux is in /boot of 3rd partition as the other partitions are swap and f0. At 11:48 AM 11/15/00 +0100, Thomas Marteau wrote: >----- Original Message ----- >From: Kailashnath V Rampure >To: Paul Bame >Cc: Grant Grundler ; Matt Taggart >; >Sent: Tuesday, November 14, 2000 11:58 PM >Subject: Re: [parisc-linux] Boot command > > > > I have booted HP A class server through network. On that I have >repartioned > > the system and followed the steps on >http://www.parisc-linux.org/install.html. > > I have used the following command to initialize the hard disk. The kernel >I > > have downloaded is vmlinux-20001018. and cpied it to /mnt/boot/vmlinux > > after mounting /dev/sda3. I have used the following command to initialize > > the HDD. > > > > palo -I -k /boot/vmlinux -b /boot/iplboot \ -c '3/boot/vmlinux TERM=linux > > HOME=/ root=/dev/sda3' \ /dev/sda > >This means that vmlinux must be in /boot in your third partition on your >disk. >Is it true in your case? > > > -------------------------------- > > I get the following error: > > -------------------------------- > > SOFT Boot. > > palo ipl bame@noam Tue oct 31 14:18:02 MST 2000 > > 0/vmlinux 2138614 bytes@ 0x1f78c000 > > 0/palo-cmdline '3/boot/vmlinux TERM=linux HOME=/ root=/dev/sda3' > > /dev/ida1 82 62 1030688 > > /dev/ida2 f0 1030750 24738 > > /dev/ida3 83 1055488 1030750 > > Kernel:partition 3 file /boot/vmlinux > > ext2 block size 1024 > > ext2_mount(partition 3) returns 0 > > ext2_open(/boot/vmlinux) = -1 > > open /boot/vmlinux failed > > ------------------------------------- > > Please suggest. > > > > -------------------------------------------------------------------------- >- > > To unsubscribe: send e-mail to parisc-linux-request@thepuffingroup.com >with > > `unsubscribe' as the subject. > > > > From bame@noam.fc.hp.com Wed, 15 Nov 2000 11:05:14 -0700 Date: Wed, 15 Nov 2000 11:05:14 -0700 From: Paul Bame bame@noam.fc.hp.com Subject: [parisc-linux] Beta CD = How did you get the kernel image into the boot = sector of the CD? I'd like to try to build some CD's of the kernels I'm = building to test in some mahcines that are not on the same network as = the machine that I'm building everything from. The magic for making bootable CDs is documented in the PALO README.html which you have on your system already since you're building kernels. -P From marteaut@esiee.fr Wed, 15 Nov 2000 19:10:56 +0100 Date: Wed, 15 Nov 2000 19:10:56 +0100 From: Thomas Marteau marteaut@esiee.fr Subject: [parisc-linux] Boot command Hi again, You put the swap partition before the f0 partition and here it is the f0 partition in first position. Also, your hard disk is ida instead of sda, what's that ? Bye, ESIEE Team ----- Original Message ----- From: Kailashnath V Rampure To: Thomas Marteau Cc: Sent: Wednesday, November 15, 2000 6:55 PM Subject: Re: [parisc-linux] Boot command > Yes Thomas the vmlinux is in /boot of 3rd partition as the other partitions > are swap and f0. > > At 11:48 AM 11/15/00 +0100, Thomas Marteau wrote: > > >----- Original Message ----- > >From: Kailashnath V Rampure > >To: Paul Bame > >Cc: Grant Grundler ; Matt Taggart > >; > >Sent: Tuesday, November 14, 2000 11:58 PM > >Subject: Re: [parisc-linux] Boot command > > > > > > > I have booted HP A class server through network. On that I have > >repartioned > > > the system and followed the steps on > >http://www.parisc-linux.org/install.html. > > > I have used the following command to initialize the hard disk. The kernel > >I > > > have downloaded is vmlinux-20001018. and cpied it to /mnt/boot/vmlinux > > > after mounting /dev/sda3. I have used the following command to initialize > > > the HDD. > > > > > > palo -I -k /boot/vmlinux -b /boot/iplboot \ -c '3/boot/vmlinux TERM=linux > > > HOME=/ root=/dev/sda3' \ /dev/sda > > > >This means that vmlinux must be in /boot in your third partition on your > >disk. > >Is it true in your case? > > > > > -------------------------------- > > > I get the following error: > > > -------------------------------- > > > SOFT Boot. > > > palo ipl bame@noam Tue oct 31 14:18:02 MST 2000 > > > 0/vmlinux 2138614 bytes@ 0x1f78c000 > > > 0/palo-cmdline '3/boot/vmlinux TERM=linux HOME=/ root=/dev/sda3' > > > /dev/ida1 82 62 1030688 > > > /dev/ida2 f0 1030750 24738 > > > /dev/ida3 83 1055488 1030750 > > > Kernel:partition 3 file /boot/vmlinux > > > ext2 block size 1024 > > > ext2_mount(partition 3) returns 0 > > > ext2_open(/boot/vmlinux) = -1 > > > open /boot/vmlinux failed From dave@hiauly1.hia.nrc.ca Wed, 15 Nov 2000 13:09:49 -0500 (EST) Date: Wed, 15 Nov 2000 13:09:49 -0500 (EST) From: John David Anglin dave@hiauly1.hia.nrc.ca Subject: [parisc-linux] Help with posix_types.h The largest disk currently available I believe is the 180GB Seagate Baracuda. The size of drives is increasing about a factor of 2 per year. The __kernel_off_t definitely needs to be 64 bits to handle large drives in both 32 and 64 bit systems. Disk blocks are typically 512 or 1024 bytes. Thus, drives may exceed 4GB disk blocks in 3-4 years. Inodes are variable in size (8KB average). Thus, we are a little further away from exceeding the 32 bit inode limit. Dave -- J. David Anglin dave.anglin@nrc.ca National Research Council of Canada (613) 990-0752 (FAX: 952-6605) From bame@noam.fc.hp.com Wed, 15 Nov 2000 11:12:57 -0700 Date: Wed, 15 Nov 2000 11:12:57 -0700 From: Paul Bame bame@noam.fc.hp.com Subject: [parisc-linux] Boot command = You put the swap partition before the f0 partition and here it is the f0 = partition in first position. The partition order doesn't matter so long as the f0 partition and the partition containing your kernel (an ext2 partition) *end* within the first 2Gb of the disk. See the PALO README.html. = Also, your hard disk is ida instead of sda, what's that ? PALO lists the devices as 'ida' instead of 'sda' or 'hda' since it is using the firmware 'IODC' interface to talk to the boot device, and it has no idea what type of boot device IODC is providing. -P From rhirst@linuxcare.com Wed, 15 Nov 2000 18:48:08 +0000 Date: Wed, 15 Nov 2000 18:48:08 +0000 From: Richard Hirst rhirst@linuxcare.com Subject: [parisc-linux] Single-stepping (Oops, CC-ed to the wrong list first time!) Hi John, I've been helping Alan Modra out with kernel changes to support single stepping for gdb. Paul Bame suggested I bounced our ideas off you in case you (or anyone else) had any comments. I havn't actually committed my changes yet. The basic approach is to use the recovery counter to generate a trap every instruction. The scheme is complicated because a suspended process may or may not return to user space via an RFI. If it was suspended as a result of an interrupt then we can simply set PSW bit R in the tasks saved registers and it will get loaded by the RFI. On every task switch I set the recovery counter to 0, just in case the new process is being single-stepped. If a process is suspended during a syscall, then there is no RFI on the return path to userland, and we have to handle things differently. I have changed the syscall return path such that it loads the recovery counter with 3 before updating the PSW with a value from the tasks saved registers. If that PSW has the R bit set, then the count of 3 will generate a trap on the first instruction following the branch back to user space. Note that PSW wasn't previously restored on the syscall return path. To avoid further complications of interrupts during the three instructions when the recovery counter is decrementing, whenever we set the R bit, we also clear the I bit to disable interrupts. Nullified instructions are handled by the controlling process manually moving the childs IAOQ over the instruction without actually setting it running, because the recovery counter isn't decremented for nullified instructions. I need to do some more testing before committing this, but would welcome any comments on the basic approach taken, areas I have mis-understood, or problems with it that might not yet have occurred to me. Thanks, Richard From andreas@bawue.de Thu, 16 Nov 2000 20:20:41 +0100 Date: Thu, 16 Nov 2000 20:20:41 +0100 From: Andreas Thienemann andreas@bawue.de Subject: [parisc-linux] 250/1 doesn't boot but dumps stack This is a multi-part message in MIME format. --------------F7EF1B69F0A7C4C7DD54E27D Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hi, I recently got a D-Class HP900 250/1 (at least it says that on the label) and tried to get the pa-risc port running on it. So I got a CVS checkout and build the whole toolchain without any major hassles. The kernel, including NFS-ROOT, built also without any glitches. But when I try to boot up this kernel it dumps stack right after initialising the pty interfaces. (I already left out everything unnecessary, such as parallel port support) After that it complains about "Data acces rights fault in kernel: Code=26 regs=c7f98780 (Addr=000000004)" and some more data... For the curious, the boot sequence is attached. I hope someone can give me a clue what might be wrong... Thanks, Andreas --------------F7EF1B69F0A7C4C7DD54E27D Content-Type: text/plain; charset=us-ascii; name="hp9000-capture" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="hp9000-capture" Firmware Version 36.34 Duplex Console IO Dependent Code (IODC) revision 0 ------------------------------------------------------------------------------ (c) Copyright 1995-1998, Hewlett-Packard Company, All rights reserved ------------------------------------------------------------------------------ Processor Speed State Coprocessor State Cache Size --------- -------- --------------------- ----------------- ---------- 0 101 MHz Active Functional 256 KB Central Bus Speed (in MHz) : 101 Available memory (bytes) : 134217728 Good memory required (bytes): 15245312 Primary boot path: 8/16/5.5 (dec) Alternate boot path: 8/16/5.2 (dec) Console path: 8/16/4.0 (dec) Keyboard path: 8/16/7.0 (dec) Processor is booting from first available device. To discontinue, press any key within 10 seconds. Boot terminated. ------- Main Menu ------------------------------------------------------------- Command Description ------- ----------- BOot [PRI|ALT|] Boot from specified path PAth [PRI|ALT|CON|KEY] [] Display or modify a path SEArch [DIsplay|IPL] [] Search for boot devices COnfiguration [] Access Configuration menu/commands INformation [] Access Information menu/commands SERvice [] Access Service menu/commands DIsplay Redisplay the current menu HElp [|] Display help for menu or command RESET Restart the system ------- Main Menu: Enter command > bo 8/16/6.0 Interact with IPL (Y or N)?> n Booting... Network Station Address 0060b0-3c08d4 Boot IO Dependent Code (IODC) revision 2 HARD Booted. palo ipl root@gate.ixs.com Wed Nov 15 14:08:22 CET 2000 0/vmlinux 2143238 bytes @ 0x6800 0/palo-cmdline '0/vmlinux HOME=/ TERM=LINUX root=/dev/nfs nfsroot=192.168.1.1 ' Kernel: partition 0 file /vmlinux ELF32 executable Entry 00100120 first 00100000 n 4 Segment 0 load 00100000 size 1467884 mediaptr 0x1000 Segment 1 load 00268000 size 174520 mediaptr 0x168000 Segment 2 load 00294000 size 103180 mediaptr 0x193000 Segment 3 load 002b0000 size 8192 mediaptr 0x1ad000 branching to kernel entry point 0x00100120 Set default PSW W bit to 0 PDC Console Initialized The 32-bit Kernel has started... Enabled FP coprocessor Free memory starts at: 0xc02dc000 start_parisc(0x504d6c,0x504d6c,0x0,0x0) PALO command line: 'HOME=/ TERM=LINUX root=/dev/nfs nfsroot=192.168.1.1 ' PALO initrd 0-0 model 00005890 00000481 00000000 00000002 778314c3 100000f0 00000004 0000008a 0000008a vers 0000000d cpuid 0000016d CPUID vers 11 rev 13 Searching for devices in PDC firmware... processor hpa 0xfffa0000 a newer box... Found devices: 1. UL 350 Lasi Core BA (11) at 0xffd00000, versions 0x2e, 0x0, 0x81, 0x0, 0x0 2. UL 350 Lasi Core RS-232 (10) at 0xffd05000, versions 0x2e, 0x0, 0x8c, 0x0, 0x0 3. UL 350 Core SCSI (10) at 0xffd06000, versions 0x2e, 0x0, 0x82, 0x0, 0x80 4. UL 350 Core LAN (802.3) (10) at 0xffd07000, versions 0x2e, 0x0, 0x8a, 0x0, 0x0 5. UL 350 Core Centronics (10) at 0xffd02000, versions 0x2e, 0x0, 0x74, 0x0, 0x0 6. UL 350 Core PC Keyboard (10) at 0xffd08000, versions 0x2e, 0x0, 0x84, 0x0, 0x0 7. UL 350 Core PC Keyboard (10) at 0xffd08100, versions 0x2e, 0x0, 0x84, 0x0, 0x0 8. UL 350 Core PC Floppy (10) at 0xffd0a000, versions 0x2e, 0x0, 0x83, 0x0, 0x0 9. UL 350 Core Wax BA (11) at 0xffe00000, versions 0x30, 0x0, 0x8e, 0x0, 0x0 10. UL 350 Wax EISA BA (11) at 0xfc000000, versions 0x30, 0x0, 0x90, 0x0, 0x0 11. UL 350 Wax Core RS-232 (10) at 0xffe02000, versions 0x30, 0x0, 0x8c, 0x0, 0x0 That's a total of 11 devices. No CPUs reported by firmware - probing... Found CPU at fffa0000 CPU(s): 1 x PA7200 (PCX-T') at 101.000000 MHz Linux version 2.4.0-test10 (root@gate.ixs.com) (gcc version 2.96 20000925 (experimental)) #4 Wed Nov 15 19:06:49 CET 2000 free_bootmem(0x2dd000, 0x7d23000) pagetable_init On node 0 totalpages: 32768 zone(0): 16384 pages. zone(1): 16384 pages. zone(2): 0 pages. Kernel command line: HOME=/ TERM=LINUX root=/dev/nfs nfsroot=192.168.1.1 trap_init Calibrating delay loop... 100.76 BogoMIPS Memory: 125568k available Dentry-cache hash table entries: 16384 (order: 5, 131072 bytes) Buffer-cache hash table entries: 8192 (order: 3, 32768 bytes) Page-cache hash table entries: 32768 (order: 5, 131072 bytes) Inode-cache hash table entries: 8192 (order: 4, 65536 bytes) POSIX conformance testing by UNIFIX Lasi version 0 at 0xffd00000 found. Wax at 0xffe00000 found. Wax: HIL Keyboard-NMI registered. parport0: PC-style at 0xffd02800, irq 88 [PCSPP,TRISTATE] Found i82596 at 0xffd07000, IRQ 87 early initialization of device eth0 is deferred Initializing Lasi PS/2-keyboard port at 0xffd08000... Support for Lasi PS/2-psaux not yet available ! Linux NET4.0 for Linux 2.4 Based upon Swansea University Computer Society NET3.039 Starting kswapd v1.8 pty: 256 Unix98 ptys configured lp0: using parport0 (interrupt-driven). Dumping Stack from c7f98000 to c7f989c0: 8000 00000000 00000040 00000000 00000000 c027c32c 00000000 00000000 ffffffff 8020 00000001 00000000 00000000 00000000 00000000 00000000 ffffffff c027c244 8040 c027c244 00000031 c7f90000 c02b0000 c028160c 00000000 00000000 00000000 8060 00000000 00000000 00000000 00000001 00000000 00000000 00000000 00000000 8080 00000000 c02b0000 c02b0000 c7f84000 00000000 00000000 c7f84098 c02b0098 80a0 00000000 c02cba18 00000000 c7f980ac c7f980ac c7f980b4 c01177f4 c7f98908 80c0 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 80e0 00000000 00000000 c7f98000 c011a5e4 00000000 0000000f 00000000 00000000 8100 00000024 00000000 00000033 00000000 00000000 00000000 00000000 00000000 8120 00000000 80000000 00000000 00000000 00000000 00000000 00000000 00000000 8140 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 8160 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 8180 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 81a0 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 81c0 00000000 00000000 00000000 fffffeff 00000000 ffffffff 00000000 c027ceb8 81e0 ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff 00800000 05000000 8200 00000000 ffffffff ffffffff ffffffff 00000800 00000800 00000400 00000400 8220 ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff 00007377 61707065 8240 72000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 8260 00008000 c0269000 c0269000 c013de10 00010000 c7ffeba0 c022248c c0234898 8280 000000f0 c02db000 00000000 c0118cf0 c0269054 00008000 c0269000 c0269054 82a0 f0000068 f0000070 c027c000 c027c368 0000000b 00000024 0000003c 0000003e 82c0 c027c000 00000000 c01001dc 00000004 00000000 00000023 c02b61ef 00000000 82e0 c027c000 f0000070 f0000068 000000ff ffd05800 ffd05800 ffd05800 00000060 8300 ffffffff ffd05800 002b50c0 c0268000 00000000 00000000 c02b08c0 00000000 8320 000b0800 00000000 0000001f 00000000 0000001f 00000000 0000001f 00000000 8340 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 8360 00000010 00000020 7f7fffff ffffffff 43ebebeb e0000000 00000000 00000000 8380 45e69c6a 25b7ea20 41800000 00000000 00000010 00000010 00000000 00000000 83a0 00000040 00000080 00000100 00000200 00000400 00000800 7fffffff 7fffffff 83c0 41000000 00000000 7fffffff 7fffffff 40800000 00000000 41000000 00000000 83e0 40300000 00000000 40200000 00000000 40200000 00000000 41800000 7fffffff 8400 40000000 00000000 40000000 00000000 40800000 00000000 41000000 00000000 8420 00000000 00000000 c7f98800 c0103cf4 00000000 00000000 00000000 00000000 8440 00000000 00000000 c0118ce0 c0118ce4 40800000 00000000 00282000 00000000 8460 c0281040 c0281064 00000000 c0281204 00000000 00000000 00000000 c7f98478 8480 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 84a0 00000000 00000000 71894dcb e3642ec4 c6c85d89 8d90bb13 1b217627 3634591c 84c0 6c1e076a d84abb86 b095770d 612aee1b c2236964 8446d2c9 088da593 116dfe74 84e0 22ad49ba 452c2626 8a2ef91e c0103c48 28cd5128 51ec1702 a3ae9b56 475d36ad 8500 c7f98000 c028160c 00000000 76fd1fb2 ed8c8a36 db19146d b63228db 6c6451b7 8520 d8be163c b17c2c79 62f858f3 c01001f0 8b0c0969 161812d3 2c4690f4 58fb94ba 8540 b1819c26 6303384d c670c5c8 8ce18b91 19c31723 33f09b14 6797837a cf59b3a6 8560 9eb3674d 3d66ce9b 7abb2864 c0294ef4 ea01cb35 d403966b a8072cd7 500e59af 8580 00000000 c02b0000 81dead60 03bd5ac1 00000060 c027c35c c027c35c c025920c 85a0 7234ad2e e41fef0e c83fde1d c0294ea0 20ff7877 418845bc 83663e2a 06cc7c55 85c0 c02ad30c c02ad2cc 00000000 00000000 00000000 c7f985d4 c7f985d4 c7f985dc 85e0 c7f985dc c7f985e4 00000000 c0298ca0 00000000 c7f985d4 c7f985d4 c7f985dc 8600 c027e800 00000000 00000000 00000000 000000fa 000000f2 000000ff c0295514 8620 000000f0 c02cb800 c02b06c0 c0299814 c028160c c02ad30c c02ad2bc c028160c 8640 c02b06c0 c7f98000 c028160c c02ad30c c02ad2d0 c7f94800 c0230add 0000003e 8660 c027c000 00000001 c02b6206 c0299744 c02b61ce 00000037 c02b6206 00000000 8680 c02ad30c c02ad2d0 00000040 c02cb800 000000fa 000000f2 000000ff c0295514 86a0 000000f0 c02cb800 c02b06c0 c02a4af4 c028160c c02ad30c c02ad2d0 c7f98000 86c0 c028b800 c01e2468 ffffffff c028b1e4 c7ffc400 c028160c c024256c c0186688 86e0 c028160c c02c6104 c01e2468 c029c4e0 c028b310 c028b1b4 c7f988c0 00000000 8700 ffffffff 0000ffe0 0060b03c 08d4bcfc 00000000 00000008 c0295514 000000f0 8720 c02cb800 c028b800 c01e2468 ffffffff c028b1e4 c7ffc400 c02bfc1c c02bfe50 8740 00000063 00000008 c7f98718 c024256c 00000000 c0285038 c028b1b9 c0242340 8760 45e69c6a 25b7ea20 41800000 c029c248 00000010 00000010 00000000 00000000 8780 0004000b c02ca800 c029c248 00000000 c7ffc400 ffffffff c01e2468 c028b800 87a0 c02cb800 000000f0 00000000 000000ff 000000f2 000000fa 000000fd f0100000 87c0 f0001180 f0000070 f0000068 00000000 c7f9870e 00000002 c029c4d0 ffd07000 87e0 c7f98710 00000f20 00000000 c0268000 00000001 00000000 c7f989c0 002b31b8 8800 000b0800 00000000 0000001f 00000000 0000001f 00000000 0000001f 00000000 8820 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 8840 00000010 00000020 7f7fffff ffffffff 43ebebeb e0000000 00000000 00000000 8860 45e69c6a 25b7ea20 41800000 00000000 00000010 00000010 00000000 00000000 8880 00000040 00000080 00000100 00000200 00000400 00000800 7fffffff 7fffffff 88a0 41000000 00000000 7fffffff 7fffffff 40800000 00000000 41000000 00000000 88c0 40300000 00000000 40200000 00000000 40200000 00000000 41800000 7fffffff 88e0 40000000 00000000 40000000 00000000 40800000 00000000 41000000 00000000 8900 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 8920 00000000 00000000 c029c264 c029c268 00000000 00000000 c7f98b00 00000000 8940 00000000 00000000 0000001f 00000000 0000001f 0e681096 00000000 00000004 8960 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 8980 00000010 00000020 7f7fffff ffffffff 43ebebeb e0000000 00000000 00000000 89a0 45e69c6a 25b7ea20 41800000 c01046e0 00000010 00000010 00000000 00000000 Data access rights fault in kernel: Code=26 regs=c7f98780 (Addr=00000004) YZrvWESTHLNXBCVMcbcbcbcbOGFRQPDI PSW: 00000000000001000000000000001011 r0-3 00000000 c02ca800 c029c248 00000000 r4-7 c7ffc400 ffffffff c01e2468 c028b800 r8-11 c02cb800 000000f0 00000000 000000ff r12-15 000000f2 000000fa 000000fd f0100000 r16-19 f0001180 f0000070 f0000068 00000000 r20-23 c7f9870e 00000002 c029c4d0 ffd07000 r24-27 c7f98710 00000f20 00000000 c0268000 r28-31 00000001 00000000 c7f989c0 002b31b8 sr0-4 00000000 00000000 00000000 00000000 sr4-8 00000000 00000000 00000000 00000000 IASQ: 00000000 00000000 IAOQ: c029c264 c029c268 IIR: 0e681096 ISR: 00000000 IOR: 00000004 ORIG_R28: 00000000 --------------F7EF1B69F0A7C4C7DD54E27D-- From ixs@ixs.bb.bawue.de Wed, 15 Nov 2000 20:28:28 +0100 (CET) Date: Wed, 15 Nov 2000 20:28:28 +0100 (CET) From: Andreas Thienemann ixs@ixs.bb.bawue.de Subject: [parisc-linux] 250/1 doesn't boot but dumps stack Hi again, just to clear something up: On Thu, 16 Nov 2000, Andreas Thienemann wrote: > the pty interfaces. (I already left out everything unnecessary, such as > parallel port support) I just noticed I attached the wrong file. The attached bootlog was from a kernel that still had support for lp0. But with another kernel, this time without lp support, this errors were the same... bye, Andreas From kailasr@webcash.com Wed, 15 Nov 2000 11:26:30 -0800 Date: Wed, 15 Nov 2000 11:26:30 -0800 From: Kailashnath V Rampure kailasr@webcash.com Subject: [parisc-linux] Boot command Thomas, I mounted the /dev/sda3 on mnt and deleted every thing and recopied then rebooted. It worked. Probably there was some fault while I copied yesterday. I did not repartition the disk now. Thanks Regards Kailas At 07:10 PM 11/15/00 +0100, Thomas Marteau wrote: >Hi again, > > You put the swap partition before the f0 partition and here it is the f0 >partition in first position. > Also, your hard disk is ida instead of sda, what's that ? > >Bye, > >ESIEE Team >----- Original Message ----- >From: Kailashnath V Rampure >To: Thomas Marteau >Cc: >Sent: Wednesday, November 15, 2000 6:55 PM >Subject: Re: [parisc-linux] Boot command > > > > Yes Thomas the vmlinux is in /boot of 3rd partition as the other >partitions > > are swap and f0. > > > > At 11:48 AM 11/15/00 +0100, Thomas Marteau wrote: > > > > >----- Original Message ----- > > >From: Kailashnath V Rampure > > >To: Paul Bame > > >Cc: Grant Grundler ; Matt Taggart > > >; > > >Sent: Tuesday, November 14, 2000 11:58 PM > > >Subject: Re: [parisc-linux] Boot command > > > > > > > > > > I have booted HP A class server through network. On that I have > > >repartioned > > > > the system and followed the steps on > > >http://www.parisc-linux.org/install.html. > > > > I have used the following command to initialize the hard disk. The >kernel > > >I > > > > have downloaded is vmlinux-20001018. and cpied it to /mnt/boot/vmlinux > > > > after mounting /dev/sda3. I have used the following command to >initialize > > > > the HDD. > > > > > > > > palo -I -k /boot/vmlinux -b /boot/iplboot \ -c '3/boot/vmlinux >TERM=linux > > > > HOME=/ root=/dev/sda3' \ /dev/sda > > > > > >This means that vmlinux must be in /boot in your third partition on your > > >disk. > > >Is it true in your case? > > > > > > > -------------------------------- > > > > I get the following error: > > > > -------------------------------- > > > > SOFT Boot. > > > > palo ipl bame@noam Tue oct 31 14:18:02 MST 2000 > > > > 0/vmlinux 2138614 bytes@ 0x1f78c000 > > > > 0/palo-cmdline '3/boot/vmlinux TERM=linux HOME=/ root=/dev/sda3' > > > > /dev/ida1 82 62 1030688 > > > > /dev/ida2 f0 1030750 24738 > > > > /dev/ida3 83 1055488 1030750 > > > > Kernel:partition 3 file /boot/vmlinux > > > > ext2 block size 1024 > > > > ext2_mount(partition 3) returns 0 > > > > ext2_open(/boot/vmlinux) = -1 > > > > open /boot/vmlinux failed From bame@noam.fc.hp.com Wed, 15 Nov 2000 12:34:48 -0700 Date: Wed, 15 Nov 2000 12:34:48 -0700 From: Paul Bame bame@noam.fc.hp.com Subject: [parisc-linux] Help with posix_types.h FYI I just heard some pretty good reasons why both ino_t and off_t should be 64 bits even on 32-bit kernels. Keep those cards and letters coming! -P From grundler@cup.hp.com Wed, 15 Nov 2000 11:23:41 -0800 Date: Wed, 15 Nov 2000 11:23:41 -0800 From: Grant Grundler grundler@cup.hp.com Subject: [parisc-linux] 250/1 doesn't boot but dumps stack Andreas Thienemann wrote: > But when I try to boot up this kernel it dumps stack right after initialising > the pty interfaces. (I already left out everything unnecessary, such as > parallel port support) ... > parport0: PC-style at 0xffd02800, irq 88 [PCSPP,TRISTATE] > Found i82596 at 0xffd07000, IRQ 87 > early initialization of device eth0 is deferred > Initializing Lasi PS/2-keyboard port at 0xffd08000... > Support for Lasi PS/2-psaux not yet available ! > Linux NET4.0 for Linux 2.4 > Based upon Swansea University Computer Society NET3.039 > Starting kswapd v1.8 > pty: 256 Unix98 ptys configured > lp0: using parport0 (interrupt-driven). Are you sure you left out parallel port support? > Data access rights fault in kernel: Code=26 regs=c7f98780 (Addr=00000004) > > YZrvWESTHLNXBCVMcbcbcbcbOGFRQPDI > PSW: 00000000000001000000000000001011 > r0-3 00000000 c02ca800 c029c248 00000000 > r4-7 c7ffc400 ffffffff c01e2468 c028b800 > r8-11 c02cb800 000000f0 00000000 000000ff > r12-15 000000f2 000000fa 000000fd f0100000 > r16-19 f0001180 f0000070 f0000068 00000000 > r20-23 c7f9870e 00000002 c029c4d0 ffd07000 > r24-27 c7f98710 00000f20 00000000 c0268000 > r28-31 00000001 00000000 c7f989c0 002b31b8 > sr0-4 00000000 00000000 00000000 00000000 > sr4-8 00000000 00000000 00000000 00000000 > > IASQ: 00000000 00000000 IAOQ: c029c264 c029c268 > IIR: 0e681096 ISR: 00000000 IOR: 00000004 > ORIG_R28: 00000000 Smells like a driver bug. Can you look up IOAQ and GR2 (c029c264 and c029c248) in System.map file? grant From dave@hiauly1.hia.nrc.ca Wed, 15 Nov 2000 14:49:02 -0500 (EST) Date: Wed, 15 Nov 2000 14:49:02 -0500 (EST) From: John David Anglin dave@hiauly1.hia.nrc.ca Subject: [parisc-linux] Single-stepping > I've been helping Alan Modra out with kernel changes to support > single stepping for gdb. Paul Bame suggested I bounced our ideas > off you in case you (or anyone else) had any comments. I havn't > actually committed my changes yet. > > The basic approach is to use the recovery counter to generate > a trap every instruction. The scheme is complicated because a > suspended process may or may not return to user space via an RFI. I really don't know enough to comment on the implementation choice. Why did you decide on this approach as opposed to inserting breaks and enabling the taken branch branch trap (T)? It would appear that the recovery counter was intended to provide software recovery from hardware faults in fault tolerant systems. Possibly, Grant could comment on whether it is actually useful for this purpose. Dave -- J. David Anglin dave.anglin@nrc.ca National Research Council of Canada (613) 990-0752 (FAX: 952-6605) From j-perdue@tamu.edu Wed, 15 Nov 2000 13:53:03 -0600 Date: Wed, 15 Nov 2000 13:53:03 -0600 From: Jack Perdue j-perdue@tamu.edu Subject: [parisc-linux] nfsroot - 712/60 - RPC - help Howdy Puffins and others, I have a 712/60 here that I bought for the purpose of playing with PARISC linux. It came w/HP-UX 9.0 which I don't want to wax just yet (e.g. for ioscan and other HP-UX utils). I don't have a CD for it, so I've been trying to get NFSROOT to work. The 712/60 is known as pancho. The bootp server is named blacktower. I've unzipped nfsroot-20000804.tgz as /tftpboot/pancho and exported it to the local net. I can mount it from an i386 RH6.2 box, but I think I'm having problems accessing it from PA-RISC linux. Below are some of my config files, the output from bootp and two attempts at booting the 712/60... one with debugging turned on in net/sunrpc/sysctl.c. I'm kinda stumped. Can anyone see where I've gone wrong? Some notes: a) I've tried NFSROOT=192.168.1.11 and NFSROOT=192.168.1.11/tftpboot/vmlinux in palo/Makefile and the results are the same (both suggestions were made to this list at some point) b) I tried the APRICOT drivers, but the kernel would never see the net interface so I've switched to the LASI_82596 driver (doing both resulted in dupe symbols). The LASI driver seems to get much further. c) my sources were updated today from the puffin's CVS tree. The kernel booting below was built on those sources. d) with debugging on, I get: Root-NFS: Unable to get nfsd port number from server, using default Root-NFS: Portmapper on server returned 2049 as nfsd port however, with the debugging off, I only get: Root-NFS: Unable to get nfsd port number from server, using default portmap and rpc.mountd are running on blacktower. Why the conflicting report when debug is on? e) the final message in /var/log/messages is always "tftpd: read: Connection refused". My hosts.allow and hosts.deny files are empty so they shouldn't be the problem. And, as mentioned I can NFS mount the directory. Is this the problem and if so, what is the solution??? Any help on how I can resolve this problem is appreciated. TIA, jack j-perdue@tamu.edu ========== blacktower:/etc/exports ========== /tftpboot/pancho 192.168.1.0/255.255.255.0(rw,no_root_squash) ========== blacktower:/etc/bootptab ========== pancho:\ :hd=/tftpboot:\ :bf=vmlinux:\ :ht=ether:\ :ha=08000993DA02:\ :sm=255.255.255.0:\ :hn:\ :ip=192.168.1.13:\ :vm=rfc1048: ========== bootpd output ========== [root@blacktower rc.d]# /usr/sbin/bootpd -d 20 bootpd: info(6): bootptab mtime: Wed Nov 15 13:02:44 2000 bootpd: info(6): reading "/etc/bootptab" bootpd: info(6): read 1 entries (1 hosts) from "/etc/bootptab" bootpd: info(6): recvd pkt from IP addr 0.0.0.0 bootpd: info(6): bootptab mtime: Wed Nov 15 13:02:44 2000 bootpd: info(6): request from Ethernet address 08:00:09:93:DA:02 bootpd: info(6): found 192.168.1.13 (pancho) bootpd: info(6): bootfile="/tftpboot/vmlinux" bootpd: info(6): vendor magic field is 99.130.83.99 bootpd: info(6): sending reply (with RFC1048 options) bootpd: info(6): setarp 192.168.1.13 - 08:00:09:93:DA:02 bootpd: info(6): recvd pkt from IP addr 0.0.0.0 bootpd: info(6): bootptab mtime: Wed Nov 15 13:02:44 2000 bootpd: info(6): request from Ethernet address 08:00:09:93:DA:02 bootpd: info(6): found 192.168.1.13 (pancho) bootpd: info(6): bootfile="/tftpboot/vmlinux" bootpd: info(6): vendor magic field is 99.130.83.99 bootpd: info(6): request message length=364 bootpd: info(6): extended reply, length=364, options=128 bootpd: info(6): sending reply (with RFC1048 options) bootpd: info(6): setarp 192.168.1.13 - 08:00:09:93:DA:02 ========== from /var/log/messages ========== Nov 15 13:02:20 blacktower bootpd[1320]: version 2.4.3 Nov 15 13:02:20 blacktower bootpd[1320]: bootptab mtime: Wed Oct 12 00:41:28 1994 Nov 15 13:02:20 blacktower bootpd[1320]: reading "/etc/bootptab" Nov 15 13:02:20 blacktower bootpd[1320]: read 1 entries (1 hosts) from "/etc/bootptab" Nov 15 13:02:47 blacktower bootpd[1323]: version 2.4.3 Nov 15 13:02:47 blacktower bootpd[1323]: bootptab mtime: Wed Nov 15 13:02:44 2000 Nov 15 13:02:47 blacktower bootpd[1323]: reading "/etc/bootptab" Nov 15 13:02:47 blacktower bootpd[1323]: read 1 entries (1 hosts) from "/etc/bootptab" Nov 15 13:04:34 blacktower bootpd[1323]: recvd pkt from IP addr 0.0.0.0 Nov 15 13:04:34 blacktower bootpd[1323]: bootptab mtime: Wed Nov 15 13:02:44 2000 Nov 15 13:04:34 blacktower bootpd[1323]: request from Ethernet address 08:00:09:93:DA:02 Nov 15 13:04:34 blacktower bootpd[1323]: found 192.168.1.13 (pancho) Nov 15 13:04:34 blacktower bootpd[1323]: bootfile="/tftpboot/vmlinux" Nov 15 13:04:34 blacktower bootpd[1323]: vendor magic field is 99.130.83.99 Nov 15 13:04:34 blacktower bootpd[1323]: sending reply (with RFC1048 options) Nov 15 13:04:34 blacktower bootpd[1323]: setarp 192.168.1.13 - 08:00:09:93:DA:02 Nov 15 13:04:35 blacktower tftpd[1325]: tftpd: trying to get file: /tftpboot/vmlinux Nov 15 13:04:36 blacktower tftpd[1327]: tftpd: trying to get file: /tftpboot/vmlinux Nov 15 13:04:47 blacktower bootpd[1323]: recvd pkt from IP addr 0.0.0.0 Nov 15 13:04:47 blacktower bootpd[1323]: bootptab mtime: Wed Nov 15 13:02:44 2000 Nov 15 13:04:47 blacktower bootpd[1323]: request from Ethernet address 08:00:09:93:DA:02 Nov 15 13:04:47 blacktower bootpd[1323]: found 192.168.1.13 (pancho) Nov 15 13:04:47 blacktower bootpd[1323]: bootfile="/tftpboot/vmlinux" Nov 15 13:04:47 blacktower bootpd[1323]: vendor magic field is 99.130.83.99 Nov 15 13:04:47 blacktower bootpd[1323]: request message length=364 Nov 15 13:04:47 blacktower bootpd[1323]: extended reply, length=364, options=128 Nov 15 13:04:47 blacktower bootpd[1323]: sending reply (with RFC1048 options) Nov 15 13:04:47 blacktower bootpd[1323]: setarp 192.168.1.13 - 08:00:09:93:DA:02 Nov 15 13:04:53 blacktower tftpd[1327]: tftpd: read: Connection refused ========== console output (no RPC debug) ========== ---------------------------------------------------------------------------- BootRom Version 1.5 Memory Size: 32 MB ---------------------------------------------------------------------------- (c) Copyright 1990-1993, Hewlett-Packard Company. All rights reserved Press to stop boot sequence. Selecting a system to boot. Booting palo ipl jkp2866@redtower Wed Nov 15 12:44:21 CST 2000 0/vmlinux 1606438 bytes @ 0x6800 0/palo-cmdline '0/vmlinux HOME=/ TERM=LINUX root=/dev/nfs nfsroot=192.68.1.11:/tftpboot/pancho ' Kernel: partition 0 file /vmlinux ELF32 executable Entry 00100000 first 00100000 n 4 Segment 0 load 00100000 size 1097900 mediaptr 0x1000 Segment 1 load 0020e000 size 150520 mediaptr 0x10e000 Segment 2 load 00234000 size 55900 mediaptr 0x133000 Segment 3 load 00244000 size 8192 mediaptr 0x141000 branching to kernel entry point 0x00100000 Set default PSW W bit to 0 PDC Console Initialized The 32-bit Kernel has started... Enabled FP coprocessor Free memory starts at: 0xc026e000 start_parisc(0x504d6c,0x504d6c,0x0,0x0) PALO command line: 'HOME=/ TERM=LINUX root=/dev/nfs nfsroot=192.68.1.11:/tftpboot/pancho ' PALO initrd 0-0 model 00006000 00000481 00000000 00000000 77564139 00000000 00000004 00000072 00000072 vers 0000000a CPUID vers 0 rev 0 Searching for devices in PDC firmware... processor hpa 0xfffbe000 an older box... Found devices: 1. Gecko GSC Core Graphics (10) at 0xf8000000, versions 0x16, 0x0, 0x85, 0x0, 0x0 2. Gecko Core BA (11) at 0xf0100000, versions 0x16, 0x0, 0x81, 0x0, 0x0 3. Gecko Core SCSI (10) at 0xf0106000, versions 0x16, 0x0, 0x82, 0x0, 0x0 4. Gecko Core Lan (802.3) (10) at 0xf0107000, versions 0x16, 0x0, 0x8a, 0x0, 0x0 5. Gecko Core RS-232 (10) at 0xf0105000, versions 0x16, 0x0, 0x8c, 0x0, 0x0 6. Gecko Core Centronics (10) at 0xf0102000, versions 0x16, 0x0, 0x74, 0x0, 0x0 7. Gecko Audio (10) at 0xf0104000, versions 0x16, 0x0, 0x7b, 0x0, 0x0 8. Gecko Core PC Floppy (10) at 0xf010a000, versions 0x16, 0x0, 0x83, 0x0, 0x0 9. Gecko Core PC Keyboard (10) at 0xf0108000, versions 0x16, 0x0, 0x84, 0x0, 0x0 10. Gecko Core PC Keyboard (10) at 0xf0108100, versions 0x16, 0x0, 0x84, 0x0, 0x0 11. Gecko (712/60) (0) at 0xfffbe000, versions 0x600, 0x0, 0x4, 0x0, 0x81 12. Gecko (1) at 0xfffbf000, versions 0x26, 0x0, 0x9, 0x0, 0x0 That's a total of 12 devices. CPU(s): 1 x PA7100LC (PCX-L) at 60.000000 MHz Linux version 2.4.0-test10 (jkp2866@redtower) (gcc version 2.96 20000925 (experimental)) #16 Wed Nov 15 14:01:38 CST 2000 free_bootmem(0x26e400, 0x1d91c00) pagetable_init On node 0 totalpages: 8192 zone(0): 4096 pages. zone(1): 4096 pages. zone(2): 0 pages. Kernel command line: HOME=/ TERM=LINUX root=/dev/nfs nfsroot=192.68.1.11:/tftpboot/pancho trap_init Calibrating delay loop... 59.80 BogoMIPS Memory: 29632k available Dentry-cache hash table entries: 4096 (order: 3, 32768 bytes) Buffer-cache hash table entries: 1024 (order: 0, 4096 bytes) Page-cache hash table entries: 8192 (order: 3, 32768 bytes) Inode-cache hash table entries: 2048 (order: 2, 16384 bytes) POSIX conformance testing by UNIFIX Lasi version 0 at 0xf0100000 found. Found i82596 at 0xf0107000, IRQ 87 early initialization of device eth0 is deferred Linux NET4.0 for Linux 2.4 Based upon Swansea University Computer Society NET3.039 Starting kswapd v1.8 pty: 256 Unix98 ptys configured eth0: 82596 at 0xf0107000, 08 00 09 93 DA 02 IRQ 87. 82596.c $Revision: 1.14 $ Serial driver version 5.02 (2000-08-09) with MANY_PORTS SHARE_IRQ SERIAL_PCI enabled ttyS00 at iomem 0xf0105800 (irq = 90) is a 16550A NET4: Linux TCP/IP 1.0 for NET4.0 IP Protocols: ICMP, UDP, TCP IP: routing cache hash table of 512 buckets, 4Kbytes TCP: Hash tables configured (established 2048 bind 2048) eth0: link ok. Sending BOOTP requests.... OK IP-Config: Got BOOTP answer from 192.168.1.11, my address is 192.168.1.13 Switching from PDC console kmem_create: Forcing size word alignment - nfs_fh Looking up port of RPC 100003/2 on 192.68.1.11 RPC: sendmsg returned error 229 portmap: RPC call returned error 229 Root-NFS: Unable to get nfsd port number from server, using default Looking up port of RPC 100005/2 on 192.68.1.11 RPC: sendmsg returned error 229 portmap: RPC call returned error 229 Root-NFS: Unable to get mountd port number from server, using default RPC: sendmsg returned error 229 mount: RPC call returned error 229 Root-NFS: Server returned error -229 while mounting /tftpboot/pancho VFS: Unable to mount root fs via NFS, trying floppy. VFS: Cannot open root device "nfs" or 02:00 Please append a correct "root=" boot option Kernel panic: VFS: Unable to mount root fs on 02:00 ========== console output (with RPC debug) ========== ---------------------------------------------------------------------------- BootRom Version 1.5 Memory Size: 32 MB ---------------------------------------------------------------------------- (c) Copyright 1990-1993, Hewlett-Packard Company. All rights reserved Press to stop boot sequence. Selecting a system to boot. Booting palo ipl jkp2866@redtower Wed Nov 15 12:44:21 CST 2000 0/vmlinux 1606438 bytes @ 0x6800 0/palo-cmdline '0/vmlinux HOME=/ TERM=LINUX root=/dev/nfs nfsroot=192.68.1.11:/tftpboot/pancho ' Kernel: partition 0 file /vmlinux ELF32 executable Entry 00100000 first 00100000 n 4 Segment 0 load 00100000 size 1097900 mediaptr 0x1000 Segment 1 load 0020e000 size 150520 mediaptr 0x10e000 Segment 2 load 00234000 size 55900 mediaptr 0x133000 Segment 3 load 00244000 size 8192 mediaptr 0x141000 branching to kernel entry point 0x00100000 Set default PSW W bit to 0 PDC Console Initialized The 32-bit Kernel has started... Enabled FP coprocessor Free memory starts at: 0xc026e000 start_parisc(0x504d6c,0x504d6c,0x0,0x0) PALO command line: 'HOME=/ TERM=LINUX root=/dev/nfs nfsroot=192.68.1.11:/tftpboot/pancho ' PALO initrd 0-0 model 00006000 00000481 00000000 00000000 77564139 00000000 00000004 00000072 00000072 vers 0000000a CPUID vers 0 rev 0 Searching for devices in PDC firmware... processor hpa 0xfffbe000 an older box... Found devices: 1. Gecko GSC Core Graphics (10) at 0xf8000000, versions 0x16, 0x0, 0x85, 0x0, 0x0 2. Gecko Core BA (11) at 0xf0100000, versions 0x16, 0x0, 0x81, 0x0, 0x0 3. Gecko Core SCSI (10) at 0xf0106000, versions 0x16, 0x0, 0x82, 0x0, 0x0 4. Gecko Core Lan (802.3) (10) at 0xf0107000, versions 0x16, 0x0, 0x8a, 0x0, 0x0 5. Gecko Core RS-232 (10) at 0xf0105000, versions 0x16, 0x0, 0x8c, 0x0, 0x0 6. Gecko Core Centronics (10) at 0xf0102000, versions 0x16, 0x0, 0x74, 0x0, 0x0 7. Gecko Audio (10) at 0xf0104000, versions 0x16, 0x0, 0x7b, 0x0, 0x0 8. Gecko Core PC Floppy (10) at 0xf010a000, versions 0x16, 0x0, 0x83, 0x0, 0x0 9. Gecko Core PC Keyboard (10) at 0xf0108000, versions 0x16, 0x0, 0x84, 0x0, 0x0 10. Gecko Core PC Keyboard (10) at 0xf0108100, versions 0x16, 0x0, 0x84, 0x0, 0x0 11. Gecko (712/60) (0) at 0xfffbe000, versions 0x600, 0x0, 0x4, 0x0, 0x81 12. Gecko (1) at 0xfffbf000, versions 0x26, 0x0, 0x9, 0x0, 0x0 That's a total of 12 devices. CPU(s): 1 x PA7100LC (PCX-L) at 60.000000 MHz Linux version 2.4.0-test10 (jkp2866@redtower) (gcc version 2.96 20000925 (experimental)) #15 Wed Nov 15 13:48:41 CST 2000 free_bootmem(0x26e400, 0x1d91c00) pagetable_init On node 0 totalpages: 8192 zone(0): 4096 pages. zone(1): 4096 pages. zone(2): 0 pages. Kernel command line: HOME=/ TERM=LINUX root=/dev/nfs nfsroot=192.68.1.11:/tftpboot/pancho trap_init Calibrating delay loop... 59.80 BogoMIPS Memory: 29632k available Dentry-cache hash table entries: 4096 (order: 3, 32768 bytes) Buffer-cache hash table entries: 1024 (order: 0, 4096 bytes) Page-cache hash table entries: 8192 (order: 3, 32768 bytes) Inode-cache hash table entries: 2048 (order: 2, 16384 bytes) POSIX conformance testing by UNIFIX Lasi version 0 at 0xf0100000 found. Found i82596 at 0xf0107000, IRQ 87 early initialization of device eth0 is deferred Linux NET4.0 for Linux 2.4 Based upon Swansea University Computer Society NET3.039 Starting kswapd v1.8 pty: 256 Unix98 ptys configured eth0: 82596 at 0xf0107000, 08 00 09 93 DA 02 IRQ 87. 82596.c $Revision: 1.14 $ Serial driver version 5.02 (2000-08-09) with MANY_PORTS SHARE_IRQ SERIAL_PCI enabled ttyS00 at iomem 0xf0105800 (irq = 90) is a 16550A NET4: Linux TCP/IP 1.0 for NET4.0 IP Protocols: ICMP, UDP, TCP IP: routing cache hash table of 512 buckets, 4Kbytes TCP: Hash tables configured (established 2048 bind 2048) eth0: link ok. Sending BOOTP requests.... OK IP-Config: Got BOOTP answer from 192.168.1.11, my address is 192.168.1.13 Switching from PDC console kmem_create: Forcing size word alignment - nfs_fh RPC: registering /proc/net/rpc RPC: registering /proc/net/rpc/nfs Looking up port of RPC 100003/2 on 192.68.1.11 RPC: rpc_getport_external(192.68.1.11, 100003, 2, 17) RPC: xprt_create_proto called RPC: xprt_create_socket(udp 17) RPC: setting up UDP transport... RPC: created transport c1fa4000 RPC: creating portmap client for 192.68.1.11 (xprt c1fa4000) RPC: allocated buffer c1faa5a0 RPC: creating NULL authenticator for client c1faa5a0 RPC: allocated buffer c1fe6460 RPC: 0 new task procpid 1 RPC: 0 looking up NULL cred RPC: allocated buffer c1fe5500 RPC: 0 rpc_execute flgs 0 RPC: 0 call_reserve RPC: 0 xprt_reserve cong = 0 cwnd = 256 RPC: 0 reserved req c1fa4064 xid 11582000 RPC: 0 xprt_reserve returns 0 RPC: 0 call_reserveresult (status 0) RPC: 0 call_allocate (status 0) RPC: allocated buffer c1fb3800 RPC: 0 call_encode (status 0) RPC: 0 marshaling NULL cred c1fe5500 RPC: xdr_encode_mapping(100003, 2, 17, 0) RPC: 0 call_transmit (status 0) RPC: 0 xprt_transmit(11582000) RPC: 0 xprt_receive RPC: 0 sleep_on(queue "xprt_pending" time 89) RPC: 0 added to queue c1fa4048 "xprt_pending" RPC: xprt_sendmsg(56) = -229 RPC: sendmsg returned error 229 RPC: 0 __rpc_wake_up_task (now 93 inh 0) RPC: 0 disabling timer RPC: 0 removed from queue c1fa4048 "xprt_pending" RPC: __rpc_wake_up_task done RPC: wake_up_next(c1fa4040 "xprt_sending") RPC: 0 call_status (status -229) portmap: RPC call returned error 229 RPC: 0 exit() = -229 RPC: 0 release task RPC: 0 disabling timer RPC: 0 release request c1fa4064 RPC: wake_up_next(c1fa4050 "xprt_backlog") RPC: 0 releasing NULL cred c1fe5500 RPC: rpc_release_client(c1faa5a0, 1) RPC: destroying portmap client for 192.68.1.11 RPC: destroying NULL authenticator c1fe6460 RPC: destroying transport c1fa4000 RPC: disconnected transport c1fa4000 Root-NFS: Unable to get nfsd port number from server, using default Root-NFS: Portmapper on server returned 2049 as nfsd port Looking up port of RPC 100005/2 on 192.68.1.11 RPC: rpc_getport_external(192.68.1.11, 100005, 2, 17) RPC: xprt_create_proto called RPC: xprt_create_socket(udp 17) RPC: setting up UDP transport... RPC: created transport c1fa4000 RPC: creating portmap client for 192.68.1.11 (xprt c1fa4000) RPC: allocated buffer c1faa5a0 RPC: creating NULL authenticator for client c1faa5a0 RPC: allocated buffer c1fe6460 RPC: 1 new task procpid 1 RPC: 1 looking up NULL cred RPC: allocated buffer c1fe5500 RPC: 1 rpc_execute flgs 0 RPC: 1 call_reserve RPC: 1 xprt_reserve cong = 0 cwnd = 256 RPC: 1 reserved req c1fa4064 xid 11582001 RPC: 1 xprt_reserve returns 0 RPC: 1 call_reserveresult (status 0) RPC: 1 call_allocate (status 0) RPC: allocated buffer c1fb3800 RPC: 1 call_encode (status 0) RPC: 1 marshaling NULL cred c1fe5500 RPC: xdr_encode_mapping(100005, 2, 17, 0) RPC: 1 call_transmit (status 0) RPC: 1 xprt_transmit(11582001) RPC: 1 xprt_receive RPC: 1 sleep_on(queue "xprt_pending" time 140) RPC: 1 added to queue c1fa4048 "xprt_pending" RPC: xprt_sendmsg(56) = -229 RPC: sendmsg returned error 229 RPC: 1 __rpc_wake_up_task (now 144 inh 0) RPC: 1 disabling timer RPC: 1 removed from queue c1fa4048 "xprt_pending" RPC: __rpc_wake_up_task done RPC: wake_up_next(c1fa4040 "xprt_sending") RPC: 1 call_status (status -229) portmap: RPC call returned error 229 RPC: 1 exit() = -229 RPC: 1 release task RPC: 1 disabling timer RPC: 1 release request c1fa4064 RPC: wake_up_next(c1fa4050 "xprt_backlog") RPC: 1 releasing NULL cred c1fe5500 RPC: rpc_release_client(c1faa5a0, 1) RPC: destroying portmap client for 192.68.1.11 RPC: destroying NULL authenticator c1fe6460 RPC: destroying transport c1fa4000 RPC: disconnected transport c1fa4000 Root-NFS: Unable to get mountd port number from server, using default Root-NFS: mountd port is 627 NFS: nfs_mount(c044010b:/tftpboot/pancho) RPC: xprt_create_proto called RPC: xprt_create_socket(udp 17) RPC: setting up UDP transport... RPC: created transport c1fa4000 RPC: creating mount client for 192.68.1.11 (xprt c1fa4000) RPC: allocated buffer c1faa5a0 RPC: creating NULL authenticator for client c1faa5a0 RPC: allocated buffer c1fe6460 RPC: 2 new task procpid 1 RPC: 2 looking up NULL cred RPC: allocated buffer c1fe5500 RPC: 2 rpc_execute flgs 0 RPC: 2 call_reserve RPC: 2 xprt_reserve cong = 0 cwnd = 256 RPC: 2 reserved req c1fa4064 xid 11582002 RPC: 2 xprt_reserve returns 0 RPC: 2 call_reserveresult (status 0) RPC: 2 call_allocate (status 0) RPC: allocated buffer c1fa3000 RPC: 2 call_encode (status 0) RPC: 2 marshaling NULL cred c1fe5500 RPC: 2 call_transmit (status 0) RPC: 2 xprt_transmit(11582002) RPC: 2 xprt_receive RPC: 2 sleep_on(queue "xprt_pending" time 189) RPC: 2 added to queue c1fa4048 "xprt_pending" RPC: xprt_sendmsg(60) = -229 RPC: sendmsg returned error 229 RPC: 2 __rpc_wake_up_task (now 193 inh 0) RPC: 2 disabling timer RPC: 2 removed from queue c1fa4048 "xprt_pending" RPC: __rpc_wake_up_task done RPC: wake_up_next(c1fa4040 "xprt_sending") RPC: 2 call_status (status -229) mount: RPC call returned error 229 RPC: 2 exit() = -229 RPC: 2 release task RPC: 2 disabling timer RPC: 2 release request c1fa4064 RPC: wake_up_next(c1fa4050 "xprt_backlog") RPC: 2 releasing NULL cred c1fe5500 RPC: rpc_release_client(c1faa5a0, 1) RPC: destroying mount client for 192.68.1.11 RPC: destroying NULL authenticator c1fe6460 RPC: destroying transport c1fa4000 RPC: disconnected transport c1fa4000 Root-NFS: Server returned error -229 while mounting /tftpboot/pancho VFS: Unable to mount root fs via NFS, trying floppy. VFS: Cannot open root device "nfs" or 02:00 Please append a correct "root=" boot option Kernel panic: VFS: Unable to mount root fs on 02:00 ========== linux/.config ========== # # Automatically generated make config: don't edit # CONFIG_PARISC=y # CONFIG_UID16 is not set # # Code maturity level options # CONFIG_EXPERIMENTAL=y # # General options # # CONFIG_SMP is not set # CONFIG_KWDB is not set CONFIG_GSC=y # CONFIG_IOMMU_CCIO is not set CONFIG_GSC_LASI=y CONFIG_PCI=y CONFIG_GSC_DINO=y # CONFIG_PCI_LBA is not set # # Loadable module support # # CONFIG_MODULES is not set # # General setup # CONFIG_NET=y CONFIG_SYSVIPC=y # CONFIG_BSD_PROCESS_ACCT is not set CONFIG_SYSCTL=y CONFIG_BINFMT_SOM=y # CONFIG_BINFMT_ELF is not set # CONFIG_BINFMT_MISC is not set # CONFIG_BINFMT_JAVA is not set # # Parallel port support # # CONFIG_PARPORT is not set # # Block devices # # CONFIG_BLK_DEV_FD is not set # CONFIG_BLK_DEV_XD is not set # CONFIG_PARIDE is not set # CONFIG_BLK_CPQ_DA is not set # CONFIG_BLK_CPQ_CISS_DA is not set # CONFIG_BLK_DEV_DAC960 is not set # CONFIG_BLK_DEV_LOOP is not set # CONFIG_BLK_DEV_NBD is not set # CONFIG_BLK_DEV_RAM is not set # CONFIG_BLK_DEV_INITRD is not set # # Networking options # # CONFIG_PACKET is not set # CONFIG_NETLINK is not set # CONFIG_NETFILTER is not set # CONFIG_FILTER is not set # CONFIG_UNIX is not set CONFIG_INET=y # CONFIG_IP_MULTICAST is not set # CONFIG_IP_ADVANCED_ROUTER is not set CONFIG_IP_PNP=y CONFIG_IP_PNP_BOOTP=y # CONFIG_IP_PNP_RARP is not set # CONFIG_NET_IPIP is not set # CONFIG_NET_IPGRE is not set # CONFIG_INET_ECN is not set # CONFIG_SYN_COOKIES is not set # CONFIG_IPV6 is not set # CONFIG_KHTTPD is not set # CONFIG_ATM is not set # # # # CONFIG_IPX is not set # CONFIG_ATALK is not set # CONFIG_DECNET is not set # CONFIG_BRIDGE is not set # CONFIG_X25 is not set # CONFIG_LAPB is not set # CONFIG_LLC is not set # CONFIG_NET_DIVERT is not set # CONFIG_ECONET is not set # CONFIG_WAN_ROUTER is not set # CONFIG_NET_FASTROUTE is not set # CONFIG_NET_HW_FLOWCONTROL is not set # # QoS and/or fair queueing # # CONFIG_NET_SCHED is not set # # SCSI support # # CONFIG_SCSI is not set # # Network device support # CONFIG_NETDEVICES=y CONFIG_LASI_82596=y # # ARCnet devices # # CONFIG_ARCNET is not set # CONFIG_DUMMY is not set # CONFIG_BONDING is not set # CONFIG_EQUALIZER is not set # CONFIG_TUN is not set # CONFIG_NET_SB1000 is not set # # Ethernet (10 or 100Mbit) # CONFIG_NET_ETHERNET=y # CONFIG_NET_VENDOR_3COM is not set # CONFIG_LANCE is not set # CONFIG_NET_VENDOR_SMC is not set # CONFIG_NET_VENDOR_RACAL is not set # CONFIG_AT1700 is not set # CONFIG_DEPCA is not set # CONFIG_HP100 is not set # CONFIG_NET_ISA is not set CONFIG_NET_PCI=y # CONFIG_PCNET32 is not set # CONFIG_ADAPTEC_STARFIRE is not set # CONFIG_AC3200 is not set # CONFIG_APRICOT is not set # CONFIG_CS89x0 is not set # CONFIG_DE4X5 is not set # CONFIG_TULIP is not set # CONFIG_DGRS is not set # CONFIG_DM9102 is not set # CONFIG_EEPRO100 is not set # CONFIG_LNE390 is not set # CONFIG_NATSEMI is not set # CONFIG_NE2K_PCI is not set # CONFIG_NE3210 is not set # CONFIG_ES3210 is not set # CONFIG_RTL8129 is not set # CONFIG_8139TOO is not set # CONFIG_SIS900 is not set # CONFIG_EPIC100 is not set # CONFIG_SUNDANCE is not set # CONFIG_TLAN is not set # CONFIG_VIA_RHINE is not set # CONFIG_WINBOND_840 is not set # CONFIG_NET_POCKET is not set # # Ethernet (1000 Mbit) # # CONFIG_ACENIC is not set # CONFIG_HAMACHI is not set # CONFIG_YELLOWFIN is not set # CONFIG_SK98LIN is not set # CONFIG_FDDI is not set # CONFIG_HIPPI is not set # CONFIG_PPP is not set # CONFIG_SLIP is not set # # Wireless LAN (non-hamradio) # # CONFIG_NET_RADIO is not set # # Token Ring devices # # CONFIG_TR is not set # CONFIG_NET_FC is not set # CONFIG_RCPCI is not set # CONFIG_SHAPER is not set # # Wan interfaces # # CONFIG_WAN is not set # # Character devices # # CONFIG_VT is not set CONFIG_SERIAL=y CONFIG_SERIAL_CONSOLE=y CONFIG_SERIAL_GSC=y CONFIG_SERIAL_EXTENDED=y # CONFIG_SERIAL_MANY_PORTS is not set # CONFIG_SERIAL_SHARE_IRQ is not set # CONFIG_SERIAL_DETECT_IRQ is not set # CONFIG_SERIAL_MULTIPORT is not set # CONFIG_HUB6 is not set # CONFIG_SERIAL_NONSTANDARD is not set CONFIG_UNIX98_PTYS=y CONFIG_UNIX98_PTY_COUNT=256 # # I2C support # # CONFIG_I2C is not set # # Mice # # CONFIG_BUSMOUSE is not set # CONFIG_MOUSE is not set # # Joysticks # # CONFIG_JOYSTICK is not set # # Input core support is needed for joysticks # # CONFIG_QIC02_TAPE is not set # # Watchdog Cards # # CONFIG_WATCHDOG is not set # CONFIG_GENRTC is not set # CONFIG_INTEL_RNG is not set # CONFIG_NVRAM is not set # CONFIG_RTC is not set # CONFIG_DTLK is not set # CONFIG_R3964 is not set # CONFIG_APPLICOM is not set # # Ftape, the floppy tape device driver # # CONFIG_FTAPE is not set # CONFIG_AGP is not set # CONFIG_DRM is not set # # File systems # # CONFIG_QUOTA is not set # CONFIG_AUTOFS_FS is not set # CONFIG_AUTOFS4_FS is not set # CONFIG_ADFS_FS is not set # CONFIG_ADFS_FS_RW is not set # CONFIG_AFFS_FS is not set # CONFIG_HFS_FS is not set # CONFIG_BFS_FS is not set # CONFIG_FAT_FS is not set # CONFIG_MSDOS_FS is not set # CONFIG_UMSDOS_FS is not set # CONFIG_VFAT_FS is not set # CONFIG_EFS_FS is not set # CONFIG_JFFS_FS is not set # CONFIG_CRAMFS is not set # CONFIG_RAMFS is not set CONFIG_ISO9660_FS=y # CONFIG_JOLIET is not set # CONFIG_MINIX_FS is not set # CONFIG_NTFS_FS is not set # CONFIG_NTFS_RW is not set # CONFIG_HPFS_FS is not set CONFIG_PROC_FS=y # CONFIG_DEVFS_FS is not set # CONFIG_DEVFS_MOUNT is not set # CONFIG_DEVFS_DEBUG is not set # CONFIG_DEVPTS_FS is not set # CONFIG_QNX4FS_FS is not set # CONFIG_QNX4FS_RW is not set # CONFIG_ROMFS_FS is not set CONFIG_EXT2_FS=y # CONFIG_SYSV_FS is not set # CONFIG_SYSV_FS_WRITE is not set # CONFIG_UDF_FS is not set # CONFIG_UDF_RW is not set # CONFIG_UFS_FS is not set # CONFIG_UFS_FS_WRITE is not set # # Network File Systems # # CONFIG_CODA_FS is not set CONFIG_NFS_FS=y # CONFIG_NFS_V3 is not set CONFIG_ROOT_NFS=y # CONFIG_NFSD is not set # CONFIG_NFSD_V3 is not set CONFIG_SUNRPC=y CONFIG_LOCKD=y # CONFIG_SMB_FS is not set # CONFIG_NCP_FS is not set # CONFIG_NCPFS_PACKET_SIGNING is not set # CONFIG_NCPFS_IOCTL_LOCKING is not set # CONFIG_NCPFS_STRONG is not set # CONFIG_NCPFS_NFS_NS is not set # CONFIG_NCPFS_OS2_NS is not set # CONFIG_NCPFS_SMALLDOS is not set # CONFIG_NCPFS_MOUNT_SUBDIR is not set # CONFIG_NCPFS_NDS_DOMAINS is not set # CONFIG_NCPFS_NLS is not set # CONFIG_NCPFS_EXTRAS is not set # # Partition Types # # CONFIG_PARTITION_ADVANCED is not set CONFIG_MSDOS_PARTITION=y # CONFIG_NLS is not set # # Sound Drivers # # CONFIG_SOUND is not set # # Kernel hacking # # CONFIG_MAGIC_SYSRQ is not set From grundler@cup.hp.com Wed, 15 Nov 2000 12:10:36 -0800 Date: Wed, 15 Nov 2000 12:10:36 -0800 From: Grant Grundler grundler@cup.hp.com Subject: [parisc-linux] nfsroot - 712/60 - RPC - help Jack Perdue wrote: Two changes: > a) I've tried NFSROOT=192.168.1.11 and NFSROOT=192.168.1.11/tftpboot/vmlinux > in palo/Makefile and the results are the same (both suggestions were > made to this list at some point) Try NFSROOT=192.168.1.11/tftpboot/pancho > ========== blacktower:/etc/bootptab ========== > pancho:\ > :hd=/tftpboot:\ > :bf=vmlinux:\ > :ht=ether:\ > :ha=08000993DA02:\ > :sm=255.255.255.0:\ > :hn:\ > :ip=192.168.1.13:\ > :vm=rfc1048: This is just a nit: bf= might be better named ":bf=lifimage\" (and you only need one colon between entry's :^) Copy /palo/lifimage to /tftpboot/lifimage. There must be something wrong but I don't see it. grant > kmem_create: Forcing size word alignment - nfs_fh > Looking up port of RPC 100003/2 on 192.68.1.11 > RPC: sendmsg returned error 229 > portmap: RPC call returned error 229 I don't see these types of errors on my config. Could be related to the misdirected NFSROOT. grant Grant Grundler Unix Systems Enablement Lab +1.408.447.7253 From j-perdue@tamu.edu Wed, 15 Nov 2000 14:14:13 -0600 Date: Wed, 15 Nov 2000 14:14:13 -0600 From: Jack Perdue j-perdue@tamu.edu Subject: Doh!!! was Re: [parisc-linux] nfsroot - 712/60 - RPC - help Of course, as soon I collected all that info and sent it I, in rereading, realized that I had put 192.68.1.11 in palo/Makefile instead of 192.168.1.11. Doh! However, since the info is out there now, can someone tell me what I need to resolve the following: [previous console output in previous mail] Switching from PDC console kmem_create: Forcing size word alignment - nfs_fh Looking up port of RPC 100003/2 on 192.168.1.11 Looking up port of RPC 100005/2 on 192.168.1.11 VFS: Mounted root (nfs filesystem) readonly. Kernel panic: No init found. Try passing init= option to kernel. jack j-perdue@tamu.edu From law@redhat.com Wed, 15 Nov 2000 13:30:59 -0700 Date: Wed, 15 Nov 2000 13:30:59 -0700 From: law@redhat.com law@redhat.com Subject: [parisc-linux] Single-stepping In message <200011151949.OAA22929@hiauly1.hia.nrc.ca>you write: > > I've been helping Alan Modra out with kernel changes to support > > single stepping for gdb. Paul Bame suggested I bounced our ideas > > off you in case you (or anyone else) had any comments. I havn't > > actually committed my changes yet. > > > > The basic approach is to use the recovery counter to generate > > a trap every instruction. The scheme is complicated because a > > suspended process may or may not return to user space via an RFI. > > I really don't know enough to comment on the implementation choice. Why > did you decide on this approach as opposed to inserting breaks and > enabling the taken branch branch trap (T)? It would appear that the recove > ry > counter was intended to provide software recovery from hardware faults > in fault tolerant systems. Possibly, Grant could comment on whether > it is actually useful for this purpose. Err, we tried that at the UofU in our mach port to the PA -- there's a problem with that scheme, though I don't remember precisely what it was. I believe there were cases where the recovery counter doesn't trigger a trap, possibly due to nullified instructions. You might look at the UofU BSD code, which I believe used breakpoints and branch taken traps instad. jeff From taggart@carmen.fc.hp.com Wed, 15 Nov 2000 13:49:18 -0700 Date: Wed, 15 Nov 2000 13:49:18 -0700 From: Matt Taggart taggart@carmen.fc.hp.com Subject: [parisc-linux] Palinux on a 712/60 Andrew Shugg writes... > Arnaud.ATOCH@oecd.org said: > > Hi, > > > > I got a couple of 715 and I'd love having access to an ISO image with STI > > console kernel too. > > I've never made an El Torito CDROM, is it possible to have multiple boot > images and a boot loader on a single disc? El Torito is a PC thing. It makes the front of a CDROM look like a floppy to the PC BIOS. For hppa you put a lifimage on the front of the CDROM(or tape or HDD, etc). > ie could the actual boot > image be a boot loader (PALO) which then points at one or more kernels > on the CDROM? Maybe. Paul Bame is the expert though. I think he had to do some work to get palo to be able to see a kernel on an ISO9660 filesystem. I don't know if it can currently be interruped and pointed at a different kernel. Paul? -- Matt Taggart taggart@fc.hp.com From drepper@redhat.com 15 Nov 2000 12:52:52 -0800 Date: 15 Nov 2000 12:52:52 -0800 From: Ulrich Drepper drepper@redhat.com Subject: [parisc-linux] Help with posix_types.h Paul Bame writes: > FYI I just heard some pretty good reasons why both ino_t and off_t > should be 64 bits even on 32-bit kernels. Keep those cards and letters > coming! Any new port which does *not* do this is broken from the beginning. Copying existing files is not what you have to do. Instead look at today's needs. The numbers of the x86 port are those the kernel people told me are needs, multiplied by 2 or 4. Do the same. -- ---------------. ,-. 1325 Chesapeake Terrace Ulrich Drepper \ ,-------------------' \ Sunnyvale, CA 94089 USA Red Hat `--' drepper at redhat.com `------------------------ From ich@johannes-zahn.de Wed, 15 Nov 2000 21:49:31 +0100 Date: Wed, 15 Nov 2000 21:49:31 +0100 From: johannes zahn ich@johannes-zahn.de Subject: [parisc-linux] init dies on apollo 720 Hi! I'm trying to get a 720/50 to boot from nfs, but as soon as the nfs mound happened init dies. This is all i get on the serial console (pasted from minicom): kmem_create: Forcing size word alignment - nfs_fh Looking up port of RPC 100003/2 on 192.168.1.1 Looking up port of RPC 100005/2 on 192.168.1.1 VFS: Mounted root (nfs filesystem) readonly. handle_interruption() pid=1 command='init' YZrvWESTHLNXBCVMcbcbcbcbOGFRQPDI PSW: 00000000000001001111011100001011 r0-3 00000000 4001ad3c 400057a3 00001f58 r4-7 4001967c 00000000 4001ada0 00001f58 r8-11 00000000 000023cc 00000001 00000000 r12-15 00001034 00000006 40019622 2001ff18 r16-19 c1fdc000 c027b60c 00000000 4001967c r20-23 0000a090 0000a090 00009d8c 00001f58 r24-27 00000001 00000081 4001ada0 c01492b0 r28-31 00000000 0000000b 20020790 400032d7 sr0-4 00000001 00000001 00000000 00000001 sr4-8 00000001 00000001 00000001 00000001 IASQ: 00000001 00000001 IAOQ: 4000d237 4000d23b IIR: 0ed51280 ISR: 00000001 IOR: 00009d8c ORIG_R28: 4001b208 handle_interruption() pid=1 command='init' YZrvWESTHLNXBCVMcbcbcbcbOGFRQPDI [...] I tried the cvs-latest kernel and palo from 2000-11-10 and 2000-11-14 with the crosscompiler from 2000-10-31. Buildhost is i386 linux. nfsroot was from 2000-10-09 or base.tgz from the 0.5 beta CD. I also tried the ramdisk images with sercon and sticon, but the kernel only says "cannot mount root FS on 01:00". The kernel from the 0.5 beta CD seems to have the parport stuff, and that does not work on this machine. Any ideas? Or a working .config? johannes From sieler@allegro.com Wed, 15 Nov 2000 13:08:15 -0800 (PST) Date: Wed, 15 Nov 2000 13:08:15 -0800 (PST) From: Stan Sieler sieler@allegro.com Subject: [parisc-linux] Single-stepping Re: > > The basic approach is to use the recovery counter to generate > > a trap every instruction. The scheme is complicated because a ... > I really don't know enough to comment on the implementation choice. Why > did you decide on this approach as opposed to inserting breaks and MPE/iX (which runs on PA-RISC hardware), has successfully used the Recovery Counter to implement single step for many, many years. BTW, in addition to single step, it's a great tool for counting the number of instructions a procedure (or code path) takes, assuming an adequately powerful debugger: 1) stop (perhaps via a breakpoint) at the start of the code you want to count. 2) set a breakpoint at the end of the code you want to count (e.g., if you're counting a procedure, set a breakpoint at the procedure exit) 3) instead of "continue", do: s 1000000 (i.e., tell Debug/iX to "singlestep" 1000000 instructions) 4) if you hit the breakpoint, enter: = 1000000 - rctr that's how many instructions your code took! (Not counting instructions executed by interrupt handlers, of course.) 5) if you *didn't* hit the breakpoint, then 1000000 wasn't enough instructions (and why are you trying to count so high?) This works because MPE's debug "s" command sets the Recovery Counter to the number of instructions you wanted to step. Normally, that's one (for just "s"). If you said "s 3", it would set the Recovery Counter to 3. If you say "s 1000000", and then execute 123 instructions, and then hit a breakpoint, Debug captures the entire register state as of the breakpoint: including the Recovery Counter (which has 1000000 - 123 in it). Tip: if you're looking at instruction-level debugging, look at Debug/iX to see how to do it right! > It would appear that the recovery > counter was intended to provide software recovery from hardware faults The 1986 PA-RISC Instruction manual simply says "The Recovery Counter (CR 0) can be used to provide software recovery of hardware faults in fault tolerant systems". (I.e., "can", not "must" ... and there's no explanation of how one would use it for this.) -- Stan Sieler sieler@allegro.com www.allegro.com/sieler/wanted/index.html www.sieler.com From drepper@redhat.com 15 Nov 2000 13:08:01 -0800 Date: 15 Nov 2000 13:08:01 -0800 From: Ulrich Drepper drepper@redhat.com Subject: [parisc-linux] Help with posix_types.h This reminds me of something I talked to Cary Coutant about before. You have certainly reserved a thread register in the ABI, right? If not, do it ASAP. -- ---------------. ,-. 1325 Chesapeake Terrace Ulrich Drepper \ ,-------------------' \ Sunnyvale, CA 94089 USA Red Hat `--' drepper at redhat.com `------------------------ From frank_rowand@mvista.com Wed, 15 Nov 2000 13:16:28 -0800 Date: Wed, 15 Nov 2000 13:16:28 -0800 From: Frank Rowand frank_rowand@mvista.com Subject: [parisc-linux] Single-stepping law@redhat.com wrote: > > In message <200011151949.OAA22929@hiauly1.hia.nrc.ca>you write: > > > I've been helping Alan Modra out with kernel changes to support > > > single stepping for gdb. Paul Bame suggested I bounced our ideas > > > off you in case you (or anyone else) had any comments. I havn't > > > actually committed my changes yet. > > > > > > The basic approach is to use the recovery counter to generate > > > a trap every instruction. The scheme is complicated because a > > > suspended process may or may not return to user space via an RFI. > > > > I really don't know enough to comment on the implementation choice. Why > > did you decide on this approach as opposed to inserting breaks and > > enabling the taken branch branch trap (T)? It would appear that the recove > > ry > > counter was intended to provide software recovery from hardware faults > > in fault tolerant systems. Possibly, Grant could comment on whether > > it is actually useful for this purpose. > Err, we tried that at the UofU in our mach port to the PA -- there's a problem > with that scheme, though I don't remember precisely what it was. I believe > there were cases where the recovery counter doesn't trigger a trap, possibly > due to nullified instructions. > > You might look at the UofU BSD code, which I believe used breakpoints and > branch taken traps instad. > > jeff > I implemented two different single step algorithms for a a _kernel_ debugger for hp-ux. The algorithm used could be chosen by a compile switch, because each method had cases that weren't handled well - for some debugging tasks one algorithm was superior to the other. Part of my problem with the recovery counter was that other services in the hp-ux kernel also used the recovery counter. I liked the recovery counter method better than my second method (but had to deal with collisions with the other kernel services). My second method was to insert a breakpoint at the target of the single step. It's a pain to do that because of issues with delay slots, branching, and nullification. I guess the point of all this rambling is to say that the recovery counter has been successfully used by a debugger for single stepping. -Frank -- Frank Rowand MontaVista Software, Inc From sieler@allegro.com Wed, 15 Nov 2000 13:47:15 -0800 (PST) Date: Wed, 15 Nov 2000 13:47:15 -0800 (PST) From: Stan Sieler sieler@allegro.com Subject: [parisc-linux] Single-stepping Re: > I implemented two different single step algorithms for a a _kernel_ debugger > for hp-ux. The algorithm used could be chosen by a compile switch, because BTW, Frank, ask Lee Courtney at MontaVista about Debug/iX ... we've had kernel debugging and single stepping (except for the interrupt control stack and a few other corner cases) for 15+ years. It's *very* powerful to be able to logon as root (or equivalent) and set breakpoints within the kernel, hit them, and then single step ... all on a standard release of the operating system. > I liked the recovery counter method better than my second method (but had to > deal with collisions with the other kernel services). My second method was > to insert a breakpoint at the target of the single step. It's a pain to do > that because of issues with delay slots, branching, and nullification. Worse yet...the breakpoint mechanism raises hell if you have more than one CPU :) You realllly don't want that other CPU to hit the breakpoint! -- Stan Sieler sieler@allegro.com www.allegro.com/sieler/wanted/index.html www.sieler.com From andreas@bawue.de Thu, 16 Nov 2000 23:06:04 +0100 Date: Thu, 16 Nov 2000 23:06:04 +0100 From: Andreas Thienemann andreas@bawue.de Subject: [parisc-linux] 250/1 doesn't boot but dumps stack Hi Grant, Grant Grundler wrote: > > lp0: using parport0 (interrupt-driven). > Are you sure you left out parallel port support? Yes, I am. I just attached the wrong log. Except the lp0 line, there are no differences... > > IASQ: 00000000 00000000 IAOQ: c029c264 c029c268 > > IIR: 0e681096 ISR: 00000000 IOR: 00000004 > > ORIG_R28: 00000000 > Smells like a driver bug. > Can you look up IOAQ and GR2 (c029c264 and c029c248) in System.map file? Of course. The only problem is, there is no such entry in /usr/src/pa-risc/sourcE/linux/System.map . Any ideas? andreas From rhirst@linuxcare.com Wed, 15 Nov 2000 22:19:29 +0000 Date: Wed, 15 Nov 2000 22:19:29 +0000 From: Richard Hirst rhirst@linuxcare.com Subject: [parisc-linux] dino maintainer? On Wed, Nov 15, 2000 at 09:58:35AM +0000, Richard Hirst wrote: > But Helge has problems with the sym53c8xx driver on a B160L. Is Turned out to be a 53c720, driven via Zalon and the ncr53c8xx driver. Driver worked as a module, but not compiled in. Now fixed. Richard From rlduncan@nortelnetworks.com Wed, 15 Nov 2000 17:28:13 -0500 Date: Wed, 15 Nov 2000 17:28:13 -0500 From: Robert Duncan rlduncan@nortelnetworks.com Subject: [parisc-linux] CD-ROM 715/50 boot dies after serial driver... This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C04F53.576F0F70 Content-Type: text/plain; charset="iso-8859-1" Greetings, I have downloaded the .5 Beta CDROM image, burned it and get a "fault in kernel" after the "Serial driver ... enabled" message when booting on my 715/50. This happens with either graphics or serial console configured in NVRAM. Has anyone else seen this error? ----------------begin console output (c) Copyright Hewlett-Packard Company, 1991, 1992 Portions of this code are (c) Copyright Samsung Electronics Co., Ltd, 91, 92 PDC ROM rev. 1.2 IODC ROM rev. 1.1 64 MB of memory have been configured. Selecting a system to boot. To stop selection process, press and hold the ESCAPE key..... Booting from: scsi.6.0 TOSHIBA CD-ROM XM-3501TA Soft booted. palo ipl bame@noam Tue Oct 31 14:18:02 MST 2000 0/vmlinux 2140145 bytes @ 0x6f9800 0/palo-cmdline '0/vmlinux ROOT=/ TERM=LINUX root=/dev/scd0' Kernel: partition 0 file /vmlinux ELF32 executable Entry 00100150 first 00100000 n 4 Segment 0 load 00100000 size 1460344 mediaptr 0x1000 Segment 1 load 00266000 size 179048 mediaptr 0x166000 Segment 2 load 00294000 size 109876 mediaptr 0x192000 Segment 3 load 002b0000 size 8192 mediaptr 0x1ad000 branching to kernel entry point 0x00100150 PDC Console Initialized The 32-bit Kernel has started... Enabled FP coprocessor Free memory starts at: 0xc02da000 (0x504d6c,0x504d6c,0x0,0x0) PALO command line: 'ROOT=/ TERM=LINUX root=/dev/scd0' PALO initrd 0-0 model 00003100 00000481 00000000 00000000 77a94524 ffffffff 00000004 0000000a 0000000a vers 00000009 CPUID vers 0 rev 0 Searching for devices in PDC firmware... processor hpa 0xfffbe000 an older box... Found devices: 1. Stinger Optional Graphics (10) at 0xf4000000, versions 0x6, 0x0, 0x77, 0x0, 0x0 2. Scorpio Core BA (11) at 0xf082f000, versions 0x7, 0x0, 0x70, 0x0, 0x0 3. Scorpio Core SCSI (10) at 0xf0825000, versions 0x7, 0x0, 0x71, 0x0, 0x0 4. Scorpio Core LAN (802.3) (10) at 0xf0826000, versions 0x7, 0x0, 0x72, 0x0, 0x0 5. Scorpio Core HIL (10) at 0xf0821000, versions 0x7, 0x0, 0x73, 0x0, 0x0 6. Scorpio Core RS-232 (10) at 0xf0823000, versions 0x7, 0x0, 0x75, 0x0, 0x0 7. Scorpio Core RS-232 (10) at 0xf0822000, versions 0x7, 0x0, 0x75, 0x0, 0x0 8. Scorpio Core Centronics (10) at 0xf0824000, versions 0x7, 0x0, 0x74, 0x0, 0x0 9. Scorpio Audio (10) at 0xf1000000, versions 0x7, 0x0, 0x7b, 0x0, 0x0 10. Scorpio EISA BA (11) at 0xfc000000, versions 0x7, 0x0, 0x76, 0x0, 0x0 11. Scorpio (715/50) (0) at 0xfffbe000, versions 0x310, 0x0, 0x4, 0x0, 0x81 12. Scorpio (1) at 0xfffbf000, versions 0x17, 0x0, 0x9, 0x0, 0x0 That's a total of 12 devices. CPU(s): 1 x PA7100 (PCX-T) at 50.000000 MHz Linux version 2.4.0-test6 (pjlahaie@elenuial.thepuffingroup.com) (gcc version 2.96 20000925 (experimental)) #32 Mon Nov 6 10:20:58 EST 2000 free_bootmem(0x2da800, 0x3d25800) initrd: 00000000-00000000 pagetable_init On node 0 totalpages: 16384 zone(0): 8192 pages. zone(1): 8192 pages. zone(2): 0 pages. Kernel command line: ROOT=/ TERM=LINUX root=/dev/scd0 trap_init Calibrating delay loop... 49.77 BogoMIPS Memory: 61388k available Dentry-cache hash table entries: 8192 (order: 4, 65536 bytes) Buffer-cache hash table entries: 4096 (order: 2, 16384 bytes) Page-cache hash table entries: 16384 (order: 4, 65536 bytes) Inode-cache hash table entries: 4096 (order: 3, 32768 bytes) POSIX conformance testing by UNIFIX ASP version 1 at 0xf0800000 found. Found i82596 at 0xf0826000, IRQ 87 early initialization of device eth0 is deferred Found HIL at 0xf0821000, IRQ 94 HIL: no keyboard present. Warning : device (10, 0x7, 0x0, 0x73, 0x0) NOT claimed by HIL 712, 715 or similiar Linux NET4.0 for Linux 2.4 Based upon Swansea University Computer Society NET3.039 NET4: Unix domain sockets 1.0/SMP for Linux NET4.0. NET4: Linux TCP/IP 1.0 for NET4.0 IP Protocols: ICMP, UDP, TCP IP: routing cache hash table of 512 buckets, 4Kbytes TCP: Hash tables configured (established 4096 bind 4096) Starting kswapd v1.7 pty: 256 Unix98 ptys configured lp: driver loaded but no devices found RAMDISK driver initialized: 16 RAM disks of 4096K size 1024 blocksize sim700: Couldn't get consistent shared memory sim700: Configuring 53c700 (SCSI-ID 7) at f0825100, IRQ 86 scsi0: Revision 0x0 Post test1, istat 05, sstat0 00, dstat 84 sim700: WARNING IRQ probe failed, (returned 0) scsi0: WARNING: target data areas are not dma coherent! scsi0: test 1 completed ok. scsi0: sim700_intr_handle() called with no interrupt scsi0 : LASI/Simple 53c7xx scsi : 1 host. Vendor: TOSHIBA Model: CD-ROM XM-3501TA Rev: 3054 Type: CD-ROM ANSI SCSI revision: 02 Detected scsi CD-ROM sr0 at scsi0, channel 0, id 6, lun 0 scsi : detected 1 SCSI cdrom total. Uniform CD-ROM driver Revision: 3.11 82596.c: MAC of HP700 LAN blindely read from the prom! eth0: Couldn't get consistent shared memory eth0: 82596 at 0xf0826000, 08 00 09 42 1B 37 IRQ 87. 82596.c $Revision: 1.14 $ Serial driver version 5.01 (2000-05-29) with MANY_PORTS SHARE_IRQ SERIAL_PCI enabled Dumping Stack from c3fc4000 to c3fc4bc0: 4000 00000000 00000140 00000000 00000000 c027a46c 00000001 00000000 ffffffff 4020 00000000 00000000 00000000 00000000 00000000 00000000 ffffffff c027a384 [...] 4ba0 ffffffff bffff5ff ffffff7f c01046e0 ffffbeff f7b7eddf 5fffffdf feefffff Data access rights fault in kernel: Code=26 regs=c3fc4980 (Addr=00000003) YZrvWESTHLNXBCVMcbcbcbcbOGFRQPDI PSW: 00000000000001000000000000001010 r0-3 00000000 c0221800 c011e9f8 c3fce420 r4-7 c3fce200 c0244f10 00000008 f0823800 r8-11 00000003 00000007 c0191568 c02c60a4 r12-15 fffffffc c0245000 c0245000 c02d72b8 r16-19 c0245000 c0245000 c02c6028 00000000 r20-23 c3fce234 f0823807 f0823800 0000000a r24-27 ffffffff c3fce420 c3fce200 c0266000 r28-31 ffffffff 00000240 c3fc4bc0 c012dfc0 sr0-4 00000000 00000000 00000000 00000000 sr4-8 00000000 00000000 00000000 00000000 IASQ: 00000000 00000000 IAOQ: c011e710 c011e714 IIR: 0f881093 ISR: 00000000 IOR: 00000003 ORIG_R28: 00000058 ----------------end console output thanks, Robert Duncan Nortelnetworks ------_=_NextPart_001_01C04F53.576F0F70 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable CD-ROM 715/50 boot dies after serial driver...

Greetings,
I have downloaded the .5 Beta CDROM image, burned it = and get a "fault in kernel" after the "Serial driver ... = enabled" message when booting on my 715/50.  This happens = with either graphics or serial console configured in NVRAM.

Has anyone else seen this error?

----------------begin console output
          &nb= sp;   (c) Copyright Hewlett-Packard Company, 1991, = 1992
Portions of this code are (c) Copyright Samsung = Electronics Co., Ltd, 91, 92

PDC ROM rev. 1.2
IODC ROM rev. 1.1
64 MB of memory have been configured.


Selecting a system to boot.
To stop selection process, press and hold the ESCAPE = key.....

Booting from:     = scsi.6.0     TOSHIBA CD-ROM XM-3501TA

Soft booted.
palo ipl bame@noam Tue Oct 31 14:18:02 MST = 2000
0/vmlinux 2140145 bytes @ 0x6f9800
0/palo-cmdline '0/vmlinux ROOT=3D/ TERM=3DLINUX = root=3D/dev/scd0'
Kernel: partition 0 file /vmlinux
ELF32 executable

Entry 00100150 first 00100000 n 4
Segment 0 load 00100000 size 1460344 mediaptr = 0x1000
Segment 1 load 00266000 size 179048 mediaptr = 0x166000
Segment 2 load 00294000 size 109876 mediaptr = 0x192000
Segment 3 load 002b0000 size 8192 mediaptr = 0x1ad000
branching to kernel entry point 0x00100150
PDC Console Initialized
The 32-bit Kernel has started...
Enabled FP coprocessor
Free memory starts at: 0xc02da000
(0x504d6c,0x504d6c,0x0,0x0)
PALO command line: 'ROOT=3D/ TERM=3DLINUX = root=3D/dev/scd0'
PALO initrd 0-0
model   00003100 00000481 00000000 = 00000000 77a94524 ffffffff 00000004 0000000a 0000000a
vers    00000009
CPUID vers 0 rev 0
Searching for devices in PDC firmware... processor = hpa 0xfffbe000
 an older box...
Found devices:
1. Stinger Optional Graphics (10) at 0xf4000000, = versions 0x6, 0x0, 0x77, 0x0, 0x0
2. Scorpio Core BA (11) at 0xf082f000, versions 0x7, = 0x0, 0x70, 0x0, 0x0
3. Scorpio Core SCSI (10) at 0xf0825000, versions = 0x7, 0x0, 0x71, 0x0, 0x0
4. Scorpio Core LAN (802.3) (10) at 0xf0826000, = versions 0x7, 0x0, 0x72, 0x0, 0x0
5. Scorpio Core HIL (10) at 0xf0821000, versions = 0x7, 0x0, 0x73, 0x0, 0x0
6. Scorpio Core RS-232 (10) at 0xf0823000, versions = 0x7, 0x0, 0x75, 0x0, 0x0
7. Scorpio Core RS-232 (10) at 0xf0822000, versions = 0x7, 0x0, 0x75, 0x0, 0x0
8. Scorpio Core Centronics (10) at 0xf0824000, = versions 0x7, 0x0, 0x74, 0x0, 0x0
9. Scorpio Audio (10) at 0xf1000000, versions 0x7, = 0x0, 0x7b, 0x0, 0x0
10. Scorpio EISA BA (11) at 0xfc000000, versions = 0x7, 0x0, 0x76, 0x0, 0x0
11. Scorpio (715/50) (0) at 0xfffbe000, versions = 0x310, 0x0, 0x4, 0x0, 0x81
12. Scorpio (1) at 0xfffbf000, versions 0x17, 0x0, = 0x9, 0x0, 0x0
That's a total of 12 devices.
CPU(s): 1 x PA7100 (PCX-T) at 50.000000 MHz
Linux version 2.4.0-test6 = (pjlahaie@elenuial.thepuffingroup.com) (gcc version 2.96 20000925 = (experimental)) #32 Mon Nov 6 10:20:58 EST 2000

free_bootmem(0x2da800, 0x3d25800)
initrd: 00000000-00000000
pagetable_init
On node 0 totalpages: 16384
zone(0): 8192 pages.
zone(1): 8192 pages.
zone(2): 0 pages.
Kernel command line: ROOT=3D/ TERM=3DLINUX = root=3D/dev/scd0
trap_init
Calibrating delay loop... 49.77 BogoMIPS
Memory: 61388k available
Dentry-cache hash table entries: 8192 (order: 4, = 65536 bytes)
Buffer-cache hash table entries: 4096 (order: 2, = 16384 bytes)
Page-cache hash table entries: 16384 (order: 4, = 65536 bytes)
Inode-cache hash table entries: 4096 (order: 3, = 32768 bytes)
POSIX conformance testing by UNIFIX
ASP version 1 at 0xf0800000 found.
Found i82596 at 0xf0826000, IRQ 87
early initialization of device eth0 is = deferred
Found HIL at 0xf0821000, IRQ 94
HIL: no keyboard present.
Warning : device (10, 0x7, 0x0, 0x73, 0x0) NOT = claimed by HIL 712, 715 or similiar
Linux NET4.0 for Linux 2.4
Based upon Swansea University Computer Society = NET3.039
NET4: Unix domain sockets 1.0/SMP for Linux = NET4.0.
NET4: Linux TCP/IP 1.0 for NET4.0
IP Protocols: ICMP, UDP, TCP
IP: routing cache hash table of 512 buckets, = 4Kbytes
TCP: Hash tables configured (established 4096 bind = 4096)
Starting kswapd v1.7
pty: 256 Unix98 ptys configured
lp: driver loaded but no devices found
RAMDISK driver initialized: 16 RAM disks of 4096K = size 1024 blocksize
sim700: Couldn't get consistent shared memory
sim700: Configuring 53c700 (SCSI-ID 7) at f0825100, = IRQ 86
scsi0: Revision 0x0
Post test1, istat 05, sstat0 00, dstat 84
sim700: WARNING IRQ probe failed, (returned = 0)
scsi0: WARNING: target data areas are not dma = coherent!
scsi0: test 1 completed ok.
scsi0: sim700_intr_handle() called with no = interrupt
scsi0 : LASI/Simple 53c7xx
scsi : 1 host.
  Vendor: TOSHIBA   Model: CD-ROM = XM-3501TA  Rev: 3054
  Type:   = CD-ROM           =             =       ANSI SCSI revision: 02
Detected scsi CD-ROM sr0 at scsi0, channel 0, id 6, = lun 0
scsi : detected 1 SCSI cdrom total.
Uniform CD-ROM driver Revision: 3.11
82596.c: MAC of HP700 LAN blindely read from the = prom!
eth0: Couldn't get consistent shared memory
eth0: 82596 at 0xf0826000, 08 00 09 42 1B 37 IRQ = 87.
82596.c $Revision: 1.14 $
Serial driver version 5.01 (2000-05-29) with = MANY_PORTS SHARE_IRQ SERIAL_PCI enabled

Dumping Stack from c3fc4000 to c3fc4bc0:
4000 00000000 00000140 00000000 00000000 c027a46c = 00000001 00000000 ffffffff
4020 00000000 00000000 00000000 00000000 00000000 = 00000000 ffffffff c027a384
 [...]
4ba0 ffffffff bffff5ff ffffff7f c01046e0 ffffbeff = f7b7eddf 5fffffdf feefffff

Data access rights fault in kernel: Code=3D26 = regs=3Dc3fc4980 (Addr=3D00000003)

     = YZrvWESTHLNXBCVMcbcbcbcbOGFRQPDI
PSW: 00000000000001000000000000001010
r0-3     00000000 c0221800 = c011e9f8 c3fce420
r4-7     c3fce200 c0244f10 = 00000008 f0823800
r8-11    00000003 00000007 c0191568 = c02c60a4
r12-15   fffffffc c0245000 c0245000 = c02d72b8
r16-19   c0245000 c0245000 c02c6028 = 00000000
r20-23   c3fce234 f0823807 f0823800 = 0000000a
r24-27   ffffffff c3fce420 c3fce200 = c0266000
r28-31   ffffffff 00000240 c3fc4bc0 = c012dfc0
sr0-4    00000000 00000000 00000000 = 00000000
sr4-8    00000000 00000000 00000000 = 00000000

IASQ: 00000000 00000000 IAOQ: c011e710 = c011e714
 IIR: 0f881093    ISR: = 00000000  IOR: 00000003
ORIG_R28: 00000058

----------------end console output

thanks,
Robert Duncan
Nortelnetworks

------_=_NextPart_001_01C04F53.576F0F70-- From rhirst@linuxcare.com Wed, 15 Nov 2000 22:35:40 +0000 Date: Wed, 15 Nov 2000 22:35:40 +0000 From: Richard Hirst rhirst@linuxcare.com Subject: [parisc-linux] CD-ROM 715/50 boot dies after serial driver... On Wed, Nov 15, 2000 at 05:28:13PM -0500, Robert Duncan wrote: > Greetings, > I have downloaded the .5 Beta CDROM image, burned it and get a "fault in > kernel" after the "Serial driver ... enabled" message when booting on my > 715/50. This happens with either graphics or serial console configured in > NVRAM. > > Has anyone else seen this error? I get exactly the same on my 715/75. Havn't had time to investigate yet. Richard From andreas@bawue.de Thu, 16 Nov 2000 23:42:35 +0100 Date: Thu, 16 Nov 2000 23:42:35 +0100 From: Andreas Thienemann andreas@bawue.de Subject: [parisc-linux] 250/1 doesn't boot but dumps stack Grant Grundler wrote: > > IASQ: 00000000 00000000 IAOQ: c029c264 c029c268 > > IIR: 0e681096 ISR: 00000000 IOR: 00000004 > > ORIG_R28: 00000000 > Smells like a driver bug. > Can you look up IOAQ and GR2 (c029c264 and c029c248) in System.map file? Okay, here we go (thanks for the build-tool information...) System Map output: 0xc029c264 __init_begin+264 0xc029x248 __init_begin+248 andreas From kailasr@webcash.com Wed, 15 Nov 2000 15:41:55 -0800 Date: Wed, 15 Nov 2000 15:41:55 -0800 From: Kailashnath V Rampure kailasr@webcash.com Subject: [parisc-linux] Apache package. --=====================_108207293==_.ALT Content-Type: text/plain; charset="us-ascii"; format=flowed Hi I tried to build apache_1.3.12 on HP a class server. But I have error. I have tried to check the site ftp://ftp.debian.org/debian/dists/unstable/main/binary-hppa/ I could not find one. I found some apache-doc etc. Can any on point me where I can try. Regards Kailas --=====================_108207293==_.ALT Content-Type: text/html; charset="us-ascii" Hi

I tried to build apache_1.3.12 on HP a class server. But I have error. I have tried to check the site ftp://ftp.debian.org/debian/dists/unstable/main/binary-hppa/
I could not find one. I found some apache-doc etc.

Can any on point me where I can try.
Regards
Kailas --=====================_108207293==_.ALT-- From bame@noam.fc.hp.com Wed, 15 Nov 2000 16:59:18 -0700 Date: Wed, 15 Nov 2000 16:59:18 -0700 From: Paul Bame bame@noam.fc.hp.com Subject: [parisc-linux] Apache package. = I tried to build apache_1.3.12 on HP a class server. But I have error. I = have tried to check the site = ftp://ftp.debian.org/debian/dists/unstable/main/binary-hppa/ = I could not find one. I found some apache-doc etc. We are still working on some kernel features which are required to support Apache (system 5 shared memory). -P From cary@cup.hp.com Wed, 15 Nov 2000 16:00:49 -0800 Date: Wed, 15 Nov 2000 16:00:49 -0800 From: Cary Coutant cary@cup.hp.com Subject: [parisc-linux] Help with posix_types.h >You have certainly reserved a thread register in the ABI, right? If >not, do it ASAP. On PA-RISC, the thread pointer is kept in the read-only control register CR 27. For user-thread implementations, we provided a kernel API to change the contents of the register. -cary From drepper@redhat.com 15 Nov 2000 16:04:51 -0800 Date: 15 Nov 2000 16:04:51 -0800 From: Ulrich Drepper drepper@redhat.com Subject: [parisc-linux] Help with posix_types.h Cary Coutant writes: > On PA-RISC, the thread pointer is kept in the read-only control register > CR 27. > > For user-thread implementations, we provided a kernel API to change the > contents of the register. This works fine for a 1:1 thread implementation but adds significant runtime hits for a m:n implementation. The latter is the direction we are heading. -- ---------------. ,-. 1325 Chesapeake Terrace Ulrich Drepper \ ,-------------------' \ Sunnyvale, CA 94089 USA Red Hat `--' drepper at redhat.com `------------------------ From jsm@udlkern.fc.hp.com Thu, 16 Nov 2000 02:01:12 -0700 (MST) Date: Thu, 16 Nov 2000 02:01:12 -0700 (MST) From: John Marvin jsm@udlkern.fc.hp.com Subject: Single-stepping > I've been helping Alan Modra out with kernel changes to support > single stepping for gdb. Paul Bame suggested I bounced our ideas > off you in case you (or anyone else) had any comments. I havn't > actually committed my changes yet. > I've decided to respond to the whole list, since others are now participating in the discussion. > The basic approach is to use the recovery counter to generate > a trap every instruction. The scheme is complicated because a > suspended process may or may not return to user space via an RFI. > There is no easy way to do single stepping on parisc. So any single stepping design will be complicated. > If it was suspended as a result of an interrupt then we can > simply set PSW bit R in the tasks saved registers and it will > get loaded by the RFI. On every task switch I set the > recovery counter to 0, just in case the new process is being > single-stepped. > > If a process is suspended during a syscall, then there is no > RFI on the return path to userland, and we have to handle things > differently. I have changed the syscall return path such that > it loads the recovery counter with 3 before updating the PSW > with a value from the tasks saved registers. If that PSW has > the R bit set, then the count of 3 will generate a trap on the > first instruction following the branch back to user space. > Note that PSW wasn't previously restored on the syscall return > path. > Just to be clear, it is impossible to restore the entire PSW without an RFI. So, I assume you are referring to the system mask subset of the PSW that can be manipulated by the ssm,rsm, and mtsm instructions. You mention restoring from the task's saved registers, but we currently do not save the system mask during a syscall (because it should be the same for all processes). Have you added code to do that also? If not, you are restoring from whatever the state was at the last interruption. Which in this case works (since the R bit state will be changed by another process while the debugged process is suspended, this should guarantee that the R bit state is up to date), but it seems a little ugly. In my opinion, you should just be checking a bit in the ptrace flags in the task structure, and setting the R bit with an ssm instruction based on that. > To avoid further complications of interrupts during the three > instructions when the recovery counter is decrementing, whenever > we set the R bit, we also clear the I bit to disable interrupts. Yuck, but I agree that it would be messier to have to deal with this in the interrupt handlers. Please make sure that a comment is added that explains what you are doing, and clearly documents the dependency on the number of remaining instructions before we return to user privilege level. I assume you restore the I bit in the recovery counter trap handler. I can think of alternative ways of doing this, but they are probably just as ugly (e.g. one possibility would be to do an rfi to set the L bit). > > Nullified instructions are handled by the controlling process > manually moving the childs IAOQ over the instruction without > actually setting it running, because the recovery counter isn't > decremented for nullified instructions. Does this code properly handle branches in the delay slot of another branch? (you need to make sure you are not advancing the queues by just adding 4 to each element). One concern I have about this method is that the userland debugger has to cooperate to make this design work, i.e. the single stepping is not accomplished entirely within the kernel, so we cannot easily change the design for single stepping at a later date. I wonder if it is necessary to do this. So what if we don't stop on the nullified instruction. Since it is nullified, it doesn't actually do anything, so why does the user have to see it, i.e. just let the recovery counter trap happen on the next truly executed instruction (i.e. the debugger performs a "double step" in this case). Am I missing something here? > > I need to do some more testing before committing this, but would > welcome any comments on the basic approach taken, areas I have > mis-understood, or problems with it that might not yet have > occurred to me. OK, well here are some issues that you didn't mention, so I don't know whether or not you addressed them: 1) When single stepping over a syscall, when do you actually stop the single stepping and execute the syscall? Hopefully you are not allowing single stepping after the gate instruction on the gateway page (and returning control to a non privileged debugging process). The recovery counter trap should detect when the user code gets to the gateway page. 2) Does your solution properly handle single stepping into and out of a signal handler? Note that the debugger will trap the signal as part of this process. Since the return is handled through a hidden syscall you may not have to do anything special here. Note that HP-UX does not use the recovery counter for single stepping. I made a few phone calls to various engineers to find out what the design process was, and why they chose the solution they did, but I could not find anyone who knew. Looking at the code in HP-UX it looks like someone implemented that code a long time ago, and some of the engineers who have worked on it since don't understand it, because some of the comments added since then clearly show a lack of understanding of what is really going on. Others on this list have mentioned that MPE does use the recovery counter for single stepping. Of course, MPE is not a Unix clone, so just because it could be done on MPE doesn't mean that the recovery counter can cover all cases on Unix (e.g. I have no idea how signals and syscalls are implemented on MPE). But since I have no idea why the recovery counter was not used for HP-UX, I can't say it is the wrong way to go. I can't think of anything that will definitely rule it out, I'm just a little uncomfortable with the fact that HP-UX chose not to use it. One advantage of the HP-UX method is that it completely encapsulates the single stepping inside the kernel, so it can be changed if necessary, without having to modify gdb (and having to worry about old versions of gdb). Anyway, for reference, HP-UX does single stepping by using a combination of the taken branch trap, and loading the instruction queues such that the front of the queue points to the next instruction to be single stepped and the back of the queue points to the first of two break instructions on a "break" page. It does NOT insert break instructions into the code, so it does not adversely affect execution on a SMP machine. Note that we already put a bunch of break instructions before the syscall entry point on the gateway page, so it would be easy to use our gateway page for the "break page". This way, if the single stepped instruction branches, a taken branch trap will be taken (which is important in the case where the branch nullifies its delay slot). Otherwise, the instruction will be executed and then the break instruction at the known location on the "break" page will be executed. If the single stepped instruction nullifies the next instruction, the second break instruction on the "break" page will be executed. Note that this is the short explanation. It is not as simple as it sounds. One major complication is that branches with links don't work properly with the instruction queue magic, so the link register has to be updated in the taken branch trap handler. Also branch externals won't update the space of the space queue tail properly (again, that has to be fixed in the taken branch handler). I can provide more details if the recovery counter method doesn't work out. Sincerely, John Marvin jsm@fc.hp.com From marteaut@esiee.fr Thu, 16 Nov 2000 10:04:07 +0100 Date: Thu, 16 Nov 2000 10:04:07 +0100 From: Thomas Marteau marteaut@esiee.fr Subject: [parisc-linux] nfsroot - 712/60 - RPC - help Hi Jack, > (c) Copyright 1990-1993, Hewlett-Packard Company. > All rights reserved > > Press to stop boot sequence. > Selecting a system to boot. > > Booting > palo ipl jkp2866@redtower Wed Nov 15 12:44:21 CST 2000 > 0/vmlinux 1606438 bytes @ 0x6800 > 0/palo-cmdline '0/vmlinux HOME=/ TERM=LINUX root=/dev/nfs nfsroot=192.68.1.11:/tftpboot/pancho ' Are you sure that the command line is rigth? Is your Server address is 192.-68-.1.11 Here is probably your mistake! Bye, ESIEE Team Visit http://www.esiee.fr/puffin > Kernel: partition 0 file /vmlinux > ELF32 executable > > Entry 00100000 first 00100000 n 4 > Segment 0 load 00100000 size 1097900 mediaptr 0x1000 > Segment 1 load 0020e000 size 150520 mediaptr 0x10e000 > Segment 2 load 00234000 size 55900 mediaptr 0x133000 > Segment 3 load 00244000 size 8192 mediaptr 0x141000 > branching to kernel entry point 0x00100000 > Set default PSW W bit to 0 > PDC Console Initialized > The 32-bit Kernel has started... > Enabled FP coprocessor > Free memory starts at: 0xc026e000 > start_parisc(0x504d6c,0x504d6c,0x0,0x0) > PALO command line: 'HOME=/ TERM=LINUX root=/dev/nfs nfsroot=192.68.1.11:/tftpboot/pancho ' > PALO initrd 0-0 > model 00006000 00000481 00000000 00000000 77564139 00000000 00000004 00000072 00000072 > vers 0000000a > CPUID vers 0 rev 0 > Searching for devices in PDC firmware... processor hpa 0xfffbe000 > an older box... > Found devices From rhirst@linuxcare.com Thu, 16 Nov 2000 12:00:47 +0000 Date: Thu, 16 Nov 2000 12:00:47 +0000 From: Richard Hirst rhirst@linuxcare.com Subject: Single-stepping Hi John, On Thu, Nov 16, 2000 at 02:01:12AM -0700, John Marvin wrote: > Just to be clear, it is impossible to restore the entire PSW without > an RFI. So, I assume you are referring to the system mask subset of > the PSW that can be manipulated by the ssm,rsm, and mtsm instructions. Yes, mtsm in this case. > You mention restoring from the task's saved registers, but we currently > do not save the system mask during a syscall (because it should be the > same for all processes). Have you added code to do that also? If not, Yes I have. > you are restoring from whatever the state was at the last interruption. > Which in this case works (since the R bit state will be changed > by another process while the debugged process is suspended, this should > guarantee that the R bit state is up to date), but it seems a little ugly. > In my opinion, you should just be checking a bit in the ptrace flags > in the task structure, and setting the R bit with an ssm instruction > based on that. Sounds better, I'll look in to it. > > Nullified instructions are handled by the controlling process > > manually moving the childs IAOQ over the instruction without > > actually setting it running, because the recovery counter isn't > > decremented for nullified instructions. Sorry, I worded that very badly. The code that moves the childs IAOQ on is in the kernel, invoked as a result of the controlling process calling ptrace(PTRACE_SINGLESTEP...) when the childs N bit is set. > Does this code properly handle branches in the delay slot of another > branch? (you need to make sure you are not advancing the queues by just > adding 4 to each element). One concern I have about this method is that Current code does /* Nullified, just crank over the queue. */ task_regs(child)->iaoq[0] = task_regs(child)->iaoq[1]; task_regs(child)->iasq[0] = task_regs(child)->iasq[1]; task_regs(child)->iaoq[1] = task_regs(child)->iaoq[0] + 4; Does that look right to you? > I wonder if it is necessary to do this. So what if we don't stop on the > nullified instruction. Since it is nullified, it doesn't actually do > anything, so why does the user have to see it, i.e. just let the recovery > counter trap happen on the next truly executed instruction (i.e. the > debugger performs a "double step" in this case). Am I missing something > here? I don't see why we really need to stop on a nullified instruction, but I'll wait for Alan to comment as he wrote this initially. > 1) When single stepping over a syscall, when do you actually stop the > single stepping and execute the syscall? Hopefully you are not > allowing single stepping after the gate instruction on the gateway > page (and returning control to a non privileged debugging process). > The recovery counter trap should detect when the user code gets > to the gateway page. At the moment my test harness notes IAOQ=0x100 and stops single stepping, but obviously the kernel needs to enforce that. > 2) Does your solution properly handle single stepping into and out of > a signal handler? Note that the debugger will trap the signal as part > of this process. Since the return is handled through a hidden syscall > you may not have to do anything special here. Havn't looked at signal handling yet. > Note that HP-UX does not use the recovery counter for single stepping. I Thanks for the description of how HP-UX does it. I'll stick with the recovery counter for now as it does seem to be basically working. I'll also try to ensure that it is completely encapsulated within the kernel so it is less painful to change later, if need be. Thanks, Richard From rhirst@linuxcare.com Thu, 16 Nov 2000 12:09:57 +0000 Date: Thu, 16 Nov 2000 12:09:57 +0000 From: Richard Hirst rhirst@linuxcare.com Subject: [parisc-linux] Single-stepping On Wed, Nov 15, 2000 at 02:49:02PM -0500, John David Anglin wrote: > > I've been helping Alan Modra out with kernel changes to support > > single stepping for gdb. Paul Bame suggested I bounced our ideas > > off you in case you (or anyone else) had any comments. I havn't > > actually committed my changes yet. > > > > The basic approach is to use the recovery counter to generate > > a trap every instruction. The scheme is complicated because a > > suspended process may or may not return to user space via an RFI. > > I really don't know enough to comment on the implementation choice. Why > did you decide on this approach as opposed to inserting breaks and > enabling the taken branch branch trap (T)? It would appear that the recovery > counter was intended to provide software recovery from hardware faults > in fault tolerant systems. Possibly, Grant could comment on whether > it is actually useful for this purpose. Alan Modra made those early decisions, but I gather that he went for the recovery counter because it at least appears to be rather more straightforward. Richard From jsm@udlkern.fc.hp.com Thu, 16 Nov 2000 05:44:55 -0700 (MST) Date: Thu, 16 Nov 2000 05:44:55 -0700 (MST) From: John Marvin jsm@udlkern.fc.hp.com Subject: Single-stepping Richard, > > Sorry, I worded that very badly. The code that moves the childs > IAOQ on is in the kernel, invoked as a result of the controlling > process calling ptrace(PTRACE_SINGLESTEP...) when the childs N > bit is set. > Great. > > Does this code properly handle branches in the delay slot of another > > branch? (you need to make sure you are not advancing the queues by just > > adding 4 to each element). One concern I have about this method is that > > Current code does > > /* Nullified, just crank over the queue. */ > task_regs(child)->iaoq[0] = task_regs(child)->iaoq[1]; > task_regs(child)->iasq[0] = task_regs(child)->iasq[1]; > task_regs(child)->iaoq[1] = task_regs(child)->iaoq[0] + 4; > > Does that look right to you? > Yes, that is the correct way to do it (I'll assume the duplicated line is just a cut/paste error). > > I wonder if it is necessary to do this. So what if we don't stop on the > > nullified instruction. Since it is nullified, it doesn't actually do > > anything, so why does the user have to see it, i.e. just let the recovery > > counter trap happen on the next truly executed instruction (i.e. the > > debugger performs a "double step" in this case). Am I missing something > > here? > > I don't see why we really need to stop on a nullified instruction, but > I'll wait for Alan to comment as he wrote this initially. > Given the above, i.e. that this is being handled in the kernel anyway, I guess I don't really care which way this goes. Probably it is best to do it whatever way gdb on hp-ux presents it. > > 1) When single stepping over a syscall, when do you actually stop the > > single stepping and execute the syscall? Hopefully you are not > > allowing single stepping after the gate instruction on the gateway > > page (and returning control to a non privileged debugging process). > > The recovery counter trap should detect when the user code gets > > to the gateway page. > > At the moment my test harness notes IAOQ=0x100 and stops single stepping, > but obviously the kernel needs to enforce that. > You should also be checking the space. But yes, the kernel needs to enforce this for security reasons. You should be able to do it in the recovery counter trap handler (rather than having to test for it in the syscall path, which affects all processes). > > 2) Does your solution properly handle single stepping into and out of > > a signal handler? Note that the debugger will trap the signal as part > > of this process. Since the return is handled through a hidden syscall > > you may not have to do anything special here. > > Havn't looked at signal handling yet. > I'm not sure that there is a real issue here or not. HP-UX has some code for single stepping with respect to signal handlers, but I believe it may only be necessary due to the saved state necessary as part of the iaoq manipulation. Obviously you should test this case. > > Note that HP-UX does not use the recovery counter for single stepping. I > > Thanks for the description of how HP-UX does it. I'll stick with > the recovery counter for now as it does seem to be basically working. > I'll also try to ensure that it is completely encapsulated within the kernel > so it is less painful to change later, if need be. > Sounds ok with me. And as long as there are no corner cases, it probably is the best solution, assuming we don't find another application for the recovery counter. John From rhirst@linuxcare.com Thu, 16 Nov 2000 13:20:17 +0000 Date: Thu, 16 Nov 2000 13:20:17 +0000 From: Richard Hirst rhirst@linuxcare.com Subject: Single-stepping On Thu, Nov 16, 2000 at 05:44:55AM -0700, John Marvin wrote: > > Current code does > > > > /* Nullified, just crank over the queue. */ > > task_regs(child)->iaoq[0] = task_regs(child)->iaoq[1]; > > task_regs(child)->iasq[0] = task_regs(child)->iasq[1]; > > task_regs(child)->iaoq[1] = task_regs(child)->iaoq[0] + 4; > > > > Does that look right to you? > > Yes, that is the correct way to do it (I'll assume the duplicated line > is just a cut/paste error). It's not duplicated (iaoq v. iasq). > > At the moment my test harness notes IAOQ=0x100 and stops single stepping, > > but obviously the kernel needs to enforce that. > > > You should also be checking the space. But yes, the kernel needs to enforce > this for security reasons. You should be able to do it in the recovery > counter trap handler (rather than having to test for it in the syscall > path, which affects all processes). I might come back to you on that when I've thought some more. Thanks, Richard From ian.zink@maryville.com Thu, 16 Nov 2000 09:46:18 -0600 Date: Thu, 16 Nov 2000 09:46:18 -0600 From: Ian Zink ian.zink@maryville.com Subject: [parisc-linux] I got the serial console to work... After reading some posts, I went back to trying to use to a serial console to no avail.. Then.. suddenly it hit me. Do'y. The cable I was using was straight-through not Cross-over. Now I have the 712 all booted and running Debian. Very cool, indeed. Thanks for all for your help. I think I will still work on building a STI ISO for the fun of it :) Thanks much, Ian Zink, Systems Engineer Maryville Technologies 540 Maryville Centre, Suite 300 St. Louis, MO 63141 636/519-4182 (FAX) 636/519-4141 ian.zink@maryville.com www.maryville.com From marteaut@esiee.fr Thu, 16 Nov 2000 18:18:58 +0100 Date: Thu, 16 Nov 2000 18:18:58 +0100 From: Thomas Marteau marteaut@esiee.fr Subject: [parisc-linux] The config for 712 hp boxes This is a multi-part message in MIME format. ------=_NextPart_000_00A5_01C04FF9.B01CC3A0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Hi all, Here is the config file we use to compile a new kernel from the test10 sources. We have the console with the STI and an extra term on the serial port. Also, in this mail, you have the diff between our hp_keyb.c and the official one but it gives you the ~ and the ' and others scancodes. All this works for the 712 boxes. We were forced to reboot our box to test the new kernel but before the uptime was 3 days and 4 hours during which we ran dselect and did some compiling. All the files inclosed are downloadable at http://www.esiee.fr/~puffin/code/dl.html Bye, ESIEE Team ------=_NextPart_000_00A5_01C04FF9.B01CC3A0 Content-Type: application/octet-stream; name="keyb.patch" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="keyb.patch" diff -urN linux2/drivers/char/hp_keyb.c linux/drivers/char/hp_keyb.c=0A= --- linux2/drivers/char/hp_keyb.c Thu Nov 16 17:39:03 2000=0A= +++ linux/drivers/char/hp_keyb.c Thu Nov 16 17:18:54 2000=0A= @@ -70,12 +70,12 @@=0A= #define K_F8 0x42=0A= #define K_F9 0x43=0A= #define K_F10 0x44=0A= -#define K_F11 87=0A= -#define K_F12 88=0A= +#define K_F11 0x57=0A= +#define K_F12 0x58=0A= #define K_PRNT 0x54=0A= -#define K_SCRL 70=0A= -#define K_BRK 119=0A= -#define K_AGR K_NONE=0A= +#define K_SCRL 0x46=0A= +#define K_BRK 0x77=0A= +#define K_AGR 0x29=0A= #define K_1 0x02=0A= #define K_2 0x03=0A= #define K_3 0x04=0A= @@ -89,10 +89,10 @@=0A= #define K_MINS 0x0c=0A= #define K_EQLS 0x0d=0A= #define K_BKSP 0x0e=0A= -#define K_INS 110=0A= -#define K_HOME 102=0A= -#define K_PGUP 104=0A= -#define K_NUML 69=0A= +#define K_INS 0x6e=0A= +#define K_HOME 0x66=0A= +#define K_PGUP 0x68=0A= +#define K_NUML 0x45=0A= #define KP_SLH 0x62=0A= #define KP_STR 0x37=0A= #define KP_MNS 0x4a=0A= @@ -111,13 +111,13 @@=0A= #define K_RSBK 0x1b=0A= #define K_ENTR 0x1c=0A= #define K_DEL 111=0A= -#define K_END 107=0A= -#define K_PGDN 109=0A= +#define K_END 0x6b=0A= +#define K_PGDN 0x6d=0A= #define KP_7 0x47=0A= #define KP_8 0x48=0A= #define KP_9 0x49=0A= -#define KP_PLS 118=0A= -#define K_CAPS 58=0A= +#define KP_PLS 0x4e=0A= +#define K_CAPS 0x3a=0A= #define K_A 0x1e=0A= #define K_S 0x1f=0A= #define K_D 0x20=0A= @@ -146,7 +146,7 @@=0A= #define K_DOT 0x34=0A= #define K_FSLH 0x35=0A= #define K_RSFT 0x36=0A= -#define K_UP 103 =0A= +#define K_UP 0x67=0A= #define KP_1 0x4f=0A= #define KP_2 0x50=0A= #define KP_3 0x51=0A= @@ -156,11 +156,11 @@=0A= #define K_SPCE 0x39=0A= #define K_RALT 0x64=0A= #define K_RCTL 0x61=0A= -#define K_LEFT 105=0A= -#define K_DOWN 108=0A= -#define K_RGHT 106=0A= -#define KP_0 82=0A= -#define KP_DOT 83=0A= +#define K_LEFT 0x69=0A= +#define K_DOWN 0x6c=0A= +#define K_RGHT 0x6a=0A= +#define KP_0 0x52=0A= +#define KP_DOT 0x53=0A= =0A= static unsigned char keycode_translate[256] =3D=0A= {=0A= @@ -198,7 +198,7 @@=0A= =0A= /* ----- the following code stolen from pc_keyb.c */=0A= =0A= -#ifdef CONFIG_MAGIC_SYSRQ=0A= +=0A= unsigned char pckbd_sysrq_xlate[128] =3D=0A= "\000\0331234567890-=3D\177\t" /* 0x00 - 0x0f */=0A= "qwertyuiop[]\r\000as" /* 0x10 - 0x1f */=0A= @@ -207,7 +207,6 @@=0A= "\206\207\210\211\212\000\000789-456+1" /* 0x40 - 0x4f */=0A= "230\177\000\000\213\214\000\000\000\000\000\000\000\000\000\000" /* = 0x50 - 0x5f */=0A= "\r\000/"; /* 0x60 - 0x6f */=0A= -#endif=0A= =0A= /*=0A= * Translation of escaped scancodes to keycodes.=0A= ------=_NextPart_000_00A5_01C04FF9.B01CC3A0 Content-Type: application/octet-stream; name="config" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="config" #=0A= # Automatically generated by make menuconfig: don't edit=0A= #=0A= CONFIG_PARISC=3Dy=0A= # CONFIG_UID16 is not set=0A= =0A= #=0A= # Code maturity level options=0A= #=0A= CONFIG_EXPERIMENTAL=3Dy=0A= =0A= #=0A= # General options=0A= #=0A= # CONFIG_SMP is not set=0A= # CONFIG_KWDB is not set=0A= CONFIG_GSC=3Dy=0A= CONFIG_IOMMU_CCIO=3Dy=0A= CONFIG_GSC_LASI=3Dy=0A= CONFIG_PCI=3Dy=0A= CONFIG_GSC_DINO=3Dy=0A= CONFIG_PCI_LBA=3Dy=0A= CONFIG_IOSAPIC=3Dy=0A= CONFIG_IOMMU_SBA=3Dy=0A= =0A= #=0A= # Loadable module support=0A= #=0A= # CONFIG_MODULES is not set=0A= =0A= #=0A= # General setup=0A= #=0A= CONFIG_NET=3Dy=0A= # CONFIG_SYSVIPC is not set=0A= # CONFIG_BSD_PROCESS_ACCT is not set=0A= CONFIG_SYSCTL=3Dy=0A= # CONFIG_BINFMT_SOM is not set=0A= CONFIG_BINFMT_ELF=3Dy=0A= # CONFIG_BINFMT_MISC is not set=0A= # CONFIG_BINFMT_JAVA is not set=0A= =0A= #=0A= # Parallel port support=0A= #=0A= CONFIG_PARPORT=3Dy=0A= # CONFIG_PARPORT_PC is not set=0A= # CONFIG_PARPORT_GSC is not set=0A= # CONFIG_PARPORT_OTHER is not set=0A= # CONFIG_PARPORT_1284 is not set=0A= =0A= #=0A= # Block devices=0A= #=0A= # CONFIG_BLK_DEV_FD is not set=0A= # CONFIG_BLK_DEV_XD is not set=0A= # CONFIG_PARIDE is not set=0A= # CONFIG_BLK_CPQ_DA is not set=0A= # CONFIG_BLK_CPQ_CISS_DA is not set=0A= # CONFIG_BLK_DEV_DAC960 is not set=0A= # CONFIG_BLK_DEV_LOOP is not set=0A= # CONFIG_BLK_DEV_NBD is not set=0A= CONFIG_BLK_DEV_RAM=3Dy=0A= CONFIG_BLK_DEV_RAM_SIZE=3D4096=0A= CONFIG_BLK_DEV_INITRD=3Dy=0A= =0A= #=0A= # Networking options=0A= #=0A= # CONFIG_PACKET is not set=0A= # CONFIG_NETLINK is not set=0A= # CONFIG_NETFILTER is not set=0A= # CONFIG_FILTER is not set=0A= # CONFIG_UNIX is not set=0A= CONFIG_INET=3Dy=0A= # CONFIG_IP_MULTICAST is not set=0A= # CONFIG_IP_ADVANCED_ROUTER is not set=0A= CONFIG_IP_PNP=3Dy=0A= # CONFIG_IP_PNP_BOOTP is not set=0A= # CONFIG_IP_PNP_RARP is not set=0A= # CONFIG_NET_IPIP is not set=0A= # CONFIG_NET_IPGRE is not set=0A= # CONFIG_INET_ECN is not set=0A= # CONFIG_SYN_COOKIES is not set=0A= # CONFIG_IPV6 is not set=0A= # CONFIG_KHTTPD is not set=0A= # CONFIG_ATM is not set=0A= # CONFIG_IPX is not set=0A= # CONFIG_ATALK is not set=0A= # CONFIG_DECNET is not set=0A= # CONFIG_BRIDGE is not set=0A= # CONFIG_X25 is not set=0A= # CONFIG_LAPB is not set=0A= # CONFIG_LLC is not set=0A= # CONFIG_NET_DIVERT is not set=0A= # CONFIG_ECONET is not set=0A= # CONFIG_WAN_ROUTER is not set=0A= # CONFIG_NET_FASTROUTE is not set=0A= # CONFIG_NET_HW_FLOWCONTROL is not set=0A= =0A= #=0A= # QoS and/or fair queueing=0A= #=0A= # CONFIG_NET_SCHED is not set=0A= =0A= #=0A= # SCSI support=0A= #=0A= CONFIG_SCSI=3Dy=0A= CONFIG_BLK_DEV_SD=3Dy=0A= CONFIG_SD_EXTRA_DEVS=3D40=0A= # CONFIG_CHR_DEV_ST is not set=0A= # CONFIG_BLK_DEV_SR is not set=0A= CONFIG_CHR_DEV_SG=3Dy=0A= # CONFIG_SCSI_MULTI_LUN is not set=0A= # CONFIG_SCSI_CONSTANTS is not set=0A= =0A= #=0A= # SCSI low-level drivers=0A= #=0A= CONFIG_SCSI_LASI=3Dy=0A= CONFIG_SCSI_ZALON=3Dy=0A= CONFIG_SCSI_SYM53C8XX=3Dy=0A= CONFIG_SCSI_NCR53C8XX_DEFAULT_TAGS=3D8=0A= CONFIG_SCSI_NCR53C8XX_MAX_TAGS=3D32=0A= CONFIG_SCSI_NCR53C8XX_SYNC=3D20=0A= # CONFIG_SCSI_NCR53C8XX_PROFILE is not set=0A= # CONFIG_SCSI_NCR53C8XX_IOMAPPED is not set=0A= =0A= #=0A= # Network device support=0A= #=0A= CONFIG_NETDEVICES=3Dy=0A= CONFIG_LASI_82596=3Dy=0A= =0A= #=0A= # ARCnet devices=0A= #=0A= # CONFIG_ARCNET is not set=0A= # CONFIG_DUMMY is not set=0A= # CONFIG_BONDING is not set=0A= # CONFIG_EQUALIZER is not set=0A= # CONFIG_TUN is not set=0A= # CONFIG_NET_SB1000 is not set=0A= =0A= #=0A= # Ethernet (10 or 100Mbit)=0A= #=0A= CONFIG_NET_ETHERNET=3Dy=0A= # CONFIG_NET_VENDOR_3COM is not set=0A= # CONFIG_LANCE is not set=0A= # CONFIG_NET_VENDOR_SMC is not set=0A= # CONFIG_NET_VENDOR_RACAL is not set=0A= # CONFIG_AT1700 is not set=0A= # CONFIG_DEPCA is not set=0A= # CONFIG_HP100 is not set=0A= # CONFIG_NET_ISA is not set=0A= CONFIG_NET_PCI=3Dy=0A= # CONFIG_PCNET32 is not set=0A= # CONFIG_ADAPTEC_STARFIRE is not set=0A= # CONFIG_AC3200 is not set=0A= # CONFIG_APRICOT is not set=0A= # CONFIG_CS89x0 is not set=0A= # CONFIG_DE4X5 is not set=0A= CONFIG_TULIP=3Dy=0A= # CONFIG_DGRS is not set=0A= # CONFIG_DM9102 is not set=0A= # CONFIG_EEPRO100 is not set=0A= # CONFIG_LNE390 is not set=0A= # CONFIG_NATSEMI is not set=0A= # CONFIG_NE2K_PCI is not set=0A= # CONFIG_NE3210 is not set=0A= # CONFIG_ES3210 is not set=0A= # CONFIG_RTL8129 is not set=0A= # CONFIG_8139TOO is not set=0A= # CONFIG_SIS900 is not set=0A= # CONFIG_EPIC100 is not set=0A= # CONFIG_SUNDANCE is not set=0A= # CONFIG_TLAN is not set=0A= # CONFIG_VIA_RHINE is not set=0A= # CONFIG_WINBOND_840 is not set=0A= # CONFIG_NET_POCKET is not set=0A= =0A= #=0A= # Ethernet (1000 Mbit)=0A= #=0A= # CONFIG_ACENIC is not set=0A= # CONFIG_HAMACHI is not set=0A= # CONFIG_YELLOWFIN is not set=0A= # CONFIG_SK98LIN is not set=0A= # CONFIG_FDDI is not set=0A= # CONFIG_HIPPI is not set=0A= # CONFIG_PLIP is not set=0A= # CONFIG_PPP is not set=0A= # CONFIG_SLIP is not set=0A= =0A= #=0A= # Wireless LAN (non-hamradio)=0A= #=0A= # CONFIG_NET_RADIO is not set=0A= =0A= #=0A= # Token Ring devices=0A= #=0A= # CONFIG_TR is not set=0A= # CONFIG_NET_FC is not set=0A= # CONFIG_RCPCI is not set=0A= # CONFIG_SHAPER is not set=0A= =0A= #=0A= # Wan interfaces=0A= #=0A= # CONFIG_WAN is not set=0A= =0A= #=0A= # Character devices=0A= #=0A= CONFIG_VT=3Dy=0A= CONFIG_VT_CONSOLE=3Dy=0A= CONFIG_GSC_PS2=3Dy=0A= # CONFIG_HIL is not set=0A= CONFIG_SERIAL=3Dy=0A= # CONFIG_SERIAL_CONSOLE is not set=0A= CONFIG_SERIAL_GSC=3Dy=0A= # CONFIG_SERIAL_EXTENDED is not set=0A= # CONFIG_SERIAL_NONSTANDARD is not set=0A= CONFIG_UNIX98_PTYS=3Dy=0A= CONFIG_UNIX98_PTY_COUNT=3D256=0A= # CONFIG_PRINTER is not set=0A= # CONFIG_PPDEV is not set=0A= =0A= #=0A= # I2C support=0A= #=0A= # CONFIG_I2C is not set=0A= =0A= #=0A= # Mice=0A= #=0A= # CONFIG_BUSMOUSE is not set=0A= # CONFIG_MOUSE is not set=0A= =0A= #=0A= # Joysticks=0A= #=0A= # CONFIG_JOYSTICK is not set=0A= # CONFIG_QIC02_TAPE is not set=0A= =0A= #=0A= # Watchdog Cards=0A= #=0A= # CONFIG_WATCHDOG is not set=0A= CONFIG_GENRTC=3Dy=0A= # CONFIG_INTEL_RNG is not set=0A= # CONFIG_NVRAM is not set=0A= # CONFIG_RTC is not set=0A= # CONFIG_DTLK is not set=0A= # CONFIG_R3964 is not set=0A= # CONFIG_APPLICOM is not set=0A= =0A= #=0A= # Ftape, the floppy tape device driver=0A= #=0A= # CONFIG_FTAPE is not set=0A= # CONFIG_AGP is not set=0A= # CONFIG_DRM is not set=0A= =0A= #=0A= # File systems=0A= #=0A= # CONFIG_QUOTA is not set=0A= # CONFIG_AUTOFS_FS is not set=0A= # CONFIG_AUTOFS4_FS is not set=0A= # CONFIG_ADFS_FS is not set=0A= # CONFIG_ADFS_FS_RW is not set=0A= # CONFIG_AFFS_FS is not set=0A= # CONFIG_HFS_FS is not set=0A= # CONFIG_BFS_FS is not set=0A= # CONFIG_FAT_FS is not set=0A= # CONFIG_MSDOS_FS is not set=0A= # CONFIG_UMSDOS_FS is not set=0A= # CONFIG_VFAT_FS is not set=0A= # CONFIG_EFS_FS is not set=0A= # CONFIG_JFFS_FS is not set=0A= # CONFIG_CRAMFS is not set=0A= # CONFIG_RAMFS is not set=0A= CONFIG_ISO9660_FS=3Dy=0A= # CONFIG_JOLIET is not set=0A= # CONFIG_MINIX_FS is not set=0A= # CONFIG_NTFS_FS is not set=0A= # CONFIG_NTFS_RW is not set=0A= # CONFIG_HPFS_FS is not set=0A= CONFIG_PROC_FS=3Dy=0A= # CONFIG_DEVFS_FS is not set=0A= # CONFIG_DEVFS_MOUNT is not set=0A= # CONFIG_DEVFS_DEBUG is not set=0A= # CONFIG_DEVPTS_FS is not set=0A= # CONFIG_QNX4FS_FS is not set=0A= # CONFIG_QNX4FS_RW is not set=0A= # CONFIG_ROMFS_FS is not set=0A= CONFIG_EXT2_FS=3Dy=0A= # CONFIG_SYSV_FS is not set=0A= # CONFIG_SYSV_FS_WRITE is not set=0A= # CONFIG_UDF_FS is not set=0A= # CONFIG_UDF_RW is not set=0A= # CONFIG_UFS_FS is not set=0A= # CONFIG_UFS_FS_WRITE is not set=0A= =0A= #=0A= # Network File Systems=0A= #=0A= # CONFIG_CODA_FS is not set=0A= CONFIG_NFS_FS=3Dy=0A= # CONFIG_NFS_V3 is not set=0A= CONFIG_ROOT_NFS=3Dy=0A= # CONFIG_NFSD is not set=0A= # CONFIG_NFSD_V3 is not set=0A= CONFIG_SUNRPC=3Dy=0A= CONFIG_LOCKD=3Dy=0A= # CONFIG_SMB_FS is not set=0A= # CONFIG_NCP_FS is not set=0A= # CONFIG_NCPFS_PACKET_SIGNING is not set=0A= # CONFIG_NCPFS_IOCTL_LOCKING is not set=0A= # CONFIG_NCPFS_STRONG is not set=0A= # CONFIG_NCPFS_NFS_NS is not set=0A= # CONFIG_NCPFS_OS2_NS is not set=0A= # CONFIG_NCPFS_SMALLDOS is not set=0A= # CONFIG_NCPFS_MOUNT_SUBDIR is not set=0A= # CONFIG_NCPFS_NDS_DOMAINS is not set=0A= # CONFIG_NCPFS_NLS is not set=0A= # CONFIG_NCPFS_EXTRAS is not set=0A= =0A= #=0A= # Partition Types=0A= #=0A= # CONFIG_PARTITION_ADVANCED is not set=0A= CONFIG_MSDOS_PARTITION=3Dy=0A= # CONFIG_NLS is not set=0A= =0A= #=0A= # Sound Drivers=0A= #=0A= # CONFIG_SOUND is not set=0A= =0A= #=0A= # Console drivers=0A= #=0A= =0A= #=0A= # Frame-buffer support=0A= #=0A= # CONFIG_FB is not set=0A= CONFIG_STI_CONSOLE=3Dy=0A= CONFIG_DUMMY_CONSOLE=3Dy=0A= =0A= #=0A= # Kernel hacking=0A= #=0A= CONFIG_MAGIC_SYSRQ=3Dy=0A= ------=_NextPart_000_00A5_01C04FF9.B01CC3A0-- From grundler@cup.hp.com Thu, 16 Nov 2000 10:10:23 -0800 Date: Thu, 16 Nov 2000 10:10:23 -0800 From: Grant Grundler grundler@cup.hp.com Subject: [parisc-linux] The config for 712 hp boxes "Thomas Marteau" wrote: > Hi all, > > Here is the config file we use to compile a new kernel from the test10 > sources. We have the console with the STI and an extra term on the serial > port. Thomas - excellent - thanks! > Also, in this mail, you have the diff between our hp_keyb.c and the official > one but it gives you the ~ and the ' and others scancodes. I noticed this mail was directed to me - but I can't take ownership of this code. I have too many other things going on. Helge - can you commit this fix too? thanks, grant Grant Grundler Unix Systems Enablement Lab +1.408.447.7253 From deller@gmx.de Thu, 16 Nov 2000 19:25:49 +0100 Date: Thu, 16 Nov 2000 19:25:49 +0100 From: Helge Deller deller@gmx.de Subject: [parisc-linux] The config for 712 hp boxes On Thursday 16 November 2000 19:10, Grant Grundler wrote: > "Thomas Marteau" wrote: > > Hi all, > > > > Here is the config file we use to compile a new kernel from the test10 > > sources. We have the console with the STI and an extra term on the serial > > port. > > Thomas - excellent - thanks! > > > Also, in this mail, you have the diff between our hp_keyb.c and the official > > one but it gives you the ~ and the ' and others scancodes. > > I noticed this mail was directed to me - but I can't take ownership > of this code. I have too many other things going on. > > Helge - can you commit this fix too? Ok. I will test & evtl. commit it today. > > thanks, > grant > > Grant Grundler > Unix Systems Enablement Lab > +1.408.447.7253 > > --------------------------------------------------------------------------- > To unsubscribe: send e-mail to parisc-linux-request@thepuffingroup.com with > `unsubscribe' as the subject. From frank_rowand@mvista.com Thu, 16 Nov 2000 11:00:48 -0800 Date: Thu, 16 Nov 2000 11:00:48 -0800 From: Frank Rowand frank_rowand@mvista.com Subject: Single-stepping John Marvin wrote: > > Richard, > > > > > Sorry, I worded that very badly. The code that moves the childs > > IAOQ on is in the kernel, invoked as a result of the controlling > > process calling ptrace(PTRACE_SINGLESTEP...) when the childs N > > bit is set. > > > > Great. > > > > Does this code properly handle branches in the delay slot of another > > > branch? (you need to make sure you are not advancing the queues by just > > > adding 4 to each element). One concern I have about this method is that > > > > Current code does > > > > /* Nullified, just crank over the queue. */ > > task_regs(child)->iaoq[0] = task_regs(child)->iaoq[1]; > > task_regs(child)->iasq[0] = task_regs(child)->iasq[1]; > > task_regs(child)->iaoq[1] = task_regs(child)->iaoq[0] + 4; > > > > Does that look right to you? > > > > Yes, that is the correct way to do it (I'll assume the duplicated line > is just a cut/paste error). If iaoq[0] contains a branch, iaoq[1] is in the delay slot. The instruction executed after iaoq[1] would then typically _not_ be iaoq[0] + 4 (the next instruction would be the target of the branch at iaoq[0]). > Sounds ok with me. And as long as there are no corner cases, it probably > is the best solution, assuming we don't find another application for > the recovery counter. The recovery counter is very useful for performance measurement tools to understand the cycles per instruction of a code path. (Using the recovery counter for the debugger doesn't preclude using it for performance tools - you just can't easily use it for both purposes at the same instant in time.) > John -Frank -- Frank Rowand MontaVista Software, Inc From rhirst@linuxcare.com Thu, 16 Nov 2000 20:28:42 +0000 Date: Thu, 16 Nov 2000 20:28:42 +0000 From: Richard Hirst rhirst@linuxcare.com Subject: Single-stepping On Thu, Nov 16, 2000 at 11:00:48AM -0800, Frank Rowand wrote: > John Marvin wrote: > > > > Does this code properly handle branches in the delay slot of another > > > > branch? (you need to make sure you are not advancing the queues by just > > > > adding 4 to each element). One concern I have about this method is that > > > > > > Current code does > > > > > > /* Nullified, just crank over the queue. */ > > > task_regs(child)->iaoq[0] = task_regs(child)->iaoq[1]; > > > task_regs(child)->iasq[0] = task_regs(child)->iasq[1]; > > > task_regs(child)->iaoq[1] = task_regs(child)->iaoq[0] + 4; > > > > > > Does that look right to you? > > > > > > > Yes, that is the correct way to do it (I'll assume the duplicated line > > is just a cut/paste error). > > If iaoq[0] contains a branch, iaoq[1] is in the delay slot. The instruction > executed after iaoq[1] would then typically _not_ be iaoq[0] + 4 (the next > instruction would be the target of the branch at iaoq[0]). But the above code is only executed if the current instruction is nullified. In your example, the branch in iaoq[0] would be nullified and therefore never taken. Richard From deller@gmx.de Thu, 16 Nov 2000 22:28:50 +0100 Date: Thu, 16 Nov 2000 22:28:50 +0100 From: Helge Deller deller@gmx.de Subject: [parisc-linux] The config for 712 hp boxes On Thursday 16 November 2000 18:18, Thomas Marteau wrote: > Hi all, > > [....] > Also, in this mail, you have the diff between our hp_keyb.c and the official > one but it gives you the ~ and the ' and others scancodes. > [....] Hi ESIEE-Team ! Thanks for your patch ! I committed your patch into CVS and just tweaked it a little for CONFIG_MAGIC_SYSRQ. I hope this is ok for you ? If your time permits, I would like to ask, if you maybe also want to look at getting the CAPS-Lock-, Scroll-Lock- & Num-Lock-LED's working ? Furthermore you mention in your project-history on your homepage something about "keyboard and soundchip problems" (Oct. 24). I'm asking just out of curiousity: Did you thought about programming the on-board sound-chips (which I believe would be a hard job.) ? > Bye, > ESIEE Team Best regards, Helge Deller. From taggart@carmen.fc.hp.com Thu, 16 Nov 2000 19:25:26 -0700 Date: Thu, 16 Nov 2000 19:25:26 -0700 From: Matt Taggart taggart@carmen.fc.hp.com Subject: [parisc-linux] glibc merged to 2.2 Today Paul Bame and I merged/updated the puffin.external.hp.com glibc cvs to glibc 2.2. After the merge I cleaned up the differences between our cvs and 2.2, mostly comment differences and formatting changes. With the exception of the setjmp problem mentioned in, http://puffin.external.hp.com/mailing-lists/parisc-linux/2000/11-Nov/0091.html and the fact that we have/need newer "scripts/config.guess" and "scripts/config.sub", we are completely sync'ed up with glibc 2.2. -- Matt Taggart taggart@fc.hp.com From deller@gmx.de Fri, 17 Nov 2000 15:34:09 +0100 Date: Fri, 17 Nov 2000 15:34:09 +0100 From: Helge Deller deller@gmx.de Subject: [parisc-linux] The config for 712 hp boxes [CC'ed the list, so maybe someone else can comment too....] On Friday 17 November 2000 11:45, Thomas Marteau wrote: > Hi Helge, Hi, > > > ----- Original Message ----- > From: Helge Deller > To: Thomas Marteau > Cc: > Sent: Thursday, November 16, 2000 10:28 PM > Subject: Re: [parisc-linux] The config for 712 hp boxes > > > > On Thursday 16 November 2000 18:18, Thomas Marteau wrote: > > > Hi all, > > > > > > [....] > > > Also, in this mail, you have the diff between our hp_keyb.c and the > official > > > one but it gives you the ~ and the ' and others scancodes. > > > [....] > > > > Hi ESIEE-Team ! > > > > Thanks for your patch ! > > > > I committed your patch into CVS and just tweaked it a little for > > CONFIG_MAGIC_SYSRQ. I hope this is ok for you ? > We didn't really understand why pckbd_sysrq_xlate was here for. > If you can explain to us, it will be fine. The best documentation you can find is in linux/Documentation/sysrq.txt. The copy of pckbd_sysrq_xlate[] is a simple implementation of keyboard-scancodes to chars, which is used by drivers/char/keyboard.c to call handle_sysrq() from /drivers/char/sysrq.c. This means, that you can press Alt-PrintScr (=> SysRQ) and a char at the keyboard simultaniously and your machine for example syncs the disks, mounts all discs read-only or reboots your machine immediately. > > If your time permits, I would like to ask, if you maybe also want to look > at > > getting the CAPS-Lock-, Scroll-Lock- & Num-Lock-LED's working ? > Normally, you can see yours leds switching on/off but we did not init them. > So they are like boot admin switch them... ^^^^^^^ ^^^^^ ^^^ Sorry ? > But we would like to know how and where we have to init them > because we know how to. We have made test and it was working... I'm not sure, but I think you should check the code in lasikbd_leds() in hp_psaux.c. The initialization should maybe be done in the same file in the function lasi_ps2_register() before calling register_kbd_ops(). > > > Furthermore you mention in your project-history on your homepage something > > about "keyboard and soundchip problems" (Oct. 24). I'm asking just out of > > curiousity: Did you thought about programming the on-board sound-chips > (which > > I believe would be a hard job.) ? > Yes, it is in our internal todo list, if we have time to. Because we look at > it with Thierry, we saw that, for LASI, > you have an interface and then the chip to configure. But it is very > interesting... Yes it is, and it would be great if you worked on that too ! > > Also, we want to rule the power leds but they are different if the box is > 712 or B132 or ... So our question is how to implement > this kind of initialsation and deinitialisation in a linux kernel and in a > second time, how to do for differents kind of boxes. As far as I know / have heard, there are only two types of LED's (but I may be wrong here !). One is where the LED's are organized in a row on the front panel (as my local machines here), and the other one, where you have (LED/)LCD-Numbers on your front panel ? They differ how to be accessed and where the controlling registers are located. One method to distiguish them is maybe to place the special initialisation code into drivers/gsc/lasi.c and asp.c, depending on the machine and which method needs to be used. Since I don't have any real documentation or knowledge of the programming of the LEDs (beside of the PDC-calls I placed into setup.c), maybe someone else can better comment on that or give some documentation ? > > Thanks for your answers, Helge > Bye, > ESIEE Team Best regards, Helge Deller. From Arnaud.ATOCH@oecd.org Fri, 17 Nov 2000 16:30:42 +0100 Date: Fri, 17 Nov 2000 16:30:42 +0100 From: Arnaud.ATOCH@oecd.org Arnaud.ATOCH@oecd.org Subject: [parisc-linux] Booting 712 with CD 0.5 Is the following output the normal behavior of Linux-PARisc on a 712/100 ? kmem_create: Forcing size word alignment - nfs_fh kernel BUG at pci-dma.c:391! kernel BUG at pci-dma.c:400! kernel BUG at pci-dma.c:391! kernel BUG at pci-dma.c:400! kernel BUG at pci-dma.c:391! kernel BUG at pci-dma.c:400! VFS: Disk change detected on device sr(11,0) kernel BUG at pci-dma.c:391! kernel BUG at pci-dma.c:400! kernel BUG at pci-dma.c:391! kernel BUG at pci-dma.c:400! kernel BUG at pci-dma.c:391! kernel BUG at pci-dma.c:400! ISO 9660 Extensions: RRIP_1991A VFS: Mounted root (iso9660 filesystem) readonly. INIT: version 2.78 booting INIT: Entering runlevel: 2 Setting up /tmp ramdisk4096+0 records in 4096+0 records out mke2fs 1.19, 13-Jul-2000 for EXT2 FS 0.5b, 95/08/09 Filesystem label= OS type: Linux Block size=1024 (log=0) Fragment size=1024 (log=0) 1024 inodes, 4096 blocks 0 blocks (0.00%) reserved for the super user First data block=1 1 block group 8192 blocks per group, 8192 fragments per group 1024 inodes per group Writing inode tables: done Writing superblocks and filesystem accounting information: done INIT: Id "T0" respawni INIT: no more processe From rhirst@linuxcare.com Fri, 17 Nov 2000 15:39:55 +0000 Date: Fri, 17 Nov 2000 15:39:55 +0000 From: Richard Hirst rhirst@linuxcare.com Subject: [parisc-linux] SEGV signal handling bug (dynamic linking) Hi, Don't know if anyone expects this to work yet or not, but: ------------------------- cut ----------------------------- #include #include #include #include #include #include #include #include #include char *mem; void sig_handler(int sig) { int res; printf("Trapped!!!\n"); res = mprotect(mem, 4096, PROT_READ|PROT_WRITE); if (res < 0) { perror("mprotect"); exit(1); } } void install_handlers(void) { struct sigaction act; memset(&act, 0, sizeof(act)); act.sa_handler = sig_handler; sigaction(SIGSEGV, &act, NULL); } int main(int argc, char **argv) { int res; mem = malloc(8192); if (mem == NULL) { perror("malloc"); exit(1); } mem = (char *)(((int)mem + 4095) & ~0x0fff); res = mprotect(mem, 4096, PROT_READ); if (res < 0) { perror("mprotect"); exit(1); } install_handlers(); write(1, "Going\n", 6); mem[24] = 17; write(1, "Gone\n", 5); return 0; } ------------------------- cut ----------------------------- generates: Going Bus error plus the following on the console: do_page_fault() pid=167 command='ch' YZrvWESTHLNXBCVMcbcbcbcbOGFRQPDI PSW: 00000000000001001111111100001011 r0-3 00000000 fffff000 0000166f 00002944 r4-7 40138c38 2001fd8c 00002852 00000001 r8-11 00002862 0008b010 0009c290 0009cbf0 r12-15 00000000 00000000 0009cb50 00000000 r16-19 00000000 00000001 0000b71b 00000011 r20-23 00004000 40041fcc 40041fcc 00000008 r24-27 00000006 00001000 00000001 0000280c r28-31 00000006 00000020 20020140 40041fd7 sr0-4 00000000 00000003 00000000 0000000a sr4-8 0000000a 0000000a 0000000a 0000000a IASQ: 0000000a 0000000a IAOQ: 0000167b 0000167f IIR: 6293002e ISR: 0000000a IOR: 00004017 ORIG_R28: 00002880 !!die_if_kernel: ch(167): Unaligned data reference 28 YZrvWESTHLNXBCVMcbcbcbcbOGFRQPDI PSW: 00000000000011001111111100001011 r0-3 00000000 fffff000 20020140 00002944 r4-7 40138c38 2001fd8c 00002852 00000001 r8-11 00002862 0008b010 0009c290 0009cbf0 r12-15 00000000 00000000 0009cb50 00000000 r16-19 00000000 00000001 0000b71b 00000000 r20-23 0000289f 40041fcc 40041fcc 00000008 r24-27 200201d0 20020150 0000000b 0000280c r28-31 00000006 00000020 200203c0 40041fd7 sr0-4 00000000 00000003 00000000 0000000a sr4-8 0000000a 0000000a 0000000a 0000000a IASQ: 0000000a 0000000a IAOQ: 0000289b 0000289b IIR: 0e801096 ISR: 0000000a IOR: 0000289f ORIG_R28: 00002880 The first do_page_fault() is fine, it is the 'mem[24] = 17' line, but the second isn't. The corresponding code is at the end of .plt: 2898: 0e 80 10 96 ldw 0(sr0,r20),r22 289c: ea c0 c0 00 bv r0(r22) 28a0: 0e 88 10 95 ldw 4(sr0,r20),r21 28a4: ea 9f 1f dd b,l 2898 <__DTOR_END__+0x74>,r20 28a8: d6 80 1c 1e depwi 0,31,2,r20 28ac: 00 c0 ff ee # c0ffee 28b0: de ad be ef #deadbeef However, if I make it statically linked, it works fine, giving: Going Trapped!!! Gone Richard From bri@mojo.calyx.net Fri, 17 Nov 2000 10:49:22 -0500 (EST) Date: Fri, 17 Nov 2000 10:49:22 -0500 (EST) From: Brian S. Julin bri@mojo.calyx.net Subject: [parisc-linux] debian archive beware libpam JFYI to save other people some time. Before firing up "apt-get upgrade" you'll be best off putting a hold on all the libpam packages, as the 0.72-12 version on ftp.us.debian.org fails on a bad symbol in libpam-misc, which locks you out of the box except if you boot single. -- Brian S. Julin From grundler@cup.hp.com Fri, 17 Nov 2000 08:38:24 -0800 Date: Fri, 17 Nov 2000 08:38:24 -0800 From: Grant Grundler grundler@cup.hp.com Subject: [parisc-linux] Booting 712 with CD 0.5 Arnaud.ATOCH@oecd.org wrote: > Is the following output the normal behavior of Linux-PARisc on a 712/100 ? > > kmem_create: Forcing size word alignment - nfs_fh > kernel BUG at pci-dma.c:391! > kernel BUG at pci-dma.c:400! The bug is real. A driver is calling pci_map_single() and pci_unmap_single() without specifying which direction the DMA is going. Cache flushing on 712 (PCXL) systems needs to know. I'll assume it's the SCSI driver since it looks like we are talking to a SCSI CD-ROM. grant Grant Grundler Unix Systems Enablement Lab +1.408.447.7253 From drepper@redhat.com 17 Nov 2000 09:09:10 -0800 Date: 17 Nov 2000 09:09:10 -0800 From: Ulrich Drepper drepper@redhat.com Subject: [parisc-linux] SEGV signal handling bug (dynamic linking) Richard Hirst writes: > mem = malloc(8192); > if (mem == NULL) { > perror("malloc"); > exit(1); > } > mem = (char *)(((int)mem + 4095) & ~0x0fff); > res = mprotect(mem, 4096, PROT_READ); Read the Unix standard: The behavior of this function is unspecified if the mapping was not established by a call to mmap(). -- ---------------. ,-. 1325 Chesapeake Terrace Ulrich Drepper \ ,-------------------' \ Sunnyvale, CA 94089 USA Red Hat `--' drepper at redhat.com `------------------------ From grundler@cup.hp.com Fri, 17 Nov 2000 09:09:04 -0800 (PST) Date: Fri, 17 Nov 2000 09:09:04 -0800 (PST) From: Grant Grundler grundler@cup.hp.com Subject: [parisc-linux] pci-dma.c BUG(391/400) PATCH Hi all, The following patch tries to point a finger at the offender rather than just call attention to a problem in the service. I don't have a PCXL/L2 machine setup right now. Could someone test commit this patch for me? thanks, grant grundler <505>cvs diff arch/parisc/kernel/pci-dma.c Index: arch/parisc/kernel/pci-dma.c =================================================================== RCS file: /home/cvs/parisc/linux/arch/parisc/kernel/pci-dma.c,v retrieving revision 1.16 diff -u -p -r1.16 pci-dma.c --- pci-dma.c 2000/11/08 06:20:27 1.16 +++ pci-dma.c 2000/11/17 17:04:22 @@ -387,8 +387,10 @@ static void pa11_dma_free_consistent (st static dma_addr_t pa11_dma_map_single(struct pci_dev *dev, void *addr, size_t size, int direction) { - if (direction == PCI_DMA_NONE) - BUG(); + if (direction == PCI_DMA_NONE) { + printk(KERN_ERR "pa11_dma_map_single(PCI_DMA_NONE) called by %p\n", __builtin_return_address(0)); + BUG(); + } flush_kernel_dcache_range((unsigned long) addr, size); return virt_to_phys(addr); @@ -396,8 +398,10 @@ static dma_addr_t pa11_dma_map_single(st static void pa11_dma_unmap_single(struct pci_dev *dev, dma_addr_t dma_handle, size_t size, int direction) { - if (direction == PCI_DMA_NONE) - BUG(); + if (direction == PCI_DMA_NONE) { + printk(KERN_ERR "pa11_dma_unmap_single(PCI_DMA_NONE) called by %p\n", __builtin_return_address(0)); + BUG(); + } if (direction == PCI_DMA_TODEVICE) return; From Arnaud.ATOCH@oecd.org Fri, 17 Nov 2000 18:10:52 +0100 Date: Fri, 17 Nov 2000 18:10:52 +0100 From: Arnaud.ATOCH@oecd.org Arnaud.ATOCH@oecd.org Subject: [parisc-linux] Booting 712 with CD 0.5 Thanks for the enlightment. Should I try a new CD-ROM or should I wait untill next ISO image is created ? IS the shutdown also due to this bug ? Setting up /tmp ramdisk4096+0 records in 4096+0 records out mke2fs 1.19, 13-Jul-2000 for EXT2 FS 0.5b, 95/08/09 Filesystem label= OS type: Linux Block size=1024 (log=0) Fragment size=1024 (log=0) 1024 inodes, 4096 blocks 0 blocks (0.00%) reserved for the super user First data block=1 1 block group 8192 blocks per group, 8192 fragments per group 1024 inodes per group Writing inode tables: done Writing superblocks and filesystem accounting information: done INIT: Id "T0" respawni INIT: no more processe -----Original Message----- From: Grant Grundler [mailto:grundler@cup.hp.com] Sent: Friday, November 17, 2000 17:38 To: Arnaud.ATOCH@oecd.org Cc: parisc-linux@puffin.external.hp.com Subject: Re: [parisc-linux] Booting 712 with CD 0.5 Arnaud.ATOCH@oecd.org wrote: > Is the following output the normal behavior of Linux-PARisc on a 712/100 ? > > kmem_create: Forcing size word alignment - nfs_fh > kernel BUG at pci-dma.c:391! > kernel BUG at pci-dma.c:400! The bug is real. A driver is calling pci_map_single() and pci_unmap_single() without specifying which direction the DMA is going. Cache flushing on 712 (PCXL) systems needs to know. I'll assume it's the SCSI driver since it looks like we are talking to a SCSI CD-ROM. grant Grant Grundler Unix Systems Enablement Lab +1.408.447.7253 From rhirst@linuxcare.com Fri, 17 Nov 2000 17:38:18 +0000 Date: Fri, 17 Nov 2000 17:38:18 +0000 From: Richard Hirst rhirst@linuxcare.com Subject: [parisc-linux] SEGV signal handling bug (dynamic linking) On Fri, Nov 17, 2000 at 09:09:10AM -0800, Ulrich Drepper wrote: > Richard Hirst writes: > > > mem = malloc(8192); > > if (mem == NULL) { > > perror("malloc"); > > exit(1); > > } > > mem = (char *)(((int)mem + 4095) & ~0x0fff); > > res = mprotect(mem, 4096, PROT_READ); > > Read the Unix standard: > > The behavior of this function is unspecified if the mapping was not > established by a call to mmap(). Yeh, but it works on m68k and i386, and works on hppa if statically linked. And the code is in an example on the mprotect man page on my Mandrake7 box. Richard From drepper@redhat.com 17 Nov 2000 10:06:21 -0800 Date: 17 Nov 2000 10:06:21 -0800 From: Ulrich Drepper drepper@redhat.com Subject: [parisc-linux] SEGV signal handling bug (dynamic linking) Richard Hirst writes: > Yeh, but it works on m68k and i386, and works on hppa if statically > linked. And the code is in an example on the mprotect man page on > my Mandrake7 box. Then shoot the guy who wrote the man page. It's wrong and will never reliably work. -- ---------------. ,-. 1325 Chesapeake Terrace Ulrich Drepper \ ,-------------------' \ Sunnyvale, CA 94089 USA Red Hat `--' drepper at redhat.com `------------------------ From rhirst@linuxcare.com Fri, 17 Nov 2000 20:10:34 +0000 Date: Fri, 17 Nov 2000 20:10:34 +0000 From: Richard Hirst rhirst@linuxcare.com Subject: [parisc-linux] SEGV signal handling bug (dynamic linking) On Fri, Nov 17, 2000 at 09:09:10AM -0800, Ulrich Drepper wrote: > Richard Hirst writes: > > > mem = malloc(8192); > > if (mem == NULL) { > > perror("malloc"); > > exit(1); > > } > > mem = (char *)(((int)mem + 4095) & ~0x0fff); > > res = mprotect(mem, 4096, PROT_READ); > > Read the Unix standard: > > The behavior of this function is unspecified if the mapping was not > established by a call to mmap(). Changed my prog to use mmap and get the same problem. Richard From grundler@cup.hp.com Fri, 17 Nov 2000 13:50:46 -0800 Date: Fri, 17 Nov 2000 13:50:46 -0800 From: Grant Grundler grundler@cup.hp.com Subject: [parisc-linux] PDC firmware revision FAQ update Hi folks, The issue of PDC/firmware revs came up locally and sounded like a FAQ. I added "10. How can I check if the PDC (firmware) revision is the latest?" and what I knew/could find to our FAQ at: http://www.parisc-linux.org/faq.html The new FAQ entry should be visible to the world in the next hour or so. **** WARNING **** Firmware upgrades can *kill* your machine! **** WARNING **** Don't do it just because. Read the FAQ carefully. Take the time to figure out why you might need the upgrade and expose yourself to this risk. grant ps. please don't ask me why your favorite machine's PDC isn't listed. I don't run the referenced sites. From taggart@carmen.fc.hp.com Fri, 17 Nov 2000 18:26:19 -0700 Date: Fri, 17 Nov 2000 18:26:19 -0700 From: Matt Taggart taggart@carmen.fc.hp.com Subject: [parisc-linux] New cross compiler I have posted new i386/linux -> hppa/linux cross tools at, ftp://puffin.external.hp.com/pub/parisc/binaries/LinuxX86/xc-20001117.tar.gz it includes 32bit and 64bit cross-compilers and a static 32bit glibc 2.2. I have also updated the include tarball, ftp://puffin.external.hp.com/pub/parisc/src/include-20001117.tar.gz it includes glibc 2.2 headers and the latest kernel headers. -- Matt Taggart taggart@fc.hp.com From sandy@storm.ca Fri, 17 Nov 2000 22:54:58 -0500 Date: Fri, 17 Nov 2000 22:54:58 -0500 From: Sandy Harris sandy@storm.ca Subject: [parisc-linux] Host for 712/60 compiles A couple of us have 16 diskless 712/60s which we want to use for distributed processing on easily parallelized tasks like factoring and perhaps crypto cracking. A few questions arise. Is PARISC Linux far enough along to be useful for that? We need no monitor or console (except perhaps for initial debugging), no devices except ethernet, and expect to run only one process per machine, but we need stability. We'll need a host for cross-compiling. We have a 256 meg 715/100 with HP/UX which we expect to use as the host for booting, handing out chunks of work, storing results, etc. Should we compile there under HP/UX or would we get better tools on one of our Intel Linux boxes? Or is PARISC Linux far enough along we should put it on the 715 and get native compilation? From matthew@wil.cx Sat, 18 Nov 2000 07:08:12 +0000 Date: Sat, 18 Nov 2000 07:08:12 +0000 From: Matthew Wilcox matthew@wil.cx Subject: binutils taggart On Wed, Nov 15, 2000 at 05:16:02PM -0700, Matt Taggart wrote: > Modified files: > . : config.guess config.sub > > Log message: > New upstream versions from > http://subversions.gnu.org/cgi-bin/cvsweb/config/ > Now config.guess returns the right thing for hppa-linux so... we needed new versions anyway, even though we're not parisc-linux..? :-) [not bitter, just amused] -- Revolutions do not require corporate support. From matthew@wil.cx Sat, 18 Nov 2000 07:24:54 +0000 Date: Sat, 18 Nov 2000 07:24:54 +0000 From: Matthew Wilcox matthew@wil.cx Subject: [parisc-linux] CVS linux Vs. -test10 On Tue, Nov 14, 2000 at 09:35:01AM -0700, Paul Bame wrote: > > I've attached an overview of differences between our CVS linux sources ok, here's my memories. > * Lots of RCS $Revision$ differences in ACPI (a different 'cvs > import' would've eliminated these differences). i assume someone's already done the appropriate cvs admin -ko magic to fix this? > * drivers/char/Config.in: changes to support LASI, parisc real-time > clock (CONFIG_GENRTC) istr this was `stolen' from the m68k port by sammy. > * drivers/char/serial.c: support for GSC and A500 serial if they're working, send to Ted and he'll do an update with Linus at some point. > * drivers/net/eepro100.c: no clue about this one we were trying to get it to work for the Jan NYLWE show. i doubt we have any changes of note. does anyone have an eepro in an hp? > * drivers/video: STI and HP FB video drivers (iodccon is probably > worthless) agreed on iodccon. unless we're using it up until the point that one of the more advanced consoles takes over? i don't think we are now. > * fs/binfmt_elf.c,exec.c: changes for stack-grows-up? Yes, that's what they're for. > * fs/nfs/read.c: probably unnecessary hack for broken parisc64 gcc we certainly don't want to send it upstream, but we don't want to take it out until the bug is fixed. is fixing that bug on the webshite todo list? > * include/linux/binfmts.h,fs.h,kernel.h,tty.h,udf_fs_sb.h: > unnecessary differences? mostly, yes. > * include/linux/init.h: we use different section names -- why????, > probably some unnecessary other differences too because we use -ffunction-sections. text.init clashes with a function called init, and the linker just merges it into the text segment. we need it to be separate, so it became init.text. there's patches around to do this for other architectures too. just bad naming choices initially. > * include/linux/wait.h: parisc debugging -- should be removed yeah, that can die now. > * scripts/*: MANY differences here. Looks like a combination of > things we hacked to fix configuration problems plus MAYBE not > updating these files from new Linux versions in the past. 'make > menuconfig' is significantly different from upstream. Even the > mkdep.c program is different. ok. mea extremely culpa here. i had an exclude file which included the scripts/ directory. someone should now ditch our stuff, take what's in -test10, hack it till it works for us and check it in. -- Revolutions do not require corporate support. From bzeeb+hplinux@zabbadoz.net Sun, 19 Nov 2000 13:12:25 +0100 (CET) Date: Sun, 19 Nov 2000 13:12:25 +0100 (CET) From: Bjoern A. Zeeb bzeeb+hplinux@zabbadoz.net Subject: [parisc-linux] serial console ? Hi, I just started booting into a 715-100 using palinux-0.5.iso. I did read multiple times that I need serial console. So I plugged in serial cable I an normally using for x86 to x86 serial console on my linux router but I did not get anything on both serial ports :-( What information would one need to help ? personal contact is prefered. I would then sum up all information I got and post it to the list afterwards (if desired). Have to say: I am 'new' to those workstation and had to hoover it first after I got it ;) I also could have a 735-99 with some kind of graphic accelerator if that one would be better. -- Bjoern A. Zeeb bzeeb at Zabbadoz dot NeT 56 69 73 69 74 http://www.zabbadoz.net/ From bzeeb+hplinux@zabbadoz.net Sun, 19 Nov 2000 17:06:11 +0100 (CET) Date: Sun, 19 Nov 2000 17:06:11 +0100 (CET) From: Bjoern A. Zeeb bzeeb+hplinux@zabbadoz.net Subject: [parisc-linux] serial console ? On Sun, 19 Nov 2000, Bjoern A. Zeeb wrote: > I just started booting into a 715-100 using palinux-0.5.iso. > > I did read multiple times that I need serial console. So I plugged in > serial cable I an normally using for x86 to x86 serial console on my > linux router but I did not get anything on both serial ports :-( Hi, sorted out everything. serial cable was quite ok, but using cu I was never able to reach IPL. Using minicom and everything was fine. Had a great success afterwards: installed from CD (palinux-0.5.iso) Everthing worked at once out of the box :-) openssh was enabled on default :-)) only one bad touch: please do not enable portmapper on default. there are too much exploits out there these days. Short: Great great great work !!! -- Bjoern A. Zeeb bzeeb at Zabbadoz dot NeT 56 69 73 69 74 http://www.zabbadoz.net/ From dhazeghi@pacbell.net Sun, 19 Nov 2000 09:24:56 -0800 Date: Sun, 19 Nov 2000 09:24:56 -0800 From: dhazeghi@pacbell.net dhazeghi@pacbell.net Subject: [parisc-linux] glibc-latest tarball broken the glibc-latest tarball on pehc appears to be missing some important subdirectories like scripts and sysdeps. Perhaps a legacy of the 2.2 merge? Thanks, Dara Hazeghi From imatthae@grc.hp.com Sun, 19 Nov 2000 19:35:57 +0100 Date: Sun, 19 Nov 2000 19:35:57 +0100 From: Ingo Matthaes imatthae@grc.hp.com Subject: [parisc-linux] A500 and glibc woes finally we've got a A500 for palinux testing. Unfortunately we have some problems with it. A 32 bit kernel complains about a very old firmware and claims "that machine will probably never run linux" But in fact, it will :-) First question: Did anyone ever succeeded with a 32bit kernel on that hardware ? A 64 bit Kernel boots fine and recognizes all available hardware including the additional 100BT card. But it traps with the init which comes with the latest nfsroot tarball. I built a new one from the sourcesw of debians sysvlinux-2.78 and it does not trap anymore, but the kernel told me about unimplemented 32 syscalls. At this point I tried to build a 64 bit glibc in order to get a crt1.o , which is needed to builf for a 64bit init. Did anyone ever build a 64bit glibc out of the current cvs tree ? Today I've got ologue/epilogue insn (insn 433 431 435 (set (reg:DI 26 %r26) (reg:DI 2 %r2)) -1 (nil) (nil)) ../sysdeps/unix/sysv/linux/init-first.c:105: Unrecognizable insn: (insn 440 438 441 (set (reg:DI 24 %r24) (lo_sum:DI (reg:DI 1 %r1) (symbol_ref:DI ("LP$-001")))) -1 (insn_list 437 (nil)) (expr_list:REG_DEAD (reg:DI 1 %r1) (expr_list:REG_UNUSED (reg:DI 24 %r24) (nil)))) ../sysdeps/unix/sysv/linux/init-first.c:105: Internal compiler error in num_delay_slots, at insn-attrtab.c:2505 Thats the point I'm currently stucking. BTW If someone involved into the port with access to the internal HP Network needs access to that machine, please contact me. Later Ingo -- Tel: ++49-2102-908-210 German Response Center Fax: ++49-2102-907-934 Berliner Str. 111 Mailto: Ingo_Matthaes@hp.com 40880 Ratingen Germany HP Unix/Linux Competency Center Network and High AvailabilitY OpenPGP fingerprint = 4298E7785FFD65DC8950 14E9F17F8CB5B611AA4A From alan@linuxcare.com.au Mon, 20 Nov 2000 14:03:16 +1100 (EST) Date: Mon, 20 Nov 2000 14:03:16 +1100 (EST) From: Alan Modra alan@linuxcare.com.au Subject: Single-stepping On Thu, 16 Nov 2000, John Marvin wrote: > Anyway, for reference, HP-UX does single stepping by using a combination > of the taken branch trap, and loading the instruction queues such that the > front of the queue points to the next instruction to be single stepped and > the back of the queue points to the first of two break instructions on a > "break" page. It does NOT insert break instructions into the code, so it > does not adversely affect execution on a SMP machine. Note that we > already put a bunch of break instructions before the syscall entry point > on the gateway page, so it would be easy to use our gateway page for the > "break page". This way, if the single stepped instruction branches, a > taken branch trap will be taken (which is important in the case where the > branch nullifies its delay slot). Otherwise, the instruction will be > executed and then the break instruction at the known location on the > "break" page will be executed. If the single stepped instruction > nullifies the next instruction, the second break instruction on the > "break" page will be executed. This is the path I started out on for hppa-linux, then hit the problem of a branch that nullifies it's delay slot. At that point, I decided playing with IAOQ_back wouldn't work as I missed the solution of enabling taken branch traps. :-( If I'd seen this trick, then I would not have tried using the recovery counter, and even now, it may be better to go back to IAOQ fiddling. The recovery counter scheme has the disadvantage that there's only one of them so you need to save/restore over task swaps or introduce extra instructions in the syscall path - and be very careful. > Note that this is the short explanation. It is not as simple as it sounds. > One major complication is that branches with links don't work properly > with the instruction queue magic, so the link register has to be updated > in the taken branch trap handler. Also branch externals won't update > the space of the space queue tail properly (again, that has to be fixed > in the taken branch handler). I can provide more details if the recovery > counter method doesn't work out. I'm a little intrigued about these "complications". How can the link register or space _not_ be updated properly? As far as I can see, the only really tricky instruction to single-step is RFI - which shouldn't ever occur in userspace, and which we'd just emulate if it was important. Alan Modra -- Linuxcare. Support for the Revolution. From jsm@udlkern.fc.hp.com Sun, 19 Nov 2000 22:43:02 -0700 (MST) Date: Sun, 19 Nov 2000 22:43:02 -0700 (MST) From: John Marvin jsm@udlkern.fc.hp.com Subject: Single-stepping > > Note that this is the short explanation. It is not as simple as it sounds. > > One major complication is that branches with links don't work properly > > with the instruction queue magic, so the link register has to be updated > > in the taken branch trap handler. Also branch externals won't update > > the space of the space queue tail properly (again, that has to be fixed > > in the taken branch handler). I can provide more details if the recovery > > counter method doesn't work out. > > I'm a little intrigued about these "complications". How can the link > register or space _not_ be updated properly? As far as I can see, the > only really tricky instruction to single-step is RFI - which shouldn't > ever occur in userspace, and which we'd just emulate if it was important. The problem is that the link register is set to IAOQ_Back + 4. and in the case of ble, sr0 is set to IASQ_Back. Since we've played games with the queues, IAOQ_Back and IASQ_Back are pointing at the break page, not at the instruction following the branch. The additional complication is that the taken branch trap traps at the branch destination, not at the branch, so at the point of the trap you don't know where you came from in order to fix the problem easily. So, what HP-UX does is check each instruction before it executes it to see if it is a branch, and if so, what the link register is (and that is all that needs to be parsed, since we are not emulating the instruction). It then stores the branch location, and also sets some branch state flags (e.g. UBE for a branch external, and UBL for a branch with a link, both flags being set for a ble instruction). Then in the taken branch handler you have all the information you need to fix the queue. You also need to check this saved state if a signal handler is invoked while single stepping, so that the proper pc queue values can be saved in the signal context. John Marvin jsm@fc.hp.com From jsm@udlkern.fc.hp.com Sun, 19 Nov 2000 23:01:20 -0700 (MST) Date: Sun, 19 Nov 2000 23:01:20 -0700 (MST) From: John Marvin jsm@udlkern.fc.hp.com Subject: A500 and glibc woes Ingo, > > finally we've got a A500 for palinux testing. Unfortunately > we have some problems with it. > A 32 bit kernel complains about a very old firmware and claims > "that machine will probably never run linux" But in fact, it > will :-) Actually, there are no plans to ever support the A500 on a 32 bit kernel. The A500 only has 64 bit firmware, so in order to support it we would need to write a 32->64 bit firmware translation layer. ... > A 64 bit Kernel boots fine and recognizes all available hardware > including the additional 100BT card. But it traps with the init > which comes with the latest nfsroot tarball. I built a new one > from the sourcesw of debians sysvlinux-2.78 and it does not trap > anymore, but the kernel told me about unimplemented 32 syscalls. > At this point I tried to build a 64 bit glibc in order to get > a crt1.o , which is needed to builf for a 64bit init. > Well, it might seem crazy, but our short term plans do not include supporting a 64 bit user environment on the 64 bit kernel. Long term I believe this will happen, but as you have already seen, work needs to be done to support 64 bit glibc, shared libraries, etc. So, in order to get the A500 to boot, we need to support the 32 bit user environment on a 64 bit kernel. We've only recently gotten to the point where the 64 bit kernel gets far enough to start running user space applications. The problem is that we need to write translations for many system calls, since type sizes (and the structures those types are in) are different between 32 bit and 64 bit (the ugliest case is the ioctl system call). In summary, the A500 currently won't work, but since it is one of the machines that HP has targetted for Linux support, you can be sure that this will change fairly soon. John Marvin jsm@fc.hp.com From grundler@cup.hp.com Sun, 19 Nov 2000 22:47:27 -0800 Date: Sun, 19 Nov 2000 22:47:27 -0800 From: Grant Grundler grundler@cup.hp.com Subject: [parisc-linux] A500 and glibc woes Ingo Matthaes wrote: > finally we've got a A500 for palinux testing. Unfortunately > we have some problems with it. Ingo, uhmm...I'm not surprised. Let me help you understand the A500 and the direction we are going with support on the A500. I'm one of several people working on A500 support. A500 Features (marketing crud - you probably know this): o 16GB of RAM o 2-way 550 MHz PA8600 o 4 PCI-4X slots (3 of which are 1 slot per PCI bus) o all in 2U rack mountable box. Inside is (technical crud): o PCX-W+ o Astro IOMMU (aka SBA. Provides cache-coherent DMA and virtual I/O DMA) o Elroy PCI Host Bus Adapter (aka LBA) o IOSAPIC interrupt controller (integrated in Elroy) o PAT PDC (not legacy) o ^B for service processor access (ie I can reset the machine remotely) > A 32 bit kernel complains about a very old firmware and claims > "that machine will probably never run linux" But in fact, it > will :-) That's right! :^) > First question: Did anyone ever succeeded with a 32bit kernel > on that hardware ? No. Only on *64-bit* kernels. The reason is some of the PAT PDC calls we need are *only* available in wide mode. We could have written narrow<->wide mode translation routines but a 32-bit kernel ignores the A500's best feature - 16GB of RAM. The issue is HP needs good specweb99 numbers to sell these boxes and that requires GB of RAM. The 512MB of RAM that 32-bit kernel currently supports (jsm tells me 3GB or so can be done) won't approach the perf levels which can be acheived with 8 or 16GB. The HPUX specweb team (who just *beat* single CPU TUX specweb99 numbers with HPUX on A500) told me. They have a clue. You are welcome to write those translation routines and then *remove* many the "#ifdef __LP64__" preprocessor directives in arch/parisc/kernel/inventory.c and lba_pci.c. Send me the patch and I'll test/review/commit the changes. > A 64 bit Kernel boots fine and recognizes all available hardware > including the additional 100BT card. But it traps with the init > which comes with the latest nfsroot tarball. There are issues/problems with PCI resource management and I have some code waiting to be tested when I get in tomorrow. But you can be very helpful with user space! Perhaps Paul Bame can be more specific. But basically we don't have all the translation routines in place for 32-bit applications invoking 64-bit kernel syscalls. > I built a new one > from the sourcesw of debians sysvlinux-2.78 and it does not trap > anymore, but the kernel told me about unimplemented 32 syscalls. Right. > At this point I tried to build a 64 bit glibc in order to get > a crt1.o , which is needed to builf for a 64bit init. > > Did anyone ever build a 64bit glibc out of the current cvs tree ? I don't think so. Eventually we wanted to but haven't been able yet. So this great that you are trying! > Today I've got ... Can someone one with a clue about toolchain look at that? I'd be really impressed if someone got a 64-bit userspace built! I can help get kernel working right but don't have a clue about the tools. The 64-bit kernel can be booted on the following class of boxes to about the same point as the A500: o C160/180/200/240/360 o B2000/C3000/J5000/C3600/J5600/J6000 o some D/K/R-class machines The key is the box must have PCX-U (PA8000), PCX-U+ (PA8200), PCX-W (PA8500) or PCX-W+ (PA8600) processor. Look in the HWDB (http://www.parisc-linux.org/hw.html) or in /usr/sam/lib/mo/sched.models (HPUX 11.x) to determine which processor you have. > Thats the point I'm currently stucking. > > BTW If someone involved into the port with access to the internal HP > Network needs access to that machine, please contact me. Ditto. I can arrange access to my A500 as well. External access to some limited number of people could be arranged if demand is justifiable. But given the number of other boxes which can run 64-bit kernel, I hope that's not necessary. Thanks Ingo! grant Grant Grundler Unix Systems Enablement Lab +1.408.447.7253 From alan@linuxcare.com.au Mon, 20 Nov 2000 17:53:18 +1100 (EST) Date: Mon, 20 Nov 2000 17:53:18 +1100 (EST) From: Alan Modra alan@linuxcare.com.au Subject: Single-stepping On Sun, 19 Nov 2000, John Marvin wrote: > > I'm a little intrigued about these "complications". How can the link > > register or space _not_ be updated properly? As far as I can see, the > > only really tricky instruction to single-step is RFI - which shouldn't > > ever occur in userspace, and which we'd just emulate if it was important. > > The problem is that the link register is set to IAOQ_Back + 4. and in > the case of ble, sr0 is set to IASQ_Back. Since we've played games with > the queues, IAOQ_Back and IASQ_Back are pointing at the break page, not > at the instruction following the branch. Ah. That is a little nasty, especially given the effect on signal handlers you mention below. Maybe using the recovery counter isn't such a bad idea after all, especially since the added syscall and task switch overhead can be quite small if the kernel only supports single-step by one instruction. > The additional complication is that the taken branch trap traps at the > branch destination, not at the branch, so at the point of the trap you > don't know where you came from in order to fix the problem easily. So, > what HP-UX does is check each instruction before it executes it to see if > it is a branch, and if so, what the link register is (and that is all that > needs to be parsed, since we are not emulating the instruction). It then > stores the branch location, and also sets some branch state flags (e.g. > UBE for a branch external, and UBL for a branch with a link, both flags > being set for a ble instruction). Then in the taken branch handler you > have all the information you need to fix the queue. You also need > to check this saved state if a signal handler is invoked while single > stepping, so that the proper pc queue values can be saved in the signal > context. Another question for you and/or the list in general: Why does struct pt_regs have an ipsw field? Seems like it currently is unused. Regards, Alan Modra -- Linuxcare. Support for the Revolution. From grundler@cup.hp.com Sun, 19 Nov 2000 23:05:26 -0800 Date: Sun, 19 Nov 2000 23:05:26 -0800 From: Grant Grundler grundler@cup.hp.com Subject: [parisc-linux] Host for 712/60 compiles Sandy Harris wrote: > A couple of us have 16 diskless 712/60s which we want to use for distributed > processing on easily parallelized tasks like factoring and perhaps crypto > cracking. A few questions arise. > > Is PARISC Linux far enough along to be useful for that? We need no monitor or > console (except perhaps for initial debugging), no devices except ethernet, > and expect to run only one process per machine, but we need stability. It's not rock solid. On 712's, it should be pretty good though. > We'll need a host for cross-compiling. We have a 256 meg 715/100 with HP/UX > which we expect to use as the host for booting, handing out chunks of work, > storing results, etc. Should we compile there under HP/UX or would we get > better tools on one of our Intel Linux boxes? I don't think anyone has tried to cross-compile parisc-linux on an HPUX host in quite a while. > Or is PARISC Linux far enough along we should put it on the 715 and get > native compilation? AFAIK, all of the debian packages on the ISO image are built natively. But using a dual P700 linux box would be alot faster. :^) grant Grant Grundler Unix Systems Enablement Lab +1.408.447.7253 From sieler@allegro.com Sun, 19 Nov 2000 23:24:00 -0800 (PST) Date: Sun, 19 Nov 2000 23:24:00 -0800 (PST) From: Stan Sieler sieler@allegro.com Subject: Single-stepping Re: > handlers you mention below. Maybe using the recovery counter isn't such a quite true. > bad idea after all, especially since the added syscall and task switch > overhead can be quite small if the kernel only supports single-step by > one instruction. why the limit? We've used multi-instruction "single step" (oxymoron :) for about 15 years on PA-RISC...no problems, efficient, and *very* useful! -- Stan Sieler sieler@allegro.com www.allegro.com/sieler/wanted/index.html www.sieler.com From grundler@cup.hp.com Sun, 19 Nov 2000 23:44:42 -0800 Date: Sun, 19 Nov 2000 23:44:42 -0800 From: Grant Grundler grundler@cup.hp.com Subject: [parisc-linux] CVS linux Vs. -test10 Matthew Wilcox wrote: > On Tue, Nov 14, 2000 at 09:35:01AM -0700, Paul Bame wrote: > ok, here's my memories. Thanks Matthew! hehe...sounds like someone's getting older. :^) ... > > * drivers/net/eepro100.c: no clue about this one > > we were trying to get it to work for the Jan NYLWE show. I think I did that. IIRC, it's a one-line change to use I/O port space since MMIO wasn't usable without more invasive changes. > i doubt we have any changes of note. does anyone have an eepro in an hp? I have picked nearly 30 i82557/i82558 PCI cards from scrap yard. And maybe a few i82559 even. Did you need one (or two)? :^) FWIW, this is the card/driver which I think was causing misaligned data reference traps. I never had a chance to followup with this though. At the time, I thought it would be *really* fun to show this working to HP's marketing team... > > * fs/nfs/read.c: probably unnecessary hack for broken parisc64 gcc > > we certainly don't want to send it upstream, but we don't want to take it > out until the bug is fixed. is fixing that bug on the webshite todo list? I don't think so. It's possible it's already fixed. Relevant CVS log entry: | revision 1.5 | date: 2000/07/18 03:15:25; author: dhd; state: Exp; lines: +5 -0 | ARGH! When I put in an assertion, NFS stops breaking randomly. I | suspect this is a compiler or binutils problem but I can't see any | clear differences in the generated code. I'll debug it later... This sounds like the hppa64 bug we saw with %r29 getting trashed. But I don't think David was working on hppa64 kernel at the time. I can test 32-bit NFS Root tomorrow w/o assertion if no one else beats me to it. > > * include/linux/init.h: we use different section names -- why????, > > probably some unnecessary other differences too > > because we use -ffunction-sections. text.init clashes with a function > called init, and the linker just merges it into the text segment. we > need it to be separate, so it became init.text. there's patches around > to do this for other architectures too. just bad naming choices initially. We need to resolve this in order to merge upstream. Matthew, any advice on how we should proceed? Or would be easier for you pester Alan Cox and just get it fixed? > > * include/linux/wait.h: parisc debugging -- should be removed > > yeah, that can die now. I'd be happy to fix this by clobbering the current version with what's in linux-2.4.0-test10. But what is the "right" way to revert changes we've made so this doesn't show up in next merge? I'll need to know this in order to revert the fs/nfs/read.c change as well. thanks, grant Grant Grundler Unix Systems Enablement Lab +1.408.447.7253 From milang@tal.org Mon, 20 Nov 2000 10:57:36 +0200 Date: Mon, 20 Nov 2000 10:57:36 +0200 From: Kaj-Michael Lang milang@tal.org Subject: [parisc-linux] Palinux on a 712/60 > Thanks for the reply, Grant. However, the 712s do not have a serial console. Yes it does.. it's just undocumented. Unfortunately I don't have the information here, but I have succesfully changed the console to serial on one of my 712. Kaj-Michael Lang milang@tal.org From alan@linuxcare.com.au Mon, 20 Nov 2000 20:05:58 +1100 (EST) Date: Mon, 20 Nov 2000 20:05:58 +1100 (EST) From: Alan Modra alan@linuxcare.com.au Subject: Single-stepping On Sun, 19 Nov 2000, Stan Sieler wrote: > > bad idea after all, especially since the added syscall and task switch > > overhead can be quite small if the kernel only supports single-step by > > one instruction. > > why the limit? We've used multi-instruction "single step" (oxymoron :) > for about 15 years on PA-RISC...no problems, efficient, and *very* > useful! Because you would then need to save and restore cr0 on task switches (or only allow one task to be single-stepped at a time). That's four instructions and two extra memory accesses per task switch. Which might not seem very much, but at some point somebody will no doubt start caring about pa-linux performance. For a single-step by one, you can simply set cr0 to zero on a task switch, and possibly avoid touching cr0 on a task switch at all with careful attention to various trap handlers. Here's the idea. The tail of syscall_restore (64-bit stuff pruned) will look like the following, with the first three instructions being the added code to support single-step (and also wide/narrow switching for 64-bit) ldi 3,%r20 mtctl $r20,%cr0 /* recovery counter, ptrace single-step */ LDREG TASK_PT_PSW(%r1),%r20 mtctl %r1,%cr30 /* intrhandler okay. */ mfsp %sr3,%r1 /* Get users space id */ mtsp %r1,%sr4 /* Restore sr4 */ mtsp %r1,%sr5 /* Restore sr5 */ mtsp %r1,%sr6 /* Restore sr6 */ depi 3,31,2,%r31 /* ensure return to user mode. */ mtsm %r20 /* restore irq state */ mfctl %cr27,%r20 be 0(%sr3,%r31) /* return to user space */ mtsp %r1,%sr7 /* Restore sr7 */ ptrace will fiddle with TASK_PT_PSW, setting the R bit and clearing the I bit to enable the recovery counter - which will start counting down at the mtsm instruction above, and reach zero on the user-space instruction, so we'll trap after executing one user-space instruction. The task-switch nonsense is to handle the case where we page-fault on the instruction and switch to another task also doing single-stepping. You want to ensure cr0 is zero when we finally get back to the original task. Now it might turn out that having extra instructions in the syscall path is worse than extra code and memory accesses on task switch. If that turns out to be true, then you'll probably get your multi-step ptrace. :-) Alan Modra -- Linuxcare. Support for the Revolution. From M_Wild@tunstall.co.uk Mon, 20 Nov 2000 10:21:32 -0000 Date: Mon, 20 Nov 2000 10:21:32 -0000 From: Mark Wild M_Wild@tunstall.co.uk Subject: [parisc-linux] Upgrading memory on a 710 Hi, I have acquired some 8MB SIMMs suitable for my old 710 workstation and wish to utilise them. I don't have any docs for the 710 and was wondering if anyone could point me in the direction of some. I've looked on the HP website but could only find some for 712s, 720, 730 etc. Alternatively, if anyone knows whether any motherboard links need to be changed, whether SIMMS need to be added in pairs / quads and which memory configurations are allowed I would be grateful. Thanks, Mark Wild -- From matthew@wil.cx Mon, 20 Nov 2000 10:50:57 +0000 Date: Mon, 20 Nov 2000 10:50:57 +0000 From: Matthew Wilcox matthew@wil.cx Subject: [parisc-linux] A500 and glibc woes On Sun, Nov 19, 2000 at 07:35:57PM +0100, Ingo Matthaes wrote: > finally we've got a A500 for palinux testing. Unfortunately > we have some problems with it. > A 32 bit kernel complains about a very old firmware and claims > "that machine will probably never run linux" But in fact, it > will :-) > First question: Did anyone ever succeeded with a 32bit kernel > on that hardware ? It's not intended to work; I doubt anyone has tried. You should build a 64 bit kernel. > A 64 bit Kernel boots fine and recognizes all available hardware > including the additional 100BT card. But it traps with the init > which comes with the latest nfsroot tarball. I built a new one > from the sourcesw of debians sysvlinux-2.78 and it does not trap > anymore, but the kernel told me about unimplemented 32 syscalls. > At this point I tried to build a 64 bit glibc in order to get > a crt1.o , which is needed to builf for a 64bit init. Don't try a 64-bit userland yet. What you need to do is implement some of the 32-bit syscalls. -- Revolutions do not require corporate support. From matthew@wil.cx Mon, 20 Nov 2000 11:17:26 +0000 Date: Mon, 20 Nov 2000 11:17:26 +0000 From: Matthew Wilcox matthew@wil.cx Subject: [parisc-linux] CVS linux Vs. -test10 On Sun, Nov 19, 2000 at 11:44:42PM -0800, Grant Grundler wrote: > Matthew Wilcox wrote: > > On Tue, Nov 14, 2000 at 09:35:01AM -0700, Paul Bame wrote: > > ok, here's my memories. > > Thanks Matthew! > > hehe...sounds like someone's getting older. :^) ... when i were a lad, all this were fields! Our dad used to kill us every morning, we'd get up half an hour before we went to bed and walk uphill both to and from school... > ... > > > * drivers/net/eepro100.c: no clue about this one > > > > we were trying to get it to work for the Jan NYLWE show. > > I think I did that. IIRC, it's a one-line change to use I/O port > space since MMIO wasn't usable without more invasive changes. sounds right. MMIO should work now though, right? > > i doubt we have any changes of note. does anyone have an eepro in an hp? > > I have picked nearly 30 i82557/i82558 PCI cards from scrap yard. > And maybe a few i82559 even. Did you need one (or two)? :^) Heh, I only have a 712 right now :-) > FWIW, this is the card/driver which I think was causing misaligned > data reference traps. I never had a chance to followup with this though. > At the time, I thought it would be *really* fun to show this working > to HP's marketing team... Oh yes, I remember that now. Tulip always does a copy (well, it doesn't _have_ to, but we tell it to, just like the Alpha does). > > > * fs/nfs/read.c: probably unnecessary hack for broken parisc64 gcc > > > > we certainly don't want to send it upstream, but we don't want to take it > > out until the bug is fixed. is fixing that bug on the webshite todo list? > > I don't think so. It's possible it's already fixed. > > Relevant CVS log entry: > | revision 1.5 > | date: 2000/07/18 03:15:25; author: dhd; state: Exp; lines: +5 -0 > | ARGH! When I put in an assertion, NFS stops breaking randomly. I > | suspect this is a compiler or binutils problem but I can't see any > | clear differences in the generated code. I'll debug it later... > > This sounds like the hppa64 bug we saw with %r29 getting trashed. > But I don't think David was working on hppa64 kernel at the time. > I can test 32-bit NFS Root tomorrow w/o assertion if no one else > beats me to it. it was definitely a 32-bit kernel at the time. It might be the same bug, but I'm not sure. > > > * include/linux/init.h: we use different section names -- why????, > > > probably some unnecessary other differences too > > > > because we use -ffunction-sections. text.init clashes with a function > > called init, and the linker just merges it into the text segment. we > > need it to be separate, so it became init.text. there's patches around > > to do this for other architectures too. just bad naming choices initially. > > We need to resolve this in order to merge upstream. > Matthew, any advice on how we should proceed? > Or would be easier for you pester Alan Cox and just get it fixed? Hm. Alan's not hacking on 2.4, last I heard. I might pester Linus and see if we can change that. It's a mechanical change so he might not be averse to it at this point. Bear in mind we don't need to do a complete merge at this point -- most architectures have a separate patch to apply on top of Linus' tree. > > > * include/linux/wait.h: parisc debugging -- should be removed > > > > yeah, that can die now. > > I'd be happy to fix this by clobbering the current version with what's in > linux-2.4.0-test10. But what is the "right" way to revert changes we've made > so this doesn't show up in next merge? I don't know that there's an official way to do this. I always changed the file to its previous state and then committed it. There are a number of ways of doing it; perhaps the cleanest is: cvs diff -r1.4 -r1.5 fs/nfs/read.c >../read.c.diff (then check the read.c.diff file) patch -p1 <../read.c.diff rm ../read.c.diff or you can just delete the lines yourself. Use diff to make sure there aren't any silly cosmetic changes (eg whitespace). -- Revolutions do not require corporate support. From grundler@cup.hp.com Mon, 20 Nov 2000 09:34:31 -0800 Date: Mon, 20 Nov 2000 09:34:31 -0800 From: Grant Grundler grundler@cup.hp.com Subject: [parisc-linux] CVS linux Vs. -test10 Matthew Wilcox wrote: ... > sounds right. MMIO should work now though, right? It would have worked then too. Changing it to use MMIO space would require disabling I/O Port space by defining inb/outb locally to use gsc_readb/writeb. My problem with doing that was the semantics are slightly different. I/O Port space is non-postable and MMIO space is. I wasn't confident a driver written to use I/O port space would work right under MMIO though some certainly do. ... > it was definitely a 32-bit kernel at the time. It might be the same bug, > but I'm not sure. Can't be. AP (%r29) is a 64-bit only construct. dhd also just confirmed it was 32-bit kernel. I'll try it now. ... > > We need to resolve this in order to merge upstream. > > Matthew, any advice on how we should proceed? > > Or would be easier for you pester Alan Cox and just get it fixed? > > Hm. Alan's not hacking on 2.4, last I heard. I might pester Linus and > see if we can change that. It's a mechanical change so he might not be > averse to it at this point. Bear in mind we don't need to do a complete > merge at this point -- most architectures have a separate patch to apply > on top of Linus' tree. Ok. What's the first step to getting arch/parisc* and include/asm-parisc* into Linus's tree? I had dinner with Bdale Garbee last night and one of two things he made clear was we need to unfork from debian and linus's tree in order to move forward. All our CVS branches need to become obsolete or "local sandboxes" of the respective upstream partners. Feeding kernel bits upstream will bring a new level of visibility (and *HELP*) to the parisc-linux port. I totally agree with Bdale. I understand alot of work still needs to happen in our tree (eg though sba_iommu.c works, it's current form sucks) But pushing bits upstream to linus will not preclude us from doing that work. I also find it odd that glibc is merged upstream *before* the kernel is. For the record, the second issue bdale made clear was we need "boot floppies" debian package working. We don't need more ISO images (no offense to pjlahaie for his good work). "Boot floppies" is a pre-requisite to becoming part of the next debian release. Given I still don't have a clue how to build a debian package and I can still contribute alot in other areas, it doesn't make sense for me to do it myself. > > I'd be happy to fix this by clobbering the current version with what's in > > linux-2.4.0-test10. But what is the "right" way to revert changes we've made > > so this doesn't show up in next merge? > > I don't know that there's an official way to do this. I always changed > the file to its previous state and then committed it. There are a number of > ways of doing it; perhaps the cleanest is: > > cvs diff -r1.4 -r1.5 fs/nfs/read.c >../read.c.diff > (then check the read.c.diff file) > patch -p1 <../read.c.diff > rm ../read.c.diff > > or you can just delete the lines yourself. Use diff to make sure there > aren't any silly cosmetic changes (eg whitespace). The part you described above is the easy part - np. I'm worried about labels and tracking how we "name" the releases. Mang or other CVS ninja's care to comment? thanks, grant Grant Grundler Unix Systems Enablement Lab +1.408.447.7253 From rhirst@linuxcare.com Mon, 20 Nov 2000 17:58:38 +0000 Date: Mon, 20 Nov 2000 17:58:38 +0000 From: Richard Hirst rhirst@linuxcare.com Subject: [parisc-linux] signal handling problems (32 bit kernel) Hi, Following on from my problems with SEGV last week, I've come up with a few signal handling issues: ============================================================= parisc:signal.c /* Possibly bogus. */ #warning XXX FIXME probably bogus -PB /* I think this is bogus -- it'll cause the first instn of the * signal handler to be executed twice! Better might be to * set iaoq[0] to one of the NOPs in the trampoline. -PB */ regs->iaoq[0] = (unsigned long) haddr | 3; regs->iaoq[1] = (unsigned long) haddr | 3; This causes real problems if the signal handler is a dynamic object which has not yet been resolved; in that case the signal handler points at the b,l instr in the following at the end of the .plt: 2700: 0e 80 10 96 ldw 0(sr0,r20),r22 2704: ea c0 c0 00 bv r0(r22) 2708: 0e 88 10 95 ldw 4(sr0,r20),r21 270c: ea 9f 1f dd b,l 2700 <__DTOR_END__+0x54>,r20 2710: d6 80 1c 1e depwi 0,31,2,r20 typically that results in a misalligned access on the first ldw as r20 is screwed. I've fixed that by setting iaoq[1] = iaoq[0]+4. Is that OK, or should we use the NOP approach in the comment above? ============================================================= If a program gets a SEGV, fixes the cause of it in its signal handler, and returns, then the faulting instruction is not rerun. I think that's wrong (differs from m68k anyway). ============================================================= Set the following program running: #include #include #include #include int v[8]; void (* fp)(int); void sig_handler(int sig) { } void poke(int i) { v[0] = i; v[1] = i; v[2] = i; v[3] = i; v[4] = i; v[5] = i; v[6] = i; v[7] = i; } int main() { int j, i = 0; struct sigaction act; memset(&act, 0, sizeof(act)); act.sa_handler = sig_handler; sigaction(SIGUSR1, &act, NULL); fp = sig_handler; fp(0); printf("I am %d\n", getpid()); while (1) { poke (++i); j = v[7]; if (j != i) printf("Wah!\n"); } } and then in another terminal do 'kill -USR1 '. The program either goes 'Wah!', gives a SEGV, or works. That seems to be because %r1 is corrupted while processing the signal. The signal handler ends with a syscall (rt_sigreturn_wrapper), and %r1, at least, is not saved and restored over the syscall. %r31 also appears to get corrupted, as it is used in the final branch of the syscall return. Richard From sieler@allegro.com Mon, 20 Nov 2000 10:47:38 -0800 (PST) Date: Mon, 20 Nov 2000 10:47:38 -0800 (PST) From: Stan Sieler sieler@allegro.com Subject: Single-stepping Re: > Because you would then need to save and restore cr0 on task switches (or > only allow one task to be single-stepped at a time). That's four > instructions and two extra memory accesses per task switch. Which might > not seem very much, but at some point somebody will no doubt start caring > about pa-linux performance. And it still won't seem like much, then! Non-memory-access instructions are cheap. An extra memory reference (from something probably already in cache) and two extra instructions would probably cost less than an hour per CPU over the next 10 *years*, assuming 10 years of 1000 task switches per second on a slow 100 MHz CPU. Of course, at the cost of an extra non-memory-referencing instruction or so, you could say "at switch-to-task time: if PSW R-bit set, then load the saved CR0 from memory and move it to CR0", saving one memory reference 99.99999% of the time, resuling in an average of only one memory reference per task switch normally. I haven't look at interrupt handling / system calls closely, but I hope there aren't other false savings. (E.g., failure to save/restore the PID check flag ... sure, user processes *now* probably never have pid checking disabled, but that's a very useful feature to have available (with proper security controls, of course).) (Yes, I'm one of the very few who use that feature on MPE/iX ... carefully, of course :) -- Stan Sieler sieler@allegro.com www.allegro.com/sieler/wanted/index.html www.sieler.com From grundler@cup.hp.com Mon, 20 Nov 2000 11:23:40 -0800 Date: Mon, 20 Nov 2000 11:23:40 -0800 From: Grant Grundler grundler@cup.hp.com Subject: [parisc-linux] CVS linux Vs. -test10 Matthew Wilcox wrote: ... > > * fs/nfs/read.c: probably unnecessary hack for broken parisc64 gcc > > we certainly don't want to send it upstream, but we don't want to take it > out until the bug is fixed. is fixing that bug on the webshite todo list? It's fixed. I was able to NFS boot my A180 and install palinux-0.5.iso bits on the SCSI disk. I've reverted the change to the LINUS_240_TEST10 version. > > * include/linux/wait.h: parisc debugging -- should be removed > > yeah, that can die now. Is anyone else already doing this? thanks, grant Grant Grundler Unix Systems Enablement Lab +1.408.447.7253 From herrold@owlriver.com Mon, 20 Nov 2000 15:40:24 -0500 (EST) Date: Mon, 20 Nov 2000 15:40:24 -0500 (EST) From: herrold herrold@owlriver.com Subject: Serial vs. STI console selector was: Re: [parisc-linux] Beta CD On Tue, 14 Nov 2000, Paul J.Y. Lahaie wrote: > This is to answer all the questions about sti console. Currently, in the > CVS tree, serial console and STI console cannot be turned on at the same time. > > This means that a choice between serial/sti needs to be done at compile > time. > If you have any more questions or suggestions, feel free to email me or > post on this list. Thank you. ... Query -- Background: Back in the early 70's with a HP 8090 , IBM 1401, IBM 1620, and IBM 360/40, we faced such issues (Don't ask my age, please) -- The solution was to probe for, and look for 'sense switches' in unusual state -- that is -- Some condition which we could examine, and yet not hose up the boot proces on the host. -- CapsLock set on a keyboard driver -- DSR on a serial line, a 'console sense switch' normally kept off but turned on ... so on. Sort of like working through a qualitative analysis flowchart in non-organic chemistry. Is this possible, to allow support of both, with a single kernel? -- Russ From grundler@cup.hp.com Mon, 20 Nov 2000 12:59:41 -0800 Date: Mon, 20 Nov 2000 12:59:41 -0800 From: Grant Grundler grundler@cup.hp.com Subject: Serial vs. STI console selector was: Re: [parisc-linux] Beta CD "Russ" herrold wrote: > Is this possible, to allow support of both, with a single kernel? Yes. I think the issues are code not stomping on each other. And it's easy than you might think - PDC can tell us what the primary console is. grant Grant Grundler Unix Systems Enablement Lab +1.408.447.7253 From grundler@cup.hp.com Mon, 20 Nov 2000 17:19:03 -0800 (PST) Date: Mon, 20 Nov 2000 17:19:03 -0800 (PST) From: Grant Grundler grundler@cup.hp.com Subject: [parisc-linux] 712 ISL and palo Hi Paul (Bame), I tried booting 712 with "bo scsi.4.0 isl" with the palinux-0.5.iso image on a regular hard disk. I wanted to edit the "root" parameter so it would be /dev/sdb (also had a disk at scsi.0.0) instead of /dev/scd0. palo wouldn't accept any ps/2 keyboard input. Don't know if this is a palo or PDC bug. Any ideas? thanks, grant From alan@linuxcare.com.au Tue, 21 Nov 2000 12:55:42 +1100 (EST) Date: Tue, 21 Nov 2000 12:55:42 +1100 (EST) From: Alan Modra alan@linuxcare.com.au Subject: A DT_INIT/DT_FINI glibc patch. On Thu, 16 Nov 2000, H . J . Lu wrote: > While we are on this subject, I looked at the hppa code. It seems to > have the same bug. I have an impression that HP never really used > DT_INIT/DT_FINI. They use DT_INIT_ARRAY/DT_FINI_ARRAY. I don't know > if we should fix hppa also. Yes to all of these comments. elf32-hppa stole some ideas from ia64, which is why the bug is common. Fortunately, I think hppa ld.so etc. can be fixed in a way such that current (broken ABI) binaries will still work. Alan Modra -- Linuxcare. Support for the Revolution. From taggart@carmen.fc.hp.com Mon, 20 Nov 2000 20:12:33 -0700 Date: Mon, 20 Nov 2000 20:12:33 -0700 From: Matt Taggart taggart@carmen.fc.hp.com Subject: [parisc-linux] glibc-latest tarball broken dhazeghi@pacbell.net writes... > the glibc-latest tarball on pehc appears to be missing some important > subdirectories like scripts and sysdeps. Perhaps a legacy of the 2.2 > merge? Disk space problem. I made some room and generated new tarballs. Thanks for pointing out the problem. -- Matt Taggart taggart@fc.hp.com From alan@linuxcare.com.au Tue, 21 Nov 2000 14:22:53 +1100 (EST) Date: Tue, 21 Nov 2000 14:22:53 +1100 (EST) From: Alan Modra alan@linuxcare.com.au Subject: A DT_INIT/DT_FINI glibc patch. On Mon, 20 Nov 2000, Grant Grundler wrote: > I'm afraid we will break binary compatibility for elf32 hppa-linux again. > I only raise this in case there is really a "right" way to fix the > DT_INIT/DT_FINI problem. The fix involves pruning out all the special handling in bfd/elf32-hppa.c for DT_INIT,DT_FINI, and making some small changes to glibc. H.J. Lu has already made the necessary framework changes, and all we need to do is something like #define DL_FUNCTION_ADDRESS(map, addr) _dl_start_address (map, addr) #define DL_DT_INIT_ADDRESS(map, addr) \ ((addr) & 2 ? (addr) : DL_FUNCTION_ADDRESS (map, addr)) with similar defines for DT_FINI. The test for (addr) & 2 is the fairly innocuous fudge to support old binaries. Another glibc issue (which is why I'm sending this back to the list) is that there has been quite some discussion on the binutils list over the use of the EI_OSABI field. The conclusion being that it isn't really correct to use this field to discern the intendend execution platform. It's purpose is really to tell ELF tools that a file contains fields and values that need to be interpreted in a non-standard way. Since both elf32-hppa and elf64-hppa follow the standards, I'm inclined to think that the gnu tools should set EI_OSABI to zero for both HPUX and Linux targets. Instead the .note.ABI-tag section should be examined to determine the target, which sadly isn't set correctly at the moment. :-( Alan Modra -- Linuxcare. Support for the Revolution. From bame@riverrock.org Mon, 20 Nov 2000 21:02:40 -0700 Date: Mon, 20 Nov 2000 21:02:40 -0700 From: bame@riverrock.org bame@riverrock.org Subject: [parisc-linux] 712 ISL and palo = palo wouldn't accept any ps/2 keyboard input. = Don't know if this is a palo or PDC bug. = Any ideas? PALO bug. I didn't test the PS/2 case but I think I fixed it. -P From alan@linuxcare.com.au Tue, 21 Nov 2000 15:38:57 +1100 (EST) Date: Tue, 21 Nov 2000 15:38:57 +1100 (EST) From: Alan Modra alan@linuxcare.com.au Subject: A DT_INIT/DT_FINI glibc patch. On Tue, 21 Nov 2000, I wrote: > Instead the .note.ABI-tag section should be examined to determine the > target, which sadly isn't set correctly at the moment. :-( Actually, it is set correctly. A comment in csu/abi-note.S was wrong. -- Linuxcare. Support for the Revolution. From jsm@udlkern.fc.hp.com Mon, 20 Nov 2000 22:47:41 -0700 (MST) Date: Mon, 20 Nov 2000 22:47:41 -0700 (MST) From: John Marvin jsm@udlkern.fc.hp.com Subject: [parisc-linux] Use of the EI_OSABI field > Another glibc issue (which is why I'm sending this back to the list) is > that there has been quite some discussion on the binutils list over the > use of the EI_OSABI field. The conclusion being that it isn't really > correct to use this field to discern the intendend execution platform. > It's purpose is really to tell ELF tools that a file contains fields and > values that need to be interpreted in a non-standard way. Since both > elf32-hppa and elf64-hppa follow the standards, I'm inclined to think that > the gnu tools should set EI_OSABI to zero for both HPUX and Linux targets. I don't read the binutils mailing list, so I checked the archive. In my opinion I didn't see a discussion, I saw H.J. Lu repeatedly asserting this "fact". He may or may not be correct about original intention, but the implementation so far has been that EI_OSABI is used to tell what the target platform is. That is what FreeBSD is doing, that is what HP-UX is doing, and that is what the IA-64 Unix System V Application Binary Interface specifies: http://developer.intel.com/design/IA-64/Downloads/24537002.pdf Note that the second paragraph in section 1.1 of that specification includes the following: This document is the result of consensus among operating system vendors intending to provide UNIX and UNIX workalike operating systems on the IA-64 architecture. The vendors participating in this effort include Intel, Sun Microsystems, SCO, IBM, SGI, Cygnus Solutions, VA Linux Systems, HP, and Compaq. So, If the specification is wrong according to H.J. Lu, why did both Cygnus and VA Linux Systems not object to this: Section 4.1.1.4 Operating System Identification The e_ident[EI_OSABI] value identifies the operating system and ABI to which the object is targeted, as listed in Table 4-1. Table 4-1 lists the various ELFOSABI_* fields, e.g. ELFOSABI_HPUX, ELFOSABI_NETBSD, ELFOSABI_LINUX, etc. Note also, that the current mechanism for us to be able to differentiate elf executables in the Linux kernel is the machine dependent elf_check_arch() macro, whose only argument is a pointer to a elf32_hdr or elf64_hdr. I think it would be ugly to try to get the .note.ABI-tag section first for every exec of a new binary in order to determine what the target ABI is. In my opinion, unless H.J. Lu can get the IA-64 ABI changed, it is too late to assert his view of what that field was supposed to be. Please leave the EI_OSABI field set to ELFOSABI_LINUX until a better consensus on this issue is reached. John Marvin jsm@fc.hp.com From alan@linuxcare.com.au Tue, 21 Nov 2000 18:05:36 +1100 (EST) Date: Tue, 21 Nov 2000 18:05:36 +1100 (EST) From: Alan Modra alan@linuxcare.com.au Subject: [parisc-linux] signal handling problems (32 bit kernel) On Mon, 20 Nov 2000, Richard Hirst wrote: > #warning XXX FIXME probably bogus -PB > /* I think this is bogus -- it'll cause the first instn of the > * signal handler to be executed twice! Better might be to Definitely bogus, as with quite a lot of iaoq manipulation in signal.c > I've fixed that by setting iaoq[1] = iaoq[0]+4. Is that OK, or Sounds like the right thing to do. I reckon everywhere ioaq is fudged from/to r31 should have this sort of mapping. ie. it should be regs->gr[31] = regs->iaoq[0]; in sys_rt_sigreturn, and err |= __put_user(regs->gr[31], &sc->sc_iaoq[0]); err |= __put_user(regs->gr[31] + 4, &sc->sc_iaoq[1]); in setup_sigcontext, and so on. I'm guessing the origial author of this code didn't know which of iaoq[0] and ioaq[1] was ioaq_front. :) > and then in another terminal do 'kill -USR1 '. The program > either goes 'Wah!', gives a SEGV, or works. That seems to be because > %r1 is corrupted while processing the signal. The signal handler ends > with a syscall (rt_sigreturn_wrapper), and %r1, at least, is not saved > and restored over the syscall. %r31 also appears to get corrupted, as > it is used in the final branch of the syscall return. I don't really understand what is going on here, but it seems wrong to me that setup_rt_frame should be touching regs->iaoq at all when in_syscall. Hmm, and in that case why all the other gr[31] to/from ioaq[] fudgery? Alan -- Linuxcare. Support for the Revolution. From rhirst@linuxcare.com Tue, 21 Nov 2000 09:34:42 +0000 Date: Tue, 21 Nov 2000 09:34:42 +0000 From: Richard Hirst rhirst@linuxcare.com Subject: [parisc-linux] signal handling problems (32 bit kernel) On Tue, Nov 21, 2000 at 06:05:36PM +1100, Alan Modra wrote: > On Mon, 20 Nov 2000, Richard Hirst wrote: > > > #warning XXX FIXME probably bogus -PB > > /* I think this is bogus -- it'll cause the first instn of the > > * signal handler to be executed twice! Better might be to > > Definitely bogus, as with quite a lot of iaoq manipulation in signal.c As another example, if a process gets a signal as it is about to execute the instr in the delay slot of a branch, it forgets that it was supposed to be branching on return from the signal handler. Try compiling the following and sending it a SIGUSR1: #include #include #include #include void sig_handler(int sig) { } int main() { struct sigaction act; int i = 1; memset(&act, 0, sizeof(act)); act.sa_handler = sig_handler; sigaction(SIGUSR1, &act, NULL); printf("I am %d\n", getpid()); while (i++) ; printf("Escaped, i=%d!\n", i); return 0; } Oh, you have to run it with "LD_BIND_NOW=1 " to avoid one of the other problems. Time to try and work out what signal.c is really trying to do, I guess. Richard From alan@linuxcare.com.au Tue, 21 Nov 2000 22:26:14 +1100 (EST) Date: Tue, 21 Nov 2000 22:26:14 +1100 (EST) From: Alan Modra alan@linuxcare.com.au Subject: [parisc-linux] signal handling problems (32 bit kernel) On Tue, 21 Nov 2000, Richard Hirst wrote: > Time to try and work out what signal.c is really trying to do, I guess. Maybe you should start by considering all the possible states a task can be in when a signal is delivered, in regards to saved registers and stack layout. It would be a _very_ good idea to formalize this once you've sorted it out by splitting up struct pt_regs appropriately. ie. as other architectures do, into struct pt_regs and struct switch_stack. Actually, parisc could go one further and have three structures, one corresponding to registers saved on syscall entry (new pt_regs), one corresponding to macro callee_save (switch_stack), and one corresponding more or less to macro save_specials. Quite a bit of work, but IMO well worth doing. Alan Modra -- Linuxcare. Support for the Revolution. From matthew@wil.cx Tue, 21 Nov 2000 11:34:32 +0000 Date: Tue, 21 Nov 2000 11:34:32 +0000 From: Matthew Wilcox matthew@wil.cx Subject: [parisc-linux] CVS linux Vs. -test10 On Mon, Nov 20, 2000 at 09:34:31AM -0800, Grant Grundler wrote: > Ok. What's the first step to getting arch/parisc* and include/asm-parisc* > into Linus's tree? Someone (probably me) sends him a patch. He told me at the Toronto show that he was quite happy to apply anything that only touched those two directories. (oh, and drivers/gsc wouldn't be a problem either). Can I just check that no-one wants to rename drivers/gsc again? :-) > I had dinner with Bdale Garbee last night and one of two things he made > clear was we need to unfork from debian and linus's tree in order to move > forward. All our CVS branches need to become obsolete or "local sandboxes" > of the respective upstream partners. Feeding kernel bits upstream will > bring a new level of visibility (and *HELP*) to the parisc-linux port. that's true. last time we discussed this several people were unhappy with the idea of sending our current work to Linus. Is anyone unhappy with doing this now? > I also find it odd that glibc is merged upstream *before* the kernel is. glibc is more portable :-) > The part you described above is the easy part - np. > I'm worried about labels and tracking how we "name" the releases. > Mang or other CVS ninja's care to comment? don't tag it. just commit it. tags are laid down at big events, not when you fix bugs or undo changes. -- Revolutions do not require corporate support. From jsm@udlkern.fc.hp.com Tue, 21 Nov 2000 06:11:29 -0700 (MST) Date: Tue, 21 Nov 2000 06:11:29 -0700 (MST) From: John Marvin jsm@udlkern.fc.hp.com Subject: CVS linux Vs. -test10 > > I had dinner with Bdale Garbee last night and one of two things he made > > clear was we need to unfork from debian and linus's tree in order to move > > forward. All our CVS branches need to become obsolete or "local sandboxes" > > of the respective upstream partners. Feeding kernel bits upstream will > > bring a new level of visibility (and *HELP*) to the parisc-linux port. > > that's true. last time we discussed this several people were unhappy > with the idea of sending our current work to Linus. Is anyone unhappy > with doing this now? > Are we suggesting that we populate include/asm-parisc* and arch/parisc* WITHOUT the machine independent changes in the rest of the tree? If that is the case, I guess I don't object, although I would want to make sure that Linus knew the state of the code, and that it would not work without a patch containing changes to the machine independent part, and that followup patches to these branches are likely to be huge. We should also add a README in arch/parisc that explains the above (and where to get patches, how to access CVS, etc.). We also need someone to set up an automatic nightly? patch generator. I certainly don't want to try to get the machine independent changes in yet, since we still have some major issues to fix/clean there, and I doubt Linus would want them at this time anyway. John Marvin jsm@fc.hp.com From rhirst@linuxcare.com Tue, 21 Nov 2000 16:54:42 +0000 Date: Tue, 21 Nov 2000 16:54:42 +0000 From: Richard Hirst rhirst@linuxcare.com Subject: [parisc-linux] signal handling problems (32 bit kernel) On Tue, Nov 21, 2000 at 06:05:36PM +1100, Alan Modra wrote: > > and then in another terminal do 'kill -USR1 '. The program > > either goes 'Wah!', gives a SEGV, or works. That seems to be because > > %r1 is corrupted while processing the signal. The signal handler ends > > with a syscall (rt_sigreturn_wrapper), and %r1, at least, is not saved > > and restored over the syscall. %r31 also appears to get corrupted, as > > it is used in the final branch of the syscall return. > > I don't really understand what is going on here, but it seems wrong to me > that setup_rt_frame should be touching regs->iaoq at all when in_syscall. Problem is that whenever a signal handler is invoked, it is followed by a sys_rt_sigreturn syscall (invoked via the trampoline code), before returning to original usercode. I can imagine that this might work if the process in question was blocked on a syscall, but not if it was suspended due to an interrupt. In either case the path back to the original user code is the syscall return path, and that obviously cannot put things back as they were if the process was interrupted. I think the answer is for syscall_do_signal to save enough in the pt_regs such that sys_rt_sigreturn_wrapper can return to userland via an RFI (like intr_restore, but remembering to trace the syscall exit if necessary) regardless of the process state when the signal occurred. Richard From taggart@carmen.fc.hp.com Tue, 21 Nov 2000 10:20:35 -0700 Date: Tue, 21 Nov 2000 10:20:35 -0700 From: Matt Taggart taggart@carmen.fc.hp.com Subject: [parisc-linux] kernel BUG at sched.c:692! I arrived this morning to discover both my B160 and my C3000 were printing the following as fast as they could, Scheduling in interrupt kernel BUG at sched.c:692! Looking at linux/kernel/sched.c here's the relevant section, 690 scheduling_in_interrupt: 691 printk("Scheduling in interrupt\n"); 692 BUG(); 693 return; scheduling_in_interrupt is called from line 516. Here's some context, 500 asmlinkage void schedule(void) 501 { 502 struct schedule_data * sched_data; 503 struct task_struct *prev, *next, *p; 504 struct list_head *tmp; 505 int this_cpu, c; 506 507 if (!current->active_mm) BUG(); 508 if (tq_scheduler) 509 goto handle_tq_scheduler; 510 tq_scheduler_back: 511 512 prev = current; 513 this_cpu = prev->processor; 514 515 if (in_interrupt()) 516 goto scheduling_in_interrupt; 517 518 release_kernel_lock(prev, this_cpu); I thought it was odd that both systems chose to freak out last night when I have never seen this problem on either of them. The B160 is running a slightly newer kernel and had been up for about 3 days as of last night. The C3K had been up for 4-5 days. When I left last night the B160 was doing a build although the it looks like the build died before this problem occurred. The C3K was idle. Any ideas? Thanks, -- Matt Taggart taggart@fc.hp.com From robert.reilly@gecapital.com Tue, 21 Nov 2000 18:26:41 GMT Date: Tue, 21 Nov 2000 18:26:41 GMT From: Robert Reilly robert.reilly@gecapital.com Subject: [parisc-linux] cd .5 Hi All, I have HP9000/d212 I was able to boot off the cdrom image no problem, however when I get the login prompt I am only able to type in two characters and the screen redraws itself and prompts me for a login. I am using a HP700 serial terminal on ttyS0.I briefly scanned the mailing list but did not find anything. Any help would be appreciated. --Robert Reilly GE Capital Card Service UNIX Administrator robert.reilly@gecapital.com From matthew@wil.cx Tue, 21 Nov 2000 17:38:57 +0000 Date: Tue, 21 Nov 2000 17:38:57 +0000 From: Matthew Wilcox matthew@wil.cx Subject: CVS linux Vs. -test10 On Tue, Nov 21, 2000 at 06:11:29AM -0700, John Marvin wrote: > Are we suggesting that we populate include/asm-parisc* and arch/parisc* > WITHOUT the machine independent changes in the rest of the tree? Yes. > If that is the case, I guess I don't object, although I would want > to make sure that Linus knew the state of the code, and that it would > not work without a patch containing changes to the machine independent > part, and that followup patches to these branches are likely to be > huge. We should also add a README in arch/parisc that explains the > above (and where to get patches, how to access CVS, etc.). We also > need someone to set up an automatic nightly? patch generator. Agreed. The patch generation is not a big deal to arrange. > I certainly don't want to try to get the machine independent changes in > yet, since we still have some major issues to fix/clean there, and I doubt > Linus would want them at this time anyway. Certainly none of the stack direction changes. Some of the MI stuff is arguably stuff we could put in. -- Revolutions do not require corporate support. From Pirvulescu_Alexandru@telemobil.ro Tue, 21 Nov 2000 20:49:57 +0200 Date: Tue, 21 Nov 2000 20:49:57 +0200 From: Alexandru Pirvulescu Pirvulescu_Alexandru@telemobil.ro Subject: [parisc-linux] case LEDs Hello Is there any possibility to activate the case LEDs? I mean the heartbeat and the network activity I have a A180 machine Alex From grundler@cup.hp.com Tue, 21 Nov 2000 10:55:06 -0800 Date: Tue, 21 Nov 2000 10:55:06 -0800 From: Grant Grundler grundler@cup.hp.com Subject: [parisc-linux] case LEDs "Alexandru Pirvulescu" wrote: > Hello > > Is there any possibility to activate the case LEDs? I mean the heartbeat and > the network activity. I have a A180 machine. Yes. I was already asked this weekend to dig up technical info on LED and soft power control. I guess this is my reminder to do that. :^) grant From grundler@cup.hp.com Tue, 21 Nov 2000 10:59:24 -0800 Date: Tue, 21 Nov 2000 10:59:24 -0800 From: Grant Grundler grundler@cup.hp.com Subject: [parisc-linux] cd .5 Robert Reilly wrote: > Hi All, > I have HP9000/d212 I was able to boot off the cdrom image no problem, > however when I get the login prompt I am only able to type in two > characters and the screen redraws itself and prompts me for a login. I am > using a HP700 serial terminal on ttyS0. I briefly scanned the mailing list > but did not find anything. Any help would be appreciated. Robert, I would suspent the terminal isn't configured correctly for the serial connection. Is it set up for 9600 baud, 8 data bits, no parity, 1 stop bit? I'm pretty sure you have the baud rate correct since you get a login prompt. I'm not sure all the other things must be correct to get that far. I'm not familiar with "HP700 serial terminal". But all the HP terminals I've worked with in the past also support vt100 emulation mode. You probably want to set that too. grant Grant Grundler Unix Systems Enablement Lab +1.408.447.7253 From kailasr@webcash.com Tue, 21 Nov 2000 12:30:12 -0800 Date: Tue, 21 Nov 2000 12:30:12 -0800 From: Kailashnath V Rampure kailasr@webcash.com Subject: [parisc-linux] Apache package. Hi Paul, I have installed Apache + mod_ssl + mod_perl on HP A Class server. I need help on to change the server looking fort bootpd server and put the IP address on the system. Also where can I find the ftp client for linux . Regards Kalas At 04:59 PM 11/15/00 -0700, Paul Bame wrote: >= I tried to build apache_1.3.12 on HP a class server. But I have error. I >= have tried to check the site >= ftp://ftp.debian.org/debian/dists/unstable/main/binary-hppa/ >= I could not find one. I found some apache-doc etc. > >We are still working on some kernel features which are required to >support Apache (system 5 shared memory). > > -P From grundler@cup.hp.com Tue, 21 Nov 2000 13:24:31 -0800 Date: Tue, 21 Nov 2000 13:24:31 -0800 From: Grant Grundler grundler@cup.hp.com Subject: [parisc-linux] CVS linux Vs. -test10 Matthew Wilcox wrote: ... > Someone (probably me) sends him a patch. He told me at the Toronto > show that he was quite happy to apply anything that only touched those > two directories. (oh, and drivers/gsc wouldn't be a problem either). > Can I just check that no-one wants to rename drivers/gsc again? :-) Hi Mathew, I don't and it's a good question. I would like a few files moved: arch/parisc/kernel/ccio-dma.c -> drivers/gsc/ccio-dma.c arch/parisc/kernel/ccio-rm-dma.c -> drivers/gsc/ccio-rm-dma.c ccio will *always* be associated with a GSC bus since that's the secondary bus. And ccio supports devices below dino.c which already lives in drivers/gsc. arch/parisc/kernel/lba_pci.c -> drivers/ropes/lba_pci.c arch/parisc/kernel/sba_iommu.c -> drivers/ropes/sba_iommu.c arch/parisc/kernel/iosapic.c -> drivers/ropes/iosapic.c lba/sba code is equivalent to dino/ccio code for another set of platforms. And long term, I'm certain iosapic.c does not belong under arch/parisc. I can do this move if there are no major objections. Any reason why we couldn't do these moves *after* you submit a patch? FWIW, here are issues I see with merging IA64 iosapic code with mine: o iosapic "discovery" (I invented register_iosapic() interface for parisc) o parisc PDC calls (initialization) o interrupt policy decisions (eg EOI generation and picking a CPU) o I don't have time to do it in the near future. Folks working on IA64 stuff inside HP need to think about: (a) if they want to do the merge any time soon (b) which iosapic.c they want to start with (c) where the final version should live thanks, grant Grant Grundler Unix Systems Enablement Lab +1.408.447.7253 From pjlahaie@linuxcare.com Tue, 21 Nov 2000 16:41:48 -0500 Date: Tue, 21 Nov 2000 16:41:48 -0500 From: Paul J.Y. Lahaie pjlahaie@linuxcare.com Subject: [parisc-linux] Fun build problems --PW0Eas8rCkcu1VkF Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hello everyone, Over the last couple of days, I've been trying to get the debian boot-floppies building (I know some changes will be necessary) and as it stands now, several packages are missing. In the process of trying to compile/install these packages, I've run into some difficulties. Here are some of them: apt -- Package on pehc and .iso do not work. Missing lots of helper apps. Seeing as apt was broken, I decided to download the woody version of apt so I can get a newer version and hopefully skip some steps in building the above packages. gcc 2.96 and apt-0.3.19 don't get along, so I tried picking it up from cvs (supposed to have been fixed). Follow the directions on cvs.debian.org $ cvs -d :pserver:anonymous@cvs.debian.org:/cvs/APT login (Logging in to anonymous@cvs.debian.org) CVS password:=20 cvs login: authorization failed: server cvs.debian.org rejected access Anyone know if there are other instructions other than what cvs.debian.org says? If so, feel free to email me rsync -- ldd crashes on dpkg-shlibdepends stage Can I just manually put the required dependancies in? autoconf -- installinfo spins When installing the autoconf package (to compile dpkg) installinfo spins. And after several minutes still doesn't return. It's taking up 100% cpu at the time. If I abort this, autoconf seems to be installed but cannot generate the dpkg configure properly, some macros are missing AM_CONDITIONAL(HAVE_CPLUSPLUS, test "$CXX" !=3D "") Is in the ./configure script. info -- Reinstall spins If I try to reinstall info, it spins on the uninstall. 100% cpu. If anyone has any solutions for any of the above problems, I am all ears (eyes?). - Paul --PW0Eas8rCkcu1VkF Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.4 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE6Guwc8ggPQthPCzcRAgkGAJ9TzClXOg009RWO/v09ONBNnxJcbgCfcWcX gj26osR06BqyJ0O+/Q83csk= =YHRW -----END PGP SIGNATURE----- --PW0Eas8rCkcu1VkF-- From alan@linuxcare.com.au Wed, 22 Nov 2000 09:50:05 +1100 (EST) Date: Wed, 22 Nov 2000 09:50:05 +1100 (EST) From: Alan Modra alan@linuxcare.com.au Subject: [parisc-linux] Use of the EI_OSABI field cc to binutils because John makes some salient points. On Mon, 20 Nov 2000, John Marvin wrote: > > Another glibc issue (which is why I'm sending this back to the list) is > > that there has been quite some discussion on the binutils list over the > > use of the EI_OSABI field. The conclusion being that it isn't really > > correct to use this field to discern the intendend execution platform. > > It's purpose is really to tell ELF tools that a file contains fields and > > values that need to be interpreted in a non-standard way. Since both > > elf32-hppa and elf64-hppa follow the standards, I'm inclined to think that > > the gnu tools should set EI_OSABI to zero for both HPUX and Linux targets. > > I don't read the binutils mailing list, so I checked the archive. In my > opinion I didn't see a discussion, I saw H.J. Lu repeatedly asserting > this "fact". He may or may not be correct about original intention, but > the implementation so far has been that EI_OSABI is used to tell what the > target platform is. That is what FreeBSD is doing, that is what HP-UX is > doing, and that is what the IA-64 Unix System V Application Binary > Interface specifies: > > http://developer.intel.com/design/IA-64/Downloads/24537002.pdf > > Note that the second paragraph in section 1.1 of that specification > includes the following: > > This document is the result of consensus among operating system > vendors intending to provide UNIX and UNIX workalike operating > systems on the IA-64 architecture. The vendors participating in > this effort include Intel, Sun Microsystems, SCO, IBM, SGI, > Cygnus Solutions, VA Linux Systems, HP, and Compaq. > > So, If the specification is wrong according to H.J. Lu, why did both > Cygnus and VA Linux Systems not object to this: > > Section 4.1.1.4 Operating System Identification > > The e_ident[EI_OSABI] value identifies the operating system and > ABI to which the object is targeted, as listed in Table 4-1. > > Table 4-1 lists the various ELFOSABI_* fields, e.g. ELFOSABI_HPUX, > ELFOSABI_NETBSD, ELFOSABI_LINUX, etc. > > Note also, that the current mechanism for us to be able to differentiate > elf executables in the Linux kernel is the machine dependent > elf_check_arch() macro, whose only argument is a pointer to a > elf32_hdr or elf64_hdr. I think it would be ugly to try to get the > .note.ABI-tag section first for every exec of a new binary in order > to determine what the target ABI is. > > In my opinion, unless H.J. Lu can get the IA-64 ABI changed, it is too > late to assert his view of what that field was supposed to be. Please > leave the EI_OSABI field set to ELFOSABI_LINUX until a better consensus > on this issue is reached. > > John Marvin > jsm@fc.hp.com I'm happy enough to leave things as they are in puffin CVS, but these changes haven't been merged back to sourceware yet, partly because I had some doubts myself as to whether setting EI_OSABI was correct. H.J. Lu wasn't the only one arguing that EI_OSABI should be left at zero; Ulrich Drepper also was quite vehement against changing sourceware FreeBSD binutils. BTW, it's not too hard to check .note.ABI-tag. The linker arranges for a PT_NOTE program header entry to point to it, and the section itself is virtually guaranteed to be read in with the header as it's placed right after the header along with .interp. Alan Modra -- Linuxcare. Support for the Revolution. From drepper@redhat.com 21 Nov 2000 15:27:19 -0800 Date: 21 Nov 2000 15:27:19 -0800 From: Ulrich Drepper drepper@redhat.com Subject: [parisc-linux] Use of the EI_OSABI field Alan Modra writes: > Ulrich Drepper also was quite vehement against changing sourceware > FreeBSD binutils. I've never said anything about any *BSD, why should I? The *BSD people wanted to change the Linux binutils. Anyway, the ABI value is zero unless you implement ELF extensions. -- ---------------. ,-. 1325 Chesapeake Terrace Ulrich Drepper \ ,-------------------' \ Sunnyvale, CA 94089 USA Red Hat `--' drepper at redhat.com `------------------------ From alan@linuxcare.com.au Wed, 22 Nov 2000 11:13:29 +1100 (EST) Date: Wed, 22 Nov 2000 11:13:29 +1100 (EST) From: Alan Modra alan@linuxcare.com.au Subject: [parisc-linux] Use of the EI_OSABI field On 21 Nov 2000, Ulrich Drepper wrote: > Alan Modra writes: > > > Ulrich Drepper also was quite vehement against changing sourceware > > FreeBSD binutils. > > I've never said anything about any *BSD, why should I? The *BSD > people wanted to change the Linux binutils. Sorry, I stated that badly. > Anyway, the ABI value is zero unless you implement ELF extensions. Exactly what is an "ELF extension"? Anything outside gABI or "gABI + psABI"? Handly the latter, as it seems to me that a processor specific ABI can specify extensions. There's also the awkward possibility that a psABI may specify an extension that is later incorporated into a new revision of the gABI (eg. hpux and DT_INIT_ARRAY) Does that mean that if a new revision of the gABI completely incorporates all previous extensions, that EI_OSABI should become zero? Yes, I'm arguing that "No ELF extensions => EI_OSABI == 0" is not necessarily true, but I'm _not_ arguing that changing x86 Linux binutils is wise. Historical usage is important. If we were to change x86 Linux binutils to set EI_OSABI, then that can only be after a considerable period of time to allow code such as glibc to accept a new branding. Alan Modra -- Linuxcare. Support for the Revolution. From drepper@redhat.com 21 Nov 2000 16:31:39 -0800 Date: 21 Nov 2000 16:31:39 -0800 From: Ulrich Drepper drepper@redhat.com Subject: [parisc-linux] Use of the EI_OSABI field Alan Modra writes: > Exactly what is an "ELF extension"? Anything outside gABI or > "gABI + psABI"? Anything beyond the psABI that cannot be handled by the rules in the gABI. -- ---------------. ,-. 1325 Chesapeake Terrace Ulrich Drepper \ ,-------------------' \ Sunnyvale, CA 94089 USA Red Hat `--' drepper at redhat.com `------------------------ From hjl@valinux.com Tue, 21 Nov 2000 16:53:27 -0800 Date: Tue, 21 Nov 2000 16:53:27 -0800 From: H . J . Lu hjl@valinux.com Subject: [parisc-linux] Use of the EI_OSABI field On Wed, Nov 22, 2000 at 11:13:29AM +1100, Alan Modra wrote: > > > Anyway, the ABI value is zero unless you implement ELF extensions. > > Exactly what is an "ELF extension"? Anything outside gABI or ELF extension is something whose interpretation is not documented in neither gABI nor psABI. HP's old ELF is a good example since it didn't implement DT_INIT/DT_FINI, but added DT_INIT_ARRARY/DT_FINI_ARRAY. A normal ELF tool will have a hard time to interpret those fields and their values. H.J. From matthew@wil.cx Wed, 22 Nov 2000 00:53:09 +0000 Date: Wed, 22 Nov 2000 00:53:09 +0000 From: Matthew Wilcox matthew@wil.cx Subject: [parisc-linux] CVS linux Vs. -test10 On Tue, Nov 21, 2000 at 01:24:31PM -0800, Grant Grundler wrote: > I would like a few files moved: > > arch/parisc/kernel/ccio-dma.c -> drivers/gsc/ccio-dma.c > arch/parisc/kernel/ccio-rm-dma.c -> drivers/gsc/ccio-rm-dma.c > arch/parisc/kernel/lba_pci.c -> drivers/ropes/lba_pci.c > arch/parisc/kernel/sba_iommu.c -> drivers/ropes/sba_iommu.c > arch/parisc/kernel/iosapic.c -> drivers/ropes/iosapic.c > Any reason why we couldn't do these moves *after* you submit a patch? Better to get our house in order before we patchbomb Linus, I think. Renames are hard enough in CVS; renames in diff -u format are a real stinker :-) -- Revolutions do not require corporate support. From adevries@linuxcare.com Tue, 21 Nov 2000 21:27:51 -0500 Date: Tue, 21 Nov 2000 21:27:51 -0500 From: Alex deVries adevries@linuxcare.com Subject: [parisc-linux] case LEDs Grant Grundler wrote: > Yes. > I was already asked this weekend to dig up technical info on LED > and soft power control. I guess this is my reminder to do that. :^) Isn't there a PDC call (pdc_chassis?) to do this? Or is the heartbeat LED done by hardware? - Alex -- Alex deVries, Principal Solutions Architect, The Puffins at Linuxcare 613.562.2759 tel alex@linuxcare.com, http://www.linuxcare.com/ Linuxcare, Support for the revolution. From randolph@tausq.org Tue, 21 Nov 2000 18:50:24 -0700 Date: Tue, 21 Nov 2000 18:50:24 -0700 From: Randolph Chung randolph@tausq.org Subject: [parisc-linux] Fun build problems --9zSXsLTf0vkW971A Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable > Seeing as apt was broken, I decided to download the woody version of apt = so > I can get a newer version and hopefully skip some steps in building the > above packages. gcc 2.96 and apt-0.3.19 don't get along, so I tried pick= ing > it up from cvs (supposed to have been fixed). Follow the directions on > cvs.debian.org >=20 > $ cvs -d :pserver:anonymous@cvs.debian.org:/cvs/APT login > (Logging in to anonymous@cvs.debian.org) > CVS password:=20 > cvs login: authorization failed: server cvs.debian.org rejected access Try: cvs -d:pserver:anonymous@cvs.debian.org:/cvs/deity login (empty password) It should work. if not let me know and i can mail you a tarball. You probably want to get the aliencode branch, which has hppa patches. Let me know if you run into any problems. > rsync -- ldd crashes on dpkg-shlibdepends stage > Can I just manually put the required dependancies in? Yes, or pick up the dpkg-architecture and dpkg-shlibdeps scripts from http://puffin.external.hp.com/~tausq/, or wait for the next version of dpkg to get built for hppa (it doesn't use ldd anymore) > autoconf -- installinfo spins >=20 > When installing the autoconf package (to compile dpkg) installinfo spins. > And after several minutes still doesn't return. It's taking up 100% cpu > at the time. hmmm.. didn't see this. I had built a slightly older version of dpkg successfully. randolph (tausq@debian.org) --=20 @..@ http://www.TauSq.org/ (----) ( >__< ) ^^ ~~ ^^ --9zSXsLTf0vkW971A Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.1 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE6GyZgULspdC1Zp9IRAozyAKC/Df1fexltMjFlcwpeYlD+IIWEigCgiGyT YKOjLA0BQzMo7qOj8jC1BTI= =whh1 -----END PGP SIGNATURE----- --9zSXsLTf0vkW971A-- From hjl@valinux.com Tue, 21 Nov 2000 19:11:29 -0800 Date: Tue, 21 Nov 2000 19:11:29 -0800 From: H . J . Lu hjl@valinux.com Subject: [parisc-linux] Use of the EI_OSABI field On Wed, Nov 22, 2000 at 02:03:07PM +1100, Alan Modra wrote: > On Tue, 21 Nov 2000, H . J . Lu wrote: > > > On Wed, Nov 22, 2000 at 11:13:29AM +1100, Alan Modra wrote: > > > > > > > Anyway, the ABI value is zero unless you implement ELF extensions. > > > > > > Exactly what is an "ELF extension"? Anything outside gABI or > > > > ELF extension is something whose interpretation is not documented in > > neither gABI nor psABI. HP's old ELF is a good example since it didn't > > implement DT_INIT/DT_FINI, but added DT_INIT_ARRARY/DT_FINI_ARRAY. A > > normal ELF tool will have a hard time to interpret those fields and > > their values. > > Neither you nor Ulrich have responded to John's point that the IA64 psABI > states > "The e_ident[EI_OSABI] value identifies the operating system and ABI to > which the object is targeted" > > Granted, this is only in a processor specific ABI, but it does flatly > contradict your assertions that the purpose of EI_OSABI is to flag the > presense of ELF extensions. > When I was at the IA64 ABI meeting yesterday, we were looking at the EI_OSABI issue. Everyone at the IA64 ABI meeting agreed that what Ulrich and I had said was the correct understanding. "The e_ident[EI_OSABI] value identifies the operating system and ABI to which the object is targeted" just means if the e_ident[EI_OSABI] value is not ELFOSABI_NONE, you have to look somewhere else in addition to gABI and IA64 psABI to interpret the ELF fields/values specific to that OS. Otherwise, gABI and IA64 psABI are sufficient. -- H.J. Lu (hjl@valinux.com) From drepper@redhat.com 21 Nov 2000 19:18:21 -0800 Date: 21 Nov 2000 19:18:21 -0800 From: Ulrich Drepper drepper@redhat.com Subject: [parisc-linux] Use of the EI_OSABI field Alan Modra writes: > "The e_ident[EI_OSABI] value identifies the operating system and ABI to > which the object is targeted" > > Granted, this is only in a processor specific ABI, but it does flatly > contradict your assertions that the purpose of EI_OSABI is to flag the > presense of ELF extensions. The meaning of the field changed over time. Or better said, some people initially understood it differently. -- ---------------. ,-. 1325 Chesapeake Terrace Ulrich Drepper \ ,-------------------' \ Sunnyvale, CA 94089 USA Red Hat `--' drepper at redhat.com `------------------------ From alan@linuxcare.com.au Wed, 22 Nov 2000 14:03:07 +1100 (EST) Date: Wed, 22 Nov 2000 14:03:07 +1100 (EST) From: Alan Modra alan@linuxcare.com.au Subject: [parisc-linux] Use of the EI_OSABI field On Tue, 21 Nov 2000, H . J . Lu wrote: > On Wed, Nov 22, 2000 at 11:13:29AM +1100, Alan Modra wrote: > > > > > Anyway, the ABI value is zero unless you implement ELF extensions. > > > > Exactly what is an "ELF extension"? Anything outside gABI or > > ELF extension is something whose interpretation is not documented in > neither gABI nor psABI. HP's old ELF is a good example since it didn't > implement DT_INIT/DT_FINI, but added DT_INIT_ARRARY/DT_FINI_ARRAY. A > normal ELF tool will have a hard time to interpret those fields and > their values. Neither you nor Ulrich have responded to John's point that the IA64 psABI states "The e_ident[EI_OSABI] value identifies the operating system and ABI to which the object is targeted" Granted, this is only in a processor specific ABI, but it does flatly contradict your assertions that the purpose of EI_OSABI is to flag the presense of ELF extensions. Alan Modra -- Linuxcare. Support for the Revolution. From rbradetich@uswest.net Tue, 21 Nov 2000 22:54:11 -0800 Date: Tue, 21 Nov 2000 22:54:11 -0800 From: Ryan Bradetich rbradetich@uswest.net Subject: [parisc-linux] CVS linux Vs. -test10 Grant Grundler wrote: > Matthew Wilcox wrote: > ... > > Someone (probably me) sends him a patch. He told me at the Toronto > > show that he was quite happy to apply anything that only touched those > > two directories. (oh, and drivers/gsc wouldn't be a problem either). > > Can I just check that no-one wants to rename drivers/gsc again? :-) > > Hi Mathew, > I don't and it's a good question. > I would like a few files moved: > > arch/parisc/kernel/ccio-dma.c -> drivers/gsc/ccio-dma.c > arch/parisc/kernel/ccio-rm-dma.c -> drivers/gsc/ccio-rm-dma.c Grant, Do you really want to merget the ccio-rm-dma.c file into Linus's tree? It is just a reference file used to construct the real ccio-dma.c file ... I don't believe it is referenced anywhere. I'll double check this in the morning. - Ryan > ccio will *always* be associated with a GSC bus since that's > the secondary bus. And ccio supports devices below dino.c which > already lives in drivers/gsc. > > arch/parisc/kernel/lba_pci.c -> drivers/ropes/lba_pci.c > arch/parisc/kernel/sba_iommu.c -> drivers/ropes/sba_iommu.c > arch/parisc/kernel/iosapic.c -> drivers/ropes/iosapic.c > > lba/sba code is equivalent to dino/ccio code for another set > of platforms. And long term, I'm certain iosapic.c does not > belong under arch/parisc. I can do this move if there are no > major objections. > > Any reason why we couldn't do these moves *after* you submit a patch? > > FWIW, here are issues I see with merging IA64 iosapic code with mine: > o iosapic "discovery" (I invented register_iosapic() interface for parisc) > o parisc PDC calls (initialization) > o interrupt policy decisions (eg EOI generation and picking a CPU) > o I don't have time to do it in the near future. > > Folks working on IA64 stuff inside HP need to think about: > (a) if they want to do the merge any time soon > (b) which iosapic.c they want to start with > (c) where the final version should live > > thanks, > grant > > Grant Grundler > Unix Systems Enablement Lab > +1.408.447.7253 > > --------------------------------------------------------------------------- > To unsubscribe: send e-mail to parisc-linux-request@thepuffingroup.com with > `unsubscribe' as the subject. From jsm@udlkern.fc.hp.com Tue, 21 Nov 2000 23:50:03 -0700 (MST) Date: Tue, 21 Nov 2000 23:50:03 -0700 (MST) From: John Marvin jsm@udlkern.fc.hp.com Subject: [parisc-linux] CVS linux Vs. -test10 > Better to get our house in order before we patchbomb Linus, I think. > Renames are hard enough in CVS; renames in diff -u format are a real > stinker :-) In that case, we need to do some cleanup first. I've been lobbying for the removal of the almost empty arch/parisc/real directory, and its few remaining valid files moved to the kernel directory. There are also a fair number of dead files. Every file that is not currently involved in the build should be removed, unless a good case for it remaining can be made. If the reason to keep it is not a long term reason, then that file should not be sent to Linus (It sounds like it is a lot easier to add files rather than remove/rename them). If there are any files that are currently in use, but which we know will eventually be removed, perhaps we should consider what to do with that file (although I don't know of any files in this category at the moment). John Marvin jsm@fc.hp.com From grundler@cup.hp.com Tue, 21 Nov 2000 23:18:16 -0800 Date: Tue, 21 Nov 2000 23:18:16 -0800 From: Grant Grundler grundler@cup.hp.com Subject: [parisc-linux] CVS linux Vs. -test10 Ryan Bradetich wrote: > Do you really want to merget the ccio-rm-dma.c file into Linus's tree? > It is just a reference file used to construct the real ccio-dma.c file ... I > don't believe it is referenced anywhere. Hi Ryan, Yes I do. It is supposed to work for ccio+PCX-W platforms (eg C360). Keeping it arround will document the pro/con's of that approach and give folks who have time (and the right machine) something to experiment with instead of writing it from scratch. If someone finds an application it's good for (short transactions with low latency requirements perhaps), it's worth having around. It's not referenced because I didn't add a CONFIG_CCIO_RM_IOMMU flag or ccio_rm_init() call to drivers/gsc/gsc.c:gsc_init(). You are welcome add this CONFIG flag by hacking arch/parisc/config.in and defconfig. If you do, please add rules which only allow one or the other CONFIG_CCIO* option to be enabled. thanks, grant Grant Grundler Unix Systems Enablement Lab +1.408.447.7253 From Pirvulescu_Alexandru@telemobil.ro Wed, 22 Nov 2000 09:36:58 +0200 Date: Wed, 22 Nov 2000 09:36:58 +0200 From: Alexandru Pirvulescu Pirvulescu_Alexandru@telemobil.ro Subject: [parisc-linux] case LEDs I think that the heartbeat LED is software because it starts with the kernel boot and if the kernel stops the LED stops blinking too. Is better to implement a software monitoring tool because you have to watch the software for hanging. Alex PS. There is a function in the kernel source in linux/arch/parisc/kernel/process.c named machine_heartbeat(). Any connection with the heartbeat from the chassis? ----- Original Message ----- From: "Alex deVries" To: "Grant Grundler" Cc: "Alexandru Pirvulescu" ; Sent: Wednesday, November 22, 2000 4:27 AM Subject: Re: [parisc-linux] case LEDs > Grant Grundler wrote: > > Yes. > > I was already asked this weekend to dig up technical info on LED > > and soft power control. I guess this is my reminder to do that. :^) > > Isn't there a PDC call (pdc_chassis?) to do this? Or is the heartbeat > LED done by hardware? > > - Alex > > -- > Alex deVries, Principal Solutions Architect, The Puffins at Linuxcare > 613.562.2759 tel > alex@linuxcare.com, http://www.linuxcare.com/ > Linuxcare, Support for the revolution. > > From bvalkema@knowhowww.nl Wed, 22 Nov 2000 06:32:51 +0100 Date: Wed, 22 Nov 2000 06:32:51 +0100 From: Bas Valkema bvalkema@knowhowww.nl Subject: [parisc-linux] case LEDs Alex deVries wrote: > Grant Grundler wrote: > > Yes. > > I was already asked this weekend to dig up technical info on LED > > and soft power control. I guess this is my reminder to do that. :^) > > Isn't there a PDC call (pdc_chassis?) to do this? Or is the heartbeat > LED done by hardware? > > - Alex A couple of months ago, I asked the same question, got answer to look in the mkLinux sources. I did, and I think it was a register (outb(0xblabla);). Wrote a driver (and for WAX, got a Intel Flash 32 EISA running), can't release it now, because of some copyright issues... Bas From grundler@cup.hp.com Tue, 21 Nov 2000 23:56:35 -0800 Date: Tue, 21 Nov 2000 23:56:35 -0800 From: Grant Grundler grundler@cup.hp.com Subject: [parisc-linux] CVS linux Vs. -test10 John Marvin wrote: > In that case, we need to do some cleanup first. John, I want a task list which leads us to a submital to linus. That's why I listed the specific files I wanted moved. Can you come up with (or ask someone else to come up) with a list of files which meet your criteria? All of your criteria sounds reasonable to me. But I don't have a feel of which files meet your criteria. If someone makes the task list, I'm happy to help with items and verify the result works. thanks, grant From jsm@udlkern.fc.hp.com Wed, 22 Nov 2000 01:11:57 -0700 (MST) Date: Wed, 22 Nov 2000 01:11:57 -0700 (MST) From: John Marvin jsm@udlkern.fc.hp.com Subject: [parisc-linux] CVS linux Vs. -test10 > Ryan Bradetich wrote: > > Do you really want to merget the ccio-rm-dma.c file into Linus's tree? > > It is just a reference file used to construct the real ccio-dma.c file ... I > > don't believe it is referenced anywhere. > > Hi Ryan, > Yes I do. It is supposed to work for ccio+PCX-W platforms (eg C360). > Keeping it arround will document the pro/con's of that approach and > give folks who have time (and the right machine) something to experiment > with instead of writing it from scratch. If someone finds an application > it's good for (short transactions with low latency requirements perhaps), > it's worth having around. > > It's not referenced because I didn't add a CONFIG_CCIO_RM_IOMMU flag > or ccio_rm_init() call to drivers/gsc/gsc.c:gsc_init(). You are welcome > add this CONFIG flag by hacking arch/parisc/config.in and defconfig. > If you do, please add rules which only allow one or the other > CONFIG_CCIO* option to be enabled. > Well, personally i'd vote to get rid of it. It works for ONE machine only, and MAY have an advantage in some small case. But if we keep it, lets make sure that it is real clear that it should NOT be the default choice. It should be marked CONFIG_EXPERIMENTAL, and the text associated with it should clearly show that it works on a C360 only. If possible, it should also be made clear that ccio-dma.c works for C360, so people who have C360's don't think they have to choose ccio-rm-dma.c. Grant, I hope you are prepared to answer the parisc-linux mailing list questions this is going to generate once parisc-linux starts becoming more visible. Another FAQ entry perhaps? :-) John Marvin jsm@fc.hp.com From jsm@udlkern.fc.hp.com Wed, 22 Nov 2000 01:52:04 -0700 (MST) Date: Wed, 22 Nov 2000 01:52:04 -0700 (MST) From: John Marvin jsm@udlkern.fc.hp.com Subject: [parisc-linux] Use of the EI_OSABI field > > BTW, it's not too hard to check .note.ABI-tag. The linker arranges for a > PT_NOTE program header entry to point to it, and the section itself is > virtually guaranteed to be read in with the header as it's placed right > after the header along with .interp. I didn't say it was difficult, I said it was ugly. It means another parisc only change to the machine independent file fs/binfmt_elf.c, since the hook provided will not allow this check. Without a change, binfmt_elf.c won't be smart enough to differentiate a binary produced by Gnu binutils for HP-UX and a binary produced by Gnu binutils for Linux, so it will claim both, and then blow up later, rather than not claiming the HP-UX binary and allowing it to be claimed by an arch dependent binary handler further down the list. And binfmt_elf.c does NOT read the program headers in the same read, so another read would have to be done (the data should be found in in cache rather than going to disk for it). Since we now need both the program headers and a section header to determine whether or not we should claim the file AND binfmt_elf.c also wants to look at those headers after the file is claimed, a small redesign is probably in order (rather than re-reading the headers). I'm not sure whether or not Linus would buy that. So, I guess I'll pursue the interpreter field instead, since that is what sparc is doing (i.e. they have their own sparc only code in binfmt_elf.c). Since that will be an easier sell. I need to do more research here. I suspect that statically linked binaries are not going to allow this solution to work though. John Marvin jsm@fc.hp.com From alan@linuxcare.com.au Wed, 22 Nov 2000 23:28:45 +1100 (EST) Date: Wed, 22 Nov 2000 23:28:45 +1100 (EST) From: Alan Modra alan@linuxcare.com.au Subject: [parisc-linux] binutils update I've just committed a change to binutils that cures an ELF spec violation. We now no longer create plabels for DT_INIT and DT_FINI and instead rely on the dynamic linker to create them for us. This means you need an updated glibc, that I committed a little earlier today, to create the plabel function pointers if you update your binutils. You have been warned... Alan Modra -- Linuxcare. Support for the Revolution. From bruno_vidal@hpfrcu03.france.hp.com Wed, 22 Nov 2000 15:14:18 +0100 Date: Wed, 22 Nov 2000 15:14:18 +0100 From: Bruno Vidal bruno_vidal@hpfrcu03.france.hp.com Subject: [parisc-linux] Crash dump module Hi Good news, I've finished to recompile the entire chain on hpux 11.00 64bits. I've recompile my own kernel and booted a small 712/60. It work pretty well. Now I'm going to start the work about crash dump. So, In my mind, I'll start from the linux/kernel/panic.c function and I'll add a function dumpsys.c in the linux/arch/paric directory -> is it okay for you ? It will depend on the CONFIG_PARISC var (or do you prefer adding a CONFIG_DUMPSYS var ?) thanks. -- Vidal Bruno, (770-4271) SSD-HA Team, HP-UX & LINUX Support bruno_vidal@admin.france.hp.com From randolph@tausq.org Wed, 22 Nov 2000 07:44:24 -0700 Date: Wed, 22 Nov 2000 07:44:24 -0700 From: Randolph Chung randolph@tausq.org Subject: [parisc-linux] Crash dump module > It will depend on the CONFIG_PARISC var (or do you prefer adding a CONFIG_DUMPSYS var ?) I think there was a consensus to use __hppa__ instead of CONFIG_PARISC ... randolph -- @..@ http://www.TauSq.org/ (----) ( >__< ) ^^ ~~ ^^ From mike_clapper@hp.com Wed, 22 Nov 2000 07:54:24 -0800 Date: Wed, 22 Nov 2000 07:54:24 -0800 From: CLAPPER,MIKE (HP-USA,ex1) mike_clapper@hp.com Subject: [parisc-linux] B132L boot hang Hello Everyone, I download the cross-compilers and build a lifimage on Redhat 6.1. I set up nfsroot on a S712 running hpux 10.20. With this I am able to boot a B132L running pdc 6.1 - almost. I get a hang right after - VFS: Mounted root (nfs filesystem) readonly Warning: unable to open an initial console I have a 700/96 on serial port 1 as the console. I have hpux on a disc in the unit I'm trying to boot - from HPUX I have verified I can nfs mount the filesys I'm using for NFSROOT. With linux in this condition the machine will respond to ping. I will also react to a telnet - i get the telnet banner then "connection closed by foreign host". FTP gets "connection refused" - so it' partially alive..... Is there a way to keyword search the developers archive? I vaguely recall seeing the 'initial console' warning, but couldn't find it browsing the developers archive Thanks, Mike ********************************************** Mike Clapper North American Crisis Management Team Hewlett Packard (405) 948-4715 ********************************************** From bame@noam.fc.hp.com Wed, 22 Nov 2000 09:02:03 -0700 Date: Wed, 22 Nov 2000 09:02:03 -0700 From: Paul Bame bame@noam.fc.hp.com Subject: [parisc-linux] CVS linux Vs. -test10 = I've been lobbying for = the removal of the almost empty arch/parisc/real directory, and its few = remaining valid files moved to the kernel directory. Done. arch/parisc/real R.I.P. From grundler@cup.hp.com Wed, 22 Nov 2000 08:27:22 -0800 Date: Wed, 22 Nov 2000 08:27:22 -0800 From: Grant Grundler grundler@cup.hp.com Subject: [parisc-linux] Crash dump module Bruno Vidal wrote: > Hi > Good news, I've finished to recompile the entire chain on hpux 11.00 64bits. > I've recompile my own kernel and booted a small 712/60. It work pretty well. > Now I'm going to start the work about crash dump. So, In my mind, I'll start > from the linux/kernel/panic.c function and I'll add a function dumpsys.c > in the linux/arch/paric directory -> is it okay for you ? YES! > It will depend on the CONFIG_PARISC var > (or do you prefer adding a CONFIG_DUMPSYS var ?) As Randolph pointed out CONFIG_PARISC is deprecated. Use "ifdef __hppa__" for changes in *common* (ie not arch/parisc) files. They should not be needed for anything in arch/parisc or linux/include/asm-parisc. Adding a CONFIG_DUMPSYS is a good idea. Look in linux/arch/parisc/config.in, linux/arch/parisc/defconfig, and the various Makefiles for how CONFIG_* flags work. thanks Bruno! grant Grant Grundler Unix Systems Enablement Lab +1.408.447.7253 From grundler@cup.hp.com Wed, 22 Nov 2000 09:27:20 -0800 Date: Wed, 22 Nov 2000 09:27:20 -0800 From: Grant Grundler grundler@cup.hp.com Subject: [parisc-linux] B132L boot hang "CLAPPER,MIKE (HP-USA,ex1)" wrote: > > > Hello Everyone, > > I download the cross-compilers and build a lifimage on Redhat 6.1. I set > up nfsroot on a S712 running hpux 10.20. With this I am able to boot a > B132L running pdc 6.1 - > almost. I get a hang right after - > > VFS: Mounted root (nfs filesystem) readonly > Warning: unable to open an initial console I think I need more output. Based on ioscan output, the B132L has two serial ports: 8/16/4 - off of LASI 8/20/2 - of WAX (EISA Bus Adapter) (GSCtoPCI is at 8/0) I don't think the one off of WAX is supported right now. Are you using the default .config produced by "make oldconfig"? It's also possible the LASI support is broken on B132L and I would expect some console output indicating what's wrong. > I have a 700/96 on serial port 1 as the console. I have hpux on a disc in > the unit I'm trying to boot - from HPUX I have verified I can nfs mount the > filesys I'm using for NFSROOT. NFS root mounted fine. Console is the problem. ... > Is there a way to keyword search the developers archive? I vaguely recall > seeing the 'initial console' warning, but couldn't find it browsing the > developers archive Yes - http://puffin.external.hp.com/cgi-bin/mailgrep grant Grant Grundler Unix Systems Enablement Lab +1.408.447.7253 From cary@cup.hp.com Wed, 22 Nov 2000 10:06:05 -0800 Date: Wed, 22 Nov 2000 10:06:05 -0800 From: Cary Coutant cary@cup.hp.com Subject: [parisc-linux] Use of the EI_OSABI field As the original author of the proposal to add the EI_OSABI field to the ELF format, let me try to clarify the intent of this field. The authoritative definition of this field is found in SCO's gABI document, which is still the official specification for the ELF format (this is probably posted somewhere on SCO's web site). Here's what it says: Byte e_ident[EI_OSABI] identifies the operating system and ABI to which the object is targeted. Some fields in other ELF structures have flags and values that have operating system and/or ABI specific meanings; the interpretation of those fields is determined by the value of this byte. The value of this byte must be interpreted differently for each machine. That is, each value for the e_machine field determines a set of values for the EI_OSABI byte. Values are assigned by the ABI processor supplement for each machine. If the processor supplement does not specify a set of values, the value 0 shall be used and indicates unspecified. The first sentence is still a bit misleading, and is an artifact of the original proposal. Originally, the field was intended to identify the target ABI (hence the name of the field). As we started discussing a common Unix ABI for IA-64, however, it became clear that this field wouldn't serve that purpose, but it was still needed to identify the set of platform-specific ELF extensions that are used by the object file. There are a number of fields in the ELF format for which ranges of values or a set of flag bits are reserved for vendor-specific use (e.g., SHT_LOOS through SHT_HIOS for vendor-specific section types, and SHF_MASKOS for vendor-specific section attributes). If an object file uses any of these values or flag bits, the consumer of the file must consult the EI_OSABI field to determine what those values or flags mean. It works just like the e_machine field does for attaching meaning to processor-specific values and flags. The intent is that any ABI-conforming implementation will be able to execute an ABI-conforming binary, even if it uses certain vendor-specific features. In many cases, those vendor-specific features are hints for a particular OS that can be ignored by other implementations. Where this is not the case, and a vendor-specific feature must be understood by the system in order to process the file correctly, we have a couple of alternatives. For section types and flags that a linker must understand, we have the SHF_OS_NONCONFORMING flag -- if set, and a linker doesn't understand a particular section type or flag, it must reject the file. For executables that will execute only on a particular implementation, we must use an alternate interpreter (PT_INTERP) or bind to implementation-specific shared libraries. An ABI-conforming binary will use the interpreter specified in the psABI spec, and will use only system libraries specified there. For statically-bound programs, I'm afraid we don't have a clear solution. We took the general approach that such programs are not ABI-conforming in the first place, and can use any mechanism they might choose to verify that they are executing on the appropriate implementation. -cary From grundler@cup.hp.com Wed, 22 Nov 2000 11:55:38 -0800 Date: Wed, 22 Nov 2000 11:55:38 -0800 From: Grant Grundler grundler@cup.hp.com Subject: [parisc-linux] CVS linux Vs. -test10 John Marvin wrote: > Grant Grundler wrote: > > Yes I do. It is supposed to work for ccio+PCX-W platforms (eg C360). ... > Well, personally i'd vote to get rid of it. It works for ONE machine only, > and MAY have an advantage in some small case. And so does the OB600 mouse driver I rewrote/published. AFAIK, it only works on OB600s. I was originally thinking D/K/R-class boxes had PCX-W upgrades but AFAICT, they don't. > But if we keep it, lets make > sure that it is real clear that it should NOT be the default choice. > > It should be marked CONFIG_EXPERIMENTAL, and the text associated with it > should clearly show that it works on a C360 only. If possible, it should > also be made clear that ccio-dma.c works for C360, so people who have > C360's don't think they have to choose ccio-rm-dma.c. IIRC, Comments in the headers of both ccio files make those issues clear. I'm not sure where else that needs to be documented. > Grant, I hope you are prepared to answer the parisc-linux mailing list > questions this is going to generate once parisc-linux starts becoming more > visible. Another FAQ entry perhaps? :-) Ryan owns it. He's responsible for documenting it and adding FAQ questions. He can choose to delete ccio-rm-dma.c as well. :^) I think it'd be a waste to throw it away before someone figures out that it's really not useful - even if just for C360. thanks, grant From mike_clapper@hp.com Wed, 22 Nov 2000 12:05:23 -0800 Date: Wed, 22 Nov 2000 12:05:23 -0800 From: CLAPPER,MIKE (HP-USA,ex1) mike_clapper@hp.com Subject: [parisc-linux] B132L boot hang Thanks Grant, I verified the console is off 8/16/4.0 and that it is the LASI port. I also downloaded the newest cross-compiler and source code. After rebuilding the palo lifimage I get the same hang in the same place. Since I was cabled to a dumb terminal I was not able to capture the boot output. I will find the right cable to hook up to my pc so I can capture the output and send it to you - perhaps an error occurred earlier in the boot that I overlooked. Thanks for the help. Mike -----Original Message----- From: Grant Grundler [mailto:grundler@cup.hp.com] Sent: Wednesday, November 22, 2000 11:27 AM To: CLAPPER,MIKE (HP-USA,ex1) Cc: 'parisc-linux@thepuffingroup.com' Subject: Re: [parisc-linux] B132L boot hang "CLAPPER,MIKE (HP-USA,ex1)" wrote: > > > Hello Everyone, > > I download the cross-compilers and build a lifimage on Redhat 6.1. I set > up nfsroot on a S712 running hpux 10.20. With this I am able to boot a > B132L running pdc 6.1 - > almost. I get a hang right after - > > VFS: Mounted root (nfs filesystem) readonly > Warning: unable to open an initial console I think I need more output. Based on ioscan output, the B132L has two serial ports: 8/16/4 - off of LASI 8/20/2 - of WAX (EISA Bus Adapter) (GSCtoPCI is at 8/0) I don't think the one off of WAX is supported right now. Are you using the default .config produced by "make oldconfig"? It's also possible the LASI support is broken on B132L and I would expect some console output indicating what's wrong. > I have a 700/96 on serial port 1 as the console. I have hpux on a disc in > the unit I'm trying to boot - from HPUX I have verified I can nfs mount the > filesys I'm using for NFSROOT. NFS root mounted fine. Console is the problem. ... > Is there a way to keyword search the developers archive? I vaguely recall > seeing the 'initial console' warning, but couldn't find it browsing the > developers archive Yes - http://puffin.external.hp.com/cgi-bin/mailgrep grant Grant Grundler Unix Systems Enablement Lab +1.408.447.7253 --------------------------------------------------------------------------- To unsubscribe: send e-mail to parisc-linux-request@thepuffingroup.com with `unsubscribe' as the subject. From kirkb@chrome.rose.hp.com Wed, 22 Nov 2000 12:10:10 PST Date: Wed, 22 Nov 2000 12:10:10 PST From: Kirk Bresniker kirkb@chrome.rose.hp.com Subject: [parisc-linux] CVS linux Vs. -test10 Grant Grundler wrote: | I was originally thinking D/K/R-class boxes had PCX-W upgrades but | AFAICT, they don't. | The C-class upgrade to PCX-W was a one-off. Upgrades for similar enterprise servers were not designed. KMB -- +============================================================+ | Kirk Bresniker (916) 748-2393 | | 8000 Foothills Blvd | | Roseville, CA 95747-5649 | | kirkb@rose.hp.com | From grundler@cup.hp.com Wed, 22 Nov 2000 12:11:23 -0800 Date: Wed, 22 Nov 2000 12:11:23 -0800 From: Grant Grundler grundler@cup.hp.com Subject: [parisc-linux] CVS linux Vs. -test10 Grant Grundler wrote: ... > arch/parisc/kernel/ccio-dma.c -> drivers/gsc/ccio-dma.c > arch/parisc/kernel/ccio-rm-dma.c -> drivers/gsc/ccio-rm-dma.c > > ccio will *always* be associated with a GSC bus since that's > the secondary bus. And ccio supports devices below dino.c which > already lives in drivers/gsc. Ryan - moving/keeping these files is up to you. I was just sharing what I thought was "right". Apologies for not making that clear earlier. > arch/parisc/kernel/lba_pci.c -> drivers/ropes/lba_pci.c > arch/parisc/kernel/sba_iommu.c -> drivers/ropes/sba_iommu.c > arch/parisc/kernel/iosapic.c -> drivers/ropes/iosapic.c I've talked to one of the folks working on IA64-linux. They are interested in merging iosapic code but haven't even looked at the parisc version I wrote. We talked a bit about the issues and it doesn't sound like it's going to happen anytime soon. In any case, iosapic.c doesn't belong under "drivers/ropes". So none of this needs to move in the forseeable future. It can all stay in arch/parisc/kernel. grant Grant Grundler Unix Systems Enablement Lab +1.408.447.7253 From deller@gmx.de Wed, 22 Nov 2000 21:43:40 +0100 Date: Wed, 22 Nov 2000 21:43:40 +0100 From: Helge Deller deller@gmx.de Subject: [parisc-linux] B132L boot hang > I think I need more output. Based on ioscan output, the B132L > has two serial ports: > 8/16/4 - off of LASI > 8/20/2 - of WAX (EISA Bus Adapter) > > (GSCtoPCI is at 8/0) > > I don't think the one off of WAX is supported right now. It should be detected & supported (at least it is on my B160L). But it is not used as initial console since it normally gets assigned as ttyS1 while LASI-serial gets ttyS0. Greetings, Helge. From bame@noam.fc.hp.com Wed, 22 Nov 2000 16:03:12 -0700 Date: Wed, 22 Nov 2000 16:03:12 -0700 From: Paul Bame bame@noam.fc.hp.com Subject: [parisc-linux] 64-bit progress 32-bit syscalls on 64-bit kernel are to the point where a few things work, and signals appear to be working (I didn't implement *all* the signal-related syscalls yet). I'll be continuing to produce syscall wrappers for a while... If you try to boot the standard NFS root with wide kernel, you'll want to mv sbin/init sbin/init-real then compile and install this program as sbin/init: int main() { char *argv[2]; argv[0] = "/sbin/init-real"; argv[1] = 0; execv(argv[0], argv); } I never felt comfortable I found the point where sys_execve figures out it needs to pack the argv vector differently for narrow user apps (locally I also am using PER_LINUX32 in binfmt_elf32.c) which causes the initial exec(/sbin/init) to be passed incomprehensible arguments. This program is a little temporary workaround. -Paul Bame From alan@linuxcare.com.au Thu, 23 Nov 2000 11:18:20 +1100 (EST) Date: Thu, 23 Nov 2000 11:18:20 +1100 (EST) From: Alan Modra alan@linuxcare.com.au Subject: glibc On Wed, 22 Nov 2000, Matt Taggart wrote: > Hi Alan, > > First a timezone question... your mail headers have you in +11 and Ft. Collins > is -7 so you're 6 hours behind + 1 day relative to us? So as I send this it's > 14:05 here and 8:05 there? Hi Matt, I'm actually on +10:30 in Adelaide, but posting from a Linuxcare machine in Canberra which is on +11. >[snip segfaults] > I am building native using dhd's binutils/gcc/glibc debs, using source checked > out just after the glibc 2.2 merge. Do you think the merge / ld.so changes you > just made would help this problem at all? Quite likely. This fix * sysdeps/hppa/dl-machine.h (ELF_MACHINE_START_ADDRESS): Define. is fairly crucial, as without it %dp will not be set correctly. I should have mentioned this when posting to the list about the binutils change. Oh, and as of this email, I haven't actually run anything linked to the new glibc. A little remiss, I know, but I've been deep in the gdb port, and if I spend time tinkering with glibc, binutils and gcc (which I like), gdb (which I don't like) will never be finished. ;-) Alan -- Linuxcare. Support for the Revolution. From grundler@cup.hp.com Wed, 22 Nov 2000 18:24:52 -0800 (PST) Date: Wed, 22 Nov 2000 18:24:52 -0800 (PST) From: Grant Grundler grundler@cup.hp.com Subject: [parisc-linux] new SBA IOMMU version committed Hi all, I've committed my "second generation" I/O MMU code for C3K/J5k boxes. It's only tested for 32-bit. I'll be testing 64-bit shortly. This code makes "perfect" use of the I/O pdir resource map and we shouldn't see any panics due to out_of_resource. grant From grundler@cup.hp.com Wed, 22 Nov 2000 18:47:06 -0800 (PST) Date: Wed, 22 Nov 2000 18:47:06 -0800 (PST) From: Grant Grundler grundler@cup.hp.com Subject: [parisc-linux] CONFIG_DMB_TRAP diff Hello again (last one until Monday - I promise), With Lamont's wisdom, I implemented support for Date Memory Break trap. This enables the kernel programmer to capture the evil code which stomps on other people's "private" data. Only works for stores through virtual addresses. gsc_writeX() and DMA will still bypass this mechanism. pb, dhd, (or some equivalent deity), could you review/commit this code? Or tell me it's ok to commit? I've touched: arch/parisc/config.in arch/parisc/kernel/entry.S arch/parisc/mm/kmap.c include/asm-parisc/pgtable.h thanks, grant Index: arch/parisc/config.in =================================================================== RCS file: /home/cvs/parisc/linux/arch/parisc/config.in,v retrieving revision 1.25 diff -u -p -r1.25 config.in --- config.in 2000/10/20 18:28:26 1.25 +++ config.in 2000/11/23 02:18:23 @@ -16,8 +16,12 @@ endmenu mainmenu_option next_comment comment 'General options' -# bool 'Symmetric multi-processing support' CONFIG_SMP -define_bool CONFIG_SMP n +bool 'Symmetric multi-processing support' CONFIG_SMP +# define_bool CONFIG_SMP n + +# One needs to tweak dmb_trap_11 code in entry.S to match. +# Not tested for 64-bit kernel. +bool 'Debug support for Data Memory Break Trap' CONFIG_DMB_TRAP bool 'Kernel Debugger support' CONFIG_KWDB # define_bool CONFIG_KWDB n Index: arch/parisc/kernel/entry.S =================================================================== RCS file: /home/cvs/parisc/linux/arch/parisc/kernel/entry.S,v retrieving revision 1.53 diff -u -p -r1.53 entry.S --- entry.S 2000/11/22 16:51:33 1.53 +++ entry.S 2000/11/23 02:18:23 @@ -23,6 +23,7 @@ */ #include +#include /* the following is the setup i think we should follow: * whenever the CPU is interruptible, the following has to be true: @@ -349,7 +350,39 @@ .endm #endif +#ifdef CONFIG_DMB_TRAP /* + ** Data Memory Bit trap interruption handler (parisc 1.1) + ** + ** This is a debugging aid. Use it when you think someone else + ** is stepping on your memory. It only catches *virtual* + ** accesses. gsc_writeX() functions disable virtual translation + ** (D-bit) and will happily scribble whatever physical address + ** is passed in. + ** + ** Here's how to use it: + ** 1) Call iterate_pages() from your init routine like this: + ** iterate_pages( my_private_mem, private_mem_size, + ** set_data_memory_break, 0); + ** 2) substitute your functions for your_function1 (or 2) in + ** dmb_trap_11 code below. + ** + ** Thanks to Lamont Jones for telling me how to do this. + ** - ggg 1/22/2000 + */ + .macro dmb_11 code + + mfctl %isr,spc + b dmb_trap_11 + mfctl %ior,va + + .align 32 + .endm +#else +#define dmb_11 def +#endif + + /* * dirty bit trap interruption handler (parisc 2.0) */ @@ -448,7 +481,7 @@ fault_vector_11: naitlb_11 16 nadtlb_11 17 def 18 - def 19 + dmb_11 19 dbit_11 20 def 21 def 22 @@ -467,7 +500,6 @@ fault_vector_11: .import handle_interruption,code .import handle_real_interruption,code .import do_irq_mask,code - .import parisc_stopkernel,code .import cpu_irq_region,data /* @@ -903,11 +935,15 @@ dtlb_miss_11: dep pte,8,7,prot extru,= pte,_PAGE_NO_CACHE_BIT,1,r0 - depi 1,12,1,prot + depi 1,12,1,prot /* U-bit */ extru,= pte,_PAGE_USER_BIT,1,r0 depi 7,11,3,prot /* Set for user space (1 rsvd for read) */ extru,= pte,_PAGE_GATEWAY_BIT,1,r0 depi 0,11,2,prot /* If Gateway, Set PL2 to 0 */ +#ifdef CONFIG_DMB_TRAP + extru,= pte,_PAGE_DMB_BIT,1,r0 + depi 1,4,1,prot /* B-bit */ +#endif /* Get rid of prot bits and convert to page addr for idtlba */ @@ -1300,6 +1336,30 @@ dbit_trap_11: rfir nop + +#ifdef CONFIG_DMB_TRAP + .import your_function1,code + .import your_function2,code + +dmb_trap_11: + mfctl pcsq,t0 /* get space */ + comb,<>,n t0,%r0,dmb_rfi /* not kernel - bail */ + + mfctl pcoq,t0 /* get offset */ + ldil L%dmb_ok_function1, t1 + dep %r0, 31, 12, t0 + comb,=,n t0,t1,dmb_rfi /* it's ours - bail */ + + ldil L%dmb_ok_function2, t1 + comb,<>,n t0,t1,intr_save /* not ours - panic */ + +dmb_rfi: + mfctl ipsw,t0 /* Set PSW X-bit - just continue */ + depi 1,11,1,t0 /* Set X-bit */ + mtctl t0, ipsw + rfir + nop +#endif dbit_trap_20: mfctl %cr25,ptp /* Assume user space trap */ Index: arch/parisc/mm/kmap.c =================================================================== RCS file: /home/cvs/parisc/linux/arch/parisc/mm/kmap.c,v retrieving revision 1.3 diff -u -p -r1.3 kmap.c --- kmap.c 2000/05/05 18:05:47 1.3 +++ kmap.c 2000/11/23 02:18:23 @@ -43,7 +43,16 @@ static void unmap_cached_pte(pte_t * pte } #endif +#ifdef CONFIG_DMB_TRAP /* These two routines should probably check a few things... */ +void set_data_memory_break(pte_t * pte, unsigned long arg) +{ + pte_val(*pte) |= _PAGE_DMB; +} + +#endif + +/* These two routines should probably check a few things... */ static void set_uncached(pte_t * pte, unsigned long arg) { pte_val(*pte) |= _PAGE_NO_CACHE; @@ -106,7 +115,10 @@ static inline void iterate_pmd(pgd_t * d } while (address < end); } -static void iterate_pages(unsigned long address, unsigned long size, +#ifndef CONFIG_DMB_TRAP +static +#endif +void iterate_pages(unsigned long address, unsigned long size, pte_iterator_t op, unsigned long arg) { pgd_t *dir; Index: include/asm-parisc/pgtable.h =================================================================== RCS file: /home/cvs/parisc/linux/include/asm-parisc/pgtable.h,v retrieving revision 1.29 diff -u -p -r1.29 pgtable.h --- pgtable.h 2000/11/10 21:44:44 1.29 +++ pgtable.h 2000/11/23 02:18:23 @@ -109,6 +109,10 @@ extern void *vmalloc_start; #define _PAGE_USER 0x400 /* Software: User accessable page */ #define _PAGE_USER_BIT 21 /* Needs to agree with _PAGE_USER above */ /* 0x800 still available */ +#ifdef CONFIG_DMB_TRAP +#define _PAGE_DMB 0x800 /* Data Memory Break Trap */ +#define _PAGE_DMB_BIT 20 /* Data Memory Break Trap */ +#endif #ifdef __ASSEMBLY__ #define _PGB_(x) (1 << (63 - (x))) From jsm@udlkern.fc.hp.com Wed, 22 Nov 2000 22:50:14 -0700 (MST) Date: Wed, 22 Nov 2000 22:50:14 -0700 (MST) From: John Marvin jsm@udlkern.fc.hp.com Subject: [parisc-linux] CONFIG_DMB_TRAP diff > > Hello again (last one until Monday - I promise), > > With Lamont's wisdom, I implemented support for Date Memory Break trap. > > This enables the kernel programmer to capture the evil code which > stomps on other people's "private" data. Only works for stores > through virtual addresses. gsc_writeX() and DMA will still > bypass this mechanism. > > pb, dhd, (or some equivalent deity), could you review/commit this code? > Or tell me it's ok to commit? > > I've touched: > arch/parisc/config.in > arch/parisc/kernel/entry.S > arch/parisc/mm/kmap.c > include/asm-parisc/pgtable.h > Please don't. This solution is way more complicated than it should be. Here are the problems with it: 1) As I had already mentioned in a previous discussion, the pte's already reserve the location for the B bit (data memory break trap) and the dtlb miss handlers already move the entire group of bits that include this bit in one operation. So no change is necessary to the dtlb miss handlers to specially set that bit and incur extra instructions in the tlb miss handlers, and no extra bits need to be allocated in the pte. Instead of adding a new definition (e.g. 0x800, which is our last available bit) use the one that is already reserved for it: 0x010. 2) There is no reason to add a special data memory break trap handler. The general trap handler is more than sufficient for this case. handle_interruption will be called if a data memory break trap is encountered. Just add a new case for the list of traps, and handle the trap in C. You can set the X bit by simply setting it in the saved ipsw (in gr[0]) and it will be set upon return from the trap, no muss, no fuss. Note that the above also applies for the page reference trap. The T bit is also already supported (0x040 in the pte) by the dtlb miss handlers. Note that the reason I reserved these bits is because it would actually take MORE code in the dtlb miss handlers to NOT support those bits and use them for something else. Another helpful hint for those wanting to use this feature. If you are tracking corruptions that span multiple pages, then just setting the B bit on each page may be all you need. But, when I've used the data memory break trap for corruption tracking, typically I've wanted to track a corruption that was happening to a particular variable, i.e. a 4 byte quantity, and lots of other variables were being legitimately written on the same page, so you wind up with thousands of data memory break traps, where only one may be the one that is corrupting the location you are interested in. But, all is not lost, the solution is still fairly simple. The data memory break trap provides a valid iir, isr and ior. So once you get the trap, a custom data memory break handler (which can be written with a few lines of C in handle_interruption), simply uses iir, isr and ior to check if the access was to the specific byte or bytes you are interested in. I've simply used isr/ior to check for writes within the word I was interested in. That may be enough for most cases. The information you are missing from isr/ior is the size of the write transaction. To get this you would need to parse the instruction stored in iir (code to determine the size of a store from the instruction in the iir will be necessary when an unaligned fault handler is written). John Marvin jsm@fc.hp.com From jsm@udlkern.fc.hp.com Thu, 23 Nov 2000 01:29:55 -0700 (MST) Date: Thu, 23 Nov 2000 01:29:55 -0700 (MST) From: John Marvin jsm@udlkern.fc.hp.com Subject: [parisc-linux] CONFIG_DMB_TRAP diff Alan Modra wrote: > > gdb will eventually want to use this trap too. > Cool! However, data memory break traps for user translations are a little tougher. There are some small modifications in the machine dependent code that I can make to make sure the B bit stays set during most VM operations on a page. However, since the machine independent part of the VM system doesn't know anything about this bit (nor should it), it won't be preserved if the page is paged out (and subsequently paged back in). This could be fixed fairly easily with some changes to the machine independent code, but I don't think that would be appropriate. Some potential solutions (each has its problems): 1) Just document the fact that the feature may not work on systems with low memory. It's a parisc only feature, so perhaps we could live with that. 2) Lock the page in memory (using the mlock interface) when we set the B bit on a page. Just some thoughts on the subject. John Marvin jsm@fc.hp.com From pjlahaie@linuxcare.com Fri, 24 Nov 2000 16:56:16 -0500 Date: Fri, 24 Nov 2000 16:56:16 -0500 From: Paul J.Y. Lahaie pjlahaie@linuxcare.com Subject: [parisc-linux] boot-floppies dependancies --GRPZ8SYKNexpdSJ7 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline I would like to know if anyone has built any of the following packages that are needed for the boot-floppies. Currently, the missing deps are: cspsfonts man-db tetex-bin recode cslatex libpaperg tetex-extra libnewt-dev libgd1g-dev gawk libi18n-langtags-perl dpkg-awk debiandoc-sgml I'm currently trying to get a working apt, since the one of pehc and the .iso seem to be broken (no xfer methods). I'll let everyone know when a working copy will be available. - Paul --GRPZ8SYKNexpdSJ7 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.4 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE6HuP/8ggPQthPCzcRAnyKAJ0fyraVXEvlI0yQLsli7FlnUUAPdwCfSyv/ YgAxOcVMDgWfHBc7lneuc1Y= =tScM -----END PGP SIGNATURE----- --GRPZ8SYKNexpdSJ7-- From doneill@linuxcare.com Fri, 24 Nov 2000 17:01:00 -0500 (EST) Date: Fri, 24 Nov 2000 17:01:00 -0500 (EST) From: Dave O'Neill doneill@linuxcare.com Subject: [parisc-linux] strace? So, I've heard rumours that somewhere there's a working strace for parisc.... Can anyone point me in the right direction? Dave -- Dave O'Neill, Senior Linux Consultant, Linuxcare, Inc. desk: (613) 562-9949 fax: (613) 562-9700 cell: (613) 223-0219 doneill@linuxcare.com http://www.linuxcare.com/ From obrien@FreeBSD.org Sat, 25 Nov 2000 12:22:11 -0800 Date: Sat, 25 Nov 2000 12:22:11 -0800 From: David O'Brien obrien@FreeBSD.org Subject: [parisc-linux] Use of the EI_OSABI field On Tue, Nov 21, 2000 at 03:27:19PM -0800, Ulrich Drepper wrote: > Alan Modra writes: > > > Ulrich Drepper also was quite vehement against changing sourceware > > FreeBSD binutils. > > I've never said anything about any *BSD, why should I? The *BSD > people wanted to change the Linux binutils. No (don't put words in my mouth Ulrich as you'll be wrong 99% of the time). I wanted the Sourceware Binutils to set the EI_OSABI to "ELFOSABI_LINUX" when targeting Linux. -- -- David (obrien@FreeBSD.org) From obrien@FreeBSD.org Sat, 25 Nov 2000 12:28:40 -0800 Date: Sat, 25 Nov 2000 12:28:40 -0800 From: David O'Brien obrien@FreeBSD.org Subject: [parisc-linux] Use of the EI_OSABI field On Tue, Nov 21, 2000 at 07:11:29PM -0800, H . J . Lu wrote: > When I was at the IA64 ABI meeting yesterday, we were looking at the > EI_OSABI issue. Everyone at the IA64 ABI meeting agreed that what > Ulrich and I had said was the correct understanding. > > "The e_ident[EI_OSABI] value identifies the operating system and ABI > to which the object is targeted" just means if the e_ident[EI_OSABI] Then is this *extremely* misleading text going to be changed??? "the operating system and" needs to be deleted in the _official_ _published_ specification. -- -- David (obrien@FreeBSD.org) From obrien@FreeBSD.org Sat, 25 Nov 2000 12:31:08 -0800 Date: Sat, 25 Nov 2000 12:31:08 -0800 From: David O'Brien obrien@FreeBSD.org Subject: [parisc-linux] Use of the EI_OSABI field On Tue, Nov 21, 2000 at 07:18:21PM -0800, Ulrich Drepper wrote: > Alan Modra writes: > > "The e_ident[EI_OSABI] value identifies the operating system and ABI to > > which the object is targeted" > > > > Granted, this is only in a processor specific ABI, but it does flatly > > contradict your assertions that the purpose of EI_OSABI is to flag the > > presense of ELF extensions. > > The meaning of the field changed over time. Or better said, some > people initially understood it differently. Then lets get the _official_ wording changed. Obviously my interpretation wasn't unreasonable. And the world does not need to have you as a premadona keeper of the [unwritten] rules of the land. -- -- David (obrien@FreeBSD.org) From hjl@valinux.com Sat, 25 Nov 2000 12:33:40 -0800 Date: Sat, 25 Nov 2000 12:33:40 -0800 From: H . J . Lu hjl@valinux.com Subject: [parisc-linux] Use of the EI_OSABI field On Sat, Nov 25, 2000 at 12:28:40PM -0800, David O'Brien wrote: > On Tue, Nov 21, 2000 at 07:11:29PM -0800, H . J . Lu wrote: > > When I was at the IA64 ABI meeting yesterday, we were looking at the > > EI_OSABI issue. Everyone at the IA64 ABI meeting agreed that what > > Ulrich and I had said was the correct understanding. > > > > "The e_ident[EI_OSABI] value identifies the operating system and ABI > > to which the object is targeted" just means if the e_ident[EI_OSABI] > > > Then is this *extremely* misleading text going to be changed??? > "the operating system and" needs to be deleted in the _official_ > _published_ specification. > I will bring this issue up to ia64 psABI and gABI. -- H.J. Lu (hjl@valinux.com) From alan@lxorguk.ukuu.org.uk Sat, 25 Nov 2000 20:57:05 +0000 (GMT) Date: Sat, 25 Nov 2000 20:57:05 +0000 (GMT) From: Alan Cox alan@lxorguk.ukuu.org.uk Subject: [parisc-linux] RPM and hppa I've uploaded my first block of RPM packages to ftp.linux.org.uk/pub/linux/alan/HPPA along with a tar ball of built RPM tools for anyone who wants to play. In doing so I've hit a few problems with the 0.5 iso (no suprises there since its not actually meant to work reliably) - g++ explodes trying to build groff after allocating about 400Mb of RAM. Building -O0 works - the configure script for procmail tries to find the largest argument set that works (by searching). It crashes the kernel in doing so 8) - ldd is causing page faults in ld.so (kernel logged ones) and dying with segv. Fortunately it outputs the library list first - The linker appears to have a problem when resolving symbols between three shared objects while doing a shared object link. [Example is rpm: rpmlib is linked dynamically with -ldb3 -ldb The linker emits messages about symbols being static and should be built -fPIC. If you dump the libraries they are -fPIC. It looks as if its resolving a symbol between two shared libraries and making a static resolution that then blows up when the third library gets involved ] - The kernel shows occasional page cache corruption. This actually is quite possibly generic test6 bugs On the whole the toolset is working remarkably well. I've built over 100 source package sets so far including things like ncurses and most stuff just builds or hits portability problems (eg gmp wants to use HP format asm, zlib wants to be a non PIC library for performance but the HP tools dont allow it) Alan From alan@linuxcare.com.au Sun, 26 Nov 2000 23:01:50 +1100 (EST) Date: Sun, 26 Nov 2000 23:01:50 +1100 (EST) From: Alan Modra alan@linuxcare.com.au Subject: [parisc-linux] RPM and hppa On Sat, 25 Nov 2000, Alan Cox wrote: > - g++ explodes trying to build groff after allocating about 400Mb of RAM. > Building -O0 works Yeah, this is a known issue. I see on the gcc list that rth and others have been working on gcc fixes recently that should address the problem. I don't have the time/ability to fix it myself. > - the configure script for procmail tries to find the largest argument set > that works (by searching). It crashes the kernel in doing so 8) > > - ldd is causing page faults in ld.so (kernel logged ones) and dying with > segv. Fortunately it outputs the library list first How old are your glibc and binutils? I made some changes late October that should have fixed this problem. See http://puffin.external.hp.com/mailing-lists/parisc-linux/2000/10-Oct/0146.html Does "readelf -d" on your hppa-linux ld.so show you have a DT_TEXTREL tag? > - The linker appears to have a problem when resolving symbols between three > shared objects while doing a shared object link. > > [Example is rpm: > > rpmlib is linked dynamically with -ldb3 -ldb > > The linker emits messages about symbols being static and should be > built -fPIC. If you dump the libraries they are -fPIC. > > It looks as if its resolving a symbol between two shared libraries > and making a static resolution that then blows up when the third > library gets involved > > ] Could you put all the objects involved in the link up for ftp somewhere? I've just built rpm-2.5.6 without seeing this problem, but I'm sure my setup is different to yours... Regards, Alan Modra -- Linuxcare. Support for the Revolution. From alan@lxorguk.ukuu.org.uk Sun, 26 Nov 2000 12:12:21 +0000 (GMT) Date: Sun, 26 Nov 2000 12:12:21 +0000 (GMT) From: Alan Cox alan@lxorguk.ukuu.org.uk Subject: [parisc-linux] RPM and hppa > How old are your glibc and binutils? I made some changes late October From the 0.5 cdrom > http://puffin.external.hp.com/mailing-lists/parisc-linux/2000/10-Oct/0146.html > Does "readelf -d" on your hppa-linux ld.so show you have a DT_TEXTREL tag? Nope > Could you put all the objects involved in the link up for ftp > somewhere? I've just built rpm-2.5.6 without seeing this problem, but I'm > sure my setup is different to yours... rpm 4.0. rpm2 doesnt do that 3 way link with db and db3. I'll put them up when I get a bit of time From dave@hiauly1.hia.nrc.ca Sun, 26 Nov 2000 11:45:08 -0500 (EST) Date: Sun, 26 Nov 2000 11:45:08 -0500 (EST) From: John David Anglin dave@hiauly1.hia.nrc.ca Subject: [parisc-linux] RPM and hppa > On Sat, 25 Nov 2000, Alan Cox wrote: > > > - g++ explodes trying to build groff after allocating about 400Mb of RAM. > > Building -O0 works > > Yeah, this is a known issue. I see on the gcc list that rth and others > have been working on gcc fixes recently that should address the problem. > I don't have the time/ability to fix it myself. I think the above is a different problem. The explosion is most likely a problem with exception edges in the gcse pass. Try `-fno-gcse'. This also appears in the tFile.cc libio test. The pa port uses sjlj exceptions via __builtin_setjmp/longjmp. A nonlocal goto label is used for the target of the longjmp. The flow analysis assumes that an "exception" could jump to any label in the procedure rather than just the label associated with the exception region. Dave -- J. David Anglin dave.anglin@nrc.ca National Research Council of Canada (613) 990-0752 (FAX: 952-6605) From cwalthall@cwalthall.com Sun, 26 Nov 2000 11:45:38 -0600 Date: Sun, 26 Nov 2000 11:45:38 -0600 From: Carl & Delores Walthall cwalthall@cwalthall.com Subject: [parisc-linux] RPM and hppa Does anyone know where I can find the operating system for the HP9000 J200 Server? Thanks Carl Walthall ----- Original Message ----- From: "Alan Modra" To: "Alan Cox" Cc: Sent: Sunday, November 26, 2000 6:01 AM Subject: Re: [parisc-linux] RPM and hppa > On Sat, 25 Nov 2000, Alan Cox wrote: > > > - g++ explodes trying to build groff after allocating about 400Mb of RAM. > > Building -O0 works > > Yeah, this is a known issue. I see on the gcc list that rth and others > have been working on gcc fixes recently that should address the problem. > I don't have the time/ability to fix it myself. > > > - the configure script for procmail tries to find the largest argument set > > that works (by searching). It crashes the kernel in doing so 8) > > > > - ldd is causing page faults in ld.so (kernel logged ones) and dying with > > segv. Fortunately it outputs the library list first > > How old are your glibc and binutils? I made some changes late October > that should have fixed this problem. See > http://puffin.external.hp.com/mailing-lists/parisc-linux/2000/10-Oct/0146.ht ml > Does "readelf -d" on your hppa-linux ld.so show you have a DT_TEXTREL tag? > > > - The linker appears to have a problem when resolving symbols between three > > shared objects while doing a shared object link. > > > > [Example is rpm: > > > > rpmlib is linked dynamically with -ldb3 -ldb > > > > The linker emits messages about symbols being static and should be > > built -fPIC. If you dump the libraries they are -fPIC. > > > > It looks as if its resolving a symbol between two shared libraries > > and making a static resolution that then blows up when the third > > library gets involved > > > > ] > > Could you put all the objects involved in the link up for ftp > somewhere? I've just built rpm-2.5.6 without seeing this problem, but I'm > sure my setup is different to yours... > > Regards, Alan Modra > -- > Linuxcare. Support for the Revolution. > > > -------------------------------------------------------------------------- - > To unsubscribe: send e-mail to parisc-linux-request@thepuffingroup.com with > `unsubscribe' as the subject. > From cwalthall@cwalthall.com Sun, 26 Nov 2000 11:47:24 -0600 Date: Sun, 26 Nov 2000 11:47:24 -0600 From: Carl & Delores Walthall cwalthall@cwalthall.com Subject: [parisc-linux] RPM and hppa Hi All I have a HP9000 J200 server and would like to find the operating system software for it. Can you tell me where to look on the internet or who I may call? The server has a OS installed but no one can remember the user or password information. So they gave it to me to take home, is there a way to boot it on a floppy and change this information? Thanks for any information you can give me! Carl walthall ----- Original Message ----- From: "John David Anglin" To: "Alan Modra" Cc: ; Sent: Sunday, November 26, 2000 10:45 AM Subject: Re: [parisc-linux] RPM and hppa > > On Sat, 25 Nov 2000, Alan Cox wrote: > > > > > - g++ explodes trying to build groff after allocating about 400Mb of RAM. > > > Building -O0 works > > > > Yeah, this is a known issue. I see on the gcc list that rth and others > > have been working on gcc fixes recently that should address the problem. > > I don't have the time/ability to fix it myself. > > I think the above is a different problem. The explosion is most likely > a problem with exception edges in the gcse pass. Try `-fno-gcse'. This > also appears in the tFile.cc libio test. > > The pa port uses sjlj exceptions via __builtin_setjmp/longjmp. A > nonlocal goto label is used for the target of the longjmp. The flow > analysis assumes that an "exception" could jump to any label in the > procedure rather than just the label associated with the exception > region. > > Dave > -- > J. David Anglin dave.anglin@nrc.ca > National Research Council of Canada (613) 990-0752 (FAX: 952-6605) > > -------------------------------------------------------------------------- - > To unsubscribe: send e-mail to parisc-linux-request@thepuffingroup.com with > `unsubscribe' as the subject. > From alan@lxorguk.ukuu.org.uk Sun, 26 Nov 2000 22:47:43 +0000 (GMT) Date: Sun, 26 Nov 2000 22:47:43 +0000 (GMT) From: Alan Cox alan@lxorguk.ukuu.org.uk Subject: [parisc-linux] Linker failure with db1 I replaced the libdb1 on the ISO with one built using the toolchain on the ISO and all is now happy. From grundler@cup.hp.com Sun, 26 Nov 2000 19:11:41 -0800 Date: Sun, 26 Nov 2000 19:11:41 -0800 From: Grant Grundler grundler@cup.hp.com Subject: [parisc-linux] RPM and hppa "Carl & Delores Walthall" wrote: > Hi All > > I have a HP9000 J200 server and would like to find the operating system > software for it. Can you tell me where to look on the internet or who I may > call? Carl, The short answer is a port of linux to the J200 is in progress. See http://www.parisc-linux.org/ for status. If you have more questions read the FAQ and check the mailing list archives using http://puffin.external.hp.com/cgi-bin/mailgrep first please. > The server has a OS installed but no one can remember the user or password > information. So they gave it to me to take home, is there a way to boot > it on a floppy and change this information? Here's how to "fix" this: During power up/boot press key to get "BOOT ADMIN>" prompt. type "bo pri isl". At "ISL>" prompt, type "hpux -is". HPUX should boot to single user. use "mountall" or "mount -a" to mount all file systems. Then you can "vi /etc/passwd" or "passwd root". If that doesn't work and you can afford to loan the box out for a 3-4 monthes, you might ask if someone could install parisc-linux on it for you in exchange for a few monthes use. grant Grant Grundler Unix Systems Enablement Lab +1.408.447.7253 From grundler@cup.hp.com Sun, 26 Nov 2000 22:12:10 -0800 Date: Sun, 26 Nov 2000 22:12:10 -0800 From: Grant Grundler grundler@cup.hp.com Subject: [parisc-linux] case LEDs Alex deVries wrote: > Grant Grundler wrote: > > I was already asked this weekend to dig up technical info on LED > > and soft power control. I guess this is my reminder to do that. :^) I dug up the info but it's not in a form I'm willing to publishing. However, someone did volunteer to look at this and I've provided them with this info. So it will make into our CVS source tree and get published that way. > Isn't there a PDC call (pdc_chassis?) to do this? Not AFAICT. PDC_CHASSIS is documented in the pdc32.pdf found on http://www.parisc-linux.org/documentation.html But my gut feeling is parisc specific code could make some PDC_CHASSIS calls to set up "sysstat" field (eg initialize, shutdown, run states). Does anyone know if the chassis codes used by HPUX are published? It would be cool if parisc-linux used the same codes where possible... > Or is the heartbeat LED done by hardware? Code I've looked at before seems to all do it in software. grant Grant Grundler Unix Systems Enablement Lab +1.408.447.7253 From sanjak@tipas.lt Mon, 27 Nov 2000 09:09:22 +0200 Date: Mon, 27 Nov 2000 09:09:22 +0200 From: Aleksandr Konstantinov sanjak@tipas.lt Subject: [parisc-linux] how to boot ? Hello, All. We have two HP Workstations here (Model 735). I would like to try linux on one of them. But I have no disk space to install all the stuff (binutils, compiler, etc) . I found precompiled kernel on puffin.external.hp.com but it looks like I also need palo . Does anybody know, where to get precompiled palo for hpux9, hpux10 or linux-x86 ? Thanks in advance. A.K. From rhirst@linuxcare.com Mon, 27 Nov 2000 09:18:21 +0000 Date: Mon, 27 Nov 2000 09:18:21 +0000 From: Richard Hirst rhirst@linuxcare.com Subject: [parisc-linux] strace? Hi Dave, The source is in cvs on pehc; I can supply a binary if you want one. I havn't made serious use of it, but it does basically work. Richard On Fri, Nov 24, 2000 at 05:01:00PM -0500, Dave O'Neill wrote: > > So, I've heard rumours that somewhere there's a working strace for > parisc.... Can anyone point me in the right direction? > > Dave > -- > Dave O'Neill, Senior Linux Consultant, Linuxcare, Inc. > desk: (613) 562-9949 fax: (613) 562-9700 cell: (613) 223-0219 > doneill@linuxcare.com http://www.linuxcare.com/ > > --------------------------------------------------------------------------- > To unsubscribe: send e-mail to parisc-linux-request@thepuffingroup.com with > `unsubscribe' as the subject. > > From alan@lxorguk.ukuu.org.uk Mon, 27 Nov 2000 16:55:36 +0000 (GMT) Date: Mon, 27 Nov 2000 16:55:36 +0000 (GMT) From: Alan Cox alan@lxorguk.ukuu.org.uk Subject: [parisc-linux] RPM and hppa > I think the above is a different problem. The explosion is most likely > a problem with exception edges in the gcse pass. Try `-fno-gcse'. This > also appears in the tFile.cc libio test. I've not yet had a chance to try this. I see the same behaviour building Qt so I may try it on that From marteaut@esiee.fr Mon, 27 Nov 2000 18:11:36 +0000 Date: Mon, 27 Nov 2000 18:11:36 +0000 From: marteau marteaut@esiee.fr Subject: [parisc-linux] Hi all, We have tried to compile the new linux source today and vmlinux always needs pci.o to link. It works if you delete pci.o from the objects list in the kernel Makefile. But, we don't know why it was needed because we did not ask for in our "make config"... We appreciate any help! THX, ESIEE Team From dave@hiauly1.hia.nrc.ca Mon, 27 Nov 2000 12:13:02 -0500 (EST) Date: Mon, 27 Nov 2000 12:13:02 -0500 (EST) From: John David Anglin dave@hiauly1.hia.nrc.ca Subject: [parisc-linux] RPM and hppa > > > I think the above is a different problem. The explosion is most likely > > a problem with exception edges in the gcse pass. Try `-fno-gcse'. This > > also appears in the tFile.cc libio test. > > I've not yet had a chance to try this. I see the same behaviour building Qt > so I may try it on that Another option that might help if exceptions aren't needed is `-fno-exceptions'. Dave -- J. David Anglin dave.anglin@nrc.ca National Research Council of Canada (613) 990-0752 (FAX: 952-6605) From grundler@cup.hp.com Mon, 27 Nov 2000 09:57:39 -0800 Date: Mon, 27 Nov 2000 09:57:39 -0800 From: Grant Grundler grundler@cup.hp.com Subject: No subject marteau wrote: > We have tried to compile the new linux source today and vmlinux > always needs pci.o to link. It works if you delete pci.o from the > objects list in the kernel Makefile. But, we don't know why it was > needed because we did not ask for in our "make config"... Hi Thomas, The problem is in arch/parisc/kernel/Makefile. It doesn't use CONFIG_PCI to decide if pci.o is needed. I'll fix that now - should be simple. thanks, grant From dave@hiauly1.hia.nrc.ca Mon, 27 Nov 2000 13:19:52 -0500 (EST) Date: Mon, 27 Nov 2000 13:19:52 -0500 (EST) From: John David Anglin dave@hiauly1.hia.nrc.ca Subject: [parisc-linux] RPM and hppa > > I think the above is a different problem. The explosion is most likely > > a problem with exception edges in the gcse pass. Try `-fno-gcse'. This > > also appears in the tFile.cc libio test. > > I've not yet had a chance to try this. I see the same behaviour building Qt > so I may try it on that If the problem is in fact the exception handling method, I think we should look at implementing the DWARF2 unwind mechanism and exception handling using this unwind mechanism. The default method of handling exceptions is sjlj. See the description of DWARF2_UNWIND_INFO and INCOMING_RETURN_ADDR_RTX in gcc/tm.texi for more info. Alan Modra may want this for gdb as well. Dave -- J. David Anglin dave.anglin@nrc.ca National Research Council of Canada (613) 990-0752 (FAX: 952-6605) From alan@lxorguk.ukuu.org.uk Mon, 27 Nov 2000 18:34:23 +0000 (GMT) Date: Mon, 27 Nov 2000 18:34:23 +0000 (GMT) From: Alan Cox alan@lxorguk.ukuu.org.uk Subject: [parisc-linux] gcc crashes/out of memory and groff With groff -fno-gcse does not help but -O0 does. Without -O0 you get an internal error. g++ -I. -I/usr/src/redhat/BUILD/groff-1.16/src/roff/troff -I/usr/src/redhat/BUILD/groff-1.16/src/include -I/usr/src/redhat/BUILD/groff-1.16/src/include -DHAVE_UNISTD_H=1 -DHAVE_DIRENT_H=1 -DHAVE_LIMITS_H=1 -DHAVE_SYS_DIR_H=1 -DHAVE_STDLIB_H=1 -DHAVE_STRINGS_H=1 -DSTDLIB_H_DECLARES_PUTENV=1 -DSTDIO_H_DECLARES_POPEN=1 -DSTDIO_H_DECLARES_PCLOSE=1 -DHAVE_SYS_NERR=1 -DHAVE_SYS_ERRLIST=1 -DHAVE_CC_LIMITS_H=1 -DRETSIGTYPE=void -DHAVE_STRUCT_EXCEPTION=1 -DHAVE_UNISTD_H=1 -DHAVE_GETPAGESIZE=1 -DHAVE_MMAP=1 -DHAVE_FMOD=1 -DHAVE_STRTOL=1 -DHAVE_GETCWD=1 -DHAVE_STRERROR=1 -DHAVE_PUTENV=1 -DHAVE_RENAME=1 -DHAVE_MKSTEMP=1 -DHAVE_STRCASECMP=1 -DHAVE_STRSEP=1 -DHAVE_STRDUP=1 -DSYS_SIGLIST_DECLARED=1 -O2 -mpa-risc-1-0 -fno-gcse -c env.cc env.cc: In member function `void environment::output_line (node *, hunits)': env.cc:1582: Internal error: Segmentation fault. Please submit a full bug report. See for instructions. make[2]: *** [env.o] Error 1 make[2]: Leaving directory `/usr/src/redhat/BUILD/groff-1.16/src/roff/troff' Alan From marteaut@esiee.fr Mon, 27 Nov 2000 21:31:09 +0100 Date: Mon, 27 Nov 2000 21:31:09 +0100 From: Thomas Marteau marteaut@esiee.fr Subject: [parisc-linux] Include trouble Hi folks, Just to know if it is a local problem. We have this warning when we cross compile the kernel: /linux/cvs/linux/include/linux/string.h:61: warning: conflicting types for built-in function `memset' /linux/cvs/linux/include/linux/string.h:64: warning: conflicting types for built-in function `memcpy' /linux/cvs/linux/include/linux/string.h:73: warning: conflicting types for built-in function `memcmp' Can we have your point of view? Bye, ESIEE Team From marteaut@esiee.fr Tue, 28 Nov 2000 00:17:24 +0100 Date: Tue, 28 Nov 2000 00:17:24 +0100 From: Thomas Marteau marteaut@esiee.fr Subject: [parisc-linux] Leds Hi all, We tried to implement the led power of 712 hp boxes. We call leds_init in main.c in init directory. Even though it is working, we are not sure where to put the source that must be completed for others models. We could make a LEDS directory in drivers put the file in the kernel directory We also put the source for the initialisation of keyboard leds in lasi_ps2_reset but we admit that no led is on. Is it true? How can we know? THX, ESIEE Team From alan@linuxcare.com.au Tue, 28 Nov 2000 12:12:03 +1100 (EST) Date: Tue, 28 Nov 2000 12:12:03 +1100 (EST) From: Alan Modra alan@linuxcare.com.au Subject: [parisc-linux] gcc crashes/out of memory and groff On Mon, 27 Nov 2000, Alan Cox wrote: > With groff -fno-gcse does not help but -O0 does. Without -O0 you get an > internal error. Cross compiling from an x86-linux box with enough memory+swap (256M + 2G), env.cc eventually compiled for me using the default -O2 optimisation level. I had a crash later when compiling preproc/tbl/table.cc, so that's nothing to boast about. table.cc: In member function `void table::build_span_list ()': table.cc:2009: Internal error: Segmentation fault. Worse, when I added "-Q -da" to see what was happening, the compile succeeded - and also succeeded with either of -Q or -da alone. So I ran cc1plus under gdb, and that too failed to crash. :-( Maybe a garbage collection or uninitialised var bug? Alan Modra -- Linuxcare. Support for the Revolution. From alan@linuxcare.com.au Tue, 28 Nov 2000 15:59:54 +1100 (EST) Date: Tue, 28 Nov 2000 15:59:54 +1100 (EST) From: Alan Modra alan@linuxcare.com.au Subject: [parisc-linux] Include trouble On Mon, 27 Nov 2000, Thomas Marteau wrote: > Can we have your point of view? Your version of gcc expects the size_t parameter to all these functions to be "unsigned int", whereas the 2000/11/18 changes to linux/include/asm-parisc/posix_types.h made __kernel_size_t "unsigned long". As far as I understand, gcc's cpp has a built-in definition of size_t, __SIZE_TYPE__, and it ultimately gets it's idea of the definition from the kernel includes on the machine where gcc was compiled. ie. recompile gcc with the new kernel headers installed, and the problem should go away. For 32-bit hppa-linux, sizeof(int) == sizeof(long) so there shouldn't be any practical consequence other than these warning messages. There might be some "interesting" problems on hppa64-linux - I'm not sure. Alan Modra -- Linuxcare. Support for the Revolution. From alan@linuxcare.com.au Tue, 28 Nov 2000 20:19:20 +1100 (EST) Date: Tue, 28 Nov 2000 20:19:20 +1100 (EST) From: Alan Modra alan@linuxcare.com.au Subject: [parisc-linux] Include trouble On Tue, 28 Nov 2000, Alan Modra wrote: > As far as I understand, gcc's cpp has a built-in definition of size_t, > __SIZE_TYPE__, and it ultimately gets it's idea of the definition from the > kernel includes on the machine where gcc was compiled. ie. recompile gcc > with the new kernel headers installed, and the problem should go away. No, that's wrong. __SIZE_TYPE__ comes from `#define SIZE_TYPE' in gcc/config/pa/pa-linux{,64}.h I'll check in a patch to gcc in a few moments. Alan -- Linuxcare. Support for the Revolution. From marteaut@esiee.fr Tue, 28 Nov 2000 16:07:04 +0100 Date: Tue, 28 Nov 2000 16:07:04 +0100 From: Thomas Marteau marteaut@esiee.fr Subject: [parisc-linux] Mouse driver for PS/2 Hi all, We appreciate if someone can explain where we can find request_irq and request_region in hp_psaux.c and also, what are they doing? Thanks, ESIEE Team From deller@gmx.de Tue, 28 Nov 2000 18:21:34 +0100 Date: Tue, 28 Nov 2000 18:21:34 +0100 From: Helge Deller deller@gmx.de Subject: [parisc-linux] Mouse driver for PS/2 On Tuesday 28 November 2000 16:07, Thomas Marteau wrote: > Hi all, Hi Thomas, > > We appreciate if someone can explain where we can find request_irq #include and /arch/parisc/kernel/irq.c request_irq() binds the given interrupt-number to a function (if possible). > and > request_region #include request_region only marks (and tests) an I/O-region as used by a driver and makes this information visible via /proc/iomem and /proc/ioports. > in hp_psaux.c and also, > what are they doing? > > Thanks, > ESIEE Team From wferguson@server01.chatspace.com Tue, 28 Nov 2000 09:35:36 -0800 Date: Tue, 28 Nov 2000 09:35:36 -0800 From: William Ferguson wferguson@server01.chatspace.com Subject: [parisc-linux] PDC firmware revision FAQ update This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C05961.9E1AB8A8 Content-Type: text/plain; charset="iso-8859-1" Is the web server at www.parisc-linux.org down? Can't seem to connect from San Diego. -----Original Message----- From: Grant Grundler [mailto:grundler@cup.hp.com] Sent: Friday, November 17, 2000 1:51 PM To: parisc-linux@puffin.external.hp.com Subject: [parisc-linux] PDC firmware revision FAQ update Hi folks, The issue of PDC/firmware revs came up locally and sounded like a FAQ. I added "10. How can I check if the PDC (firmware) revision is the latest?" and what I knew/could find to our FAQ at: http://www.parisc-linux.org/faq.html The new FAQ entry should be visible to the world in the next hour or so. **** WARNING **** Firmware upgrades can *kill* your machine! **** WARNING **** Don't do it just because. Read the FAQ carefully. Take the time to figure out why you might need the upgrade and expose yourself to this risk. grant ps. please don't ask me why your favorite machine's PDC isn't listed. I don't run the referenced sites. --------------------------------------------------------------------------- To unsubscribe: send e-mail to parisc-linux-request@thepuffingroup.com with `unsubscribe' as the subject. ------_=_NextPart_001_01C05961.9E1AB8A8 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [parisc-linux] PDC firmware revision FAQ update

Is the web server at www.parisc-linux.org down?  = Can't seem to connect from San Diego.

-----Original Message-----
From: Grant Grundler [mailto:grundler@cup.hp.com]
Sent: Friday, November 17, 2000 1:51 PM
To: parisc-linux@puffin.external.hp.com
Subject: [parisc-linux] PDC firmware revision FAQ = update


Hi folks,

The issue of PDC/firmware revs came up locally and = sounded like a FAQ.
I added

    "10. How can I check if the = PDC (firmware) revision is the latest?"

and what I knew/could find to our FAQ at:

        http://www.parisc-linux.org/faq.html

The new FAQ entry should be visible to the world in = the next hour or so.


    **** WARNING ****
    Firmware upgrades can *kill* your = machine!
    **** WARNING ****

Don't do it just because. Read the FAQ carefully. = Take the
time to figure out why you might need the upgrade = and expose
yourself to this risk.

grant

ps. please don't ask me why your favorite machine's = PDC isn't listed.
   I don't run the referenced = sites.

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

------_=_NextPart_001_01C05961.9E1AB8A8-- From dave@hiauly1.hia.nrc.ca Tue, 28 Nov 2000 12:37:28 -0500 (EST) Date: Tue, 28 Nov 2000 12:37:28 -0500 (EST) From: John David Anglin dave@hiauly1.hia.nrc.ca Subject: [parisc-linux] Include trouble > On Tue, 28 Nov 2000, Alan Modra wrote: > > > As far as I understand, gcc's cpp has a built-in definition of size_t, > > __SIZE_TYPE__, and it ultimately gets it's idea of the definition from the > > kernel includes on the machine where gcc was compiled. ie. recompile gcc > > with the new kernel headers installed, and the problem should go away. > > No, that's wrong. __SIZE_TYPE__ comes from `#define SIZE_TYPE' in > gcc/config/pa/pa-linux{,64}.h I'll check in a patch to gcc in a few > moments. Hmm. Most 32 bit systems use "unsigned int" rather than "unsigned long". Using "unsigned long" might cause problems with packages like libio. I know there is a problem if off_t is not the same as size_t. Dave -- J. David Anglin dave.anglin@nrc.ca National Research Council of Canada (613) 990-0752 (FAX: 952-6605) From grundler@cup.hp.com Tue, 28 Nov 2000 09:49:26 -0800 Date: Tue, 28 Nov 2000 09:49:26 -0800 From: Grant Grundler grundler@cup.hp.com Subject: [parisc-linux] Mouse driver for PS/2 Thomas Marteau wrote: > Hi all, > > We appreciate if someone can explain where we can find request_irq and > request_region in hp_psaux.c and also, what are they doing? include/linux/sched.h:extern int request_irq(unsigned int, ...) (Implementation is in arch/parisc/kernel/irq.c) The request_irq() "allocates" an IRQ line for use by the device - this program the PIC (or APIC) on x86 platforms. request_irq() is also how an interrupt handler is associated with a specific IRQ line. Since PA Risc CPU's don't have IRQ lines going into them, IRQ's are virtualized and don't always represent a physical IRQ line. Under LASI, see gsc_alloc_irq(&gsc_irq) usage in drivers/gsc/lasi.c. lasi_find_irq() helps associate the PS/2 interrupt handler with the correct IRQ line which is internal to lasi. include/linux/ioport.h:#define request_region(start,n,name) ... request_region() will reserve a range of I/O port address from the global I/O space. request_mem_region() does the same for MMIO. Drivers that use inb/outb (as defined in include/asm-parisc/io.h) must use request_region(). Drivers that use gsc_readb/gsc_writeb (as defined in include/asm-parisc/gsc.h) must use request_mem_region(). Collisions are probably occuring where a driver originally used inb/outb and those were redefined to use gsc_readb/writeb functions. But the driver is still using request_region(). And it doesn't help that I may have broken some of the resource mgt with some code I committed last night. It worked on my boxes (A180/C3K) but broke on other folks. Paul Bame helped find/fix one bug but I shouldn't be surprised if more bugs are still out there. I will be fixing some known resource failure problems on A500. Please post problems on other platforms to parisc-linux list as well. hope this helps, grant Grant Grundler Unix Systems Enablement Lab +1.408.447.7253 From grundler@cup.hp.com Tue, 28 Nov 2000 09:53:37 -0800 Date: Tue, 28 Nov 2000 09:53:37 -0800 From: Grant Grundler grundler@cup.hp.com Subject: [parisc-linux] PDC firmware revision FAQ update William Ferguson wrote: > Is the web server at www.parisc-linux.org down? Can't seem to connect from > San Diego. Yes. Linuxcare is having some DNS problems right now and they host that site. Any forecasts on when that will be back up? grant From bame@noam.fc.hp.com Tue, 28 Nov 2000 12:27:09 -0700 Date: Tue, 28 Nov 2000 12:27:09 -0700 From: Paul Bame bame@noam.fc.hp.com Subject: [parisc-linux] Include trouble = Hmm. Most 32 bit systems use "unsigned int" rather than "unsigned long". I will be happy to change it back to unsigned int. The only reason I used unsigned long is because it seems off_t wants to be, to a first approximation, the word length of the machine, and 'long' does that. = Using "unsigned long" might cause problems with packages like libio. = I know there is a problem if off_t is not the same as size_t. What problem is that? I'm working on a proposal for the palinux type sizes at the moment. One dilema is that off_t is supposed to be good for file offsets, which these days means it should be 64 bits. size_t refers to the sizes of objects which are expected to fit in RAM, so should be the word size of the machine. So there's a conflict because one logic suggests 64-bit off_t and 32-bit size_t on 32-bit palinux, but your statement suggests they should be the same size. Any ideas? However I'm leaning towards leaning with the older 32-bit off_t because we might not want to be the first ones to fix all the problems with making it 64 bits on a 32-bit machine. -P From marteaut@esiee.fr Tue, 28 Nov 2000 20:30:30 +0100 Date: Tue, 28 Nov 2000 20:30:30 +0100 From: Thomas Marteau marteaut@esiee.fr Subject: [parisc-linux] Mouse driver for PS/2 Hi all, We have a sample of code for the mouse driver. But, we would like to know how the Puffin would like the implementation of the driver. Because of drag & drop..., do you want two different interrupt functions or a single that does a redirection. Also , we have seen that busmouse.c is quite interesting for our driver. Do we make a copy and call it hp_mouse.c? Thanks for your answer, ESIEE Team For a better future with a mouse! From alan@lxorguk.ukuu.org.uk Tue, 28 Nov 2000 20:02:26 +0000 (GMT) Date: Tue, 28 Nov 2000 20:02:26 +0000 (GMT) From: Alan Cox alan@lxorguk.ukuu.org.uk Subject: [parisc-linux] Include trouble > One dilema is that off_t is supposed to > be good for file offsets, which these days means it should be 64 bits. off_t should be a natural type. So it should be 32bits. glibc 2.2 deals with the 64bit I/O stuff nicely > However I'm leaning towards leaning with the older 32-bit off_t because > we might not want to be the first ones to fix all the problems with > making it 64 bits on a 32-bit machine. Go 32bit. Linus will probably refuse to touch a 32bit port using longlong internally for off-t From dave@hiauly1.hia.nrc.ca Tue, 28 Nov 2000 15:24:26 -0500 (EST) Date: Tue, 28 Nov 2000 15:24:26 -0500 (EST) From: John David Anglin dave@hiauly1.hia.nrc.ca Subject: [parisc-linux] Include trouble > = Hmm. Most 32 bit systems use "unsigned int" rather than "unsigned long". > > I will be happy to change it back to unsigned int. The only reason > I used unsigned long is because it seems off_t wants to be, to a > first approximation, the word length of the machine, and 'long' does > that. Agreed. > = Using "unsigned long" might cause problems with packages like libio. > > > = I know there is a problem if off_t is not the same as size_t. > > What problem is that? I'm working on a proposal for the palinux > type sizes at the moment. It is simply dumb coding that hasn't been fixed. There are inconsistencies between the interface declarations and implementations. The old libio is on the way out. > One dilema is that off_t is supposed to > be good for file offsets, which these days means it should be 64 bits. > size_t refers to the sizes of objects which are expected to fit in > RAM, so should be the word size of the machine. So there's a conflict > because one logic suggests 64-bit off_t and 32-bit size_t on 32-bit palinux, > but your statement suggests they should be the same size. Any ideas? Only, because of poorly written legacy code. I agree that off_t should be 64 bits on 32 bit platforms today. > However I'm leaning towards leaning with the older 32-bit off_t because > we might not want to be the first ones to fix all the problems with > making it 64 bits on a 32-bit machine. Maybe it isn't that bad because I noticed at least one port used unsigned long long for off_t. Dave -- J. David Anglin dave.anglin@nrc.ca National Research Council of Canada (613) 990-0752 (FAX: 952-6605) From dave@hiauly1.hia.nrc.ca Tue, 28 Nov 2000 15:33:52 -0500 (EST) Date: Tue, 28 Nov 2000 15:33:52 -0500 (EST) From: John David Anglin dave@hiauly1.hia.nrc.ca Subject: [parisc-linux] Include trouble > Maybe it isn't that bad because I noticed at least one port used unsigned > long long for off_t. Take that back. It was __kernel_loff_t. Just go with typedef unsigned int __kernel_size_t; typedef long __kernel_off_t; #ifdef __GNUC__ typedef long long __kernel_loff_t; #endif for the 32 bit port. Dave -- J. David Anglin dave.anglin@nrc.ca National Research Council of Canada (613) 990-0752 (FAX: 952-6605) From deller@gmx.de Tue, 28 Nov 2000 21:41:53 +0100 Date: Tue, 28 Nov 2000 21:41:53 +0100 From: Helge Deller deller@gmx.de Subject: [parisc-linux] Mouse driver for PS/2 On Tuesday 28 November 2000 20:30, Thomas Marteau wrote: > Hi all, Hi Thomas, > > We have a sample of code for the mouse driver. But, we would like to > know how the Puffin would like the implementation of the driver. Because > of drag & drop..., do you want two different interrupt functions or a > single that does a redirection. Also , we have seen that busmouse.c is > quite interesting for our driver. Do we make a copy and call it > hp_mouse.c? I would propose, that you check in hp_mouse.c and use different interrupt functions for now. Changing it later shouldn't be too difficult. Greetings, Helge. > > Thanks for your answer, > ESIEE Team > For a better future with a mouse! From doneill@linuxcare.com Tue, 28 Nov 2000 16:08:49 -0500 (EST) Date: Tue, 28 Nov 2000 16:08:49 -0500 (EST) From: Dave O'Neill doneill@linuxcare.com Subject: [parisc-linux] PDC firmware revision FAQ update On Tue, 28 Nov 2000, Grant Grundler wrote: > Yes. Linuxcare is having some DNS problems right now and > they host that site. Any forecasts on when that will be back up? Well, it looks like our DNS issues are fixed... the site should be accessible now. Dave -- Dave O'Neill, Senior Linux Consultant, Linuxcare, Inc. desk: (613) 562-9949 fax: (613) 562-9700 cell: (613) 223-0219 doneill@linuxcare.com http://www.linuxcare.com/ From bame@noam.fc.hp.com Tue, 28 Nov 2000 14:21:05 -0700 Date: Tue, 28 Nov 2000 14:21:05 -0700 From: Paul Bame bame@noam.fc.hp.com Subject: [parisc-linux] Include trouble = Go 32bit. Linus will probably refuse to touch a 32bit port using longlong = internally for off-t Hmmm, too bad, since we have few palinux backwards compatibility issues and could just have the __USE_FILE_OFFSET64 glibc magic be a no-op rather than supporting all those extra *64 syscalls. Plus we'd need considerably fewer syscall translators to run 32-bit apps on 64-bit kernel (but might need more for 32-bit hpux apps). It seems illogical to make a file-system-related data type different based on cpu word size but I understand this isn't simple -- oh well. Seems like the consensus is 32-bit off_t on 32-bit kernel and just live with all those *64 syscalls -- many not supported on palinux yet I notice. -P From alan@lxorguk.ukuu.org.uk Tue, 28 Nov 2000 21:58:56 +0000 (GMT) Date: Tue, 28 Nov 2000 21:58:56 +0000 (GMT) From: Alan Cox alan@lxorguk.ukuu.org.uk Subject: [parisc-linux] Include trouble > Seems like the consensus is 32-bit off_t on 32-bit kernel and just > live with all those *64 syscalls -- many not supported on palinux > yet I notice. Remember providing you use off_t you can just tell glibc to do all the work for you and write with a 64bit off_t to userspace From alan@linuxcare.com.au Wed, 29 Nov 2000 10:27:20 +1100 (EST) Date: Wed, 29 Nov 2000 10:27:20 +1100 (EST) From: Alan Modra alan@linuxcare.com.au Subject: [parisc-linux] Include trouble On Tue, 28 Nov 2000, John David Anglin wrote: > Hmm. Most 32 bit systems use "unsigned int" rather than "unsigned long". There's some precedent for using "unsigned long", as that is what is used on 32-bit hpux11 and osf gcc targets. current sourceware CVS gcc/config/pa/: $ grep SIZE_TYPE * grep: CVS: Is a directory pa-64.h:#undef SIZE_TYPE pa-64.h:#define SIZE_TYPE "long unsigned int" pa-hpux.h:#undef SIZE_TYPE pa-hpux.h:#define SIZE_TYPE "unsigned int" pa-hpux11.h:#undef SIZE_TYPE pa-hpux11.h:#define SIZE_TYPE "long unsigned int" pa-hpux7.h:#undef SIZE_TYPE pa-hpux7.h:#define SIZE_TYPE "unsigned int" pa-linux.h:#undef SIZE_TYPE pa-linux.h:#define SIZE_TYPE "unsigned int" pa-osf.h:#undef SIZE_TYPE pa-osf.h:#define SIZE_TYPE "long unsigned int" pa-pro-end.h:#undef SIZE_TYPE pa-pro-end.h:#define SIZE_TYPE "unsigned int" pa.h:#define SIZE_TYPE "unsigned int" Some further grepping shows quite a number of other 32-bit gcc targets using "unsigned long", but I didn't see any 32-bit linux targets in the list. Paul, If you change back to "unsigned int", please change gcc/config/pa/pa-linux.h too. Alan -- Linuxcare. Support for the Revolution. From Frank.Butter@otto.de Wed, 29 Nov 2000 11:50:39 +0100 Date: Wed, 29 Nov 2000 11:50:39 +0100 From: Butter, Frank Frank.Butter@otto.de Subject: [parisc-linux] hardware to all here I was annaouncing an offer for hp hardware recently: it'll take longer than initially expected to convince our bosses ;-/ please stay patient... frank From matthias@archimed.math.uni-mannheim.de Wed, 29 Nov 2000 20:52:38 +0100 (MET) Date: Wed, 29 Nov 2000 20:52:38 +0100 (MET) From: Matthias Juchem matthias@archimed.math.uni-mannheim.de Subject: [parisc-linux] parisc-0.5.iso and stack trace Hi there. I've just downloaded the ISO images and tried to boot an 9000/705. I keep getting a stack trace. Can you tell me which part of the trace I can send you so that you could eventually tell me what is wrong? TIA, Matthias From dave@hiauly1.hia.nrc.ca Wed, 29 Nov 2000 17:05:31 -0500 (EST) Date: Wed, 29 Nov 2000 17:05:31 -0500 (EST) From: John David Anglin dave@hiauly1.hia.nrc.ca Subject: [parisc-linux] gcc crashes/out of memory and groff > With groff -fno-gcse does not help but -O0 does. Without -O0 you get an > internal error. > > g++ -I. -I/usr/src/redhat/BUILD/groff-1.16/src/roff/troff -I/usr/src/redhat/BUILD/groff-1.16/src/include -I/usr/src/redhat/BUILD/groff-1.16/src/include -DHAVE_UNISTD_H=1 -DHAVE_DIRENT_H=1 -DHAVE_LIMITS_H=1 -DHAVE_SYS_DIR_H=1 -DHAVE_STDLIB_H=1 -DHAVE_STRINGS_H=1 -DSTDLIB_H_DECLARES_PUTENV=1 -DSTDIO_H_DECLARES_POPEN=1 -DSTDIO_H_DECLARES_PCLOSE=1 -DHAVE_SYS_NERR=1 -DHAVE_SYS_ERRLIST=1 -DHAVE_CC_LIMITS_H=1 -DRETSIGTYPE=void -DHAVE_STRUCT_EXCEPTION=1 -DHAVE_UNISTD_H=1 -DHAVE_GETPAGESIZE=1 -DHAVE_MMAP=1 -DHAVE_FMOD=1 -DHAVE_STRTOL=1 -DHAVE_GETCWD=1 -DHAVE_STRERROR=1 -DHAVE_PUTENV=1 -DHAVE_RENAME=1 -DHAVE_MKSTEMP=1 -DHAVE_STRCASECMP=1 -DHAVE_STRSEP=1 -DHAVE_STRDUP=1 -DSYS_SIGLIST_DECLARED=1 -O2 -mpa-risc-1-0 -fno-gcse -c env.cc > env.cc: In member function `void environment::output_line (node *, hunits)': > env.cc:1582: Internal error: Segmentation fault. > Please submit a full bug report. > See for instructions. > make[2]: *** [env.o] Error 1 > make[2]: Leaving directory `/usr/src/redhat/BUILD/groff-1.16/src/roff/troff' This error is also exception related but appears different from the memory explosion. It occurs in scan_region in except.c. The memory explosion that occurs without -fno-gcse does seem to occur in the gcse pass as I suspected. I need to rebuild gcc with debugging to get further. I was able to build the groff package with `CXXFLAGS="-O3 -fno-exceptions"'. Dave -- J. David Anglin dave.anglin@nrc.ca National Research Council of Canada (613) 990-0752 (FAX: 952-6605) From delyra@latt.if.usp.br Wed, 29 Nov 2000 20:22:47 -0200 (BRST) Date: Wed, 29 Nov 2000 20:22:47 -0200 (BRST) From: Jorge L. deLyra delyra@latt.if.usp.br Subject: [parisc-linux] HP 9000/735-125 I just booted the palinux-0.5.iso CD on a HP 9000 model 735 workstation. It went on quite a bit before hanging immediatelly after reporting the serial ports. Gave large amount of what looks like traceback or state information. Question: would it do anyone any good if I tried to get everything the kernel said before the hang into a message in this list? Cheers, ---------------------------------------------------------------- Jorge L. deLyra, Associate Professor of Physics The University of Sao Paulo, IFUSP-DFMA For more information: finger delyra@latt.if.usp.br ---------------------------------------------------------------- From grundler@cup.hp.com Wed, 29 Nov 2000 15:19:10 -0800 Date: Wed, 29 Nov 2000 15:19:10 -0800 From: Grant Grundler grundler@cup.hp.com Subject: [parisc-linux] HP 9000/735-125 "Jorge L. deLyra" wrote: > I just booted the palinux-0.5.iso CD on a HP 9000 model 735 workstation. > It went on quite a bit before hanging immediatelly after reporting the > serial ports. Gave large amount of what looks like traceback or state > information. Question: would it do anyone any good if I tried to get > everything the kernel said before the hang into a message in this list? Certainly. I won't be able to debug the problems since I (a) don't have the time too (unless it's obvious) and (b) don't have a 735 setup for testing. This is becoming a FAQ: "My system crashed after ... What should I do next?" I'm thinking people in the support space would know how to write this one really well :^) Is I get one in the mail, I'll add it to our FAQ. thanks, grant Grant Grundler Unix Systems Enablement Lab +1.408.447.7253 From smoret@uci.edu Wed, 29 Nov 2000 15:28:20 -0800 Date: Wed, 29 Nov 2000 15:28:20 -0800 From: Steve Moret smoret@uci.edu Subject: [parisc-linux] HP 9000/735-125 Jorge, I have a 735-125 and am able to net-boot it on a custom configured kernel as long as I disable the ASP parallel ports. It works quite well using an NFS root as I cannot get the SCSI hard drives to mkfs. I was going to try and debug it but have yet to find the free time. I can e-mail you my working .config for the kernel, or build kernels (tested on my own 735) for people if they need them. -- Steve Moret smoret@uci.edu > -----Original Message----- > From: Grant Grundler [mailto:grundler@cup.hp.com] > Sent: Wednesday, November 29, 2000 3:19 PM > To: Jorge L. deLyra > Cc: parisc-linux@thepuffingroup.com > Subject: Re: [parisc-linux] HP 9000/735-125 > > > "Jorge L. deLyra" wrote: > > I just booted the palinux-0.5.iso CD on a HP 9000 model 735 workstation. > > It went on quite a bit before hanging immediatelly after reporting the > > serial ports. Gave large amount of what looks like traceback or state > > information. Question: would it do anyone any good if I tried to get > > everything the kernel said before the hang into a message in this list? > > Certainly. I won't be able to debug the problems since I (a) don't have > the time too (unless it's obvious) and (b) don't have a 735 setup > for testing. > > This is becoming a FAQ: > "My system crashed after ... What should I do next?" > > I'm thinking people in the support space would know how to write > this one really well :^) > Is I get one in the mail, I'll add it to our FAQ. > > thanks, > grant > > > Grant Grundler > Unix Systems Enablement Lab > +1.408.447.7253 > > ------------------------------------------------------------------ > --------- > To unsubscribe: send e-mail to > parisc-linux-request@thepuffingroup.com with > `unsubscribe' as the subject. > > From deller@gmx.de Thu, 30 Nov 2000 01:10:51 +0100 Date: Thu, 30 Nov 2000 01:10:51 +0100 From: Helge Deller deller@gmx.de Subject: [parisc-linux] HP 9000/735-125 X On Thursday 30 November 2000 00:28, Steve Moret wrote: > I have a 735-125 and am able to net-boot it on a custom configured kernel > as long as I disable the ASP parallel ports. .... Steve, I really would like to get the parallel-port problems on ASP get fixed as soon as possible. Could you please mail me your bootlog (with parport enabled), so I can try to track down the problem. Maybe you can also check out CVS again, and test if this version works for you ? Thanks, Helge Deller From alan@lxorguk.ukuu.org.uk Thu, 30 Nov 2000 02:38:56 +0000 (GMT) Date: Thu, 30 Nov 2000 02:38:56 +0000 (GMT) From: Alan Cox alan@lxorguk.ukuu.org.uk Subject: [parisc-linux] XFree status I have a server linked. inb/inw/outb/outw and friends are right now null functions until I fill them in. Thats not a big deal. Initially I'll probably use /dev/port but for speed I hope everyone uses mmio based hardware. Also is this bad ? /usr/bin/ld: lbxdix.o(.text+0x6fc): fixing R_PARISC_DPREL21L /usr/bin/ld: lbxprop.o(.text+0xde4): fixing R_PARISC_DPREL21L /usr/bin/ld: lbxprop.o(.text+0xdf4): fixing R_PARISC_DPREL21L Alan phux:/usr/src/redhat/BUILD/XFree86-4.0.1/xc/programs/Xserver# ./XFree86 XFree86 Version 4.0.1a / X Window System (protocol Version 11, revision 0, vendor release 6400) Release Date: 2 August 2000 If the server is older than 6-12 months, or if your card is newer than the above date, look for a newer version before reporting problems. (see http://www.XFree86.Org/FAQ) Operating System: Linux 2.4.0-test6 parisc [ELF] (==) Log file: "/var/log/XFree86.0.log", Time: Wed Nov 29 19:40:16 2000 (==) Using config file: "/etc/X11/XF86Config" Parse warning on line 77 of section Keyboard in file /etc/X11/XF86Config Ignoring obsolete keyword "LeftAlt". Parse error on line 77 of section Keyboard in file /etc/X11/XF86Config "Meta" is not a valid keyword in this section. (EE) Problem parsing the config file (EE) Error from xf86HandleConfigFile() Fatal server error: no screens found When reporting a problem related to a server crash, please send the full server output, not just the last messages. This can be found in the log file "/var/log/XFree86.0.log". Please reports problems to xfree86@xfree86.org. From alan@linuxcare.com.au Thu, 30 Nov 2000 14:41:48 +1100 (EST) Date: Thu, 30 Nov 2000 14:41:48 +1100 (EST) From: Alan Modra alan@linuxcare.com.au Subject: [parisc-linux] XFree status On Thu, 30 Nov 2000, Alan Cox wrote: > Also is this bad ? > > /usr/bin/ld: lbxdix.o(.text+0x6fc): fixing R_PARISC_DPREL21L No. It's a symptom of a variable's "constness" being declared differently from the way the variable is defined. For instance, referring to "extern int foo" in one object with foo defined as "const int foo" in another. I'll be removing the linker warning at some stage. Alan Modra -- Linuxcare. Support for the Revolution. From grundler@cup.hp.com Wed, 29 Nov 2000 21:18:14 -0800 Date: Wed, 29 Nov 2000 21:18:14 -0800 From: Grant Grundler grundler@cup.hp.com Subject: [parisc-linux] XFree status Alan Cox wrote: > I have a server linked. Alan - that's Cool! Wow! > inb/inw/outb/outw and friends are right now null > functions until I fill them in. Thats not a big deal. Initially I'll probably > use /dev/port but for speed I hope everyone uses mmio based hardware. All HP graphics for PARISC are memory mapped. Both "GSC" and PCI flavors. But I'm pretty clueless how linux X server finds/talks to a frame buffer. For HPUX, the graphics driver supports some ioctl()'s. Any references to describe how it works for linux? parisc-linux doesn't create kernel virtual addresses for MMIO. Which interface is used to create user virtual addresses for MMIO? (In general - not just for frame buffers) Is the PCI address passed to user space? I'm wondering if/how "bus_to_virt()" type translations take place. sorry for the many questions... grant Grant Grundler Unix Systems Enablement Lab +1.408.447.7253 From gibreel@pobox.com 30 Nov 2000 00:09:03 -0800 Date: 30 Nov 2000 00:09:03 -0800 From: Stephen Zander gibreel@pobox.com Subject: [parisc-linux] CVS linux Vs. -test10 >>>>> "Grant" == Grant Grundler writes: Grant> For the record, the second issue bdale made clear was we Grant> need "boot floppies" debian package working. We don't need Grant> more ISO images (no offense to pjlahaie for his good Grant> work). "Boot floppies" is a pre-requisite to becoming part Grant> of the next debian release. Given I still don't have a clue Grant> how to build a debian package and I can still contribute Grant> alot in other areas, it doesn't make sense for me to do it Grant> myself. Oooh, there's a reason for me to finally get the 712/80 under my desk to be more than a foot-rest. I'll see what I can do about this. Note that the likelihood of Debian releasing woody anytime soon is vanishingly small, so this dosen't have to happen Right Now. -- Stephen (debian developer) "Strange women lying in ponds distributing swords is no basis for a system of government" From smoret@uci.edu Thu, 30 Nov 2000 01:20:28 -0800 Date: Thu, 30 Nov 2000 01:20:28 -0800 From: Steve Moret smoret@uci.edu Subject: [parisc-linux] HP 9000/735-125 Helge, My mistake! I did a full build with todays CVS and parport didn't die. So somewhere between the 17th and now parport must have been fixed. Now, maybe you can help me identify my SCSI problem. I don't know if it is because of driver issues or a bad disk (completly likely). Do other people have the Fast SCSI2 working on their 735s? Whenever I do a mke2fs (after partitioning the drive with fdisk ok) it dies. At bootup I get: SCSI subsystem driver Revision: 1.00 sim700: Couldn't get consistent shared memory sim700: Configuring 53c700 (SCSI-ID 7) at f0825100, IRQ 86 scsi0: Revision 0x0 Post test1, istat 05, sstat0 00, dstat 84 sim700: WARNING IRQ probe failed, (returned 0) scsi0: WARNING: target data areas are not dma coherent! scsi0: test 1 completed ok. scsi0: sim700_intr_handle() called with no interrupt scsi0 : LASI/Simple 53c7xx Vendor: HP Model: C2235 Rev: 0B11 Type: Direct-Access ANSI SCSI revision: 02 Vendor: HP Model: C2235 Rev: 0B11 Type: Direct-Access ANSI SCSI revision: 02 Detected scsi disk sda at scsi0, channel 0, id 5, lun 0 Detected scsi disk sdb at scsi0, channel 0, id 6, lun 0 SCSI device sda: 825012 512-byte hdwr sectors (422 MB) Partition check: sda: sda1 sda2 SCSI device sdb: 825012 512-byte hdwr sectors (422 MB) sdb: sdb1 sdb2 And then if I try to mke2fs the disk I get: hp735:~# fdisk -l /dev/sda Disk /dev/sda: 13 heads, 62 sectors, 1023 cylinders Units = cylinders of 806 * 512 bytes Device Boot Start End Blocks Id System /dev/sda1 1 910 366699 83 Linux /dev/sda2 911 1023 45539 82 Linux swap hp735:~# mke2fs /dev/sda1 mke2fs 1.19, 13-Jul-2000 for EXT2 FS 0.5b, 95/08/09 Filesystem label= OS type: Linux Block size=1024 (log=0) Fragment size=1024 (log=0) 91800 inodes, 366699 blocks 18334 blocks (5.00%) reserved for the super user First data block=1 45 block groups 8192 blocks per group, 8192 fragments per group 2040 inodes per group Superblock backups stored on blocks: 8193, 24577, 40961, 57345, 73729, 204801, 221185 Writing inode tables: done Writing superblocks and filesystem accounting information: scsi0: Unable to abort command for target 5 scsi0: Unable to send Bus Device Reset for target 5 scsi0: Unable to do SCSI bus reset scsi0: >>>>>>>>>>>> Host reset <<<<<<<<<<<< scsi0: istat = 0c, sstat0 = 00, sstat1 = 00, dstat = 00 scsi0: dsp = 0cf15038 (script[0x140e]), dsps = 0cf15cde, target = 0 scsi0: Failing command for ID5 scsi0: sim700_intr_handle() called with no interrupt pa11_dma_map_single(PCI_DMA_NONE) called by c01cb6d4 kernel BUG at pci-dma.c:392! pa11_dma_unmap_single(PCI_DMA_NONE) called by c01ca3bc kernel BUG at pci-dma.c:403! SCSI disk error : host 0 channel 0 id 5 lun 0 return code = 2 I/O error: dev 08:01, sector 268 I/O error: dev 08:01, sector 270 I/O error: dev 08:01, sector 396 I/O error: dev 08:01, sector 16396 I/O error: dev 08:01, sector 16524 I/O error: dev 08:01, sector 16652 Of course the I/O errors continue on for a long time. Are these bad drives? Or is there a problem with the driver that still needs to be worked out? Thanks for all your help, I hope my spews of debug output are helpful, -- Steve Moret smoret@uci.edu > -----Original Message----- > From: Helge Deller [mailto:deller@gmx.de] > Sent: Wednesday, November 29, 2000 4:11 PM > To: Steve Moret > Cc: parisc-linux@thepuffingroup.com > Subject: Re: [parisc-linux] HP 9000/735-125 > > I really would like to get the parallel-port problems on ASP get fixed as > soon as possible. > Could you please mail me your bootlog (with parport enabled), so > I can try to > track down the problem. > Maybe you can also check out CVS again, and test if this version > works for > you ? From delyra@latt.if.usp.br Thu, 30 Nov 2000 08:58:22 -0200 (BRST) Date: Thu, 30 Nov 2000 08:58:22 -0200 (BRST) From: Jorge L. deLyra delyra@latt.if.usp.br Subject: [parisc-linux] HP 9000/735-125 > > information. Question: would it do anyone any good if I tried to get > > everything the kernel said before the hang into a message in this list? > > Certainly. I won't be able to debug the problems since I (a) don't have > the time too (unless it's obvious) and (b) don't have a 735 setup > for testing. OK, here goes. I want to congratulate you all on this effort. We have five of these HP-9000 stations here, quite old by now. They used to be our main number crunching force. They are wonderfully built hardware in bad need of a wonderful system on them! |:-) ---------------------------------------------------------------- Jorge L. deLyra, Associate Professor of Physics The University of Sao Paulo, IFUSP-DFMA For more information: finger delyra@latt.if.usp.br ---------------------------------------------------------------- Seyon Copyright (c) 1992-1993 Muhammad M. Saggaf. All rights reserved. Version 2 rev. 20c i586-Linux steve@hammer 05/23/99 20:19:22. Locating Modems... Modem `/dev/ttyS0' is Available. (c) Copyright. Hewlett-Packard Company. 1992. All rights reserved. PDC ROM rev. 2.7 IODC ROM rev. 1.1 80 MB of memory configured and tested. Searching for Potential Boot Devices. To terminate search, press and hold the ESCAPE key. Device Selection Device Path Device Type ---------------------------------------------------------------------------- P0 scsi.6.0 HP C3725S P1 scsi.4.0 TOSHIBA CD-ROM XM-3301TA b) Boot from specified device s) Search for bootable devices a) Enter Boot Administration mode x) Exit and continue boot sequence ?) Help Select from menu: b p1 Trying scsi.4.0 Boot path initialized. Attempting to load IPL. Soft booted. palo ipl bame@noam Tue Oct 31 14:18:02 MST 2000 0/vmlinux 2140145 bytes @ 0x6f9800 0/palo-cmdline '0/vmlinux ROOT=/ TERM=LINUX root=/dev/scd0' Kernel: partition 0 file /vmlinux ELF32 executable Entry 00100150 first 00100000 n 4 Segment 0 load 00100000 size 1460344 mediaptr 0x1000 Segment 1 load 00266000 size 179048 mediaptr 0x166000 Segment 2 load 00294000 size 109876 mediaptr 0x192000 Segment 3 load 002b0000 size 8192 mediaptr 0x1ad000 branching to kernel entry point 0x00100150 PDC Console Initialized The 32-bit Kernel has started... Enabled FP coprocessor Free memory starts at: 0xc02da000 (0x504d6c,0x504d6c,0x0,0x0) PALO command line: 'ROOT=/ TERM=LINUX root=/dev/scd0' PALO initrd 0-0 model 00002060 00000481 00000000 00000000 77f451b0 ffffffff 00000004 0000000a 0000000a vers 00000015 CPUID vers 0 rev 0 Searching for devices in PDC firmware... processor hpa 0xfffbe000 an older box... Found devices: 1. Outfield Core BA (11) at 0xf082f000, versions 0x9, 0x0, 0x70, 0x0, 0x0 2. Outfield Core SCSI (10) at 0xf0825000, versions 0x9, 0x0, 0x71, 0x0, 0x0 3. Outfield Core LAN (802.3) (10) at 0xf0826000, versions 0x9, 0x0, 0x72, 0x0, 0x0 4. Outfield Core HIL (10) at 0xf0821000, versions 0x9, 0x0, 0x73, 0x0, 0x0 5. Outfield Core RS-232 (10) at 0xf0823000, versions 0x9, 0x0, 0x75, 0x0, 0x0 6. Outfield Core RS-232 (10) at 0xf0822000, versions 0x9, 0x0, 0x75, 0x0, 0x0 7. Outfield Core Centronics (10) at 0xf0824000, versions 0x9, 0x0, 0x74, 0x0, 0x0 8. Outfield FW SCSI (10) at 0xf0830000, versions 0x9, 0x0, 0x7c, 0x0, 0x0 9. Outfield Audio (10) at 0xf1000000, versions 0x9, 0x0, 0x7f, 0x0, 0x0 10. Cobra EISA BA (11) at 0xfc000000, versions 0x4, 0x0, 0x76, 0x0, 0x0 11. Snake Cheetah (735/130) (0) at 0xfffbe000, versions 0x206, 0x0, 0x4, 0x0, 0x81 12. Snake Cheetah (1) at 0xfffbf000, versions 0x37, 0x0, 0x9, 0x0, 0x0 That's a total of 12 devices. CPU(s): 1 x PA7100 (PCX-T) at 125.000000 MHz Linux version 2.4.0-test6 (pjlahaie@elenuial.thepuffingroup.com) (gcc version 2.96 20000925 (experimental)) #32 Mon Nov 6 10:20:58 EST 2000 free_bootmem(0x2daa00, 0x4d25600) initrd: 00000000-00000000 pagetable_init On node 0 totalpages: 20480 zone(0): 10240 pages. zone(1): 10240 pages. zone(2): 0 pages. Kernel command line: ROOT=/ TERM=LINUX root=/dev/scd0 trap_init Calibrating delay loop... 124.52 BogoMIPS Memory: 77468k available Dentry-cache hash table entries: 16384 (order: 5, 131072 bytes) Buffer-cache hash table entries: 4096 (order: 2, 16384 bytes) Page-cache hash table entries: 32768 (order: 5, 131072 bytes) Inode-cache hash table entries: 8192 (order: 4, 65536 bytes) POSIX conformance testing by UNIFIX ASP version 20 at 0xf0800000 found. Found i82596 at 0xf0826000, IRQ 87 early initialization of device eth0 is deferred Found HIL at 0xf0821000, IRQ 94 HIL: no keyboard present. Warning : device (10, 0x9, 0x0, 0x73, 0x0) NOT claimed by HIL 712, 715 or similiar Linux NET4.0 for Linux 2.4 Based upon Swansea University Computer Society NET3.039 NET4: Unix domain sockets 1.0/SMP for Linux NET4.0. NET4: Linux TCP/IP 1.0 for NET4.0 IP Protocols: ICMP, UDP, TCP IP: routing cache hash table of 512 buckets, 4Kbytes TCP: Hash tables configured (established 8192 bind 8192) Starting kswapd v1.7 pty: 256 Unix98 ptys configured lp: driver loaded but no devices found RAMDISK driver initialized: 16 RAM disks of 4096K size 1024 blocksize sim700: Couldn't get consistent shared memory sim700: Configuring 53c700 (SCSI-ID 7) at f0825100, IRQ 86 scsi0: Revision 0x0 Post test1, istat 05, sstat0 00, dstat 84 sim700: WARNING IRQ probe failed, (returned 0) scsi0: WARNING: target data areas are not dma coherent! scsi0: test 1 completed ok. scsi0: sim700_intr_handle() called with no interrupt scsi0 : LASI/Simple 53c7xx scsi : 1 host. Vendor: TOSHIBA Model: CD-ROM XM-3301TA Rev: 1651 Type: CD-ROM ANSI SCSI revision: 02 Detected scsi CD-ROM sr0 at scsi0, channel 0, id 4, lun 0 Vendor: HP Model: C3725S Rev: 6019 Type: Direct-Access ANSI SCSI revision: 02 Detected scsi disk sda at scsi0, channel 0, id 6, lun 0 scsi : detected 1 SCSI cdrom 1 SCSI disk total. Uniform CD-ROM driver Revision: 3.11 SCSI device sda: hdwr sector= 512 bytes. Sectors= 4194058 [2047 MB] [2.0 GB] Partition check: sda: unknown partition table 82596.c: MAC of HP700 LAN blindely read from the prom! eth0: Couldn't get consistent shared memory eth0: 82596 at 0xf0826000, 08 00 09 0B DB EB IRQ 87. 82596.c $Revision: 1.14 $ Serial driver version 5.01 (2000-05-29) with MANY_PORTS SHARE_IRQ SERIAL_PCI enabled Dumping Stack from c4f9c000 to c4f9cbc0: c000 00000000 00000140 00000000 00000000 c027a46c 00000001 00000000 ffffffff c020 00000000 00000000 00000000 00000000 00000000 00000000 ffffffff c027a384 c040 c027a384 c4f90000 c02b0000 c028060c 00000000 00000000 00000000 00000000 c060 00000000 00000000 00000001 00000000 00000000 00000000 00000000 c02b0000 c080 c02b0000 c4f50000 00000000 00000000 00000000 c02c9ab8 00000000 c4f9c09c c0a0 c4f9c09c c4f9c0a4 c011a6e4 c4f9cac8 00000000 00000000 00000000 00000000 c0c0 00000000 00000000 00000000 00000000 00000000 00000000 c4f9c000 c011d4a8 c0e0 00000000 00000037 00000000 00000000 00000024 00000000 0000005b 00000000 c100 00000000 00000000 00000000 00000000 00000000 80000000 00000000 00000000 c120 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 c140 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 c160 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 c180 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 c1a0 00000000 00000000 00000000 00000000 00000000 00000000 00000000 fffffeff c1c0 00000000 ffffffff 00000000 c027afb4 ffffffff ffffffff ffffffff ffffffff c1e0 ffffffff ffffffff 00800000 05000000 00000000 ffffffff ffffffff ffffffff c200 00000500 00000500 00000400 00000400 ffffffff ffffffff ffffffff ffffffff c220 00007377 61707065 72000000 00000000 00000000 00000000 00000000 00000000 c240 00000000 00000000 00005000 c0267054 c0267054 c013d1e8 00010000 c4ffeba0 c260 c02238c4 c0236708 c02d9800 00504d6c 00000000 c011bb88 c0267000 00005000 c280 c0267054 c0267000 0000003e c027a000 00000001 c02b61eb 00000004 c02b61c7 c2a0 00000023 c02b61eb 00000000 00000000 c0100290 0000003e 00000000 00000024 c2c0 0000000b c027a4ac c027a000 08000059 00000000 000000ff 00000060 00000000 c2e0 00000060 00000002 002b2080 00000008 002b50c0 c0266000 00000000 023c3460 c300 c02b08c0 00000001 08000000 00000000 00000000 00000000 00856606 00000000 c320 00000000 00000000 42780000 00000000 431c0000 00000000 4471cccc 00000000 c340 000003c7 00000000 fffffde0 fffffde0 7f7fffff ffffffff 7f7fffff ffffffff c360 00000000 00000000 00000000 00000000 41800000 00000000 00000010 00000010 c380 00000000 00000000 fffffde0 fffffde0 41000000 00000000 40800000 00000000 c3a0 fffffde0 fffffde0 41000000 00000000 fffffde0 fffffde0 40800000 00000000 c3c0 41000000 00000000 40300000 00000000 40200000 00000000 40200000 00000000 c3e0 41800000 fffffde0 40000000 00000000 40000000 00000000 40800000 00000000 c400 41000000 00000000 00000000 00000000 c4f9cb80 c0103cf4 00000000 00000000 c420 00000000 00000000 00000000 00000000 c011bb78 c011bb7c 40800000 00000000 c440 00281000 00000000 c0280040 c0280064 00000000 c0280204 00000000 00000000 c460 00000000 00000000 00000000 c4f9c468 00000000 00000000 00000000 00000000 c480 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 c4a0 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 c4c0 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 c4e0 00000000 00000000 00000000 c0103c48 00000000 00000000 00000000 00000000 c500 c4f9c000 c028060c 00000000 00000000 00000000 00000000 00000000 00000000 c520 00000000 00000000 00000000 c01002a4 00000000 00000000 00000000 00000000 c540 00000000 00000000 00000000 00000000 c02b06c0 c4f9c000 c028060c 00000000 c560 c02b0000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 c580 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 c5a0 00000000 00000000 00000000 c02950a4 00000000 00000000 00000000 00000000 c5c0 00000001 c0284000 00000000 00000000 00000002 c027a4a0 c027a4a0 c0258bbc c5e0 00000000 00000000 00000000 c0294fe8 00000000 00000000 00000000 00000000 c600 00000000 08000059 00000000 00000000 f00012a0 000ff000 000a5a59 000a5a59 c620 c0295794 c02d9800 00504d6c c02cc000 c0266000 c02c8000 c02aed34 c02aed24 c640 c02aed34 c02aed20 00000000 00000000 000ff000 000a5a59 000a5a59 c0295794 c660 c02d9800 00504d6c c02cc000 c029bc3c c02c8000 c02aed34 c02aed04 c02c8000 c680 c02c5fe8 c02c60a4 c028758c 00000040 c0244ed8 c0244a0c c0244b80 c0244edc c6a0 01234567 c4f9c000 00000000 c02a6e64 c4f9c698 00000000 c02cc000 c0266000 c6c0 10000080 c02c5fe8 c02c60a4 c028758c 00000040 c4ffeea0 f00012a0 000ff000 c6e0 000a5a59 000a5a59 c0295794 c0155890 00504d6c c02cc000 c0266000 c02c8000 c700 c02c6164 00000100 c0244c38 00000000 c0245000 00000000 c02c5fe8 c02c5fe8 c720 c01e55ec c028be04 c02c9a20 c0109e74 c4ffc200 c028b474 c4f4a000 c028bf60 c740 00000004 c02aeab4 c02c8d20 c02b621f 00000004 c02b61ca 00000054 c02b621f c760 00000000 00000001 c027a000 c02a6de4 0000003c 00000058 0000000b c027a4ac c780 0000005a c4ff74a0 00000000 000000ff 00000060 00000000 00000060 00000002 c7a0 002b2080 00000008 002b50c0 c019324c 00000000 023c3460 c4f9c980 00000001 c7c0 08000000 00000000 00005301 f0823800 00856606 00000000 00000000 c028478c c7e0 42780000 00000000 431c0000 00000000 4471cccc 00000000 000003c7 00000000 c800 fffffde0 fffffde0 7f7fffff ffffffff 7f7fffff ffffffff 00000000 00000000 c820 00000000 00000000 41800000 00000000 00000010 00000010 f0823800 00000000 c840 00000003 fffffde0 41000000 00000000 40800000 00000000 fffffde0 fffffde0 c860 41000000 00000000 fffffde0 fffffde0 40800000 00000000 41000000 00000000 c880 40300000 00000000 40200000 00000000 40200000 00000000 c018ffb8 c02846d8 c8a0 c02c8800 c026c000 c02c8d20 0000000b c028478c 00000000 41000000 00000000 c8c0 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 c8e0 00000000 00000000 c011bb78 c0192bd4 4471cccc 00000000 000003c7 00000000 c900 0000000a c028478c c4f9c7c8 00000090 00000006 2b6a0000 00000000 00000000 c920 00000000 00000000 41800000 00000000 00000010 00000010 00000000 00000000 c940 fffffde0 fffffde0 41000000 00000000 40800000 00000000 fffffde0 fffffde0 c960 41000000 00000000 fffffde0 c011e9bc 40800000 00000000 41000000 00000000 c980 0004000a c0221800 c011e9f8 c4ff6520 c4ff6200 c0244f10 00000008 f0823800 c9a0 00000003 00000007 c0191568 c02c60a4 fffffffc c0245000 c0245000 c02d72b8 c9c0 c0245000 c0245000 c02c6028 00000000 c4ff6234 f0823807 f0823800 0000000a c9e0 ffffffff c4ff6520 c4ff6200 c0266000 ffffffff 00000340 c4f9cbc0 c012dfc0 ca00 08000000 00000000 00000000 00000000 00856606 00000000 00000000 00000000 ca20 42780000 00000000 431c0000 00000000 4471cccc 00000000 000003c7 00000000 ca40 fffffde0 fffffde0 7f7fffff ffffffff 7f7fffff ffffffff 00000000 00000000 ca60 00000000 00000000 41800000 00000000 00000010 00000010 00000000 00000000 ca80 fffffde0 fffffde0 41000000 00000000 40800000 00000000 fffffde0 fffffde0 caa0 41000000 00000000 fffffde0 fffffde0 40800000 00000000 41000000 00000000 cac0 40300000 00000000 40200000 00000000 40200000 00000000 41800000 fffffde0 cae0 40000000 00000000 40000000 00000000 40800000 00000000 41000000 00000000 cb00 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 cb20 00000000 00000000 c011e710 c011e714 00000000 00000000 00000000 00000000 cb40 00000000 00000058 c4f9c740 c02caac8 00000007 0f881093 00000000 00000003 cb60 c02c9800 c02c9a60 c02c9a20 00000000 00000000 00000400 c4f9cd40 c01d1c98 cb80 0000003c 0000003e c027a000 00000001 c02b61e0 00000004 c02b61c7 00000018 cba0 c02b61e0 00000000 431c0000 c01046e0 4471cccc 00000000 000003c7 00000000 Data access rights fault in kernel: Code=26 regs=c4f9c980 (Addr=00000003) YZrvWESTHLNXBCVMcbcbcbcbOGFRQPDI PSW: 00000000000001000000000000001010 r0-3 00000000 c0221800 c011e9f8 c4ff6520 r4-7 c4ff6200 c0244f10 00000008 f0823800 r8-11 00000003 00000007 c0191568 c02c60a4 r12-15 fffffffc c0245000 c0245000 c02d72b8 r16-19 c0245000 c0245000 c02c6028 00000000 r20-23 c4ff6234 f0823807 f0823800 0000000a r24-27 ffffffff c4ff6520 c4ff6200 c0266000 r28-31 ffffffff 00000340 c4f9cbc0 c012dfc0 sr0-4 00000000 00000000 00000000 00000000 sr4-8 00000000 00000000 00000000 00000000 IASQ: 00000000 00000000 IAOQ: c011e710 c011e714 IIR: 0f881093 ISR: 00000000 IOR: 00000003 ORIG_R28: 00000058 From delyra@latt.if.usp.br Thu, 30 Nov 2000 09:15:11 -0200 (BRST) Date: Thu, 30 Nov 2000 09:15:11 -0200 (BRST) From: Jorge L. deLyra delyra@latt.if.usp.br Subject: [parisc-linux] HP 9000/735-125 > I have a 735-125 and am able to net-boot it on a custom configured kernel as > long as I disable the ASP parallel ports. It works quite well using an NFS > root as I cannot get the SCSI hard drives to mkfs. I was going to try and > debug it but have yet to find the free time. I can e-mail you my working > .config for the kernel, or build kernels (tested on my own 735) for people > if they need them. Well, looks like the problem is known, good! But we have a queer little problem with our machines here, we are unable to boot from the network. I think we did everything right, in fact, we are trying to use a server here other machines boot from, it has dhcp, boopt, tftp, rarp, the works. We set it all up, put the kernel on the tftpboot area, tested all that we could by other means but, when we try to net boot the HPs, we are faced with complete silence on the network. No logs on the server, nothing. A little explanation might be needed: these are not really native 735-125 models, they were upgraded from older 720-50 models by card swapping. I am not sure whether all cards were changed, maybe some aspects of the machine are still old. The syntax of the net boot procedure in them is strange, you have to put in the hardware address of the server, which is unusual. I _suspect_ that this bios does not use tcp/ip for the net boot, but some HP proprietary protocol relating to that clustering software they have or used to have for these machines, in which you ran several stations out of the disks of a single one. In any case, a listing of what happens on the console on a net-boot trial goes below. We had a tail -f on the system log of the server, we had tcpdump listening, but nothing at all shows up... ---------------------------------------------------------------- Jorge L. deLyra, Associate Professor of Physics The University of Sao Paulo, IFUSP-DFMA For more information: finger delyra@latt.if.usp.br ---------------------------------------------------------------- Seyon Copyright (c) 1992-1993 Muhammad M. Saggaf. All rights reserved. Version 2 rev. 20c i586-Linux steve@hammer 05/23/99 20:19:22. Locating Modems... Modem `/dev/ttyS0' is Available. (c) Copyright. Hewlett-Packard Company. 1992. All rights reserved. PDC ROM rev. 2.7 IODC ROM rev. 1.1 80 MB of memory configured and tested. Searching for Potential Boot Devices. To terminate search, press and hold the ESCAPE key. Device Selection Device Path Device Type ---------------------------------------------------------------------------- P0 scsi.6.0 HP C3725S P1 scsi.4.0 TOSHIBA CD-ROM XM-3301TA b) Boot from specified device s) Search for bootable devices a) Enter Boot Administration mode x) Exit and continue boot sequence ?) Help Select from menu: a BOOT_ADMIN> help boot Boot from specified device or path: BOOT IPL boots Initial Program Loader (interactive mode) BOOT boots default boot utility may be one of the following: pri primary path in Stable Storage alt alternate path in Stable Storage Pn Device selection from SEARCH eisa. EISA adapter fwscsi. On-board FASTWIDE SCSI interface lan. Slider-card LAN interface scsi. On-board SCSI interface For more information on boot selection options, type HELP where = eisa, lan, scsi, etc ... BOOT_ADMIN> help lan LAN (IEEE 802.3/Ethernet LAN) Path Specification lan... 12 digit (hex) LAN server address max number of times to try a boot request (0 = default, 255 = infinite) max number of times to try a read request (0 = default, 255 = infinite) Example: to specify LAN address 123456-78ABCD with infinite initialization retries and default I/O retries, lan.123456-78ABCD.255.0 If one or more parameters are not specified, the following defaults will be used: = 000000-000000 = 3 tries = 6 tries BOOT_ADMIN> boot lan.0000f8-01abb1.0.0 Trying lan.0000f8-01abb1.0.0 Failed to initialize lan.0000f8-01abb1.3.0 ENTRY_INIT status = -7 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000008 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 A000800C F0002898 00000000 0800090B DBEB0000 00000000 Searching for Potential Boot Devices. To terminate search, press and hold the ESCAPE key. Device Selection Device Path Device Type ---------------------------------------------------------------------------- P0 scsi.6.0 HP C3725S P1 scsi.4.0 TOSHIBA CD-ROM XM-3301TA b) Boot from specified device s) Search for bootable devices a) Enter Boot Administration mode x) Exit and continue boot sequence ?) Help Select from menu: From rhirst@linuxcare.com Thu, 30 Nov 2000 11:19:30 +0000 Date: Thu, 30 Nov 2000 11:19:30 +0000 From: Richard Hirst rhirst@linuxcare.com Subject: [parisc-linux] HP 9000/735-125 On Thu, Nov 30, 2000 at 08:58:22AM -0200, Jorge L. deLyra wrote: > OK, here goes. I want to congratulate you all on this effort. We have five > of these HP-9000 stations here, quite old by now. They used to be our main > number crunching force. They are wonderfully built hardware in bad need of > a wonderful system on them! |:-) > Serial driver version 5.01 (2000-05-29) with MANY_PORTS SHARE_IRQ SERIAL_PCI enabled > > Dumping Stack from c4f9c000 to c4f9cbc0: This has been reported on 715/50 (Robert Duncan) and 715/75 (me) round about November 15th. At the time I tried a current cvs kernel on my 715/75 and it was even worse (IIRC). I'll have another look at it. Richard From rhirst@linuxcare.com Thu, 30 Nov 2000 11:27:39 +0000 Date: Thu, 30 Nov 2000 11:27:39 +0000 From: Richard Hirst rhirst@linuxcare.com Subject: [parisc-linux] HP 9000/735-125 On Thu, Nov 30, 2000 at 01:20:28AM -0800, Steve Moret wrote: > Now, maybe you can help me identify my SCSI problem. I don't know if it is > because of driver issues or a bad disk (completly likely). Do other people > have the Fast SCSI2 working on their 735s? > > Whenever I do a mke2fs (after partitioning the drive with fdisk ok) it dies. I have a 53c700 on my 715/75, and the driver was having trouble with a CRDOM I attached, so it has some problems. I wrote the driver, but havn't used the 715/75 for a while since latest kernels wouldn't boot for me. I'll get it going again and see if the scsi driver still works. Richard From deller@gmx.de Thu, 30 Nov 2000 13:04:49 +0100 (MET) Date: Thu, 30 Nov 2000 13:04:49 +0100 (MET) From: Helge Deller deller@gmx.de Subject: [parisc-linux] HP 9000/735-125 Hi Steve, > My mistake! I did a full build with todays CVS and parport didn't die. > So > somewhere between the 17th and now parport must have been fixed. I checked in yesterday a modified version of /drivers/parport/parport_gsc.c with an "#if 0 ... #endif" in the code. Could you try to boot again with "#if 1" (search for the text which says something like "enable bidirectional PS/2 mode") and try again ? If this hangs your machine I will implement a better work-around. > > Now, maybe you can help me identify my SCSI problem. I don't know if it > is > because of driver issues or a bad disk (completly likely). I think Richard Hirst can help you much more with your SCSI-problems than me. NB: Does your chassis LEDs work with the new kernel, and if not, could you send me your bootlog (or "dmesg | grep led") ? Greetings, Helge -- Sent through GMX FreeMail - http://www.gmx.net From rbradetich@uswest.net Thu, 30 Nov 2000 07:01:53 -0800 Date: Thu, 30 Nov 2000 07:01:53 -0800 From: Ryan Bradetich rbradetich@uswest.net Subject: [parisc-linux] HP 9000/735-125 "Jorge L. deLyra" wrote: > > I have a 735-125 and am able to net-boot it on a custom configured kernel as > > long as I disable the ASP parallel ports. It works quite well using an NFS > > root as I cannot get the SCSI hard drives to mkfs. I was going to try and > > debug it but have yet to find the free time. I can e-mail you my working > > .config for the kernel, or build kernels (tested on my own 735) for people > > if they need them. > > Well, looks like the problem is known, good! But we have a queer little > problem with our machines here, we are unable to boot from the network. I > think we did everything right, in fact, we are trying to use a server here > other machines boot from, it has dhcp, boopt, tftp, rarp, the works. We > set it all up, put the kernel on the tftpboot area, tested all that we > could by other means but, when we try to net boot the HPs, we are faced > with complete silence on the network. No logs on the server, nothing. > > A little explanation might be needed: these are not really native 735-125 > models, they were upgraded from older 720-50 models by card swapping. I am > not sure whether all cards were changed, maybe some aspects of the machine > are still old. The syntax of the net boot procedure in them is strange, > you have to put in the hardware address of the server, which is unusual. > > I _suspect_ that this bios does not use tcp/ip for the net boot, but some > HP proprietary protocol relating to that clustering software they have or > used to have for these machines, in which you ran several stations out of > the disks of a single one. In any case, a listing of what happens on the > console on a net-boot trial goes below. We had a tail -f on the system log > of the server, we had tcpdump listening, but nothing at all shows up... I believe the 735/755 type machines require rbootd to boot from the network. rbootd is available at: ftp://puffin.external.hp.com/pub/parisc/binaries/tgz/rbootd-2.0-2.tar.gz - Ryan From rhirst@linuxcare.com Thu, 30 Nov 2000 14:03:10 +0000 Date: Thu, 30 Nov 2000 14:03:10 +0000 From: Richard Hirst rhirst@linuxcare.com Subject: [parisc-linux] 715/75 dies in pdc_iodc_read() Hi, My 715/75 no longer boots with cvs kernel. It hangs while searching for devices in PDC firmware, after finding the first device. The beta 0.5 cd kernel gets past this point. The device list is: Searching for devices in PDC firmware... processor hpa 0xfffbe000 an older box... Found devices: 1. Stinger Optional Graphics (10) at 0xf4000000, versions 0x6, 0x0, 0x77, 0x0, 0x0 2. Scorpio Sr. Core BA (11) at 0xf082f000, versions 0x19, 0x0, 0x70, 0x0, 0x0 3. Scorpio Sr. Core SCSI (10) at 0xf0825000, versions 0x19, 0x0, 0x71, 0x0, 0x0 4. Scorpio Sr. Core LAN (802.3) (10) at 0xf0826000, versions 0x19, 0x0, 0x72, 0x0, 0x0 5. Scorpio Sr. Core HIL (10) at 0xf0821000, versions 0x19, 0x0, 0x73, 0x0, 0x0 6. Scorpio Sr. Core RS-232 (10) at 0xf0823000, versions 0x19, 0x0, 0x75, 0x0, 0x0 7. Scorpio Sr. Core RS-232 (10) at 0xf0822000, versions 0x19, 0x0, 0x75, 0x0, 0x0 8. Scorpio Sr. Core Centronics (10) at 0xf0824000, versions 0x19, 0x0, 0x74, 0x0, 0x0 9. Scorpio Sr. Audio (10) at 0xf1000000, versions 0x19, 0x0, 0x7b, 0x0, 0x0 10. Scorpio Sr. EISA BA (11) at 0xfc000000, versions 0x19, 0x0, 0x76, 0x0, 0x0 11. Unknown device (10) at 0xfc001000, versions 0x0, 0x0, 0xfff, 0x0, 0x0 12. Scorpio Sr.(715/75) (0) at 0xfffbe000, versions 0x316, 0x0, 0x4, 0x0, 0x81 13. Scorpio Sr. (1) at 0xfffbf000, versions 0x27, 0x0, 0x9, 0x0, 0x0 That's a total of 13 devices. CPU(s): 1 x PA7100 (PCX-T) at 75.000000 MHz So, with lastest cvs source, it gets in to the loop in really_do_oldhw_inventory(), and first time through pdc_mem_map_hpa() returns r_addr.hpa=0xf4000000 (the Stinger Optional Graphics). Next time round, mod=1, pdc_mem_map_hpa() returns r_addr.hpa=0xf8000000, and the subsequent call to pdc_iodc_read() hangs. I made the code skip the loop where mod=1, and it then goes on to discover all the devices without problems. At power on, the machine reports: Warning: one or more EISA cards could not be configured. Autoselect and search will ignore unconfigured cards. Which I assume relates to an EISA SCSI card in the machine, which I assume is item 11 in the above list. Richard From delyra@latt.if.usp.br Thu, 30 Nov 2000 13:04:46 -0200 (BRST) Date: Thu, 30 Nov 2000 13:04:46 -0200 (BRST) From: Jorge L. deLyra delyra@latt.if.usp.br Subject: [parisc-linux] HP 9000/735-125 > I believe the 735/755 type machines require rbootd to boot from the network. > rbootd is available at: > > ftp://puffin.external.hp.com/pub/parisc/binaries/tgz/rbootd-2.0-2.tar.gz Ah! This is it, then! Had never heard of this beast before. I see it is available for i386, nice, our server is a Pentium. Well, thanks a whole lot for the tip, we are certainly trying this. Well, back to work... ---------------------------------------------------------------- Jorge L. deLyra, Associate Professor of Physics The University of Sao Paulo, IFUSP-DFMA For more information: finger delyra@latt.if.usp.br ---------------------------------------------------------------- From delyra@latt.if.usp.br Thu, 30 Nov 2000 13:49:56 -0200 (BRST) Date: Thu, 30 Nov 2000 13:49:56 -0200 (BRST) From: Jorge L. deLyra delyra@latt.if.usp.br Subject: [parisc-linux] HP 9000/735-125 OK, rbootd is up and running, the station now establishes instantaneous communication with the server. But it says "bad LIF magic" and does not boot. I presume I can't just put the precompiled kernel in there. Since I cannot cross-compile for the time being (bad HP server disk crash) is there a net-boot kernel somewhere that I can download and try? Cheers, ---------------------------------------------------------------- Jorge L. deLyra, Associate Professor of Physics The University of Sao Paulo, IFUSP-DFMA For more information: finger delyra@latt.if.usp.br ---------------------------------------------------------------- From randolph@tausq.org Thu, 30 Nov 2000 08:44:18 -0700 Date: Thu, 30 Nov 2000 08:44:18 -0700 From: Randolph Chung randolph@tausq.org Subject: [parisc-linux] CVS linux Vs. -test10 > Oooh, there's a reason for me to finally get the 712/80 under my desk > to be more than a foot-rest. I'll see what I can do about this. > > Note that the likelihood of Debian releasing woody anytime soon is > vanishingly small, so this dosen't have to happen Right Now. So little faith... :P Let me know what I can do to help.... it takes my dual-400MHz i386 box about an hour to build boot-floopies; i don't even wait to think how long it will take on the 712/80 :-) randolph -- @..@ http://www.TauSq.org/ (----) ( >__< ) ^^ ~~ ^^ From rhirst@linuxcare.com Thu, 30 Nov 2000 16:11:15 +0000 Date: Thu, 30 Nov 2000 16:11:15 +0000 From: Richard Hirst rhirst@linuxcare.com Subject: [parisc-linux] HP 9000/735-125 On Thu, Nov 30, 2000 at 11:27:39AM +0000, Richard Hirst wrote: > On Thu, Nov 30, 2000 at 01:20:28AM -0800, Steve Moret wrote: > > Now, maybe you can help me identify my SCSI problem. I don't know if it is > > because of driver issues or a bad disk (completly likely). Do other people > > have the Fast SCSI2 working on their 735s? > > > > Whenever I do a mke2fs (after partitioning the drive with fdisk ok) it dies. > > > I have a 53c700 on my 715/75, and the driver was having trouble > with a CRDOM I attached, so it has some problems. I wrote the > driver, but havn't used the 715/75 for a while since latest kernels > wouldn't boot for me. I'll get it going again and see if the scsi > driver still works. I got my 715/75 to boot. The scsi driver still has problems with my CDROM drive, but the disk seems ok. I ran mke2fs of a 1Gig partition a few times and then copied 200MB of files from the network to it. Richard From bame@noam.fc.hp.com Thu, 30 Nov 2000 09:18:51 -0700 Date: Thu, 30 Nov 2000 09:18:51 -0700 From: Paul Bame bame@noam.fc.hp.com Subject: [parisc-linux] CVS linux Vs. -test10 = Grant> need "boot floppies" debian package working. We don't need = = Oooh, there's a reason for me to finally get the 712/80 under my desk = to be more than a foot-rest. I'll see what I can do about this. = = Note that the likelihood of Debian releasing woody anytime soon is = vanishingly small, so this dosen't have to happen Right Now. Well yes and no. We want to release parisc-linux sooner than woody will be ready for public stable release, so we'll want to do the boot floppies work sooner than other architectures need it and can probably therefore provide early testing too. Since we aren't going to time travel back to Debian potato, woody boot floppies are increasingly interesting to replace our manual install process (hey at least it's documented!). -P From alan@lxorguk.ukuu.org.uk Thu, 30 Nov 2000 16:10:46 +0000 (GMT) Date: Thu, 30 Nov 2000 16:10:46 +0000 (GMT) From: Alan Cox alan@lxorguk.ukuu.org.uk Subject: [parisc-linux] XFree status > Alan Cox wrote: > > I have a server linked. > Alan - that's Cool! Wow! Its still got its atoms in a twist, so its bombing out in Xnest loading the first font. > > inb/inw/outb/outw and friends are right now null > > functions until I fill them in. Thats not a big deal. Initially I'll probably > > use /dev/port but for speed I hope everyone uses mmio based hardware. > > All HP graphics for PARISC are memory mapped. Both "GSC" and PCI flavors. Yes, but if I want to say put an S3 Trio64 in my A180 and a USB card for keyboard mouse..,, (and yes these are sitting on my desk) > But I'm pretty clueless how linux X server finds/talks to a frame buffer. > For HPUX, the graphics driver supports some ioctl()'s. > Any references to describe how it works for linux? The OS specific X code in XFree86 knows several ways to talk to Linux Memory: 1. Directly mmap()ing /dev/mem or /dev/kmem to get access to the mmio space of the card and frame buffer memory. 2. Mapping the pci space via a kernel frame buffer device (/dev/fb*) 3. Arbitary other mmap based code that you plug into it (harder to do) I/O 1. Use of iopl/ioperm on x86 2. Use of mmap to map the PCI I/O space regions on different platforms (which doesnt work on some PA kit) 3. Arbitary other code we plug into it For I/O it seems that on things like the A180 the only way to do it is to use /dev/port and pread/pwrite the file handle for each port I/O. This is slow but hopefully primarily used for booting the card (XFree 4.0 has a X86 emulator for booting the BIOS firmware on PCI cards) For most machines I imagine we would be using mmio and the /dev/fb interface. Alan From alan@lxorguk.ukuu.org.uk Thu, 30 Nov 2000 16:16:18 +0000 (GMT) Date: Thu, 30 Nov 2000 16:16:18 +0000 (GMT) From: Alan Cox alan@lxorguk.ukuu.org.uk Subject: [parisc-linux] CVS linux Vs. -test10 > Oooh, there's a reason for me to finally get the 712/80 under my desk > to be more than a foot-rest. I'll see what I can do about this. > > Note that the likelihood of Debian releasing woody anytime soon is > vanishingly small, so this dosen't have to happen Right Now. My experiences with building Red Hat 7 so far are mostly good. I don't think there will be many actual changes needed to build Debian packages either. I've made very little that isnt 'use -fPIC' 'dont optimise C++' From marteaut@esiee.fr Thu, 16 Nov 2000 21:16:22 +0100 Date: Thu, 16 Nov 2000 21:16:22 +0100 From: Thomas Marteau marteaut@esiee.fr Subject: [parisc-linux] Troubles with read only file system Hi all, We have done everything well but the NFSroot and the bootable disk say that we have a read only file system ??? What is the recipe for making a bootable disk because ours can not be the good one... Thanks, Thomas From marteaut@esiee.fr Fri, 17 Nov 2000 17:59:14 +0100 Date: Fri, 17 Nov 2000 17:59:14 +0100 From: Thomas Marteau marteaut@esiee.fr Subject: [parisc-linux] Trouble with new STI This is a multi-part message in MIME format. ------=_NextPart_000_000F_01C050C0.18E3D060 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi all, We've tried the new STI driver and our 712 dies with this message: Kernel Panic: VFS: Unable to mount root fs on 01:00 We tried with Ramdisk, nfs and hard disk support and always the same = end. Also, the death happens when you 've passed bootp request... Help! Thomas ------=_NextPart_000_000F_01C050C0.18E3D060 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi all,
 
We've tried the new STI driver and our = 712 dies=20 with this message:
 
Kernel Panic: VFS: Unable to mount root = fs on=20 01:00
 
We tried with Ramdisk, nfs and hard = disk support=20 and always the same end.
Also, the death happens when you 've = passed bootp=20 request...
 
Help!
 
Thomas
------=_NextPart_000_000F_01C050C0.18E3D060-- From marteaut@esiee.fr Sun, 19 Nov 2000 13:08:45 +0100 Date: Sun, 19 Nov 2000 13:08:45 +0100 From: Thomas Marteau marteaut@esiee.fr Subject: [parisc-linux] Booting 712 STI and nfs This is a multi-part message in MIME format. ------=_NextPart_000_0047_01C05229.D8DA5D20 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi all, We managed to boot on the STI-console with a 712/80 in changing the = parameters in inittab and in securetty (if you want to login as root).=20 > cat inittab (! just the interesting thing!) # /sbin/getty invocations for the runlevels. # # The "id" field MUST be the same as the last # characters of the device (after "tty"). # # Format: # ::: 1:2345:respawn:/sbin/getty 38400 tty1 #2:23:respawn:/sbin/getty 38400 tty2 #3:23:respawn:/sbin/getty 38400 tty3 #4:23:respawn:/sbin/getty 38400 tty4 #5:23:respawn:/sbin/getty 38400 tty5 #6:23:respawn:/sbin/getty 38400 tty6 =20 > cat securetty # /etc/securetty: list of terminals on which root is allowed to login. # See securetty(5) and login(1). ttyS0 tty1 Also, in order to boot with the STI console, you need to have the module = for STI-console and not for serial console support... But, we have troubles with the rpc that print somestimes nfs: server X.X.X.165 not responding, still trying nfs: server X.X.X.165 OK nfs: server X.X.X.165 not responding, still trying nfs: server X.X.X.165 OK nfs: server X.X.X.165 not responding, still trying nfs: server X.X.X.165 OK We don't understand where comes from the problem!! Bye, ESIEE Port Team ------=_NextPart_000_0047_01C05229.D8DA5D20 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi all,
 
We managed to boot on the STI-console = with a 712/80=20 in changing the parameters in inittab and in securetty (if you want to = login as=20 root).
 
> cat inittab (! just the = interesting=20 thing!)
# /sbin/getty invocations for the=20 runlevels.
#
# The "id" field MUST be the same as the last
# = characters=20 of the device (after "tty").
#
# Format:
# =20 <id>:<runlevels>:<action>:<process>
1:2345:res= pawn:/sbin/getty=20 38400 tty1
#2:23:respawn:/sbin/getty 38400 = tty2
#3:23:respawn:/sbin/getty=20 38400 tty3
#4:23:respawn:/sbin/getty 38400 = tty4
#5:23:respawn:/sbin/getty=20 38400 tty5
#6:23:respawn:/sbin/getty 38400 tty6
 
 
 
> cat securetty
# /etc/securetty: list of terminals on = which root=20 is allowed to login.
# See securetty(5) and=20 login(1).
ttyS0
tty1
 
Also, in order to boot with the STI = console, you=20 need to have the module for STI-console and not for serial console=20 support...
 
But, we have troubles with the rpc that = print=20 somestimes
nfs: server X.X.X.165 not responding, = still=20 trying
nfs: server X.X.X.165 OK
nfs: server X.X.X.165 not responding, = still=20 trying
nfs: server X.X.X.165 OK
nfs: server X.X.X.165 not responding, = still=20 trying
nfs: server X.X.X.165 OK
We don't understand where comes from the problem!!
 
Bye,
ESIEE Port Team
------=_NextPart_000_0047_01C05229.D8DA5D20-- From marteaut@esiee.fr Mon, 20 Nov 2000 15:32:55 +0100 Date: Mon, 20 Nov 2000 15:32:55 +0100 From: Thomas Marteau marteaut@esiee.fr Subject: [parisc-linux] A new file system This is a multi-part message in MIME format. ------=_NextPart_000_0009_01C05307.27222700 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi all, Since we have the STI, we have produced a file system quite = interesting for the 712. You can have a network support till you configure the file.conf like resolv... = Also, we have noticed that the sti on B180 does not work well, it look like it can not find the = rom. But we have to work on... To download the archives go there: http://www.esiee.fr/~djoudim/code/suitable.html It is incredible what can do a 712 with it! Bye, ESIEE Port Team ------=_NextPart_000_0009_01C05307.27222700 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi all,
 
    Since we have the = STI, we have=20 produced a file system quite interesting for the 712. You = can
have a network support till you = configure the=20 file.conf like resolv... Also, we have noticed that
the sti on B180 does not work well, it = look like it=20 can not find the rom. But we have to work on...
 
To download the archives go = there:
http://www.esiee= .fr/~djoudim/code/suitable.html
 
It is incredible what can do a 712 with = it!
 
Bye,
ESIEE Port Team
------=_NextPart_000_0009_01C05307.27222700-- From kailasr@webcash.com Tue, 31 Oct 2000 12:58:41 -0800 Date: Tue, 31 Oct 2000 12:58:41 -0800 From: Kailashnath V Rampure kailasr@webcash.com Subject: [parisc-linux] unable to run palo on nfs root Hi Paul, After booting the Server from NFSroot I need to Initialize the harddisk on the server. so I copied the palo and linux in to the nfsroot. I am trying to Run the following command: $ palo -I -k /boot/vmlinux -b /boot/iplboot -c '2/boot/vmlinux TERM=linux HOME=/ root=/dev/sda2' /dev/sda fisrt partition is 10M of type f0 second partition is /dev/sda2 of type linux native. Third partition is /dev/sda3 of type linux Swap Then I get the cannot execute binary file. second question is that what is the Terminal type I should set as I am unable to open vi. Please suggest the correct steps. Thanks. Kailas At 09:54 AM 10/31/00 -0700, Paul Bame wrote: >= Hi, >= >= I have booted HP A class server from nfsroot. but when I try to run palo on >= the server to initialize boot loader to the hdd I get >= "cannot execute the binary file" >= >= can any one help me to make the hdd bootable > >It would help me to see the actual command you used and the actual >error message(s) printed. With the info you give so far it could be >"a million" things. > > -P From bame@noam.fc.hp.com Tue, 31 Oct 2000 14:26:00 -0700 Date: Tue, 31 Oct 2000 14:26:00 -0700 From: Paul Bame bame@noam.fc.hp.com Subject: [parisc-linux] NEW NATIVE PALO TARBALL - REQUIRED = Hi Paul, = = After booting the Server from NFSroot I need to Initialize the harddisk on = the server. so I copied the palo and linux in to the nfsroot. I am trying = to Run the following command: = $ palo -I -k /boot/vmlinux -b /boot/iplboot -c '2/boot/vmlinux TERM=linux = HOME=/ root=/dev/sda2' /dev/sda = fisrt partition is 10M of type f0 = second partition is /dev/sda2 of type linux native. = Third partition is /dev/sda3 of type linux Swap That looks great. = Then I get the cannot execute binary file. Ok I think we changed the kernal such that the old palo bits won't run any more (we removed the old gateway page). I uploaded a new version: ftp://puffin.external.hp.com/pub/parisc/binaries/userspace/palo-200001031.tgz -P From grundler@cup.hp.com Tue, 31 Oct 2000 13:53:04 -0800 Date: Tue, 31 Oct 2000 13:53:04 -0800 From: Grant Grundler grundler@cup.hp.com Subject: [parisc-linux] unable to run palo on nfs root Kailashnath V Rampure wrote: > fisrt partition is 10M of type f0 > second partition is /dev/sda2 of type linux native. > Third partition is /dev/sda3 of type linux Swap Kailashnath, Even though your partitioning should work fine, you really want the swap on the lowest numbered SCSI block you can get away with. Several reasons for this: o lowest block number is on the outside of the SCSI disk were data xfer rate is typically 80% faster than the inside. (someday try "time dd if=/dev/sda of=/dev/null bs=8k count=50" with and with out skip parameter). o Eventualy we will have kernel dumps to swap space - and IODC will likely have the same limitations where on the disk dump can be as we have with booting from a disk (as discussed in the PALO documentation). grant Grant Grundler Unix Systems Enablement Lab +1.408.447.7253 From taggart@carmen.fc.hp.com Tue, 31 Oct 2000 16:16:09 -0700 Date: Tue, 31 Oct 2000 16:16:09 -0700 From: Matt Taggart taggart@carmen.fc.hp.com Subject: [parisc-linux] New cross-compiler I have placed a new i386-linux -> hppa32/64-linux cross compiler (with 32bit glibc) in, ftp://puffin.external.hp.com/pub/parisc/binaries/LinuxX86/xc-20001031.tar.gz It includes Alan Modra's recent fix for the 64 bit compiler, http://puffin.external.hp.com/mailing-lists/parisc-linux-cvs/2000/10-Oct/0233.h tml -- Matt Taggart taggart@fc.hp.com From pdbeal@bealz.net Tue, 31 Oct 2000 18:43:06 -0500 Date: Tue, 31 Oct 2000 18:43:06 -0500 From: Phillip Beal pdbeal@bealz.net Subject: [parisc-linux] 735 and Thin Lan Hey, I've obtained two HP 735's and I'd like to try the linus port on them. I have compiled a kernel, but it never boots the nfsroot disk. It has the same problem that the HP 755 that I've worked with. However, it has a different ethernet connection. The 735 has a thin lan connection. What network device should be used in the kernel to be able to use the thin lan adapter? Here's the info on the Thin lan: Outfield Core LAN (802.3) (10) at 0xf0826000 versions 0x9, 0x0, 0x72, 0x0, 0x0 Thanks, -- Phillip Beal S+LUG Vice-President From deller@gmx.de Wed, 1 Nov 2000 00:57:22 +0100 Date: Wed, 1 Nov 2000 00:57:22 +0100 From: Helge Deller deller@gmx.de Subject: [parisc-linux] 735 and Thin Lan On Wednesday 01 November 2000 00:43, Phillip Beal wrote: > Hey, > > I've obtained two HP 735's and I'd like to try the linus port on them. > I have compiled a kernel, but it never boots the nfsroot disk. It has > the same problem that the HP 755 that I've worked with. However, it has > a different ethernet connection. The 735 has a thin lan connection. > What network device should be used in the kernel to be able to use the > thin lan adapter? Here's the info on the Thin lan: > > Outfield Core LAN (802.3) (10) at 0xf0826000 versions 0x9, 0x0, 0x72, > 0x0, 0x0 > > Thanks, > Phillip Beal > S+LUG Vice-President Hi Phillip, I think the "Lasi ethernet"-driver (enabled by default in our configuration) should work on both of your boxes. Helge. From deller@gmx.de Wed, 1 Nov 2000 01:45:52 +0100 Date: Wed, 1 Nov 2000 01:45:52 +0100 From: Helge Deller deller@gmx.de Subject: [parisc-linux] The new PS/2 Keyboard Driver On Friday 27 October 2000 01:50, Helge Deller wrote: > On Thursday 26 October 2000 22:05, Thomas Marteau wrote: > > > > > > Hello everyone, > > > > We've just updated the PS/2 keyboard driver. The leds and interrupt > > functions work really well on a 712 workstation and also B132 now. The > > updated driver files are available on our website. It works better than > > under HP UX for the B 132 ;-> > > > > http://www.esiee.fr/~djoudim > > > > The ESIEE Port Team in Paris. > > > > Here is the patch: > > > > diff -urN linux/drivers/char/gsc_ps2.c linux-parisc/drivers/char/gsc_ps2.c > > --- linux/drivers/char/gsc_ps2.c Thu Oct 26 21:06:54 2000 > > +++ linux-parisc/drivers/char/gsc_ps2.c Thu Oct 26 21:34:00 2000 > > @@ -7,6 +7,11 @@ > > [.............] > > > diff -urN linux/drivers/char/keyb_at.c linux-parisc/drivers/char/keyb_at.c > > --- linux/drivers/char/keyb_at.c Thu Oct 26 21:07:00 2000 > > +++ linux-parisc/drivers/char/keyb_at.c Thu Oct 26 21:23:16 2000 > > [........] > > Hi Thomas, > > Thanks for your patch. > But I don't think it's a good idea to change a common file like keyb_at.c, > which is used in most other arches too. This patch surely breaks their > keyboard support and more than that I'm sure, that Linus will not accept this > patch, when the time is come to integrate parisc into the official kernel. > > Isn't there any other solution as for example to #ifdef the code or create a > new keyb_at.c for parisc (Yes I know, both of those aren't clean too.) ? > > Helge Deller Hi folks, I need to correct myself on this topic. The ESIEE-team made a great patch and didn't changed any globally used file. keyb_at.c is just used in the current parisc-port, and so it's ok to change that file. I just committed their changes to the CVS, and in the same cycle tried to clean up the code. In the same step I renamed the original filenames to some hopefully better ones. Since I don't own myself a real HP PS/2 keyboard (it's just an PC-AT one with a small DIN to PS/2-connector), it would be great to get some feedback if I did the Right Thing. Helge. From bri@mojo.calyx.net Wed, 1 Nov 2000 02:48:02 -0500 (EST) Date: Wed, 1 Nov 2000 02:48:02 -0500 (EST) From: Brian S. Julin bri@mojo.calyx.net Subject: [parisc-linux] The new PS/2 Keyboard Driver Probably best not to worry about cleaning keyboard drivers up too much. The current USB code will be followed by linux-input style drivers at some point. In fact I started a HIL linux-input style driver, which would abstract the PS2 port/HIL ports and allow a standard keyboard module to be hooked into the abstracted serio port. I will work on it more when time permits. -- Brian S. Julin From jsm@udlkern.fc.hp.com Wed, 1 Nov 2000 02:37:58 -0700 (MST) Date: Wed, 1 Nov 2000 02:37:58 -0700 (MST) From: John Marvin jsm@udlkern.fc.hp.com Subject: Elf Header change proposal Paul and Alan pointed out that I goofed. I analyzed the vmlinux in my 64 bit build area to get the current flags, but it turns out that the vmlinux I looked at was a 32 bit version. I had recently made some 64 bit checkins, and I like to rebuild everything for 32 bit before doing that, to make sure that I haven't broken the 32 bit path by making 64 bit changes. So, the bad news is that I wasted time writing an unecessarily long design proposal. The good news is that the only thing that needs to change is value in the e_ident[EI_OSABI] field, so that we can differentiate 64 bit HP-UX binaries from 64 bit Linux binaries. We should also change the field for 32 bit Linux also. John From jsm@udlkern.fc.hp.com Wed, 1 Nov 2000 03:35:49 -0700 (MST) Date: Wed, 1 Nov 2000 03:35:49 -0700 (MST) From: John Marvin jsm@udlkern.fc.hp.com Subject: space registers Matthew Wilcox wrote: > a small optimisation just occurred to me. > > right now, when we switch to kernel space, we set all of sr4-sr7 to 0 > (for the kernel mapping). we don't need to do that since the kernel is > entirely in sr7's domain. this has the added bonus that badly written > drivers which blindly dereference userspace pointers will work on > parisc as well as x86. we can also lazily restore sr4-6 on exit from > kernel space if we're switching back to the same task which called us. > this optimisation may not be worthwhile, but i think setting sr4-6 > on entry to the kernel is unnecessary. True for now. But it won't always be true. It is a desired goal to be able to support large (~3.5 Gb) physical memory for the 32 bit port. To do this we will move the kernel down to around virtual address 0, so the kernel address space will then be controlled by sr4, and depending on the amount of physical memory in the machine, possibly sr5, sr6, and sr7. We could do this based on a test of the amount of physical memory in the machine, but once you load something from memory to do the test, and then actually do the test, you wouldn't have any advantage over just writing zero's to the space registers. This might be worth considering for the 64 bit port, since both the kernel and user space will reside entirely within the linear address space covered by sr4 (We would have to go to a 1 Mb page size to be able to support greater than a 62 bit address space with three level page tables). sr5,sr6, and sr7 will only be used when we are running 64 bit HP-UX processes (with its address space broken up into 4 segments). Note that since we just store the users space in sr3 while we are in the kernel, its not clear that any kind of test with a branch would be a performance gain, especially if it required that we load something from memory to do that test. We may be able cover this by managing sr5, sr6 and sr7 only in the HP-UX specific parts of the syscall path. John From alan@linuxcare.com.au Thu, 2 Nov 2000 00:11:11 +1100 (EST) Date: Thu, 2 Nov 2000 00:11:11 +1100 (EST) From: Alan Modra alan@linuxcare.com.au Subject: Elf Header change proposal On Wed, 1 Nov 2000, John Marvin wrote: > So, the bad news is that I wasted time writing an unecessarily long > design proposal. The good news is that the only thing that needs to > change is value in the e_ident[EI_OSABI] field, so that we can > differentiate 64 bit HP-UX binaries from 64 bit Linux binaries. > We should also change the field for 32 bit Linux also. Some other bad news is that the change isn't quite trivial, due to not wishing to break other bfd targets. The good new is I've made the change. Compiling at the moment. Alan Modra -- Linuxcare. Support for the Revolution. From bame@noam.fc.hp.com Wed, 01 Nov 2000 10:59:34 -0700 Date: Wed, 01 Nov 2000 10:59:34 -0700 From: Paul Bame bame@noam.fc.hp.com Subject: [parisc-linux] new method for 64-bit parisc tree I want to propose/discuss a new method for maintaining our 64-bit parisc tree in relation to the 32-bit tree. I have prototyped this and so far it seems pretty useful. Most of the files in the current parisc64 tree only contain one line, a #include of the same file from the parisc tree. This confuses 'make dep', causes some compile errors to have nonsense line numbers, and doesn't allow direct editing of the source files in the parisc64 tree. The method I'm proposing works like this: The future parisc64 tree ONLY contains files which are different from, or in addition to, those in the parisc tree. When you 'make config' or 'make oldconfig', each file in the parsic tree is symbolically linked as the same file in the parisc64 tree. This enables all the rest of the tools/build to work normally. 'make distclean' includes a step to remove all the symlinks. The ugliest "feature" is that even though you can edit source files in the parisc64 tree, 'cvs commit' will fail on those which are symbolic links. To reduce this problem, I'm dropping a symbolic link called '...' in each parisc64 directory which is a pointer to the corresponding parisc directory, so 'cd ...; cvs commit foo.c' will work and not be too onerous. We should additionally consider a naming convention or something so that maintainers in the parisc tree know whether files are shared with parisc64 or not. I prototyped this as a fictional new "architecture" called "p64". To try it out, grab the tarball (only about 30 files -- can be fewer) ftp://puffin.external.hp.com/pub/parisc/ and unpack in your top-level linux source tree directory. Then in your top-level Makefile, change ARCH := parisc64 to ARCH := p64, then make oldconfig or whatever you usually do. Let me know of any problems. Is this something we should adopt for the real parisc64 tree? -Paul Bame From kailasr@webcash.com Wed, 01 Nov 2000 12:30:40 -0800 Date: Wed, 01 Nov 2000 12:30:40 -0800 From: Kailashnath V Rampure kailasr@webcash.com Subject: [parisc-linux] NEW NATIVE PALO TARBALL - REQUIRED Thanks paul I was able to run the command. Can you let me know what I should type at ISL prompt as its trying to boot from /stand/vmunix instead of /boot/vmlinux. Also I am unable to open vi as it says vi:LINUX:unknown terminal type. Please suggest. Regards At 02:26 PM 10/31/00 -0700, Paul Bame wrote: >= Hi Paul, >= >= After booting the Server from NFSroot I need to Initialize the harddisk on >= the server. so I copied the palo and linux in to the nfsroot. I am trying >= to Run the following command: >= $ palo -I -k /boot/vmlinux -b /boot/iplboot -c '2/boot/vmlinux TERM=linux >= HOME=/ root=/dev/sda2' /dev/sda >= fisrt partition is 10M of type f0 >= second partition is /dev/sda2 of type linux native. >= Third partition is /dev/sda3 of type linux Swap > >That looks great. > >= Then I get the cannot execute binary file. > >Ok I think we changed the kernal such that the old palo bits won't run >any more (we removed the old gateway page). I uploaded a new version: >ftp://puffin.external.hp.com/pub/parisc/binaries/userspace/palo-200001031.tgz > > -P From matthew@wil.cx Thu, 2 Nov 2000 00:13:06 +0000 Date: Thu, 2 Nov 2000 00:13:06 +0000 From: Matthew Wilcox matthew@wil.cx Subject: linux bame On Wed, Nov 01, 2000 at 01:53:24PM -0700, Paul Bame wrote: > CVSROOT: /home/cvs/parisc > Module name: linux > Changes by: bame 00/11/01 13:53:24 > > Modified files: > include/asm-parisc64: posix_types.h > > Log message: > Don't need a separate copy of this one either err.. are you sure? we used to get a lot of prototype problems when they were the same file. what's changed that they're now able to be the same? -- Revolutions do not require corporate support. From bame@riverrock.org Wed, 01 Nov 2000 23:18:43 -0700 Date: Wed, 01 Nov 2000 23:18:43 -0700 From: bame@riverrock.org bame@riverrock.org Subject: linux bame = On Wed, Nov 01, 2000 at 01:53:24PM -0700, Paul Bame wrote: = > CVSROOT: /home/cvs/parisc = > Module name: linux = > Changes by: bame 00/11/01 13:53:24 = > = > Modified files: = > include/asm-parisc64: posix_types.h = > = > Log message: = > Don't need a separate copy of this one either = = err.. are you sure? we used to get a lot of prototype problems when they = were the same file. what's changed that they're now able to be the same? I changed the parisc version so that the data types would compile to the same size in both wide and narrow mode. Unfortunately there is at least one issue which will probably require this scheme to change :-( -P From grundler@cup.hp.com Thu, 2 Nov 2000 00:21:36 -0800 (PST) Date: Thu, 2 Nov 2000 00:21:36 -0800 (PST) From: Grant Grundler grundler@cup.hp.com Subject: [parisc-linux] a500.out16 Hi Richard (et al), I finally think I understand how pcibios_align_resource() is used... that definitely was the problem. Everything on A500 but PCI-PCI bridge seems to be assigned I/O port and MMIO addresses correctly. I'll look at tulip code tomorrow to see why it's not happy. 6 Tulips are behind PCI-PCI Bridges and that's part of the problem. But the complaints about "MMIO resource" list I/O Port addresses instead...and those look fine to me if they are treated like I/O port addresses... I'd also like to connect some more SCSI disks....but any clue what the "CACHE TEST FAILED" is about? But instead of putting out another tar ball, I'm committing my code. I haven't tested on c3k/j5k yet and it might be broken. 32-bit still builds and any fix should be simple - either cvs update back to an older date or put "if (pdc_pat) { }" around anything that I added that shouldn't be. Tell me to test/fix any brokeness you might find and I'll make time to do it. aplogies for the long delay, grant Firmware Version 40.32 Duplex Console IO Dependent Code (IODC) revision 1 ------------------------------------------------------------------------------ (c) Copyright 1995-1998, Hewlett-Packard Company, All rights reserved ------------------------------------------------------------------------------ Processor Speed State CoProcessor State Cache Size Number State Inst Data --------- -------- --------------------- ----------------- ------------ 0 440 MHz Active Functional 512 KB 1 MB 1 440 MHz Idle Functional 512 KB 1 MB Central Bus Speed (in MHz) : 111 Available Memory : 262144 KB Good Memory Required : 11468 KB Primary boot path: 0/0/1/1.15 Alternate boot path: 0/0/2/1.15 Console path: 0/0/4/0.0 Keyboard path: 0/0/4/0.0 WARNING: The non-destructive test bit was set, so memory was not tested destructively. Information only, no action required. ---- Main Menu --------------------------------------------------------------- Command Description ------- ----------- BOot [PRI|ALT|] Boot from specified path PAth [PRI|ALT] [] Display or modify a path SEArch [DIsplay|IPL] [] Search for boot devices COnfiguration menu Displays or sets boot values INformation menu Displays hardware information SERvice menu Displays service commands DIsplay Redisplay the current menu HElp [|] Display help for menu or command RESET Restart the system ---- Main Menu: Enter command or menu > bo lan Interact with IPL (Y, N, or Cancel)?> n Booting... Network Station Address 00306e-03799f System IP Address 15.8.80.78 Server IP Address 15.8.81.247 Boot IO Dependent Code (IODC) revision 2 HARD Booted. palo ipl grundler@hpisp747 Tue Oct 31 16:45:27 PST 2000 0/vmlinux 2708507 bytes @ 0x6800 0/palo-cmdline '0/vmlinux HOME=/ TERM=linux root=/dev/nfs nfsroot=15.8.81.247:/tftpboot/hppa64 ' Kernel: partition 0 file /vmlinux ELF64 executable Entry 00100000 first 00100000 n 4 Segment 0 load 00100000 size 1705408 mediaptr 0x1000 Segment 1 load 002a2000 size 407616 mediaptr 0x1a2000 Segment 2 load 00308000 size 131960 mediaptr 0x206000 Segment 3 load 0032c000 size 16384 mediaptr 0x227000 branching to kernel entry point 0x00100000 Set default PSW W bit to 1 PDC Console Initialized The 64-bit Kernel has started... Enabled FP coprocessor If this is the LAST MESSAGE YOU SEE, you're probably using 32-bit millicode by mistake. Free memory starts at: 0xc0371000 start_parisc(0x504d40,0x504d40,0x0,0x0) PALO command line: 'HOME=/ TERM=linux root=/dev/nfs nfsroot=15.8.81.247:/tftpboot/hppa64 ' PALO initrd 0-0 model 00005cb0 00000491 00000000 00000001 23355fdc 100000f0 00000008 000000b2 000000b2 vers 00000300 cpuid 0000022a CPUID vers 17 rev 10 Searching for devices in PDC firmware... processor hpa 0xfffffffffffa0000 CELL_GET_NUMBER: 0x0 0x1 PAT_ENTITY_PROC: id_eid 0xa0ff0000 PAT_ENTITY_PROC: id_eid 0xa2ff0000 PAT_ENTITY_MEM: amount 0x10000000 min_gni_base 0x0 min_gni_len 0x0 PAT_ENTITY_SBA: ranges 6 0: 0xc000000000000005 0xfffffffffed18000 0xfffffffffed2ffff 1: 0x8000000000000000 0x0000000000000000 0x000000000000003f 2: 0x8000000000000001 0xfffffffff8000000 0xfffffffffbffffff 3: 0x00040000001a1701 0xfffffffff0000000 0xfffffffff7ffffff 4: 0x00040000001a1701 0xfffffffffc000000 0xfffffffffecfffff 5: 0x8000000000000002 0xfffffff800000000 0xfffffffbffffffff PAT_ENTITY_LBA: ranges 4 0: 0x8000000000000000 0x0000000000000000 0x0000000000000007 1: 0x8000000000000001 0xfffffffff8000000 0xfffffffff87fffff 2: 0x8000000000000002 0xfffffff804000000 0xfffffff87fffffff 3: 0x8000000000000004 0xfffffff800000000 0xfffffff803ffffff PAT_ENTITY_LBA: ranges 4 0: 0x8000000000000000 0x0000000000000010 0x0000000000000017 1: 0x8000000000000001 0xfffffffff9000000 0xfffffffff97fffff 2: 0x8000000000000002 0xfffffff904000000 0xfffffff97fffffff 3: 0x8000000000000004 0xfffffff900000000 0xfffffff903ffffff PAT_ENTITY_LBA: ranges 4 0: 0x8000000000000000 0x0000000000000020 0x0000000000000027 1: 0x8000000000000001 0xfffffffffa000000 0xfffffffffa7fffff 2: 0x8000000000000002 0xfffffffa04000000 0xfffffffa7fffffff 3: 0x8000000000000004 0xfffffffa00000000 0xfffffffa03ffffff PAT_ENTITY_LBA: ranges 4 0: 0x8000000000000000 0x0000000000000030 0x0000000000000037 1: 0x8000000000000001 0xfffffffffb000000 0xfffffffffb7fffff 2: 0x8000000000000002 0xfffffffb04000000 0xfffffffb7fffffff 3: 0x8000000000000004 0xfffffffb00000000 0xfffffffb03ffffff Found devices: 1. Crescendo 440 (0) at 0xfffffffffffa0000, versions 0x5cb, 0x0, 0x4, 0x0, 0x91 2. Crescendo 440 (0) at 0xfffffffffffa2000, versions 0x5cb, 0x0, 0x4, 0x0, 0x91 3. Crescendo Memory (1) at 0xfffffffffed08000, versions 0x9b, 0x0, 0x9, 0x0, 0x0 4. Astro BC Runway Port (12) at 0xfffffffffed00000, versions 0x582, 0x0, 0xb, 0x0, 0x10 5. Elroy PCI Bridge (13) at 0xfffffffffed30000, versions 0x782, 0x0, 0xa, 0x0, 0x0 6. Elroy PCI Bridge (13) at 0xfffffffffed34000, versions 0x782, 0x0, 0xa, 0x0, 0x0 7. Elroy PCI Bridge (13) at 0xfffffffffed38000, versions 0x782, 0x0, 0xa, 0x0, 0x0 8. Elroy PCI Bridge (13) at 0xfffffffffed3c000, versions 0x782, 0x0, 0xa, 0x0, 0x0 That's a total of 8 devices. CONFIG_SMP disabled - not claiming addional CPUs Warning : device (0, 0x5cb, 0x0, 0x4, 0x0) NOT claimed by CPU PARISC CPU(s): 1 x PA8500 (PCX-W) at 440.000000 MHz Linux version 2.4.0-test6 (grundler@hpisp747) (gcc version 2.96 20000925 (experimental)) #73 Wed Nov 1 23:58:51 PST 2000 free_bootmem(0x373000, 0xfc8d000) initrd: 00000000-00000000 pagetable_init On node 0 totalpages: 65536 zone(0): 32768 pages. zone(1): 32768 pages. zone(2): 0 pages. Kernel command line: HOME=/ TERM=linux root=/dev/nfs nfsroot=15.8.81.247:/tftpboot/hppa64 trap_init Calibrating delay loop... 878.18 BogoMIPS kernel BUG at page_alloc.c:106! Memory: 248868k available Dentry-cache hash table entries: 32768 (order: 7, 524288 bytes) Buffer-cache hash table entries: 16384 (order: 5, 131072 bytes) Page-cache hash table entries: 65536 (order: 7, 524288 bytes) Inode-cache hash table entries: 16384 (order: 6, 262144 bytes) POSIX conformance testing by UNIFIX lba version TR4.0 (0x5) found at 0xfffffffffed30000 0: 0x8000000000000000 PA 0x0000000000000000,0x0000000000000007 IO 0x0000000000000000,0x0000000000000007 1: 0x8000000000000001 PA 0xfffffffff8000000,0xfffffffff87fffff IO 0x00000000f8000000,0x00000000f87fffff 2: 0x8000000000000002 PA 0xfffffff804000000,0xfffffff87fffffff IO 0x000000f804000000,0x000000f87fffffff lba range[2] : ignoring GMMIO (0xfffffff804000000) 3: 0x8000000000000004 PA 0xfffffff800000000,0xfffffff803ffffff IO 0x000000f800000000,0x000000f803ffffff lba_fixup_bus(0x00000000cffe60c0) bus 0 sysdata 0x00000000cffe9e80 cons 0x00002000 boot 0x00000000 kbd 0x00002000 claimed 00:00 0 [0,7f]/101 claimed 00:00 1 [fffffffff8020000,fffffffff80203ff]/200 claimed 00:20 0 [fffffffff8000000,fffffffff8000fff]/200 LBA PIOP resource tree 00000000cffe9ed0 [0,7ffff]/100 00000000cffe5080 [0,7f]/101 LBA pcibios_size_bridges() LBA pci_assign_unassigned_resources() pcibios_update_resource(00:08, ..., 0) [100,1ff]/101 pcibios_update_resource(00:08, ..., 1) [fffffffff8001000,fffffffff80013ff]/204 PCI: dev PCI device 1000:000b type 64-bit pcibios_update_resource(00:08, ..., 3) [fffffffff8002000,fffffffff8003fff]/204 PCI: dev PCI device 1000:000b type 64-bit pcibios_update_resource(00:09, ..., 0) [200,2ff]/101 pcibios_update_resource(00:09, ..., 1) [fffffffff8001400,fffffffff80017ff]/204 PCI: dev PCI device 1000:000b type 64-bit pcibios_update_resource(00:09, ..., 3) [fffffffff8004000,fffffffff8005fff]/204 PCI: dev PCI device 1000:000b type 64-bit pcibios_update_resource(00:10, ..., 0) [300,3ff]/101 pcibios_update_resource(00:10, ..., 1) [fffffffff8001800,fffffffff80018ff]/200 pcibios_update_resource(00:10, ..., 2) [fffffffff8006000,fffffffff8006fff]/200 pcibios_update_resource(00:11, ..., 0) [400,4ff]/101 pcibios_update_resource(00:11, ..., 1) [fffffffff8001900,fffffffff80019ff]/200 pcibios_update_resource(00:11, ..., 2) [fffffffff8007000,fffffffff8007fff]/200 pcibios_update_resource(00:20, ..., 1) [80,bf]/101 pcibios_update_resource(00:28, ..., 0) [fffffffff8008000,fffffffff8008fff]/200 pcibios_update_resource(00:28, ..., 1) [c0,ff]/101 LBA pci_set_bus_ranges() pcibios_fixup_pbus_ranges(0, [0,1000 fffffffff8000000,fffffffff8100000]) lba version TR4.0 (0x5) found at 0xfffffffffed34000 0: 0x8000000000000000 PA 0x0000000000000010,0x0000000000000017 IO 0x0000000000000010,0x0000000000000017 1: 0x8000000000000001 PA 0xfffffffff9000000,0xfffffffff97fffff IO 0x00000000f9000000,0x00000000f97fffff 2: 0x8000000000000002 PA 0xfffffff904000000,0xfffffff97fffffff IO 0x000000f904000000,0x000000f97fffffff lba range[2] : ignoring GMMIO (0xfffffff904000000) 3: 0x8000000000000004 PA 0xfffffff900000000,0xfffffff903ffffff IO 0x000000f900000000,0x000000f903ffffff lba_fixup_bus(0x00000000cffe62c0) bus 16 sysdata 0x00000000cffe61c0 cons 0x00002000 boot 0x00000000 kbd 0x00002000 LBA PIOP resource tree 00000000cffe6210 [100000,17ffff]/100 LBA pcibios_size_bridges() LBA pci_assign_unassigned_resources() pcibios_update_resource(10:00, ..., 1) [100000,1000ff]/101 pcibios_update_resource(10:00, ..., 2) [100100,1001ff]/101 pcibios_update_resource(10:00, ..., 3) [fffffffff9000000,fffffffff90001ff]/200 pcibios_update_resource(10:00, ..., 5) [fffffffff9020000,fffffffff903ffff]/200 LBA pci_set_bus_ranges() pcibios_fixup_pbus_ranges(0, [0,1000 fffffffff8000000,fffffffff8100000]) pcibios_fixup_pbus_ranges(16, [100000,101000 fffffffff9000000,fffffffff9100000]) lba version TR4.0 (0x5) found at 0xfffffffffed38000 0: 0x8000000000000000 PA 0x0000000000000020,0x0000000000000027 IO 0x0000000000000020,0x0000000000000027 1: 0x8000000000000001 PA 0xfffffffffa000000,0xfffffffffa7fffff IO 0x00000000fa000000,0x00000000fa7fffff 2: 0x8000000000000002 PA 0xfffffffa04000000,0xfffffffa7fffffff IO 0x000000fa04000000,0x000000fa7fffffff lba range[2] : ignoring GMMIO (0xfffffffa04000000) 3: 0x8000000000000004 PA 0xfffffffa00000000,0xfffffffa03ffffff IO 0x000000fa00000000,0x000000fa03ffffff lba_fixup_bus(0x00000000cffe64c0) bus 32 sysdata 0x00000000cffe63c0 cons 0x00002000 boot 0x00000000 kbd 0x00002000 LBA PIOP resource tree 00000000cffe6410 [200000,27ffff]/100 LBA pcibios_size_bridges() LBA pci_assign_unassigned_resources() pcibios_update_resource(20:00, ..., 0) [200000,2000ff]/101 pcibios_update_resource(20:00, ..., 1) [fffffffffa000000,fffffffffa0003ff]/204 PCI: dev PCI device 1000:000b type 64-bit pcibios_update_resource(20:00, ..., 3) [fffffffffa002000,fffffffffa003fff]/204 PCI: dev PCI device 1000:000b type 64-bit pcibios_update_resource(20:01, ..., 0) [200100,2001ff]/101 pcibios_update_resource(20:01, ..., 1) [fffffffffa000400,fffffffffa0007ff]/204 PCI: dev PCI device 1000:000b type 64-bit pcibios_update_resource(20:01, ..., 3) [fffffffffa004000,fffffffffa005fff]/204 PCI: dev PCI device 1000:000b type 64-bit LBA pci_set_bus_ranges() pcibios_fixup_pbus_ranges(0, [0,1000 fffffffff8000000,fffffffff8100000]) pcibios_fixup_pbus_ranges(16, [100000,101000 fffffffff9000000,fffffffff9100000]) pcibios_fixup_pbus_ranges(32, [200000,201000 fffffffffa000000,fffffffffa100000]) lba version TR4.0 (0x5) found at 0xfffffffffed3c000 0: 0x8000000000000000 PA 0x0000000000000030,0x0000000000000037 IO 0x0000000000000030,0x0000000000000037 1: 0x8000000000000001 PA 0xfffffffffb000000,0xfffffffffb7fffff IO 0x00000000fb000000,0x00000000fb7fffff 2: 0x8000000000000002 PA 0xfffffffb04000000,0xfffffffb7fffffff IO 0x000000fb04000000,0x000000fb7fffffff lba range[2] : ignoring GMMIO (0xfffffffb04000000) 3: 0x8000000000000004 PA 0xfffffffb00000000,0xfffffffb03ffffff IO 0x000000fb00000000,0x000000fb03ffffff lba_fixup_bus(0x00000000cffe66c0) bus 48 sysdata 0x00000000cffe65c0 cons 0x00002000 boot 0x00000000 kbd 0x00002000 lba_fixup_bus(0x00000000cffe67c0) bus 49 sysdata 0x00000000cffe65c0 cons 0x00002000 boot 0x00000000 kbd 0x00002000 lba_fixup_bus(0x00000000cffe68c0) bus 50 sysdata 0x00000000cffe65c0 cons 0x00002000 boot 0x00000000 kbd 0x00002000 LBA PIOP resource tree 00000000cffe6610 [300000,37ffff]/100 LBA pcibios_size_bridges() LBA pci_assign_unassigned_resources() PCI: Failed to allocate resource 0 for PCI device 1000:000b PCI: Failed to allocate resource 1 for PCI device 1000:000b PCI: Failed to allocate resource 3 for PCI device 1000:000b PCI: Failed to allocate resource 0 for PCI device 1000:000b PCI: Failed to allocate resource 1 for PCI device 1000:000b PCI: Failed to allocate resource 3 for PCI device 1000:000b PCI: Failed to allocate resource 0 for PCI device 1011:0019 PCI: Failed to allocate resource 1 for PCI device 1011:0019 PCI: Failed to allocate resource 0 for PCI device 1011:0019 PCI: Failed to allocate resource 1 for PCI device 1011:0019 PCI: Failed to allocate resource 0 for PCI device 1011:0009 PCI: Failed to allocate resource 1 for PCI device 1011:0009 PCI: Failed to allocate resource 0 for PCI device 1011:0009 PCI: Failed to allocate resource 1 for PCI device 1011:0009 PCI: Failed to allocate resource 0 for PCI device 1011:0009 PCI: Failed to allocate resource 1 for PCI device 1011:0009 PCI: Failed to allocate resource 0 for PCI device 1011:0009 PCI: Failed to allocate resource 1 for PCI device 1011:0009 LBA pci_set_bus_ranges() pcibios_fixup_pbus_ranges(0, [0,1000 fffffffff8000000,fffffffff8100000]) pcibios_fixup_pbus_ranges(16, [100000,101000 fffffffff9000000,fffffffff9100000]) pcibios_fixup_pbus_ranges(32, [200000,201000 fffffffffa000000,fffffffffa100000]) pcibios_fixup_pbus_ranges(49, [310000,311000 fffffffffb000000,fffffffffb100000]) pcibios_fixup_pbus_ranges(50, [320000,321000 fffffffffb000000,fffffffffb100000]) pcibios_fixup_pbus_ranges(48, [0,1000 fb000000,fb100000]) SBA found Astro 2.1 at 0xfffffffffed00000 lba_init_iregs() ibase 0x1 imask 0xf0000000 lba_init_iregs() base_addr fffffffffed3c000 lba_init_iregs() base_addr fffffffffed38000 lba_init_iregs() base_addr fffffffffed34000 lba_init_iregs() base_addr fffffffffed30000 lba_init_iregs() done lba: lba_bios_init Linux NET4.0 for Linux 2.4 Based upon Swansea University Computer Society NET3.039 NET4: Linux TCP/IP 1.0 for NET4.0 IP Protocols: ICMP, UDP, TCP IP: routing cache hash table of 1024 buckets, 16Kbytes TCP: Hash tables configured (established 8192 bind 8192) Starting kswapd v1.7 pty: 256 Unix98 ptys configured lp: driver loaded but no devices found RAMDISK driver initialized: 16 RAM disks of 4096K size 1024 blocksize sym53c8xx: at PCI bus 0, device 2, function 0 sym53c8xx: setting PCI_COMMAND_PARITY...(fix-up) sym53c8xx: changing PCI_LATENCY_TIMER from 0 to 80. kernel BUG at sym53c8xx.c:725! sym53c8xx: 53c876 detected sym53c8xx: at PCI bus 0, device 2, function 1 sym53c8xx: setting PCI_COMMAND_PARITY...(fix-up) sym53c8xx: changing PCI_LATENCY_TIMER from 0 to 80. kernel BUG at sym53c8xx.c:725! sym53c8xx: 53c876 detected sym53c8xx: at PCI bus 0, device 1, function 0 sym53c8xx: setting PCI_COMMAND_PARITY...(fix-up) sym53c8xx: changing PCI_LATENCY_TIMER from 0 to 80. kernel BUG at sym53c8xx.c:725! sym53c8xx: 53c896 detected sym53c8xx: at PCI bus 0, device 1, function 1 sym53c8xx: setting PCI_COMMAND_PARITY...(fix-up) sym53c8xx: changing PCI_LATENCY_TIMER from 0 to 80. kernel BUG at sym53c8xx.c:725! sym53c8xx: 53c896 detected sym53c8xx: at PCI bus 32, device 0, function 0 sym53c8xx: setting PCI_COMMAND_PARITY...(fix-up) sym53c8xx: changing PCI_LATENCY_TIMER from 0 to 80. kernel BUG at sym53c8xx.c:725! sym53c8xx: 53c896 detected sym53c8xx: at PCI bus 32, device 0, function 1 sym53c8xx: setting PCI_COMMAND_PARITY...(fix-up) sym53c8xx: changing PCI_LATENCY_TIMER from 0 to 80. kernel BUG at sym53c8xx.c:725! sym53c8xx: 53c896 detected sym53c8xx: at PCI bus 49, device 4, function 0 sym53c8xx: setting PCI_COMMAND_PARITY...(fix-up) sym53c8xx: changing PCI_LATENCY_TIMER from 0 to 80. kernel BUG at sym53c8xx.c:725! sym53c8xx: 53c896 detected sym53c8xx: at PCI bus 49, device 4, function 1 sym53c8xx: setting PCI_COMMAND_PARITY...(fix-up) sym53c8xx: changing PCI_LATENCY_TIMER from 0 to 80. kernel BUG at sym53c8xx.c:725! sym53c8xx: 53c896 detected kernel BUG at sym53c8xx.c:725! sym53c876-0: rev 0x14 on pci bus 0 device 2 function 0 irq 130 sym53c876-0: NCR clock is 40218KHz sym53c876-0: ID 7, Fast-20, Parity Checking sym53c876-0: on-chip RAM at 0xfffffffff8006000 sym53c876-0: restart (scsi reset). sym53c876-0: Downloading SCSI SCRIPTS. kernel BUG at sym53c8xx.c:725! sym53c876-1: rev 0x14 on pci bus 0 device 2 function 1 irq 131 sym53c876-1: NCR clock is 40218KHz sym53c876-1: ID 7, Fast-20, Parity Checking sym53c876-1: on-chip RAM at 0xfffffffff8007000 sym53c876-1: restart (scsi reset). sym53c876-1: Downloading SCSI SCRIPTS. kernel BUG at sym53c8xx.c:725! sym53c896-2: rev 0x7 on pci bus 0 device 1 function 0 irq 129 sym53c896-2: NCR clock is 40218KHz sym53c896-2: ID 7, Fast-40, Parity Checking sym53c896-2: on-chip RAM at 0xfffffffff8002000 sym53c896-2: restart (scsi reset). sym53c896-2: handling phase mismatch from SCRIPTS. sym53c896-2: Downloading SCSI SCRIPTS. kernel BUG at sym53c8xx.c:725! sym53c896-3: rev 0x7 on pci bus 0 device 1 function 1 irq 130 sym53c896-3: NCR clock is 40218KHz sym53c896-3: ID 7, Fast-40, Parity Checking sym53c896-3: on-chip RAM at 0xfffffffff8004000 sym53c896-3: restart (scsi reset). sym53c896-3: handling phase mismatch from SCRIPTS. sym53c896-3: Downloading SCSI SCRIPTS. kernel BUG at sym53c8xx.c:725! sym53c896-4: rev 0x1 on pci bus 32 device 0 function 0 irq 256 sym53c896-4: NCR clock is 40218KHz sym53c896-4: ID 7, Fast-40, Parity Checking sym53c896-4: on-chip RAM at 0xfffffffffa002000 sym53c896-4: restart (scsi reset). sym53c896-4: handling phase mismatch from SCRIPTS. sym53c896-4: Downloading SCSI SCRIPTS. kernel BUG at sym53c8xx.c:725! sym53c896-5: rev 0x1 on pci bus 32 device 0 function 1 irq 257 sym53c896-5: NCR clock is 40218KHz sym53c896-5: ID 7, Fast-40, Parity Checking sym53c896-5: on-chip RAM at 0xfffffffffa004000 sym53c896-5: restart (scsi reset). sym53c896-5: handling phase mismatch from SCRIPTS. sym53c896-5: Downloading SCSI SCRIPTS. kernel BUG at sym53c8xx.c:725! sym53c896-6: rev 0x5 on pci bus 49 device 4 function 0 irq 323 sym53c896-6: ID 7, Fast-40, Parity Checking sym53c896-6: on-chip RAM at 0xfffffffffb000000 CACHE TEST FAILED: reg dstat-sstat2 readback ffffffff. CACHE INCORRECTLY CONFIGURED. sym53c896-6: giving up ... kernel BUG at sym53c8xx.c:725! kernel BUG at sym53c8xx.c:725! kernel BUG at sym53c8xx.c:725! sym53c896-6: rev 0x5 on pci bus 49 device 4 function 1 irq 320 sym53c896-6: ID 7, Fast-40, Parity Checking sym53c896-6: on-chip RAM at 0xfffffffffb000000 CACHE TEST FAILED: reg dstat-sstat2 readback ffffffff. CACHE INCORRECTLY CONFIGURED. sym53c896-6: giving up ... kernel BUG at sym53c8xx.c:725! kernel BUG at sym53c8xx.c:725! scsi0 : sym53c8xx - version 1.6b scsi1 : sym53c8xx - version 1.6b scsi2 : sym53c8xx - version 1.6b scsi3 : sym53c8xx - version 1.6b scsi4 : sym53c8xx - version 1.6b scsi5 : sym53c8xx - version 1.6b scsi : 6 hosts. Vendor: SEAGATE Model: ST318404LC Rev: HP01 Type: Direct-Access ANSI SCSI revision: 03 Detected scsi disk sda at scsi3, channel 0, id 15, lun 0 sym53c896-3-<15,0>: tagged command queue depth set to 8 scsi : detected 1 SCSI disk total. sym53c896-3-<15,0>: wide msgout: 1-2-3-1. sym53c896-3-<15,0>: wide msgin: 1-2-3-1. sym53c896-3-<15,0>: wide: wide=1 chg=0. sym53c896-3-<15,0>: wide msgout: 1-2-3-1. sym53c896-3-<15,0>: wide msgin: 1-2-3-1. sym53c896-3-<15,0>: wide: wide=1 chg=0. sym53c896-3-<15,0>: sync msgout: 1-3-1-c-1f. sym53c896-3-<15,0>: sync msg in: 1-3-1-c-1f. sym53c896-3-<15,0>: sync: per=12 scntl3=0xb0 scntl4=0x0 ofs=31 fak=0 chg=0. sym53c896-3-<15,*>: FAST-20 WIDE SCSI 40.0 MB/s (50 ns, offset 31) SCSI device sda: hdwr sector= 512 bytes. Sectors= 35566480 [17366 MB] [17.4 GB] Partition check: sda: unknown partition table Serial driver version 5.01 (2000-05-29) with MANY_PORTS SHARE_IRQ SERIAL_PCI enabled Linux Tulip driver version 0.9.8 (July 13, 2000) tulip: MMIO resource (0x80@0x0) unavailable, aborting tulip: MMIO resource (0x80@0x310200) unavailable, aborting tulip: MMIO resource (0x80@0x310280) unavailable, aborting tulip: MMIO resource (0x80@0x320300) unavailable, aborting tulip: MMIO resource (0x80@0x320380) unavailable, aborting tulip: MMIO resource (0x80@0x320400) unavailable, aborting tulip: MMIO resource (0x80@0x320480) unavailable, aborting IP-Config: No network devices available. Switching from PDC console From alan@linuxcare.com.au Thu, 2 Nov 2000 19:51:19 +1100 (EST) Date: Thu, 2 Nov 2000 19:51:19 +1100 (EST) From: Alan Modra alan@linuxcare.com.au Subject: [parisc-linux] new method for 64-bit parisc tree On Wed, 1 Nov 2000, Paul Bame wrote: > The future parisc64 tree ONLY contains files which are different from, > or in addition to, those in the parisc tree. When you 'make config' > or 'make oldconfig', each file in the parsic tree is symbolically > linked as the same file in the parisc64 tree. This enables all > the rest of the tools/build to work normally. 'make distclean' includes > a step to remove all the symlinks. Instead, can't you simply play tricks with -I, and add a symbolic link asm -> ../asm-parisc in asm-parisc64)? The idea being to end up with an include path looking like "-I $(TOPDIR)/include -I $(TOPDIR)/include/asm" That way, asm/foo.h is found by the first -I if we have asm-parisc64/foo.h, and is found by the second if asm-parisc/foo.h exists but not asm-parisc64/foo.h. Hmm, you might also need -I- -- Linuxcare. Support for the Revolution. From rhirst@linuxcare.com Thu, 2 Nov 2000 10:43:06 +0000 Date: Thu, 2 Nov 2000 10:43:06 +0000 From: Richard Hirst rhirst@linuxcare.com Subject: [parisc-linux] a500.out16 On Thu, Nov 02, 2000 at 12:21:36AM -0800, Grant Grundler wrote: > Hi Richard (et al), > I finally think I understand how pcibios_align_resource() is used... > that definitely was the problem. Everything on A500 but PCI-PCI bridge > seems to be assigned I/O port and MMIO addresses correctly. > > I'll look at tulip code tomorrow to see why it's not happy. I fixed tulip_core.c to report what it means, which gave me tulip: MMIO resource (0x400@0xfffffffff8020000) unavailable, aborting Note sym53c8xx.c doesn't seem to bother with request_mem_region(), so maybe request_mem_region() is just broken. I then patched out the goto, so it ignored that error, and.... Linux Tulip driver version 0.9.8 (July 13, 2000) tulip: MMIO resource (0x400@0xfffffffff8020000) unavailable, aborting PCI: Setting latency timer of device 00:00.0 to 64 eth0: Digital DS21143 Tulip rev 65 at 0x0, 00:30:6E:03:79:A0, IRQ 128. eth0: MII transceiver #1 config 1000 status 782d advertising 01e1. Sending BOOTP requests.... OK IP-Config: Got BOOTP answer from 10.160.240.111, my address is 10.160.240.117 Switching from PDC console Wheeee! Nice work Grant! Richard From rhirst@linuxcare.com Thu, 2 Nov 2000 10:48:33 +0000 Date: Thu, 2 Nov 2000 10:48:33 +0000 From: Richard Hirst rhirst@linuxcare.com Subject: [parisc-linux] a500.out16 On Thu, Nov 02, 2000 at 12:21:36AM -0800, Grant Grundler wrote: > I'd also like to connect some more SCSI disks....but any clue > what the "CACHE TEST FAILED" is about? .... > sym53c896-6: rev 0x5 on pci bus 49 device 4 function 0 irq 323 > sym53c896-6: ID 7, Fast-40, Parity Checking > sym53c896-6: on-chip RAM at 0xfffffffffb000000 > CACHE TEST FAILED: reg dstat-sstat2 readback ffffffff. > CACHE INCORRECTLY CONFIGURED. I'd guess that the NCR registers are being cached: static int __init ncr_regtest (struct ncb* np) { register volatile u_int32 data; /* ** ncr registers may NOT be cached. ** write 0xffffffff to a read only register area, ** and try to read it back. */ data = 0xffffffff; OUTL_OFF(offsetof(struct ncr_reg, nc_dstat), data); data = INL_OFF(offsetof(struct ncr_reg, nc_dstat)); #if 1 if (data == 0xffffffff) { #else if ((data & 0xe2f0fffd) != 0x02000080) { #endif printk ("CACHE TEST FAILED: reg dstat-sstat2 readback %x.\n", (unsigned) data); return (0x10); }; return (0); } Richard From fl@fl.priv.at Thu, 02 Nov 2000 12:15:17 +0100 Date: Thu, 02 Nov 2000 12:15:17 +0100 From: Friedrich Lobenstock fl@fl.priv.at Subject: [parisc-linux] HP 3000 - 922LX ?? Hi! How about support for a HP3000-922LX? I think this should be a PA-RISC machine. PS: Please CC me, because I'm not on the list. MfG / Regards Friedrich Lobenstock From rhirst@linuxcare.com Thu, 2 Nov 2000 11:30:47 +0000 Date: Thu, 2 Nov 2000 11:30:47 +0000 From: Richard Hirst rhirst@linuxcare.com Subject: [parisc-linux] a500.out16 On Thu, Nov 02, 2000 at 10:43:06AM +0000, Richard Hirst wrote: > On Thu, Nov 02, 2000 at 12:21:36AM -0800, Grant Grundler wrote: > > Hi Richard (et al), > > I finally think I understand how pcibios_align_resource() is used... > > that definitely was the problem. Everything on A500 but PCI-PCI bridge > > seems to be assigned I/O port and MMIO addresses correctly. > > > > I'll look at tulip code tomorrow to see why it's not happy. > > I fixed tulip_core.c to report what it means, which gave me > > tulip: MMIO resource (0x400@0xfffffffff8020000) unavailable, aborting > > Note sym53c8xx.c doesn't seem to bother with request_mem_region(), so > maybe request_mem_region() is just broken. It is broken because of the following line in kernel/resource.c: struct resource iomem_resource = { "PCI mem", 0x00000000, 0xffffffff, IORESOURCE_MEM }; 'end' needs to be rather higher than 0xffffffff on 64 bit. I changed it to struct resource iomem_resource = { "PCI mem", 0x00000000, ~0, IORESOURCE_MEM }; and it works. I havn't committed that 'fix' though. Richard From matthew@wil.cx Thu, 2 Nov 2000 11:57:53 +0000 Date: Thu, 2 Nov 2000 11:57:53 +0000 From: Matthew Wilcox matthew@wil.cx Subject: [parisc-linux] HP 3000 - 922LX ?? On Thu, Nov 02, 2000 at 12:15:17PM +0100, Friedrich Lobenstock wrote: > Hi! > > How about support for a HP3000-922LX? I think this should be a PA-RISC > machine. According to the docs: http://www.thepuffingroup.com/parisc/hp9000_models.html the 922 is the same physical machine as the 822. As such, it's too old for it to be worth supporting. the official statement is... The earliest PA-RISC servers have proprietary HP devices attached to proprietary HP bus architectures. It is unlikely that documentation on these busses and devices will ever become available, since so few people are interested in spending any effort finding and releasing the docs. Machines in this category are the E, F, G, H, I class (aka Nova) and T500 series (Emerald) machines as well as some earlier, unlettered servers. I should perhaps update this to reflect the particular model numbers. -- Revolutions do not require corporate support. From rhirst@linuxcare.com Thu, 2 Nov 2000 12:07:36 +0000 Date: Thu, 2 Nov 2000 12:07:36 +0000 From: Richard Hirst rhirst@linuxcare.com Subject: [parisc-linux] a500.out16 On Thu, Nov 02, 2000 at 10:43:06AM +0000, Richard Hirst wrote: > Linux Tulip driver version 0.9.8 (July 13, 2000) > tulip: MMIO resource (0x400@0xfffffffff8020000) unavailable, aborting > PCI: Setting latency timer of device 00:00.0 to 64 > eth0: Digital DS21143 Tulip rev 65 at 0x0, 00:30:6E:03:79:A0, IRQ 128. > eth0: MII transceiver #1 config 1000 status 782d advertising 01e1. > Sending BOOTP requests.... OK > IP-Config: Got BOOTP answer from 10.160.240.111, my address is 10.160.240.117 > Switching from PDC console > > Wheeee! Nice work Grant! And if you stop it from trying to switch from pdc to ttyS0 console: Linux Tulip driver version 0.9.8 (July 13, 2000) PCI: Setting latency timer of device 00:00.0 to 64 eth0: Digital DS21143 Tulip rev 65 at 0x0, 00:30:6E:03:79:A0, IRQ 128. eth0: MII transceiver #1 config 1000 status 782d advertising 01e1. Sending BOOTP requests.... OK IP-Config: Got BOOTP answer from 10.160.240.111, my address is 10.160.240.117 kmem_create: Forcing size word alignment - nfs_fh Looking up port of RPC 100003/2 on 10.160.240.111 Looking up port of RPC 100005/2 on 10.160.240.111 VFS: Mounted root (nfs filesystem) readonly. Warning: unable to open an initial console. Kernel panic: Attempted to kill init! Richard From matthew@wil.cx Thu, 2 Nov 2000 12:01:58 +0000 Date: Thu, 2 Nov 2000 12:01:58 +0000 From: Matthew Wilcox matthew@wil.cx Subject: [parisc-linux] a500.out16 On Thu, Nov 02, 2000 at 11:30:47AM +0000, Richard Hirst wrote: > > Note sym53c8xx.c doesn't seem to bother with request_mem_region(), so > > maybe request_mem_region() is just broken. > > It is broken because of the following line in kernel/resource.c: > > struct resource iomem_resource = { "PCI mem", 0x00000000, 0xffffffff, IORESOURCE_MEM }; > > 'end' needs to be rather higher than 0xffffffff on 64 bit. I changed it to > > struct resource iomem_resource = { "PCI mem", 0x00000000, ~0, IORESOURCE_MEM }; > > and it works. I havn't committed that 'fix' though. Probably just as well... the pci_consistent interfaces were designed partly to stop 32-bit PCI cards having to do dual-address-cycle on machines with an IOMMU. if you can, this card should get mapped below the 32-bit boundary. -- Revolutions do not require corporate support. From grundler@cup.hp.com Thu, 02 Nov 2000 08:12:47 -0800 Date: Thu, 02 Nov 2000 08:12:47 -0800 From: Grant Grundler grundler@cup.hp.com Subject: [parisc-linux] a500.out16 This is why I do NOT like our current scheme of using host physical addresses to access I/O space. Richard Hirst wrote: ... > I'd guess that the NCR registers are being cached: > > > static int __init ncr_regtest (struct ncb* np) > { > register volatile u_int32 data; > /* > ** ncr registers may NOT be cached. > ** write 0xffffffff to a read only register area, > ** and try to read it back. > */ > data = 0xffffffff; > OUTL_OFF(offsetof(struct ncr_reg, nc_dstat), data); > data = INL_OFF(offsetof(struct ncr_reg, nc_dstat)); If INL_OFF and OUTL_OFF are broken, they will very likely point to something in memory - page zero. And happily scribble over it gsc_write(xxx). We don't cache I/O space. Never. Something is definitely broken on this code path. I'll look at this once I find out what I broke on the j5k/c3k boot path in lba_pci.c. jsm already restored the previous version of lba_pci.c so folks can still boot 32-bit on c3k/j5k. grant Grant Grundler Unix Systems Enablement Lab +1.408.447.7253 From bame@riverrock.org Thu, 02 Nov 2000 09:20:24 -0700 Date: Thu, 02 Nov 2000 09:20:24 -0700 From: bame@riverrock.org bame@riverrock.org Subject: [parisc-linux] new method for 64-bit parisc tree I want to hear concerns because without serious ones I'm going to make this change next week... = Instead, can't you simply play tricks with -I, and add a symbolic link = asm -> ../asm-parisc in asm-parisc64)? The idea being to end up with = an include path looking like = "-I $(TOPDIR)/include -I $(TOPDIR)/include/asm" = = That way, asm/foo.h is found by the first -I if we have asm-parisc64/foo.h, = and is found by the second if asm-parisc/foo.h exists but not = asm-parisc64/foo.h. Hmm, you might also need -I- That would function fine for header files, but not for source files where something like VPATH might work, but is not available to us. It's worth noting that both -I and VPATH tricks mean if you have an error in or need to change a file, you may have to examine two directories to figure out where it really lives. The symbolic link scheme solves some of that problem. -P From dkennedy@linuxcare.com Thu, 2 Nov 2000 12:30:32 -0800 (PST) Date: Thu, 2 Nov 2000 12:30:32 -0800 (PST) From: dkennedy dkennedy@linuxcare.com Subject: [parisc-linux] Boot Problems with 755 On Mon, 30 Oct 2000, Matthew Wilcox wrote: > This isn't tagged correctly in the hwdb. Could someone inside linuxcare > please fix this? It should be supported by the Apricot driver. I have updated the hwdb to include the Coral II Core Lan Apricot driver. -- David Kennedy, Technical Account Manager, Linuxcare, Inc. 613.562.9594 tel, 613.562.9304 fax dkennedy@linuxcare.com, http://www.linuxcare.com/ Linuxcare. Support for the revolution. From grundler@cup.hp.com Thu, 02 Nov 2000 08:42:06 -0800 Date: Thu, 02 Nov 2000 08:42:06 -0800 From: Grant Grundler grundler@cup.hp.com Subject: [parisc-linux] a500.out16 Matthew Wilcox wrote: > On Thu, Nov 02, 2000 at 11:30:47AM +0000, Richard Hirst wrote: > > > Note sym53c8xx.c doesn't seem to bother with request_mem_region(), so > > > maybe request_mem_region() is just broken. > > > > It is broken because of the following line in kernel/resource.c: > > > > struct resource iomem_resource = { "PCI mem", 0x00000000, 0xffffffff, IORES > OURCE_MEM }; > > > > 'end' needs to be rather higher than 0xffffffff on 64 bit. I changed it to > > > > struct resource iomem_resource = { "PCI mem", 0x00000000, ~0, IORESOURCE_ME > M }; > > > > and it works. I havn't committed that 'fix' though. > > Probably just as well... the pci_consistent interfaces were designed > partly to stop 32-bit PCI cards having to do dual-address-cycle on > machines with an IOMMU. if you can, this card should get mapped below > the 32-bit boundary. Mathew, That's not the whole story. The value (0xfffffffff8020000) seen by the PCI driver *is* a 32-bit PCI address - dual address cycles are not needed. pcibios_update_resource() mangles the address the PCI device driver uses to fit the BAR it's supposed to get written to. See arch/parisc/kernel/pci.c and I think you'll understand. I think you are confusing DMA with PIO (register accesses). The address above is only used to PIO to access registers and has nothing to do with DMA (or I/O MMUs). And PCI device's that can do dual address cycle *should* in order to *avoid* the I/O MMU. The I/O MMU introduces a latency in the DMA path which ideally would be avoided. Of course, there are lots of issues with making that actually work...but it can work. I haven't looked at the whole issue of 64-bit BAR's yet. Mostly because I haven't had to. 64-bit BAR's work just fine when the upper 32-bits are zero'd. :^) But also because the 896 chip (older rev's at least) has 64-bit BARs and it didn't work during N-class bringup in Feb 1999. Currently shipping revs may work. A hack needs to go into pci_quirks.c to support 896 64-bit BARs. thanks for the ideas though, grant Grant Grundler Unix Systems Enablement Lab +1.408.447.7253 From headcrusher@web.de Thu, 2 Nov 2000 19:58:51 +0100 Date: Thu, 2 Nov 2000 19:58:51 +0100 From: =?iso-8859-1?Q? Alexander=20Sch=F6ck ?= headcrusher@web.de Subject: [parisc-linux] Help!? Hallo Puffingroup-Team, I have a very important question about the installation of the linux for PARisc. I hope you can help me! OK, i have a 725/100 Unix Workstation, i tried to install the PARisc-linux on this machine. The CD is booting from this machine, but in the middle of the booting phase the system hang on following line: "request_irq(259, c01ec76c, 0x0, asp, c3rcd080)" - So, what's wrong? How can I go on with the installation? Bye, Alexander S. _______________________________________________________________________ 1.000.000 DM gewinnen - kostenlos tippen - http://millionenklick.web.de IhrName@web.de, 8MB Speicher, Verschluesselung - http://freemail.web.de From matthew@wil.cx Fri, 3 Nov 2000 00:08:06 +0000 Date: Fri, 3 Nov 2000 00:08:06 +0000 From: Matthew Wilcox matthew@wil.cx Subject: [parisc-linux] Help!? On Thu, Nov 02, 2000 at 07:58:51PM +0100, Alexander Schöck wrote: > How can I go on with the installation? question added to the FAQ: 7. I'm using the Alpha 0.1 release CD and the machine stops after printing request_irq(259, c01ec76c, 0x0, asp, c3rcd080) what's going on? This is a bug in the kernel shipped on the CD. It only affects certain machines and has been fixed in the current CVS tree. We recommend you acquire a newer kernel from the FTP site. -- Revolutions do not require corporate support. From kailasr@webcash.com Thu, 02 Nov 2000 17:29:19 -0800 Date: Thu, 02 Nov 2000 17:29:19 -0800 From: Kailashnath V Rampure kailasr@webcash.com Subject: [parisc-linux] Boot command Hi, I have run the following command to initialize the sda harddisk. The sda3 is the linux native partion. Wen I say boot on the HP server it is trying to boot from /stand/vmunix instead of vmlinux can any one help me about the command. Secondaly I want to knwo what is the term type as its not taking vt100 so I am unable to open vi. I have made nesessary changes for the /etc/fstab $ palo -I -k /boot/vmlinux -b /boot/iplboot -c '3/boot/vmlinux TERM=linux HOME=/ root=/dev/sda3' /dev/sda regards Kailas From grundler@cup.hp.com Thu, 02 Nov 2000 17:44:23 -0800 Date: Thu, 02 Nov 2000 17:44:23 -0800 From: Grant Grundler grundler@cup.hp.com Subject: [parisc-linux] Boot command Kailashnath V Rampure wrote: > Hi, > I have run the following command to initialize the sda harddisk. The sda3 > is the linux native partion. > Wen I say boot on the HP server it is trying to boot from /stand/vmunix > instead of vmlinux can any one help me about the command. Sounds like your system is booting from an existing HPUX installed disk. Ie you are not using palo. > Secondaly I want > to knwo what is the term type as its not taking vt100 so I am unable to > open vi. TERM=linux is what I've seen before. The debian ncurses package might need to be installed first though and vt100 should work too. Search the mail archive at http://puffin.external.hp.com/cgi-bin/mailgrep grant > > I have made nesessary changes for the /etc/fstab > > $ palo -I -k /boot/vmlinux -b /boot/iplboot -c '3/boot/vmlinux TERM=linux > HOME=/ root=/dev/sda3' /dev/sda > > regards > Kailas > > --------------------------------------------------------------------------- > To unsubscribe: send e-mail to parisc-linux-request@thepuffingroup.com with > `unsubscribe' as the subject. > Grant Grundler Unix Systems Enablement Lab +1.408.447.7253 From taggart@carmen.fc.hp.com Thu, 02 Nov 2000 18:47:33 -0700 Date: Thu, 02 Nov 2000 18:47:33 -0700 From: Matt Taggart taggart@carmen.fc.hp.com Subject: [parisc-linux] Boot command Kailashnath V Rampure writes... > Hi, > I have run the following command to initialize the sda harddisk. The sda3 > is the linux native partion. > Wen I say boot on the HP server it is trying to boot from /stand/vmunix > instead of vmlinux can any one help me about the command. This means that you are somehow still booting an HP-UX lifimage. Did you follow the directions on, http://www.thepuffingroup.com/parisc/install.html including the partitioning stuff? Maybe you're still booting off another disk, are you sure you're booting from the linux disk? HTH, -- Matt Taggart taggart@fc.hp.com From headcrusher@web.de Fri, 3 Nov 2000 08:04:31 +0100 Date: Fri, 3 Nov 2000 08:04:31 +0100 From: =?iso-8859-1?Q? Alexander=20Sch=F6ck ?= headcrusher@web.de Subject: [parisc-linux] Help!? I downloaded a new kernel from the ftp-site, how can i use this kernel to work with my machine? This is a image file, how can i extract this file, or must i copy it only to the boot-cd? How can i use this kernel? Matthew Wilcox schrieb am 03.11.00: > On Thu, Nov 02, 2000 at 07:58:51PM +0100, Alexander Schöck wrote: > > How can I go on with the installation? > > question added to the FAQ: > > 7. I'm using the Alpha 0.1 release CD and the machine stops after printing > request_irq(259, c01ec76c, 0x0, asp, c3rcd080) > what's going on? > > This is a bug in the kernel shipped on the CD. It only affects certain > machines and has been fixed in the current CVS tree. We recommend you > acquire a newer kernel from the FTP site. > > -- > Revolutions do not require corporate support. > _______________________________________________________________________ 1.000.000 DM gewinnen - kostenlos tippen - http://millionenklick.web.de IhrName@web.de, 8MB Speicher, Verschluesselung - http://freemail.web.de From pdbeal@louisville.edu Fri, 3 Nov 2000 10:02:39 -0500 Date: Fri, 3 Nov 2000 10:02:39 -0500 From: Phillip Beal pdbeal@louisville.edu Subject: [parisc-linux] STI Console problems on 735 and 755 Hey, After all the help I obtained from this list, both through my posts and through the archives, I've finally gotten the 735 and 755, that I have access to, to boot and run linux. However, as soon as it starts to process init, the console screen becomes garbled. The system continues to boot, and I can access the machine via serial console and minicom, but the physical console on the box, just prints garbage. Is this normal for this stage of development? I couldn't see anything in the archives, that said it was, so I'm wondering how I fix this problem, if its been fixed before. Thanks, -- Phillip Beal Electrical and Computer Engineering S+LUG Vice-President From adevries@linuxcare.com Fri, 03 Nov 2000 11:37:08 -0500 Date: Fri, 03 Nov 2000 11:37:08 -0500 From: Alex deVries adevries@linuxcare.com Subject: [parisc-linux] STI Console problems on 735 and 755 Phillip Beal wrote: > After all the help I obtained from this list, both through my posts and > through the archives, I've finally gotten the 735 and 755, that I have > access to, to boot and run linux. However, as soon as it starts to > process init, the console screen becomes garbled. The system continues > to boot, and I can access the machine via serial console and minicom, > but the physical console on the box, just prints garbage. Is this > normal for this stage of development? I couldn't see anything in the > archives, that said it was, so I'm wondering how I fix this problem, if > its been fixed before. Good to hear that your 735 and 755 start to boot! What kind of graphics hardware is sitting on a 735 or 755? I think we've only ever looked at that on a 712 and 715. Can you use serial console in the meantime? - Alex -- Alex deVries, Principal Solutions Architect, The Puffins at Linuxcare 613.562.2759 tel alex@linuxcare.com, http://www.linuxcare.com/ Linuxcare, Support for the revolution. From pdbeal@louisville.edu Fri, 3 Nov 2000 10:49:00 -0500 Date: Fri, 3 Nov 2000 10:49:00 -0500 From: Phillip Beal pdbeal@louisville.edu Subject: [parisc-linux] STI Console problems on 735 and 755 > What kind of graphics hardware is sitting on a 735 or 755? I think > we've only ever looked at that on a 712 and 715. Both the 735 and the 755 have the following device, that seems be refer to the graphics: Coral SGC Graphics (10) at 0xf8000000, version 0x4, 0x0, 0x77, 0x0, 0x0 However, the 755 is known only to use mono graphics, even though they both report the same info for the Coral SGC Grpahics. I hope this helps, > Can you use serial console in the meantime? Yeah, serial works just fine. > > - Alex > > -- > Alex deVries, Principal Solutions Architect, The Puffins at Linuxcare > 613.562.2759 tel > alex@linuxcare.com, http://www.linuxcare.com/ > Linuxcare, Support for the revolution. -- Phillip Beal Electrical and Computer Engineering S+LUG Vice-President From kailasr@webcash.com Fri, 03 Nov 2000 11:03:23 -0800 Date: Fri, 03 Nov 2000 11:03:23 -0800 From: Kailashnath V Rampure kailasr@webcash.com Subject: [parisc-linux] Boot command Yes I have been following the same Doc. its tries to boot from the sda as I can see the hard disk path. I have 2 Hdd's one sda and other sdb. the path are 8/16/5.6 and other is 8/16/5.0. Here I think /dev/sda is 8/16/5.6. It is trying to boot but give sthe following o/p: Boot IO Dependent Code (IODC) revision 144 .... SUCCEEDED! HARD Booted. palo ipl bame@noam Tue Oct 31 14:18:02 MST 2000 0/vmlinux 208896 bytes @ 0x1f78c000 0/palo-cmdline '3/boot/vmlinux TERM=linux Home=/ root=/dev/sdb3' /dev/ida1 82 62 1030688 /dev/ida2 f0 1030750 24738 /dev/ida3 83 1055488 1030750 Kernel:partition 3 file /boot/vmlinux ext2 block size 1024 ext2_mount(partition 3) returns 0 ext2_open(/boot/vmlinux)=3 Couldn't gork your kernel executabel format failed to load kernel Failed to load Kernel. please suggest. At 06:47 PM 11/2/00 -0700, Matt Taggart wrote: >Kailashnath V Rampure writes... > > > Hi, > > I have run the following command to initialize the sda harddisk. The sda3 > > is the linux native partion. > > Wen I say boot on the HP server it is trying to boot from /stand/vmunix > > instead of vmlinux can any one help me about the command. > >This means that you are somehow still booting an HP-UX lifimage. Did you >follow the directions on, > >http://www.thepuffingroup.com/parisc/install.html > >including the partitioning stuff? Maybe you're still booting off another >disk, >are you sure you're booting from the linux disk? > >HTH, > >-- >Matt Taggart >taggart@fc.hp.com From grundler@cup.hp.com Fri, 03 Nov 2000 11:19:29 -0800 Date: Fri, 03 Nov 2000 11:19:29 -0800 From: Grant Grundler grundler@cup.hp.com Subject: [parisc-linux] Boot command Kailashnath V Rampure wrote: > Yes I have been following the same Doc. > its tries to boot from the sda as I can see the hard disk path. I have 2 > Hdd's one sda and other sdb. the path are 8/16/5.6 and other is 8/16/5.0. > Here I think /dev/sda is 8/16/5.6. The lower numbered SCSI ID will be /dev/sda. SCSI devices are lettered in the order they are discovered. The order is reflected in /proc/scsi/scsi. grant Grant Grundler Unix Systems Enablement Lab +1.408.447.7253 From kailasr@webcash.com Fri, 03 Nov 2000 11:46:39 -0800 Date: Fri, 03 Nov 2000 11:46:39 -0800 From: Kailashnath V Rampure kailasr@webcash.com Subject: [parisc-linux] Boot command I have removed the 2nd HDD now the boot is trying but I get the same error: my fstab reads as : # /etc/fstab: static file system information. # # #/dev/sda1 /boot ext2 defaults,errors=remount-ro 0 0 #/dev/sda2 none swap sw 0 0 /dev/sda3 / ext2 defaults,errors=remount-ro 0 0 # proc /proc proc defaults 0 0 The erros is as follows: Boot IO Dependent Code (IODC) revision 144 .... SUCCEEDED! HARD Booted. palo ipl bame@noam Tue Oct 31 14:18:02 MST 2000 0/vmlinux 208896 bytes @ 0x1f78c000 0/palo-cmdline '3/boot/vmlinux TERM=linux Home=/ root=/dev/sda3' /dev/ida1 82 62 1030688 /dev/ida2 f0 1030750 24738 /dev/ida3 83 1055488 1030750 Kernel:partition 3 file /boot/vmlinux ext2 block size 1024 ext2_mount(partition 3) returns 0 ext2_open(/boot/vmlinux)=3 Couldn't gork your kernel executabel format failed to load kernel Failed to load Kernel. Please suggest. From dave@hiauly1.hia.nrc.ca Fri, 3 Nov 2000 15:01:17 -0500 (EST) Date: Fri, 3 Nov 2000 15:01:17 -0500 (EST) From: John David Anglin dave@hiauly1.hia.nrc.ca Subject: testcase for hppa64 gcc bug > I think I know what's going on here. The root of the problem is that > pa-64.h defines an ARG_POINTER_REGNUM that isn't a fixed reg, and isn't > eliminable. The arg_pointer isn't even a call-saved reg. That breaks a > number of places in the compiler. > > So I went down the path of trying to fix things properly by defining > ELIMINABLE_REGS and so on, but I ended in a maze of twisty little passages > labelled "Unrecognizable instruction", like this one: > > /src/parisc/gcc/gcc/libgcc2.c: In function `__moddi3': > /src/parisc/gcc/gcc/libgcc2.c:601: Unrecognizable insn: > (insn 1289 209 1298 (set (reg:SI 50 %fr22) > (subreg:SI (plus:DI (reg:DI 30 %r30) > (const_int -272 [0xfffffef0])) 0)) -1 (nil) > (nil)) > /src/parisc/gcc/gcc/libgcc2.c:601: Internal compiler error in > extract_insn, at recog.c:2134 I am making progress in trying to make the arg_pointer register eliminable. I have fixed the above problem. What was happening was that reload_as_needed was incorrectly trying to eliminate the return from millicode calls which is also register r29. I have figured out how to hide it from reload with unspec. However, the compiler is now too good at eliminating the arg_pointer. At -O3, it completely eliminates the arg_pointer. However, as I read the ABI, the call must always set the arg_pointer before calls. Dave -- J. David Anglin dave.anglin@nrc.ca National Research Council of Canada (613) 990-0752 (FAX: 952-6605) From bame@noam.fc.hp.com Fri, 03 Nov 2000 13:30:16 -0700 Date: Fri, 03 Nov 2000 13:30:16 -0700 From: Paul Bame bame@noam.fc.hp.com Subject: [parisc-linux] Boot command = ext2_open(/boot/vmlinux)=3 = Couldn't gork your kernel executabel format failed to load kernel = Failed to load Kernel. That should be "grok" :-) Apparently you're not using cut/paste for these error messages. This is PALO saying that /boot/vmlinux is neither elf32, elf64, nor SOM format. I'm guessing, based on some earlier advice I gave when you were net-booting, that you may have a lifimage there by mistake -- you need a kernel instead, for example from ftp://puffin.external.hp.com/pub/parisc/binaries/kernels To tell for sure, run 'file vmlinux' on that file. If you get vmlinux: 8086 relocatable (Microsoft) that's probably a lifimage. You should get this instead: vmlinux: ELF 32-bit MSB executable, PA-RISC, version 1, statically linked, not stripped -P From kailasr@webcash.com Fri, 03 Nov 2000 14:59:29 -0800 Date: Fri, 03 Nov 2000 14:59:29 -0800 From: Kailashnath V Rampure kailasr@webcash.com Subject: [parisc-linux] Boot command Thanks! Paul. Yes I had copied the lifImage there. Now I have downloaded the kernel from the link you mentioned. I am still unable to use vi as it says "linux:unknown terminal type" Can you help me. To add features can I add deb packages. I am not that familiar with debian. Actually I want to build an apache + mod_ssl+mod_perl on A180c. Regards Kailas At 01:30 PM 11/3/00 -0700, Paul Bame wrote: >= ext2_open(/boot/vmlinux)=3 >= Couldn't gork your kernel executabel format failed to load kernel >= Failed to load Kernel. > >That should be "grok" :-) Apparently you're not using cut/paste for >these error messages. > >This is PALO saying that /boot/vmlinux is neither elf32, elf64, nor SOM >format. I'm guessing, based on some earlier advice I gave when you >were net-booting, that you may have a lifimage there by mistake -- you >need a kernel instead, for example from >ftp://puffin.external.hp.com/pub/parisc/binaries/kernels > >To tell for sure, run 'file vmlinux' on that file. If you get > vmlinux: 8086 relocatable (Microsoft) >that's probably a lifimage. You should get this instead: > vmlinux: ELF 32-bit MSB executable, PA-RISC, version 1, statically > linked, not stripped > > > -P From randolph@tausq.org Sat, 4 Nov 2000 18:02:03 -0700 Date: Sat, 4 Nov 2000 18:02:03 -0700 From: Randolph Chung randolph@tausq.org Subject: [parisc-linux] ldd segfaulting? I think this may be related to what bdale has been seeing... frodo:~# cat test.c int main(int a, char **b) { return 0; } frodo:~# gcc -o test test.c frodo:~# ./test frodo:~# ldd ./test do_page_fault() pid=144 command='ld.so.1' YZrvWESTHLNXBCVMcbcbcbcbOGFRQPDI PSW: 00000000000001001000000100001011 r0-3 00000000 2aac367c 2aaacd67 2aaaa2f0 r4-7 2aac367c 2aaab4e8 2aac3622 2aac02b8 r8-11 20020048 2aaaccb8 2aaaa2f0 00000000 r12-15 00000081 00000080 200201e8 2001fe10 r16-19 00000000 00000000 00000000 2aac367c r20-23 00000000 2aaaa000 2aaaa000 00000041 r24-27 2aaaa000 70000021 20020048 00076b50 r28-31 00000021 20020048 200202c0 2aaacd1b sr0-4 00000000 00002003 00000000 00002003 sr4-8 00002003 00002003 00002003 00002003 IASQ: 00002003 00002003 IAOQ: 2aaadc63 2aaadc67 IIR: 0ce61280 ISR: 00002003 IOR: 2aac02b8 ORIG_R28: 00086350 do_page_fault() pid=145 command='ld.so.1' YZrvWESTHLNXBCVMcbcbcbcbOGFRQPDI PSW: 00000000000001001000000100001011 r0-3 00000000 2aac367c 2aaacd67 2aaaa2f0 r4-7 2aac367c 2aaab4e8 2aac3622 2aac02b8 r8-11 20020048 2aaaccb8 2aaaa2f0 00000000 r12-15 00000081 00000080 200201e8 2001fe10 r16-19 00000000 00000000 00000000 2aac367c r20-23 00000000 2aaaa000 2aaaa000 00000041 r24-27 2aaaa000 70000021 20020048 00076b50 r28-31 00000021 20020048 200202c0 2aaacd1b sr0-4 00000000 00002003 00000000 00002003 sr4-8 00002003 00002003 00002003 00002003 IASQ: 00002003 00002003 IAOQ: 2aaadc63 2aaadc67 IIR: 0ce61280 ISR: 00002003 IOR: 2aac02b8 ORIG_R28: 00090190 ldd: /lib/ld.so.1 exited with unknown exit code (139) frodo:~# gcc --version 2.96 frodo:~# ldd --version ldd (GNU libc) 2.1.95 Copyright (C) 1999 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. Written by Roland McGrath and Ulrich Drepper. frodo:~# Any ideas what's going on? I've tried this both with a Oct26 kernel and one that is from cvs today. Same results. randolph -- @..@ http://www.TauSq.org/ (----) ( >__< ) ^^ ~~ ^^ From alan@linuxcare.com.au Sun, 5 Nov 2000 16:02:43 +1100 (EST) Date: Sun, 5 Nov 2000 16:02:43 +1100 (EST) From: Alan Modra alan@linuxcare.com.au Subject: [parisc-linux] ldd segfaulting? On Sat, 4 Nov 2000, Randolph Chung wrote: > frodo:~# ldd ./test > > do_page_fault() pid=144 command='ld.so.1' Most likely a case of new kernel, ld.so compiled with old gcc. Old is earlier than 25th Oct. Before that gcc put plabels, which need relocating, in .rodata, which is mapped read-only. The new kernel enforces the read-only mapping, so you run into problems when ld.so tries to relocate itself. Fortunately, you only need recompile glibc with a new gcc. Older binaries with plabels in .rodata are handled OK as ld.so re-maps the segments read/write, something it doesn't manage to do for itself. Alan Modra -- Linuxcare. Support for the Revolution. From bdale@gag.com Sat, 04 Nov 2000 23:16:29 -0700 Date: Sat, 04 Nov 2000 23:16:29 -0700 From: Bdale Garbee bdale@gag.com Subject: [parisc-linux] compiler bug? In the build of util-linux, compilation of fdisk/fdiskbsdlabel.c fails as shown below. I have placed "gcc -E" output on pehc in ~bdale/fdiskbsdlabel.E for reference. Hacking the makefiles to remove "-O -O2" allows the compile to complete cleanly. I assume this means something in the compiler is broken? Bdale bdale@j5k:/space/debian/util-linux-2.10o/fdisk $ cc -c -O -O2 -fomit-frame-pointer -I../lib -Wall -Wmissing-prototypes -Wstrict-prototypes -DNCH=1 -DSBINDIR=\"/sbin\" -DUSRSBINDIR=\"/usr/sbin\" -DLOGDIR=\"/var/log\" -DVARPATH=\"/var\" -DLOCALEDIR=\"/usr/share/locale\" fdiskbsdlabel.c -o fdiskbsdlabel.o /usr/include/linux/string.h:12: parse error before "__extension__" /usr/include/linux/string.h:12: parse error before '&&' token /usr/include/linux/string.h:14: parse error before "__extension__" /usr/include/linux/string.h:14: parse error before '(' token /usr/include/linux/string.h:15: parse error before "__extension__" /usr/include/linux/string.h:15: parse error before '&&' token /usr/include/linux/string.h:24: parse error before "__extension__" /usr/include/linux/string.h:27: parse error before "__extension__" /usr/include/linux/string.h:33: parse error before "__extension__" /usr/include/linux/string.h:36: parse error before "__extension__" /usr/include/linux/string.h:36: parse error before '&&' token /usr/include/linux/string.h:36: parse error before '}' token /usr/include/linux/string.h:36: conflicting declarations of `__result' /usr/include/linux/string.h:36: `__result' previously declared here /usr/include/linux/string.h:36: parse error before ')' token /usr/include/linux/string.h:36: `__s2' undeclared here (not in a function) /usr/include/linux/string.h:36: parse error before ';' token /usr/include/linux/string.h:36: conflicting declarations of `__result' /usr/include/linux/string.h:36: `__result' previously defined here /usr/include/linux/string.h:36: parse error before '}' token /usr/include/linux/string.h:36: parse error before '}' token /usr/include/linux/string.h:36: redefinition of `__result' /usr/include/linux/string.h:36: `__result' previously defined here /usr/include/linux/string.h:36: `__s1' undeclared here (not in a function) /usr/include/linux/string.h:36: parse error before ')' token /usr/include/linux/string.h:36: parse error before ';' token /usr/include/linux/string.h:36: conflicting declarations of `__result' /usr/include/linux/string.h:36: `__result' previously defined here /usr/include/linux/string.h:36: parse error before '}' token /usr/include/linux/string.h:39: parse error before "__extension__" /usr/include/linux/string.h:39: parse error before '&&' token /usr/include/linux/string.h:39: parse error before '}' token /usr/include/linux/string.h:39: redefinition of `__result' /usr/include/linux/string.h:36: `__result' previously defined here /usr/include/linux/string.h:39: parse error before ')' token /usr/include/linux/string.h:39: `__s2' undeclared here (not in a function) /usr/include/linux/string.h:39: parse error before ';' token /usr/include/linux/string.h:39: conflicting declarations of `__result' /usr/include/linux/string.h:39: `__result' previously defined here /usr/include/linux/string.h:39: parse error before '}' token /usr/include/linux/string.h:39: parse error before '}' token /usr/include/linux/string.h:39: redefinition of `__result' /usr/include/linux/string.h:39: `__result' previously defined here /usr/include/linux/string.h:39: `__s1' undeclared here (not in a function) /usr/include/linux/string.h:39: parse error before ')' token /usr/include/linux/string.h:39: parse error before ';' token /usr/include/linux/string.h:39: conflicting declarations of `__result' /usr/include/linux/string.h:39: `__result' previously defined here /usr/include/linux/string.h:39: parse error before '}' token /usr/include/linux/string.h:45: parse error before "__extension__" /usr/include/linux/string.h:51: parse error before "__extension__" /usr/include/linux/string.h:61: parse error before "__extension__" /usr/include/linux/string.h:61: parse error before '\x0' /usr/include/linux/string.h:61: parse error before '}' token fdiskbsdlabel.c: In function `xbsd_zaplabel': fdiskbsdlabel.c:840: warning: `sector' might be used uninitialized in this function bdale@j5k:/space/debian/util-linux-2.10o/fdisk $ From alan@linuxcare.com.au Sun, 5 Nov 2000 18:41:54 +1100 (EST) Date: Sun, 5 Nov 2000 18:41:54 +1100 (EST) From: Alan Modra alan@linuxcare.com.au Subject: [parisc-linux] compiler bug? On Sat, 4 Nov 2000, Bdale Garbee wrote: > Hacking the makefiles to remove "-O -O2" allows the compile to complete > cleanly. glibc includes are "smart", and do things like `#if defined __OPTIMIZE__' > I assume this means something in the compiler is broken? No, I think it's a problem with glibc, or perhaps just your include files. > bdale@j5k:/space/debian/util-linux-2.10o/fdisk $ cc -c -O -O2 -fomit-frame-pointer -I../lib -Wall -Wmissing-prototypes -Wstrict-prototypes -DNCH=1 -DSBINDIR=\"/sbin\" -DUSRSBINDIR=\"/usr/sbin\" -DLOGDIR=\"/var/log\" -DVARPATH=\"/var\" -DLOCALEDIR=\"/usr/share/locale\" fdiskbsdlabel.c -o fdiskbsdlabel.o > /usr/include/linux/string.h:12: parse error before "__extension__" Your .i file had this in it: extern char * ___strtok; extern char * __extension__ ({ char __a0, __a1, __a2; [rest snipped] which comes from linux/string.h extern char * ___strtok; extern char * strcpy(char *,const char *); The problem being that strcpy is being replaced with an inline expansion. Dunno why this is happenning. Alan Modra -- Linuxcare. Support for the Revolution. From xam@sgate.charlysworld.de Mon, 6 Nov 2000 01:14:41 +0100 (CET) Date: Mon, 6 Nov 2000 01:14:41 +0100 (CET) From: xam@deathsdoor.com xam@sgate.charlysworld.de Subject: [parisc-linux] HP9000/730 boot problems Hi all, i have an HP9000/730 (66.6MHz, 32MB RAM, 10MBit Network, CRX graphics, HIL keyboard & mouse, HP 535MBM SCSI HD). I got the latest nfsroot, the latest xc and the palo sources from puffin.external.hp.com. the parition scheme for the HD (id 6) is /dev/sdb1 swap 128MB /dev/sdb2 f0 10MB /dev/sdb3 ext2 rest i untarred nfsroot on /dev/sdb3 and changed /etc/fstab accordingly i installed palo with the following command /opt/palinux/palo-src/palo/palo -I -k /hydra/hppa/boot/vmlinux -b /opt/palinux/palo-src/iplboot -c '3/boot/vmlinux TERM=linux HOME=/ root=/dev/sdb3' /dev/sdb well, i used /dev/sdb since there is also the scsi fd (id 0) that is /dev/sda IMHO (i tested alos to use root=/dev/sda3 btw). some of the boot messages PDC ROM rev. 2.1 IODC ROM rev. 2.1 32 MB of memory configured and tested. Selecting a system to boot. Hard booted. [...] now it prints the palo configuration as i installed it and the hd partition scheme (but /dev/idaXYZ instead of /dev/sdbXYZ [...] ext2 block size 1024 ext2_open(/boot/vmlinux) = 3 ext2_mount(partition 3) returns 0 ELF32 executable [...] now all recognized devices (SGC craphics, BA, HIL, LAN, 2x RS232, SCSI, EISA, Core Centronics, HP model 'king Cobra' ...) the kernel boots actually, but i dumps the stack register and the processor registers (not included in this mail) after ASP version 1 at ..... found thats all. no message like 'unable to boot root fs' or something ... any help ? PS: i tried to use a IBM0664 2.0GB scsi hd before (works fine on linux/ia32), but i couldn't get it work on hp (i reported this in a former mail). PPS: just FYI: the same configuration worked with HP/UX 10.10 From grundler@cup.hp.com Sun, 05 Nov 2000 17:21:12 -0800 Date: Sun, 05 Nov 2000 17:21:12 -0800 From: Grant Grundler grundler@cup.hp.com Subject: [parisc-linux] HP9000/730 boot problems "xam@deathsdoor.com" wrote: > Hi all, > > i have an HP9000/730 (66.6MHz, 32MB RAM, 10MBit Network, CRX graphics, > HIL keyboard & mouse, HP 535MBM SCSI HD). > > I got the latest nfsroot, the latest xc and the palo sources from > puffin.external.hp.com. > > the parition scheme for the HD (id 6) is > > /dev/sdb1 swap 128MB > /dev/sdb2 f0 10MB > /dev/sdb3 ext2 rest > > i untarred nfsroot on /dev/sdb3 and changed /etc/fstab accordingly > i installed palo with the following command > > /opt/palinux/palo-src/palo/palo -I -k /hydra/hppa/boot/vmlinux -b > /opt/palinux/palo-src/iplboot -c '3/boot/vmlinux TERM=linux HOME=/ > root=/dev/sdb3' /dev/sdb > > > well, i used /dev/sdb since there is also the scsi fd (id 0) > that is /dev/sda IMHO (i tested alos to use root=/dev/sda3 btw). using /dev/sdb is ok - your palo command looks "right" to me. > [...] > now it prints the palo configuration as i installed it > and the hd partition scheme (but /dev/idaXYZ instead of /dev/sdbXYZ > [...] > ext2 block size 1024 > ext2_open(/boot/vmlinux) = 3 > ext2_mount(partition 3) returns 0 > ELF32 executable This looks like palo loading the vmlinux. > [...] > > now all recognized devices (SGC craphics, BA, HIL, LAN, 2x RS232, SCSI, > EISA, Core Centronics, HP model 'king Cobra' ...) > > the kernel boots actually, but i dumps the stack register and the > processor registers (not included in this mail) after > > ASP version 1 at ..... found Sounds like ASP support may be broken. The way to find out where IOAQ and GR2 registers are pointing. They should point to functions in System.map. Who is maintaining ASP support? > PS: i tried to use a IBM0664 2.0GB scsi hd before (works fine on > linux/ia32), but i couldn't get it work on hp (i reported this > in a former mail). Right. I'm pretty sure older PDC/IODC doesn't send START_UNIT command to the disk drive. The boot drive is expected to spin up on it's own. I don't know if newer PDC does send START_UNIT either... grant Grant Grundler Unix Systems Enablement Lab +1.408.447.7253 From grundler@cup.hp.com Sun, 5 Nov 2000 18:18:35 -0800 (PST) Date: Sun, 5 Nov 2000 18:18:35 -0800 (PST) From: Grant Grundler grundler@cup.hp.com Subject: [parisc-linux] string.h warnings When linux/arch/parisc/kernel/pci.c built, I get the following warnings: /linux/kwdb64/linux/include/linux/string.h:54: warning: conflicting types for built-in function `strlen' /linux/kwdb64/linux/include/linux/string.h:61: warning: conflicting types for built-in function `memset' /linux/kwdb64/linux/include/linux/string.h:64: warning: conflicting types for built-in function `memcpy' /linux/kwdb64/linux/include/linux/string.h:73: warning: conflicting types for built-in function `memcmp' Could this be related to or shed light on the problem bdale had? thanks, grant From bri@mojo.calyx.net Sun, 5 Nov 2000 21:34:54 -0500 (EST) Date: Sun, 5 Nov 2000 21:34:54 -0500 (EST) From: Brian S. Julin bri@mojo.calyx.net Subject: [parisc-linux] string.h warnings On Sun, 5 Nov 2000, Grant Grundler wrote: > When linux/arch/parisc/kernel/pci.c built, I get the following > warnings: > /linux/kwdb64/linux/include/linux/string.h:54: warning: conflicting types for built-in function `strlen' > /linux/kwdb64/linux/include/linux/string.h:61: warning: conflicting types for built-in function `memset' > /linux/kwdb64/linux/include/linux/string.h:64: warning: conflicting types for built-in function `memcpy' > /linux/kwdb64/linux/include/linux/string.h:73: warning: conflicting types for built-in function `memcmp' For some reason I had numerous problems with string.h not being included when building ncurses natively with the nfsroot tarball. (Also the nfsroot tarball seems to not be able to find the crt* objects by default) -- Brian S. Julin From jsm@udlkern.fc.hp.com Sun, 5 Nov 2000 23:12:56 -0700 (MST) Date: Sun, 5 Nov 2000 23:12:56 -0700 (MST) From: John Marvin jsm@udlkern.fc.hp.com Subject: [parisc-linux] HP 9000/730 boot problem "xam@deathsdoor.com" wrote: > > the kernel boots actually, but i dumps the stack register and the > processor registers (not included in this mail) after > > ASP version 1 at ..... found Grant Grundler wrote: > Sounds like ASP support may be broken. > The way to find out where IOAQ and GR2 registers are pointing. > They should point to functions in System.map. > Who is maintaining ASP support? No, the parallel port support for ASP is broken. If you disable the LASI/ASP builtin parallel-port support (CONFIG_PARPORT_GSC) you will get further. I can't guarantee you will succeed, but others have reported some success on boxes almost that old. This is at least the second time this question has come up, so I guess I'll add it to the FAQ and todo lists. John Marvin jsm@fc.hp.com From marteaut@esiee.fr Tue, 7 Nov 2000 17:00:48 +0100 Date: Tue, 7 Nov 2000 17:00:48 +0100 From: Thomas Marteau marteaut@esiee.fr Subject: [parisc-linux] A browser and a new URL for the ESIEE team web site Hi all, We have succeded to compile Lynx on a 712 and it works well. Also this short mail must tell you that our website can be reached with http://www.esiee.fr/puffin You can find a cool root FS which has the terminfo directory like that you won't have the "vt100:unknown term" message, the network support and lot of thing like that... Bye, ESIEE Team Don't hesitate to visit our website From kailasr@webcash.com Tue, 07 Nov 2000 09:46:53 -0800 Date: Tue, 07 Nov 2000 09:46:53 -0800 From: Kailashnath V Rampure kailasr@webcash.com Subject: [parisc-linux] Boot command Hi, Thanks. I copied the termcap and terminfo directory froma red hat linux box. Now I am able to run VI and the TERM is vt100. Regards Kailas At 02:56 PM 11/5/00 +0100, Thierry SIMONNET wrote: >To have a suitable TERM, you must get termcap or terminfo definition; ie a >good terminfo tree from a linux box. To have a good method to install a >pa/linux box, see my student's web site at http://www.esiee.fr/~djoudim > >Th. SIMONNET > > >Kailashnath V Rampure wrote: > > > Thanks! Paul. > > Yes I had copied the lifImage there. Now I have downloaded the kernel from > > the link you mentioned. > > > > I am still unable to use vi as it says "linux:unknown terminal type" > > Can you help me. > > > > To add features can I add deb packages. I am not that familiar with debian. > > Actually I want to build an apache + mod_ssl+mod_perl on A180c. > > Regards > > Kailas > > > > At 01:30 PM 11/3/00 -0700, Paul Bame wrote: > > >= ext2_open(/boot/vmlinux)=3 > > >= Couldn't gork your kernel executabel format failed to load kernel > > >= Failed to load Kernel. > > > > > >That should be "grok" :-) Apparently you're not using cut/paste for > > >these error messages. > > > > > >This is PALO saying that /boot/vmlinux is neither elf32, elf64, nor SOM > > >format. I'm guessing, based on some earlier advice I gave when you > > >were net-booting, that you may have a lifimage there by mistake -- you > > >need a kernel instead, for example from > > >ftp://puffin.external.hp.com/pub/parisc/binaries/kernels > > > > > >To tell for sure, run 'file vmlinux' on that file. If you get > > > vmlinux: 8086 relocatable (Microsoft) > > >that's probably a lifimage. You should get this instead: > > > vmlinux: ELF 32-bit MSB executable, PA-RISC, version 1, statically > > > linked, not stripped > > > > > > > > > -P > > > > --------------------------------------------------------------------------- > > To unsubscribe: send e-mail to parisc-linux-request@thepuffingroup.com with > > `unsubscribe' as the subject. From bame@noam.fc.hp.com Tue, 07 Nov 2000 11:15:50 -0700 Date: Tue, 07 Nov 2000 11:15:50 -0700 From: Paul Bame bame@noam.fc.hp.com Subject: [parisc-linux] 64-bit BUILD CHANGES The described changes have just been committed to CVS. If you have an existing configured/built 64-bit parisc tree right now I think these are the steps to update: Save your .config file do 'make distclean' do your cvs update restore your .config make oldconfig dep and then proceed as normal The symlinks come when you do a make {old}config and go with a 'make distclean' FYI >>> You may want to start hand-editing .hdepend (following each make dep) to remove the dependency of atomic.h on spinlock.h (just remove the first line containing the string spinlock.h) -- it can cause massive unnecessary rebuilds. It's due to a parisc-specific circular dependency :-( -P = I want to propose/discuss a new method for maintaining our 64-bit parisc = tree in relation to the 32-bit tree. I have prototyped this and so = far it seems pretty useful. = = Most of the files in the current parisc64 tree only contain one = line, a #include of the same file from the parisc tree. This confuses = 'make dep', causes some compile errors to have nonsense line numbers, = and doesn't allow direct editing of the source files in the parisc64 tree. = = The method I'm proposing works like this: = = The future parisc64 tree ONLY contains files which are different from, = or in addition to, those in the parisc tree. When you 'make config' = or 'make oldconfig', each file in the parsic tree is symbolically = linked as the same file in the parisc64 tree. This enables all = the rest of the tools/build to work normally. 'make distclean' includes = a step to remove all the symlinks. = = The ugliest "feature" is that even though you can edit source files = in the parisc64 tree, 'cvs commit' will fail on those which are = symbolic links. To reduce this problem, I'm dropping a symbolic link = called '...' in each parisc64 directory which is a pointer to the = corresponding parisc directory, so 'cd ...; cvs commit foo.c' will = work and not be too onerous. = = We should additionally consider a naming convention or something so = that maintainers in the parisc tree know whether files are shared with = parisc64 or not. = = I prototyped this as a fictional new "architecture" called "p64". To = try it out, grab the tarball (only about 30 files -- can be fewer) = ftp://puffin.external.hp.com/pub/parisc/ = and unpack in your top-level linux source tree directory. Then in = your top-level Makefile, change ARCH := parisc64 to ARCH := p64, then = make oldconfig or whatever you usually do. Let me know of any problems. = = Is this something we should adopt for the real parisc64 tree? = = -Paul Bame = = --------------------------------------------------------------------------- = To unsubscribe: send e-mail to parisc-linux-request@thepuffingroup.com with = `unsubscribe' as the subject. = = = From grundler@cup.hp.com Tue, 07 Nov 2000 11:19:02 -0800 Date: Tue, 07 Nov 2000 11:19:02 -0800 From: Grant Grundler grundler@cup.hp.com Subject: [parisc-linux] Boot command Kailashnath V Rampure wrote: > Hi, > Thanks. I copied the termcap and terminfo directory froma red hat linux > box. Now I am able to run VI and the TERM is vt100. I've added a "vi is complaining" item to the FAQ. Normally the FAQ lives at http://www.thepuffingroup.com/parisc/faq.html but it's not updated yet. I've put a temporary copy at http://puffin.external.hp.com/~grundler/faq.html and will remove this once the regular location is updated. (Hint - relative links won't work from my copy) grant Grant Grundler Unix Systems Enablement Lab +1.408.447.7253 From marteaut@esiee.fr Tue, 7 Nov 2000 20:53:55 +0100 Date: Tue, 7 Nov 2000 20:53:55 +0100 From: Thomas Marteau marteaut@esiee.fr Subject: [parisc-linux] Boot command ----- Original Message ----- From: Grant Grundler To: Kailashnath V Rampure Cc: Sent: Tuesday, November 07, 2000 8:19 PM Subject: Re: [parisc-linux] Boot command > Kailashnath V Rampure wrote: > > Hi, > > Thanks. I copied the termcap and terminfo directory froma red hat linux > > box. Now I am able to run VI and the TERM is vt100. > > I've added a "vi is complaining" item to the FAQ. To use vi and all these applications like top, they need the terminfo directory in /usr/share from any distrib!! Bye, the ESIEE Team From grundler@cup.hp.com Tue, 07 Nov 2000 12:24:39 -0800 Date: Tue, 07 Nov 2000 12:24:39 -0800 From: Grant Grundler grundler@cup.hp.com Subject: [parisc-linux] Boot command "Thomas Marteau" wrote: > Grant Grundler wrote: > > Kailashnat V Rampure wrote: > > > Hi, > > > Thanks. I copied the termcap and terminfo directory froma red hat linux > > > box. Now I am able to run VI and the TERM is vt100. > > > > I've added a "vi is complaining" item to the FAQ. > > To use vi and all these applications like top, they need the terminfo > directory in /usr/share from any distrib!! I didn't say taking from RH was wrong. IMHO, doing so defeats the whole point of debian's packaging system. Please read the new FAQ entry and tell me if I've gotten that right or not. grant Grant Grundler Unix Systems Enablement Lab +1.408.447.7253 From kailasr@webcash.com Tue, 07 Nov 2000 14:50:10 -0800 Date: Tue, 07 Nov 2000 14:50:10 -0800 From: Kailashnath V Rampure kailasr@webcash.com Subject: [parisc-linux] Boot command I agree with you regarding taking from RH. I just wanted to let u all know how I solved the issue. I have gone through the faq it is fine. Regards Kailas At 12:24 PM 11/7/00 -0800, Grant Grundler wrote: >"Thomas Marteau" wrote: > > Grant Grundler wrote: > > > Kailashnat V Rampure wrote: > > > > Hi, > > > > Thanks. I copied the termcap and terminfo directory froma red hat linux > > > > box. Now I am able to run VI and the TERM is vt100. > > > > > > I've added a "vi is complaining" item to the FAQ. > > > > To use vi and all these applications like top, they need the terminfo > > directory in /usr/share from any distrib!! > >I didn't say taking from RH was wrong. >IMHO, doing so defeats the whole point of debian's packaging system. > >Please read the new FAQ entry and tell me if I've gotten >that right or not. > >grant > >Grant Grundler >Unix Systems Enablement Lab >+1.408.447.7253 > >--------------------------------------------------------------------------- >To unsubscribe: send e-mail to parisc-linux-request@thepuffingroup.com with >`unsubscribe' as the subject. From cjknoch@yahoo.com Tue, 7 Nov 2000 15:40:14 -0800 (PST) Date: Tue, 7 Nov 2000 15:40:14 -0800 (PST) From: Christian Knoch cjknoch@yahoo.com Subject: [parisc-linux] HP 9000 e25 hi. i need information about how to install linux on hp 9000 e25 what version on linux what distribution ? how many memoty i need in this machine how many space on disk i need in this machine howto boot machine for install linux Thanks __________________________________________________ Do You Yahoo!? Thousands of Stores. Millions of Products. All in one Place. http://shopping.yahoo.com/ From matthew@wil.cx Wed, 8 Nov 2000 00:28:08 +0000 Date: Wed, 8 Nov 2000 00:28:08 +0000 From: Matthew Wilcox matthew@wil.cx Subject: [parisc-linux] HP 9000 e25 On Tue, Nov 07, 2000 at 03:40:14PM -0800, Christian Knoch wrote: > hi. > i need information about how to install linux on hp > 9000 e25 *sigh*. This is in the FAQ. Where do we need to put links to the FAQ to persuade people to read it? Where did you find this mailing list address, do we need to put a link to the FAQ there? The answer given in the FAQ is: The earliest PA-RISC servers have proprietary HP devices attached to proprietary HP bus architectures. It is unlikely that documentation on these busses and devices will ever become available, since so few people are interested in spending any effort finding and releasing the docs. Machines in this category are the E, F, G, H, I class (aka Nova) and T500 series (Emerald) machines as well as some earlier, unlettered servers. -- Revolutions do not require corporate support. From matthew@wil.cx Wed, 8 Nov 2000 20:14:43 +0000 Date: Wed, 8 Nov 2000 20:14:43 +0000 From: Matthew Wilcox matthew@wil.cx Subject: [parisc-linux] webshite since the lord god alex hasn't seen fit to inform anyone, it seems like i should. the www.thepuffingroup.com website is no longer being updated and all the updates are only going to parisc-linux.org. i have been updating www.thepuffingroup.com becuase no-one told me that this site was no longer supposed to be operational and i suspect a large number of people who subscribe to this list still have it bookmarked. also, email sent to willy@thepuffingroup.com is no longer being received by me. i don't know who gets it, but the sender does not receive a bounce. yours, fucking furious, Matthew. -- "It's time for you to change your sig" -- Alex deVries From grundler@cup.hp.com Wed, 08 Nov 2000 12:31:11 -0800 Date: Wed, 08 Nov 2000 12:31:11 -0800 From: Grant Grundler grundler@cup.hp.com Subject: [parisc-linux] webshite Matthew Wilcox wrote: > > since the lord god alex hasn't seen fit to inform anyone, it seems like > i should. the www.thepuffingroup.com website is no longer being updated > and all the updates are only going to parisc-linux.org. We gave LXC's website maintainer grief about this already. > i have been > updating www.thepuffingroup.comwww.thepuffingroup.com becuase no-one told me that this site > was no longer supposed to be operational and i suspect a large number > of people who subscribe to this list still have it bookmarked. Some time today, I expect (hope?) www.thepuffingroup.com/parisc will be redirected to www.parisc-linux.org (.com works too). I've asked mail be sent to this list when it happens. > also, > email sent to willy@thepuffingroup.com is no longer being received by me. > i don't know who gets it, but the sender does not receive a bounce. This should probably bounce since it's been stale for about 11 monthes now... hope this helps, grant ps. just trying to compensate for an otherwise lack of communication. > > yours, fucking furious, Matthew. > > -- > "It's time for you to change your sig" -- Alex deVries > > --------------------------------------------------------------------------- > To unsubscribe: send e-mail to parisc-linux-request@thepuffingroup.com with > `unsubscribe' as the subject. > Grant Grundler Unix Systems Enablement Lab +1.408.447.7253 From andrew@neep.com.au Thu, 9 Nov 2000 05:13:23 +0800 Date: Thu, 9 Nov 2000 05:13:23 +0800 From: Andrew Shugg andrew@neep.com.au Subject: [parisc-linux] webshite Matthew Wilcox said: > the www.thepuffingroup.com website is no longer being updated and all > the updates are only going to parisc-linux.org. I don't know if there's some other secret mailing list I'm missing out on, but that's the first time I've heard of "parisc-linux.org" I'm sure. So thankyou for being the one to bring it up. Will the mailing list be moving as well? (Given that it belongs with the project, not the mothballed puffingroup website.) > -- > "It's time for you to change your sig" -- Alex deVries Shame, I thought your old sig was funnier. Andrew. -- Andrew Shugg http://www.neep.com.au/ "Just remember, Mr Fawlty, there's always someone worse off than yourself." "Is there? Well I'd like to meet him. I could do with a good laugh." From taggart@carmen.fc.hp.com Wed, 08 Nov 2000 14:22:03 -0700 Date: Wed, 08 Nov 2000 14:22:03 -0700 From: Matt Taggart taggart@carmen.fc.hp.com Subject: [parisc-linux] webshite Andrew Shugg writes... > I don't know if there's some other secret mailing list I'm missing out > on, but that's the first time I've heard of "parisc-linux.org" I'm sure. > So thankyou for being the one to bring it up. It was never officially announced, just setup. I guess this is the announcement. > Will the mailing list be moving as well? (Given that it belongs with > the project, not the mothballed puffingroup website.) Yes, most of the project's web/mail resources will be moving there shortly. Go ahead and update your bookmarks. I've been told there will be a pointer/redirect from the old site but I wouldn't count on it existing forever. -- Matt Taggart taggart@fc.hp.com From andrew@neep.com.au Thu, 9 Nov 2000 05:48:06 +0800 Date: Thu, 9 Nov 2000 05:48:06 +0800 From: Andrew Shugg andrew@neep.com.au Subject: [parisc-linux] HP 9000 e25 Matthew Wilcox said: > On Tue, Nov 07, 2000 at 03:40:14PM -0800, Christian Knoch wrote: > > hi. > > i need information about how to install linux on hp > > 9000 e25 > > *sigh*. This is in the FAQ. Where do we need to put links to the FAQ > to persuade people to read it? Where did you find this mailing list > address, do we need to put a link to the FAQ there? I think the fault lies in the "Contact" page, new (!) URL being: http://parisc-linux.org/contact.html "Most questions about the port should be addressed to the developer mailing list parisc-linux@thepuffingroup.com" I would suggest this page be changed a bit, like stick the mailing list down the bottom and change it to a link to the mailing list subscribe and browse-the-archives page, rather than simply the address of the list. Also a comment about reading the FAQ. Yes, the FAQ is in the left-hand side-bar but you can never over-do the help. =) One of my favourite comments along that line was on the windowmaker.org home page (sadly it has been removed). It was something like "Please bear in mind that asking questions on the mailing list that are answered in the FAQ is NOT A GOOD IDEA." The FAQ on parisc-linux.org is also missing the all-important Q/A pair: Q. I have a question that isn't answered in this FAQ? A. Please subscribe to the [mailing list] and ask. Politely. Preferably in English, or (failing that) in a recognisable pidgin. Don't hold back on the relevant information either. "It won't boot" is not good. Andrew. -- Andrew Shugg http://www.neep.com.au/ "Just remember, Mr Fawlty, there's always someone worse off than yourself." "Is there? Well I'd like to meet him. I could do with a good laugh." From jvinet@linuxcare.com Wed, 08 Nov 2000 17:41:50 -0500 Date: Wed, 08 Nov 2000 17:41:50 -0500 From: Jane Vinet jvinet@linuxcare.com Subject: [parisc-linux] HP 9000 e25 Good advice...will notify the web design folks. Jane -- jvinet@linuxcare.com Andrew Shugg wrote: > I would suggest this page be changed a bit, like stick the mailing list > down the bottom and change it to a link to the mailing list subscribe > and browse-the-archives page, rather than simply the address of the > list. Also a comment about reading the FAQ. Yes, the FAQ is in the > left-hand side-bar but you can never over-do the help. =) > > One of my favourite comments along that line was on the windowmaker.org > home page (sadly it has been removed). It was something like "Please > bear in mind that asking questions on the mailing list that are answered > in the FAQ is NOT A GOOD IDEA." > > The FAQ on parisc-linux.org is also missing the all-important Q/A pair: > > Q. I have a question that isn't answered in this FAQ? > A. Please subscribe to the [mailing list] and ask. Politely. Preferably > in English, or (failing that) in a recognisable pidgin. Don't hold back > on the relevant information either. "It won't boot" is not good. > > Andrew. > > -- > Andrew Shugg http://www.neep.com.au/ > > "Just remember, Mr Fawlty, there's always someone worse off than yourself." > "Is there? Well I'd like to meet him. I could do with a good laugh." > > --------------------------------------------------------------------------- > To unsubscribe: send e-mail to parisc-linux-request@thepuffingroup.com with > `unsubscribe' as the subject. From matthew@wil.cx Thu, 9 Nov 2000 09:59:58 +0000 Date: Thu, 9 Nov 2000 09:59:58 +0000 From: Matthew Wilcox matthew@wil.cx Subject: [parisc-linux] webshite On Thu, Nov 09, 2000 at 05:13:23AM +0800, Andrew Shugg wrote: > Matthew Wilcox said: > > the www.thepuffingroup.com website is no longer being updated and all > > the updates are only going to parisc-linux.org. > > I don't know if there's some other secret mailing list I'm missing out > on, but that's the first time I've heard of "parisc-linux.org" I'm sure. > So thankyou for being the one to bring it up. oh, alex secretly went off and registered it. the first we heard about it was in a press release a couple of months ago. for a while it's been a (broken) redirect to www.thepuffingroup.com/parisc. there's a linuxcare internal mailing list for discussions of the parisc project, but it wasn't mentioned on there either. > Will the mailing list be moving as well? (Given that it belongs with > the project, not the mothballed puffingroup website.) no idea. alex is playing politics and he's not very good at it. personally, i think everything should be moved to puffin.external.hp.com and parisc-linux.org should just redirect to it, but that wouldn't fit with the aforementioned political games. > > -- > > "It's time for you to change your sig" -- Alex deVries > > Shame, I thought your old sig was funnier. oh, i just thought that was a more appropriate sig for the circumstances, I haven't changed permanently. -- Revolutions do not require corporate support. From matthew@wil.cx Thu, 9 Nov 2000 10:06:27 +0000 Date: Thu, 9 Nov 2000 10:06:27 +0000 From: Matthew Wilcox matthew@wil.cx Subject: [parisc-linux] webshite On Wed, Nov 08, 2000 at 12:31:11PM -0800, Grant Grundler wrote: > Matthew Wilcox wrote: > > also, > > email sent to willy@thepuffingroup.com is no longer being received by me. > > i don't know who gets it, but the sender does not receive a bounce. > > This should probably bounce since it's been stale for about > 11 monthes now... um, it was my email address until about 3 months ago. at least one person still had that as their preferred email address for me. if anyone else does, they should probably change it. it's the lack of bounce which concerns me, which implies that someone's receiving it, reading mail destined for me and not forwarding it on. -- Revolutions do not require corporate support. From dave@hiauly1.hia.nrc.ca Thu, 9 Nov 2000 12:39:57 -0500 (EST) Date: Thu, 9 Nov 2000 12:39:57 -0500 (EST) From: John David Anglin dave@hiauly1.hia.nrc.ca Subject: testcase for hppa64 gcc bug > > So I went down the path of trying to fix things properly by defining > > ELIMINABLE_REGS and so on, but I ended in a maze of twisty little passages > > labelled "Unrecognizable instruction", like this one: > > > > /src/parisc/gcc/gcc/libgcc2.c: In function `__moddi3': > > /src/parisc/gcc/gcc/libgcc2.c:601: Unrecognizable insn: > > (insn 1289 209 1298 (set (reg:SI 50 %fr22) > > (subreg:SI (plus:DI (reg:DI 30 %r30) > > (const_int -272 [0xfffffef0])) 0)) -1 (nil) > > (nil)) > > /src/parisc/gcc/gcc/libgcc2.c:601: Internal compiler error in > > extract_insn, at recog.c:2134 > > I am making progress in trying to make the arg_pointer register eliminable. > I have fixed the above problem. What was happening was that reload_as_needed > was incorrectly trying to eliminate the return from millicode calls which > is also register r29. I have figured out how to hide it from reload with > unspec. > > However, the compiler is now too good at eliminating the arg_pointer. At > -O3, it completely eliminates the arg_pointer. However, as I read the ABI, > the call must always set the arg_pointer before calls. For the record, here is my final patch regarding making the arg_pointer eliminable for TARGET_64BIT. I think the code it generates is correct but it hasn't been extensively tested. However, I don't recommend it for installation since in comparing the assembler code generated with and without elimination for a couple of test cases, I didn't observe any significant improvement in the code with the patch. Possibly, the patch implicitly disables elimination when the arg_pointer is needed. I do find that Alan Modra's ARG_POINTER_INVARIANT patch needs to be installed to get correct code with his test case. There is one part of the patch below which I think needs to be installed. That is (call, call_value): Always USE the arg_pointer for TARGET_64BIT. The use for the arg_pointer needs to be pulled out of the `if (flag_pic)'. Dave -- J. David Anglin dave.anglin@nrc.ca National Research Council of Canada (613) 990-0752 (FAX: 952-6605) 2000-11-07 John David Anglin * pa-linux64.h (ARG_POINTER_INVARIANT): Define even when the arg_pointer is being eliminated. (ELIMINABLE_REGS): Enable elimination of the arg_pointer. (INITIAL_ELIMINATION_OFFSET): Revise offsets for arg_pointer. * pa.md (mulsi3, divsi3, udivsi3, modsi3, umodsi3 and canonicalize_funcptr_for_compare): Put "(reg:SI 26)" inside unspec to prevent elimination. (call, call_value): Always USE the arg_pointer for TARGET_64BIT. Use the new addmovdi3 insn to load the arg_pointer register. (addmovdi3 and mov_from_r29_si): New insn and expand which prevent r29 from being eliminated in call setups and millicode returns. --- pa-linux64.h.orig Tue Oct 31 18:38:24 2000 +++ pa-linux64.h Tue Nov 7 12:17:12 2000 @@ -209,21 +209,18 @@ that grow to lower addresses. What fun. */ #undef ARGS_GROW_DOWNWARD #undef ARG_POINTER_REGNUM -#define ARG_POINTER_INVARIANT 0 #define ARG_POINTER_REGNUM 29 +#define ARG_POINTER_INVARIANT 0 #undef STATIC_CHAIN_REGNUM #define STATIC_CHAIN_REGNUM 31 -#if 1 -#define ARG_POINTER_INVARIANT 0 -#else -/* If defined, this macro specifies a table of register pairs used to eliminate - unneeded registers that point into the stack frame. */ +/* If defined, this macro specifies a table of register pairs used to + eliminate unneeded registers that point into the stack frame. */ #define ELIMINABLE_REGS \ { \ - {ARG_POINTER_REGNUM, STACK_POINTER_REGNUM}, \ {FRAME_POINTER_REGNUM, STACK_POINTER_REGNUM}, \ + {ARG_POINTER_REGNUM, STACK_POINTER_REGNUM}, \ {ARG_POINTER_REGNUM, FRAME_POINTER_REGNUM}, \ } @@ -240,19 +237,18 @@ #define INITIAL_ELIMINATION_OFFSET(FROM, TO, OFFSET) \ do \ { \ - int fsize; \ + int fsize = compute_frame_size (get_frame_size (), 0); \ \ if ((TO) == FRAME_POINTER_REGNUM \ && (FROM) == ARG_POINTER_REGNUM) \ { \ - (OFFSET) = - current_function_pretend_args_size - 16; \ + (OFFSET) = fsize + 48 - current_function_outgoing_args_size; \ break; \ } \ \ if ((TO) != STACK_POINTER_REGNUM) \ abort (); \ \ - fsize = compute_frame_size (get_frame_size (), 0); \ switch (FROM) \ { \ case FRAME_POINTER_REGNUM: \ @@ -260,14 +256,13 @@ break; \ \ case ARG_POINTER_REGNUM: \ - (OFFSET) = - fsize - current_function_pretend_args_size - 16; \ + (OFFSET) = 48 - current_function_outgoing_args_size; \ break; \ \ default: \ abort (); \ } \ } while (0) -#endif #undef SELECT_RTX_SECTION #define SELECT_RTX_SECTION(MODE,RTX) \ --- pa.md.orig Tue Nov 7 13:50:34 2000 +++ pa.md.work Wed Nov 8 14:06:05 2000 @@ -3993,7 +3993,7 @@ (clobber (reg:SI 26)) (clobber (reg:SI 25)) (clobber (reg:SI 31))]) - (set (match_operand:SI 0 "general_operand" "") (reg:SI 29))] + (set (match_operand:SI 0 "general_operand" "") (unspec:SI [(reg:SI 29)] 0))] "" " { @@ -4139,7 +4139,7 @@ (clobber (reg:SI 26)) (clobber (reg:SI 25)) (clobber (reg:SI 31))]) - (set (match_operand:SI 0 "general_operand" "") (reg:SI 29))] + (set (match_operand:SI 0 "general_operand" "") (unspec:SI [(reg:SI 29)] 0))] "" " { @@ -4197,7 +4197,7 @@ (clobber (reg:SI 26)) (clobber (reg:SI 25)) (clobber (reg:SI 31))]) - (set (match_operand:SI 0 "general_operand" "") (reg:SI 29))] + (set (match_operand:SI 0 "general_operand" "") (unspec:SI [(reg:SI 29)] 0))] "" " { @@ -4255,7 +4255,7 @@ (clobber (reg:SI 26)) (clobber (reg:SI 25)) (clobber (reg:SI 31))]) - (set (match_operand:SI 0 "general_operand" "") (reg:SI 29))] + (set (match_operand:SI 0 "general_operand" "") (unspec:SI [(reg:SI 29)] 0))] "" " { @@ -4310,7 +4310,7 @@ (clobber (reg:SI 26)) (clobber (reg:SI 25)) (clobber (reg:SI 31))]) - (set (match_operand:SI 0 "general_operand" "") (reg:SI 29))] + (set (match_operand:SI 0 "general_operand" "") (unspec:SI [(reg:SI 29)] 0))] "" " { @@ -5785,9 +5785,9 @@ op = XEXP (operands[0], 0); if (TARGET_64BIT) - emit_move_insn (arg_pointer_rtx, - gen_rtx_PLUS (word_mode, virtual_outgoing_args_rtx, - GEN_INT (64))); + emit_insn (gen_addmovdi3 (arg_pointer_rtx, + virtual_outgoing_args_rtx, + GEN_INT (64))); /* Use two different patterns for calls to explicitly named functions and calls through function pointers. This is necessary as these two @@ -5809,13 +5809,14 @@ call_insn = emit_call_insn (gen_call_internal_reg (operands[1])); } + if (TARGET_64BIT) + use_reg (&CALL_INSN_FUNCTION_USAGE (call_insn), arg_pointer_rtx); + if (flag_pic) { use_reg (&CALL_INSN_FUNCTION_USAGE (call_insn), pic_offset_table_rtx); use_reg (&CALL_INSN_FUNCTION_USAGE (call_insn), gen_rtx_REG (word_mode, PIC_OFFSET_TABLE_REGNUM_SAVED)); - if (TARGET_64BIT) - use_reg (&CALL_INSN_FUNCTION_USAGE (call_insn), arg_pointer_rtx); /* After each call we must restore the PIC register, even if it doesn't appear to be used. @@ -5961,9 +5962,9 @@ op = XEXP (operands[1], 0); if (TARGET_64BIT) - emit_move_insn (arg_pointer_rtx, - gen_rtx_PLUS (word_mode, virtual_outgoing_args_rtx, - GEN_INT (64))); + emit_insn (gen_addmovdi3 (arg_pointer_rtx, + virtual_outgoing_args_rtx, + GEN_INT (64))); /* Use two different patterns for calls to explicitly named functions and calls through function pointers. This is necessary as these two @@ -5989,6 +5990,10 @@ call_insn = emit_call_insn (gen_call_value_internal_reg (operands[0], operands[2])); } + + if (TARGET_64BIT) + use_reg (&CALL_INSN_FUNCTION_USAGE (call_insn), arg_pointer_rtx); + if (flag_pic) { use_reg (&CALL_INSN_FUNCTION_USAGE (call_insn), pic_offset_table_rtx); @@ -7124,7 +7129,7 @@ (clobber (reg:SI 22)) (clobber (reg:SI 31))]) (set (match_operand:SI 0 "register_operand" "") - (reg:SI 29))] + (unspec:SI [(reg:SI 29)] 0))] "! TARGET_PORTABLE_RUNTIME && !TARGET_64BIT && !TARGET_ELF32" " { @@ -7236,3 +7241,48 @@ emit_insn (gen_blockage ()); DONE; }") + +;; For TARGET_64BIT, the arg_pointer register is also used for millicode +;; returns. The ABI requires that the arg_pointer be set for all calls. +;; When the arg_pointer is made an eliminable register, eliminate_regs +;; will eliminate the arg_pointer register from the function call setup and +;; millicode returns unless the arg_pointer is hidden in a use, clobber or +;; unspec. + +;; This is for loading the arg_pointer in function calls. +(define_insn "addmovdi3" + [(set (unspec:DI [(match_operand:DI 0 "register_operand" "=r,r")] 0) + (plus:DI (match_operand:DI 1 "register_operand" "r,r") + (match_operand 2 "const_int_operand" "J,i"))) + (set (match_dup 0) (match_dup 0))] + "TARGET_64BIT" + "@ + ldo %2(%1),%0 + ldil L'%G2,%0\;add,l %0,%1,%0" + [(set_attr "type" "binary,binary") + (set_attr "pa_combine_type" "addmove,none") + (set_attr "length" "4,8")]) + +;; This is for millicode return. +(define_expand "mov_from_r29_si" + [(set (match_operand:SI 0 "" "") + (unspec:SI [(reg:SI 29)] 0))] + "" + " +{ + if (!TARGET_64BIT) + { + rtx tmp = gen_rtx_REG (SImode, 29); + emit_insn (gen_movsi (operands[0], tmp)); + DONE; + } +}") + +(define_insn "" + [(set (match_operand:SI 0 "register_operand" "=r") + (unspec:SI [(reg:SI 29)] 0))] + "" + "copy %%r29,%0" + [(set_attr "type" "multi") + (set_attr "length" "4")]) + From bame@noam.fc.hp.com Thu, 09 Nov 2000 11:47:51 -0700 Date: Thu, 09 Nov 2000 11:47:51 -0700 From: Paul Bame bame@noam.fc.hp.com Subject: [parisc-linux] kernel merge We're getting ready to do a kernel merge (to -test10 I think). Anybody concerns before we get started? -P From jvinet@linuxcare.com Thu, 09 Nov 2000 14:08:20 -0500 Date: Thu, 09 Nov 2000 14:08:20 -0500 From: Jane Vinet jvinet@linuxcare.com Subject: [parisc-linux] Website Plan Recently there have been concerns about what is happening with the web site. I'd like to let everyone know what the plan is in order to address these concerns. The Development team at HP provided us with a list of where current pages are hosted and where they should be hosted in the future. Item current future ---- ------- ------ mailing lists pehc LXC parisc website puffin LXC hardware database puffin pehc ftp server pehc pehc cvs pehc pehc As per Linuxcare's agreement with Hewlett Packard, Linuxcare (formerly the Puffing Group) is responsible for all of the pages that are currently hosted at http://www.thepuffingroup.com/parisc/. Linuxcare is in the process of redesigning the existing web pages and we will be moving very soon to http://www.parisc-linux.org/. By revamping the existing web pages, we want to make things like the FAQ page and the To-Do list much more visible to the public to encourage new contributors to join us, as well as meeting the needs of current Developers. The plan is to transition from the current website to the new website with as little disruption to the public as possible. Currently, http://www.parisc-linux.org/ is set up but not active. http://www.thepuffingroup.com/parisc/ will remain the active site until everything is ready to switch over. Each of the above items is being addressed independently and have separate schedules for transition. We will make sure that notification is made on http://www.thepuffingroup.com/parisc/ and on the mailing list prior to the transition. Thanks for your patience and we apologize for any inconvenience this may have caused. Jane -- Jane Vinet, Director Professional Services/Canadian Operations Linuxcare, Inc. 613.562.9260 (tel), 613.562.9700 fax jvinet@linuxcare.com, http://www.linuxcare.com/ Linuxcare, Support for the Revolution From dave@hiauly1.hia.nrc.ca Thu, 9 Nov 2000 14:54:00 -0500 (EST) Date: Thu, 9 Nov 2000 14:54:00 -0500 (EST) From: John David Anglin dave@hiauly1.hia.nrc.ca Subject: [parisc-linux] abort in eliminate_regs compiling glob.c from glibc The following abort occurs with a relatively current version of gcc from the cvs under hpux and the parisc-linux version of the compiler: hppa-linux-gcc ../sysdeps/generic/glob.c -c -O3 -Wall -Winline -Wstrict-prototypes -Wwrite-strings -I../include -I. -I/home/dave/puffin/glibc/objdir/posix -I.. -I../libio -I/home/dave/puffin/glibc/objdir -I../sysdeps/hppa/elf -I../linuxthreads/sysdeps/unix/sysv/linux/hppa -I../linuxthreads/sysdeps/unix/sysv/linux -I../linuxthreads/sysdeps/pthread -I../linuxthreads/sysdeps/unix/sysv -I../linuxthreads/sysdeps/unix -I../linuxthreads/sysdeps/hppa -I../sysdeps/unix/sysv/linux/hppa -I../sysdeps/unix/sysv/linux -I../sysdeps/gnu -I../sysdeps/unix/common -I../sysdeps/unix/mman -I../sysdeps/unix/inet -I../sysdeps/unix/sysv -I../sysdeps/unix -I../sysdeps/posix -I../sysdeps/hppa/hppa1.1 -I../sysdeps/wordsize-32 -I../sysdeps/ieee754/flt-32 -I../sysdeps/ieee754/dbl-64 -I../sysdeps/ieee754/ldbl-128 -I../sysdeps/hppa/fpu -I../sysdeps/hppa -I../sysdeps/ieee754 -I../sysdeps/generic/elf -I../sysdeps/generic -nostdinc -isystem /usr/local/puffin/lib/gcc-lib/hppa-linux/2.96/include -isystem ! /home/dave/puffin/linux/include -D_LIBC_REENTRANT -include ../include/libc-symbols.h -o /home/dave/puffin/glibc/objdir/posix/glob.o ../sysdeps/generic/glob.c: In function `glob_in_dir': ../sysdeps/generic/glob.c:1446: Internal compiler error in , at reload1.c:2516 Please submit a full bug report. See for instructions. make[2]: *** [/home/dave/puffin/glibc/objdir/posix/glob.o] Error 1 make[2]: Leaving directory `/home/dave/puffin/glibc/posix' make[1]: *** [posix/subdir_lib] Error 2 make[1]: Leaving directory `/home/dave/puffin/glibc' make: *** [all] Error 2 The insn that causes the fault is the following: Breakpoint 2, eliminate_regs_in_insn (insn=0x406a0ba0, replace=0) at ../../gcc/reload1.c:2826 2826 if (! insn_is_asm && icode < 0) (gdb) p debug_rtx (insn) (insn/s 2711 2709 2719 (set (reg:SI 6 %r6) (reg:SI 28 %r28)) 69 {pre_ldw-4} (insn_list 2708 (insn_list:REG_DEP_ANTI 2696 (insn_list:REG_DEP_ANTI 2702 (insn_list:REG_DEP_ANTI 2697 (nil))))) (expr_list:REG_DEAD (reg:SI 28 %r28) (insn_list:REG_RETVAL 2708 (expr_list:REG_EQUAL (expr_list (use (mem:BLK (scratch) 0)) (expr_list (symbol_ref/v:SI ("@strlen")) (expr_list (reg/v:SI 4 %r4) (nil)))) (nil))))) As can be seen, there is a use in the REG notes which will cause eliminate_regs to abort if it is called to process the notes of this insn. It is called from this code which is near the end of eliminate_regs_in_insn: for (ep = reg_eliminate; ep < ®_eliminate[NUM_ELIMINABLE_REGS]; ep++) { if (ep->previous_offset != ep->offset && ep->ref_outside_mem) ep->can_eliminate = 0; ep->ref_outside_mem = 0; if (ep->previous_offset != ep->offset) val = 1; } done: /* If we changed something, perform elimination in REG_NOTES. This is needed even when REPLACE is zero because a REG_DEAD note might refer to a register that we eliminate and could cause a different number of spill registers to be needed in the final reload pass than in the pre-passes. */ if (val && REG_NOTES (insn) != 0) REG_NOTES (insn) = eliminate_regs (REG_NOTES (insn), 0, REG_NOTES (insn)); ep->previous_offset is not equal ep->offset here and thus val is 1. The use would appear to arise from the rtl generated by expand_builtin_strlen. Anybody got any thoughts on how to fix this. Dave -- J. David Anglin dave.anglin@nrc.ca National Research Council of Canada (613) 990-0752 (FAX: 952-6605) From grundler@cup.hp.com Thu, 9 Nov 2000 12:12:25 -0800 (PST) Date: Thu, 9 Nov 2000 12:12:25 -0800 (PST) From: Grant Grundler grundler@cup.hp.com Subject: [parisc-linux] tulip DMA mapping Hi all, I see a "bug" in tulip's usage of mapping services. It's not the bug I was looking for unfortunately. In line 217 of drivers/net/tulip/interrupt.c: if (tp->tx_buffers[entry].mapping) pci_unmap_single(tp->pdev, tp->tx_buffers[entry].mapping, sizeof(tp->setup_frame), PCI_DMA_TODEVICE); 0 is a valid pci_map_single() return value when the system has an IO MMU. The system will panic before pci_map_single() will fail. The driver needs to remember some other way if a buffer was mapped or not. Or the Documentation/DMA-mapping.txt should be changed - ie add this to the interface definition and I can reserve the 1st mapping entry so no-one uses it. Should I be mailing Jeff Garzik directly? Or can someone who knows Jeff point this out to him? thanks, grant From rhirst@linuxcare.com Thu, 9 Nov 2000 23:00:50 +0000 Date: Thu, 9 Nov 2000 23:00:50 +0000 From: Richard Hirst rhirst@linuxcare.com Subject: [parisc-linux] strace working I have updated the strace source in our cvs, such that it now builds a basically working binary. It requires an up-to-date kernel. Outstanding issues: a) ioctl defines in linux/hppa/ioctlent.h are probably wrong b) there is a hack in defs.h to get round a problem where the libc wrapper for ptrace() isn't getting used c) there is a struct user defined in defs.h that should probably be in the kernel source asm/user.h d) there are probably more places where we need to add HPPA specific code Richard From dave@hiauly1.hia.nrc.ca Thu, 9 Nov 2000 18:57:13 -0500 (EST) Date: Thu, 9 Nov 2000 18:57:13 -0500 (EST) From: John David Anglin dave@hiauly1.hia.nrc.ca Subject: abort in eliminate_regs compiling glob.c from glibc > Breakpoint 2, eliminate_regs_in_insn (insn=0x406a0ba0, replace=0) > at ../../gcc/reload1.c:2826 > 2826 if (! insn_is_asm && icode < 0) > (gdb) p debug_rtx (insn) > (insn/s 2711 2709 2719 (set (reg:SI 6 %r6) > (reg:SI 28 %r28)) 69 {pre_ldw-4} (insn_list 2708 (insn_list:REG_DEP_ANTI 2696 (insn_list:REG_DEP_ANTI 2702 (insn_list:REG_DEP_ANTI 2697 (nil))))) > (expr_list:REG_DEAD (reg:SI 28 %r28) > (insn_list:REG_RETVAL 2708 (expr_list:REG_EQUAL (expr_list (use (mem:BLK (scratch) 0)) > (expr_list (symbol_ref/v:SI ("@strlen")) > (expr_list (reg/v:SI 4 %r4) > (nil)))) > (nil))))) The `use' arises from the `__pure__' attribute in the prototype for strlen: extern size_t strlen (__const char *__s) __attribute__ ((__pure__)); Still haven't been able to figure out why the REG notes are processed or a simple test case. The cpp'd input is attached. Dave -- J. David Anglin dave.anglin@nrc.ca National Research Council of Canada (613) 990-0752 (FAX: 952-6605) begin 644 glob.i.gz M'XL("('T"CH``V=L;V(N:0#M??MWV[:2\._Z*]CFG%[+<1I+\BO5MO>XB9/X MJV-G;:>]W6P.#RU1-F\D4B4I.]DV^[=_>#\'("DQS6/%O9M:P&`P&`"#P6`P MN!?T@F^___YA\;X8Q_/BX76G@]S:Z^'WW;N#^[RJ;%]S??!CT$T?>"=!#$SKX?@GZDKHP=+$^6HLN_F$![R?2SU M'&,1D#I(@O?ZGLY!^=OPM.@+#/H\7*3)._SC%DWE=/'NX552%L9DVJY?0*G# M%L847DH._$O6%`QJ%XV*F57P,_O0DM*8!7W<$L1O$T&T5EDJ7!QFV6C+M!&$9EF2=7BS(.PV!C(PS1 M(EN48=CM#AU\&>S[!RA`UN@FRH/->9Y=Y]$L3-);1D681K-X"\PI;K*\)/D& M'>7[>8PF(&]JEH?ED!$VJ%Z@K,F,T1GB;IX5E/%Z)EN3[%S)FAHS$T)9JX!: MR<-%D3_$73F5H^OJX?5H]`#_]V8^CQY0#/WO'^W)YI9CQ#@^Y:BD6143P?.H M'3Q8EUH=3_.)WMO>:;EBK,[NMXD3:YIM$]GDXY-ND1;)=1J/R>PKDO^)V>2S MF=KOMS(J3*Q[K;+U;_G$DEY/+F`Q:K&;"-`P7(3XCZ&=3Z0E`2!_`1"XPW`^ M^B^0.\W2:Y*-_T`]BI8+)+E1+I+$80"#DW\XVC\6T1B/!;B@"<^AZ9RO+P$Y M/ITK".=!"+6*<\T$T)A&*4+_]O9`)"K4P@+3N(O^'?1!)+(X!7#PR<%>]._> MCIN[[FX1!05%G/=8(_@C&H]S(Y?W)/IS'-^J;6&#AZ`=PQG7=@8;6`E2/<`B MLVP3%!+L`1YW=M&.OG#8.,@V"2K5C8)-@18M_N&(68= M,@Z+&"#V;?Q>;P,H(I+YB`^W#L@GQ$)UX80A1FGI&.`TD\UJ:.A."JB\,GPY M@!?'))GZ<5``"(<`0I/>SJ<3E,YA,U<=R&&!UOS!K>0@&:/H7_G9>[H M-#:DT=B:03.S%/U"1(?GH9!R7T>@&5QTK-6,VS+-I,B(\@-@FH/`/63));]".N"19 M*KYL3M!3L837\464C_$O!0@1\I8L/$0V!@$V'^#52&1H&$@JQ?`AX$W&E@9# M+BHM=G4$7D%"RNG`X"K)NHN2,L%*JZP(KV'NBAAK%[/9>[.0I!`4%QQ4K`2^ M"F9A'A=Q?JNR>H9J6:0EV))9F-VE<:X"OTW2\=#/FAECC6S';%'&[ZI:3X`H M>J,DT$EJT[-T9"U=)GGY'54%JKHUOQ/]2JE""1@FS@N00RC[#@U?RB,HE_P6 MX\Ⴁ-NBX1Y@32N6&,1;YJ?NQA&Q^9$I;!;X+O-IE&93&.-\5S>Z,.3 M<;>"T5>1P6B4D,=_+))<'9PH<8Z'K&-\HFQ@JEU%>9[$N9,J9_-90;7]GH6> MERJ)P._MU3"4:E(>F]U=MCUUP\VWV(&YTQ9;Z\#:8G/EW]A;"W6*;ZHM98[O M@@'E26ZH92;=*`3V?D$H57SSH^61K5?`-F`ZGX6*%BBJFII-MH`!VPCJ662O M%UP+35?)HGNZ@&_M]$RVK0O$]D[/)GO+8"'1*GFTD;*-9B9IB:)6JME$)0_F M$+DD!\I@&\2@@/1UL4$+K(V:V*(%8JNF%23+1Z`N(JKNQ^U5>&_$G0%X'DY3 M,H0!64U752JDO>UZ`32ZV`XN4'9R-A#=809\H^E&1-BJ[?TRZ24=##!RV^+1E;Q_*$N9QMSA6!8(P M202J=4*?J`I084"M3TS6)R8?G3O8&6+W8U:V/D]1J>[M>)4YCQZYT%4QP(*W M\!V@+(B&5^M3-T_T_"&PS]J)BA1B6^1_'N,C]^[0+(=/&[P%GSL*XG,&;\$+ M1T&B1?D*/N$%';OD1;A,>VT4S9MNXVC.!1M'`X:HK,SCZZ0HB7;C*WR7Y6/! M3V6(ZSX6Z3B)4MU+`6VRT%[,S'H$YE&<@[XSTS8]XFG//$Z4&CCLX`"F`?:S M-)VH5'BL='EU`:FHN%IR.7)O=IN<(-59JV!P>CCHDP("! MBPJMC7ZK:7)=Q+)9-/O'/!&#)(3FG.#?)<6!PG:YEHU@7R]%?G[OZ.:QE1 MW"QI8K#!/!@FXV)+8MX,\8D`6C'):0TV9^)\,G*-SU&$F*X;EHG?C>)YZ2JD M\\HHBE.S12D5$Z6A\Y9:NE13EVMK0!Q;`T.BP&WV(9`+F5$6)1-W`GZ2K%]A ML$>KPDYL(:]DJ(>+.DL$\[34"NYX^.-E"LP6A1=:,]L:-LN-FR4'3MUI(@5^ MA2KK6OW)&'E?S*)1GDD?8;^B9Y8!E@9]E>BYW)B9")4247BJ!(;/B@%$'$4" MZ76BBU7ACA*HGBD&#'S#)4:G0@%1*E))JX)))265TE5BDZ7960= M3@(\F:["E!I/J*T#L<_`U;!AGMI`)JY8F['RRQ# M9\PFG3+&%$^P`H-/2]V+%JG,U2S7("&]AC6Q'`D/4A,;BH.M0-+/(8>=#TZB M'"M`-57UR)HN2U?5V@M7-U&KHP*[3F6-A*2?*X8$U?N(U=-3F4$%[W=\^'SH M5(P@:/6LT5OP#'&,(US'KJDC==GKXZ:I)O5(E*H7%%/M!NKJC(NCD9 MG'=4,0'U3%W>UU)-=4&[6HT--2F=VAJ*E*D6H0V+2XO2<#?4CXRR[GGO.+WQ M*DQ#Q]!S]38ELA7Y[JK8)]];$N&NJC^*"'=5UJ((;TV(RT]X0KC-[1W;,!X5 M19Q+FQ_)HVE&%C..FWG0)OI>L-NO`&8L)K?DPI`"A),HF=KLI9E)EL(JFY?1 MADT&]R:`99&.,/YN)[`]T=*,]@J/^`,2/J>!=BC]M"H<]FFM6:?G,P^8Y(CL2V<'SW"WCI?*<9*IGGK*A)@F5W@3)"'$ MD-=S.D;1M>?\VG-^[3G_E7C.#W8@6=!GN:O,]BB_5F9["YATWB@G_XMD6B9I M>!LA(4P<3Z[3Q8C_M$7NO6!_%=D#4N/[E"N2"EV!DSZ]?QZY^T='SZ_['I^% M3X]/C@+\S[`:+`P-0'UY(/^*Y6$?R%'+B)4I73P,GX7.`,;K=62]CJS7D?4UZ[\X>*"7Z@"ZCWNC2Q$;>M;J/I@D1?"D-$`8X@Y17; MTKO2%(=X6NR[`ES8=S9]:Y^QO0XZ+N`[P6[VZZ! ML>OMC=V!NZ/Q4R3N%N\Y:]QSX,0/"KB&XIYC**H=!^L71#P8[RW(XO@MADH= M!IC>W*$R#.<9#70E9R@SU-.)^RR<(`@MVJR!A5U-KH5'NK6S^:XUZQI1?:M; MR1.81 MI`;TUROO>N5=K[Q?U\H[`#5^MO#&Z6+&MAS/'I^=_AJ>_1+\&&QO*2FG9_@_ M>LJ3G_7?+XY>;'64E*,7+R]_#X]/7[ZZ5`&?OCHY"<]>71K)QRGAQ='O$\H-23HXO'Y\G*/OH_/SLG(7QMEI[?!&> M'%Y[FD8GIV>G1_1\A<?O6=-T)S?3QZX>5QOR5IE(E+&;NO>;>R+1\G(ZT>*X0J?,0O*5 M"%%C.J$4\??0`E!Z7P`J:78!1I(`9K_5QPNH`+4FHZ04`Z6HAJ%;IFM1[B'A M3=QT;]#*']Y$Z7@:4TIUU\)9-F9/'6KF?QSJ'H">Y-F,/8UH9Y99*%`I*P'Q M(->XQ+N<^`$G%A,E^P3C.I*\69(BQL2XE9@:Y=6"Z)TC0Y8H,Q"^S(9*#<1^ M.5E,24/T#G/V!1]=UGP,PVR!W9^'[JP8Q^M7ZI],H^M"2U%>IY2]HV9CW])H MBD,6,^Y+>RQSU<8J@,-02S!Y!R+Y-70\-R(Z=9+1$OL--BY+,3"TW5D535+$%O$8RZ7#`3[P`J85;AP>[\JC&.)< MS`?J66VE#/A`9M+L*DGI0P6(N$2T3`N>^&RYZ*2R[(I121&2Q5(40%CJT[+$ MAL)P*FO]BKM\\-EV4JOU*>YQ_U[,YJBO38\YP*>.>H^C?"U.OE)N%N5OXUQ[ ME4.F;K(%);!\\S;#@HBHCI`IY&`'[X6WP48228`W+&3HCN/1;8FO.)GI98(CAAF7ITLID?+*SHCI&U-VQE54Q%8.??K*DP75 M0W.@BM!:!2/#&52;-C**Z-91_U4T>KN8LSRP&%//#>49Y_+7\<_Q/[0JZ?-.J`VO>V]HC9:2@,@B779;1E=X/V=U*%G.A2N7W$ETJ/#: M#,RN-5(9NXU4SCF9K/>HF6[AUOI2)JL=J:?R7F0[);,+9;+6?Q8\1P,I0_2/ MPLQG"A%"A.>1X"0.82$WCR*DE.)4DTW'^$\>P]>*;Q:.%CGJ]^EB1N:G]E(T M[4]1G+O6&0,"UR:4/T0C>P62?9IGCB0$''^;<@!J^4(>\($F#+V\Y334EZ"0 MA;-ZW=M5@K%CRVGP`&W)9!*SS;SA0]9Y2T11?HV\<#[%SV#RFY10+OG5#WLA MOL"2AL.ZL$@VU@=&VFIH1`Z2PX:(A3$>.:X\(H==F0BWZ%#[.3"TT\_HA)RD MG*5XP)O&6,"J@\;*E;,*OWI=QT:W"2B..OE`WB0^9OSNZYUE321X1M.L@(CO6@^N2?91"/:37>750[2J7&'0[+<+ MG+>'0=.?+F!!-(-FOQ5PAP^?THA-_,>0IPIJ-\E?(IV3M8G_$*FB_DWR%S$\ M$`E!J$$`G!3-#]`)$C@*ZGLW`H)EJ77A6\&;)J6A[HABI&_5V]#TX4WQ`"ELW5%E0I@ M'2"X:IKOL;2HY*-RUW$Y4C$@ELV-1J*\^0)#,:/R5E`%/J&/HU="86,!`&?5 MC@8[?;XW'D/@2K/$")Q@<#+.0#9*N$7JAQ34EOE[!V0%BV\GQ2A*-88$,F2> MOH]0,YRS0+\52N>/$H3/IOUV,L_1WT:?P!34(<"@0`VW(I8BW&_1.+4FQI8$ MDN640@4:D48I?DHG2LGJA):$2Z)A@G[K906(=A3L+(]6*%]YI6XY@O(XYKIK MA(28-3B,F4LGW9UGUBF0:.)A2+&O"._J3#^L[YGHN9A5PQ.J'_9B&\!F4< MW=49T&+[56M,+S.H[^J,:KD+K$-%S9%]9P]MVFG@Z-:'RIUOK-">V%=-M?H- M;K%Z<\?^@/OW`[DT)+WEM^_XY,M"1C`/ZJMWD\WBAV.T%>/^2-<(;/0PN_KW M.,EYI&M4`C%N)BX!/&I>T$,=%&J$LH5QFG)25]M%FJJNBT1%35?&5Q[/T/(* M!]G"!Z/&(I631!L<[2-MK3N-[_1`,I26IY6Q<]UQ M,CT%L7@NE*:R"O-XQ2JK*W65,P5KH/(.>Z-#X2:@P4NX5B/F\"J-Z`Y!QJU8 MZ_+,JV"?Q:(Q[68U/I_EY"%M`#9[Z3Y([IY5.J/K9,0W3=X5<-FF!MZM&$LH M5*'%*)\A<4O:SC*>9_J? M&!6%-AU%C,U[4KY8_;T%<12*=HXPW2Z'"FZ2U/M4MJ8Z]Y0VH'U9:W4'BOT( M_V&%AT-5XC!H6GN=HIGK>V[BFHK;29;/(J2U??_]]\;Z(G3+90H7O#10ROD> M6=UZU(INO3RQYXV-%>XV(_`06K[S:Z.-MPTX!*+K&/C\3&N]*7J'I?[*Q2"> M1>^P0')55:L/(76(YE-O&4I*&&X%@ZU@A_K-:%:GVW;(K4O5::N`00K1Q8RRTM=FZ6O4]1_7+]LQ'D_<0P_0Q3X]) M+`55`7%`=$P83+IAXS$@?,8*&YD"K6`U:6]B`#$.>WPT5(%V3>@8/,H#4 MKE#KPVUAKU7.IL@N!BSXV&9?U;_86L]QW/E)ID,8]TWA4H(HGG3+8T+H#&&4 M2HO\N/U[X)JV"UJ%WA3EV!4PH>,3D'$\31P;=+PC]&DE_`/WZ"EO':D@0557 MXO&UTR*^#=+;(=S?/1#AF+H5Z':0[2U3`GTEH9E,JXYGY".50A$X+BWWV@^88.=#W&#/9 M(:K1<5EA6J>P#Z:&2U).^U\BPJ5K^=]09N"S"9`=+#`;Q!#+?X%RQ$:EZSN, M(2J8@R7<8\]FBLT3N`&2*XKWG]9%9#2-IG&4QWE>==I'/(HJ0*@[D6=0:#76 M5+-QS;5!R0LG]51M0LNA\O0S]A<$0%-[\O'YCJ*=A M31RAA<08M\2#NL9.@L!5\<,XP)G#!YVC;#:+4N^!F+H,.T^0+;5UA/Z>)6-` M<]7!%D6<0V`%]6[,\+4!ZL.MT,%20VZKT8&-"<92O6M$;>,$0,1M:U0L:\V0 MQ>U-NNVG26:(XL=7)>TU!SWW1HVB5=W^_"N9_KB!=%=1?5S@;%#P\P>S,,V= M6F'E8M4$IQ4NP? M_YW^8TO=;'D&EU\[](PI_JT2K&L54]?KX>O;;O; MSN4+Y>[M^A:W>\'>CMLGD^)W/"YG/<-J^]UIV6V=>-<^HJ?`#8_I]5-Z[XG0 MTD?:S0Z.JYMA'WX8O@9U3XL:'7TVH*MGT&78D>N(@@JSBV]3ASFP]('5Y]&? MBAZ[CKBZCKBZCKCZM41NK9H`PX\CAVAMS40S(*?#)(/\]X+=KT@QF#X2H7["M/C"Y#. MZJ?>A4<*S#C!1QV5E[;6,O?O_/"&I_GS\8L4:7!CXQV;>58D[[0L\32.D=4& MV;W]71"U-&XB)IMA58L@=V MA-:%X$-M<7J;Y%DZB].R,*S`=>`[4`5W63[&B_ ^]!L<2'!7XX.6+2+7( M[TM5HA;Y:.UJ`&TP_6#;S72@C[[.16V]8UGO6/Y/KI[][0;3'_R4P#MIB=0D MM'GA?PPMD`+IX%.\G0C$7[I"I=Y#&(W0]L#>-)![H7S;@C#;Q]SQ(ADW+*TS MA;U>9"W[AM?+E#KYJ/[^BM-,$9>VWXS54NDQ0K!AUPT#G_0Z<6!46LY.V3D& MW76+;2VIUYJLA/M).6-;&>69[YE]R\&!""1BWH0*F[&*WXO`V)0NCT7:J&Q( M'\H"9XK=HUH3]?[T-M)S).[!9LR_!,!*/$PJ!!962T*+10$^JDOLGN``<< M&JH+84W&M)OND-)''!-8PG6>+>:`$R[#IPZ3"AR6A)VV09/>QG$"N%UA0YGM M5\*`%2F']#?'5LWTB!_=*2Y#^GP0UZ%E=:(8#C"9(PT:F]A":@C3KHR8\$8M M-@?'B[DAI_7,OMI!_*^^"B@.6)B"/S1S9+JY/KZ+1U`P%9N\1MDD1RTNE/:((2B;M<$:21C'U,D(,Q4A@6^:$32M M8+F=N^:4KT46+4XL?F)4/&DR$OV%]%3`53*,W^%@@DRZEE&Y*+HU;+B=BKT\ M?CL"3S##FE$%RP8Y?N>+/QX1OGP4",)J%?X>/#T[-3(TT^ M-$;33@]?'!E%7QY>/C>3CE\>A3^_>JHD/7Y^]MMI>'YT<7E^_/CRZ(F*\RR\ M/']U^EA)^O7)\<7ASR='2M+%[Z>/P^,S)>703GIY?GRFIUR!6')\\,=-.?@DO'_^BI)P^.S][]?+" M@#M[>71J)"%F'!V^,!(O_\MD,DK\?V<_AX_/3B_/ST[4\H>_'CT)CY]<*&D( MX\GE,4)P_S\[/3LU<7 M"E,E(L3`)WH&+V'G/,59RN\7AR]?(AC2$6KRT8N3,XV9+"4\/SQ]=J2GGYW_ MCD@YNSQZ?'DL1R[)N[@X?':$AN;%A=[(BR-4\?.S'YX@6AO'LY_^' M$&J,0(/JY/@"56+TRB&80@;ADZ.3RT,C$Z4=_D[8;&2\^$]H=*!4@DI/_15U MDM[:EZBI>#"C)#D*+E'WFZ/MZ$5XBOXQ!R9.__7PY)4YYA"&_WQU9"6K#5!J M_!G][_#"!$:I3X[-$8X2+QX?G@"P6#J<6I/N[.0D_.WH^-GS2Y/TH_]\=?PK MFH&HG\VFG-],-SBE>9C2*W#W1#/T1-.#Y] M8B0].?I52WEZ=GX))R(9J"5>_&;!H9F`^/;DZ*E*S,OCXRWM5_BO2S,%B\&C M2R.1O@II)9]=:*41][7!62WY%\OG_7M9KQ\-H`2=]3RI.J?M6XF2;9X-08K MD@@&$$G18$[.T.J@(__M[/R)D?3BY_#$6DU/_^OH7%-5@+E[`5!Z`9!Z\?S< MI)4F:5"O`&RO[%:^(HTRTI0:9`M.L$9JM.HD/$&*D97XXL)..[52+HXNK30T MXB_-P?WSQ6YX?/)RT`_/GCX=:`-#R_KY^)F9=_)R;P=G[>W8.0A8H4VV+RR-5 MVKQ`VX9+M!%@_%!S7J&.>HG*,!&M:9RGS\`,I"B@>6Y4C%F'--'?SO&"20C3 M<+U$R["9>'[T#"F&9@(@%B^>'^EJC[69NGAY^)M6`@V$PR?'6$,Z1_B`!=H) M0)D7/CF\/#3&GY&C=2P>,6>O-&WH\O>7OGW,*U1S2/>F<*J&_^7/%_JO\/#Q MX[-7IY=Z+^`,K)9>'AF);!-FI%Z>'VJCX>)WM+T[>XD3/@PA>\7C"V)A$'N- M+9%\\A0M^T]/#I_A]\A[V]O;'"W+.WE",LW4XY_MI--+`!0)KL=P,H@9IUNX M22+##C3!E*Q*>WI:>RQ`FP0;1*<&R+>;;=LQ2;JJ(0`G8UHJM M@2XK+`NOPR*%VW$69'G3ZNXL4[POU!("SHA/@6&*,E?!7.\)36,C!BP^5!O3 M0#'S9&R'&%?S=0`0Y#J?6]',33AR@V-^G9!`&CQI3HM`*$%`TYA<@)!;2J4X MFYZS[NX>.,]93910>QSM0O"%SB&[-86C,?*HD$,NX-X0^;$#X)H#7%?DQ]=P M=[+`5^08K1#&=QS(1#EDHV$"K`,&4@B'8KZ*R5&;.)-S=MJ",H2?YBT@:A!8 M'AN`^2+1CA5C5TFSX,))"AL^-LTF*09@?DU)X;]C5TFS(,`5/C0F6?X6/O_C M$+I1VR0?/69";H:28\0 M/.*L58A-$(;2(06GV->)O1ATHZ1S!\GT5/1_\C2]6C/TX9>#VX$]JYTM]WH0)3#AP5J MS8@/>]HC]#SWUGP]BCQTB0IRMQ-\B;COX:?ZH7YQ]";V4=[O>QRV`>IOLJ+4 M+Q&Q\2>\`N$96:A%88<^[XQFY;%\5P)P6:*943G.9E&2@G3JE>@UJ,66H'%2 MO$]'EK!6(6YOHO1Z,;?5!BHI;[.WCO=Q8,^M/$-YBI<4?4@59^$Q$\WFTSBD M;P_4"9DF(+B;HNE]-8JFIG,-<_(L?3)%@%$P M,>=##9Y@8QF%01, M>$Z34*-EQ*\D'L"7,\"M*`G4H(@WE)9FJG,/0O=HQ^/"JFI^^*JDO14>S4P> M.QA,RNO,-3%(/D.;-Z._\$O)FGQ,IN/8CD_%%L/\_1P0$V_C][;264334I,= M3#(P'$+?Q@WB;8C'.(2'J?E3B7$777D#4%+5%\@H,TBL%J87M=W8$@Z6AI01 M^#:5M@;0VV%(!LCM2K!!1%<\C_*XR\:W-UJ#+!1A!\EF948WJ"=Y$3%.!X[+ M>E:(D@9._EJYAA<$+%=]-&Z7_VM;*?6!E6W=[.B28>V6&G]7FWU#D6S MKFVYZJ;UUYP_SO)+W`K21++S)@ETPP,M&#G_"\3U*LS1!:B[& MATK%HS++WU.358*OXJ10A)'R)BGP]JIRJNB?VH*&1:WK)%J#S6L?9J;SVH>N MO[1U@<-SA]VB@KK,>$ZCN28]9#CQ;,8'J'1':)-4[\;'Z M7#^CT=`N<_BB(0#.7G3)WO1@1&_U$BS[;*+Z^(R:GAGAE-;8BZ!E'3 M9J=9R%!O>&QD'=,D0)31.,7]A-7!11Z3HYF]@^HH0^L.$%W8YDJ M0P2)5,6&M8Z7LHZ7LHZ7\C7%2QGLF#+`CI3"7G/`IT)W8Q()FJYV\SNRW`W5 M!`J$D[@.A1+1'S3EFJ=YI1[)B%;#/Y>1(.S"$Y@6J?63?"_;A<)+V;DDN<-K`Q^;9M#3V3311 MRQ.[)S//J7\QSS4+W@PI`L8YU:LVXG?Z2ZB*'4TDUW;HA88P23/$]C'^[Y`E MT4WM&/^7"@><#!@PT-3#,6C2H0Y`>G9,#J!I#DO`0_QU?W?OS9#?(M*(VMN1 MMXDP->3LQZ2+)1+*/A95O+O@[N4A70\07E+`G$\Z/GJ&$`YEPEHS9>!#UD?D0#M=,8'B!15%\64;>*']L#C&-@?#MN2 M"#@I3)#/R?3M[>PZ^*KKL30CV,0F)P"1N1H:(TV4PX>64$G-/9%`AK(.9?7% MA9R/T^J4:N502OZ^9L&*]=Y!+YHIC2D.;#[5IQHH[*%9#.T_$:WL;2GX)*[\6\91XL70M0R='ZW"CY0A&LWG7]#Q_%C.VW'//D&- M^]T.<.PY7^2Q$N72YK6H1N7VZA6I=X3BO$@0BH_>%*6B=ALCJY&O"N*3=S(& M\B0N()>,6I<^U3';T$]6[.>-NJ(BGCMV$0[J=0?/9>E?H@7JWM_7"M.&J4M0 M=;>*\%7L5VW7!V#[`&])J1]$37"^QW+L1BW7%WTG2O<_5OU-]FD>LQ^TDP1J MI$VHJ-.Y.P3J=-!TO&GC*5B!B M]U-4@:]2'O%+NO3GE?,%/"D=-<2&^%T1];W@T:"9P=>G@EGO"R-5D9F"-0B: MHP$(>["99U:PWK.M]VSK/=M7LF=C/C66/+"=\KPFJ+LH*Z/48'XV%7R=^O0;=C&FZE,5Z6)3R*AU/(@($(A8CMF1I@)/%"0M> M8^Y82']ZSD-7<+9H_\FIX&NVZCW[0V]O"&9@UU2DJY2C;!S_<."!&65Y/%[, MYC_T/$#XVBM*^F%_R,GX@--1*TA6DD9E//;0WISTHLSFN$8?Z1CF-IIB&),J MG#6G)*D'9#N58]_\^)D2Z3?19;(7L7*RF)?Y4'0E2DA8`B;GM\-C'*CZ\/+5 M!:`5E'F4%O0J;TB0VMM`BQ3!83E\_EADI:0@CV>T]G%RRU[\#;\.4<5H04@,?6A=NH`*M!N7CNP^N]XUP?5A3#&=7^(F88UX!\T^QO2^#$YV`)Y2_(0'TW"&V!+JWM'M'CYX#`]DR5I M9E[?D0DOU8@B"A&R=9)X,K$\EH-CKF"NT)_%Z][@S9`H3I1I\%TLNAY>#068 MEHY&1787Y\[\"YIJV%M]`S]:C?((6M$E[799Y6-;(3' MVW^=H:F,L1:-5VR/KXM\5%`MC1$Q68V(1C3`^AL?N:NR8_4NA0CNV+JTZ#YW MQ(3FH[)ZOHE7/^%N;)&8YK3`_=DF?U;O7?:I#0!V=&)I:Y?X%0E7!8S1@%J+ M7?L]T4JS:C:PV?KW,=K:2CN];5QR170UMAGWZ;?J8*!?:T."?BZF=:1=21P[ M)CB00LSD4*>NR<.W]2<73^G3J[#83]E*Q\7C-NK-#Q9%O..CE+87HM4=*I;6JHU_]^TA=-:+?[GRR,G;I6J(;=/UFV^]516<=:U9"N M:9UQZ3([ZI3JG5[#3-+&:&W2Y?XVP$*S4]OHT\X(;C:$FW=+'=M+&RWYNSK& M;@^P'M5<7-KM&\?RXCF'4"N5JQ"MAP7MV>P&&RS(37>["TH-S!O/085:"7:M MZ2HF:4]56T&O8HWRG&E8#:M=6[,1[CWXL&AH0(2F,%#8Z=Y.I,5\3L%[.]'> M#D`1^%B[>@QC>?*\+QYB0YTXV1X\\AG>.NJQU:"/-J9YE(ZSF2/@1,%SK9". M,?R$2I+2@^P8+"(=M0B,UZM21HS"H&9P?HH'!XBCE9EXY>$HLY_2AA#[J7HD M2EBP.5%/9FE2;B<1W,KQ*<*H7+H42>/XVD@IXKF!"HF&D!_^ZB>)C$YY!UTA MO+93JJBG.GY"(2L$.PRF@G%8P2,ZWHD)6%26&`65+I)>?IF-CR7-RY!7MTI] MVA%X.>&L^>:9;082B]>;^M0T#4UC7&CGP`PBQG)CG@N<(H3ANV)QE;P>O`&% MV11&+/+3Y5'/*E#_NS%JR6E<3-T$(];=1E-9"72<@H&',WMXMK5"M;HK$ M_+6SV#S*H]GK?4HE&U2LKW2)!91^]WKPQGEC//)ECIPY6/F7>/GTEEXRZKU2 M1J846"KA<'P0QW1BP]`AM)0Z8UFGM].K+L=\'$+U-Q?:8X\8J-4,2C\Q@ZI( MU5@T^R0L^O>7Q*)"$FN+JRT7+2P*3L=<\V)?NZ4$KQDU&_*8TG!:I.4Q M0\QO7Y$]QO*$3O(XUI!I6@))'SE@S'T$J2+B-P*,VP!JI@S18N2QOEC?!%C? M!%C?!/B:;@*P]P0M62"\H3491_--\:LZ5SOD3M_&A>]J>;#="W9W]GS&#@W9 M[5+K0D=;T$A$"QR\/9JBU8R+U4V4H$IRDCF+TU*DU%TO5(*C*W)?V!7..=-)NKF5I")?@IX/XTH&,>AWEUUW]EW['K@UT M5@=2C"J&6FS1<(1'JR&A1@+\+$!Z6R,@E+!*D9#7874Y,^`J`9>VK3Q)KP'` MPH/7#CR/YL%"G'WF\7P:C9@7I,HII*_5H%:/?!7C"PJWKN?W:/G9VQ)-%MDH M_&N*QBL8.'SVMJB"!L#)W4MW`9.>L;<*E&-U)6V116(8"/371WD*F"54,-K6#&TZ32Y(CO MZN!_Q3,QBUDL_+W&<9K-JO!QXBBJ*<&EGJM0A$I*+:P.#O!:E&JLNFKYFYA% MZQ$%3_QX=(N&H?"#TT1W.DZN$_;HGSZSQ_%H#L<$L&'QKAQ:XR:?K.;K&C4K M]_U56PE-_H-R37EJE+L%>N633UGY=B.4:;,[M". M\0Y#6\>I\[N1<]%WJ&C>VNY&93:[4M3]K8!7'(;D+TUQ8(AF5P4FLO!0Z7W) MM3ZM>KT(+2:W@`].JVOT4*O6VX&V!?E\%I4C6!N>HX086E!Q0;0!*Q97F7Q$ M6J\=92"=P!E#5NK[N$Z]:)F]11I%D]NN9-I887GY*R!(\04?RP:W2==YA)]A MTEZPTB$6*7XKVP;1EX]Y6=#-B0&D[THI4*-7V*S0_:6Q2=2SIUDTCFZO%8'. M4EZ_$7(FGL8SU:ITX(AOT]?1$[<(U`^ZTXMF(@@KG%Z,O7U['B^PSXME2O"X MO&@VG2I/$M)7NJ<(%+%J!?\0#5%]!Y&E.-6`$LCK0]19'TV%`X8&N^J)=<51 MV)9^)`UTXZHGPE4$.(L9YYP`::N>Q'Y$TOSGKLO18X_&UI?H3TXP\)<77(?Q3X4=((4W2 MN*!*@NPLO;?^6"2CMZI]CZ*8:T:^,BNC:8B5#(\NJQSNF*9%'"C1;/SH710: M)S/*N0R.O\B/T/)K_J?-PA6/H/!7?>1U+^@-=BN"#]HQ!?'QA.E!X/13WG$4 M[EMG@*AIH]'\O33'CI$6;9N%BQS>CVDS>.3?U9!#EA3>*1(*E>*SZ!T>_2Z6 MVD%^%$Q%/%>V(!3UW)9(XWB:S&RI5N8XTN0(GUI85/9L+$6_`9&BBG2$YD.# M.FII:TNRB[S/#G=(K2%M8TP]*+?JT.MV'L*:X1T>LS>Y?:!1\`W,:#E.(*0I M=&MN*;S*!,LKJ*W%$V\-+5>@^BCA3M/$CQ*Q5,]3S`)K/Z6UG]+:3^EK\E,2 M$4L->:":@)B+*!)'JD*AF:2=X;1-X:4:/'-+L;!JG&6W<1T=!C)_6M1[R:^B MU+%2@Y+8]J'!]:/MCJS>(<1-8SJB6M4F1&G@40*D3>C+@7\IL+C3:*FI>OQ` M]^"MM;0WI+?AXEN38'9%#ND,>*P`5GI]K$!F_%P+\R,0IEZ,CM'EK\(=VI0;PO6F9OYODL\9C MJNF@ZMC[4C.:W_8C]R)B;I%&CNAH+L[KX:":L8A4B)F$*Y3[0VBH&BWW&E`, MDF`!`N^5ZKC.`M.N_L:KEIEBQZ'HHZS=OG,/8$D750`#>ZH&VS2$;45T,'U5 MV[ZZ..64&Q5S^$3CY3W92Y/BF[64A9GN2^ M5V\BH2-"%=0D@1I"ZXT2Q28T7V(7!A#E7?5-WBQ59\.M'R`+89OR$E*[J76Z MZ5(3YWDFSG[0CW0QKZ`GZO8.5T>DZ\V0B'-T3NR2I MPWA4JV8)HR94:JH=V4]]94%_<(YF:ON"3R'5W46*6.+;V_T9N[)6<=M;RX:G M0,U,%2Y.-=A5U=_=9#7U>.L(K"5JU#V935I]9DD553M%U`+7T`-%_YKN5,'L MFT_+G#@VD#.X+J*I8Y_O?1),]U903Q'V8(L" ML0"9UB,%55]_$((5AP#Z/@A&Q4Z_"D8A>6_'!WPOV!_40&:\1?&GC`M$6(_O MY>:O^V^&Y+6JB\OSX]-G_?#QVK(MYQ M(-Y9%?&N`_'NJHCW'(CW5D6\[T"\ORKB`P?B`P]B;0#W#K9K#W?S0_/IP#]9 MT)SN>:<<$STB=J2Q0PT+;'?D\HON3+:@25`['C4PSEU(&PU$'`.Q"B79H' M]0@L#!#P'H1HG^9!+(;G*`(^4-9D]).8#G#(.?J"(0T^Q[C&PL8YN#2*^J[\ M``GQ#>"#8\Y_E;E51Y';X>R1%^64'>D MK#QF+4?1=Z$85*$81['G0K%? MA6*?H]AWH3BH0G'`41P`*#YTE%#1:GD12QAC"N[+,:0$%7;[%#K=#H;JJC@X M>.37"G=VO``88G^_R;*IGFE(R4M35UHO5U@N5U@M5U@L5U@K5U@JFZV4M%\Z M<'>Y=HUM+8UMK8QM+8SK=;'INJA(L#87R'_\]_8_ULOC_X7E45LN+6;_L[EJO7^OU:[U^@2C6Z]='6K^4 M?5SP(.AIR]F^WP!IW!TVL__M[WJ42`3SR+I3W@H/>;@7`P+]5!(RR!_O> M-IC27/5RQ7Z)X:@'NATP6<4\$NU5@>+I-,3#G@"Z3@J$3=)"@P*@(;"-._SN M)IF2`ZGB-<]Z$WQ#IWSPW7>!E:$X3J+O_GV>.51'#D_ZT*G!DWYU6R"#)O1I MA?JU.%FK=A/QQV5M3S;6!]9OKPL&'ZL+#"2#6EU2BQJSHHZ'C,%GTF'>W$'= M[F2RZ%&_D1U+[?1J$<*\B_V]51M-#>Z[V/_CCPJ:U8=[]92G==4<[5J9*GE3 MOVX3;SO\ZP5__14XVS=^!Y"FS.E>JJHIML&M0-S178&+J%*-I$2N&%@V4H<1? MY1P1E&C4X`^F"'^\:7I5@B*5*@9>&"8?&TMP/^C)W`\=_J]37:6CRK]E]XPJ MU&YE%-3;-*OCJ+J\OL;+(53>1E,Z/@HYDG@R,)PTX6,.`]9)LKB^F=XD/=B] M?U_AO^@G7':#HS4.WO$-DF1:)BD5%E%:AG-*)T&.QY#R2Y&)7*H8T7TH@5N2 M/"0F"G&?U,I%'QZ>%B_@%FEC#^:3,HQP557K*.[=OJ]W[0U\]7!IB/#3CA^B M6X(Y_1I#BT]_B_P1G>Z\%TPAA;)U*443)%%0:E\78*.Y(<$DTJY//JDEW2-- M2B=#XL'\M818W=$W:#18:FESE783<\`VI,%O(?F,!C!CEBM_\-D-<+UW(9#! MUS@'KO7AY[AN7SV.Z^%I>;@"XW1#<%E;:_\4VYMM3%Q$+@I%_6&]59BKXIJ[ M6W=#@4*:51=IZ`Y`;15'@/\D5Y"B;=*/YEY!0G=?;[\A=&X+_=#>$F%$O4I$ M/8JHIR&JJ8]$VUP7P7\UT4.B;9<.@G*Z@OQ^)?E]2GY?)=\T.:C(:6-I!5[$ M@S=*@\P-M8V14L$:Q8,^0)I5)<@P^.#0OR!Y`$UL\[/O1/M"50;^B"8XV-UV MG:LZ=JVM157!-`SJGE7>"_K>VU!]"L$CR^[&][ZZV'ID8]^G6R24H>MM!ODI&`OU;6(S!O!5K4>\\I>U]# M'TYS-'`0B!ZCN>+=.1Y5;C*-K@MY9Z_O:C;N\_Z^MPMIG^-K/X_\761REV30 M"W\Z;V4&OHID9SCZCKFH58,V^-@]*_PIQ1$6Q`D*01JBAO<-0<Y<^ M7:C`[>V8]^,^HQ[:V_E,^P@3MFPO^>KP5T&[<&]'O#^)9CJ[-VS,7T4.XC07 M+8$B#Q41YXNMB76,.,]9S'<5+4'1=96E@\^L'*=:EZUQ(GWP71:2D+:DITQI MJ8VKM3(0/>1J*=103+Q:KJJQO$%8RW:L;K2E?RPRY=58I,>`2XD5%7"I.BP, M=I)*\PU>KH_=&XTB..,PA$$*_QTQ2L.#HE%$9C]F[%+%^ M<8SS1WF^U]]%';./:+_09EK]-61>QLK32&CHE#?<@4@M0$Q+K)0\5.JI_K;4 MSL`P(!2PL8?8A)A%:(L:HMBO#]HOS5ID(E$1X6WJGP8L_N[?)Z0,.V:R;F5B MG$&[^T6LIW_HF'\Y3YFXC4VWL&TH+?OK+\;;GP)YGE#=L`]`PQX\J-FP#P#; MQ7F:!@F9C10`FS\]THE-(C+#EW!A4B@4SM@\W8KH+// M'L*L`*-)"`7EMW_R,T!MDM,9H<+R4";F?$#"BB>SF8U2R+%SP*+QX'?K^:]L M.AYEB[0D7,5=P8@W;'AXE!`Z@/0-TKK@N^!_-S9ZP7_\!QI&?]$_>OR//O]C MT$7PY*\]GK3#_]@5>?L\Z9'`M"TR>P)K3Z#M#<1?.^R0;%L7`&Q)2S,2.`D_ MU!AL($#4F'Z?,YR/D0<]9=Q@GGPCFLA;@28*'8:$*0]^8@JX\%'"I?0R/3ZY M.$66T*M]WHB%"IG%Y(\JZYX8O@1:VO:T]*[@`::N"A5%D M#3W;O#=IZ M?>C6J6NP>EW>['Y]4G8^.BG>[$%]2G<_-:7>[)WZ#=G[S!OBS=ZMW\[]+[N= MWNR]^FPX^*K9X,W>YURRUHP?`B4J,I?A8I4WP94H6G)MP\LN6M;`O1I9;M1U M%VL*M(!#4>#*@J[1"S4+TJZ)%LGU)4O5-C<1*F*\_#/253"^_R'9WP#[%G./ MH^!169#3*WJ]KKFYP5R@93Q<<'&B16Y0COCY@]4CU#:N"-V_CQ.[U,?0&@N0 MXKO;!;I7IT$JQ,1VS7?L;I!;R#4":A'5,A&T486F\`EC@.XY:=H%)/TZ:?3E M3^I2:36MGK9'>>I4]7@_^'4\T3$>!8_"".U.=+!+K:M'?C#W$$\%Q`,&XZ0> MY_MIQQ"""W)R90K<>2W(RX]*G3NO!6UIORYM&2M*;>L*>U\^'.8L><6 MQ=3NB`84-60;)]YH@=W&]U'","J*."_#292@-?9;`/;;+=\)\E:PN[V/9^G+ M\Z/+R]_#IZ].'U\>GYV&(>KE;>7P73#)-L6:=E54/S6(P@XSFM$5>P>970T- MSBZ$:2`Q\?OGN$;N?D+MR:9+P<-_*%Z4S!U"%``,Y=*.3&Z$&50JCA[$O0,- M=E85$EUDX/ROXP(?X$(/`'FW[P6AEN&+<%WP]D"HXN8L4!1N,''I@PTIM;LA@ M)"WY;=!J/I*[!FN#2]7'3%C[:!C'MFL?C?8I7?MHM+.=^$+:N?;1J,.&>CX: M?'W0]B54<`M=B<%TB3R1@@E@L@&U=KY2:+$6(E2HS33H^5&Z9@K\L M5UM#HV:*K!)Y0E%E*_9`G#$>MP:GA[#=8(^_@U-WQ-V1J,T!T-$QB`8AO8RM M,93X)6/=HXJ/QK=)'&NSB5"SK.ZU"/%XP+`^Z&FZ[80\%4YX&218T=&I'J*! MGKC&#JGR=?+&KY.3#N8^[K;K".*+4:78KM38@[")8>Y!M#LG#*0G@Q;@^Q9Z MZD-M\^+P>K[)9C&YKH2F98PD[RW:B#X_>W'TK;;14KM'EK!<]GF6(BFJ_6** MQ6@4%X6YAV9[`548\8]Y9M-7UVE`L_<%:A2.%7+Q.#PY>W9\&IX>OC@*7QS^ MB_LA&15C=W16GD@2P#[`T?3F_"$(GAE0'@9$!$=T2[H)7*\!&$*EQ)_OS00_J4/PI[>QM]W<@ M$G@K_!W,$<$$B5BRJ)?G=ZA[92]_1TINB6JV!$TXSR--O[%6//Y!G<_9XKB@ M@JUY.^[*7!@)?WR.=?JG7):"O@^.'-%)FVCRN8HW[B88C?L"#QZ&CF(?W%;/ MN?-^B_HI4G?^X*?Y'?Z[VN]2KZE5.6S?*]H!2+=-=_33E`R@C=_^[[=#HRW6 MLF(O:7K]4F7EB$U3I+>%MFF)?TP"$JRZW8Y79(V":D.1P':?*^*6G*AG+/I. M\F5%@Y&&R6\TTD#K&HYJGFX+IGH.N3GW*@ZY):J*LVX)*!HC.JBA'4SB6OG0 MV\#D!6CC"+Q9?14`;9R+MTQ0!4`;9^9_-\45`&T*345X)TL*Z\3DWKA*DA37D"V]_)4@+*\K7SZ)*$/^)S7K'M-XQK7=, MZQW3>L>TWC%])DSYF#LF96E4W!-`%VEI[+4MMFJ4NJI#;MJ(.!V'_,BN7B2L MASP2UL,:D;#&W)&!0,M(6%JZ?LRMLGA1Q'DH'2-M`&GO-DSFLEV>(P>!'K6> ML]7P;5[!>%YM"1=$/N#5VZ;PQBZ42D,\6A%0M5<]TK#Z%20-5*A(=H5-E245 M[ZKJDHVK`J0%E6F).BM!6E"YAV2ZBD/X`*6,JO*XW5/@?57AQ5?@= M45[!'D>5OD9-O8QT;S'(N\CC553/407V)@+]B$2/0,Y$BBL1Z#%D>_8LXR4$ M^P?5\@QR^@39WD!>+R"%K1YNFJ4:NOM8CCYU7'RJG7L`?QFED(.%'YR.F#YR M/JH?C!$B%Q5Q;$G8E4>.D$.MYE@CJM6N8_&O\9Y"$+5JD#6)R+^'D'"M!UM; MFXS7)N.UR7AM,EZ;C- MQZSW,>M]S)>\C^$KHQ8<4`_,L9P+#&!+=MSE=+R6HH5AX[$-Z@978U9@Y9'J MHA2&6/WIXX(\3.T(Q\9BQJF6:_P`H`GQR#ZX^B>"VI2Q%MA#S6/N>?,=>\IB M&SAO(-H"TA?*[U&/S+)QC*,O!-N]_6WTD5(;V]L[Y(==+PG?]XZU;6,@#MU( ME7L[M%)9Q=Y.G4JZ73C:'#ZN0H.@0;`)6=:(;*&U0XWPD<%,:`A]B<_80F-$QF5IB&K`#]/7=(`.P(CC]M"RG>'A/,"S@Q+"2*(9T2Z M\3QEH'.;%5@[,B:\E!=%](BK)#]HK?H%3-BT%ZWJ\3" M9&C9$["HD`B[DL?728&P\;A`;CG]J&N>+.NO-6&LWV-1-$>K'CT%E>*)I@T! M<"2`QB8X2X/`1].LB$UXG@@5(,N3"HP3(,"I!3G503_(%0X_>6L%M((EIA7Y M!X=J$$M?(-^OK12X?\F.<`%SD+Y$W!MT7<]_BW!;V$.WT)YL94W4^YN-2O[B MKQQ71N`EP5(Z+_2P2^8"ETW'XMVM>\&C7D7$3J6T*`F]X27!M-X2C[1S#6=+ M(Q9'@*I>^7B7*M&5982Q'2>[(<[#@ MM_/AJ,S&(%"S/MAR7GL[OAFGOS/%LNQO4_.IP&0J3@_DT*E885IBEG/M$2*% M#:@?V8@ZT-WCH8#-)@_P:.&1R1SQO^P=@AGLQ6P_4T/X9#&T$9[NJF&//WAHX\\*RMYD>?"1I:K55`4P)0H8@4R\6F\KTT`0?/P1[:=Z$\H_ MYV:4;42_@3>B_$-;WF^6WY'R#]J9BEUI;0KJ;ECA*&O@ZL0_W[:-[U=X)Z%) M46].6-]]35B!(W?Y#0C_7&'2ZLP;'<[]\@'^W',,?Q_`L5MO!RQ%M_.`1>.C M=Z>LK0.>K;*$$R&P=7'Y,Z M=UX;YU.?BG)W7ALG4)]CJ]QY;1PO?6DM=N>I$4"`4R./B"5Z&R\%.L.196AE MF2N1N/+:D+EU:G'GM2%S5Z7`G=>&S/V8U+GSVI"YGXIR=UX;,O=S;)4[KPV9 M^Z6UV)TG9&YO.:^SM3J^5L?7ZOA:'?^"6K56Q_]V=1RM-5OD32"@-F'A6E4$ M&XA\^2V(XD:U^?-;$,NM4N//;T%,_ZW4^O-;$-V?56O\^2V(]"^JM?[\%L3] M5\4-?[Y8#O1#CF4V#>M3A_4V9[W-66]S/A/U>+W-66]SUJ<.ZU.']:E#NY2O M3QUDWOK40%@W7Q5U86_9"&OVW`\:3D#>*&:/HG6'Z MHU$X")HG+@;QBVOT?E#E73#]RE"MVSKP'1VSQY(WOM@1*T2.L&[G.&KF(23< M==>^H>,:).P^E'X7RB8';R>,\-M4UB'!A`JZQ#!IB'WSADG#BMLU]KV:ZILR MKCLR>ECQ>GLQ;+G?IC6IR;8MJU>3(ZCT'^9#F)&-NEW337DCR++2[FN@(H8VUCIBT3EG?H'0C,Q M2AKJ_U8PRJ;3J(S':#V9S:,\%BIR1XWT0F-L=3"A'7-IZ[#EC,5C8;%:J,XR M[/S9@:]W0QL+OHR:L5UHJGD;VU30;>7*9*?!I/L!ZD7W!H>V471.#61BS/B+ M"A83KF+=*AGAIG;,O@@VHJV`,UA=K8-H""0R;JOSB/Y=]!#7-C?LC$T*W*7X M@(+]JH)70S[<<25(+^M3#07D]U:0:JRE[6,PG+]T]T[@61)30U/*;#%463(9K?+F/AP%:RBM'S,"-H7C,K8?_X+'P!#[$U7M!K[?[J#+DC#EG4F66B'!XE-IX6NK4DD8S MA5IHJ:HJ;47M8@32J&H4G[;?]2G2J@K-7A%*]*TN,+$HB0\>*%//'%7TDU?. M93V4^C@=:R^X-`_$YH2H//T8+Q6IC0Z1BNB^P((Z5J*YM?!,HTM]D-GM/<]8 MIRYO=GM/,K9`BC>[O2<8/SZEWNSVGEO\Y`WQ9K?WK.+GWDYO=GM/)W[A;/!F MJPQ7X\EB].\R6+K%;W[P=$+9#)]=8LN9Z['R"F:[9WT=+4`L^J)>'D M<\-4Q7`M6[AQ`/<$HE47+@.1+[^%I:M1;?[\%E:O5JGQY[>P@OVMU/KS6UC& M/JO6^/-;6,R^J-;Z\UM8T[XJ;OCSY;._;!71UC8JW#FX`)*KVP?5`0#V]7;M/\41$/\*P?#\GEDRS;[N!T==AB/[,DZM%&9/)>X?PHY$X3:(B MV/C6+/ZM[H^B&I.T`W\Q@-"O>%1F^7O7B7_5V#*L3Q29,NZ8EXGXO;')*D#3 M3RV[A7/Y#`&LL,Q*6)2(P3/;U86==V/X:9*^U4U$>AXV`+TK#9.0,)I]`+#1 M_`*HE5G3)MDB'?,)-(O+B/^-GSDF8PHGDK>3G5,9"B7.#8NT-'_CP(ALO=/] MBSD*]*#HXT:,VQTAA2C5=*K3T4K]2JP:51N6>>*/J"2/1]32X?&DINHY_0L( MRA^&>72'CT)NU%%*P>F1AYW1[9IV.>24'NW3<)3/YMDP`3NR99 MP?_)0)-L$/@]S6LYFG-,U>[F'+*NP96/28=')4/7AJ.YALH/T9+3>:,:JR!: M_PS;5071DH/[%]GR*HB67.&_4MY40?@MO'*A M4+8-PM`+X5Y?7EU?7EU?7K7RUI=7UY=75[R\NMY8K#<6GUQI66\LOJQVK3<6 MZXW%E[BQ\`7_Y";'59<1'8\GNX4%I$%=WNP6UHWV2/%FM[!6_&V4>K-;6!P^ MEX9XLUM8"KZ0=GJS6Y#Z7P<;O-E"NJO'2?]GPGJNMV+KK=@G5_/66[$OJUWK MK=AZ*_8E;L5\9MGU&<_ZC,=)W?J,9WW&LS[C69_QK#<6ZXW%YZ!JK3<6ZXW% M>F/Q^6PLE#,>X=ZOF!.[:MP1?A^G(O[@/P,@^*"D`X<<5,$QN6JP0`UR;X=> M,]CN=F302N!N1<7E"NUB"HGR0]O*XZ5H=YK^[*CQ,<4=%.MV"G2%@(=*,H#U MR%`$Y8.?S`L)/")*3P,F,5#4`IZ@@M=9F>&(5JB3PSC/L]Q1*VDVO4T&`*`Y MZ`YJ*SBLQ2!D]VRVU>`I]+]:V%8U7HMRI:@BFB7[]&&%[X2-<8QWYSK)S^YP_#6*UTNNJ:4S M$1AYPPI^MM\E`2I9(#34D]NNALH66\-I3T'28TC`F-'69\7?=+/#D$@'4B+Q MCX4G`H(OVW%`]>M]2F0I[9.A3<%<*H#PV$%\WD14@TVN._DP"PV472W&+)HS M8SH?Z?QQX<'2GL&BRI\46W(5 M53_U%N#&QKC+>>$L@*AT+\#RWA]ESIW7 M@C'ADU'NSFO!4/!9MLJ=U\+V_XMKL3M/;.>!1WH!N4K_I;MY]]K#-WMNS9>B MI%L_LA%TKIQL/VS$,5:_^_=E:`;[^V"EZBG.]QFX^FT%9&!6@"X8HM0?2,#> MSK:\WZ_<5%<8`TQ=I*XYP*UM--8NJL,95"H82\O^&IOA,L7ZV`+KZEM M5+Z<<)_K$=6OJ]F/J:DKN_4R6N/5G82.&S(M1K6)$X#A?N#!H%1?/`U![ON_M"/OU+]4.JIHY1].L MB#4[)V^U9N\.!:!EY)0'4XX3`ZQZHG91/C#+O*KZ_C,88"LVSE9'``Z91]O# M(Z!Y.>-O=)TF*PVN;&YE4RE'F)$<&KQVAZE:L.M!#B,DI%*D:^K[RIR0720C .#:+Q]O\!-6U&P&H/`P!E ` end From alan@linuxcare.com.au Fri, 10 Nov 2000 11:36:56 +1100 (EST) Date: Fri, 10 Nov 2000 11:36:56 +1100 (EST) From: Alan Modra alan@linuxcare.com.au Subject: abort in eliminate_regs compiling glob.c from glibc On Thu, 9 Nov 2000, John David Anglin wrote: > > Breakpoint 2, eliminate_regs_in_insn (insn=0x406a0ba0, replace=0) > > at ../../gcc/reload1.c:2826 > > 2826 if (! insn_is_asm && icode < 0) > > (gdb) p debug_rtx (insn) > > (insn/s 2711 2709 2719 (set (reg:SI 6 %r6) > > (reg:SI 28 %r28)) 69 {pre_ldw-4} (insn_list 2708 (insn_list:REG_DEP_ANTI 2696 (insn_list:REG_DEP_ANTI 2702 (insn_list:REG_DEP_ANTI 2697 (nil))))) > > (expr_list:REG_DEAD (reg:SI 28 %r28) > > (insn_list:REG_RETVAL 2708 (expr_list:REG_EQUAL (expr_list (use (mem:BLK (scratch) 0)) > > (expr_list (symbol_ref/v:SI ("@strlen")) > > (expr_list (reg/v:SI 4 %r4) > > (nil)))) > > (nil))))) > > The `use' arises from the `__pure__' attribute in the prototype for strlen: > > extern size_t strlen (__const char *__s) __attribute__ ((__pure__)); I don't see this problem using current puffin CVS hppa64-linux gcc. Was this with your REG_ELIMINATE patch? Alan Modra -- Linuxcare. Support for the Revolution. From dave@hiauly1.hia.nrc.ca Thu, 9 Nov 2000 21:50:49 -0500 (EST) Date: Thu, 9 Nov 2000 21:50:49 -0500 (EST) From: John David Anglin dave@hiauly1.hia.nrc.ca Subject: abort in eliminate_regs compiling glob.c from glibc > > > 2826 if (! insn_is_asm && icode < 0) > > > (gdb) p debug_rtx (insn) > > > (insn/s 2711 2709 2719 (set (reg:SI 6 %r6) > > > (reg:SI 28 %r28)) 69 {pre_ldw-4} (insn_list 2708 (insn_list:REG_DEP_ANTI 2696 (insn_list:REG_DEP_ANTI 2702 (insn_list:REG_DEP_ANTI 2697 (nil))))) > > > (expr_list:REG_DEAD (reg:SI 28 %r28) > > > (insn_list:REG_RETVAL 2708 (expr_list:REG_EQUAL (expr_list (use (mem:BLK (scratch) 0)) > > > (expr_list (symbol_ref/v:SI ("@strlen")) > > > (expr_list (reg/v:SI 4 %r4) > > > (nil)))) > > > (nil))))) > > > > The `use' arises from the `__pure__' attribute in the prototype for strlen: > > > > extern size_t strlen (__const char *__s) __attribute__ ((__pure__)); > > I don't see this problem using current puffin CVS hppa64-linux gcc. Was > this with your REG_ELIMINATE patch? No. Well actually I saw it first with the patch. I see this with the 32 bit compiler. The only elimination with the 32 bit compiler is the default frame pointer elimination. I just tried the hppa64-linux-gcc compiler with the source that I posted and it didn't abort. There were lots of warnings about int to pointer conversions though. Make sure you compile with -O2 or -O3? Register elimination only occurs at -O2 or above. I see the problem both with a i686-linux cross compiler and a fairly recent native hpux compiler under hpux 10.20. The problem is not present in 2.95.2 but it doesn't support the pure atribute. Dave -- J. David Anglin dave.anglin@nrc.ca National Research Council of Canada (613) 990-0752 (FAX: 952-6605) From matthew@wil.cx Fri, 10 Nov 2000 09:49:07 +0000 Date: Fri, 10 Nov 2000 09:49:07 +0000 From: Matthew Wilcox matthew@wil.cx Subject: linux bame On Thu, Nov 09, 2000 at 03:53:48PM -0700, Paul Bame wrote: > Somebody never imported 2.4.0-test6, then I imported -test10 on the main > vendor branch and now can't (easily) undo that to import test6 and THEN > test10. This workaround sucks. don't use vendor branches. didn't you talk to mang about this? -- Revolutions do not require corporate support. From matthew@wil.cx Fri, 10 Nov 2000 10:18:08 +0000 Date: Fri, 10 Nov 2000 10:18:08 +0000 From: Matthew Wilcox matthew@wil.cx Subject: [parisc-linux] tulip DMA mapping On Thu, Nov 09, 2000 at 12:12:25PM -0800, Grant Grundler wrote: > 0 is a valid pci_map_single() return value when the system has an IO MMU. Oh dear. You can bet tulip won't be the only driver which assumes it isn't a valid return value. Can't our IOMMU code be limited in such a way that 0 is not a valid return value? Say, constrain all allocated addresses to the top half of the device bus? (um, just check me on this, map_single returns a device bus address, not a processor bus address, right?) > The system will panic before pci_map_single() will fail. > The driver needs to remember some other way if a buffer was mapped or not. > Or the Documentation/DMA-mapping.txt should be changed - ie add this > to the interface definition and I can reserve the 1st mapping > entry so no-one uses it. we should probably have a BAD_DMA_ADDR define which that array should be initialised to. it's a little late in 2.4 to go through and audit all the drivers again. > Should I be mailing Jeff Garzik directly? > Or can someone who knows Jeff point this out to him? i've cc'd jeff & dave miller on this. -- Revolutions do not require corporate support. From davem@redhat.com Fri, 10 Nov 2000 02:16:11 -0800 Date: Fri, 10 Nov 2000 02:16:11 -0800 From: David S. Miller davem@redhat.com Subject: [parisc-linux] tulip DMA mapping Date: Fri, 10 Nov 2000 10:18:08 +0000 From: Matthew Wilcox > Should I be mailing Jeff Garzik directly? > Or can someone who knows Jeff point this out to him? i've cc'd jeff & dave miller on this. In 2.4.x there is _NO_ error return from the PCI dma functions except the consistent DMA mapping ones. This was an explicit design decision, the dynamic mapping functions should never fail, and if they do it is a hard error. Therefore no drivers need to check for failure, as far as they are concerned, there is no failure. So what is the issue? In 2.5.x I'll add an error return facility (BTW: -1 ie. 0xfffffff would probably work as an error value on all platforms :-) Later, David S. Miller davem@redhat.com From rhirst@linuxcare.com Fri, 10 Nov 2000 10:55:16 +0000 Date: Fri, 10 Nov 2000 10:55:16 +0000 From: Richard Hirst rhirst@linuxcare.com Subject: [parisc-linux] parisc-linux reaches uptimes in excess of one day! Just for interest... My A180 has been up for 25 hours, the first 12 of which I had a couple of telnet sessions open running vi, gcc, etc. and since then it has been looping doing kernel builds. I also ran cvs to update its kernel source tree from pehc. So far it has completed about 23 kernel builds with one hiccup: do_page_fault() pid=2420 command='cpp0' YZrvWESTHLNXBCVMcbcbcbcbOGFRQPDI PSW: 00000000000001100000000000001011 r0-3 00000000 4013ac38 400e134f 00000004 r4-7 40138c38 ffffffb5 2002014b 00000001 r8-11 00000004 00000000 00000000 4001ada0 r12-15 4001ad7c 0001b300 2001f601 00000001 r16-19 00012000 00000023 00000020 40138c38 r20-23 20020100 4012a51c 00000000 9999999a r24-27 2002016c 2002014c 00000004 00013d34 r28-31 00000000 4013a438 200201c0 40041757 sr0-4 00000000 00000011 00000000 00000011 sr4-8 00000011 00000011 00000011 00000011 IASQ: 00000011 00000011 IAOQ: 400e13b7 400e13bb IIR: 0c601094 ISR: 00000011 IOR: 00000004 ORIG_R28: 40019450 Richard From rhirst@linuxcare.com Fri, 10 Nov 2000 11:12:20 +0000 Date: Fri, 10 Nov 2000 11:12:20 +0000 From: Richard Hirst rhirst@linuxcare.com Subject: [parisc-linux] tulip DMA mapping I've quoted the whole of Grants message below, so you can see the context. It looks like tulip is treating zero as meaning it doesn't have anything to pci_unmap... Grant Grundler wrote: > Hi all, > I see a "bug" in tulip's usage of mapping services. > It's not the bug I was looking for unfortunately. > > In line 217 of drivers/net/tulip/interrupt.c: > > if (tp->tx_buffers[entry].mapping) > pci_unmap_single(tp->pdev, > tp->tx_buffers[entry].mapping, > sizeof(tp->setup_frame), > PCI_DMA_TODEVICE); > > 0 is a valid pci_map_single() return value when the system has an IO MMU. > > The system will panic before pci_map_single() will fail. > The driver needs to remember some other way if a buffer was mapped or not. > Or the Documentation/DMA-mapping.txt should be changed - ie add this > to the interface definition and I can reserve the 1st mapping > entry so no-one uses it. Richard On Fri, Nov 10, 2000 at 02:16:11AM -0800, David S. Miller wrote: > Date: Fri, 10 Nov 2000 10:18:08 +0000 > From: Matthew Wilcox > > > Should I be mailing Jeff Garzik directly? > > Or can someone who knows Jeff point this out to him? > > i've cc'd jeff & dave miller on this. > > In 2.4.x there is _NO_ error return from the PCI dma functions except > the consistent DMA mapping ones. > > This was an explicit design decision, the dynamic mapping functions > should never fail, and if they do it is a hard error. > > Therefore no drivers need to check for failure, as far as they are > concerned, there is no failure. > > So what is the issue? In 2.5.x I'll add an error return facility > (BTW: -1 ie. 0xfffffff would probably work as an error value on all > platforms :-) > > Later, > David S. Miller > davem@redhat.com > > --------------------------------------------------------------------------- > To unsubscribe: send e-mail to parisc-linux-request@thepuffingroup.com with > `unsubscribe' as the subject. > > From davem@redhat.com Fri, 10 Nov 2000 03:26:48 -0800 Date: Fri, 10 Nov 2000 03:26:48 -0800 From: David S. Miller davem@redhat.com Subject: [parisc-linux] tulip DMA mapping Date: Fri, 10 Nov 2000 11:12:20 +0000 From: Richard Hirst I've quoted the whole of Grants message below, so you can see the context. It looks like tulip is treating zero as meaning it doesn't have anything to pci_unmap... Thank you for the clarification. Jeff, this is in fact a bug, please fix :-) Later, David S. Miller davem@redhat.com From jgarzik@mandrakesoft.com Fri, 10 Nov 2000 09:30:41 -0500 Date: Fri, 10 Nov 2000 09:30:41 -0500 From: Jeff Garzik jgarzik@mandrakesoft.com Subject: [parisc-linux] tulip DMA mapping "David S. Miller" wrote: > > Date: Fri, 10 Nov 2000 11:12:20 +0000 > From: Richard Hirst > > I've quoted the whole of Grants message below, so you can see the > context. It looks like tulip is treating zero as meaning it > doesn't have anything to pci_unmap... > > Thank you for the clarification. > > Jeff, this is in fact a bug, please fix :-) np. Like Matthew(?) hinted, this is not the only place that needs fixing. I'll take care of it. Jeff -- Jeff Garzik | Building 1024 | Would you like a Twinkie? MandrakeSoft | From bame@riverrock.org Fri, 10 Nov 2000 08:57:47 -0700 Date: Fri, 10 Nov 2000 08:57:47 -0700 From: bame@riverrock.org bame@riverrock.org Subject: linux bame = On Thu, Nov 09, 2000 at 03:53:48PM -0700, Paul Bame wrote: = > Somebody never imported 2.4.0-test6, then I imported -test10 on the mai n = > vendor branch and now can't (easily) undo that to import test6 and THEN = > test10. This workaround sucks. = = don't use vendor branches. didn't you talk to mang about this? Um, I have no information to go on from your note. All the (successful) merges I've done before have used the cookbook CVS merge method including a vendor branch. Several (N-1?) of the palinux merges have been accompanied by updating the vendor branch. And this merge is going well despite the ugly workaround, or so it appears to me. Just importing files to a vendor branch should have no effect on anything else unless CVS has some horrible bug (RCS does not). Before I make what is apparently a serious mistake ("don't use vendor branches" sounds pretty serious) please enlighten me! -P From grundler@cup.hp.com Fri, 10 Nov 2000 08:29:25 -0800 Date: Fri, 10 Nov 2000 08:29:25 -0800 From: Grant Grundler grundler@cup.hp.com Subject: [parisc-linux] tulip DMA mapping Mathew, I think the situation is clarified. This is just FYI. Matthew Wilcox wrote: > On Thu, Nov 09, 2000 at 12:12:25PM -0800, Grant Grundler wrote: > > 0 is a valid pci_map_single() return value when the system has an IO MMU. > > Oh dear. You can bet tulip won't be the only driver which assumes it > isn't a valid return value. Well, then: 1) the driver writer made a wrong assumption that the "spec" does not support. 2) that wasn't the case here - 0 was used as a flag to indicate a mapping had (or hadn't rather) been done - not that the mapping call had failed. > Can't our IOMMU code be limited in such a > way that 0 is not a valid return value? Say, constrain all allocated > addresses to the top half of the device bus? It could pretty easily by reserving the dma_map[0] entry during init time. Dave Miller already made it clear that's not desirable. > (um, just check me on this, map_single returns a device bus address, > not a processor bus address, right?) Yes. It's the address a device must use to master DMA transactions. pci_map_single() input parameters are "struct pci_dev *", virtual host memory address, and buffer size. The return is a device specific I/O DMA address - ie this mapping cannot be shared with other devices. FWIW, "I/O DMA address" are called IOVAs in HPUX (I/O Virtual Address). The HW guys prefer another name but this one stuck. grant Grant Grundler Unix Systems Enablement Lab +1.408.447.7253 From bame@riverrock.org Fri, 10 Nov 2000 14:28:33 -0700 Date: Fri, 10 Nov 2000 14:28:33 -0700 From: bame@riverrock.org bame@riverrock.org Subject: [parisc-linux] kernel merge = = We're getting ready to do a kernel merge (to -test10 I think). Anybody = concerns before we get started? = I'm getting ready to commit the changes to merge us up to 2.4.0-test10 as soon as I'm confident 64-bit kernels are OK (32-bit seems fine). Here's a brief list of changes made (and yet to be made -- if anyone has the time/energy) to our parisc code (does not include changes in common code!). While there's plenty yet to do, I think we're no worse off than before the merge. Some parts of our parisc code are getting rather moldy compared to the other ports FYI. Important tags: LINUS_240_TEST6 Linus' 2.4.0-test6 LINUS_240_TEST10 Linus' 2.4.0-test10 LINUS_240_TEST10_PREMERGE Our tree before the -test10 merge LINUS_240_TEST10_MERGED Our tree after the -test10 merge ------------ Lots of 'extern __inline__' turned into 'static __inline__' and there are more to do (TODO). Beginnings of several smp_mb*() macros -- implemented as no-ops in the non-SMP case (asm/bitops.h, asm/system.h) SET_PERSONALITY() macro in asm/elf.h needs updating (TODO). fcntl.h acquired a 'struct fcntl64' used with 64-bit offsets, implementing fcntl(fd, F_S/GETLK[W]64, ...). Several other locking-related #defines added. asm/mmu_context.h:init_new_context() now returns int (always 0), not void. Should our asm/bitops.h routines be re-coded in assembly? (TODO) Added #define RLIMIT_LOCKS to asm/resource.h Added #define CLOCKS_PER_SEC to asm/param.h (how did we miss this one?) Our asm/string.h is behind the times. Fixing it might get rid of a bunch of compiler warnings! (TODO) Removed mktime from drivers/char/genrtc.c (it's in a header file now) x86 made a bunch of changes to asm-i386/floppy.h -- should we? (TODO) looks like maybe the get/put_user_ret() functions in asm/uaccess.h are obsolete? (TODO) We'll need to add the getdents64() and fcntl64() syscall glue. (TODO!!!) Our arch/parisc/config.in is in BAD SHAPE (TODO) arch/parisc/process.c: added new argsto do_fork() and copy_thread(). IA64 seems to use the copy_thread() arg. arch/parisc/signal.c: minor change to common data structure drivers/scsi sym53c8xx_comm.h #ifdef doesn't work on parisc -- eliminates unmap_pci_mem() causing link error (TODO - rhirst) From pjlahaie@linuxcare.com Fri, 10 Nov 2000 17:14:06 -0500 Date: Fri, 10 Nov 2000 17:14:06 -0500 From: Paul J.Y. Lahaie pjlahaie@linuxcare.com Subject: [parisc-linux] Beta CD --uXxzq0nDebZQVNAZ Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Hello fellow PA-RISCers, An preliminary beta CD for PA/Linux has been uploaded to puffin.external.hp.com. If people could try it and forward any complaints or suggestions to me, it would be greatly appreciated. The URL for the image is: ftp://puffin.external.hp.com/pub/parisc/cd-images/palinux-0.5.iso.gz - Paul --uXxzq0nDebZQVNAZ Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.4 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE6DHMu8ggPQthPCzcRAgb0AJ4jJs5VOnm+9aDXUbtwht7hxAa+UwCgihAo nEE25pYQwBwCDuALcSdyCNw= =bTuw -----END PGP SIGNATURE----- --uXxzq0nDebZQVNAZ-- From randolph@tausq.org Fri, 10 Nov 2000 19:18:47 -0700 Date: Fri, 10 Nov 2000 19:18:47 -0700 From: Randolph Chung randolph@tausq.org Subject: [parisc-linux] kernel merge > Our asm/string.h is behind the times. Fixing it might get rid of a > bunch of compiler warnings! (TODO) if this is just an issue of implementing the various parisc-optimized string routines, i've been working on this, but don't have everything ready yet. randolph -- @..@ http://www.TauSq.org/ (----) ( >__< ) ^^ ~~ ^^ From crypt@ihug.co.nz Sun, 12 Nov 2000 01:47:56 +1300 Date: Sun, 12 Nov 2000 01:47:56 +1300 From: crypt@ihug.co.nz crypt@ihug.co.nz Subject: [parisc-linux] HP 9000 e25 Considering how often this question comes up is there anyone out there that is interested in tracking down the info to port linux to this class of box. Server boxes may be classed as boring to some but there seem to be a large number of people who have at least one of them sitting about doing nothing. Joe. -- ======================================================================= in real life: Joseph Skinner |There's no such thing as a wizard email: crypt@ihug.co.nz |who minds his own business Analyst/Programmer | - Berengis the Black | Court Mage to the Earls Caeline ======================================================================== From snaketails@optushome.com.au Sat, 11 Nov 2000 23:57:43 +1100 Date: Sat, 11 Nov 2000 23:57:43 +1100 From: Rod Smart snaketails@optushome.com.au Subject: [parisc-linux] PA-RISC newbie Hi there. I just purchased at a **VERY** cheap price, a HP Visualize C-180 RISC system from a CAD drafting company, this box included a 4Gb Hard disk, a video card with unknown amount of memory (& daughter board, assuming its memory upgrade) and system board RAM is fully loaded (768Megs). I would like to run this system on Linux, and found the PA-RISC web site from the www.linux.org web site :o) The system currently has HP-UX installed, but not having any usernames or passwords, I cannot access the system from the prompt. I have read how to NFS-boot the HPbox from the message board, but I couldn't figgure out where to find the kernel sources (or how I would be able to compile them on the HPbox anyway). I downloaded the vmlinux kernel file from the ftp site and the NFS-ROOT and installed both on my current Linux box (Pentium 133 pre-MMX) in the format of how it was layed out in ... LINUX/PA-RISC NFSROOT HOWTO In there it states that you have to get the latest linux-2.3 tree from CVS, but which CVS server I'm curious about as the ones on ftp.kernel.org don't have "parisc" in the /arch/ branch, so where do I find the CVS "tree" that I need to use? I seem to have the "STEP 2." section running, as from playing with the system I had found my way into the PDC prompt and have played with the "boot" function. I tried to boot the installation CD (on a drive I have borrowed from work) of HP-UX and reinstall so I have access, as I don't really care whats currently on the system.. I'm not confident enough on how to create and burn a bootable CD to try and boot the box that way, I still think the vmlinux kernel I downloaded from the PA-RISC website has something to do with my problems (or the permissions) I do know that the Hp is talking to the Linux box (apart from the lack of logged info) I get a report in /var/log/secure and messages that the HP box has attempted a bootp session, but the HP box reports something along the lines that the booting code was not found. So, if anyone has any ideas on how to help me, I would be appreciated ;o) Oh, what *is* the RAM modules in the Hp systems anyway (apart from the obvious 64Mx72-pin SIMM) Thank you for your time and help :o) PS. I would prefer replies to my E-mail address as I generally forget to surf the net reading mailing lists.... From andrew@neep.com.au Sat, 11 Nov 2000 23:12:55 +0800 Date: Sat, 11 Nov 2000 23:12:55 +0800 From: Andrew Shugg andrew@neep.com.au Subject: [parisc-linux] HP 9000 e25 > Considering how often this question comes up is there anyone out there > that is interested in tracking down the info to port linux to this class > of box. > > Server boxes may be classed as boring to some but there seem to be a > large number of people who have at least one of them sitting about doing > nothing. > > Joe. I don't perceive the problem to be a lack of willingness, or interest, but has already been stated the older systems contain a lot of proprietry stuff that isn't sufficiently documented for people to work on. Maybe as the parisc port grows more popular and attracts more resources, some enthusiastic people will get it happening. =) Andrew. -- Andrew Shugg http://www.neep.com.au/ "Just remember, Mr Fawlty, there's always someone worse off than yourself." "Is there? Well I'd like to meet him. I could do with a good laugh." From grundler@cup.hp.com Sat, 11 Nov 2000 15:29:14 -0800 Date: Sat, 11 Nov 2000 15:29:14 -0800 From: Grant Grundler grundler@cup.hp.com Subject: [parisc-linux] HP 9000 e25 Andrew Shugg wrote: > > Considering how often this question comes up is there anyone out there > > that is interested in tracking down the info to port linux to this class > > of box. > > > > Server boxes may be classed as boring to some but there seem to be a > > large number of people who have at least one of them sitting about doing > > nothing. > > > > Joe. > > I don't perceive the problem to be a lack of willingness, or interest, but > has already been stated the older systems contain a lot of proprietry stuff > that isn't sufficiently documented for people to work on. AFIAK, the chipsets for I/O devices in E25 have plenty of documentation. The issue is someone has to clean them up and get a lawyer to approve their publication. It's all about IP and avoiding lawsuits. This has been discussed before. Any HP employees interested in doing this "on their own time" can contact me and I'll help locate unpublished docs. Note that PDC is the same for Nova-Class (EFGHI-class) boxes as for the workstations for the most part. So someone could start by just trying to boot those boxes and see how far it gets before dying. > Maybe as the parisc port grows more popular and attracts more resources, > some enthusiastic people will get it happening. =) Having worked on the HPUX SCSI driver (scsi3 and scsi1) for E25 and similar boxes, I question anyone's sanity who volunteers to write drivers for SPIFI chips - even with full documentation. I would rather give folks that interested in contributing a 715/33! (or my gosh /50's!) Yes - I know folks who collect PDP's and keep them running in their garage...'nuf said. grant Grant Grundler Unix Systems Enablement Lab +1.408.447.7253 From grundler@cup.hp.com Sat, 11 Nov 2000 15:38:58 -0800 Date: Sat, 11 Nov 2000 15:38:58 -0800 From: Grant Grundler grundler@cup.hp.com Subject: [parisc-linux] PA-RISC newbie Rod Smart wrote: > Hi there. > > I just purchased at a **VERY** cheap price, a HP Visualize C-180 > RISC system from a CAD drafting company, this box included a 4Gb Hard > disk, a video card with unknown amount of memory (& daughter board, > assuming its memory upgrade) and system board RAM is fully loaded > (768Megs). > > I would like to run this system on Linux, and found the PA-RISC web > site from the www.linux.org web site :o) > > The system currently has HP-UX installed, but not having any > usernames or passwords, I cannot access the system from the prompt. Yes you can. You just need to know how. Interrupt the boot process to get a "BOOT ADMIN" prompt (or whatever it's called - Boot Console Handler). Then "boot primary isl" (shortened to bo pri isl) You should have an "ISL>" prompt now. ISL> hpux -is And you will boot to single user state with a shell. mountall and you should have the regular tools too. vi /etc/passwd to your hearts content. "There is no such thing at security with out physical security". .. > I'm not confident enough on how to create and burn a bootable CD to > try and boot the box that way, I still think the vmlinux kernel I > downloaded from the PA-RISC website has something to do with my problems > (or the permissions) > You can dd the ISO image to a regular hard disk (ie /dev/sdc) and move that disk over to the C180. Then boot from that disk. From BCH, use "sea" to locate all boot devices. grant Grant Grundler Unix Systems Enablement Lab +1.408.447.7253 From randolph@tausq.org Sat, 11 Nov 2000 17:04:29 -0700 Date: Sat, 11 Nov 2000 17:04:29 -0700 From: Randolph Chung randolph@tausq.org Subject: [parisc-linux] glibc question I'm working with bdale and taggart to try to get the Debian glibc package to compile under hppa. One of the things I saw today while playing with this is that the build dies because it tries to link in bsd-setjmp.c and bsd-_setjmp.c, which both define setjmp. Can someone enlighten me about why this may be happening? This is built from the glibc-2.2 sources, which I understand has all/most of the changes in pehc cvs. randolph -- @..@ http://www.TauSq.org/ (----) ( >__< ) ^^ ~~ ^^ From rajak@purdue.edu Sat, 11 Nov 2000 22:58:57 -0500 (EST) Date: Sat, 11 Nov 2000 22:58:57 -0500 (EST) From: Brian Poole rajak@purdue.edu Subject: [parisc-linux] Problems booting new beta CD Hello, My machine is a 715/80 with 88M of RAM, 1G HD, external 4x CD drive & floppy. Trying to get the new palinux CD working on my 715/80 here and not having too much success. Did get the CD to actually boot, but after all the normal Linux init messages (which were very nice to see btw, congratulations on how far it has already gotten ;) it stops at 'Switching from PDC console'. Looking thru the FAQ I saw a somewhat similar question, in that it had 'pdc' in it & was booting from the CD (but the 0.1 CD, not the one I am using), that said the kernel on the CD booted from/to the serial console. Is this also true of the 0.5 CD? If so, what is necessary to boot one of these from console? I've been fooling with it to no success.. I have it automatically booting from the CD, but it doesn't actually boot. I replug in the monitor & keyboard and find that it can't boot without the keyboard ('Failed to initiliaze a keyboard\n SYSTEM HALTED').. How am I supposed to boot to the console if I can't boot w/o a keyboard? I imagine if it has a keyboard it will boot to the screen like a Sun. Thanks for the help, -b From grundler@cup.hp.com Sat, 11 Nov 2000 23:31:37 -0800 Date: Sat, 11 Nov 2000 23:31:37 -0800 From: Grant Grundler grundler@cup.hp.com Subject: [parisc-linux] Problems booting new beta CD Brian Poole wrote: ... > Looking thru the FAQ Brian, Thank you for first reading the FAQ! > I saw a somewhat similar question, in that it had > 'pdc' in it & was booting from the CD (but the 0.1 CD, not the one I am > using), that said the kernel on the CD booted from/to the > serial console. Is this also true of the 0.5 CD? I think it is. Is there a way via PALO to direct the console to FBCON or STICON or whatever it's called now? I had the impression *eventually* the boot console would be whatever PDC says it is - ie graphics console for the 712. > If so, what is necessary to boot one of these from console? kernel with CONFIG_STI_CONSOLE I think....but that's not enabled by default. It may not be possible to use the graphics console unless one builds a "custom" kernel. > I've been fooling with it to no > success.. I have it automatically booting from the CD, but it doesn't > actually boot. I replug in the monitor & keyboard and find that it can't > boot without the keyboard ('Failed to initiliaze a keyboard\n SYSTEM > HALTED').. How am I supposed to boot to the console if I can't boot w/o a > keyboard? I imagine if it has a keyboard it will boot to the screen like a > Sun. AFAIK, 712's are the only parisc workstations what won't boot w/o keyboard. All others will auto-switch to use serial console if the keyboard is not connected. Both or the above questions sounds like a FAQ. Could someone who knows more update/add those to the FAQ? thanks, grant ps. The most up-to-date FAQ is at parisc-linux.org/faq.html even though that's not officially online yet. > > Thanks for the help, > > -b > > > > --------------------------------------------------------------------------- > To unsubscribe: send e-mail to parisc-linux-request@thepuffingroup.com with > `unsubscribe' as the subject. > Grant Grundler Unix Systems Enablement Lab +1.408.447.7253 From alan@linuxcare.com.au Sun, 12 Nov 2000 23:08:35 +1100 (EST) Date: Sun, 12 Nov 2000 23:08:35 +1100 (EST) From: Alan Modra alan@linuxcare.com.au Subject: [parisc-linux] glibc question On Sat, 11 Nov 2000, Randolph Chung wrote: > I'm working with bdale and taggart to try to get the Debian glibc > package to compile under hppa. One of the things I saw today while > playing with this is that the build dies because it tries to link in > bsd-setjmp.c and bsd-_setjmp.c, which both define setjmp. Can someone > enlighten me about why this may be happening? I think bsd-_setjmp.c should define _setjmp, not setjmp. Alan Modra -- Linuxcare. Support for the Revolution. From andrew@neep.com.au Mon, 13 Nov 2000 00:40:15 +0800 Date: Mon, 13 Nov 2000 00:40:15 +0800 From: Andrew Shugg andrew@neep.com.au Subject: [parisc-linux] HP 9000 e25 Grant Grundler said: > AFIAK, the chipsets for I/O devices in E25 have plenty of > documentation. The issue is someone has to clean them up and get a > lawyer to approve their publication. My bad, I should've said "public documentation". =) *prods LC FAQ maintainers* Andrew. -- Andrew Shugg http://www.neep.com.au/ "Just remember, Mr Fawlty, there's always someone worse off than yourself." "Is there? Well I'd like to meet him. I could do with a good laugh." From randolph@tausq.org Sun, 12 Nov 2000 11:06:38 -0700 Date: Sun, 12 Nov 2000 11:06:38 -0700 From: Randolph Chung randolph@tausq.org Subject: [parisc-linux] glibc build fails / bash bug Bdale, taggart and I have been looking at trying to build glibc on hppa from Debian's sources. What we saw was that it looks like a lot of the syscalls were not being reocognized as such by one part of the build, so it tries to build things from the sysdeps/generic directory and fails. After a lot of digging, I *think* what is at fault is actually bash. It looks like during the build, a shell script (make-syscalls.sh) parses through syscalls.list to generate syscall stubs that are needed for the build to happen correctly, but these are not being generated. What it boils down to, I think, is this: (on hppa - bdale's J5K) ============================= tausq@j5k:/space/tausq $ bash --version GNU bash, version 2.04.0(1)-release (hppa-unknown-linux-gnu) Copyright 1999 Free Software Foundation, Inc. tausq@j5k:/space/tausq $ dpkg -l |grep bash ii bash 2.04-7 The GNU Bourne Again SHell tausq@j5k:/space/tausq $ cat test.sh #!/bin/sh echo "1 2 3 4 5 a b c d e " | while read a b c d e; do echo $a $b $c $d $e done tausq@j5k:/space/tausq $ /bin/bash test.sh 1 2 3 4 5 ============================= (on other archs, tested with i386 and sparc) samwise[11:06] ~% bash --version GNU bash, version 2.04.0(1)-release (i386-pc-linux-gnu) Copyright 1999 Free Software Foundation, Inc. samwise[11:06] ~% dpkg -l |grep bash ii bash 2.04-7 The GNU Bourne Again SHell samwise[11:06] ~% /bin/bash test.sh 1 2 3 4 5 a b c d e This causes the parsing routines to die quite miserably.... Anyone feel like trying to fix this? :-) randolph -- @..@ http://www.TauSq.org/ (----) ( >__< ) ^^ ~~ ^^ From pdbeal@louisville.edu Sun, 12 Nov 2000 14:27:28 -0500 Date: Sun, 12 Nov 2000 14:27:28 -0500 From: Phillip D. Beal pdbeal@louisville.edu Subject: [parisc-linux] Beta CD On Fri, Nov 10, 2000 at 05:14:06PM -0500, Paul J.Y. Lahaie wrote: > Hello fellow PA-RISCers, > > An preliminary beta CD for PA/Linux has been uploaded to > puffin.external.hp.com. If people could try it and forward any complaints > or suggestions to me, it would be greatly appreciated. The URL for the > image is: ftp://puffin.external.hp.com/pub/parisc/cd-images/palinux-0.5.iso.gz > > - Paul The kernel dumps on an HP755. Actually, how do you make these CD's? I know how to use mkisofs to crerat a filesystem CD, but how you make it bootable with a kernel image? Thanks, -- Phillip Beal Electrical and Computer Engineering S+LUG Vice-President From bame@riverrock.org Sun, 12 Nov 2000 13:27:32 -0700 Date: Sun, 12 Nov 2000 13:27:32 -0700 From: bame@riverrock.org bame@riverrock.org Subject: [parisc-linux] glibc build fails / bash bug = After a lot of digging, I *think* what is at fault is actually bash. Bash has a bunch of 'set' options, some shell variables, and probably some compile-time configure options, which affect its behavior, so I'd compare all those. One possibility is that the bash configure script on hppa configures bash to be more like Posix, since that's what hp-ux shell users expect. The construct in question: echo "a b c 1 2 3" | while read x1 x2 x3 *depends* on the way echo breaks or doesn't break lines, and the way read parses them. Often scripts like that also depend on whether the shell actually makes a new subprocess for the 'while' or it doesn't, because that determines whether variables set in the loop will still be set on exit from the loop. While I didn't find a way to make the construction fail, a safer method (when you get a choice) is to use 'set': set -- a b c \ 1 2 3 while [ $# != 0 ] do echo $1 $2 $3 shift 3 done -Paul "too much shell programming" Bame From bame@riverrock.org Sun, 12 Nov 2000 17:25:45 -0700 Date: Sun, 12 Nov 2000 17:25:45 -0700 From: bame@riverrock.org bame@riverrock.org Subject: [parisc-linux] kernel merge Helge noticed SCSI fails (B160L, 712, I think it's ok on c3k) after the -test10 merge. We have MANY differences from Linus in the SCSI area. Anybody want to take a look at this? FYI to get the pre-merge kernel you can use LINUS_240_TEST10_PREMERGE. Beware that tags are sticky in CVS (use cvs update -A to fix that). -P From catfish@alltel.net Sun, 12 Nov 2000 19:05:21 -0600 Date: Sun, 12 Nov 2000 19:05:21 -0600 From: catfish@alltel.net catfish@alltel.net Subject: [parisc-linux] Project Dead???? Hello, Its been so long since I've had an email I was curious if this has become a Dead project? Just curious. Terry -- catfish: icq #20116127 From bame@riverrock.org Sun, 12 Nov 2000 18:15:07 -0700 Date: Sun, 12 Nov 2000 18:15:07 -0700 From: bame@riverrock.org bame@riverrock.org Subject: [parisc-linux] Project Dead???? = Hello, = Its been so long since I've had an email I was curious if this has = become a Dead project? You might want to check the e-mail archives to see what you've been missing. I don't know why you haven't been receiving anything. The project is quite alive. http://www.parisc-linux.org/lists.html -P From bame@riverrock.org Sun, 12 Nov 2000 19:20:50 -0700 Date: Sun, 12 Nov 2000 19:20:50 -0700 From: bame@riverrock.org bame@riverrock.org Subject: [parisc-linux] kernel merge = = Helge noticed SCSI fails (B160L, 712, I think it's ok on c3k) = after the -test10 merge. Fixed. From test6 to test10 the SCSI host registration method changed. Updated sim700.c, lasi7xx.h, zalon7xx.h -P From grundler@cup.hp.com Sun, 12 Nov 2000 21:34:08 -0800 Date: Sun, 12 Nov 2000 21:34:08 -0800 From: Grant Grundler grundler@cup.hp.com Subject: [parisc-linux] Problems booting new beta CD Brian Poole wrote: > Quoting Grant Grundler (grundler@cup.hp.com) from 11 November 2000: > > Is there a way via PALO to direct the console to FBCON or STICON or > > whatever it's called now? > > > > I had the impression *eventually* the boot console would be whatever PDC > > says it is - ie graphics console for the 712. > > Working on a 715 here.. notice you refer to 712s throughout, hopefully we are > on the same page. Maybe 712s are identical to 715s, I don't have any idea, > just noticed the irregularity. For the most part yes. I had just assumed you were using a 712. > I meant to say 'from serial console' or something of the sort.. Serial console should just work. Shouldn't need an HIL keyboard connected though. > > > > I've been fooling with it to no > > > success.. I have it automatically booting from the CD, but it doesn't > > > actually boot. I replug in the monitor & keyboard and find that it can't > > > boot without the keyboard ('Failed to initiliaze a keyboard\n SYSTEM > > > HALTED').. How am I supposed to boot to the console if I can't boot w/o a > > > keyboard? I imagine if it has a keyboard it will boot to the screen like > a > > > Sun. > > > > AFAIK, 712's are the only parisc workstations what won't boot w/o keyboard. > > All others will auto-switch to use serial console if the keyboard > > is not connected > > Hmmm.. so I have manually switch it to use serial console? No. Just disconnect the keyboard before powering on the machine. Should end up with console on the serial interface. You may want to set the keyboard/console path to the serial port. This can be done from "BOOT_ADMIN>" prompt. The default kernel has "CONFIG_HIL=y". But since I don't test on boxes with HIL interfaces, I have no idea if a keyboard is required since the driver is enabled. It sounds like a bug if the 715 can't boot from serial console w/o HIL keyboard. grant Grant Grundler Unix Systems Enablement Lab +1.408.447.7253 From dhazeghi@pacbell.net Sun, 12 Nov 2000 21:34:19 -0800 Date: Sun, 12 Nov 2000 21:34:19 -0800 From: dhazeghi@pacbell.net dhazeghi@pacbell.net Subject: [parisc-linux] [Semi OT] SOM Linker Hello, I have been watching this project for some time and wanted to thank you guys for all the great work so far. The recent announcement of a BETA CD is highly encouraging. However I would like to know what work if any has been done on the SOM linker which HP released to the public last November(?). It seems that as of right now, it has not been touched since February 14, and the FSF binutils snapshots still do not have any SOM support for ld. Has there been any movement in merging this in, or is anybody working on this? Thanks. Dara Hazeghi From deller@gmx.de Mon, 13 Nov 2000 08:32:54 +0100 Date: Mon, 13 Nov 2000 08:32:54 +0100 From: Helge Deller deller@gmx.de Subject: [parisc-linux] kernel merge On Monday 13 November 2000 03:20, bame@riverrock.org wrote: > = > = Helge noticed SCSI fails (B160L, 712, I think it's ok on c3k) > = after the -test10 merge. > > Fixed. > > >From test6 to test10 the SCSI host registration method changed. > Updated sim700.c, lasi7xx.h, zalon7xx.h > > -P Thanks Paul, sim700 (53c710) now works again, but the second built-in controller (ncr/sym 53c8xx) still doesn't. Greetings, Helge From rhirst@linuxcare.com Mon, 13 Nov 2000 10:24:03 +0000 Date: Mon, 13 Nov 2000 10:24:03 +0000 From: Richard Hirst rhirst@linuxcare.com Subject: [parisc-linux] BEWARE: Makefile changed from parisc to parisc64 Confused me for a while, anyway. If you cvs update your kernel source and expect to build a 32 bit kernel, you need to edit the top level Makefile to change the arch := line. Richard From rhirst@linuxcare.com Mon, 13 Nov 2000 12:13:49 +0000 Date: Mon, 13 Nov 2000 12:13:49 +0000 From: Richard Hirst rhirst@linuxcare.com Subject: [parisc-linux] kernel merge On Fri, Nov 10, 2000 at 02:28:33PM -0700, bame@riverrock.org wrote: > drivers/scsi sym53c8xx_comm.h #ifdef doesn't work on parisc -- eliminates > unmap_pci_mem() causing link error (TODO - rhirst) Fixed. This relates to NVRAM that some PCI scsi cards have to hold config settings over reboot. CONFIG_SCSI_NCR53C8XX_NVRAM_DETECT is normally defined in sym53c8xx_defs.h to turn that code on. When I implemented Zalon (FWD) support I guessed that the 53c720 h/w wouldn't have NVRAM implemented the same way, and turned off NVRAM detect. I've also replaced a chunk of Zalon specific code that got lost in the merge, so Zalon/FWD/53c720 support works again. There is a problem remaining when using the driver as a module; it looks like something is trying to printk() from a string in the module after the module has been removed. Havn't tracked that down yet. Richard From adevries@linuxcare.com Mon, 13 Nov 2000 13:50:24 -0500 Date: Mon, 13 Nov 2000 13:50:24 -0500 From: Alex deVries adevries@linuxcare.com Subject: [parisc-linux] [Semi OT] SOM Linker dhazeghi@pacbell.net wrote: > However I would like to know what work if any has been done on the SOM > linker which HP released to the public last November(?). It seems that > as of right now, it has not been touched since February 14, and the FSF > binutils snapshots still do not have any SOM support for ld. Has there > been any movement in merging this in, or is anybody working on this? The initial plan was to do our 32-bit userspace with SOM, worrying about ELF32 much later in the game. But ELF32 development happened a lot quicker than expected, and so nobody's really done much on the SOM linker. I suspect it'd be very hard to use the SOM linker code to incorporate it into binutils, but I could be wrong. What are you actually trying to do? - Alex -- Alex deVries, Principal Solutions Architect, The Puffins at Linuxcare 613.562.2759 tel alex@linuxcare.com, http://www.linuxcare.com/ Linuxcare, Support for the revolution. From deller@gmx.de Mon, 13 Nov 2000 23:54:29 +0100 Date: Mon, 13 Nov 2000 23:54:29 +0100 From: Helge Deller deller@gmx.de Subject: sym53c8xx-driver (was: Re: [parisc-linux] kernel merge) On Monday 13 November 2000 13:13, Richard Hirst wrote: > On Fri, Nov 10, 2000 at 02:28:33PM -0700, bame@riverrock.org wrote: > > drivers/scsi sym53c8xx_comm.h #ifdef doesn't work on parisc -- eliminates > > unmap_pci_mem() causing link error (TODO - rhirst) > > Fixed. This relates to NVRAM that some PCI scsi cards have to hold > config settings over reboot. CONFIG_SCSI_NCR53C8XX_NVRAM_DETECT > is normally defined in sym53c8xx_defs.h to turn that code on. When > I implemented Zalon (FWD) support I guessed that the 53c720 h/w > wouldn't have NVRAM implemented the same way, and turned off > NVRAM detect. > > I've also replaced a chunk of Zalon specific code that got lost in > the merge, so Zalon/FWD/53c720 support works again. > > There is a problem remaining when using the driver as a module; > it looks like something is trying to printk() from a string in > the module after the module has been removed. Havn't tracked > that down yet. > > Richard Hi Richard, I'm sorry to say that the sym53c8xx still doesn't work on my B160L (32 bit-Kernel). It looks like the controller isn't detected at all, while it worked perfectly with 2.4.0-test6. Would you mind to take a look at the code again ? Thanks, Helge. From rhirst@linuxcare.com Mon, 13 Nov 2000 23:27:52 +0000 Date: Mon, 13 Nov 2000 23:27:52 +0000 From: Richard Hirst rhirst@linuxcare.com Subject: sym53c8xx-driver (was: Re: [parisc-linux] kernel merge) Hi Helge, The problem I fixed related to the ncr53c8xx driver (which shares code with sym53c8xx), and was to make 53c720 support work again. sym53c8xx worked for me on my A180. Please can you try booting with sym53c8xx=verb:7,debug:0xffff and send me the output? Thanks, Richard On Mon, Nov 13, 2000 at 11:54:29PM +0100, Helge Deller wrote: > On Monday 13 November 2000 13:13, Richard Hirst wrote: > > On Fri, Nov 10, 2000 at 02:28:33PM -0700, bame@riverrock.org wrote: > > > drivers/scsi sym53c8xx_comm.h #ifdef doesn't work on parisc -- eliminates > > > unmap_pci_mem() causing link error (TODO - rhirst) > > > > Fixed. This relates to NVRAM that some PCI scsi cards have to hold > > config settings over reboot. CONFIG_SCSI_NCR53C8XX_NVRAM_DETECT > > is normally defined in sym53c8xx_defs.h to turn that code on. When > > I implemented Zalon (FWD) support I guessed that the 53c720 h/w > > wouldn't have NVRAM implemented the same way, and turned off > > NVRAM detect. > > > > I've also replaced a chunk of Zalon specific code that got lost in > > the merge, so Zalon/FWD/53c720 support works again. > > > > There is a problem remaining when using the driver as a module; > > it looks like something is trying to printk() from a string in > > the module after the module has been removed. Havn't tracked > > that down yet. > > > > Richard > > > Hi Richard, > > I'm sorry to say that the sym53c8xx still doesn't work on my B160L (32 > bit-Kernel). It looks like the controller isn't detected at all, while it > worked perfectly with 2.4.0-test6. > Would you mind to take a look at the code again ? > > Thanks, > Helge. > From deller@gmx.de Tue, 14 Nov 2000 01:13:58 +0100 Date: Tue, 14 Nov 2000 01:13:58 +0100 From: Helge Deller deller@gmx.de Subject: sym53c8xx-driver (was: Re: [parisc-linux] kernel merge) --------------Boundary-00=_ABNZX5KGKOOFAA0B1BIM Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 8bit Subject: On Tuesday 14 November 2000 00:27, Richard Hirst wrote: > Hi Helge, > The problem I fixed related to the ncr53c8xx driver (which shares > code with sym53c8xx), and was to make 53c720 support work again. > sym53c8xx worked for me on my A180. Please can you try booting > with > > sym53c8xx=verb:7,debug:0xffff > > and send me the output? > > Thanks, > Richard Hi Richard, the output and the relevant part of .config is attached. Greetings, Helge --------------Boundary-00=_ABNZX5KGKOOFAA0B1BIM Content-Type: text/plain; name="log1" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="log1" Ci5jb25maWc6IAotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tCiMKIyBT Q1NJIHN1cHBvcnQKIwpDT05GSUdfU0NTST15CkNPTkZJR19CTEtfREVWX1NEPXkKQ09ORklHX1NE X0VYVFJBX0RFVlM9NDAKIyBDT05GSUdfQ0hSX0RFVl9TVCBpcyBub3Qgc2V0CkNPTkZJR19CTEtf REVWX1NSPXkKQ09ORklHX0JMS19ERVZfU1JfVkVORE9SPXkKQ09ORklHX1NSX0VYVFJBX0RFVlM9 MgpDT05GSUdfQ0hSX0RFVl9TRz15CkNPTkZJR19TQ1NJX01VTFRJX0xVTj15CkNPTkZJR19TQ1NJ X0NPTlNUQU5UUz15CgojCiMgU0NTSSBsb3ctbGV2ZWwgZHJpdmVycwojCkNPTkZJR19TQ1NJX0xB U0k9eQpDT05GSUdfU0NTSV9aQUxPTj15CkNPTkZJR19TQ1NJX1NZTTUzQzhYWD15CkNPTkZJR19T Q1NJX05DUjUzQzhYWF9ERUZBVUxUX1RBR1M9OApDT05GSUdfU0NTSV9OQ1I1M0M4WFhfTUFYX1RB R1M9MzIKQ09ORklHX1NDU0lfTkNSNTNDOFhYX1NZTkM9MjAKIyBDT05GSUdfU0NTSV9OQ1I1M0M4 WFhfUFJPRklMRSBpcyBub3Qgc2V0CiMgQ09ORklHX1NDU0lfTkNSNTNDOFhYX0lPTUFQUEVEIGlz IG5vdCBzZXQKCgotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0KCmJvb3QtbG9nOgotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tCgpGaXJtd2FyZSBWZXJzaW9uICA2LjEKCkR1cGxleCBDb25zb2xlIElPIERlcGVuZGVu dCBDb2RlIChJT0RDKSByZXZpc2lvbiAxCgpNZW1vcnkgVGVzdC9Jbml0aWFsaXphdGlvbiBDb21w bGV0ZWQgCgotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0KICAgKGMpIENvcHlyaWdodCAxOTk1LTE5OTgs IEhld2xldHQtUGFja2FyZCBDb21wYW55LCBBbGwgcmlnaHRzIHJlc2VydmVkCi0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLQoKICBQcm9jZXNzb3IgICBTcGVlZCAgICAgICAgICAgIFN0YXRlICAgICAgICAg ICBDb3Byb2Nlc3NvciBTdGF0ZSAgQ2FjaGUgU2l6ZQogIC0tLS0tLS0tLSAgLS0tLS0tLS0gICAt LS0tLS0tLS0tLS0tLS0tLS0tLS0gIC0tLS0tLS0tLS0tLS0tLS0tICAtLS0tLS0tLS0tCiAgICAg IDAgICAgICAxNjAgTUh6ICAgIEFjdGl2ZSAgICAgICAgICAgICAgICAgRnVuY3Rpb25hbCAgICAg ICAgICA2NCBLQgogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgIDEgTUIgZXh0CgoKICBBdmFpbGFibGUgbWVtb3J5IChieXRl cykgICAgOiAgNTM2ODcwOTEyIAogIEdvb2QgbWVtb3J5IHJlcXVpcmVkIChieXRlcyk6ICA1MzY4 NzA5MTIgCgogIFByaW1hcnkgYm9vdCBwYXRoOiAgICBGV1NDU0kuNi4wCiAgQWx0ZXJuYXRlIGJv b3QgcGF0aDogIExBTi4wLjAuMC4wLjAuMAogIENvbnNvbGUgcGF0aDogICAgICAgICBHUkFQSElD UygyKQogIEtleWJvYXJkIHBhdGg6ICAgICAgICBQUzIKCkNQVSAwCldBUk5JTkc6ICBTZWxmIHRl c3RzIGhhdmUgYmVlbiBkaXNhYmxlZCBhcyBhIHJlc3VsdCBvZiBGQVNUQk9PVAogICAgICAgICAg YmVpbmcgZW5hYmxlZC4gIFRvIGVuYWJsZSBzZWxmIHRlc3RzLCB1c2UgdGhlIEZBU1RCT09UCiAg ICAgICAgICBjb21tYW5kIGluIHRoZSBDT05GSUdVUkFUSU9OIG1lbnUgYW5kIHJlYm9vdCB0aGUg c3lzdGVtLgoKCi0tLS0tLS0gTWFpbiBNZW51IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0KCiAgICAgICAgQ29tbWFuZCAgICAgICAg ICAgICAgICAgICAgICAgICBEZXNjcmlwdGlvbgogICAgICAgIC0tLS0tLS0gICAgICAgICAgICAg ICAgICAgICAgICAgLS0tLS0tLS0tLS0KICAgICAgICBCT290IFtQUkl8QUxUfDxwYXRoPl0gICAg ICAgICAgIEJvb3QgZnJvbSBzcGVjaWZpZWQgcGF0aAogICAgICAgIFBBdGggW1BSSXxBTFR8Q09O fEtFWV0gWzxwYXRoPl0gRGlzcGxheSBvciBtb2RpZnkgYSBwYXRoCiAgICAgICAgU0VBcmNoIFtE SXNwbGF5fElQTF0gWzxwYXRoPl0gICBTZWFyY2ggZm9yIGJvb3QgZGV2aWNlcwoKICAgICAgICBD T25maWd1cmF0aW9uIFs8Y29tbWFuZD5dICAgICAgIEFjY2VzcyBDb25maWd1cmF0aW9uIG1lbnUv Y29tbWFuZHMKICAgICAgICBJTmZvcm1hdGlvbiBbPGNvbW1hbmQ+XSAgICAgICAgIEFjY2VzcyBJ bmZvcm1hdGlvbiBtZW51L2NvbW1hbmRzCiAgICAgICAgU0VSdmljZSBbPGNvbW1hbmQ+XSAgICAg ICAgICAgICBBY2Nlc3MgU2VydmljZSBtZW51L2NvbW1hbmRzCgogICAgICAgIERJc3BsYXkgICAg ICAgICAgICAgICAgICAgICAgICAgUmVkaXNwbGF5IHRoZSBjdXJyZW50IG1lbnUKICAgICAgICBI RWxwIFs8bWVudT58PGNvbW1hbmQ+XSAgICAgICAgIERpc3BsYXkgaGVscCBmb3IgbWVudSBvciBj b21tYW5kCiAgICAgICAgUkVTRVQgICAgICAgICAgICAgICAgICAgICAgICAgICBSZXN0YXJ0IHRo ZSBzeXN0ZW0KLS0tLS0tLQpNYWluIE1lbnU6IEVudGVyIGNvbW1hbmQgPiBibyBsYW4KSW50ZXJh Y3Qgd2l0aCBJUEwgKFksIE4sIFEpPz4gbgoKQm9vdGluZy4uLiAKTmV0d29yayBTdGF0aW9uIEFk ZHJlc3MgMDgwMDA5LWVmMzRmNQpTeXN0ZW0gSVAgQWRkcmVzcyAxOTIuMTY4LjEwMC4xNjAKU2Vy dmVyIElQIEFkZHJlc3MgMTkyLjE2OC4xMDAuMTAwCgpCb290IElPIERlcGVuZGVudCBDb2RlIChJ T0RDKSByZXZpc2lvbiAyCgoKSEFSRCBCb290ZWQuCnBhbG8gaXBsIHJvb3RAUDEwMCBUaHUgTm92 ICAyIDIwOjE0OjA4IE1FVCAyMDAwCjAvdm1saW51eCAyMjc0NzcxIGJ5dGVzIEAgMHg2ODAwCjAv cGFsby1jbWRsaW5lICcwL3ZtbGludXggSE9NRT0vIFRFUk09TElOVVggcm9vdD0vZGV2L25mcyBu ZnNyb290PTE5Mi4xNjguMTAwLjEwMDovdGZ0cGJvb3QvbmZzcm9vdCBjb25zb2xlPXR0eSBzeW01 M2M4eHg9dmVyYjo3LGRlYnVnOjB4ZmZmZicKS2VybmVsOiBwYXJ0aXRpb24gMCBmaWxlIC92bWxp bnV4CkVMRjMyIGV4ZWN1dGFibGUKCkVudHJ5IDAwMTAwMTkwIGZpcnN0IDAwMTAwMDAwIG4gNApT ZWdtZW50IDAgbG9hZCAwMDEwMDAwMCBzaXplIDE1MzQ2NjggbWVkaWFwdHIgMHgxMDAwClNlZ21l bnQgMSBsb2FkIDAwMjc4MDAwIHNpemUgMTgyMzQ0IG1lZGlhcHRyIDB4MTc4MDAwClNlZ21lbnQg MiBsb2FkIDAwMmE4MDAwIHNpemUgMTM5MTMyIG1lZGlhcHRyIDB4MWE1MDAwClNlZ21lbnQgMyBs b2FkIDAwMmNjMDAwIHNpemUgODE5MiBtZWRpYXB0ciAweDFjNzAwMApicmFuY2hpbmcgdG8ga2Vy bmVsIGVudHJ5IHBvaW50IDB4MDAxMDAxOTAKU2V0IGRlZmF1bHQgUFNXIFcgYml0IHRvIDAKUERD IENvbnNvbGUgSW5pdGlhbGl6ZWQKVGhlIDMyLWJpdCBLZXJuZWwgaGFzIHN0YXJ0ZWQuLi4KRW5h YmxlZCBGUCBjb3Byb2Nlc3NvcgpGcmVlIG1lbW9yeSBzdGFydHMgYXQ6IDB4YzAyZmQwMDAKc3Rh cnRfcGFyaXNjKDB4NTA0ZDZjLDB4NTA0ZDZjLDB4MCwweDApClBBTE8gY29tbWFuZCBsaW5lOiAn SE9NRT0vIFRFUk09TElOVVggcm9vdD0vZGV2L25mcyBuZnNyb290PTE5Mi4xNjguMTAwLjEwMDov dGZ0cGJvb3QvbmZzcm9vdCBjb25zb2xlPXR0eSBzeW01M2M4eHg9dmVyYjo3LGRlYnVnOjB4ZmZm ZicKUEFMTyBpbml0cmQgMC0wCm1vZGVsICAgMDAwMDUwMjAgMDAwMDA0ODEgMDAwMDAwMDAgMDIw MjAyMDIgNzc5NGQ3ZmUgMTAwMDAwZjAgMDAwMDAwMDQgMDAwMDAwYmEgMDAwMDAwYmEKdmVycyAg ICAwMDAwMDAwOApjcHVpZCAgIDAwMDAwMWU4CkNQVUlEIHZlcnMgMTUgcmV2IDgKU2VhcmNoaW5n IGZvciBkZXZpY2VzIGluIFBEQyBmaXJtd2FyZS4uLiBwcm9jZXNzb3IgaHBhIDB4ZmZmYmUwMDAK YSBuZXdlciBib3guLi4KRm91bmQgZGV2aWNlczoKMS4gUGhhbnRvbSBQc2V1ZG9CQyBHU0MrIFBv cnQgKDcpIGF0IDB4ZmZjMDAwMDAsIHZlcnNpb25zIDB4NTA0LCAweDAsIDB4MCwgMHgwLCAweDAK Mi4gTWVybGluIDE2MCBDb3JlIEZXLVNDU0kgKDQpIGF0IDB4ZmZmOGMwMDAsIHZlcnNpb25zIDB4 M2QsIDB4MCwgMHg4OSwgMHgwLCAweDgwCjMuIE1lcmxpbiBMMiAxNjAgKDkwMDAvNzc4L0IxNjBM KSAoMCkgYXQgMHhmZmZiZTAwMCwgdmVyc2lvbnMgMHg1MDIsIDB4MCwgMHg0LCAweDAsIDB4ODEK NC4gTWVybGluIDE2MC9UaHVuZGVySGF3ayBNZW1vcnkgKDEpIGF0IDB4ZmZmYmYwMDAsIHZlcnNp b25zIDB4NjcsIDB4MCwgMHg5LCAweDAsIDB4MAo1LiBNZXJsaW4gMTYwIENvcmUgQkEgKDExKSBh dCAweGZmZDAwMDAwLCB2ZXJzaW9ucyAweDNkLCAweDAsIDB4ODEsIDB4MCwgMHgwCjYuIE1lcmxp biAxNjAgQ29yZSBSUy0yMzIgKDEwKSBhdCAweGZmZDA1MDAwLCB2ZXJzaW9ucyAweDNkLCAweDAs IDB4OGMsIDB4MCwgMHgwCjcuIE1lcmxpbiAxNjAgQ29yZSBTQ1NJICgxMCkgYXQgMHhmZmQwNjAw MCwgdmVyc2lvbnMgMHgzZCwgMHgwLCAweDgyLCAweDAsIDB4MAo4LiBNZXJsaW4gMTYwIENvcmUg TGFuICg4MDIuMykgKDEwKSBhdCAweGZmZDA3MDAwLCB2ZXJzaW9ucyAweDNkLCAweDAsIDB4OGEs IDB4MCwgMHgwCjkuIE1lcmxpbiAxNjAgQ29yZSBDZW50cm9uaWNzICgxMCkgYXQgMHhmZmQwMjAw MCwgdmVyc2lvbnMgMHgzZCwgMHgwLCAweDc0LCAweDAsIDB4MAoxMC4gTWVybGluIDE2MCBDb3Jl IEF1ZGlvICgxMCkgYXQgMHhmZmQwNDAwMCwgdmVyc2lvbnMgMHgzZCwgMHg0LCAweDdiLCAweDAs IDB4MAoxMS4gTWVybGluIDE2MCBDb3JlIFBDIEtleWJvYXJkICgxMCkgYXQgMHhmZmQwODAwMCwg dmVyc2lvbnMgMHgzZCwgMHgwLCAweDg0LCAweDAsIDB4MAoxMi4gTWVybGluIDE2MCBDb3JlIFBD IEtleWJvYXJkICgxMCkgYXQgMHhmZmQwODEwMCwgdmVyc2lvbnMgMHgzZCwgMHgwLCAweDg0LCAw eDAsIDB4MAoxMy4gTWVybGluIDE2MCBXYXggQkEgKDExKSBhdCAweGZmZTAwMDAwLCB2ZXJzaW9u cyAweDQxLCAweDAsIDB4OGUsIDB4MCwgMHgwCjE0LiBNZXJsaW4gMTYwIFdheCBFSVNBIEJBICgx MSkgYXQgMHhmYzAwMDAwMCwgdmVyc2lvbnMgMHg0MSwgMHgwLCAweDkwLCAweDAsIDB4MAoxNS4g TWVybGluIDE2MCBXYXggSElMICgxMCkgYXQgMHhmZmUwMTAwMCwgdmVyc2lvbnMgMHg0MSwgMHgw LCAweDczLCAweDAsIDB4MAoxNi4gTWVybGluIDE2MCBXYXggUlMtMjMyICgxMCkgYXQgMHhmZmUw MjAwMCwgdmVyc2lvbnMgMHg0MSwgMHgwLCAweDhjLCAweDAsIDB4MAoxNy4gQ29yYWwgU0dDIEdy YXBoaWNzICgxMCkgYXQgMHhmNDAwMDAwMCwgdmVyc2lvbnMgMHg0LCAweDAsIDB4NzcsIDB4MCwg MHgwCjE4LiBHZWNrbyBHU0MgQ29yZSBHcmFwaGljcyAoMTApIGF0IDB4ZjgwMDAwMDAsIHZlcnNp b25zIDB4MTYsIDB4MCwgMHg4NSwgMHgwLCAweDAKMTkuIERpbm8gUENJIEJyaWRnZSAoMTMpIGF0 IDB4ZmZmODAwMDAsIHZlcnNpb25zIDB4NjgwLCAweDAsIDB4YSwgMHgwLCAweDAKVGhhdCdzIGEg dG90YWwgb2YgMTkgZGV2aWNlcy4KQ1BVKHMpOiAxIHggUEE3MzAwTEMgKFBDWC1MMikgYXQgMTYw LjAwMDAwMCBNSHoKTGludXggdmVyc2lvbiAyLjQuMC10ZXN0MTAgKHJvb3RAUDEwMCkgKGdjYyB2 ZXJzaW9uIDIuOTYgMjAwMDA5MjUgKGV4cGVyaW1lbnRhbCkpICMxNSBUdWUgTm92IDE0IDAxOjAx OjMzIE1FVCAyMDAwCmZyZWVfYm9vdG1lbSgweDMwMTAwMCwgMHgxZmNmZjAwMCkKaW5pdHJkOiAw MDAwMDAwMC0wMDAwMDAwMApwYWdldGFibGVfaW5pdApPbiBub2RlIDAgdG90YWxwYWdlczogMTMx MDcyCnpvbmUoMCk6IDY1NTM2IHBhZ2VzLgp6b25lKDEpOiA2NTUzNiBwYWdlcy4Kem9uZSgyKTog MCBwYWdlcy4KS2VybmVsIGNvbW1hbmQgbGluZTogSE9NRT0vIFRFUk09TElOVVggcm9vdD0vZGV2 L25mcyBuZnNyb290PTE5Mi4xNjguMTAwLjEwMDovdGZ0cGJvb3QvbmZzcm9vdCBjb25zb2xlPXR0 eSBzeW01M2M4eHg9dmVyYjo3LGRlYnVnOjB4ZmZmZgp0cmFwX2luaXQKQ29uc29sZTogY29sb3Vy IGR1bW15IGRldmljZSA4MHgyNQpyZWdpc3Rlcl9jb25zb2xlCkNhbGlicmF0aW5nIGRlbGF5IGxv b3AuLi4gMTA2LjUwIEJvZ29NSVBTCk1lbW9yeTogNTEwOTQ0ayBhdmFpbGFibGUKRGVudHJ5LWNh Y2hlIGhhc2ggdGFibGUgZW50cmllczogNjU1MzYgKG9yZGVyOiA3LCA1MjQyODggYnl0ZXMpCkJ1 ZmZlci1jYWNoZSBoYXNoIHRhYmxlIGVudHJpZXM6IDMyNzY4IChvcmRlcjogNSwgMTMxMDcyIGJ5 dGVzKQpQYWdlLWNhY2hlIGhhc2ggdGFibGUgZW50cmllczogMTMxMDcyIChvcmRlcjogNywgNTI0 Mjg4IGJ5dGVzKQpJbm9kZS1jYWNoZSBoYXNoIHRhYmxlIGVudHJpZXM6IDMyNzY4IChvcmRlcjog NiwgMjYyMTQ0IGJ5dGVzKQpQT1NJWCBjb25mb3JtYW5jZSB0ZXN0aW5nIGJ5IFVOSUZJWApMYXNp IHZlcnNpb24gMCBhdCAweGZmZDAwMDAwIGZvdW5kLgpXYXggYXQgMHhmZmUwMDAwMCBmb3VuZC4K V2F4OiBISUwgS2V5Ym9hcmQtTk1JIHJlZ2lzdGVyZWQuCnBhcnBvcnQwOiBQQy1zdHlsZSBhdCAw eGZmZDAyODAwLCBpcnEgODggW1BDU1BQLFRSSVNUQVRFXQpGb3VuZCBpODI1OTYgYXQgMHhmZmQw NzAwMCwgSVJRIDg3CmVhcmx5IGluaXRpYWxpemF0aW9uIG9mIGRldmljZSBldGgwIGlzIGRlZmVy cmVkCkluaXRpYWxpemluZyBMYXNpIFBTLzIta2V5Ym9hcmQgcG9ydCBhdCAweGZmZDA4MDAwLi4u ClN1cHBvcnQgZm9yIExhc2kgUFMvMi1wc2F1eCBub3QgeWV0IGF2YWlsYWJsZSAhCkZvdW5kIEhJ TCBhdCAweGZmZTAxMDAwLCBJUlEgMTI2Ck5vIGhhbmRsZXIgZm9yIGludGVycnVwdCAzNSAhCkhJ TDogdGltZWQgb3V0LCBhc3N1bWluZyBubyBrZXlib2FyZCBwcmVzZW50LgpXYXJuaW5nIDogZGV2 aWNlICgxMCwgMHg0MSwgMHgwLCAweDczLCAweDApIE5PVCBjbGFpbWVkIGJ5IEhJTCA3MTIsIDcx NSBvciBzaW1pbGlhcgpEaW5vIHZlcnNpb24gMi4wIChicmlkZ2UgbW9kZSkgZm91bmQgYXQgMHhm ZmY4MDAwMAoKClRoZSBHU0N0b1BDSSAoRGlubyBocmV2IDApIGJ1cyBjb252ZXJ0ZXIgZm91bmQg bWF5IGV4aGliaXQKZGF0YSBjb3JydXB0aW9uLiAgU2VlIFNlcnZpY2UgTm90ZSBOdW1iZXJzOiBB NDE5MEEtMDEsIEE0MTkxQS0wMS4KU3lzdGVtcyBzaGlwcGVkIGFmdGVyIEF1ZyAyMCwgMTk5NyB3 aWxsIG5vdCBleGhpYml0IHRoaXMgcHJvYmxlbS4KTW9kZWxzIGFmZmVjdGVkOiBDMTgwLCBDMTYw LCBDMTYwTCwgQjE2MEwsIGFuZCBCMTMyTCB3b3Jrc3RhdGlvbnMuCgpkaW5vX2JyaWRnZV9pbml0 OiBJT19BRERSX0VOIGhhc24ndCBiZWVuIGNvbmZpZ3VyZWQuCmtlcm5lbCBCVUcgYXQgZGluby5j OjY0NiEKTGludXggTkVUNC4wIGZvciBMaW51eCAyLjQKQmFzZWQgdXBvbiBTd2Fuc2VhIFVuaXZl cnNpdHkgQ29tcHV0ZXIgU29jaWV0eSBORVQzLjAzOQpTdGFydGluZyBrc3dhcGQgdjEuOApzdGlm Yi5jOiBzZWFyY2hpbmcgZm9yIHdvcmQgbW9kZSBTVEkgUk9Ncwpmb3VuZCBwb3RlbnRpYWwgU1RJ IFJPTSBhdCBmNDAwMDAwMApTVEkgYnl0ZSBtb2RlIFJPTSBhdCBmNDAwMDAwMCwgaWdub3JlZApm b3VuZCBwb3RlbnRpYWwgU1RJIFJPTSBhdCBmODAwMDAwMApwdHk6IDI1NiBVbml4OTggcHR5cyBj b25maWd1cmVkCmxwMDogdXNpbmcgcGFycG9ydDAgKGludGVycnVwdC1kcml2ZW4pLgpSQU1ESVNL IGRyaXZlciBpbml0aWFsaXplZDogMTYgUkFNIGRpc2tzIG9mIDQwOTZLIHNpemUgMTAyNCBibG9j a3NpemUKZXRoMDogODI1OTYgYXQgMHhmZmQwNzAwMCwgMDggMDAgMDkgRUYgMzQgRjUgSVJRIDg3 Lgo4MjU5Ni5jICRSZXZpc2lvbjogMS4xNCAkClNlcmlhbCBkcml2ZXIgdmVyc2lvbiA1LjAyICgy MDAwLTA4LTA5KSB3aXRoIE1BTllfUE9SVFMgU0hBUkVfSVJRIFNFUklBTF9QQ0kgZW5hYmxlZAp0 dHlTMDAgYXQgaW9tZW0gMHhmZmQwNTgwMCAoaXJxID0gOTApIGlzIGEgMTY1NTBBCnR0eVMwMSBh dCBpb21lbSAweGZmZTAyODAwIChpcnEgPSAxMjEpIGlzIGEgMTY1NTBBCkdlbmVyaWMgUlRDIERy aXZlciB2MS4wMiAwNS8yNy8xOTk5IFNhbSBDcmVhc2V5IChzYW1teUBvaC52ZXJpby5jb20pClND U0kgc3Vic3lzdGVtIGRyaXZlciBSZXZpc2lvbjogMS4wMApzaW03MDA6IENvbmZpZ3VyaW5nIDUz YzcxMCAoU0NTSS1JRCA3KSBhdCBmZmQwNjEwMCwgSVJRIDg2CnNjc2kwOiBSZXZpc2lvbiAweDIK UG9zdCB0ZXN0MSwgaXN0YXQgMDEsIHNzdGF0MCAwMCwgZHN0YXQgODQKc2ltNzAwOiBXQVJOSU5H IElSUSBwcm9iZSBmYWlsZWQsIChyZXR1cm5lZCAwKQpzY3NpMDogR29vZCwgdGFyZ2V0IGRhdGEg YXJlYXMgYXJlIGRtYSBjb2hlcmVudApzY3NpMDogdGVzdCAxIGNvbXBsZXRlZCBvay4Kc2NzaTA6 IHNpbTcwMF9pbnRyX2hhbmRsZSgpIGNhbGxlZCB3aXRoIG5vIGludGVycnVwdApzY3NpMCA6IExB U0kvU2ltcGxlIDUzYzd4eAogIFZlbmRvcjogUElPTkVFUiAgIE1vZGVsOiBDRC1ST00gRFItVTEy WCAgICBSZXY6IDEuMDYKICBUeXBlOiAgIENELVJPTSAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgQU5TSSBTQ1NJIHJldmlzaW9uOiAwMgpEZXRlY3RlZCBzY3NpIENELVJPTSBzcjAgYXQgc2Nz aTAsIGNoYW5uZWwgMCwgaWQgMCwgbHVuIDAKc3IwOiBzY3NpMy1tbWMgZHJpdmU6IDEyeC8xMngg eGEvZm9ybTIgY2RkYSB0cmF5ClVuaWZvcm0gQ0QtUk9NIGRyaXZlciBSZXZpc2lvbjogMy4xMQpz ZWFyY2hpbmcgZm9yIHdvcmQgbW9kZSBTVEkgUk9Ncwpmb3VuZCBwb3RlbnRpYWwgU1RJIFJPTSBh dCBmNDAwMDAwMApTVEkgYnl0ZSBtb2RlIFJPTSBhdCBmNDAwMDAwMCwgaWdub3JlZApmb3VuZCBw b3RlbnRpYWwgU1RJIFJPTSBhdCBmODAwMDAwMApzZWFyY2hpbmcgZm9yIGJ5dGUgbW9kZSBTVEkg Uk9Ncwpmb3VuZCBwb3RlbnRpYWwgU1RJIFJPTSBhdCBmNDAwMDAwMApTVEkgYnl0ZSBtb2RlIFJP TSB0eXBlIDEKIHN1cHBvcnRzIDE1IG1vbml0b3JzCiBjb25mb3JtcyB0byBTVEkgUk9NIHNwZWMg cmV2aXNpb24gOC4wNwpkdW1wX3N0aV9yb206IDUwMAogZ3JhcGhpY3MgaWQgMmQwOGMwYTcwOWEw MjU4NwpkdW1wX3N0aV9yb206IDUxMAogZm9udCBzdGFydCAwMDAxODNjMwpkdW1wX3N0aV9yb206 IDUxMgogcmVnaW9uIGxpc3QgMDAwMTgzNjMKZHVtcF9zdGlfcm9tOiA1MTQKIGluaXRfZ3JhcGgg MDAwMDFhNjMKZHVtcF9zdGlfcm9tOiA1MTYKIGFsdGVybmF0ZSBjb2RlIHR5cGUgMApkdW1wX3N0 aV9yb206IDUxOApuZXh0IGZvbnQgMDAwMDQwNDAKZjQwMDAwMDAgYgpmODAwMDAwMCBiClN3aXRj aGluZyBmcm9tIFBEQyBjb25zb2xlCg== --------------Boundary-00=_ABNZX5KGKOOFAA0B1BIM-- From rhirst@linuxcare.com Tue, 14 Nov 2000 10:17:04 +0000 Date: Tue, 14 Nov 2000 10:17:04 +0000 From: Richard Hirst rhirst@linuxcare.com Subject: sym53c8xx-driver (was: Re: [parisc-linux] kernel merge) Hi Helge, On Tue, Nov 14, 2000 at 01:13:58AM +0100, Helge Deller wrote: > On Tuesday 14 November 2000 00:27, Richard Hirst wrote: > > Hi Helge, > > The problem I fixed related to the ncr53c8xx driver (which shares > > code with sym53c8xx), and was to make 53c720 support work again. > > sym53c8xx worked for me on my A180. Please can you try booting > > with > > > > sym53c8xx=verb:7,debug:0xffff > > > > and send me the output? > > > > Thanks, > > Richard > > > Hi Richard, > > the output and the relevant part of .config is attached. > > Greetings, > > Helge Thanks. I agree it doesn't look like the driver is even seeing the chip; I wonder if PCI support is broken... > dino_bridge_init: IO_ADDR_EN hasn't been configured. > kernel BUG at dino.c:646! Does it usually say that on bootup? Richard From matthew@wil.cx Tue, 14 Nov 2000 10:29:36 +0000 Date: Tue, 14 Nov 2000 10:29:36 +0000 From: Matthew Wilcox matthew@wil.cx Subject: [parisc-linux] kernel merge On Fri, Nov 10, 2000 at 02:28:33PM -0700, bame@riverrock.org wrote: > fcntl.h acquired a 'struct fcntl64' used with 64-bit offsets, implementing > fcntl(fd, F_S/GETLK[W]64, ...). Several other locking-related #defines added. > > We'll need to add the getdents64() and fcntl64() syscall glue. (TODO!!!) actually, we don't. Linux/PA-RISC has sufficiently wide data types already so we don't have the grot required in other ports to support the appropriate wide data types. > looks like maybe the get/put_user_ret() functions in asm/uaccess.h are > obsolete? (TODO) yes, they are. exterminate! exterminate! -- Revolutions do not require corporate support. From deller@gmx.de Tue, 14 Nov 2000 14:11:42 +0100 (MET) Date: Tue, 14 Nov 2000 14:11:42 +0100 (MET) From: Helge Deller deller@gmx.de Subject: sym53c8xx-driver (was: Re: [parisc-linux] kernel merge) > Hi Helge, > > On Tue, Nov 14, 2000 at 01:13:58AM +0100, Helge Deller wrote: > > On Tuesday 14 November 2000 00:27, Richard Hirst wrote: > > > Hi Helge, > > > The problem I fixed related to the ncr53c8xx driver (which shares > > > code with sym53c8xx), and was to make 53c720 support work again. > > > sym53c8xx worked for me on my A180. Please can you try booting > > > with > > > > > > sym53c8xx=verb:7,debug:0xffff > > > > > > and send me the output? > > > > > > Thanks, > > > Richard > > > > > > Hi Richard, > > > > the output and the relevant part of .config is attached. > > > > Greetings, > > > > Helge > > Thanks. I agree it doesn't look like the driver is even seeing the > chip; I wonder if PCI support is broken... > > > dino_bridge_init: IO_ADDR_EN hasn't been configured. > > kernel BUG at dino.c:646! > > Does it usually say that on bootup? Yep. Has always been there, but nevertheless the scsi-driver worked before. FYI: The non-pci sim700-driver also didn't showed up before pb fixed it in CVS with a few one-line-patches. NB: Could maybe someone (ggg?) explain me the kernel-bug mentioned above ? > > Richard > Greetings, Helge -- Sent through GMX FreeMail - http://www.gmx.net From grundler@cup.hp.com Tue, 14 Nov 2000 08:10:42 -0800 Date: Tue, 14 Nov 2000 08:10:42 -0800 From: Grant Grundler grundler@cup.hp.com Subject: [parisc-linux] dino maintainer? Anyone interested in maintaining Dino? I don't have time for it and all the docs are on the web. One of the "TODO" things is to convert dino.c to use struct pci_hba the same way lba_pci.c does.... Richard Hirst wrote: ... > Thanks. I agree it doesn't look like the driver is even seeing the > chip; I wonder if PCI support is broken... > > > dino_bridge_init: IO_ADDR_EN hasn't been configured. > > kernel BUG at dino.c:646! > > Does it usually say that on bootup? per Helge's request: The bug is normal for card-mode Dino - not for Built-in Dino. I think Helge has the GSC 100BT card which is a card-mode Dino on-board with one (or two) Tulip(s) behind it. The warning is a reminder one can NOT use MMIO accesses to those PCI devices and *only* I/O Port space (eg inb/outb). If someone wants to fix the warning so it's quiet for card-mode devices...see is_card_dino(d) in dino_driver_callback() for an example. FYI - card-mode dino was used for several different networking interfaces but not SCSI interfaces. hope this helps, grant Grant Grundler Unix Systems Enablement Lab +1.408.447.7253 From bame@noam.fc.hp.com Tue, 14 Nov 2000 09:35:01 -0700 Date: Tue, 14 Nov 2000 09:35:01 -0700 From: Paul Bame bame@noam.fc.hp.com Subject: [parisc-linux] CVS linux Vs. -test10 I've attached an overview of differences between our CVS linux sources following the -test10 merge and the upstream -test10 sources. This document is also at http://puffin.external.hp.com/~bame/diff.html The raw 'diff' output (now a bit out of date) is at http://puffin.external.hp.com/~bame/diff.out If anyone gets bored, this list is full of small (and not so small) tasks which range from very simple (drivers/block/rd.c) to fairly complex (scripts/*). -P palinux Vs. linux 2.4.0-test10 Here's a brief summary of the differences in common code between palinux (tag: LINUS_240_TEST10_MERGED) and the upstream -test10 sources. The full diff output is in diff.out. NOTE this does not include machine-depend differences * Minor changes in several locations to support GSC * Minor top-level Makefile hacks, though the CFLAGS one is quite important. * Lots of RCS $Revision$ differences in ACPI (a different 'cvs import' would've eliminated these differences). * drivers/block/rd.c: obsolete debug code for parisc64. Changed a constant from 0xffffffffL to 0xffffffffUL because of a parisc64 gcc bug initializing longs. The repaired code is probably "more correct" anyway. * drivers/char/Config.in: changes to support LASI, parisc real-time clock (CONFIG_GENRTC) * drivers/char/Makefile: Config-related changes to support HP keyboards and RTC * drivers/char/console.c: looks like dead or dying experimental parisc code -- probably should be removed. Also some parisc-specific comments and format changes which should disappear. * drivers/char/serial.c: support for GSC and A500 serial * drivers/net/Makefile,Space.c: mostly LASI LAN support * drivers/net/eepro100.c: no clue about this one * drivers/net/tulip/interrupt.c: workaround for a B180+busy-lan boot problem -- probably should be sent upstream. * drivers/net/tulip/tulip_core.c: required #ifdef for hppa, also printk() changes which appear valid * drivers/parport/Makefile: GSC * drivers/parport/parport_gsc.c: New file for palinux -- GSC parallel ports -- required * drivers/pci/pci.c: eh? Grant? * drivers/pci/setup-bus.c: function definition tweek -- Grant? * drivers/scsi: Lots of changes here -- rhirst? See for yourself. Basics: support LASI and Zalon scsi, changes to 53c8xx drivers, rename sim7x0 to sim710 * drivers/sound: support for HP "Harmony" sound * drivers/video: STI and HP FB video drivers (iodccon is probably worthless) * fs: add support for SOM executables * fs/binfmt_elf.c,exec.c: changes for stack-grows-up? * fs/nfs/read.c: probably unnecessary hack for broken parisc64 gcc * fs/proc/array.c: ?? something with signals ?? * fs/stat.c: added __hppa__ to several #ifdefs * include/linux/binfmts.h,fs.h,kernel.h,tty.h,udf_fs_sb.h: unnecessary differences? * include/linux/init.h: we use different section names -- why????, probably some unnecessary other differences too * include/linux/mm.h: VM_STACK_FLAGS difference -- jsm? * include/linux/wait.h: parisc debugging -- should be removed * init/main.c: KWDB and GSC support plus a bunch of stuff which should probably go away. * kernel/Makefile,dma.c,fork.c,printk.c: eh? * kernel/module.c: possible parisc-needed changes * kernel/signal.c: unknown signal-related differences * lib/inflate.c: changed some constants to work around parisc64 gcc bug * mm/mprotect.c: ? * scripts/*: MANY differences here. Looks like a combination of things we hacked to fix configuration problems plus MAYBE not updating these files from new Linux versions in the past. 'make menuconfig' is significantly different from upstream. Even the mkdep.c program is different. From bame@noam.fc.hp.com Tue, 14 Nov 2000 10:02:06 -0700 Date: Tue, 14 Nov 2000 10:02:06 -0700 From: Paul Bame bame@noam.fc.hp.com Subject: [parisc-linux] kernel merge = On Fri, Nov 10, 2000 at 02:28:33PM -0700, bame@riverrock.org wrote: = > fcntl.h acquired a 'struct fcntl64' used with 64-bit offsets, implementing = > fcntl(fd, F_S/GETLK[W]64, ...). Several other locking-related #defines add ed. = > = > We'll need to add the getdents64() and fcntl64() syscall glue. (TODO!!!) = = actually, we don't. Linux/PA-RISC has sufficiently wide data types = already so we don't have the grot required in other ports to support = the appropriate wide data types. Ok that sounds great but I need a clue how to see it. struct flock contains an off_t which is 32 bits on narrow (wide too at the moment, but that will probably change). Also, struct dirent contains a 32-bit inode and a __kernel_off_t offset (d_off), which is also 32 bits narrow. I did see the ... in our fcntl() syscall definition so I'll go check glibc to see what's happening there. I wouldn't be so picky except that I need to write the 32/64 syscall translators for these soon! Thanks! -P From bame@noam.fc.hp.com Tue, 14 Nov 2000 10:14:51 -0700 Date: Tue, 14 Nov 2000 10:14:51 -0700 From: Paul Bame bame@noam.fc.hp.com Subject: [parisc-linux] kernel merge = On Fri, Nov 10, 2000 at 02:28:33PM -0700, bame@riverrock.org wrote: = > fcntl.h acquired a 'struct fcntl64' used with 64-bit offsets, implementing = > fcntl(fd, F_S/GETLK[W]64, ...). Several other locking-related #defines add ed. = > = > We'll need to add the getdents64() and fcntl64() syscall glue. (TODO!!!) = = actually, we don't. Linux/PA-RISC has sufficiently wide data types = already so we don't have the grot required in other ports to support = the appropriate wide data types. Oh, and won't we have to support these syscalls anyway, because user programs will make them? I suppose we could #define them in libc headers. = > looks like maybe the get/put_user_ret() functions in asm/uaccess.h are = > obsolete? (TODO) = = yes, they are. exterminate! exterminate! Done From pdbeal@louisville.edu Tue, 14 Nov 2000 13:40:24 -0500 Date: Tue, 14 Nov 2000 13:40:24 -0500 From: Phillip D. Beal pdbeal@louisville.edu Subject: [parisc-linux] 735/755 and Kernel test10.. Hey, I've been working on the 735 and 755 that I has access to and so far the systems booted the test6 kernel, but scrambled the console as soon as init was run. So, I figured I'd try the new test10 kernel that you have added. Both system boot, and then stop at this line: branching to kernel entry point 0x00100000 Can't select default wide mode, PDC_PSW call does not work What does the above actually mean? How can I remove the PDC_PSW call from the kernel so it can boot? I have plans to test this new kernel image on a 715 later today. Thanks, -- Phillip Beal Electrical and Computer Engineering S+LUG Vice-President From grundler@cup.hp.com Tue, 14 Nov 2000 10:51:26 -0800 Date: Tue, 14 Nov 2000 10:51:26 -0800 From: Grant Grundler grundler@cup.hp.com Subject: [parisc-linux] 735/755 and Kernel test10.. "Phillip D. Beal" wrote: > Hey, > > I've been working on the 735 and 755 that I has access to and so far > the systems booted the test6 kernel, but scrambled the console as soon > as init was run. So, I figured I'd try the new test10 kernel that you > have added. Both system boot, and then stop at this line: > > branching to kernel entry point 0x00100000 > Can't select default wide mode, PDC_PSW call does not work Did you build this kernel yourself? If so, it sounds like you built a 64-bit kernel since that's the default. You need to change the ARCH line in the linux/Makefile to read "parisc" instead of "parisc64". grant > > What does the above actually mean? How can I remove the PDC_PSW call > from the kernel so it can boot? I have plans to test this new kernel > image on a 715 later today. > > Thanks, > -- > Phillip Beal > Electrical and Computer Engineering > S+LUG Vice-President > > --------------------------------------------------------------------------- > To unsubscribe: send e-mail to parisc-linux-request@thepuffingroup.com with > `unsubscribe' as the subject. > Grant Grundler Unix Systems Enablement Lab +1.408.447.7253 From grundler@cup.hp.com Tue, 14 Nov 2000 11:08:20 -0800 Date: Tue, 14 Nov 2000 11:08:20 -0800 From: Grant Grundler grundler@cup.hp.com Subject: [parisc-linux] 735/755 and Kernel test10.. Grant Grundler wrote: > If so, it sounds like you built a 64-bit kernel since that's the default. Correction. *was* the default. default ARCH was changed last night to parisc. grant Grant Grundler Unix Systems Enablement Lab +1.408.447.7253 From ian.zink@maryville.com Tue, 14 Nov 2000 13:20:05 -0600 Date: Tue, 14 Nov 2000 13:20:05 -0600 From: Ian Zink ian.zink@maryville.com Subject: [parisc-linux] Palinux on a 712/60 I have a hp 712/60 I was trying to get loaded with Pa-linux. I'm using the 0.5 version of the Pa-linux cd. If I boot right off the CD it all loads until it gets to Switching to PDC. At that point nothing happens. From I have read the list, that is because the kernel is switching the text console. However, the 712s don't have consoles. From what I have also read the CD should work if you pass the kernel the parameter console=tty. So I tried to "boot scsi.2.0 isl" from the boot_admin prompt. It gave me the PALO ISL, but I could not choose which line I wanted to edit. Further, I couldn't even type "b" to boot. I don't know if the isl is freezing or what is taking place What I am wondering is there a way to boot a 712/80 without having to get cross-compiler gcc, compile the kernel, etc. Is there someway I could add the ramdisk-sti.tgz on the ISO to make it work? If so, what would need to be done? Thanks, Ian Zink, Systems Engineer Maryville Technologies 540 Maryville Centre, Suite 300 St. Louis, MO 63141 636/519-4182 (FAX) 636/519-4141 ian.zink@maryville.com www.maryville.com From mang@subcarrier.org Tue, 14 Nov 2000 14:17:35 -0500 Date: Tue, 14 Nov 2000 14:17:35 -0500 From: Michael Ang mang@subcarrier.org Subject: linux bame bame@riverrock.org wrote: > > = On Thu, Nov 09, 2000 at 03:53:48PM -0700, Paul Bame wrote: > = > Somebody never imported 2.4.0-test6, then I imported -test10 on the mai > n > = > vendor branch and now can't (easily) undo that to import test6 and THEN > = > test10. This workaround sucks. If the sources on the linus branch have been religiously tagged every time they're updated, then reverting to a previous would have been relatively painless. I'm not sure what "this workaround" was, but I guess at this point test10 is merged so the point is moot. > = don't use vendor branches. didn't you talk to mang about this? > > Um, I have no information to go on from your note. All the (successful) > merges I've done before have used the cookbook CVS merge method including > a vendor branch. Several (N-1?) of the palinux merges have been > accompanied by updating the vendor branch. And this merge is going > well despite the ugly workaround, or so it appears to me. Just > importing files to a vendor branch should have no effect on anything > else unless CVS has some horrible bug (RCS does not). Before I make > what is apparently a serious mistake ("don't use vendor branches" sounds > pretty serious) please enlighten me! Vendor branches are evil. (When I say "vendor branch" I mean the special kind of branch created by "cvs import".) When you check in to a vendor branch your changes will also be seen on the trunk, *unless* that file has been previously modified on the trunk. This is almost never what you want and adds confusion during merging (when you least want it). Tracking third-party sources using a normal branch, as we are doing, is much simpler and gives you more control. When I did the original import of Linus' sources I converted the vendor branch to a normal branch using cvs admin magic. So none of the annoyances of vendor branches should affect us, as long as any new files are added on the linus branch using "cvs add", NOT "cvs import". When you say you "I imported -test10 on the main vendor branch" I hope you really mean that you used "cvs add" on the linus branch. From your other messages, your tags looked good. - Mike. From bame@noam.fc.hp.com Tue, 14 Nov 2000 13:00:41 -0700 Date: Tue, 14 Nov 2000 13:00:41 -0700 From: Paul Bame bame@noam.fc.hp.com Subject: linux bame = bame@riverrock.org wrote: = > = > = On Thu, Nov 09, 2000 at 03:53:48PM -0700, Paul Bame wrote: = > = > Somebody never imported 2.4.0-test6, then I imported -test10 on the mai = > n = > = > vendor branch and now can't (easily) undo that to import test6 and THEN = > = > test10. This workaround sucks. = = If the sources on the linus branch have been religiously tagged every = time they're updated, then reverting to a previous would have been = relatively painless. I'm not sure what "this workaround" was, but I = guess at this point test10 is merged so the point is moot. Like the comment said, there was no copy of plain -test6 in CVS (that I saw). Without -test6 in CVS it's much harder to use cvs diff to figure out the right way to merge files when there are conflicts. I didn't realize this until -test10 was already there, so I *then* brought in -test6. They're in the wrong order on the 1.1.1 branch, so the standard merge command 'cvs -jlinus:yesterday -jlinus:' won't work next time -- explicit names will be required. = Vendor branches are evil. (When I say "vendor branch" I mean the = special kind of branch created by "cvs import".) When you check in to a = vendor branch your changes will also be seen on the trunk, *unless* that = file has been previously modified on the trunk. Thanks for clarifying what "evil" means! That is pretty ugly indeed! = This is almost never = what you want and adds confusion during merging (when you least want = it). Tracking third-party sources using a normal branch, as we are = doing, is much simpler and gives you more control. But I've seen no cook book for it. I'm guessing that instead of cvs import you use: cvs co -rlinus linux cd linux cvs commit (make note of new files from commit) cvs add cvs commit cvs tag LINUS_NEW_REVISION perhaps with provision for removing obsolete files too. I suppose that is simpler than a single cvs import command from a certain perspective :-) = When I did the original import of Linus' sources I converted the vendor = branch to a normal branch using cvs admin magic. So none of the = annoyances of vendor branches should affect us, as long as any new files = are added on the linus branch using "cvs add", NOT "cvs import". Have you a pointer to the magic or the knowledge to recreate it? I had no idea there was a special RCS marking for the evil type of branch. = When you say you "I imported -test10 on the main vendor branch" I hope = you really mean that you used "cvs add" on the linus branch. From your = other messages, your tags looked good. I used "cvs import", and either your branch magic worked, or I finished the merge before anybody randomly updated from cvs. Since import used 1.1.1, which is the branch you "fixed", it seems possible that 'cvs import' might be rendered harmless but I don't know that for sure. -P From pjlahaie@linuxcare.com Tue, 14 Nov 2000 15:43:00 -0500 Date: Tue, 14 Nov 2000 15:43:00 -0500 From: Paul J.Y. Lahaie pjlahaie@linuxcare.com Subject: [parisc-linux] Beta CD --SkvwRMAIpAhPCcCJ Content-Type: text/plain; charset=us-ascii Content-Disposition: inline This is to answer all the questions about sti console. Currently, in the CVS tree, serial console and STI console cannot be turned on at the same time. This means that a choice between serial/sti needs to be done at compile time. At the time we cut the beta, it was decided that serial console was more important than sti console. I am also working on resolving the problem with STI/serial console and once I have a fix ready, I will make a kernel image available. The current beta CD is also expecting a console on ttyS0 and does not currently open a ttyx getty. When I have a kernel that can decide the console at runtime, I will look into the beta CD issues. If you have any more questions or suggestions, feel free to email me or post on this list. Thank you. - Paul --SkvwRMAIpAhPCcCJ Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.4 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE6EaPR8ggPQthPCzcRAhT8AKC8EU8yusyoEvPHxKAQsaM0vMGthwCgnbbC Yz6ZWjq3q9B80bI+YRxc8xo= =HhRZ -----END PGP SIGNATURE----- --SkvwRMAIpAhPCcCJ-- From raj@cerias.purdue.edu Tue, 14 Nov 2000 16:18:06 -0500 Date: Tue, 14 Nov 2000 16:18:06 -0500 From: Brian Poole raj@cerias.purdue.edu Subject: [parisc-linux] Beta CD Sounds like a plan to me. I don't suppose you know how to make a 715 boot to console? Pulling the keyboard and monitor cables off the back just make it stop at boot with the unable to initiliaze keyboard error I posted with earlier. I am assuming there is some sort of boot_admin trickery necessary, but I am unaware of what it might entail and my poking around has yielded nothing.. Any advice here would be much appreciated. -b Quoting Paul J.Y. Lahaie (pjlahaie@linuxcare.com) from 14 November 2000: > with STI/serial console and once I have a fix ready, I will make a kernel > image available. The current beta CD is also expecting a console on .. > If you have any more questions or suggestions, feel free to email me or > post on this list. Thank you. From dave@hiauly1.hia.nrc.ca Tue, 14 Nov 2000 16:40:52 -0500 (EST) Date: Tue, 14 Nov 2000 16:40:52 -0500 (EST) From: John David Anglin dave@hiauly1.hia.nrc.ca Subject: abort in eliminate_regs compiling glob.c from glibc > > Breakpoint 2, eliminate_regs_in_insn (insn=0x406a0ba0, replace=0) > > at ../../gcc/reload1.c:2826 > > 2826 if (! insn_is_asm && icode < 0) > > (gdb) p debug_rtx (insn) > > (insn/s 2711 2709 2719 (set (reg:SI 6 %r6) > > (reg:SI 28 %r28)) 69 {pre_ldw-4} (insn_list 2708 (insn_list:REG_DEP_ANTI 2696 (insn_list:REG_DEP_ANTI 2702 (insn_list:REG_DEP_ANTI 2697 (nil))))) > > (expr_list:REG_DEAD (reg:SI 28 %r28) > > (insn_list:REG_RETVAL 2708 (expr_list:REG_EQUAL (expr_list (use (mem:BLK (scratch) 0)) > > (expr_list (symbol_ref/v:SI ("@strlen")) > > (expr_list (reg/v:SI 4 %r4) > > (nil)))) > > (nil))))) > > The `use' arises from the `__pure__' attribute in the prototype for strlen: > > extern size_t strlen (__const char *__s) __attribute__ ((__pure__)); Here is a patch to fix the abort in eliminate_regs when it encounters a USE. As I understand the situation, there are three conditions needed to trigger it: 1) A function that contains insns with an eliminable register. 2) The function must call __builtin_alloca to change the frame size from its initial size. 3) After the call to __builtin_alloca, there must be a call to a pure function. With the enclosed patch, I can now build glibc for hppa-linux with -O3 optimisation. Please review carefully because I will be the first to admit that I don't understand why the use is there in the first place and all the details of what eliminate_reg does. Dave -- J. David Anglin dave.anglin@nrc.ca National Research Council of Canada (613) 990-0752 (FAX: 952-6605) 2000-11-14 John David Anglin * reload1.c (eliminate_regs): Don't abort on MEM USEs. --- reload1.c.orig Wed Sep 27 14:27:23 2000 +++ reload1.c Tue Nov 14 16:01:56 2000 @@ -2499,6 +2499,10 @@ return x; case USE: + /* Handle insn_list USE that a call to a pure functions may generate. */ + new = eliminate_regs (XEXP (x, 0), 0, insn); + if (GET_CODE (new) == MEM) + return XEXP (new, 0); case CLOBBER: case ASM_OPERANDS: case SET: From grundler@cup.hp.com Tue, 14 Nov 2000 14:32:00 -0800 Date: Tue, 14 Nov 2000 14:32:00 -0800 From: Grant Grundler grundler@cup.hp.com Subject: [parisc-linux] Palinux on a 712/60 Ian Zink wrote: > I have a hp 712/60 I was trying to get loaded with Pa-linux. I'm using the > 0.5 version of the Pa-linux cd. If I boot right off the CD it all loads > until it gets to Switching to PDC. At that point nothing happens. From I > have read the list, that is because the kernel is switching the text > console. However, the 712s don't have consoles. 712s have consoles. They have two outputs which can be used as console by linux. The STI consoles (VGA-like spigot) and serial. Connect a serial cable 9600-8-n-1 and run minicom at the other end. > From what I have also read > the CD should work if you pass the kernel the parameter console=tty. So I > tried to "boot scsi.2.0 isl" from the boot_admin prompt. It gave me the > PALO ISL, but I could not choose which line I wanted to edit. Further, I > couldn't even type "b" to boot. I don't know if the isl is freezing or what > is taking place That's a different problem...pb? > What I am wondering is there a way to boot a 712/80 without having > to get cross-compiler gcc, compile the kernel, etc. The CD was intended to also work on the 712 even though we may not have tested on it. > Is there someway I could > add the ramdisk-sti.tgz on the ISO to make it work? If so, what would need > to be done? no clue. anyone else? grant Grant Grundler Unix Systems Enablement Lab +1.408.447.7253 From mang@subcarrier.org Tue, 14 Nov 2000 17:31:22 -0500 Date: Tue, 14 Nov 2000 17:31:22 -0500 From: Michael Ang mang@subcarrier.org Subject: [parisc-linux] tracking third-party sources (was Re: linux bame) Paul Bame wrote: > > = bame@riverrock.org wrote: > = > > = > = On Thu, Nov 09, 2000 at 03:53:48PM -0700, Paul Bame wrote: > = > = > Somebody never imported 2.4.0-test6, then I imported -test10 on the > mai > = > n > = > = > vendor branch and now can't (easily) undo that to import test6 and > THEN > = > = > test10. This workaround sucks. > = > Like the comment said, there was no copy of plain -test6 in CVS (that I > saw). Without -test6 in CVS it's much harder to use cvs diff to figure > out the right way to merge files when there are conflicts. > I didn't realize this until -test10 was already there, so I *then* > brought in -test6. They're in the wrong order on the 1.1.1 branch, so > the standard merge command 'cvs -jlinus:yesterday -jlinus:' > won't work next time -- explicit names will be required. The best thing to do is to import -test10 again and move the static tag by re-tagging. > = Tracking third-party sources using a normal branch, as we are > = doing, is much simpler and gives you more control. > > But I've seen no cook book for it. I'm guessing that instead of cvs import > you use: > cvs co -rlinus linux > > cd linux > cvs commit (make note of new files from commit) > cvs add > cvs commit > cvs tag LINUS_NEW_REVISION > perhaps with provision for removing obsolete files too. I suppose that is > simpler than a single cvs import command from a certain perspective :-) I had a good chat with Paul about this, and we worked out that using "import" is marginally better. This is what the add/remove method would look like: cvs co -rlinux linux cvs rm cvs add cvs commit cvs tag LINUS_NEW_REVISION Add the import method: cd linux cvs import linux linus LINUS_NEW_REVISION cvs admin -b > = When you say you "I imported -test10 on the main vendor branch" I hope > = you really mean that you used "cvs add" on the linus branch. From your > = other messages, your tags looked good. > > I used "cvs import", and either your branch magic worked, or I finished the > merge before anybody randomly updated from cvs. Since import used 1.1.1, > which is the branch you "fixed", it seems possible that 'cvs import' might > be rendered harmless but I don't know that for sure. Using "import" to bring in new files taints them with the vendor branch badness. These files should be adjusted using "cvs admin -b". Note that "cvs admin" works directly on files in the repository at low level (without any revisioning of changes) and is thus to be avoided if at all possible. Please don't run "cvs admin" if you (the collective "you") don't know the consequences. - Mike. From ian.zink@maryville.com Tue, 14 Nov 2000 17:08:33 -0600 Date: Tue, 14 Nov 2000 17:08:33 -0600 From: Ian Zink ian.zink@maryville.com Subject: [parisc-linux] Palinux on a 712/60 Thanks for the reply, Grant. However, the 712s do not have a serial console. They do have a com port, but it does not work as a console, unfortunately. So I need do need to get a STI enabled kernel. I dropped Paul Lahaie a note to see if he could send me such a kernel so I do not have to create the entire cross-platform development environment just to boot one of these 712s. After I get it, I plan on expanding the 0.5 iso and making a new one using the STI console kernel. Ian From kailasr@webcash.com Tue, 14 Nov 2000 14:58:55 -0800 Date: Tue, 14 Nov 2000 14:58:55 -0800 From: Kailashnath V Rampure kailasr@webcash.com Subject: [parisc-linux] Boot command I have booted HP A class server through network. On that I have repartioned the system and followed the steps on http://www.parisc-linux.org/install.html. I have used the following command to initialize the hard disk. The kernel I have downloaded is vmlinux-20001018. and cpied it to /mnt/boot/vmlinux after mounting /dev/sda3. I have used the following command to initialize the HDD. palo -I -k /boot/vmlinux -b /boot/iplboot \ -c '3/boot/vmlinux TERM=linux HOME=/ root=/dev/sda3' \ /dev/sda -------------------------------- I get the following error: -------------------------------- SOFT Boot. palo ipl bame@noam Tue oct 31 14:18:02 MST 2000 0/vmlinux 2138614 bytes@ 0x1f78c000 0/palo-cmdline '3/boot/vmlinux TERM=linux HOME=/ root=/dev/sda3' /dev/ida1 82 62 1030688 /dev/ida2 f0 1030750 24738 /dev/ida3 83 1055488 1030750 Kernel:partition 3 file /boot/vmlinux ext2 block size 1024 ext2_mount(partition 3) returns 0 ext2_open(/boot/vmlinux) = -1 open /boot/vmlinux failed ------------------------------------- Please suggest. From grundler@cup.hp.com Tue, 14 Nov 2000 15:18:10 -0800 Date: Tue, 14 Nov 2000 15:18:10 -0800 From: Grant Grundler grundler@cup.hp.com Subject: [parisc-linux] Palinux on a 712/60 Ian Zink wrote: > Thanks for the reply, Grant. However, the 712s do not have a serial console. > They do have a com port, but it does not work as a console, unfortunately. It does for linux. That's what the "Switching from PDC Console" is about. Connect the serial cable to the com port and look at the output. I've done it in the past and know it worked at least once. I haven't tried it with the lasted ISO - no time to play w/712's now. > So I need do need to get a STI enabled kernel. I dropped Paul Lahaie a note > to see if he could send me such a kernel... Paul just sent mail to the list indicating he's working on console issues. Please let him work on it. Trust me, he'll tell us when he's done. :^) grant From dhazeghi@pacbell.net Tue, 14 Nov 2000 18:17:39 -0800 Date: Tue, 14 Nov 2000 18:17:39 -0800 From: dhazeghi@pacbell.net dhazeghi@pacbell.net Subject: [parisc-linux] [Semi OT] SOM Linker Alex deVries wrote: > dhazeghi@pacbell.net wrote: > > However I would like to know what work if any has been done on the SOM > > linker which HP released to the public last November(?). It seems that > > as of right now, it has not been touched since February 14, and the FSF > > binutils snapshots still do not have any SOM support for ld. Has there > > been any movement in merging this in, or is anybody working on this? > > The initial plan was to do our 32-bit userspace with SOM, worrying about > ELF32 much later in the game. But ELF32 development happened a lot > quicker than expected, and so nobody's really done much on the SOM > linker. That's what it looked like... > > > I suspect it'd be very hard to use the SOM linker code to incorporate it > into binutils, but I could be wrong. > > What are you actually trying to do? I would like to be able to set up a cross compilation environment for hpux and 32 bit PA-RISC. However without a functional cross linker, this is impossible to do, and as binutils has not got one yet, I thought perhaps the one that HP open-sourced might be some use. It would seem logical that with the sources available, it shouldn't be too difficult to fix the broken bits and get a SOM linker working in binutils, but that doesn't seem to have happened yet. Oh well, thanks for the info... Dara Hazeghi From dave@hiauly1.hia.nrc.ca Tue, 14 Nov 2000 22:00:25 -0500 (EST) Date: Tue, 14 Nov 2000 22:00:25 -0500 (EST) From: John David Anglin dave@hiauly1.hia.nrc.ca Subject: [parisc-linux] [Semi OT] SOM Linker > I would like to be able to set up a cross compilation environment for hpux and > 32 bit PA-RISC. However without a functional cross linker, this is impossible > to do, and as binutils has not got one yet, I thought perhaps the one that HP > open-sourced might be some use. It would seem logical that with the sources > available, it shouldn't be too difficult to fix the broken bits and get a SOM > linker working in binutils, but that doesn't seem to have happened yet. Oh > well, thanks for the info... You should be able to build cross compilation tools under hpux for hppa-linux. First you should install native versions of binutils and gcc under hpux (this assumes that you have the hpux C compiler and linker). The release version of gcc (2.95.2) would be a good choice. The standard hpux linker works fine with gcc/gas for C compilations. Then follow the directions at www.parisc-linux.org for building the cross compilation tools and linux. Dave -- J. David Anglin dave.anglin@nrc.ca National Research Council of Canada (613) 990-0752 (FAX: 952-6605) From dhazeghi@pacbell.net Tue, 14 Nov 2000 21:23:41 -0800 Date: Tue, 14 Nov 2000 21:23:41 -0800 From: dhazeghi@pacbell.net dhazeghi@pacbell.net Subject: [parisc-linux] [Semi OT] SOM Linker John David Anglin wrote: > > I would like to be able to set up a cross compilation environment for hpux and > > 32 bit PA-RISC. However without a functional cross linker, this is impossible > > to do, and as binutils has not got one yet, I thought perhaps the one that HP > > open-sourced might be some use. It would seem logical that with the sources > > available, it shouldn't be too difficult to fix the broken bits and get a SOM > > linker working in binutils, but that doesn't seem to have happened yet. Oh > > well, thanks for the info... > > You should be able to build cross compilation tools under hpux for hppa-linux. > First you should install native versions of binutils and gcc under hpux (this > assumes that you have the hpux C compiler and linker). The release version of > gcc (2.95.2) would be a good choice. The standard hpux linker works fine with > gcc/gas for C compilations. Then follow the directions at www.parisc-linux.org > for building the cross compilation tools and linux. This is not precisely what I mean. What I should have said is that I want to create a cross compiler --host=i686-linux --target=hppa-hpux. I asked this list, because you folks did some work on the SOM linker, which is at the moment the missing piece for a cross toolchain which targets hpux. Thanks, Dara P.S. On a different note, is the recipe fully up to date? I tried following it a few weeks ago, but glibc did not complete building successfully. From Arnaud.ATOCH@oecd.org Wed, 15 Nov 2000 10:05:04 +0100 Date: Wed, 15 Nov 2000 10:05:04 +0100 From: Arnaud.ATOCH@oecd.org Arnaud.ATOCH@oecd.org Subject: [parisc-linux] Palinux on a 712/60 Hi, I got a couple of 715 and I'd love having access to an ISO image with STI console kernel too. -----Original Message----- From: Ian Zink [mailto:ian.zink@maryville.com] Sent: Wednesday, November 15, 2000 00:09 To: 'parisc-linux@thepuffingroup.com' Subject: RE: [parisc-linux] Palinux on a 712/60 Thanks for the reply, Grant. However, the 712s do not have a serial console. They do have a com port, but it does not work as a console, unfortunately. So I need do need to get a STI enabled kernel. I dropped Paul Lahaie a note to see if he could send me such a kernel so I do not have to create the entire cross-platform development environment just to boot one of these 712s. After I get it, I plan on expanding the 0.5 iso and making a new one using the STI console kernel. Ian --------------------------------------------------------------------------- To unsubscribe: send e-mail to parisc-linux-request@thepuffingroup.com with `unsubscribe' as the subject. From rhirst@linuxcare.com Wed, 15 Nov 2000 09:58:35 +0000 Date: Wed, 15 Nov 2000 09:58:35 +0000 From: Richard Hirst rhirst@linuxcare.com Subject: [parisc-linux] dino maintainer? On Tue, Nov 14, 2000 at 08:10:42AM -0800, Grant Grundler wrote: > The bug is normal for card-mode Dino - not for Built-in Dino. > I think Helge has the GSC 100BT card which is a card-mode Dino on-board > with one (or two) Tulip(s) behind it. > > The warning is a reminder one can NOT use MMIO accesses to those > PCI devices and *only* I/O Port space (eg inb/outb). > > If someone wants to fix the warning so it's quiet for card-mode > devices...see is_card_dino(d) in dino_driver_callback() for an > example. > > FYI - card-mode dino was used for several different networking > interfaces but not SCSI interfaces. But Helge has problems with the sym53c8xx driver on a B160L. Is that a PCI card driven via Dino? And if so, are you saying he needs to build his kernel with CONFIG_SCSI_NCR53C8XX_IOMAPPED=y so it doesn't try to use MMIO? Helge, it might be worth trying to switch on CONFIG_SCSI_NCR53C8XX_IOMAPPED anyway just to see what happens. Otherwise someone needs to start adding printk debug to figure out what is happening. I can't do that as I don't have a sym53c8xx pci card. Richard From andrew@neep.com.au Wed, 15 Nov 2000 18:10:13 +0800 Date: Wed, 15 Nov 2000 18:10:13 +0800 From: Andrew Shugg andrew@neep.com.au Subject: [parisc-linux] Palinux on a 712/60 Arnaud.ATOCH@oecd.org said: > Hi, > > I got a couple of 715 and I'd love having access to an ISO image with STI > console kernel too. I've never made an El Torito CDROM, is it possible to have multiple boot images and a boot loader on a single disc? ie could the actual boot image be a boot loader (PALO) which then points at one or more kernels on the CDROM? Andrew. -- Andrew Shugg http://www.neep.com.au/ "Just remember, Mr Fawlty, there's always someone worse off than yourself." "Is there? Well I'd like to meet him. I could do with a good laugh." From marteaut@esiee.fr Wed, 15 Nov 2000 11:25:07 +0100 Date: Wed, 15 Nov 2000 11:25:07 +0100 From: Thomas Marteau marteaut@esiee.fr Subject: [parisc-linux] Palinux on a 712/60 Hi Ian, If you like to see a linux kernel booting on your 712, you can donwload a fully operationnal root file system with the STI console and an extra terminal with the RS232 port at http://www.esiee.fr/puffin You have also all the info to make a bootable hard disk so try it and give us feedback... Bye, Thomas Marteau ESIEE Team From rhirst@linuxcare.com Wed, 15 Nov 2000 11:12:20 +0000 Date: Wed, 15 Nov 2000 11:12:20 +0000 From: Richard Hirst rhirst@linuxcare.com Subject: [parisc-linux] Beta CD On Fri, Nov 10, 2000 at 05:14:06PM -0500, Paul J.Y. Lahaie wrote: > Hello fellow PA-RISCers, > > An preliminary beta CD for PA/Linux has been uploaded to > puffin.external.hp.com. If people could try it and forward any complaints > or suggestions to me, it would be greatly appreciated. The URL for the > image is: ftp://puffin.external.hp.com/pub/parisc/cd-images/palinux-0.5.iso.gz I just borrowed a CDROM drive for my 715/75 so I could try it on there [Actually this is the palinux-0.5.iso.gz that I commented on, not the final version]. I wasn't successful: Sometimes the boot hangs after "ASP version 1 at 0xf0800000 found", waits a few seconds and then HPMCs. The scsi driver always has serious problems with the CD drive but does detect other devices on the bus. The kernel always crashes after "Serial driver version 5.01...", (if it gets that far) with Data access rights fault in kernel: Code=26 regs=c5f9c940 (Addr=00000003) YZrvWESTHLNXBCVMcbcbcbcbOGFRQPDI PSW: 00000000000001000000000000001010 r0-3 00000000 c0217800 c011e9f8 c5ff64a0 r4-7 c5ff6200 c023ab20 00000008 f0823800 r8-11 00000003 00000007 c019134c c02b20a0 r12-15 fffffffc c023a800 c023a800 c02c31cc r16-19 c023a800 c023a800 c02b2024 00000000 r20-23 c5ff6234 f0823807 f0823800 0000000a r24-27 ffffffff c5ff64a0 c5ff6200 c0258000 r28-31 ffffffff 000002c0 c5f9cb80 c012dfc0 sr0-4 00000000 00000000 00000000 00000000 sr4-8 00000000 00000000 00000000 00000000 IASQ: 00000000 00000000 IAOQ: c011e710 c011e714 IIR: 0f881093 ISR: 00000000 IOR: 00000003 ORIG_R28: 00000058 I'll investigate further when I have the time. Richard From adevries@linuxcare.com Wed, 15 Nov 2000 11:50:27 -0500 Date: Wed, 15 Nov 2000 11:50:27 -0500 From: Alex deVries adevries@linuxcare.com Subject: [parisc-linux] dino maintainer? Richard Hirst wrote: > On Tue, Nov 14, 2000 at 08:10:42AM -0800, Grant Grundler wrote: > > FYI - card-mode dino was used for several different networking > > interfaces but not SCSI interfaces. > > But Helge has problems with the sym53c8xx driver on a B160L. Is > that a PCI card driven via Dino? And if so, are you saying he needs > to build his kernel with CONFIG_SCSI_NCR53C8XX_IOMAPPED=y so it > doesn't try to use MMIO? Hang on a sec... what Grant's saying is that *card-mode* dino is never used for SCSI controllers, but on the B160L it would probably be *chip-mode* dino. Does this mean that all GSC SCSI expansion cards are Zalon based? So what Helge has isn't a PCI card specifically, Dino and the 53c8xx are all on the motherboard. Does Dino handle IO memory mapping differently for chip or card mode? - Alex -- Alex deVries, Principal Solutions Architect, The Puffins at Linuxcare 613.562.2759 tel alex@linuxcare.com, http://www.linuxcare.com/ Linuxcare, Support for the revolution. From grundler@cup.hp.com Wed, 15 Nov 2000 08:06:32 -0800 Date: Wed, 15 Nov 2000 08:06:32 -0800 From: Grant Grundler grundler@cup.hp.com Subject: [parisc-linux] dino maintainer? Richard Hirst wrote: > On Tue, Nov 14, 2000 at 08:10:42AM -0800, Grant Grundler wrote: > > The bug is normal for card-mode Dino - not for Built-in Dino. > > I think Helge has the GSC 100BT card which is a card-mode Dino on-board > > with one (or two) Tulip(s) behind it. Helge confirmed he has no such card. I think the PDC simply isn't programming the Dino IO_ADDR_EN since there are no PCI devices in his B160. Helge's B160 has a old rev of Dino PCI host bus adapter chip. It's possible to have "silent" data corruption caused by older revs of dino - 3.0 and older. The latest PDC Revisions (5.x and later) know this and won't permit the system to be booted unless the only devices on the PCI bus are known graphics interface cards. > > The warning is a reminder one can NOT use MMIO accesses to those > > PCI devices and *only* I/O Port space (eg inb/outb). > > > > If someone wants to fix the warning so it's quiet for card-mode > > devices...see is_card_dino(d) in dino_driver_callback() for an > > example. This is still correct for card-mode dino. > > FYI - card-mode dino was used for several different networking > > interfaces but not SCSI interfaces. > > But Helge has problems with the sym53c8xx driver on a B160L. Is > that a PCI card driven via Dino? I doubt it now. If Helge could send richard "in io" output, I think that would clarify what's in the B160. > And if so, are you saying he needs > to build his kernel with CONFIG_SCSI_NCR53C8XX_IOMAPPED=y so it > doesn't try to use MMIO? no. no SCSI was ever implement on a card-mode dino board. No reason to since they already had Zalon or open slots. grant > Helge, it might be worth trying to switch on CONFIG_SCSI_NCR53C8XX_IOMAPPED > anyway just to see what happens. Otherwise someone needs to start > adding printk debug to figure out what is happening. I can't do > that as I don't have a sym53c8xx pci card. > > Richard From grundler@cup.hp.com Wed, 15 Nov 2000 08:17:41 -0800 Date: Wed, 15 Nov 2000 08:17:41 -0800 From: Grant Grundler grundler@cup.hp.com Subject: [parisc-linux] dino maintainer? Alex deVries wrote: > Hang on a sec... what Grant's saying is that *card-mode* dino is never > used for SCSI controllers, but on the B160L it would probably be > *chip-mode* dino. No such thing - you probably mean "Bridge Mode" and that's what the built-in Dino is using. > Does this mean that all GSC SCSI expansion cards are Zalon based? > > So what Helge has isn't a PCI card specifically, Dino and the 53c8xx are > all on the motherboard. > > Does Dino handle IO memory mapping differently for chip or card mode? yes. yes. yes (conditional). "IO memory mapping" is a confusing term. I'll assume you mean MMIO. (Memory Mapped I/O) MMIO space access is independent of I/O Port space access. MMIO space access simple isn't available for card-mode Dino since niether PDC nor the OS assigns host physical address space to the card-mode Dino (that's what IO_ADDR_EN is for). PDC does this for Bridge-mode dino (built-in) - but apperently only when it needs to. I/O Port space accesses are done the same way for both modes. I/O Port space access is implemented by poking registers on Dino. Read the Dino Spec (or source) for more details. grant Grant Grundler Unix Systems Enablement Lab +1.408.447.7253 From dave@hiauly1.hia.nrc.ca Wed, 15 Nov 2000 11:23:05 -0500 (EST) Date: Wed, 15 Nov 2000 11:23:05 -0500 (EST) From: John David Anglin dave@hiauly1.hia.nrc.ca Subject: [parisc-linux] [Semi OT] SOM Linker > This is not precisely what I mean. What I should have said is that I want to create > a cross compiler --host=i686-linux --target=hppa-hpux. I asked this list, because > you folks did some work on the SOM linker, which is at the moment the missing piece > for a cross toolchain which targets hpux. This also may be possible. The first step would be to copy the hpux headers to a i686-linux system and see if you can build the HP linker. The next step would be to try to build the cross binutils tools. I know this requires the hpux headers and likely some hacking would be required to get it to build. The linker is probably the hard part. There may be byte ordering issues and bugs in what HP contributed. Dave -- J. David Anglin dave.anglin@nrc.ca National Research Council of Canada (613) 990-0752 (FAX: 952-6605) From pdbeal@louisville.edu Wed, 15 Nov 2000 11:47:09 -0500 Date: Wed, 15 Nov 2000 11:47:09 -0500 From: Phillip D. Beal pdbeal@louisville.edu Subject: [parisc-linux] Beta CD On Fri, Nov 10, 2000 at 05:14:06PM -0500, Paul J.Y. Lahaie wrote: > Hello fellow PA-RISCers, > > An preliminary beta CD for PA/Linux has been uploaded to > puffin.external.hp.com. If people could try it and forward any complaints > or suggestions to me, it would be greatly appreciated. The URL for the > image is: ftp://puffin.external.hp.com/pub/parisc/cd-images/palinux-0.5.iso.gz > > - Paul the CD worked great on the 715 I tried, and I actually didn't have a serial console machine, so I used my Palm Pilot and a link cable. Still worked like a charm. How did you get the kernel image into the boot sector of the CD? I'd like to try to build some CD's of the kernels I'm building to test in some mahcines that are not on the same network as the machine that I'm building everything from. And I don't mind posting my CD images somewhere if they work...but most of my testing is on a 735 or 755. Thanks, -- Phillip Beal Electrical and Computer Engineering S+LUG Vice-President From bame@noam.fc.hp.com Wed, 15 Nov 2000 10:08:22 -0700 Date: Wed, 15 Nov 2000 10:08:22 -0700 From: Paul Bame bame@noam.fc.hp.com Subject: [parisc-linux] Help with posix_types.h I'm reviewing the posix_types.h to figure out what's right for 64-bit linux. I know others may have thought through this before so I'm hoping for guidance. For those unfamiliar, the type names in posix_types.h are like __kernel_dev_t and usually are used to define the corresponding "normal" type (dev_t). These should be settled before the 32/64 syscall wrappers can be completed. __kernel_ino_t: often 32 bits, currently 32 bits for parisc and som3 64-bit kernels (mips64 and ia64). 64 bits on alpha and sparc64. Seems to me this ought to be 32 bits on parisc and parisc64, or 64 bits on both, since it's a function of file system sizes not processor width. HPUX kernel seems to always use 32 bits, but 64-bit userspace uses 64 bits. I propose 32 bits on both, but willy had selected 64 bits in parisc64 for some reason. __kernel_off_t: seems to be 32 bits on 32-bit cpus, 64 on 64-bit ones. This is supposedly the offset from a beginning of a file. HPUX appears to use 64-bits *in the kernel* for both 32 and 64-bit kernels. The obvious pattern is to make ours 32 on narrow, and 64 on wide palinux so I guess I propose that, and that's the way it was before I hacked on it too. Should we consider switching to 64 bits on narrow palinux since this is related to file systems, not CPUs. Note there's also a __kernel_loff_t -> loff_t which appears to be defined as 64 bits. I'm not sure how this does/should interact with off_t (lseek vs lseek64 for example). __kernel_suseconds_t: which becomes suseconds_t which is used in struct timeval { time_t tv_sec; /* seconds */ suseconds_t tv_usec; /* microseconds */ }; I'm confused why hpux, and other systems, like for this to be 'long' (e.g., 64 bits on 64-bit processors) since it seems like values over a million are probably rare and 32 bits seems to be enough for most implementations. sparc64 chose 32 bits for this and I want to do the same for parisc64 because it will reduce the amount of syscall structure repackings. Comments? __kernel_daddr_t: which is used indirectly in struct solaris_x86_vtoc and solaris_x86_slice which *might* be an on-disk data structures (used with CONFIG_SOLARIS_X86_PARTITION). So this needs to be 32 bits if that's the case (definition from sparc) and several archs have it 64 bits! On the other hand, HPUX's man page says 'daddr_t used for disk addresses except in an inode [and partition table I would think] on disk'. So it should probably be the same type as off_t. FYI the only other place it's used is in 'struct mtio' -- used to talk to magnetic tape units. I'm guessing the sparc struct should not be using this type, and that we should define it the same as off_t. Comments? From kailasr@webcash.com Wed, 15 Nov 2000 09:55:09 -0800 Date: Wed, 15 Nov 2000 09:55:09 -0800 From: Kailashnath V Rampure kailasr@webcash.com Subject: [parisc-linux] Boot command Yes Thomas the vmlinux is in /boot of 3rd partition as the other partitions are swap and f0. At 11:48 AM 11/15/00 +0100, Thomas Marteau wrote: >----- Original Message ----- >From: Kailashnath V Rampure >To: Paul Bame >Cc: Grant Grundler ; Matt Taggart >; >Sent: Tuesday, November 14, 2000 11:58 PM >Subject: Re: [parisc-linux] Boot command > > > > I have booted HP A class server through network. On that I have >repartioned > > the system and followed the steps on >http://www.parisc-linux.org/install.html. > > I have used the following command to initialize the hard disk. The kernel >I > > have downloaded is vmlinux-20001018. and cpied it to /mnt/boot/vmlinux > > after mounting /dev/sda3. I have used the following command to initialize > > the HDD. > > > > palo -I -k /boot/vmlinux -b /boot/iplboot \ -c '3/boot/vmlinux TERM=linux > > HOME=/ root=/dev/sda3' \ /dev/sda > >This means that vmlinux must be in /boot in your third partition on your >disk. >Is it true in your case? > > > -------------------------------- > > I get the following error: > > -------------------------------- > > SOFT Boot. > > palo ipl bame@noam Tue oct 31 14:18:02 MST 2000 > > 0/vmlinux 2138614 bytes@ 0x1f78c000 > > 0/palo-cmdline '3/boot/vmlinux TERM=linux HOME=/ root=/dev/sda3' > > /dev/ida1 82 62 1030688 > > /dev/ida2 f0 1030750 24738 > > /dev/ida3 83 1055488 1030750 > > Kernel:partition 3 file /boot/vmlinux > > ext2 block size 1024 > > ext2_mount(partition 3) returns 0 > > ext2_open(/boot/vmlinux) = -1 > > open /boot/vmlinux failed > > ------------------------------------- > > Please suggest. > > > > -------------------------------------------------------------------------- >- > > To unsubscribe: send e-mail to parisc-linux-request@thepuffingroup.com >with > > `unsubscribe' as the subject. > > > > From bame@noam.fc.hp.com Wed, 15 Nov 2000 11:05:14 -0700 Date: Wed, 15 Nov 2000 11:05:14 -0700 From: Paul Bame bame@noam.fc.hp.com Subject: [parisc-linux] Beta CD = How did you get the kernel image into the boot = sector of the CD? I'd like to try to build some CD's of the kernels I'm = building to test in some mahcines that are not on the same network as = the machine that I'm building everything from. The magic for making bootable CDs is documented in the PALO README.html which you have on your system already since you're building kernels. -P From marteaut@esiee.fr Wed, 15 Nov 2000 19:10:56 +0100 Date: Wed, 15 Nov 2000 19:10:56 +0100 From: Thomas Marteau marteaut@esiee.fr Subject: [parisc-linux] Boot command Hi again, You put the swap partition before the f0 partition and here it is the f0 partition in first position. Also, your hard disk is ida instead of sda, what's that ? Bye, ESIEE Team ----- Original Message ----- From: Kailashnath V Rampure To: Thomas Marteau Cc: Sent: Wednesday, November 15, 2000 6:55 PM Subject: Re: [parisc-linux] Boot command > Yes Thomas the vmlinux is in /boot of 3rd partition as the other partitions > are swap and f0. > > At 11:48 AM 11/15/00 +0100, Thomas Marteau wrote: > > >----- Original Message ----- > >From: Kailashnath V Rampure > >To: Paul Bame > >Cc: Grant Grundler ; Matt Taggart > >; > >Sent: Tuesday, November 14, 2000 11:58 PM > >Subject: Re: [parisc-linux] Boot command > > > > > > > I have booted HP A class server through network. On that I have > >repartioned > > > the system and followed the steps on > >http://www.parisc-linux.org/install.html. > > > I have used the following command to initialize the hard disk. The kernel > >I > > > have downloaded is vmlinux-20001018. and cpied it to /mnt/boot/vmlinux > > > after mounting /dev/sda3. I have used the following command to initialize > > > the HDD. > > > > > > palo -I -k /boot/vmlinux -b /boot/iplboot \ -c '3/boot/vmlinux TERM=linux > > > HOME=/ root=/dev/sda3' \ /dev/sda > > > >This means that vmlinux must be in /boot in your third partition on your > >disk. > >Is it true in your case? > > > > > -------------------------------- > > > I get the following error: > > > -------------------------------- > > > SOFT Boot. > > > palo ipl bame@noam Tue oct 31 14:18:02 MST 2000 > > > 0/vmlinux 2138614 bytes@ 0x1f78c000 > > > 0/palo-cmdline '3/boot/vmlinux TERM=linux HOME=/ root=/dev/sda3' > > > /dev/ida1 82 62 1030688 > > > /dev/ida2 f0 1030750 24738 > > > /dev/ida3 83 1055488 1030750 > > > Kernel:partition 3 file /boot/vmlinux > > > ext2 block size 1024 > > > ext2_mount(partition 3) returns 0 > > > ext2_open(/boot/vmlinux) = -1 > > > open /boot/vmlinux failed From dave@hiauly1.hia.nrc.ca Wed, 15 Nov 2000 13:09:49 -0500 (EST) Date: Wed, 15 Nov 2000 13:09:49 -0500 (EST) From: John David Anglin dave@hiauly1.hia.nrc.ca Subject: [parisc-linux] Help with posix_types.h The largest disk currently available I believe is the 180GB Seagate Baracuda. The size of drives is increasing about a factor of 2 per year. The __kernel_off_t definitely needs to be 64 bits to handle large drives in both 32 and 64 bit systems. Disk blocks are typically 512 or 1024 bytes. Thus, drives may exceed 4GB disk blocks in 3-4 years. Inodes are variable in size (8KB average). Thus, we are a little further away from exceeding the 32 bit inode limit. Dave -- J. David Anglin dave.anglin@nrc.ca National Research Council of Canada (613) 990-0752 (FAX: 952-6605) From bame@noam.fc.hp.com Wed, 15 Nov 2000 11:12:57 -0700 Date: Wed, 15 Nov 2000 11:12:57 -0700 From: Paul Bame bame@noam.fc.hp.com Subject: [parisc-linux] Boot command = You put the swap partition before the f0 partition and here it is the f0 = partition in first position. The partition order doesn't matter so long as the f0 partition and the partition containing your kernel (an ext2 partition) *end* within the first 2Gb of the disk. See the PALO README.html. = Also, your hard disk is ida instead of sda, what's that ? PALO lists the devices as 'ida' instead of 'sda' or 'hda' since it is using the firmware 'IODC' interface to talk to the boot device, and it has no idea what type of boot device IODC is providing. -P From rhirst@linuxcare.com Wed, 15 Nov 2000 18:48:08 +0000 Date: Wed, 15 Nov 2000 18:48:08 +0000 From: Richard Hirst rhirst@linuxcare.com Subject: [parisc-linux] Single-stepping (Oops, CC-ed to the wrong list first time!) Hi John, I've been helping Alan Modra out with kernel changes to support single stepping for gdb. Paul Bame suggested I bounced our ideas off you in case you (or anyone else) had any comments. I havn't actually committed my changes yet. The basic approach is to use the recovery counter to generate a trap every instruction. The scheme is complicated because a suspended process may or may not return to user space via an RFI. If it was suspended as a result of an interrupt then we can simply set PSW bit R in the tasks saved registers and it will get loaded by the RFI. On every task switch I set the recovery counter to 0, just in case the new process is being single-stepped. If a process is suspended during a syscall, then there is no RFI on the return path to userland, and we have to handle things differently. I have changed the syscall return path such that it loads the recovery counter with 3 before updating the PSW with a value from the tasks saved registers. If that PSW has the R bit set, then the count of 3 will generate a trap on the first instruction following the branch back to user space. Note that PSW wasn't previously restored on the syscall return path. To avoid further complications of interrupts during the three instructions when the recovery counter is decrementing, whenever we set the R bit, we also clear the I bit to disable interrupts. Nullified instructions are handled by the controlling process manually moving the childs IAOQ over the instruction without actually setting it running, because the recovery counter isn't decremented for nullified instructions. I need to do some more testing before committing this, but would welcome any comments on the basic approach taken, areas I have mis-understood, or problems with it that might not yet have occurred to me. Thanks, Richard From andreas@bawue.de Thu, 16 Nov 2000 20:20:41 +0100 Date: Thu, 16 Nov 2000 20:20:41 +0100 From: Andreas Thienemann andreas@bawue.de Subject: [parisc-linux] 250/1 doesn't boot but dumps stack This is a multi-part message in MIME format. --------------F7EF1B69F0A7C4C7DD54E27D Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hi, I recently got a D-Class HP900 250/1 (at least it says that on the label) and tried to get the pa-risc port running on it. So I got a CVS checkout and build the whole toolchain without any major hassles. The kernel, including NFS-ROOT, built also without any glitches. But when I try to boot up this kernel it dumps stack right after initialising the pty interfaces. (I already left out everything unnecessary, such as parallel port support) After that it complains about "Data acces rights fault in kernel: Code=26 regs=c7f98780 (Addr=000000004)" and some more data... For the curious, the boot sequence is attached. I hope someone can give me a clue what might be wrong... Thanks, Andreas --------------F7EF1B69F0A7C4C7DD54E27D Content-Type: text/plain; charset=us-ascii; name="hp9000-capture" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="hp9000-capture" Firmware Version 36.34 Duplex Console IO Dependent Code (IODC) revision 0 ------------------------------------------------------------------------------ (c) Copyright 1995-1998, Hewlett-Packard Company, All rights reserved ------------------------------------------------------------------------------ Processor Speed State Coprocessor State Cache Size --------- -------- --------------------- ----------------- ---------- 0 101 MHz Active Functional 256 KB Central Bus Speed (in MHz) : 101 Available memory (bytes) : 134217728 Good memory required (bytes): 15245312 Primary boot path: 8/16/5.5 (dec) Alternate boot path: 8/16/5.2 (dec) Console path: 8/16/4.0 (dec) Keyboard path: 8/16/7.0 (dec) Processor is booting from first available device. To discontinue, press any key within 10 seconds. Boot terminated. ------- Main Menu ------------------------------------------------------------- Command Description ------- ----------- BOot [PRI|ALT|] Boot from specified path PAth [PRI|ALT|CON|KEY] [] Display or modify a path SEArch [DIsplay|IPL] [] Search for boot devices COnfiguration [] Access Configuration menu/commands INformation [] Access Information menu/commands SERvice [] Access Service menu/commands DIsplay Redisplay the current menu HElp [|] Display help for menu or command RESET Restart the system ------- Main Menu: Enter command > bo 8/16/6.0 Interact with IPL (Y or N)?> n Booting... Network Station Address 0060b0-3c08d4 Boot IO Dependent Code (IODC) revision 2 HARD Booted. palo ipl root@gate.ixs.com Wed Nov 15 14:08:22 CET 2000 0/vmlinux 2143238 bytes @ 0x6800 0/palo-cmdline '0/vmlinux HOME=/ TERM=LINUX root=/dev/nfs nfsroot=192.168.1.1 ' Kernel: partition 0 file /vmlinux ELF32 executable Entry 00100120 first 00100000 n 4 Segment 0 load 00100000 size 1467884 mediaptr 0x1000 Segment 1 load 00268000 size 174520 mediaptr 0x168000 Segment 2 load 00294000 size 103180 mediaptr 0x193000 Segment 3 load 002b0000 size 8192 mediaptr 0x1ad000 branching to kernel entry point 0x00100120 Set default PSW W bit to 0 PDC Console Initialized The 32-bit Kernel has started... Enabled FP coprocessor Free memory starts at: 0xc02dc000 start_parisc(0x504d6c,0x504d6c,0x0,0x0) PALO command line: 'HOME=/ TERM=LINUX root=/dev/nfs nfsroot=192.168.1.1 ' PALO initrd 0-0 model 00005890 00000481 00000000 00000002 778314c3 100000f0 00000004 0000008a 0000008a vers 0000000d cpuid 0000016d CPUID vers 11 rev 13 Searching for devices in PDC firmware... processor hpa 0xfffa0000 a newer box... Found devices: 1. UL 350 Lasi Core BA (11) at 0xffd00000, versions 0x2e, 0x0, 0x81, 0x0, 0x0 2. UL 350 Lasi Core RS-232 (10) at 0xffd05000, versions 0x2e, 0x0, 0x8c, 0x0, 0x0 3. UL 350 Core SCSI (10) at 0xffd06000, versions 0x2e, 0x0, 0x82, 0x0, 0x80 4. UL 350 Core LAN (802.3) (10) at 0xffd07000, versions 0x2e, 0x0, 0x8a, 0x0, 0x0 5. UL 350 Core Centronics (10) at 0xffd02000, versions 0x2e, 0x0, 0x74, 0x0, 0x0 6. UL 350 Core PC Keyboard (10) at 0xffd08000, versions 0x2e, 0x0, 0x84, 0x0, 0x0 7. UL 350 Core PC Keyboard (10) at 0xffd08100, versions 0x2e, 0x0, 0x84, 0x0, 0x0 8. UL 350 Core PC Floppy (10) at 0xffd0a000, versions 0x2e, 0x0, 0x83, 0x0, 0x0 9. UL 350 Core Wax BA (11) at 0xffe00000, versions 0x30, 0x0, 0x8e, 0x0, 0x0 10. UL 350 Wax EISA BA (11) at 0xfc000000, versions 0x30, 0x0, 0x90, 0x0, 0x0 11. UL 350 Wax Core RS-232 (10) at 0xffe02000, versions 0x30, 0x0, 0x8c, 0x0, 0x0 That's a total of 11 devices. No CPUs reported by firmware - probing... Found CPU at fffa0000 CPU(s): 1 x PA7200 (PCX-T') at 101.000000 MHz Linux version 2.4.0-test10 (root@gate.ixs.com) (gcc version 2.96 20000925 (experimental)) #4 Wed Nov 15 19:06:49 CET 2000 free_bootmem(0x2dd000, 0x7d23000) pagetable_init On node 0 totalpages: 32768 zone(0): 16384 pages. zone(1): 16384 pages. zone(2): 0 pages. Kernel command line: HOME=/ TERM=LINUX root=/dev/nfs nfsroot=192.168.1.1 trap_init Calibrating delay loop... 100.76 BogoMIPS Memory: 125568k available Dentry-cache hash table entries: 16384 (order: 5, 131072 bytes) Buffer-cache hash table entries: 8192 (order: 3, 32768 bytes) Page-cache hash table entries: 32768 (order: 5, 131072 bytes) Inode-cache hash table entries: 8192 (order: 4, 65536 bytes) POSIX conformance testing by UNIFIX Lasi version 0 at 0xffd00000 found. Wax at 0xffe00000 found. Wax: HIL Keyboard-NMI registered. parport0: PC-style at 0xffd02800, irq 88 [PCSPP,TRISTATE] Found i82596 at 0xffd07000, IRQ 87 early initialization of device eth0 is deferred Initializing Lasi PS/2-keyboard port at 0xffd08000... Support for Lasi PS/2-psaux not yet available ! Linux NET4.0 for Linux 2.4 Based upon Swansea University Computer Society NET3.039 Starting kswapd v1.8 pty: 256 Unix98 ptys configured lp0: using parport0 (interrupt-driven). Dumping Stack from c7f98000 to c7f989c0: 8000 00000000 00000040 00000000 00000000 c027c32c 00000000 00000000 ffffffff 8020 00000001 00000000 00000000 00000000 00000000 00000000 ffffffff c027c244 8040 c027c244 00000031 c7f90000 c02b0000 c028160c 00000000 00000000 00000000 8060 00000000 00000000 00000000 00000001 00000000 00000000 00000000 00000000 8080 00000000 c02b0000 c02b0000 c7f84000 00000000 00000000 c7f84098 c02b0098 80a0 00000000 c02cba18 00000000 c7f980ac c7f980ac c7f980b4 c01177f4 c7f98908 80c0 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 80e0 00000000 00000000 c7f98000 c011a5e4 00000000 0000000f 00000000 00000000 8100 00000024 00000000 00000033 00000000 00000000 00000000 00000000 00000000 8120 00000000 80000000 00000000 00000000 00000000 00000000 00000000 00000000 8140 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 8160 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 8180 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 81a0 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 81c0 00000000 00000000 00000000 fffffeff 00000000 ffffffff 00000000 c027ceb8 81e0 ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff 00800000 05000000 8200 00000000 ffffffff ffffffff ffffffff 00000800 00000800 00000400 00000400 8220 ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff 00007377 61707065 8240 72000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 8260 00008000 c0269000 c0269000 c013de10 00010000 c7ffeba0 c022248c c0234898 8280 000000f0 c02db000 00000000 c0118cf0 c0269054 00008000 c0269000 c0269054 82a0 f0000068 f0000070 c027c000 c027c368 0000000b 00000024 0000003c 0000003e 82c0 c027c000 00000000 c01001dc 00000004 00000000 00000023 c02b61ef 00000000 82e0 c027c000 f0000070 f0000068 000000ff ffd05800 ffd05800 ffd05800 00000060 8300 ffffffff ffd05800 002b50c0 c0268000 00000000 00000000 c02b08c0 00000000 8320 000b0800 00000000 0000001f 00000000 0000001f 00000000 0000001f 00000000 8340 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 8360 00000010 00000020 7f7fffff ffffffff 43ebebeb e0000000 00000000 00000000 8380 45e69c6a 25b7ea20 41800000 00000000 00000010 00000010 00000000 00000000 83a0 00000040 00000080 00000100 00000200 00000400 00000800 7fffffff 7fffffff 83c0 41000000 00000000 7fffffff 7fffffff 40800000 00000000 41000000 00000000 83e0 40300000 00000000 40200000 00000000 40200000 00000000 41800000 7fffffff 8400 40000000 00000000 40000000 00000000 40800000 00000000 41000000 00000000 8420 00000000 00000000 c7f98800 c0103cf4 00000000 00000000 00000000 00000000 8440 00000000 00000000 c0118ce0 c0118ce4 40800000 00000000 00282000 00000000 8460 c0281040 c0281064 00000000 c0281204 00000000 00000000 00000000 c7f98478 8480 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 84a0 00000000 00000000 71894dcb e3642ec4 c6c85d89 8d90bb13 1b217627 3634591c 84c0 6c1e076a d84abb86 b095770d 612aee1b c2236964 8446d2c9 088da593 116dfe74 84e0 22ad49ba 452c2626 8a2ef91e c0103c48 28cd5128 51ec1702 a3ae9b56 475d36ad 8500 c7f98000 c028160c 00000000 76fd1fb2 ed8c8a36 db19146d b63228db 6c6451b7 8520 d8be163c b17c2c79 62f858f3 c01001f0 8b0c0969 161812d3 2c4690f4 58fb94ba 8540 b1819c26 6303384d c670c5c8 8ce18b91 19c31723 33f09b14 6797837a cf59b3a6 8560 9eb3674d 3d66ce9b 7abb2864 c0294ef4 ea01cb35 d403966b a8072cd7 500e59af 8580 00000000 c02b0000 81dead60 03bd5ac1 00000060 c027c35c c027c35c c025920c 85a0 7234ad2e e41fef0e c83fde1d c0294ea0 20ff7877 418845bc 83663e2a 06cc7c55 85c0 c02ad30c c02ad2cc 00000000 00000000 00000000 c7f985d4 c7f985d4 c7f985dc 85e0 c7f985dc c7f985e4 00000000 c0298ca0 00000000 c7f985d4 c7f985d4 c7f985dc 8600 c027e800 00000000 00000000 00000000 000000fa 000000f2 000000ff c0295514 8620 000000f0 c02cb800 c02b06c0 c0299814 c028160c c02ad30c c02ad2bc c028160c 8640 c02b06c0 c7f98000 c028160c c02ad30c c02ad2d0 c7f94800 c0230add 0000003e 8660 c027c000 00000001 c02b6206 c0299744 c02b61ce 00000037 c02b6206 00000000 8680 c02ad30c c02ad2d0 00000040 c02cb800 000000fa 000000f2 000000ff c0295514 86a0 000000f0 c02cb800 c02b06c0 c02a4af4 c028160c c02ad30c c02ad2d0 c7f98000 86c0 c028b800 c01e2468 ffffffff c028b1e4 c7ffc400 c028160c c024256c c0186688 86e0 c028160c c02c6104 c01e2468 c029c4e0 c028b310 c028b1b4 c7f988c0 00000000 8700 ffffffff 0000ffe0 0060b03c 08d4bcfc 00000000 00000008 c0295514 000000f0 8720 c02cb800 c028b800 c01e2468 ffffffff c028b1e4 c7ffc400 c02bfc1c c02bfe50 8740 00000063 00000008 c7f98718 c024256c 00000000 c0285038 c028b1b9 c0242340 8760 45e69c6a 25b7ea20 41800000 c029c248 00000010 00000010 00000000 00000000 8780 0004000b c02ca800 c029c248 00000000 c7ffc400 ffffffff c01e2468 c028b800 87a0 c02cb800 000000f0 00000000 000000ff 000000f2 000000fa 000000fd f0100000 87c0 f0001180 f0000070 f0000068 00000000 c7f9870e 00000002 c029c4d0 ffd07000 87e0 c7f98710 00000f20 00000000 c0268000 00000001 00000000 c7f989c0 002b31b8 8800 000b0800 00000000 0000001f 00000000 0000001f 00000000 0000001f 00000000 8820 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 8840 00000010 00000020 7f7fffff ffffffff 43ebebeb e0000000 00000000 00000000 8860 45e69c6a 25b7ea20 41800000 00000000 00000010 00000010 00000000 00000000 8880 00000040 00000080 00000100 00000200 00000400 00000800 7fffffff 7fffffff 88a0 41000000 00000000 7fffffff 7fffffff 40800000 00000000 41000000 00000000 88c0 40300000 00000000 40200000 00000000 40200000 00000000 41800000 7fffffff 88e0 40000000 00000000 40000000 00000000 40800000 00000000 41000000 00000000 8900 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 8920 00000000 00000000 c029c264 c029c268 00000000 00000000 c7f98b00 00000000 8940 00000000 00000000 0000001f 00000000 0000001f 0e681096 00000000 00000004 8960 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 8980 00000010 00000020 7f7fffff ffffffff 43ebebeb e0000000 00000000 00000000 89a0 45e69c6a 25b7ea20 41800000 c01046e0 00000010 00000010 00000000 00000000 Data access rights fault in kernel: Code=26 regs=c7f98780 (Addr=00000004) YZrvWESTHLNXBCVMcbcbcbcbOGFRQPDI PSW: 00000000000001000000000000001011 r0-3 00000000 c02ca800 c029c248 00000000 r4-7 c7ffc400 ffffffff c01e2468 c028b800 r8-11 c02cb800 000000f0 00000000 000000ff r12-15 000000f2 000000fa 000000fd f0100000 r16-19 f0001180 f0000070 f0000068 00000000 r20-23 c7f9870e 00000002 c029c4d0 ffd07000 r24-27 c7f98710 00000f20 00000000 c0268000 r28-31 00000001 00000000 c7f989c0 002b31b8 sr0-4 00000000 00000000 00000000 00000000 sr4-8 00000000 00000000 00000000 00000000 IASQ: 00000000 00000000 IAOQ: c029c264 c029c268 IIR: 0e681096 ISR: 00000000 IOR: 00000004 ORIG_R28: 00000000 --------------F7EF1B69F0A7C4C7DD54E27D-- From ixs@ixs.bb.bawue.de Wed, 15 Nov 2000 20:28:28 +0100 (CET) Date: Wed, 15 Nov 2000 20:28:28 +0100 (CET) From: Andreas Thienemann ixs@ixs.bb.bawue.de Subject: [parisc-linux] 250/1 doesn't boot but dumps stack Hi again, just to clear something up: On Thu, 16 Nov 2000, Andreas Thienemann wrote: > the pty interfaces. (I already left out everything unnecessary, such as > parallel port support) I just noticed I attached the wrong file. The attached bootlog was from a kernel that still had support for lp0. But with another kernel, this time without lp support, this errors were the same... bye, Andreas From kailasr@webcash.com Wed, 15 Nov 2000 11:26:30 -0800 Date: Wed, 15 Nov 2000 11:26:30 -0800 From: Kailashnath V Rampure kailasr@webcash.com Subject: [parisc-linux] Boot command Thomas, I mounted the /dev/sda3 on mnt and deleted every thing and recopied then rebooted. It worked. Probably there was some fault while I copied yesterday. I did not repartition the disk now. Thanks Regards Kailas At 07:10 PM 11/15/00 +0100, Thomas Marteau wrote: >Hi again, > > You put the swap partition before the f0 partition and here it is the f0 >partition in first position. > Also, your hard disk is ida instead of sda, what's that ? > >Bye, > >ESIEE Team >----- Original Message ----- >From: Kailashnath V Rampure >To: Thomas Marteau >Cc: >Sent: Wednesday, November 15, 2000 6:55 PM >Subject: Re: [parisc-linux] Boot command > > > > Yes Thomas the vmlinux is in /boot of 3rd partition as the other >partitions > > are swap and f0. > > > > At 11:48 AM 11/15/00 +0100, Thomas Marteau wrote: > > > > >----- Original Message ----- > > >From: Kailashnath V Rampure > > >To: Paul Bame > > >Cc: Grant Grundler ; Matt Taggart > > >; > > >Sent: Tuesday, November 14, 2000 11:58 PM > > >Subject: Re: [parisc-linux] Boot command > > > > > > > > > > I have booted HP A class server through network. On that I have > > >repartioned > > > > the system and followed the steps on > > >http://www.parisc-linux.org/install.html. > > > > I have used the following command to initialize the hard disk. The >kernel > > >I > > > > have downloaded is vmlinux-20001018. and cpied it to /mnt/boot/vmlinux > > > > after mounting /dev/sda3. I have used the following command to >initialize > > > > the HDD. > > > > > > > > palo -I -k /boot/vmlinux -b /boot/iplboot \ -c '3/boot/vmlinux >TERM=linux > > > > HOME=/ root=/dev/sda3' \ /dev/sda > > > > > >This means that vmlinux must be in /boot in your third partition on your > > >disk. > > >Is it true in your case? > > > > > > > -------------------------------- > > > > I get the following error: > > > > -------------------------------- > > > > SOFT Boot. > > > > palo ipl bame@noam Tue oct 31 14:18:02 MST 2000 > > > > 0/vmlinux 2138614 bytes@ 0x1f78c000 > > > > 0/palo-cmdline '3/boot/vmlinux TERM=linux HOME=/ root=/dev/sda3' > > > > /dev/ida1 82 62 1030688 > > > > /dev/ida2 f0 1030750 24738 > > > > /dev/ida3 83 1055488 1030750 > > > > Kernel:partition 3 file /boot/vmlinux > > > > ext2 block size 1024 > > > > ext2_mount(partition 3) returns 0 > > > > ext2_open(/boot/vmlinux) = -1 > > > > open /boot/vmlinux failed From bame@noam.fc.hp.com Wed, 15 Nov 2000 12:34:48 -0700 Date: Wed, 15 Nov 2000 12:34:48 -0700 From: Paul Bame bame@noam.fc.hp.com Subject: [parisc-linux] Help with posix_types.h FYI I just heard some pretty good reasons why both ino_t and off_t should be 64 bits even on 32-bit kernels. Keep those cards and letters coming! -P From grundler@cup.hp.com Wed, 15 Nov 2000 11:23:41 -0800 Date: Wed, 15 Nov 2000 11:23:41 -0800 From: Grant Grundler grundler@cup.hp.com Subject: [parisc-linux] 250/1 doesn't boot but dumps stack Andreas Thienemann wrote: > But when I try to boot up this kernel it dumps stack right after initialising > the pty interfaces. (I already left out everything unnecessary, such as > parallel port support) ... > parport0: PC-style at 0xffd02800, irq 88 [PCSPP,TRISTATE] > Found i82596 at 0xffd07000, IRQ 87 > early initialization of device eth0 is deferred > Initializing Lasi PS/2-keyboard port at 0xffd08000... > Support for Lasi PS/2-psaux not yet available ! > Linux NET4.0 for Linux 2.4 > Based upon Swansea University Computer Society NET3.039 > Starting kswapd v1.8 > pty: 256 Unix98 ptys configured > lp0: using parport0 (interrupt-driven). Are you sure you left out parallel port support? > Data access rights fault in kernel: Code=26 regs=c7f98780 (Addr=00000004) > > YZrvWESTHLNXBCVMcbcbcbcbOGFRQPDI > PSW: 00000000000001000000000000001011 > r0-3 00000000 c02ca800 c029c248 00000000 > r4-7 c7ffc400 ffffffff c01e2468 c028b800 > r8-11 c02cb800 000000f0 00000000 000000ff > r12-15 000000f2 000000fa 000000fd f0100000 > r16-19 f0001180 f0000070 f0000068 00000000 > r20-23 c7f9870e 00000002 c029c4d0 ffd07000 > r24-27 c7f98710 00000f20 00000000 c0268000 > r28-31 00000001 00000000 c7f989c0 002b31b8 > sr0-4 00000000 00000000 00000000 00000000 > sr4-8 00000000 00000000 00000000 00000000 > > IASQ: 00000000 00000000 IAOQ: c029c264 c029c268 > IIR: 0e681096 ISR: 00000000 IOR: 00000004 > ORIG_R28: 00000000 Smells like a driver bug. Can you look up IOAQ and GR2 (c029c264 and c029c248) in System.map file? grant From dave@hiauly1.hia.nrc.ca Wed, 15 Nov 2000 14:49:02 -0500 (EST) Date: Wed, 15 Nov 2000 14:49:02 -0500 (EST) From: John David Anglin dave@hiauly1.hia.nrc.ca Subject: [parisc-linux] Single-stepping > I've been helping Alan Modra out with kernel changes to support > single stepping for gdb. Paul Bame suggested I bounced our ideas > off you in case you (or anyone else) had any comments. I havn't > actually committed my changes yet. > > The basic approach is to use the recovery counter to generate > a trap every instruction. The scheme is complicated because a > suspended process may or may not return to user space via an RFI. I really don't know enough to comment on the implementation choice. Why did you decide on this approach as opposed to inserting breaks and enabling the taken branch branch trap (T)? It would appear that the recovery counter was intended to provide software recovery from hardware faults in fault tolerant systems. Possibly, Grant could comment on whether it is actually useful for this purpose. Dave -- J. David Anglin dave.anglin@nrc.ca National Research Council of Canada (613) 990-0752 (FAX: 952-6605) From j-perdue@tamu.edu Wed, 15 Nov 2000 13:53:03 -0600 Date: Wed, 15 Nov 2000 13:53:03 -0600 From: Jack Perdue j-perdue@tamu.edu Subject: [parisc-linux] nfsroot - 712/60 - RPC - help Howdy Puffins and others, I have a 712/60 here that I bought for the purpose of playing with PARISC linux. It came w/HP-UX 9.0 which I don't want to wax just yet (e.g. for ioscan and other HP-UX utils). I don't have a CD for it, so I've been trying to get NFSROOT to work. The 712/60 is known as pancho. The bootp server is named blacktower. I've unzipped nfsroot-20000804.tgz as /tftpboot/pancho and exported it to the local net. I can mount it from an i386 RH6.2 box, but I think I'm having problems accessing it from PA-RISC linux. Below are some of my config files, the output from bootp and two attempts at booting the 712/60... one with debugging turned on in net/sunrpc/sysctl.c. I'm kinda stumped. Can anyone see where I've gone wrong? Some notes: a) I've tried NFSROOT=192.168.1.11 and NFSROOT=192.168.1.11/tftpboot/vmlinux in palo/Makefile and the results are the same (both suggestions were made to this list at some point) b) I tried the APRICOT drivers, but the kernel would never see the net interface so I've switched to the LASI_82596 driver (doing both resulted in dupe symbols). The LASI driver seems to get much further. c) my sources were updated today from the puffin's CVS tree. The kernel booting below was built on those sources. d) with debugging on, I get: Root-NFS: Unable to get nfsd port number from server, using default Root-NFS: Portmapper on server returned 2049 as nfsd port however, with the debugging off, I only get: Root-NFS: Unable to get nfsd port number from server, using default portmap and rpc.mountd are running on blacktower. Why the conflicting report when debug is on? e) the final message in /var/log/messages is always "tftpd: read: Connection refused". My hosts.allow and hosts.deny files are empty so they shouldn't be the problem. And, as mentioned I can NFS mount the directory. Is this the problem and if so, what is the solution??? Any help on how I can resolve this problem is appreciated. TIA, jack j-perdue@tamu.edu ========== blacktower:/etc/exports ========== /tftpboot/pancho 192.168.1.0/255.255.255.0(rw,no_root_squash) ========== blacktower:/etc/bootptab ========== pancho:\ :hd=/tftpboot:\ :bf=vmlinux:\ :ht=ether:\ :ha=08000993DA02:\ :sm=255.255.255.0:\ :hn:\ :ip=192.168.1.13:\ :vm=rfc1048: ========== bootpd output ========== [root@blacktower rc.d]# /usr/sbin/bootpd -d 20 bootpd: info(6): bootptab mtime: Wed Nov 15 13:02:44 2000 bootpd: info(6): reading "/etc/bootptab" bootpd: info(6): read 1 entries (1 hosts) from "/etc/bootptab" bootpd: info(6): recvd pkt from IP addr 0.0.0.0 bootpd: info(6): bootptab mtime: Wed Nov 15 13:02:44 2000 bootpd: info(6): request from Ethernet address 08:00:09:93:DA:02 bootpd: info(6): found 192.168.1.13 (pancho) bootpd: info(6): bootfile="/tftpboot/vmlinux" bootpd: info(6): vendor magic field is 99.130.83.99 bootpd: info(6): sending reply (with RFC1048 options) bootpd: info(6): setarp 192.168.1.13 - 08:00:09:93:DA:02 bootpd: info(6): recvd pkt from IP addr 0.0.0.0 bootpd: info(6): bootptab mtime: Wed Nov 15 13:02:44 2000 bootpd: info(6): request from Ethernet address 08:00:09:93:DA:02 bootpd: info(6): found 192.168.1.13 (pancho) bootpd: info(6): bootfile="/tftpboot/vmlinux" bootpd: info(6): vendor magic field is 99.130.83.99 bootpd: info(6): request message length=364 bootpd: info(6): extended reply, length=364, options=128 bootpd: info(6): sending reply (with RFC1048 options) bootpd: info(6): setarp 192.168.1.13 - 08:00:09:93:DA:02 ========== from /var/log/messages ========== Nov 15 13:02:20 blacktower bootpd[1320]: version 2.4.3 Nov 15 13:02:20 blacktower bootpd[1320]: bootptab mtime: Wed Oct 12 00:41:28 1994 Nov 15 13:02:20 blacktower bootpd[1320]: reading "/etc/bootptab" Nov 15 13:02:20 blacktower bootpd[1320]: read 1 entries (1 hosts) from "/etc/bootptab" Nov 15 13:02:47 blacktower bootpd[1323]: version 2.4.3 Nov 15 13:02:47 blacktower bootpd[1323]: bootptab mtime: Wed Nov 15 13:02:44 2000 Nov 15 13:02:47 blacktower bootpd[1323]: reading "/etc/bootptab" Nov 15 13:02:47 blacktower bootpd[1323]: read 1 entries (1 hosts) from "/etc/bootptab" Nov 15 13:04:34 blacktower bootpd[1323]: recvd pkt from IP addr 0.0.0.0 Nov 15 13:04:34 blacktower bootpd[1323]: bootptab mtime: Wed Nov 15 13:02:44 2000 Nov 15 13:04:34 blacktower bootpd[1323]: request from Ethernet address 08:00:09:93:DA:02 Nov 15 13:04:34 blacktower bootpd[1323]: found 192.168.1.13 (pancho) Nov 15 13:04:34 blacktower bootpd[1323]: bootfile="/tftpboot/vmlinux" Nov 15 13:04:34 blacktower bootpd[1323]: vendor magic field is 99.130.83.99 Nov 15 13:04:34 blacktower bootpd[1323]: sending reply (with RFC1048 options) Nov 15 13:04:34 blacktower bootpd[1323]: setarp 192.168.1.13 - 08:00:09:93:DA:02 Nov 15 13:04:35 blacktower tftpd[1325]: tftpd: trying to get file: /tftpboot/vmlinux Nov 15 13:04:36 blacktower tftpd[1327]: tftpd: trying to get file: /tftpboot/vmlinux Nov 15 13:04:47 blacktower bootpd[1323]: recvd pkt from IP addr 0.0.0.0 Nov 15 13:04:47 blacktower bootpd[1323]: bootptab mtime: Wed Nov 15 13:02:44 2000 Nov 15 13:04:47 blacktower bootpd[1323]: request from Ethernet address 08:00:09:93:DA:02 Nov 15 13:04:47 blacktower bootpd[1323]: found 192.168.1.13 (pancho) Nov 15 13:04:47 blacktower bootpd[1323]: bootfile="/tftpboot/vmlinux" Nov 15 13:04:47 blacktower bootpd[1323]: vendor magic field is 99.130.83.99 Nov 15 13:04:47 blacktower bootpd[1323]: request message length=364 Nov 15 13:04:47 blacktower bootpd[1323]: extended reply, length=364, options=128 Nov 15 13:04:47 blacktower bootpd[1323]: sending reply (with RFC1048 options) Nov 15 13:04:47 blacktower bootpd[1323]: setarp 192.168.1.13 - 08:00:09:93:DA:02 Nov 15 13:04:53 blacktower tftpd[1327]: tftpd: read: Connection refused ========== console output (no RPC debug) ========== ---------------------------------------------------------------------------- BootRom Version 1.5 Memory Size: 32 MB ---------------------------------------------------------------------------- (c) Copyright 1990-1993, Hewlett-Packard Company. All rights reserved Press to stop boot sequence. Selecting a system to boot. Booting palo ipl jkp2866@redtower Wed Nov 15 12:44:21 CST 2000 0/vmlinux 1606438 bytes @ 0x6800 0/palo-cmdline '0/vmlinux HOME=/ TERM=LINUX root=/dev/nfs nfsroot=192.68.1.11:/tftpboot/pancho ' Kernel: partition 0 file /vmlinux ELF32 executable Entry 00100000 first 00100000 n 4 Segment 0 load 00100000 size 1097900 mediaptr 0x1000 Segment 1 load 0020e000 size 150520 mediaptr 0x10e000 Segment 2 load 00234000 size 55900 mediaptr 0x133000 Segment 3 load 00244000 size 8192 mediaptr 0x141000 branching to kernel entry point 0x00100000 Set default PSW W bit to 0 PDC Console Initialized The 32-bit Kernel has started... Enabled FP coprocessor Free memory starts at: 0xc026e000 start_parisc(0x504d6c,0x504d6c,0x0,0x0) PALO command line: 'HOME=/ TERM=LINUX root=/dev/nfs nfsroot=192.68.1.11:/tftpboot/pancho ' PALO initrd 0-0 model 00006000 00000481 00000000 00000000 77564139 00000000 00000004 00000072 00000072 vers 0000000a CPUID vers 0 rev 0 Searching for devices in PDC firmware... processor hpa 0xfffbe000 an older box... Found devices: 1. Gecko GSC Core Graphics (10) at 0xf8000000, versions 0x16, 0x0, 0x85, 0x0, 0x0 2. Gecko Core BA (11) at 0xf0100000, versions 0x16, 0x0, 0x81, 0x0, 0x0 3. Gecko Core SCSI (10) at 0xf0106000, versions 0x16, 0x0, 0x82, 0x0, 0x0 4. Gecko Core Lan (802.3) (10) at 0xf0107000, versions 0x16, 0x0, 0x8a, 0x0, 0x0 5. Gecko Core RS-232 (10) at 0xf0105000, versions 0x16, 0x0, 0x8c, 0x0, 0x0 6. Gecko Core Centronics (10) at 0xf0102000, versions 0x16, 0x0, 0x74, 0x0, 0x0 7. Gecko Audio (10) at 0xf0104000, versions 0x16, 0x0, 0x7b, 0x0, 0x0 8. Gecko Core PC Floppy (10) at 0xf010a000, versions 0x16, 0x0, 0x83, 0x0, 0x0 9. Gecko Core PC Keyboard (10) at 0xf0108000, versions 0x16, 0x0, 0x84, 0x0, 0x0 10. Gecko Core PC Keyboard (10) at 0xf0108100, versions 0x16, 0x0, 0x84, 0x0, 0x0 11. Gecko (712/60) (0) at 0xfffbe000, versions 0x600, 0x0, 0x4, 0x0, 0x81 12. Gecko (1) at 0xfffbf000, versions 0x26, 0x0, 0x9, 0x0, 0x0 That's a total of 12 devices. CPU(s): 1 x PA7100LC (PCX-L) at 60.000000 MHz Linux version 2.4.0-test10 (jkp2866@redtower) (gcc version 2.96 20000925 (experimental)) #16 Wed Nov 15 14:01:38 CST 2000 free_bootmem(0x26e400, 0x1d91c00) pagetable_init On node 0 totalpages: 8192 zone(0): 4096 pages. zone(1): 4096 pages. zone(2): 0 pages. Kernel command line: HOME=/ TERM=LINUX root=/dev/nfs nfsroot=192.68.1.11:/tftpboot/pancho trap_init Calibrating delay loop... 59.80 BogoMIPS Memory: 29632k available Dentry-cache hash table entries: 4096 (order: 3, 32768 bytes) Buffer-cache hash table entries: 1024 (order: 0, 4096 bytes) Page-cache hash table entries: 8192 (order: 3, 32768 bytes) Inode-cache hash table entries: 2048 (order: 2, 16384 bytes) POSIX conformance testing by UNIFIX Lasi version 0 at 0xf0100000 found. Found i82596 at 0xf0107000, IRQ 87 early initialization of device eth0 is deferred Linux NET4.0 for Linux 2.4 Based upon Swansea University Computer Society NET3.039 Starting kswapd v1.8 pty: 256 Unix98 ptys configured eth0: 82596 at 0xf0107000, 08 00 09 93 DA 02 IRQ 87. 82596.c $Revision: 1.14 $ Serial driver version 5.02 (2000-08-09) with MANY_PORTS SHARE_IRQ SERIAL_PCI enabled ttyS00 at iomem 0xf0105800 (irq = 90) is a 16550A NET4: Linux TCP/IP 1.0 for NET4.0 IP Protocols: ICMP, UDP, TCP IP: routing cache hash table of 512 buckets, 4Kbytes TCP: Hash tables configured (established 2048 bind 2048) eth0: link ok. Sending BOOTP requests.... OK IP-Config: Got BOOTP answer from 192.168.1.11, my address is 192.168.1.13 Switching from PDC console kmem_create: Forcing size word alignment - nfs_fh Looking up port of RPC 100003/2 on 192.68.1.11 RPC: sendmsg returned error 229 portmap: RPC call returned error 229 Root-NFS: Unable to get nfsd port number from server, using default Looking up port of RPC 100005/2 on 192.68.1.11 RPC: sendmsg returned error 229 portmap: RPC call returned error 229 Root-NFS: Unable to get mountd port number from server, using default RPC: sendmsg returned error 229 mount: RPC call returned error 229 Root-NFS: Server returned error -229 while mounting /tftpboot/pancho VFS: Unable to mount root fs via NFS, trying floppy. VFS: Cannot open root device "nfs" or 02:00 Please append a correct "root=" boot option Kernel panic: VFS: Unable to mount root fs on 02:00 ========== console output (with RPC debug) ========== ---------------------------------------------------------------------------- BootRom Version 1.5 Memory Size: 32 MB ---------------------------------------------------------------------------- (c) Copyright 1990-1993, Hewlett-Packard Company. All rights reserved Press to stop boot sequence. Selecting a system to boot. Booting palo ipl jkp2866@redtower Wed Nov 15 12:44:21 CST 2000 0/vmlinux 1606438 bytes @ 0x6800 0/palo-cmdline '0/vmlinux HOME=/ TERM=LINUX root=/dev/nfs nfsroot=192.68.1.11:/tftpboot/pancho ' Kernel: partition 0 file /vmlinux ELF32 executable Entry 00100000 first 00100000 n 4 Segment 0 load 00100000 size 1097900 mediaptr 0x1000 Segment 1 load 0020e000 size 150520 mediaptr 0x10e000 Segment 2 load 00234000 size 55900 mediaptr 0x133000 Segment 3 load 00244000 size 8192 mediaptr 0x141000 branching to kernel entry point 0x00100000 Set default PSW W bit to 0 PDC Console Initialized The 32-bit Kernel has started... Enabled FP coprocessor Free memory starts at: 0xc026e000 start_parisc(0x504d6c,0x504d6c,0x0,0x0) PALO command line: 'HOME=/ TERM=LINUX root=/dev/nfs nfsroot=192.68.1.11:/tftpboot/pancho ' PALO initrd 0-0 model 00006000 00000481 00000000 00000000 77564139 00000000 00000004 00000072 00000072 vers 0000000a CPUID vers 0 rev 0 Searching for devices in PDC firmware... processor hpa 0xfffbe000 an older box... Found devices: 1. Gecko GSC Core Graphics (10) at 0xf8000000, versions 0x16, 0x0, 0x85, 0x0, 0x0 2. Gecko Core BA (11) at 0xf0100000, versions 0x16, 0x0, 0x81, 0x0, 0x0 3. Gecko Core SCSI (10) at 0xf0106000, versions 0x16, 0x0, 0x82, 0x0, 0x0 4. Gecko Core Lan (802.3) (10) at 0xf0107000, versions 0x16, 0x0, 0x8a, 0x0, 0x0 5. Gecko Core RS-232 (10) at 0xf0105000, versions 0x16, 0x0, 0x8c, 0x0, 0x0 6. Gecko Core Centronics (10) at 0xf0102000, versions 0x16, 0x0, 0x74, 0x0, 0x0 7. Gecko Audio (10) at 0xf0104000, versions 0x16, 0x0, 0x7b, 0x0, 0x0 8. Gecko Core PC Floppy (10) at 0xf010a000, versions 0x16, 0x0, 0x83, 0x0, 0x0 9. Gecko Core PC Keyboard (10) at 0xf0108000, versions 0x16, 0x0, 0x84, 0x0, 0x0 10. Gecko Core PC Keyboard (10) at 0xf0108100, versions 0x16, 0x0, 0x84, 0x0, 0x0 11. Gecko (712/60) (0) at 0xfffbe000, versions 0x600, 0x0, 0x4, 0x0, 0x81 12. Gecko (1) at 0xfffbf000, versions 0x26, 0x0, 0x9, 0x0, 0x0 That's a total of 12 devices. CPU(s): 1 x PA7100LC (PCX-L) at 60.000000 MHz Linux version 2.4.0-test10 (jkp2866@redtower) (gcc version 2.96 20000925 (experimental)) #15 Wed Nov 15 13:48:41 CST 2000 free_bootmem(0x26e400, 0x1d91c00) pagetable_init On node 0 totalpages: 8192 zone(0): 4096 pages. zone(1): 4096 pages. zone(2): 0 pages. Kernel command line: HOME=/ TERM=LINUX root=/dev/nfs nfsroot=192.68.1.11:/tftpboot/pancho trap_init Calibrating delay loop... 59.80 BogoMIPS Memory: 29632k available Dentry-cache hash table entries: 4096 (order: 3, 32768 bytes) Buffer-cache hash table entries: 1024 (order: 0, 4096 bytes) Page-cache hash table entries: 8192 (order: 3, 32768 bytes) Inode-cache hash table entries: 2048 (order: 2, 16384 bytes) POSIX conformance testing by UNIFIX Lasi version 0 at 0xf0100000 found. Found i82596 at 0xf0107000, IRQ 87 early initialization of device eth0 is deferred Linux NET4.0 for Linux 2.4 Based upon Swansea University Computer Society NET3.039 Starting kswapd v1.8 pty: 256 Unix98 ptys configured eth0: 82596 at 0xf0107000, 08 00 09 93 DA 02 IRQ 87. 82596.c $Revision: 1.14 $ Serial driver version 5.02 (2000-08-09) with MANY_PORTS SHARE_IRQ SERIAL_PCI enabled ttyS00 at iomem 0xf0105800 (irq = 90) is a 16550A NET4: Linux TCP/IP 1.0 for NET4.0 IP Protocols: ICMP, UDP, TCP IP: routing cache hash table of 512 buckets, 4Kbytes TCP: Hash tables configured (established 2048 bind 2048) eth0: link ok. Sending BOOTP requests.... OK IP-Config: Got BOOTP answer from 192.168.1.11, my address is 192.168.1.13 Switching from PDC console kmem_create: Forcing size word alignment - nfs_fh RPC: registering /proc/net/rpc RPC: registering /proc/net/rpc/nfs Looking up port of RPC 100003/2 on 192.68.1.11 RPC: rpc_getport_external(192.68.1.11, 100003, 2, 17) RPC: xprt_create_proto called RPC: xprt_create_socket(udp 17) RPC: setting up UDP transport... RPC: created transport c1fa4000 RPC: creating portmap client for 192.68.1.11 (xprt c1fa4000) RPC: allocated buffer c1faa5a0 RPC: creating NULL authenticator for client c1faa5a0 RPC: allocated buffer c1fe6460 RPC: 0 new task procpid 1 RPC: 0 looking up NULL cred RPC: allocated buffer c1fe5500 RPC: 0 rpc_execute flgs 0 RPC: 0 call_reserve RPC: 0 xprt_reserve cong = 0 cwnd = 256 RPC: 0 reserved req c1fa4064 xid 11582000 RPC: 0 xprt_reserve returns 0 RPC: 0 call_reserveresult (status 0) RPC: 0 call_allocate (status 0) RPC: allocated buffer c1fb3800 RPC: 0 call_encode (status 0) RPC: 0 marshaling NULL cred c1fe5500 RPC: xdr_encode_mapping(100003, 2, 17, 0) RPC: 0 call_transmit (status 0) RPC: 0 xprt_transmit(11582000) RPC: 0 xprt_receive RPC: 0 sleep_on(queue "xprt_pending" time 89) RPC: 0 added to queue c1fa4048 "xprt_pending" RPC: xprt_sendmsg(56) = -229 RPC: sendmsg returned error 229 RPC: 0 __rpc_wake_up_task (now 93 inh 0) RPC: 0 disabling timer RPC: 0 removed from queue c1fa4048 "xprt_pending" RPC: __rpc_wake_up_task done RPC: wake_up_next(c1fa4040 "xprt_sending") RPC: 0 call_status (status -229) portmap: RPC call returned error 229 RPC: 0 exit() = -229 RPC: 0 release task RPC: 0 disabling timer RPC: 0 release request c1fa4064 RPC: wake_up_next(c1fa4050 "xprt_backlog") RPC: 0 releasing NULL cred c1fe5500 RPC: rpc_release_client(c1faa5a0, 1) RPC: destroying portmap client for 192.68.1.11 RPC: destroying NULL authenticator c1fe6460 RPC: destroying transport c1fa4000 RPC: disconnected transport c1fa4000 Root-NFS: Unable to get nfsd port number from server, using default Root-NFS: Portmapper on server returned 2049 as nfsd port Looking up port of RPC 100005/2 on 192.68.1.11 RPC: rpc_getport_external(192.68.1.11, 100005, 2, 17) RPC: xprt_create_proto called RPC: xprt_create_socket(udp 17) RPC: setting up UDP transport... RPC: created transport c1fa4000 RPC: creating portmap client for 192.68.1.11 (xprt c1fa4000) RPC: allocated buffer c1faa5a0 RPC: creating NULL authenticator for client c1faa5a0 RPC: allocated buffer c1fe6460 RPC: 1 new task procpid 1 RPC: 1 looking up NULL cred RPC: allocated buffer c1fe5500 RPC: 1 rpc_execute flgs 0 RPC: 1 call_reserve RPC: 1 xprt_reserve cong = 0 cwnd = 256 RPC: 1 reserved req c1fa4064 xid 11582001 RPC: 1 xprt_reserve returns 0 RPC: 1 call_reserveresult (status 0) RPC: 1 call_allocate (status 0) RPC: allocated buffer c1fb3800 RPC: 1 call_encode (status 0) RPC: 1 marshaling NULL cred c1fe5500 RPC: xdr_encode_mapping(100005, 2, 17, 0) RPC: 1 call_transmit (status 0) RPC: 1 xprt_transmit(11582001) RPC: 1 xprt_receive RPC: 1 sleep_on(queue "xprt_pending" time 140) RPC: 1 added to queue c1fa4048 "xprt_pending" RPC: xprt_sendmsg(56) = -229 RPC: sendmsg returned error 229 RPC: 1 __rpc_wake_up_task (now 144 inh 0) RPC: 1 disabling timer RPC: 1 removed from queue c1fa4048 "xprt_pending" RPC: __rpc_wake_up_task done RPC: wake_up_next(c1fa4040 "xprt_sending") RPC: 1 call_status (status -229) portmap: RPC call returned error 229 RPC: 1 exit() = -229 RPC: 1 release task RPC: 1 disabling timer RPC: 1 release request c1fa4064 RPC: wake_up_next(c1fa4050 "xprt_backlog") RPC: 1 releasing NULL cred c1fe5500 RPC: rpc_release_client(c1faa5a0, 1) RPC: destroying portmap client for 192.68.1.11 RPC: destroying NULL authenticator c1fe6460 RPC: destroying transport c1fa4000 RPC: disconnected transport c1fa4000 Root-NFS: Unable to get mountd port number from server, using default Root-NFS: mountd port is 627 NFS: nfs_mount(c044010b:/tftpboot/pancho) RPC: xprt_create_proto called RPC: xprt_create_socket(udp 17) RPC: setting up UDP transport... RPC: created transport c1fa4000 RPC: creating mount client for 192.68.1.11 (xprt c1fa4000) RPC: allocated buffer c1faa5a0 RPC: creating NULL authenticator for client c1faa5a0 RPC: allocated buffer c1fe6460 RPC: 2 new task procpid 1 RPC: 2 looking up NULL cred RPC: allocated buffer c1fe5500 RPC: 2 rpc_execute flgs 0 RPC: 2 call_reserve RPC: 2 xprt_reserve cong = 0 cwnd = 256 RPC: 2 reserved req c1fa4064 xid 11582002 RPC: 2 xprt_reserve returns 0 RPC: 2 call_reserveresult (status 0) RPC: 2 call_allocate (status 0) RPC: allocated buffer c1fa3000 RPC: 2 call_encode (status 0) RPC: 2 marshaling NULL cred c1fe5500 RPC: 2 call_transmit (status 0) RPC: 2 xprt_transmit(11582002) RPC: 2 xprt_receive RPC: 2 sleep_on(queue "xprt_pending" time 189) RPC: 2 added to queue c1fa4048 "xprt_pending" RPC: xprt_sendmsg(60) = -229 RPC: sendmsg returned error 229 RPC: 2 __rpc_wake_up_task (now 193 inh 0) RPC: 2 disabling timer RPC: 2 removed from queue c1fa4048 "xprt_pending" RPC: __rpc_wake_up_task done RPC: wake_up_next(c1fa4040 "xprt_sending") RPC: 2 call_status (status -229) mount: RPC call returned error 229 RPC: 2 exit() = -229 RPC: 2 release task RPC: 2 disabling timer RPC: 2 release request c1fa4064 RPC: wake_up_next(c1fa4050 "xprt_backlog") RPC: 2 releasing NULL cred c1fe5500 RPC: rpc_release_client(c1faa5a0, 1) RPC: destroying mount client for 192.68.1.11 RPC: destroying NULL authenticator c1fe6460 RPC: destroying transport c1fa4000 RPC: disconnected transport c1fa4000 Root-NFS: Server returned error -229 while mounting /tftpboot/pancho VFS: Unable to mount root fs via NFS, trying floppy. VFS: Cannot open root device "nfs" or 02:00 Please append a correct "root=" boot option Kernel panic: VFS: Unable to mount root fs on 02:00 ========== linux/.config ========== # # Automatically generated make config: don't edit # CONFIG_PARISC=y # CONFIG_UID16 is not set # # Code maturity level options # CONFIG_EXPERIMENTAL=y # # General options # # CONFIG_SMP is not set # CONFIG_KWDB is not set CONFIG_GSC=y # CONFIG_IOMMU_CCIO is not set CONFIG_GSC_LASI=y CONFIG_PCI=y CONFIG_GSC_DINO=y # CONFIG_PCI_LBA is not set # # Loadable module support # # CONFIG_MODULES is not set # # General setup # CONFIG_NET=y CONFIG_SYSVIPC=y # CONFIG_BSD_PROCESS_ACCT is not set CONFIG_SYSCTL=y CONFIG_BINFMT_SOM=y # CONFIG_BINFMT_ELF is not set # CONFIG_BINFMT_MISC is not set # CONFIG_BINFMT_JAVA is not set # # Parallel port support # # CONFIG_PARPORT is not set # # Block devices # # CONFIG_BLK_DEV_FD is not set # CONFIG_BLK_DEV_XD is not set # CONFIG_PARIDE is not set # CONFIG_BLK_CPQ_DA is not set # CONFIG_BLK_CPQ_CISS_DA is not set # CONFIG_BLK_DEV_DAC960 is not set # CONFIG_BLK_DEV_LOOP is not set # CONFIG_BLK_DEV_NBD is not set # CONFIG_BLK_DEV_RAM is not set # CONFIG_BLK_DEV_INITRD is not set # # Networking options # # CONFIG_PACKET is not set # CONFIG_NETLINK is not set # CONFIG_NETFILTER is not set # CONFIG_FILTER is not set # CONFIG_UNIX is not set CONFIG_INET=y # CONFIG_IP_MULTICAST is not set # CONFIG_IP_ADVANCED_ROUTER is not set CONFIG_IP_PNP=y CONFIG_IP_PNP_BOOTP=y # CONFIG_IP_PNP_RARP is not set # CONFIG_NET_IPIP is not set # CONFIG_NET_IPGRE is not set # CONFIG_INET_ECN is not set # CONFIG_SYN_COOKIES is not set # CONFIG_IPV6 is not set # CONFIG_KHTTPD is not set # CONFIG_ATM is not set # # # # CONFIG_IPX is not set # CONFIG_ATALK is not set # CONFIG_DECNET is not set # CONFIG_BRIDGE is not set # CONFIG_X25 is not set # CONFIG_LAPB is not set # CONFIG_LLC is not set # CONFIG_NET_DIVERT is not set # CONFIG_ECONET is not set # CONFIG_WAN_ROUTER is not set # CONFIG_NET_FASTROUTE is not set # CONFIG_NET_HW_FLOWCONTROL is not set # # QoS and/or fair queueing # # CONFIG_NET_SCHED is not set # # SCSI support # # CONFIG_SCSI is not set # # Network device support # CONFIG_NETDEVICES=y CONFIG_LASI_82596=y # # ARCnet devices # # CONFIG_ARCNET is not set # CONFIG_DUMMY is not set # CONFIG_BONDING is not set # CONFIG_EQUALIZER is not set # CONFIG_TUN is not set # CONFIG_NET_SB1000 is not set # # Ethernet (10 or 100Mbit) # CONFIG_NET_ETHERNET=y # CONFIG_NET_VENDOR_3COM is not set # CONFIG_LANCE is not set # CONFIG_NET_VENDOR_SMC is not set # CONFIG_NET_VENDOR_RACAL is not set # CONFIG_AT1700 is not set # CONFIG_DEPCA is not set # CONFIG_HP100 is not set # CONFIG_NET_ISA is not set CONFIG_NET_PCI=y # CONFIG_PCNET32 is not set # CONFIG_ADAPTEC_STARFIRE is not set # CONFIG_AC3200 is not set # CONFIG_APRICOT is not set # CONFIG_CS89x0 is not set # CONFIG_DE4X5 is not set # CONFIG_TULIP is not set # CONFIG_DGRS is not set # CONFIG_DM9102 is not set # CONFIG_EEPRO100 is not set # CONFIG_LNE390 is not set # CONFIG_NATSEMI is not set # CONFIG_NE2K_PCI is not set # CONFIG_NE3210 is not set # CONFIG_ES3210 is not set # CONFIG_RTL8129 is not set # CONFIG_8139TOO is not set # CONFIG_SIS900 is not set # CONFIG_EPIC100 is not set # CONFIG_SUNDANCE is not set # CONFIG_TLAN is not set # CONFIG_VIA_RHINE is not set # CONFIG_WINBOND_840 is not set # CONFIG_NET_POCKET is not set # # Ethernet (1000 Mbit) # # CONFIG_ACENIC is not set # CONFIG_HAMACHI is not set # CONFIG_YELLOWFIN is not set # CONFIG_SK98LIN is not set # CONFIG_FDDI is not set # CONFIG_HIPPI is not set # CONFIG_PPP is not set # CONFIG_SLIP is not set # # Wireless LAN (non-hamradio) # # CONFIG_NET_RADIO is not set # # Token Ring devices # # CONFIG_TR is not set # CONFIG_NET_FC is not set # CONFIG_RCPCI is not set # CONFIG_SHAPER is not set # # Wan interfaces # # CONFIG_WAN is not set # # Character devices # # CONFIG_VT is not set CONFIG_SERIAL=y CONFIG_SERIAL_CONSOLE=y CONFIG_SERIAL_GSC=y CONFIG_SERIAL_EXTENDED=y # CONFIG_SERIAL_MANY_PORTS is not set # CONFIG_SERIAL_SHARE_IRQ is not set # CONFIG_SERIAL_DETECT_IRQ is not set # CONFIG_SERIAL_MULTIPORT is not set # CONFIG_HUB6 is not set # CONFIG_SERIAL_NONSTANDARD is not set CONFIG_UNIX98_PTYS=y CONFIG_UNIX98_PTY_COUNT=256 # # I2C support # # CONFIG_I2C is not set # # Mice # # CONFIG_BUSMOUSE is not set # CONFIG_MOUSE is not set # # Joysticks # # CONFIG_JOYSTICK is not set # # Input core support is needed for joysticks # # CONFIG_QIC02_TAPE is not set # # Watchdog Cards # # CONFIG_WATCHDOG is not set # CONFIG_GENRTC is not set # CONFIG_INTEL_RNG is not set # CONFIG_NVRAM is not set # CONFIG_RTC is not set # CONFIG_DTLK is not set # CONFIG_R3964 is not set # CONFIG_APPLICOM is not set # # Ftape, the floppy tape device driver # # CONFIG_FTAPE is not set # CONFIG_AGP is not set # CONFIG_DRM is not set # # File systems # # CONFIG_QUOTA is not set # CONFIG_AUTOFS_FS is not set # CONFIG_AUTOFS4_FS is not set # CONFIG_ADFS_FS is not set # CONFIG_ADFS_FS_RW is not set # CONFIG_AFFS_FS is not set # CONFIG_HFS_FS is not set # CONFIG_BFS_FS is not set # CONFIG_FAT_FS is not set # CONFIG_MSDOS_FS is not set # CONFIG_UMSDOS_FS is not set # CONFIG_VFAT_FS is not set # CONFIG_EFS_FS is not set # CONFIG_JFFS_FS is not set # CONFIG_CRAMFS is not set # CONFIG_RAMFS is not set CONFIG_ISO9660_FS=y # CONFIG_JOLIET is not set # CONFIG_MINIX_FS is not set # CONFIG_NTFS_FS is not set # CONFIG_NTFS_RW is not set # CONFIG_HPFS_FS is not set CONFIG_PROC_FS=y # CONFIG_DEVFS_FS is not set # CONFIG_DEVFS_MOUNT is not set # CONFIG_DEVFS_DEBUG is not set # CONFIG_DEVPTS_FS is not set # CONFIG_QNX4FS_FS is not set # CONFIG_QNX4FS_RW is not set # CONFIG_ROMFS_FS is not set CONFIG_EXT2_FS=y # CONFIG_SYSV_FS is not set # CONFIG_SYSV_FS_WRITE is not set # CONFIG_UDF_FS is not set # CONFIG_UDF_RW is not set # CONFIG_UFS_FS is not set # CONFIG_UFS_FS_WRITE is not set # # Network File Systems # # CONFIG_CODA_FS is not set CONFIG_NFS_FS=y # CONFIG_NFS_V3 is not set CONFIG_ROOT_NFS=y # CONFIG_NFSD is not set # CONFIG_NFSD_V3 is not set CONFIG_SUNRPC=y CONFIG_LOCKD=y # CONFIG_SMB_FS is not set # CONFIG_NCP_FS is not set # CONFIG_NCPFS_PACKET_SIGNING is not set # CONFIG_NCPFS_IOCTL_LOCKING is not set # CONFIG_NCPFS_STRONG is not set # CONFIG_NCPFS_NFS_NS is not set # CONFIG_NCPFS_OS2_NS is not set # CONFIG_NCPFS_SMALLDOS is not set # CONFIG_NCPFS_MOUNT_SUBDIR is not set # CONFIG_NCPFS_NDS_DOMAINS is not set # CONFIG_NCPFS_NLS is not set # CONFIG_NCPFS_EXTRAS is not set # # Partition Types # # CONFIG_PARTITION_ADVANCED is not set CONFIG_MSDOS_PARTITION=y # CONFIG_NLS is not set # # Sound Drivers # # CONFIG_SOUND is not set # # Kernel hacking # # CONFIG_MAGIC_SYSRQ is not set From grundler@cup.hp.com Wed, 15 Nov 2000 12:10:36 -0800 Date: Wed, 15 Nov 2000 12:10:36 -0800 From: Grant Grundler grundler@cup.hp.com Subject: [parisc-linux] nfsroot - 712/60 - RPC - help Jack Perdue wrote: Two changes: > a) I've tried NFSROOT=192.168.1.11 and NFSROOT=192.168.1.11/tftpboot/vmlinux > in palo/Makefile and the results are the same (both suggestions were > made to this list at some point) Try NFSROOT=192.168.1.11/tftpboot/pancho > ========== blacktower:/etc/bootptab ========== > pancho:\ > :hd=/tftpboot:\ > :bf=vmlinux:\ > :ht=ether:\ > :ha=08000993DA02:\ > :sm=255.255.255.0:\ > :hn:\ > :ip=192.168.1.13:\ > :vm=rfc1048: This is just a nit: bf= might be better named ":bf=lifimage\" (and you only need one colon between entry's :^) Copy /palo/lifimage to /tftpboot/lifimage. There must be something wrong but I don't see it. grant > kmem_create: Forcing size word alignment - nfs_fh > Looking up port of RPC 100003/2 on 192.68.1.11 > RPC: sendmsg returned error 229 > portmap: RPC call returned error 229 I don't see these types of errors on my config. Could be related to the misdirected NFSROOT. grant Grant Grundler Unix Systems Enablement Lab +1.408.447.7253 From j-perdue@tamu.edu Wed, 15 Nov 2000 14:14:13 -0600 Date: Wed, 15 Nov 2000 14:14:13 -0600 From: Jack Perdue j-perdue@tamu.edu Subject: Doh!!! was Re: [parisc-linux] nfsroot - 712/60 - RPC - help Of course, as soon I collected all that info and sent it I, in rereading, realized that I had put 192.68.1.11 in palo/Makefile instead of 192.168.1.11. Doh! However, since the info is out there now, can someone tell me what I need to resolve the following: [previous console output in previous mail] Switching from PDC console kmem_create: Forcing size word alignment - nfs_fh Looking up port of RPC 100003/2 on 192.168.1.11 Looking up port of RPC 100005/2 on 192.168.1.11 VFS: Mounted root (nfs filesystem) readonly. Kernel panic: No init found. Try passing init= option to kernel. jack j-perdue@tamu.edu From law@redhat.com Wed, 15 Nov 2000 13:30:59 -0700 Date: Wed, 15 Nov 2000 13:30:59 -0700 From: law@redhat.com law@redhat.com Subject: [parisc-linux] Single-stepping In message <200011151949.OAA22929@hiauly1.hia.nrc.ca>you write: > > I've been helping Alan Modra out with kernel changes to support > > single stepping for gdb. Paul Bame suggested I bounced our ideas > > off you in case you (or anyone else) had any comments. I havn't > > actually committed my changes yet. > > > > The basic approach is to use the recovery counter to generate > > a trap every instruction. The scheme is complicated because a > > suspended process may or may not return to user space via an RFI. > > I really don't know enough to comment on the implementation choice. Why > did you decide on this approach as opposed to inserting breaks and > enabling the taken branch branch trap (T)? It would appear that the recove > ry > counter was intended to provide software recovery from hardware faults > in fault tolerant systems. Possibly, Grant could comment on whether > it is actually useful for this purpose. Err, we tried that at the UofU in our mach port to the PA -- there's a problem with that scheme, though I don't remember precisely what it was. I believe there were cases where the recovery counter doesn't trigger a trap, possibly due to nullified instructions. You might look at the UofU BSD code, which I believe used breakpoints and branch taken traps instad. jeff From taggart@carmen.fc.hp.com Wed, 15 Nov 2000 13:49:18 -0700 Date: Wed, 15 Nov 2000 13:49:18 -0700 From: Matt Taggart taggart@carmen.fc.hp.com Subject: [parisc-linux] Palinux on a 712/60 Andrew Shugg writes... > Arnaud.ATOCH@oecd.org said: > > Hi, > > > > I got a couple of 715 and I'd love having access to an ISO image with STI > > console kernel too. > > I've never made an El Torito CDROM, is it possible to have multiple boot > images and a boot loader on a single disc? El Torito is a PC thing. It makes the front of a CDROM look like a floppy to the PC BIOS. For hppa you put a lifimage on the front of the CDROM(or tape or HDD, etc). > ie could the actual boot > image be a boot loader (PALO) which then points at one or more kernels > on the CDROM? Maybe. Paul Bame is the expert though. I think he had to do some work to get palo to be able to see a kernel on an ISO9660 filesystem. I don't know if it can currently be interruped and pointed at a different kernel. Paul? -- Matt Taggart taggart@fc.hp.com From drepper@redhat.com 15 Nov 2000 12:52:52 -0800 Date: 15 Nov 2000 12:52:52 -0800 From: Ulrich Drepper drepper@redhat.com Subject: [parisc-linux] Help with posix_types.h Paul Bame writes: > FYI I just heard some pretty good reasons why both ino_t and off_t > should be 64 bits even on 32-bit kernels. Keep those cards and letters > coming! Any new port which does *not* do this is broken from the beginning. Copying existing files is not what you have to do. Instead look at today's needs. The numbers of the x86 port are those the kernel people told me are needs, multiplied by 2 or 4. Do the same. -- ---------------. ,-. 1325 Chesapeake Terrace Ulrich Drepper \ ,-------------------' \ Sunnyvale, CA 94089 USA Red Hat `--' drepper at redhat.com `------------------------ From ich@johannes-zahn.de Wed, 15 Nov 2000 21:49:31 +0100 Date: Wed, 15 Nov 2000 21:49:31 +0100 From: johannes zahn ich@johannes-zahn.de Subject: [parisc-linux] init dies on apollo 720 Hi! I'm trying to get a 720/50 to boot from nfs, but as soon as the nfs mound happened init dies. This is all i get on the serial console (pasted from minicom): kmem_create: Forcing size word alignment - nfs_fh Looking up port of RPC 100003/2 on 192.168.1.1 Looking up port of RPC 100005/2 on 192.168.1.1 VFS: Mounted root (nfs filesystem) readonly. handle_interruption() pid=1 command='init' YZrvWESTHLNXBCVMcbcbcbcbOGFRQPDI PSW: 00000000000001001111011100001011 r0-3 00000000 4001ad3c 400057a3 00001f58 r4-7 4001967c 00000000 4001ada0 00001f58 r8-11 00000000 000023cc 00000001 00000000 r12-15 00001034 00000006 40019622 2001ff18 r16-19 c1fdc000 c027b60c 00000000 4001967c r20-23 0000a090 0000a090 00009d8c 00001f58 r24-27 00000001 00000081 4001ada0 c01492b0 r28-31 00000000 0000000b 20020790 400032d7 sr0-4 00000001 00000001 00000000 00000001 sr4-8 00000001 00000001 00000001 00000001 IASQ: 00000001 00000001 IAOQ: 4000d237 4000d23b IIR: 0ed51280 ISR: 00000001 IOR: 00009d8c ORIG_R28: 4001b208 handle_interruption() pid=1 command='init' YZrvWESTHLNXBCVMcbcbcbcbOGFRQPDI [...] I tried the cvs-latest kernel and palo from 2000-11-10 and 2000-11-14 with the crosscompiler from 2000-10-31. Buildhost is i386 linux. nfsroot was from 2000-10-09 or base.tgz from the 0.5 beta CD. I also tried the ramdisk images with sercon and sticon, but the kernel only says "cannot mount root FS on 01:00". The kernel from the 0.5 beta CD seems to have the parport stuff, and that does not work on this machine. Any ideas? Or a working .config? johannes From sieler@allegro.com Wed, 15 Nov 2000 13:08:15 -0800 (PST) Date: Wed, 15 Nov 2000 13:08:15 -0800 (PST) From: Stan Sieler sieler@allegro.com Subject: [parisc-linux] Single-stepping Re: > > The basic approach is to use the recovery counter to generate > > a trap every instruction. The scheme is complicated because a ... > I really don't know enough to comment on the implementation choice. Why > did you decide on this approach as opposed to inserting breaks and MPE/iX (which runs on PA-RISC hardware), has successfully used the Recovery Counter to implement single step for many, many years. BTW, in addition to single step, it's a great tool for counting the number of instructions a procedure (or code path) takes, assuming an adequately powerful debugger: 1) stop (perhaps via a breakpoint) at the start of the code you want to count. 2) set a breakpoint at the end of the code you want to count (e.g., if you're counting a procedure, set a breakpoint at the procedure exit) 3) instead of "continue", do: s 1000000 (i.e., tell Debug/iX to "singlestep" 1000000 instructions) 4) if you hit the breakpoint, enter: = 1000000 - rctr that's how many instructions your code took! (Not counting instructions executed by interrupt handlers, of course.) 5) if you *didn't* hit the breakpoint, then 1000000 wasn't enough instructions (and why are you trying to count so high?) This works because MPE's debug "s" command sets the Recovery Counter to the number of instructions you wanted to step. Normally, that's one (for just "s"). If you said "s 3", it would set the Recovery Counter to 3. If you say "s 1000000", and then execute 123 instructions, and then hit a breakpoint, Debug captures the entire register state as of the breakpoint: including the Recovery Counter (which has 1000000 - 123 in it). Tip: if you're looking at instruction-level debugging, look at Debug/iX to see how to do it right! > It would appear that the recovery > counter was intended to provide software recovery from hardware faults The 1986 PA-RISC Instruction manual simply says "The Recovery Counter (CR 0) can be used to provide software recovery of hardware faults in fault tolerant systems". (I.e., "can", not "must" ... and there's no explanation of how one would use it for this.) -- Stan Sieler sieler@allegro.com www.allegro.com/sieler/wanted/index.html www.sieler.com From drepper@redhat.com 15 Nov 2000 13:08:01 -0800 Date: 15 Nov 2000 13:08:01 -0800 From: Ulrich Drepper drepper@redhat.com Subject: [parisc-linux] Help with posix_types.h This reminds me of something I talked to Cary Coutant about before. You have certainly reserved a thread register in the ABI, right? If not, do it ASAP. -- ---------------. ,-. 1325 Chesapeake Terrace Ulrich Drepper \ ,-------------------' \ Sunnyvale, CA 94089 USA Red Hat `--' drepper at redhat.com `------------------------ From frank_rowand@mvista.com Wed, 15 Nov 2000 13:16:28 -0800 Date: Wed, 15 Nov 2000 13:16:28 -0800 From: Frank Rowand frank_rowand@mvista.com Subject: [parisc-linux] Single-stepping law@redhat.com wrote: > > In message <200011151949.OAA22929@hiauly1.hia.nrc.ca>you write: > > > I've been helping Alan Modra out with kernel changes to support > > > single stepping for gdb. Paul Bame suggested I bounced our ideas > > > off you in case you (or anyone else) had any comments. I havn't > > > actually committed my changes yet. > > > > > > The basic approach is to use the recovery counter to generate > > > a trap every instruction. The scheme is complicated because a > > > suspended process may or may not return to user space via an RFI. > > > > I really don't know enough to comment on the implementation choice. Why > > did you decide on this approach as opposed to inserting breaks and > > enabling the taken branch branch trap (T)? It would appear that the recove > > ry > > counter was intended to provide software recovery from hardware faults > > in fault tolerant systems. Possibly, Grant could comment on whether > > it is actually useful for this purpose. > Err, we tried that at the UofU in our mach port to the PA -- there's a problem > with that scheme, though I don't remember precisely what it was. I believe > there were cases where the recovery counter doesn't trigger a trap, possibly > due to nullified instructions. > > You might look at the UofU BSD code, which I believe used breakpoints and > branch taken traps instad. > > jeff > I implemented two different single step algorithms for a a _kernel_ debugger for hp-ux. The algorithm used could be chosen by a compile switch, because each method had cases that weren't handled well - for some debugging tasks one algorithm was superior to the other. Part of my problem with the recovery counter was that other services in the hp-ux kernel also used the recovery counter. I liked the recovery counter method better than my second method (but had to deal with collisions with the other kernel services). My second method was to insert a breakpoint at the target of the single step. It's a pain to do that because of issues with delay slots, branching, and nullification. I guess the point of all this rambling is to say that the recovery counter has been successfully used by a debugger for single stepping. -Frank -- Frank Rowand MontaVista Software, Inc From sieler@allegro.com Wed, 15 Nov 2000 13:47:15 -0800 (PST) Date: Wed, 15 Nov 2000 13:47:15 -0800 (PST) From: Stan Sieler sieler@allegro.com Subject: [parisc-linux] Single-stepping Re: > I implemented two different single step algorithms for a a _kernel_ debugger > for hp-ux. The algorithm used could be chosen by a compile switch, because BTW, Frank, ask Lee Courtney at MontaVista about Debug/iX ... we've had kernel debugging and single stepping (except for the interrupt control stack and a few other corner cases) for 15+ years. It's *very* powerful to be able to logon as root (or equivalent) and set breakpoints within the kernel, hit them, and then single step ... all on a standard release of the operating system. > I liked the recovery counter method better than my second method (but had to > deal with collisions with the other kernel services). My second method was > to insert a breakpoint at the target of the single step. It's a pain to do > that because of issues with delay slots, branching, and nullification. Worse yet...the breakpoint mechanism raises hell if you have more than one CPU :) You realllly don't want that other CPU to hit the breakpoint! -- Stan Sieler sieler@allegro.com www.allegro.com/sieler/wanted/index.html www.sieler.com From andreas@bawue.de Thu, 16 Nov 2000 23:06:04 +0100 Date: Thu, 16 Nov 2000 23:06:04 +0100 From: Andreas Thienemann andreas@bawue.de Subject: [parisc-linux] 250/1 doesn't boot but dumps stack Hi Grant, Grant Grundler wrote: > > lp0: using parport0 (interrupt-driven). > Are you sure you left out parallel port support? Yes, I am. I just attached the wrong log. Except the lp0 line, there are no differences... > > IASQ: 00000000 00000000 IAOQ: c029c264 c029c268 > > IIR: 0e681096 ISR: 00000000 IOR: 00000004 > > ORIG_R28: 00000000 > Smells like a driver bug. > Can you look up IOAQ and GR2 (c029c264 and c029c248) in System.map file? Of course. The only problem is, there is no such entry in /usr/src/pa-risc/sourcE/linux/System.map . Any ideas? andreas From rhirst@linuxcare.com Wed, 15 Nov 2000 22:19:29 +0000 Date: Wed, 15 Nov 2000 22:19:29 +0000 From: Richard Hirst rhirst@linuxcare.com Subject: [parisc-linux] dino maintainer? On Wed, Nov 15, 2000 at 09:58:35AM +0000, Richard Hirst wrote: > But Helge has problems with the sym53c8xx driver on a B160L. Is Turned out to be a 53c720, driven via Zalon and the ncr53c8xx driver. Driver worked as a module, but not compiled in. Now fixed. Richard From rlduncan@nortelnetworks.com Wed, 15 Nov 2000 17:28:13 -0500 Date: Wed, 15 Nov 2000 17:28:13 -0500 From: Robert Duncan rlduncan@nortelnetworks.com Subject: [parisc-linux] CD-ROM 715/50 boot dies after serial driver... This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C04F53.576F0F70 Content-Type: text/plain; charset="iso-8859-1" Greetings, I have downloaded the .5 Beta CDROM image, burned it and get a "fault in kernel" after the "Serial driver ... enabled" message when booting on my 715/50. This happens with either graphics or serial console configured in NVRAM. Has anyone else seen this error? ----------------begin console output (c) Copyright Hewlett-Packard Company, 1991, 1992 Portions of this code are (c) Copyright Samsung Electronics Co., Ltd, 91, 92 PDC ROM rev. 1.2 IODC ROM rev. 1.1 64 MB of memory have been configured. Selecting a system to boot. To stop selection process, press and hold the ESCAPE key..... Booting from: scsi.6.0 TOSHIBA CD-ROM XM-3501TA Soft booted. palo ipl bame@noam Tue Oct 31 14:18:02 MST 2000 0/vmlinux 2140145 bytes @ 0x6f9800 0/palo-cmdline '0/vmlinux ROOT=/ TERM=LINUX root=/dev/scd0' Kernel: partition 0 file /vmlinux ELF32 executable Entry 00100150 first 00100000 n 4 Segment 0 load 00100000 size 1460344 mediaptr 0x1000 Segment 1 load 00266000 size 179048 mediaptr 0x166000 Segment 2 load 00294000 size 109876 mediaptr 0x192000 Segment 3 load 002b0000 size 8192 mediaptr 0x1ad000 branching to kernel entry point 0x00100150 PDC Console Initialized The 32-bit Kernel has started... Enabled FP coprocessor Free memory starts at: 0xc02da000 (0x504d6c,0x504d6c,0x0,0x0) PALO command line: 'ROOT=/ TERM=LINUX root=/dev/scd0' PALO initrd 0-0 model 00003100 00000481 00000000 00000000 77a94524 ffffffff 00000004 0000000a 0000000a vers 00000009 CPUID vers 0 rev 0 Searching for devices in PDC firmware... processor hpa 0xfffbe000 an older box... Found devices: 1. Stinger Optional Graphics (10) at 0xf4000000, versions 0x6, 0x0, 0x77, 0x0, 0x0 2. Scorpio Core BA (11) at 0xf082f000, versions 0x7, 0x0, 0x70, 0x0, 0x0 3. Scorpio Core SCSI (10) at 0xf0825000, versions 0x7, 0x0, 0x71, 0x0, 0x0 4. Scorpio Core LAN (802.3) (10) at 0xf0826000, versions 0x7, 0x0, 0x72, 0x0, 0x0 5. Scorpio Core HIL (10) at 0xf0821000, versions 0x7, 0x0, 0x73, 0x0, 0x0 6. Scorpio Core RS-232 (10) at 0xf0823000, versions 0x7, 0x0, 0x75, 0x0, 0x0 7. Scorpio Core RS-232 (10) at 0xf0822000, versions 0x7, 0x0, 0x75, 0x0, 0x0 8. Scorpio Core Centronics (10) at 0xf0824000, versions 0x7, 0x0, 0x74, 0x0, 0x0 9. Scorpio Audio (10) at 0xf1000000, versions 0x7, 0x0, 0x7b, 0x0, 0x0 10. Scorpio EISA BA (11) at 0xfc000000, versions 0x7, 0x0, 0x76, 0x0, 0x0 11. Scorpio (715/50) (0) at 0xfffbe000, versions 0x310, 0x0, 0x4, 0x0, 0x81 12. Scorpio (1) at 0xfffbf000, versions 0x17, 0x0, 0x9, 0x0, 0x0 That's a total of 12 devices. CPU(s): 1 x PA7100 (PCX-T) at 50.000000 MHz Linux version 2.4.0-test6 (pjlahaie@elenuial.thepuffingroup.com) (gcc version 2.96 20000925 (experimental)) #32 Mon Nov 6 10:20:58 EST 2000 free_bootmem(0x2da800, 0x3d25800) initrd: 00000000-00000000 pagetable_init On node 0 totalpages: 16384 zone(0): 8192 pages. zone(1): 8192 pages. zone(2): 0 pages. Kernel command line: ROOT=/ TERM=LINUX root=/dev/scd0 trap_init Calibrating delay loop... 49.77 BogoMIPS Memory: 61388k available Dentry-cache hash table entries: 8192 (order: 4, 65536 bytes) Buffer-cache hash table entries: 4096 (order: 2, 16384 bytes) Page-cache hash table entries: 16384 (order: 4, 65536 bytes) Inode-cache hash table entries: 4096 (order: 3, 32768 bytes) POSIX conformance testing by UNIFIX ASP version 1 at 0xf0800000 found. Found i82596 at 0xf0826000, IRQ 87 early initialization of device eth0 is deferred Found HIL at 0xf0821000, IRQ 94 HIL: no keyboard present. Warning : device (10, 0x7, 0x0, 0x73, 0x0) NOT claimed by HIL 712, 715 or similiar Linux NET4.0 for Linux 2.4 Based upon Swansea University Computer Society NET3.039 NET4: Unix domain sockets 1.0/SMP for Linux NET4.0. NET4: Linux TCP/IP 1.0 for NET4.0 IP Protocols: ICMP, UDP, TCP IP: routing cache hash table of 512 buckets, 4Kbytes TCP: Hash tables configured (established 4096 bind 4096) Starting kswapd v1.7 pty: 256 Unix98 ptys configured lp: driver loaded but no devices found RAMDISK driver initialized: 16 RAM disks of 4096K size 1024 blocksize sim700: Couldn't get consistent shared memory sim700: Configuring 53c700 (SCSI-ID 7) at f0825100, IRQ 86 scsi0: Revision 0x0 Post test1, istat 05, sstat0 00, dstat 84 sim700: WARNING IRQ probe failed, (returned 0) scsi0: WARNING: target data areas are not dma coherent! scsi0: test 1 completed ok. scsi0: sim700_intr_handle() called with no interrupt scsi0 : LASI/Simple 53c7xx scsi : 1 host. Vendor: TOSHIBA Model: CD-ROM XM-3501TA Rev: 3054 Type: CD-ROM ANSI SCSI revision: 02 Detected scsi CD-ROM sr0 at scsi0, channel 0, id 6, lun 0 scsi : detected 1 SCSI cdrom total. Uniform CD-ROM driver Revision: 3.11 82596.c: MAC of HP700 LAN blindely read from the prom! eth0: Couldn't get consistent shared memory eth0: 82596 at 0xf0826000, 08 00 09 42 1B 37 IRQ 87. 82596.c $Revision: 1.14 $ Serial driver version 5.01 (2000-05-29) with MANY_PORTS SHARE_IRQ SERIAL_PCI enabled Dumping Stack from c3fc4000 to c3fc4bc0: 4000 00000000 00000140 00000000 00000000 c027a46c 00000001 00000000 ffffffff 4020 00000000 00000000 00000000 00000000 00000000 00000000 ffffffff c027a384 [...] 4ba0 ffffffff bffff5ff ffffff7f c01046e0 ffffbeff f7b7eddf 5fffffdf feefffff Data access rights fault in kernel: Code=26 regs=c3fc4980 (Addr=00000003) YZrvWESTHLNXBCVMcbcbcbcbOGFRQPDI PSW: 00000000000001000000000000001010 r0-3 00000000 c0221800 c011e9f8 c3fce420 r4-7 c3fce200 c0244f10 00000008 f0823800 r8-11 00000003 00000007 c0191568 c02c60a4 r12-15 fffffffc c0245000 c0245000 c02d72b8 r16-19 c0245000 c0245000 c02c6028 00000000 r20-23 c3fce234 f0823807 f0823800 0000000a r24-27 ffffffff c3fce420 c3fce200 c0266000 r28-31 ffffffff 00000240 c3fc4bc0 c012dfc0 sr0-4 00000000 00000000 00000000 00000000 sr4-8 00000000 00000000 00000000 00000000 IASQ: 00000000 00000000 IAOQ: c011e710 c011e714 IIR: 0f881093 ISR: 00000000 IOR: 00000003 ORIG_R28: 00000058 ----------------end console output thanks, Robert Duncan Nortelnetworks ------_=_NextPart_001_01C04F53.576F0F70 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable CD-ROM 715/50 boot dies after serial driver...

Greetings,
I have downloaded the .5 Beta CDROM image, burned it = and get a "fault in kernel" after the "Serial driver ... = enabled" message when booting on my 715/50.  This happens = with either graphics or serial console configured in NVRAM.

Has anyone else seen this error?

----------------begin console output
          &nb= sp;   (c) Copyright Hewlett-Packard Company, 1991, = 1992
Portions of this code are (c) Copyright Samsung = Electronics Co., Ltd, 91, 92

PDC ROM rev. 1.2
IODC ROM rev. 1.1
64 MB of memory have been configured.


Selecting a system to boot.
To stop selection process, press and hold the ESCAPE = key.....

Booting from:     = scsi.6.0     TOSHIBA CD-ROM XM-3501TA

Soft booted.
palo ipl bame@noam Tue Oct 31 14:18:02 MST = 2000
0/vmlinux 2140145 bytes @ 0x6f9800
0/palo-cmdline '0/vmlinux ROOT=3D/ TERM=3DLINUX = root=3D/dev/scd0'
Kernel: partition 0 file /vmlinux
ELF32 executable

Entry 00100150 first 00100000 n 4
Segment 0 load 00100000 size 1460344 mediaptr = 0x1000
Segment 1 load 00266000 size 179048 mediaptr = 0x166000
Segment 2 load 00294000 size 109876 mediaptr = 0x192000
Segment 3 load 002b0000 size 8192 mediaptr = 0x1ad000
branching to kernel entry point 0x00100150
PDC Console Initialized
The 32-bit Kernel has started...
Enabled FP coprocessor
Free memory starts at: 0xc02da000
(0x504d6c,0x504d6c,0x0,0x0)
PALO command line: 'ROOT=3D/ TERM=3DLINUX = root=3D/dev/scd0'
PALO initrd 0-0
model   00003100 00000481 00000000 = 00000000 77a94524 ffffffff 00000004 0000000a 0000000a
vers    00000009
CPUID vers 0 rev 0
Searching for devices in PDC firmware... processor = hpa 0xfffbe000
 an older box...
Found devices:
1. Stinger Optional Graphics (10) at 0xf4000000, = versions 0x6, 0x0, 0x77, 0x0, 0x0
2. Scorpio Core BA (11) at 0xf082f000, versions 0x7, = 0x0, 0x70, 0x0, 0x0
3. Scorpio Core SCSI (10) at 0xf0825000, versions = 0x7, 0x0, 0x71, 0x0, 0x0
4. Scorpio Core LAN (802.3) (10) at 0xf0826000, = versions 0x7, 0x0, 0x72, 0x0, 0x0
5. Scorpio Core HIL (10) at 0xf0821000, versions = 0x7, 0x0, 0x73, 0x0, 0x0
6. Scorpio Core RS-232 (10) at 0xf0823000, versions = 0x7, 0x0, 0x75, 0x0, 0x0
7. Scorpio Core RS-232 (10) at 0xf0822000, versions = 0x7, 0x0, 0x75, 0x0, 0x0
8. Scorpio Core Centronics (10) at 0xf0824000, = versions 0x7, 0x0, 0x74, 0x0, 0x0
9. Scorpio Audio (10) at 0xf1000000, versions 0x7, = 0x0, 0x7b, 0x0, 0x0
10. Scorpio EISA BA (11) at 0xfc000000, versions = 0x7, 0x0, 0x76, 0x0, 0x0
11. Scorpio (715/50) (0) at 0xfffbe000, versions = 0x310, 0x0, 0x4, 0x0, 0x81
12. Scorpio (1) at 0xfffbf000, versions 0x17, 0x0, = 0x9, 0x0, 0x0
That's a total of 12 devices.
CPU(s): 1 x PA7100 (PCX-T) at 50.000000 MHz
Linux version 2.4.0-test6 = (pjlahaie@elenuial.thepuffingroup.com) (gcc version 2.96 20000925 = (experimental)) #32 Mon Nov 6 10:20:58 EST 2000

free_bootmem(0x2da800, 0x3d25800)
initrd: 00000000-00000000
pagetable_init
On node 0 totalpages: 16384
zone(0): 8192 pages.
zone(1): 8192 pages.
zone(2): 0 pages.
Kernel command line: ROOT=3D/ TERM=3DLINUX = root=3D/dev/scd0
trap_init
Calibrating delay loop... 49.77 BogoMIPS
Memory: 61388k available
Dentry-cache hash table entries: 8192 (order: 4, = 65536 bytes)
Buffer-cache hash table entries: 4096 (order: 2, = 16384 bytes)
Page-cache hash table entries: 16384 (order: 4, = 65536 bytes)
Inode-cache hash table entries: 4096 (order: 3, = 32768 bytes)
POSIX conformance testing by UNIFIX
ASP version 1 at 0xf0800000 found.
Found i82596 at 0xf0826000, IRQ 87
early initialization of device eth0 is = deferred
Found HIL at 0xf0821000, IRQ 94
HIL: no keyboard present.
Warning : device (10, 0x7, 0x0, 0x73, 0x0) NOT = claimed by HIL 712, 715 or similiar
Linux NET4.0 for Linux 2.4
Based upon Swansea University Computer Society = NET3.039
NET4: Unix domain sockets 1.0/SMP for Linux = NET4.0.
NET4: Linux TCP/IP 1.0 for NET4.0
IP Protocols: ICMP, UDP, TCP
IP: routing cache hash table of 512 buckets, = 4Kbytes
TCP: Hash tables configured (established 4096 bind = 4096)
Starting kswapd v1.7
pty: 256 Unix98 ptys configured
lp: driver loaded but no devices found
RAMDISK driver initialized: 16 RAM disks of 4096K = size 1024 blocksize
sim700: Couldn't get consistent shared memory
sim700: Configuring 53c700 (SCSI-ID 7) at f0825100, = IRQ 86
scsi0: Revision 0x0
Post test1, istat 05, sstat0 00, dstat 84
sim700: WARNING IRQ probe failed, (returned = 0)
scsi0: WARNING: target data areas are not dma = coherent!
scsi0: test 1 completed ok.
scsi0: sim700_intr_handle() called with no = interrupt
scsi0 : LASI/Simple 53c7xx
scsi : 1 host.
  Vendor: TOSHIBA   Model: CD-ROM = XM-3501TA  Rev: 3054
  Type:   = CD-ROM           =             =       ANSI SCSI revision: 02
Detected scsi CD-ROM sr0 at scsi0, channel 0, id 6, = lun 0
scsi : detected 1 SCSI cdrom total.
Uniform CD-ROM driver Revision: 3.11
82596.c: MAC of HP700 LAN blindely read from the = prom!
eth0: Couldn't get consistent shared memory
eth0: 82596 at 0xf0826000, 08 00 09 42 1B 37 IRQ = 87.
82596.c $Revision: 1.14 $
Serial driver version 5.01 (2000-05-29) with = MANY_PORTS SHARE_IRQ SERIAL_PCI enabled

Dumping Stack from c3fc4000 to c3fc4bc0:
4000 00000000 00000140 00000000 00000000 c027a46c = 00000001 00000000 ffffffff
4020 00000000 00000000 00000000 00000000 00000000 = 00000000 ffffffff c027a384
 [...]
4ba0 ffffffff bffff5ff ffffff7f c01046e0 ffffbeff = f7b7eddf 5fffffdf feefffff

Data access rights fault in kernel: Code=3D26 = regs=3Dc3fc4980 (Addr=3D00000003)

     = YZrvWESTHLNXBCVMcbcbcbcbOGFRQPDI
PSW: 00000000000001000000000000001010
r0-3     00000000 c0221800 = c011e9f8 c3fce420
r4-7     c3fce200 c0244f10 = 00000008 f0823800
r8-11    00000003 00000007 c0191568 = c02c60a4
r12-15   fffffffc c0245000 c0245000 = c02d72b8
r16-19   c0245000 c0245000 c02c6028 = 00000000
r20-23   c3fce234 f0823807 f0823800 = 0000000a
r24-27   ffffffff c3fce420 c3fce200 = c0266000
r28-31   ffffffff 00000240 c3fc4bc0 = c012dfc0
sr0-4    00000000 00000000 00000000 = 00000000
sr4-8    00000000 00000000 00000000 = 00000000

IASQ: 00000000 00000000 IAOQ: c011e710 = c011e714
 IIR: 0f881093    ISR: = 00000000  IOR: 00000003
ORIG_R28: 00000058

----------------end console output

thanks,
Robert Duncan
Nortelnetworks

------_=_NextPart_001_01C04F53.576F0F70-- From rhirst@linuxcare.com Wed, 15 Nov 2000 22:35:40 +0000 Date: Wed, 15 Nov 2000 22:35:40 +0000 From: Richard Hirst rhirst@linuxcare.com Subject: [parisc-linux] CD-ROM 715/50 boot dies after serial driver... On Wed, Nov 15, 2000 at 05:28:13PM -0500, Robert Duncan wrote: > Greetings, > I have downloaded the .5 Beta CDROM image, burned it and get a "fault in > kernel" after the "Serial driver ... enabled" message when booting on my > 715/50. This happens with either graphics or serial console configured in > NVRAM. > > Has anyone else seen this error? I get exactly the same on my 715/75. Havn't had time to investigate yet. Richard From andreas@bawue.de Thu, 16 Nov 2000 23:42:35 +0100 Date: Thu, 16 Nov 2000 23:42:35 +0100 From: Andreas Thienemann andreas@bawue.de Subject: [parisc-linux] 250/1 doesn't boot but dumps stack Grant Grundler wrote: > > IASQ: 00000000 00000000 IAOQ: c029c264 c029c268 > > IIR: 0e681096 ISR: 00000000 IOR: 00000004 > > ORIG_R28: 00000000 > Smells like a driver bug. > Can you look up IOAQ and GR2 (c029c264 and c029c248) in System.map file? Okay, here we go (thanks for the build-tool information...) System Map output: 0xc029c264 __init_begin+264 0xc029x248 __init_begin+248 andreas From kailasr@webcash.com Wed, 15 Nov 2000 15:41:55 -0800 Date: Wed, 15 Nov 2000 15:41:55 -0800 From: Kailashnath V Rampure kailasr@webcash.com Subject: [parisc-linux] Apache package. --=====================_108207293==_.ALT Content-Type: text/plain; charset="us-ascii"; format=flowed Hi I tried to build apache_1.3.12 on HP a class server. But I have error. I have tried to check the site ftp://ftp.debian.org/debian/dists/unstable/main/binary-hppa/ I could not find one. I found some apache-doc etc. Can any on point me where I can try. Regards Kailas --=====================_108207293==_.ALT Content-Type: text/html; charset="us-ascii" Hi

I tried to build apache_1.3.12 on HP a class server. But I have error. I have tried to check the site ftp://ftp.debian.org/debian/dists/unstable/main/binary-hppa/
I could not find one. I found some apache-doc etc.

Can any on point me where I can try.
Regards
Kailas --=====================_108207293==_.ALT-- From bame@noam.fc.hp.com Wed, 15 Nov 2000 16:59:18 -0700 Date: Wed, 15 Nov 2000 16:59:18 -0700 From: Paul Bame bame@noam.fc.hp.com Subject: [parisc-linux] Apache package. = I tried to build apache_1.3.12 on HP a class server. But I have error. I = have tried to check the site = ftp://ftp.debian.org/debian/dists/unstable/main/binary-hppa/ = I could not find one. I found some apache-doc etc. We are still working on some kernel features which are required to support Apache (system 5 shared memory). -P From cary@cup.hp.com Wed, 15 Nov 2000 16:00:49 -0800 Date: Wed, 15 Nov 2000 16:00:49 -0800 From: Cary Coutant cary@cup.hp.com Subject: [parisc-linux] Help with posix_types.h >You have certainly reserved a thread register in the ABI, right? If >not, do it ASAP. On PA-RISC, the thread pointer is kept in the read-only control register CR 27. For user-thread implementations, we provided a kernel API to change the contents of the register. -cary From drepper@redhat.com 15 Nov 2000 16:04:51 -0800 Date: 15 Nov 2000 16:04:51 -0800 From: Ulrich Drepper drepper@redhat.com Subject: [parisc-linux] Help with posix_types.h Cary Coutant writes: > On PA-RISC, the thread pointer is kept in the read-only control register > CR 27. > > For user-thread implementations, we provided a kernel API to change the > contents of the register. This works fine for a 1:1 thread implementation but adds significant runtime hits for a m:n implementation. The latter is the direction we are heading. -- ---------------. ,-. 1325 Chesapeake Terrace Ulrich Drepper \ ,-------------------' \ Sunnyvale, CA 94089 USA Red Hat `--' drepper at redhat.com `------------------------ From jsm@udlkern.fc.hp.com Thu, 16 Nov 2000 02:01:12 -0700 (MST) Date: Thu, 16 Nov 2000 02:01:12 -0700 (MST) From: John Marvin jsm@udlkern.fc.hp.com Subject: Single-stepping > I've been helping Alan Modra out with kernel changes to support > single stepping for gdb. Paul Bame suggested I bounced our ideas > off you in case you (or anyone else) had any comments. I havn't > actually committed my changes yet. > I've decided to respond to the whole list, since others are now participating in the discussion. > The basic approach is to use the recovery counter to generate > a trap every instruction. The scheme is complicated because a > suspended process may or may not return to user space via an RFI. > There is no easy way to do single stepping on parisc. So any single stepping design will be complicated. > If it was suspended as a result of an interrupt then we can > simply set PSW bit R in the tasks saved registers and it will > get loaded by the RFI. On every task switch I set the > recovery counter to 0, just in case the new process is being > single-stepped. > > If a process is suspended during a syscall, then there is no > RFI on the return path to userland, and we have to handle things > differently. I have changed the syscall return path such that > it loads the recovery counter with 3 before updating the PSW > with a value from the tasks saved registers. If that PSW has > the R bit set, then the count of 3 will generate a trap on the > first instruction following the branch back to user space. > Note that PSW wasn't previously restored on the syscall return > path. > Just to be clear, it is impossible to restore the entire PSW without an RFI. So, I assume you are referring to the system mask subset of the PSW that can be manipulated by the ssm,rsm, and mtsm instructions. You mention restoring from the task's saved registers, but we currently do not save the system mask during a syscall (because it should be the same for all processes). Have you added code to do that also? If not, you are restoring from whatever the state was at the last interruption. Which in this case works (since the R bit state will be changed by another process while the debugged process is suspended, this should guarantee that the R bit state is up to date), but it seems a little ugly. In my opinion, you should just be checking a bit in the ptrace flags in the task structure, and setting the R bit with an ssm instruction based on that. > To avoid further complications of interrupts during the three > instructions when the recovery counter is decrementing, whenever > we set the R bit, we also clear the I bit to disable interrupts. Yuck, but I agree that it would be messier to have to deal with this in the interrupt handlers. Please make sure that a comment is added that explains what you are doing, and clearly documents the dependency on the number of remaining instructions before we return to user privilege level. I assume you restore the I bit in the recovery counter trap handler. I can think of alternative ways of doing this, but they are probably just as ugly (e.g. one possibility would be to do an rfi to set the L bit). > > Nullified instructions are handled by the controlling process > manually moving the childs IAOQ over the instruction without > actually setting it running, because the recovery counter isn't > decremented for nullified instructions. Does this code properly handle branches in the delay slot of another branch? (you need to make sure you are not advancing the queues by just adding 4 to each element). One concern I have about this method is that the userland debugger has to cooperate to make this design work, i.e. the single stepping is not accomplished entirely within the kernel, so we cannot easily change the design for single stepping at a later date. I wonder if it is necessary to do this. So what if we don't stop on the nullified instruction. Since it is nullified, it doesn't actually do anything, so why does the user have to see it, i.e. just let the recovery counter trap happen on the next truly executed instruction (i.e. the debugger performs a "double step" in this case). Am I missing something here? > > I need to do some more testing before committing this, but would > welcome any comments on the basic approach taken, areas I have > mis-understood, or problems with it that might not yet have > occurred to me. OK, well here are some issues that you didn't mention, so I don't know whether or not you addressed them: 1) When single stepping over a syscall, when do you actually stop the single stepping and execute the syscall? Hopefully you are not allowing single stepping after the gate instruction on the gateway page (and returning control to a non privileged debugging process). The recovery counter trap should detect when the user code gets to the gateway page. 2) Does your solution properly handle single stepping into and out of a signal handler? Note that the debugger will trap the signal as part of this process. Since the return is handled through a hidden syscall you may not have to do anything special here. Note that HP-UX does not use the recovery counter for single stepping. I made a few phone calls to various engineers to find out what the design process was, and why they chose the solution they did, but I could not find anyone who knew. Looking at the code in HP-UX it looks like someone implemented that code a long time ago, and some of the engineers who have worked on it since don't understand it, because some of the comments added since then clearly show a lack of understanding of what is really going on. Others on this list have mentioned that MPE does use the recovery counter for single stepping. Of course, MPE is not a Unix clone, so just because it could be done on MPE doesn't mean that the recovery counter can cover all cases on Unix (e.g. I have no idea how signals and syscalls are implemented on MPE). But since I have no idea why the recovery counter was not used for HP-UX, I can't say it is the wrong way to go. I can't think of anything that will definitely rule it out, I'm just a little uncomfortable with the fact that HP-UX chose not to use it. One advantage of the HP-UX method is that it completely encapsulates the single stepping inside the kernel, so it can be changed if necessary, without having to modify gdb (and having to worry about old versions of gdb). Anyway, for reference, HP-UX does single stepping by using a combination of the taken branch trap, and loading the instruction queues such that the front of the queue points to the next instruction to be single stepped and the back of the queue points to the first of two break instructions on a "break" page. It does NOT insert break instructions into the code, so it does not adversely affect execution on a SMP machine. Note that we already put a bunch of break instructions before the syscall entry point on the gateway page, so it would be easy to use our gateway page for the "break page". This way, if the single stepped instruction branches, a taken branch trap will be taken (which is important in the case where the branch nullifies its delay slot). Otherwise, the instruction will be executed and then the break instruction at the known location on the "break" page will be executed. If the single stepped instruction nullifies the next instruction, the second break instruction on the "break" page will be executed. Note that this is the short explanation. It is not as simple as it sounds. One major complication is that branches with links don't work properly with the instruction queue magic, so the link register has to be updated in the taken branch trap handler. Also branch externals won't update the space of the space queue tail properly (again, that has to be fixed in the taken branch handler). I can provide more details if the recovery counter method doesn't work out. Sincerely, John Marvin jsm@fc.hp.com From marteaut@esiee.fr Thu, 16 Nov 2000 10:04:07 +0100 Date: Thu, 16 Nov 2000 10:04:07 +0100 From: Thomas Marteau marteaut@esiee.fr Subject: [parisc-linux] nfsroot - 712/60 - RPC - help Hi Jack, > (c) Copyright 1990-1993, Hewlett-Packard Company. > All rights reserved > > Press to stop boot sequence. > Selecting a system to boot. > > Booting > palo ipl jkp2866@redtower Wed Nov 15 12:44:21 CST 2000 > 0/vmlinux 1606438 bytes @ 0x6800 > 0/palo-cmdline '0/vmlinux HOME=/ TERM=LINUX root=/dev/nfs nfsroot=192.68.1.11:/tftpboot/pancho ' Are you sure that the command line is rigth? Is your Server address is 192.-68-.1.11 Here is probably your mistake! Bye, ESIEE Team Visit http://www.esiee.fr/puffin > Kernel: partition 0 file /vmlinux > ELF32 executable > > Entry 00100000 first 00100000 n 4 > Segment 0 load 00100000 size 1097900 mediaptr 0x1000 > Segment 1 load 0020e000 size 150520 mediaptr 0x10e000 > Segment 2 load 00234000 size 55900 mediaptr 0x133000 > Segment 3 load 00244000 size 8192 mediaptr 0x141000 > branching to kernel entry point 0x00100000 > Set default PSW W bit to 0 > PDC Console Initialized > The 32-bit Kernel has started... > Enabled FP coprocessor > Free memory starts at: 0xc026e000 > start_parisc(0x504d6c,0x504d6c,0x0,0x0) > PALO command line: 'HOME=/ TERM=LINUX root=/dev/nfs nfsroot=192.68.1.11:/tftpboot/pancho ' > PALO initrd 0-0 > model 00006000 00000481 00000000 00000000 77564139 00000000 00000004 00000072 00000072 > vers 0000000a > CPUID vers 0 rev 0 > Searching for devices in PDC firmware... processor hpa 0xfffbe000 > an older box... > Found devices From rhirst@linuxcare.com Thu, 16 Nov 2000 12:00:47 +0000 Date: Thu, 16 Nov 2000 12:00:47 +0000 From: Richard Hirst rhirst@linuxcare.com Subject: Single-stepping Hi John, On Thu, Nov 16, 2000 at 02:01:12AM -0700, John Marvin wrote: > Just to be clear, it is impossible to restore the entire PSW without > an RFI. So, I assume you are referring to the system mask subset of > the PSW that can be manipulated by the ssm,rsm, and mtsm instructions. Yes, mtsm in this case. > You mention restoring from the task's saved registers, but we currently > do not save the system mask during a syscall (because it should be the > same for all processes). Have you added code to do that also? If not, Yes I have. > you are restoring from whatever the state was at the last interruption. > Which in this case works (since the R bit state will be changed > by another process while the debugged process is suspended, this should > guarantee that the R bit state is up to date), but it seems a little ugly. > In my opinion, you should just be checking a bit in the ptrace flags > in the task structure, and setting the R bit with an ssm instruction > based on that. Sounds better, I'll look in to it. > > Nullified instructions are handled by the controlling process > > manually moving the childs IAOQ over the instruction without > > actually setting it running, because the recovery counter isn't > > decremented for nullified instructions. Sorry, I worded that very badly. The code that moves the childs IAOQ on is in the kernel, invoked as a result of the controlling process calling ptrace(PTRACE_SINGLESTEP...) when the childs N bit is set. > Does this code properly handle branches in the delay slot of another > branch? (you need to make sure you are not advancing the queues by just > adding 4 to each element). One concern I have about this method is that Current code does /* Nullified, just crank over the queue. */ task_regs(child)->iaoq[0] = task_regs(child)->iaoq[1]; task_regs(child)->iasq[0] = task_regs(child)->iasq[1]; task_regs(child)->iaoq[1] = task_regs(child)->iaoq[0] + 4; Does that look right to you? > I wonder if it is necessary to do this. So what if we don't stop on the > nullified instruction. Since it is nullified, it doesn't actually do > anything, so why does the user have to see it, i.e. just let the recovery > counter trap happen on the next truly executed instruction (i.e. the > debugger performs a "double step" in this case). Am I missing something > here? I don't see why we really need to stop on a nullified instruction, but I'll wait for Alan to comment as he wrote this initially. > 1) When single stepping over a syscall, when do you actually stop the > single stepping and execute the syscall? Hopefully you are not > allowing single stepping after the gate instruction on the gateway > page (and returning control to a non privileged debugging process). > The recovery counter trap should detect when the user code gets > to the gateway page. At the moment my test harness notes IAOQ=0x100 and stops single stepping, but obviously the kernel needs to enforce that. > 2) Does your solution properly handle single stepping into and out of > a signal handler? Note that the debugger will trap the signal as part > of this process. Since the return is handled through a hidden syscall > you may not have to do anything special here. Havn't looked at signal handling yet. > Note that HP-UX does not use the recovery counter for single stepping. I Thanks for the description of how HP-UX does it. I'll stick with the recovery counter for now as it does seem to be basically working. I'll also try to ensure that it is completely encapsulated within the kernel so it is less painful to change later, if need be. Thanks, Richard From rhirst@linuxcare.com Thu, 16 Nov 2000 12:09:57 +0000 Date: Thu, 16 Nov 2000 12:09:57 +0000 From: Richard Hirst rhirst@linuxcare.com Subject: [parisc-linux] Single-stepping On Wed, Nov 15, 2000 at 02:49:02PM -0500, John David Anglin wrote: > > I've been helping Alan Modra out with kernel changes to support > > single stepping for gdb. Paul Bame suggested I bounced our ideas > > off you in case you (or anyone else) had any comments. I havn't > > actually committed my changes yet. > > > > The basic approach is to use the recovery counter to generate > > a trap every instruction. The scheme is complicated because a > > suspended process may or may not return to user space via an RFI. > > I really don't know enough to comment on the implementation choice. Why > did you decide on this approach as opposed to inserting breaks and > enabling the taken branch branch trap (T)? It would appear that the recovery > counter was intended to provide software recovery from hardware faults > in fault tolerant systems. Possibly, Grant could comment on whether > it is actually useful for this purpose. Alan Modra made those early decisions, but I gather that he went for the recovery counter because it at least appears to be rather more straightforward. Richard From jsm@udlkern.fc.hp.com Thu, 16 Nov 2000 05:44:55 -0700 (MST) Date: Thu, 16 Nov 2000 05:44:55 -0700 (MST) From: John Marvin jsm@udlkern.fc.hp.com Subject: Single-stepping Richard, > > Sorry, I worded that very badly. The code that moves the childs > IAOQ on is in the kernel, invoked as a result of the controlling > process calling ptrace(PTRACE_SINGLESTEP...) when the childs N > bit is set. > Great. > > Does this code properly handle branches in the delay slot of another > > branch? (you need to make sure you are not advancing the queues by just > > adding 4 to each element). One concern I have about this method is that > > Current code does > > /* Nullified, just crank over the queue. */ > task_regs(child)->iaoq[0] = task_regs(child)->iaoq[1]; > task_regs(child)->iasq[0] = task_regs(child)->iasq[1]; > task_regs(child)->iaoq[1] = task_regs(child)->iaoq[0] + 4; > > Does that look right to you? > Yes, that is the correct way to do it (I'll assume the duplicated line is just a cut/paste error). > > I wonder if it is necessary to do this. So what if we don't stop on the > > nullified instruction. Since it is nullified, it doesn't actually do > > anything, so why does the user have to see it, i.e. just let the recovery > > counter trap happen on the next truly executed instruction (i.e. the > > debugger performs a "double step" in this case). Am I missing something > > here? > > I don't see why we really need to stop on a nullified instruction, but > I'll wait for Alan to comment as he wrote this initially. > Given the above, i.e. that this is being handled in the kernel anyway, I guess I don't really care which way this goes. Probably it is best to do it whatever way gdb on hp-ux presents it. > > 1) When single stepping over a syscall, when do you actually stop the > > single stepping and execute the syscall? Hopefully you are not > > allowing single stepping after the gate instruction on the gateway > > page (and returning control to a non privileged debugging process). > > The recovery counter trap should detect when the user code gets > > to the gateway page. > > At the moment my test harness notes IAOQ=0x100 and stops single stepping, > but obviously the kernel needs to enforce that. > You should also be checking the space. But yes, the kernel needs to enforce this for security reasons. You should be able to do it in the recovery counter trap handler (rather than having to test for it in the syscall path, which affects all processes). > > 2) Does your solution properly handle single stepping into and out of > > a signal handler? Note that the debugger will trap the signal as part > > of this process. Since the return is handled through a hidden syscall > > you may not have to do anything special here. > > Havn't looked at signal handling yet. > I'm not sure that there is a real issue here or not. HP-UX has some code for single stepping with respect to signal handlers, but I believe it may only be necessary due to the saved state necessary as part of the iaoq manipulation. Obviously you should test this case. > > Note that HP-UX does not use the recovery counter for single stepping. I > > Thanks for the description of how HP-UX does it. I'll stick with > the recovery counter for now as it does seem to be basically working. > I'll also try to ensure that it is completely encapsulated within the kernel > so it is less painful to change later, if need be. > Sounds ok with me. And as long as there are no corner cases, it probably is the best solution, assuming we don't find another application for the recovery counter. John From rhirst@linuxcare.com Thu, 16 Nov 2000 13:20:17 +0000 Date: Thu, 16 Nov 2000 13:20:17 +0000 From: Richard Hirst rhirst@linuxcare.com Subject: Single-stepping On Thu, Nov 16, 2000 at 05:44:55AM -0700, John Marvin wrote: > > Current code does > > > > /* Nullified, just crank over the queue. */ > > task_regs(child)->iaoq[0] = task_regs(child)->iaoq[1]; > > task_regs(child)->iasq[0] = task_regs(child)->iasq[1]; > > task_regs(child)->iaoq[1] = task_regs(child)->iaoq[0] + 4; > > > > Does that look right to you? > > Yes, that is the correct way to do it (I'll assume the duplicated line > is just a cut/paste error). It's not duplicated (iaoq v. iasq). > > At the moment my test harness notes IAOQ=0x100 and stops single stepping, > > but obviously the kernel needs to enforce that. > > > You should also be checking the space. But yes, the kernel needs to enforce > this for security reasons. You should be able to do it in the recovery > counter trap handler (rather than having to test for it in the syscall > path, which affects all processes). I might come back to you on that when I've thought some more. Thanks, Richard From ian.zink@maryville.com Thu, 16 Nov 2000 09:46:18 -0600 Date: Thu, 16 Nov 2000 09:46:18 -0600 From: Ian Zink ian.zink@maryville.com Subject: [parisc-linux] I got the serial console to work... After reading some posts, I went back to trying to use to a serial console to no avail.. Then.. suddenly it hit me. Do'y. The cable I was using was straight-through not Cross-over. Now I have the 712 all booted and running Debian. Very cool, indeed. Thanks for all for your help. I think I will still work on building a STI ISO for the fun of it :) Thanks much, Ian Zink, Systems Engineer Maryville Technologies 540 Maryville Centre, Suite 300 St. Louis, MO 63141 636/519-4182 (FAX) 636/519-4141 ian.zink@maryville.com www.maryville.com From marteaut@esiee.fr Thu, 16 Nov 2000 18:18:58 +0100 Date: Thu, 16 Nov 2000 18:18:58 +0100 From: Thomas Marteau marteaut@esiee.fr Subject: [parisc-linux] The config for 712 hp boxes This is a multi-part message in MIME format. ------=_NextPart_000_00A5_01C04FF9.B01CC3A0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Hi all, Here is the config file we use to compile a new kernel from the test10 sources. We have the console with the STI and an extra term on the serial port. Also, in this mail, you have the diff between our hp_keyb.c and the official one but it gives you the ~ and the ' and others scancodes. All this works for the 712 boxes. We were forced to reboot our box to test the new kernel but before the uptime was 3 days and 4 hours during which we ran dselect and did some compiling. All the files inclosed are downloadable at http://www.esiee.fr/~puffin/code/dl.html Bye, ESIEE Team ------=_NextPart_000_00A5_01C04FF9.B01CC3A0 Content-Type: application/octet-stream; name="keyb.patch" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="keyb.patch" diff -urN linux2/drivers/char/hp_keyb.c linux/drivers/char/hp_keyb.c=0A= --- linux2/drivers/char/hp_keyb.c Thu Nov 16 17:39:03 2000=0A= +++ linux/drivers/char/hp_keyb.c Thu Nov 16 17:18:54 2000=0A= @@ -70,12 +70,12 @@=0A= #define K_F8 0x42=0A= #define K_F9 0x43=0A= #define K_F10 0x44=0A= -#define K_F11 87=0A= -#define K_F12 88=0A= +#define K_F11 0x57=0A= +#define K_F12 0x58=0A= #define K_PRNT 0x54=0A= -#define K_SCRL 70=0A= -#define K_BRK 119=0A= -#define K_AGR K_NONE=0A= +#define K_SCRL 0x46=0A= +#define K_BRK 0x77=0A= +#define K_AGR 0x29=0A= #define K_1 0x02=0A= #define K_2 0x03=0A= #define K_3 0x04=0A= @@ -89,10 +89,10 @@=0A= #define K_MINS 0x0c=0A= #define K_EQLS 0x0d=0A= #define K_BKSP 0x0e=0A= -#define K_INS 110=0A= -#define K_HOME 102=0A= -#define K_PGUP 104=0A= -#define K_NUML 69=0A= +#define K_INS 0x6e=0A= +#define K_HOME 0x66=0A= +#define K_PGUP 0x68=0A= +#define K_NUML 0x45=0A= #define KP_SLH 0x62=0A= #define KP_STR 0x37=0A= #define KP_MNS 0x4a=0A= @@ -111,13 +111,13 @@=0A= #define K_RSBK 0x1b=0A= #define K_ENTR 0x1c=0A= #define K_DEL 111=0A= -#define K_END 107=0A= -#define K_PGDN 109=0A= +#define K_END 0x6b=0A= +#define K_PGDN 0x6d=0A= #define KP_7 0x47=0A= #define KP_8 0x48=0A= #define KP_9 0x49=0A= -#define KP_PLS 118=0A= -#define K_CAPS 58=0A= +#define KP_PLS 0x4e=0A= +#define K_CAPS 0x3a=0A= #define K_A 0x1e=0A= #define K_S 0x1f=0A= #define K_D 0x20=0A= @@ -146,7 +146,7 @@=0A= #define K_DOT 0x34=0A= #define K_FSLH 0x35=0A= #define K_RSFT 0x36=0A= -#define K_UP 103 =0A= +#define K_UP 0x67=0A= #define KP_1 0x4f=0A= #define KP_2 0x50=0A= #define KP_3 0x51=0A= @@ -156,11 +156,11 @@=0A= #define K_SPCE 0x39=0A= #define K_RALT 0x64=0A= #define K_RCTL 0x61=0A= -#define K_LEFT 105=0A= -#define K_DOWN 108=0A= -#define K_RGHT 106=0A= -#define KP_0 82=0A= -#define KP_DOT 83=0A= +#define K_LEFT 0x69=0A= +#define K_DOWN 0x6c=0A= +#define K_RGHT 0x6a=0A= +#define KP_0 0x52=0A= +#define KP_DOT 0x53=0A= =0A= static unsigned char keycode_translate[256] =3D=0A= {=0A= @@ -198,7 +198,7 @@=0A= =0A= /* ----- the following code stolen from pc_keyb.c */=0A= =0A= -#ifdef CONFIG_MAGIC_SYSRQ=0A= +=0A= unsigned char pckbd_sysrq_xlate[128] =3D=0A= "\000\0331234567890-=3D\177\t" /* 0x00 - 0x0f */=0A= "qwertyuiop[]\r\000as" /* 0x10 - 0x1f */=0A= @@ -207,7 +207,6 @@=0A= "\206\207\210\211\212\000\000789-456+1" /* 0x40 - 0x4f */=0A= "230\177\000\000\213\214\000\000\000\000\000\000\000\000\000\000" /* = 0x50 - 0x5f */=0A= "\r\000/"; /* 0x60 - 0x6f */=0A= -#endif=0A= =0A= /*=0A= * Translation of escaped scancodes to keycodes.=0A= ------=_NextPart_000_00A5_01C04FF9.B01CC3A0 Content-Type: application/octet-stream; name="config" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="config" #=0A= # Automatically generated by make menuconfig: don't edit=0A= #=0A= CONFIG_PARISC=3Dy=0A= # CONFIG_UID16 is not set=0A= =0A= #=0A= # Code maturity level options=0A= #=0A= CONFIG_EXPERIMENTAL=3Dy=0A= =0A= #=0A= # General options=0A= #=0A= # CONFIG_SMP is not set=0A= # CONFIG_KWDB is not set=0A= CONFIG_GSC=3Dy=0A= CONFIG_IOMMU_CCIO=3Dy=0A= CONFIG_GSC_LASI=3Dy=0A= CONFIG_PCI=3Dy=0A= CONFIG_GSC_DINO=3Dy=0A= CONFIG_PCI_LBA=3Dy=0A= CONFIG_IOSAPIC=3Dy=0A= CONFIG_IOMMU_SBA=3Dy=0A= =0A= #=0A= # Loadable module support=0A= #=0A= # CONFIG_MODULES is not set=0A= =0A= #=0A= # General setup=0A= #=0A= CONFIG_NET=3Dy=0A= # CONFIG_SYSVIPC is not set=0A= # CONFIG_BSD_PROCESS_ACCT is not set=0A= CONFIG_SYSCTL=3Dy=0A= # CONFIG_BINFMT_SOM is not set=0A= CONFIG_BINFMT_ELF=3Dy=0A= # CONFIG_BINFMT_MISC is not set=0A= # CONFIG_BINFMT_JAVA is not set=0A= =0A= #=0A= # Parallel port support=0A= #=0A= CONFIG_PARPORT=3Dy=0A= # CONFIG_PARPORT_PC is not set=0A= # CONFIG_PARPORT_GSC is not set=0A= # CONFIG_PARPORT_OTHER is not set=0A= # CONFIG_PARPORT_1284 is not set=0A= =0A= #=0A= # Block devices=0A= #=0A= # CONFIG_BLK_DEV_FD is not set=0A= # CONFIG_BLK_DEV_XD is not set=0A= # CONFIG_PARIDE is not set=0A= # CONFIG_BLK_CPQ_DA is not set=0A= # CONFIG_BLK_CPQ_CISS_DA is not set=0A= # CONFIG_BLK_DEV_DAC960 is not set=0A= # CONFIG_BLK_DEV_LOOP is not set=0A= # CONFIG_BLK_DEV_NBD is not set=0A= CONFIG_BLK_DEV_RAM=3Dy=0A= CONFIG_BLK_DEV_RAM_SIZE=3D4096=0A= CONFIG_BLK_DEV_INITRD=3Dy=0A= =0A= #=0A= # Networking options=0A= #=0A= # CONFIG_PACKET is not set=0A= # CONFIG_NETLINK is not set=0A= # CONFIG_NETFILTER is not set=0A= # CONFIG_FILTER is not set=0A= # CONFIG_UNIX is not set=0A= CONFIG_INET=3Dy=0A= # CONFIG_IP_MULTICAST is not set=0A= # CONFIG_IP_ADVANCED_ROUTER is not set=0A= CONFIG_IP_PNP=3Dy=0A= # CONFIG_IP_PNP_BOOTP is not set=0A= # CONFIG_IP_PNP_RARP is not set=0A= # CONFIG_NET_IPIP is not set=0A= # CONFIG_NET_IPGRE is not set=0A= # CONFIG_INET_ECN is not set=0A= # CONFIG_SYN_COOKIES is not set=0A= # CONFIG_IPV6 is not set=0A= # CONFIG_KHTTPD is not set=0A= # CONFIG_ATM is not set=0A= # CONFIG_IPX is not set=0A= # CONFIG_ATALK is not set=0A= # CONFIG_DECNET is not set=0A= # CONFIG_BRIDGE is not set=0A= # CONFIG_X25 is not set=0A= # CONFIG_LAPB is not set=0A= # CONFIG_LLC is not set=0A= # CONFIG_NET_DIVERT is not set=0A= # CONFIG_ECONET is not set=0A= # CONFIG_WAN_ROUTER is not set=0A= # CONFIG_NET_FASTROUTE is not set=0A= # CONFIG_NET_HW_FLOWCONTROL is not set=0A= =0A= #=0A= # QoS and/or fair queueing=0A= #=0A= # CONFIG_NET_SCHED is not set=0A= =0A= #=0A= # SCSI support=0A= #=0A= CONFIG_SCSI=3Dy=0A= CONFIG_BLK_DEV_SD=3Dy=0A= CONFIG_SD_EXTRA_DEVS=3D40=0A= # CONFIG_CHR_DEV_ST is not set=0A= # CONFIG_BLK_DEV_SR is not set=0A= CONFIG_CHR_DEV_SG=3Dy=0A= # CONFIG_SCSI_MULTI_LUN is not set=0A= # CONFIG_SCSI_CONSTANTS is not set=0A= =0A= #=0A= # SCSI low-level drivers=0A= #=0A= CONFIG_SCSI_LASI=3Dy=0A= CONFIG_SCSI_ZALON=3Dy=0A= CONFIG_SCSI_SYM53C8XX=3Dy=0A= CONFIG_SCSI_NCR53C8XX_DEFAULT_TAGS=3D8=0A= CONFIG_SCSI_NCR53C8XX_MAX_TAGS=3D32=0A= CONFIG_SCSI_NCR53C8XX_SYNC=3D20=0A= # CONFIG_SCSI_NCR53C8XX_PROFILE is not set=0A= # CONFIG_SCSI_NCR53C8XX_IOMAPPED is not set=0A= =0A= #=0A= # Network device support=0A= #=0A= CONFIG_NETDEVICES=3Dy=0A= CONFIG_LASI_82596=3Dy=0A= =0A= #=0A= # ARCnet devices=0A= #=0A= # CONFIG_ARCNET is not set=0A= # CONFIG_DUMMY is not set=0A= # CONFIG_BONDING is not set=0A= # CONFIG_EQUALIZER is not set=0A= # CONFIG_TUN is not set=0A= # CONFIG_NET_SB1000 is not set=0A= =0A= #=0A= # Ethernet (10 or 100Mbit)=0A= #=0A= CONFIG_NET_ETHERNET=3Dy=0A= # CONFIG_NET_VENDOR_3COM is not set=0A= # CONFIG_LANCE is not set=0A= # CONFIG_NET_VENDOR_SMC is not set=0A= # CONFIG_NET_VENDOR_RACAL is not set=0A= # CONFIG_AT1700 is not set=0A= # CONFIG_DEPCA is not set=0A= # CONFIG_HP100 is not set=0A= # CONFIG_NET_ISA is not set=0A= CONFIG_NET_PCI=3Dy=0A= # CONFIG_PCNET32 is not set=0A= # CONFIG_ADAPTEC_STARFIRE is not set=0A= # CONFIG_AC3200 is not set=0A= # CONFIG_APRICOT is not set=0A= # CONFIG_CS89x0 is not set=0A= # CONFIG_DE4X5 is not set=0A= CONFIG_TULIP=3Dy=0A= # CONFIG_DGRS is not set=0A= # CONFIG_DM9102 is not set=0A= # CONFIG_EEPRO100 is not set=0A= # CONFIG_LNE390 is not set=0A= # CONFIG_NATSEMI is not set=0A= # CONFIG_NE2K_PCI is not set=0A= # CONFIG_NE3210 is not set=0A= # CONFIG_ES3210 is not set=0A= # CONFIG_RTL8129 is not set=0A= # CONFIG_8139TOO is not set=0A= # CONFIG_SIS900 is not set=0A= # CONFIG_EPIC100 is not set=0A= # CONFIG_SUNDANCE is not set=0A= # CONFIG_TLAN is not set=0A= # CONFIG_VIA_RHINE is not set=0A= # CONFIG_WINBOND_840 is not set=0A= # CONFIG_NET_POCKET is not set=0A= =0A= #=0A= # Ethernet (1000 Mbit)=0A= #=0A= # CONFIG_ACENIC is not set=0A= # CONFIG_HAMACHI is not set=0A= # CONFIG_YELLOWFIN is not set=0A= # CONFIG_SK98LIN is not set=0A= # CONFIG_FDDI is not set=0A= # CONFIG_HIPPI is not set=0A= # CONFIG_PLIP is not set=0A= # CONFIG_PPP is not set=0A= # CONFIG_SLIP is not set=0A= =0A= #=0A= # Wireless LAN (non-hamradio)=0A= #=0A= # CONFIG_NET_RADIO is not set=0A= =0A= #=0A= # Token Ring devices=0A= #=0A= # CONFIG_TR is not set=0A= # CONFIG_NET_FC is not set=0A= # CONFIG_RCPCI is not set=0A= # CONFIG_SHAPER is not set=0A= =0A= #=0A= # Wan interfaces=0A= #=0A= # CONFIG_WAN is not set=0A= =0A= #=0A= # Character devices=0A= #=0A= CONFIG_VT=3Dy=0A= CONFIG_VT_CONSOLE=3Dy=0A= CONFIG_GSC_PS2=3Dy=0A= # CONFIG_HIL is not set=0A= CONFIG_SERIAL=3Dy=0A= # CONFIG_SERIAL_CONSOLE is not set=0A= CONFIG_SERIAL_GSC=3Dy=0A= # CONFIG_SERIAL_EXTENDED is not set=0A= # CONFIG_SERIAL_NONSTANDARD is not set=0A= CONFIG_UNIX98_PTYS=3Dy=0A= CONFIG_UNIX98_PTY_COUNT=3D256=0A= # CONFIG_PRINTER is not set=0A= # CONFIG_PPDEV is not set=0A= =0A= #=0A= # I2C support=0A= #=0A= # CONFIG_I2C is not set=0A= =0A= #=0A= # Mice=0A= #=0A= # CONFIG_BUSMOUSE is not set=0A= # CONFIG_MOUSE is not set=0A= =0A= #=0A= # Joysticks=0A= #=0A= # CONFIG_JOYSTICK is not set=0A= # CONFIG_QIC02_TAPE is not set=0A= =0A= #=0A= # Watchdog Cards=0A= #=0A= # CONFIG_WATCHDOG is not set=0A= CONFIG_GENRTC=3Dy=0A= # CONFIG_INTEL_RNG is not set=0A= # CONFIG_NVRAM is not set=0A= # CONFIG_RTC is not set=0A= # CONFIG_DTLK is not set=0A= # CONFIG_R3964 is not set=0A= # CONFIG_APPLICOM is not set=0A= =0A= #=0A= # Ftape, the floppy tape device driver=0A= #=0A= # CONFIG_FTAPE is not set=0A= # CONFIG_AGP is not set=0A= # CONFIG_DRM is not set=0A= =0A= #=0A= # File systems=0A= #=0A= # CONFIG_QUOTA is not set=0A= # CONFIG_AUTOFS_FS is not set=0A= # CONFIG_AUTOFS4_FS is not set=0A= # CONFIG_ADFS_FS is not set=0A= # CONFIG_ADFS_FS_RW is not set=0A= # CONFIG_AFFS_FS is not set=0A= # CONFIG_HFS_FS is not set=0A= # CONFIG_BFS_FS is not set=0A= # CONFIG_FAT_FS is not set=0A= # CONFIG_MSDOS_FS is not set=0A= # CONFIG_UMSDOS_FS is not set=0A= # CONFIG_VFAT_FS is not set=0A= # CONFIG_EFS_FS is not set=0A= # CONFIG_JFFS_FS is not set=0A= # CONFIG_CRAMFS is not set=0A= # CONFIG_RAMFS is not set=0A= CONFIG_ISO9660_FS=3Dy=0A= # CONFIG_JOLIET is not set=0A= # CONFIG_MINIX_FS is not set=0A= # CONFIG_NTFS_FS is not set=0A= # CONFIG_NTFS_RW is not set=0A= # CONFIG_HPFS_FS is not set=0A= CONFIG_PROC_FS=3Dy=0A= # CONFIG_DEVFS_FS is not set=0A= # CONFIG_DEVFS_MOUNT is not set=0A= # CONFIG_DEVFS_DEBUG is not set=0A= # CONFIG_DEVPTS_FS is not set=0A= # CONFIG_QNX4FS_FS is not set=0A= # CONFIG_QNX4FS_RW is not set=0A= # CONFIG_ROMFS_FS is not set=0A= CONFIG_EXT2_FS=3Dy=0A= # CONFIG_SYSV_FS is not set=0A= # CONFIG_SYSV_FS_WRITE is not set=0A= # CONFIG_UDF_FS is not set=0A= # CONFIG_UDF_RW is not set=0A= # CONFIG_UFS_FS is not set=0A= # CONFIG_UFS_FS_WRITE is not set=0A= =0A= #=0A= # Network File Systems=0A= #=0A= # CONFIG_CODA_FS is not set=0A= CONFIG_NFS_FS=3Dy=0A= # CONFIG_NFS_V3 is not set=0A= CONFIG_ROOT_NFS=3Dy=0A= # CONFIG_NFSD is not set=0A= # CONFIG_NFSD_V3 is not set=0A= CONFIG_SUNRPC=3Dy=0A= CONFIG_LOCKD=3Dy=0A= # CONFIG_SMB_FS is not set=0A= # CONFIG_NCP_FS is not set=0A= # CONFIG_NCPFS_PACKET_SIGNING is not set=0A= # CONFIG_NCPFS_IOCTL_LOCKING is not set=0A= # CONFIG_NCPFS_STRONG is not set=0A= # CONFIG_NCPFS_NFS_NS is not set=0A= # CONFIG_NCPFS_OS2_NS is not set=0A= # CONFIG_NCPFS_SMALLDOS is not set=0A= # CONFIG_NCPFS_MOUNT_SUBDIR is not set=0A= # CONFIG_NCPFS_NDS_DOMAINS is not set=0A= # CONFIG_NCPFS_NLS is not set=0A= # CONFIG_NCPFS_EXTRAS is not set=0A= =0A= #=0A= # Partition Types=0A= #=0A= # CONFIG_PARTITION_ADVANCED is not set=0A= CONFIG_MSDOS_PARTITION=3Dy=0A= # CONFIG_NLS is not set=0A= =0A= #=0A= # Sound Drivers=0A= #=0A= # CONFIG_SOUND is not set=0A= =0A= #=0A= # Console drivers=0A= #=0A= =0A= #=0A= # Frame-buffer support=0A= #=0A= # CONFIG_FB is not set=0A= CONFIG_STI_CONSOLE=3Dy=0A= CONFIG_DUMMY_CONSOLE=3Dy=0A= =0A= #=0A= # Kernel hacking=0A= #=0A= CONFIG_MAGIC_SYSRQ=3Dy=0A= ------=_NextPart_000_00A5_01C04FF9.B01CC3A0-- From grundler@cup.hp.com Thu, 16 Nov 2000 10:10:23 -0800 Date: Thu, 16 Nov 2000 10:10:23 -0800 From: Grant Grundler grundler@cup.hp.com Subject: [parisc-linux] The config for 712 hp boxes "Thomas Marteau" wrote: > Hi all, > > Here is the config file we use to compile a new kernel from the test10 > sources. We have the console with the STI and an extra term on the serial > port. Thomas - excellent - thanks! > Also, in this mail, you have the diff between our hp_keyb.c and the official > one but it gives you the ~ and the ' and others scancodes. I noticed this mail was directed to me - but I can't take ownership of this code. I have too many other things going on. Helge - can you commit this fix too? thanks, grant Grant Grundler Unix Systems Enablement Lab +1.408.447.7253 From deller@gmx.de Thu, 16 Nov 2000 19:25:49 +0100 Date: Thu, 16 Nov 2000 19:25:49 +0100 From: Helge Deller deller@gmx.de Subject: [parisc-linux] The config for 712 hp boxes On Thursday 16 November 2000 19:10, Grant Grundler wrote: > "Thomas Marteau" wrote: > > Hi all, > > > > Here is the config file we use to compile a new kernel from the test10 > > sources. We have the console with the STI and an extra term on the serial > > port. > > Thomas - excellent - thanks! > > > Also, in this mail, you have the diff between our hp_keyb.c and the official > > one but it gives you the ~ and the ' and others scancodes. > > I noticed this mail was directed to me - but I can't take ownership > of this code. I have too many other things going on. > > Helge - can you commit this fix too? Ok. I will test & evtl. commit it today. > > thanks, > grant > > Grant Grundler > Unix Systems Enablement Lab > +1.408.447.7253 > > --------------------------------------------------------------------------- > To unsubscribe: send e-mail to parisc-linux-request@thepuffingroup.com with > `unsubscribe' as the subject. From frank_rowand@mvista.com Thu, 16 Nov 2000 11:00:48 -0800 Date: Thu, 16 Nov 2000 11:00:48 -0800 From: Frank Rowand frank_rowand@mvista.com Subject: Single-stepping John Marvin wrote: > > Richard, > > > > > Sorry, I worded that very badly. The code that moves the childs > > IAOQ on is in the kernel, invoked as a result of the controlling > > process calling ptrace(PTRACE_SINGLESTEP...) when the childs N > > bit is set. > > > > Great. > > > > Does this code properly handle branches in the delay slot of another > > > branch? (you need to make sure you are not advancing the queues by just > > > adding 4 to each element). One concern I have about this method is that > > > > Current code does > > > > /* Nullified, just crank over the queue. */ > > task_regs(child)->iaoq[0] = task_regs(child)->iaoq[1]; > > task_regs(child)->iasq[0] = task_regs(child)->iasq[1]; > > task_regs(child)->iaoq[1] = task_regs(child)->iaoq[0] + 4; > > > > Does that look right to you? > > > > Yes, that is the correct way to do it (I'll assume the duplicated line > is just a cut/paste error). If iaoq[0] contains a branch, iaoq[1] is in the delay slot. The instruction executed after iaoq[1] would then typically _not_ be iaoq[0] + 4 (the next instruction would be the target of the branch at iaoq[0]). > Sounds ok with me. And as long as there are no corner cases, it probably > is the best solution, assuming we don't find another application for > the recovery counter. The recovery counter is very useful for performance measurement tools to understand the cycles per instruction of a code path. (Using the recovery counter for the debugger doesn't preclude using it for performance tools - you just can't easily use it for both purposes at the same instant in time.) > John -Frank -- Frank Rowand MontaVista Software, Inc From rhirst@linuxcare.com Thu, 16 Nov 2000 20:28:42 +0000 Date: Thu, 16 Nov 2000 20:28:42 +0000 From: Richard Hirst rhirst@linuxcare.com Subject: Single-stepping On Thu, Nov 16, 2000 at 11:00:48AM -0800, Frank Rowand wrote: > John Marvin wrote: > > > > Does this code properly handle branches in the delay slot of another > > > > branch? (you need to make sure you are not advancing the queues by just > > > > adding 4 to each element). One concern I have about this method is that > > > > > > Current code does > > > > > > /* Nullified, just crank over the queue. */ > > > task_regs(child)->iaoq[0] = task_regs(child)->iaoq[1]; > > > task_regs(child)->iasq[0] = task_regs(child)->iasq[1]; > > > task_regs(child)->iaoq[1] = task_regs(child)->iaoq[0] + 4; > > > > > > Does that look right to you? > > > > > > > Yes, that is the correct way to do it (I'll assume the duplicated line > > is just a cut/paste error). > > If iaoq[0] contains a branch, iaoq[1] is in the delay slot. The instruction > executed after iaoq[1] would then typically _not_ be iaoq[0] + 4 (the next > instruction would be the target of the branch at iaoq[0]). But the above code is only executed if the current instruction is nullified. In your example, the branch in iaoq[0] would be nullified and therefore never taken. Richard From deller@gmx.de Thu, 16 Nov 2000 22:28:50 +0100 Date: Thu, 16 Nov 2000 22:28:50 +0100 From: Helge Deller deller@gmx.de Subject: [parisc-linux] The config for 712 hp boxes On Thursday 16 November 2000 18:18, Thomas Marteau wrote: > Hi all, > > [....] > Also, in this mail, you have the diff between our hp_keyb.c and the official > one but it gives you the ~ and the ' and others scancodes. > [....] Hi ESIEE-Team ! Thanks for your patch ! I committed your patch into CVS and just tweaked it a little for CONFIG_MAGIC_SYSRQ. I hope this is ok for you ? If your time permits, I would like to ask, if you maybe also want to look at getting the CAPS-Lock-, Scroll-Lock- & Num-Lock-LED's working ? Furthermore you mention in your project-history on your homepage something about "keyboard and soundchip problems" (Oct. 24). I'm asking just out of curiousity: Did you thought about programming the on-board sound-chips (which I believe would be a hard job.) ? > Bye, > ESIEE Team Best regards, Helge Deller. From taggart@carmen.fc.hp.com Thu, 16 Nov 2000 19:25:26 -0700 Date: Thu, 16 Nov 2000 19:25:26 -0700 From: Matt Taggart taggart@carmen.fc.hp.com Subject: [parisc-linux] glibc merged to 2.2 Today Paul Bame and I merged/updated the puffin.external.hp.com glibc cvs to glibc 2.2. After the merge I cleaned up the differences between our cvs and 2.2, mostly comment differences and formatting changes. With the exception of the setjmp problem mentioned in, http://puffin.external.hp.com/mailing-lists/parisc-linux/2000/11-Nov/0091.html and the fact that we have/need newer "scripts/config.guess" and "scripts/config.sub", we are completely sync'ed up with glibc 2.2. -- Matt Taggart taggart@fc.hp.com From deller@gmx.de Fri, 17 Nov 2000 15:34:09 +0100 Date: Fri, 17 Nov 2000 15:34:09 +0100 From: Helge Deller deller@gmx.de Subject: [parisc-linux] The config for 712 hp boxes [CC'ed the list, so maybe someone else can comment too....] On Friday 17 November 2000 11:45, Thomas Marteau wrote: > Hi Helge, Hi, > > > ----- Original Message ----- > From: Helge Deller > To: Thomas Marteau > Cc: > Sent: Thursday, November 16, 2000 10:28 PM > Subject: Re: [parisc-linux] The config for 712 hp boxes > > > > On Thursday 16 November 2000 18:18, Thomas Marteau wrote: > > > Hi all, > > > > > > [....] > > > Also, in this mail, you have the diff between our hp_keyb.c and the > official > > > one but it gives you the ~ and the ' and others scancodes. > > > [....] > > > > Hi ESIEE-Team ! > > > > Thanks for your patch ! > > > > I committed your patch into CVS and just tweaked it a little for > > CONFIG_MAGIC_SYSRQ. I hope this is ok for you ? > We didn't really understand why pckbd_sysrq_xlate was here for. > If you can explain to us, it will be fine. The best documentation you can find is in linux/Documentation/sysrq.txt. The copy of pckbd_sysrq_xlate[] is a simple implementation of keyboard-scancodes to chars, which is used by drivers/char/keyboard.c to call handle_sysrq() from /drivers/char/sysrq.c. This means, that you can press Alt-PrintScr (=> SysRQ) and a char at the keyboard simultaniously and your machine for example syncs the disks, mounts all discs read-only or reboots your machine immediately. > > If your time permits, I would like to ask, if you maybe also want to look > at > > getting the CAPS-Lock-, Scroll-Lock- & Num-Lock-LED's working ? > Normally, you can see yours leds switching on/off but we did not init them. > So they are like boot admin switch them... ^^^^^^^ ^^^^^ ^^^ Sorry ? > But we would like to know how and where we have to init them > because we know how to. We have made test and it was working... I'm not sure, but I think you should check the code in lasikbd_leds() in hp_psaux.c. The initialization should maybe be done in the same file in the function lasi_ps2_register() before calling register_kbd_ops(). > > > Furthermore you mention in your project-history on your homepage something > > about "keyboard and soundchip problems" (Oct. 24). I'm asking just out of > > curiousity: Did you thought about programming the on-board sound-chips > (which > > I believe would be a hard job.) ? > Yes, it is in our internal todo list, if we have time to. Because we look at > it with Thierry, we saw that, for LASI, > you have an interface and then the chip to configure. But it is very > interesting... Yes it is, and it would be great if you worked on that too ! > > Also, we want to rule the power leds but they are different if the box is > 712 or B132 or ... So our question is how to implement > this kind of initialsation and deinitialisation in a linux kernel and in a > second time, how to do for differents kind of boxes. As far as I know / have heard, there are only two types of LED's (but I may be wrong here !). One is where the LED's are organized in a row on the front panel (as my local machines here), and the other one, where you have (LED/)LCD-Numbers on your front panel ? They differ how to be accessed and where the controlling registers are located. One method to distiguish them is maybe to place the special initialisation code into drivers/gsc/lasi.c and asp.c, depending on the machine and which method needs to be used. Since I don't have any real documentation or knowledge of the programming of the LEDs (beside of the PDC-calls I placed into setup.c), maybe someone else can better comment on that or give some documentation ? > > Thanks for your answers, Helge > Bye, > ESIEE Team Best regards, Helge Deller. From Arnaud.ATOCH@oecd.org Fri, 17 Nov 2000 16:30:42 +0100 Date: Fri, 17 Nov 2000 16:30:42 +0100 From: Arnaud.ATOCH@oecd.org Arnaud.ATOCH@oecd.org Subject: [parisc-linux] Booting 712 with CD 0.5 Is the following output the normal behavior of Linux-PARisc on a 712/100 ? kmem_create: Forcing size word alignment - nfs_fh kernel BUG at pci-dma.c:391! kernel BUG at pci-dma.c:400! kernel BUG at pci-dma.c:391! kernel BUG at pci-dma.c:400! kernel BUG at pci-dma.c:391! kernel BUG at pci-dma.c:400! VFS: Disk change detected on device sr(11,0) kernel BUG at pci-dma.c:391! kernel BUG at pci-dma.c:400! kernel BUG at pci-dma.c:391! kernel BUG at pci-dma.c:400! kernel BUG at pci-dma.c:391! kernel BUG at pci-dma.c:400! ISO 9660 Extensions: RRIP_1991A VFS: Mounted root (iso9660 filesystem) readonly. INIT: version 2.78 booting INIT: Entering runlevel: 2 Setting up /tmp ramdisk4096+0 records in 4096+0 records out mke2fs 1.19, 13-Jul-2000 for EXT2 FS 0.5b, 95/08/09 Filesystem label= OS type: Linux Block size=1024 (log=0) Fragment size=1024 (log=0) 1024 inodes, 4096 blocks 0 blocks (0.00%) reserved for the super user First data block=1 1 block group 8192 blocks per group, 8192 fragments per group 1024 inodes per group Writing inode tables: done Writing superblocks and filesystem accounting information: done INIT: Id "T0" respawni INIT: no more processe From rhirst@linuxcare.com Fri, 17 Nov 2000 15:39:55 +0000 Date: Fri, 17 Nov 2000 15:39:55 +0000 From: Richard Hirst rhirst@linuxcare.com Subject: [parisc-linux] SEGV signal handling bug (dynamic linking) Hi, Don't know if anyone expects this to work yet or not, but: ------------------------- cut ----------------------------- #include #include #include #include #include #include #include #include #include char *mem; void sig_handler(int sig) { int res; printf("Trapped!!!\n"); res = mprotect(mem, 4096, PROT_READ|PROT_WRITE); if (res < 0) { perror("mprotect"); exit(1); } } void install_handlers(void) { struct sigaction act; memset(&act, 0, sizeof(act)); act.sa_handler = sig_handler; sigaction(SIGSEGV, &act, NULL); } int main(int argc, char **argv) { int res; mem = malloc(8192); if (mem == NULL) { perror("malloc"); exit(1); } mem = (char *)(((int)mem + 4095) & ~0x0fff); res = mprotect(mem, 4096, PROT_READ); if (res < 0) { perror("mprotect"); exit(1); } install_handlers(); write(1, "Going\n", 6); mem[24] = 17; write(1, "Gone\n", 5); return 0; } ------------------------- cut ----------------------------- generates: Going Bus error plus the following on the console: do_page_fault() pid=167 command='ch' YZrvWESTHLNXBCVMcbcbcbcbOGFRQPDI PSW: 00000000000001001111111100001011 r0-3 00000000 fffff000 0000166f 00002944 r4-7 40138c38 2001fd8c 00002852 00000001 r8-11 00002862 0008b010 0009c290 0009cbf0 r12-15 00000000 00000000 0009cb50 00000000 r16-19 00000000 00000001 0000b71b 00000011 r20-23 00004000 40041fcc 40041fcc 00000008 r24-27 00000006 00001000 00000001 0000280c r28-31 00000006 00000020 20020140 40041fd7 sr0-4 00000000 00000003 00000000 0000000a sr4-8 0000000a 0000000a 0000000a 0000000a IASQ: 0000000a 0000000a IAOQ: 0000167b 0000167f IIR: 6293002e ISR: 0000000a IOR: 00004017 ORIG_R28: 00002880 !!die_if_kernel: ch(167): Unaligned data reference 28 YZrvWESTHLNXBCVMcbcbcbcbOGFRQPDI PSW: 00000000000011001111111100001011 r0-3 00000000 fffff000 20020140 00002944 r4-7 40138c38 2001fd8c 00002852 00000001 r8-11 00002862 0008b010 0009c290 0009cbf0 r12-15 00000000 00000000 0009cb50 00000000 r16-19 00000000 00000001 0000b71b 00000000 r20-23 0000289f 40041fcc 40041fcc 00000008 r24-27 200201d0 20020150 0000000b 0000280c r28-31 00000006 00000020 200203c0 40041fd7 sr0-4 00000000 00000003 00000000 0000000a sr4-8 0000000a 0000000a 0000000a 0000000a IASQ: 0000000a 0000000a IAOQ: 0000289b 0000289b IIR: 0e801096 ISR: 0000000a IOR: 0000289f ORIG_R28: 00002880 The first do_page_fault() is fine, it is the 'mem[24] = 17' line, but the second isn't. The corresponding code is at the end of .plt: 2898: 0e 80 10 96 ldw 0(sr0,r20),r22 289c: ea c0 c0 00 bv r0(r22) 28a0: 0e 88 10 95 ldw 4(sr0,r20),r21 28a4: ea 9f 1f dd b,l 2898 <__DTOR_END__+0x74>,r20 28a8: d6 80 1c 1e depwi 0,31,2,r20 28ac: 00 c0 ff ee # c0ffee 28b0: de ad be ef #deadbeef However, if I make it statically linked, it works fine, giving: Going Trapped!!! Gone Richard From bri@mojo.calyx.net Fri, 17 Nov 2000 10:49:22 -0500 (EST) Date: Fri, 17 Nov 2000 10:49:22 -0500 (EST) From: Brian S. Julin bri@mojo.calyx.net Subject: [parisc-linux] debian archive beware libpam JFYI to save other people some time. Before firing up "apt-get upgrade" you'll be best off putting a hold on all the libpam packages, as the 0.72-12 version on ftp.us.debian.org fails on a bad symbol in libpam-misc, which locks you out of the box except if you boot single. -- Brian S. Julin From grundler@cup.hp.com Fri, 17 Nov 2000 08:38:24 -0800 Date: Fri, 17 Nov 2000 08:38:24 -0800 From: Grant Grundler grundler@cup.hp.com Subject: [parisc-linux] Booting 712 with CD 0.5 Arnaud.ATOCH@oecd.org wrote: > Is the following output the normal behavior of Linux-PARisc on a 712/100 ? > > kmem_create: Forcing size word alignment - nfs_fh > kernel BUG at pci-dma.c:391! > kernel BUG at pci-dma.c:400! The bug is real. A driver is calling pci_map_single() and pci_unmap_single() without specifying which direction the DMA is going. Cache flushing on 712 (PCXL) systems needs to know. I'll assume it's the SCSI driver since it looks like we are talking to a SCSI CD-ROM. grant Grant Grundler Unix Systems Enablement Lab +1.408.447.7253 From drepper@redhat.com 17 Nov 2000 09:09:10 -0800 Date: 17 Nov 2000 09:09:10 -0800 From: Ulrich Drepper drepper@redhat.com Subject: [parisc-linux] SEGV signal handling bug (dynamic linking) Richard Hirst writes: > mem = malloc(8192); > if (mem == NULL) { > perror("malloc"); > exit(1); > } > mem = (char *)(((int)mem + 4095) & ~0x0fff); > res = mprotect(mem, 4096, PROT_READ); Read the Unix standard: The behavior of this function is unspecified if the mapping was not established by a call to mmap(). -- ---------------. ,-. 1325 Chesapeake Terrace Ulrich Drepper \ ,-------------------' \ Sunnyvale, CA 94089 USA Red Hat `--' drepper at redhat.com `------------------------ From grundler@cup.hp.com Fri, 17 Nov 2000 09:09:04 -0800 (PST) Date: Fri, 17 Nov 2000 09:09:04 -0800 (PST) From: Grant Grundler grundler@cup.hp.com Subject: [parisc-linux] pci-dma.c BUG(391/400) PATCH Hi all, The following patch tries to point a finger at the offender rather than just call attention to a problem in the service. I don't have a PCXL/L2 machine setup right now. Could someone test commit this patch for me? thanks, grant grundler <505>cvs diff arch/parisc/kernel/pci-dma.c Index: arch/parisc/kernel/pci-dma.c =================================================================== RCS file: /home/cvs/parisc/linux/arch/parisc/kernel/pci-dma.c,v retrieving revision 1.16 diff -u -p -r1.16 pci-dma.c --- pci-dma.c 2000/11/08 06:20:27 1.16 +++ pci-dma.c 2000/11/17 17:04:22 @@ -387,8 +387,10 @@ static void pa11_dma_free_consistent (st static dma_addr_t pa11_dma_map_single(struct pci_dev *dev, void *addr, size_t size, int direction) { - if (direction == PCI_DMA_NONE) - BUG(); + if (direction == PCI_DMA_NONE) { + printk(KERN_ERR "pa11_dma_map_single(PCI_DMA_NONE) called by %p\n", __builtin_return_address(0)); + BUG(); + } flush_kernel_dcache_range((unsigned long) addr, size); return virt_to_phys(addr); @@ -396,8 +398,10 @@ static dma_addr_t pa11_dma_map_single(st static void pa11_dma_unmap_single(struct pci_dev *dev, dma_addr_t dma_handle, size_t size, int direction) { - if (direction == PCI_DMA_NONE) - BUG(); + if (direction == PCI_DMA_NONE) { + printk(KERN_ERR "pa11_dma_unmap_single(PCI_DMA_NONE) called by %p\n", __builtin_return_address(0)); + BUG(); + } if (direction == PCI_DMA_TODEVICE) return; From Arnaud.ATOCH@oecd.org Fri, 17 Nov 2000 18:10:52 +0100 Date: Fri, 17 Nov 2000 18:10:52 +0100 From: Arnaud.ATOCH@oecd.org Arnaud.ATOCH@oecd.org Subject: [parisc-linux] Booting 712 with CD 0.5 Thanks for the enlightment. Should I try a new CD-ROM or should I wait untill next ISO image is created ? IS the shutdown also due to this bug ? Setting up /tmp ramdisk4096+0 records in 4096+0 records out mke2fs 1.19, 13-Jul-2000 for EXT2 FS 0.5b, 95/08/09 Filesystem label= OS type: Linux Block size=1024 (log=0) Fragment size=1024 (log=0) 1024 inodes, 4096 blocks 0 blocks (0.00%) reserved for the super user First data block=1 1 block group 8192 blocks per group, 8192 fragments per group 1024 inodes per group Writing inode tables: done Writing superblocks and filesystem accounting information: done INIT: Id "T0" respawni INIT: no more processe -----Original Message----- From: Grant Grundler [mailto:grundler@cup.hp.com] Sent: Friday, November 17, 2000 17:38 To: Arnaud.ATOCH@oecd.org Cc: parisc-linux@puffin.external.hp.com Subject: Re: [parisc-linux] Booting 712 with CD 0.5 Arnaud.ATOCH@oecd.org wrote: > Is the following output the normal behavior of Linux-PARisc on a 712/100 ? > > kmem_create: Forcing size word alignment - nfs_fh > kernel BUG at pci-dma.c:391! > kernel BUG at pci-dma.c:400! The bug is real. A driver is calling pci_map_single() and pci_unmap_single() without specifying which direction the DMA is going. Cache flushing on 712 (PCXL) systems needs to know. I'll assume it's the SCSI driver since it looks like we are talking to a SCSI CD-ROM. grant Grant Grundler Unix Systems Enablement Lab +1.408.447.7253 From rhirst@linuxcare.com Fri, 17 Nov 2000 17:38:18 +0000 Date: Fri, 17 Nov 2000 17:38:18 +0000 From: Richard Hirst rhirst@linuxcare.com Subject: [parisc-linux] SEGV signal handling bug (dynamic linking) On Fri, Nov 17, 2000 at 09:09:10AM -0800, Ulrich Drepper wrote: > Richard Hirst writes: > > > mem = malloc(8192); > > if (mem == NULL) { > > perror("malloc"); > > exit(1); > > } > > mem = (char *)(((int)mem + 4095) & ~0x0fff); > > res = mprotect(mem, 4096, PROT_READ); > > Read the Unix standard: > > The behavior of this function is unspecified if the mapping was not > established by a call to mmap(). Yeh, but it works on m68k and i386, and works on hppa if statically linked. And the code is in an example on the mprotect man page on my Mandrake7 box. Richard From drepper@redhat.com 17 Nov 2000 10:06:21 -0800 Date: 17 Nov 2000 10:06:21 -0800 From: Ulrich Drepper drepper@redhat.com Subject: [parisc-linux] SEGV signal handling bug (dynamic linking) Richard Hirst writes: > Yeh, but it works on m68k and i386, and works on hppa if statically > linked. And the code is in an example on the mprotect man page on > my Mandrake7 box. Then shoot the guy who wrote the man page. It's wrong and will never reliably work. -- ---------------. ,-. 1325 Chesapeake Terrace Ulrich Drepper \ ,-------------------' \ Sunnyvale, CA 94089 USA Red Hat `--' drepper at redhat.com `------------------------ From rhirst@linuxcare.com Fri, 17 Nov 2000 20:10:34 +0000 Date: Fri, 17 Nov 2000 20:10:34 +0000 From: Richard Hirst rhirst@linuxcare.com Subject: [parisc-linux] SEGV signal handling bug (dynamic linking) On Fri, Nov 17, 2000 at 09:09:10AM -0800, Ulrich Drepper wrote: > Richard Hirst writes: > > > mem = malloc(8192); > > if (mem == NULL) { > > perror("malloc"); > > exit(1); > > } > > mem = (char *)(((int)mem + 4095) & ~0x0fff); > > res = mprotect(mem, 4096, PROT_READ); > > Read the Unix standard: > > The behavior of this function is unspecified if the mapping was not > established by a call to mmap(). Changed my prog to use mmap and get the same problem. Richard From grundler@cup.hp.com Fri, 17 Nov 2000 13:50:46 -0800 Date: Fri, 17 Nov 2000 13:50:46 -0800 From: Grant Grundler grundler@cup.hp.com Subject: [parisc-linux] PDC firmware revision FAQ update Hi folks, The issue of PDC/firmware revs came up locally and sounded like a FAQ. I added "10. How can I check if the PDC (firmware) revision is the latest?" and what I knew/could find to our FAQ at: http://www.parisc-linux.org/faq.html The new FAQ entry should be visible to the world in the next hour or so. **** WARNING **** Firmware upgrades can *kill* your machine! **** WARNING **** Don't do it just because. Read the FAQ carefully. Take the time to figure out why you might need the upgrade and expose yourself to this risk. grant ps. please don't ask me why your favorite machine's PDC isn't listed. I don't run the referenced sites. From taggart@carmen.fc.hp.com Fri, 17 Nov 2000 18:26:19 -0700 Date: Fri, 17 Nov 2000 18:26:19 -0700 From: Matt Taggart taggart@carmen.fc.hp.com Subject: [parisc-linux] New cross compiler I have posted new i386/linux -> hppa/linux cross tools at, ftp://puffin.external.hp.com/pub/parisc/binaries/LinuxX86/xc-20001117.tar.gz it includes 32bit and 64bit cross-compilers and a static 32bit glibc 2.2. I have also updated the include tarball, ftp://puffin.external.hp.com/pub/parisc/src/include-20001117.tar.gz it includes glibc 2.2 headers and the latest kernel headers. -- Matt Taggart taggart@fc.hp.com From sandy@storm.ca Fri, 17 Nov 2000 22:54:58 -0500 Date: Fri, 17 Nov 2000 22:54:58 -0500 From: Sandy Harris sandy@storm.ca Subject: [parisc-linux] Host for 712/60 compiles A couple of us have 16 diskless 712/60s which we want to use for distributed processing on easily parallelized tasks like factoring and perhaps crypto cracking. A few questions arise. Is PARISC Linux far enough along to be useful for that? We need no monitor or console (except perhaps for initial debugging), no devices except ethernet, and expect to run only one process per machine, but we need stability. We'll need a host for cross-compiling. We have a 256 meg 715/100 with HP/UX which we expect to use as the host for booting, handing out chunks of work, storing results, etc. Should we compile there under HP/UX or would we get better tools on one of our Intel Linux boxes? Or is PARISC Linux far enough along we should put it on the 715 and get native compilation? From matthew@wil.cx Sat, 18 Nov 2000 07:08:12 +0000 Date: Sat, 18 Nov 2000 07:08:12 +0000 From: Matthew Wilcox matthew@wil.cx Subject: binutils taggart On Wed, Nov 15, 2000 at 05:16:02PM -0700, Matt Taggart wrote: > Modified files: > . : config.guess config.sub > > Log message: > New upstream versions from > http://subversions.gnu.org/cgi-bin/cvsweb/config/ > Now config.guess returns the right thing for hppa-linux so... we needed new versions anyway, even though we're not parisc-linux..? :-) [not bitter, just amused] -- Revolutions do not require corporate support. From matthew@wil.cx Sat, 18 Nov 2000 07:24:54 +0000 Date: Sat, 18 Nov 2000 07:24:54 +0000 From: Matthew Wilcox matthew@wil.cx Subject: [parisc-linux] CVS linux Vs. -test10 On Tue, Nov 14, 2000 at 09:35:01AM -0700, Paul Bame wrote: > > I've attached an overview of differences between our CVS linux sources ok, here's my memories. > * Lots of RCS $Revision$ differences in ACPI (a different 'cvs > import' would've eliminated these differences). i assume someone's already done the appropriate cvs admin -ko magic to fix this? > * drivers/char/Config.in: changes to support LASI, parisc real-time > clock (CONFIG_GENRTC) istr this was `stolen' from the m68k port by sammy. > * drivers/char/serial.c: support for GSC and A500 serial if they're working, send to Ted and he'll do an update with Linus at some point. > * drivers/net/eepro100.c: no clue about this one we were trying to get it to work for the Jan NYLWE show. i doubt we have any changes of note. does anyone have an eepro in an hp? > * drivers/video: STI and HP FB video drivers (iodccon is probably > worthless) agreed on iodccon. unless we're using it up until the point that one of the more advanced consoles takes over? i don't think we are now. > * fs/binfmt_elf.c,exec.c: changes for stack-grows-up? Yes, that's what they're for. > * fs/nfs/read.c: probably unnecessary hack for broken parisc64 gcc we certainly don't want to send it upstream, but we don't want to take it out until the bug is fixed. is fixing that bug on the webshite todo list? > * include/linux/binfmts.h,fs.h,kernel.h,tty.h,udf_fs_sb.h: > unnecessary differences? mostly, yes. > * include/linux/init.h: we use different section names -- why????, > probably some unnecessary other differences too because we use -ffunction-sections. text.init clashes with a function called init, and the linker just merges it into the text segment. we need it to be separate, so it became init.text. there's patches around to do this for other architectures too. just bad naming choices initially. > * include/linux/wait.h: parisc debugging -- should be removed yeah, that can die now. > * scripts/*: MANY differences here. Looks like a combination of > things we hacked to fix configuration problems plus MAYBE not > updating these files from new Linux versions in the past. 'make > menuconfig' is significantly different from upstream. Even the > mkdep.c program is different. ok. mea extremely culpa here. i had an exclude file which included the scripts/ directory. someone should now ditch our stuff, take what's in -test10, hack it till it works for us and check it in. -- Revolutions do not require corporate support. From bzeeb+hplinux@zabbadoz.net Sun, 19 Nov 2000 13:12:25 +0100 (CET) Date: Sun, 19 Nov 2000 13:12:25 +0100 (CET) From: Bjoern A. Zeeb bzeeb+hplinux@zabbadoz.net Subject: [parisc-linux] serial console ? Hi, I just started booting into a 715-100 using palinux-0.5.iso. I did read multiple times that I need serial console. So I plugged in serial cable I an normally using for x86 to x86 serial console on my linux router but I did not get anything on both serial ports :-( What information would one need to help ? personal contact is prefered. I would then sum up all information I got and post it to the list afterwards (if desired). Have to say: I am 'new' to those workstation and had to hoover it first after I got it ;) I also could have a 735-99 with some kind of graphic accelerator if that one would be better. -- Bjoern A. Zeeb bzeeb at Zabbadoz dot NeT 56 69 73 69 74 http://www.zabbadoz.net/ From bzeeb+hplinux@zabbadoz.net Sun, 19 Nov 2000 17:06:11 +0100 (CET) Date: Sun, 19 Nov 2000 17:06:11 +0100 (CET) From: Bjoern A. Zeeb bzeeb+hplinux@zabbadoz.net Subject: [parisc-linux] serial console ? On Sun, 19 Nov 2000, Bjoern A. Zeeb wrote: > I just started booting into a 715-100 using palinux-0.5.iso. > > I did read multiple times that I need serial console. So I plugged in > serial cable I an normally using for x86 to x86 serial console on my > linux router but I did not get anything on both serial ports :-( Hi, sorted out everything. serial cable was quite ok, but using cu I was never able to reach IPL. Using minicom and everything was fine. Had a great success afterwards: installed from CD (palinux-0.5.iso) Everthing worked at once out of the box :-) openssh was enabled on default :-)) only one bad touch: please do not enable portmapper on default. there are too much exploits out there these days. Short: Great great great work !!! -- Bjoern A. Zeeb bzeeb at Zabbadoz dot NeT 56 69 73 69 74 http://www.zabbadoz.net/ From dhazeghi@pacbell.net Sun, 19 Nov 2000 09:24:56 -0800 Date: Sun, 19 Nov 2000 09:24:56 -0800 From: dhazeghi@pacbell.net dhazeghi@pacbell.net Subject: [parisc-linux] glibc-latest tarball broken the glibc-latest tarball on pehc appears to be missing some important subdirectories like scripts and sysdeps. Perhaps a legacy of the 2.2 merge? Thanks, Dara Hazeghi From imatthae@grc.hp.com Sun, 19 Nov 2000 19:35:57 +0100 Date: Sun, 19 Nov 2000 19:35:57 +0100 From: Ingo Matthaes imatthae@grc.hp.com Subject: [parisc-linux] A500 and glibc woes finally we've got a A500 for palinux testing. Unfortunately we have some problems with it. A 32 bit kernel complains about a very old firmware and claims "that machine will probably never run linux" But in fact, it will :-) First question: Did anyone ever succeeded with a 32bit kernel on that hardware ? A 64 bit Kernel boots fine and recognizes all available hardware including the additional 100BT card. But it traps with the init which comes with the latest nfsroot tarball. I built a new one from the sourcesw of debians sysvlinux-2.78 and it does not trap anymore, but the kernel told me about unimplemented 32 syscalls. At this point I tried to build a 64 bit glibc in order to get a crt1.o , which is needed to builf for a 64bit init. Did anyone ever build a 64bit glibc out of the current cvs tree ? Today I've got ologue/epilogue insn (insn 433 431 435 (set (reg:DI 26 %r26) (reg:DI 2 %r2)) -1 (nil) (nil)) ../sysdeps/unix/sysv/linux/init-first.c:105: Unrecognizable insn: (insn 440 438 441 (set (reg:DI 24 %r24) (lo_sum:DI (reg:DI 1 %r1) (symbol_ref:DI ("LP$-001")))) -1 (insn_list 437 (nil)) (expr_list:REG_DEAD (reg:DI 1 %r1) (expr_list:REG_UNUSED (reg:DI 24 %r24) (nil)))) ../sysdeps/unix/sysv/linux/init-first.c:105: Internal compiler error in num_delay_slots, at insn-attrtab.c:2505 Thats the point I'm currently stucking. BTW If someone involved into the port with access to the internal HP Network needs access to that machine, please contact me. Later Ingo -- Tel: ++49-2102-908-210 German Response Center Fax: ++49-2102-907-934 Berliner Str. 111 Mailto: Ingo_Matthaes@hp.com 40880 Ratingen Germany HP Unix/Linux Competency Center Network and High AvailabilitY OpenPGP fingerprint = 4298E7785FFD65DC8950 14E9F17F8CB5B611AA4A From alan@linuxcare.com.au Mon, 20 Nov 2000 14:03:16 +1100 (EST) Date: Mon, 20 Nov 2000 14:03:16 +1100 (EST) From: Alan Modra alan@linuxcare.com.au Subject: Single-stepping On Thu, 16 Nov 2000, John Marvin wrote: > Anyway, for reference, HP-UX does single stepping by using a combination > of the taken branch trap, and loading the instruction queues such that the > front of the queue points to the next instruction to be single stepped and > the back of the queue points to the first of two break instructions on a > "break" page. It does NOT insert break instructions into the code, so it > does not adversely affect execution on a SMP machine. Note that we > already put a bunch of break instructions before the syscall entry point > on the gateway page, so it would be easy to use our gateway page for the > "break page". This way, if the single stepped instruction branches, a > taken branch trap will be taken (which is important in the case where the > branch nullifies its delay slot). Otherwise, the instruction will be > executed and then the break instruction at the known location on the > "break" page will be executed. If the single stepped instruction > nullifies the next instruction, the second break instruction on the > "break" page will be executed. This is the path I started out on for hppa-linux, then hit the problem of a branch that nullifies it's delay slot. At that point, I decided playing with IAOQ_back wouldn't work as I missed the solution of enabling taken branch traps. :-( If I'd seen this trick, then I would not have tried using the recovery counter, and even now, it may be better to go back to IAOQ fiddling. The recovery counter scheme has the disadvantage that there's only one of them so you need to save/restore over task swaps or introduce extra instructions in the syscall path - and be very careful. > Note that this is the short explanation. It is not as simple as it sounds. > One major complication is that branches with links don't work properly > with the instruction queue magic, so the link register has to be updated > in the taken branch trap handler. Also branch externals won't update > the space of the space queue tail properly (again, that has to be fixed > in the taken branch handler). I can provide more details if the recovery > counter method doesn't work out. I'm a little intrigued about these "complications". How can the link register or space _not_ be updated properly? As far as I can see, the only really tricky instruction to single-step is RFI - which shouldn't ever occur in userspace, and which we'd just emulate if it was important. Alan Modra -- Linuxcare. Support for the Revolution. From jsm@udlkern.fc.hp.com Sun, 19 Nov 2000 22:43:02 -0700 (MST) Date: Sun, 19 Nov 2000 22:43:02 -0700 (MST) From: John Marvin jsm@udlkern.fc.hp.com Subject: Single-stepping > > Note that this is the short explanation. It is not as simple as it sounds. > > One major complication is that branches with links don't work properly > > with the instruction queue magic, so the link register has to be updated > > in the taken branch trap handler. Also branch externals won't update > > the space of the space queue tail properly (again, that has to be fixed > > in the taken branch handler). I can provide more details if the recovery > > counter method doesn't work out. > > I'm a little intrigued about these "complications". How can the link > register or space _not_ be updated properly? As far as I can see, the > only really tricky instruction to single-step is RFI - which shouldn't > ever occur in userspace, and which we'd just emulate if it was important. The problem is that the link register is set to IAOQ_Back + 4. and in the case of ble, sr0 is set to IASQ_Back. Since we've played games with the queues, IAOQ_Back and IASQ_Back are pointing at the break page, not at the instruction following the branch. The additional complication is that the taken branch trap traps at the branch destination, not at the branch, so at the point of the trap you don't know where you came from in order to fix the problem easily. So, what HP-UX does is check each instruction before it executes it to see if it is a branch, and if so, what the link register is (and that is all that needs to be parsed, since we are not emulating the instruction). It then stores the branch location, and also sets some branch state flags (e.g. UBE for a branch external, and UBL for a branch with a link, both flags being set for a ble instruction). Then in the taken branch handler you have all the information you need to fix the queue. You also need to check this saved state if a signal handler is invoked while single stepping, so that the proper pc queue values can be saved in the signal context. John Marvin jsm@fc.hp.com From jsm@udlkern.fc.hp.com Sun, 19 Nov 2000 23:01:20 -0700 (MST) Date: Sun, 19 Nov 2000 23:01:20 -0700 (MST) From: John Marvin jsm@udlkern.fc.hp.com Subject: A500 and glibc woes Ingo, > > finally we've got a A500 for palinux testing. Unfortunately > we have some problems with it. > A 32 bit kernel complains about a very old firmware and claims > "that machine will probably never run linux" But in fact, it > will :-) Actually, there are no plans to ever support the A500 on a 32 bit kernel. The A500 only has 64 bit firmware, so in order to support it we would need to write a 32->64 bit firmware translation layer. ... > A 64 bit Kernel boots fine and recognizes all available hardware > including the additional 100BT card. But it traps with the init > which comes with the latest nfsroot tarball. I built a new one > from the sourcesw of debians sysvlinux-2.78 and it does not trap > anymore, but the kernel told me about unimplemented 32 syscalls. > At this point I tried to build a 64 bit glibc in order to get > a crt1.o , which is needed to builf for a 64bit init. > Well, it might seem crazy, but our short term plans do not include supporting a 64 bit user environment on the 64 bit kernel. Long term I believe this will happen, but as you have already seen, work needs to be done to support 64 bit glibc, shared libraries, etc. So, in order to get the A500 to boot, we need to support the 32 bit user environment on a 64 bit kernel. We've only recently gotten to the point where the 64 bit kernel gets far enough to start running user space applications. The problem is that we need to write translations for many system calls, since type sizes (and the structures those types are in) are different between 32 bit and 64 bit (the ugliest case is the ioctl system call). In summary, the A500 currently won't work, but since it is one of the machines that HP has targetted for Linux support, you can be sure that this will change fairly soon. John Marvin jsm@fc.hp.com From grundler@cup.hp.com Sun, 19 Nov 2000 22:47:27 -0800 Date: Sun, 19 Nov 2000 22:47:27 -0800 From: Grant Grundler grundler@cup.hp.com Subject: [parisc-linux] A500 and glibc woes Ingo Matthaes wrote: > finally we've got a A500 for palinux testing. Unfortunately > we have some problems with it. Ingo, uhmm...I'm not surprised. Let me help you understand the A500 and the direction we are going with support on the A500. I'm one of several people working on A500 support. A500 Features (marketing crud - you probably know this): o 16GB of RAM o 2-way 550 MHz PA8600 o 4 PCI-4X slots (3 of which are 1 slot per PCI bus) o all in 2U rack mountable box. Inside is (technical crud): o PCX-W+ o Astro IOMMU (aka SBA. Provides cache-coherent DMA and virtual I/O DMA) o Elroy PCI Host Bus Adapter (aka LBA) o IOSAPIC interrupt controller (integrated in Elroy) o PAT PDC (not legacy) o ^B for service processor access (ie I can reset the machine remotely) > A 32 bit kernel complains about a very old firmware and claims > "that machine will probably never run linux" But in fact, it > will :-) That's right! :^) > First question: Did anyone ever succeeded with a 32bit kernel > on that hardware ? No. Only on *64-bit* kernels. The reason is some of the PAT PDC calls we need are *only* available in wide mode. We could have written narrow<->wide mode translation routines but a 32-bit kernel ignores the A500's best feature - 16GB of RAM. The issue is HP needs good specweb99 numbers to sell these boxes and that requires GB of RAM. The 512MB of RAM that 32-bit kernel currently supports (jsm tells me 3GB or so can be done) won't approach the perf levels which can be acheived with 8 or 16GB. The HPUX specweb team (who just *beat* single CPU TUX specweb99 numbers with HPUX on A500) told me. They have a clue. You are welcome to write those translation routines and then *remove* many the "#ifdef __LP64__" preprocessor directives in arch/parisc/kernel/inventory.c and lba_pci.c. Send me the patch and I'll test/review/commit the changes. > A 64 bit Kernel boots fine and recognizes all available hardware > including the additional 100BT card. But it traps with the init > which comes with the latest nfsroot tarball. There are issues/problems with PCI resource management and I have some code waiting to be tested when I get in tomorrow. But you can be very helpful with user space! Perhaps Paul Bame can be more specific. But basically we don't have all the translation routines in place for 32-bit applications invoking 64-bit kernel syscalls. > I built a new one > from the sourcesw of debians sysvlinux-2.78 and it does not trap > anymore, but the kernel told me about unimplemented 32 syscalls. Right. > At this point I tried to build a 64 bit glibc in order to get > a crt1.o , which is needed to builf for a 64bit init. > > Did anyone ever build a 64bit glibc out of the current cvs tree ? I don't think so. Eventually we wanted to but haven't been able yet. So this great that you are trying! > Today I've got ... Can someone one with a clue about toolchain look at that? I'd be really impressed if someone got a 64-bit userspace built! I can help get kernel working right but don't have a clue about the tools. The 64-bit kernel can be booted on the following class of boxes to about the same point as the A500: o C160/180/200/240/360 o B2000/C3000/J5000/C3600/J5600/J6000 o some D/K/R-class machines The key is the box must have PCX-U (PA8000), PCX-U+ (PA8200), PCX-W (PA8500) or PCX-W+ (PA8600) processor. Look in the HWDB (http://www.parisc-linux.org/hw.html) or in /usr/sam/lib/mo/sched.models (HPUX 11.x) to determine which processor you have. > Thats the point I'm currently stucking. > > BTW If someone involved into the port with access to the internal HP > Network needs access to that machine, please contact me. Ditto. I can arrange access to my A500 as well. External access to some limited number of people could be arranged if demand is justifiable. But given the number of other boxes which can run 64-bit kernel, I hope that's not necessary. Thanks Ingo! grant Grant Grundler Unix Systems Enablement Lab +1.408.447.7253 From alan@linuxcare.com.au Mon, 20 Nov 2000 17:53:18 +1100 (EST) Date: Mon, 20 Nov 2000 17:53:18 +1100 (EST) From: Alan Modra alan@linuxcare.com.au Subject: Single-stepping On Sun, 19 Nov 2000, John Marvin wrote: > > I'm a little intrigued about these "complications". How can the link > > register or space _not_ be updated properly? As far as I can see, the > > only really tricky instruction to single-step is RFI - which shouldn't > > ever occur in userspace, and which we'd just emulate if it was important. > > The problem is that the link register is set to IAOQ_Back + 4. and in > the case of ble, sr0 is set to IASQ_Back. Since we've played games with > the queues, IAOQ_Back and IASQ_Back are pointing at the break page, not > at the instruction following the branch. Ah. That is a little nasty, especially given the effect on signal handlers you mention below. Maybe using the recovery counter isn't such a bad idea after all, especially since the added syscall and task switch overhead can be quite small if the kernel only supports single-step by one instruction. > The additional complication is that the taken branch trap traps at the > branch destination, not at the branch, so at the point of the trap you > don't know where you came from in order to fix the problem easily. So, > what HP-UX does is check each instruction before it executes it to see if > it is a branch, and if so, what the link register is (and that is all that > needs to be parsed, since we are not emulating the instruction). It then > stores the branch location, and also sets some branch state flags (e.g. > UBE for a branch external, and UBL for a branch with a link, both flags > being set for a ble instruction). Then in the taken branch handler you > have all the information you need to fix the queue. You also need > to check this saved state if a signal handler is invoked while single > stepping, so that the proper pc queue values can be saved in the signal > context. Another question for you and/or the list in general: Why does struct pt_regs have an ipsw field? Seems like it currently is unused. Regards, Alan Modra -- Linuxcare. Support for the Revolution. From grundler@cup.hp.com Sun, 19 Nov 2000 23:05:26 -0800 Date: Sun, 19 Nov 2000 23:05:26 -0800 From: Grant Grundler grundler@cup.hp.com Subject: [parisc-linux] Host for 712/60 compiles Sandy Harris wrote: > A couple of us have 16 diskless 712/60s which we want to use for distributed > processing on easily parallelized tasks like factoring and perhaps crypto > cracking. A few questions arise. > > Is PARISC Linux far enough along to be useful for that? We need no monitor or > console (except perhaps for initial debugging), no devices except ethernet, > and expect to run only one process per machine, but we need stability. It's not rock solid. On 712's, it should be pretty good though. > We'll need a host for cross-compiling. We have a 256 meg 715/100 with HP/UX > which we expect to use as the host for booting, handing out chunks of work, > storing results, etc. Should we compile there under HP/UX or would we get > better tools on one of our Intel Linux boxes? I don't think anyone has tried to cross-compile parisc-linux on an HPUX host in quite a while. > Or is PARISC Linux far enough along we should put it on the 715 and get > native compilation? AFAIK, all of the debian packages on the ISO image are built natively. But using a dual P700 linux box would be alot faster. :^) grant Grant Grundler Unix Systems Enablement Lab +1.408.447.7253 From sieler@allegro.com Sun, 19 Nov 2000 23:24:00 -0800 (PST) Date: Sun, 19 Nov 2000 23:24:00 -0800 (PST) From: Stan Sieler sieler@allegro.com Subject: Single-stepping Re: > handlers you mention below. Maybe using the recovery counter isn't such a quite true. > bad idea after all, especially since the added syscall and task switch > overhead can be quite small if the kernel only supports single-step by > one instruction. why the limit? We've used multi-instruction "single step" (oxymoron :) for about 15 years on PA-RISC...no problems, efficient, and *very* useful! -- Stan Sieler sieler@allegro.com www.allegro.com/sieler/wanted/index.html www.sieler.com From grundler@cup.hp.com Sun, 19 Nov 2000 23:44:42 -0800 Date: Sun, 19 Nov 2000 23:44:42 -0800 From: Grant Grundler grundler@cup.hp.com Subject: [parisc-linux] CVS linux Vs. -test10 Matthew Wilcox wrote: > On Tue, Nov 14, 2000 at 09:35:01AM -0700, Paul Bame wrote: > ok, here's my memories. Thanks Matthew! hehe...sounds like someone's getting older. :^) ... > > * drivers/net/eepro100.c: no clue about this one > > we were trying to get it to work for the Jan NYLWE show. I think I did that. IIRC, it's a one-line change to use I/O port space since MMIO wasn't usable without more invasive changes. > i doubt we have any changes of note. does anyone have an eepro in an hp? I have picked nearly 30 i82557/i82558 PCI cards from scrap yard. And maybe a few i82559 even. Did you need one (or two)? :^) FWIW, this is the card/driver which I think was causing misaligned data reference traps. I never had a chance to followup with this though. At the time, I thought it would be *really* fun to show this working to HP's marketing team... > > * fs/nfs/read.c: probably unnecessary hack for broken parisc64 gcc > > we certainly don't want to send it upstream, but we don't want to take it > out until the bug is fixed. is fixing that bug on the webshite todo list? I don't think so. It's possible it's already fixed. Relevant CVS log entry: | revision 1.5 | date: 2000/07/18 03:15:25; author: dhd; state: Exp; lines: +5 -0 | ARGH! When I put in an assertion, NFS stops breaking randomly. I | suspect this is a compiler or binutils problem but I can't see any | clear differences in the generated code. I'll debug it later... This sounds like the hppa64 bug we saw with %r29 getting trashed. But I don't think David was working on hppa64 kernel at the time. I can test 32-bit NFS Root tomorrow w/o assertion if no one else beats me to it. > > * include/linux/init.h: we use different section names -- why????, > > probably some unnecessary other differences too > > because we use -ffunction-sections. text.init clashes with a function > called init, and the linker just merges it into the text segment. we > need it to be separate, so it became init.text. there's patches around > to do this for other architectures too. just bad naming choices initially. We need to resolve this in order to merge upstream. Matthew, any advice on how we should proceed? Or would be easier for you pester Alan Cox and just get it fixed? > > * include/linux/wait.h: parisc debugging -- should be removed > > yeah, that can die now. I'd be happy to fix this by clobbering the current version with what's in linux-2.4.0-test10. But what is the "right" way to revert changes we've made so this doesn't show up in next merge? I'll need to know this in order to revert the fs/nfs/read.c change as well. thanks, grant Grant Grundler Unix Systems Enablement Lab +1.408.447.7253 From milang@tal.org Mon, 20 Nov 2000 10:57:36 +0200 Date: Mon, 20 Nov 2000 10:57:36 +0200 From: Kaj-Michael Lang milang@tal.org Subject: [parisc-linux] Palinux on a 712/60 > Thanks for the reply, Grant. However, the 712s do not have a serial console. Yes it does.. it's just undocumented. Unfortunately I don't have the information here, but I have succesfully changed the console to serial on one of my 712. Kaj-Michael Lang milang@tal.org From alan@linuxcare.com.au Mon, 20 Nov 2000 20:05:58 +1100 (EST) Date: Mon, 20 Nov 2000 20:05:58 +1100 (EST) From: Alan Modra alan@linuxcare.com.au Subject: Single-stepping On Sun, 19 Nov 2000, Stan Sieler wrote: > > bad idea after all, especially since the added syscall and task switch > > overhead can be quite small if the kernel only supports single-step by > > one instruction. > > why the limit? We've used multi-instruction "single step" (oxymoron :) > for about 15 years on PA-RISC...no problems, efficient, and *very* > useful! Because you would then need to save and restore cr0 on task switches (or only allow one task to be single-stepped at a time). That's four instructions and two extra memory accesses per task switch. Which might not seem very much, but at some point somebody will no doubt start caring about pa-linux performance. For a single-step by one, you can simply set cr0 to zero on a task switch, and possibly avoid touching cr0 on a task switch at all with careful attention to various trap handlers. Here's the idea. The tail of syscall_restore (64-bit stuff pruned) will look like the following, with the first three instructions being the added code to support single-step (and also wide/narrow switching for 64-bit) ldi 3,%r20 mtctl $r20,%cr0 /* recovery counter, ptrace single-step */ LDREG TASK_PT_PSW(%r1),%r20 mtctl %r1,%cr30 /* intrhandler okay. */ mfsp %sr3,%r1 /* Get users space id */ mtsp %r1,%sr4 /* Restore sr4 */ mtsp %r1,%sr5 /* Restore sr5 */ mtsp %r1,%sr6 /* Restore sr6 */ depi 3,31,2,%r31 /* ensure return to user mode. */ mtsm %r20 /* restore irq state */ mfctl %cr27,%r20 be 0(%sr3,%r31) /* return to user space */ mtsp %r1,%sr7 /* Restore sr7 */ ptrace will fiddle with TASK_PT_PSW, setting the R bit and clearing the I bit to enable the recovery counter - which will start counting down at the mtsm instruction above, and reach zero on the user-space instruction, so we'll trap after executing one user-space instruction. The task-switch nonsense is to handle the case where we page-fault on the instruction and switch to another task also doing single-stepping. You want to ensure cr0 is zero when we finally get back to the original task. Now it might turn out that having extra instructions in the syscall path is worse than extra code and memory accesses on task switch. If that turns out to be true, then you'll probably get your multi-step ptrace. :-) Alan Modra -- Linuxcare. Support for the Revolution. From M_Wild@tunstall.co.uk Mon, 20 Nov 2000 10:21:32 -0000 Date: Mon, 20 Nov 2000 10:21:32 -0000 From: Mark Wild M_Wild@tunstall.co.uk Subject: [parisc-linux] Upgrading memory on a 710 Hi, I have acquired some 8MB SIMMs suitable for my old 710 workstation and wish to utilise them. I don't have any docs for the 710 and was wondering if anyone could point me in the direction of some. I've looked on the HP website but could only find some for 712s, 720, 730 etc. Alternatively, if anyone knows whether any motherboard links need to be changed, whether SIMMS need to be added in pairs / quads and which memory configurations are allowed I would be grateful. Thanks, Mark Wild -- From matthew@wil.cx Mon, 20 Nov 2000 10:50:57 +0000 Date: Mon, 20 Nov 2000 10:50:57 +0000 From: Matthew Wilcox matthew@wil.cx Subject: [parisc-linux] A500 and glibc woes On Sun, Nov 19, 2000 at 07:35:57PM +0100, Ingo Matthaes wrote: > finally we've got a A500 for palinux testing. Unfortunately > we have some problems with it. > A 32 bit kernel complains about a very old firmware and claims > "that machine will probably never run linux" But in fact, it > will :-) > First question: Did anyone ever succeeded with a 32bit kernel > on that hardware ? It's not intended to work; I doubt anyone has tried. You should build a 64 bit kernel. > A 64 bit Kernel boots fine and recognizes all available hardware > including the additional 100BT card. But it traps with the init > which comes with the latest nfsroot tarball. I built a new one > from the sourcesw of debians sysvlinux-2.78 and it does not trap > anymore, but the kernel told me about unimplemented 32 syscalls. > At this point I tried to build a 64 bit glibc in order to get > a crt1.o , which is needed to builf for a 64bit init. Don't try a 64-bit userland yet. What you need to do is implement some of the 32-bit syscalls. -- Revolutions do not require corporate support. From matthew@wil.cx Mon, 20 Nov 2000 11:17:26 +0000 Date: Mon, 20 Nov 2000 11:17:26 +0000 From: Matthew Wilcox matthew@wil.cx Subject: [parisc-linux] CVS linux Vs. -test10 On Sun, Nov 19, 2000 at 11:44:42PM -0800, Grant Grundler wrote: > Matthew Wilcox wrote: > > On Tue, Nov 14, 2000 at 09:35:01AM -0700, Paul Bame wrote: > > ok, here's my memories. > > Thanks Matthew! > > hehe...sounds like someone's getting older. :^) ... when i were a lad, all this were fields! Our dad used to kill us every morning, we'd get up half an hour before we went to bed and walk uphill both to and from school... > ... > > > * drivers/net/eepro100.c: no clue about this one > > > > we were trying to get it to work for the Jan NYLWE show. > > I think I did that. IIRC, it's a one-line change to use I/O port > space since MMIO wasn't usable without more invasive changes. sounds right. MMIO should work now though, right? > > i doubt we have any changes of note. does anyone have an eepro in an hp? > > I have picked nearly 30 i82557/i82558 PCI cards from scrap yard. > And maybe a few i82559 even. Did you need one (or two)? :^) Heh, I only have a 712 right now :-) > FWIW, this is the card/driver which I think was causing misaligned > data reference traps. I never had a chance to followup with this though. > At the time, I thought it would be *really* fun to show this working > to HP's marketing team... Oh yes, I remember that now. Tulip always does a copy (well, it doesn't _have_ to, but we tell it to, just like the Alpha does). > > > * fs/nfs/read.c: probably unnecessary hack for broken parisc64 gcc > > > > we certainly don't want to send it upstream, but we don't want to take it > > out until the bug is fixed. is fixing that bug on the webshite todo list? > > I don't think so. It's possible it's already fixed. > > Relevant CVS log entry: > | revision 1.5 > | date: 2000/07/18 03:15:25; author: dhd; state: Exp; lines: +5 -0 > | ARGH! When I put in an assertion, NFS stops breaking randomly. I > | suspect this is a compiler or binutils problem but I can't see any > | clear differences in the generated code. I'll debug it later... > > This sounds like the hppa64 bug we saw with %r29 getting trashed. > But I don't think David was working on hppa64 kernel at the time. > I can test 32-bit NFS Root tomorrow w/o assertion if no one else > beats me to it. it was definitely a 32-bit kernel at the time. It might be the same bug, but I'm not sure. > > > * include/linux/init.h: we use different section names -- why????, > > > probably some unnecessary other differences too > > > > because we use -ffunction-sections. text.init clashes with a function > > called init, and the linker just merges it into the text segment. we > > need it to be separate, so it became init.text. there's patches around > > to do this for other architectures too. just bad naming choices initially. > > We need to resolve this in order to merge upstream. > Matthew, any advice on how we should proceed? > Or would be easier for you pester Alan Cox and just get it fixed? Hm. Alan's not hacking on 2.4, last I heard. I might pester Linus and see if we can change that. It's a mechanical change so he might not be averse to it at this point. Bear in mind we don't need to do a complete merge at this point -- most architectures have a separate patch to apply on top of Linus' tree. > > > * include/linux/wait.h: parisc debugging -- should be removed > > > > yeah, that can die now. > > I'd be happy to fix this by clobbering the current version with what's in > linux-2.4.0-test10. But what is the "right" way to revert changes we've made > so this doesn't show up in next merge? I don't know that there's an official way to do this. I always changed the file to its previous state and then committed it. There are a number of ways of doing it; perhaps the cleanest is: cvs diff -r1.4 -r1.5 fs/nfs/read.c >../read.c.diff (then check the read.c.diff file) patch -p1 <../read.c.diff rm ../read.c.diff or you can just delete the lines yourself. Use diff to make sure there aren't any silly cosmetic changes (eg whitespace). -- Revolutions do not require corporate support. From grundler@cup.hp.com Mon, 20 Nov 2000 09:34:31 -0800 Date: Mon, 20 Nov 2000 09:34:31 -0800 From: Grant Grundler grundler@cup.hp.com Subject: [parisc-linux] CVS linux Vs. -test10 Matthew Wilcox wrote: ... > sounds right. MMIO should work now though, right? It would have worked then too. Changing it to use MMIO space would require disabling I/O Port space by defining inb/outb locally to use gsc_readb/writeb. My problem with doing that was the semantics are slightly different. I/O Port space is non-postable and MMIO space is. I wasn't confident a driver written to use I/O port space would work right under MMIO though some certainly do. ... > it was definitely a 32-bit kernel at the time. It might be the same bug, > but I'm not sure. Can't be. AP (%r29) is a 64-bit only construct. dhd also just confirmed it was 32-bit kernel. I'll try it now. ... > > We need to resolve this in order to merge upstream. > > Matthew, any advice on how we should proceed? > > Or would be easier for you pester Alan Cox and just get it fixed? > > Hm. Alan's not hacking on 2.4, last I heard. I might pester Linus and > see if we can change that. It's a mechanical change so he might not be > averse to it at this point. Bear in mind we don't need to do a complete > merge at this point -- most architectures have a separate patch to apply > on top of Linus' tree. Ok. What's the first step to getting arch/parisc* and include/asm-parisc* into Linus's tree? I had dinner with Bdale Garbee last night and one of two things he made clear was we need to unfork from debian and linus's tree in order to move forward. All our CVS branches need to become obsolete or "local sandboxes" of the respective upstream partners. Feeding kernel bits upstream will bring a new level of visibility (and *HELP*) to the parisc-linux port. I totally agree with Bdale. I understand alot of work still needs to happen in our tree (eg though sba_iommu.c works, it's current form sucks) But pushing bits upstream to linus will not preclude us from doing that work. I also find it odd that glibc is merged upstream *before* the kernel is. For the record, the second issue bdale made clear was we need "boot floppies" debian package working. We don't need more ISO images (no offense to pjlahaie for his good work). "Boot floppies" is a pre-requisite to becoming part of the next debian release. Given I still don't have a clue how to build a debian package and I can still contribute alot in other areas, it doesn't make sense for me to do it myself. > > I'd be happy to fix this by clobbering the current version with what's in > > linux-2.4.0-test10. But what is the "right" way to revert changes we've made > > so this doesn't show up in next merge? > > I don't know that there's an official way to do this. I always changed > the file to its previous state and then committed it. There are a number of > ways of doing it; perhaps the cleanest is: > > cvs diff -r1.4 -r1.5 fs/nfs/read.c >../read.c.diff > (then check the read.c.diff file) > patch -p1 <../read.c.diff > rm ../read.c.diff > > or you can just delete the lines yourself. Use diff to make sure there > aren't any silly cosmetic changes (eg whitespace). The part you described above is the easy part - np. I'm worried about labels and tracking how we "name" the releases. Mang or other CVS ninja's care to comment? thanks, grant Grant Grundler Unix Systems Enablement Lab +1.408.447.7253 From rhirst@linuxcare.com Mon, 20 Nov 2000 17:58:38 +0000 Date: Mon, 20 Nov 2000 17:58:38 +0000 From: Richard Hirst rhirst@linuxcare.com Subject: [parisc-linux] signal handling problems (32 bit kernel) Hi, Following on from my problems with SEGV last week, I've come up with a few signal handling issues: ============================================================= parisc:signal.c /* Possibly bogus. */ #warning XXX FIXME probably bogus -PB /* I think this is bogus -- it'll cause the first instn of the * signal handler to be executed twice! Better might be to * set iaoq[0] to one of the NOPs in the trampoline. -PB */ regs->iaoq[0] = (unsigned long) haddr | 3; regs->iaoq[1] = (unsigned long) haddr | 3; This causes real problems if the signal handler is a dynamic object which has not yet been resolved; in that case the signal handler points at the b,l instr in the following at the end of the .plt: 2700: 0e 80 10 96 ldw 0(sr0,r20),r22 2704: ea c0 c0 00 bv r0(r22) 2708: 0e 88 10 95 ldw 4(sr0,r20),r21 270c: ea 9f 1f dd b,l 2700 <__DTOR_END__+0x54>,r20 2710: d6 80 1c 1e depwi 0,31,2,r20 typically that results in a misalligned access on the first ldw as r20 is screwed. I've fixed that by setting iaoq[1] = iaoq[0]+4. Is that OK, or should we use the NOP approach in the comment above? ============================================================= If a program gets a SEGV, fixes the cause of it in its signal handler, and returns, then the faulting instruction is not rerun. I think that's wrong (differs from m68k anyway). ============================================================= Set the following program running: #include #include #include #include int v[8]; void (* fp)(int); void sig_handler(int sig) { } void poke(int i) { v[0] = i; v[1] = i; v[2] = i; v[3] = i; v[4] = i; v[5] = i; v[6] = i; v[7] = i; } int main() { int j, i = 0; struct sigaction act; memset(&act, 0, sizeof(act)); act.sa_handler = sig_handler; sigaction(SIGUSR1, &act, NULL); fp = sig_handler; fp(0); printf("I am %d\n", getpid()); while (1) { poke (++i); j = v[7]; if (j != i) printf("Wah!\n"); } } and then in another terminal do 'kill -USR1 '. The program either goes 'Wah!', gives a SEGV, or works. That seems to be because %r1 is corrupted while processing the signal. The signal handler ends with a syscall (rt_sigreturn_wrapper), and %r1, at least, is not saved and restored over the syscall. %r31 also appears to get corrupted, as it is used in the final branch of the syscall return. Richard From sieler@allegro.com Mon, 20 Nov 2000 10:47:38 -0800 (PST) Date: Mon, 20 Nov 2000 10:47:38 -0800 (PST) From: Stan Sieler sieler@allegro.com Subject: Single-stepping Re: > Because you would then need to save and restore cr0 on task switches (or > only allow one task to be single-stepped at a time). That's four > instructions and two extra memory accesses per task switch. Which might > not seem very much, but at some point somebody will no doubt start caring > about pa-linux performance. And it still won't seem like much, then! Non-memory-access instructions are cheap. An extra memory reference (from something probably already in cache) and two extra instructions would probably cost less than an hour per CPU over the next 10 *years*, assuming 10 years of 1000 task switches per second on a slow 100 MHz CPU. Of course, at the cost of an extra non-memory-referencing instruction or so, you could say "at switch-to-task time: if PSW R-bit set, then load the saved CR0 from memory and move it to CR0", saving one memory reference 99.99999% of the time, resuling in an average of only one memory reference per task switch normally. I haven't look at interrupt handling / system calls closely, but I hope there aren't other false savings. (E.g., failure to save/restore the PID check flag ... sure, user processes *now* probably never have pid checking disabled, but that's a very useful feature to have available (with proper security controls, of course).) (Yes, I'm one of the very few who use that feature on MPE/iX ... carefully, of course :) -- Stan Sieler sieler@allegro.com www.allegro.com/sieler/wanted/index.html www.sieler.com From grundler@cup.hp.com Mon, 20 Nov 2000 11:23:40 -0800 Date: Mon, 20 Nov 2000 11:23:40 -0800 From: Grant Grundler grundler@cup.hp.com Subject: [parisc-linux] CVS linux Vs. -test10 Matthew Wilcox wrote: ... > > * fs/nfs/read.c: probably unnecessary hack for broken parisc64 gcc > > we certainly don't want to send it upstream, but we don't want to take it > out until the bug is fixed. is fixing that bug on the webshite todo list? It's fixed. I was able to NFS boot my A180 and install palinux-0.5.iso bits on the SCSI disk. I've reverted the change to the LINUS_240_TEST10 version. > > * include/linux/wait.h: parisc debugging -- should be removed > > yeah, that can die now. Is anyone else already doing this? thanks, grant Grant Grundler Unix Systems Enablement Lab +1.408.447.7253 From herrold@owlriver.com Mon, 20 Nov 2000 15:40:24 -0500 (EST) Date: Mon, 20 Nov 2000 15:40:24 -0500 (EST) From: herrold herrold@owlriver.com Subject: Serial vs. STI console selector was: Re: [parisc-linux] Beta CD On Tue, 14 Nov 2000, Paul J.Y. Lahaie wrote: > This is to answer all the questions about sti console. Currently, in the > CVS tree, serial console and STI console cannot be turned on at the same time. > > This means that a choice between serial/sti needs to be done at compile > time. > If you have any more questions or suggestions, feel free to email me or > post on this list. Thank you. ... Query -- Background: Back in the early 70's with a HP 8090 , IBM 1401, IBM 1620, and IBM 360/40, we faced such issues (Don't ask my age, please) -- The solution was to probe for, and look for 'sense switches' in unusual state -- that is -- Some condition which we could examine, and yet not hose up the boot proces on the host. -- CapsLock set on a keyboard driver -- DSR on a serial line, a 'console sense switch' normally kept off but turned on ... so on. Sort of like working through a qualitative analysis flowchart in non-organic chemistry. Is this possible, to allow support of both, with a single kernel? -- Russ From grundler@cup.hp.com Mon, 20 Nov 2000 12:59:41 -0800 Date: Mon, 20 Nov 2000 12:59:41 -0800 From: Grant Grundler grundler@cup.hp.com Subject: Serial vs. STI console selector was: Re: [parisc-linux] Beta CD "Russ" herrold wrote: > Is this possible, to allow support of both, with a single kernel? Yes. I think the issues are code not stomping on each other. And it's easy than you might think - PDC can tell us what the primary console is. grant Grant Grundler Unix Systems Enablement Lab +1.408.447.7253 From grundler@cup.hp.com Mon, 20 Nov 2000 17:19:03 -0800 (PST) Date: Mon, 20 Nov 2000 17:19:03 -0800 (PST) From: Grant Grundler grundler@cup.hp.com Subject: [parisc-linux] 712 ISL and palo Hi Paul (Bame), I tried booting 712 with "bo scsi.4.0 isl" with the palinux-0.5.iso image on a regular hard disk. I wanted to edit the "root" parameter so it would be /dev/sdb (also had a disk at scsi.0.0) instead of /dev/scd0. palo wouldn't accept any ps/2 keyboard input. Don't know if this is a palo or PDC bug. Any ideas? thanks, grant From alan@linuxcare.com.au Tue, 21 Nov 2000 12:55:42 +1100 (EST) Date: Tue, 21 Nov 2000 12:55:42 +1100 (EST) From: Alan Modra alan@linuxcare.com.au Subject: A DT_INIT/DT_FINI glibc patch. On Thu, 16 Nov 2000, H . J . Lu wrote: > While we are on this subject, I looked at the hppa code. It seems to > have the same bug. I have an impression that HP never really used > DT_INIT/DT_FINI. They use DT_INIT_ARRAY/DT_FINI_ARRAY. I don't know > if we should fix hppa also. Yes to all of these comments. elf32-hppa stole some ideas from ia64, which is why the bug is common. Fortunately, I think hppa ld.so etc. can be fixed in a way such that current (broken ABI) binaries will still work. Alan Modra -- Linuxcare. Support for the Revolution. From taggart@carmen.fc.hp.com Mon, 20 Nov 2000 20:12:33 -0700 Date: Mon, 20 Nov 2000 20:12:33 -0700 From: Matt Taggart taggart@carmen.fc.hp.com Subject: [parisc-linux] glibc-latest tarball broken dhazeghi@pacbell.net writes... > the glibc-latest tarball on pehc appears to be missing some important > subdirectories like scripts and sysdeps. Perhaps a legacy of the 2.2 > merge? Disk space problem. I made some room and generated new tarballs. Thanks for pointing out the problem. -- Matt Taggart taggart@fc.hp.com From alan@linuxcare.com.au Tue, 21 Nov 2000 14:22:53 +1100 (EST) Date: Tue, 21 Nov 2000 14:22:53 +1100 (EST) From: Alan Modra alan@linuxcare.com.au Subject: A DT_INIT/DT_FINI glibc patch. On Mon, 20 Nov 2000, Grant Grundler wrote: > I'm afraid we will break binary compatibility for elf32 hppa-linux again. > I only raise this in case there is really a "right" way to fix the > DT_INIT/DT_FINI problem. The fix involves pruning out all the special handling in bfd/elf32-hppa.c for DT_INIT,DT_FINI, and making some small changes to glibc. H.J. Lu has already made the necessary framework changes, and all we need to do is something like #define DL_FUNCTION_ADDRESS(map, addr) _dl_start_address (map, addr) #define DL_DT_INIT_ADDRESS(map, addr) \ ((addr) & 2 ? (addr) : DL_FUNCTION_ADDRESS (map, addr)) with similar defines for DT_FINI. The test for (addr) & 2 is the fairly innocuous fudge to support old binaries. Another glibc issue (which is why I'm sending this back to the list) is that there has been quite some discussion on the binutils list over the use of the EI_OSABI field. The conclusion being that it isn't really correct to use this field to discern the intendend execution platform. It's purpose is really to tell ELF tools that a file contains fields and values that need to be interpreted in a non-standard way. Since both elf32-hppa and elf64-hppa follow the standards, I'm inclined to think that the gnu tools should set EI_OSABI to zero for both HPUX and Linux targets. Instead the .note.ABI-tag section should be examined to determine the target, which sadly isn't set correctly at the moment. :-( Alan Modra -- Linuxcare. Support for the Revolution. From bame@riverrock.org Mon, 20 Nov 2000 21:02:40 -0700 Date: Mon, 20 Nov 2000 21:02:40 -0700 From: bame@riverrock.org bame@riverrock.org Subject: [parisc-linux] 712 ISL and palo = palo wouldn't accept any ps/2 keyboard input. = Don't know if this is a palo or PDC bug. = Any ideas? PALO bug. I didn't test the PS/2 case but I think I fixed it. -P From alan@linuxcare.com.au Tue, 21 Nov 2000 15:38:57 +1100 (EST) Date: Tue, 21 Nov 2000 15:38:57 +1100 (EST) From: Alan Modra alan@linuxcare.com.au Subject: A DT_INIT/DT_FINI glibc patch. On Tue, 21 Nov 2000, I wrote: > Instead the .note.ABI-tag section should be examined to determine the > target, which sadly isn't set correctly at the moment. :-( Actually, it is set correctly. A comment in csu/abi-note.S was wrong. -- Linuxcare. Support for the Revolution. From jsm@udlkern.fc.hp.com Mon, 20 Nov 2000 22:47:41 -0700 (MST) Date: Mon, 20 Nov 2000 22:47:41 -0700 (MST) From: John Marvin jsm@udlkern.fc.hp.com Subject: [parisc-linux] Use of the EI_OSABI field > Another glibc issue (which is why I'm sending this back to the list) is > that there has been quite some discussion on the binutils list over the > use of the EI_OSABI field. The conclusion being that it isn't really > correct to use this field to discern the intendend execution platform. > It's purpose is really to tell ELF tools that a file contains fields and > values that need to be interpreted in a non-standard way. Since both > elf32-hppa and elf64-hppa follow the standards, I'm inclined to think that > the gnu tools should set EI_OSABI to zero for both HPUX and Linux targets. I don't read the binutils mailing list, so I checked the archive. In my opinion I didn't see a discussion, I saw H.J. Lu repeatedly asserting this "fact". He may or may not be correct about original intention, but the implementation so far has been that EI_OSABI is used to tell what the target platform is. That is what FreeBSD is doing, that is what HP-UX is doing, and that is what the IA-64 Unix System V Application Binary Interface specifies: http://developer.intel.com/design/IA-64/Downloads/24537002.pdf Note that the second paragraph in section 1.1 of that specification includes the following: This document is the result of consensus among operating system vendors intending to provide UNIX and UNIX workalike operating systems on the IA-64 architecture. The vendors participating in this effort include Intel, Sun Microsystems, SCO, IBM, SGI, Cygnus Solutions, VA Linux Systems, HP, and Compaq. So, If the specification is wrong according to H.J. Lu, why did both Cygnus and VA Linux Systems not object to this: Section 4.1.1.4 Operating System Identification The e_ident[EI_OSABI] value identifies the operating system and ABI to which the object is targeted, as listed in Table 4-1. Table 4-1 lists the various ELFOSABI_* fields, e.g. ELFOSABI_HPUX, ELFOSABI_NETBSD, ELFOSABI_LINUX, etc. Note also, that the current mechanism for us to be able to differentiate elf executables in the Linux kernel is the machine dependent elf_check_arch() macro, whose only argument is a pointer to a elf32_hdr or elf64_hdr. I think it would be ugly to try to get the .note.ABI-tag section first for every exec of a new binary in order to determine what the target ABI is. In my opinion, unless H.J. Lu can get the IA-64 ABI changed, it is too late to assert his view of what that field was supposed to be. Please leave the EI_OSABI field set to ELFOSABI_LINUX until a better consensus on this issue is reached. John Marvin jsm@fc.hp.com From alan@linuxcare.com.au Tue, 21 Nov 2000 18:05:36 +1100 (EST) Date: Tue, 21 Nov 2000 18:05:36 +1100 (EST) From: Alan Modra alan@linuxcare.com.au Subject: [parisc-linux] signal handling problems (32 bit kernel) On Mon, 20 Nov 2000, Richard Hirst wrote: > #warning XXX FIXME probably bogus -PB > /* I think this is bogus -- it'll cause the first instn of the > * signal handler to be executed twice! Better might be to Definitely bogus, as with quite a lot of iaoq manipulation in signal.c > I've fixed that by setting iaoq[1] = iaoq[0]+4. Is that OK, or Sounds like the right thing to do. I reckon everywhere ioaq is fudged from/to r31 should have this sort of mapping. ie. it should be regs->gr[31] = regs->iaoq[0]; in sys_rt_sigreturn, and err |= __put_user(regs->gr[31], &sc->sc_iaoq[0]); err |= __put_user(regs->gr[31] + 4, &sc->sc_iaoq[1]); in setup_sigcontext, and so on. I'm guessing the origial author of this code didn't know which of iaoq[0] and ioaq[1] was ioaq_front. :) > and then in another terminal do 'kill -USR1 '. The program > either goes 'Wah!', gives a SEGV, or works. That seems to be because > %r1 is corrupted while processing the signal. The signal handler ends > with a syscall (rt_sigreturn_wrapper), and %r1, at least, is not saved > and restored over the syscall. %r31 also appears to get corrupted, as > it is used in the final branch of the syscall return. I don't really understand what is going on here, but it seems wrong to me that setup_rt_frame should be touching regs->iaoq at all when in_syscall. Hmm, and in that case why all the other gr[31] to/from ioaq[] fudgery? Alan -- Linuxcare. Support for the Revolution. From rhirst@linuxcare.com Tue, 21 Nov 2000 09:34:42 +0000 Date: Tue, 21 Nov 2000 09:34:42 +0000 From: Richard Hirst rhirst@linuxcare.com Subject: [parisc-linux] signal handling problems (32 bit kernel) On Tue, Nov 21, 2000 at 06:05:36PM +1100, Alan Modra wrote: > On Mon, 20 Nov 2000, Richard Hirst wrote: > > > #warning XXX FIXME probably bogus -PB > > /* I think this is bogus -- it'll cause the first instn of the > > * signal handler to be executed twice! Better might be to > > Definitely bogus, as with quite a lot of iaoq manipulation in signal.c As another example, if a process gets a signal as it is about to execute the instr in the delay slot of a branch, it forgets that it was supposed to be branching on return from the signal handler. Try compiling the following and sending it a SIGUSR1: #include #include #include #include void sig_handler(int sig) { } int main() { struct sigaction act; int i = 1; memset(&act, 0, sizeof(act)); act.sa_handler = sig_handler; sigaction(SIGUSR1, &act, NULL); printf("I am %d\n", getpid()); while (i++) ; printf("Escaped, i=%d!\n", i); return 0; } Oh, you have to run it with "LD_BIND_NOW=1 " to avoid one of the other problems. Time to try and work out what signal.c is really trying to do, I guess. Richard From alan@linuxcare.com.au Tue, 21 Nov 2000 22:26:14 +1100 (EST) Date: Tue, 21 Nov 2000 22:26:14 +1100 (EST) From: Alan Modra alan@linuxcare.com.au Subject: [parisc-linux] signal handling problems (32 bit kernel) On Tue, 21 Nov 2000, Richard Hirst wrote: > Time to try and work out what signal.c is really trying to do, I guess. Maybe you should start by considering all the possible states a task can be in when a signal is delivered, in regards to saved registers and stack layout. It would be a _very_ good idea to formalize this once you've sorted it out by splitting up struct pt_regs appropriately. ie. as other architectures do, into struct pt_regs and struct switch_stack. Actually, parisc could go one further and have three structures, one corresponding to registers saved on syscall entry (new pt_regs), one corresponding to macro callee_save (switch_stack), and one corresponding more or less to macro save_specials. Quite a bit of work, but IMO well worth doing. Alan Modra -- Linuxcare. Support for the Revolution. From matthew@wil.cx Tue, 21 Nov 2000 11:34:32 +0000 Date: Tue, 21 Nov 2000 11:34:32 +0000 From: Matthew Wilcox matthew@wil.cx Subject: [parisc-linux] CVS linux Vs. -test10 On Mon, Nov 20, 2000 at 09:34:31AM -0800, Grant Grundler wrote: > Ok. What's the first step to getting arch/parisc* and include/asm-parisc* > into Linus's tree? Someone (probably me) sends him a patch. He told me at the Toronto show that he was quite happy to apply anything that only touched those two directories. (oh, and drivers/gsc wouldn't be a problem either). Can I just check that no-one wants to rename drivers/gsc again? :-) > I had dinner with Bdale Garbee last night and one of two things he made > clear was we need to unfork from debian and linus's tree in order to move > forward. All our CVS branches need to become obsolete or "local sandboxes" > of the respective upstream partners. Feeding kernel bits upstream will > bring a new level of visibility (and *HELP*) to the parisc-linux port. that's true. last time we discussed this several people were unhappy with the idea of sending our current work to Linus. Is anyone unhappy with doing this now? > I also find it odd that glibc is merged upstream *before* the kernel is. glibc is more portable :-) > The part you described above is the easy part - np. > I'm worried about labels and tracking how we "name" the releases. > Mang or other CVS ninja's care to comment? don't tag it. just commit it. tags are laid down at big events, not when you fix bugs or undo changes. -- Revolutions do not require corporate support. From jsm@udlkern.fc.hp.com Tue, 21 Nov 2000 06:11:29 -0700 (MST) Date: Tue, 21 Nov 2000 06:11:29 -0700 (MST) From: John Marvin jsm@udlkern.fc.hp.com Subject: CVS linux Vs. -test10 > > I had dinner with Bdale Garbee last night and one of two things he made > > clear was we need to unfork from debian and linus's tree in order to move > > forward. All our CVS branches need to become obsolete or "local sandboxes" > > of the respective upstream partners. Feeding kernel bits upstream will > > bring a new level of visibility (and *HELP*) to the parisc-linux port. > > that's true. last time we discussed this several people were unhappy > with the idea of sending our current work to Linus. Is anyone unhappy > with doing this now? > Are we suggesting that we populate include/asm-parisc* and arch/parisc* WITHOUT the machine independent changes in the rest of the tree? If that is the case, I guess I don't object, although I would want to make sure that Linus knew the state of the code, and that it would not work without a patch containing changes to the machine independent part, and that followup patches to these branches are likely to be huge. We should also add a README in arch/parisc that explains the above (and where to get patches, how to access CVS, etc.). We also need someone to set up an automatic nightly? patch generator. I certainly don't want to try to get the machine independent changes in yet, since we still have some major issues to fix/clean there, and I doubt Linus would want them at this time anyway. John Marvin jsm@fc.hp.com From rhirst@linuxcare.com Tue, 21 Nov 2000 16:54:42 +0000 Date: Tue, 21 Nov 2000 16:54:42 +0000 From: Richard Hirst rhirst@linuxcare.com Subject: [parisc-linux] signal handling problems (32 bit kernel) On Tue, Nov 21, 2000 at 06:05:36PM +1100, Alan Modra wrote: > > and then in another terminal do 'kill -USR1 '. The program > > either goes 'Wah!', gives a SEGV, or works. That seems to be because > > %r1 is corrupted while processing the signal. The signal handler ends > > with a syscall (rt_sigreturn_wrapper), and %r1, at least, is not saved > > and restored over the syscall. %r31 also appears to get corrupted, as > > it is used in the final branch of the syscall return. > > I don't really understand what is going on here, but it seems wrong to me > that setup_rt_frame should be touching regs->iaoq at all when in_syscall. Problem is that whenever a signal handler is invoked, it is followed by a sys_rt_sigreturn syscall (invoked via the trampoline code), before returning to original usercode. I can imagine that this might work if the process in question was blocked on a syscall, but not if it was suspended due to an interrupt. In either case the path back to the original user code is the syscall return path, and that obviously cannot put things back as they were if the process was interrupted. I think the answer is for syscall_do_signal to save enough in the pt_regs such that sys_rt_sigreturn_wrapper can return to userland via an RFI (like intr_restore, but remembering to trace the syscall exit if necessary) regardless of the process state when the signal occurred. Richard From taggart@carmen.fc.hp.com Tue, 21 Nov 2000 10:20:35 -0700 Date: Tue, 21 Nov 2000 10:20:35 -0700 From: Matt Taggart taggart@carmen.fc.hp.com Subject: [parisc-linux] kernel BUG at sched.c:692! I arrived this morning to discover both my B160 and my C3000 were printing the following as fast as they could, Scheduling in interrupt kernel BUG at sched.c:692! Looking at linux/kernel/sched.c here's the relevant section, 690 scheduling_in_interrupt: 691 printk("Scheduling in interrupt\n"); 692 BUG(); 693 return; scheduling_in_interrupt is called from line 516. Here's some context, 500 asmlinkage void schedule(void) 501 { 502 struct schedule_data * sched_data; 503 struct task_struct *prev, *next, *p; 504 struct list_head *tmp; 505 int this_cpu, c; 506 507 if (!current->active_mm) BUG(); 508 if (tq_scheduler) 509 goto handle_tq_scheduler; 510 tq_scheduler_back: 511 512 prev = current; 513 this_cpu = prev->processor; 514 515 if (in_interrupt()) 516 goto scheduling_in_interrupt; 517 518 release_kernel_lock(prev, this_cpu); I thought it was odd that both systems chose to freak out last night when I have never seen this problem on either of them. The B160 is running a slightly newer kernel and had been up for about 3 days as of last night. The C3K had been up for 4-5 days. When I left last night the B160 was doing a build although the it looks like the build died before this problem occurred. The C3K was idle. Any ideas? Thanks, -- Matt Taggart taggart@fc.hp.com From robert.reilly@gecapital.com Tue, 21 Nov 2000 18:26:41 GMT Date: Tue, 21 Nov 2000 18:26:41 GMT From: Robert Reilly robert.reilly@gecapital.com Subject: [parisc-linux] cd .5 Hi All, I have HP9000/d212 I was able to boot off the cdrom image no problem, however when I get the login prompt I am only able to type in two characters and the screen redraws itself and prompts me for a login. I am using a HP700 serial terminal on ttyS0.I briefly scanned the mailing list but did not find anything. Any help would be appreciated. --Robert Reilly GE Capital Card Service UNIX Administrator robert.reilly@gecapital.com From matthew@wil.cx Tue, 21 Nov 2000 17:38:57 +0000 Date: Tue, 21 Nov 2000 17:38:57 +0000 From: Matthew Wilcox matthew@wil.cx Subject: CVS linux Vs. -test10 On Tue, Nov 21, 2000 at 06:11:29AM -0700, John Marvin wrote: > Are we suggesting that we populate include/asm-parisc* and arch/parisc* > WITHOUT the machine independent changes in the rest of the tree? Yes. > If that is the case, I guess I don't object, although I would want > to make sure that Linus knew the state of the code, and that it would > not work without a patch containing changes to the machine independent > part, and that followup patches to these branches are likely to be > huge. We should also add a README in arch/parisc that explains the > above (and where to get patches, how to access CVS, etc.). We also > need someone to set up an automatic nightly? patch generator. Agreed. The patch generation is not a big deal to arrange. > I certainly don't want to try to get the machine independent changes in > yet, since we still have some major issues to fix/clean there, and I doubt > Linus would want them at this time anyway. Certainly none of the stack direction changes. Some of the MI stuff is arguably stuff we could put in. -- Revolutions do not require corporate support. From Pirvulescu_Alexandru@telemobil.ro Tue, 21 Nov 2000 20:49:57 +0200 Date: Tue, 21 Nov 2000 20:49:57 +0200 From: Alexandru Pirvulescu Pirvulescu_Alexandru@telemobil.ro Subject: [parisc-linux] case LEDs Hello Is there any possibility to activate the case LEDs? I mean the heartbeat and the network activity I have a A180 machine Alex From grundler@cup.hp.com Tue, 21 Nov 2000 10:55:06 -0800 Date: Tue, 21 Nov 2000 10:55:06 -0800 From: Grant Grundler grundler@cup.hp.com Subject: [parisc-linux] case LEDs "Alexandru Pirvulescu" wrote: > Hello > > Is there any possibility to activate the case LEDs? I mean the heartbeat and > the network activity. I have a A180 machine. Yes. I was already asked this weekend to dig up technical info on LED and soft power control. I guess this is my reminder to do that. :^) grant From grundler@cup.hp.com Tue, 21 Nov 2000 10:59:24 -0800 Date: Tue, 21 Nov 2000 10:59:24 -0800 From: Grant Grundler grundler@cup.hp.com Subject: [parisc-linux] cd .5 Robert Reilly wrote: > Hi All, > I have HP9000/d212 I was able to boot off the cdrom image no problem, > however when I get the login prompt I am only able to type in two > characters and the screen redraws itself and prompts me for a login. I am > using a HP700 serial terminal on ttyS0. I briefly scanned the mailing list > but did not find anything. Any help would be appreciated. Robert, I would suspent the terminal isn't configured correctly for the serial connection. Is it set up for 9600 baud, 8 data bits, no parity, 1 stop bit? I'm pretty sure you have the baud rate correct since you get a login prompt. I'm not sure all the other things must be correct to get that far. I'm not familiar with "HP700 serial terminal". But all the HP terminals I've worked with in the past also support vt100 emulation mode. You probably want to set that too. grant Grant Grundler Unix Systems Enablement Lab +1.408.447.7253 From kailasr@webcash.com Tue, 21 Nov 2000 12:30:12 -0800 Date: Tue, 21 Nov 2000 12:30:12 -0800 From: Kailashnath V Rampure kailasr@webcash.com Subject: [parisc-linux] Apache package. Hi Paul, I have installed Apache + mod_ssl + mod_perl on HP A Class server. I need help on to change the server looking fort bootpd server and put the IP address on the system. Also where can I find the ftp client for linux . Regards Kalas At 04:59 PM 11/15/00 -0700, Paul Bame wrote: >= I tried to build apache_1.3.12 on HP a class server. But I have error. I >= have tried to check the site >= ftp://ftp.debian.org/debian/dists/unstable/main/binary-hppa/ >= I could not find one. I found some apache-doc etc. > >We are still working on some kernel features which are required to >support Apache (system 5 shared memory). > > -P From grundler@cup.hp.com Tue, 21 Nov 2000 13:24:31 -0800 Date: Tue, 21 Nov 2000 13:24:31 -0800 From: Grant Grundler grundler@cup.hp.com Subject: [parisc-linux] CVS linux Vs. -test10 Matthew Wilcox wrote: ... > Someone (probably me) sends him a patch. He told me at the Toronto > show that he was quite happy to apply anything that only touched those > two directories. (oh, and drivers/gsc wouldn't be a problem either). > Can I just check that no-one wants to rename drivers/gsc again? :-) Hi Mathew, I don't and it's a good question. I would like a few files moved: arch/parisc/kernel/ccio-dma.c -> drivers/gsc/ccio-dma.c arch/parisc/kernel/ccio-rm-dma.c -> drivers/gsc/ccio-rm-dma.c ccio will *always* be associated with a GSC bus since that's the secondary bus. And ccio supports devices below dino.c which already lives in drivers/gsc. arch/parisc/kernel/lba_pci.c -> drivers/ropes/lba_pci.c arch/parisc/kernel/sba_iommu.c -> drivers/ropes/sba_iommu.c arch/parisc/kernel/iosapic.c -> drivers/ropes/iosapic.c lba/sba code is equivalent to dino/ccio code for another set of platforms. And long term, I'm certain iosapic.c does not belong under arch/parisc. I can do this move if there are no major objections. Any reason why we couldn't do these moves *after* you submit a patch? FWIW, here are issues I see with merging IA64 iosapic code with mine: o iosapic "discovery" (I invented register_iosapic() interface for parisc) o parisc PDC calls (initialization) o interrupt policy decisions (eg EOI generation and picking a CPU) o I don't have time to do it in the near future. Folks working on IA64 stuff inside HP need to think about: (a) if they want to do the merge any time soon (b) which iosapic.c they want to start with (c) where the final version should live thanks, grant Grant Grundler Unix Systems Enablement Lab +1.408.447.7253 From pjlahaie@linuxcare.com Tue, 21 Nov 2000 16:41:48 -0500 Date: Tue, 21 Nov 2000 16:41:48 -0500 From: Paul J.Y. Lahaie pjlahaie@linuxcare.com Subject: [parisc-linux] Fun build problems --PW0Eas8rCkcu1VkF Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hello everyone, Over the last couple of days, I've been trying to get the debian boot-floppies building (I know some changes will be necessary) and as it stands now, several packages are missing. In the process of trying to compile/install these packages, I've run into some difficulties. Here are some of them: apt -- Package on pehc and .iso do not work. Missing lots of helper apps. Seeing as apt was broken, I decided to download the woody version of apt so I can get a newer version and hopefully skip some steps in building the above packages. gcc 2.96 and apt-0.3.19 don't get along, so I tried picking it up from cvs (supposed to have been fixed). Follow the directions on cvs.debian.org $ cvs -d :pserver:anonymous@cvs.debian.org:/cvs/APT login (Logging in to anonymous@cvs.debian.org) CVS password:=20 cvs login: authorization failed: server cvs.debian.org rejected access Anyone know if there are other instructions other than what cvs.debian.org says? If so, feel free to email me rsync -- ldd crashes on dpkg-shlibdepends stage Can I just manually put the required dependancies in? autoconf -- installinfo spins When installing the autoconf package (to compile dpkg) installinfo spins. And after several minutes still doesn't return. It's taking up 100% cpu at the time. If I abort this, autoconf seems to be installed but cannot generate the dpkg configure properly, some macros are missing AM_CONDITIONAL(HAVE_CPLUSPLUS, test "$CXX" !=3D "") Is in the ./configure script. info -- Reinstall spins If I try to reinstall info, it spins on the uninstall. 100% cpu. If anyone has any solutions for any of the above problems, I am all ears (eyes?). - Paul --PW0Eas8rCkcu1VkF Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.4 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE6Guwc8ggPQthPCzcRAgkGAJ9TzClXOg009RWO/v09ONBNnxJcbgCfcWcX gj26osR06BqyJ0O+/Q83csk= =YHRW -----END PGP SIGNATURE----- --PW0Eas8rCkcu1VkF-- From alan@linuxcare.com.au Wed, 22 Nov 2000 09:50:05 +1100 (EST) Date: Wed, 22 Nov 2000 09:50:05 +1100 (EST) From: Alan Modra alan@linuxcare.com.au Subject: [parisc-linux] Use of the EI_OSABI field cc to binutils because John makes some salient points. On Mon, 20 Nov 2000, John Marvin wrote: > > Another glibc issue (which is why I'm sending this back to the list) is > > that there has been quite some discussion on the binutils list over the > > use of the EI_OSABI field. The conclusion being that it isn't really > > correct to use this field to discern the intendend execution platform. > > It's purpose is really to tell ELF tools that a file contains fields and > > values that need to be interpreted in a non-standard way. Since both > > elf32-hppa and elf64-hppa follow the standards, I'm inclined to think that > > the gnu tools should set EI_OSABI to zero for both HPUX and Linux targets. > > I don't read the binutils mailing list, so I checked the archive. In my > opinion I didn't see a discussion, I saw H.J. Lu repeatedly asserting > this "fact". He may or may not be correct about original intention, but > the implementation so far has been that EI_OSABI is used to tell what the > target platform is. That is what FreeBSD is doing, that is what HP-UX is > doing, and that is what the IA-64 Unix System V Application Binary > Interface specifies: > > http://developer.intel.com/design/IA-64/Downloads/24537002.pdf > > Note that the second paragraph in section 1.1 of that specification > includes the following: > > This document is the result of consensus among operating system > vendors intending to provide UNIX and UNIX workalike operating > systems on the IA-64 architecture. The vendors participating in > this effort include Intel, Sun Microsystems, SCO, IBM, SGI, > Cygnus Solutions, VA Linux Systems, HP, and Compaq. > > So, If the specification is wrong according to H.J. Lu, why did both > Cygnus and VA Linux Systems not object to this: > > Section 4.1.1.4 Operating System Identification > > The e_ident[EI_OSABI] value identifies the operating system and > ABI to which the object is targeted, as listed in Table 4-1. > > Table 4-1 lists the various ELFOSABI_* fields, e.g. ELFOSABI_HPUX, > ELFOSABI_NETBSD, ELFOSABI_LINUX, etc. > > Note also, that the current mechanism for us to be able to differentiate > elf executables in the Linux kernel is the machine dependent > elf_check_arch() macro, whose only argument is a pointer to a > elf32_hdr or elf64_hdr. I think it would be ugly to try to get the > .note.ABI-tag section first for every exec of a new binary in order > to determine what the target ABI is. > > In my opinion, unless H.J. Lu can get the IA-64 ABI changed, it is too > late to assert his view of what that field was supposed to be. Please > leave the EI_OSABI field set to ELFOSABI_LINUX until a better consensus > on this issue is reached. > > John Marvin > jsm@fc.hp.com I'm happy enough to leave things as they are in puffin CVS, but these changes haven't been merged back to sourceware yet, partly because I had some doubts myself as to whether setting EI_OSABI was correct. H.J. Lu wasn't the only one arguing that EI_OSABI should be left at zero; Ulrich Drepper also was quite vehement against changing sourceware FreeBSD binutils. BTW, it's not too hard to check .note.ABI-tag. The linker arranges for a PT_NOTE program header entry to point to it, and the section itself is virtually guaranteed to be read in with the header as it's placed right after the header along with .interp. Alan Modra -- Linuxcare. Support for the Revolution. From drepper@redhat.com 21 Nov 2000 15:27:19 -0800 Date: 21 Nov 2000 15:27:19 -0800 From: Ulrich Drepper drepper@redhat.com Subject: [parisc-linux] Use of the EI_OSABI field Alan Modra writes: > Ulrich Drepper also was quite vehement against changing sourceware > FreeBSD binutils. I've never said anything about any *BSD, why should I? The *BSD people wanted to change the Linux binutils. Anyway, the ABI value is zero unless you implement ELF extensions. -- ---------------. ,-. 1325 Chesapeake Terrace Ulrich Drepper \ ,-------------------' \ Sunnyvale, CA 94089 USA Red Hat `--' drepper at redhat.com `------------------------ From alan@linuxcare.com.au Wed, 22 Nov 2000 11:13:29 +1100 (EST) Date: Wed, 22 Nov 2000 11:13:29 +1100 (EST) From: Alan Modra alan@linuxcare.com.au Subject: [parisc-linux] Use of the EI_OSABI field On 21 Nov 2000, Ulrich Drepper wrote: > Alan Modra writes: > > > Ulrich Drepper also was quite vehement against changing sourceware > > FreeBSD binutils. > > I've never said anything about any *BSD, why should I? The *BSD > people wanted to change the Linux binutils. Sorry, I stated that badly. > Anyway, the ABI value is zero unless you implement ELF extensions. Exactly what is an "ELF extension"? Anything outside gABI or "gABI + psABI"? Handly the latter, as it seems to me that a processor specific ABI can specify extensions. There's also the awkward possibility that a psABI may specify an extension that is later incorporated into a new revision of the gABI (eg. hpux and DT_INIT_ARRAY) Does that mean that if a new revision of the gABI completely incorporates all previous extensions, that EI_OSABI should become zero? Yes, I'm arguing that "No ELF extensions => EI_OSABI == 0" is not necessarily true, but I'm _not_ arguing that changing x86 Linux binutils is wise. Historical usage is important. If we were to change x86 Linux binutils to set EI_OSABI, then that can only be after a considerable period of time to allow code such as glibc to accept a new branding. Alan Modra -- Linuxcare. Support for the Revolution. From drepper@redhat.com 21 Nov 2000 16:31:39 -0800 Date: 21 Nov 2000 16:31:39 -0800 From: Ulrich Drepper drepper@redhat.com Subject: [parisc-linux] Use of the EI_OSABI field Alan Modra writes: > Exactly what is an "ELF extension"? Anything outside gABI or > "gABI + psABI"? Anything beyond the psABI that cannot be handled by the rules in the gABI. -- ---------------. ,-. 1325 Chesapeake Terrace Ulrich Drepper \ ,-------------------' \ Sunnyvale, CA 94089 USA Red Hat `--' drepper at redhat.com `------------------------ From hjl@valinux.com Tue, 21 Nov 2000 16:53:27 -0800 Date: Tue, 21 Nov 2000 16:53:27 -0800 From: H . J . Lu hjl@valinux.com Subject: [parisc-linux] Use of the EI_OSABI field On Wed, Nov 22, 2000 at 11:13:29AM +1100, Alan Modra wrote: > > > Anyway, the ABI value is zero unless you implement ELF extensions. > > Exactly what is an "ELF extension"? Anything outside gABI or ELF extension is something whose interpretation is not documented in neither gABI nor psABI. HP's old ELF is a good example since it didn't implement DT_INIT/DT_FINI, but added DT_INIT_ARRARY/DT_FINI_ARRAY. A normal ELF tool will have a hard time to interpret those fields and their values. H.J. From matthew@wil.cx Wed, 22 Nov 2000 00:53:09 +0000 Date: Wed, 22 Nov 2000 00:53:09 +0000 From: Matthew Wilcox matthew@wil.cx Subject: [parisc-linux] CVS linux Vs. -test10 On Tue, Nov 21, 2000 at 01:24:31PM -0800, Grant Grundler wrote: > I would like a few files moved: > > arch/parisc/kernel/ccio-dma.c -> drivers/gsc/ccio-dma.c > arch/parisc/kernel/ccio-rm-dma.c -> drivers/gsc/ccio-rm-dma.c > arch/parisc/kernel/lba_pci.c -> drivers/ropes/lba_pci.c > arch/parisc/kernel/sba_iommu.c -> drivers/ropes/sba_iommu.c > arch/parisc/kernel/iosapic.c -> drivers/ropes/iosapic.c > Any reason why we couldn't do these moves *after* you submit a patch? Better to get our house in order before we patchbomb Linus, I think. Renames are hard enough in CVS; renames in diff -u format are a real stinker :-) -- Revolutions do not require corporate support. From adevries@linuxcare.com Tue, 21 Nov 2000 21:27:51 -0500 Date: Tue, 21 Nov 2000 21:27:51 -0500 From: Alex deVries adevries@linuxcare.com Subject: [parisc-linux] case LEDs Grant Grundler wrote: > Yes. > I was already asked this weekend to dig up technical info on LED > and soft power control. I guess this is my reminder to do that. :^) Isn't there a PDC call (pdc_chassis?) to do this? Or is the heartbeat LED done by hardware? - Alex -- Alex deVries, Principal Solutions Architect, The Puffins at Linuxcare 613.562.2759 tel alex@linuxcare.com, http://www.linuxcare.com/ Linuxcare, Support for the revolution. From randolph@tausq.org Tue, 21 Nov 2000 18:50:24 -0700 Date: Tue, 21 Nov 2000 18:50:24 -0700 From: Randolph Chung randolph@tausq.org Subject: [parisc-linux] Fun build problems --9zSXsLTf0vkW971A Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable > Seeing as apt was broken, I decided to download the woody version of apt = so > I can get a newer version and hopefully skip some steps in building the > above packages. gcc 2.96 and apt-0.3.19 don't get along, so I tried pick= ing > it up from cvs (supposed to have been fixed). Follow the directions on > cvs.debian.org >=20 > $ cvs -d :pserver:anonymous@cvs.debian.org:/cvs/APT login > (Logging in to anonymous@cvs.debian.org) > CVS password:=20 > cvs login: authorization failed: server cvs.debian.org rejected access Try: cvs -d:pserver:anonymous@cvs.debian.org:/cvs/deity login (empty password) It should work. if not let me know and i can mail you a tarball. You probably want to get the aliencode branch, which has hppa patches. Let me know if you run into any problems. > rsync -- ldd crashes on dpkg-shlibdepends stage > Can I just manually put the required dependancies in? Yes, or pick up the dpkg-architecture and dpkg-shlibdeps scripts from http://puffin.external.hp.com/~tausq/, or wait for the next version of dpkg to get built for hppa (it doesn't use ldd anymore) > autoconf -- installinfo spins >=20 > When installing the autoconf package (to compile dpkg) installinfo spins. > And after several minutes still doesn't return. It's taking up 100% cpu > at the time. hmmm.. didn't see this. I had built a slightly older version of dpkg successfully. randolph (tausq@debian.org) --=20 @..@ http://www.TauSq.org/ (----) ( >__< ) ^^ ~~ ^^ --9zSXsLTf0vkW971A Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.1 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE6GyZgULspdC1Zp9IRAozyAKC/Df1fexltMjFlcwpeYlD+IIWEigCgiGyT YKOjLA0BQzMo7qOj8jC1BTI= =whh1 -----END PGP SIGNATURE----- --9zSXsLTf0vkW971A-- From hjl@valinux.com Tue, 21 Nov 2000 19:11:29 -0800 Date: Tue, 21 Nov 2000 19:11:29 -0800 From: H . J . Lu hjl@valinux.com Subject: [parisc-linux] Use of the EI_OSABI field On Wed, Nov 22, 2000 at 02:03:07PM +1100, Alan Modra wrote: > On Tue, 21 Nov 2000, H . J . Lu wrote: > > > On Wed, Nov 22, 2000 at 11:13:29AM +1100, Alan Modra wrote: > > > > > > > Anyway, the ABI value is zero unless you implement ELF extensions. > > > > > > Exactly what is an "ELF extension"? Anything outside gABI or > > > > ELF extension is something whose interpretation is not documented in > > neither gABI nor psABI. HP's old ELF is a good example since it didn't > > implement DT_INIT/DT_FINI, but added DT_INIT_ARRARY/DT_FINI_ARRAY. A > > normal ELF tool will have a hard time to interpret those fields and > > their values. > > Neither you nor Ulrich have responded to John's point that the IA64 psABI > states > "The e_ident[EI_OSABI] value identifies the operating system and ABI to > which the object is targeted" > > Granted, this is only in a processor specific ABI, but it does flatly > contradict your assertions that the purpose of EI_OSABI is to flag the > presense of ELF extensions. > When I was at the IA64 ABI meeting yesterday, we were looking at the EI_OSABI issue. Everyone at the IA64 ABI meeting agreed that what Ulrich and I had said was the correct understanding. "The e_ident[EI_OSABI] value identifies the operating system and ABI to which the object is targeted" just means if the e_ident[EI_OSABI] value is not ELFOSABI_NONE, you have to look somewhere else in addition to gABI and IA64 psABI to interpret the ELF fields/values specific to that OS. Otherwise, gABI and IA64 psABI are sufficient. -- H.J. Lu (hjl@valinux.com) From drepper@redhat.com 21 Nov 2000 19:18:21 -0800 Date: 21 Nov 2000 19:18:21 -0800 From: Ulrich Drepper drepper@redhat.com Subject: [parisc-linux] Use of the EI_OSABI field Alan Modra writes: > "The e_ident[EI_OSABI] value identifies the operating system and ABI to > which the object is targeted" > > Granted, this is only in a processor specific ABI, but it does flatly > contradict your assertions that the purpose of EI_OSABI is to flag the > presense of ELF extensions. The meaning of the field changed over time. Or better said, some people initially understood it differently. -- ---------------. ,-. 1325 Chesapeake Terrace Ulrich Drepper \ ,-------------------' \ Sunnyvale, CA 94089 USA Red Hat `--' drepper at redhat.com `------------------------ From alan@linuxcare.com.au Wed, 22 Nov 2000 14:03:07 +1100 (EST) Date: Wed, 22 Nov 2000 14:03:07 +1100 (EST) From: Alan Modra alan@linuxcare.com.au Subject: [parisc-linux] Use of the EI_OSABI field On Tue, 21 Nov 2000, H . J . Lu wrote: > On Wed, Nov 22, 2000 at 11:13:29AM +1100, Alan Modra wrote: > > > > > Anyway, the ABI value is zero unless you implement ELF extensions. > > > > Exactly what is an "ELF extension"? Anything outside gABI or > > ELF extension is something whose interpretation is not documented in > neither gABI nor psABI. HP's old ELF is a good example since it didn't > implement DT_INIT/DT_FINI, but added DT_INIT_ARRARY/DT_FINI_ARRAY. A > normal ELF tool will have a hard time to interpret those fields and > their values. Neither you nor Ulrich have responded to John's point that the IA64 psABI states "The e_ident[EI_OSABI] value identifies the operating system and ABI to which the object is targeted" Granted, this is only in a processor specific ABI, but it does flatly contradict your assertions that the purpose of EI_OSABI is to flag the presense of ELF extensions. Alan Modra -- Linuxcare. Support for the Revolution. From rbradetich@uswest.net Tue, 21 Nov 2000 22:54:11 -0800 Date: Tue, 21 Nov 2000 22:54:11 -0800 From: Ryan Bradetich rbradetich@uswest.net Subject: [parisc-linux] CVS linux Vs. -test10 Grant Grundler wrote: > Matthew Wilcox wrote: > ... > > Someone (probably me) sends him a patch. He told me at the Toronto > > show that he was quite happy to apply anything that only touched those > > two directories. (oh, and drivers/gsc wouldn't be a problem either). > > Can I just check that no-one wants to rename drivers/gsc again? :-) > > Hi Mathew, > I don't and it's a good question. > I would like a few files moved: > > arch/parisc/kernel/ccio-dma.c -> drivers/gsc/ccio-dma.c > arch/parisc/kernel/ccio-rm-dma.c -> drivers/gsc/ccio-rm-dma.c Grant, Do you really want to merget the ccio-rm-dma.c file into Linus's tree? It is just a reference file used to construct the real ccio-dma.c file ... I don't believe it is referenced anywhere. I'll double check this in the morning. - Ryan > ccio will *always* be associated with a GSC bus since that's > the secondary bus. And ccio supports devices below dino.c which > already lives in drivers/gsc. > > arch/parisc/kernel/lba_pci.c -> drivers/ropes/lba_pci.c > arch/parisc/kernel/sba_iommu.c -> drivers/ropes/sba_iommu.c > arch/parisc/kernel/iosapic.c -> drivers/ropes/iosapic.c > > lba/sba code is equivalent to dino/ccio code for another set > of platforms. And long term, I'm certain iosapic.c does not > belong under arch/parisc. I can do this move if there are no > major objections. > > Any reason why we couldn't do these moves *after* you submit a patch? > > FWIW, here are issues I see with merging IA64 iosapic code with mine: > o iosapic "discovery" (I invented register_iosapic() interface for parisc) > o parisc PDC calls (initialization) > o interrupt policy decisions (eg EOI generation and picking a CPU) > o I don't have time to do it in the near future. > > Folks working on IA64 stuff inside HP need to think about: > (a) if they want to do the merge any time soon > (b) which iosapic.c they want to start with > (c) where the final version should live > > thanks, > grant > > Grant Grundler > Unix Systems Enablement Lab > +1.408.447.7253 > > --------------------------------------------------------------------------- > To unsubscribe: send e-mail to parisc-linux-request@thepuffingroup.com with > `unsubscribe' as the subject. From jsm@udlkern.fc.hp.com Tue, 21 Nov 2000 23:50:03 -0700 (MST) Date: Tue, 21 Nov 2000 23:50:03 -0700 (MST) From: John Marvin jsm@udlkern.fc.hp.com Subject: [parisc-linux] CVS linux Vs. -test10 > Better to get our house in order before we patchbomb Linus, I think. > Renames are hard enough in CVS; renames in diff -u format are a real > stinker :-) In that case, we need to do some cleanup first. I've been lobbying for the removal of the almost empty arch/parisc/real directory, and its few remaining valid files moved to the kernel directory. There are also a fair number of dead files. Every file that is not currently involved in the build should be removed, unless a good case for it remaining can be made. If the reason to keep it is not a long term reason, then that file should not be sent to Linus (It sounds like it is a lot easier to add files rather than remove/rename them). If there are any files that are currently in use, but which we know will eventually be removed, perhaps we should consider what to do with that file (although I don't know of any files in this category at the moment). John Marvin jsm@fc.hp.com From grundler@cup.hp.com Tue, 21 Nov 2000 23:18:16 -0800 Date: Tue, 21 Nov 2000 23:18:16 -0800 From: Grant Grundler grundler@cup.hp.com Subject: [parisc-linux] CVS linux Vs. -test10 Ryan Bradetich wrote: > Do you really want to merget the ccio-rm-dma.c file into Linus's tree? > It is just a reference file used to construct the real ccio-dma.c file ... I > don't believe it is referenced anywhere. Hi Ryan, Yes I do. It is supposed to work for ccio+PCX-W platforms (eg C360). Keeping it arround will document the pro/con's of that approach and give folks who have time (and the right machine) something to experiment with instead of writing it from scratch. If someone finds an application it's good for (short transactions with low latency requirements perhaps), it's worth having around. It's not referenced because I didn't add a CONFIG_CCIO_RM_IOMMU flag or ccio_rm_init() call to drivers/gsc/gsc.c:gsc_init(). You are welcome add this CONFIG flag by hacking arch/parisc/config.in and defconfig. If you do, please add rules which only allow one or the other CONFIG_CCIO* option to be enabled. thanks, grant Grant Grundler Unix Systems Enablement Lab +1.408.447.7253 From Pirvulescu_Alexandru@telemobil.ro Wed, 22 Nov 2000 09:36:58 +0200 Date: Wed, 22 Nov 2000 09:36:58 +0200 From: Alexandru Pirvulescu Pirvulescu_Alexandru@telemobil.ro Subject: [parisc-linux] case LEDs I think that the heartbeat LED is software because it starts with the kernel boot and if the kernel stops the LED stops blinking too. Is better to implement a software monitoring tool because you have to watch the software for hanging. Alex PS. There is a function in the kernel source in linux/arch/parisc/kernel/process.c named machine_heartbeat(). Any connection with the heartbeat from the chassis? ----- Original Message ----- From: "Alex deVries" To: "Grant Grundler" Cc: "Alexandru Pirvulescu" ; Sent: Wednesday, November 22, 2000 4:27 AM Subject: Re: [parisc-linux] case LEDs > Grant Grundler wrote: > > Yes. > > I was already asked this weekend to dig up technical info on LED > > and soft power control. I guess this is my reminder to do that. :^) > > Isn't there a PDC call (pdc_chassis?) to do this? Or is the heartbeat > LED done by hardware? > > - Alex > > -- > Alex deVries, Principal Solutions Architect, The Puffins at Linuxcare > 613.562.2759 tel > alex@linuxcare.com, http://www.linuxcare.com/ > Linuxcare, Support for the revolution. > > From bvalkema@knowhowww.nl Wed, 22 Nov 2000 06:32:51 +0100 Date: Wed, 22 Nov 2000 06:32:51 +0100 From: Bas Valkema bvalkema@knowhowww.nl Subject: [parisc-linux] case LEDs Alex deVries wrote: > Grant Grundler wrote: > > Yes. > > I was already asked this weekend to dig up technical info on LED > > and soft power control. I guess this is my reminder to do that. :^) > > Isn't there a PDC call (pdc_chassis?) to do this? Or is the heartbeat > LED done by hardware? > > - Alex A couple of months ago, I asked the same question, got answer to look in the mkLinux sources. I did, and I think it was a register (outb(0xblabla);). Wrote a driver (and for WAX, got a Intel Flash 32 EISA running), can't release it now, because of some copyright issues... Bas From grundler@cup.hp.com Tue, 21 Nov 2000 23:56:35 -0800 Date: Tue, 21 Nov 2000 23:56:35 -0800 From: Grant Grundler grundler@cup.hp.com Subject: [parisc-linux] CVS linux Vs. -test10 John Marvin wrote: > In that case, we need to do some cleanup first. John, I want a task list which leads us to a submital to linus. That's why I listed the specific files I wanted moved. Can you come up with (or ask someone else to come up) with a list of files which meet your criteria? All of your criteria sounds reasonable to me. But I don't have a feel of which files meet your criteria. If someone makes the task list, I'm happy to help with items and verify the result works. thanks, grant From jsm@udlkern.fc.hp.com Wed, 22 Nov 2000 01:11:57 -0700 (MST) Date: Wed, 22 Nov 2000 01:11:57 -0700 (MST) From: John Marvin jsm@udlkern.fc.hp.com Subject: [parisc-linux] CVS linux Vs. -test10 > Ryan Bradetich wrote: > > Do you really want to merget the ccio-rm-dma.c file into Linus's tree? > > It is just a reference file used to construct the real ccio-dma.c file ... I > > don't believe it is referenced anywhere. > > Hi Ryan, > Yes I do. It is supposed to work for ccio+PCX-W platforms (eg C360). > Keeping it arround will document the pro/con's of that approach and > give folks who have time (and the right machine) something to experiment > with instead of writing it from scratch. If someone finds an application > it's good for (short transactions with low latency requirements perhaps), > it's worth having around. > > It's not referenced because I didn't add a CONFIG_CCIO_RM_IOMMU flag > or ccio_rm_init() call to drivers/gsc/gsc.c:gsc_init(). You are welcome > add this CONFIG flag by hacking arch/parisc/config.in and defconfig. > If you do, please add rules which only allow one or the other > CONFIG_CCIO* option to be enabled. > Well, personally i'd vote to get rid of it. It works for ONE machine only, and MAY have an advantage in some small case. But if we keep it, lets make sure that it is real clear that it should NOT be the default choice. It should be marked CONFIG_EXPERIMENTAL, and the text associated with it should clearly show that it works on a C360 only. If possible, it should also be made clear that ccio-dma.c works for C360, so people who have C360's don't think they have to choose ccio-rm-dma.c. Grant, I hope you are prepared to answer the parisc-linux mailing list questions this is going to generate once parisc-linux starts becoming more visible. Another FAQ entry perhaps? :-) John Marvin jsm@fc.hp.com From jsm@udlkern.fc.hp.com Wed, 22 Nov 2000 01:52:04 -0700 (MST) Date: Wed, 22 Nov 2000 01:52:04 -0700 (MST) From: John Marvin jsm@udlkern.fc.hp.com Subject: [parisc-linux] Use of the EI_OSABI field > > BTW, it's not too hard to check .note.ABI-tag. The linker arranges for a > PT_NOTE program header entry to point to it, and the section itself is > virtually guaranteed to be read in with the header as it's placed right > after the header along with .interp. I didn't say it was difficult, I said it was ugly. It means another parisc only change to the machine independent file fs/binfmt_elf.c, since the hook provided will not allow this check. Without a change, binfmt_elf.c won't be smart enough to differentiate a binary produced by Gnu binutils for HP-UX and a binary produced by Gnu binutils for Linux, so it will claim both, and then blow up later, rather than not claiming the HP-UX binary and allowing it to be claimed by an arch dependent binary handler further down the list. And binfmt_elf.c does NOT read the program headers in the same read, so another read would have to be done (the data should be found in in cache rather than going to disk for it). Since we now need both the program headers and a section header to determine whether or not we should claim the file AND binfmt_elf.c also wants to look at those headers after the file is claimed, a small redesign is probably in order (rather than re-reading the headers). I'm not sure whether or not Linus would buy that. So, I guess I'll pursue the interpreter field instead, since that is what sparc is doing (i.e. they have their own sparc only code in binfmt_elf.c). Since that will be an easier sell. I need to do more research here. I suspect that statically linked binaries are not going to allow this solution to work though. John Marvin jsm@fc.hp.com From alan@linuxcare.com.au Wed, 22 Nov 2000 23:28:45 +1100 (EST) Date: Wed, 22 Nov 2000 23:28:45 +1100 (EST) From: Alan Modra alan@linuxcare.com.au Subject: [parisc-linux] binutils update I've just committed a change to binutils that cures an ELF spec violation. We now no longer create plabels for DT_INIT and DT_FINI and instead rely on the dynamic linker to create them for us. This means you need an updated glibc, that I committed a little earlier today, to create the plabel function pointers if you update your binutils. You have been warned... Alan Modra -- Linuxcare. Support for the Revolution. From bruno_vidal@hpfrcu03.france.hp.com Wed, 22 Nov 2000 15:14:18 +0100 Date: Wed, 22 Nov 2000 15:14:18 +0100 From: Bruno Vidal bruno_vidal@hpfrcu03.france.hp.com Subject: [parisc-linux] Crash dump module Hi Good news, I've finished to recompile the entire chain on hpux 11.00 64bits. I've recompile my own kernel and booted a small 712/60. It work pretty well. Now I'm going to start the work about crash dump. So, In my mind, I'll start from the linux/kernel/panic.c function and I'll add a function dumpsys.c in the linux/arch/paric directory -> is it okay for you ? It will depend on the CONFIG_PARISC var (or do you prefer adding a CONFIG_DUMPSYS var ?) thanks. -- Vidal Bruno, (770-4271) SSD-HA Team, HP-UX & LINUX Support bruno_vidal@admin.france.hp.com From randolph@tausq.org Wed, 22 Nov 2000 07:44:24 -0700 Date: Wed, 22 Nov 2000 07:44:24 -0700 From: Randolph Chung randolph@tausq.org Subject: [parisc-linux] Crash dump module > It will depend on the CONFIG_PARISC var (or do you prefer adding a CONFIG_DUMPSYS var ?) I think there was a consensus to use __hppa__ instead of CONFIG_PARISC ... randolph -- @..@ http://www.TauSq.org/ (----) ( >__< ) ^^ ~~ ^^ From mike_clapper@hp.com Wed, 22 Nov 2000 07:54:24 -0800 Date: Wed, 22 Nov 2000 07:54:24 -0800 From: CLAPPER,MIKE (HP-USA,ex1) mike_clapper@hp.com Subject: [parisc-linux] B132L boot hang Hello Everyone, I download the cross-compilers and build a lifimage on Redhat 6.1. I set up nfsroot on a S712 running hpux 10.20. With this I am able to boot a B132L running pdc 6.1 - almost. I get a hang right after - VFS: Mounted root (nfs filesystem) readonly Warning: unable to open an initial console I have a 700/96 on serial port 1 as the console. I have hpux on a disc in the unit I'm trying to boot - from HPUX I have verified I can nfs mount the filesys I'm using for NFSROOT. With linux in this condition the machine will respond to ping. I will also react to a telnet - i get the telnet banner then "connection closed by foreign host". FTP gets "connection refused" - so it' partially alive..... Is there a way to keyword search the developers archive? I vaguely recall seeing the 'initial console' warning, but couldn't find it browsing the developers archive Thanks, Mike ********************************************** Mike Clapper North American Crisis Management Team Hewlett Packard (405) 948-4715 ********************************************** From bame@noam.fc.hp.com Wed, 22 Nov 2000 09:02:03 -0700 Date: Wed, 22 Nov 2000 09:02:03 -0700 From: Paul Bame bame@noam.fc.hp.com Subject: [parisc-linux] CVS linux Vs. -test10 = I've been lobbying for = the removal of the almost empty arch/parisc/real directory, and its few = remaining valid files moved to the kernel directory. Done. arch/parisc/real R.I.P. From grundler@cup.hp.com Wed, 22 Nov 2000 08:27:22 -0800 Date: Wed, 22 Nov 2000 08:27:22 -0800 From: Grant Grundler grundler@cup.hp.com Subject: [parisc-linux] Crash dump module Bruno Vidal wrote: > Hi > Good news, I've finished to recompile the entire chain on hpux 11.00 64bits. > I've recompile my own kernel and booted a small 712/60. It work pretty well. > Now I'm going to start the work about crash dump. So, In my mind, I'll start > from the linux/kernel/panic.c function and I'll add a function dumpsys.c > in the linux/arch/paric directory -> is it okay for you ? YES! > It will depend on the CONFIG_PARISC var > (or do you prefer adding a CONFIG_DUMPSYS var ?) As Randolph pointed out CONFIG_PARISC is deprecated. Use "ifdef __hppa__" for changes in *common* (ie not arch/parisc) files. They should not be needed for anything in arch/parisc or linux/include/asm-parisc. Adding a CONFIG_DUMPSYS is a good idea. Look in linux/arch/parisc/config.in, linux/arch/parisc/defconfig, and the various Makefiles for how CONFIG_* flags work. thanks Bruno! grant Grant Grundler Unix Systems Enablement Lab +1.408.447.7253 From grundler@cup.hp.com Wed, 22 Nov 2000 09:27:20 -0800 Date: Wed, 22 Nov 2000 09:27:20 -0800 From: Grant Grundler grundler@cup.hp.com Subject: [parisc-linux] B132L boot hang "CLAPPER,MIKE (HP-USA,ex1)" wrote: > > > Hello Everyone, > > I download the cross-compilers and build a lifimage on Redhat 6.1. I set > up nfsroot on a S712 running hpux 10.20. With this I am able to boot a > B132L running pdc 6.1 - > almost. I get a hang right after - > > VFS: Mounted root (nfs filesystem) readonly > Warning: unable to open an initial console I think I need more output. Based on ioscan output, the B132L has two serial ports: 8/16/4 - off of LASI 8/20/2 - of WAX (EISA Bus Adapter) (GSCtoPCI is at 8/0) I don't think the one off of WAX is supported right now. Are you using the default .config produced by "make oldconfig"? It's also possible the LASI support is broken on B132L and I would expect some console output indicating what's wrong. > I have a 700/96 on serial port 1 as the console. I have hpux on a disc in > the unit I'm trying to boot - from HPUX I have verified I can nfs mount the > filesys I'm using for NFSROOT. NFS root mounted fine. Console is the problem. ... > Is there a way to keyword search the developers archive? I vaguely recall > seeing the 'initial console' warning, but couldn't find it browsing the > developers archive Yes - http://puffin.external.hp.com/cgi-bin/mailgrep grant Grant Grundler Unix Systems Enablement Lab +1.408.447.7253 From cary@cup.hp.com Wed, 22 Nov 2000 10:06:05 -0800 Date: Wed, 22 Nov 2000 10:06:05 -0800 From: Cary Coutant cary@cup.hp.com Subject: [parisc-linux] Use of the EI_OSABI field As the original author of the proposal to add the EI_OSABI field to the ELF format, let me try to clarify the intent of this field. The authoritative definition of this field is found in SCO's gABI document, which is still the official specification for the ELF format (this is probably posted somewhere on SCO's web site). Here's what it says: Byte e_ident[EI_OSABI] identifies the operating system and ABI to which the object is targeted. Some fields in other ELF structures have flags and values that have operating system and/or ABI specific meanings; the interpretation of those fields is determined by the value of this byte. The value of this byte must be interpreted differently for each machine. That is, each value for the e_machine field determines a set of values for the EI_OSABI byte. Values are assigned by the ABI processor supplement for each machine. If the processor supplement does not specify a set of values, the value 0 shall be used and indicates unspecified. The first sentence is still a bit misleading, and is an artifact of the original proposal. Originally, the field was intended to identify the target ABI (hence the name of the field). As we started discussing a common Unix ABI for IA-64, however, it became clear that this field wouldn't serve that purpose, but it was still needed to identify the set of platform-specific ELF extensions that are used by the object file. There are a number of fields in the ELF format for which ranges of values or a set of flag bits are reserved for vendor-specific use (e.g., SHT_LOOS through SHT_HIOS for vendor-specific section types, and SHF_MASKOS for vendor-specific section attributes). If an object file uses any of these values or flag bits, the consumer of the file must consult the EI_OSABI field to determine what those values or flags mean. It works just like the e_machine field does for attaching meaning to processor-specific values and flags. The intent is that any ABI-conforming implementation will be able to execute an ABI-conforming binary, even if it uses certain vendor-specific features. In many cases, those vendor-specific features are hints for a particular OS that can be ignored by other implementations. Where this is not the case, and a vendor-specific feature must be understood by the system in order to process the file correctly, we have a couple of alternatives. For section types and flags that a linker must understand, we have the SHF_OS_NONCONFORMING flag -- if set, and a linker doesn't understand a particular section type or flag, it must reject the file. For executables that will execute only on a particular implementation, we must use an alternate interpreter (PT_INTERP) or bind to implementation-specific shared libraries. An ABI-conforming binary will use the interpreter specified in the psABI spec, and will use only system libraries specified there. For statically-bound programs, I'm afraid we don't have a clear solution. We took the general approach that such programs are not ABI-conforming in the first place, and can use any mechanism they might choose to verify that they are executing on the appropriate implementation. -cary From grundler@cup.hp.com Wed, 22 Nov 2000 11:55:38 -0800 Date: Wed, 22 Nov 2000 11:55:38 -0800 From: Grant Grundler grundler@cup.hp.com Subject: [parisc-linux] CVS linux Vs. -test10 John Marvin wrote: > Grant Grundler wrote: > > Yes I do. It is supposed to work for ccio+PCX-W platforms (eg C360). ... > Well, personally i'd vote to get rid of it. It works for ONE machine only, > and MAY have an advantage in some small case. And so does the OB600 mouse driver I rewrote/published. AFAIK, it only works on OB600s. I was originally thinking D/K/R-class boxes had PCX-W upgrades but AFAICT, they don't. > But if we keep it, lets make > sure that it is real clear that it should NOT be the default choice. > > It should be marked CONFIG_EXPERIMENTAL, and the text associated with it > should clearly show that it works on a C360 only. If possible, it should > also be made clear that ccio-dma.c works for C360, so people who have > C360's don't think they have to choose ccio-rm-dma.c. IIRC, Comments in the headers of both ccio files make those issues clear. I'm not sure where else that needs to be documented. > Grant, I hope you are prepared to answer the parisc-linux mailing list > questions this is going to generate once parisc-linux starts becoming more > visible. Another FAQ entry perhaps? :-) Ryan owns it. He's responsible for documenting it and adding FAQ questions. He can choose to delete ccio-rm-dma.c as well. :^) I think it'd be a waste to throw it away before someone figures out that it's really not useful - even if just for C360. thanks, grant From mike_clapper@hp.com Wed, 22 Nov 2000 12:05:23 -0800 Date: Wed, 22 Nov 2000 12:05:23 -0800 From: CLAPPER,MIKE (HP-USA,ex1) mike_clapper@hp.com Subject: [parisc-linux] B132L boot hang Thanks Grant, I verified the console is off 8/16/4.0 and that it is the LASI port. I also downloaded the newest cross-compiler and source code. After rebuilding the palo lifimage I get the same hang in the same place. Since I was cabled to a dumb terminal I was not able to capture the boot output. I will find the right cable to hook up to my pc so I can capture the output and send it to you - perhaps an error occurred earlier in the boot that I overlooked. Thanks for the help. Mike -----Original Message----- From: Grant Grundler [mailto:grundler@cup.hp.com] Sent: Wednesday, November 22, 2000 11:27 AM To: CLAPPER,MIKE (HP-USA,ex1) Cc: 'parisc-linux@thepuffingroup.com' Subject: Re: [parisc-linux] B132L boot hang "CLAPPER,MIKE (HP-USA,ex1)" wrote: > > > Hello Everyone, > > I download the cross-compilers and build a lifimage on Redhat 6.1. I set > up nfsroot on a S712 running hpux 10.20. With this I am able to boot a > B132L running pdc 6.1 - > almost. I get a hang right after - > > VFS: Mounted root (nfs filesystem) readonly > Warning: unable to open an initial console I think I need more output. Based on ioscan output, the B132L has two serial ports: 8/16/4 - off of LASI 8/20/2 - of WAX (EISA Bus Adapter) (GSCtoPCI is at 8/0) I don't think the one off of WAX is supported right now. Are you using the default .config produced by "make oldconfig"? It's also possible the LASI support is broken on B132L and I would expect some console output indicating what's wrong. > I have a 700/96 on serial port 1 as the console. I have hpux on a disc in > the unit I'm trying to boot - from HPUX I have verified I can nfs mount the > filesys I'm using for NFSROOT. NFS root mounted fine. Console is the problem. ... > Is there a way to keyword search the developers archive? I vaguely recall > seeing the 'initial console' warning, but couldn't find it browsing the > developers archive Yes - http://puffin.external.hp.com/cgi-bin/mailgrep grant Grant Grundler Unix Systems Enablement Lab +1.408.447.7253 --------------------------------------------------------------------------- To unsubscribe: send e-mail to parisc-linux-request@thepuffingroup.com with `unsubscribe' as the subject. From kirkb@chrome.rose.hp.com Wed, 22 Nov 2000 12:10:10 PST Date: Wed, 22 Nov 2000 12:10:10 PST From: Kirk Bresniker kirkb@chrome.rose.hp.com Subject: [parisc-linux] CVS linux Vs. -test10 Grant Grundler wrote: | I was originally thinking D/K/R-class boxes had PCX-W upgrades but | AFAICT, they don't. | The C-class upgrade to PCX-W was a one-off. Upgrades for similar enterprise servers were not designed. KMB -- +============================================================+ | Kirk Bresniker (916) 748-2393 | | 8000 Foothills Blvd | | Roseville, CA 95747-5649 | | kirkb@rose.hp.com | From grundler@cup.hp.com Wed, 22 Nov 2000 12:11:23 -0800 Date: Wed, 22 Nov 2000 12:11:23 -0800 From: Grant Grundler grundler@cup.hp.com Subject: [parisc-linux] CVS linux Vs. -test10 Grant Grundler wrote: ... > arch/parisc/kernel/ccio-dma.c -> drivers/gsc/ccio-dma.c > arch/parisc/kernel/ccio-rm-dma.c -> drivers/gsc/ccio-rm-dma.c > > ccio will *always* be associated with a GSC bus since that's > the secondary bus. And ccio supports devices below dino.c which > already lives in drivers/gsc. Ryan - moving/keeping these files is up to you. I was just sharing what I thought was "right". Apologies for not making that clear earlier. > arch/parisc/kernel/lba_pci.c -> drivers/ropes/lba_pci.c > arch/parisc/kernel/sba_iommu.c -> drivers/ropes/sba_iommu.c > arch/parisc/kernel/iosapic.c -> drivers/ropes/iosapic.c I've talked to one of the folks working on IA64-linux. They are interested in merging iosapic code but haven't even looked at the parisc version I wrote. We talked a bit about the issues and it doesn't sound like it's going to happen anytime soon. In any case, iosapic.c doesn't belong under "drivers/ropes". So none of this needs to move in the forseeable future. It can all stay in arch/parisc/kernel. grant Grant Grundler Unix Systems Enablement Lab +1.408.447.7253 From deller@gmx.de Wed, 22 Nov 2000 21:43:40 +0100 Date: Wed, 22 Nov 2000 21:43:40 +0100 From: Helge Deller deller@gmx.de Subject: [parisc-linux] B132L boot hang > I think I need more output. Based on ioscan output, the B132L > has two serial ports: > 8/16/4 - off of LASI > 8/20/2 - of WAX (EISA Bus Adapter) > > (GSCtoPCI is at 8/0) > > I don't think the one off of WAX is supported right now. It should be detected & supported (at least it is on my B160L). But it is not used as initial console since it normally gets assigned as ttyS1 while LASI-serial gets ttyS0. Greetings, Helge. From bame@noam.fc.hp.com Wed, 22 Nov 2000 16:03:12 -0700 Date: Wed, 22 Nov 2000 16:03:12 -0700 From: Paul Bame bame@noam.fc.hp.com Subject: [parisc-linux] 64-bit progress 32-bit syscalls on 64-bit kernel are to the point where a few things work, and signals appear to be working (I didn't implement *all* the signal-related syscalls yet). I'll be continuing to produce syscall wrappers for a while... If you try to boot the standard NFS root with wide kernel, you'll want to mv sbin/init sbin/init-real then compile and install this program as sbin/init: int main() { char *argv[2]; argv[0] = "/sbin/init-real"; argv[1] = 0; execv(argv[0], argv); } I never felt comfortable I found the point where sys_execve figures out it needs to pack the argv vector differently for narrow user apps (locally I also am using PER_LINUX32 in binfmt_elf32.c) which causes the initial exec(/sbin/init) to be passed incomprehensible arguments. This program is a little temporary workaround. -Paul Bame From alan@linuxcare.com.au Thu, 23 Nov 2000 11:18:20 +1100 (EST) Date: Thu, 23 Nov 2000 11:18:20 +1100 (EST) From: Alan Modra alan@linuxcare.com.au Subject: glibc On Wed, 22 Nov 2000, Matt Taggart wrote: > Hi Alan, > > First a timezone question... your mail headers have you in +11 and Ft. Collins > is -7 so you're 6 hours behind + 1 day relative to us? So as I send this it's > 14:05 here and 8:05 there? Hi Matt, I'm actually on +10:30 in Adelaide, but posting from a Linuxcare machine in Canberra which is on +11. >[snip segfaults] > I am building native using dhd's binutils/gcc/glibc debs, using source checked > out just after the glibc 2.2 merge. Do you think the merge / ld.so changes you > just made would help this problem at all? Quite likely. This fix * sysdeps/hppa/dl-machine.h (ELF_MACHINE_START_ADDRESS): Define. is fairly crucial, as without it %dp will not be set correctly. I should have mentioned this when posting to the list about the binutils change. Oh, and as of this email, I haven't actually run anything linked to the new glibc. A little remiss, I know, but I've been deep in the gdb port, and if I spend time tinkering with glibc, binutils and gcc (which I like), gdb (which I don't like) will never be finished. ;-) Alan -- Linuxcare. Support for the Revolution. From grundler@cup.hp.com Wed, 22 Nov 2000 18:24:52 -0800 (PST) Date: Wed, 22 Nov 2000 18:24:52 -0800 (PST) From: Grant Grundler grundler@cup.hp.com Subject: [parisc-linux] new SBA IOMMU version committed Hi all, I've committed my "second generation" I/O MMU code for C3K/J5k boxes. It's only tested for 32-bit. I'll be testing 64-bit shortly. This code makes "perfect" use of the I/O pdir resource map and we shouldn't see any panics due to out_of_resource. grant From grundler@cup.hp.com Wed, 22 Nov 2000 18:47:06 -0800 (PST) Date: Wed, 22 Nov 2000 18:47:06 -0800 (PST) From: Grant Grundler grundler@cup.hp.com Subject: [parisc-linux] CONFIG_DMB_TRAP diff Hello again (last one until Monday - I promise), With Lamont's wisdom, I implemented support for Date Memory Break trap. This enables the kernel programmer to capture the evil code which stomps on other people's "private" data. Only works for stores through virtual addresses. gsc_writeX() and DMA will still bypass this mechanism. pb, dhd, (or some equivalent deity), could you review/commit this code? Or tell me it's ok to commit? I've touched: arch/parisc/config.in arch/parisc/kernel/entry.S arch/parisc/mm/kmap.c include/asm-parisc/pgtable.h thanks, grant Index: arch/parisc/config.in =================================================================== RCS file: /home/cvs/parisc/linux/arch/parisc/config.in,v retrieving revision 1.25 diff -u -p -r1.25 config.in --- config.in 2000/10/20 18:28:26 1.25 +++ config.in 2000/11/23 02:18:23 @@ -16,8 +16,12 @@ endmenu mainmenu_option next_comment comment 'General options' -# bool 'Symmetric multi-processing support' CONFIG_SMP -define_bool CONFIG_SMP n +bool 'Symmetric multi-processing support' CONFIG_SMP +# define_bool CONFIG_SMP n + +# One needs to tweak dmb_trap_11 code in entry.S to match. +# Not tested for 64-bit kernel. +bool 'Debug support for Data Memory Break Trap' CONFIG_DMB_TRAP bool 'Kernel Debugger support' CONFIG_KWDB # define_bool CONFIG_KWDB n Index: arch/parisc/kernel/entry.S =================================================================== RCS file: /home/cvs/parisc/linux/arch/parisc/kernel/entry.S,v retrieving revision 1.53 diff -u -p -r1.53 entry.S --- entry.S 2000/11/22 16:51:33 1.53 +++ entry.S 2000/11/23 02:18:23 @@ -23,6 +23,7 @@ */ #include +#include /* the following is the setup i think we should follow: * whenever the CPU is interruptible, the following has to be true: @@ -349,7 +350,39 @@ .endm #endif +#ifdef CONFIG_DMB_TRAP /* + ** Data Memory Bit trap interruption handler (parisc 1.1) + ** + ** This is a debugging aid. Use it when you think someone else + ** is stepping on your memory. It only catches *virtual* + ** accesses. gsc_writeX() functions disable virtual translation + ** (D-bit) and will happily scribble whatever physical address + ** is passed in. + ** + ** Here's how to use it: + ** 1) Call iterate_pages() from your init routine like this: + ** iterate_pages( my_private_mem, private_mem_size, + ** set_data_memory_break, 0); + ** 2) substitute your functions for your_function1 (or 2) in + ** dmb_trap_11 code below. + ** + ** Thanks to Lamont Jones for telling me how to do this. + ** - ggg 1/22/2000 + */ + .macro dmb_11 code + + mfctl %isr,spc + b dmb_trap_11 + mfctl %ior,va + + .align 32 + .endm +#else +#define dmb_11 def +#endif + + /* * dirty bit trap interruption handler (parisc 2.0) */ @@ -448,7 +481,7 @@ fault_vector_11: naitlb_11 16 nadtlb_11 17 def 18 - def 19 + dmb_11 19 dbit_11 20 def 21 def 22 @@ -467,7 +500,6 @@ fault_vector_11: .import handle_interruption,code .import handle_real_interruption,code .import do_irq_mask,code - .import parisc_stopkernel,code .import cpu_irq_region,data /* @@ -903,11 +935,15 @@ dtlb_miss_11: dep pte,8,7,prot extru,= pte,_PAGE_NO_CACHE_BIT,1,r0 - depi 1,12,1,prot + depi 1,12,1,prot /* U-bit */ extru,= pte,_PAGE_USER_BIT,1,r0 depi 7,11,3,prot /* Set for user space (1 rsvd for read) */ extru,= pte,_PAGE_GATEWAY_BIT,1,r0 depi 0,11,2,prot /* If Gateway, Set PL2 to 0 */ +#ifdef CONFIG_DMB_TRAP + extru,= pte,_PAGE_DMB_BIT,1,r0 + depi 1,4,1,prot /* B-bit */ +#endif /* Get rid of prot bits and convert to page addr for idtlba */ @@ -1300,6 +1336,30 @@ dbit_trap_11: rfir nop + +#ifdef CONFIG_DMB_TRAP + .import your_function1,code + .import your_function2,code + +dmb_trap_11: + mfctl pcsq,t0 /* get space */ + comb,<>,n t0,%r0,dmb_rfi /* not kernel - bail */ + + mfctl pcoq,t0 /* get offset */ + ldil L%dmb_ok_function1, t1 + dep %r0, 31, 12, t0 + comb,=,n t0,t1,dmb_rfi /* it's ours - bail */ + + ldil L%dmb_ok_function2, t1 + comb,<>,n t0,t1,intr_save /* not ours - panic */ + +dmb_rfi: + mfctl ipsw,t0 /* Set PSW X-bit - just continue */ + depi 1,11,1,t0 /* Set X-bit */ + mtctl t0, ipsw + rfir + nop +#endif dbit_trap_20: mfctl %cr25,ptp /* Assume user space trap */ Index: arch/parisc/mm/kmap.c =================================================================== RCS file: /home/cvs/parisc/linux/arch/parisc/mm/kmap.c,v retrieving revision 1.3 diff -u -p -r1.3 kmap.c --- kmap.c 2000/05/05 18:05:47 1.3 +++ kmap.c 2000/11/23 02:18:23 @@ -43,7 +43,16 @@ static void unmap_cached_pte(pte_t * pte } #endif +#ifdef CONFIG_DMB_TRAP /* These two routines should probably check a few things... */ +void set_data_memory_break(pte_t * pte, unsigned long arg) +{ + pte_val(*pte) |= _PAGE_DMB; +} + +#endif + +/* These two routines should probably check a few things... */ static void set_uncached(pte_t * pte, unsigned long arg) { pte_val(*pte) |= _PAGE_NO_CACHE; @@ -106,7 +115,10 @@ static inline void iterate_pmd(pgd_t * d } while (address < end); } -static void iterate_pages(unsigned long address, unsigned long size, +#ifndef CONFIG_DMB_TRAP +static +#endif +void iterate_pages(unsigned long address, unsigned long size, pte_iterator_t op, unsigned long arg) { pgd_t *dir; Index: include/asm-parisc/pgtable.h =================================================================== RCS file: /home/cvs/parisc/linux/include/asm-parisc/pgtable.h,v retrieving revision 1.29 diff -u -p -r1.29 pgtable.h --- pgtable.h 2000/11/10 21:44:44 1.29 +++ pgtable.h 2000/11/23 02:18:23 @@ -109,6 +109,10 @@ extern void *vmalloc_start; #define _PAGE_USER 0x400 /* Software: User accessable page */ #define _PAGE_USER_BIT 21 /* Needs to agree with _PAGE_USER above */ /* 0x800 still available */ +#ifdef CONFIG_DMB_TRAP +#define _PAGE_DMB 0x800 /* Data Memory Break Trap */ +#define _PAGE_DMB_BIT 20 /* Data Memory Break Trap */ +#endif #ifdef __ASSEMBLY__ #define _PGB_(x) (1 << (63 - (x))) From jsm@udlkern.fc.hp.com Wed, 22 Nov 2000 22:50:14 -0700 (MST) Date: Wed, 22 Nov 2000 22:50:14 -0700 (MST) From: John Marvin jsm@udlkern.fc.hp.com Subject: [parisc-linux] CONFIG_DMB_TRAP diff > > Hello again (last one until Monday - I promise), > > With Lamont's wisdom, I implemented support for Date Memory Break trap. > > This enables the kernel programmer to capture the evil code which > stomps on other people's "private" data. Only works for stores > through virtual addresses. gsc_writeX() and DMA will still > bypass this mechanism. > > pb, dhd, (or some equivalent deity), could you review/commit this code? > Or tell me it's ok to commit? > > I've touched: > arch/parisc/config.in > arch/parisc/kernel/entry.S > arch/parisc/mm/kmap.c > include/asm-parisc/pgtable.h > Please don't. This solution is way more complicated than it should be. Here are the problems with it: 1) As I had already mentioned in a previous discussion, the pte's already reserve the location for the B bit (data memory break trap) and the dtlb miss handlers already move the entire group of bits that include this bit in one operation. So no change is necessary to the dtlb miss handlers to specially set that bit and incur extra instructions in the tlb miss handlers, and no extra bits need to be allocated in the pte. Instead of adding a new definition (e.g. 0x800, which is our last available bit) use the one that is already reserved for it: 0x010. 2) There is no reason to add a special data memory break trap handler. The general trap handler is more than sufficient for this case. handle_interruption will be called if a data memory break trap is encountered. Just add a new case for the list of traps, and handle the trap in C. You can set the X bit by simply setting it in the saved ipsw (in gr[0]) and it will be set upon return from the trap, no muss, no fuss. Note that the above also applies for the page reference trap. The T bit is also already supported (0x040 in the pte) by the dtlb miss handlers. Note that the reason I reserved these bits is because it would actually take MORE code in the dtlb miss handlers to NOT support those bits and use them for something else. Another helpful hint for those wanting to use this feature. If you are tracking corruptions that span multiple pages, then just setting the B bit on each page may be all you need. But, when I've used the data memory break trap for corruption tracking, typically I've wanted to track a corruption that was happening to a particular variable, i.e. a 4 byte quantity, and lots of other variables were being legitimately written on the same page, so you wind up with thousands of data memory break traps, where only one may be the one that is corrupting the location you are interested in. But, all is not lost, the solution is still fairly simple. The data memory break trap provides a valid iir, isr and ior. So once you get the trap, a custom data memory break handler (which can be written with a few lines of C in handle_interruption), simply uses iir, isr and ior to check if the access was to the specific byte or bytes you are interested in. I've simply used isr/ior to check for writes within the word I was interested in. That may be enough for most cases. The information you are missing from isr/ior is the size of the write transaction. To get this you would need to parse the instruction stored in iir (code to determine the size of a store from the instruction in the iir will be necessary when an unaligned fault handler is written). John Marvin jsm@fc.hp.com From jsm@udlkern.fc.hp.com Thu, 23 Nov 2000 01:29:55 -0700 (MST) Date: Thu, 23 Nov 2000 01:29:55 -0700 (MST) From: John Marvin jsm@udlkern.fc.hp.com Subject: [parisc-linux] CONFIG_DMB_TRAP diff Alan Modra wrote: > > gdb will eventually want to use this trap too. > Cool! However, data memory break traps for user translations are a little tougher. There are some small modifications in the machine dependent code that I can make to make sure the B bit stays set during most VM operations on a page. However, since the machine independent part of the VM system doesn't know anything about this bit (nor should it), it won't be preserved if the page is paged out (and subsequently paged back in). This could be fixed fairly easily with some changes to the machine independent code, but I don't think that would be appropriate. Some potential solutions (each has its problems): 1) Just document the fact that the feature may not work on systems with low memory. It's a parisc only feature, so perhaps we could live with that. 2) Lock the page in memory (using the mlock interface) when we set the B bit on a page. Just some thoughts on the subject. John Marvin jsm@fc.hp.com From pjlahaie@linuxcare.com Fri, 24 Nov 2000 16:56:16 -0500 Date: Fri, 24 Nov 2000 16:56:16 -0500 From: Paul J.Y. Lahaie pjlahaie@linuxcare.com Subject: [parisc-linux] boot-floppies dependancies --GRPZ8SYKNexpdSJ7 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline I would like to know if anyone has built any of the following packages that are needed for the boot-floppies. Currently, the missing deps are: cspsfonts man-db tetex-bin recode cslatex libpaperg tetex-extra libnewt-dev libgd1g-dev gawk libi18n-langtags-perl dpkg-awk debiandoc-sgml I'm currently trying to get a working apt, since the one of pehc and the .iso seem to be broken (no xfer methods). I'll let everyone know when a working copy will be available. - Paul --GRPZ8SYKNexpdSJ7 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.4 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE6HuP/8ggPQthPCzcRAnyKAJ0fyraVXEvlI0yQLsli7FlnUUAPdwCfSyv/ YgAxOcVMDgWfHBc7lneuc1Y= =tScM -----END PGP SIGNATURE----- --GRPZ8SYKNexpdSJ7-- From doneill@linuxcare.com Fri, 24 Nov 2000 17:01:00 -0500 (EST) Date: Fri, 24 Nov 2000 17:01:00 -0500 (EST) From: Dave O'Neill doneill@linuxcare.com Subject: [parisc-linux] strace? So, I've heard rumours that somewhere there's a working strace for parisc.... Can anyone point me in the right direction? Dave -- Dave O'Neill, Senior Linux Consultant, Linuxcare, Inc. desk: (613) 562-9949 fax: (613) 562-9700 cell: (613) 223-0219 doneill@linuxcare.com http://www.linuxcare.com/ From obrien@FreeBSD.org Sat, 25 Nov 2000 12:22:11 -0800 Date: Sat, 25 Nov 2000 12:22:11 -0800 From: David O'Brien obrien@FreeBSD.org Subject: [parisc-linux] Use of the EI_OSABI field On Tue, Nov 21, 2000 at 03:27:19PM -0800, Ulrich Drepper wrote: > Alan Modra writes: > > > Ulrich Drepper also was quite vehement against changing sourceware > > FreeBSD binutils. > > I've never said anything about any *BSD, why should I? The *BSD > people wanted to change the Linux binutils. No (don't put words in my mouth Ulrich as you'll be wrong 99% of the time). I wanted the Sourceware Binutils to set the EI_OSABI to "ELFOSABI_LINUX" when targeting Linux. -- -- David (obrien@FreeBSD.org) From obrien@FreeBSD.org Sat, 25 Nov 2000 12:28:40 -0800 Date: Sat, 25 Nov 2000 12:28:40 -0800 From: David O'Brien obrien@FreeBSD.org Subject: [parisc-linux] Use of the EI_OSABI field On Tue, Nov 21, 2000 at 07:11:29PM -0800, H . J . Lu wrote: > When I was at the IA64 ABI meeting yesterday, we were looking at the > EI_OSABI issue. Everyone at the IA64 ABI meeting agreed that what > Ulrich and I had said was the correct understanding. > > "The e_ident[EI_OSABI] value identifies the operating system and ABI > to which the object is targeted" just means if the e_ident[EI_OSABI] Then is this *extremely* misleading text going to be changed??? "the operating system and" needs to be deleted in the _official_ _published_ specification. -- -- David (obrien@FreeBSD.org) From obrien@FreeBSD.org Sat, 25 Nov 2000 12:31:08 -0800 Date: Sat, 25 Nov 2000 12:31:08 -0800 From: David O'Brien obrien@FreeBSD.org Subject: [parisc-linux] Use of the EI_OSABI field On Tue, Nov 21, 2000 at 07:18:21PM -0800, Ulrich Drepper wrote: > Alan Modra writes: > > "The e_ident[EI_OSABI] value identifies the operating system and ABI to > > which the object is targeted" > > > > Granted, this is only in a processor specific ABI, but it does flatly > > contradict your assertions that the purpose of EI_OSABI is to flag the > > presense of ELF extensions. > > The meaning of the field changed over time. Or better said, some > people initially understood it differently. Then lets get the _official_ wording changed. Obviously my interpretation wasn't unreasonable. And the world does not need to have you as a premadona keeper of the [unwritten] rules of the land. -- -- David (obrien@FreeBSD.org) From hjl@valinux.com Sat, 25 Nov 2000 12:33:40 -0800 Date: Sat, 25 Nov 2000 12:33:40 -0800 From: H . J . Lu hjl@valinux.com Subject: [parisc-linux] Use of the EI_OSABI field On Sat, Nov 25, 2000 at 12:28:40PM -0800, David O'Brien wrote: > On Tue, Nov 21, 2000 at 07:11:29PM -0800, H . J . Lu wrote: > > When I was at the IA64 ABI meeting yesterday, we were looking at the > > EI_OSABI issue. Everyone at the IA64 ABI meeting agreed that what > > Ulrich and I had said was the correct understanding. > > > > "The e_ident[EI_OSABI] value identifies the operating system and ABI > > to which the object is targeted" just means if the e_ident[EI_OSABI] > > > Then is this *extremely* misleading text going to be changed??? > "the operating system and" needs to be deleted in the _official_ > _published_ specification. > I will bring this issue up to ia64 psABI and gABI. -- H.J. Lu (hjl@valinux.com) From alan@lxorguk.ukuu.org.uk Sat, 25 Nov 2000 20:57:05 +0000 (GMT) Date: Sat, 25 Nov 2000 20:57:05 +0000 (GMT) From: Alan Cox alan@lxorguk.ukuu.org.uk Subject: [parisc-linux] RPM and hppa I've uploaded my first block of RPM packages to ftp.linux.org.uk/pub/linux/alan/HPPA along with a tar ball of built RPM tools for anyone who wants to play. In doing so I've hit a few problems with the 0.5 iso (no suprises there since its not actually meant to work reliably) - g++ explodes trying to build groff after allocating about 400Mb of RAM. Building -O0 works - the configure script for procmail tries to find the largest argument set that works (by searching). It crashes the kernel in doing so 8) - ldd is causing page faults in ld.so (kernel logged ones) and dying with segv. Fortunately it outputs the library list first - The linker appears to have a problem when resolving symbols between three shared objects while doing a shared object link. [Example is rpm: rpmlib is linked dynamically with -ldb3 -ldb The linker emits messages about symbols being static and should be built -fPIC. If you dump the libraries they are -fPIC. It looks as if its resolving a symbol between two shared libraries and making a static resolution that then blows up when the third library gets involved ] - The kernel shows occasional page cache corruption. This actually is quite possibly generic test6 bugs On the whole the toolset is working remarkably well. I've built over 100 source package sets so far including things like ncurses and most stuff just builds or hits portability problems (eg gmp wants to use HP format asm, zlib wants to be a non PIC library for performance but the HP tools dont allow it) Alan From alan@linuxcare.com.au Sun, 26 Nov 2000 23:01:50 +1100 (EST) Date: Sun, 26 Nov 2000 23:01:50 +1100 (EST) From: Alan Modra alan@linuxcare.com.au Subject: [parisc-linux] RPM and hppa On Sat, 25 Nov 2000, Alan Cox wrote: > - g++ explodes trying to build groff after allocating about 400Mb of RAM. > Building -O0 works Yeah, this is a known issue. I see on the gcc list that rth and others have been working on gcc fixes recently that should address the problem. I don't have the time/ability to fix it myself. > - the configure script for procmail tries to find the largest argument set > that works (by searching). It crashes the kernel in doing so 8) > > - ldd is causing page faults in ld.so (kernel logged ones) and dying with > segv. Fortunately it outputs the library list first How old are your glibc and binutils? I made some changes late October that should have fixed this problem. See http://puffin.external.hp.com/mailing-lists/parisc-linux/2000/10-Oct/0146.html Does "readelf -d" on your hppa-linux ld.so show you have a DT_TEXTREL tag? > - The linker appears to have a problem when resolving symbols between three > shared objects while doing a shared object link. > > [Example is rpm: > > rpmlib is linked dynamically with -ldb3 -ldb > > The linker emits messages about symbols being static and should be > built -fPIC. If you dump the libraries they are -fPIC. > > It looks as if its resolving a symbol between two shared libraries > and making a static resolution that then blows up when the third > library gets involved > > ] Could you put all the objects involved in the link up for ftp somewhere? I've just built rpm-2.5.6 without seeing this problem, but I'm sure my setup is different to yours... Regards, Alan Modra -- Linuxcare. Support for the Revolution. From alan@lxorguk.ukuu.org.uk Sun, 26 Nov 2000 12:12:21 +0000 (GMT) Date: Sun, 26 Nov 2000 12:12:21 +0000 (GMT) From: Alan Cox alan@lxorguk.ukuu.org.uk Subject: [parisc-linux] RPM and hppa > How old are your glibc and binutils? I made some changes late October From the 0.5 cdrom > http://puffin.external.hp.com/mailing-lists/parisc-linux/2000/10-Oct/0146.html > Does "readelf -d" on your hppa-linux ld.so show you have a DT_TEXTREL tag? Nope > Could you put all the objects involved in the link up for ftp > somewhere? I've just built rpm-2.5.6 without seeing this problem, but I'm > sure my setup is different to yours... rpm 4.0. rpm2 doesnt do that 3 way link with db and db3. I'll put them up when I get a bit of time From dave@hiauly1.hia.nrc.ca Sun, 26 Nov 2000 11:45:08 -0500 (EST) Date: Sun, 26 Nov 2000 11:45:08 -0500 (EST) From: John David Anglin dave@hiauly1.hia.nrc.ca Subject: [parisc-linux] RPM and hppa > On Sat, 25 Nov 2000, Alan Cox wrote: > > > - g++ explodes trying to build groff after allocating about 400Mb of RAM. > > Building -O0 works > > Yeah, this is a known issue. I see on the gcc list that rth and others > have been working on gcc fixes recently that should address the problem. > I don't have the time/ability to fix it myself. I think the above is a different problem. The explosion is most likely a problem with exception edges in the gcse pass. Try `-fno-gcse'. This also appears in the tFile.cc libio test. The pa port uses sjlj exceptions via __builtin_setjmp/longjmp. A nonlocal goto label is used for the target of the longjmp. The flow analysis assumes that an "exception" could jump to any label in the procedure rather than just the label associated with the exception region. Dave -- J. David Anglin dave.anglin@nrc.ca National Research Council of Canada (613) 990-0752 (FAX: 952-6605) From cwalthall@cwalthall.com Sun, 26 Nov 2000 11:45:38 -0600 Date: Sun, 26 Nov 2000 11:45:38 -0600 From: Carl & Delores Walthall cwalthall@cwalthall.com Subject: [parisc-linux] RPM and hppa Does anyone know where I can find the operating system for the HP9000 J200 Server? Thanks Carl Walthall ----- Original Message ----- From: "Alan Modra" To: "Alan Cox" Cc: Sent: Sunday, November 26, 2000 6:01 AM Subject: Re: [parisc-linux] RPM and hppa > On Sat, 25 Nov 2000, Alan Cox wrote: > > > - g++ explodes trying to build groff after allocating about 400Mb of RAM. > > Building -O0 works > > Yeah, this is a known issue. I see on the gcc list that rth and others > have been working on gcc fixes recently that should address the problem. > I don't have the time/ability to fix it myself. > > > - the configure script for procmail tries to find the largest argument set > > that works (by searching). It crashes the kernel in doing so 8) > > > > - ldd is causing page faults in ld.so (kernel logged ones) and dying with > > segv. Fortunately it outputs the library list first > > How old are your glibc and binutils? I made some changes late October > that should have fixed this problem. See > http://puffin.external.hp.com/mailing-lists/parisc-linux/2000/10-Oct/0146.ht ml > Does "readelf -d" on your hppa-linux ld.so show you have a DT_TEXTREL tag? > > > - The linker appears to have a problem when resolving symbols between three > > shared objects while doing a shared object link. > > > > [Example is rpm: > > > > rpmlib is linked dynamically with -ldb3 -ldb > > > > The linker emits messages about symbols being static and should be > > built -fPIC. If you dump the libraries they are -fPIC. > > > > It looks as if its resolving a symbol between two shared libraries > > and making a static resolution that then blows up when the third > > library gets involved > > > > ] > > Could you put all the objects involved in the link up for ftp > somewhere? I've just built rpm-2.5.6 without seeing this problem, but I'm > sure my setup is different to yours... > > Regards, Alan Modra > -- > Linuxcare. Support for the Revolution. > > > -------------------------------------------------------------------------- - > To unsubscribe: send e-mail to parisc-linux-request@thepuffingroup.com with > `unsubscribe' as the subject. > From cwalthall@cwalthall.com Sun, 26 Nov 2000 11:47:24 -0600 Date: Sun, 26 Nov 2000 11:47:24 -0600 From: Carl & Delores Walthall cwalthall@cwalthall.com Subject: [parisc-linux] RPM and hppa Hi All I have a HP9000 J200 server and would like to find the operating system software for it. Can you tell me where to look on the internet or who I may call? The server has a OS installed but no one can remember the user or password information. So they gave it to me to take home, is there a way to boot it on a floppy and change this information? Thanks for any information you can give me! Carl walthall ----- Original Message ----- From: "John David Anglin" To: "Alan Modra" Cc: ; Sent: Sunday, November 26, 2000 10:45 AM Subject: Re: [parisc-linux] RPM and hppa > > On Sat, 25 Nov 2000, Alan Cox wrote: > > > > > - g++ explodes trying to build groff after allocating about 400Mb of RAM. > > > Building -O0 works > > > > Yeah, this is a known issue. I see on the gcc list that rth and others > > have been working on gcc fixes recently that should address the problem. > > I don't have the time/ability to fix it myself. > > I think the above is a different problem. The explosion is most likely > a problem with exception edges in the gcse pass. Try `-fno-gcse'. This > also appears in the tFile.cc libio test. > > The pa port uses sjlj exceptions via __builtin_setjmp/longjmp. A > nonlocal goto label is used for the target of the longjmp. The flow > analysis assumes that an "exception" could jump to any label in the > procedure rather than just the label associated with the exception > region. > > Dave > -- > J. David Anglin dave.anglin@nrc.ca > National Research Council of Canada (613) 990-0752 (FAX: 952-6605) > > -------------------------------------------------------------------------- - > To unsubscribe: send e-mail to parisc-linux-request@thepuffingroup.com with > `unsubscribe' as the subject. > From alan@lxorguk.ukuu.org.uk Sun, 26 Nov 2000 22:47:43 +0000 (GMT) Date: Sun, 26 Nov 2000 22:47:43 +0000 (GMT) From: Alan Cox alan@lxorguk.ukuu.org.uk Subject: [parisc-linux] Linker failure with db1 I replaced the libdb1 on the ISO with one built using the toolchain on the ISO and all is now happy. From grundler@cup.hp.com Sun, 26 Nov 2000 19:11:41 -0800 Date: Sun, 26 Nov 2000 19:11:41 -0800 From: Grant Grundler grundler@cup.hp.com Subject: [parisc-linux] RPM and hppa "Carl & Delores Walthall" wrote: > Hi All > > I have a HP9000 J200 server and would like to find the operating system > software for it. Can you tell me where to look on the internet or who I may > call? Carl, The short answer is a port of linux to the J200 is in progress. See http://www.parisc-linux.org/ for status. If you have more questions read the FAQ and check the mailing list archives using http://puffin.external.hp.com/cgi-bin/mailgrep first please. > The server has a OS installed but no one can remember the user or password > information. So they gave it to me to take home, is there a way to boot > it on a floppy and change this information? Here's how to "fix" this: During power up/boot press key to get "BOOT ADMIN>" prompt. type "bo pri isl". At "ISL>" prompt, type "hpux -is". HPUX should boot to single user. use "mountall" or "mount -a" to mount all file systems. Then you can "vi /etc/passwd" or "passwd root". If that doesn't work and you can afford to loan the box out for a 3-4 monthes, you might ask if someone could install parisc-linux on it for you in exchange for a few monthes use. grant Grant Grundler Unix Systems Enablement Lab +1.408.447.7253 From grundler@cup.hp.com Sun, 26 Nov 2000 22:12:10 -0800 Date: Sun, 26 Nov 2000 22:12:10 -0800 From: Grant Grundler grundler@cup.hp.com Subject: [parisc-linux] case LEDs Alex deVries wrote: > Grant Grundler wrote: > > I was already asked this weekend to dig up technical info on LED > > and soft power control. I guess this is my reminder to do that. :^) I dug up the info but it's not in a form I'm willing to publishing. However, someone did volunteer to look at this and I've provided them with this info. So it will make into our CVS source tree and get published that way. > Isn't there a PDC call (pdc_chassis?) to do this? Not AFAICT. PDC_CHASSIS is documented in the pdc32.pdf found on http://www.parisc-linux.org/documentation.html But my gut feeling is parisc specific code could make some PDC_CHASSIS calls to set up "sysstat" field (eg initialize, shutdown, run states). Does anyone know if the chassis codes used by HPUX are published? It would be cool if parisc-linux used the same codes where possible... > Or is the heartbeat LED done by hardware? Code I've looked at before seems to all do it in software. grant Grant Grundler Unix Systems Enablement Lab +1.408.447.7253 From sanjak@tipas.lt Mon, 27 Nov 2000 09:09:22 +0200 Date: Mon, 27 Nov 2000 09:09:22 +0200 From: Aleksandr Konstantinov sanjak@tipas.lt Subject: [parisc-linux] how to boot ? Hello, All. We have two HP Workstations here (Model 735). I would like to try linux on one of them. But I have no disk space to install all the stuff (binutils, compiler, etc) . I found precompiled kernel on puffin.external.hp.com but it looks like I also need palo . Does anybody know, where to get precompiled palo for hpux9, hpux10 or linux-x86 ? Thanks in advance. A.K. From rhirst@linuxcare.com Mon, 27 Nov 2000 09:18:21 +0000 Date: Mon, 27 Nov 2000 09:18:21 +0000 From: Richard Hirst rhirst@linuxcare.com Subject: [parisc-linux] strace? Hi Dave, The source is in cvs on pehc; I can supply a binary if you want one. I havn't made serious use of it, but it does basically work. Richard On Fri, Nov 24, 2000 at 05:01:00PM -0500, Dave O'Neill wrote: > > So, I've heard rumours that somewhere there's a working strace for > parisc.... Can anyone point me in the right direction? > > Dave > -- > Dave O'Neill, Senior Linux Consultant, Linuxcare, Inc. > desk: (613) 562-9949 fax: (613) 562-9700 cell: (613) 223-0219 > doneill@linuxcare.com http://www.linuxcare.com/ > > --------------------------------------------------------------------------- > To unsubscribe: send e-mail to parisc-linux-request@thepuffingroup.com with > `unsubscribe' as the subject. > > From alan@lxorguk.ukuu.org.uk Mon, 27 Nov 2000 16:55:36 +0000 (GMT) Date: Mon, 27 Nov 2000 16:55:36 +0000 (GMT) From: Alan Cox alan@lxorguk.ukuu.org.uk Subject: [parisc-linux] RPM and hppa > I think the above is a different problem. The explosion is most likely > a problem with exception edges in the gcse pass. Try `-fno-gcse'. This > also appears in the tFile.cc libio test. I've not yet had a chance to try this. I see the same behaviour building Qt so I may try it on that From marteaut@esiee.fr Mon, 27 Nov 2000 18:11:36 +0000 Date: Mon, 27 Nov 2000 18:11:36 +0000 From: marteau marteaut@esiee.fr Subject: [parisc-linux] Hi all, We have tried to compile the new linux source today and vmlinux always needs pci.o to link. It works if you delete pci.o from the objects list in the kernel Makefile. But, we don't know why it was needed because we did not ask for in our "make config"... We appreciate any help! THX, ESIEE Team From dave@hiauly1.hia.nrc.ca Mon, 27 Nov 2000 12:13:02 -0500 (EST) Date: Mon, 27 Nov 2000 12:13:02 -0500 (EST) From: John David Anglin dave@hiauly1.hia.nrc.ca Subject: [parisc-linux] RPM and hppa > > > I think the above is a different problem. The explosion is most likely > > a problem with exception edges in the gcse pass. Try `-fno-gcse'. This > > also appears in the tFile.cc libio test. > > I've not yet had a chance to try this. I see the same behaviour building Qt > so I may try it on that Another option that might help if exceptions aren't needed is `-fno-exceptions'. Dave -- J. David Anglin dave.anglin@nrc.ca National Research Council of Canada (613) 990-0752 (FAX: 952-6605) From grundler@cup.hp.com Mon, 27 Nov 2000 09:57:39 -0800 Date: Mon, 27 Nov 2000 09:57:39 -0800 From: Grant Grundler grundler@cup.hp.com Subject: No subject marteau wrote: > We have tried to compile the new linux source today and vmlinux > always needs pci.o to link. It works if you delete pci.o from the > objects list in the kernel Makefile. But, we don't know why it was > needed because we did not ask for in our "make config"... Hi Thomas, The problem is in arch/parisc/kernel/Makefile. It doesn't use CONFIG_PCI to decide if pci.o is needed. I'll fix that now - should be simple. thanks, grant From dave@hiauly1.hia.nrc.ca Mon, 27 Nov 2000 13:19:52 -0500 (EST) Date: Mon, 27 Nov 2000 13:19:52 -0500 (EST) From: John David Anglin dave@hiauly1.hia.nrc.ca Subject: [parisc-linux] RPM and hppa > > I think the above is a different problem. The explosion is most likely > > a problem with exception edges in the gcse pass. Try `-fno-gcse'. This > > also appears in the tFile.cc libio test. > > I've not yet had a chance to try this. I see the same behaviour building Qt > so I may try it on that If the problem is in fact the exception handling method, I think we should look at implementing the DWARF2 unwind mechanism and exception handling using this unwind mechanism. The default method of handling exceptions is sjlj. See the description of DWARF2_UNWIND_INFO and INCOMING_RETURN_ADDR_RTX in gcc/tm.texi for more info. Alan Modra may want this for gdb as well. Dave -- J. David Anglin dave.anglin@nrc.ca National Research Council of Canada (613) 990-0752 (FAX: 952-6605) From alan@lxorguk.ukuu.org.uk Mon, 27 Nov 2000 18:34:23 +0000 (GMT) Date: Mon, 27 Nov 2000 18:34:23 +0000 (GMT) From: Alan Cox alan@lxorguk.ukuu.org.uk Subject: [parisc-linux] gcc crashes/out of memory and groff With groff -fno-gcse does not help but -O0 does. Without -O0 you get an internal error. g++ -I. -I/usr/src/redhat/BUILD/groff-1.16/src/roff/troff -I/usr/src/redhat/BUILD/groff-1.16/src/include -I/usr/src/redhat/BUILD/groff-1.16/src/include -DHAVE_UNISTD_H=1 -DHAVE_DIRENT_H=1 -DHAVE_LIMITS_H=1 -DHAVE_SYS_DIR_H=1 -DHAVE_STDLIB_H=1 -DHAVE_STRINGS_H=1 -DSTDLIB_H_DECLARES_PUTENV=1 -DSTDIO_H_DECLARES_POPEN=1 -DSTDIO_H_DECLARES_PCLOSE=1 -DHAVE_SYS_NERR=1 -DHAVE_SYS_ERRLIST=1 -DHAVE_CC_LIMITS_H=1 -DRETSIGTYPE=void -DHAVE_STRUCT_EXCEPTION=1 -DHAVE_UNISTD_H=1 -DHAVE_GETPAGESIZE=1 -DHAVE_MMAP=1 -DHAVE_FMOD=1 -DHAVE_STRTOL=1 -DHAVE_GETCWD=1 -DHAVE_STRERROR=1 -DHAVE_PUTENV=1 -DHAVE_RENAME=1 -DHAVE_MKSTEMP=1 -DHAVE_STRCASECMP=1 -DHAVE_STRSEP=1 -DHAVE_STRDUP=1 -DSYS_SIGLIST_DECLARED=1 -O2 -mpa-risc-1-0 -fno-gcse -c env.cc env.cc: In member function `void environment::output_line (node *, hunits)': env.cc:1582: Internal error: Segmentation fault. Please submit a full bug report. See for instructions. make[2]: *** [env.o] Error 1 make[2]: Leaving directory `/usr/src/redhat/BUILD/groff-1.16/src/roff/troff' Alan From marteaut@esiee.fr Mon, 27 Nov 2000 21:31:09 +0100 Date: Mon, 27 Nov 2000 21:31:09 +0100 From: Thomas Marteau marteaut@esiee.fr Subject: [parisc-linux] Include trouble Hi folks, Just to know if it is a local problem. We have this warning when we cross compile the kernel: /linux/cvs/linux/include/linux/string.h:61: warning: conflicting types for built-in function `memset' /linux/cvs/linux/include/linux/string.h:64: warning: conflicting types for built-in function `memcpy' /linux/cvs/linux/include/linux/string.h:73: warning: conflicting types for built-in function `memcmp' Can we have your point of view? Bye, ESIEE Team From marteaut@esiee.fr Tue, 28 Nov 2000 00:17:24 +0100 Date: Tue, 28 Nov 2000 00:17:24 +0100 From: Thomas Marteau marteaut@esiee.fr Subject: [parisc-linux] Leds Hi all, We tried to implement the led power of 712 hp boxes. We call leds_init in main.c in init directory. Even though it is working, we are not sure where to put the source that must be completed for others models. We could make a LEDS directory in drivers put the file in the kernel directory We also put the source for the initialisation of keyboard leds in lasi_ps2_reset but we admit that no led is on. Is it true? How can we know? THX, ESIEE Team From alan@linuxcare.com.au Tue, 28 Nov 2000 12:12:03 +1100 (EST) Date: Tue, 28 Nov 2000 12:12:03 +1100 (EST) From: Alan Modra alan@linuxcare.com.au Subject: [parisc-linux] gcc crashes/out of memory and groff On Mon, 27 Nov 2000, Alan Cox wrote: > With groff -fno-gcse does not help but -O0 does. Without -O0 you get an > internal error. Cross compiling from an x86-linux box with enough memory+swap (256M + 2G), env.cc eventually compiled for me using the default -O2 optimisation level. I had a crash later when compiling preproc/tbl/table.cc, so that's nothing to boast about. table.cc: In member function `void table::build_span_list ()': table.cc:2009: Internal error: Segmentation fault. Worse, when I added "-Q -da" to see what was happening, the compile succeeded - and also succeeded with either of -Q or -da alone. So I ran cc1plus under gdb, and that too failed to crash. :-( Maybe a garbage collection or uninitialised var bug? Alan Modra -- Linuxcare. Support for the Revolution. From alan@linuxcare.com.au Tue, 28 Nov 2000 15:59:54 +1100 (EST) Date: Tue, 28 Nov 2000 15:59:54 +1100 (EST) From: Alan Modra alan@linuxcare.com.au Subject: [parisc-linux] Include trouble On Mon, 27 Nov 2000, Thomas Marteau wrote: > Can we have your point of view? Your version of gcc expects the size_t parameter to all these functions to be "unsigned int", whereas the 2000/11/18 changes to linux/include/asm-parisc/posix_types.h made __kernel_size_t "unsigned long". As far as I understand, gcc's cpp has a built-in definition of size_t, __SIZE_TYPE__, and it ultimately gets it's idea of the definition from the kernel includes on the machine where gcc was compiled. ie. recompile gcc with the new kernel headers installed, and the problem should go away. For 32-bit hppa-linux, sizeof(int) == sizeof(long) so there shouldn't be any practical consequence other than these warning messages. There might be some "interesting" problems on hppa64-linux - I'm not sure. Alan Modra -- Linuxcare. Support for the Revolution. From alan@linuxcare.com.au Tue, 28 Nov 2000 20:19:20 +1100 (EST) Date: Tue, 28 Nov 2000 20:19:20 +1100 (EST) From: Alan Modra alan@linuxcare.com.au Subject: [parisc-linux] Include trouble On Tue, 28 Nov 2000, Alan Modra wrote: > As far as I understand, gcc's cpp has a built-in definition of size_t, > __SIZE_TYPE__, and it ultimately gets it's idea of the definition from the > kernel includes on the machine where gcc was compiled. ie. recompile gcc > with the new kernel headers installed, and the problem should go away. No, that's wrong. __SIZE_TYPE__ comes from `#define SIZE_TYPE' in gcc/config/pa/pa-linux{,64}.h I'll check in a patch to gcc in a few moments. Alan -- Linuxcare. Support for the Revolution. From marteaut@esiee.fr Tue, 28 Nov 2000 16:07:04 +0100 Date: Tue, 28 Nov 2000 16:07:04 +0100 From: Thomas Marteau marteaut@esiee.fr Subject: [parisc-linux] Mouse driver for PS/2 Hi all, We appreciate if someone can explain where we can find request_irq and request_region in hp_psaux.c and also, what are they doing? Thanks, ESIEE Team From deller@gmx.de Tue, 28 Nov 2000 18:21:34 +0100 Date: Tue, 28 Nov 2000 18:21:34 +0100 From: Helge Deller deller@gmx.de Subject: [parisc-linux] Mouse driver for PS/2 On Tuesday 28 November 2000 16:07, Thomas Marteau wrote: > Hi all, Hi Thomas, > > We appreciate if someone can explain where we can find request_irq #include and /arch/parisc/kernel/irq.c request_irq() binds the given interrupt-number to a function (if possible). > and > request_region #include request_region only marks (and tests) an I/O-region as used by a driver and makes this information visible via /proc/iomem and /proc/ioports. > in hp_psaux.c and also, > what are they doing? > > Thanks, > ESIEE Team From wferguson@server01.chatspace.com Tue, 28 Nov 2000 09:35:36 -0800 Date: Tue, 28 Nov 2000 09:35:36 -0800 From: William Ferguson wferguson@server01.chatspace.com Subject: [parisc-linux] PDC firmware revision FAQ update This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C05961.9E1AB8A8 Content-Type: text/plain; charset="iso-8859-1" Is the web server at www.parisc-linux.org down? Can't seem to connect from San Diego. -----Original Message----- From: Grant Grundler [mailto:grundler@cup.hp.com] Sent: Friday, November 17, 2000 1:51 PM To: parisc-linux@puffin.external.hp.com Subject: [parisc-linux] PDC firmware revision FAQ update Hi folks, The issue of PDC/firmware revs came up locally and sounded like a FAQ. I added "10. How can I check if the PDC (firmware) revision is the latest?" and what I knew/could find to our FAQ at: http://www.parisc-linux.org/faq.html The new FAQ entry should be visible to the world in the next hour or so. **** WARNING **** Firmware upgrades can *kill* your machine! **** WARNING **** Don't do it just because. Read the FAQ carefully. Take the time to figure out why you might need the upgrade and expose yourself to this risk. grant ps. please don't ask me why your favorite machine's PDC isn't listed. I don't run the referenced sites. --------------------------------------------------------------------------- To unsubscribe: send e-mail to parisc-linux-request@thepuffingroup.com with `unsubscribe' as the subject. ------_=_NextPart_001_01C05961.9E1AB8A8 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [parisc-linux] PDC firmware revision FAQ update

Is the web server at www.parisc-linux.org down?  = Can't seem to connect from San Diego.

-----Original Message-----
From: Grant Grundler [mailto:grundler@cup.hp.com]
Sent: Friday, November 17, 2000 1:51 PM
To: parisc-linux@puffin.external.hp.com
Subject: [parisc-linux] PDC firmware revision FAQ = update


Hi folks,

The issue of PDC/firmware revs came up locally and = sounded like a FAQ.
I added

    "10. How can I check if the = PDC (firmware) revision is the latest?"

and what I knew/could find to our FAQ at:

        http://www.parisc-linux.org/faq.html

The new FAQ entry should be visible to the world in = the next hour or so.


    **** WARNING ****
    Firmware upgrades can *kill* your = machine!
    **** WARNING ****

Don't do it just because. Read the FAQ carefully. = Take the
time to figure out why you might need the upgrade = and expose
yourself to this risk.

grant

ps. please don't ask me why your favorite machine's = PDC isn't listed.
   I don't run the referenced = sites.

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

------_=_NextPart_001_01C05961.9E1AB8A8-- From dave@hiauly1.hia.nrc.ca Tue, 28 Nov 2000 12:37:28 -0500 (EST) Date: Tue, 28 Nov 2000 12:37:28 -0500 (EST) From: John David Anglin dave@hiauly1.hia.nrc.ca Subject: [parisc-linux] Include trouble > On Tue, 28 Nov 2000, Alan Modra wrote: > > > As far as I understand, gcc's cpp has a built-in definition of size_t, > > __SIZE_TYPE__, and it ultimately gets it's idea of the definition from the > > kernel includes on the machine where gcc was compiled. ie. recompile gcc > > with the new kernel headers installed, and the problem should go away. > > No, that's wrong. __SIZE_TYPE__ comes from `#define SIZE_TYPE' in > gcc/config/pa/pa-linux{,64}.h I'll check in a patch to gcc in a few > moments. Hmm. Most 32 bit systems use "unsigned int" rather than "unsigned long". Using "unsigned long" might cause problems with packages like libio. I know there is a problem if off_t is not the same as size_t. Dave -- J. David Anglin dave.anglin@nrc.ca National Research Council of Canada (613) 990-0752 (FAX: 952-6605) From grundler@cup.hp.com Tue, 28 Nov 2000 09:49:26 -0800 Date: Tue, 28 Nov 2000 09:49:26 -0800 From: Grant Grundler grundler@cup.hp.com Subject: [parisc-linux] Mouse driver for PS/2 Thomas Marteau wrote: > Hi all, > > We appreciate if someone can explain where we can find request_irq and > request_region in hp_psaux.c and also, what are they doing? include/linux/sched.h:extern int request_irq(unsigned int, ...) (Implementation is in arch/parisc/kernel/irq.c) The request_irq() "allocates" an IRQ line for use by the device - this program the PIC (or APIC) on x86 platforms. request_irq() is also how an interrupt handler is associated with a specific IRQ line. Since PA Risc CPU's don't have IRQ lines going into them, IRQ's are virtualized and don't always represent a physical IRQ line. Under LASI, see gsc_alloc_irq(&gsc_irq) usage in drivers/gsc/lasi.c. lasi_find_irq() helps associate the PS/2 interrupt handler with the correct IRQ line which is internal to lasi. include/linux/ioport.h:#define request_region(start,n,name) ... request_region() will reserve a range of I/O port address from the global I/O space. request_mem_region() does the same for MMIO. Drivers that use inb/outb (as defined in include/asm-parisc/io.h) must use request_region(). Drivers that use gsc_readb/gsc_writeb (as defined in include/asm-parisc/gsc.h) must use request_mem_region(). Collisions are probably occuring where a driver originally used inb/outb and those were redefined to use gsc_readb/writeb functions. But the driver is still using request_region(). And it doesn't help that I may have broken some of the resource mgt with some code I committed last night. It worked on my boxes (A180/C3K) but broke on other folks. Paul Bame helped find/fix one bug but I shouldn't be surprised if more bugs are still out there. I will be fixing some known resource failure problems on A500. Please post problems on other platforms to parisc-linux list as well. hope this helps, grant Grant Grundler Unix Systems Enablement Lab +1.408.447.7253 From grundler@cup.hp.com Tue, 28 Nov 2000 09:53:37 -0800 Date: Tue, 28 Nov 2000 09:53:37 -0800 From: Grant Grundler grundler@cup.hp.com Subject: [parisc-linux] PDC firmware revision FAQ update William Ferguson wrote: > Is the web server at www.parisc-linux.org down? Can't seem to connect from > San Diego. Yes. Linuxcare is having some DNS problems right now and they host that site. Any forecasts on when that will be back up? grant From bame@noam.fc.hp.com Tue, 28 Nov 2000 12:27:09 -0700 Date: Tue, 28 Nov 2000 12:27:09 -0700 From: Paul Bame bame@noam.fc.hp.com Subject: [parisc-linux] Include trouble = Hmm. Most 32 bit systems use "unsigned int" rather than "unsigned long". I will be happy to change it back to unsigned int. The only reason I used unsigned long is because it seems off_t wants to be, to a first approximation, the word length of the machine, and 'long' does that. = Using "unsigned long" might cause problems with packages like libio. = I know there is a problem if off_t is not the same as size_t. What problem is that? I'm working on a proposal for the palinux type sizes at the moment. One dilema is that off_t is supposed to be good for file offsets, which these days means it should be 64 bits. size_t refers to the sizes of objects which are expected to fit in RAM, so should be the word size of the machine. So there's a conflict because one logic suggests 64-bit off_t and 32-bit size_t on 32-bit palinux, but your statement suggests they should be the same size. Any ideas? However I'm leaning towards leaning with the older 32-bit off_t because we might not want to be the first ones to fix all the problems with making it 64 bits on a 32-bit machine. -P From marteaut@esiee.fr Tue, 28 Nov 2000 20:30:30 +0100 Date: Tue, 28 Nov 2000 20:30:30 +0100 From: Thomas Marteau marteaut@esiee.fr Subject: [parisc-linux] Mouse driver for PS/2 Hi all, We have a sample of code for the mouse driver. But, we would like to know how the Puffin would like the implementation of the driver. Because of drag & drop..., do you want two different interrupt functions or a single that does a redirection. Also , we have seen that busmouse.c is quite interesting for our driver. Do we make a copy and call it hp_mouse.c? Thanks for your answer, ESIEE Team For a better future with a mouse! From alan@lxorguk.ukuu.org.uk Tue, 28 Nov 2000 20:02:26 +0000 (GMT) Date: Tue, 28 Nov 2000 20:02:26 +0000 (GMT) From: Alan Cox alan@lxorguk.ukuu.org.uk Subject: [parisc-linux] Include trouble > One dilema is that off_t is supposed to > be good for file offsets, which these days means it should be 64 bits. off_t should be a natural type. So it should be 32bits. glibc 2.2 deals with the 64bit I/O stuff nicely > However I'm leaning towards leaning with the older 32-bit off_t because > we might not want to be the first ones to fix all the problems with > making it 64 bits on a 32-bit machine. Go 32bit. Linus will probably refuse to touch a 32bit port using longlong internally for off-t From dave@hiauly1.hia.nrc.ca Tue, 28 Nov 2000 15:24:26 -0500 (EST) Date: Tue, 28 Nov 2000 15:24:26 -0500 (EST) From: John David Anglin dave@hiauly1.hia.nrc.ca Subject: [parisc-linux] Include trouble > = Hmm. Most 32 bit systems use "unsigned int" rather than "unsigned long". > > I will be happy to change it back to unsigned int. The only reason > I used unsigned long is because it seems off_t wants to be, to a > first approximation, the word length of the machine, and 'long' does > that. Agreed. > = Using "unsigned long" might cause problems with packages like libio. > > > = I know there is a problem if off_t is not the same as size_t. > > What problem is that? I'm working on a proposal for the palinux > type sizes at the moment. It is simply dumb coding that hasn't been fixed. There are inconsistencies between the interface declarations and implementations. The old libio is on the way out. > One dilema is that off_t is supposed to > be good for file offsets, which these days means it should be 64 bits. > size_t refers to the sizes of objects which are expected to fit in > RAM, so should be the word size of the machine. So there's a conflict > because one logic suggests 64-bit off_t and 32-bit size_t on 32-bit palinux, > but your statement suggests they should be the same size. Any ideas? Only, because of poorly written legacy code. I agree that off_t should be 64 bits on 32 bit platforms today. > However I'm leaning towards leaning with the older 32-bit off_t because > we might not want to be the first ones to fix all the problems with > making it 64 bits on a 32-bit machine. Maybe it isn't that bad because I noticed at least one port used unsigned long long for off_t. Dave -- J. David Anglin dave.anglin@nrc.ca National Research Council of Canada (613) 990-0752 (FAX: 952-6605) From dave@hiauly1.hia.nrc.ca Tue, 28 Nov 2000 15:33:52 -0500 (EST) Date: Tue, 28 Nov 2000 15:33:52 -0500 (EST) From: John David Anglin dave@hiauly1.hia.nrc.ca Subject: [parisc-linux] Include trouble > Maybe it isn't that bad because I noticed at least one port used unsigned > long long for off_t. Take that back. It was __kernel_loff_t. Just go with typedef unsigned int __kernel_size_t; typedef long __kernel_off_t; #ifdef __GNUC__ typedef long long __kernel_loff_t; #endif for the 32 bit port. Dave -- J. David Anglin dave.anglin@nrc.ca National Research Council of Canada (613) 990-0752 (FAX: 952-6605) From deller@gmx.de Tue, 28 Nov 2000 21:41:53 +0100 Date: Tue, 28 Nov 2000 21:41:53 +0100 From: Helge Deller deller@gmx.de Subject: [parisc-linux] Mouse driver for PS/2 On Tuesday 28 November 2000 20:30, Thomas Marteau wrote: > Hi all, Hi Thomas, > > We have a sample of code for the mouse driver. But, we would like to > know how the Puffin would like the implementation of the driver. Because > of drag & drop..., do you want two different interrupt functions or a > single that does a redirection. Also , we have seen that busmouse.c is > quite interesting for our driver. Do we make a copy and call it > hp_mouse.c? I would propose, that you check in hp_mouse.c and use different interrupt functions for now. Changing it later shouldn't be too difficult. Greetings, Helge. > > Thanks for your answer, > ESIEE Team > For a better future with a mouse! From doneill@linuxcare.com Tue, 28 Nov 2000 16:08:49 -0500 (EST) Date: Tue, 28 Nov 2000 16:08:49 -0500 (EST) From: Dave O'Neill doneill@linuxcare.com Subject: [parisc-linux] PDC firmware revision FAQ update On Tue, 28 Nov 2000, Grant Grundler wrote: > Yes. Linuxcare is having some DNS problems right now and > they host that site. Any forecasts on when that will be back up? Well, it looks like our DNS issues are fixed... the site should be accessible now. Dave -- Dave O'Neill, Senior Linux Consultant, Linuxcare, Inc. desk: (613) 562-9949 fax: (613) 562-9700 cell: (613) 223-0219 doneill@linuxcare.com http://www.linuxcare.com/ From bame@noam.fc.hp.com Tue, 28 Nov 2000 14:21:05 -0700 Date: Tue, 28 Nov 2000 14:21:05 -0700 From: Paul Bame bame@noam.fc.hp.com Subject: [parisc-linux] Include trouble = Go 32bit. Linus will probably refuse to touch a 32bit port using longlong = internally for off-t Hmmm, too bad, since we have few palinux backwards compatibility issues and could just have the __USE_FILE_OFFSET64 glibc magic be a no-op rather than supporting all those extra *64 syscalls. Plus we'd need considerably fewer syscall translators to run 32-bit apps on 64-bit kernel (but might need more for 32-bit hpux apps). It seems illogical to make a file-system-related data type different based on cpu word size but I understand this isn't simple -- oh well. Seems like the consensus is 32-bit off_t on 32-bit kernel and just live with all those *64 syscalls -- many not supported on palinux yet I notice. -P From alan@lxorguk.ukuu.org.uk Tue, 28 Nov 2000 21:58:56 +0000 (GMT) Date: Tue, 28 Nov 2000 21:58:56 +0000 (GMT) From: Alan Cox alan@lxorguk.ukuu.org.uk Subject: [parisc-linux] Include trouble > Seems like the consensus is 32-bit off_t on 32-bit kernel and just > live with all those *64 syscalls -- many not supported on palinux > yet I notice. Remember providing you use off_t you can just tell glibc to do all the work for you and write with a 64bit off_t to userspace From alan@linuxcare.com.au Wed, 29 Nov 2000 10:27:20 +1100 (EST) Date: Wed, 29 Nov 2000 10:27:20 +1100 (EST) From: Alan Modra alan@linuxcare.com.au Subject: [parisc-linux] Include trouble On Tue, 28 Nov 2000, John David Anglin wrote: > Hmm. Most 32 bit systems use "unsigned int" rather than "unsigned long". There's some precedent for using "unsigned long", as that is what is used on 32-bit hpux11 and osf gcc targets. current sourceware CVS gcc/config/pa/: $ grep SIZE_TYPE * grep: CVS: Is a directory pa-64.h:#undef SIZE_TYPE pa-64.h:#define SIZE_TYPE "long unsigned int" pa-hpux.h:#undef SIZE_TYPE pa-hpux.h:#define SIZE_TYPE "unsigned int" pa-hpux11.h:#undef SIZE_TYPE pa-hpux11.h:#define SIZE_TYPE "long unsigned int" pa-hpux7.h:#undef SIZE_TYPE pa-hpux7.h:#define SIZE_TYPE "unsigned int" pa-linux.h:#undef SIZE_TYPE pa-linux.h:#define SIZE_TYPE "unsigned int" pa-osf.h:#undef SIZE_TYPE pa-osf.h:#define SIZE_TYPE "long unsigned int" pa-pro-end.h:#undef SIZE_TYPE pa-pro-end.h:#define SIZE_TYPE "unsigned int" pa.h:#define SIZE_TYPE "unsigned int" Some further grepping shows quite a number of other 32-bit gcc targets using "unsigned long", but I didn't see any 32-bit linux targets in the list. Paul, If you change back to "unsigned int", please change gcc/config/pa/pa-linux.h too. Alan -- Linuxcare. Support for the Revolution. From Frank.Butter@otto.de Wed, 29 Nov 2000 11:50:39 +0100 Date: Wed, 29 Nov 2000 11:50:39 +0100 From: Butter, Frank Frank.Butter@otto.de Subject: [parisc-linux] hardware to all here I was annaouncing an offer for hp hardware recently: it'll take longer than initially expected to convince our bosses ;-/ please stay patient... frank From matthias@archimed.math.uni-mannheim.de Wed, 29 Nov 2000 20:52:38 +0100 (MET) Date: Wed, 29 Nov 2000 20:52:38 +0100 (MET) From: Matthias Juchem matthias@archimed.math.uni-mannheim.de Subject: [parisc-linux] parisc-0.5.iso and stack trace Hi there. I've just downloaded the ISO images and tried to boot an 9000/705. I keep getting a stack trace. Can you tell me which part of the trace I can send you so that you could eventually tell me what is wrong? TIA, Matthias From dave@hiauly1.hia.nrc.ca Wed, 29 Nov 2000 17:05:31 -0500 (EST) Date: Wed, 29 Nov 2000 17:05:31 -0500 (EST) From: John David Anglin dave@hiauly1.hia.nrc.ca Subject: [parisc-linux] gcc crashes/out of memory and groff > With groff -fno-gcse does not help but -O0 does. Without -O0 you get an > internal error. > > g++ -I. -I/usr/src/redhat/BUILD/groff-1.16/src/roff/troff -I/usr/src/redhat/BUILD/groff-1.16/src/include -I/usr/src/redhat/BUILD/groff-1.16/src/include -DHAVE_UNISTD_H=1 -DHAVE_DIRENT_H=1 -DHAVE_LIMITS_H=1 -DHAVE_SYS_DIR_H=1 -DHAVE_STDLIB_H=1 -DHAVE_STRINGS_H=1 -DSTDLIB_H_DECLARES_PUTENV=1 -DSTDIO_H_DECLARES_POPEN=1 -DSTDIO_H_DECLARES_PCLOSE=1 -DHAVE_SYS_NERR=1 -DHAVE_SYS_ERRLIST=1 -DHAVE_CC_LIMITS_H=1 -DRETSIGTYPE=void -DHAVE_STRUCT_EXCEPTION=1 -DHAVE_UNISTD_H=1 -DHAVE_GETPAGESIZE=1 -DHAVE_MMAP=1 -DHAVE_FMOD=1 -DHAVE_STRTOL=1 -DHAVE_GETCWD=1 -DHAVE_STRERROR=1 -DHAVE_PUTENV=1 -DHAVE_RENAME=1 -DHAVE_MKSTEMP=1 -DHAVE_STRCASECMP=1 -DHAVE_STRSEP=1 -DHAVE_STRDUP=1 -DSYS_SIGLIST_DECLARED=1 -O2 -mpa-risc-1-0 -fno-gcse -c env.cc > env.cc: In member function `void environment::output_line (node *, hunits)': > env.cc:1582: Internal error: Segmentation fault. > Please submit a full bug report. > See for instructions. > make[2]: *** [env.o] Error 1 > make[2]: Leaving directory `/usr/src/redhat/BUILD/groff-1.16/src/roff/troff' This error is also exception related but appears different from the memory explosion. It occurs in scan_region in except.c. The memory explosion that occurs without -fno-gcse does seem to occur in the gcse pass as I suspected. I need to rebuild gcc with debugging to get further. I was able to build the groff package with `CXXFLAGS="-O3 -fno-exceptions"'. Dave -- J. David Anglin dave.anglin@nrc.ca National Research Council of Canada (613) 990-0752 (FAX: 952-6605) From delyra@latt.if.usp.br Wed, 29 Nov 2000 20:22:47 -0200 (BRST) Date: Wed, 29 Nov 2000 20:22:47 -0200 (BRST) From: Jorge L. deLyra delyra@latt.if.usp.br Subject: [parisc-linux] HP 9000/735-125 I just booted the palinux-0.5.iso CD on a HP 9000 model 735 workstation. It went on quite a bit before hanging immediatelly after reporting the serial ports. Gave large amount of what looks like traceback or state information. Question: would it do anyone any good if I tried to get everything the kernel said before the hang into a message in this list? Cheers, ---------------------------------------------------------------- Jorge L. deLyra, Associate Professor of Physics The University of Sao Paulo, IFUSP-DFMA For more information: finger delyra@latt.if.usp.br ---------------------------------------------------------------- From grundler@cup.hp.com Wed, 29 Nov 2000 15:19:10 -0800 Date: Wed, 29 Nov 2000 15:19:10 -0800 From: Grant Grundler grundler@cup.hp.com Subject: [parisc-linux] HP 9000/735-125 "Jorge L. deLyra" wrote: > I just booted the palinux-0.5.iso CD on a HP 9000 model 735 workstation. > It went on quite a bit before hanging immediatelly after reporting the > serial ports. Gave large amount of what looks like traceback or state > information. Question: would it do anyone any good if I tried to get > everything the kernel said before the hang into a message in this list? Certainly. I won't be able to debug the problems since I (a) don't have the time too (unless it's obvious) and (b) don't have a 735 setup for testing. This is becoming a FAQ: "My system crashed after ... What should I do next?" I'm thinking people in the support space would know how to write this one really well :^) Is I get one in the mail, I'll add it to our FAQ. thanks, grant Grant Grundler Unix Systems Enablement Lab +1.408.447.7253 From smoret@uci.edu Wed, 29 Nov 2000 15:28:20 -0800 Date: Wed, 29 Nov 2000 15:28:20 -0800 From: Steve Moret smoret@uci.edu Subject: [parisc-linux] HP 9000/735-125 Jorge, I have a 735-125 and am able to net-boot it on a custom configured kernel as long as I disable the ASP parallel ports. It works quite well using an NFS root as I cannot get the SCSI hard drives to mkfs. I was going to try and debug it but have yet to find the free time. I can e-mail you my working .config for the kernel, or build kernels (tested on my own 735) for people if they need them. -- Steve Moret smoret@uci.edu > -----Original Message----- > From: Grant Grundler [mailto:grundler@cup.hp.com] > Sent: Wednesday, November 29, 2000 3:19 PM > To: Jorge L. deLyra > Cc: parisc-linux@thepuffingroup.com > Subject: Re: [parisc-linux] HP 9000/735-125 > > > "Jorge L. deLyra" wrote: > > I just booted the palinux-0.5.iso CD on a HP 9000 model 735 workstation. > > It went on quite a bit before hanging immediatelly after reporting the > > serial ports. Gave large amount of what looks like traceback or state > > information. Question: would it do anyone any good if I tried to get > > everything the kernel said before the hang into a message in this list? > > Certainly. I won't be able to debug the problems since I (a) don't have > the time too (unless it's obvious) and (b) don't have a 735 setup > for testing. > > This is becoming a FAQ: > "My system crashed after ... What should I do next?" > > I'm thinking people in the support space would know how to write > this one really well :^) > Is I get one in the mail, I'll add it to our FAQ. > > thanks, > grant > > > Grant Grundler > Unix Systems Enablement Lab > +1.408.447.7253 > > ------------------------------------------------------------------ > --------- > To unsubscribe: send e-mail to > parisc-linux-request@thepuffingroup.com with > `unsubscribe' as the subject. > > From deller@gmx.de Thu, 30 Nov 2000 01:10:51 +0100 Date: Thu, 30 Nov 2000 01:10:51 +0100 From: Helge Deller deller@gmx.de Subject: [parisc-linux] HP 9000/735-125 X On Thursday 30 November 2000 00:28, Steve Moret wrote: > I have a 735-125 and am able to net-boot it on a custom configured kernel > as long as I disable the ASP parallel ports. .... Steve, I really would like to get the parallel-port problems on ASP get fixed as soon as possible. Could you please mail me your bootlog (with parport enabled), so I can try to track down the problem. Maybe you can also check out CVS again, and test if this version works for you ? Thanks, Helge Deller From alan@lxorguk.ukuu.org.uk Thu, 30 Nov 2000 02:38:56 +0000 (GMT) Date: Thu, 30 Nov 2000 02:38:56 +0000 (GMT) From: Alan Cox alan@lxorguk.ukuu.org.uk Subject: [parisc-linux] XFree status I have a server linked. inb/inw/outb/outw and friends are right now null functions until I fill them in. Thats not a big deal. Initially I'll probably use /dev/port but for speed I hope everyone uses mmio based hardware. Also is this bad ? /usr/bin/ld: lbxdix.o(.text+0x6fc): fixing R_PARISC_DPREL21L /usr/bin/ld: lbxprop.o(.text+0xde4): fixing R_PARISC_DPREL21L /usr/bin/ld: lbxprop.o(.text+0xdf4): fixing R_PARISC_DPREL21L Alan phux:/usr/src/redhat/BUILD/XFree86-4.0.1/xc/programs/Xserver# ./XFree86 XFree86 Version 4.0.1a / X Window System (protocol Version 11, revision 0, vendor release 6400) Release Date: 2 August 2000 If the server is older than 6-12 months, or if your card is newer than the above date, look for a newer version before reporting problems. (see http://www.XFree86.Org/FAQ) Operating System: Linux 2.4.0-test6 parisc [ELF] (==) Log file: "/var/log/XFree86.0.log", Time: Wed Nov 29 19:40:16 2000 (==) Using config file: "/etc/X11/XF86Config" Parse warning on line 77 of section Keyboard in file /etc/X11/XF86Config Ignoring obsolete keyword "LeftAlt". Parse error on line 77 of section Keyboard in file /etc/X11/XF86Config "Meta" is not a valid keyword in this section. (EE) Problem parsing the config file (EE) Error from xf86HandleConfigFile() Fatal server error: no screens found When reporting a problem related to a server crash, please send the full server output, not just the last messages. This can be found in the log file "/var/log/XFree86.0.log". Please reports problems to xfree86@xfree86.org. From alan@linuxcare.com.au Thu, 30 Nov 2000 14:41:48 +1100 (EST) Date: Thu, 30 Nov 2000 14:41:48 +1100 (EST) From: Alan Modra alan@linuxcare.com.au Subject: [parisc-linux] XFree status On Thu, 30 Nov 2000, Alan Cox wrote: > Also is this bad ? > > /usr/bin/ld: lbxdix.o(.text+0x6fc): fixing R_PARISC_DPREL21L No. It's a symptom of a variable's "constness" being declared differently from the way the variable is defined. For instance, referring to "extern int foo" in one object with foo defined as "const int foo" in another. I'll be removing the linker warning at some stage. Alan Modra -- Linuxcare. Support for the Revolution. From grundler@cup.hp.com Wed, 29 Nov 2000 21:18:14 -0800 Date: Wed, 29 Nov 2000 21:18:14 -0800 From: Grant Grundler grundler@cup.hp.com Subject: [parisc-linux] XFree status Alan Cox wrote: > I have a server linked. Alan - that's Cool! Wow! > inb/inw/outb/outw and friends are right now null > functions until I fill them in. Thats not a big deal. Initially I'll probably > use /dev/port but for speed I hope everyone uses mmio based hardware. All HP graphics for PARISC are memory mapped. Both "GSC" and PCI flavors. But I'm pretty clueless how linux X server finds/talks to a frame buffer. For HPUX, the graphics driver supports some ioctl()'s. Any references to describe how it works for linux? parisc-linux doesn't create kernel virtual addresses for MMIO. Which interface is used to create user virtual addresses for MMIO? (In general - not just for frame buffers) Is the PCI address passed to user space? I'm wondering if/how "bus_to_virt()" type translations take place. sorry for the many questions... grant Grant Grundler Unix Systems Enablement Lab +1.408.447.7253 From gibreel@pobox.com 30 Nov 2000 00:09:03 -0800 Date: 30 Nov 2000 00:09:03 -0800 From: Stephen Zander gibreel@pobox.com Subject: [parisc-linux] CVS linux Vs. -test10 >>>>> "Grant" == Grant Grundler writes: Grant> For the record, the second issue bdale made clear was we Grant> need "boot floppies" debian package working. We don't need Grant> more ISO images (no offense to pjlahaie for his good Grant> work). "Boot floppies" is a pre-requisite to becoming part Grant> of the next debian release. Given I still don't have a clue Grant> how to build a debian package and I can still contribute Grant> alot in other areas, it doesn't make sense for me to do it Grant> myself. Oooh, there's a reason for me to finally get the 712/80 under my desk to be more than a foot-rest. I'll see what I can do about this. Note that the likelihood of Debian releasing woody anytime soon is vanishingly small, so this dosen't have to happen Right Now. -- Stephen (debian developer) "Strange women lying in ponds distributing swords is no basis for a system of government" From smoret@uci.edu Thu, 30 Nov 2000 01:20:28 -0800 Date: Thu, 30 Nov 2000 01:20:28 -0800 From: Steve Moret smoret@uci.edu Subject: [parisc-linux] HP 9000/735-125 Helge, My mistake! I did a full build with todays CVS and parport didn't die. So somewhere between the 17th and now parport must have been fixed. Now, maybe you can help me identify my SCSI problem. I don't know if it is because of driver issues or a bad disk (completly likely). Do other people have the Fast SCSI2 working on their 735s? Whenever I do a mke2fs (after partitioning the drive with fdisk ok) it dies. At bootup I get: SCSI subsystem driver Revision: 1.00 sim700: Couldn't get consistent shared memory sim700: Configuring 53c700 (SCSI-ID 7) at f0825100, IRQ 86 scsi0: Revision 0x0 Post test1, istat 05, sstat0 00, dstat 84 sim700: WARNING IRQ probe failed, (returned 0) scsi0: WARNING: target data areas are not dma coherent! scsi0: test 1 completed ok. scsi0: sim700_intr_handle() called with no interrupt scsi0 : LASI/Simple 53c7xx Vendor: HP Model: C2235 Rev: 0B11 Type: Direct-Access ANSI SCSI revision: 02 Vendor: HP Model: C2235 Rev: 0B11 Type: Direct-Access ANSI SCSI revision: 02 Detected scsi disk sda at scsi0, channel 0, id 5, lun 0 Detected scsi disk sdb at scsi0, channel 0, id 6, lun 0 SCSI device sda: 825012 512-byte hdwr sectors (422 MB) Partition check: sda: sda1 sda2 SCSI device sdb: 825012 512-byte hdwr sectors (422 MB) sdb: sdb1 sdb2 And then if I try to mke2fs the disk I get: hp735:~# fdisk -l /dev/sda Disk /dev/sda: 13 heads, 62 sectors, 1023 cylinders Units = cylinders of 806 * 512 bytes Device Boot Start End Blocks Id System /dev/sda1 1 910 366699 83 Linux /dev/sda2 911 1023 45539 82 Linux swap hp735:~# mke2fs /dev/sda1 mke2fs 1.19, 13-Jul-2000 for EXT2 FS 0.5b, 95/08/09 Filesystem label= OS type: Linux Block size=1024 (log=0) Fragment size=1024 (log=0) 91800 inodes, 366699 blocks 18334 blocks (5.00%) reserved for the super user First data block=1 45 block groups 8192 blocks per group, 8192 fragments per group 2040 inodes per group Superblock backups stored on blocks: 8193, 24577, 40961, 57345, 73729, 204801, 221185 Writing inode tables: done Writing superblocks and filesystem accounting information: scsi0: Unable to abort command for target 5 scsi0: Unable to send Bus Device Reset for target 5 scsi0: Unable to do SCSI bus reset scsi0: >>>>>>>>>>>> Host reset <<<<<<<<<<<< scsi0: istat = 0c, sstat0 = 00, sstat1 = 00, dstat = 00 scsi0: dsp = 0cf15038 (script[0x140e]), dsps = 0cf15cde, target = 0 scsi0: Failing command for ID5 scsi0: sim700_intr_handle() called with no interrupt pa11_dma_map_single(PCI_DMA_NONE) called by c01cb6d4 kernel BUG at pci-dma.c:392! pa11_dma_unmap_single(PCI_DMA_NONE) called by c01ca3bc kernel BUG at pci-dma.c:403! SCSI disk error : host 0 channel 0 id 5 lun 0 return code = 2 I/O error: dev 08:01, sector 268 I/O error: dev 08:01, sector 270 I/O error: dev 08:01, sector 396 I/O error: dev 08:01, sector 16396 I/O error: dev 08:01, sector 16524 I/O error: dev 08:01, sector 16652 Of course the I/O errors continue on for a long time. Are these bad drives? Or is there a problem with the driver that still needs to be worked out? Thanks for all your help, I hope my spews of debug output are helpful, -- Steve Moret smoret@uci.edu > -----Original Message----- > From: Helge Deller [mailto:deller@gmx.de] > Sent: Wednesday, November 29, 2000 4:11 PM > To: Steve Moret > Cc: parisc-linux@thepuffingroup.com > Subject: Re: [parisc-linux] HP 9000/735-125 > > I really would like to get the parallel-port problems on ASP get fixed as > soon as possible. > Could you please mail me your bootlog (with parport enabled), so > I can try to > track down the problem. > Maybe you can also check out CVS again, and test if this version > works for > you ? From delyra@latt.if.usp.br Thu, 30 Nov 2000 08:58:22 -0200 (BRST) Date: Thu, 30 Nov 2000 08:58:22 -0200 (BRST) From: Jorge L. deLyra delyra@latt.if.usp.br Subject: [parisc-linux] HP 9000/735-125 > > information. Question: would it do anyone any good if I tried to get > > everything the kernel said before the hang into a message in this list? > > Certainly. I won't be able to debug the problems since I (a) don't have > the time too (unless it's obvious) and (b) don't have a 735 setup > for testing. OK, here goes. I want to congratulate you all on this effort. We have five of these HP-9000 stations here, quite old by now. They used to be our main number crunching force. They are wonderfully built hardware in bad need of a wonderful system on them! |:-) ---------------------------------------------------------------- Jorge L. deLyra, Associate Professor of Physics The University of Sao Paulo, IFUSP-DFMA For more information: finger delyra@latt.if.usp.br ---------------------------------------------------------------- Seyon Copyright (c) 1992-1993 Muhammad M. Saggaf. All rights reserved. Version 2 rev. 20c i586-Linux steve@hammer 05/23/99 20:19:22. Locating Modems... Modem `/dev/ttyS0' is Available. (c) Copyright. Hewlett-Packard Company. 1992. All rights reserved. PDC ROM rev. 2.7 IODC ROM rev. 1.1 80 MB of memory configured and tested. Searching for Potential Boot Devices. To terminate search, press and hold the ESCAPE key. Device Selection Device Path Device Type ---------------------------------------------------------------------------- P0 scsi.6.0 HP C3725S P1 scsi.4.0 TOSHIBA CD-ROM XM-3301TA b) Boot from specified device s) Search for bootable devices a) Enter Boot Administration mode x) Exit and continue boot sequence ?) Help Select from menu: b p1 Trying scsi.4.0 Boot path initialized. Attempting to load IPL. Soft booted. palo ipl bame@noam Tue Oct 31 14:18:02 MST 2000 0/vmlinux 2140145 bytes @ 0x6f9800 0/palo-cmdline '0/vmlinux ROOT=/ TERM=LINUX root=/dev/scd0' Kernel: partition 0 file /vmlinux ELF32 executable Entry 00100150 first 00100000 n 4 Segment 0 load 00100000 size 1460344 mediaptr 0x1000 Segment 1 load 00266000 size 179048 mediaptr 0x166000 Segment 2 load 00294000 size 109876 mediaptr 0x192000 Segment 3 load 002b0000 size 8192 mediaptr 0x1ad000 branching to kernel entry point 0x00100150 PDC Console Initialized The 32-bit Kernel has started... Enabled FP coprocessor Free memory starts at: 0xc02da000 (0x504d6c,0x504d6c,0x0,0x0) PALO command line: 'ROOT=/ TERM=LINUX root=/dev/scd0' PALO initrd 0-0 model 00002060 00000481 00000000 00000000 77f451b0 ffffffff 00000004 0000000a 0000000a vers 00000015 CPUID vers 0 rev 0 Searching for devices in PDC firmware... processor hpa 0xfffbe000 an older box... Found devices: 1. Outfield Core BA (11) at 0xf082f000, versions 0x9, 0x0, 0x70, 0x0, 0x0 2. Outfield Core SCSI (10) at 0xf0825000, versions 0x9, 0x0, 0x71, 0x0, 0x0 3. Outfield Core LAN (802.3) (10) at 0xf0826000, versions 0x9, 0x0, 0x72, 0x0, 0x0 4. Outfield Core HIL (10) at 0xf0821000, versions 0x9, 0x0, 0x73, 0x0, 0x0 5. Outfield Core RS-232 (10) at 0xf0823000, versions 0x9, 0x0, 0x75, 0x0, 0x0 6. Outfield Core RS-232 (10) at 0xf0822000, versions 0x9, 0x0, 0x75, 0x0, 0x0 7. Outfield Core Centronics (10) at 0xf0824000, versions 0x9, 0x0, 0x74, 0x0, 0x0 8. Outfield FW SCSI (10) at 0xf0830000, versions 0x9, 0x0, 0x7c, 0x0, 0x0 9. Outfield Audio (10) at 0xf1000000, versions 0x9, 0x0, 0x7f, 0x0, 0x0 10. Cobra EISA BA (11) at 0xfc000000, versions 0x4, 0x0, 0x76, 0x0, 0x0 11. Snake Cheetah (735/130) (0) at 0xfffbe000, versions 0x206, 0x0, 0x4, 0x0, 0x81 12. Snake Cheetah (1) at 0xfffbf000, versions 0x37, 0x0, 0x9, 0x0, 0x0 That's a total of 12 devices. CPU(s): 1 x PA7100 (PCX-T) at 125.000000 MHz Linux version 2.4.0-test6 (pjlahaie@elenuial.thepuffingroup.com) (gcc version 2.96 20000925 (experimental)) #32 Mon Nov 6 10:20:58 EST 2000 free_bootmem(0x2daa00, 0x4d25600) initrd: 00000000-00000000 pagetable_init On node 0 totalpages: 20480 zone(0): 10240 pages. zone(1): 10240 pages. zone(2): 0 pages. Kernel command line: ROOT=/ TERM=LINUX root=/dev/scd0 trap_init Calibrating delay loop... 124.52 BogoMIPS Memory: 77468k available Dentry-cache hash table entries: 16384 (order: 5, 131072 bytes) Buffer-cache hash table entries: 4096 (order: 2, 16384 bytes) Page-cache hash table entries: 32768 (order: 5, 131072 bytes) Inode-cache hash table entries: 8192 (order: 4, 65536 bytes) POSIX conformance testing by UNIFIX ASP version 20 at 0xf0800000 found. Found i82596 at 0xf0826000, IRQ 87 early initialization of device eth0 is deferred Found HIL at 0xf0821000, IRQ 94 HIL: no keyboard present. Warning : device (10, 0x9, 0x0, 0x73, 0x0) NOT claimed by HIL 712, 715 or similiar Linux NET4.0 for Linux 2.4 Based upon Swansea University Computer Society NET3.039 NET4: Unix domain sockets 1.0/SMP for Linux NET4.0. NET4: Linux TCP/IP 1.0 for NET4.0 IP Protocols: ICMP, UDP, TCP IP: routing cache hash table of 512 buckets, 4Kbytes TCP: Hash tables configured (established 8192 bind 8192) Starting kswapd v1.7 pty: 256 Unix98 ptys configured lp: driver loaded but no devices found RAMDISK driver initialized: 16 RAM disks of 4096K size 1024 blocksize sim700: Couldn't get consistent shared memory sim700: Configuring 53c700 (SCSI-ID 7) at f0825100, IRQ 86 scsi0: Revision 0x0 Post test1, istat 05, sstat0 00, dstat 84 sim700: WARNING IRQ probe failed, (returned 0) scsi0: WARNING: target data areas are not dma coherent! scsi0: test 1 completed ok. scsi0: sim700_intr_handle() called with no interrupt scsi0 : LASI/Simple 53c7xx scsi : 1 host. Vendor: TOSHIBA Model: CD-ROM XM-3301TA Rev: 1651 Type: CD-ROM ANSI SCSI revision: 02 Detected scsi CD-ROM sr0 at scsi0, channel 0, id 4, lun 0 Vendor: HP Model: C3725S Rev: 6019 Type: Direct-Access ANSI SCSI revision: 02 Detected scsi disk sda at scsi0, channel 0, id 6, lun 0 scsi : detected 1 SCSI cdrom 1 SCSI disk total. Uniform CD-ROM driver Revision: 3.11 SCSI device sda: hdwr sector= 512 bytes. Sectors= 4194058 [2047 MB] [2.0 GB] Partition check: sda: unknown partition table 82596.c: MAC of HP700 LAN blindely read from the prom! eth0: Couldn't get consistent shared memory eth0: 82596 at 0xf0826000, 08 00 09 0B DB EB IRQ 87. 82596.c $Revision: 1.14 $ Serial driver version 5.01 (2000-05-29) with MANY_PORTS SHARE_IRQ SERIAL_PCI enabled Dumping Stack from c4f9c000 to c4f9cbc0: c000 00000000 00000140 00000000 00000000 c027a46c 00000001 00000000 ffffffff c020 00000000 00000000 00000000 00000000 00000000 00000000 ffffffff c027a384 c040 c027a384 c4f90000 c02b0000 c028060c 00000000 00000000 00000000 00000000 c060 00000000 00000000 00000001 00000000 00000000 00000000 00000000 c02b0000 c080 c02b0000 c4f50000 00000000 00000000 00000000 c02c9ab8 00000000 c4f9c09c c0a0 c4f9c09c c4f9c0a4 c011a6e4 c4f9cac8 00000000 00000000 00000000 00000000 c0c0 00000000 00000000 00000000 00000000 00000000 00000000 c4f9c000 c011d4a8 c0e0 00000000 00000037 00000000 00000000 00000024 00000000 0000005b 00000000 c100 00000000 00000000 00000000 00000000 00000000 80000000 00000000 00000000 c120 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 c140 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 c160 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 c180 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 c1a0 00000000 00000000 00000000 00000000 00000000 00000000 00000000 fffffeff c1c0 00000000 ffffffff 00000000 c027afb4 ffffffff ffffffff ffffffff ffffffff c1e0 ffffffff ffffffff 00800000 05000000 00000000 ffffffff ffffffff ffffffff c200 00000500 00000500 00000400 00000400 ffffffff ffffffff ffffffff ffffffff c220 00007377 61707065 72000000 00000000 00000000 00000000 00000000 00000000 c240 00000000 00000000 00005000 c0267054 c0267054 c013d1e8 00010000 c4ffeba0 c260 c02238c4 c0236708 c02d9800 00504d6c 00000000 c011bb88 c0267000 00005000 c280 c0267054 c0267000 0000003e c027a000 00000001 c02b61eb 00000004 c02b61c7 c2a0 00000023 c02b61eb 00000000 00000000 c0100290 0000003e 00000000 00000024 c2c0 0000000b c027a4ac c027a000 08000059 00000000 000000ff 00000060 00000000 c2e0 00000060 00000002 002b2080 00000008 002b50c0 c0266000 00000000 023c3460 c300 c02b08c0 00000001 08000000 00000000 00000000 00000000 00856606 00000000 c320 00000000 00000000 42780000 00000000 431c0000 00000000 4471cccc 00000000 c340 000003c7 00000000 fffffde0 fffffde0 7f7fffff ffffffff 7f7fffff ffffffff c360 00000000 00000000 00000000 00000000 41800000 00000000 00000010 00000010 c380 00000000 00000000 fffffde0 fffffde0 41000000 00000000 40800000 00000000 c3a0 fffffde0 fffffde0 41000000 00000000 fffffde0 fffffde0 40800000 00000000 c3c0 41000000 00000000 40300000 00000000 40200000 00000000 40200000 00000000 c3e0 41800000 fffffde0 40000000 00000000 40000000 00000000 40800000 00000000 c400 41000000 00000000 00000000 00000000 c4f9cb80 c0103cf4 00000000 00000000 c420 00000000 00000000 00000000 00000000 c011bb78 c011bb7c 40800000 00000000 c440 00281000 00000000 c0280040 c0280064 00000000 c0280204 00000000 00000000 c460 00000000 00000000 00000000 c4f9c468 00000000 00000000 00000000 00000000 c480 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 c4a0 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 c4c0 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 c4e0 00000000 00000000 00000000 c0103c48 00000000 00000000 00000000 00000000 c500 c4f9c000 c028060c 00000000 00000000 00000000 00000000 00000000 00000000 c520 00000000 00000000 00000000 c01002a4 00000000 00000000 00000000 00000000 c540 00000000 00000000 00000000 00000000 c02b06c0 c4f9c000 c028060c 00000000 c560 c02b0000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 c580 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 c5a0 00000000 00000000 00000000 c02950a4 00000000 00000000 00000000 00000000 c5c0 00000001 c0284000 00000000 00000000 00000002 c027a4a0 c027a4a0 c0258bbc c5e0 00000000 00000000 00000000 c0294fe8 00000000 00000000 00000000 00000000 c600 00000000 08000059 00000000 00000000 f00012a0 000ff000 000a5a59 000a5a59 c620 c0295794 c02d9800 00504d6c c02cc000 c0266000 c02c8000 c02aed34 c02aed24 c640 c02aed34 c02aed20 00000000 00000000 000ff000 000a5a59 000a5a59 c0295794 c660 c02d9800 00504d6c c02cc000 c029bc3c c02c8000 c02aed34 c02aed04 c02c8000 c680 c02c5fe8 c02c60a4 c028758c 00000040 c0244ed8 c0244a0c c0244b80 c0244edc c6a0 01234567 c4f9c000 00000000 c02a6e64 c4f9c698 00000000 c02cc000 c0266000 c6c0 10000080 c02c5fe8 c02c60a4 c028758c 00000040 c4ffeea0 f00012a0 000ff000 c6e0 000a5a59 000a5a59 c0295794 c0155890 00504d6c c02cc000 c0266000 c02c8000 c700 c02c6164 00000100 c0244c38 00000000 c0245000 00000000 c02c5fe8 c02c5fe8 c720 c01e55ec c028be04 c02c9a20 c0109e74 c4ffc200 c028b474 c4f4a000 c028bf60 c740 00000004 c02aeab4 c02c8d20 c02b621f 00000004 c02b61ca 00000054 c02b621f c760 00000000 00000001 c027a000 c02a6de4 0000003c 00000058 0000000b c027a4ac c780 0000005a c4ff74a0 00000000 000000ff 00000060 00000000 00000060 00000002 c7a0 002b2080 00000008 002b50c0 c019324c 00000000 023c3460 c4f9c980 00000001 c7c0 08000000 00000000 00005301 f0823800 00856606 00000000 00000000 c028478c c7e0 42780000 00000000 431c0000 00000000 4471cccc 00000000 000003c7 00000000 c800 fffffde0 fffffde0 7f7fffff ffffffff 7f7fffff ffffffff 00000000 00000000 c820 00000000 00000000 41800000 00000000 00000010 00000010 f0823800 00000000 c840 00000003 fffffde0 41000000 00000000 40800000 00000000 fffffde0 fffffde0 c860 41000000 00000000 fffffde0 fffffde0 40800000 00000000 41000000 00000000 c880 40300000 00000000 40200000 00000000 40200000 00000000 c018ffb8 c02846d8 c8a0 c02c8800 c026c000 c02c8d20 0000000b c028478c 00000000 41000000 00000000 c8c0 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 c8e0 00000000 00000000 c011bb78 c0192bd4 4471cccc 00000000 000003c7 00000000 c900 0000000a c028478c c4f9c7c8 00000090 00000006 2b6a0000 00000000 00000000 c920 00000000 00000000 41800000 00000000 00000010 00000010 00000000 00000000 c940 fffffde0 fffffde0 41000000 00000000 40800000 00000000 fffffde0 fffffde0 c960 41000000 00000000 fffffde0 c011e9bc 40800000 00000000 41000000 00000000 c980 0004000a c0221800 c011e9f8 c4ff6520 c4ff6200 c0244f10 00000008 f0823800 c9a0 00000003 00000007 c0191568 c02c60a4 fffffffc c0245000 c0245000 c02d72b8 c9c0 c0245000 c0245000 c02c6028 00000000 c4ff6234 f0823807 f0823800 0000000a c9e0 ffffffff c4ff6520 c4ff6200 c0266000 ffffffff 00000340 c4f9cbc0 c012dfc0 ca00 08000000 00000000 00000000 00000000 00856606 00000000 00000000 00000000 ca20 42780000 00000000 431c0000 00000000 4471cccc 00000000 000003c7 00000000 ca40 fffffde0 fffffde0 7f7fffff ffffffff 7f7fffff ffffffff 00000000 00000000 ca60 00000000 00000000 41800000 00000000 00000010 00000010 00000000 00000000 ca80 fffffde0 fffffde0 41000000 00000000 40800000 00000000 fffffde0 fffffde0 caa0 41000000 00000000 fffffde0 fffffde0 40800000 00000000 41000000 00000000 cac0 40300000 00000000 40200000 00000000 40200000 00000000 41800000 fffffde0 cae0 40000000 00000000 40000000 00000000 40800000 00000000 41000000 00000000 cb00 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 cb20 00000000 00000000 c011e710 c011e714 00000000 00000000 00000000 00000000 cb40 00000000 00000058 c4f9c740 c02caac8 00000007 0f881093 00000000 00000003 cb60 c02c9800 c02c9a60 c02c9a20 00000000 00000000 00000400 c4f9cd40 c01d1c98 cb80 0000003c 0000003e c027a000 00000001 c02b61e0 00000004 c02b61c7 00000018 cba0 c02b61e0 00000000 431c0000 c01046e0 4471cccc 00000000 000003c7 00000000 Data access rights fault in kernel: Code=26 regs=c4f9c980 (Addr=00000003) YZrvWESTHLNXBCVMcbcbcbcbOGFRQPDI PSW: 00000000000001000000000000001010 r0-3 00000000 c0221800 c011e9f8 c4ff6520 r4-7 c4ff6200 c0244f10 00000008 f0823800 r8-11 00000003 00000007 c0191568 c02c60a4 r12-15 fffffffc c0245000 c0245000 c02d72b8 r16-19 c0245000 c0245000 c02c6028 00000000 r20-23 c4ff6234 f0823807 f0823800 0000000a r24-27 ffffffff c4ff6520 c4ff6200 c0266000 r28-31 ffffffff 00000340 c4f9cbc0 c012dfc0 sr0-4 00000000 00000000 00000000 00000000 sr4-8 00000000 00000000 00000000 00000000 IASQ: 00000000 00000000 IAOQ: c011e710 c011e714 IIR: 0f881093 ISR: 00000000 IOR: 00000003 ORIG_R28: 00000058 From delyra@latt.if.usp.br Thu, 30 Nov 2000 09:15:11 -0200 (BRST) Date: Thu, 30 Nov 2000 09:15:11 -0200 (BRST) From: Jorge L. deLyra delyra@latt.if.usp.br Subject: [parisc-linux] HP 9000/735-125 > I have a 735-125 and am able to net-boot it on a custom configured kernel as > long as I disable the ASP parallel ports. It works quite well using an NFS > root as I cannot get the SCSI hard drives to mkfs. I was going to try and > debug it but have yet to find the free time. I can e-mail you my working > .config for the kernel, or build kernels (tested on my own 735) for people > if they need them. Well, looks like the problem is known, good! But we have a queer little problem with our machines here, we are unable to boot from the network. I think we did everything right, in fact, we are trying to use a server here other machines boot from, it has dhcp, boopt, tftp, rarp, the works. We set it all up, put the kernel on the tftpboot area, tested all that we could by other means but, when we try to net boot the HPs, we are faced with complete silence on the network. No logs on the server, nothing. A little explanation might be needed: these are not really native 735-125 models, they were upgraded from older 720-50 models by card swapping. I am not sure whether all cards were changed, maybe some aspects of the machine are still old. The syntax of the net boot procedure in them is strange, you have to put in the hardware address of the server, which is unusual. I _suspect_ that this bios does not use tcp/ip for the net boot, but some HP proprietary protocol relating to that clustering software they have or used to have for these machines, in which you ran several stations out of the disks of a single one. In any case, a listing of what happens on the console on a net-boot trial goes below. We had a tail -f on the system log of the server, we had tcpdump listening, but nothing at all shows up... ---------------------------------------------------------------- Jorge L. deLyra, Associate Professor of Physics The University of Sao Paulo, IFUSP-DFMA For more information: finger delyra@latt.if.usp.br ---------------------------------------------------------------- Seyon Copyright (c) 1992-1993 Muhammad M. Saggaf. All rights reserved. Version 2 rev. 20c i586-Linux steve@hammer 05/23/99 20:19:22. Locating Modems... Modem `/dev/ttyS0' is Available. (c) Copyright. Hewlett-Packard Company. 1992. All rights reserved. PDC ROM rev. 2.7 IODC ROM rev. 1.1 80 MB of memory configured and tested. Searching for Potential Boot Devices. To terminate search, press and hold the ESCAPE key. Device Selection Device Path Device Type ---------------------------------------------------------------------------- P0 scsi.6.0 HP C3725S P1 scsi.4.0 TOSHIBA CD-ROM XM-3301TA b) Boot from specified device s) Search for bootable devices a) Enter Boot Administration mode x) Exit and continue boot sequence ?) Help Select from menu: a BOOT_ADMIN> help boot Boot from specified device or path: BOOT IPL boots Initial Program Loader (interactive mode) BOOT boots default boot utility may be one of the following: pri primary path in Stable Storage alt alternate path in Stable Storage Pn Device selection from SEARCH eisa. EISA adapter fwscsi. On-board FASTWIDE SCSI interface lan. Slider-card LAN interface scsi. On-board SCSI interface For more information on boot selection options, type HELP where = eisa, lan, scsi, etc ... BOOT_ADMIN> help lan LAN (IEEE 802.3/Ethernet LAN) Path Specification lan... 12 digit (hex) LAN server address max number of times to try a boot request (0 = default, 255 = infinite) max number of times to try a read request (0 = default, 255 = infinite) Example: to specify LAN address 123456-78ABCD with infinite initialization retries and default I/O retries, lan.123456-78ABCD.255.0 If one or more parameters are not specified, the following defaults will be used: = 000000-000000 = 3 tries = 6 tries BOOT_ADMIN> boot lan.0000f8-01abb1.0.0 Trying lan.0000f8-01abb1.0.0 Failed to initialize lan.0000f8-01abb1.3.0 ENTRY_INIT status = -7 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000008 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 A000800C F0002898 00000000 0800090B DBEB0000 00000000 Searching for Potential Boot Devices. To terminate search, press and hold the ESCAPE key. Device Selection Device Path Device Type ---------------------------------------------------------------------------- P0 scsi.6.0 HP C3725S P1 scsi.4.0 TOSHIBA CD-ROM XM-3301TA b) Boot from specified device s) Search for bootable devices a) Enter Boot Administration mode x) Exit and continue boot sequence ?) Help Select from menu: From rhirst@linuxcare.com Thu, 30 Nov 2000 11:19:30 +0000 Date: Thu, 30 Nov 2000 11:19:30 +0000 From: Richard Hirst rhirst@linuxcare.com Subject: [parisc-linux] HP 9000/735-125 On Thu, Nov 30, 2000 at 08:58:22AM -0200, Jorge L. deLyra wrote: > OK, here goes. I want to congratulate you all on this effort. We have five > of these HP-9000 stations here, quite old by now. They used to be our main > number crunching force. They are wonderfully built hardware in bad need of > a wonderful system on them! |:-) > Serial driver version 5.01 (2000-05-29) with MANY_PORTS SHARE_IRQ SERIAL_PCI enabled > > Dumping Stack from c4f9c000 to c4f9cbc0: This has been reported on 715/50 (Robert Duncan) and 715/75 (me) round about November 15th. At the time I tried a current cvs kernel on my 715/75 and it was even worse (IIRC). I'll have another look at it. Richard From rhirst@linuxcare.com Thu, 30 Nov 2000 11:27:39 +0000 Date: Thu, 30 Nov 2000 11:27:39 +0000 From: Richard Hirst rhirst@linuxcare.com Subject: [parisc-linux] HP 9000/735-125 On Thu, Nov 30, 2000 at 01:20:28AM -0800, Steve Moret wrote: > Now, maybe you can help me identify my SCSI problem. I don't know if it is > because of driver issues or a bad disk (completly likely). Do other people > have the Fast SCSI2 working on their 735s? > > Whenever I do a mke2fs (after partitioning the drive with fdisk ok) it dies. I have a 53c700 on my 715/75, and the driver was having trouble with a CRDOM I attached, so it has some problems. I wrote the driver, but havn't used the 715/75 for a while since latest kernels wouldn't boot for me. I'll get it going again and see if the scsi driver still works. Richard From deller@gmx.de Thu, 30 Nov 2000 13:04:49 +0100 (MET) Date: Thu, 30 Nov 2000 13:04:49 +0100 (MET) From: Helge Deller deller@gmx.de Subject: [parisc-linux] HP 9000/735-125 Hi Steve, > My mistake! I did a full build with todays CVS and parport didn't die. > So > somewhere between the 17th and now parport must have been fixed. I checked in yesterday a modified version of /drivers/parport/parport_gsc.c with an "#if 0 ... #endif" in the code. Could you try to boot again with "#if 1" (search for the text which says something like "enable bidirectional PS/2 mode") and try again ? If this hangs your machine I will implement a better work-around. > > Now, maybe you can help me identify my SCSI problem. I don't know if it > is > because of driver issues or a bad disk (completly likely). I think Richard Hirst can help you much more with your SCSI-problems than me. NB: Does your chassis LEDs work with the new kernel, and if not, could you send me your bootlog (or "dmesg | grep led") ? Greetings, Helge -- Sent through GMX FreeMail - http://www.gmx.net From rbradetich@uswest.net Thu, 30 Nov 2000 07:01:53 -0800 Date: Thu, 30 Nov 2000 07:01:53 -0800 From: Ryan Bradetich rbradetich@uswest.net Subject: [parisc-linux] HP 9000/735-125 "Jorge L. deLyra" wrote: > > I have a 735-125 and am able to net-boot it on a custom configured kernel as > > long as I disable the ASP parallel ports. It works quite well using an NFS > > root as I cannot get the SCSI hard drives to mkfs. I was going to try and > > debug it but have yet to find the free time. I can e-mail you my working > > .config for the kernel, or build kernels (tested on my own 735) for people > > if they need them. > > Well, looks like the problem is known, good! But we have a queer little > problem with our machines here, we are unable to boot from the network. I > think we did everything right, in fact, we are trying to use a server here > other machines boot from, it has dhcp, boopt, tftp, rarp, the works. We > set it all up, put the kernel on the tftpboot area, tested all that we > could by other means but, when we try to net boot the HPs, we are faced > with complete silence on the network. No logs on the server, nothing. > > A little explanation might be needed: these are not really native 735-125 > models, they were upgraded from older 720-50 models by card swapping. I am > not sure whether all cards were changed, maybe some aspects of the machine > are still old. The syntax of the net boot procedure in them is strange, > you have to put in the hardware address of the server, which is unusual. > > I _suspect_ that this bios does not use tcp/ip for the net boot, but some > HP proprietary protocol relating to that clustering software they have or > used to have for these machines, in which you ran several stations out of > the disks of a single one. In any case, a listing of what happens on the > console on a net-boot trial goes below. We had a tail -f on the system log > of the server, we had tcpdump listening, but nothing at all shows up... I believe the 735/755 type machines require rbootd to boot from the network. rbootd is available at: ftp://puffin.external.hp.com/pub/parisc/binaries/tgz/rbootd-2.0-2.tar.gz - Ryan From rhirst@linuxcare.com Thu, 30 Nov 2000 14:03:10 +0000 Date: Thu, 30 Nov 2000 14:03:10 +0000 From: Richard Hirst rhirst@linuxcare.com Subject: [parisc-linux] 715/75 dies in pdc_iodc_read() Hi, My 715/75 no longer boots with cvs kernel. It hangs while searching for devices in PDC firmware, after finding the first device. The beta 0.5 cd kernel gets past this point. The device list is: Searching for devices in PDC firmware... processor hpa 0xfffbe000 an older box... Found devices: 1. Stinger Optional Graphics (10) at 0xf4000000, versions 0x6, 0x0, 0x77, 0x0, 0x0 2. Scorpio Sr. Core BA (11) at 0xf082f000, versions 0x19, 0x0, 0x70, 0x0, 0x0 3. Scorpio Sr. Core SCSI (10) at 0xf0825000, versions 0x19, 0x0, 0x71, 0x0, 0x0 4. Scorpio Sr. Core LAN (802.3) (10) at 0xf0826000, versions 0x19, 0x0, 0x72, 0x0, 0x0 5. Scorpio Sr. Core HIL (10) at 0xf0821000, versions 0x19, 0x0, 0x73, 0x0, 0x0 6. Scorpio Sr. Core RS-232 (10) at 0xf0823000, versions 0x19, 0x0, 0x75, 0x0, 0x0 7. Scorpio Sr. Core RS-232 (10) at 0xf0822000, versions 0x19, 0x0, 0x75, 0x0, 0x0 8. Scorpio Sr. Core Centronics (10) at 0xf0824000, versions 0x19, 0x0, 0x74, 0x0, 0x0 9. Scorpio Sr. Audio (10) at 0xf1000000, versions 0x19, 0x0, 0x7b, 0x0, 0x0 10. Scorpio Sr. EISA BA (11) at 0xfc000000, versions 0x19, 0x0, 0x76, 0x0, 0x0 11. Unknown device (10) at 0xfc001000, versions 0x0, 0x0, 0xfff, 0x0, 0x0 12. Scorpio Sr.(715/75) (0) at 0xfffbe000, versions 0x316, 0x0, 0x4, 0x0, 0x81 13. Scorpio Sr. (1) at 0xfffbf000, versions 0x27, 0x0, 0x9, 0x0, 0x0 That's a total of 13 devices. CPU(s): 1 x PA7100 (PCX-T) at 75.000000 MHz So, with lastest cvs source, it gets in to the loop in really_do_oldhw_inventory(), and first time through pdc_mem_map_hpa() returns r_addr.hpa=0xf4000000 (the Stinger Optional Graphics). Next time round, mod=1, pdc_mem_map_hpa() returns r_addr.hpa=0xf8000000, and the subsequent call to pdc_iodc_read() hangs. I made the code skip the loop where mod=1, and it then goes on to discover all the devices without problems. At power on, the machine reports: Warning: one or more EISA cards could not be configured. Autoselect and search will ignore unconfigured cards. Which I assume relates to an EISA SCSI card in the machine, which I assume is item 11 in the above list. Richard From delyra@latt.if.usp.br Thu, 30 Nov 2000 13:04:46 -0200 (BRST) Date: Thu, 30 Nov 2000 13:04:46 -0200 (BRST) From: Jorge L. deLyra delyra@latt.if.usp.br Subject: [parisc-linux] HP 9000/735-125 > I believe the 735/755 type machines require rbootd to boot from the network. > rbootd is available at: > > ftp://puffin.external.hp.com/pub/parisc/binaries/tgz/rbootd-2.0-2.tar.gz Ah! This is it, then! Had never heard of this beast before. I see it is available for i386, nice, our server is a Pentium. Well, thanks a whole lot for the tip, we are certainly trying this. Well, back to work... ---------------------------------------------------------------- Jorge L. deLyra, Associate Professor of Physics The University of Sao Paulo, IFUSP-DFMA For more information: finger delyra@latt.if.usp.br ---------------------------------------------------------------- From delyra@latt.if.usp.br Thu, 30 Nov 2000 13:49:56 -0200 (BRST) Date: Thu, 30 Nov 2000 13:49:56 -0200 (BRST) From: Jorge L. deLyra delyra@latt.if.usp.br Subject: [parisc-linux] HP 9000/735-125 OK, rbootd is up and running, the station now establishes instantaneous communication with the server. But it says "bad LIF magic" and does not boot. I presume I can't just put the precompiled kernel in there. Since I cannot cross-compile for the time being (bad HP server disk crash) is there a net-boot kernel somewhere that I can download and try? Cheers, ---------------------------------------------------------------- Jorge L. deLyra, Associate Professor of Physics The University of Sao Paulo, IFUSP-DFMA For more information: finger delyra@latt.if.usp.br ---------------------------------------------------------------- From randolph@tausq.org Thu, 30 Nov 2000 08:44:18 -0700 Date: Thu, 30 Nov 2000 08:44:18 -0700 From: Randolph Chung randolph@tausq.org Subject: [parisc-linux] CVS linux Vs. -test10 > Oooh, there's a reason for me to finally get the 712/80 under my desk > to be more than a foot-rest. I'll see what I can do about this. > > Note that the likelihood of Debian releasing woody anytime soon is > vanishingly small, so this dosen't have to happen Right Now. So little faith... :P Let me know what I can do to help.... it takes my dual-400MHz i386 box about an hour to build boot-floopies; i don't even wait to think how long it will take on the 712/80 :-) randolph -- @..@ http://www.TauSq.org/ (----) ( >__< ) ^^ ~~ ^^ From rhirst@linuxcare.com Thu, 30 Nov 2000 16:11:15 +0000 Date: Thu, 30 Nov 2000 16:11:15 +0000 From: Richard Hirst rhirst@linuxcare.com Subject: [parisc-linux] HP 9000/735-125 On Thu, Nov 30, 2000 at 11:27:39AM +0000, Richard Hirst wrote: > On Thu, Nov 30, 2000 at 01:20:28AM -0800, Steve Moret wrote: > > Now, maybe you can help me identify my SCSI problem. I don't know if it is > > because of driver issues or a bad disk (completly likely). Do other people > > have the Fast SCSI2 working on their 735s? > > > > Whenever I do a mke2fs (after partitioning the drive with fdisk ok) it dies. > > > I have a 53c700 on my 715/75, and the driver was having trouble > with a CRDOM I attached, so it has some problems. I wrote the > driver, but havn't used the 715/75 for a while since latest kernels > wouldn't boot for me. I'll get it going again and see if the scsi > driver still works. I got my 715/75 to boot. The scsi driver still has problems with my CDROM drive, but the disk seems ok. I ran mke2fs of a 1Gig partition a few times and then copied 200MB of files from the network to it. Richard From bame@noam.fc.hp.com Thu, 30 Nov 2000 09:18:51 -0700 Date: Thu, 30 Nov 2000 09:18:51 -0700 From: Paul Bame bame@noam.fc.hp.com Subject: [parisc-linux] CVS linux Vs. -test10 = Grant> need "boot floppies" debian package working. We don't need = = Oooh, there's a reason for me to finally get the 712/80 under my desk = to be more than a foot-rest. I'll see what I can do about this. = = Note that the likelihood of Debian releasing woody anytime soon is = vanishingly small, so this dosen't have to happen Right Now. Well yes and no. We want to release parisc-linux sooner than woody will be ready for public stable release, so we'll want to do the boot floppies work sooner than other architectures need it and can probably therefore provide early testing too. Since we aren't going to time travel back to Debian potato, woody boot floppies are increasingly interesting to replace our manual install process (hey at least it's documented!). -P From alan@lxorguk.ukuu.org.uk Thu, 30 Nov 2000 16:10:46 +0000 (GMT) Date: Thu, 30 Nov 2000 16:10:46 +0000 (GMT) From: Alan Cox alan@lxorguk.ukuu.org.uk Subject: [parisc-linux] XFree status > Alan Cox wrote: > > I have a server linked. > Alan - that's Cool! Wow! Its still got its atoms in a twist, so its bombing out in Xnest loading the first font. > > inb/inw/outb/outw and friends are right now null > > functions until I fill them in. Thats not a big deal. Initially I'll probably > > use /dev/port but for speed I hope everyone uses mmio based hardware. > > All HP graphics for PARISC are memory mapped. Both "GSC" and PCI flavors. Yes, but if I want to say put an S3 Trio64 in my A180 and a USB card for keyboard mouse..,, (and yes these are sitting on my desk) > But I'm pretty clueless how linux X server finds/talks to a frame buffer. > For HPUX, the graphics driver supports some ioctl()'s. > Any references to describe how it works for linux? The OS specific X code in XFree86 knows several ways to talk to Linux Memory: 1. Directly mmap()ing /dev/mem or /dev/kmem to get access to the mmio space of the card and frame buffer memory. 2. Mapping the pci space via a kernel frame buffer device (/dev/fb*) 3. Arbitary other mmap based code that you plug into it (harder to do) I/O 1. Use of iopl/ioperm on x86 2. Use of mmap to map the PCI I/O space regions on different platforms (which doesnt work on some PA kit) 3. Arbitary other code we plug into it For I/O it seems that on things like the A180 the only way to do it is to use /dev/port and pread/pwrite the file handle for each port I/O. This is slow but hopefully primarily used for booting the card (XFree 4.0 has a X86 emulator for booting the BIOS firmware on PCI cards) For most machines I imagine we would be using mmio and the /dev/fb interface. Alan From alan@lxorguk.ukuu.org.uk Thu, 30 Nov 2000 16:16:18 +0000 (GMT) Date: Thu, 30 Nov 2000 16:16:18 +0000 (GMT) From: Alan Cox alan@lxorguk.ukuu.org.uk Subject: [parisc-linux] CVS linux Vs. -test10 > Oooh, there's a reason for me to finally get the 712/80 under my desk > to be more than a foot-rest. I'll see what I can do about this. > > Note that the likelihood of Debian releasing woody anytime soon is > vanishingly small, so this dosen't have to happen Right Now. My experiences with building Red Hat 7 so far are mostly good. I don't think there will be many actual changes needed to build Debian packages either. I've made very little that isnt 'use -fPIC' 'dont optimise C++' From marteaut@esiee.fr Thu, 16 Nov 2000 21:16:22 +0100 Date: Thu, 16 Nov 2000 21:16:22 +0100 From: Thomas Marteau marteaut@esiee.fr Subject: [parisc-linux] Troubles with read only file system Hi all, We have done everything well but the NFSroot and the bootable disk say that we have a read only file system ??? What is the recipe for making a bootable disk because ours can not be the good one... Thanks, Thomas From marteaut@esiee.fr Fri, 17 Nov 2000 17:59:14 +0100 Date: Fri, 17 Nov 2000 17:59:14 +0100 From: Thomas Marteau marteaut@esiee.fr Subject: [parisc-linux] Trouble with new STI This is a multi-part message in MIME format. ------=_NextPart_000_000F_01C050C0.18E3D060 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi all, We've tried the new STI driver and our 712 dies with this message: Kernel Panic: VFS: Unable to mount root fs on 01:00 We tried with Ramdisk, nfs and hard disk support and always the same = end. Also, the death happens when you 've passed bootp request... Help! Thomas ------=_NextPart_000_000F_01C050C0.18E3D060 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi all,
 
We've tried the new STI driver and our = 712 dies=20 with this message:
 
Kernel Panic: VFS: Unable to mount root = fs on=20 01:00
 
We tried with Ramdisk, nfs and hard = disk support=20 and always the same end.
Also, the death happens when you 've = passed bootp=20 request...
 
Help!
 
Thomas
------=_NextPart_000_000F_01C050C0.18E3D060-- From marteaut@esiee.fr Sun, 19 Nov 2000 13:08:45 +0100 Date: Sun, 19 Nov 2000 13:08:45 +0100 From: Thomas Marteau marteaut@esiee.fr Subject: [parisc-linux] Booting 712 STI and nfs This is a multi-part message in MIME format. ------=_NextPart_000_0047_01C05229.D8DA5D20 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi all, We managed to boot on the STI-console with a 712/80 in changing the = parameters in inittab and in securetty (if you want to login as root).=20 > cat inittab (! just the interesting thing!) # /sbin/getty invocations for the runlevels. # # The "id" field MUST be the same as the last # characters of the device (after "tty"). # # Format: # ::: 1:2345:respawn:/sbin/getty 38400 tty1 #2:23:respawn:/sbin/getty 38400 tty2 #3:23:respawn:/sbin/getty 38400 tty3 #4:23:respawn:/sbin/getty 38400 tty4 #5:23:respawn:/sbin/getty 38400 tty5 #6:23:respawn:/sbin/getty 38400 tty6 =20 > cat securetty # /etc/securetty: list of terminals on which root is allowed to login. # See securetty(5) and login(1). ttyS0 tty1 Also, in order to boot with the STI console, you need to have the module = for STI-console and not for serial console support... But, we have troubles with the rpc that print somestimes nfs: server X.X.X.165 not responding, still trying nfs: server X.X.X.165 OK nfs: server X.X.X.165 not responding, still trying nfs: server X.X.X.165 OK nfs: server X.X.X.165 not responding, still trying nfs: server X.X.X.165 OK We don't understand where comes from the problem!! Bye, ESIEE Port Team ------=_NextPart_000_0047_01C05229.D8DA5D20 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi all,
 
We managed to boot on the STI-console = with a 712/80=20 in changing the parameters in inittab and in securetty (if you want to = login as=20 root).
 
> cat inittab (! just the = interesting=20 thing!)
# /sbin/getty invocations for the=20 runlevels.
#
# The "id" field MUST be the same as the last
# = characters=20 of the device (after "tty").
#
# Format:
# =20 <id>:<runlevels>:<action>:<process>
1:2345:res= pawn:/sbin/getty=20 38400 tty1
#2:23:respawn:/sbin/getty 38400 = tty2
#3:23:respawn:/sbin/getty=20 38400 tty3
#4:23:respawn:/sbin/getty 38400 = tty4
#5:23:respawn:/sbin/getty=20 38400 tty5
#6:23:respawn:/sbin/getty 38400 tty6
 
 
 
> cat securetty
# /etc/securetty: list of terminals on = which root=20 is allowed to login.
# See securetty(5) and=20 login(1).
ttyS0
tty1
 
Also, in order to boot with the STI = console, you=20 need to have the module for STI-console and not for serial console=20 support...
 
But, we have troubles with the rpc that = print=20 somestimes
nfs: server X.X.X.165 not responding, = still=20 trying
nfs: server X.X.X.165 OK
nfs: server X.X.X.165 not responding, = still=20 trying
nfs: server X.X.X.165 OK
nfs: server X.X.X.165 not responding, = still=20 trying
nfs: server X.X.X.165 OK
We don't understand where comes from the problem!!
 
Bye,
ESIEE Port Team
------=_NextPart_000_0047_01C05229.D8DA5D20-- From marteaut@esiee.fr Mon, 20 Nov 2000 15:32:55 +0100 Date: Mon, 20 Nov 2000 15:32:55 +0100 From: Thomas Marteau marteaut@esiee.fr Subject: [parisc-linux] A new file system This is a multi-part message in MIME format. ------=_NextPart_000_0009_01C05307.27222700 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi all, Since we have the STI, we have produced a file system quite = interesting for the 712. You can have a network support till you configure the file.conf like resolv... = Also, we have noticed that the sti on B180 does not work well, it look like it can not find the = rom. But we have to work on... To download the archives go there: http://www.esiee.fr/~djoudim/code/suitable.html It is incredible what can do a 712 with it! Bye, ESIEE Port Team ------=_NextPart_000_0009_01C05307.27222700 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi all,
 
    Since we have the = STI, we have=20 produced a file system quite interesting for the 712. You = can
have a network support till you = configure the=20 file.conf like resolv... Also, we have noticed that
the sti on B180 does not work well, it = look like it=20 can not find the rom. But we have to work on...
 
To download the archives go = there:
http://www.esiee= .fr/~djoudim/code/suitable.html
 
It is incredible what can do a 712 with = it!
 
Bye,
ESIEE Port Team
------=_NextPart_000_0009_01C05307.27222700-- From kailasr@webcash.com Tue, 31 Oct 2000 12:58:41 -0800 Date: Tue, 31 Oct 2000 12:58:41 -0800 From: Kailashnath V Rampure kailasr@webcash.com Subject: [parisc-linux] unable to run palo on nfs root Hi Paul, After booting the Server from NFSroot I need to Initialize the harddisk on the server. so I copied the palo and linux in to the nfsroot. I am trying to Run the following command: $ palo -I -k /boot/vmlinux -b /boot/iplboot -c '2/boot/vmlinux TERM=linux HOME=/ root=/dev/sda2' /dev/sda fisrt partition is 10M of type f0 second partition is /dev/sda2 of type linux native. Third partition is /dev/sda3 of type linux Swap Then I get the cannot execute binary file. second question is that what is the Terminal type I should set as I am unable to open vi. Please suggest the correct steps. Thanks. Kailas At 09:54 AM 10/31/00 -0700, Paul Bame wrote: >= Hi, >= >= I have booted HP A class server from nfsroot. but when I try to run palo on >= the server to initialize boot loader to the hdd I get >= "cannot execute the binary file" >= >= can any one help me to make the hdd bootable > >It would help me to see the actual command you used and the actual >error message(s) printed. With the info you give so far it could be >"a million" things. > > -P From bame@noam.fc.hp.com Tue, 31 Oct 2000 14:26:00 -0700 Date: Tue, 31 Oct 2000 14:26:00 -0700 From: Paul Bame bame@noam.fc.hp.com Subject: [parisc-linux] NEW NATIVE PALO TARBALL - REQUIRED = Hi Paul, = = After booting the Server from NFSroot I need to Initialize the harddisk on = the server. so I copied the palo and linux in to the nfsroot. I am trying = to Run the following command: = $ palo -I -k /boot/vmlinux -b /boot/iplboot -c '2/boot/vmlinux TERM=linux = HOME=/ root=/dev/sda2' /dev/sda = fisrt partition is 10M of type f0 = second partition is /dev/sda2 of type linux native. = Third partition is /dev/sda3 of type linux Swap That looks great. = Then I get the cannot execute binary file. Ok I think we changed the kernal such that the old palo bits won't run any more (we removed the old gateway page). I uploaded a new version: ftp://puffin.external.hp.com/pub/parisc/binaries/userspace/palo-200001031.tgz -P From grundler@cup.hp.com Tue, 31 Oct 2000 13:53:04 -0800 Date: Tue, 31 Oct 2000 13:53:04 -0800 From: Grant Grundler grundler@cup.hp.com Subject: [parisc-linux] unable to run palo on nfs root Kailashnath V Rampure wrote: > fisrt partition is 10M of type f0 > second partition is /dev/sda2 of type linux native. > Third partition is /dev/sda3 of type linux Swap Kailashnath, Even though your partitioning should work fine, you really want the swap on the lowest numbered SCSI block you can get away with. Several reasons for this: o lowest block number is on the outside of the SCSI disk were data xfer rate is typically 80% faster than the inside. (someday try "time dd if=/dev/sda of=/dev/null bs=8k count=50" with and with out skip parameter). o Eventualy we will have kernel dumps to swap space - and IODC will likely have the same limitations where on the disk dump can be as we have with booting from a disk (as discussed in the PALO documentation). grant Grant Grundler Unix Systems Enablement Lab +1.408.447.7253 From taggart@carmen.fc.hp.com Tue, 31 Oct 2000 16:16:09 -0700 Date: Tue, 31 Oct 2000 16:16:09 -0700 From: Matt Taggart taggart@carmen.fc.hp.com Subject: [parisc-linux] New cross-compiler I have placed a new i386-linux -> hppa32/64-linux cross compiler (with 32bit glibc) in, ftp://puffin.external.hp.com/pub/parisc/binaries/LinuxX86/xc-20001031.tar.gz It includes Alan Modra's recent fix for the 64 bit compiler, http://puffin.external.hp.com/mailing-lists/parisc-linux-cvs/2000/10-Oct/0233.h tml -- Matt Taggart taggart@fc.hp.com From pdbeal@bealz.net Tue, 31 Oct 2000 18:43:06 -0500 Date: Tue, 31 Oct 2000 18:43:06 -0500 From: Phillip Beal pdbeal@bealz.net Subject: [parisc-linux] 735 and Thin Lan Hey, I've obtained two HP 735's and I'd like to try the linus port on them. I have compiled a kernel, but it never boots the nfsroot disk. It has the same problem that the HP 755 that I've worked with. However, it has a different ethernet connection. The 735 has a thin lan connection. What network device should be used in the kernel to be able to use the thin lan adapter? Here's the info on the Thin lan: Outfield Core LAN (802.3) (10) at 0xf0826000 versions 0x9, 0x0, 0x72, 0x0, 0x0 Thanks, -- Phillip Beal S+LUG Vice-President From deller@gmx.de Wed, 1 Nov 2000 00:57:22 +0100 Date: Wed, 1 Nov 2000 00:57:22 +0100 From: Helge Deller deller@gmx.de Subject: [parisc-linux] 735 and Thin Lan On Wednesday 01 November 2000 00:43, Phillip Beal wrote: > Hey, > > I've obtained two HP 735's and I'd like to try the linus port on them. > I have compiled a kernel, but it never boots the nfsroot disk. It has > the same problem that the HP 755 that I've worked with. However, it has > a different ethernet connection. The 735 has a thin lan connection. > What network device should be used in the kernel to be able to use the > thin lan adapter? Here's the info on the Thin lan: > > Outfield Core LAN (802.3) (10) at 0xf0826000 versions 0x9, 0x0, 0x72, > 0x0, 0x0 > > Thanks, > Phillip Beal > S+LUG Vice-President Hi Phillip, I think the "Lasi ethernet"-driver (enabled by default in our configuration) should work on both of your boxes. Helge. From deller@gmx.de Wed, 1 Nov 2000 01:45:52 +0100 Date: Wed, 1 Nov 2000 01:45:52 +0100 From: Helge Deller deller@gmx.de Subject: [parisc-linux] The new PS/2 Keyboard Driver On Friday 27 October 2000 01:50, Helge Deller wrote: > On Thursday 26 October 2000 22:05, Thomas Marteau wrote: > > > > > > Hello everyone, > > > > We've just updated the PS/2 keyboard driver. The leds and interrupt > > functions work really well on a 712 workstation and also B132 now. The > > updated driver files are available on our website. It works better than > > under HP UX for the B 132 ;-> > > > > http://www.esiee.fr/~djoudim > > > > The ESIEE Port Team in Paris. > > > > Here is the patch: > > > > diff -urN linux/drivers/char/gsc_ps2.c linux-parisc/drivers/char/gsc_ps2.c > > --- linux/drivers/char/gsc_ps2.c Thu Oct 26 21:06:54 2000 > > +++ linux-parisc/drivers/char/gsc_ps2.c Thu Oct 26 21:34:00 2000 > > @@ -7,6 +7,11 @@ > > [.............] > > > diff -urN linux/drivers/char/keyb_at.c linux-parisc/drivers/char/keyb_at.c > > --- linux/drivers/char/keyb_at.c Thu Oct 26 21:07:00 2000 > > +++ linux-parisc/drivers/char/keyb_at.c Thu Oct 26 21:23:16 2000 > > [........] > > Hi Thomas, > > Thanks for your patch. > But I don't think it's a good idea to change a common file like keyb_at.c, > which is used in most other arches too. This patch surely breaks their > keyboard support and more than that I'm sure, that Linus will not accept this > patch, when the time is come to integrate parisc into the official kernel. > > Isn't there any other solution as for example to #ifdef the code or create a > new keyb_at.c for parisc (Yes I know, both of those aren't clean too.) ? > > Helge Deller Hi folks, I need to correct myself on this topic. The ESIEE-team made a great patch and didn't changed any globally used file. keyb_at.c is just used in the current parisc-port, and so it's ok to change that file. I just committed their changes to the CVS, and in the same cycle tried to clean up the code. In the same step I renamed the original filenames to some hopefully better ones. Since I don't own myself a real HP PS/2 keyboard (it's just an PC-AT one with a small DIN to PS/2-connector), it would be great to get some feedback if I did the Right Thing. Helge. From bri@mojo.calyx.net Wed, 1 Nov 2000 02:48:02 -0500 (EST) Date: Wed, 1 Nov 2000 02:48:02 -0500 (EST) From: Brian S. Julin bri@mojo.calyx.net Subject: [parisc-linux] The new PS/2 Keyboard Driver Probably best not to worry about cleaning keyboard drivers up too much. The current USB code will be followed by linux-input style drivers at some point. In fact I started a HIL linux-input style driver, which would abstract the PS2 port/HIL ports and allow a standard keyboard module to be hooked into the abstracted serio port. I will work on it more when time permits. -- Brian S. Julin From jsm@udlkern.fc.hp.com Wed, 1 Nov 2000 02:37:58 -0700 (MST) Date: Wed, 1 Nov 2000 02:37:58 -0700 (MST) From: John Marvin jsm@udlkern.fc.hp.com Subject: Elf Header change proposal Paul and Alan pointed out that I goofed. I analyzed the vmlinux in my 64 bit build area to get the current flags, but it turns out that the vmlinux I looked at was a 32 bit version. I had recently made some 64 bit checkins, and I like to rebuild everything for 32 bit before doing that, to make sure that I haven't broken the 32 bit path by making 64 bit changes. So, the bad news is that I wasted time writing an unecessarily long design proposal. The good news is that the only thing that needs to change is value in the e_ident[EI_OSABI] field, so that we can differentiate 64 bit HP-UX binaries from 64 bit Linux binaries. We should also change the field for 32 bit Linux also. John From jsm@udlkern.fc.hp.com Wed, 1 Nov 2000 03:35:49 -0700 (MST) Date: Wed, 1 Nov 2000 03:35:49 -0700 (MST) From: John Marvin jsm@udlkern.fc.hp.com Subject: space registers Matthew Wilcox wrote: > a small optimisation just occurred to me. > > right now, when we switch to kernel space, we set all of sr4-sr7 to 0 > (for the kernel mapping). we don't need to do that since the kernel is > entirely in sr7's domain. this has the added bonus that badly written > drivers which blindly dereference userspace pointers will work on > parisc as well as x86. we can also lazily restore sr4-6 on exit from > kernel space if we're switching back to the same task which called us. > this optimisation may not be worthwhile, but i think setting sr4-6 > on entry to the kernel is unnecessary. True for now. But it won't always be true. It is a desired goal to be able to support large (~3.5 Gb) physical memory for the 32 bit port. To do this we will move the kernel down to around virtual address 0, so the kernel address space will then be controlled by sr4, and depending on the amount of physical memory in the machine, possibly sr5, sr6, and sr7. We could do this based on a test of the amount of physical memory in the machine, but once you load something from memory to do the test, and then actually do the test, you wouldn't have any advantage over just writing zero's to the space registers. This might be worth considering for the 64 bit port, since both the kernel and user space will reside entirely within the linear address space covered by sr4 (We would have to go to a 1 Mb page size to be able to support greater than a 62 bit address space with three level page tables). sr5,sr6, and sr7 will only be used when we are running 64 bit HP-UX processes (with its address space broken up into 4 segments). Note that since we just store the users space in sr3 while we are in the kernel, its not clear that any kind of test with a branch would be a performance gain, especially if it required that we load something from memory to do that test. We may be able cover this by managing sr5, sr6 and sr7 only in the HP-UX specific parts of the syscall path. John From alan@linuxcare.com.au Thu, 2 Nov 2000 00:11:11 +1100 (EST) Date: Thu, 2 Nov 2000 00:11:11 +1100 (EST) From: Alan Modra alan@linuxcare.com.au Subject: Elf Header change proposal On Wed, 1 Nov 2000, John Marvin wrote: > So, the bad news is that I wasted time writing an unecessarily long > design proposal. The good news is that the only thing that needs to > change is value in the e_ident[EI_OSABI] field, so that we can > differentiate 64 bit HP-UX binaries from 64 bit Linux binaries. > We should also change the field for 32 bit Linux also. Some other bad news is that the change isn't quite trivial, due to not wishing to break other bfd targets. The good new is I've made the change. Compiling at the moment. Alan Modra -- Linuxcare. Support for the Revolution. From bame@noam.fc.hp.com Wed, 01 Nov 2000 10:59:34 -0700 Date: Wed, 01 Nov 2000 10:59:34 -0700 From: Paul Bame bame@noam.fc.hp.com Subject: [parisc-linux] new method for 64-bit parisc tree I want to propose/discuss a new method for maintaining our 64-bit parisc tree in relation to the 32-bit tree. I have prototyped this and so far it seems pretty useful. Most of the files in the current parisc64 tree only contain one line, a #include of the same file from the parisc tree. This confuses 'make dep', causes some compile errors to have nonsense line numbers, and doesn't allow direct editing of the source files in the parisc64 tree. The method I'm proposing works like this: The future parisc64 tree ONLY contains files which are different from, or in addition to, those in the parisc tree. When you 'make config' or 'make oldconfig', each file in the parsic tree is symbolically linked as the same file in the parisc64 tree. This enables all the rest of the tools/build to work normally. 'make distclean' includes a step to remove all the symlinks. The ugliest "feature" is that even though you can edit source files in the parisc64 tree, 'cvs commit' will fail on those which are symbolic links. To reduce this problem, I'm dropping a symbolic link called '...' in each parisc64 directory which is a pointer to the corresponding parisc directory, so 'cd ...; cvs commit foo.c' will work and not be too onerous. We should additionally consider a naming convention or something so that maintainers in the parisc tree know whether files are shared with parisc64 or not. I prototyped this as a fictional new "architecture" called "p64". To try it out, grab the tarball (only about 30 files -- can be fewer) ftp://puffin.external.hp.com/pub/parisc/ and unpack in your top-level linux source tree directory. Then in your top-level Makefile, change ARCH := parisc64 to ARCH := p64, then make oldconfig or whatever you usually do. Let me know of any problems. Is this something we should adopt for the real parisc64 tree? -Paul Bame From kailasr@webcash.com Wed, 01 Nov 2000 12:30:40 -0800 Date: Wed, 01 Nov 2000 12:30:40 -0800 From: Kailashnath V Rampure kailasr@webcash.com Subject: [parisc-linux] NEW NATIVE PALO TARBALL - REQUIRED Thanks paul I was able to run the command. Can you let me know what I should type at ISL prompt as its trying to boot from /stand/vmunix instead of /boot/vmlinux. Also I am unable to open vi as it says vi:LINUX:unknown terminal type. Please suggest. Regards At 02:26 PM 10/31/00 -0700, Paul Bame wrote: >= Hi Paul, >= >= After booting the Server from NFSroot I need to Initialize the harddisk on >= the server. so I copied the palo and linux in to the nfsroot. I am trying >= to Run the following command: >= $ palo -I -k /boot/vmlinux -b /boot/iplboot -c '2/boot/vmlinux TERM=linux >= HOME=/ root=/dev/sda2' /dev/sda >= fisrt partition is 10M of type f0 >= second partition is /dev/sda2 of type linux native. >= Third partition is /dev/sda3 of type linux Swap > >That looks great. > >= Then I get the cannot execute binary file. > >Ok I think we changed the kernal such that the old palo bits won't run >any more (we removed the old gateway page). I uploaded a new version: >ftp://puffin.external.hp.com/pub/parisc/binaries/userspace/palo-200001031.tgz > > -P From matthew@wil.cx Thu, 2 Nov 2000 00:13:06 +0000 Date: Thu, 2 Nov 2000 00:13:06 +0000 From: Matthew Wilcox matthew@wil.cx Subject: linux bame On Wed, Nov 01, 2000 at 01:53:24PM -0700, Paul Bame wrote: > CVSROOT: /home/cvs/parisc > Module name: linux > Changes by: bame 00/11/01 13:53:24 > > Modified files: > include/asm-parisc64: posix_types.h > > Log message: > Don't need a separate copy of this one either err.. are you sure? we used to get a lot of prototype problems when they were the same file. what's changed that they're now able to be the same? -- Revolutions do not require corporate support. From bame@riverrock.org Wed, 01 Nov 2000 23:18:43 -0700 Date: Wed, 01 Nov 2000 23:18:43 -0700 From: bame@riverrock.org bame@riverrock.org Subject: linux bame = On Wed, Nov 01, 2000 at 01:53:24PM -0700, Paul Bame wrote: = > CVSROOT: /home/cvs/parisc = > Module name: linux = > Changes by: bame 00/11/01 13:53:24 = > = > Modified files: = > include/asm-parisc64: posix_types.h = > = > Log message: = > Don't need a separate copy of this one either = = err.. are you sure? we used to get a lot of prototype problems when they = were the same file. what's changed that they're now able to be the same? I changed the parisc version so that the data types would compile to the same size in both wide and narrow mode. Unfortunately there is at least one issue which will probably require this scheme to change :-( -P From grundler@cup.hp.com Thu, 2 Nov 2000 00:21:36 -0800 (PST) Date: Thu, 2 Nov 2000 00:21:36 -0800 (PST) From: Grant Grundler grundler@cup.hp.com Subject: [parisc-linux] a500.out16 Hi Richard (et al), I finally think I understand how pcibios_align_resource() is used... that definitely was the problem. Everything on A500 but PCI-PCI bridge seems to be assigned I/O port and MMIO addresses correctly. I'll look at tulip code tomorrow to see why it's not happy. 6 Tulips are behind PCI-PCI Bridges and that's part of the problem. But the complaints about "MMIO resource" list I/O Port addresses instead...and those look fine to me if they are treated like I/O port addresses... I'd also like to connect some more SCSI disks....but any clue what the "CACHE TEST FAILED" is about? But instead of putting out another tar ball, I'm committing my code. I haven't tested on c3k/j5k yet and it might be broken. 32-bit still builds and any fix should be simple - either cvs update back to an older date or put "if (pdc_pat) { }" around anything that I added that shouldn't be. Tell me to test/fix any brokeness you might find and I'll make time to do it. aplogies for the long delay, grant Firmware Version 40.32 Duplex Console IO Dependent Code (IODC) revision 1 ------------------------------------------------------------------------------ (c) Copyright 1995-1998, Hewlett-Packard Company, All rights reserved ------------------------------------------------------------------------------ Processor Speed State CoProcessor State Cache Size Number State Inst Data --------- -------- --------------------- ----------------- ------------ 0 440 MHz Active Functional 512 KB 1 MB 1 440 MHz Idle Functional 512 KB 1 MB Central Bus Speed (in MHz) : 111 Available Memory : 262144 KB Good Memory Required : 11468 KB Primary boot path: 0/0/1/1.15 Alternate boot path: 0/0/2/1.15 Console path: 0/0/4/0.0 Keyboard path: 0/0/4/0.0 WARNING: The non-destructive test bit was set, so memory was not tested destructively. Information only, no action required. ---- Main Menu --------------------------------------------------------------- Command Description ------- ----------- BOot [PRI|ALT|] Boot from specified path PAth [PRI|ALT] [] Display or modify a path SEArch [DIsplay|IPL] [] Search for boot devices COnfiguration menu Displays or sets boot values INformation menu Displays hardware information SERvice menu Displays service commands DIsplay Redisplay the current menu HElp [|] Display help for menu or command RESET Restart the system ---- Main Menu: Enter command or menu > bo lan Interact with IPL (Y, N, or Cancel)?> n Booting... Network Station Address 00306e-03799f System IP Address 15.8.80.78 Server IP Address 15.8.81.247 Boot IO Dependent Code (IODC) revision 2 HARD Booted. palo ipl grundler@hpisp747 Tue Oct 31 16:45:27 PST 2000 0/vmlinux 2708507 bytes @ 0x6800 0/palo-cmdline '0/vmlinux HOME=/ TERM=linux root=/dev/nfs nfsroot=15.8.81.247:/tftpboot/hppa64 ' Kernel: partition 0 file /vmlinux ELF64 executable Entry 00100000 first 00100000 n 4 Segment 0 load 00100000 size 1705408 mediaptr 0x1000 Segment 1 load 002a2000 size 407616 mediaptr 0x1a2000 Segment 2 load 00308000 size 131960 mediaptr 0x206000 Segment 3 load 0032c000 size 16384 mediaptr 0x227000 branching to kernel entry point 0x00100000 Set default PSW W bit to 1 PDC Console Initialized The 64-bit Kernel has started... Enabled FP coprocessor If this is the LAST MESSAGE YOU SEE, you're probably using 32-bit millicode by mistake. Free memory starts at: 0xc0371000 start_parisc(0x504d40,0x504d40,0x0,0x0) PALO command line: 'HOME=/ TERM=linux root=/dev/nfs nfsroot=15.8.81.247:/tftpboot/hppa64 ' PALO initrd 0-0 model 00005cb0 00000491 00000000 00000001 23355fdc 100000f0 00000008 000000b2 000000b2 vers 00000300 cpuid 0000022a CPUID vers 17 rev 10 Searching for devices in PDC firmware... processor hpa 0xfffffffffffa0000 CELL_GET_NUMBER: 0x0 0x1 PAT_ENTITY_PROC: id_eid 0xa0ff0000 PAT_ENTITY_PROC: id_eid 0xa2ff0000 PAT_ENTITY_MEM: amount 0x10000000 min_gni_base 0x0 min_gni_len 0x0 PAT_ENTITY_SBA: ranges 6 0: 0xc000000000000005 0xfffffffffed18000 0xfffffffffed2ffff 1: 0x8000000000000000 0x0000000000000000 0x000000000000003f 2: 0x8000000000000001 0xfffffffff8000000 0xfffffffffbffffff 3: 0x00040000001a1701 0xfffffffff0000000 0xfffffffff7ffffff 4: 0x00040000001a1701 0xfffffffffc000000 0xfffffffffecfffff 5: 0x8000000000000002 0xfffffff800000000 0xfffffffbffffffff PAT_ENTITY_LBA: ranges 4 0: 0x8000000000000000 0x0000000000000000 0x0000000000000007 1: 0x8000000000000001 0xfffffffff8000000 0xfffffffff87fffff 2: 0x8000000000000002 0xfffffff804000000 0xfffffff87fffffff 3: 0x8000000000000004 0xfffffff800000000 0xfffffff803ffffff PAT_ENTITY_LBA: ranges 4 0: 0x8000000000000000 0x0000000000000010 0x0000000000000017 1: 0x8000000000000001 0xfffffffff9000000 0xfffffffff97fffff 2: 0x8000000000000002 0xfffffff904000000 0xfffffff97fffffff 3: 0x8000000000000004 0xfffffff900000000 0xfffffff903ffffff PAT_ENTITY_LBA: ranges 4 0: 0x8000000000000000 0x0000000000000020 0x0000000000000027 1: 0x8000000000000001 0xfffffffffa000000 0xfffffffffa7fffff 2: 0x8000000000000002 0xfffffffa04000000 0xfffffffa7fffffff 3: 0x8000000000000004 0xfffffffa00000000 0xfffffffa03ffffff PAT_ENTITY_LBA: ranges 4 0: 0x8000000000000000 0x0000000000000030 0x0000000000000037 1: 0x8000000000000001 0xfffffffffb000000 0xfffffffffb7fffff 2: 0x8000000000000002 0xfffffffb04000000 0xfffffffb7fffffff 3: 0x8000000000000004 0xfffffffb00000000 0xfffffffb03ffffff Found devices: 1. Crescendo 440 (0) at 0xfffffffffffa0000, versions 0x5cb, 0x0, 0x4, 0x0, 0x91 2. Crescendo 440 (0) at 0xfffffffffffa2000, versions 0x5cb, 0x0, 0x4, 0x0, 0x91 3. Crescendo Memory (1) at 0xfffffffffed08000, versions 0x9b, 0x0, 0x9, 0x0, 0x0 4. Astro BC Runway Port (12) at 0xfffffffffed00000, versions 0x582, 0x0, 0xb, 0x0, 0x10 5. Elroy PCI Bridge (13) at 0xfffffffffed30000, versions 0x782, 0x0, 0xa, 0x0, 0x0 6. Elroy PCI Bridge (13) at 0xfffffffffed34000, versions 0x782, 0x0, 0xa, 0x0, 0x0 7. Elroy PCI Bridge (13) at 0xfffffffffed38000, versions 0x782, 0x0, 0xa, 0x0, 0x0 8. Elroy PCI Bridge (13) at 0xfffffffffed3c000, versions 0x782, 0x0, 0xa, 0x0, 0x0 That's a total of 8 devices. CONFIG_SMP disabled - not claiming addional CPUs Warning : device (0, 0x5cb, 0x0, 0x4, 0x0) NOT claimed by CPU PARISC CPU(s): 1 x PA8500 (PCX-W) at 440.000000 MHz Linux version 2.4.0-test6 (grundler@hpisp747) (gcc version 2.96 20000925 (experimental)) #73 Wed Nov 1 23:58:51 PST 2000 free_bootmem(0x373000, 0xfc8d000) initrd: 00000000-00000000 pagetable_init On node 0 totalpages: 65536 zone(0): 32768 pages. zone(1): 32768 pages. zone(2): 0 pages. Kernel command line: HOME=/ TERM=linux root=/dev/nfs nfsroot=15.8.81.247:/tftpboot/hppa64 trap_init Calibrating delay loop... 878.18 BogoMIPS kernel BUG at page_alloc.c:106! Memory: 248868k available Dentry-cache hash table entries: 32768 (order: 7, 524288 bytes) Buffer-cache hash table entries: 16384 (order: 5, 131072 bytes) Page-cache hash table entries: 65536 (order: 7, 524288 bytes) Inode-cache hash table entries: 16384 (order: 6, 262144 bytes) POSIX conformance testing by UNIFIX lba version TR4.0 (0x5) found at 0xfffffffffed30000 0: 0x8000000000000000 PA 0x0000000000000000,0x0000000000000007 IO 0x0000000000000000,0x0000000000000007 1: 0x8000000000000001 PA 0xfffffffff8000000,0xfffffffff87fffff IO 0x00000000f8000000,0x00000000f87fffff 2: 0x8000000000000002 PA 0xfffffff804000000,0xfffffff87fffffff IO 0x000000f804000000,0x000000f87fffffff lba range[2] : ignoring GMMIO (0xfffffff804000000) 3: 0x8000000000000004 PA 0xfffffff800000000,0xfffffff803ffffff IO 0x000000f800000000,0x000000f803ffffff lba_fixup_bus(0x00000000cffe60c0) bus 0 sysdata 0x00000000cffe9e80 cons 0x00002000 boot 0x00000000 kbd 0x00002000 claimed 00:00 0 [0,7f]/101 claimed 00:00 1 [fffffffff8020000,fffffffff80203ff]/200 claimed 00:20 0 [fffffffff8000000,fffffffff8000fff]/200 LBA PIOP resource tree 00000000cffe9ed0 [0,7ffff]/100 00000000cffe5080 [0,7f]/101 LBA pcibios_size_bridges() LBA pci_assign_unassigned_resources() pcibios_update_resource(00:08, ..., 0) [100,1ff]/101 pcibios_update_resource(00:08, ..., 1) [fffffffff8001000,fffffffff80013ff]/204 PCI: dev PCI device 1000:000b type 64-bit pcibios_update_resource(00:08, ..., 3) [fffffffff8002000,fffffffff8003fff]/204 PCI: dev PCI device 1000:000b type 64-bit pcibios_update_resource(00:09, ..., 0) [200,2ff]/101 pcibios_update_resource(00:09, ..., 1) [fffffffff8001400,fffffffff80017ff]/204 PCI: dev PCI device 1000:000b type 64-bit pcibios_update_resource(00:09, ..., 3) [fffffffff8004000,fffffffff8005fff]/204 PCI: dev PCI device 1000:000b type 64-bit pcibios_update_resource(00:10, ..., 0) [300,3ff]/101 pcibios_update_resource(00:10, ..., 1) [fffffffff8001800,fffffffff80018ff]/200 pcibios_update_resource(00:10, ..., 2) [fffffffff8006000,fffffffff8006fff]/200 pcibios_update_resource(00:11, ..., 0) [400,4ff]/101 pcibios_update_resource(00:11, ..., 1) [fffffffff8001900,fffffffff80019ff]/200 pcibios_update_resource(00:11, ..., 2) [fffffffff8007000,fffffffff8007fff]/200 pcibios_update_resource(00:20, ..., 1) [80,bf]/101 pcibios_update_resource(00:28, ..., 0) [fffffffff8008000,fffffffff8008fff]/200 pcibios_update_resource(00:28, ..., 1) [c0,ff]/101 LBA pci_set_bus_ranges() pcibios_fixup_pbus_ranges(0, [0,1000 fffffffff8000000,fffffffff8100000]) lba version TR4.0 (0x5) found at 0xfffffffffed34000 0: 0x8000000000000000 PA 0x0000000000000010,0x0000000000000017 IO 0x0000000000000010,0x0000000000000017 1: 0x8000000000000001 PA 0xfffffffff9000000,0xfffffffff97fffff IO 0x00000000f9000000,0x00000000f97fffff 2: 0x8000000000000002 PA 0xfffffff904000000,0xfffffff97fffffff IO 0x000000f904000000,0x000000f97fffffff lba range[2] : ignoring GMMIO (0xfffffff904000000) 3: 0x8000000000000004 PA 0xfffffff900000000,0xfffffff903ffffff IO 0x000000f900000000,0x000000f903ffffff lba_fixup_bus(0x00000000cffe62c0) bus 16 sysdata 0x00000000cffe61c0 cons 0x00002000 boot 0x00000000 kbd 0x00002000 LBA PIOP resource tree 00000000cffe6210 [100000,17ffff]/100 LBA pcibios_size_bridges() LBA pci_assign_unassigned_resources() pcibios_update_resource(10:00, ..., 1) [100000,1000ff]/101 pcibios_update_resource(10:00, ..., 2) [100100,1001ff]/101 pcibios_update_resource(10:00, ..., 3) [fffffffff9000000,fffffffff90001ff]/200 pcibios_update_resource(10:00, ..., 5) [fffffffff9020000,fffffffff903ffff]/200 LBA pci_set_bus_ranges() pcibios_fixup_pbus_ranges(0, [0,1000 fffffffff8000000,fffffffff8100000]) pcibios_fixup_pbus_ranges(16, [100000,101000 fffffffff9000000,fffffffff9100000]) lba version TR4.0 (0x5) found at 0xfffffffffed38000 0: 0x8000000000000000 PA 0x0000000000000020,0x0000000000000027 IO 0x0000000000000020,0x0000000000000027 1: 0x8000000000000001 PA 0xfffffffffa000000,0xfffffffffa7fffff IO 0x00000000fa000000,0x00000000fa7fffff 2: 0x8000000000000002 PA 0xfffffffa04000000,0xfffffffa7fffffff IO 0x000000fa04000000,0x000000fa7fffffff lba range[2] : ignoring GMMIO (0xfffffffa04000000) 3: 0x8000000000000004 PA 0xfffffffa00000000,0xfffffffa03ffffff IO 0x000000fa00000000,0x000000fa03ffffff lba_fixup_bus(0x00000000cffe64c0) bus 32 sysdata 0x00000000cffe63c0 cons 0x00002000 boot 0x00000000 kbd 0x00002000 LBA PIOP resource tree 00000000cffe6410 [200000,27ffff]/100 LBA pcibios_size_bridges() LBA pci_assign_unassigned_resources() pcibios_update_resource(20:00, ..., 0) [200000,2000ff]/101 pcibios_update_resource(20:00, ..., 1) [fffffffffa000000,fffffffffa0003ff]/204 PCI: dev PCI device 1000:000b type 64-bit pcibios_update_resource(20:00, ..., 3) [fffffffffa002000,fffffffffa003fff]/204 PCI: dev PCI device 1000:000b type 64-bit pcibios_update_resource(20:01, ..., 0) [200100,2001ff]/101 pcibios_update_resource(20:01, ..., 1) [fffffffffa000400,fffffffffa0007ff]/204 PCI: dev PCI device 1000:000b type 64-bit pcibios_update_resource(20:01, ..., 3) [fffffffffa004000,fffffffffa005fff]/204 PCI: dev PCI device 1000:000b type 64-bit LBA pci_set_bus_ranges() pcibios_fixup_pbus_ranges(0, [0,1000 fffffffff8000000,fffffffff8100000]) pcibios_fixup_pbus_ranges(16, [100000,101000 fffffffff9000000,fffffffff9100000]) pcibios_fixup_pbus_ranges(32, [200000,201000 fffffffffa000000,fffffffffa100000]) lba version TR4.0 (0x5) found at 0xfffffffffed3c000 0: 0x8000000000000000 PA 0x0000000000000030,0x0000000000000037 IO 0x0000000000000030,0x0000000000000037 1: 0x8000000000000001 PA 0xfffffffffb000000,0xfffffffffb7fffff IO 0x00000000fb000000,0x00000000fb7fffff 2: 0x8000000000000002 PA 0xfffffffb04000000,0xfffffffb7fffffff IO 0x000000fb04000000,0x000000fb7fffffff lba range[2] : ignoring GMMIO (0xfffffffb04000000) 3: 0x8000000000000004 PA 0xfffffffb00000000,0xfffffffb03ffffff IO 0x000000fb00000000,0x000000fb03ffffff lba_fixup_bus(0x00000000cffe66c0) bus 48 sysdata 0x00000000cffe65c0 cons 0x00002000 boot 0x00000000 kbd 0x00002000 lba_fixup_bus(0x00000000cffe67c0) bus 49 sysdata 0x00000000cffe65c0 cons 0x00002000 boot 0x00000000 kbd 0x00002000 lba_fixup_bus(0x00000000cffe68c0) bus 50 sysdata 0x00000000cffe65c0 cons 0x00002000 boot 0x00000000 kbd 0x00002000 LBA PIOP resource tree 00000000cffe6610 [300000,37ffff]/100 LBA pcibios_size_bridges() LBA pci_assign_unassigned_resources() PCI: Failed to allocate resource 0 for PCI device 1000:000b PCI: Failed to allocate resource 1 for PCI device 1000:000b PCI: Failed to allocate resource 3 for PCI device 1000:000b PCI: Failed to allocate resource 0 for PCI device 1000:000b PCI: Failed to allocate resource 1 for PCI device 1000:000b PCI: Failed to allocate resource 3 for PCI device 1000:000b PCI: Failed to allocate resource 0 for PCI device 1011:0019 PCI: Failed to allocate resource 1 for PCI device 1011:0019 PCI: Failed to allocate resource 0 for PCI device 1011:0019 PCI: Failed to allocate resource 1 for PCI device 1011:0019 PCI: Failed to allocate resource 0 for PCI device 1011:0009 PCI: Failed to allocate resource 1 for PCI device 1011:0009 PCI: Failed to allocate resource 0 for PCI device 1011:0009 PCI: Failed to allocate resource 1 for PCI device 1011:0009 PCI: Failed to allocate resource 0 for PCI device 1011:0009 PCI: Failed to allocate resource 1 for PCI device 1011:0009 PCI: Failed to allocate resource 0 for PCI device 1011:0009 PCI: Failed to allocate resource 1 for PCI device 1011:0009 LBA pci_set_bus_ranges() pcibios_fixup_pbus_ranges(0, [0,1000 fffffffff8000000,fffffffff8100000]) pcibios_fixup_pbus_ranges(16, [100000,101000 fffffffff9000000,fffffffff9100000]) pcibios_fixup_pbus_ranges(32, [200000,201000 fffffffffa000000,fffffffffa100000]) pcibios_fixup_pbus_ranges(49, [310000,311000 fffffffffb000000,fffffffffb100000]) pcibios_fixup_pbus_ranges(50, [320000,321000 fffffffffb000000,fffffffffb100000]) pcibios_fixup_pbus_ranges(48, [0,1000 fb000000,fb100000]) SBA found Astro 2.1 at 0xfffffffffed00000 lba_init_iregs() ibase 0x1 imask 0xf0000000 lba_init_iregs() base_addr fffffffffed3c000 lba_init_iregs() base_addr fffffffffed38000 lba_init_iregs() base_addr fffffffffed34000 lba_init_iregs() base_addr fffffffffed30000 lba_init_iregs() done lba: lba_bios_init Linux NET4.0 for Linux 2.4 Based upon Swansea University Computer Society NET3.039 NET4: Linux TCP/IP 1.0 for NET4.0 IP Protocols: ICMP, UDP, TCP IP: routing cache hash table of 1024 buckets, 16Kbytes TCP: Hash tables configured (established 8192 bind 8192) Starting kswapd v1.7 pty: 256 Unix98 ptys configured lp: driver loaded but no devices found RAMDISK driver initialized: 16 RAM disks of 4096K size 1024 blocksize sym53c8xx: at PCI bus 0, device 2, function 0 sym53c8xx: setting PCI_COMMAND_PARITY...(fix-up) sym53c8xx: changing PCI_LATENCY_TIMER from 0 to 80. kernel BUG at sym53c8xx.c:725! sym53c8xx: 53c876 detected sym53c8xx: at PCI bus 0, device 2, function 1 sym53c8xx: setting PCI_COMMAND_PARITY...(fix-up) sym53c8xx: changing PCI_LATENCY_TIMER from 0 to 80. kernel BUG at sym53c8xx.c:725! sym53c8xx: 53c876 detected sym53c8xx: at PCI bus 0, device 1, function 0 sym53c8xx: setting PCI_COMMAND_PARITY...(fix-up) sym53c8xx: changing PCI_LATENCY_TIMER from 0 to 80. kernel BUG at sym53c8xx.c:725! sym53c8xx: 53c896 detected sym53c8xx: at PCI bus 0, device 1, function 1 sym53c8xx: setting PCI_COMMAND_PARITY...(fix-up) sym53c8xx: changing PCI_LATENCY_TIMER from 0 to 80. kernel BUG at sym53c8xx.c:725! sym53c8xx: 53c896 detected sym53c8xx: at PCI bus 32, device 0, function 0 sym53c8xx: setting PCI_COMMAND_PARITY...(fix-up) sym53c8xx: changing PCI_LATENCY_TIMER from 0 to 80. kernel BUG at sym53c8xx.c:725! sym53c8xx: 53c896 detected sym53c8xx: at PCI bus 32, device 0, function 1 sym53c8xx: setting PCI_COMMAND_PARITY...(fix-up) sym53c8xx: changing PCI_LATENCY_TIMER from 0 to 80. kernel BUG at sym53c8xx.c:725! sym53c8xx: 53c896 detected sym53c8xx: at PCI bus 49, device 4, function 0 sym53c8xx: setting PCI_COMMAND_PARITY...(fix-up) sym53c8xx: changing PCI_LATENCY_TIMER from 0 to 80. kernel BUG at sym53c8xx.c:725! sym53c8xx: 53c896 detected sym53c8xx: at PCI bus 49, device 4, function 1 sym53c8xx: setting PCI_COMMAND_PARITY...(fix-up) sym53c8xx: changing PCI_LATENCY_TIMER from 0 to 80. kernel BUG at sym53c8xx.c:725! sym53c8xx: 53c896 detected kernel BUG at sym53c8xx.c:725! sym53c876-0: rev 0x14 on pci bus 0 device 2 function 0 irq 130 sym53c876-0: NCR clock is 40218KHz sym53c876-0: ID 7, Fast-20, Parity Checking sym53c876-0: on-chip RAM at 0xfffffffff8006000 sym53c876-0: restart (scsi reset). sym53c876-0: Downloading SCSI SCRIPTS. kernel BUG at sym53c8xx.c:725! sym53c876-1: rev 0x14 on pci bus 0 device 2 function 1 irq 131 sym53c876-1: NCR clock is 40218KHz sym53c876-1: ID 7, Fast-20, Parity Checking sym53c876-1: on-chip RAM at 0xfffffffff8007000 sym53c876-1: restart (scsi reset). sym53c876-1: Downloading SCSI SCRIPTS. kernel BUG at sym53c8xx.c:725! sym53c896-2: rev 0x7 on pci bus 0 device 1 function 0 irq 129 sym53c896-2: NCR clock is 40218KHz sym53c896-2: ID 7, Fast-40, Parity Checking sym53c896-2: on-chip RAM at 0xfffffffff8002000 sym53c896-2: restart (scsi reset). sym53c896-2: handling phase mismatch from SCRIPTS. sym53c896-2: Downloading SCSI SCRIPTS. kernel BUG at sym53c8xx.c:725! sym53c896-3: rev 0x7 on pci bus 0 device 1 function 1 irq 130 sym53c896-3: NCR clock is 40218KHz sym53c896-3: ID 7, Fast-40, Parity Checking sym53c896-3: on-chip RAM at 0xfffffffff8004000 sym53c896-3: restart (scsi reset). sym53c896-3: handling phase mismatch from SCRIPTS. sym53c896-3: Downloading SCSI SCRIPTS. kernel BUG at sym53c8xx.c:725! sym53c896-4: rev 0x1 on pci bus 32 device 0 function 0 irq 256 sym53c896-4: NCR clock is 40218KHz sym53c896-4: ID 7, Fast-40, Parity Checking sym53c896-4: on-chip RAM at 0xfffffffffa002000 sym53c896-4: restart (scsi reset). sym53c896-4: handling phase mismatch from SCRIPTS. sym53c896-4: Downloading SCSI SCRIPTS. kernel BUG at sym53c8xx.c:725! sym53c896-5: rev 0x1 on pci bus 32 device 0 function 1 irq 257 sym53c896-5: NCR clock is 40218KHz sym53c896-5: ID 7, Fast-40, Parity Checking sym53c896-5: on-chip RAM at 0xfffffffffa004000 sym53c896-5: restart (scsi reset). sym53c896-5: handling phase mismatch from SCRIPTS. sym53c896-5: Downloading SCSI SCRIPTS. kernel BUG at sym53c8xx.c:725! sym53c896-6: rev 0x5 on pci bus 49 device 4 function 0 irq 323 sym53c896-6: ID 7, Fast-40, Parity Checking sym53c896-6: on-chip RAM at 0xfffffffffb000000 CACHE TEST FAILED: reg dstat-sstat2 readback ffffffff. CACHE INCORRECTLY CONFIGURED. sym53c896-6: giving up ... kernel BUG at sym53c8xx.c:725! kernel BUG at sym53c8xx.c:725! kernel BUG at sym53c8xx.c:725! sym53c896-6: rev 0x5 on pci bus 49 device 4 function 1 irq 320 sym53c896-6: ID 7, Fast-40, Parity Checking sym53c896-6: on-chip RAM at 0xfffffffffb000000 CACHE TEST FAILED: reg dstat-sstat2 readback ffffffff. CACHE INCORRECTLY CONFIGURED. sym53c896-6: giving up ... kernel BUG at sym53c8xx.c:725! kernel BUG at sym53c8xx.c:725! scsi0 : sym53c8xx - version 1.6b scsi1 : sym53c8xx - version 1.6b scsi2 : sym53c8xx - version 1.6b scsi3 : sym53c8xx - version 1.6b scsi4 : sym53c8xx - version 1.6b scsi5 : sym53c8xx - version 1.6b scsi : 6 hosts. Vendor: SEAGATE Model: ST318404LC Rev: HP01 Type: Direct-Access ANSI SCSI revision: 03 Detected scsi disk sda at scsi3, channel 0, id 15, lun 0 sym53c896-3-<15,0>: tagged command queue depth set to 8 scsi : detected 1 SCSI disk total. sym53c896-3-<15,0>: wide msgout: 1-2-3-1. sym53c896-3-<15,0>: wide msgin: 1-2-3-1. sym53c896-3-<15,0>: wide: wide=1 chg=0. sym53c896-3-<15,0>: wide msgout: 1-2-3-1. sym53c896-3-<15,0>: wide msgin: 1-2-3-1. sym53c896-3-<15,0>: wide: wide=1 chg=0. sym53c896-3-<15,0>: sync msgout: 1-3-1-c-1f. sym53c896-3-<15,0>: sync msg in: 1-3-1-c-1f. sym53c896-3-<15,0>: sync: per=12 scntl3=0xb0 scntl4=0x0 ofs=31 fak=0 chg=0. sym53c896-3-<15,*>: FAST-20 WIDE SCSI 40.0 MB/s (50 ns, offset 31) SCSI device sda: hdwr sector= 512 bytes. Sectors= 35566480 [17366 MB] [17.4 GB] Partition check: sda: unknown partition table Serial driver version 5.01 (2000-05-29) with MANY_PORTS SHARE_IRQ SERIAL_PCI enabled Linux Tulip driver version 0.9.8 (July 13, 2000) tulip: MMIO resource (0x80@0x0) unavailable, aborting tulip: MMIO resource (0x80@0x310200) unavailable, aborting tulip: MMIO resource (0x80@0x310280) unavailable, aborting tulip: MMIO resource (0x80@0x320300) unavailable, aborting tulip: MMIO resource (0x80@0x320380) unavailable, aborting tulip: MMIO resource (0x80@0x320400) unavailable, aborting tulip: MMIO resource (0x80@0x320480) unavailable, aborting IP-Config: No network devices available. Switching from PDC console From alan@linuxcare.com.au Thu, 2 Nov 2000 19:51:19 +1100 (EST) Date: Thu, 2 Nov 2000 19:51:19 +1100 (EST) From: Alan Modra alan@linuxcare.com.au Subject: [parisc-linux] new method for 64-bit parisc tree On Wed, 1 Nov 2000, Paul Bame wrote: > The future parisc64 tree ONLY contains files which are different from, > or in addition to, those in the parisc tree. When you 'make config' > or 'make oldconfig', each file in the parsic tree is symbolically > linked as the same file in the parisc64 tree. This enables all > the rest of the tools/build to work normally. 'make distclean' includes > a step to remove all the symlinks. Instead, can't you simply play tricks with -I, and add a symbolic link asm -> ../asm-parisc in asm-parisc64)? The idea being to end up with an include path looking like "-I $(TOPDIR)/include -I $(TOPDIR)/include/asm" That way, asm/foo.h is found by the first -I if we have asm-parisc64/foo.h, and is found by the second if asm-parisc/foo.h exists but not asm-parisc64/foo.h. Hmm, you might also need -I- -- Linuxcare. Support for the Revolution. From rhirst@linuxcare.com Thu, 2 Nov 2000 10:43:06 +0000 Date: Thu, 2 Nov 2000 10:43:06 +0000 From: Richard Hirst rhirst@linuxcare.com Subject: [parisc-linux] a500.out16 On Thu, Nov 02, 2000 at 12:21:36AM -0800, Grant Grundler wrote: > Hi Richard (et al), > I finally think I understand how pcibios_align_resource() is used... > that definitely was the problem. Everything on A500 but PCI-PCI bridge > seems to be assigned I/O port and MMIO addresses correctly. > > I'll look at tulip code tomorrow to see why it's not happy. I fixed tulip_core.c to report what it means, which gave me tulip: MMIO resource (0x400@0xfffffffff8020000) unavailable, aborting Note sym53c8xx.c doesn't seem to bother with request_mem_region(), so maybe request_mem_region() is just broken. I then patched out the goto, so it ignored that error, and.... Linux Tulip driver version 0.9.8 (July 13, 2000) tulip: MMIO resource (0x400@0xfffffffff8020000) unavailable, aborting PCI: Setting latency timer of device 00:00.0 to 64 eth0: Digital DS21143 Tulip rev 65 at 0x0, 00:30:6E:03:79:A0, IRQ 128. eth0: MII transceiver #1 config 1000 status 782d advertising 01e1. Sending BOOTP requests.... OK IP-Config: Got BOOTP answer from 10.160.240.111, my address is 10.160.240.117 Switching from PDC console Wheeee! Nice work Grant! Richard From rhirst@linuxcare.com Thu, 2 Nov 2000 10:48:33 +0000 Date: Thu, 2 Nov 2000 10:48:33 +0000 From: Richard Hirst rhirst@linuxcare.com Subject: [parisc-linux] a500.out16 On Thu, Nov 02, 2000 at 12:21:36AM -0800, Grant Grundler wrote: > I'd also like to connect some more SCSI disks....but any clue > what the "CACHE TEST FAILED" is about? .... > sym53c896-6: rev 0x5 on pci bus 49 device 4 function 0 irq 323 > sym53c896-6: ID 7, Fast-40, Parity Checking > sym53c896-6: on-chip RAM at 0xfffffffffb000000 > CACHE TEST FAILED: reg dstat-sstat2 readback ffffffff. > CACHE INCORRECTLY CONFIGURED. I'd guess that the NCR registers are being cached: static int __init ncr_regtest (struct ncb* np) { register volatile u_int32 data; /* ** ncr registers may NOT be cached. ** write 0xffffffff to a read only register area, ** and try to read it back. */ data = 0xffffffff; OUTL_OFF(offsetof(struct ncr_reg, nc_dstat), data); data = INL_OFF(offsetof(struct ncr_reg, nc_dstat)); #if 1 if (data == 0xffffffff) { #else if ((data & 0xe2f0fffd) != 0x02000080) { #endif printk ("CACHE TEST FAILED: reg dstat-sstat2 readback %x.\n", (unsigned) data); return (0x10); }; return (0); } Richard From fl@fl.priv.at Thu, 02 Nov 2000 12:15:17 +0100 Date: Thu, 02 Nov 2000 12:15:17 +0100 From: Friedrich Lobenstock fl@fl.priv.at Subject: [parisc-linux] HP 3000 - 922LX ?? Hi! How about support for a HP3000-922LX? I think this should be a PA-RISC machine. PS: Please CC me, because I'm not on the list. MfG / Regards Friedrich Lobenstock From rhirst@linuxcare.com Thu, 2 Nov 2000 11:30:47 +0000 Date: Thu, 2 Nov 2000 11:30:47 +0000 From: Richard Hirst rhirst@linuxcare.com Subject: [parisc-linux] a500.out16 On Thu, Nov 02, 2000 at 10:43:06AM +0000, Richard Hirst wrote: > On Thu, Nov 02, 2000 at 12:21:36AM -0800, Grant Grundler wrote: > > Hi Richard (et al), > > I finally think I understand how pcibios_align_resource() is used... > > that definitely was the problem. Everything on A500 but PCI-PCI bridge > > seems to be assigned I/O port and MMIO addresses correctly. > > > > I'll look at tulip code tomorrow to see why it's not happy. > > I fixed tulip_core.c to report what it means, which gave me > > tulip: MMIO resource (0x400@0xfffffffff8020000) unavailable, aborting > > Note sym53c8xx.c doesn't seem to bother with request_mem_region(), so > maybe request_mem_region() is just broken. It is broken because of the following line in kernel/resource.c: struct resource iomem_resource = { "PCI mem", 0x00000000, 0xffffffff, IORESOURCE_MEM }; 'end' needs to be rather higher than 0xffffffff on 64 bit. I changed it to struct resource iomem_resource = { "PCI mem", 0x00000000, ~0, IORESOURCE_MEM }; and it works. I havn't committed that 'fix' though. Richard From matthew@wil.cx Thu, 2 Nov 2000 11:57:53 +0000 Date: Thu, 2 Nov 2000 11:57:53 +0000 From: Matthew Wilcox matthew@wil.cx Subject: [parisc-linux] HP 3000 - 922LX ?? On Thu, Nov 02, 2000 at 12:15:17PM +0100, Friedrich Lobenstock wrote: > Hi! > > How about support for a HP3000-922LX? I think this should be a PA-RISC > machine. According to the docs: http://www.thepuffingroup.com/parisc/hp9000_models.html the 922 is the same physical machine as the 822. As such, it's too old for it to be worth supporting. the official statement is... The earliest PA-RISC servers have proprietary HP devices attached to proprietary HP bus architectures. It is unlikely that documentation on these busses and devices will ever become available, since so few people are interested in spending any effort finding and releasing the docs. Machines in this category are the E, F, G, H, I class (aka Nova) and T500 series (Emerald) machines as well as some earlier, unlettered servers. I should perhaps update this to reflect the particular model numbers. -- Revolutions do not require corporate support. From rhirst@linuxcare.com Thu, 2 Nov 2000 12:07:36 +0000 Date: Thu, 2 Nov 2000 12:07:36 +0000 From: Richard Hirst rhirst@linuxcare.com Subject: [parisc-linux] a500.out16 On Thu, Nov 02, 2000 at 10:43:06AM +0000, Richard Hirst wrote: > Linux Tulip driver version 0.9.8 (July 13, 2000) > tulip: MMIO resource (0x400@0xfffffffff8020000) unavailable, aborting > PCI: Setting latency timer of device 00:00.0 to 64 > eth0: Digital DS21143 Tulip rev 65 at 0x0, 00:30:6E:03:79:A0, IRQ 128. > eth0: MII transceiver #1 config 1000 status 782d advertising 01e1. > Sending BOOTP requests.... OK > IP-Config: Got BOOTP answer from 10.160.240.111, my address is 10.160.240.117 > Switching from PDC console > > Wheeee! Nice work Grant! And if you stop it from trying to switch from pdc to ttyS0 console: Linux Tulip driver version 0.9.8 (July 13, 2000) PCI: Setting latency timer of device 00:00.0 to 64 eth0: Digital DS21143 Tulip rev 65 at 0x0, 00:30:6E:03:79:A0, IRQ 128. eth0: MII transceiver #1 config 1000 status 782d advertising 01e1. Sending BOOTP requests.... OK IP-Config: Got BOOTP answer from 10.160.240.111, my address is 10.160.240.117 kmem_create: Forcing size word alignment - nfs_fh Looking up port of RPC 100003/2 on 10.160.240.111 Looking up port of RPC 100005/2 on 10.160.240.111 VFS: Mounted root (nfs filesystem) readonly. Warning: unable to open an initial console. Kernel panic: Attempted to kill init! Richard From matthew@wil.cx Thu, 2 Nov 2000 12:01:58 +0000 Date: Thu, 2 Nov 2000 12:01:58 +0000 From: Matthew Wilcox matthew@wil.cx Subject: [parisc-linux] a500.out16 On Thu, Nov 02, 2000 at 11:30:47AM +0000, Richard Hirst wrote: > > Note sym53c8xx.c doesn't seem to bother with request_mem_region(), so > > maybe request_mem_region() is just broken. > > It is broken because of the following line in kernel/resource.c: > > struct resource iomem_resource = { "PCI mem", 0x00000000, 0xffffffff, IORESOURCE_MEM }; > > 'end' needs to be rather higher than 0xffffffff on 64 bit. I changed it to > > struct resource iomem_resource = { "PCI mem", 0x00000000, ~0, IORESOURCE_MEM }; > > and it works. I havn't committed that 'fix' though. Probably just as well... the pci_consistent interfaces were designed partly to stop 32-bit PCI cards having to do dual-address-cycle on machines with an IOMMU. if you can, this card should get mapped below the 32-bit boundary. -- Revolutions do not require corporate support. From grundler@cup.hp.com Thu, 02 Nov 2000 08:12:47 -0800 Date: Thu, 02 Nov 2000 08:12:47 -0800 From: Grant Grundler grundler@cup.hp.com Subject: [parisc-linux] a500.out16 This is why I do NOT like our current scheme of using host physical addresses to access I/O space. Richard Hirst wrote: ... > I'd guess that the NCR registers are being cached: > > > static int __init ncr_regtest (struct ncb* np) > { > register volatile u_int32 data; > /* > ** ncr registers may NOT be cached. > ** write 0xffffffff to a read only register area, > ** and try to read it back. > */ > data = 0xffffffff; > OUTL_OFF(offsetof(struct ncr_reg, nc_dstat), data); > data = INL_OFF(offsetof(struct ncr_reg, nc_dstat)); If INL_OFF and OUTL_OFF are broken, they will very likely point to something in memory - page zero. And happily scribble over it gsc_write(xxx). We don't cache I/O space. Never. Something is definitely broken on this code path. I'll look at this once I find out what I broke on the j5k/c3k boot path in lba_pci.c. jsm already restored the previous version of lba_pci.c so folks can still boot 32-bit on c3k/j5k. grant Grant Grundler Unix Systems Enablement Lab +1.408.447.7253 From bame@riverrock.org Thu, 02 Nov 2000 09:20:24 -0700 Date: Thu, 02 Nov 2000 09:20:24 -0700 From: bame@riverrock.org bame@riverrock.org Subject: [parisc-linux] new method for 64-bit parisc tree I want to hear concerns because without serious ones I'm going to make this change next week... = Instead, can't you simply play tricks with -I, and add a symbolic link = asm -> ../asm-parisc in asm-parisc64)? The idea being to end up with = an include path looking like = "-I $(TOPDIR)/include -I $(TOPDIR)/include/asm" = = That way, asm/foo.h is found by the first -I if we have asm-parisc64/foo.h, = and is found by the second if asm-parisc/foo.h exists but not = asm-parisc64/foo.h. Hmm, you might also need -I- That would function fine for header files, but not for source files where something like VPATH might work, but is not available to us. It's worth noting that both -I and VPATH tricks mean if you have an error in or need to change a file, you may have to examine two directories to figure out where it really lives. The symbolic link scheme solves some of that problem. -P From dkennedy@linuxcare.com Thu, 2 Nov 2000 12:30:32 -0800 (PST) Date: Thu, 2 Nov 2000 12:30:32 -0800 (PST) From: dkennedy dkennedy@linuxcare.com Subject: [parisc-linux] Boot Problems with 755 On Mon, 30 Oct 2000, Matthew Wilcox wrote: > This isn't tagged correctly in the hwdb. Could someone inside linuxcare > please fix this? It should be supported by the Apricot driver. I have updated the hwdb to include the Coral II Core Lan Apricot driver. -- David Kennedy, Technical Account Manager, Linuxcare, Inc. 613.562.9594 tel, 613.562.9304 fax dkennedy@linuxcare.com, http://www.linuxcare.com/ Linuxcare. Support for the revolution. From grundler@cup.hp.com Thu, 02 Nov 2000 08:42:06 -0800 Date: Thu, 02 Nov 2000 08:42:06 -0800 From: Grant Grundler grundler@cup.hp.com Subject: [parisc-linux] a500.out16 Matthew Wilcox wrote: > On Thu, Nov 02, 2000 at 11:30:47AM +0000, Richard Hirst wrote: > > > Note sym53c8xx.c doesn't seem to bother with request_mem_region(), so > > > maybe request_mem_region() is just broken. > > > > It is broken because of the following line in kernel/resource.c: > > > > struct resource iomem_resource = { "PCI mem", 0x00000000, 0xffffffff, IORES > OURCE_MEM }; > > > > 'end' needs to be rather higher than 0xffffffff on 64 bit. I changed it to > > > > struct resource iomem_resource = { "PCI mem", 0x00000000, ~0, IORESOURCE_ME > M }; > > > > and it works. I havn't committed that 'fix' though. > > Probably just as well... the pci_consistent interfaces were designed > partly to stop 32-bit PCI cards having to do dual-address-cycle on > machines with an IOMMU. if you can, this card should get mapped below > the 32-bit boundary. Mathew, That's not the whole story. The value (0xfffffffff8020000) seen by the PCI driver *is* a 32-bit PCI address - dual address cycles are not needed. pcibios_update_resource() mangles the address the PCI device driver uses to fit the BAR it's supposed to get written to. See arch/parisc/kernel/pci.c and I think you'll understand. I think you are confusing DMA with PIO (register accesses). The address above is only used to PIO to access registers and has nothing to do with DMA (or I/O MMUs). And PCI device's that can do dual address cycle *should* in order to *avoid* the I/O MMU. The I/O MMU introduces a latency in the DMA path which ideally would be avoided. Of course, there are lots of issues with making that actually work...but it can work. I haven't looked at the whole issue of 64-bit BAR's yet. Mostly because I haven't had to. 64-bit BAR's work just fine when the upper 32-bits are zero'd. :^) But also because the 896 chip (older rev's at least) has 64-bit BARs and it didn't work during N-class bringup in Feb 1999. Currently shipping revs may work. A hack needs to go into pci_quirks.c to support 896 64-bit BARs. thanks for the ideas though, grant Grant Grundler Unix Systems Enablement Lab +1.408.447.7253 From headcrusher@web.de Thu, 2 Nov 2000 19:58:51 +0100 Date: Thu, 2 Nov 2000 19:58:51 +0100 From: =?iso-8859-1?Q? Alexander=20Sch=F6ck ?= headcrusher@web.de Subject: [parisc-linux] Help!? Hallo Puffingroup-Team, I have a very important question about the installation of the linux for PARisc. I hope you can help me! OK, i have a 725/100 Unix Workstation, i tried to install the PARisc-linux on this machine. The CD is booting from this machine, but in the middle of the booting phase the system hang on following line: "request_irq(259, c01ec76c, 0x0, asp, c3rcd080)" - So, what's wrong? How can I go on with the installation? Bye, Alexander S. _______________________________________________________________________ 1.000.000 DM gewinnen - kostenlos tippen - http://millionenklick.web.de IhrName@web.de, 8MB Speicher, Verschluesselung - http://freemail.web.de From matthew@wil.cx Fri, 3 Nov 2000 00:08:06 +0000 Date: Fri, 3 Nov 2000 00:08:06 +0000 From: Matthew Wilcox matthew@wil.cx Subject: [parisc-linux] Help!? On Thu, Nov 02, 2000 at 07:58:51PM +0100, Alexander Schöck wrote: > How can I go on with the installation? question added to the FAQ: 7. I'm using the Alpha 0.1 release CD and the machine stops after printing request_irq(259, c01ec76c, 0x0, asp, c3rcd080) what's going on? This is a bug in the kernel shipped on the CD. It only affects certain machines and has been fixed in the current CVS tree. We recommend you acquire a newer kernel from the FTP site. -- Revolutions do not require corporate support. From kailasr@webcash.com Thu, 02 Nov 2000 17:29:19 -0800 Date: Thu, 02 Nov 2000 17:29:19 -0800 From: Kailashnath V Rampure kailasr@webcash.com Subject: [parisc-linux] Boot command Hi, I have run the following command to initialize the sda harddisk. The sda3 is the linux native partion. Wen I say boot on the HP server it is trying to boot from /stand/vmunix instead of vmlinux can any one help me about the command. Secondaly I want to knwo what is the term type as its not taking vt100 so I am unable to open vi. I have made nesessary changes for the /etc/fstab $ palo -I -k /boot/vmlinux -b /boot/iplboot -c '3/boot/vmlinux TERM=linux HOME=/ root=/dev/sda3' /dev/sda regards Kailas From grundler@cup.hp.com Thu, 02 Nov 2000 17:44:23 -0800 Date: Thu, 02 Nov 2000 17:44:23 -0800 From: Grant Grundler grundler@cup.hp.com Subject: [parisc-linux] Boot command Kailashnath V Rampure wrote: > Hi, > I have run the following command to initialize the sda harddisk. The sda3 > is the linux native partion. > Wen I say boot on the HP server it is trying to boot from /stand/vmunix > instead of vmlinux can any one help me about the command. Sounds like your system is booting from an existing HPUX installed disk. Ie you are not using palo. > Secondaly I want > to knwo what is the term type as its not taking vt100 so I am unable to > open vi. TERM=linux is what I've seen before. The debian ncurses package might need to be installed first though and vt100 should work too. Search the mail archive at http://puffin.external.hp.com/cgi-bin/mailgrep grant > > I have made nesessary changes for the /etc/fstab > > $ palo -I -k /boot/vmlinux -b /boot/iplboot -c '3/boot/vmlinux TERM=linux > HOME=/ root=/dev/sda3' /dev/sda > > regards > Kailas > > --------------------------------------------------------------------------- > To unsubscribe: send e-mail to parisc-linux-request@thepuffingroup.com with > `unsubscribe' as the subject. > Grant Grundler Unix Systems Enablement Lab +1.408.447.7253 From taggart@carmen.fc.hp.com Thu, 02 Nov 2000 18:47:33 -0700 Date: Thu, 02 Nov 2000 18:47:33 -0700 From: Matt Taggart taggart@carmen.fc.hp.com Subject: [parisc-linux] Boot command Kailashnath V Rampure writes... > Hi, > I have run the following command to initialize the sda harddisk. The sda3 > is the linux native partion. > Wen I say boot on the HP server it is trying to boot from /stand/vmunix > instead of vmlinux can any one help me about the command. This means that you are somehow still booting an HP-UX lifimage. Did you follow the directions on, http://www.thepuffingroup.com/parisc/install.html including the partitioning stuff? Maybe you're still booting off another disk, are you sure you're booting from the linux disk? HTH, -- Matt Taggart taggart@fc.hp.com From headcrusher@web.de Fri, 3 Nov 2000 08:04:31 +0100 Date: Fri, 3 Nov 2000 08:04:31 +0100 From: =?iso-8859-1?Q? Alexander=20Sch=F6ck ?= headcrusher@web.de Subject: [parisc-linux] Help!? I downloaded a new kernel from the ftp-site, how can i use this kernel to work with my machine? This is a image file, how can i extract this file, or must i copy it only to the boot-cd? How can i use this kernel? Matthew Wilcox schrieb am 03.11.00: > On Thu, Nov 02, 2000 at 07:58:51PM +0100, Alexander Schöck wrote: > > How can I go on with the installation? > > question added to the FAQ: > > 7. I'm using the Alpha 0.1 release CD and the machine stops after printing > request_irq(259, c01ec76c, 0x0, asp, c3rcd080) > what's going on? > > This is a bug in the kernel shipped on the CD. It only affects certain > machines and has been fixed in the current CVS tree. We recommend you > acquire a newer kernel from the FTP site. > > -- > Revolutions do not require corporate support. > _______________________________________________________________________ 1.000.000 DM gewinnen - kostenlos tippen - http://millionenklick.web.de IhrName@web.de, 8MB Speicher, Verschluesselung - http://freemail.web.de From pdbeal@louisville.edu Fri, 3 Nov 2000 10:02:39 -0500 Date: Fri, 3 Nov 2000 10:02:39 -0500 From: Phillip Beal pdbeal@louisville.edu Subject: [parisc-linux] STI Console problems on 735 and 755 Hey, After all the help I obtained from this list, both through my posts and through the archives, I've finally gotten the 735 and 755, that I have access to, to boot and run linux. However, as soon as it starts to process init, the console screen becomes garbled. The system continues to boot, and I can access the machine via serial console and minicom, but the physical console on the box, just prints garbage. Is this normal for this stage of development? I couldn't see anything in the archives, that said it was, so I'm wondering how I fix this problem, if its been fixed before. Thanks, -- Phillip Beal Electrical and Computer Engineering S+LUG Vice-President From adevries@linuxcare.com Fri, 03 Nov 2000 11:37:08 -0500 Date: Fri, 03 Nov 2000 11:37:08 -0500 From: Alex deVries adevries@linuxcare.com Subject: [parisc-linux] STI Console problems on 735 and 755 Phillip Beal wrote: > After all the help I obtained from this list, both through my posts and > through the archives, I've finally gotten the 735 and 755, that I have > access to, to boot and run linux. However, as soon as it starts to > process init, the console screen becomes garbled. The system continues > to boot, and I can access the machine via serial console and minicom, > but the physical console on the box, just prints garbage. Is this > normal for this stage of development? I couldn't see anything in the > archives, that said it was, so I'm wondering how I fix this problem, if > its been fixed before. Good to hear that your 735 and 755 start to boot! What kind of graphics hardware is sitting on a 735 or 755? I think we've only ever looked at that on a 712 and 715. Can you use serial console in the meantime? - Alex -- Alex deVries, Principal Solutions Architect, The Puffins at Linuxcare 613.562.2759 tel alex@linuxcare.com, http://www.linuxcare.com/ Linuxcare, Support for the revolution. From pdbeal@louisville.edu Fri, 3 Nov 2000 10:49:00 -0500 Date: Fri, 3 Nov 2000 10:49:00 -0500 From: Phillip Beal pdbeal@louisville.edu Subject: [parisc-linux] STI Console problems on 735 and 755 > What kind of graphics hardware is sitting on a 735 or 755? I think > we've only ever looked at that on a 712 and 715. Both the 735 and the 755 have the following device, that seems be refer to the graphics: Coral SGC Graphics (10) at 0xf8000000, version 0x4, 0x0, 0x77, 0x0, 0x0 However, the 755 is known only to use mono graphics, even though they both report the same info for the Coral SGC Grpahics. I hope this helps, > Can you use serial console in the meantime? Yeah, serial works just fine. > > - Alex > > -- > Alex deVries, Principal Solutions Architect, The Puffins at Linuxcare > 613.562.2759 tel > alex@linuxcare.com, http://www.linuxcare.com/ > Linuxcare, Support for the revolution. -- Phillip Beal Electrical and Computer Engineering S+LUG Vice-President From kailasr@webcash.com Fri, 03 Nov 2000 11:03:23 -0800 Date: Fri, 03 Nov 2000 11:03:23 -0800 From: Kailashnath V Rampure kailasr@webcash.com Subject: [parisc-linux] Boot command Yes I have been following the same Doc. its tries to boot from the sda as I can see the hard disk path. I have 2 Hdd's one sda and other sdb. the path are 8/16/5.6 and other is 8/16/5.0. Here I think /dev/sda is 8/16/5.6. It is trying to boot but give sthe following o/p: Boot IO Dependent Code (IODC) revision 144 .... SUCCEEDED! HARD Booted. palo ipl bame@noam Tue Oct 31 14:18:02 MST 2000 0/vmlinux 208896 bytes @ 0x1f78c000 0/palo-cmdline '3/boot/vmlinux TERM=linux Home=/ root=/dev/sdb3' /dev/ida1 82 62 1030688 /dev/ida2 f0 1030750 24738 /dev/ida3 83 1055488 1030750 Kernel:partition 3 file /boot/vmlinux ext2 block size 1024 ext2_mount(partition 3) returns 0 ext2_open(/boot/vmlinux)=3 Couldn't gork your kernel executabel format failed to load kernel Failed to load Kernel. please suggest. At 06:47 PM 11/2/00 -0700, Matt Taggart wrote: >Kailashnath V Rampure writes... > > > Hi, > > I have run the following command to initialize the sda harddisk. The sda3 > > is the linux native partion. > > Wen I say boot on the HP server it is trying to boot from /stand/vmunix > > instead of vmlinux can any one help me about the command. > >This means that you are somehow still booting an HP-UX lifimage. Did you >follow the directions on, > >http://www.thepuffingroup.com/parisc/install.html > >including the partitioning stuff? Maybe you're still booting off another >disk, >are you sure you're booting from the linux disk? > >HTH, > >-- >Matt Taggart >taggart@fc.hp.com From grundler@cup.hp.com Fri, 03 Nov 2000 11:19:29 -0800 Date: Fri, 03 Nov 2000 11:19:29 -0800 From: Grant Grundler grundler@cup.hp.com Subject: [parisc-linux] Boot command Kailashnath V Rampure wrote: > Yes I have been following the same Doc. > its tries to boot from the sda as I can see the hard disk path. I have 2 > Hdd's one sda and other sdb. the path are 8/16/5.6 and other is 8/16/5.0. > Here I think /dev/sda is 8/16/5.6. The lower numbered SCSI ID will be /dev/sda. SCSI devices are lettered in the order they are discovered. The order is reflected in /proc/scsi/scsi. grant Grant Grundler Unix Systems Enablement Lab +1.408.447.7253 From kailasr@webcash.com Fri, 03 Nov 2000 11:46:39 -0800 Date: Fri, 03 Nov 2000 11:46:39 -0800 From: Kailashnath V Rampure kailasr@webcash.com Subject: [parisc-linux] Boot command I have removed the 2nd HDD now the boot is trying but I get the same error: my fstab reads as : # /etc/fstab: static file system information. # # #/dev/sda1 /boot ext2 defaults,errors=remount-ro 0 0 #/dev/sda2 none swap sw 0 0 /dev/sda3 / ext2 defaults,errors=remount-ro 0 0 # proc /proc proc defaults 0 0 The erros is as follows: Boot IO Dependent Code (IODC) revision 144 .... SUCCEEDED! HARD Booted. palo ipl bame@noam Tue Oct 31 14:18:02 MST 2000 0/vmlinux 208896 bytes @ 0x1f78c000 0/palo-cmdline '3/boot/vmlinux TERM=linux Home=/ root=/dev/sda3' /dev/ida1 82 62 1030688 /dev/ida2 f0 1030750 24738 /dev/ida3 83 1055488 1030750 Kernel:partition 3 file /boot/vmlinux ext2 block size 1024 ext2_mount(partition 3) returns 0 ext2_open(/boot/vmlinux)=3 Couldn't gork your kernel executabel format failed to load kernel Failed to load Kernel. Please suggest. From dave@hiauly1.hia.nrc.ca Fri, 3 Nov 2000 15:01:17 -0500 (EST) Date: Fri, 3 Nov 2000 15:01:17 -0500 (EST) From: John David Anglin dave@hiauly1.hia.nrc.ca Subject: testcase for hppa64 gcc bug > I think I know what's going on here. The root of the problem is that > pa-64.h defines an ARG_POINTER_REGNUM that isn't a fixed reg, and isn't > eliminable. The arg_pointer isn't even a call-saved reg. That breaks a > number of places in the compiler. > > So I went down the path of trying to fix things properly by defining > ELIMINABLE_REGS and so on, but I ended in a maze of twisty little passages > labelled "Unrecognizable instruction", like this one: > > /src/parisc/gcc/gcc/libgcc2.c: In function `__moddi3': > /src/parisc/gcc/gcc/libgcc2.c:601: Unrecognizable insn: > (insn 1289 209 1298 (set (reg:SI 50 %fr22) > (subreg:SI (plus:DI (reg:DI 30 %r30) > (const_int -272 [0xfffffef0])) 0)) -1 (nil) > (nil)) > /src/parisc/gcc/gcc/libgcc2.c:601: Internal compiler error in > extract_insn, at recog.c:2134 I am making progress in trying to make the arg_pointer register eliminable. I have fixed the above problem. What was happening was that reload_as_needed was incorrectly trying to eliminate the return from millicode calls which is also register r29. I have figured out how to hide it from reload with unspec. However, the compiler is now too good at eliminating the arg_pointer. At -O3, it completely eliminates the arg_pointer. However, as I read the ABI, the call must always set the arg_pointer before calls. Dave -- J. David Anglin dave.anglin@nrc.ca National Research Council of Canada (613) 990-0752 (FAX: 952-6605) From bame@noam.fc.hp.com Fri, 03 Nov 2000 13:30:16 -0700 Date: Fri, 03 Nov 2000 13:30:16 -0700 From: Paul Bame bame@noam.fc.hp.com Subject: [parisc-linux] Boot command = ext2_open(/boot/vmlinux)=3 = Couldn't gork your kernel executabel format failed to load kernel = Failed to load Kernel. That should be "grok" :-) Apparently you're not using cut/paste for these error messages. This is PALO saying that /boot/vmlinux is neither elf32, elf64, nor SOM format. I'm guessing, based on some earlier advice I gave when you were net-booting, that you may have a lifimage there by mistake -- you need a kernel instead, for example from ftp://puffin.external.hp.com/pub/parisc/binaries/kernels To tell for sure, run 'file vmlinux' on that file. If you get vmlinux: 8086 relocatable (Microsoft) that's probably a lifimage. You should get this instead: vmlinux: ELF 32-bit MSB executable, PA-RISC, version 1, statically linked, not stripped -P From kailasr@webcash.com Fri, 03 Nov 2000 14:59:29 -0800 Date: Fri, 03 Nov 2000 14:59:29 -0800 From: Kailashnath V Rampure kailasr@webcash.com Subject: [parisc-linux] Boot command Thanks! Paul. Yes I had copied the lifImage there. Now I have downloaded the kernel from the link you mentioned. I am still unable to use vi as it says "linux:unknown terminal type" Can you help me. To add features can I add deb packages. I am not that familiar with debian. Actually I want to build an apache + mod_ssl+mod_perl on A180c. Regards Kailas At 01:30 PM 11/3/00 -0700, Paul Bame wrote: >= ext2_open(/boot/vmlinux)=3 >= Couldn't gork your kernel executabel format failed to load kernel >= Failed to load Kernel. > >That should be "grok" :-) Apparently you're not using cut/paste for >these error messages. > >This is PALO saying that /boot/vmlinux is neither elf32, elf64, nor SOM >format. I'm guessing, based on some earlier advice I gave when you >were net-booting, that you may have a lifimage there by mistake -- you >need a kernel instead, for example from >ftp://puffin.external.hp.com/pub/parisc/binaries/kernels > >To tell for sure, run 'file vmlinux' on that file. If you get > vmlinux: 8086 relocatable (Microsoft) >that's probably a lifimage. You should get this instead: > vmlinux: ELF 32-bit MSB executable, PA-RISC, version 1, statically > linked, not stripped > > > -P From randolph@tausq.org Sat, 4 Nov 2000 18:02:03 -0700 Date: Sat, 4 Nov 2000 18:02:03 -0700 From: Randolph Chung randolph@tausq.org Subject: [parisc-linux] ldd segfaulting? I think this may be related to what bdale has been seeing... frodo:~# cat test.c int main(int a, char **b) { return 0; } frodo:~# gcc -o test test.c frodo:~# ./test frodo:~# ldd ./test do_page_fault() pid=144 command='ld.so.1' YZrvWESTHLNXBCVMcbcbcbcbOGFRQPDI PSW: 00000000000001001000000100001011 r0-3 00000000 2aac367c 2aaacd67 2aaaa2f0 r4-7 2aac367c 2aaab4e8 2aac3622 2aac02b8 r8-11 20020048 2aaaccb8 2aaaa2f0 00000000 r12-15 00000081 00000080 200201e8 2001fe10 r16-19 00000000 00000000 00000000 2aac367c r20-23 00000000 2aaaa000 2aaaa000 00000041 r24-27 2aaaa000 70000021 20020048 00076b50 r28-31 00000021 20020048 200202c0 2aaacd1b sr0-4 00000000 00002003 00000000 00002003 sr4-8 00002003 00002003 00002003 00002003 IASQ: 00002003 00002003 IAOQ: 2aaadc63 2aaadc67 IIR: 0ce61280 ISR: 00002003 IOR: 2aac02b8 ORIG_R28: 00086350 do_page_fault() pid=145 command='ld.so.1' YZrvWESTHLNXBCVMcbcbcbcbOGFRQPDI PSW: 00000000000001001000000100001011 r0-3 00000000 2aac367c 2aaacd67 2aaaa2f0 r4-7 2aac367c 2aaab4e8 2aac3622 2aac02b8 r8-11 20020048 2aaaccb8 2aaaa2f0 00000000 r12-15 00000081 00000080 200201e8 2001fe10 r16-19 00000000 00000000 00000000 2aac367c r20-23 00000000 2aaaa000 2aaaa000 00000041 r24-27 2aaaa000 70000021 20020048 00076b50 r28-31 00000021 20020048 200202c0 2aaacd1b sr0-4 00000000 00002003 00000000 00002003 sr4-8 00002003 00002003 00002003 00002003 IASQ: 00002003 00002003 IAOQ: 2aaadc63 2aaadc67 IIR: 0ce61280 ISR: 00002003 IOR: 2aac02b8 ORIG_R28: 00090190 ldd: /lib/ld.so.1 exited with unknown exit code (139) frodo:~# gcc --version 2.96 frodo:~# ldd --version ldd (GNU libc) 2.1.95 Copyright (C) 1999 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. Written by Roland McGrath and Ulrich Drepper. frodo:~# Any ideas what's going on? I've tried this both with a Oct26 kernel and one that is from cvs today. Same results. randolph -- @..@ http://www.TauSq.org/ (----) ( >__< ) ^^ ~~ ^^ From alan@linuxcare.com.au Sun, 5 Nov 2000 16:02:43 +1100 (EST) Date: Sun, 5 Nov 2000 16:02:43 +1100 (EST) From: Alan Modra alan@linuxcare.com.au Subject: [parisc-linux] ldd segfaulting? On Sat, 4 Nov 2000, Randolph Chung wrote: > frodo:~# ldd ./test > > do_page_fault() pid=144 command='ld.so.1' Most likely a case of new kernel, ld.so compiled with old gcc. Old is earlier than 25th Oct. Before that gcc put plabels, which need relocating, in .rodata, which is mapped read-only. The new kernel enforces the read-only mapping, so you run into problems when ld.so tries to relocate itself. Fortunately, you only need recompile glibc with a new gcc. Older binaries with plabels in .rodata are handled OK as ld.so re-maps the segments read/write, something it doesn't manage to do for itself. Alan Modra -- Linuxcare. Support for the Revolution. From bdale@gag.com Sat, 04 Nov 2000 23:16:29 -0700 Date: Sat, 04 Nov 2000 23:16:29 -0700 From: Bdale Garbee bdale@gag.com Subject: [parisc-linux] compiler bug? In the build of util-linux, compilation of fdisk/fdiskbsdlabel.c fails as shown below. I have placed "gcc -E" output on pehc in ~bdale/fdiskbsdlabel.E for reference. Hacking the makefiles to remove "-O -O2" allows the compile to complete cleanly. I assume this means something in the compiler is broken? Bdale bdale@j5k:/space/debian/util-linux-2.10o/fdisk $ cc -c -O -O2 -fomit-frame-pointer -I../lib -Wall -Wmissing-prototypes -Wstrict-prototypes -DNCH=1 -DSBINDIR=\"/sbin\" -DUSRSBINDIR=\"/usr/sbin\" -DLOGDIR=\"/var/log\" -DVARPATH=\"/var\" -DLOCALEDIR=\"/usr/share/locale\" fdiskbsdlabel.c -o fdiskbsdlabel.o /usr/include/linux/string.h:12: parse error before "__extension__" /usr/include/linux/string.h:12: parse error before '&&' token /usr/include/linux/string.h:14: parse error before "__extension__" /usr/include/linux/string.h:14: parse error before '(' token /usr/include/linux/string.h:15: parse error before "__extension__" /usr/include/linux/string.h:15: parse error before '&&' token /usr/include/linux/string.h:24: parse error before "__extension__" /usr/include/linux/string.h:27: parse error before "__extension__" /usr/include/linux/string.h:33: parse error before "__extension__" /usr/include/linux/string.h:36: parse error before "__extension__" /usr/include/linux/string.h:36: parse error before '&&' token /usr/include/linux/string.h:36: parse error before '}' token /usr/include/linux/string.h:36: conflicting declarations of `__result' /usr/include/linux/string.h:36: `__result' previously declared here /usr/include/linux/string.h:36: parse error before ')' token /usr/include/linux/string.h:36: `__s2' undeclared here (not in a function) /usr/include/linux/string.h:36: parse error before ';' token /usr/include/linux/string.h:36: conflicting declarations of `__result' /usr/include/linux/string.h:36: `__result' previously defined here /usr/include/linux/string.h:36: parse error before '}' token /usr/include/linux/string.h:36: parse error before '}' token /usr/include/linux/string.h:36: redefinition of `__result' /usr/include/linux/string.h:36: `__result' previously defined here /usr/include/linux/string.h:36: `__s1' undeclared here (not in a function) /usr/include/linux/string.h:36: parse error before ')' token /usr/include/linux/string.h:36: parse error before ';' token /usr/include/linux/string.h:36: conflicting declarations of `__result' /usr/include/linux/string.h:36: `__result' previously defined here /usr/include/linux/string.h:36: parse error before '}' token /usr/include/linux/string.h:39: parse error before "__extension__" /usr/include/linux/string.h:39: parse error before '&&' token /usr/include/linux/string.h:39: parse error before '}' token /usr/include/linux/string.h:39: redefinition of `__result' /usr/include/linux/string.h:36: `__result' previously defined here /usr/include/linux/string.h:39: parse error before ')' token /usr/include/linux/string.h:39: `__s2' undeclared here (not in a function) /usr/include/linux/string.h:39: parse error before ';' token /usr/include/linux/string.h:39: conflicting declarations of `__result' /usr/include/linux/string.h:39: `__result' previously defined here /usr/include/linux/string.h:39: parse error before '}' token /usr/include/linux/string.h:39: parse error before '}' token /usr/include/linux/string.h:39: redefinition of `__result' /usr/include/linux/string.h:39: `__result' previously defined here /usr/include/linux/string.h:39: `__s1' undeclared here (not in a function) /usr/include/linux/string.h:39: parse error before ')' token /usr/include/linux/string.h:39: parse error before ';' token /usr/include/linux/string.h:39: conflicting declarations of `__result' /usr/include/linux/string.h:39: `__result' previously defined here /usr/include/linux/string.h:39: parse error before '}' token /usr/include/linux/string.h:45: parse error before "__extension__" /usr/include/linux/string.h:51: parse error before "__extension__" /usr/include/linux/string.h:61: parse error before "__extension__" /usr/include/linux/string.h:61: parse error before '\x0' /usr/include/linux/string.h:61: parse error before '}' token fdiskbsdlabel.c: In function `xbsd_zaplabel': fdiskbsdlabel.c:840: warning: `sector' might be used uninitialized in this function bdale@j5k:/space/debian/util-linux-2.10o/fdisk $ From alan@linuxcare.com.au Sun, 5 Nov 2000 18:41:54 +1100 (EST) Date: Sun, 5 Nov 2000 18:41:54 +1100 (EST) From: Alan Modra alan@linuxcare.com.au Subject: [parisc-linux] compiler bug? On Sat, 4 Nov 2000, Bdale Garbee wrote: > Hacking the makefiles to remove "-O -O2" allows the compile to complete > cleanly. glibc includes are "smart", and do things like `#if defined __OPTIMIZE__' > I assume this means something in the compiler is broken? No, I think it's a problem with glibc, or perhaps just your include files. > bdale@j5k:/space/debian/util-linux-2.10o/fdisk $ cc -c -O -O2 -fomit-frame-pointer -I../lib -Wall -Wmissing-prototypes -Wstrict-prototypes -DNCH=1 -DSBINDIR=\"/sbin\" -DUSRSBINDIR=\"/usr/sbin\" -DLOGDIR=\"/var/log\" -DVARPATH=\"/var\" -DLOCALEDIR=\"/usr/share/locale\" fdiskbsdlabel.c -o fdiskbsdlabel.o > /usr/include/linux/string.h:12: parse error before "__extension__" Your .i file had this in it: extern char * ___strtok; extern char * __extension__ ({ char __a0, __a1, __a2; [rest snipped] which comes from linux/string.h extern char * ___strtok; extern char * strcpy(char *,const char *); The problem being that strcpy is being replaced with an inline expansion. Dunno why this is happenning. Alan Modra -- Linuxcare. Support for the Revolution. From xam@sgate.charlysworld.de Mon, 6 Nov 2000 01:14:41 +0100 (CET) Date: Mon, 6 Nov 2000 01:14:41 +0100 (CET) From: xam@deathsdoor.com xam@sgate.charlysworld.de Subject: [parisc-linux] HP9000/730 boot problems Hi all, i have an HP9000/730 (66.6MHz, 32MB RAM, 10MBit Network, CRX graphics, HIL keyboard & mouse, HP 535MBM SCSI HD). I got the latest nfsroot, the latest xc and the palo sources from puffin.external.hp.com. the parition scheme for the HD (id 6) is /dev/sdb1 swap 128MB /dev/sdb2 f0 10MB /dev/sdb3 ext2 rest i untarred nfsroot on /dev/sdb3 and changed /etc/fstab accordingly i installed palo with the following command /opt/palinux/palo-src/palo/palo -I -k /hydra/hppa/boot/vmlinux -b /opt/palinux/palo-src/iplboot -c '3/boot/vmlinux TERM=linux HOME=/ root=/dev/sdb3' /dev/sdb well, i used /dev/sdb since there is also the scsi fd (id 0) that is /dev/sda IMHO (i tested alos to use root=/dev/sda3 btw). some of the boot messages PDC ROM rev. 2.1 IODC ROM rev. 2.1 32 MB of memory configured and tested. Selecting a system to boot. Hard booted. [...] now it prints the palo configuration as i installed it and the hd partition scheme (but /dev/idaXYZ instead of /dev/sdbXYZ [...] ext2 block size 1024 ext2_open(/boot/vmlinux) = 3 ext2_mount(partition 3) returns 0 ELF32 executable [...] now all recognized devices (SGC craphics, BA, HIL, LAN, 2x RS232, SCSI, EISA, Core Centronics, HP model 'king Cobra' ...) the kernel boots actually, but i dumps the stack register and the processor registers (not included in this mail) after ASP version 1 at ..... found thats all. no message like 'unable to boot root fs' or something ... any help ? PS: i tried to use a IBM0664 2.0GB scsi hd before (works fine on linux/ia32), but i couldn't get it work on hp (i reported this in a former mail). PPS: just FYI: the same configuration worked with HP/UX 10.10 From grundler@cup.hp.com Sun, 05 Nov 2000 17:21:12 -0800 Date: Sun, 05 Nov 2000 17:21:12 -0800 From: Grant Grundler grundler@cup.hp.com Subject: [parisc-linux] HP9000/730 boot problems "xam@deathsdoor.com" wrote: > Hi all, > > i have an HP9000/730 (66.6MHz, 32MB RAM, 10MBit Network, CRX graphics, > HIL keyboard & mouse, HP 535MBM SCSI HD). > > I got the latest nfsroot, the latest xc and the palo sources from > puffin.external.hp.com. > > the parition scheme for the HD (id 6) is > > /dev/sdb1 swap 128MB > /dev/sdb2 f0 10MB > /dev/sdb3 ext2 rest > > i untarred nfsroot on /dev/sdb3 and changed /etc/fstab accordingly > i installed palo with the following command > > /opt/palinux/palo-src/palo/palo -I -k /hydra/hppa/boot/vmlinux -b > /opt/palinux/palo-src/iplboot -c '3/boot/vmlinux TERM=linux HOME=/ > root=/dev/sdb3' /dev/sdb > > > well, i used /dev/sdb since there is also the scsi fd (id 0) > that is /dev/sda IMHO (i tested alos to use root=/dev/sda3 btw). using /dev/sdb is ok - your palo command looks "right" to me. > [...] > now it prints the palo configuration as i installed it > and the hd partition scheme (but /dev/idaXYZ instead of /dev/sdbXYZ > [...] > ext2 block size 1024 > ext2_open(/boot/vmlinux) = 3 > ext2_mount(partition 3) returns 0 > ELF32 executable This looks like palo loading the vmlinux. > [...] > > now all recognized devices (SGC craphics, BA, HIL, LAN, 2x RS232, SCSI, > EISA, Core Centronics, HP model 'king Cobra' ...) > > the kernel boots actually, but i dumps the stack register and the > processor registers (not included in this mail) after > > ASP version 1 at ..... found Sounds like ASP support may be broken. The way to find out where IOAQ and GR2 registers are pointing. They should point to functions in System.map. Who is maintaining ASP support? > PS: i tried to use a IBM0664 2.0GB scsi hd before (works fine on > linux/ia32), but i couldn't get it work on hp (i reported this > in a former mail). Right. I'm pretty sure older PDC/IODC doesn't send START_UNIT command to the disk drive. The boot drive is expected to spin up on it's own. I don't know if newer PDC does send START_UNIT either... grant Grant Grundler Unix Systems Enablement Lab +1.408.447.7253 From grundler@cup.hp.com Sun, 5 Nov 2000 18:18:35 -0800 (PST) Date: Sun, 5 Nov 2000 18:18:35 -0800 (PST) From: Grant Grundler grundler@cup.hp.com Subject: [parisc-linux] string.h warnings When linux/arch/parisc/kernel/pci.c built, I get the following warnings: /linux/kwdb64/linux/include/linux/string.h:54: warning: conflicting types for built-in function `strlen' /linux/kwdb64/linux/include/linux/string.h:61: warning: conflicting types for built-in function `memset' /linux/kwdb64/linux/include/linux/string.h:64: warning: conflicting types for built-in function `memcpy' /linux/kwdb64/linux/include/linux/string.h:73: warning: conflicting types for built-in function `memcmp' Could this be related to or shed light on the problem bdale had? thanks, grant From bri@mojo.calyx.net Sun, 5 Nov 2000 21:34:54 -0500 (EST) Date: Sun, 5 Nov 2000 21:34:54 -0500 (EST) From: Brian S. Julin bri@mojo.calyx.net Subject: [parisc-linux] string.h warnings On Sun, 5 Nov 2000, Grant Grundler wrote: > When linux/arch/parisc/kernel/pci.c built, I get the following > warnings: > /linux/kwdb64/linux/include/linux/string.h:54: warning: conflicting types for built-in function `strlen' > /linux/kwdb64/linux/include/linux/string.h:61: warning: conflicting types for built-in function `memset' > /linux/kwdb64/linux/include/linux/string.h:64: warning: conflicting types for built-in function `memcpy' > /linux/kwdb64/linux/include/linux/string.h:73: warning: conflicting types for built-in function `memcmp' For some reason I had numerous problems with string.h not being included when building ncurses natively with the nfsroot tarball. (Also the nfsroot tarball seems to not be able to find the crt* objects by default) -- Brian S. Julin From jsm@udlkern.fc.hp.com Sun, 5 Nov 2000 23:12:56 -0700 (MST) Date: Sun, 5 Nov 2000 23:12:56 -0700 (MST) From: John Marvin jsm@udlkern.fc.hp.com Subject: [parisc-linux] HP 9000/730 boot problem "xam@deathsdoor.com" wrote: > > the kernel boots actually, but i dumps the stack register and the > processor registers (not included in this mail) after > > ASP version 1 at ..... found Grant Grundler wrote: > Sounds like ASP support may be broken. > The way to find out where IOAQ and GR2 registers are pointing. > They should point to functions in System.map. > Who is maintaining ASP support? No, the parallel port support for ASP is broken. If you disable the LASI/ASP builtin parallel-port support (CONFIG_PARPORT_GSC) you will get further. I can't guarantee you will succeed, but others have reported some success on boxes almost that old. This is at least the second time this question has come up, so I guess I'll add it to the FAQ and todo lists. John Marvin jsm@fc.hp.com From marteaut@esiee.fr Tue, 7 Nov 2000 17:00:48 +0100 Date: Tue, 7 Nov 2000 17:00:48 +0100 From: Thomas Marteau marteaut@esiee.fr Subject: [parisc-linux] A browser and a new URL for the ESIEE team web site Hi all, We have succeded to compile Lynx on a 712 and it works well. Also this short mail must tell you that our website can be reached with http://www.esiee.fr/puffin You can find a cool root FS which has the terminfo directory like that you won't have the "vt100:unknown term" message, the network support and lot of thing like that... Bye, ESIEE Team Don't hesitate to visit our website From kailasr@webcash.com Tue, 07 Nov 2000 09:46:53 -0800 Date: Tue, 07 Nov 2000 09:46:53 -0800 From: Kailashnath V Rampure kailasr@webcash.com Subject: [parisc-linux] Boot command Hi, Thanks. I copied the termcap and terminfo directory froma red hat linux box. Now I am able to run VI and the TERM is vt100. Regards Kailas At 02:56 PM 11/5/00 +0100, Thierry SIMONNET wrote: >To have a suitable TERM, you must get termcap or terminfo definition; ie a >good terminfo tree from a linux box. To have a good method to install a >pa/linux box, see my student's web site at http://www.esiee.fr/~djoudim > >Th. SIMONNET > > >Kailashnath V Rampure wrote: > > > Thanks! Paul. > > Yes I had copied the lifImage there. Now I have downloaded the kernel from > > the link you mentioned. > > > > I am still unable to use vi as it says "linux:unknown terminal type" > > Can you help me. > > > > To add features can I add deb packages. I am not that familiar with debian. > > Actually I want to build an apache + mod_ssl+mod_perl on A180c. > > Regards > > Kailas > > > > At 01:30 PM 11/3/00 -0700, Paul Bame wrote: > > >= ext2_open(/boot/vmlinux)=3 > > >= Couldn't gork your kernel executabel format failed to load kernel > > >= Failed to load Kernel. > > > > > >That should be "grok" :-) Apparently you're not using cut/paste for > > >these error messages. > > > > > >This is PALO saying that /boot/vmlinux is neither elf32, elf64, nor SOM > > >format. I'm guessing, based on some earlier advice I gave when you > > >were net-booting, that you may have a lifimage there by mistake -- you > > >need a kernel instead, for example from > > >ftp://puffin.external.hp.com/pub/parisc/binaries/kernels > > > > > >To tell for sure, run 'file vmlinux' on that file. If you get > > > vmlinux: 8086 relocatable (Microsoft) > > >that's probably a lifimage. You should get this instead: > > > vmlinux: ELF 32-bit MSB executable, PA-RISC, version 1, statically > > > linked, not stripped > > > > > > > > > -P > > > > --------------------------------------------------------------------------- > > To unsubscribe: send e-mail to parisc-linux-request@thepuffingroup.com with > > `unsubscribe' as the subject. From bame@noam.fc.hp.com Tue, 07 Nov 2000 11:15:50 -0700 Date: Tue, 07 Nov 2000 11:15:50 -0700 From: Paul Bame bame@noam.fc.hp.com Subject: [parisc-linux] 64-bit BUILD CHANGES The described changes have just been committed to CVS. If you have an existing configured/built 64-bit parisc tree right now I think these are the steps to update: Save your .config file do 'make distclean' do your cvs update restore your .config make oldconfig dep and then proceed as normal The symlinks come when you do a make {old}config and go with a 'make distclean' FYI >>> You may want to start hand-editing .hdepend (following each make dep) to remove the dependency of atomic.h on spinlock.h (just remove the first line containing the string spinlock.h) -- it can cause massive unnecessary rebuilds. It's due to a parisc-specific circular dependency :-( -P = I want to propose/discuss a new method for maintaining our 64-bit parisc = tree in relation to the 32-bit tree. I have prototyped this and so = far it seems pretty useful. = = Most of the files in the current parisc64 tree only contain one = line, a #include of the same file from the parisc tree. This confuses = 'make dep', causes some compile errors to have nonsense line numbers, = and doesn't allow direct editing of the source files in the parisc64 tree. = = The method I'm proposing works like this: = = The future parisc64 tree ONLY contains files which are different from, = or in addition to, those in the parisc tree. When you 'make config' = or 'make oldconfig', each file in the parsic tree is symbolically = linked as the same file in the parisc64 tree. This enables all = the rest of the tools/build to work normally. 'make distclean' includes = a step to remove all the symlinks. = = The ugliest "feature" is that even though you can edit source files = in the parisc64 tree, 'cvs commit' will fail on those which are = symbolic links. To reduce this problem, I'm dropping a symbolic link = called '...' in each parisc64 directory which is a pointer to the = corresponding parisc directory, so 'cd ...; cvs commit foo.c' will = work and not be too onerous. = = We should additionally consider a naming convention or something so = that maintainers in the parisc tree know whether files are shared with = parisc64 or not. = = I prototyped this as a fictional new "architecture" called "p64". To = try it out, grab the tarball (only about 30 files -- can be fewer) = ftp://puffin.external.hp.com/pub/parisc/ = and unpack in your top-level linux source tree directory. Then in = your top-level Makefile, change ARCH := parisc64 to ARCH := p64, then = make oldconfig or whatever you usually do. Let me know of any problems. = = Is this something we should adopt for the real parisc64 tree? = = -Paul Bame = = --------------------------------------------------------------------------- = To unsubscribe: send e-mail to parisc-linux-request@thepuffingroup.com with = `unsubscribe' as the subject. = = = From grundler@cup.hp.com Tue, 07 Nov 2000 11:19:02 -0800 Date: Tue, 07 Nov 2000 11:19:02 -0800 From: Grant Grundler grundler@cup.hp.com Subject: [parisc-linux] Boot command Kailashnath V Rampure wrote: > Hi, > Thanks. I copied the termcap and terminfo directory froma red hat linux > box. Now I am able to run VI and the TERM is vt100. I've added a "vi is complaining" item to the FAQ. Normally the FAQ lives at http://www.thepuffingroup.com/parisc/faq.html but it's not updated yet. I've put a temporary copy at http://puffin.external.hp.com/~grundler/faq.html and will remove this once the regular location is updated. (Hint - relative links won't work from my copy) grant Grant Grundler Unix Systems Enablement Lab +1.408.447.7253 From marteaut@esiee.fr Tue, 7 Nov 2000 20:53:55 +0100 Date: Tue, 7 Nov 2000 20:53:55 +0100 From: Thomas Marteau marteaut@esiee.fr Subject: [parisc-linux] Boot command ----- Original Message ----- From: Grant Grundler To: Kailashnath V Rampure Cc: Sent: Tuesday, November 07, 2000 8:19 PM Subject: Re: [parisc-linux] Boot command > Kailashnath V Rampure wrote: > > Hi, > > Thanks. I copied the termcap and terminfo directory froma red hat linux > > box. Now I am able to run VI and the TERM is vt100. > > I've added a "vi is complaining" item to the FAQ. To use vi and all these applications like top, they need the terminfo directory in /usr/share from any distrib!! Bye, the ESIEE Team From grundler@cup.hp.com Tue, 07 Nov 2000 12:24:39 -0800 Date: Tue, 07 Nov 2000 12:24:39 -0800 From: Grant Grundler grundler@cup.hp.com Subject: [parisc-linux] Boot command "Thomas Marteau" wrote: > Grant Grundler wrote: > > Kailashnat V Rampure wrote: > > > Hi, > > > Thanks. I copied the termcap and terminfo directory froma red hat linux > > > box. Now I am able to run VI and the TERM is vt100. > > > > I've added a "vi is complaining" item to the FAQ. > > To use vi and all these applications like top, they need the terminfo > directory in /usr/share from any distrib!! I didn't say taking from RH was wrong. IMHO, doing so defeats the whole point of debian's packaging system. Please read the new FAQ entry and tell me if I've gotten that right or not. grant Grant Grundler Unix Systems Enablement Lab +1.408.447.7253 From kailasr@webcash.com Tue, 07 Nov 2000 14:50:10 -0800 Date: Tue, 07 Nov 2000 14:50:10 -0800 From: Kailashnath V Rampure kailasr@webcash.com Subject: [parisc-linux] Boot command I agree with you regarding taking from RH. I just wanted to let u all know how I solved the issue. I have gone through the faq it is fine. Regards Kailas At 12:24 PM 11/7/00 -0800, Grant Grundler wrote: >"Thomas Marteau" wrote: > > Grant Grundler wrote: > > > Kailashnat V Rampure wrote: > > > > Hi, > > > > Thanks. I copied the termcap and terminfo directory froma red hat linux > > > > box. Now I am able to run VI and the TERM is vt100. > > > > > > I've added a "vi is complaining" item to the FAQ. > > > > To use vi and all these applications like top, they need the terminfo > > directory in /usr/share from any distrib!! > >I didn't say taking from RH was wrong. >IMHO, doing so defeats the whole point of debian's packaging system. > >Please read the new FAQ entry and tell me if I've gotten >that right or not. > >grant > >Grant Grundler >Unix Systems Enablement Lab >+1.408.447.7253 > >--------------------------------------------------------------------------- >To unsubscribe: send e-mail to parisc-linux-request@thepuffingroup.com with >`unsubscribe' as the subject. From cjknoch@yahoo.com Tue, 7 Nov 2000 15:40:14 -0800 (PST) Date: Tue, 7 Nov 2000 15:40:14 -0800 (PST) From: Christian Knoch cjknoch@yahoo.com Subject: [parisc-linux] HP 9000 e25 hi. i need information about how to install linux on hp 9000 e25 what version on linux what distribution ? how many memoty i need in this machine how many space on disk i need in this machine howto boot machine for install linux Thanks __________________________________________________ Do You Yahoo!? Thousands of Stores. Millions of Products. All in one Place. http://shopping.yahoo.com/ From matthew@wil.cx Wed, 8 Nov 2000 00:28:08 +0000 Date: Wed, 8 Nov 2000 00:28:08 +0000 From: Matthew Wilcox matthew@wil.cx Subject: [parisc-linux] HP 9000 e25 On Tue, Nov 07, 2000 at 03:40:14PM -0800, Christian Knoch wrote: > hi. > i need information about how to install linux on hp > 9000 e25 *sigh*. This is in the FAQ. Where do we need to put links to the FAQ to persuade people to read it? Where did you find this mailing list address, do we need to put a link to the FAQ there? The answer given in the FAQ is: The earliest PA-RISC servers have proprietary HP devices attached to proprietary HP bus architectures. It is unlikely that documentation on these busses and devices will ever become available, since so few people are interested in spending any effort finding and releasing the docs. Machines in this category are the E, F, G, H, I class (aka Nova) and T500 series (Emerald) machines as well as some earlier, unlettered servers. -- Revolutions do not require corporate support. From matthew@wil.cx Wed, 8 Nov 2000 20:14:43 +0000 Date: Wed, 8 Nov 2000 20:14:43 +0000 From: Matthew Wilcox matthew@wil.cx Subject: [parisc-linux] webshite since the lord god alex hasn't seen fit to inform anyone, it seems like i should. the www.thepuffingroup.com website is no longer being updated and all the updates are only going to parisc-linux.org. i have been updating www.thepuffingroup.com becuase no-one told me that this site was no longer supposed to be operational and i suspect a large number of people who subscribe to this list still have it bookmarked. also, email sent to willy@thepuffingroup.com is no longer being received by me. i don't know who gets it, but the sender does not receive a bounce. yours, fucking furious, Matthew. -- "It's time for you to change your sig" -- Alex deVries From grundler@cup.hp.com Wed, 08 Nov 2000 12:31:11 -0800 Date: Wed, 08 Nov 2000 12:31:11 -0800 From: Grant Grundler grundler@cup.hp.com Subject: [parisc-linux] webshite Matthew Wilcox wrote: > > since the lord god alex hasn't seen fit to inform anyone, it seems like > i should. the www.thepuffingroup.com website is no longer being updated > and all the updates are only going to parisc-linux.org. We gave LXC's website maintainer grief about this already. > i have been > updating www.thepuffingroup.comwww.thepuffingroup.com becuase no-one told me that this site > was no longer supposed to be operational and i suspect a large number > of people who subscribe to this list still have it bookmarked. Some time today, I expect (hope?) www.thepuffingroup.com/parisc will be redirected to www.parisc-linux.org (.com works too). I've asked mail be sent to this list when it happens. > also, > email sent to willy@thepuffingroup.com is no longer being received by me. > i don't know who gets it, but the sender does not receive a bounce. This should probably bounce since it's been stale for about 11 monthes now... hope this helps, grant ps. just trying to compensate for an otherwise lack of communication. > > yours, fucking furious, Matthew. > > -- > "It's time for you to change your sig" -- Alex deVries > > --------------------------------------------------------------------------- > To unsubscribe: send e-mail to parisc-linux-request@thepuffingroup.com with > `unsubscribe' as the subject. > Grant Grundler Unix Systems Enablement Lab +1.408.447.7253 From andrew@neep.com.au Thu, 9 Nov 2000 05:13:23 +0800 Date: Thu, 9 Nov 2000 05:13:23 +0800 From: Andrew Shugg andrew@neep.com.au Subject: [parisc-linux] webshite Matthew Wilcox said: > the www.thepuffingroup.com website is no longer being updated and all > the updates are only going to parisc-linux.org. I don't know if there's some other secret mailing list I'm missing out on, but that's the first time I've heard of "parisc-linux.org" I'm sure. So thankyou for being the one to bring it up. Will the mailing list be moving as well? (Given that it belongs with the project, not the mothballed puffingroup website.) > -- > "It's time for you to change your sig" -- Alex deVries Shame, I thought your old sig was funnier. Andrew. -- Andrew Shugg http://www.neep.com.au/ "Just remember, Mr Fawlty, there's always someone worse off than yourself." "Is there? Well I'd like to meet him. I could do with a good laugh." From taggart@carmen.fc.hp.com Wed, 08 Nov 2000 14:22:03 -0700 Date: Wed, 08 Nov 2000 14:22:03 -0700 From: Matt Taggart taggart@carmen.fc.hp.com Subject: [parisc-linux] webshite Andrew Shugg writes... > I don't know if there's some other secret mailing list I'm missing out > on, but that's the first time I've heard of "parisc-linux.org" I'm sure. > So thankyou for being the one to bring it up. It was never officially announced, just setup. I guess this is the announcement. > Will the mailing list be moving as well? (Given that it belongs with > the project, not the mothballed puffingroup website.) Yes, most of the project's web/mail resources will be moving there shortly. Go ahead and update your bookmarks. I've been told there will be a pointer/redirect from the old site but I wouldn't count on it existing forever. -- Matt Taggart taggart@fc.hp.com From andrew@neep.com.au Thu, 9 Nov 2000 05:48:06 +0800 Date: Thu, 9 Nov 2000 05:48:06 +0800 From: Andrew Shugg andrew@neep.com.au Subject: [parisc-linux] HP 9000 e25 Matthew Wilcox said: > On Tue, Nov 07, 2000 at 03:40:14PM -0800, Christian Knoch wrote: > > hi. > > i need information about how to install linux on hp > > 9000 e25 > > *sigh*. This is in the FAQ. Where do we need to put links to the FAQ > to persuade people to read it? Where did you find this mailing list > address, do we need to put a link to the FAQ there? I think the fault lies in the "Contact" page, new (!) URL being: http://parisc-linux.org/contact.html "Most questions about the port should be addressed to the developer mailing list parisc-linux@thepuffingroup.com" I would suggest this page be changed a bit, like stick the mailing list down the bottom and change it to a link to the mailing list subscribe and browse-the-archives page, rather than simply the address of the list. Also a comment about reading the FAQ. Yes, the FAQ is in the left-hand side-bar but you can never over-do the help. =) One of my favourite comments along that line was on the windowmaker.org home page (sadly it has been removed). It was something like "Please bear in mind that asking questions on the mailing list that are answered in the FAQ is NOT A GOOD IDEA." The FAQ on parisc-linux.org is also missing the all-important Q/A pair: Q. I have a question that isn't answered in this FAQ? A. Please subscribe to the [mailing list] and ask. Politely. Preferably in English, or (failing that) in a recognisable pidgin. Don't hold back on the relevant information either. "It won't boot" is not good. Andrew. -- Andrew Shugg http://www.neep.com.au/ "Just remember, Mr Fawlty, there's always someone worse off than yourself." "Is there? Well I'd like to meet him. I could do with a good laugh." From jvinet@linuxcare.com Wed, 08 Nov 2000 17:41:50 -0500 Date: Wed, 08 Nov 2000 17:41:50 -0500 From: Jane Vinet jvinet@linuxcare.com Subject: [parisc-linux] HP 9000 e25 Good advice...will notify the web design folks. Jane -- jvinet@linuxcare.com Andrew Shugg wrote: > I would suggest this page be changed a bit, like stick the mailing list > down the bottom and change it to a link to the mailing list subscribe > and browse-the-archives page, rather than simply the address of the > list. Also a comment about reading the FAQ. Yes, the FAQ is in the > left-hand side-bar but you can never over-do the help. =) > > One of my favourite comments along that line was on the windowmaker.org > home page (sadly it has been removed). It was something like "Please > bear in mind that asking questions on the mailing list that are answered > in the FAQ is NOT A GOOD IDEA." > > The FAQ on parisc-linux.org is also missing the all-important Q/A pair: > > Q. I have a question that isn't answered in this FAQ? > A. Please subscribe to the [mailing list] and ask. Politely. Preferably > in English, or (failing that) in a recognisable pidgin. Don't hold back > on the relevant information either. "It won't boot" is not good. > > Andrew. > > -- > Andrew Shugg http://www.neep.com.au/ > > "Just remember, Mr Fawlty, there's always someone worse off than yourself." > "Is there? Well I'd like to meet him. I could do with a good laugh." > > --------------------------------------------------------------------------- > To unsubscribe: send e-mail to parisc-linux-request@thepuffingroup.com with > `unsubscribe' as the subject. From matthew@wil.cx Thu, 9 Nov 2000 09:59:58 +0000 Date: Thu, 9 Nov 2000 09:59:58 +0000 From: Matthew Wilcox matthew@wil.cx Subject: [parisc-linux] webshite On Thu, Nov 09, 2000 at 05:13:23AM +0800, Andrew Shugg wrote: > Matthew Wilcox said: > > the www.thepuffingroup.com website is no longer being updated and all > > the updates are only going to parisc-linux.org. > > I don't know if there's some other secret mailing list I'm missing out > on, but that's the first time I've heard of "parisc-linux.org" I'm sure. > So thankyou for being the one to bring it up. oh, alex secretly went off and registered it. the first we heard about it was in a press release a couple of months ago. for a while it's been a (broken) redirect to www.thepuffingroup.com/parisc. there's a linuxcare internal mailing list for discussions of the parisc project, but it wasn't mentioned on there either. > Will the mailing list be moving as well? (Given that it belongs with > the project, not the mothballed puffingroup website.) no idea. alex is playing politics and he's not very good at it. personally, i think everything should be moved to puffin.external.hp.com and parisc-linux.org should just redirect to it, but that wouldn't fit with the aforementioned political games. > > -- > > "It's time for you to change your sig" -- Alex deVries > > Shame, I thought your old sig was funnier. oh, i just thought that was a more appropriate sig for the circumstances, I haven't changed permanently. -- Revolutions do not require corporate support. From matthew@wil.cx Thu, 9 Nov 2000 10:06:27 +0000 Date: Thu, 9 Nov 2000 10:06:27 +0000 From: Matthew Wilcox matthew@wil.cx Subject: [parisc-linux] webshite On Wed, Nov 08, 2000 at 12:31:11PM -0800, Grant Grundler wrote: > Matthew Wilcox wrote: > > also, > > email sent to willy@thepuffingroup.com is no longer being received by me. > > i don't know who gets it, but the sender does not receive a bounce. > > This should probably bounce since it's been stale for about > 11 monthes now... um, it was my email address until about 3 months ago. at least one person still had that as their preferred email address for me. if anyone else does, they should probably change it. it's the lack of bounce which concerns me, which implies that someone's receiving it, reading mail destined for me and not forwarding it on. -- Revolutions do not require corporate support. From dave@hiauly1.hia.nrc.ca Thu, 9 Nov 2000 12:39:57 -0500 (EST) Date: Thu, 9 Nov 2000 12:39:57 -0500 (EST) From: John David Anglin dave@hiauly1.hia.nrc.ca Subject: testcase for hppa64 gcc bug > > So I went down the path of trying to fix things properly by defining > > ELIMINABLE_REGS and so on, but I ended in a maze of twisty little passages > > labelled "Unrecognizable instruction", like this one: > > > > /src/parisc/gcc/gcc/libgcc2.c: In function `__moddi3': > > /src/parisc/gcc/gcc/libgcc2.c:601: Unrecognizable insn: > > (insn 1289 209 1298 (set (reg:SI 50 %fr22) > > (subreg:SI (plus:DI (reg:DI 30 %r30) > > (const_int -272 [0xfffffef0])) 0)) -1 (nil) > > (nil)) > > /src/parisc/gcc/gcc/libgcc2.c:601: Internal compiler error in > > extract_insn, at recog.c:2134 > > I am making progress in trying to make the arg_pointer register eliminable. > I have fixed the above problem. What was happening was that reload_as_needed > was incorrectly trying to eliminate the return from millicode calls which > is also register r29. I have figured out how to hide it from reload with > unspec. > > However, the compiler is now too good at eliminating the arg_pointer. At > -O3, it completely eliminates the arg_pointer. However, as I read the ABI, > the call must always set the arg_pointer before calls. For the record, here is my final patch regarding making the arg_pointer eliminable for TARGET_64BIT. I think the code it generates is correct but it hasn't been extensively tested. However, I don't recommend it for installation since in comparing the assembler code generated with and without elimination for a couple of test cases, I didn't observe any significant improvement in the code with the patch. Possibly, the patch implicitly disables elimination when the arg_pointer is needed. I do find that Alan Modra's ARG_POINTER_INVARIANT patch needs to be installed to get correct code with his test case. There is one part of the patch below which I think needs to be installed. That is (call, call_value): Always USE the arg_pointer for TARGET_64BIT. The use for the arg_pointer needs to be pulled out of the `if (flag_pic)'. Dave -- J. David Anglin dave.anglin@nrc.ca National Research Council of Canada (613) 990-0752 (FAX: 952-6605) 2000-11-07 John David Anglin * pa-linux64.h (ARG_POINTER_INVARIANT): Define even when the arg_pointer is being eliminated. (ELIMINABLE_REGS): Enable elimination of the arg_pointer. (INITIAL_ELIMINATION_OFFSET): Revise offsets for arg_pointer. * pa.md (mulsi3, divsi3, udivsi3, modsi3, umodsi3 and canonicalize_funcptr_for_compare): Put "(reg:SI 26)" inside unspec to prevent elimination. (call, call_value): Always USE the arg_pointer for TARGET_64BIT. Use the new addmovdi3 insn to load the arg_pointer register. (addmovdi3 and mov_from_r29_si): New insn and expand which prevent r29 from being eliminated in call setups and millicode returns. --- pa-linux64.h.orig Tue Oct 31 18:38:24 2000 +++ pa-linux64.h Tue Nov 7 12:17:12 2000 @@ -209,21 +209,18 @@ that grow to lower addresses. What fun. */ #undef ARGS_GROW_DOWNWARD #undef ARG_POINTER_REGNUM -#define ARG_POINTER_INVARIANT 0 #define ARG_POINTER_REGNUM 29 +#define ARG_POINTER_INVARIANT 0 #undef STATIC_CHAIN_REGNUM #define STATIC_CHAIN_REGNUM 31 -#if 1 -#define ARG_POINTER_INVARIANT 0 -#else -/* If defined, this macro specifies a table of register pairs used to eliminate - unneeded registers that point into the stack frame. */ +/* If defined, this macro specifies a table of register pairs used to + eliminate unneeded registers that point into the stack frame. */ #define ELIMINABLE_REGS \ { \ - {ARG_POINTER_REGNUM, STACK_POINTER_REGNUM}, \ {FRAME_POINTER_REGNUM, STACK_POINTER_REGNUM}, \ + {ARG_POINTER_REGNUM, STACK_POINTER_REGNUM}, \ {ARG_POINTER_REGNUM, FRAME_POINTER_REGNUM}, \ } @@ -240,19 +237,18 @@ #define INITIAL_ELIMINATION_OFFSET(FROM, TO, OFFSET) \ do \ { \ - int fsize; \ + int fsize = compute_frame_size (get_frame_size (), 0); \ \ if ((TO) == FRAME_POINTER_REGNUM \ && (FROM) == ARG_POINTER_REGNUM) \ { \ - (OFFSET) = - current_function_pretend_args_size - 16; \ + (OFFSET) = fsize + 48 - current_function_outgoing_args_size; \ break; \ } \ \ if ((TO) != STACK_POINTER_REGNUM) \ abort (); \ \ - fsize = compute_frame_size (get_frame_size (), 0); \ switch (FROM) \ { \ case FRAME_POINTER_REGNUM: \ @@ -260,14 +256,13 @@ break; \ \ case ARG_POINTER_REGNUM: \ - (OFFSET) = - fsize - current_function_pretend_args_size - 16; \ + (OFFSET) = 48 - current_function_outgoing_args_size; \ break; \ \ default: \ abort (); \ } \ } while (0) -#endif #undef SELECT_RTX_SECTION #define SELECT_RTX_SECTION(MODE,RTX) \ --- pa.md.orig Tue Nov 7 13:50:34 2000 +++ pa.md.work Wed Nov 8 14:06:05 2000 @@ -3993,7 +3993,7 @@ (clobber (reg:SI 26)) (clobber (reg:SI 25)) (clobber (reg:SI 31))]) - (set (match_operand:SI 0 "general_operand" "") (reg:SI 29))] + (set (match_operand:SI 0 "general_operand" "") (unspec:SI [(reg:SI 29)] 0))] "" " { @@ -4139,7 +4139,7 @@ (clobber (reg:SI 26)) (clobber (reg:SI 25)) (clobber (reg:SI 31))]) - (set (match_operand:SI 0 "general_operand" "") (reg:SI 29))] + (set (match_operand:SI 0 "general_operand" "") (unspec:SI [(reg:SI 29)] 0))] "" " { @@ -4197,7 +4197,7 @@ (clobber (reg:SI 26)) (clobber (reg:SI 25)) (clobber (reg:SI 31))]) - (set (match_operand:SI 0 "general_operand" "") (reg:SI 29))] + (set (match_operand:SI 0 "general_operand" "") (unspec:SI [(reg:SI 29)] 0))] "" " { @@ -4255,7 +4255,7 @@ (clobber (reg:SI 26)) (clobber (reg:SI 25)) (clobber (reg:SI 31))]) - (set (match_operand:SI 0 "general_operand" "") (reg:SI 29))] + (set (match_operand:SI 0 "general_operand" "") (unspec:SI [(reg:SI 29)] 0))] "" " { @@ -4310,7 +4310,7 @@ (clobber (reg:SI 26)) (clobber (reg:SI 25)) (clobber (reg:SI 31))]) - (set (match_operand:SI 0 "general_operand" "") (reg:SI 29))] + (set (match_operand:SI 0 "general_operand" "") (unspec:SI [(reg:SI 29)] 0))] "" " { @@ -5785,9 +5785,9 @@ op = XEXP (operands[0], 0); if (TARGET_64BIT) - emit_move_insn (arg_pointer_rtx, - gen_rtx_PLUS (word_mode, virtual_outgoing_args_rtx, - GEN_INT (64))); + emit_insn (gen_addmovdi3 (arg_pointer_rtx, + virtual_outgoing_args_rtx, + GEN_INT (64))); /* Use two different patterns for calls to explicitly named functions and calls through function pointers. This is necessary as these two @@ -5809,13 +5809,14 @@ call_insn = emit_call_insn (gen_call_internal_reg (operands[1])); } + if (TARGET_64BIT) + use_reg (&CALL_INSN_FUNCTION_USAGE (call_insn), arg_pointer_rtx); + if (flag_pic) { use_reg (&CALL_INSN_FUNCTION_USAGE (call_insn), pic_offset_table_rtx); use_reg (&CALL_INSN_FUNCTION_USAGE (call_insn), gen_rtx_REG (word_mode, PIC_OFFSET_TABLE_REGNUM_SAVED)); - if (TARGET_64BIT) - use_reg (&CALL_INSN_FUNCTION_USAGE (call_insn), arg_pointer_rtx); /* After each call we must restore the PIC register, even if it doesn't appear to be used. @@ -5961,9 +5962,9 @@ op = XEXP (operands[1], 0); if (TARGET_64BIT) - emit_move_insn (arg_pointer_rtx, - gen_rtx_PLUS (word_mode, virtual_outgoing_args_rtx, - GEN_INT (64))); + emit_insn (gen_addmovdi3 (arg_pointer_rtx, + virtual_outgoing_args_rtx, + GEN_INT (64))); /* Use two different patterns for calls to explicitly named functions and calls through function pointers. This is necessary as these two @@ -5989,6 +5990,10 @@ call_insn = emit_call_insn (gen_call_value_internal_reg (operands[0], operands[2])); } + + if (TARGET_64BIT) + use_reg (&CALL_INSN_FUNCTION_USAGE (call_insn), arg_pointer_rtx); + if (flag_pic) { use_reg (&CALL_INSN_FUNCTION_USAGE (call_insn), pic_offset_table_rtx); @@ -7124,7 +7129,7 @@ (clobber (reg:SI 22)) (clobber (reg:SI 31))]) (set (match_operand:SI 0 "register_operand" "") - (reg:SI 29))] + (unspec:SI [(reg:SI 29)] 0))] "! TARGET_PORTABLE_RUNTIME && !TARGET_64BIT && !TARGET_ELF32" " { @@ -7236,3 +7241,48 @@ emit_insn (gen_blockage ()); DONE; }") + +;; For TARGET_64BIT, the arg_pointer register is also used for millicode +;; returns. The ABI requires that the arg_pointer be set for all calls. +;; When the arg_pointer is made an eliminable register, eliminate_regs +;; will eliminate the arg_pointer register from the function call setup and +;; millicode returns unless the arg_pointer is hidden in a use, clobber or +;; unspec. + +;; This is for loading the arg_pointer in function calls. +(define_insn "addmovdi3" + [(set (unspec:DI [(match_operand:DI 0 "register_operand" "=r,r")] 0) + (plus:DI (match_operand:DI 1 "register_operand" "r,r") + (match_operand 2 "const_int_operand" "J,i"))) + (set (match_dup 0) (match_dup 0))] + "TARGET_64BIT" + "@ + ldo %2(%1),%0 + ldil L'%G2,%0\;add,l %0,%1,%0" + [(set_attr "type" "binary,binary") + (set_attr "pa_combine_type" "addmove,none") + (set_attr "length" "4,8")]) + +;; This is for millicode return. +(define_expand "mov_from_r29_si" + [(set (match_operand:SI 0 "" "") + (unspec:SI [(reg:SI 29)] 0))] + "" + " +{ + if (!TARGET_64BIT) + { + rtx tmp = gen_rtx_REG (SImode, 29); + emit_insn (gen_movsi (operands[0], tmp)); + DONE; + } +}") + +(define_insn "" + [(set (match_operand:SI 0 "register_operand" "=r") + (unspec:SI [(reg:SI 29)] 0))] + "" + "copy %%r29,%0" + [(set_attr "type" "multi") + (set_attr "length" "4")]) + From bame@noam.fc.hp.com Thu, 09 Nov 2000 11:47:51 -0700 Date: Thu, 09 Nov 2000 11:47:51 -0700 From: Paul Bame bame@noam.fc.hp.com Subject: [parisc-linux] kernel merge We're getting ready to do a kernel merge (to -test10 I think). Anybody concerns before we get started? -P From jvinet@linuxcare.com Thu, 09 Nov 2000 14:08:20 -0500 Date: Thu, 09 Nov 2000 14:08:20 -0500 From: Jane Vinet jvinet@linuxcare.com Subject: [parisc-linux] Website Plan Recently there have been concerns about what is happening with the web site. I'd like to let everyone know what the plan is in order to address these concerns. The Development team at HP provided us with a list of where current pages are hosted and where they should be hosted in the future. Item current future ---- ------- ------ mailing lists pehc LXC parisc website puffin LXC hardware database puffin pehc ftp server pehc pehc cvs pehc pehc As per Linuxcare's agreement with Hewlett Packard, Linuxcare (formerly the Puffing Group) is responsible for all of the pages that are currently hosted at http://www.thepuffingroup.com/parisc/. Linuxcare is in the process of redesigning the existing web pages and we will be moving very soon to http://www.parisc-linux.org/. By revamping the existing web pages, we want to make things like the FAQ page and the To-Do list much more visible to the public to encourage new contributors to join us, as well as meeting the needs of current Developers. The plan is to transition from the current website to the new website with as little disruption to the public as possible. Currently, http://www.parisc-linux.org/ is set up but not active. http://www.thepuffingroup.com/parisc/ will remain the active site until everything is ready to switch over. Each of the above items is being addressed independently and have separate schedules for transition. We will make sure that notification is made on http://www.thepuffingroup.com/parisc/ and on the mailing list prior to the transition. Thanks for your patience and we apologize for any inconvenience this may have caused. Jane -- Jane Vinet, Director Professional Services/Canadian Operations Linuxcare, Inc. 613.562.9260 (tel), 613.562.9700 fax jvinet@linuxcare.com, http://www.linuxcare.com/ Linuxcare, Support for the Revolution From dave@hiauly1.hia.nrc.ca Thu, 9 Nov 2000 14:54:00 -0500 (EST) Date: Thu, 9 Nov 2000 14:54:00 -0500 (EST) From: John David Anglin dave@hiauly1.hia.nrc.ca Subject: [parisc-linux] abort in eliminate_regs compiling glob.c from glibc The following abort occurs with a relatively current version of gcc from the cvs under hpux and the parisc-linux version of the compiler: hppa-linux-gcc ../sysdeps/generic/glob.c -c -O3 -Wall -Winline -Wstrict-prototypes -Wwrite-strings -I../include -I. -I/home/dave/puffin/glibc/objdir/posix -I.. -I../libio -I/home/dave/puffin/glibc/objdir -I../sysdeps/hppa/elf -I../linuxthreads/sysdeps/unix/sysv/linux/hppa -I../linuxthreads/sysdeps/unix/sysv/linux -I../linuxthreads/sysdeps/pthread -I../linuxthreads/sysdeps/unix/sysv -I../linuxthreads/sysdeps/unix -I../linuxthreads/sysdeps/hppa -I../sysdeps/unix/sysv/linux/hppa -I../sysdeps/unix/sysv/linux -I../sysdeps/gnu -I../sysdeps/unix/common -I../sysdeps/unix/mman -I../sysdeps/unix/inet -I../sysdeps/unix/sysv -I../sysdeps/unix -I../sysdeps/posix -I../sysdeps/hppa/hppa1.1 -I../sysdeps/wordsize-32 -I../sysdeps/ieee754/flt-32 -I../sysdeps/ieee754/dbl-64 -I../sysdeps/ieee754/ldbl-128 -I../sysdeps/hppa/fpu -I../sysdeps/hppa -I../sysdeps/ieee754 -I../sysdeps/generic/elf -I../sysdeps/generic -nostdinc -isystem /usr/local/puffin/lib/gcc-lib/hppa-linux/2.96/include -isystem ! /home/dave/puffin/linux/include -D_LIBC_REENTRANT -include ../include/libc-symbols.h -o /home/dave/puffin/glibc/objdir/posix/glob.o ../sysdeps/generic/glob.c: In function `glob_in_dir': ../sysdeps/generic/glob.c:1446: Internal compiler error in , at reload1.c:2516 Please submit a full bug report. See for instructions. make[2]: *** [/home/dave/puffin/glibc/objdir/posix/glob.o] Error 1 make[2]: Leaving directory `/home/dave/puffin/glibc/posix' make[1]: *** [posix/subdir_lib] Error 2 make[1]: Leaving directory `/home/dave/puffin/glibc' make: *** [all] Error 2 The insn that causes the fault is the following: Breakpoint 2, eliminate_regs_in_insn (insn=0x406a0ba0, replace=0) at ../../gcc/reload1.c:2826 2826 if (! insn_is_asm && icode < 0) (gdb) p debug_rtx (insn) (insn/s 2711 2709 2719 (set (reg:SI 6 %r6) (reg:SI 28 %r28)) 69 {pre_ldw-4} (insn_list 2708 (insn_list:REG_DEP_ANTI 2696 (insn_list:REG_DEP_ANTI 2702 (insn_list:REG_DEP_ANTI 2697 (nil))))) (expr_list:REG_DEAD (reg:SI 28 %r28) (insn_list:REG_RETVAL 2708 (expr_list:REG_EQUAL (expr_list (use (mem:BLK (scratch) 0)) (expr_list (symbol_ref/v:SI ("@strlen")) (expr_list (reg/v:SI 4 %r4) (nil)))) (nil))))) As can be seen, there is a use in the REG notes which will cause eliminate_regs to abort if it is called to process the notes of this insn. It is called from this code which is near the end of eliminate_regs_in_insn: for (ep = reg_eliminate; ep < ®_eliminate[NUM_ELIMINABLE_REGS]; ep++) { if (ep->previous_offset != ep->offset && ep->ref_outside_mem) ep->can_eliminate = 0; ep->ref_outside_mem = 0; if (ep->previous_offset != ep->offset) val = 1; } done: /* If we changed something, perform elimination in REG_NOTES. This is needed even when REPLACE is zero because a REG_DEAD note might refer to a register that we eliminate and could cause a different number of spill registers to be needed in the final reload pass than in the pre-passes. */ if (val && REG_NOTES (insn) != 0) REG_NOTES (insn) = eliminate_regs (REG_NOTES (insn), 0, REG_NOTES (insn)); ep->previous_offset is not equal ep->offset here and thus val is 1. The use would appear to arise from the rtl generated by expand_builtin_strlen. Anybody got any thoughts on how to fix this. Dave -- J. David Anglin dave.anglin@nrc.ca National Research Council of Canada (613) 990-0752 (FAX: 952-6605) From grundler@cup.hp.com Thu, 9 Nov 2000 12:12:25 -0800 (PST) Date: Thu, 9 Nov 2000 12:12:25 -0800 (PST) From: Grant Grundler grundler@cup.hp.com Subject: [parisc-linux] tulip DMA mapping Hi all, I see a "bug" in tulip's usage of mapping services. It's not the bug I was looking for unfortunately. In line 217 of drivers/net/tulip/interrupt.c: if (tp->tx_buffers[entry].mapping) pci_unmap_single(tp->pdev, tp->tx_buffers[entry].mapping, sizeof(tp->setup_frame), PCI_DMA_TODEVICE); 0 is a valid pci_map_single() return value when the system has an IO MMU. The system will panic before pci_map_single() will fail. The driver needs to remember some other way if a buffer was mapped or not. Or the Documentation/DMA-mapping.txt should be changed - ie add this to the interface definition and I can reserve the 1st mapping entry so no-one uses it. Should I be mailing Jeff Garzik directly? Or can someone who knows Jeff point this out to him? thanks, grant From rhirst@linuxcare.com Thu, 9 Nov 2000 23:00:50 +0000 Date: Thu, 9 Nov 2000 23:00:50 +0000 From: Richard Hirst rhirst@linuxcare.com Subject: [parisc-linux] strace working I have updated the strace source in our cvs, such that it now builds a basically working binary. It requires an up-to-date kernel. Outstanding issues: a) ioctl defines in linux/hppa/ioctlent.h are probably wrong b) there is a hack in defs.h to get round a problem where the libc wrapper for ptrace() isn't getting used c) there is a struct user defined in defs.h that should probably be in the kernel source asm/user.h d) there are probably more places where we need to add HPPA specific code Richard From dave@hiauly1.hia.nrc.ca Thu, 9 Nov 2000 18:57:13 -0500 (EST) Date: Thu, 9 Nov 2000 18:57:13 -0500 (EST) From: John David Anglin dave@hiauly1.hia.nrc.ca Subject: abort in eliminate_regs compiling glob.c from glibc > Breakpoint 2, eliminate_regs_in_insn (insn=0x406a0ba0, replace=0) > at ../../gcc/reload1.c:2826 > 2826 if (! insn_is_asm && icode < 0) > (gdb) p debug_rtx (insn) > (insn/s 2711 2709 2719 (set (reg:SI 6 %r6) > (reg:SI 28 %r28)) 69 {pre_ldw-4} (insn_list 2708 (insn_list:REG_DEP_ANTI 2696 (insn_list:REG_DEP_ANTI 2702 (insn_list:REG_DEP_ANTI 2697 (nil))))) > (expr_list:REG_DEAD (reg:SI 28 %r28) > (insn_list:REG_RETVAL 2708 (expr_list:REG_EQUAL (expr_list (use (mem:BLK (scratch) 0)) > (expr_list (symbol_ref/v:SI ("@strlen")) > (expr_list (reg/v:SI 4 %r4) > (nil)))) > (nil))))) The `use' arises from the `__pure__' attribute in the prototype for strlen: extern size_t strlen (__const char *__s) __attribute__ ((__pure__)); Still haven't been able to figure out why the REG notes are processed or a simple test case. The cpp'd input is attached. Dave -- J. David Anglin dave.anglin@nrc.ca National Research Council of Canada (613) 990-0752 (FAX: 952-6605) begin 644 glob.i.gz M'XL("('T"CH``V=L;V(N:0#M??MWV[:2\._Z*]CFG%[+<1I+\BO5MO>XB9/X MJV-G;:>]W6P.#RU1-F\D4B4I.]DV^[=_>#\'("DQS6/%O9M:P&`P&`"#P6`P MN!?T@F^___YA\;X8Q_/BX76G@]S:Z^'WW;N#^[RJ;%]S??!CT$T?>"=!#$SKX?@GZDKHP=+$^6HLN_F$![R?2SU M'&,1D#I(@O?ZGLY!^=OPM.@+#/H\7*3)._SC%DWE=/'NX552%L9DVJY?0*G# M%L847DH._$O6%`QJ%XV*F57P,_O0DM*8!7W<$L1O$T&T5EDJ7!QFV6C+M!&$9EF2=7BS(.PV!C(PS1 M(EN48=CM#AU\&>S[!RA`UN@FRH/->9Y=Y]$L3-);1D681K-X"\PI;K*\)/D& M'>7[>8PF(&]JEH?ED!$VJ%Z@K,F,T1GB;IX5E/%Z)EN3[%S)FAHS$T)9JX!: MR<-%D3_$73F5H^OJX?5H]`#_]V8^CQY0#/WO'^W)YI9CQ#@^Y:BD6143P?.H M'3Q8EUH=3_.)WMO>:;EBK,[NMXD3:YIM$]GDXY-ND1;)=1J/R>PKDO^)V>2S MF=KOMS(J3*Q[K;+U;_G$DEY/+F`Q:K&;"-`P7(3XCZ&=3Z0E`2!_`1"XPW`^ M^B^0.\W2:Y*-_T`]BI8+)+E1+I+$80"#DW\XVC\6T1B/!;B@"<^AZ9RO+P$Y M/ITK".=!"+6*<\T$T)A&*4+_]O9`)"K4P@+3N(O^'?1!)+(X!7#PR<%>]._> MCIN[[FX1!05%G/=8(_@C&H]S(Y?W)/IS'-^J;6&#AZ`=PQG7=@8;6`E2/<`B MLVP3%!+L`1YW=M&.OG#8.,@V"2K5C8)-@18M_N&(68= M,@Z+&"#V;?Q>;P,H(I+YB`^W#L@GQ$)UX80A1FGI&.`TD\UJ:.A."JB\,GPY M@!?'))GZ<5``"(<`0I/>SJ<3E,YA,U<=R&&!UOS!K>0@&:/H7_G9>[H M-#:DT=B:03.S%/U"1(?GH9!R7T>@&5QTK-6,VS+-I,B(\@-@FH/`/63));]".N"19 M*KYL3M!3L837\464C_$O!0@1\I8L/$0V!@$V'^#52&1H&$@JQ?`AX$W&E@9# M+BHM=G4$7D%"RNG`X"K)NHN2,L%*JZP(KV'NBAAK%[/9>[.0I!`4%QQ4K`2^ M"F9A'A=Q?JNR>H9J6:0EV))9F-VE<:X"OTW2\=#/FAECC6S';%'&[ZI:3X`H M>J,DT$EJT[-T9"U=)GGY'54%JKHUOQ/]2JE""1@FS@N00RC[#@U?RB,HE_P6 MX\Ⴁ-NBX1Y@32N6&,1;YJ?NQA&Q^9$I;!;X+O-IE&93&.-\5S>Z,.3 M<;>"T5>1P6B4D,=_+))<'9PH<8Z'K&-\HFQ@JEU%>9[$N9,J9_-90;7]GH6> MERJ)P._MU3"4:E(>F]U=MCUUP\VWV(&YTQ9;Z\#:8G/EW]A;"W6*;ZHM98[O M@@'E26ZH92;=*`3V?D$H57SSH^61K5?`-F`ZGX6*%BBJFII-MH`!VPCJ662O M%UP+35?)HGNZ@&_M]$RVK0O$]D[/)GO+8"'1*GFTD;*-9B9IB:)6JME$)0_F M$+DD!\I@&\2@@/1UL4$+K(V:V*(%8JNF%23+1Z`N(JKNQ^U5>&_$G0%X'DY3 M,H0!64U752JDO>UZ`32ZV`XN4'9R-A#=809\H^E&1-BJ[?TRZ24=##!RV^+1E;Q_*$N9QMSA6!8(P M202J=4*?J`I084"M3TS6)R8?G3O8&6+W8U:V/D]1J>[M>)4YCQZYT%4QP(*W M\!V@+(B&5^M3-T_T_"&PS]J)BA1B6^1_'N,C]^[0+(=/&[P%GSL*XG,&;\$+ M1T&B1?D*/N$%';OD1;A,>VT4S9MNXVC.!1M'`X:HK,SCZZ0HB7;C*WR7Y6/! M3V6(ZSX6Z3B)4MU+`6VRT%[,S'H$YE&<@[XSTS8]XFG//$Z4&CCLX`"F`?:S M-)VH5'BL='EU`:FHN%IR.7)O=IN<(-59JV!P>CCHDP("! MBPJMC7ZK:7)=Q+)9-/O'/!&#)(3FG.#?)<6!PG:YEHU@7R]%?G[OZ.:QE1 MW"QI8K#!/!@FXV)+8MX,\8D`6C'):0TV9^)\,G*-SU&$F*X;EHG?C>)YZ2JD M\\HHBE.S12D5$Z6A\Y9:NE13EVMK0!Q;`T.BP&WV(9`+F5$6)1-W`GZ2K%]A ML$>KPDYL(:]DJ(>+.DL$\[34"NYX^.-E"LP6A1=:,]L:-LN-FR4'3MUI(@5^ MA2KK6OW)&'E?S*)1GDD?8;^B9Y8!E@9]E>BYW)B9")4247BJ!(;/B@%$'$4" MZ76BBU7ACA*HGBD&#'S#)4:G0@%1*E))JX)))265TE5BDZ7960= M3@(\F:["E!I/J*T#L<_`U;!AGMI`)JY8F['RRQ# M9\PFG3+&%$^P`H-/2]V+%JG,U2S7("&]AC6Q'`D/4A,;BH.M0-+/(8>=#TZB M'"M`-57UR)HN2U?5V@M7-U&KHP*[3F6-A*2?*X8$U?N(U=-3F4$%[W=\^'SH M5(P@:/6LT5OP#'&,(US'KJDC==GKXZ:I)O5(E*H7%%/M!NKJC(NCD9 MG'=4,0'U3%W>UU)-=4&[6HT--2F=VAJ*E*D6H0V+2XO2<#?4CXRR[GGO.+WQ M*DQ#Q]!S]38ELA7Y[JK8)]];$N&NJC^*"'=5UJ((;TV(RT]X0KC-[1W;,!X5 M19Q+FQ_)HVE&%C..FWG0)OI>L-NO`&8L)K?DPI`"A),HF=KLI9E)EL(JFY?1 MADT&]R:`99&.,/YN)[`]T=*,]@J/^`,2/J>!=BC]M"H<]FFM6:?G,P^8Y(CL2V<'SW"WCI?*<9*IGGK*A)@F5W@3)"'$ MD-=S.D;1M>?\VG-^[3G_E7C.#W8@6=!GN:O,]BB_5F9["YATWB@G_XMD6B9I M>!LA(4P<3Z[3Q8C_M$7NO6!_%=D#4N/[E"N2"EV!DSZ]?QZY^T='SZ_['I^% M3X]/C@+\S[`:+`P-0'UY(/^*Y6$?R%'+B)4I73P,GX7.`,;K=62]CJS7D?4UZ[\X>*"7Z@"ZCWNC2Q$;>M;J/I@D1?"D-$`8X@Y17; MTKO2%(=X6NR[`ES8=S9]:Y^QO0XZ+N`[P6[VZZ! ML>OMC=V!NZ/Q4R3N%N\Y:]QSX,0/"KB&XIYC**H=!^L71#P8[RW(XO@MADH= M!IC>W*$R#.<9#70E9R@SU-.)^RR<(`@MVJR!A5U-KH5'NK6S^:XUZQI1?:M; MR1.81 MI`;TUROO>N5=K[Q?U\H[`#5^MO#&Z6+&MAS/'I^=_AJ>_1+\&&QO*2FG9_@_ M>LJ3G_7?+XY>;'64E*,7+R]_#X]/7[ZZ5`&?OCHY"<]>71K)QRGAQ='O$\H-23HXO'Y\G*/OH_/SLG(7QMEI[?!&> M'%Y[FD8GIV>G1_1\A<?O6=-T)S?3QZX>5QOR5IE(E+&;NO>;>R+1\G(ZT>*X0J?,0O*5 M"%%C.J$4\??0`E!Z7P`J:78!1I(`9K_5QPNH`+4FHZ04`Z6HAJ%;IFM1[B'A M3=QT;]#*']Y$Z7@:4TIUU\)9-F9/'6KF?QSJ'H">Y-F,/8UH9Y99*%`I*P'Q M(->XQ+N<^`$G%A,E^P3C.I*\69(BQL2XE9@:Y=6"Z)TC0Y8H,Q"^S(9*#<1^ M.5E,24/T#G/V!1]=UGP,PVR!W9^'[JP8Q^M7ZI],H^M"2U%>IY2]HV9CW])H MBD,6,^Y+>RQSU<8J@,-02S!Y!R+Y-70\-R(Z=9+1$OL--BY+,3"TW5D535+$%O$8RZ7#`3[P`J85;AP>[\JC&.)< MS`?J66VE#/A`9M+L*DGI0P6(N$2T3`N>^&RYZ*2R[(I121&2Q5(40%CJT[+$ MAL)P*FO]BKM\\-EV4JOU*>YQ_U[,YJBO38\YP*>.>H^C?"U.OE)N%N5OXUQ[ ME4.F;K(%);!\\S;#@HBHCI`IY&`'[X6WP48228`W+&3HCN/1;8FO.)GI98(CAAF7ITLID?+*SHCI&U-VQE54Q%8.??K*DP75 M0W.@BM!:!2/#&52;-C**Z-91_U4T>KN8LSRP&%//#>49Y_+7\<_Q/[0JZ?-.J`VO>V]HC9:2@,@B779;1E=X/V=U*%G.A2N7W$ETJ/#: M#,RN-5(9NXU4SCF9K/>HF6[AUOI2)JL=J:?R7F0[);,+9;+6?Q8\1P,I0_2/ MPLQG"A%"A.>1X"0.82$WCR*DE.)4DTW'^$\>P]>*;Q:.%CGJ]^EB1N:G]E(T M[4]1G+O6&0,"UR:4/T0C>P62?9IGCB0$''^;<@!J^4(>\($F#+V\Y334EZ"0 MA;-ZW=M5@K%CRVGP`&W)9!*SS;SA0]9Y2T11?HV\<#[%SV#RFY10+OG5#WLA MOL"2AL.ZL$@VU@=&VFIH1`Z2PX:(A3$>.:X\(H==F0BWZ%#[.3"TT\_HA)RD MG*5XP)O&6,"J@\;*E;,*OWI=QT:W"2B..OE`WB0^9OSNZYUE321X1M.L@(CO6@^N2?91"/:37>750[2J7&'0[+<+ MG+>'0=.?+F!!-(-FOQ5PAP^?THA-_,>0IPIJ-\E?(IV3M8G_$*FB_DWR%S$\ M$`E!J$$`G!3-#]`)$C@*ZGLW`H)EJ77A6\&;)J6A[HABI&_5V]#TX4WQ`"ELW5%E0I@ M'2"X:IKOL;2HY*-RUW$Y4C$@ELV-1J*\^0)#,:/R5E`%/J&/HU="86,!`&?5 MC@8[?;XW'D/@2K/$")Q@<#+.0#9*N$7JAQ34EOE[!V0%BV\GQ2A*-88$,F2> MOH]0,YRS0+\52N>/$H3/IOUV,L_1WT:?P!34(<"@0`VW(I8BW&_1.+4FQI8$ MDN640@4:D48I?DHG2LGJA):$2Z)A@G[K906(=A3L+(]6*%]YI6XY@O(XYKIK MA(28-3B,F4LGW9UGUBF0:.)A2+&O"._J3#^L[YGHN9A5PQ.J'_9B&\!F4< MW=49T&+[56M,+S.H[^J,:KD+K$-%S9%]9P]MVFG@Z-:'RIUOK-">V%=-M?H- M;K%Z<\?^@/OW`[DT)+WEM^_XY,M"1C`/ZJMWD\WBAV.T%>/^2-<(;/0PN_KW M.,EYI&M4`C%N)BX!/&I>T$,=%&J$LH5QFG)25]M%FJJNBT1%35?&5Q[/T/(* M!]G"!Z/&(I631!L<[2-MK3N-[_1`,I26IY6Q<]UQ M,CT%L7@NE*:R"O-XQ2JK*W65,P5KH/(.>Z-#X2:@P4NX5B/F\"J-Z`Y!QJU8 MZ_+,JV"?Q:(Q[68U/I_EY"%M`#9[Z3Y([IY5.J/K9,0W3=X5<-FF!MZM&$LH M5*'%*)\A<4O:SC*>9_J? M&!6%-AU%C,U[4KY8_;T%<12*=HXPW2Z'"FZ2U/M4MJ8Z]Y0VH'U9:W4'BOT( M_V&%AT-5XC!H6GN=HIGK>V[BFHK;29;/(J2U??_]]\;Z(G3+90H7O#10ROD> M6=UZU(INO3RQYXV-%>XV(_`06K[S:Z.-MPTX!*+K&/C\3&N]*7J'I?[*Q2"> M1>^P0')55:L/(76(YE-O&4I*&&X%@ZU@A_K-:%:GVW;(K4O5::N`00K1Q8RRTM=FZ6O4]1_7+]LQ'D_<0P_0Q3X]) M+`55`7%`=$P83+IAXS$@?,8*&YD"K6`U:6]B`#$.>WPT5(%V3>@8/,H#4 MKE#KPVUAKU7.IL@N!BSXV&9?U;_86L]QW/E)ID,8]TWA4H(HGG3+8T+H#&&4 M2HO\N/U[X)JV"UJ%WA3EV!4PH>,3D'$\31P;=+PC]&DE_`/WZ"EO':D@0557 MXO&UTR*^#=+;(=S?/1#AF+H5Z':0[2U3`GTEH9E,JXYGY".50A$X+BWWV@^88.=#W&#/9 M(:K1<5EA6J>P#Z:&2U).^U\BPJ5K^=]09N"S"9`=+#`;Q!#+?X%RQ$:EZSN, M(2J8@R7<8\]FBLT3N`&2*XKWG]9%9#2-IG&4QWE>==I'/(HJ0*@[D6=0:#76 M5+-QS;5!R0LG]51M0LNA\O0S]A<$0%-[\O'YCJ*=A M31RAA<08M\2#NL9.@L!5\<,XP)G#!YVC;#:+4N^!F+H,.T^0+;5UA/Z>)6-` M<]7!%D6<0V`%]6[,\+4!ZL.MT,%20VZKT8&-"<92O6M$;>,$0,1M:U0L:\V0 MQ>U-NNVG26:(XL=7)>TU!SWW1HVB5=W^_"N9_KB!=%=1?5S@;%#P\P>S,,V= M6F'E8M4$IQ4NP? M_YW^8TO=;'D&EU\[](PI_JT2K&L54]?KX>O;;O; MSN4+Y>[M^A:W>\'>CMLGD^)W/"YG/<-J^]UIV6V=>-<^HJ?`#8_I]5-Z[XG0 MTD?:S0Z.JYMA'WX8O@9U3XL:'7TVH*MGT&78D>N(@@JSBV]3ASFP]('5Y]&? MBAZ[CKBZCKBZCKCZM41NK9H`PX\CAVAMS40S(*?#)(/\]X+=KT@QF#X2H7["M/C"Y#. MZJ?>A4<*S#C!1QV5E[;6,O?O_/"&I_GS\8L4:7!CXQV;>58D[[0L\32.D=4& MV;W]71"U-&XB)IMA58L@=V MA-:%X$-M<7J;Y%DZB].R,*S`=>`[4`5W63[&B_ ^]!L<2'!7XX.6+2+7( M[TM5HA;Y:.UJ`&TP_6#;S72@C[[.16V]8UGO6/Y/KI[][0;3'_R4P#MIB=0D MM'GA?PPMD`+IX%.\G0C$7[I"I=Y#&(W0]L#>-)![H7S;@C#;Q]SQ(ADW+*TS MA;U>9"W[AM?+E#KYJ/[^BM-,$9>VWXS54NDQ0K!AUPT#G_0Z<6!46LY.V3D& MW76+;2VIUYJLA/M).6-;&>69[YE]R\&!""1BWH0*F[&*WXO`V)0NCT7:J&Q( M'\H"9XK=HUH3]?[T-M)S).[!9LR_!,!*/$PJ!!962T*+10$^JDOLGN``<< M&JH+84W&M)OND-)''!-8PG6>+>:`$R[#IPZ3"AR6A)VV09/>QG$"N%UA0YGM M5\*`%2F']#?'5LWTB!_=*2Y#^GP0UZ%E=:(8#C"9(PT:F]A":@C3KHR8\$8M M-@?'B[DAI_7,OMI!_*^^"B@.6)B"/S1S9+JY/KZ+1U`P%9N\1MDD1RTNE/:((2B;M<$:21C'U,D(,Q4A@6^:$32M M8+F=N^:4KT46+4XL?F)4/&DR$OV%]%3`53*,W^%@@DRZEE&Y*+HU;+B=BKT\ M?CL"3S##FE$%RP8Y?N>+/QX1OGP4",)J%?X>/#T[-3(TT^ M-$;33@]?'!E%7QY>/C>3CE\>A3^_>JHD/7Y^]MMI>'YT<7E^_/CRZ(F*\RR\ M/']U^EA)^O7)\<7ASR='2M+%[Z>/P^,S)>703GIY?GRFIUR!6')\\,=-.?@DO'_^BI)P^.S][]?+" M@#M[>71J)"%F'!V^,!(O_\MD,DK\?V<_AX_/3B_/ST[4\H>_'CT)CY]<*&D( MX\GE,4)P_S\[/3LU<7 M"E,E(L3`)WH&+V'G/,59RN\7AR]?(AC2$6KRT8N3,XV9+"4\/SQ]=J2GGYW_ MCD@YNSQZ?'DL1R[)N[@X?':$AN;%A=[(BR-4\?.S'YX@6AO'LY_^' M$&J,0(/JY/@"56+TRB&80@;ADZ.3RT,C$Z4=_D[8;&2\^$]H=*!4@DI/_15U MDM[:EZBI>#"C)#D*+E'WFZ/MZ$5XBOXQ!R9.__7PY)4YYA"&_WQU9"6K#5!J M_!G][_#"!$:I3X[-$8X2+QX?G@"P6#J<6I/N[.0D_.WH^-GS2Y/TH_]\=?PK MFH&HG\VFG-],-SBE>9C2*W#W1#/T1-.#Y] M8B0].?I52WEZ=GX))R(9J"5>_&;!H9F`^/;DZ*E*S,OCXRWM5_BO2S,%B\&C M2R.1O@II)9]=:*41][7!62WY%\OG_7M9KQ\-H`2=]3RI.J?M6XF2;9X-08K MD@@&$$G18$[.T.J@(__M[/R)D?3BY_#$6DU/_^OH7%-5@+E[`5!Z`9!Z\?S< MI)4F:5"O`&RO[%:^(HTRTI0:9`M.L$9JM.HD/$&*D97XXL)..[52+HXNK30T MXB_-P?WSQ6YX?/)RT`_/GCX=:`-#R_KY^)F9=_)R;P=G[>W8.0A8H4VV+RR-5 MVKQ`VX9+M!%@_%!S7J&.>HG*,!&M:9RGS\`,I"B@>6Y4C%F'--'?SO&"20C3 M<+U$R["9>'[T#"F&9@(@%B^>'^EJC[69NGAY^)M6`@V$PR?'6$,Z1_B`!=H) M0)D7/CF\/#3&GY&C=2P>,6>O-&WH\O>7OGW,*U1S2/>F<*J&_^7/%_JO\/#Q MX[-7IY=Z+^`,K)9>'AF);!-FI%Z>'VJCX>)WM+T[>XD3/@PA>\7C"V)A$'N- M+9%\\A0M^T]/#I_A]\A[V]O;'"W+.WE",LW4XY_MI--+`!0)KL=P,H@9IUNX M22+##C3!E*Q*>WI:>RQ`FP0;1*<&R+>;;=LQ2;JJ(0`G8UHJM M@2XK+`NOPR*%VW$69'G3ZNXL4[POU!("SHA/@6&*,E?!7.\)36,C!BP^5!O3 M0#'S9&R'&%?S=0`0Y#J?6]',33AR@V-^G9!`&CQI3HM`*$%`TYA<@)!;2J4X MFYZS[NX>.,]93910>QSM0O"%SB&[-86C,?*HD$,NX-X0^;$#X)H#7%?DQ]=P M=[+`5^08K1#&=QS(1#EDHV$"K`,&4@B'8KZ*R5&;.)-S=MJ",H2?YBT@:A!8 M'AN`^2+1CA5C5TFSX,))"AL^-LTF*09@?DU)X;]C5TFS(,`5/C0F6?X6/O_C M$+I1VR0?/69";H:28\0 M/.*L58A-$(;2(06GV->)O1ATHZ1S!\GT5/1_\C2]6C/TX9>#VX$]JYTM]WH0)3#AP5J MS8@/>]HC]#SWUGP]BCQTB0IRMQ-\B;COX:?ZH7YQ]";V4=[O>QRV`>IOLJ+4 M+Q&Q\2>\`N$96:A%88<^[XQFY;%\5P)P6:*943G.9E&2@G3JE>@UJ,66H'%2 MO$]'EK!6(6YOHO1Z,;?5!BHI;[.WCO=Q8,^M/$-YBI<4?4@59^$Q$\WFTSBD M;P_4"9DF(+B;HNE]-8JFIG,-<_(L?3)%@%$P M,>=##9Y@8QF%01, M>$Z34*-EQ*\D'L"7,\"M*`G4H(@WE)9FJG,/0O=HQ^/"JFI^^*JDO14>S4P> M.QA,RNO,-3%(/D.;-Z._\$O)FGQ,IN/8CD_%%L/\_1P0$V_C][;264334I,= M3#(P'$+?Q@WB;8C'.(2'J?E3B7$777D#4%+5%\@H,TBL%J87M=W8$@Z6AI01 M^#:5M@;0VV%(!LCM2K!!1%<\C_*XR\:W-UJ#+!1A!\EF948WJ"=Y$3%.!X[+ M>E:(D@9._EJYAA<$+%=]-&Z7_VM;*?6!E6W=[.B28>V6&G]7FWU#D6S MKFVYZJ;UUYP_SO)+W`K21++S)@ETPP,M&#G_"\3U*LS1!:B[& MATK%HS++WU.358*OXJ10A)'R)BGP]JIRJNB?VH*&1:WK)%J#S6L?9J;SVH>N MO[1U@<-SA]VB@KK,>$ZCN28]9#CQ;,8'J'1':)-4[\;'Z M7#^CT=`N<_BB(0#.7G3)WO1@1&_U$BS[;*+Z^(R:GAGAE-;8BZ!E'3 M9J=9R%!O>&QD'=,D0)31.,7]A-7!11Z3HYF]@^HH0^L.$%W8YDJ M0P2)5,6&M8Z7LHZ7LHZ7\C7%2QGLF#+`CI3"7G/`IT)W8Q()FJYV\SNRW`W5 M!`J$D[@.A1+1'S3EFJ=YI1[)B%;#/Y>1(.S"$Y@6J?63?"_;A<)+V;DDN<-K`Q^;9M#3V3311 MRQ.[)S//J7\QSS4+W@PI`L8YU:LVXG?Z2ZB*'4TDUW;HA88P23/$]C'^[Y`E MT4WM&/^7"@><#!@PT-3#,6C2H0Y`>G9,#J!I#DO`0_QU?W?OS9#?(M*(VMN1 MMXDP->3LQZ2+)1+*/A95O+O@[N4A70\07E+`G$\Z/GJ&$`YEPEHS9>!#UD?D0#M=,8'B!15%\64;>*']L#C&-@?#MN2 M"#@I3)#/R?3M[>PZ^*KKL30CV,0F)P"1N1H:(TV4PX>64$G-/9%`AK(.9?7% MA9R/T^J4:N502OZ^9L&*]=Y!+YHIC2D.;#[5IQHH[*%9#.T_$:WL;2GX)*[\6\91XL70M0R='ZW"CY0A&LWG7]#Q_%C.VW'//D&- M^]T.<.PY7^2Q$N72YK6H1N7VZA6I=X3BO$@0BH_>%*6B=ALCJY&O"N*3=S(& M\B0N()>,6I<^U3';T$]6[.>-NJ(BGCMV$0[J=0?/9>E?H@7JWM_7"M.&J4M0 M=;>*\%7L5VW7!V#[`&])J1]$37"^QW+L1BW7%WTG2O<_5OU-]FD>LQ^TDP1J MI$VHJ-.Y.P3J=-!TO&GC*5B!B M]U-4@:]2'O%+NO3GE?,%/"D=-<2&^%T1];W@T:"9P=>G@EGO"R-5D9F"-0B: MHP$(>["99U:PWK.M]VSK/=M7LF=C/C66/+"=\KPFJ+LH*Z/48'XV%7R=^O0;=C&FZE,5Z6)3R*AU/(@($(A8CMF1I@)/%"0M> M8^Y82']ZSD-7<+9H_\FIX&NVZCW[0V]O"&9@UU2DJY2C;!S_<."!&65Y/%[, MYC_T/$#XVBM*^F%_R,GX@--1*TA6DD9E//;0WISTHLSFN$8?Z1CF-IIB&),J MG#6G)*D'9#N58]_\^)D2Z3?19;(7L7*RF)?Y4'0E2DA8`B;GM\-C'*CZ\/+5 M!:`5E'F4%O0J;TB0VMM`BQ3!83E\_EADI:0@CV>T]G%RRU[\#;\.4<5H04@,?6A=NH`*M!N7CNP^N]XUP?5A3#&=7^(F88UX!\T^QO2^#$YV`)Y2_(0'TW"&V!+JWM'M'CYX#`]DR5I M9E[?D0DOU8@B"A&R=9)X,K$\EH-CKF"NT)_%Z][@S9`H3I1I\%TLNAY>#068 MEHY&1787Y\[\"YIJV%M]`S]:C?((6M$E[799Y6-;(3' MVW^=H:F,L1:-5VR/KXM\5%`MC1$Q68V(1C3`^AL?N:NR8_4NA0CNV+JTZ#YW MQ(3FH[)ZOHE7/^%N;)&8YK3`_=DF?U;O7?:I#0!V=&)I:Y?X%0E7!8S1@%J+ M7?L]T4JS:C:PV?KW,=K:2CN];5QR170UMAGWZ;?J8*!?:T."?BZF=:1=21P[ M)CB00LSD4*>NR<.W]2<73^G3J[#83]E*Q\7C-NK-#Q9%O..CE+87HM4=*I;6JHU_]^TA=-:+?[GRR,G;I6J(;=/UFV^]516<=:U9"N M:9UQZ3([ZI3JG5[#3-+&:&W2Y?XVP$*S4]OHT\X(;C:$FW=+'=M+&RWYNSK& M;@^P'M5<7-KM&\?RXCF'4"N5JQ"MAP7MV>P&&RS(37>["TH-S!O/085:"7:M MZ2HF:4]56T&O8HWRG&E8#:M=6[,1[CWXL&AH0(2F,%#8Z=Y.I,5\3L%[.]'> M#D`1^%B[>@QC>?*\+QYB0YTXV1X\\AG>.NJQU:"/-J9YE(ZSF2/@1,%SK9". M,?R$2I+2@^P8+"(=M0B,UZM21HS"H&9P?HH'!XBCE9EXY>$HLY_2AA#[J7HD M2EBP.5%/9FE2;B<1W,KQ*<*H7+H42>/XVD@IXKF!"HF&D!_^ZB>)C$YY!UTA MO+93JJBG.GY"(2L$.PRF@G%8P2,ZWHD)6%26&`65+I)>?IF-CR7-RY!7MTI] MVA%X.>&L^>:9;082B]>;^M0T#4UC7&CGP`PBQG)CG@N<(H3ANV)QE;P>O`&% MV11&+/+3Y5'/*E#_NS%JR6E<3-T$(];=1E-9"72<@H&',WMXMK5"M;HK$ M_+6SV#S*H]GK?4HE&U2LKW2)!91^]WKPQGEC//)ECIPY6/F7>/GTEEXRZKU2 M1J846"KA<'P0QW1BP]`AM)0Z8UFGM].K+L=\'$+U-Q?:8X\8J-4,2C\Q@ZI( MU5@T^R0L^O>7Q*)"$FN+JRT7+2P*3L=<\V)?NZ4$KQDU&_*8TG!:I.4Q M0\QO7Y$]QO*$3O(XUI!I6@))'SE@S'T$J2+B-P*,VP!JI@S18N2QOEC?!%C? M!%C?!/B:;@*P]P0M62"\H3491_--\:LZ5SOD3M_&A>]J>;#="W9W]GS&#@W9 M[5+K0D=;T$A$"QR\/9JBU8R+U4V4H$IRDCF+TU*DU%TO5(*C*W)?V!7..=-)NKF5I")?@IX/XTH&,>AWEUUW]EW['K@UT M5@=2C"J&6FS1<(1'JR&A1@+\+$!Z6R,@E+!*D9#7874Y,^`J`9>VK3Q)KP'` MPH/7#CR/YL%"G'WF\7P:C9@7I,HII*_5H%:/?!7C"PJWKN?W:/G9VQ)-%MDH M_&N*QBL8.'SVMJB"!L#)W4MW`9.>L;<*E&-U)6V116(8"/371WD*F"54,-K6#&TZ32Y(CO MZN!_Q3,QBUDL_+W&<9K-JO!QXBBJ*<&EGJM0A$I*+:P.#O!:E&JLNFKYFYA% MZQ$%3_QX=(N&H?"#TT1W.DZN$_;HGSZSQ_%H#L<$L&'QKAQ:XR:?K.;K&C4K M]_U56PE-_H-R37EJE+L%>N633UGY=B.4:;,[M". M\0Y#6\>I\[N1<]%WJ&C>VNY&93:[4M3]K8!7'(;D+TUQ8(AF5P4FLO!0Z7W) MM3ZM>KT(+2:W@`].JVOT4*O6VX&V!?E\%I4C6!N>HX086E!Q0;0!*Q97F7Q$ M6J\=92"=P!E#5NK[N$Z]:)F]11I%D]NN9-I887GY*R!(\04?RP:W2==YA)]A MTEZPTB$6*7XKVP;1EX]Y6=#-B0&D[THI4*-7V*S0_:6Q2=2SIUDTCFZO%8'. M4EZ_$7(FGL8SU:ITX(AOT]?1$[<(U`^ZTXMF(@@KG%Z,O7U['B^PSXME2O"X MO&@VG2I/$M)7NJ<(%+%J!?\0#5%]!Y&E.-6`$LCK0]19'TV%`X8&N^J)=<51 MV)9^)`UTXZHGPE4$.(L9YYP`::N>Q'Y$TOSGKLO18X_&UI?H3TXP\)<77(?Q3X4=((4W2 MN*!*@NPLO;?^6"2CMZI]CZ*8:T:^,BNC:8B5#(\NJQSNF*9%'"C1;/SH710: M)S/*N0R.O\B/T/)K_J?-PA6/H/!7?>1U+^@-=BN"#]HQ!?'QA.E!X/13WG$4 M[EMG@*AIH]'\O33'CI$6;9N%BQS>CVDS>.3?U9!#EA3>*1(*E>*SZ!T>_2Z6 MVD%^%$Q%/%>V(!3UW)9(XWB:S&RI5N8XTN0(GUI85/9L+$6_`9&BBG2$YD.# M.FII:TNRB[S/#G=(K2%M8TP]*+?JT.MV'L*:X1T>LS>Y?:!1\`W,:#E.(*0I M=&MN*;S*!,LKJ*W%$V\-+5>@^BCA3M/$CQ*Q5,]3S`)K/Z6UG]+:3^EK\E,2 M$4L->:":@)B+*!)'JD*AF:2=X;1-X:4:/'-+L;!JG&6W<1T=!C)_6M1[R:^B MU+%2@Y+8]J'!]:/MCJS>(<1-8SJB6M4F1&G@40*D3>C+@7\IL+C3:*FI>OQ` M]^"MM;0WI+?AXEN38'9%#ND,>*P`5GI]K$!F_%P+\R,0IEZ,CM'EK\(=VI0;PO6F9OYODL\9C MJNF@ZMC[4C.:W_8C]R)B;I%&CNAH+L[KX:":L8A4B)F$*Y3[0VBH&BWW&E`, MDF`!`N^5ZKC.`M.N_L:KEIEBQZ'HHZS=OG,/8$D750`#>ZH&VS2$;45T,'U5 MV[ZZ..64&Q5S^$3CY3W92Y/BF[64A9GN2^ M5V\BH2-"%=0D@1I"ZXT2Q28T7V(7!A#E7?5-WBQ59\.M'R`+89OR$E*[J76Z MZ5(3YWDFSG[0CW0QKZ`GZO8.5T>DZ\V0B'-T3NR2I MPWA4JV8)HR94:JH=V4]]94%_<(YF:ON"3R'5W46*6.+;V_T9N[)6<=M;RX:G M0,U,%2Y.-=A5U=_=9#7U>.L(K"5JU#V935I]9DD553M%U`+7T`-%_YKN5,'L MFT_+G#@VD#.X+J*I8Y_O?1),]U903Q'V8(L" ML0"9UB,%55]_$((5AP#Z/@A&Q4Z_"D8A>6_'!WPOV!_40&:\1?&GC`M$6(_O MY>:O^V^&Y+6JB\OSX]-G_?#QVK(MYQ M(-Y9%?&N`_'NJHCW'(CW5D6\[T"\ORKB`P?B`P]B;0#W#K9K#W?S0_/IP#]9 MT)SN>:<<$STB=J2Q0PT+;'?D\HON3+:@25`['C4PSEU(&PU$'`.Q"B79H' M]0@L#!#P'H1HG^9!+(;G*`(^4-9D]).8#G#(.?J"(0T^Q[C&PL8YN#2*^J[\ M``GQ#>"#8\Y_E;E51Y';X>R1%^64'>D MK#QF+4?1=Z$85*$81['G0K%? MA6*?H]AWH3BH0G'`41P`*#YTE%#1:GD12QAC"N[+,:0$%7;[%#K=#H;JJC@X M>.37"G=VO``88G^_R;*IGFE(R4M35UHO5U@N5U@M5U@L5U@K5U@JFZV4M%\Z M<'>Y=HUM+8UMK8QM+8SK=;'INJA(L#87R'_\]_8_ULOC_X7E45LN+6;_L[EJO7^OU:[U^@2C6Z]='6K^4 M?5SP(.AIR]F^WP!IW!TVL__M[WJ42`3SR+I3W@H/>;@7`P+]5!(RR!_O> M-IC27/5RQ7Z)X:@'NATP6<4\$NU5@>+I-,3#G@"Z3@J$3=)"@P*@(;"-._SN M)IF2`ZGB-<]Z$WQ#IWSPW7>!E:$X3J+O_GV>.51'#D_ZT*G!DWYU6R"#)O1I MA?JU.%FK=A/QQV5M3S;6!]9OKPL&'ZL+#"2#6EU2BQJSHHZ'C,%GTF'>W$'= M[F2RZ%&_D1U+[?1J$<*\B_V]51M-#>Z[V/_CCPJ:U8=[]92G==4<[5J9*GE3 MOVX3;SO\ZP5__14XVS=^!Y"FS.E>JJHIML&M0-S178&+J%*-I$2N&%@V4H<1? MY1P1E&C4X`^F"'^\:7I5@B*5*@9>&"8?&TMP/^C)W`\=_J]37:6CRK]E]XPJ MU&YE%-3;-*OCJ+J\OL;+(53>1E,Z/@HYDG@R,)PTX6,.`]9)LKB^F=XD/=B] M?U_AO^@G7':#HS4.WO$-DF1:)BD5%E%:AG-*)T&.QY#R2Y&)7*H8T7TH@5N2 M/"0F"G&?U,I%'QZ>%B_@%FEC#^:3,HQP557K*.[=OJ]W[0U\]7!IB/#3CA^B M6X(Y_1I#BT]_B_P1G>Z\%TPAA;)U*443)%%0:E\78*.Y(<$DTJY//JDEW2-- M2B=#XL'\M818W=$W:#18:FESE783<\`VI,%O(?F,!C!CEBM_\-D-<+UW(9#! MUS@'KO7AY[AN7SV.Z^%I>;@"XW1#<%E;:_\4VYMM3%Q$+@I%_6&]59BKXIJ[ M6W=#@4*:51=IZ`Y`;15'@/\D5Y"B;=*/YEY!0G=?;[\A=&X+_=#>$F%$O4I$ M/8JHIR&JJ8]$VUP7P7\UT4.B;9<.@G*Z@OQ^)?E]2GY?)=\T.:C(:6-I!5[$ M@S=*@\P-M8V14L$:Q8,^0)I5)<@P^.#0OR!Y`$UL\[/O1/M"50;^B"8XV-UV MG:LZ=JVM157!-`SJGE7>"_K>VU!]"L$CR^[&][ZZV'ID8]^G6R24H>MM!ODI&`OU;6(S!O!5K4>\\I>U]# M'TYS-'`0B!ZCN>+=.1Y5;C*-K@MY9Z_O:C;N\_Z^MPMIG^-K/X_\761REV30 M"W\Z;V4&OHID9SCZCKFH58,V^-@]*_PIQ1$6Q`D*01JBAO<-0<Y<^ M7:C`[>V8]^,^HQ[:V_E,^P@3MFPO^>KP5T&[<&]'O#^)9CJ[-VS,7T4.XC07 M+8$B#Q41YXNMB76,.,]9S'<5+4'1=96E@\^L'*=:EZUQ(GWP71:2D+:DITQI MJ8VKM3(0/>1J*=103+Q:KJJQO$%8RW:L;K2E?RPRY=58I,>`2XD5%7"I.BP, M=I)*\PU>KH_=&XTB..,PA$$*_QTQ2L.#HE%$9C]F[%+%^ M<8SS1WF^U]]%';./:+_09EK]-61>QLK32&CHE#?<@4@M0$Q+K)0\5.JI_K;4 MSL`P(!2PL8?8A)A%:(L:HMBO#]HOS5ID(E$1X6WJGP8L_N[?)Z0,.V:R;F5B MG$&[^T6LIW_HF'\Y3YFXC4VWL&TH+?OK+\;;GP)YGE#=L`]`PQX\J-FP#P#; MQ7F:!@F9C10`FS\]THE-(C+#EW!A4B@4SM@\W8KH+// M'L*L`*-)"`7EMW_R,T!MDM,9H<+R4";F?$#"BB>SF8U2R+%SP*+QX'?K^:]L M.AYEB[0D7,5=P8@W;'AXE!`Z@/0-TKK@N^!_-S9ZP7_\!QI&?]$_>OR//O]C MT$7PY*\]GK3#_]@5>?L\Z9'`M"TR>P)K3Z#M#<1?.^R0;%L7`&Q)2S,2.`D_ MU!AL($#4F'Z?,YR/D0<]9=Q@GGPCFLA;@28*'8:$*0]^8@JX\%'"I?0R/3ZY M.$66T*M]WHB%"IG%Y(\JZYX8O@1:VO:T]*[@`::N"A5%D M#3W;O#=IZ M?>C6J6NP>EW>['Y]4G8^.BG>[$%]2G<_-:7>[)WZ#=G[S!OBS=ZMW\[]+[N= MWNR]^FPX^*K9X,W>YURRUHP?`B4J,I?A8I4WP94H6G)MP\LN6M;`O1I9;M1U M%VL*M(!#4>#*@J[1"S4+TJZ)%LGU)4O5-C<1*F*\_#/253"^_R'9WP#[%G./ MH^!169#3*WJ]KKFYP5R@93Q<<'&B16Y0COCY@]4CU#:N"-V_CQ.[U,?0&@N0 MXKO;!;I7IT$JQ,1VS7?L;I!;R#4":A'5,A&T486F\`EC@.XY:=H%)/TZ:?3E M3^I2:36MGK9'>>I4]7@_^'4\T3$>!8_"".U.=+!+K:M'?C#W$$\%Q`,&XZ0> MY_MIQQ"""W)R90K<>2W(RX]*G3NO!6UIORYM&2M*;>L*>U\^'.8L><6 MQ=3NB`84-60;)]YH@=W&]U'","J*."_#292@-?9;`/;;+=\)\E:PN[V/9^G+ M\Z/+R]_#IZ].'U\>GYV&(>KE;>7P73#)-L6:=E54/S6(P@XSFM$5>P>970T- MSBZ$:2`Q\?OGN$;N?D+MR:9+P<-_*%Z4S!U"%``,Y=*.3&Z$&50JCA[$O0,- M=E85$EUDX/ROXP(?X$(/`'FW[P6AEN&+<%WP]D"HXN8L4!1N,''I@PTIM;LA@ M)"WY;=!J/I*[!FN#2]7'3%C[:!C'MFL?C?8I7?MHM+.=^$+:N?;1J,.&>CX: M?'W0]B54<`M=B<%TB3R1@@E@L@&U=KY2:+$6(E2HS33H^5&Z9@K\L M5UM#HV:*K!)Y0E%E*_9`G#$>MP:GA[#=8(^_@U-WQ-V1J,T!T-$QB`8AO8RM M,93X)6/=HXJ/QK=)'&NSB5"SK.ZU"/%XP+`^Z&FZ[80\%4YX&218T=&I'J*! MGKC&#JGR=?+&KY.3#N8^[K;K".*+4:78KM38@[")8>Y!M#LG#*0G@Q;@^Q9Z MZD-M\^+P>K[)9C&YKH2F98PD[RW:B#X_>W'TK;;14KM'EK!<]GF6(BFJ_6** MQ6@4%X6YAV9[`548\8]Y9M-7UVE`L_<%:A2.%7+Q.#PY>W9\&IX>OC@*7QS^ MB_LA&15C=W16GD@2P#[`T?3F_"$(GAE0'@9$!$=T2[H)7*\!&$*EQ)_OS00_J4/PI[>QM]W<@ M$G@K_!W,$<$$B5BRJ)?G=ZA[92]_1TINB6JV!$TXSR--O[%6//Y!G<_9XKB@ M@JUY.^[*7!@)?WR.=?JG7):"O@^.'-%)FVCRN8HW[B88C?L"#QZ&CF(?W%;/ MN?-^B_HI4G?^X*?Y'?Z[VN]2KZE5.6S?*]H!2+=-=_33E`R@C=_^[[=#HRW6 MLF(O:7K]4F7EB$U3I+>%MFF)?TP"$JRZW8Y79(V":D.1P':?*^*6G*AG+/I. M\F5%@Y&&R6\TTD#K&HYJGFX+IGH.N3GW*@ZY):J*LVX)*!HC.JBA'4SB6OG0 MV\#D!6CC"+Q9?14`;9R+MTQ0!4`;9^9_-\45`&T*345X)TL*Z\3DWKA*DA37D"V]_)4@+*\K7SZ)*$/^)S7K'M-XQK7=, MZQW3>L>TWC%])DSYF#LF96E4W!-`%VEI[+4MMFJ4NJI#;MJ(.!V'_,BN7B2L MASP2UL,:D;#&W)&!0,M(6%JZ?LRMLGA1Q'DH'2-M`&GO-DSFLEV>(P>!'K6> ML]7P;5[!>%YM"1=$/N#5VZ;PQBZ42D,\6A%0M5<]TK#Z%20-5*A(=H5-E245 M[ZKJDHVK`J0%E6F).BM!6E"YAV2ZBD/X`*6,JO*XW5/@?57AQ5?@= M45[!'D>5OD9-O8QT;S'(N\CC553/407V)@+]B$2/0,Y$BBL1Z#%D>_8LXR4$ M^P?5\@QR^@39WD!>+R"%K1YNFJ4:NOM8CCYU7'RJG7L`?QFED(.%'YR.F#YR M/JH?C!$B%Q5Q;$G8E4>.D$.MYE@CJM6N8_&O\9Y"$+5JD#6)R+^'D'"M!UM; MFXS7)N.UR7AM,EZ;C- MQZSW,>M]S)>\C^$KHQ8<4`_,L9P+#&!+=MSE=+R6HH5AX[$-Z@978U9@Y9'J MHA2&6/WIXX(\3.T(Q\9BQJF6:_P`H`GQR#ZX^B>"VI2Q%MA#S6/N>?,=>\IB M&SAO(-H"TA?*[U&/S+)QC*,O!-N]_6WTD5(;V]L[Y(==+PG?]XZU;6,@#MU( ME7L[M%)9Q=Y.G4JZ73C:'#ZN0H.@0;`)6=:(;*&U0XWPD<%,:`A]B<_80F-$QF5IB&K`#]/7=(`.P(CC]M"RG>'A/,"S@Q+"2*(9T2Z M\3QEH'.;%5@[,B:\E!=%](BK)#]HK?H%3-BT%ZWJ\3" M9&C9$["HD`B[DL?728&P\;A`;CG]J&N>+.NO-6&LWV-1-$>K'CT%E>*)I@T! M<"2`QB8X2X/`1].LB$UXG@@5(,N3"HP3(,"I!3G503_(%0X_>6L%M((EIA7Y M!X=J$$M?(-^OK12X?\F.<`%SD+Y$W!MT7<]_BW!;V$.WT)YL94W4^YN-2O[B MKQQ71N`EP5(Z+_2P2^8"ETW'XMVM>\&C7D7$3J6T*`F]X27!M-X2C[1S#6=+ M(Q9'@*I>^7B7*M&5982Q'2>[(<[#@ MM_/AJ,S&(%"S/MAR7GL[OAFGOS/%LNQO4_.IP&0J3@_DT*E885IBEG/M$2*% M#:@?V8@ZT-WCH8#-)@_P:.&1R1SQO^P=@AGLQ6P_4T/X9#&T$9[NJF&//WAHX\\*RMYD>?"1I:K55`4P)0H8@4R\6F\KTT`0?/P1[:=Z$\H_ MYV:4;42_@3>B_$-;WF^6WY'R#]J9BEUI;0KJ;ECA*&O@ZL0_W[:-[U=X)Z%) M46].6-]]35B!(W?Y#0C_7&'2ZLP;'<[]\@'^W',,?Q_`L5MO!RQ%M_.`1>.C M=Z>LK0.>K;*$$R&P=7'Y,Z M=UX;YU.?BG)W7ALG4)]CJ]QY;1PO?6DM=N>I$4"`4R./B"5Z&R\%.L.196AE MF2N1N/+:D+EU:G'GM2%S5Z7`G=>&S/V8U+GSVI"YGXIR=UX;,O=S;)4[KPV9 M^Z6UV)TG9&YO.:^SM3J^5L?7ZOA:'?^"6K56Q_]V=1RM-5OD32"@-F'A6E4$ M&XA\^2V(XD:U^?-;$,NM4N//;T%,_ZW4^O-;$-V?56O\^2V(]"^JM?[\%L3] M5\4-?[Y8#O1#CF4V#>M3A_4V9[W-66]S/A/U>+W-66]SUJ<.ZU.']:E#NY2O M3QUDWOK40%@W7Q5U86_9"&OVW`\:3D#>*&:/HG6'Z MHU$X")HG+@;QBVOT?E#E73#]RE"MVSKP'1VSQY(WOM@1*T2.L&[G.&KF(23< M==>^H>,:).P^E'X7RB8';R>,\-M4UB'!A`JZQ#!IB'WSADG#BMLU]KV:ZILR MKCLR>ECQ>GLQ;+G?IC6IR;8MJU>3(ZCT'^9#F)&-NEW337DCR++2[FN@(H8VUCIBT3EG?H'0C,Q M2AKJ_U8PRJ;3J(S':#V9S:,\%BIR1XWT0F-L=3"A'7-IZ[#EC,5C8;%:J,XR M[/S9@:]W0QL+OHR:L5UHJGD;VU30;>7*9*?!I/L!ZD7W!H>V471.#61BS/B+ M"A83KF+=*AGAIG;,O@@VHJV`,UA=K8-H""0R;JOSB/Y=]!#7-C?LC$T*W*7X M@(+]JH)70S[<<25(+^M3#07D]U:0:JRE[6,PG+]T]T[@61)30U/*;#%463(9K?+F/AP%:RBM'S,"-H7C,K8?_X+'P!#[$U7M!K[?[J#+DC#EG4F66B'!XE-IX6NK4DD8S MA5IHJ:HJ;47M8@32J&H4G[;?]2G2J@K-7A%*]*TN,+$HB0\>*%//'%7TDU?. M93V4^C@=:R^X-`_$YH2H//T8+Q6IC0Z1BNB^P((Z5J*YM?!,HTM]D-GM/<]8 MIRYO=GM/,K9`BC>[O2<8/SZEWNSVGEO\Y`WQ9K?WK.+GWDYO=GM/)W[A;/!F MJPQ7X\EB].\R6+K%;W[P=$+9#)]=8LN9Z['R"F:[9WT=+4`L^J)>'D M<\-4Q7`M6[AQ`/<$HE47+@.1+[^%I:M1;?[\%E:O5JGQY[>P@OVMU/KS6UC& M/JO6^/-;6,R^J-;Z\UM8T[XJ;OCSY;._;!71UC8JW#FX`)*KVP?5`0#V]7;M/\41$/\*P?#\GEDRS;[N!T==AB/[,DZM%&9/)>X?PHY$X3:(B MV/C6+/ZM[H^B&I.T`W\Q@-"O>%1F^7O7B7_5V#*L3Q29,NZ8EXGXO;')*D#3 M3RV[A7/Y#`&LL,Q*6)2(P3/;U86==V/X:9*^U4U$>AXV`+TK#9.0,)I]`+#1 M_`*HE5G3)MDB'?,)-(O+B/^-GSDF8PHGDK>3G5,9"B7.#8NT-'_CP(ALO=/] MBSD*]*#HXT:,VQTAA2C5=*K3T4K]2JP:51N6>>*/J"2/1]32X?&DINHY_0L( MRA^&>72'CT)NU%%*P>F1AYW1[9IV.>24'NW3<)3/YMDP`3NR99 MP?_)0)-L$/@]S6LYFG-,U>[F'+*NP96/28=')4/7AJ.YALH/T9+3>:,:JR!: M_PS;5071DH/[%]GR*HB67.&_4MY40?@MO'*A M4+8-PM`+X5Y?7EU?7EU?7K7RUI=7UY=75[R\NMY8K#<6GUQI66\LOJQVK3<6 MZXW%E[BQ\`7_Y";'59<1'8\GNX4%I$%=WNP6UHWV2/%FM[!6_&V4>K-;6!P^ MEX9XLUM8"KZ0=GJS6Y#Z7P<;O-E"NJO'2?]GPGJNMV+KK=@G5_/66[$OJUWK MK=AZ*_8E;L5\9MGU&<_ZC,=)W?J,9WW&LS[C69_QK#<6ZXW%YZ!JK3<6ZXW% M>F/Q^6PLE#,>X=ZOF!.[:MP1?A^G(O[@/P,@^*"D`X<<5,$QN6JP0`UR;X=> M,]CN=F302N!N1<7E"NUB"HGR0]O*XZ5H=YK^[*CQ,<4=%.MV"G2%@(=*,H#U MR%`$Y8.?S`L)/")*3P,F,5#4`IZ@@M=9F>&(5JB3PSC/L]Q1*VDVO4T&`*`Y MZ`YJ*SBLQ2!D]VRVU>`I]+]:V%8U7HMRI:@BFB7[]&&%[X2-<8QWYSK)S^YP_#6*UTNNJ:4S M$1AYPPI^MM\E`2I9(#34D]NNALH66\-I3T'28TC`F-'69\7?=+/#D$@'4B+Q MCX4G`H(OVW%`]>M]2F0I[9.A3<%<*H#PV$%\WD14@TVN._DP"PV472W&+)HS M8SH?Z?QQX<'2GL&BRI\46W(5 M53_U%N#&QKC+>>$L@*AT+\#RWA]ESIW7 M@C'ADU'NSFO!4/!9MLJ=U\+V_XMKL3M/;.>!1WH!N4K_I;MY]]K#-WMNS9>B MI%L_LA%TKIQL/VS$,5:_^_=E:`;[^V"EZBG.]QFX^FT%9&!6@"X8HM0?2,#> MSK:\WZ_<5%<8`TQ=I*XYP*UM--8NJL,95"H82\O^&IOA,L7ZV`+KZEM M5+Z<<)_K$=6OJ]F/J:DKN_4R6N/5G82.&S(M1K6)$X#A?N#!H%1?/`U![ON_M"/OU+]4.JIHY1].L MB#4[)V^U9N\.!:!EY)0'4XX3`ZQZHG91/C#+O*KZ_C,88"LVSE9'``Z91]O# M(Z!Y.>-O=)TF*PVN;&YE4RE'F)$<&KQVAZE:L.M!#B,DI%*D:^K[RIR0720C .#:+Q]O\!-6U&P&H/`P!E ` end From alan@linuxcare.com.au Fri, 10 Nov 2000 11:36:56 +1100 (EST) Date: Fri, 10 Nov 2000 11:36:56 +1100 (EST) From: Alan Modra alan@linuxcare.com.au Subject: abort in eliminate_regs compiling glob.c from glibc On Thu, 9 Nov 2000, John David Anglin wrote: > > Breakpoint 2, eliminate_regs_in_insn (insn=0x406a0ba0, replace=0) > > at ../../gcc/reload1.c:2826 > > 2826 if (! insn_is_asm && icode < 0) > > (gdb) p debug_rtx (insn) > > (insn/s 2711 2709 2719 (set (reg:SI 6 %r6) > > (reg:SI 28 %r28)) 69 {pre_ldw-4} (insn_list 2708 (insn_list:REG_DEP_ANTI 2696 (insn_list:REG_DEP_ANTI 2702 (insn_list:REG_DEP_ANTI 2697 (nil))))) > > (expr_list:REG_DEAD (reg:SI 28 %r28) > > (insn_list:REG_RETVAL 2708 (expr_list:REG_EQUAL (expr_list (use (mem:BLK (scratch) 0)) > > (expr_list (symbol_ref/v:SI ("@strlen")) > > (expr_list (reg/v:SI 4 %r4) > > (nil)))) > > (nil))))) > > The `use' arises from the `__pure__' attribute in the prototype for strlen: > > extern size_t strlen (__const char *__s) __attribute__ ((__pure__)); I don't see this problem using current puffin CVS hppa64-linux gcc. Was this with your REG_ELIMINATE patch? Alan Modra -- Linuxcare. Support for the Revolution. From dave@hiauly1.hia.nrc.ca Thu, 9 Nov 2000 21:50:49 -0500 (EST) Date: Thu, 9 Nov 2000 21:50:49 -0500 (EST) From: John David Anglin dave@hiauly1.hia.nrc.ca Subject: abort in eliminate_regs compiling glob.c from glibc > > > 2826 if (! insn_is_asm && icode < 0) > > > (gdb) p debug_rtx (insn) > > > (insn/s 2711 2709 2719 (set (reg:SI 6 %r6) > > > (reg:SI 28 %r28)) 69 {pre_ldw-4} (insn_list 2708 (insn_list:REG_DEP_ANTI 2696 (insn_list:REG_DEP_ANTI 2702 (insn_list:REG_DEP_ANTI 2697 (nil))))) > > > (expr_list:REG_DEAD (reg:SI 28 %r28) > > > (insn_list:REG_RETVAL 2708 (expr_list:REG_EQUAL (expr_list (use (mem:BLK (scratch) 0)) > > > (expr_list (symbol_ref/v:SI ("@strlen")) > > > (expr_list (reg/v:SI 4 %r4) > > > (nil)))) > > > (nil))))) > > > > The `use' arises from the `__pure__' attribute in the prototype for strlen: > > > > extern size_t strlen (__const char *__s) __attribute__ ((__pure__)); > > I don't see this problem using current puffin CVS hppa64-linux gcc. Was > this with your REG_ELIMINATE patch? No. Well actually I saw it first with the patch. I see this with the 32 bit compiler. The only elimination with the 32 bit compiler is the default frame pointer elimination. I just tried the hppa64-linux-gcc compiler with the source that I posted and it didn't abort. There were lots of warnings about int to pointer conversions though. Make sure you compile with -O2 or -O3? Register elimination only occurs at -O2 or above. I see the problem both with a i686-linux cross compiler and a fairly recent native hpux compiler under hpux 10.20. The problem is not present in 2.95.2 but it doesn't support the pure atribute. Dave -- J. David Anglin dave.anglin@nrc.ca National Research Council of Canada (613) 990-0752 (FAX: 952-6605) From matthew@wil.cx Fri, 10 Nov 2000 09:49:07 +0000 Date: Fri, 10 Nov 2000 09:49:07 +0000 From: Matthew Wilcox matthew@wil.cx Subject: linux bame On Thu, Nov 09, 2000 at 03:53:48PM -0700, Paul Bame wrote: > Somebody never imported 2.4.0-test6, then I imported -test10 on the main > vendor branch and now can't (easily) undo that to import test6 and THEN > test10. This workaround sucks. don't use vendor branches. didn't you talk to mang about this? -- Revolutions do not require corporate support. From matthew@wil.cx Fri, 10 Nov 2000 10:18:08 +0000 Date: Fri, 10 Nov 2000 10:18:08 +0000 From: Matthew Wilcox matthew@wil.cx Subject: [parisc-linux] tulip DMA mapping On Thu, Nov 09, 2000 at 12:12:25PM -0800, Grant Grundler wrote: > 0 is a valid pci_map_single() return value when the system has an IO MMU. Oh dear. You can bet tulip won't be the only driver which assumes it isn't a valid return value. Can't our IOMMU code be limited in such a way that 0 is not a valid return value? Say, constrain all allocated addresses to the top half of the device bus? (um, just check me on this, map_single returns a device bus address, not a processor bus address, right?) > The system will panic before pci_map_single() will fail. > The driver needs to remember some other way if a buffer was mapped or not. > Or the Documentation/DMA-mapping.txt should be changed - ie add this > to the interface definition and I can reserve the 1st mapping > entry so no-one uses it. we should probably have a BAD_DMA_ADDR define which that array should be initialised to. it's a little late in 2.4 to go through and audit all the drivers again. > Should I be mailing Jeff Garzik directly? > Or can someone who knows Jeff point this out to him? i've cc'd jeff & dave miller on this. -- Revolutions do not require corporate support. From davem@redhat.com Fri, 10 Nov 2000 02:16:11 -0800 Date: Fri, 10 Nov 2000 02:16:11 -0800 From: David S. Miller davem@redhat.com Subject: [parisc-linux] tulip DMA mapping Date: Fri, 10 Nov 2000 10:18:08 +0000 From: Matthew Wilcox > Should I be mailing Jeff Garzik directly? > Or can someone who knows Jeff point this out to him? i've cc'd jeff & dave miller on this. In 2.4.x there is _NO_ error return from the PCI dma functions except the consistent DMA mapping ones. This was an explicit design decision, the dynamic mapping functions should never fail, and if they do it is a hard error. Therefore no drivers need to check for failure, as far as they are concerned, there is no failure. So what is the issue? In 2.5.x I'll add an error return facility (BTW: -1 ie. 0xfffffff would probably work as an error value on all platforms :-) Later, David S. Miller davem@redhat.com From rhirst@linuxcare.com Fri, 10 Nov 2000 10:55:16 +0000 Date: Fri, 10 Nov 2000 10:55:16 +0000 From: Richard Hirst rhirst@linuxcare.com Subject: [parisc-linux] parisc-linux reaches uptimes in excess of one day! Just for interest... My A180 has been up for 25 hours, the first 12 of which I had a couple of telnet sessions open running vi, gcc, etc. and since then it has been looping doing kernel builds. I also ran cvs to update its kernel source tree from pehc. So far it has completed about 23 kernel builds with one hiccup: do_page_fault() pid=2420 command='cpp0' YZrvWESTHLNXBCVMcbcbcbcbOGFRQPDI PSW: 00000000000001100000000000001011 r0-3 00000000 4013ac38 400e134f 00000004 r4-7 40138c38 ffffffb5 2002014b 00000001 r8-11 00000004 00000000 00000000 4001ada0 r12-15 4001ad7c 0001b300 2001f601 00000001 r16-19 00012000 00000023 00000020 40138c38 r20-23 20020100 4012a51c 00000000 9999999a r24-27 2002016c 2002014c 00000004 00013d34 r28-31 00000000 4013a438 200201c0 40041757 sr0-4 00000000 00000011 00000000 00000011 sr4-8 00000011 00000011 00000011 00000011 IASQ: 00000011 00000011 IAOQ: 400e13b7 400e13bb IIR: 0c601094 ISR: 00000011 IOR: 00000004 ORIG_R28: 40019450 Richard From rhirst@linuxcare.com Fri, 10 Nov 2000 11:12:20 +0000 Date: Fri, 10 Nov 2000 11:12:20 +0000 From: Richard Hirst rhirst@linuxcare.com Subject: [parisc-linux] tulip DMA mapping I've quoted the whole of Grants message below, so you can see the context. It looks like tulip is treating zero as meaning it doesn't have anything to pci_unmap... Grant Grundler wrote: > Hi all, > I see a "bug" in tulip's usage of mapping services. > It's not the bug I was looking for unfortunately. > > In line 217 of drivers/net/tulip/interrupt.c: > > if (tp->tx_buffers[entry].mapping) > pci_unmap_single(tp->pdev, > tp->tx_buffers[entry].mapping, > sizeof(tp->setup_frame), > PCI_DMA_TODEVICE); > > 0 is a valid pci_map_single() return value when the system has an IO MMU. > > The system will panic before pci_map_single() will fail. > The driver needs to remember some other way if a buffer was mapped or not. > Or the Documentation/DMA-mapping.txt should be changed - ie add this > to the interface definition and I can reserve the 1st mapping > entry so no-one uses it. Richard On Fri, Nov 10, 2000 at 02:16:11AM -0800, David S. Miller wrote: > Date: Fri, 10 Nov 2000 10:18:08 +0000 > From: Matthew Wilcox > > > Should I be mailing Jeff Garzik directly? > > Or can someone who knows Jeff point this out to him? > > i've cc'd jeff & dave miller on this. > > In 2.4.x there is _NO_ error return from the PCI dma functions except > the consistent DMA mapping ones. > > This was an explicit design decision, the dynamic mapping functions > should never fail, and if they do it is a hard error. > > Therefore no drivers need to check for failure, as far as they are > concerned, there is no failure. > > So what is the issue? In 2.5.x I'll add an error return facility > (BTW: -1 ie. 0xfffffff would probably work as an error value on all > platforms :-) > > Later, > David S. Miller > davem@redhat.com > > --------------------------------------------------------------------------- > To unsubscribe: send e-mail to parisc-linux-request@thepuffingroup.com with > `unsubscribe' as the subject. > > From davem@redhat.com Fri, 10 Nov 2000 03:26:48 -0800 Date: Fri, 10 Nov 2000 03:26:48 -0800 From: David S. Miller davem@redhat.com Subject: [parisc-linux] tulip DMA mapping Date: Fri, 10 Nov 2000 11:12:20 +0000 From: Richard Hirst I've quoted the whole of Grants message below, so you can see the context. It looks like tulip is treating zero as meaning it doesn't have anything to pci_unmap... Thank you for the clarification. Jeff, this is in fact a bug, please fix :-) Later, David S. Miller davem@redhat.com From jgarzik@mandrakesoft.com Fri, 10 Nov 2000 09:30:41 -0500 Date: Fri, 10 Nov 2000 09:30:41 -0500 From: Jeff Garzik jgarzik@mandrakesoft.com Subject: [parisc-linux] tulip DMA mapping "David S. Miller" wrote: > > Date: Fri, 10 Nov 2000 11:12:20 +0000 > From: Richard Hirst > > I've quoted the whole of Grants message below, so you can see the > context. It looks like tulip is treating zero as meaning it > doesn't have anything to pci_unmap... > > Thank you for the clarification. > > Jeff, this is in fact a bug, please fix :-) np. Like Matthew(?) hinted, this is not the only place that needs fixing. I'll take care of it. Jeff -- Jeff Garzik | Building 1024 | Would you like a Twinkie? MandrakeSoft | From bame@riverrock.org Fri, 10 Nov 2000 08:57:47 -0700 Date: Fri, 10 Nov 2000 08:57:47 -0700 From: bame@riverrock.org bame@riverrock.org Subject: linux bame = On Thu, Nov 09, 2000 at 03:53:48PM -0700, Paul Bame wrote: = > Somebody never imported 2.4.0-test6, then I imported -test10 on the mai n = > vendor branch and now can't (easily) undo that to import test6 and THEN = > test10. This workaround sucks. = = don't use vendor branches. didn't you talk to mang about this? Um, I have no information to go on from your note. All the (successful) merges I've done before have used the cookbook CVS merge method including a vendor branch. Several (N-1?) of the palinux merges have been accompanied by updating the vendor branch. And this merge is going well despite the ugly workaround, or so it appears to me. Just importing files to a vendor branch should have no effect on anything else unless CVS has some horrible bug (RCS does not). Before I make what is apparently a serious mistake ("don't use vendor branches" sounds pretty serious) please enlighten me! -P From grundler@cup.hp.com Fri, 10 Nov 2000 08:29:25 -0800 Date: Fri, 10 Nov 2000 08:29:25 -0800 From: Grant Grundler grundler@cup.hp.com Subject: [parisc-linux] tulip DMA mapping Mathew, I think the situation is clarified. This is just FYI. Matthew Wilcox wrote: > On Thu, Nov 09, 2000 at 12:12:25PM -0800, Grant Grundler wrote: > > 0 is a valid pci_map_single() return value when the system has an IO MMU. > > Oh dear. You can bet tulip won't be the only driver which assumes it > isn't a valid return value. Well, then: 1) the driver writer made a wrong assumption that the "spec" does not support. 2) that wasn't the case here - 0 was used as a flag to indicate a mapping had (or hadn't rather) been done - not that the mapping call had failed. > Can't our IOMMU code be limited in such a > way that 0 is not a valid return value? Say, constrain all allocated > addresses to the top half of the device bus? It could pretty easily by reserving the dma_map[0] entry during init time. Dave Miller already made it clear that's not desirable. > (um, just check me on this, map_single returns a device bus address, > not a processor bus address, right?) Yes. It's the address a device must use to master DMA transactions. pci_map_single() input parameters are "struct pci_dev *", virtual host memory address, and buffer size. The return is a device specific I/O DMA address - ie this mapping cannot be shared with other devices. FWIW, "I/O DMA address" are called IOVAs in HPUX (I/O Virtual Address). The HW guys prefer another name but this one stuck. grant Grant Grundler Unix Systems Enablement Lab +1.408.447.7253 From bame@riverrock.org Fri, 10 Nov 2000 14:28:33 -0700 Date: Fri, 10 Nov 2000 14:28:33 -0700 From: bame@riverrock.org bame@riverrock.org Subject: [parisc-linux] kernel merge = = We're getting ready to do a kernel merge (to -test10 I think). Anybody = concerns before we get started? = I'm getting ready to commit the changes to merge us up to 2.4.0-test10 as soon as I'm confident 64-bit kernels are OK (32-bit seems fine). Here's a brief list of changes made (and yet to be made -- if anyone has the time/energy) to our parisc code (does not include changes in common code!). While there's plenty yet to do, I think we're no worse off than before the merge. Some parts of our parisc code are getting rather moldy compared to the other ports FYI. Important tags: LINUS_240_TEST6 Linus' 2.4.0-test6 LINUS_240_TEST10 Linus' 2.4.0-test10 LINUS_240_TEST10_PREMERGE Our tree before the -test10 merge LINUS_240_TEST10_MERGED Our tree after the -test10 merge ------------ Lots of 'extern __inline__' turned into 'static __inline__' and there are more to do (TODO). Beginnings of several smp_mb*() macros -- implemented as no-ops in the non-SMP case (asm/bitops.h, asm/system.h) SET_PERSONALITY() macro in asm/elf.h needs updating (TODO). fcntl.h acquired a 'struct fcntl64' used with 64-bit offsets, implementing fcntl(fd, F_S/GETLK[W]64, ...). Several other locking-related #defines added. asm/mmu_context.h:init_new_context() now returns int (always 0), not void. Should our asm/bitops.h routines be re-coded in assembly? (TODO) Added #define RLIMIT_LOCKS to asm/resource.h Added #define CLOCKS_PER_SEC to asm/param.h (how did we miss this one?) Our asm/string.h is behind the times. Fixing it might get rid of a bunch of compiler warnings! (TODO) Removed mktime from drivers/char/genrtc.c (it's in a header file now) x86 made a bunch of changes to asm-i386/floppy.h -- should we? (TODO) looks like maybe the get/put_user_ret() functions in asm/uaccess.h are obsolete? (TODO) We'll need to add the getdents64() and fcntl64() syscall glue. (TODO!!!) Our arch/parisc/config.in is in BAD SHAPE (TODO) arch/parisc/process.c: added new argsto do_fork() and copy_thread(). IA64 seems to use the copy_thread() arg. arch/parisc/signal.c: minor change to common data structure drivers/scsi sym53c8xx_comm.h #ifdef doesn't work on parisc -- eliminates unmap_pci_mem() causing link error (TODO - rhirst) From pjlahaie@linuxcare.com Fri, 10 Nov 2000 17:14:06 -0500 Date: Fri, 10 Nov 2000 17:14:06 -0500 From: Paul J.Y. Lahaie pjlahaie@linuxcare.com Subject: [parisc-linux] Beta CD --uXxzq0nDebZQVNAZ Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Hello fellow PA-RISCers, An preliminary beta CD for PA/Linux has been uploaded to puffin.external.hp.com. If people could try it and forward any complaints or suggestions to me, it would be greatly appreciated. The URL for the image is: ftp://puffin.external.hp.com/pub/parisc/cd-images/palinux-0.5.iso.gz - Paul --uXxzq0nDebZQVNAZ Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.4 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE6DHMu8ggPQthPCzcRAgb0AJ4jJs5VOnm+9aDXUbtwht7hxAa+UwCgihAo nEE25pYQwBwCDuALcSdyCNw= =bTuw -----END PGP SIGNATURE----- --uXxzq0nDebZQVNAZ-- From randolph@tausq.org Fri, 10 Nov 2000 19:18:47 -0700 Date: Fri, 10 Nov 2000 19:18:47 -0700 From: Randolph Chung randolph@tausq.org Subject: [parisc-linux] kernel merge > Our asm/string.h is behind the times. Fixing it might get rid of a > bunch of compiler warnings! (TODO) if this is just an issue of implementing the various parisc-optimized string routines, i've been working on this, but don't have everything ready yet. randolph -- @..@ http://www.TauSq.org/ (----) ( >__< ) ^^ ~~ ^^ From crypt@ihug.co.nz Sun, 12 Nov 2000 01:47:56 +1300 Date: Sun, 12 Nov 2000 01:47:56 +1300 From: crypt@ihug.co.nz crypt@ihug.co.nz Subject: [parisc-linux] HP 9000 e25 Considering how often this question comes up is there anyone out there that is interested in tracking down the info to port linux to this class of box. Server boxes may be classed as boring to some but there seem to be a large number of people who have at least one of them sitting about doing nothing. Joe. -- ======================================================================= in real life: Joseph Skinner |There's no such thing as a wizard email: crypt@ihug.co.nz |who minds his own business Analyst/Programmer | - Berengis the Black | Court Mage to the Earls Caeline ======================================================================== From snaketails@optushome.com.au Sat, 11 Nov 2000 23:57:43 +1100 Date: Sat, 11 Nov 2000 23:57:43 +1100 From: Rod Smart snaketails@optushome.com.au Subject: [parisc-linux] PA-RISC newbie Hi there. I just purchased at a **VERY** cheap price, a HP Visualize C-180 RISC system from a CAD drafting company, this box included a 4Gb Hard disk, a video card with unknown amount of memory (& daughter board, assuming its memory upgrade) and system board RAM is fully loaded (768Megs). I would like to run this system on Linux, and found the PA-RISC web site from the www.linux.org web site :o) The system currently has HP-UX installed, but not having any usernames or passwords, I cannot access the system from the prompt. I have read how to NFS-boot the HPbox from the message board, but I couldn't figgure out where to find the kernel sources (or how I would be able to compile them on the HPbox anyway). I downloaded the vmlinux kernel file from the ftp site and the NFS-ROOT and installed both on my current Linux box (Pentium 133 pre-MMX) in the format of how it was layed out in ... LINUX/PA-RISC NFSROOT HOWTO In there it states that you have to get the latest linux-2.3 tree from CVS, but which CVS server I'm curious about as the ones on ftp.kernel.org don't have "parisc" in the /arch/ branch, so where do I find the CVS "tree" that I need to use? I seem to have the "STEP 2." section running, as from playing with the system I had found my way into the PDC prompt and have played with the "boot" function. I tried to boot the installation CD (on a drive I have borrowed from work) of HP-UX and reinstall so I have access, as I don't really care whats currently on the system.. I'm not confident enough on how to create and burn a bootable CD to try and boot the box that way, I still think the vmlinux kernel I downloaded from the PA-RISC website has something to do with my problems (or the permissions) I do know that the Hp is talking to the Linux box (apart from the lack of logged info) I get a report in /var/log/secure and messages that the HP box has attempted a bootp session, but the HP box reports something along the lines that the booting code was not found. So, if anyone has any ideas on how to help me, I would be appreciated ;o) Oh, what *is* the RAM modules in the Hp systems anyway (apart from the obvious 64Mx72-pin SIMM) Thank you for your time and help :o) PS. I would prefer replies to my E-mail address as I generally forget to surf the net reading mailing lists.... From andrew@neep.com.au Sat, 11 Nov 2000 23:12:55 +0800 Date: Sat, 11 Nov 2000 23:12:55 +0800 From: Andrew Shugg andrew@neep.com.au Subject: [parisc-linux] HP 9000 e25 > Considering how often this question comes up is there anyone out there > that is interested in tracking down the info to port linux to this class > of box. > > Server boxes may be classed as boring to some but there seem to be a > large number of people who have at least one of them sitting about doing > nothing. > > Joe. I don't perceive the problem to be a lack of willingness, or interest, but has already been stated the older systems contain a lot of proprietry stuff that isn't sufficiently documented for people to work on. Maybe as the parisc port grows more popular and attracts more resources, some enthusiastic people will get it happening. =) Andrew. -- Andrew Shugg http://www.neep.com.au/ "Just remember, Mr Fawlty, there's always someone worse off than yourself." "Is there? Well I'd like to meet him. I could do with a good laugh." From grundler@cup.hp.com Sat, 11 Nov 2000 15:29:14 -0800 Date: Sat, 11 Nov 2000 15:29:14 -0800 From: Grant Grundler grundler@cup.hp.com Subject: [parisc-linux] HP 9000 e25 Andrew Shugg wrote: > > Considering how often this question comes up is there anyone out there > > that is interested in tracking down the info to port linux to this class > > of box. > > > > Server boxes may be classed as boring to some but there seem to be a > > large number of people who have at least one of them sitting about doing > > nothing. > > > > Joe. > > I don't perceive the problem to be a lack of willingness, or interest, but > has already been stated the older systems contain a lot of proprietry stuff > that isn't sufficiently documented for people to work on. AFIAK, the chipsets for I/O devices in E25 have plenty of documentation. The issue is someone has to clean them up and get a lawyer to approve their publication. It's all about IP and avoiding lawsuits. This has been discussed before. Any HP employees interested in doing this "on their own time" can contact me and I'll help locate unpublished docs. Note that PDC is the same for Nova-Class (EFGHI-class) boxes as for the workstations for the most part. So someone could start by just trying to boot those boxes and see how far it gets before dying. > Maybe as the parisc port grows more popular and attracts more resources, > some enthusiastic people will get it happening. =) Having worked on the HPUX SCSI driver (scsi3 and scsi1) for E25 and similar boxes, I question anyone's sanity who volunteers to write drivers for SPIFI chips - even with full documentation. I would rather give folks that interested in contributing a 715/33! (or my gosh /50's!) Yes - I know folks who collect PDP's and keep them running in their garage...'nuf said. grant Grant Grundler Unix Systems Enablement Lab +1.408.447.7253 From grundler@cup.hp.com Sat, 11 Nov 2000 15:38:58 -0800 Date: Sat, 11 Nov 2000 15:38:58 -0800 From: Grant Grundler grundler@cup.hp.com Subject: [parisc-linux] PA-RISC newbie Rod Smart wrote: > Hi there. > > I just purchased at a **VERY** cheap price, a HP Visualize C-180 > RISC system from a CAD drafting company, this box included a 4Gb Hard > disk, a video card with unknown amount of memory (& daughter board, > assuming its memory upgrade) and system board RAM is fully loaded > (768Megs). > > I would like to run this system on Linux, and found the PA-RISC web > site from the www.linux.org web site :o) > > The system currently has HP-UX installed, but not having any > usernames or passwords, I cannot access the system from the prompt. Yes you can. You just need to know how. Interrupt the boot process to get a "BOOT ADMIN" prompt (or whatever it's called - Boot Console Handler). Then "boot primary isl" (shortened to bo pri isl) You should have an "ISL>" prompt now. ISL> hpux -is And you will boot to single user state with a shell. mountall and you should have the regular tools too. vi /etc/passwd to your hearts content. "There is no such thing at security with out physical security". .. > I'm not confident enough on how to create and burn a bootable CD to > try and boot the box that way, I still think the vmlinux kernel I > downloaded from the PA-RISC website has something to do with my problems > (or the permissions) > You can dd the ISO image to a regular hard disk (ie /dev/sdc) and move that disk over to the C180. Then boot from that disk. From BCH, use "sea" to locate all boot devices. grant Grant Grundler Unix Systems Enablement Lab +1.408.447.7253 From randolph@tausq.org Sat, 11 Nov 2000 17:04:29 -0700 Date: Sat, 11 Nov 2000 17:04:29 -0700 From: Randolph Chung randolph@tausq.org Subject: [parisc-linux] glibc question I'm working with bdale and taggart to try to get the Debian glibc package to compile under hppa. One of the things I saw today while playing with this is that the build dies because it tries to link in bsd-setjmp.c and bsd-_setjmp.c, which both define setjmp. Can someone enlighten me about why this may be happening? This is built from the glibc-2.2 sources, which I understand has all/most of the changes in pehc cvs. randolph -- @..@ http://www.TauSq.org/ (----) ( >__< ) ^^ ~~ ^^ From rajak@purdue.edu Sat, 11 Nov 2000 22:58:57 -0500 (EST) Date: Sat, 11 Nov 2000 22:58:57 -0500 (EST) From: Brian Poole rajak@purdue.edu Subject: [parisc-linux] Problems booting new beta CD Hello, My machine is a 715/80 with 88M of RAM, 1G HD, external 4x CD drive & floppy. Trying to get the new palinux CD working on my 715/80 here and not having too much success. Did get the CD to actually boot, but after all the normal Linux init messages (which were very nice to see btw, congratulations on how far it has already gotten ;) it stops at 'Switching from PDC console'. Looking thru the FAQ I saw a somewhat similar question, in that it had 'pdc' in it & was booting from the CD (but the 0.1 CD, not the one I am using), that said the kernel on the CD booted from/to the serial console. Is this also true of the 0.5 CD? If so, what is necessary to boot one of these from console? I've been fooling with it to no success.. I have it automatically booting from the CD, but it doesn't actually boot. I replug in the monitor & keyboard and find that it can't boot without the keyboard ('Failed to initiliaze a keyboard\n SYSTEM HALTED').. How am I supposed to boot to the console if I can't boot w/o a keyboard? I imagine if it has a keyboard it will boot to the screen like a Sun. Thanks for the help, -b From grundler@cup.hp.com Sat, 11 Nov 2000 23:31:37 -0800 Date: Sat, 11 Nov 2000 23:31:37 -0800 From: Grant Grundler grundler@cup.hp.com Subject: [parisc-linux] Problems booting new beta CD Brian Poole wrote: ... > Looking thru the FAQ Brian, Thank you for first reading the FAQ! > I saw a somewhat similar question, in that it had > 'pdc' in it & was booting from the CD (but the 0.1 CD, not the one I am > using), that said the kernel on the CD booted from/to the > serial console. Is this also true of the 0.5 CD? I think it is. Is there a way via PALO to direct the console to FBCON or STICON or whatever it's called now? I had the impression *eventually* the boot console would be whatever PDC says it is - ie graphics console for the 712. > If so, what is necessary to boot one of these from console? kernel with CONFIG_STI_CONSOLE I think....but that's not enabled by default. It may not be possible to use the graphics console unless one builds a "custom" kernel. > I've been fooling with it to no > success.. I have it automatically booting from the CD, but it doesn't > actually boot. I replug in the monitor & keyboard and find that it can't > boot without the keyboard ('Failed to initiliaze a keyboard\n SYSTEM > HALTED').. How am I supposed to boot to the console if I can't boot w/o a > keyboard? I imagine if it has a keyboard it will boot to the screen like a > Sun. AFAIK, 712's are the only parisc workstations what won't boot w/o keyboard. All others will auto-switch to use serial console if the keyboard is not connected. Both or the above questions sounds like a FAQ. Could someone who knows more update/add those to the FAQ? thanks, grant ps. The most up-to-date FAQ is at parisc-linux.org/faq.html even though that's not officially online yet. > > Thanks for the help, > > -b > > > > --------------------------------------------------------------------------- > To unsubscribe: send e-mail to parisc-linux-request@thepuffingroup.com with > `unsubscribe' as the subject. > Grant Grundler Unix Systems Enablement Lab +1.408.447.7253 From alan@linuxcare.com.au Sun, 12 Nov 2000 23:08:35 +1100 (EST) Date: Sun, 12 Nov 2000 23:08:35 +1100 (EST) From: Alan Modra alan@linuxcare.com.au Subject: [parisc-linux] glibc question On Sat, 11 Nov 2000, Randolph Chung wrote: > I'm working with bdale and taggart to try to get the Debian glibc > package to compile under hppa. One of the things I saw today while > playing with this is that the build dies because it tries to link in > bsd-setjmp.c and bsd-_setjmp.c, which both define setjmp. Can someone > enlighten me about why this may be happening? I think bsd-_setjmp.c should define _setjmp, not setjmp. Alan Modra -- Linuxcare. Support for the Revolution. From andrew@neep.com.au Mon, 13 Nov 2000 00:40:15 +0800 Date: Mon, 13 Nov 2000 00:40:15 +0800 From: Andrew Shugg andrew@neep.com.au Subject: [parisc-linux] HP 9000 e25 Grant Grundler said: > AFIAK, the chipsets for I/O devices in E25 have plenty of > documentation. The issue is someone has to clean them up and get a > lawyer to approve their publication. My bad, I should've said "public documentation". =) *prods LC FAQ maintainers* Andrew. -- Andrew Shugg http://www.neep.com.au/ "Just remember, Mr Fawlty, there's always someone worse off than yourself." "Is there? Well I'd like to meet him. I could do with a good laugh." From randolph@tausq.org Sun, 12 Nov 2000 11:06:38 -0700 Date: Sun, 12 Nov 2000 11:06:38 -0700 From: Randolph Chung randolph@tausq.org Subject: [parisc-linux] glibc build fails / bash bug Bdale, taggart and I have been looking at trying to build glibc on hppa from Debian's sources. What we saw was that it looks like a lot of the syscalls were not being reocognized as such by one part of the build, so it tries to build things from the sysdeps/generic directory and fails. After a lot of digging, I *think* what is at fault is actually bash. It looks like during the build, a shell script (make-syscalls.sh) parses through syscalls.list to generate syscall stubs that are needed for the build to happen correctly, but these are not being generated. What it boils down to, I think, is this: (on hppa - bdale's J5K) ============================= tausq@j5k:/space/tausq $ bash --version GNU bash, version 2.04.0(1)-release (hppa-unknown-linux-gnu) Copyright 1999 Free Software Foundation, Inc. tausq@j5k:/space/tausq $ dpkg -l |grep bash ii bash 2.04-7 The GNU Bourne Again SHell tausq@j5k:/space/tausq $ cat test.sh #!/bin/sh echo "1 2 3 4 5 a b c d e " | while read a b c d e; do echo $a $b $c $d $e done tausq@j5k:/space/tausq $ /bin/bash test.sh 1 2 3 4 5 ============================= (on other archs, tested with i386 and sparc) samwise[11:06] ~% bash --version GNU bash, version 2.04.0(1)-release (i386-pc-linux-gnu) Copyright 1999 Free Software Foundation, Inc. samwise[11:06] ~% dpkg -l |grep bash ii bash 2.04-7 The GNU Bourne Again SHell samwise[11:06] ~% /bin/bash test.sh 1 2 3 4 5 a b c d e This causes the parsing routines to die quite miserably.... Anyone feel like trying to fix this? :-) randolph -- @..@ http://www.TauSq.org/ (----) ( >__< ) ^^ ~~ ^^ From pdbeal@louisville.edu Sun, 12 Nov 2000 14:27:28 -0500 Date: Sun, 12 Nov 2000 14:27:28 -0500 From: Phillip D. Beal pdbeal@louisville.edu Subject: [parisc-linux] Beta CD On Fri, Nov 10, 2000 at 05:14:06PM -0500, Paul J.Y. Lahaie wrote: > Hello fellow PA-RISCers, > > An preliminary beta CD for PA/Linux has been uploaded to > puffin.external.hp.com. If people could try it and forward any complaints > or suggestions to me, it would be greatly appreciated. The URL for the > image is: ftp://puffin.external.hp.com/pub/parisc/cd-images/palinux-0.5.iso.gz > > - Paul The kernel dumps on an HP755. Actually, how do you make these CD's? I know how to use mkisofs to crerat a filesystem CD, but how you make it bootable with a kernel image? Thanks, -- Phillip Beal Electrical and Computer Engineering S+LUG Vice-President From bame@riverrock.org Sun, 12 Nov 2000 13:27:32 -0700 Date: Sun, 12 Nov 2000 13:27:32 -0700 From: bame@riverrock.org bame@riverrock.org Subject: [parisc-linux] glibc build fails / bash bug = After a lot of digging, I *think* what is at fault is actually bash. Bash has a bunch of 'set' options, some shell variables, and probably some compile-time configure options, which affect its behavior, so I'd compare all those. One possibility is that the bash configure script on hppa configures bash to be more like Posix, since that's what hp-ux shell users expect. The construct in question: echo "a b c 1 2 3" | while read x1 x2 x3 *depends* on the way echo breaks or doesn't break lines, and the way read parses them. Often scripts like that also depend on whether the shell actually makes a new subprocess for the 'while' or it doesn't, because that determines whether variables set in the loop will still be set on exit from the loop. While I didn't find a way to make the construction fail, a safer method (when you get a choice) is to use 'set': set -- a b c \ 1 2 3 while [ $# != 0 ] do echo $1 $2 $3 shift 3 done -Paul "too much shell programming" Bame From bame@riverrock.org Sun, 12 Nov 2000 17:25:45 -0700 Date: Sun, 12 Nov 2000 17:25:45 -0700 From: bame@riverrock.org bame@riverrock.org Subject: [parisc-linux] kernel merge Helge noticed SCSI fails (B160L, 712, I think it's ok on c3k) after the -test10 merge. We have MANY differences from Linus in the SCSI area. Anybody want to take a look at this? FYI to get the pre-merge kernel you can use LINUS_240_TEST10_PREMERGE. Beware that tags are sticky in CVS (use cvs update -A to fix that). -P From catfish@alltel.net Sun, 12 Nov 2000 19:05:21 -0600 Date: Sun, 12 Nov 2000 19:05:21 -0600 From: catfish@alltel.net catfish@alltel.net Subject: [parisc-linux] Project Dead???? Hello, Its been so long since I've had an email I was curious if this has become a Dead project? Just curious. Terry -- catfish: icq #20116127 From bame@riverrock.org Sun, 12 Nov 2000 18:15:07 -0700 Date: Sun, 12 Nov 2000 18:15:07 -0700 From: bame@riverrock.org bame@riverrock.org Subject: [parisc-linux] Project Dead???? = Hello, = Its been so long since I've had an email I was curious if this has = become a Dead project? You might want to check the e-mail archives to see what you've been missing. I don't know why you haven't been receiving anything. The project is quite alive. http://www.parisc-linux.org/lists.html -P From bame@riverrock.org Sun, 12 Nov 2000 19:20:50 -0700 Date: Sun, 12 Nov 2000 19:20:50 -0700 From: bame@riverrock.org bame@riverrock.org Subject: [parisc-linux] kernel merge = = Helge noticed SCSI fails (B160L, 712, I think it's ok on c3k) = after the -test10 merge. Fixed. From test6 to test10 the SCSI host registration method changed. Updated sim700.c, lasi7xx.h, zalon7xx.h -P From grundler@cup.hp.com Sun, 12 Nov 2000 21:34:08 -0800 Date: Sun, 12 Nov 2000 21:34:08 -0800 From: Grant Grundler grundler@cup.hp.com Subject: [parisc-linux] Problems booting new beta CD Brian Poole wrote: > Quoting Grant Grundler (grundler@cup.hp.com) from 11 November 2000: > > Is there a way via PALO to direct the console to FBCON or STICON or > > whatever it's called now? > > > > I had the impression *eventually* the boot console would be whatever PDC > > says it is - ie graphics console for the 712. > > Working on a 715 here.. notice you refer to 712s throughout, hopefully we are > on the same page. Maybe 712s are identical to 715s, I don't have any idea, > just noticed the irregularity. For the most part yes. I had just assumed you were using a 712. > I meant to say 'from serial console' or something of the sort.. Serial console should just work. Shouldn't need an HIL keyboard connected though. > > > > I've been fooling with it to no > > > success.. I have it automatically booting from the CD, but it doesn't > > > actually boot. I replug in the monitor & keyboard and find that it can't > > > boot without the keyboard ('Failed to initiliaze a keyboard\n SYSTEM > > > HALTED').. How am I supposed to boot to the console if I can't boot w/o a > > > keyboard? I imagine if it has a keyboard it will boot to the screen like > a > > > Sun. > > > > AFAIK, 712's are the only parisc workstations what won't boot w/o keyboard. > > All others will auto-switch to use serial console if the keyboard > > is not connected > > Hmmm.. so I have manually switch it to use serial console? No. Just disconnect the keyboard before powering on the machine. Should end up with console on the serial interface. You may want to set the keyboard/console path to the serial port. This can be done from "BOOT_ADMIN>" prompt. The default kernel has "CONFIG_HIL=y". But since I don't test on boxes with HIL interfaces, I have no idea if a keyboard is required since the driver is enabled. It sounds like a bug if the 715 can't boot from serial console w/o HIL keyboard. grant Grant Grundler Unix Systems Enablement Lab +1.408.447.7253 From dhazeghi@pacbell.net Sun, 12 Nov 2000 21:34:19 -0800 Date: Sun, 12 Nov 2000 21:34:19 -0800 From: dhazeghi@pacbell.net dhazeghi@pacbell.net Subject: [parisc-linux] [Semi OT] SOM Linker Hello, I have been watching this project for some time and wanted to thank you guys for all the great work so far. The recent announcement of a BETA CD is highly encouraging. However I would like to know what work if any has been done on the SOM linker which HP released to the public last November(?). It seems that as of right now, it has not been touched since February 14, and the FSF binutils snapshots still do not have any SOM support for ld. Has there been any movement in merging this in, or is anybody working on this? Thanks. Dara Hazeghi From deller@gmx.de Mon, 13 Nov 2000 08:32:54 +0100 Date: Mon, 13 Nov 2000 08:32:54 +0100 From: Helge Deller deller@gmx.de Subject: [parisc-linux] kernel merge On Monday 13 November 2000 03:20, bame@riverrock.org wrote: > = > = Helge noticed SCSI fails (B160L, 712, I think it's ok on c3k) > = after the -test10 merge. > > Fixed. > > >From test6 to test10 the SCSI host registration method changed. > Updated sim700.c, lasi7xx.h, zalon7xx.h > > -P Thanks Paul, sim700 (53c710) now works again, but the second built-in controller (ncr/sym 53c8xx) still doesn't. Greetings, Helge From rhirst@linuxcare.com Mon, 13 Nov 2000 10:24:03 +0000 Date: Mon, 13 Nov 2000 10:24:03 +0000 From: Richard Hirst rhirst@linuxcare.com Subject: [parisc-linux] BEWARE: Makefile changed from parisc to parisc64 Confused me for a while, anyway. If you cvs update your kernel source and expect to build a 32 bit kernel, you need to edit the top level Makefile to change the arch := line. Richard From rhirst@linuxcare.com Mon, 13 Nov 2000 12:13:49 +0000 Date: Mon, 13 Nov 2000 12:13:49 +0000 From: Richard Hirst rhirst@linuxcare.com Subject: [parisc-linux] kernel merge On Fri, Nov 10, 2000 at 02:28:33PM -0700, bame@riverrock.org wrote: > drivers/scsi sym53c8xx_comm.h #ifdef doesn't work on parisc -- eliminates > unmap_pci_mem() causing link error (TODO - rhirst) Fixed. This relates to NVRAM that some PCI scsi cards have to hold config settings over reboot. CONFIG_SCSI_NCR53C8XX_NVRAM_DETECT is normally defined in sym53c8xx_defs.h to turn that code on. When I implemented Zalon (FWD) support I guessed that the 53c720 h/w wouldn't have NVRAM implemented the same way, and turned off NVRAM detect. I've also replaced a chunk of Zalon specific code that got lost in the merge, so Zalon/FWD/53c720 support works again. There is a problem remaining when using the driver as a module; it looks like something is trying to printk() from a string in the module after the module has been removed. Havn't tracked that down yet. Richard From adevries@linuxcare.com Mon, 13 Nov 2000 13:50:24 -0500 Date: Mon, 13 Nov 2000 13:50:24 -0500 From: Alex deVries adevries@linuxcare.com Subject: [parisc-linux] [Semi OT] SOM Linker dhazeghi@pacbell.net wrote: > However I would like to know what work if any has been done on the SOM > linker which HP released to the public last November(?). It seems that > as of right now, it has not been touched since February 14, and the FSF > binutils snapshots still do not have any SOM support for ld. Has there > been any movement in merging this in, or is anybody working on this? The initial plan was to do our 32-bit userspace with SOM, worrying about ELF32 much later in the game. But ELF32 development happened a lot quicker than expected, and so nobody's really done much on the SOM linker. I suspect it'd be very hard to use the SOM linker code to incorporate it into binutils, but I could be wrong. What are you actually trying to do? - Alex -- Alex deVries, Principal Solutions Architect, The Puffins at Linuxcare 613.562.2759 tel alex@linuxcare.com, http://www.linuxcare.com/ Linuxcare, Support for the revolution. From deller@gmx.de Mon, 13 Nov 2000 23:54:29 +0100 Date: Mon, 13 Nov 2000 23:54:29 +0100 From: Helge Deller deller@gmx.de Subject: sym53c8xx-driver (was: Re: [parisc-linux] kernel merge) On Monday 13 November 2000 13:13, Richard Hirst wrote: > On Fri, Nov 10, 2000 at 02:28:33PM -0700, bame@riverrock.org wrote: > > drivers/scsi sym53c8xx_comm.h #ifdef doesn't work on parisc -- eliminates > > unmap_pci_mem() causing link error (TODO - rhirst) > > Fixed. This relates to NVRAM that some PCI scsi cards have to hold > config settings over reboot. CONFIG_SCSI_NCR53C8XX_NVRAM_DETECT > is normally defined in sym53c8xx_defs.h to turn that code on. When > I implemented Zalon (FWD) support I guessed that the 53c720 h/w > wouldn't have NVRAM implemented the same way, and turned off > NVRAM detect. > > I've also replaced a chunk of Zalon specific code that got lost in > the merge, so Zalon/FWD/53c720 support works again. > > There is a problem remaining when using the driver as a module; > it looks like something is trying to printk() from a string in > the module after the module has been removed. Havn't tracked > that down yet. > > Richard Hi Richard, I'm sorry to say that the sym53c8xx still doesn't work on my B160L (32 bit-Kernel). It looks like the controller isn't detected at all, while it worked perfectly with 2.4.0-test6. Would you mind to take a look at the code again ? Thanks, Helge. From rhirst@linuxcare.com Mon, 13 Nov 2000 23:27:52 +0000 Date: Mon, 13 Nov 2000 23:27:52 +0000 From: Richard Hirst rhirst@linuxcare.com Subject: sym53c8xx-driver (was: Re: [parisc-linux] kernel merge) Hi Helge, The problem I fixed related to the ncr53c8xx driver (which shares code with sym53c8xx), and was to make 53c720 support work again. sym53c8xx worked for me on my A180. Please can you try booting with sym53c8xx=verb:7,debug:0xffff and send me the output? Thanks, Richard On Mon, Nov 13, 2000 at 11:54:29PM +0100, Helge Deller wrote: > On Monday 13 November 2000 13:13, Richard Hirst wrote: > > On Fri, Nov 10, 2000 at 02:28:33PM -0700, bame@riverrock.org wrote: > > > drivers/scsi sym53c8xx_comm.h #ifdef doesn't work on parisc -- eliminates > > > unmap_pci_mem() causing link error (TODO - rhirst) > > > > Fixed. This relates to NVRAM that some PCI scsi cards have to hold > > config settings over reboot. CONFIG_SCSI_NCR53C8XX_NVRAM_DETECT > > is normally defined in sym53c8xx_defs.h to turn that code on. When > > I implemented Zalon (FWD) support I guessed that the 53c720 h/w > > wouldn't have NVRAM implemented the same way, and turned off > > NVRAM detect. > > > > I've also replaced a chunk of Zalon specific code that got lost in > > the merge, so Zalon/FWD/53c720 support works again. > > > > There is a problem remaining when using the driver as a module; > > it looks like something is trying to printk() from a string in > > the module after the module has been removed. Havn't tracked > > that down yet. > > > > Richard > > > Hi Richard, > > I'm sorry to say that the sym53c8xx still doesn't work on my B160L (32 > bit-Kernel). It looks like the controller isn't detected at all, while it > worked perfectly with 2.4.0-test6. > Would you mind to take a look at the code again ? > > Thanks, > Helge. > From deller@gmx.de Tue, 14 Nov 2000 01:13:58 +0100 Date: Tue, 14 Nov 2000 01:13:58 +0100 From: Helge Deller deller@gmx.de Subject: sym53c8xx-driver (was: Re: [parisc-linux] kernel merge) --------------Boundary-00=_ABNZX5KGKOOFAA0B1BIM Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 8bit Subject: On Tuesday 14 November 2000 00:27, Richard Hirst wrote: > Hi Helge, > The problem I fixed related to the ncr53c8xx driver (which shares > code with sym53c8xx), and was to make 53c720 support work again. > sym53c8xx worked for me on my A180. Please can you try booting > with > > sym53c8xx=verb:7,debug:0xffff > > and send me the output? > > Thanks, > Richard Hi Richard, the output and the relevant part of .config is attached. Greetings, Helge --------------Boundary-00=_ABNZX5KGKOOFAA0B1BIM Content-Type: text/plain; name="log1" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="log1" Ci5jb25maWc6IAotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tCiMKIyBT Q1NJIHN1cHBvcnQKIwpDT05GSUdfU0NTST15CkNPTkZJR19CTEtfREVWX1NEPXkKQ09ORklHX1NE X0VYVFJBX0RFVlM9NDAKIyBDT05GSUdfQ0hSX0RFVl9TVCBpcyBub3Qgc2V0CkNPTkZJR19CTEtf REVWX1NSPXkKQ09ORklHX0JMS19ERVZfU1JfVkVORE9SPXkKQ09ORklHX1NSX0VYVFJBX0RFVlM9 MgpDT05GSUdfQ0hSX0RFVl9TRz15CkNPTkZJR19TQ1NJX01VTFRJX0xVTj15CkNPTkZJR19TQ1NJ X0NPTlNUQU5UUz15CgojCiMgU0NTSSBsb3ctbGV2ZWwgZHJpdmVycwojCkNPTkZJR19TQ1NJX0xB U0k9eQpDT05GSUdfU0NTSV9aQUxPTj15CkNPTkZJR19TQ1NJX1NZTTUzQzhYWD15CkNPTkZJR19T Q1NJX05DUjUzQzhYWF9ERUZBVUxUX1RBR1M9OApDT05GSUdfU0NTSV9OQ1I1M0M4WFhfTUFYX1RB R1M9MzIKQ09ORklHX1NDU0lfTkNSNTNDOFhYX1NZTkM9MjAKIyBDT05GSUdfU0NTSV9OQ1I1M0M4 WFhfUFJPRklMRSBpcyBub3Qgc2V0CiMgQ09ORklHX1NDU0lfTkNSNTNDOFhYX0lPTUFQUEVEIGlz IG5vdCBzZXQKCgotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0KCmJvb3QtbG9nOgotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tCgpGaXJtd2FyZSBWZXJzaW9uICA2LjEKCkR1cGxleCBDb25zb2xlIElPIERlcGVuZGVu dCBDb2RlIChJT0RDKSByZXZpc2lvbiAxCgpNZW1vcnkgVGVzdC9Jbml0aWFsaXphdGlvbiBDb21w bGV0ZWQgCgotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0KICAgKGMpIENvcHlyaWdodCAxOTk1LTE5OTgs IEhld2xldHQtUGFja2FyZCBDb21wYW55LCBBbGwgcmlnaHRzIHJlc2VydmVkCi0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLQoKICBQcm9jZXNzb3IgICBTcGVlZCAgICAgICAgICAgIFN0YXRlICAgICAgICAg ICBDb3Byb2Nlc3NvciBTdGF0ZSAgQ2FjaGUgU2l6ZQogIC0tLS0tLS0tLSAgLS0tLS0tLS0gICAt LS0tLS0tLS0tLS0tLS0tLS0tLS0gIC0tLS0tLS0tLS0tLS0tLS0tICAtLS0tLS0tLS0tCiAgICAg IDAgICAgICAxNjAgTUh6ICAgIEFjdGl2ZSAgICAgICAgICAgICAgICAgRnVuY3Rpb25hbCAgICAg ICAgICA2NCBLQgogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgIDEgTUIgZXh0CgoKICBBdmFpbGFibGUgbWVtb3J5IChieXRl cykgICAgOiAgNTM2ODcwOTEyIAogIEdvb2QgbWVtb3J5IHJlcXVpcmVkIChieXRlcyk6ICA1MzY4 NzA5MTIgCgogIFByaW1hcnkgYm9vdCBwYXRoOiAgICBGV1NDU0kuNi4wCiAgQWx0ZXJuYXRlIGJv b3QgcGF0aDogIExBTi4wLjAuMC4wLjAuMAogIENvbnNvbGUgcGF0aDogICAgICAgICBHUkFQSElD UygyKQogIEtleWJvYXJkIHBhdGg6ICAgICAgICBQUzIKCkNQVSAwCldBUk5JTkc6ICBTZWxmIHRl c3RzIGhhdmUgYmVlbiBkaXNhYmxlZCBhcyBhIHJlc3VsdCBvZiBGQVNUQk9PVAogICAgICAgICAg YmVpbmcgZW5hYmxlZC4gIFRvIGVuYWJsZSBzZWxmIHRlc3RzLCB1c2UgdGhlIEZBU1RCT09UCiAg ICAgICAgICBjb21tYW5kIGluIHRoZSBDT05GSUdVUkFUSU9OIG1lbnUgYW5kIHJlYm9vdCB0aGUg c3lzdGVtLgoKCi0tLS0tLS0gTWFpbiBNZW51IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0KCiAgICAgICAgQ29tbWFuZCAgICAgICAg ICAgICAgICAgICAgICAgICBEZXNjcmlwdGlvbgogICAgICAgIC0tLS0tLS0gICAgICAgICAgICAg ICAgICAgICAgICAgLS0tLS0tLS0tLS0KICAgICAgICBCT290IFtQUkl8QUxUfDxwYXRoPl0gICAg ICAgICAgIEJvb3QgZnJvbSBzcGVjaWZpZWQgcGF0aAogICAgICAgIFBBdGggW1BSSXxBTFR8Q09O fEtFWV0gWzxwYXRoPl0gRGlzcGxheSBvciBtb2RpZnkgYSBwYXRoCiAgICAgICAgU0VBcmNoIFtE SXNwbGF5fElQTF0gWzxwYXRoPl0gICBTZWFyY2ggZm9yIGJvb3QgZGV2aWNlcwoKICAgICAgICBD T25maWd1cmF0aW9uIFs8Y29tbWFuZD5dICAgICAgIEFjY2VzcyBDb25maWd1cmF0aW9uIG1lbnUv Y29tbWFuZHMKICAgICAgICBJTmZvcm1hdGlvbiBbPGNvbW1hbmQ+XSAgICAgICAgIEFjY2VzcyBJ bmZvcm1hdGlvbiBtZW51L2NvbW1hbmRzCiAgICAgICAgU0VSdmljZSBbPGNvbW1hbmQ+XSAgICAg ICAgICAgICBBY2Nlc3MgU2VydmljZSBtZW51L2NvbW1hbmRzCgogICAgICAgIERJc3BsYXkgICAg ICAgICAgICAgICAgICAgICAgICAgUmVkaXNwbGF5IHRoZSBjdXJyZW50IG1lbnUKICAgICAgICBI RWxwIFs8bWVudT58PGNvbW1hbmQ+XSAgICAgICAgIERpc3BsYXkgaGVscCBmb3IgbWVudSBvciBj b21tYW5kCiAgICAgICAgUkVTRVQgICAgICAgICAgICAgICAgICAgICAgICAgICBSZXN0YXJ0IHRo ZSBzeXN0ZW0KLS0tLS0tLQpNYWluIE1lbnU6IEVudGVyIGNvbW1hbmQgPiBibyBsYW4KSW50ZXJh Y3Qgd2l0aCBJUEwgKFksIE4sIFEpPz4gbgoKQm9vdGluZy4uLiAKTmV0d29yayBTdGF0aW9uIEFk ZHJlc3MgMDgwMDA5LWVmMzRmNQpTeXN0ZW0gSVAgQWRkcmVzcyAxOTIuMTY4LjEwMC4xNjAKU2Vy dmVyIElQIEFkZHJlc3MgMTkyLjE2OC4xMDAuMTAwCgpCb290IElPIERlcGVuZGVudCBDb2RlIChJ T0RDKSByZXZpc2lvbiAyCgoKSEFSRCBCb290ZWQuCnBhbG8gaXBsIHJvb3RAUDEwMCBUaHUgTm92 ICAyIDIwOjE0OjA4IE1FVCAyMDAwCjAvdm1saW51eCAyMjc0NzcxIGJ5dGVzIEAgMHg2ODAwCjAv cGFsby1jbWRsaW5lICcwL3ZtbGludXggSE9NRT0vIFRFUk09TElOVVggcm9vdD0vZGV2L25mcyBu ZnNyb290PTE5Mi4xNjguMTAwLjEwMDovdGZ0cGJvb3QvbmZzcm9vdCBjb25zb2xlPXR0eSBzeW01 M2M4eHg9dmVyYjo3LGRlYnVnOjB4ZmZmZicKS2VybmVsOiBwYXJ0aXRpb24gMCBmaWxlIC92bWxp bnV4CkVMRjMyIGV4ZWN1dGFibGUKCkVudHJ5IDAwMTAwMTkwIGZpcnN0IDAwMTAwMDAwIG4gNApT ZWdtZW50IDAgbG9hZCAwMDEwMDAwMCBzaXplIDE1MzQ2NjggbWVkaWFwdHIgMHgxMDAwClNlZ21l bnQgMSBsb2FkIDAwMjc4MDAwIHNpemUgMTgyMzQ0IG1lZGlhcHRyIDB4MTc4MDAwClNlZ21lbnQg MiBsb2FkIDAwMmE4MDAwIHNpemUgMTM5MTMyIG1lZGlhcHRyIDB4MWE1MDAwClNlZ21lbnQgMyBs b2FkIDAwMmNjMDAwIHNpemUgODE5MiBtZWRpYXB0ciAweDFjNzAwMApicmFuY2hpbmcgdG8ga2Vy bmVsIGVudHJ5IHBvaW50IDB4MDAxMDAxOTAKU2V0IGRlZmF1bHQgUFNXIFcgYml0IHRvIDAKUERD IENvbnNvbGUgSW5pdGlhbGl6ZWQKVGhlIDMyLWJpdCBLZXJuZWwgaGFzIHN0YXJ0ZWQuLi4KRW5h YmxlZCBGUCBjb3Byb2Nlc3NvcgpGcmVlIG1lbW9yeSBzdGFydHMgYXQ6IDB4YzAyZmQwMDAKc3Rh cnRfcGFyaXNjKDB4NTA0ZDZjLDB4NTA0ZDZjLDB4MCwweDApClBBTE8gY29tbWFuZCBsaW5lOiAn SE9NRT0vIFRFUk09TElOVVggcm9vdD0vZGV2L25mcyBuZnNyb290PTE5Mi4xNjguMTAwLjEwMDov dGZ0cGJvb3QvbmZzcm9vdCBjb25zb2xlPXR0eSBzeW01M2M4eHg9dmVyYjo3LGRlYnVnOjB4ZmZm ZicKUEFMTyBpbml0cmQgMC0wCm1vZGVsICAgMDAwMDUwMjAgMDAwMDA0ODEgMDAwMDAwMDAgMDIw MjAyMDIgNzc5NGQ3ZmUgMTAwMDAwZjAgMDAwMDAwMDQgMDAwMDAwYmEgMDAwMDAwYmEKdmVycyAg ICAwMDAwMDAwOApjcHVpZCAgIDAwMDAwMWU4CkNQVUlEIHZlcnMgMTUgcmV2IDgKU2VhcmNoaW5n IGZvciBkZXZpY2VzIGluIFBEQyBmaXJtd2FyZS4uLiBwcm9jZXNzb3IgaHBhIDB4ZmZmYmUwMDAK YSBuZXdlciBib3guLi4KRm91bmQgZGV2aWNlczoKMS4gUGhhbnRvbSBQc2V1ZG9CQyBHU0MrIFBv cnQgKDcpIGF0IDB4ZmZjMDAwMDAsIHZlcnNpb25zIDB4NTA0LCAweDAsIDB4MCwgMHgwLCAweDAK Mi4gTWVybGluIDE2MCBDb3JlIEZXLVNDU0kgKDQpIGF0IDB4ZmZmOGMwMDAsIHZlcnNpb25zIDB4 M2QsIDB4MCwgMHg4OSwgMHgwLCAweDgwCjMuIE1lcmxpbiBMMiAxNjAgKDkwMDAvNzc4L0IxNjBM KSAoMCkgYXQgMHhmZmZiZTAwMCwgdmVyc2lvbnMgMHg1MDIsIDB4MCwgMHg0LCAweDAsIDB4ODEK NC4gTWVybGluIDE2MC9UaHVuZGVySGF3ayBNZW1vcnkgKDEpIGF0IDB4ZmZmYmYwMDAsIHZlcnNp b25zIDB4NjcsIDB4MCwgMHg5LCAweDAsIDB4MAo1LiBNZXJsaW4gMTYwIENvcmUgQkEgKDExKSBh dCAweGZmZDAwMDAwLCB2ZXJzaW9ucyAweDNkLCAweDAsIDB4ODEsIDB4MCwgMHgwCjYuIE1lcmxp biAxNjAgQ29yZSBSUy0yMzIgKDEwKSBhdCAweGZmZDA1MDAwLCB2ZXJzaW9ucyAweDNkLCAweDAs IDB4OGMsIDB4MCwgMHgwCjcuIE1lcmxpbiAxNjAgQ29yZSBTQ1NJICgxMCkgYXQgMHhmZmQwNjAw MCwgdmVyc2lvbnMgMHgzZCwgMHgwLCAweDgyLCAweDAsIDB4MAo4LiBNZXJsaW4gMTYwIENvcmUg TGFuICg4MDIuMykgKDEwKSBhdCAweGZmZDA3MDAwLCB2ZXJzaW9ucyAweDNkLCAweDAsIDB4OGEs IDB4MCwgMHgwCjkuIE1lcmxpbiAxNjAgQ29yZSBDZW50cm9uaWNzICgxMCkgYXQgMHhmZmQwMjAw MCwgdmVyc2lvbnMgMHgzZCwgMHgwLCAweDc0LCAweDAsIDB4MAoxMC4gTWVybGluIDE2MCBDb3Jl IEF1ZGlvICgxMCkgYXQgMHhmZmQwNDAwMCwgdmVyc2lvbnMgMHgzZCwgMHg0LCAweDdiLCAweDAs IDB4MAoxMS4gTWVybGluIDE2MCBDb3JlIFBDIEtleWJvYXJkICgxMCkgYXQgMHhmZmQwODAwMCwg dmVyc2lvbnMgMHgzZCwgMHgwLCAweDg0LCAweDAsIDB4MAoxMi4gTWVybGluIDE2MCBDb3JlIFBD IEtleWJvYXJkICgxMCkgYXQgMHhmZmQwODEwMCwgdmVyc2lvbnMgMHgzZCwgMHgwLCAweDg0LCAw eDAsIDB4MAoxMy4gTWVybGluIDE2MCBXYXggQkEgKDExKSBhdCAweGZmZTAwMDAwLCB2ZXJzaW9u cyAweDQxLCAweDAsIDB4OGUsIDB4MCwgMHgwCjE0LiBNZXJsaW4gMTYwIFdheCBFSVNBIEJBICgx MSkgYXQgMHhmYzAwMDAwMCwgdmVyc2lvbnMgMHg0MSwgMHgwLCAweDkwLCAweDAsIDB4MAoxNS4g TWVybGluIDE2MCBXYXggSElMICgxMCkgYXQgMHhmZmUwMTAwMCwgdmVyc2lvbnMgMHg0MSwgMHgw LCAweDczLCAweDAsIDB4MAoxNi4gTWVybGluIDE2MCBXYXggUlMtMjMyICgxMCkgYXQgMHhmZmUw MjAwMCwgdmVyc2lvbnMgMHg0MSwgMHgwLCAweDhjLCAweDAsIDB4MAoxNy4gQ29yYWwgU0dDIEdy YXBoaWNzICgxMCkgYXQgMHhmNDAwMDAwMCwgdmVyc2lvbnMgMHg0LCAweDAsIDB4NzcsIDB4MCwg MHgwCjE4LiBHZWNrbyBHU0MgQ29yZSBHcmFwaGljcyAoMTApIGF0IDB4ZjgwMDAwMDAsIHZlcnNp b25zIDB4MTYsIDB4MCwgMHg4NSwgMHgwLCAweDAKMTkuIERpbm8gUENJIEJyaWRnZSAoMTMpIGF0 IDB4ZmZmODAwMDAsIHZlcnNpb25zIDB4NjgwLCAweDAsIDB4YSwgMHgwLCAweDAKVGhhdCdzIGEg dG90YWwgb2YgMTkgZGV2aWNlcy4KQ1BVKHMpOiAxIHggUEE3MzAwTEMgKFBDWC1MMikgYXQgMTYw LjAwMDAwMCBNSHoKTGludXggdmVyc2lvbiAyLjQuMC10ZXN0MTAgKHJvb3RAUDEwMCkgKGdjYyB2 ZXJzaW9uIDIuOTYgMjAwMDA5MjUgKGV4cGVyaW1lbnRhbCkpICMxNSBUdWUgTm92IDE0IDAxOjAx OjMzIE1FVCAyMDAwCmZyZWVfYm9vdG1lbSgweDMwMTAwMCwgMHgxZmNmZjAwMCkKaW5pdHJkOiAw MDAwMDAwMC0wMDAwMDAwMApwYWdldGFibGVfaW5pdApPbiBub2RlIDAgdG90YWxwYWdlczogMTMx MDcyCnpvbmUoMCk6IDY1NTM2IHBhZ2VzLgp6b25lKDEpOiA2NTUzNiBwYWdlcy4Kem9uZSgyKTog MCBwYWdlcy4KS2VybmVsIGNvbW1hbmQgbGluZTogSE9NRT0vIFRFUk09TElOVVggcm9vdD0vZGV2 L25mcyBuZnNyb290PTE5Mi4xNjguMTAwLjEwMDovdGZ0cGJvb3QvbmZzcm9vdCBjb25zb2xlPXR0 eSBzeW01M2M4eHg9dmVyYjo3LGRlYnVnOjB4ZmZmZgp0cmFwX2luaXQKQ29uc29sZTogY29sb3Vy IGR1bW15IGRldmljZSA4MHgyNQpyZWdpc3Rlcl9jb25zb2xlCkNhbGlicmF0aW5nIGRlbGF5IGxv b3AuLi4gMTA2LjUwIEJvZ29NSVBTCk1lbW9yeTogNTEwOTQ0ayBhdmFpbGFibGUKRGVudHJ5LWNh Y2hlIGhhc2ggdGFibGUgZW50cmllczogNjU1MzYgKG9yZGVyOiA3LCA1MjQyODggYnl0ZXMpCkJ1 ZmZlci1jYWNoZSBoYXNoIHRhYmxlIGVudHJpZXM6IDMyNzY4IChvcmRlcjogNSwgMTMxMDcyIGJ5 dGVzKQpQYWdlLWNhY2hlIGhhc2ggdGFibGUgZW50cmllczogMTMxMDcyIChvcmRlcjogNywgNTI0 Mjg4IGJ5dGVzKQpJbm9kZS1jYWNoZSBoYXNoIHRhYmxlIGVudHJpZXM6IDMyNzY4IChvcmRlcjog NiwgMjYyMTQ0IGJ5dGVzKQpQT1NJWCBjb25mb3JtYW5jZSB0ZXN0aW5nIGJ5IFVOSUZJWApMYXNp IHZlcnNpb24gMCBhdCAweGZmZDAwMDAwIGZvdW5kLgpXYXggYXQgMHhmZmUwMDAwMCBmb3VuZC4K V2F4OiBISUwgS2V5Ym9hcmQtTk1JIHJlZ2lzdGVyZWQuCnBhcnBvcnQwOiBQQy1zdHlsZSBhdCAw eGZmZDAyODAwLCBpcnEgODggW1BDU1BQLFRSSVNUQVRFXQpGb3VuZCBpODI1OTYgYXQgMHhmZmQw NzAwMCwgSVJRIDg3CmVhcmx5IGluaXRpYWxpemF0aW9uIG9mIGRldmljZSBldGgwIGlzIGRlZmVy cmVkCkluaXRpYWxpemluZyBMYXNpIFBTLzIta2V5Ym9hcmQgcG9ydCBhdCAweGZmZDA4MDAwLi4u ClN1cHBvcnQgZm9yIExhc2kgUFMvMi1wc2F1eCBub3QgeWV0IGF2YWlsYWJsZSAhCkZvdW5kIEhJ TCBhdCAweGZmZTAxMDAwLCBJUlEgMTI2Ck5vIGhhbmRsZXIgZm9yIGludGVycnVwdCAzNSAhCkhJ TDogdGltZWQgb3V0LCBhc3N1bWluZyBubyBrZXlib2FyZCBwcmVzZW50LgpXYXJuaW5nIDogZGV2 aWNlICgxMCwgMHg0MSwgMHgwLCAweDczLCAweDApIE5PVCBjbGFpbWVkIGJ5IEhJTCA3MTIsIDcx NSBvciBzaW1pbGlhcgpEaW5vIHZlcnNpb24gMi4wIChicmlkZ2UgbW9kZSkgZm91bmQgYXQgMHhm ZmY4MDAwMAoKClRoZSBHU0N0b1BDSSAoRGlubyBocmV2IDApIGJ1cyBjb252ZXJ0ZXIgZm91bmQg bWF5IGV4aGliaXQKZGF0YSBjb3JydXB0aW9uLiAgU2VlIFNlcnZpY2UgTm90ZSBOdW1iZXJzOiBB NDE5MEEtMDEsIEE0MTkxQS0wMS4KU3lzdGVtcyBzaGlwcGVkIGFmdGVyIEF1ZyAyMCwgMTk5NyB3 aWxsIG5vdCBleGhpYml0IHRoaXMgcHJvYmxlbS4KTW9kZWxzIGFmZmVjdGVkOiBDMTgwLCBDMTYw LCBDMTYwTCwgQjE2MEwsIGFuZCBCMTMyTCB3b3Jrc3RhdGlvbnMuCgpkaW5vX2JyaWRnZV9pbml0 OiBJT19BRERSX0VOIGhhc24ndCBiZWVuIGNvbmZpZ3VyZWQuCmtlcm5lbCBCVUcgYXQgZGluby5j OjY0NiEKTGludXggTkVUNC4wIGZvciBMaW51eCAyLjQKQmFzZWQgdXBvbiBTd2Fuc2VhIFVuaXZl cnNpdHkgQ29tcHV0ZXIgU29jaWV0eSBORVQzLjAzOQpTdGFydGluZyBrc3dhcGQgdjEuOApzdGlm Yi5jOiBzZWFyY2hpbmcgZm9yIHdvcmQgbW9kZSBTVEkgUk9Ncwpmb3VuZCBwb3RlbnRpYWwgU1RJ IFJPTSBhdCBmNDAwMDAwMApTVEkgYnl0ZSBtb2RlIFJPTSBhdCBmNDAwMDAwMCwgaWdub3JlZApm b3VuZCBwb3RlbnRpYWwgU1RJIFJPTSBhdCBmODAwMDAwMApwdHk6IDI1NiBVbml4OTggcHR5cyBj b25maWd1cmVkCmxwMDogdXNpbmcgcGFycG9ydDAgKGludGVycnVwdC1kcml2ZW4pLgpSQU1ESVNL IGRyaXZlciBpbml0aWFsaXplZDogMTYgUkFNIGRpc2tzIG9mIDQwOTZLIHNpemUgMTAyNCBibG9j a3NpemUKZXRoMDogODI1OTYgYXQgMHhmZmQwNzAwMCwgMDggMDAgMDkgRUYgMzQgRjUgSVJRIDg3 Lgo4MjU5Ni5jICRSZXZpc2lvbjogMS4xNCAkClNlcmlhbCBkcml2ZXIgdmVyc2lvbiA1LjAyICgy MDAwLTA4LTA5KSB3aXRoIE1BTllfUE9SVFMgU0hBUkVfSVJRIFNFUklBTF9QQ0kgZW5hYmxlZAp0 dHlTMDAgYXQgaW9tZW0gMHhmZmQwNTgwMCAoaXJxID0gOTApIGlzIGEgMTY1NTBBCnR0eVMwMSBh dCBpb21lbSAweGZmZTAyODAwIChpcnEgPSAxMjEpIGlzIGEgMTY1NTBBCkdlbmVyaWMgUlRDIERy aXZlciB2MS4wMiAwNS8yNy8xOTk5IFNhbSBDcmVhc2V5IChzYW1teUBvaC52ZXJpby5jb20pClND U0kgc3Vic3lzdGVtIGRyaXZlciBSZXZpc2lvbjogMS4wMApzaW03MDA6IENvbmZpZ3VyaW5nIDUz YzcxMCAoU0NTSS1JRCA3KSBhdCBmZmQwNjEwMCwgSVJRIDg2CnNjc2kwOiBSZXZpc2lvbiAweDIK UG9zdCB0ZXN0MSwgaXN0YXQgMDEsIHNzdGF0MCAwMCwgZHN0YXQgODQKc2ltNzAwOiBXQVJOSU5H IElSUSBwcm9iZSBmYWlsZWQsIChyZXR1cm5lZCAwKQpzY3NpMDogR29vZCwgdGFyZ2V0IGRhdGEg YXJlYXMgYXJlIGRtYSBjb2hlcmVudApzY3NpMDogdGVzdCAxIGNvbXBsZXRlZCBvay4Kc2NzaTA6 IHNpbTcwMF9pbnRyX2hhbmRsZSgpIGNhbGxlZCB3aXRoIG5vIGludGVycnVwdApzY3NpMCA6IExB U0kvU2ltcGxlIDUzYzd4eAogIFZlbmRvcjogUElPTkVFUiAgIE1vZGVsOiBDRC1ST00gRFItVTEy WCAgICBSZXY6IDEuMDYKICBUeXBlOiAgIENELVJPTSAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgQU5TSSBTQ1NJIHJldmlzaW9uOiAwMgpEZXRlY3RlZCBzY3NpIENELVJPTSBzcjAgYXQgc2Nz aTAsIGNoYW5uZWwgMCwgaWQgMCwgbHVuIDAKc3IwOiBzY3NpMy1tbWMgZHJpdmU6IDEyeC8xMngg eGEvZm9ybTIgY2RkYSB0cmF5ClVuaWZvcm0gQ0QtUk9NIGRyaXZlciBSZXZpc2lvbjogMy4xMQpz ZWFyY2hpbmcgZm9yIHdvcmQgbW9kZSBTVEkgUk9Ncwpmb3VuZCBwb3RlbnRpYWwgU1RJIFJPTSBh dCBmNDAwMDAwMApTVEkgYnl0ZSBtb2RlIFJPTSBhdCBmNDAwMDAwMCwgaWdub3JlZApmb3VuZCBw b3RlbnRpYWwgU1RJIFJPTSBhdCBmODAwMDAwMApzZWFyY2hpbmcgZm9yIGJ5dGUgbW9kZSBTVEkg Uk9Ncwpmb3VuZCBwb3RlbnRpYWwgU1RJIFJPTSBhdCBmNDAwMDAwMApTVEkgYnl0ZSBtb2RlIFJP TSB0eXBlIDEKIHN1cHBvcnRzIDE1IG1vbml0b3JzCiBjb25mb3JtcyB0byBTVEkgUk9NIHNwZWMg cmV2aXNpb24gOC4wNwpkdW1wX3N0aV9yb206IDUwMAogZ3JhcGhpY3MgaWQgMmQwOGMwYTcwOWEw MjU4NwpkdW1wX3N0aV9yb206IDUxMAogZm9udCBzdGFydCAwMDAxODNjMwpkdW1wX3N0aV9yb206 IDUxMgogcmVnaW9uIGxpc3QgMDAwMTgzNjMKZHVtcF9zdGlfcm9tOiA1MTQKIGluaXRfZ3JhcGgg MDAwMDFhNjMKZHVtcF9zdGlfcm9tOiA1MTYKIGFsdGVybmF0ZSBjb2RlIHR5cGUgMApkdW1wX3N0 aV9yb206IDUxOApuZXh0IGZvbnQgMDAwMDQwNDAKZjQwMDAwMDAgYgpmODAwMDAwMCBiClN3aXRj aGluZyBmcm9tIFBEQyBjb25zb2xlCg== --------------Boundary-00=_ABNZX5KGKOOFAA0B1BIM-- From rhirst@linuxcare.com Tue, 14 Nov 2000 10:17:04 +0000 Date: Tue, 14 Nov 2000 10:17:04 +0000 From: Richard Hirst rhirst@linuxcare.com Subject: sym53c8xx-driver (was: Re: [parisc-linux] kernel merge) Hi Helge, On Tue, Nov 14, 2000 at 01:13:58AM +0100, Helge Deller wrote: > On Tuesday 14 November 2000 00:27, Richard Hirst wrote: > > Hi Helge, > > The problem I fixed related to the ncr53c8xx driver (which shares > > code with sym53c8xx), and was to make 53c720 support work again. > > sym53c8xx worked for me on my A180. Please can you try booting > > with > > > > sym53c8xx=verb:7,debug:0xffff > > > > and send me the output? > > > > Thanks, > > Richard > > > Hi Richard, > > the output and the relevant part of .config is attached. > > Greetings, > > Helge Thanks. I agree it doesn't look like the driver is even seeing the chip; I wonder if PCI support is broken... > dino_bridge_init: IO_ADDR_EN hasn't been configured. > kernel BUG at dino.c:646! Does it usually say that on bootup? Richard From matthew@wil.cx Tue, 14 Nov 2000 10:29:36 +0000 Date: Tue, 14 Nov 2000 10:29:36 +0000 From: Matthew Wilcox matthew@wil.cx Subject: [parisc-linux] kernel merge On Fri, Nov 10, 2000 at 02:28:33PM -0700, bame@riverrock.org wrote: > fcntl.h acquired a 'struct fcntl64' used with 64-bit offsets, implementing > fcntl(fd, F_S/GETLK[W]64, ...). Several other locking-related #defines added. > > We'll need to add the getdents64() and fcntl64() syscall glue. (TODO!!!) actually, we don't. Linux/PA-RISC has sufficiently wide data types already so we don't have the grot required in other ports to support the appropriate wide data types. > looks like maybe the get/put_user_ret() functions in asm/uaccess.h are > obsolete? (TODO) yes, they are. exterminate! exterminate! -- Revolutions do not require corporate support. From deller@gmx.de Tue, 14 Nov 2000 14:11:42 +0100 (MET) Date: Tue, 14 Nov 2000 14:11:42 +0100 (MET) From: Helge Deller deller@gmx.de Subject: sym53c8xx-driver (was: Re: [parisc-linux] kernel merge) > Hi Helge, > > On Tue, Nov 14, 2000 at 01:13:58AM +0100, Helge Deller wrote: > > On Tuesday 14 November 2000 00:27, Richard Hirst wrote: > > > Hi Helge, > > > The problem I fixed related to the ncr53c8xx driver (which shares > > > code with sym53c8xx), and was to make 53c720 support work again. > > > sym53c8xx worked for me on my A180. Please can you try booting > > > with > > > > > > sym53c8xx=verb:7,debug:0xffff > > > > > > and send me the output? > > > > > > Thanks, > > > Richard > > > > > > Hi Richard, > > > > the output and the relevant part of .config is attached. > > > > Greetings, > > > > Helge > > Thanks. I agree it doesn't look like the driver is even seeing the > chip; I wonder if PCI support is broken... > > > dino_bridge_init: IO_ADDR_EN hasn't been configured. > > kernel BUG at dino.c:646! > > Does it usually say that on bootup? Yep. Has always been there, but nevertheless the scsi-driver worked before. FYI: The non-pci sim700-driver also didn't showed up before pb fixed it in CVS with a few one-line-patches. NB: Could maybe someone (ggg?) explain me the kernel-bug mentioned above ? > > Richard > Greetings, Helge -- Sent through GMX FreeMail - http://www.gmx.net From grundler@cup.hp.com Tue, 14 Nov 2000 08:10:42 -0800 Date: Tue, 14 Nov 2000 08:10:42 -0800 From: Grant Grundler grundler@cup.hp.com Subject: [parisc-linux] dino maintainer? Anyone interested in maintaining Dino? I don't have time for it and all the docs are on the web. One of the "TODO" things is to convert dino.c to use struct pci_hba the same way lba_pci.c does.... Richard Hirst wrote: ... > Thanks. I agree it doesn't look like the driver is even seeing the > chip; I wonder if PCI support is broken... > > > dino_bridge_init: IO_ADDR_EN hasn't been configured. > > kernel BUG at dino.c:646! > > Does it usually say that on bootup? per Helge's request: The bug is normal for card-mode Dino - not for Built-in Dino. I think Helge has the GSC 100BT card which is a card-mode Dino on-board with one (or two) Tulip(s) behind it. The warning is a reminder one can NOT use MMIO accesses to those PCI devices and *only* I/O Port space (eg inb/outb). If someone wants to fix the warning so it's quiet for card-mode devices...see is_card_dino(d) in dino_driver_callback() for an example. FYI - card-mode dino was used for several different networking interfaces but not SCSI interfaces. hope this helps, grant Grant Grundler Unix Systems Enablement Lab +1.408.447.7253 From bame@noam.fc.hp.com Tue, 14 Nov 2000 09:35:01 -0700 Date: Tue, 14 Nov 2000 09:35:01 -0700 From: Paul Bame bame@noam.fc.hp.com Subject: [parisc-linux] CVS linux Vs. -test10 I've attached an overview of differences between our CVS linux sources following the -test10 merge and the upstream -test10 sources. This document is also at http://puffin.external.hp.com/~bame/diff.html The raw 'diff' output (now a bit out of date) is at http://puffin.external.hp.com/~bame/diff.out If anyone gets bored, this list is full of small (and not so small) tasks which range from very simple (drivers/block/rd.c) to fairly complex (scripts/*). -P palinux Vs. linux 2.4.0-test10 Here's a brief summary of the differences in common code between palinux (tag: LINUS_240_TEST10_MERGED) and the upstream -test10 sources. The full diff output is in diff.out. NOTE this does not include machine-depend differences * Minor changes in several locations to support GSC * Minor top-level Makefile hacks, though the CFLAGS one is quite important. * Lots of RCS $Revision$ differences in ACPI (a different 'cvs import' would've eliminated these differences). * drivers/block/rd.c: obsolete debug code for parisc64. Changed a constant from 0xffffffffL to 0xffffffffUL because of a parisc64 gcc bug initializing longs. The repaired code is probably "more correct" anyway. * drivers/char/Config.in: changes to support LASI, parisc real-time clock (CONFIG_GENRTC) * drivers/char/Makefile: Config-related changes to support HP keyboards and RTC * drivers/char/console.c: looks like dead or dying experimental parisc code -- probably should be removed. Also some parisc-specific comments and format changes which should disappear. * drivers/char/serial.c: support for GSC and A500 serial * drivers/net/Makefile,Space.c: mostly LASI LAN support * drivers/net/eepro100.c: no clue about this one * drivers/net/tulip/interrupt.c: workaround for a B180+busy-lan boot problem -- probably should be sent upstream. * drivers/net/tulip/tulip_core.c: required #ifdef for hppa, also printk() changes which appear valid * drivers/parport/Makefile: GSC * drivers/parport/parport_gsc.c: New file for palinux -- GSC parallel ports -- required * drivers/pci/pci.c: eh? Grant? * drivers/pci/setup-bus.c: function definition tweek -- Grant? * drivers/scsi: Lots of changes here -- rhirst? See for yourself. Basics: support LASI and Zalon scsi, changes to 53c8xx drivers, rename sim7x0 to sim710 * drivers/sound: support for HP "Harmony" sound * drivers/video: STI and HP FB video drivers (iodccon is probably worthless) * fs: add support for SOM executables * fs/binfmt_elf.c,exec.c: changes for stack-grows-up? * fs/nfs/read.c: probably unnecessary hack for broken parisc64 gcc * fs/proc/array.c: ?? something with signals ?? * fs/stat.c: added __hppa__ to several #ifdefs * include/linux/binfmts.h,fs.h,kernel.h,tty.h,udf_fs_sb.h: unnecessary differences? * include/linux/init.h: we use different section names -- why????, probably some unnecessary other differences too * include/linux/mm.h: VM_STACK_FLAGS difference -- jsm? * include/linux/wait.h: parisc debugging -- should be removed * init/main.c: KWDB and GSC support plus a bunch of stuff which should probably go away. * kernel/Makefile,dma.c,fork.c,printk.c: eh? * kernel/module.c: possible parisc-needed changes * kernel/signal.c: unknown signal-related differences * lib/inflate.c: changed some constants to work around parisc64 gcc bug * mm/mprotect.c: ? * scripts/*: MANY differences here. Looks like a combination of things we hacked to fix configuration problems plus MAYBE not updating these files from new Linux versions in the past. 'make menuconfig' is significantly different from upstream. Even the mkdep.c program is different. From bame@noam.fc.hp.com Tue, 14 Nov 2000 10:02:06 -0700 Date: Tue, 14 Nov 2000 10:02:06 -0700 From: Paul Bame bame@noam.fc.hp.com Subject: [parisc-linux] kernel merge = On Fri, Nov 10, 2000 at 02:28:33PM -0700, bame@riverrock.org wrote: = > fcntl.h acquired a 'struct fcntl64' used with 64-bit offsets, implementing = > fcntl(fd, F_S/GETLK[W]64, ...). Several other locking-related #defines add ed. = > = > We'll need to add the getdents64() and fcntl64() syscall glue. (TODO!!!) = = actually, we don't. Linux/PA-RISC has sufficiently wide data types = already so we don't have the grot required in other ports to support = the appropriate wide data types. Ok that sounds great but I need a clue how to see it. struct flock contains an off_t which is 32 bits on narrow (wide too at the moment, but that will probably change). Also, struct dirent contains a 32-bit inode and a __kernel_off_t offset (d_off), which is also 32 bits narrow. I did see the ... in our fcntl() syscall definition so I'll go check glibc to see what's happening there. I wouldn't be so picky except that I need to write the 32/64 syscall translators for these soon! Thanks! -P From bame@noam.fc.hp.com Tue, 14 Nov 2000 10:14:51 -0700 Date: Tue, 14 Nov 2000 10:14:51 -0700 From: Paul Bame bame@noam.fc.hp.com Subject: [parisc-linux] kernel merge = On Fri, Nov 10, 2000 at 02:28:33PM -0700, bame@riverrock.org wrote: = > fcntl.h acquired a 'struct fcntl64' used with 64-bit offsets, implementing = > fcntl(fd, F_S/GETLK[W]64, ...). Several other locking-related #defines add ed. = > = > We'll need to add the getdents64() and fcntl64() syscall glue. (TODO!!!) = = actually, we don't. Linux/PA-RISC has sufficiently wide data types = already so we don't have the grot required in other ports to support = the appropriate wide data types. Oh, and won't we have to support these syscalls anyway, because user programs will make them? I suppose we could #define them in libc headers. = > looks like maybe the get/put_user_ret() functions in asm/uaccess.h are = > obsolete? (TODO) = = yes, they are. exterminate! exterminate! Done From pdbeal@louisville.edu Tue, 14 Nov 2000 13:40:24 -0500 Date: Tue, 14 Nov 2000 13:40:24 -0500 From: Phillip D. Beal pdbeal@louisville.edu Subject: [parisc-linux] 735/755 and Kernel test10.. Hey, I've been working on the 735 and 755 that I has access to and so far the systems booted the test6 kernel, but scrambled the console as soon as init was run. So, I figured I'd try the new test10 kernel that you have added. Both system boot, and then stop at this line: branching to kernel entry point 0x00100000 Can't select default wide mode, PDC_PSW call does not work What does the above actually mean? How can I remove the PDC_PSW call from the kernel so it can boot? I have plans to test this new kernel image on a 715 later today. Thanks, -- Phillip Beal Electrical and Computer Engineering S+LUG Vice-President From grundler@cup.hp.com Tue, 14 Nov 2000 10:51:26 -0800 Date: Tue, 14 Nov 2000 10:51:26 -0800 From: Grant Grundler grundler@cup.hp.com Subject: [parisc-linux] 735/755 and Kernel test10.. "Phillip D. Beal" wrote: > Hey, > > I've been working on the 735 and 755 that I has access to and so far > the systems booted the test6 kernel, but scrambled the console as soon > as init was run. So, I figured I'd try the new test10 kernel that you > have added. Both system boot, and then stop at this line: > > branching to kernel entry point 0x00100000 > Can't select default wide mode, PDC_PSW call does not work Did you build this kernel yourself? If so, it sounds like you built a 64-bit kernel since that's the default. You need to change the ARCH line in the linux/Makefile to read "parisc" instead of "parisc64". grant > > What does the above actually mean? How can I remove the PDC_PSW call > from the kernel so it can boot? I have plans to test this new kernel > image on a 715 later today. > > Thanks, > -- > Phillip Beal > Electrical and Computer Engineering > S+LUG Vice-President > > --------------------------------------------------------------------------- > To unsubscribe: send e-mail to parisc-linux-request@thepuffingroup.com with > `unsubscribe' as the subject. > Grant Grundler Unix Systems Enablement Lab +1.408.447.7253 From grundler@cup.hp.com Tue, 14 Nov 2000 11:08:20 -0800 Date: Tue, 14 Nov 2000 11:08:20 -0800 From: Grant Grundler grundler@cup.hp.com Subject: [parisc-linux] 735/755 and Kernel test10.. Grant Grundler wrote: > If so, it sounds like you built a 64-bit kernel since that's the default. Correction. *was* the default. default ARCH was changed last night to parisc. grant Grant Grundler Unix Systems Enablement Lab +1.408.447.7253 From ian.zink@maryville.com Tue, 14 Nov 2000 13:20:05 -0600 Date: Tue, 14 Nov 2000 13:20:05 -0600 From: Ian Zink ian.zink@maryville.com Subject: [parisc-linux] Palinux on a 712/60 I have a hp 712/60 I was trying to get loaded with Pa-linux. I'm using the 0.5 version of the Pa-linux cd. If I boot right off the CD it all loads until it gets to Switching to PDC. At that point nothing happens. From I have read the list, that is because the kernel is switching the text console. However, the 712s don't have consoles. From what I have also read the CD should work if you pass the kernel the parameter console=tty. So I tried to "boot scsi.2.0 isl" from the boot_admin prompt. It gave me the PALO ISL, but I could not choose which line I wanted to edit. Further, I couldn't even type "b" to boot. I don't know if the isl is freezing or what is taking place What I am wondering is there a way to boot a 712/80 without having to get cross-compiler gcc, compile the kernel, etc. Is there someway I could add the ramdisk-sti.tgz on the ISO to make it work? If so, what would need to be done? Thanks, Ian Zink, Systems Engineer Maryville Technologies 540 Maryville Centre, Suite 300 St. Louis, MO 63141 636/519-4182 (FAX) 636/519-4141 ian.zink@maryville.com www.maryville.com From mang@subcarrier.org Tue, 14 Nov 2000 14:17:35 -0500 Date: Tue, 14 Nov 2000 14:17:35 -0500 From: Michael Ang mang@subcarrier.org Subject: linux bame bame@riverrock.org wrote: > > = On Thu, Nov 09, 2000 at 03:53:48PM -0700, Paul Bame wrote: > = > Somebody never imported 2.4.0-test6, then I imported -test10 on the mai > n > = > vendor branch and now can't (easily) undo that to import test6 and THEN > = > test10. This workaround sucks. If the sources on the linus branch have been religiously tagged every time they're updated, then reverting to a previous would have been relatively painless. I'm not sure what "this workaround" was, but I guess at this point test10 is merged so the point is moot. > = don't use vendor branches. didn't you talk to mang about this? > > Um, I have no information to go on from your note. All the (successful) > merges I've done before have used the cookbook CVS merge method including > a vendor branch. Several (N-1?) of the palinux merges have been > accompanied by updating the vendor branch. And this merge is going > well despite the ugly workaround, or so it appears to me. Just > importing files to a vendor branch should have no effect on anything > else unless CVS has some horrible bug (RCS does not). Before I make > what is apparently a serious mistake ("don't use vendor branches" sounds > pretty serious) please enlighten me! Vendor branches are evil. (When I say "vendor branch" I mean the special kind of branch created by "cvs import".) When you check in to a vendor branch your changes will also be seen on the trunk, *unless* that file has been previously modified on the trunk. This is almost never what you want and adds confusion during merging (when you least want it). Tracking third-party sources using a normal branch, as we are doing, is much simpler and gives you more control. When I did the original import of Linus' sources I converted the vendor branch to a normal branch using cvs admin magic. So none of the annoyances of vendor branches should affect us, as long as any new files are added on the linus branch using "cvs add", NOT "cvs import". When you say you "I imported -test10 on the main vendor branch" I hope you really mean that you used "cvs add" on the linus branch. From your other messages, your tags looked good. - Mike. From bame@noam.fc.hp.com Tue, 14 Nov 2000 13:00:41 -0700 Date: Tue, 14 Nov 2000 13:00:41 -0700 From: Paul Bame bame@noam.fc.hp.com Subject: linux bame = bame@riverrock.org wrote: = > = > = On Thu, Nov 09, 2000 at 03:53:48PM -0700, Paul Bame wrote: = > = > Somebody never imported 2.4.0-test6, then I imported -test10 on the mai = > n = > = > vendor branch and now can't (easily) undo that to import test6 and THEN = > = > test10. This workaround sucks. = = If the sources on the linus branch have been religiously tagged every = time they're updated, then reverting to a previous would have been = relatively painless. I'm not sure what "this workaround" was, but I = guess at this point test10 is merged so the point is moot. Like the comment said, there was no copy of plain -test6 in CVS (that I saw). Without -test6 in CVS it's much harder to use cvs diff to figure out the right way to merge files when there are conflicts. I didn't realize this until -test10 was already there, so I *then* brought in -test6. They're in the wrong order on the 1.1.1 branch, so the standard merge command 'cvs -jlinus:yesterday -jlinus:' won't work next time -- explicit names will be required. = Vendor branches are evil. (When I say "vendor branch" I mean the = special kind of branch created by "cvs import".) When you check in to a = vendor branch your changes will also be seen on the trunk, *unless* that = file has been previously modified on the trunk. Thanks for clarifying what "evil" means! That is pretty ugly indeed! = This is almost never = what you want and adds confusion during merging (when you least want = it). Tracking third-party sources using a normal branch, as we are = doing, is much simpler and gives you more control. But I've seen no cook book for it. I'm guessing that instead of cvs import you use: cvs co -rlinus linux cd linux cvs commit (make note of new files from commit) cvs add cvs commit cvs tag LINUS_NEW_REVISION perhaps with provision for removing obsolete files too. I suppose that is simpler than a single cvs import command from a certain perspective :-) = When I did the original import of Linus' sources I converted the vendor = branch to a normal branch using cvs admin magic. So none of the = annoyances of vendor branches should affect us, as long as any new files = are added on the linus branch using "cvs add", NOT "cvs import". Have you a pointer to the magic or the knowledge to recreate it? I had no idea there was a special RCS marking for the evil type of branch. = When you say you "I imported -test10 on the main vendor branch" I hope = you really mean that you used "cvs add" on the linus branch. From your = other messages, your tags looked good. I used "cvs import", and either your branch magic worked, or I finished the merge before anybody randomly updated from cvs. Since import used 1.1.1, which is the branch you "fixed", it seems possible that 'cvs import' might be rendered harmless but I don't know that for sure. -P From pjlahaie@linuxcare.com Tue, 14 Nov 2000 15:43:00 -0500 Date: Tue, 14 Nov 2000 15:43:00 -0500 From: Paul J.Y. Lahaie pjlahaie@linuxcare.com Subject: [parisc-linux] Beta CD --SkvwRMAIpAhPCcCJ Content-Type: text/plain; charset=us-ascii Content-Disposition: inline This is to answer all the questions about sti console. Currently, in the CVS tree, serial console and STI console cannot be turned on at the same time. This means that a choice between serial/sti needs to be done at compile time. At the time we cut the beta, it was decided that serial console was more important than sti console. I am also working on resolving the problem with STI/serial console and once I have a fix ready, I will make a kernel image available. The current beta CD is also expecting a console on ttyS0 and does not currently open a ttyx getty. When I have a kernel that can decide the console at runtime, I will look into the beta CD issues. If you have any more questions or suggestions, feel free to email me or post on this list. Thank you. - Paul --SkvwRMAIpAhPCcCJ Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.4 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE6EaPR8ggPQthPCzcRAhT8AKC8EU8yusyoEvPHxKAQsaM0vMGthwCgnbbC Yz6ZWjq3q9B80bI+YRxc8xo= =HhRZ -----END PGP SIGNATURE----- --SkvwRMAIpAhPCcCJ-- From raj@cerias.purdue.edu Tue, 14 Nov 2000 16:18:06 -0500 Date: Tue, 14 Nov 2000 16:18:06 -0500 From: Brian Poole raj@cerias.purdue.edu Subject: [parisc-linux] Beta CD Sounds like a plan to me. I don't suppose you know how to make a 715 boot to console? Pulling the keyboard and monitor cables off the back just make it stop at boot with the unable to initiliaze keyboard error I posted with earlier. I am assuming there is some sort of boot_admin trickery necessary, but I am unaware of what it might entail and my poking around has yielded nothing.. Any advice here would be much appreciated. -b Quoting Paul J.Y. Lahaie (pjlahaie@linuxcare.com) from 14 November 2000: > with STI/serial console and once I have a fix ready, I will make a kernel > image available. The current beta CD is also expecting a console on .. > If you have any more questions or suggestions, feel free to email me or > post on this list. Thank you. From dave@hiauly1.hia.nrc.ca Tue, 14 Nov 2000 16:40:52 -0500 (EST) Date: Tue, 14 Nov 2000 16:40:52 -0500 (EST) From: John David Anglin dave@hiauly1.hia.nrc.ca Subject: abort in eliminate_regs compiling glob.c from glibc > > Breakpoint 2, eliminate_regs_in_insn (insn=0x406a0ba0, replace=0) > > at ../../gcc/reload1.c:2826 > > 2826 if (! insn_is_asm && icode < 0) > > (gdb) p debug_rtx (insn) > > (insn/s 2711 2709 2719 (set (reg:SI 6 %r6) > > (reg:SI 28 %r28)) 69 {pre_ldw-4} (insn_list 2708 (insn_list:REG_DEP_ANTI 2696 (insn_list:REG_DEP_ANTI 2702 (insn_list:REG_DEP_ANTI 2697 (nil))))) > > (expr_list:REG_DEAD (reg:SI 28 %r28) > > (insn_list:REG_RETVAL 2708 (expr_list:REG_EQUAL (expr_list (use (mem:BLK (scratch) 0)) > > (expr_list (symbol_ref/v:SI ("@strlen")) > > (expr_list (reg/v:SI 4 %r4) > > (nil)))) > > (nil))))) > > The `use' arises from the `__pure__' attribute in the prototype for strlen: > > extern size_t strlen (__const char *__s) __attribute__ ((__pure__)); Here is a patch to fix the abort in eliminate_regs when it encounters a USE. As I understand the situation, there are three conditions needed to trigger it: 1) A function that contains insns with an eliminable register. 2) The function must call __builtin_alloca to change the frame size from its initial size. 3) After the call to __builtin_alloca, there must be a call to a pure function. With the enclosed patch, I can now build glibc for hppa-linux with -O3 optimisation. Please review carefully because I will be the first to admit that I don't understand why the use is there in the first place and all the details of what eliminate_reg does. Dave -- J. David Anglin dave.anglin@nrc.ca National Research Council of Canada (613) 990-0752 (FAX: 952-6605) 2000-11-14 John David Anglin * reload1.c (eliminate_regs): Don't abort on MEM USEs. --- reload1.c.orig Wed Sep 27 14:27:23 2000 +++ reload1.c Tue Nov 14 16:01:56 2000 @@ -2499,6 +2499,10 @@ return x; case USE: + /* Handle insn_list USE that a call to a pure functions may generate. */ + new = eliminate_regs (XEXP (x, 0), 0, insn); + if (GET_CODE (new) == MEM) + return XEXP (new, 0); case CLOBBER: case ASM_OPERANDS: case SET: From grundler@cup.hp.com Tue, 14 Nov 2000 14:32:00 -0800 Date: Tue, 14 Nov 2000 14:32:00 -0800 From: Grant Grundler grundler@cup.hp.com Subject: [parisc-linux] Palinux on a 712/60 Ian Zink wrote: > I have a hp 712/60 I was trying to get loaded with Pa-linux. I'm using the > 0.5 version of the Pa-linux cd. If I boot right off the CD it all loads > until it gets to Switching to PDC. At that point nothing happens. From I > have read the list, that is because the kernel is switching the text > console. However, the 712s don't have consoles. 712s have consoles. They have two outputs which can be used as console by linux. The STI consoles (VGA-like spigot) and serial. Connect a serial cable 9600-8-n-1 and run minicom at the other end. > From what I have also read > the CD should work if you pass the kernel the parameter console=tty. So I > tried to "boot scsi.2.0 isl" from the boot_admin prompt. It gave me the > PALO ISL, but I could not choose which line I wanted to edit. Further, I > couldn't even type "b" to boot. I don't know if the isl is freezing or what > is taking place That's a different problem...pb? > What I am wondering is there a way to boot a 712/80 without having > to get cross-compiler gcc, compile the kernel, etc. The CD was intended to also work on the 712 even though we may not have tested on it. > Is there someway I could > add the ramdisk-sti.tgz on the ISO to make it work? If so, what would need > to be done? no clue. anyone else? grant Grant Grundler Unix Systems Enablement Lab +1.408.447.7253 From mang@subcarrier.org Tue, 14 Nov 2000 17:31:22 -0500 Date: Tue, 14 Nov 2000 17:31:22 -0500 From: Michael Ang mang@subcarrier.org Subject: [parisc-linux] tracking third-party sources (was Re: linux bame) Paul Bame wrote: > > = bame@riverrock.org wrote: > = > > = > = On Thu, Nov 09, 2000 at 03:53:48PM -0700, Paul Bame wrote: > = > = > Somebody never imported 2.4.0-test6, then I imported -test10 on the > mai > = > n > = > = > vendor branch and now can't (easily) undo that to import test6 and > THEN > = > = > test10. This workaround sucks. > = > Like the comment said, there was no copy of plain -test6 in CVS (that I > saw). Without -test6 in CVS it's much harder to use cvs diff to figure > out the right way to merge files when there are conflicts. > I didn't realize this until -test10 was already there, so I *then* > brought in -test6. They're in the wrong order on the 1.1.1 branch, so > the standard merge command 'cvs -jlinus:yesterday -jlinus:' > won't work next time -- explicit names will be required. The best thing to do is to import -test10 again and move the static tag by re-tagging. > = Tracking third-party sources using a normal branch, as we are > = doing, is much simpler and gives you more control. > > But I've seen no cook book for it. I'm guessing that instead of cvs import > you use: > cvs co -rlinus linux > > cd linux > cvs commit (make note of new files from commit) > cvs add > cvs commit > cvs tag LINUS_NEW_REVISION > perhaps with provision for removing obsolete files too. I suppose that is > simpler than a single cvs import command from a certain perspective :-) I had a good chat with Paul about this, and we worked out that using "import" is marginally better. This is what the add/remove method would look like: cvs co -rlinux linux cvs rm cvs add cvs commit cvs tag LINUS_NEW_REVISION Add the import method: cd linux cvs import linux linus LINUS_NEW_REVISION cvs admin -b > = When you say you "I imported -test10 on the main vendor branch" I hope > = you really mean that you used "cvs add" on the linus branch. From your > = other messages, your tags looked good. > > I used "cvs import", and either your branch magic worked, or I finished the > merge before anybody randomly updated from cvs. Since import used 1.1.1, > which is the branch you "fixed", it seems possible that 'cvs import' might > be rendered harmless but I don't know that for sure. Using "import" to bring in new files taints them with the vendor branch badness. These files should be adjusted using "cvs admin -b". Note that "cvs admin" works directly on files in the repository at low level (without any revisioning of changes) and is thus to be avoided if at all possible. Please don't run "cvs admin" if you (the collective "you") don't know the consequences. - Mike. From ian.zink@maryville.com Tue, 14 Nov 2000 17:08:33 -0600 Date: Tue, 14 Nov 2000 17:08:33 -0600 From: Ian Zink ian.zink@maryville.com Subject: [parisc-linux] Palinux on a 712/60 Thanks for the reply, Grant. However, the 712s do not have a serial console. They do have a com port, but it does not work as a console, unfortunately. So I need do need to get a STI enabled kernel. I dropped Paul Lahaie a note to see if he could send me such a kernel so I do not have to create the entire cross-platform development environment just to boot one of these 712s. After I get it, I plan on expanding the 0.5 iso and making a new one using the STI console kernel. Ian From kailasr@webcash.com Tue, 14 Nov 2000 14:58:55 -0800 Date: Tue, 14 Nov 2000 14:58:55 -0800 From: Kailashnath V Rampure kailasr@webcash.com Subject: [parisc-linux] Boot command I have booted HP A class server through network. On that I have repartioned the system and followed the steps on http://www.parisc-linux.org/install.html. I have used the following command to initialize the hard disk. The kernel I have downloaded is vmlinux-20001018. and cpied it to /mnt/boot/vmlinux after mounting /dev/sda3. I have used the following command to initialize the HDD. palo -I -k /boot/vmlinux -b /boot/iplboot \ -c '3/boot/vmlinux TERM=linux HOME=/ root=/dev/sda3' \ /dev/sda -------------------------------- I get the following error: -------------------------------- SOFT Boot. palo ipl bame@noam Tue oct 31 14:18:02 MST 2000 0/vmlinux 2138614 bytes@ 0x1f78c000 0/palo-cmdline '3/boot/vmlinux TERM=linux HOME=/ root=/dev/sda3' /dev/ida1 82 62 1030688 /dev/ida2 f0 1030750 24738 /dev/ida3 83 1055488 1030750 Kernel:partition 3 file /boot/vmlinux ext2 block size 1024 ext2_mount(partition 3) returns 0 ext2_open(/boot/vmlinux) = -1 open /boot/vmlinux failed ------------------------------------- Please suggest. From grundler@cup.hp.com Tue, 14 Nov 2000 15:18:10 -0800 Date: Tue, 14 Nov 2000 15:18:10 -0800 From: Grant Grundler grundler@cup.hp.com Subject: [parisc-linux] Palinux on a 712/60 Ian Zink wrote: > Thanks for the reply, Grant. However, the 712s do not have a serial console. > They do have a com port, but it does not work as a console, unfortunately. It does for linux. That's what the "Switching from PDC Console" is about. Connect the serial cable to the com port and look at the output. I've done it in the past and know it worked at least once. I haven't tried it with the lasted ISO - no time to play w/712's now. > So I need do need to get a STI enabled kernel. I dropped Paul Lahaie a note > to see if he could send me such a kernel... Paul just sent mail to the list indicating he's working on console issues. Please let him work on it. Trust me, he'll tell us when he's done. :^) grant From dhazeghi@pacbell.net Tue, 14 Nov 2000 18:17:39 -0800 Date: Tue, 14 Nov 2000 18:17:39 -0800 From: dhazeghi@pacbell.net dhazeghi@pacbell.net Subject: [parisc-linux] [Semi OT] SOM Linker Alex deVries wrote: > dhazeghi@pacbell.net wrote: > > However I would like to know what work if any has been done on the SOM > > linker which HP released to the public last November(?). It seems that > > as of right now, it has not been touched since February 14, and the FSF > > binutils snapshots still do not have any SOM support for ld. Has there > > been any movement in merging this in, or is anybody working on this? > > The initial plan was to do our 32-bit userspace with SOM, worrying about > ELF32 much later in the game. But ELF32 development happened a lot > quicker than expected, and so nobody's really done much on the SOM > linker. That's what it looked like... > > > I suspect it'd be very hard to use the SOM linker code to incorporate it > into binutils, but I could be wrong. > > What are you actually trying to do? I would like to be able to set up a cross compilation environment for hpux and 32 bit PA-RISC. However without a functional cross linker, this is impossible to do, and as binutils has not got one yet, I thought perhaps the one that HP open-sourced might be some use. It would seem logical that with the sources available, it shouldn't be too difficult to fix the broken bits and get a SOM linker working in binutils, but that doesn't seem to have happened yet. Oh well, thanks for the info... Dara Hazeghi From dave@hiauly1.hia.nrc.ca Tue, 14 Nov 2000 22:00:25 -0500 (EST) Date: Tue, 14 Nov 2000 22:00:25 -0500 (EST) From: John David Anglin dave@hiauly1.hia.nrc.ca Subject: [parisc-linux] [Semi OT] SOM Linker > I would like to be able to set up a cross compilation environment for hpux and > 32 bit PA-RISC. However without a functional cross linker, this is impossible > to do, and as binutils has not got one yet, I thought perhaps the one that HP > open-sourced might be some use. It would seem logical that with the sources > available, it shouldn't be too difficult to fix the broken bits and get a SOM > linker working in binutils, but that doesn't seem to have happened yet. Oh > well, thanks for the info... You should be able to build cross compilation tools under hpux for hppa-linux. First you should install native versions of binutils and gcc under hpux (this assumes that you have the hpux C compiler and linker). The release version of gcc (2.95.2) would be a good choice. The standard hpux linker works fine with gcc/gas for C compilations. Then follow the directions at www.parisc-linux.org for building the cross compilation tools and linux. Dave -- J. David Anglin dave.anglin@nrc.ca National Research Council of Canada (613) 990-0752 (FAX: 952-6605) From dhazeghi@pacbell.net Tue, 14 Nov 2000 21:23:41 -0800 Date: Tue, 14 Nov 2000 21:23:41 -0800 From: dhazeghi@pacbell.net dhazeghi@pacbell.net Subject: [parisc-linux] [Semi OT] SOM Linker John David Anglin wrote: > > I would like to be able to set up a cross compilation environment for hpux and > > 32 bit PA-RISC. However without a functional cross linker, this is impossible > > to do, and as binutils has not got one yet, I thought perhaps the one that HP > > open-sourced might be some use. It would seem logical that with the sources > > available, it shouldn't be too difficult to fix the broken bits and get a SOM > > linker working in binutils, but that doesn't seem to have happened yet. Oh > > well, thanks for the info... > > You should be able to build cross compilation tools under hpux for hppa-linux. > First you should install native versions of binutils and gcc under hpux (this > assumes that you have the hpux C compiler and linker). The release version of > gcc (2.95.2) would be a good choice. The standard hpux linker works fine with > gcc/gas for C compilations. Then follow the directions at www.parisc-linux.org > for building the cross compilation tools and linux. This is not precisely what I mean. What I should have said is that I want to create a cross compiler --host=i686-linux --target=hppa-hpux. I asked this list, because you folks did some work on the SOM linker, which is at the moment the missing piece for a cross toolchain which targets hpux. Thanks, Dara P.S. On a different note, is the recipe fully up to date? I tried following it a few weeks ago, but glibc did not complete building successfully. From Arnaud.ATOCH@oecd.org Wed, 15 Nov 2000 10:05:04 +0100 Date: Wed, 15 Nov 2000 10:05:04 +0100 From: Arnaud.ATOCH@oecd.org Arnaud.ATOCH@oecd.org Subject: [parisc-linux] Palinux on a 712/60 Hi, I got a couple of 715 and I'd love having access to an ISO image with STI console kernel too. -----Original Message----- From: Ian Zink [mailto:ian.zink@maryville.com] Sent: Wednesday, November 15, 2000 00:09 To: 'parisc-linux@thepuffingroup.com' Subject: RE: [parisc-linux] Palinux on a 712/60 Thanks for the reply, Grant. However, the 712s do not have a serial console. They do have a com port, but it does not work as a console, unfortunately. So I need do need to get a STI enabled kernel. I dropped Paul Lahaie a note to see if he could send me such a kernel so I do not have to create the entire cross-platform development environment just to boot one of these 712s. After I get it, I plan on expanding the 0.5 iso and making a new one using the STI console kernel. Ian --------------------------------------------------------------------------- To unsubscribe: send e-mail to parisc-linux-request@thepuffingroup.com with `unsubscribe' as the subject. From rhirst@linuxcare.com Wed, 15 Nov 2000 09:58:35 +0000 Date: Wed, 15 Nov 2000 09:58:35 +0000 From: Richard Hirst rhirst@linuxcare.com Subject: [parisc-linux] dino maintainer? On Tue, Nov 14, 2000 at 08:10:42AM -0800, Grant Grundler wrote: > The bug is normal for card-mode Dino - not for Built-in Dino. > I think Helge has the GSC 100BT card which is a card-mode Dino on-board > with one (or two) Tulip(s) behind it. > > The warning is a reminder one can NOT use MMIO accesses to those > PCI devices and *only* I/O Port space (eg inb/outb). > > If someone wants to fix the warning so it's quiet for card-mode > devices...see is_card_dino(d) in dino_driver_callback() for an > example. > > FYI - card-mode dino was used for several different networking > interfaces but not SCSI interfaces. But Helge has problems with the sym53c8xx driver on a B160L. Is that a PCI card driven via Dino? And if so, are you saying he needs to build his kernel with CONFIG_SCSI_NCR53C8XX_IOMAPPED=y so it doesn't try to use MMIO? Helge, it might be worth trying to switch on CONFIG_SCSI_NCR53C8XX_IOMAPPED anyway just to see what happens. Otherwise someone needs to start adding printk debug to figure out what is happening. I can't do that as I don't have a sym53c8xx pci card. Richard From andrew@neep.com.au Wed, 15 Nov 2000 18:10:13 +0800 Date: Wed, 15 Nov 2000 18:10:13 +0800 From: Andrew Shugg andrew@neep.com.au Subject: [parisc-linux] Palinux on a 712/60 Arnaud.ATOCH@oecd.org said: > Hi, > > I got a couple of 715 and I'd love having access to an ISO image with STI > console kernel too. I've never made an El Torito CDROM, is it possible to have multiple boot images and a boot loader on a single disc? ie could the actual boot image be a boot loader (PALO) which then points at one or more kernels on the CDROM? Andrew. -- Andrew Shugg http://www.neep.com.au/ "Just remember, Mr Fawlty, there's always someone worse off than yourself." "Is there? Well I'd like to meet him. I could do with a good laugh." From marteaut@esiee.fr Wed, 15 Nov 2000 11:25:07 +0100 Date: Wed, 15 Nov 2000 11:25:07 +0100 From: Thomas Marteau marteaut@esiee.fr Subject: [parisc-linux] Palinux on a 712/60 Hi Ian, If you like to see a linux kernel booting on your 712, you can donwload a fully operationnal root file system with the STI console and an extra terminal with the RS232 port at http://www.esiee.fr/puffin You have also all the info to make a bootable hard disk so try it and give us feedback... Bye, Thomas Marteau ESIEE Team From rhirst@linuxcare.com Wed, 15 Nov 2000 11:12:20 +0000 Date: Wed, 15 Nov 2000 11:12:20 +0000 From: Richard Hirst rhirst@linuxcare.com Subject: [parisc-linux] Beta CD On Fri, Nov 10, 2000 at 05:14:06PM -0500, Paul J.Y. Lahaie wrote: > Hello fellow PA-RISCers, > > An preliminary beta CD for PA/Linux has been uploaded to > puffin.external.hp.com. If people could try it and forward any complaints > or suggestions to me, it would be greatly appreciated. The URL for the > image is: ftp://puffin.external.hp.com/pub/parisc/cd-images/palinux-0.5.iso.gz I just borrowed a CDROM drive for my 715/75 so I could try it on there [Actually this is the palinux-0.5.iso.gz that I commented on, not the final version]. I wasn't successful: Sometimes the boot hangs after "ASP version 1 at 0xf0800000 found", waits a few seconds and then HPMCs. The scsi driver always has serious problems with the CD drive but does detect other devices on the bus. The kernel always crashes after "Serial driver version 5.01...", (if it gets that far) with Data access rights fault in kernel: Code=26 regs=c5f9c940 (Addr=00000003) YZrvWESTHLNXBCVMcbcbcbcbOGFRQPDI PSW: 00000000000001000000000000001010 r0-3 00000000 c0217800 c011e9f8 c5ff64a0 r4-7 c5ff6200 c023ab20 00000008 f0823800 r8-11 00000003 00000007 c019134c c02b20a0 r12-15 fffffffc c023a800 c023a800 c02c31cc r16-19 c023a800 c023a800 c02b2024 00000000 r20-23 c5ff6234 f0823807 f0823800 0000000a r24-27 ffffffff c5ff64a0 c5ff6200 c0258000 r28-31 ffffffff 000002c0 c5f9cb80 c012dfc0 sr0-4 00000000 00000000 00000000 00000000 sr4-8 00000000 00000000 00000000 00000000 IASQ: 00000000 00000000 IAOQ: c011e710 c011e714 IIR: 0f881093 ISR: 00000000 IOR: 00000003 ORIG_R28: 00000058 I'll investigate further when I have the time. Richard From adevries@linuxcare.com Wed, 15 Nov 2000 11:50:27 -0500 Date: Wed, 15 Nov 2000 11:50:27 -0500 From: Alex deVries adevries@linuxcare.com Subject: [parisc-linux] dino maintainer? Richard Hirst wrote: > On Tue, Nov 14, 2000 at 08:10:42AM -0800, Grant Grundler wrote: > > FYI - card-mode dino was used for several different networking > > interfaces but not SCSI interfaces. > > But Helge has problems with the sym53c8xx driver on a B160L. Is > that a PCI card driven via Dino? And if so, are you saying he needs > to build his kernel with CONFIG_SCSI_NCR53C8XX_IOMAPPED=y so it > doesn't try to use MMIO? Hang on a sec... what Grant's saying is that *card-mode* dino is never used for SCSI controllers, but on the B160L it would probably be *chip-mode* dino. Does this mean that all GSC SCSI expansion cards are Zalon based? So what Helge has isn't a PCI card specifically, Dino and the 53c8xx are all on the motherboard. Does Dino handle IO memory mapping differently for chip or card mode? - Alex -- Alex deVries, Principal Solutions Architect, The Puffins at Linuxcare 613.562.2759 tel alex@linuxcare.com, http://www.linuxcare.com/ Linuxcare, Support for the revolution. From grundler@cup.hp.com Wed, 15 Nov 2000 08:06:32 -0800 Date: Wed, 15 Nov 2000 08:06:32 -0800 From: Grant Grundler grundler@cup.hp.com Subject: [parisc-linux] dino maintainer? Richard Hirst wrote: > On Tue, Nov 14, 2000 at 08:10:42AM -0800, Grant Grundler wrote: > > The bug is normal for card-mode Dino - not for Built-in Dino. > > I think Helge has the GSC 100BT card which is a card-mode Dino on-board > > with one (or two) Tulip(s) behind it. Helge confirmed he has no such card. I think the PDC simply isn't programming the Dino IO_ADDR_EN since there are no PCI devices in his B160. Helge's B160 has a old rev of Dino PCI host bus adapter chip. It's possible to have "silent" data corruption caused by older revs of dino - 3.0 and older. The latest PDC Revisions (5.x and later) know this and won't permit the system to be booted unless the only devices on the PCI bus are known graphics interface cards. > > The warning is a reminder one can NOT use MMIO accesses to those > > PCI devices and *only* I/O Port space (eg inb/outb). > > > > If someone wants to fix the warning so it's quiet for card-mode > > devices...see is_card_dino(d) in dino_driver_callback() for an > > example. This is still correct for card-mode dino. > > FYI - card-mode dino was used for several different networking > > interfaces but not SCSI interfaces. > > But Helge has problems with the sym53c8xx driver on a B160L. Is > that a PCI card driven via Dino? I doubt it now. If Helge could send richard "in io" output, I think that would clarify what's in the B160. > And if so, are you saying he needs > to build his kernel with CONFIG_SCSI_NCR53C8XX_IOMAPPED=y so it > doesn't try to use MMIO? no. no SCSI was ever implement on a card-mode dino board. No reason to since they already had Zalon or open slots. grant > Helge, it might be worth trying to switch on CONFIG_SCSI_NCR53C8XX_IOMAPPED > anyway just to see what happens. Otherwise someone needs to start > adding printk debug to figure out what is happening. I can't do > that as I don't have a sym53c8xx pci card. > > Richard From grundler@cup.hp.com Wed, 15 Nov 2000 08:17:41 -0800 Date: Wed, 15 Nov 2000 08:17:41 -0800 From: Grant Grundler grundler@cup.hp.com Subject: [parisc-linux] dino maintainer? Alex deVries wrote: > Hang on a sec... what Grant's saying is that *card-mode* dino is never > used for SCSI controllers, but on the B160L it would probably be > *chip-mode* dino. No such thing - you probably mean "Bridge Mode" and that's what the built-in Dino is using. > Does this mean that all GSC SCSI expansion cards are Zalon based? > > So what Helge has isn't a PCI card specifically, Dino and the 53c8xx are > all on the motherboard. > > Does Dino handle IO memory mapping differently for chip or card mode? yes. yes. yes (conditional). "IO memory mapping" is a confusing term. I'll assume you mean MMIO. (Memory Mapped I/O) MMIO space access is independent of I/O Port space access. MMIO space access simple isn't available for card-mode Dino since niether PDC nor the OS assigns host physical address space to the card-mode Dino (that's what IO_ADDR_EN is for). PDC does this for Bridge-mode dino (built-in) - but apperently only when it needs to. I/O Port space accesses are done the same way for both modes. I/O Port space access is implemented by poking registers on Dino. Read the Dino Spec (or source) for more details. grant Grant Grundler Unix Systems Enablement Lab +1.408.447.7253 From dave@hiauly1.hia.nrc.ca Wed, 15 Nov 2000 11:23:05 -0500 (EST) Date: Wed, 15 Nov 2000 11:23:05 -0500 (EST) From: John David Anglin dave@hiauly1.hia.nrc.ca Subject: [parisc-linux] [Semi OT] SOM Linker > This is not precisely what I mean. What I should have said is that I want to create > a cross compiler --host=i686-linux --target=hppa-hpux. I asked this list, because > you folks did some work on the SOM linker, which is at the moment the missing piece > for a cross toolchain which targets hpux. This also may be possible. The first step would be to copy the hpux headers to a i686-linux system and see if you can build the HP linker. The next step would be to try to build the cross binutils tools. I know this requires the hpux headers and likely some hacking would be required to get it to build. The linker is probably the hard part. There may be byte ordering issues and bugs in what HP contributed. Dave -- J. David Anglin dave.anglin@nrc.ca National Research Council of Canada (613) 990-0752 (FAX: 952-6605) From pdbeal@louisville.edu Wed, 15 Nov 2000 11:47:09 -0500 Date: Wed, 15 Nov 2000 11:47:09 -0500 From: Phillip D. Beal pdbeal@louisville.edu Subject: [parisc-linux] Beta CD On Fri, Nov 10, 2000 at 05:14:06PM -0500, Paul J.Y. Lahaie wrote: > Hello fellow PA-RISCers, > > An preliminary beta CD for PA/Linux has been uploaded to > puffin.external.hp.com. If people could try it and forward any complaints > or suggestions to me, it would be greatly appreciated. The URL for the > image is: ftp://puffin.external.hp.com/pub/parisc/cd-images/palinux-0.5.iso.gz > > - Paul the CD worked great on the 715 I tried, and I actually didn't have a serial console machine, so I used my Palm Pilot and a link cable. Still worked like a charm. How did you get the kernel image into the boot sector of the CD? I'd like to try to build some CD's of the kernels I'm building to test in some mahcines that are not on the same network as the machine that I'm building everything from. And I don't mind posting my CD images somewhere if they work...but most of my testing is on a 735 or 755. Thanks, -- Phillip Beal Electrical and Computer Engineering S+LUG Vice-President From bame@noam.fc.hp.com Wed, 15 Nov 2000 10:08:22 -0700 Date: Wed, 15 Nov 2000 10:08:22 -0700 From: Paul Bame bame@noam.fc.hp.com Subject: [parisc-linux] Help with posix_types.h I'm reviewing the posix_types.h to figure out what's right for 64-bit linux. I know others may have thought through this before so I'm hoping for guidance. For those unfamiliar, the type names in posix_types.h are like __kernel_dev_t and usually are used to define the corresponding "normal" type (dev_t). These should be settled before the 32/64 syscall wrappers can be completed. __kernel_ino_t: often 32 bits, currently 32 bits for parisc and som3 64-bit kernels (mips64 and ia64). 64 bits on alpha and sparc64. Seems to me this ought to be 32 bits on parisc and parisc64, or 64 bits on both, since it's a function of file system sizes not processor width. HPUX kernel seems to always use 32 bits, but 64-bit userspace uses 64 bits. I propose 32 bits on both, but willy had selected 64 bits in parisc64 for some reason. __kernel_off_t: seems to be 32 bits on 32-bit cpus, 64 on 64-bit ones. This is supposedly the offset from a beginning of a file. HPUX appears to use 64-bits *in the kernel* for both 32 and 64-bit kernels. The obvious pattern is to make ours 32 on narrow, and 64 on wide palinux so I guess I propose that, and that's the way it was before I hacked on it too. Should we consider switching to 64 bits on narrow palinux since this is related to file systems, not CPUs. Note there's also a __kernel_loff_t -> loff_t which appears to be defined as 64 bits. I'm not sure how this does/should interact with off_t (lseek vs lseek64 for example). __kernel_suseconds_t: which becomes suseconds_t which is used in struct timeval { time_t tv_sec; /* seconds */ suseconds_t tv_usec; /* microseconds */ }; I'm confused why hpux, and other systems, like for this to be 'long' (e.g., 64 bits on 64-bit processors) since it seems like values over a million are probably rare and 32 bits seems to be enough for most implementations. sparc64 chose 32 bits for this and I want to do the same for parisc64 because it will reduce the amount of syscall structure repackings. Comments? __kernel_daddr_t: which is used indirectly in struct solaris_x86_vtoc and solaris_x86_slice which *might* be an on-disk data structures (used with CONFIG_SOLARIS_X86_PARTITION). So this needs to be 32 bits if that's the case (definition from sparc) and several archs have it 64 bits! On the other hand, HPUX's man page says 'daddr_t used for disk addresses except in an inode [and partition table I would think] on disk'. So it should probably be the same type as off_t. FYI the only other place it's used is in 'struct mtio' -- used to talk to magnetic tape units. I'm guessing the sparc struct should not be using this type, and that we should define it the same as off_t. Comments? From kailasr@webcash.com Wed, 15 Nov 2000 09:55:09 -0800 Date: Wed, 15 Nov 2000 09:55:09 -0800 From: Kailashnath V Rampure kailasr@webcash.com Subject: [parisc-linux] Boot command Yes Thomas the vmlinux is in /boot of 3rd partition as the other partitions are swap and f0. At 11:48 AM 11/15/00 +0100, Thomas Marteau wrote: >----- Original Message ----- >From: Kailashnath V Rampure >To: Paul Bame >Cc: Grant Grundler ; Matt Taggart >; >Sent: Tuesday, November 14, 2000 11:58 PM >Subject: Re: [parisc-linux] Boot command > > > > I have booted HP A class server through network. On that I have >repartioned > > the system and followed the steps on >http://www.parisc-linux.org/install.html. > > I have used the following command to initialize the hard disk. The kernel >I > > have downloaded is vmlinux-20001018. and cpied it to /mnt/boot/vmlinux > > after mounting /dev/sda3. I have used the following command to initialize > > the HDD. > > > > palo -I -k /boot/vmlinux -b /boot/iplboot \ -c '3/boot/vmlinux TERM=linux > > HOME=/ root=/dev/sda3' \ /dev/sda > >This means that vmlinux must be in /boot in your third partition on your >disk. >Is it true in your case? > > > -------------------------------- > > I get the following error: > > -------------------------------- > > SOFT Boot. > > palo ipl bame@noam Tue oct 31 14:18:02 MST 2000 > > 0/vmlinux 2138614 bytes@ 0x1f78c000 > > 0/palo-cmdline '3/boot/vmlinux TERM=linux HOME=/ root=/dev/sda3' > > /dev/ida1 82 62 1030688 > > /dev/ida2 f0 1030750 24738 > > /dev/ida3 83 1055488 1030750 > > Kernel:partition 3 file /boot/vmlinux > > ext2 block size 1024 > > ext2_mount(partition 3) returns 0 > > ext2_open(/boot/vmlinux) = -1 > > open /boot/vmlinux failed > > ------------------------------------- > > Please suggest. > > > > -------------------------------------------------------------------------- >- > > To unsubscribe: send e-mail to parisc-linux-request@thepuffingroup.com >with > > `unsubscribe' as the subject. > > > > From bame@noam.fc.hp.com Wed, 15 Nov 2000 11:05:14 -0700 Date: Wed, 15 Nov 2000 11:05:14 -0700 From: Paul Bame bame@noam.fc.hp.com Subject: [parisc-linux] Beta CD = How did you get the kernel image into the boot = sector of the CD? I'd like to try to build some CD's of the kernels I'm = building to test in some mahcines that are not on the same network as = the machine that I'm building everything from. The magic for making bootable CDs is documented in the PALO README.html which you have on your system already since you're building kernels. -P From marteaut@esiee.fr Wed, 15 Nov 2000 19:10:56 +0100 Date: Wed, 15 Nov 2000 19:10:56 +0100 From: Thomas Marteau marteaut@esiee.fr Subject: [parisc-linux] Boot command Hi again, You put the swap partition before the f0 partition and here it is the f0 partition in first position. Also, your hard disk is ida instead of sda, what's that ? Bye, ESIEE Team ----- Original Message ----- From: Kailashnath V Rampure To: Thomas Marteau Cc: Sent: Wednesday, November 15, 2000 6:55 PM Subject: Re: [parisc-linux] Boot command > Yes Thomas the vmlinux is in /boot of 3rd partition as the other partitions > are swap and f0. > > At 11:48 AM 11/15/00 +0100, Thomas Marteau wrote: > > >----- Original Message ----- > >From: Kailashnath V Rampure > >To: Paul Bame > >Cc: Grant Grundler ; Matt Taggart > >; > >Sent: Tuesday, November 14, 2000 11:58 PM > >Subject: Re: [parisc-linux] Boot command > > > > > > > I have booted HP A class server through network. On that I have > >repartioned > > > the system and followed the steps on > >http://www.parisc-linux.org/install.html. > > > I have used the following command to initialize the hard disk. The kernel > >I > > > have downloaded is vmlinux-20001018. and cpied it to /mnt/boot/vmlinux > > > after mounting /dev/sda3. I have used the following command to initialize > > > the HDD. > > > > > > palo -I -k /boot/vmlinux -b /boot/iplboot \ -c '3/boot/vmlinux TERM=linux > > > HOME=/ root=/dev/sda3' \ /dev/sda > > > >This means that vmlinux must be in /boot in your third partition on your > >disk. > >Is it true in your case? > > > > > -------------------------------- > > > I get the following error: > > > -------------------------------- > > > SOFT Boot. > > > palo ipl bame@noam Tue oct 31 14:18:02 MST 2000 > > > 0/vmlinux 2138614 bytes@ 0x1f78c000 > > > 0/palo-cmdline '3/boot/vmlinux TERM=linux HOME=/ root=/dev/sda3' > > > /dev/ida1 82 62 1030688 > > > /dev/ida2 f0 1030750 24738 > > > /dev/ida3 83 1055488 1030750 > > > Kernel:partition 3 file /boot/vmlinux > > > ext2 block size 1024 > > > ext2_mount(partition 3) returns 0 > > > ext2_open(/boot/vmlinux) = -1 > > > open /boot/vmlinux failed From dave@hiauly1.hia.nrc.ca Wed, 15 Nov 2000 13:09:49 -0500 (EST) Date: Wed, 15 Nov 2000 13:09:49 -0500 (EST) From: John David Anglin dave@hiauly1.hia.nrc.ca Subject: [parisc-linux] Help with posix_types.h The largest disk currently available I believe is the 180GB Seagate Baracuda. The size of drives is increasing about a factor of 2 per year. The __kernel_off_t definitely needs to be 64 bits to handle large drives in both 32 and 64 bit systems. Disk blocks are typically 512 or 1024 bytes. Thus, drives may exceed 4GB disk blocks in 3-4 years. Inodes are variable in size (8KB average). Thus, we are a little further away from exceeding the 32 bit inode limit. Dave -- J. David Anglin dave.anglin@nrc.ca National Research Council of Canada (613) 990-0752 (FAX: 952-6605) From bame@noam.fc.hp.com Wed, 15 Nov 2000 11:12:57 -0700 Date: Wed, 15 Nov 2000 11:12:57 -0700 From: Paul Bame bame@noam.fc.hp.com Subject: [parisc-linux] Boot command = You put the swap partition before the f0 partition and here it is the f0 = partition in first position. The partition order doesn't matter so long as the f0 partition and the partition containing your kernel (an ext2 partition) *end* within the first 2Gb of the disk. See the PALO README.html. = Also, your hard disk is ida instead of sda, what's that ? PALO lists the devices as 'ida' instead of 'sda' or 'hda' since it is using the firmware 'IODC' interface to talk to the boot device, and it has no idea what type of boot device IODC is providing. -P From rhirst@linuxcare.com Wed, 15 Nov 2000 18:48:08 +0000 Date: Wed, 15 Nov 2000 18:48:08 +0000 From: Richard Hirst rhirst@linuxcare.com Subject: [parisc-linux] Single-stepping (Oops, CC-ed to the wrong list first time!) Hi John, I've been helping Alan Modra out with kernel changes to support single stepping for gdb. Paul Bame suggested I bounced our ideas off you in case you (or anyone else) had any comments. I havn't actually committed my changes yet. The basic approach is to use the recovery counter to generate a trap every instruction. The scheme is complicated because a suspended process may or may not return to user space via an RFI. If it was suspended as a result of an interrupt then we can simply set PSW bit R in the tasks saved registers and it will get loaded by the RFI. On every task switch I set the recovery counter to 0, just in case the new process is being single-stepped. If a process is suspended during a syscall, then there is no RFI on the return path to userland, and we have to handle things differently. I have changed the syscall return path such that it loads the recovery counter with 3 before updating the PSW with a value from the tasks saved registers. If that PSW has the R bit set, then the count of 3 will generate a trap on the first instruction following the branch back to user space. Note that PSW wasn't previously restored on the syscall return path. To avoid further complications of interrupts during the three instructions when the recovery counter is decrementing, whenever we set the R bit, we also clear the I bit to disable interrupts. Nullified instructions are handled by the controlling process manually moving the childs IAOQ over the instruction without actually setting it running, because the recovery counter isn't decremented for nullified instructions. I need to do some more testing before committing this, but would welcome any comments on the basic approach taken, areas I have mis-understood, or problems with it that might not yet have occurred to me. Thanks, Richard From andreas@bawue.de Thu, 16 Nov 2000 20:20:41 +0100 Date: Thu, 16 Nov 2000 20:20:41 +0100 From: Andreas Thienemann andreas@bawue.de Subject: [parisc-linux] 250/1 doesn't boot but dumps stack This is a multi-part message in MIME format. --------------F7EF1B69F0A7C4C7DD54E27D Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hi, I recently got a D-Class HP900 250/1 (at least it says that on the label) and tried to get the pa-risc port running on it. So I got a CVS checkout and build the whole toolchain without any major hassles. The kernel, including NFS-ROOT, built also without any glitches. But when I try to boot up this kernel it dumps stack right after initialising the pty interfaces. (I already left out everything unnecessary, such as parallel port support) After that it complains about "Data acces rights fault in kernel: Code=26 regs=c7f98780 (Addr=000000004)" and some more data... For the curious, the boot sequence is attached. I hope someone can give me a clue what might be wrong... Thanks, Andreas --------------F7EF1B69F0A7C4C7DD54E27D Content-Type: text/plain; charset=us-ascii; name="hp9000-capture" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="hp9000-capture" Firmware Version 36.34 Duplex Console IO Dependent Code (IODC) revision 0 ------------------------------------------------------------------------------ (c) Copyright 1995-1998, Hewlett-Packard Company, All rights reserved ------------------------------------------------------------------------------ Processor Speed State Coprocessor State Cache Size --------- -------- --------------------- ----------------- ---------- 0 101 MHz Active Functional 256 KB Central Bus Speed (in MHz) : 101 Available memory (bytes) : 134217728 Good memory required (bytes): 15245312 Primary boot path: 8/16/5.5 (dec) Alternate boot path: 8/16/5.2 (dec) Console path: 8/16/4.0 (dec) Keyboard path: 8/16/7.0 (dec) Processor is booting from first available device. To discontinue, press any key within 10 seconds. Boot terminated. ------- Main Menu ------------------------------------------------------------- Command Description ------- ----------- BOot [PRI|ALT|] Boot from specified path PAth [PRI|ALT|CON|KEY] [] Display or modify a path SEArch [DIsplay|IPL] [] Search for boot devices COnfiguration [] Access Configuration menu/commands INformation [] Access Information menu/commands SERvice [] Access Service menu/commands DIsplay Redisplay the current menu HElp [|] Display help for menu or command RESET Restart the system ------- Main Menu: Enter command > bo 8/16/6.0 Interact with IPL (Y or N)?> n Booting... Network Station Address 0060b0-3c08d4 Boot IO Dependent Code (IODC) revision 2 HARD Booted. palo ipl root@gate.ixs.com Wed Nov 15 14:08:22 CET 2000 0/vmlinux 2143238 bytes @ 0x6800 0/palo-cmdline '0/vmlinux HOME=/ TERM=LINUX root=/dev/nfs nfsroot=192.168.1.1 ' Kernel: partition 0 file /vmlinux ELF32 executable Entry 00100120 first 00100000 n 4 Segment 0 load 00100000 size 1467884 mediaptr 0x1000 Segment 1 load 00268000 size 174520 mediaptr 0x168000 Segment 2 load 00294000 size 103180 mediaptr 0x193000 Segment 3 load 002b0000 size 8192 mediaptr 0x1ad000 branching to kernel entry point 0x00100120 Set default PSW W bit to 0 PDC Console Initialized The 32-bit Kernel has started... Enabled FP coprocessor Free memory starts at: 0xc02dc000 start_parisc(0x504d6c,0x504d6c,0x0,0x0) PALO command line: 'HOME=/ TERM=LINUX root=/dev/nfs nfsroot=192.168.1.1 ' PALO initrd 0-0 model 00005890 00000481 00000000 00000002 778314c3 100000f0 00000004 0000008a 0000008a vers 0000000d cpuid 0000016d CPUID vers 11 rev 13 Searching for devices in PDC firmware... processor hpa 0xfffa0000 a newer box... Found devices: 1. UL 350 Lasi Core BA (11) at 0xffd00000, versions 0x2e, 0x0, 0x81, 0x0, 0x0 2. UL 350 Lasi Core RS-232 (10) at 0xffd05000, versions 0x2e, 0x0, 0x8c, 0x0, 0x0 3. UL 350 Core SCSI (10) at 0xffd06000, versions 0x2e, 0x0, 0x82, 0x0, 0x80 4. UL 350 Core LAN (802.3) (10) at 0xffd07000, versions 0x2e, 0x0, 0x8a, 0x0, 0x0 5. UL 350 Core Centronics (10) at 0xffd02000, versions 0x2e, 0x0, 0x74, 0x0, 0x0 6. UL 350 Core PC Keyboard (10) at 0xffd08000, versions 0x2e, 0x0, 0x84, 0x0, 0x0 7. UL 350 Core PC Keyboard (10) at 0xffd08100, versions 0x2e, 0x0, 0x84, 0x0, 0x0 8. UL 350 Core PC Floppy (10) at 0xffd0a000, versions 0x2e, 0x0, 0x83, 0x0, 0x0 9. UL 350 Core Wax BA (11) at 0xffe00000, versions 0x30, 0x0, 0x8e, 0x0, 0x0 10. UL 350 Wax EISA BA (11) at 0xfc000000, versions 0x30, 0x0, 0x90, 0x0, 0x0 11. UL 350 Wax Core RS-232 (10) at 0xffe02000, versions 0x30, 0x0, 0x8c, 0x0, 0x0 That's a total of 11 devices. No CPUs reported by firmware - probing... Found CPU at fffa0000 CPU(s): 1 x PA7200 (PCX-T') at 101.000000 MHz Linux version 2.4.0-test10 (root@gate.ixs.com) (gcc version 2.96 20000925 (experimental)) #4 Wed Nov 15 19:06:49 CET 2000 free_bootmem(0x2dd000, 0x7d23000) pagetable_init On node 0 totalpages: 32768 zone(0): 16384 pages. zone(1): 16384 pages. zone(2): 0 pages. Kernel command line: HOME=/ TERM=LINUX root=/dev/nfs nfsroot=192.168.1.1 trap_init Calibrating delay loop... 100.76 BogoMIPS Memory: 125568k available Dentry-cache hash table entries: 16384 (order: 5, 131072 bytes) Buffer-cache hash table entries: 8192 (order: 3, 32768 bytes) Page-cache hash table entries: 32768 (order: 5, 131072 bytes) Inode-cache hash table entries: 8192 (order: 4, 65536 bytes) POSIX conformance testing by UNIFIX Lasi version 0 at 0xffd00000 found. Wax at 0xffe00000 found. Wax: HIL Keyboard-NMI registered. parport0: PC-style at 0xffd02800, irq 88 [PCSPP,TRISTATE] Found i82596 at 0xffd07000, IRQ 87 early initialization of device eth0 is deferred Initializing Lasi PS/2-keyboard port at 0xffd08000... Support for Lasi PS/2-psaux not yet available ! Linux NET4.0 for Linux 2.4 Based upon Swansea University Computer Society NET3.039 Starting kswapd v1.8 pty: 256 Unix98 ptys configured lp0: using parport0 (interrupt-driven). Dumping Stack from c7f98000 to c7f989c0: 8000 00000000 00000040 00000000 00000000 c027c32c 00000000 00000000 ffffffff 8020 00000001 00000000 00000000 00000000 00000000 00000000 ffffffff c027c244 8040 c027c244 00000031 c7f90000 c02b0000 c028160c 00000000 00000000 00000000 8060 00000000 00000000 00000000 00000001 00000000 00000000 00000000 00000000 8080 00000000 c02b0000 c02b0000 c7f84000 00000000 00000000 c7f84098 c02b0098 80a0 00000000 c02cba18 00000000 c7f980ac c7f980ac c7f980b4 c01177f4 c7f98908 80c0 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 80e0 00000000 00000000 c7f98000 c011a5e4 00000000 0000000f 00000000 00000000 8100 00000024 00000000 00000033 00000000 00000000 00000000 00000000 00000000 8120 00000000 80000000 00000000 00000000 00000000 00000000 00000000 00000000 8140 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 8160 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 8180 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 81a0 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 81c0 00000000 00000000 00000000 fffffeff 00000000 ffffffff 00000000 c027ceb8 81e0 ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff 00800000 05000000 8200 00000000 ffffffff ffffffff ffffffff 00000800 00000800 00000400 00000400 8220 ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff 00007377 61707065 8240 72000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 8260 00008000 c0269000 c0269000 c013de10 00010000 c7ffeba0 c022248c c0234898 8280 000000f0 c02db000 00000000 c0118cf0 c0269054 00008000 c0269000 c0269054 82a0 f0000068 f0000070 c027c000 c027c368 0000000b 00000024 0000003c 0000003e 82c0 c027c000 00000000 c01001dc 00000004 00000000 00000023 c02b61ef 00000000 82e0 c027c000 f0000070 f0000068 000000ff ffd05800 ffd05800 ffd05800 00000060 8300 ffffffff ffd05800 002b50c0 c0268000 00000000 00000000 c02b08c0 00000000 8320 000b0800 00000000 0000001f 00000000 0000001f 00000000 0000001f 00000000 8340 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 8360 00000010 00000020 7f7fffff ffffffff 43ebebeb e0000000 00000000 00000000 8380 45e69c6a 25b7ea20 41800000 00000000 00000010 00000010 00000000 00000000 83a0 00000040 00000080 00000100 00000200 00000400 00000800 7fffffff 7fffffff 83c0 41000000 00000000 7fffffff 7fffffff 40800000 00000000 41000000 00000000 83e0 40300000 00000000 40200000 00000000 40200000 00000000 41800000 7fffffff 8400 40000000 00000000 40000000 00000000 40800000 00000000 41000000 00000000 8420 00000000 00000000 c7f98800 c0103cf4 00000000 00000000 00000000 00000000 8440 00000000 00000000 c0118ce0 c0118ce4 40800000 00000000 00282000 00000000 8460 c0281040 c0281064 00000000 c0281204 00000000 00000000 00000000 c7f98478 8480 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 84a0 00000000 00000000 71894dcb e3642ec4 c6c85d89 8d90bb13 1b217627 3634591c 84c0 6c1e076a d84abb86 b095770d 612aee1b c2236964 8446d2c9 088da593 116dfe74 84e0 22ad49ba 452c2626 8a2ef91e c0103c48 28cd5128 51ec1702 a3ae9b56 475d36ad 8500 c7f98000 c028160c 00000000 76fd1fb2 ed8c8a36 db19146d b63228db 6c6451b7 8520 d8be163c b17c2c79 62f858f3 c01001f0 8b0c0969 161812d3 2c4690f4 58fb94ba 8540 b1819c26 6303384d c670c5c8 8ce18b91 19c31723 33f09b14 6797837a cf59b3a6 8560 9eb3674d 3d66ce9b 7abb2864 c0294ef4 ea01cb35 d403966b a8072cd7 500e59af 8580 00000000 c02b0000 81dead60 03bd5ac1 00000060 c027c35c c027c35c c025920c 85a0 7234ad2e e41fef0e c83fde1d c0294ea0 20ff7877 418845bc 83663e2a 06cc7c55 85c0 c02ad30c c02ad2cc 00000000 00000000 00000000 c7f985d4 c7f985d4 c7f985dc 85e0 c7f985dc c7f985e4 00000000 c0298ca0 00000000 c7f985d4 c7f985d4 c7f985dc 8600 c027e800 00000000 00000000 00000000 000000fa 000000f2 000000ff c0295514 8620 000000f0 c02cb800 c02b06c0 c0299814 c028160c c02ad30c c02ad2bc c028160c 8640 c02b06c0 c7f98000 c028160c c02ad30c c02ad2d0 c7f94800 c0230add 0000003e 8660 c027c000 00000001 c02b6206 c0299744 c02b61ce 00000037 c02b6206 00000000 8680 c02ad30c c02ad2d0 00000040 c02cb800 000000fa 000000f2 000000ff c0295514 86a0 000000f0 c02cb800 c02b06c0 c02a4af4 c028160c c02ad30c c02ad2d0 c7f98000 86c0 c028b800 c01e2468 ffffffff c028b1e4 c7ffc400 c028160c c024256c c0186688 86e0 c028160c c02c6104 c01e2468 c029c4e0 c028b310 c028b1b4 c7f988c0 00000000 8700 ffffffff 0000ffe0 0060b03c 08d4bcfc 00000000 00000008 c0295514 000000f0 8720 c02cb800 c028b800 c01e2468 ffffffff c028b1e4 c7ffc400 c02bfc1c c02bfe50 8740 00000063 00000008 c7f98718 c024256c 00000000 c0285038 c028b1b9 c0242340 8760 45e69c6a 25b7ea20 41800000 c029c248 00000010 00000010 00000000 00000000 8780 0004000b c02ca800 c029c248 00000000 c7ffc400 ffffffff c01e2468 c028b800 87a0 c02cb800 000000f0 00000000 000000ff 000000f2 000000fa 000000fd f0100000 87c0 f0001180 f0000070 f0000068 00000000 c7f9870e 00000002 c029c4d0 ffd07000 87e0 c7f98710 00000f20 00000000 c0268000 00000001 00000000 c7f989c0 002b31b8 8800 000b0800 00000000 0000001f 00000000 0000001f 00000000 0000001f 00000000 8820 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 8840 00000010 00000020 7f7fffff ffffffff 43ebebeb e0000000 00000000 00000000 8860 45e69c6a 25b7ea20 41800000 00000000 00000010 00000010 00000000 00000000 8880 00000040 00000080 00000100 00000200 00000400 00000800 7fffffff 7fffffff 88a0 41000000 00000000 7fffffff 7fffffff 40800000 00000000 41000000 00000000 88c0 40300000 00000000 40200000 00000000 40200000 00000000 41800000 7fffffff 88e0 40000000 00000000 40000000 00000000 40800000 00000000 41000000 00000000 8900 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 8920 00000000 00000000 c029c264 c029c268 00000000 00000000 c7f98b00 00000000 8940 00000000 00000000 0000001f 00000000 0000001f 0e681096 00000000 00000004 8960 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 8980 00000010 00000020 7f7fffff ffffffff 43ebebeb e0000000 00000000 00000000 89a0 45e69c6a 25b7ea20 41800000 c01046e0 00000010 00000010 00000000 00000000 Data access rights fault in kernel: Code=26 regs=c7f98780 (Addr=00000004) YZrvWESTHLNXBCVMcbcbcbcbOGFRQPDI PSW: 00000000000001000000000000001011 r0-3 00000000 c02ca800 c029c248 00000000 r4-7 c7ffc400 ffffffff c01e2468 c028b800 r8-11 c02cb800 000000f0 00000000 000000ff r12-15 000000f2 000000fa 000000fd f0100000 r16-19 f0001180 f0000070 f0000068 00000000 r20-23 c7f9870e 00000002 c029c4d0 ffd07000 r24-27 c7f98710 00000f20 00000000 c0268000 r28-31 00000001 00000000 c7f989c0 002b31b8 sr0-4 00000000 00000000 00000000 00000000 sr4-8 00000000 00000000 00000000 00000000 IASQ: 00000000 00000000 IAOQ: c029c264 c029c268 IIR: 0e681096 ISR: 00000000 IOR: 00000004 ORIG_R28: 00000000 --------------F7EF1B69F0A7C4C7DD54E27D-- From ixs@ixs.bb.bawue.de Wed, 15 Nov 2000 20:28:28 +0100 (CET) Date: Wed, 15 Nov 2000 20:28:28 +0100 (CET) From: Andreas Thienemann ixs@ixs.bb.bawue.de Subject: [parisc-linux] 250/1 doesn't boot but dumps stack Hi again, just to clear something up: On Thu, 16 Nov 2000, Andreas Thienemann wrote: > the pty interfaces. (I already left out everything unnecessary, such as > parallel port support) I just noticed I attached the wrong file. The attached bootlog was from a kernel that still had support for lp0. But with another kernel, this time without lp support, this errors were the same... bye, Andreas From kailasr@webcash.com Wed, 15 Nov 2000 11:26:30 -0800 Date: Wed, 15 Nov 2000 11:26:30 -0800 From: Kailashnath V Rampure kailasr@webcash.com Subject: [parisc-linux] Boot command Thomas, I mounted the /dev/sda3 on mnt and deleted every thing and recopied then rebooted. It worked. Probably there was some fault while I copied yesterday. I did not repartition the disk now. Thanks Regards Kailas At 07:10 PM 11/15/00 +0100, Thomas Marteau wrote: >Hi again, > > You put the swap partition before the f0 partition and here it is the f0 >partition in first position. > Also, your hard disk is ida instead of sda, what's that ? > >Bye, > >ESIEE Team >----- Original Message ----- >From: Kailashnath V Rampure >To: Thomas Marteau >Cc: >Sent: Wednesday, November 15, 2000 6:55 PM >Subject: Re: [parisc-linux] Boot command > > > > Yes Thomas the vmlinux is in /boot of 3rd partition as the other >partitions > > are swap and f0. > > > > At 11:48 AM 11/15/00 +0100, Thomas Marteau wrote: > > > > >----- Original Message ----- > > >From: Kailashnath V Rampure > > >To: Paul Bame > > >Cc: Grant Grundler ; Matt Taggart > > >; > > >Sent: Tuesday, November 14, 2000 11:58 PM > > >Subject: Re: [parisc-linux] Boot command > > > > > > > > > > I have booted HP A class server through network. On that I have > > >repartioned > > > > the system and followed the steps on > > >http://www.parisc-linux.org/install.html. > > > > I have used the following command to initialize the hard disk. The >kernel > > >I > > > > have downloaded is vmlinux-20001018. and cpied it to /mnt/boot/vmlinux > > > > after mounting /dev/sda3. I have used the following command to >initialize > > > > the HDD. > > > > > > > > palo -I -k /boot/vmlinux -b /boot/iplboot \ -c '3/boot/vmlinux >TERM=linux > > > > HOME=/ root=/dev/sda3' \ /dev/sda > > > > > >This means that vmlinux must be in /boot in your third partition on your > > >disk. > > >Is it true in your case? > > > > > > > -------------------------------- > > > > I get the following error: > > > > -------------------------------- > > > > SOFT Boot. > > > > palo ipl bame@noam Tue oct 31 14:18:02 MST 2000 > > > > 0/vmlinux 2138614 bytes@ 0x1f78c000 > > > > 0/palo-cmdline '3/boot/vmlinux TERM=linux HOME=/ root=/dev/sda3' > > > > /dev/ida1 82 62 1030688 > > > > /dev/ida2 f0 1030750 24738 > > > > /dev/ida3 83 1055488 1030750 > > > > Kernel:partition 3 file /boot/vmlinux > > > > ext2 block size 1024 > > > > ext2_mount(partition 3) returns 0 > > > > ext2_open(/boot/vmlinux) = -1 > > > > open /boot/vmlinux failed From bame@noam.fc.hp.com Wed, 15 Nov 2000 12:34:48 -0700 Date: Wed, 15 Nov 2000 12:34:48 -0700 From: Paul Bame bame@noam.fc.hp.com Subject: [parisc-linux] Help with posix_types.h FYI I just heard some pretty good reasons why both ino_t and off_t should be 64 bits even on 32-bit kernels. Keep those cards and letters coming! -P From grundler@cup.hp.com Wed, 15 Nov 2000 11:23:41 -0800 Date: Wed, 15 Nov 2000 11:23:41 -0800 From: Grant Grundler grundler@cup.hp.com Subject: [parisc-linux] 250/1 doesn't boot but dumps stack Andreas Thienemann wrote: > But when I try to boot up this kernel it dumps stack right after initialising > the pty interfaces. (I already left out everything unnecessary, such as > parallel port support) ... > parport0: PC-style at 0xffd02800, irq 88 [PCSPP,TRISTATE] > Found i82596 at 0xffd07000, IRQ 87 > early initialization of device eth0 is deferred > Initializing Lasi PS/2-keyboard port at 0xffd08000... > Support for Lasi PS/2-psaux not yet available ! > Linux NET4.0 for Linux 2.4 > Based upon Swansea University Computer Society NET3.039 > Starting kswapd v1.8 > pty: 256 Unix98 ptys configured > lp0: using parport0 (interrupt-driven). Are you sure you left out parallel port support? > Data access rights fault in kernel: Code=26 regs=c7f98780 (Addr=00000004) > > YZrvWESTHLNXBCVMcbcbcbcbOGFRQPDI > PSW: 00000000000001000000000000001011 > r0-3 00000000 c02ca800 c029c248 00000000 > r4-7 c7ffc400 ffffffff c01e2468 c028b800 > r8-11 c02cb800 000000f0 00000000 000000ff > r12-15 000000f2 000000fa 000000fd f0100000 > r16-19 f0001180 f0000070 f0000068 00000000 > r20-23 c7f9870e 00000002 c029c4d0 ffd07000 > r24-27 c7f98710 00000f20 00000000 c0268000 > r28-31 00000001 00000000 c7f989c0 002b31b8 > sr0-4 00000000 00000000 00000000 00000000 > sr4-8 00000000 00000000 00000000 00000000 > > IASQ: 00000000 00000000 IAOQ: c029c264 c029c268 > IIR: 0e681096 ISR: 00000000 IOR: 00000004 > ORIG_R28: 00000000 Smells like a driver bug. Can you look up IOAQ and GR2 (c029c264 and c029c248) in System.map file? grant From dave@hiauly1.hia.nrc.ca Wed, 15 Nov 2000 14:49:02 -0500 (EST) Date: Wed, 15 Nov 2000 14:49:02 -0500 (EST) From: John David Anglin dave@hiauly1.hia.nrc.ca Subject: [parisc-linux] Single-stepping > I've been helping Alan Modra out with kernel changes to support > single stepping for gdb. Paul Bame suggested I bounced our ideas > off you in case you (or anyone else) had any comments. I havn't > actually committed my changes yet. > > The basic approach is to use the recovery counter to generate > a trap every instruction. The scheme is complicated because a > suspended process may or may not return to user space via an RFI. I really don't know enough to comment on the implementation choice. Why did you decide on this approach as opposed to inserting breaks and enabling the taken branch branch trap (T)? It would appear that the recovery counter was intended to provide software recovery from hardware faults in fault tolerant systems. Possibly, Grant could comment on whether it is actually useful for this purpose. Dave -- J. David Anglin dave.anglin@nrc.ca National Research Council of Canada (613) 990-0752 (FAX: 952-6605) From j-perdue@tamu.edu Wed, 15 Nov 2000 13:53:03 -0600 Date: Wed, 15 Nov 2000 13:53:03 -0600 From: Jack Perdue j-perdue@tamu.edu Subject: [parisc-linux] nfsroot - 712/60 - RPC - help Howdy Puffins and others, I have a 712/60 here that I bought for the purpose of playing with PARISC linux. It came w/HP-UX 9.0 which I don't want to wax just yet (e.g. for ioscan and other HP-UX utils). I don't have a CD for it, so I've been trying to get NFSROOT to work. The 712/60 is known as pancho. The bootp server is named blacktower. I've unzipped nfsroot-20000804.tgz as /tftpboot/pancho and exported it to the local net. I can mount it from an i386 RH6.2 box, but I think I'm having problems accessing it from PA-RISC linux. Below are some of my config files, the output from bootp and two attempts at booting the 712/60... one with debugging turned on in net/sunrpc/sysctl.c. I'm kinda stumped. Can anyone see where I've gone wrong? Some notes: a) I've tried NFSROOT=192.168.1.11 and NFSROOT=192.168.1.11/tftpboot/vmlinux in palo/Makefile and the results are the same (both suggestions were made to this list at some point) b) I tried the APRICOT drivers, but the kernel would never see the net interface so I've switched to the LASI_82596 driver (doing both resulted in dupe symbols). The LASI driver seems to get much further. c) my sources were updated today from the puffin's CVS tree. The kernel booting below was built on those sources. d) with debugging on, I get: Root-NFS: Unable to get nfsd port number from server, using default Root-NFS: Portmapper on server returned 2049 as nfsd port however, with the debugging off, I only get: Root-NFS: Unable to get nfsd port number from server, using default portmap and rpc.mountd are running on blacktower. Why the conflicting report when debug is on? e) the final message in /var/log/messages is always "tftpd: read: Connection refused". My hosts.allow and hosts.deny files are empty so they shouldn't be the problem. And, as mentioned I can NFS mount the directory. Is this the problem and if so, what is the solution??? Any help on how I can resolve this problem is appreciated. TIA, jack j-perdue@tamu.edu ========== blacktower:/etc/exports ========== /tftpboot/pancho 192.168.1.0/255.255.255.0(rw,no_root_squash) ========== blacktower:/etc/bootptab ========== pancho:\ :hd=/tftpboot:\ :bf=vmlinux:\ :ht=ether:\ :ha=08000993DA02:\ :sm=255.255.255.0:\ :hn:\ :ip=192.168.1.13:\ :vm=rfc1048: ========== bootpd output ========== [root@blacktower rc.d]# /usr/sbin/bootpd -d 20 bootpd: info(6): bootptab mtime: Wed Nov 15 13:02:44 2000 bootpd: info(6): reading "/etc/bootptab" bootpd: info(6): read 1 entries (1 hosts) from "/etc/bootptab" bootpd: info(6): recvd pkt from IP addr 0.0.0.0 bootpd: info(6): bootptab mtime: Wed Nov 15 13:02:44 2000 bootpd: info(6): request from Ethernet address 08:00:09:93:DA:02 bootpd: info(6): found 192.168.1.13 (pancho) bootpd: info(6): bootfile="/tftpboot/vmlinux" bootpd: info(6): vendor magic field is 99.130.83.99 bootpd: info(6): sending reply (with RFC1048 options) bootpd: info(6): setarp 192.168.1.13 - 08:00:09:93:DA:02 bootpd: info(6): recvd pkt from IP addr 0.0.0.0 bootpd: info(6): bootptab mtime: Wed Nov 15 13:02:44 2000 bootpd: info(6): request from Ethernet address 08:00:09:93:DA:02 bootpd: info(6): found 192.168.1.13 (pancho) bootpd: info(6): bootfile="/tftpboot/vmlinux" bootpd: info(6): vendor magic field is 99.130.83.99 bootpd: info(6): request message length=364 bootpd: info(6): extended reply, length=364, options=128 bootpd: info(6): sending reply (with RFC1048 options) bootpd: info(6): setarp 192.168.1.13 - 08:00:09:93:DA:02 ========== from /var/log/messages ========== Nov 15 13:02:20 blacktower bootpd[1320]: version 2.4.3 Nov 15 13:02:20 blacktower bootpd[1320]: bootptab mtime: Wed Oct 12 00:41:28 1994 Nov 15 13:02:20 blacktower bootpd[1320]: reading "/etc/bootptab" Nov 15 13:02:20 blacktower bootpd[1320]: read 1 entries (1 hosts) from "/etc/bootptab" Nov 15 13:02:47 blacktower bootpd[1323]: version 2.4.3 Nov 15 13:02:47 blacktower bootpd[1323]: bootptab mtime: Wed Nov 15 13:02:44 2000 Nov 15 13:02:47 blacktower bootpd[1323]: reading "/etc/bootptab" Nov 15 13:02:47 blacktower bootpd[1323]: read 1 entries (1 hosts) from "/etc/bootptab" Nov 15 13:04:34 blacktower bootpd[1323]: recvd pkt from IP addr 0.0.0.0 Nov 15 13:04:34 blacktower bootpd[1323]: bootptab mtime: Wed Nov 15 13:02:44 2000 Nov 15 13:04:34 blacktower bootpd[1323]: request from Ethernet address 08:00:09:93:DA:02 Nov 15 13:04:34 blacktower bootpd[1323]: found 192.168.1.13 (pancho) Nov 15 13:04:34 blacktower bootpd[1323]: bootfile="/tftpboot/vmlinux" Nov 15 13:04:34 blacktower bootpd[1323]: vendor magic field is 99.130.83.99 Nov 15 13:04:34 blacktower bootpd[1323]: sending reply (with RFC1048 options) Nov 15 13:04:34 blacktower bootpd[1323]: setarp 192.168.1.13 - 08:00:09:93:DA:02 Nov 15 13:04:35 blacktower tftpd[1325]: tftpd: trying to get file: /tftpboot/vmlinux Nov 15 13:04:36 blacktower tftpd[1327]: tftpd: trying to get file: /tftpboot/vmlinux Nov 15 13:04:47 blacktower bootpd[1323]: recvd pkt from IP addr 0.0.0.0 Nov 15 13:04:47 blacktower bootpd[1323]: bootptab mtime: Wed Nov 15 13:02:44 2000 Nov 15 13:04:47 blacktower bootpd[1323]: request from Ethernet address 08:00:09:93:DA:02 Nov 15 13:04:47 blacktower bootpd[1323]: found 192.168.1.13 (pancho) Nov 15 13:04:47 blacktower bootpd[1323]: bootfile="/tftpboot/vmlinux" Nov 15 13:04:47 blacktower bootpd[1323]: vendor magic field is 99.130.83.99 Nov 15 13:04:47 blacktower bootpd[1323]: request message length=364 Nov 15 13:04:47 blacktower bootpd[1323]: extended reply, length=364, options=128 Nov 15 13:04:47 blacktower bootpd[1323]: sending reply (with RFC1048 options) Nov 15 13:04:47 blacktower bootpd[1323]: setarp 192.168.1.13 - 08:00:09:93:DA:02 Nov 15 13:04:53 blacktower tftpd[1327]: tftpd: read: Connection refused ========== console output (no RPC debug) ========== ---------------------------------------------------------------------------- BootRom Version 1.5 Memory Size: 32 MB ---------------------------------------------------------------------------- (c) Copyright 1990-1993, Hewlett-Packard Company. All rights reserved Press to stop boot sequence. Selecting a system to boot. Booting palo ipl jkp2866@redtower Wed Nov 15 12:44:21 CST 2000 0/vmlinux 1606438 bytes @ 0x6800 0/palo-cmdline '0/vmlinux HOME=/ TERM=LINUX root=/dev/nfs nfsroot=192.68.1.11:/tftpboot/pancho ' Kernel: partition 0 file /vmlinux ELF32 executable Entry 00100000 first 00100000 n 4 Segment 0 load 00100000 size 1097900 mediaptr 0x1000 Segment 1 load 0020e000 size 150520 mediaptr 0x10e000 Segment 2 load 00234000 size 55900 mediaptr 0x133000 Segment 3 load 00244000 size 8192 mediaptr 0x141000 branching to kernel entry point 0x00100000 Set default PSW W bit to 0 PDC Console Initialized The 32-bit Kernel has started... Enabled FP coprocessor Free memory starts at: 0xc026e000 start_parisc(0x504d6c,0x504d6c,0x0,0x0) PALO command line: 'HOME=/ TERM=LINUX root=/dev/nfs nfsroot=192.68.1.11:/tftpboot/pancho ' PALO initrd 0-0 model 00006000 00000481 00000000 00000000 77564139 00000000 00000004 00000072 00000072 vers 0000000a CPUID vers 0 rev 0 Searching for devices in PDC firmware... processor hpa 0xfffbe000 an older box... Found devices: 1. Gecko GSC Core Graphics (10) at 0xf8000000, versions 0x16, 0x0, 0x85, 0x0, 0x0 2. Gecko Core BA (11) at 0xf0100000, versions 0x16, 0x0, 0x81, 0x0, 0x0 3. Gecko Core SCSI (10) at 0xf0106000, versions 0x16, 0x0, 0x82, 0x0, 0x0 4. Gecko Core Lan (802.3) (10) at 0xf0107000, versions 0x16, 0x0, 0x8a, 0x0, 0x0 5. Gecko Core RS-232 (10) at 0xf0105000, versions 0x16, 0x0, 0x8c, 0x0, 0x0 6. Gecko Core Centronics (10) at 0xf0102000, versions 0x16, 0x0, 0x74, 0x0, 0x0 7. Gecko Audio (10) at 0xf0104000, versions 0x16, 0x0, 0x7b, 0x0, 0x0 8. Gecko Core PC Floppy (10) at 0xf010a000, versions 0x16, 0x0, 0x83, 0x0, 0x0 9. Gecko Core PC Keyboard (10) at 0xf0108000, versions 0x16, 0x0, 0x84, 0x0, 0x0 10. Gecko Core PC Keyboard (10) at 0xf0108100, versions 0x16, 0x0, 0x84, 0x0, 0x0 11. Gecko (712/60) (0) at 0xfffbe000, versions 0x600, 0x0, 0x4, 0x0, 0x81 12. Gecko (1) at 0xfffbf000, versions 0x26, 0x0, 0x9, 0x0, 0x0 That's a total of 12 devices. CPU(s): 1 x PA7100LC (PCX-L) at 60.000000 MHz Linux version 2.4.0-test10 (jkp2866@redtower) (gcc version 2.96 20000925 (experimental)) #16 Wed Nov 15 14:01:38 CST 2000 free_bootmem(0x26e400, 0x1d91c00) pagetable_init On node 0 totalpages: 8192 zone(0): 4096 pages. zone(1): 4096 pages. zone(2): 0 pages. Kernel command line: HOME=/ TERM=LINUX root=/dev/nfs nfsroot=192.68.1.11:/tftpboot/pancho trap_init Calibrating delay loop... 59.80 BogoMIPS Memory: 29632k available Dentry-cache hash table entries: 4096 (order: 3, 32768 bytes) Buffer-cache hash table entries: 1024 (order: 0, 4096 bytes) Page-cache hash table entries: 8192 (order: 3, 32768 bytes) Inode-cache hash table entries: 2048 (order: 2, 16384 bytes) POSIX conformance testing by UNIFIX Lasi version 0 at 0xf0100000 found. Found i82596 at 0xf0107000, IRQ 87 early initialization of device eth0 is deferred Linux NET4.0 for Linux 2.4 Based upon Swansea University Computer Society NET3.039 Starting kswapd v1.8 pty: 256 Unix98 ptys configured eth0: 82596 at 0xf0107000, 08 00 09 93 DA 02 IRQ 87. 82596.c $Revision: 1.14 $ Serial driver version 5.02 (2000-08-09) with MANY_PORTS SHARE_IRQ SERIAL_PCI enabled ttyS00 at iomem 0xf0105800 (irq = 90) is a 16550A NET4: Linux TCP/IP 1.0 for NET4.0 IP Protocols: ICMP, UDP, TCP IP: routing cache hash table of 512 buckets, 4Kbytes TCP: Hash tables configured (established 2048 bind 2048) eth0: link ok. Sending BOOTP requests.... OK IP-Config: Got BOOTP answer from 192.168.1.11, my address is 192.168.1.13 Switching from PDC console kmem_create: Forcing size word alignment - nfs_fh Looking up port of RPC 100003/2 on 192.68.1.11 RPC: sendmsg returned error 229 portmap: RPC call returned error 229 Root-NFS: Unable to get nfsd port number from server, using default Looking up port of RPC 100005/2 on 192.68.1.11 RPC: sendmsg returned error 229 portmap: RPC call returned error 229 Root-NFS: Unable to get mountd port number from server, using default RPC: sendmsg returned error 229 mount: RPC call returned error 229 Root-NFS: Server returned error -229 while mounting /tftpboot/pancho VFS: Unable to mount root fs via NFS, trying floppy. VFS: Cannot open root device "nfs" or 02:00 Please append a correct "root=" boot option Kernel panic: VFS: Unable to mount root fs on 02:00 ========== console output (with RPC debug) ========== ---------------------------------------------------------------------------- BootRom Version 1.5 Memory Size: 32 MB ---------------------------------------------------------------------------- (c) Copyright 1990-1993, Hewlett-Packard Company. All rights reserved Press to stop boot sequence. Selecting a system to boot. Booting palo ipl jkp2866@redtower Wed Nov 15 12:44:21 CST 2000 0/vmlinux 1606438 bytes @ 0x6800 0/palo-cmdline '0/vmlinux HOME=/ TERM=LINUX root=/dev/nfs nfsroot=192.68.1.11:/tftpboot/pancho ' Kernel: partition 0 file /vmlinux ELF32 executable Entry 00100000 first 00100000 n 4 Segment 0 load 00100000 size 1097900 mediaptr 0x1000 Segment 1 load 0020e000 size 150520 mediaptr 0x10e000 Segment 2 load 00234000 size 55900 mediaptr 0x133000 Segment 3 load 00244000 size 8192 mediaptr 0x141000 branching to kernel entry point 0x00100000 Set default PSW W bit to 0 PDC Console Initialized The 32-bit Kernel has started... Enabled FP coprocessor Free memory starts at: 0xc026e000 start_parisc(0x504d6c,0x504d6c,0x0,0x0) PALO command line: 'HOME=/ TERM=LINUX root=/dev/nfs nfsroot=192.68.1.11:/tftpboot/pancho ' PALO initrd 0-0 model 00006000 00000481 00000000 00000000 77564139 00000000 00000004 00000072 00000072 vers 0000000a CPUID vers 0 rev 0 Searching for devices in PDC firmware... processor hpa 0xfffbe000 an older box... Found devices: 1. Gecko GSC Core Graphics (10) at 0xf8000000, versions 0x16, 0x0, 0x85, 0x0, 0x0 2. Gecko Core BA (11) at 0xf0100000, versions 0x16, 0x0, 0x81, 0x0, 0x0 3. Gecko Core SCSI (10) at 0xf0106000, versions 0x16, 0x0, 0x82, 0x0, 0x0 4. Gecko Core Lan (802.3) (10) at 0xf0107000, versions 0x16, 0x0, 0x8a, 0x0, 0x0 5. Gecko Core RS-232 (10) at 0xf0105000, versions 0x16, 0x0, 0x8c, 0x0, 0x0 6. Gecko Core Centronics (10) at 0xf0102000, versions 0x16, 0x0, 0x74, 0x0, 0x0 7. Gecko Audio (10) at 0xf0104000, versions 0x16, 0x0, 0x7b, 0x0, 0x0 8. Gecko Core PC Floppy (10) at 0xf010a000, versions 0x16, 0x0, 0x83, 0x0, 0x0 9. Gecko Core PC Keyboard (10) at 0xf0108000, versions 0x16, 0x0, 0x84, 0x0, 0x0 10. Gecko Core PC Keyboard (10) at 0xf0108100, versions 0x16, 0x0, 0x84, 0x0, 0x0 11. Gecko (712/60) (0) at 0xfffbe000, versions 0x600, 0x0, 0x4, 0x0, 0x81 12. Gecko (1) at 0xfffbf000, versions 0x26, 0x0, 0x9, 0x0, 0x0 That's a total of 12 devices. CPU(s): 1 x PA7100LC (PCX-L) at 60.000000 MHz Linux version 2.4.0-test10 (jkp2866@redtower) (gcc version 2.96 20000925 (experimental)) #15 Wed Nov 15 13:48:41 CST 2000 free_bootmem(0x26e400, 0x1d91c00) pagetable_init On node 0 totalpages: 8192 zone(0): 4096 pages. zone(1): 4096 pages. zone(2): 0 pages. Kernel command line: HOME=/ TERM=LINUX root=/dev/nfs nfsroot=192.68.1.11:/tftpboot/pancho trap_init Calibrating delay loop... 59.80 BogoMIPS Memory: 29632k available Dentry-cache hash table entries: 4096 (order: 3, 32768 bytes) Buffer-cache hash table entries: 1024 (order: 0, 4096 bytes) Page-cache hash table entries: 8192 (order: 3, 32768 bytes) Inode-cache hash table entries: 2048 (order: 2, 16384 bytes) POSIX conformance testing by UNIFIX Lasi version 0 at 0xf0100000 found. Found i82596 at 0xf0107000, IRQ 87 early initialization of device eth0 is deferred Linux NET4.0 for Linux 2.4 Based upon Swansea University Computer Society NET3.039 Starting kswapd v1.8 pty: 256 Unix98 ptys configured eth0: 82596 at 0xf0107000, 08 00 09 93 DA 02 IRQ 87. 82596.c $Revision: 1.14 $ Serial driver version 5.02 (2000-08-09) with MANY_PORTS SHARE_IRQ SERIAL_PCI enabled ttyS00 at iomem 0xf0105800 (irq = 90) is a 16550A NET4: Linux TCP/IP 1.0 for NET4.0 IP Protocols: ICMP, UDP, TCP IP: routing cache hash table of 512 buckets, 4Kbytes TCP: Hash tables configured (established 2048 bind 2048) eth0: link ok. Sending BOOTP requests.... OK IP-Config: Got BOOTP answer from 192.168.1.11, my address is 192.168.1.13 Switching from PDC console kmem_create: Forcing size word alignment - nfs_fh RPC: registering /proc/net/rpc RPC: registering /proc/net/rpc/nfs Looking up port of RPC 100003/2 on 192.68.1.11 RPC: rpc_getport_external(192.68.1.11, 100003, 2, 17) RPC: xprt_create_proto called RPC: xprt_create_socket(udp 17) RPC: setting up UDP transport... RPC: created transport c1fa4000 RPC: creating portmap client for 192.68.1.11 (xprt c1fa4000) RPC: allocated buffer c1faa5a0 RPC: creating NULL authenticator for client c1faa5a0 RPC: allocated buffer c1fe6460 RPC: 0 new task procpid 1 RPC: 0 looking up NULL cred RPC: allocated buffer c1fe5500 RPC: 0 rpc_execute flgs 0 RPC: 0 call_reserve RPC: 0 xprt_reserve cong = 0 cwnd = 256 RPC: 0 reserved req c1fa4064 xid 11582000 RPC: 0 xprt_reserve returns 0 RPC: 0 call_reserveresult (status 0) RPC: 0 call_allocate (status 0) RPC: allocated buffer c1fb3800 RPC: 0 call_encode (status 0) RPC: 0 marshaling NULL cred c1fe5500 RPC: xdr_encode_mapping(100003, 2, 17, 0) RPC: 0 call_transmit (status 0) RPC: 0 xprt_transmit(11582000) RPC: 0 xprt_receive RPC: 0 sleep_on(queue "xprt_pending" time 89) RPC: 0 added to queue c1fa4048 "xprt_pending" RPC: xprt_sendmsg(56) = -229 RPC: sendmsg returned error 229 RPC: 0 __rpc_wake_up_task (now 93 inh 0) RPC: 0 disabling timer RPC: 0 removed from queue c1fa4048 "xprt_pending" RPC: __rpc_wake_up_task done RPC: wake_up_next(c1fa4040 "xprt_sending") RPC: 0 call_status (status -229) portmap: RPC call returned error 229 RPC: 0 exit() = -229 RPC: 0 release task RPC: 0 disabling timer RPC: 0 release request c1fa4064 RPC: wake_up_next(c1fa4050 "xprt_backlog") RPC: 0 releasing NULL cred c1fe5500 RPC: rpc_release_client(c1faa5a0, 1) RPC: destroying portmap client for 192.68.1.11 RPC: destroying NULL authenticator c1fe6460 RPC: destroying transport c1fa4000 RPC: disconnected transport c1fa4000 Root-NFS: Unable to get nfsd port number from server, using default Root-NFS: Portmapper on server returned 2049 as nfsd port Looking up port of RPC 100005/2 on 192.68.1.11 RPC: rpc_getport_external(192.68.1.11, 100005, 2, 17) RPC: xprt_create_proto called RPC: xprt_create_socket(udp 17) RPC: setting up UDP transport... RPC: created transport c1fa4000 RPC: creating portmap client for 192.68.1.11 (xprt c1fa4000) RPC: allocated buffer c1faa5a0 RPC: creating NULL authenticator for client c1faa5a0 RPC: allocated buffer c1fe6460 RPC: 1 new task procpid 1 RPC: 1 looking up NULL cred RPC: allocated buffer c1fe5500 RPC: 1 rpc_execute flgs 0 RPC: 1 call_reserve RPC: 1 xprt_reserve cong = 0 cwnd = 256 RPC: 1 reserved req c1fa4064 xid 11582001 RPC: 1 xprt_reserve returns 0 RPC: 1 call_reserveresult (status 0) RPC: 1 call_allocate (status 0) RPC: allocated buffer c1fb3800 RPC: 1 call_encode (status 0) RPC: 1 marshaling NULL cred c1fe5500 RPC: xdr_encode_mapping(100005, 2, 17, 0) RPC: 1 call_transmit (status 0) RPC: 1 xprt_transmit(11582001) RPC: 1 xprt_receive RPC: 1 sleep_on(queue "xprt_pending" time 140) RPC: 1 added to queue c1fa4048 "xprt_pending" RPC: xprt_sendmsg(56) = -229 RPC: sendmsg returned error 229 RPC: 1 __rpc_wake_up_task (now 144 inh 0) RPC: 1 disabling timer RPC: 1 removed from queue c1fa4048 "xprt_pending" RPC: __rpc_wake_up_task done RPC: wake_up_next(c1fa4040 "xprt_sending") RPC: 1 call_status (status -229) portmap: RPC call returned error 229 RPC: 1 exit() = -229 RPC: 1 release task RPC: 1 disabling timer RPC: 1 release request c1fa4064 RPC: wake_up_next(c1fa4050 "xprt_backlog") RPC: 1 releasing NULL cred c1fe5500 RPC: rpc_release_client(c1faa5a0, 1) RPC: destroying portmap client for 192.68.1.11 RPC: destroying NULL authenticator c1fe6460 RPC: destroying transport c1fa4000 RPC: disconnected transport c1fa4000 Root-NFS: Unable to get mountd port number from server, using default Root-NFS: mountd port is 627 NFS: nfs_mount(c044010b:/tftpboot/pancho) RPC: xprt_create_proto called RPC: xprt_create_socket(udp 17) RPC: setting up UDP transport... RPC: created transport c1fa4000 RPC: creating mount client for 192.68.1.11 (xprt c1fa4000) RPC: allocated buffer c1faa5a0 RPC: creating NULL authenticator for client c1faa5a0 RPC: allocated buffer c1fe6460 RPC: 2 new task procpid 1 RPC: 2 looking up NULL cred RPC: allocated buffer c1fe5500 RPC: 2 rpc_execute flgs 0 RPC: 2 call_reserve RPC: 2 xprt_reserve cong = 0 cwnd = 256 RPC: 2 reserved req c1fa4064 xid 11582002 RPC: 2 xprt_reserve returns 0 RPC: 2 call_reserveresult (status 0) RPC: 2 call_allocate (status 0) RPC: allocated buffer c1fa3000 RPC: 2 call_encode (status 0) RPC: 2 marshaling NULL cred c1fe5500 RPC: 2 call_transmit (status 0) RPC: 2 xprt_transmit(11582002) RPC: 2 xprt_receive RPC: 2 sleep_on(queue "xprt_pending" time 189) RPC: 2 added to queue c1fa4048 "xprt_pending" RPC: xprt_sendmsg(60) = -229 RPC: sendmsg returned error 229 RPC: 2 __rpc_wake_up_task (now 193 inh 0) RPC: 2 disabling timer RPC: 2 removed from queue c1fa4048 "xprt_pending" RPC: __rpc_wake_up_task done RPC: wake_up_next(c1fa4040 "xprt_sending") RPC: 2 call_status (status -229) mount: RPC call returned error 229 RPC: 2 exit() = -229 RPC: 2 release task RPC: 2 disabling timer RPC: 2 release request c1fa4064 RPC: wake_up_next(c1fa4050 "xprt_backlog") RPC: 2 releasing NULL cred c1fe5500 RPC: rpc_release_client(c1faa5a0, 1) RPC: destroying mount client for 192.68.1.11 RPC: destroying NULL authenticator c1fe6460 RPC: destroying transport c1fa4000 RPC: disconnected transport c1fa4000 Root-NFS: Server returned error -229 while mounting /tftpboot/pancho VFS: Unable to mount root fs via NFS, trying floppy. VFS: Cannot open root device "nfs" or 02:00 Please append a correct "root=" boot option Kernel panic: VFS: Unable to mount root fs on 02:00 ========== linux/.config ========== # # Automatically generated make config: don't edit # CONFIG_PARISC=y # CONFIG_UID16 is not set # # Code maturity level options # CONFIG_EXPERIMENTAL=y # # General options # # CONFIG_SMP is not set # CONFIG_KWDB is not set CONFIG_GSC=y # CONFIG_IOMMU_CCIO is not set CONFIG_GSC_LASI=y CONFIG_PCI=y CONFIG_GSC_DINO=y # CONFIG_PCI_LBA is not set # # Loadable module support # # CONFIG_MODULES is not set # # General setup # CONFIG_NET=y CONFIG_SYSVIPC=y # CONFIG_BSD_PROCESS_ACCT is not set CONFIG_SYSCTL=y CONFIG_BINFMT_SOM=y # CONFIG_BINFMT_ELF is not set # CONFIG_BINFMT_MISC is not set # CONFIG_BINFMT_JAVA is not set # # Parallel port support # # CONFIG_PARPORT is not set # # Block devices # # CONFIG_BLK_DEV_FD is not set # CONFIG_BLK_DEV_XD is not set # CONFIG_PARIDE is not set # CONFIG_BLK_CPQ_DA is not set # CONFIG_BLK_CPQ_CISS_DA is not set # CONFIG_BLK_DEV_DAC960 is not set # CONFIG_BLK_DEV_LOOP is not set # CONFIG_BLK_DEV_NBD is not set # CONFIG_BLK_DEV_RAM is not set # CONFIG_BLK_DEV_INITRD is not set # # Networking options # # CONFIG_PACKET is not set # CONFIG_NETLINK is not set # CONFIG_NETFILTER is not set # CONFIG_FILTER is not set # CONFIG_UNIX is not set CONFIG_INET=y # CONFIG_IP_MULTICAST is not set # CONFIG_IP_ADVANCED_ROUTER is not set CONFIG_IP_PNP=y CONFIG_IP_PNP_BOOTP=y # CONFIG_IP_PNP_RARP is not set # CONFIG_NET_IPIP is not set # CONFIG_NET_IPGRE is not set # CONFIG_INET_ECN is not set # CONFIG_SYN_COOKIES is not set # CONFIG_IPV6 is not set # CONFIG_KHTTPD is not set # CONFIG_ATM is not set # # # # CONFIG_IPX is not set # CONFIG_ATALK is not set # CONFIG_DECNET is not set # CONFIG_BRIDGE is not set # CONFIG_X25 is not set # CONFIG_LAPB is not set # CONFIG_LLC is not set # CONFIG_NET_DIVERT is not set # CONFIG_ECONET is not set # CONFIG_WAN_ROUTER is not set # CONFIG_NET_FASTROUTE is not set # CONFIG_NET_HW_FLOWCONTROL is not set # # QoS and/or fair queueing # # CONFIG_NET_SCHED is not set # # SCSI support # # CONFIG_SCSI is not set # # Network device support # CONFIG_NETDEVICES=y CONFIG_LASI_82596=y # # ARCnet devices # # CONFIG_ARCNET is not set # CONFIG_DUMMY is not set # CONFIG_BONDING is not set # CONFIG_EQUALIZER is not set # CONFIG_TUN is not set # CONFIG_NET_SB1000 is not set # # Ethernet (10 or 100Mbit) # CONFIG_NET_ETHERNET=y # CONFIG_NET_VENDOR_3COM is not set # CONFIG_LANCE is not set # CONFIG_NET_VENDOR_SMC is not set # CONFIG_NET_VENDOR_RACAL is not set # CONFIG_AT1700 is not set # CONFIG_DEPCA is not set # CONFIG_HP100 is not set # CONFIG_NET_ISA is not set CONFIG_NET_PCI=y # CONFIG_PCNET32 is not set # CONFIG_ADAPTEC_STARFIRE is not set # CONFIG_AC3200 is not set # CONFIG_APRICOT is not set # CONFIG_CS89x0 is not set # CONFIG_DE4X5 is not set # CONFIG_TULIP is not set # CONFIG_DGRS is not set # CONFIG_DM9102 is not set # CONFIG_EEPRO100 is not set # CONFIG_LNE390 is not set # CONFIG_NATSEMI is not set # CONFIG_NE2K_PCI is not set # CONFIG_NE3210 is not set # CONFIG_ES3210 is not set # CONFIG_RTL8129 is not set # CONFIG_8139TOO is not set # CONFIG_SIS900 is not set # CONFIG_EPIC100 is not set # CONFIG_SUNDANCE is not set # CONFIG_TLAN is not set # CONFIG_VIA_RHINE is not set # CONFIG_WINBOND_840 is not set # CONFIG_NET_POCKET is not set # # Ethernet (1000 Mbit) # # CONFIG_ACENIC is not set # CONFIG_HAMACHI is not set # CONFIG_YELLOWFIN is not set # CONFIG_SK98LIN is not set # CONFIG_FDDI is not set # CONFIG_HIPPI is not set # CONFIG_PPP is not set # CONFIG_SLIP is not set # # Wireless LAN (non-hamradio) # # CONFIG_NET_RADIO is not set # # Token Ring devices # # CONFIG_TR is not set # CONFIG_NET_FC is not set # CONFIG_RCPCI is not set # CONFIG_SHAPER is not set # # Wan interfaces # # CONFIG_WAN is not set # # Character devices # # CONFIG_VT is not set CONFIG_SERIAL=y CONFIG_SERIAL_CONSOLE=y CONFIG_SERIAL_GSC=y CONFIG_SERIAL_EXTENDED=y # CONFIG_SERIAL_MANY_PORTS is not set # CONFIG_SERIAL_SHARE_IRQ is not set # CONFIG_SERIAL_DETECT_IRQ is not set # CONFIG_SERIAL_MULTIPORT is not set # CONFIG_HUB6 is not set # CONFIG_SERIAL_NONSTANDARD is not set CONFIG_UNIX98_PTYS=y CONFIG_UNIX98_PTY_COUNT=256 # # I2C support # # CONFIG_I2C is not set # # Mice # # CONFIG_BUSMOUSE is not set # CONFIG_MOUSE is not set # # Joysticks # # CONFIG_JOYSTICK is not set # # Input core support is needed for joysticks # # CONFIG_QIC02_TAPE is not set # # Watchdog Cards # # CONFIG_WATCHDOG is not set # CONFIG_GENRTC is not set # CONFIG_INTEL_RNG is not set # CONFIG_NVRAM is not set # CONFIG_RTC is not set # CONFIG_DTLK is not set # CONFIG_R3964 is not set # CONFIG_APPLICOM is not set # # Ftape, the floppy tape device driver # # CONFIG_FTAPE is not set # CONFIG_AGP is not set # CONFIG_DRM is not set # # File systems # # CONFIG_QUOTA is not set # CONFIG_AUTOFS_FS is not set # CONFIG_AUTOFS4_FS is not set # CONFIG_ADFS_FS is not set # CONFIG_ADFS_FS_RW is not set # CONFIG_AFFS_FS is not set # CONFIG_HFS_FS is not set # CONFIG_BFS_FS is not set # CONFIG_FAT_FS is not set # CONFIG_MSDOS_FS is not set # CONFIG_UMSDOS_FS is not set # CONFIG_VFAT_FS is not set # CONFIG_EFS_FS is not set # CONFIG_JFFS_FS is not set # CONFIG_CRAMFS is not set # CONFIG_RAMFS is not set CONFIG_ISO9660_FS=y # CONFIG_JOLIET is not set # CONFIG_MINIX_FS is not set # CONFIG_NTFS_FS is not set # CONFIG_NTFS_RW is not set # CONFIG_HPFS_FS is not set CONFIG_PROC_FS=y # CONFIG_DEVFS_FS is not set # CONFIG_DEVFS_MOUNT is not set # CONFIG_DEVFS_DEBUG is not set # CONFIG_DEVPTS_FS is not set # CONFIG_QNX4FS_FS is not set # CONFIG_QNX4FS_RW is not set # CONFIG_ROMFS_FS is not set CONFIG_EXT2_FS=y # CONFIG_SYSV_FS is not set # CONFIG_SYSV_FS_WRITE is not set # CONFIG_UDF_FS is not set # CONFIG_UDF_RW is not set # CONFIG_UFS_FS is not set # CONFIG_UFS_FS_WRITE is not set # # Network File Systems # # CONFIG_CODA_FS is not set CONFIG_NFS_FS=y # CONFIG_NFS_V3 is not set CONFIG_ROOT_NFS=y # CONFIG_NFSD is not set # CONFIG_NFSD_V3 is not set CONFIG_SUNRPC=y CONFIG_LOCKD=y # CONFIG_SMB_FS is not set # CONFIG_NCP_FS is not set # CONFIG_NCPFS_PACKET_SIGNING is not set # CONFIG_NCPFS_IOCTL_LOCKING is not set # CONFIG_NCPFS_STRONG is not set # CONFIG_NCPFS_NFS_NS is not set # CONFIG_NCPFS_OS2_NS is not set # CONFIG_NCPFS_SMALLDOS is not set # CONFIG_NCPFS_MOUNT_SUBDIR is not set # CONFIG_NCPFS_NDS_DOMAINS is not set # CONFIG_NCPFS_NLS is not set # CONFIG_NCPFS_EXTRAS is not set # # Partition Types # # CONFIG_PARTITION_ADVANCED is not set CONFIG_MSDOS_PARTITION=y # CONFIG_NLS is not set # # Sound Drivers # # CONFIG_SOUND is not set # # Kernel hacking # # CONFIG_MAGIC_SYSRQ is not set From grundler@cup.hp.com Wed, 15 Nov 2000 12:10:36 -0800 Date: Wed, 15 Nov 2000 12:10:36 -0800 From: Grant Grundler grundler@cup.hp.com Subject: [parisc-linux] nfsroot - 712/60 - RPC - help Jack Perdue wrote: Two changes: > a) I've tried NFSROOT=192.168.1.11 and NFSROOT=192.168.1.11/tftpboot/vmlinux > in palo/Makefile and the results are the same (both suggestions were > made to this list at some point) Try NFSROOT=192.168.1.11/tftpboot/pancho > ========== blacktower:/etc/bootptab ========== > pancho:\ > :hd=/tftpboot:\ > :bf=vmlinux:\ > :ht=ether:\ > :ha=08000993DA02:\ > :sm=255.255.255.0:\ > :hn:\ > :ip=192.168.1.13:\ > :vm=rfc1048: This is just a nit: bf= might be better named ":bf=lifimage\" (and you only need one colon between entry's :^) Copy /palo/lifimage to /tftpboot/lifimage. There must be something wrong but I don't see it. grant > kmem_create: Forcing size word alignment - nfs_fh > Looking up port of RPC 100003/2 on 192.68.1.11 > RPC: sendmsg returned error 229 > portmap: RPC call returned error 229 I don't see these types of errors on my config. Could be related to the misdirected NFSROOT. grant Grant Grundler Unix Systems Enablement Lab +1.408.447.7253 From j-perdue@tamu.edu Wed, 15 Nov 2000 14:14:13 -0600 Date: Wed, 15 Nov 2000 14:14:13 -0600 From: Jack Perdue j-perdue@tamu.edu Subject: Doh!!! was Re: [parisc-linux] nfsroot - 712/60 - RPC - help Of course, as soon I collected all that info and sent it I, in rereading, realized that I had put 192.68.1.11 in palo/Makefile instead of 192.168.1.11. Doh! However, since the info is out there now, can someone tell me what I need to resolve the following: [previous console output in previous mail] Switching from PDC console kmem_create: Forcing size word alignment - nfs_fh Looking up port of RPC 100003/2 on 192.168.1.11 Looking up port of RPC 100005/2 on 192.168.1.11 VFS: Mounted root (nfs filesystem) readonly. Kernel panic: No init found. Try passing init= option to kernel. jack j-perdue@tamu.edu From law@redhat.com Wed, 15 Nov 2000 13:30:59 -0700 Date: Wed, 15 Nov 2000 13:30:59 -0700 From: law@redhat.com law@redhat.com Subject: [parisc-linux] Single-stepping In message <200011151949.OAA22929@hiauly1.hia.nrc.ca>you write: > > I've been helping Alan Modra out with kernel changes to support > > single stepping for gdb. Paul Bame suggested I bounced our ideas > > off you in case you (or anyone else) had any comments. I havn't > > actually committed my changes yet. > > > > The basic approach is to use the recovery counter to generate > > a trap every instruction. The scheme is complicated because a > > suspended process may or may not return to user space via an RFI. > > I really don't know enough to comment on the implementation choice. Why > did you decide on this approach as opposed to inserting breaks and > enabling the taken branch branch trap (T)? It would appear that the recove > ry > counter was intended to provide software recovery from hardware faults > in fault tolerant systems. Possibly, Grant could comment on whether > it is actually useful for this purpose. Err, we tried that at the UofU in our mach port to the PA -- there's a problem with that scheme, though I don't remember precisely what it was. I believe there were cases where the recovery counter doesn't trigger a trap, possibly due to nullified instructions. You might look at the UofU BSD code, which I believe used breakpoints and branch taken traps instad. jeff From taggart@carmen.fc.hp.com Wed, 15 Nov 2000 13:49:18 -0700 Date: Wed, 15 Nov 2000 13:49:18 -0700 From: Matt Taggart taggart@carmen.fc.hp.com Subject: [parisc-linux] Palinux on a 712/60 Andrew Shugg writes... > Arnaud.ATOCH@oecd.org said: > > Hi, > > > > I got a couple of 715 and I'd love having access to an ISO image with STI > > console kernel too. > > I've never made an El Torito CDROM, is it possible to have multiple boot > images and a boot loader on a single disc? El Torito is a PC thing. It makes the front of a CDROM look like a floppy to the PC BIOS. For hppa you put a lifimage on the front of the CDROM(or tape or HDD, etc). > ie could the actual boot > image be a boot loader (PALO) which then points at one or more kernels > on the CDROM? Maybe. Paul Bame is the expert though. I think he had to do some work to get palo to be able to see a kernel on an ISO9660 filesystem. I don't know if it can currently be interruped and pointed at a different kernel. Paul? -- Matt Taggart taggart@fc.hp.com From drepper@redhat.com 15 Nov 2000 12:52:52 -0800 Date: 15 Nov 2000 12:52:52 -0800 From: Ulrich Drepper drepper@redhat.com Subject: [parisc-linux] Help with posix_types.h Paul Bame writes: > FYI I just heard some pretty good reasons why both ino_t and off_t > should be 64 bits even on 32-bit kernels. Keep those cards and letters > coming! Any new port which does *not* do this is broken from the beginning. Copying existing files is not what you have to do. Instead look at today's needs. The numbers of the x86 port are those the kernel people told me are needs, multiplied by 2 or 4. Do the same. -- ---------------. ,-. 1325 Chesapeake Terrace Ulrich Drepper \ ,-------------------' \ Sunnyvale, CA 94089 USA Red Hat `--' drepper at redhat.com `------------------------ From ich@johannes-zahn.de Wed, 15 Nov 2000 21:49:31 +0100 Date: Wed, 15 Nov 2000 21:49:31 +0100 From: johannes zahn ich@johannes-zahn.de Subject: [parisc-linux] init dies on apollo 720 Hi! I'm trying to get a 720/50 to boot from nfs, but as soon as the nfs mound happened init dies. This is all i get on the serial console (pasted from minicom): kmem_create: Forcing size word alignment - nfs_fh Looking up port of RPC 100003/2 on 192.168.1.1 Looking up port of RPC 100005/2 on 192.168.1.1 VFS: Mounted root (nfs filesystem) readonly. handle_interruption() pid=1 command='init' YZrvWESTHLNXBCVMcbcbcbcbOGFRQPDI PSW: 00000000000001001111011100001011 r0-3 00000000 4001ad3c 400057a3 00001f58 r4-7 4001967c 00000000 4001ada0 00001f58 r8-11 00000000 000023cc 00000001 00000000 r12-15 00001034 00000006 40019622 2001ff18 r16-19 c1fdc000 c027b60c 00000000 4001967c r20-23 0000a090 0000a090 00009d8c 00001f58 r24-27 00000001 00000081 4001ada0 c01492b0 r28-31 00000000 0000000b 20020790 400032d7 sr0-4 00000001 00000001 00000000 00000001 sr4-8 00000001 00000001 00000001 00000001 IASQ: 00000001 00000001 IAOQ: 4000d237 4000d23b IIR: 0ed51280 ISR: 00000001 IOR: 00009d8c ORIG_R28: 4001b208 handle_interruption() pid=1 command='init' YZrvWESTHLNXBCVMcbcbcbcbOGFRQPDI [...] I tried the cvs-latest kernel and palo from 2000-11-10 and 2000-11-14 with the crosscompiler from 2000-10-31. Buildhost is i386 linux. nfsroot was from 2000-10-09 or base.tgz from the 0.5 beta CD. I also tried the ramdisk images with sercon and sticon, but the kernel only says "cannot mount root FS on 01:00". The kernel from the 0.5 beta CD seems to have the parport stuff, and that does not work on this machine. Any ideas? Or a working .config? johannes From sieler@allegro.com Wed, 15 Nov 2000 13:08:15 -0800 (PST) Date: Wed, 15 Nov 2000 13:08:15 -0800 (PST) From: Stan Sieler sieler@allegro.com Subject: [parisc-linux] Single-stepping Re: > > The basic approach is to use the recovery counter to generate > > a trap every instruction. The scheme is complicated because a ... > I really don't know enough to comment on the implementation choice. Why > did you decide on this approach as opposed to inserting breaks and MPE/iX (which runs on PA-RISC hardware), has successfully used the Recovery Counter to implement single step for many, many years. BTW, in addition to single step, it's a great tool for counting the number of instructions a procedure (or code path) takes, assuming an adequately powerful debugger: 1) stop (perhaps via a breakpoint) at the start of the code you want to count. 2) set a breakpoint at the end of the code you want to count (e.g., if you're counting a procedure, set a breakpoint at the procedure exit) 3) instead of "continue", do: s 1000000 (i.e., tell Debug/iX to "singlestep" 1000000 instructions) 4) if you hit the breakpoint, enter: = 1000000 - rctr that's how many instructions your code took! (Not counting instructions executed by interrupt handlers, of course.) 5) if you *didn't* hit the breakpoint, then 1000000 wasn't enough instructions (and why are you trying to count so high?) This works because MPE's debug "s" command sets the Recovery Counter to the number of instructions you wanted to step. Normally, that's one (for just "s"). If you said "s 3", it would set the Recovery Counter to 3. If you say "s 1000000", and then execute 123 instructions, and then hit a breakpoint, Debug captures the entire register state as of the breakpoint: including the Recovery Counter (which has 1000000 - 123 in it). Tip: if you're looking at instruction-level debugging, look at Debug/iX to see how to do it right! > It would appear that the recovery > counter was intended to provide software recovery from hardware faults The 1986 PA-RISC Instruction manual simply says "The Recovery Counter (CR 0) can be used to provide software recovery of hardware faults in fault tolerant systems". (I.e., "can", not "must" ... and there's no explanation of how one would use it for this.) -- Stan Sieler sieler@allegro.com www.allegro.com/sieler/wanted/index.html www.sieler.com From drepper@redhat.com 15 Nov 2000 13:08:01 -0800 Date: 15 Nov 2000 13:08:01 -0800 From: Ulrich Drepper drepper@redhat.com Subject: [parisc-linux] Help with posix_types.h This reminds me of something I talked to Cary Coutant about before. You have certainly reserved a thread register in the ABI, right? If not, do it ASAP. -- ---------------. ,-. 1325 Chesapeake Terrace Ulrich Drepper \ ,-------------------' \ Sunnyvale, CA 94089 USA Red Hat `--' drepper at redhat.com `------------------------ From frank_rowand@mvista.com Wed, 15 Nov 2000 13:16:28 -0800 Date: Wed, 15 Nov 2000 13:16:28 -0800 From: Frank Rowand frank_rowand@mvista.com Subject: [parisc-linux] Single-stepping law@redhat.com wrote: > > In message <200011151949.OAA22929@hiauly1.hia.nrc.ca>you write: > > > I've been helping Alan Modra out with kernel changes to support > > > single stepping for gdb. Paul Bame suggested I bounced our ideas > > > off you in case you (or anyone else) had any comments. I havn't > > > actually committed my changes yet. > > > > > > The basic approach is to use the recovery counter to generate > > > a trap every instruction. The scheme is complicated because a > > > suspended process may or may not return to user space via an RFI. > > > > I really don't know enough to comment on the implementation choice. Why > > did you decide on this approach as opposed to inserting breaks and > > enabling the taken branch branch trap (T)? It would appear that the recove > > ry > > counter was intended to provide software recovery from hardware faults > > in fault tolerant systems. Possibly, Grant could comment on whether > > it is actually useful for this purpose. > Err, we tried that at the UofU in our mach port to the PA -- there's a problem > with that scheme, though I don't remember precisely what it was. I believe > there were cases where the recovery counter doesn't trigger a trap, possibly > due to nullified instructions. > > You might look at the UofU BSD code, which I believe used breakpoints and > branch taken traps instad. > > jeff > I implemented two different single step algorithms for a a _kernel_ debugger for hp-ux. The algorithm used could be chosen by a compile switch, because each method had cases that weren't handled well - for some debugging tasks one algorithm was superior to the other. Part of my problem with the recovery counter was that other services in the hp-ux kernel also used the recovery counter. I liked the recovery counter method better than my second method (but had to deal with collisions with the other kernel services). My second method was to insert a breakpoint at the target of the single step. It's a pain to do that because of issues with delay slots, branching, and nullification. I guess the point of all this rambling is to say that the recovery counter has been successfully used by a debugger for single stepping. -Frank -- Frank Rowand MontaVista Software, Inc From sieler@allegro.com Wed, 15 Nov 2000 13:47:15 -0800 (PST) Date: Wed, 15 Nov 2000 13:47:15 -0800 (PST) From: Stan Sieler sieler@allegro.com Subject: [parisc-linux] Single-stepping Re: > I implemented two different single step algorithms for a a _kernel_ debugger > for hp-ux. The algorithm used could be chosen by a compile switch, because BTW, Frank, ask Lee Courtney at MontaVista about Debug/iX ... we've had kernel debugging and single stepping (except for the interrupt control stack and a few other corner cases) for 15+ years. It's *very* powerful to be able to logon as root (or equivalent) and set breakpoints within the kernel, hit them, and then single step ... all on a standard release of the operating system. > I liked the recovery counter method better than my second method (but had to > deal with collisions with the other kernel services). My second method was > to insert a breakpoint at the target of the single step. It's a pain to do > that because of issues with delay slots, branching, and nullification. Worse yet...the breakpoint mechanism raises hell if you have more than one CPU :) You realllly don't want that other CPU to hit the breakpoint! -- Stan Sieler sieler@allegro.com www.allegro.com/sieler/wanted/index.html www.sieler.com From andreas@bawue.de Thu, 16 Nov 2000 23:06:04 +0100 Date: Thu, 16 Nov 2000 23:06:04 +0100 From: Andreas Thienemann andreas@bawue.de Subject: [parisc-linux] 250/1 doesn't boot but dumps stack Hi Grant, Grant Grundler wrote: > > lp0: using parport0 (interrupt-driven). > Are you sure you left out parallel port support? Yes, I am. I just attached the wrong log. Except the lp0 line, there are no differences... > > IASQ: 00000000 00000000 IAOQ: c029c264 c029c268 > > IIR: 0e681096 ISR: 00000000 IOR: 00000004 > > ORIG_R28: 00000000 > Smells like a driver bug. > Can you look up IOAQ and GR2 (c029c264 and c029c248) in System.map file? Of course. The only problem is, there is no such entry in /usr/src/pa-risc/sourcE/linux/System.map . Any ideas? andreas From rhirst@linuxcare.com Wed, 15 Nov 2000 22:19:29 +0000 Date: Wed, 15 Nov 2000 22:19:29 +0000 From: Richard Hirst rhirst@linuxcare.com Subject: [parisc-linux] dino maintainer? On Wed, Nov 15, 2000 at 09:58:35AM +0000, Richard Hirst wrote: > But Helge has problems with the sym53c8xx driver on a B160L. Is Turned out to be a 53c720, driven via Zalon and the ncr53c8xx driver. Driver worked as a module, but not compiled in. Now fixed. Richard From rlduncan@nortelnetworks.com Wed, 15 Nov 2000 17:28:13 -0500 Date: Wed, 15 Nov 2000 17:28:13 -0500 From: Robert Duncan rlduncan@nortelnetworks.com Subject: [parisc-linux] CD-ROM 715/50 boot dies after serial driver... This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C04F53.576F0F70 Content-Type: text/plain; charset="iso-8859-1" Greetings, I have downloaded the .5 Beta CDROM image, burned it and get a "fault in kernel" after the "Serial driver ... enabled" message when booting on my 715/50. This happens with either graphics or serial console configured in NVRAM. Has anyone else seen this error? ----------------begin console output (c) Copyright Hewlett-Packard Company, 1991, 1992 Portions of this code are (c) Copyright Samsung Electronics Co., Ltd, 91, 92 PDC ROM rev. 1.2 IODC ROM rev. 1.1 64 MB of memory have been configured. Selecting a system to boot. To stop selection process, press and hold the ESCAPE key..... Booting from: scsi.6.0 TOSHIBA CD-ROM XM-3501TA Soft booted. palo ipl bame@noam Tue Oct 31 14:18:02 MST 2000 0/vmlinux 2140145 bytes @ 0x6f9800 0/palo-cmdline '0/vmlinux ROOT=/ TERM=LINUX root=/dev/scd0' Kernel: partition 0 file /vmlinux ELF32 executable Entry 00100150 first 00100000 n 4 Segment 0 load 00100000 size 1460344 mediaptr 0x1000 Segment 1 load 00266000 size 179048 mediaptr 0x166000 Segment 2 load 00294000 size 109876 mediaptr 0x192000 Segment 3 load 002b0000 size 8192 mediaptr 0x1ad000 branching to kernel entry point 0x00100150 PDC Console Initialized The 32-bit Kernel has started... Enabled FP coprocessor Free memory starts at: 0xc02da000 (0x504d6c,0x504d6c,0x0,0x0) PALO command line: 'ROOT=/ TERM=LINUX root=/dev/scd0' PALO initrd 0-0 model 00003100 00000481 00000000 00000000 77a94524 ffffffff 00000004 0000000a 0000000a vers 00000009 CPUID vers 0 rev 0 Searching for devices in PDC firmware... processor hpa 0xfffbe000 an older box... Found devices: 1. Stinger Optional Graphics (10) at 0xf4000000, versions 0x6, 0x0, 0x77, 0x0, 0x0 2. Scorpio Core BA (11) at 0xf082f000, versions 0x7, 0x0, 0x70, 0x0, 0x0 3. Scorpio Core SCSI (10) at 0xf0825000, versions 0x7, 0x0, 0x71, 0x0, 0x0 4. Scorpio Core LAN (802.3) (10) at 0xf0826000, versions 0x7, 0x0, 0x72, 0x0, 0x0 5. Scorpio Core HIL (10) at 0xf0821000, versions 0x7, 0x0, 0x73, 0x0, 0x0 6. Scorpio Core RS-232 (10) at 0xf0823000, versions 0x7, 0x0, 0x75, 0x0, 0x0 7. Scorpio Core RS-232 (10) at 0xf0822000, versions 0x7, 0x0, 0x75, 0x0, 0x0 8. Scorpio Core Centronics (10) at 0xf0824000, versions 0x7, 0x0, 0x74, 0x0, 0x0 9. Scorpio Audio (10) at 0xf1000000, versions 0x7, 0x0, 0x7b, 0x0, 0x0 10. Scorpio EISA BA (11) at 0xfc000000, versions 0x7, 0x0, 0x76, 0x0, 0x0 11. Scorpio (715/50) (0) at 0xfffbe000, versions 0x310, 0x0, 0x4, 0x0, 0x81 12. Scorpio (1) at 0xfffbf000, versions 0x17, 0x0, 0x9, 0x0, 0x0 That's a total of 12 devices. CPU(s): 1 x PA7100 (PCX-T) at 50.000000 MHz Linux version 2.4.0-test6 (pjlahaie@elenuial.thepuffingroup.com) (gcc version 2.96 20000925 (experimental)) #32 Mon Nov 6 10:20:58 EST 2000 free_bootmem(0x2da800, 0x3d25800) initrd: 00000000-00000000 pagetable_init On node 0 totalpages: 16384 zone(0): 8192 pages. zone(1): 8192 pages. zone(2): 0 pages. Kernel command line: ROOT=/ TERM=LINUX root=/dev/scd0 trap_init Calibrating delay loop... 49.77 BogoMIPS Memory: 61388k available Dentry-cache hash table entries: 8192 (order: 4, 65536 bytes) Buffer-cache hash table entries: 4096 (order: 2, 16384 bytes) Page-cache hash table entries: 16384 (order: 4, 65536 bytes) Inode-cache hash table entries: 4096 (order: 3, 32768 bytes) POSIX conformance testing by UNIFIX ASP version 1 at 0xf0800000 found. Found i82596 at 0xf0826000, IRQ 87 early initialization of device eth0 is deferred Found HIL at 0xf0821000, IRQ 94 HIL: no keyboard present. Warning : device (10, 0x7, 0x0, 0x73, 0x0) NOT claimed by HIL 712, 715 or similiar Linux NET4.0 for Linux 2.4 Based upon Swansea University Computer Society NET3.039 NET4: Unix domain sockets 1.0/SMP for Linux NET4.0. NET4: Linux TCP/IP 1.0 for NET4.0 IP Protocols: ICMP, UDP, TCP IP: routing cache hash table of 512 buckets, 4Kbytes TCP: Hash tables configured (established 4096 bind 4096) Starting kswapd v1.7 pty: 256 Unix98 ptys configured lp: driver loaded but no devices found RAMDISK driver initialized: 16 RAM disks of 4096K size 1024 blocksize sim700: Couldn't get consistent shared memory sim700: Configuring 53c700 (SCSI-ID 7) at f0825100, IRQ 86 scsi0: Revision 0x0 Post test1, istat 05, sstat0 00, dstat 84 sim700: WARNING IRQ probe failed, (returned 0) scsi0: WARNING: target data areas are not dma coherent! scsi0: test 1 completed ok. scsi0: sim700_intr_handle() called with no interrupt scsi0 : LASI/Simple 53c7xx scsi : 1 host. Vendor: TOSHIBA Model: CD-ROM XM-3501TA Rev: 3054 Type: CD-ROM ANSI SCSI revision: 02 Detected scsi CD-ROM sr0 at scsi0, channel 0, id 6, lun 0 scsi : detected 1 SCSI cdrom total. Uniform CD-ROM driver Revision: 3.11 82596.c: MAC of HP700 LAN blindely read from the prom! eth0: Couldn't get consistent shared memory eth0: 82596 at 0xf0826000, 08 00 09 42 1B 37 IRQ 87. 82596.c $Revision: 1.14 $ Serial driver version 5.01 (2000-05-29) with MANY_PORTS SHARE_IRQ SERIAL_PCI enabled Dumping Stack from c3fc4000 to c3fc4bc0: 4000 00000000 00000140 00000000 00000000 c027a46c 00000001 00000000 ffffffff 4020 00000000 00000000 00000000 00000000 00000000 00000000 ffffffff c027a384 [...] 4ba0 ffffffff bffff5ff ffffff7f c01046e0 ffffbeff f7b7eddf 5fffffdf feefffff Data access rights fault in kernel: Code=26 regs=c3fc4980 (Addr=00000003) YZrvWESTHLNXBCVMcbcbcbcbOGFRQPDI PSW: 00000000000001000000000000001010 r0-3 00000000 c0221800 c011e9f8 c3fce420 r4-7 c3fce200 c0244f10 00000008 f0823800 r8-11 00000003 00000007 c0191568 c02c60a4 r12-15 fffffffc c0245000 c0245000 c02d72b8 r16-19 c0245000 c0245000 c02c6028 00000000 r20-23 c3fce234 f0823807 f0823800 0000000a r24-27 ffffffff c3fce420 c3fce200 c0266000 r28-31 ffffffff 00000240 c3fc4bc0 c012dfc0 sr0-4 00000000 00000000 00000000 00000000 sr4-8 00000000 00000000 00000000 00000000 IASQ: 00000000 00000000 IAOQ: c011e710 c011e714 IIR: 0f881093 ISR: 00000000 IOR: 00000003 ORIG_R28: 00000058 ----------------end console output thanks, Robert Duncan Nortelnetworks ------_=_NextPart_001_01C04F53.576F0F70 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable CD-ROM 715/50 boot dies after serial driver...

Greetings,
I have downloaded the .5 Beta CDROM image, burned it = and get a "fault in kernel" after the "Serial driver ... = enabled" message when booting on my 715/50.  This happens = with either graphics or serial console configured in NVRAM.

Has anyone else seen this error?

----------------begin console output
          &nb= sp;   (c) Copyright Hewlett-Packard Company, 1991, = 1992
Portions of this code are (c) Copyright Samsung = Electronics Co., Ltd, 91, 92

PDC ROM rev. 1.2
IODC ROM rev. 1.1
64 MB of memory have been configured.


Selecting a system to boot.
To stop selection process, press and hold the ESCAPE = key.....

Booting from:     = scsi.6.0     TOSHIBA CD-ROM XM-3501TA

Soft booted.
palo ipl bame@noam Tue Oct 31 14:18:02 MST = 2000
0/vmlinux 2140145 bytes @ 0x6f9800
0/palo-cmdline '0/vmlinux ROOT=3D/ TERM=3DLINUX = root=3D/dev/scd0'
Kernel: partition 0 file /vmlinux
ELF32 executable

Entry 00100150 first 00100000 n 4
Segment 0 load 00100000 size 1460344 mediaptr = 0x1000
Segment 1 load 00266000 size 179048 mediaptr = 0x166000
Segment 2 load 00294000 size 109876 mediaptr = 0x192000
Segment 3 load 002b0000 size 8192 mediaptr = 0x1ad000
branching to kernel entry point 0x00100150
PDC Console Initialized
The 32-bit Kernel has started...
Enabled FP coprocessor
Free memory starts at: 0xc02da000
(0x504d6c,0x504d6c,0x0,0x0)
PALO command line: 'ROOT=3D/ TERM=3DLINUX = root=3D/dev/scd0'
PALO initrd 0-0
model   00003100 00000481 00000000 = 00000000 77a94524 ffffffff 00000004 0000000a 0000000a
vers    00000009
CPUID vers 0 rev 0
Searching for devices in PDC firmware... processor = hpa 0xfffbe000
 an older box...
Found devices:
1. Stinger Optional Graphics (10) at 0xf4000000, = versions 0x6, 0x0, 0x77, 0x0, 0x0
2. Scorpio Core BA (11) at 0xf082f000, versions 0x7, = 0x0, 0x70, 0x0, 0x0
3. Scorpio Core SCSI (10) at 0xf0825000, versions = 0x7, 0x0, 0x71, 0x0, 0x0
4. Scorpio Core LAN (802.3) (10) at 0xf0826000, = versions 0x7, 0x0, 0x72, 0x0, 0x0
5. Scorpio Core HIL (10) at 0xf0821000, versions = 0x7, 0x0, 0x73, 0x0, 0x0
6. Scorpio Core RS-232 (10) at 0xf0823000, versions = 0x7, 0x0, 0x75, 0x0, 0x0
7. Scorpio Core RS-232 (10) at 0xf0822000, versions = 0x7, 0x0, 0x75, 0x0, 0x0
8. Scorpio Core Centronics (10) at 0xf0824000, = versions 0x7, 0x0, 0x74, 0x0, 0x0
9. Scorpio Audio (10) at 0xf1000000, versions 0x7, = 0x0, 0x7b, 0x0, 0x0
10. Scorpio EISA BA (11) at 0xfc000000, versions = 0x7, 0x0, 0x76, 0x0, 0x0
11. Scorpio (715/50) (0) at 0xfffbe000, versions = 0x310, 0x0, 0x4, 0x0, 0x81
12. Scorpio (1) at 0xfffbf000, versions 0x17, 0x0, = 0x9, 0x0, 0x0
That's a total of 12 devices.
CPU(s): 1 x PA7100 (PCX-T) at 50.000000 MHz
Linux version 2.4.0-test6 = (pjlahaie@elenuial.thepuffingroup.com) (gcc version 2.96 20000925 = (experimental)) #32 Mon Nov 6 10:20:58 EST 2000

free_bootmem(0x2da800, 0x3d25800)
initrd: 00000000-00000000
pagetable_init
On node 0 totalpages: 16384
zone(0): 8192 pages.
zone(1): 8192 pages.
zone(2): 0 pages.
Kernel command line: ROOT=3D/ TERM=3DLINUX = root=3D/dev/scd0
trap_init
Calibrating delay loop... 49.77 BogoMIPS
Memory: 61388k available
Dentry-cache hash table entries: 8192 (order: 4, = 65536 bytes)
Buffer-cache hash table entries: 4096 (order: 2, = 16384 bytes)
Page-cache hash table entries: 16384 (order: 4, = 65536 bytes)
Inode-cache hash table entries: 4096 (order: 3, = 32768 bytes)
POSIX conformance testing by UNIFIX
ASP version 1 at 0xf0800000 found.
Found i82596 at 0xf0826000, IRQ 87
early initialization of device eth0 is = deferred
Found HIL at 0xf0821000, IRQ 94
HIL: no keyboard present.
Warning : device (10, 0x7, 0x0, 0x73, 0x0) NOT = claimed by HIL 712, 715 or similiar
Linux NET4.0 for Linux 2.4
Based upon Swansea University Computer Society = NET3.039
NET4: Unix domain sockets 1.0/SMP for Linux = NET4.0.
NET4: Linux TCP/IP 1.0 for NET4.0
IP Protocols: ICMP, UDP, TCP
IP: routing cache hash table of 512 buckets, = 4Kbytes
TCP: Hash tables configured (established 4096 bind = 4096)
Starting kswapd v1.7
pty: 256 Unix98 ptys configured
lp: driver loaded but no devices found
RAMDISK driver initialized: 16 RAM disks of 4096K = size 1024 blocksize
sim700: Couldn't get consistent shared memory
sim700: Configuring 53c700 (SCSI-ID 7) at f0825100, = IRQ 86
scsi0: Revision 0x0
Post test1, istat 05, sstat0 00, dstat 84
sim700: WARNING IRQ probe failed, (returned = 0)
scsi0: WARNING: target data areas are not dma = coherent!
scsi0: test 1 completed ok.
scsi0: sim700_intr_handle() called with no = interrupt
scsi0 : LASI/Simple 53c7xx
scsi : 1 host.
  Vendor: TOSHIBA   Model: CD-ROM = XM-3501TA  Rev: 3054
  Type:   = CD-ROM           =             =       ANSI SCSI revision: 02
Detected scsi CD-ROM sr0 at scsi0, channel 0, id 6, = lun 0
scsi : detected 1 SCSI cdrom total.
Uniform CD-ROM driver Revision: 3.11
82596.c: MAC of HP700 LAN blindely read from the = prom!
eth0: Couldn't get consistent shared memory
eth0: 82596 at 0xf0826000, 08 00 09 42 1B 37 IRQ = 87.
82596.c $Revision: 1.14 $
Serial driver version 5.01 (2000-05-29) with = MANY_PORTS SHARE_IRQ SERIAL_PCI enabled

Dumping Stack from c3fc4000 to c3fc4bc0:
4000 00000000 00000140 00000000 00000000 c027a46c = 00000001 00000000 ffffffff
4020 00000000 00000000 00000000 00000000 00000000 = 00000000 ffffffff c027a384
 [...]
4ba0 ffffffff bffff5ff ffffff7f c01046e0 ffffbeff = f7b7eddf 5fffffdf feefffff

Data access rights fault in kernel: Code=3D26 = regs=3Dc3fc4980 (Addr=3D00000003)

     = YZrvWESTHLNXBCVMcbcbcbcbOGFRQPDI
PSW: 00000000000001000000000000001010
r0-3     00000000 c0221800 = c011e9f8 c3fce420
r4-7     c3fce200 c0244f10 = 00000008 f0823800
r8-11    00000003 00000007 c0191568 = c02c60a4
r12-15   fffffffc c0245000 c0245000 = c02d72b8
r16-19   c0245000 c0245000 c02c6028 = 00000000
r20-23   c3fce234 f0823807 f0823800 = 0000000a
r24-27   ffffffff c3fce420 c3fce200 = c0266000
r28-31   ffffffff 00000240 c3fc4bc0 = c012dfc0
sr0-4    00000000 00000000 00000000 = 00000000
sr4-8    00000000 00000000 00000000 = 00000000

IASQ: 00000000 00000000 IAOQ: c011e710 = c011e714
 IIR: 0f881093    ISR: = 00000000  IOR: 00000003
ORIG_R28: 00000058

----------------end console output

thanks,
Robert Duncan
Nortelnetworks

------_=_NextPart_001_01C04F53.576F0F70-- From rhirst@linuxcare.com Wed, 15 Nov 2000 22:35:40 +0000 Date: Wed, 15 Nov 2000 22:35:40 +0000 From: Richard Hirst rhirst@linuxcare.com Subject: [parisc-linux] CD-ROM 715/50 boot dies after serial driver... On Wed, Nov 15, 2000 at 05:28:13PM -0500, Robert Duncan wrote: > Greetings, > I have downloaded the .5 Beta CDROM image, burned it and get a "fault in > kernel" after the "Serial driver ... enabled" message when booting on my > 715/50. This happens with either graphics or serial console configured in > NVRAM. > > Has anyone else seen this error? I get exactly the same on my 715/75. Havn't had time to investigate yet. Richard From andreas@bawue.de Thu, 16 Nov 2000 23:42:35 +0100 Date: Thu, 16 Nov 2000 23:42:35 +0100 From: Andreas Thienemann andreas@bawue.de Subject: [parisc-linux] 250/1 doesn't boot but dumps stack Grant Grundler wrote: > > IASQ: 00000000 00000000 IAOQ: c029c264 c029c268 > > IIR: 0e681096 ISR: 00000000 IOR: 00000004 > > ORIG_R28: 00000000 > Smells like a driver bug. > Can you look up IOAQ and GR2 (c029c264 and c029c248) in System.map file? Okay, here we go (thanks for the build-tool information...) System Map output: 0xc029c264 __init_begin+264 0xc029x248 __init_begin+248 andreas From kailasr@webcash.com Wed, 15 Nov 2000 15:41:55 -0800 Date: Wed, 15 Nov 2000 15:41:55 -0800 From: Kailashnath V Rampure kailasr@webcash.com Subject: [parisc-linux] Apache package. --=====================_108207293==_.ALT Content-Type: text/plain; charset="us-ascii"; format=flowed Hi I tried to build apache_1.3.12 on HP a class server. But I have error. I have tried to check the site ftp://ftp.debian.org/debian/dists/unstable/main/binary-hppa/ I could not find one. I found some apache-doc etc. Can any on point me where I can try. Regards Kailas --=====================_108207293==_.ALT Content-Type: text/html; charset="us-ascii" Hi

I tried to build apache_1.3.12 on HP a class server. But I have error. I have tried to check the site ftp://ftp.debian.org/debian/dists/unstable/main/binary-hppa/
I could not find one. I found some apache-doc etc.

Can any on point me where I can try.
Regards
Kailas --=====================_108207293==_.ALT-- From bame@noam.fc.hp.com Wed, 15 Nov 2000 16:59:18 -0700 Date: Wed, 15 Nov 2000 16:59:18 -0700 From: Paul Bame bame@noam.fc.hp.com Subject: [parisc-linux] Apache package. = I tried to build apache_1.3.12 on HP a class server. But I have error. I = have tried to check the site = ftp://ftp.debian.org/debian/dists/unstable/main/binary-hppa/ = I could not find one. I found some apache-doc etc. We are still working on some kernel features which are required to support Apache (system 5 shared memory). -P From cary@cup.hp.com Wed, 15 Nov 2000 16:00:49 -0800 Date: Wed, 15 Nov 2000 16:00:49 -0800 From: Cary Coutant cary@cup.hp.com Subject: [parisc-linux] Help with posix_types.h >You have certainly reserved a thread register in the ABI, right? If >not, do it ASAP. On PA-RISC, the thread pointer is kept in the read-only control register CR 27. For user-thread implementations, we provided a kernel API to change the contents of the register. -cary From drepper@redhat.com 15 Nov 2000 16:04:51 -0800 Date: 15 Nov 2000 16:04:51 -0800 From: Ulrich Drepper drepper@redhat.com Subject: [parisc-linux] Help with posix_types.h Cary Coutant writes: > On PA-RISC, the thread pointer is kept in the read-only control register > CR 27. > > For user-thread implementations, we provided a kernel API to change the > contents of the register. This works fine for a 1:1 thread implementation but adds significant runtime hits for a m:n implementation. The latter is the direction we are heading. -- ---------------. ,-. 1325 Chesapeake Terrace Ulrich Drepper \ ,-------------------' \ Sunnyvale, CA 94089 USA Red Hat `--' drepper at redhat.com `------------------------ From jsm@udlkern.fc.hp.com Thu, 16 Nov 2000 02:01:12 -0700 (MST) Date: Thu, 16 Nov 2000 02:01:12 -0700 (MST) From: John Marvin jsm@udlkern.fc.hp.com Subject: Single-stepping > I've been helping Alan Modra out with kernel changes to support > single stepping for gdb. Paul Bame suggested I bounced our ideas > off you in case you (or anyone else) had any comments. I havn't > actually committed my changes yet. > I've decided to respond to the whole list, since others are now participating in the discussion. > The basic approach is to use the recovery counter to generate > a trap every instruction. The scheme is complicated because a > suspended process may or may not return to user space via an RFI. > There is no easy way to do single stepping on parisc. So any single stepping design will be complicated. > If it was suspended as a result of an interrupt then we can > simply set PSW bit R in the tasks saved registers and it will > get loaded by the RFI. On every task switch I set the > recovery counter to 0, just in case the new process is being > single-stepped. > > If a process is suspended during a syscall, then there is no > RFI on the return path to userland, and we have to handle things > differently. I have changed the syscall return path such that > it loads the recovery counter with 3 before updating the PSW > with a value from the tasks saved registers. If that PSW has > the R bit set, then the count of 3 will generate a trap on the > first instruction following the branch back to user space. > Note that PSW wasn't previously restored on the syscall return > path. > Just to be clear, it is impossible to restore the entire PSW without an RFI. So, I assume you are referring to the system mask subset of the PSW that can be manipulated by the ssm,rsm, and mtsm instructions. You mention restoring from the task's saved registers, but we currently do not save the system mask during a syscall (because it should be the same for all processes). Have you added code to do that also? If not, you are restoring from whatever the state was at the last interruption. Which in this case works (since the R bit state will be changed by another process while the debugged process is suspended, this should guarantee that the R bit state is up to date), but it seems a little ugly. In my opinion, you should just be checking a bit in the ptrace flags in the task structure, and setting the R bit with an ssm instruction based on that. > To avoid further complications of interrupts during the three > instructions when the recovery counter is decrementing, whenever > we set the R bit, we also clear the I bit to disable interrupts. Yuck, but I agree that it would be messier to have to deal with this in the interrupt handlers. Please make sure that a comment is added that explains what you are doing, and clearly documents the dependency on the number of remaining instructions before we return to user privilege level. I assume you restore the I bit in the recovery counter trap handler. I can think of alternative ways of doing this, but they are probably just as ugly (e.g. one possibility would be to do an rfi to set the L bit). > > Nullified instructions are handled by the controlling process > manually moving the childs IAOQ over the instruction without > actually setting it running, because the recovery counter isn't > decremented for nullified instructions. Does this code properly handle branches in the delay slot of another branch? (you need to make sure you are not advancing the queues by just adding 4 to each element). One concern I have about this method is that the userland debugger has to cooperate to make this design work, i.e. the single stepping is not accomplished entirely within the kernel, so we cannot easily change the design for single stepping at a later date. I wonder if it is necessary to do this. So what if we don't stop on the nullified instruction. Since it is nullified, it doesn't actually do anything, so why does the user have to see it, i.e. just let the recovery counter trap happen on the next truly executed instruction (i.e. the debugger performs a "double step" in this case). Am I missing something here? > > I need to do some more testing before committing this, but would > welcome any comments on the basic approach taken, areas I have > mis-understood, or problems with it that might not yet have > occurred to me. OK, well here are some issues that you didn't mention, so I don't know whether or not you addressed them: 1) When single stepping over a syscall, when do you actually stop the single stepping and execute the syscall? Hopefully you are not allowing single stepping after the gate instruction on the gateway page (and returning control to a non privileged debugging process). The recovery counter trap should detect when the user code gets to the gateway page. 2) Does your solution properly handle single stepping into and out of a signal handler? Note that the debugger will trap the signal as part of this process. Since the return is handled through a hidden syscall you may not have to do anything special here. Note that HP-UX does not use the recovery counter for single stepping. I made a few phone calls to various engineers to find out what the design process was, and why they chose the solution they did, but I could not find anyone who knew. Looking at the code in HP-UX it looks like someone implemented that code a long time ago, and some of the engineers who have worked on it since don't understand it, because some of the comments added since then clearly show a lack of understanding of what is really going on. Others on this list have mentioned that MPE does use the recovery counter for single stepping. Of course, MPE is not a Unix clone, so just because it could be done on MPE doesn't mean that the recovery counter can cover all cases on Unix (e.g. I have no idea how signals and syscalls are implemented on MPE). But since I have no idea why the recovery counter was not used for HP-UX, I can't say it is the wrong way to go. I can't think of anything that will definitely rule it out, I'm just a little uncomfortable with the fact that HP-UX chose not to use it. One advantage of the HP-UX method is that it completely encapsulates the single stepping inside the kernel, so it can be changed if necessary, without having to modify gdb (and having to worry about old versions of gdb). Anyway, for reference, HP-UX does single stepping by using a combination of the taken branch trap, and loading the instruction queues such that the front of the queue points to the next instruction to be single stepped and the back of the queue points to the first of two break instructions on a "break" page. It does NOT insert break instructions into the code, so it does not adversely affect execution on a SMP machine. Note that we already put a bunch of break instructions before the syscall entry point on the gateway page, so it would be easy to use our gateway page for the "break page". This way, if the single stepped instruction branches, a taken branch trap will be taken (which is important in the case where the branch nullifies its delay slot). Otherwise, the instruction will be executed and then the break instruction at the known location on the "break" page will be executed. If the single stepped instruction nullifies the next instruction, the second break instruction on the "break" page will be executed. Note that this is the short explanation. It is not as simple as it sounds. One major complication is that branches with links don't work properly with the instruction queue magic, so the link register has to be updated in the taken branch trap handler. Also branch externals won't update the space of the space queue tail properly (again, that has to be fixed in the taken branch handler). I can provide more details if the recovery counter method doesn't work out. Sincerely, John Marvin jsm@fc.hp.com From marteaut@esiee.fr Thu, 16 Nov 2000 10:04:07 +0100 Date: Thu, 16 Nov 2000 10:04:07 +0100 From: Thomas Marteau marteaut@esiee.fr Subject: [parisc-linux] nfsroot - 712/60 - RPC - help Hi Jack, > (c) Copyright 1990-1993, Hewlett-Packard Company. > All rights reserved > > Press to stop boot sequence. > Selecting a system to boot. > > Booting > palo ipl jkp2866@redtower Wed Nov 15 12:44:21 CST 2000 > 0/vmlinux 1606438 bytes @ 0x6800 > 0/palo-cmdline '0/vmlinux HOME=/ TERM=LINUX root=/dev/nfs nfsroot=192.68.1.11:/tftpboot/pancho ' Are you sure that the command line is rigth? Is your Server address is 192.-68-.1.11 Here is probably your mistake! Bye, ESIEE Team Visit http://www.esiee.fr/puffin > Kernel: partition 0 file /vmlinux > ELF32 executable > > Entry 00100000 first 00100000 n 4 > Segment 0 load 00100000 size 1097900 mediaptr 0x1000 > Segment 1 load 0020e000 size 150520 mediaptr 0x10e000 > Segment 2 load 00234000 size 55900 mediaptr 0x133000 > Segment 3 load 00244000 size 8192 mediaptr 0x141000 > branching to kernel entry point 0x00100000 > Set default PSW W bit to 0 > PDC Console Initialized > The 32-bit Kernel has started... > Enabled FP coprocessor > Free memory starts at: 0xc026e000 > start_parisc(0x504d6c,0x504d6c,0x0,0x0) > PALO command line: 'HOME=/ TERM=LINUX root=/dev/nfs nfsroot=192.68.1.11:/tftpboot/pancho ' > PALO initrd 0-0 > model 00006000 00000481 00000000 00000000 77564139 00000000 00000004 00000072 00000072 > vers 0000000a > CPUID vers 0 rev 0 > Searching for devices in PDC firmware... processor hpa 0xfffbe000 > an older box... > Found devices From rhirst@linuxcare.com Thu, 16 Nov 2000 12:00:47 +0000 Date: Thu, 16 Nov 2000 12:00:47 +0000 From: Richard Hirst rhirst@linuxcare.com Subject: Single-stepping Hi John, On Thu, Nov 16, 2000 at 02:01:12AM -0700, John Marvin wrote: > Just to be clear, it is impossible to restore the entire PSW without > an RFI. So, I assume you are referring to the system mask subset of > the PSW that can be manipulated by the ssm,rsm, and mtsm instructions. Yes, mtsm in this case. > You mention restoring from the task's saved registers, but we currently > do not save the system mask during a syscall (because it should be the > same for all processes). Have you added code to do that also? If not, Yes I have. > you are restoring from whatever the state was at the last interruption. > Which in this case works (since the R bit state will be changed > by another process while the debugged process is suspended, this should > guarantee that the R bit state is up to date), but it seems a little ugly. > In my opinion, you should just be checking a bit in the ptrace flags > in the task structure, and setting the R bit with an ssm instruction > based on that. Sounds better, I'll look in to it. > > Nullified instructions are handled by the controlling process > > manually moving the childs IAOQ over the instruction without > > actually setting it running, because the recovery counter isn't > > decremented for nullified instructions. Sorry, I worded that very badly. The code that moves the childs IAOQ on is in the kernel, invoked as a result of the controlling process calling ptrace(PTRACE_SINGLESTEP...) when the childs N bit is set. > Does this code properly handle branches in the delay slot of another > branch? (you need to make sure you are not advancing the queues by just > adding 4 to each element). One concern I have about this method is that Current code does /* Nullified, just crank over the queue. */ task_regs(child)->iaoq[0] = task_regs(child)->iaoq[1]; task_regs(child)->iasq[0] = task_regs(child)->iasq[1]; task_regs(child)->iaoq[1] = task_regs(child)->iaoq[0] + 4; Does that look right to you? > I wonder if it is necessary to do this. So what if we don't stop on the > nullified instruction. Since it is nullified, it doesn't actually do > anything, so why does the user have to see it, i.e. just let the recovery > counter trap happen on the next truly executed instruction (i.e. the > debugger performs a "double step" in this case). Am I missing something > here? I don't see why we really need to stop on a nullified instruction, but I'll wait for Alan to comment as he wrote this initially. > 1) When single stepping over a syscall, when do you actually stop the > single stepping and execute the syscall? Hopefully you are not > allowing single stepping after the gate instruction on the gateway > page (and returning control to a non privileged debugging process). > The recovery counter trap should detect when the user code gets > to the gateway page. At the moment my test harness notes IAOQ=0x100 and stops single stepping, but obviously the kernel needs to enforce that. > 2) Does your solution properly handle single stepping into and out of > a signal handler? Note that the debugger will trap the signal as part > of this process. Since the return is handled through a hidden syscall > you may not have to do anything special here. Havn't looked at signal handling yet. > Note that HP-UX does not use the recovery counter for single stepping. I Thanks for the description of how HP-UX does it. I'll stick with the recovery counter for now as it does seem to be basically working. I'll also try to ensure that it is completely encapsulated within the kernel so it is less painful to change later, if need be. Thanks, Richard From rhirst@linuxcare.com Thu, 16 Nov 2000 12:09:57 +0000 Date: Thu, 16 Nov 2000 12:09:57 +0000 From: Richard Hirst rhirst@linuxcare.com Subject: [parisc-linux] Single-stepping On Wed, Nov 15, 2000 at 02:49:02PM -0500, John David Anglin wrote: > > I've been helping Alan Modra out with kernel changes to support > > single stepping for gdb. Paul Bame suggested I bounced our ideas > > off you in case you (or anyone else) had any comments. I havn't > > actually committed my changes yet. > > > > The basic approach is to use the recovery counter to generate > > a trap every instruction. The scheme is complicated because a > > suspended process may or may not return to user space via an RFI. > > I really don't know enough to comment on the implementation choice. Why > did you decide on this approach as opposed to inserting breaks and > enabling the taken branch branch trap (T)? It would appear that the recovery > counter was intended to provide software recovery from hardware faults > in fault tolerant systems. Possibly, Grant could comment on whether > it is actually useful for this purpose. Alan Modra made those early decisions, but I gather that he went for the recovery counter because it at least appears to be rather more straightforward. Richard From jsm@udlkern.fc.hp.com Thu, 16 Nov 2000 05:44:55 -0700 (MST) Date: Thu, 16 Nov 2000 05:44:55 -0700 (MST) From: John Marvin jsm@udlkern.fc.hp.com Subject: Single-stepping Richard, > > Sorry, I worded that very badly. The code that moves the childs > IAOQ on is in the kernel, invoked as a result of the controlling > process calling ptrace(PTRACE_SINGLESTEP...) when the childs N > bit is set. > Great. > > Does this code properly handle branches in the delay slot of another > > branch? (you need to make sure you are not advancing the queues by just > > adding 4 to each element). One concern I have about this method is that > > Current code does > > /* Nullified, just crank over the queue. */ > task_regs(child)->iaoq[0] = task_regs(child)->iaoq[1]; > task_regs(child)->iasq[0] = task_regs(child)->iasq[1]; > task_regs(child)->iaoq[1] = task_regs(child)->iaoq[0] + 4; > > Does that look right to you? > Yes, that is the correct way to do it (I'll assume the duplicated line is just a cut/paste error). > > I wonder if it is necessary to do this. So what if we don't stop on the > > nullified instruction. Since it is nullified, it doesn't actually do > > anything, so why does the user have to see it, i.e. just let the recovery > > counter trap happen on the next truly executed instruction (i.e. the > > debugger performs a "double step" in this case). Am I missing something > > here? > > I don't see why we really need to stop on a nullified instruction, but > I'll wait for Alan to comment as he wrote this initially. > Given the above, i.e. that this is being handled in the kernel anyway, I guess I don't really care which way this goes. Probably it is best to do it whatever way gdb on hp-ux presents it. > > 1) When single stepping over a syscall, when do you actually stop the > > single stepping and execute the syscall? Hopefully you are not > > allowing single stepping after the gate instruction on the gateway > > page (and returning control to a non privileged debugging process). > > The recovery counter trap should detect when the user code gets > > to the gateway page. > > At the moment my test harness notes IAOQ=0x100 and stops single stepping, > but obviously the kernel needs to enforce that. > You should also be checking the space. But yes, the kernel needs to enforce this for security reasons. You should be able to do it in the recovery counter trap handler (rather than having to test for it in the syscall path, which affects all processes). > > 2) Does your solution properly handle single stepping into and out of > > a signal handler? Note that the debugger will trap the signal as part > > of this process. Since the return is handled through a hidden syscall > > you may not have to do anything special here. > > Havn't looked at signal handling yet. > I'm not sure that there is a real issue here or not. HP-UX has some code for single stepping with respect to signal handlers, but I believe it may only be necessary due to the saved state necessary as part of the iaoq manipulation. Obviously you should test this case. > > Note that HP-UX does not use the recovery counter for single stepping. I > > Thanks for the description of how HP-UX does it. I'll stick with > the recovery counter for now as it does seem to be basically working. > I'll also try to ensure that it is completely encapsulated within the kernel > so it is less painful to change later, if need be. > Sounds ok with me. And as long as there are no corner cases, it probably is the best solution, assuming we don't find another application for the recovery counter. John From rhirst@linuxcare.com Thu, 16 Nov 2000 13:20:17 +0000 Date: Thu, 16 Nov 2000 13:20:17 +0000 From: Richard Hirst rhirst@linuxcare.com Subject: Single-stepping On Thu, Nov 16, 2000 at 05:44:55AM -0700, John Marvin wrote: > > Current code does > > > > /* Nullified, just crank over the queue. */ > > task_regs(child)->iaoq[0] = task_regs(child)->iaoq[1]; > > task_regs(child)->iasq[0] = task_regs(child)->iasq[1]; > > task_regs(child)->iaoq[1] = task_regs(child)->iaoq[0] + 4; > > > > Does that look right to you? > > Yes, that is the correct way to do it (I'll assume the duplicated line > is just a cut/paste error). It's not duplicated (iaoq v. iasq). > > At the moment my test harness notes IAOQ=0x100 and stops single stepping, > > but obviously the kernel needs to enforce that. > > > You should also be checking the space. But yes, the kernel needs to enforce > this for security reasons. You should be able to do it in the recovery > counter trap handler (rather than having to test for it in the syscall > path, which affects all processes). I might come back to you on that when I've thought some more. Thanks, Richard From ian.zink@maryville.com Thu, 16 Nov 2000 09:46:18 -0600 Date: Thu, 16 Nov 2000 09:46:18 -0600 From: Ian Zink ian.zink@maryville.com Subject: [parisc-linux] I got the serial console to work... After reading some posts, I went back to trying to use to a serial console to no avail.. Then.. suddenly it hit me. Do'y. The cable I was using was straight-through not Cross-over. Now I have the 712 all booted and running Debian. Very cool, indeed. Thanks for all for your help. I think I will still work on building a STI ISO for the fun of it :) Thanks much, Ian Zink, Systems Engineer Maryville Technologies 540 Maryville Centre, Suite 300 St. Louis, MO 63141 636/519-4182 (FAX) 636/519-4141 ian.zink@maryville.com www.maryville.com From marteaut@esiee.fr Thu, 16 Nov 2000 18:18:58 +0100 Date: Thu, 16 Nov 2000 18:18:58 +0100 From: Thomas Marteau marteaut@esiee.fr Subject: [parisc-linux] The config for 712 hp boxes This is a multi-part message in MIME format. ------=_NextPart_000_00A5_01C04FF9.B01CC3A0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Hi all, Here is the config file we use to compile a new kernel from the test10 sources. We have the console with the STI and an extra term on the serial port. Also, in this mail, you have the diff between our hp_keyb.c and the official one but it gives you the ~ and the ' and others scancodes. All this works for the 712 boxes. We were forced to reboot our box to test the new kernel but before the uptime was 3 days and 4 hours during which we ran dselect and did some compiling. All the files inclosed are downloadable at http://www.esiee.fr/~puffin/code/dl.html Bye, ESIEE Team ------=_NextPart_000_00A5_01C04FF9.B01CC3A0 Content-Type: application/octet-stream; name="keyb.patch" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="keyb.patch" diff -urN linux2/drivers/char/hp_keyb.c linux/drivers/char/hp_keyb.c=0A= --- linux2/drivers/char/hp_keyb.c Thu Nov 16 17:39:03 2000=0A= +++ linux/drivers/char/hp_keyb.c Thu Nov 16 17:18:54 2000=0A= @@ -70,12 +70,12 @@=0A= #define K_F8 0x42=0A= #define K_F9 0x43=0A= #define K_F10 0x44=0A= -#define K_F11 87=0A= -#define K_F12 88=0A= +#define K_F11 0x57=0A= +#define K_F12 0x58=0A= #define K_PRNT 0x54=0A= -#define K_SCRL 70=0A= -#define K_BRK 119=0A= -#define K_AGR K_NONE=0A= +#define K_SCRL 0x46=0A= +#define K_BRK 0x77=0A= +#define K_AGR 0x29=0A= #define K_1 0x02=0A= #define K_2 0x03=0A= #define K_3 0x04=0A= @@ -89,10 +89,10 @@=0A= #define K_MINS 0x0c=0A= #define K_EQLS 0x0d=0A= #define K_BKSP 0x0e=0A= -#define K_INS 110=0A= -#define K_HOME 102=0A= -#define K_PGUP 104=0A= -#define K_NUML 69=0A= +#define K_INS 0x6e=0A= +#define K_HOME 0x66=0A= +#define K_PGUP 0x68=0A= +#define K_NUML 0x45=0A= #define KP_SLH 0x62=0A= #define KP_STR 0x37=0A= #define KP_MNS 0x4a=0A= @@ -111,13 +111,13 @@=0A= #define K_RSBK 0x1b=0A= #define K_ENTR 0x1c=0A= #define K_DEL 111=0A= -#define K_END 107=0A= -#define K_PGDN 109=0A= +#define K_END 0x6b=0A= +#define K_PGDN 0x6d=0A= #define KP_7 0x47=0A= #define KP_8 0x48=0A= #define KP_9 0x49=0A= -#define KP_PLS 118=0A= -#define K_CAPS 58=0A= +#define KP_PLS 0x4e=0A= +#define K_CAPS 0x3a=0A= #define K_A 0x1e=0A= #define K_S 0x1f=0A= #define K_D 0x20=0A= @@ -146,7 +146,7 @@=0A= #define K_DOT 0x34=0A= #define K_FSLH 0x35=0A= #define K_RSFT 0x36=0A= -#define K_UP 103 =0A= +#define K_UP 0x67=0A= #define KP_1 0x4f=0A= #define KP_2 0x50=0A= #define KP_3 0x51=0A= @@ -156,11 +156,11 @@=0A= #define K_SPCE 0x39=0A= #define K_RALT 0x64=0A= #define K_RCTL 0x61=0A= -#define K_LEFT 105=0A= -#define K_DOWN 108=0A= -#define K_RGHT 106=0A= -#define KP_0 82=0A= -#define KP_DOT 83=0A= +#define K_LEFT 0x69=0A= +#define K_DOWN 0x6c=0A= +#define K_RGHT 0x6a=0A= +#define KP_0 0x52=0A= +#define KP_DOT 0x53=0A= =0A= static unsigned char keycode_translate[256] =3D=0A= {=0A= @@ -198,7 +198,7 @@=0A= =0A= /* ----- the following code stolen from pc_keyb.c */=0A= =0A= -#ifdef CONFIG_MAGIC_SYSRQ=0A= +=0A= unsigned char pckbd_sysrq_xlate[128] =3D=0A= "\000\0331234567890-=3D\177\t" /* 0x00 - 0x0f */=0A= "qwertyuiop[]\r\000as" /* 0x10 - 0x1f */=0A= @@ -207,7 +207,6 @@=0A= "\206\207\210\211\212\000\000789-456+1" /* 0x40 - 0x4f */=0A= "230\177\000\000\213\214\000\000\000\000\000\000\000\000\000\000" /* = 0x50 - 0x5f */=0A= "\r\000/"; /* 0x60 - 0x6f */=0A= -#endif=0A= =0A= /*=0A= * Translation of escaped scancodes to keycodes.=0A= ------=_NextPart_000_00A5_01C04FF9.B01CC3A0 Content-Type: application/octet-stream; name="config" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="config" #=0A= # Automatically generated by make menuconfig: don't edit=0A= #=0A= CONFIG_PARISC=3Dy=0A= # CONFIG_UID16 is not set=0A= =0A= #=0A= # Code maturity level options=0A= #=0A= CONFIG_EXPERIMENTAL=3Dy=0A= =0A= #=0A= # General options=0A= #=0A= # CONFIG_SMP is not set=0A= # CONFIG_KWDB is not set=0A= CONFIG_GSC=3Dy=0A= CONFIG_IOMMU_CCIO=3Dy=0A= CONFIG_GSC_LASI=3Dy=0A= CONFIG_PCI=3Dy=0A= CONFIG_GSC_DINO=3Dy=0A= CONFIG_PCI_LBA=3Dy=0A= CONFIG_IOSAPIC=3Dy=0A= CONFIG_IOMMU_SBA=3Dy=0A= =0A= #=0A= # Loadable module support=0A= #=0A= # CONFIG_MODULES is not set=0A= =0A= #=0A= # General setup=0A= #=0A= CONFIG_NET=3Dy=0A= # CONFIG_SYSVIPC is not set=0A= # CONFIG_BSD_PROCESS_ACCT is not set=0A= CONFIG_SYSCTL=3Dy=0A= # CONFIG_BINFMT_SOM is not set=0A= CONFIG_BINFMT_ELF=3Dy=0A= # CONFIG_BINFMT_MISC is not set=0A= # CONFIG_BINFMT_JAVA is not set=0A= =0A= #=0A= # Parallel port support=0A= #=0A= CONFIG_PARPORT=3Dy=0A= # CONFIG_PARPORT_PC is not set=0A= # CONFIG_PARPORT_GSC is not set=0A= # CONFIG_PARPORT_OTHER is not set=0A= # CONFIG_PARPORT_1284 is not set=0A= =0A= #=0A= # Block devices=0A= #=0A= # CONFIG_BLK_DEV_FD is not set=0A= # CONFIG_BLK_DEV_XD is not set=0A= # CONFIG_PARIDE is not set=0A= # CONFIG_BLK_CPQ_DA is not set=0A= # CONFIG_BLK_CPQ_CISS_DA is not set=0A= # CONFIG_BLK_DEV_DAC960 is not set=0A= # CONFIG_BLK_DEV_LOOP is not set=0A= # CONFIG_BLK_DEV_NBD is not set=0A= CONFIG_BLK_DEV_RAM=3Dy=0A= CONFIG_BLK_DEV_RAM_SIZE=3D4096=0A= CONFIG_BLK_DEV_INITRD=3Dy=0A= =0A= #=0A= # Networking options=0A= #=0A= # CONFIG_PACKET is not set=0A= # CONFIG_NETLINK is not set=0A= # CONFIG_NETFILTER is not set=0A= # CONFIG_FILTER is not set=0A= # CONFIG_UNIX is not set=0A= CONFIG_INET=3Dy=0A= # CONFIG_IP_MULTICAST is not set=0A= # CONFIG_IP_ADVANCED_ROUTER is not set=0A= CONFIG_IP_PNP=3Dy=0A= # CONFIG_IP_PNP_BOOTP is not set=0A= # CONFIG_IP_PNP_RARP is not set=0A= # CONFIG_NET_IPIP is not set=0A= # CONFIG_NET_IPGRE is not set=0A= # CONFIG_INET_ECN is not set=0A= # CONFIG_SYN_COOKIES is not set=0A= # CONFIG_IPV6 is not set=0A= # CONFIG_KHTTPD is not set=0A= # CONFIG_ATM is not set=0A= # CONFIG_IPX is not set=0A= # CONFIG_ATALK is not set=0A= # CONFIG_DECNET is not set=0A= # CONFIG_BRIDGE is not set=0A= # CONFIG_X25 is not set=0A= # CONFIG_LAPB is not set=0A= # CONFIG_LLC is not set=0A= # CONFIG_NET_DIVERT is not set=0A= # CONFIG_ECONET is not set=0A= # CONFIG_WAN_ROUTER is not set=0A= # CONFIG_NET_FASTROUTE is not set=0A= # CONFIG_NET_HW_FLOWCONTROL is not set=0A= =0A= #=0A= # QoS and/or fair queueing=0A= #=0A= # CONFIG_NET_SCHED is not set=0A= =0A= #=0A= # SCSI support=0A= #=0A= CONFIG_SCSI=3Dy=0A= CONFIG_BLK_DEV_SD=3Dy=0A= CONFIG_SD_EXTRA_DEVS=3D40=0A= # CONFIG_CHR_DEV_ST is not set=0A= # CONFIG_BLK_DEV_SR is not set=0A= CONFIG_CHR_DEV_SG=3Dy=0A= # CONFIG_SCSI_MULTI_LUN is not set=0A= # CONFIG_SCSI_CONSTANTS is not set=0A= =0A= #=0A= # SCSI low-level drivers=0A= #=0A= CONFIG_SCSI_LASI=3Dy=0A= CONFIG_SCSI_ZALON=3Dy=0A= CONFIG_SCSI_SYM53C8XX=3Dy=0A= CONFIG_SCSI_NCR53C8XX_DEFAULT_TAGS=3D8=0A= CONFIG_SCSI_NCR53C8XX_MAX_TAGS=3D32=0A= CONFIG_SCSI_NCR53C8XX_SYNC=3D20=0A= # CONFIG_SCSI_NCR53C8XX_PROFILE is not set=0A= # CONFIG_SCSI_NCR53C8XX_IOMAPPED is not set=0A= =0A= #=0A= # Network device support=0A= #=0A= CONFIG_NETDEVICES=3Dy=0A= CONFIG_LASI_82596=3Dy=0A= =0A= #=0A= # ARCnet devices=0A= #=0A= # CONFIG_ARCNET is not set=0A= # CONFIG_DUMMY is not set=0A= # CONFIG_BONDING is not set=0A= # CONFIG_EQUALIZER is not set=0A= # CONFIG_TUN is not set=0A= # CONFIG_NET_SB1000 is not set=0A= =0A= #=0A= # Ethernet (10 or 100Mbit)=0A= #=0A= CONFIG_NET_ETHERNET=3Dy=0A= # CONFIG_NET_VENDOR_3COM is not set=0A= # CONFIG_LANCE is not set=0A= # CONFIG_NET_VENDOR_SMC is not set=0A= # CONFIG_NET_VENDOR_RACAL is not set=0A= # CONFIG_AT1700 is not set=0A= # CONFIG_DEPCA is not set=0A= # CONFIG_HP100 is not set=0A= # CONFIG_NET_ISA is not set=0A= CONFIG_NET_PCI=3Dy=0A= # CONFIG_PCNET32 is not set=0A= # CONFIG_ADAPTEC_STARFIRE is not set=0A= # CONFIG_AC3200 is not set=0A= # CONFIG_APRICOT is not set=0A= # CONFIG_CS89x0 is not set=0A= # CONFIG_DE4X5 is not set=0A= CONFIG_TULIP=3Dy=0A= # CONFIG_DGRS is not set=0A= # CONFIG_DM9102 is not set=0A= # CONFIG_EEPRO100 is not set=0A= # CONFIG_LNE390 is not set=0A= # CONFIG_NATSEMI is not set=0A= # CONFIG_NE2K_PCI is not set=0A= # CONFIG_NE3210 is not set=0A= # CONFIG_ES3210 is not set=0A= # CONFIG_RTL8129 is not set=0A= # CONFIG_8139TOO is not set=0A= # CONFIG_SIS900 is not set=0A= # CONFIG_EPIC100 is not set=0A= # CONFIG_SUNDANCE is not set=0A= # CONFIG_TLAN is not set=0A= # CONFIG_VIA_RHINE is not set=0A= # CONFIG_WINBOND_840 is not set=0A= # CONFIG_NET_POCKET is not set=0A= =0A= #=0A= # Ethernet (1000 Mbit)=0A= #=0A= # CONFIG_ACENIC is not set=0A= # CONFIG_HAMACHI is not set=0A= # CONFIG_YELLOWFIN is not set=0A= # CONFIG_SK98LIN is not set=0A= # CONFIG_FDDI is not set=0A= # CONFIG_HIPPI is not set=0A= # CONFIG_PLIP is not set=0A= # CONFIG_PPP is not set=0A= # CONFIG_SLIP is not set=0A= =0A= #=0A= # Wireless LAN (non-hamradio)=0A= #=0A= # CONFIG_NET_RADIO is not set=0A= =0A= #=0A= # Token Ring devices=0A= #=0A= # CONFIG_TR is not set=0A= # CONFIG_NET_FC is not set=0A= # CONFIG_RCPCI is not set=0A= # CONFIG_SHAPER is not set=0A= =0A= #=0A= # Wan interfaces=0A= #=0A= # CONFIG_WAN is not set=0A= =0A= #=0A= # Character devices=0A= #=0A= CONFIG_VT=3Dy=0A= CONFIG_VT_CONSOLE=3Dy=0A= CONFIG_GSC_PS2=3Dy=0A= # CONFIG_HIL is not set=0A= CONFIG_SERIAL=3Dy=0A= # CONFIG_SERIAL_CONSOLE is not set=0A= CONFIG_SERIAL_GSC=3Dy=0A= # CONFIG_SERIAL_EXTENDED is not set=0A= # CONFIG_SERIAL_NONSTANDARD is not set=0A= CONFIG_UNIX98_PTYS=3Dy=0A= CONFIG_UNIX98_PTY_COUNT=3D256=0A= # CONFIG_PRINTER is not set=0A= # CONFIG_PPDEV is not set=0A= =0A= #=0A= # I2C support=0A= #=0A= # CONFIG_I2C is not set=0A= =0A= #=0A= # Mice=0A= #=0A= # CONFIG_BUSMOUSE is not set=0A= # CONFIG_MOUSE is not set=0A= =0A= #=0A= # Joysticks=0A= #=0A= # CONFIG_JOYSTICK is not set=0A= # CONFIG_QIC02_TAPE is not set=0A= =0A= #=0A= # Watchdog Cards=0A= #=0A= # CONFIG_WATCHDOG is not set=0A= CONFIG_GENRTC=3Dy=0A= # CONFIG_INTEL_RNG is not set=0A= # CONFIG_NVRAM is not set=0A= # CONFIG_RTC is not set=0A= # CONFIG_DTLK is not set=0A= # CONFIG_R3964 is not set=0A= # CONFIG_APPLICOM is not set=0A= =0A= #=0A= # Ftape, the floppy tape device driver=0A= #=0A= # CONFIG_FTAPE is not set=0A= # CONFIG_AGP is not set=0A= # CONFIG_DRM is not set=0A= =0A= #=0A= # File systems=0A= #=0A= # CONFIG_QUOTA is not set=0A= # CONFIG_AUTOFS_FS is not set=0A= # CONFIG_AUTOFS4_FS is not set=0A= # CONFIG_ADFS_FS is not set=0A= # CONFIG_ADFS_FS_RW is not set=0A= # CONFIG_AFFS_FS is not set=0A= # CONFIG_HFS_FS is not set=0A= # CONFIG_BFS_FS is not set=0A= # CONFIG_FAT_FS is not set=0A= # CONFIG_MSDOS_FS is not set=0A= # CONFIG_UMSDOS_FS is not set=0A= # CONFIG_VFAT_FS is not set=0A= # CONFIG_EFS_FS is not set=0A= # CONFIG_JFFS_FS is not set=0A= # CONFIG_CRAMFS is not set=0A= # CONFIG_RAMFS is not set=0A= CONFIG_ISO9660_FS=3Dy=0A= # CONFIG_JOLIET is not set=0A= # CONFIG_MINIX_FS is not set=0A= # CONFIG_NTFS_FS is not set=0A= # CONFIG_NTFS_RW is not set=0A= # CONFIG_HPFS_FS is not set=0A= CONFIG_PROC_FS=3Dy=0A= # CONFIG_DEVFS_FS is not set=0A= # CONFIG_DEVFS_MOUNT is not set=0A= # CONFIG_DEVFS_DEBUG is not set=0A= # CONFIG_DEVPTS_FS is not set=0A= # CONFIG_QNX4FS_FS is not set=0A= # CONFIG_QNX4FS_RW is not set=0A= # CONFIG_ROMFS_FS is not set=0A= CONFIG_EXT2_FS=3Dy=0A= # CONFIG_SYSV_FS is not set=0A= # CONFIG_SYSV_FS_WRITE is not set=0A= # CONFIG_UDF_FS is not set=0A= # CONFIG_UDF_RW is not set=0A= # CONFIG_UFS_FS is not set=0A= # CONFIG_UFS_FS_WRITE is not set=0A= =0A= #=0A= # Network File Systems=0A= #=0A= # CONFIG_CODA_FS is not set=0A= CONFIG_NFS_FS=3Dy=0A= # CONFIG_NFS_V3 is not set=0A= CONFIG_ROOT_NFS=3Dy=0A= # CONFIG_NFSD is not set=0A= # CONFIG_NFSD_V3 is not set=0A= CONFIG_SUNRPC=3Dy=0A= CONFIG_LOCKD=3Dy=0A= # CONFIG_SMB_FS is not set=0A= # CONFIG_NCP_FS is not set=0A= # CONFIG_NCPFS_PACKET_SIGNING is not set=0A= # CONFIG_NCPFS_IOCTL_LOCKING is not set=0A= # CONFIG_NCPFS_STRONG is not set=0A= # CONFIG_NCPFS_NFS_NS is not set=0A= # CONFIG_NCPFS_OS2_NS is not set=0A= # CONFIG_NCPFS_SMALLDOS is not set=0A= # CONFIG_NCPFS_MOUNT_SUBDIR is not set=0A= # CONFIG_NCPFS_NDS_DOMAINS is not set=0A= # CONFIG_NCPFS_NLS is not set=0A= # CONFIG_NCPFS_EXTRAS is not set=0A= =0A= #=0A= # Partition Types=0A= #=0A= # CONFIG_PARTITION_ADVANCED is not set=0A= CONFIG_MSDOS_PARTITION=3Dy=0A= # CONFIG_NLS is not set=0A= =0A= #=0A= # Sound Drivers=0A= #=0A= # CONFIG_SOUND is not set=0A= =0A= #=0A= # Console drivers=0A= #=0A= =0A= #=0A= # Frame-buffer support=0A= #=0A= # CONFIG_FB is not set=0A= CONFIG_STI_CONSOLE=3Dy=0A= CONFIG_DUMMY_CONSOLE=3Dy=0A= =0A= #=0A= # Kernel hacking=0A= #=0A= CONFIG_MAGIC_SYSRQ=3Dy=0A= ------=_NextPart_000_00A5_01C04FF9.B01CC3A0-- From grundler@cup.hp.com Thu, 16 Nov 2000 10:10:23 -0800 Date: Thu, 16 Nov 2000 10:10:23 -0800 From: Grant Grundler grundler@cup.hp.com Subject: [parisc-linux] The config for 712 hp boxes "Thomas Marteau" wrote: > Hi all, > > Here is the config file we use to compile a new kernel from the test10 > sources. We have the console with the STI and an extra term on the serial > port. Thomas - excellent - thanks! > Also, in this mail, you have the diff between our hp_keyb.c and the official > one but it gives you the ~ and the ' and others scancodes. I noticed this mail was directed to me - but I can't take ownership of this code. I have too many other things going on. Helge - can you commit this fix too? thanks, grant Grant Grundler Unix Systems Enablement Lab +1.408.447.7253 From deller@gmx.de Thu, 16 Nov 2000 19:25:49 +0100 Date: Thu, 16 Nov 2000 19:25:49 +0100 From: Helge Deller deller@gmx.de Subject: [parisc-linux] The config for 712 hp boxes On Thursday 16 November 2000 19:10, Grant Grundler wrote: > "Thomas Marteau" wrote: > > Hi all, > > > > Here is the config file we use to compile a new kernel from the test10 > > sources. We have the console with the STI and an extra term on the serial > > port. > > Thomas - excellent - thanks! > > > Also, in this mail, you have the diff between our hp_keyb.c and the official > > one but it gives you the ~ and the ' and others scancodes. > > I noticed this mail was directed to me - but I can't take ownership > of this code. I have too many other things going on. > > Helge - can you commit this fix too? Ok. I will test & evtl. commit it today. > > thanks, > grant > > Grant Grundler > Unix Systems Enablement Lab > +1.408.447.7253 > > --------------------------------------------------------------------------- > To unsubscribe: send e-mail to parisc-linux-request@thepuffingroup.com with > `unsubscribe' as the subject. From frank_rowand@mvista.com Thu, 16 Nov 2000 11:00:48 -0800 Date: Thu, 16 Nov 2000 11:00:48 -0800 From: Frank Rowand frank_rowand@mvista.com Subject: Single-stepping John Marvin wrote: > > Richard, > > > > > Sorry, I worded that very badly. The code that moves the childs > > IAOQ on is in the kernel, invoked as a result of the controlling > > process calling ptrace(PTRACE_SINGLESTEP...) when the childs N > > bit is set. > > > > Great. > > > > Does this code properly handle branches in the delay slot of another > > > branch? (you need to make sure you are not advancing the queues by just > > > adding 4 to each element). One concern I have about this method is that > > > > Current code does > > > > /* Nullified, just crank over the queue. */ > > task_regs(child)->iaoq[0] = task_regs(child)->iaoq[1]; > > task_regs(child)->iasq[0] = task_regs(child)->iasq[1]; > > task_regs(child)->iaoq[1] = task_regs(child)->iaoq[0] + 4; > > > > Does that look right to you? > > > > Yes, that is the correct way to do it (I'll assume the duplicated line > is just a cut/paste error). If iaoq[0] contains a branch, iaoq[1] is in the delay slot. The instruction executed after iaoq[1] would then typically _not_ be iaoq[0] + 4 (the next instruction would be the target of the branch at iaoq[0]). > Sounds ok with me. And as long as there are no corner cases, it probably > is the best solution, assuming we don't find another application for > the recovery counter. The recovery counter is very useful for performance measurement tools to understand the cycles per instruction of a code path. (Using the recovery counter for the debugger doesn't preclude using it for performance tools - you just can't easily use it for both purposes at the same instant in time.) > John -Frank -- Frank Rowand MontaVista Software, Inc From rhirst@linuxcare.com Thu, 16 Nov 2000 20:28:42 +0000 Date: Thu, 16 Nov 2000 20:28:42 +0000 From: Richard Hirst rhirst@linuxcare.com Subject: Single-stepping On Thu, Nov 16, 2000 at 11:00:48AM -0800, Frank Rowand wrote: > John Marvin wrote: > > > > Does this code properly handle branches in the delay slot of another > > > > branch? (you need to make sure you are not advancing the queues by just > > > > adding 4 to each element). One concern I have about this method is that > > > > > > Current code does > > > > > > /* Nullified, just crank over the queue. */ > > > task_regs(child)->iaoq[0] = task_regs(child)->iaoq[1]; > > > task_regs(child)->iasq[0] = task_regs(child)->iasq[1]; > > > task_regs(child)->iaoq[1] = task_regs(child)->iaoq[0] + 4; > > > > > > Does that look right to you? > > > > > > > Yes, that is the correct way to do it (I'll assume the duplicated line > > is just a cut/paste error). > > If iaoq[0] contains a branch, iaoq[1] is in the delay slot. The instruction > executed after iaoq[1] would then typically _not_ be iaoq[0] + 4 (the next > instruction would be the target of the branch at iaoq[0]). But the above code is only executed if the current instruction is nullified. In your example, the branch in iaoq[0] would be nullified and therefore never taken. Richard From deller@gmx.de Thu, 16 Nov 2000 22:28:50 +0100 Date: Thu, 16 Nov 2000 22:28:50 +0100 From: Helge Deller deller@gmx.de Subject: [parisc-linux] The config for 712 hp boxes On Thursday 16 November 2000 18:18, Thomas Marteau wrote: > Hi all, > > [....] > Also, in this mail, you have the diff between our hp_keyb.c and the official > one but it gives you the ~ and the ' and others scancodes. > [....] Hi ESIEE-Team ! Thanks for your patch ! I committed your patch into CVS and just tweaked it a little for CONFIG_MAGIC_SYSRQ. I hope this is ok for you ? If your time permits, I would like to ask, if you maybe also want to look at getting the CAPS-Lock-, Scroll-Lock- & Num-Lock-LED's working ? Furthermore you mention in your project-history on your homepage something about "keyboard and soundchip problems" (Oct. 24). I'm asking just out of curiousity: Did you thought about programming the on-board sound-chips (which I believe would be a hard job.) ? > Bye, > ESIEE Team Best regards, Helge Deller. From taggart@carmen.fc.hp.com Thu, 16 Nov 2000 19:25:26 -0700 Date: Thu, 16 Nov 2000 19:25:26 -0700 From: Matt Taggart taggart@carmen.fc.hp.com Subject: [parisc-linux] glibc merged to 2.2 Today Paul Bame and I merged/updated the puffin.external.hp.com glibc cvs to glibc 2.2. After the merge I cleaned up the differences between our cvs and 2.2, mostly comment differences and formatting changes. With the exception of the setjmp problem mentioned in, http://puffin.external.hp.com/mailing-lists/parisc-linux/2000/11-Nov/0091.html and the fact that we have/need newer "scripts/config.guess" and "scripts/config.sub", we are completely sync'ed up with glibc 2.2. -- Matt Taggart taggart@fc.hp.com From deller@gmx.de Fri, 17 Nov 2000 15:34:09 +0100 Date: Fri, 17 Nov 2000 15:34:09 +0100 From: Helge Deller deller@gmx.de Subject: [parisc-linux] The config for 712 hp boxes [CC'ed the list, so maybe someone else can comment too....] On Friday 17 November 2000 11:45, Thomas Marteau wrote: > Hi Helge, Hi, > > > ----- Original Message ----- > From: Helge Deller > To: Thomas Marteau > Cc: > Sent: Thursday, November 16, 2000 10:28 PM > Subject: Re: [parisc-linux] The config for 712 hp boxes > > > > On Thursday 16 November 2000 18:18, Thomas Marteau wrote: > > > Hi all, > > > > > > [....] > > > Also, in this mail, you have the diff between our hp_keyb.c and the > official > > > one but it gives you the ~ and the ' and others scancodes. > > > [....] > > > > Hi ESIEE-Team ! > > > > Thanks for your patch ! > > > > I committed your patch into CVS and just tweaked it a little for > > CONFIG_MAGIC_SYSRQ. I hope this is ok for you ? > We didn't really understand why pckbd_sysrq_xlate was here for. > If you can explain to us, it will be fine. The best documentation you can find is in linux/Documentation/sysrq.txt. The copy of pckbd_sysrq_xlate[] is a simple implementation of keyboard-scancodes to chars, which is used by drivers/char/keyboard.c to call handle_sysrq() from /drivers/char/sysrq.c. This means, that you can press Alt-PrintScr (=> SysRQ) and a char at the keyboard simultaniously and your machine for example syncs the disks, mounts all discs read-only or reboots your machine immediately. > > If your time permits, I would like to ask, if you maybe also want to look > at > > getting the CAPS-Lock-, Scroll-Lock- & Num-Lock-LED's working ? > Normally, you can see yours leds switching on/off but we did not init them. > So they are like boot admin switch them... ^^^^^^^ ^^^^^ ^^^ Sorry ? > But we would like to know how and where we have to init them > because we know how to. We have made test and it was working... I'm not sure, but I think you should check the code in lasikbd_leds() in hp_psaux.c. The initialization should maybe be done in the same file in the function lasi_ps2_register() before calling register_kbd_ops(). > > > Furthermore you mention in your project-history on your homepage something > > about "keyboard and soundchip problems" (Oct. 24). I'm asking just out of > > curiousity: Did you thought about programming the on-board sound-chips > (which > > I believe would be a hard job.) ? > Yes, it is in our internal todo list, if we have time to. Because we look at > it with Thierry, we saw that, for LASI, > you have an interface and then the chip to configure. But it is very > interesting... Yes it is, and it would be great if you worked on that too ! > > Also, we want to rule the power leds but they are different if the box is > 712 or B132 or ... So our question is how to implement > this kind of initialsation and deinitialisation in a linux kernel and in a > second time, how to do for differents kind of boxes. As far as I know / have heard, there are only two types of LED's (but I may be wrong here !). One is where the LED's are organized in a row on the front panel (as my local machines here), and the other one, where you have (LED/)LCD-Numbers on your front panel ? They differ how to be accessed and where the controlling registers are located. One method to distiguish them is maybe to place the special initialisation code into drivers/gsc/lasi.c and asp.c, depending on the machine and which method needs to be used. Since I don't have any real documentation or knowledge of the programming of the LEDs (beside of the PDC-calls I placed into setup.c), maybe someone else can better comment on that or give some documentation ? > > Thanks for your answers, Helge > Bye, > ESIEE Team Best regards, Helge Deller. From Arnaud.ATOCH@oecd.org Fri, 17 Nov 2000 16:30:42 +0100 Date: Fri, 17 Nov 2000 16:30:42 +0100 From: Arnaud.ATOCH@oecd.org Arnaud.ATOCH@oecd.org Subject: [parisc-linux] Booting 712 with CD 0.5 Is the following output the normal behavior of Linux-PARisc on a 712/100 ? kmem_create: Forcing size word alignment - nfs_fh kernel BUG at pci-dma.c:391! kernel BUG at pci-dma.c:400! kernel BUG at pci-dma.c:391! kernel BUG at pci-dma.c:400! kernel BUG at pci-dma.c:391! kernel BUG at pci-dma.c:400! VFS: Disk change detected on device sr(11,0) kernel BUG at pci-dma.c:391! kernel BUG at pci-dma.c:400! kernel BUG at pci-dma.c:391! kernel BUG at pci-dma.c:400! kernel BUG at pci-dma.c:391! kernel BUG at pci-dma.c:400! ISO 9660 Extensions: RRIP_1991A VFS: Mounted root (iso9660 filesystem) readonly. INIT: version 2.78 booting INIT: Entering runlevel: 2 Setting up /tmp ramdisk4096+0 records in 4096+0 records out mke2fs 1.19, 13-Jul-2000 for EXT2 FS 0.5b, 95/08/09 Filesystem label= OS type: Linux Block size=1024 (log=0) Fragment size=1024 (log=0) 1024 inodes, 4096 blocks 0 blocks (0.00%) reserved for the super user First data block=1 1 block group 8192 blocks per group, 8192 fragments per group 1024 inodes per group Writing inode tables: done Writing superblocks and filesystem accounting information: done INIT: Id "T0" respawni INIT: no more processe From rhirst@linuxcare.com Fri, 17 Nov 2000 15:39:55 +0000 Date: Fri, 17 Nov 2000 15:39:55 +0000 From: Richard Hirst rhirst@linuxcare.com Subject: [parisc-linux] SEGV signal handling bug (dynamic linking) Hi, Don't know if anyone expects this to work yet or not, but: ------------------------- cut ----------------------------- #include #include #include #include #include #include #include #include #include char *mem; void sig_handler(int sig) { int res; printf("Trapped!!!\n"); res = mprotect(mem, 4096, PROT_READ|PROT_WRITE); if (res < 0) { perror("mprotect"); exit(1); } } void install_handlers(void) { struct sigaction act; memset(&act, 0, sizeof(act)); act.sa_handler = sig_handler; sigaction(SIGSEGV, &act, NULL); } int main(int argc, char **argv) { int res; mem = malloc(8192); if (mem == NULL) { perror("malloc"); exit(1); } mem = (char *)(((int)mem + 4095) & ~0x0fff); res = mprotect(mem, 4096, PROT_READ); if (res < 0) { perror("mprotect"); exit(1); } install_handlers(); write(1, "Going\n", 6); mem[24] = 17; write(1, "Gone\n", 5); return 0; } ------------------------- cut ----------------------------- generates: Going Bus error plus the following on the console: do_page_fault() pid=167 command='ch' YZrvWESTHLNXBCVMcbcbcbcbOGFRQPDI PSW: 00000000000001001111111100001011 r0-3 00000000 fffff000 0000166f 00002944 r4-7 40138c38 2001fd8c 00002852 00000001 r8-11 00002862 0008b010 0009c290 0009cbf0 r12-15 00000000 00000000 0009cb50 00000000 r16-19 00000000 00000001 0000b71b 00000011 r20-23 00004000 40041fcc 40041fcc 00000008 r24-27 00000006 00001000 00000001 0000280c r28-31 00000006 00000020 20020140 40041fd7 sr0-4 00000000 00000003 00000000 0000000a sr4-8 0000000a 0000000a 0000000a 0000000a IASQ: 0000000a 0000000a IAOQ: 0000167b 0000167f IIR: 6293002e ISR: 0000000a IOR: 00004017 ORIG_R28: 00002880 !!die_if_kernel: ch(167): Unaligned data reference 28 YZrvWESTHLNXBCVMcbcbcbcbOGFRQPDI PSW: 00000000000011001111111100001011 r0-3 00000000 fffff000 20020140 00002944 r4-7 40138c38 2001fd8c 00002852 00000001 r8-11 00002862 0008b010 0009c290 0009cbf0 r12-15 00000000 00000000 0009cb50 00000000 r16-19 00000000 00000001 0000b71b 00000000 r20-23 0000289f 40041fcc 40041fcc 00000008 r24-27 200201d0 20020150 0000000b 0000280c r28-31 00000006 00000020 200203c0 40041fd7 sr0-4 00000000 00000003 00000000 0000000a sr4-8 0000000a 0000000a 0000000a 0000000a IASQ: 0000000a 0000000a IAOQ: 0000289b 0000289b IIR: 0e801096 ISR: 0000000a IOR: 0000289f ORIG_R28: 00002880 The first do_page_fault() is fine, it is the 'mem[24] = 17' line, but the second isn't. The corresponding code is at the end of .plt: 2898: 0e 80 10 96 ldw 0(sr0,r20),r22 289c: ea c0 c0 00 bv r0(r22) 28a0: 0e 88 10 95 ldw 4(sr0,r20),r21 28a4: ea 9f 1f dd b,l 2898 <__DTOR_END__+0x74>,r20 28a8: d6 80 1c 1e depwi 0,31,2,r20 28ac: 00 c0 ff ee # c0ffee 28b0: de ad be ef #deadbeef However, if I make it statically linked, it works fine, giving: Going Trapped!!! Gone Richard From bri@mojo.calyx.net Fri, 17 Nov 2000 10:49:22 -0500 (EST) Date: Fri, 17 Nov 2000 10:49:22 -0500 (EST) From: Brian S. Julin bri@mojo.calyx.net Subject: [parisc-linux] debian archive beware libpam JFYI to save other people some time. Before firing up "apt-get upgrade" you'll be best off putting a hold on all the libpam packages, as the 0.72-12 version on ftp.us.debian.org fails on a bad symbol in libpam-misc, which locks you out of the box except if you boot single. -- Brian S. Julin From grundler@cup.hp.com Fri, 17 Nov 2000 08:38:24 -0800 Date: Fri, 17 Nov 2000 08:38:24 -0800 From: Grant Grundler grundler@cup.hp.com Subject: [parisc-linux] Booting 712 with CD 0.5 Arnaud.ATOCH@oecd.org wrote: > Is the following output the normal behavior of Linux-PARisc on a 712/100 ? > > kmem_create: Forcing size word alignment - nfs_fh > kernel BUG at pci-dma.c:391! > kernel BUG at pci-dma.c:400! The bug is real. A driver is calling pci_map_single() and pci_unmap_single() without specifying which direction the DMA is going. Cache flushing on 712 (PCXL) systems needs to know. I'll assume it's the SCSI driver since it looks like we are talking to a SCSI CD-ROM. grant Grant Grundler Unix Systems Enablement Lab +1.408.447.7253 From drepper@redhat.com 17 Nov 2000 09:09:10 -0800 Date: 17 Nov 2000 09:09:10 -0800 From: Ulrich Drepper drepper@redhat.com Subject: [parisc-linux] SEGV signal handling bug (dynamic linking) Richard Hirst writes: > mem = malloc(8192); > if (mem == NULL) { > perror("malloc"); > exit(1); > } > mem = (char *)(((int)mem + 4095) & ~0x0fff); > res = mprotect(mem, 4096, PROT_READ); Read the Unix standard: The behavior of this function is unspecified if the mapping was not established by a call to mmap(). -- ---------------. ,-. 1325 Chesapeake Terrace Ulrich Drepper \ ,-------------------' \ Sunnyvale, CA 94089 USA Red Hat `--' drepper at redhat.com `------------------------ From grundler@cup.hp.com Fri, 17 Nov 2000 09:09:04 -0800 (PST) Date: Fri, 17 Nov 2000 09:09:04 -0800 (PST) From: Grant Grundler grundler@cup.hp.com Subject: [parisc-linux] pci-dma.c BUG(391/400) PATCH Hi all, The following patch tries to point a finger at the offender rather than just call attention to a problem in the service. I don't have a PCXL/L2 machine setup right now. Could someone test commit this patch for me? thanks, grant grundler <505>cvs diff arch/parisc/kernel/pci-dma.c Index: arch/parisc/kernel/pci-dma.c =================================================================== RCS file: /home/cvs/parisc/linux/arch/parisc/kernel/pci-dma.c,v retrieving revision 1.16 diff -u -p -r1.16 pci-dma.c --- pci-dma.c 2000/11/08 06:20:27 1.16 +++ pci-dma.c 2000/11/17 17:04:22 @@ -387,8 +387,10 @@ static void pa11_dma_free_consistent (st static dma_addr_t pa11_dma_map_single(struct pci_dev *dev, void *addr, size_t size, int direction) { - if (direction == PCI_DMA_NONE) - BUG(); + if (direction == PCI_DMA_NONE) { + printk(KERN_ERR "pa11_dma_map_single(PCI_DMA_NONE) called by %p\n", __builtin_return_address(0)); + BUG(); + } flush_kernel_dcache_range((unsigned long) addr, size); return virt_to_phys(addr); @@ -396,8 +398,10 @@ static dma_addr_t pa11_dma_map_single(st static void pa11_dma_unmap_single(struct pci_dev *dev, dma_addr_t dma_handle, size_t size, int direction) { - if (direction == PCI_DMA_NONE) - BUG(); + if (direction == PCI_DMA_NONE) { + printk(KERN_ERR "pa11_dma_unmap_single(PCI_DMA_NONE) called by %p\n", __builtin_return_address(0)); + BUG(); + } if (direction == PCI_DMA_TODEVICE) return; From Arnaud.ATOCH@oecd.org Fri, 17 Nov 2000 18:10:52 +0100 Date: Fri, 17 Nov 2000 18:10:52 +0100 From: Arnaud.ATOCH@oecd.org Arnaud.ATOCH@oecd.org Subject: [parisc-linux] Booting 712 with CD 0.5 Thanks for the enlightment. Should I try a new CD-ROM or should I wait untill next ISO image is created ? IS the shutdown also due to this bug ? Setting up /tmp ramdisk4096+0 records in 4096+0 records out mke2fs 1.19, 13-Jul-2000 for EXT2 FS 0.5b, 95/08/09 Filesystem label= OS type: Linux Block size=1024 (log=0) Fragment size=1024 (log=0) 1024 inodes, 4096 blocks 0 blocks (0.00%) reserved for the super user First data block=1 1 block group 8192 blocks per group, 8192 fragments per group 1024 inodes per group Writing inode tables: done Writing superblocks and filesystem accounting information: done INIT: Id "T0" respawni INIT: no more processe -----Original Message----- From: Grant Grundler [mailto:grundler@cup.hp.com] Sent: Friday, November 17, 2000 17:38 To: Arnaud.ATOCH@oecd.org Cc: parisc-linux@puffin.external.hp.com Subject: Re: [parisc-linux] Booting 712 with CD 0.5 Arnaud.ATOCH@oecd.org wrote: > Is the following output the normal behavior of Linux-PARisc on a 712/100 ? > > kmem_create: Forcing size word alignment - nfs_fh > kernel BUG at pci-dma.c:391! > kernel BUG at pci-dma.c:400! The bug is real. A driver is calling pci_map_single() and pci_unmap_single() without specifying which direction the DMA is going. Cache flushing on 712 (PCXL) systems needs to know. I'll assume it's the SCSI driver since it looks like we are talking to a SCSI CD-ROM. grant Grant Grundler Unix Systems Enablement Lab +1.408.447.7253 From rhirst@linuxcare.com Fri, 17 Nov 2000 17:38:18 +0000 Date: Fri, 17 Nov 2000 17:38:18 +0000 From: Richard Hirst rhirst@linuxcare.com Subject: [parisc-linux] SEGV signal handling bug (dynamic linking) On Fri, Nov 17, 2000 at 09:09:10AM -0800, Ulrich Drepper wrote: > Richard Hirst writes: > > > mem = malloc(8192); > > if (mem == NULL) { > > perror("malloc"); > > exit(1); > > } > > mem = (char *)(((int)mem + 4095) & ~0x0fff); > > res = mprotect(mem, 4096, PROT_READ); > > Read the Unix standard: > > The behavior of this function is unspecified if the mapping was not > established by a call to mmap(). Yeh, but it works on m68k and i386, and works on hppa if statically linked. And the code is in an example on the mprotect man page on my Mandrake7 box. Richard From drepper@redhat.com 17 Nov 2000 10:06:21 -0800 Date: 17 Nov 2000 10:06:21 -0800 From: Ulrich Drepper drepper@redhat.com Subject: [parisc-linux] SEGV signal handling bug (dynamic linking) Richard Hirst writes: > Yeh, but it works on m68k and i386, and works on hppa if statically > linked. And the code is in an example on the mprotect man page on > my Mandrake7 box. Then shoot the guy who wrote the man page. It's wrong and will never reliably work. -- ---------------. ,-. 1325 Chesapeake Terrace Ulrich Drepper \ ,-------------------' \ Sunnyvale, CA 94089 USA Red Hat `--' drepper at redhat.com `------------------------ From rhirst@linuxcare.com Fri, 17 Nov 2000 20:10:34 +0000 Date: Fri, 17 Nov 2000 20:10:34 +0000 From: Richard Hirst rhirst@linuxcare.com Subject: [parisc-linux] SEGV signal handling bug (dynamic linking) On Fri, Nov 17, 2000 at 09:09:10AM -0800, Ulrich Drepper wrote: > Richard Hirst writes: > > > mem = malloc(8192); > > if (mem == NULL) { > > perror("malloc"); > > exit(1); > > } > > mem = (char *)(((int)mem + 4095) & ~0x0fff); > > res = mprotect(mem, 4096, PROT_READ); > > Read the Unix standard: > > The behavior of this function is unspecified if the mapping was not > established by a call to mmap(). Changed my prog to use mmap and get the same problem. Richard From grundler@cup.hp.com Fri, 17 Nov 2000 13:50:46 -0800 Date: Fri, 17 Nov 2000 13:50:46 -0800 From: Grant Grundler grundler@cup.hp.com Subject: [parisc-linux] PDC firmware revision FAQ update Hi folks, The issue of PDC/firmware revs came up locally and sounded like a FAQ. I added "10. How can I check if the PDC (firmware) revision is the latest?" and what I knew/could find to our FAQ at: http://www.parisc-linux.org/faq.html The new FAQ entry should be visible to the world in the next hour or so. **** WARNING **** Firmware upgrades can *kill* your machine! **** WARNING **** Don't do it just because. Read the FAQ carefully. Take the time to figure out why you might need the upgrade and expose yourself to this risk. grant ps. please don't ask me why your favorite machine's PDC isn't listed. I don't run the referenced sites. From taggart@carmen.fc.hp.com Fri, 17 Nov 2000 18:26:19 -0700 Date: Fri, 17 Nov 2000 18:26:19 -0700 From: Matt Taggart taggart@carmen.fc.hp.com Subject: [parisc-linux] New cross compiler I have posted new i386/linux -> hppa/linux cross tools at, ftp://puffin.external.hp.com/pub/parisc/binaries/LinuxX86/xc-20001117.tar.gz it includes 32bit and 64bit cross-compilers and a static 32bit glibc 2.2. I have also updated the include tarball, ftp://puffin.external.hp.com/pub/parisc/src/include-20001117.tar.gz it includes glibc 2.2 headers and the latest kernel headers. -- Matt Taggart taggart@fc.hp.com From sandy@storm.ca Fri, 17 Nov 2000 22:54:58 -0500 Date: Fri, 17 Nov 2000 22:54:58 -0500 From: Sandy Harris sandy@storm.ca Subject: [parisc-linux] Host for 712/60 compiles A couple of us have 16 diskless 712/60s which we want to use for distributed processing on easily parallelized tasks like factoring and perhaps crypto cracking. A few questions arise. Is PARISC Linux far enough along to be useful for that? We need no monitor or console (except perhaps for initial debugging), no devices except ethernet, and expect to run only one process per machine, but we need stability. We'll need a host for cross-compiling. We have a 256 meg 715/100 with HP/UX which we expect to use as the host for booting, handing out chunks of work, storing results, etc. Should we compile there under HP/UX or would we get better tools on one of our Intel Linux boxes? Or is PARISC Linux far enough along we should put it on the 715 and get native compilation? From matthew@wil.cx Sat, 18 Nov 2000 07:08:12 +0000 Date: Sat, 18 Nov 2000 07:08:12 +0000 From: Matthew Wilcox matthew@wil.cx Subject: binutils taggart On Wed, Nov 15, 2000 at 05:16:02PM -0700, Matt Taggart wrote: > Modified files: > . : config.guess config.sub > > Log message: > New upstream versions from > http://subversions.gnu.org/cgi-bin/cvsweb/config/ > Now config.guess returns the right thing for hppa-linux so... we needed new versions anyway, even though we're not parisc-linux..? :-) [not bitter, just amused] -- Revolutions do not require corporate support. From matthew@wil.cx Sat, 18 Nov 2000 07:24:54 +0000 Date: Sat, 18 Nov 2000 07:24:54 +0000 From: Matthew Wilcox matthew@wil.cx Subject: [parisc-linux] CVS linux Vs. -test10 On Tue, Nov 14, 2000 at 09:35:01AM -0700, Paul Bame wrote: > > I've attached an overview of differences between our CVS linux sources ok, here's my memories. > * Lots of RCS $Revision$ differences in ACPI (a different 'cvs > import' would've eliminated these differences). i assume someone's already done the appropriate cvs admin -ko magic to fix this? > * drivers/char/Config.in: changes to support LASI, parisc real-time > clock (CONFIG_GENRTC) istr this was `stolen' from the m68k port by sammy. > * drivers/char/serial.c: support for GSC and A500 serial if they're working, send to Ted and he'll do an update with Linus at some point. > * drivers/net/eepro100.c: no clue about this one we were trying to get it to work for the Jan NYLWE show. i doubt we have any changes of note. does anyone have an eepro in an hp? > * drivers/video: STI and HP FB video drivers (iodccon is probably > worthless) agreed on iodccon. unless we're using it up until the point that one of the more advanced consoles takes over? i don't think we are now. > * fs/binfmt_elf.c,exec.c: changes for stack-grows-up? Yes, that's what they're for. > * fs/nfs/read.c: probably unnecessary hack for broken parisc64 gcc we certainly don't want to send it upstream, but we don't want to take it out until the bug is fixed. is fixing that bug on the webshite todo list? > * include/linux/binfmts.h,fs.h,kernel.h,tty.h,udf_fs_sb.h: > unnecessary differences? mostly, yes. > * include/linux/init.h: we use different section names -- why????, > probably some unnecessary other differences too because we use -ffunction-sections. text.init clashes with a function called init, and the linker just merges it into the text segment. we need it to be separate, so it became init.text. there's patches around to do this for other architectures too. just bad naming choices initially. > * include/linux/wait.h: parisc debugging -- should be removed yeah, that can die now. > * scripts/*: MANY differences here. Looks like a combination of > things we hacked to fix configuration problems plus MAYBE not > updating these files from new Linux versions in the past. 'make > menuconfig' is significantly different from upstream. Even the > mkdep.c program is different. ok. mea extremely culpa here. i had an exclude file which included the scripts/ directory. someone should now ditch our stuff, take what's in -test10, hack it till it works for us and check it in. -- Revolutions do not require corporate support. From bzeeb+hplinux@zabbadoz.net Sun, 19 Nov 2000 13:12:25 +0100 (CET) Date: Sun, 19 Nov 2000 13:12:25 +0100 (CET) From: Bjoern A. Zeeb bzeeb+hplinux@zabbadoz.net Subject: [parisc-linux] serial console ? Hi, I just started booting into a 715-100 using palinux-0.5.iso. I did read multiple times that I need serial console. So I plugged in serial cable I an normally using for x86 to x86 serial console on my linux router but I did not get anything on both serial ports :-( What information would one need to help ? personal contact is prefered. I would then sum up all information I got and post it to the list afterwards (if desired). Have to say: I am 'new' to those workstation and had to hoover it first after I got it ;) I also could have a 735-99 with some kind of graphic accelerator if that one would be better. -- Bjoern A. Zeeb bzeeb at Zabbadoz dot NeT 56 69 73 69 74 http://www.zabbadoz.net/ From bzeeb+hplinux@zabbadoz.net Sun, 19 Nov 2000 17:06:11 +0100 (CET) Date: Sun, 19 Nov 2000 17:06:11 +0100 (CET) From: Bjoern A. Zeeb bzeeb+hplinux@zabbadoz.net Subject: [parisc-linux] serial console ? On Sun, 19 Nov 2000, Bjoern A. Zeeb wrote: > I just started booting into a 715-100 using palinux-0.5.iso. > > I did read multiple times that I need serial console. So I plugged in > serial cable I an normally using for x86 to x86 serial console on my > linux router but I did not get anything on both serial ports :-( Hi, sorted out everything. serial cable was quite ok, but using cu I was never able to reach IPL. Using minicom and everything was fine. Had a great success afterwards: installed from CD (palinux-0.5.iso) Everthing worked at once out of the box :-) openssh was enabled on default :-)) only one bad touch: please do not enable portmapper on default. there are too much exploits out there these days. Short: Great great great work !!! -- Bjoern A. Zeeb bzeeb at Zabbadoz dot NeT 56 69 73 69 74 http://www.zabbadoz.net/ From dhazeghi@pacbell.net Sun, 19 Nov 2000 09:24:56 -0800 Date: Sun, 19 Nov 2000 09:24:56 -0800 From: dhazeghi@pacbell.net dhazeghi@pacbell.net Subject: [parisc-linux] glibc-latest tarball broken the glibc-latest tarball on pehc appears to be missing some important subdirectories like scripts and sysdeps. Perhaps a legacy of the 2.2 merge? Thanks, Dara Hazeghi From imatthae@grc.hp.com Sun, 19 Nov 2000 19:35:57 +0100 Date: Sun, 19 Nov 2000 19:35:57 +0100 From: Ingo Matthaes imatthae@grc.hp.com Subject: [parisc-linux] A500 and glibc woes finally we've got a A500 for palinux testing. Unfortunately we have some problems with it. A 32 bit kernel complains about a very old firmware and claims "that machine will probably never run linux" But in fact, it will :-) First question: Did anyone ever succeeded with a 32bit kernel on that hardware ? A 64 bit Kernel boots fine and recognizes all available hardware including the additional 100BT card. But it traps with the init which comes with the latest nfsroot tarball. I built a new one from the sourcesw of debians sysvlinux-2.78 and it does not trap anymore, but the kernel told me about unimplemented 32 syscalls. At this point I tried to build a 64 bit glibc in order to get a crt1.o , which is needed to builf for a 64bit init. Did anyone ever build a 64bit glibc out of the current cvs tree ? Today I've got ologue/epilogue insn (insn 433 431 435 (set (reg:DI 26 %r26) (reg:DI 2 %r2)) -1 (nil) (nil)) ../sysdeps/unix/sysv/linux/init-first.c:105: Unrecognizable insn: (insn 440 438 441 (set (reg:DI 24 %r24) (lo_sum:DI (reg:DI 1 %r1) (symbol_ref:DI ("LP$-001")))) -1 (insn_list 437 (nil)) (expr_list:REG_DEAD (reg:DI 1 %r1) (expr_list:REG_UNUSED (reg:DI 24 %r24) (nil)))) ../sysdeps/unix/sysv/linux/init-first.c:105: Internal compiler error in num_delay_slots, at insn-attrtab.c:2505 Thats the point I'm currently stucking. BTW If someone involved into the port with access to the internal HP Network needs access to that machine, please contact me. Later Ingo -- Tel: ++49-2102-908-210 German Response Center Fax: ++49-2102-907-934 Berliner Str. 111 Mailto: Ingo_Matthaes@hp.com 40880 Ratingen Germany HP Unix/Linux Competency Center Network and High AvailabilitY OpenPGP fingerprint = 4298E7785FFD65DC8950 14E9F17F8CB5B611AA4A From alan@linuxcare.com.au Mon, 20 Nov 2000 14:03:16 +1100 (EST) Date: Mon, 20 Nov 2000 14:03:16 +1100 (EST) From: Alan Modra alan@linuxcare.com.au Subject: Single-stepping On Thu, 16 Nov 2000, John Marvin wrote: > Anyway, for reference, HP-UX does single stepping by using a combination > of the taken branch trap, and loading the instruction queues such that the > front of the queue points to the next instruction to be single stepped and > the back of the queue points to the first of two break instructions on a > "break" page. It does NOT insert break instructions into the code, so it > does not adversely affect execution on a SMP machine. Note that we > already put a bunch of break instructions before the syscall entry point > on the gateway page, so it would be easy to use our gateway page for the > "break page". This way, if the single stepped instruction branches, a > taken branch trap will be taken (which is important in the case where the > branch nullifies its delay slot). Otherwise, the instruction will be > executed and then the break instruction at the known location on the > "break" page will be executed. If the single stepped instruction > nullifies the next instruction, the second break instruction on the > "break" page will be executed. This is the path I started out on for hppa-linux, then hit the problem of a branch that nullifies it's delay slot. At that point, I decided playing with IAOQ_back wouldn't work as I missed the solution of enabling taken branch traps. :-( If I'd seen this trick, then I would not have tried using the recovery counter, and even now, it may be better to go back to IAOQ fiddling. The recovery counter scheme has the disadvantage that there's only one of them so you need to save/restore over task swaps or introduce extra instructions in the syscall path - and be very careful. > Note that this is the short explanation. It is not as simple as it sounds. > One major complication is that branches with links don't work properly > with the instruction queue magic, so the link register has to be updated > in the taken branch trap handler. Also branch externals won't update > the space of the space queue tail properly (again, that has to be fixed > in the taken branch handler). I can provide more details if the recovery > counter method doesn't work out. I'm a little intrigued about these "complications". How can the link register or space _not_ be updated properly? As far as I can see, the only really tricky instruction to single-step is RFI - which shouldn't ever occur in userspace, and which we'd just emulate if it was important. Alan Modra -- Linuxcare. Support for the Revolution. From jsm@udlkern.fc.hp.com Sun, 19 Nov 2000 22:43:02 -0700 (MST) Date: Sun, 19 Nov 2000 22:43:02 -0700 (MST) From: John Marvin jsm@udlkern.fc.hp.com Subject: Single-stepping > > Note that this is the short explanation. It is not as simple as it sounds. > > One major complication is that branches with links don't work properly > > with the instruction queue magic, so the link register has to be updated > > in the taken branch trap handler. Also branch externals won't update > > the space of the space queue tail properly (again, that has to be fixed > > in the taken branch handler). I can provide more details if the recovery > > counter method doesn't work out. > > I'm a little intrigued about these "complications". How can the link > register or space _not_ be updated properly? As far as I can see, the > only really tricky instruction to single-step is RFI - which shouldn't > ever occur in userspace, and which we'd just emulate if it was important. The problem is that the link register is set to IAOQ_Back + 4. and in the case of ble, sr0 is set to IASQ_Back. Since we've played games with the queues, IAOQ_Back and IASQ_Back are pointing at the break page, not at the instruction following the branch. The additional complication is that the taken branch trap traps at the branch destination, not at the branch, so at the point of the trap you don't know where you came from in order to fix the problem easily. So, what HP-UX does is check each instruction before it executes it to see if it is a branch, and if so, what the link register is (and that is all that needs to be parsed, since we are not emulating the instruction). It then stores the branch location, and also sets some branch state flags (e.g. UBE for a branch external, and UBL for a branch with a link, both flags being set for a ble instruction). Then in the taken branch handler you have all the information you need to fix the queue. You also need to check this saved state if a signal handler is invoked while single stepping, so that the proper pc queue values can be saved in the signal context. John Marvin jsm@fc.hp.com From jsm@udlkern.fc.hp.com Sun, 19 Nov 2000 23:01:20 -0700 (MST) Date: Sun, 19 Nov 2000 23:01:20 -0700 (MST) From: John Marvin jsm@udlkern.fc.hp.com Subject: A500 and glibc woes Ingo, > > finally we've got a A500 for palinux testing. Unfortunately > we have some problems with it. > A 32 bit kernel complains about a very old firmware and claims > "that machine will probably never run linux" But in fact, it > will :-) Actually, there are no plans to ever support the A500 on a 32 bit kernel. The A500 only has 64 bit firmware, so in order to support it we would need to write a 32->64 bit firmware translation layer. ... > A 64 bit Kernel boots fine and recognizes all available hardware > including the additional 100BT card. But it traps with the init > which comes with the latest nfsroot tarball. I built a new one > from the sourcesw of debians sysvlinux-2.78 and it does not trap > anymore, but the kernel told me about unimplemented 32 syscalls. > At this point I tried to build a 64 bit glibc in order to get > a crt1.o , which is needed to builf for a 64bit init. > Well, it might seem crazy, but our short term plans do not include supporting a 64 bit user environment on the 64 bit kernel. Long term I believe this will happen, but as you have already seen, work needs to be done to support 64 bit glibc, shared libraries, etc. So, in order to get the A500 to boot, we need to support the 32 bit user environment on a 64 bit kernel. We've only recently gotten to the point where the 64 bit kernel gets far enough to start running user space applications. The problem is that we need to write translations for many system calls, since type sizes (and the structures those types are in) are different between 32 bit and 64 bit (the ugliest case is the ioctl system call). In summary, the A500 currently won't work, but since it is one of the machines that HP has targetted for Linux support, you can be sure that this will change fairly soon. John Marvin jsm@fc.hp.com From grundler@cup.hp.com Sun, 19 Nov 2000 22:47:27 -0800 Date: Sun, 19 Nov 2000 22:47:27 -0800 From: Grant Grundler grundler@cup.hp.com Subject: [parisc-linux] A500 and glibc woes Ingo Matthaes wrote: > finally we've got a A500 for palinux testing. Unfortunately > we have some problems with it. Ingo, uhmm...I'm not surprised. Let me help you understand the A500 and the direction we are going with support on the A500. I'm one of several people working on A500 support. A500 Features (marketing crud - you probably know this): o 16GB of RAM o 2-way 550 MHz PA8600 o 4 PCI-4X slots (3 of which are 1 slot per PCI bus) o all in 2U rack mountable box. Inside is (technical crud): o PCX-W+ o Astro IOMMU (aka SBA. Provides cache-coherent DMA and virtual I/O DMA) o Elroy PCI Host Bus Adapter (aka LBA) o IOSAPIC interrupt controller (integrated in Elroy) o PAT PDC (not legacy) o ^B for service processor access (ie I can reset the machine remotely) > A 32 bit kernel complains about a very old firmware and claims > "that machine will probably never run linux" But in fact, it > will :-) That's right! :^) > First question: Did anyone ever succeeded with a 32bit kernel > on that hardware ? No. Only on *64-bit* kernels. The reason is some of the PAT PDC calls we need are *only* available in wide mode. We could have written narrow<->wide mode translation routines but a 32-bit kernel ignores the A500's best feature - 16GB of RAM. The issue is HP needs good specweb99 numbers to sell these boxes and that requires GB of RAM. The 512MB of RAM that 32-bit kernel currently supports (jsm tells me 3GB or so can be done) won't approach the perf levels which can be acheived with 8 or 16GB. The HPUX specweb team (who just *beat* single CPU TUX specweb99 numbers with HPUX on A500) told me. They have a clue. You are welcome to write those translation routines and then *remove* many the "#ifdef __LP64__" preprocessor directives in arch/parisc/kernel/inventory.c and lba_pci.c. Send me the patch and I'll test/review/commit the changes. > A 64 bit Kernel boots fine and recognizes all available hardware > including the additional 100BT card. But it traps with the init > which comes with the latest nfsroot tarball. There are issues/problems with PCI resource management and I have some code waiting to be tested when I get in tomorrow. But you can be very helpful with user space! Perhaps Paul Bame can be more specific. But basically we don't have all the translation routines in place for 32-bit applications invoking 64-bit kernel syscalls. > I built a new one > from the sourcesw of debians sysvlinux-2.78 and it does not trap > anymore, but the kernel told me about unimplemented 32 syscalls. Right. > At this point I tried to build a 64 bit glibc in order to get > a crt1.o , which is needed to builf for a 64bit init. > > Did anyone ever build a 64bit glibc out of the current cvs tree ? I don't think so. Eventually we wanted to but haven't been able yet. So this great that you are trying! > Today I've got ... Can someone one with a clue about toolchain look at that? I'd be really impressed if someone got a 64-bit userspace built! I can help get kernel working right but don't have a clue about the tools. The 64-bit kernel can be booted on the following class of boxes to about the same point as the A500: o C160/180/200/240/360 o B2000/C3000/J5000/C3600/J5600/J6000 o some D/K/R-class machines The key is the box must have PCX-U (PA8000), PCX-U+ (PA8200), PCX-W (PA8500) or PCX-W+ (PA8600) processor. Look in the HWDB (http://www.parisc-linux.org/hw.html) or in /usr/sam/lib/mo/sched.models (HPUX 11.x) to determine which processor you have. > Thats the point I'm currently stucking. > > BTW If someone involved into the port with access to the internal HP > Network needs access to that machine, please contact me. Ditto. I can arrange access to my A500 as well. External access to some limited number of people could be arranged if demand is justifiable. But given the number of other boxes which can run 64-bit kernel, I hope that's not necessary. Thanks Ingo! grant Grant Grundler Unix Systems Enablement Lab +1.408.447.7253 From alan@linuxcare.com.au Mon, 20 Nov 2000 17:53:18 +1100 (EST) Date: Mon, 20 Nov 2000 17:53:18 +1100 (EST) From: Alan Modra alan@linuxcare.com.au Subject: Single-stepping On Sun, 19 Nov 2000, John Marvin wrote: > > I'm a little intrigued about these "complications". How can the link > > register or space _not_ be updated properly? As far as I can see, the > > only really tricky instruction to single-step is RFI - which shouldn't > > ever occur in userspace, and which we'd just emulate if it was important. > > The problem is that the link register is set to IAOQ_Back + 4. and in > the case of ble, sr0 is set to IASQ_Back. Since we've played games with > the queues, IAOQ_Back and IASQ_Back are pointing at the break page, not > at the instruction following the branch. Ah. That is a little nasty, especially given the effect on signal handlers you mention below. Maybe using the recovery counter isn't such a bad idea after all, especially since the added syscall and task switch overhead can be quite small if the kernel only supports single-step by one instruction. > The additional complication is that the taken branch trap traps at the > branch destination, not at the branch, so at the point of the trap you > don't know where you came from in order to fix the problem easily. So, > what HP-UX does is check each instruction before it executes it to see if > it is a branch, and if so, what the link register is (and that is all that > needs to be parsed, since we are not emulating the instruction). It then > stores the branch location, and also sets some branch state flags (e.g. > UBE for a branch external, and UBL for a branch with a link, both flags > being set for a ble instruction). Then in the taken branch handler you > have all the information you need to fix the queue. You also need > to check this saved state if a signal handler is invoked while single > stepping, so that the proper pc queue values can be saved in the signal > context. Another question for you and/or the list in general: Why does struct pt_regs have an ipsw field? Seems like it currently is unused. Regards, Alan Modra -- Linuxcare. Support for the Revolution. From grundler@cup.hp.com Sun, 19 Nov 2000 23:05:26 -0800 Date: Sun, 19 Nov 2000 23:05:26 -0800 From: Grant Grundler grundler@cup.hp.com Subject: [parisc-linux] Host for 712/60 compiles Sandy Harris wrote: > A couple of us have 16 diskless 712/60s which we want to use for distributed > processing on easily parallelized tasks like factoring and perhaps crypto > cracking. A few questions arise. > > Is PARISC Linux far enough along to be useful for that? We need no monitor or > console (except perhaps for initial debugging), no devices except ethernet, > and expect to run only one process per machine, but we need stability. It's not rock solid. On 712's, it should be pretty good though. > We'll need a host for cross-compiling. We have a 256 meg 715/100 with HP/UX > which we expect to use as the host for booting, handing out chunks of work, > storing results, etc. Should we compile there under HP/UX or would we get > better tools on one of our Intel Linux boxes? I don't think anyone has tried to cross-compile parisc-linux on an HPUX host in quite a while. > Or is PARISC Linux far enough along we should put it on the 715 and get > native compilation? AFAIK, all of the debian packages on the ISO image are built natively. But using a dual P700 linux box would be alot faster. :^) grant Grant Grundler Unix Systems Enablement Lab +1.408.447.7253 From sieler@allegro.com Sun, 19 Nov 2000 23:24:00 -0800 (PST) Date: Sun, 19 Nov 2000 23:24:00 -0800 (PST) From: Stan Sieler sieler@allegro.com Subject: Single-stepping Re: > handlers you mention below. Maybe using the recovery counter isn't such a quite true. > bad idea after all, especially since the added syscall and task switch > overhead can be quite small if the kernel only supports single-step by > one instruction. why the limit? We've used multi-instruction "single step" (oxymoron :) for about 15 years on PA-RISC...no problems, efficient, and *very* useful! -- Stan Sieler sieler@allegro.com www.allegro.com/sieler/wanted/index.html www.sieler.com From grundler@cup.hp.com Sun, 19 Nov 2000 23:44:42 -0800 Date: Sun, 19 Nov 2000 23:44:42 -0800 From: Grant Grundler grundler@cup.hp.com Subject: [parisc-linux] CVS linux Vs. -test10 Matthew Wilcox wrote: > On Tue, Nov 14, 2000 at 09:35:01AM -0700, Paul Bame wrote: > ok, here's my memories. Thanks Matthew! hehe...sounds like someone's getting older. :^) ... > > * drivers/net/eepro100.c: no clue about this one > > we were trying to get it to work for the Jan NYLWE show. I think I did that. IIRC, it's a one-line change to use I/O port space since MMIO wasn't usable without more invasive changes. > i doubt we have any changes of note. does anyone have an eepro in an hp? I have picked nearly 30 i82557/i82558 PCI cards from scrap yard. And maybe a few i82559 even. Did you need one (or two)? :^) FWIW, this is the card/driver which I think was causing misaligned data reference traps. I never had a chance to followup with this though. At the time, I thought it would be *really* fun to show this working to HP's marketing team... > > * fs/nfs/read.c: probably unnecessary hack for broken parisc64 gcc > > we certainly don't want to send it upstream, but we don't want to take it > out until the bug is fixed. is fixing that bug on the webshite todo list? I don't think so. It's possible it's already fixed. Relevant CVS log entry: | revision 1.5 | date: 2000/07/18 03:15:25; author: dhd; state: Exp; lines: +5 -0 | ARGH! When I put in an assertion, NFS stops breaking randomly. I | suspect this is a compiler or binutils problem but I can't see any | clear differences in the generated code. I'll debug it later... This sounds like the hppa64 bug we saw with %r29 getting trashed. But I don't think David was working on hppa64 kernel at the time. I can test 32-bit NFS Root tomorrow w/o assertion if no one else beats me to it. > > * include/linux/init.h: we use different section names -- why????, > > probably some unnecessary other differences too > > because we use -ffunction-sections. text.init clashes with a function > called init, and the linker just merges it into the text segment. we > need it to be separate, so it became init.text. there's patches around > to do this for other architectures too. just bad naming choices initially. We need to resolve this in order to merge upstream. Matthew, any advice on how we should proceed? Or would be easier for you pester Alan Cox and just get it fixed? > > * include/linux/wait.h: parisc debugging -- should be removed > > yeah, that can die now. I'd be happy to fix this by clobbering the current version with what's in linux-2.4.0-test10. But what is the "right" way to revert changes we've made so this doesn't show up in next merge? I'll need to know this in order to revert the fs/nfs/read.c change as well. thanks, grant Grant Grundler Unix Systems Enablement Lab +1.408.447.7253 From milang@tal.org Mon, 20 Nov 2000 10:57:36 +0200 Date: Mon, 20 Nov 2000 10:57:36 +0200 From: Kaj-Michael Lang milang@tal.org Subject: [parisc-linux] Palinux on a 712/60 > Thanks for the reply, Grant. However, the 712s do not have a serial console. Yes it does.. it's just undocumented. Unfortunately I don't have the information here, but I have succesfully changed the console to serial on one of my 712. Kaj-Michael Lang milang@tal.org From alan@linuxcare.com.au Mon, 20 Nov 2000 20:05:58 +1100 (EST) Date: Mon, 20 Nov 2000 20:05:58 +1100 (EST) From: Alan Modra alan@linuxcare.com.au Subject: Single-stepping On Sun, 19 Nov 2000, Stan Sieler wrote: > > bad idea after all, especially since the added syscall and task switch > > overhead can be quite small if the kernel only supports single-step by > > one instruction. > > why the limit? We've used multi-instruction "single step" (oxymoron :) > for about 15 years on PA-RISC...no problems, efficient, and *very* > useful! Because you would then need to save and restore cr0 on task switches (or only allow one task to be single-stepped at a time). That's four instructions and two extra memory accesses per task switch. Which might not seem very much, but at some point somebody will no doubt start caring about pa-linux performance. For a single-step by one, you can simply set cr0 to zero on a task switch, and possibly avoid touching cr0 on a task switch at all with careful attention to various trap handlers. Here's the idea. The tail of syscall_restore (64-bit stuff pruned) will look like the following, with the first three instructions being the added code to support single-step (and also wide/narrow switching for 64-bit) ldi 3,%r20 mtctl $r20,%cr0 /* recovery counter, ptrace single-step */ LDREG TASK_PT_PSW(%r1),%r20 mtctl %r1,%cr30 /* intrhandler okay. */ mfsp %sr3,%r1 /* Get users space id */ mtsp %r1,%sr4 /* Restore sr4 */ mtsp %r1,%sr5 /* Restore sr5 */ mtsp %r1,%sr6 /* Restore sr6 */ depi 3,31,2,%r31 /* ensure return to user mode. */ mtsm %r20 /* restore irq state */ mfctl %cr27,%r20 be 0(%sr3,%r31) /* return to user space */ mtsp %r1,%sr7 /* Restore sr7 */ ptrace will fiddle with TASK_PT_PSW, setting the R bit and clearing the I bit to enable the recovery counter - which will start counting down at the mtsm instruction above, and reach zero on the user-space instruction, so we'll trap after executing one user-space instruction. The task-switch nonsense is to handle the case where we page-fault on the instruction and switch to another task also doing single-stepping. You want to ensure cr0 is zero when we finally get back to the original task. Now it might turn out that having extra instructions in the syscall path is worse than extra code and memory accesses on task switch. If that turns out to be true, then you'll probably get your multi-step ptrace. :-) Alan Modra -- Linuxcare. Support for the Revolution. From M_Wild@tunstall.co.uk Mon, 20 Nov 2000 10:21:32 -0000 Date: Mon, 20 Nov 2000 10:21:32 -0000 From: Mark Wild M_Wild@tunstall.co.uk Subject: [parisc-linux] Upgrading memory on a 710 Hi, I have acquired some 8MB SIMMs suitable for my old 710 workstation and wish to utilise them. I don't have any docs for the 710 and was wondering if anyone could point me in the direction of some. I've looked on the HP website but could only find some for 712s, 720, 730 etc. Alternatively, if anyone knows whether any motherboard links need to be changed, whether SIMMS need to be added in pairs / quads and which memory configurations are allowed I would be grateful. Thanks, Mark Wild -- From matthew@wil.cx Mon, 20 Nov 2000 10:50:57 +0000 Date: Mon, 20 Nov 2000 10:50:57 +0000 From: Matthew Wilcox matthew@wil.cx Subject: [parisc-linux] A500 and glibc woes On Sun, Nov 19, 2000 at 07:35:57PM +0100, Ingo Matthaes wrote: > finally we've got a A500 for palinux testing. Unfortunately > we have some problems with it. > A 32 bit kernel complains about a very old firmware and claims > "that machine will probably never run linux" But in fact, it > will :-) > First question: Did anyone ever succeeded with a 32bit kernel > on that hardware ? It's not intended to work; I doubt anyone has tried. You should build a 64 bit kernel. > A 64 bit Kernel boots fine and recognizes all available hardware > including the additional 100BT card. But it traps with the init > which comes with the latest nfsroot tarball. I built a new one > from the sourcesw of debians sysvlinux-2.78 and it does not trap > anymore, but the kernel told me about unimplemented 32 syscalls. > At this point I tried to build a 64 bit glibc in order to get > a crt1.o , which is needed to builf for a 64bit init. Don't try a 64-bit userland yet. What you need to do is implement some of the 32-bit syscalls. -- Revolutions do not require corporate support. From matthew@wil.cx Mon, 20 Nov 2000 11:17:26 +0000 Date: Mon, 20 Nov 2000 11:17:26 +0000 From: Matthew Wilcox matthew@wil.cx Subject: [parisc-linux] CVS linux Vs. -test10 On Sun, Nov 19, 2000 at 11:44:42PM -0800, Grant Grundler wrote: > Matthew Wilcox wrote: > > On Tue, Nov 14, 2000 at 09:35:01AM -0700, Paul Bame wrote: > > ok, here's my memories. > > Thanks Matthew! > > hehe...sounds like someone's getting older. :^) ... when i were a lad, all this were fields! Our dad used to kill us every morning, we'd get up half an hour before we went to bed and walk uphill both to and from school... > ... > > > * drivers/net/eepro100.c: no clue about this one > > > > we were trying to get it to work for the Jan NYLWE show. > > I think I did that. IIRC, it's a one-line change to use I/O port > space since MMIO wasn't usable without more invasive changes. sounds right. MMIO should work now though, right? > > i doubt we have any changes of note. does anyone have an eepro in an hp? > > I have picked nearly 30 i82557/i82558 PCI cards from scrap yard. > And maybe a few i82559 even. Did you need one (or two)? :^) Heh, I only have a 712 right now :-) > FWIW, this is the card/driver which I think was causing misaligned > data reference traps. I never had a chance to followup with this though. > At the time, I thought it would be *really* fun to show this working > to HP's marketing team... Oh yes, I remember that now. Tulip always does a copy (well, it doesn't _have_ to, but we tell it to, just like the Alpha does). > > > * fs/nfs/read.c: probably unnecessary hack for broken parisc64 gcc > > > > we certainly don't want to send it upstream, but we don't want to take it > > out until the bug is fixed. is fixing that bug on the webshite todo list? > > I don't think so. It's possible it's already fixed. > > Relevant CVS log entry: > | revision 1.5 > | date: 2000/07/18 03:15:25; author: dhd; state: Exp; lines: +5 -0 > | ARGH! When I put in an assertion, NFS stops breaking randomly. I > | suspect this is a compiler or binutils problem but I can't see any > | clear differences in the generated code. I'll debug it later... > > This sounds like the hppa64 bug we saw with %r29 getting trashed. > But I don't think David was working on hppa64 kernel at the time. > I can test 32-bit NFS Root tomorrow w/o assertion if no one else > beats me to it. it was definitely a 32-bit kernel at the time. It might be the same bug, but I'm not sure. > > > * include/linux/init.h: we use different section names -- why????, > > > probably some unnecessary other differences too > > > > because we use -ffunction-sections. text.init clashes with a function > > called init, and the linker just merges it into the text segment. we > > need it to be separate, so it became init.text. there's patches around > > to do this for other architectures too. just bad naming choices initially. > > We need to resolve this in order to merge upstream. > Matthew, any advice on how we should proceed? > Or would be easier for you pester Alan Cox and just get it fixed? Hm. Alan's not hacking on 2.4, last I heard. I might pester Linus and see if we can change that. It's a mechanical change so he might not be averse to it at this point. Bear in mind we don't need to do a complete merge at this point -- most architectures have a separate patch to apply on top of Linus' tree. > > > * include/linux/wait.h: parisc debugging -- should be removed > > > > yeah, that can die now. > > I'd be happy to fix this by clobbering the current version with what's in > linux-2.4.0-test10. But what is the "right" way to revert changes we've made > so this doesn't show up in next merge? I don't know that there's an official way to do this. I always changed the file to its previous state and then committed it. There are a number of ways of doing it; perhaps the cleanest is: cvs diff -r1.4 -r1.5 fs/nfs/read.c >../read.c.diff (then check the read.c.diff file) patch -p1 <../read.c.diff rm ../read.c.diff or you can just delete the lines yourself. Use diff to make sure there aren't any silly cosmetic changes (eg whitespace). -- Revolutions do not require corporate support. From grundler@cup.hp.com Mon, 20 Nov 2000 09:34:31 -0800 Date: Mon, 20 Nov 2000 09:34:31 -0800 From: Grant Grundler grundler@cup.hp.com Subject: [parisc-linux] CVS linux Vs. -test10 Matthew Wilcox wrote: ... > sounds right. MMIO should work now though, right? It would have worked then too. Changing it to use MMIO space would require disabling I/O Port space by defining inb/outb locally to use gsc_readb/writeb. My problem with doing that was the semantics are slightly different. I/O Port space is non-postable and MMIO space is. I wasn't confident a driver written to use I/O port space would work right under MMIO though some certainly do. ... > it was definitely a 32-bit kernel at the time. It might be the same bug, > but I'm not sure. Can't be. AP (%r29) is a 64-bit only construct. dhd also just confirmed it was 32-bit kernel. I'll try it now. ... > > We need to resolve this in order to merge upstream. > > Matthew, any advice on how we should proceed? > > Or would be easier for you pester Alan Cox and just get it fixed? > > Hm. Alan's not hacking on 2.4, last I heard. I might pester Linus and > see if we can change that. It's a mechanical change so he might not be > averse to it at this point. Bear in mind we don't need to do a complete > merge at this point -- most architectures have a separate patch to apply > on top of Linus' tree. Ok. What's the first step to getting arch/parisc* and include/asm-parisc* into Linus's tree? I had dinner with Bdale Garbee last night and one of two things he made clear was we need to unfork from debian and linus's tree in order to move forward. All our CVS branches need to become obsolete or "local sandboxes" of the respective upstream partners. Feeding kernel bits upstream will bring a new level of visibility (and *HELP*) to the parisc-linux port. I totally agree with Bdale. I understand alot of work still needs to happen in our tree (eg though sba_iommu.c works, it's current form sucks) But pushing bits upstream to linus will not preclude us from doing that work. I also find it odd that glibc is merged upstream *before* the kernel is. For the record, the second issue bdale made clear was we need "boot floppies" debian package working. We don't need more ISO images (no offense to pjlahaie for his good work). "Boot floppies" is a pre-requisite to becoming part of the next debian release. Given I still don't have a clue how to build a debian package and I can still contribute alot in other areas, it doesn't make sense for me to do it myself. > > I'd be happy to fix this by clobbering the current version with what's in > > linux-2.4.0-test10. But what is the "right" way to revert changes we've made > > so this doesn't show up in next merge? > > I don't know that there's an official way to do this. I always changed > the file to its previous state and then committed it. There are a number of > ways of doing it; perhaps the cleanest is: > > cvs diff -r1.4 -r1.5 fs/nfs/read.c >../read.c.diff > (then check the read.c.diff file) > patch -p1 <../read.c.diff > rm ../read.c.diff > > or you can just delete the lines yourself. Use diff to make sure there > aren't any silly cosmetic changes (eg whitespace). The part you described above is the easy part - np. I'm worried about labels and tracking how we "name" the releases. Mang or other CVS ninja's care to comment? thanks, grant Grant Grundler Unix Systems Enablement Lab +1.408.447.7253 From rhirst@linuxcare.com Mon, 20 Nov 2000 17:58:38 +0000 Date: Mon, 20 Nov 2000 17:58:38 +0000 From: Richard Hirst rhirst@linuxcare.com Subject: [parisc-linux] signal handling problems (32 bit kernel) Hi, Following on from my problems with SEGV last week, I've come up with a few signal handling issues: ============================================================= parisc:signal.c /* Possibly bogus. */ #warning XXX FIXME probably bogus -PB /* I think this is bogus -- it'll cause the first instn of the * signal handler to be executed twice! Better might be to * set iaoq[0] to one of the NOPs in the trampoline. -PB */ regs->iaoq[0] = (unsigned long) haddr | 3; regs->iaoq[1] = (unsigned long) haddr | 3; This causes real problems if the signal handler is a dynamic object which has not yet been resolved; in that case the signal handler points at the b,l instr in the following at the end of the .plt: 2700: 0e 80 10 96 ldw 0(sr0,r20),r22 2704: ea c0 c0 00 bv r0(r22) 2708: 0e 88 10 95 ldw 4(sr0,r20),r21 270c: ea 9f 1f dd b,l 2700 <__DTOR_END__+0x54>,r20 2710: d6 80 1c 1e depwi 0,31,2,r20 typically that results in a misalligned access on the first ldw as r20 is screwed. I've fixed that by setting iaoq[1] = iaoq[0]+4. Is that OK, or should we use the NOP approach in the comment above? ============================================================= If a program gets a SEGV, fixes the cause of it in its signal handler, and returns, then the faulting instruction is not rerun. I think that's wrong (differs from m68k anyway). ============================================================= Set the following program running: #include #include #include #include int v[8]; void (* fp)(int); void sig_handler(int sig) { } void poke(int i) { v[0] = i; v[1] = i; v[2] = i; v[3] = i; v[4] = i; v[5] = i; v[6] = i; v[7] = i; } int main() { int j, i = 0; struct sigaction act; memset(&act, 0, sizeof(act)); act.sa_handler = sig_handler; sigaction(SIGUSR1, &act, NULL); fp = sig_handler; fp(0); printf("I am %d\n", getpid()); while (1) { poke (++i); j = v[7]; if (j != i) printf("Wah!\n"); } } and then in another terminal do 'kill -USR1 '. The program either goes 'Wah!', gives a SEGV, or works. That seems to be because %r1 is corrupted while processing the signal. The signal handler ends with a syscall (rt_sigreturn_wrapper), and %r1, at least, is not saved and restored over the syscall. %r31 also appears to get corrupted, as it is used in the final branch of the syscall return. Richard From sieler@allegro.com Mon, 20 Nov 2000 10:47:38 -0800 (PST) Date: Mon, 20 Nov 2000 10:47:38 -0800 (PST) From: Stan Sieler sieler@allegro.com Subject: Single-stepping Re: > Because you would then need to save and restore cr0 on task switches (or > only allow one task to be single-stepped at a time). That's four > instructions and two extra memory accesses per task switch. Which might > not seem very much, but at some point somebody will no doubt start caring > about pa-linux performance. And it still won't seem like much, then! Non-memory-access instructions are cheap. An extra memory reference (from something probably already in cache) and two extra instructions would probably cost less than an hour per CPU over the next 10 *years*, assuming 10 years of 1000 task switches per second on a slow 100 MHz CPU. Of course, at the cost of an extra non-memory-referencing instruction or so, you could say "at switch-to-task time: if PSW R-bit set, then load the saved CR0 from memory and move it to CR0", saving one memory reference 99.99999% of the time, resuling in an average of only one memory reference per task switch normally. I haven't look at interrupt handling / system calls closely, but I hope there aren't other false savings. (E.g., failure to save/restore the PID check flag ... sure, user processes *now* probably never have pid checking disabled, but that's a very useful feature to have available (with proper security controls, of course).) (Yes, I'm one of the very few who use that feature on MPE/iX ... carefully, of course :) -- Stan Sieler sieler@allegro.com www.allegro.com/sieler/wanted/index.html www.sieler.com From grundler@cup.hp.com Mon, 20 Nov 2000 11:23:40 -0800 Date: Mon, 20 Nov 2000 11:23:40 -0800 From: Grant Grundler grundler@cup.hp.com Subject: [parisc-linux] CVS linux Vs. -test10 Matthew Wilcox wrote: ... > > * fs/nfs/read.c: probably unnecessary hack for broken parisc64 gcc > > we certainly don't want to send it upstream, but we don't want to take it > out until the bug is fixed. is fixing that bug on the webshite todo list? It's fixed. I was able to NFS boot my A180 and install palinux-0.5.iso bits on the SCSI disk. I've reverted the change to the LINUS_240_TEST10 version. > > * include/linux/wait.h: parisc debugging -- should be removed > > yeah, that can die now. Is anyone else already doing this? thanks, grant Grant Grundler Unix Systems Enablement Lab +1.408.447.7253 From herrold@owlriver.com Mon, 20 Nov 2000 15:40:24 -0500 (EST) Date: Mon, 20 Nov 2000 15:40:24 -0500 (EST) From: herrold herrold@owlriver.com Subject: Serial vs. STI console selector was: Re: [parisc-linux] Beta CD On Tue, 14 Nov 2000, Paul J.Y. Lahaie wrote: > This is to answer all the questions about sti console. Currently, in the > CVS tree, serial console and STI console cannot be turned on at the same time. > > This means that a choice between serial/sti needs to be done at compile > time. > If you have any more questions or suggestions, feel free to email me or > post on this list. Thank you. ... Query -- Background: Back in the early 70's with a HP 8090 , IBM 1401, IBM 1620, and IBM 360/40, we faced such issues (Don't ask my age, please) -- The solution was to probe for, and look for 'sense switches' in unusual state -- that is -- Some condition which we could examine, and yet not hose up the boot proces on the host. -- CapsLock set on a keyboard driver -- DSR on a serial line, a 'console sense switch' normally kept off but turned on ... so on. Sort of like working through a qualitative analysis flowchart in non-organic chemistry. Is this possible, to allow support of both, with a single kernel? -- Russ From grundler@cup.hp.com Mon, 20 Nov 2000 12:59:41 -0800 Date: Mon, 20 Nov 2000 12:59:41 -0800 From: Grant Grundler grundler@cup.hp.com Subject: Serial vs. STI console selector was: Re: [parisc-linux] Beta CD "Russ" herrold wrote: > Is this possible, to allow support of both, with a single kernel? Yes. I think the issues are code not stomping on each other. And it's easy than you might think - PDC can tell us what the primary console is. grant Grant Grundler Unix Systems Enablement Lab +1.408.447.7253 From grundler@cup.hp.com Mon, 20 Nov 2000 17:19:03 -0800 (PST) Date: Mon, 20 Nov 2000 17:19:03 -0800 (PST) From: Grant Grundler grundler@cup.hp.com Subject: [parisc-linux] 712 ISL and palo Hi Paul (Bame), I tried booting 712 with "bo scsi.4.0 isl" with the palinux-0.5.iso image on a regular hard disk. I wanted to edit the "root" parameter so it would be /dev/sdb (also had a disk at scsi.0.0) instead of /dev/scd0. palo wouldn't accept any ps/2 keyboard input. Don't know if this is a palo or PDC bug. Any ideas? thanks, grant From alan@linuxcare.com.au Tue, 21 Nov 2000 12:55:42 +1100 (EST) Date: Tue, 21 Nov 2000 12:55:42 +1100 (EST) From: Alan Modra alan@linuxcare.com.au Subject: A DT_INIT/DT_FINI glibc patch. On Thu, 16 Nov 2000, H . J . Lu wrote: > While we are on this subject, I looked at the hppa code. It seems to > have the same bug. I have an impression that HP never really used > DT_INIT/DT_FINI. They use DT_INIT_ARRAY/DT_FINI_ARRAY. I don't know > if we should fix hppa also. Yes to all of these comments. elf32-hppa stole some ideas from ia64, which is why the bug is common. Fortunately, I think hppa ld.so etc. can be fixed in a way such that current (broken ABI) binaries will still work. Alan Modra -- Linuxcare. Support for the Revolution. From taggart@carmen.fc.hp.com Mon, 20 Nov 2000 20:12:33 -0700 Date: Mon, 20 Nov 2000 20:12:33 -0700 From: Matt Taggart taggart@carmen.fc.hp.com Subject: [parisc-linux] glibc-latest tarball broken dhazeghi@pacbell.net writes... > the glibc-latest tarball on pehc appears to be missing some important > subdirectories like scripts and sysdeps. Perhaps a legacy of the 2.2 > merge? Disk space problem. I made some room and generated new tarballs. Thanks for pointing out the problem. -- Matt Taggart taggart@fc.hp.com From alan@linuxcare.com.au Tue, 21 Nov 2000 14:22:53 +1100 (EST) Date: Tue, 21 Nov 2000 14:22:53 +1100 (EST) From: Alan Modra alan@linuxcare.com.au Subject: A DT_INIT/DT_FINI glibc patch. On Mon, 20 Nov 2000, Grant Grundler wrote: > I'm afraid we will break binary compatibility for elf32 hppa-linux again. > I only raise this in case there is really a "right" way to fix the > DT_INIT/DT_FINI problem. The fix involves pruning out all the special handling in bfd/elf32-hppa.c for DT_INIT,DT_FINI, and making some small changes to glibc. H.J. Lu has already made the necessary framework changes, and all we need to do is something like #define DL_FUNCTION_ADDRESS(map, addr) _dl_start_address (map, addr) #define DL_DT_INIT_ADDRESS(map, addr) \ ((addr) & 2 ? (addr) : DL_FUNCTION_ADDRESS (map, addr)) with similar defines for DT_FINI. The test for (addr) & 2 is the fairly innocuous fudge to support old binaries. Another glibc issue (which is why I'm sending this back to the list) is that there has been quite some discussion on the binutils list over the use of the EI_OSABI field. The conclusion being that it isn't really correct to use this field to discern the intendend execution platform. It's purpose is really to tell ELF tools that a file contains fields and values that need to be interpreted in a non-standard way. Since both elf32-hppa and elf64-hppa follow the standards, I'm inclined to think that the gnu tools should set EI_OSABI to zero for both HPUX and Linux targets. Instead the .note.ABI-tag section should be examined to determine the target, which sadly isn't set correctly at the moment. :-( Alan Modra -- Linuxcare. Support for the Revolution. From bame@riverrock.org Mon, 20 Nov 2000 21:02:40 -0700 Date: Mon, 20 Nov 2000 21:02:40 -0700 From: bame@riverrock.org bame@riverrock.org Subject: [parisc-linux] 712 ISL and palo = palo wouldn't accept any ps/2 keyboard input. = Don't know if this is a palo or PDC bug. = Any ideas? PALO bug. I didn't test the PS/2 case but I think I fixed it. -P From alan@linuxcare.com.au Tue, 21 Nov 2000 15:38:57 +1100 (EST) Date: Tue, 21 Nov 2000 15:38:57 +1100 (EST) From: Alan Modra alan@linuxcare.com.au Subject: A DT_INIT/DT_FINI glibc patch. On Tue, 21 Nov 2000, I wrote: > Instead the .note.ABI-tag section should be examined to determine the > target, which sadly isn't set correctly at the moment. :-( Actually, it is set correctly. A comment in csu/abi-note.S was wrong. -- Linuxcare. Support for the Revolution. From jsm@udlkern.fc.hp.com Mon, 20 Nov 2000 22:47:41 -0700 (MST) Date: Mon, 20 Nov 2000 22:47:41 -0700 (MST) From: John Marvin jsm@udlkern.fc.hp.com Subject: [parisc-linux] Use of the EI_OSABI field > Another glibc issue (which is why I'm sending this back to the list) is > that there has been quite some discussion on the binutils list over the > use of the EI_OSABI field. The conclusion being that it isn't really > correct to use this field to discern the intendend execution platform. > It's purpose is really to tell ELF tools that a file contains fields and > values that need to be interpreted in a non-standard way. Since both > elf32-hppa and elf64-hppa follow the standards, I'm inclined to think that > the gnu tools should set EI_OSABI to zero for both HPUX and Linux targets. I don't read the binutils mailing list, so I checked the archive. In my opinion I didn't see a discussion, I saw H.J. Lu repeatedly asserting this "fact". He may or may not be correct about original intention, but the implementation so far has been that EI_OSABI is used to tell what the target platform is. That is what FreeBSD is doing, that is what HP-UX is doing, and that is what the IA-64 Unix System V Application Binary Interface specifies: http://developer.intel.com/design/IA-64/Downloads/24537002.pdf Note that the second paragraph in section 1.1 of that specification includes the following: This document is the result of consensus among operating system vendors intending to provide UNIX and UNIX workalike operating systems on the IA-64 architecture. The vendors participating in this effort include Intel, Sun Microsystems, SCO, IBM, SGI, Cygnus Solutions, VA Linux Systems, HP, and Compaq. So, If the specification is wrong according to H.J. Lu, why did both Cygnus and VA Linux Systems not object to this: Section 4.1.1.4 Operating System Identification The e_ident[EI_OSABI] value identifies the operating system and ABI to which the object is targeted, as listed in Table 4-1. Table 4-1 lists the various ELFOSABI_* fields, e.g. ELFOSABI_HPUX, ELFOSABI_NETBSD, ELFOSABI_LINUX, etc. Note also, that the current mechanism for us to be able to differentiate elf executables in the Linux kernel is the machine dependent elf_check_arch() macro, whose only argument is a pointer to a elf32_hdr or elf64_hdr. I think it would be ugly to try to get the .note.ABI-tag section first for every exec of a new binary in order to determine what the target ABI is. In my opinion, unless H.J. Lu can get the IA-64 ABI changed, it is too late to assert his view of what that field was supposed to be. Please leave the EI_OSABI field set to ELFOSABI_LINUX until a better consensus on this issue is reached. John Marvin jsm@fc.hp.com From alan@linuxcare.com.au Tue, 21 Nov 2000 18:05:36 +1100 (EST) Date: Tue, 21 Nov 2000 18:05:36 +1100 (EST) From: Alan Modra alan@linuxcare.com.au Subject: [parisc-linux] signal handling problems (32 bit kernel) On Mon, 20 Nov 2000, Richard Hirst wrote: > #warning XXX FIXME probably bogus -PB > /* I think this is bogus -- it'll cause the first instn of the > * signal handler to be executed twice! Better might be to Definitely bogus, as with quite a lot of iaoq manipulation in signal.c > I've fixed that by setting iaoq[1] = iaoq[0]+4. Is that OK, or Sounds like the right thing to do. I reckon everywhere ioaq is fudged from/to r31 should have this sort of mapping. ie. it should be regs->gr[31] = regs->iaoq[0]; in sys_rt_sigreturn, and err |= __put_user(regs->gr[31], &sc->sc_iaoq[0]); err |= __put_user(regs->gr[31] + 4, &sc->sc_iaoq[1]); in setup_sigcontext, and so on. I'm guessing the origial author of this code didn't know which of iaoq[0] and ioaq[1] was ioaq_front. :) > and then in another terminal do 'kill -USR1 '. The program > either goes 'Wah!', gives a SEGV, or works. That seems to be because > %r1 is corrupted while processing the signal. The signal handler ends > with a syscall (rt_sigreturn_wrapper), and %r1, at least, is not saved > and restored over the syscall. %r31 also appears to get corrupted, as > it is used in the final branch of the syscall return. I don't really understand what is going on here, but it seems wrong to me that setup_rt_frame should be touching regs->iaoq at all when in_syscall. Hmm, and in that case why all the other gr[31] to/from ioaq[] fudgery? Alan -- Linuxcare. Support for the Revolution. From rhirst@linuxcare.com Tue, 21 Nov 2000 09:34:42 +0000 Date: Tue, 21 Nov 2000 09:34:42 +0000 From: Richard Hirst rhirst@linuxcare.com Subject: [parisc-linux] signal handling problems (32 bit kernel) On Tue, Nov 21, 2000 at 06:05:36PM +1100, Alan Modra wrote: > On Mon, 20 Nov 2000, Richard Hirst wrote: > > > #warning XXX FIXME probably bogus -PB > > /* I think this is bogus -- it'll cause the first instn of the > > * signal handler to be executed twice! Better might be to > > Definitely bogus, as with quite a lot of iaoq manipulation in signal.c As another example, if a process gets a signal as it is about to execute the instr in the delay slot of a branch, it forgets that it was supposed to be branching on return from the signal handler. Try compiling the following and sending it a SIGUSR1: #include #include #include #include void sig_handler(int sig) { } int main() { struct sigaction act; int i = 1; memset(&act, 0, sizeof(act)); act.sa_handler = sig_handler; sigaction(SIGUSR1, &act, NULL); printf("I am %d\n", getpid()); while (i++) ; printf("Escaped, i=%d!\n", i); return 0; } Oh, you have to run it with "LD_BIND_NOW=1 " to avoid one of the other problems. Time to try and work out what signal.c is really trying to do, I guess. Richard From alan@linuxcare.com.au Tue, 21 Nov 2000 22:26:14 +1100 (EST) Date: Tue, 21 Nov 2000 22:26:14 +1100 (EST) From: Alan Modra alan@linuxcare.com.au Subject: [parisc-linux] signal handling problems (32 bit kernel) On Tue, 21 Nov 2000, Richard Hirst wrote: > Time to try and work out what signal.c is really trying to do, I guess. Maybe you should start by considering all the possible states a task can be in when a signal is delivered, in regards to saved registers and stack layout. It would be a _very_ good idea to formalize this once you've sorted it out by splitting up struct pt_regs appropriately. ie. as other architectures do, into struct pt_regs and struct switch_stack. Actually, parisc could go one further and have three structures, one corresponding to registers saved on syscall entry (new pt_regs), one corresponding to macro callee_save (switch_stack), and one corresponding more or less to macro save_specials. Quite a bit of work, but IMO well worth doing. Alan Modra -- Linuxcare. Support for the Revolution. From matthew@wil.cx Tue, 21 Nov 2000 11:34:32 +0000 Date: Tue, 21 Nov 2000 11:34:32 +0000 From: Matthew Wilcox matthew@wil.cx Subject: [parisc-linux] CVS linux Vs. -test10 On Mon, Nov 20, 2000 at 09:34:31AM -0800, Grant Grundler wrote: > Ok. What's the first step to getting arch/parisc* and include/asm-parisc* > into Linus's tree? Someone (probably me) sends him a patch. He told me at the Toronto show that he was quite happy to apply anything that only touched those two directories. (oh, and drivers/gsc wouldn't be a problem either). Can I just check that no-one wants to rename drivers/gsc again? :-) > I had dinner with Bdale Garbee last night and one of two things he made > clear was we need to unfork from debian and linus's tree in order to move > forward. All our CVS branches need to become obsolete or "local sandboxes" > of the respective upstream partners. Feeding kernel bits upstream will > bring a new level of visibility (and *HELP*) to the parisc-linux port. that's true. last time we discussed this several people were unhappy with the idea of sending our current work to Linus. Is anyone unhappy with doing this now? > I also find it odd that glibc is merged upstream *before* the kernel is. glibc is more portable :-) > The part you described above is the easy part - np. > I'm worried about labels and tracking how we "name" the releases. > Mang or other CVS ninja's care to comment? don't tag it. just commit it. tags are laid down at big events, not when you fix bugs or undo changes. -- Revolutions do not require corporate support. From jsm@udlkern.fc.hp.com Tue, 21 Nov 2000 06:11:29 -0700 (MST) Date: Tue, 21 Nov 2000 06:11:29 -0700 (MST) From: John Marvin jsm@udlkern.fc.hp.com Subject: CVS linux Vs. -test10 > > I had dinner with Bdale Garbee last night and one of two things he made > > clear was we need to unfork from debian and linus's tree in order to move > > forward. All our CVS branches need to become obsolete or "local sandboxes" > > of the respective upstream partners. Feeding kernel bits upstream will > > bring a new level of visibility (and *HELP*) to the parisc-linux port. > > that's true. last time we discussed this several people were unhappy > with the idea of sending our current work to Linus. Is anyone unhappy > with doing this now? > Are we suggesting that we populate include/asm-parisc* and arch/parisc* WITHOUT the machine independent changes in the rest of the tree? If that is the case, I guess I don't object, although I would want to make sure that Linus knew the state of the code, and that it would not work without a patch containing changes to the machine independent part, and that followup patches to these branches are likely to be huge. We should also add a README in arch/parisc that explains the above (and where to get patches, how to access CVS, etc.). We also need someone to set up an automatic nightly? patch generator. I certainly don't want to try to get the machine independent changes in yet, since we still have some major issues to fix/clean there, and I doubt Linus would want them at this time anyway. John Marvin jsm@fc.hp.com From rhirst@linuxcare.com Tue, 21 Nov 2000 16:54:42 +0000 Date: Tue, 21 Nov 2000 16:54:42 +0000 From: Richard Hirst rhirst@linuxcare.com Subject: [parisc-linux] signal handling problems (32 bit kernel) On Tue, Nov 21, 2000 at 06:05:36PM +1100, Alan Modra wrote: > > and then in another terminal do 'kill -USR1 '. The program > > either goes 'Wah!', gives a SEGV, or works. That seems to be because > > %r1 is corrupted while processing the signal. The signal handler ends > > with a syscall (rt_sigreturn_wrapper), and %r1, at least, is not saved > > and restored over the syscall. %r31 also appears to get corrupted, as > > it is used in the final branch of the syscall return. > > I don't really understand what is going on here, but it seems wrong to me > that setup_rt_frame should be touching regs->iaoq at all when in_syscall. Problem is that whenever a signal handler is invoked, it is followed by a sys_rt_sigreturn syscall (invoked via the trampoline code), before returning to original usercode. I can imagine that this might work if the process in question was blocked on a syscall, but not if it was suspended due to an interrupt. In either case the path back to the original user code is the syscall return path, and that obviously cannot put things back as they were if the process was interrupted. I think the answer is for syscall_do_signal to save enough in the pt_regs such that sys_rt_sigreturn_wrapper can return to userland via an RFI (like intr_restore, but remembering to trace the syscall exit if necessary) regardless of the process state when the signal occurred. Richard From taggart@carmen.fc.hp.com Tue, 21 Nov 2000 10:20:35 -0700 Date: Tue, 21 Nov 2000 10:20:35 -0700 From: Matt Taggart taggart@carmen.fc.hp.com Subject: [parisc-linux] kernel BUG at sched.c:692! I arrived this morning to discover both my B160 and my C3000 were printing the following as fast as they could, Scheduling in interrupt kernel BUG at sched.c:692! Looking at linux/kernel/sched.c here's the relevant section, 690 scheduling_in_interrupt: 691 printk("Scheduling in interrupt\n"); 692 BUG(); 693 return; scheduling_in_interrupt is called from line 516. Here's some context, 500 asmlinkage void schedule(void) 501 { 502 struct schedule_data * sched_data; 503 struct task_struct *prev, *next, *p; 504 struct list_head *tmp; 505 int this_cpu, c; 506 507 if (!current->active_mm) BUG(); 508 if (tq_scheduler) 509 goto handle_tq_scheduler; 510 tq_scheduler_back: 511 512 prev = current; 513 this_cpu = prev->processor; 514 515 if (in_interrupt()) 516 goto scheduling_in_interrupt; 517 518 release_kernel_lock(prev, this_cpu); I thought it was odd that both systems chose to freak out last night when I have never seen this problem on either of them. The B160 is running a slightly newer kernel and had been up for about 3 days as of last night. The C3K had been up for 4-5 days. When I left last night the B160 was doing a build although the it looks like the build died before this problem occurred. The C3K was idle. Any ideas? Thanks, -- Matt Taggart taggart@fc.hp.com From robert.reilly@gecapital.com Tue, 21 Nov 2000 18:26:41 GMT Date: Tue, 21 Nov 2000 18:26:41 GMT From: Robert Reilly robert.reilly@gecapital.com Subject: [parisc-linux] cd .5 Hi All, I have HP9000/d212 I was able to boot off the cdrom image no problem, however when I get the login prompt I am only able to type in two characters and the screen redraws itself and prompts me for a login. I am using a HP700 serial terminal on ttyS0.I briefly scanned the mailing list but did not find anything. Any help would be appreciated. --Robert Reilly GE Capital Card Service UNIX Administrator robert.reilly@gecapital.com From matthew@wil.cx Tue, 21 Nov 2000 17:38:57 +0000 Date: Tue, 21 Nov 2000 17:38:57 +0000 From: Matthew Wilcox matthew@wil.cx Subject: CVS linux Vs. -test10 On Tue, Nov 21, 2000 at 06:11:29AM -0700, John Marvin wrote: > Are we suggesting that we populate include/asm-parisc* and arch/parisc* > WITHOUT the machine independent changes in the rest of the tree? Yes. > If that is the case, I guess I don't object, although I would want > to make sure that Linus knew the state of the code, and that it would > not work without a patch containing changes to the machine independent > part, and that followup patches to these branches are likely to be > huge. We should also add a README in arch/parisc that explains the > above (and where to get patches, how to access CVS, etc.). We also > need someone to set up an automatic nightly? patch generator. Agreed. The patch generation is not a big deal to arrange. > I certainly don't want to try to get the machine independent changes in > yet, since we still have some major issues to fix/clean there, and I doubt > Linus would want them at this time anyway. Certainly none of the stack direction changes. Some of the MI stuff is arguably stuff we could put in. -- Revolutions do not require corporate support. From Pirvulescu_Alexandru@telemobil.ro Tue, 21 Nov 2000 20:49:57 +0200 Date: Tue, 21 Nov 2000 20:49:57 +0200 From: Alexandru Pirvulescu Pirvulescu_Alexandru@telemobil.ro Subject: [parisc-linux] case LEDs Hello Is there any possibility to activate the case LEDs? I mean the heartbeat and the network activity I have a A180 machine Alex From grundler@cup.hp.com Tue, 21 Nov 2000 10:55:06 -0800 Date: Tue, 21 Nov 2000 10:55:06 -0800 From: Grant Grundler grundler@cup.hp.com Subject: [parisc-linux] case LEDs "Alexandru Pirvulescu" wrote: > Hello > > Is there any possibility to activate the case LEDs? I mean the heartbeat and > the network activity. I have a A180 machine. Yes. I was already asked this weekend to dig up technical info on LED and soft power control. I guess this is my reminder to do that. :^) grant From grundler@cup.hp.com Tue, 21 Nov 2000 10:59:24 -0800 Date: Tue, 21 Nov 2000 10:59:24 -0800 From: Grant Grundler grundler@cup.hp.com Subject: [parisc-linux] cd .5 Robert Reilly wrote: > Hi All, > I have HP9000/d212 I was able to boot off the cdrom image no problem, > however when I get the login prompt I am only able to type in two > characters and the screen redraws itself and prompts me for a login. I am > using a HP700 serial terminal on ttyS0. I briefly scanned the mailing list > but did not find anything. Any help would be appreciated. Robert, I would suspent the terminal isn't configured correctly for the serial connection. Is it set up for 9600 baud, 8 data bits, no parity, 1 stop bit? I'm pretty sure you have the baud rate correct since you get a login prompt. I'm not sure all the other things must be correct to get that far. I'm not familiar with "HP700 serial terminal". But all the HP terminals I've worked with in the past also support vt100 emulation mode. You probably want to set that too. grant Grant Grundler Unix Systems Enablement Lab +1.408.447.7253 From kailasr@webcash.com Tue, 21 Nov 2000 12:30:12 -0800 Date: Tue, 21 Nov 2000 12:30:12 -0800 From: Kailashnath V Rampure kailasr@webcash.com Subject: [parisc-linux] Apache package. Hi Paul, I have installed Apache + mod_ssl + mod_perl on HP A Class server. I need help on to change the server looking fort bootpd server and put the IP address on the system. Also where can I find the ftp client for linux . Regards Kalas At 04:59 PM 11/15/00 -0700, Paul Bame wrote: >= I tried to build apache_1.3.12 on HP a class server. But I have error. I >= have tried to check the site >= ftp://ftp.debian.org/debian/dists/unstable/main/binary-hppa/ >= I could not find one. I found some apache-doc etc. > >We are still working on some kernel features which are required to >support Apache (system 5 shared memory). > > -P From grundler@cup.hp.com Tue, 21 Nov 2000 13:24:31 -0800 Date: Tue, 21 Nov 2000 13:24:31 -0800 From: Grant Grundler grundler@cup.hp.com Subject: [parisc-linux] CVS linux Vs. -test10 Matthew Wilcox wrote: ... > Someone (probably me) sends him a patch. He told me at the Toronto > show that he was quite happy to apply anything that only touched those > two directories. (oh, and drivers/gsc wouldn't be a problem either). > Can I just check that no-one wants to rename drivers/gsc again? :-) Hi Mathew, I don't and it's a good question. I would like a few files moved: arch/parisc/kernel/ccio-dma.c -> drivers/gsc/ccio-dma.c arch/parisc/kernel/ccio-rm-dma.c -> drivers/gsc/ccio-rm-dma.c ccio will *always* be associated with a GSC bus since that's the secondary bus. And ccio supports devices below dino.c which already lives in drivers/gsc. arch/parisc/kernel/lba_pci.c -> drivers/ropes/lba_pci.c arch/parisc/kernel/sba_iommu.c -> drivers/ropes/sba_iommu.c arch/parisc/kernel/iosapic.c -> drivers/ropes/iosapic.c lba/sba code is equivalent to dino/ccio code for another set of platforms. And long term, I'm certain iosapic.c does not belong under arch/parisc. I can do this move if there are no major objections. Any reason why we couldn't do these moves *after* you submit a patch? FWIW, here are issues I see with merging IA64 iosapic code with mine: o iosapic "discovery" (I invented register_iosapic() interface for parisc) o parisc PDC calls (initialization) o interrupt policy decisions (eg EOI generation and picking a CPU) o I don't have time to do it in the near future. Folks working on IA64 stuff inside HP need to think about: (a) if they want to do the merge any time soon (b) which iosapic.c they want to start with (c) where the final version should live thanks, grant Grant Grundler Unix Systems Enablement Lab +1.408.447.7253 From pjlahaie@linuxcare.com Tue, 21 Nov 2000 16:41:48 -0500 Date: Tue, 21 Nov 2000 16:41:48 -0500 From: Paul J.Y. Lahaie pjlahaie@linuxcare.com Subject: [parisc-linux] Fun build problems --PW0Eas8rCkcu1VkF Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hello everyone, Over the last couple of days, I've been trying to get the debian boot-floppies building (I know some changes will be necessary) and as it stands now, several packages are missing. In the process of trying to compile/install these packages, I've run into some difficulties. Here are some of them: apt -- Package on pehc and .iso do not work. Missing lots of helper apps. Seeing as apt was broken, I decided to download the woody version of apt so I can get a newer version and hopefully skip some steps in building the above packages. gcc 2.96 and apt-0.3.19 don't get along, so I tried picking it up from cvs (supposed to have been fixed). Follow the directions on cvs.debian.org $ cvs -d :pserver:anonymous@cvs.debian.org:/cvs/APT login (Logging in to anonymous@cvs.debian.org) CVS password:=20 cvs login: authorization failed: server cvs.debian.org rejected access Anyone know if there are other instructions other than what cvs.debian.org says? If so, feel free to email me rsync -- ldd crashes on dpkg-shlibdepends stage Can I just manually put the required dependancies in? autoconf -- installinfo spins When installing the autoconf package (to compile dpkg) installinfo spins. And after several minutes still doesn't return. It's taking up 100% cpu at the time. If I abort this, autoconf seems to be installed but cannot generate the dpkg configure properly, some macros are missing AM_CONDITIONAL(HAVE_CPLUSPLUS, test "$CXX" !=3D "") Is in the ./configure script. info -- Reinstall spins If I try to reinstall info, it spins on the uninstall. 100% cpu. If anyone has any solutions for any of the above problems, I am all ears (eyes?). - Paul --PW0Eas8rCkcu1VkF Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.4 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE6Guwc8ggPQthPCzcRAgkGAJ9TzClXOg009RWO/v09ONBNnxJcbgCfcWcX gj26osR06BqyJ0O+/Q83csk= =YHRW -----END PGP SIGNATURE----- --PW0Eas8rCkcu1VkF-- From alan@linuxcare.com.au Wed, 22 Nov 2000 09:50:05 +1100 (EST) Date: Wed, 22 Nov 2000 09:50:05 +1100 (EST) From: Alan Modra alan@linuxcare.com.au Subject: [parisc-linux] Use of the EI_OSABI field cc to binutils because John makes some salient points. On Mon, 20 Nov 2000, John Marvin wrote: > > Another glibc issue (which is why I'm sending this back to the list) is > > that there has been quite some discussion on the binutils list over the > > use of the EI_OSABI field. The conclusion being that it isn't really > > correct to use this field to discern the intendend execution platform. > > It's purpose is really to tell ELF tools that a file contains fields and > > values that need to be interpreted in a non-standard way. Since both > > elf32-hppa and elf64-hppa follow the standards, I'm inclined to think that > > the gnu tools should set EI_OSABI to zero for both HPUX and Linux targets. > > I don't read the binutils mailing list, so I checked the archive. In my > opinion I didn't see a discussion, I saw H.J. Lu repeatedly asserting > this "fact". He may or may not be correct about original intention, but > the implementation so far has been that EI_OSABI is used to tell what the > target platform is. That is what FreeBSD is doing, that is what HP-UX is > doing, and that is what the IA-64 Unix System V Application Binary > Interface specifies: > > http://developer.intel.com/design/IA-64/Downloads/24537002.pdf > > Note that the second paragraph in section 1.1 of that specification > includes the following: > > This document is the result of consensus among operating system > vendors intending to provide UNIX and UNIX workalike operating > systems on the IA-64 architecture. The vendors participating in > this effort include Intel, Sun Microsystems, SCO, IBM, SGI, > Cygnus Solutions, VA Linux Systems, HP, and Compaq. > > So, If the specification is wrong according to H.J. Lu, why did both > Cygnus and VA Linux Systems not object to this: > > Section 4.1.1.4 Operating System Identification > > The e_ident[EI_OSABI] value identifies the operating system and > ABI to which the object is targeted, as listed in Table 4-1. > > Table 4-1 lists the various ELFOSABI_* fields, e.g. ELFOSABI_HPUX, > ELFOSABI_NETBSD, ELFOSABI_LINUX, etc. > > Note also, that the current mechanism for us to be able to differentiate > elf executables in the Linux kernel is the machine dependent > elf_check_arch() macro, whose only argument is a pointer to a > elf32_hdr or elf64_hdr. I think it would be ugly to try to get the > .note.ABI-tag section first for every exec of a new binary in order > to determine what the target ABI is. > > In my opinion, unless H.J. Lu can get the IA-64 ABI changed, it is too > late to assert his view of what that field was supposed to be. Please > leave the EI_OSABI field set to ELFOSABI_LINUX until a better consensus > on this issue is reached. > > John Marvin > jsm@fc.hp.com I'm happy enough to leave things as they are in puffin CVS, but these changes haven't been merged back to sourceware yet, partly because I had some doubts myself as to whether setting EI_OSABI was correct. H.J. Lu wasn't the only one arguing that EI_OSABI should be left at zero; Ulrich Drepper also was quite vehement against changing sourceware FreeBSD binutils. BTW, it's not too hard to check .note.ABI-tag. The linker arranges for a PT_NOTE program header entry to point to it, and the section itself is virtually guaranteed to be read in with the header as it's placed right after the header along with .interp. Alan Modra -- Linuxcare. Support for the Revolution. From drepper@redhat.com 21 Nov 2000 15:27:19 -0800 Date: 21 Nov 2000 15:27:19 -0800 From: Ulrich Drepper drepper@redhat.com Subject: [parisc-linux] Use of the EI_OSABI field Alan Modra writes: > Ulrich Drepper also was quite vehement against changing sourceware > FreeBSD binutils. I've never said anything about any *BSD, why should I? The *BSD people wanted to change the Linux binutils. Anyway, the ABI value is zero unless you implement ELF extensions. -- ---------------. ,-. 1325 Chesapeake Terrace Ulrich Drepper \ ,-------------------' \ Sunnyvale, CA 94089 USA Red Hat `--' drepper at redhat.com `------------------------ From alan@linuxcare.com.au Wed, 22 Nov 2000 11:13:29 +1100 (EST) Date: Wed, 22 Nov 2000 11:13:29 +1100 (EST) From: Alan Modra alan@linuxcare.com.au Subject: [parisc-linux] Use of the EI_OSABI field On 21 Nov 2000, Ulrich Drepper wrote: > Alan Modra writes: > > > Ulrich Drepper also was quite vehement against changing sourceware > > FreeBSD binutils. > > I've never said anything about any *BSD, why should I? The *BSD > people wanted to change the Linux binutils. Sorry, I stated that badly. > Anyway, the ABI value is zero unless you implement ELF extensions. Exactly what is an "ELF extension"? Anything outside gABI or "gABI + psABI"? Handly the latter, as it seems to me that a processor specific ABI can specify extensions. There's also the awkward possibility that a psABI may specify an extension that is later incorporated into a new revision of the gABI (eg. hpux and DT_INIT_ARRAY) Does that mean that if a new revision of the gABI completely incorporates all previous extensions, that EI_OSABI should become zero? Yes, I'm arguing that "No ELF extensions => EI_OSABI == 0" is not necessarily true, but I'm _not_ arguing that changing x86 Linux binutils is wise. Historical usage is important. If we were to change x86 Linux binutils to set EI_OSABI, then that can only be after a considerable period of time to allow code such as glibc to accept a new branding. Alan Modra -- Linuxcare. Support for the Revolution. From drepper@redhat.com 21 Nov 2000 16:31:39 -0800 Date: 21 Nov 2000 16:31:39 -0800 From: Ulrich Drepper drepper@redhat.com Subject: [parisc-linux] Use of the EI_OSABI field Alan Modra writes: > Exactly what is an "ELF extension"? Anything outside gABI or > "gABI + psABI"? Anything beyond the psABI that cannot be handled by the rules in the gABI. -- ---------------. ,-. 1325 Chesapeake Terrace Ulrich Drepper \ ,-------------------' \ Sunnyvale, CA 94089 USA Red Hat `--' drepper at redhat.com `------------------------ From hjl@valinux.com Tue, 21 Nov 2000 16:53:27 -0800 Date: Tue, 21 Nov 2000 16:53:27 -0800 From: H . J . Lu hjl@valinux.com Subject: [parisc-linux] Use of the EI_OSABI field On Wed, Nov 22, 2000 at 11:13:29AM +1100, Alan Modra wrote: > > > Anyway, the ABI value is zero unless you implement ELF extensions. > > Exactly what is an "ELF extension"? Anything outside gABI or ELF extension is something whose interpretation is not documented in neither gABI nor psABI. HP's old ELF is a good example since it didn't implement DT_INIT/DT_FINI, but added DT_INIT_ARRARY/DT_FINI_ARRAY. A normal ELF tool will have a hard time to interpret those fields and their values. H.J. From matthew@wil.cx Wed, 22 Nov 2000 00:53:09 +0000 Date: Wed, 22 Nov 2000 00:53:09 +0000 From: Matthew Wilcox matthew@wil.cx Subject: [parisc-linux] CVS linux Vs. -test10 On Tue, Nov 21, 2000 at 01:24:31PM -0800, Grant Grundler wrote: > I would like a few files moved: > > arch/parisc/kernel/ccio-dma.c -> drivers/gsc/ccio-dma.c > arch/parisc/kernel/ccio-rm-dma.c -> drivers/gsc/ccio-rm-dma.c > arch/parisc/kernel/lba_pci.c -> drivers/ropes/lba_pci.c > arch/parisc/kernel/sba_iommu.c -> drivers/ropes/sba_iommu.c > arch/parisc/kernel/iosapic.c -> drivers/ropes/iosapic.c > Any reason why we couldn't do these moves *after* you submit a patch? Better to get our house in order before we patchbomb Linus, I think. Renames are hard enough in CVS; renames in diff -u format are a real stinker :-) -- Revolutions do not require corporate support. From adevries@linuxcare.com Tue, 21 Nov 2000 21:27:51 -0500 Date: Tue, 21 Nov 2000 21:27:51 -0500 From: Alex deVries adevries@linuxcare.com Subject: [parisc-linux] case LEDs Grant Grundler wrote: > Yes. > I was already asked this weekend to dig up technical info on LED > and soft power control. I guess this is my reminder to do that. :^) Isn't there a PDC call (pdc_chassis?) to do this? Or is the heartbeat LED done by hardware? - Alex -- Alex deVries, Principal Solutions Architect, The Puffins at Linuxcare 613.562.2759 tel alex@linuxcare.com, http://www.linuxcare.com/ Linuxcare, Support for the revolution. From randolph@tausq.org Tue, 21 Nov 2000 18:50:24 -0700 Date: Tue, 21 Nov 2000 18:50:24 -0700 From: Randolph Chung randolph@tausq.org Subject: [parisc-linux] Fun build problems --9zSXsLTf0vkW971A Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable > Seeing as apt was broken, I decided to download the woody version of apt = so > I can get a newer version and hopefully skip some steps in building the > above packages. gcc 2.96 and apt-0.3.19 don't get along, so I tried pick= ing > it up from cvs (supposed to have been fixed). Follow the directions on > cvs.debian.org >=20 > $ cvs -d :pserver:anonymous@cvs.debian.org:/cvs/APT login > (Logging in to anonymous@cvs.debian.org) > CVS password:=20 > cvs login: authorization failed: server cvs.debian.org rejected access Try: cvs -d:pserver:anonymous@cvs.debian.org:/cvs/deity login (empty password) It should work. if not let me know and i can mail you a tarball. You probably want to get the aliencode branch, which has hppa patches. Let me know if you run into any problems. > rsync -- ldd crashes on dpkg-shlibdepends stage > Can I just manually put the required dependancies in? Yes, or pick up the dpkg-architecture and dpkg-shlibdeps scripts from http://puffin.external.hp.com/~tausq/, or wait for the next version of dpkg to get built for hppa (it doesn't use ldd anymore) > autoconf -- installinfo spins >=20 > When installing the autoconf package (to compile dpkg) installinfo spins. > And after several minutes still doesn't return. It's taking up 100% cpu > at the time. hmmm.. didn't see this. I had built a slightly older version of dpkg successfully. randolph (tausq@debian.org) --=20 @..@ http://www.TauSq.org/ (----) ( >__< ) ^^ ~~ ^^ --9zSXsLTf0vkW971A Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.1 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE6GyZgULspdC1Zp9IRAozyAKC/Df1fexltMjFlcwpeYlD+IIWEigCgiGyT YKOjLA0BQzMo7qOj8jC1BTI= =whh1 -----END PGP SIGNATURE----- --9zSXsLTf0vkW971A-- From hjl@valinux.com Tue, 21 Nov 2000 19:11:29 -0800 Date: Tue, 21 Nov 2000 19:11:29 -0800 From: H . J . Lu hjl@valinux.com Subject: [parisc-linux] Use of the EI_OSABI field On Wed, Nov 22, 2000 at 02:03:07PM +1100, Alan Modra wrote: > On Tue, 21 Nov 2000, H . J . Lu wrote: > > > On Wed, Nov 22, 2000 at 11:13:29AM +1100, Alan Modra wrote: > > > > > > > Anyway, the ABI value is zero unless you implement ELF extensions. > > > > > > Exactly what is an "ELF extension"? Anything outside gABI or > > > > ELF extension is something whose interpretation is not documented in > > neither gABI nor psABI. HP's old ELF is a good example since it didn't > > implement DT_INIT/DT_FINI, but added DT_INIT_ARRARY/DT_FINI_ARRAY. A > > normal ELF tool will have a hard time to interpret those fields and > > their values. > > Neither you nor Ulrich have responded to John's point that the IA64 psABI > states > "The e_ident[EI_OSABI] value identifies the operating system and ABI to > which the object is targeted" > > Granted, this is only in a processor specific ABI, but it does flatly > contradict your assertions that the purpose of EI_OSABI is to flag the > presense of ELF extensions. > When I was at the IA64 ABI meeting yesterday, we were looking at the EI_OSABI issue. Everyone at the IA64 ABI meeting agreed that what Ulrich and I had said was the correct understanding. "The e_ident[EI_OSABI] value identifies the operating system and ABI to which the object is targeted" just means if the e_ident[EI_OSABI] value is not ELFOSABI_NONE, you have to look somewhere else in addition to gABI and IA64 psABI to interpret the ELF fields/values specific to that OS. Otherwise, gABI and IA64 psABI are sufficient. -- H.J. Lu (hjl@valinux.com) From drepper@redhat.com 21 Nov 2000 19:18:21 -0800 Date: 21 Nov 2000 19:18:21 -0800 From: Ulrich Drepper drepper@redhat.com Subject: [parisc-linux] Use of the EI_OSABI field Alan Modra writes: > "The e_ident[EI_OSABI] value identifies the operating system and ABI to > which the object is targeted" > > Granted, this is only in a processor specific ABI, but it does flatly > contradict your assertions that the purpose of EI_OSABI is to flag the > presense of ELF extensions. The meaning of the field changed over time. Or better said, some people initially understood it differently. -- ---------------. ,-. 1325 Chesapeake Terrace Ulrich Drepper \ ,-------------------' \ Sunnyvale, CA 94089 USA Red Hat `--' drepper at redhat.com `------------------------ From alan@linuxcare.com.au Wed, 22 Nov 2000 14:03:07 +1100 (EST) Date: Wed, 22 Nov 2000 14:03:07 +1100 (EST) From: Alan Modra alan@linuxcare.com.au Subject: [parisc-linux] Use of the EI_OSABI field On Tue, 21 Nov 2000, H . J . Lu wrote: > On Wed, Nov 22, 2000 at 11:13:29AM +1100, Alan Modra wrote: > > > > > Anyway, the ABI value is zero unless you implement ELF extensions. > > > > Exactly what is an "ELF extension"? Anything outside gABI or > > ELF extension is something whose interpretation is not documented in > neither gABI nor psABI. HP's old ELF is a good example since it didn't > implement DT_INIT/DT_FINI, but added DT_INIT_ARRARY/DT_FINI_ARRAY. A > normal ELF tool will have a hard time to interpret those fields and > their values. Neither you nor Ulrich have responded to John's point that the IA64 psABI states "The e_ident[EI_OSABI] value identifies the operating system and ABI to which the object is targeted" Granted, this is only in a processor specific ABI, but it does flatly contradict your assertions that the purpose of EI_OSABI is to flag the presense of ELF extensions. Alan Modra -- Linuxcare. Support for the Revolution. From rbradetich@uswest.net Tue, 21 Nov 2000 22:54:11 -0800 Date: Tue, 21 Nov 2000 22:54:11 -0800 From: Ryan Bradetich rbradetich@uswest.net Subject: [parisc-linux] CVS linux Vs. -test10 Grant Grundler wrote: > Matthew Wilcox wrote: > ... > > Someone (probably me) sends him a patch. He told me at the Toronto > > show that he was quite happy to apply anything that only touched those > > two directories. (oh, and drivers/gsc wouldn't be a problem either). > > Can I just check that no-one wants to rename drivers/gsc again? :-) > > Hi Mathew, > I don't and it's a good question. > I would like a few files moved: > > arch/parisc/kernel/ccio-dma.c -> drivers/gsc/ccio-dma.c > arch/parisc/kernel/ccio-rm-dma.c -> drivers/gsc/ccio-rm-dma.c Grant, Do you really want to merget the ccio-rm-dma.c file into Linus's tree? It is just a reference file used to construct the real ccio-dma.c file ... I don't believe it is referenced anywhere. I'll double check this in the morning. - Ryan > ccio will *always* be associated with a GSC bus since that's > the secondary bus. And ccio supports devices below dino.c which > already lives in drivers/gsc. > > arch/parisc/kernel/lba_pci.c -> drivers/ropes/lba_pci.c > arch/parisc/kernel/sba_iommu.c -> drivers/ropes/sba_iommu.c > arch/parisc/kernel/iosapic.c -> drivers/ropes/iosapic.c > > lba/sba code is equivalent to dino/ccio code for another set > of platforms. And long term, I'm certain iosapic.c does not > belong under arch/parisc. I can do this move if there are no > major objections. > > Any reason why we couldn't do these moves *after* you submit a patch? > > FWIW, here are issues I see with merging IA64 iosapic code with mine: > o iosapic "discovery" (I invented register_iosapic() interface for parisc) > o parisc PDC calls (initialization) > o interrupt policy decisions (eg EOI generation and picking a CPU) > o I don't have time to do it in the near future. > > Folks working on IA64 stuff inside HP need to think about: > (a) if they want to do the merge any time soon > (b) which iosapic.c they want to start with > (c) where the final version should live > > thanks, > grant > > Grant Grundler > Unix Systems Enablement Lab > +1.408.447.7253 > > --------------------------------------------------------------------------- > To unsubscribe: send e-mail to parisc-linux-request@thepuffingroup.com with > `unsubscribe' as the subject. From jsm@udlkern.fc.hp.com Tue, 21 Nov 2000 23:50:03 -0700 (MST) Date: Tue, 21 Nov 2000 23:50:03 -0700 (MST) From: John Marvin jsm@udlkern.fc.hp.com Subject: [parisc-linux] CVS linux Vs. -test10 > Better to get our house in order before we patchbomb Linus, I think. > Renames are hard enough in CVS; renames in diff -u format are a real > stinker :-) In that case, we need to do some cleanup first. I've been lobbying for the removal of the almost empty arch/parisc/real directory, and its few remaining valid files moved to the kernel directory. There are also a fair number of dead files. Every file that is not currently involved in the build should be removed, unless a good case for it remaining can be made. If the reason to keep it is not a long term reason, then that file should not be sent to Linus (It sounds like it is a lot easier to add files rather than remove/rename them). If there are any files that are currently in use, but which we know will eventually be removed, perhaps we should consider what to do with that file (although I don't know of any files in this category at the moment). John Marvin jsm@fc.hp.com From grundler@cup.hp.com Tue, 21 Nov 2000 23:18:16 -0800 Date: Tue, 21 Nov 2000 23:18:16 -0800 From: Grant Grundler grundler@cup.hp.com Subject: [parisc-linux] CVS linux Vs. -test10 Ryan Bradetich wrote: > Do you really want to merget the ccio-rm-dma.c file into Linus's tree? > It is just a reference file used to construct the real ccio-dma.c file ... I > don't believe it is referenced anywhere. Hi Ryan, Yes I do. It is supposed to work for ccio+PCX-W platforms (eg C360). Keeping it arround will document the pro/con's of that approach and give folks who have time (and the right machine) something to experiment with instead of writing it from scratch. If someone finds an application it's good for (short transactions with low latency requirements perhaps), it's worth having around. It's not referenced because I didn't add a CONFIG_CCIO_RM_IOMMU flag or ccio_rm_init() call to drivers/gsc/gsc.c:gsc_init(). You are welcome add this CONFIG flag by hacking arch/parisc/config.in and defconfig. If you do, please add rules which only allow one or the other CONFIG_CCIO* option to be enabled. thanks, grant Grant Grundler Unix Systems Enablement Lab +1.408.447.7253 From Pirvulescu_Alexandru@telemobil.ro Wed, 22 Nov 2000 09:36:58 +0200 Date: Wed, 22 Nov 2000 09:36:58 +0200 From: Alexandru Pirvulescu Pirvulescu_Alexandru@telemobil.ro Subject: [parisc-linux] case LEDs I think that the heartbeat LED is software because it starts with the kernel boot and if the kernel stops the LED stops blinking too. Is better to implement a software monitoring tool because you have to watch the software for hanging. Alex PS. There is a function in the kernel source in linux/arch/parisc/kernel/process.c named machine_heartbeat(). Any connection with the heartbeat from the chassis? ----- Original Message ----- From: "Alex deVries" To: "Grant Grundler" Cc: "Alexandru Pirvulescu" ; Sent: Wednesday, November 22, 2000 4:27 AM Subject: Re: [parisc-linux] case LEDs > Grant Grundler wrote: > > Yes. > > I was already asked this weekend to dig up technical info on LED > > and soft power control. I guess this is my reminder to do that. :^) > > Isn't there a PDC call (pdc_chassis?) to do this? Or is the heartbeat > LED done by hardware? > > - Alex > > -- > Alex deVries, Principal Solutions Architect, The Puffins at Linuxcare > 613.562.2759 tel > alex@linuxcare.com, http://www.linuxcare.com/ > Linuxcare, Support for the revolution. > > From bvalkema@knowhowww.nl Wed, 22 Nov 2000 06:32:51 +0100 Date: Wed, 22 Nov 2000 06:32:51 +0100 From: Bas Valkema bvalkema@knowhowww.nl Subject: [parisc-linux] case LEDs Alex deVries wrote: > Grant Grundler wrote: > > Yes. > > I was already asked this weekend to dig up technical info on LED > > and soft power control. I guess this is my reminder to do that. :^) > > Isn't there a PDC call (pdc_chassis?) to do this? Or is the heartbeat > LED done by hardware? > > - Alex A couple of months ago, I asked the same question, got answer to look in the mkLinux sources. I did, and I think it was a register (outb(0xblabla);). Wrote a driver (and for WAX, got a Intel Flash 32 EISA running), can't release it now, because of some copyright issues... Bas From grundler@cup.hp.com Tue, 21 Nov 2000 23:56:35 -0800 Date: Tue, 21 Nov 2000 23:56:35 -0800 From: Grant Grundler grundler@cup.hp.com Subject: [parisc-linux] CVS linux Vs. -test10 John Marvin wrote: > In that case, we need to do some cleanup first. John, I want a task list which leads us to a submital to linus. That's why I listed the specific files I wanted moved. Can you come up with (or ask someone else to come up) with a list of files which meet your criteria? All of your criteria sounds reasonable to me. But I don't have a feel of which files meet your criteria. If someone makes the task list, I'm happy to help with items and verify the result works. thanks, grant From jsm@udlkern.fc.hp.com Wed, 22 Nov 2000 01:11:57 -0700 (MST) Date: Wed, 22 Nov 2000 01:11:57 -0700 (MST) From: John Marvin jsm@udlkern.fc.hp.com Subject: [parisc-linux] CVS linux Vs. -test10 > Ryan Bradetich wrote: > > Do you really want to merget the ccio-rm-dma.c file into Linus's tree? > > It is just a reference file used to construct the real ccio-dma.c file ... I > > don't believe it is referenced anywhere. > > Hi Ryan, > Yes I do. It is supposed to work for ccio+PCX-W platforms (eg C360). > Keeping it arround will document the pro/con's of that approach and > give folks who have time (and the right machine) something to experiment > with instead of writing it from scratch. If someone finds an application > it's good for (short transactions with low latency requirements perhaps), > it's worth having around. > > It's not referenced because I didn't add a CONFIG_CCIO_RM_IOMMU flag > or ccio_rm_init() call to drivers/gsc/gsc.c:gsc_init(). You are welcome > add this CONFIG flag by hacking arch/parisc/config.in and defconfig. > If you do, please add rules which only allow one or the other > CONFIG_CCIO* option to be enabled. > Well, personally i'd vote to get rid of it. It works for ONE machine only, and MAY have an advantage in some small case. But if we keep it, lets make sure that it is real clear that it should NOT be the default choice. It should be marked CONFIG_EXPERIMENTAL, and the text associated with it should clearly show that it works on a C360 only. If possible, it should also be made clear that ccio-dma.c works for C360, so people who have C360's don't think they have to choose ccio-rm-dma.c. Grant, I hope you are prepared to answer the parisc-linux mailing list questions this is going to generate once parisc-linux starts becoming more visible. Another FAQ entry perhaps? :-) John Marvin jsm@fc.hp.com From jsm@udlkern.fc.hp.com Wed, 22 Nov 2000 01:52:04 -0700 (MST) Date: Wed, 22 Nov 2000 01:52:04 -0700 (MST) From: John Marvin jsm@udlkern.fc.hp.com Subject: [parisc-linux] Use of the EI_OSABI field > > BTW, it's not too hard to check .note.ABI-tag. The linker arranges for a > PT_NOTE program header entry to point to it, and the section itself is > virtually guaranteed to be read in with the header as it's placed right > after the header along with .interp. I didn't say it was difficult, I said it was ugly. It means another parisc only change to the machine independent file fs/binfmt_elf.c, since the hook provided will not allow this check. Without a change, binfmt_elf.c won't be smart enough to differentiate a binary produced by Gnu binutils for HP-UX and a binary produced by Gnu binutils for Linux, so it will claim both, and then blow up later, rather than not claiming the HP-UX binary and allowing it to be claimed by an arch dependent binary handler further down the list. And binfmt_elf.c does NOT read the program headers in the same read, so another read would have to be done (the data should be found in in cache rather than going to disk for it). Since we now need both the program headers and a section header to determine whether or not we should claim the file AND binfmt_elf.c also wants to look at those headers after the file is claimed, a small redesign is probably in order (rather than re-reading the headers). I'm not sure whether or not Linus would buy that. So, I guess I'll pursue the interpreter field instead, since that is what sparc is doing (i.e. they have their own sparc only code in binfmt_elf.c). Since that will be an easier sell. I need to do more research here. I suspect that statically linked binaries are not going to allow this solution to work though. John Marvin jsm@fc.hp.com From alan@linuxcare.com.au Wed, 22 Nov 2000 23:28:45 +1100 (EST) Date: Wed, 22 Nov 2000 23:28:45 +1100 (EST) From: Alan Modra alan@linuxcare.com.au Subject: [parisc-linux] binutils update I've just committed a change to binutils that cures an ELF spec violation. We now no longer create plabels for DT_INIT and DT_FINI and instead rely on the dynamic linker to create them for us. This means you need an updated glibc, that I committed a little earlier today, to create the plabel function pointers if you update your binutils. You have been warned... Alan Modra -- Linuxcare. Support for the Revolution. From bruno_vidal@hpfrcu03.france.hp.com Wed, 22 Nov 2000 15:14:18 +0100 Date: Wed, 22 Nov 2000 15:14:18 +0100 From: Bruno Vidal bruno_vidal@hpfrcu03.france.hp.com Subject: [parisc-linux] Crash dump module Hi Good news, I've finished to recompile the entire chain on hpux 11.00 64bits. I've recompile my own kernel and booted a small 712/60. It work pretty well. Now I'm going to start the work about crash dump. So, In my mind, I'll start from the linux/kernel/panic.c function and I'll add a function dumpsys.c in the linux/arch/paric directory -> is it okay for you ? It will depend on the CONFIG_PARISC var (or do you prefer adding a CONFIG_DUMPSYS var ?) thanks. -- Vidal Bruno, (770-4271) SSD-HA Team, HP-UX & LINUX Support bruno_vidal@admin.france.hp.com From randolph@tausq.org Wed, 22 Nov 2000 07:44:24 -0700 Date: Wed, 22 Nov 2000 07:44:24 -0700 From: Randolph Chung randolph@tausq.org Subject: [parisc-linux] Crash dump module > It will depend on the CONFIG_PARISC var (or do you prefer adding a CONFIG_DUMPSYS var ?) I think there was a consensus to use __hppa__ instead of CONFIG_PARISC ... randolph -- @..@ http://www.TauSq.org/ (----) ( >__< ) ^^ ~~ ^^ From mike_clapper@hp.com Wed, 22 Nov 2000 07:54:24 -0800 Date: Wed, 22 Nov 2000 07:54:24 -0800 From: CLAPPER,MIKE (HP-USA,ex1) mike_clapper@hp.com Subject: [parisc-linux] B132L boot hang Hello Everyone, I download the cross-compilers and build a lifimage on Redhat 6.1. I set up nfsroot on a S712 running hpux 10.20. With this I am able to boot a B132L running pdc 6.1 - almost. I get a hang right after - VFS: Mounted root (nfs filesystem) readonly Warning: unable to open an initial console I have a 700/96 on serial port 1 as the console. I have hpux on a disc in the unit I'm trying to boot - from HPUX I have verified I can nfs mount the filesys I'm using for NFSROOT. With linux in this condition the machine will respond to ping. I will also react to a telnet - i get the telnet banner then "connection closed by foreign host". FTP gets "connection refused" - so it' partially alive..... Is there a way to keyword search the developers archive? I vaguely recall seeing the 'initial console' warning, but couldn't find it browsing the developers archive Thanks, Mike ********************************************** Mike Clapper North American Crisis Management Team Hewlett Packard (405) 948-4715 ********************************************** From bame@noam.fc.hp.com Wed, 22 Nov 2000 09:02:03 -0700 Date: Wed, 22 Nov 2000 09:02:03 -0700 From: Paul Bame bame@noam.fc.hp.com Subject: [parisc-linux] CVS linux Vs. -test10 = I've been lobbying for = the removal of the almost empty arch/parisc/real directory, and its few = remaining valid files moved to the kernel directory. Done. arch/parisc/real R.I.P. From grundler@cup.hp.com Wed, 22 Nov 2000 08:27:22 -0800 Date: Wed, 22 Nov 2000 08:27:22 -0800 From: Grant Grundler grundler@cup.hp.com Subject: [parisc-linux] Crash dump module Bruno Vidal wrote: > Hi > Good news, I've finished to recompile the entire chain on hpux 11.00 64bits. > I've recompile my own kernel and booted a small 712/60. It work pretty well. > Now I'm going to start the work about crash dump. So, In my mind, I'll start > from the linux/kernel/panic.c function and I'll add a function dumpsys.c > in the linux/arch/paric directory -> is it okay for you ? YES! > It will depend on the CONFIG_PARISC var > (or do you prefer adding a CONFIG_DUMPSYS var ?) As Randolph pointed out CONFIG_PARISC is deprecated. Use "ifdef __hppa__" for changes in *common* (ie not arch/parisc) files. They should not be needed for anything in arch/parisc or linux/include/asm-parisc. Adding a CONFIG_DUMPSYS is a good idea. Look in linux/arch/parisc/config.in, linux/arch/parisc/defconfig, and the various Makefiles for how CONFIG_* flags work. thanks Bruno! grant Grant Grundler Unix Systems Enablement Lab +1.408.447.7253 From grundler@cup.hp.com Wed, 22 Nov 2000 09:27:20 -0800 Date: Wed, 22 Nov 2000 09:27:20 -0800 From: Grant Grundler grundler@cup.hp.com Subject: [parisc-linux] B132L boot hang "CLAPPER,MIKE (HP-USA,ex1)" wrote: > > > Hello Everyone, > > I download the cross-compilers and build a lifimage on Redhat 6.1. I set > up nfsroot on a S712 running hpux 10.20. With this I am able to boot a > B132L running pdc 6.1 - > almost. I get a hang right after - > > VFS: Mounted root (nfs filesystem) readonly > Warning: unable to open an initial console I think I need more output. Based on ioscan output, the B132L has two serial ports: 8/16/4 - off of LASI 8/20/2 - of WAX (EISA Bus Adapter) (GSCtoPCI is at 8/0) I don't think the one off of WAX is supported right now. Are you using the default .config produced by "make oldconfig"? It's also possible the LASI support is broken on B132L and I would expect some console output indicating what's wrong. > I have a 700/96 on serial port 1 as the console. I have hpux on a disc in > the unit I'm trying to boot - from HPUX I have verified I can nfs mount the > filesys I'm using for NFSROOT. NFS root mounted fine. Console is the problem. ... > Is there a way to keyword search the developers archive? I vaguely recall > seeing the 'initial console' warning, but couldn't find it browsing the > developers archive Yes - http://puffin.external.hp.com/cgi-bin/mailgrep grant Grant Grundler Unix Systems Enablement Lab +1.408.447.7253 From cary@cup.hp.com Wed, 22 Nov 2000 10:06:05 -0800 Date: Wed, 22 Nov 2000 10:06:05 -0800 From: Cary Coutant cary@cup.hp.com Subject: [parisc-linux] Use of the EI_OSABI field As the original author of the proposal to add the EI_OSABI field to the ELF format, let me try to clarify the intent of this field. The authoritative definition of this field is found in SCO's gABI document, which is still the official specification for the ELF format (this is probably posted somewhere on SCO's web site). Here's what it says: Byte e_ident[EI_OSABI] identifies the operating system and ABI to which the object is targeted. Some fields in other ELF structures have flags and values that have operating system and/or ABI specific meanings; the interpretation of those fields is determined by the value of this byte. The value of this byte must be interpreted differently for each machine. That is, each value for the e_machine field determines a set of values for the EI_OSABI byte. Values are assigned by the ABI processor supplement for each machine. If the processor supplement does not specify a set of values, the value 0 shall be used and indicates unspecified. The first sentence is still a bit misleading, and is an artifact of the original proposal. Originally, the field was intended to identify the target ABI (hence the name of the field). As we started discussing a common Unix ABI for IA-64, however, it became clear that this field wouldn't serve that purpose, but it was still needed to identify the set of platform-specific ELF extensions that are used by the object file. There are a number of fields in the ELF format for which ranges of values or a set of flag bits are reserved for vendor-specific use (e.g., SHT_LOOS through SHT_HIOS for vendor-specific section types, and SHF_MASKOS for vendor-specific section attributes). If an object file uses any of these values or flag bits, the consumer of the file must consult the EI_OSABI field to determine what those values or flags mean. It works just like the e_machine field does for attaching meaning to processor-specific values and flags. The intent is that any ABI-conforming implementation will be able to execute an ABI-conforming binary, even if it uses certain vendor-specific features. In many cases, those vendor-specific features are hints for a particular OS that can be ignored by other implementations. Where this is not the case, and a vendor-specific feature must be understood by the system in order to process the file correctly, we have a couple of alternatives. For section types and flags that a linker must understand, we have the SHF_OS_NONCONFORMING flag -- if set, and a linker doesn't understand a particular section type or flag, it must reject the file. For executables that will execute only on a particular implementation, we must use an alternate interpreter (PT_INTERP) or bind to implementation-specific shared libraries. An ABI-conforming binary will use the interpreter specified in the psABI spec, and will use only system libraries specified there. For statically-bound programs, I'm afraid we don't have a clear solution. We took the general approach that such programs are not ABI-conforming in the first place, and can use any mechanism they might choose to verify that they are executing on the appropriate implementation. -cary From grundler@cup.hp.com Wed, 22 Nov 2000 11:55:38 -0800 Date: Wed, 22 Nov 2000 11:55:38 -0800 From: Grant Grundler grundler@cup.hp.com Subject: [parisc-linux] CVS linux Vs. -test10 John Marvin wrote: > Grant Grundler wrote: > > Yes I do. It is supposed to work for ccio+PCX-W platforms (eg C360). ... > Well, personally i'd vote to get rid of it. It works for ONE machine only, > and MAY have an advantage in some small case. And so does the OB600 mouse driver I rewrote/published. AFAIK, it only works on OB600s. I was originally thinking D/K/R-class boxes had PCX-W upgrades but AFAICT, they don't. > But if we keep it, lets make > sure that it is real clear that it should NOT be the default choice. > > It should be marked CONFIG_EXPERIMENTAL, and the text associated with it > should clearly show that it works on a C360 only. If possible, it should > also be made clear that ccio-dma.c works for C360, so people who have > C360's don't think they have to choose ccio-rm-dma.c. IIRC, Comments in the headers of both ccio files make those issues clear. I'm not sure where else that needs to be documented. > Grant, I hope you are prepared to answer the parisc-linux mailing list > questions this is going to generate once parisc-linux starts becoming more > visible. Another FAQ entry perhaps? :-) Ryan owns it. He's responsible for documenting it and adding FAQ questions. He can choose to delete ccio-rm-dma.c as well. :^) I think it'd be a waste to throw it away before someone figures out that it's really not useful - even if just for C360. thanks, grant From mike_clapper@hp.com Wed, 22 Nov 2000 12:05:23 -0800 Date: Wed, 22 Nov 2000 12:05:23 -0800 From: CLAPPER,MIKE (HP-USA,ex1) mike_clapper@hp.com Subject: [parisc-linux] B132L boot hang Thanks Grant, I verified the console is off 8/16/4.0 and that it is the LASI port. I also downloaded the newest cross-compiler and source code. After rebuilding the palo lifimage I get the same hang in the same place. Since I was cabled to a dumb terminal I was not able to capture the boot output. I will find the right cable to hook up to my pc so I can capture the output and send it to you - perhaps an error occurred earlier in the boot that I overlooked. Thanks for the help. Mike -----Original Message----- From: Grant Grundler [mailto:grundler@cup.hp.com] Sent: Wednesday, November 22, 2000 11:27 AM To: CLAPPER,MIKE (HP-USA,ex1) Cc: 'parisc-linux@thepuffingroup.com' Subject: Re: [parisc-linux] B132L boot hang "CLAPPER,MIKE (HP-USA,ex1)" wrote: > > > Hello Everyone, > > I download the cross-compilers and build a lifimage on Redhat 6.1. I set > up nfsroot on a S712 running hpux 10.20. With this I am able to boot a > B132L running pdc 6.1 - > almost. I get a hang right after - > > VFS: Mounted root (nfs filesystem) readonly > Warning: unable to open an initial console I think I need more output. Based on ioscan output, the B132L has two serial ports: 8/16/4 - off of LASI 8/20/2 - of WAX (EISA Bus Adapter) (GSCtoPCI is at 8/0) I don't think the one off of WAX is supported right now. Are you using the default .config produced by "make oldconfig"? It's also possible the LASI support is broken on B132L and I would expect some console output indicating what's wrong. > I have a 700/96 on serial port 1 as the console. I have hpux on a disc in > the unit I'm trying to boot - from HPUX I have verified I can nfs mount the > filesys I'm using for NFSROOT. NFS root mounted fine. Console is the problem. ... > Is there a way to keyword search the developers archive? I vaguely recall > seeing the 'initial console' warning, but couldn't find it browsing the > developers archive Yes - http://puffin.external.hp.com/cgi-bin/mailgrep grant Grant Grundler Unix Systems Enablement Lab +1.408.447.7253 --------------------------------------------------------------------------- To unsubscribe: send e-mail to parisc-linux-request@thepuffingroup.com with `unsubscribe' as the subject. From kirkb@chrome.rose.hp.com Wed, 22 Nov 2000 12:10:10 PST Date: Wed, 22 Nov 2000 12:10:10 PST From: Kirk Bresniker kirkb@chrome.rose.hp.com Subject: [parisc-linux] CVS linux Vs. -test10 Grant Grundler wrote: | I was originally thinking D/K/R-class boxes had PCX-W upgrades but | AFAICT, they don't. | The C-class upgrade to PCX-W was a one-off. Upgrades for similar enterprise servers were not designed. KMB -- +============================================================+ | Kirk Bresniker (916) 748-2393 | | 8000 Foothills Blvd | | Roseville, CA 95747-5649 | | kirkb@rose.hp.com | From grundler@cup.hp.com Wed, 22 Nov 2000 12:11:23 -0800 Date: Wed, 22 Nov 2000 12:11:23 -0800 From: Grant Grundler grundler@cup.hp.com Subject: [parisc-linux] CVS linux Vs. -test10 Grant Grundler wrote: ... > arch/parisc/kernel/ccio-dma.c -> drivers/gsc/ccio-dma.c > arch/parisc/kernel/ccio-rm-dma.c -> drivers/gsc/ccio-rm-dma.c > > ccio will *always* be associated with a GSC bus since that's > the secondary bus. And ccio supports devices below dino.c which > already lives in drivers/gsc. Ryan - moving/keeping these files is up to you. I was just sharing what I thought was "right". Apologies for not making that clear earlier. > arch/parisc/kernel/lba_pci.c -> drivers/ropes/lba_pci.c > arch/parisc/kernel/sba_iommu.c -> drivers/ropes/sba_iommu.c > arch/parisc/kernel/iosapic.c -> drivers/ropes/iosapic.c I've talked to one of the folks working on IA64-linux. They are interested in merging iosapic code but haven't even looked at the parisc version I wrote. We talked a bit about the issues and it doesn't sound like it's going to happen anytime soon. In any case, iosapic.c doesn't belong under "drivers/ropes". So none of this needs to move in the forseeable future. It can all stay in arch/parisc/kernel. grant Grant Grundler Unix Systems Enablement Lab +1.408.447.7253 From deller@gmx.de Wed, 22 Nov 2000 21:43:40 +0100 Date: Wed, 22 Nov 2000 21:43:40 +0100 From: Helge Deller deller@gmx.de Subject: [parisc-linux] B132L boot hang > I think I need more output. Based on ioscan output, the B132L > has two serial ports: > 8/16/4 - off of LASI > 8/20/2 - of WAX (EISA Bus Adapter) > > (GSCtoPCI is at 8/0) > > I don't think the one off of WAX is supported right now. It should be detected & supported (at least it is on my B160L). But it is not used as initial console since it normally gets assigned as ttyS1 while LASI-serial gets ttyS0. Greetings, Helge. From bame@noam.fc.hp.com Wed, 22 Nov 2000 16:03:12 -0700 Date: Wed, 22 Nov 2000 16:03:12 -0700 From: Paul Bame bame@noam.fc.hp.com Subject: [parisc-linux] 64-bit progress 32-bit syscalls on 64-bit kernel are to the point where a few things work, and signals appear to be working (I didn't implement *all* the signal-related syscalls yet). I'll be continuing to produce syscall wrappers for a while... If you try to boot the standard NFS root with wide kernel, you'll want to mv sbin/init sbin/init-real then compile and install this program as sbin/init: int main() { char *argv[2]; argv[0] = "/sbin/init-real"; argv[1] = 0; execv(argv[0], argv); } I never felt comfortable I found the point where sys_execve figures out it needs to pack the argv vector differently for narrow user apps (locally I also am using PER_LINUX32 in binfmt_elf32.c) which causes the initial exec(/sbin/init) to be passed incomprehensible arguments. This program is a little temporary workaround. -Paul Bame From alan@linuxcare.com.au Thu, 23 Nov 2000 11:18:20 +1100 (EST) Date: Thu, 23 Nov 2000 11:18:20 +1100 (EST) From: Alan Modra alan@linuxcare.com.au Subject: glibc On Wed, 22 Nov 2000, Matt Taggart wrote: > Hi Alan, > > First a timezone question... your mail headers have you in +11 and Ft. Collins > is -7 so you're 6 hours behind + 1 day relative to us? So as I send this it's > 14:05 here and 8:05 there? Hi Matt, I'm actually on +10:30 in Adelaide, but posting from a Linuxcare machine in Canberra which is on +11. >[snip segfaults] > I am building native using dhd's binutils/gcc/glibc debs, using source checked > out just after the glibc 2.2 merge. Do you think the merge / ld.so changes you > just made would help this problem at all? Quite likely. This fix * sysdeps/hppa/dl-machine.h (ELF_MACHINE_START_ADDRESS): Define. is fairly crucial, as without it %dp will not be set correctly. I should have mentioned this when posting to the list about the binutils change. Oh, and as of this email, I haven't actually run anything linked to the new glibc. A little remiss, I know, but I've been deep in the gdb port, and if I spend time tinkering with glibc, binutils and gcc (which I like), gdb (which I don't like) will never be finished. ;-) Alan -- Linuxcare. Support for the Revolution. From grundler@cup.hp.com Wed, 22 Nov 2000 18:24:52 -0800 (PST) Date: Wed, 22 Nov 2000 18:24:52 -0800 (PST) From: Grant Grundler grundler@cup.hp.com Subject: [parisc-linux] new SBA IOMMU version committed Hi all, I've committed my "second generation" I/O MMU code for C3K/J5k boxes. It's only tested for 32-bit. I'll be testing 64-bit shortly. This code makes "perfect" use of the I/O pdir resource map and we shouldn't see any panics due to out_of_resource. grant From grundler@cup.hp.com Wed, 22 Nov 2000 18:47:06 -0800 (PST) Date: Wed, 22 Nov 2000 18:47:06 -0800 (PST) From: Grant Grundler grundler@cup.hp.com Subject: [parisc-linux] CONFIG_DMB_TRAP diff Hello again (last one until Monday - I promise), With Lamont's wisdom, I implemented support for Date Memory Break trap. This enables the kernel programmer to capture the evil code which stomps on other people's "private" data. Only works for stores through virtual addresses. gsc_writeX() and DMA will still bypass this mechanism. pb, dhd, (or some equivalent deity), could you review/commit this code? Or tell me it's ok to commit? I've touched: arch/parisc/config.in arch/parisc/kernel/entry.S arch/parisc/mm/kmap.c include/asm-parisc/pgtable.h thanks, grant Index: arch/parisc/config.in =================================================================== RCS file: /home/cvs/parisc/linux/arch/parisc/config.in,v retrieving revision 1.25 diff -u -p -r1.25 config.in --- config.in 2000/10/20 18:28:26 1.25 +++ config.in 2000/11/23 02:18:23 @@ -16,8 +16,12 @@ endmenu mainmenu_option next_comment comment 'General options' -# bool 'Symmetric multi-processing support' CONFIG_SMP -define_bool CONFIG_SMP n +bool 'Symmetric multi-processing support' CONFIG_SMP +# define_bool CONFIG_SMP n + +# One needs to tweak dmb_trap_11 code in entry.S to match. +# Not tested for 64-bit kernel. +bool 'Debug support for Data Memory Break Trap' CONFIG_DMB_TRAP bool 'Kernel Debugger support' CONFIG_KWDB # define_bool CONFIG_KWDB n Index: arch/parisc/kernel/entry.S =================================================================== RCS file: /home/cvs/parisc/linux/arch/parisc/kernel/entry.S,v retrieving revision 1.53 diff -u -p -r1.53 entry.S --- entry.S 2000/11/22 16:51:33 1.53 +++ entry.S 2000/11/23 02:18:23 @@ -23,6 +23,7 @@ */ #include +#include /* the following is the setup i think we should follow: * whenever the CPU is interruptible, the following has to be true: @@ -349,7 +350,39 @@ .endm #endif +#ifdef CONFIG_DMB_TRAP /* + ** Data Memory Bit trap interruption handler (parisc 1.1) + ** + ** This is a debugging aid. Use it when you think someone else + ** is stepping on your memory. It only catches *virtual* + ** accesses. gsc_writeX() functions disable virtual translation + ** (D-bit) and will happily scribble whatever physical address + ** is passed in. + ** + ** Here's how to use it: + ** 1) Call iterate_pages() from your init routine like this: + ** iterate_pages( my_private_mem, private_mem_size, + ** set_data_memory_break, 0); + ** 2) substitute your functions for your_function1 (or 2) in + ** dmb_trap_11 code below. + ** + ** Thanks to Lamont Jones for telling me how to do this. + ** - ggg 1/22/2000 + */ + .macro dmb_11 code + + mfctl %isr,spc + b dmb_trap_11 + mfctl %ior,va + + .align 32 + .endm +#else +#define dmb_11 def +#endif + + /* * dirty bit trap interruption handler (parisc 2.0) */ @@ -448,7 +481,7 @@ fault_vector_11: naitlb_11 16 nadtlb_11 17 def 18 - def 19 + dmb_11 19 dbit_11 20 def 21 def 22 @@ -467,7 +500,6 @@ fault_vector_11: .import handle_interruption,code .import handle_real_interruption,code .import do_irq_mask,code - .import parisc_stopkernel,code .import cpu_irq_region,data /* @@ -903,11 +935,15 @@ dtlb_miss_11: dep pte,8,7,prot extru,= pte,_PAGE_NO_CACHE_BIT,1,r0 - depi 1,12,1,prot + depi 1,12,1,prot /* U-bit */ extru,= pte,_PAGE_USER_BIT,1,r0 depi 7,11,3,prot /* Set for user space (1 rsvd for read) */ extru,= pte,_PAGE_GATEWAY_BIT,1,r0 depi 0,11,2,prot /* If Gateway, Set PL2 to 0 */ +#ifdef CONFIG_DMB_TRAP + extru,= pte,_PAGE_DMB_BIT,1,r0 + depi 1,4,1,prot /* B-bit */ +#endif /* Get rid of prot bits and convert to page addr for idtlba */ @@ -1300,6 +1336,30 @@ dbit_trap_11: rfir nop + +#ifdef CONFIG_DMB_TRAP + .import your_function1,code + .import your_function2,code + +dmb_trap_11: + mfctl pcsq,t0 /* get space */ + comb,<>,n t0,%r0,dmb_rfi /* not kernel - bail */ + + mfctl pcoq,t0 /* get offset */ + ldil L%dmb_ok_function1, t1 + dep %r0, 31, 12, t0 + comb,=,n t0,t1,dmb_rfi /* it's ours - bail */ + + ldil L%dmb_ok_function2, t1 + comb,<>,n t0,t1,intr_save /* not ours - panic */ + +dmb_rfi: + mfctl ipsw,t0 /* Set PSW X-bit - just continue */ + depi 1,11,1,t0 /* Set X-bit */ + mtctl t0, ipsw + rfir + nop +#endif dbit_trap_20: mfctl %cr25,ptp /* Assume user space trap */ Index: arch/parisc/mm/kmap.c =================================================================== RCS file: /home/cvs/parisc/linux/arch/parisc/mm/kmap.c,v retrieving revision 1.3 diff -u -p -r1.3 kmap.c --- kmap.c 2000/05/05 18:05:47 1.3 +++ kmap.c 2000/11/23 02:18:23 @@ -43,7 +43,16 @@ static void unmap_cached_pte(pte_t * pte } #endif +#ifdef CONFIG_DMB_TRAP /* These two routines should probably check a few things... */ +void set_data_memory_break(pte_t * pte, unsigned long arg) +{ + pte_val(*pte) |= _PAGE_DMB; +} + +#endif + +/* These two routines should probably check a few things... */ static void set_uncached(pte_t * pte, unsigned long arg) { pte_val(*pte) |= _PAGE_NO_CACHE; @@ -106,7 +115,10 @@ static inline void iterate_pmd(pgd_t * d } while (address < end); } -static void iterate_pages(unsigned long address, unsigned long size, +#ifndef CONFIG_DMB_TRAP +static +#endif +void iterate_pages(unsigned long address, unsigned long size, pte_iterator_t op, unsigned long arg) { pgd_t *dir; Index: include/asm-parisc/pgtable.h =================================================================== RCS file: /home/cvs/parisc/linux/include/asm-parisc/pgtable.h,v retrieving revision 1.29 diff -u -p -r1.29 pgtable.h --- pgtable.h 2000/11/10 21:44:44 1.29 +++ pgtable.h 2000/11/23 02:18:23 @@ -109,6 +109,10 @@ extern void *vmalloc_start; #define _PAGE_USER 0x400 /* Software: User accessable page */ #define _PAGE_USER_BIT 21 /* Needs to agree with _PAGE_USER above */ /* 0x800 still available */ +#ifdef CONFIG_DMB_TRAP +#define _PAGE_DMB 0x800 /* Data Memory Break Trap */ +#define _PAGE_DMB_BIT 20 /* Data Memory Break Trap */ +#endif #ifdef __ASSEMBLY__ #define _PGB_(x) (1 << (63 - (x))) From jsm@udlkern.fc.hp.com Wed, 22 Nov 2000 22:50:14 -0700 (MST) Date: Wed, 22 Nov 2000 22:50:14 -0700 (MST) From: John Marvin jsm@udlkern.fc.hp.com Subject: [parisc-linux] CONFIG_DMB_TRAP diff > > Hello again (last one until Monday - I promise), > > With Lamont's wisdom, I implemented support for Date Memory Break trap. > > This enables the kernel programmer to capture the evil code which > stomps on other people's "private" data. Only works for stores > through virtual addresses. gsc_writeX() and DMA will still > bypass this mechanism. > > pb, dhd, (or some equivalent deity), could you review/commit this code? > Or tell me it's ok to commit? > > I've touched: > arch/parisc/config.in > arch/parisc/kernel/entry.S > arch/parisc/mm/kmap.c > include/asm-parisc/pgtable.h > Please don't. This solution is way more complicated than it should be. Here are the problems with it: 1) As I had already mentioned in a previous discussion, the pte's already reserve the location for the B bit (data memory break trap) and the dtlb miss handlers already move the entire group of bits that include this bit in one operation. So no change is necessary to the dtlb miss handlers to specially set that bit and incur extra instructions in the tlb miss handlers, and no extra bits need to be allocated in the pte. Instead of adding a new definition (e.g. 0x800, which is our last available bit) use the one that is already reserved for it: 0x010. 2) There is no reason to add a special data memory break trap handler. The general trap handler is more than sufficient for this case. handle_interruption will be called if a data memory break trap is encountered. Just add a new case for the list of traps, and handle the trap in C. You can set the X bit by simply setting it in the saved ipsw (in gr[0]) and it will be set upon return from the trap, no muss, no fuss. Note that the above also applies for the page reference trap. The T bit is also already supported (0x040 in the pte) by the dtlb miss handlers. Note that the reason I reserved these bits is because it would actually take MORE code in the dtlb miss handlers to NOT support those bits and use them for something else. Another helpful hint for those wanting to use this feature. If you are tracking corruptions that span multiple pages, then just setting the B bit on each page may be all you need. But, when I've used the data memory break trap for corruption tracking, typically I've wanted to track a corruption that was happening to a particular variable, i.e. a 4 byte quantity, and lots of other variables were being legitimately written on the same page, so you wind up with thousands of data memory break traps, where only one may be the one that is corrupting the location you are interested in. But, all is not lost, the solution is still fairly simple. The data memory break trap provides a valid iir, isr and ior. So once you get the trap, a custom data memory break handler (which can be written with a few lines of C in handle_interruption), simply uses iir, isr and ior to check if the access was to the specific byte or bytes you are interested in. I've simply used isr/ior to check for writes within the word I was interested in. That may be enough for most cases. The information you are missing from isr/ior is the size of the write transaction. To get this you would need to parse the instruction stored in iir (code to determine the size of a store from the instruction in the iir will be necessary when an unaligned fault handler is written). John Marvin jsm@fc.hp.com From jsm@udlkern.fc.hp.com Thu, 23 Nov 2000 01:29:55 -0700 (MST) Date: Thu, 23 Nov 2000 01:29:55 -0700 (MST) From: John Marvin jsm@udlkern.fc.hp.com Subject: [parisc-linux] CONFIG_DMB_TRAP diff Alan Modra wrote: > > gdb will eventually want to use this trap too. > Cool! However, data memory break traps for user translations are a little tougher. There are some small modifications in the machine dependent code that I can make to make sure the B bit stays set during most VM operations on a page. However, since the machine independent part of the VM system doesn't know anything about this bit (nor should it), it won't be preserved if the page is paged out (and subsequently paged back in). This could be fixed fairly easily with some changes to the machine independent code, but I don't think that would be appropriate. Some potential solutions (each has its problems): 1) Just document the fact that the feature may not work on systems with low memory. It's a parisc only feature, so perhaps we could live with that. 2) Lock the page in memory (using the mlock interface) when we set the B bit on a page. Just some thoughts on the subject. John Marvin jsm@fc.hp.com From pjlahaie@linuxcare.com Fri, 24 Nov 2000 16:56:16 -0500 Date: Fri, 24 Nov 2000 16:56:16 -0500 From: Paul J.Y. Lahaie pjlahaie@linuxcare.com Subject: [parisc-linux] boot-floppies dependancies --GRPZ8SYKNexpdSJ7 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline I would like to know if anyone has built any of the following packages that are needed for the boot-floppies. Currently, the missing deps are: cspsfonts man-db tetex-bin recode cslatex libpaperg tetex-extra libnewt-dev libgd1g-dev gawk libi18n-langtags-perl dpkg-awk debiandoc-sgml I'm currently trying to get a working apt, since the one of pehc and the .iso seem to be broken (no xfer methods). I'll let everyone know when a working copy will be available. - Paul --GRPZ8SYKNexpdSJ7 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.4 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE6HuP/8ggPQthPCzcRAnyKAJ0fyraVXEvlI0yQLsli7FlnUUAPdwCfSyv/ YgAxOcVMDgWfHBc7lneuc1Y= =tScM -----END PGP SIGNATURE----- --GRPZ8SYKNexpdSJ7-- From doneill@linuxcare.com Fri, 24 Nov 2000 17:01:00 -0500 (EST) Date: Fri, 24 Nov 2000 17:01:00 -0500 (EST) From: Dave O'Neill doneill@linuxcare.com Subject: [parisc-linux] strace? So, I've heard rumours that somewhere there's a working strace for parisc.... Can anyone point me in the right direction? Dave -- Dave O'Neill, Senior Linux Consultant, Linuxcare, Inc. desk: (613) 562-9949 fax: (613) 562-9700 cell: (613) 223-0219 doneill@linuxcare.com http://www.linuxcare.com/ From obrien@FreeBSD.org Sat, 25 Nov 2000 12:22:11 -0800 Date: Sat, 25 Nov 2000 12:22:11 -0800 From: David O'Brien obrien@FreeBSD.org Subject: [parisc-linux] Use of the EI_OSABI field On Tue, Nov 21, 2000 at 03:27:19PM -0800, Ulrich Drepper wrote: > Alan Modra writes: > > > Ulrich Drepper also was quite vehement against changing sourceware > > FreeBSD binutils. > > I've never said anything about any *BSD, why should I? The *BSD > people wanted to change the Linux binutils. No (don't put words in my mouth Ulrich as you'll be wrong 99% of the time). I wanted the Sourceware Binutils to set the EI_OSABI to "ELFOSABI_LINUX" when targeting Linux. -- -- David (obrien@FreeBSD.org) From obrien@FreeBSD.org Sat, 25 Nov 2000 12:28:40 -0800 Date: Sat, 25 Nov 2000 12:28:40 -0800 From: David O'Brien obrien@FreeBSD.org Subject: [parisc-linux] Use of the EI_OSABI field On Tue, Nov 21, 2000 at 07:11:29PM -0800, H . J . Lu wrote: > When I was at the IA64 ABI meeting yesterday, we were looking at the > EI_OSABI issue. Everyone at the IA64 ABI meeting agreed that what > Ulrich and I had said was the correct understanding. > > "The e_ident[EI_OSABI] value identifies the operating system and ABI > to which the object is targeted" just means if the e_ident[EI_OSABI] Then is this *extremely* misleading text going to be changed??? "the operating system and" needs to be deleted in the _official_ _published_ specification. -- -- David (obrien@FreeBSD.org) From obrien@FreeBSD.org Sat, 25 Nov 2000 12:31:08 -0800 Date: Sat, 25 Nov 2000 12:31:08 -0800 From: David O'Brien obrien@FreeBSD.org Subject: [parisc-linux] Use of the EI_OSABI field On Tue, Nov 21, 2000 at 07:18:21PM -0800, Ulrich Drepper wrote: > Alan Modra writes: > > "The e_ident[EI_OSABI] value identifies the operating system and ABI to > > which the object is targeted" > > > > Granted, this is only in a processor specific ABI, but it does flatly > > contradict your assertions that the purpose of EI_OSABI is to flag the > > presense of ELF extensions. > > The meaning of the field changed over time. Or better said, some > people initially understood it differently. Then lets get the _official_ wording changed. Obviously my interpretation wasn't unreasonable. And the world does not need to have you as a premadona keeper of the [unwritten] rules of the land. -- -- David (obrien@FreeBSD.org) From hjl@valinux.com Sat, 25 Nov 2000 12:33:40 -0800 Date: Sat, 25 Nov 2000 12:33:40 -0800 From: H . J . Lu hjl@valinux.com Subject: [parisc-linux] Use of the EI_OSABI field On Sat, Nov 25, 2000 at 12:28:40PM -0800, David O'Brien wrote: > On Tue, Nov 21, 2000 at 07:11:29PM -0800, H . J . Lu wrote: > > When I was at the IA64 ABI meeting yesterday, we were looking at the > > EI_OSABI issue. Everyone at the IA64 ABI meeting agreed that what > > Ulrich and I had said was the correct understanding. > > > > "The e_ident[EI_OSABI] value identifies the operating system and ABI > > to which the object is targeted" just means if the e_ident[EI_OSABI] > > > Then is this *extremely* misleading text going to be changed??? > "the operating system and" needs to be deleted in the _official_ > _published_ specification. > I will bring this issue up to ia64 psABI and gABI. -- H.J. Lu (hjl@valinux.com) From alan@lxorguk.ukuu.org.uk Sat, 25 Nov 2000 20:57:05 +0000 (GMT) Date: Sat, 25 Nov 2000 20:57:05 +0000 (GMT) From: Alan Cox alan@lxorguk.ukuu.org.uk Subject: [parisc-linux] RPM and hppa I've uploaded my first block of RPM packages to ftp.linux.org.uk/pub/linux/alan/HPPA along with a tar ball of built RPM tools for anyone who wants to play. In doing so I've hit a few problems with the 0.5 iso (no suprises there since its not actually meant to work reliably) - g++ explodes trying to build groff after allocating about 400Mb of RAM. Building -O0 works - the configure script for procmail tries to find the largest argument set that works (by searching). It crashes the kernel in doing so 8) - ldd is causing page faults in ld.so (kernel logged ones) and dying with segv. Fortunately it outputs the library list first - The linker appears to have a problem when resolving symbols between three shared objects while doing a shared object link. [Example is rpm: rpmlib is linked dynamically with -ldb3 -ldb The linker emits messages about symbols being static and should be built -fPIC. If you dump the libraries they are -fPIC. It looks as if its resolving a symbol between two shared libraries and making a static resolution that then blows up when the third library gets involved ] - The kernel shows occasional page cache corruption. This actually is quite possibly generic test6 bugs On the whole the toolset is working remarkably well. I've built over 100 source package sets so far including things like ncurses and most stuff just builds or hits portability problems (eg gmp wants to use HP format asm, zlib wants to be a non PIC library for performance but the HP tools dont allow it) Alan From alan@linuxcare.com.au Sun, 26 Nov 2000 23:01:50 +1100 (EST) Date: Sun, 26 Nov 2000 23:01:50 +1100 (EST) From: Alan Modra alan@linuxcare.com.au Subject: [parisc-linux] RPM and hppa On Sat, 25 Nov 2000, Alan Cox wrote: > - g++ explodes trying to build groff after allocating about 400Mb of RAM. > Building -O0 works Yeah, this is a known issue. I see on the gcc list that rth and others have been working on gcc fixes recently that should address the problem. I don't have the time/ability to fix it myself. > - the configure script for procmail tries to find the largest argument set > that works (by searching). It crashes the kernel in doing so 8) > > - ldd is causing page faults in ld.so (kernel logged ones) and dying with > segv. Fortunately it outputs the library list first How old are your glibc and binutils? I made some changes late October that should have fixed this problem. See http://puffin.external.hp.com/mailing-lists/parisc-linux/2000/10-Oct/0146.html Does "readelf -d" on your hppa-linux ld.so show you have a DT_TEXTREL tag? > - The linker appears to have a problem when resolving symbols between three > shared objects while doing a shared object link. > > [Example is rpm: > > rpmlib is linked dynamically with -ldb3 -ldb > > The linker emits messages about symbols being static and should be > built -fPIC. If you dump the libraries they are -fPIC. > > It looks as if its resolving a symbol between two shared libraries > and making a static resolution that then blows up when the third > library gets involved > > ] Could you put all the objects involved in the link up for ftp somewhere? I've just built rpm-2.5.6 without seeing this problem, but I'm sure my setup is different to yours... Regards, Alan Modra -- Linuxcare. Support for the Revolution. From alan@lxorguk.ukuu.org.uk Sun, 26 Nov 2000 12:12:21 +0000 (GMT) Date: Sun, 26 Nov 2000 12:12:21 +0000 (GMT) From: Alan Cox alan@lxorguk.ukuu.org.uk Subject: [parisc-linux] RPM and hppa > How old are your glibc and binutils? I made some changes late October From the 0.5 cdrom > http://puffin.external.hp.com/mailing-lists/parisc-linux/2000/10-Oct/0146.html > Does "readelf -d" on your hppa-linux ld.so show you have a DT_TEXTREL tag? Nope > Could you put all the objects involved in the link up for ftp > somewhere? I've just built rpm-2.5.6 without seeing this problem, but I'm > sure my setup is different to yours... rpm 4.0. rpm2 doesnt do that 3 way link with db and db3. I'll put them up when I get a bit of time From dave@hiauly1.hia.nrc.ca Sun, 26 Nov 2000 11:45:08 -0500 (EST) Date: Sun, 26 Nov 2000 11:45:08 -0500 (EST) From: John David Anglin dave@hiauly1.hia.nrc.ca Subject: [parisc-linux] RPM and hppa > On Sat, 25 Nov 2000, Alan Cox wrote: > > > - g++ explodes trying to build groff after allocating about 400Mb of RAM. > > Building -O0 works > > Yeah, this is a known issue. I see on the gcc list that rth and others > have been working on gcc fixes recently that should address the problem. > I don't have the time/ability to fix it myself. I think the above is a different problem. The explosion is most likely a problem with exception edges in the gcse pass. Try `-fno-gcse'. This also appears in the tFile.cc libio test. The pa port uses sjlj exceptions via __builtin_setjmp/longjmp. A nonlocal goto label is used for the target of the longjmp. The flow analysis assumes that an "exception" could jump to any label in the procedure rather than just the label associated with the exception region. Dave -- J. David Anglin dave.anglin@nrc.ca National Research Council of Canada (613) 990-0752 (FAX: 952-6605) From cwalthall@cwalthall.com Sun, 26 Nov 2000 11:45:38 -0600 Date: Sun, 26 Nov 2000 11:45:38 -0600 From: Carl & Delores Walthall cwalthall@cwalthall.com Subject: [parisc-linux] RPM and hppa Does anyone know where I can find the operating system for the HP9000 J200 Server? Thanks Carl Walthall ----- Original Message ----- From: "Alan Modra" To: "Alan Cox" Cc: Sent: Sunday, November 26, 2000 6:01 AM Subject: Re: [parisc-linux] RPM and hppa > On Sat, 25 Nov 2000, Alan Cox wrote: > > > - g++ explodes trying to build groff after allocating about 400Mb of RAM. > > Building -O0 works > > Yeah, this is a known issue. I see on the gcc list that rth and others > have been working on gcc fixes recently that should address the problem. > I don't have the time/ability to fix it myself. > > > - the configure script for procmail tries to find the largest argument set > > that works (by searching). It crashes the kernel in doing so 8) > > > > - ldd is causing page faults in ld.so (kernel logged ones) and dying with > > segv. Fortunately it outputs the library list first > > How old are your glibc and binutils? I made some changes late October > that should have fixed this problem. See > http://puffin.external.hp.com/mailing-lists/parisc-linux/2000/10-Oct/0146.ht ml > Does "readelf -d" on your hppa-linux ld.so show you have a DT_TEXTREL tag? > > > - The linker appears to have a problem when resolving symbols between three > > shared objects while doing a shared object link. > > > > [Example is rpm: > > > > rpmlib is linked dynamically with -ldb3 -ldb > > > > The linker emits messages about symbols being static and should be > > built -fPIC. If you dump the libraries they are -fPIC. > > > > It looks as if its resolving a symbol between two shared libraries > > and making a static resolution that then blows up when the third > > library gets involved > > > > ] > > Could you put all the objects involved in the link up for ftp > somewhere? I've just built rpm-2.5.6 without seeing this problem, but I'm > sure my setup is different to yours... > > Regards, Alan Modra > -- > Linuxcare. Support for the Revolution. > > > -------------------------------------------------------------------------- - > To unsubscribe: send e-mail to parisc-linux-request@thepuffingroup.com with > `unsubscribe' as the subject. > From cwalthall@cwalthall.com Sun, 26 Nov 2000 11:47:24 -0600 Date: Sun, 26 Nov 2000 11:47:24 -0600 From: Carl & Delores Walthall cwalthall@cwalthall.com Subject: [parisc-linux] RPM and hppa Hi All I have a HP9000 J200 server and would like to find the operating system software for it. Can you tell me where to look on the internet or who I may call? The server has a OS installed but no one can remember the user or password information. So they gave it to me to take home, is there a way to boot it on a floppy and change this information? Thanks for any information you can give me! Carl walthall ----- Original Message ----- From: "John David Anglin" To: "Alan Modra" Cc: ; Sent: Sunday, November 26, 2000 10:45 AM Subject: Re: [parisc-linux] RPM and hppa > > On Sat, 25 Nov 2000, Alan Cox wrote: > > > > > - g++ explodes trying to build groff after allocating about 400Mb of RAM. > > > Building -O0 works > > > > Yeah, this is a known issue. I see on the gcc list that rth and others > > have been working on gcc fixes recently that should address the problem. > > I don't have the time/ability to fix it myself. > > I think the above is a different problem. The explosion is most likely > a problem with exception edges in the gcse pass. Try `-fno-gcse'. This > also appears in the tFile.cc libio test. > > The pa port uses sjlj exceptions via __builtin_setjmp/longjmp. A > nonlocal goto label is used for the target of the longjmp. The flow > analysis assumes that an "exception" could jump to any label in the > procedure rather than just the label associated with the exception > region. > > Dave > -- > J. David Anglin dave.anglin@nrc.ca > National Research Council of Canada (613) 990-0752 (FAX: 952-6605) > > -------------------------------------------------------------------------- - > To unsubscribe: send e-mail to parisc-linux-request@thepuffingroup.com with > `unsubscribe' as the subject. > From alan@lxorguk.ukuu.org.uk Sun, 26 Nov 2000 22:47:43 +0000 (GMT) Date: Sun, 26 Nov 2000 22:47:43 +0000 (GMT) From: Alan Cox alan@lxorguk.ukuu.org.uk Subject: [parisc-linux] Linker failure with db1 I replaced the libdb1 on the ISO with one built using the toolchain on the ISO and all is now happy. From grundler@cup.hp.com Sun, 26 Nov 2000 19:11:41 -0800 Date: Sun, 26 Nov 2000 19:11:41 -0800 From: Grant Grundler grundler@cup.hp.com Subject: [parisc-linux] RPM and hppa "Carl & Delores Walthall" wrote: > Hi All > > I have a HP9000 J200 server and would like to find the operating system > software for it. Can you tell me where to look on the internet or who I may > call? Carl, The short answer is a port of linux to the J200 is in progress. See http://www.parisc-linux.org/ for status. If you have more questions read the FAQ and check the mailing list archives using http://puffin.external.hp.com/cgi-bin/mailgrep first please. > The server has a OS installed but no one can remember the user or password > information. So they gave it to me to take home, is there a way to boot > it on a floppy and change this information? Here's how to "fix" this: During power up/boot press key to get "BOOT ADMIN>" prompt. type "bo pri isl". At "ISL>" prompt, type "hpux -is". HPUX should boot to single user. use "mountall" or "mount -a" to mount all file systems. Then you can "vi /etc/passwd" or "passwd root". If that doesn't work and you can afford to loan the box out for a 3-4 monthes, you might ask if someone could install parisc-linux on it for you in exchange for a few monthes use. grant Grant Grundler Unix Systems Enablement Lab +1.408.447.7253 From grundler@cup.hp.com Sun, 26 Nov 2000 22:12:10 -0800 Date: Sun, 26 Nov 2000 22:12:10 -0800 From: Grant Grundler grundler@cup.hp.com Subject: [parisc-linux] case LEDs Alex deVries wrote: > Grant Grundler wrote: > > I was already asked this weekend to dig up technical info on LED > > and soft power control. I guess this is my reminder to do that. :^) I dug up the info but it's not in a form I'm willing to publishing. However, someone did volunteer to look at this and I've provided them with this info. So it will make into our CVS source tree and get published that way. > Isn't there a PDC call (pdc_chassis?) to do this? Not AFAICT. PDC_CHASSIS is documented in the pdc32.pdf found on http://www.parisc-linux.org/documentation.html But my gut feeling is parisc specific code could make some PDC_CHASSIS calls to set up "sysstat" field (eg initialize, shutdown, run states). Does anyone know if the chassis codes used by HPUX are published? It would be cool if parisc-linux used the same codes where possible... > Or is the heartbeat LED done by hardware? Code I've looked at before seems to all do it in software. grant Grant Grundler Unix Systems Enablement Lab +1.408.447.7253 From sanjak@tipas.lt Mon, 27 Nov 2000 09:09:22 +0200 Date: Mon, 27 Nov 2000 09:09:22 +0200 From: Aleksandr Konstantinov sanjak@tipas.lt Subject: [parisc-linux] how to boot ? Hello, All. We have two HP Workstations here (Model 735). I would like to try linux on one of them. But I have no disk space to install all the stuff (binutils, compiler, etc) . I found precompiled kernel on puffin.external.hp.com but it looks like I also need palo . Does anybody know, where to get precompiled palo for hpux9, hpux10 or linux-x86 ? Thanks in advance. A.K. From rhirst@linuxcare.com Mon, 27 Nov 2000 09:18:21 +0000 Date: Mon, 27 Nov 2000 09:18:21 +0000 From: Richard Hirst rhirst@linuxcare.com Subject: [parisc-linux] strace? Hi Dave, The source is in cvs on pehc; I can supply a binary if you want one. I havn't made serious use of it, but it does basically work. Richard On Fri, Nov 24, 2000 at 05:01:00PM -0500, Dave O'Neill wrote: > > So, I've heard rumours that somewhere there's a working strace for > parisc.... Can anyone point me in the right direction? > > Dave > -- > Dave O'Neill, Senior Linux Consultant, Linuxcare, Inc. > desk: (613) 562-9949 fax: (613) 562-9700 cell: (613) 223-0219 > doneill@linuxcare.com http://www.linuxcare.com/ > > --------------------------------------------------------------------------- > To unsubscribe: send e-mail to parisc-linux-request@thepuffingroup.com with > `unsubscribe' as the subject. > > From alan@lxorguk.ukuu.org.uk Mon, 27 Nov 2000 16:55:36 +0000 (GMT) Date: Mon, 27 Nov 2000 16:55:36 +0000 (GMT) From: Alan Cox alan@lxorguk.ukuu.org.uk Subject: [parisc-linux] RPM and hppa > I think the above is a different problem. The explosion is most likely > a problem with exception edges in the gcse pass. Try `-fno-gcse'. This > also appears in the tFile.cc libio test. I've not yet had a chance to try this. I see the same behaviour building Qt so I may try it on that From marteaut@esiee.fr Mon, 27 Nov 2000 18:11:36 +0000 Date: Mon, 27 Nov 2000 18:11:36 +0000 From: marteau marteaut@esiee.fr Subject: [parisc-linux] Hi all, We have tried to compile the new linux source today and vmlinux always needs pci.o to link. It works if you delete pci.o from the objects list in the kernel Makefile. But, we don't know why it was needed because we did not ask for in our "make config"... We appreciate any help! THX, ESIEE Team From dave@hiauly1.hia.nrc.ca Mon, 27 Nov 2000 12:13:02 -0500 (EST) Date: Mon, 27 Nov 2000 12:13:02 -0500 (EST) From: John David Anglin dave@hiauly1.hia.nrc.ca Subject: [parisc-linux] RPM and hppa > > > I think the above is a different problem. The explosion is most likely > > a problem with exception edges in the gcse pass. Try `-fno-gcse'. This > > also appears in the tFile.cc libio test. > > I've not yet had a chance to try this. I see the same behaviour building Qt > so I may try it on that Another option that might help if exceptions aren't needed is `-fno-exceptions'. Dave -- J. David Anglin dave.anglin@nrc.ca National Research Council of Canada (613) 990-0752 (FAX: 952-6605) From grundler@cup.hp.com Mon, 27 Nov 2000 09:57:39 -0800 Date: Mon, 27 Nov 2000 09:57:39 -0800 From: Grant Grundler grundler@cup.hp.com Subject: No subject marteau wrote: > We have tried to compile the new linux source today and vmlinux > always needs pci.o to link. It works if you delete pci.o from the > objects list in the kernel Makefile. But, we don't know why it was > needed because we did not ask for in our "make config"... Hi Thomas, The problem is in arch/parisc/kernel/Makefile. It doesn't use CONFIG_PCI to decide if pci.o is needed. I'll fix that now - should be simple. thanks, grant From dave@hiauly1.hia.nrc.ca Mon, 27 Nov 2000 13:19:52 -0500 (EST) Date: Mon, 27 Nov 2000 13:19:52 -0500 (EST) From: John David Anglin dave@hiauly1.hia.nrc.ca Subject: [parisc-linux] RPM and hppa > > I think the above is a different problem. The explosion is most likely > > a problem with exception edges in the gcse pass. Try `-fno-gcse'. This > > also appears in the tFile.cc libio test. > > I've not yet had a chance to try this. I see the same behaviour building Qt > so I may try it on that If the problem is in fact the exception handling method, I think we should look at implementing the DWARF2 unwind mechanism and exception handling using this unwind mechanism. The default method of handling exceptions is sjlj. See the description of DWARF2_UNWIND_INFO and INCOMING_RETURN_ADDR_RTX in gcc/tm.texi for more info. Alan Modra may want this for gdb as well. Dave -- J. David Anglin dave.anglin@nrc.ca National Research Council of Canada (613) 990-0752 (FAX: 952-6605) From alan@lxorguk.ukuu.org.uk Mon, 27 Nov 2000 18:34:23 +0000 (GMT) Date: Mon, 27 Nov 2000 18:34:23 +0000 (GMT) From: Alan Cox alan@lxorguk.ukuu.org.uk Subject: [parisc-linux] gcc crashes/out of memory and groff With groff -fno-gcse does not help but -O0 does. Without -O0 you get an internal error. g++ -I. -I/usr/src/redhat/BUILD/groff-1.16/src/roff/troff -I/usr/src/redhat/BUILD/groff-1.16/src/include -I/usr/src/redhat/BUILD/groff-1.16/src/include -DHAVE_UNISTD_H=1 -DHAVE_DIRENT_H=1 -DHAVE_LIMITS_H=1 -DHAVE_SYS_DIR_H=1 -DHAVE_STDLIB_H=1 -DHAVE_STRINGS_H=1 -DSTDLIB_H_DECLARES_PUTENV=1 -DSTDIO_H_DECLARES_POPEN=1 -DSTDIO_H_DECLARES_PCLOSE=1 -DHAVE_SYS_NERR=1 -DHAVE_SYS_ERRLIST=1 -DHAVE_CC_LIMITS_H=1 -DRETSIGTYPE=void -DHAVE_STRUCT_EXCEPTION=1 -DHAVE_UNISTD_H=1 -DHAVE_GETPAGESIZE=1 -DHAVE_MMAP=1 -DHAVE_FMOD=1 -DHAVE_STRTOL=1 -DHAVE_GETCWD=1 -DHAVE_STRERROR=1 -DHAVE_PUTENV=1 -DHAVE_RENAME=1 -DHAVE_MKSTEMP=1 -DHAVE_STRCASECMP=1 -DHAVE_STRSEP=1 -DHAVE_STRDUP=1 -DSYS_SIGLIST_DECLARED=1 -O2 -mpa-risc-1-0 -fno-gcse -c env.cc env.cc: In member function `void environment::output_line (node *, hunits)': env.cc:1582: Internal error: Segmentation fault. Please submit a full bug report. See for instructions. make[2]: *** [env.o] Error 1 make[2]: Leaving directory `/usr/src/redhat/BUILD/groff-1.16/src/roff/troff' Alan From marteaut@esiee.fr Mon, 27 Nov 2000 21:31:09 +0100 Date: Mon, 27 Nov 2000 21:31:09 +0100 From: Thomas Marteau marteaut@esiee.fr Subject: [parisc-linux] Include trouble Hi folks, Just to know if it is a local problem. We have this warning when we cross compile the kernel: /linux/cvs/linux/include/linux/string.h:61: warning: conflicting types for built-in function `memset' /linux/cvs/linux/include/linux/string.h:64: warning: conflicting types for built-in function `memcpy' /linux/cvs/linux/include/linux/string.h:73: warning: conflicting types for built-in function `memcmp' Can we have your point of view? Bye, ESIEE Team From marteaut@esiee.fr Tue, 28 Nov 2000 00:17:24 +0100 Date: Tue, 28 Nov 2000 00:17:24 +0100 From: Thomas Marteau marteaut@esiee.fr Subject: [parisc-linux] Leds Hi all, We tried to implement the led power of 712 hp boxes. We call leds_init in main.c in init directory. Even though it is working, we are not sure where to put the source that must be completed for others models. We could make a LEDS directory in drivers put the file in the kernel directory We also put the source for the initialisation of keyboard leds in lasi_ps2_reset but we admit that no led is on. Is it true? How can we know? THX, ESIEE Team From alan@linuxcare.com.au Tue, 28 Nov 2000 12:12:03 +1100 (EST) Date: Tue, 28 Nov 2000 12:12:03 +1100 (EST) From: Alan Modra alan@linuxcare.com.au Subject: [parisc-linux] gcc crashes/out of memory and groff On Mon, 27 Nov 2000, Alan Cox wrote: > With groff -fno-gcse does not help but -O0 does. Without -O0 you get an > internal error. Cross compiling from an x86-linux box with enough memory+swap (256M + 2G), env.cc eventually compiled for me using the default -O2 optimisation level. I had a crash later when compiling preproc/tbl/table.cc, so that's nothing to boast about. table.cc: In member function `void table::build_span_list ()': table.cc:2009: Internal error: Segmentation fault. Worse, when I added "-Q -da" to see what was happening, the compile succeeded - and also succeeded with either of -Q or -da alone. So I ran cc1plus under gdb, and that too failed to crash. :-( Maybe a garbage collection or uninitialised var bug? Alan Modra -- Linuxcare. Support for the Revolution. From alan@linuxcare.com.au Tue, 28 Nov 2000 15:59:54 +1100 (EST) Date: Tue, 28 Nov 2000 15:59:54 +1100 (EST) From: Alan Modra alan@linuxcare.com.au Subject: [parisc-linux] Include trouble On Mon, 27 Nov 2000, Thomas Marteau wrote: > Can we have your point of view? Your version of gcc expects the size_t parameter to all these functions to be "unsigned int", whereas the 2000/11/18 changes to linux/include/asm-parisc/posix_types.h made __kernel_size_t "unsigned long". As far as I understand, gcc's cpp has a built-in definition of size_t, __SIZE_TYPE__, and it ultimately gets it's idea of the definition from the kernel includes on the machine where gcc was compiled. ie. recompile gcc with the new kernel headers installed, and the problem should go away. For 32-bit hppa-linux, sizeof(int) == sizeof(long) so there shouldn't be any practical consequence other than these warning messages. There might be some "interesting" problems on hppa64-linux - I'm not sure. Alan Modra -- Linuxcare. Support for the Revolution. From alan@linuxcare.com.au Tue, 28 Nov 2000 20:19:20 +1100 (EST) Date: Tue, 28 Nov 2000 20:19:20 +1100 (EST) From: Alan Modra alan@linuxcare.com.au Subject: [parisc-linux] Include trouble On Tue, 28 Nov 2000, Alan Modra wrote: > As far as I understand, gcc's cpp has a built-in definition of size_t, > __SIZE_TYPE__, and it ultimately gets it's idea of the definition from the > kernel includes on the machine where gcc was compiled. ie. recompile gcc > with the new kernel headers installed, and the problem should go away. No, that's wrong. __SIZE_TYPE__ comes from `#define SIZE_TYPE' in gcc/config/pa/pa-linux{,64}.h I'll check in a patch to gcc in a few moments. Alan -- Linuxcare. Support for the Revolution. From marteaut@esiee.fr Tue, 28 Nov 2000 16:07:04 +0100 Date: Tue, 28 Nov 2000 16:07:04 +0100 From: Thomas Marteau marteaut@esiee.fr Subject: [parisc-linux] Mouse driver for PS/2 Hi all, We appreciate if someone can explain where we can find request_irq and request_region in hp_psaux.c and also, what are they doing? Thanks, ESIEE Team From deller@gmx.de Tue, 28 Nov 2000 18:21:34 +0100 Date: Tue, 28 Nov 2000 18:21:34 +0100 From: Helge Deller deller@gmx.de Subject: [parisc-linux] Mouse driver for PS/2 On Tuesday 28 November 2000 16:07, Thomas Marteau wrote: > Hi all, Hi Thomas, > > We appreciate if someone can explain where we can find request_irq #include and /arch/parisc/kernel/irq.c request_irq() binds the given interrupt-number to a function (if possible). > and > request_region #include request_region only marks (and tests) an I/O-region as used by a driver and makes this information visible via /proc/iomem and /proc/ioports. > in hp_psaux.c and also, > what are they doing? > > Thanks, > ESIEE Team From wferguson@server01.chatspace.com Tue, 28 Nov 2000 09:35:36 -0800 Date: Tue, 28 Nov 2000 09:35:36 -0800 From: William Ferguson wferguson@server01.chatspace.com Subject: [parisc-linux] PDC firmware revision FAQ update This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C05961.9E1AB8A8 Content-Type: text/plain; charset="iso-8859-1" Is the web server at www.parisc-linux.org down? Can't seem to connect from San Diego. -----Original Message----- From: Grant Grundler [mailto:grundler@cup.hp.com] Sent: Friday, November 17, 2000 1:51 PM To: parisc-linux@puffin.external.hp.com Subject: [parisc-linux] PDC firmware revision FAQ update Hi folks, The issue of PDC/firmware revs came up locally and sounded like a FAQ. I added "10. How can I check if the PDC (firmware) revision is the latest?" and what I knew/could find to our FAQ at: http://www.parisc-linux.org/faq.html The new FAQ entry should be visible to the world in the next hour or so. **** WARNING **** Firmware upgrades can *kill* your machine! **** WARNING **** Don't do it just because. Read the FAQ carefully. Take the time to figure out why you might need the upgrade and expose yourself to this risk. grant ps. please don't ask me why your favorite machine's PDC isn't listed. I don't run the referenced sites. --------------------------------------------------------------------------- To unsubscribe: send e-mail to parisc-linux-request@thepuffingroup.com with `unsubscribe' as the subject. ------_=_NextPart_001_01C05961.9E1AB8A8 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [parisc-linux] PDC firmware revision FAQ update

Is the web server at www.parisc-linux.org down?  = Can't seem to connect from San Diego.

-----Original Message-----
From: Grant Grundler [mailto:grundler@cup.hp.com]
Sent: Friday, November 17, 2000 1:51 PM
To: parisc-linux@puffin.external.hp.com
Subject: [parisc-linux] PDC firmware revision FAQ = update


Hi folks,

The issue of PDC/firmware revs came up locally and = sounded like a FAQ.
I added

    "10. How can I check if the = PDC (firmware) revision is the latest?"

and what I knew/could find to our FAQ at:

        http://www.parisc-linux.org/faq.html

The new FAQ entry should be visible to the world in = the next hour or so.


    **** WARNING ****
    Firmware upgrades can *kill* your = machine!
    **** WARNING ****

Don't do it just because. Read the FAQ carefully. = Take the
time to figure out why you might need the upgrade = and expose
yourself to this risk.

grant

ps. please don't ask me why your favorite machine's = PDC isn't listed.
   I don't run the referenced = sites.

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

------_=_NextPart_001_01C05961.9E1AB8A8-- From dave@hiauly1.hia.nrc.ca Tue, 28 Nov 2000 12:37:28 -0500 (EST) Date: Tue, 28 Nov 2000 12:37:28 -0500 (EST) From: John David Anglin dave@hiauly1.hia.nrc.ca Subject: [parisc-linux] Include trouble > On Tue, 28 Nov 2000, Alan Modra wrote: > > > As far as I understand, gcc's cpp has a built-in definition of size_t, > > __SIZE_TYPE__, and it ultimately gets it's idea of the definition from the > > kernel includes on the machine where gcc was compiled. ie. recompile gcc > > with the new kernel headers installed, and the problem should go away. > > No, that's wrong. __SIZE_TYPE__ comes from `#define SIZE_TYPE' in > gcc/config/pa/pa-linux{,64}.h I'll check in a patch to gcc in a few > moments. Hmm. Most 32 bit systems use "unsigned int" rather than "unsigned long". Using "unsigned long" might cause problems with packages like libio. I know there is a problem if off_t is not the same as size_t. Dave -- J. David Anglin dave.anglin@nrc.ca National Research Council of Canada (613) 990-0752 (FAX: 952-6605) From grundler@cup.hp.com Tue, 28 Nov 2000 09:49:26 -0800 Date: Tue, 28 Nov 2000 09:49:26 -0800 From: Grant Grundler grundler@cup.hp.com Subject: [parisc-linux] Mouse driver for PS/2 Thomas Marteau wrote: > Hi all, > > We appreciate if someone can explain where we can find request_irq and > request_region in hp_psaux.c and also, what are they doing? include/linux/sched.h:extern int request_irq(unsigned int, ...) (Implementation is in arch/parisc/kernel/irq.c) The request_irq() "allocates" an IRQ line for use by the device - this program the PIC (or APIC) on x86 platforms. request_irq() is also how an interrupt handler is associated with a specific IRQ line. Since PA Risc CPU's don't have IRQ lines going into them, IRQ's are virtualized and don't always represent a physical IRQ line. Under LASI, see gsc_alloc_irq(&gsc_irq) usage in drivers/gsc/lasi.c. lasi_find_irq() helps associate the PS/2 interrupt handler with the correct IRQ line which is internal to lasi. include/linux/ioport.h:#define request_region(start,n,name) ... request_region() will reserve a range of I/O port address from the global I/O space. request_mem_region() does the same for MMIO. Drivers that use inb/outb (as defined in include/asm-parisc/io.h) must use request_region(). Drivers that use gsc_readb/gsc_writeb (as defined in include/asm-parisc/gsc.h) must use request_mem_region(). Collisions are probably occuring where a driver originally used inb/outb and those were redefined to use gsc_readb/writeb functions. But the driver is still using request_region(). And it doesn't help that I may have broken some of the resource mgt with some code I committed last night. It worked on my boxes (A180/C3K) but broke on other folks. Paul Bame helped find/fix one bug but I shouldn't be surprised if more bugs are still out there. I will be fixing some known resource failure problems on A500. Please post problems on other platforms to parisc-linux list as well. hope this helps, grant Grant Grundler Unix Systems Enablement Lab +1.408.447.7253 From grundler@cup.hp.com Tue, 28 Nov 2000 09:53:37 -0800 Date: Tue, 28 Nov 2000 09:53:37 -0800 From: Grant Grundler grundler@cup.hp.com Subject: [parisc-linux] PDC firmware revision FAQ update William Ferguson wrote: > Is the web server at www.parisc-linux.org down? Can't seem to connect from > San Diego. Yes. Linuxcare is having some DNS problems right now and they host that site. Any forecasts on when that will be back up? grant From bame@noam.fc.hp.com Tue, 28 Nov 2000 12:27:09 -0700 Date: Tue, 28 Nov 2000 12:27:09 -0700 From: Paul Bame bame@noam.fc.hp.com Subject: [parisc-linux] Include trouble = Hmm. Most 32 bit systems use "unsigned int" rather than "unsigned long". I will be happy to change it back to unsigned int. The only reason I used unsigned long is because it seems off_t wants to be, to a first approximation, the word length of the machine, and 'long' does that. = Using "unsigned long" might cause problems with packages like libio. = I know there is a problem if off_t is not the same as size_t. What problem is that? I'm working on a proposal for the palinux type sizes at the moment. One dilema is that off_t is supposed to be good for file offsets, which these days means it should be 64 bits. size_t refers to the sizes of objects which are expected to fit in RAM, so should be the word size of the machine. So there's a conflict because one logic suggests 64-bit off_t and 32-bit size_t on 32-bit palinux, but your statement suggests they should be the same size. Any ideas? However I'm leaning towards leaning with the older 32-bit off_t because we might not want to be the first ones to fix all the problems with making it 64 bits on a 32-bit machine. -P From marteaut@esiee.fr Tue, 28 Nov 2000 20:30:30 +0100 Date: Tue, 28 Nov 2000 20:30:30 +0100 From: Thomas Marteau marteaut@esiee.fr Subject: [parisc-linux] Mouse driver for PS/2 Hi all, We have a sample of code for the mouse driver. But, we would like to know how the Puffin would like the implementation of the driver. Because of drag & drop..., do you want two different interrupt functions or a single that does a redirection. Also , we have seen that busmouse.c is quite interesting for our driver. Do we make a copy and call it hp_mouse.c? Thanks for your answer, ESIEE Team For a better future with a mouse! From alan@lxorguk.ukuu.org.uk Tue, 28 Nov 2000 20:02:26 +0000 (GMT) Date: Tue, 28 Nov 2000 20:02:26 +0000 (GMT) From: Alan Cox alan@lxorguk.ukuu.org.uk Subject: [parisc-linux] Include trouble > One dilema is that off_t is supposed to > be good for file offsets, which these days means it should be 64 bits. off_t should be a natural type. So it should be 32bits. glibc 2.2 deals with the 64bit I/O stuff nicely > However I'm leaning towards leaning with the older 32-bit off_t because > we might not want to be the first ones to fix all the problems with > making it 64 bits on a 32-bit machine. Go 32bit. Linus will probably refuse to touch a 32bit port using longlong internally for off-t From dave@hiauly1.hia.nrc.ca Tue, 28 Nov 2000 15:24:26 -0500 (EST) Date: Tue, 28 Nov 2000 15:24:26 -0500 (EST) From: John David Anglin dave@hiauly1.hia.nrc.ca Subject: [parisc-linux] Include trouble > = Hmm. Most 32 bit systems use "unsigned int" rather than "unsigned long". > > I will be happy to change it back to unsigned int. The only reason > I used unsigned long is because it seems off_t wants to be, to a > first approximation, the word length of the machine, and 'long' does > that. Agreed. > = Using "unsigned long" might cause problems with packages like libio. > > > = I know there is a problem if off_t is not the same as size_t. > > What problem is that? I'm working on a proposal for the palinux > type sizes at the moment. It is simply dumb coding that hasn't been fixed. There are inconsistencies between the interface declarations and implementations. The old libio is on the way out. > One dilema is that off_t is supposed to > be good for file offsets, which these days means it should be 64 bits. > size_t refers to the sizes of objects which are expected to fit in > RAM, so should be the word size of the machine. So there's a conflict > because one logic suggests 64-bit off_t and 32-bit size_t on 32-bit palinux, > but your statement suggests they should be the same size. Any ideas? Only, because of poorly written legacy code. I agree that off_t should be 64 bits on 32 bit platforms today. > However I'm leaning towards leaning with the older 32-bit off_t because > we might not want to be the first ones to fix all the problems with > making it 64 bits on a 32-bit machine. Maybe it isn't that bad because I noticed at least one port used unsigned long long for off_t. Dave -- J. David Anglin dave.anglin@nrc.ca National Research Council of Canada (613) 990-0752 (FAX: 952-6605) From dave@hiauly1.hia.nrc.ca Tue, 28 Nov 2000 15:33:52 -0500 (EST) Date: Tue, 28 Nov 2000 15:33:52 -0500 (EST) From: John David Anglin dave@hiauly1.hia.nrc.ca Subject: [parisc-linux] Include trouble > Maybe it isn't that bad because I noticed at least one port used unsigned > long long for off_t. Take that back. It was __kernel_loff_t. Just go with typedef unsigned int __kernel_size_t; typedef long __kernel_off_t; #ifdef __GNUC__ typedef long long __kernel_loff_t; #endif for the 32 bit port. Dave -- J. David Anglin dave.anglin@nrc.ca National Research Council of Canada (613) 990-0752 (FAX: 952-6605) From deller@gmx.de Tue, 28 Nov 2000 21:41:53 +0100 Date: Tue, 28 Nov 2000 21:41:53 +0100 From: Helge Deller deller@gmx.de Subject: [parisc-linux] Mouse driver for PS/2 On Tuesday 28 November 2000 20:30, Thomas Marteau wrote: > Hi all, Hi Thomas, > > We have a sample of code for the mouse driver. But, we would like to > know how the Puffin would like the implementation of the driver. Because > of drag & drop..., do you want two different interrupt functions or a > single that does a redirection. Also , we have seen that busmouse.c is > quite interesting for our driver. Do we make a copy and call it > hp_mouse.c? I would propose, that you check in hp_mouse.c and use different interrupt functions for now. Changing it later shouldn't be too difficult. Greetings, Helge. > > Thanks for your answer, > ESIEE Team > For a better future with a mouse! From doneill@linuxcare.com Tue, 28 Nov 2000 16:08:49 -0500 (EST) Date: Tue, 28 Nov 2000 16:08:49 -0500 (EST) From: Dave O'Neill doneill@linuxcare.com Subject: [parisc-linux] PDC firmware revision FAQ update On Tue, 28 Nov 2000, Grant Grundler wrote: > Yes. Linuxcare is having some DNS problems right now and > they host that site. Any forecasts on when that will be back up? Well, it looks like our DNS issues are fixed... the site should be accessible now. Dave -- Dave O'Neill, Senior Linux Consultant, Linuxcare, Inc. desk: (613) 562-9949 fax: (613) 562-9700 cell: (613) 223-0219 doneill@linuxcare.com http://www.linuxcare.com/ From bame@noam.fc.hp.com Tue, 28 Nov 2000 14:21:05 -0700 Date: Tue, 28 Nov 2000 14:21:05 -0700 From: Paul Bame bame@noam.fc.hp.com Subject: [parisc-linux] Include trouble = Go 32bit. Linus will probably refuse to touch a 32bit port using longlong = internally for off-t Hmmm, too bad, since we have few palinux backwards compatibility issues and could just have the __USE_FILE_OFFSET64 glibc magic be a no-op rather than supporting all those extra *64 syscalls. Plus we'd need considerably fewer syscall translators to run 32-bit apps on 64-bit kernel (but might need more for 32-bit hpux apps). It seems illogical to make a file-system-related data type different based on cpu word size but I understand this isn't simple -- oh well. Seems like the consensus is 32-bit off_t on 32-bit kernel and just live with all those *64 syscalls -- many not supported on palinux yet I notice. -P From alan@lxorguk.ukuu.org.uk Tue, 28 Nov 2000 21:58:56 +0000 (GMT) Date: Tue, 28 Nov 2000 21:58:56 +0000 (GMT) From: Alan Cox alan@lxorguk.ukuu.org.uk Subject: [parisc-linux] Include trouble > Seems like the consensus is 32-bit off_t on 32-bit kernel and just > live with all those *64 syscalls -- many not supported on palinux > yet I notice. Remember providing you use off_t you can just tell glibc to do all the work for you and write with a 64bit off_t to userspace From alan@linuxcare.com.au Wed, 29 Nov 2000 10:27:20 +1100 (EST) Date: Wed, 29 Nov 2000 10:27:20 +1100 (EST) From: Alan Modra alan@linuxcare.com.au Subject: [parisc-linux] Include trouble On Tue, 28 Nov 2000, John David Anglin wrote: > Hmm. Most 32 bit systems use "unsigned int" rather than "unsigned long". There's some precedent for using "unsigned long", as that is what is used on 32-bit hpux11 and osf gcc targets. current sourceware CVS gcc/config/pa/: $ grep SIZE_TYPE * grep: CVS: Is a directory pa-64.h:#undef SIZE_TYPE pa-64.h:#define SIZE_TYPE "long unsigned int" pa-hpux.h:#undef SIZE_TYPE pa-hpux.h:#define SIZE_TYPE "unsigned int" pa-hpux11.h:#undef SIZE_TYPE pa-hpux11.h:#define SIZE_TYPE "long unsigned int" pa-hpux7.h:#undef SIZE_TYPE pa-hpux7.h:#define SIZE_TYPE "unsigned int" pa-linux.h:#undef SIZE_TYPE pa-linux.h:#define SIZE_TYPE "unsigned int" pa-osf.h:#undef SIZE_TYPE pa-osf.h:#define SIZE_TYPE "long unsigned int" pa-pro-end.h:#undef SIZE_TYPE pa-pro-end.h:#define SIZE_TYPE "unsigned int" pa.h:#define SIZE_TYPE "unsigned int" Some further grepping shows quite a number of other 32-bit gcc targets using "unsigned long", but I didn't see any 32-bit linux targets in the list. Paul, If you change back to "unsigned int", please change gcc/config/pa/pa-linux.h too. Alan -- Linuxcare. Support for the Revolution. From Frank.Butter@otto.de Wed, 29 Nov 2000 11:50:39 +0100 Date: Wed, 29 Nov 2000 11:50:39 +0100 From: Butter, Frank Frank.Butter@otto.de Subject: [parisc-linux] hardware to all here I was annaouncing an offer for hp hardware recently: it'll take longer than initially expected to convince our bosses ;-/ please stay patient... frank From matthias@archimed.math.uni-mannheim.de Wed, 29 Nov 2000 20:52:38 +0100 (MET) Date: Wed, 29 Nov 2000 20:52:38 +0100 (MET) From: Matthias Juchem matthias@archimed.math.uni-mannheim.de Subject: [parisc-linux] parisc-0.5.iso and stack trace Hi there. I've just downloaded the ISO images and tried to boot an 9000/705. I keep getting a stack trace. Can you tell me which part of the trace I can send you so that you could eventually tell me what is wrong? TIA, Matthias From dave@hiauly1.hia.nrc.ca Wed, 29 Nov 2000 17:05:31 -0500 (EST) Date: Wed, 29 Nov 2000 17:05:31 -0500 (EST) From: John David Anglin dave@hiauly1.hia.nrc.ca Subject: [parisc-linux] gcc crashes/out of memory and groff > With groff -fno-gcse does not help but -O0 does. Without -O0 you get an > internal error. > > g++ -I. -I/usr/src/redhat/BUILD/groff-1.16/src/roff/troff -I/usr/src/redhat/BUILD/groff-1.16/src/include -I/usr/src/redhat/BUILD/groff-1.16/src/include -DHAVE_UNISTD_H=1 -DHAVE_DIRENT_H=1 -DHAVE_LIMITS_H=1 -DHAVE_SYS_DIR_H=1 -DHAVE_STDLIB_H=1 -DHAVE_STRINGS_H=1 -DSTDLIB_H_DECLARES_PUTENV=1 -DSTDIO_H_DECLARES_POPEN=1 -DSTDIO_H_DECLARES_PCLOSE=1 -DHAVE_SYS_NERR=1 -DHAVE_SYS_ERRLIST=1 -DHAVE_CC_LIMITS_H=1 -DRETSIGTYPE=void -DHAVE_STRUCT_EXCEPTION=1 -DHAVE_UNISTD_H=1 -DHAVE_GETPAGESIZE=1 -DHAVE_MMAP=1 -DHAVE_FMOD=1 -DHAVE_STRTOL=1 -DHAVE_GETCWD=1 -DHAVE_STRERROR=1 -DHAVE_PUTENV=1 -DHAVE_RENAME=1 -DHAVE_MKSTEMP=1 -DHAVE_STRCASECMP=1 -DHAVE_STRSEP=1 -DHAVE_STRDUP=1 -DSYS_SIGLIST_DECLARED=1 -O2 -mpa-risc-1-0 -fno-gcse -c env.cc > env.cc: In member function `void environment::output_line (node *, hunits)': > env.cc:1582: Internal error: Segmentation fault. > Please submit a full bug report. > See for instructions. > make[2]: *** [env.o] Error 1 > make[2]: Leaving directory `/usr/src/redhat/BUILD/groff-1.16/src/roff/troff' This error is also exception related but appears different from the memory explosion. It occurs in scan_region in except.c. The memory explosion that occurs without -fno-gcse does seem to occur in the gcse pass as I suspected. I need to rebuild gcc with debugging to get further. I was able to build the groff package with `CXXFLAGS="-O3 -fno-exceptions"'. Dave -- J. David Anglin dave.anglin@nrc.ca National Research Council of Canada (613) 990-0752 (FAX: 952-6605) From delyra@latt.if.usp.br Wed, 29 Nov 2000 20:22:47 -0200 (BRST) Date: Wed, 29 Nov 2000 20:22:47 -0200 (BRST) From: Jorge L. deLyra delyra@latt.if.usp.br Subject: [parisc-linux] HP 9000/735-125 I just booted the palinux-0.5.iso CD on a HP 9000 model 735 workstation. It went on quite a bit before hanging immediatelly after reporting the serial ports. Gave large amount of what looks like traceback or state information. Question: would it do anyone any good if I tried to get everything the kernel said before the hang into a message in this list? Cheers, ---------------------------------------------------------------- Jorge L. deLyra, Associate Professor of Physics The University of Sao Paulo, IFUSP-DFMA For more information: finger delyra@latt.if.usp.br ---------------------------------------------------------------- From grundler@cup.hp.com Wed, 29 Nov 2000 15:19:10 -0800 Date: Wed, 29 Nov 2000 15:19:10 -0800 From: Grant Grundler grundler@cup.hp.com Subject: [parisc-linux] HP 9000/735-125 "Jorge L. deLyra" wrote: > I just booted the palinux-0.5.iso CD on a HP 9000 model 735 workstation. > It went on quite a bit before hanging immediatelly after reporting the > serial ports. Gave large amount of what looks like traceback or state > information. Question: would it do anyone any good if I tried to get > everything the kernel said before the hang into a message in this list? Certainly. I won't be able to debug the problems since I (a) don't have the time too (unless it's obvious) and (b) don't have a 735 setup for testing. This is becoming a FAQ: "My system crashed after ... What should I do next?" I'm thinking people in the support space would know how to write this one really well :^) Is I get one in the mail, I'll add it to our FAQ. thanks, grant Grant Grundler Unix Systems Enablement Lab +1.408.447.7253 From smoret@uci.edu Wed, 29 Nov 2000 15:28:20 -0800 Date: Wed, 29 Nov 2000 15:28:20 -0800 From: Steve Moret smoret@uci.edu Subject: [parisc-linux] HP 9000/735-125 Jorge, I have a 735-125 and am able to net-boot it on a custom configured kernel as long as I disable the ASP parallel ports. It works quite well using an NFS root as I cannot get the SCSI hard drives to mkfs. I was going to try and debug it but have yet to find the free time. I can e-mail you my working .config for the kernel, or build kernels (tested on my own 735) for people if they need them. -- Steve Moret smoret@uci.edu > -----Original Message----- > From: Grant Grundler [mailto:grundler@cup.hp.com] > Sent: Wednesday, November 29, 2000 3:19 PM > To: Jorge L. deLyra > Cc: parisc-linux@thepuffingroup.com > Subject: Re: [parisc-linux] HP 9000/735-125 > > > "Jorge L. deLyra" wrote: > > I just booted the palinux-0.5.iso CD on a HP 9000 model 735 workstation. > > It went on quite a bit before hanging immediatelly after reporting the > > serial ports. Gave large amount of what looks like traceback or state > > information. Question: would it do anyone any good if I tried to get > > everything the kernel said before the hang into a message in this list? > > Certainly. I won't be able to debug the problems since I (a) don't have > the time too (unless it's obvious) and (b) don't have a 735 setup > for testing. > > This is becoming a FAQ: > "My system crashed after ... What should I do next?" > > I'm thinking people in the support space would know how to write > this one really well :^) > Is I get one in the mail, I'll add it to our FAQ. > > thanks, > grant > > > Grant Grundler > Unix Systems Enablement Lab > +1.408.447.7253 > > ------------------------------------------------------------------ > --------- > To unsubscribe: send e-mail to > parisc-linux-request@thepuffingroup.com with > `unsubscribe' as the subject. > > From deller@gmx.de Thu, 30 Nov 2000 01:10:51 +0100 Date: Thu, 30 Nov 2000 01:10:51 +0100 From: Helge Deller deller@gmx.de Subject: [parisc-linux] HP 9000/735-125 X On Thursday 30 November 2000 00:28, Steve Moret wrote: > I have a 735-125 and am able to net-boot it on a custom configured kernel > as long as I disable the ASP parallel ports. .... Steve, I really would like to get the parallel-port problems on ASP get fixed as soon as possible. Could you please mail me your bootlog (with parport enabled), so I can try to track down the problem. Maybe you can also check out CVS again, and test if this version works for you ? Thanks, Helge Deller From alan@lxorguk.ukuu.org.uk Thu, 30 Nov 2000 02:38:56 +0000 (GMT) Date: Thu, 30 Nov 2000 02:38:56 +0000 (GMT) From: Alan Cox alan@lxorguk.ukuu.org.uk Subject: [parisc-linux] XFree status I have a server linked. inb/inw/outb/outw and friends are right now null functions until I fill them in. Thats not a big deal. Initially I'll probably use /dev/port but for speed I hope everyone uses mmio based hardware. Also is this bad ? /usr/bin/ld: lbxdix.o(.text+0x6fc): fixing R_PARISC_DPREL21L /usr/bin/ld: lbxprop.o(.text+0xde4): fixing R_PARISC_DPREL21L /usr/bin/ld: lbxprop.o(.text+0xdf4): fixing R_PARISC_DPREL21L Alan phux:/usr/src/redhat/BUILD/XFree86-4.0.1/xc/programs/Xserver# ./XFree86 XFree86 Version 4.0.1a / X Window System (protocol Version 11, revision 0, vendor release 6400) Release Date: 2 August 2000 If the server is older than 6-12 months, or if your card is newer than the above date, look for a newer version before reporting problems. (see http://www.XFree86.Org/FAQ) Operating System: Linux 2.4.0-test6 parisc [ELF] (==) Log file: "/var/log/XFree86.0.log", Time: Wed Nov 29 19:40:16 2000 (==) Using config file: "/etc/X11/XF86Config" Parse warning on line 77 of section Keyboard in file /etc/X11/XF86Config Ignoring obsolete keyword "LeftAlt". Parse error on line 77 of section Keyboard in file /etc/X11/XF86Config "Meta" is not a valid keyword in this section. (EE) Problem parsing the config file (EE) Error from xf86HandleConfigFile() Fatal server error: no screens found When reporting a problem related to a server crash, please send the full server output, not just the last messages. This can be found in the log file "/var/log/XFree86.0.log". Please reports problems to xfree86@xfree86.org. From alan@linuxcare.com.au Thu, 30 Nov 2000 14:41:48 +1100 (EST) Date: Thu, 30 Nov 2000 14:41:48 +1100 (EST) From: Alan Modra alan@linuxcare.com.au Subject: [parisc-linux] XFree status On Thu, 30 Nov 2000, Alan Cox wrote: > Also is this bad ? > > /usr/bin/ld: lbxdix.o(.text+0x6fc): fixing R_PARISC_DPREL21L No. It's a symptom of a variable's "constness" being declared differently from the way the variable is defined. For instance, referring to "extern int foo" in one object with foo defined as "const int foo" in another. I'll be removing the linker warning at some stage. Alan Modra -- Linuxcare. Support for the Revolution. From grundler@cup.hp.com Wed, 29 Nov 2000 21:18:14 -0800 Date: Wed, 29 Nov 2000 21:18:14 -0800 From: Grant Grundler grundler@cup.hp.com Subject: [parisc-linux] XFree status Alan Cox wrote: > I have a server linked. Alan - that's Cool! Wow! > inb/inw/outb/outw and friends are right now null > functions until I fill them in. Thats not a big deal. Initially I'll probably > use /dev/port but for speed I hope everyone uses mmio based hardware. All HP graphics for PARISC are memory mapped. Both "GSC" and PCI flavors. But I'm pretty clueless how linux X server finds/talks to a frame buffer. For HPUX, the graphics driver supports some ioctl()'s. Any references to describe how it works for linux? parisc-linux doesn't create kernel virtual addresses for MMIO. Which interface is used to create user virtual addresses for MMIO? (In general - not just for frame buffers) Is the PCI address passed to user space? I'm wondering if/how "bus_to_virt()" type translations take place. sorry for the many questions... grant Grant Grundler Unix Systems Enablement Lab +1.408.447.7253 From gibreel@pobox.com 30 Nov 2000 00:09:03 -0800 Date: 30 Nov 2000 00:09:03 -0800 From: Stephen Zander gibreel@pobox.com Subject: [parisc-linux] CVS linux Vs. -test10 >>>>> "Grant" == Grant Grundler writes: Grant> For the record, the second issue bdale made clear was we Grant> need "boot floppies" debian package working. We don't need Grant> more ISO images (no offense to pjlahaie for his good Grant> work). "Boot floppies" is a pre-requisite to becoming part Grant> of the next debian release. Given I still don't have a clue Grant> how to build a debian package and I can still contribute Grant> alot in other areas, it doesn't make sense for me to do it Grant> myself. Oooh, there's a reason for me to finally get the 712/80 under my desk to be more than a foot-rest. I'll see what I can do about this. Note that the likelihood of Debian releasing woody anytime soon is vanishingly small, so this dosen't have to happen Right Now. -- Stephen (debian developer) "Strange women lying in ponds distributing swords is no basis for a system of government" From smoret@uci.edu Thu, 30 Nov 2000 01:20:28 -0800 Date: Thu, 30 Nov 2000 01:20:28 -0800 From: Steve Moret smoret@uci.edu Subject: [parisc-linux] HP 9000/735-125 Helge, My mistake! I did a full build with todays CVS and parport didn't die. So somewhere between the 17th and now parport must have been fixed. Now, maybe you can help me identify my SCSI problem. I don't know if it is because of driver issues or a bad disk (completly likely). Do other people have the Fast SCSI2 working on their 735s? Whenever I do a mke2fs (after partitioning the drive with fdisk ok) it dies. At bootup I get: SCSI subsystem driver Revision: 1.00 sim700: Couldn't get consistent shared memory sim700: Configuring 53c700 (SCSI-ID 7) at f0825100, IRQ 86 scsi0: Revision 0x0 Post test1, istat 05, sstat0 00, dstat 84 sim700: WARNING IRQ probe failed, (returned 0) scsi0: WARNING: target data areas are not dma coherent! scsi0: test 1 completed ok. scsi0: sim700_intr_handle() called with no interrupt scsi0 : LASI/Simple 53c7xx Vendor: HP Model: C2235 Rev: 0B11 Type: Direct-Access ANSI SCSI revision: 02 Vendor: HP Model: C2235 Rev: 0B11 Type: Direct-Access ANSI SCSI revision: 02 Detected scsi disk sda at scsi0, channel 0, id 5, lun 0 Detected scsi disk sdb at scsi0, channel 0, id 6, lun 0 SCSI device sda: 825012 512-byte hdwr sectors (422 MB) Partition check: sda: sda1 sda2 SCSI device sdb: 825012 512-byte hdwr sectors (422 MB) sdb: sdb1 sdb2 And then if I try to mke2fs the disk I get: hp735:~# fdisk -l /dev/sda Disk /dev/sda: 13 heads, 62 sectors, 1023 cylinders Units = cylinders of 806 * 512 bytes Device Boot Start End Blocks Id System /dev/sda1 1 910 366699 83 Linux /dev/sda2 911 1023 45539 82 Linux swap hp735:~# mke2fs /dev/sda1 mke2fs 1.19, 13-Jul-2000 for EXT2 FS 0.5b, 95/08/09 Filesystem label= OS type: Linux Block size=1024 (log=0) Fragment size=1024 (log=0) 91800 inodes, 366699 blocks 18334 blocks (5.00%) reserved for the super user First data block=1 45 block groups 8192 blocks per group, 8192 fragments per group 2040 inodes per group Superblock backups stored on blocks: 8193, 24577, 40961, 57345, 73729, 204801, 221185 Writing inode tables: done Writing superblocks and filesystem accounting information: scsi0: Unable to abort command for target 5 scsi0: Unable to send Bus Device Reset for target 5 scsi0: Unable to do SCSI bus reset scsi0: >>>>>>>>>>>> Host reset <<<<<<<<<<<< scsi0: istat = 0c, sstat0 = 00, sstat1 = 00, dstat = 00 scsi0: dsp = 0cf15038 (script[0x140e]), dsps = 0cf15cde, target = 0 scsi0: Failing command for ID5 scsi0: sim700_intr_handle() called with no interrupt pa11_dma_map_single(PCI_DMA_NONE) called by c01cb6d4 kernel BUG at pci-dma.c:392! pa11_dma_unmap_single(PCI_DMA_NONE) called by c01ca3bc kernel BUG at pci-dma.c:403! SCSI disk error : host 0 channel 0 id 5 lun 0 return code = 2 I/O error: dev 08:01, sector 268 I/O error: dev 08:01, sector 270 I/O error: dev 08:01, sector 396 I/O error: dev 08:01, sector 16396 I/O error: dev 08:01, sector 16524 I/O error: dev 08:01, sector 16652 Of course the I/O errors continue on for a long time. Are these bad drives? Or is there a problem with the driver that still needs to be worked out? Thanks for all your help, I hope my spews of debug output are helpful, -- Steve Moret smoret@uci.edu > -----Original Message----- > From: Helge Deller [mailto:deller@gmx.de] > Sent: Wednesday, November 29, 2000 4:11 PM > To: Steve Moret > Cc: parisc-linux@thepuffingroup.com > Subject: Re: [parisc-linux] HP 9000/735-125 > > I really would like to get the parallel-port problems on ASP get fixed as > soon as possible. > Could you please mail me your bootlog (with parport enabled), so > I can try to > track down the problem. > Maybe you can also check out CVS again, and test if this version > works for > you ? From delyra@latt.if.usp.br Thu, 30 Nov 2000 08:58:22 -0200 (BRST) Date: Thu, 30 Nov 2000 08:58:22 -0200 (BRST) From: Jorge L. deLyra delyra@latt.if.usp.br Subject: [parisc-linux] HP 9000/735-125 > > information. Question: would it do anyone any good if I tried to get > > everything the kernel said before the hang into a message in this list? > > Certainly. I won't be able to debug the problems since I (a) don't have > the time too (unless it's obvious) and (b) don't have a 735 setup > for testing. OK, here goes. I want to congratulate you all on this effort. We have five of these HP-9000 stations here, quite old by now. They used to be our main number crunching force. They are wonderfully built hardware in bad need of a wonderful system on them! |:-) ---------------------------------------------------------------- Jorge L. deLyra, Associate Professor of Physics The University of Sao Paulo, IFUSP-DFMA For more information: finger delyra@latt.if.usp.br ---------------------------------------------------------------- Seyon Copyright (c) 1992-1993 Muhammad M. Saggaf. All rights reserved. Version 2 rev. 20c i586-Linux steve@hammer 05/23/99 20:19:22. Locating Modems... Modem `/dev/ttyS0' is Available. (c) Copyright. Hewlett-Packard Company. 1992. All rights reserved. PDC ROM rev. 2.7 IODC ROM rev. 1.1 80 MB of memory configured and tested. Searching for Potential Boot Devices. To terminate search, press and hold the ESCAPE key. Device Selection Device Path Device Type ---------------------------------------------------------------------------- P0 scsi.6.0 HP C3725S P1 scsi.4.0 TOSHIBA CD-ROM XM-3301TA b) Boot from specified device s) Search for bootable devices a) Enter Boot Administration mode x) Exit and continue boot sequence ?) Help Select from menu: b p1 Trying scsi.4.0 Boot path initialized. Attempting to load IPL. Soft booted. palo ipl bame@noam Tue Oct 31 14:18:02 MST 2000 0/vmlinux 2140145 bytes @ 0x6f9800 0/palo-cmdline '0/vmlinux ROOT=/ TERM=LINUX root=/dev/scd0' Kernel: partition 0 file /vmlinux ELF32 executable Entry 00100150 first 00100000 n 4 Segment 0 load 00100000 size 1460344 mediaptr 0x1000 Segment 1 load 00266000 size 179048 mediaptr 0x166000 Segment 2 load 00294000 size 109876 mediaptr 0x192000 Segment 3 load 002b0000 size 8192 mediaptr 0x1ad000 branching to kernel entry point 0x00100150 PDC Console Initialized The 32-bit Kernel has started... Enabled FP coprocessor Free memory starts at: 0xc02da000 (0x504d6c,0x504d6c,0x0,0x0) PALO command line: 'ROOT=/ TERM=LINUX root=/dev/scd0' PALO initrd 0-0 model 00002060 00000481 00000000 00000000 77f451b0 ffffffff 00000004 0000000a 0000000a vers 00000015 CPUID vers 0 rev 0 Searching for devices in PDC firmware... processor hpa 0xfffbe000 an older box... Found devices: 1. Outfield Core BA (11) at 0xf082f000, versions 0x9, 0x0, 0x70, 0x0, 0x0 2. Outfield Core SCSI (10) at 0xf0825000, versions 0x9, 0x0, 0x71, 0x0, 0x0 3. Outfield Core LAN (802.3) (10) at 0xf0826000, versions 0x9, 0x0, 0x72, 0x0, 0x0 4. Outfield Core HIL (10) at 0xf0821000, versions 0x9, 0x0, 0x73, 0x0, 0x0 5. Outfield Core RS-232 (10) at 0xf0823000, versions 0x9, 0x0, 0x75, 0x0, 0x0 6. Outfield Core RS-232 (10) at 0xf0822000, versions 0x9, 0x0, 0x75, 0x0, 0x0 7. Outfield Core Centronics (10) at 0xf0824000, versions 0x9, 0x0, 0x74, 0x0, 0x0 8. Outfield FW SCSI (10) at 0xf0830000, versions 0x9, 0x0, 0x7c, 0x0, 0x0 9. Outfield Audio (10) at 0xf1000000, versions 0x9, 0x0, 0x7f, 0x0, 0x0 10. Cobra EISA BA (11) at 0xfc000000, versions 0x4, 0x0, 0x76, 0x0, 0x0 11. Snake Cheetah (735/130) (0) at 0xfffbe000, versions 0x206, 0x0, 0x4, 0x0, 0x81 12. Snake Cheetah (1) at 0xfffbf000, versions 0x37, 0x0, 0x9, 0x0, 0x0 That's a total of 12 devices. CPU(s): 1 x PA7100 (PCX-T) at 125.000000 MHz Linux version 2.4.0-test6 (pjlahaie@elenuial.thepuffingroup.com) (gcc version 2.96 20000925 (experimental)) #32 Mon Nov 6 10:20:58 EST 2000 free_bootmem(0x2daa00, 0x4d25600) initrd: 00000000-00000000 pagetable_init On node 0 totalpages: 20480 zone(0): 10240 pages. zone(1): 10240 pages. zone(2): 0 pages. Kernel command line: ROOT=/ TERM=LINUX root=/dev/scd0 trap_init Calibrating delay loop... 124.52 BogoMIPS Memory: 77468k available Dentry-cache hash table entries: 16384 (order: 5, 131072 bytes) Buffer-cache hash table entries: 4096 (order: 2, 16384 bytes) Page-cache hash table entries: 32768 (order: 5, 131072 bytes) Inode-cache hash table entries: 8192 (order: 4, 65536 bytes) POSIX conformance testing by UNIFIX ASP version 20 at 0xf0800000 found. Found i82596 at 0xf0826000, IRQ 87 early initialization of device eth0 is deferred Found HIL at 0xf0821000, IRQ 94 HIL: no keyboard present. Warning : device (10, 0x9, 0x0, 0x73, 0x0) NOT claimed by HIL 712, 715 or similiar Linux NET4.0 for Linux 2.4 Based upon Swansea University Computer Society NET3.039 NET4: Unix domain sockets 1.0/SMP for Linux NET4.0. NET4: Linux TCP/IP 1.0 for NET4.0 IP Protocols: ICMP, UDP, TCP IP: routing cache hash table of 512 buckets, 4Kbytes TCP: Hash tables configured (established 8192 bind 8192) Starting kswapd v1.7 pty: 256 Unix98 ptys configured lp: driver loaded but no devices found RAMDISK driver initialized: 16 RAM disks of 4096K size 1024 blocksize sim700: Couldn't get consistent shared memory sim700: Configuring 53c700 (SCSI-ID 7) at f0825100, IRQ 86 scsi0: Revision 0x0 Post test1, istat 05, sstat0 00, dstat 84 sim700: WARNING IRQ probe failed, (returned 0) scsi0: WARNING: target data areas are not dma coherent! scsi0: test 1 completed ok. scsi0: sim700_intr_handle() called with no interrupt scsi0 : LASI/Simple 53c7xx scsi : 1 host. Vendor: TOSHIBA Model: CD-ROM XM-3301TA Rev: 1651 Type: CD-ROM ANSI SCSI revision: 02 Detected scsi CD-ROM sr0 at scsi0, channel 0, id 4, lun 0 Vendor: HP Model: C3725S Rev: 6019 Type: Direct-Access ANSI SCSI revision: 02 Detected scsi disk sda at scsi0, channel 0, id 6, lun 0 scsi : detected 1 SCSI cdrom 1 SCSI disk total. Uniform CD-ROM driver Revision: 3.11 SCSI device sda: hdwr sector= 512 bytes. Sectors= 4194058 [2047 MB] [2.0 GB] Partition check: sda: unknown partition table 82596.c: MAC of HP700 LAN blindely read from the prom! eth0: Couldn't get consistent shared memory eth0: 82596 at 0xf0826000, 08 00 09 0B DB EB IRQ 87. 82596.c $Revision: 1.14 $ Serial driver version 5.01 (2000-05-29) with MANY_PORTS SHARE_IRQ SERIAL_PCI enabled Dumping Stack from c4f9c000 to c4f9cbc0: c000 00000000 00000140 00000000 00000000 c027a46c 00000001 00000000 ffffffff c020 00000000 00000000 00000000 00000000 00000000 00000000 ffffffff c027a384 c040 c027a384 c4f90000 c02b0000 c028060c 00000000 00000000 00000000 00000000 c060 00000000 00000000 00000001 00000000 00000000 00000000 00000000 c02b0000 c080 c02b0000 c4f50000 00000000 00000000 00000000 c02c9ab8 00000000 c4f9c09c c0a0 c4f9c09c c4f9c0a4 c011a6e4 c4f9cac8 00000000 00000000 00000000 00000000 c0c0 00000000 00000000 00000000 00000000 00000000 00000000 c4f9c000 c011d4a8 c0e0 00000000 00000037 00000000 00000000 00000024 00000000 0000005b 00000000 c100 00000000 00000000 00000000 00000000 00000000 80000000 00000000 00000000 c120 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 c140 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 c160 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 c180 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 c1a0 00000000 00000000 00000000 00000000 00000000 00000000 00000000 fffffeff c1c0 00000000 ffffffff 00000000 c027afb4 ffffffff ffffffff ffffffff ffffffff c1e0 ffffffff ffffffff 00800000 05000000 00000000 ffffffff ffffffff ffffffff c200 00000500 00000500 00000400 00000400 ffffffff ffffffff ffffffff ffffffff c220 00007377 61707065 72000000 00000000 00000000 00000000 00000000 00000000 c240 00000000 00000000 00005000 c0267054 c0267054 c013d1e8 00010000 c4ffeba0 c260 c02238c4 c0236708 c02d9800 00504d6c 00000000 c011bb88 c0267000 00005000 c280 c0267054 c0267000 0000003e c027a000 00000001 c02b61eb 00000004 c02b61c7 c2a0 00000023 c02b61eb 00000000 00000000 c0100290 0000003e 00000000 00000024 c2c0 0000000b c027a4ac c027a000 08000059 00000000 000000ff 00000060 00000000 c2e0 00000060 00000002 002b2080 00000008 002b50c0 c0266000 00000000 023c3460 c300 c02b08c0 00000001 08000000 00000000 00000000 00000000 00856606 00000000 c320 00000000 00000000 42780000 00000000 431c0000 00000000 4471cccc 00000000 c340 000003c7 00000000 fffffde0 fffffde0 7f7fffff ffffffff 7f7fffff ffffffff c360 00000000 00000000 00000000 00000000 41800000 00000000 00000010 00000010 c380 00000000 00000000 fffffde0 fffffde0 41000000 00000000 40800000 00000000 c3a0 fffffde0 fffffde0 41000000 00000000 fffffde0 fffffde0 40800000 00000000 c3c0 41000000 00000000 40300000 00000000 40200000 00000000 40200000 00000000 c3e0 41800000 fffffde0 40000000 00000000 40000000 00000000 40800000 00000000 c400 41000000 00000000 00000000 00000000 c4f9cb80 c0103cf4 00000000 00000000 c420 00000000 00000000 00000000 00000000 c011bb78 c011bb7c 40800000 00000000 c440 00281000 00000000 c0280040 c0280064 00000000 c0280204 00000000 00000000 c460 00000000 00000000 00000000 c4f9c468 00000000 00000000 00000000 00000000 c480 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 c4a0 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 c4c0 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 c4e0 00000000 00000000 00000000 c0103c48 00000000 00000000 00000000 00000000 c500 c4f9c000 c028060c 00000000 00000000 00000000 00000000 00000000 00000000 c520 00000000 00000000 00000000 c01002a4 00000000 00000000 00000000 00000000 c540 00000000 00000000 00000000 00000000 c02b06c0 c4f9c000 c028060c 00000000 c560 c02b0000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 c580 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 c5a0 00000000 00000000 00000000 c02950a4 00000000 00000000 00000000 00000000 c5c0 00000001 c0284000 00000000 00000000 00000002 c027a4a0 c027a4a0 c0258bbc c5e0 00000000 00000000 00000000 c0294fe8 00000000 00000000 00000000 00000000 c600 00000000 08000059 00000000 00000000 f00012a0 000ff000 000a5a59 000a5a59 c620 c0295794 c02d9800 00504d6c c02cc000 c0266000 c02c8000 c02aed34 c02aed24 c640 c02aed34 c02aed20 00000000 00000000 000ff000 000a5a59 000a5a59 c0295794 c660 c02d9800 00504d6c c02cc000 c029bc3c c02c8000 c02aed34 c02aed04 c02c8000 c680 c02c5fe8 c02c60a4 c028758c 00000040 c0244ed8 c0244a0c c0244b80 c0244edc c6a0 01234567 c4f9c000 00000000 c02a6e64 c4f9c698 00000000 c02cc000 c0266000 c6c0 10000080 c02c5fe8 c02c60a4 c028758c 00000040 c4ffeea0 f00012a0 000ff000 c6e0 000a5a59 000a5a59 c0295794 c0155890 00504d6c c02cc000 c0266000 c02c8000 c700 c02c6164 00000100 c0244c38 00000000 c0245000 00000000 c02c5fe8 c02c5fe8 c720 c01e55ec c028be04 c02c9a20 c0109e74 c4ffc200 c028b474 c4f4a000 c028bf60 c740 00000004 c02aeab4 c02c8d20 c02b621f 00000004 c02b61ca 00000054 c02b621f c760 00000000 00000001 c027a000 c02a6de4 0000003c 00000058 0000000b c027a4ac c780 0000005a c4ff74a0 00000000 000000ff 00000060 00000000 00000060 00000002 c7a0 002b2080 00000008 002b50c0 c019324c 00000000 023c3460 c4f9c980 00000001 c7c0 08000000 00000000 00005301 f0823800 00856606 00000000 00000000 c028478c c7e0 42780000 00000000 431c0000 00000000 4471cccc 00000000 000003c7 00000000 c800 fffffde0 fffffde0 7f7fffff ffffffff 7f7fffff ffffffff 00000000 00000000 c820 00000000 00000000 41800000 00000000 00000010 00000010 f0823800 00000000 c840 00000003 fffffde0 41000000 00000000 40800000 00000000 fffffde0 fffffde0 c860 41000000 00000000 fffffde0 fffffde0 40800000 00000000 41000000 00000000 c880 40300000 00000000 40200000 00000000 40200000 00000000 c018ffb8 c02846d8 c8a0 c02c8800 c026c000 c02c8d20 0000000b c028478c 00000000 41000000 00000000 c8c0 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 c8e0 00000000 00000000 c011bb78 c0192bd4 4471cccc 00000000 000003c7 00000000 c900 0000000a c028478c c4f9c7c8 00000090 00000006 2b6a0000 00000000 00000000 c920 00000000 00000000 41800000 00000000 00000010 00000010 00000000 00000000 c940 fffffde0 fffffde0 41000000 00000000 40800000 00000000 fffffde0 fffffde0 c960 41000000 00000000 fffffde0 c011e9bc 40800000 00000000 41000000 00000000 c980 0004000a c0221800 c011e9f8 c4ff6520 c4ff6200 c0244f10 00000008 f0823800 c9a0 00000003 00000007 c0191568 c02c60a4 fffffffc c0245000 c0245000 c02d72b8 c9c0 c0245000 c0245000 c02c6028 00000000 c4ff6234 f0823807 f0823800 0000000a c9e0 ffffffff c4ff6520 c4ff6200 c0266000 ffffffff 00000340 c4f9cbc0 c012dfc0 ca00 08000000 00000000 00000000 00000000 00856606 00000000 00000000 00000000 ca20 42780000 00000000 431c0000 00000000 4471cccc 00000000 000003c7 00000000 ca40 fffffde0 fffffde0 7f7fffff ffffffff 7f7fffff ffffffff 00000000 00000000 ca60 00000000 00000000 41800000 00000000 00000010 00000010 00000000 00000000 ca80 fffffde0 fffffde0 41000000 00000000 40800000 00000000 fffffde0 fffffde0 caa0 41000000 00000000 fffffde0 fffffde0 40800000 00000000 41000000 00000000 cac0 40300000 00000000 40200000 00000000 40200000 00000000 41800000 fffffde0 cae0 40000000 00000000 40000000 00000000 40800000 00000000 41000000 00000000 cb00 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 cb20 00000000 00000000 c011e710 c011e714 00000000 00000000 00000000 00000000 cb40 00000000 00000058 c4f9c740 c02caac8 00000007 0f881093 00000000 00000003 cb60 c02c9800 c02c9a60 c02c9a20 00000000 00000000 00000400 c4f9cd40 c01d1c98 cb80 0000003c 0000003e c027a000 00000001 c02b61e0 00000004 c02b61c7 00000018 cba0 c02b61e0 00000000 431c0000 c01046e0 4471cccc 00000000 000003c7 00000000 Data access rights fault in kernel: Code=26 regs=c4f9c980 (Addr=00000003) YZrvWESTHLNXBCVMcbcbcbcbOGFRQPDI PSW: 00000000000001000000000000001010 r0-3 00000000 c0221800 c011e9f8 c4ff6520 r4-7 c4ff6200 c0244f10 00000008 f0823800 r8-11 00000003 00000007 c0191568 c02c60a4 r12-15 fffffffc c0245000 c0245000 c02d72b8 r16-19 c0245000 c0245000 c02c6028 00000000 r20-23 c4ff6234 f0823807 f0823800 0000000a r24-27 ffffffff c4ff6520 c4ff6200 c0266000 r28-31 ffffffff 00000340 c4f9cbc0 c012dfc0 sr0-4 00000000 00000000 00000000 00000000 sr4-8 00000000 00000000 00000000 00000000 IASQ: 00000000 00000000 IAOQ: c011e710 c011e714 IIR: 0f881093 ISR: 00000000 IOR: 00000003 ORIG_R28: 00000058 From delyra@latt.if.usp.br Thu, 30 Nov 2000 09:15:11 -0200 (BRST) Date: Thu, 30 Nov 2000 09:15:11 -0200 (BRST) From: Jorge L. deLyra delyra@latt.if.usp.br Subject: [parisc-linux] HP 9000/735-125 > I have a 735-125 and am able to net-boot it on a custom configured kernel as > long as I disable the ASP parallel ports. It works quite well using an NFS > root as I cannot get the SCSI hard drives to mkfs. I was going to try and > debug it but have yet to find the free time. I can e-mail you my working > .config for the kernel, or build kernels (tested on my own 735) for people > if they need them. Well, looks like the problem is known, good! But we have a queer little problem with our machines here, we are unable to boot from the network. I think we did everything right, in fact, we are trying to use a server here other machines boot from, it has dhcp, boopt, tftp, rarp, the works. We set it all up, put the kernel on the tftpboot area, tested all that we could by other means but, when we try to net boot the HPs, we are faced with complete silence on the network. No logs on the server, nothing. A little explanation might be needed: these are not really native 735-125 models, they were upgraded from older 720-50 models by card swapping. I am not sure whether all cards were changed, maybe some aspects of the machine are still old. The syntax of the net boot procedure in them is strange, you have to put in the hardware address of the server, which is unusual. I _suspect_ that this bios does not use tcp/ip for the net boot, but some HP proprietary protocol relating to that clustering software they have or used to have for these machines, in which you ran several stations out of the disks of a single one. In any case, a listing of what happens on the console on a net-boot trial goes below. We had a tail -f on the system log of the server, we had tcpdump listening, but nothing at all shows up... ---------------------------------------------------------------- Jorge L. deLyra, Associate Professor of Physics The University of Sao Paulo, IFUSP-DFMA For more information: finger delyra@latt.if.usp.br ---------------------------------------------------------------- Seyon Copyright (c) 1992-1993 Muhammad M. Saggaf. All rights reserved. Version 2 rev. 20c i586-Linux steve@hammer 05/23/99 20:19:22. Locating Modems... Modem `/dev/ttyS0' is Available. (c) Copyright. Hewlett-Packard Company. 1992. All rights reserved. PDC ROM rev. 2.7 IODC ROM rev. 1.1 80 MB of memory configured and tested. Searching for Potential Boot Devices. To terminate search, press and hold the ESCAPE key. Device Selection Device Path Device Type ---------------------------------------------------------------------------- P0 scsi.6.0 HP C3725S P1 scsi.4.0 TOSHIBA CD-ROM XM-3301TA b) Boot from specified device s) Search for bootable devices a) Enter Boot Administration mode x) Exit and continue boot sequence ?) Help Select from menu: a BOOT_ADMIN> help boot Boot from specified device or path: BOOT IPL boots Initial Program Loader (interactive mode) BOOT boots default boot utility may be one of the following: pri primary path in Stable Storage alt alternate path in Stable Storage Pn Device selection from SEARCH eisa. EISA adapter fwscsi. On-board FASTWIDE SCSI interface lan. Slider-card LAN interface scsi. On-board SCSI interface For more information on boot selection options, type HELP where = eisa, lan, scsi, etc ... BOOT_ADMIN> help lan LAN (IEEE 802.3/Ethernet LAN) Path Specification lan... 12 digit (hex) LAN server address max number of times to try a boot request (0 = default, 255 = infinite) max number of times to try a read request (0 = default, 255 = infinite) Example: to specify LAN address 123456-78ABCD with infinite initialization retries and default I/O retries, lan.123456-78ABCD.255.0 If one or more parameters are not specified, the following defaults will be used: = 000000-000000 = 3 tries = 6 tries BOOT_ADMIN> boot lan.0000f8-01abb1.0.0 Trying lan.0000f8-01abb1.0.0 Failed to initialize lan.0000f8-01abb1.3.0 ENTRY_INIT status = -7 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000008 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 A000800C F0002898 00000000 0800090B DBEB0000 00000000 Searching for Potential Boot Devices. To terminate search, press and hold the ESCAPE key. Device Selection Device Path Device Type ---------------------------------------------------------------------------- P0 scsi.6.0 HP C3725S P1 scsi.4.0 TOSHIBA CD-ROM XM-3301TA b) Boot from specified device s) Search for bootable devices a) Enter Boot Administration mode x) Exit and continue boot sequence ?) Help Select from menu: From rhirst@linuxcare.com Thu, 30 Nov 2000 11:19:30 +0000 Date: Thu, 30 Nov 2000 11:19:30 +0000 From: Richard Hirst rhirst@linuxcare.com Subject: [parisc-linux] HP 9000/735-125 On Thu, Nov 30, 2000 at 08:58:22AM -0200, Jorge L. deLyra wrote: > OK, here goes. I want to congratulate you all on this effort. We have five > of these HP-9000 stations here, quite old by now. They used to be our main > number crunching force. They are wonderfully built hardware in bad need of > a wonderful system on them! |:-) > Serial driver version 5.01 (2000-05-29) with MANY_PORTS SHARE_IRQ SERIAL_PCI enabled > > Dumping Stack from c4f9c000 to c4f9cbc0: This has been reported on 715/50 (Robert Duncan) and 715/75 (me) round about November 15th. At the time I tried a current cvs kernel on my 715/75 and it was even worse (IIRC). I'll have another look at it. Richard From rhirst@linuxcare.com Thu, 30 Nov 2000 11:27:39 +0000 Date: Thu, 30 Nov 2000 11:27:39 +0000 From: Richard Hirst rhirst@linuxcare.com Subject: [parisc-linux] HP 9000/735-125 On Thu, Nov 30, 2000 at 01:20:28AM -0800, Steve Moret wrote: > Now, maybe you can help me identify my SCSI problem. I don't know if it is > because of driver issues or a bad disk (completly likely). Do other people > have the Fast SCSI2 working on their 735s? > > Whenever I do a mke2fs (after partitioning the drive with fdisk ok) it dies. I have a 53c700 on my 715/75, and the driver was having trouble with a CRDOM I attached, so it has some problems. I wrote the driver, but havn't used the 715/75 for a while since latest kernels wouldn't boot for me. I'll get it going again and see if the scsi driver still works. Richard From deller@gmx.de Thu, 30 Nov 2000 13:04:49 +0100 (MET) Date: Thu, 30 Nov 2000 13:04:49 +0100 (MET) From: Helge Deller deller@gmx.de Subject: [parisc-linux] HP 9000/735-125 Hi Steve, > My mistake! I did a full build with todays CVS and parport didn't die. > So > somewhere between the 17th and now parport must have been fixed. I checked in yesterday a modified version of /drivers/parport/parport_gsc.c with an "#if 0 ... #endif" in the code. Could you try to boot again with "#if 1" (search for the text which says something like "enable bidirectional PS/2 mode") and try again ? If this hangs your machine I will implement a better work-around. > > Now, maybe you can help me identify my SCSI problem. I don't know if it > is > because of driver issues or a bad disk (completly likely). I think Richard Hirst can help you much more with your SCSI-problems than me. NB: Does your chassis LEDs work with the new kernel, and if not, could you send me your bootlog (or "dmesg | grep led") ? Greetings, Helge -- Sent through GMX FreeMail - http://www.gmx.net From rbradetich@uswest.net Thu, 30 Nov 2000 07:01:53 -0800 Date: Thu, 30 Nov 2000 07:01:53 -0800 From: Ryan Bradetich rbradetich@uswest.net Subject: [parisc-linux] HP 9000/735-125 "Jorge L. deLyra" wrote: > > I have a 735-125 and am able to net-boot it on a custom configured kernel as > > long as I disable the ASP parallel ports. It works quite well using an NFS > > root as I cannot get the SCSI hard drives to mkfs. I was going to try and > > debug it but have yet to find the free time. I can e-mail you my working > > .config for the kernel, or build kernels (tested on my own 735) for people > > if they need them. > > Well, looks like the problem is known, good! But we have a queer little > problem with our machines here, we are unable to boot from the network. I > think we did everything right, in fact, we are trying to use a server here > other machines boot from, it has dhcp, boopt, tftp, rarp, the works. We > set it all up, put the kernel on the tftpboot area, tested all that we > could by other means but, when we try to net boot the HPs, we are faced > with complete silence on the network. No logs on the server, nothing. > > A little explanation might be needed: these are not really native 735-125 > models, they were upgraded from older 720-50 models by card swapping. I am > not sure whether all cards were changed, maybe some aspects of the machine > are still old. The syntax of the net boot procedure in them is strange, > you have to put in the hardware address of the server, which is unusual. > > I _suspect_ that this bios does not use tcp/ip for the net boot, but some > HP proprietary protocol relating to that clustering software they have or > used to have for these machines, in which you ran several stations out of > the disks of a single one. In any case, a listing of what happens on the > console on a net-boot trial goes below. We had a tail -f on the system log > of the server, we had tcpdump listening, but nothing at all shows up... I believe the 735/755 type machines require rbootd to boot from the network. rbootd is available at: ftp://puffin.external.hp.com/pub/parisc/binaries/tgz/rbootd-2.0-2.tar.gz - Ryan From rhirst@linuxcare.com Thu, 30 Nov 2000 14:03:10 +0000 Date: Thu, 30 Nov 2000 14:03:10 +0000 From: Richard Hirst rhirst@linuxcare.com Subject: [parisc-linux] 715/75 dies in pdc_iodc_read() Hi, My 715/75 no longer boots with cvs kernel. It hangs while searching for devices in PDC firmware, after finding the first device. The beta 0.5 cd kernel gets past this point. The device list is: Searching for devices in PDC firmware... processor hpa 0xfffbe000 an older box... Found devices: 1. Stinger Optional Graphics (10) at 0xf4000000, versions 0x6, 0x0, 0x77, 0x0, 0x0 2. Scorpio Sr. Core BA (11) at 0xf082f000, versions 0x19, 0x0, 0x70, 0x0, 0x0 3. Scorpio Sr. Core SCSI (10) at 0xf0825000, versions 0x19, 0x0, 0x71, 0x0, 0x0 4. Scorpio Sr. Core LAN (802.3) (10) at 0xf0826000, versions 0x19, 0x0, 0x72, 0x0, 0x0 5. Scorpio Sr. Core HIL (10) at 0xf0821000, versions 0x19, 0x0, 0x73, 0x0, 0x0 6. Scorpio Sr. Core RS-232 (10) at 0xf0823000, versions 0x19, 0x0, 0x75, 0x0, 0x0 7. Scorpio Sr. Core RS-232 (10) at 0xf0822000, versions 0x19, 0x0, 0x75, 0x0, 0x0 8. Scorpio Sr. Core Centronics (10) at 0xf0824000, versions 0x19, 0x0, 0x74, 0x0, 0x0 9. Scorpio Sr. Audio (10) at 0xf1000000, versions 0x19, 0x0, 0x7b, 0x0, 0x0 10. Scorpio Sr. EISA BA (11) at 0xfc000000, versions 0x19, 0x0, 0x76, 0x0, 0x0 11. Unknown device (10) at 0xfc001000, versions 0x0, 0x0, 0xfff, 0x0, 0x0 12. Scorpio Sr.(715/75) (0) at 0xfffbe000, versions 0x316, 0x0, 0x4, 0x0, 0x81 13. Scorpio Sr. (1) at 0xfffbf000, versions 0x27, 0x0, 0x9, 0x0, 0x0 That's a total of 13 devices. CPU(s): 1 x PA7100 (PCX-T) at 75.000000 MHz So, with lastest cvs source, it gets in to the loop in really_do_oldhw_inventory(), and first time through pdc_mem_map_hpa() returns r_addr.hpa=0xf4000000 (the Stinger Optional Graphics). Next time round, mod=1, pdc_mem_map_hpa() returns r_addr.hpa=0xf8000000, and the subsequent call to pdc_iodc_read() hangs. I made the code skip the loop where mod=1, and it then goes on to discover all the devices without problems. At power on, the machine reports: Warning: one or more EISA cards could not be configured. Autoselect and search will ignore unconfigured cards. Which I assume relates to an EISA SCSI card in the machine, which I assume is item 11 in the above list. Richard From delyra@latt.if.usp.br Thu, 30 Nov 2000 13:04:46 -0200 (BRST) Date: Thu, 30 Nov 2000 13:04:46 -0200 (BRST) From: Jorge L. deLyra delyra@latt.if.usp.br Subject: [parisc-linux] HP 9000/735-125 > I believe the 735/755 type machines require rbootd to boot from the network. > rbootd is available at: > > ftp://puffin.external.hp.com/pub/parisc/binaries/tgz/rbootd-2.0-2.tar.gz Ah! This is it, then! Had never heard of this beast before. I see it is available for i386, nice, our server is a Pentium. Well, thanks a whole lot for the tip, we are certainly trying this. Well, back to work... ---------------------------------------------------------------- Jorge L. deLyra, Associate Professor of Physics The University of Sao Paulo, IFUSP-DFMA For more information: finger delyra@latt.if.usp.br ---------------------------------------------------------------- From delyra@latt.if.usp.br Thu, 30 Nov 2000 13:49:56 -0200 (BRST) Date: Thu, 30 Nov 2000 13:49:56 -0200 (BRST) From: Jorge L. deLyra delyra@latt.if.usp.br Subject: [parisc-linux] HP 9000/735-125 OK, rbootd is up and running, the station now establishes instantaneous communication with the server. But it says "bad LIF magic" and does not boot. I presume I can't just put the precompiled kernel in there. Since I cannot cross-compile for the time being (bad HP server disk crash) is there a net-boot kernel somewhere that I can download and try? Cheers, ---------------------------------------------------------------- Jorge L. deLyra, Associate Professor of Physics The University of Sao Paulo, IFUSP-DFMA For more information: finger delyra@latt.if.usp.br ---------------------------------------------------------------- From randolph@tausq.org Thu, 30 Nov 2000 08:44:18 -0700 Date: Thu, 30 Nov 2000 08:44:18 -0700 From: Randolph Chung randolph@tausq.org Subject: [parisc-linux] CVS linux Vs. -test10 > Oooh, there's a reason for me to finally get the 712/80 under my desk > to be more than a foot-rest. I'll see what I can do about this. > > Note that the likelihood of Debian releasing woody anytime soon is > vanishingly small, so this dosen't have to happen Right Now. So little faith... :P Let me know what I can do to help.... it takes my dual-400MHz i386 box about an hour to build boot-floopies; i don't even wait to think how long it will take on the 712/80 :-) randolph -- @..@ http://www.TauSq.org/ (----) ( >__< ) ^^ ~~ ^^ From rhirst@linuxcare.com Thu, 30 Nov 2000 16:11:15 +0000 Date: Thu, 30 Nov 2000 16:11:15 +0000 From: Richard Hirst rhirst@linuxcare.com Subject: [parisc-linux] HP 9000/735-125 On Thu, Nov 30, 2000 at 11:27:39AM +0000, Richard Hirst wrote: > On Thu, Nov 30, 2000 at 01:20:28AM -0800, Steve Moret wrote: > > Now, maybe you can help me identify my SCSI problem. I don't know if it is > > because of driver issues or a bad disk (completly likely). Do other people > > have the Fast SCSI2 working on their 735s? > > > > Whenever I do a mke2fs (after partitioning the drive with fdisk ok) it dies. > > > I have a 53c700 on my 715/75, and the driver was having trouble > with a CRDOM I attached, so it has some problems. I wrote the > driver, but havn't used the 715/75 for a while since latest kernels > wouldn't boot for me. I'll get it going again and see if the scsi > driver still works. I got my 715/75 to boot. The scsi driver still has problems with my CDROM drive, but the disk seems ok. I ran mke2fs of a 1Gig partition a few times and then copied 200MB of files from the network to it. Richard From bame@noam.fc.hp.com Thu, 30 Nov 2000 09:18:51 -0700 Date: Thu, 30 Nov 2000 09:18:51 -0700 From: Paul Bame bame@noam.fc.hp.com Subject: [parisc-linux] CVS linux Vs. -test10 = Grant> need "boot floppies" debian package working. We don't need = = Oooh, there's a reason for me to finally get the 712/80 under my desk = to be more than a foot-rest. I'll see what I can do about this. = = Note that the likelihood of Debian releasing woody anytime soon is = vanishingly small, so this dosen't have to happen Right Now. Well yes and no. We want to release parisc-linux sooner than woody will be ready for public stable release, so we'll want to do the boot floppies work sooner than other architectures need it and can probably therefore provide early testing too. Since we aren't going to time travel back to Debian potato, woody boot floppies are increasingly interesting to replace our manual install process (hey at least it's documented!). -P From alan@lxorguk.ukuu.org.uk Thu, 30 Nov 2000 16:10:46 +0000 (GMT) Date: Thu, 30 Nov 2000 16:10:46 +0000 (GMT) From: Alan Cox alan@lxorguk.ukuu.org.uk Subject: [parisc-linux] XFree status > Alan Cox wrote: > > I have a server linked. > Alan - that's Cool! Wow! Its still got its atoms in a twist, so its bombing out in Xnest loading the first font. > > inb/inw/outb/outw and friends are right now null > > functions until I fill them in. Thats not a big deal. Initially I'll probably > > use /dev/port but for speed I hope everyone uses mmio based hardware. > > All HP graphics for PARISC are memory mapped. Both "GSC" and PCI flavors. Yes, but if I want to say put an S3 Trio64 in my A180 and a USB card for keyboard mouse..,, (and yes these are sitting on my desk) > But I'm pretty clueless how linux X server finds/talks to a frame buffer. > For HPUX, the graphics driver supports some ioctl()'s. > Any references to describe how it works for linux? The OS specific X code in XFree86 knows several ways to talk to Linux Memory: 1. Directly mmap()ing /dev/mem or /dev/kmem to get access to the mmio space of the card and frame buffer memory. 2. Mapping the pci space via a kernel frame buffer device (/dev/fb*) 3. Arbitary other mmap based code that you plug into it (harder to do) I/O 1. Use of iopl/ioperm on x86 2. Use of mmap to map the PCI I/O space regions on different platforms (which doesnt work on some PA kit) 3. Arbitary other code we plug into it For I/O it seems that on things like the A180 the only way to do it is to use /dev/port and pread/pwrite the file handle for each port I/O. This is slow but hopefully primarily used for booting the card (XFree 4.0 has a X86 emulator for booting the BIOS firmware on PCI cards) For most machines I imagine we would be using mmio and the /dev/fb interface. Alan From alan@lxorguk.ukuu.org.uk Thu, 30 Nov 2000 16:16:18 +0000 (GMT) Date: Thu, 30 Nov 2000 16:16:18 +0000 (GMT) From: Alan Cox alan@lxorguk.ukuu.org.uk Subject: [parisc-linux] CVS linux Vs. -test10 > Oooh, there's a reason for me to finally get the 712/80 under my desk > to be more than a foot-rest. I'll see what I can do about this. > > Note that the likelihood of Debian releasing woody anytime soon is > vanishingly small, so this dosen't have to happen Right Now. My experiences with building Red Hat 7 so far are mostly good. I don't think there will be many actual changes needed to build Debian packages either. I've made very little that isnt 'use -fPIC' 'dont optimise C++' From marteaut@esiee.fr Thu, 16 Nov 2000 21:16:22 +0100 Date: Thu, 16 Nov 2000 21:16:22 +0100 From: Thomas Marteau marteaut@esiee.fr Subject: [parisc-linux] Troubles with read only file system Hi all, We have done everything well but the NFSroot and the bootable disk say that we have a read only file system ??? What is the recipe for making a bootable disk because ours can not be the good one... Thanks, Thomas From marteaut@esiee.fr Fri, 17 Nov 2000 17:59:14 +0100 Date: Fri, 17 Nov 2000 17:59:14 +0100 From: Thomas Marteau marteaut@esiee.fr Subject: [parisc-linux] Trouble with new STI This is a multi-part message in MIME format. ------=_NextPart_000_000F_01C050C0.18E3D060 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi all, We've tried the new STI driver and our 712 dies with this message: Kernel Panic: VFS: Unable to mount root fs on 01:00 We tried with Ramdisk, nfs and hard disk support and always the same = end. Also, the death happens when you 've passed bootp request... Help! Thomas ------=_NextPart_000_000F_01C050C0.18E3D060 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi all,
 
We've tried the new STI driver and our = 712 dies=20 with this message:
 
Kernel Panic: VFS: Unable to mount root = fs on=20 01:00
 
We tried with Ramdisk, nfs and hard = disk support=20 and always the same end.
Also, the death happens when you 've = passed bootp=20 request...
 
Help!
 
Thomas
------=_NextPart_000_000F_01C050C0.18E3D060-- From marteaut@esiee.fr Sun, 19 Nov 2000 13:08:45 +0100 Date: Sun, 19 Nov 2000 13:08:45 +0100 From: Thomas Marteau marteaut@esiee.fr Subject: [parisc-linux] Booting 712 STI and nfs This is a multi-part message in MIME format. ------=_NextPart_000_0047_01C05229.D8DA5D20 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi all, We managed to boot on the STI-console with a 712/80 in changing the = parameters in inittab and in securetty (if you want to login as root).=20 > cat inittab (! just the interesting thing!) # /sbin/getty invocations for the runlevels. # # The "id" field MUST be the same as the last # characters of the device (after "tty"). # # Format: # ::: 1:2345:respawn:/sbin/getty 38400 tty1 #2:23:respawn:/sbin/getty 38400 tty2 #3:23:respawn:/sbin/getty 38400 tty3 #4:23:respawn:/sbin/getty 38400 tty4 #5:23:respawn:/sbin/getty 38400 tty5 #6:23:respawn:/sbin/getty 38400 tty6 =20 > cat securetty # /etc/securetty: list of terminals on which root is allowed to login. # See securetty(5) and login(1). ttyS0 tty1 Also, in order to boot with the STI console, you need to have the module = for STI-console and not for serial console support... But, we have troubles with the rpc that print somestimes nfs: server X.X.X.165 not responding, still trying nfs: server X.X.X.165 OK nfs: server X.X.X.165 not responding, still trying nfs: server X.X.X.165 OK nfs: server X.X.X.165 not responding, still trying nfs: server X.X.X.165 OK We don't understand where comes from the problem!! Bye, ESIEE Port Team ------=_NextPart_000_0047_01C05229.D8DA5D20 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi all,
 
We managed to boot on the STI-console = with a 712/80=20 in changing the parameters in inittab and in securetty (if you want to = login as=20 root).
 
> cat inittab (! just the = interesting=20 thing!)
# /sbin/getty invocations for the=20 runlevels.
#
# The "id" field MUST be the same as the last
# = characters=20 of the device (after "tty").
#
# Format:
# =20 <id>:<runlevels>:<action>:<process>
1:2345:res= pawn:/sbin/getty=20 38400 tty1
#2:23:respawn:/sbin/getty 38400 = tty2
#3:23:respawn:/sbin/getty=20 38400 tty3
#4:23:respawn:/sbin/getty 38400 = tty4
#5:23:respawn:/sbin/getty=20 38400 tty5
#6:23:respawn:/sbin/getty 38400 tty6
 
 
 
> cat securetty
# /etc/securetty: list of terminals on = which root=20 is allowed to login.
# See securetty(5) and=20 login(1).
ttyS0
tty1
 
Also, in order to boot with the STI = console, you=20 need to have the module for STI-console and not for serial console=20 support...
 
But, we have troubles with the rpc that = print=20 somestimes
nfs: server X.X.X.165 not responding, = still=20 trying
nfs: server X.X.X.165 OK
nfs: server X.X.X.165 not responding, = still=20 trying
nfs: server X.X.X.165 OK
nfs: server X.X.X.165 not responding, = still=20 trying
nfs: server X.X.X.165 OK
We don't understand where comes from the problem!!
 
Bye,
ESIEE Port Team
------=_NextPart_000_0047_01C05229.D8DA5D20-- From marteaut@esiee.fr Mon, 20 Nov 2000 15:32:55 +0100 Date: Mon, 20 Nov 2000 15:32:55 +0100 From: Thomas Marteau marteaut@esiee.fr Subject: [parisc-linux] A new file system This is a multi-part message in MIME format. ------=_NextPart_000_0009_01C05307.27222700 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi all, Since we have the STI, we have produced a file system quite = interesting for the 712. You can have a network support till you configure the file.conf like resolv... = Also, we have noticed that the sti on B180 does not work well, it look like it can not find the = rom. But we have to work on... To download the archives go there: http://www.esiee.fr/~djoudim/code/suitable.html It is incredible what can do a 712 with it! Bye, ESIEE Port Team ------=_NextPart_000_0009_01C05307.27222700 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi all,
 
    Since we have the = STI, we have=20 produced a file system quite interesting for the 712. You = can
have a network support till you = configure the=20 file.conf like resolv... Also, we have noticed that
the sti on B180 does not work well, it = look like it=20 can not find the rom. But we have to work on...
 
To download the archives go = there:
http://www.esiee= .fr/~djoudim/code/suitable.html
 
It is incredible what can do a 712 with = it!
 
Bye,
ESIEE Port Team
------=_NextPart_000_0009_01C05307.27222700-- From kailasr@webcash.com Tue, 31 Oct 2000 12:58:41 -0800 Date: Tue, 31 Oct 2000 12:58:41 -0800 From: Kailashnath V Rampure kailasr@webcash.com Subject: [parisc-linux] unable to run palo on nfs root Hi Paul, After booting the Server from NFSroot I need to Initialize the harddisk on the server. so I copied the palo and linux in to the nfsroot. I am trying to Run the following command: $ palo -I -k /boot/vmlinux -b /boot/iplboot -c '2/boot/vmlinux TERM=linux HOME=/ root=/dev/sda2' /dev/sda fisrt partition is 10M of type f0 second partition is /dev/sda2 of type linux native. Third partition is /dev/sda3 of type linux Swap Then I get the cannot execute binary file. second question is that what is the Terminal type I should set as I am unable to open vi. Please suggest the correct steps. Thanks. Kailas At 09:54 AM 10/31/00 -0700, Paul Bame wrote: >= Hi, >= >= I have booted HP A class server from nfsroot. but when I try to run palo on >= the server to initialize boot loader to the hdd I get >= "cannot execute the binary file" >= >= can any one help me to make the hdd bootable > >It would help me to see the actual command you used and the actual >error message(s) printed. With the info you give so far it could be >"a million" things. > > -P From bame@noam.fc.hp.com Tue, 31 Oct 2000 14:26:00 -0700 Date: Tue, 31 Oct 2000 14:26:00 -0700 From: Paul Bame bame@noam.fc.hp.com Subject: [parisc-linux] NEW NATIVE PALO TARBALL - REQUIRED = Hi Paul, = = After booting the Server from NFSroot I need to Initialize the harddisk on = the server. so I copied the palo and linux in to the nfsroot. I am trying = to Run the following command: = $ palo -I -k /boot/vmlinux -b /boot/iplboot -c '2/boot/vmlinux TERM=linux = HOME=/ root=/dev/sda2' /dev/sda = fisrt partition is 10M of type f0 = second partition is /dev/sda2 of type linux native. = Third partition is /dev/sda3 of type linux Swap That looks great. = Then I get the cannot execute binary file. Ok I think we changed the kernal such that the old palo bits won't run any more (we removed the old gateway page). I uploaded a new version: ftp://puffin.external.hp.com/pub/parisc/binaries/userspace/palo-200001031.tgz -P From grundler@cup.hp.com Tue, 31 Oct 2000 13:53:04 -0800 Date: Tue, 31 Oct 2000 13:53:04 -0800 From: Grant Grundler grundler@cup.hp.com Subject: [parisc-linux] unable to run palo on nfs root Kailashnath V Rampure wrote: > fisrt partition is 10M of type f0 > second partition is /dev/sda2 of type linux native. > Third partition is /dev/sda3 of type linux Swap Kailashnath, Even though your partitioning should work fine, you really want the swap on the lowest numbered SCSI block you can get away with. Several reasons for this: o lowest block number is on the outside of the SCSI disk were data xfer rate is typically 80% faster than the inside. (someday try "time dd if=/dev/sda of=/dev/null bs=8k count=50" with and with out skip parameter). o Eventualy we will have kernel dumps to swap space - and IODC will likely have the same limitations where on the disk dump can be as we have with booting from a disk (as discussed in the PALO documentation). grant Grant Grundler Unix Systems Enablement Lab +1.408.447.7253 From taggart@carmen.fc.hp.com Tue, 31 Oct 2000 16:16:09 -0700 Date: Tue, 31 Oct 2000 16:16:09 -0700 From: Matt Taggart taggart@carmen.fc.hp.com Subject: [parisc-linux] New cross-compiler I have placed a new i386-linux -> hppa32/64-linux cross compiler (with 32bit glibc) in, ftp://puffin.external.hp.com/pub/parisc/binaries/LinuxX86/xc-20001031.tar.gz It includes Alan Modra's recent fix for the 64 bit compiler, http://puffin.external.hp.com/mailing-lists/parisc-linux-cvs/2000/10-Oct/0233.h tml -- Matt Taggart taggart@fc.hp.com From pdbeal@bealz.net Tue, 31 Oct 2000 18:43:06 -0500 Date: Tue, 31 Oct 2000 18:43:06 -0500 From: Phillip Beal pdbeal@bealz.net Subject: [parisc-linux] 735 and Thin Lan Hey, I've obtained two HP 735's and I'd like to try the linus port on them. I have compiled a kernel, but it never boots the nfsroot disk. It has the same problem that the HP 755 that I've worked with. However, it has a different ethernet connection. The 735 has a thin lan connection. What network device should be used in the kernel to be able to use the thin lan adapter? Here's the info on the Thin lan: Outfield Core LAN (802.3) (10) at 0xf0826000 versions 0x9, 0x0, 0x72, 0x0, 0x0 Thanks, -- Phillip Beal S+LUG Vice-President From deller@gmx.de Wed, 1 Nov 2000 00:57:22 +0100 Date: Wed, 1 Nov 2000 00:57:22 +0100 From: Helge Deller deller@gmx.de Subject: [parisc-linux] 735 and Thin Lan On Wednesday 01 November 2000 00:43, Phillip Beal wrote: > Hey, > > I've obtained two HP 735's and I'd like to try the linus port on them. > I have compiled a kernel, but it never boots the nfsroot disk. It has > the same problem that the HP 755 that I've worked with. However, it has > a different ethernet connection. The 735 has a thin lan connection. > What network device should be used in the kernel to be able to use the > thin lan adapter? Here's the info on the Thin lan: > > Outfield Core LAN (802.3) (10) at 0xf0826000 versions 0x9, 0x0, 0x72, > 0x0, 0x0 > > Thanks, > Phillip Beal > S+LUG Vice-President Hi Phillip, I think the "Lasi ethernet"-driver (enabled by default in our configuration) should work on both of your boxes. Helge. From deller@gmx.de Wed, 1 Nov 2000 01:45:52 +0100 Date: Wed, 1 Nov 2000 01:45:52 +0100 From: Helge Deller deller@gmx.de Subject: [parisc-linux] The new PS/2 Keyboard Driver On Friday 27 October 2000 01:50, Helge Deller wrote: > On Thursday 26 October 2000 22:05, Thomas Marteau wrote: > > > > > > Hello everyone, > > > > We've just updated the PS/2 keyboard driver. The leds and interrupt > > functions work really well on a 712 workstation and also B132 now. The > > updated driver files are available on our website. It works better than > > under HP UX for the B 132 ;-> > > > > http://www.esiee.fr/~djoudim > > > > The ESIEE Port Team in Paris. > > > > Here is the patch: > > > > diff -urN linux/drivers/char/gsc_ps2.c linux-parisc/drivers/char/gsc_ps2.c > > --- linux/drivers/char/gsc_ps2.c Thu Oct 26 21:06:54 2000 > > +++ linux-parisc/drivers/char/gsc_ps2.c Thu Oct 26 21:34:00 2000 > > @@ -7,6 +7,11 @@ > > [.............] > > > diff -urN linux/drivers/char/keyb_at.c linux-parisc/drivers/char/keyb_at.c > > --- linux/drivers/char/keyb_at.c Thu Oct 26 21:07:00 2000 > > +++ linux-parisc/drivers/char/keyb_at.c Thu Oct 26 21:23:16 2000 > > [........] > > Hi Thomas, > > Thanks for your patch. > But I don't think it's a good idea to change a common file like keyb_at.c, > which is used in most other arches too. This patch surely breaks their > keyboard support and more than that I'm sure, that Linus will not accept this > patch, when the time is come to integrate parisc into the official kernel. > > Isn't there any other solution as for example to #ifdef the code or create a > new keyb_at.c for parisc (Yes I know, both of those aren't clean too.) ? > > Helge Deller Hi folks, I need to correct myself on this topic. The ESIEE-team made a great patch and didn't changed any globally used file. keyb_at.c is just used in the current parisc-port, and so it's ok to change that file. I just committed their changes to the CVS, and in the same cycle tried to clean up the code. In the same step I renamed the original filenames to some hopefully better ones. Since I don't own myself a real HP PS/2 keyboard (it's just an PC-AT one with a small DIN to PS/2-connector), it would be great to get some feedback if I did the Right Thing. Helge. From bri@mojo.calyx.net Wed, 1 Nov 2000 02:48:02 -0500 (EST) Date: Wed, 1 Nov 2000 02:48:02 -0500 (EST) From: Brian S. Julin bri@mojo.calyx.net Subject: [parisc-linux] The new PS/2 Keyboard Driver Probably best not to worry about cleaning keyboard drivers up too much. The current USB code will be followed by linux-input style drivers at some point. In fact I started a HIL linux-input style driver, which would abstract the PS2 port/HIL ports and allow a standard keyboard module to be hooked into the abstracted serio port. I will work on it more when time permits. -- Brian S. Julin From jsm@udlkern.fc.hp.com Wed, 1 Nov 2000 02:37:58 -0700 (MST) Date: Wed, 1 Nov 2000 02:37:58 -0700 (MST) From: John Marvin jsm@udlkern.fc.hp.com Subject: Elf Header change proposal Paul and Alan pointed out that I goofed. I analyzed the vmlinux in my 64 bit build area to get the current flags, but it turns out that the vmlinux I looked at was a 32 bit version. I had recently made some 64 bit checkins, and I like to rebuild everything for 32 bit before doing that, to make sure that I haven't broken the 32 bit path by making 64 bit changes. So, the bad news is that I wasted time writing an unecessarily long design proposal. The good news is that the only thing that needs to change is value in the e_ident[EI_OSABI] field, so that we can differentiate 64 bit HP-UX binaries from 64 bit Linux binaries. We should also change the field for 32 bit Linux also. John From jsm@udlkern.fc.hp.com Wed, 1 Nov 2000 03:35:49 -0700 (MST) Date: Wed, 1 Nov 2000 03:35:49 -0700 (MST) From: John Marvin jsm@udlkern.fc.hp.com Subject: space registers Matthew Wilcox wrote: > a small optimisation just occurred to me. > > right now, when we switch to kernel space, we set all of sr4-sr7 to 0 > (for the kernel mapping). we don't need to do that since the kernel is > entirely in sr7's domain. this has the added bonus that badly written > drivers which blindly dereference userspace pointers will work on > parisc as well as x86. we can also lazily restore sr4-6 on exit from > kernel space if we're switching back to the same task which called us. > this optimisation may not be worthwhile, but i think setting sr4-6 > on entry to the kernel is unnecessary. True for now. But it won't always be true. It is a desired goal to be able to support large (~3.5 Gb) physical memory for the 32 bit port. To do this we will move the kernel down to around virtual address 0, so the kernel address space will then be controlled by sr4, and depending on the amount of physical memory in the machine, possibly sr5, sr6, and sr7. We could do this based on a test of the amount of physical memory in the machine, but once you load something from memory to do the test, and then actually do the test, you wouldn't have any advantage over just writing zero's to the space registers. This might be worth considering for the 64 bit port, since both the kernel and user space will reside entirely within the linear address space covered by sr4 (We would have to go to a 1 Mb page size to be able to support greater than a 62 bit address space with three level page tables). sr5,sr6, and sr7 will only be used when we are running 64 bit HP-UX processes (with its address space broken up into 4 segments). Note that since we just store the users space in sr3 while we are in the kernel, its not clear that any kind of test with a branch would be a performance gain, especially if it required that we load something from memory to do that test. We may be able cover this by managing sr5, sr6 and sr7 only in the HP-UX specific parts of the syscall path. John From alan@linuxcare.com.au Thu, 2 Nov 2000 00:11:11 +1100 (EST) Date: Thu, 2 Nov 2000 00:11:11 +1100 (EST) From: Alan Modra alan@linuxcare.com.au Subject: Elf Header change proposal On Wed, 1 Nov 2000, John Marvin wrote: > So, the bad news is that I wasted time writing an unecessarily long > design proposal. The good news is that the only thing that needs to > change is value in the e_ident[EI_OSABI] field, so that we can > differentiate 64 bit HP-UX binaries from 64 bit Linux binaries. > We should also change the field for 32 bit Linux also. Some other bad news is that the change isn't quite trivial, due to not wishing to break other bfd targets. The good new is I've made the change. Compiling at the moment. Alan Modra -- Linuxcare. Support for the Revolution. From bame@noam.fc.hp.com Wed, 01 Nov 2000 10:59:34 -0700 Date: Wed, 01 Nov 2000 10:59:34 -0700 From: Paul Bame bame@noam.fc.hp.com Subject: [parisc-linux] new method for 64-bit parisc tree I want to propose/discuss a new method for maintaining our 64-bit parisc tree in relation to the 32-bit tree. I have prototyped this and so far it seems pretty useful. Most of the files in the current parisc64 tree only contain one line, a #include of the same file from the parisc tree. This confuses 'make dep', causes some compile errors to have nonsense line numbers, and doesn't allow direct editing of the source files in the parisc64 tree. The method I'm proposing works like this: The future parisc64 tree ONLY contains files which are different from, or in addition to, those in the parisc tree. When you 'make config' or 'make oldconfig', each file in the parsic tree is symbolically linked as the same file in the parisc64 tree. This enables all the rest of the tools/build to work normally. 'make distclean' includes a step to remove all the symlinks. The ugliest "feature" is that even though you can edit source files in the parisc64 tree, 'cvs commit' will fail on those which are symbolic links. To reduce this problem, I'm dropping a symbolic link called '...' in each parisc64 directory which is a pointer to the corresponding parisc directory, so 'cd ...; cvs commit foo.c' will work and not be too onerous. We should additionally consider a naming convention or something so that maintainers in the parisc tree know whether files are shared with parisc64 or not. I prototyped this as a fictional new "architecture" called "p64". To try it out, grab the tarball (only about 30 files -- can be fewer) ftp://puffin.external.hp.com/pub/parisc/ and unpack in your top-level linux source tree directory. Then in your top-level Makefile, change ARCH := parisc64 to ARCH := p64, then make oldconfig or whatever you usually do. Let me know of any problems. Is this something we should adopt for the real parisc64 tree? -Paul Bame From kailasr@webcash.com Wed, 01 Nov 2000 12:30:40 -0800 Date: Wed, 01 Nov 2000 12:30:40 -0800 From: Kailashnath V Rampure kailasr@webcash.com Subject: [parisc-linux] NEW NATIVE PALO TARBALL - REQUIRED Thanks paul I was able to run the command. Can you let me know what I should type at ISL prompt as its trying to boot from /stand/vmunix instead of /boot/vmlinux. Also I am unable to open vi as it says vi:LINUX:unknown terminal type. Please suggest. Regards At 02:26 PM 10/31/00 -0700, Paul Bame wrote: >= Hi Paul, >= >= After booting the Server from NFSroot I need to Initialize the harddisk on >= the server. so I copied the palo and linux in to the nfsroot. I am trying >= to Run the following command: >= $ palo -I -k /boot/vmlinux -b /boot/iplboot -c '2/boot/vmlinux TERM=linux >= HOME=/ root=/dev/sda2' /dev/sda >= fisrt partition is 10M of type f0 >= second partition is /dev/sda2 of type linux native. >= Third partition is /dev/sda3 of type linux Swap > >That looks great. > >= Then I get the cannot execute binary file. > >Ok I think we changed the kernal such that the old palo bits won't run >any more (we removed the old gateway page). I uploaded a new version: >ftp://puffin.external.hp.com/pub/parisc/binaries/userspace/palo-200001031.tgz > > -P From matthew@wil.cx Thu, 2 Nov 2000 00:13:06 +0000 Date: Thu, 2 Nov 2000 00:13:06 +0000 From: Matthew Wilcox matthew@wil.cx Subject: linux bame On Wed, Nov 01, 2000 at 01:53:24PM -0700, Paul Bame wrote: > CVSROOT: /home/cvs/parisc > Module name: linux > Changes by: bame 00/11/01 13:53:24 > > Modified files: > include/asm-parisc64: posix_types.h > > Log message: > Don't need a separate copy of this one either err.. are you sure? we used to get a lot of prototype problems when they were the same file. what's changed that they're now able to be the same? -- Revolutions do not require corporate support. From bame@riverrock.org Wed, 01 Nov 2000 23:18:43 -0700 Date: Wed, 01 Nov 2000 23:18:43 -0700 From: bame@riverrock.org bame@riverrock.org Subject: linux bame = On Wed, Nov 01, 2000 at 01:53:24PM -0700, Paul Bame wrote: = > CVSROOT: /home/cvs/parisc = > Module name: linux = > Changes by: bame 00/11/01 13:53:24 = > = > Modified files: = > include/asm-parisc64: posix_types.h = > = > Log message: = > Don't need a separate copy of this one either = = err.. are you sure? we used to get a lot of prototype problems when they = were the same file. what's changed that they're now able to be the same? I changed the parisc version so that the data types would compile to the same size in both wide and narrow mode. Unfortunately there is at least one issue which will probably require this scheme to change :-( -P From grundler@cup.hp.com Thu, 2 Nov 2000 00:21:36 -0800 (PST) Date: Thu, 2 Nov 2000 00:21:36 -0800 (PST) From: Grant Grundler grundler@cup.hp.com Subject: [parisc-linux] a500.out16 Hi Richard (et al), I finally think I understand how pcibios_align_resource() is used... that definitely was the problem. Everything on A500 but PCI-PCI bridge seems to be assigned I/O port and MMIO addresses correctly. I'll look at tulip code tomorrow to see why it's not happy. 6 Tulips are behind PCI-PCI Bridges and that's part of the problem. But the complaints about "MMIO resource" list I/O Port addresses instead...and those look fine to me if they are treated like I/O port addresses... I'd also like to connect some more SCSI disks....but any clue what the "CACHE TEST FAILED" is about? But instead of putting out another tar ball, I'm committing my code. I haven't tested on c3k/j5k yet and it might be broken. 32-bit still builds and any fix should be simple - either cvs update back to an older date or put "if (pdc_pat) { }" around anything that I added that shouldn't be. Tell me to test/fix any brokeness you might find and I'll make time to do it. aplogies for the long delay, grant Firmware Version 40.32 Duplex Console IO Dependent Code (IODC) revision 1 ------------------------------------------------------------------------------ (c) Copyright 1995-1998, Hewlett-Packard Company, All rights reserved ------------------------------------------------------------------------------ Processor Speed State CoProcessor State Cache Size Number State Inst Data --------- -------- --------------------- ----------------- ------------ 0 440 MHz Active Functional 512 KB 1 MB 1 440 MHz Idle Functional 512 KB 1 MB Central Bus Speed (in MHz) : 111 Available Memory : 262144 KB Good Memory Required : 11468 KB Primary boot path: 0/0/1/1.15 Alternate boot path: 0/0/2/1.15 Console path: 0/0/4/0.0 Keyboard path: 0/0/4/0.0 WARNING: The non-destructive test bit was set, so memory was not tested destructively. Information only, no action required. ---- Main Menu --------------------------------------------------------------- Command Description ------- ----------- BOot [PRI|ALT|] Boot from specified path PAth [PRI|ALT] [] Display or modify a path SEArch [DIsplay|IPL] [] Search for boot devices COnfiguration menu Displays or sets boot values INformation menu Displays hardware information SERvice menu Displays service commands DIsplay Redisplay the current menu HElp [|] Display help for menu or command RESET Restart the system ---- Main Menu: Enter command or menu > bo lan Interact with IPL (Y, N, or Cancel)?> n Booting... Network Station Address 00306e-03799f System IP Address 15.8.80.78 Server IP Address 15.8.81.247 Boot IO Dependent Code (IODC) revision 2 HARD Booted. palo ipl grundler@hpisp747 Tue Oct 31 16:45:27 PST 2000 0/vmlinux 2708507 bytes @ 0x6800 0/palo-cmdline '0/vmlinux HOME=/ TERM=linux root=/dev/nfs nfsroot=15.8.81.247:/tftpboot/hppa64 ' Kernel: partition 0 file /vmlinux ELF64 executable Entry 00100000 first 00100000 n 4 Segment 0 load 00100000 size 1705408 mediaptr 0x1000 Segment 1 load 002a2000 size 407616 mediaptr 0x1a2000 Segment 2 load 00308000 size 131960 mediaptr 0x206000 Segment 3 load 0032c000 size 16384 mediaptr 0x227000 branching to kernel entry point 0x00100000 Set default PSW W bit to 1 PDC Console Initialized The 64-bit Kernel has started... Enabled FP coprocessor If this is the LAST MESSAGE YOU SEE, you're probably using 32-bit millicode by mistake. Free memory starts at: 0xc0371000 start_parisc(0x504d40,0x504d40,0x0,0x0) PALO command line: 'HOME=/ TERM=linux root=/dev/nfs nfsroot=15.8.81.247:/tftpboot/hppa64 ' PALO initrd 0-0 model 00005cb0 00000491 00000000 00000001 23355fdc 100000f0 00000008 000000b2 000000b2 vers 00000300 cpuid 0000022a CPUID vers 17 rev 10 Searching for devices in PDC firmware... processor hpa 0xfffffffffffa0000 CELL_GET_NUMBER: 0x0 0x1 PAT_ENTITY_PROC: id_eid 0xa0ff0000 PAT_ENTITY_PROC: id_eid 0xa2ff0000 PAT_ENTITY_MEM: amount 0x10000000 min_gni_base 0x0 min_gni_len 0x0 PAT_ENTITY_SBA: ranges 6 0: 0xc000000000000005 0xfffffffffed18000 0xfffffffffed2ffff 1: 0x8000000000000000 0x0000000000000000 0x000000000000003f 2: 0x8000000000000001 0xfffffffff8000000 0xfffffffffbffffff 3: 0x00040000001a1701 0xfffffffff0000000 0xfffffffff7ffffff 4: 0x00040000001a1701 0xfffffffffc000000 0xfffffffffecfffff 5: 0x8000000000000002 0xfffffff800000000 0xfffffffbffffffff PAT_ENTITY_LBA: ranges 4 0: 0x8000000000000000 0x0000000000000000 0x0000000000000007 1: 0x8000000000000001 0xfffffffff8000000 0xfffffffff87fffff 2: 0x8000000000000002 0xfffffff804000000 0xfffffff87fffffff 3: 0x8000000000000004 0xfffffff800000000 0xfffffff803ffffff PAT_ENTITY_LBA: ranges 4 0: 0x8000000000000000 0x0000000000000010 0x0000000000000017 1: 0x8000000000000001 0xfffffffff9000000 0xfffffffff97fffff 2: 0x8000000000000002 0xfffffff904000000 0xfffffff97fffffff 3: 0x8000000000000004 0xfffffff900000000 0xfffffff903ffffff PAT_ENTITY_LBA: ranges 4 0: 0x8000000000000000 0x0000000000000020 0x0000000000000027 1: 0x8000000000000001 0xfffffffffa000000 0xfffffffffa7fffff 2: 0x8000000000000002 0xfffffffa04000000 0xfffffffa7fffffff 3: 0x8000000000000004 0xfffffffa00000000 0xfffffffa03ffffff PAT_ENTITY_LBA: ranges 4 0: 0x8000000000000000 0x0000000000000030 0x0000000000000037 1: 0x8000000000000001 0xfffffffffb000000 0xfffffffffb7fffff 2: 0x8000000000000002 0xfffffffb04000000 0xfffffffb7fffffff 3: 0x8000000000000004 0xfffffffb00000000 0xfffffffb03ffffff Found devices: 1. Crescendo 440 (0) at 0xfffffffffffa0000, versions 0x5cb, 0x0, 0x4, 0x0, 0x91 2. Crescendo 440 (0) at 0xfffffffffffa2000, versions 0x5cb, 0x0, 0x4, 0x0, 0x91 3. Crescendo Memory (1) at 0xfffffffffed08000, versions 0x9b, 0x0, 0x9, 0x0, 0x0 4. Astro BC Runway Port (12) at 0xfffffffffed00000, versions 0x582, 0x0, 0xb, 0x0, 0x10 5. Elroy PCI Bridge (13) at 0xfffffffffed30000, versions 0x782, 0x0, 0xa, 0x0, 0x0 6. Elroy PCI Bridge (13) at 0xfffffffffed34000, versions 0x782, 0x0, 0xa, 0x0, 0x0 7. Elroy PCI Bridge (13) at 0xfffffffffed38000, versions 0x782, 0x0, 0xa, 0x0, 0x0 8. Elroy PCI Bridge (13) at 0xfffffffffed3c000, versions 0x782, 0x0, 0xa, 0x0, 0x0 That's a total of 8 devices. CONFIG_SMP disabled - not claiming addional CPUs Warning : device (0, 0x5cb, 0x0, 0x4, 0x0) NOT claimed by CPU PARISC CPU(s): 1 x PA8500 (PCX-W) at 440.000000 MHz Linux version 2.4.0-test6 (grundler@hpisp747) (gcc version 2.96 20000925 (experimental)) #73 Wed Nov 1 23:58:51 PST 2000 free_bootmem(0x373000, 0xfc8d000) initrd: 00000000-00000000 pagetable_init On node 0 totalpages: 65536 zone(0): 32768 pages. zone(1): 32768 pages. zone(2): 0 pages. Kernel command line: HOME=/ TERM=linux root=/dev/nfs nfsroot=15.8.81.247:/tftpboot/hppa64 trap_init Calibrating delay loop... 878.18 BogoMIPS kernel BUG at page_alloc.c:106! Memory: 248868k available Dentry-cache hash table entries: 32768 (order: 7, 524288 bytes) Buffer-cache hash table entries: 16384 (order: 5, 131072 bytes) Page-cache hash table entries: 65536 (order: 7, 524288 bytes) Inode-cache hash table entries: 16384 (order: 6, 262144 bytes) POSIX conformance testing by UNIFIX lba version TR4.0 (0x5) found at 0xfffffffffed30000 0: 0x8000000000000000 PA 0x0000000000000000,0x0000000000000007 IO 0x0000000000000000,0x0000000000000007 1: 0x8000000000000001 PA 0xfffffffff8000000,0xfffffffff87fffff IO 0x00000000f8000000,0x00000000f87fffff 2: 0x8000000000000002 PA 0xfffffff804000000,0xfffffff87fffffff IO 0x000000f804000000,0x000000f87fffffff lba range[2] : ignoring GMMIO (0xfffffff804000000) 3: 0x8000000000000004 PA 0xfffffff800000000,0xfffffff803ffffff IO 0x000000f800000000,0x000000f803ffffff lba_fixup_bus(0x00000000cffe60c0) bus 0 sysdata 0x00000000cffe9e80 cons 0x00002000 boot 0x00000000 kbd 0x00002000 claimed 00:00 0 [0,7f]/101 claimed 00:00 1 [fffffffff8020000,fffffffff80203ff]/200 claimed 00:20 0 [fffffffff8000000,fffffffff8000fff]/200 LBA PIOP resource tree 00000000cffe9ed0 [0,7ffff]/100 00000000cffe5080 [0,7f]/101 LBA pcibios_size_bridges() LBA pci_assign_unassigned_resources() pcibios_update_resource(00:08, ..., 0) [100,1ff]/101 pcibios_update_resource(00:08, ..., 1) [fffffffff8001000,fffffffff80013ff]/204 PCI: dev PCI device 1000:000b type 64-bit pcibios_update_resource(00:08, ..., 3) [fffffffff8002000,fffffffff8003fff]/204 PCI: dev PCI device 1000:000b type 64-bit pcibios_update_resource(00:09, ..., 0) [200,2ff]/101 pcibios_update_resource(00:09, ..., 1) [fffffffff8001400,fffffffff80017ff]/204 PCI: dev PCI device 1000:000b type 64-bit pcibios_update_resource(00:09, ..., 3) [fffffffff8004000,fffffffff8005fff]/204 PCI: dev PCI device 1000:000b type 64-bit pcibios_update_resource(00:10, ..., 0) [300,3ff]/101 pcibios_update_resource(00:10, ..., 1) [fffffffff8001800,fffffffff80018ff]/200 pcibios_update_resource(00:10, ..., 2) [fffffffff8006000,fffffffff8006fff]/200 pcibios_update_resource(00:11, ..., 0) [400,4ff]/101 pcibios_update_resource(00:11, ..., 1) [fffffffff8001900,fffffffff80019ff]/200 pcibios_update_resource(00:11, ..., 2) [fffffffff8007000,fffffffff8007fff]/200 pcibios_update_resource(00:20, ..., 1) [80,bf]/101 pcibios_update_resource(00:28, ..., 0) [fffffffff8008000,fffffffff8008fff]/200 pcibios_update_resource(00:28, ..., 1) [c0,ff]/101 LBA pci_set_bus_ranges() pcibios_fixup_pbus_ranges(0, [0,1000 fffffffff8000000,fffffffff8100000]) lba version TR4.0 (0x5) found at 0xfffffffffed34000 0: 0x8000000000000000 PA 0x0000000000000010,0x0000000000000017 IO 0x0000000000000010,0x0000000000000017 1: 0x8000000000000001 PA 0xfffffffff9000000,0xfffffffff97fffff IO 0x00000000f9000000,0x00000000f97fffff 2: 0x8000000000000002 PA 0xfffffff904000000,0xfffffff97fffffff IO 0x000000f904000000,0x000000f97fffffff lba range[2] : ignoring GMMIO (0xfffffff904000000) 3: 0x8000000000000004 PA 0xfffffff900000000,0xfffffff903ffffff IO 0x000000f900000000,0x000000f903ffffff lba_fixup_bus(0x00000000cffe62c0) bus 16 sysdata 0x00000000cffe61c0 cons 0x00002000 boot 0x00000000 kbd 0x00002000 LBA PIOP resource tree 00000000cffe6210 [100000,17ffff]/100 LBA pcibios_size_bridges() LBA pci_assign_unassigned_resources() pcibios_update_resource(10:00, ..., 1) [100000,1000ff]/101 pcibios_update_resource(10:00, ..., 2) [100100,1001ff]/101 pcibios_update_resource(10:00, ..., 3) [fffffffff9000000,fffffffff90001ff]/200 pcibios_update_resource(10:00, ..., 5) [fffffffff9020000,fffffffff903ffff]/200 LBA pci_set_bus_ranges() pcibios_fixup_pbus_ranges(0, [0,1000 fffffffff8000000,fffffffff8100000]) pcibios_fixup_pbus_ranges(16, [100000,101000 fffffffff9000000,fffffffff9100000]) lba version TR4.0 (0x5) found at 0xfffffffffed38000 0: 0x8000000000000000 PA 0x0000000000000020,0x0000000000000027 IO 0x0000000000000020,0x0000000000000027 1: 0x8000000000000001 PA 0xfffffffffa000000,0xfffffffffa7fffff IO 0x00000000fa000000,0x00000000fa7fffff 2: 0x8000000000000002 PA 0xfffffffa04000000,0xfffffffa7fffffff IO 0x000000fa04000000,0x000000fa7fffffff lba range[2] : ignoring GMMIO (0xfffffffa04000000) 3: 0x8000000000000004 PA 0xfffffffa00000000,0xfffffffa03ffffff IO 0x000000fa00000000,0x000000fa03ffffff lba_fixup_bus(0x00000000cffe64c0) bus 32 sysdata 0x00000000cffe63c0 cons 0x00002000 boot 0x00000000 kbd 0x00002000 LBA PIOP resource tree 00000000cffe6410 [200000,27ffff]/100 LBA pcibios_size_bridges() LBA pci_assign_unassigned_resources() pcibios_update_resource(20:00, ..., 0) [200000,2000ff]/101 pcibios_update_resource(20:00, ..., 1) [fffffffffa000000,fffffffffa0003ff]/204 PCI: dev PCI device 1000:000b type 64-bit pcibios_update_resource(20:00, ..., 3) [fffffffffa002000,fffffffffa003fff]/204 PCI: dev PCI device 1000:000b type 64-bit pcibios_update_resource(20:01, ..., 0) [200100,2001ff]/101 pcibios_update_resource(20:01, ..., 1) [fffffffffa000400,fffffffffa0007ff]/204 PCI: dev PCI device 1000:000b type 64-bit pcibios_update_resource(20:01, ..., 3) [fffffffffa004000,fffffffffa005fff]/204 PCI: dev PCI device 1000:000b type 64-bit LBA pci_set_bus_ranges() pcibios_fixup_pbus_ranges(0, [0,1000 fffffffff8000000,fffffffff8100000]) pcibios_fixup_pbus_ranges(16, [100000,101000 fffffffff9000000,fffffffff9100000]) pcibios_fixup_pbus_ranges(32, [200000,201000 fffffffffa000000,fffffffffa100000]) lba version TR4.0 (0x5) found at 0xfffffffffed3c000 0: 0x8000000000000000 PA 0x0000000000000030,0x0000000000000037 IO 0x0000000000000030,0x0000000000000037 1: 0x8000000000000001 PA 0xfffffffffb000000,0xfffffffffb7fffff IO 0x00000000fb000000,0x00000000fb7fffff 2: 0x8000000000000002 PA 0xfffffffb04000000,0xfffffffb7fffffff IO 0x000000fb04000000,0x000000fb7fffffff lba range[2] : ignoring GMMIO (0xfffffffb04000000) 3: 0x8000000000000004 PA 0xfffffffb00000000,0xfffffffb03ffffff IO 0x000000fb00000000,0x000000fb03ffffff lba_fixup_bus(0x00000000cffe66c0) bus 48 sysdata 0x00000000cffe65c0 cons 0x00002000 boot 0x00000000 kbd 0x00002000 lba_fixup_bus(0x00000000cffe67c0) bus 49 sysdata 0x00000000cffe65c0 cons 0x00002000 boot 0x00000000 kbd 0x00002000 lba_fixup_bus(0x00000000cffe68c0) bus 50 sysdata 0x00000000cffe65c0 cons 0x00002000 boot 0x00000000 kbd 0x00002000 LBA PIOP resource tree 00000000cffe6610 [300000,37ffff]/100 LBA pcibios_size_bridges() LBA pci_assign_unassigned_resources() PCI: Failed to allocate resource 0 for PCI device 1000:000b PCI: Failed to allocate resource 1 for PCI device 1000:000b PCI: Failed to allocate resource 3 for PCI device 1000:000b PCI: Failed to allocate resource 0 for PCI device 1000:000b PCI: Failed to allocate resource 1 for PCI device 1000:000b PCI: Failed to allocate resource 3 for PCI device 1000:000b PCI: Failed to allocate resource 0 for PCI device 1011:0019 PCI: Failed to allocate resource 1 for PCI device 1011:0019 PCI: Failed to allocate resource 0 for PCI device 1011:0019 PCI: Failed to allocate resource 1 for PCI device 1011:0019 PCI: Failed to allocate resource 0 for PCI device 1011:0009 PCI: Failed to allocate resource 1 for PCI device 1011:0009 PCI: Failed to allocate resource 0 for PCI device 1011:0009 PCI: Failed to allocate resource 1 for PCI device 1011:0009 PCI: Failed to allocate resource 0 for PCI device 1011:0009 PCI: Failed to allocate resource 1 for PCI device 1011:0009 PCI: Failed to allocate resource 0 for PCI device 1011:0009 PCI: Failed to allocate resource 1 for PCI device 1011:0009 LBA pci_set_bus_ranges() pcibios_fixup_pbus_ranges(0, [0,1000 fffffffff8000000,fffffffff8100000]) pcibios_fixup_pbus_ranges(16, [100000,101000 fffffffff9000000,fffffffff9100000]) pcibios_fixup_pbus_ranges(32, [200000,201000 fffffffffa000000,fffffffffa100000]) pcibios_fixup_pbus_ranges(49, [310000,311000 fffffffffb000000,fffffffffb100000]) pcibios_fixup_pbus_ranges(50, [320000,321000 fffffffffb000000,fffffffffb100000]) pcibios_fixup_pbus_ranges(48, [0,1000 fb000000,fb100000]) SBA found Astro 2.1 at 0xfffffffffed00000 lba_init_iregs() ibase 0x1 imask 0xf0000000 lba_init_iregs() base_addr fffffffffed3c000 lba_init_iregs() base_addr fffffffffed38000 lba_init_iregs() base_addr fffffffffed34000 lba_init_iregs() base_addr fffffffffed30000 lba_init_iregs() done lba: lba_bios_init Linux NET4.0 for Linux 2.4 Based upon Swansea University Computer Society NET3.039 NET4: Linux TCP/IP 1.0 for NET4.0 IP Protocols: ICMP, UDP, TCP IP: routing cache hash table of 1024 buckets, 16Kbytes TCP: Hash tables configured (established 8192 bind 8192) Starting kswapd v1.7 pty: 256 Unix98 ptys configured lp: driver loaded but no devices found RAMDISK driver initialized: 16 RAM disks of 4096K size 1024 blocksize sym53c8xx: at PCI bus 0, device 2, function 0 sym53c8xx: setting PCI_COMMAND_PARITY...(fix-up) sym53c8xx: changing PCI_LATENCY_TIMER from 0 to 80. kernel BUG at sym53c8xx.c:725! sym53c8xx: 53c876 detected sym53c8xx: at PCI bus 0, device 2, function 1 sym53c8xx: setting PCI_COMMAND_PARITY...(fix-up) sym53c8xx: changing PCI_LATENCY_TIMER from 0 to 80. kernel BUG at sym53c8xx.c:725! sym53c8xx: 53c876 detected sym53c8xx: at PCI bus 0, device 1, function 0 sym53c8xx: setting PCI_COMMAND_PARITY...(fix-up) sym53c8xx: changing PCI_LATENCY_TIMER from 0 to 80. kernel BUG at sym53c8xx.c:725! sym53c8xx: 53c896 detected sym53c8xx: at PCI bus 0, device 1, function 1 sym53c8xx: setting PCI_COMMAND_PARITY...(fix-up) sym53c8xx: changing PCI_LATENCY_TIMER from 0 to 80. kernel BUG at sym53c8xx.c:725! sym53c8xx: 53c896 detected sym53c8xx: at PCI bus 32, device 0, function 0 sym53c8xx: setting PCI_COMMAND_PARITY...(fix-up) sym53c8xx: changing PCI_LATENCY_TIMER from 0 to 80. kernel BUG at sym53c8xx.c:725! sym53c8xx: 53c896 detected sym53c8xx: at PCI bus 32, device 0, function 1 sym53c8xx: setting PCI_COMMAND_PARITY...(fix-up) sym53c8xx: changing PCI_LATENCY_TIMER from 0 to 80. kernel BUG at sym53c8xx.c:725! sym53c8xx: 53c896 detected sym53c8xx: at PCI bus 49, device 4, function 0 sym53c8xx: setting PCI_COMMAND_PARITY...(fix-up) sym53c8xx: changing PCI_LATENCY_TIMER from 0 to 80. kernel BUG at sym53c8xx.c:725! sym53c8xx: 53c896 detected sym53c8xx: at PCI bus 49, device 4, function 1 sym53c8xx: setting PCI_COMMAND_PARITY...(fix-up) sym53c8xx: changing PCI_LATENCY_TIMER from 0 to 80. kernel BUG at sym53c8xx.c:725! sym53c8xx: 53c896 detected kernel BUG at sym53c8xx.c:725! sym53c876-0: rev 0x14 on pci bus 0 device 2 function 0 irq 130 sym53c876-0: NCR clock is 40218KHz sym53c876-0: ID 7, Fast-20, Parity Checking sym53c876-0: on-chip RAM at 0xfffffffff8006000 sym53c876-0: restart (scsi reset). sym53c876-0: Downloading SCSI SCRIPTS. kernel BUG at sym53c8xx.c:725! sym53c876-1: rev 0x14 on pci bus 0 device 2 function 1 irq 131 sym53c876-1: NCR clock is 40218KHz sym53c876-1: ID 7, Fast-20, Parity Checking sym53c876-1: on-chip RAM at 0xfffffffff8007000 sym53c876-1: restart (scsi reset). sym53c876-1: Downloading SCSI SCRIPTS. kernel BUG at sym53c8xx.c:725! sym53c896-2: rev 0x7 on pci bus 0 device 1 function 0 irq 129 sym53c896-2: NCR clock is 40218KHz sym53c896-2: ID 7, Fast-40, Parity Checking sym53c896-2: on-chip RAM at 0xfffffffff8002000 sym53c896-2: restart (scsi reset). sym53c896-2: handling phase mismatch from SCRIPTS. sym53c896-2: Downloading SCSI SCRIPTS. kernel BUG at sym53c8xx.c:725! sym53c896-3: rev 0x7 on pci bus 0 device 1 function 1 irq 130 sym53c896-3: NCR clock is 40218KHz sym53c896-3: ID 7, Fast-40, Parity Checking sym53c896-3: on-chip RAM at 0xfffffffff8004000 sym53c896-3: restart (scsi reset). sym53c896-3: handling phase mismatch from SCRIPTS. sym53c896-3: Downloading SCSI SCRIPTS. kernel BUG at sym53c8xx.c:725! sym53c896-4: rev 0x1 on pci bus 32 device 0 function 0 irq 256 sym53c896-4: NCR clock is 40218KHz sym53c896-4: ID 7, Fast-40, Parity Checking sym53c896-4: on-chip RAM at 0xfffffffffa002000 sym53c896-4: restart (scsi reset). sym53c896-4: handling phase mismatch from SCRIPTS. sym53c896-4: Downloading SCSI SCRIPTS. kernel BUG at sym53c8xx.c:725! sym53c896-5: rev 0x1 on pci bus 32 device 0 function 1 irq 257 sym53c896-5: NCR clock is 40218KHz sym53c896-5: ID 7, Fast-40, Parity Checking sym53c896-5: on-chip RAM at 0xfffffffffa004000 sym53c896-5: restart (scsi reset). sym53c896-5: handling phase mismatch from SCRIPTS. sym53c896-5: Downloading SCSI SCRIPTS. kernel BUG at sym53c8xx.c:725! sym53c896-6: rev 0x5 on pci bus 49 device 4 function 0 irq 323 sym53c896-6: ID 7, Fast-40, Parity Checking sym53c896-6: on-chip RAM at 0xfffffffffb000000 CACHE TEST FAILED: reg dstat-sstat2 readback ffffffff. CACHE INCORRECTLY CONFIGURED. sym53c896-6: giving up ... kernel BUG at sym53c8xx.c:725! kernel BUG at sym53c8xx.c:725! kernel BUG at sym53c8xx.c:725! sym53c896-6: rev 0x5 on pci bus 49 device 4 function 1 irq 320 sym53c896-6: ID 7, Fast-40, Parity Checking sym53c896-6: on-chip RAM at 0xfffffffffb000000 CACHE TEST FAILED: reg dstat-sstat2 readback ffffffff. CACHE INCORRECTLY CONFIGURED. sym53c896-6: giving up ... kernel BUG at sym53c8xx.c:725! kernel BUG at sym53c8xx.c:725! scsi0 : sym53c8xx - version 1.6b scsi1 : sym53c8xx - version 1.6b scsi2 : sym53c8xx - version 1.6b scsi3 : sym53c8xx - version 1.6b scsi4 : sym53c8xx - version 1.6b scsi5 : sym53c8xx - version 1.6b scsi : 6 hosts. Vendor: SEAGATE Model: ST318404LC Rev: HP01 Type: Direct-Access ANSI SCSI revision: 03 Detected scsi disk sda at scsi3, channel 0, id 15, lun 0 sym53c896-3-<15,0>: tagged command queue depth set to 8 scsi : detected 1 SCSI disk total. sym53c896-3-<15,0>: wide msgout: 1-2-3-1. sym53c896-3-<15,0>: wide msgin: 1-2-3-1. sym53c896-3-<15,0>: wide: wide=1 chg=0. sym53c896-3-<15,0>: wide msgout: 1-2-3-1. sym53c896-3-<15,0>: wide msgin: 1-2-3-1. sym53c896-3-<15,0>: wide: wide=1 chg=0. sym53c896-3-<15,0>: sync msgout: 1-3-1-c-1f. sym53c896-3-<15,0>: sync msg in: 1-3-1-c-1f. sym53c896-3-<15,0>: sync: per=12 scntl3=0xb0 scntl4=0x0 ofs=31 fak=0 chg=0. sym53c896-3-<15,*>: FAST-20 WIDE SCSI 40.0 MB/s (50 ns, offset 31) SCSI device sda: hdwr sector= 512 bytes. Sectors= 35566480 [17366 MB] [17.4 GB] Partition check: sda: unknown partition table Serial driver version 5.01 (2000-05-29) with MANY_PORTS SHARE_IRQ SERIAL_PCI enabled Linux Tulip driver version 0.9.8 (July 13, 2000) tulip: MMIO resource (0x80@0x0) unavailable, aborting tulip: MMIO resource (0x80@0x310200) unavailable, aborting tulip: MMIO resource (0x80@0x310280) unavailable, aborting tulip: MMIO resource (0x80@0x320300) unavailable, aborting tulip: MMIO resource (0x80@0x320380) unavailable, aborting tulip: MMIO resource (0x80@0x320400) unavailable, aborting tulip: MMIO resource (0x80@0x320480) unavailable, aborting IP-Config: No network devices available. Switching from PDC console From alan@linuxcare.com.au Thu, 2 Nov 2000 19:51:19 +1100 (EST) Date: Thu, 2 Nov 2000 19:51:19 +1100 (EST) From: Alan Modra alan@linuxcare.com.au Subject: [parisc-linux] new method for 64-bit parisc tree On Wed, 1 Nov 2000, Paul Bame wrote: > The future parisc64 tree ONLY contains files which are different from, > or in addition to, those in the parisc tree. When you 'make config' > or 'make oldconfig', each file in the parsic tree is symbolically > linked as the same file in the parisc64 tree. This enables all > the rest of the tools/build to work normally. 'make distclean' includes > a step to remove all the symlinks. Instead, can't you simply play tricks with -I, and add a symbolic link asm -> ../asm-parisc in asm-parisc64)? The idea being to end up with an include path looking like "-I $(TOPDIR)/include -I $(TOPDIR)/include/asm" That way, asm/foo.h is found by the first -I if we have asm-parisc64/foo.h, and is found by the second if asm-parisc/foo.h exists but not asm-parisc64/foo.h. Hmm, you might also need -I- -- Linuxcare. Support for the Revolution. From rhirst@linuxcare.com Thu, 2 Nov 2000 10:43:06 +0000 Date: Thu, 2 Nov 2000 10:43:06 +0000 From: Richard Hirst rhirst@linuxcare.com Subject: [parisc-linux] a500.out16 On Thu, Nov 02, 2000 at 12:21:36AM -0800, Grant Grundler wrote: > Hi Richard (et al), > I finally think I understand how pcibios_align_resource() is used... > that definitely was the problem. Everything on A500 but PCI-PCI bridge > seems to be assigned I/O port and MMIO addresses correctly. > > I'll look at tulip code tomorrow to see why it's not happy. I fixed tulip_core.c to report what it means, which gave me tulip: MMIO resource (0x400@0xfffffffff8020000) unavailable, aborting Note sym53c8xx.c doesn't seem to bother with request_mem_region(), so maybe request_mem_region() is just broken. I then patched out the goto, so it ignored that error, and.... Linux Tulip driver version 0.9.8 (July 13, 2000) tulip: MMIO resource (0x400@0xfffffffff8020000) unavailable, aborting PCI: Setting latency timer of device 00:00.0 to 64 eth0: Digital DS21143 Tulip rev 65 at 0x0, 00:30:6E:03:79:A0, IRQ 128. eth0: MII transceiver #1 config 1000 status 782d advertising 01e1. Sending BOOTP requests.... OK IP-Config: Got BOOTP answer from 10.160.240.111, my address is 10.160.240.117 Switching from PDC console Wheeee! Nice work Grant! Richard From rhirst@linuxcare.com Thu, 2 Nov 2000 10:48:33 +0000 Date: Thu, 2 Nov 2000 10:48:33 +0000 From: Richard Hirst rhirst@linuxcare.com Subject: [parisc-linux] a500.out16 On Thu, Nov 02, 2000 at 12:21:36AM -0800, Grant Grundler wrote: > I'd also like to connect some more SCSI disks....but any clue > what the "CACHE TEST FAILED" is about? .... > sym53c896-6: rev 0x5 on pci bus 49 device 4 function 0 irq 323 > sym53c896-6: ID 7, Fast-40, Parity Checking > sym53c896-6: on-chip RAM at 0xfffffffffb000000 > CACHE TEST FAILED: reg dstat-sstat2 readback ffffffff. > CACHE INCORRECTLY CONFIGURED. I'd guess that the NCR registers are being cached: static int __init ncr_regtest (struct ncb* np) { register volatile u_int32 data; /* ** ncr registers may NOT be cached. ** write 0xffffffff to a read only register area, ** and try to read it back. */ data = 0xffffffff; OUTL_OFF(offsetof(struct ncr_reg, nc_dstat), data); data = INL_OFF(offsetof(struct ncr_reg, nc_dstat)); #if 1 if (data == 0xffffffff) { #else if ((data & 0xe2f0fffd) != 0x02000080) { #endif printk ("CACHE TEST FAILED: reg dstat-sstat2 readback %x.\n", (unsigned) data); return (0x10); }; return (0); } Richard From fl@fl.priv.at Thu, 02 Nov 2000 12:15:17 +0100 Date: Thu, 02 Nov 2000 12:15:17 +0100 From: Friedrich Lobenstock fl@fl.priv.at Subject: [parisc-linux] HP 3000 - 922LX ?? Hi! How about support for a HP3000-922LX? I think this should be a PA-RISC machine. PS: Please CC me, because I'm not on the list. MfG / Regards Friedrich Lobenstock From rhirst@linuxcare.com Thu, 2 Nov 2000 11:30:47 +0000 Date: Thu, 2 Nov 2000 11:30:47 +0000 From: Richard Hirst rhirst@linuxcare.com Subject: [parisc-linux] a500.out16 On Thu, Nov 02, 2000 at 10:43:06AM +0000, Richard Hirst wrote: > On Thu, Nov 02, 2000 at 12:21:36AM -0800, Grant Grundler wrote: > > Hi Richard (et al), > > I finally think I understand how pcibios_align_resource() is used... > > that definitely was the problem. Everything on A500 but PCI-PCI bridge > > seems to be assigned I/O port and MMIO addresses correctly. > > > > I'll look at tulip code tomorrow to see why it's not happy. > > I fixed tulip_core.c to report what it means, which gave me > > tulip: MMIO resource (0x400@0xfffffffff8020000) unavailable, aborting > > Note sym53c8xx.c doesn't seem to bother with request_mem_region(), so > maybe request_mem_region() is just broken. It is broken because of the following line in kernel/resource.c: struct resource iomem_resource = { "PCI mem", 0x00000000, 0xffffffff, IORESOURCE_MEM }; 'end' needs to be rather higher than 0xffffffff on 64 bit. I changed it to struct resource iomem_resource = { "PCI mem", 0x00000000, ~0, IORESOURCE_MEM }; and it works. I havn't committed that 'fix' though. Richard From matthew@wil.cx Thu, 2 Nov 2000 11:57:53 +0000 Date: Thu, 2 Nov 2000 11:57:53 +0000 From: Matthew Wilcox matthew@wil.cx Subject: [parisc-linux] HP 3000 - 922LX ?? On Thu, Nov 02, 2000 at 12:15:17PM +0100, Friedrich Lobenstock wrote: > Hi! > > How about support for a HP3000-922LX? I think this should be a PA-RISC > machine. According to the docs: http://www.thepuffingroup.com/parisc/hp9000_models.html the 922 is the same physical machine as the 822. As such, it's too old for it to be worth supporting. the official statement is... The earliest PA-RISC servers have proprietary HP devices attached to proprietary HP bus architectures. It is unlikely that documentation on these busses and devices will ever become available, since so few people are interested in spending any effort finding and releasing the docs. Machines in this category are the E, F, G, H, I class (aka Nova) and T500 series (Emerald) machines as well as some earlier, unlettered servers. I should perhaps update this to reflect the particular model numbers. -- Revolutions do not require corporate support. From rhirst@linuxcare.com Thu, 2 Nov 2000 12:07:36 +0000 Date: Thu, 2 Nov 2000 12:07:36 +0000 From: Richard Hirst rhirst@linuxcare.com Subject: [parisc-linux] a500.out16 On Thu, Nov 02, 2000 at 10:43:06AM +0000, Richard Hirst wrote: > Linux Tulip driver version 0.9.8 (July 13, 2000) > tulip: MMIO resource (0x400@0xfffffffff8020000) unavailable, aborting > PCI: Setting latency timer of device 00:00.0 to 64 > eth0: Digital DS21143 Tulip rev 65 at 0x0, 00:30:6E:03:79:A0, IRQ 128. > eth0: MII transceiver #1 config 1000 status 782d advertising 01e1. > Sending BOOTP requests.... OK > IP-Config: Got BOOTP answer from 10.160.240.111, my address is 10.160.240.117 > Switching from PDC console > > Wheeee! Nice work Grant! And if you stop it from trying to switch from pdc to ttyS0 console: Linux Tulip driver version 0.9.8 (July 13, 2000) PCI: Setting latency timer of device 00:00.0 to 64 eth0: Digital DS21143 Tulip rev 65 at 0x0, 00:30:6E:03:79:A0, IRQ 128. eth0: MII transceiver #1 config 1000 status 782d advertising 01e1. Sending BOOTP requests.... OK IP-Config: Got BOOTP answer from 10.160.240.111, my address is 10.160.240.117 kmem_create: Forcing size word alignment - nfs_fh Looking up port of RPC 100003/2 on 10.160.240.111 Looking up port of RPC 100005/2 on 10.160.240.111 VFS: Mounted root (nfs filesystem) readonly. Warning: unable to open an initial console. Kernel panic: Attempted to kill init! Richard From matthew@wil.cx Thu, 2 Nov 2000 12:01:58 +0000 Date: Thu, 2 Nov 2000 12:01:58 +0000 From: Matthew Wilcox matthew@wil.cx Subject: [parisc-linux] a500.out16 On Thu, Nov 02, 2000 at 11:30:47AM +0000, Richard Hirst wrote: > > Note sym53c8xx.c doesn't seem to bother with request_mem_region(), so > > maybe request_mem_region() is just broken. > > It is broken because of the following line in kernel/resource.c: > > struct resource iomem_resource = { "PCI mem", 0x00000000, 0xffffffff, IORESOURCE_MEM }; > > 'end' needs to be rather higher than 0xffffffff on 64 bit. I changed it to > > struct resource iomem_resource = { "PCI mem", 0x00000000, ~0, IORESOURCE_MEM }; > > and it works. I havn't committed that 'fix' though. Probably just as well... the pci_consistent interfaces were designed partly to stop 32-bit PCI cards having to do dual-address-cycle on machines with an IOMMU. if you can, this card should get mapped below the 32-bit boundary. -- Revolutions do not require corporate support. From grundler@cup.hp.com Thu, 02 Nov 2000 08:12:47 -0800 Date: Thu, 02 Nov 2000 08:12:47 -0800 From: Grant Grundler grundler@cup.hp.com Subject: [parisc-linux] a500.out16 This is why I do NOT like our current scheme of using host physical addresses to access I/O space. Richard Hirst wrote: ... > I'd guess that the NCR registers are being cached: > > > static int __init ncr_regtest (struct ncb* np) > { > register volatile u_int32 data; > /* > ** ncr registers may NOT be cached. > ** write 0xffffffff to a read only register area, > ** and try to read it back. > */ > data = 0xffffffff; > OUTL_OFF(offsetof(struct ncr_reg, nc_dstat), data); > data = INL_OFF(offsetof(struct ncr_reg, nc_dstat)); If INL_OFF and OUTL_OFF are broken, they will very likely point to something in memory - page zero. And happily scribble over it gsc_write(xxx). We don't cache I/O space. Never. Something is definitely broken on this code path. I'll look at this once I find out what I broke on the j5k/c3k boot path in lba_pci.c. jsm already restored the previous version of lba_pci.c so folks can still boot 32-bit on c3k/j5k. grant Grant Grundler Unix Systems Enablement Lab +1.408.447.7253 From bame@riverrock.org Thu, 02 Nov 2000 09:20:24 -0700 Date: Thu, 02 Nov 2000 09:20:24 -0700 From: bame@riverrock.org bame@riverrock.org Subject: [parisc-linux] new method for 64-bit parisc tree I want to hear concerns because without serious ones I'm going to make this change next week... = Instead, can't you simply play tricks with -I, and add a symbolic link = asm -> ../asm-parisc in asm-parisc64)? The idea being to end up with = an include path looking like = "-I $(TOPDIR)/include -I $(TOPDIR)/include/asm" = = That way, asm/foo.h is found by the first -I if we have asm-parisc64/foo.h, = and is found by the second if asm-parisc/foo.h exists but not = asm-parisc64/foo.h. Hmm, you might also need -I- That would function fine for header files, but not for source files where something like VPATH might work, but is not available to us. It's worth noting that both -I and VPATH tricks mean if you have an error in or need to change a file, you may have to examine two directories to figure out where it really lives. The symbolic link scheme solves some of that problem. -P From dkennedy@linuxcare.com Thu, 2 Nov 2000 12:30:32 -0800 (PST) Date: Thu, 2 Nov 2000 12:30:32 -0800 (PST) From: dkennedy dkennedy@linuxcare.com Subject: [parisc-linux] Boot Problems with 755 On Mon, 30 Oct 2000, Matthew Wilcox wrote: > This isn't tagged correctly in the hwdb. Could someone inside linuxcare > please fix this? It should be supported by the Apricot driver. I have updated the hwdb to include the Coral II Core Lan Apricot driver. -- David Kennedy, Technical Account Manager, Linuxcare, Inc. 613.562.9594 tel, 613.562.9304 fax dkennedy@linuxcare.com, http://www.linuxcare.com/ Linuxcare. Support for the revolution. From grundler@cup.hp.com Thu, 02 Nov 2000 08:42:06 -0800 Date: Thu, 02 Nov 2000 08:42:06 -0800 From: Grant Grundler grundler@cup.hp.com Subject: [parisc-linux] a500.out16 Matthew Wilcox wrote: > On Thu, Nov 02, 2000 at 11:30:47AM +0000, Richard Hirst wrote: > > > Note sym53c8xx.c doesn't seem to bother with request_mem_region(), so > > > maybe request_mem_region() is just broken. > > > > It is broken because of the following line in kernel/resource.c: > > > > struct resource iomem_resource = { "PCI mem", 0x00000000, 0xffffffff, IORES > OURCE_MEM }; > > > > 'end' needs to be rather higher than 0xffffffff on 64 bit. I changed it to > > > > struct resource iomem_resource = { "PCI mem", 0x00000000, ~0, IORESOURCE_ME > M }; > > > > and it works. I havn't committed that 'fix' though. > > Probably just as well... the pci_consistent interfaces were designed > partly to stop 32-bit PCI cards having to do dual-address-cycle on > machines with an IOMMU. if you can, this card should get mapped below > the 32-bit boundary. Mathew, That's not the whole story. The value (0xfffffffff8020000) seen by the PCI driver *is* a 32-bit PCI address - dual address cycles are not needed. pcibios_update_resource() mangles the address the PCI device driver uses to fit the BAR it's supposed to get written to. See arch/parisc/kernel/pci.c and I think you'll understand. I think you are confusing DMA with PIO (register accesses). The address above is only used to PIO to access registers and has nothing to do with DMA (or I/O MMUs). And PCI device's that can do dual address cycle *should* in order to *avoid* the I/O MMU. The I/O MMU introduces a latency in the DMA path which ideally would be avoided. Of course, there are lots of issues with making that actually work...but it can work. I haven't looked at the whole issue of 64-bit BAR's yet. Mostly because I haven't had to. 64-bit BAR's work just fine when the upper 32-bits are zero'd. :^) But also because the 896 chip (older rev's at least) has 64-bit BARs and it didn't work during N-class bringup in Feb 1999. Currently shipping revs may work. A hack needs to go into pci_quirks.c to support 896 64-bit BARs. thanks for the ideas though, grant Grant Grundler Unix Systems Enablement Lab +1.408.447.7253 From headcrusher@web.de Thu, 2 Nov 2000 19:58:51 +0100 Date: Thu, 2 Nov 2000 19:58:51 +0100 From: =?iso-8859-1?Q? Alexander=20Sch=F6ck ?= headcrusher@web.de Subject: [parisc-linux] Help!? Hallo Puffingroup-Team, I have a very important question about the installation of the linux for PARisc. I hope you can help me! OK, i have a 725/100 Unix Workstation, i tried to install the PARisc-linux on this machine. The CD is booting from this machine, but in the middle of the booting phase the system hang on following line: "request_irq(259, c01ec76c, 0x0, asp, c3rcd080)" - So, what's wrong? How can I go on with the installation? Bye, Alexander S. _______________________________________________________________________ 1.000.000 DM gewinnen - kostenlos tippen - http://millionenklick.web.de IhrName@web.de, 8MB Speicher, Verschluesselung - http://freemail.web.de From matthew@wil.cx Fri, 3 Nov 2000 00:08:06 +0000 Date: Fri, 3 Nov 2000 00:08:06 +0000 From: Matthew Wilcox matthew@wil.cx Subject: [parisc-linux] Help!? On Thu, Nov 02, 2000 at 07:58:51PM +0100, Alexander Schöck wrote: > How can I go on with the installation? question added to the FAQ: 7. I'm using the Alpha 0.1 release CD and the machine stops after printing request_irq(259, c01ec76c, 0x0, asp, c3rcd080) what's going on? This is a bug in the kernel shipped on the CD. It only affects certain machines and has been fixed in the current CVS tree. We recommend you acquire a newer kernel from the FTP site. -- Revolutions do not require corporate support. From kailasr@webcash.com Thu, 02 Nov 2000 17:29:19 -0800 Date: Thu, 02 Nov 2000 17:29:19 -0800 From: Kailashnath V Rampure kailasr@webcash.com Subject: [parisc-linux] Boot command Hi, I have run the following command to initialize the sda harddisk. The sda3 is the linux native partion. Wen I say boot on the HP server it is trying to boot from /stand/vmunix instead of vmlinux can any one help me about the command. Secondaly I want to knwo what is the term type as its not taking vt100 so I am unable to open vi. I have made nesessary changes for the /etc/fstab $ palo -I -k /boot/vmlinux -b /boot/iplboot -c '3/boot/vmlinux TERM=linux HOME=/ root=/dev/sda3' /dev/sda regards Kailas From grundler@cup.hp.com Thu, 02 Nov 2000 17:44:23 -0800 Date: Thu, 02 Nov 2000 17:44:23 -0800 From: Grant Grundler grundler@cup.hp.com Subject: [parisc-linux] Boot command Kailashnath V Rampure wrote: > Hi, > I have run the following command to initialize the sda harddisk. The sda3 > is the linux native partion. > Wen I say boot on the HP server it is trying to boot from /stand/vmunix > instead of vmlinux can any one help me about the command. Sounds like your system is booting from an existing HPUX installed disk. Ie you are not using palo. > Secondaly I want > to knwo what is the term type as its not taking vt100 so I am unable to > open vi. TERM=linux is what I've seen before. The debian ncurses package might need to be installed first though and vt100 should work too. Search the mail archive at http://puffin.external.hp.com/cgi-bin/mailgrep grant > > I have made nesessary changes for the /etc/fstab > > $ palo -I -k /boot/vmlinux -b /boot/iplboot -c '3/boot/vmlinux TERM=linux > HOME=/ root=/dev/sda3' /dev/sda > > regards > Kailas > > --------------------------------------------------------------------------- > To unsubscribe: send e-mail to parisc-linux-request@thepuffingroup.com with > `unsubscribe' as the subject. > Grant Grundler Unix Systems Enablement Lab +1.408.447.7253 From taggart@carmen.fc.hp.com Thu, 02 Nov 2000 18:47:33 -0700 Date: Thu, 02 Nov 2000 18:47:33 -0700 From: Matt Taggart taggart@carmen.fc.hp.com Subject: [parisc-linux] Boot command Kailashnath V Rampure writes... > Hi, > I have run the following command to initialize the sda harddisk. The sda3 > is the linux native partion. > Wen I say boot on the HP server it is trying to boot from /stand/vmunix > instead of vmlinux can any one help me about the command. This means that you are somehow still booting an HP-UX lifimage. Did you follow the directions on, http://www.thepuffingroup.com/parisc/install.html including the partitioning stuff? Maybe you're still booting off another disk, are you sure you're booting from the linux disk? HTH, -- Matt Taggart taggart@fc.hp.com From headcrusher@web.de Fri, 3 Nov 2000 08:04:31 +0100 Date: Fri, 3 Nov 2000 08:04:31 +0100 From: =?iso-8859-1?Q? Alexander=20Sch=F6ck ?= headcrusher@web.de Subject: [parisc-linux] Help!? I downloaded a new kernel from the ftp-site, how can i use this kernel to work with my machine? This is a image file, how can i extract this file, or must i copy it only to the boot-cd? How can i use this kernel? Matthew Wilcox schrieb am 03.11.00: > On Thu, Nov 02, 2000 at 07:58:51PM +0100, Alexander Schöck wrote: > > How can I go on with the installation? > > question added to the FAQ: > > 7. I'm using the Alpha 0.1 release CD and the machine stops after printing > request_irq(259, c01ec76c, 0x0, asp, c3rcd080) > what's going on? > > This is a bug in the kernel shipped on the CD. It only affects certain > machines and has been fixed in the current CVS tree. We recommend you > acquire a newer kernel from the FTP site. > > -- > Revolutions do not require corporate support. > _______________________________________________________________________ 1.000.000 DM gewinnen - kostenlos tippen - http://millionenklick.web.de IhrName@web.de, 8MB Speicher, Verschluesselung - http://freemail.web.de From pdbeal@louisville.edu Fri, 3 Nov 2000 10:02:39 -0500 Date: Fri, 3 Nov 2000 10:02:39 -0500 From: Phillip Beal pdbeal@louisville.edu Subject: [parisc-linux] STI Console problems on 735 and 755 Hey, After all the help I obtained from this list, both through my posts and through the archives, I've finally gotten the 735 and 755, that I have access to, to boot and run linux. However, as soon as it starts to process init, the console screen becomes garbled. The system continues to boot, and I can access the machine via serial console and minicom, but the physical console on the box, just prints garbage. Is this normal for this stage of development? I couldn't see anything in the archives, that said it was, so I'm wondering how I fix this problem, if its been fixed before. Thanks, -- Phillip Beal Electrical and Computer Engineering S+LUG Vice-President From adevries@linuxcare.com Fri, 03 Nov 2000 11:37:08 -0500 Date: Fri, 03 Nov 2000 11:37:08 -0500 From: Alex deVries adevries@linuxcare.com Subject: [parisc-linux] STI Console problems on 735 and 755 Phillip Beal wrote: > After all the help I obtained from this list, both through my posts and > through the archives, I've finally gotten the 735 and 755, that I have > access to, to boot and run linux. However, as soon as it starts to > process init, the console screen becomes garbled. The system continues > to boot, and I can access the machine via serial console and minicom, > but the physical console on the box, just prints garbage. Is this > normal for this stage of development? I couldn't see anything in the > archives, that said it was, so I'm wondering how I fix this problem, if > its been fixed before. Good to hear that your 735 and 755 start to boot! What kind of graphics hardware is sitting on a 735 or 755? I think we've only ever looked at that on a 712 and 715. Can you use serial console in the meantime? - Alex -- Alex deVries, Principal Solutions Architect, The Puffins at Linuxcare 613.562.2759 tel alex@linuxcare.com, http://www.linuxcare.com/ Linuxcare, Support for the revolution. From pdbeal@louisville.edu Fri, 3 Nov 2000 10:49:00 -0500 Date: Fri, 3 Nov 2000 10:49:00 -0500 From: Phillip Beal pdbeal@louisville.edu Subject: [parisc-linux] STI Console problems on 735 and 755 > What kind of graphics hardware is sitting on a 735 or 755? I think > we've only ever looked at that on a 712 and 715. Both the 735 and the 755 have the following device, that seems be refer to the graphics: Coral SGC Graphics (10) at 0xf8000000, version 0x4, 0x0, 0x77, 0x0, 0x0 However, the 755 is known only to use mono graphics, even though they both report the same info for the Coral SGC Grpahics. I hope this helps, > Can you use serial console in the meantime? Yeah, serial works just fine. > > - Alex > > -- > Alex deVries, Principal Solutions Architect, The Puffins at Linuxcare > 613.562.2759 tel > alex@linuxcare.com, http://www.linuxcare.com/ > Linuxcare, Support for the revolution. -- Phillip Beal Electrical and Computer Engineering S+LUG Vice-President From kailasr@webcash.com Fri, 03 Nov 2000 11:03:23 -0800 Date: Fri, 03 Nov 2000 11:03:23 -0800 From: Kailashnath V Rampure kailasr@webcash.com Subject: [parisc-linux] Boot command Yes I have been following the same Doc. its tries to boot from the sda as I can see the hard disk path. I have 2 Hdd's one sda and other sdb. the path are 8/16/5.6 and other is 8/16/5.0. Here I think /dev/sda is 8/16/5.6. It is trying to boot but give sthe following o/p: Boot IO Dependent Code (IODC) revision 144 .... SUCCEEDED! HARD Booted. palo ipl bame@noam Tue Oct 31 14:18:02 MST 2000 0/vmlinux 208896 bytes @ 0x1f78c000 0/palo-cmdline '3/boot/vmlinux TERM=linux Home=/ root=/dev/sdb3' /dev/ida1 82 62 1030688 /dev/ida2 f0 1030750 24738 /dev/ida3 83 1055488 1030750 Kernel:partition 3 file /boot/vmlinux ext2 block size 1024 ext2_mount(partition 3) returns 0 ext2_open(/boot/vmlinux)=3 Couldn't gork your kernel executabel format failed to load kernel Failed to load Kernel. please suggest. At 06:47 PM 11/2/00 -0700, Matt Taggart wrote: >Kailashnath V Rampure writes... > > > Hi, > > I have run the following command to initialize the sda harddisk. The sda3 > > is the linux native partion. > > Wen I say boot on the HP server it is trying to boot from /stand/vmunix > > instead of vmlinux can any one help me about the command. > >This means that you are somehow still booting an HP-UX lifimage. Did you >follow the directions on, > >http://www.thepuffingroup.com/parisc/install.html > >including the partitioning stuff? Maybe you're still booting off another >disk, >are you sure you're booting from the linux disk? > >HTH, > >-- >Matt Taggart >taggart@fc.hp.com From grundler@cup.hp.com Fri, 03 Nov 2000 11:19:29 -0800 Date: Fri, 03 Nov 2000 11:19:29 -0800 From: Grant Grundler grundler@cup.hp.com Subject: [parisc-linux] Boot command Kailashnath V Rampure wrote: > Yes I have been following the same Doc. > its tries to boot from the sda as I can see the hard disk path. I have 2 > Hdd's one sda and other sdb. the path are 8/16/5.6 and other is 8/16/5.0. > Here I think /dev/sda is 8/16/5.6. The lower numbered SCSI ID will be /dev/sda. SCSI devices are lettered in the order they are discovered. The order is reflected in /proc/scsi/scsi. grant Grant Grundler Unix Systems Enablement Lab +1.408.447.7253 From kailasr@webcash.com Fri, 03 Nov 2000 11:46:39 -0800 Date: Fri, 03 Nov 2000 11:46:39 -0800 From: Kailashnath V Rampure kailasr@webcash.com Subject: [parisc-linux] Boot command I have removed the 2nd HDD now the boot is trying but I get the same error: my fstab reads as : # /etc/fstab: static file system information. # # #/dev/sda1 /boot ext2 defaults,errors=remount-ro 0 0 #/dev/sda2 none swap sw 0 0 /dev/sda3 / ext2 defaults,errors=remount-ro 0 0 # proc /proc proc defaults 0 0 The erros is as follows: Boot IO Dependent Code (IODC) revision 144 .... SUCCEEDED! HARD Booted. palo ipl bame@noam Tue Oct 31 14:18:02 MST 2000 0/vmlinux 208896 bytes @ 0x1f78c000 0/palo-cmdline '3/boot/vmlinux TERM=linux Home=/ root=/dev/sda3' /dev/ida1 82 62 1030688 /dev/ida2 f0 1030750 24738 /dev/ida3 83 1055488 1030750 Kernel:partition 3 file /boot/vmlinux ext2 block size 1024 ext2_mount(partition 3) returns 0 ext2_open(/boot/vmlinux)=3 Couldn't gork your kernel executabel format failed to load kernel Failed to load Kernel. Please suggest. From dave@hiauly1.hia.nrc.ca Fri, 3 Nov 2000 15:01:17 -0500 (EST) Date: Fri, 3 Nov 2000 15:01:17 -0500 (EST) From: John David Anglin dave@hiauly1.hia.nrc.ca Subject: testcase for hppa64 gcc bug > I think I know what's going on here. The root of the problem is that > pa-64.h defines an ARG_POINTER_REGNUM that isn't a fixed reg, and isn't > eliminable. The arg_pointer isn't even a call-saved reg. That breaks a > number of places in the compiler. > > So I went down the path of trying to fix things properly by defining > ELIMINABLE_REGS and so on, but I ended in a maze of twisty little passages > labelled "Unrecognizable instruction", like this one: > > /src/parisc/gcc/gcc/libgcc2.c: In function `__moddi3': > /src/parisc/gcc/gcc/libgcc2.c:601: Unrecognizable insn: > (insn 1289 209 1298 (set (reg:SI 50 %fr22) > (subreg:SI (plus:DI (reg:DI 30 %r30) > (const_int -272 [0xfffffef0])) 0)) -1 (nil) > (nil)) > /src/parisc/gcc/gcc/libgcc2.c:601: Internal compiler error in > extract_insn, at recog.c:2134 I am making progress in trying to make the arg_pointer register eliminable. I have fixed the above problem. What was happening was that reload_as_needed was incorrectly trying to eliminate the return from millicode calls which is also register r29. I have figured out how to hide it from reload with unspec. However, the compiler is now too good at eliminating the arg_pointer. At -O3, it completely eliminates the arg_pointer. However, as I read the ABI, the call must always set the arg_pointer before calls. Dave -- J. David Anglin dave.anglin@nrc.ca National Research Council of Canada (613) 990-0752 (FAX: 952-6605) From bame@noam.fc.hp.com Fri, 03 Nov 2000 13:30:16 -0700 Date: Fri, 03 Nov 2000 13:30:16 -0700 From: Paul Bame bame@noam.fc.hp.com Subject: [parisc-linux] Boot command = ext2_open(/boot/vmlinux)=3 = Couldn't gork your kernel executabel format failed to load kernel = Failed to load Kernel. That should be "grok" :-) Apparently you're not using cut/paste for these error messages. This is PALO saying that /boot/vmlinux is neither elf32, elf64, nor SOM format. I'm guessing, based on some earlier advice I gave when you were net-booting, that you may have a lifimage there by mistake -- you need a kernel instead, for example from ftp://puffin.external.hp.com/pub/parisc/binaries/kernels To tell for sure, run 'file vmlinux' on that file. If you get vmlinux: 8086 relocatable (Microsoft) that's probably a lifimage. You should get this instead: vmlinux: ELF 32-bit MSB executable, PA-RISC, version 1, statically linked, not stripped -P From kailasr@webcash.com Fri, 03 Nov 2000 14:59:29 -0800 Date: Fri, 03 Nov 2000 14:59:29 -0800 From: Kailashnath V Rampure kailasr@webcash.com Subject: [parisc-linux] Boot command Thanks! Paul. Yes I had copied the lifImage there. Now I have downloaded the kernel from the link you mentioned. I am still unable to use vi as it says "linux:unknown terminal type" Can you help me. To add features can I add deb packages. I am not that familiar with debian. Actually I want to build an apache + mod_ssl+mod_perl on A180c. Regards Kailas At 01:30 PM 11/3/00 -0700, Paul Bame wrote: >= ext2_open(/boot/vmlinux)=3 >= Couldn't gork your kernel executabel format failed to load kernel >= Failed to load Kernel. > >That should be "grok" :-) Apparently you're not using cut/paste for >these error messages. > >This is PALO saying that /boot/vmlinux is neither elf32, elf64, nor SOM >format. I'm guessing, based on some earlier advice I gave when you >were net-booting, that you may have a lifimage there by mistake -- you >need a kernel instead, for example from >ftp://puffin.external.hp.com/pub/parisc/binaries/kernels > >To tell for sure, run 'file vmlinux' on that file. If you get > vmlinux: 8086 relocatable (Microsoft) >that's probably a lifimage. You should get this instead: > vmlinux: ELF 32-bit MSB executable, PA-RISC, version 1, statically > linked, not stripped > > > -P From randolph@tausq.org Sat, 4 Nov 2000 18:02:03 -0700 Date: Sat, 4 Nov 2000 18:02:03 -0700 From: Randolph Chung randolph@tausq.org Subject: [parisc-linux] ldd segfaulting? I think this may be related to what bdale has been seeing... frodo:~# cat test.c int main(int a, char **b) { return 0; } frodo:~# gcc -o test test.c frodo:~# ./test frodo:~# ldd ./test do_page_fault() pid=144 command='ld.so.1' YZrvWESTHLNXBCVMcbcbcbcbOGFRQPDI PSW: 00000000000001001000000100001011 r0-3 00000000 2aac367c 2aaacd67 2aaaa2f0 r4-7 2aac367c 2aaab4e8 2aac3622 2aac02b8 r8-11 20020048 2aaaccb8 2aaaa2f0 00000000 r12-15 00000081 00000080 200201e8 2001fe10 r16-19 00000000 00000000 00000000 2aac367c r20-23 00000000 2aaaa000 2aaaa000 00000041 r24-27 2aaaa000 70000021 20020048 00076b50 r28-31 00000021 20020048 200202c0 2aaacd1b sr0-4 00000000 00002003 00000000 00002003 sr4-8 00002003 00002003 00002003 00002003 IASQ: 00002003 00002003 IAOQ: 2aaadc63 2aaadc67 IIR: 0ce61280 ISR: 00002003 IOR: 2aac02b8 ORIG_R28: 00086350 do_page_fault() pid=145 command='ld.so.1' YZrvWESTHLNXBCVMcbcbcbcbOGFRQPDI PSW: 00000000000001001000000100001011 r0-3 00000000 2aac367c 2aaacd67 2aaaa2f0 r4-7 2aac367c 2aaab4e8 2aac3622 2aac02b8 r8-11 20020048 2aaaccb8 2aaaa2f0 00000000 r12-15 00000081 00000080 200201e8 2001fe10 r16-19 00000000 00000000 00000000 2aac367c r20-23 00000000 2aaaa000 2aaaa000 00000041 r24-27 2aaaa000 70000021 20020048 00076b50 r28-31 00000021 20020048 200202c0 2aaacd1b sr0-4 00000000 00002003 00000000 00002003 sr4-8 00002003 00002003 00002003 00002003 IASQ: 00002003 00002003 IAOQ: 2aaadc63 2aaadc67 IIR: 0ce61280 ISR: 00002003 IOR: 2aac02b8 ORIG_R28: 00090190 ldd: /lib/ld.so.1 exited with unknown exit code (139) frodo:~# gcc --version 2.96 frodo:~# ldd --version ldd (GNU libc) 2.1.95 Copyright (C) 1999 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. Written by Roland McGrath and Ulrich Drepper. frodo:~# Any ideas what's going on? I've tried this both with a Oct26 kernel and one that is from cvs today. Same results. randolph -- @..@ http://www.TauSq.org/ (----) ( >__< ) ^^ ~~ ^^ From alan@linuxcare.com.au Sun, 5 Nov 2000 16:02:43 +1100 (EST) Date: Sun, 5 Nov 2000 16:02:43 +1100 (EST) From: Alan Modra alan@linuxcare.com.au Subject: [parisc-linux] ldd segfaulting? On Sat, 4 Nov 2000, Randolph Chung wrote: > frodo:~# ldd ./test > > do_page_fault() pid=144 command='ld.so.1' Most likely a case of new kernel, ld.so compiled with old gcc. Old is earlier than 25th Oct. Before that gcc put plabels, which need relocating, in .rodata, which is mapped read-only. The new kernel enforces the read-only mapping, so you run into problems when ld.so tries to relocate itself. Fortunately, you only need recompile glibc with a new gcc. Older binaries with plabels in .rodata are handled OK as ld.so re-maps the segments read/write, something it doesn't manage to do for itself. Alan Modra -- Linuxcare. Support for the Revolution. From bdale@gag.com Sat, 04 Nov 2000 23:16:29 -0700 Date: Sat, 04 Nov 2000 23:16:29 -0700 From: Bdale Garbee bdale@gag.com Subject: [parisc-linux] compiler bug? In the build of util-linux, compilation of fdisk/fdiskbsdlabel.c fails as shown below. I have placed "gcc -E" output on pehc in ~bdale/fdiskbsdlabel.E for reference. Hacking the makefiles to remove "-O -O2" allows the compile to complete cleanly. I assume this means something in the compiler is broken? Bdale bdale@j5k:/space/debian/util-linux-2.10o/fdisk $ cc -c -O -O2 -fomit-frame-pointer -I../lib -Wall -Wmissing-prototypes -Wstrict-prototypes -DNCH=1 -DSBINDIR=\"/sbin\" -DUSRSBINDIR=\"/usr/sbin\" -DLOGDIR=\"/var/log\" -DVARPATH=\"/var\" -DLOCALEDIR=\"/usr/share/locale\" fdiskbsdlabel.c -o fdiskbsdlabel.o /usr/include/linux/string.h:12: parse error before "__extension__" /usr/include/linux/string.h:12: parse error before '&&' token /usr/include/linux/string.h:14: parse error before "__extension__" /usr/include/linux/string.h:14: parse error before '(' token /usr/include/linux/string.h:15: parse error before "__extension__" /usr/include/linux/string.h:15: parse error before '&&' token /usr/include/linux/string.h:24: parse error before "__extension__" /usr/include/linux/string.h:27: parse error before "__extension__" /usr/include/linux/string.h:33: parse error before "__extension__" /usr/include/linux/string.h:36: parse error before "__extension__" /usr/include/linux/string.h:36: parse error before '&&' token /usr/include/linux/string.h:36: parse error before '}' token /usr/include/linux/string.h:36: conflicting declarations of `__result' /usr/include/linux/string.h:36: `__result' previously declared here /usr/include/linux/string.h:36: parse error before ')' token /usr/include/linux/string.h:36: `__s2' undeclared here (not in a function) /usr/include/linux/string.h:36: parse error before ';' token /usr/include/linux/string.h:36: conflicting declarations of `__result' /usr/include/linux/string.h:36: `__result' previously defined here /usr/include/linux/string.h:36: parse error before '}' token /usr/include/linux/string.h:36: parse error before '}' token /usr/include/linux/string.h:36: redefinition of `__result' /usr/include/linux/string.h:36: `__result' previously defined here /usr/include/linux/string.h:36: `__s1' undeclared here (not in a function) /usr/include/linux/string.h:36: parse error before ')' token /usr/include/linux/string.h:36: parse error before ';' token /usr/include/linux/string.h:36: conflicting declarations of `__result' /usr/include/linux/string.h:36: `__result' previously defined here /usr/include/linux/string.h:36: parse error before '}' token /usr/include/linux/string.h:39: parse error before "__extension__" /usr/include/linux/string.h:39: parse error before '&&' token /usr/include/linux/string.h:39: parse error before '}' token /usr/include/linux/string.h:39: redefinition of `__result' /usr/include/linux/string.h:36: `__result' previously defined here /usr/include/linux/string.h:39: parse error before ')' token /usr/include/linux/string.h:39: `__s2' undeclared here (not in a function) /usr/include/linux/string.h:39: parse error before ';' token /usr/include/linux/string.h:39: conflicting declarations of `__result' /usr/include/linux/string.h:39: `__result' previously defined here /usr/include/linux/string.h:39: parse error before '}' token /usr/include/linux/string.h:39: parse error before '}' token /usr/include/linux/string.h:39: redefinition of `__result' /usr/include/linux/string.h:39: `__result' previously defined here /usr/include/linux/string.h:39: `__s1' undeclared here (not in a function) /usr/include/linux/string.h:39: parse error before ')' token /usr/include/linux/string.h:39: parse error before ';' token /usr/include/linux/string.h:39: conflicting declarations of `__result' /usr/include/linux/string.h:39: `__result' previously defined here /usr/include/linux/string.h:39: parse error before '}' token /usr/include/linux/string.h:45: parse error before "__extension__" /usr/include/linux/string.h:51: parse error before "__extension__" /usr/include/linux/string.h:61: parse error before "__extension__" /usr/include/linux/string.h:61: parse error before '\x0' /usr/include/linux/string.h:61: parse error before '}' token fdiskbsdlabel.c: In function `xbsd_zaplabel': fdiskbsdlabel.c:840: warning: `sector' might be used uninitialized in this function bdale@j5k:/space/debian/util-linux-2.10o/fdisk $ From alan@linuxcare.com.au Sun, 5 Nov 2000 18:41:54 +1100 (EST) Date: Sun, 5 Nov 2000 18:41:54 +1100 (EST) From: Alan Modra alan@linuxcare.com.au Subject: [parisc-linux] compiler bug? On Sat, 4 Nov 2000, Bdale Garbee wrote: > Hacking the makefiles to remove "-O -O2" allows the compile to complete > cleanly. glibc includes are "smart", and do things like `#if defined __OPTIMIZE__' > I assume this means something in the compiler is broken? No, I think it's a problem with glibc, or perhaps just your include files. > bdale@j5k:/space/debian/util-linux-2.10o/fdisk $ cc -c -O -O2 -fomit-frame-pointer -I../lib -Wall -Wmissing-prototypes -Wstrict-prototypes -DNCH=1 -DSBINDIR=\"/sbin\" -DUSRSBINDIR=\"/usr/sbin\" -DLOGDIR=\"/var/log\" -DVARPATH=\"/var\" -DLOCALEDIR=\"/usr/share/locale\" fdiskbsdlabel.c -o fdiskbsdlabel.o > /usr/include/linux/string.h:12: parse error before "__extension__" Your .i file had this in it: extern char * ___strtok; extern char * __extension__ ({ char __a0, __a1, __a2; [rest snipped] which comes from linux/string.h extern char * ___strtok; extern char * strcpy(char *,const char *); The problem being that strcpy is being replaced with an inline expansion. Dunno why this is happenning. Alan Modra -- Linuxcare. Support for the Revolution. From xam@sgate.charlysworld.de Mon, 6 Nov 2000 01:14:41 +0100 (CET) Date: Mon, 6 Nov 2000 01:14:41 +0100 (CET) From: xam@deathsdoor.com xam@sgate.charlysworld.de Subject: [parisc-linux] HP9000/730 boot problems Hi all, i have an HP9000/730 (66.6MHz, 32MB RAM, 10MBit Network, CRX graphics, HIL keyboard & mouse, HP 535MBM SCSI HD). I got the latest nfsroot, the latest xc and the palo sources from puffin.external.hp.com. the parition scheme for the HD (id 6) is /dev/sdb1 swap 128MB /dev/sdb2 f0 10MB /dev/sdb3 ext2 rest i untarred nfsroot on /dev/sdb3 and changed /etc/fstab accordingly i installed palo with the following command /opt/palinux/palo-src/palo/palo -I -k /hydra/hppa/boot/vmlinux -b /opt/palinux/palo-src/iplboot -c '3/boot/vmlinux TERM=linux HOME=/ root=/dev/sdb3' /dev/sdb well, i used /dev/sdb since there is also the scsi fd (id 0) that is /dev/sda IMHO (i tested alos to use root=/dev/sda3 btw). some of the boot messages PDC ROM rev. 2.1 IODC ROM rev. 2.1 32 MB of memory configured and tested. Selecting a system to boot. Hard booted. [...] now it prints the palo configuration as i installed it and the hd partition scheme (but /dev/idaXYZ instead of /dev/sdbXYZ [...] ext2 block size 1024 ext2_open(/boot/vmlinux) = 3 ext2_mount(partition 3) returns 0 ELF32 executable [...] now all recognized devices (SGC craphics, BA, HIL, LAN, 2x RS232, SCSI, EISA, Core Centronics, HP model 'king Cobra' ...) the kernel boots actually, but i dumps the stack register and the processor registers (not included in this mail) after ASP version 1 at ..... found thats all. no message like 'unable to boot root fs' or something ... any help ? PS: i tried to use a IBM0664 2.0GB scsi hd before (works fine on linux/ia32), but i couldn't get it work on hp (i reported this in a former mail). PPS: just FYI: the same configuration worked with HP/UX 10.10 From grundler@cup.hp.com Sun, 05 Nov 2000 17:21:12 -0800 Date: Sun, 05 Nov 2000 17:21:12 -0800 From: Grant Grundler grundler@cup.hp.com Subject: [parisc-linux] HP9000/730 boot problems "xam@deathsdoor.com" wrote: > Hi all, > > i have an HP9000/730 (66.6MHz, 32MB RAM, 10MBit Network, CRX graphics, > HIL keyboard & mouse, HP 535MBM SCSI HD). > > I got the latest nfsroot, the latest xc and the palo sources from > puffin.external.hp.com. > > the parition scheme for the HD (id 6) is > > /dev/sdb1 swap 128MB > /dev/sdb2 f0 10MB > /dev/sdb3 ext2 rest > > i untarred nfsroot on /dev/sdb3 and changed /etc/fstab accordingly > i installed palo with the following command > > /opt/palinux/palo-src/palo/palo -I -k /hydra/hppa/boot/vmlinux -b > /opt/palinux/palo-src/iplboot -c '3/boot/vmlinux TERM=linux HOME=/ > root=/dev/sdb3' /dev/sdb > > > well, i used /dev/sdb since there is also the scsi fd (id 0) > that is /dev/sda IMHO (i tested alos to use root=/dev/sda3 btw). using /dev/sdb is ok - your palo command looks "right" to me. > [...] > now it prints the palo configuration as i installed it > and the hd partition scheme (but /dev/idaXYZ instead of /dev/sdbXYZ > [...] > ext2 block size 1024 > ext2_open(/boot/vmlinux) = 3 > ext2_mount(partition 3) returns 0 > ELF32 executable This looks like palo loading the vmlinux. > [...] > > now all recognized devices (SGC craphics, BA, HIL, LAN, 2x RS232, SCSI, > EISA, Core Centronics, HP model 'king Cobra' ...) > > the kernel boots actually, but i dumps the stack register and the > processor registers (not included in this mail) after > > ASP version 1 at ..... found Sounds like ASP support may be broken. The way to find out where IOAQ and GR2 registers are pointing. They should point to functions in System.map. Who is maintaining ASP support? > PS: i tried to use a IBM0664 2.0GB scsi hd before (works fine on > linux/ia32), but i couldn't get it work on hp (i reported this > in a former mail). Right. I'm pretty sure older PDC/IODC doesn't send START_UNIT command to the disk drive. The boot drive is expected to spin up on it's own. I don't know if newer PDC does send START_UNIT either... grant Grant Grundler Unix Systems Enablement Lab +1.408.447.7253 From grundler@cup.hp.com Sun, 5 Nov 2000 18:18:35 -0800 (PST) Date: Sun, 5 Nov 2000 18:18:35 -0800 (PST) From: Grant Grundler grundler@cup.hp.com Subject: [parisc-linux] string.h warnings When linux/arch/parisc/kernel/pci.c built, I get the following warnings: /linux/kwdb64/linux/include/linux/string.h:54: warning: conflicting types for built-in function `strlen' /linux/kwdb64/linux/include/linux/string.h:61: warning: conflicting types for built-in function `memset' /linux/kwdb64/linux/include/linux/string.h:64: warning: conflicting types for built-in function `memcpy' /linux/kwdb64/linux/include/linux/string.h:73: warning: conflicting types for built-in function `memcmp' Could this be related to or shed light on the problem bdale had? thanks, grant From bri@mojo.calyx.net Sun, 5 Nov 2000 21:34:54 -0500 (EST) Date: Sun, 5 Nov 2000 21:34:54 -0500 (EST) From: Brian S. Julin bri@mojo.calyx.net Subject: [parisc-linux] string.h warnings On Sun, 5 Nov 2000, Grant Grundler wrote: > When linux/arch/parisc/kernel/pci.c built, I get the following > warnings: > /linux/kwdb64/linux/include/linux/string.h:54: warning: conflicting types for built-in function `strlen' > /linux/kwdb64/linux/include/linux/string.h:61: warning: conflicting types for built-in function `memset' > /linux/kwdb64/linux/include/linux/string.h:64: warning: conflicting types for built-in function `memcpy' > /linux/kwdb64/linux/include/linux/string.h:73: warning: conflicting types for built-in function `memcmp' For some reason I had numerous problems with string.h not being included when building ncurses natively with the nfsroot tarball. (Also the nfsroot tarball seems to not be able to find the crt* objects by default) -- Brian S. Julin From jsm@udlkern.fc.hp.com Sun, 5 Nov 2000 23:12:56 -0700 (MST) Date: Sun, 5 Nov 2000 23:12:56 -0700 (MST) From: John Marvin jsm@udlkern.fc.hp.com Subject: [parisc-linux] HP 9000/730 boot problem "xam@deathsdoor.com" wrote: > > the kernel boots actually, but i dumps the stack register and the > processor registers (not included in this mail) after > > ASP version 1 at ..... found Grant Grundler wrote: > Sounds like ASP support may be broken. > The way to find out where IOAQ and GR2 registers are pointing. > They should point to functions in System.map. > Who is maintaining ASP support? No, the parallel port support for ASP is broken. If you disable the LASI/ASP builtin parallel-port support (CONFIG_PARPORT_GSC) you will get further. I can't guarantee you will succeed, but others have reported some success on boxes almost that old. This is at least the second time this question has come up, so I guess I'll add it to the FAQ and todo lists. John Marvin jsm@fc.hp.com From marteaut@esiee.fr Tue, 7 Nov 2000 17:00:48 +0100 Date: Tue, 7 Nov 2000 17:00:48 +0100 From: Thomas Marteau marteaut@esiee.fr Subject: [parisc-linux] A browser and a new URL for the ESIEE team web site Hi all, We have succeded to compile Lynx on a 712 and it works well. Also this short mail must tell you that our website can be reached with http://www.esiee.fr/puffin You can find a cool root FS which has the terminfo directory like that you won't have the "vt100:unknown term" message, the network support and lot of thing like that... Bye, ESIEE Team Don't hesitate to visit our website From kailasr@webcash.com Tue, 07 Nov 2000 09:46:53 -0800 Date: Tue, 07 Nov 2000 09:46:53 -0800 From: Kailashnath V Rampure kailasr@webcash.com Subject: [parisc-linux] Boot command Hi, Thanks. I copied the termcap and terminfo directory froma red hat linux box. Now I am able to run VI and the TERM is vt100. Regards Kailas At 02:56 PM 11/5/00 +0100, Thierry SIMONNET wrote: >To have a suitable TERM, you must get termcap or terminfo definition; ie a >good terminfo tree from a linux box. To have a good method to install a >pa/linux box, see my student's web site at http://www.esiee.fr/~djoudim > >Th. SIMONNET > > >Kailashnath V Rampure wrote: > > > Thanks! Paul. > > Yes I had copied the lifImage there. Now I have downloaded the kernel from > > the link you mentioned. > > > > I am still unable to use vi as it says "linux:unknown terminal type" > > Can you help me. > > > > To add features can I add deb packages. I am not that familiar with debian. > > Actually I want to build an apache + mod_ssl+mod_perl on A180c. > > Regards > > Kailas > > > > At 01:30 PM 11/3/00 -0700, Paul Bame wrote: > > >= ext2_open(/boot/vmlinux)=3 > > >= Couldn't gork your kernel executabel format failed to load kernel > > >= Failed to load Kernel. > > > > > >That should be "grok" :-) Apparently you're not using cut/paste for > > >these error messages. > > > > > >This is PALO saying that /boot/vmlinux is neither elf32, elf64, nor SOM > > >format. I'm guessing, based on some earlier advice I gave when you > > >were net-booting, that you may have a lifimage there by mistake -- you > > >need a kernel instead, for example from > > >ftp://puffin.external.hp.com/pub/parisc/binaries/kernels > > > > > >To tell for sure, run 'file vmlinux' on that file. If you get > > > vmlinux: 8086 relocatable (Microsoft) > > >that's probably a lifimage. You should get this instead: > > > vmlinux: ELF 32-bit MSB executable, PA-RISC, version 1, statically > > > linked, not stripped > > > > > > > > > -P > > > > --------------------------------------------------------------------------- > > To unsubscribe: send e-mail to parisc-linux-request@thepuffingroup.com with > > `unsubscribe' as the subject. From bame@noam.fc.hp.com Tue, 07 Nov 2000 11:15:50 -0700 Date: Tue, 07 Nov 2000 11:15:50 -0700 From: Paul Bame bame@noam.fc.hp.com Subject: [parisc-linux] 64-bit BUILD CHANGES The described changes have just been committed to CVS. If you have an existing configured/built 64-bit parisc tree right now I think these are the steps to update: Save your .config file do 'make distclean' do your cvs update restore your .config make oldconfig dep and then proceed as normal The symlinks come when you do a make {old}config and go with a 'make distclean' FYI >>> You may want to start hand-editing .hdepend (following each make dep) to remove the dependency of atomic.h on spinlock.h (just remove the first line containing the string spinlock.h) -- it can cause massive unnecessary rebuilds. It's due to a parisc-specific circular dependency :-( -P = I want to propose/discuss a new method for maintaining our 64-bit parisc = tree in relation to the 32-bit tree. I have prototyped this and so = far it seems pretty useful. = = Most of the files in the current parisc64 tree only contain one = line, a #include of the same file from the parisc tree. This confuses = 'make dep', causes some compile errors to have nonsense line numbers, = and doesn't allow direct editing of the source files in the parisc64 tree. = = The method I'm proposing works like this: = = The future parisc64 tree ONLY contains files which are different from, = or in addition to, those in the parisc tree. When you 'make config' = or 'make oldconfig', each file in the parsic tree is symbolically = linked as the same file in the parisc64 tree. This enables all = the rest of the tools/build to work normally. 'make distclean' includes = a step to remove all the symlinks. = = The ugliest "feature" is that even though you can edit source files = in the parisc64 tree, 'cvs commit' will fail on those which are = symbolic links. To reduce this problem, I'm dropping a symbolic link = called '...' in each parisc64 directory which is a pointer to the = corresponding parisc directory, so 'cd ...; cvs commit foo.c' will = work and not be too onerous. = = We should additionally consider a naming convention or something so = that maintainers in the parisc tree know whether files are shared with = parisc64 or not. = = I prototyped this as a fictional new "architecture" called "p64". To = try it out, grab the tarball (only about 30 files -- can be fewer) = ftp://puffin.external.hp.com/pub/parisc/ = and unpack in your top-level linux source tree directory. Then in = your top-level Makefile, change ARCH := parisc64 to ARCH := p64, then = make oldconfig or whatever you usually do. Let me know of any problems. = = Is this something we should adopt for the real parisc64 tree? = = -Paul Bame = = --------------------------------------------------------------------------- = To unsubscribe: send e-mail to parisc-linux-request@thepuffingroup.com with = `unsubscribe' as the subject. = = = From grundler@cup.hp.com Tue, 07 Nov 2000 11:19:02 -0800 Date: Tue, 07 Nov 2000 11:19:02 -0800 From: Grant Grundler grundler@cup.hp.com Subject: [parisc-linux] Boot command Kailashnath V Rampure wrote: > Hi, > Thanks. I copied the termcap and terminfo directory froma red hat linux > box. Now I am able to run VI and the TERM is vt100. I've added a "vi is complaining" item to the FAQ. Normally the FAQ lives at http://www.thepuffingroup.com/parisc/faq.html but it's not updated yet. I've put a temporary copy at http://puffin.external.hp.com/~grundler/faq.html and will remove this once the regular location is updated. (Hint - relative links won't work from my copy) grant Grant Grundler Unix Systems Enablement Lab +1.408.447.7253 From marteaut@esiee.fr Tue, 7 Nov 2000 20:53:55 +0100 Date: Tue, 7 Nov 2000 20:53:55 +0100 From: Thomas Marteau marteaut@esiee.fr Subject: [parisc-linux] Boot command ----- Original Message ----- From: Grant Grundler To: Kailashnath V Rampure Cc: Sent: Tuesday, November 07, 2000 8:19 PM Subject: Re: [parisc-linux] Boot command > Kailashnath V Rampure wrote: > > Hi, > > Thanks. I copied the termcap and terminfo directory froma red hat linux > > box. Now I am able to run VI and the TERM is vt100. > > I've added a "vi is complaining" item to the FAQ. To use vi and all these applications like top, they need the terminfo directory in /usr/share from any distrib!! Bye, the ESIEE Team From grundler@cup.hp.com Tue, 07 Nov 2000 12:24:39 -0800 Date: Tue, 07 Nov 2000 12:24:39 -0800 From: Grant Grundler grundler@cup.hp.com Subject: [parisc-linux] Boot command "Thomas Marteau" wrote: > Grant Grundler wrote: > > Kailashnat V Rampure wrote: > > > Hi, > > > Thanks. I copied the termcap and terminfo directory froma red hat linux > > > box. Now I am able to run VI and the TERM is vt100. > > > > I've added a "vi is complaining" item to the FAQ. > > To use vi and all these applications like top, they need the terminfo > directory in /usr/share from any distrib!! I didn't say taking from RH was wrong. IMHO, doing so defeats the whole point of debian's packaging system. Please read the new FAQ entry and tell me if I've gotten that right or not. grant Grant Grundler Unix Systems Enablement Lab +1.408.447.7253 From kailasr@webcash.com Tue, 07 Nov 2000 14:50:10 -0800 Date: Tue, 07 Nov 2000 14:50:10 -0800 From: Kailashnath V Rampure kailasr@webcash.com Subject: [parisc-linux] Boot command I agree with you regarding taking from RH. I just wanted to let u all know how I solved the issue. I have gone through the faq it is fine. Regards Kailas At 12:24 PM 11/7/00 -0800, Grant Grundler wrote: >"Thomas Marteau" wrote: > > Grant Grundler wrote: > > > Kailashnat V Rampure wrote: > > > > Hi, > > > > Thanks. I copied the termcap and terminfo directory froma red hat linux > > > > box. Now I am able to run VI and the TERM is vt100. > > > > > > I've added a "vi is complaining" item to the FAQ. > > > > To use vi and all these applications like top, they need the terminfo > > directory in /usr/share from any distrib!! > >I didn't say taking from RH was wrong. >IMHO, doing so defeats the whole point of debian's packaging system. > >Please read the new FAQ entry and tell me if I've gotten >that right or not. > >grant > >Grant Grundler >Unix Systems Enablement Lab >+1.408.447.7253 > >--------------------------------------------------------------------------- >To unsubscribe: send e-mail to parisc-linux-request@thepuffingroup.com with >`unsubscribe' as the subject. From cjknoch@yahoo.com Tue, 7 Nov 2000 15:40:14 -0800 (PST) Date: Tue, 7 Nov 2000 15:40:14 -0800 (PST) From: Christian Knoch cjknoch@yahoo.com Subject: [parisc-linux] HP 9000 e25 hi. i need information about how to install linux on hp 9000 e25 what version on linux what distribution ? how many memoty i need in this machine how many space on disk i need in this machine howto boot machine for install linux Thanks __________________________________________________ Do You Yahoo!? Thousands of Stores. Millions of Products. All in one Place. http://shopping.yahoo.com/ From matthew@wil.cx Wed, 8 Nov 2000 00:28:08 +0000 Date: Wed, 8 Nov 2000 00:28:08 +0000 From: Matthew Wilcox matthew@wil.cx Subject: [parisc-linux] HP 9000 e25 On Tue, Nov 07, 2000 at 03:40:14PM -0800, Christian Knoch wrote: > hi. > i need information about how to install linux on hp > 9000 e25 *sigh*. This is in the FAQ. Where do we need to put links to the FAQ to persuade people to read it? Where did you find this mailing list address, do we need to put a link to the FAQ there? The answer given in the FAQ is: The earliest PA-RISC servers have proprietary HP devices attached to proprietary HP bus architectures. It is unlikely that documentation on these busses and devices will ever become available, since so few people are interested in spending any effort finding and releasing the docs. Machines in this category are the E, F, G, H, I class (aka Nova) and T500 series (Emerald) machines as well as some earlier, unlettered servers. -- Revolutions do not require corporate support. From matthew@wil.cx Wed, 8 Nov 2000 20:14:43 +0000 Date: Wed, 8 Nov 2000 20:14:43 +0000 From: Matthew Wilcox matthew@wil.cx Subject: [parisc-linux] webshite since the lord god alex hasn't seen fit to inform anyone, it seems like i should. the www.thepuffingroup.com website is no longer being updated and all the updates are only going to parisc-linux.org. i have been updating www.thepuffingroup.com becuase no-one told me that this site was no longer supposed to be operational and i suspect a large number of people who subscribe to this list still have it bookmarked. also, email sent to willy@thepuffingroup.com is no longer being received by me. i don't know who gets it, but the sender does not receive a bounce. yours, fucking furious, Matthew. -- "It's time for you to change your sig" -- Alex deVries From grundler@cup.hp.com Wed, 08 Nov 2000 12:31:11 -0800 Date: Wed, 08 Nov 2000 12:31:11 -0800 From: Grant Grundler grundler@cup.hp.com Subject: [parisc-linux] webshite Matthew Wilcox wrote: > > since the lord god alex hasn't seen fit to inform anyone, it seems like > i should. the www.thepuffingroup.com website is no longer being updated > and all the updates are only going to parisc-linux.org. We gave LXC's website maintainer grief about this already. > i have been > updating www.thepuffingroup.comwww.thepuffingroup.com becuase no-one told me that this site > was no longer supposed to be operational and i suspect a large number > of people who subscribe to this list still have it bookmarked. Some time today, I expect (hope?) www.thepuffingroup.com/parisc will be redirected to www.parisc-linux.org (.com works too). I've asked mail be sent to this list when it happens. > also, > email sent to willy@thepuffingroup.com is no longer being received by me. > i don't know who gets it, but the sender does not receive a bounce. This should probably bounce since it's been stale for about 11 monthes now... hope this helps, grant ps. just trying to compensate for an otherwise lack of communication. > > yours, fucking furious, Matthew. > > -- > "It's time for you to change your sig" -- Alex deVries > > --------------------------------------------------------------------------- > To unsubscribe: send e-mail to parisc-linux-request@thepuffingroup.com with > `unsubscribe' as the subject. > Grant Grundler Unix Systems Enablement Lab +1.408.447.7253 From andrew@neep.com.au Thu, 9 Nov 2000 05:13:23 +0800 Date: Thu, 9 Nov 2000 05:13:23 +0800 From: Andrew Shugg andrew@neep.com.au Subject: [parisc-linux] webshite Matthew Wilcox said: > the www.thepuffingroup.com website is no longer being updated and all > the updates are only going to parisc-linux.org. I don't know if there's some other secret mailing list I'm missing out on, but that's the first time I've heard of "parisc-linux.org" I'm sure. So thankyou for being the one to bring it up. Will the mailing list be moving as well? (Given that it belongs with the project, not the mothballed puffingroup website.) > -- > "It's time for you to change your sig" -- Alex deVries Shame, I thought your old sig was funnier. Andrew. -- Andrew Shugg http://www.neep.com.au/ "Just remember, Mr Fawlty, there's always someone worse off than yourself." "Is there? Well I'd like to meet him. I could do with a good laugh." From taggart@carmen.fc.hp.com Wed, 08 Nov 2000 14:22:03 -0700 Date: Wed, 08 Nov 2000 14:22:03 -0700 From: Matt Taggart taggart@carmen.fc.hp.com Subject: [parisc-linux] webshite Andrew Shugg writes... > I don't know if there's some other secret mailing list I'm missing out > on, but that's the first time I've heard of "parisc-linux.org" I'm sure. > So thankyou for being the one to bring it up. It was never officially announced, just setup. I guess this is the announcement. > Will the mailing list be moving as well? (Given that it belongs with > the project, not the mothballed puffingroup website.) Yes, most of the project's web/mail resources will be moving there shortly. Go ahead and update your bookmarks. I've been told there will be a pointer/redirect from the old site but I wouldn't count on it existing forever. -- Matt Taggart taggart@fc.hp.com From andrew@neep.com.au Thu, 9 Nov 2000 05:48:06 +0800 Date: Thu, 9 Nov 2000 05:48:06 +0800 From: Andrew Shugg andrew@neep.com.au Subject: [parisc-linux] HP 9000 e25 Matthew Wilcox said: > On Tue, Nov 07, 2000 at 03:40:14PM -0800, Christian Knoch wrote: > > hi. > > i need information about how to install linux on hp > > 9000 e25 > > *sigh*. This is in the FAQ. Where do we need to put links to the FAQ > to persuade people to read it? Where did you find this mailing list > address, do we need to put a link to the FAQ there? I think the fault lies in the "Contact" page, new (!) URL being: http://parisc-linux.org/contact.html "Most questions about the port should be addressed to the developer mailing list parisc-linux@thepuffingroup.com" I would suggest this page be changed a bit, like stick the mailing list down the bottom and change it to a link to the mailing list subscribe and browse-the-archives page, rather than simply the address of the list. Also a comment about reading the FAQ. Yes, the FAQ is in the left-hand side-bar but you can never over-do the help. =) One of my favourite comments along that line was on the windowmaker.org home page (sadly it has been removed). It was something like "Please bear in mind that asking questions on the mailing list that are answered in the FAQ is NOT A GOOD IDEA." The FAQ on parisc-linux.org is also missing the all-important Q/A pair: Q. I have a question that isn't answered in this FAQ? A. Please subscribe to the [mailing list] and ask. Politely. Preferably in English, or (failing that) in a recognisable pidgin. Don't hold back on the relevant information either. "It won't boot" is not good. Andrew. -- Andrew Shugg http://www.neep.com.au/ "Just remember, Mr Fawlty, there's always someone worse off than yourself." "Is there? Well I'd like to meet him. I could do with a good laugh." From jvinet@linuxcare.com Wed, 08 Nov 2000 17:41:50 -0500 Date: Wed, 08 Nov 2000 17:41:50 -0500 From: Jane Vinet jvinet@linuxcare.com Subject: [parisc-linux] HP 9000 e25 Good advice...will notify the web design folks. Jane -- jvinet@linuxcare.com Andrew Shugg wrote: > I would suggest this page be changed a bit, like stick the mailing list > down the bottom and change it to a link to the mailing list subscribe > and browse-the-archives page, rather than simply the address of the > list. Also a comment about reading the FAQ. Yes, the FAQ is in the > left-hand side-bar but you can never over-do the help. =) > > One of my favourite comments along that line was on the windowmaker.org > home page (sadly it has been removed). It was something like "Please > bear in mind that asking questions on the mailing list that are answered > in the FAQ is NOT A GOOD IDEA." > > The FAQ on parisc-linux.org is also missing the all-important Q/A pair: > > Q. I have a question that isn't answered in this FAQ? > A. Please subscribe to the [mailing list] and ask. Politely. Preferably > in English, or (failing that) in a recognisable pidgin. Don't hold back > on the relevant information either. "It won't boot" is not good. > > Andrew. > > -- > Andrew Shugg http://www.neep.com.au/ > > "Just remember, Mr Fawlty, there's always someone worse off than yourself." > "Is there? Well I'd like to meet him. I could do with a good laugh." > > --------------------------------------------------------------------------- > To unsubscribe: send e-mail to parisc-linux-request@thepuffingroup.com with > `unsubscribe' as the subject. From matthew@wil.cx Thu, 9 Nov 2000 09:59:58 +0000 Date: Thu, 9 Nov 2000 09:59:58 +0000 From: Matthew Wilcox matthew@wil.cx Subject: [parisc-linux] webshite On Thu, Nov 09, 2000 at 05:13:23AM +0800, Andrew Shugg wrote: > Matthew Wilcox said: > > the www.thepuffingroup.com website is no longer being updated and all > > the updates are only going to parisc-linux.org. > > I don't know if there's some other secret mailing list I'm missing out > on, but that's the first time I've heard of "parisc-linux.org" I'm sure. > So thankyou for being the one to bring it up. oh, alex secretly went off and registered it. the first we heard about it was in a press release a couple of months ago. for a while it's been a (broken) redirect to www.thepuffingroup.com/parisc. there's a linuxcare internal mailing list for discussions of the parisc project, but it wasn't mentioned on there either. > Will the mailing list be moving as well? (Given that it belongs with > the project, not the mothballed puffingroup website.) no idea. alex is playing politics and he's not very good at it. personally, i think everything should be moved to puffin.external.hp.com and parisc-linux.org should just redirect to it, but that wouldn't fit with the aforementioned political games. > > -- > > "It's time for you to change your sig" -- Alex deVries > > Shame, I thought your old sig was funnier. oh, i just thought that was a more appropriate sig for the circumstances, I haven't changed permanently. -- Revolutions do not require corporate support. From matthew@wil.cx Thu, 9 Nov 2000 10:06:27 +0000 Date: Thu, 9 Nov 2000 10:06:27 +0000 From: Matthew Wilcox matthew@wil.cx Subject: [parisc-linux] webshite On Wed, Nov 08, 2000 at 12:31:11PM -0800, Grant Grundler wrote: > Matthew Wilcox wrote: > > also, > > email sent to willy@thepuffingroup.com is no longer being received by me. > > i don't know who gets it, but the sender does not receive a bounce. > > This should probably bounce since it's been stale for about > 11 monthes now... um, it was my email address until about 3 months ago. at least one person still had that as their preferred email address for me. if anyone else does, they should probably change it. it's the lack of bounce which concerns me, which implies that someone's receiving it, reading mail destined for me and not forwarding it on. -- Revolutions do not require corporate support. From dave@hiauly1.hia.nrc.ca Thu, 9 Nov 2000 12:39:57 -0500 (EST) Date: Thu, 9 Nov 2000 12:39:57 -0500 (EST) From: John David Anglin dave@hiauly1.hia.nrc.ca Subject: testcase for hppa64 gcc bug > > So I went down the path of trying to fix things properly by defining > > ELIMINABLE_REGS and so on, but I ended in a maze of twisty little passages > > labelled "Unrecognizable instruction", like this one: > > > > /src/parisc/gcc/gcc/libgcc2.c: In function `__moddi3': > > /src/parisc/gcc/gcc/libgcc2.c:601: Unrecognizable insn: > > (insn 1289 209 1298 (set (reg:SI 50 %fr22) > > (subreg:SI (plus:DI (reg:DI 30 %r30) > > (const_int -272 [0xfffffef0])) 0)) -1 (nil) > > (nil)) > > /src/parisc/gcc/gcc/libgcc2.c:601: Internal compiler error in > > extract_insn, at recog.c:2134 > > I am making progress in trying to make the arg_pointer register eliminable. > I have fixed the above problem. What was happening was that reload_as_needed > was incorrectly trying to eliminate the return from millicode calls which > is also register r29. I have figured out how to hide it from reload with > unspec. > > However, the compiler is now too good at eliminating the arg_pointer. At > -O3, it completely eliminates the arg_pointer. However, as I read the ABI, > the call must always set the arg_pointer before calls. For the record, here is my final patch regarding making the arg_pointer eliminable for TARGET_64BIT. I think the code it generates is correct but it hasn't been extensively tested. However, I don't recommend it for installation since in comparing the assembler code generated with and without elimination for a couple of test cases, I didn't observe any significant improvement in the code with the patch. Possibly, the patch implicitly disables elimination when the arg_pointer is needed. I do find that Alan Modra's ARG_POINTER_INVARIANT patch needs to be installed to get correct code with his test case. There is one part of the patch below which I think needs to be installed. That is (call, call_value): Always USE the arg_pointer for TARGET_64BIT. The use for the arg_pointer needs to be pulled out of the `if (flag_pic)'. Dave -- J. David Anglin dave.anglin@nrc.ca National Research Council of Canada (613) 990-0752 (FAX: 952-6605) 2000-11-07 John David Anglin * pa-linux64.h (ARG_POINTER_INVARIANT): Define even when the arg_pointer is being eliminated. (ELIMINABLE_REGS): Enable elimination of the arg_pointer. (INITIAL_ELIMINATION_OFFSET): Revise offsets for arg_pointer. * pa.md (mulsi3, divsi3, udivsi3, modsi3, umodsi3 and canonicalize_funcptr_for_compare): Put "(reg:SI 26)" inside unspec to prevent elimination. (call, call_value): Always USE the arg_pointer for TARGET_64BIT. Use the new addmovdi3 insn to load the arg_pointer register. (addmovdi3 and mov_from_r29_si): New insn and expand which prevent r29 from being eliminated in call setups and millicode returns. --- pa-linux64.h.orig Tue Oct 31 18:38:24 2000 +++ pa-linux64.h Tue Nov 7 12:17:12 2000 @@ -209,21 +209,18 @@ that grow to lower addresses. What fun. */ #undef ARGS_GROW_DOWNWARD #undef ARG_POINTER_REGNUM -#define ARG_POINTER_INVARIANT 0 #define ARG_POINTER_REGNUM 29 +#define ARG_POINTER_INVARIANT 0 #undef STATIC_CHAIN_REGNUM #define STATIC_CHAIN_REGNUM 31 -#if 1 -#define ARG_POINTER_INVARIANT 0 -#else -/* If defined, this macro specifies a table of register pairs used to eliminate - unneeded registers that point into the stack frame. */ +/* If defined, this macro specifies a table of register pairs used to + eliminate unneeded registers that point into the stack frame. */ #define ELIMINABLE_REGS \ { \ - {ARG_POINTER_REGNUM, STACK_POINTER_REGNUM}, \ {FRAME_POINTER_REGNUM, STACK_POINTER_REGNUM}, \ + {ARG_POINTER_REGNUM, STACK_POINTER_REGNUM}, \ {ARG_POINTER_REGNUM, FRAME_POINTER_REGNUM}, \ } @@ -240,19 +237,18 @@ #define INITIAL_ELIMINATION_OFFSET(FROM, TO, OFFSET) \ do \ { \ - int fsize; \ + int fsize = compute_frame_size (get_frame_size (), 0); \ \ if ((TO) == FRAME_POINTER_REGNUM \ && (FROM) == ARG_POINTER_REGNUM) \ { \ - (OFFSET) = - current_function_pretend_args_size - 16; \ + (OFFSET) = fsize + 48 - current_function_outgoing_args_size; \ break; \ } \ \ if ((TO) != STACK_POINTER_REGNUM) \ abort (); \ \ - fsize = compute_frame_size (get_frame_size (), 0); \ switch (FROM) \ { \ case FRAME_POINTER_REGNUM: \ @@ -260,14 +256,13 @@ break; \ \ case ARG_POINTER_REGNUM: \ - (OFFSET) = - fsize - current_function_pretend_args_size - 16; \ + (OFFSET) = 48 - current_function_outgoing_args_size; \ break; \ \ default: \ abort (); \ } \ } while (0) -#endif #undef SELECT_RTX_SECTION #define SELECT_RTX_SECTION(MODE,RTX) \ --- pa.md.orig Tue Nov 7 13:50:34 2000 +++ pa.md.work Wed Nov 8 14:06:05 2000 @@ -3993,7 +3993,7 @@ (clobber (reg:SI 26)) (clobber (reg:SI 25)) (clobber (reg:SI 31))]) - (set (match_operand:SI 0 "general_operand" "") (reg:SI 29))] + (set (match_operand:SI 0 "general_operand" "") (unspec:SI [(reg:SI 29)] 0))] "" " { @@ -4139,7 +4139,7 @@ (clobber (reg:SI 26)) (clobber (reg:SI 25)) (clobber (reg:SI 31))]) - (set (match_operand:SI 0 "general_operand" "") (reg:SI 29))] + (set (match_operand:SI 0 "general_operand" "") (unspec:SI [(reg:SI 29)] 0))] "" " { @@ -4197,7 +4197,7 @@ (clobber (reg:SI 26)) (clobber (reg:SI 25)) (clobber (reg:SI 31))]) - (set (match_operand:SI 0 "general_operand" "") (reg:SI 29))] + (set (match_operand:SI 0 "general_operand" "") (unspec:SI [(reg:SI 29)] 0))] "" " { @@ -4255,7 +4255,7 @@ (clobber (reg:SI 26)) (clobber (reg:SI 25)) (clobber (reg:SI 31))]) - (set (match_operand:SI 0 "general_operand" "") (reg:SI 29))] + (set (match_operand:SI 0 "general_operand" "") (unspec:SI [(reg:SI 29)] 0))] "" " { @@ -4310,7 +4310,7 @@ (clobber (reg:SI 26)) (clobber (reg:SI 25)) (clobber (reg:SI 31))]) - (set (match_operand:SI 0 "general_operand" "") (reg:SI 29))] + (set (match_operand:SI 0 "general_operand" "") (unspec:SI [(reg:SI 29)] 0))] "" " { @@ -5785,9 +5785,9 @@ op = XEXP (operands[0], 0); if (TARGET_64BIT) - emit_move_insn (arg_pointer_rtx, - gen_rtx_PLUS (word_mode, virtual_outgoing_args_rtx, - GEN_INT (64))); + emit_insn (gen_addmovdi3 (arg_pointer_rtx, + virtual_outgoing_args_rtx, + GEN_INT (64))); /* Use two different patterns for calls to explicitly named functions and calls through function pointers. This is necessary as these two @@ -5809,13 +5809,14 @@ call_insn = emit_call_insn (gen_call_internal_reg (operands[1])); } + if (TARGET_64BIT) + use_reg (&CALL_INSN_FUNCTION_USAGE (call_insn), arg_pointer_rtx); + if (flag_pic) { use_reg (&CALL_INSN_FUNCTION_USAGE (call_insn), pic_offset_table_rtx); use_reg (&CALL_INSN_FUNCTION_USAGE (call_insn), gen_rtx_REG (word_mode, PIC_OFFSET_TABLE_REGNUM_SAVED)); - if (TARGET_64BIT) - use_reg (&CALL_INSN_FUNCTION_USAGE (call_insn), arg_pointer_rtx); /* After each call we must restore the PIC register, even if it doesn't appear to be used. @@ -5961,9 +5962,9 @@ op = XEXP (operands[1], 0); if (TARGET_64BIT) - emit_move_insn (arg_pointer_rtx, - gen_rtx_PLUS (word_mode, virtual_outgoing_args_rtx, - GEN_INT (64))); + emit_insn (gen_addmovdi3 (arg_pointer_rtx, + virtual_outgoing_args_rtx, + GEN_INT (64))); /* Use two different patterns for calls to explicitly named functions and calls through function pointers. This is necessary as these two @@ -5989,6 +5990,10 @@ call_insn = emit_call_insn (gen_call_value_internal_reg (operands[0], operands[2])); } + + if (TARGET_64BIT) + use_reg (&CALL_INSN_FUNCTION_USAGE (call_insn), arg_pointer_rtx); + if (flag_pic) { use_reg (&CALL_INSN_FUNCTION_USAGE (call_insn), pic_offset_table_rtx); @@ -7124,7 +7129,7 @@ (clobber (reg:SI 22)) (clobber (reg:SI 31))]) (set (match_operand:SI 0 "register_operand" "") - (reg:SI 29))] + (unspec:SI [(reg:SI 29)] 0))] "! TARGET_PORTABLE_RUNTIME && !TARGET_64BIT && !TARGET_ELF32" " { @@ -7236,3 +7241,48 @@ emit_insn (gen_blockage ()); DONE; }") + +;; For TARGET_64BIT, the arg_pointer register is also used for millicode +;; returns. The ABI requires that the arg_pointer be set for all calls. +;; When the arg_pointer is made an eliminable register, eliminate_regs +;; will eliminate the arg_pointer register from the function call setup and +;; millicode returns unless the arg_pointer is hidden in a use, clobber or +;; unspec. + +;; This is for loading the arg_pointer in function calls. +(define_insn "addmovdi3" + [(set (unspec:DI [(match_operand:DI 0 "register_operand" "=r,r")] 0) + (plus:DI (match_operand:DI 1 "register_operand" "r,r") + (match_operand 2 "const_int_operand" "J,i"))) + (set (match_dup 0) (match_dup 0))] + "TARGET_64BIT" + "@ + ldo %2(%1),%0 + ldil L'%G2,%0\;add,l %0,%1,%0" + [(set_attr "type" "binary,binary") + (set_attr "pa_combine_type" "addmove,none") + (set_attr "length" "4,8")]) + +;; This is for millicode return. +(define_expand "mov_from_r29_si" + [(set (match_operand:SI 0 "" "") + (unspec:SI [(reg:SI 29)] 0))] + "" + " +{ + if (!TARGET_64BIT) + { + rtx tmp = gen_rtx_REG (SImode, 29); + emit_insn (gen_movsi (operands[0], tmp)); + DONE; + } +}") + +(define_insn "" + [(set (match_operand:SI 0 "register_operand" "=r") + (unspec:SI [(reg:SI 29)] 0))] + "" + "copy %%r29,%0" + [(set_attr "type" "multi") + (set_attr "length" "4")]) + From bame@noam.fc.hp.com Thu, 09 Nov 2000 11:47:51 -0700 Date: Thu, 09 Nov 2000 11:47:51 -0700 From: Paul Bame bame@noam.fc.hp.com Subject: [parisc-linux] kernel merge We're getting ready to do a kernel merge (to -test10 I think). Anybody concerns before we get started? -P From jvinet@linuxcare.com Thu, 09 Nov 2000 14:08:20 -0500 Date: Thu, 09 Nov 2000 14:08:20 -0500 From: Jane Vinet jvinet@linuxcare.com Subject: [parisc-linux] Website Plan Recently there have been concerns about what is happening with the web site. I'd like to let everyone know what the plan is in order to address these concerns. The Development team at HP provided us with a list of where current pages are hosted and where they should be hosted in the future. Item current future ---- ------- ------ mailing lists pehc LXC parisc website puffin LXC hardware database puffin pehc ftp server pehc pehc cvs pehc pehc As per Linuxcare's agreement with Hewlett Packard, Linuxcare (formerly the Puffing Group) is responsible for all of the pages that are currently hosted at http://www.thepuffingroup.com/parisc/. Linuxcare is in the process of redesigning the existing web pages and we will be moving very soon to http://www.parisc-linux.org/. By revamping the existing web pages, we want to make things like the FAQ page and the To-Do list much more visible to the public to encourage new contributors to join us, as well as meeting the needs of current Developers. The plan is to transition from the current website to the new website with as little disruption to the public as possible. Currently, http://www.parisc-linux.org/ is set up but not active. http://www.thepuffingroup.com/parisc/ will remain the active site until everything is ready to switch over. Each of the above items is being addressed independently and have separate schedules for transition. We will make sure that notification is made on http://www.thepuffingroup.com/parisc/ and on the mailing list prior to the transition. Thanks for your patience and we apologize for any inconvenience this may have caused. Jane -- Jane Vinet, Director Professional Services/Canadian Operations Linuxcare, Inc. 613.562.9260 (tel), 613.562.9700 fax jvinet@linuxcare.com, http://www.linuxcare.com/ Linuxcare, Support for the Revolution From dave@hiauly1.hia.nrc.ca Thu, 9 Nov 2000 14:54:00 -0500 (EST) Date: Thu, 9 Nov 2000 14:54:00 -0500 (EST) From: John David Anglin dave@hiauly1.hia.nrc.ca Subject: [parisc-linux] abort in eliminate_regs compiling glob.c from glibc The following abort occurs with a relatively current version of gcc from the cvs under hpux and the parisc-linux version of the compiler: hppa-linux-gcc ../sysdeps/generic/glob.c -c -O3 -Wall -Winline -Wstrict-prototypes -Wwrite-strings -I../include -I. -I/home/dave/puffin/glibc/objdir/posix -I.. -I../libio -I/home/dave/puffin/glibc/objdir -I../sysdeps/hppa/elf -I../linuxthreads/sysdeps/unix/sysv/linux/hppa -I../linuxthreads/sysdeps/unix/sysv/linux -I../linuxthreads/sysdeps/pthread -I../linuxthreads/sysdeps/unix/sysv -I../linuxthreads/sysdeps/unix -I../linuxthreads/sysdeps/hppa -I../sysdeps/unix/sysv/linux/hppa -I../sysdeps/unix/sysv/linux -I../sysdeps/gnu -I../sysdeps/unix/common -I../sysdeps/unix/mman -I../sysdeps/unix/inet -I../sysdeps/unix/sysv -I../sysdeps/unix -I../sysdeps/posix -I../sysdeps/hppa/hppa1.1 -I../sysdeps/wordsize-32 -I../sysdeps/ieee754/flt-32 -I../sysdeps/ieee754/dbl-64 -I../sysdeps/ieee754/ldbl-128 -I../sysdeps/hppa/fpu -I../sysdeps/hppa -I../sysdeps/ieee754 -I../sysdeps/generic/elf -I../sysdeps/generic -nostdinc -isystem /usr/local/puffin/lib/gcc-lib/hppa-linux/2.96/include -isystem ! /home/dave/puffin/linux/include -D_LIBC_REENTRANT -include ../include/libc-symbols.h -o /home/dave/puffin/glibc/objdir/posix/glob.o ../sysdeps/generic/glob.c: In function `glob_in_dir': ../sysdeps/generic/glob.c:1446: Internal compiler error in , at reload1.c:2516 Please submit a full bug report. See for instructions. make[2]: *** [/home/dave/puffin/glibc/objdir/posix/glob.o] Error 1 make[2]: Leaving directory `/home/dave/puffin/glibc/posix' make[1]: *** [posix/subdir_lib] Error 2 make[1]: Leaving directory `/home/dave/puffin/glibc' make: *** [all] Error 2 The insn that causes the fault is the following: Breakpoint 2, eliminate_regs_in_insn (insn=0x406a0ba0, replace=0) at ../../gcc/reload1.c:2826 2826 if (! insn_is_asm && icode < 0) (gdb) p debug_rtx (insn) (insn/s 2711 2709 2719 (set (reg:SI 6 %r6) (reg:SI 28 %r28)) 69 {pre_ldw-4} (insn_list 2708 (insn_list:REG_DEP_ANTI 2696 (insn_list:REG_DEP_ANTI 2702 (insn_list:REG_DEP_ANTI 2697 (nil))))) (expr_list:REG_DEAD (reg:SI 28 %r28) (insn_list:REG_RETVAL 2708 (expr_list:REG_EQUAL (expr_list (use (mem:BLK (scratch) 0)) (expr_list (symbol_ref/v:SI ("@strlen")) (expr_list (reg/v:SI 4 %r4) (nil)))) (nil))))) As can be seen, there is a use in the REG notes which will cause eliminate_regs to abort if it is called to process the notes of this insn. It is called from this code which is near the end of eliminate_regs_in_insn: for (ep = reg_eliminate; ep < ®_eliminate[NUM_ELIMINABLE_REGS]; ep++) { if (ep->previous_offset != ep->offset && ep->ref_outside_mem) ep->can_eliminate = 0; ep->ref_outside_mem = 0; if (ep->previous_offset != ep->offset) val = 1; } done: /* If we changed something, perform elimination in REG_NOTES. This is needed even when REPLACE is zero because a REG_DEAD note might refer to a register that we eliminate and could cause a different number of spill registers to be needed in the final reload pass than in the pre-passes. */ if (val && REG_NOTES (insn) != 0) REG_NOTES (insn) = eliminate_regs (REG_NOTES (insn), 0, REG_NOTES (insn)); ep->previous_offset is not equal ep->offset here and thus val is 1. The use would appear to arise from the rtl generated by expand_builtin_strlen. Anybody got any thoughts on how to fix this. Dave -- J. David Anglin dave.anglin@nrc.ca National Research Council of Canada (613) 990-0752 (FAX: 952-6605) From grundler@cup.hp.com Thu, 9 Nov 2000 12:12:25 -0800 (PST) Date: Thu, 9 Nov 2000 12:12:25 -0800 (PST) From: Grant Grundler grundler@cup.hp.com Subject: [parisc-linux] tulip DMA mapping Hi all, I see a "bug" in tulip's usage of mapping services. It's not the bug I was looking for unfortunately. In line 217 of drivers/net/tulip/interrupt.c: if (tp->tx_buffers[entry].mapping) pci_unmap_single(tp->pdev, tp->tx_buffers[entry].mapping, sizeof(tp->setup_frame), PCI_DMA_TODEVICE); 0 is a valid pci_map_single() return value when the system has an IO MMU. The system will panic before pci_map_single() will fail. The driver needs to remember some other way if a buffer was mapped or not. Or the Documentation/DMA-mapping.txt should be changed - ie add this to the interface definition and I can reserve the 1st mapping entry so no-one uses it. Should I be mailing Jeff Garzik directly? Or can someone who knows Jeff point this out to him? thanks, grant From rhirst@linuxcare.com Thu, 9 Nov 2000 23:00:50 +0000 Date: Thu, 9 Nov 2000 23:00:50 +0000 From: Richard Hirst rhirst@linuxcare.com Subject: [parisc-linux] strace working I have updated the strace source in our cvs, such that it now builds a basically working binary. It requires an up-to-date kernel. Outstanding issues: a) ioctl defines in linux/hppa/ioctlent.h are probably wrong b) there is a hack in defs.h to get round a problem where the libc wrapper for ptrace() isn't getting used c) there is a struct user defined in defs.h that should probably be in the kernel source asm/user.h d) there are probably more places where we need to add HPPA specific code Richard From dave@hiauly1.hia.nrc.ca Thu, 9 Nov 2000 18:57:13 -0500 (EST) Date: Thu, 9 Nov 2000 18:57:13 -0500 (EST) From: John David Anglin dave@hiauly1.hia.nrc.ca Subject: abort in eliminate_regs compiling glob.c from glibc > Breakpoint 2, eliminate_regs_in_insn (insn=0x406a0ba0, replace=0) > at ../../gcc/reload1.c:2826 > 2826 if (! insn_is_asm && icode < 0) > (gdb) p debug_rtx (insn) > (insn/s 2711 2709 2719 (set (reg:SI 6 %r6) > (reg:SI 28 %r28)) 69 {pre_ldw-4} (insn_list 2708 (insn_list:REG_DEP_ANTI 2696 (insn_list:REG_DEP_ANTI 2702 (insn_list:REG_DEP_ANTI 2697 (nil))))) > (expr_list:REG_DEAD (reg:SI 28 %r28) > (insn_list:REG_RETVAL 2708 (expr_list:REG_EQUAL (expr_list (use (mem:BLK (scratch) 0)) > (expr_list (symbol_ref/v:SI ("@strlen")) > (expr_list (reg/v:SI 4 %r4) > (nil)))) > (nil))))) The `use' arises from the `__pure__' attribute in the prototype for strlen: extern size_t strlen (__const char *__s) __attribute__ ((__pure__)); Still haven't been able to figure out why the REG notes are processed or a simple test case. The cpp'd input is attached. Dave -- J. David Anglin dave.anglin@nrc.ca National Research Council of Canada (613) 990-0752 (FAX: 952-6605) begin 644 glob.i.gz M'XL("('T"CH``V=L;V(N:0#M??MWV[:2\._Z*]CFG%[+<1I+\BO5MO>XB9/X MJV-G;:>]W6P.#RU1-F\D4B4I.]DV^[=_>#\'("DQS6/%O9M:P&`P&`"#P6`P MN!?T@F^___YA\;X8Q_/BX76G@]S:Z^'WW;N#^[RJ;%]S??!CT$T?>"=!#$SKX?@GZDKHP=+$^6HLN_F$![R?2SU M'&,1D#I(@O?ZGLY!^=OPM.@+#/H\7*3)._SC%DWE=/'NX552%L9DVJY?0*G# M%L847DH._$O6%`QJ%XV*F57P,_O0DM*8!7W<$L1O$T&T5EDJ7!QFV6C+M!&$9EF2=7BS(.PV!C(PS1 M(EN48=CM#AU\&>S[!RA`UN@FRH/->9Y=Y]$L3-);1D681K-X"\PI;K*\)/D& M'>7[>8PF(&]JEH?ED!$VJ%Z@K,F,T1GB;IX5E/%Z)EN3[%S)FAHS$T)9JX!: MR<-%D3_$73F5H^OJX?5H]`#_]V8^CQY0#/WO'^W)YI9CQ#@^Y:BD6143P?.H M'3Q8EUH=3_.)WMO>:;EBK,[NMXD3:YIM$]GDXY-ND1;)=1J/R>PKDO^)V>2S MF=KOMS(J3*Q[K;+U;_G$DEY/+F`Q:K&;"-`P7(3XCZ&=3Z0E`2!_`1"XPW`^ M^B^0.\W2:Y*-_T`]BI8+)+E1+I+$80"#DW\XVC\6T1B/!;B@"<^AZ9RO+P$Y M/ITK".=!"+6*<\T$T)A&*4+_]O9`)"K4P@+3N(O^'?1!)+(X!7#PR<%>]._> MCIN[[FX1!05%G/=8(_@C&H]S(Y?W)/IS'-^J;6&#AZ`=PQG7=@8;6`E2/<`B MLVP3%!+L`1YW=M&.OG#8.,@V"2K5C8)-@18M_N&(68= M,@Z+&"#V;?Q>;P,H(I+YB`^W#L@GQ$)UX80A1FGI&.`TD\UJ:.A."JB\,GPY M@!?'))GZ<5``"(<`0I/>SJ<3E,YA,U<=R&&!UOS!K>0@&:/H7_G9>[H M-#:DT=B:03.S%/U"1(?GH9!R7T>@&5QTK-6,VS+-I,B(\@-@FH/`/63));]".N"19 M*KYL3M!3L837\464C_$O!0@1\I8L/$0V!@$V'^#52&1H&$@JQ?`AX$W&E@9# M+BHM=G4$7D%"RNG`X"K)NHN2,L%*JZP(KV'NBAAK%[/9>[.0I!`4%QQ4K`2^ M"F9A'A=Q?JNR>H9J6:0EV))9F-VE<:X"OTW2\=#/FAECC6S';%'&[ZI:3X`H M>J,DT$EJT[-T9"U=)GGY'54%JKHUOQ/]2JE""1@FS@N00RC[#@U?RB,HE_P6 MX\Ⴁ-NBX1Y@32N6&,1;YJ?NQA&Q^9$I;!;X+O-IE&93&.-\5S>Z,.3 M<;>"T5>1P6B4D,=_+))<'9PH<8Z'K&-\HFQ@JEU%>9[$N9,J9_-90;7]GH6> MERJ)P._MU3"4:E(>F]U=MCUUP\VWV(&YTQ9;Z\#:8G/EW]A;"W6*;ZHM98[O M@@'E26ZH92;=*`3V?D$H57SSH^61K5?`-F`ZGX6*%BBJFII-MH`!VPCJ662O M%UP+35?)HGNZ@&_M]$RVK0O$]D[/)GO+8"'1*GFTD;*-9B9IB:)6JME$)0_F M$+DD!\I@&\2@@/1UL4$+K(V:V*(%8JNF%23+1Z`N(JKNQ^U5>&_$G0%X'DY3 M,H0!64U752JDO>UZ`32ZV`XN4'9R-A#=809\H^E&1-BJ[?TRZ24=##!RV^+1E;Q_*$N9QMSA6!8(P M202J=4*?J`I084"M3TS6)R8?G3O8&6+W8U:V/D]1J>[M>)4YCQZYT%4QP(*W M\!V@+(B&5^M3-T_T_"&PS]J)BA1B6^1_'N,C]^[0+(=/&[P%GSL*XG,&;\$+ M1T&B1?D*/N$%';OD1;A,>VT4S9MNXVC.!1M'`X:HK,SCZZ0HB7;C*WR7Y6/! M3V6(ZSX6Z3B)4MU+`6VRT%[,S'H$YE&<@[XSTS8]XFG//$Z4&CCLX`"F`?:S M-)VH5'BL='EU`:FHN%IR.7)O=IN<(-59JV!P>CCHDP("! MBPJMC7ZK:7)=Q+)9-/O'/!&#)(3FG.#?)<6!PG:YEHU@7R]%?G[OZ.:QE1 MW"QI8K#!/!@FXV)+8MX,\8D`6C'):0TV9^)\,G*-SU&$F*X;EHG?C>)YZ2JD M\\HHBE.S12D5$Z6A\Y9:NE13EVMK0!Q;`T.BP&WV(9`+F5$6)1-W`GZ2K%]A ML$>KPDYL(:]DJ(>+.DL$\[34"NYX^.-E"LP6A1=:,]L:-LN-FR4'3MUI(@5^ MA2KK6OW)&'E?S*)1GDD?8;^B9Y8!E@9]E>BYW)B9")4247BJ!(;/B@%$'$4" MZ76BBU7ACA*HGBD&#'S#)4:G0@%1*E))JX)))265TE5BDZ7960= M3@(\F:["E!I/J*T#L<_`U;!AGMI`)JY8F['RRQ# M9\PFG3+&%$^P`H-/2]V+%JG,U2S7("&]AC6Q'`D/4A,;BH.M0-+/(8>=#TZB M'"M`-57UR)HN2U?5V@M7-U&KHP*[3F6-A*2?*X8$U?N(U=-3F4$%[W=\^'SH M5(P@:/6LT5OP#'&,(US'KJDC==GKXZ:I)O5(E*H7%%/M!NKJC(NCD9 MG'=4,0'U3%W>UU)-=4&[6HT--2F=VAJ*E*D6H0V+2XO2<#?4CXRR[GGO.+WQ M*DQ#Q]!S]38ELA7Y[JK8)]];$N&NJC^*"'=5UJ((;TV(RT]X0KC-[1W;,!X5 M19Q+FQ_)HVE&%C..FWG0)OI>L-NO`&8L)K?DPI`"A),HF=KLI9E)EL(JFY?1 MADT&]R:`99&.,/YN)[`]T=*,]@J/^`,2/J>!=BC]M"H<]FFM6:?G,P^8Y(CL2V<'SW"WCI?*<9*IGGK*A)@F5W@3)"'$ MD-=S.D;1M>?\VG-^[3G_E7C.#W8@6=!GN:O,]BB_5F9["YATWB@G_XMD6B9I M>!LA(4P<3Z[3Q8C_M$7NO6!_%=D#4N/[E"N2"EV!DSZ]?QZY^T='SZ_['I^% M3X]/C@+\S[`:+`P-0'UY(/^*Y6$?R%'+B)4I73P,GX7.`,;K=62]CJS7D?4UZ[\X>*"7Z@"ZCWNC2Q$;>M;J/I@D1?"D-$`8X@Y17; MTKO2%(=X6NR[`ES8=S9]:Y^QO0XZ+N`[P6[VZZ! ML>OMC=V!NZ/Q4R3N%N\Y:]QSX,0/"KB&XIYC**H=!^L71#P8[RW(XO@MADH= M!IC>W*$R#.<9#70E9R@SU-.)^RR<(`@MVJR!A5U-KH5'NK6S^:XUZQI1?:M; MR1.81 MI`;TUROO>N5=K[Q?U\H[`#5^MO#&Z6+&MAS/'I^=_AJ>_1+\&&QO*2FG9_@_ M>LJ3G_7?+XY>;'64E*,7+R]_#X]/7[ZZ5`&?OCHY"<]>71K)QRGAQ='O$\H-23HXO'Y\G*/OH_/SLG(7QMEI[?!&> M'%Y[FD8GIV>G1_1\A<?O6=-T)S?3QZX>5QOR5IE(E+&;NO>;>R+1\G(ZT>*X0J?,0O*5 M"%%C.J$4\??0`E!Z7P`J:78!1I(`9K_5QPNH`+4FHZ04`Z6HAJ%;IFM1[B'A M3=QT;]#*']Y$Z7@:4TIUU\)9-F9/'6KF?QSJ'H">Y-F,/8UH9Y99*%`I*P'Q M(->XQ+N<^`$G%A,E^P3C.I*\69(BQL2XE9@:Y=6"Z)TC0Y8H,Q"^S(9*#<1^ M.5E,24/T#G/V!1]=UGP,PVR!W9^'[JP8Q^M7ZI],H^M"2U%>IY2]HV9CW])H MBD,6,^Y+>RQSU<8J@,-02S!Y!R+Y-70\-R(Z=9+1$OL--BY+,3"TW5D535+$%O$8RZ7#`3[P`J85;AP>[\JC&.)< MS`?J66VE#/A`9M+L*DGI0P6(N$2T3`N>^&RYZ*2R[(I121&2Q5(40%CJT[+$ MAL)P*FO]BKM\\-EV4JOU*>YQ_U[,YJBO38\YP*>.>H^C?"U.OE)N%N5OXUQ[ ME4.F;K(%);!\\S;#@HBHCI`IY&`'[X6WP48228`W+&3HCN/1;8FO.)GI98(CAAF7ITLID?+*SHCI&U-VQE54Q%8.??K*DP75 M0W.@BM!:!2/#&52;-C**Z-91_U4T>KN8LSRP&%//#>49Y_+7\<_Q/[0JZ?-.J`VO>V]HC9:2@,@B779;1E=X/V=U*%G.A2N7W$ETJ/#: M#,RN-5(9NXU4SCF9K/>HF6[AUOI2)JL=J:?R7F0[);,+9;+6?Q8\1P,I0_2/ MPLQG"A%"A.>1X"0.82$WCR*DE.)4DTW'^$\>P]>*;Q:.%CGJ]^EB1N:G]E(T M[4]1G+O6&0,"UR:4/T0C>P62?9IGCB0$''^;<@!J^4(>\($F#+V\Y334EZ"0 MA;-ZW=M5@K%CRVGP`&W)9!*SS;SA0]9Y2T11?HV\<#[%SV#RFY10+OG5#WLA MOL"2AL.ZL$@VU@=&VFIH1`Z2PX:(A3$>.:X\(H==F0BWZ%#[.3"TT\_HA)RD MG*5XP)O&6,"J@\;*E;,*OWI=QT:W"2B..OE`WB0^9OSNZYUE321X1M.L@(CO6@^N2?91"/:37>750[2J7&'0[+<+ MG+>'0=.?+F!!-(-FOQ5PAP^?THA-_,>0IPIJ-\E?(IV3M8G_$*FB_DWR%S$\ M$`E!J$$`G!3-#]`)$C@*ZGLW`H)EJ77A6\&;)J6A[HABI&_5V]#TX4WQ`"ELW5%E0I@ M'2"X:IKOL;2HY*-RUW$Y4C$@ELV-1J*\^0)#,:/R5E`%/J&/HU="86,!`&?5 MC@8[?;XW'D/@2K/$")Q@<#+.0#9*N$7JAQ34EOE[!V0%BV\GQ2A*-88$,F2> MOH]0,YRS0+\52N>/$H3/IOUV,L_1WT:?P!34(<"@0`VW(I8BW&_1.+4FQI8$ MDN640@4:D48I?DHG2LGJA):$2Z)A@G[K906(=A3L+(]6*%]YI6XY@O(XYKIK MA(28-3B,F4LGW9UGUBF0:.)A2+&O"._J3#^L[YGHN9A5PQ.J'_9B&\!F4< MW=49T&+[56M,+S.H[^J,:KD+K$-%S9%]9P]MVFG@Z-:'RIUOK-">V%=-M?H- M;K%Z<\?^@/OW`[DT)+WEM^_XY,M"1C`/ZJMWD\WBAV.T%>/^2-<(;/0PN_KW M.,EYI&M4`C%N)BX!/&I>T$,=%&J$LH5QFG)25]M%FJJNBT1%35?&5Q[/T/(* M!]G"!Z/&(I631!L<[2-MK3N-[_1`,I26IY6Q<]UQ M,CT%L7@NE*:R"O-XQ2JK*W65,P5KH/(.>Z-#X2:@P4NX5B/F\"J-Z`Y!QJU8 MZ_+,JV"?Q:(Q[68U/I_EY"%M`#9[Z3Y([IY5.J/K9,0W3=X5<-FF!MZM&$LH M5*'%*)\A<4O:SC*>9_J? M&!6%-AU%C,U[4KY8_;T%<12*=HXPW2Z'"FZ2U/M4MJ8Z]Y0VH'U9:W4'BOT( M_V&%AT-5XC!H6GN=HIGK>V[BFHK;29;/(J2U??_]]\;Z(G3+90H7O#10ROD> M6=UZU(INO3RQYXV-%>XV(_`06K[S:Z.-MPTX!*+K&/C\3&N]*7J'I?[*Q2"> M1>^P0')55:L/(76(YE-O&4I*&&X%@ZU@A_K-:%:GVW;(K4O5::N`00K1Q8RRTM=FZ6O4]1_7+]LQ'D_<0P_0Q3X]) M+`55`7%`=$P83+IAXS$@?,8*&YD"K6`U:6]B`#$.>WPT5(%V3>@8/,H#4 MKE#KPVUAKU7.IL@N!BSXV&9?U;_86L]QW/E)ID,8]TWA4H(HGG3+8T+H#&&4 M2HO\N/U[X)JV"UJ%WA3EV!4PH>,3D'$\31P;=+PC]&DE_`/WZ"EO':D@0557 MXO&UTR*^#=+;(=S?/1#AF+H5Z':0[2U3`GTEH9E,JXYGY".50A$X+BWWV@^88.=#W&#/9 M(:K1<5EA6J>P#Z:&2U).^U\BPJ5K^=]09N"S"9`=+#`;Q!#+?X%RQ$:EZSN, M(2J8@R7<8\]FBLT3N`&2*XKWG]9%9#2-IG&4QWE>==I'/(HJ0*@[D6=0:#76 M5+-QS;5!R0LG]51M0LNA\O0S]A<$0%-[\O'YCJ*=A M31RAA<08M\2#NL9.@L!5\<,XP)G#!YVC;#:+4N^!F+H,.T^0+;5UA/Z>)6-` M<]7!%D6<0V`%]6[,\+4!ZL.MT,%20VZKT8&-"<92O6M$;>,$0,1M:U0L:\V0 MQ>U-NNVG26:(XL=7)>TU!SWW1HVB5=W^_"N9_KB!=%=1?5S@;%#P\P>S,,V= M6F'E8M4$IQ4NP? M_YW^8TO=;'D&EU\[](PI_JT2K&L54]?KX>O;;O; MSN4+Y>[M^A:W>\'>CMLGD^)W/"YG/<-J^]UIV6V=>-<^HJ?`#8_I]5-Z[XG0 MTD?:S0Z.JYMA'WX8O@9U3XL:'7TVH*MGT&78D>N(@@JSBV]3ASFP]('5Y]&? MBAZ[CKBZCKBZCKCZM41NK9H`PX\CAVAMS40S(*?#)(/\]X+=KT@QF#X2H7["M/C"Y#. MZJ?>A4<*S#C!1QV5E[;6,O?O_/"&I_GS\8L4:7!CXQV;>58D[[0L\32.D=4& MV;W]71"U-&XB)IMA58L@=V MA-:%X$-M<7J;Y%DZB].R,*S`=>`[4`5W63[&B_ ^]!L<2'!7XX.6+2+7( M[TM5HA;Y:.UJ`&TP_6#;S72@C[[.16V]8UGO6/Y/KI[][0;3'_R4P#MIB=0D MM'GA?PPMD`+IX%.\G0C$7[I"I=Y#&(W0]L#>-)![H7S;@C#;Q]SQ(ADW+*TS MA;U>9"W[AM?+E#KYJ/[^BM-,$9>VWXS54NDQ0K!AUPT#G_0Z<6!46LY.V3D& MW76+;2VIUYJLA/M).6-;&>69[YE]R\&!""1BWH0*F[&*WXO`V)0NCT7:J&Q( M'\H"9XK=HUH3]?[T-M)S).[!9LR_!,!*/$PJ!!962T*+10$^JDOLGN``<< M&JH+84W&M)OND-)''!-8PG6>+>:`$R[#IPZ3"AR6A)VV09/>QG$"N%UA0YGM M5\*`%2F']#?'5LWTB!_=*2Y#^GP0UZ%E=:(8#C"9(PT:F]A":@C3KHR8\$8M M-@?'B[DAI_7,OMI!_*^^"B@.6)B"/S1S9+JY/KZ+1U`P%9N\1MDD1RTNE/:((2B;M<$:21C'U,D(,Q4A@6^:$32M M8+F=N^:4KT46+4XL?F)4/&DR$OV%]%3`53*,W^%@@DRZEE&Y*+HU;+B=BKT\ M?CL"3S##FE$%RP8Y?N>+/QX1OGP4",)J%?X>/#T[-3(TT^ M-$;33@]?'!E%7QY>/C>3CE\>A3^_>JHD/7Y^]MMI>'YT<7E^_/CRZ(F*\RR\ M/']U^EA)^O7)\<7ASR='2M+%[Z>/P^,S)>703GIY?GRFIUR!6')\\,=-.?@DO'_^BI)P^.S][]?+" M@#M[>71J)"%F'!V^,!(O_\MD,DK\?V<_AX_/3B_/ST[4\H>_'CT)CY]<*&D( MX\GE,4)P_S\[/3LU<7 M"E,E(L3`)WH&+V'G/,59RN\7AR]?(AC2$6KRT8N3,XV9+"4\/SQ]=J2GGYW_ MCD@YNSQZ?'DL1R[)N[@X?':$AN;%A=[(BR-4\?.S'YX@6AO'LY_^' M$&J,0(/JY/@"56+TRB&80@;ADZ.3RT,C$Z4=_D[8;&2\^$]H=*!4@DI/_15U MDM[:EZBI>#"C)#D*+E'WFZ/MZ$5XBOXQ!R9.__7PY)4YYA"&_WQU9"6K#5!J M_!G][_#"!$:I3X[-$8X2+QX?G@"P6#J<6I/N[.0D_.WH^-GS2Y/TH_]\=?PK MFH&HG\VFG-],-SBE>9C2*W#W1#/T1-.#Y] M8B0].?I52WEZ=GX))R(9J"5>_&;!H9F`^/;DZ*E*S,OCXRWM5_BO2S,%B\&C M2R.1O@II)9]=:*41][7!62WY%\OG_7M9KQ\-H`2=]3RI.J?M6XF2;9X-08K MD@@&$$G18$[.T.J@(__M[/R)D?3BY_#$6DU/_^OH7%-5@+E[`5!Z`9!Z\?S< MI)4F:5"O`&RO[%:^(HTRTI0:9`M.L$9JM.HD/$&*D97XXL)..[52+HXNK30T MXB_-P?WSQ6YX?/)RT`_/GCX=:`-#R_KY^)F9=_)R;P=G[>W8.0A8H4VV+RR-5 MVKQ`VX9+M!%@_%!S7J&.>HG*,!&M:9RGS\`,I"B@>6Y4C%F'--'?SO&"20C3 M<+U$R["9>'[T#"F&9@(@%B^>'^EJC[69NGAY^)M6`@V$PR?'6$,Z1_B`!=H) M0)D7/CF\/#3&GY&C=2P>,6>O-&WH\O>7OGW,*U1S2/>F<*J&_^7/%_JO\/#Q MX[-7IY=Z+^`,K)9>'AF);!-FI%Z>'VJCX>)WM+T[>XD3/@PA>\7C"V)A$'N- M+9%\\A0M^T]/#I_A]\A[V]O;'"W+.WE",LW4XY_MI--+`!0)KL=P,H@9IUNX M22+##C3!E*Q*>WI:>RQ`FP0;1*<&R+>;;=LQ2;JJ(0`G8UHJM M@2XK+`NOPR*%VW$69'G3ZNXL4[POU!("SHA/@6&*,E?!7.\)36,C!BP^5!O3 M0#'S9&R'&%?S=0`0Y#J?6]',33AR@V-^G9!`&CQI3HM`*$%`TYA<@)!;2J4X MFYZS[NX>.,]93910>QSM0O"%SB&[-86C,?*HD$,NX-X0^;$#X)H#7%?DQ]=P M=[+`5^08K1#&=QS(1#EDHV$"K`,&4@B'8KZ*R5&;.)-S=MJ",H2?YBT@:A!8 M'AN`^2+1CA5C5TFSX,))"AL^-LTF*09@?DU)X;]C5TFS(,`5/C0F6?X6/O_C M$+I1VR0?/69";H:28\0 M/.*L58A-$(;2(06GV->)O1ATHZ1S!\GT5/1_\C2]6C/TX9>#VX$]JYTM]WH0)3#AP5J MS8@/>]HC]#SWUGP]BCQTB0IRMQ-\B;COX:?ZH7YQ]";V4=[O>QRV`>IOLJ+4 M+Q&Q\2>\`N$96:A%88<^[XQFY;%\5P)P6:*943G.9E&2@G3JE>@UJ,66H'%2 MO$]'EK!6(6YOHO1Z,;?5!BHI;[.WCO=Q8,^M/$-YBI<4?4@59^$Q$\WFTSBD M;P_4"9DF(+B;HNE]-8JFIG,-<_(L?3)%@%$P M,>=##9Y@8QF%01, M>$Z34*-EQ*\D'L"7,\"M*`G4H(@WE)9FJG,/0O=HQ^/"JFI^^*JDO14>S4P> M.QA,RNO,-3%(/D.;-Z._\$O)FGQ,IN/8CD_%%L/\_1P0$V_C][;264334I,= M3#(P'$+?Q@WB;8C'.(2'J?E3B7$777D#4%+5%\@H,TBL%J87M=W8$@Z6AI01 M^#:5M@;0VV%(!LCM2K!!1%<\C_*XR\:W-UJ#+!1A!\EF948WJ"=Y$3%.!X[+ M>E:(D@9._EJYAA<$+%=]-&Z7_VM;*?6!E6W=[.B28>V6&G]7FWU#D6S MKFVYZJ;UUYP_SO)+W`K21++S)@ETPP,M&#G_"\3U*LS1!:B[& MATK%HS++WU.358*OXJ10A)'R)BGP]JIRJNB?VH*&1:WK)%J#S6L?9J;SVH>N MO[1U@<-SA]VB@KK,>$ZCN28]9#CQ;,8'J'1':)-4[\;'Z M7#^CT=`N<_BB(0#.7G3)WO1@1&_U$BS[;*+Z^(R:GAGAE-;8BZ!E'3 M9J=9R%!O>&QD'=,D0)31.,7]A-7!11Z3HYF]@^HH0^L.$%W8YDJ M0P2)5,6&M8Z7LHZ7LHZ7\C7%2QGLF#+`CI3"7G/`IT)W8Q()FJYV\SNRW`W5 M!`J$D[@.A1+1'S3EFJ=YI1[)B%;#/Y>1(.S"$Y@6J?63?"_;A<)+V;DDN<-K`Q^;9M#3V3311 MRQ.[)S//J7\QSS4+W@PI`L8YU:LVXG?Z2ZB*'4TDUW;HA88P23/$]C'^[Y`E MT4WM&/^7"@><#!@PT-3#,6C2H0Y`>G9,#J!I#DO`0_QU?W?OS9#?(M*(VMN1 MMXDP->3LQZ2+)1+*/A95O+O@[N4A70\07E+`G$\Z/GJ&$`YEPEHS9>!#UD?D0#M=,8'B!15%\64;>*']L#C&-@?#MN2 M"#@I3)#/R?3M[>PZ^*KKL30CV,0F)P"1N1H:(TV4PX>64$G-/9%`AK(.9?7% MA9R/T^J4:N502OZ^9L&*]=Y!+YHIC2D.;#[5IQHH[*%9#.T_$:WL;2GX)*[\6\91XL70M0R='ZW"CY0A&LWG7]#Q_%C.VW'//D&- M^]T.<.PY7^2Q$N72YK6H1N7VZA6I=X3BO$@0BH_>%*6B=ALCJY&O"N*3=S(& M\B0N()>,6I<^U3';T$]6[.>-NJ(BGCMV$0[J=0?/9>E?H@7JWM_7"M.&J4M0 M=;>*\%7L5VW7!V#[`&])J1]$37"^QW+L1BW7%WTG2O<_5OU-]FD>LQ^TDP1J MI$VHJ-.Y.P3J=-!TO&GC*5B!B M]U-4@:]2'O%+NO3GE?,%/"D=-<2&^%T1];W@T:"9P=>G@EGO"R-5D9F"-0B: MHP$(>["99U:PWK.M]VSK/=M7LF=C/C66/+"=\KPFJ+LH*Z/48'XV%7R=^O0;=C&FZE,5Z6)3R*AU/(@($(A8CMF1I@)/%"0M> M8^Y82']ZSD-7<+9H_\FIX&NVZCW[0V]O"&9@UU2DJY2C;!S_<."!&65Y/%[, MYC_T/$#XVBM*^F%_R,GX@--1*TA6DD9E//;0WISTHLSFN$8?Z1CF-IIB&),J MG#6G)*D'9#N58]_\^)D2Z3?19;(7L7*RF)?Y4'0E2DA8`B;GM\-C'*CZ\/+5 M!:`5E'F4%O0J;TB0VMM`BQ3!83E\_EADI:0@CV>T]G%RRU[\#;\.4<5H04@,?6A=NH`*M!N7CNP^N]XUP?5A3#&=7^(F88UX!\T^QO2^#$YV`)Y2_(0'TW"&V!+JWM'M'CYX#`]DR5I M9E[?D0DOU8@B"A&R=9)X,K$\EH-CKF"NT)_%Z][@S9`H3I1I\%TLNAY>#068 MEHY&1787Y\[\"YIJV%M]`S]:C?((6M$E[799Y6-;(3' MVW^=H:F,L1:-5VR/KXM\5%`MC1$Q68V(1C3`^AL?N:NR8_4NA0CNV+JTZ#YW MQ(3FH[)ZOHE7/^%N;)&8YK3`_=DF?U;O7?:I#0!V=&)I:Y?X%0E7!8S1@%J+ M7?L]T4JS:C:PV?KW,=K:2CN];5QR170UMAGWZ;?J8*!?:T."?BZF=:1=21P[ M)CB00LSD4*>NR<.W]2<73^G3J[#83]E*Q\7C-NK-#Q9%O..CE+87HM4=*I;6JHU_]^TA=-:+?[GRR,G;I6J(;=/UFV^]516<=:U9"N M:9UQZ3([ZI3JG5[#3-+&:&W2Y?XVP$*S4]OHT\X(;C:$FW=+'=M+&RWYNSK& M;@^P'M5<7-KM&\?RXCF'4"N5JQ"MAP7MV>P&&RS(37>["TH-S!O/085:"7:M MZ2HF:4]56T&O8HWRG&E8#:M=6[,1[CWXL&AH0(2F,%#8Z=Y.I,5\3L%[.]'> M#D`1^%B[>@QC>?*\+QYB0YTXV1X\\AG>.NJQU:"/-J9YE(ZSF2/@1,%SK9". M,?R$2I+2@^P8+"(=M0B,UZM21HS"H&9P?HH'!XBCE9EXY>$HLY_2AA#[J7HD M2EBP.5%/9FE2;B<1W,KQ*<*H7+H42>/XVD@IXKF!"HF&D!_^ZB>)C$YY!UTA MO+93JJBG.GY"(2L$.PRF@G%8P2,ZWHD)6%26&`65+I)>?IF-CR7-RY!7MTI] MVA%X.>&L^>:9;082B]>;^M0T#4UC7&CGP`PBQG)CG@N<(H3ANV)QE;P>O`&% MV11&+/+3Y5'/*E#_NS%JR6E<3-T$(];=1E-9"72<@H&',WMXMK5"M;HK$ M_+6SV#S*H]GK?4HE&U2LKW2)!91^]WKPQGEC//)ECIPY6/F7>/GTEEXRZKU2 M1J846"KA<'P0QW1BP]`AM)0Z8UFGM].K+L=\'$+U-Q?:8X\8J-4,2C\Q@ZI( MU5@T^R0L^O>7Q*)"$FN+JRT7+2P*3L=<\V)?NZ4$KQDU&_*8TG!:I.4Q M0\QO7Y$]QO*$3O(XUI!I6@))'SE@S'T$J2+B-P*,VP!JI@S18N2QOEC?!%C? M!%C?!/B:;@*P]P0M62"\H3491_--\:LZ5SOD3M_&A>]J>;#="W9W]GS&#@W9 M[5+K0D=;T$A$"QR\/9JBU8R+U4V4H$IRDCF+TU*DU%TO5(*C*W)?V!7..=-)NKF5I")?@IX/XTH&,>AWEUUW]EW['K@UT M5@=2C"J&6FS1<(1'JR&A1@+\+$!Z6R,@E+!*D9#7874Y,^`J`9>VK3Q)KP'` MPH/7#CR/YL%"G'WF\7P:C9@7I,HII*_5H%:/?!7C"PJWKN?W:/G9VQ)-%MDH M_&N*QBL8.'SVMJB"!L#)W4MW`9.>L;<*E&-U)6V116(8"/371WD*F"54,-K6#&TZ32Y(CO MZN!_Q3,QBUDL_+W&<9K-JO!QXBBJ*<&EGJM0A$I*+:P.#O!:E&JLNFKYFYA% MZQ$%3_QX=(N&H?"#TT1W.DZN$_;HGSZSQ_%H#L<$L&'QKAQ:XR:?K.;K&C4K M]_U56PE-_H-R37EJE+L%>N633UGY=B.4:;,[M". M\0Y#6\>I\[N1<]%WJ&C>VNY&93:[4M3]K8!7'(;D+TUQ8(AF5P4FLO!0Z7W) MM3ZM>KT(+2:W@`].JVOT4*O6VX&V!?E\%I4C6!N>HX086E!Q0;0!*Q97F7Q$ M6J\=92"=P!E#5NK[N$Z]:)F]11I%D]NN9-I887GY*R!(\04?RP:W2==YA)]A MTEZPTB$6*7XKVP;1EX]Y6=#-B0&D[THI4*-7V*S0_:6Q2=2SIUDTCFZO%8'. M4EZ_$7(FGL8SU:ITX(AOT]?1$[<(U`^ZTXMF(@@KG%Z,O7U['B^PSXME2O"X MO&@VG2I/$M)7NJ<(%+%J!?\0#5%]!Y&E.-6`$LCK0]19'TV%`X8&N^J)=<51 MV)9^)`UTXZHGPE4$.(L9YYP`::N>Q'Y$TOSGKLO18X_&UI?H3TXP\)<77(?Q3X4=((4W2 MN*!*@NPLO;?^6"2CMZI]CZ*8:T:^,BNC:8B5#(\NJQSNF*9%'"C1;/SH710: M)S/*N0R.O\B/T/)K_J?-PA6/H/!7?>1U+^@-=BN"#]HQ!?'QA.E!X/13WG$4 M[EMG@*AIH]'\O33'CI$6;9N%BQS>CVDS>.3?U9!#EA3>*1(*E>*SZ!T>_2Z6 MVD%^%$Q%/%>V(!3UW)9(XWB:S&RI5N8XTN0(GUI85/9L+$6_`9&BBG2$YD.# M.FII:TNRB[S/#G=(K2%M8TP]*+?JT.MV'L*:X1T>LS>Y?:!1\`W,:#E.(*0I M=&MN*;S*!,LKJ*W%$V\-+5>@^BCA3M/$CQ*Q5,]3S`)K/Z6UG]+:3^EK\E,2 M$4L->:":@)B+*!)'JD*AF:2=X;1-X:4:/'-+L;!JG&6W<1T=!C)_6M1[R:^B MU+%2@Y+8]J'!]:/MCJS>(<1-8SJB6M4F1&G@40*D3>C+@7\IL+C3:*FI>OQ` M]^"MM;0WI+?AXEN38'9%#ND,>*P`5GI]K$!F_%P+\R,0IEZ,CM'EK\(=VI0;PO6F9OYODL\9C MJNF@ZMC[4C.:W_8C]R)B;I%&CNAH+L[KX:":L8A4B)F$*Y3[0VBH&BWW&E`, MDF`!`N^5ZKC.`M.N_L:KEIEBQZ'HHZS=OG,/8$D750`#>ZH&VS2$;45T,'U5 MV[ZZ..64&Q5S^$3CY3W92Y/BF[64A9GN2^ M5V\BH2-"%=0D@1I"ZXT2Q28T7V(7!A#E7?5-WBQ59\.M'R`+89OR$E*[J76Z MZ5(3YWDFSG[0CW0QKZ`GZO8.5T>DZ\V0B'-T3NR2I MPWA4JV8)HR94:JH=V4]]94%_<(YF:ON"3R'5W46*6.+;V_T9N[)6<=M;RX:G M0,U,%2Y.-=A5U=_=9#7U>.L(K"5JU#V935I]9DD553M%U`+7T`-%_YKN5,'L MFT_+G#@VD#.X+J*I8Y_O?1),]U903Q'V8(L" ML0"9UB,%55]_$((5AP#Z/@A&Q4Z_"D8A>6_'!WPOV!_40&:\1?&GC`M$6(_O MY>:O^V^&Y+6JB\OSX]-G_?#QVK(MYQ M(-Y9%?&N`_'NJHCW'(CW5D6\[T"\ORKB`P?B`P]B;0#W#K9K#W?S0_/IP#]9 MT)SN>:<<$STB=J2Q0PT+;'?D\HON3+:@25`['C4PSEU(&PU$'`.Q"B79H' M]0@L#!#P'H1HG^9!+(;G*`(^4-9D]).8#G#(.?J"(0T^Q[C&PL8YN#2*^J[\ M``GQ#>"#8\Y_E;E51Y';X>R1%^64'>D MK#QF+4?1=Z$85*$81['G0K%? MA6*?H]AWH3BH0G'`41P`*#YTE%#1:GD12QAC"N[+,:0$%7;[%#K=#H;JJC@X M>.37"G=VO``88G^_R;*IGFE(R4M35UHO5U@N5U@M5U@L5U@K5U@JFZV4M%\Z M<'>Y=HUM+8UMK8QM+8SK=;'INJA(L#87R'_\]_8_ULOC_X7E45LN+6;_L[EJO7^OU:[U^@2C6Z]='6K^4 M?5SP(.AIR]F^WP!IW!TVL__M[WJ42`3SR+I3W@H/>;@7`P+]5!(RR!_O> M-IC27/5RQ7Z)X:@'NATP6<4\$NU5@>+I-,3#G@"Z3@J$3=)"@P*@(;"-._SN M)IF2`ZGB-<]Z$WQ#IWSPW7>!E:$X3J+O_GV>.51'#D_ZT*G!DWYU6R"#)O1I MA?JU.%FK=A/QQV5M3S;6!]9OKPL&'ZL+#"2#6EU2BQJSHHZ'C,%GTF'>W$'= M[F2RZ%&_D1U+[?1J$<*\B_V]51M-#>Z[V/_CCPJ:U8=[]92G==4<[5J9*GE3 MOVX3;SO\ZP5__14XVS=^!Y"FS.E>JJHIML&M0-S178&+J%*-I$2N&%@V4H<1? MY1P1E&C4X`^F"'^\:7I5@B*5*@9>&"8?&TMP/^C)W`\=_J]37:6CRK]E]XPJ MU&YE%-3;-*OCJ+J\OL;+(53>1E,Z/@HYDG@R,)PTX6,.`]9)LKB^F=XD/=B] M?U_AO^@G7':#HS4.WO$-DF1:)BD5%E%:AG-*)T&.QY#R2Y&)7*H8T7TH@5N2 M/"0F"G&?U,I%'QZ>%B_@%FEC#^:3,HQP557K*.[=OJ]W[0U\]7!IB/#3CA^B M6X(Y_1I#BT]_B_P1G>Z\%TPAA;)U*443)%%0:E\78*.Y(<$DTJY//JDEW2-- M2B=#XL'\M818W=$W:#18:FESE783<\`VI,%O(?F,!C!CEBM_\-D-<+UW(9#! MUS@'KO7AY[AN7SV.Z^%I>;@"XW1#<%E;:_\4VYMM3%Q$+@I%_6&]59BKXIJ[ M6W=#@4*:51=IZ`Y`;15'@/\D5Y"B;=*/YEY!0G=?;[\A=&X+_=#>$F%$O4I$ M/8JHIR&JJ8]$VUP7P7\UT4.B;9<.@G*Z@OQ^)?E]2GY?)=\T.:C(:6-I!5[$ M@S=*@\P-M8V14L$:Q8,^0)I5)<@P^.#0OR!Y`$UL\[/O1/M"50;^B"8XV-UV MG:LZ=JVM157!-`SJGE7>"_K>VU!]"L$CR^[&][ZZV'ID8]^G6R24H>MM!ODI&`OU;6(S!O!5K4>\\I>U]# M'TYS-'`0B!ZCN>+=.1Y5;C*-K@MY9Z_O:C;N\_Z^MPMIG^-K/X_\761REV30 M"W\Z;V4&OHID9SCZCKFH58,V^-@]*_PIQ1$6Q`D*01JBAO<-0<Y<^ M7:C`[>V8]^,^HQ[:V_E,^P@3MFPO^>KP5T&[<&]'O#^)9CJ[-VS,7T4.XC07 M+8$B#Q41YXNMB76,.,]9S'<5+4'1=96E@\^L'*=:EZUQ(GWP71:2D+:DITQI MJ8VKM3(0/>1J*=103+Q:KJJQO$%8RW:L;K2E?RPRY=58I,>`2XD5%7"I.BP, M=I)*\PU>KH_=&XTB..,PA$$*_QTQ2L.#HE%$9C]F[%+%^ M<8SS1WF^U]]%';./:+_09EK]-61>QLK32&CHE#?<@4@M0$Q+K)0\5.JI_K;4 MSL`P(!2PL8?8A)A%:(L:HMBO#]HOS5ID(E$1X6WJGP8L_N[?)Z0,.V:R;F5B MG$&[^T6LIW_HF'\Y3YFXC4VWL&TH+?OK+\;;GP)YGE#=L`]`PQX\J-FP#P#; MQ7F:!@F9C10`FS\]THE-(C+#EW!A4B@4SM@\W8KH+// M'L*L`*-)"`7EMW_R,T!MDM,9H<+R4";F?$#"BB>SF8U2R+%SP*+QX'?K^:]L M.AYEB[0D7,5=P8@W;'AXE!`Z@/0-TKK@N^!_-S9ZP7_\!QI&?]$_>OR//O]C MT$7PY*\]GK3#_]@5>?L\Z9'`M"TR>P)K3Z#M#<1?.^R0;%L7`&Q)2S,2.`D_ MU!AL($#4F'Z?,YR/D0<]9=Q@GGPCFLA;@28*'8:$*0]^8@JX\%'"I?0R/3ZY M.$66T*M]WHB%"IG%Y(\JZYX8O@1:VO:T]*[@`::N"A5%D M#3W;O#=IZ M?>C6J6NP>EW>['Y]4G8^.BG>[$%]2G<_-:7>[)WZ#=G[S!OBS=ZMW\[]+[N= MWNR]^FPX^*K9X,W>YURRUHP?`B4J,I?A8I4WP94H6G)MP\LN6M;`O1I9;M1U M%VL*M(!#4>#*@J[1"S4+TJZ)%LGU)4O5-C<1*F*\_#/253"^_R'9WP#[%G./ MH^!169#3*WJ]KKFYP5R@93Q<<'&B16Y0COCY@]4CU#:N"-V_CQ.[U,?0&@N0 MXKO;!;I7IT$JQ,1VS7?L;I!;R#4":A'5,A&T486F\`EC@.XY:=H%)/TZ:?3E M3^I2:36MGK9'>>I4]7@_^'4\T3$>!8_"".U.=+!+K:M'?C#W$$\%Q`,&XZ0> MY_MIQQ"""W)R90K<>2W(RX]*G3NO!6UIORYM&2M*;>L*>U\^'.8L><6 MQ=3NB`84-60;)]YH@=W&]U'","J*."_#292@-?9;`/;;+=\)\E:PN[V/9^G+ M\Z/+R]_#IZ].'U\>GYV&(>KE;>7P73#)-L6:=E54/S6(P@XSFM$5>P>970T- MSBZ$:2`Q\?OGN$;N?D+MR:9+P<-_*%Z4S!U"%``,Y=*.3&Z$&50JCA[$O0,- M=E85$EUDX/ROXP(?X$(/`'FW[P6AEN&+<%WP]D"HXN8L4!1N,''I@PTIM;LA@ M)"WY;=!J/I*[!FN#2]7'3%C[:!C'MFL?C?8I7?MHM+.=^$+:N?;1J,.&>CX: M?'W0]B54<`M=B<%TB3R1@@E@L@&U=KY2:+$6(E2HS33H^5&Z9@K\L M5UM#HV:*K!)Y0E%E*_9`G#$>MP:GA[#=8(^_@U-WQ-V1J,T!T-$QB`8AO8RM M,93X)6/=HXJ/QK=)'&NSB5"SK.ZU"/%XP+`^Z&FZ[80\%4YX&218T=&I'J*! MGKC&#JGR=?+&KY.3#N8^[K;K".*+4:78KM38@[")8>Y!M#LG#*0G@Q;@^Q9Z MZD-M\^+P>K[)9C&YKH2F98PD[RW:B#X_>W'TK;;14KM'EK!<]GF6(BFJ_6** MQ6@4%X6YAV9[`548\8]Y9M-7UVE`L_<%:A2.%7+Q.#PY>W9\&IX>OC@*7QS^ MB_LA&15C=W16GD@2P#[`T?3F_"$(GAE0'@9$!$=T2[H)7*\!&$*EQ)_OS00_J4/PI[>QM]W<@ M$G@K_!W,$<$$B5BRJ)?G=ZA[92]_1TINB6JV!$TXSR--O[%6//Y!G<_9XKB@ M@JUY.^[*7!@)?WR.=?JG7):"O@^.'-%)FVCRN8HW[B88C?L"#QZ&CF(?W%;/ MN?-^B_HI4G?^X*?Y'?Z[VN]2KZE5.6S?*]H!2+=-=_33E`R@C=_^[[=#HRW6 MLF(O:7K]4F7EB$U3I+>%MFF)?TP"$JRZW8Y79(V":D.1P':?*^*6G*AG+/I. M\F5%@Y&&R6\TTD#K&HYJGFX+IGH.N3GW*@ZY):J*LVX)*!HC.JBA'4SB6OG0 MV\#D!6CC"+Q9?14`;9R+MTQ0!4`;9^9_-\45`&T*345X)TL*Z\3DWKA*DA37D"V]_)4@+*\K7SZ)*$/^)S7K'M-XQK7=, MZQW3>L>TWC%])DSYF#LF96E4W!-`%VEI[+4MMFJ4NJI#;MJ(.!V'_,BN7B2L MASP2UL,:D;#&W)&!0,M(6%JZ?LRMLGA1Q'DH'2-M`&GO-DSFLEV>(P>!'K6> ML]7P;5[!>%YM"1=$/N#5VZ;PQBZ42D,\6A%0M5<]TK#Z%20-5*A(=H5-E245 M[ZKJDHVK`J0%E6F).BM!6E"YAV2ZBD/X`*6,JO*XW5/@?57AQ5?@= M45[!'D>5OD9-O8QT;S'(N\CC553/407V)@+]B$2/0,Y$BBL1Z#%D>_8LXR4$ M^P?5\@QR^@39WD!>+R"%K1YNFJ4:NOM8CCYU7'RJG7L`?QFED(.%'YR.F#YR M/JH?C!$B%Q5Q;$G8E4>.D$.MYE@CJM6N8_&O\9Y"$+5JD#6)R+^'D'"M!UM; MFXS7)N.UR7AM,EZ;C- MQZSW,>M]S)>\C^$KHQ8<4`_,L9P+#&!+=MSE=+R6HH5AX[$-Z@978U9@Y9'J MHA2&6/WIXX(\3.T(Q\9BQJF6:_P`H`GQR#ZX^B>"VI2Q%MA#S6/N>?,=>\IB M&SAO(-H"TA?*[U&/S+)QC*,O!-N]_6WTD5(;V]L[Y(==+PG?]XZU;6,@#MU( ME7L[M%)9Q=Y.G4JZ73C:'#ZN0H.@0;`)6=:(;*&U0XWPD<%,:`A]B<_80F-$QF5IB&K`#]/7=(`.P(CC]M"RG>'A/,"S@Q+"2*(9T2Z M\3QEH'.;%5@[,B:\E!=%](BK)#]HK?H%3-BT%ZWJ\3" M9&C9$["HD`B[DL?728&P\;A`;CG]J&N>+.NO-6&LWV-1-$>K'CT%E>*)I@T! M<"2`QB8X2X/`1].LB$UXG@@5(,N3"HP3(,"I!3G503_(%0X_>6L%M((EIA7Y M!X=J$$M?(-^OK12X?\F.<`%SD+Y$W!MT7<]_BW!;V$.WT)YL94W4^YN-2O[B MKQQ71N`EP5(Z+_2P2^8"ETW'XMVM>\&C7D7$3J6T*`F]X27!M-X2C[1S#6=+ M(Q9'@*I>^7B7*M&5982Q'2>[(<[#@ MM_/AJ,S&(%"S/MAR7GL[OAFGOS/%LNQO4_.IP&0J3@_DT*E885IBEG/M$2*% M#:@?V8@ZT-WCH8#-)@_P:.&1R1SQO^P=@AGLQ6P_4T/X9#&T$9[NJF&//WAHX\\*RMYD>?"1I:K55`4P)0H8@4R\6F\KTT`0?/P1[:=Z$\H_ MYV:4;42_@3>B_$-;WF^6WY'R#]J9BEUI;0KJ;ECA*&O@ZL0_W[:-[U=X)Z%) M46].6-]]35B!(W?Y#0C_7&'2ZLP;'<[]\@'^W',,?Q_`L5MO!RQ%M_.`1>.C M=Z>LK0.>K;*$$R&P=7'Y,Z M=UX;YU.?BG)W7ALG4)]CJ]QY;1PO?6DM=N>I$4"`4R./B"5Z&R\%.L.196AE MF2N1N/+:D+EU:G'GM2%S5Z7`G=>&S/V8U+GSVI"YGXIR=UX;,O=S;)4[KPV9 M^Z6UV)TG9&YO.:^SM3J^5L?7ZOA:'?^"6K56Q_]V=1RM-5OD32"@-F'A6E4$ M&XA\^2V(XD:U^?-;$,NM4N//;T%,_ZW4^O-;$-V?56O\^2V(]"^JM?[\%L3] M5\4-?[Y8#O1#CF4V#>M3A_4V9[W-66]S/A/U>+W-66]SUJ<.ZU.']:E#NY2O M3QUDWOK40%@W7Q5U86_9"&OVW`\:3D#>*&:/HG6'Z MHU$X")HG+@;QBVOT?E#E73#]RE"MVSKP'1VSQY(WOM@1*T2.L&[G.&KF(23< M==>^H>,:).P^E'X7RB8';R>,\-M4UB'!A`JZQ#!IB'WSADG#BMLU]KV:ZILR MKCLR>ECQ>GLQ;+G?IC6IR;8MJU>3(ZCT'^9#F)&-NEW337DCR++2[FN@(H8VUCIBT3EG?H'0C,Q M2AKJ_U8PRJ;3J(S':#V9S:,\%BIR1XWT0F-L=3"A'7-IZ[#EC,5C8;%:J,XR M[/S9@:]W0QL+OHR:L5UHJGD;VU30;>7*9*?!I/L!ZD7W!H>V471.#61BS/B+ M"A83KF+=*AGAIG;,O@@VHJV`,UA=K8-H""0R;JOSB/Y=]!#7-C?LC$T*W*7X M@(+]JH)70S[<<25(+^M3#07D]U:0:JRE[6,PG+]T]T[@61)30U/*;#%463(9K?+F/AP%:RBM'S,"-H7C,K8?_X+'P!#[$U7M!K[?[J#+DC#EG4F66B'!XE-IX6NK4DD8S MA5IHJ:HJ;47M8@32J&H4G[;?]2G2J@K-7A%*]*TN,+$HB0\>*%//'%7TDU?. M93V4^C@=:R^X-`_$YH2H//T8+Q6IC0Z1BNB^P((Z5J*YM?!,HTM]D-GM/<]8 MIRYO=GM/,K9`BC>[O2<8/SZEWNSVGEO\Y`WQ9K?WK.+GWDYO=GM/)W[A;/!F MJPQ7X\EB].\R6+K%;W[P=$+9#)]=8LN9Z['R"F:[9WT=+4`L^J)>'D M<\-4Q7`M6[AQ`/<$HE47+@.1+[^%I:M1;?[\%E:O5JGQY[>P@OVMU/KS6UC& M/JO6^/-;6,R^J-;Z\UM8T[XJ;OCSY;._;!71UC8JW#FX`)*KVP?5`0#V]7;M/\41$/\*P?#\GEDRS;[N!T==AB/[,DZM%&9/)>X?PHY$X3:(B MV/C6+/ZM[H^B&I.T`W\Q@-"O>%1F^7O7B7_5V#*L3Q29,NZ8EXGXO;')*D#3 M3RV[A7/Y#`&LL,Q*6)2(P3/;U86==V/X:9*^U4U$>AXV`+TK#9.0,)I]`+#1 M_`*HE5G3)MDB'?,)-(O+B/^-GSDF8PHGDK>3G5,9"B7.#8NT-'_CP(ALO=/] MBSD*]*#HXT:,VQTAA2C5=*K3T4K]2JP:51N6>>*/J"2/1]32X?&DINHY_0L( MRA^&>72'CT)NU%%*P>F1AYW1[9IV.>24'NW3<)3/YMDP`3NR99 MP?_)0)-L$/@]S6LYFG-,U>[F'+*NP96/28=')4/7AJ.YALH/T9+3>:,:JR!: M_PS;5071DH/[%]GR*HB67.&_4MY40?@MO'*A M4+8-PM`+X5Y?7EU?7EU?7K7RUI=7UY=75[R\NMY8K#<6GUQI66\LOJQVK3<6 MZXW%E[BQ\`7_Y";'59<1'8\GNX4%I$%=WNP6UHWV2/%FM[!6_&V4>K-;6!P^ MEX9XLUM8"KZ0=GJS6Y#Z7P<;O-E"NJO'2?]GPGJNMV+KK=@G5_/66[$OJUWK MK=AZ*_8E;L5\9MGU&<_ZC,=)W?J,9WW&LS[C69_QK#<6ZXW%YZ!JK3<6ZXW% M>F/Q^6PLE#,>X=ZOF!.[:MP1?A^G(O[@/P,@^*"D`X<<5,$QN6JP0`UR;X=> M,]CN=F302N!N1<7E"NUB"HGR0]O*XZ5H=YK^[*CQ,<4=%.MV"G2%@(=*,H#U MR%`$Y8.?S`L)/")*3P,F,5#4`IZ@@M=9F>&(5JB3PSC/L]Q1*VDVO4T&`*`Y MZ`YJ*SBLQ2!D]VRVU>`I]+]:V%8U7HMRI:@BFB7[]&&%[X2-<8QWYSK)S^YP_#6*UTNNJ:4S M$1AYPPI^MM\E`2I9(#34D]NNALH66\-I3T'28TC`F-'69\7?=+/#D$@'4B+Q MCX4G`H(OVW%`]>M]2F0I[9.A3<%<*H#PV$%\WD14@TVN._DP"PV472W&+)HS M8SH?Z?QQX<'2GL&BRI\46W(5 M53_U%N#&QKC+>>$L@*AT+\#RWA]ESIW7 M@C'ADU'NSFO!4/!9MLJ=U\+V_XMKL3M/;.>!1WH!N4K_I;MY]]K#-WMNS9>B MI%L_LA%TKIQL/VS$,5:_^_=E:`;[^V"EZBG.]QFX^FT%9&!6@"X8HM0?2,#> MSK:\WZ_<5%<8`TQ=I*XYP*UM--8NJL,95"H82\O^&IOA,L7ZV`+KZEM M5+Z<<)_K$=6OJ]F/J:DKN_4R6N/5G82.&S(M1K6)$X#A?N#!H%1?/`U![ON_M"/OU+]4.JIHY1].L MB#4[)V^U9N\.!:!EY)0'4XX3`ZQZHG91/C#+O*KZ_C,88"LVSE9'``Z91]O# M(Z!Y.>-O=)TF*PVN;&YE4RE'F)$<&KQVAZE:L.M!#B,DI%*D:^K[RIR0720C .#:+Q]O\!-6U&P&H/`P!E ` end From alan@linuxcare.com.au Fri, 10 Nov 2000 11:36:56 +1100 (EST) Date: Fri, 10 Nov 2000 11:36:56 +1100 (EST) From: Alan Modra alan@linuxcare.com.au Subject: abort in eliminate_regs compiling glob.c from glibc On Thu, 9 Nov 2000, John David Anglin wrote: > > Breakpoint 2, eliminate_regs_in_insn (insn=0x406a0ba0, replace=0) > > at ../../gcc/reload1.c:2826 > > 2826 if (! insn_is_asm && icode < 0) > > (gdb) p debug_rtx (insn) > > (insn/s 2711 2709 2719 (set (reg:SI 6 %r6) > > (reg:SI 28 %r28)) 69 {pre_ldw-4} (insn_list 2708 (insn_list:REG_DEP_ANTI 2696 (insn_list:REG_DEP_ANTI 2702 (insn_list:REG_DEP_ANTI 2697 (nil))))) > > (expr_list:REG_DEAD (reg:SI 28 %r28) > > (insn_list:REG_RETVAL 2708 (expr_list:REG_EQUAL (expr_list (use (mem:BLK (scratch) 0)) > > (expr_list (symbol_ref/v:SI ("@strlen")) > > (expr_list (reg/v:SI 4 %r4) > > (nil)))) > > (nil))))) > > The `use' arises from the `__pure__' attribute in the prototype for strlen: > > extern size_t strlen (__const char *__s) __attribute__ ((__pure__)); I don't see this problem using current puffin CVS hppa64-linux gcc. Was this with your REG_ELIMINATE patch? Alan Modra -- Linuxcare. Support for the Revolution. From dave@hiauly1.hia.nrc.ca Thu, 9 Nov 2000 21:50:49 -0500 (EST) Date: Thu, 9 Nov 2000 21:50:49 -0500 (EST) From: John David Anglin dave@hiauly1.hia.nrc.ca Subject: abort in eliminate_regs compiling glob.c from glibc > > > 2826 if (! insn_is_asm && icode < 0) > > > (gdb) p debug_rtx (insn) > > > (insn/s 2711 2709 2719 (set (reg:SI 6 %r6) > > > (reg:SI 28 %r28)) 69 {pre_ldw-4} (insn_list 2708 (insn_list:REG_DEP_ANTI 2696 (insn_list:REG_DEP_ANTI 2702 (insn_list:REG_DEP_ANTI 2697 (nil))))) > > > (expr_list:REG_DEAD (reg:SI 28 %r28) > > > (insn_list:REG_RETVAL 2708 (expr_list:REG_EQUAL (expr_list (use (mem:BLK (scratch) 0)) > > > (expr_list (symbol_ref/v:SI ("@strlen")) > > > (expr_list (reg/v:SI 4 %r4) > > > (nil)))) > > > (nil))))) > > > > The `use' arises from the `__pure__' attribute in the prototype for strlen: > > > > extern size_t strlen (__const char *__s) __attribute__ ((__pure__)); > > I don't see this problem using current puffin CVS hppa64-linux gcc. Was > this with your REG_ELIMINATE patch? No. Well actually I saw it first with the patch. I see this with the 32 bit compiler. The only elimination with the 32 bit compiler is the default frame pointer elimination. I just tried the hppa64-linux-gcc compiler with the source that I posted and it didn't abort. There were lots of warnings about int to pointer conversions though. Make sure you compile with -O2 or -O3? Register elimination only occurs at -O2 or above. I see the problem both with a i686-linux cross compiler and a fairly recent native hpux compiler under hpux 10.20. The problem is not present in 2.95.2 but it doesn't support the pure atribute. Dave -- J. David Anglin dave.anglin@nrc.ca National Research Council of Canada (613) 990-0752 (FAX: 952-6605) From matthew@wil.cx Fri, 10 Nov 2000 09:49:07 +0000 Date: Fri, 10 Nov 2000 09:49:07 +0000 From: Matthew Wilcox matthew@wil.cx Subject: linux bame On Thu, Nov 09, 2000 at 03:53:48PM -0700, Paul Bame wrote: > Somebody never imported 2.4.0-test6, then I imported -test10 on the main > vendor branch and now can't (easily) undo that to import test6 and THEN > test10. This workaround sucks. don't use vendor branches. didn't you talk to mang about this? -- Revolutions do not require corporate support. From matthew@wil.cx Fri, 10 Nov 2000 10:18:08 +0000 Date: Fri, 10 Nov 2000 10:18:08 +0000 From: Matthew Wilcox matthew@wil.cx Subject: [parisc-linux] tulip DMA mapping On Thu, Nov 09, 2000 at 12:12:25PM -0800, Grant Grundler wrote: > 0 is a valid pci_map_single() return value when the system has an IO MMU. Oh dear. You can bet tulip won't be the only driver which assumes it isn't a valid return value. Can't our IOMMU code be limited in such a way that 0 is not a valid return value? Say, constrain all allocated addresses to the top half of the device bus? (um, just check me on this, map_single returns a device bus address, not a processor bus address, right?) > The system will panic before pci_map_single() will fail. > The driver needs to remember some other way if a buffer was mapped or not. > Or the Documentation/DMA-mapping.txt should be changed - ie add this > to the interface definition and I can reserve the 1st mapping > entry so no-one uses it. we should probably have a BAD_DMA_ADDR define which that array should be initialised to. it's a little late in 2.4 to go through and audit all the drivers again. > Should I be mailing Jeff Garzik directly? > Or can someone who knows Jeff point this out to him? i've cc'd jeff & dave miller on this. -- Revolutions do not require corporate support. From davem@redhat.com Fri, 10 Nov 2000 02:16:11 -0800 Date: Fri, 10 Nov 2000 02:16:11 -0800 From: David S. Miller davem@redhat.com Subject: [parisc-linux] tulip DMA mapping Date: Fri, 10 Nov 2000 10:18:08 +0000 From: Matthew Wilcox > Should I be mailing Jeff Garzik directly? > Or can someone who knows Jeff point this out to him? i've cc'd jeff & dave miller on this. In 2.4.x there is _NO_ error return from the PCI dma functions except the consistent DMA mapping ones. This was an explicit design decision, the dynamic mapping functions should never fail, and if they do it is a hard error. Therefore no drivers need to check for failure, as far as they are concerned, there is no failure. So what is the issue? In 2.5.x I'll add an error return facility (BTW: -1 ie. 0xfffffff would probably work as an error value on all platforms :-) Later, David S. Miller davem@redhat.com From rhirst@linuxcare.com Fri, 10 Nov 2000 10:55:16 +0000 Date: Fri, 10 Nov 2000 10:55:16 +0000 From: Richard Hirst rhirst@linuxcare.com Subject: [parisc-linux] parisc-linux reaches uptimes in excess of one day! Just for interest... My A180 has been up for 25 hours, the first 12 of which I had a couple of telnet sessions open running vi, gcc, etc. and since then it has been looping doing kernel builds. I also ran cvs to update its kernel source tree from pehc. So far it has completed about 23 kernel builds with one hiccup: do_page_fault() pid=2420 command='cpp0' YZrvWESTHLNXBCVMcbcbcbcbOGFRQPDI PSW: 00000000000001100000000000001011 r0-3 00000000 4013ac38 400e134f 00000004 r4-7 40138c38 ffffffb5 2002014b 00000001 r8-11 00000004 00000000 00000000 4001ada0 r12-15 4001ad7c 0001b300 2001f601 00000001 r16-19 00012000 00000023 00000020 40138c38 r20-23 20020100 4012a51c 00000000 9999999a r24-27 2002016c 2002014c 00000004 00013d34 r28-31 00000000 4013a438 200201c0 40041757 sr0-4 00000000 00000011 00000000 00000011 sr4-8 00000011 00000011 00000011 00000011 IASQ: 00000011 00000011 IAOQ: 400e13b7 400e13bb IIR: 0c601094 ISR: 00000011 IOR: 00000004 ORIG_R28: 40019450 Richard From rhirst@linuxcare.com Fri, 10 Nov 2000 11:12:20 +0000 Date: Fri, 10 Nov 2000 11:12:20 +0000 From: Richard Hirst rhirst@linuxcare.com Subject: [parisc-linux] tulip DMA mapping I've quoted the whole of Grants message below, so you can see the context. It looks like tulip is treating zero as meaning it doesn't have anything to pci_unmap... Grant Grundler wrote: > Hi all, > I see a "bug" in tulip's usage of mapping services. > It's not the bug I was looking for unfortunately. > > In line 217 of drivers/net/tulip/interrupt.c: > > if (tp->tx_buffers[entry].mapping) > pci_unmap_single(tp->pdev, > tp->tx_buffers[entry].mapping, > sizeof(tp->setup_frame), > PCI_DMA_TODEVICE); > > 0 is a valid pci_map_single() return value when the system has an IO MMU. > > The system will panic before pci_map_single() will fail. > The driver needs to remember some other way if a buffer was mapped or not. > Or the Documentation/DMA-mapping.txt should be changed - ie add this > to the interface definition and I can reserve the 1st mapping > entry so no-one uses it. Richard On Fri, Nov 10, 2000 at 02:16:11AM -0800, David S. Miller wrote: > Date: Fri, 10 Nov 2000 10:18:08 +0000 > From: Matthew Wilcox > > > Should I be mailing Jeff Garzik directly? > > Or can someone who knows Jeff point this out to him? > > i've cc'd jeff & dave miller on this. > > In 2.4.x there is _NO_ error return from the PCI dma functions except > the consistent DMA mapping ones. > > This was an explicit design decision, the dynamic mapping functions > should never fail, and if they do it is a hard error. > > Therefore no drivers need to check for failure, as far as they are > concerned, there is no failure. > > So what is the issue? In 2.5.x I'll add an error return facility > (BTW: -1 ie. 0xfffffff would probably work as an error value on all > platforms :-) > > Later, > David S. Miller > davem@redhat.com > > --------------------------------------------------------------------------- > To unsubscribe: send e-mail to parisc-linux-request@thepuffingroup.com with > `unsubscribe' as the subject. > > From davem@redhat.com Fri, 10 Nov 2000 03:26:48 -0800 Date: Fri, 10 Nov 2000 03:26:48 -0800 From: David S. Miller davem@redhat.com Subject: [parisc-linux] tulip DMA mapping Date: Fri, 10 Nov 2000 11:12:20 +0000 From: Richard Hirst I've quoted the whole of Grants message below, so you can see the context. It looks like tulip is treating zero as meaning it doesn't have anything to pci_unmap... Thank you for the clarification. Jeff, this is in fact a bug, please fix :-) Later, David S. Miller davem@redhat.com From jgarzik@mandrakesoft.com Fri, 10 Nov 2000 09:30:41 -0500 Date: Fri, 10 Nov 2000 09:30:41 -0500 From: Jeff Garzik jgarzik@mandrakesoft.com Subject: [parisc-linux] tulip DMA mapping "David S. Miller" wrote: > > Date: Fri, 10 Nov 2000 11:12:20 +0000 > From: Richard Hirst > > I've quoted the whole of Grants message below, so you can see the > context. It looks like tulip is treating zero as meaning it > doesn't have anything to pci_unmap... > > Thank you for the clarification. > > Jeff, this is in fact a bug, please fix :-) np. Like Matthew(?) hinted, this is not the only place that needs fixing. I'll take care of it. Jeff -- Jeff Garzik | Building 1024 | Would you like a Twinkie? MandrakeSoft | From bame@riverrock.org Fri, 10 Nov 2000 08:57:47 -0700 Date: Fri, 10 Nov 2000 08:57:47 -0700 From: bame@riverrock.org bame@riverrock.org Subject: linux bame = On Thu, Nov 09, 2000 at 03:53:48PM -0700, Paul Bame wrote: = > Somebody never imported 2.4.0-test6, then I imported -test10 on the mai n = > vendor branch and now can't (easily) undo that to import test6 and THEN = > test10. This workaround sucks. = = don't use vendor branches. didn't you talk to mang about this? Um, I have no information to go on from your note. All the (successful) merges I've done before have used the cookbook CVS merge method including a vendor branch. Several (N-1?) of the palinux merges have been accompanied by updating the vendor branch. And this merge is going well despite the ugly workaround, or so it appears to me. Just importing files to a vendor branch should have no effect on anything else unless CVS has some horrible bug (RCS does not). Before I make what is apparently a serious mistake ("don't use vendor branches" sounds pretty serious) please enlighten me! -P From grundler@cup.hp.com Fri, 10 Nov 2000 08:29:25 -0800 Date: Fri, 10 Nov 2000 08:29:25 -0800 From: Grant Grundler grundler@cup.hp.com Subject: [parisc-linux] tulip DMA mapping Mathew, I think the situation is clarified. This is just FYI. Matthew Wilcox wrote: > On Thu, Nov 09, 2000 at 12:12:25PM -0800, Grant Grundler wrote: > > 0 is a valid pci_map_single() return value when the system has an IO MMU. > > Oh dear. You can bet tulip won't be the only driver which assumes it > isn't a valid return value. Well, then: 1) the driver writer made a wrong assumption that the "spec" does not support. 2) that wasn't the case here - 0 was used as a flag to indicate a mapping had (or hadn't rather) been done - not that the mapping call had failed. > Can't our IOMMU code be limited in such a > way that 0 is not a valid return value? Say, constrain all allocated > addresses to the top half of the device bus? It could pretty easily by reserving the dma_map[0] entry during init time. Dave Miller already made it clear that's not desirable. > (um, just check me on this, map_single returns a device bus address, > not a processor bus address, right?) Yes. It's the address a device must use to master DMA transactions. pci_map_single() input parameters are "struct pci_dev *", virtual host memory address, and buffer size. The return is a device specific I/O DMA address - ie this mapping cannot be shared with other devices. FWIW, "I/O DMA address" are called IOVAs in HPUX (I/O Virtual Address). The HW guys prefer another name but this one stuck. grant Grant Grundler Unix Systems Enablement Lab +1.408.447.7253 From bame@riverrock.org Fri, 10 Nov 2000 14:28:33 -0700 Date: Fri, 10 Nov 2000 14:28:33 -0700 From: bame@riverrock.org bame@riverrock.org Subject: [parisc-linux] kernel merge = = We're getting ready to do a kernel merge (to -test10 I think). Anybody = concerns before we get started? = I'm getting ready to commit the changes to merge us up to 2.4.0-test10 as soon as I'm confident 64-bit kernels are OK (32-bit seems fine). Here's a brief list of changes made (and yet to be made -- if anyone has the time/energy) to our parisc code (does not include changes in common code!). While there's plenty yet to do, I think we're no worse off than before the merge. Some parts of our parisc code are getting rather moldy compared to the other ports FYI. Important tags: LINUS_240_TEST6 Linus' 2.4.0-test6 LINUS_240_TEST10 Linus' 2.4.0-test10 LINUS_240_TEST10_PREMERGE Our tree before the -test10 merge LINUS_240_TEST10_MERGED Our tree after the -test10 merge ------------ Lots of 'extern __inline__' turned into 'static __inline__' and there are more to do (TODO). Beginnings of several smp_mb*() macros -- implemented as no-ops in the non-SMP case (asm/bitops.h, asm/system.h) SET_PERSONALITY() macro in asm/elf.h needs updating (TODO). fcntl.h acquired a 'struct fcntl64' used with 64-bit offsets, implementing fcntl(fd, F_S/GETLK[W]64, ...). Several other locking-related #defines added. asm/mmu_context.h:init_new_context() now returns int (always 0), not void. Should our asm/bitops.h routines be re-coded in assembly? (TODO) Added #define RLIMIT_LOCKS to asm/resource.h Added #define CLOCKS_PER_SEC to asm/param.h (how did we miss this one?) Our asm/string.h is behind the times. Fixing it might get rid of a bunch of compiler warnings! (TODO) Removed mktime from drivers/char/genrtc.c (it's in a header file now) x86 made a bunch of changes to asm-i386/floppy.h -- should we? (TODO) looks like maybe the get/put_user_ret() functions in asm/uaccess.h are obsolete? (TODO) We'll need to add the getdents64() and fcntl64() syscall glue. (TODO!!!) Our arch/parisc/config.in is in BAD SHAPE (TODO) arch/parisc/process.c: added new argsto do_fork() and copy_thread(). IA64 seems to use the copy_thread() arg. arch/parisc/signal.c: minor change to common data structure drivers/scsi sym53c8xx_comm.h #ifdef doesn't work on parisc -- eliminates unmap_pci_mem() causing link error (TODO - rhirst) From pjlahaie@linuxcare.com Fri, 10 Nov 2000 17:14:06 -0500 Date: Fri, 10 Nov 2000 17:14:06 -0500 From: Paul J.Y. Lahaie pjlahaie@linuxcare.com Subject: [parisc-linux] Beta CD --uXxzq0nDebZQVNAZ Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Hello fellow PA-RISCers, An preliminary beta CD for PA/Linux has been uploaded to puffin.external.hp.com. If people could try it and forward any complaints or suggestions to me, it would be greatly appreciated. The URL for the image is: ftp://puffin.external.hp.com/pub/parisc/cd-images/palinux-0.5.iso.gz - Paul --uXxzq0nDebZQVNAZ Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.4 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE6DHMu8ggPQthPCzcRAgb0AJ4jJs5VOnm+9aDXUbtwht7hxAa+UwCgihAo nEE25pYQwBwCDuALcSdyCNw= =bTuw -----END PGP SIGNATURE----- --uXxzq0nDebZQVNAZ-- From randolph@tausq.org Fri, 10 Nov 2000 19:18:47 -0700 Date: Fri, 10 Nov 2000 19:18:47 -0700 From: Randolph Chung randolph@tausq.org Subject: [parisc-linux] kernel merge > Our asm/string.h is behind the times. Fixing it might get rid of a > bunch of compiler warnings! (TODO) if this is just an issue of implementing the various parisc-optimized string routines, i've been working on this, but don't have everything ready yet. randolph -- @..@ http://www.TauSq.org/ (----) ( >__< ) ^^ ~~ ^^ From crypt@ihug.co.nz Sun, 12 Nov 2000 01:47:56 +1300 Date: Sun, 12 Nov 2000 01:47:56 +1300 From: crypt@ihug.co.nz crypt@ihug.co.nz Subject: [parisc-linux] HP 9000 e25 Considering how often this question comes up is there anyone out there that is interested in tracking down the info to port linux to this class of box. Server boxes may be classed as boring to some but there seem to be a large number of people who have at least one of them sitting about doing nothing. Joe. -- ======================================================================= in real life: Joseph Skinner |There's no such thing as a wizard email: crypt@ihug.co.nz |who minds his own business Analyst/Programmer | - Berengis the Black | Court Mage to the Earls Caeline ======================================================================== From snaketails@optushome.com.au Sat, 11 Nov 2000 23:57:43 +1100 Date: Sat, 11 Nov 2000 23:57:43 +1100 From: Rod Smart snaketails@optushome.com.au Subject: [parisc-linux] PA-RISC newbie Hi there. I just purchased at a **VERY** cheap price, a HP Visualize C-180 RISC system from a CAD drafting company, this box included a 4Gb Hard disk, a video card with unknown amount of memory (& daughter board, assuming its memory upgrade) and system board RAM is fully loaded (768Megs). I would like to run this system on Linux, and found the PA-RISC web site from the www.linux.org web site :o) The system currently has HP-UX installed, but not having any usernames or passwords, I cannot access the system from the prompt. I have read how to NFS-boot the HPbox from the message board, but I couldn't figgure out where to find the kernel sources (or how I would be able to compile them on the HPbox anyway). I downloaded the vmlinux kernel file from the ftp site and the NFS-ROOT and installed both on my current Linux box (Pentium 133 pre-MMX) in the format of how it was layed out in ... LINUX/PA-RISC NFSROOT HOWTO In there it states that you have to get the latest linux-2.3 tree from CVS, but which CVS server I'm curious about as the ones on ftp.kernel.org don't have "parisc" in the /arch/ branch, so where do I find the CVS "tree" that I need to use? I seem to have the "STEP 2." section running, as from playing with the system I had found my way into the PDC prompt and have played with the "boot" function. I tried to boot the installation CD (on a drive I have borrowed from work) of HP-UX and reinstall so I have access, as I don't really care whats currently on the system.. I'm not confident enough on how to create and burn a bootable CD to try and boot the box that way, I still think the vmlinux kernel I downloaded from the PA-RISC website has something to do with my problems (or the permissions) I do know that the Hp is talking to the Linux box (apart from the lack of logged info) I get a report in /var/log/secure and messages that the HP box has attempted a bootp session, but the HP box reports something along the lines that the booting code was not found. So, if anyone has any ideas on how to help me, I would be appreciated ;o) Oh, what *is* the RAM modules in the Hp systems anyway (apart from the obvious 64Mx72-pin SIMM) Thank you for your time and help :o) PS. I would prefer replies to my E-mail address as I generally forget to surf the net reading mailing lists.... From andrew@neep.com.au Sat, 11 Nov 2000 23:12:55 +0800 Date: Sat, 11 Nov 2000 23:12:55 +0800 From: Andrew Shugg andrew@neep.com.au Subject: [parisc-linux] HP 9000 e25 > Considering how often this question comes up is there anyone out there > that is interested in tracking down the info to port linux to this class > of box. > > Server boxes may be classed as boring to some but there seem to be a > large number of people who have at least one of them sitting about doing > nothing. > > Joe. I don't perceive the problem to be a lack of willingness, or interest, but has already been stated the older systems contain a lot of proprietry stuff that isn't sufficiently documented for people to work on. Maybe as the parisc port grows more popular and attracts more resources, some enthusiastic people will get it happening. =) Andrew. -- Andrew Shugg http://www.neep.com.au/ "Just remember, Mr Fawlty, there's always someone worse off than yourself." "Is there? Well I'd like to meet him. I could do with a good laugh." From grundler@cup.hp.com Sat, 11 Nov 2000 15:29:14 -0800 Date: Sat, 11 Nov 2000 15:29:14 -0800 From: Grant Grundler grundler@cup.hp.com Subject: [parisc-linux] HP 9000 e25 Andrew Shugg wrote: > > Considering how often this question comes up is there anyone out there > > that is interested in tracking down the info to port linux to this class > > of box. > > > > Server boxes may be classed as boring to some but there seem to be a > > large number of people who have at least one of them sitting about doing > > nothing. > > > > Joe. > > I don't perceive the problem to be a lack of willingness, or interest, but > has already been stated the older systems contain a lot of proprietry stuff > that isn't sufficiently documented for people to work on. AFIAK, the chipsets for I/O devices in E25 have plenty of documentation. The issue is someone has to clean them up and get a lawyer to approve their publication. It's all about IP and avoiding lawsuits. This has been discussed before. Any HP employees interested in doing this "on their own time" can contact me and I'll help locate unpublished docs. Note that PDC is the same for Nova-Class (EFGHI-class) boxes as for the workstations for the most part. So someone could start by just trying to boot those boxes and see how far it gets before dying. > Maybe as the parisc port grows more popular and attracts more resources, > some enthusiastic people will get it happening. =) Having worked on the HPUX SCSI driver (scsi3 and scsi1) for E25 and similar boxes, I question anyone's sanity who volunteers to write drivers for SPIFI chips - even with full documentation. I would rather give folks that interested in contributing a 715/33! (or my gosh /50's!) Yes - I know folks who collect PDP's and keep them running in their garage...'nuf said. grant Grant Grundler Unix Systems Enablement Lab +1.408.447.7253 From grundler@cup.hp.com Sat, 11 Nov 2000 15:38:58 -0800 Date: Sat, 11 Nov 2000 15:38:58 -0800 From: Grant Grundler grundler@cup.hp.com Subject: [parisc-linux] PA-RISC newbie Rod Smart wrote: > Hi there. > > I just purchased at a **VERY** cheap price, a HP Visualize C-180 > RISC system from a CAD drafting company, this box included a 4Gb Hard > disk, a video card with unknown amount of memory (& daughter board, > assuming its memory upgrade) and system board RAM is fully loaded > (768Megs). > > I would like to run this system on Linux, and found the PA-RISC web > site from the www.linux.org web site :o) > > The system currently has HP-UX installed, but not having any > usernames or passwords, I cannot access the system from the prompt. Yes you can. You just need to know how. Interrupt the boot process to get a "BOOT ADMIN" prompt (or whatever it's called - Boot Console Handler). Then "boot primary isl" (shortened to bo pri isl) You should have an "ISL>" prompt now. ISL> hpux -is And you will boot to single user state with a shell. mountall and you should have the regular tools too. vi /etc/passwd to your hearts content. "There is no such thing at security with out physical security". .. > I'm not confident enough on how to create and burn a bootable CD to > try and boot the box that way, I still think the vmlinux kernel I > downloaded from the PA-RISC website has something to do with my problems > (or the permissions) > You can dd the ISO image to a regular hard disk (ie /dev/sdc) and move that disk over to the C180. Then boot from that disk. From BCH, use "sea" to locate all boot devices. grant Grant Grundler Unix Systems Enablement Lab +1.408.447.7253 From randolph@tausq.org Sat, 11 Nov 2000 17:04:29 -0700 Date: Sat, 11 Nov 2000 17:04:29 -0700 From: Randolph Chung randolph@tausq.org Subject: [parisc-linux] glibc question I'm working with bdale and taggart to try to get the Debian glibc package to compile under hppa. One of the things I saw today while playing with this is that the build dies because it tries to link in bsd-setjmp.c and bsd-_setjmp.c, which both define setjmp. Can someone enlighten me about why this may be happening? This is built from the glibc-2.2 sources, which I understand has all/most of the changes in pehc cvs. randolph -- @..@ http://www.TauSq.org/ (----) ( >__< ) ^^ ~~ ^^ From rajak@purdue.edu Sat, 11 Nov 2000 22:58:57 -0500 (EST) Date: Sat, 11 Nov 2000 22:58:57 -0500 (EST) From: Brian Poole rajak@purdue.edu Subject: [parisc-linux] Problems booting new beta CD Hello, My machine is a 715/80 with 88M of RAM, 1G HD, external 4x CD drive & floppy. Trying to get the new palinux CD working on my 715/80 here and not having too much success. Did get the CD to actually boot, but after all the normal Linux init messages (which were very nice to see btw, congratulations on how far it has already gotten ;) it stops at 'Switching from PDC console'. Looking thru the FAQ I saw a somewhat similar question, in that it had 'pdc' in it & was booting from the CD (but the 0.1 CD, not the one I am using), that said the kernel on the CD booted from/to the serial console. Is this also true of the 0.5 CD? If so, what is necessary to boot one of these from console? I've been fooling with it to no success.. I have it automatically booting from the CD, but it doesn't actually boot. I replug in the monitor & keyboard and find that it can't boot without the keyboard ('Failed to initiliaze a keyboard\n SYSTEM HALTED').. How am I supposed to boot to the console if I can't boot w/o a keyboard? I imagine if it has a keyboard it will boot to the screen like a Sun. Thanks for the help, -b From grundler@cup.hp.com Sat, 11 Nov 2000 23:31:37 -0800 Date: Sat, 11 Nov 2000 23:31:37 -0800 From: Grant Grundler grundler@cup.hp.com Subject: [parisc-linux] Problems booting new beta CD Brian Poole wrote: ... > Looking thru the FAQ Brian, Thank you for first reading the FAQ! > I saw a somewhat similar question, in that it had > 'pdc' in it & was booting from the CD (but the 0.1 CD, not the one I am > using), that said the kernel on the CD booted from/to the > serial console. Is this also true of the 0.5 CD? I think it is. Is there a way via PALO to direct the console to FBCON or STICON or whatever it's called now? I had the impression *eventually* the boot console would be whatever PDC says it is - ie graphics console for the 712. > If so, what is necessary to boot one of these from console? kernel with CONFIG_STI_CONSOLE I think....but that's not enabled by default. It may not be possible to use the graphics console unless one builds a "custom" kernel. > I've been fooling with it to no > success.. I have it automatically booting from the CD, but it doesn't > actually boot. I replug in the monitor & keyboard and find that it can't > boot without the keyboard ('Failed to initiliaze a keyboard\n SYSTEM > HALTED').. How am I supposed to boot to the console if I can't boot w/o a > keyboard? I imagine if it has a keyboard it will boot to the screen like a > Sun. AFAIK, 712's are the only parisc workstations what won't boot w/o keyboard. All others will auto-switch to use serial console if the keyboard is not connected. Both or the above questions sounds like a FAQ. Could someone who knows more update/add those to the FAQ? thanks, grant ps. The most up-to-date FAQ is at parisc-linux.org/faq.html even though that's not officially online yet. > > Thanks for the help, > > -b > > > > --------------------------------------------------------------------------- > To unsubscribe: send e-mail to parisc-linux-request@thepuffingroup.com with > `unsubscribe' as the subject. > Grant Grundler Unix Systems Enablement Lab +1.408.447.7253 From alan@linuxcare.com.au Sun, 12 Nov 2000 23:08:35 +1100 (EST) Date: Sun, 12 Nov 2000 23:08:35 +1100 (EST) From: Alan Modra alan@linuxcare.com.au Subject: [parisc-linux] glibc question On Sat, 11 Nov 2000, Randolph Chung wrote: > I'm working with bdale and taggart to try to get the Debian glibc > package to compile under hppa. One of the things I saw today while > playing with this is that the build dies because it tries to link in > bsd-setjmp.c and bsd-_setjmp.c, which both define setjmp. Can someone > enlighten me about why this may be happening? I think bsd-_setjmp.c should define _setjmp, not setjmp. Alan Modra -- Linuxcare. Support for the Revolution. From andrew@neep.com.au Mon, 13 Nov 2000 00:40:15 +0800 Date: Mon, 13 Nov 2000 00:40:15 +0800 From: Andrew Shugg andrew@neep.com.au Subject: [parisc-linux] HP 9000 e25 Grant Grundler said: > AFIAK, the chipsets for I/O devices in E25 have plenty of > documentation. The issue is someone has to clean them up and get a > lawyer to approve their publication. My bad, I should've said "public documentation". =) *prods LC FAQ maintainers* Andrew. -- Andrew Shugg http://www.neep.com.au/ "Just remember, Mr Fawlty, there's always someone worse off than yourself." "Is there? Well I'd like to meet him. I could do with a good laugh." From randolph@tausq.org Sun, 12 Nov 2000 11:06:38 -0700 Date: Sun, 12 Nov 2000 11:06:38 -0700 From: Randolph Chung randolph@tausq.org Subject: [parisc-linux] glibc build fails / bash bug Bdale, taggart and I have been looking at trying to build glibc on hppa from Debian's sources. What we saw was that it looks like a lot of the syscalls were not being reocognized as such by one part of the build, so it tries to build things from the sysdeps/generic directory and fails. After a lot of digging, I *think* what is at fault is actually bash. It looks like during the build, a shell script (make-syscalls.sh) parses through syscalls.list to generate syscall stubs that are needed for the build to happen correctly, but these are not being generated. What it boils down to, I think, is this: (on hppa - bdale's J5K) ============================= tausq@j5k:/space/tausq $ bash --version GNU bash, version 2.04.0(1)-release (hppa-unknown-linux-gnu) Copyright 1999 Free Software Foundation, Inc. tausq@j5k:/space/tausq $ dpkg -l |grep bash ii bash 2.04-7 The GNU Bourne Again SHell tausq@j5k:/space/tausq $ cat test.sh #!/bin/sh echo "1 2 3 4 5 a b c d e " | while read a b c d e; do echo $a $b $c $d $e done tausq@j5k:/space/tausq $ /bin/bash test.sh 1 2 3 4 5 ============================= (on other archs, tested with i386 and sparc) samwise[11:06] ~% bash --version GNU bash, version 2.04.0(1)-release (i386-pc-linux-gnu) Copyright 1999 Free Software Foundation, Inc. samwise[11:06] ~% dpkg -l |grep bash ii bash 2.04-7 The GNU Bourne Again SHell samwise[11:06] ~% /bin/bash test.sh 1 2 3 4 5 a b c d e This causes the parsing routines to die quite miserably.... Anyone feel like trying to fix this? :-) randolph -- @..@ http://www.TauSq.org/ (----) ( >__< ) ^^ ~~ ^^ From pdbeal@louisville.edu Sun, 12 Nov 2000 14:27:28 -0500 Date: Sun, 12 Nov 2000 14:27:28 -0500 From: Phillip D. Beal pdbeal@louisville.edu Subject: [parisc-linux] Beta CD On Fri, Nov 10, 2000 at 05:14:06PM -0500, Paul J.Y. Lahaie wrote: > Hello fellow PA-RISCers, > > An preliminary beta CD for PA/Linux has been uploaded to > puffin.external.hp.com. If people could try it and forward any complaints > or suggestions to me, it would be greatly appreciated. The URL for the > image is: ftp://puffin.external.hp.com/pub/parisc/cd-images/palinux-0.5.iso.gz > > - Paul The kernel dumps on an HP755. Actually, how do you make these CD's? I know how to use mkisofs to crerat a filesystem CD, but how you make it bootable with a kernel image? Thanks, -- Phillip Beal Electrical and Computer Engineering S+LUG Vice-President From bame@riverrock.org Sun, 12 Nov 2000 13:27:32 -0700 Date: Sun, 12 Nov 2000 13:27:32 -0700 From: bame@riverrock.org bame@riverrock.org Subject: [parisc-linux] glibc build fails / bash bug = After a lot of digging, I *think* what is at fault is actually bash. Bash has a bunch of 'set' options, some shell variables, and probably some compile-time configure options, which affect its behavior, so I'd compare all those. One possibility is that the bash configure script on hppa configures bash to be more like Posix, since that's what hp-ux shell users expect. The construct in question: echo "a b c 1 2 3" | while read x1 x2 x3 *depends* on the way echo breaks or doesn't break lines, and the way read parses them. Often scripts like that also depend on whether the shell actually makes a new subprocess for the 'while' or it doesn't, because that determines whether variables set in the loop will still be set on exit from the loop. While I didn't find a way to make the construction fail, a safer method (when you get a choice) is to use 'set': set -- a b c \ 1 2 3 while [ $# != 0 ] do echo $1 $2 $3 shift 3 done -Paul "too much shell programming" Bame From bame@riverrock.org Sun, 12 Nov 2000 17:25:45 -0700 Date: Sun, 12 Nov 2000 17:25:45 -0700 From: bame@riverrock.org bame@riverrock.org Subject: [parisc-linux] kernel merge Helge noticed SCSI fails (B160L, 712, I think it's ok on c3k) after the -test10 merge. We have MANY differences from Linus in the SCSI area. Anybody want to take a look at this? FYI to get the pre-merge kernel you can use LINUS_240_TEST10_PREMERGE. Beware that tags are sticky in CVS (use cvs update -A to fix that). -P From catfish@alltel.net Sun, 12 Nov 2000 19:05:21 -0600 Date: Sun, 12 Nov 2000 19:05:21 -0600 From: catfish@alltel.net catfish@alltel.net Subject: [parisc-linux] Project Dead???? Hello, Its been so long since I've had an email I was curious if this has become a Dead project? Just curious. Terry -- catfish: icq #20116127 From bame@riverrock.org Sun, 12 Nov 2000 18:15:07 -0700 Date: Sun, 12 Nov 2000 18:15:07 -0700 From: bame@riverrock.org bame@riverrock.org Subject: [parisc-linux] Project Dead???? = Hello, = Its been so long since I've had an email I was curious if this has = become a Dead project? You might want to check the e-mail archives to see what you've been missing. I don't know why you haven't been receiving anything. The project is quite alive. http://www.parisc-linux.org/lists.html -P From bame@riverrock.org Sun, 12 Nov 2000 19:20:50 -0700 Date: Sun, 12 Nov 2000 19:20:50 -0700 From: bame@riverrock.org bame@riverrock.org Subject: [parisc-linux] kernel merge = = Helge noticed SCSI fails (B160L, 712, I think it's ok on c3k) = after the -test10 merge. Fixed. From test6 to test10 the SCSI host registration method changed. Updated sim700.c, lasi7xx.h, zalon7xx.h -P From grundler@cup.hp.com Sun, 12 Nov 2000 21:34:08 -0800 Date: Sun, 12 Nov 2000 21:34:08 -0800 From: Grant Grundler grundler@cup.hp.com Subject: [parisc-linux] Problems booting new beta CD Brian Poole wrote: > Quoting Grant Grundler (grundler@cup.hp.com) from 11 November 2000: > > Is there a way via PALO to direct the console to FBCON or STICON or > > whatever it's called now? > > > > I had the impression *eventually* the boot console would be whatever PDC > > says it is - ie graphics console for the 712. > > Working on a 715 here.. notice you refer to 712s throughout, hopefully we are > on the same page. Maybe 712s are identical to 715s, I don't have any idea, > just noticed the irregularity. For the most part yes. I had just assumed you were using a 712. > I meant to say 'from serial console' or something of the sort.. Serial console should just work. Shouldn't need an HIL keyboard connected though. > > > > I've been fooling with it to no > > > success.. I have it automatically booting from the CD, but it doesn't > > > actually boot. I replug in the monitor & keyboard and find that it can't > > > boot without the keyboard ('Failed to initiliaze a keyboard\n SYSTEM > > > HALTED').. How am I supposed to boot to the console if I can't boot w/o a > > > keyboard? I imagine if it has a keyboard it will boot to the screen like > a > > > Sun. > > > > AFAIK, 712's are the only parisc workstations what won't boot w/o keyboard. > > All others will auto-switch to use serial console if the keyboard > > is not connected > > Hmmm.. so I have manually switch it to use serial console? No. Just disconnect the keyboard before powering on the machine. Should end up with console on the serial interface. You may want to set the keyboard/console path to the serial port. This can be done from "BOOT_ADMIN>" prompt. The default kernel has "CONFIG_HIL=y". But since I don't test on boxes with HIL interfaces, I have no idea if a keyboard is required since the driver is enabled. It sounds like a bug if the 715 can't boot from serial console w/o HIL keyboard. grant Grant Grundler Unix Systems Enablement Lab +1.408.447.7253 From dhazeghi@pacbell.net Sun, 12 Nov 2000 21:34:19 -0800 Date: Sun, 12 Nov 2000 21:34:19 -0800 From: dhazeghi@pacbell.net dhazeghi@pacbell.net Subject: [parisc-linux] [Semi OT] SOM Linker Hello, I have been watching this project for some time and wanted to thank you guys for all the great work so far. The recent announcement of a BETA CD is highly encouraging. However I would like to know what work if any has been done on the SOM linker which HP released to the public last November(?). It seems that as of right now, it has not been touched since February 14, and the FSF binutils snapshots still do not have any SOM support for ld. Has there been any movement in merging this in, or is anybody working on this? Thanks. Dara Hazeghi From deller@gmx.de Mon, 13 Nov 2000 08:32:54 +0100 Date: Mon, 13 Nov 2000 08:32:54 +0100 From: Helge Deller deller@gmx.de Subject: [parisc-linux] kernel merge On Monday 13 November 2000 03:20, bame@riverrock.org wrote: > = > = Helge noticed SCSI fails (B160L, 712, I think it's ok on c3k) > = after the -test10 merge. > > Fixed. > > >From test6 to test10 the SCSI host registration method changed. > Updated sim700.c, lasi7xx.h, zalon7xx.h > > -P Thanks Paul, sim700 (53c710) now works again, but the second built-in controller (ncr/sym 53c8xx) still doesn't. Greetings, Helge From rhirst@linuxcare.com Mon, 13 Nov 2000 10:24:03 +0000 Date: Mon, 13 Nov 2000 10:24:03 +0000 From: Richard Hirst rhirst@linuxcare.com Subject: [parisc-linux] BEWARE: Makefile changed from parisc to parisc64 Confused me for a while, anyway. If you cvs update your kernel source and expect to build a 32 bit kernel, you need to edit the top level Makefile to change the arch := line. Richard From rhirst@linuxcare.com Mon, 13 Nov 2000 12:13:49 +0000 Date: Mon, 13 Nov 2000 12:13:49 +0000 From: Richard Hirst rhirst@linuxcare.com Subject: [parisc-linux] kernel merge On Fri, Nov 10, 2000 at 02:28:33PM -0700, bame@riverrock.org wrote: > drivers/scsi sym53c8xx_comm.h #ifdef doesn't work on parisc -- eliminates > unmap_pci_mem() causing link error (TODO - rhirst) Fixed. This relates to NVRAM that some PCI scsi cards have to hold config settings over reboot. CONFIG_SCSI_NCR53C8XX_NVRAM_DETECT is normally defined in sym53c8xx_defs.h to turn that code on. When I implemented Zalon (FWD) support I guessed that the 53c720 h/w wouldn't have NVRAM implemented the same way, and turned off NVRAM detect. I've also replaced a chunk of Zalon specific code that got lost in the merge, so Zalon/FWD/53c720 support works again. There is a problem remaining when using the driver as a module; it looks like something is trying to printk() from a string in the module after the module has been removed. Havn't tracked that down yet. Richard From adevries@linuxcare.com Mon, 13 Nov 2000 13:50:24 -0500 Date: Mon, 13 Nov 2000 13:50:24 -0500 From: Alex deVries adevries@linuxcare.com Subject: [parisc-linux] [Semi OT] SOM Linker dhazeghi@pacbell.net wrote: > However I would like to know what work if any has been done on the SOM > linker which HP released to the public last November(?). It seems that > as of right now, it has not been touched since February 14, and the FSF > binutils snapshots still do not have any SOM support for ld. Has there > been any movement in merging this in, or is anybody working on this? The initial plan was to do our 32-bit userspace with SOM, worrying about ELF32 much later in the game. But ELF32 development happened a lot quicker than expected, and so nobody's really done much on the SOM linker. I suspect it'd be very hard to use the SOM linker code to incorporate it into binutils, but I could be wrong. What are you actually trying to do? - Alex -- Alex deVries, Principal Solutions Architect, The Puffins at Linuxcare 613.562.2759 tel alex@linuxcare.com, http://www.linuxcare.com/ Linuxcare, Support for the revolution. From deller@gmx.de Mon, 13 Nov 2000 23:54:29 +0100 Date: Mon, 13 Nov 2000 23:54:29 +0100 From: Helge Deller deller@gmx.de Subject: sym53c8xx-driver (was: Re: [parisc-linux] kernel merge) On Monday 13 November 2000 13:13, Richard Hirst wrote: > On Fri, Nov 10, 2000 at 02:28:33PM -0700, bame@riverrock.org wrote: > > drivers/scsi sym53c8xx_comm.h #ifdef doesn't work on parisc -- eliminates > > unmap_pci_mem() causing link error (TODO - rhirst) > > Fixed. This relates to NVRAM that some PCI scsi cards have to hold > config settings over reboot. CONFIG_SCSI_NCR53C8XX_NVRAM_DETECT > is normally defined in sym53c8xx_defs.h to turn that code on. When > I implemented Zalon (FWD) support I guessed that the 53c720 h/w > wouldn't have NVRAM implemented the same way, and turned off > NVRAM detect. > > I've also replaced a chunk of Zalon specific code that got lost in > the merge, so Zalon/FWD/53c720 support works again. > > There is a problem remaining when using the driver as a module; > it looks like something is trying to printk() from a string in > the module after the module has been removed. Havn't tracked > that down yet. > > Richard Hi Richard, I'm sorry to say that the sym53c8xx still doesn't work on my B160L (32 bit-Kernel). It looks like the controller isn't detected at all, while it worked perfectly with 2.4.0-test6. Would you mind to take a look at the code again ? Thanks, Helge. From rhirst@linuxcare.com Mon, 13 Nov 2000 23:27:52 +0000 Date: Mon, 13 Nov 2000 23:27:52 +0000 From: Richard Hirst rhirst@linuxcare.com Subject: sym53c8xx-driver (was: Re: [parisc-linux] kernel merge) Hi Helge, The problem I fixed related to the ncr53c8xx driver (which shares code with sym53c8xx), and was to make 53c720 support work again. sym53c8xx worked for me on my A180. Please can you try booting with sym53c8xx=verb:7,debug:0xffff and send me the output? Thanks, Richard On Mon, Nov 13, 2000 at 11:54:29PM +0100, Helge Deller wrote: > On Monday 13 November 2000 13:13, Richard Hirst wrote: > > On Fri, Nov 10, 2000 at 02:28:33PM -0700, bame@riverrock.org wrote: > > > drivers/scsi sym53c8xx_comm.h #ifdef doesn't work on parisc -- eliminates > > > unmap_pci_mem() causing link error (TODO - rhirst) > > > > Fixed. This relates to NVRAM that some PCI scsi cards have to hold > > config settings over reboot. CONFIG_SCSI_NCR53C8XX_NVRAM_DETECT > > is normally defined in sym53c8xx_defs.h to turn that code on. When > > I implemented Zalon (FWD) support I guessed that the 53c720 h/w > > wouldn't have NVRAM implemented the same way, and turned off > > NVRAM detect. > > > > I've also replaced a chunk of Zalon specific code that got lost in > > the merge, so Zalon/FWD/53c720 support works again. > > > > There is a problem remaining when using the driver as a module; > > it looks like something is trying to printk() from a string in > > the module after the module has been removed. Havn't tracked > > that down yet. > > > > Richard > > > Hi Richard, > > I'm sorry to say that the sym53c8xx still doesn't work on my B160L (32 > bit-Kernel). It looks like the controller isn't detected at all, while it > worked perfectly with 2.4.0-test6. > Would you mind to take a look at the code again ? > > Thanks, > Helge. > From deller@gmx.de Tue, 14 Nov 2000 01:13:58 +0100 Date: Tue, 14 Nov 2000 01:13:58 +0100 From: Helge Deller deller@gmx.de Subject: sym53c8xx-driver (was: Re: [parisc-linux] kernel merge) --------------Boundary-00=_ABNZX5KGKOOFAA0B1BIM Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 8bit Subject: On Tuesday 14 November 2000 00:27, Richard Hirst wrote: > Hi Helge, > The problem I fixed related to the ncr53c8xx driver (which shares > code with sym53c8xx), and was to make 53c720 support work again. > sym53c8xx worked for me on my A180. Please can you try booting > with > > sym53c8xx=verb:7,debug:0xffff > > and send me the output? > > Thanks, > Richard Hi Richard, the output and the relevant part of .config is attached. Greetings, Helge --------------Boundary-00=_ABNZX5KGKOOFAA0B1BIM Content-Type: text/plain; name="log1" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="log1" Ci5jb25maWc6IAotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tCiMKIyBT Q1NJIHN1cHBvcnQKIwpDT05GSUdfU0NTST15CkNPTkZJR19CTEtfREVWX1NEPXkKQ09ORklHX1NE X0VYVFJBX0RFVlM9NDAKIyBDT05GSUdfQ0hSX0RFVl9TVCBpcyBub3Qgc2V0CkNPTkZJR19CTEtf REVWX1NSPXkKQ09ORklHX0JMS19ERVZfU1JfVkVORE9SPXkKQ09ORklHX1NSX0VYVFJBX0RFVlM9 MgpDT05GSUdfQ0hSX0RFVl9TRz15CkNPTkZJR19TQ1NJX01VTFRJX0xVTj15CkNPTkZJR19TQ1NJ X0NPTlNUQU5UUz15CgojCiMgU0NTSSBsb3ctbGV2ZWwgZHJpdmVycwojCkNPTkZJR19TQ1NJX0xB U0k9eQpDT05GSUdfU0NTSV9aQUxPTj15CkNPTkZJR19TQ1NJX1NZTTUzQzhYWD15CkNPTkZJR19T Q1NJX05DUjUzQzhYWF9ERUZBVUxUX1RBR1M9OApDT05GSUdfU0NTSV9OQ1I1M0M4WFhfTUFYX1RB R1M9MzIKQ09ORklHX1NDU0lfTkNSNTNDOFhYX1NZTkM9MjAKIyBDT05GSUdfU0NTSV9OQ1I1M0M4 WFhfUFJPRklMRSBpcyBub3Qgc2V0CiMgQ09ORklHX1NDU0lfTkNSNTNDOFhYX0lPTUFQUEVEIGlz IG5vdCBzZXQKCgotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0KCmJvb3QtbG9nOgotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tCgpGaXJtd2FyZSBWZXJzaW9uICA2LjEKCkR1cGxleCBDb25zb2xlIElPIERlcGVuZGVu dCBDb2RlIChJT0RDKSByZXZpc2lvbiAxCgpNZW1vcnkgVGVzdC9Jbml0aWFsaXphdGlvbiBDb21w bGV0ZWQgCgotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0KICAgKGMpIENvcHlyaWdodCAxOTk1LTE5OTgs IEhld2xldHQtUGFja2FyZCBDb21wYW55LCBBbGwgcmlnaHRzIHJlc2VydmVkCi0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLQoKICBQcm9jZXNzb3IgICBTcGVlZCAgICAgICAgICAgIFN0YXRlICAgICAgICAg ICBDb3Byb2Nlc3NvciBTdGF0ZSAgQ2FjaGUgU2l6ZQogIC0tLS0tLS0tLSAgLS0tLS0tLS0gICAt LS0tLS0tLS0tLS0tLS0tLS0tLS0gIC0tLS0tLS0tLS0tLS0tLS0tICAtLS0tLS0tLS0tCiAgICAg IDAgICAgICAxNjAgTUh6ICAgIEFjdGl2ZSAgICAgICAgICAgICAgICAgRnVuY3Rpb25hbCAgICAg ICAgICA2NCBLQgogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgIDEgTUIgZXh0CgoKICBBdmFpbGFibGUgbWVtb3J5IChieXRl cykgICAgOiAgNTM2ODcwOTEyIAogIEdvb2QgbWVtb3J5IHJlcXVpcmVkIChieXRlcyk6ICA1MzY4 NzA5MTIgCgogIFByaW1hcnkgYm9vdCBwYXRoOiAgICBGV1NDU0kuNi4wCiAgQWx0ZXJuYXRlIGJv b3QgcGF0aDogIExBTi4wLjAuMC4wLjAuMAogIENvbnNvbGUgcGF0aDogICAgICAgICBHUkFQSElD UygyKQogIEtleWJvYXJkIHBhdGg6ICAgICAgICBQUzIKCkNQVSAwCldBUk5JTkc6ICBTZWxmIHRl c3RzIGhhdmUgYmVlbiBkaXNhYmxlZCBhcyBhIHJlc3VsdCBvZiBGQVNUQk9PVAogICAgICAgICAg YmVpbmcgZW5hYmxlZC4gIFRvIGVuYWJsZSBzZWxmIHRlc3RzLCB1c2UgdGhlIEZBU1RCT09UCiAg ICAgICAgICBjb21tYW5kIGluIHRoZSBDT05GSUdVUkFUSU9OIG1lbnUgYW5kIHJlYm9vdCB0aGUg c3lzdGVtLgoKCi0tLS0tLS0gTWFpbiBNZW51IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0KCiAgICAgICAgQ29tbWFuZCAgICAgICAg ICAgICAgICAgICAgICAgICBEZXNjcmlwdGlvbgogICAgICAgIC0tLS0tLS0gICAgICAgICAgICAg ICAgICAgICAgICAgLS0tLS0tLS0tLS0KICAgICAgICBCT290IFtQUkl8QUxUfDxwYXRoPl0gICAg ICAgICAgIEJvb3QgZnJvbSBzcGVjaWZpZWQgcGF0aAogICAgICAgIFBBdGggW1BSSXxBTFR8Q09O fEtFWV0gWzxwYXRoPl0gRGlzcGxheSBvciBtb2RpZnkgYSBwYXRoCiAgICAgICAgU0VBcmNoIFtE SXNwbGF5fElQTF0gWzxwYXRoPl0gICBTZWFyY2ggZm9yIGJvb3QgZGV2aWNlcwoKICAgICAgICBD T25maWd1cmF0aW9uIFs8Y29tbWFuZD5dICAgICAgIEFjY2VzcyBDb25maWd1cmF0aW9uIG1lbnUv Y29tbWFuZHMKICAgICAgICBJTmZvcm1hdGlvbiBbPGNvbW1hbmQ+XSAgICAgICAgIEFjY2VzcyBJ bmZvcm1hdGlvbiBtZW51L2NvbW1hbmRzCiAgICAgICAgU0VSdmljZSBbPGNvbW1hbmQ+XSAgICAg ICAgICAgICBBY2Nlc3MgU2VydmljZSBtZW51L2NvbW1hbmRzCgogICAgICAgIERJc3BsYXkgICAg ICAgICAgICAgICAgICAgICAgICAgUmVkaXNwbGF5IHRoZSBjdXJyZW50IG1lbnUKICAgICAgICBI RWxwIFs8bWVudT58PGNvbW1hbmQ+XSAgICAgICAgIERpc3BsYXkgaGVscCBmb3IgbWVudSBvciBj b21tYW5kCiAgICAgICAgUkVTRVQgICAgICAgICAgICAgICAgICAgICAgICAgICBSZXN0YXJ0IHRo ZSBzeXN0ZW0KLS0tLS0tLQpNYWluIE1lbnU6IEVudGVyIGNvbW1hbmQgPiBibyBsYW4KSW50ZXJh Y3Qgd2l0aCBJUEwgKFksIE4sIFEpPz4gbgoKQm9vdGluZy4uLiAKTmV0d29yayBTdGF0aW9uIEFk ZHJlc3MgMDgwMDA5LWVmMzRmNQpTeXN0ZW0gSVAgQWRkcmVzcyAxOTIuMTY4LjEwMC4xNjAKU2Vy dmVyIElQIEFkZHJlc3MgMTkyLjE2OC4xMDAuMTAwCgpCb290IElPIERlcGVuZGVudCBDb2RlIChJ T0RDKSByZXZpc2lvbiAyCgoKSEFSRCBCb290ZWQuCnBhbG8gaXBsIHJvb3RAUDEwMCBUaHUgTm92 ICAyIDIwOjE0OjA4IE1FVCAyMDAwCjAvdm1saW51eCAyMjc0NzcxIGJ5dGVzIEAgMHg2ODAwCjAv cGFsby1jbWRsaW5lICcwL3ZtbGludXggSE9NRT0vIFRFUk09TElOVVggcm9vdD0vZGV2L25mcyBu ZnNyb290PTE5Mi4xNjguMTAwLjEwMDovdGZ0cGJvb3QvbmZzcm9vdCBjb25zb2xlPXR0eSBzeW01 M2M4eHg9dmVyYjo3LGRlYnVnOjB4ZmZmZicKS2VybmVsOiBwYXJ0aXRpb24gMCBmaWxlIC92bWxp bnV4CkVMRjMyIGV4ZWN1dGFibGUKCkVudHJ5IDAwMTAwMTkwIGZpcnN0IDAwMTAwMDAwIG4gNApT ZWdtZW50IDAgbG9hZCAwMDEwMDAwMCBzaXplIDE1MzQ2NjggbWVkaWFwdHIgMHgxMDAwClNlZ21l bnQgMSBsb2FkIDAwMjc4MDAwIHNpemUgMTgyMzQ0IG1lZGlhcHRyIDB4MTc4MDAwClNlZ21lbnQg MiBsb2FkIDAwMmE4MDAwIHNpemUgMTM5MTMyIG1lZGlhcHRyIDB4MWE1MDAwClNlZ21lbnQgMyBs b2FkIDAwMmNjMDAwIHNpemUgODE5MiBtZWRpYXB0ciAweDFjNzAwMApicmFuY2hpbmcgdG8ga2Vy bmVsIGVudHJ5IHBvaW50IDB4MDAxMDAxOTAKU2V0IGRlZmF1bHQgUFNXIFcgYml0IHRvIDAKUERD IENvbnNvbGUgSW5pdGlhbGl6ZWQKVGhlIDMyLWJpdCBLZXJuZWwgaGFzIHN0YXJ0ZWQuLi4KRW5h YmxlZCBGUCBjb3Byb2Nlc3NvcgpGcmVlIG1lbW9yeSBzdGFydHMgYXQ6IDB4YzAyZmQwMDAKc3Rh cnRfcGFyaXNjKDB4NTA0ZDZjLDB4NTA0ZDZjLDB4MCwweDApClBBTE8gY29tbWFuZCBsaW5lOiAn SE9NRT0vIFRFUk09TElOVVggcm9vdD0vZGV2L25mcyBuZnNyb290PTE5Mi4xNjguMTAwLjEwMDov dGZ0cGJvb3QvbmZzcm9vdCBjb25zb2xlPXR0eSBzeW01M2M4eHg9dmVyYjo3LGRlYnVnOjB4ZmZm ZicKUEFMTyBpbml0cmQgMC0wCm1vZGVsICAgMDAwMDUwMjAgMDAwMDA0ODEgMDAwMDAwMDAgMDIw MjAyMDIgNzc5NGQ3ZmUgMTAwMDAwZjAgMDAwMDAwMDQgMDAwMDAwYmEgMDAwMDAwYmEKdmVycyAg ICAwMDAwMDAwOApjcHVpZCAgIDAwMDAwMWU4CkNQVUlEIHZlcnMgMTUgcmV2IDgKU2VhcmNoaW5n IGZvciBkZXZpY2VzIGluIFBEQyBmaXJtd2FyZS4uLiBwcm9jZXNzb3IgaHBhIDB4ZmZmYmUwMDAK YSBuZXdlciBib3guLi4KRm91bmQgZGV2aWNlczoKMS4gUGhhbnRvbSBQc2V1ZG9CQyBHU0MrIFBv cnQgKDcpIGF0IDB4ZmZjMDAwMDAsIHZlcnNpb25zIDB4NTA0LCAweDAsIDB4MCwgMHgwLCAweDAK Mi4gTWVybGluIDE2MCBDb3JlIEZXLVNDU0kgKDQpIGF0IDB4ZmZmOGMwMDAsIHZlcnNpb25zIDB4 M2QsIDB4MCwgMHg4OSwgMHgwLCAweDgwCjMuIE1lcmxpbiBMMiAxNjAgKDkwMDAvNzc4L0IxNjBM KSAoMCkgYXQgMHhmZmZiZTAwMCwgdmVyc2lvbnMgMHg1MDIsIDB4MCwgMHg0LCAweDAsIDB4ODEK NC4gTWVybGluIDE2MC9UaHVuZGVySGF3ayBNZW1vcnkgKDEpIGF0IDB4ZmZmYmYwMDAsIHZlcnNp b25zIDB4NjcsIDB4MCwgMHg5LCAweDAsIDB4MAo1LiBNZXJsaW4gMTYwIENvcmUgQkEgKDExKSBh dCAweGZmZDAwMDAwLCB2ZXJzaW9ucyAweDNkLCAweDAsIDB4ODEsIDB4MCwgMHgwCjYuIE1lcmxp biAxNjAgQ29yZSBSUy0yMzIgKDEwKSBhdCAweGZmZDA1MDAwLCB2ZXJzaW9ucyAweDNkLCAweDAs IDB4OGMsIDB4MCwgMHgwCjcuIE1lcmxpbiAxNjAgQ29yZSBTQ1NJICgxMCkgYXQgMHhmZmQwNjAw MCwgdmVyc2lvbnMgMHgzZCwgMHgwLCAweDgyLCAweDAsIDB4MAo4LiBNZXJsaW4gMTYwIENvcmUg TGFuICg4MDIuMykgKDEwKSBhdCAweGZmZDA3MDAwLCB2ZXJzaW9ucyAweDNkLCAweDAsIDB4OGEs IDB4MCwgMHgwCjkuIE1lcmxpbiAxNjAgQ29yZSBDZW50cm9uaWNzICgxMCkgYXQgMHhmZmQwMjAw MCwgdmVyc2lvbnMgMHgzZCwgMHgwLCAweDc0LCAweDAsIDB4MAoxMC4gTWVybGluIDE2MCBDb3Jl IEF1ZGlvICgxMCkgYXQgMHhmZmQwNDAwMCwgdmVyc2lvbnMgMHgzZCwgMHg0LCAweDdiLCAweDAs IDB4MAoxMS4gTWVybGluIDE2MCBDb3JlIFBDIEtleWJvYXJkICgxMCkgYXQgMHhmZmQwODAwMCwg dmVyc2lvbnMgMHgzZCwgMHgwLCAweDg0LCAweDAsIDB4MAoxMi4gTWVybGluIDE2MCBDb3JlIFBD IEtleWJvYXJkICgxMCkgYXQgMHhmZmQwODEwMCwgdmVyc2lvbnMgMHgzZCwgMHgwLCAweDg0LCAw eDAsIDB4MAoxMy4gTWVybGluIDE2MCBXYXggQkEgKDExKSBhdCAweGZmZTAwMDAwLCB2ZXJzaW9u cyAweDQxLCAweDAsIDB4OGUsIDB4MCwgMHgwCjE0LiBNZXJsaW4gMTYwIFdheCBFSVNBIEJBICgx MSkgYXQgMHhmYzAwMDAwMCwgdmVyc2lvbnMgMHg0MSwgMHgwLCAweDkwLCAweDAsIDB4MAoxNS4g TWVybGluIDE2MCBXYXggSElMICgxMCkgYXQgMHhmZmUwMTAwMCwgdmVyc2lvbnMgMHg0MSwgMHgw LCAweDczLCAweDAsIDB4MAoxNi4gTWVybGluIDE2MCBXYXggUlMtMjMyICgxMCkgYXQgMHhmZmUw MjAwMCwgdmVyc2lvbnMgMHg0MSwgMHgwLCAweDhjLCAweDAsIDB4MAoxNy4gQ29yYWwgU0dDIEdy YXBoaWNzICgxMCkgYXQgMHhmNDAwMDAwMCwgdmVyc2lvbnMgMHg0LCAweDAsIDB4NzcsIDB4MCwg MHgwCjE4LiBHZWNrbyBHU0MgQ29yZSBHcmFwaGljcyAoMTApIGF0IDB4ZjgwMDAwMDAsIHZlcnNp b25zIDB4MTYsIDB4MCwgMHg4NSwgMHgwLCAweDAKMTkuIERpbm8gUENJIEJyaWRnZSAoMTMpIGF0 IDB4ZmZmODAwMDAsIHZlcnNpb25zIDB4NjgwLCAweDAsIDB4YSwgMHgwLCAweDAKVGhhdCdzIGEg dG90YWwgb2YgMTkgZGV2aWNlcy4KQ1BVKHMpOiAxIHggUEE3MzAwTEMgKFBDWC1MMikgYXQgMTYw LjAwMDAwMCBNSHoKTGludXggdmVyc2lvbiAyLjQuMC10ZXN0MTAgKHJvb3RAUDEwMCkgKGdjYyB2 ZXJzaW9uIDIuOTYgMjAwMDA5MjUgKGV4cGVyaW1lbnRhbCkpICMxNSBUdWUgTm92IDE0IDAxOjAx OjMzIE1FVCAyMDAwCmZyZWVfYm9vdG1lbSgweDMwMTAwMCwgMHgxZmNmZjAwMCkKaW5pdHJkOiAw MDAwMDAwMC0wMDAwMDAwMApwYWdldGFibGVfaW5pdApPbiBub2RlIDAgdG90YWxwYWdlczogMTMx MDcyCnpvbmUoMCk6IDY1NTM2IHBhZ2VzLgp6b25lKDEpOiA2NTUzNiBwYWdlcy4Kem9uZSgyKTog MCBwYWdlcy4KS2VybmVsIGNvbW1hbmQgbGluZTogSE9NRT0vIFRFUk09TElOVVggcm9vdD0vZGV2 L25mcyBuZnNyb290PTE5Mi4xNjguMTAwLjEwMDovdGZ0cGJvb3QvbmZzcm9vdCBjb25zb2xlPXR0 eSBzeW01M2M4eHg9dmVyYjo3LGRlYnVnOjB4ZmZmZgp0cmFwX2luaXQKQ29uc29sZTogY29sb3Vy IGR1bW15IGRldmljZSA4MHgyNQpyZWdpc3Rlcl9jb25zb2xlCkNhbGlicmF0aW5nIGRlbGF5IGxv b3AuLi4gMTA2LjUwIEJvZ29NSVBTCk1lbW9yeTogNTEwOTQ0ayBhdmFpbGFibGUKRGVudHJ5LWNh Y2hlIGhhc2ggdGFibGUgZW50cmllczogNjU1MzYgKG9yZGVyOiA3LCA1MjQyODggYnl0ZXMpCkJ1 ZmZlci1jYWNoZSBoYXNoIHRhYmxlIGVudHJpZXM6IDMyNzY4IChvcmRlcjogNSwgMTMxMDcyIGJ5 dGVzKQpQYWdlLWNhY2hlIGhhc2ggdGFibGUgZW50cmllczogMTMxMDcyIChvcmRlcjogNywgNTI0 Mjg4IGJ5dGVzKQpJbm9kZS1jYWNoZSBoYXNoIHRhYmxlIGVudHJpZXM6IDMyNzY4IChvcmRlcjog NiwgMjYyMTQ0IGJ5dGVzKQpQT1NJWCBjb25mb3JtYW5jZSB0ZXN0aW5nIGJ5IFVOSUZJWApMYXNp IHZlcnNpb24gMCBhdCAweGZmZDAwMDAwIGZvdW5kLgpXYXggYXQgMHhmZmUwMDAwMCBmb3VuZC4K V2F4OiBISUwgS2V5Ym9hcmQtTk1JIHJlZ2lzdGVyZWQuCnBhcnBvcnQwOiBQQy1zdHlsZSBhdCAw eGZmZDAyODAwLCBpcnEgODggW1BDU1BQLFRSSVNUQVRFXQpGb3VuZCBpODI1OTYgYXQgMHhmZmQw NzAwMCwgSVJRIDg3CmVhcmx5IGluaXRpYWxpemF0aW9uIG9mIGRldmljZSBldGgwIGlzIGRlZmVy cmVkCkluaXRpYWxpemluZyBMYXNpIFBTLzIta2V5Ym9hcmQgcG9ydCBhdCAweGZmZDA4MDAwLi4u ClN1cHBvcnQgZm9yIExhc2kgUFMvMi1wc2F1eCBub3QgeWV0IGF2YWlsYWJsZSAhCkZvdW5kIEhJ TCBhdCAweGZmZTAxMDAwLCBJUlEgMTI2Ck5vIGhhbmRsZXIgZm9yIGludGVycnVwdCAzNSAhCkhJ TDogdGltZWQgb3V0LCBhc3N1bWluZyBubyBrZXlib2FyZCBwcmVzZW50LgpXYXJuaW5nIDogZGV2 aWNlICgxMCwgMHg0MSwgMHgwLCAweDczLCAweDApIE5PVCBjbGFpbWVkIGJ5IEhJTCA3MTIsIDcx NSBvciBzaW1pbGlhcgpEaW5vIHZlcnNpb24gMi4wIChicmlkZ2UgbW9kZSkgZm91bmQgYXQgMHhm ZmY4MDAwMAoKClRoZSBHU0N0b1BDSSAoRGlubyBocmV2IDApIGJ1cyBjb252ZXJ0ZXIgZm91bmQg bWF5IGV4aGliaXQKZGF0YSBjb3JydXB0aW9uLiAgU2VlIFNlcnZpY2UgTm90ZSBOdW1iZXJzOiBB NDE5MEEtMDEsIEE0MTkxQS0wMS4KU3lzdGVtcyBzaGlwcGVkIGFmdGVyIEF1ZyAyMCwgMTk5NyB3 aWxsIG5vdCBleGhpYml0IHRoaXMgcHJvYmxlbS4KTW9kZWxzIGFmZmVjdGVkOiBDMTgwLCBDMTYw LCBDMTYwTCwgQjE2MEwsIGFuZCBCMTMyTCB3b3Jrc3RhdGlvbnMuCgpkaW5vX2JyaWRnZV9pbml0 OiBJT19BRERSX0VOIGhhc24ndCBiZWVuIGNvbmZpZ3VyZWQuCmtlcm5lbCBCVUcgYXQgZGluby5j OjY0NiEKTGludXggTkVUNC4wIGZvciBMaW51eCAyLjQKQmFzZWQgdXBvbiBTd2Fuc2VhIFVuaXZl cnNpdHkgQ29tcHV0ZXIgU29jaWV0eSBORVQzLjAzOQpTdGFydGluZyBrc3dhcGQgdjEuOApzdGlm Yi5jOiBzZWFyY2hpbmcgZm9yIHdvcmQgbW9kZSBTVEkgUk9Ncwpmb3VuZCBwb3RlbnRpYWwgU1RJ IFJPTSBhdCBmNDAwMDAwMApTVEkgYnl0ZSBtb2RlIFJPTSBhdCBmNDAwMDAwMCwgaWdub3JlZApm b3VuZCBwb3RlbnRpYWwgU1RJIFJPTSBhdCBmODAwMDAwMApwdHk6IDI1NiBVbml4OTggcHR5cyBj b25maWd1cmVkCmxwMDogdXNpbmcgcGFycG9ydDAgKGludGVycnVwdC1kcml2ZW4pLgpSQU1ESVNL IGRyaXZlciBpbml0aWFsaXplZDogMTYgUkFNIGRpc2tzIG9mIDQwOTZLIHNpemUgMTAyNCBibG9j a3NpemUKZXRoMDogODI1OTYgYXQgMHhmZmQwNzAwMCwgMDggMDAgMDkgRUYgMzQgRjUgSVJRIDg3 Lgo4MjU5Ni5jICRSZXZpc2lvbjogMS4xNCAkClNlcmlhbCBkcml2ZXIgdmVyc2lvbiA1LjAyICgy MDAwLTA4LTA5KSB3aXRoIE1BTllfUE9SVFMgU0hBUkVfSVJRIFNFUklBTF9QQ0kgZW5hYmxlZAp0 dHlTMDAgYXQgaW9tZW0gMHhmZmQwNTgwMCAoaXJxID0gOTApIGlzIGEgMTY1NTBBCnR0eVMwMSBh dCBpb21lbSAweGZmZTAyODAwIChpcnEgPSAxMjEpIGlzIGEgMTY1NTBBCkdlbmVyaWMgUlRDIERy aXZlciB2MS4wMiAwNS8yNy8xOTk5IFNhbSBDcmVhc2V5IChzYW1teUBvaC52ZXJpby5jb20pClND U0kgc3Vic3lzdGVtIGRyaXZlciBSZXZpc2lvbjogMS4wMApzaW03MDA6IENvbmZpZ3VyaW5nIDUz YzcxMCAoU0NTSS1JRCA3KSBhdCBmZmQwNjEwMCwgSVJRIDg2CnNjc2kwOiBSZXZpc2lvbiAweDIK UG9zdCB0ZXN0MSwgaXN0YXQgMDEsIHNzdGF0MCAwMCwgZHN0YXQgODQKc2ltNzAwOiBXQVJOSU5H IElSUSBwcm9iZSBmYWlsZWQsIChyZXR1cm5lZCAwKQpzY3NpMDogR29vZCwgdGFyZ2V0IGRhdGEg YXJlYXMgYXJlIGRtYSBjb2hlcmVudApzY3NpMDogdGVzdCAxIGNvbXBsZXRlZCBvay4Kc2NzaTA6 IHNpbTcwMF9pbnRyX2hhbmRsZSgpIGNhbGxlZCB3aXRoIG5vIGludGVycnVwdApzY3NpMCA6IExB U0kvU2ltcGxlIDUzYzd4eAogIFZlbmRvcjogUElPTkVFUiAgIE1vZGVsOiBDRC1ST00gRFItVTEy WCAgICBSZXY6IDEuMDYKICBUeXBlOiAgIENELVJPTSAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgQU5TSSBTQ1NJIHJldmlzaW9uOiAwMgpEZXRlY3RlZCBzY3NpIENELVJPTSBzcjAgYXQgc2Nz aTAsIGNoYW5uZWwgMCwgaWQgMCwgbHVuIDAKc3IwOiBzY3NpMy1tbWMgZHJpdmU6IDEyeC8xMngg eGEvZm9ybTIgY2RkYSB0cmF5ClVuaWZvcm0gQ0QtUk9NIGRyaXZlciBSZXZpc2lvbjogMy4xMQpz ZWFyY2hpbmcgZm9yIHdvcmQgbW9kZSBTVEkgUk9Ncwpmb3VuZCBwb3RlbnRpYWwgU1RJIFJPTSBh dCBmNDAwMDAwMApTVEkgYnl0ZSBtb2RlIFJPTSBhdCBmNDAwMDAwMCwgaWdub3JlZApmb3VuZCBw b3RlbnRpYWwgU1RJIFJPTSBhdCBmODAwMDAwMApzZWFyY2hpbmcgZm9yIGJ5dGUgbW9kZSBTVEkg Uk9Ncwpmb3VuZCBwb3RlbnRpYWwgU1RJIFJPTSBhdCBmNDAwMDAwMApTVEkgYnl0ZSBtb2RlIFJP TSB0eXBlIDEKIHN1cHBvcnRzIDE1IG1vbml0b3JzCiBjb25mb3JtcyB0byBTVEkgUk9NIHNwZWMg cmV2aXNpb24gOC4wNwpkdW1wX3N0aV9yb206IDUwMAogZ3JhcGhpY3MgaWQgMmQwOGMwYTcwOWEw MjU4NwpkdW1wX3N0aV9yb206IDUxMAogZm9udCBzdGFydCAwMDAxODNjMwpkdW1wX3N0aV9yb206 IDUxMgogcmVnaW9uIGxpc3QgMDAwMTgzNjMKZHVtcF9zdGlfcm9tOiA1MTQKIGluaXRfZ3JhcGgg MDAwMDFhNjMKZHVtcF9zdGlfcm9tOiA1MTYKIGFsdGVybmF0ZSBjb2RlIHR5cGUgMApkdW1wX3N0 aV9yb206IDUxOApuZXh0IGZvbnQgMDAwMDQwNDAKZjQwMDAwMDAgYgpmODAwMDAwMCBiClN3aXRj aGluZyBmcm9tIFBEQyBjb25zb2xlCg== --------------Boundary-00=_ABNZX5KGKOOFAA0B1BIM-- From rhirst@linuxcare.com Tue, 14 Nov 2000 10:17:04 +0000 Date: Tue, 14 Nov 2000 10:17:04 +0000 From: Richard Hirst rhirst@linuxcare.com Subject: sym53c8xx-driver (was: Re: [parisc-linux] kernel merge) Hi Helge, On Tue, Nov 14, 2000 at 01:13:58AM +0100, Helge Deller wrote: > On Tuesday 14 November 2000 00:27, Richard Hirst wrote: > > Hi Helge, > > The problem I fixed related to the ncr53c8xx driver (which shares > > code with sym53c8xx), and was to make 53c720 support work again. > > sym53c8xx worked for me on my A180. Please can you try booting > > with > > > > sym53c8xx=verb:7,debug:0xffff > > > > and send me the output? > > > > Thanks, > > Richard > > > Hi Richard, > > the output and the relevant part of .config is attached. > > Greetings, > > Helge Thanks. I agree it doesn't look like the driver is even seeing the chip; I wonder if PCI support is broken... > dino_bridge_init: IO_ADDR_EN hasn't been configured. > kernel BUG at dino.c:646! Does it usually say that on bootup? Richard From matthew@wil.cx Tue, 14 Nov 2000 10:29:36 +0000 Date: Tue, 14 Nov 2000 10:29:36 +0000 From: Matthew Wilcox matthew@wil.cx Subject: [parisc-linux] kernel merge On Fri, Nov 10, 2000 at 02:28:33PM -0700, bame@riverrock.org wrote: > fcntl.h acquired a 'struct fcntl64' used with 64-bit offsets, implementing > fcntl(fd, F_S/GETLK[W]64, ...). Several other locking-related #defines added. > > We'll need to add the getdents64() and fcntl64() syscall glue. (TODO!!!) actually, we don't. Linux/PA-RISC has sufficiently wide data types already so we don't have the grot required in other ports to support the appropriate wide data types. > looks like maybe the get/put_user_ret() functions in asm/uaccess.h are > obsolete? (TODO) yes, they are. exterminate! exterminate! -- Revolutions do not require corporate support. From deller@gmx.de Tue, 14 Nov 2000 14:11:42 +0100 (MET) Date: Tue, 14 Nov 2000 14:11:42 +0100 (MET) From: Helge Deller deller@gmx.de Subject: sym53c8xx-driver (was: Re: [parisc-linux] kernel merge) > Hi Helge, > > On Tue, Nov 14, 2000 at 01:13:58AM +0100, Helge Deller wrote: > > On Tuesday 14 November 2000 00:27, Richard Hirst wrote: > > > Hi Helge, > > > The problem I fixed related to the ncr53c8xx driver (which shares > > > code with sym53c8xx), and was to make 53c720 support work again. > > > sym53c8xx worked for me on my A180. Please can you try booting > > > with > > > > > > sym53c8xx=verb:7,debug:0xffff > > > > > > and send me the output? > > > > > > Thanks, > > > Richard > > > > > > Hi Richard, > > > > the output and the relevant part of .config is attached. > > > > Greetings, > > > > Helge > > Thanks. I agree it doesn't look like the driver is even seeing the > chip; I wonder if PCI support is broken... > > > dino_bridge_init: IO_ADDR_EN hasn't been configured. > > kernel BUG at dino.c:646! > > Does it usually say that on bootup? Yep. Has always been there, but nevertheless the scsi-driver worked before. FYI: The non-pci sim700-driver also didn't showed up before pb fixed it in CVS with a few one-line-patches. NB: Could maybe someone (ggg?) explain me the kernel-bug mentioned above ? > > Richard > Greetings, Helge -- Sent through GMX FreeMail - http://www.gmx.net From grundler@cup.hp.com Tue, 14 Nov 2000 08:10:42 -0800 Date: Tue, 14 Nov 2000 08:10:42 -0800 From: Grant Grundler grundler@cup.hp.com Subject: [parisc-linux] dino maintainer? Anyone interested in maintaining Dino? I don't have time for it and all the docs are on the web. One of the "TODO" things is to convert dino.c to use struct pci_hba the same way lba_pci.c does.... Richard Hirst wrote: ... > Thanks. I agree it doesn't look like the driver is even seeing the > chip; I wonder if PCI support is broken... > > > dino_bridge_init: IO_ADDR_EN hasn't been configured. > > kernel BUG at dino.c:646! > > Does it usually say that on bootup? per Helge's request: The bug is normal for card-mode Dino - not for Built-in Dino. I think Helge has the GSC 100BT card which is a card-mode Dino on-board with one (or two) Tulip(s) behind it. The warning is a reminder one can NOT use MMIO accesses to those PCI devices and *only* I/O Port space (eg inb/outb). If someone wants to fix the warning so it's quiet for card-mode devices...see is_card_dino(d) in dino_driver_callback() for an example. FYI - card-mode dino was used for several different networking interfaces but not SCSI interfaces. hope this helps, grant Grant Grundler Unix Systems Enablement Lab +1.408.447.7253 From bame@noam.fc.hp.com Tue, 14 Nov 2000 09:35:01 -0700 Date: Tue, 14 Nov 2000 09:35:01 -0700 From: Paul Bame bame@noam.fc.hp.com Subject: [parisc-linux] CVS linux Vs. -test10 I've attached an overview of differences between our CVS linux sources following the -test10 merge and the upstream -test10 sources. This document is also at http://puffin.external.hp.com/~bame/diff.html The raw 'diff' output (now a bit out of date) is at http://puffin.external.hp.com/~bame/diff.out If anyone gets bored, this list is full of small (and not so small) tasks which range from very simple (drivers/block/rd.c) to fairly complex (scripts/*). -P palinux Vs. linux 2.4.0-test10 Here's a brief summary of the differences in common code between palinux (tag: LINUS_240_TEST10_MERGED) and the upstream -test10 sources. The full diff output is in diff.out. NOTE this does not include machine-depend differences * Minor changes in several locations to support GSC * Minor top-level Makefile hacks, though the CFLAGS one is quite important. * Lots of RCS $Revision$ differences in ACPI (a different 'cvs import' would've eliminated these differences). * drivers/block/rd.c: obsolete debug code for parisc64. Changed a constant from 0xffffffffL to 0xffffffffUL because of a parisc64 gcc bug initializing longs. The repaired code is probably "more correct" anyway. * drivers/char/Config.in: changes to support LASI, parisc real-time clock (CONFIG_GENRTC) * drivers/char/Makefile: Config-related changes to support HP keyboards and RTC * drivers/char/console.c: looks like dead or dying experimental parisc code -- probably should be removed. Also some parisc-specific comments and format changes which should disappear. * drivers/char/serial.c: support for GSC and A500 serial * drivers/net/Makefile,Space.c: mostly LASI LAN support * drivers/net/eepro100.c: no clue about this one * drivers/net/tulip/interrupt.c: workaround for a B180+busy-lan boot problem -- probably should be sent upstream. * drivers/net/tulip/tulip_core.c: required #ifdef for hppa, also printk() changes which appear valid * drivers/parport/Makefile: GSC * drivers/parport/parport_gsc.c: New file for palinux -- GSC parallel ports -- required * drivers/pci/pci.c: eh? Grant? * drivers/pci/setup-bus.c: function definition tweek -- Grant? * drivers/scsi: Lots of changes here -- rhirst? See for yourself. Basics: support LASI and Zalon scsi, changes to 53c8xx drivers, rename sim7x0 to sim710 * drivers/sound: support for HP "Harmony" sound * drivers/video: STI and HP FB video drivers (iodccon is probably worthless) * fs: add support for SOM executables * fs/binfmt_elf.c,exec.c: changes for stack-grows-up? * fs/nfs/read.c: probably unnecessary hack for broken parisc64 gcc * fs/proc/array.c: ?? something with signals ?? * fs/stat.c: added __hppa__ to several #ifdefs * include/linux/binfmts.h,fs.h,kernel.h,tty.h,udf_fs_sb.h: unnecessary differences? * include/linux/init.h: we use different section names -- why????, probably some unnecessary other differences too * include/linux/mm.h: VM_STACK_FLAGS difference -- jsm? * include/linux/wait.h: parisc debugging -- should be removed * init/main.c: KWDB and GSC support plus a bunch of stuff which should probably go away. * kernel/Makefile,dma.c,fork.c,printk.c: eh? * kernel/module.c: possible parisc-needed changes * kernel/signal.c: unknown signal-related differences * lib/inflate.c: changed some constants to work around parisc64 gcc bug * mm/mprotect.c: ? * scripts/*: MANY differences here. Looks like a combination of things we hacked to fix configuration problems plus MAYBE not updating these files from new Linux versions in the past. 'make menuconfig' is significantly different from upstream. Even the mkdep.c program is different. From bame@noam.fc.hp.com Tue, 14 Nov 2000 10:02:06 -0700 Date: Tue, 14 Nov 2000 10:02:06 -0700 From: Paul Bame bame@noam.fc.hp.com Subject: [parisc-linux] kernel merge = On Fri, Nov 10, 2000 at 02:28:33PM -0700, bame@riverrock.org wrote: = > fcntl.h acquired a 'struct fcntl64' used with 64-bit offsets, implementing = > fcntl(fd, F_S/GETLK[W]64, ...). Several other locking-related #defines add ed. = > = > We'll need to add the getdents64() and fcntl64() syscall glue. (TODO!!!) = = actually, we don't. Linux/PA-RISC has sufficiently wide data types = already so we don't have the grot required in other ports to support = the appropriate wide data types. Ok that sounds great but I need a clue how to see it. struct flock contains an off_t which is 32 bits on narrow (wide too at the moment, but that will probably change). Also, struct dirent contains a 32-bit inode and a __kernel_off_t offset (d_off), which is also 32 bits narrow. I did see the ... in our fcntl() syscall definition so I'll go check glibc to see what's happening there. I wouldn't be so picky except that I need to write the 32/64 syscall translators for these soon! Thanks! -P From bame@noam.fc.hp.com Tue, 14 Nov 2000 10:14:51 -0700 Date: Tue, 14 Nov 2000 10:14:51 -0700 From: Paul Bame bame@noam.fc.hp.com Subject: [parisc-linux] kernel merge = On Fri, Nov 10, 2000 at 02:28:33PM -0700, bame@riverrock.org wrote: = > fcntl.h acquired a 'struct fcntl64' used with 64-bit offsets, implementing = > fcntl(fd, F_S/GETLK[W]64, ...). Several other locking-related #defines add ed. = > = > We'll need to add the getdents64() and fcntl64() syscall glue. (TODO!!!) = = actually, we don't. Linux/PA-RISC has sufficiently wide data types = already so we don't have the grot required in other ports to support = the appropriate wide data types. Oh, and won't we have to support these syscalls anyway, because user programs will make them? I suppose we could #define them in libc headers. = > looks like maybe the get/put_user_ret() functions in asm/uaccess.h are = > obsolete? (TODO) = = yes, they are. exterminate! exterminate! Done From pdbeal@louisville.edu Tue, 14 Nov 2000 13:40:24 -0500 Date: Tue, 14 Nov 2000 13:40:24 -0500 From: Phillip D. Beal pdbeal@louisville.edu Subject: [parisc-linux] 735/755 and Kernel test10.. Hey, I've been working on the 735 and 755 that I has access to and so far the systems booted the test6 kernel, but scrambled the console as soon as init was run. So, I figured I'd try the new test10 kernel that you have added. Both system boot, and then stop at this line: branching to kernel entry point 0x00100000 Can't select default wide mode, PDC_PSW call does not work What does the above actually mean? How can I remove the PDC_PSW call from the kernel so it can boot? I have plans to test this new kernel image on a 715 later today. Thanks, -- Phillip Beal Electrical and Computer Engineering S+LUG Vice-President From grundler@cup.hp.com Tue, 14 Nov 2000 10:51:26 -0800 Date: Tue, 14 Nov 2000 10:51:26 -0800 From: Grant Grundler grundler@cup.hp.com Subject: [parisc-linux] 735/755 and Kernel test10.. "Phillip D. Beal" wrote: > Hey, > > I've been working on the 735 and 755 that I has access to and so far > the systems booted the test6 kernel, but scrambled the console as soon > as init was run. So, I figured I'd try the new test10 kernel that you > have added. Both system boot, and then stop at this line: > > branching to kernel entry point 0x00100000 > Can't select default wide mode, PDC_PSW call does not work Did you build this kernel yourself? If so, it sounds like you built a 64-bit kernel since that's the default. You need to change the ARCH line in the linux/Makefile to read "parisc" instead of "parisc64". grant > > What does the above actually mean? How can I remove the PDC_PSW call > from the kernel so it can boot? I have plans to test this new kernel > image on a 715 later today. > > Thanks, > -- > Phillip Beal > Electrical and Computer Engineering > S+LUG Vice-President > > --------------------------------------------------------------------------- > To unsubscribe: send e-mail to parisc-linux-request@thepuffingroup.com with > `unsubscribe' as the subject. > Grant Grundler Unix Systems Enablement Lab +1.408.447.7253 From grundler@cup.hp.com Tue, 14 Nov 2000 11:08:20 -0800 Date: Tue, 14 Nov 2000 11:08:20 -0800 From: Grant Grundler grundler@cup.hp.com Subject: [parisc-linux] 735/755 and Kernel test10.. Grant Grundler wrote: > If so, it sounds like you built a 64-bit kernel since that's the default. Correction. *was* the default. default ARCH was changed last night to parisc. grant Grant Grundler Unix Systems Enablement Lab +1.408.447.7253 From ian.zink@maryville.com Tue, 14 Nov 2000 13:20:05 -0600 Date: Tue, 14 Nov 2000 13:20:05 -0600 From: Ian Zink ian.zink@maryville.com Subject: [parisc-linux] Palinux on a 712/60 I have a hp 712/60 I was trying to get loaded with Pa-linux. I'm using the 0.5 version of the Pa-linux cd. If I boot right off the CD it all loads until it gets to Switching to PDC. At that point nothing happens. From I have read the list, that is because the kernel is switching the text console. However, the 712s don't have consoles. From what I have also read the CD should work if you pass the kernel the parameter console=tty. So I tried to "boot scsi.2.0 isl" from the boot_admin prompt. It gave me the PALO ISL, but I could not choose which line I wanted to edit. Further, I couldn't even type "b" to boot. I don't know if the isl is freezing or what is taking place What I am wondering is there a way to boot a 712/80 without having to get cross-compiler gcc, compile the kernel, etc. Is there someway I could add the ramdisk-sti.tgz on the ISO to make it work? If so, what would need to be done? Thanks, Ian Zink, Systems Engineer Maryville Technologies 540 Maryville Centre, Suite 300 St. Louis, MO 63141 636/519-4182 (FAX) 636/519-4141 ian.zink@maryville.com www.maryville.com From mang@subcarrier.org Tue, 14 Nov 2000 14:17:35 -0500 Date: Tue, 14 Nov 2000 14:17:35 -0500 From: Michael Ang mang@subcarrier.org Subject: linux bame bame@riverrock.org wrote: > > = On Thu, Nov 09, 2000 at 03:53:48PM -0700, Paul Bame wrote: > = > Somebody never imported 2.4.0-test6, then I imported -test10 on the mai > n > = > vendor branch and now can't (easily) undo that to import test6 and THEN > = > test10. This workaround sucks. If the sources on the linus branch have been religiously tagged every time they're updated, then reverting to a previous would have been relatively painless. I'm not sure what "this workaround" was, but I guess at this point test10 is merged so the point is moot. > = don't use vendor branches. didn't you talk to mang about this? > > Um, I have no information to go on from your note. All the (successful) > merges I've done before have used the cookbook CVS merge method including > a vendor branch. Several (N-1?) of the palinux merges have been > accompanied by updating the vendor branch. And this merge is going > well despite the ugly workaround, or so it appears to me. Just > importing files to a vendor branch should have no effect on anything > else unless CVS has some horrible bug (RCS does not). Before I make > what is apparently a serious mistake ("don't use vendor branches" sounds > pretty serious) please enlighten me! Vendor branches are evil. (When I say "vendor branch" I mean the special kind of branch created by "cvs import".) When you check in to a vendor branch your changes will also be seen on the trunk, *unless* that file has been previously modified on the trunk. This is almost never what you want and adds confusion during merging (when you least want it). Tracking third-party sources using a normal branch, as we are doing, is much simpler and gives you more control. When I did the original import of Linus' sources I converted the vendor branch to a normal branch using cvs admin magic. So none of the annoyances of vendor branches should affect us, as long as any new files are added on the linus branch using "cvs add", NOT "cvs import". When you say you "I imported -test10 on the main vendor branch" I hope you really mean that you used "cvs add" on the linus branch. From your other messages, your tags looked good. - Mike. From bame@noam.fc.hp.com Tue, 14 Nov 2000 13:00:41 -0700 Date: Tue, 14 Nov 2000 13:00:41 -0700 From: Paul Bame bame@noam.fc.hp.com Subject: linux bame = bame@riverrock.org wrote: = > = > = On Thu, Nov 09, 2000 at 03:53:48PM -0700, Paul Bame wrote: = > = > Somebody never imported 2.4.0-test6, then I imported -test10 on the mai = > n = > = > vendor branch and now can't (easily) undo that to import test6 and THEN = > = > test10. This workaround sucks. = = If the sources on the linus branch have been religiously tagged every = time they're updated, then reverting to a previous would have been = relatively painless. I'm not sure what "this workaround" was, but I = guess at this point test10 is merged so the point is moot. Like the comment said, there was no copy of plain -test6 in CVS (that I saw). Without -test6 in CVS it's much harder to use cvs diff to figure out the right way to merge files when there are conflicts. I didn't realize this until -test10 was already there, so I *then* brought in -test6. They're in the wrong order on the 1.1.1 branch, so the standard merge command 'cvs -jlinus:yesterday -jlinus:' won't work next time -- explicit names will be required. = Vendor branches are evil. (When I say "vendor branch" I mean the = special kind of branch created by "cvs import".) When you check in to a = vendor branch your changes will also be seen on the trunk, *unless* that = file has been previously modified on the trunk. Thanks for clarifying what "evil" means! That is pretty ugly indeed! = This is almost never = what you want and adds confusion during merging (when you least want = it). Tracking third-party sources using a normal branch, as we are = doing, is much simpler and gives you more control. But I've seen no cook book for it. I'm guessing that instead of cvs import you use: cvs co -rlinus linux cd linux cvs commit (make note of new files from commit) cvs add cvs commit cvs tag LINUS_NEW_REVISION perhaps with provision for removing obsolete files too. I suppose that is simpler than a single cvs import command from a certain perspective :-) = When I did the original import of Linus' sources I converted the vendor = branch to a normal branch using cvs admin magic. So none of the = annoyances of vendor branches should affect us, as long as any new files = are added on the linus branch using "cvs add", NOT "cvs import". Have you a pointer to the magic or the knowledge to recreate it? I had no idea there was a special RCS marking for the evil type of branch. = When you say you "I imported -test10 on the main vendor branch" I hope = you really mean that you used "cvs add" on the linus branch. From your = other messages, your tags looked good. I used "cvs import", and either your branch magic worked, or I finished the merge before anybody randomly updated from cvs. Since import used 1.1.1, which is the branch you "fixed", it seems possible that 'cvs import' might be rendered harmless but I don't know that for sure. -P From pjlahaie@linuxcare.com Tue, 14 Nov 2000 15:43:00 -0500 Date: Tue, 14 Nov 2000 15:43:00 -0500 From: Paul J.Y. Lahaie pjlahaie@linuxcare.com Subject: [parisc-linux] Beta CD --SkvwRMAIpAhPCcCJ Content-Type: text/plain; charset=us-ascii Content-Disposition: inline This is to answer all the questions about sti console. Currently, in the CVS tree, serial console and STI console cannot be turned on at the same time. This means that a choice between serial/sti needs to be done at compile time. At the time we cut the beta, it was decided that serial console was more important than sti console. I am also working on resolving the problem with STI/serial console and once I have a fix ready, I will make a kernel image available. The current beta CD is also expecting a console on ttyS0 and does not currently open a ttyx getty. When I have a kernel that can decide the console at runtime, I will look into the beta CD issues. If you have any more questions or suggestions, feel free to email me or post on this list. Thank you. - Paul --SkvwRMAIpAhPCcCJ Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.4 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE6EaPR8ggPQthPCzcRAhT8AKC8EU8yusyoEvPHxKAQsaM0vMGthwCgnbbC Yz6ZWjq3q9B80bI+YRxc8xo= =HhRZ -----END PGP SIGNATURE----- --SkvwRMAIpAhPCcCJ-- From raj@cerias.purdue.edu Tue, 14 Nov 2000 16:18:06 -0500 Date: Tue, 14 Nov 2000 16:18:06 -0500 From: Brian Poole raj@cerias.purdue.edu Subject: [parisc-linux] Beta CD Sounds like a plan to me. I don't suppose you know how to make a 715 boot to console? Pulling the keyboard and monitor cables off the back just make it stop at boot with the unable to initiliaze keyboard error I posted with earlier. I am assuming there is some sort of boot_admin trickery necessary, but I am unaware of what it might entail and my poking around has yielded nothing.. Any advice here would be much appreciated. -b Quoting Paul J.Y. Lahaie (pjlahaie@linuxcare.com) from 14 November 2000: > with STI/serial console and once I have a fix ready, I will make a kernel > image available. The current beta CD is also expecting a console on .. > If you have any more questions or suggestions, feel free to email me or > post on this list. Thank you. From dave@hiauly1.hia.nrc.ca Tue, 14 Nov 2000 16:40:52 -0500 (EST) Date: Tue, 14 Nov 2000 16:40:52 -0500 (EST) From: John David Anglin dave@hiauly1.hia.nrc.ca Subject: abort in eliminate_regs compiling glob.c from glibc > > Breakpoint 2, eliminate_regs_in_insn (insn=0x406a0ba0, replace=0) > > at ../../gcc/reload1.c:2826 > > 2826 if (! insn_is_asm && icode < 0) > > (gdb) p debug_rtx (insn) > > (insn/s 2711 2709 2719 (set (reg:SI 6 %r6) > > (reg:SI 28 %r28)) 69 {pre_ldw-4} (insn_list 2708 (insn_list:REG_DEP_ANTI 2696 (insn_list:REG_DEP_ANTI 2702 (insn_list:REG_DEP_ANTI 2697 (nil))))) > > (expr_list:REG_DEAD (reg:SI 28 %r28) > > (insn_list:REG_RETVAL 2708 (expr_list:REG_EQUAL (expr_list (use (mem:BLK (scratch) 0)) > > (expr_list (symbol_ref/v:SI ("@strlen")) > > (expr_list (reg/v:SI 4 %r4) > > (nil)))) > > (nil))))) > > The `use' arises from the `__pure__' attribute in the prototype for strlen: > > extern size_t strlen (__const char *__s) __attribute__ ((__pure__)); Here is a patch to fix the abort in eliminate_regs when it encounters a USE. As I understand the situation, there are three conditions needed to trigger it: 1) A function that contains insns with an eliminable register. 2) The function must call __builtin_alloca to change the frame size from its initial size. 3) After the call to __builtin_alloca, there must be a call to a pure function. With the enclosed patch, I can now build glibc for hppa-linux with -O3 optimisation. Please review carefully because I will be the first to admit that I don't understand why the use is there in the first place and all the details of what eliminate_reg does. Dave -- J. David Anglin dave.anglin@nrc.ca National Research Council of Canada (613) 990-0752 (FAX: 952-6605) 2000-11-14 John David Anglin * reload1.c (eliminate_regs): Don't abort on MEM USEs. --- reload1.c.orig Wed Sep 27 14:27:23 2000 +++ reload1.c Tue Nov 14 16:01:56 2000 @@ -2499,6 +2499,10 @@ return x; case USE: + /* Handle insn_list USE that a call to a pure functions may generate. */ + new = eliminate_regs (XEXP (x, 0), 0, insn); + if (GET_CODE (new) == MEM) + return XEXP (new, 0); case CLOBBER: case ASM_OPERANDS: case SET: From grundler@cup.hp.com Tue, 14 Nov 2000 14:32:00 -0800 Date: Tue, 14 Nov 2000 14:32:00 -0800 From: Grant Grundler grundler@cup.hp.com Subject: [parisc-linux] Palinux on a 712/60 Ian Zink wrote: > I have a hp 712/60 I was trying to get loaded with Pa-linux. I'm using the > 0.5 version of the Pa-linux cd. If I boot right off the CD it all loads > until it gets to Switching to PDC. At that point nothing happens. From I > have read the list, that is because the kernel is switching the text > console. However, the 712s don't have consoles. 712s have consoles. They have two outputs which can be used as console by linux. The STI consoles (VGA-like spigot) and serial. Connect a serial cable 9600-8-n-1 and run minicom at the other end. > From what I have also read > the CD should work if you pass the kernel the parameter console=tty. So I > tried to "boot scsi.2.0 isl" from the boot_admin prompt. It gave me the > PALO ISL, but I could not choose which line I wanted to edit. Further, I > couldn't even type "b" to boot. I don't know if the isl is freezing or what > is taking place That's a different problem...pb? > What I am wondering is there a way to boot a 712/80 without having > to get cross-compiler gcc, compile the kernel, etc. The CD was intended to also work on the 712 even though we may not have tested on it. > Is there someway I could > add the ramdisk-sti.tgz on the ISO to make it work? If so, what would need > to be done? no clue. anyone else? grant Grant Grundler Unix Systems Enablement Lab +1.408.447.7253 From mang@subcarrier.org Tue, 14 Nov 2000 17:31:22 -0500 Date: Tue, 14 Nov 2000 17:31:22 -0500 From: Michael Ang mang@subcarrier.org Subject: [parisc-linux] tracking third-party sources (was Re: linux bame) Paul Bame wrote: > > = bame@riverrock.org wrote: > = > > = > = On Thu, Nov 09, 2000 at 03:53:48PM -0700, Paul Bame wrote: > = > = > Somebody never imported 2.4.0-test6, then I imported -test10 on the > mai > = > n > = > = > vendor branch and now can't (easily) undo that to import test6 and > THEN > = > = > test10. This workaround sucks. > = > Like the comment said, there was no copy of plain -test6 in CVS (that I > saw). Without -test6 in CVS it's much harder to use cvs diff to figure > out the right way to merge files when there are conflicts. > I didn't realize this until -test10 was already there, so I *then* > brought in -test6. They're in the wrong order on the 1.1.1 branch, so > the standard merge command 'cvs -jlinus:yesterday -jlinus:' > won't work next time -- explicit names will be required. The best thing to do is to import -test10 again and move the static tag by re-tagging. > = Tracking third-party sources using a normal branch, as we are > = doing, is much simpler and gives you more control. > > But I've seen no cook book for it. I'm guessing that instead of cvs import > you use: > cvs co -rlinus linux > > cd linux > cvs commit (make note of new files from commit) > cvs add > cvs commit > cvs tag LINUS_NEW_REVISION > perhaps with provision for removing obsolete files too. I suppose that is > simpler than a single cvs import command from a certain perspective :-) I had a good chat with Paul about this, and we worked out that using "import" is marginally better. This is what the add/remove method would look like: cvs co -rlinux linux cvs rm cvs add cvs commit cvs tag LINUS_NEW_REVISION Add the import method: cd linux cvs import linux linus LINUS_NEW_REVISION cvs admin -b > = When you say you "I imported -test10 on the main vendor branch" I hope > = you really mean that you used "cvs add" on the linus branch. From your > = other messages, your tags looked good. > > I used "cvs import", and either your branch magic worked, or I finished the > merge before anybody randomly updated from cvs. Since import used 1.1.1, > which is the branch you "fixed", it seems possible that 'cvs import' might > be rendered harmless but I don't know that for sure. Using "import" to bring in new files taints them with the vendor branch badness. These files should be adjusted using "cvs admin -b". Note that "cvs admin" works directly on files in the repository at low level (without any revisioning of changes) and is thus to be avoided if at all possible. Please don't run "cvs admin" if you (the collective "you") don't know the consequences. - Mike. From ian.zink@maryville.com Tue, 14 Nov 2000 17:08:33 -0600 Date: Tue, 14 Nov 2000 17:08:33 -0600 From: Ian Zink ian.zink@maryville.com Subject: [parisc-linux] Palinux on a 712/60 Thanks for the reply, Grant. However, the 712s do not have a serial console. They do have a com port, but it does not work as a console, unfortunately. So I need do need to get a STI enabled kernel. I dropped Paul Lahaie a note to see if he could send me such a kernel so I do not have to create the entire cross-platform development environment just to boot one of these 712s. After I get it, I plan on expanding the 0.5 iso and making a new one using the STI console kernel. Ian From kailasr@webcash.com Tue, 14 Nov 2000 14:58:55 -0800 Date: Tue, 14 Nov 2000 14:58:55 -0800 From: Kailashnath V Rampure kailasr@webcash.com Subject: [parisc-linux] Boot command I have booted HP A class server through network. On that I have repartioned the system and followed the steps on http://www.parisc-linux.org/install.html. I have used the following command to initialize the hard disk. The kernel I have downloaded is vmlinux-20001018. and cpied it to /mnt/boot/vmlinux after mounting /dev/sda3. I have used the following command to initialize the HDD. palo -I -k /boot/vmlinux -b /boot/iplboot \ -c '3/boot/vmlinux TERM=linux HOME=/ root=/dev/sda3' \ /dev/sda -------------------------------- I get the following error: -------------------------------- SOFT Boot. palo ipl bame@noam Tue oct 31 14:18:02 MST 2000 0/vmlinux 2138614 bytes@ 0x1f78c000 0/palo-cmdline '3/boot/vmlinux TERM=linux HOME=/ root=/dev/sda3' /dev/ida1 82 62 1030688 /dev/ida2 f0 1030750 24738 /dev/ida3 83 1055488 1030750 Kernel:partition 3 file /boot/vmlinux ext2 block size 1024 ext2_mount(partition 3) returns 0 ext2_open(/boot/vmlinux) = -1 open /boot/vmlinux failed ------------------------------------- Please suggest. From grundler@cup.hp.com Tue, 14 Nov 2000 15:18:10 -0800 Date: Tue, 14 Nov 2000 15:18:10 -0800 From: Grant Grundler grundler@cup.hp.com Subject: [parisc-linux] Palinux on a 712/60 Ian Zink wrote: > Thanks for the reply, Grant. However, the 712s do not have a serial console. > They do have a com port, but it does not work as a console, unfortunately. It does for linux. That's what the "Switching from PDC Console" is about. Connect the serial cable to the com port and look at the output. I've done it in the past and know it worked at least once. I haven't tried it with the lasted ISO - no time to play w/712's now. > So I need do need to get a STI enabled kernel. I dropped Paul Lahaie a note > to see if he could send me such a kernel... Paul just sent mail to the list indicating he's working on console issues. Please let him work on it. Trust me, he'll tell us when he's done. :^) grant From dhazeghi@pacbell.net Tue, 14 Nov 2000 18:17:39 -0800 Date: Tue, 14 Nov 2000 18:17:39 -0800 From: dhazeghi@pacbell.net dhazeghi@pacbell.net Subject: [parisc-linux] [Semi OT] SOM Linker Alex deVries wrote: > dhazeghi@pacbell.net wrote: > > However I would like to know what work if any has been done on the SOM > > linker which HP released to the public last November(?). It seems that > > as of right now, it has not been touched since February 14, and the FSF > > binutils snapshots still do not have any SOM support for ld. Has there > > been any movement in merging this in, or is anybody working on this? > > The initial plan was to do our 32-bit userspace with SOM, worrying about > ELF32 much later in the game. But ELF32 development happened a lot > quicker than expected, and so nobody's really done much on the SOM > linker. That's what it looked like... > > > I suspect it'd be very hard to use the SOM linker code to incorporate it > into binutils, but I could be wrong. > > What are you actually trying to do? I would like to be able to set up a cross compilation environment for hpux and 32 bit PA-RISC. However without a functional cross linker, this is impossible to do, and as binutils has not got one yet, I thought perhaps the one that HP open-sourced might be some use. It would seem logical that with the sources available, it shouldn't be too difficult to fix the broken bits and get a SOM linker working in binutils, but that doesn't seem to have happened yet. Oh well, thanks for the info... Dara Hazeghi From dave@hiauly1.hia.nrc.ca Tue, 14 Nov 2000 22:00:25 -0500 (EST) Date: Tue, 14 Nov 2000 22:00:25 -0500 (EST) From: John David Anglin dave@hiauly1.hia.nrc.ca Subject: [parisc-linux] [Semi OT] SOM Linker > I would like to be able to set up a cross compilation environment for hpux and > 32 bit PA-RISC. However without a functional cross linker, this is impossible > to do, and as binutils has not got one yet, I thought perhaps the one that HP > open-sourced might be some use. It would seem logical that with the sources > available, it shouldn't be too difficult to fix the broken bits and get a SOM > linker working in binutils, but that doesn't seem to have happened yet. Oh > well, thanks for the info... You should be able to build cross compilation tools under hpux for hppa-linux. First you should install native versions of binutils and gcc under hpux (this assumes that you have the hpux C compiler and linker). The release version of gcc (2.95.2) would be a good choice. The standard hpux linker works fine with gcc/gas for C compilations. Then follow the directions at www.parisc-linux.org for building the cross compilation tools and linux. Dave -- J. David Anglin dave.anglin@nrc.ca National Research Council of Canada (613) 990-0752 (FAX: 952-6605) From dhazeghi@pacbell.net Tue, 14 Nov 2000 21:23:41 -0800 Date: Tue, 14 Nov 2000 21:23:41 -0800 From: dhazeghi@pacbell.net dhazeghi@pacbell.net Subject: [parisc-linux] [Semi OT] SOM Linker John David Anglin wrote: > > I would like to be able to set up a cross compilation environment for hpux and > > 32 bit PA-RISC. However without a functional cross linker, this is impossible > > to do, and as binutils has not got one yet, I thought perhaps the one that HP > > open-sourced might be some use. It would seem logical that with the sources > > available, it shouldn't be too difficult to fix the broken bits and get a SOM > > linker working in binutils, but that doesn't seem to have happened yet. Oh > > well, thanks for the info... > > You should be able to build cross compilation tools under hpux for hppa-linux. > First you should install native versions of binutils and gcc under hpux (this > assumes that you have the hpux C compiler and linker). The release version of > gcc (2.95.2) would be a good choice. The standard hpux linker works fine with > gcc/gas for C compilations. Then follow the directions at www.parisc-linux.org > for building the cross compilation tools and linux. This is not precisely what I mean. What I should have said is that I want to create a cross compiler --host=i686-linux --target=hppa-hpux. I asked this list, because you folks did some work on the SOM linker, which is at the moment the missing piece for a cross toolchain which targets hpux. Thanks, Dara P.S. On a different note, is the recipe fully up to date? I tried following it a few weeks ago, but glibc did not complete building successfully. From Arnaud.ATOCH@oecd.org Wed, 15 Nov 2000 10:05:04 +0100 Date: Wed, 15 Nov 2000 10:05:04 +0100 From: Arnaud.ATOCH@oecd.org Arnaud.ATOCH@oecd.org Subject: [parisc-linux] Palinux on a 712/60 Hi, I got a couple of 715 and I'd love having access to an ISO image with STI console kernel too. -----Original Message----- From: Ian Zink [mailto:ian.zink@maryville.com] Sent: Wednesday, November 15, 2000 00:09 To: 'parisc-linux@thepuffingroup.com' Subject: RE: [parisc-linux] Palinux on a 712/60 Thanks for the reply, Grant. However, the 712s do not have a serial console. They do have a com port, but it does not work as a console, unfortunately. So I need do need to get a STI enabled kernel. I dropped Paul Lahaie a note to see if he could send me such a kernel so I do not have to create the entire cross-platform development environment just to boot one of these 712s. After I get it, I plan on expanding the 0.5 iso and making a new one using the STI console kernel. Ian --------------------------------------------------------------------------- To unsubscribe: send e-mail to parisc-linux-request@thepuffingroup.com with `unsubscribe' as the subject. From rhirst@linuxcare.com Wed, 15 Nov 2000 09:58:35 +0000 Date: Wed, 15 Nov 2000 09:58:35 +0000 From: Richard Hirst rhirst@linuxcare.com Subject: [parisc-linux] dino maintainer? On Tue, Nov 14, 2000 at 08:10:42AM -0800, Grant Grundler wrote: > The bug is normal for card-mode Dino - not for Built-in Dino. > I think Helge has the GSC 100BT card which is a card-mode Dino on-board > with one (or two) Tulip(s) behind it. > > The warning is a reminder one can NOT use MMIO accesses to those > PCI devices and *only* I/O Port space (eg inb/outb). > > If someone wants to fix the warning so it's quiet for card-mode > devices...see is_card_dino(d) in dino_driver_callback() for an > example. > > FYI - card-mode dino was used for several different networking > interfaces but not SCSI interfaces. But Helge has problems with the sym53c8xx driver on a B160L. Is that a PCI card driven via Dino? And if so, are you saying he needs to build his kernel with CONFIG_SCSI_NCR53C8XX_IOMAPPED=y so it doesn't try to use MMIO? Helge, it might be worth trying to switch on CONFIG_SCSI_NCR53C8XX_IOMAPPED anyway just to see what happens. Otherwise someone needs to start adding printk debug to figure out what is happening. I can't do that as I don't have a sym53c8xx pci card. Richard From andrew@neep.com.au Wed, 15 Nov 2000 18:10:13 +0800 Date: Wed, 15 Nov 2000 18:10:13 +0800 From: Andrew Shugg andrew@neep.com.au Subject: [parisc-linux] Palinux on a 712/60 Arnaud.ATOCH@oecd.org said: > Hi, > > I got a couple of 715 and I'd love having access to an ISO image with STI > console kernel too. I've never made an El Torito CDROM, is it possible to have multiple boot images and a boot loader on a single disc? ie could the actual boot image be a boot loader (PALO) which then points at one or more kernels on the CDROM? Andrew. -- Andrew Shugg http://www.neep.com.au/ "Just remember, Mr Fawlty, there's always someone worse off than yourself." "Is there? Well I'd like to meet him. I could do with a good laugh." From marteaut@esiee.fr Wed, 15 Nov 2000 11:25:07 +0100 Date: Wed, 15 Nov 2000 11:25:07 +0100 From: Thomas Marteau marteaut@esiee.fr Subject: [parisc-linux] Palinux on a 712/60 Hi Ian, If you like to see a linux kernel booting on your 712, you can donwload a fully operationnal root file system with the STI console and an extra terminal with the RS232 port at http://www.esiee.fr/puffin You have also all the info to make a bootable hard disk so try it and give us feedback... Bye, Thomas Marteau ESIEE Team From rhirst@linuxcare.com Wed, 15 Nov 2000 11:12:20 +0000 Date: Wed, 15 Nov 2000 11:12:20 +0000 From: Richard Hirst rhirst@linuxcare.com Subject: [parisc-linux] Beta CD On Fri, Nov 10, 2000 at 05:14:06PM -0500, Paul J.Y. Lahaie wrote: > Hello fellow PA-RISCers, > > An preliminary beta CD for PA/Linux has been uploaded to > puffin.external.hp.com. If people could try it and forward any complaints > or suggestions to me, it would be greatly appreciated. The URL for the > image is: ftp://puffin.external.hp.com/pub/parisc/cd-images/palinux-0.5.iso.gz I just borrowed a CDROM drive for my 715/75 so I could try it on there [Actually this is the palinux-0.5.iso.gz that I commented on, not the final version]. I wasn't successful: Sometimes the boot hangs after "ASP version 1 at 0xf0800000 found", waits a few seconds and then HPMCs. The scsi driver always has serious problems with the CD drive but does detect other devices on the bus. The kernel always crashes after "Serial driver version 5.01...", (if it gets that far) with Data access rights fault in kernel: Code=26 regs=c5f9c940 (Addr=00000003) YZrvWESTHLNXBCVMcbcbcbcbOGFRQPDI PSW: 00000000000001000000000000001010 r0-3 00000000 c0217800 c011e9f8 c5ff64a0 r4-7 c5ff6200 c023ab20 00000008 f0823800 r8-11 00000003 00000007 c019134c c02b20a0 r12-15 fffffffc c023a800 c023a800 c02c31cc r16-19 c023a800 c023a800 c02b2024 00000000 r20-23 c5ff6234 f0823807 f0823800 0000000a r24-27 ffffffff c5ff64a0 c5ff6200 c0258000 r28-31 ffffffff 000002c0 c5f9cb80 c012dfc0 sr0-4 00000000 00000000 00000000 00000000 sr4-8 00000000 00000000 00000000 00000000 IASQ: 00000000 00000000 IAOQ: c011e710 c011e714 IIR: 0f881093 ISR: 00000000 IOR: 00000003 ORIG_R28: 00000058 I'll investigate further when I have the time. Richard From adevries@linuxcare.com Wed, 15 Nov 2000 11:50:27 -0500 Date: Wed, 15 Nov 2000 11:50:27 -0500 From: Alex deVries adevries@linuxcare.com Subject: [parisc-linux] dino maintainer? Richard Hirst wrote: > On Tue, Nov 14, 2000 at 08:10:42AM -0800, Grant Grundler wrote: > > FYI - card-mode dino was used for several different networking > > interfaces but not SCSI interfaces. > > But Helge has problems with the sym53c8xx driver on a B160L. Is > that a PCI card driven via Dino? And if so, are you saying he needs > to build his kernel with CONFIG_SCSI_NCR53C8XX_IOMAPPED=y so it > doesn't try to use MMIO? Hang on a sec... what Grant's saying is that *card-mode* dino is never used for SCSI controllers, but on the B160L it would probably be *chip-mode* dino. Does this mean that all GSC SCSI expansion cards are Zalon based? So what Helge has isn't a PCI card specifically, Dino and the 53c8xx are all on the motherboard. Does Dino handle IO memory mapping differently for chip or card mode? - Alex -- Alex deVries, Principal Solutions Architect, The Puffins at Linuxcare 613.562.2759 tel alex@linuxcare.com, http://www.linuxcare.com/ Linuxcare, Support for the revolution. From grundler@cup.hp.com Wed, 15 Nov 2000 08:06:32 -0800 Date: Wed, 15 Nov 2000 08:06:32 -0800 From: Grant Grundler grundler@cup.hp.com Subject: [parisc-linux] dino maintainer? Richard Hirst wrote: > On Tue, Nov 14, 2000 at 08:10:42AM -0800, Grant Grundler wrote: > > The bug is normal for card-mode Dino - not for Built-in Dino. > > I think Helge has the GSC 100BT card which is a card-mode Dino on-board > > with one (or two) Tulip(s) behind it. Helge confirmed he has no such card. I think the PDC simply isn't programming the Dino IO_ADDR_EN since there are no PCI devices in his B160. Helge's B160 has a old rev of Dino PCI host bus adapter chip. It's possible to have "silent" data corruption caused by older revs of dino - 3.0 and older. The latest PDC Revisions (5.x and later) know this and won't permit the system to be booted unless the only devices on the PCI bus are known graphics interface cards. > > The warning is a reminder one can NOT use MMIO accesses to those > > PCI devices and *only* I/O Port space (eg inb/outb). > > > > If someone wants to fix the warning so it's quiet for card-mode > > devices...see is_card_dino(d) in dino_driver_callback() for an > > example. This is still correct for card-mode dino. > > FYI - card-mode dino was used for several different networking > > interfaces but not SCSI interfaces. > > But Helge has problems with the sym53c8xx driver on a B160L. Is > that a PCI card driven via Dino? I doubt it now. If Helge could send richard "in io" output, I think that would clarify what's in the B160. > And if so, are you saying he needs > to build his kernel with CONFIG_SCSI_NCR53C8XX_IOMAPPED=y so it > doesn't try to use MMIO? no. no SCSI was ever implement on a card-mode dino board. No reason to since they already had Zalon or open slots. grant > Helge, it might be worth trying to switch on CONFIG_SCSI_NCR53C8XX_IOMAPPED > anyway just to see what happens. Otherwise someone needs to start > adding printk debug to figure out what is happening. I can't do > that as I don't have a sym53c8xx pci card. > > Richard From grundler@cup.hp.com Wed, 15 Nov 2000 08:17:41 -0800 Date: Wed, 15 Nov 2000 08:17:41 -0800 From: Grant Grundler grundler@cup.hp.com Subject: [parisc-linux] dino maintainer? Alex deVries wrote: > Hang on a sec... what Grant's saying is that *card-mode* dino is never > used for SCSI controllers, but on the B160L it would probably be > *chip-mode* dino. No such thing - you probably mean "Bridge Mode" and that's what the built-in Dino is using. > Does this mean that all GSC SCSI expansion cards are Zalon based? > > So what Helge has isn't a PCI card specifically, Dino and the 53c8xx are > all on the motherboard. > > Does Dino handle IO memory mapping differently for chip or card mode? yes. yes. yes (conditional). "IO memory mapping" is a confusing term. I'll assume you mean MMIO. (Memory Mapped I/O) MMIO space access is independent of I/O Port space access. MMIO space access simple isn't available for card-mode Dino since niether PDC nor the OS assigns host physical address space to the card-mode Dino (that's what IO_ADDR_EN is for). PDC does this for Bridge-mode dino (built-in) - but apperently only when it needs to. I/O Port space accesses are done the same way for both modes. I/O Port space access is implemented by poking registers on Dino. Read the Dino Spec (or source) for more details. grant Grant Grundler Unix Systems Enablement Lab +1.408.447.7253 From dave@hiauly1.hia.nrc.ca Wed, 15 Nov 2000 11:23:05 -0500 (EST) Date: Wed, 15 Nov 2000 11:23:05 -0500 (EST) From: John David Anglin dave@hiauly1.hia.nrc.ca Subject: [parisc-linux] [Semi OT] SOM Linker > This is not precisely what I mean. What I should have said is that I want to create > a cross compiler --host=i686-linux --target=hppa-hpux. I asked this list, because > you folks did some work on the SOM linker, which is at the moment the missing piece > for a cross toolchain which targets hpux. This also may be possible. The first step would be to copy the hpux headers to a i686-linux system and see if you can build the HP linker. The next step would be to try to build the cross binutils tools. I know this requires the hpux headers and likely some hacking would be required to get it to build. The linker is probably the hard part. There may be byte ordering issues and bugs in what HP contributed. Dave -- J. David Anglin dave.anglin@nrc.ca National Research Council of Canada (613) 990-0752 (FAX: 952-6605) From pdbeal@louisville.edu Wed, 15 Nov 2000 11:47:09 -0500 Date: Wed, 15 Nov 2000 11:47:09 -0500 From: Phillip D. Beal pdbeal@louisville.edu Subject: [parisc-linux] Beta CD On Fri, Nov 10, 2000 at 05:14:06PM -0500, Paul J.Y. Lahaie wrote: > Hello fellow PA-RISCers, > > An preliminary beta CD for PA/Linux has been uploaded to > puffin.external.hp.com. If people could try it and forward any complaints > or suggestions to me, it would be greatly appreciated. The URL for the > image is: ftp://puffin.external.hp.com/pub/parisc/cd-images/palinux-0.5.iso.gz > > - Paul the CD worked great on the 715 I tried, and I actually didn't have a serial console machine, so I used my Palm Pilot and a link cable. Still worked like a charm. How did you get the kernel image into the boot sector of the CD? I'd like to try to build some CD's of the kernels I'm building to test in some mahcines that are not on the same network as the machine that I'm building everything from. And I don't mind posting my CD images somewhere if they work...but most of my testing is on a 735 or 755. Thanks, -- Phillip Beal Electrical and Computer Engineering S+LUG Vice-President From bame@noam.fc.hp.com Wed, 15 Nov 2000 10:08:22 -0700 Date: Wed, 15 Nov 2000 10:08:22 -0700 From: Paul Bame bame@noam.fc.hp.com Subject: [parisc-linux] Help with posix_types.h I'm reviewing the posix_types.h to figure out what's right for 64-bit linux. I know others may have thought through this before so I'm hoping for guidance. For those unfamiliar, the type names in posix_types.h are like __kernel_dev_t and usually are used to define the corresponding "normal" type (dev_t). These should be settled before the 32/64 syscall wrappers can be completed. __kernel_ino_t: often 32 bits, currently 32 bits for parisc and som3 64-bit kernels (mips64 and ia64). 64 bits on alpha and sparc64. Seems to me this ought to be 32 bits on parisc and parisc64, or 64 bits on both, since it's a function of file system sizes not processor width. HPUX kernel seems to always use 32 bits, but 64-bit userspace uses 64 bits. I propose 32 bits on both, but willy had selected 64 bits in parisc64 for some reason. __kernel_off_t: seems to be 32 bits on 32-bit cpus, 64 on 64-bit ones. This is supposedly the offset from a beginning of a file. HPUX appears to use 64-bits *in the kernel* for both 32 and 64-bit kernels. The obvious pattern is to make ours 32 on narrow, and 64 on wide palinux so I guess I propose that, and that's the way it was before I hacked on it too. Should we consider switching to 64 bits on narrow palinux since this is related to file systems, not CPUs. Note there's also a __kernel_loff_t -> loff_t which appears to be defined as 64 bits. I'm not sure how this does/should interact with off_t (lseek vs lseek64 for example). __kernel_suseconds_t: which becomes suseconds_t which is used in struct timeval { time_t tv_sec; /* seconds */ suseconds_t tv_usec; /* microseconds */ }; I'm confused why hpux, and other systems, like for this to be 'long' (e.g., 64 bits on 64-bit processors) since it seems like values over a million are probably rare and 32 bits seems to be enough for most implementations. sparc64 chose 32 bits for this and I want to do the same for parisc64 because it will reduce the amount of syscall structure repackings. Comments? __kernel_daddr_t: which is used indirectly in struct solaris_x86_vtoc and solaris_x86_slice which *might* be an on-disk data structures (used with CONFIG_SOLARIS_X86_PARTITION). So this needs to be 32 bits if that's the case (definition from sparc) and several archs have it 64 bits! On the other hand, HPUX's man page says 'daddr_t used for disk addresses except in an inode [and partition table I would think] on disk'. So it should probably be the same type as off_t. FYI the only other place it's used is in 'struct mtio' -- used to talk to magnetic tape units. I'm guessing the sparc struct should not be using this type, and that we should define it the same as off_t. Comments? From kailasr@webcash.com Wed, 15 Nov 2000 09:55:09 -0800 Date: Wed, 15 Nov 2000 09:55:09 -0800 From: Kailashnath V Rampure kailasr@webcash.com Subject: [parisc-linux] Boot command Yes Thomas the vmlinux is in /boot of 3rd partition as the other partitions are swap and f0. At 11:48 AM 11/15/00 +0100, Thomas Marteau wrote: >----- Original Message ----- >From: Kailashnath V Rampure >To: Paul Bame >Cc: Grant Grundler ; Matt Taggart >; >Sent: Tuesday, November 14, 2000 11:58 PM >Subject: Re: [parisc-linux] Boot command > > > > I have booted HP A class server through network. On that I have >repartioned > > the system and followed the steps on >http://www.parisc-linux.org/install.html. > > I have used the following command to initialize the hard disk. The kernel >I > > have downloaded is vmlinux-20001018. and cpied it to /mnt/boot/vmlinux > > after mounting /dev/sda3. I have used the following command to initialize > > the HDD. > > > > palo -I -k /boot/vmlinux -b /boot/iplboot \ -c '3/boot/vmlinux TERM=linux > > HOME=/ root=/dev/sda3' \ /dev/sda > >This means that vmlinux must be in /boot in your third partition on your >disk. >Is it true in your case? > > > -------------------------------- > > I get the following error: > > -------------------------------- > > SOFT Boot. > > palo ipl bame@noam Tue oct 31 14:18:02 MST 2000 > > 0/vmlinux 2138614 bytes@ 0x1f78c000 > > 0/palo-cmdline '3/boot/vmlinux TERM=linux HOME=/ root=/dev/sda3' > > /dev/ida1 82 62 1030688 > > /dev/ida2 f0 1030750 24738 > > /dev/ida3 83 1055488 1030750 > > Kernel:partition 3 file /boot/vmlinux > > ext2 block size 1024 > > ext2_mount(partition 3) returns 0 > > ext2_open(/boot/vmlinux) = -1 > > open /boot/vmlinux failed > > ------------------------------------- > > Please suggest. > > > > -------------------------------------------------------------------------- >- > > To unsubscribe: send e-mail to parisc-linux-request@thepuffingroup.com >with > > `unsubscribe' as the subject. > > > > From bame@noam.fc.hp.com Wed, 15 Nov 2000 11:05:14 -0700 Date: Wed, 15 Nov 2000 11:05:14 -0700 From: Paul Bame bame@noam.fc.hp.com Subject: [parisc-linux] Beta CD = How did you get the kernel image into the boot = sector of the CD? I'd like to try to build some CD's of the kernels I'm = building to test in some mahcines that are not on the same network as = the machine that I'm building everything from. The magic for making bootable CDs is documented in the PALO README.html which you have on your system already since you're building kernels. -P From marteaut@esiee.fr Wed, 15 Nov 2000 19:10:56 +0100 Date: Wed, 15 Nov 2000 19:10:56 +0100 From: Thomas Marteau marteaut@esiee.fr Subject: [parisc-linux] Boot command Hi again, You put the swap partition before the f0 partition and here it is the f0 partition in first position. Also, your hard disk is ida instead of sda, what's that ? Bye, ESIEE Team ----- Original Message ----- From: Kailashnath V Rampure To: Thomas Marteau Cc: Sent: Wednesday, November 15, 2000 6:55 PM Subject: Re: [parisc-linux] Boot command > Yes Thomas the vmlinux is in /boot of 3rd partition as the other partitions > are swap and f0. > > At 11:48 AM 11/15/00 +0100, Thomas Marteau wrote: > > >----- Original Message ----- > >From: Kailashnath V Rampure > >To: Paul Bame > >Cc: Grant Grundler ; Matt Taggart > >; > >Sent: Tuesday, November 14, 2000 11:58 PM > >Subject: Re: [parisc-linux] Boot command > > > > > > > I have booted HP A class server through network. On that I have > >repartioned > > > the system and followed the steps on > >http://www.parisc-linux.org/install.html. > > > I have used the following command to initialize the hard disk. The kernel > >I > > > have downloaded is vmlinux-20001018. and cpied it to /mnt/boot/vmlinux > > > after mounting /dev/sda3. I have used the following command to initialize > > > the HDD. > > > > > > palo -I -k /boot/vmlinux -b /boot/iplboot \ -c '3/boot/vmlinux TERM=linux > > > HOME=/ root=/dev/sda3' \ /dev/sda > > > >This means that vmlinux must be in /boot in your third partition on your > >disk. > >Is it true in your case? > > > > > -------------------------------- > > > I get the following error: > > > -------------------------------- > > > SOFT Boot. > > > palo ipl bame@noam Tue oct 31 14:18:02 MST 2000 > > > 0/vmlinux 2138614 bytes@ 0x1f78c000 > > > 0/palo-cmdline '3/boot/vmlinux TERM=linux HOME=/ root=/dev/sda3' > > > /dev/ida1 82 62 1030688 > > > /dev/ida2 f0 1030750 24738 > > > /dev/ida3 83 1055488 1030750 > > > Kernel:partition 3 file /boot/vmlinux > > > ext2 block size 1024 > > > ext2_mount(partition 3) returns 0 > > > ext2_open(/boot/vmlinux) = -1 > > > open /boot/vmlinux failed From dave@hiauly1.hia.nrc.ca Wed, 15 Nov 2000 13:09:49 -0500 (EST) Date: Wed, 15 Nov 2000 13:09:49 -0500 (EST) From: John David Anglin dave@hiauly1.hia.nrc.ca Subject: [parisc-linux] Help with posix_types.h The largest disk currently available I believe is the 180GB Seagate Baracuda. The size of drives is increasing about a factor of 2 per year. The __kernel_off_t definitely needs to be 64 bits to handle large drives in both 32 and 64 bit systems. Disk blocks are typically 512 or 1024 bytes. Thus, drives may exceed 4GB disk blocks in 3-4 years. Inodes are variable in size (8KB average). Thus, we are a little further away from exceeding the 32 bit inode limit. Dave -- J. David Anglin dave.anglin@nrc.ca National Research Council of Canada (613) 990-0752 (FAX: 952-6605) From bame@noam.fc.hp.com Wed, 15 Nov 2000 11:12:57 -0700 Date: Wed, 15 Nov 2000 11:12:57 -0700 From: Paul Bame bame@noam.fc.hp.com Subject: [parisc-linux] Boot command = You put the swap partition before the f0 partition and here it is the f0 = partition in first position. The partition order doesn't matter so long as the f0 partition and the partition containing your kernel (an ext2 partition) *end* within the first 2Gb of the disk. See the PALO README.html. = Also, your hard disk is ida instead of sda, what's that ? PALO lists the devices as 'ida' instead of 'sda' or 'hda' since it is using the firmware 'IODC' interface to talk to the boot device, and it has no idea what type of boot device IODC is providing. -P From rhirst@linuxcare.com Wed, 15 Nov 2000 18:48:08 +0000 Date: Wed, 15 Nov 2000 18:48:08 +0000 From: Richard Hirst rhirst@linuxcare.com Subject: [parisc-linux] Single-stepping (Oops, CC-ed to the wrong list first time!) Hi John, I've been helping Alan Modra out with kernel changes to support single stepping for gdb. Paul Bame suggested I bounced our ideas off you in case you (or anyone else) had any comments. I havn't actually committed my changes yet. The basic approach is to use the recovery counter to generate a trap every instruction. The scheme is complicated because a suspended process may or may not return to user space via an RFI. If it was suspended as a result of an interrupt then we can simply set PSW bit R in the tasks saved registers and it will get loaded by the RFI. On every task switch I set the recovery counter to 0, just in case the new process is being single-stepped. If a process is suspended during a syscall, then there is no RFI on the return path to userland, and we have to handle things differently. I have changed the syscall return path such that it loads the recovery counter with 3 before updating the PSW with a value from the tasks saved registers. If that PSW has the R bit set, then the count of 3 will generate a trap on the first instruction following the branch back to user space. Note that PSW wasn't previously restored on the syscall return path. To avoid further complications of interrupts during the three instructions when the recovery counter is decrementing, whenever we set the R bit, we also clear the I bit to disable interrupts. Nullified instructions are handled by the controlling process manually moving the childs IAOQ over the instruction without actually setting it running, because the recovery counter isn't decremented for nullified instructions. I need to do some more testing before committing this, but would welcome any comments on the basic approach taken, areas I have mis-understood, or problems with it that might not yet have occurred to me. Thanks, Richard From andreas@bawue.de Thu, 16 Nov 2000 20:20:41 +0100 Date: Thu, 16 Nov 2000 20:20:41 +0100 From: Andreas Thienemann andreas@bawue.de Subject: [parisc-linux] 250/1 doesn't boot but dumps stack This is a multi-part message in MIME format. --------------F7EF1B69F0A7C4C7DD54E27D Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hi, I recently got a D-Class HP900 250/1 (at least it says that on the label) and tried to get the pa-risc port running on it. So I got a CVS checkout and build the whole toolchain without any major hassles. The kernel, including NFS-ROOT, built also without any glitches. But when I try to boot up this kernel it dumps stack right after initialising the pty interfaces. (I already left out everything unnecessary, such as parallel port support) After that it complains about "Data acces rights fault in kernel: Code=26 regs=c7f98780 (Addr=000000004)" and some more data... For the curious, the boot sequence is attached. I hope someone can give me a clue what might be wrong... Thanks, Andreas --------------F7EF1B69F0A7C4C7DD54E27D Content-Type: text/plain; charset=us-ascii; name="hp9000-capture" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="hp9000-capture" Firmware Version 36.34 Duplex Console IO Dependent Code (IODC) revision 0 ------------------------------------------------------------------------------ (c) Copyright 1995-1998, Hewlett-Packard Company, All rights reserved ------------------------------------------------------------------------------ Processor Speed State Coprocessor State Cache Size --------- -------- --------------------- ----------------- ---------- 0 101 MHz Active Functional 256 KB Central Bus Speed (in MHz) : 101 Available memory (bytes) : 134217728 Good memory required (bytes): 15245312 Primary boot path: 8/16/5.5 (dec) Alternate boot path: 8/16/5.2 (dec) Console path: 8/16/4.0 (dec) Keyboard path: 8/16/7.0 (dec) Processor is booting from first available device. To discontinue, press any key within 10 seconds. Boot terminated. ------- Main Menu ------------------------------------------------------------- Command Description ------- ----------- BOot [PRI|ALT|] Boot from specified path PAth [PRI|ALT|CON|KEY] [] Display or modify a path SEArch [DIsplay|IPL] [] Search for boot devices COnfiguration [] Access Configuration menu/commands INformation [] Access Information menu/commands SERvice [] Access Service menu/commands DIsplay Redisplay the current menu HElp [|] Display help for menu or command RESET Restart the system ------- Main Menu: Enter command > bo 8/16/6.0 Interact with IPL (Y or N)?> n Booting... Network Station Address 0060b0-3c08d4 Boot IO Dependent Code (IODC) revision 2 HARD Booted. palo ipl root@gate.ixs.com Wed Nov 15 14:08:22 CET 2000 0/vmlinux 2143238 bytes @ 0x6800 0/palo-cmdline '0/vmlinux HOME=/ TERM=LINUX root=/dev/nfs nfsroot=192.168.1.1 ' Kernel: partition 0 file /vmlinux ELF32 executable Entry 00100120 first 00100000 n 4 Segment 0 load 00100000 size 1467884 mediaptr 0x1000 Segment 1 load 00268000 size 174520 mediaptr 0x168000 Segment 2 load 00294000 size 103180 mediaptr 0x193000 Segment 3 load 002b0000 size 8192 mediaptr 0x1ad000 branching to kernel entry point 0x00100120 Set default PSW W bit to 0 PDC Console Initialized The 32-bit Kernel has started... Enabled FP coprocessor Free memory starts at: 0xc02dc000 start_parisc(0x504d6c,0x504d6c,0x0,0x0) PALO command line: 'HOME=/ TERM=LINUX root=/dev/nfs nfsroot=192.168.1.1 ' PALO initrd 0-0 model 00005890 00000481 00000000 00000002 778314c3 100000f0 00000004 0000008a 0000008a vers 0000000d cpuid 0000016d CPUID vers 11 rev 13 Searching for devices in PDC firmware... processor hpa 0xfffa0000 a newer box... Found devices: 1. UL 350 Lasi Core BA (11) at 0xffd00000, versions 0x2e, 0x0, 0x81, 0x0, 0x0 2. UL 350 Lasi Core RS-232 (10) at 0xffd05000, versions 0x2e, 0x0, 0x8c, 0x0, 0x0 3. UL 350 Core SCSI (10) at 0xffd06000, versions 0x2e, 0x0, 0x82, 0x0, 0x80 4. UL 350 Core LAN (802.3) (10) at 0xffd07000, versions 0x2e, 0x0, 0x8a, 0x0, 0x0 5. UL 350 Core Centronics (10) at 0xffd02000, versions 0x2e, 0x0, 0x74, 0x0, 0x0 6. UL 350 Core PC Keyboard (10) at 0xffd08000, versions 0x2e, 0x0, 0x84, 0x0, 0x0 7. UL 350 Core PC Keyboard (10) at 0xffd08100, versions 0x2e, 0x0, 0x84, 0x0, 0x0 8. UL 350 Core PC Floppy (10) at 0xffd0a000, versions 0x2e, 0x0, 0x83, 0x0, 0x0 9. UL 350 Core Wax BA (11) at 0xffe00000, versions 0x30, 0x0, 0x8e, 0x0, 0x0 10. UL 350 Wax EISA BA (11) at 0xfc000000, versions 0x30, 0x0, 0x90, 0x0, 0x0 11. UL 350 Wax Core RS-232 (10) at 0xffe02000, versions 0x30, 0x0, 0x8c, 0x0, 0x0 That's a total of 11 devices. No CPUs reported by firmware - probing... Found CPU at fffa0000 CPU(s): 1 x PA7200 (PCX-T') at 101.000000 MHz Linux version 2.4.0-test10 (root@gate.ixs.com) (gcc version 2.96 20000925 (experimental)) #4 Wed Nov 15 19:06:49 CET 2000 free_bootmem(0x2dd000, 0x7d23000) pagetable_init On node 0 totalpages: 32768 zone(0): 16384 pages. zone(1): 16384 pages. zone(2): 0 pages. Kernel command line: HOME=/ TERM=LINUX root=/dev/nfs nfsroot=192.168.1.1 trap_init Calibrating delay loop... 100.76 BogoMIPS Memory: 125568k available Dentry-cache hash table entries: 16384 (order: 5, 131072 bytes) Buffer-cache hash table entries: 8192 (order: 3, 32768 bytes) Page-cache hash table entries: 32768 (order: 5, 131072 bytes) Inode-cache hash table entries: 8192 (order: 4, 65536 bytes) POSIX conformance testing by UNIFIX Lasi version 0 at 0xffd00000 found. Wax at 0xffe00000 found. Wax: HIL Keyboard-NMI registered. parport0: PC-style at 0xffd02800, irq 88 [PCSPP,TRISTATE] Found i82596 at 0xffd07000, IRQ 87 early initialization of device eth0 is deferred Initializing Lasi PS/2-keyboard port at 0xffd08000... Support for Lasi PS/2-psaux not yet available ! Linux NET4.0 for Linux 2.4 Based upon Swansea University Computer Society NET3.039 Starting kswapd v1.8 pty: 256 Unix98 ptys configured lp0: using parport0 (interrupt-driven). Dumping Stack from c7f98000 to c7f989c0: 8000 00000000 00000040 00000000 00000000 c027c32c 00000000 00000000 ffffffff 8020 00000001 00000000 00000000 00000000 00000000 00000000 ffffffff c027c244 8040 c027c244 00000031 c7f90000 c02b0000 c028160c 00000000 00000000 00000000 8060 00000000 00000000 00000000 00000001 00000000 00000000 00000000 00000000 8080 00000000 c02b0000 c02b0000 c7f84000 00000000 00000000 c7f84098 c02b0098 80a0 00000000 c02cba18 00000000 c7f980ac c7f980ac c7f980b4 c01177f4 c7f98908 80c0 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 80e0 00000000 00000000 c7f98000 c011a5e4 00000000 0000000f 00000000 00000000 8100 00000024 00000000 00000033 00000000 00000000 00000000 00000000 00000000 8120 00000000 80000000 00000000 00000000 00000000 00000000 00000000 00000000 8140 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 8160 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 8180 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 81a0 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 81c0 00000000 00000000 00000000 fffffeff 00000000 ffffffff 00000000 c027ceb8 81e0 ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff 00800000 05000000 8200 00000000 ffffffff ffffffff ffffffff 00000800 00000800 00000400 00000400 8220 ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff 00007377 61707065 8240 72000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 8260 00008000 c0269000 c0269000 c013de10 00010000 c7ffeba0 c022248c c0234898 8280 000000f0 c02db000 00000000 c0118cf0 c0269054 00008000 c0269000 c0269054 82a0 f0000068 f0000070 c027c000 c027c368 0000000b 00000024 0000003c 0000003e 82c0 c027c000 00000000 c01001dc 00000004 00000000 00000023 c02b61ef 00000000 82e0 c027c000 f0000070 f0000068 000000ff ffd05800 ffd05800 ffd05800 00000060 8300 ffffffff ffd05800 002b50c0 c0268000 00000000 00000000 c02b08c0 00000000 8320 000b0800 00000000 0000001f 00000000 0000001f 00000000 0000001f 00000000 8340 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 8360 00000010 00000020 7f7fffff ffffffff 43ebebeb e0000000 00000000 00000000 8380 45e69c6a 25b7ea20 41800000 00000000 00000010 00000010 00000000 00000000 83a0 00000040 00000080 00000100 00000200 00000400 00000800 7fffffff 7fffffff 83c0 41000000 00000000 7fffffff 7fffffff 40800000 00000000 41000000 00000000 83e0 40300000 00000000 40200000 00000000 40200000 00000000 41800000 7fffffff 8400 40000000 00000000 40000000 00000000 40800000 00000000 41000000 00000000 8420 00000000 00000000 c7f98800 c0103cf4 00000000 00000000 00000000 00000000 8440 00000000 00000000 c0118ce0 c0118ce4 40800000 00000000 00282000 00000000 8460 c0281040 c0281064 00000000 c0281204 00000000 00000000 00000000 c7f98478 8480 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 84a0 00000000 00000000 71894dcb e3642ec4 c6c85d89 8d90bb13 1b217627 3634591c 84c0 6c1e076a d84abb86 b095770d 612aee1b c2236964 8446d2c9 088da593 116dfe74 84e0 22ad49ba 452c2626 8a2ef91e c0103c48 28cd5128 51ec1702 a3ae9b56 475d36ad 8500 c7f98000 c028160c 00000000 76fd1fb2 ed8c8a36 db19146d b63228db 6c6451b7 8520 d8be163c b17c2c79 62f858f3 c01001f0 8b0c0969 161812d3 2c4690f4 58fb94ba 8540 b1819c26 6303384d c670c5c8 8ce18b91 19c31723 33f09b14 6797837a cf59b3a6 8560 9eb3674d 3d66ce9b 7abb2864 c0294ef4 ea01cb35 d403966b a8072cd7 500e59af 8580 00000000 c02b0000 81dead60 03bd5ac1 00000060 c027c35c c027c35c c025920c 85a0 7234ad2e e41fef0e c83fde1d c0294ea0 20ff7877 418845bc 83663e2a 06cc7c55 85c0 c02ad30c c02ad2cc 00000000 00000000 00000000 c7f985d4 c7f985d4 c7f985dc 85e0 c7f985dc c7f985e4 00000000 c0298ca0 00000000 c7f985d4 c7f985d4 c7f985dc 8600 c027e800 00000000 00000000 00000000 000000fa 000000f2 000000ff c0295514 8620 000000f0 c02cb800 c02b06c0 c0299814 c028160c c02ad30c c02ad2bc c028160c 8640 c02b06c0 c7f98000 c028160c c02ad30c c02ad2d0 c7f94800 c0230add 0000003e 8660 c027c000 00000001 c02b6206 c0299744 c02b61ce 00000037 c02b6206 00000000 8680 c02ad30c c02ad2d0 00000040 c02cb800 000000fa 000000f2 000000ff c0295514 86a0 000000f0 c02cb800 c02b06c0 c02a4af4 c028160c c02ad30c c02ad2d0 c7f98000 86c0 c028b800 c01e2468 ffffffff c028b1e4 c7ffc400 c028160c c024256c c0186688 86e0 c028160c c02c6104 c01e2468 c029c4e0 c028b310 c028b1b4 c7f988c0 00000000 8700 ffffffff 0000ffe0 0060b03c 08d4bcfc 00000000 00000008 c0295514 000000f0 8720 c02cb800 c028b800 c01e2468 ffffffff c028b1e4 c7ffc400 c02bfc1c c02bfe50 8740 00000063 00000008 c7f98718 c024256c 00000000 c0285038 c028b1b9 c0242340 8760 45e69c6a 25b7ea20 41800000 c029c248 00000010 00000010 00000000 00000000 8780 0004000b c02ca800 c029c248 00000000 c7ffc400 ffffffff c01e2468 c028b800 87a0 c02cb800 000000f0 00000000 000000ff 000000f2 000000fa 000000fd f0100000 87c0 f0001180 f0000070 f0000068 00000000 c7f9870e 00000002 c029c4d0 ffd07000 87e0 c7f98710 00000f20 00000000 c0268000 00000001 00000000 c7f989c0 002b31b8 8800 000b0800 00000000 0000001f 00000000 0000001f 00000000 0000001f 00000000 8820 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 8840 00000010 00000020 7f7fffff ffffffff 43ebebeb e0000000 00000000 00000000 8860 45e69c6a 25b7ea20 41800000 00000000 00000010 00000010 00000000 00000000 8880 00000040 00000080 00000100 00000200 00000400 00000800 7fffffff 7fffffff 88a0 41000000 00000000 7fffffff 7fffffff 40800000 00000000 41000000 00000000 88c0 40300000 00000000 40200000 00000000 40200000 00000000 41800000 7fffffff 88e0 40000000 00000000 40000000 00000000 40800000 00000000 41000000 00000000 8900 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 8920 00000000 00000000 c029c264 c029c268 00000000 00000000 c7f98b00 00000000 8940 00000000 00000000 0000001f 00000000 0000001f 0e681096 00000000 00000004 8960 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 8980 00000010 00000020 7f7fffff ffffffff 43ebebeb e0000000 00000000 00000000 89a0 45e69c6a 25b7ea20 41800000 c01046e0 00000010 00000010 00000000 00000000 Data access rights fault in kernel: Code=26 regs=c7f98780 (Addr=00000004) YZrvWESTHLNXBCVMcbcbcbcbOGFRQPDI PSW: 00000000000001000000000000001011 r0-3 00000000 c02ca800 c029c248 00000000 r4-7 c7ffc400 ffffffff c01e2468 c028b800 r8-11 c02cb800 000000f0 00000000 000000ff r12-15 000000f2 000000fa 000000fd f0100000 r16-19 f0001180 f0000070 f0000068 00000000 r20-23 c7f9870e 00000002 c029c4d0 ffd07000 r24-27 c7f98710 00000f20 00000000 c0268000 r28-31 00000001 00000000 c7f989c0 002b31b8 sr0-4 00000000 00000000 00000000 00000000 sr4-8 00000000 00000000 00000000 00000000 IASQ: 00000000 00000000 IAOQ: c029c264 c029c268 IIR: 0e681096 ISR: 00000000 IOR: 00000004 ORIG_R28: 00000000 --------------F7EF1B69F0A7C4C7DD54E27D-- From ixs@ixs.bb.bawue.de Wed, 15 Nov 2000 20:28:28 +0100 (CET) Date: Wed, 15 Nov 2000 20:28:28 +0100 (CET) From: Andreas Thienemann ixs@ixs.bb.bawue.de Subject: [parisc-linux] 250/1 doesn't boot but dumps stack Hi again, just to clear something up: On Thu, 16 Nov 2000, Andreas Thienemann wrote: > the pty interfaces. (I already left out everything unnecessary, such as > parallel port support) I just noticed I attached the wrong file. The attached bootlog was from a kernel that still had support for lp0. But with another kernel, this time without lp support, this errors were the same... bye, Andreas From kailasr@webcash.com Wed, 15 Nov 2000 11:26:30 -0800 Date: Wed, 15 Nov 2000 11:26:30 -0800 From: Kailashnath V Rampure kailasr@webcash.com Subject: [parisc-linux] Boot command Thomas, I mounted the /dev/sda3 on mnt and deleted every thing and recopied then rebooted. It worked. Probably there was some fault while I copied yesterday. I did not repartition the disk now. Thanks Regards Kailas At 07:10 PM 11/15/00 +0100, Thomas Marteau wrote: >Hi again, > > You put the swap partition before the f0 partition and here it is the f0 >partition in first position. > Also, your hard disk is ida instead of sda, what's that ? > >Bye, > >ESIEE Team >----- Original Message ----- >From: Kailashnath V Rampure >To: Thomas Marteau >Cc: >Sent: Wednesday, November 15, 2000 6:55 PM >Subject: Re: [parisc-linux] Boot command > > > > Yes Thomas the vmlinux is in /boot of 3rd partition as the other >partitions > > are swap and f0. > > > > At 11:48 AM 11/15/00 +0100, Thomas Marteau wrote: > > > > >----- Original Message ----- > > >From: Kailashnath V Rampure > > >To: Paul Bame > > >Cc: Grant Grundler ; Matt Taggart > > >; > > >Sent: Tuesday, November 14, 2000 11:58 PM > > >Subject: Re: [parisc-linux] Boot command > > > > > > > > > > I have booted HP A class server through network. On that I have > > >repartioned > > > > the system and followed the steps on > > >http://www.parisc-linux.org/install.html. > > > > I have used the following command to initialize the hard disk. The >kernel > > >I > > > > have downloaded is vmlinux-20001018. and cpied it to /mnt/boot/vmlinux > > > > after mounting /dev/sda3. I have used the following command to >initialize > > > > the HDD. > > > > > > > > palo -I -k /boot/vmlinux -b /boot/iplboot \ -c '3/boot/vmlinux >TERM=linux > > > > HOME=/ root=/dev/sda3' \ /dev/sda > > > > > >This means that vmlinux must be in /boot in your third partition on your > > >disk. > > >Is it true in your case? > > > > > > > -------------------------------- > > > > I get the following error: > > > > -------------------------------- > > > > SOFT Boot. > > > > palo ipl bame@noam Tue oct 31 14:18:02 MST 2000 > > > > 0/vmlinux 2138614 bytes@ 0x1f78c000 > > > > 0/palo-cmdline '3/boot/vmlinux TERM=linux HOME=/ root=/dev/sda3' > > > > /dev/ida1 82 62 1030688 > > > > /dev/ida2 f0 1030750 24738 > > > > /dev/ida3 83 1055488 1030750 > > > > Kernel:partition 3 file /boot/vmlinux > > > > ext2 block size 1024 > > > > ext2_mount(partition 3) returns 0 > > > > ext2_open(/boot/vmlinux) = -1 > > > > open /boot/vmlinux failed From bame@noam.fc.hp.com Wed, 15 Nov 2000 12:34:48 -0700 Date: Wed, 15 Nov 2000 12:34:48 -0700 From: Paul Bame bame@noam.fc.hp.com Subject: [parisc-linux] Help with posix_types.h FYI I just heard some pretty good reasons why both ino_t and off_t should be 64 bits even on 32-bit kernels. Keep those cards and letters coming! -P From grundler@cup.hp.com Wed, 15 Nov 2000 11:23:41 -0800 Date: Wed, 15 Nov 2000 11:23:41 -0800 From: Grant Grundler grundler@cup.hp.com Subject: [parisc-linux] 250/1 doesn't boot but dumps stack Andreas Thienemann wrote: > But when I try to boot up this kernel it dumps stack right after initialising > the pty interfaces. (I already left out everything unnecessary, such as > parallel port support) ... > parport0: PC-style at 0xffd02800, irq 88 [PCSPP,TRISTATE] > Found i82596 at 0xffd07000, IRQ 87 > early initialization of device eth0 is deferred > Initializing Lasi PS/2-keyboard port at 0xffd08000... > Support for Lasi PS/2-psaux not yet available ! > Linux NET4.0 for Linux 2.4 > Based upon Swansea University Computer Society NET3.039 > Starting kswapd v1.8 > pty: 256 Unix98 ptys configured > lp0: using parport0 (interrupt-driven). Are you sure you left out parallel port support? > Data access rights fault in kernel: Code=26 regs=c7f98780 (Addr=00000004) > > YZrvWESTHLNXBCVMcbcbcbcbOGFRQPDI > PSW: 00000000000001000000000000001011 > r0-3 00000000 c02ca800 c029c248 00000000 > r4-7 c7ffc400 ffffffff c01e2468 c028b800 > r8-11 c02cb800 000000f0 00000000 000000ff > r12-15 000000f2 000000fa 000000fd f0100000 > r16-19 f0001180 f0000070 f0000068 00000000 > r20-23 c7f9870e 00000002 c029c4d0 ffd07000 > r24-27 c7f98710 00000f20 00000000 c0268000 > r28-31 00000001 00000000 c7f989c0 002b31b8 > sr0-4 00000000 00000000 00000000 00000000 > sr4-8 00000000 00000000 00000000 00000000 > > IASQ: 00000000 00000000 IAOQ: c029c264 c029c268 > IIR: 0e681096 ISR: 00000000 IOR: 00000004 > ORIG_R28: 00000000 Smells like a driver bug. Can you look up IOAQ and GR2 (c029c264 and c029c248) in System.map file? grant From dave@hiauly1.hia.nrc.ca Wed, 15 Nov 2000 14:49:02 -0500 (EST) Date: Wed, 15 Nov 2000 14:49:02 -0500 (EST) From: John David Anglin dave@hiauly1.hia.nrc.ca Subject: [parisc-linux] Single-stepping > I've been helping Alan Modra out with kernel changes to support > single stepping for gdb. Paul Bame suggested I bounced our ideas > off you in case you (or anyone else) had any comments. I havn't > actually committed my changes yet. > > The basic approach is to use the recovery counter to generate > a trap every instruction. The scheme is complicated because a > suspended process may or may not return to user space via an RFI. I really don't know enough to comment on the implementation choice. Why did you decide on this approach as opposed to inserting breaks and enabling the taken branch branch trap (T)? It would appear that the recovery counter was intended to provide software recovery from hardware faults in fault tolerant systems. Possibly, Grant could comment on whether it is actually useful for this purpose. Dave -- J. David Anglin dave.anglin@nrc.ca National Research Council of Canada (613) 990-0752 (FAX: 952-6605) From j-perdue@tamu.edu Wed, 15 Nov 2000 13:53:03 -0600 Date: Wed, 15 Nov 2000 13:53:03 -0600 From: Jack Perdue j-perdue@tamu.edu Subject: [parisc-linux] nfsroot - 712/60 - RPC - help Howdy Puffins and others, I have a 712/60 here that I bought for the purpose of playing with PARISC linux. It came w/HP-UX 9.0 which I don't want to wax just yet (e.g. for ioscan and other HP-UX utils). I don't have a CD for it, so I've been trying to get NFSROOT to work. The 712/60 is known as pancho. The bootp server is named blacktower. I've unzipped nfsroot-20000804.tgz as /tftpboot/pancho and exported it to the local net. I can mount it from an i386 RH6.2 box, but I think I'm having problems accessing it from PA-RISC linux. Below are some of my config files, the output from bootp and two attempts at booting the 712/60... one with debugging turned on in net/sunrpc/sysctl.c. I'm kinda stumped. Can anyone see where I've gone wrong? Some notes: a) I've tried NFSROOT=192.168.1.11 and NFSROOT=192.168.1.11/tftpboot/vmlinux in palo/Makefile and the results are the same (both suggestions were made to this list at some point) b) I tried the APRICOT drivers, but the kernel would never see the net interface so I've switched to the LASI_82596 driver (doing both resulted in dupe symbols). The LASI driver seems to get much further. c) my sources were updated today from the puffin's CVS tree. The kernel booting below was built on those sources. d) with debugging on, I get: Root-NFS: Unable to get nfsd port number from server, using default Root-NFS: Portmapper on server returned 2049 as nfsd port however, with the debugging off, I only get: Root-NFS: Unable to get nfsd port number from server, using default portmap and rpc.mountd are running on blacktower. Why the conflicting report when debug is on? e) the final message in /var/log/messages is always "tftpd: read: Connection refused". My hosts.allow and hosts.deny files are empty so they shouldn't be the problem. And, as mentioned I can NFS mount the directory. Is this the problem and if so, what is the solution??? Any help on how I can resolve this problem is appreciated. TIA, jack j-perdue@tamu.edu ========== blacktower:/etc/exports ========== /tftpboot/pancho 192.168.1.0/255.255.255.0(rw,no_root_squash) ========== blacktower:/etc/bootptab ========== pancho:\ :hd=/tftpboot:\ :bf=vmlinux:\ :ht=ether:\ :ha=08000993DA02:\ :sm=255.255.255.0:\ :hn:\ :ip=192.168.1.13:\ :vm=rfc1048: ========== bootpd output ========== [root@blacktower rc.d]# /usr/sbin/bootpd -d 20 bootpd: info(6): bootptab mtime: Wed Nov 15 13:02:44 2000 bootpd: info(6): reading "/etc/bootptab" bootpd: info(6): read 1 entries (1 hosts) from "/etc/bootptab" bootpd: info(6): recvd pkt from IP addr 0.0.0.0 bootpd: info(6): bootptab mtime: Wed Nov 15 13:02:44 2000 bootpd: info(6): request from Ethernet address 08:00:09:93:DA:02 bootpd: info(6): found 192.168.1.13 (pancho) bootpd: info(6): bootfile="/tftpboot/vmlinux" bootpd: info(6): vendor magic field is 99.130.83.99 bootpd: info(6): sending reply (with RFC1048 options) bootpd: info(6): setarp 192.168.1.13 - 08:00:09:93:DA:02 bootpd: info(6): recvd pkt from IP addr 0.0.0.0 bootpd: info(6): bootptab mtime: Wed Nov 15 13:02:44 2000 bootpd: info(6): request from Ethernet address 08:00:09:93:DA:02 bootpd: info(6): found 192.168.1.13 (pancho) bootpd: info(6): bootfile="/tftpboot/vmlinux" bootpd: info(6): vendor magic field is 99.130.83.99 bootpd: info(6): request message length=364 bootpd: info(6): extended reply, length=364, options=128 bootpd: info(6): sending reply (with RFC1048 options) bootpd: info(6): setarp 192.168.1.13 - 08:00:09:93:DA:02 ========== from /var/log/messages ========== Nov 15 13:02:20 blacktower bootpd[1320]: version 2.4.3 Nov 15 13:02:20 blacktower bootpd[1320]: bootptab mtime: Wed Oct 12 00:41:28 1994 Nov 15 13:02:20 blacktower bootpd[1320]: reading "/etc/bootptab" Nov 15 13:02:20 blacktower bootpd[1320]: read 1 entries (1 hosts) from "/etc/bootptab" Nov 15 13:02:47 blacktower bootpd[1323]: version 2.4.3 Nov 15 13:02:47 blacktower bootpd[1323]: bootptab mtime: Wed Nov 15 13:02:44 2000 Nov 15 13:02:47 blacktower bootpd[1323]: reading "/etc/bootptab" Nov 15 13:02:47 blacktower bootpd[1323]: read 1 entries (1 hosts) from "/etc/bootptab" Nov 15 13:04:34 blacktower bootpd[1323]: recvd pkt from IP addr 0.0.0.0 Nov 15 13:04:34 blacktower bootpd[1323]: bootptab mtime: Wed Nov 15 13:02:44 2000 Nov 15 13:04:34 blacktower bootpd[1323]: request from Ethernet address 08:00:09:93:DA:02 Nov 15 13:04:34 blacktower bootpd[1323]: found 192.168.1.13 (pancho) Nov 15 13:04:34 blacktower bootpd[1323]: bootfile="/tftpboot/vmlinux" Nov 15 13:04:34 blacktower bootpd[1323]: vendor magic field is 99.130.83.99 Nov 15 13:04:34 blacktower bootpd[1323]: sending reply (with RFC1048 options) Nov 15 13:04:34 blacktower bootpd[1323]: setarp 192.168.1.13 - 08:00:09:93:DA:02 Nov 15 13:04:35 blacktower tftpd[1325]: tftpd: trying to get file: /tftpboot/vmlinux Nov 15 13:04:36 blacktower tftpd[1327]: tftpd: trying to get file: /tftpboot/vmlinux Nov 15 13:04:47 blacktower bootpd[1323]: recvd pkt from IP addr 0.0.0.0 Nov 15 13:04:47 blacktower bootpd[1323]: bootptab mtime: Wed Nov 15 13:02:44 2000 Nov 15 13:04:47 blacktower bootpd[1323]: request from Ethernet address 08:00:09:93:DA:02 Nov 15 13:04:47 blacktower bootpd[1323]: found 192.168.1.13 (pancho) Nov 15 13:04:47 blacktower bootpd[1323]: bootfile="/tftpboot/vmlinux" Nov 15 13:04:47 blacktower bootpd[1323]: vendor magic field is 99.130.83.99 Nov 15 13:04:47 blacktower bootpd[1323]: request message length=364 Nov 15 13:04:47 blacktower bootpd[1323]: extended reply, length=364, options=128 Nov 15 13:04:47 blacktower bootpd[1323]: sending reply (with RFC1048 options) Nov 15 13:04:47 blacktower bootpd[1323]: setarp 192.168.1.13 - 08:00:09:93:DA:02 Nov 15 13:04:53 blacktower tftpd[1327]: tftpd: read: Connection refused ========== console output (no RPC debug) ========== ---------------------------------------------------------------------------- BootRom Version 1.5 Memory Size: 32 MB ---------------------------------------------------------------------------- (c) Copyright 1990-1993, Hewlett-Packard Company. All rights reserved Press to stop boot sequence. Selecting a system to boot. Booting palo ipl jkp2866@redtower Wed Nov 15 12:44:21 CST 2000 0/vmlinux 1606438 bytes @ 0x6800 0/palo-cmdline '0/vmlinux HOME=/ TERM=LINUX root=/dev/nfs nfsroot=192.68.1.11:/tftpboot/pancho ' Kernel: partition 0 file /vmlinux ELF32 executable Entry 00100000 first 00100000 n 4 Segment 0 load 00100000 size 1097900 mediaptr 0x1000 Segment 1 load 0020e000 size 150520 mediaptr 0x10e000 Segment 2 load 00234000 size 55900 mediaptr 0x133000 Segment 3 load 00244000 size 8192 mediaptr 0x141000 branching to kernel entry point 0x00100000 Set default PSW W bit to 0 PDC Console Initialized The 32-bit Kernel has started... Enabled FP coprocessor Free memory starts at: 0xc026e000 start_parisc(0x504d6c,0x504d6c,0x0,0x0) PALO command line: 'HOME=/ TERM=LINUX root=/dev/nfs nfsroot=192.68.1.11:/tftpboot/pancho ' PALO initrd 0-0 model 00006000 00000481 00000000 00000000 77564139 00000000 00000004 00000072 00000072 vers 0000000a CPUID vers 0 rev 0 Searching for devices in PDC firmware... processor hpa 0xfffbe000 an older box... Found devices: 1. Gecko GSC Core Graphics (10) at 0xf8000000, versions 0x16, 0x0, 0x85, 0x0, 0x0 2. Gecko Core BA (11) at 0xf0100000, versions 0x16, 0x0, 0x81, 0x0, 0x0 3. Gecko Core SCSI (10) at 0xf0106000, versions 0x16, 0x0, 0x82, 0x0, 0x0 4. Gecko Core Lan (802.3) (10) at 0xf0107000, versions 0x16, 0x0, 0x8a, 0x0, 0x0 5. Gecko Core RS-232 (10) at 0xf0105000, versions 0x16, 0x0, 0x8c, 0x0, 0x0 6. Gecko Core Centronics (10) at 0xf0102000, versions 0x16, 0x0, 0x74, 0x0, 0x0 7. Gecko Audio (10) at 0xf0104000, versions 0x16, 0x0, 0x7b, 0x0, 0x0 8. Gecko Core PC Floppy (10) at 0xf010a000, versions 0x16, 0x0, 0x83, 0x0, 0x0 9. Gecko Core PC Keyboard (10) at 0xf0108000, versions 0x16, 0x0, 0x84, 0x0, 0x0 10. Gecko Core PC Keyboard (10) at 0xf0108100, versions 0x16, 0x0, 0x84, 0x0, 0x0 11. Gecko (712/60) (0) at 0xfffbe000, versions 0x600, 0x0, 0x4, 0x0, 0x81 12. Gecko (1) at 0xfffbf000, versions 0x26, 0x0, 0x9, 0x0, 0x0 That's a total of 12 devices. CPU(s): 1 x PA7100LC (PCX-L) at 60.000000 MHz Linux version 2.4.0-test10 (jkp2866@redtower) (gcc version 2.96 20000925 (experimental)) #16 Wed Nov 15 14:01:38 CST 2000 free_bootmem(0x26e400, 0x1d91c00) pagetable_init On node 0 totalpages: 8192 zone(0): 4096 pages. zone(1): 4096 pages. zone(2): 0 pages. Kernel command line: HOME=/ TERM=LINUX root=/dev/nfs nfsroot=192.68.1.11:/tftpboot/pancho trap_init Calibrating delay loop... 59.80 BogoMIPS Memory: 29632k available Dentry-cache hash table entries: 4096 (order: 3, 32768 bytes) Buffer-cache hash table entries: 1024 (order: 0, 4096 bytes) Page-cache hash table entries: 8192 (order: 3, 32768 bytes) Inode-cache hash table entries: 2048 (order: 2, 16384 bytes) POSIX conformance testing by UNIFIX Lasi version 0 at 0xf0100000 found. Found i82596 at 0xf0107000, IRQ 87 early initialization of device eth0 is deferred Linux NET4.0 for Linux 2.4 Based upon Swansea University Computer Society NET3.039 Starting kswapd v1.8 pty: 256 Unix98 ptys configured eth0: 82596 at 0xf0107000, 08 00 09 93 DA 02 IRQ 87. 82596.c $Revision: 1.14 $ Serial driver version 5.02 (2000-08-09) with MANY_PORTS SHARE_IRQ SERIAL_PCI enabled ttyS00 at iomem 0xf0105800 (irq = 90) is a 16550A NET4: Linux TCP/IP 1.0 for NET4.0 IP Protocols: ICMP, UDP, TCP IP: routing cache hash table of 512 buckets, 4Kbytes TCP: Hash tables configured (established 2048 bind 2048) eth0: link ok. Sending BOOTP requests.... OK IP-Config: Got BOOTP answer from 192.168.1.11, my address is 192.168.1.13 Switching from PDC console kmem_create: Forcing size word alignment - nfs_fh Looking up port of RPC 100003/2 on 192.68.1.11 RPC: sendmsg returned error 229 portmap: RPC call returned error 229 Root-NFS: Unable to get nfsd port number from server, using default Looking up port of RPC 100005/2 on 192.68.1.11 RPC: sendmsg returned error 229 portmap: RPC call returned error 229 Root-NFS: Unable to get mountd port number from server, using default RPC: sendmsg returned error 229 mount: RPC call returned error 229 Root-NFS: Server returned error -229 while mounting /tftpboot/pancho VFS: Unable to mount root fs via NFS, trying floppy. VFS: Cannot open root device "nfs" or 02:00 Please append a correct "root=" boot option Kernel panic: VFS: Unable to mount root fs on 02:00 ========== console output (with RPC debug) ========== ---------------------------------------------------------------------------- BootRom Version 1.5 Memory Size: 32 MB ---------------------------------------------------------------------------- (c) Copyright 1990-1993, Hewlett-Packard Company. All rights reserved Press to stop boot sequence. Selecting a system to boot. Booting palo ipl jkp2866@redtower Wed Nov 15 12:44:21 CST 2000 0/vmlinux 1606438 bytes @ 0x6800 0/palo-cmdline '0/vmlinux HOME=/ TERM=LINUX root=/dev/nfs nfsroot=192.68.1.11:/tftpboot/pancho ' Kernel: partition 0 file /vmlinux ELF32 executable Entry 00100000 first 00100000 n 4 Segment 0 load 00100000 size 1097900 mediaptr 0x1000 Segment 1 load 0020e000 size 150520 mediaptr 0x10e000 Segment 2 load 00234000 size 55900 mediaptr 0x133000 Segment 3 load 00244000 size 8192 mediaptr 0x141000 branching to kernel entry point 0x00100000 Set default PSW W bit to 0 PDC Console Initialized The 32-bit Kernel has started... Enabled FP coprocessor Free memory starts at: 0xc026e000 start_parisc(0x504d6c,0x504d6c,0x0,0x0) PALO command line: 'HOME=/ TERM=LINUX root=/dev/nfs nfsroot=192.68.1.11:/tftpboot/pancho ' PALO initrd 0-0 model 00006000 00000481 00000000 00000000 77564139 00000000 00000004 00000072 00000072 vers 0000000a CPUID vers 0 rev 0 Searching for devices in PDC firmware... processor hpa 0xfffbe000 an older box... Found devices: 1. Gecko GSC Core Graphics (10) at 0xf8000000, versions 0x16, 0x0, 0x85, 0x0, 0x0 2. Gecko Core BA (11) at 0xf0100000, versions 0x16, 0x0, 0x81, 0x0, 0x0 3. Gecko Core SCSI (10) at 0xf0106000, versions 0x16, 0x0, 0x82, 0x0, 0x0 4. Gecko Core Lan (802.3) (10) at 0xf0107000, versions 0x16, 0x0, 0x8a, 0x0, 0x0 5. Gecko Core RS-232 (10) at 0xf0105000, versions 0x16, 0x0, 0x8c, 0x0, 0x0 6. Gecko Core Centronics (10) at 0xf0102000, versions 0x16, 0x0, 0x74, 0x0, 0x0 7. Gecko Audio (10) at 0xf0104000, versions 0x16, 0x0, 0x7b, 0x0, 0x0 8. Gecko Core PC Floppy (10) at 0xf010a000, versions 0x16, 0x0, 0x83, 0x0, 0x0 9. Gecko Core PC Keyboard (10) at 0xf0108000, versions 0x16, 0x0, 0x84, 0x0, 0x0 10. Gecko Core PC Keyboard (10) at 0xf0108100, versions 0x16, 0x0, 0x84, 0x0, 0x0 11. Gecko (712/60) (0) at 0xfffbe000, versions 0x600, 0x0, 0x4, 0x0, 0x81 12. Gecko (1) at 0xfffbf000, versions 0x26, 0x0, 0x9, 0x0, 0x0 That's a total of 12 devices. CPU(s): 1 x PA7100LC (PCX-L) at 60.000000 MHz Linux version 2.4.0-test10 (jkp2866@redtower) (gcc version 2.96 20000925 (experimental)) #15 Wed Nov 15 13:48:41 CST 2000 free_bootmem(0x26e400, 0x1d91c00) pagetable_init On node 0 totalpages: 8192 zone(0): 4096 pages. zone(1): 4096 pages. zone(2): 0 pages. Kernel command line: HOME=/ TERM=LINUX root=/dev/nfs nfsroot=192.68.1.11:/tftpboot/pancho trap_init Calibrating delay loop... 59.80 BogoMIPS Memory: 29632k available Dentry-cache hash table entries: 4096 (order: 3, 32768 bytes) Buffer-cache hash table entries: 1024 (order: 0, 4096 bytes) Page-cache hash table entries: 8192 (order: 3, 32768 bytes) Inode-cache hash table entries: 2048 (order: 2, 16384 bytes) POSIX conformance testing by UNIFIX Lasi version 0 at 0xf0100000 found. Found i82596 at 0xf0107000, IRQ 87 early initialization of device eth0 is deferred Linux NET4.0 for Linux 2.4 Based upon Swansea University Computer Society NET3.039 Starting kswapd v1.8 pty: 256 Unix98 ptys configured eth0: 82596 at 0xf0107000, 08 00 09 93 DA 02 IRQ 87. 82596.c $Revision: 1.14 $ Serial driver version 5.02 (2000-08-09) with MANY_PORTS SHARE_IRQ SERIAL_PCI enabled ttyS00 at iomem 0xf0105800 (irq = 90) is a 16550A NET4: Linux TCP/IP 1.0 for NET4.0 IP Protocols: ICMP, UDP, TCP IP: routing cache hash table of 512 buckets, 4Kbytes TCP: Hash tables configured (established 2048 bind 2048) eth0: link ok. Sending BOOTP requests.... OK IP-Config: Got BOOTP answer from 192.168.1.11, my address is 192.168.1.13 Switching from PDC console kmem_create: Forcing size word alignment - nfs_fh RPC: registering /proc/net/rpc RPC: registering /proc/net/rpc/nfs Looking up port of RPC 100003/2 on 192.68.1.11 RPC: rpc_getport_external(192.68.1.11, 100003, 2, 17) RPC: xprt_create_proto called RPC: xprt_create_socket(udp 17) RPC: setting up UDP transport... RPC: created transport c1fa4000 RPC: creating portmap client for 192.68.1.11 (xprt c1fa4000) RPC: allocated buffer c1faa5a0 RPC: creating NULL authenticator for client c1faa5a0 RPC: allocated buffer c1fe6460 RPC: 0 new task procpid 1 RPC: 0 looking up NULL cred RPC: allocated buffer c1fe5500 RPC: 0 rpc_execute flgs 0 RPC: 0 call_reserve RPC: 0 xprt_reserve cong = 0 cwnd = 256 RPC: 0 reserved req c1fa4064 xid 11582000 RPC: 0 xprt_reserve returns 0 RPC: 0 call_reserveresult (status 0) RPC: 0 call_allocate (status 0) RPC: allocated buffer c1fb3800 RPC: 0 call_encode (status 0) RPC: 0 marshaling NULL cred c1fe5500 RPC: xdr_encode_mapping(100003, 2, 17, 0) RPC: 0 call_transmit (status 0) RPC: 0 xprt_transmit(11582000) RPC: 0 xprt_receive RPC: 0 sleep_on(queue "xprt_pending" time 89) RPC: 0 added to queue c1fa4048 "xprt_pending" RPC: xprt_sendmsg(56) = -229 RPC: sendmsg returned error 229 RPC: 0 __rpc_wake_up_task (now 93 inh 0) RPC: 0 disabling timer RPC: 0 removed from queue c1fa4048 "xprt_pending" RPC: __rpc_wake_up_task done RPC: wake_up_next(c1fa4040 "xprt_sending") RPC: 0 call_status (status -229) portmap: RPC call returned error 229 RPC: 0 exit() = -229 RPC: 0 release task RPC: 0 disabling timer RPC: 0 release request c1fa4064 RPC: wake_up_next(c1fa4050 "xprt_backlog") RPC: 0 releasing NULL cred c1fe5500 RPC: rpc_release_client(c1faa5a0, 1) RPC: destroying portmap client for 192.68.1.11 RPC: destroying NULL authenticator c1fe6460 RPC: destroying transport c1fa4000 RPC: disconnected transport c1fa4000 Root-NFS: Unable to get nfsd port number from server, using default Root-NFS: Portmapper on server returned 2049 as nfsd port Looking up port of RPC 100005/2 on 192.68.1.11 RPC: rpc_getport_external(192.68.1.11, 100005, 2, 17) RPC: xprt_create_proto called RPC: xprt_create_socket(udp 17) RPC: setting up UDP transport... RPC: created transport c1fa4000 RPC: creating portmap client for 192.68.1.11 (xprt c1fa4000) RPC: allocated buffer c1faa5a0 RPC: creating NULL authenticator for client c1faa5a0 RPC: allocated buffer c1fe6460 RPC: 1 new task procpid 1 RPC: 1 looking up NULL cred RPC: allocated buffer c1fe5500 RPC: 1 rpc_execute flgs 0 RPC: 1 call_reserve RPC: 1 xprt_reserve cong = 0 cwnd = 256 RPC: 1 reserved req c1fa4064 xid 11582001 RPC: 1 xprt_reserve returns 0 RPC: 1 call_reserveresult (status 0) RPC: 1 call_allocate (status 0) RPC: allocated buffer c1fb3800 RPC: 1 call_encode (status 0) RPC: 1 marshaling NULL cred c1fe5500 RPC: xdr_encode_mapping(100005, 2, 17, 0) RPC: 1 call_transmit (status 0) RPC: 1 xprt_transmit(11582001) RPC: 1 xprt_receive RPC: 1 sleep_on(queue "xprt_pending" time 140) RPC: 1 added to queue c1fa4048 "xprt_pending" RPC: xprt_sendmsg(56) = -229 RPC: sendmsg returned error 229 RPC: 1 __rpc_wake_up_task (now 144 inh 0) RPC: 1 disabling timer RPC: 1 removed from queue c1fa4048 "xprt_pending" RPC: __rpc_wake_up_task done RPC: wake_up_next(c1fa4040 "xprt_sending") RPC: 1 call_status (status -229) portmap: RPC call returned error 229 RPC: 1 exit() = -229 RPC: 1 release task RPC: 1 disabling timer RPC: 1 release request c1fa4064 RPC: wake_up_next(c1fa4050 "xprt_backlog") RPC: 1 releasing NULL cred c1fe5500 RPC: rpc_release_client(c1faa5a0, 1) RPC: destroying portmap client for 192.68.1.11 RPC: destroying NULL authenticator c1fe6460 RPC: destroying transport c1fa4000 RPC: disconnected transport c1fa4000 Root-NFS: Unable to get mountd port number from server, using default Root-NFS: mountd port is 627 NFS: nfs_mount(c044010b:/tftpboot/pancho) RPC: xprt_create_proto called RPC: xprt_create_socket(udp 17) RPC: setting up UDP transport... RPC: created transport c1fa4000 RPC: creating mount client for 192.68.1.11 (xprt c1fa4000) RPC: allocated buffer c1faa5a0 RPC: creating NULL authenticator for client c1faa5a0 RPC: allocated buffer c1fe6460 RPC: 2 new task procpid 1 RPC: 2 looking up NULL cred RPC: allocated buffer c1fe5500 RPC: 2 rpc_execute flgs 0 RPC: 2 call_reserve RPC: 2 xprt_reserve cong = 0 cwnd = 256 RPC: 2 reserved req c1fa4064 xid 11582002 RPC: 2 xprt_reserve returns 0 RPC: 2 call_reserveresult (status 0) RPC: 2 call_allocate (status 0) RPC: allocated buffer c1fa3000 RPC: 2 call_encode (status 0) RPC: 2 marshaling NULL cred c1fe5500 RPC: 2 call_transmit (status 0) RPC: 2 xprt_transmit(11582002) RPC: 2 xprt_receive RPC: 2 sleep_on(queue "xprt_pending" time 189) RPC: 2 added to queue c1fa4048 "xprt_pending" RPC: xprt_sendmsg(60) = -229 RPC: sendmsg returned error 229 RPC: 2 __rpc_wake_up_task (now 193 inh 0) RPC: 2 disabling timer RPC: 2 removed from queue c1fa4048 "xprt_pending" RPC: __rpc_wake_up_task done RPC: wake_up_next(c1fa4040 "xprt_sending") RPC: 2 call_status (status -229) mount: RPC call returned error 229 RPC: 2 exit() = -229 RPC: 2 release task RPC: 2 disabling timer RPC: 2 release request c1fa4064 RPC: wake_up_next(c1fa4050 "xprt_backlog") RPC: 2 releasing NULL cred c1fe5500 RPC: rpc_release_client(c1faa5a0, 1) RPC: destroying mount client for 192.68.1.11 RPC: destroying NULL authenticator c1fe6460 RPC: destroying transport c1fa4000 RPC: disconnected transport c1fa4000 Root-NFS: Server returned error -229 while mounting /tftpboot/pancho VFS: Unable to mount root fs via NFS, trying floppy. VFS: Cannot open root device "nfs" or 02:00 Please append a correct "root=" boot option Kernel panic: VFS: Unable to mount root fs on 02:00 ========== linux/.config ========== # # Automatically generated make config: don't edit # CONFIG_PARISC=y # CONFIG_UID16 is not set # # Code maturity level options # CONFIG_EXPERIMENTAL=y # # General options # # CONFIG_SMP is not set # CONFIG_KWDB is not set CONFIG_GSC=y # CONFIG_IOMMU_CCIO is not set CONFIG_GSC_LASI=y CONFIG_PCI=y CONFIG_GSC_DINO=y # CONFIG_PCI_LBA is not set # # Loadable module support # # CONFIG_MODULES is not set # # General setup # CONFIG_NET=y CONFIG_SYSVIPC=y # CONFIG_BSD_PROCESS_ACCT is not set CONFIG_SYSCTL=y CONFIG_BINFMT_SOM=y # CONFIG_BINFMT_ELF is not set # CONFIG_BINFMT_MISC is not set # CONFIG_BINFMT_JAVA is not set # # Parallel port support # # CONFIG_PARPORT is not set # # Block devices # # CONFIG_BLK_DEV_FD is not set # CONFIG_BLK_DEV_XD is not set # CONFIG_PARIDE is not set # CONFIG_BLK_CPQ_DA is not set # CONFIG_BLK_CPQ_CISS_DA is not set # CONFIG_BLK_DEV_DAC960 is not set # CONFIG_BLK_DEV_LOOP is not set # CONFIG_BLK_DEV_NBD is not set # CONFIG_BLK_DEV_RAM is not set # CONFIG_BLK_DEV_INITRD is not set # # Networking options # # CONFIG_PACKET is not set # CONFIG_NETLINK is not set # CONFIG_NETFILTER is not set # CONFIG_FILTER is not set # CONFIG_UNIX is not set CONFIG_INET=y # CONFIG_IP_MULTICAST is not set # CONFIG_IP_ADVANCED_ROUTER is not set CONFIG_IP_PNP=y CONFIG_IP_PNP_BOOTP=y # CONFIG_IP_PNP_RARP is not set # CONFIG_NET_IPIP is not set # CONFIG_NET_IPGRE is not set # CONFIG_INET_ECN is not set # CONFIG_SYN_COOKIES is not set # CONFIG_IPV6 is not set # CONFIG_KHTTPD is not set # CONFIG_ATM is not set # # # # CONFIG_IPX is not set # CONFIG_ATALK is not set # CONFIG_DECNET is not set # CONFIG_BRIDGE is not set # CONFIG_X25 is not set # CONFIG_LAPB is not set # CONFIG_LLC is not set # CONFIG_NET_DIVERT is not set # CONFIG_ECONET is not set # CONFIG_WAN_ROUTER is not set # CONFIG_NET_FASTROUTE is not set # CONFIG_NET_HW_FLOWCONTROL is not set # # QoS and/or fair queueing # # CONFIG_NET_SCHED is not set # # SCSI support # # CONFIG_SCSI is not set # # Network device support # CONFIG_NETDEVICES=y CONFIG_LASI_82596=y # # ARCnet devices # # CONFIG_ARCNET is not set # CONFIG_DUMMY is not set # CONFIG_BONDING is not set # CONFIG_EQUALIZER is not set # CONFIG_TUN is not set # CONFIG_NET_SB1000 is not set # # Ethernet (10 or 100Mbit) # CONFIG_NET_ETHERNET=y # CONFIG_NET_VENDOR_3COM is not set # CONFIG_LANCE is not set # CONFIG_NET_VENDOR_SMC is not set # CONFIG_NET_VENDOR_RACAL is not set # CONFIG_AT1700 is not set # CONFIG_DEPCA is not set # CONFIG_HP100 is not set # CONFIG_NET_ISA is not set CONFIG_NET_PCI=y # CONFIG_PCNET32 is not set # CONFIG_ADAPTEC_STARFIRE is not set # CONFIG_AC3200 is not set # CONFIG_APRICOT is not set # CONFIG_CS89x0 is not set # CONFIG_DE4X5 is not set # CONFIG_TULIP is not set # CONFIG_DGRS is not set # CONFIG_DM9102 is not set # CONFIG_EEPRO100 is not set # CONFIG_LNE390 is not set # CONFIG_NATSEMI is not set # CONFIG_NE2K_PCI is not set # CONFIG_NE3210 is not set # CONFIG_ES3210 is not set # CONFIG_RTL8129 is not set # CONFIG_8139TOO is not set # CONFIG_SIS900 is not set # CONFIG_EPIC100 is not set # CONFIG_SUNDANCE is not set # CONFIG_TLAN is not set # CONFIG_VIA_RHINE is not set # CONFIG_WINBOND_840 is not set # CONFIG_NET_POCKET is not set # # Ethernet (1000 Mbit) # # CONFIG_ACENIC is not set # CONFIG_HAMACHI is not set # CONFIG_YELLOWFIN is not set # CONFIG_SK98LIN is not set # CONFIG_FDDI is not set # CONFIG_HIPPI is not set # CONFIG_PPP is not set # CONFIG_SLIP is not set # # Wireless LAN (non-hamradio) # # CONFIG_NET_RADIO is not set # # Token Ring devices # # CONFIG_TR is not set # CONFIG_NET_FC is not set # CONFIG_RCPCI is not set # CONFIG_SHAPER is not set # # Wan interfaces # # CONFIG_WAN is not set # # Character devices # # CONFIG_VT is not set CONFIG_SERIAL=y CONFIG_SERIAL_CONSOLE=y CONFIG_SERIAL_GSC=y CONFIG_SERIAL_EXTENDED=y # CONFIG_SERIAL_MANY_PORTS is not set # CONFIG_SERIAL_SHARE_IRQ is not set # CONFIG_SERIAL_DETECT_IRQ is not set # CONFIG_SERIAL_MULTIPORT is not set # CONFIG_HUB6 is not set # CONFIG_SERIAL_NONSTANDARD is not set CONFIG_UNIX98_PTYS=y CONFIG_UNIX98_PTY_COUNT=256 # # I2C support # # CONFIG_I2C is not set # # Mice # # CONFIG_BUSMOUSE is not set # CONFIG_MOUSE is not set # # Joysticks # # CONFIG_JOYSTICK is not set # # Input core support is needed for joysticks # # CONFIG_QIC02_TAPE is not set # # Watchdog Cards # # CONFIG_WATCHDOG is not set # CONFIG_GENRTC is not set # CONFIG_INTEL_RNG is not set # CONFIG_NVRAM is not set # CONFIG_RTC is not set # CONFIG_DTLK is not set # CONFIG_R3964 is not set # CONFIG_APPLICOM is not set # # Ftape, the floppy tape device driver # # CONFIG_FTAPE is not set # CONFIG_AGP is not set # CONFIG_DRM is not set # # File systems # # CONFIG_QUOTA is not set # CONFIG_AUTOFS_FS is not set # CONFIG_AUTOFS4_FS is not set # CONFIG_ADFS_FS is not set # CONFIG_ADFS_FS_RW is not set # CONFIG_AFFS_FS is not set # CONFIG_HFS_FS is not set # CONFIG_BFS_FS is not set # CONFIG_FAT_FS is not set # CONFIG_MSDOS_FS is not set # CONFIG_UMSDOS_FS is not set # CONFIG_VFAT_FS is not set # CONFIG_EFS_FS is not set # CONFIG_JFFS_FS is not set # CONFIG_CRAMFS is not set # CONFIG_RAMFS is not set CONFIG_ISO9660_FS=y # CONFIG_JOLIET is not set # CONFIG_MINIX_FS is not set # CONFIG_NTFS_FS is not set # CONFIG_NTFS_RW is not set # CONFIG_HPFS_FS is not set CONFIG_PROC_FS=y # CONFIG_DEVFS_FS is not set # CONFIG_DEVFS_MOUNT is not set # CONFIG_DEVFS_DEBUG is not set # CONFIG_DEVPTS_FS is not set # CONFIG_QNX4FS_FS is not set # CONFIG_QNX4FS_RW is not set # CONFIG_ROMFS_FS is not set CONFIG_EXT2_FS=y # CONFIG_SYSV_FS is not set # CONFIG_SYSV_FS_WRITE is not set # CONFIG_UDF_FS is not set # CONFIG_UDF_RW is not set # CONFIG_UFS_FS is not set # CONFIG_UFS_FS_WRITE is not set # # Network File Systems # # CONFIG_CODA_FS is not set CONFIG_NFS_FS=y # CONFIG_NFS_V3 is not set CONFIG_ROOT_NFS=y # CONFIG_NFSD is not set # CONFIG_NFSD_V3 is not set CONFIG_SUNRPC=y CONFIG_LOCKD=y # CONFIG_SMB_FS is not set # CONFIG_NCP_FS is not set # CONFIG_NCPFS_PACKET_SIGNING is not set # CONFIG_NCPFS_IOCTL_LOCKING is not set # CONFIG_NCPFS_STRONG is not set # CONFIG_NCPFS_NFS_NS is not set # CONFIG_NCPFS_OS2_NS is not set # CONFIG_NCPFS_SMALLDOS is not set # CONFIG_NCPFS_MOUNT_SUBDIR is not set # CONFIG_NCPFS_NDS_DOMAINS is not set # CONFIG_NCPFS_NLS is not set # CONFIG_NCPFS_EXTRAS is not set # # Partition Types # # CONFIG_PARTITION_ADVANCED is not set CONFIG_MSDOS_PARTITION=y # CONFIG_NLS is not set # # Sound Drivers # # CONFIG_SOUND is not set # # Kernel hacking # # CONFIG_MAGIC_SYSRQ is not set From grundler@cup.hp.com Wed, 15 Nov 2000 12:10:36 -0800 Date: Wed, 15 Nov 2000 12:10:36 -0800 From: Grant Grundler grundler@cup.hp.com Subject: [parisc-linux] nfsroot - 712/60 - RPC - help Jack Perdue wrote: Two changes: > a) I've tried NFSROOT=192.168.1.11 and NFSROOT=192.168.1.11/tftpboot/vmlinux > in palo/Makefile and the results are the same (both suggestions were > made to this list at some point) Try NFSROOT=192.168.1.11/tftpboot/pancho > ========== blacktower:/etc/bootptab ========== > pancho:\ > :hd=/tftpboot:\ > :bf=vmlinux:\ > :ht=ether:\ > :ha=08000993DA02:\ > :sm=255.255.255.0:\ > :hn:\ > :ip=192.168.1.13:\ > :vm=rfc1048: This is just a nit: bf= might be better named ":bf=lifimage\" (and you only need one colon between entry's :^) Copy /palo/lifimage to /tftpboot/lifimage. There must be something wrong but I don't see it. grant > kmem_create: Forcing size word alignment - nfs_fh > Looking up port of RPC 100003/2 on 192.68.1.11 > RPC: sendmsg returned error 229 > portmap: RPC call returned error 229 I don't see these types of errors on my config. Could be related to the misdirected NFSROOT. grant Grant Grundler Unix Systems Enablement Lab +1.408.447.7253 From j-perdue@tamu.edu Wed, 15 Nov 2000 14:14:13 -0600 Date: Wed, 15 Nov 2000 14:14:13 -0600 From: Jack Perdue j-perdue@tamu.edu Subject: Doh!!! was Re: [parisc-linux] nfsroot - 712/60 - RPC - help Of course, as soon I collected all that info and sent it I, in rereading, realized that I had put 192.68.1.11 in palo/Makefile instead of 192.168.1.11. Doh! However, since the info is out there now, can someone tell me what I need to resolve the following: [previous console output in previous mail] Switching from PDC console kmem_create: Forcing size word alignment - nfs_fh Looking up port of RPC 100003/2 on 192.168.1.11 Looking up port of RPC 100005/2 on 192.168.1.11 VFS: Mounted root (nfs filesystem) readonly. Kernel panic: No init found. Try passing init= option to kernel. jack j-perdue@tamu.edu From law@redhat.com Wed, 15 Nov 2000 13:30:59 -0700 Date: Wed, 15 Nov 2000 13:30:59 -0700 From: law@redhat.com law@redhat.com Subject: [parisc-linux] Single-stepping In message <200011151949.OAA22929@hiauly1.hia.nrc.ca>you write: > > I've been helping Alan Modra out with kernel changes to support > > single stepping for gdb. Paul Bame suggested I bounced our ideas > > off you in case you (or anyone else) had any comments. I havn't > > actually committed my changes yet. > > > > The basic approach is to use the recovery counter to generate > > a trap every instruction. The scheme is complicated because a > > suspended process may or may not return to user space via an RFI. > > I really don't know enough to comment on the implementation choice. Why > did you decide on this approach as opposed to inserting breaks and > enabling the taken branch branch trap (T)? It would appear that the recove > ry > counter was intended to provide software recovery from hardware faults > in fault tolerant systems. Possibly, Grant could comment on whether > it is actually useful for this purpose. Err, we tried that at the UofU in our mach port to the PA -- there's a problem with that scheme, though I don't remember precisely what it was. I believe there were cases where the recovery counter doesn't trigger a trap, possibly due to nullified instructions. You might look at the UofU BSD code, which I believe used breakpoints and branch taken traps instad. jeff From taggart@carmen.fc.hp.com Wed, 15 Nov 2000 13:49:18 -0700 Date: Wed, 15 Nov 2000 13:49:18 -0700 From: Matt Taggart taggart@carmen.fc.hp.com Subject: [parisc-linux] Palinux on a 712/60 Andrew Shugg writes... > Arnaud.ATOCH@oecd.org said: > > Hi, > > > > I got a couple of 715 and I'd love having access to an ISO image with STI > > console kernel too. > > I've never made an El Torito CDROM, is it possible to have multiple boot > images and a boot loader on a single disc? El Torito is a PC thing. It makes the front of a CDROM look like a floppy to the PC BIOS. For hppa you put a lifimage on the front of the CDROM(or tape or HDD, etc). > ie could the actual boot > image be a boot loader (PALO) which then points at one or more kernels > on the CDROM? Maybe. Paul Bame is the expert though. I think he had to do some work to get palo to be able to see a kernel on an ISO9660 filesystem. I don't know if it can currently be interruped and pointed at a different kernel. Paul? -- Matt Taggart taggart@fc.hp.com From drepper@redhat.com 15 Nov 2000 12:52:52 -0800 Date: 15 Nov 2000 12:52:52 -0800 From: Ulrich Drepper drepper@redhat.com Subject: [parisc-linux] Help with posix_types.h Paul Bame writes: > FYI I just heard some pretty good reasons why both ino_t and off_t > should be 64 bits even on 32-bit kernels. Keep those cards and letters > coming! Any new port which does *not* do this is broken from the beginning. Copying existing files is not what you have to do. Instead look at today's needs. The numbers of the x86 port are those the kernel people told me are needs, multiplied by 2 or 4. Do the same. -- ---------------. ,-. 1325 Chesapeake Terrace Ulrich Drepper \ ,-------------------' \ Sunnyvale, CA 94089 USA Red Hat `--' drepper at redhat.com `------------------------ From ich@johannes-zahn.de Wed, 15 Nov 2000 21:49:31 +0100 Date: Wed, 15 Nov 2000 21:49:31 +0100 From: johannes zahn ich@johannes-zahn.de Subject: [parisc-linux] init dies on apollo 720 Hi! I'm trying to get a 720/50 to boot from nfs, but as soon as the nfs mound happened init dies. This is all i get on the serial console (pasted from minicom): kmem_create: Forcing size word alignment - nfs_fh Looking up port of RPC 100003/2 on 192.168.1.1 Looking up port of RPC 100005/2 on 192.168.1.1 VFS: Mounted root (nfs filesystem) readonly. handle_interruption() pid=1 command='init' YZrvWESTHLNXBCVMcbcbcbcbOGFRQPDI PSW: 00000000000001001111011100001011 r0-3 00000000 4001ad3c 400057a3 00001f58 r4-7 4001967c 00000000 4001ada0 00001f58 r8-11 00000000 000023cc 00000001 00000000 r12-15 00001034 00000006 40019622 2001ff18 r16-19 c1fdc000 c027b60c 00000000 4001967c r20-23 0000a090 0000a090 00009d8c 00001f58 r24-27 00000001 00000081 4001ada0 c01492b0 r28-31 00000000 0000000b 20020790 400032d7 sr0-4 00000001 00000001 00000000 00000001 sr4-8 00000001 00000001 00000001 00000001 IASQ: 00000001 00000001 IAOQ: 4000d237 4000d23b IIR: 0ed51280 ISR: 00000001 IOR: 00009d8c ORIG_R28: 4001b208 handle_interruption() pid=1 command='init' YZrvWESTHLNXBCVMcbcbcbcbOGFRQPDI [...] I tried the cvs-latest kernel and palo from 2000-11-10 and 2000-11-14 with the crosscompiler from 2000-10-31. Buildhost is i386 linux. nfsroot was from 2000-10-09 or base.tgz from the 0.5 beta CD. I also tried the ramdisk images with sercon and sticon, but the kernel only says "cannot mount root FS on 01:00". The kernel from the 0.5 beta CD seems to have the parport stuff, and that does not work on this machine. Any ideas? Or a working .config? johannes From sieler@allegro.com Wed, 15 Nov 2000 13:08:15 -0800 (PST) Date: Wed, 15 Nov 2000 13:08:15 -0800 (PST) From: Stan Sieler sieler@allegro.com Subject: [parisc-linux] Single-stepping Re: > > The basic approach is to use the recovery counter to generate > > a trap every instruction. The scheme is complicated because a ... > I really don't know enough to comment on the implementation choice. Why > did you decide on this approach as opposed to inserting breaks and MPE/iX (which runs on PA-RISC hardware), has successfully used the Recovery Counter to implement single step for many, many years. BTW, in addition to single step, it's a great tool for counting the number of instructions a procedure (or code path) takes, assuming an adequately powerful debugger: 1) stop (perhaps via a breakpoint) at the start of the code you want to count. 2) set a breakpoint at the end of the code you want to count (e.g., if you're counting a procedure, set a breakpoint at the procedure exit) 3) instead of "continue", do: s 1000000 (i.e., tell Debug/iX to "singlestep" 1000000 instructions) 4) if you hit the breakpoint, enter: = 1000000 - rctr that's how many instructions your code took! (Not counting instructions executed by interrupt handlers, of course.) 5) if you *didn't* hit the breakpoint, then 1000000 wasn't enough instructions (and why are you trying to count so high?) This works because MPE's debug "s" command sets the Recovery Counter to the number of instructions you wanted to step. Normally, that's one (for just "s"). If you said "s 3", it would set the Recovery Counter to 3. If you say "s 1000000", and then execute 123 instructions, and then hit a breakpoint, Debug captures the entire register state as of the breakpoint: including the Recovery Counter (which has 1000000 - 123 in it). Tip: if you're looking at instruction-level debugging, look at Debug/iX to see how to do it right! > It would appear that the recovery > counter was intended to provide software recovery from hardware faults The 1986 PA-RISC Instruction manual simply says "The Recovery Counter (CR 0) can be used to provide software recovery of hardware faults in fault tolerant systems". (I.e., "can", not "must" ... and there's no explanation of how one would use it for this.) -- Stan Sieler sieler@allegro.com www.allegro.com/sieler/wanted/index.html www.sieler.com From drepper@redhat.com 15 Nov 2000 13:08:01 -0800 Date: 15 Nov 2000 13:08:01 -0800 From: Ulrich Drepper drepper@redhat.com Subject: [parisc-linux] Help with posix_types.h This reminds me of something I talked to Cary Coutant about before. You have certainly reserved a thread register in the ABI, right? If not, do it ASAP. -- ---------------. ,-. 1325 Chesapeake Terrace Ulrich Drepper \ ,-------------------' \ Sunnyvale, CA 94089 USA Red Hat `--' drepper at redhat.com `------------------------ From frank_rowand@mvista.com Wed, 15 Nov 2000 13:16:28 -0800 Date: Wed, 15 Nov 2000 13:16:28 -0800 From: Frank Rowand frank_rowand@mvista.com Subject: [parisc-linux] Single-stepping law@redhat.com wrote: > > In message <200011151949.OAA22929@hiauly1.hia.nrc.ca>you write: > > > I've been helping Alan Modra out with kernel changes to support > > > single stepping for gdb. Paul Bame suggested I bounced our ideas > > > off you in case you (or anyone else) had any comments. I havn't > > > actually committed my changes yet. > > > > > > The basic approach is to use the recovery counter to generate > > > a trap every instruction. The scheme is complicated because a > > > suspended process may or may not return to user space via an RFI. > > > > I really don't know enough to comment on the implementation choice. Why > > did you decide on this approach as opposed to inserting breaks and > > enabling the taken branch branch trap (T)? It would appear that the recove > > ry > > counter was intended to provide software recovery from hardware faults > > in fault tolerant systems. Possibly, Grant could comment on whether > > it is actually useful for this purpose. > Err, we tried that at the UofU in our mach port to the PA -- there's a problem > with that scheme, though I don't remember precisely what it was. I believe > there were cases where the recovery counter doesn't trigger a trap, possibly > due to nullified instructions. > > You might look at the UofU BSD code, which I believe used breakpoints and > branch taken traps instad. > > jeff > I implemented two different single step algorithms for a a _kernel_ debugger for hp-ux. The algorithm used could be chosen by a compile switch, because each method had cases that weren't handled well - for some debugging tasks one algorithm was superior to the other. Part of my problem with the recovery counter was that other services in the hp-ux kernel also used the recovery counter. I liked the recovery counter method better than my second method (but had to deal with collisions with the other kernel services). My second method was to insert a breakpoint at the target of the single step. It's a pain to do that because of issues with delay slots, branching, and nullification. I guess the point of all this rambling is to say that the recovery counter has been successfully used by a debugger for single stepping. -Frank -- Frank Rowand MontaVista Software, Inc From sieler@allegro.com Wed, 15 Nov 2000 13:47:15 -0800 (PST) Date: Wed, 15 Nov 2000 13:47:15 -0800 (PST) From: Stan Sieler sieler@allegro.com Subject: [parisc-linux] Single-stepping Re: > I implemented two different single step algorithms for a a _kernel_ debugger > for hp-ux. The algorithm used could be chosen by a compile switch, because BTW, Frank, ask Lee Courtney at MontaVista about Debug/iX ... we've had kernel debugging and single stepping (except for the interrupt control stack and a few other corner cases) for 15+ years. It's *very* powerful to be able to logon as root (or equivalent) and set breakpoints within the kernel, hit them, and then single step ... all on a standard release of the operating system. > I liked the recovery counter method better than my second method (but had to > deal with collisions with the other kernel services). My second method was > to insert a breakpoint at the target of the single step. It's a pain to do > that because of issues with delay slots, branching, and nullification. Worse yet...the breakpoint mechanism raises hell if you have more than one CPU :) You realllly don't want that other CPU to hit the breakpoint! -- Stan Sieler sieler@allegro.com www.allegro.com/sieler/wanted/index.html www.sieler.com From andreas@bawue.de Thu, 16 Nov 2000 23:06:04 +0100 Date: Thu, 16 Nov 2000 23:06:04 +0100 From: Andreas Thienemann andreas@bawue.de Subject: [parisc-linux] 250/1 doesn't boot but dumps stack Hi Grant, Grant Grundler wrote: > > lp0: using parport0 (interrupt-driven). > Are you sure you left out parallel port support? Yes, I am. I just attached the wrong log. Except the lp0 line, there are no differences... > > IASQ: 00000000 00000000 IAOQ: c029c264 c029c268 > > IIR: 0e681096 ISR: 00000000 IOR: 00000004 > > ORIG_R28: 00000000 > Smells like a driver bug. > Can you look up IOAQ and GR2 (c029c264 and c029c248) in System.map file? Of course. The only problem is, there is no such entry in /usr/src/pa-risc/sourcE/linux/System.map . Any ideas? andreas From rhirst@linuxcare.com Wed, 15 Nov 2000 22:19:29 +0000 Date: Wed, 15 Nov 2000 22:19:29 +0000 From: Richard Hirst rhirst@linuxcare.com Subject: [parisc-linux] dino maintainer? On Wed, Nov 15, 2000 at 09:58:35AM +0000, Richard Hirst wrote: > But Helge has problems with the sym53c8xx driver on a B160L. Is Turned out to be a 53c720, driven via Zalon and the ncr53c8xx driver. Driver worked as a module, but not compiled in. Now fixed. Richard From rlduncan@nortelnetworks.com Wed, 15 Nov 2000 17:28:13 -0500 Date: Wed, 15 Nov 2000 17:28:13 -0500 From: Robert Duncan rlduncan@nortelnetworks.com Subject: [parisc-linux] CD-ROM 715/50 boot dies after serial driver... This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C04F53.576F0F70 Content-Type: text/plain; charset="iso-8859-1" Greetings, I have downloaded the .5 Beta CDROM image, burned it and get a "fault in kernel" after the "Serial driver ... enabled" message when booting on my 715/50. This happens with either graphics or serial console configured in NVRAM. Has anyone else seen this error? ----------------begin console output (c) Copyright Hewlett-Packard Company, 1991, 1992 Portions of this code are (c) Copyright Samsung Electronics Co., Ltd, 91, 92 PDC ROM rev. 1.2 IODC ROM rev. 1.1 64 MB of memory have been configured. Selecting a system to boot. To stop selection process, press and hold the ESCAPE key..... Booting from: scsi.6.0 TOSHIBA CD-ROM XM-3501TA Soft booted. palo ipl bame@noam Tue Oct 31 14:18:02 MST 2000 0/vmlinux 2140145 bytes @ 0x6f9800 0/palo-cmdline '0/vmlinux ROOT=/ TERM=LINUX root=/dev/scd0' Kernel: partition 0 file /vmlinux ELF32 executable Entry 00100150 first 00100000 n 4 Segment 0 load 00100000 size 1460344 mediaptr 0x1000 Segment 1 load 00266000 size 179048 mediaptr 0x166000 Segment 2 load 00294000 size 109876 mediaptr 0x192000 Segment 3 load 002b0000 size 8192 mediaptr 0x1ad000 branching to kernel entry point 0x00100150 PDC Console Initialized The 32-bit Kernel has started... Enabled FP coprocessor Free memory starts at: 0xc02da000 (0x504d6c,0x504d6c,0x0,0x0) PALO command line: 'ROOT=/ TERM=LINUX root=/dev/scd0' PALO initrd 0-0 model 00003100 00000481 00000000 00000000 77a94524 ffffffff 00000004 0000000a 0000000a vers 00000009 CPUID vers 0 rev 0 Searching for devices in PDC firmware... processor hpa 0xfffbe000 an older box... Found devices: 1. Stinger Optional Graphics (10) at 0xf4000000, versions 0x6, 0x0, 0x77, 0x0, 0x0 2. Scorpio Core BA (11) at 0xf082f000, versions 0x7, 0x0, 0x70, 0x0, 0x0 3. Scorpio Core SCSI (10) at 0xf0825000, versions 0x7, 0x0, 0x71, 0x0, 0x0 4. Scorpio Core LAN (802.3) (10) at 0xf0826000, versions 0x7, 0x0, 0x72, 0x0, 0x0 5. Scorpio Core HIL (10) at 0xf0821000, versions 0x7, 0x0, 0x73, 0x0, 0x0 6. Scorpio Core RS-232 (10) at 0xf0823000, versions 0x7, 0x0, 0x75, 0x0, 0x0 7. Scorpio Core RS-232 (10) at 0xf0822000, versions 0x7, 0x0, 0x75, 0x0, 0x0 8. Scorpio Core Centronics (10) at 0xf0824000, versions 0x7, 0x0, 0x74, 0x0, 0x0 9. Scorpio Audio (10) at 0xf1000000, versions 0x7, 0x0, 0x7b, 0x0, 0x0 10. Scorpio EISA BA (11) at 0xfc000000, versions 0x7, 0x0, 0x76, 0x0, 0x0 11. Scorpio (715/50) (0) at 0xfffbe000, versions 0x310, 0x0, 0x4, 0x0, 0x81 12. Scorpio (1) at 0xfffbf000, versions 0x17, 0x0, 0x9, 0x0, 0x0 That's a total of 12 devices. CPU(s): 1 x PA7100 (PCX-T) at 50.000000 MHz Linux version 2.4.0-test6 (pjlahaie@elenuial.thepuffingroup.com) (gcc version 2.96 20000925 (experimental)) #32 Mon Nov 6 10:20:58 EST 2000 free_bootmem(0x2da800, 0x3d25800) initrd: 00000000-00000000 pagetable_init On node 0 totalpages: 16384 zone(0): 8192 pages. zone(1): 8192 pages. zone(2): 0 pages. Kernel command line: ROOT=/ TERM=LINUX root=/dev/scd0 trap_init Calibrating delay loop... 49.77 BogoMIPS Memory: 61388k available Dentry-cache hash table entries: 8192 (order: 4, 65536 bytes) Buffer-cache hash table entries: 4096 (order: 2, 16384 bytes) Page-cache hash table entries: 16384 (order: 4, 65536 bytes) Inode-cache hash table entries: 4096 (order: 3, 32768 bytes) POSIX conformance testing by UNIFIX ASP version 1 at 0xf0800000 found. Found i82596 at 0xf0826000, IRQ 87 early initialization of device eth0 is deferred Found HIL at 0xf0821000, IRQ 94 HIL: no keyboard present. Warning : device (10, 0x7, 0x0, 0x73, 0x0) NOT claimed by HIL 712, 715 or similiar Linux NET4.0 for Linux 2.4 Based upon Swansea University Computer Society NET3.039 NET4: Unix domain sockets 1.0/SMP for Linux NET4.0. NET4: Linux TCP/IP 1.0 for NET4.0 IP Protocols: ICMP, UDP, TCP IP: routing cache hash table of 512 buckets, 4Kbytes TCP: Hash tables configured (established 4096 bind 4096) Starting kswapd v1.7 pty: 256 Unix98 ptys configured lp: driver loaded but no devices found RAMDISK driver initialized: 16 RAM disks of 4096K size 1024 blocksize sim700: Couldn't get consistent shared memory sim700: Configuring 53c700 (SCSI-ID 7) at f0825100, IRQ 86 scsi0: Revision 0x0 Post test1, istat 05, sstat0 00, dstat 84 sim700: WARNING IRQ probe failed, (returned 0) scsi0: WARNING: target data areas are not dma coherent! scsi0: test 1 completed ok. scsi0: sim700_intr_handle() called with no interrupt scsi0 : LASI/Simple 53c7xx scsi : 1 host. Vendor: TOSHIBA Model: CD-ROM XM-3501TA Rev: 3054 Type: CD-ROM ANSI SCSI revision: 02 Detected scsi CD-ROM sr0 at scsi0, channel 0, id 6, lun 0 scsi : detected 1 SCSI cdrom total. Uniform CD-ROM driver Revision: 3.11 82596.c: MAC of HP700 LAN blindely read from the prom! eth0: Couldn't get consistent shared memory eth0: 82596 at 0xf0826000, 08 00 09 42 1B 37 IRQ 87. 82596.c $Revision: 1.14 $ Serial driver version 5.01 (2000-05-29) with MANY_PORTS SHARE_IRQ SERIAL_PCI enabled Dumping Stack from c3fc4000 to c3fc4bc0: 4000 00000000 00000140 00000000 00000000 c027a46c 00000001 00000000 ffffffff 4020 00000000 00000000 00000000 00000000 00000000 00000000 ffffffff c027a384 [...] 4ba0 ffffffff bffff5ff ffffff7f c01046e0 ffffbeff f7b7eddf 5fffffdf feefffff Data access rights fault in kernel: Code=26 regs=c3fc4980 (Addr=00000003) YZrvWESTHLNXBCVMcbcbcbcbOGFRQPDI PSW: 00000000000001000000000000001010 r0-3 00000000 c0221800 c011e9f8 c3fce420 r4-7 c3fce200 c0244f10 00000008 f0823800 r8-11 00000003 00000007 c0191568 c02c60a4 r12-15 fffffffc c0245000 c0245000 c02d72b8 r16-19 c0245000 c0245000 c02c6028 00000000 r20-23 c3fce234 f0823807 f0823800 0000000a r24-27 ffffffff c3fce420 c3fce200 c0266000 r28-31 ffffffff 00000240 c3fc4bc0 c012dfc0 sr0-4 00000000 00000000 00000000 00000000 sr4-8 00000000 00000000 00000000 00000000 IASQ: 00000000 00000000 IAOQ: c011e710 c011e714 IIR: 0f881093 ISR: 00000000 IOR: 00000003 ORIG_R28: 00000058 ----------------end console output thanks, Robert Duncan Nortelnetworks ------_=_NextPart_001_01C04F53.576F0F70 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable CD-ROM 715/50 boot dies after serial driver...

Greetings,
I have downloaded the .5 Beta CDROM image, burned it = and get a "fault in kernel" after the "Serial driver ... = enabled" message when booting on my 715/50.  This happens = with either graphics or serial console configured in NVRAM.

Has anyone else seen this error?

----------------begin console output
          &nb= sp;   (c) Copyright Hewlett-Packard Company, 1991, = 1992
Portions of this code are (c) Copyright Samsung = Electronics Co., Ltd, 91, 92

PDC ROM rev. 1.2
IODC ROM rev. 1.1
64 MB of memory have been configured.


Selecting a system to boot.
To stop selection process, press and hold the ESCAPE = key.....

Booting from:     = scsi.6.0     TOSHIBA CD-ROM XM-3501TA

Soft booted.
palo ipl bame@noam Tue Oct 31 14:18:02 MST = 2000
0/vmlinux 2140145 bytes @ 0x6f9800
0/palo-cmdline '0/vmlinux ROOT=3D/ TERM=3DLINUX = root=3D/dev/scd0'
Kernel: partition 0 file /vmlinux
ELF32 executable

Entry 00100150 first 00100000 n 4
Segment 0 load 00100000 size 1460344 mediaptr = 0x1000
Segment 1 load 00266000 size 179048 mediaptr = 0x166000
Segment 2 load 00294000 size 109876 mediaptr = 0x192000
Segment 3 load 002b0000 size 8192 mediaptr = 0x1ad000
branching to kernel entry point 0x00100150
PDC Console Initialized
The 32-bit Kernel has started...
Enabled FP coprocessor
Free memory starts at: 0xc02da000
(0x504d6c,0x504d6c,0x0,0x0)
PALO command line: 'ROOT=3D/ TERM=3DLINUX = root=3D/dev/scd0'
PALO initrd 0-0
model   00003100 00000481 00000000 = 00000000 77a94524 ffffffff 00000004 0000000a 0000000a
vers    00000009
CPUID vers 0 rev 0
Searching for devices in PDC firmware... processor = hpa 0xfffbe000
 an older box...
Found devices:
1. Stinger Optional Graphics (10) at 0xf4000000, = versions 0x6, 0x0, 0x77, 0x0, 0x0
2. Scorpio Core BA (11) at 0xf082f000, versions 0x7, = 0x0, 0x70, 0x0, 0x0
3. Scorpio Core SCSI (10) at 0xf0825000, versions = 0x7, 0x0, 0x71, 0x0, 0x0
4. Scorpio Core LAN (802.3) (10) at 0xf0826000, = versions 0x7, 0x0, 0x72, 0x0, 0x0
5. Scorpio Core HIL (10) at 0xf0821000, versions = 0x7, 0x0, 0x73, 0x0, 0x0
6. Scorpio Core RS-232 (10) at 0xf0823000, versions = 0x7, 0x0, 0x75, 0x0, 0x0
7. Scorpio Core RS-232 (10) at 0xf0822000, versions = 0x7, 0x0, 0x75, 0x0, 0x0
8. Scorpio Core Centronics (10) at 0xf0824000, = versions 0x7, 0x0, 0x74, 0x0, 0x0
9. Scorpio Audio (10) at 0xf1000000, versions 0x7, = 0x0, 0x7b, 0x0, 0x0
10. Scorpio EISA BA (11) at 0xfc000000, versions = 0x7, 0x0, 0x76, 0x0, 0x0
11. Scorpio (715/50) (0) at 0xfffbe000, versions = 0x310, 0x0, 0x4, 0x0, 0x81
12. Scorpio (1) at 0xfffbf000, versions 0x17, 0x0, = 0x9, 0x0, 0x0
That's a total of 12 devices.
CPU(s): 1 x PA7100 (PCX-T) at 50.000000 MHz
Linux version 2.4.0-test6 = (pjlahaie@elenuial.thepuffingroup.com) (gcc version 2.96 20000925 = (experimental)) #32 Mon Nov 6 10:20:58 EST 2000

free_bootmem(0x2da800, 0x3d25800)
initrd: 00000000-00000000
pagetable_init
On node 0 totalpages: 16384
zone(0): 8192 pages.
zone(1): 8192 pages.
zone(2): 0 pages.
Kernel command line: ROOT=3D/ TERM=3DLINUX = root=3D/dev/scd0
trap_init
Calibrating delay loop... 49.77 BogoMIPS
Memory: 61388k available
Dentry-cache hash table entries: 8192 (order: 4, = 65536 bytes)
Buffer-cache hash table entries: 4096 (order: 2, = 16384 bytes)
Page-cache hash table entries: 16384 (order: 4, = 65536 bytes)
Inode-cache hash table entries: 4096 (order: 3, = 32768 bytes)
POSIX conformance testing by UNIFIX
ASP version 1 at 0xf0800000 found.
Found i82596 at 0xf0826000, IRQ 87
early initialization of device eth0 is = deferred
Found HIL at 0xf0821000, IRQ 94
HIL: no keyboard present.
Warning : device (10, 0x7, 0x0, 0x73, 0x0) NOT = claimed by HIL 712, 715 or similiar
Linux NET4.0 for Linux 2.4
Based upon Swansea University Computer Society = NET3.039
NET4: Unix domain sockets 1.0/SMP for Linux = NET4.0.
NET4: Linux TCP/IP 1.0 for NET4.0
IP Protocols: ICMP, UDP, TCP
IP: routing cache hash table of 512 buckets, = 4Kbytes
TCP: Hash tables configured (established 4096 bind = 4096)
Starting kswapd v1.7
pty: 256 Unix98 ptys configured
lp: driver loaded but no devices found
RAMDISK driver initialized: 16 RAM disks of 4096K = size 1024 blocksize
sim700: Couldn't get consistent shared memory
sim700: Configuring 53c700 (SCSI-ID 7) at f0825100, = IRQ 86
scsi0: Revision 0x0
Post test1, istat 05, sstat0 00, dstat 84
sim700: WARNING IRQ probe failed, (returned = 0)
scsi0: WARNING: target data areas are not dma = coherent!
scsi0: test 1 completed ok.
scsi0: sim700_intr_handle() called with no = interrupt
scsi0 : LASI/Simple 53c7xx
scsi : 1 host.
  Vendor: TOSHIBA   Model: CD-ROM = XM-3501TA  Rev: 3054
  Type:   = CD-ROM           =             =       ANSI SCSI revision: 02
Detected scsi CD-ROM sr0 at scsi0, channel 0, id 6, = lun 0
scsi : detected 1 SCSI cdrom total.
Uniform CD-ROM driver Revision: 3.11
82596.c: MAC of HP700 LAN blindely read from the = prom!
eth0: Couldn't get consistent shared memory
eth0: 82596 at 0xf0826000, 08 00 09 42 1B 37 IRQ = 87.
82596.c $Revision: 1.14 $
Serial driver version 5.01 (2000-05-29) with = MANY_PORTS SHARE_IRQ SERIAL_PCI enabled

Dumping Stack from c3fc4000 to c3fc4bc0:
4000 00000000 00000140 00000000 00000000 c027a46c = 00000001 00000000 ffffffff
4020 00000000 00000000 00000000 00000000 00000000 = 00000000 ffffffff c027a384
 [...]
4ba0 ffffffff bffff5ff ffffff7f c01046e0 ffffbeff = f7b7eddf 5fffffdf feefffff

Data access rights fault in kernel: Code=3D26 = regs=3Dc3fc4980 (Addr=3D00000003)

     = YZrvWESTHLNXBCVMcbcbcbcbOGFRQPDI
PSW: 00000000000001000000000000001010
r0-3     00000000 c0221800 = c011e9f8 c3fce420
r4-7     c3fce200 c0244f10 = 00000008 f0823800
r8-11    00000003 00000007 c0191568 = c02c60a4
r12-15   fffffffc c0245000 c0245000 = c02d72b8
r16-19   c0245000 c0245000 c02c6028 = 00000000
r20-23   c3fce234 f0823807 f0823800 = 0000000a
r24-27   ffffffff c3fce420 c3fce200 = c0266000
r28-31   ffffffff 00000240 c3fc4bc0 = c012dfc0
sr0-4    00000000 00000000 00000000 = 00000000
sr4-8    00000000 00000000 00000000 = 00000000

IASQ: 00000000 00000000 IAOQ: c011e710 = c011e714
 IIR: 0f881093    ISR: = 00000000  IOR: 00000003
ORIG_R28: 00000058

----------------end console output

thanks,
Robert Duncan
Nortelnetworks

------_=_NextPart_001_01C04F53.576F0F70-- From rhirst@linuxcare.com Wed, 15 Nov 2000 22:35:40 +0000 Date: Wed, 15 Nov 2000 22:35:40 +0000 From: Richard Hirst rhirst@linuxcare.com Subject: [parisc-linux] CD-ROM 715/50 boot dies after serial driver... On Wed, Nov 15, 2000 at 05:28:13PM -0500, Robert Duncan wrote: > Greetings, > I have downloaded the .5 Beta CDROM image, burned it and get a "fault in > kernel" after the "Serial driver ... enabled" message when booting on my > 715/50. This happens with either graphics or serial console configured in > NVRAM. > > Has anyone else seen this error? I get exactly the same on my 715/75. Havn't had time to investigate yet. Richard From andreas@bawue.de Thu, 16 Nov 2000 23:42:35 +0100 Date: Thu, 16 Nov 2000 23:42:35 +0100 From: Andreas Thienemann andreas@bawue.de Subject: [parisc-linux] 250/1 doesn't boot but dumps stack Grant Grundler wrote: > > IASQ: 00000000 00000000 IAOQ: c029c264 c029c268 > > IIR: 0e681096 ISR: 00000000 IOR: 00000004 > > ORIG_R28: 00000000 > Smells like a driver bug. > Can you look up IOAQ and GR2 (c029c264 and c029c248) in System.map file? Okay, here we go (thanks for the build-tool information...) System Map output: 0xc029c264 __init_begin+264 0xc029x248 __init_begin+248 andreas From kailasr@webcash.com Wed, 15 Nov 2000 15:41:55 -0800 Date: Wed, 15 Nov 2000 15:41:55 -0800 From: Kailashnath V Rampure kailasr@webcash.com Subject: [parisc-linux] Apache package. --=====================_108207293==_.ALT Content-Type: text/plain; charset="us-ascii"; format=flowed Hi I tried to build apache_1.3.12 on HP a class server. But I have error. I have tried to check the site ftp://ftp.debian.org/debian/dists/unstable/main/binary-hppa/ I could not find one. I found some apache-doc etc. Can any on point me where I can try. Regards Kailas --=====================_108207293==_.ALT Content-Type: text/html; charset="us-ascii" Hi

I tried to build apache_1.3.12 on HP a class server. But I have error. I have tried to check the site ftp://ftp.debian.org/debian/dists/unstable/main/binary-hppa/
I could not find one. I found some apache-doc etc.

Can any on point me where I can try.
Regards
Kailas --=====================_108207293==_.ALT-- From bame@noam.fc.hp.com Wed, 15 Nov 2000 16:59:18 -0700 Date: Wed, 15 Nov 2000 16:59:18 -0700 From: Paul Bame bame@noam.fc.hp.com Subject: [parisc-linux] Apache package. = I tried to build apache_1.3.12 on HP a class server. But I have error. I = have tried to check the site = ftp://ftp.debian.org/debian/dists/unstable/main/binary-hppa/ = I could not find one. I found some apache-doc etc. We are still working on some kernel features which are required to support Apache (system 5 shared memory). -P From cary@cup.hp.com Wed, 15 Nov 2000 16:00:49 -0800 Date: Wed, 15 Nov 2000 16:00:49 -0800 From: Cary Coutant cary@cup.hp.com Subject: [parisc-linux] Help with posix_types.h >You have certainly reserved a thread register in the ABI, right? If >not, do it ASAP. On PA-RISC, the thread pointer is kept in the read-only control register CR 27. For user-thread implementations, we provided a kernel API to change the contents of the register. -cary From drepper@redhat.com 15 Nov 2000 16:04:51 -0800 Date: 15 Nov 2000 16:04:51 -0800 From: Ulrich Drepper drepper@redhat.com Subject: [parisc-linux] Help with posix_types.h Cary Coutant writes: > On PA-RISC, the thread pointer is kept in the read-only control register > CR 27. > > For user-thread implementations, we provided a kernel API to change the > contents of the register. This works fine for a 1:1 thread implementation but adds significant runtime hits for a m:n implementation. The latter is the direction we are heading. -- ---------------. ,-. 1325 Chesapeake Terrace Ulrich Drepper \ ,-------------------' \ Sunnyvale, CA 94089 USA Red Hat `--' drepper at redhat.com `------------------------ From jsm@udlkern.fc.hp.com Thu, 16 Nov 2000 02:01:12 -0700 (MST) Date: Thu, 16 Nov 2000 02:01:12 -0700 (MST) From: John Marvin jsm@udlkern.fc.hp.com Subject: Single-stepping > I've been helping Alan Modra out with kernel changes to support > single stepping for gdb. Paul Bame suggested I bounced our ideas > off you in case you (or anyone else) had any comments. I havn't > actually committed my changes yet. > I've decided to respond to the whole list, since others are now participating in the discussion. > The basic approach is to use the recovery counter to generate > a trap every instruction. The scheme is complicated because a > suspended process may or may not return to user space via an RFI. > There is no easy way to do single stepping on parisc. So any single stepping design will be complicated. > If it was suspended as a result of an interrupt then we can > simply set PSW bit R in the tasks saved registers and it will > get loaded by the RFI. On every task switch I set the > recovery counter to 0, just in case the new process is being > single-stepped. > > If a process is suspended during a syscall, then there is no > RFI on the return path to userland, and we have to handle things > differently. I have changed the syscall return path such that > it loads the recovery counter with 3 before updating the PSW > with a value from the tasks saved registers. If that PSW has > the R bit set, then the count of 3 will generate a trap on the > first instruction following the branch back to user space. > Note that PSW wasn't previously restored on the syscall return > path. > Just to be clear, it is impossible to restore the entire PSW without an RFI. So, I assume you are referring to the system mask subset of the PSW that can be manipulated by the ssm,rsm, and mtsm instructions. You mention restoring from the task's saved registers, but we currently do not save the system mask during a syscall (because it should be the same for all processes). Have you added code to do that also? If not, you are restoring from whatever the state was at the last interruption. Which in this case works (since the R bit state will be changed by another process while the debugged process is suspended, this should guarantee that the R bit state is up to date), but it seems a little ugly. In my opinion, you should just be checking a bit in the ptrace flags in the task structure, and setting the R bit with an ssm instruction based on that. > To avoid further complications of interrupts during the three > instructions when the recovery counter is decrementing, whenever > we set the R bit, we also clear the I bit to disable interrupts. Yuck, but I agree that it would be messier to have to deal with this in the interrupt handlers. Please make sure that a comment is added that explains what you are doing, and clearly documents the dependency on the number of remaining instructions before we return to user privilege level. I assume you restore the I bit in the recovery counter trap handler. I can think of alternative ways of doing this, but they are probably just as ugly (e.g. one possibility would be to do an rfi to set the L bit). > > Nullified instructions are handled by the controlling process > manually moving the childs IAOQ over the instruction without > actually setting it running, because the recovery counter isn't > decremented for nullified instructions. Does this code properly handle branches in the delay slot of another branch? (you need to make sure you are not advancing the queues by just adding 4 to each element). One concern I have about this method is that the userland debugger has to cooperate to make this design work, i.e. the single stepping is not accomplished entirely within the kernel, so we cannot easily change the design for single stepping at a later date. I wonder if it is necessary to do this. So what if we don't stop on the nullified instruction. Since it is nullified, it doesn't actually do anything, so why does the user have to see it, i.e. just let the recovery counter trap happen on the next truly executed instruction (i.e. the debugger performs a "double step" in this case). Am I missing something here? > > I need to do some more testing before committing this, but would > welcome any comments on the basic approach taken, areas I have > mis-understood, or problems with it that might not yet have > occurred to me. OK, well here are some issues that you didn't mention, so I don't know whether or not you addressed them: 1) When single stepping over a syscall, when do you actually stop the single stepping and execute the syscall? Hopefully you are not allowing single stepping after the gate instruction on the gateway page (and returning control to a non privileged debugging process). The recovery counter trap should detect when the user code gets to the gateway page. 2) Does your solution properly handle single stepping into and out of a signal handler? Note that the debugger will trap the signal as part of this process. Since the return is handled through a hidden syscall you may not have to do anything special here. Note that HP-UX does not use the recovery counter for single stepping. I made a few phone calls to various engineers to find out what the design process was, and why they chose the solution they did, but I could not find anyone who knew. Looking at the code in HP-UX it looks like someone implemented that code a long time ago, and some of the engineers who have worked on it since don't understand it, because some of the comments added since then clearly show a lack of understanding of what is really going on. Others on this list have mentioned that MPE does use the recovery counter for single stepping. Of course, MPE is not a Unix clone, so just because it could be done on MPE doesn't mean that the recovery counter can cover all cases on Unix (e.g. I have no idea how signals and syscalls are implemented on MPE). But since I have no idea why the recovery counter was not used for HP-UX, I can't say it is the wrong way to go. I can't think of anything that will definitely rule it out, I'm just a little uncomfortable with the fact that HP-UX chose not to use it. One advantage of the HP-UX method is that it completely encapsulates the single stepping inside the kernel, so it can be changed if necessary, without having to modify gdb (and having to worry about old versions of gdb). Anyway, for reference, HP-UX does single stepping by using a combination of the taken branch trap, and loading the instruction queues such that the front of the queue points to the next instruction to be single stepped and the back of the queue points to the first of two break instructions on a "break" page. It does NOT insert break instructions into the code, so it does not adversely affect execution on a SMP machine. Note that we already put a bunch of break instructions before the syscall entry point on the gateway page, so it would be easy to use our gateway page for the "break page". This way, if the single stepped instruction branches, a taken branch trap will be taken (which is important in the case where the branch nullifies its delay slot). Otherwise, the instruction will be executed and then the break instruction at the known location on the "break" page will be executed. If the single stepped instruction nullifies the next instruction, the second break instruction on the "break" page will be executed. Note that this is the short explanation. It is not as simple as it sounds. One major complication is that branches with links don't work properly with the instruction queue magic, so the link register has to be updated in the taken branch trap handler. Also branch externals won't update the space of the space queue tail properly (again, that has to be fixed in the taken branch handler). I can provide more details if the recovery counter method doesn't work out. Sincerely, John Marvin jsm@fc.hp.com From marteaut@esiee.fr Thu, 16 Nov 2000 10:04:07 +0100 Date: Thu, 16 Nov 2000 10:04:07 +0100 From: Thomas Marteau marteaut@esiee.fr Subject: [parisc-linux] nfsroot - 712/60 - RPC - help Hi Jack, > (c) Copyright 1990-1993, Hewlett-Packard Company. > All rights reserved > > Press to stop boot sequence. > Selecting a system to boot. > > Booting > palo ipl jkp2866@redtower Wed Nov 15 12:44:21 CST 2000 > 0/vmlinux 1606438 bytes @ 0x6800 > 0/palo-cmdline '0/vmlinux HOME=/ TERM=LINUX root=/dev/nfs nfsroot=192.68.1.11:/tftpboot/pancho ' Are you sure that the command line is rigth? Is your Server address is 192.-68-.1.11 Here is probably your mistake! Bye, ESIEE Team Visit http://www.esiee.fr/puffin > Kernel: partition 0 file /vmlinux > ELF32 executable > > Entry 00100000 first 00100000 n 4 > Segment 0 load 00100000 size 1097900 mediaptr 0x1000 > Segment 1 load 0020e000 size 150520 mediaptr 0x10e000 > Segment 2 load 00234000 size 55900 mediaptr 0x133000 > Segment 3 load 00244000 size 8192 mediaptr 0x141000 > branching to kernel entry point 0x00100000 > Set default PSW W bit to 0 > PDC Console Initialized > The 32-bit Kernel has started... > Enabled FP coprocessor > Free memory starts at: 0xc026e000 > start_parisc(0x504d6c,0x504d6c,0x0,0x0) > PALO command line: 'HOME=/ TERM=LINUX root=/dev/nfs nfsroot=192.68.1.11:/tftpboot/pancho ' > PALO initrd 0-0 > model 00006000 00000481 00000000 00000000 77564139 00000000 00000004 00000072 00000072 > vers 0000000a > CPUID vers 0 rev 0 > Searching for devices in PDC firmware... processor hpa 0xfffbe000 > an older box... > Found devices From rhirst@linuxcare.com Thu, 16 Nov 2000 12:00:47 +0000 Date: Thu, 16 Nov 2000 12:00:47 +0000 From: Richard Hirst rhirst@linuxcare.com Subject: Single-stepping Hi John, On Thu, Nov 16, 2000 at 02:01:12AM -0700, John Marvin wrote: > Just to be clear, it is impossible to restore the entire PSW without > an RFI. So, I assume you are referring to the system mask subset of > the PSW that can be manipulated by the ssm,rsm, and mtsm instructions. Yes, mtsm in this case. > You mention restoring from the task's saved registers, but we currently > do not save the system mask during a syscall (because it should be the > same for all processes). Have you added code to do that also? If not, Yes I have. > you are restoring from whatever the state was at the last interruption. > Which in this case works (since the R bit state will be changed > by another process while the debugged process is suspended, this should > guarantee that the R bit state is up to date), but it seems a little ugly. > In my opinion, you should just be checking a bit in the ptrace flags > in the task structure, and setting the R bit with an ssm instruction > based on that. Sounds better, I'll look in to it. > > Nullified instructions are handled by the controlling process > > manually moving the childs IAOQ over the instruction without > > actually setting it running, because the recovery counter isn't > > decremented for nullified instructions. Sorry, I worded that very badly. The code that moves the childs IAOQ on is in the kernel, invoked as a result of the controlling process calling ptrace(PTRACE_SINGLESTEP...) when the childs N bit is set. > Does this code properly handle branches in the delay slot of another > branch? (you need to make sure you are not advancing the queues by just > adding 4 to each element). One concern I have about this method is that Current code does /* Nullified, just crank over the queue. */ task_regs(child)->iaoq[0] = task_regs(child)->iaoq[1]; task_regs(child)->iasq[0] = task_regs(child)->iasq[1]; task_regs(child)->iaoq[1] = task_regs(child)->iaoq[0] + 4; Does that look right to you? > I wonder if it is necessary to do this. So what if we don't stop on the > nullified instruction. Since it is nullified, it doesn't actually do > anything, so why does the user have to see it, i.e. just let the recovery > counter trap happen on the next truly executed instruction (i.e. the > debugger performs a "double step" in this case). Am I missing something > here? I don't see why we really need to stop on a nullified instruction, but I'll wait for Alan to comment as he wrote this initially. > 1) When single stepping over a syscall, when do you actually stop the > single stepping and execute the syscall? Hopefully you are not > allowing single stepping after the gate instruction on the gateway > page (and returning control to a non privileged debugging process). > The recovery counter trap should detect when the user code gets > to the gateway page. At the moment my test harness notes IAOQ=0x100 and stops single stepping, but obviously the kernel needs to enforce that. > 2) Does your solution properly handle single stepping into and out of > a signal handler? Note that the debugger will trap the signal as part > of this process. Since the return is handled through a hidden syscall > you may not have to do anything special here. Havn't looked at signal handling yet. > Note that HP-UX does not use the recovery counter for single stepping. I Thanks for the description of how HP-UX does it. I'll stick with the recovery counter for now as it does seem to be basically working. I'll also try to ensure that it is completely encapsulated within the kernel so it is less painful to change later, if need be. Thanks, Richard From rhirst@linuxcare.com Thu, 16 Nov 2000 12:09:57 +0000 Date: Thu, 16 Nov 2000 12:09:57 +0000 From: Richard Hirst rhirst@linuxcare.com Subject: [parisc-linux] Single-stepping On Wed, Nov 15, 2000 at 02:49:02PM -0500, John David Anglin wrote: > > I've been helping Alan Modra out with kernel changes to support > > single stepping for gdb. Paul Bame suggested I bounced our ideas > > off you in case you (or anyone else) had any comments. I havn't > > actually committed my changes yet. > > > > The basic approach is to use the recovery counter to generate > > a trap every instruction. The scheme is complicated because a > > suspended process may or may not return to user space via an RFI. > > I really don't know enough to comment on the implementation choice. Why > did you decide on this approach as opposed to inserting breaks and > enabling the taken branch branch trap (T)? It would appear that the recovery > counter was intended to provide software recovery from hardware faults > in fault tolerant systems. Possibly, Grant could comment on whether > it is actually useful for this purpose. Alan Modra made those early decisions, but I gather that he went for the recovery counter because it at least appears to be rather more straightforward. Richard From jsm@udlkern.fc.hp.com Thu, 16 Nov 2000 05:44:55 -0700 (MST) Date: Thu, 16 Nov 2000 05:44:55 -0700 (MST) From: John Marvin jsm@udlkern.fc.hp.com Subject: Single-stepping Richard, > > Sorry, I worded that very badly. The code that moves the childs > IAOQ on is in the kernel, invoked as a result of the controlling > process calling ptrace(PTRACE_SINGLESTEP...) when the childs N > bit is set. > Great. > > Does this code properly handle branches in the delay slot of another > > branch? (you need to make sure you are not advancing the queues by just > > adding 4 to each element). One concern I have about this method is that > > Current code does > > /* Nullified, just crank over the queue. */ > task_regs(child)->iaoq[0] = task_regs(child)->iaoq[1]; > task_regs(child)->iasq[0] = task_regs(child)->iasq[1]; > task_regs(child)->iaoq[1] = task_regs(child)->iaoq[0] + 4; > > Does that look right to you? > Yes, that is the correct way to do it (I'll assume the duplicated line is just a cut/paste error). > > I wonder if it is necessary to do this. So what if we don't stop on the > > nullified instruction. Since it is nullified, it doesn't actually do > > anything, so why does the user have to see it, i.e. just let the recovery > > counter trap happen on the next truly executed instruction (i.e. the > > debugger performs a "double step" in this case). Am I missing something > > here? > > I don't see why we really need to stop on a nullified instruction, but > I'll wait for Alan to comment as he wrote this initially. > Given the above, i.e. that this is being handled in the kernel anyway, I guess I don't really care which way this goes. Probably it is best to do it whatever way gdb on hp-ux presents it. > > 1) When single stepping over a syscall, when do you actually stop the > > single stepping and execute the syscall? Hopefully you are not > > allowing single stepping after the gate instruction on the gateway > > page (and returning control to a non privileged debugging process). > > The recovery counter trap should detect when the user code gets > > to the gateway page. > > At the moment my test harness notes IAOQ=0x100 and stops single stepping, > but obviously the kernel needs to enforce that. > You should also be checking the space. But yes, the kernel needs to enforce this for security reasons. You should be able to do it in the recovery counter trap handler (rather than having to test for it in the syscall path, which affects all processes). > > 2) Does your solution properly handle single stepping into and out of > > a signal handler? Note that the debugger will trap the signal as part > > of this process. Since the return is handled through a hidden syscall > > you may not have to do anything special here. > > Havn't looked at signal handling yet. > I'm not sure that there is a real issue here or not. HP-UX has some code for single stepping with respect to signal handlers, but I believe it may only be necessary due to the saved state necessary as part of the iaoq manipulation. Obviously you should test this case. > > Note that HP-UX does not use the recovery counter for single stepping. I > > Thanks for the description of how HP-UX does it. I'll stick with > the recovery counter for now as it does seem to be basically working. > I'll also try to ensure that it is completely encapsulated within the kernel > so it is less painful to change later, if need be. > Sounds ok with me. And as long as there are no corner cases, it probably is the best solution, assuming we don't find another application for the recovery counter. John From rhirst@linuxcare.com Thu, 16 Nov 2000 13:20:17 +0000 Date: Thu, 16 Nov 2000 13:20:17 +0000 From: Richard Hirst rhirst@linuxcare.com Subject: Single-stepping On Thu, Nov 16, 2000 at 05:44:55AM -0700, John Marvin wrote: > > Current code does > > > > /* Nullified, just crank over the queue. */ > > task_regs(child)->iaoq[0] = task_regs(child)->iaoq[1]; > > task_regs(child)->iasq[0] = task_regs(child)->iasq[1]; > > task_regs(child)->iaoq[1] = task_regs(child)->iaoq[0] + 4; > > > > Does that look right to you? > > Yes, that is the correct way to do it (I'll assume the duplicated line > is just a cut/paste error). It's not duplicated (iaoq v. iasq). > > At the moment my test harness notes IAOQ=0x100 and stops single stepping, > > but obviously the kernel needs to enforce that. > > > You should also be checking the space. But yes, the kernel needs to enforce > this for security reasons. You should be able to do it in the recovery > counter trap handler (rather than having to test for it in the syscall > path, which affects all processes). I might come back to you on that when I've thought some more. Thanks, Richard From ian.zink@maryville.com Thu, 16 Nov 2000 09:46:18 -0600 Date: Thu, 16 Nov 2000 09:46:18 -0600 From: Ian Zink ian.zink@maryville.com Subject: [parisc-linux] I got the serial console to work... After reading some posts, I went back to trying to use to a serial console to no avail.. Then.. suddenly it hit me. Do'y. The cable I was using was straight-through not Cross-over. Now I have the 712 all booted and running Debian. Very cool, indeed. Thanks for all for your help. I think I will still work on building a STI ISO for the fun of it :) Thanks much, Ian Zink, Systems Engineer Maryville Technologies 540 Maryville Centre, Suite 300 St. Louis, MO 63141 636/519-4182 (FAX) 636/519-4141 ian.zink@maryville.com www.maryville.com From marteaut@esiee.fr Thu, 16 Nov 2000 18:18:58 +0100 Date: Thu, 16 Nov 2000 18:18:58 +0100 From: Thomas Marteau marteaut@esiee.fr Subject: [parisc-linux] The config for 712 hp boxes This is a multi-part message in MIME format. ------=_NextPart_000_00A5_01C04FF9.B01CC3A0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Hi all, Here is the config file we use to compile a new kernel from the test10 sources. We have the console with the STI and an extra term on the serial port. Also, in this mail, you have the diff between our hp_keyb.c and the official one but it gives you the ~ and the ' and others scancodes. All this works for the 712 boxes. We were forced to reboot our box to test the new kernel but before the uptime was 3 days and 4 hours during which we ran dselect and did some compiling. All the files inclosed are downloadable at http://www.esiee.fr/~puffin/code/dl.html Bye, ESIEE Team ------=_NextPart_000_00A5_01C04FF9.B01CC3A0 Content-Type: application/octet-stream; name="keyb.patch" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="keyb.patch" diff -urN linux2/drivers/char/hp_keyb.c linux/drivers/char/hp_keyb.c=0A= --- linux2/drivers/char/hp_keyb.c Thu Nov 16 17:39:03 2000=0A= +++ linux/drivers/char/hp_keyb.c Thu Nov 16 17:18:54 2000=0A= @@ -70,12 +70,12 @@=0A= #define K_F8 0x42=0A= #define K_F9 0x43=0A= #define K_F10 0x44=0A= -#define K_F11 87=0A= -#define K_F12 88=0A= +#define K_F11 0x57=0A= +#define K_F12 0x58=0A= #define K_PRNT 0x54=0A= -#define K_SCRL 70=0A= -#define K_BRK 119=0A= -#define K_AGR K_NONE=0A= +#define K_SCRL 0x46=0A= +#define K_BRK 0x77=0A= +#define K_AGR 0x29=0A= #define K_1 0x02=0A= #define K_2 0x03=0A= #define K_3 0x04=0A= @@ -89,10 +89,10 @@=0A= #define K_MINS 0x0c=0A= #define K_EQLS 0x0d=0A= #define K_BKSP 0x0e=0A= -#define K_INS 110=0A= -#define K_HOME 102=0A= -#define K_PGUP 104=0A= -#define K_NUML 69=0A= +#define K_INS 0x6e=0A= +#define K_HOME 0x66=0A= +#define K_PGUP 0x68=0A= +#define K_NUML 0x45=0A= #define KP_SLH 0x62=0A= #define KP_STR 0x37=0A= #define KP_MNS 0x4a=0A= @@ -111,13 +111,13 @@=0A= #define K_RSBK 0x1b=0A= #define K_ENTR 0x1c=0A= #define K_DEL 111=0A= -#define K_END 107=0A= -#define K_PGDN 109=0A= +#define K_END 0x6b=0A= +#define K_PGDN 0x6d=0A= #define KP_7 0x47=0A= #define KP_8 0x48=0A= #define KP_9 0x49=0A= -#define KP_PLS 118=0A= -#define K_CAPS 58=0A= +#define KP_PLS 0x4e=0A= +#define K_CAPS 0x3a=0A= #define K_A 0x1e=0A= #define K_S 0x1f=0A= #define K_D 0x20=0A= @@ -146,7 +146,7 @@=0A= #define K_DOT 0x34=0A= #define K_FSLH 0x35=0A= #define K_RSFT 0x36=0A= -#define K_UP 103 =0A= +#define K_UP 0x67=0A= #define KP_1 0x4f=0A= #define KP_2 0x50=0A= #define KP_3 0x51=0A= @@ -156,11 +156,11 @@=0A= #define K_SPCE 0x39=0A= #define K_RALT 0x64=0A= #define K_RCTL 0x61=0A= -#define K_LEFT 105=0A= -#define K_DOWN 108=0A= -#define K_RGHT 106=0A= -#define KP_0 82=0A= -#define KP_DOT 83=0A= +#define K_LEFT 0x69=0A= +#define K_DOWN 0x6c=0A= +#define K_RGHT 0x6a=0A= +#define KP_0 0x52=0A= +#define KP_DOT 0x53=0A= =0A= static unsigned char keycode_translate[256] =3D=0A= {=0A= @@ -198,7 +198,7 @@=0A= =0A= /* ----- the following code stolen from pc_keyb.c */=0A= =0A= -#ifdef CONFIG_MAGIC_SYSRQ=0A= +=0A= unsigned char pckbd_sysrq_xlate[128] =3D=0A= "\000\0331234567890-=3D\177\t" /* 0x00 - 0x0f */=0A= "qwertyuiop[]\r\000as" /* 0x10 - 0x1f */=0A= @@ -207,7 +207,6 @@=0A= "\206\207\210\211\212\000\000789-456+1" /* 0x40 - 0x4f */=0A= "230\177\000\000\213\214\000\000\000\000\000\000\000\000\000\000" /* = 0x50 - 0x5f */=0A= "\r\000/"; /* 0x60 - 0x6f */=0A= -#endif=0A= =0A= /*=0A= * Translation of escaped scancodes to keycodes.=0A= ------=_NextPart_000_00A5_01C04FF9.B01CC3A0 Content-Type: application/octet-stream; name="config" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="config" #=0A= # Automatically generated by make menuconfig: don't edit=0A= #=0A= CONFIG_PARISC=3Dy=0A= # CONFIG_UID16 is not set=0A= =0A= #=0A= # Code maturity level options=0A= #=0A= CONFIG_EXPERIMENTAL=3Dy=0A= =0A= #=0A= # General options=0A= #=0A= # CONFIG_SMP is not set=0A= # CONFIG_KWDB is not set=0A= CONFIG_GSC=3Dy=0A= CONFIG_IOMMU_CCIO=3Dy=0A= CONFIG_GSC_LASI=3Dy=0A= CONFIG_PCI=3Dy=0A= CONFIG_GSC_DINO=3Dy=0A= CONFIG_PCI_LBA=3Dy=0A= CONFIG_IOSAPIC=3Dy=0A= CONFIG_IOMMU_SBA=3Dy=0A= =0A= #=0A= # Loadable module support=0A= #=0A= # CONFIG_MODULES is not set=0A= =0A= #=0A= # General setup=0A= #=0A= CONFIG_NET=3Dy=0A= # CONFIG_SYSVIPC is not set=0A= # CONFIG_BSD_PROCESS_ACCT is not set=0A= CONFIG_SYSCTL=3Dy=0A= # CONFIG_BINFMT_SOM is not set=0A= CONFIG_BINFMT_ELF=3Dy=0A= # CONFIG_BINFMT_MISC is not set=0A= # CONFIG_BINFMT_JAVA is not set=0A= =0A= #=0A= # Parallel port support=0A= #=0A= CONFIG_PARPORT=3Dy=0A= # CONFIG_PARPORT_PC is not set=0A= # CONFIG_PARPORT_GSC is not set=0A= # CONFIG_PARPORT_OTHER is not set=0A= # CONFIG_PARPORT_1284 is not set=0A= =0A= #=0A= # Block devices=0A= #=0A= # CONFIG_BLK_DEV_FD is not set=0A= # CONFIG_BLK_DEV_XD is not set=0A= # CONFIG_PARIDE is not set=0A= # CONFIG_BLK_CPQ_DA is not set=0A= # CONFIG_BLK_CPQ_CISS_DA is not set=0A= # CONFIG_BLK_DEV_DAC960 is not set=0A= # CONFIG_BLK_DEV_LOOP is not set=0A= # CONFIG_BLK_DEV_NBD is not set=0A= CONFIG_BLK_DEV_RAM=3Dy=0A= CONFIG_BLK_DEV_RAM_SIZE=3D4096=0A= CONFIG_BLK_DEV_INITRD=3Dy=0A= =0A= #=0A= # Networking options=0A= #=0A= # CONFIG_PACKET is not set=0A= # CONFIG_NETLINK is not set=0A= # CONFIG_NETFILTER is not set=0A= # CONFIG_FILTER is not set=0A= # CONFIG_UNIX is not set=0A= CONFIG_INET=3Dy=0A= # CONFIG_IP_MULTICAST is not set=0A= # CONFIG_IP_ADVANCED_ROUTER is not set=0A= CONFIG_IP_PNP=3Dy=0A= # CONFIG_IP_PNP_BOOTP is not set=0A= # CONFIG_IP_PNP_RARP is not set=0A= # CONFIG_NET_IPIP is not set=0A= # CONFIG_NET_IPGRE is not set=0A= # CONFIG_INET_ECN is not set=0A= # CONFIG_SYN_COOKIES is not set=0A= # CONFIG_IPV6 is not set=0A= # CONFIG_KHTTPD is not set=0A= # CONFIG_ATM is not set=0A= # CONFIG_IPX is not set=0A= # CONFIG_ATALK is not set=0A= # CONFIG_DECNET is not set=0A= # CONFIG_BRIDGE is not set=0A= # CONFIG_X25 is not set=0A= # CONFIG_LAPB is not set=0A= # CONFIG_LLC is not set=0A= # CONFIG_NET_DIVERT is not set=0A= # CONFIG_ECONET is not set=0A= # CONFIG_WAN_ROUTER is not set=0A= # CONFIG_NET_FASTROUTE is not set=0A= # CONFIG_NET_HW_FLOWCONTROL is not set=0A= =0A= #=0A= # QoS and/or fair queueing=0A= #=0A= # CONFIG_NET_SCHED is not set=0A= =0A= #=0A= # SCSI support=0A= #=0A= CONFIG_SCSI=3Dy=0A= CONFIG_BLK_DEV_SD=3Dy=0A= CONFIG_SD_EXTRA_DEVS=3D40=0A= # CONFIG_CHR_DEV_ST is not set=0A= # CONFIG_BLK_DEV_SR is not set=0A= CONFIG_CHR_DEV_SG=3Dy=0A= # CONFIG_SCSI_MULTI_LUN is not set=0A= # CONFIG_SCSI_CONSTANTS is not set=0A= =0A= #=0A= # SCSI low-level drivers=0A= #=0A= CONFIG_SCSI_LASI=3Dy=0A= CONFIG_SCSI_ZALON=3Dy=0A= CONFIG_SCSI_SYM53C8XX=3Dy=0A= CONFIG_SCSI_NCR53C8XX_DEFAULT_TAGS=3D8=0A= CONFIG_SCSI_NCR53C8XX_MAX_TAGS=3D32=0A= CONFIG_SCSI_NCR53C8XX_SYNC=3D20=0A= # CONFIG_SCSI_NCR53C8XX_PROFILE is not set=0A= # CONFIG_SCSI_NCR53C8XX_IOMAPPED is not set=0A= =0A= #=0A= # Network device support=0A= #=0A= CONFIG_NETDEVICES=3Dy=0A= CONFIG_LASI_82596=3Dy=0A= =0A= #=0A= # ARCnet devices=0A= #=0A= # CONFIG_ARCNET is not set=0A= # CONFIG_DUMMY is not set=0A= # CONFIG_BONDING is not set=0A= # CONFIG_EQUALIZER is not set=0A= # CONFIG_TUN is not set=0A= # CONFIG_NET_SB1000 is not set=0A= =0A= #=0A= # Ethernet (10 or 100Mbit)=0A= #=0A= CONFIG_NET_ETHERNET=3Dy=0A= # CONFIG_NET_VENDOR_3COM is not set=0A= # CONFIG_LANCE is not set=0A= # CONFIG_NET_VENDOR_SMC is not set=0A= # CONFIG_NET_VENDOR_RACAL is not set=0A= # CONFIG_AT1700 is not set=0A= # CONFIG_DEPCA is not set=0A= # CONFIG_HP100 is not set=0A= # CONFIG_NET_ISA is not set=0A= CONFIG_NET_PCI=3Dy=0A= # CONFIG_PCNET32 is not set=0A= # CONFIG_ADAPTEC_STARFIRE is not set=0A= # CONFIG_AC3200 is not set=0A= # CONFIG_APRICOT is not set=0A= # CONFIG_CS89x0 is not set=0A= # CONFIG_DE4X5 is not set=0A= CONFIG_TULIP=3Dy=0A= # CONFIG_DGRS is not set=0A= # CONFIG_DM9102 is not set=0A= # CONFIG_EEPRO100 is not set=0A= # CONFIG_LNE390 is not set=0A= # CONFIG_NATSEMI is not set=0A= # CONFIG_NE2K_PCI is not set=0A= # CONFIG_NE3210 is not set=0A= # CONFIG_ES3210 is not set=0A= # CONFIG_RTL8129 is not set=0A= # CONFIG_8139TOO is not set=0A= # CONFIG_SIS900 is not set=0A= # CONFIG_EPIC100 is not set=0A= # CONFIG_SUNDANCE is not set=0A= # CONFIG_TLAN is not set=0A= # CONFIG_VIA_RHINE is not set=0A= # CONFIG_WINBOND_840 is not set=0A= # CONFIG_NET_POCKET is not set=0A= =0A= #=0A= # Ethernet (1000 Mbit)=0A= #=0A= # CONFIG_ACENIC is not set=0A= # CONFIG_HAMACHI is not set=0A= # CONFIG_YELLOWFIN is not set=0A= # CONFIG_SK98LIN is not set=0A= # CONFIG_FDDI is not set=0A= # CONFIG_HIPPI is not set=0A= # CONFIG_PLIP is not set=0A= # CONFIG_PPP is not set=0A= # CONFIG_SLIP is not set=0A= =0A= #=0A= # Wireless LAN (non-hamradio)=0A= #=0A= # CONFIG_NET_RADIO is not set=0A= =0A= #=0A= # Token Ring devices=0A= #=0A= # CONFIG_TR is not set=0A= # CONFIG_NET_FC is not set=0A= # CONFIG_RCPCI is not set=0A= # CONFIG_SHAPER is not set=0A= =0A= #=0A= # Wan interfaces=0A= #=0A= # CONFIG_WAN is not set=0A= =0A= #=0A= # Character devices=0A= #=0A= CONFIG_VT=3Dy=0A= CONFIG_VT_CONSOLE=3Dy=0A= CONFIG_GSC_PS2=3Dy=0A= # CONFIG_HIL is not set=0A= CONFIG_SERIAL=3Dy=0A= # CONFIG_SERIAL_CONSOLE is not set=0A= CONFIG_SERIAL_GSC=3Dy=0A= # CONFIG_SERIAL_EXTENDED is not set=0A= # CONFIG_SERIAL_NONSTANDARD is not set=0A= CONFIG_UNIX98_PTYS=3Dy=0A= CONFIG_UNIX98_PTY_COUNT=3D256=0A= # CONFIG_PRINTER is not set=0A= # CONFIG_PPDEV is not set=0A= =0A= #=0A= # I2C support=0A= #=0A= # CONFIG_I2C is not set=0A= =0A= #=0A= # Mice=0A= #=0A= # CONFIG_BUSMOUSE is not set=0A= # CONFIG_MOUSE is not set=0A= =0A= #=0A= # Joysticks=0A= #=0A= # CONFIG_JOYSTICK is not set=0A= # CONFIG_QIC02_TAPE is not set=0A= =0A= #=0A= # Watchdog Cards=0A= #=0A= # CONFIG_WATCHDOG is not set=0A= CONFIG_GENRTC=3Dy=0A= # CONFIG_INTEL_RNG is not set=0A= # CONFIG_NVRAM is not set=0A= # CONFIG_RTC is not set=0A= # CONFIG_DTLK is not set=0A= # CONFIG_R3964 is not set=0A= # CONFIG_APPLICOM is not set=0A= =0A= #=0A= # Ftape, the floppy tape device driver=0A= #=0A= # CONFIG_FTAPE is not set=0A= # CONFIG_AGP is not set=0A= # CONFIG_DRM is not set=0A= =0A= #=0A= # File systems=0A= #=0A= # CONFIG_QUOTA is not set=0A= # CONFIG_AUTOFS_FS is not set=0A= # CONFIG_AUTOFS4_FS is not set=0A= # CONFIG_ADFS_FS is not set=0A= # CONFIG_ADFS_FS_RW is not set=0A= # CONFIG_AFFS_FS is not set=0A= # CONFIG_HFS_FS is not set=0A= # CONFIG_BFS_FS is not set=0A= # CONFIG_FAT_FS is not set=0A= # CONFIG_MSDOS_FS is not set=0A= # CONFIG_UMSDOS_FS is not set=0A= # CONFIG_VFAT_FS is not set=0A= # CONFIG_EFS_FS is not set=0A= # CONFIG_JFFS_FS is not set=0A= # CONFIG_CRAMFS is not set=0A= # CONFIG_RAMFS is not set=0A= CONFIG_ISO9660_FS=3Dy=0A= # CONFIG_JOLIET is not set=0A= # CONFIG_MINIX_FS is not set=0A= # CONFIG_NTFS_FS is not set=0A= # CONFIG_NTFS_RW is not set=0A= # CONFIG_HPFS_FS is not set=0A= CONFIG_PROC_FS=3Dy=0A= # CONFIG_DEVFS_FS is not set=0A= # CONFIG_DEVFS_MOUNT is not set=0A= # CONFIG_DEVFS_DEBUG is not set=0A= # CONFIG_DEVPTS_FS is not set=0A= # CONFIG_QNX4FS_FS is not set=0A= # CONFIG_QNX4FS_RW is not set=0A= # CONFIG_ROMFS_FS is not set=0A= CONFIG_EXT2_FS=3Dy=0A= # CONFIG_SYSV_FS is not set=0A= # CONFIG_SYSV_FS_WRITE is not set=0A= # CONFIG_UDF_FS is not set=0A= # CONFIG_UDF_RW is not set=0A= # CONFIG_UFS_FS is not set=0A= # CONFIG_UFS_FS_WRITE is not set=0A= =0A= #=0A= # Network File Systems=0A= #=0A= # CONFIG_CODA_FS is not set=0A= CONFIG_NFS_FS=3Dy=0A= # CONFIG_NFS_V3 is not set=0A= CONFIG_ROOT_NFS=3Dy=0A= # CONFIG_NFSD is not set=0A= # CONFIG_NFSD_V3 is not set=0A= CONFIG_SUNRPC=3Dy=0A= CONFIG_LOCKD=3Dy=0A= # CONFIG_SMB_FS is not set=0A= # CONFIG_NCP_FS is not set=0A= # CONFIG_NCPFS_PACKET_SIGNING is not set=0A= # CONFIG_NCPFS_IOCTL_LOCKING is not set=0A= # CONFIG_NCPFS_STRONG is not set=0A= # CONFIG_NCPFS_NFS_NS is not set=0A= # CONFIG_NCPFS_OS2_NS is not set=0A= # CONFIG_NCPFS_SMALLDOS is not set=0A= # CONFIG_NCPFS_MOUNT_SUBDIR is not set=0A= # CONFIG_NCPFS_NDS_DOMAINS is not set=0A= # CONFIG_NCPFS_NLS is not set=0A= # CONFIG_NCPFS_EXTRAS is not set=0A= =0A= #=0A= # Partition Types=0A= #=0A= # CONFIG_PARTITION_ADVANCED is not set=0A= CONFIG_MSDOS_PARTITION=3Dy=0A= # CONFIG_NLS is not set=0A= =0A= #=0A= # Sound Drivers=0A= #=0A= # CONFIG_SOUND is not set=0A= =0A= #=0A= # Console drivers=0A= #=0A= =0A= #=0A= # Frame-buffer support=0A= #=0A= # CONFIG_FB is not set=0A= CONFIG_STI_CONSOLE=3Dy=0A= CONFIG_DUMMY_CONSOLE=3Dy=0A= =0A= #=0A= # Kernel hacking=0A= #=0A= CONFIG_MAGIC_SYSRQ=3Dy=0A= ------=_NextPart_000_00A5_01C04FF9.B01CC3A0-- From grundler@cup.hp.com Thu, 16 Nov 2000 10:10:23 -0800 Date: Thu, 16 Nov 2000 10:10:23 -0800 From: Grant Grundler grundler@cup.hp.com Subject: [parisc-linux] The config for 712 hp boxes "Thomas Marteau" wrote: > Hi all, > > Here is the config file we use to compile a new kernel from the test10 > sources. We have the console with the STI and an extra term on the serial > port. Thomas - excellent - thanks! > Also, in this mail, you have the diff between our hp_keyb.c and the official > one but it gives you the ~ and the ' and others scancodes. I noticed this mail was directed to me - but I can't take ownership of this code. I have too many other things going on. Helge - can you commit this fix too? thanks, grant Grant Grundler Unix Systems Enablement Lab +1.408.447.7253 From deller@gmx.de Thu, 16 Nov 2000 19:25:49 +0100 Date: Thu, 16 Nov 2000 19:25:49 +0100 From: Helge Deller deller@gmx.de Subject: [parisc-linux] The config for 712 hp boxes On Thursday 16 November 2000 19:10, Grant Grundler wrote: > "Thomas Marteau" wrote: > > Hi all, > > > > Here is the config file we use to compile a new kernel from the test10 > > sources. We have the console with the STI and an extra term on the serial > > port. > > Thomas - excellent - thanks! > > > Also, in this mail, you have the diff between our hp_keyb.c and the official > > one but it gives you the ~ and the ' and others scancodes. > > I noticed this mail was directed to me - but I can't take ownership > of this code. I have too many other things going on. > > Helge - can you commit this fix too? Ok. I will test & evtl. commit it today. > > thanks, > grant > > Grant Grundler > Unix Systems Enablement Lab > +1.408.447.7253 > > --------------------------------------------------------------------------- > To unsubscribe: send e-mail to parisc-linux-request@thepuffingroup.com with > `unsubscribe' as the subject. From frank_rowand@mvista.com Thu, 16 Nov 2000 11:00:48 -0800 Date: Thu, 16 Nov 2000 11:00:48 -0800 From: Frank Rowand frank_rowand@mvista.com Subject: Single-stepping John Marvin wrote: > > Richard, > > > > > Sorry, I worded that very badly. The code that moves the childs > > IAOQ on is in the kernel, invoked as a result of the controlling > > process calling ptrace(PTRACE_SINGLESTEP...) when the childs N > > bit is set. > > > > Great. > > > > Does this code properly handle branches in the delay slot of another > > > branch? (you need to make sure you are not advancing the queues by just > > > adding 4 to each element). One concern I have about this method is that > > > > Current code does > > > > /* Nullified, just crank over the queue. */ > > task_regs(child)->iaoq[0] = task_regs(child)->iaoq[1]; > > task_regs(child)->iasq[0] = task_regs(child)->iasq[1]; > > task_regs(child)->iaoq[1] = task_regs(child)->iaoq[0] + 4; > > > > Does that look right to you? > > > > Yes, that is the correct way to do it (I'll assume the duplicated line > is just a cut/paste error). If iaoq[0] contains a branch, iaoq[1] is in the delay slot. The instruction executed after iaoq[1] would then typically _not_ be iaoq[0] + 4 (the next instruction would be the target of the branch at iaoq[0]). > Sounds ok with me. And as long as there are no corner cases, it probably > is the best solution, assuming we don't find another application for > the recovery counter. The recovery counter is very useful for performance measurement tools to understand the cycles per instruction of a code path. (Using the recovery counter for the debugger doesn't preclude using it for performance tools - you just can't easily use it for both purposes at the same instant in time.) > John -Frank -- Frank Rowand MontaVista Software, Inc From rhirst@linuxcare.com Thu, 16 Nov 2000 20:28:42 +0000 Date: Thu, 16 Nov 2000 20:28:42 +0000 From: Richard Hirst rhirst@linuxcare.com Subject: Single-stepping On Thu, Nov 16, 2000 at 11:00:48AM -0800, Frank Rowand wrote: > John Marvin wrote: > > > > Does this code properly handle branches in the delay slot of another > > > > branch? (you need to make sure you are not advancing the queues by just > > > > adding 4 to each element). One concern I have about this method is that > > > > > > Current code does > > > > > > /* Nullified, just crank over the queue. */ > > > task_regs(child)->iaoq[0] = task_regs(child)->iaoq[1]; > > > task_regs(child)->iasq[0] = task_regs(child)->iasq[1]; > > > task_regs(child)->iaoq[1] = task_regs(child)->iaoq[0] + 4; > > > > > > Does that look right to you? > > > > > > > Yes, that is the correct way to do it (I'll assume the duplicated line > > is just a cut/paste error). > > If iaoq[0] contains a branch, iaoq[1] is in the delay slot. The instruction > executed after iaoq[1] would then typically _not_ be iaoq[0] + 4 (the next > instruction would be the target of the branch at iaoq[0]). But the above code is only executed if the current instruction is nullified. In your example, the branch in iaoq[0] would be nullified and therefore never taken. Richard From deller@gmx.de Thu, 16 Nov 2000 22:28:50 +0100 Date: Thu, 16 Nov 2000 22:28:50 +0100 From: Helge Deller deller@gmx.de Subject: [parisc-linux] The config for 712 hp boxes On Thursday 16 November 2000 18:18, Thomas Marteau wrote: > Hi all, > > [....] > Also, in this mail, you have the diff between our hp_keyb.c and the official > one but it gives you the ~ and the ' and others scancodes. > [....] Hi ESIEE-Team ! Thanks for your patch ! I committed your patch into CVS and just tweaked it a little for CONFIG_MAGIC_SYSRQ. I hope this is ok for you ? If your time permits, I would like to ask, if you maybe also want to look at getting the CAPS-Lock-, Scroll-Lock- & Num-Lock-LED's working ? Furthermore you mention in your project-history on your homepage something about "keyboard and soundchip problems" (Oct. 24). I'm asking just out of curiousity: Did you thought about programming the on-board sound-chips (which I believe would be a hard job.) ? > Bye, > ESIEE Team Best regards, Helge Deller. From taggart@carmen.fc.hp.com Thu, 16 Nov 2000 19:25:26 -0700 Date: Thu, 16 Nov 2000 19:25:26 -0700 From: Matt Taggart taggart@carmen.fc.hp.com Subject: [parisc-linux] glibc merged to 2.2 Today Paul Bame and I merged/updated the puffin.external.hp.com glibc cvs to glibc 2.2. After the merge I cleaned up the differences between our cvs and 2.2, mostly comment differences and formatting changes. With the exception of the setjmp problem mentioned in, http://puffin.external.hp.com/mailing-lists/parisc-linux/2000/11-Nov/0091.html and the fact that we have/need newer "scripts/config.guess" and "scripts/config.sub", we are completely sync'ed up with glibc 2.2. -- Matt Taggart taggart@fc.hp.com From deller@gmx.de Fri, 17 Nov 2000 15:34:09 +0100 Date: Fri, 17 Nov 2000 15:34:09 +0100 From: Helge Deller deller@gmx.de Subject: [parisc-linux] The config for 712 hp boxes [CC'ed the list, so maybe someone else can comment too....] On Friday 17 November 2000 11:45, Thomas Marteau wrote: > Hi Helge, Hi, > > > ----- Original Message ----- > From: Helge Deller > To: Thomas Marteau > Cc: > Sent: Thursday, November 16, 2000 10:28 PM > Subject: Re: [parisc-linux] The config for 712 hp boxes > > > > On Thursday 16 November 2000 18:18, Thomas Marteau wrote: > > > Hi all, > > > > > > [....] > > > Also, in this mail, you have the diff between our hp_keyb.c and the > official > > > one but it gives you the ~ and the ' and others scancodes. > > > [....] > > > > Hi ESIEE-Team ! > > > > Thanks for your patch ! > > > > I committed your patch into CVS and just tweaked it a little for > > CONFIG_MAGIC_SYSRQ. I hope this is ok for you ? > We didn't really understand why pckbd_sysrq_xlate was here for. > If you can explain to us, it will be fine. The best documentation you can find is in linux/Documentation/sysrq.txt. The copy of pckbd_sysrq_xlate[] is a simple implementation of keyboard-scancodes to chars, which is used by drivers/char/keyboard.c to call handle_sysrq() from /drivers/char/sysrq.c. This means, that you can press Alt-PrintScr (=> SysRQ) and a char at the keyboard simultaniously and your machine for example syncs the disks, mounts all discs read-only or reboots your machine immediately. > > If your time permits, I would like to ask, if you maybe also want to look > at > > getting the CAPS-Lock-, Scroll-Lock- & Num-Lock-LED's working ? > Normally, you can see yours leds switching on/off but we did not init them. > So they are like boot admin switch them... ^^^^^^^ ^^^^^ ^^^ Sorry ? > But we would like to know how and where we have to init them > because we know how to. We have made test and it was working... I'm not sure, but I think you should check the code in lasikbd_leds() in hp_psaux.c. The initialization should maybe be done in the same file in the function lasi_ps2_register() before calling register_kbd_ops(). > > > Furthermore you mention in your project-history on your homepage something > > about "keyboard and soundchip problems" (Oct. 24). I'm asking just out of > > curiousity: Did you thought about programming the on-board sound-chips > (which > > I believe would be a hard job.) ? > Yes, it is in our internal todo list, if we have time to. Because we look at > it with Thierry, we saw that, for LASI, > you have an interface and then the chip to configure. But it is very > interesting... Yes it is, and it would be great if you worked on that too ! > > Also, we want to rule the power leds but they are different if the box is > 712 or B132 or ... So our question is how to implement > this kind of initialsation and deinitialisation in a linux kernel and in a > second time, how to do for differents kind of boxes. As far as I know / have heard, there are only two types of LED's (but I may be wrong here !). One is where the LED's are organized in a row on the front panel (as my local machines here), and the other one, where you have (LED/)LCD-Numbers on your front panel ? They differ how to be accessed and where the controlling registers are located. One method to distiguish them is maybe to place the special initialisation code into drivers/gsc/lasi.c and asp.c, depending on the machine and which method needs to be used. Since I don't have any real documentation or knowledge of the programming of the LEDs (beside of the PDC-calls I placed into setup.c), maybe someone else can better comment on that or give some documentation ? > > Thanks for your answers, Helge > Bye, > ESIEE Team Best regards, Helge Deller. From Arnaud.ATOCH@oecd.org Fri, 17 Nov 2000 16:30:42 +0100 Date: Fri, 17 Nov 2000 16:30:42 +0100 From: Arnaud.ATOCH@oecd.org Arnaud.ATOCH@oecd.org Subject: [parisc-linux] Booting 712 with CD 0.5 Is the following output the normal behavior of Linux-PARisc on a 712/100 ? kmem_create: Forcing size word alignment - nfs_fh kernel BUG at pci-dma.c:391! kernel BUG at pci-dma.c:400! kernel BUG at pci-dma.c:391! kernel BUG at pci-dma.c:400! kernel BUG at pci-dma.c:391! kernel BUG at pci-dma.c:400! VFS: Disk change detected on device sr(11,0) kernel BUG at pci-dma.c:391! kernel BUG at pci-dma.c:400! kernel BUG at pci-dma.c:391! kernel BUG at pci-dma.c:400! kernel BUG at pci-dma.c:391! kernel BUG at pci-dma.c:400! ISO 9660 Extensions: RRIP_1991A VFS: Mounted root (iso9660 filesystem) readonly. INIT: version 2.78 booting INIT: Entering runlevel: 2 Setting up /tmp ramdisk4096+0 records in 4096+0 records out mke2fs 1.19, 13-Jul-2000 for EXT2 FS 0.5b, 95/08/09 Filesystem label= OS type: Linux Block size=1024 (log=0) Fragment size=1024 (log=0) 1024 inodes, 4096 blocks 0 blocks (0.00%) reserved for the super user First data block=1 1 block group 8192 blocks per group, 8192 fragments per group 1024 inodes per group Writing inode tables: done Writing superblocks and filesystem accounting information: done INIT: Id "T0" respawni INIT: no more processe From rhirst@linuxcare.com Fri, 17 Nov 2000 15:39:55 +0000 Date: Fri, 17 Nov 2000 15:39:55 +0000 From: Richard Hirst rhirst@linuxcare.com Subject: [parisc-linux] SEGV signal handling bug (dynamic linking) Hi, Don't know if anyone expects this to work yet or not, but: ------------------------- cut ----------------------------- #include #include #include #include #include #include #include #include #include char *mem; void sig_handler(int sig) { int res; printf("Trapped!!!\n"); res = mprotect(mem, 4096, PROT_READ|PROT_WRITE); if (res < 0) { perror("mprotect"); exit(1); } } void install_handlers(void) { struct sigaction act; memset(&act, 0, sizeof(act)); act.sa_handler = sig_handler; sigaction(SIGSEGV, &act, NULL); } int main(int argc, char **argv) { int res; mem = malloc(8192); if (mem == NULL) { perror("malloc"); exit(1); } mem = (char *)(((int)mem + 4095) & ~0x0fff); res = mprotect(mem, 4096, PROT_READ); if (res < 0) { perror("mprotect"); exit(1); } install_handlers(); write(1, "Going\n", 6); mem[24] = 17; write(1, "Gone\n", 5); return 0; } ------------------------- cut ----------------------------- generates: Going Bus error plus the following on the console: do_page_fault() pid=167 command='ch' YZrvWESTHLNXBCVMcbcbcbcbOGFRQPDI PSW: 00000000000001001111111100001011 r0-3 00000000 fffff000 0000166f 00002944 r4-7 40138c38 2001fd8c 00002852 00000001 r8-11 00002862 0008b010 0009c290 0009cbf0 r12-15 00000000 00000000 0009cb50 00000000 r16-19 00000000 00000001 0000b71b 00000011 r20-23 00004000 40041fcc 40041fcc 00000008 r24-27 00000006 00001000 00000001 0000280c r28-31 00000006 00000020 20020140 40041fd7 sr0-4 00000000 00000003 00000000 0000000a sr4-8 0000000a 0000000a 0000000a 0000000a IASQ: 0000000a 0000000a IAOQ: 0000167b 0000167f IIR: 6293002e ISR: 0000000a IOR: 00004017 ORIG_R28: 00002880 !!die_if_kernel: ch(167): Unaligned data reference 28 YZrvWESTHLNXBCVMcbcbcbcbOGFRQPDI PSW: 00000000000011001111111100001011 r0-3 00000000 fffff000 20020140 00002944 r4-7 40138c38 2001fd8c 00002852 00000001 r8-11 00002862 0008b010 0009c290 0009cbf0 r12-15 00000000 00000000 0009cb50 00000000 r16-19 00000000 00000001 0000b71b 00000000 r20-23 0000289f 40041fcc 40041fcc 00000008 r24-27 200201d0 20020150 0000000b 0000280c r28-31 00000006 00000020 200203c0 40041fd7 sr0-4 00000000 00000003 00000000 0000000a sr4-8 0000000a 0000000a 0000000a 0000000a IASQ: 0000000a 0000000a IAOQ: 0000289b 0000289b IIR: 0e801096 ISR: 0000000a IOR: 0000289f ORIG_R28: 00002880 The first do_page_fault() is fine, it is the 'mem[24] = 17' line, but the second isn't. The corresponding code is at the end of .plt: 2898: 0e 80 10 96 ldw 0(sr0,r20),r22 289c: ea c0 c0 00 bv r0(r22) 28a0: 0e 88 10 95 ldw 4(sr0,r20),r21 28a4: ea 9f 1f dd b,l 2898 <__DTOR_END__+0x74>,r20 28a8: d6 80 1c 1e depwi 0,31,2,r20 28ac: 00 c0 ff ee # c0ffee 28b0: de ad be ef #deadbeef However, if I make it statically linked, it works fine, giving: Going Trapped!!! Gone Richard From bri@mojo.calyx.net Fri, 17 Nov 2000 10:49:22 -0500 (EST) Date: Fri, 17 Nov 2000 10:49:22 -0500 (EST) From: Brian S. Julin bri@mojo.calyx.net Subject: [parisc-linux] debian archive beware libpam JFYI to save other people some time. Before firing up "apt-get upgrade" you'll be best off putting a hold on all the libpam packages, as the 0.72-12 version on ftp.us.debian.org fails on a bad symbol in libpam-misc, which locks you out of the box except if you boot single. -- Brian S. Julin From grundler@cup.hp.com Fri, 17 Nov 2000 08:38:24 -0800 Date: Fri, 17 Nov 2000 08:38:24 -0800 From: Grant Grundler grundler@cup.hp.com Subject: [parisc-linux] Booting 712 with CD 0.5 Arnaud.ATOCH@oecd.org wrote: > Is the following output the normal behavior of Linux-PARisc on a 712/100 ? > > kmem_create: Forcing size word alignment - nfs_fh > kernel BUG at pci-dma.c:391! > kernel BUG at pci-dma.c:400! The bug is real. A driver is calling pci_map_single() and pci_unmap_single() without specifying which direction the DMA is going. Cache flushing on 712 (PCXL) systems needs to know. I'll assume it's the SCSI driver since it looks like we are talking to a SCSI CD-ROM. grant Grant Grundler Unix Systems Enablement Lab +1.408.447.7253 From drepper@redhat.com 17 Nov 2000 09:09:10 -0800 Date: 17 Nov 2000 09:09:10 -0800 From: Ulrich Drepper drepper@redhat.com Subject: [parisc-linux] SEGV signal handling bug (dynamic linking) Richard Hirst writes: > mem = malloc(8192); > if (mem == NULL) { > perror("malloc"); > exit(1); > } > mem = (char *)(((int)mem + 4095) & ~0x0fff); > res = mprotect(mem, 4096, PROT_READ); Read the Unix standard: The behavior of this function is unspecified if the mapping was not established by a call to mmap(). -- ---------------. ,-. 1325 Chesapeake Terrace Ulrich Drepper \ ,-------------------' \ Sunnyvale, CA 94089 USA Red Hat `--' drepper at redhat.com `------------------------ From grundler@cup.hp.com Fri, 17 Nov 2000 09:09:04 -0800 (PST) Date: Fri, 17 Nov 2000 09:09:04 -0800 (PST) From: Grant Grundler grundler@cup.hp.com Subject: [parisc-linux] pci-dma.c BUG(391/400) PATCH Hi all, The following patch tries to point a finger at the offender rather than just call attention to a problem in the service. I don't have a PCXL/L2 machine setup right now. Could someone test commit this patch for me? thanks, grant grundler <505>cvs diff arch/parisc/kernel/pci-dma.c Index: arch/parisc/kernel/pci-dma.c =================================================================== RCS file: /home/cvs/parisc/linux/arch/parisc/kernel/pci-dma.c,v retrieving revision 1.16 diff -u -p -r1.16 pci-dma.c --- pci-dma.c 2000/11/08 06:20:27 1.16 +++ pci-dma.c 2000/11/17 17:04:22 @@ -387,8 +387,10 @@ static void pa11_dma_free_consistent (st static dma_addr_t pa11_dma_map_single(struct pci_dev *dev, void *addr, size_t size, int direction) { - if (direction == PCI_DMA_NONE) - BUG(); + if (direction == PCI_DMA_NONE) { + printk(KERN_ERR "pa11_dma_map_single(PCI_DMA_NONE) called by %p\n", __builtin_return_address(0)); + BUG(); + } flush_kernel_dcache_range((unsigned long) addr, size); return virt_to_phys(addr); @@ -396,8 +398,10 @@ static dma_addr_t pa11_dma_map_single(st static void pa11_dma_unmap_single(struct pci_dev *dev, dma_addr_t dma_handle, size_t size, int direction) { - if (direction == PCI_DMA_NONE) - BUG(); + if (direction == PCI_DMA_NONE) { + printk(KERN_ERR "pa11_dma_unmap_single(PCI_DMA_NONE) called by %p\n", __builtin_return_address(0)); + BUG(); + } if (direction == PCI_DMA_TODEVICE) return; From Arnaud.ATOCH@oecd.org Fri, 17 Nov 2000 18:10:52 +0100 Date: Fri, 17 Nov 2000 18:10:52 +0100 From: Arnaud.ATOCH@oecd.org Arnaud.ATOCH@oecd.org Subject: [parisc-linux] Booting 712 with CD 0.5 Thanks for the enlightment. Should I try a new CD-ROM or should I wait untill next ISO image is created ? IS the shutdown also due to this bug ? Setting up /tmp ramdisk4096+0 records in 4096+0 records out mke2fs 1.19, 13-Jul-2000 for EXT2 FS 0.5b, 95/08/09 Filesystem label= OS type: Linux Block size=1024 (log=0) Fragment size=1024 (log=0) 1024 inodes, 4096 blocks 0 blocks (0.00%) reserved for the super user First data block=1 1 block group 8192 blocks per group, 8192 fragments per group 1024 inodes per group Writing inode tables: done Writing superblocks and filesystem accounting information: done INIT: Id "T0" respawni INIT: no more processe -----Original Message----- From: Grant Grundler [mailto:grundler@cup.hp.com] Sent: Friday, November 17, 2000 17:38 To: Arnaud.ATOCH@oecd.org Cc: parisc-linux@puffin.external.hp.com Subject: Re: [parisc-linux] Booting 712 with CD 0.5 Arnaud.ATOCH@oecd.org wrote: > Is the following output the normal behavior of Linux-PARisc on a 712/100 ? > > kmem_create: Forcing size word alignment - nfs_fh > kernel BUG at pci-dma.c:391! > kernel BUG at pci-dma.c:400! The bug is real. A driver is calling pci_map_single() and pci_unmap_single() without specifying which direction the DMA is going. Cache flushing on 712 (PCXL) systems needs to know. I'll assume it's the SCSI driver since it looks like we are talking to a SCSI CD-ROM. grant Grant Grundler Unix Systems Enablement Lab +1.408.447.7253 From rhirst@linuxcare.com Fri, 17 Nov 2000 17:38:18 +0000 Date: Fri, 17 Nov 2000 17:38:18 +0000 From: Richard Hirst rhirst@linuxcare.com Subject: [parisc-linux] SEGV signal handling bug (dynamic linking) On Fri, Nov 17, 2000 at 09:09:10AM -0800, Ulrich Drepper wrote: > Richard Hirst writes: > > > mem = malloc(8192); > > if (mem == NULL) { > > perror("malloc"); > > exit(1); > > } > > mem = (char *)(((int)mem + 4095) & ~0x0fff); > > res = mprotect(mem, 4096, PROT_READ); > > Read the Unix standard: > > The behavior of this function is unspecified if the mapping was not > established by a call to mmap(). Yeh, but it works on m68k and i386, and works on hppa if statically linked. And the code is in an example on the mprotect man page on my Mandrake7 box. Richard From drepper@redhat.com 17 Nov 2000 10:06:21 -0800 Date: 17 Nov 2000 10:06:21 -0800 From: Ulrich Drepper drepper@redhat.com Subject: [parisc-linux] SEGV signal handling bug (dynamic linking) Richard Hirst writes: > Yeh, but it works on m68k and i386, and works on hppa if statically > linked. And the code is in an example on the mprotect man page on > my Mandrake7 box. Then shoot the guy who wrote the man page. It's wrong and will never reliably work. -- ---------------. ,-. 1325 Chesapeake Terrace Ulrich Drepper \ ,-------------------' \ Sunnyvale, CA 94089 USA Red Hat `--' drepper at redhat.com `------------------------ From rhirst@linuxcare.com Fri, 17 Nov 2000 20:10:34 +0000 Date: Fri, 17 Nov 2000 20:10:34 +0000 From: Richard Hirst rhirst@linuxcare.com Subject: [parisc-linux] SEGV signal handling bug (dynamic linking) On Fri, Nov 17, 2000 at 09:09:10AM -0800, Ulrich Drepper wrote: > Richard Hirst writes: > > > mem = malloc(8192); > > if (mem == NULL) { > > perror("malloc"); > > exit(1); > > } > > mem = (char *)(((int)mem + 4095) & ~0x0fff); > > res = mprotect(mem, 4096, PROT_READ); > > Read the Unix standard: > > The behavior of this function is unspecified if the mapping was not > established by a call to mmap(). Changed my prog to use mmap and get the same problem. Richard From grundler@cup.hp.com Fri, 17 Nov 2000 13:50:46 -0800 Date: Fri, 17 Nov 2000 13:50:46 -0800 From: Grant Grundler grundler@cup.hp.com Subject: [parisc-linux] PDC firmware revision FAQ update Hi folks, The issue of PDC/firmware revs came up locally and sounded like a FAQ. I added "10. How can I check if the PDC (firmware) revision is the latest?" and what I knew/could find to our FAQ at: http://www.parisc-linux.org/faq.html The new FAQ entry should be visible to the world in the next hour or so. **** WARNING **** Firmware upgrades can *kill* your machine! **** WARNING **** Don't do it just because. Read the FAQ carefully. Take the time to figure out why you might need the upgrade and expose yourself to this risk. grant ps. please don't ask me why your favorite machine's PDC isn't listed. I don't run the referenced sites. From taggart@carmen.fc.hp.com Fri, 17 Nov 2000 18:26:19 -0700 Date: Fri, 17 Nov 2000 18:26:19 -0700 From: Matt Taggart taggart@carmen.fc.hp.com Subject: [parisc-linux] New cross compiler I have posted new i386/linux -> hppa/linux cross tools at, ftp://puffin.external.hp.com/pub/parisc/binaries/LinuxX86/xc-20001117.tar.gz it includes 32bit and 64bit cross-compilers and a static 32bit glibc 2.2. I have also updated the include tarball, ftp://puffin.external.hp.com/pub/parisc/src/include-20001117.tar.gz it includes glibc 2.2 headers and the latest kernel headers. -- Matt Taggart taggart@fc.hp.com From sandy@storm.ca Fri, 17 Nov 2000 22:54:58 -0500 Date: Fri, 17 Nov 2000 22:54:58 -0500 From: Sandy Harris sandy@storm.ca Subject: [parisc-linux] Host for 712/60 compiles A couple of us have 16 diskless 712/60s which we want to use for distributed processing on easily parallelized tasks like factoring and perhaps crypto cracking. A few questions arise. Is PARISC Linux far enough along to be useful for that? We need no monitor or console (except perhaps for initial debugging), no devices except ethernet, and expect to run only one process per machine, but we need stability. We'll need a host for cross-compiling. We have a 256 meg 715/100 with HP/UX which we expect to use as the host for booting, handing out chunks of work, storing results, etc. Should we compile there under HP/UX or would we get better tools on one of our Intel Linux boxes? Or is PARISC Linux far enough along we should put it on the 715 and get native compilation? From matthew@wil.cx Sat, 18 Nov 2000 07:08:12 +0000 Date: Sat, 18 Nov 2000 07:08:12 +0000 From: Matthew Wilcox matthew@wil.cx Subject: binutils taggart On Wed, Nov 15, 2000 at 05:16:02PM -0700, Matt Taggart wrote: > Modified files: > . : config.guess config.sub > > Log message: > New upstream versions from > http://subversions.gnu.org/cgi-bin/cvsweb/config/ > Now config.guess returns the right thing for hppa-linux so... we needed new versions anyway, even though we're not parisc-linux..? :-) [not bitter, just amused] -- Revolutions do not require corporate support. From matthew@wil.cx Sat, 18 Nov 2000 07:24:54 +0000 Date: Sat, 18 Nov 2000 07:24:54 +0000 From: Matthew Wilcox matthew@wil.cx Subject: [parisc-linux] CVS linux Vs. -test10 On Tue, Nov 14, 2000 at 09:35:01AM -0700, Paul Bame wrote: > > I've attached an overview of differences between our CVS linux sources ok, here's my memories. > * Lots of RCS $Revision$ differences in ACPI (a different 'cvs > import' would've eliminated these differences). i assume someone's already done the appropriate cvs admin -ko magic to fix this? > * drivers/char/Config.in: changes to support LASI, parisc real-time > clock (CONFIG_GENRTC) istr this was `stolen' from the m68k port by sammy. > * drivers/char/serial.c: support for GSC and A500 serial if they're working, send to Ted and he'll do an update with Linus at some point. > * drivers/net/eepro100.c: no clue about this one we were trying to get it to work for the Jan NYLWE show. i doubt we have any changes of note. does anyone have an eepro in an hp? > * drivers/video: STI and HP FB video drivers (iodccon is probably > worthless) agreed on iodccon. unless we're using it up until the point that one of the more advanced consoles takes over? i don't think we are now. > * fs/binfmt_elf.c,exec.c: changes for stack-grows-up? Yes, that's what they're for. > * fs/nfs/read.c: probably unnecessary hack for broken parisc64 gcc we certainly don't want to send it upstream, but we don't want to take it out until the bug is fixed. is fixing that bug on the webshite todo list? > * include/linux/binfmts.h,fs.h,kernel.h,tty.h,udf_fs_sb.h: > unnecessary differences? mostly, yes. > * include/linux/init.h: we use different section names -- why????, > probably some unnecessary other differences too because we use -ffunction-sections. text.init clashes with a function called init, and the linker just merges it into the text segment. we need it to be separate, so it became init.text. there's patches around to do this for other architectures too. just bad naming choices initially. > * include/linux/wait.h: parisc debugging -- should be removed yeah, that can die now. > * scripts/*: MANY differences here. Looks like a combination of > things we hacked to fix configuration problems plus MAYBE not > updating these files from new Linux versions in the past. 'make > menuconfig' is significantly different from upstream. Even the > mkdep.c program is different. ok. mea extremely culpa here. i had an exclude file which included the scripts/ directory. someone should now ditch our stuff, take what's in -test10, hack it till it works for us and check it in. -- Revolutions do not require corporate support. From bzeeb+hplinux@zabbadoz.net Sun, 19 Nov 2000 13:12:25 +0100 (CET) Date: Sun, 19 Nov 2000 13:12:25 +0100 (CET) From: Bjoern A. Zeeb bzeeb+hplinux@zabbadoz.net Subject: [parisc-linux] serial console ? Hi, I just started booting into a 715-100 using palinux-0.5.iso. I did read multiple times that I need serial console. So I plugged in serial cable I an normally using for x86 to x86 serial console on my linux router but I did not get anything on both serial ports :-( What information would one need to help ? personal contact is prefered. I would then sum up all information I got and post it to the list afterwards (if desired). Have to say: I am 'new' to those workstation and had to hoover it first after I got it ;) I also could have a 735-99 with some kind of graphic accelerator if that one would be better. -- Bjoern A. Zeeb bzeeb at Zabbadoz dot NeT 56 69 73 69 74 http://www.zabbadoz.net/ From bzeeb+hplinux@zabbadoz.net Sun, 19 Nov 2000 17:06:11 +0100 (CET) Date: Sun, 19 Nov 2000 17:06:11 +0100 (CET) From: Bjoern A. Zeeb bzeeb+hplinux@zabbadoz.net Subject: [parisc-linux] serial console ? On Sun, 19 Nov 2000, Bjoern A. Zeeb wrote: > I just started booting into a 715-100 using palinux-0.5.iso. > > I did read multiple times that I need serial console. So I plugged in > serial cable I an normally using for x86 to x86 serial console on my > linux router but I did not get anything on both serial ports :-( Hi, sorted out everything. serial cable was quite ok, but using cu I was never able to reach IPL. Using minicom and everything was fine. Had a great success afterwards: installed from CD (palinux-0.5.iso) Everthing worked at once out of the box :-) openssh was enabled on default :-)) only one bad touch: please do not enable portmapper on default. there are too much exploits out there these days. Short: Great great great work !!! -- Bjoern A. Zeeb bzeeb at Zabbadoz dot NeT 56 69 73 69 74 http://www.zabbadoz.net/ From dhazeghi@pacbell.net Sun, 19 Nov 2000 09:24:56 -0800 Date: Sun, 19 Nov 2000 09:24:56 -0800 From: dhazeghi@pacbell.net dhazeghi@pacbell.net Subject: [parisc-linux] glibc-latest tarball broken the glibc-latest tarball on pehc appears to be missing some important subdirectories like scripts and sysdeps. Perhaps a legacy of the 2.2 merge? Thanks, Dara Hazeghi From imatthae@grc.hp.com Sun, 19 Nov 2000 19:35:57 +0100 Date: Sun, 19 Nov 2000 19:35:57 +0100 From: Ingo Matthaes imatthae@grc.hp.com Subject: [parisc-linux] A500 and glibc woes finally we've got a A500 for palinux testing. Unfortunately we have some problems with it. A 32 bit kernel complains about a very old firmware and claims "that machine will probably never run linux" But in fact, it will :-) First question: Did anyone ever succeeded with a 32bit kernel on that hardware ? A 64 bit Kernel boots fine and recognizes all available hardware including the additional 100BT card. But it traps with the init which comes with the latest nfsroot tarball. I built a new one from the sourcesw of debians sysvlinux-2.78 and it does not trap anymore, but the kernel told me about unimplemented 32 syscalls. At this point I tried to build a 64 bit glibc in order to get a crt1.o , which is needed to builf for a 64bit init. Did anyone ever build a 64bit glibc out of the current cvs tree ? Today I've got ologue/epilogue insn (insn 433 431 435 (set (reg:DI 26 %r26) (reg:DI 2 %r2)) -1 (nil) (nil)) ../sysdeps/unix/sysv/linux/init-first.c:105: Unrecognizable insn: (insn 440 438 441 (set (reg:DI 24 %r24) (lo_sum:DI (reg:DI 1 %r1) (symbol_ref:DI ("LP$-001")))) -1 (insn_list 437 (nil)) (expr_list:REG_DEAD (reg:DI 1 %r1) (expr_list:REG_UNUSED (reg:DI 24 %r24) (nil)))) ../sysdeps/unix/sysv/linux/init-first.c:105: Internal compiler error in num_delay_slots, at insn-attrtab.c:2505 Thats the point I'm currently stucking. BTW If someone involved into the port with access to the internal HP Network needs access to that machine, please contact me. Later Ingo -- Tel: ++49-2102-908-210 German Response Center Fax: ++49-2102-907-934 Berliner Str. 111 Mailto: Ingo_Matthaes@hp.com 40880 Ratingen Germany HP Unix/Linux Competency Center Network and High AvailabilitY OpenPGP fingerprint = 4298E7785FFD65DC8950 14E9F17F8CB5B611AA4A From alan@linuxcare.com.au Mon, 20 Nov 2000 14:03:16 +1100 (EST) Date: Mon, 20 Nov 2000 14:03:16 +1100 (EST) From: Alan Modra alan@linuxcare.com.au Subject: Single-stepping On Thu, 16 Nov 2000, John Marvin wrote: > Anyway, for reference, HP-UX does single stepping by using a combination > of the taken branch trap, and loading the instruction queues such that the > front of the queue points to the next instruction to be single stepped and > the back of the queue points to the first of two break instructions on a > "break" page. It does NOT insert break instructions into the code, so it > does not adversely affect execution on a SMP machine. Note that we > already put a bunch of break instructions before the syscall entry point > on the gateway page, so it would be easy to use our gateway page for the > "break page". This way, if the single stepped instruction branches, a > taken branch trap will be taken (which is important in the case where the > branch nullifies its delay slot). Otherwise, the instruction will be > executed and then the break instruction at the known location on the > "break" page will be executed. If the single stepped instruction > nullifies the next instruction, the second break instruction on the > "break" page will be executed. This is the path I started out on for hppa-linux, then hit the problem of a branch that nullifies it's delay slot. At that point, I decided playing with IAOQ_back wouldn't work as I missed the solution of enabling taken branch traps. :-( If I'd seen this trick, then I would not have tried using the recovery counter, and even now, it may be better to go back to IAOQ fiddling. The recovery counter scheme has the disadvantage that there's only one of them so you need to save/restore over task swaps or introduce extra instructions in the syscall path - and be very careful. > Note that this is the short explanation. It is not as simple as it sounds. > One major complication is that branches with links don't work properly > with the instruction queue magic, so the link register has to be updated > in the taken branch trap handler. Also branch externals won't update > the space of the space queue tail properly (again, that has to be fixed > in the taken branch handler). I can provide more details if the recovery > counter method doesn't work out. I'm a little intrigued about these "complications". How can the link register or space _not_ be updated properly? As far as I can see, the only really tricky instruction to single-step is RFI - which shouldn't ever occur in userspace, and which we'd just emulate if it was important. Alan Modra -- Linuxcare. Support for the Revolution. From jsm@udlkern.fc.hp.com Sun, 19 Nov 2000 22:43:02 -0700 (MST) Date: Sun, 19 Nov 2000 22:43:02 -0700 (MST) From: John Marvin jsm@udlkern.fc.hp.com Subject: Single-stepping > > Note that this is the short explanation. It is not as simple as it sounds. > > One major complication is that branches with links don't work properly > > with the instruction queue magic, so the link register has to be updated > > in the taken branch trap handler. Also branch externals won't update > > the space of the space queue tail properly (again, that has to be fixed > > in the taken branch handler). I can provide more details if the recovery > > counter method doesn't work out. > > I'm a little intrigued about these "complications". How can the link > register or space _not_ be updated properly? As far as I can see, the > only really tricky instruction to single-step is RFI - which shouldn't > ever occur in userspace, and which we'd just emulate if it was important. The problem is that the link register is set to IAOQ_Back + 4. and in the case of ble, sr0 is set to IASQ_Back. Since we've played games with the queues, IAOQ_Back and IASQ_Back are pointing at the break page, not at the instruction following the branch. The additional complication is that the taken branch trap traps at the branch destination, not at the branch, so at the point of the trap you don't know where you came from in order to fix the problem easily. So, what HP-UX does is check each instruction before it executes it to see if it is a branch, and if so, what the link register is (and that is all that needs to be parsed, since we are not emulating the instruction). It then stores the branch location, and also sets some branch state flags (e.g. UBE for a branch external, and UBL for a branch with a link, both flags being set for a ble instruction). Then in the taken branch handler you have all the information you need to fix the queue. You also need to check this saved state if a signal handler is invoked while single stepping, so that the proper pc queue values can be saved in the signal context. John Marvin jsm@fc.hp.com From jsm@udlkern.fc.hp.com Sun, 19 Nov 2000 23:01:20 -0700 (MST) Date: Sun, 19 Nov 2000 23:01:20 -0700 (MST) From: John Marvin jsm@udlkern.fc.hp.com Subject: A500 and glibc woes Ingo, > > finally we've got a A500 for palinux testing. Unfortunately > we have some problems with it. > A 32 bit kernel complains about a very old firmware and claims > "that machine will probably never run linux" But in fact, it > will :-) Actually, there are no plans to ever support the A500 on a 32 bit kernel. The A500 only has 64 bit firmware, so in order to support it we would need to write a 32->64 bit firmware translation layer. ... > A 64 bit Kernel boots fine and recognizes all available hardware > including the additional 100BT card. But it traps with the init > which comes with the latest nfsroot tarball. I built a new one > from the sourcesw of debians sysvlinux-2.78 and it does not trap > anymore, but the kernel told me about unimplemented 32 syscalls. > At this point I tried to build a 64 bit glibc in order to get > a crt1.o , which is needed to builf for a 64bit init. > Well, it might seem crazy, but our short term plans do not include supporting a 64 bit user environment on the 64 bit kernel. Long term I believe this will happen, but as you have already seen, work needs to be done to support 64 bit glibc, shared libraries, etc. So, in order to get the A500 to boot, we need to support the 32 bit user environment on a 64 bit kernel. We've only recently gotten to the point where the 64 bit kernel gets far enough to start running user space applications. The problem is that we need to write translations for many system calls, since type sizes (and the structures those types are in) are different between 32 bit and 64 bit (the ugliest case is the ioctl system call). In summary, the A500 currently won't work, but since it is one of the machines that HP has targetted for Linux support, you can be sure that this will change fairly soon. John Marvin jsm@fc.hp.com From grundler@cup.hp.com Sun, 19 Nov 2000 22:47:27 -0800 Date: Sun, 19 Nov 2000 22:47:27 -0800 From: Grant Grundler grundler@cup.hp.com Subject: [parisc-linux] A500 and glibc woes Ingo Matthaes wrote: > finally we've got a A500 for palinux testing. Unfortunately > we have some problems with it. Ingo, uhmm...I'm not surprised. Let me help you understand the A500 and the direction we are going with support on the A500. I'm one of several people working on A500 support. A500 Features (marketing crud - you probably know this): o 16GB of RAM o 2-way 550 MHz PA8600 o 4 PCI-4X slots (3 of which are 1 slot per PCI bus) o all in 2U rack mountable box. Inside is (technical crud): o PCX-W+ o Astro IOMMU (aka SBA. Provides cache-coherent DMA and virtual I/O DMA) o Elroy PCI Host Bus Adapter (aka LBA) o IOSAPIC interrupt controller (integrated in Elroy) o PAT PDC (not legacy) o ^B for service processor access (ie I can reset the machine remotely) > A 32 bit kernel complains about a very old firmware and claims > "that machine will probably never run linux" But in fact, it > will :-) That's right! :^) > First question: Did anyone ever succeeded with a 32bit kernel > on that hardware ? No. Only on *64-bit* kernels. The reason is some of the PAT PDC calls we need are *only* available in wide mode. We could have written narrow<->wide mode translation routines but a 32-bit kernel ignores the A500's best feature - 16GB of RAM. The issue is HP needs good specweb99 numbers to sell these boxes and that requires GB of RAM. The 512MB of RAM that 32-bit kernel currently supports (jsm tells me 3GB or so can be done) won't approach the perf levels which can be acheived with 8 or 16GB. The HPUX specweb team (who just *beat* single CPU TUX specweb99 numbers with HPUX on A500) told me. They have a clue. You are welcome to write those translation routines and then *remove* many the "#ifdef __LP64__" preprocessor directives in arch/parisc/kernel/inventory.c and lba_pci.c. Send me the patch and I'll test/review/commit the changes. > A 64 bit Kernel boots fine and recognizes all available hardware > including the additional 100BT card. But it traps with the init > which comes with the latest nfsroot tarball. There are issues/problems with PCI resource management and I have some code waiting to be tested when I get in tomorrow. But you can be very helpful with user space! Perhaps Paul Bame can be more specific. But basically we don't have all the translation routines in place for 32-bit applications invoking 64-bit kernel syscalls. > I built a new one > from the sourcesw of debians sysvlinux-2.78 and it does not trap > anymore, but the kernel told me about unimplemented 32 syscalls. Right. > At this point I tried to build a 64 bit glibc in order to get > a crt1.o , which is needed to builf for a 64bit init. > > Did anyone ever build a 64bit glibc out of the current cvs tree ? I don't think so. Eventually we wanted to but haven't been able yet. So this great that you are trying! > Today I've got ... Can someone one with a clue about toolchain look at that? I'd be really impressed if someone got a 64-bit userspace built! I can help get kernel working right but don't have a clue about the tools. The 64-bit kernel can be booted on the following class of boxes to about the same point as the A500: o C160/180/200/240/360 o B2000/C3000/J5000/C3600/J5600/J6000 o some D/K/R-class machines The key is the box must have PCX-U (PA8000), PCX-U+ (PA8200), PCX-W (PA8500) or PCX-W+ (PA8600) processor. Look in the HWDB (http://www.parisc-linux.org/hw.html) or in /usr/sam/lib/mo/sched.models (HPUX 11.x) to determine which processor you have. > Thats the point I'm currently stucking. > > BTW If someone involved into the port with access to the internal HP > Network needs access to that machine, please contact me. Ditto. I can arrange access to my A500 as well. External access to some limited number of people could be arranged if demand is justifiable. But given the number of other boxes which can run 64-bit kernel, I hope that's not necessary. Thanks Ingo! grant Grant Grundler Unix Systems Enablement Lab +1.408.447.7253 From alan@linuxcare.com.au Mon, 20 Nov 2000 17:53:18 +1100 (EST) Date: Mon, 20 Nov 2000 17:53:18 +1100 (EST) From: Alan Modra alan@linuxcare.com.au Subject: Single-stepping On Sun, 19 Nov 2000, John Marvin wrote: > > I'm a little intrigued about these "complications". How can the link > > register or space _not_ be updated properly? As far as I can see, the > > only really tricky instruction to single-step is RFI - which shouldn't > > ever occur in userspace, and which we'd just emulate if it was important. > > The problem is that the link register is set to IAOQ_Back + 4. and in > the case of ble, sr0 is set to IASQ_Back. Since we've played games with > the queues, IAOQ_Back and IASQ_Back are pointing at the break page, not > at the instruction following the branch. Ah. That is a little nasty, especially given the effect on signal handlers you mention below. Maybe using the recovery counter isn't such a bad idea after all, especially since the added syscall and task switch overhead can be quite small if the kernel only supports single-step by one instruction. > The additional complication is that the taken branch trap traps at the > branch destination, not at the branch, so at the point of the trap you > don't know where you came from in order to fix the problem easily. So, > what HP-UX does is check each instruction before it executes it to see if > it is a branch, and if so, what the link register is (and that is all that > needs to be parsed, since we are not emulating the instruction). It then > stores the branch location, and also sets some branch state flags (e.g. > UBE for a branch external, and UBL for a branch with a link, both flags > being set for a ble instruction). Then in the taken branch handler you > have all the information you need to fix the queue. You also need > to check this saved state if a signal handler is invoked while single > stepping, so that the proper pc queue values can be saved in the signal > context. Another question for you and/or the list in general: Why does struct pt_regs have an ipsw field? Seems like it currently is unused. Regards, Alan Modra -- Linuxcare. Support for the Revolution. From grundler@cup.hp.com Sun, 19 Nov 2000 23:05:26 -0800 Date: Sun, 19 Nov 2000 23:05:26 -0800 From: Grant Grundler grundler@cup.hp.com Subject: [parisc-linux] Host for 712/60 compiles Sandy Harris wrote: > A couple of us have 16 diskless 712/60s which we want to use for distributed > processing on easily parallelized tasks like factoring and perhaps crypto > cracking. A few questions arise. > > Is PARISC Linux far enough along to be useful for that? We need no monitor or > console (except perhaps for initial debugging), no devices except ethernet, > and expect to run only one process per machine, but we need stability. It's not rock solid. On 712's, it should be pretty good though. > We'll need a host for cross-compiling. We have a 256 meg 715/100 with HP/UX > which we expect to use as the host for booting, handing out chunks of work, > storing results, etc. Should we compile there under HP/UX or would we get > better tools on one of our Intel Linux boxes? I don't think anyone has tried to cross-compile parisc-linux on an HPUX host in quite a while. > Or is PARISC Linux far enough along we should put it on the 715 and get > native compilation? AFAIK, all of the debian packages on the ISO image are built natively. But using a dual P700 linux box would be alot faster. :^) grant Grant Grundler Unix Systems Enablement Lab +1.408.447.7253 From sieler@allegro.com Sun, 19 Nov 2000 23:24:00 -0800 (PST) Date: Sun, 19 Nov 2000 23:24:00 -0800 (PST) From: Stan Sieler sieler@allegro.com Subject: Single-stepping Re: > handlers you mention below. Maybe using the recovery counter isn't such a quite true. > bad idea after all, especially since the added syscall and task switch > overhead can be quite small if the kernel only supports single-step by > one instruction. why the limit? We've used multi-instruction "single step" (oxymoron :) for about 15 years on PA-RISC...no problems, efficient, and *very* useful! -- Stan Sieler sieler@allegro.com www.allegro.com/sieler/wanted/index.html www.sieler.com From grundler@cup.hp.com Sun, 19 Nov 2000 23:44:42 -0800 Date: Sun, 19 Nov 2000 23:44:42 -0800 From: Grant Grundler grundler@cup.hp.com Subject: [parisc-linux] CVS linux Vs. -test10 Matthew Wilcox wrote: > On Tue, Nov 14, 2000 at 09:35:01AM -0700, Paul Bame wrote: > ok, here's my memories. Thanks Matthew! hehe...sounds like someone's getting older. :^) ... > > * drivers/net/eepro100.c: no clue about this one > > we were trying to get it to work for the Jan NYLWE show. I think I did that. IIRC, it's a one-line change to use I/O port space since MMIO wasn't usable without more invasive changes. > i doubt we have any changes of note. does anyone have an eepro in an hp? I have picked nearly 30 i82557/i82558 PCI cards from scrap yard. And maybe a few i82559 even. Did you need one (or two)? :^) FWIW, this is the card/driver which I think was causing misaligned data reference traps. I never had a chance to followup with this though. At the time, I thought it would be *really* fun to show this working to HP's marketing team... > > * fs/nfs/read.c: probably unnecessary hack for broken parisc64 gcc > > we certainly don't want to send it upstream, but we don't want to take it > out until the bug is fixed. is fixing that bug on the webshite todo list? I don't think so. It's possible it's already fixed. Relevant CVS log entry: | revision 1.5 | date: 2000/07/18 03:15:25; author: dhd; state: Exp; lines: +5 -0 | ARGH! When I put in an assertion, NFS stops breaking randomly. I | suspect this is a compiler or binutils problem but I can't see any | clear differences in the generated code. I'll debug it later... This sounds like the hppa64 bug we saw with %r29 getting trashed. But I don't think David was working on hppa64 kernel at the time. I can test 32-bit NFS Root tomorrow w/o assertion if no one else beats me to it. > > * include/linux/init.h: we use different section names -- why????, > > probably some unnecessary other differences too > > because we use -ffunction-sections. text.init clashes with a function > called init, and the linker just merges it into the text segment. we > need it to be separate, so it became init.text. there's patches around > to do this for other architectures too. just bad naming choices initially. We need to resolve this in order to merge upstream. Matthew, any advice on how we should proceed? Or would be easier for you pester Alan Cox and just get it fixed? > > * include/linux/wait.h: parisc debugging -- should be removed > > yeah, that can die now. I'd be happy to fix this by clobbering the current version with what's in linux-2.4.0-test10. But what is the "right" way to revert changes we've made so this doesn't show up in next merge? I'll need to know this in order to revert the fs/nfs/read.c change as well. thanks, grant Grant Grundler Unix Systems Enablement Lab +1.408.447.7253 From milang@tal.org Mon, 20 Nov 2000 10:57:36 +0200 Date: Mon, 20 Nov 2000 10:57:36 +0200 From: Kaj-Michael Lang milang@tal.org Subject: [parisc-linux] Palinux on a 712/60 > Thanks for the reply, Grant. However, the 712s do not have a serial console. Yes it does.. it's just undocumented. Unfortunately I don't have the information here, but I have succesfully changed the console to serial on one of my 712. Kaj-Michael Lang milang@tal.org From alan@linuxcare.com.au Mon, 20 Nov 2000 20:05:58 +1100 (EST) Date: Mon, 20 Nov 2000 20:05:58 +1100 (EST) From: Alan Modra alan@linuxcare.com.au Subject: Single-stepping On Sun, 19 Nov 2000, Stan Sieler wrote: > > bad idea after all, especially since the added syscall and task switch > > overhead can be quite small if the kernel only supports single-step by > > one instruction. > > why the limit? We've used multi-instruction "single step" (oxymoron :) > for about 15 years on PA-RISC...no problems, efficient, and *very* > useful! Because you would then need to save and restore cr0 on task switches (or only allow one task to be single-stepped at a time). That's four instructions and two extra memory accesses per task switch. Which might not seem very much, but at some point somebody will no doubt start caring about pa-linux performance. For a single-step by one, you can simply set cr0 to zero on a task switch, and possibly avoid touching cr0 on a task switch at all with careful attention to various trap handlers. Here's the idea. The tail of syscall_restore (64-bit stuff pruned) will look like the following, with the first three instructions being the added code to support single-step (and also wide/narrow switching for 64-bit) ldi 3,%r20 mtctl $r20,%cr0 /* recovery counter, ptrace single-step */ LDREG TASK_PT_PSW(%r1),%r20 mtctl %r1,%cr30 /* intrhandler okay. */ mfsp %sr3,%r1 /* Get users space id */ mtsp %r1,%sr4 /* Restore sr4 */ mtsp %r1,%sr5 /* Restore sr5 */ mtsp %r1,%sr6 /* Restore sr6 */ depi 3,31,2,%r31 /* ensure return to user mode. */ mtsm %r20 /* restore irq state */ mfctl %cr27,%r20 be 0(%sr3,%r31) /* return to user space */ mtsp %r1,%sr7 /* Restore sr7 */ ptrace will fiddle with TASK_PT_PSW, setting the R bit and clearing the I bit to enable the recovery counter - which will start counting down at the mtsm instruction above, and reach zero on the user-space instruction, so we'll trap after executing one user-space instruction. The task-switch nonsense is to handle the case where we page-fault on the instruction and switch to another task also doing single-stepping. You want to ensure cr0 is zero when we finally get back to the original task. Now it might turn out that having extra instructions in the syscall path is worse than extra code and memory accesses on task switch. If that turns out to be true, then you'll probably get your multi-step ptrace. :-) Alan Modra -- Linuxcare. Support for the Revolution. From M_Wild@tunstall.co.uk Mon, 20 Nov 2000 10:21:32 -0000 Date: Mon, 20 Nov 2000 10:21:32 -0000 From: Mark Wild M_Wild@tunstall.co.uk Subject: [parisc-linux] Upgrading memory on a 710 Hi, I have acquired some 8MB SIMMs suitable for my old 710 workstation and wish to utilise them. I don't have any docs for the 710 and was wondering if anyone could point me in the direction of some. I've looked on the HP website but could only find some for 712s, 720, 730 etc. Alternatively, if anyone knows whether any motherboard links need to be changed, whether SIMMS need to be added in pairs / quads and which memory configurations are allowed I would be grateful. Thanks, Mark Wild -- From matthew@wil.cx Mon, 20 Nov 2000 10:50:57 +0000 Date: Mon, 20 Nov 2000 10:50:57 +0000 From: Matthew Wilcox matthew@wil.cx Subject: [parisc-linux] A500 and glibc woes On Sun, Nov 19, 2000 at 07:35:57PM +0100, Ingo Matthaes wrote: > finally we've got a A500 for palinux testing. Unfortunately > we have some problems with it. > A 32 bit kernel complains about a very old firmware and claims > "that machine will probably never run linux" But in fact, it > will :-) > First question: Did anyone ever succeeded with a 32bit kernel > on that hardware ? It's not intended to work; I doubt anyone has tried. You should build a 64 bit kernel. > A 64 bit Kernel boots fine and recognizes all available hardware > including the additional 100BT card. But it traps with the init > which comes with the latest nfsroot tarball. I built a new one > from the sourcesw of debians sysvlinux-2.78 and it does not trap > anymore, but the kernel told me about unimplemented 32 syscalls. > At this point I tried to build a 64 bit glibc in order to get > a crt1.o , which is needed to builf for a 64bit init. Don't try a 64-bit userland yet. What you need to do is implement some of the 32-bit syscalls. -- Revolutions do not require corporate support. From matthew@wil.cx Mon, 20 Nov 2000 11:17:26 +0000 Date: Mon, 20 Nov 2000 11:17:26 +0000 From: Matthew Wilcox matthew@wil.cx Subject: [parisc-linux] CVS linux Vs. -test10 On Sun, Nov 19, 2000 at 11:44:42PM -0800, Grant Grundler wrote: > Matthew Wilcox wrote: > > On Tue, Nov 14, 2000 at 09:35:01AM -0700, Paul Bame wrote: > > ok, here's my memories. > > Thanks Matthew! > > hehe...sounds like someone's getting older. :^) ... when i were a lad, all this were fields! Our dad used to kill us every morning, we'd get up half an hour before we went to bed and walk uphill both to and from school... > ... > > > * drivers/net/eepro100.c: no clue about this one > > > > we were trying to get it to work for the Jan NYLWE show. > > I think I did that. IIRC, it's a one-line change to use I/O port > space since MMIO wasn't usable without more invasive changes. sounds right. MMIO should work now though, right? > > i doubt we have any changes of note. does anyone have an eepro in an hp? > > I have picked nearly 30 i82557/i82558 PCI cards from scrap yard. > And maybe a few i82559 even. Did you need one (or two)? :^) Heh, I only have a 712 right now :-) > FWIW, this is the card/driver which I think was causing misaligned > data reference traps. I never had a chance to followup with this though. > At the time, I thought it would be *really* fun to show this working > to HP's marketing team... Oh yes, I remember that now. Tulip always does a copy (well, it doesn't _have_ to, but we tell it to, just like the Alpha does). > > > * fs/nfs/read.c: probably unnecessary hack for broken parisc64 gcc > > > > we certainly don't want to send it upstream, but we don't want to take it > > out until the bug is fixed. is fixing that bug on the webshite todo list? > > I don't think so. It's possible it's already fixed. > > Relevant CVS log entry: > | revision 1.5 > | date: 2000/07/18 03:15:25; author: dhd; state: Exp; lines: +5 -0 > | ARGH! When I put in an assertion, NFS stops breaking randomly. I > | suspect this is a compiler or binutils problem but I can't see any > | clear differences in the generated code. I'll debug it later... > > This sounds like the hppa64 bug we saw with %r29 getting trashed. > But I don't think David was working on hppa64 kernel at the time. > I can test 32-bit NFS Root tomorrow w/o assertion if no one else > beats me to it. it was definitely a 32-bit kernel at the time. It might be the same bug, but I'm not sure. > > > * include/linux/init.h: we use different section names -- why????, > > > probably some unnecessary other differences too > > > > because we use -ffunction-sections. text.init clashes with a function > > called init, and the linker just merges it into the text segment. we > > need it to be separate, so it became init.text. there's patches around > > to do this for other architectures too. just bad naming choices initially. > > We need to resolve this in order to merge upstream. > Matthew, any advice on how we should proceed? > Or would be easier for you pester Alan Cox and just get it fixed? Hm. Alan's not hacking on 2.4, last I heard. I might pester Linus and see if we can change that. It's a mechanical change so he might not be averse to it at this point. Bear in mind we don't need to do a complete merge at this point -- most architectures have a separate patch to apply on top of Linus' tree. > > > * include/linux/wait.h: parisc debugging -- should be removed > > > > yeah, that can die now. > > I'd be happy to fix this by clobbering the current version with what's in > linux-2.4.0-test10. But what is the "right" way to revert changes we've made > so this doesn't show up in next merge? I don't know that there's an official way to do this. I always changed the file to its previous state and then committed it. There are a number of ways of doing it; perhaps the cleanest is: cvs diff -r1.4 -r1.5 fs/nfs/read.c >../read.c.diff (then check the read.c.diff file) patch -p1 <../read.c.diff rm ../read.c.diff or you can just delete the lines yourself. Use diff to make sure there aren't any silly cosmetic changes (eg whitespace). -- Revolutions do not require corporate support. From grundler@cup.hp.com Mon, 20 Nov 2000 09:34:31 -0800 Date: Mon, 20 Nov 2000 09:34:31 -0800 From: Grant Grundler grundler@cup.hp.com Subject: [parisc-linux] CVS linux Vs. -test10 Matthew Wilcox wrote: ... > sounds right. MMIO should work now though, right? It would have worked then too. Changing it to use MMIO space would require disabling I/O Port space by defining inb/outb locally to use gsc_readb/writeb. My problem with doing that was the semantics are slightly different. I/O Port space is non-postable and MMIO space is. I wasn't confident a driver written to use I/O port space would work right under MMIO though some certainly do. ... > it was definitely a 32-bit kernel at the time. It might be the same bug, > but I'm not sure. Can't be. AP (%r29) is a 64-bit only construct. dhd also just confirmed it was 32-bit kernel. I'll try it now. ... > > We need to resolve this in order to merge upstream. > > Matthew, any advice on how we should proceed? > > Or would be easier for you pester Alan Cox and just get it fixed? > > Hm. Alan's not hacking on 2.4, last I heard. I might pester Linus and > see if we can change that. It's a mechanical change so he might not be > averse to it at this point. Bear in mind we don't need to do a complete > merge at this point -- most architectures have a separate patch to apply > on top of Linus' tree. Ok. What's the first step to getting arch/parisc* and include/asm-parisc* into Linus's tree? I had dinner with Bdale Garbee last night and one of two things he made clear was we need to unfork from debian and linus's tree in order to move forward. All our CVS branches need to become obsolete or "local sandboxes" of the respective upstream partners. Feeding kernel bits upstream will bring a new level of visibility (and *HELP*) to the parisc-linux port. I totally agree with Bdale. I understand alot of work still needs to happen in our tree (eg though sba_iommu.c works, it's current form sucks) But pushing bits upstream to linus will not preclude us from doing that work. I also find it odd that glibc is merged upstream *before* the kernel is. For the record, the second issue bdale made clear was we need "boot floppies" debian package working. We don't need more ISO images (no offense to pjlahaie for his good work). "Boot floppies" is a pre-requisite to becoming part of the next debian release. Given I still don't have a clue how to build a debian package and I can still contribute alot in other areas, it doesn't make sense for me to do it myself. > > I'd be happy to fix this by clobbering the current version with what's in > > linux-2.4.0-test10. But what is the "right" way to revert changes we've made > > so this doesn't show up in next merge? > > I don't know that there's an official way to do this. I always changed > the file to its previous state and then committed it. There are a number of > ways of doing it; perhaps the cleanest is: > > cvs diff -r1.4 -r1.5 fs/nfs/read.c >../read.c.diff > (then check the read.c.diff file) > patch -p1 <../read.c.diff > rm ../read.c.diff > > or you can just delete the lines yourself. Use diff to make sure there > aren't any silly cosmetic changes (eg whitespace). The part you described above is the easy part - np. I'm worried about labels and tracking how we "name" the releases. Mang or other CVS ninja's care to comment? thanks, grant Grant Grundler Unix Systems Enablement Lab +1.408.447.7253 From rhirst@linuxcare.com Mon, 20 Nov 2000 17:58:38 +0000 Date: Mon, 20 Nov 2000 17:58:38 +0000 From: Richard Hirst rhirst@linuxcare.com Subject: [parisc-linux] signal handling problems (32 bit kernel) Hi, Following on from my problems with SEGV last week, I've come up with a few signal handling issues: ============================================================= parisc:signal.c /* Possibly bogus. */ #warning XXX FIXME probably bogus -PB /* I think this is bogus -- it'll cause the first instn of the * signal handler to be executed twice! Better might be to * set iaoq[0] to one of the NOPs in the trampoline. -PB */ regs->iaoq[0] = (unsigned long) haddr | 3; regs->iaoq[1] = (unsigned long) haddr | 3; This causes real problems if the signal handler is a dynamic object which has not yet been resolved; in that case the signal handler points at the b,l instr in the following at the end of the .plt: 2700: 0e 80 10 96 ldw 0(sr0,r20),r22 2704: ea c0 c0 00 bv r0(r22) 2708: 0e 88 10 95 ldw 4(sr0,r20),r21 270c: ea 9f 1f dd b,l 2700 <__DTOR_END__+0x54>,r20 2710: d6 80 1c 1e depwi 0,31,2,r20 typically that results in a misalligned access on the first ldw as r20 is screwed. I've fixed that by setting iaoq[1] = iaoq[0]+4. Is that OK, or should we use the NOP approach in the comment above? ============================================================= If a program gets a SEGV, fixes the cause of it in its signal handler, and returns, then the faulting instruction is not rerun. I think that's wrong (differs from m68k anyway). ============================================================= Set the following program running: #include #include #include #include int v[8]; void (* fp)(int); void sig_handler(int sig) { } void poke(int i) { v[0] = i; v[1] = i; v[2] = i; v[3] = i; v[4] = i; v[5] = i; v[6] = i; v[7] = i; } int main() { int j, i = 0; struct sigaction act; memset(&act, 0, sizeof(act)); act.sa_handler = sig_handler; sigaction(SIGUSR1, &act, NULL); fp = sig_handler; fp(0); printf("I am %d\n", getpid()); while (1) { poke (++i); j = v[7]; if (j != i) printf("Wah!\n"); } } and then in another terminal do 'kill -USR1 '. The program either goes 'Wah!', gives a SEGV, or works. That seems to be because %r1 is corrupted while processing the signal. The signal handler ends with a syscall (rt_sigreturn_wrapper), and %r1, at least, is not saved and restored over the syscall. %r31 also appears to get corrupted, as it is used in the final branch of the syscall return. Richard From sieler@allegro.com Mon, 20 Nov 2000 10:47:38 -0800 (PST) Date: Mon, 20 Nov 2000 10:47:38 -0800 (PST) From: Stan Sieler sieler@allegro.com Subject: Single-stepping Re: > Because you would then need to save and restore cr0 on task switches (or > only allow one task to be single-stepped at a time). That's four > instructions and two extra memory accesses per task switch. Which might > not seem very much, but at some point somebody will no doubt start caring > about pa-linux performance. And it still won't seem like much, then! Non-memory-access instructions are cheap. An extra memory reference (from something probably already in cache) and two extra instructions would probably cost less than an hour per CPU over the next 10 *years*, assuming 10 years of 1000 task switches per second on a slow 100 MHz CPU. Of course, at the cost of an extra non-memory-referencing instruction or so, you could say "at switch-to-task time: if PSW R-bit set, then load the saved CR0 from memory and move it to CR0", saving one memory reference 99.99999% of the time, resuling in an average of only one memory reference per task switch normally. I haven't look at interrupt handling / system calls closely, but I hope there aren't other false savings. (E.g., failure to save/restore the PID check flag ... sure, user processes *now* probably never have pid checking disabled, but that's a very useful feature to have available (with proper security controls, of course).) (Yes, I'm one of the very few who use that feature on MPE/iX ... carefully, of course :) -- Stan Sieler sieler@allegro.com www.allegro.com/sieler/wanted/index.html www.sieler.com From grundler@cup.hp.com Mon, 20 Nov 2000 11:23:40 -0800 Date: Mon, 20 Nov 2000 11:23:40 -0800 From: Grant Grundler grundler@cup.hp.com Subject: [parisc-linux] CVS linux Vs. -test10 Matthew Wilcox wrote: ... > > * fs/nfs/read.c: probably unnecessary hack for broken parisc64 gcc > > we certainly don't want to send it upstream, but we don't want to take it > out until the bug is fixed. is fixing that bug on the webshite todo list? It's fixed. I was able to NFS boot my A180 and install palinux-0.5.iso bits on the SCSI disk. I've reverted the change to the LINUS_240_TEST10 version. > > * include/linux/wait.h: parisc debugging -- should be removed > > yeah, that can die now. Is anyone else already doing this? thanks, grant Grant Grundler Unix Systems Enablement Lab +1.408.447.7253 From herrold@owlriver.com Mon, 20 Nov 2000 15:40:24 -0500 (EST) Date: Mon, 20 Nov 2000 15:40:24 -0500 (EST) From: herrold herrold@owlriver.com Subject: Serial vs. STI console selector was: Re: [parisc-linux] Beta CD On Tue, 14 Nov 2000, Paul J.Y. Lahaie wrote: > This is to answer all the questions about sti console. Currently, in the > CVS tree, serial console and STI console cannot be turned on at the same time. > > This means that a choice between serial/sti needs to be done at compile > time. > If you have any more questions or suggestions, feel free to email me or > post on this list. Thank you. ... Query -- Background: Back in the early 70's with a HP 8090 , IBM 1401, IBM 1620, and IBM 360/40, we faced such issues (Don't ask my age, please) -- The solution was to probe for, and look for 'sense switches' in unusual state -- that is -- Some condition which we could examine, and yet not hose up the boot proces on the host. -- CapsLock set on a keyboard driver -- DSR on a serial line, a 'console sense switch' normally kept off but turned on ... so on. Sort of like working through a qualitative analysis flowchart in non-organic chemistry. Is this possible, to allow support of both, with a single kernel? -- Russ From grundler@cup.hp.com Mon, 20 Nov 2000 12:59:41 -0800 Date: Mon, 20 Nov 2000 12:59:41 -0800 From: Grant Grundler grundler@cup.hp.com Subject: Serial vs. STI console selector was: Re: [parisc-linux] Beta CD "Russ" herrold wrote: > Is this possible, to allow support of both, with a single kernel? Yes. I think the issues are code not stomping on each other. And it's easy than you might think - PDC can tell us what the primary console is. grant Grant Grundler Unix Systems Enablement Lab +1.408.447.7253 From grundler@cup.hp.com Mon, 20 Nov 2000 17:19:03 -0800 (PST) Date: Mon, 20 Nov 2000 17:19:03 -0800 (PST) From: Grant Grundler grundler@cup.hp.com Subject: [parisc-linux] 712 ISL and palo Hi Paul (Bame), I tried booting 712 with "bo scsi.4.0 isl" with the palinux-0.5.iso image on a regular hard disk. I wanted to edit the "root" parameter so it would be /dev/sdb (also had a disk at scsi.0.0) instead of /dev/scd0. palo wouldn't accept any ps/2 keyboard input. Don't know if this is a palo or PDC bug. Any ideas? thanks, grant From alan@linuxcare.com.au Tue, 21 Nov 2000 12:55:42 +1100 (EST) Date: Tue, 21 Nov 2000 12:55:42 +1100 (EST) From: Alan Modra alan@linuxcare.com.au Subject: A DT_INIT/DT_FINI glibc patch. On Thu, 16 Nov 2000, H . J . Lu wrote: > While we are on this subject, I looked at the hppa code. It seems to > have the same bug. I have an impression that HP never really used > DT_INIT/DT_FINI. They use DT_INIT_ARRAY/DT_FINI_ARRAY. I don't know > if we should fix hppa also. Yes to all of these comments. elf32-hppa stole some ideas from ia64, which is why the bug is common. Fortunately, I think hppa ld.so etc. can be fixed in a way such that current (broken ABI) binaries will still work. Alan Modra -- Linuxcare. Support for the Revolution. From taggart@carmen.fc.hp.com Mon, 20 Nov 2000 20:12:33 -0700 Date: Mon, 20 Nov 2000 20:12:33 -0700 From: Matt Taggart taggart@carmen.fc.hp.com Subject: [parisc-linux] glibc-latest tarball broken dhazeghi@pacbell.net writes... > the glibc-latest tarball on pehc appears to be missing some important > subdirectories like scripts and sysdeps. Perhaps a legacy of the 2.2 > merge? Disk space problem. I made some room and generated new tarballs. Thanks for pointing out the problem. -- Matt Taggart taggart@fc.hp.com From alan@linuxcare.com.au Tue, 21 Nov 2000 14:22:53 +1100 (EST) Date: Tue, 21 Nov 2000 14:22:53 +1100 (EST) From: Alan Modra alan@linuxcare.com.au Subject: A DT_INIT/DT_FINI glibc patch. On Mon, 20 Nov 2000, Grant Grundler wrote: > I'm afraid we will break binary compatibility for elf32 hppa-linux again. > I only raise this in case there is really a "right" way to fix the > DT_INIT/DT_FINI problem. The fix involves pruning out all the special handling in bfd/elf32-hppa.c for DT_INIT,DT_FINI, and making some small changes to glibc. H.J. Lu has already made the necessary framework changes, and all we need to do is something like #define DL_FUNCTION_ADDRESS(map, addr) _dl_start_address (map, addr) #define DL_DT_INIT_ADDRESS(map, addr) \ ((addr) & 2 ? (addr) : DL_FUNCTION_ADDRESS (map, addr)) with similar defines for DT_FINI. The test for (addr) & 2 is the fairly innocuous fudge to support old binaries. Another glibc issue (which is why I'm sending this back to the list) is that there has been quite some discussion on the binutils list over the use of the EI_OSABI field. The conclusion being that it isn't really correct to use this field to discern the intendend execution platform. It's purpose is really to tell ELF tools that a file contains fields and values that need to be interpreted in a non-standard way. Since both elf32-hppa and elf64-hppa follow the standards, I'm inclined to think that the gnu tools should set EI_OSABI to zero for both HPUX and Linux targets. Instead the .note.ABI-tag section should be examined to determine the target, which sadly isn't set correctly at the moment. :-( Alan Modra -- Linuxcare. Support for the Revolution. From bame@riverrock.org Mon, 20 Nov 2000 21:02:40 -0700 Date: Mon, 20 Nov 2000 21:02:40 -0700 From: bame@riverrock.org bame@riverrock.org Subject: [parisc-linux] 712 ISL and palo = palo wouldn't accept any ps/2 keyboard input. = Don't know if this is a palo or PDC bug. = Any ideas? PALO bug. I didn't test the PS/2 case but I think I fixed it. -P From alan@linuxcare.com.au Tue, 21 Nov 2000 15:38:57 +1100 (EST) Date: Tue, 21 Nov 2000 15:38:57 +1100 (EST) From: Alan Modra alan@linuxcare.com.au Subject: A DT_INIT/DT_FINI glibc patch. On Tue, 21 Nov 2000, I wrote: > Instead the .note.ABI-tag section should be examined to determine the > target, which sadly isn't set correctly at the moment. :-( Actually, it is set correctly. A comment in csu/abi-note.S was wrong. -- Linuxcare. Support for the Revolution. From jsm@udlkern.fc.hp.com Mon, 20 Nov 2000 22:47:41 -0700 (MST) Date: Mon, 20 Nov 2000 22:47:41 -0700 (MST) From: John Marvin jsm@udlkern.fc.hp.com Subject: [parisc-linux] Use of the EI_OSABI field > Another glibc issue (which is why I'm sending this back to the list) is > that there has been quite some discussion on the binutils list over the > use of the EI_OSABI field. The conclusion being that it isn't really > correct to use this field to discern the intendend execution platform. > It's purpose is really to tell ELF tools that a file contains fields and > values that need to be interpreted in a non-standard way. Since both > elf32-hppa and elf64-hppa follow the standards, I'm inclined to think that > the gnu tools should set EI_OSABI to zero for both HPUX and Linux targets. I don't read the binutils mailing list, so I checked the archive. In my opinion I didn't see a discussion, I saw H.J. Lu repeatedly asserting this "fact". He may or may not be correct about original intention, but the implementation so far has been that EI_OSABI is used to tell what the target platform is. That is what FreeBSD is doing, that is what HP-UX is doing, and that is what the IA-64 Unix System V Application Binary Interface specifies: http://developer.intel.com/design/IA-64/Downloads/24537002.pdf Note that the second paragraph in section 1.1 of that specification includes the following: This document is the result of consensus among operating system vendors intending to provide UNIX and UNIX workalike operating systems on the IA-64 architecture. The vendors participating in this effort include Intel, Sun Microsystems, SCO, IBM, SGI, Cygnus Solutions, VA Linux Systems, HP, and Compaq. So, If the specification is wrong according to H.J. Lu, why did both Cygnus and VA Linux Systems not object to this: Section 4.1.1.4 Operating System Identification The e_ident[EI_OSABI] value identifies the operating system and ABI to which the object is targeted, as listed in Table 4-1. Table 4-1 lists the various ELFOSABI_* fields, e.g. ELFOSABI_HPUX, ELFOSABI_NETBSD, ELFOSABI_LINUX, etc. Note also, that the current mechanism for us to be able to differentiate elf executables in the Linux kernel is the machine dependent elf_check_arch() macro, whose only argument is a pointer to a elf32_hdr or elf64_hdr. I think it would be ugly to try to get the .note.ABI-tag section first for every exec of a new binary in order to determine what the target ABI is. In my opinion, unless H.J. Lu can get the IA-64 ABI changed, it is too late to assert his view of what that field was supposed to be. Please leave the EI_OSABI field set to ELFOSABI_LINUX until a better consensus on this issue is reached. John Marvin jsm@fc.hp.com From alan@linuxcare.com.au Tue, 21 Nov 2000 18:05:36 +1100 (EST) Date: Tue, 21 Nov 2000 18:05:36 +1100 (EST) From: Alan Modra alan@linuxcare.com.au Subject: [parisc-linux] signal handling problems (32 bit kernel) On Mon, 20 Nov 2000, Richard Hirst wrote: > #warning XXX FIXME probably bogus -PB > /* I think this is bogus -- it'll cause the first instn of the > * signal handler to be executed twice! Better might be to Definitely bogus, as with quite a lot of iaoq manipulation in signal.c > I've fixed that by setting iaoq[1] = iaoq[0]+4. Is that OK, or Sounds like the right thing to do. I reckon everywhere ioaq is fudged from/to r31 should have this sort of mapping. ie. it should be regs->gr[31] = regs->iaoq[0]; in sys_rt_sigreturn, and err |= __put_user(regs->gr[31], &sc->sc_iaoq[0]); err |= __put_user(regs->gr[31] + 4, &sc->sc_iaoq[1]); in setup_sigcontext, and so on. I'm guessing the origial author of this code didn't know which of iaoq[0] and ioaq[1] was ioaq_front. :) > and then in another terminal do 'kill -USR1 '. The program > either goes 'Wah!', gives a SEGV, or works. That seems to be because > %r1 is corrupted while processing the signal. The signal handler ends > with a syscall (rt_sigreturn_wrapper), and %r1, at least, is not saved > and restored over the syscall. %r31 also appears to get corrupted, as > it is used in the final branch of the syscall return. I don't really understand what is going on here, but it seems wrong to me that setup_rt_frame should be touching regs->iaoq at all when in_syscall. Hmm, and in that case why all the other gr[31] to/from ioaq[] fudgery? Alan -- Linuxcare. Support for the Revolution. From rhirst@linuxcare.com Tue, 21 Nov 2000 09:34:42 +0000 Date: Tue, 21 Nov 2000 09:34:42 +0000 From: Richard Hirst rhirst@linuxcare.com Subject: [parisc-linux] signal handling problems (32 bit kernel) On Tue, Nov 21, 2000 at 06:05:36PM +1100, Alan Modra wrote: > On Mon, 20 Nov 2000, Richard Hirst wrote: > > > #warning XXX FIXME probably bogus -PB > > /* I think this is bogus -- it'll cause the first instn of the > > * signal handler to be executed twice! Better might be to > > Definitely bogus, as with quite a lot of iaoq manipulation in signal.c As another example, if a process gets a signal as it is about to execute the instr in the delay slot of a branch, it forgets that it was supposed to be branching on return from the signal handler. Try compiling the following and sending it a SIGUSR1: #include #include #include #include void sig_handler(int sig) { } int main() { struct sigaction act; int i = 1; memset(&act, 0, sizeof(act)); act.sa_handler = sig_handler; sigaction(SIGUSR1, &act, NULL); printf("I am %d\n", getpid()); while (i++) ; printf("Escaped, i=%d!\n", i); return 0; } Oh, you have to run it with "LD_BIND_NOW=1 " to avoid one of the other problems. Time to try and work out what signal.c is really trying to do, I guess. Richard From alan@linuxcare.com.au Tue, 21 Nov 2000 22:26:14 +1100 (EST) Date: Tue, 21 Nov 2000 22:26:14 +1100 (EST) From: Alan Modra alan@linuxcare.com.au Subject: [parisc-linux] signal handling problems (32 bit kernel) On Tue, 21 Nov 2000, Richard Hirst wrote: > Time to try and work out what signal.c is really trying to do, I guess. Maybe you should start by considering all the possible states a task can be in when a signal is delivered, in regards to saved registers and stack layout. It would be a _very_ good idea to formalize this once you've sorted it out by splitting up struct pt_regs appropriately. ie. as other architectures do, into struct pt_regs and struct switch_stack. Actually, parisc could go one further and have three structures, one corresponding to registers saved on syscall entry (new pt_regs), one corresponding to macro callee_save (switch_stack), and one corresponding more or less to macro save_specials. Quite a bit of work, but IMO well worth doing. Alan Modra -- Linuxcare. Support for the Revolution. From matthew@wil.cx Tue, 21 Nov 2000 11:34:32 +0000 Date: Tue, 21 Nov 2000 11:34:32 +0000 From: Matthew Wilcox matthew@wil.cx Subject: [parisc-linux] CVS linux Vs. -test10 On Mon, Nov 20, 2000 at 09:34:31AM -0800, Grant Grundler wrote: > Ok. What's the first step to getting arch/parisc* and include/asm-parisc* > into Linus's tree? Someone (probably me) sends him a patch. He told me at the Toronto show that he was quite happy to apply anything that only touched those two directories. (oh, and drivers/gsc wouldn't be a problem either). Can I just check that no-one wants to rename drivers/gsc again? :-) > I had dinner with Bdale Garbee last night and one of two things he made > clear was we need to unfork from debian and linus's tree in order to move > forward. All our CVS branches need to become obsolete or "local sandboxes" > of the respective upstream partners. Feeding kernel bits upstream will > bring a new level of visibility (and *HELP*) to the parisc-linux port. that's true. last time we discussed this several people were unhappy with the idea of sending our current work to Linus. Is anyone unhappy with doing this now? > I also find it odd that glibc is merged upstream *before* the kernel is. glibc is more portable :-) > The part you described above is the easy part - np. > I'm worried about labels and tracking how we "name" the releases. > Mang or other CVS ninja's care to comment? don't tag it. just commit it. tags are laid down at big events, not when you fix bugs or undo changes. -- Revolutions do not require corporate support. From jsm@udlkern.fc.hp.com Tue, 21 Nov 2000 06:11:29 -0700 (MST) Date: Tue, 21 Nov 2000 06:11:29 -0700 (MST) From: John Marvin jsm@udlkern.fc.hp.com Subject: CVS linux Vs. -test10 > > I had dinner with Bdale Garbee last night and one of two things he made > > clear was we need to unfork from debian and linus's tree in order to move > > forward. All our CVS branches need to become obsolete or "local sandboxes" > > of the respective upstream partners. Feeding kernel bits upstream will > > bring a new level of visibility (and *HELP*) to the parisc-linux port. > > that's true. last time we discussed this several people were unhappy > with the idea of sending our current work to Linus. Is anyone unhappy > with doing this now? > Are we suggesting that we populate include/asm-parisc* and arch/parisc* WITHOUT the machine independent changes in the rest of the tree? If that is the case, I guess I don't object, although I would want to make sure that Linus knew the state of the code, and that it would not work without a patch containing changes to the machine independent part, and that followup patches to these branches are likely to be huge. We should also add a README in arch/parisc that explains the above (and where to get patches, how to access CVS, etc.). We also need someone to set up an automatic nightly? patch generator. I certainly don't want to try to get the machine independent changes in yet, since we still have some major issues to fix/clean there, and I doubt Linus would want them at this time anyway. John Marvin jsm@fc.hp.com From rhirst@linuxcare.com Tue, 21 Nov 2000 16:54:42 +0000 Date: Tue, 21 Nov 2000 16:54:42 +0000 From: Richard Hirst rhirst@linuxcare.com Subject: [parisc-linux] signal handling problems (32 bit kernel) On Tue, Nov 21, 2000 at 06:05:36PM +1100, Alan Modra wrote: > > and then in another terminal do 'kill -USR1 '. The program > > either goes 'Wah!', gives a SEGV, or works. That seems to be because > > %r1 is corrupted while processing the signal. The signal handler ends > > with a syscall (rt_sigreturn_wrapper), and %r1, at least, is not saved > > and restored over the syscall. %r31 also appears to get corrupted, as > > it is used in the final branch of the syscall return. > > I don't really understand what is going on here, but it seems wrong to me > that setup_rt_frame should be touching regs->iaoq at all when in_syscall. Problem is that whenever a signal handler is invoked, it is followed by a sys_rt_sigreturn syscall (invoked via the trampoline code), before returning to original usercode. I can imagine that this might work if the process in question was blocked on a syscall, but not if it was suspended due to an interrupt. In either case the path back to the original user code is the syscall return path, and that obviously cannot put things back as they were if the process was interrupted. I think the answer is for syscall_do_signal to save enough in the pt_regs such that sys_rt_sigreturn_wrapper can return to userland via an RFI (like intr_restore, but remembering to trace the syscall exit if necessary) regardless of the process state when the signal occurred. Richard From taggart@carmen.fc.hp.com Tue, 21 Nov 2000 10:20:35 -0700 Date: Tue, 21 Nov 2000 10:20:35 -0700 From: Matt Taggart taggart@carmen.fc.hp.com Subject: [parisc-linux] kernel BUG at sched.c:692! I arrived this morning to discover both my B160 and my C3000 were printing the following as fast as they could, Scheduling in interrupt kernel BUG at sched.c:692! Looking at linux/kernel/sched.c here's the relevant section, 690 scheduling_in_interrupt: 691 printk("Scheduling in interrupt\n"); 692 BUG(); 693 return; scheduling_in_interrupt is called from line 516. Here's some context, 500 asmlinkage void schedule(void) 501 { 502 struct schedule_data * sched_data; 503 struct task_struct *prev, *next, *p; 504 struct list_head *tmp; 505 int this_cpu, c; 506 507 if (!current->active_mm) BUG(); 508 if (tq_scheduler) 509 goto handle_tq_scheduler; 510 tq_scheduler_back: 511 512 prev = current; 513 this_cpu = prev->processor; 514 515 if (in_interrupt()) 516 goto scheduling_in_interrupt; 517 518 release_kernel_lock(prev, this_cpu); I thought it was odd that both systems chose to freak out last night when I have never seen this problem on either of them. The B160 is running a slightly newer kernel and had been up for about 3 days as of last night. The C3K had been up for 4-5 days. When I left last night the B160 was doing a build although the it looks like the build died before this problem occurred. The C3K was idle. Any ideas? Thanks, -- Matt Taggart taggart@fc.hp.com From robert.reilly@gecapital.com Tue, 21 Nov 2000 18:26:41 GMT Date: Tue, 21 Nov 2000 18:26:41 GMT From: Robert Reilly robert.reilly@gecapital.com Subject: [parisc-linux] cd .5 Hi All, I have HP9000/d212 I was able to boot off the cdrom image no problem, however when I get the login prompt I am only able to type in two characters and the screen redraws itself and prompts me for a login. I am using a HP700 serial terminal on ttyS0.I briefly scanned the mailing list but did not find anything. Any help would be appreciated. --Robert Reilly GE Capital Card Service UNIX Administrator robert.reilly@gecapital.com From matthew@wil.cx Tue, 21 Nov 2000 17:38:57 +0000 Date: Tue, 21 Nov 2000 17:38:57 +0000 From: Matthew Wilcox matthew@wil.cx Subject: CVS linux Vs. -test10 On Tue, Nov 21, 2000 at 06:11:29AM -0700, John Marvin wrote: > Are we suggesting that we populate include/asm-parisc* and arch/parisc* > WITHOUT the machine independent changes in the rest of the tree? Yes. > If that is the case, I guess I don't object, although I would want > to make sure that Linus knew the state of the code, and that it would > not work without a patch containing changes to the machine independent > part, and that followup patches to these branches are likely to be > huge. We should also add a README in arch/parisc that explains the > above (and where to get patches, how to access CVS, etc.). We also > need someone to set up an automatic nightly? patch generator. Agreed. The patch generation is not a big deal to arrange. > I certainly don't want to try to get the machine independent changes in > yet, since we still have some major issues to fix/clean there, and I doubt > Linus would want them at this time anyway. Certainly none of the stack direction changes. Some of the MI stuff is arguably stuff we could put in. -- Revolutions do not require corporate support. From Pirvulescu_Alexandru@telemobil.ro Tue, 21 Nov 2000 20:49:57 +0200 Date: Tue, 21 Nov 2000 20:49:57 +0200 From: Alexandru Pirvulescu Pirvulescu_Alexandru@telemobil.ro Subject: [parisc-linux] case LEDs Hello Is there any possibility to activate the case LEDs? I mean the heartbeat and the network activity I have a A180 machine Alex From grundler@cup.hp.com Tue, 21 Nov 2000 10:55:06 -0800 Date: Tue, 21 Nov 2000 10:55:06 -0800 From: Grant Grundler grundler@cup.hp.com Subject: [parisc-linux] case LEDs "Alexandru Pirvulescu" wrote: > Hello > > Is there any possibility to activate the case LEDs? I mean the heartbeat and > the network activity. I have a A180 machine. Yes. I was already asked this weekend to dig up technical info on LED and soft power control. I guess this is my reminder to do that. :^) grant From grundler@cup.hp.com Tue, 21 Nov 2000 10:59:24 -0800 Date: Tue, 21 Nov 2000 10:59:24 -0800 From: Grant Grundler grundler@cup.hp.com Subject: [parisc-linux] cd .5 Robert Reilly wrote: > Hi All, > I have HP9000/d212 I was able to boot off the cdrom image no problem, > however when I get the login prompt I am only able to type in two > characters and the screen redraws itself and prompts me for a login. I am > using a HP700 serial terminal on ttyS0. I briefly scanned the mailing list > but did not find anything. Any help would be appreciated. Robert, I would suspent the terminal isn't configured correctly for the serial connection. Is it set up for 9600 baud, 8 data bits, no parity, 1 stop bit? I'm pretty sure you have the baud rate correct since you get a login prompt. I'm not sure all the other things must be correct to get that far. I'm not familiar with "HP700 serial terminal". But all the HP terminals I've worked with in the past also support vt100 emulation mode. You probably want to set that too. grant Grant Grundler Unix Systems Enablement Lab +1.408.447.7253 From kailasr@webcash.com Tue, 21 Nov 2000 12:30:12 -0800 Date: Tue, 21 Nov 2000 12:30:12 -0800 From: Kailashnath V Rampure kailasr@webcash.com Subject: [parisc-linux] Apache package. Hi Paul, I have installed Apache + mod_ssl + mod_perl on HP A Class server. I need help on to change the server looking fort bootpd server and put the IP address on the system. Also where can I find the ftp client for linux . Regards Kalas At 04:59 PM 11/15/00 -0700, Paul Bame wrote: >= I tried to build apache_1.3.12 on HP a class server. But I have error. I >= have tried to check the site >= ftp://ftp.debian.org/debian/dists/unstable/main/binary-hppa/ >= I could not find one. I found some apache-doc etc. > >We are still working on some kernel features which are required to >support Apache (system 5 shared memory). > > -P From grundler@cup.hp.com Tue, 21 Nov 2000 13:24:31 -0800 Date: Tue, 21 Nov 2000 13:24:31 -0800 From: Grant Grundler grundler@cup.hp.com Subject: [parisc-linux] CVS linux Vs. -test10 Matthew Wilcox wrote: ... > Someone (probably me) sends him a patch. He told me at the Toronto > show that he was quite happy to apply anything that only touched those > two directories. (oh, and drivers/gsc wouldn't be a problem either). > Can I just check that no-one wants to rename drivers/gsc again? :-) Hi Mathew, I don't and it's a good question. I would like a few files moved: arch/parisc/kernel/ccio-dma.c -> drivers/gsc/ccio-dma.c arch/parisc/kernel/ccio-rm-dma.c -> drivers/gsc/ccio-rm-dma.c ccio will *always* be associated with a GSC bus since that's the secondary bus. And ccio supports devices below dino.c which already lives in drivers/gsc. arch/parisc/kernel/lba_pci.c -> drivers/ropes/lba_pci.c arch/parisc/kernel/sba_iommu.c -> drivers/ropes/sba_iommu.c arch/parisc/kernel/iosapic.c -> drivers/ropes/iosapic.c lba/sba code is equivalent to dino/ccio code for another set of platforms. And long term, I'm certain iosapic.c does not belong under arch/parisc. I can do this move if there are no major objections. Any reason why we couldn't do these moves *after* you submit a patch? FWIW, here are issues I see with merging IA64 iosapic code with mine: o iosapic "discovery" (I invented register_iosapic() interface for parisc) o parisc PDC calls (initialization) o interrupt policy decisions (eg EOI generation and picking a CPU) o I don't have time to do it in the near future. Folks working on IA64 stuff inside HP need to think about: (a) if they want to do the merge any time soon (b) which iosapic.c they want to start with (c) where the final version should live thanks, grant Grant Grundler Unix Systems Enablement Lab +1.408.447.7253 From pjlahaie@linuxcare.com Tue, 21 Nov 2000 16:41:48 -0500 Date: Tue, 21 Nov 2000 16:41:48 -0500 From: Paul J.Y. Lahaie pjlahaie@linuxcare.com Subject: [parisc-linux] Fun build problems --PW0Eas8rCkcu1VkF Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hello everyone, Over the last couple of days, I've been trying to get the debian boot-floppies building (I know some changes will be necessary) and as it stands now, several packages are missing. In the process of trying to compile/install these packages, I've run into some difficulties. Here are some of them: apt -- Package on pehc and .iso do not work. Missing lots of helper apps. Seeing as apt was broken, I decided to download the woody version of apt so I can get a newer version and hopefully skip some steps in building the above packages. gcc 2.96 and apt-0.3.19 don't get along, so I tried picking it up from cvs (supposed to have been fixed). Follow the directions on cvs.debian.org $ cvs -d :pserver:anonymous@cvs.debian.org:/cvs/APT login (Logging in to anonymous@cvs.debian.org) CVS password:=20 cvs login: authorization failed: server cvs.debian.org rejected access Anyone know if there are other instructions other than what cvs.debian.org says? If so, feel free to email me rsync -- ldd crashes on dpkg-shlibdepends stage Can I just manually put the required dependancies in? autoconf -- installinfo spins When installing the autoconf package (to compile dpkg) installinfo spins. And after several minutes still doesn't return. It's taking up 100% cpu at the time. If I abort this, autoconf seems to be installed but cannot generate the dpkg configure properly, some macros are missing AM_CONDITIONAL(HAVE_CPLUSPLUS, test "$CXX" !=3D "") Is in the ./configure script. info -- Reinstall spins If I try to reinstall info, it spins on the uninstall. 100% cpu. If anyone has any solutions for any of the above problems, I am all ears (eyes?). - Paul --PW0Eas8rCkcu1VkF Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.4 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE6Guwc8ggPQthPCzcRAgkGAJ9TzClXOg009RWO/v09ONBNnxJcbgCfcWcX gj26osR06BqyJ0O+/Q83csk= =YHRW -----END PGP SIGNATURE----- --PW0Eas8rCkcu1VkF-- From alan@linuxcare.com.au Wed, 22 Nov 2000 09:50:05 +1100 (EST) Date: Wed, 22 Nov 2000 09:50:05 +1100 (EST) From: Alan Modra alan@linuxcare.com.au Subject: [parisc-linux] Use of the EI_OSABI field cc to binutils because John makes some salient points. On Mon, 20 Nov 2000, John Marvin wrote: > > Another glibc issue (which is why I'm sending this back to the list) is > > that there has been quite some discussion on the binutils list over the > > use of the EI_OSABI field. The conclusion being that it isn't really > > correct to use this field to discern the intendend execution platform. > > It's purpose is really to tell ELF tools that a file contains fields and > > values that need to be interpreted in a non-standard way. Since both > > elf32-hppa and elf64-hppa follow the standards, I'm inclined to think that > > the gnu tools should set EI_OSABI to zero for both HPUX and Linux targets. > > I don't read the binutils mailing list, so I checked the archive. In my > opinion I didn't see a discussion, I saw H.J. Lu repeatedly asserting > this "fact". He may or may not be correct about original intention, but > the implementation so far has been that EI_OSABI is used to tell what the > target platform is. That is what FreeBSD is doing, that is what HP-UX is > doing, and that is what the IA-64 Unix System V Application Binary > Interface specifies: > > http://developer.intel.com/design/IA-64/Downloads/24537002.pdf > > Note that the second paragraph in section 1.1 of that specification > includes the following: > > This document is the result of consensus among operating system > vendors intending to provide UNIX and UNIX workalike operating > systems on the IA-64 architecture. The vendors participating in > this effort include Intel, Sun Microsystems, SCO, IBM, SGI, > Cygnus Solutions, VA Linux Systems, HP, and Compaq. > > So, If the specification is wrong according to H.J. Lu, why did both > Cygnus and VA Linux Systems not object to this: > > Section 4.1.1.4 Operating System Identification > > The e_ident[EI_OSABI] value identifies the operating system and > ABI to which the object is targeted, as listed in Table 4-1. > > Table 4-1 lists the various ELFOSABI_* fields, e.g. ELFOSABI_HPUX, > ELFOSABI_NETBSD, ELFOSABI_LINUX, etc. > > Note also, that the current mechanism for us to be able to differentiate > elf executables in the Linux kernel is the machine dependent > elf_check_arch() macro, whose only argument is a pointer to a > elf32_hdr or elf64_hdr. I think it would be ugly to try to get the > .note.ABI-tag section first for every exec of a new binary in order > to determine what the target ABI is. > > In my opinion, unless H.J. Lu can get the IA-64 ABI changed, it is too > late to assert his view of what that field was supposed to be. Please > leave the EI_OSABI field set to ELFOSABI_LINUX until a better consensus > on this issue is reached. > > John Marvin > jsm@fc.hp.com I'm happy enough to leave things as they are in puffin CVS, but these changes haven't been merged back to sourceware yet, partly because I had some doubts myself as to whether setting EI_OSABI was correct. H.J. Lu wasn't the only one arguing that EI_OSABI should be left at zero; Ulrich Drepper also was quite vehement against changing sourceware FreeBSD binutils. BTW, it's not too hard to check .note.ABI-tag. The linker arranges for a PT_NOTE program header entry to point to it, and the section itself is virtually guaranteed to be read in with the header as it's placed right after the header along with .interp. Alan Modra -- Linuxcare. Support for the Revolution. From drepper@redhat.com 21 Nov 2000 15:27:19 -0800 Date: 21 Nov 2000 15:27:19 -0800 From: Ulrich Drepper drepper@redhat.com Subject: [parisc-linux] Use of the EI_OSABI field Alan Modra writes: > Ulrich Drepper also was quite vehement against changing sourceware > FreeBSD binutils. I've never said anything about any *BSD, why should I? The *BSD people wanted to change the Linux binutils. Anyway, the ABI value is zero unless you implement ELF extensions. -- ---------------. ,-. 1325 Chesapeake Terrace Ulrich Drepper \ ,-------------------' \ Sunnyvale, CA 94089 USA Red Hat `--' drepper at redhat.com `------------------------ From alan@linuxcare.com.au Wed, 22 Nov 2000 11:13:29 +1100 (EST) Date: Wed, 22 Nov 2000 11:13:29 +1100 (EST) From: Alan Modra alan@linuxcare.com.au Subject: [parisc-linux] Use of the EI_OSABI field On 21 Nov 2000, Ulrich Drepper wrote: > Alan Modra writes: > > > Ulrich Drepper also was quite vehement against changing sourceware > > FreeBSD binutils. > > I've never said anything about any *BSD, why should I? The *BSD > people wanted to change the Linux binutils. Sorry, I stated that badly. > Anyway, the ABI value is zero unless you implement ELF extensions. Exactly what is an "ELF extension"? Anything outside gABI or "gABI + psABI"? Handly the latter, as it seems to me that a processor specific ABI can specify extensions. There's also the awkward possibility that a psABI may specify an extension that is later incorporated into a new revision of the gABI (eg. hpux and DT_INIT_ARRAY) Does that mean that if a new revision of the gABI completely incorporates all previous extensions, that EI_OSABI should become zero? Yes, I'm arguing that "No ELF extensions => EI_OSABI == 0" is not necessarily true, but I'm _not_ arguing that changing x86 Linux binutils is wise. Historical usage is important. If we were to change x86 Linux binutils to set EI_OSABI, then that can only be after a considerable period of time to allow code such as glibc to accept a new branding. Alan Modra -- Linuxcare. Support for the Revolution. From drepper@redhat.com 21 Nov 2000 16:31:39 -0800 Date: 21 Nov 2000 16:31:39 -0800 From: Ulrich Drepper drepper@redhat.com Subject: [parisc-linux] Use of the EI_OSABI field Alan Modra writes: > Exactly what is an "ELF extension"? Anything outside gABI or > "gABI + psABI"? Anything beyond the psABI that cannot be handled by the rules in the gABI. -- ---------------. ,-. 1325 Chesapeake Terrace Ulrich Drepper \ ,-------------------' \ Sunnyvale, CA 94089 USA Red Hat `--' drepper at redhat.com `------------------------ From hjl@valinux.com Tue, 21 Nov 2000 16:53:27 -0800 Date: Tue, 21 Nov 2000 16:53:27 -0800 From: H . J . Lu hjl@valinux.com Subject: [parisc-linux] Use of the EI_OSABI field On Wed, Nov 22, 2000 at 11:13:29AM +1100, Alan Modra wrote: > > > Anyway, the ABI value is zero unless you implement ELF extensions. > > Exactly what is an "ELF extension"? Anything outside gABI or ELF extension is something whose interpretation is not documented in neither gABI nor psABI. HP's old ELF is a good example since it didn't implement DT_INIT/DT_FINI, but added DT_INIT_ARRARY/DT_FINI_ARRAY. A normal ELF tool will have a hard time to interpret those fields and their values. H.J. From matthew@wil.cx Wed, 22 Nov 2000 00:53:09 +0000 Date: Wed, 22 Nov 2000 00:53:09 +0000 From: Matthew Wilcox matthew@wil.cx Subject: [parisc-linux] CVS linux Vs. -test10 On Tue, Nov 21, 2000 at 01:24:31PM -0800, Grant Grundler wrote: > I would like a few files moved: > > arch/parisc/kernel/ccio-dma.c -> drivers/gsc/ccio-dma.c > arch/parisc/kernel/ccio-rm-dma.c -> drivers/gsc/ccio-rm-dma.c > arch/parisc/kernel/lba_pci.c -> drivers/ropes/lba_pci.c > arch/parisc/kernel/sba_iommu.c -> drivers/ropes/sba_iommu.c > arch/parisc/kernel/iosapic.c -> drivers/ropes/iosapic.c > Any reason why we couldn't do these moves *after* you submit a patch? Better to get our house in order before we patchbomb Linus, I think. Renames are hard enough in CVS; renames in diff -u format are a real stinker :-) -- Revolutions do not require corporate support. From adevries@linuxcare.com Tue, 21 Nov 2000 21:27:51 -0500 Date: Tue, 21 Nov 2000 21:27:51 -0500 From: Alex deVries adevries@linuxcare.com Subject: [parisc-linux] case LEDs Grant Grundler wrote: > Yes. > I was already asked this weekend to dig up technical info on LED > and soft power control. I guess this is my reminder to do that. :^) Isn't there a PDC call (pdc_chassis?) to do this? Or is the heartbeat LED done by hardware? - Alex -- Alex deVries, Principal Solutions Architect, The Puffins at Linuxcare 613.562.2759 tel alex@linuxcare.com, http://www.linuxcare.com/ Linuxcare, Support for the revolution. From randolph@tausq.org Tue, 21 Nov 2000 18:50:24 -0700 Date: Tue, 21 Nov 2000 18:50:24 -0700 From: Randolph Chung randolph@tausq.org Subject: [parisc-linux] Fun build problems --9zSXsLTf0vkW971A Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable > Seeing as apt was broken, I decided to download the woody version of apt = so > I can get a newer version and hopefully skip some steps in building the > above packages. gcc 2.96 and apt-0.3.19 don't get along, so I tried pick= ing > it up from cvs (supposed to have been fixed). Follow the directions on > cvs.debian.org >=20 > $ cvs -d :pserver:anonymous@cvs.debian.org:/cvs/APT login > (Logging in to anonymous@cvs.debian.org) > CVS password:=20 > cvs login: authorization failed: server cvs.debian.org rejected access Try: cvs -d:pserver:anonymous@cvs.debian.org:/cvs/deity login (empty password) It should work. if not let me know and i can mail you a tarball. You probably want to get the aliencode branch, which has hppa patches. Let me know if you run into any problems. > rsync -- ldd crashes on dpkg-shlibdepends stage > Can I just manually put the required dependancies in? Yes, or pick up the dpkg-architecture and dpkg-shlibdeps scripts from http://puffin.external.hp.com/~tausq/, or wait for the next version of dpkg to get built for hppa (it doesn't use ldd anymore) > autoconf -- installinfo spins >=20 > When installing the autoconf package (to compile dpkg) installinfo spins. > And after several minutes still doesn't return. It's taking up 100% cpu > at the time. hmmm.. didn't see this. I had built a slightly older version of dpkg successfully. randolph (tausq@debian.org) --=20 @..@ http://www.TauSq.org/ (----) ( >__< ) ^^ ~~ ^^ --9zSXsLTf0vkW971A Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.1 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE6GyZgULspdC1Zp9IRAozyAKC/Df1fexltMjFlcwpeYlD+IIWEigCgiGyT YKOjLA0BQzMo7qOj8jC1BTI= =whh1 -----END PGP SIGNATURE----- --9zSXsLTf0vkW971A-- From hjl@valinux.com Tue, 21 Nov 2000 19:11:29 -0800 Date: Tue, 21 Nov 2000 19:11:29 -0800 From: H . J . Lu hjl@valinux.com Subject: [parisc-linux] Use of the EI_OSABI field On Wed, Nov 22, 2000 at 02:03:07PM +1100, Alan Modra wrote: > On Tue, 21 Nov 2000, H . J . Lu wrote: > > > On Wed, Nov 22, 2000 at 11:13:29AM +1100, Alan Modra wrote: > > > > > > > Anyway, the ABI value is zero unless you implement ELF extensions. > > > > > > Exactly what is an "ELF extension"? Anything outside gABI or > > > > ELF extension is something whose interpretation is not documented in > > neither gABI nor psABI. HP's old ELF is a good example since it didn't > > implement DT_INIT/DT_FINI, but added DT_INIT_ARRARY/DT_FINI_ARRAY. A > > normal ELF tool will have a hard time to interpret those fields and > > their values. > > Neither you nor Ulrich have responded to John's point that the IA64 psABI > states > "The e_ident[EI_OSABI] value identifies the operating system and ABI to > which the object is targeted" > > Granted, this is only in a processor specific ABI, but it does flatly > contradict your assertions that the purpose of EI_OSABI is to flag the > presense of ELF extensions. > When I was at the IA64 ABI meeting yesterday, we were looking at the EI_OSABI issue. Everyone at the IA64 ABI meeting agreed that what Ulrich and I had said was the correct understanding. "The e_ident[EI_OSABI] value identifies the operating system and ABI to which the object is targeted" just means if the e_ident[EI_OSABI] value is not ELFOSABI_NONE, you have to look somewhere else in addition to gABI and IA64 psABI to interpret the ELF fields/values specific to that OS. Otherwise, gABI and IA64 psABI are sufficient. -- H.J. Lu (hjl@valinux.com) From drepper@redhat.com 21 Nov 2000 19:18:21 -0800 Date: 21 Nov 2000 19:18:21 -0800 From: Ulrich Drepper drepper@redhat.com Subject: [parisc-linux] Use of the EI_OSABI field Alan Modra writes: > "The e_ident[EI_OSABI] value identifies the operating system and ABI to > which the object is targeted" > > Granted, this is only in a processor specific ABI, but it does flatly > contradict your assertions that the purpose of EI_OSABI is to flag the > presense of ELF extensions. The meaning of the field changed over time. Or better said, some people initially understood it differently. -- ---------------. ,-. 1325 Chesapeake Terrace Ulrich Drepper \ ,-------------------' \ Sunnyvale, CA 94089 USA Red Hat `--' drepper at redhat.com `------------------------ From alan@linuxcare.com.au Wed, 22 Nov 2000 14:03:07 +1100 (EST) Date: Wed, 22 Nov 2000 14:03:07 +1100 (EST) From: Alan Modra alan@linuxcare.com.au Subject: [parisc-linux] Use of the EI_OSABI field On Tue, 21 Nov 2000, H . J . Lu wrote: > On Wed, Nov 22, 2000 at 11:13:29AM +1100, Alan Modra wrote: > > > > > Anyway, the ABI value is zero unless you implement ELF extensions. > > > > Exactly what is an "ELF extension"? Anything outside gABI or > > ELF extension is something whose interpretation is not documented in > neither gABI nor psABI. HP's old ELF is a good example since it didn't > implement DT_INIT/DT_FINI, but added DT_INIT_ARRARY/DT_FINI_ARRAY. A > normal ELF tool will have a hard time to interpret those fields and > their values. Neither you nor Ulrich have responded to John's point that the IA64 psABI states "The e_ident[EI_OSABI] value identifies the operating system and ABI to which the object is targeted" Granted, this is only in a processor specific ABI, but it does flatly contradict your assertions that the purpose of EI_OSABI is to flag the presense of ELF extensions. Alan Modra -- Linuxcare. Support for the Revolution. From rbradetich@uswest.net Tue, 21 Nov 2000 22:54:11 -0800 Date: Tue, 21 Nov 2000 22:54:11 -0800 From: Ryan Bradetich rbradetich@uswest.net Subject: [parisc-linux] CVS linux Vs. -test10 Grant Grundler wrote: > Matthew Wilcox wrote: > ... > > Someone (probably me) sends him a patch. He told me at the Toronto > > show that he was quite happy to apply anything that only touched those > > two directories. (oh, and drivers/gsc wouldn't be a problem either). > > Can I just check that no-one wants to rename drivers/gsc again? :-) > > Hi Mathew, > I don't and it's a good question. > I would like a few files moved: > > arch/parisc/kernel/ccio-dma.c -> drivers/gsc/ccio-dma.c > arch/parisc/kernel/ccio-rm-dma.c -> drivers/gsc/ccio-rm-dma.c Grant, Do you really want to merget the ccio-rm-dma.c file into Linus's tree? It is just a reference file used to construct the real ccio-dma.c file ... I don't believe it is referenced anywhere. I'll double check this in the morning. - Ryan > ccio will *always* be associated with a GSC bus since that's > the secondary bus. And ccio supports devices below dino.c which > already lives in drivers/gsc. > > arch/parisc/kernel/lba_pci.c -> drivers/ropes/lba_pci.c > arch/parisc/kernel/sba_iommu.c -> drivers/ropes/sba_iommu.c > arch/parisc/kernel/iosapic.c -> drivers/ropes/iosapic.c > > lba/sba code is equivalent to dino/ccio code for another set > of platforms. And long term, I'm certain iosapic.c does not > belong under arch/parisc. I can do this move if there are no > major objections. > > Any reason why we couldn't do these moves *after* you submit a patch? > > FWIW, here are issues I see with merging IA64 iosapic code with mine: > o iosapic "discovery" (I invented register_iosapic() interface for parisc) > o parisc PDC calls (initialization) > o interrupt policy decisions (eg EOI generation and picking a CPU) > o I don't have time to do it in the near future. > > Folks working on IA64 stuff inside HP need to think about: > (a) if they want to do the merge any time soon > (b) which iosapic.c they want to start with > (c) where the final version should live > > thanks, > grant > > Grant Grundler > Unix Systems Enablement Lab > +1.408.447.7253 > > --------------------------------------------------------------------------- > To unsubscribe: send e-mail to parisc-linux-request@thepuffingroup.com with > `unsubscribe' as the subject. From jsm@udlkern.fc.hp.com Tue, 21 Nov 2000 23:50:03 -0700 (MST) Date: Tue, 21 Nov 2000 23:50:03 -0700 (MST) From: John Marvin jsm@udlkern.fc.hp.com Subject: [parisc-linux] CVS linux Vs. -test10 > Better to get our house in order before we patchbomb Linus, I think. > Renames are hard enough in CVS; renames in diff -u format are a real > stinker :-) In that case, we need to do some cleanup first. I've been lobbying for the removal of the almost empty arch/parisc/real directory, and its few remaining valid files moved to the kernel directory. There are also a fair number of dead files. Every file that is not currently involved in the build should be removed, unless a good case for it remaining can be made. If the reason to keep it is not a long term reason, then that file should not be sent to Linus (It sounds like it is a lot easier to add files rather than remove/rename them). If there are any files that are currently in use, but which we know will eventually be removed, perhaps we should consider what to do with that file (although I don't know of any files in this category at the moment). John Marvin jsm@fc.hp.com From grundler@cup.hp.com Tue, 21 Nov 2000 23:18:16 -0800 Date: Tue, 21 Nov 2000 23:18:16 -0800 From: Grant Grundler grundler@cup.hp.com Subject: [parisc-linux] CVS linux Vs. -test10 Ryan Bradetich wrote: > Do you really want to merget the ccio-rm-dma.c file into Linus's tree? > It is just a reference file used to construct the real ccio-dma.c file ... I > don't believe it is referenced anywhere. Hi Ryan, Yes I do. It is supposed to work for ccio+PCX-W platforms (eg C360). Keeping it arround will document the pro/con's of that approach and give folks who have time (and the right machine) something to experiment with instead of writing it from scratch. If someone finds an application it's good for (short transactions with low latency requirements perhaps), it's worth having around. It's not referenced because I didn't add a CONFIG_CCIO_RM_IOMMU flag or ccio_rm_init() call to drivers/gsc/gsc.c:gsc_init(). You are welcome add this CONFIG flag by hacking arch/parisc/config.in and defconfig. If you do, please add rules which only allow one or the other CONFIG_CCIO* option to be enabled. thanks, grant Grant Grundler Unix Systems Enablement Lab +1.408.447.7253 From Pirvulescu_Alexandru@telemobil.ro Wed, 22 Nov 2000 09:36:58 +0200 Date: Wed, 22 Nov 2000 09:36:58 +0200 From: Alexandru Pirvulescu Pirvulescu_Alexandru@telemobil.ro Subject: [parisc-linux] case LEDs I think that the heartbeat LED is software because it starts with the kernel boot and if the kernel stops the LED stops blinking too. Is better to implement a software monitoring tool because you have to watch the software for hanging. Alex PS. There is a function in the kernel source in linux/arch/parisc/kernel/process.c named machine_heartbeat(). Any connection with the heartbeat from the chassis? ----- Original Message ----- From: "Alex deVries" To: "Grant Grundler" Cc: "Alexandru Pirvulescu" ; Sent: Wednesday, November 22, 2000 4:27 AM Subject: Re: [parisc-linux] case LEDs > Grant Grundler wrote: > > Yes. > > I was already asked this weekend to dig up technical info on LED > > and soft power control. I guess this is my reminder to do that. :^) > > Isn't there a PDC call (pdc_chassis?) to do this? Or is the heartbeat > LED done by hardware? > > - Alex > > -- > Alex deVries, Principal Solutions Architect, The Puffins at Linuxcare > 613.562.2759 tel > alex@linuxcare.com, http://www.linuxcare.com/ > Linuxcare, Support for the revolution. > > From bvalkema@knowhowww.nl Wed, 22 Nov 2000 06:32:51 +0100 Date: Wed, 22 Nov 2000 06:32:51 +0100 From: Bas Valkema bvalkema@knowhowww.nl Subject: [parisc-linux] case LEDs Alex deVries wrote: > Grant Grundler wrote: > > Yes. > > I was already asked this weekend to dig up technical info on LED > > and soft power control. I guess this is my reminder to do that. :^) > > Isn't there a PDC call (pdc_chassis?) to do this? Or is the heartbeat > LED done by hardware? > > - Alex A couple of months ago, I asked the same question, got answer to look in the mkLinux sources. I did, and I think it was a register (outb(0xblabla);). Wrote a driver (and for WAX, got a Intel Flash 32 EISA running), can't release it now, because of some copyright issues... Bas From grundler@cup.hp.com Tue, 21 Nov 2000 23:56:35 -0800 Date: Tue, 21 Nov 2000 23:56:35 -0800 From: Grant Grundler grundler@cup.hp.com Subject: [parisc-linux] CVS linux Vs. -test10 John Marvin wrote: > In that case, we need to do some cleanup first. John, I want a task list which leads us to a submital to linus. That's why I listed the specific files I wanted moved. Can you come up with (or ask someone else to come up) with a list of files which meet your criteria? All of your criteria sounds reasonable to me. But I don't have a feel of which files meet your criteria. If someone makes the task list, I'm happy to help with items and verify the result works. thanks, grant From jsm@udlkern.fc.hp.com Wed, 22 Nov 2000 01:11:57 -0700 (MST) Date: Wed, 22 Nov 2000 01:11:57 -0700 (MST) From: John Marvin jsm@udlkern.fc.hp.com Subject: [parisc-linux] CVS linux Vs. -test10 > Ryan Bradetich wrote: > > Do you really want to merget the ccio-rm-dma.c file into Linus's tree? > > It is just a reference file used to construct the real ccio-dma.c file ... I > > don't believe it is referenced anywhere. > > Hi Ryan, > Yes I do. It is supposed to work for ccio+PCX-W platforms (eg C360). > Keeping it arround will document the pro/con's of that approach and > give folks who have time (and the right machine) something to experiment > with instead of writing it from scratch. If someone finds an application > it's good for (short transactions with low latency requirements perhaps), > it's worth having around. > > It's not referenced because I didn't add a CONFIG_CCIO_RM_IOMMU flag > or ccio_rm_init() call to drivers/gsc/gsc.c:gsc_init(). You are welcome > add this CONFIG flag by hacking arch/parisc/config.in and defconfig. > If you do, please add rules which only allow one or the other > CONFIG_CCIO* option to be enabled. > Well, personally i'd vote to get rid of it. It works for ONE machine only, and MAY have an advantage in some small case. But if we keep it, lets make sure that it is real clear that it should NOT be the default choice. It should be marked CONFIG_EXPERIMENTAL, and the text associated with it should clearly show that it works on a C360 only. If possible, it should also be made clear that ccio-dma.c works for C360, so people who have C360's don't think they have to choose ccio-rm-dma.c. Grant, I hope you are prepared to answer the parisc-linux mailing list questions this is going to generate once parisc-linux starts becoming more visible. Another FAQ entry perhaps? :-) John Marvin jsm@fc.hp.com From jsm@udlkern.fc.hp.com Wed, 22 Nov 2000 01:52:04 -0700 (MST) Date: Wed, 22 Nov 2000 01:52:04 -0700 (MST) From: John Marvin jsm@udlkern.fc.hp.com Subject: [parisc-linux] Use of the EI_OSABI field > > BTW, it's not too hard to check .note.ABI-tag. The linker arranges for a > PT_NOTE program header entry to point to it, and the section itself is > virtually guaranteed to be read in with the header as it's placed right > after the header along with .interp. I didn't say it was difficult, I said it was ugly. It means another parisc only change to the machine independent file fs/binfmt_elf.c, since the hook provided will not allow this check. Without a change, binfmt_elf.c won't be smart enough to differentiate a binary produced by Gnu binutils for HP-UX and a binary produced by Gnu binutils for Linux, so it will claim both, and then blow up later, rather than not claiming the HP-UX binary and allowing it to be claimed by an arch dependent binary handler further down the list. And binfmt_elf.c does NOT read the program headers in the same read, so another read would have to be done (the data should be found in in cache rather than going to disk for it). Since we now need both the program headers and a section header to determine whether or not we should claim the file AND binfmt_elf.c also wants to look at those headers after the file is claimed, a small redesign is probably in order (rather than re-reading the headers). I'm not sure whether or not Linus would buy that. So, I guess I'll pursue the interpreter field instead, since that is what sparc is doing (i.e. they have their own sparc only code in binfmt_elf.c). Since that will be an easier sell. I need to do more research here. I suspect that statically linked binaries are not going to allow this solution to work though. John Marvin jsm@fc.hp.com From alan@linuxcare.com.au Wed, 22 Nov 2000 23:28:45 +1100 (EST) Date: Wed, 22 Nov 2000 23:28:45 +1100 (EST) From: Alan Modra alan@linuxcare.com.au Subject: [parisc-linux] binutils update I've just committed a change to binutils that cures an ELF spec violation. We now no longer create plabels for DT_INIT and DT_FINI and instead rely on the dynamic linker to create them for us. This means you need an updated glibc, that I committed a little earlier today, to create the plabel function pointers if you update your binutils. You have been warned... Alan Modra -- Linuxcare. Support for the Revolution. From bruno_vidal@hpfrcu03.france.hp.com Wed, 22 Nov 2000 15:14:18 +0100 Date: Wed, 22 Nov 2000 15:14:18 +0100 From: Bruno Vidal bruno_vidal@hpfrcu03.france.hp.com Subject: [parisc-linux] Crash dump module Hi Good news, I've finished to recompile the entire chain on hpux 11.00 64bits. I've recompile my own kernel and booted a small 712/60. It work pretty well. Now I'm going to start the work about crash dump. So, In my mind, I'll start from the linux/kernel/panic.c function and I'll add a function dumpsys.c in the linux/arch/paric directory -> is it okay for you ? It will depend on the CONFIG_PARISC var (or do you prefer adding a CONFIG_DUMPSYS var ?) thanks. -- Vidal Bruno, (770-4271) SSD-HA Team, HP-UX & LINUX Support bruno_vidal@admin.france.hp.com From randolph@tausq.org Wed, 22 Nov 2000 07:44:24 -0700 Date: Wed, 22 Nov 2000 07:44:24 -0700 From: Randolph Chung randolph@tausq.org Subject: [parisc-linux] Crash dump module > It will depend on the CONFIG_PARISC var (or do you prefer adding a CONFIG_DUMPSYS var ?) I think there was a consensus to use __hppa__ instead of CONFIG_PARISC ... randolph -- @..@ http://www.TauSq.org/ (----) ( >__< ) ^^ ~~ ^^ From mike_clapper@hp.com Wed, 22 Nov 2000 07:54:24 -0800 Date: Wed, 22 Nov 2000 07:54:24 -0800 From: CLAPPER,MIKE (HP-USA,ex1) mike_clapper@hp.com Subject: [parisc-linux] B132L boot hang Hello Everyone, I download the cross-compilers and build a lifimage on Redhat 6.1. I set up nfsroot on a S712 running hpux 10.20. With this I am able to boot a B132L running pdc 6.1 - almost. I get a hang right after - VFS: Mounted root (nfs filesystem) readonly Warning: unable to open an initial console I have a 700/96 on serial port 1 as the console. I have hpux on a disc in the unit I'm trying to boot - from HPUX I have verified I can nfs mount the filesys I'm using for NFSROOT. With linux in this condition the machine will respond to ping. I will also react to a telnet - i get the telnet banner then "connection closed by foreign host". FTP gets "connection refused" - so it' partially alive..... Is there a way to keyword search the developers archive? I vaguely recall seeing the 'initial console' warning, but couldn't find it browsing the developers archive Thanks, Mike ********************************************** Mike Clapper North American Crisis Management Team Hewlett Packard (405) 948-4715 ********************************************** From bame@noam.fc.hp.com Wed, 22 Nov 2000 09:02:03 -0700 Date: Wed, 22 Nov 2000 09:02:03 -0700 From: Paul Bame bame@noam.fc.hp.com Subject: [parisc-linux] CVS linux Vs. -test10 = I've been lobbying for = the removal of the almost empty arch/parisc/real directory, and its few = remaining valid files moved to the kernel directory. Done. arch/parisc/real R.I.P. From grundler@cup.hp.com Wed, 22 Nov 2000 08:27:22 -0800 Date: Wed, 22 Nov 2000 08:27:22 -0800 From: Grant Grundler grundler@cup.hp.com Subject: [parisc-linux] Crash dump module Bruno Vidal wrote: > Hi > Good news, I've finished to recompile the entire chain on hpux 11.00 64bits. > I've recompile my own kernel and booted a small 712/60. It work pretty well. > Now I'm going to start the work about crash dump. So, In my mind, I'll start > from the linux/kernel/panic.c function and I'll add a function dumpsys.c > in the linux/arch/paric directory -> is it okay for you ? YES! > It will depend on the CONFIG_PARISC var > (or do you prefer adding a CONFIG_DUMPSYS var ?) As Randolph pointed out CONFIG_PARISC is deprecated. Use "ifdef __hppa__" for changes in *common* (ie not arch/parisc) files. They should not be needed for anything in arch/parisc or linux/include/asm-parisc. Adding a CONFIG_DUMPSYS is a good idea. Look in linux/arch/parisc/config.in, linux/arch/parisc/defconfig, and the various Makefiles for how CONFIG_* flags work. thanks Bruno! grant Grant Grundler Unix Systems Enablement Lab +1.408.447.7253 From grundler@cup.hp.com Wed, 22 Nov 2000 09:27:20 -0800 Date: Wed, 22 Nov 2000 09:27:20 -0800 From: Grant Grundler grundler@cup.hp.com Subject: [parisc-linux] B132L boot hang "CLAPPER,MIKE (HP-USA,ex1)" wrote: > > > Hello Everyone, > > I download the cross-compilers and build a lifimage on Redhat 6.1. I set > up nfsroot on a S712 running hpux 10.20. With this I am able to boot a > B132L running pdc 6.1 - > almost. I get a hang right after - > > VFS: Mounted root (nfs filesystem) readonly > Warning: unable to open an initial console I think I need more output. Based on ioscan output, the B132L has two serial ports: 8/16/4 - off of LASI 8/20/2 - of WAX (EISA Bus Adapter) (GSCtoPCI is at 8/0) I don't think the one off of WAX is supported right now. Are you using the default .config produced by "make oldconfig"? It's also possible the LASI support is broken on B132L and I would expect some console output indicating what's wrong. > I have a 700/96 on serial port 1 as the console. I have hpux on a disc in > the unit I'm trying to boot - from HPUX I have verified I can nfs mount the > filesys I'm using for NFSROOT. NFS root mounted fine. Console is the problem. ... > Is there a way to keyword search the developers archive? I vaguely recall > seeing the 'initial console' warning, but couldn't find it browsing the > developers archive Yes - http://puffin.external.hp.com/cgi-bin/mailgrep grant Grant Grundler Unix Systems Enablement Lab +1.408.447.7253 From cary@cup.hp.com Wed, 22 Nov 2000 10:06:05 -0800 Date: Wed, 22 Nov 2000 10:06:05 -0800 From: Cary Coutant cary@cup.hp.com Subject: [parisc-linux] Use of the EI_OSABI field As the original author of the proposal to add the EI_OSABI field to the ELF format, let me try to clarify the intent of this field. The authoritative definition of this field is found in SCO's gABI document, which is still the official specification for the ELF format (this is probably posted somewhere on SCO's web site). Here's what it says: Byte e_ident[EI_OSABI] identifies the operating system and ABI to which the object is targeted. Some fields in other ELF structures have flags and values that have operating system and/or ABI specific meanings; the interpretation of those fields is determined by the value of this byte. The value of this byte must be interpreted differently for each machine. That is, each value for the e_machine field determines a set of values for the EI_OSABI byte. Values are assigned by the ABI processor supplement for each machine. If the processor supplement does not specify a set of values, the value 0 shall be used and indicates unspecified. The first sentence is still a bit misleading, and is an artifact of the original proposal. Originally, the field was intended to identify the target ABI (hence the name of the field). As we started discussing a common Unix ABI for IA-64, however, it became clear that this field wouldn't serve that purpose, but it was still needed to identify the set of platform-specific ELF extensions that are used by the object file. There are a number of fields in the ELF format for which ranges of values or a set of flag bits are reserved for vendor-specific use (e.g., SHT_LOOS through SHT_HIOS for vendor-specific section types, and SHF_MASKOS for vendor-specific section attributes). If an object file uses any of these values or flag bits, the consumer of the file must consult the EI_OSABI field to determine what those values or flags mean. It works just like the e_machine field does for attaching meaning to processor-specific values and flags. The intent is that any ABI-conforming implementation will be able to execute an ABI-conforming binary, even if it uses certain vendor-specific features. In many cases, those vendor-specific features are hints for a particular OS that can be ignored by other implementations. Where this is not the case, and a vendor-specific feature must be understood by the system in order to process the file correctly, we have a couple of alternatives. For section types and flags that a linker must understand, we have the SHF_OS_NONCONFORMING flag -- if set, and a linker doesn't understand a particular section type or flag, it must reject the file. For executables that will execute only on a particular implementation, we must use an alternate interpreter (PT_INTERP) or bind to implementation-specific shared libraries. An ABI-conforming binary will use the interpreter specified in the psABI spec, and will use only system libraries specified there. For statically-bound programs, I'm afraid we don't have a clear solution. We took the general approach that such programs are not ABI-conforming in the first place, and can use any mechanism they might choose to verify that they are executing on the appropriate implementation. -cary From grundler@cup.hp.com Wed, 22 Nov 2000 11:55:38 -0800 Date: Wed, 22 Nov 2000 11:55:38 -0800 From: Grant Grundler grundler@cup.hp.com Subject: [parisc-linux] CVS linux Vs. -test10 John Marvin wrote: > Grant Grundler wrote: > > Yes I do. It is supposed to work for ccio+PCX-W platforms (eg C360). ... > Well, personally i'd vote to get rid of it. It works for ONE machine only, > and MAY have an advantage in some small case. And so does the OB600 mouse driver I rewrote/published. AFAIK, it only works on OB600s. I was originally thinking D/K/R-class boxes had PCX-W upgrades but AFAICT, they don't. > But if we keep it, lets make > sure that it is real clear that it should NOT be the default choice. > > It should be marked CONFIG_EXPERIMENTAL, and the text associated with it > should clearly show that it works on a C360 only. If possible, it should > also be made clear that ccio-dma.c works for C360, so people who have > C360's don't think they have to choose ccio-rm-dma.c. IIRC, Comments in the headers of both ccio files make those issues clear. I'm not sure where else that needs to be documented. > Grant, I hope you are prepared to answer the parisc-linux mailing list > questions this is going to generate once parisc-linux starts becoming more > visible. Another FAQ entry perhaps? :-) Ryan owns it. He's responsible for documenting it and adding FAQ questions. He can choose to delete ccio-rm-dma.c as well. :^) I think it'd be a waste to throw it away before someone figures out that it's really not useful - even if just for C360. thanks, grant From mike_clapper@hp.com Wed, 22 Nov 2000 12:05:23 -0800 Date: Wed, 22 Nov 2000 12:05:23 -0800 From: CLAPPER,MIKE (HP-USA,ex1) mike_clapper@hp.com Subject: [parisc-linux] B132L boot hang Thanks Grant, I verified the console is off 8/16/4.0 and that it is the LASI port. I also downloaded the newest cross-compiler and source code. After rebuilding the palo lifimage I get the same hang in the same place. Since I was cabled to a dumb terminal I was not able to capture the boot output. I will find the right cable to hook up to my pc so I can capture the output and send it to you - perhaps an error occurred earlier in the boot that I overlooked. Thanks for the help. Mike -----Original Message----- From: Grant Grundler [mailto:grundler@cup.hp.com] Sent: Wednesday, November 22, 2000 11:27 AM To: CLAPPER,MIKE (HP-USA,ex1) Cc: 'parisc-linux@thepuffingroup.com' Subject: Re: [parisc-linux] B132L boot hang "CLAPPER,MIKE (HP-USA,ex1)" wrote: > > > Hello Everyone, > > I download the cross-compilers and build a lifimage on Redhat 6.1. I set > up nfsroot on a S712 running hpux 10.20. With this I am able to boot a > B132L running pdc 6.1 - > almost. I get a hang right after - > > VFS: Mounted root (nfs filesystem) readonly > Warning: unable to open an initial console I think I need more output. Based on ioscan output, the B132L has two serial ports: 8/16/4 - off of LASI 8/20/2 - of WAX (EISA Bus Adapter) (GSCtoPCI is at 8/0) I don't think the one off of WAX is supported right now. Are you using the default .config produced by "make oldconfig"? It's also possible the LASI support is broken on B132L and I would expect some console output indicating what's wrong. > I have a 700/96 on serial port 1 as the console. I have hpux on a disc in > the unit I'm trying to boot - from HPUX I have verified I can nfs mount the > filesys I'm using for NFSROOT. NFS root mounted fine. Console is the problem. ... > Is there a way to keyword search the developers archive? I vaguely recall > seeing the 'initial console' warning, but couldn't find it browsing the > developers archive Yes - http://puffin.external.hp.com/cgi-bin/mailgrep grant Grant Grundler Unix Systems Enablement Lab +1.408.447.7253 --------------------------------------------------------------------------- To unsubscribe: send e-mail to parisc-linux-request@thepuffingroup.com with `unsubscribe' as the subject. From kirkb@chrome.rose.hp.com Wed, 22 Nov 2000 12:10:10 PST Date: Wed, 22 Nov 2000 12:10:10 PST From: Kirk Bresniker kirkb@chrome.rose.hp.com Subject: [parisc-linux] CVS linux Vs. -test10 Grant Grundler wrote: | I was originally thinking D/K/R-class boxes had PCX-W upgrades but | AFAICT, they don't. | The C-class upgrade to PCX-W was a one-off. Upgrades for similar enterprise servers were not designed. KMB -- +============================================================+ | Kirk Bresniker (916) 748-2393 | | 8000 Foothills Blvd | | Roseville, CA 95747-5649 | | kirkb@rose.hp.com | From grundler@cup.hp.com Wed, 22 Nov 2000 12:11:23 -0800 Date: Wed, 22 Nov 2000 12:11:23 -0800 From: Grant Grundler grundler@cup.hp.com Subject: [parisc-linux] CVS linux Vs. -test10 Grant Grundler wrote: ... > arch/parisc/kernel/ccio-dma.c -> drivers/gsc/ccio-dma.c > arch/parisc/kernel/ccio-rm-dma.c -> drivers/gsc/ccio-rm-dma.c > > ccio will *always* be associated with a GSC bus since that's > the secondary bus. And ccio supports devices below dino.c which > already lives in drivers/gsc. Ryan - moving/keeping these files is up to you. I was just sharing what I thought was "right". Apologies for not making that clear earlier. > arch/parisc/kernel/lba_pci.c -> drivers/ropes/lba_pci.c > arch/parisc/kernel/sba_iommu.c -> drivers/ropes/sba_iommu.c > arch/parisc/kernel/iosapic.c -> drivers/ropes/iosapic.c I've talked to one of the folks working on IA64-linux. They are interested in merging iosapic code but haven't even looked at the parisc version I wrote. We talked a bit about the issues and it doesn't sound like it's going to happen anytime soon. In any case, iosapic.c doesn't belong under "drivers/ropes". So none of this needs to move in the forseeable future. It can all stay in arch/parisc/kernel. grant Grant Grundler Unix Systems Enablement Lab +1.408.447.7253 From deller@gmx.de Wed, 22 Nov 2000 21:43:40 +0100 Date: Wed, 22 Nov 2000 21:43:40 +0100 From: Helge Deller deller@gmx.de Subject: [parisc-linux] B132L boot hang > I think I need more output. Based on ioscan output, the B132L > has two serial ports: > 8/16/4 - off of LASI > 8/20/2 - of WAX (EISA Bus Adapter) > > (GSCtoPCI is at 8/0) > > I don't think the one off of WAX is supported right now. It should be detected & supported (at least it is on my B160L). But it is not used as initial console since it normally gets assigned as ttyS1 while LASI-serial gets ttyS0. Greetings, Helge. From bame@noam.fc.hp.com Wed, 22 Nov 2000 16:03:12 -0700 Date: Wed, 22 Nov 2000 16:03:12 -0700 From: Paul Bame bame@noam.fc.hp.com Subject: [parisc-linux] 64-bit progress 32-bit syscalls on 64-bit kernel are to the point where a few things work, and signals appear to be working (I didn't implement *all* the signal-related syscalls yet). I'll be continuing to produce syscall wrappers for a while... If you try to boot the standard NFS root with wide kernel, you'll want to mv sbin/init sbin/init-real then compile and install this program as sbin/init: int main() { char *argv[2]; argv[0] = "/sbin/init-real"; argv[1] = 0; execv(argv[0], argv); } I never felt comfortable I found the point where sys_execve figures out it needs to pack the argv vector differently for narrow user apps (locally I also am using PER_LINUX32 in binfmt_elf32.c) which causes the initial exec(/sbin/init) to be passed incomprehensible arguments. This program is a little temporary workaround. -Paul Bame From alan@linuxcare.com.au Thu, 23 Nov 2000 11:18:20 +1100 (EST) Date: Thu, 23 Nov 2000 11:18:20 +1100 (EST) From: Alan Modra alan@linuxcare.com.au Subject: glibc On Wed, 22 Nov 2000, Matt Taggart wrote: > Hi Alan, > > First a timezone question... your mail headers have you in +11 and Ft. Collins > is -7 so you're 6 hours behind + 1 day relative to us? So as I send this it's > 14:05 here and 8:05 there? Hi Matt, I'm actually on +10:30 in Adelaide, but posting from a Linuxcare machine in Canberra which is on +11. >[snip segfaults] > I am building native using dhd's binutils/gcc/glibc debs, using source checked > out just after the glibc 2.2 merge. Do you think the merge / ld.so changes you > just made would help this problem at all? Quite likely. This fix * sysdeps/hppa/dl-machine.h (ELF_MACHINE_START_ADDRESS): Define. is fairly crucial, as without it %dp will not be set correctly. I should have mentioned this when posting to the list about the binutils change. Oh, and as of this email, I haven't actually run anything linked to the new glibc. A little remiss, I know, but I've been deep in the gdb port, and if I spend time tinkering with glibc, binutils and gcc (which I like), gdb (which I don't like) will never be finished. ;-) Alan -- Linuxcare. Support for the Revolution. From grundler@cup.hp.com Wed, 22 Nov 2000 18:24:52 -0800 (PST) Date: Wed, 22 Nov 2000 18:24:52 -0800 (PST) From: Grant Grundler grundler@cup.hp.com Subject: [parisc-linux] new SBA IOMMU version committed Hi all, I've committed my "second generation" I/O MMU code for C3K/J5k boxes. It's only tested for 32-bit. I'll be testing 64-bit shortly. This code makes "perfect" use of the I/O pdir resource map and we shouldn't see any panics due to out_of_resource. grant From grundler@cup.hp.com Wed, 22 Nov 2000 18:47:06 -0800 (PST) Date: Wed, 22 Nov 2000 18:47:06 -0800 (PST) From: Grant Grundler grundler@cup.hp.com Subject: [parisc-linux] CONFIG_DMB_TRAP diff Hello again (last one until Monday - I promise), With Lamont's wisdom, I implemented support for Date Memory Break trap. This enables the kernel programmer to capture the evil code which stomps on other people's "private" data. Only works for stores through virtual addresses. gsc_writeX() and DMA will still bypass this mechanism. pb, dhd, (or some equivalent deity), could you review/commit this code? Or tell me it's ok to commit? I've touched: arch/parisc/config.in arch/parisc/kernel/entry.S arch/parisc/mm/kmap.c include/asm-parisc/pgtable.h thanks, grant Index: arch/parisc/config.in =================================================================== RCS file: /home/cvs/parisc/linux/arch/parisc/config.in,v retrieving revision 1.25 diff -u -p -r1.25 config.in --- config.in 2000/10/20 18:28:26 1.25 +++ config.in 2000/11/23 02:18:23 @@ -16,8 +16,12 @@ endmenu mainmenu_option next_comment comment 'General options' -# bool 'Symmetric multi-processing support' CONFIG_SMP -define_bool CONFIG_SMP n +bool 'Symmetric multi-processing support' CONFIG_SMP +# define_bool CONFIG_SMP n + +# One needs to tweak dmb_trap_11 code in entry.S to match. +# Not tested for 64-bit kernel. +bool 'Debug support for Data Memory Break Trap' CONFIG_DMB_TRAP bool 'Kernel Debugger support' CONFIG_KWDB # define_bool CONFIG_KWDB n Index: arch/parisc/kernel/entry.S =================================================================== RCS file: /home/cvs/parisc/linux/arch/parisc/kernel/entry.S,v retrieving revision 1.53 diff -u -p -r1.53 entry.S --- entry.S 2000/11/22 16:51:33 1.53 +++ entry.S 2000/11/23 02:18:23 @@ -23,6 +23,7 @@ */ #include +#include /* the following is the setup i think we should follow: * whenever the CPU is interruptible, the following has to be true: @@ -349,7 +350,39 @@ .endm #endif +#ifdef CONFIG_DMB_TRAP /* + ** Data Memory Bit trap interruption handler (parisc 1.1) + ** + ** This is a debugging aid. Use it when you think someone else + ** is stepping on your memory. It only catches *virtual* + ** accesses. gsc_writeX() functions disable virtual translation + ** (D-bit) and will happily scribble whatever physical address + ** is passed in. + ** + ** Here's how to use it: + ** 1) Call iterate_pages() from your init routine like this: + ** iterate_pages( my_private_mem, private_mem_size, + ** set_data_memory_break, 0); + ** 2) substitute your functions for your_function1 (or 2) in + ** dmb_trap_11 code below. + ** + ** Thanks to Lamont Jones for telling me how to do this. + ** - ggg 1/22/2000 + */ + .macro dmb_11 code + + mfctl %isr,spc + b dmb_trap_11 + mfctl %ior,va + + .align 32 + .endm +#else +#define dmb_11 def +#endif + + /* * dirty bit trap interruption handler (parisc 2.0) */ @@ -448,7 +481,7 @@ fault_vector_11: naitlb_11 16 nadtlb_11 17 def 18 - def 19 + dmb_11 19 dbit_11 20 def 21 def 22 @@ -467,7 +500,6 @@ fault_vector_11: .import handle_interruption,code .import handle_real_interruption,code .import do_irq_mask,code - .import parisc_stopkernel,code .import cpu_irq_region,data /* @@ -903,11 +935,15 @@ dtlb_miss_11: dep pte,8,7,prot extru,= pte,_PAGE_NO_CACHE_BIT,1,r0 - depi 1,12,1,prot + depi 1,12,1,prot /* U-bit */ extru,= pte,_PAGE_USER_BIT,1,r0 depi 7,11,3,prot /* Set for user space (1 rsvd for read) */ extru,= pte,_PAGE_GATEWAY_BIT,1,r0 depi 0,11,2,prot /* If Gateway, Set PL2 to 0 */ +#ifdef CONFIG_DMB_TRAP + extru,= pte,_PAGE_DMB_BIT,1,r0 + depi 1,4,1,prot /* B-bit */ +#endif /* Get rid of prot bits and convert to page addr for idtlba */ @@ -1300,6 +1336,30 @@ dbit_trap_11: rfir nop + +#ifdef CONFIG_DMB_TRAP + .import your_function1,code + .import your_function2,code + +dmb_trap_11: + mfctl pcsq,t0 /* get space */ + comb,<>,n t0,%r0,dmb_rfi /* not kernel - bail */ + + mfctl pcoq,t0 /* get offset */ + ldil L%dmb_ok_function1, t1 + dep %r0, 31, 12, t0 + comb,=,n t0,t1,dmb_rfi /* it's ours - bail */ + + ldil L%dmb_ok_function2, t1 + comb,<>,n t0,t1,intr_save /* not ours - panic */ + +dmb_rfi: + mfctl ipsw,t0 /* Set PSW X-bit - just continue */ + depi 1,11,1,t0 /* Set X-bit */ + mtctl t0, ipsw + rfir + nop +#endif dbit_trap_20: mfctl %cr25,ptp /* Assume user space trap */ Index: arch/parisc/mm/kmap.c =================================================================== RCS file: /home/cvs/parisc/linux/arch/parisc/mm/kmap.c,v retrieving revision 1.3 diff -u -p -r1.3 kmap.c --- kmap.c 2000/05/05 18:05:47 1.3 +++ kmap.c 2000/11/23 02:18:23 @@ -43,7 +43,16 @@ static void unmap_cached_pte(pte_t * pte } #endif +#ifdef CONFIG_DMB_TRAP /* These two routines should probably check a few things... */ +void set_data_memory_break(pte_t * pte, unsigned long arg) +{ + pte_val(*pte) |= _PAGE_DMB; +} + +#endif + +/* These two routines should probably check a few things... */ static void set_uncached(pte_t * pte, unsigned long arg) { pte_val(*pte) |= _PAGE_NO_CACHE; @@ -106,7 +115,10 @@ static inline void iterate_pmd(pgd_t * d } while (address < end); } -static void iterate_pages(unsigned long address, unsigned long size, +#ifndef CONFIG_DMB_TRAP +static +#endif +void iterate_pages(unsigned long address, unsigned long size, pte_iterator_t op, unsigned long arg) { pgd_t *dir; Index: include/asm-parisc/pgtable.h =================================================================== RCS file: /home/cvs/parisc/linux/include/asm-parisc/pgtable.h,v retrieving revision 1.29 diff -u -p -r1.29 pgtable.h --- pgtable.h 2000/11/10 21:44:44 1.29 +++ pgtable.h 2000/11/23 02:18:23 @@ -109,6 +109,10 @@ extern void *vmalloc_start; #define _PAGE_USER 0x400 /* Software: User accessable page */ #define _PAGE_USER_BIT 21 /* Needs to agree with _PAGE_USER above */ /* 0x800 still available */ +#ifdef CONFIG_DMB_TRAP +#define _PAGE_DMB 0x800 /* Data Memory Break Trap */ +#define _PAGE_DMB_BIT 20 /* Data Memory Break Trap */ +#endif #ifdef __ASSEMBLY__ #define _PGB_(x) (1 << (63 - (x))) From jsm@udlkern.fc.hp.com Wed, 22 Nov 2000 22:50:14 -0700 (MST) Date: Wed, 22 Nov 2000 22:50:14 -0700 (MST) From: John Marvin jsm@udlkern.fc.hp.com Subject: [parisc-linux] CONFIG_DMB_TRAP diff > > Hello again (last one until Monday - I promise), > > With Lamont's wisdom, I implemented support for Date Memory Break trap. > > This enables the kernel programmer to capture the evil code which > stomps on other people's "private" data. Only works for stores > through virtual addresses. gsc_writeX() and DMA will still > bypass this mechanism. > > pb, dhd, (or some equivalent deity), could you review/commit this code? > Or tell me it's ok to commit? > > I've touched: > arch/parisc/config.in > arch/parisc/kernel/entry.S > arch/parisc/mm/kmap.c > include/asm-parisc/pgtable.h > Please don't. This solution is way more complicated than it should be. Here are the problems with it: 1) As I had already mentioned in a previous discussion, the pte's already reserve the location for the B bit (data memory break trap) and the dtlb miss handlers already move the entire group of bits that include this bit in one operation. So no change is necessary to the dtlb miss handlers to specially set that bit and incur extra instructions in the tlb miss handlers, and no extra bits need to be allocated in the pte. Instead of adding a new definition (e.g. 0x800, which is our last available bit) use the one that is already reserved for it: 0x010. 2) There is no reason to add a special data memory break trap handler. The general trap handler is more than sufficient for this case. handle_interruption will be called if a data memory break trap is encountered. Just add a new case for the list of traps, and handle the trap in C. You can set the X bit by simply setting it in the saved ipsw (in gr[0]) and it will be set upon return from the trap, no muss, no fuss. Note that the above also applies for the page reference trap. The T bit is also already supported (0x040 in the pte) by the dtlb miss handlers. Note that the reason I reserved these bits is because it would actually take MORE code in the dtlb miss handlers to NOT support those bits and use them for something else. Another helpful hint for those wanting to use this feature. If you are tracking corruptions that span multiple pages, then just setting the B bit on each page may be all you need. But, when I've used the data memory break trap for corruption tracking, typically I've wanted to track a corruption that was happening to a particular variable, i.e. a 4 byte quantity, and lots of other variables were being legitimately written on the same page, so you wind up with thousands of data memory break traps, where only one may be the one that is corrupting the location you are interested in. But, all is not lost, the solution is still fairly simple. The data memory break trap provides a valid iir, isr and ior. So once you get the trap, a custom data memory break handler (which can be written with a few lines of C in handle_interruption), simply uses iir, isr and ior to check if the access was to the specific byte or bytes you are interested in. I've simply used isr/ior to check for writes within the word I was interested in. That may be enough for most cases. The information you are missing from isr/ior is the size of the write transaction. To get this you would need to parse the instruction stored in iir (code to determine the size of a store from the instruction in the iir will be necessary when an unaligned fault handler is written). John Marvin jsm@fc.hp.com From jsm@udlkern.fc.hp.com Thu, 23 Nov 2000 01:29:55 -0700 (MST) Date: Thu, 23 Nov 2000 01:29:55 -0700 (MST) From: John Marvin jsm@udlkern.fc.hp.com Subject: [parisc-linux] CONFIG_DMB_TRAP diff Alan Modra wrote: > > gdb will eventually want to use this trap too. > Cool! However, data memory break traps for user translations are a little tougher. There are some small modifications in the machine dependent code that I can make to make sure the B bit stays set during most VM operations on a page. However, since the machine independent part of the VM system doesn't know anything about this bit (nor should it), it won't be preserved if the page is paged out (and subsequently paged back in). This could be fixed fairly easily with some changes to the machine independent code, but I don't think that would be appropriate. Some potential solutions (each has its problems): 1) Just document the fact that the feature may not work on systems with low memory. It's a parisc only feature, so perhaps we could live with that. 2) Lock the page in memory (using the mlock interface) when we set the B bit on a page. Just some thoughts on the subject. John Marvin jsm@fc.hp.com From pjlahaie@linuxcare.com Fri, 24 Nov 2000 16:56:16 -0500 Date: Fri, 24 Nov 2000 16:56:16 -0500 From: Paul J.Y. Lahaie pjlahaie@linuxcare.com Subject: [parisc-linux] boot-floppies dependancies --GRPZ8SYKNexpdSJ7 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline I would like to know if anyone has built any of the following packages that are needed for the boot-floppies. Currently, the missing deps are: cspsfonts man-db tetex-bin recode cslatex libpaperg tetex-extra libnewt-dev libgd1g-dev gawk libi18n-langtags-perl dpkg-awk debiandoc-sgml I'm currently trying to get a working apt, since the one of pehc and the .iso seem to be broken (no xfer methods). I'll let everyone know when a working copy will be available. - Paul --GRPZ8SYKNexpdSJ7 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.4 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE6HuP/8ggPQthPCzcRAnyKAJ0fyraVXEvlI0yQLsli7FlnUUAPdwCfSyv/ YgAxOcVMDgWfHBc7lneuc1Y= =tScM -----END PGP SIGNATURE----- --GRPZ8SYKNexpdSJ7-- From doneill@linuxcare.com Fri, 24 Nov 2000 17:01:00 -0500 (EST) Date: Fri, 24 Nov 2000 17:01:00 -0500 (EST) From: Dave O'Neill doneill@linuxcare.com Subject: [parisc-linux] strace? So, I've heard rumours that somewhere there's a working strace for parisc.... Can anyone point me in the right direction? Dave -- Dave O'Neill, Senior Linux Consultant, Linuxcare, Inc. desk: (613) 562-9949 fax: (613) 562-9700 cell: (613) 223-0219 doneill@linuxcare.com http://www.linuxcare.com/ From obrien@FreeBSD.org Sat, 25 Nov 2000 12:22:11 -0800 Date: Sat, 25 Nov 2000 12:22:11 -0800 From: David O'Brien obrien@FreeBSD.org Subject: [parisc-linux] Use of the EI_OSABI field On Tue, Nov 21, 2000 at 03:27:19PM -0800, Ulrich Drepper wrote: > Alan Modra writes: > > > Ulrich Drepper also was quite vehement against changing sourceware > > FreeBSD binutils. > > I've never said anything about any *BSD, why should I? The *BSD > people wanted to change the Linux binutils. No (don't put words in my mouth Ulrich as you'll be wrong 99% of the time). I wanted the Sourceware Binutils to set the EI_OSABI to "ELFOSABI_LINUX" when targeting Linux. -- -- David (obrien@FreeBSD.org) From obrien@FreeBSD.org Sat, 25 Nov 2000 12:28:40 -0800 Date: Sat, 25 Nov 2000 12:28:40 -0800 From: David O'Brien obrien@FreeBSD.org Subject: [parisc-linux] Use of the EI_OSABI field On Tue, Nov 21, 2000 at 07:11:29PM -0800, H . J . Lu wrote: > When I was at the IA64 ABI meeting yesterday, we were looking at the > EI_OSABI issue. Everyone at the IA64 ABI meeting agreed that what > Ulrich and I had said was the correct understanding. > > "The e_ident[EI_OSABI] value identifies the operating system and ABI > to which the object is targeted" just means if the e_ident[EI_OSABI] Then is this *extremely* misleading text going to be changed??? "the operating system and" needs to be deleted in the _official_ _published_ specification. -- -- David (obrien@FreeBSD.org) From obrien@FreeBSD.org Sat, 25 Nov 2000 12:31:08 -0800 Date: Sat, 25 Nov 2000 12:31:08 -0800 From: David O'Brien obrien@FreeBSD.org Subject: [parisc-linux] Use of the EI_OSABI field On Tue, Nov 21, 2000 at 07:18:21PM -0800, Ulrich Drepper wrote: > Alan Modra writes: > > "The e_ident[EI_OSABI] value identifies the operating system and ABI to > > which the object is targeted" > > > > Granted, this is only in a processor specific ABI, but it does flatly > > contradict your assertions that the purpose of EI_OSABI is to flag the > > presense of ELF extensions. > > The meaning of the field changed over time. Or better said, some > people initially understood it differently. Then lets get the _official_ wording changed. Obviously my interpretation wasn't unreasonable. And the world does not need to have you as a premadona keeper of the [unwritten] rules of the land. -- -- David (obrien@FreeBSD.org) From hjl@valinux.com Sat, 25 Nov 2000 12:33:40 -0800 Date: Sat, 25 Nov 2000 12:33:40 -0800 From: H . J . Lu hjl@valinux.com Subject: [parisc-linux] Use of the EI_OSABI field On Sat, Nov 25, 2000 at 12:28:40PM -0800, David O'Brien wrote: > On Tue, Nov 21, 2000 at 07:11:29PM -0800, H . J . Lu wrote: > > When I was at the IA64 ABI meeting yesterday, we were looking at the > > EI_OSABI issue. Everyone at the IA64 ABI meeting agreed that what > > Ulrich and I had said was the correct understanding. > > > > "The e_ident[EI_OSABI] value identifies the operating system and ABI > > to which the object is targeted" just means if the e_ident[EI_OSABI] > > > Then is this *extremely* misleading text going to be changed??? > "the operating system and" needs to be deleted in the _official_ > _published_ specification. > I will bring this issue up to ia64 psABI and gABI. -- H.J. Lu (hjl@valinux.com) From alan@lxorguk.ukuu.org.uk Sat, 25 Nov 2000 20:57:05 +0000 (GMT) Date: Sat, 25 Nov 2000 20:57:05 +0000 (GMT) From: Alan Cox alan@lxorguk.ukuu.org.uk Subject: [parisc-linux] RPM and hppa I've uploaded my first block of RPM packages to ftp.linux.org.uk/pub/linux/alan/HPPA along with a tar ball of built RPM tools for anyone who wants to play. In doing so I've hit a few problems with the 0.5 iso (no suprises there since its not actually meant to work reliably) - g++ explodes trying to build groff after allocating about 400Mb of RAM. Building -O0 works - the configure script for procmail tries to find the largest argument set that works (by searching). It crashes the kernel in doing so 8) - ldd is causing page faults in ld.so (kernel logged ones) and dying with segv. Fortunately it outputs the library list first - The linker appears to have a problem when resolving symbols between three shared objects while doing a shared object link. [Example is rpm: rpmlib is linked dynamically with -ldb3 -ldb The linker emits messages about symbols being static and should be built -fPIC. If you dump the libraries they are -fPIC. It looks as if its resolving a symbol between two shared libraries and making a static resolution that then blows up when the third library gets involved ] - The kernel shows occasional page cache corruption. This actually is quite possibly generic test6 bugs On the whole the toolset is working remarkably well. I've built over 100 source package sets so far including things like ncurses and most stuff just builds or hits portability problems (eg gmp wants to use HP format asm, zlib wants to be a non PIC library for performance but the HP tools dont allow it) Alan From alan@linuxcare.com.au Sun, 26 Nov 2000 23:01:50 +1100 (EST) Date: Sun, 26 Nov 2000 23:01:50 +1100 (EST) From: Alan Modra alan@linuxcare.com.au Subject: [parisc-linux] RPM and hppa On Sat, 25 Nov 2000, Alan Cox wrote: > - g++ explodes trying to build groff after allocating about 400Mb of RAM. > Building -O0 works Yeah, this is a known issue. I see on the gcc list that rth and others have been working on gcc fixes recently that should address the problem. I don't have the time/ability to fix it myself. > - the configure script for procmail tries to find the largest argument set > that works (by searching). It crashes the kernel in doing so 8) > > - ldd is causing page faults in ld.so (kernel logged ones) and dying with > segv. Fortunately it outputs the library list first How old are your glibc and binutils? I made some changes late October that should have fixed this problem. See http://puffin.external.hp.com/mailing-lists/parisc-linux/2000/10-Oct/0146.html Does "readelf -d" on your hppa-linux ld.so show you have a DT_TEXTREL tag? > - The linker appears to have a problem when resolving symbols between three > shared objects while doing a shared object link. > > [Example is rpm: > > rpmlib is linked dynamically with -ldb3 -ldb > > The linker emits messages about symbols being static and should be > built -fPIC. If you dump the libraries they are -fPIC. > > It looks as if its resolving a symbol between two shared libraries > and making a static resolution that then blows up when the third > library gets involved > > ] Could you put all the objects involved in the link up for ftp somewhere? I've just built rpm-2.5.6 without seeing this problem, but I'm sure my setup is different to yours... Regards, Alan Modra -- Linuxcare. Support for the Revolution. From alan@lxorguk.ukuu.org.uk Sun, 26 Nov 2000 12:12:21 +0000 (GMT) Date: Sun, 26 Nov 2000 12:12:21 +0000 (GMT) From: Alan Cox alan@lxorguk.ukuu.org.uk Subject: [parisc-linux] RPM and hppa > How old are your glibc and binutils? I made some changes late October From the 0.5 cdrom > http://puffin.external.hp.com/mailing-lists/parisc-linux/2000/10-Oct/0146.html > Does "readelf -d" on your hppa-linux ld.so show you have a DT_TEXTREL tag? Nope > Could you put all the objects involved in the link up for ftp > somewhere? I've just built rpm-2.5.6 without seeing this problem, but I'm > sure my setup is different to yours... rpm 4.0. rpm2 doesnt do that 3 way link with db and db3. I'll put them up when I get a bit of time From dave@hiauly1.hia.nrc.ca Sun, 26 Nov 2000 11:45:08 -0500 (EST) Date: Sun, 26 Nov 2000 11:45:08 -0500 (EST) From: John David Anglin dave@hiauly1.hia.nrc.ca Subject: [parisc-linux] RPM and hppa > On Sat, 25 Nov 2000, Alan Cox wrote: > > > - g++ explodes trying to build groff after allocating about 400Mb of RAM. > > Building -O0 works > > Yeah, this is a known issue. I see on the gcc list that rth and others > have been working on gcc fixes recently that should address the problem. > I don't have the time/ability to fix it myself. I think the above is a different problem. The explosion is most likely a problem with exception edges in the gcse pass. Try `-fno-gcse'. This also appears in the tFile.cc libio test. The pa port uses sjlj exceptions via __builtin_setjmp/longjmp. A nonlocal goto label is used for the target of the longjmp. The flow analysis assumes that an "exception" could jump to any label in the procedure rather than just the label associated with the exception region. Dave -- J. David Anglin dave.anglin@nrc.ca National Research Council of Canada (613) 990-0752 (FAX: 952-6605) From cwalthall@cwalthall.com Sun, 26 Nov 2000 11:45:38 -0600 Date: Sun, 26 Nov 2000 11:45:38 -0600 From: Carl & Delores Walthall cwalthall@cwalthall.com Subject: [parisc-linux] RPM and hppa Does anyone know where I can find the operating system for the HP9000 J200 Server? Thanks Carl Walthall ----- Original Message ----- From: "Alan Modra" To: "Alan Cox" Cc: Sent: Sunday, November 26, 2000 6:01 AM Subject: Re: [parisc-linux] RPM and hppa > On Sat, 25 Nov 2000, Alan Cox wrote: > > > - g++ explodes trying to build groff after allocating about 400Mb of RAM. > > Building -O0 works > > Yeah, this is a known issue. I see on the gcc list that rth and others > have been working on gcc fixes recently that should address the problem. > I don't have the time/ability to fix it myself. > > > - the configure script for procmail tries to find the largest argument set > > that works (by searching). It crashes the kernel in doing so 8) > > > > - ldd is causing page faults in ld.so (kernel logged ones) and dying with > > segv. Fortunately it outputs the library list first > > How old are your glibc and binutils? I made some changes late October > that should have fixed this problem. See > http://puffin.external.hp.com/mailing-lists/parisc-linux/2000/10-Oct/0146.ht ml > Does "readelf -d" on your hppa-linux ld.so show you have a DT_TEXTREL tag? > > > - The linker appears to have a problem when resolving symbols between three > > shared objects while doing a shared object link. > > > > [Example is rpm: > > > > rpmlib is linked dynamically with -ldb3 -ldb > > > > The linker emits messages about symbols being static and should be > > built -fPIC. If you dump the libraries they are -fPIC. > > > > It looks as if its resolving a symbol between two shared libraries > > and making a static resolution that then blows up when the third > > library gets involved > > > > ] > > Could you put all the objects involved in the link up for ftp > somewhere? I've just built rpm-2.5.6 without seeing this problem, but I'm > sure my setup is different to yours... > > Regards, Alan Modra > -- > Linuxcare. Support for the Revolution. > > > -------------------------------------------------------------------------- - > To unsubscribe: send e-mail to parisc-linux-request@thepuffingroup.com with > `unsubscribe' as the subject. > From cwalthall@cwalthall.com Sun, 26 Nov 2000 11:47:24 -0600 Date: Sun, 26 Nov 2000 11:47:24 -0600 From: Carl & Delores Walthall cwalthall@cwalthall.com Subject: [parisc-linux] RPM and hppa Hi All I have a HP9000 J200 server and would like to find the operating system software for it. Can you tell me where to look on the internet or who I may call? The server has a OS installed but no one can remember the user or password information. So they gave it to me to take home, is there a way to boot it on a floppy and change this information? Thanks for any information you can give me! Carl walthall ----- Original Message ----- From: "John David Anglin" To: "Alan Modra" Cc: ; Sent: Sunday, November 26, 2000 10:45 AM Subject: Re: [parisc-linux] RPM and hppa > > On Sat, 25 Nov 2000, Alan Cox wrote: > > > > > - g++ explodes trying to build groff after allocating about 400Mb of RAM. > > > Building -O0 works > > > > Yeah, this is a known issue. I see on the gcc list that rth and others > > have been working on gcc fixes recently that should address the problem. > > I don't have the time/ability to fix it myself. > > I think the above is a different problem. The explosion is most likely > a problem with exception edges in the gcse pass. Try `-fno-gcse'. This > also appears in the tFile.cc libio test. > > The pa port uses sjlj exceptions via __builtin_setjmp/longjmp. A > nonlocal goto label is used for the target of the longjmp. The flow > analysis assumes that an "exception" could jump to any label in the > procedure rather than just the label associated with the exception > region. > > Dave > -- > J. David Anglin dave.anglin@nrc.ca > National Research Council of Canada (613) 990-0752 (FAX: 952-6605) > > -------------------------------------------------------------------------- - > To unsubscribe: send e-mail to parisc-linux-request@thepuffingroup.com with > `unsubscribe' as the subject. > From alan@lxorguk.ukuu.org.uk Sun, 26 Nov 2000 22:47:43 +0000 (GMT) Date: Sun, 26 Nov 2000 22:47:43 +0000 (GMT) From: Alan Cox alan@lxorguk.ukuu.org.uk Subject: [parisc-linux] Linker failure with db1 I replaced the libdb1 on the ISO with one built using the toolchain on the ISO and all is now happy. From grundler@cup.hp.com Sun, 26 Nov 2000 19:11:41 -0800 Date: Sun, 26 Nov 2000 19:11:41 -0800 From: Grant Grundler grundler@cup.hp.com Subject: [parisc-linux] RPM and hppa "Carl & Delores Walthall" wrote: > Hi All > > I have a HP9000 J200 server and would like to find the operating system > software for it. Can you tell me where to look on the internet or who I may > call? Carl, The short answer is a port of linux to the J200 is in progress. See http://www.parisc-linux.org/ for status. If you have more questions read the FAQ and check the mailing list archives using http://puffin.external.hp.com/cgi-bin/mailgrep first please. > The server has a OS installed but no one can remember the user or password > information. So they gave it to me to take home, is there a way to boot > it on a floppy and change this information? Here's how to "fix" this: During power up/boot press key to get "BOOT ADMIN>" prompt. type "bo pri isl". At "ISL>" prompt, type "hpux -is". HPUX should boot to single user. use "mountall" or "mount -a" to mount all file systems. Then you can "vi /etc/passwd" or "passwd root". If that doesn't work and you can afford to loan the box out for a 3-4 monthes, you might ask if someone could install parisc-linux on it for you in exchange for a few monthes use. grant Grant Grundler Unix Systems Enablement Lab +1.408.447.7253 From grundler@cup.hp.com Sun, 26 Nov 2000 22:12:10 -0800 Date: Sun, 26 Nov 2000 22:12:10 -0800 From: Grant Grundler grundler@cup.hp.com Subject: [parisc-linux] case LEDs Alex deVries wrote: > Grant Grundler wrote: > > I was already asked this weekend to dig up technical info on LED > > and soft power control. I guess this is my reminder to do that. :^) I dug up the info but it's not in a form I'm willing to publishing. However, someone did volunteer to look at this and I've provided them with this info. So it will make into our CVS source tree and get published that way. > Isn't there a PDC call (pdc_chassis?) to do this? Not AFAICT. PDC_CHASSIS is documented in the pdc32.pdf found on http://www.parisc-linux.org/documentation.html But my gut feeling is parisc specific code could make some PDC_CHASSIS calls to set up "sysstat" field (eg initialize, shutdown, run states). Does anyone know if the chassis codes used by HPUX are published? It would be cool if parisc-linux used the same codes where possible... > Or is the heartbeat LED done by hardware? Code I've looked at before seems to all do it in software. grant Grant Grundler Unix Systems Enablement Lab +1.408.447.7253 From sanjak@tipas.lt Mon, 27 Nov 2000 09:09:22 +0200 Date: Mon, 27 Nov 2000 09:09:22 +0200 From: Aleksandr Konstantinov sanjak@tipas.lt Subject: [parisc-linux] how to boot ? Hello, All. We have two HP Workstations here (Model 735). I would like to try linux on one of them. But I have no disk space to install all the stuff (binutils, compiler, etc) . I found precompiled kernel on puffin.external.hp.com but it looks like I also need palo . Does anybody know, where to get precompiled palo for hpux9, hpux10 or linux-x86 ? Thanks in advance. A.K. From rhirst@linuxcare.com Mon, 27 Nov 2000 09:18:21 +0000 Date: Mon, 27 Nov 2000 09:18:21 +0000 From: Richard Hirst rhirst@linuxcare.com Subject: [parisc-linux] strace? Hi Dave, The source is in cvs on pehc; I can supply a binary if you want one. I havn't made serious use of it, but it does basically work. Richard On Fri, Nov 24, 2000 at 05:01:00PM -0500, Dave O'Neill wrote: > > So, I've heard rumours that somewhere there's a working strace for > parisc.... Can anyone point me in the right direction? > > Dave > -- > Dave O'Neill, Senior Linux Consultant, Linuxcare, Inc. > desk: (613) 562-9949 fax: (613) 562-9700 cell: (613) 223-0219 > doneill@linuxcare.com http://www.linuxcare.com/ > > --------------------------------------------------------------------------- > To unsubscribe: send e-mail to parisc-linux-request@thepuffingroup.com with > `unsubscribe' as the subject. > > From alan@lxorguk.ukuu.org.uk Mon, 27 Nov 2000 16:55:36 +0000 (GMT) Date: Mon, 27 Nov 2000 16:55:36 +0000 (GMT) From: Alan Cox alan@lxorguk.ukuu.org.uk Subject: [parisc-linux] RPM and hppa > I think the above is a different problem. The explosion is most likely > a problem with exception edges in the gcse pass. Try `-fno-gcse'. This > also appears in the tFile.cc libio test. I've not yet had a chance to try this. I see the same behaviour building Qt so I may try it on that From marteaut@esiee.fr Mon, 27 Nov 2000 18:11:36 +0000 Date: Mon, 27 Nov 2000 18:11:36 +0000 From: marteau marteaut@esiee.fr Subject: [parisc-linux] Hi all, We have tried to compile the new linux source today and vmlinux always needs pci.o to link. It works if you delete pci.o from the objects list in the kernel Makefile. But, we don't know why it was needed because we did not ask for in our "make config"... We appreciate any help! THX, ESIEE Team From dave@hiauly1.hia.nrc.ca Mon, 27 Nov 2000 12:13:02 -0500 (EST) Date: Mon, 27 Nov 2000 12:13:02 -0500 (EST) From: John David Anglin dave@hiauly1.hia.nrc.ca Subject: [parisc-linux] RPM and hppa > > > I think the above is a different problem. The explosion is most likely > > a problem with exception edges in the gcse pass. Try `-fno-gcse'. This > > also appears in the tFile.cc libio test. > > I've not yet had a chance to try this. I see the same behaviour building Qt > so I may try it on that Another option that might help if exceptions aren't needed is `-fno-exceptions'. Dave -- J. David Anglin dave.anglin@nrc.ca National Research Council of Canada (613) 990-0752 (FAX: 952-6605) From grundler@cup.hp.com Mon, 27 Nov 2000 09:57:39 -0800 Date: Mon, 27 Nov 2000 09:57:39 -0800 From: Grant Grundler grundler@cup.hp.com Subject: No subject marteau wrote: > We have tried to compile the new linux source today and vmlinux > always needs pci.o to link. It works if you delete pci.o from the > objects list in the kernel Makefile. But, we don't know why it was > needed because we did not ask for in our "make config"... Hi Thomas, The problem is in arch/parisc/kernel/Makefile. It doesn't use CONFIG_PCI to decide if pci.o is needed. I'll fix that now - should be simple. thanks, grant From dave@hiauly1.hia.nrc.ca Mon, 27 Nov 2000 13:19:52 -0500 (EST) Date: Mon, 27 Nov 2000 13:19:52 -0500 (EST) From: John David Anglin dave@hiauly1.hia.nrc.ca Subject: [parisc-linux] RPM and hppa > > I think the above is a different problem. The explosion is most likely > > a problem with exception edges in the gcse pass. Try `-fno-gcse'. This > > also appears in the tFile.cc libio test. > > I've not yet had a chance to try this. I see the same behaviour building Qt > so I may try it on that If the problem is in fact the exception handling method, I think we should look at implementing the DWARF2 unwind mechanism and exception handling using this unwind mechanism. The default method of handling exceptions is sjlj. See the description of DWARF2_UNWIND_INFO and INCOMING_RETURN_ADDR_RTX in gcc/tm.texi for more info. Alan Modra may want this for gdb as well. Dave -- J. David Anglin dave.anglin@nrc.ca National Research Council of Canada (613) 990-0752 (FAX: 952-6605) From alan@lxorguk.ukuu.org.uk Mon, 27 Nov 2000 18:34:23 +0000 (GMT) Date: Mon, 27 Nov 2000 18:34:23 +0000 (GMT) From: Alan Cox alan@lxorguk.ukuu.org.uk Subject: [parisc-linux] gcc crashes/out of memory and groff With groff -fno-gcse does not help but -O0 does. Without -O0 you get an internal error. g++ -I. -I/usr/src/redhat/BUILD/groff-1.16/src/roff/troff -I/usr/src/redhat/BUILD/groff-1.16/src/include -I/usr/src/redhat/BUILD/groff-1.16/src/include -DHAVE_UNISTD_H=1 -DHAVE_DIRENT_H=1 -DHAVE_LIMITS_H=1 -DHAVE_SYS_DIR_H=1 -DHAVE_STDLIB_H=1 -DHAVE_STRINGS_H=1 -DSTDLIB_H_DECLARES_PUTENV=1 -DSTDIO_H_DECLARES_POPEN=1 -DSTDIO_H_DECLARES_PCLOSE=1 -DHAVE_SYS_NERR=1 -DHAVE_SYS_ERRLIST=1 -DHAVE_CC_LIMITS_H=1 -DRETSIGTYPE=void -DHAVE_STRUCT_EXCEPTION=1 -DHAVE_UNISTD_H=1 -DHAVE_GETPAGESIZE=1 -DHAVE_MMAP=1 -DHAVE_FMOD=1 -DHAVE_STRTOL=1 -DHAVE_GETCWD=1 -DHAVE_STRERROR=1 -DHAVE_PUTENV=1 -DHAVE_RENAME=1 -DHAVE_MKSTEMP=1 -DHAVE_STRCASECMP=1 -DHAVE_STRSEP=1 -DHAVE_STRDUP=1 -DSYS_SIGLIST_DECLARED=1 -O2 -mpa-risc-1-0 -fno-gcse -c env.cc env.cc: In member function `void environment::output_line (node *, hunits)': env.cc:1582: Internal error: Segmentation fault. Please submit a full bug report. See for instructions. make[2]: *** [env.o] Error 1 make[2]: Leaving directory `/usr/src/redhat/BUILD/groff-1.16/src/roff/troff' Alan From marteaut@esiee.fr Mon, 27 Nov 2000 21:31:09 +0100 Date: Mon, 27 Nov 2000 21:31:09 +0100 From: Thomas Marteau marteaut@esiee.fr Subject: [parisc-linux] Include trouble Hi folks, Just to know if it is a local problem. We have this warning when we cross compile the kernel: /linux/cvs/linux/include/linux/string.h:61: warning: conflicting types for built-in function `memset' /linux/cvs/linux/include/linux/string.h:64: warning: conflicting types for built-in function `memcpy' /linux/cvs/linux/include/linux/string.h:73: warning: conflicting types for built-in function `memcmp' Can we have your point of view? Bye, ESIEE Team From marteaut@esiee.fr Tue, 28 Nov 2000 00:17:24 +0100 Date: Tue, 28 Nov 2000 00:17:24 +0100 From: Thomas Marteau marteaut@esiee.fr Subject: [parisc-linux] Leds Hi all, We tried to implement the led power of 712 hp boxes. We call leds_init in main.c in init directory. Even though it is working, we are not sure where to put the source that must be completed for others models. We could make a LEDS directory in drivers put the file in the kernel directory We also put the source for the initialisation of keyboard leds in lasi_ps2_reset but we admit that no led is on. Is it true? How can we know? THX, ESIEE Team From alan@linuxcare.com.au Tue, 28 Nov 2000 12:12:03 +1100 (EST) Date: Tue, 28 Nov 2000 12:12:03 +1100 (EST) From: Alan Modra alan@linuxcare.com.au Subject: [parisc-linux] gcc crashes/out of memory and groff On Mon, 27 Nov 2000, Alan Cox wrote: > With groff -fno-gcse does not help but -O0 does. Without -O0 you get an > internal error. Cross compiling from an x86-linux box with enough memory+swap (256M + 2G), env.cc eventually compiled for me using the default -O2 optimisation level. I had a crash later when compiling preproc/tbl/table.cc, so that's nothing to boast about. table.cc: In member function `void table::build_span_list ()': table.cc:2009: Internal error: Segmentation fault. Worse, when I added "-Q -da" to see what was happening, the compile succeeded - and also succeeded with either of -Q or -da alone. So I ran cc1plus under gdb, and that too failed to crash. :-( Maybe a garbage collection or uninitialised var bug? Alan Modra -- Linuxcare. Support for the Revolution. From alan@linuxcare.com.au Tue, 28 Nov 2000 15:59:54 +1100 (EST) Date: Tue, 28 Nov 2000 15:59:54 +1100 (EST) From: Alan Modra alan@linuxcare.com.au Subject: [parisc-linux] Include trouble On Mon, 27 Nov 2000, Thomas Marteau wrote: > Can we have your point of view? Your version of gcc expects the size_t parameter to all these functions to be "unsigned int", whereas the 2000/11/18 changes to linux/include/asm-parisc/posix_types.h made __kernel_size_t "unsigned long". As far as I understand, gcc's cpp has a built-in definition of size_t, __SIZE_TYPE__, and it ultimately gets it's idea of the definition from the kernel includes on the machine where gcc was compiled. ie. recompile gcc with the new kernel headers installed, and the problem should go away. For 32-bit hppa-linux, sizeof(int) == sizeof(long) so there shouldn't be any practical consequence other than these warning messages. There might be some "interesting" problems on hppa64-linux - I'm not sure. Alan Modra -- Linuxcare. Support for the Revolution. From alan@linuxcare.com.au Tue, 28 Nov 2000 20:19:20 +1100 (EST) Date: Tue, 28 Nov 2000 20:19:20 +1100 (EST) From: Alan Modra alan@linuxcare.com.au Subject: [parisc-linux] Include trouble On Tue, 28 Nov 2000, Alan Modra wrote: > As far as I understand, gcc's cpp has a built-in definition of size_t, > __SIZE_TYPE__, and it ultimately gets it's idea of the definition from the > kernel includes on the machine where gcc was compiled. ie. recompile gcc > with the new kernel headers installed, and the problem should go away. No, that's wrong. __SIZE_TYPE__ comes from `#define SIZE_TYPE' in gcc/config/pa/pa-linux{,64}.h I'll check in a patch to gcc in a few moments. Alan -- Linuxcare. Support for the Revolution. From marteaut@esiee.fr Tue, 28 Nov 2000 16:07:04 +0100 Date: Tue, 28 Nov 2000 16:07:04 +0100 From: Thomas Marteau marteaut@esiee.fr Subject: [parisc-linux] Mouse driver for PS/2 Hi all, We appreciate if someone can explain where we can find request_irq and request_region in hp_psaux.c and also, what are they doing? Thanks, ESIEE Team From deller@gmx.de Tue, 28 Nov 2000 18:21:34 +0100 Date: Tue, 28 Nov 2000 18:21:34 +0100 From: Helge Deller deller@gmx.de Subject: [parisc-linux] Mouse driver for PS/2 On Tuesday 28 November 2000 16:07, Thomas Marteau wrote: > Hi all, Hi Thomas, > > We appreciate if someone can explain where we can find request_irq #include and /arch/parisc/kernel/irq.c request_irq() binds the given interrupt-number to a function (if possible). > and > request_region #include request_region only marks (and tests) an I/O-region as used by a driver and makes this information visible via /proc/iomem and /proc/ioports. > in hp_psaux.c and also, > what are they doing? > > Thanks, > ESIEE Team From wferguson@server01.chatspace.com Tue, 28 Nov 2000 09:35:36 -0800 Date: Tue, 28 Nov 2000 09:35:36 -0800 From: William Ferguson wferguson@server01.chatspace.com Subject: [parisc-linux] PDC firmware revision FAQ update This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C05961.9E1AB8A8 Content-Type: text/plain; charset="iso-8859-1" Is the web server at www.parisc-linux.org down? Can't seem to connect from San Diego. -----Original Message----- From: Grant Grundler [mailto:grundler@cup.hp.com] Sent: Friday, November 17, 2000 1:51 PM To: parisc-linux@puffin.external.hp.com Subject: [parisc-linux] PDC firmware revision FAQ update Hi folks, The issue of PDC/firmware revs came up locally and sounded like a FAQ. I added "10. How can I check if the PDC (firmware) revision is the latest?" and what I knew/could find to our FAQ at: http://www.parisc-linux.org/faq.html The new FAQ entry should be visible to the world in the next hour or so. **** WARNING **** Firmware upgrades can *kill* your machine! **** WARNING **** Don't do it just because. Read the FAQ carefully. Take the time to figure out why you might need the upgrade and expose yourself to this risk. grant ps. please don't ask me why your favorite machine's PDC isn't listed. I don't run the referenced sites. --------------------------------------------------------------------------- To unsubscribe: send e-mail to parisc-linux-request@thepuffingroup.com with `unsubscribe' as the subject. ------_=_NextPart_001_01C05961.9E1AB8A8 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [parisc-linux] PDC firmware revision FAQ update

Is the web server at www.parisc-linux.org down?  = Can't seem to connect from San Diego.

-----Original Message-----
From: Grant Grundler [mailto:grundler@cup.hp.com]
Sent: Friday, November 17, 2000 1:51 PM
To: parisc-linux@puffin.external.hp.com
Subject: [parisc-linux] PDC firmware revision FAQ = update


Hi folks,

The issue of PDC/firmware revs came up locally and = sounded like a FAQ.
I added

    "10. How can I check if the = PDC (firmware) revision is the latest?"

and what I knew/could find to our FAQ at:

        http://www.parisc-linux.org/faq.html

The new FAQ entry should be visible to the world in = the next hour or so.


    **** WARNING ****
    Firmware upgrades can *kill* your = machine!
    **** WARNING ****

Don't do it just because. Read the FAQ carefully. = Take the
time to figure out why you might need the upgrade = and expose
yourself to this risk.

grant

ps. please don't ask me why your favorite machine's = PDC isn't listed.
   I don't run the referenced = sites.

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

------_=_NextPart_001_01C05961.9E1AB8A8-- From dave@hiauly1.hia.nrc.ca Tue, 28 Nov 2000 12:37:28 -0500 (EST) Date: Tue, 28 Nov 2000 12:37:28 -0500 (EST) From: John David Anglin dave@hiauly1.hia.nrc.ca Subject: [parisc-linux] Include trouble > On Tue, 28 Nov 2000, Alan Modra wrote: > > > As far as I understand, gcc's cpp has a built-in definition of size_t, > > __SIZE_TYPE__, and it ultimately gets it's idea of the definition from the > > kernel includes on the machine where gcc was compiled. ie. recompile gcc > > with the new kernel headers installed, and the problem should go away. > > No, that's wrong. __SIZE_TYPE__ comes from `#define SIZE_TYPE' in > gcc/config/pa/pa-linux{,64}.h I'll check in a patch to gcc in a few > moments. Hmm. Most 32 bit systems use "unsigned int" rather than "unsigned long". Using "unsigned long" might cause problems with packages like libio. I know there is a problem if off_t is not the same as size_t. Dave -- J. David Anglin dave.anglin@nrc.ca National Research Council of Canada (613) 990-0752 (FAX: 952-6605) From grundler@cup.hp.com Tue, 28 Nov 2000 09:49:26 -0800 Date: Tue, 28 Nov 2000 09:49:26 -0800 From: Grant Grundler grundler@cup.hp.com Subject: [parisc-linux] Mouse driver for PS/2 Thomas Marteau wrote: > Hi all, > > We appreciate if someone can explain where we can find request_irq and > request_region in hp_psaux.c and also, what are they doing? include/linux/sched.h:extern int request_irq(unsigned int, ...) (Implementation is in arch/parisc/kernel/irq.c) The request_irq() "allocates" an IRQ line for use by the device - this program the PIC (or APIC) on x86 platforms. request_irq() is also how an interrupt handler is associated with a specific IRQ line. Since PA Risc CPU's don't have IRQ lines going into them, IRQ's are virtualized and don't always represent a physical IRQ line. Under LASI, see gsc_alloc_irq(&gsc_irq) usage in drivers/gsc/lasi.c. lasi_find_irq() helps associate the PS/2 interrupt handler with the correct IRQ line which is internal to lasi. include/linux/ioport.h:#define request_region(start,n,name) ... request_region() will reserve a range of I/O port address from the global I/O space. request_mem_region() does the same for MMIO. Drivers that use inb/outb (as defined in include/asm-parisc/io.h) must use request_region(). Drivers that use gsc_readb/gsc_writeb (as defined in include/asm-parisc/gsc.h) must use request_mem_region(). Collisions are probably occuring where a driver originally used inb/outb and those were redefined to use gsc_readb/writeb functions. But the driver is still using request_region(). And it doesn't help that I may have broken some of the resource mgt with some code I committed last night. It worked on my boxes (A180/C3K) but broke on other folks. Paul Bame helped find/fix one bug but I shouldn't be surprised if more bugs are still out there. I will be fixing some known resource failure problems on A500. Please post problems on other platforms to parisc-linux list as well. hope this helps, grant Grant Grundler Unix Systems Enablement Lab +1.408.447.7253 From grundler@cup.hp.com Tue, 28 Nov 2000 09:53:37 -0800 Date: Tue, 28 Nov 2000 09:53:37 -0800 From: Grant Grundler grundler@cup.hp.com Subject: [parisc-linux] PDC firmware revision FAQ update William Ferguson wrote: > Is the web server at www.parisc-linux.org down? Can't seem to connect from > San Diego. Yes. Linuxcare is having some DNS problems right now and they host that site. Any forecasts on when that will be back up? grant From bame@noam.fc.hp.com Tue, 28 Nov 2000 12:27:09 -0700 Date: Tue, 28 Nov 2000 12:27:09 -0700 From: Paul Bame bame@noam.fc.hp.com Subject: [parisc-linux] Include trouble = Hmm. Most 32 bit systems use "unsigned int" rather than "unsigned long". I will be happy to change it back to unsigned int. The only reason I used unsigned long is because it seems off_t wants to be, to a first approximation, the word length of the machine, and 'long' does that. = Using "unsigned long" might cause problems with packages like libio. = I know there is a problem if off_t is not the same as size_t. What problem is that? I'm working on a proposal for the palinux type sizes at the moment. One dilema is that off_t is supposed to be good for file offsets, which these days means it should be 64 bits. size_t refers to the sizes of objects which are expected to fit in RAM, so should be the word size of the machine. So there's a conflict because one logic suggests 64-bit off_t and 32-bit size_t on 32-bit palinux, but your statement suggests they should be the same size. Any ideas? However I'm leaning towards leaning with the older 32-bit off_t because we might not want to be the first ones to fix all the problems with making it 64 bits on a 32-bit machine. -P From marteaut@esiee.fr Tue, 28 Nov 2000 20:30:30 +0100 Date: Tue, 28 Nov 2000 20:30:30 +0100 From: Thomas Marteau marteaut@esiee.fr Subject: [parisc-linux] Mouse driver for PS/2 Hi all, We have a sample of code for the mouse driver. But, we would like to know how the Puffin would like the implementation of the driver. Because of drag & drop..., do you want two different interrupt functions or a single that does a redirection. Also , we have seen that busmouse.c is quite interesting for our driver. Do we make a copy and call it hp_mouse.c? Thanks for your answer, ESIEE Team For a better future with a mouse! From alan@lxorguk.ukuu.org.uk Tue, 28 Nov 2000 20:02:26 +0000 (GMT) Date: Tue, 28 Nov 2000 20:02:26 +0000 (GMT) From: Alan Cox alan@lxorguk.ukuu.org.uk Subject: [parisc-linux] Include trouble > One dilema is that off_t is supposed to > be good for file offsets, which these days means it should be 64 bits. off_t should be a natural type. So it should be 32bits. glibc 2.2 deals with the 64bit I/O stuff nicely > However I'm leaning towards leaning with the older 32-bit off_t because > we might not want to be the first ones to fix all the problems with > making it 64 bits on a 32-bit machine. Go 32bit. Linus will probably refuse to touch a 32bit port using longlong internally for off-t From dave@hiauly1.hia.nrc.ca Tue, 28 Nov 2000 15:24:26 -0500 (EST) Date: Tue, 28 Nov 2000 15:24:26 -0500 (EST) From: John David Anglin dave@hiauly1.hia.nrc.ca Subject: [parisc-linux] Include trouble > = Hmm. Most 32 bit systems use "unsigned int" rather than "unsigned long". > > I will be happy to change it back to unsigned int. The only reason > I used unsigned long is because it seems off_t wants to be, to a > first approximation, the word length of the machine, and 'long' does > that. Agreed. > = Using "unsigned long" might cause problems with packages like libio. > > > = I know there is a problem if off_t is not the same as size_t. > > What problem is that? I'm working on a proposal for the palinux > type sizes at the moment. It is simply dumb coding that hasn't been fixed. There are inconsistencies between the interface declarations and implementations. The old libio is on the way out. > One dilema is that off_t is supposed to > be good for file offsets, which these days means it should be 64 bits. > size_t refers to the sizes of objects which are expected to fit in > RAM, so should be the word size of the machine. So there's a conflict > because one logic suggests 64-bit off_t and 32-bit size_t on 32-bit palinux, > but your statement suggests they should be the same size. Any ideas? Only, because of poorly written legacy code. I agree that off_t should be 64 bits on 32 bit platforms today. > However I'm leaning towards leaning with the older 32-bit off_t because > we might not want to be the first ones to fix all the problems with > making it 64 bits on a 32-bit machine. Maybe it isn't that bad because I noticed at least one port used unsigned long long for off_t. Dave -- J. David Anglin dave.anglin@nrc.ca National Research Council of Canada (613) 990-0752 (FAX: 952-6605) From dave@hiauly1.hia.nrc.ca Tue, 28 Nov 2000 15:33:52 -0500 (EST) Date: Tue, 28 Nov 2000 15:33:52 -0500 (EST) From: John David Anglin dave@hiauly1.hia.nrc.ca Subject: [parisc-linux] Include trouble > Maybe it isn't that bad because I noticed at least one port used unsigned > long long for off_t. Take that back. It was __kernel_loff_t. Just go with typedef unsigned int __kernel_size_t; typedef long __kernel_off_t; #ifdef __GNUC__ typedef long long __kernel_loff_t; #endif for the 32 bit port. Dave -- J. David Anglin dave.anglin@nrc.ca National Research Council of Canada (613) 990-0752 (FAX: 952-6605) From deller@gmx.de Tue, 28 Nov 2000 21:41:53 +0100 Date: Tue, 28 Nov 2000 21:41:53 +0100 From: Helge Deller deller@gmx.de Subject: [parisc-linux] Mouse driver for PS/2 On Tuesday 28 November 2000 20:30, Thomas Marteau wrote: > Hi all, Hi Thomas, > > We have a sample of code for the mouse driver. But, we would like to > know how the Puffin would like the implementation of the driver. Because > of drag & drop..., do you want two different interrupt functions or a > single that does a redirection. Also , we have seen that busmouse.c is > quite interesting for our driver. Do we make a copy and call it > hp_mouse.c? I would propose, that you check in hp_mouse.c and use different interrupt functions for now. Changing it later shouldn't be too difficult. Greetings, Helge. > > Thanks for your answer, > ESIEE Team > For a better future with a mouse! From doneill@linuxcare.com Tue, 28 Nov 2000 16:08:49 -0500 (EST) Date: Tue, 28 Nov 2000 16:08:49 -0500 (EST) From: Dave O'Neill doneill@linuxcare.com Subject: [parisc-linux] PDC firmware revision FAQ update On Tue, 28 Nov 2000, Grant Grundler wrote: > Yes. Linuxcare is having some DNS problems right now and > they host that site. Any forecasts on when that will be back up? Well, it looks like our DNS issues are fixed... the site should be accessible now. Dave -- Dave O'Neill, Senior Linux Consultant, Linuxcare, Inc. desk: (613) 562-9949 fax: (613) 562-9700 cell: (613) 223-0219 doneill@linuxcare.com http://www.linuxcare.com/ From bame@noam.fc.hp.com Tue, 28 Nov 2000 14:21:05 -0700 Date: Tue, 28 Nov 2000 14:21:05 -0700 From: Paul Bame bame@noam.fc.hp.com Subject: [parisc-linux] Include trouble = Go 32bit. Linus will probably refuse to touch a 32bit port using longlong = internally for off-t Hmmm, too bad, since we have few palinux backwards compatibility issues and could just have the __USE_FILE_OFFSET64 glibc magic be a no-op rather than supporting all those extra *64 syscalls. Plus we'd need considerably fewer syscall translators to run 32-bit apps on 64-bit kernel (but might need more for 32-bit hpux apps). It seems illogical to make a file-system-related data type different based on cpu word size but I understand this isn't simple -- oh well. Seems like the consensus is 32-bit off_t on 32-bit kernel and just live with all those *64 syscalls -- many not supported on palinux yet I notice. -P From alan@lxorguk.ukuu.org.uk Tue, 28 Nov 2000 21:58:56 +0000 (GMT) Date: Tue, 28 Nov 2000 21:58:56 +0000 (GMT) From: Alan Cox alan@lxorguk.ukuu.org.uk Subject: [parisc-linux] Include trouble > Seems like the consensus is 32-bit off_t on 32-bit kernel and just > live with all those *64 syscalls -- many not supported on palinux > yet I notice. Remember providing you use off_t you can just tell glibc to do all the work for you and write with a 64bit off_t to userspace From alan@linuxcare.com.au Wed, 29 Nov 2000 10:27:20 +1100 (EST) Date: Wed, 29 Nov 2000 10:27:20 +1100 (EST) From: Alan Modra alan@linuxcare.com.au Subject: [parisc-linux] Include trouble On Tue, 28 Nov 2000, John David Anglin wrote: > Hmm. Most 32 bit systems use "unsigned int" rather than "unsigned long". There's some precedent for using "unsigned long", as that is what is used on 32-bit hpux11 and osf gcc targets. current sourceware CVS gcc/config/pa/: $ grep SIZE_TYPE * grep: CVS: Is a directory pa-64.h:#undef SIZE_TYPE pa-64.h:#define SIZE_TYPE "long unsigned int" pa-hpux.h:#undef SIZE_TYPE pa-hpux.h:#define SIZE_TYPE "unsigned int" pa-hpux11.h:#undef SIZE_TYPE pa-hpux11.h:#define SIZE_TYPE "long unsigned int" pa-hpux7.h:#undef SIZE_TYPE pa-hpux7.h:#define SIZE_TYPE "unsigned int" pa-linux.h:#undef SIZE_TYPE pa-linux.h:#define SIZE_TYPE "unsigned int" pa-osf.h:#undef SIZE_TYPE pa-osf.h:#define SIZE_TYPE "long unsigned int" pa-pro-end.h:#undef SIZE_TYPE pa-pro-end.h:#define SIZE_TYPE "unsigned int" pa.h:#define SIZE_TYPE "unsigned int" Some further grepping shows quite a number of other 32-bit gcc targets using "unsigned long", but I didn't see any 32-bit linux targets in the list. Paul, If you change back to "unsigned int", please change gcc/config/pa/pa-linux.h too. Alan -- Linuxcare. Support for the Revolution. From Frank.Butter@otto.de Wed, 29 Nov 2000 11:50:39 +0100 Date: Wed, 29 Nov 2000 11:50:39 +0100 From: Butter, Frank Frank.Butter@otto.de Subject: [parisc-linux] hardware to all here I was annaouncing an offer for hp hardware recently: it'll take longer than initially expected to convince our bosses ;-/ please stay patient... frank From matthias@archimed.math.uni-mannheim.de Wed, 29 Nov 2000 20:52:38 +0100 (MET) Date: Wed, 29 Nov 2000 20:52:38 +0100 (MET) From: Matthias Juchem matthias@archimed.math.uni-mannheim.de Subject: [parisc-linux] parisc-0.5.iso and stack trace Hi there. I've just downloaded the ISO images and tried to boot an 9000/705. I keep getting a stack trace. Can you tell me which part of the trace I can send you so that you could eventually tell me what is wrong? TIA, Matthias From dave@hiauly1.hia.nrc.ca Wed, 29 Nov 2000 17:05:31 -0500 (EST) Date: Wed, 29 Nov 2000 17:05:31 -0500 (EST) From: John David Anglin dave@hiauly1.hia.nrc.ca Subject: [parisc-linux] gcc crashes/out of memory and groff > With groff -fno-gcse does not help but -O0 does. Without -O0 you get an > internal error. > > g++ -I. -I/usr/src/redhat/BUILD/groff-1.16/src/roff/troff -I/usr/src/redhat/BUILD/groff-1.16/src/include -I/usr/src/redhat/BUILD/groff-1.16/src/include -DHAVE_UNISTD_H=1 -DHAVE_DIRENT_H=1 -DHAVE_LIMITS_H=1 -DHAVE_SYS_DIR_H=1 -DHAVE_STDLIB_H=1 -DHAVE_STRINGS_H=1 -DSTDLIB_H_DECLARES_PUTENV=1 -DSTDIO_H_DECLARES_POPEN=1 -DSTDIO_H_DECLARES_PCLOSE=1 -DHAVE_SYS_NERR=1 -DHAVE_SYS_ERRLIST=1 -DHAVE_CC_LIMITS_H=1 -DRETSIGTYPE=void -DHAVE_STRUCT_EXCEPTION=1 -DHAVE_UNISTD_H=1 -DHAVE_GETPAGESIZE=1 -DHAVE_MMAP=1 -DHAVE_FMOD=1 -DHAVE_STRTOL=1 -DHAVE_GETCWD=1 -DHAVE_STRERROR=1 -DHAVE_PUTENV=1 -DHAVE_RENAME=1 -DHAVE_MKSTEMP=1 -DHAVE_STRCASECMP=1 -DHAVE_STRSEP=1 -DHAVE_STRDUP=1 -DSYS_SIGLIST_DECLARED=1 -O2 -mpa-risc-1-0 -fno-gcse -c env.cc > env.cc: In member function `void environment::output_line (node *, hunits)': > env.cc:1582: Internal error: Segmentation fault. > Please submit a full bug report. > See for instructions. > make[2]: *** [env.o] Error 1 > make[2]: Leaving directory `/usr/src/redhat/BUILD/groff-1.16/src/roff/troff' This error is also exception related but appears different from the memory explosion. It occurs in scan_region in except.c. The memory explosion that occurs without -fno-gcse does seem to occur in the gcse pass as I suspected. I need to rebuild gcc with debugging to get further. I was able to build the groff package with `CXXFLAGS="-O3 -fno-exceptions"'. Dave -- J. David Anglin dave.anglin@nrc.ca National Research Council of Canada (613) 990-0752 (FAX: 952-6605) From delyra@latt.if.usp.br Wed, 29 Nov 2000 20:22:47 -0200 (BRST) Date: Wed, 29 Nov 2000 20:22:47 -0200 (BRST) From: Jorge L. deLyra delyra@latt.if.usp.br Subject: [parisc-linux] HP 9000/735-125 I just booted the palinux-0.5.iso CD on a HP 9000 model 735 workstation. It went on quite a bit before hanging immediatelly after reporting the serial ports. Gave large amount of what looks like traceback or state information. Question: would it do anyone any good if I tried to get everything the kernel said before the hang into a message in this list? Cheers, ---------------------------------------------------------------- Jorge L. deLyra, Associate Professor of Physics The University of Sao Paulo, IFUSP-DFMA For more information: finger delyra@latt.if.usp.br ---------------------------------------------------------------- From grundler@cup.hp.com Wed, 29 Nov 2000 15:19:10 -0800 Date: Wed, 29 Nov 2000 15:19:10 -0800 From: Grant Grundler grundler@cup.hp.com Subject: [parisc-linux] HP 9000/735-125 "Jorge L. deLyra" wrote: > I just booted the palinux-0.5.iso CD on a HP 9000 model 735 workstation. > It went on quite a bit before hanging immediatelly after reporting the > serial ports. Gave large amount of what looks like traceback or state > information. Question: would it do anyone any good if I tried to get > everything the kernel said before the hang into a message in this list? Certainly. I won't be able to debug the problems since I (a) don't have the time too (unless it's obvious) and (b) don't have a 735 setup for testing. This is becoming a FAQ: "My system crashed after ... What should I do next?" I'm thinking people in the support space would know how to write this one really well :^) Is I get one in the mail, I'll add it to our FAQ. thanks, grant Grant Grundler Unix Systems Enablement Lab +1.408.447.7253 From smoret@uci.edu Wed, 29 Nov 2000 15:28:20 -0800 Date: Wed, 29 Nov 2000 15:28:20 -0800 From: Steve Moret smoret@uci.edu Subject: [parisc-linux] HP 9000/735-125 Jorge, I have a 735-125 and am able to net-boot it on a custom configured kernel as long as I disable the ASP parallel ports. It works quite well using an NFS root as I cannot get the SCSI hard drives to mkfs. I was going to try and debug it but have yet to find the free time. I can e-mail you my working .config for the kernel, or build kernels (tested on my own 735) for people if they need them. -- Steve Moret smoret@uci.edu > -----Original Message----- > From: Grant Grundler [mailto:grundler@cup.hp.com] > Sent: Wednesday, November 29, 2000 3:19 PM > To: Jorge L. deLyra > Cc: parisc-linux@thepuffingroup.com > Subject: Re: [parisc-linux] HP 9000/735-125 > > > "Jorge L. deLyra" wrote: > > I just booted the palinux-0.5.iso CD on a HP 9000 model 735 workstation. > > It went on quite a bit before hanging immediatelly after reporting the > > serial ports. Gave large amount of what looks like traceback or state > > information. Question: would it do anyone any good if I tried to get > > everything the kernel said before the hang into a message in this list? > > Certainly. I won't be able to debug the problems since I (a) don't have > the time too (unless it's obvious) and (b) don't have a 735 setup > for testing. > > This is becoming a FAQ: > "My system crashed after ... What should I do next?" > > I'm thinking people in the support space would know how to write > this one really well :^) > Is I get one in the mail, I'll add it to our FAQ. > > thanks, > grant > > > Grant Grundler > Unix Systems Enablement Lab > +1.408.447.7253 > > ------------------------------------------------------------------ > --------- > To unsubscribe: send e-mail to > parisc-linux-request@thepuffingroup.com with > `unsubscribe' as the subject. > > From deller@gmx.de Thu, 30 Nov 2000 01:10:51 +0100 Date: Thu, 30 Nov 2000 01:10:51 +0100 From: Helge Deller deller@gmx.de Subject: [parisc-linux] HP 9000/735-125 X On Thursday 30 November 2000 00:28, Steve Moret wrote: > I have a 735-125 and am able to net-boot it on a custom configured kernel > as long as I disable the ASP parallel ports. .... Steve, I really would like to get the parallel-port problems on ASP get fixed as soon as possible. Could you please mail me your bootlog (with parport enabled), so I can try to track down the problem. Maybe you can also check out CVS again, and test if this version works for you ? Thanks, Helge Deller From alan@lxorguk.ukuu.org.uk Thu, 30 Nov 2000 02:38:56 +0000 (GMT) Date: Thu, 30 Nov 2000 02:38:56 +0000 (GMT) From: Alan Cox alan@lxorguk.ukuu.org.uk Subject: [parisc-linux] XFree status I have a server linked. inb/inw/outb/outw and friends are right now null functions until I fill them in. Thats not a big deal. Initially I'll probably use /dev/port but for speed I hope everyone uses mmio based hardware. Also is this bad ? /usr/bin/ld: lbxdix.o(.text+0x6fc): fixing R_PARISC_DPREL21L /usr/bin/ld: lbxprop.o(.text+0xde4): fixing R_PARISC_DPREL21L /usr/bin/ld: lbxprop.o(.text+0xdf4): fixing R_PARISC_DPREL21L Alan phux:/usr/src/redhat/BUILD/XFree86-4.0.1/xc/programs/Xserver# ./XFree86 XFree86 Version 4.0.1a / X Window System (protocol Version 11, revision 0, vendor release 6400) Release Date: 2 August 2000 If the server is older than 6-12 months, or if your card is newer than the above date, look for a newer version before reporting problems. (see http://www.XFree86.Org/FAQ) Operating System: Linux 2.4.0-test6 parisc [ELF] (==) Log file: "/var/log/XFree86.0.log", Time: Wed Nov 29 19:40:16 2000 (==) Using config file: "/etc/X11/XF86Config" Parse warning on line 77 of section Keyboard in file /etc/X11/XF86Config Ignoring obsolete keyword "LeftAlt". Parse error on line 77 of section Keyboard in file /etc/X11/XF86Config "Meta" is not a valid keyword in this section. (EE) Problem parsing the config file (EE) Error from xf86HandleConfigFile() Fatal server error: no screens found When reporting a problem related to a server crash, please send the full server output, not just the last messages. This can be found in the log file "/var/log/XFree86.0.log". Please reports problems to xfree86@xfree86.org. From alan@linuxcare.com.au Thu, 30 Nov 2000 14:41:48 +1100 (EST) Date: Thu, 30 Nov 2000 14:41:48 +1100 (EST) From: Alan Modra alan@linuxcare.com.au Subject: [parisc-linux] XFree status On Thu, 30 Nov 2000, Alan Cox wrote: > Also is this bad ? > > /usr/bin/ld: lbxdix.o(.text+0x6fc): fixing R_PARISC_DPREL21L No. It's a symptom of a variable's "constness" being declared differently from the way the variable is defined. For instance, referring to "extern int foo" in one object with foo defined as "const int foo" in another. I'll be removing the linker warning at some stage. Alan Modra -- Linuxcare. Support for the Revolution. From grundler@cup.hp.com Wed, 29 Nov 2000 21:18:14 -0800 Date: Wed, 29 Nov 2000 21:18:14 -0800 From: Grant Grundler grundler@cup.hp.com Subject: [parisc-linux] XFree status Alan Cox wrote: > I have a server linked. Alan - that's Cool! Wow! > inb/inw/outb/outw and friends are right now null > functions until I fill them in. Thats not a big deal. Initially I'll probably > use /dev/port but for speed I hope everyone uses mmio based hardware. All HP graphics for PARISC are memory mapped. Both "GSC" and PCI flavors. But I'm pretty clueless how linux X server finds/talks to a frame buffer. For HPUX, the graphics driver supports some ioctl()'s. Any references to describe how it works for linux? parisc-linux doesn't create kernel virtual addresses for MMIO. Which interface is used to create user virtual addresses for MMIO? (In general - not just for frame buffers) Is the PCI address passed to user space? I'm wondering if/how "bus_to_virt()" type translations take place. sorry for the many questions... grant Grant Grundler Unix Systems Enablement Lab +1.408.447.7253 From gibreel@pobox.com 30 Nov 2000 00:09:03 -0800 Date: 30 Nov 2000 00:09:03 -0800 From: Stephen Zander gibreel@pobox.com Subject: [parisc-linux] CVS linux Vs. -test10 >>>>> "Grant" == Grant Grundler writes: Grant> For the record, the second issue bdale made clear was we Grant> need "boot floppies" debian package working. We don't need Grant> more ISO images (no offense to pjlahaie for his good Grant> work). "Boot floppies" is a pre-requisite to becoming part Grant> of the next debian release. Given I still don't have a clue Grant> how to build a debian package and I can still contribute Grant> alot in other areas, it doesn't make sense for me to do it Grant> myself. Oooh, there's a reason for me to finally get the 712/80 under my desk to be more than a foot-rest. I'll see what I can do about this. Note that the likelihood of Debian releasing woody anytime soon is vanishingly small, so this dosen't have to happen Right Now. -- Stephen (debian developer) "Strange women lying in ponds distributing swords is no basis for a system of government" From smoret@uci.edu Thu, 30 Nov 2000 01:20:28 -0800 Date: Thu, 30 Nov 2000 01:20:28 -0800 From: Steve Moret smoret@uci.edu Subject: [parisc-linux] HP 9000/735-125 Helge, My mistake! I did a full build with todays CVS and parport didn't die. So somewhere between the 17th and now parport must have been fixed. Now, maybe you can help me identify my SCSI problem. I don't know if it is because of driver issues or a bad disk (completly likely). Do other people have the Fast SCSI2 working on their 735s? Whenever I do a mke2fs (after partitioning the drive with fdisk ok) it dies. At bootup I get: SCSI subsystem driver Revision: 1.00 sim700: Couldn't get consistent shared memory sim700: Configuring 53c700 (SCSI-ID 7) at f0825100, IRQ 86 scsi0: Revision 0x0 Post test1, istat 05, sstat0 00, dstat 84 sim700: WARNING IRQ probe failed, (returned 0) scsi0: WARNING: target data areas are not dma coherent! scsi0: test 1 completed ok. scsi0: sim700_intr_handle() called with no interrupt scsi0 : LASI/Simple 53c7xx Vendor: HP Model: C2235 Rev: 0B11 Type: Direct-Access ANSI SCSI revision: 02 Vendor: HP Model: C2235 Rev: 0B11 Type: Direct-Access ANSI SCSI revision: 02 Detected scsi disk sda at scsi0, channel 0, id 5, lun 0 Detected scsi disk sdb at scsi0, channel 0, id 6, lun 0 SCSI device sda: 825012 512-byte hdwr sectors (422 MB) Partition check: sda: sda1 sda2 SCSI device sdb: 825012 512-byte hdwr sectors (422 MB) sdb: sdb1 sdb2 And then if I try to mke2fs the disk I get: hp735:~# fdisk -l /dev/sda Disk /dev/sda: 13 heads, 62 sectors, 1023 cylinders Units = cylinders of 806 * 512 bytes Device Boot Start End Blocks Id System /dev/sda1 1 910 366699 83 Linux /dev/sda2 911 1023 45539 82 Linux swap hp735:~# mke2fs /dev/sda1 mke2fs 1.19, 13-Jul-2000 for EXT2 FS 0.5b, 95/08/09 Filesystem label= OS type: Linux Block size=1024 (log=0) Fragment size=1024 (log=0) 91800 inodes, 366699 blocks 18334 blocks (5.00%) reserved for the super user First data block=1 45 block groups 8192 blocks per group, 8192 fragments per group 2040 inodes per group Superblock backups stored on blocks: 8193, 24577, 40961, 57345, 73729, 204801, 221185 Writing inode tables: done Writing superblocks and filesystem accounting information: scsi0: Unable to abort command for target 5 scsi0: Unable to send Bus Device Reset for target 5 scsi0: Unable to do SCSI bus reset scsi0: >>>>>>>>>>>> Host reset <<<<<<<<<<<< scsi0: istat = 0c, sstat0 = 00, sstat1 = 00, dstat = 00 scsi0: dsp = 0cf15038 (script[0x140e]), dsps = 0cf15cde, target = 0 scsi0: Failing command for ID5 scsi0: sim700_intr_handle() called with no interrupt pa11_dma_map_single(PCI_DMA_NONE) called by c01cb6d4 kernel BUG at pci-dma.c:392! pa11_dma_unmap_single(PCI_DMA_NONE) called by c01ca3bc kernel BUG at pci-dma.c:403! SCSI disk error : host 0 channel 0 id 5 lun 0 return code = 2 I/O error: dev 08:01, sector 268 I/O error: dev 08:01, sector 270 I/O error: dev 08:01, sector 396 I/O error: dev 08:01, sector 16396 I/O error: dev 08:01, sector 16524 I/O error: dev 08:01, sector 16652 Of course the I/O errors continue on for a long time. Are these bad drives? Or is there a problem with the driver that still needs to be worked out? Thanks for all your help, I hope my spews of debug output are helpful, -- Steve Moret smoret@uci.edu > -----Original Message----- > From: Helge Deller [mailto:deller@gmx.de] > Sent: Wednesday, November 29, 2000 4:11 PM > To: Steve Moret > Cc: parisc-linux@thepuffingroup.com > Subject: Re: [parisc-linux] HP 9000/735-125 > > I really would like to get the parallel-port problems on ASP get fixed as > soon as possible. > Could you please mail me your bootlog (with parport enabled), so > I can try to > track down the problem. > Maybe you can also check out CVS again, and test if this version > works for > you ? From delyra@latt.if.usp.br Thu, 30 Nov 2000 08:58:22 -0200 (BRST) Date: Thu, 30 Nov 2000 08:58:22 -0200 (BRST) From: Jorge L. deLyra delyra@latt.if.usp.br Subject: [parisc-linux] HP 9000/735-125 > > information. Question: would it do anyone any good if I tried to get > > everything the kernel said before the hang into a message in this list? > > Certainly. I won't be able to debug the problems since I (a) don't have > the time too (unless it's obvious) and (b) don't have a 735 setup > for testing. OK, here goes. I want to congratulate you all on this effort. We have five of these HP-9000 stations here, quite old by now. They used to be our main number crunching force. They are wonderfully built hardware in bad need of a wonderful system on them! |:-) ---------------------------------------------------------------- Jorge L. deLyra, Associate Professor of Physics The University of Sao Paulo, IFUSP-DFMA For more information: finger delyra@latt.if.usp.br ---------------------------------------------------------------- Seyon Copyright (c) 1992-1993 Muhammad M. Saggaf. All rights reserved. Version 2 rev. 20c i586-Linux steve@hammer 05/23/99 20:19:22. Locating Modems... Modem `/dev/ttyS0' is Available. (c) Copyright. Hewlett-Packard Company. 1992. All rights reserved. PDC ROM rev. 2.7 IODC ROM rev. 1.1 80 MB of memory configured and tested. Searching for Potential Boot Devices. To terminate search, press and hold the ESCAPE key. Device Selection Device Path Device Type ---------------------------------------------------------------------------- P0 scsi.6.0 HP C3725S P1 scsi.4.0 TOSHIBA CD-ROM XM-3301TA b) Boot from specified device s) Search for bootable devices a) Enter Boot Administration mode x) Exit and continue boot sequence ?) Help Select from menu: b p1 Trying scsi.4.0 Boot path initialized. Attempting to load IPL. Soft booted. palo ipl bame@noam Tue Oct 31 14:18:02 MST 2000 0/vmlinux 2140145 bytes @ 0x6f9800 0/palo-cmdline '0/vmlinux ROOT=/ TERM=LINUX root=/dev/scd0' Kernel: partition 0 file /vmlinux ELF32 executable Entry 00100150 first 00100000 n 4 Segment 0 load 00100000 size 1460344 mediaptr 0x1000 Segment 1 load 00266000 size 179048 mediaptr 0x166000 Segment 2 load 00294000 size 109876 mediaptr 0x192000 Segment 3 load 002b0000 size 8192 mediaptr 0x1ad000 branching to kernel entry point 0x00100150 PDC Console Initialized The 32-bit Kernel has started... Enabled FP coprocessor Free memory starts at: 0xc02da000 (0x504d6c,0x504d6c,0x0,0x0) PALO command line: 'ROOT=/ TERM=LINUX root=/dev/scd0' PALO initrd 0-0 model 00002060 00000481 00000000 00000000 77f451b0 ffffffff 00000004 0000000a 0000000a vers 00000015 CPUID vers 0 rev 0 Searching for devices in PDC firmware... processor hpa 0xfffbe000 an older box... Found devices: 1. Outfield Core BA (11) at 0xf082f000, versions 0x9, 0x0, 0x70, 0x0, 0x0 2. Outfield Core SCSI (10) at 0xf0825000, versions 0x9, 0x0, 0x71, 0x0, 0x0 3. Outfield Core LAN (802.3) (10) at 0xf0826000, versions 0x9, 0x0, 0x72, 0x0, 0x0 4. Outfield Core HIL (10) at 0xf0821000, versions 0x9, 0x0, 0x73, 0x0, 0x0 5. Outfield Core RS-232 (10) at 0xf0823000, versions 0x9, 0x0, 0x75, 0x0, 0x0 6. Outfield Core RS-232 (10) at 0xf0822000, versions 0x9, 0x0, 0x75, 0x0, 0x0 7. Outfield Core Centronics (10) at 0xf0824000, versions 0x9, 0x0, 0x74, 0x0, 0x0 8. Outfield FW SCSI (10) at 0xf0830000, versions 0x9, 0x0, 0x7c, 0x0, 0x0 9. Outfield Audio (10) at 0xf1000000, versions 0x9, 0x0, 0x7f, 0x0, 0x0 10. Cobra EISA BA (11) at 0xfc000000, versions 0x4, 0x0, 0x76, 0x0, 0x0 11. Snake Cheetah (735/130) (0) at 0xfffbe000, versions 0x206, 0x0, 0x4, 0x0, 0x81 12. Snake Cheetah (1) at 0xfffbf000, versions 0x37, 0x0, 0x9, 0x0, 0x0 That's a total of 12 devices. CPU(s): 1 x PA7100 (PCX-T) at 125.000000 MHz Linux version 2.4.0-test6 (pjlahaie@elenuial.thepuffingroup.com) (gcc version 2.96 20000925 (experimental)) #32 Mon Nov 6 10:20:58 EST 2000 free_bootmem(0x2daa00, 0x4d25600) initrd: 00000000-00000000 pagetable_init On node 0 totalpages: 20480 zone(0): 10240 pages. zone(1): 10240 pages. zone(2): 0 pages. Kernel command line: ROOT=/ TERM=LINUX root=/dev/scd0 trap_init Calibrating delay loop... 124.52 BogoMIPS Memory: 77468k available Dentry-cache hash table entries: 16384 (order: 5, 131072 bytes) Buffer-cache hash table entries: 4096 (order: 2, 16384 bytes) Page-cache hash table entries: 32768 (order: 5, 131072 bytes) Inode-cache hash table entries: 8192 (order: 4, 65536 bytes) POSIX conformance testing by UNIFIX ASP version 20 at 0xf0800000 found. Found i82596 at 0xf0826000, IRQ 87 early initialization of device eth0 is deferred Found HIL at 0xf0821000, IRQ 94 HIL: no keyboard present. Warning : device (10, 0x9, 0x0, 0x73, 0x0) NOT claimed by HIL 712, 715 or similiar Linux NET4.0 for Linux 2.4 Based upon Swansea University Computer Society NET3.039 NET4: Unix domain sockets 1.0/SMP for Linux NET4.0. NET4: Linux TCP/IP 1.0 for NET4.0 IP Protocols: ICMP, UDP, TCP IP: routing cache hash table of 512 buckets, 4Kbytes TCP: Hash tables configured (established 8192 bind 8192) Starting kswapd v1.7 pty: 256 Unix98 ptys configured lp: driver loaded but no devices found RAMDISK driver initialized: 16 RAM disks of 4096K size 1024 blocksize sim700: Couldn't get consistent shared memory sim700: Configuring 53c700 (SCSI-ID 7) at f0825100, IRQ 86 scsi0: Revision 0x0 Post test1, istat 05, sstat0 00, dstat 84 sim700: WARNING IRQ probe failed, (returned 0) scsi0: WARNING: target data areas are not dma coherent! scsi0: test 1 completed ok. scsi0: sim700_intr_handle() called with no interrupt scsi0 : LASI/Simple 53c7xx scsi : 1 host. Vendor: TOSHIBA Model: CD-ROM XM-3301TA Rev: 1651 Type: CD-ROM ANSI SCSI revision: 02 Detected scsi CD-ROM sr0 at scsi0, channel 0, id 4, lun 0 Vendor: HP Model: C3725S Rev: 6019 Type: Direct-Access ANSI SCSI revision: 02 Detected scsi disk sda at scsi0, channel 0, id 6, lun 0 scsi : detected 1 SCSI cdrom 1 SCSI disk total. Uniform CD-ROM driver Revision: 3.11 SCSI device sda: hdwr sector= 512 bytes. Sectors= 4194058 [2047 MB] [2.0 GB] Partition check: sda: unknown partition table 82596.c: MAC of HP700 LAN blindely read from the prom! eth0: Couldn't get consistent shared memory eth0: 82596 at 0xf0826000, 08 00 09 0B DB EB IRQ 87. 82596.c $Revision: 1.14 $ Serial driver version 5.01 (2000-05-29) with MANY_PORTS SHARE_IRQ SERIAL_PCI enabled Dumping Stack from c4f9c000 to c4f9cbc0: c000 00000000 00000140 00000000 00000000 c027a46c 00000001 00000000 ffffffff c020 00000000 00000000 00000000 00000000 00000000 00000000 ffffffff c027a384 c040 c027a384 c4f90000 c02b0000 c028060c 00000000 00000000 00000000 00000000 c060 00000000 00000000 00000001 00000000 00000000 00000000 00000000 c02b0000 c080 c02b0000 c4f50000 00000000 00000000 00000000 c02c9ab8 00000000 c4f9c09c c0a0 c4f9c09c c4f9c0a4 c011a6e4 c4f9cac8 00000000 00000000 00000000 00000000 c0c0 00000000 00000000 00000000 00000000 00000000 00000000 c4f9c000 c011d4a8 c0e0 00000000 00000037 00000000 00000000 00000024 00000000 0000005b 00000000 c100 00000000 00000000 00000000 00000000 00000000 80000000 00000000 00000000 c120 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 c140 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 c160 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 c180 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 c1a0 00000000 00000000 00000000 00000000 00000000 00000000 00000000 fffffeff c1c0 00000000 ffffffff 00000000 c027afb4 ffffffff ffffffff ffffffff ffffffff c1e0 ffffffff ffffffff 00800000 05000000 00000000 ffffffff ffffffff ffffffff c200 00000500 00000500 00000400 00000400 ffffffff ffffffff ffffffff ffffffff c220 00007377 61707065 72000000 00000000 00000000 00000000 00000000 00000000 c240 00000000 00000000 00005000 c0267054 c0267054 c013d1e8 00010000 c4ffeba0 c260 c02238c4 c0236708 c02d9800 00504d6c 00000000 c011bb88 c0267000 00005000 c280 c0267054 c0267000 0000003e c027a000 00000001 c02b61eb 00000004 c02b61c7 c2a0 00000023 c02b61eb 00000000 00000000 c0100290 0000003e 00000000 00000024 c2c0 0000000b c027a4ac c027a000 08000059 00000000 000000ff 00000060 00000000 c2e0 00000060 00000002 002b2080 00000008 002b50c0 c0266000 00000000 023c3460 c300 c02b08c0 00000001 08000000 00000000 00000000 00000000 00856606 00000000 c320 00000000 00000000 42780000 00000000 431c0000 00000000 4471cccc 00000000 c340 000003c7 00000000 fffffde0 fffffde0 7f7fffff ffffffff 7f7fffff ffffffff c360 00000000 00000000 00000000 00000000 41800000 00000000 00000010 00000010 c380 00000000 00000000 fffffde0 fffffde0 41000000 00000000 40800000 00000000 c3a0 fffffde0 fffffde0 41000000 00000000 fffffde0 fffffde0 40800000 00000000 c3c0 41000000 00000000 40300000 00000000 40200000 00000000 40200000 00000000 c3e0 41800000 fffffde0 40000000 00000000 40000000 00000000 40800000 00000000 c400 41000000 00000000 00000000 00000000 c4f9cb80 c0103cf4 00000000 00000000 c420 00000000 00000000 00000000 00000000 c011bb78 c011bb7c 40800000 00000000 c440 00281000 00000000 c0280040 c0280064 00000000 c0280204 00000000 00000000 c460 00000000 00000000 00000000 c4f9c468 00000000 00000000 00000000 00000000 c480 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 c4a0 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 c4c0 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 c4e0 00000000 00000000 00000000 c0103c48 00000000 00000000 00000000 00000000 c500 c4f9c000 c028060c 00000000 00000000 00000000 00000000 00000000 00000000 c520 00000000 00000000 00000000 c01002a4 00000000 00000000 00000000 00000000 c540 00000000 00000000 00000000 00000000 c02b06c0 c4f9c000 c028060c 00000000 c560 c02b0000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 c580 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 c5a0 00000000 00000000 00000000 c02950a4 00000000 00000000 00000000 00000000 c5c0 00000001 c0284000 00000000 00000000 00000002 c027a4a0 c027a4a0 c0258bbc c5e0 00000000 00000000 00000000 c0294fe8 00000000 00000000 00000000 00000000 c600 00000000 08000059 00000000 00000000 f00012a0 000ff000 000a5a59 000a5a59 c620 c0295794 c02d9800 00504d6c c02cc000 c0266000 c02c8000 c02aed34 c02aed24 c640 c02aed34 c02aed20 00000000 00000000 000ff000 000a5a59 000a5a59 c0295794 c660 c02d9800 00504d6c c02cc000 c029bc3c c02c8000 c02aed34 c02aed04 c02c8000 c680 c02c5fe8 c02c60a4 c028758c 00000040 c0244ed8 c0244a0c c0244b80 c0244edc c6a0 01234567 c4f9c000 00000000 c02a6e64 c4f9c698 00000000 c02cc000 c0266000 c6c0 10000080 c02c5fe8 c02c60a4 c028758c 00000040 c4ffeea0 f00012a0 000ff000 c6e0 000a5a59 000a5a59 c0295794 c0155890 00504d6c c02cc000 c0266000 c02c8000 c700 c02c6164 00000100 c0244c38 00000000 c0245000 00000000 c02c5fe8 c02c5fe8 c720 c01e55ec c028be04 c02c9a20 c0109e74 c4ffc200 c028b474 c4f4a000 c028bf60 c740 00000004 c02aeab4 c02c8d20 c02b621f 00000004 c02b61ca 00000054 c02b621f c760 00000000 00000001 c027a000 c02a6de4 0000003c 00000058 0000000b c027a4ac c780 0000005a c4ff74a0 00000000 000000ff 00000060 00000000 00000060 00000002 c7a0 002b2080 00000008 002b50c0 c019324c 00000000 023c3460 c4f9c980 00000001 c7c0 08000000 00000000 00005301 f0823800 00856606 00000000 00000000 c028478c c7e0 42780000 00000000 431c0000 00000000 4471cccc 00000000 000003c7 00000000 c800 fffffde0 fffffde0 7f7fffff ffffffff 7f7fffff ffffffff 00000000 00000000 c820 00000000 00000000 41800000 00000000 00000010 00000010 f0823800 00000000 c840 00000003 fffffde0 41000000 00000000 40800000 00000000 fffffde0 fffffde0 c860 41000000 00000000 fffffde0 fffffde0 40800000 00000000 41000000 00000000 c880 40300000 00000000 40200000 00000000 40200000 00000000 c018ffb8 c02846d8 c8a0 c02c8800 c026c000 c02c8d20 0000000b c028478c 00000000 41000000 00000000 c8c0 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 c8e0 00000000 00000000 c011bb78 c0192bd4 4471cccc 00000000 000003c7 00000000 c900 0000000a c028478c c4f9c7c8 00000090 00000006 2b6a0000 00000000 00000000 c920 00000000 00000000 41800000 00000000 00000010 00000010 00000000 00000000 c940 fffffde0 fffffde0 41000000 00000000 40800000 00000000 fffffde0 fffffde0 c960 41000000 00000000 fffffde0 c011e9bc 40800000 00000000 41000000 00000000 c980 0004000a c0221800 c011e9f8 c4ff6520 c4ff6200 c0244f10 00000008 f0823800 c9a0 00000003 00000007 c0191568 c02c60a4 fffffffc c0245000 c0245000 c02d72b8 c9c0 c0245000 c0245000 c02c6028 00000000 c4ff6234 f0823807 f0823800 0000000a c9e0 ffffffff c4ff6520 c4ff6200 c0266000 ffffffff 00000340 c4f9cbc0 c012dfc0 ca00 08000000 00000000 00000000 00000000 00856606 00000000 00000000 00000000 ca20 42780000 00000000 431c0000 00000000 4471cccc 00000000 000003c7 00000000 ca40 fffffde0 fffffde0 7f7fffff ffffffff 7f7fffff ffffffff 00000000 00000000 ca60 00000000 00000000 41800000 00000000 00000010 00000010 00000000 00000000 ca80 fffffde0 fffffde0 41000000 00000000 40800000 00000000 fffffde0 fffffde0 caa0 41000000 00000000 fffffde0 fffffde0 40800000 00000000 41000000 00000000 cac0 40300000 00000000 40200000 00000000 40200000 00000000 41800000 fffffde0 cae0 40000000 00000000 40000000 00000000 40800000 00000000 41000000 00000000 cb00 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 cb20 00000000 00000000 c011e710 c011e714 00000000 00000000 00000000 00000000 cb40 00000000 00000058 c4f9c740 c02caac8 00000007 0f881093 00000000 00000003 cb60 c02c9800 c02c9a60 c02c9a20 00000000 00000000 00000400 c4f9cd40 c01d1c98 cb80 0000003c 0000003e c027a000 00000001 c02b61e0 00000004 c02b61c7 00000018 cba0 c02b61e0 00000000 431c0000 c01046e0 4471cccc 00000000 000003c7 00000000 Data access rights fault in kernel: Code=26 regs=c4f9c980 (Addr=00000003) YZrvWESTHLNXBCVMcbcbcbcbOGFRQPDI PSW: 00000000000001000000000000001010 r0-3 00000000 c0221800 c011e9f8 c4ff6520 r4-7 c4ff6200 c0244f10 00000008 f0823800 r8-11 00000003 00000007 c0191568 c02c60a4 r12-15 fffffffc c0245000 c0245000 c02d72b8 r16-19 c0245000 c0245000 c02c6028 00000000 r20-23 c4ff6234 f0823807 f0823800 0000000a r24-27 ffffffff c4ff6520 c4ff6200 c0266000 r28-31 ffffffff 00000340 c4f9cbc0 c012dfc0 sr0-4 00000000 00000000 00000000 00000000 sr4-8 00000000 00000000 00000000 00000000 IASQ: 00000000 00000000 IAOQ: c011e710 c011e714 IIR: 0f881093 ISR: 00000000 IOR: 00000003 ORIG_R28: 00000058 From delyra@latt.if.usp.br Thu, 30 Nov 2000 09:15:11 -0200 (BRST) Date: Thu, 30 Nov 2000 09:15:11 -0200 (BRST) From: Jorge L. deLyra delyra@latt.if.usp.br Subject: [parisc-linux] HP 9000/735-125 > I have a 735-125 and am able to net-boot it on a custom configured kernel as > long as I disable the ASP parallel ports. It works quite well using an NFS > root as I cannot get the SCSI hard drives to mkfs. I was going to try and > debug it but have yet to find the free time. I can e-mail you my working > .config for the kernel, or build kernels (tested on my own 735) for people > if they need them. Well, looks like the problem is known, good! But we have a queer little problem with our machines here, we are unable to boot from the network. I think we did everything right, in fact, we are trying to use a server here other machines boot from, it has dhcp, boopt, tftp, rarp, the works. We set it all up, put the kernel on the tftpboot area, tested all that we could by other means but, when we try to net boot the HPs, we are faced with complete silence on the network. No logs on the server, nothing. A little explanation might be needed: these are not really native 735-125 models, they were upgraded from older 720-50 models by card swapping. I am not sure whether all cards were changed, maybe some aspects of the machine are still old. The syntax of the net boot procedure in them is strange, you have to put in the hardware address of the server, which is unusual. I _suspect_ that this bios does not use tcp/ip for the net boot, but some HP proprietary protocol relating to that clustering software they have or used to have for these machines, in which you ran several stations out of the disks of a single one. In any case, a listing of what happens on the console on a net-boot trial goes below. We had a tail -f on the system log of the server, we had tcpdump listening, but nothing at all shows up... ---------------------------------------------------------------- Jorge L. deLyra, Associate Professor of Physics The University of Sao Paulo, IFUSP-DFMA For more information: finger delyra@latt.if.usp.br ---------------------------------------------------------------- Seyon Copyright (c) 1992-1993 Muhammad M. Saggaf. All rights reserved. Version 2 rev. 20c i586-Linux steve@hammer 05/23/99 20:19:22. Locating Modems... Modem `/dev/ttyS0' is Available. (c) Copyright. Hewlett-Packard Company. 1992. All rights reserved. PDC ROM rev. 2.7 IODC ROM rev. 1.1 80 MB of memory configured and tested. Searching for Potential Boot Devices. To terminate search, press and hold the ESCAPE key. Device Selection Device Path Device Type ---------------------------------------------------------------------------- P0 scsi.6.0 HP C3725S P1 scsi.4.0 TOSHIBA CD-ROM XM-3301TA b) Boot from specified device s) Search for bootable devices a) Enter Boot Administration mode x) Exit and continue boot sequence ?) Help Select from menu: a BOOT_ADMIN> help boot Boot from specified device or path: BOOT IPL boots Initial Program Loader (interactive mode) BOOT boots default boot utility may be one of the following: pri primary path in Stable Storage alt alternate path in Stable Storage Pn Device selection from SEARCH eisa. EISA adapter fwscsi. On-board FASTWIDE SCSI interface lan. Slider-card LAN interface scsi. On-board SCSI interface For more information on boot selection options, type HELP where = eisa, lan, scsi, etc ... BOOT_ADMIN> help lan LAN (IEEE 802.3/Ethernet LAN) Path Specification lan... 12 digit (hex) LAN server address max number of times to try a boot request (0 = default, 255 = infinite) max number of times to try a read request (0 = default, 255 = infinite) Example: to specify LAN address 123456-78ABCD with infinite initialization retries and default I/O retries, lan.123456-78ABCD.255.0 If one or more parameters are not specified, the following defaults will be used: = 000000-000000 = 3 tries = 6 tries BOOT_ADMIN> boot lan.0000f8-01abb1.0.0 Trying lan.0000f8-01abb1.0.0 Failed to initialize lan.0000f8-01abb1.3.0 ENTRY_INIT status = -7 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000008 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 A000800C F0002898 00000000 0800090B DBEB0000 00000000 Searching for Potential Boot Devices. To terminate search, press and hold the ESCAPE key. Device Selection Device Path Device Type ---------------------------------------------------------------------------- P0 scsi.6.0 HP C3725S P1 scsi.4.0 TOSHIBA CD-ROM XM-3301TA b) Boot from specified device s) Search for bootable devices a) Enter Boot Administration mode x) Exit and continue boot sequence ?) Help Select from menu: From rhirst@linuxcare.com Thu, 30 Nov 2000 11:19:30 +0000 Date: Thu, 30 Nov 2000 11:19:30 +0000 From: Richard Hirst rhirst@linuxcare.com Subject: [parisc-linux] HP 9000/735-125 On Thu, Nov 30, 2000 at 08:58:22AM -0200, Jorge L. deLyra wrote: > OK, here goes. I want to congratulate you all on this effort. We have five > of these HP-9000 stations here, quite old by now. They used to be our main > number crunching force. They are wonderfully built hardware in bad need of > a wonderful system on them! |:-) > Serial driver version 5.01 (2000-05-29) with MANY_PORTS SHARE_IRQ SERIAL_PCI enabled > > Dumping Stack from c4f9c000 to c4f9cbc0: This has been reported on 715/50 (Robert Duncan) and 715/75 (me) round about November 15th. At the time I tried a current cvs kernel on my 715/75 and it was even worse (IIRC). I'll have another look at it. Richard From rhirst@linuxcare.com Thu, 30 Nov 2000 11:27:39 +0000 Date: Thu, 30 Nov 2000 11:27:39 +0000 From: Richard Hirst rhirst@linuxcare.com Subject: [parisc-linux] HP 9000/735-125 On Thu, Nov 30, 2000 at 01:20:28AM -0800, Steve Moret wrote: > Now, maybe you can help me identify my SCSI problem. I don't know if it is > because of driver issues or a bad disk (completly likely). Do other people > have the Fast SCSI2 working on their 735s? > > Whenever I do a mke2fs (after partitioning the drive with fdisk ok) it dies. I have a 53c700 on my 715/75, and the driver was having trouble with a CRDOM I attached, so it has some problems. I wrote the driver, but havn't used the 715/75 for a while since latest kernels wouldn't boot for me. I'll get it going again and see if the scsi driver still works. Richard From deller@gmx.de Thu, 30 Nov 2000 13:04:49 +0100 (MET) Date: Thu, 30 Nov 2000 13:04:49 +0100 (MET) From: Helge Deller deller@gmx.de Subject: [parisc-linux] HP 9000/735-125 Hi Steve, > My mistake! I did a full build with todays CVS and parport didn't die. > So > somewhere between the 17th and now parport must have been fixed. I checked in yesterday a modified version of /drivers/parport/parport_gsc.c with an "#if 0 ... #endif" in the code. Could you try to boot again with "#if 1" (search for the text which says something like "enable bidirectional PS/2 mode") and try again ? If this hangs your machine I will implement a better work-around. > > Now, maybe you can help me identify my SCSI problem. I don't know if it > is > because of driver issues or a bad disk (completly likely). I think Richard Hirst can help you much more with your SCSI-problems than me. NB: Does your chassis LEDs work with the new kernel, and if not, could you send me your bootlog (or "dmesg | grep led") ? Greetings, Helge -- Sent through GMX FreeMail - http://www.gmx.net From rbradetich@uswest.net Thu, 30 Nov 2000 07:01:53 -0800 Date: Thu, 30 Nov 2000 07:01:53 -0800 From: Ryan Bradetich rbradetich@uswest.net Subject: [parisc-linux] HP 9000/735-125 "Jorge L. deLyra" wrote: > > I have a 735-125 and am able to net-boot it on a custom configured kernel as > > long as I disable the ASP parallel ports. It works quite well using an NFS > > root as I cannot get the SCSI hard drives to mkfs. I was going to try and > > debug it but have yet to find the free time. I can e-mail you my working > > .config for the kernel, or build kernels (tested on my own 735) for people > > if they need them. > > Well, looks like the problem is known, good! But we have a queer little > problem with our machines here, we are unable to boot from the network. I > think we did everything right, in fact, we are trying to use a server here > other machines boot from, it has dhcp, boopt, tftp, rarp, the works. We > set it all up, put the kernel on the tftpboot area, tested all that we > could by other means but, when we try to net boot the HPs, we are faced > with complete silence on the network. No logs on the server, nothing. > > A little explanation might be needed: these are not really native 735-125 > models, they were upgraded from older 720-50 models by card swapping. I am > not sure whether all cards were changed, maybe some aspects of the machine > are still old. The syntax of the net boot procedure in them is strange, > you have to put in the hardware address of the server, which is unusual. > > I _suspect_ that this bios does not use tcp/ip for the net boot, but some > HP proprietary protocol relating to that clustering software they have or > used to have for these machines, in which you ran several stations out of > the disks of a single one. In any case, a listing of what happens on the > console on a net-boot trial goes below. We had a tail -f on the system log > of the server, we had tcpdump listening, but nothing at all shows up... I believe the 735/755 type machines require rbootd to boot from the network. rbootd is available at: ftp://puffin.external.hp.com/pub/parisc/binaries/tgz/rbootd-2.0-2.tar.gz - Ryan From rhirst@linuxcare.com Thu, 30 Nov 2000 14:03:10 +0000 Date: Thu, 30 Nov 2000 14:03:10 +0000 From: Richard Hirst rhirst@linuxcare.com Subject: [parisc-linux] 715/75 dies in pdc_iodc_read() Hi, My 715/75 no longer boots with cvs kernel. It hangs while searching for devices in PDC firmware, after finding the first device. The beta 0.5 cd kernel gets past this point. The device list is: Searching for devices in PDC firmware... processor hpa 0xfffbe000 an older box... Found devices: 1. Stinger Optional Graphics (10) at 0xf4000000, versions 0x6, 0x0, 0x77, 0x0, 0x0 2. Scorpio Sr. Core BA (11) at 0xf082f000, versions 0x19, 0x0, 0x70, 0x0, 0x0 3. Scorpio Sr. Core SCSI (10) at 0xf0825000, versions 0x19, 0x0, 0x71, 0x0, 0x0 4. Scorpio Sr. Core LAN (802.3) (10) at 0xf0826000, versions 0x19, 0x0, 0x72, 0x0, 0x0 5. Scorpio Sr. Core HIL (10) at 0xf0821000, versions 0x19, 0x0, 0x73, 0x0, 0x0 6. Scorpio Sr. Core RS-232 (10) at 0xf0823000, versions 0x19, 0x0, 0x75, 0x0, 0x0 7. Scorpio Sr. Core RS-232 (10) at 0xf0822000, versions 0x19, 0x0, 0x75, 0x0, 0x0 8. Scorpio Sr. Core Centronics (10) at 0xf0824000, versions 0x19, 0x0, 0x74, 0x0, 0x0 9. Scorpio Sr. Audio (10) at 0xf1000000, versions 0x19, 0x0, 0x7b, 0x0, 0x0 10. Scorpio Sr. EISA BA (11) at 0xfc000000, versions 0x19, 0x0, 0x76, 0x0, 0x0 11. Unknown device (10) at 0xfc001000, versions 0x0, 0x0, 0xfff, 0x0, 0x0 12. Scorpio Sr.(715/75) (0) at 0xfffbe000, versions 0x316, 0x0, 0x4, 0x0, 0x81 13. Scorpio Sr. (1) at 0xfffbf000, versions 0x27, 0x0, 0x9, 0x0, 0x0 That's a total of 13 devices. CPU(s): 1 x PA7100 (PCX-T) at 75.000000 MHz So, with lastest cvs source, it gets in to the loop in really_do_oldhw_inventory(), and first time through pdc_mem_map_hpa() returns r_addr.hpa=0xf4000000 (the Stinger Optional Graphics). Next time round, mod=1, pdc_mem_map_hpa() returns r_addr.hpa=0xf8000000, and the subsequent call to pdc_iodc_read() hangs. I made the code skip the loop where mod=1, and it then goes on to discover all the devices without problems. At power on, the machine reports: Warning: one or more EISA cards could not be configured. Autoselect and search will ignore unconfigured cards. Which I assume relates to an EISA SCSI card in the machine, which I assume is item 11 in the above list. Richard From delyra@latt.if.usp.br Thu, 30 Nov 2000 13:04:46 -0200 (BRST) Date: Thu, 30 Nov 2000 13:04:46 -0200 (BRST) From: Jorge L. deLyra delyra@latt.if.usp.br Subject: [parisc-linux] HP 9000/735-125 > I believe the 735/755 type machines require rbootd to boot from the network. > rbootd is available at: > > ftp://puffin.external.hp.com/pub/parisc/binaries/tgz/rbootd-2.0-2.tar.gz Ah! This is it, then! Had never heard of this beast before. I see it is available for i386, nice, our server is a Pentium. Well, thanks a whole lot for the tip, we are certainly trying this. Well, back to work... ---------------------------------------------------------------- Jorge L. deLyra, Associate Professor of Physics The University of Sao Paulo, IFUSP-DFMA For more information: finger delyra@latt.if.usp.br ---------------------------------------------------------------- From delyra@latt.if.usp.br Thu, 30 Nov 2000 13:49:56 -0200 (BRST) Date: Thu, 30 Nov 2000 13:49:56 -0200 (BRST) From: Jorge L. deLyra delyra@latt.if.usp.br Subject: [parisc-linux] HP 9000/735-125 OK, rbootd is up and running, the station now establishes instantaneous communication with the server. But it says "bad LIF magic" and does not boot. I presume I can't just put the precompiled kernel in there. Since I cannot cross-compile for the time being (bad HP server disk crash) is there a net-boot kernel somewhere that I can download and try? Cheers, ---------------------------------------------------------------- Jorge L. deLyra, Associate Professor of Physics The University of Sao Paulo, IFUSP-DFMA For more information: finger delyra@latt.if.usp.br ---------------------------------------------------------------- From randolph@tausq.org Thu, 30 Nov 2000 08:44:18 -0700 Date: Thu, 30 Nov 2000 08:44:18 -0700 From: Randolph Chung randolph@tausq.org Subject: [parisc-linux] CVS linux Vs. -test10 > Oooh, there's a reason for me to finally get the 712/80 under my desk > to be more than a foot-rest. I'll see what I can do about this. > > Note that the likelihood of Debian releasing woody anytime soon is > vanishingly small, so this dosen't have to happen Right Now. So little faith... :P Let me know what I can do to help.... it takes my dual-400MHz i386 box about an hour to build boot-floopies; i don't even wait to think how long it will take on the 712/80 :-) randolph -- @..@ http://www.TauSq.org/ (----) ( >__< ) ^^ ~~ ^^ From rhirst@linuxcare.com Thu, 30 Nov 2000 16:11:15 +0000 Date: Thu, 30 Nov 2000 16:11:15 +0000 From: Richard Hirst rhirst@linuxcare.com Subject: [parisc-linux] HP 9000/735-125 On Thu, Nov 30, 2000 at 11:27:39AM +0000, Richard Hirst wrote: > On Thu, Nov 30, 2000 at 01:20:28AM -0800, Steve Moret wrote: > > Now, maybe you can help me identify my SCSI problem. I don't know if it is > > because of driver issues or a bad disk (completly likely). Do other people > > have the Fast SCSI2 working on their 735s? > > > > Whenever I do a mke2fs (after partitioning the drive with fdisk ok) it dies. > > > I have a 53c700 on my 715/75, and the driver was having trouble > with a CRDOM I attached, so it has some problems. I wrote the > driver, but havn't used the 715/75 for a while since latest kernels > wouldn't boot for me. I'll get it going again and see if the scsi > driver still works. I got my 715/75 to boot. The scsi driver still has problems with my CDROM drive, but the disk seems ok. I ran mke2fs of a 1Gig partition a few times and then copied 200MB of files from the network to it. Richard From bame@noam.fc.hp.com Thu, 30 Nov 2000 09:18:51 -0700 Date: Thu, 30 Nov 2000 09:18:51 -0700 From: Paul Bame bame@noam.fc.hp.com Subject: [parisc-linux] CVS linux Vs. -test10 = Grant> need "boot floppies" debian package working. We don't need = = Oooh, there's a reason for me to finally get the 712/80 under my desk = to be more than a foot-rest. I'll see what I can do about this. = = Note that the likelihood of Debian releasing woody anytime soon is = vanishingly small, so this dosen't have to happen Right Now. Well yes and no. We want to release parisc-linux sooner than woody will be ready for public stable release, so we'll want to do the boot floppies work sooner than other architectures need it and can probably therefore provide early testing too. Since we aren't going to time travel back to Debian potato, woody boot floppies are increasingly interesting to replace our manual install process (hey at least it's documented!). -P From alan@lxorguk.ukuu.org.uk Thu, 30 Nov 2000 16:10:46 +0000 (GMT) Date: Thu, 30 Nov 2000 16:10:46 +0000 (GMT) From: Alan Cox alan@lxorguk.ukuu.org.uk Subject: [parisc-linux] XFree status > Alan Cox wrote: > > I have a server linked. > Alan - that's Cool! Wow! Its still got its atoms in a twist, so its bombing out in Xnest loading the first font. > > inb/inw/outb/outw and friends are right now null > > functions until I fill them in. Thats not a big deal. Initially I'll probably > > use /dev/port but for speed I hope everyone uses mmio based hardware. > > All HP graphics for PARISC are memory mapped. Both "GSC" and PCI flavors. Yes, but if I want to say put an S3 Trio64 in my A180 and a USB card for keyboard mouse..,, (and yes these are sitting on my desk) > But I'm pretty clueless how linux X server finds/talks to a frame buffer. > For HPUX, the graphics driver supports some ioctl()'s. > Any references to describe how it works for linux? The OS specific X code in XFree86 knows several ways to talk to Linux Memory: 1. Directly mmap()ing /dev/mem or /dev/kmem to get access to the mmio space of the card and frame buffer memory. 2. Mapping the pci space via a kernel frame buffer device (/dev/fb*) 3. Arbitary other mmap based code that you plug into it (harder to do) I/O 1. Use of iopl/ioperm on x86 2. Use of mmap to map the PCI I/O space regions on different platforms (which doesnt work on some PA kit) 3. Arbitary other code we plug into it For I/O it seems that on things like the A180 the only way to do it is to use /dev/port and pread/pwrite the file handle for each port I/O. This is slow but hopefully primarily used for booting the card (XFree 4.0 has a X86 emulator for booting the BIOS firmware on PCI cards) For most machines I imagine we would be using mmio and the /dev/fb interface. Alan From alan@lxorguk.ukuu.org.uk Thu, 30 Nov 2000 16:16:18 +0000 (GMT) Date: Thu, 30 Nov 2000 16:16:18 +0000 (GMT) From: Alan Cox alan@lxorguk.ukuu.org.uk Subject: [parisc-linux] CVS linux Vs. -test10 > Oooh, there's a reason for me to finally get the 712/80 under my desk > to be more than a foot-rest. I'll see what I can do about this. > > Note that the likelihood of Debian releasing woody anytime soon is > vanishingly small, so this dosen't have to happen Right Now. My experiences with building Red Hat 7 so far are mostly good. I don't think there will be many actual changes needed to build Debian packages either. I've made very little that isnt 'use -fPIC' 'dont optimise C++' From marteaut@esiee.fr Thu, 16 Nov 2000 21:16:22 +0100 Date: Thu, 16 Nov 2000 21:16:22 +0100 From: Thomas Marteau marteaut@esiee.fr Subject: [parisc-linux] Troubles with read only file system Hi all, We have done everything well but the NFSroot and the bootable disk say that we have a read only file system ??? What is the recipe for making a bootable disk because ours can not be the good one... Thanks, Thomas From marteaut@esiee.fr Fri, 17 Nov 2000 17:59:14 +0100 Date: Fri, 17 Nov 2000 17:59:14 +0100 From: Thomas Marteau marteaut@esiee.fr Subject: [parisc-linux] Trouble with new STI This is a multi-part message in MIME format. ------=_NextPart_000_000F_01C050C0.18E3D060 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi all, We've tried the new STI driver and our 712 dies with this message: Kernel Panic: VFS: Unable to mount root fs on 01:00 We tried with Ramdisk, nfs and hard disk support and always the same = end. Also, the death happens when you 've passed bootp request... Help! Thomas ------=_NextPart_000_000F_01C050C0.18E3D060 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi all,
 
We've tried the new STI driver and our = 712 dies=20 with this message:
 
Kernel Panic: VFS: Unable to mount root = fs on=20 01:00
 
We tried with Ramdisk, nfs and hard = disk support=20 and always the same end.
Also, the death happens when you 've = passed bootp=20 request...
 
Help!
 
Thomas
------=_NextPart_000_000F_01C050C0.18E3D060-- From marteaut@esiee.fr Sun, 19 Nov 2000 13:08:45 +0100 Date: Sun, 19 Nov 2000 13:08:45 +0100 From: Thomas Marteau marteaut@esiee.fr Subject: [parisc-linux] Booting 712 STI and nfs This is a multi-part message in MIME format. ------=_NextPart_000_0047_01C05229.D8DA5D20 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi all, We managed to boot on the STI-console with a 712/80 in changing the = parameters in inittab and in securetty (if you want to login as root).=20 > cat inittab (! just the interesting thing!) # /sbin/getty invocations for the runlevels. # # The "id" field MUST be the same as the last # characters of the device (after "tty"). # # Format: # ::: 1:2345:respawn:/sbin/getty 38400 tty1 #2:23:respawn:/sbin/getty 38400 tty2 #3:23:respawn:/sbin/getty 38400 tty3 #4:23:respawn:/sbin/getty 38400 tty4 #5:23:respawn:/sbin/getty 38400 tty5 #6:23:respawn:/sbin/getty 38400 tty6 =20 > cat securetty # /etc/securetty: list of terminals on which root is allowed to login. # See securetty(5) and login(1). ttyS0 tty1 Also, in order to boot with the STI console, you need to have the module = for STI-console and not for serial console support... But, we have troubles with the rpc that print somestimes nfs: server X.X.X.165 not responding, still trying nfs: server X.X.X.165 OK nfs: server X.X.X.165 not responding, still trying nfs: server X.X.X.165 OK nfs: server X.X.X.165 not responding, still trying nfs: server X.X.X.165 OK We don't understand where comes from the problem!! Bye, ESIEE Port Team ------=_NextPart_000_0047_01C05229.D8DA5D20 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi all,
 
We managed to boot on the STI-console = with a 712/80=20 in changing the parameters in inittab and in securetty (if you want to = login as=20 root).
 
> cat inittab (! just the = interesting=20 thing!)
# /sbin/getty invocations for the=20 runlevels.
#
# The "id" field MUST be the same as the last
# = characters=20 of the device (after "tty").
#
# Format:
# =20 <id>:<runlevels>:<action>:<process>
1:2345:res= pawn:/sbin/getty=20 38400 tty1
#2:23:respawn:/sbin/getty 38400 = tty2
#3:23:respawn:/sbin/getty=20 38400 tty3
#4:23:respawn:/sbin/getty 38400 = tty4
#5:23:respawn:/sbin/getty=20 38400 tty5
#6:23:respawn:/sbin/getty 38400 tty6
 
 
 
> cat securetty
# /etc/securetty: list of terminals on = which root=20 is allowed to login.
# See securetty(5) and=20 login(1).
ttyS0
tty1
 
Also, in order to boot with the STI = console, you=20 need to have the module for STI-console and not for serial console=20 support...
 
But, we have troubles with the rpc that = print=20 somestimes
nfs: server X.X.X.165 not responding, = still=20 trying
nfs: server X.X.X.165 OK
nfs: server X.X.X.165 not responding, = still=20 trying
nfs: server X.X.X.165 OK
nfs: server X.X.X.165 not responding, = still=20 trying
nfs: server X.X.X.165 OK
We don't understand where comes from the problem!!
 
Bye,
ESIEE Port Team
------=_NextPart_000_0047_01C05229.D8DA5D20-- From marteaut@esiee.fr Mon, 20 Nov 2000 15:32:55 +0100 Date: Mon, 20 Nov 2000 15:32:55 +0100 From: Thomas Marteau marteaut@esiee.fr Subject: [parisc-linux] A new file system This is a multi-part message in MIME format. ------=_NextPart_000_0009_01C05307.27222700 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi all, Since we have the STI, we have produced a file system quite = interesting for the 712. You can have a network support till you configure the file.conf like resolv... = Also, we have noticed that the sti on B180 does not work well, it look like it can not find the = rom. But we have to work on... To download the archives go there: http://www.esiee.fr/~djoudim/code/suitable.html It is incredible what can do a 712 with it! Bye, ESIEE Port Team ------=_NextPart_000_0009_01C05307.27222700 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi all,
 
    Since we have the = STI, we have=20 produced a file system quite interesting for the 712. You = can
have a network support till you = configure the=20 file.conf like resolv... Also, we have noticed that
the sti on B180 does not work well, it = look like it=20 can not find the rom. But we have to work on...
 
To download the archives go = there:
http://www.esiee= .fr/~djoudim/code/suitable.html
 
It is incredible what can do a 712 with = it!
 
Bye,
ESIEE Port Team
------=_NextPart_000_0009_01C05307.27222700-- From kailasr@webcash.com Tue, 31 Oct 2000 12:58:41 -0800 Date: Tue, 31 Oct 2000 12:58:41 -0800 From: Kailashnath V Rampure kailasr@webcash.com Subject: [parisc-linux] unable to run palo on nfs root Hi Paul, After booting the Server from NFSroot I need to Initialize the harddisk on the server. so I copied the palo and linux in to the nfsroot. I am trying to Run the following command: $ palo -I -k /boot/vmlinux -b /boot/iplboot -c '2/boot/vmlinux TERM=linux HOME=/ root=/dev/sda2' /dev/sda fisrt partition is 10M of type f0 second partition is /dev/sda2 of type linux native. Third partition is /dev/sda3 of type linux Swap Then I get the cannot execute binary file. second question is that what is the Terminal type I should set as I am unable to open vi. Please suggest the correct steps. Thanks. Kailas At 09:54 AM 10/31/00 -0700, Paul Bame wrote: >= Hi, >= >= I have booted HP A class server from nfsroot. but when I try to run palo on >= the server to initialize boot loader to the hdd I get >= "cannot execute the binary file" >= >= can any one help me to make the hdd bootable > >It would help me to see the actual command you used and the actual >error message(s) printed. With the info you give so far it could be >"a million" things. > > -P From bame@noam.fc.hp.com Tue, 31 Oct 2000 14:26:00 -0700 Date: Tue, 31 Oct 2000 14:26:00 -0700 From: Paul Bame bame@noam.fc.hp.com Subject: [parisc-linux] NEW NATIVE PALO TARBALL - REQUIRED = Hi Paul, = = After booting the Server from NFSroot I need to Initialize the harddisk on = the server. so I copied the palo and linux in to the nfsroot. I am trying = to Run the following command: = $ palo -I -k /boot/vmlinux -b /boot/iplboot -c '2/boot/vmlinux TERM=linux = HOME=/ root=/dev/sda2' /dev/sda = fisrt partition is 10M of type f0 = second partition is /dev/sda2 of type linux native. = Third partition is /dev/sda3 of type linux Swap That looks great. = Then I get the cannot execute binary file. Ok I think we changed the kernal such that the old palo bits won't run any more (we removed the old gateway page). I uploaded a new version: ftp://puffin.external.hp.com/pub/parisc/binaries/userspace/palo-200001031.tgz -P From grundler@cup.hp.com Tue, 31 Oct 2000 13:53:04 -0800 Date: Tue, 31 Oct 2000 13:53:04 -0800 From: Grant Grundler grundler@cup.hp.com Subject: [parisc-linux] unable to run palo on nfs root Kailashnath V Rampure wrote: > fisrt partition is 10M of type f0 > second partition is /dev/sda2 of type linux native. > Third partition is /dev/sda3 of type linux Swap Kailashnath, Even though your partitioning should work fine, you really want the swap on the lowest numbered SCSI block you can get away with. Several reasons for this: o lowest block number is on the outside of the SCSI disk were data xfer rate is typically 80% faster than the inside. (someday try "time dd if=/dev/sda of=/dev/null bs=8k count=50" with and with out skip parameter). o Eventualy we will have kernel dumps to swap space - and IODC will likely have the same limitations where on the disk dump can be as we have with booting from a disk (as discussed in the PALO documentation). grant Grant Grundler Unix Systems Enablement Lab +1.408.447.7253 From taggart@carmen.fc.hp.com Tue, 31 Oct 2000 16:16:09 -0700 Date: Tue, 31 Oct 2000 16:16:09 -0700 From: Matt Taggart taggart@carmen.fc.hp.com Subject: [parisc-linux] New cross-compiler I have placed a new i386-linux -> hppa32/64-linux cross compiler (with 32bit glibc) in, ftp://puffin.external.hp.com/pub/parisc/binaries/LinuxX86/xc-20001031.tar.gz It includes Alan Modra's recent fix for the 64 bit compiler, http://puffin.external.hp.com/mailing-lists/parisc-linux-cvs/2000/10-Oct/0233.h tml -- Matt Taggart taggart@fc.hp.com From pdbeal@bealz.net Tue, 31 Oct 2000 18:43:06 -0500 Date: Tue, 31 Oct 2000 18:43:06 -0500 From: Phillip Beal pdbeal@bealz.net Subject: [parisc-linux] 735 and Thin Lan Hey, I've obtained two HP 735's and I'd like to try the linus port on them. I have compiled a kernel, but it never boots the nfsroot disk. It has the same problem that the HP 755 that I've worked with. However, it has a different ethernet connection. The 735 has a thin lan connection. What network device should be used in the kernel to be able to use the thin lan adapter? Here's the info on the Thin lan: Outfield Core LAN (802.3) (10) at 0xf0826000 versions 0x9, 0x0, 0x72, 0x0, 0x0 Thanks, -- Phillip Beal S+LUG Vice-President From deller@gmx.de Wed, 1 Nov 2000 00:57:22 +0100 Date: Wed, 1 Nov 2000 00:57:22 +0100 From: Helge Deller deller@gmx.de Subject: [parisc-linux] 735 and Thin Lan On Wednesday 01 November 2000 00:43, Phillip Beal wrote: > Hey, > > I've obtained two HP 735's and I'd like to try the linus port on them. > I have compiled a kernel, but it never boots the nfsroot disk. It has > the same problem that the HP 755 that I've worked with. However, it has > a different ethernet connection. The 735 has a thin lan connection. > What network device should be used in the kernel to be able to use the > thin lan adapter? Here's the info on the Thin lan: > > Outfield Core LAN (802.3) (10) at 0xf0826000 versions 0x9, 0x0, 0x72, > 0x0, 0x0 > > Thanks, > Phillip Beal > S+LUG Vice-President Hi Phillip, I think the "Lasi ethernet"-driver (enabled by default in our configuration) should work on both of your boxes. Helge. From deller@gmx.de Wed, 1 Nov 2000 01:45:52 +0100 Date: Wed, 1 Nov 2000 01:45:52 +0100 From: Helge Deller deller@gmx.de Subject: [parisc-linux] The new PS/2 Keyboard Driver On Friday 27 October 2000 01:50, Helge Deller wrote: > On Thursday 26 October 2000 22:05, Thomas Marteau wrote: > > > > > > Hello everyone, > > > > We've just updated the PS/2 keyboard driver. The leds and interrupt > > functions work really well on a 712 workstation and also B132 now. The > > updated driver files are available on our website. It works better than > > under HP UX for the B 132 ;-> > > > > http://www.esiee.fr/~djoudim > > > > The ESIEE Port Team in Paris. > > > > Here is the patch: > > > > diff -urN linux/drivers/char/gsc_ps2.c linux-parisc/drivers/char/gsc_ps2.c > > --- linux/drivers/char/gsc_ps2.c Thu Oct 26 21:06:54 2000 > > +++ linux-parisc/drivers/char/gsc_ps2.c Thu Oct 26 21:34:00 2000 > > @@ -7,6 +7,11 @@ > > [.............] > > > diff -urN linux/drivers/char/keyb_at.c linux-parisc/drivers/char/keyb_at.c > > --- linux/drivers/char/keyb_at.c Thu Oct 26 21:07:00 2000 > > +++ linux-parisc/drivers/char/keyb_at.c Thu Oct 26 21:23:16 2000 > > [........] > > Hi Thomas, > > Thanks for your patch. > But I don't think it's a good idea to change a common file like keyb_at.c, > which is used in most other arches too. This patch surely breaks their > keyboard support and more than that I'm sure, that Linus will not accept this > patch, when the time is come to integrate parisc into the official kernel. > > Isn't there any other solution as for example to #ifdef the code or create a > new keyb_at.c for parisc (Yes I know, both of those aren't clean too.) ? > > Helge Deller Hi folks, I need to correct myself on this topic. The ESIEE-team made a great patch and didn't changed any globally used file. keyb_at.c is just used in the current parisc-port, and so it's ok to change that file. I just committed their changes to the CVS, and in the same cycle tried to clean up the code. In the same step I renamed the original filenames to some hopefully better ones. Since I don't own myself a real HP PS/2 keyboard (it's just an PC-AT one with a small DIN to PS/2-connector), it would be great to get some feedback if I did the Right Thing. Helge. From bri@mojo.calyx.net Wed, 1 Nov 2000 02:48:02 -0500 (EST) Date: Wed, 1 Nov 2000 02:48:02 -0500 (EST) From: Brian S. Julin bri@mojo.calyx.net Subject: [parisc-linux] The new PS/2 Keyboard Driver Probably best not to worry about cleaning keyboard drivers up too much. The current USB code will be followed by linux-input style drivers at some point. In fact I started a HIL linux-input style driver, which would abstract the PS2 port/HIL ports and allow a standard keyboard module to be hooked into the abstracted serio port. I will work on it more when time permits. -- Brian S. Julin From jsm@udlkern.fc.hp.com Wed, 1 Nov 2000 02:37:58 -0700 (MST) Date: Wed, 1 Nov 2000 02:37:58 -0700 (MST) From: John Marvin jsm@udlkern.fc.hp.com Subject: Elf Header change proposal Paul and Alan pointed out that I goofed. I analyzed the vmlinux in my 64 bit build area to get the current flags, but it turns out that the vmlinux I looked at was a 32 bit version. I had recently made some 64 bit checkins, and I like to rebuild everything for 32 bit before doing that, to make sure that I haven't broken the 32 bit path by making 64 bit changes. So, the bad news is that I wasted time writing an unecessarily long design proposal. The good news is that the only thing that needs to change is value in the e_ident[EI_OSABI] field, so that we can differentiate 64 bit HP-UX binaries from 64 bit Linux binaries. We should also change the field for 32 bit Linux also. John From jsm@udlkern.fc.hp.com Wed, 1 Nov 2000 03:35:49 -0700 (MST) Date: Wed, 1 Nov 2000 03:35:49 -0700 (MST) From: John Marvin jsm@udlkern.fc.hp.com Subject: space registers Matthew Wilcox wrote: > a small optimisation just occurred to me. > > right now, when we switch to kernel space, we set all of sr4-sr7 to 0 > (for the kernel mapping). we don't need to do that since the kernel is > entirely in sr7's domain. this has the added bonus that badly written > drivers which blindly dereference userspace pointers will work on > parisc as well as x86. we can also lazily restore sr4-6 on exit from > kernel space if we're switching back to the same task which called us. > this optimisation may not be worthwhile, but i think setting sr4-6 > on entry to the kernel is unnecessary. True for now. But it won't always be true. It is a desired goal to be able to support large (~3.5 Gb) physical memory for the 32 bit port. To do this we will move the kernel down to around virtual address 0, so the kernel address space will then be controlled by sr4, and depending on the amount of physical memory in the machine, possibly sr5, sr6, and sr7. We could do this based on a test of the amount of physical memory in the machine, but once you load something from memory to do the test, and then actually do the test, you wouldn't have any advantage over just writing zero's to the space registers. This might be worth considering for the 64 bit port, since both the kernel and user space will reside entirely within the linear address space covered by sr4 (We would have to go to a 1 Mb page size to be able to support greater than a 62 bit address space with three level page tables). sr5,sr6, and sr7 will only be used when we are running 64 bit HP-UX processes (with its address space broken up into 4 segments). Note that since we just store the users space in sr3 while we are in the kernel, its not clear that any kind of test with a branch would be a performance gain, especially if it required that we load something from memory to do that test. We may be able cover this by managing sr5, sr6 and sr7 only in the HP-UX specific parts of the syscall path. John From alan@linuxcare.com.au Thu, 2 Nov 2000 00:11:11 +1100 (EST) Date: Thu, 2 Nov 2000 00:11:11 +1100 (EST) From: Alan Modra alan@linuxcare.com.au Subject: Elf Header change proposal On Wed, 1 Nov 2000, John Marvin wrote: > So, the bad news is that I wasted time writing an unecessarily long > design proposal. The good news is that the only thing that needs to > change is value in the e_ident[EI_OSABI] field, so that we can > differentiate 64 bit HP-UX binaries from 64 bit Linux binaries. > We should also change the field for 32 bit Linux also. Some other bad news is that the change isn't quite trivial, due to not wishing to break other bfd targets. The good new is I've made the change. Compiling at the moment. Alan Modra -- Linuxcare. Support for the Revolution. From bame@noam.fc.hp.com Wed, 01 Nov 2000 10:59:34 -0700 Date: Wed, 01 Nov 2000 10:59:34 -0700 From: Paul Bame bame@noam.fc.hp.com Subject: [parisc-linux] new method for 64-bit parisc tree I want to propose/discuss a new method for maintaining our 64-bit parisc tree in relation to the 32-bit tree. I have prototyped this and so far it seems pretty useful. Most of the files in the current parisc64 tree only contain one line, a #include of the same file from the parisc tree. This confuses 'make dep', causes some compile errors to have nonsense line numbers, and doesn't allow direct editing of the source files in the parisc64 tree. The method I'm proposing works like this: The future parisc64 tree ONLY contains files which are different from, or in addition to, those in the parisc tree. When you 'make config' or 'make oldconfig', each file in the parsic tree is symbolically linked as the same file in the parisc64 tree. This enables all the rest of the tools/build to work normally. 'make distclean' includes a step to remove all the symlinks. The ugliest "feature" is that even though you can edit source files in the parisc64 tree, 'cvs commit' will fail on those which are symbolic links. To reduce this problem, I'm dropping a symbolic link called '...' in each parisc64 directory which is a pointer to the corresponding parisc directory, so 'cd ...; cvs commit foo.c' will work and not be too onerous. We should additionally consider a naming convention or something so that maintainers in the parisc tree know whether files are shared with parisc64 or not. I prototyped this as a fictional new "architecture" called "p64". To try it out, grab the tarball (only about 30 files -- can be fewer) ftp://puffin.external.hp.com/pub/parisc/ and unpack in your top-level linux source tree directory. Then in your top-level Makefile, change ARCH := parisc64 to ARCH := p64, then make oldconfig or whatever you usually do. Let me know of any problems. Is this something we should adopt for the real parisc64 tree? -Paul Bame From kailasr@webcash.com Wed, 01 Nov 2000 12:30:40 -0800 Date: Wed, 01 Nov 2000 12:30:40 -0800 From: Kailashnath V Rampure kailasr@webcash.com Subject: [parisc-linux] NEW NATIVE PALO TARBALL - REQUIRED Thanks paul I was able to run the command. Can you let me know what I should type at ISL prompt as its trying to boot from /stand/vmunix instead of /boot/vmlinux. Also I am unable to open vi as it says vi:LINUX:unknown terminal type. Please suggest. Regards At 02:26 PM 10/31/00 -0700, Paul Bame wrote: >= Hi Paul, >= >= After booting the Server from NFSroot I need to Initialize the harddisk on >= the server. so I copied the palo and linux in to the nfsroot. I am trying >= to Run the following command: >= $ palo -I -k /boot/vmlinux -b /boot/iplboot -c '2/boot/vmlinux TERM=linux >= HOME=/ root=/dev/sda2' /dev/sda >= fisrt partition is 10M of type f0 >= second partition is /dev/sda2 of type linux native. >= Third partition is /dev/sda3 of type linux Swap > >That looks great. > >= Then I get the cannot execute binary file. > >Ok I think we changed the kernal such that the old palo bits won't run >any more (we removed the old gateway page). I uploaded a new version: >ftp://puffin.external.hp.com/pub/parisc/binaries/userspace/palo-200001031.tgz > > -P From matthew@wil.cx Thu, 2 Nov 2000 00:13:06 +0000 Date: Thu, 2 Nov 2000 00:13:06 +0000 From: Matthew Wilcox matthew@wil.cx Subject: linux bame On Wed, Nov 01, 2000 at 01:53:24PM -0700, Paul Bame wrote: > CVSROOT: /home/cvs/parisc > Module name: linux > Changes by: bame 00/11/01 13:53:24 > > Modified files: > include/asm-parisc64: posix_types.h > > Log message: > Don't need a separate copy of this one either err.. are you sure? we used to get a lot of prototype problems when they were the same file. what's changed that they're now able to be the same? -- Revolutions do not require corporate support. From bame@riverrock.org Wed, 01 Nov 2000 23:18:43 -0700 Date: Wed, 01 Nov 2000 23:18:43 -0700 From: bame@riverrock.org bame@riverrock.org Subject: linux bame = On Wed, Nov 01, 2000 at 01:53:24PM -0700, Paul Bame wrote: = > CVSROOT: /home/cvs/parisc = > Module name: linux = > Changes by: bame 00/11/01 13:53:24 = > = > Modified files: = > include/asm-parisc64: posix_types.h = > = > Log message: = > Don't need a separate copy of this one either = = err.. are you sure? we used to get a lot of prototype problems when they = were the same file. what's changed that they're now able to be the same? I changed the parisc version so that the data types would compile to the same size in both wide and narrow mode. Unfortunately there is at least one issue which will probably require this scheme to change :-( -P From grundler@cup.hp.com Thu, 2 Nov 2000 00:21:36 -0800 (PST) Date: Thu, 2 Nov 2000 00:21:36 -0800 (PST) From: Grant Grundler grundler@cup.hp.com Subject: [parisc-linux] a500.out16 Hi Richard (et al), I finally think I understand how pcibios_align_resource() is used... that definitely was the problem. Everything on A500 but PCI-PCI bridge seems to be assigned I/O port and MMIO addresses correctly. I'll look at tulip code tomorrow to see why it's not happy. 6 Tulips are behind PCI-PCI Bridges and that's part of the problem. But the complaints about "MMIO resource" list I/O Port addresses instead...and those look fine to me if they are treated like I/O port addresses... I'd also like to connect some more SCSI disks....but any clue what the "CACHE TEST FAILED" is about? But instead of putting out another tar ball, I'm committing my code. I haven't tested on c3k/j5k yet and it might be broken. 32-bit still builds and any fix should be simple - either cvs update back to an older date or put "if (pdc_pat) { }" around anything that I added that shouldn't be. Tell me to test/fix any brokeness you might find and I'll make time to do it. aplogies for the long delay, grant Firmware Version 40.32 Duplex Console IO Dependent Code (IODC) revision 1 ------------------------------------------------------------------------------ (c) Copyright 1995-1998, Hewlett-Packard Company, All rights reserved ------------------------------------------------------------------------------ Processor Speed State CoProcessor State Cache Size Number State Inst Data --------- -------- --------------------- ----------------- ------------ 0 440 MHz Active Functional 512 KB 1 MB 1 440 MHz Idle Functional 512 KB 1 MB Central Bus Speed (in MHz) : 111 Available Memory : 262144 KB Good Memory Required : 11468 KB Primary boot path: 0/0/1/1.15 Alternate boot path: 0/0/2/1.15 Console path: 0/0/4/0.0 Keyboard path: 0/0/4/0.0 WARNING: The non-destructive test bit was set, so memory was not tested destructively. Information only, no action required. ---- Main Menu --------------------------------------------------------------- Command Description ------- ----------- BOot [PRI|ALT|] Boot from specified path PAth [PRI|ALT] [] Display or modify a path SEArch [DIsplay|IPL] [] Search for boot devices COnfiguration menu Displays or sets boot values INformation menu Displays hardware information SERvice menu Displays service commands DIsplay Redisplay the current menu HElp [|] Display help for menu or command RESET Restart the system ---- Main Menu: Enter command or menu > bo lan Interact with IPL (Y, N, or Cancel)?> n Booting... Network Station Address 00306e-03799f System IP Address 15.8.80.78 Server IP Address 15.8.81.247 Boot IO Dependent Code (IODC) revision 2 HARD Booted. palo ipl grundler@hpisp747 Tue Oct 31 16:45:27 PST 2000 0/vmlinux 2708507 bytes @ 0x6800 0/palo-cmdline '0/vmlinux HOME=/ TERM=linux root=/dev/nfs nfsroot=15.8.81.247:/tftpboot/hppa64 ' Kernel: partition 0 file /vmlinux ELF64 executable Entry 00100000 first 00100000 n 4 Segment 0 load 00100000 size 1705408 mediaptr 0x1000 Segment 1 load 002a2000 size 407616 mediaptr 0x1a2000 Segment 2 load 00308000 size 131960 mediaptr 0x206000 Segment 3 load 0032c000 size 16384 mediaptr 0x227000 branching to kernel entry point 0x00100000 Set default PSW W bit to 1 PDC Console Initialized The 64-bit Kernel has started... Enabled FP coprocessor If this is the LAST MESSAGE YOU SEE, you're probably using 32-bit millicode by mistake. Free memory starts at: 0xc0371000 start_parisc(0x504d40,0x504d40,0x0,0x0) PALO command line: 'HOME=/ TERM=linux root=/dev/nfs nfsroot=15.8.81.247:/tftpboot/hppa64 ' PALO initrd 0-0 model 00005cb0 00000491 00000000 00000001 23355fdc 100000f0 00000008 000000b2 000000b2 vers 00000300 cpuid 0000022a CPUID vers 17 rev 10 Searching for devices in PDC firmware... processor hpa 0xfffffffffffa0000 CELL_GET_NUMBER: 0x0 0x1 PAT_ENTITY_PROC: id_eid 0xa0ff0000 PAT_ENTITY_PROC: id_eid 0xa2ff0000 PAT_ENTITY_MEM: amount 0x10000000 min_gni_base 0x0 min_gni_len 0x0 PAT_ENTITY_SBA: ranges 6 0: 0xc000000000000005 0xfffffffffed18000 0xfffffffffed2ffff 1: 0x8000000000000000 0x0000000000000000 0x000000000000003f 2: 0x8000000000000001 0xfffffffff8000000 0xfffffffffbffffff 3: 0x00040000001a1701 0xfffffffff0000000 0xfffffffff7ffffff 4: 0x00040000001a1701 0xfffffffffc000000 0xfffffffffecfffff 5: 0x8000000000000002 0xfffffff800000000 0xfffffffbffffffff PAT_ENTITY_LBA: ranges 4 0: 0x8000000000000000 0x0000000000000000 0x0000000000000007 1: 0x8000000000000001 0xfffffffff8000000 0xfffffffff87fffff 2: 0x8000000000000002 0xfffffff804000000 0xfffffff87fffffff 3: 0x8000000000000004 0xfffffff800000000 0xfffffff803ffffff PAT_ENTITY_LBA: ranges 4 0: 0x8000000000000000 0x0000000000000010 0x0000000000000017 1: 0x8000000000000001 0xfffffffff9000000 0xfffffffff97fffff 2: 0x8000000000000002 0xfffffff904000000 0xfffffff97fffffff 3: 0x8000000000000004 0xfffffff900000000 0xfffffff903ffffff PAT_ENTITY_LBA: ranges 4 0: 0x8000000000000000 0x0000000000000020 0x0000000000000027 1: 0x8000000000000001 0xfffffffffa000000 0xfffffffffa7fffff 2: 0x8000000000000002 0xfffffffa04000000 0xfffffffa7fffffff 3: 0x8000000000000004 0xfffffffa00000000 0xfffffffa03ffffff PAT_ENTITY_LBA: ranges 4 0: 0x8000000000000000 0x0000000000000030 0x0000000000000037 1: 0x8000000000000001 0xfffffffffb000000 0xfffffffffb7fffff 2: 0x8000000000000002 0xfffffffb04000000 0xfffffffb7fffffff 3: 0x8000000000000004 0xfffffffb00000000 0xfffffffb03ffffff Found devices: 1. Crescendo 440 (0) at 0xfffffffffffa0000, versions 0x5cb, 0x0, 0x4, 0x0, 0x91 2. Crescendo 440 (0) at 0xfffffffffffa2000, versions 0x5cb, 0x0, 0x4, 0x0, 0x91 3. Crescendo Memory (1) at 0xfffffffffed08000, versions 0x9b, 0x0, 0x9, 0x0, 0x0 4. Astro BC Runway Port (12) at 0xfffffffffed00000, versions 0x582, 0x0, 0xb, 0x0, 0x10 5. Elroy PCI Bridge (13) at 0xfffffffffed30000, versions 0x782, 0x0, 0xa, 0x0, 0x0 6. Elroy PCI Bridge (13) at 0xfffffffffed34000, versions 0x782, 0x0, 0xa, 0x0, 0x0 7. Elroy PCI Bridge (13) at 0xfffffffffed38000, versions 0x782, 0x0, 0xa, 0x0, 0x0 8. Elroy PCI Bridge (13) at 0xfffffffffed3c000, versions 0x782, 0x0, 0xa, 0x0, 0x0 That's a total of 8 devices. CONFIG_SMP disabled - not claiming addional CPUs Warning : device (0, 0x5cb, 0x0, 0x4, 0x0) NOT claimed by CPU PARISC CPU(s): 1 x PA8500 (PCX-W) at 440.000000 MHz Linux version 2.4.0-test6 (grundler@hpisp747) (gcc version 2.96 20000925 (experimental)) #73 Wed Nov 1 23:58:51 PST 2000 free_bootmem(0x373000, 0xfc8d000) initrd: 00000000-00000000 pagetable_init On node 0 totalpages: 65536 zone(0): 32768 pages. zone(1): 32768 pages. zone(2): 0 pages. Kernel command line: HOME=/ TERM=linux root=/dev/nfs nfsroot=15.8.81.247:/tftpboot/hppa64 trap_init Calibrating delay loop... 878.18 BogoMIPS kernel BUG at page_alloc.c:106! Memory: 248868k available Dentry-cache hash table entries: 32768 (order: 7, 524288 bytes) Buffer-cache hash table entries: 16384 (order: 5, 131072 bytes) Page-cache hash table entries: 65536 (order: 7, 524288 bytes) Inode-cache hash table entries: 16384 (order: 6, 262144 bytes) POSIX conformance testing by UNIFIX lba version TR4.0 (0x5) found at 0xfffffffffed30000 0: 0x8000000000000000 PA 0x0000000000000000,0x0000000000000007 IO 0x0000000000000000,0x0000000000000007 1: 0x8000000000000001 PA 0xfffffffff8000000,0xfffffffff87fffff IO 0x00000000f8000000,0x00000000f87fffff 2: 0x8000000000000002 PA 0xfffffff804000000,0xfffffff87fffffff IO 0x000000f804000000,0x000000f87fffffff lba range[2] : ignoring GMMIO (0xfffffff804000000) 3: 0x8000000000000004 PA 0xfffffff800000000,0xfffffff803ffffff IO 0x000000f800000000,0x000000f803ffffff lba_fixup_bus(0x00000000cffe60c0) bus 0 sysdata 0x00000000cffe9e80 cons 0x00002000 boot 0x00000000 kbd 0x00002000 claimed 00:00 0 [0,7f]/101 claimed 00:00 1 [fffffffff8020000,fffffffff80203ff]/200 claimed 00:20 0 [fffffffff8000000,fffffffff8000fff]/200 LBA PIOP resource tree 00000000cffe9ed0 [0,7ffff]/100 00000000cffe5080 [0,7f]/101 LBA pcibios_size_bridges() LBA pci_assign_unassigned_resources() pcibios_update_resource(00:08, ..., 0) [100,1ff]/101 pcibios_update_resource(00:08, ..., 1) [fffffffff8001000,fffffffff80013ff]/204 PCI: dev PCI device 1000:000b type 64-bit pcibios_update_resource(00:08, ..., 3) [fffffffff8002000,fffffffff8003fff]/204 PCI: dev PCI device 1000:000b type 64-bit pcibios_update_resource(00:09, ..., 0) [200,2ff]/101 pcibios_update_resource(00:09, ..., 1) [fffffffff8001400,fffffffff80017ff]/204 PCI: dev PCI device 1000:000b type 64-bit pcibios_update_resource(00:09, ..., 3) [fffffffff8004000,fffffffff8005fff]/204 PCI: dev PCI device 1000:000b type 64-bit pcibios_update_resource(00:10, ..., 0) [300,3ff]/101 pcibios_update_resource(00:10, ..., 1) [fffffffff8001800,fffffffff80018ff]/200 pcibios_update_resource(00:10, ..., 2) [fffffffff8006000,fffffffff8006fff]/200 pcibios_update_resource(00:11, ..., 0) [400,4ff]/101 pcibios_update_resource(00:11, ..., 1) [fffffffff8001900,fffffffff80019ff]/200 pcibios_update_resource(00:11, ..., 2) [fffffffff8007000,fffffffff8007fff]/200 pcibios_update_resource(00:20, ..., 1) [80,bf]/101 pcibios_update_resource(00:28, ..., 0) [fffffffff8008000,fffffffff8008fff]/200 pcibios_update_resource(00:28, ..., 1) [c0,ff]/101 LBA pci_set_bus_ranges() pcibios_fixup_pbus_ranges(0, [0,1000 fffffffff8000000,fffffffff8100000]) lba version TR4.0 (0x5) found at 0xfffffffffed34000 0: 0x8000000000000000 PA 0x0000000000000010,0x0000000000000017 IO 0x0000000000000010,0x0000000000000017 1: 0x8000000000000001 PA 0xfffffffff9000000,0xfffffffff97fffff IO 0x00000000f9000000,0x00000000f97fffff 2: 0x8000000000000002 PA 0xfffffff904000000,0xfffffff97fffffff IO 0x000000f904000000,0x000000f97fffffff lba range[2] : ignoring GMMIO (0xfffffff904000000) 3: 0x8000000000000004 PA 0xfffffff900000000,0xfffffff903ffffff IO 0x000000f900000000,0x000000f903ffffff lba_fixup_bus(0x00000000cffe62c0) bus 16 sysdata 0x00000000cffe61c0 cons 0x00002000 boot 0x00000000 kbd 0x00002000 LBA PIOP resource tree 00000000cffe6210 [100000,17ffff]/100 LBA pcibios_size_bridges() LBA pci_assign_unassigned_resources() pcibios_update_resource(10:00, ..., 1) [100000,1000ff]/101 pcibios_update_resource(10:00, ..., 2) [100100,1001ff]/101 pcibios_update_resource(10:00, ..., 3) [fffffffff9000000,fffffffff90001ff]/200 pcibios_update_resource(10:00, ..., 5) [fffffffff9020000,fffffffff903ffff]/200 LBA pci_set_bus_ranges() pcibios_fixup_pbus_ranges(0, [0,1000 fffffffff8000000,fffffffff8100000]) pcibios_fixup_pbus_ranges(16, [100000,101000 fffffffff9000000,fffffffff9100000]) lba version TR4.0 (0x5) found at 0xfffffffffed38000 0: 0x8000000000000000 PA 0x0000000000000020,0x0000000000000027 IO 0x0000000000000020,0x0000000000000027 1: 0x8000000000000001 PA 0xfffffffffa000000,0xfffffffffa7fffff IO 0x00000000fa000000,0x00000000fa7fffff 2: 0x8000000000000002 PA 0xfffffffa04000000,0xfffffffa7fffffff IO 0x000000fa04000000,0x000000fa7fffffff lba range[2] : ignoring GMMIO (0xfffffffa04000000) 3: 0x8000000000000004 PA 0xfffffffa00000000,0xfffffffa03ffffff IO 0x000000fa00000000,0x000000fa03ffffff lba_fixup_bus(0x00000000cffe64c0) bus 32 sysdata 0x00000000cffe63c0 cons 0x00002000 boot 0x00000000 kbd 0x00002000 LBA PIOP resource tree 00000000cffe6410 [200000,27ffff]/100 LBA pcibios_size_bridges() LBA pci_assign_unassigned_resources() pcibios_update_resource(20:00, ..., 0) [200000,2000ff]/101 pcibios_update_resource(20:00, ..., 1) [fffffffffa000000,fffffffffa0003ff]/204 PCI: dev PCI device 1000:000b type 64-bit pcibios_update_resource(20:00, ..., 3) [fffffffffa002000,fffffffffa003fff]/204 PCI: dev PCI device 1000:000b type 64-bit pcibios_update_resource(20:01, ..., 0) [200100,2001ff]/101 pcibios_update_resource(20:01, ..., 1) [fffffffffa000400,fffffffffa0007ff]/204 PCI: dev PCI device 1000:000b type 64-bit pcibios_update_resource(20:01, ..., 3) [fffffffffa004000,fffffffffa005fff]/204 PCI: dev PCI device 1000:000b type 64-bit LBA pci_set_bus_ranges() pcibios_fixup_pbus_ranges(0, [0,1000 fffffffff8000000,fffffffff8100000]) pcibios_fixup_pbus_ranges(16, [100000,101000 fffffffff9000000,fffffffff9100000]) pcibios_fixup_pbus_ranges(32, [200000,201000 fffffffffa000000,fffffffffa100000]) lba version TR4.0 (0x5) found at 0xfffffffffed3c000 0: 0x8000000000000000 PA 0x0000000000000030,0x0000000000000037 IO 0x0000000000000030,0x0000000000000037 1: 0x8000000000000001 PA 0xfffffffffb000000,0xfffffffffb7fffff IO 0x00000000fb000000,0x00000000fb7fffff 2: 0x8000000000000002 PA 0xfffffffb04000000,0xfffffffb7fffffff IO 0x000000fb04000000,0x000000fb7fffffff lba range[2] : ignoring GMMIO (0xfffffffb04000000) 3: 0x8000000000000004 PA 0xfffffffb00000000,0xfffffffb03ffffff IO 0x000000fb00000000,0x000000fb03ffffff lba_fixup_bus(0x00000000cffe66c0) bus 48 sysdata 0x00000000cffe65c0 cons 0x00002000 boot 0x00000000 kbd 0x00002000 lba_fixup_bus(0x00000000cffe67c0) bus 49 sysdata 0x00000000cffe65c0 cons 0x00002000 boot 0x00000000 kbd 0x00002000 lba_fixup_bus(0x00000000cffe68c0) bus 50 sysdata 0x00000000cffe65c0 cons 0x00002000 boot 0x00000000 kbd 0x00002000 LBA PIOP resource tree 00000000cffe6610 [300000,37ffff]/100 LBA pcibios_size_bridges() LBA pci_assign_unassigned_resources() PCI: Failed to allocate resource 0 for PCI device 1000:000b PCI: Failed to allocate resource 1 for PCI device 1000:000b PCI: Failed to allocate resource 3 for PCI device 1000:000b PCI: Failed to allocate resource 0 for PCI device 1000:000b PCI: Failed to allocate resource 1 for PCI device 1000:000b PCI: Failed to allocate resource 3 for PCI device 1000:000b PCI: Failed to allocate resource 0 for PCI device 1011:0019 PCI: Failed to allocate resource 1 for PCI device 1011:0019 PCI: Failed to allocate resource 0 for PCI device 1011:0019 PCI: Failed to allocate resource 1 for PCI device 1011:0019 PCI: Failed to allocate resource 0 for PCI device 1011:0009 PCI: Failed to allocate resource 1 for PCI device 1011:0009 PCI: Failed to allocate resource 0 for PCI device 1011:0009 PCI: Failed to allocate resource 1 for PCI device 1011:0009 PCI: Failed to allocate resource 0 for PCI device 1011:0009 PCI: Failed to allocate resource 1 for PCI device 1011:0009 PCI: Failed to allocate resource 0 for PCI device 1011:0009 PCI: Failed to allocate resource 1 for PCI device 1011:0009 LBA pci_set_bus_ranges() pcibios_fixup_pbus_ranges(0, [0,1000 fffffffff8000000,fffffffff8100000]) pcibios_fixup_pbus_ranges(16, [100000,101000 fffffffff9000000,fffffffff9100000]) pcibios_fixup_pbus_ranges(32, [200000,201000 fffffffffa000000,fffffffffa100000]) pcibios_fixup_pbus_ranges(49, [310000,311000 fffffffffb000000,fffffffffb100000]) pcibios_fixup_pbus_ranges(50, [320000,321000 fffffffffb000000,fffffffffb100000]) pcibios_fixup_pbus_ranges(48, [0,1000 fb000000,fb100000]) SBA found Astro 2.1 at 0xfffffffffed00000 lba_init_iregs() ibase 0x1 imask 0xf0000000 lba_init_iregs() base_addr fffffffffed3c000 lba_init_iregs() base_addr fffffffffed38000 lba_init_iregs() base_addr fffffffffed34000 lba_init_iregs() base_addr fffffffffed30000 lba_init_iregs() done lba: lba_bios_init Linux NET4.0 for Linux 2.4 Based upon Swansea University Computer Society NET3.039 NET4: Linux TCP/IP 1.0 for NET4.0 IP Protocols: ICMP, UDP, TCP IP: routing cache hash table of 1024 buckets, 16Kbytes TCP: Hash tables configured (established 8192 bind 8192) Starting kswapd v1.7 pty: 256 Unix98 ptys configured lp: driver loaded but no devices found RAMDISK driver initialized: 16 RAM disks of 4096K size 1024 blocksize sym53c8xx: at PCI bus 0, device 2, function 0 sym53c8xx: setting PCI_COMMAND_PARITY...(fix-up) sym53c8xx: changing PCI_LATENCY_TIMER from 0 to 80. kernel BUG at sym53c8xx.c:725! sym53c8xx: 53c876 detected sym53c8xx: at PCI bus 0, device 2, function 1 sym53c8xx: setting PCI_COMMAND_PARITY...(fix-up) sym53c8xx: changing PCI_LATENCY_TIMER from 0 to 80. kernel BUG at sym53c8xx.c:725! sym53c8xx: 53c876 detected sym53c8xx: at PCI bus 0, device 1, function 0 sym53c8xx: setting PCI_COMMAND_PARITY...(fix-up) sym53c8xx: changing PCI_LATENCY_TIMER from 0 to 80. kernel BUG at sym53c8xx.c:725! sym53c8xx: 53c896 detected sym53c8xx: at PCI bus 0, device 1, function 1 sym53c8xx: setting PCI_COMMAND_PARITY...(fix-up) sym53c8xx: changing PCI_LATENCY_TIMER from 0 to 80. kernel BUG at sym53c8xx.c:725! sym53c8xx: 53c896 detected sym53c8xx: at PCI bus 32, device 0, function 0 sym53c8xx: setting PCI_COMMAND_PARITY...(fix-up) sym53c8xx: changing PCI_LATENCY_TIMER from 0 to 80. kernel BUG at sym53c8xx.c:725! sym53c8xx: 53c896 detected sym53c8xx: at PCI bus 32, device 0, function 1 sym53c8xx: setting PCI_COMMAND_PARITY...(fix-up) sym53c8xx: changing PCI_LATENCY_TIMER from 0 to 80. kernel BUG at sym53c8xx.c:725! sym53c8xx: 53c896 detected sym53c8xx: at PCI bus 49, device 4, function 0 sym53c8xx: setting PCI_COMMAND_PARITY...(fix-up) sym53c8xx: changing PCI_LATENCY_TIMER from 0 to 80. kernel BUG at sym53c8xx.c:725! sym53c8xx: 53c896 detected sym53c8xx: at PCI bus 49, device 4, function 1 sym53c8xx: setting PCI_COMMAND_PARITY...(fix-up) sym53c8xx: changing PCI_LATENCY_TIMER from 0 to 80. kernel BUG at sym53c8xx.c:725! sym53c8xx: 53c896 detected kernel BUG at sym53c8xx.c:725! sym53c876-0: rev 0x14 on pci bus 0 device 2 function 0 irq 130 sym53c876-0: NCR clock is 40218KHz sym53c876-0: ID 7, Fast-20, Parity Checking sym53c876-0: on-chip RAM at 0xfffffffff8006000 sym53c876-0: restart (scsi reset). sym53c876-0: Downloading SCSI SCRIPTS. kernel BUG at sym53c8xx.c:725! sym53c876-1: rev 0x14 on pci bus 0 device 2 function 1 irq 131 sym53c876-1: NCR clock is 40218KHz sym53c876-1: ID 7, Fast-20, Parity Checking sym53c876-1: on-chip RAM at 0xfffffffff8007000 sym53c876-1: restart (scsi reset). sym53c876-1: Downloading SCSI SCRIPTS. kernel BUG at sym53c8xx.c:725! sym53c896-2: rev 0x7 on pci bus 0 device 1 function 0 irq 129 sym53c896-2: NCR clock is 40218KHz sym53c896-2: ID 7, Fast-40, Parity Checking sym53c896-2: on-chip RAM at 0xfffffffff8002000 sym53c896-2: restart (scsi reset). sym53c896-2: handling phase mismatch from SCRIPTS. sym53c896-2: Downloading SCSI SCRIPTS. kernel BUG at sym53c8xx.c:725! sym53c896-3: rev 0x7 on pci bus 0 device 1 function 1 irq 130 sym53c896-3: NCR clock is 40218KHz sym53c896-3: ID 7, Fast-40, Parity Checking sym53c896-3: on-chip RAM at 0xfffffffff8004000 sym53c896-3: restart (scsi reset). sym53c896-3: handling phase mismatch from SCRIPTS. sym53c896-3: Downloading SCSI SCRIPTS. kernel BUG at sym53c8xx.c:725! sym53c896-4: rev 0x1 on pci bus 32 device 0 function 0 irq 256 sym53c896-4: NCR clock is 40218KHz sym53c896-4: ID 7, Fast-40, Parity Checking sym53c896-4: on-chip RAM at 0xfffffffffa002000 sym53c896-4: restart (scsi reset). sym53c896-4: handling phase mismatch from SCRIPTS. sym53c896-4: Downloading SCSI SCRIPTS. kernel BUG at sym53c8xx.c:725! sym53c896-5: rev 0x1 on pci bus 32 device 0 function 1 irq 257 sym53c896-5: NCR clock is 40218KHz sym53c896-5: ID 7, Fast-40, Parity Checking sym53c896-5: on-chip RAM at 0xfffffffffa004000 sym53c896-5: restart (scsi reset). sym53c896-5: handling phase mismatch from SCRIPTS. sym53c896-5: Downloading SCSI SCRIPTS. kernel BUG at sym53c8xx.c:725! sym53c896-6: rev 0x5 on pci bus 49 device 4 function 0 irq 323 sym53c896-6: ID 7, Fast-40, Parity Checking sym53c896-6: on-chip RAM at 0xfffffffffb000000 CACHE TEST FAILED: reg dstat-sstat2 readback ffffffff. CACHE INCORRECTLY CONFIGURED. sym53c896-6: giving up ... kernel BUG at sym53c8xx.c:725! kernel BUG at sym53c8xx.c:725! kernel BUG at sym53c8xx.c:725! sym53c896-6: rev 0x5 on pci bus 49 device 4 function 1 irq 320 sym53c896-6: ID 7, Fast-40, Parity Checking sym53c896-6: on-chip RAM at 0xfffffffffb000000 CACHE TEST FAILED: reg dstat-sstat2 readback ffffffff. CACHE INCORRECTLY CONFIGURED. sym53c896-6: giving up ... kernel BUG at sym53c8xx.c:725! kernel BUG at sym53c8xx.c:725! scsi0 : sym53c8xx - version 1.6b scsi1 : sym53c8xx - version 1.6b scsi2 : sym53c8xx - version 1.6b scsi3 : sym53c8xx - version 1.6b scsi4 : sym53c8xx - version 1.6b scsi5 : sym53c8xx - version 1.6b scsi : 6 hosts. Vendor: SEAGATE Model: ST318404LC Rev: HP01 Type: Direct-Access ANSI SCSI revision: 03 Detected scsi disk sda at scsi3, channel 0, id 15, lun 0 sym53c896-3-<15,0>: tagged command queue depth set to 8 scsi : detected 1 SCSI disk total. sym53c896-3-<15,0>: wide msgout: 1-2-3-1. sym53c896-3-<15,0>: wide msgin: 1-2-3-1. sym53c896-3-<15,0>: wide: wide=1 chg=0. sym53c896-3-<15,0>: wide msgout: 1-2-3-1. sym53c896-3-<15,0>: wide msgin: 1-2-3-1. sym53c896-3-<15,0>: wide: wide=1 chg=0. sym53c896-3-<15,0>: sync msgout: 1-3-1-c-1f. sym53c896-3-<15,0>: sync msg in: 1-3-1-c-1f. sym53c896-3-<15,0>: sync: per=12 scntl3=0xb0 scntl4=0x0 ofs=31 fak=0 chg=0. sym53c896-3-<15,*>: FAST-20 WIDE SCSI 40.0 MB/s (50 ns, offset 31) SCSI device sda: hdwr sector= 512 bytes. Sectors= 35566480 [17366 MB] [17.4 GB] Partition check: sda: unknown partition table Serial driver version 5.01 (2000-05-29) with MANY_PORTS SHARE_IRQ SERIAL_PCI enabled Linux Tulip driver version 0.9.8 (July 13, 2000) tulip: MMIO resource (0x80@0x0) unavailable, aborting tulip: MMIO resource (0x80@0x310200) unavailable, aborting tulip: MMIO resource (0x80@0x310280) unavailable, aborting tulip: MMIO resource (0x80@0x320300) unavailable, aborting tulip: MMIO resource (0x80@0x320380) unavailable, aborting tulip: MMIO resource (0x80@0x320400) unavailable, aborting tulip: MMIO resource (0x80@0x320480) unavailable, aborting IP-Config: No network devices available. Switching from PDC console From alan@linuxcare.com.au Thu, 2 Nov 2000 19:51:19 +1100 (EST) Date: Thu, 2 Nov 2000 19:51:19 +1100 (EST) From: Alan Modra alan@linuxcare.com.au Subject: [parisc-linux] new method for 64-bit parisc tree On Wed, 1 Nov 2000, Paul Bame wrote: > The future parisc64 tree ONLY contains files which are different from, > or in addition to, those in the parisc tree. When you 'make config' > or 'make oldconfig', each file in the parsic tree is symbolically > linked as the same file in the parisc64 tree. This enables all > the rest of the tools/build to work normally. 'make distclean' includes > a step to remove all the symlinks. Instead, can't you simply play tricks with -I, and add a symbolic link asm -> ../asm-parisc in asm-parisc64)? The idea being to end up with an include path looking like "-I $(TOPDIR)/include -I $(TOPDIR)/include/asm" That way, asm/foo.h is found by the first -I if we have asm-parisc64/foo.h, and is found by the second if asm-parisc/foo.h exists but not asm-parisc64/foo.h. Hmm, you might also need -I- -- Linuxcare. Support for the Revolution. From rhirst@linuxcare.com Thu, 2 Nov 2000 10:43:06 +0000 Date: Thu, 2 Nov 2000 10:43:06 +0000 From: Richard Hirst rhirst@linuxcare.com Subject: [parisc-linux] a500.out16 On Thu, Nov 02, 2000 at 12:21:36AM -0800, Grant Grundler wrote: > Hi Richard (et al), > I finally think I understand how pcibios_align_resource() is used... > that definitely was the problem. Everything on A500 but PCI-PCI bridge > seems to be assigned I/O port and MMIO addresses correctly. > > I'll look at tulip code tomorrow to see why it's not happy. I fixed tulip_core.c to report what it means, which gave me tulip: MMIO resource (0x400@0xfffffffff8020000) unavailable, aborting Note sym53c8xx.c doesn't seem to bother with request_mem_region(), so maybe request_mem_region() is just broken. I then patched out the goto, so it ignored that error, and.... Linux Tulip driver version 0.9.8 (July 13, 2000) tulip: MMIO resource (0x400@0xfffffffff8020000) unavailable, aborting PCI: Setting latency timer of device 00:00.0 to 64 eth0: Digital DS21143 Tulip rev 65 at 0x0, 00:30:6E:03:79:A0, IRQ 128. eth0: MII transceiver #1 config 1000 status 782d advertising 01e1. Sending BOOTP requests.... OK IP-Config: Got BOOTP answer from 10.160.240.111, my address is 10.160.240.117 Switching from PDC console Wheeee! Nice work Grant! Richard From rhirst@linuxcare.com Thu, 2 Nov 2000 10:48:33 +0000 Date: Thu, 2 Nov 2000 10:48:33 +0000 From: Richard Hirst rhirst@linuxcare.com Subject: [parisc-linux] a500.out16 On Thu, Nov 02, 2000 at 12:21:36AM -0800, Grant Grundler wrote: > I'd also like to connect some more SCSI disks....but any clue > what the "CACHE TEST FAILED" is about? .... > sym53c896-6: rev 0x5 on pci bus 49 device 4 function 0 irq 323 > sym53c896-6: ID 7, Fast-40, Parity Checking > sym53c896-6: on-chip RAM at 0xfffffffffb000000 > CACHE TEST FAILED: reg dstat-sstat2 readback ffffffff. > CACHE INCORRECTLY CONFIGURED. I'd guess that the NCR registers are being cached: static int __init ncr_regtest (struct ncb* np) { register volatile u_int32 data; /* ** ncr registers may NOT be cached. ** write 0xffffffff to a read only register area, ** and try to read it back. */ data = 0xffffffff; OUTL_OFF(offsetof(struct ncr_reg, nc_dstat), data); data = INL_OFF(offsetof(struct ncr_reg, nc_dstat)); #if 1 if (data == 0xffffffff) { #else if ((data & 0xe2f0fffd) != 0x02000080) { #endif printk ("CACHE TEST FAILED: reg dstat-sstat2 readback %x.\n", (unsigned) data); return (0x10); }; return (0); } Richard From fl@fl.priv.at Thu, 02 Nov 2000 12:15:17 +0100 Date: Thu, 02 Nov 2000 12:15:17 +0100 From: Friedrich Lobenstock fl@fl.priv.at Subject: [parisc-linux] HP 3000 - 922LX ?? Hi! How about support for a HP3000-922LX? I think this should be a PA-RISC machine. PS: Please CC me, because I'm not on the list. MfG / Regards Friedrich Lobenstock From rhirst@linuxcare.com Thu, 2 Nov 2000 11:30:47 +0000 Date: Thu, 2 Nov 2000 11:30:47 +0000 From: Richard Hirst rhirst@linuxcare.com Subject: [parisc-linux] a500.out16 On Thu, Nov 02, 2000 at 10:43:06AM +0000, Richard Hirst wrote: > On Thu, Nov 02, 2000 at 12:21:36AM -0800, Grant Grundler wrote: > > Hi Richard (et al), > > I finally think I understand how pcibios_align_resource() is used... > > that definitely was the problem. Everything on A500 but PCI-PCI bridge > > seems to be assigned I/O port and MMIO addresses correctly. > > > > I'll look at tulip code tomorrow to see why it's not happy. > > I fixed tulip_core.c to report what it means, which gave me > > tulip: MMIO resource (0x400@0xfffffffff8020000) unavailable, aborting > > Note sym53c8xx.c doesn't seem to bother with request_mem_region(), so > maybe request_mem_region() is just broken. It is broken because of the following line in kernel/resource.c: struct resource iomem_resource = { "PCI mem", 0x00000000, 0xffffffff, IORESOURCE_MEM }; 'end' needs to be rather higher than 0xffffffff on 64 bit. I changed it to struct resource iomem_resource = { "PCI mem", 0x00000000, ~0, IORESOURCE_MEM }; and it works. I havn't committed that 'fix' though. Richard From matthew@wil.cx Thu, 2 Nov 2000 11:57:53 +0000 Date: Thu, 2 Nov 2000 11:57:53 +0000 From: Matthew Wilcox matthew@wil.cx Subject: [parisc-linux] HP 3000 - 922LX ?? On Thu, Nov 02, 2000 at 12:15:17PM +0100, Friedrich Lobenstock wrote: > Hi! > > How about support for a HP3000-922LX? I think this should be a PA-RISC > machine. According to the docs: http://www.thepuffingroup.com/parisc/hp9000_models.html the 922 is the same physical machine as the 822. As such, it's too old for it to be worth supporting. the official statement is... The earliest PA-RISC servers have proprietary HP devices attached to proprietary HP bus architectures. It is unlikely that documentation on these busses and devices will ever become available, since so few people are interested in spending any effort finding and releasing the docs. Machines in this category are the E, F, G, H, I class (aka Nova) and T500 series (Emerald) machines as well as some earlier, unlettered servers. I should perhaps update this to reflect the particular model numbers. -- Revolutions do not require corporate support. From rhirst@linuxcare.com Thu, 2 Nov 2000 12:07:36 +0000 Date: Thu, 2 Nov 2000 12:07:36 +0000 From: Richard Hirst rhirst@linuxcare.com Subject: [parisc-linux] a500.out16 On Thu, Nov 02, 2000 at 10:43:06AM +0000, Richard Hirst wrote: > Linux Tulip driver version 0.9.8 (July 13, 2000) > tulip: MMIO resource (0x400@0xfffffffff8020000) unavailable, aborting > PCI: Setting latency timer of device 00:00.0 to 64 > eth0: Digital DS21143 Tulip rev 65 at 0x0, 00:30:6E:03:79:A0, IRQ 128. > eth0: MII transceiver #1 config 1000 status 782d advertising 01e1. > Sending BOOTP requests.... OK > IP-Config: Got BOOTP answer from 10.160.240.111, my address is 10.160.240.117 > Switching from PDC console > > Wheeee! Nice work Grant! And if you stop it from trying to switch from pdc to ttyS0 console: Linux Tulip driver version 0.9.8 (July 13, 2000) PCI: Setting latency timer of device 00:00.0 to 64 eth0: Digital DS21143 Tulip rev 65 at 0x0, 00:30:6E:03:79:A0, IRQ 128. eth0: MII transceiver #1 config 1000 status 782d advertising 01e1. Sending BOOTP requests.... OK IP-Config: Got BOOTP answer from 10.160.240.111, my address is 10.160.240.117 kmem_create: Forcing size word alignment - nfs_fh Looking up port of RPC 100003/2 on 10.160.240.111 Looking up port of RPC 100005/2 on 10.160.240.111 VFS: Mounted root (nfs filesystem) readonly. Warning: unable to open an initial console. Kernel panic: Attempted to kill init! Richard From matthew@wil.cx Thu, 2 Nov 2000 12:01:58 +0000 Date: Thu, 2 Nov 2000 12:01:58 +0000 From: Matthew Wilcox matthew@wil.cx Subject: [parisc-linux] a500.out16 On Thu, Nov 02, 2000 at 11:30:47AM +0000, Richard Hirst wrote: > > Note sym53c8xx.c doesn't seem to bother with request_mem_region(), so > > maybe request_mem_region() is just broken. > > It is broken because of the following line in kernel/resource.c: > > struct resource iomem_resource = { "PCI mem", 0x00000000, 0xffffffff, IORESOURCE_MEM }; > > 'end' needs to be rather higher than 0xffffffff on 64 bit. I changed it to > > struct resource iomem_resource = { "PCI mem", 0x00000000, ~0, IORESOURCE_MEM }; > > and it works. I havn't committed that 'fix' though. Probably just as well... the pci_consistent interfaces were designed partly to stop 32-bit PCI cards having to do dual-address-cycle on machines with an IOMMU. if you can, this card should get mapped below the 32-bit boundary. -- Revolutions do not require corporate support. From grundler@cup.hp.com Thu, 02 Nov 2000 08:12:47 -0800 Date: Thu, 02 Nov 2000 08:12:47 -0800 From: Grant Grundler grundler@cup.hp.com Subject: [parisc-linux] a500.out16 This is why I do NOT like our current scheme of using host physical addresses to access I/O space. Richard Hirst wrote: ... > I'd guess that the NCR registers are being cached: > > > static int __init ncr_regtest (struct ncb* np) > { > register volatile u_int32 data; > /* > ** ncr registers may NOT be cached. > ** write 0xffffffff to a read only register area, > ** and try to read it back. > */ > data = 0xffffffff; > OUTL_OFF(offsetof(struct ncr_reg, nc_dstat), data); > data = INL_OFF(offsetof(struct ncr_reg, nc_dstat)); If INL_OFF and OUTL_OFF are broken, they will very likely point to something in memory - page zero. And happily scribble over it gsc_write(xxx). We don't cache I/O space. Never. Something is definitely broken on this code path. I'll look at this once I find out what I broke on the j5k/c3k boot path in lba_pci.c. jsm already restored the previous version of lba_pci.c so folks can still boot 32-bit on c3k/j5k. grant Grant Grundler Unix Systems Enablement Lab +1.408.447.7253 From bame@riverrock.org Thu, 02 Nov 2000 09:20:24 -0700 Date: Thu, 02 Nov 2000 09:20:24 -0700 From: bame@riverrock.org bame@riverrock.org Subject: [parisc-linux] new method for 64-bit parisc tree I want to hear concerns because without serious ones I'm going to make this change next week... = Instead, can't you simply play tricks with -I, and add a symbolic link = asm -> ../asm-parisc in asm-parisc64)? The idea being to end up with = an include path looking like = "-I $(TOPDIR)/include -I $(TOPDIR)/include/asm" = = That way, asm/foo.h is found by the first -I if we have asm-parisc64/foo.h, = and is found by the second if asm-parisc/foo.h exists but not = asm-parisc64/foo.h. Hmm, you might also need -I- That would function fine for header files, but not for source files where something like VPATH might work, but is not available to us. It's worth noting that both -I and VPATH tricks mean if you have an error in or need to change a file, you may have to examine two directories to figure out where it really lives. The symbolic link scheme solves some of that problem. -P From dkennedy@linuxcare.com Thu, 2 Nov 2000 12:30:32 -0800 (PST) Date: Thu, 2 Nov 2000 12:30:32 -0800 (PST) From: dkennedy dkennedy@linuxcare.com Subject: [parisc-linux] Boot Problems with 755 On Mon, 30 Oct 2000, Matthew Wilcox wrote: > This isn't tagged correctly in the hwdb. Could someone inside linuxcare > please fix this? It should be supported by the Apricot driver. I have updated the hwdb to include the Coral II Core Lan Apricot driver. -- David Kennedy, Technical Account Manager, Linuxcare, Inc. 613.562.9594 tel, 613.562.9304 fax dkennedy@linuxcare.com, http://www.linuxcare.com/ Linuxcare. Support for the revolution. From grundler@cup.hp.com Thu, 02 Nov 2000 08:42:06 -0800 Date: Thu, 02 Nov 2000 08:42:06 -0800 From: Grant Grundler grundler@cup.hp.com Subject: [parisc-linux] a500.out16 Matthew Wilcox wrote: > On Thu, Nov 02, 2000 at 11:30:47AM +0000, Richard Hirst wrote: > > > Note sym53c8xx.c doesn't seem to bother with request_mem_region(), so > > > maybe request_mem_region() is just broken. > > > > It is broken because of the following line in kernel/resource.c: > > > > struct resource iomem_resource = { "PCI mem", 0x00000000, 0xffffffff, IORES > OURCE_MEM }; > > > > 'end' needs to be rather higher than 0xffffffff on 64 bit. I changed it to > > > > struct resource iomem_resource = { "PCI mem", 0x00000000, ~0, IORESOURCE_ME > M }; > > > > and it works. I havn't committed that 'fix' though. > > Probably just as well... the pci_consistent interfaces were designed > partly to stop 32-bit PCI cards having to do dual-address-cycle on > machines with an IOMMU. if you can, this card should get mapped below > the 32-bit boundary. Mathew, That's not the whole story. The value (0xfffffffff8020000) seen by the PCI driver *is* a 32-bit PCI address - dual address cycles are not needed. pcibios_update_resource() mangles the address the PCI device driver uses to fit the BAR it's supposed to get written to. See arch/parisc/kernel/pci.c and I think you'll understand. I think you are confusing DMA with PIO (register accesses). The address above is only used to PIO to access registers and has nothing to do with DMA (or I/O MMUs). And PCI device's that can do dual address cycle *should* in order to *avoid* the I/O MMU. The I/O MMU introduces a latency in the DMA path which ideally would be avoided. Of course, there are lots of issues with making that actually work...but it can work. I haven't looked at the whole issue of 64-bit BAR's yet. Mostly because I haven't had to. 64-bit BAR's work just fine when the upper 32-bits are zero'd. :^) But also because the 896 chip (older rev's at least) has 64-bit BARs and it didn't work during N-class bringup in Feb 1999. Currently shipping revs may work. A hack needs to go into pci_quirks.c to support 896 64-bit BARs. thanks for the ideas though, grant Grant Grundler Unix Systems Enablement Lab +1.408.447.7253 From headcrusher@web.de Thu, 2 Nov 2000 19:58:51 +0100 Date: Thu, 2 Nov 2000 19:58:51 +0100 From: =?iso-8859-1?Q? Alexander=20Sch=F6ck ?= headcrusher@web.de Subject: [parisc-linux] Help!? Hallo Puffingroup-Team, I have a very important question about the installation of the linux for PARisc. I hope you can help me! OK, i have a 725/100 Unix Workstation, i tried to install the PARisc-linux on this machine. The CD is booting from this machine, but in the middle of the booting phase the system hang on following line: "request_irq(259, c01ec76c, 0x0, asp, c3rcd080)" - So, what's wrong? How can I go on with the installation? Bye, Alexander S. _______________________________________________________________________ 1.000.000 DM gewinnen - kostenlos tippen - http://millionenklick.web.de IhrName@web.de, 8MB Speicher, Verschluesselung - http://freemail.web.de From matthew@wil.cx Fri, 3 Nov 2000 00:08:06 +0000 Date: Fri, 3 Nov 2000 00:08:06 +0000 From: Matthew Wilcox matthew@wil.cx Subject: [parisc-linux] Help!? On Thu, Nov 02, 2000 at 07:58:51PM +0100, Alexander Schöck wrote: > How can I go on with the installation? question added to the FAQ: 7. I'm using the Alpha 0.1 release CD and the machine stops after printing request_irq(259, c01ec76c, 0x0, asp, c3rcd080) what's going on? This is a bug in the kernel shipped on the CD. It only affects certain machines and has been fixed in the current CVS tree. We recommend you acquire a newer kernel from the FTP site. -- Revolutions do not require corporate support. From kailasr@webcash.com Thu, 02 Nov 2000 17:29:19 -0800 Date: Thu, 02 Nov 2000 17:29:19 -0800 From: Kailashnath V Rampure kailasr@webcash.com Subject: [parisc-linux] Boot command Hi, I have run the following command to initialize the sda harddisk. The sda3 is the linux native partion. Wen I say boot on the HP server it is trying to boot from /stand/vmunix instead of vmlinux can any one help me about the command. Secondaly I want to knwo what is the term type as its not taking vt100 so I am unable to open vi. I have made nesessary changes for the /etc/fstab $ palo -I -k /boot/vmlinux -b /boot/iplboot -c '3/boot/vmlinux TERM=linux HOME=/ root=/dev/sda3' /dev/sda regards Kailas From grundler@cup.hp.com Thu, 02 Nov 2000 17:44:23 -0800 Date: Thu, 02 Nov 2000 17:44:23 -0800 From: Grant Grundler grundler@cup.hp.com Subject: [parisc-linux] Boot command Kailashnath V Rampure wrote: > Hi, > I have run the following command to initialize the sda harddisk. The sda3 > is the linux native partion. > Wen I say boot on the HP server it is trying to boot from /stand/vmunix > instead of vmlinux can any one help me about the command. Sounds like your system is booting from an existing HPUX installed disk. Ie you are not using palo. > Secondaly I want > to knwo what is the term type as its not taking vt100 so I am unable to > open vi. TERM=linux is what I've seen before. The debian ncurses package might need to be installed first though and vt100 should work too. Search the mail archive at http://puffin.external.hp.com/cgi-bin/mailgrep grant > > I have made nesessary changes for the /etc/fstab > > $ palo -I -k /boot/vmlinux -b /boot/iplboot -c '3/boot/vmlinux TERM=linux > HOME=/ root=/dev/sda3' /dev/sda > > regards > Kailas > > --------------------------------------------------------------------------- > To unsubscribe: send e-mail to parisc-linux-request@thepuffingroup.com with > `unsubscribe' as the subject. > Grant Grundler Unix Systems Enablement Lab +1.408.447.7253 From taggart@carmen.fc.hp.com Thu, 02 Nov 2000 18:47:33 -0700 Date: Thu, 02 Nov 2000 18:47:33 -0700 From: Matt Taggart taggart@carmen.fc.hp.com Subject: [parisc-linux] Boot command Kailashnath V Rampure writes... > Hi, > I have run the following command to initialize the sda harddisk. The sda3 > is the linux native partion. > Wen I say boot on the HP server it is trying to boot from /stand/vmunix > instead of vmlinux can any one help me about the command. This means that you are somehow still booting an HP-UX lifimage. Did you follow the directions on, http://www.thepuffingroup.com/parisc/install.html including the partitioning stuff? Maybe you're still booting off another disk, are you sure you're booting from the linux disk? HTH, -- Matt Taggart taggart@fc.hp.com From headcrusher@web.de Fri, 3 Nov 2000 08:04:31 +0100 Date: Fri, 3 Nov 2000 08:04:31 +0100 From: =?iso-8859-1?Q? Alexander=20Sch=F6ck ?= headcrusher@web.de Subject: [parisc-linux] Help!? I downloaded a new kernel from the ftp-site, how can i use this kernel to work with my machine? This is a image file, how can i extract this file, or must i copy it only to the boot-cd? How can i use this kernel? Matthew Wilcox schrieb am 03.11.00: > On Thu, Nov 02, 2000 at 07:58:51PM +0100, Alexander Schöck wrote: > > How can I go on with the installation? > > question added to the FAQ: > > 7. I'm using the Alpha 0.1 release CD and the machine stops after printing > request_irq(259, c01ec76c, 0x0, asp, c3rcd080) > what's going on? > > This is a bug in the kernel shipped on the CD. It only affects certain > machines and has been fixed in the current CVS tree. We recommend you > acquire a newer kernel from the FTP site. > > -- > Revolutions do not require corporate support. > _______________________________________________________________________ 1.000.000 DM gewinnen - kostenlos tippen - http://millionenklick.web.de IhrName@web.de, 8MB Speicher, Verschluesselung - http://freemail.web.de From pdbeal@louisville.edu Fri, 3 Nov 2000 10:02:39 -0500 Date: Fri, 3 Nov 2000 10:02:39 -0500 From: Phillip Beal pdbeal@louisville.edu Subject: [parisc-linux] STI Console problems on 735 and 755 Hey, After all the help I obtained from this list, both through my posts and through the archives, I've finally gotten the 735 and 755, that I have access to, to boot and run linux. However, as soon as it starts to process init, the console screen becomes garbled. The system continues to boot, and I can access the machine via serial console and minicom, but the physical console on the box, just prints garbage. Is this normal for this stage of development? I couldn't see anything in the archives, that said it was, so I'm wondering how I fix this problem, if its been fixed before. Thanks, -- Phillip Beal Electrical and Computer Engineering S+LUG Vice-President From adevries@linuxcare.com Fri, 03 Nov 2000 11:37:08 -0500 Date: Fri, 03 Nov 2000 11:37:08 -0500 From: Alex deVries adevries@linuxcare.com Subject: [parisc-linux] STI Console problems on 735 and 755 Phillip Beal wrote: > After all the help I obtained from this list, both through my posts and > through the archives, I've finally gotten the 735 and 755, that I have > access to, to boot and run linux. However, as soon as it starts to > process init, the console screen becomes garbled. The system continues > to boot, and I can access the machine via serial console and minicom, > but the physical console on the box, just prints garbage. Is this > normal for this stage of development? I couldn't see anything in the > archives, that said it was, so I'm wondering how I fix this problem, if > its been fixed before. Good to hear that your 735 and 755 start to boot! What kind of graphics hardware is sitting on a 735 or 755? I think we've only ever looked at that on a 712 and 715. Can you use serial console in the meantime? - Alex -- Alex deVries, Principal Solutions Architect, The Puffins at Linuxcare 613.562.2759 tel alex@linuxcare.com, http://www.linuxcare.com/ Linuxcare, Support for the revolution. From pdbeal@louisville.edu Fri, 3 Nov 2000 10:49:00 -0500 Date: Fri, 3 Nov 2000 10:49:00 -0500 From: Phillip Beal pdbeal@louisville.edu Subject: [parisc-linux] STI Console problems on 735 and 755 > What kind of graphics hardware is sitting on a 735 or 755? I think > we've only ever looked at that on a 712 and 715. Both the 735 and the 755 have the following device, that seems be refer to the graphics: Coral SGC Graphics (10) at 0xf8000000, version 0x4, 0x0, 0x77, 0x0, 0x0 However, the 755 is known only to use mono graphics, even though they both report the same info for the Coral SGC Grpahics. I hope this helps, > Can you use serial console in the meantime? Yeah, serial works just fine. > > - Alex > > -- > Alex deVries, Principal Solutions Architect, The Puffins at Linuxcare > 613.562.2759 tel > alex@linuxcare.com, http://www.linuxcare.com/ > Linuxcare, Support for the revolution. -- Phillip Beal Electrical and Computer Engineering S+LUG Vice-President From kailasr@webcash.com Fri, 03 Nov 2000 11:03:23 -0800 Date: Fri, 03 Nov 2000 11:03:23 -0800 From: Kailashnath V Rampure kailasr@webcash.com Subject: [parisc-linux] Boot command Yes I have been following the same Doc. its tries to boot from the sda as I can see the hard disk path. I have 2 Hdd's one sda and other sdb. the path are 8/16/5.6 and other is 8/16/5.0. Here I think /dev/sda is 8/16/5.6. It is trying to boot but give sthe following o/p: Boot IO Dependent Code (IODC) revision 144 .... SUCCEEDED! HARD Booted. palo ipl bame@noam Tue Oct 31 14:18:02 MST 2000 0/vmlinux 208896 bytes @ 0x1f78c000 0/palo-cmdline '3/boot/vmlinux TERM=linux Home=/ root=/dev/sdb3' /dev/ida1 82 62 1030688 /dev/ida2 f0 1030750 24738 /dev/ida3 83 1055488 1030750 Kernel:partition 3 file /boot/vmlinux ext2 block size 1024 ext2_mount(partition 3) returns 0 ext2_open(/boot/vmlinux)=3 Couldn't gork your kernel executabel format failed to load kernel Failed to load Kernel. please suggest. At 06:47 PM 11/2/00 -0700, Matt Taggart wrote: >Kailashnath V Rampure writes... > > > Hi, > > I have run the following command to initialize the sda harddisk. The sda3 > > is the linux native partion. > > Wen I say boot on the HP server it is trying to boot from /stand/vmunix > > instead of vmlinux can any one help me about the command. > >This means that you are somehow still booting an HP-UX lifimage. Did you >follow the directions on, > >http://www.thepuffingroup.com/parisc/install.html > >including the partitioning stuff? Maybe you're still booting off another >disk, >are you sure you're booting from the linux disk? > >HTH, > >-- >Matt Taggart >taggart@fc.hp.com From grundler@cup.hp.com Fri, 03 Nov 2000 11:19:29 -0800 Date: Fri, 03 Nov 2000 11:19:29 -0800 From: Grant Grundler grundler@cup.hp.com Subject: [parisc-linux] Boot command Kailashnath V Rampure wrote: > Yes I have been following the same Doc. > its tries to boot from the sda as I can see the hard disk path. I have 2 > Hdd's one sda and other sdb. the path are 8/16/5.6 and other is 8/16/5.0. > Here I think /dev/sda is 8/16/5.6. The lower numbered SCSI ID will be /dev/sda. SCSI devices are lettered in the order they are discovered. The order is reflected in /proc/scsi/scsi. grant Grant Grundler Unix Systems Enablement Lab +1.408.447.7253 From kailasr@webcash.com Fri, 03 Nov 2000 11:46:39 -0800 Date: Fri, 03 Nov 2000 11:46:39 -0800 From: Kailashnath V Rampure kailasr@webcash.com Subject: [parisc-linux] Boot command I have removed the 2nd HDD now the boot is trying but I get the same error: my fstab reads as : # /etc/fstab: static file system information. # # #/dev/sda1 /boot ext2 defaults,errors=remount-ro 0 0 #/dev/sda2 none swap sw 0 0 /dev/sda3 / ext2 defaults,errors=remount-ro 0 0 # proc /proc proc defaults 0 0 The erros is as follows: Boot IO Dependent Code (IODC) revision 144 .... SUCCEEDED! HARD Booted. palo ipl bame@noam Tue Oct 31 14:18:02 MST 2000 0/vmlinux 208896 bytes @ 0x1f78c000 0/palo-cmdline '3/boot/vmlinux TERM=linux Home=/ root=/dev/sda3' /dev/ida1 82 62 1030688 /dev/ida2 f0 1030750 24738 /dev/ida3 83 1055488 1030750 Kernel:partition 3 file /boot/vmlinux ext2 block size 1024 ext2_mount(partition 3) returns 0 ext2_open(/boot/vmlinux)=3 Couldn't gork your kernel executabel format failed to load kernel Failed to load Kernel. Please suggest. From dave@hiauly1.hia.nrc.ca Fri, 3 Nov 2000 15:01:17 -0500 (EST) Date: Fri, 3 Nov 2000 15:01:17 -0500 (EST) From: John David Anglin dave@hiauly1.hia.nrc.ca Subject: testcase for hppa64 gcc bug > I think I know what's going on here. The root of the problem is that > pa-64.h defines an ARG_POINTER_REGNUM that isn't a fixed reg, and isn't > eliminable. The arg_pointer isn't even a call-saved reg. That breaks a > number of places in the compiler. > > So I went down the path of trying to fix things properly by defining > ELIMINABLE_REGS and so on, but I ended in a maze of twisty little passages > labelled "Unrecognizable instruction", like this one: > > /src/parisc/gcc/gcc/libgcc2.c: In function `__moddi3': > /src/parisc/gcc/gcc/libgcc2.c:601: Unrecognizable insn: > (insn 1289 209 1298 (set (reg:SI 50 %fr22) > (subreg:SI (plus:DI (reg:DI 30 %r30) > (const_int -272 [0xfffffef0])) 0)) -1 (nil) > (nil)) > /src/parisc/gcc/gcc/libgcc2.c:601: Internal compiler error in > extract_insn, at recog.c:2134 I am making progress in trying to make the arg_pointer register eliminable. I have fixed the above problem. What was happening was that reload_as_needed was incorrectly trying to eliminate the return from millicode calls which is also register r29. I have figured out how to hide it from reload with unspec. However, the compiler is now too good at eliminating the arg_pointer. At -O3, it completely eliminates the arg_pointer. However, as I read the ABI, the call must always set the arg_pointer before calls. Dave -- J. David Anglin dave.anglin@nrc.ca National Research Council of Canada (613) 990-0752 (FAX: 952-6605) From bame@noam.fc.hp.com Fri, 03 Nov 2000 13:30:16 -0700 Date: Fri, 03 Nov 2000 13:30:16 -0700 From: Paul Bame bame@noam.fc.hp.com Subject: [parisc-linux] Boot command = ext2_open(/boot/vmlinux)=3 = Couldn't gork your kernel executabel format failed to load kernel = Failed to load Kernel. That should be "grok" :-) Apparently you're not using cut/paste for these error messages. This is PALO saying that /boot/vmlinux is neither elf32, elf64, nor SOM format. I'm guessing, based on some earlier advice I gave when you were net-booting, that you may have a lifimage there by mistake -- you need a kernel instead, for example from ftp://puffin.external.hp.com/pub/parisc/binaries/kernels To tell for sure, run 'file vmlinux' on that file. If you get vmlinux: 8086 relocatable (Microsoft) that's probably a lifimage. You should get this instead: vmlinux: ELF 32-bit MSB executable, PA-RISC, version 1, statically linked, not stripped -P From kailasr@webcash.com Fri, 03 Nov 2000 14:59:29 -0800 Date: Fri, 03 Nov 2000 14:59:29 -0800 From: Kailashnath V Rampure kailasr@webcash.com Subject: [parisc-linux] Boot command Thanks! Paul. Yes I had copied the lifImage there. Now I have downloaded the kernel from the link you mentioned. I am still unable to use vi as it says "linux:unknown terminal type" Can you help me. To add features can I add deb packages. I am not that familiar with debian. Actually I want to build an apache + mod_ssl+mod_perl on A180c. Regards Kailas At 01:30 PM 11/3/00 -0700, Paul Bame wrote: >= ext2_open(/boot/vmlinux)=3 >= Couldn't gork your kernel executabel format failed to load kernel >= Failed to load Kernel. > >That should be "grok" :-) Apparently you're not using cut/paste for >these error messages. > >This is PALO saying that /boot/vmlinux is neither elf32, elf64, nor SOM >format. I'm guessing, based on some earlier advice I gave when you >were net-booting, that you may have a lifimage there by mistake -- you >need a kernel instead, for example from >ftp://puffin.external.hp.com/pub/parisc/binaries/kernels > >To tell for sure, run 'file vmlinux' on that file. If you get > vmlinux: 8086 relocatable (Microsoft) >that's probably a lifimage. You should get this instead: > vmlinux: ELF 32-bit MSB executable, PA-RISC, version 1, statically > linked, not stripped > > > -P From randolph@tausq.org Sat, 4 Nov 2000 18:02:03 -0700 Date: Sat, 4 Nov 2000 18:02:03 -0700 From: Randolph Chung randolph@tausq.org Subject: [parisc-linux] ldd segfaulting? I think this may be related to what bdale has been seeing... frodo:~# cat test.c int main(int a, char **b) { return 0; } frodo:~# gcc -o test test.c frodo:~# ./test frodo:~# ldd ./test do_page_fault() pid=144 command='ld.so.1' YZrvWESTHLNXBCVMcbcbcbcbOGFRQPDI PSW: 00000000000001001000000100001011 r0-3 00000000 2aac367c 2aaacd67 2aaaa2f0 r4-7 2aac367c 2aaab4e8 2aac3622 2aac02b8 r8-11 20020048 2aaaccb8 2aaaa2f0 00000000 r12-15 00000081 00000080 200201e8 2001fe10 r16-19 00000000 00000000 00000000 2aac367c r20-23 00000000 2aaaa000 2aaaa000 00000041 r24-27 2aaaa000 70000021 20020048 00076b50 r28-31 00000021 20020048 200202c0 2aaacd1b sr0-4 00000000 00002003 00000000 00002003 sr4-8 00002003 00002003 00002003 00002003 IASQ: 00002003 00002003 IAOQ: 2aaadc63 2aaadc67 IIR: 0ce61280 ISR: 00002003 IOR: 2aac02b8 ORIG_R28: 00086350 do_page_fault() pid=145 command='ld.so.1' YZrvWESTHLNXBCVMcbcbcbcbOGFRQPDI PSW: 00000000000001001000000100001011 r0-3 00000000 2aac367c 2aaacd67 2aaaa2f0 r4-7 2aac367c 2aaab4e8 2aac3622 2aac02b8 r8-11 20020048 2aaaccb8 2aaaa2f0 00000000 r12-15 00000081 00000080 200201e8 2001fe10 r16-19 00000000 00000000 00000000 2aac367c r20-23 00000000 2aaaa000 2aaaa000 00000041 r24-27 2aaaa000 70000021 20020048 00076b50 r28-31 00000021 20020048 200202c0 2aaacd1b sr0-4 00000000 00002003 00000000 00002003 sr4-8 00002003 00002003 00002003 00002003 IASQ: 00002003 00002003 IAOQ: 2aaadc63 2aaadc67 IIR: 0ce61280 ISR: 00002003 IOR: 2aac02b8 ORIG_R28: 00090190 ldd: /lib/ld.so.1 exited with unknown exit code (139) frodo:~# gcc --version 2.96 frodo:~# ldd --version ldd (GNU libc) 2.1.95 Copyright (C) 1999 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. Written by Roland McGrath and Ulrich Drepper. frodo:~# Any ideas what's going on? I've tried this both with a Oct26 kernel and one that is from cvs today. Same results. randolph -- @..@ http://www.TauSq.org/ (----) ( >__< ) ^^ ~~ ^^ From alan@linuxcare.com.au Sun, 5 Nov 2000 16:02:43 +1100 (EST) Date: Sun, 5 Nov 2000 16:02:43 +1100 (EST) From: Alan Modra alan@linuxcare.com.au Subject: [parisc-linux] ldd segfaulting? On Sat, 4 Nov 2000, Randolph Chung wrote: > frodo:~# ldd ./test > > do_page_fault() pid=144 command='ld.so.1' Most likely a case of new kernel, ld.so compiled with old gcc. Old is earlier than 25th Oct. Before that gcc put plabels, which need relocating, in .rodata, which is mapped read-only. The new kernel enforces the read-only mapping, so you run into problems when ld.so tries to relocate itself. Fortunately, you only need recompile glibc with a new gcc. Older binaries with plabels in .rodata are handled OK as ld.so re-maps the segments read/write, something it doesn't manage to do for itself. Alan Modra -- Linuxcare. Support for the Revolution. From bdale@gag.com Sat, 04 Nov 2000 23:16:29 -0700 Date: Sat, 04 Nov 2000 23:16:29 -0700 From: Bdale Garbee bdale@gag.com Subject: [parisc-linux] compiler bug? In the build of util-linux, compilation of fdisk/fdiskbsdlabel.c fails as shown below. I have placed "gcc -E" output on pehc in ~bdale/fdiskbsdlabel.E for reference. Hacking the makefiles to remove "-O -O2" allows the compile to complete cleanly. I assume this means something in the compiler is broken? Bdale bdale@j5k:/space/debian/util-linux-2.10o/fdisk $ cc -c -O -O2 -fomit-frame-pointer -I../lib -Wall -Wmissing-prototypes -Wstrict-prototypes -DNCH=1 -DSBINDIR=\"/sbin\" -DUSRSBINDIR=\"/usr/sbin\" -DLOGDIR=\"/var/log\" -DVARPATH=\"/var\" -DLOCALEDIR=\"/usr/share/locale\" fdiskbsdlabel.c -o fdiskbsdlabel.o /usr/include/linux/string.h:12: parse error before "__extension__" /usr/include/linux/string.h:12: parse error before '&&' token /usr/include/linux/string.h:14: parse error before "__extension__" /usr/include/linux/string.h:14: parse error before '(' token /usr/include/linux/string.h:15: parse error before "__extension__" /usr/include/linux/string.h:15: parse error before '&&' token /usr/include/linux/string.h:24: parse error before "__extension__" /usr/include/linux/string.h:27: parse error before "__extension__" /usr/include/linux/string.h:33: parse error before "__extension__" /usr/include/linux/string.h:36: parse error before "__extension__" /usr/include/linux/string.h:36: parse error before '&&' token /usr/include/linux/string.h:36: parse error before '}' token /usr/include/linux/string.h:36: conflicting declarations of `__result' /usr/include/linux/string.h:36: `__result' previously declared here /usr/include/linux/string.h:36: parse error before ')' token /usr/include/linux/string.h:36: `__s2' undeclared here (not in a function) /usr/include/linux/string.h:36: parse error before ';' token /usr/include/linux/string.h:36: conflicting declarations of `__result' /usr/include/linux/string.h:36: `__result' previously defined here /usr/include/linux/string.h:36: parse error before '}' token /usr/include/linux/string.h:36: parse error before '}' token /usr/include/linux/string.h:36: redefinition of `__result' /usr/include/linux/string.h:36: `__result' previously defined here /usr/include/linux/string.h:36: `__s1' undeclared here (not in a function) /usr/include/linux/string.h:36: parse error before ')' token /usr/include/linux/string.h:36: parse error before ';' token /usr/include/linux/string.h:36: conflicting declarations of `__result' /usr/include/linux/string.h:36: `__result' previously defined here /usr/include/linux/string.h:36: parse error before '}' token /usr/include/linux/string.h:39: parse error before "__extension__" /usr/include/linux/string.h:39: parse error before '&&' token /usr/include/linux/string.h:39: parse error before '}' token /usr/include/linux/string.h:39: redefinition of `__result' /usr/include/linux/string.h:36: `__result' previously defined here /usr/include/linux/string.h:39: parse error before ')' token /usr/include/linux/string.h:39: `__s2' undeclared here (not in a function) /usr/include/linux/string.h:39: parse error before ';' token /usr/include/linux/string.h:39: conflicting declarations of `__result' /usr/include/linux/string.h:39: `__result' previously defined here /usr/include/linux/string.h:39: parse error before '}' token /usr/include/linux/string.h:39: parse error before '}' token /usr/include/linux/string.h:39: redefinition of `__result' /usr/include/linux/string.h:39: `__result' previously defined here /usr/include/linux/string.h:39: `__s1' undeclared here (not in a function) /usr/include/linux/string.h:39: parse error before ')' token /usr/include/linux/string.h:39: parse error before ';' token /usr/include/linux/string.h:39: conflicting declarations of `__result' /usr/include/linux/string.h:39: `__result' previously defined here /usr/include/linux/string.h:39: parse error before '}' token /usr/include/linux/string.h:45: parse error before "__extension__" /usr/include/linux/string.h:51: parse error before "__extension__" /usr/include/linux/string.h:61: parse error before "__extension__" /usr/include/linux/string.h:61: parse error before '\x0' /usr/include/linux/string.h:61: parse error before '}' token fdiskbsdlabel.c: In function `xbsd_zaplabel': fdiskbsdlabel.c:840: warning: `sector' might be used uninitialized in this function bdale@j5k:/space/debian/util-linux-2.10o/fdisk $ From alan@linuxcare.com.au Sun, 5 Nov 2000 18:41:54 +1100 (EST) Date: Sun, 5 Nov 2000 18:41:54 +1100 (EST) From: Alan Modra alan@linuxcare.com.au Subject: [parisc-linux] compiler bug? On Sat, 4 Nov 2000, Bdale Garbee wrote: > Hacking the makefiles to remove "-O -O2" allows the compile to complete > cleanly. glibc includes are "smart", and do things like `#if defined __OPTIMIZE__' > I assume this means something in the compiler is broken? No, I think it's a problem with glibc, or perhaps just your include files. > bdale@j5k:/space/debian/util-linux-2.10o/fdisk $ cc -c -O -O2 -fomit-frame-pointer -I../lib -Wall -Wmissing-prototypes -Wstrict-prototypes -DNCH=1 -DSBINDIR=\"/sbin\" -DUSRSBINDIR=\"/usr/sbin\" -DLOGDIR=\"/var/log\" -DVARPATH=\"/var\" -DLOCALEDIR=\"/usr/share/locale\" fdiskbsdlabel.c -o fdiskbsdlabel.o > /usr/include/linux/string.h:12: parse error before "__extension__" Your .i file had this in it: extern char * ___strtok; extern char * __extension__ ({ char __a0, __a1, __a2; [rest snipped] which comes from linux/string.h extern char * ___strtok; extern char * strcpy(char *,const char *); The problem being that strcpy is being replaced with an inline expansion. Dunno why this is happenning. Alan Modra -- Linuxcare. Support for the Revolution. From xam@sgate.charlysworld.de Mon, 6 Nov 2000 01:14:41 +0100 (CET) Date: Mon, 6 Nov 2000 01:14:41 +0100 (CET) From: xam@deathsdoor.com xam@sgate.charlysworld.de Subject: [parisc-linux] HP9000/730 boot problems Hi all, i have an HP9000/730 (66.6MHz, 32MB RAM, 10MBit Network, CRX graphics, HIL keyboard & mouse, HP 535MBM SCSI HD). I got the latest nfsroot, the latest xc and the palo sources from puffin.external.hp.com. the parition scheme for the HD (id 6) is /dev/sdb1 swap 128MB /dev/sdb2 f0 10MB /dev/sdb3 ext2 rest i untarred nfsroot on /dev/sdb3 and changed /etc/fstab accordingly i installed palo with the following command /opt/palinux/palo-src/palo/palo -I -k /hydra/hppa/boot/vmlinux -b /opt/palinux/palo-src/iplboot -c '3/boot/vmlinux TERM=linux HOME=/ root=/dev/sdb3' /dev/sdb well, i used /dev/sdb since there is also the scsi fd (id 0) that is /dev/sda IMHO (i tested alos to use root=/dev/sda3 btw). some of the boot messages PDC ROM rev. 2.1 IODC ROM rev. 2.1 32 MB of memory configured and tested. Selecting a system to boot. Hard booted. [...] now it prints the palo configuration as i installed it and the hd partition scheme (but /dev/idaXYZ instead of /dev/sdbXYZ [...] ext2 block size 1024 ext2_open(/boot/vmlinux) = 3 ext2_mount(partition 3) returns 0 ELF32 executable [...] now all recognized devices (SGC craphics, BA, HIL, LAN, 2x RS232, SCSI, EISA, Core Centronics, HP model 'king Cobra' ...) the kernel boots actually, but i dumps the stack register and the processor registers (not included in this mail) after ASP version 1 at ..... found thats all. no message like 'unable to boot root fs' or something ... any help ? PS: i tried to use a IBM0664 2.0GB scsi hd before (works fine on linux/ia32), but i couldn't get it work on hp (i reported this in a former mail). PPS: just FYI: the same configuration worked with HP/UX 10.10 From grundler@cup.hp.com Sun, 05 Nov 2000 17:21:12 -0800 Date: Sun, 05 Nov 2000 17:21:12 -0800 From: Grant Grundler grundler@cup.hp.com Subject: [parisc-linux] HP9000/730 boot problems "xam@deathsdoor.com" wrote: > Hi all, > > i have an HP9000/730 (66.6MHz, 32MB RAM, 10MBit Network, CRX graphics, > HIL keyboard & mouse, HP 535MBM SCSI HD). > > I got the latest nfsroot, the latest xc and the palo sources from > puffin.external.hp.com. > > the parition scheme for the HD (id 6) is > > /dev/sdb1 swap 128MB > /dev/sdb2 f0 10MB > /dev/sdb3 ext2 rest > > i untarred nfsroot on /dev/sdb3 and changed /etc/fstab accordingly > i installed palo with the following command > > /opt/palinux/palo-src/palo/palo -I -k /hydra/hppa/boot/vmlinux -b > /opt/palinux/palo-src/iplboot -c '3/boot/vmlinux TERM=linux HOME=/ > root=/dev/sdb3' /dev/sdb > > > well, i used /dev/sdb since there is also the scsi fd (id 0) > that is /dev/sda IMHO (i tested alos to use root=/dev/sda3 btw). using /dev/sdb is ok - your palo command looks "right" to me. > [...] > now it prints the palo configuration as i installed it > and the hd partition scheme (but /dev/idaXYZ instead of /dev/sdbXYZ > [...] > ext2 block size 1024 > ext2_open(/boot/vmlinux) = 3 > ext2_mount(partition 3) returns 0 > ELF32 executable This looks like palo loading the vmlinux. > [...] > > now all recognized devices (SGC craphics, BA, HIL, LAN, 2x RS232, SCSI, > EISA, Core Centronics, HP model 'king Cobra' ...) > > the kernel boots actually, but i dumps the stack register and the > processor registers (not included in this mail) after > > ASP version 1 at ..... found Sounds like ASP support may be broken. The way to find out where IOAQ and GR2 registers are pointing. They should point to functions in System.map. Who is maintaining ASP support? > PS: i tried to use a IBM0664 2.0GB scsi hd before (works fine on > linux/ia32), but i couldn't get it work on hp (i reported this > in a former mail). Right. I'm pretty sure older PDC/IODC doesn't send START_UNIT command to the disk drive. The boot drive is expected to spin up on it's own. I don't know if newer PDC does send START_UNIT either... grant Grant Grundler Unix Systems Enablement Lab +1.408.447.7253 From grundler@cup.hp.com Sun, 5 Nov 2000 18:18:35 -0800 (PST) Date: Sun, 5 Nov 2000 18:18:35 -0800 (PST) From: Grant Grundler grundler@cup.hp.com Subject: [parisc-linux] string.h warnings When linux/arch/parisc/kernel/pci.c built, I get the following warnings: /linux/kwdb64/linux/include/linux/string.h:54: warning: conflicting types for built-in function `strlen' /linux/kwdb64/linux/include/linux/string.h:61: warning: conflicting types for built-in function `memset' /linux/kwdb64/linux/include/linux/string.h:64: warning: conflicting types for built-in function `memcpy' /linux/kwdb64/linux/include/linux/string.h:73: warning: conflicting types for built-in function `memcmp' Could this be related to or shed light on the problem bdale had? thanks, grant From bri@mojo.calyx.net Sun, 5 Nov 2000 21:34:54 -0500 (EST) Date: Sun, 5 Nov 2000 21:34:54 -0500 (EST) From: Brian S. Julin bri@mojo.calyx.net Subject: [parisc-linux] string.h warnings On Sun, 5 Nov 2000, Grant Grundler wrote: > When linux/arch/parisc/kernel/pci.c built, I get the following > warnings: > /linux/kwdb64/linux/include/linux/string.h:54: warning: conflicting types for built-in function `strlen' > /linux/kwdb64/linux/include/linux/string.h:61: warning: conflicting types for built-in function `memset' > /linux/kwdb64/linux/include/linux/string.h:64: warning: conflicting types for built-in function `memcpy' > /linux/kwdb64/linux/include/linux/string.h:73: warning: conflicting types for built-in function `memcmp' For some reason I had numerous problems with string.h not being included when building ncurses natively with the nfsroot tarball. (Also the nfsroot tarball seems to not be able to find the crt* objects by default) -- Brian S. Julin From jsm@udlkern.fc.hp.com Sun, 5 Nov 2000 23:12:56 -0700 (MST) Date: Sun, 5 Nov 2000 23:12:56 -0700 (MST) From: John Marvin jsm@udlkern.fc.hp.com Subject: [parisc-linux] HP 9000/730 boot problem "xam@deathsdoor.com" wrote: > > the kernel boots actually, but i dumps the stack register and the > processor registers (not included in this mail) after > > ASP version 1 at ..... found Grant Grundler wrote: > Sounds like ASP support may be broken. > The way to find out where IOAQ and GR2 registers are pointing. > They should point to functions in System.map. > Who is maintaining ASP support? No, the parallel port support for ASP is broken. If you disable the LASI/ASP builtin parallel-port support (CONFIG_PARPORT_GSC) you will get further. I can't guarantee you will succeed, but others have reported some success on boxes almost that old. This is at least the second time this question has come up, so I guess I'll add it to the FAQ and todo lists. John Marvin jsm@fc.hp.com From marteaut@esiee.fr Tue, 7 Nov 2000 17:00:48 +0100 Date: Tue, 7 Nov 2000 17:00:48 +0100 From: Thomas Marteau marteaut@esiee.fr Subject: [parisc-linux] A browser and a new URL for the ESIEE team web site Hi all, We have succeded to compile Lynx on a 712 and it works well. Also this short mail must tell you that our website can be reached with http://www.esiee.fr/puffin You can find a cool root FS which has the terminfo directory like that you won't have the "vt100:unknown term" message, the network support and lot of thing like that... Bye, ESIEE Team Don't hesitate to visit our website From kailasr@webcash.com Tue, 07 Nov 2000 09:46:53 -0800 Date: Tue, 07 Nov 2000 09:46:53 -0800 From: Kailashnath V Rampure kailasr@webcash.com Subject: [parisc-linux] Boot command Hi, Thanks. I copied the termcap and terminfo directory froma red hat linux box. Now I am able to run VI and the TERM is vt100. Regards Kailas At 02:56 PM 11/5/00 +0100, Thierry SIMONNET wrote: >To have a suitable TERM, you must get termcap or terminfo definition; ie a >good terminfo tree from a linux box. To have a good method to install a >pa/linux box, see my student's web site at http://www.esiee.fr/~djoudim > >Th. SIMONNET > > >Kailashnath V Rampure wrote: > > > Thanks! Paul. > > Yes I had copied the lifImage there. Now I have downloaded the kernel from > > the link you mentioned. > > > > I am still unable to use vi as it says "linux:unknown terminal type" > > Can you help me. > > > > To add features can I add deb packages. I am not that familiar with debian. > > Actually I want to build an apache + mod_ssl+mod_perl on A180c. > > Regards > > Kailas > > > > At 01:30 PM 11/3/00 -0700, Paul Bame wrote: > > >= ext2_open(/boot/vmlinux)=3 > > >= Couldn't gork your kernel executabel format failed to load kernel > > >= Failed to load Kernel. > > > > > >That should be "grok" :-) Apparently you're not using cut/paste for > > >these error messages. > > > > > >This is PALO saying that /boot/vmlinux is neither elf32, elf64, nor SOM > > >format. I'm guessing, based on some earlier advice I gave when you > > >were net-booting, that you may have a lifimage there by mistake -- you > > >need a kernel instead, for example from > > >ftp://puffin.external.hp.com/pub/parisc/binaries/kernels > > > > > >To tell for sure, run 'file vmlinux' on that file. If you get > > > vmlinux: 8086 relocatable (Microsoft) > > >that's probably a lifimage. You should get this instead: > > > vmlinux: ELF 32-bit MSB executable, PA-RISC, version 1, statically > > > linked, not stripped > > > > > > > > > -P > > > > --------------------------------------------------------------------------- > > To unsubscribe: send e-mail to parisc-linux-request@thepuffingroup.com with > > `unsubscribe' as the subject. From bame@noam.fc.hp.com Tue, 07 Nov 2000 11:15:50 -0700 Date: Tue, 07 Nov 2000 11:15:50 -0700 From: Paul Bame bame@noam.fc.hp.com Subject: [parisc-linux] 64-bit BUILD CHANGES The described changes have just been committed to CVS. If you have an existing configured/built 64-bit parisc tree right now I think these are the steps to update: Save your .config file do 'make distclean' do your cvs update restore your .config make oldconfig dep and then proceed as normal The symlinks come when you do a make {old}config and go with a 'make distclean' FYI >>> You may want to start hand-editing .hdepend (following each make dep) to remove the dependency of atomic.h on spinlock.h (just remove the first line containing the string spinlock.h) -- it can cause massive unnecessary rebuilds. It's due to a parisc-specific circular dependency :-( -P = I want to propose/discuss a new method for maintaining our 64-bit parisc = tree in relation to the 32-bit tree. I have prototyped this and so = far it seems pretty useful. = = Most of the files in the current parisc64 tree only contain one = line, a #include of the same file from the parisc tree. This confuses = 'make dep', causes some compile errors to have nonsense line numbers, = and doesn't allow direct editing of the source files in the parisc64 tree. = = The method I'm proposing works like this: = = The future parisc64 tree ONLY contains files which are different from, = or in addition to, those in the parisc tree. When you 'make config' = or 'make oldconfig', each file in the parsic tree is symbolically = linked as the same file in the parisc64 tree. This enables all = the rest of the tools/build to work normally. 'make distclean' includes = a step to remove all the symlinks. = = The ugliest "feature" is that even though you can edit source files = in the parisc64 tree, 'cvs commit' will fail on those which are = symbolic links. To reduce this problem, I'm dropping a symbolic link = called '...' in each parisc64 directory which is a pointer to the = corresponding parisc directory, so 'cd ...; cvs commit foo.c' will = work and not be too onerous. = = We should additionally consider a naming convention or something so = that maintainers in the parisc tree know whether files are shared with = parisc64 or not. = = I prototyped this as a fictional new "architecture" called "p64". To = try it out, grab the tarball (only about 30 files -- can be fewer) = ftp://puffin.external.hp.com/pub/parisc/ = and unpack in your top-level linux source tree directory. Then in = your top-level Makefile, change ARCH := parisc64 to ARCH := p64, then = make oldconfig or whatever you usually do. Let me know of any problems. = = Is this something we should adopt for the real parisc64 tree? = = -Paul Bame = = --------------------------------------------------------------------------- = To unsubscribe: send e-mail to parisc-linux-request@thepuffingroup.com with = `unsubscribe' as the subject. = = = From grundler@cup.hp.com Tue, 07 Nov 2000 11:19:02 -0800 Date: Tue, 07 Nov 2000 11:19:02 -0800 From: Grant Grundler grundler@cup.hp.com Subject: [parisc-linux] Boot command Kailashnath V Rampure wrote: > Hi, > Thanks. I copied the termcap and terminfo directory froma red hat linux > box. Now I am able to run VI and the TERM is vt100. I've added a "vi is complaining" item to the FAQ. Normally the FAQ lives at http://www.thepuffingroup.com/parisc/faq.html but it's not updated yet. I've put a temporary copy at http://puffin.external.hp.com/~grundler/faq.html and will remove this once the regular location is updated. (Hint - relative links won't work from my copy) grant Grant Grundler Unix Systems Enablement Lab +1.408.447.7253 From marteaut@esiee.fr Tue, 7 Nov 2000 20:53:55 +0100 Date: Tue, 7 Nov 2000 20:53:55 +0100 From: Thomas Marteau marteaut@esiee.fr Subject: [parisc-linux] Boot command ----- Original Message ----- From: Grant Grundler To: Kailashnath V Rampure Cc: Sent: Tuesday, November 07, 2000 8:19 PM Subject: Re: [parisc-linux] Boot command > Kailashnath V Rampure wrote: > > Hi, > > Thanks. I copied the termcap and terminfo directory froma red hat linux > > box. Now I am able to run VI and the TERM is vt100. > > I've added a "vi is complaining" item to the FAQ. To use vi and all these applications like top, they need the terminfo directory in /usr/share from any distrib!! Bye, the ESIEE Team From grundler@cup.hp.com Tue, 07 Nov 2000 12:24:39 -0800 Date: Tue, 07 Nov 2000 12:24:39 -0800 From: Grant Grundler grundler@cup.hp.com Subject: [parisc-linux] Boot command "Thomas Marteau" wrote: > Grant Grundler wrote: > > Kailashnat V Rampure wrote: > > > Hi, > > > Thanks. I copied the termcap and terminfo directory froma red hat linux > > > box. Now I am able to run VI and the TERM is vt100. > > > > I've added a "vi is complaining" item to the FAQ. > > To use vi and all these applications like top, they need the terminfo > directory in /usr/share from any distrib!! I didn't say taking from RH was wrong. IMHO, doing so defeats the whole point of debian's packaging system. Please read the new FAQ entry and tell me if I've gotten that right or not. grant Grant Grundler Unix Systems Enablement Lab +1.408.447.7253 From kailasr@webcash.com Tue, 07 Nov 2000 14:50:10 -0800 Date: Tue, 07 Nov 2000 14:50:10 -0800 From: Kailashnath V Rampure kailasr@webcash.com Subject: [parisc-linux] Boot command I agree with you regarding taking from RH. I just wanted to let u all know how I solved the issue. I have gone through the faq it is fine. Regards Kailas At 12:24 PM 11/7/00 -0800, Grant Grundler wrote: >"Thomas Marteau" wrote: > > Grant Grundler wrote: > > > Kailashnat V Rampure wrote: > > > > Hi, > > > > Thanks. I copied the termcap and terminfo directory froma red hat linux > > > > box. Now I am able to run VI and the TERM is vt100. > > > > > > I've added a "vi is complaining" item to the FAQ. > > > > To use vi and all these applications like top, they need the terminfo > > directory in /usr/share from any distrib!! > >I didn't say taking from RH was wrong. >IMHO, doing so defeats the whole point of debian's packaging system. > >Please read the new FAQ entry and tell me if I've gotten >that right or not. > >grant > >Grant Grundler >Unix Systems Enablement Lab >+1.408.447.7253 > >--------------------------------------------------------------------------- >To unsubscribe: send e-mail to parisc-linux-request@thepuffingroup.com with >`unsubscribe' as the subject. From cjknoch@yahoo.com Tue, 7 Nov 2000 15:40:14 -0800 (PST) Date: Tue, 7 Nov 2000 15:40:14 -0800 (PST) From: Christian Knoch cjknoch@yahoo.com Subject: [parisc-linux] HP 9000 e25 hi. i need information about how to install linux on hp 9000 e25 what version on linux what distribution ? how many memoty i need in this machine how many space on disk i need in this machine howto boot machine for install linux Thanks __________________________________________________ Do You Yahoo!? Thousands of Stores. Millions of Products. All in one Place. http://shopping.yahoo.com/ From matthew@wil.cx Wed, 8 Nov 2000 00:28:08 +0000 Date: Wed, 8 Nov 2000 00:28:08 +0000 From: Matthew Wilcox matthew@wil.cx Subject: [parisc-linux] HP 9000 e25 On Tue, Nov 07, 2000 at 03:40:14PM -0800, Christian Knoch wrote: > hi. > i need information about how to install linux on hp > 9000 e25 *sigh*. This is in the FAQ. Where do we need to put links to the FAQ to persuade people to read it? Where did you find this mailing list address, do we need to put a link to the FAQ there? The answer given in the FAQ is: The earliest PA-RISC servers have proprietary HP devices attached to proprietary HP bus architectures. It is unlikely that documentation on these busses and devices will ever become available, since so few people are interested in spending any effort finding and releasing the docs. Machines in this category are the E, F, G, H, I class (aka Nova) and T500 series (Emerald) machines as well as some earlier, unlettered servers. -- Revolutions do not require corporate support. From matthew@wil.cx Wed, 8 Nov 2000 20:14:43 +0000 Date: Wed, 8 Nov 2000 20:14:43 +0000 From: Matthew Wilcox matthew@wil.cx Subject: [parisc-linux] webshite since the lord god alex hasn't seen fit to inform anyone, it seems like i should. the www.thepuffingroup.com website is no longer being updated and all the updates are only going to parisc-linux.org. i have been updating www.thepuffingroup.com becuase no-one told me that this site was no longer supposed to be operational and i suspect a large number of people who subscribe to this list still have it bookmarked. also, email sent to willy@thepuffingroup.com is no longer being received by me. i don't know who gets it, but the sender does not receive a bounce. yours, fucking furious, Matthew. -- "It's time for you to change your sig" -- Alex deVries From grundler@cup.hp.com Wed, 08 Nov 2000 12:31:11 -0800 Date: Wed, 08 Nov 2000 12:31:11 -0800 From: Grant Grundler grundler@cup.hp.com Subject: [parisc-linux] webshite Matthew Wilcox wrote: > > since the lord god alex hasn't seen fit to inform anyone, it seems like > i should. the www.thepuffingroup.com website is no longer being updated > and all the updates are only going to parisc-linux.org. We gave LXC's website maintainer grief about this already. > i have been > updating www.thepuffingroup.comwww.thepuffingroup.com becuase no-one told me that this site > was no longer supposed to be operational and i suspect a large number > of people who subscribe to this list still have it bookmarked. Some time today, I expect (hope?) www.thepuffingroup.com/parisc will be redirected to www.parisc-linux.org (.com works too). I've asked mail be sent to this list when it happens. > also, > email sent to willy@thepuffingroup.com is no longer being received by me. > i don't know who gets it, but the sender does not receive a bounce. This should probably bounce since it's been stale for about 11 monthes now... hope this helps, grant ps. just trying to compensate for an otherwise lack of communication. > > yours, fucking furious, Matthew. > > -- > "It's time for you to change your sig" -- Alex deVries > > --------------------------------------------------------------------------- > To unsubscribe: send e-mail to parisc-linux-request@thepuffingroup.com with > `unsubscribe' as the subject. > Grant Grundler Unix Systems Enablement Lab +1.408.447.7253 From andrew@neep.com.au Thu, 9 Nov 2000 05:13:23 +0800 Date: Thu, 9 Nov 2000 05:13:23 +0800 From: Andrew Shugg andrew@neep.com.au Subject: [parisc-linux] webshite Matthew Wilcox said: > the www.thepuffingroup.com website is no longer being updated and all > the updates are only going to parisc-linux.org. I don't know if there's some other secret mailing list I'm missing out on, but that's the first time I've heard of "parisc-linux.org" I'm sure. So thankyou for being the one to bring it up. Will the mailing list be moving as well? (Given that it belongs with the project, not the mothballed puffingroup website.) > -- > "It's time for you to change your sig" -- Alex deVries Shame, I thought your old sig was funnier. Andrew. -- Andrew Shugg http://www.neep.com.au/ "Just remember, Mr Fawlty, there's always someone worse off than yourself." "Is there? Well I'd like to meet him. I could do with a good laugh." From taggart@carmen.fc.hp.com Wed, 08 Nov 2000 14:22:03 -0700 Date: Wed, 08 Nov 2000 14:22:03 -0700 From: Matt Taggart taggart@carmen.fc.hp.com Subject: [parisc-linux] webshite Andrew Shugg writes... > I don't know if there's some other secret mailing list I'm missing out > on, but that's the first time I've heard of "parisc-linux.org" I'm sure. > So thankyou for being the one to bring it up. It was never officially announced, just setup. I guess this is the announcement. > Will the mailing list be moving as well? (Given that it belongs with > the project, not the mothballed puffingroup website.) Yes, most of the project's web/mail resources will be moving there shortly. Go ahead and update your bookmarks. I've been told there will be a pointer/redirect from the old site but I wouldn't count on it existing forever. -- Matt Taggart taggart@fc.hp.com From andrew@neep.com.au Thu, 9 Nov 2000 05:48:06 +0800 Date: Thu, 9 Nov 2000 05:48:06 +0800 From: Andrew Shugg andrew@neep.com.au Subject: [parisc-linux] HP 9000 e25 Matthew Wilcox said: > On Tue, Nov 07, 2000 at 03:40:14PM -0800, Christian Knoch wrote: > > hi. > > i need information about how to install linux on hp > > 9000 e25 > > *sigh*. This is in the FAQ. Where do we need to put links to the FAQ > to persuade people to read it? Where did you find this mailing list > address, do we need to put a link to the FAQ there? I think the fault lies in the "Contact" page, new (!) URL being: http://parisc-linux.org/contact.html "Most questions about the port should be addressed to the developer mailing list parisc-linux@thepuffingroup.com" I would suggest this page be changed a bit, like stick the mailing list down the bottom and change it to a link to the mailing list subscribe and browse-the-archives page, rather than simply the address of the list. Also a comment about reading the FAQ. Yes, the FAQ is in the left-hand side-bar but you can never over-do the help. =) One of my favourite comments along that line was on the windowmaker.org home page (sadly it has been removed). It was something like "Please bear in mind that asking questions on the mailing list that are answered in the FAQ is NOT A GOOD IDEA." The FAQ on parisc-linux.org is also missing the all-important Q/A pair: Q. I have a question that isn't answered in this FAQ? A. Please subscribe to the [mailing list] and ask. Politely. Preferably in English, or (failing that) in a recognisable pidgin. Don't hold back on the relevant information either. "It won't boot" is not good. Andrew. -- Andrew Shugg http://www.neep.com.au/ "Just remember, Mr Fawlty, there's always someone worse off than yourself." "Is there? Well I'd like to meet him. I could do with a good laugh." From jvinet@linuxcare.com Wed, 08 Nov 2000 17:41:50 -0500 Date: Wed, 08 Nov 2000 17:41:50 -0500 From: Jane Vinet jvinet@linuxcare.com Subject: [parisc-linux] HP 9000 e25 Good advice...will notify the web design folks. Jane -- jvinet@linuxcare.com Andrew Shugg wrote: > I would suggest this page be changed a bit, like stick the mailing list > down the bottom and change it to a link to the mailing list subscribe > and browse-the-archives page, rather than simply the address of the > list. Also a comment about reading the FAQ. Yes, the FAQ is in the > left-hand side-bar but you can never over-do the help. =) > > One of my favourite comments along that line was on the windowmaker.org > home page (sadly it has been removed). It was something like "Please > bear in mind that asking questions on the mailing list that are answered > in the FAQ is NOT A GOOD IDEA." > > The FAQ on parisc-linux.org is also missing the all-important Q/A pair: > > Q. I have a question that isn't answered in this FAQ? > A. Please subscribe to the [mailing list] and ask. Politely. Preferably > in English, or (failing that) in a recognisable pidgin. Don't hold back > on the relevant information either. "It won't boot" is not good. > > Andrew. > > -- > Andrew Shugg http://www.neep.com.au/ > > "Just remember, Mr Fawlty, there's always someone worse off than yourself." > "Is there? Well I'd like to meet him. I could do with a good laugh." > > --------------------------------------------------------------------------- > To unsubscribe: send e-mail to parisc-linux-request@thepuffingroup.com with > `unsubscribe' as the subject. From matthew@wil.cx Thu, 9 Nov 2000 09:59:58 +0000 Date: Thu, 9 Nov 2000 09:59:58 +0000 From: Matthew Wilcox matthew@wil.cx Subject: [parisc-linux] webshite On Thu, Nov 09, 2000 at 05:13:23AM +0800, Andrew Shugg wrote: > Matthew Wilcox said: > > the www.thepuffingroup.com website is no longer being updated and all > > the updates are only going to parisc-linux.org. > > I don't know if there's some other secret mailing list I'm missing out > on, but that's the first time I've heard of "parisc-linux.org" I'm sure. > So thankyou for being the one to bring it up. oh, alex secretly went off and registered it. the first we heard about it was in a press release a couple of months ago. for a while it's been a (broken) redirect to www.thepuffingroup.com/parisc. there's a linuxcare internal mailing list for discussions of the parisc project, but it wasn't mentioned on there either. > Will the mailing list be moving as well? (Given that it belongs with > the project, not the mothballed puffingroup website.) no idea. alex is playing politics and he's not very good at it. personally, i think everything should be moved to puffin.external.hp.com and parisc-linux.org should just redirect to it, but that wouldn't fit with the aforementioned political games. > > -- > > "It's time for you to change your sig" -- Alex deVries > > Shame, I thought your old sig was funnier. oh, i just thought that was a more appropriate sig for the circumstances, I haven't changed permanently. -- Revolutions do not require corporate support. From matthew@wil.cx Thu, 9 Nov 2000 10:06:27 +0000 Date: Thu, 9 Nov 2000 10:06:27 +0000 From: Matthew Wilcox matthew@wil.cx Subject: [parisc-linux] webshite On Wed, Nov 08, 2000 at 12:31:11PM -0800, Grant Grundler wrote: > Matthew Wilcox wrote: > > also, > > email sent to willy@thepuffingroup.com is no longer being received by me. > > i don't know who gets it, but the sender does not receive a bounce. > > This should probably bounce since it's been stale for about > 11 monthes now... um, it was my email address until about 3 months ago. at least one person still had that as their preferred email address for me. if anyone else does, they should probably change it. it's the lack of bounce which concerns me, which implies that someone's receiving it, reading mail destined for me and not forwarding it on. -- Revolutions do not require corporate support. From dave@hiauly1.hia.nrc.ca Thu, 9 Nov 2000 12:39:57 -0500 (EST) Date: Thu, 9 Nov 2000 12:39:57 -0500 (EST) From: John David Anglin dave@hiauly1.hia.nrc.ca Subject: testcase for hppa64 gcc bug > > So I went down the path of trying to fix things properly by defining > > ELIMINABLE_REGS and so on, but I ended in a maze of twisty little passages > > labelled "Unrecognizable instruction", like this one: > > > > /src/parisc/gcc/gcc/libgcc2.c: In function `__moddi3': > > /src/parisc/gcc/gcc/libgcc2.c:601: Unrecognizable insn: > > (insn 1289 209 1298 (set (reg:SI 50 %fr22) > > (subreg:SI (plus:DI (reg:DI 30 %r30) > > (const_int -272 [0xfffffef0])) 0)) -1 (nil) > > (nil)) > > /src/parisc/gcc/gcc/libgcc2.c:601: Internal compiler error in > > extract_insn, at recog.c:2134 > > I am making progress in trying to make the arg_pointer register eliminable. > I have fixed the above problem. What was happening was that reload_as_needed > was incorrectly trying to eliminate the return from millicode calls which > is also register r29. I have figured out how to hide it from reload with > unspec. > > However, the compiler is now too good at eliminating the arg_pointer. At > -O3, it completely eliminates the arg_pointer. However, as I read the ABI, > the call must always set the arg_pointer before calls. For the record, here is my final patch regarding making the arg_pointer eliminable for TARGET_64BIT. I think the code it generates is correct but it hasn't been extensively tested. However, I don't recommend it for installation since in comparing the assembler code generated with and without elimination for a couple of test cases, I didn't observe any significant improvement in the code with the patch. Possibly, the patch implicitly disables elimination when the arg_pointer is needed. I do find that Alan Modra's ARG_POINTER_INVARIANT patch needs to be installed to get correct code with his test case. There is one part of the patch below which I think needs to be installed. That is (call, call_value): Always USE the arg_pointer for TARGET_64BIT. The use for the arg_pointer needs to be pulled out of the `if (flag_pic)'. Dave -- J. David Anglin dave.anglin@nrc.ca National Research Council of Canada (613) 990-0752 (FAX: 952-6605) 2000-11-07 John David Anglin * pa-linux64.h (ARG_POINTER_INVARIANT): Define even when the arg_pointer is being eliminated. (ELIMINABLE_REGS): Enable elimination of the arg_pointer. (INITIAL_ELIMINATION_OFFSET): Revise offsets for arg_pointer. * pa.md (mulsi3, divsi3, udivsi3, modsi3, umodsi3 and canonicalize_funcptr_for_compare): Put "(reg:SI 26)" inside unspec to prevent elimination. (call, call_value): Always USE the arg_pointer for TARGET_64BIT. Use the new addmovdi3 insn to load the arg_pointer register. (addmovdi3 and mov_from_r29_si): New insn and expand which prevent r29 from being eliminated in call setups and millicode returns. --- pa-linux64.h.orig Tue Oct 31 18:38:24 2000 +++ pa-linux64.h Tue Nov 7 12:17:12 2000 @@ -209,21 +209,18 @@ that grow to lower addresses. What fun. */ #undef ARGS_GROW_DOWNWARD #undef ARG_POINTER_REGNUM -#define ARG_POINTER_INVARIANT 0 #define ARG_POINTER_REGNUM 29 +#define ARG_POINTER_INVARIANT 0 #undef STATIC_CHAIN_REGNUM #define STATIC_CHAIN_REGNUM 31 -#if 1 -#define ARG_POINTER_INVARIANT 0 -#else -/* If defined, this macro specifies a table of register pairs used to eliminate - unneeded registers that point into the stack frame. */ +/* If defined, this macro specifies a table of register pairs used to + eliminate unneeded registers that point into the stack frame. */ #define ELIMINABLE_REGS \ { \ - {ARG_POINTER_REGNUM, STACK_POINTER_REGNUM}, \ {FRAME_POINTER_REGNUM, STACK_POINTER_REGNUM}, \ + {ARG_POINTER_REGNUM, STACK_POINTER_REGNUM}, \ {ARG_POINTER_REGNUM, FRAME_POINTER_REGNUM}, \ } @@ -240,19 +237,18 @@ #define INITIAL_ELIMINATION_OFFSET(FROM, TO, OFFSET) \ do \ { \ - int fsize; \ + int fsize = compute_frame_size (get_frame_size (), 0); \ \ if ((TO) == FRAME_POINTER_REGNUM \ && (FROM) == ARG_POINTER_REGNUM) \ { \ - (OFFSET) = - current_function_pretend_args_size - 16; \ + (OFFSET) = fsize + 48 - current_function_outgoing_args_size; \ break; \ } \ \ if ((TO) != STACK_POINTER_REGNUM) \ abort (); \ \ - fsize = compute_frame_size (get_frame_size (), 0); \ switch (FROM) \ { \ case FRAME_POINTER_REGNUM: \ @@ -260,14 +256,13 @@ break; \ \ case ARG_POINTER_REGNUM: \ - (OFFSET) = - fsize - current_function_pretend_args_size - 16; \ + (OFFSET) = 48 - current_function_outgoing_args_size; \ break; \ \ default: \ abort (); \ } \ } while (0) -#endif #undef SELECT_RTX_SECTION #define SELECT_RTX_SECTION(MODE,RTX) \ --- pa.md.orig Tue Nov 7 13:50:34 2000 +++ pa.md.work Wed Nov 8 14:06:05 2000 @@ -3993,7 +3993,7 @@ (clobber (reg:SI 26)) (clobber (reg:SI 25)) (clobber (reg:SI 31))]) - (set (match_operand:SI 0 "general_operand" "") (reg:SI 29))] + (set (match_operand:SI 0 "general_operand" "") (unspec:SI [(reg:SI 29)] 0))] "" " { @@ -4139,7 +4139,7 @@ (clobber (reg:SI 26)) (clobber (reg:SI 25)) (clobber (reg:SI 31))]) - (set (match_operand:SI 0 "general_operand" "") (reg:SI 29))] + (set (match_operand:SI 0 "general_operand" "") (unspec:SI [(reg:SI 29)] 0))] "" " { @@ -4197,7 +4197,7 @@ (clobber (reg:SI 26)) (clobber (reg:SI 25)) (clobber (reg:SI 31))]) - (set (match_operand:SI 0 "general_operand" "") (reg:SI 29))] + (set (match_operand:SI 0 "general_operand" "") (unspec:SI [(reg:SI 29)] 0))] "" " { @@ -4255,7 +4255,7 @@ (clobber (reg:SI 26)) (clobber (reg:SI 25)) (clobber (reg:SI 31))]) - (set (match_operand:SI 0 "general_operand" "") (reg:SI 29))] + (set (match_operand:SI 0 "general_operand" "") (unspec:SI [(reg:SI 29)] 0))] "" " { @@ -4310,7 +4310,7 @@ (clobber (reg:SI 26)) (clobber (reg:SI 25)) (clobber (reg:SI 31))]) - (set (match_operand:SI 0 "general_operand" "") (reg:SI 29))] + (set (match_operand:SI 0 "general_operand" "") (unspec:SI [(reg:SI 29)] 0))] "" " { @@ -5785,9 +5785,9 @@ op = XEXP (operands[0], 0); if (TARGET_64BIT) - emit_move_insn (arg_pointer_rtx, - gen_rtx_PLUS (word_mode, virtual_outgoing_args_rtx, - GEN_INT (64))); + emit_insn (gen_addmovdi3 (arg_pointer_rtx, + virtual_outgoing_args_rtx, + GEN_INT (64))); /* Use two different patterns for calls to explicitly named functions and calls through function pointers. This is necessary as these two @@ -5809,13 +5809,14 @@ call_insn = emit_call_insn (gen_call_internal_reg (operands[1])); } + if (TARGET_64BIT) + use_reg (&CALL_INSN_FUNCTION_USAGE (call_insn), arg_pointer_rtx); + if (flag_pic) { use_reg (&CALL_INSN_FUNCTION_USAGE (call_insn), pic_offset_table_rtx); use_reg (&CALL_INSN_FUNCTION_USAGE (call_insn), gen_rtx_REG (word_mode, PIC_OFFSET_TABLE_REGNUM_SAVED)); - if (TARGET_64BIT) - use_reg (&CALL_INSN_FUNCTION_USAGE (call_insn), arg_pointer_rtx); /* After each call we must restore the PIC register, even if it doesn't appear to be used. @@ -5961,9 +5962,9 @@ op = XEXP (operands[1], 0); if (TARGET_64BIT) - emit_move_insn (arg_pointer_rtx, - gen_rtx_PLUS (word_mode, virtual_outgoing_args_rtx, - GEN_INT (64))); + emit_insn (gen_addmovdi3 (arg_pointer_rtx, + virtual_outgoing_args_rtx, + GEN_INT (64))); /* Use two different patterns for calls to explicitly named functions and calls through function pointers. This is necessary as these two @@ -5989,6 +5990,10 @@ call_insn = emit_call_insn (gen_call_value_internal_reg (operands[0], operands[2])); } + + if (TARGET_64BIT) + use_reg (&CALL_INSN_FUNCTION_USAGE (call_insn), arg_pointer_rtx); + if (flag_pic) { use_reg (&CALL_INSN_FUNCTION_USAGE (call_insn), pic_offset_table_rtx); @@ -7124,7 +7129,7 @@ (clobber (reg:SI 22)) (clobber (reg:SI 31))]) (set (match_operand:SI 0 "register_operand" "") - (reg:SI 29))] + (unspec:SI [(reg:SI 29)] 0))] "! TARGET_PORTABLE_RUNTIME && !TARGET_64BIT && !TARGET_ELF32" " { @@ -7236,3 +7241,48 @@ emit_insn (gen_blockage ()); DONE; }") + +;; For TARGET_64BIT, the arg_pointer register is also used for millicode +;; returns. The ABI requires that the arg_pointer be set for all calls. +;; When the arg_pointer is made an eliminable register, eliminate_regs +;; will eliminate the arg_pointer register from the function call setup and +;; millicode returns unless the arg_pointer is hidden in a use, clobber or +;; unspec. + +;; This is for loading the arg_pointer in function calls. +(define_insn "addmovdi3" + [(set (unspec:DI [(match_operand:DI 0 "register_operand" "=r,r")] 0) + (plus:DI (match_operand:DI 1 "register_operand" "r,r") + (match_operand 2 "const_int_operand" "J,i"))) + (set (match_dup 0) (match_dup 0))] + "TARGET_64BIT" + "@ + ldo %2(%1),%0 + ldil L'%G2,%0\;add,l %0,%1,%0" + [(set_attr "type" "binary,binary") + (set_attr "pa_combine_type" "addmove,none") + (set_attr "length" "4,8")]) + +;; This is for millicode return. +(define_expand "mov_from_r29_si" + [(set (match_operand:SI 0 "" "") + (unspec:SI [(reg:SI 29)] 0))] + "" + " +{ + if (!TARGET_64BIT) + { + rtx tmp = gen_rtx_REG (SImode, 29); + emit_insn (gen_movsi (operands[0], tmp)); + DONE; + } +}") + +(define_insn "" + [(set (match_operand:SI 0 "register_operand" "=r") + (unspec:SI [(reg:SI 29)] 0))] + "" + "copy %%r29,%0" + [(set_attr "type" "multi") + (set_attr "length" "4")]) + From bame@noam.fc.hp.com Thu, 09 Nov 2000 11:47:51 -0700 Date: Thu, 09 Nov 2000 11:47:51 -0700 From: Paul Bame bame@noam.fc.hp.com Subject: [parisc-linux] kernel merge We're getting ready to do a kernel merge (to -test10 I think). Anybody concerns before we get started? -P From jvinet@linuxcare.com Thu, 09 Nov 2000 14:08:20 -0500 Date: Thu, 09 Nov 2000 14:08:20 -0500 From: Jane Vinet jvinet@linuxcare.com Subject: [parisc-linux] Website Plan Recently there have been concerns about what is happening with the web site. I'd like to let everyone know what the plan is in order to address these concerns. The Development team at HP provided us with a list of where current pages are hosted and where they should be hosted in the future. Item current future ---- ------- ------ mailing lists pehc LXC parisc website puffin LXC hardware database puffin pehc ftp server pehc pehc cvs pehc pehc As per Linuxcare's agreement with Hewlett Packard, Linuxcare (formerly the Puffing Group) is responsible for all of the pages that are currently hosted at http://www.thepuffingroup.com/parisc/. Linuxcare is in the process of redesigning the existing web pages and we will be moving very soon to http://www.parisc-linux.org/. By revamping the existing web pages, we want to make things like the FAQ page and the To-Do list much more visible to the public to encourage new contributors to join us, as well as meeting the needs of current Developers. The plan is to transition from the current website to the new website with as little disruption to the public as possible. Currently, http://www.parisc-linux.org/ is set up but not active. http://www.thepuffingroup.com/parisc/ will remain the active site until everything is ready to switch over. Each of the above items is being addressed independently and have separate schedules for transition. We will make sure that notification is made on http://www.thepuffingroup.com/parisc/ and on the mailing list prior to the transition. Thanks for your patience and we apologize for any inconvenience this may have caused. Jane -- Jane Vinet, Director Professional Services/Canadian Operations Linuxcare, Inc. 613.562.9260 (tel), 613.562.9700 fax jvinet@linuxcare.com, http://www.linuxcare.com/ Linuxcare, Support for the Revolution From dave@hiauly1.hia.nrc.ca Thu, 9 Nov 2000 14:54:00 -0500 (EST) Date: Thu, 9 Nov 2000 14:54:00 -0500 (EST) From: John David Anglin dave@hiauly1.hia.nrc.ca Subject: [parisc-linux] abort in eliminate_regs compiling glob.c from glibc The following abort occurs with a relatively current version of gcc from the cvs under hpux and the parisc-linux version of the compiler: hppa-linux-gcc ../sysdeps/generic/glob.c -c -O3 -Wall -Winline -Wstrict-prototypes -Wwrite-strings -I../include -I. -I/home/dave/puffin/glibc/objdir/posix -I.. -I../libio -I/home/dave/puffin/glibc/objdir -I../sysdeps/hppa/elf -I../linuxthreads/sysdeps/unix/sysv/linux/hppa -I../linuxthreads/sysdeps/unix/sysv/linux -I../linuxthreads/sysdeps/pthread -I../linuxthreads/sysdeps/unix/sysv -I../linuxthreads/sysdeps/unix -I../linuxthreads/sysdeps/hppa -I../sysdeps/unix/sysv/linux/hppa -I../sysdeps/unix/sysv/linux -I../sysdeps/gnu -I../sysdeps/unix/common -I../sysdeps/unix/mman -I../sysdeps/unix/inet -I../sysdeps/unix/sysv -I../sysdeps/unix -I../sysdeps/posix -I../sysdeps/hppa/hppa1.1 -I../sysdeps/wordsize-32 -I../sysdeps/ieee754/flt-32 -I../sysdeps/ieee754/dbl-64 -I../sysdeps/ieee754/ldbl-128 -I../sysdeps/hppa/fpu -I../sysdeps/hppa -I../sysdeps/ieee754 -I../sysdeps/generic/elf -I../sysdeps/generic -nostdinc -isystem /usr/local/puffin/lib/gcc-lib/hppa-linux/2.96/include -isystem ! /home/dave/puffin/linux/include -D_LIBC_REENTRANT -include ../include/libc-symbols.h -o /home/dave/puffin/glibc/objdir/posix/glob.o ../sysdeps/generic/glob.c: In function `glob_in_dir': ../sysdeps/generic/glob.c:1446: Internal compiler error in , at reload1.c:2516 Please submit a full bug report. See for instructions. make[2]: *** [/home/dave/puffin/glibc/objdir/posix/glob.o] Error 1 make[2]: Leaving directory `/home/dave/puffin/glibc/posix' make[1]: *** [posix/subdir_lib] Error 2 make[1]: Leaving directory `/home/dave/puffin/glibc' make: *** [all] Error 2 The insn that causes the fault is the following: Breakpoint 2, eliminate_regs_in_insn (insn=0x406a0ba0, replace=0) at ../../gcc/reload1.c:2826 2826 if (! insn_is_asm && icode < 0) (gdb) p debug_rtx (insn) (insn/s 2711 2709 2719 (set (reg:SI 6 %r6) (reg:SI 28 %r28)) 69 {pre_ldw-4} (insn_list 2708 (insn_list:REG_DEP_ANTI 2696 (insn_list:REG_DEP_ANTI 2702 (insn_list:REG_DEP_ANTI 2697 (nil))))) (expr_list:REG_DEAD (reg:SI 28 %r28) (insn_list:REG_RETVAL 2708 (expr_list:REG_EQUAL (expr_list (use (mem:BLK (scratch) 0)) (expr_list (symbol_ref/v:SI ("@strlen")) (expr_list (reg/v:SI 4 %r4) (nil)))) (nil))))) As can be seen, there is a use in the REG notes which will cause eliminate_regs to abort if it is called to process the notes of this insn. It is called from this code which is near the end of eliminate_regs_in_insn: for (ep = reg_eliminate; ep < ®_eliminate[NUM_ELIMINABLE_REGS]; ep++) { if (ep->previous_offset != ep->offset && ep->ref_outside_mem) ep->can_eliminate = 0; ep->ref_outside_mem = 0; if (ep->previous_offset != ep->offset) val = 1; } done: /* If we changed something, perform elimination in REG_NOTES. This is needed even when REPLACE is zero because a REG_DEAD note might refer to a register that we eliminate and could cause a different number of spill registers to be needed in the final reload pass than in the pre-passes. */ if (val && REG_NOTES (insn) != 0) REG_NOTES (insn) = eliminate_regs (REG_NOTES (insn), 0, REG_NOTES (insn)); ep->previous_offset is not equal ep->offset here and thus val is 1. The use would appear to arise from the rtl generated by expand_builtin_strlen. Anybody got any thoughts on how to fix this. Dave -- J. David Anglin dave.anglin@nrc.ca National Research Council of Canada (613) 990-0752 (FAX: 952-6605) From grundler@cup.hp.com Thu, 9 Nov 2000 12:12:25 -0800 (PST) Date: Thu, 9 Nov 2000 12:12:25 -0800 (PST) From: Grant Grundler grundler@cup.hp.com Subject: [parisc-linux] tulip DMA mapping Hi all, I see a "bug" in tulip's usage of mapping services. It's not the bug I was looking for unfortunately. In line 217 of drivers/net/tulip/interrupt.c: if (tp->tx_buffers[entry].mapping) pci_unmap_single(tp->pdev, tp->tx_buffers[entry].mapping, sizeof(tp->setup_frame), PCI_DMA_TODEVICE); 0 is a valid pci_map_single() return value when the system has an IO MMU. The system will panic before pci_map_single() will fail. The driver needs to remember some other way if a buffer was mapped or not. Or the Documentation/DMA-mapping.txt should be changed - ie add this to the interface definition and I can reserve the 1st mapping entry so no-one uses it. Should I be mailing Jeff Garzik directly? Or can someone who knows Jeff point this out to him? thanks, grant From rhirst@linuxcare.com Thu, 9 Nov 2000 23:00:50 +0000 Date: Thu, 9 Nov 2000 23:00:50 +0000 From: Richard Hirst rhirst@linuxcare.com Subject: [parisc-linux] strace working I have updated the strace source in our cvs, such that it now builds a basically working binary. It requires an up-to-date kernel. Outstanding issues: a) ioctl defines in linux/hppa/ioctlent.h are probably wrong b) there is a hack in defs.h to get round a problem where the libc wrapper for ptrace() isn't getting used c) there is a struct user defined in defs.h that should probably be in the kernel source asm/user.h d) there are probably more places where we need to add HPPA specific code Richard From dave@hiauly1.hia.nrc.ca Thu, 9 Nov 2000 18:57:13 -0500 (EST) Date: Thu, 9 Nov 2000 18:57:13 -0500 (EST) From: John David Anglin dave@hiauly1.hia.nrc.ca Subject: abort in eliminate_regs compiling glob.c from glibc > Breakpoint 2, eliminate_regs_in_insn (insn=0x406a0ba0, replace=0) > at ../../gcc/reload1.c:2826 > 2826 if (! insn_is_asm && icode < 0) > (gdb) p debug_rtx (insn) > (insn/s 2711 2709 2719 (set (reg:SI 6 %r6) > (reg:SI 28 %r28)) 69 {pre_ldw-4} (insn_list 2708 (insn_list:REG_DEP_ANTI 2696 (insn_list:REG_DEP_ANTI 2702 (insn_list:REG_DEP_ANTI 2697 (nil))))) > (expr_list:REG_DEAD (reg:SI 28 %r28) > (insn_list:REG_RETVAL 2708 (expr_list:REG_EQUAL (expr_list (use (mem:BLK (scratch) 0)) > (expr_list (symbol_ref/v:SI ("@strlen")) > (expr_list (reg/v:SI 4 %r4) > (nil)))) > (nil))))) The `use' arises from the `__pure__' attribute in the prototype for strlen: extern size_t strlen (__const char *__s) __attribute__ ((__pure__)); Still haven't been able to figure out why the REG notes are processed or a simple test case. The cpp'd input is attached. Dave -- J. David Anglin dave.anglin@nrc.ca National Research Council of Canada (613) 990-0752 (FAX: 952-6605) begin 644 glob.i.gz M'XL("('T"CH``V=L;V(N:0#M??MWV[:2\._Z*]CFG%[+<1I+\BO5MO>XB9/X MJV-G;:>]W6P.#RU1-F\D4B4I.]DV^[=_>#\'("DQS6/%O9M:P&`P&`"#P6`P MN!?T@F^___YA\;X8Q_/BX76G@]S:Z^'WW;N#^[RJ;%]S??!CT$T?>"=!#$SKX?@GZDKHP=+$^6HLN_F$![R?2SU M'&,1D#I(@O?ZGLY!^=OPM.@+#/H\7*3)._SC%DWE=/'NX552%L9DVJY?0*G# M%L847DH._$O6%`QJ%XV*F57P,_O0DM*8!7W<$L1O$T&T5EDJ7!QFV6C+M!&$9EF2=7BS(.PV!C(PS1 M(EN48=CM#AU\&>S[!RA`UN@FRH/->9Y=Y]$L3-);1D681K-X"\PI;K*\)/D& M'>7[>8PF(&]JEH?ED!$VJ%Z@K,F,T1GB;IX5E/%Z)EN3[%S)FAHS$T)9JX!: MR<-%D3_$73F5H^OJX?5H]`#_]V8^CQY0#/WO'^W)YI9CQ#@^Y:BD6143P?.H M'3Q8EUH=3_.)WMO>:;EBK,[NMXD3:YIM$]GDXY-ND1;)=1J/R>PKDO^)V>2S MF=KOMS(J3*Q[K;+U;_G$DEY/+F`Q:K&;"-`P7(3XCZ&=3Z0E`2!_`1"XPW`^ M^B^0.\W2:Y*-_T`]BI8+)+E1+I+$80"#DW\XVC\6T1B/!;B@"<^AZ9RO+P$Y M/ITK".=!"+6*<\T$T)A&*4+_]O9`)"K4P@+3N(O^'?1!)+(X!7#PR<%>]._> MCIN[[FX1!05%G/=8(_@C&H]S(Y?W)/IS'-^J;6&#AZ`=PQG7=@8;6`E2/<`B MLVP3%!+L`1YW=M&.OG#8.,@V"2K5C8)-@18M_N&(68= M,@Z+&"#V;?Q>;P,H(I+YB`^W#L@GQ$)UX80A1FGI&.`TD\UJ:.A."JB\,GPY M@!?'))GZ<5``"(<`0I/>SJ<3E,YA,U<=R&&!UOS!K>0@&:/H7_G9>[H M-#:DT=B:03.S%/U"1(?GH9!R7T>@&5QTK-6,VS+-I,B(\@-@FH/`/63));]".N"19 M*KYL3M!3L837\464C_$O!0@1\I8L/$0V!@$V'^#52&1H&$@JQ?`AX$W&E@9# M+BHM=G4$7D%"RNG`X"K)NHN2,L%*JZP(KV'NBAAK%[/9>[.0I!`4%QQ4K`2^ M"F9A'A=Q?JNR>H9J6:0EV))9F-VE<:X"OTW2\=#/FAECC6S';%'&[ZI:3X`H M>J,DT$EJT[-T9"U=)GGY'54%JKHUOQ/]2JE""1@FS@N00RC[#@U?RB,HE_P6 MX\Ⴁ-NBX1Y@32N6&,1;YJ?NQA&Q^9$I;!;X+O-IE&93&.-\5S>Z,.3 M<;>"T5>1P6B4D,=_+))<'9PH<8Z'K&-\HFQ@JEU%>9[$N9,J9_-90;7]GH6> MERJ)P._MU3"4:E(>F]U=MCUUP\VWV(&YTQ9;Z\#:8G/EW]A;"W6*;ZHM98[O M@@'E26ZH92;=*`3V?D$H57SSH^61K5?`-F`ZGX6*%BBJFII-MH`!VPCJ662O M%UP+35?)HGNZ@&_M]$RVK0O$]D[/)GO+8"'1*GFTD;*-9B9IB:)6JME$)0_F M$+DD!\I@&\2@@/1UL4$+K(V:V*(%8JNF%23+1Z`N(JKNQ^U5>&_$G0%X'DY3 M,H0!64U752JDO>UZ`32ZV`XN4'9R-A#=809\H^E&1-BJ[?TRZ24=##!RV^+1E;Q_*$N9QMSA6!8(P M202J=4*?J`I084"M3TS6)R8?G3O8&6+W8U:V/D]1J>[M>)4YCQZYT%4QP(*W M\!V@+(B&5^M3-T_T_"&PS]J)BA1B6^1_'N,C]^[0+(=/&[P%GSL*XG,&;\$+ M1T&B1?D*/N$%';OD1;A,>VT4S9MNXVC.!1M'`X:HK,SCZZ0HB7;C*WR7Y6/! M3V6(ZSX6Z3B)4MU+`6VRT%[,S'H$YE&<@[XSTS8]XFG//$Z4&CCLX`"F`?:S M-)VH5'BL='EU`:FHN%IR.7)O=IN<(-59JV!P>CCHDP("! MBPJMC7ZK:7)=Q+)9-/O'/!&#)(3FG.#?)<6!PG:YEHU@7R]%?G[OZ.:QE1 MW"QI8K#!/!@FXV)+8MX,\8D`6C'):0TV9^)\,G*-SU&$F*X;EHG?C>)YZ2JD M\\HHBE.S12D5$Z6A\Y9:NE13EVMK0!Q;`T.BP&WV(9`+F5$6)1-W`GZ2K%]A ML$>KPDYL(:]DJ(>+.DL$\[34"NYX^.-E"LP6A1=:,]L:-LN-FR4'3MUI(@5^ MA2KK6OW)&'E?S*)1GDD?8;^B9Y8!E@9]E>BYW)B9")4247BJ!(;/B@%$'$4" MZ76BBU7ACA*HGBD&#'S#)4:G0@%1*E))JX)))265TE5BDZ7960= M3@(\F:["E!I/J*T#L<_`U;!AGMI`)JY8F['RRQ# M9\PFG3+&%$^P`H-/2]V+%JG,U2S7("&]AC6Q'`D/4A,;BH.M0-+/(8>=#TZB M'"M`-57UR)HN2U?5V@M7-U&KHP*[3F6-A*2?*X8$U?N(U=-3F4$%[W=\^'SH M5(P@:/6LT5OP#'&,(US'KJDC==GKXZ:I)O5(E*H7%%/M!NKJC(NCD9 MG'=4,0'U3%W>UU)-=4&[6HT--2F=VAJ*E*D6H0V+2XO2<#?4CXRR[GGO.+WQ M*DQ#Q]!S]38ELA7Y[JK8)]];$N&NJC^*"'=5UJ((;TV(RT]X0KC-[1W;,!X5 M19Q+FQ_)HVE&%C..FWG0)OI>L-NO`&8L)K?DPI`"A),HF=KLI9E)EL(JFY?1 MADT&]R:`99&.,/YN)[`]T=*,]@J/^`,2/J>!=BC]M"H<]FFM6:?G,P^8Y(CL2V<'SW"WCI?*<9*IGGK*A)@F5W@3)"'$ MD-=S.D;1M>?\VG-^[3G_E7C.#W8@6=!GN:O,]BB_5F9["YATWB@G_XMD6B9I M>!LA(4P<3Z[3Q8C_M$7NO6!_%=D#4N/[E"N2"EV!DSZ]?QZY^T='SZ_['I^% M3X]/C@+\S[`:+`P-0'UY(/^*Y6$?R%'+B)4I73P,GX7.`,;K=62]CJS7D?4UZ[\X>*"7Z@"ZCWNC2Q$;>M;J/I@D1?"D-$`8X@Y17; MTKO2%(=X6NR[`ES8=S9]:Y^QO0XZ+N`[P6[VZZ! ML>OMC=V!NZ/Q4R3N%N\Y:]QSX,0/"KB&XIYC**H=!^L71#P8[RW(XO@MADH= M!IC>W*$R#.<9#70E9R@SU-.)^RR<(`@MVJR!A5U-KH5'NK6S^:XUZQI1?:M; MR1.81 MI`;TUROO>N5=K[Q?U\H[`#5^MO#&Z6+&MAS/'I^=_AJ>_1+\&&QO*2FG9_@_ M>LJ3G_7?+XY>;'64E*,7+R]_#X]/7[ZZ5`&?OCHY"<]>71K)QRGAQ='O$\H-23HXO'Y\G*/OH_/SLG(7QMEI[?!&> M'%Y[FD8GIV>G1_1\A<?O6=-T)S?3QZX>5QOR5IE(E+&;NO>;>R+1\G(ZT>*X0J?,0O*5 M"%%C.J$4\??0`E!Z7P`J:78!1I(`9K_5QPNH`+4FHZ04`Z6HAJ%;IFM1[B'A M3=QT;]#*']Y$Z7@:4TIUU\)9-F9/'6KF?QSJ'H">Y-F,/8UH9Y99*%`I*P'Q M(->XQ+N<^`$G%A,E^P3C.I*\69(BQL2XE9@:Y=6"Z)TC0Y8H,Q"^S(9*#<1^ M.5E,24/T#G/V!1]=UGP,PVR!W9^'[JP8Q^M7ZI],H^M"2U%>IY2]HV9CW])H MBD,6,^Y+>RQSU<8J@,-02S!Y!R+Y-70\-R(Z=9+1$OL--BY+,3"TW5D535+$%O$8RZ7#`3[P`J85;AP>[\JC&.)< MS`?J66VE#/A`9M+L*DGI0P6(N$2T3`N>^&RYZ*2R[(I121&2Q5(40%CJT[+$ MAL)P*FO]BKM\\-EV4JOU*>YQ_U[,YJBO38\YP*>.>H^C?"U.OE)N%N5OXUQ[ ME4.F;K(%);!\\S;#@HBHCI`IY&`'[X6WP48228`W+&3HCN/1;8FO.)GI98(CAAF7ITLID?+*SHCI&U-VQE54Q%8.??K*DP75 M0W.@BM!:!2/#&52;-C**Z-91_U4T>KN8LSRP&%//#>49Y_+7\<_Q/[0JZ?-.J`VO>V]HC9:2@,@B779;1E=X/V=U*%G.A2N7W$ETJ/#: M#,RN-5(9NXU4SCF9K/>HF6[AUOI2)JL=J:?R7F0[);,+9;+6?Q8\1P,I0_2/ MPLQG"A%"A.>1X"0.82$WCR*DE.)4DTW'^$\>P]>*;Q:.%CGJ]^EB1N:G]E(T M[4]1G+O6&0,"UR:4/T0C>P62?9IGCB0$''^;<@!J^4(>\($F#+V\Y334EZ"0 MA;-ZW=M5@K%CRVGP`&W)9!*SS;SA0]9Y2T11?HV\<#[%SV#RFY10+OG5#WLA MOL"2AL.ZL$@VU@=&VFIH1`Z2PX:(A3$>.:X\(H==F0BWZ%#[.3"TT\_HA)RD MG*5XP)O&6,"J@\;*E;,*OWI=QT:W"2B..OE`WB0^9OSNZYUE321X1M.L@(CO6@^N2?91"/:37>750[2J7&'0[+<+ MG+>'0=.?+F!!-(-FOQ5PAP^?THA-_,>0IPIJ-\E?(IV3M8G_$*FB_DWR%S$\ M$`E!J$$`G!3-#]`)$C@*ZGLW`H)EJ77A6\&;)J6A[HABI&_5V]#TX4WQ`"ELW5%E0I@ M'2"X:IKOL;2HY*-RUW$Y4C$@ELV-1J*\^0)#,:/R5E`%/J&/HU="86,!`&?5 MC@8[?;XW'D/@2K/$")Q@<#+.0#9*N$7JAQ34EOE[!V0%BV\GQ2A*-88$,F2> MOH]0,YRS0+\52N>/$H3/IOUV,L_1WT:?P!34(<"@0`VW(I8BW&_1.+4FQI8$ MDN640@4:D48I?DHG2LGJA):$2Z)A@G[K906(=A3L+(]6*%]YI6XY@O(XYKIK MA(28-3B,F4LGW9UGUBF0:.)A2+&O"._J3#^L[YGHN9A5PQ.J'_9B&\!F4< MW=49T&+[56M,+S.H[^J,:KD+K$-%S9%]9P]MVFG@Z-:'RIUOK-">V%=-M?H- M;K%Z<\?^@/OW`[DT)+WEM^_XY,M"1C`/ZJMWD\WBAV.T%>/^2-<(;/0PN_KW M.,EYI&M4`C%N)BX!/&I>T$,=%&J$LH5QFG)25]M%FJJNBT1%35?&5Q[/T/(* M!]G"!Z/&(I631!L<[2-MK3N-[_1`,I26IY6Q<]UQ M,CT%L7@NE*:R"O-XQ2JK*W65,P5KH/(.>Z-#X2:@P4NX5B/F\"J-Z`Y!QJU8 MZ_+,JV"?Q:(Q[68U/I_EY"%M`#9[Z3Y([IY5.J/K9,0W3=X5<-FF!MZM&$LH M5*'%*)\A<4O:SC*>9_J? M&!6%-AU%C,U[4KY8_;T%<12*=HXPW2Z'"FZ2U/M4MJ8Z]Y0VH'U9:W4'BOT( M_V&%AT-5XC!H6GN=HIGK>V[BFHK;29;/(J2U??_]]\;Z(G3+90H7O#10ROD> M6=UZU(INO3RQYXV-%>XV(_`06K[S:Z.-MPTX!*+K&/C\3&N]*7J'I?[*Q2"> M1>^P0')55:L/(76(YE-O&4I*&&X%@ZU@A_K-:%:GVW;(K4O5::N`00K1Q8RRTM=FZ6O4]1_7+]LQ'D_<0P_0Q3X]) M+`55`7%`=$P83+IAXS$@?,8*&YD"K6`U:6]B`#$.>WPT5(%V3>@8/,H#4 MKE#KPVUAKU7.IL@N!BSXV&9?U;_86L]QW/E)ID,8]TWA4H(HGG3+8T+H#&&4 M2HO\N/U[X)JV"UJ%WA3EV!4PH>,3D'$\31P;=+PC]&DE_`/WZ"EO':D@0557 MXO&UTR*^#=+;(=S?/1#AF+H5Z':0[2U3`GTEH9E,JXYGY".50A$X+BWWV@^88.=#W&#/9 M(:K1<5EA6J>P#Z:&2U).^U\BPJ5K^=]09N"S"9`=+#`;Q!#+?X%RQ$:EZSN, M(2J8@R7<8\]FBLT3N`&2*XKWG]9%9#2-IG&4QWE>==I'/(HJ0*@[D6=0:#76 M5+-QS;5!R0LG]51M0LNA\O0S]A<$0%-[\O'YCJ*=A M31RAA<08M\2#NL9.@L!5\<,XP)G#!YVC;#:+4N^!F+H,.T^0+;5UA/Z>)6-` M<]7!%D6<0V`%]6[,\+4!ZL.MT,%20VZKT8&-"<92O6M$;>,$0,1M:U0L:\V0 MQ>U-NNVG26:(XL=7)>TU!SWW1HVB5=W^_"N9_KB!=%=1?5S@;%#P\P>S,,V= M6F'E8M4$IQ4NP? M_YW^8TO=;'D&EU\[](PI_JT2K&L54]?KX>O;;O; MSN4+Y>[M^A:W>\'>CMLGD^)W/"YG/<-J^]UIV6V=>-<^HJ?`#8_I]5-Z[XG0 MTD?:S0Z.JYMA'WX8O@9U3XL:'7TVH*MGT&78D>N(@@JSBV]3ASFP]('5Y]&? MBAZ[CKBZCKBZCKCZM41NK9H`PX\CAVAMS40S(*?#)(/\]X+=KT@QF#X2H7["M/C"Y#. MZJ?>A4<*S#C!1QV5E[;6,O?O_/"&I_GS\8L4:7!CXQV;>58D[[0L\32.D=4& MV;W]71"U-&XB)IMA58L@=V MA-:%X$-M<7J;Y%DZB].R,*S`=>`[4`5W63[&B_ ^]!L<2'!7XX.6+2+7( M[TM5HA;Y:.UJ`&TP_6#;S72@C[[.16V]8UGO6/Y/KI[][0;3'_R4P#MIB=0D MM'GA?PPMD`+IX%.\G0C$7[I"I=Y#&(W0]L#>-)![H7S;@C#;Q]SQ(ADW+*TS MA;U>9"W[AM?+E#KYJ/[^BM-,$9>VWXS54NDQ0K!AUPT#G_0Z<6!46LY.V3D& MW76+;2VIUYJLA/M).6-;&>69[YE]R\&!""1BWH0*F[&*WXO`V)0NCT7:J&Q( M'\H"9XK=HUH3]?[T-M)S).[!9LR_!,!*/$PJ!!962T*+10$^JDOLGN``<< M&JH+84W&M)OND-)''!-8PG6>+>:`$R[#IPZ3"AR6A)VV09/>QG$"N%UA0YGM M5\*`%2F']#?'5LWTB!_=*2Y#^GP0UZ%E=:(8#C"9(PT:F]A":@C3KHR8\$8M M-@?'B[DAI_7,OMI!_*^^"B@.6)B"/S1S9+JY/KZ+1U`P%9N\1MDD1RTNE/:((2B;M<$:21C'U,D(,Q4A@6^:$32M M8+F=N^:4KT46+4XL?F)4/&DR$OV%]%3`53*,W^%@@DRZEE&Y*+HU;+B=BKT\ M?CL"3S##FE$%RP8Y?N>+/QX1OGP4",)J%?X>/#T[-3(TT^ M-$;33@]?'!E%7QY>/C>3CE\>A3^_>JHD/7Y^]MMI>'YT<7E^_/CRZ(F*\RR\ M/']U^EA)^O7)\<7ASR='2M+%[Z>/P^,S)>703GIY?GRFIUR!6')\\,=-.?@DO'_^BI)P^.S][]?+" M@#M[>71J)"%F'!V^,!(O_\MD,DK\?V<_AX_/3B_/ST[4\H>_'CT)CY]<*&D( MX\GE,4)P_S\[/3LU<7 M"E,E(L3`)WH&+V'G/,59RN\7AR]?(AC2$6KRT8N3,XV9+"4\/SQ]=J2GGYW_ MCD@YNSQZ?'DL1R[)N[@X?':$AN;%A=[(BR-4\?.S'YX@6AO'LY_^' M$&J,0(/JY/@"56+TRB&80@;ADZ.3RT,C$Z4=_D[8;&2\^$]H=*!4@DI/_15U MDM[:EZBI>#"C)#D*+E'WFZ/MZ$5XBOXQ!R9.__7PY)4YYA"&_WQU9"6K#5!J M_!G][_#"!$:I3X[-$8X2+QX?G@"P6#J<6I/N[.0D_.WH^-GS2Y/TH_]\=?PK MFH&HG\VFG-],-SBE>9C2*W#W1#/T1-.#Y] M8B0].?I52WEZ=GX))R(9J"5>_&;!H9F`^/;DZ*E*S,OCXRWM5_BO2S,%B\&C M2R.1O@II)9]=:*41][7!62WY%\OG_7M9KQ\-H`2=]3RI.J?M6XF2;9X-08K MD@@&$$G18$[.T.J@(__M[/R)D?3BY_#$6DU/_^OH7%-5@+E[`5!Z`9!Z\?S< MI)4F:5"O`&RO[%:^(HTRTI0:9`M.L$9JM.HD/$&*D97XXL)..[52+HXNK30T MXB_-P?WSQ6YX?/)RT`_/GCX=:`-#R_KY^)F9=_)R;P=G[>W8.0A8H4VV+RR-5 MVKQ`VX9+M!%@_%!S7J&.>HG*,!&M:9RGS\`,I"B@>6Y4C%F'--'?SO&"20C3 M<+U$R["9>'[T#"F&9@(@%B^>'^EJC[69NGAY^)M6`@V$PR?'6$,Z1_B`!=H) M0)D7/CF\/#3&GY&C=2P>,6>O-&WH\O>7OGW,*U1S2/>F<*J&_^7/%_JO\/#Q MX[-7IY=Z+^`,K)9>'AF);!-FI%Z>'VJCX>)WM+T[>XD3/@PA>\7C"V)A$'N- M+9%\\A0M^T]/#I_A]\A[V]O;'"W+.WE",LW4XY_MI--+`!0)KL=P,H@9IUNX M22+##C3!E*Q*>WI:>RQ`FP0;1*<&R+>;;=LQ2;JJ(0`G8UHJM M@2XK+`NOPR*%VW$69'G3ZNXL4[POU!("SHA/@6&*,E?!7.\)36,C!BP^5!O3 M0#'S9&R'&%?S=0`0Y#J?6]',33AR@V-^G9!`&CQI3HM`*$%`TYA<@)!;2J4X MFYZS[NX>.,]93910>QSM0O"%SB&[-86C,?*HD$,NX-X0^;$#X)H#7%?DQ]=P M=[+`5^08K1#&=QS(1#EDHV$"K`,&4@B'8KZ*R5&;.)-S=MJ",H2?YBT@:A!8 M'AN`^2+1CA5C5TFSX,))"AL^-LTF*09@?DU)X;]C5TFS(,`5/C0F6?X6/O_C M$+I1VR0?/69";H:28\0 M/.*L58A-$(;2(06GV->)O1ATHZ1S!\GT5/1_\C2]6C/TX9>#VX$]JYTM]WH0)3#AP5J MS8@/>]HC]#SWUGP]BCQTB0IRMQ-\B;COX:?ZH7YQ]";V4=[O>QRV`>IOLJ+4 M+Q&Q\2>\`N$96:A%88<^[XQFY;%\5P)P6:*943G.9E&2@G3JE>@UJ,66H'%2 MO$]'EK!6(6YOHO1Z,;?5!BHI;[.WCO=Q8,^M/$-YBI<4?4@59^$Q$\WFTSBD M;P_4"9DF(+B;HNE]-8JFIG,-<_(L?3)%@%$P M,>=##9Y@8QF%01, M>$Z34*-EQ*\D'L"7,\"M*`G4H(@WE)9FJG,/0O=HQ^/"JFI^^*JDO14>S4P> M.QA,RNO,-3%(/D.;-Z._\$O)FGQ,IN/8CD_%%L/\_1P0$V_C][;264334I,= M3#(P'$+?Q@WB;8C'.(2'J?E3B7$777D#4%+5%\@H,TBL%J87M=W8$@Z6AI01 M^#:5M@;0VV%(!LCM2K!!1%<\C_*XR\:W-UJ#+!1A!\EF948WJ"=Y$3%.!X[+ M>E:(D@9._EJYAA<$+%=]-&Z7_VM;*?6!E6W=[.B28>V6&G]7FWU#D6S MKFVYZJ;UUYP_SO)+W`K21++S)@ETPP,M&#G_"\3U*LS1!:B[& MATK%HS++WU.358*OXJ10A)'R)BGP]JIRJNB?VH*&1:WK)%J#S6L?9J;SVH>N MO[1U@<-SA]VB@KK,>$ZCN28]9#CQ;,8'J'1':)-4[\;'Z M7#^CT=`N<_BB(0#.7G3)WO1@1&_U$BS[;*+Z^(R:GAGAE-;8BZ!E'3 M9J=9R%!O>&QD'=,D0)31.,7]A-7!11Z3HYF]@^HH0^L.$%W8YDJ M0P2)5,6&M8Z7LHZ7LHZ7\C7%2QGLF#+`CI3"7G/`IT)W8Q()FJYV\SNRW`W5 M!`J$D[@.A1+1'S3EFJ=YI1[)B%;#/Y>1(.S"$Y@6J?63?"_;A<)+V;DDN<-K`Q^;9M#3V3311 MRQ.[)S//J7\QSS4+W@PI`L8YU:LVXG?Z2ZB*'4TDUW;HA88P23/$]C'^[Y`E MT4WM&/^7"@><#!@PT-3#,6C2H0Y`>G9,#J!I#DO`0_QU?W?OS9#?(M*(VMN1 MMXDP->3LQZ2+)1+*/A95O+O@[N4A70\07E+`G$\Z/GJ&$`YEPEHS9>!#UD?D0#M=,8'B!15%\64;>*']L#C&-@?#MN2 M"#@I3)#/R?3M[>PZ^*KKL30CV,0F)P"1N1H:(TV4PX>64$G-/9%`AK(.9?7% MA9R/T^J4:N502OZ^9L&*]=Y!+YHIC2D.;#[5IQHH[*%9#.T_$:WL;2GX)*[\6\91XL70M0R='ZW"CY0A&LWG7]#Q_%C.VW'//D&- M^]T.<.PY7^2Q$N72YK6H1N7VZA6I=X3BO$@0BH_>%*6B=ALCJY&O"N*3=S(& M\B0N()>,6I<^U3';T$]6[.>-NJ(BGCMV$0[J=0?/9>E?H@7JWM_7"M.&J4M0 M=;>*\%7L5VW7!V#[`&])J1]$37"^QW+L1BW7%WTG2O<_5OU-]FD>LQ^TDP1J MI$VHJ-.Y.P3J=-!TO&GC*5B!B M]U-4@:]2'O%+NO3GE?,%/"D=-<2&^%T1];W@T:"9P=>G@EGO"R-5D9F"-0B: MHP$(>["99U:PWK.M]VSK/=M7LF=C/C66/+"=\KPFJ+LH*Z/48'XV%7R=^O0;=C&FZE,5Z6)3R*AU/(@($(A8CMF1I@)/%"0M> M8^Y82']ZSD-7<+9H_\FIX&NVZCW[0V]O"&9@UU2DJY2C;!S_<."!&65Y/%[, MYC_T/$#XVBM*^F%_R,GX@--1*TA6DD9E//;0WISTHLSFN$8?Z1CF-IIB&),J MG#6G)*D'9#N58]_\^)D2Z3?19;(7L7*RF)?Y4'0E2DA8`B;GM\-C'*CZ\/+5 M!:`5E'F4%O0J;TB0VMM`BQ3!83E\_EADI:0@CV>T]G%RRU[\#;\.4<5H04@,?6A=NH`*M!N7CNP^N]XUP?5A3#&=7^(F88UX!\T^QO2^#$YV`)Y2_(0'TW"&V!+JWM'M'CYX#`]DR5I M9E[?D0DOU8@B"A&R=9)X,K$\EH-CKF"NT)_%Z][@S9`H3I1I\%TLNAY>#068 MEHY&1787Y\[\"YIJV%M]`S]:C?((6M$E[799Y6-;(3' MVW^=H:F,L1:-5VR/KXM\5%`MC1$Q68V(1C3`^AL?N:NR8_4NA0CNV+JTZ#YW MQ(3FH[)ZOHE7/^%N;)&8YK3`_=DF?U;O7?:I#0!V=&)I:Y?X%0E7!8S1@%J+ M7?L]T4JS:C:PV?KW,=K:2CN];5QR170UMAGWZ;?J8*!?:T."?BZF=:1=21P[ M)CB00LSD4*>NR<.W]2<73^G3J[#83]E*Q\7C-NK-#Q9%O..CE+87HM4=*I;6JHU_]^TA=-:+?[GRR,G;I6J(;=/UFV^]516<=:U9"N M:9UQZ3([ZI3JG5[#3-+&:&W2Y?XVP$*S4]OHT\X(;C:$FW=+'=M+&RWYNSK& M;@^P'M5<7-KM&\?RXCF'4"N5JQ"MAP7MV>P&&RS(37>["TH-S!O/085:"7:M MZ2HF:4]56T&O8HWRG&E8#:M=6[,1[CWXL&AH0(2F,%#8Z=Y.I,5\3L%[.]'> M#D`1^%B[>@QC>?*\+QYB0YTXV1X\\AG>.NJQU:"/-J9YE(ZSF2/@1,%SK9". M,?R$2I+2@^P8+"(=M0B,UZM21HS"H&9P?HH'!XBCE9EXY>$HLY_2AA#[J7HD M2EBP.5%/9FE2;B<1W,KQ*<*H7+H42>/XVD@IXKF!"HF&D!_^ZB>)C$YY!UTA MO+93JJBG.GY"(2L$.PRF@G%8P2,ZWHD)6%26&`65+I)>?IF-CR7-RY!7MTI] MVA%X.>&L^>:9;082B]>;^M0T#4UC7&CGP`PBQG)CG@N<(H3ANV)QE;P>O`&% MV11&+/+3Y5'/*E#_NS%JR6E<3-T$(];=1E-9"72<@H&',WMXMK5"M;HK$ M_+6SV#S*H]GK?4HE&U2LKW2)!91^]WKPQGEC//)ECIPY6/F7>/GTEEXRZKU2 M1J846"KA<'P0QW1BP]`AM)0Z8UFGM].K+L=\'$+U-Q?:8X\8J-4,2C\Q@ZI( MU5@T^R0L^O>7Q*)"$FN+JRT7+2P*3L=<\V)?NZ4$KQDU&_*8TG!:I.4Q M0\QO7Y$]QO*$3O(XUI!I6@))'SE@S'T$J2+B-P*,VP!JI@S18N2QOEC?!%C? M!%C?!/B:;@*P]P0M62"\H3491_--\:LZ5SOD3M_&A>]J>;#="W9W]GS&#@W9 M[5+K0D=;T$A$"QR\/9JBU8R+U4V4H$IRDCF+TU*DU%TO5(*C*W)?V!7..=-)NKF5I")?@IX/XTH&,>AWEUUW]EW['K@UT M5@=2C"J&6FS1<(1'JR&A1@+\+$!Z6R,@E+!*D9#7874Y,^`J`9>VK3Q)KP'` MPH/7#CR/YL%"G'WF\7P:C9@7I,HII*_5H%:/?!7C"PJWKN?W:/G9VQ)-%MDH M_&N*QBL8.'SVMJB"!L#)W4MW`9.>L;<*E&-U)6V116(8"/371WD*F"54,-K6#&TZ32Y(CO MZN!_Q3,QBUDL_+W&<9K-JO!QXBBJ*<&EGJM0A$I*+:P.#O!:E&JLNFKYFYA% MZQ$%3_QX=(N&H?"#TT1W.DZN$_;HGSZSQ_%H#L<$L&'QKAQ:XR:?K.;K&C4K M]_U56PE-_H-R37EJE+L%>N633UGY=B.4:;,[M". M\0Y#6\>I\[N1<]%WJ&C>VNY&93:[4M3]K8!7'(;D+TUQ8(AF5P4FLO!0Z7W) MM3ZM>KT(+2:W@`].JVOT4*O6VX&V!?E\%I4C6!N>HX086E!Q0;0!*Q97F7Q$ M6J\=92"=P!E#5NK[N$Z]:)F]11I%D]NN9-I887GY*R!(\04?RP:W2==YA)]A MTEZPTB$6*7XKVP;1EX]Y6=#-B0&D[THI4*-7V*S0_:6Q2=2SIUDTCFZO%8'. M4EZ_$7(FGL8SU:ITX(AOT]?1$[<(U`^ZTXMF(@@KG%Z,O7U['B^PSXME2O"X MO&@VG2I/$M)7NJ<(%+%J!?\0#5%]!Y&E.-6`$LCK0]19'TV%`X8&N^J)=<51 MV)9^)`UTXZHGPE4$.(L9YYP`::N>Q'Y$TOSGKLO18X_&UI?H3TXP\)<77(?Q3X4=((4W2 MN*!*@NPLO;?^6"2CMZI]CZ*8:T:^,BNC:8B5#(\NJQSNF*9%'"C1;/SH710: M)S/*N0R.O\B/T/)K_J?-PA6/H/!7?>1U+^@-=BN"#]HQ!?'QA.E!X/13WG$4 M[EMG@*AIH]'\O33'CI$6;9N%BQS>CVDS>.3?U9!#EA3>*1(*E>*SZ!T>_2Z6 MVD%^%$Q%/%>V(!3UW)9(XWB:S&RI5N8XTN0(GUI85/9L+$6_`9&BBG2$YD.# M.FII:TNRB[S/#G=(K2%M8TP]*+?JT.MV'L*:X1T>LS>Y?:!1\`W,:#E.(*0I M=&MN*;S*!,LKJ*W%$V\-+5>@^BCA3M/$CQ*Q5,]3S`)K/Z6UG]+:3^EK\E,2 M$4L->:":@)B+*!)'JD*AF:2=X;1-X:4:/'-+L;!JG&6W<1T=!C)_6M1[R:^B MU+%2@Y+8]J'!]:/MCJS>(<1-8SJB6M4F1&G@40*D3>C+@7\IL+C3:*FI>OQ` M]^"MM;0WI+?AXEN38'9%#ND,>*P`5GI]K$!F_%P+\R,0IEZ,CM'EK\(=VI0;PO6F9OYODL\9C MJNF@ZMC[4C.:W_8C]R)B;I%&CNAH+L[KX:":L8A4B)F$*Y3[0VBH&BWW&E`, MDF`!`N^5ZKC.`M.N_L:KEIEBQZ'HHZS=OG,/8$D750`#>ZH&VS2$;45T,'U5 MV[ZZ..64&Q5S^$3CY3W92Y/BF[64A9GN2^ M5V\BH2-"%=0D@1I"ZXT2Q28T7V(7!A#E7?5-WBQ59\.M'R`+89OR$E*[J76Z MZ5(3YWDFSG[0CW0QKZ`GZO8.5T>DZ\V0B'-T3NR2I MPWA4JV8)HR94:JH=V4]]94%_<(YF:ON"3R'5W46*6.+;V_T9N[)6<=M;RX:G M0,U,%2Y.-=A5U=_=9#7U>.L(K"5JU#V935I]9DD553M%U`+7T`-%_YKN5,'L MFT_+G#@VD#.X+J*I8Y_O?1),]U903Q'V8(L" ML0"9UB,%55]_$((5AP#Z/@A&Q4Z_"D8A>6_'!WPOV!_40&:\1?&GC`M$6(_O MY>:O^V^&Y+6JB\OSX]-G_?#QVK(MYQ M(-Y9%?&N`_'NJHCW'(CW5D6\[T"\ORKB`P?B`P]B;0#W#K9K#W?S0_/IP#]9 MT)SN>:<<$STB=J2Q0PT+;'?D\HON3+:@25`['C4PSEU(&PU$'`.Q"B79H' M]0@L#!#P'H1HG^9!+(;G*`(^4-9D]).8#G#(.?J"(0T^Q[C&PL8YN#2*^J[\ M``GQ#>"#8\Y_E;E51Y';X>R1%^64'>D MK#QF+4?1=Z$85*$81['G0K%? MA6*?H]AWH3BH0G'`41P`*#YTE%#1:GD12QAC"N[+,:0$%7;[%#K=#H;JJC@X M>.37"G=VO``88G^_R;*IGFE(R4M35UHO5U@N5U@M5U@L5U@K5U@JFZV4M%\Z M<'>Y=HUM+8UMK8QM+8SK=;'INJA(L#87R'_\]_8_ULOC_X7E45LN+6;_L[EJO7^OU:[U^@2C6Z]='6K^4 M?5SP(.AIR]F^WP!IW!TVL__M[WJ42`3SR+I3W@H/>;@7`P+]5!(RR!_O> M-IC27/5RQ7Z)X:@'NATP6<4\$NU5@>+I-,3#G@"Z3@J$3=)"@P*@(;"-._SN M)IF2`ZGB-<]Z$WQ#IWSPW7>!E:$X3J+O_GV>.51'#D_ZT*G!DWYU6R"#)O1I MA?JU.%FK=A/QQV5M3S;6!]9OKPL&'ZL+#"2#6EU2BQJSHHZ'C,%GTF'>W$'= M[F2RZ%&_D1U+[?1J$<*\B_V]51M-#>Z[V/_CCPJ:U8=[]92G==4<[5J9*GE3 MOVX3;SO\ZP5__14XVS=^!Y"FS.E>JJHIML&M0-S178&+J%*-I$2N&%@V4H<1? MY1P1E&C4X`^F"'^\:7I5@B*5*@9>&"8?&TMP/^C)W`\=_J]37:6CRK]E]XPJ MU&YE%-3;-*OCJ+J\OL;+(53>1E,Z/@HYDG@R,)PTX6,.`]9)LKB^F=XD/=B] M?U_AO^@G7':#HS4.WO$-DF1:)BD5%E%:AG-*)T&.QY#R2Y&)7*H8T7TH@5N2 M/"0F"G&?U,I%'QZ>%B_@%FEC#^:3,HQP557K*.[=OJ]W[0U\]7!IB/#3CA^B M6X(Y_1I#BT]_B_P1G>Z\%TPAA;)U*443)%%0:E\78*.Y(<$DTJY//JDEW2-- M2B=#XL'\M818W=$W:#18:FESE783<\`VI,%O(?F,!C!CEBM_\-D-<+UW(9#! MUS@'KO7AY[AN7SV.Z^%I>;@"XW1#<%E;:_\4VYMM3%Q$+@I%_6&]59BKXIJ[ M6W=#@4*:51=IZ`Y`;15'@/\D5Y"B;=*/YEY!0G=?;[\A=&X+_=#>$F%$O4I$ M/8JHIR&JJ8]$VUP7P7\UT4.B;9<.@G*Z@OQ^)?E]2GY?)=\T.:C(:6-I!5[$ M@S=*@\P-M8V14L$:Q8,^0)I5)<@P^.#0OR!Y`$UL\[/O1/M"50;^B"8XV-UV MG:LZ=JVM157!-`SJGE7>"_K>VU!]"L$CR^[&][ZZV'ID8]^G6R24H>MM!ODI&`OU;6(S!O!5K4>\\I>U]# M'TYS-'`0B!ZCN>+=.1Y5;C*-K@MY9Z_O:C;N\_Z^MPMIG^-K/X_\761REV30 M"W\Z;V4&OHID9SCZCKFH58,V^-@]*_PIQ1$6Q`D*01JBAO<-0<Y<^ M7:C`[>V8]^,^HQ[:V_E,^P@3MFPO^>KP5T&[<&]'O#^)9CJ[-VS,7T4.XC07 M+8$B#Q41YXNMB76,.,]9S'<5+4'1=96E@\^L'*=:EZUQ(GWP71:2D+:DITQI MJ8VKM3(0/>1J*=103+Q:KJJQO$%8RW:L;K2E?RPRY=58I,>`2XD5%7"I.BP, M=I)*\PU>KH_=&XTB..,PA$$*_QTQ2L.#HE%$9C]F[%+%^ M<8SS1WF^U]]%';./:+_09EK]-61>QLK32&CHE#?<@4@M0$Q+K)0\5.JI_K;4 MSL`P(!2PL8?8A)A%:(L:HMBO#]HOS5ID(E$1X6WJGP8L_N[?)Z0,.V:R;F5B MG$&[^T6LIW_HF'\Y3YFXC4VWL&TH+?OK+\;;GP)YGE#=L`]`PQX\J-FP#P#; MQ7F:!@F9C10`FS\]THE-(C+#EW!A4B@4SM@\W8KH+// M'L*L`*-)"`7EMW_R,T!MDM,9H<+R4";F?$#"BB>SF8U2R+%SP*+QX'?K^:]L M.AYEB[0D7,5=P8@W;'AXE!`Z@/0-TKK@N^!_-S9ZP7_\!QI&?]$_>OR//O]C MT$7PY*\]GK3#_]@5>?L\Z9'`M"TR>P)K3Z#M#<1?.^R0;%L7`&Q)2S,2.`D_ MU!AL($#4F'Z?,YR/D0<]9=Q@GGPCFLA;@28*'8:$*0]^8@JX\%'"I?0R/3ZY M.$66T*M]WHB%"IG%Y(\JZYX8O@1:VO:T]*[@`::N"A5%D M#3W;O#=IZ M?>C6J6NP>EW>['Y]4G8^.BG>[$%]2G<_-:7>[)WZ#=G[S!OBS=ZMW\[]+[N= MWNR]^FPX^*K9X,W>YURRUHP?`B4J,I?A8I4WP94H6G)MP\LN6M;`O1I9;M1U M%VL*M(!#4>#*@J[1"S4+TJZ)%LGU)4O5-C<1*F*\_#/253"^_R'9WP#[%G./ MH^!169#3*WJ]KKFYP5R@93Q<<'&B16Y0COCY@]4CU#:N"-V_CQ.[U,?0&@N0 MXKO;!;I7IT$JQ,1VS7?L;I!;R#4":A'5,A&T486F\`EC@.XY:=H%)/TZ:?3E M3^I2:36MGK9'>>I4]7@_^'4\T3$>!8_"".U.=+!+K:M'?C#W$$\%Q`,&XZ0> MY_MIQQ"""W)R90K<>2W(RX]*G3NO!6UIORYM&2M*;>L*>U\^'.8L><6 MQ=3NB`84-60;)]YH@=W&]U'","J*."_#292@-?9;`/;;+=\)\E:PN[V/9^G+ M\Z/+R]_#IZ].'U\>GYV&(>KE;>7P73#)-L6:=E54/S6(P@XSFM$5>P>970T- MSBZ$:2`Q\?OGN$;N?D+MR:9+P<-_*%Z4S!U"%``,Y=*.3&Z$&50JCA[$O0,- M=E85$EUDX/ROXP(?X$(/`'FW[P6AEN&+<%WP]D"HXN8L4!1N,''I@PTIM;LA@ M)"WY;=!J/I*[!FN#2]7'3%C[:!C'MFL?C?8I7?MHM+.=^$+:N?;1J,.&>CX: M?'W0]B54<`M=B<%TB3R1@@E@L@&U=KY2:+$6(E2HS33H^5&Z9@K\L M5UM#HV:*K!)Y0E%E*_9`G#$>MP:GA[#=8(^_@U-WQ-V1J,T!T-$QB`8AO8RM M,93X)6/=HXJ/QK=)'&NSB5"SK.ZU"/%XP+`^Z&FZ[80\%4YX&218T=&I'J*! MGKC&#JGR=?+&KY.3#N8^[K;K".*+4:78KM38@[")8>Y!M#LG#*0G@Q;@^Q9Z MZD-M\^+P>K[)9C&YKH2F98PD[RW:B#X_>W'TK;;14KM'EK!<]GF6(BFJ_6** MQ6@4%X6YAV9[`548\8]Y9M-7UVE`L_<%:A2.%7+Q.#PY>W9\&IX>OC@*7QS^ MB_LA&15C=W16GD@2P#[`T?3F_"$(GAE0'@9$!$=T2[H)7*\!&$*EQ)_OS00_J4/PI[>QM]W<@ M$G@K_!W,$<$$B5BRJ)?G=ZA[92]_1TINB6JV!$TXSR--O[%6//Y!G<_9XKB@ M@JUY.^[*7!@)?WR.=?JG7):"O@^.'-%)FVCRN8HW[B88C?L"#QZ&CF(?W%;/ MN?-^B_HI4G?^X*?Y'?Z[VN]2KZE5.6S?*]H!2+=-=_33E`R@C=_^[[=#HRW6 MLF(O:7K]4F7EB$U3I+>%MFF)?TP"$JRZW8Y79(V":D.1P':?*^*6G*AG+/I. M\F5%@Y&&R6\TTD#K&HYJGFX+IGH.N3GW*@ZY):J*LVX)*!HC.JBA'4SB6OG0 MV\#D!6CC"+Q9?14`;9R+MTQ0!4`;9^9_-\45`&T*345X)TL*Z\3DWKA*DA37D"V]_)4@+*\K7SZ)*$/^)S7K'M-XQK7=, MZQW3>L>TWC%])DSYF#LF96E4W!-`%VEI[+4MMFJ4NJI#;MJ(.!V'_,BN7B2L MASP2UL,:D;#&W)&!0,M(6%JZ?LRMLGA1Q'DH'2-M`&GO-DSFLEV>(P>!'K6> ML]7P;5[!>%YM"1=$/N#5VZ;PQBZ42D,\6A%0M5<]TK#Z%20-5*A(=H5-E245 M[ZKJDHVK`J0%E6F).BM!6E"YAV2ZBD/X`*6,JO*XW5/@?57AQ5?@= M45[!'D>5OD9-O8QT;S'(N\CC553/407V)@+]B$2/0,Y$BBL1Z#%D>_8LXR4$ M^P?5\@QR^@39WD!>+R"%K1YNFJ4:NOM8CCYU7'RJG7L`?QFED(.%'YR.F#YR M/JH?C!$B%Q5Q;$G8E4>.D$.MYE@CJM6N8_&O\9Y"$+5JD#6)R+^'D'"M!UM; MFXS7)N.UR7AM,EZ;C- MQZSW,>M]S)>\C^$KHQ8<4`_,L9P+#&!+=MSE=+R6HH5AX[$-Z@978U9@Y9'J MHA2&6/WIXX(\3.T(Q\9BQJF6:_P`H`GQR#ZX^B>"VI2Q%MA#S6/N>?,=>\IB M&SAO(-H"TA?*[U&/S+)QC*,O!-N]_6WTD5(;V]L[Y(==+PG?]XZU;6,@#MU( ME7L[M%)9Q=Y.G4JZ73C:'#ZN0H.@0;`)6=:(;*&U0XWPD<%,:`A]B<_80F-$QF5IB&K`#]/7=(`.P(CC]M"RG>'A/,"S@Q+"2*(9T2Z M\3QEH'.;%5@[,B:\E!=%](BK)#]HK?H%3-BT%ZWJ\3" M9&C9$["HD`B[DL?728&P\;A`;CG]J&N>+.NO-6&LWV-1-$>K'CT%E>*)I@T! M<"2`QB8X2X/`1].LB$UXG@@5(,N3"HP3(,"I!3G503_(%0X_>6L%M((EIA7Y M!X=J$$M?(-^OK12X?\F.<`%SD+Y$W!MT7<]_BW!;V$.WT)YL94W4^YN-2O[B MKQQ71N`EP5(Z+_2P2^8"ETW'XMVM>\&C7D7$3J6T*`F]X27!M-X2C[1S#6=+ M(Q9'@*I>^7B7*M&5982Q'2>[(<[#@ MM_/AJ,S&(%"S/MAR7GL[OAFGOS/%LNQO4_.IP&0J3@_DT*E885IBEG/M$2*% M#:@?V8@ZT-WCH8#-)@_P:.&1R1SQO^P=@AGLQ6P_4T/X9#&T$9[NJF&//WAHX\\*RMYD>?"1I:K55`4P)0H8@4R\6F\KTT`0?/P1[:=Z$\H_ MYV:4;42_@3>B_$-;WF^6WY'R#]J9BEUI;0KJ;ECA*&O@ZL0_W[:-[U=X)Z%) M46].6-]]35B!(W?Y#0C_7&'2ZLP;'<[]\@'^W',,?Q_`L5MO!RQ%M_.`1>.C M=Z>LK0.>K;*$$R&P=7'Y,Z M=UX;YU.?BG)W7ALG4)]CJ]QY;1PO?6DM=N>I$4"`4R./B"5Z&R\%.L.196AE MF2N1N/+:D+EU:G'GM2%S5Z7`G=>&S/V8U+GSVI"YGXIR=UX;,O=S;)4[KPV9 M^Z6UV)TG9&YO.:^SM3J^5L?7ZOA:'?^"6K56Q_]V=1RM-5OD32"@-F'A6E4$ M&XA\^2V(XD:U^?-;$,NM4N//;T%,_ZW4^O-;$-V?56O\^2V(]"^JM?[\%L3] M5\4-?[Y8#O1#CF4V#>M3A_4V9[W-66]S/A/U>+W-66]SUJ<.ZU.']:E#NY2O M3QUDWOK40%@W7Q5U86_9"&OVW`\:3D#>*&:/HG6'Z MHU$X")HG+@;QBVOT?E#E73#]RE"MVSKP'1VSQY(WOM@1*T2.L&[G.&KF(23< M==>^H>,:).P^E'X7RB8';R>,\-M4UB'!A`JZQ#!IB'WSADG#BMLU]KV:ZILR MKCLR>ECQ>GLQ;+G?IC6IR;8MJU>3(ZCT'^9#F)&-NEW337DCR++2[FN@(H8VUCIBT3EG?H'0C,Q M2AKJ_U8PRJ;3J(S':#V9S:,\%BIR1XWT0F-L=3"A'7-IZ[#EC,5C8;%:J,XR M[/S9@:]W0QL+OHR:L5UHJGD;VU30;>7*9*?!I/L!ZD7W!H>V471.#61BS/B+ M"A83KF+=*AGAIG;,O@@VHJV`,UA=K8-H""0R;JOSB/Y=]!#7-C?LC$T*W*7X M@(+]JH)70S[<<25(+^M3#07D]U:0:JRE[6,PG+]T]T[@61)30U/*;#%463(9K?+F/AP%:RBM'S,"-H7C,K8?_X+'P!#[$U7M!K[?[J#+DC#EG4F66B'!XE-IX6NK4DD8S MA5IHJ:HJ;47M8@32J&H4G[;?]2G2J@K-7A%*]*TN,+$HB0\>*%//'%7TDU?. M93V4^C@=:R^X-`_$YH2H//T8+Q6IC0Z1BNB^P((Z5J*YM?!,HTM]D-GM/<]8 MIRYO=GM/,K9`BC>[O2<8/SZEWNSVGEO\Y`WQ9K?WK.+GWDYO=GM/)W[A;/!F MJPQ7X\EB].\R6+K%;W[P=$+9#)]=8LN9Z['R"F:[9WT=+4`L^J)>'D M<\-4Q7`M6[AQ`/<$HE47+@.1+[^%I:M1;?[\%E:O5JGQY[>P@OVMU/KS6UC& M/JO6^/-;6,R^J-;Z\UM8T[XJ;OCSY;._;!71UC8JW#FX`)*KVP?5`0#V]7;M/\41$/\*P?#\GEDRS;[N!T==AB/[,DZM%&9/)>X?PHY$X3:(B MV/C6+/ZM[H^B&I.T`W\Q@-"O>%1F^7O7B7_5V#*L3Q29,NZ8EXGXO;')*D#3 M3RV[A7/Y#`&LL,Q*6)2(P3/;U86==V/X:9*^U4U$>AXV`+TK#9.0,)I]`+#1 M_`*HE5G3)MDB'?,)-(O+B/^-GSDF8PHGDK>3G5,9"B7.#8NT-'_CP(ALO=/] MBSD*]*#HXT:,VQTAA2C5=*K3T4K]2JP:51N6>>*/J"2/1]32X?&DINHY_0L( MRA^&>72'CT)NU%%*P>F1AYW1[9IV.>24'NW3<)3/YMDP`3NR99 MP?_)0)-L$/@]S6LYFG-,U>[F'+*NP96/28=')4/7AJ.YALH/T9+3>:,:JR!: M_PS;5071DH/[%]GR*HB67.&_4MY40?@MO'*A M4+8-PM`+X5Y?7EU?7EU?7K7RUI=7UY=75[R\NMY8K#<6GUQI66\LOJQVK3<6 MZXW%E[BQ\`7_Y";'59<1'8\GNX4%I$%=WNP6UHWV2/%FM[!6_&V4>K-;6!P^ MEX9XLUM8"KZ0=GJS6Y#Z7P<;O-E"NJO'2?]GPGJNMV+KK=@G5_/66[$OJUWK MK=AZ*_8E;L5\9MGU&<_ZC,=)W?J,9WW&LS[C69_QK#<6ZXW%YZ!JK3<6ZXW% M>F/Q^6PLE#,>X=ZOF!.[:MP1?A^G(O[@/P,@^*"D`X<<5,$QN6JP0`UR;X=> M,]CN=F302N!N1<7E"NUB"HGR0]O*XZ5H=YK^[*CQ,<4=%.MV"G2%@(=*,H#U MR%`$Y8.?S`L)/")*3P,F,5#4`IZ@@M=9F>&(5JB3PSC/L]Q1*VDVO4T&`*`Y MZ`YJ*SBLQ2!D]VRVU>`I]+]:V%8U7HMRI:@BFB7[]&&%[X2-<8QWYSK)S^YP_#6*UTNNJ:4S M$1AYPPI^MM\E`2I9(#34D]NNALH66\-I3T'28TC`F-'69\7?=+/#D$@'4B+Q MCX4G`H(OVW%`]>M]2F0I[9.A3<%<*H#PV$%\WD14@TVN._DP"PV472W&+)HS M8SH?Z?QQX<'2GL&BRI\46W(5 M53_U%N#&QKC+>>$L@*AT+\#RWA]ESIW7 M@C'ADU'NSFO!4/!9MLJ=U\+V_XMKL3M/;.>!1WH!N4K_I;MY]]K#-WMNS9>B MI%L_LA%TKIQL/VS$,5:_^_=E:`;[^V"EZBG.]QFX^FT%9&!6@"X8HM0?2,#> MSK:\WZ_<5%<8`TQ=I*XYP*UM--8NJL,95"H82\O^&IOA,L7ZV`+KZEM M5+Z<<)_K$=6OJ]F/J:DKN_4R6N/5G82.&S(M1K6)$X#A?N#!H%1?/`U![ON_M"/OU+]4.JIHY1].L MB#4[)V^U9N\.!:!EY)0'4XX3`ZQZHG91/C#+O*KZ_C,88"LVSE9'``Z91]O# M(Z!Y.>-O=)TF*PVN;&YE4RE'F)$<&KQVAZE:L.M!#B,DI%*D:^K[RIR0720C .#:+Q]O\!-6U&P&H/`P!E ` end From alan@linuxcare.com.au Fri, 10 Nov 2000 11:36:56 +1100 (EST) Date: Fri, 10 Nov 2000 11:36:56 +1100 (EST) From: Alan Modra alan@linuxcare.com.au Subject: abort in eliminate_regs compiling glob.c from glibc On Thu, 9 Nov 2000, John David Anglin wrote: > > Breakpoint 2, eliminate_regs_in_insn (insn=0x406a0ba0, replace=0) > > at ../../gcc/reload1.c:2826 > > 2826 if (! insn_is_asm && icode < 0) > > (gdb) p debug_rtx (insn) > > (insn/s 2711 2709 2719 (set (reg:SI 6 %r6) > > (reg:SI 28 %r28)) 69 {pre_ldw-4} (insn_list 2708 (insn_list:REG_DEP_ANTI 2696 (insn_list:REG_DEP_ANTI 2702 (insn_list:REG_DEP_ANTI 2697 (nil))))) > > (expr_list:REG_DEAD (reg:SI 28 %r28) > > (insn_list:REG_RETVAL 2708 (expr_list:REG_EQUAL (expr_list (use (mem:BLK (scratch) 0)) > > (expr_list (symbol_ref/v:SI ("@strlen")) > > (expr_list (reg/v:SI 4 %r4) > > (nil)))) > > (nil))))) > > The `use' arises from the `__pure__' attribute in the prototype for strlen: > > extern size_t strlen (__const char *__s) __attribute__ ((__pure__)); I don't see this problem using current puffin CVS hppa64-linux gcc. Was this with your REG_ELIMINATE patch? Alan Modra -- Linuxcare. Support for the Revolution. From dave@hiauly1.hia.nrc.ca Thu, 9 Nov 2000 21:50:49 -0500 (EST) Date: Thu, 9 Nov 2000 21:50:49 -0500 (EST) From: John David Anglin dave@hiauly1.hia.nrc.ca Subject: abort in eliminate_regs compiling glob.c from glibc > > > 2826 if (! insn_is_asm && icode < 0) > > > (gdb) p debug_rtx (insn) > > > (insn/s 2711 2709 2719 (set (reg:SI 6 %r6) > > > (reg:SI 28 %r28)) 69 {pre_ldw-4} (insn_list 2708 (insn_list:REG_DEP_ANTI 2696 (insn_list:REG_DEP_ANTI 2702 (insn_list:REG_DEP_ANTI 2697 (nil))))) > > > (expr_list:REG_DEAD (reg:SI 28 %r28) > > > (insn_list:REG_RETVAL 2708 (expr_list:REG_EQUAL (expr_list (use (mem:BLK (scratch) 0)) > > > (expr_list (symbol_ref/v:SI ("@strlen")) > > > (expr_list (reg/v:SI 4 %r4) > > > (nil)))) > > > (nil))))) > > > > The `use' arises from the `__pure__' attribute in the prototype for strlen: > > > > extern size_t strlen (__const char *__s) __attribute__ ((__pure__)); > > I don't see this problem using current puffin CVS hppa64-linux gcc. Was > this with your REG_ELIMINATE patch? No. Well actually I saw it first with the patch. I see this with the 32 bit compiler. The only elimination with the 32 bit compiler is the default frame pointer elimination. I just tried the hppa64-linux-gcc compiler with the source that I posted and it didn't abort. There were lots of warnings about int to pointer conversions though. Make sure you compile with -O2 or -O3? Register elimination only occurs at -O2 or above. I see the problem both with a i686-linux cross compiler and a fairly recent native hpux compiler under hpux 10.20. The problem is not present in 2.95.2 but it doesn't support the pure atribute. Dave -- J. David Anglin dave.anglin@nrc.ca National Research Council of Canada (613) 990-0752 (FAX: 952-6605) From matthew@wil.cx Fri, 10 Nov 2000 09:49:07 +0000 Date: Fri, 10 Nov 2000 09:49:07 +0000 From: Matthew Wilcox matthew@wil.cx Subject: linux bame On Thu, Nov 09, 2000 at 03:53:48PM -0700, Paul Bame wrote: > Somebody never imported 2.4.0-test6, then I imported -test10 on the main > vendor branch and now can't (easily) undo that to import test6 and THEN > test10. This workaround sucks. don't use vendor branches. didn't you talk to mang about this? -- Revolutions do not require corporate support. From matthew@wil.cx Fri, 10 Nov 2000 10:18:08 +0000 Date: Fri, 10 Nov 2000 10:18:08 +0000 From: Matthew Wilcox matthew@wil.cx Subject: [parisc-linux] tulip DMA mapping On Thu, Nov 09, 2000 at 12:12:25PM -0800, Grant Grundler wrote: > 0 is a valid pci_map_single() return value when the system has an IO MMU. Oh dear. You can bet tulip won't be the only driver which assumes it isn't a valid return value. Can't our IOMMU code be limited in such a way that 0 is not a valid return value? Say, constrain all allocated addresses to the top half of the device bus? (um, just check me on this, map_single returns a device bus address, not a processor bus address, right?) > The system will panic before pci_map_single() will fail. > The driver needs to remember some other way if a buffer was mapped or not. > Or the Documentation/DMA-mapping.txt should be changed - ie add this > to the interface definition and I can reserve the 1st mapping > entry so no-one uses it. we should probably have a BAD_DMA_ADDR define which that array should be initialised to. it's a little late in 2.4 to go through and audit all the drivers again. > Should I be mailing Jeff Garzik directly? > Or can someone who knows Jeff point this out to him? i've cc'd jeff & dave miller on this. -- Revolutions do not require corporate support. From davem@redhat.com Fri, 10 Nov 2000 02:16:11 -0800 Date: Fri, 10 Nov 2000 02:16:11 -0800 From: David S. Miller davem@redhat.com Subject: [parisc-linux] tulip DMA mapping Date: Fri, 10 Nov 2000 10:18:08 +0000 From: Matthew Wilcox > Should I be mailing Jeff Garzik directly? > Or can someone who knows Jeff point this out to him? i've cc'd jeff & dave miller on this. In 2.4.x there is _NO_ error return from the PCI dma functions except the consistent DMA mapping ones. This was an explicit design decision, the dynamic mapping functions should never fail, and if they do it is a hard error. Therefore no drivers need to check for failure, as far as they are concerned, there is no failure. So what is the issue? In 2.5.x I'll add an error return facility (BTW: -1 ie. 0xfffffff would probably work as an error value on all platforms :-) Later, David S. Miller davem@redhat.com From rhirst@linuxcare.com Fri, 10 Nov 2000 10:55:16 +0000 Date: Fri, 10 Nov 2000 10:55:16 +0000 From: Richard Hirst rhirst@linuxcare.com Subject: [parisc-linux] parisc-linux reaches uptimes in excess of one day! Just for interest... My A180 has been up for 25 hours, the first 12 of which I had a couple of telnet sessions open running vi, gcc, etc. and since then it has been looping doing kernel builds. I also ran cvs to update its kernel source tree from pehc. So far it has completed about 23 kernel builds with one hiccup: do_page_fault() pid=2420 command='cpp0' YZrvWESTHLNXBCVMcbcbcbcbOGFRQPDI PSW: 00000000000001100000000000001011 r0-3 00000000 4013ac38 400e134f 00000004 r4-7 40138c38 ffffffb5 2002014b 00000001 r8-11 00000004 00000000 00000000 4001ada0 r12-15 4001ad7c 0001b300 2001f601 00000001 r16-19 00012000 00000023 00000020 40138c38 r20-23 20020100 4012a51c 00000000 9999999a r24-27 2002016c 2002014c 00000004 00013d34 r28-31 00000000 4013a438 200201c0 40041757 sr0-4 00000000 00000011 00000000 00000011 sr4-8 00000011 00000011 00000011 00000011 IASQ: 00000011 00000011 IAOQ: 400e13b7 400e13bb IIR: 0c601094 ISR: 00000011 IOR: 00000004 ORIG_R28: 40019450 Richard From rhirst@linuxcare.com Fri, 10 Nov 2000 11:12:20 +0000 Date: Fri, 10 Nov 2000 11:12:20 +0000 From: Richard Hirst rhirst@linuxcare.com Subject: [parisc-linux] tulip DMA mapping I've quoted the whole of Grants message below, so you can see the context. It looks like tulip is treating zero as meaning it doesn't have anything to pci_unmap... Grant Grundler wrote: > Hi all, > I see a "bug" in tulip's usage of mapping services. > It's not the bug I was looking for unfortunately. > > In line 217 of drivers/net/tulip/interrupt.c: > > if (tp->tx_buffers[entry].mapping) > pci_unmap_single(tp->pdev, > tp->tx_buffers[entry].mapping, > sizeof(tp->setup_frame), > PCI_DMA_TODEVICE); > > 0 is a valid pci_map_single() return value when the system has an IO MMU. > > The system will panic before pci_map_single() will fail. > The driver needs to remember some other way if a buffer was mapped or not. > Or the Documentation/DMA-mapping.txt should be changed - ie add this > to the interface definition and I can reserve the 1st mapping > entry so no-one uses it. Richard On Fri, Nov 10, 2000 at 02:16:11AM -0800, David S. Miller wrote: > Date: Fri, 10 Nov 2000 10:18:08 +0000 > From: Matthew Wilcox > > > Should I be mailing Jeff Garzik directly? > > Or can someone who knows Jeff point this out to him? > > i've cc'd jeff & dave miller on this. > > In 2.4.x there is _NO_ error return from the PCI dma functions except > the consistent DMA mapping ones. > > This was an explicit design decision, the dynamic mapping functions > should never fail, and if they do it is a hard error. > > Therefore no drivers need to check for failure, as far as they are > concerned, there is no failure. > > So what is the issue? In 2.5.x I'll add an error return facility > (BTW: -1 ie. 0xfffffff would probably work as an error value on all > platforms :-) > > Later, > David S. Miller > davem@redhat.com > > --------------------------------------------------------------------------- > To unsubscribe: send e-mail to parisc-linux-request@thepuffingroup.com with > `unsubscribe' as the subject. > > From davem@redhat.com Fri, 10 Nov 2000 03:26:48 -0800 Date: Fri, 10 Nov 2000 03:26:48 -0800 From: David S. Miller davem@redhat.com Subject: [parisc-linux] tulip DMA mapping Date: Fri, 10 Nov 2000 11:12:20 +0000 From: Richard Hirst I've quoted the whole of Grants message below, so you can see the context. It looks like tulip is treating zero as meaning it doesn't have anything to pci_unmap... Thank you for the clarification. Jeff, this is in fact a bug, please fix :-) Later, David S. Miller davem@redhat.com From jgarzik@mandrakesoft.com Fri, 10 Nov 2000 09:30:41 -0500 Date: Fri, 10 Nov 2000 09:30:41 -0500 From: Jeff Garzik jgarzik@mandrakesoft.com Subject: [parisc-linux] tulip DMA mapping "David S. Miller" wrote: > > Date: Fri, 10 Nov 2000 11:12:20 +0000 > From: Richard Hirst > > I've quoted the whole of Grants message below, so you can see the > context. It looks like tulip is treating zero as meaning it > doesn't have anything to pci_unmap... > > Thank you for the clarification. > > Jeff, this is in fact a bug, please fix :-) np. Like Matthew(?) hinted, this is not the only place that needs fixing. I'll take care of it. Jeff -- Jeff Garzik | Building 1024 | Would you like a Twinkie? MandrakeSoft | From bame@riverrock.org Fri, 10 Nov 2000 08:57:47 -0700 Date: Fri, 10 Nov 2000 08:57:47 -0700 From: bame@riverrock.org bame@riverrock.org Subject: linux bame = On Thu, Nov 09, 2000 at 03:53:48PM -0700, Paul Bame wrote: = > Somebody never imported 2.4.0-test6, then I imported -test10 on the mai n = > vendor branch and now can't (easily) undo that to import test6 and THEN = > test10. This workaround sucks. = = don't use vendor branches. didn't you talk to mang about this? Um, I have no information to go on from your note. All the (successful) merges I've done before have used the cookbook CVS merge method including a vendor branch. Several (N-1?) of the palinux merges have been accompanied by updating the vendor branch. And this merge is going well despite the ugly workaround, or so it appears to me. Just importing files to a vendor branch should have no effect on anything else unless CVS has some horrible bug (RCS does not). Before I make what is apparently a serious mistake ("don't use vendor branches" sounds pretty serious) please enlighten me! -P From grundler@cup.hp.com Fri, 10 Nov 2000 08:29:25 -0800 Date: Fri, 10 Nov 2000 08:29:25 -0800 From: Grant Grundler grundler@cup.hp.com Subject: [parisc-linux] tulip DMA mapping Mathew, I think the situation is clarified. This is just FYI. Matthew Wilcox wrote: > On Thu, Nov 09, 2000 at 12:12:25PM -0800, Grant Grundler wrote: > > 0 is a valid pci_map_single() return value when the system has an IO MMU. > > Oh dear. You can bet tulip won't be the only driver which assumes it > isn't a valid return value. Well, then: 1) the driver writer made a wrong assumption that the "spec" does not support. 2) that wasn't the case here - 0 was used as a flag to indicate a mapping had (or hadn't rather) been done - not that the mapping call had failed. > Can't our IOMMU code be limited in such a > way that 0 is not a valid return value? Say, constrain all allocated > addresses to the top half of the device bus? It could pretty easily by reserving the dma_map[0] entry during init time. Dave Miller already made it clear that's not desirable. > (um, just check me on this, map_single returns a device bus address, > not a processor bus address, right?) Yes. It's the address a device must use to master DMA transactions. pci_map_single() input parameters are "struct pci_dev *", virtual host memory address, and buffer size. The return is a device specific I/O DMA address - ie this mapping cannot be shared with other devices. FWIW, "I/O DMA address" are called IOVAs in HPUX (I/O Virtual Address). The HW guys prefer another name but this one stuck. grant Grant Grundler Unix Systems Enablement Lab +1.408.447.7253 From bame@riverrock.org Fri, 10 Nov 2000 14:28:33 -0700 Date: Fri, 10 Nov 2000 14:28:33 -0700 From: bame@riverrock.org bame@riverrock.org Subject: [parisc-linux] kernel merge = = We're getting ready to do a kernel merge (to -test10 I think). Anybody = concerns before we get started? = I'm getting ready to commit the changes to merge us up to 2.4.0-test10 as soon as I'm confident 64-bit kernels are OK (32-bit seems fine). Here's a brief list of changes made (and yet to be made -- if anyone has the time/energy) to our parisc code (does not include changes in common code!). While there's plenty yet to do, I think we're no worse off than before the merge. Some parts of our parisc code are getting rather moldy compared to the other ports FYI. Important tags: LINUS_240_TEST6 Linus' 2.4.0-test6 LINUS_240_TEST10 Linus' 2.4.0-test10 LINUS_240_TEST10_PREMERGE Our tree before the -test10 merge LINUS_240_TEST10_MERGED Our tree after the -test10 merge ------------ Lots of 'extern __inline__' turned into 'static __inline__' and there are more to do (TODO). Beginnings of several smp_mb*() macros -- implemented as no-ops in the non-SMP case (asm/bitops.h, asm/system.h) SET_PERSONALITY() macro in asm/elf.h needs updating (TODO). fcntl.h acquired a 'struct fcntl64' used with 64-bit offsets, implementing fcntl(fd, F_S/GETLK[W]64, ...). Several other locking-related #defines added. asm/mmu_context.h:init_new_context() now returns int (always 0), not void. Should our asm/bitops.h routines be re-coded in assembly? (TODO) Added #define RLIMIT_LOCKS to asm/resource.h Added #define CLOCKS_PER_SEC to asm/param.h (how did we miss this one?) Our asm/string.h is behind the times. Fixing it might get rid of a bunch of compiler warnings! (TODO) Removed mktime from drivers/char/genrtc.c (it's in a header file now) x86 made a bunch of changes to asm-i386/floppy.h -- should we? (TODO) looks like maybe the get/put_user_ret() functions in asm/uaccess.h are obsolete? (TODO) We'll need to add the getdents64() and fcntl64() syscall glue. (TODO!!!) Our arch/parisc/config.in is in BAD SHAPE (TODO) arch/parisc/process.c: added new argsto do_fork() and copy_thread(). IA64 seems to use the copy_thread() arg. arch/parisc/signal.c: minor change to common data structure drivers/scsi sym53c8xx_comm.h #ifdef doesn't work on parisc -- eliminates unmap_pci_mem() causing link error (TODO - rhirst) From pjlahaie@linuxcare.com Fri, 10 Nov 2000 17:14:06 -0500 Date: Fri, 10 Nov 2000 17:14:06 -0500 From: Paul J.Y. Lahaie pjlahaie@linuxcare.com Subject: [parisc-linux] Beta CD --uXxzq0nDebZQVNAZ Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Hello fellow PA-RISCers, An preliminary beta CD for PA/Linux has been uploaded to puffin.external.hp.com. If people could try it and forward any complaints or suggestions to me, it would be greatly appreciated. The URL for the image is: ftp://puffin.external.hp.com/pub/parisc/cd-images/palinux-0.5.iso.gz - Paul --uXxzq0nDebZQVNAZ Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.4 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE6DHMu8ggPQthPCzcRAgb0AJ4jJs5VOnm+9aDXUbtwht7hxAa+UwCgihAo nEE25pYQwBwCDuALcSdyCNw= =bTuw -----END PGP SIGNATURE----- --uXxzq0nDebZQVNAZ-- From randolph@tausq.org Fri, 10 Nov 2000 19:18:47 -0700 Date: Fri, 10 Nov 2000 19:18:47 -0700 From: Randolph Chung randolph@tausq.org Subject: [parisc-linux] kernel merge > Our asm/string.h is behind the times. Fixing it might get rid of a > bunch of compiler warnings! (TODO) if this is just an issue of implementing the various parisc-optimized string routines, i've been working on this, but don't have everything ready yet. randolph -- @..@ http://www.TauSq.org/ (----) ( >__< ) ^^ ~~ ^^ From crypt@ihug.co.nz Sun, 12 Nov 2000 01:47:56 +1300 Date: Sun, 12 Nov 2000 01:47:56 +1300 From: crypt@ihug.co.nz crypt@ihug.co.nz Subject: [parisc-linux] HP 9000 e25 Considering how often this question comes up is there anyone out there that is interested in tracking down the info to port linux to this class of box. Server boxes may be classed as boring to some but there seem to be a large number of people who have at least one of them sitting about doing nothing. Joe. -- ======================================================================= in real life: Joseph Skinner |There's no such thing as a wizard email: crypt@ihug.co.nz |who minds his own business Analyst/Programmer | - Berengis the Black | Court Mage to the Earls Caeline ======================================================================== From snaketails@optushome.com.au Sat, 11 Nov 2000 23:57:43 +1100 Date: Sat, 11 Nov 2000 23:57:43 +1100 From: Rod Smart snaketails@optushome.com.au Subject: [parisc-linux] PA-RISC newbie Hi there. I just purchased at a **VERY** cheap price, a HP Visualize C-180 RISC system from a CAD drafting company, this box included a 4Gb Hard disk, a video card with unknown amount of memory (& daughter board, assuming its memory upgrade) and system board RAM is fully loaded (768Megs). I would like to run this system on Linux, and found the PA-RISC web site from the www.linux.org web site :o) The system currently has HP-UX installed, but not having any usernames or passwords, I cannot access the system from the prompt. I have read how to NFS-boot the HPbox from the message board, but I couldn't figgure out where to find the kernel sources (or how I would be able to compile them on the HPbox anyway). I downloaded the vmlinux kernel file from the ftp site and the NFS-ROOT and installed both on my current Linux box (Pentium 133 pre-MMX) in the format of how it was layed out in ... LINUX/PA-RISC NFSROOT HOWTO In there it states that you have to get the latest linux-2.3 tree from CVS, but which CVS server I'm curious about as the ones on ftp.kernel.org don't have "parisc" in the /arch/ branch, so where do I find the CVS "tree" that I need to use? I seem to have the "STEP 2." section running, as from playing with the system I had found my way into the PDC prompt and have played with the "boot" function. I tried to boot the installation CD (on a drive I have borrowed from work) of HP-UX and reinstall so I have access, as I don't really care whats currently on the system.. I'm not confident enough on how to create and burn a bootable CD to try and boot the box that way, I still think the vmlinux kernel I downloaded from the PA-RISC website has something to do with my problems (or the permissions) I do know that the Hp is talking to the Linux box (apart from the lack of logged info) I get a report in /var/log/secure and messages that the HP box has attempted a bootp session, but the HP box reports something along the lines that the booting code was not found. So, if anyone has any ideas on how to help me, I would be appreciated ;o) Oh, what *is* the RAM modules in the Hp systems anyway (apart from the obvious 64Mx72-pin SIMM) Thank you for your time and help :o) PS. I would prefer replies to my E-mail address as I generally forget to surf the net reading mailing lists.... From andrew@neep.com.au Sat, 11 Nov 2000 23:12:55 +0800 Date: Sat, 11 Nov 2000 23:12:55 +0800 From: Andrew Shugg andrew@neep.com.au Subject: [parisc-linux] HP 9000 e25 > Considering how often this question comes up is there anyone out there > that is interested in tracking down the info to port linux to this class > of box. > > Server boxes may be classed as boring to some but there seem to be a > large number of people who have at least one of them sitting about doing > nothing. > > Joe. I don't perceive the problem to be a lack of willingness, or interest, but has already been stated the older systems contain a lot of proprietry stuff that isn't sufficiently documented for people to work on. Maybe as the parisc port grows more popular and attracts more resources, some enthusiastic people will get it happening. =) Andrew. -- Andrew Shugg http://www.neep.com.au/ "Just remember, Mr Fawlty, there's always someone worse off than yourself." "Is there? Well I'd like to meet him. I could do with a good laugh." From grundler@cup.hp.com Sat, 11 Nov 2000 15:29:14 -0800 Date: Sat, 11 Nov 2000 15:29:14 -0800 From: Grant Grundler grundler@cup.hp.com Subject: [parisc-linux] HP 9000 e25 Andrew Shugg wrote: > > Considering how often this question comes up is there anyone out there > > that is interested in tracking down the info to port linux to this class > > of box. > > > > Server boxes may be classed as boring to some but there seem to be a > > large number of people who have at least one of them sitting about doing > > nothing. > > > > Joe. > > I don't perceive the problem to be a lack of willingness, or interest, but > has already been stated the older systems contain a lot of proprietry stuff > that isn't sufficiently documented for people to work on. AFIAK, the chipsets for I/O devices in E25 have plenty of documentation. The issue is someone has to clean them up and get a lawyer to approve their publication. It's all about IP and avoiding lawsuits. This has been discussed before. Any HP employees interested in doing this "on their own time" can contact me and I'll help locate unpublished docs. Note that PDC is the same for Nova-Class (EFGHI-class) boxes as for the workstations for the most part. So someone could start by just trying to boot those boxes and see how far it gets before dying. > Maybe as the parisc port grows more popular and attracts more resources, > some enthusiastic people will get it happening. =) Having worked on the HPUX SCSI driver (scsi3 and scsi1) for E25 and similar boxes, I question anyone's sanity who volunteers to write drivers for SPIFI chips - even with full documentation. I would rather give folks that interested in contributing a 715/33! (or my gosh /50's!) Yes - I know folks who collect PDP's and keep them running in their garage...'nuf said. grant Grant Grundler Unix Systems Enablement Lab +1.408.447.7253 From grundler@cup.hp.com Sat, 11 Nov 2000 15:38:58 -0800 Date: Sat, 11 Nov 2000 15:38:58 -0800 From: Grant Grundler grundler@cup.hp.com Subject: [parisc-linux] PA-RISC newbie Rod Smart wrote: > Hi there. > > I just purchased at a **VERY** cheap price, a HP Visualize C-180 > RISC system from a CAD drafting company, this box included a 4Gb Hard > disk, a video card with unknown amount of memory (& daughter board, > assuming its memory upgrade) and system board RAM is fully loaded > (768Megs). > > I would like to run this system on Linux, and found the PA-RISC web > site from the www.linux.org web site :o) > > The system currently has HP-UX installed, but not having any > usernames or passwords, I cannot access the system from the prompt. Yes you can. You just need to know how. Interrupt the boot process to get a "BOOT ADMIN" prompt (or whatever it's called - Boot Console Handler). Then "boot primary isl" (shortened to bo pri isl) You should have an "ISL>" prompt now. ISL> hpux -is And you will boot to single user state with a shell. mountall and you should have the regular tools too. vi /etc/passwd to your hearts content. "There is no such thing at security with out physical security". .. > I'm not confident enough on how to create and burn a bootable CD to > try and boot the box that way, I still think the vmlinux kernel I > downloaded from the PA-RISC website has something to do with my problems > (or the permissions) > You can dd the ISO image to a regular hard disk (ie /dev/sdc) and move that disk over to the C180. Then boot from that disk. From BCH, use "sea" to locate all boot devices. grant Grant Grundler Unix Systems Enablement Lab +1.408.447.7253 From randolph@tausq.org Sat, 11 Nov 2000 17:04:29 -0700 Date: Sat, 11 Nov 2000 17:04:29 -0700 From: Randolph Chung randolph@tausq.org Subject: [parisc-linux] glibc question I'm working with bdale and taggart to try to get the Debian glibc package to compile under hppa. One of the things I saw today while playing with this is that the build dies because it tries to link in bsd-setjmp.c and bsd-_setjmp.c, which both define setjmp. Can someone enlighten me about why this may be happening? This is built from the glibc-2.2 sources, which I understand has all/most of the changes in pehc cvs. randolph -- @..@ http://www.TauSq.org/ (----) ( >__< ) ^^ ~~ ^^ From rajak@purdue.edu Sat, 11 Nov 2000 22:58:57 -0500 (EST) Date: Sat, 11 Nov 2000 22:58:57 -0500 (EST) From: Brian Poole rajak@purdue.edu Subject: [parisc-linux] Problems booting new beta CD Hello, My machine is a 715/80 with 88M of RAM, 1G HD, external 4x CD drive & floppy. Trying to get the new palinux CD working on my 715/80 here and not having too much success. Did get the CD to actually boot, but after all the normal Linux init messages (which were very nice to see btw, congratulations on how far it has already gotten ;) it stops at 'Switching from PDC console'. Looking thru the FAQ I saw a somewhat similar question, in that it had 'pdc' in it & was booting from the CD (but the 0.1 CD, not the one I am using), that said the kernel on the CD booted from/to the serial console. Is this also true of the 0.5 CD? If so, what is necessary to boot one of these from console? I've been fooling with it to no success.. I have it automatically booting from the CD, but it doesn't actually boot. I replug in the monitor & keyboard and find that it can't boot without the keyboard ('Failed to initiliaze a keyboard\n SYSTEM HALTED').. How am I supposed to boot to the console if I can't boot w/o a keyboard? I imagine if it has a keyboard it will boot to the screen like a Sun. Thanks for the help, -b From grundler@cup.hp.com Sat, 11 Nov 2000 23:31:37 -0800 Date: Sat, 11 Nov 2000 23:31:37 -0800 From: Grant Grundler grundler@cup.hp.com Subject: [parisc-linux] Problems booting new beta CD Brian Poole wrote: ... > Looking thru the FAQ Brian, Thank you for first reading the FAQ! > I saw a somewhat similar question, in that it had > 'pdc' in it & was booting from the CD (but the 0.1 CD, not the one I am > using), that said the kernel on the CD booted from/to the > serial console. Is this also true of the 0.5 CD? I think it is. Is there a way via PALO to direct the console to FBCON or STICON or whatever it's called now? I had the impression *eventually* the boot console would be whatever PDC says it is - ie graphics console for the 712. > If so, what is necessary to boot one of these from console? kernel with CONFIG_STI_CONSOLE I think....but that's not enabled by default. It may not be possible to use the graphics console unless one builds a "custom" kernel. > I've been fooling with it to no > success.. I have it automatically booting from the CD, but it doesn't > actually boot. I replug in the monitor & keyboard and find that it can't > boot without the keyboard ('Failed to initiliaze a keyboard\n SYSTEM > HALTED').. How am I supposed to boot to the console if I can't boot w/o a > keyboard? I imagine if it has a keyboard it will boot to the screen like a > Sun. AFAIK, 712's are the only parisc workstations what won't boot w/o keyboard. All others will auto-switch to use serial console if the keyboard is not connected. Both or the above questions sounds like a FAQ. Could someone who knows more update/add those to the FAQ? thanks, grant ps. The most up-to-date FAQ is at parisc-linux.org/faq.html even though that's not officially online yet. > > Thanks for the help, > > -b > > > > --------------------------------------------------------------------------- > To unsubscribe: send e-mail to parisc-linux-request@thepuffingroup.com with > `unsubscribe' as the subject. > Grant Grundler Unix Systems Enablement Lab +1.408.447.7253 From alan@linuxcare.com.au Sun, 12 Nov 2000 23:08:35 +1100 (EST) Date: Sun, 12 Nov 2000 23:08:35 +1100 (EST) From: Alan Modra alan@linuxcare.com.au Subject: [parisc-linux] glibc question On Sat, 11 Nov 2000, Randolph Chung wrote: > I'm working with bdale and taggart to try to get the Debian glibc > package to compile under hppa. One of the things I saw today while > playing with this is that the build dies because it tries to link in > bsd-setjmp.c and bsd-_setjmp.c, which both define setjmp. Can someone > enlighten me about why this may be happening? I think bsd-_setjmp.c should define _setjmp, not setjmp. Alan Modra -- Linuxcare. Support for the Revolution. From andrew@neep.com.au Mon, 13 Nov 2000 00:40:15 +0800 Date: Mon, 13 Nov 2000 00:40:15 +0800 From: Andrew Shugg andrew@neep.com.au Subject: [parisc-linux] HP 9000 e25 Grant Grundler said: > AFIAK, the chipsets for I/O devices in E25 have plenty of > documentation. The issue is someone has to clean them up and get a > lawyer to approve their publication. My bad, I should've said "public documentation". =) *prods LC FAQ maintainers* Andrew. -- Andrew Shugg http://www.neep.com.au/ "Just remember, Mr Fawlty, there's always someone worse off than yourself." "Is there? Well I'd like to meet him. I could do with a good laugh." From randolph@tausq.org Sun, 12 Nov 2000 11:06:38 -0700 Date: Sun, 12 Nov 2000 11:06:38 -0700 From: Randolph Chung randolph@tausq.org Subject: [parisc-linux] glibc build fails / bash bug Bdale, taggart and I have been looking at trying to build glibc on hppa from Debian's sources. What we saw was that it looks like a lot of the syscalls were not being reocognized as such by one part of the build, so it tries to build things from the sysdeps/generic directory and fails. After a lot of digging, I *think* what is at fault is actually bash. It looks like during the build, a shell script (make-syscalls.sh) parses through syscalls.list to generate syscall stubs that are needed for the build to happen correctly, but these are not being generated. What it boils down to, I think, is this: (on hppa - bdale's J5K) ============================= tausq@j5k:/space/tausq $ bash --version GNU bash, version 2.04.0(1)-release (hppa-unknown-linux-gnu) Copyright 1999 Free Software Foundation, Inc. tausq@j5k:/space/tausq $ dpkg -l |grep bash ii bash 2.04-7 The GNU Bourne Again SHell tausq@j5k:/space/tausq $ cat test.sh #!/bin/sh echo "1 2 3 4 5 a b c d e " | while read a b c d e; do echo $a $b $c $d $e done tausq@j5k:/space/tausq $ /bin/bash test.sh 1 2 3 4 5 ============================= (on other archs, tested with i386 and sparc) samwise[11:06] ~% bash --version GNU bash, version 2.04.0(1)-release (i386-pc-linux-gnu) Copyright 1999 Free Software Foundation, Inc. samwise[11:06] ~% dpkg -l |grep bash ii bash 2.04-7 The GNU Bourne Again SHell samwise[11:06] ~% /bin/bash test.sh 1 2 3 4 5 a b c d e This causes the parsing routines to die quite miserably.... Anyone feel like trying to fix this? :-) randolph -- @..@ http://www.TauSq.org/ (----) ( >__< ) ^^ ~~ ^^ From pdbeal@louisville.edu Sun, 12 Nov 2000 14:27:28 -0500 Date: Sun, 12 Nov 2000 14:27:28 -0500 From: Phillip D. Beal pdbeal@louisville.edu Subject: [parisc-linux] Beta CD On Fri, Nov 10, 2000 at 05:14:06PM -0500, Paul J.Y. Lahaie wrote: > Hello fellow PA-RISCers, > > An preliminary beta CD for PA/Linux has been uploaded to > puffin.external.hp.com. If people could try it and forward any complaints > or suggestions to me, it would be greatly appreciated. The URL for the > image is: ftp://puffin.external.hp.com/pub/parisc/cd-images/palinux-0.5.iso.gz > > - Paul The kernel dumps on an HP755. Actually, how do you make these CD's? I know how to use mkisofs to crerat a filesystem CD, but how you make it bootable with a kernel image? Thanks, -- Phillip Beal Electrical and Computer Engineering S+LUG Vice-President From bame@riverrock.org Sun, 12 Nov 2000 13:27:32 -0700 Date: Sun, 12 Nov 2000 13:27:32 -0700 From: bame@riverrock.org bame@riverrock.org Subject: [parisc-linux] glibc build fails / bash bug = After a lot of digging, I *think* what is at fault is actually bash. Bash has a bunch of 'set' options, some shell variables, and probably some compile-time configure options, which affect its behavior, so I'd compare all those. One possibility is that the bash configure script on hppa configures bash to be more like Posix, since that's what hp-ux shell users expect. The construct in question: echo "a b c 1 2 3" | while read x1 x2 x3 *depends* on the way echo breaks or doesn't break lines, and the way read parses them. Often scripts like that also depend on whether the shell actually makes a new subprocess for the 'while' or it doesn't, because that determines whether variables set in the loop will still be set on exit from the loop. While I didn't find a way to make the construction fail, a safer method (when you get a choice) is to use 'set': set -- a b c \ 1 2 3 while [ $# != 0 ] do echo $1 $2 $3 shift 3 done -Paul "too much shell programming" Bame From bame@riverrock.org Sun, 12 Nov 2000 17:25:45 -0700 Date: Sun, 12 Nov 2000 17:25:45 -0700 From: bame@riverrock.org bame@riverrock.org Subject: [parisc-linux] kernel merge Helge noticed SCSI fails (B160L, 712, I think it's ok on c3k) after the -test10 merge. We have MANY differences from Linus in the SCSI area. Anybody want to take a look at this? FYI to get the pre-merge kernel you can use LINUS_240_TEST10_PREMERGE. Beware that tags are sticky in CVS (use cvs update -A to fix that). -P From catfish@alltel.net Sun, 12 Nov 2000 19:05:21 -0600 Date: Sun, 12 Nov 2000 19:05:21 -0600 From: catfish@alltel.net catfish@alltel.net Subject: [parisc-linux] Project Dead???? Hello, Its been so long since I've had an email I was curious if this has become a Dead project? Just curious. Terry -- catfish: icq #20116127 From bame@riverrock.org Sun, 12 Nov 2000 18:15:07 -0700 Date: Sun, 12 Nov 2000 18:15:07 -0700 From: bame@riverrock.org bame@riverrock.org Subject: [parisc-linux] Project Dead???? = Hello, = Its been so long since I've had an email I was curious if this has = become a Dead project? You might want to check the e-mail archives to see what you've been missing. I don't know why you haven't been receiving anything. The project is quite alive. http://www.parisc-linux.org/lists.html -P From bame@riverrock.org Sun, 12 Nov 2000 19:20:50 -0700 Date: Sun, 12 Nov 2000 19:20:50 -0700 From: bame@riverrock.org bame@riverrock.org Subject: [parisc-linux] kernel merge = = Helge noticed SCSI fails (B160L, 712, I think it's ok on c3k) = after the -test10 merge. Fixed. From test6 to test10 the SCSI host registration method changed. Updated sim700.c, lasi7xx.h, zalon7xx.h -P From grundler@cup.hp.com Sun, 12 Nov 2000 21:34:08 -0800 Date: Sun, 12 Nov 2000 21:34:08 -0800 From: Grant Grundler grundler@cup.hp.com Subject: [parisc-linux] Problems booting new beta CD Brian Poole wrote: > Quoting Grant Grundler (grundler@cup.hp.com) from 11 November 2000: > > Is there a way via PALO to direct the console to FBCON or STICON or > > whatever it's called now? > > > > I had the impression *eventually* the boot console would be whatever PDC > > says it is - ie graphics console for the 712. > > Working on a 715 here.. notice you refer to 712s throughout, hopefully we are > on the same page. Maybe 712s are identical to 715s, I don't have any idea, > just noticed the irregularity. For the most part yes. I had just assumed you were using a 712. > I meant to say 'from serial console' or something of the sort.. Serial console should just work. Shouldn't need an HIL keyboard connected though. > > > > I've been fooling with it to no > > > success.. I have it automatically booting from the CD, but it doesn't > > > actually boot. I replug in the monitor & keyboard and find that it can't > > > boot without the keyboard ('Failed to initiliaze a keyboard\n SYSTEM > > > HALTED').. How am I supposed to boot to the console if I can't boot w/o a > > > keyboard? I imagine if it has a keyboard it will boot to the screen like > a > > > Sun. > > > > AFAIK, 712's are the only parisc workstations what won't boot w/o keyboard. > > All others will auto-switch to use serial console if the keyboard > > is not connected > > Hmmm.. so I have manually switch it to use serial console? No. Just disconnect the keyboard before powering on the machine. Should end up with console on the serial interface. You may want to set the keyboard/console path to the serial port. This can be done from "BOOT_ADMIN>" prompt. The default kernel has "CONFIG_HIL=y". But since I don't test on boxes with HIL interfaces, I have no idea if a keyboard is required since the driver is enabled. It sounds like a bug if the 715 can't boot from serial console w/o HIL keyboard. grant Grant Grundler Unix Systems Enablement Lab +1.408.447.7253 From dhazeghi@pacbell.net Sun, 12 Nov 2000 21:34:19 -0800 Date: Sun, 12 Nov 2000 21:34:19 -0800 From: dhazeghi@pacbell.net dhazeghi@pacbell.net Subject: [parisc-linux] [Semi OT] SOM Linker Hello, I have been watching this project for some time and wanted to thank you guys for all the great work so far. The recent announcement of a BETA CD is highly encouraging. However I would like to know what work if any has been done on the SOM linker which HP released to the public last November(?). It seems that as of right now, it has not been touched since February 14, and the FSF binutils snapshots still do not have any SOM support for ld. Has there been any movement in merging this in, or is anybody working on this? Thanks. Dara Hazeghi From deller@gmx.de Mon, 13 Nov 2000 08:32:54 +0100 Date: Mon, 13 Nov 2000 08:32:54 +0100 From: Helge Deller deller@gmx.de Subject: [parisc-linux] kernel merge On Monday 13 November 2000 03:20, bame@riverrock.org wrote: > = > = Helge noticed SCSI fails (B160L, 712, I think it's ok on c3k) > = after the -test10 merge. > > Fixed. > > >From test6 to test10 the SCSI host registration method changed. > Updated sim700.c, lasi7xx.h, zalon7xx.h > > -P Thanks Paul, sim700 (53c710) now works again, but the second built-in controller (ncr/sym 53c8xx) still doesn't. Greetings, Helge From rhirst@linuxcare.com Mon, 13 Nov 2000 10:24:03 +0000 Date: Mon, 13 Nov 2000 10:24:03 +0000 From: Richard Hirst rhirst@linuxcare.com Subject: [parisc-linux] BEWARE: Makefile changed from parisc to parisc64 Confused me for a while, anyway. If you cvs update your kernel source and expect to build a 32 bit kernel, you need to edit the top level Makefile to change the arch := line. Richard From rhirst@linuxcare.com Mon, 13 Nov 2000 12:13:49 +0000 Date: Mon, 13 Nov 2000 12:13:49 +0000 From: Richard Hirst rhirst@linuxcare.com Subject: [parisc-linux] kernel merge On Fri, Nov 10, 2000 at 02:28:33PM -0700, bame@riverrock.org wrote: > drivers/scsi sym53c8xx_comm.h #ifdef doesn't work on parisc -- eliminates > unmap_pci_mem() causing link error (TODO - rhirst) Fixed. This relates to NVRAM that some PCI scsi cards have to hold config settings over reboot. CONFIG_SCSI_NCR53C8XX_NVRAM_DETECT is normally defined in sym53c8xx_defs.h to turn that code on. When I implemented Zalon (FWD) support I guessed that the 53c720 h/w wouldn't have NVRAM implemented the same way, and turned off NVRAM detect. I've also replaced a chunk of Zalon specific code that got lost in the merge, so Zalon/FWD/53c720 support works again. There is a problem remaining when using the driver as a module; it looks like something is trying to printk() from a string in the module after the module has been removed. Havn't tracked that down yet. Richard From adevries@linuxcare.com Mon, 13 Nov 2000 13:50:24 -0500 Date: Mon, 13 Nov 2000 13:50:24 -0500 From: Alex deVries adevries@linuxcare.com Subject: [parisc-linux] [Semi OT] SOM Linker dhazeghi@pacbell.net wrote: > However I would like to know what work if any has been done on the SOM > linker which HP released to the public last November(?). It seems that > as of right now, it has not been touched since February 14, and the FSF > binutils snapshots still do not have any SOM support for ld. Has there > been any movement in merging this in, or is anybody working on this? The initial plan was to do our 32-bit userspace with SOM, worrying about ELF32 much later in the game. But ELF32 development happened a lot quicker than expected, and so nobody's really done much on the SOM linker. I suspect it'd be very hard to use the SOM linker code to incorporate it into binutils, but I could be wrong. What are you actually trying to do? - Alex -- Alex deVries, Principal Solutions Architect, The Puffins at Linuxcare 613.562.2759 tel alex@linuxcare.com, http://www.linuxcare.com/ Linuxcare, Support for the revolution. From deller@gmx.de Mon, 13 Nov 2000 23:54:29 +0100 Date: Mon, 13 Nov 2000 23:54:29 +0100 From: Helge Deller deller@gmx.de Subject: sym53c8xx-driver (was: Re: [parisc-linux] kernel merge) On Monday 13 November 2000 13:13, Richard Hirst wrote: > On Fri, Nov 10, 2000 at 02:28:33PM -0700, bame@riverrock.org wrote: > > drivers/scsi sym53c8xx_comm.h #ifdef doesn't work on parisc -- eliminates > > unmap_pci_mem() causing link error (TODO - rhirst) > > Fixed. This relates to NVRAM that some PCI scsi cards have to hold > config settings over reboot. CONFIG_SCSI_NCR53C8XX_NVRAM_DETECT > is normally defined in sym53c8xx_defs.h to turn that code on. When > I implemented Zalon (FWD) support I guessed that the 53c720 h/w > wouldn't have NVRAM implemented the same way, and turned off > NVRAM detect. > > I've also replaced a chunk of Zalon specific code that got lost in > the merge, so Zalon/FWD/53c720 support works again. > > There is a problem remaining when using the driver as a module; > it looks like something is trying to printk() from a string in > the module after the module has been removed. Havn't tracked > that down yet. > > Richard Hi Richard, I'm sorry to say that the sym53c8xx still doesn't work on my B160L (32 bit-Kernel). It looks like the controller isn't detected at all, while it worked perfectly with 2.4.0-test6. Would you mind to take a look at the code again ? Thanks, Helge. From rhirst@linuxcare.com Mon, 13 Nov 2000 23:27:52 +0000 Date: Mon, 13 Nov 2000 23:27:52 +0000 From: Richard Hirst rhirst@linuxcare.com Subject: sym53c8xx-driver (was: Re: [parisc-linux] kernel merge) Hi Helge, The problem I fixed related to the ncr53c8xx driver (which shares code with sym53c8xx), and was to make 53c720 support work again. sym53c8xx worked for me on my A180. Please can you try booting with sym53c8xx=verb:7,debug:0xffff and send me the output? Thanks, Richard On Mon, Nov 13, 2000 at 11:54:29PM +0100, Helge Deller wrote: > On Monday 13 November 2000 13:13, Richard Hirst wrote: > > On Fri, Nov 10, 2000 at 02:28:33PM -0700, bame@riverrock.org wrote: > > > drivers/scsi sym53c8xx_comm.h #ifdef doesn't work on parisc -- eliminates > > > unmap_pci_mem() causing link error (TODO - rhirst) > > > > Fixed. This relates to NVRAM that some PCI scsi cards have to hold > > config settings over reboot. CONFIG_SCSI_NCR53C8XX_NVRAM_DETECT > > is normally defined in sym53c8xx_defs.h to turn that code on. When > > I implemented Zalon (FWD) support I guessed that the 53c720 h/w > > wouldn't have NVRAM implemented the same way, and turned off > > NVRAM detect. > > > > I've also replaced a chunk of Zalon specific code that got lost in > > the merge, so Zalon/FWD/53c720 support works again. > > > > There is a problem remaining when using the driver as a module; > > it looks like something is trying to printk() from a string in > > the module after the module has been removed. Havn't tracked > > that down yet. > > > > Richard > > > Hi Richard, > > I'm sorry to say that the sym53c8xx still doesn't work on my B160L (32 > bit-Kernel). It looks like the controller isn't detected at all, while it > worked perfectly with 2.4.0-test6. > Would you mind to take a look at the code again ? > > Thanks, > Helge. > From deller@gmx.de Tue, 14 Nov 2000 01:13:58 +0100 Date: Tue, 14 Nov 2000 01:13:58 +0100 From: Helge Deller deller@gmx.de Subject: sym53c8xx-driver (was: Re: [parisc-linux] kernel merge) --------------Boundary-00=_ABNZX5KGKOOFAA0B1BIM Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 8bit Subject: On Tuesday 14 November 2000 00:27, Richard Hirst wrote: > Hi Helge, > The problem I fixed related to the ncr53c8xx driver (which shares > code with sym53c8xx), and was to make 53c720 support work again. > sym53c8xx worked for me on my A180. Please can you try booting > with > > sym53c8xx=verb:7,debug:0xffff > > and send me the output? > > Thanks, > Richard Hi Richard, the output and the relevant part of .config is attached. Greetings, Helge --------------Boundary-00=_ABNZX5KGKOOFAA0B1BIM Content-Type: text/plain; name="log1" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="log1" Ci5jb25maWc6IAotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tCiMKIyBT Q1NJIHN1cHBvcnQKIwpDT05GSUdfU0NTST15CkNPTkZJR19CTEtfREVWX1NEPXkKQ09ORklHX1NE X0VYVFJBX0RFVlM9NDAKIyBDT05GSUdfQ0hSX0RFVl9TVCBpcyBub3Qgc2V0CkNPTkZJR19CTEtf REVWX1NSPXkKQ09ORklHX0JMS19ERVZfU1JfVkVORE9SPXkKQ09ORklHX1NSX0VYVFJBX0RFVlM9 MgpDT05GSUdfQ0hSX0RFVl9TRz15CkNPTkZJR19TQ1NJX01VTFRJX0xVTj15CkNPTkZJR19TQ1NJ X0NPTlNUQU5UUz15CgojCiMgU0NTSSBsb3ctbGV2ZWwgZHJpdmVycwojCkNPTkZJR19TQ1NJX0xB U0k9eQpDT05GSUdfU0NTSV9aQUxPTj15CkNPTkZJR19TQ1NJX1NZTTUzQzhYWD15CkNPTkZJR19T Q1NJX05DUjUzQzhYWF9ERUZBVUxUX1RBR1M9OApDT05GSUdfU0NTSV9OQ1I1M0M4WFhfTUFYX1RB R1M9MzIKQ09ORklHX1NDU0lfTkNSNTNDOFhYX1NZTkM9MjAKIyBDT05GSUdfU0NTSV9OQ1I1M0M4 WFhfUFJPRklMRSBpcyBub3Qgc2V0CiMgQ09ORklHX1NDU0lfTkNSNTNDOFhYX0lPTUFQUEVEIGlz IG5vdCBzZXQKCgotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0KCmJvb3QtbG9nOgotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tCgpGaXJtd2FyZSBWZXJzaW9uICA2LjEKCkR1cGxleCBDb25zb2xlIElPIERlcGVuZGVu dCBDb2RlIChJT0RDKSByZXZpc2lvbiAxCgpNZW1vcnkgVGVzdC9Jbml0aWFsaXphdGlvbiBDb21w bGV0ZWQgCgotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0KICAgKGMpIENvcHlyaWdodCAxOTk1LTE5OTgs IEhld2xldHQtUGFja2FyZCBDb21wYW55LCBBbGwgcmlnaHRzIHJlc2VydmVkCi0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLQoKICBQcm9jZXNzb3IgICBTcGVlZCAgICAgICAgICAgIFN0YXRlICAgICAgICAg ICBDb3Byb2Nlc3NvciBTdGF0ZSAgQ2FjaGUgU2l6ZQogIC0tLS0tLS0tLSAgLS0tLS0tLS0gICAt LS0tLS0tLS0tLS0tLS0tLS0tLS0gIC0tLS0tLS0tLS0tLS0tLS0tICAtLS0tLS0tLS0tCiAgICAg IDAgICAgICAxNjAgTUh6ICAgIEFjdGl2ZSAgICAgICAgICAgICAgICAgRnVuY3Rpb25hbCAgICAg ICAgICA2NCBLQgogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgIDEgTUIgZXh0CgoKICBBdmFpbGFibGUgbWVtb3J5IChieXRl cykgICAgOiAgNTM2ODcwOTEyIAogIEdvb2QgbWVtb3J5IHJlcXVpcmVkIChieXRlcyk6ICA1MzY4 NzA5MTIgCgogIFByaW1hcnkgYm9vdCBwYXRoOiAgICBGV1NDU0kuNi4wCiAgQWx0ZXJuYXRlIGJv b3QgcGF0aDogIExBTi4wLjAuMC4wLjAuMAogIENvbnNvbGUgcGF0aDogICAgICAgICBHUkFQSElD UygyKQogIEtleWJvYXJkIHBhdGg6ICAgICAgICBQUzIKCkNQVSAwCldBUk5JTkc6ICBTZWxmIHRl c3RzIGhhdmUgYmVlbiBkaXNhYmxlZCBhcyBhIHJlc3VsdCBvZiBGQVNUQk9PVAogICAgICAgICAg YmVpbmcgZW5hYmxlZC4gIFRvIGVuYWJsZSBzZWxmIHRlc3RzLCB1c2UgdGhlIEZBU1RCT09UCiAg ICAgICAgICBjb21tYW5kIGluIHRoZSBDT05GSUdVUkFUSU9OIG1lbnUgYW5kIHJlYm9vdCB0aGUg c3lzdGVtLgoKCi0tLS0tLS0gTWFpbiBNZW51IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0KCiAgICAgICAgQ29tbWFuZCAgICAgICAg ICAgICAgICAgICAgICAgICBEZXNjcmlwdGlvbgogICAgICAgIC0tLS0tLS0gICAgICAgICAgICAg ICAgICAgICAgICAgLS0tLS0tLS0tLS0KICAgICAgICBCT290IFtQUkl8QUxUfDxwYXRoPl0gICAg ICAgICAgIEJvb3QgZnJvbSBzcGVjaWZpZWQgcGF0aAogICAgICAgIFBBdGggW1BSSXxBTFR8Q09O fEtFWV0gWzxwYXRoPl0gRGlzcGxheSBvciBtb2RpZnkgYSBwYXRoCiAgICAgICAgU0VBcmNoIFtE SXNwbGF5fElQTF0gWzxwYXRoPl0gICBTZWFyY2ggZm9yIGJvb3QgZGV2aWNlcwoKICAgICAgICBD T25maWd1cmF0aW9uIFs8Y29tbWFuZD5dICAgICAgIEFjY2VzcyBDb25maWd1cmF0aW9uIG1lbnUv Y29tbWFuZHMKICAgICAgICBJTmZvcm1hdGlvbiBbPGNvbW1hbmQ+XSAgICAgICAgIEFjY2VzcyBJ bmZvcm1hdGlvbiBtZW51L2NvbW1hbmRzCiAgICAgICAgU0VSdmljZSBbPGNvbW1hbmQ+XSAgICAg ICAgICAgICBBY2Nlc3MgU2VydmljZSBtZW51L2NvbW1hbmRzCgogICAgICAgIERJc3BsYXkgICAg ICAgICAgICAgICAgICAgICAgICAgUmVkaXNwbGF5IHRoZSBjdXJyZW50IG1lbnUKICAgICAgICBI RWxwIFs8bWVudT58PGNvbW1hbmQ+XSAgICAgICAgIERpc3BsYXkgaGVscCBmb3IgbWVudSBvciBj b21tYW5kCiAgICAgICAgUkVTRVQgICAgICAgICAgICAgICAgICAgICAgICAgICBSZXN0YXJ0IHRo ZSBzeXN0ZW0KLS0tLS0tLQpNYWluIE1lbnU6IEVudGVyIGNvbW1hbmQgPiBibyBsYW4KSW50ZXJh Y3Qgd2l0aCBJUEwgKFksIE4sIFEpPz4gbgoKQm9vdGluZy4uLiAKTmV0d29yayBTdGF0aW9uIEFk ZHJlc3MgMDgwMDA5LWVmMzRmNQpTeXN0ZW0gSVAgQWRkcmVzcyAxOTIuMTY4LjEwMC4xNjAKU2Vy dmVyIElQIEFkZHJlc3MgMTkyLjE2OC4xMDAuMTAwCgpCb290IElPIERlcGVuZGVudCBDb2RlIChJ T0RDKSByZXZpc2lvbiAyCgoKSEFSRCBCb290ZWQuCnBhbG8gaXBsIHJvb3RAUDEwMCBUaHUgTm92 ICAyIDIwOjE0OjA4IE1FVCAyMDAwCjAvdm1saW51eCAyMjc0NzcxIGJ5dGVzIEAgMHg2ODAwCjAv cGFsby1jbWRsaW5lICcwL3ZtbGludXggSE9NRT0vIFRFUk09TElOVVggcm9vdD0vZGV2L25mcyBu ZnNyb290PTE5Mi4xNjguMTAwLjEwMDovdGZ0cGJvb3QvbmZzcm9vdCBjb25zb2xlPXR0eSBzeW01 M2M4eHg9dmVyYjo3LGRlYnVnOjB4ZmZmZicKS2VybmVsOiBwYXJ0aXRpb24gMCBmaWxlIC92bWxp bnV4CkVMRjMyIGV4ZWN1dGFibGUKCkVudHJ5IDAwMTAwMTkwIGZpcnN0IDAwMTAwMDAwIG4gNApT ZWdtZW50IDAgbG9hZCAwMDEwMDAwMCBzaXplIDE1MzQ2NjggbWVkaWFwdHIgMHgxMDAwClNlZ21l bnQgMSBsb2FkIDAwMjc4MDAwIHNpemUgMTgyMzQ0IG1lZGlhcHRyIDB4MTc4MDAwClNlZ21lbnQg MiBsb2FkIDAwMmE4MDAwIHNpemUgMTM5MTMyIG1lZGlhcHRyIDB4MWE1MDAwClNlZ21lbnQgMyBs b2FkIDAwMmNjMDAwIHNpemUgODE5MiBtZWRpYXB0ciAweDFjNzAwMApicmFuY2hpbmcgdG8ga2Vy bmVsIGVudHJ5IHBvaW50IDB4MDAxMDAxOTAKU2V0IGRlZmF1bHQgUFNXIFcgYml0IHRvIDAKUERD IENvbnNvbGUgSW5pdGlhbGl6ZWQKVGhlIDMyLWJpdCBLZXJuZWwgaGFzIHN0YXJ0ZWQuLi4KRW5h YmxlZCBGUCBjb3Byb2Nlc3NvcgpGcmVlIG1lbW9yeSBzdGFydHMgYXQ6IDB4YzAyZmQwMDAKc3Rh cnRfcGFyaXNjKDB4NTA0ZDZjLDB4NTA0ZDZjLDB4MCwweDApClBBTE8gY29tbWFuZCBsaW5lOiAn SE9NRT0vIFRFUk09TElOVVggcm9vdD0vZGV2L25mcyBuZnNyb290PTE5Mi4xNjguMTAwLjEwMDov dGZ0cGJvb3QvbmZzcm9vdCBjb25zb2xlPXR0eSBzeW01M2M4eHg9dmVyYjo3LGRlYnVnOjB4ZmZm ZicKUEFMTyBpbml0cmQgMC0wCm1vZGVsICAgMDAwMDUwMjAgMDAwMDA0ODEgMDAwMDAwMDAgMDIw MjAyMDIgNzc5NGQ3ZmUgMTAwMDAwZjAgMDAwMDAwMDQgMDAwMDAwYmEgMDAwMDAwYmEKdmVycyAg ICAwMDAwMDAwOApjcHVpZCAgIDAwMDAwMWU4CkNQVUlEIHZlcnMgMTUgcmV2IDgKU2VhcmNoaW5n IGZvciBkZXZpY2VzIGluIFBEQyBmaXJtd2FyZS4uLiBwcm9jZXNzb3IgaHBhIDB4ZmZmYmUwMDAK YSBuZXdlciBib3guLi4KRm91bmQgZGV2aWNlczoKMS4gUGhhbnRvbSBQc2V1ZG9CQyBHU0MrIFBv cnQgKDcpIGF0IDB4ZmZjMDAwMDAsIHZlcnNpb25zIDB4NTA0LCAweDAsIDB4MCwgMHgwLCAweDAK Mi4gTWVybGluIDE2MCBDb3JlIEZXLVNDU0kgKDQpIGF0IDB4ZmZmOGMwMDAsIHZlcnNpb25zIDB4 M2QsIDB4MCwgMHg4OSwgMHgwLCAweDgwCjMuIE1lcmxpbiBMMiAxNjAgKDkwMDAvNzc4L0IxNjBM KSAoMCkgYXQgMHhmZmZiZTAwMCwgdmVyc2lvbnMgMHg1MDIsIDB4MCwgMHg0LCAweDAsIDB4ODEK NC4gTWVybGluIDE2MC9UaHVuZGVySGF3ayBNZW1vcnkgKDEpIGF0IDB4ZmZmYmYwMDAsIHZlcnNp b25zIDB4NjcsIDB4MCwgMHg5LCAweDAsIDB4MAo1LiBNZXJsaW4gMTYwIENvcmUgQkEgKDExKSBh dCAweGZmZDAwMDAwLCB2ZXJzaW9ucyAweDNkLCAweDAsIDB4ODEsIDB4MCwgMHgwCjYuIE1lcmxp biAxNjAgQ29yZSBSUy0yMzIgKDEwKSBhdCAweGZmZDA1MDAwLCB2ZXJzaW9ucyAweDNkLCAweDAs IDB4OGMsIDB4MCwgMHgwCjcuIE1lcmxpbiAxNjAgQ29yZSBTQ1NJICgxMCkgYXQgMHhmZmQwNjAw MCwgdmVyc2lvbnMgMHgzZCwgMHgwLCAweDgyLCAweDAsIDB4MAo4LiBNZXJsaW4gMTYwIENvcmUg TGFuICg4MDIuMykgKDEwKSBhdCAweGZmZDA3MDAwLCB2ZXJzaW9ucyAweDNkLCAweDAsIDB4OGEs IDB4MCwgMHgwCjkuIE1lcmxpbiAxNjAgQ29yZSBDZW50cm9uaWNzICgxMCkgYXQgMHhmZmQwMjAw MCwgdmVyc2lvbnMgMHgzZCwgMHgwLCAweDc0LCAweDAsIDB4MAoxMC4gTWVybGluIDE2MCBDb3Jl IEF1ZGlvICgxMCkgYXQgMHhmZmQwNDAwMCwgdmVyc2lvbnMgMHgzZCwgMHg0LCAweDdiLCAweDAs IDB4MAoxMS4gTWVybGluIDE2MCBDb3JlIFBDIEtleWJvYXJkICgxMCkgYXQgMHhmZmQwODAwMCwg dmVyc2lvbnMgMHgzZCwgMHgwLCAweDg0LCAweDAsIDB4MAoxMi4gTWVybGluIDE2MCBDb3JlIFBD IEtleWJvYXJkICgxMCkgYXQgMHhmZmQwODEwMCwgdmVyc2lvbnMgMHgzZCwgMHgwLCAweDg0LCAw eDAsIDB4MAoxMy4gTWVybGluIDE2MCBXYXggQkEgKDExKSBhdCAweGZmZTAwMDAwLCB2ZXJzaW9u cyAweDQxLCAweDAsIDB4OGUsIDB4MCwgMHgwCjE0LiBNZXJsaW4gMTYwIFdheCBFSVNBIEJBICgx MSkgYXQgMHhmYzAwMDAwMCwgdmVyc2lvbnMgMHg0MSwgMHgwLCAweDkwLCAweDAsIDB4MAoxNS4g TWVybGluIDE2MCBXYXggSElMICgxMCkgYXQgMHhmZmUwMTAwMCwgdmVyc2lvbnMgMHg0MSwgMHgw LCAweDczLCAweDAsIDB4MAoxNi4gTWVybGluIDE2MCBXYXggUlMtMjMyICgxMCkgYXQgMHhmZmUw MjAwMCwgdmVyc2lvbnMgMHg0MSwgMHgwLCAweDhjLCAweDAsIDB4MAoxNy4gQ29yYWwgU0dDIEdy YXBoaWNzICgxMCkgYXQgMHhmNDAwMDAwMCwgdmVyc2lvbnMgMHg0LCAweDAsIDB4NzcsIDB4MCwg MHgwCjE4LiBHZWNrbyBHU0MgQ29yZSBHcmFwaGljcyAoMTApIGF0IDB4ZjgwMDAwMDAsIHZlcnNp b25zIDB4MTYsIDB4MCwgMHg4NSwgMHgwLCAweDAKMTkuIERpbm8gUENJIEJyaWRnZSAoMTMpIGF0 IDB4ZmZmODAwMDAsIHZlcnNpb25zIDB4NjgwLCAweDAsIDB4YSwgMHgwLCAweDAKVGhhdCdzIGEg dG90YWwgb2YgMTkgZGV2aWNlcy4KQ1BVKHMpOiAxIHggUEE3MzAwTEMgKFBDWC1MMikgYXQgMTYw LjAwMDAwMCBNSHoKTGludXggdmVyc2lvbiAyLjQuMC10ZXN0MTAgKHJvb3RAUDEwMCkgKGdjYyB2 ZXJzaW9uIDIuOTYgMjAwMDA5MjUgKGV4cGVyaW1lbnRhbCkpICMxNSBUdWUgTm92IDE0IDAxOjAx OjMzIE1FVCAyMDAwCmZyZWVfYm9vdG1lbSgweDMwMTAwMCwgMHgxZmNmZjAwMCkKaW5pdHJkOiAw MDAwMDAwMC0wMDAwMDAwMApwYWdldGFibGVfaW5pdApPbiBub2RlIDAgdG90YWxwYWdlczogMTMx MDcyCnpvbmUoMCk6IDY1NTM2IHBhZ2VzLgp6b25lKDEpOiA2NTUzNiBwYWdlcy4Kem9uZSgyKTog MCBwYWdlcy4KS2VybmVsIGNvbW1hbmQgbGluZTogSE9NRT0vIFRFUk09TElOVVggcm9vdD0vZGV2 L25mcyBuZnNyb290PTE5Mi4xNjguMTAwLjEwMDovdGZ0cGJvb3QvbmZzcm9vdCBjb25zb2xlPXR0 eSBzeW01M2M4eHg9dmVyYjo3LGRlYnVnOjB4ZmZmZgp0cmFwX2luaXQKQ29uc29sZTogY29sb3Vy IGR1bW15IGRldmljZSA4MHgyNQpyZWdpc3Rlcl9jb25zb2xlCkNhbGlicmF0aW5nIGRlbGF5IGxv b3AuLi4gMTA2LjUwIEJvZ29NSVBTCk1lbW9yeTogNTEwOTQ0ayBhdmFpbGFibGUKRGVudHJ5LWNh Y2hlIGhhc2ggdGFibGUgZW50cmllczogNjU1MzYgKG9yZGVyOiA3LCA1MjQyODggYnl0ZXMpCkJ1 ZmZlci1jYWNoZSBoYXNoIHRhYmxlIGVudHJpZXM6IDMyNzY4IChvcmRlcjogNSwgMTMxMDcyIGJ5 dGVzKQpQYWdlLWNhY2hlIGhhc2ggdGFibGUgZW50cmllczogMTMxMDcyIChvcmRlcjogNywgNTI0 Mjg4IGJ5dGVzKQpJbm9kZS1jYWNoZSBoYXNoIHRhYmxlIGVudHJpZXM6IDMyNzY4IChvcmRlcjog NiwgMjYyMTQ0IGJ5dGVzKQpQT1NJWCBjb25mb3JtYW5jZSB0ZXN0aW5nIGJ5IFVOSUZJWApMYXNp IHZlcnNpb24gMCBhdCAweGZmZDAwMDAwIGZvdW5kLgpXYXggYXQgMHhmZmUwMDAwMCBmb3VuZC4K V2F4OiBISUwgS2V5Ym9hcmQtTk1JIHJlZ2lzdGVyZWQuCnBhcnBvcnQwOiBQQy1zdHlsZSBhdCAw eGZmZDAyODAwLCBpcnEgODggW1BDU1BQLFRSSVNUQVRFXQpGb3VuZCBpODI1OTYgYXQgMHhmZmQw NzAwMCwgSVJRIDg3CmVhcmx5IGluaXRpYWxpemF0aW9uIG9mIGRldmljZSBldGgwIGlzIGRlZmVy cmVkCkluaXRpYWxpemluZyBMYXNpIFBTLzIta2V5Ym9hcmQgcG9ydCBhdCAweGZmZDA4MDAwLi4u ClN1cHBvcnQgZm9yIExhc2kgUFMvMi1wc2F1eCBub3QgeWV0IGF2YWlsYWJsZSAhCkZvdW5kIEhJ TCBhdCAweGZmZTAxMDAwLCBJUlEgMTI2Ck5vIGhhbmRsZXIgZm9yIGludGVycnVwdCAzNSAhCkhJ TDogdGltZWQgb3V0LCBhc3N1bWluZyBubyBrZXlib2FyZCBwcmVzZW50LgpXYXJuaW5nIDogZGV2 aWNlICgxMCwgMHg0MSwgMHgwLCAweDczLCAweDApIE5PVCBjbGFpbWVkIGJ5IEhJTCA3MTIsIDcx NSBvciBzaW1pbGlhcgpEaW5vIHZlcnNpb24gMi4wIChicmlkZ2UgbW9kZSkgZm91bmQgYXQgMHhm ZmY4MDAwMAoKClRoZSBHU0N0b1BDSSAoRGlubyBocmV2IDApIGJ1cyBjb252ZXJ0ZXIgZm91bmQg bWF5IGV4aGliaXQKZGF0YSBjb3JydXB0aW9uLiAgU2VlIFNlcnZpY2UgTm90ZSBOdW1iZXJzOiBB NDE5MEEtMDEsIEE0MTkxQS0wMS4KU3lzdGVtcyBzaGlwcGVkIGFmdGVyIEF1ZyAyMCwgMTk5NyB3 aWxsIG5vdCBleGhpYml0IHRoaXMgcHJvYmxlbS4KTW9kZWxzIGFmZmVjdGVkOiBDMTgwLCBDMTYw LCBDMTYwTCwgQjE2MEwsIGFuZCBCMTMyTCB3b3Jrc3RhdGlvbnMuCgpkaW5vX2JyaWRnZV9pbml0 OiBJT19BRERSX0VOIGhhc24ndCBiZWVuIGNvbmZpZ3VyZWQuCmtlcm5lbCBCVUcgYXQgZGluby5j OjY0NiEKTGludXggTkVUNC4wIGZvciBMaW51eCAyLjQKQmFzZWQgdXBvbiBTd2Fuc2VhIFVuaXZl cnNpdHkgQ29tcHV0ZXIgU29jaWV0eSBORVQzLjAzOQpTdGFydGluZyBrc3dhcGQgdjEuOApzdGlm Yi5jOiBzZWFyY2hpbmcgZm9yIHdvcmQgbW9kZSBTVEkgUk9Ncwpmb3VuZCBwb3RlbnRpYWwgU1RJ IFJPTSBhdCBmNDAwMDAwMApTVEkgYnl0ZSBtb2RlIFJPTSBhdCBmNDAwMDAwMCwgaWdub3JlZApm b3VuZCBwb3RlbnRpYWwgU1RJIFJPTSBhdCBmODAwMDAwMApwdHk6IDI1NiBVbml4OTggcHR5cyBj b25maWd1cmVkCmxwMDogdXNpbmcgcGFycG9ydDAgKGludGVycnVwdC1kcml2ZW4pLgpSQU1ESVNL IGRyaXZlciBpbml0aWFsaXplZDogMTYgUkFNIGRpc2tzIG9mIDQwOTZLIHNpemUgMTAyNCBibG9j a3NpemUKZXRoMDogODI1OTYgYXQgMHhmZmQwNzAwMCwgMDggMDAgMDkgRUYgMzQgRjUgSVJRIDg3 Lgo4MjU5Ni5jICRSZXZpc2lvbjogMS4xNCAkClNlcmlhbCBkcml2ZXIgdmVyc2lvbiA1LjAyICgy MDAwLTA4LTA5KSB3aXRoIE1BTllfUE9SVFMgU0hBUkVfSVJRIFNFUklBTF9QQ0kgZW5hYmxlZAp0 dHlTMDAgYXQgaW9tZW0gMHhmZmQwNTgwMCAoaXJxID0gOTApIGlzIGEgMTY1NTBBCnR0eVMwMSBh dCBpb21lbSAweGZmZTAyODAwIChpcnEgPSAxMjEpIGlzIGEgMTY1NTBBCkdlbmVyaWMgUlRDIERy aXZlciB2MS4wMiAwNS8yNy8xOTk5IFNhbSBDcmVhc2V5IChzYW1teUBvaC52ZXJpby5jb20pClND U0kgc3Vic3lzdGVtIGRyaXZlciBSZXZpc2lvbjogMS4wMApzaW03MDA6IENvbmZpZ3VyaW5nIDUz YzcxMCAoU0NTSS1JRCA3KSBhdCBmZmQwNjEwMCwgSVJRIDg2CnNjc2kwOiBSZXZpc2lvbiAweDIK UG9zdCB0ZXN0MSwgaXN0YXQgMDEsIHNzdGF0MCAwMCwgZHN0YXQgODQKc2ltNzAwOiBXQVJOSU5H IElSUSBwcm9iZSBmYWlsZWQsIChyZXR1cm5lZCAwKQpzY3NpMDogR29vZCwgdGFyZ2V0IGRhdGEg YXJlYXMgYXJlIGRtYSBjb2hlcmVudApzY3NpMDogdGVzdCAxIGNvbXBsZXRlZCBvay4Kc2NzaTA6 IHNpbTcwMF9pbnRyX2hhbmRsZSgpIGNhbGxlZCB3aXRoIG5vIGludGVycnVwdApzY3NpMCA6IExB U0kvU2ltcGxlIDUzYzd4eAogIFZlbmRvcjogUElPTkVFUiAgIE1vZGVsOiBDRC1ST00gRFItVTEy WCAgICBSZXY6IDEuMDYKICBUeXBlOiAgIENELVJPTSAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgQU5TSSBTQ1NJIHJldmlzaW9uOiAwMgpEZXRlY3RlZCBzY3NpIENELVJPTSBzcjAgYXQgc2Nz aTAsIGNoYW5uZWwgMCwgaWQgMCwgbHVuIDAKc3IwOiBzY3NpMy1tbWMgZHJpdmU6IDEyeC8xMngg eGEvZm9ybTIgY2RkYSB0cmF5ClVuaWZvcm0gQ0QtUk9NIGRyaXZlciBSZXZpc2lvbjogMy4xMQpz ZWFyY2hpbmcgZm9yIHdvcmQgbW9kZSBTVEkgUk9Ncwpmb3VuZCBwb3RlbnRpYWwgU1RJIFJPTSBh dCBmNDAwMDAwMApTVEkgYnl0ZSBtb2RlIFJPTSBhdCBmNDAwMDAwMCwgaWdub3JlZApmb3VuZCBw b3RlbnRpYWwgU1RJIFJPTSBhdCBmODAwMDAwMApzZWFyY2hpbmcgZm9yIGJ5dGUgbW9kZSBTVEkg Uk9Ncwpmb3VuZCBwb3RlbnRpYWwgU1RJIFJPTSBhdCBmNDAwMDAwMApTVEkgYnl0ZSBtb2RlIFJP TSB0eXBlIDEKIHN1cHBvcnRzIDE1IG1vbml0b3JzCiBjb25mb3JtcyB0byBTVEkgUk9NIHNwZWMg cmV2aXNpb24gOC4wNwpkdW1wX3N0aV9yb206IDUwMAogZ3JhcGhpY3MgaWQgMmQwOGMwYTcwOWEw MjU4NwpkdW1wX3N0aV9yb206IDUxMAogZm9udCBzdGFydCAwMDAxODNjMwpkdW1wX3N0aV9yb206 IDUxMgogcmVnaW9uIGxpc3QgMDAwMTgzNjMKZHVtcF9zdGlfcm9tOiA1MTQKIGluaXRfZ3JhcGgg MDAwMDFhNjMKZHVtcF9zdGlfcm9tOiA1MTYKIGFsdGVybmF0ZSBjb2RlIHR5cGUgMApkdW1wX3N0 aV9yb206IDUxOApuZXh0IGZvbnQgMDAwMDQwNDAKZjQwMDAwMDAgYgpmODAwMDAwMCBiClN3aXRj aGluZyBmcm9tIFBEQyBjb25zb2xlCg== --------------Boundary-00=_ABNZX5KGKOOFAA0B1BIM-- From rhirst@linuxcare.com Tue, 14 Nov 2000 10:17:04 +0000 Date: Tue, 14 Nov 2000 10:17:04 +0000 From: Richard Hirst rhirst@linuxcare.com Subject: sym53c8xx-driver (was: Re: [parisc-linux] kernel merge) Hi Helge, On Tue, Nov 14, 2000 at 01:13:58AM +0100, Helge Deller wrote: > On Tuesday 14 November 2000 00:27, Richard Hirst wrote: > > Hi Helge, > > The problem I fixed related to the ncr53c8xx driver (which shares > > code with sym53c8xx), and was to make 53c720 support work again. > > sym53c8xx worked for me on my A180. Please can you try booting > > with > > > > sym53c8xx=verb:7,debug:0xffff > > > > and send me the output? > > > > Thanks, > > Richard > > > Hi Richard, > > the output and the relevant part of .config is attached. > > Greetings, > > Helge Thanks. I agree it doesn't look like the driver is even seeing the chip; I wonder if PCI support is broken... > dino_bridge_init: IO_ADDR_EN hasn't been configured. > kernel BUG at dino.c:646! Does it usually say that on bootup? Richard From matthew@wil.cx Tue, 14 Nov 2000 10:29:36 +0000 Date: Tue, 14 Nov 2000 10:29:36 +0000 From: Matthew Wilcox matthew@wil.cx Subject: [parisc-linux] kernel merge On Fri, Nov 10, 2000 at 02:28:33PM -0700, bame@riverrock.org wrote: > fcntl.h acquired a 'struct fcntl64' used with 64-bit offsets, implementing > fcntl(fd, F_S/GETLK[W]64, ...). Several other locking-related #defines added. > > We'll need to add the getdents64() and fcntl64() syscall glue. (TODO!!!) actually, we don't. Linux/PA-RISC has sufficiently wide data types already so we don't have the grot required in other ports to support the appropriate wide data types. > looks like maybe the get/put_user_ret() functions in asm/uaccess.h are > obsolete? (TODO) yes, they are. exterminate! exterminate! -- Revolutions do not require corporate support. From deller@gmx.de Tue, 14 Nov 2000 14:11:42 +0100 (MET) Date: Tue, 14 Nov 2000 14:11:42 +0100 (MET) From: Helge Deller deller@gmx.de Subject: sym53c8xx-driver (was: Re: [parisc-linux] kernel merge) > Hi Helge, > > On Tue, Nov 14, 2000 at 01:13:58AM +0100, Helge Deller wrote: > > On Tuesday 14 November 2000 00:27, Richard Hirst wrote: > > > Hi Helge, > > > The problem I fixed related to the ncr53c8xx driver (which shares > > > code with sym53c8xx), and was to make 53c720 support work again. > > > sym53c8xx worked for me on my A180. Please can you try booting > > > with > > > > > > sym53c8xx=verb:7,debug:0xffff > > > > > > and send me the output? > > > > > > Thanks, > > > Richard > > > > > > Hi Richard, > > > > the output and the relevant part of .config is attached. > > > > Greetings, > > > > Helge > > Thanks. I agree it doesn't look like the driver is even seeing the > chip; I wonder if PCI support is broken... > > > dino_bridge_init: IO_ADDR_EN hasn't been configured. > > kernel BUG at dino.c:646! > > Does it usually say that on bootup? Yep. Has always been there, but nevertheless the scsi-driver worked before. FYI: The non-pci sim700-driver also didn't showed up before pb fixed it in CVS with a few one-line-patches. NB: Could maybe someone (ggg?) explain me the kernel-bug mentioned above ? > > Richard > Greetings, Helge -- Sent through GMX FreeMail - http://www.gmx.net From grundler@cup.hp.com Tue, 14 Nov 2000 08:10:42 -0800 Date: Tue, 14 Nov 2000 08:10:42 -0800 From: Grant Grundler grundler@cup.hp.com Subject: [parisc-linux] dino maintainer? Anyone interested in maintaining Dino? I don't have time for it and all the docs are on the web. One of the "TODO" things is to convert dino.c to use struct pci_hba the same way lba_pci.c does.... Richard Hirst wrote: ... > Thanks. I agree it doesn't look like the driver is even seeing the > chip; I wonder if PCI support is broken... > > > dino_bridge_init: IO_ADDR_EN hasn't been configured. > > kernel BUG at dino.c:646! > > Does it usually say that on bootup? per Helge's request: The bug is normal for card-mode Dino - not for Built-in Dino. I think Helge has the GSC 100BT card which is a card-mode Dino on-board with one (or two) Tulip(s) behind it. The warning is a reminder one can NOT use MMIO accesses to those PCI devices and *only* I/O Port space (eg inb/outb). If someone wants to fix the warning so it's quiet for card-mode devices...see is_card_dino(d) in dino_driver_callback() for an example. FYI - card-mode dino was used for several different networking interfaces but not SCSI interfaces. hope this helps, grant Grant Grundler Unix Systems Enablement Lab +1.408.447.7253 From bame@noam.fc.hp.com Tue, 14 Nov 2000 09:35:01 -0700 Date: Tue, 14 Nov 2000 09:35:01 -0700 From: Paul Bame bame@noam.fc.hp.com Subject: [parisc-linux] CVS linux Vs. -test10 I've attached an overview of differences between our CVS linux sources following the -test10 merge and the upstream -test10 sources. This document is also at http://puffin.external.hp.com/~bame/diff.html The raw 'diff' output (now a bit out of date) is at http://puffin.external.hp.com/~bame/diff.out If anyone gets bored, this list is full of small (and not so small) tasks which range from very simple (drivers/block/rd.c) to fairly complex (scripts/*). -P palinux Vs. linux 2.4.0-test10 Here's a brief summary of the differences in common code between palinux (tag: LINUS_240_TEST10_MERGED) and the upstream -test10 sources. The full diff output is in diff.out. NOTE this does not include machine-depend differences * Minor changes in several locations to support GSC * Minor top-level Makefile hacks, though the CFLAGS one is quite important. * Lots of RCS $Revision$ differences in ACPI (a different 'cvs import' would've eliminated these differences). * drivers/block/rd.c: obsolete debug code for parisc64. Changed a constant from 0xffffffffL to 0xffffffffUL because of a parisc64 gcc bug initializing longs. The repaired code is probably "more correct" anyway. * drivers/char/Config.in: changes to support LASI, parisc real-time clock (CONFIG_GENRTC) * drivers/char/Makefile: Config-related changes to support HP keyboards and RTC * drivers/char/console.c: looks like dead or dying experimental parisc code -- probably should be removed. Also some parisc-specific comments and format changes which should disappear. * drivers/char/serial.c: support for GSC and A500 serial * drivers/net/Makefile,Space.c: mostly LASI LAN support * drivers/net/eepro100.c: no clue about this one * drivers/net/tulip/interrupt.c: workaround for a B180+busy-lan boot problem -- probably should be sent upstream. * drivers/net/tulip/tulip_core.c: required #ifdef for hppa, also printk() changes which appear valid * drivers/parport/Makefile: GSC * drivers/parport/parport_gsc.c: New file for palinux -- GSC parallel ports -- required * drivers/pci/pci.c: eh? Grant? * drivers/pci/setup-bus.c: function definition tweek -- Grant? * drivers/scsi: Lots of changes here -- rhirst? See for yourself. Basics: support LASI and Zalon scsi, changes to 53c8xx drivers, rename sim7x0 to sim710 * drivers/sound: support for HP "Harmony" sound * drivers/video: STI and HP FB video drivers (iodccon is probably worthless) * fs: add support for SOM executables * fs/binfmt_elf.c,exec.c: changes for stack-grows-up? * fs/nfs/read.c: probably unnecessary hack for broken parisc64 gcc * fs/proc/array.c: ?? something with signals ?? * fs/stat.c: added __hppa__ to several #ifdefs * include/linux/binfmts.h,fs.h,kernel.h,tty.h,udf_fs_sb.h: unnecessary differences? * include/linux/init.h: we use different section names -- why????, probably some unnecessary other differences too * include/linux/mm.h: VM_STACK_FLAGS difference -- jsm? * include/linux/wait.h: parisc debugging -- should be removed * init/main.c: KWDB and GSC support plus a bunch of stuff which should probably go away. * kernel/Makefile,dma.c,fork.c,printk.c: eh? * kernel/module.c: possible parisc-needed changes * kernel/signal.c: unknown signal-related differences * lib/inflate.c: changed some constants to work around parisc64 gcc bug * mm/mprotect.c: ? * scripts/*: MANY differences here. Looks like a combination of things we hacked to fix configuration problems plus MAYBE not updating these files from new Linux versions in the past. 'make menuconfig' is significantly different from upstream. Even the mkdep.c program is different. From bame@noam.fc.hp.com Tue, 14 Nov 2000 10:02:06 -0700 Date: Tue, 14 Nov 2000 10:02:06 -0700 From: Paul Bame bame@noam.fc.hp.com Subject: [parisc-linux] kernel merge = On Fri, Nov 10, 2000 at 02:28:33PM -0700, bame@riverrock.org wrote: = > fcntl.h acquired a 'struct fcntl64' used with 64-bit offsets, implementing = > fcntl(fd, F_S/GETLK[W]64, ...). Several other locking-related #defines add ed. = > = > We'll need to add the getdents64() and fcntl64() syscall glue. (TODO!!!) = = actually, we don't. Linux/PA-RISC has sufficiently wide data types = already so we don't have the grot required in other ports to support = the appropriate wide data types. Ok that sounds great but I need a clue how to see it. struct flock contains an off_t which is 32 bits on narrow (wide too at the moment, but that will probably change). Also, struct dirent contains a 32-bit inode and a __kernel_off_t offset (d_off), which is also 32 bits narrow. I did see the ... in our fcntl() syscall definition so I'll go check glibc to see what's happening there. I wouldn't be so picky except that I need to write the 32/64 syscall translators for these soon! Thanks! -P From bame@noam.fc.hp.com Tue, 14 Nov 2000 10:14:51 -0700 Date: Tue, 14 Nov 2000 10:14:51 -0700 From: Paul Bame bame@noam.fc.hp.com Subject: [parisc-linux] kernel merge = On Fri, Nov 10, 2000 at 02:28:33PM -0700, bame@riverrock.org wrote: = > fcntl.h acquired a 'struct fcntl64' used with 64-bit offsets, implementing = > fcntl(fd, F_S/GETLK[W]64, ...). Several other locking-related #defines add ed. = > = > We'll need to add the getdents64() and fcntl64() syscall glue. (TODO!!!) = = actually, we don't. Linux/PA-RISC has sufficiently wide data types = already so we don't have the grot required in other ports to support = the appropriate wide data types. Oh, and won't we have to support these syscalls anyway, because user programs will make them? I suppose we could #define them in libc headers. = > looks like maybe the get/put_user_ret() functions in asm/uaccess.h are = > obsolete? (TODO) = = yes, they are. exterminate! exterminate! Done From pdbeal@louisville.edu Tue, 14 Nov 2000 13:40:24 -0500 Date: Tue, 14 Nov 2000 13:40:24 -0500 From: Phillip D. Beal pdbeal@louisville.edu Subject: [parisc-linux] 735/755 and Kernel test10.. Hey, I've been working on the 735 and 755 that I has access to and so far the systems booted the test6 kernel, but scrambled the console as soon as init was run. So, I figured I'd try the new test10 kernel that you have added. Both system boot, and then stop at this line: branching to kernel entry point 0x00100000 Can't select default wide mode, PDC_PSW call does not work What does the above actually mean? How can I remove the PDC_PSW call from the kernel so it can boot? I have plans to test this new kernel image on a 715 later today. Thanks, -- Phillip Beal Electrical and Computer Engineering S+LUG Vice-President From grundler@cup.hp.com Tue, 14 Nov 2000 10:51:26 -0800 Date: Tue, 14 Nov 2000 10:51:26 -0800 From: Grant Grundler grundler@cup.hp.com Subject: [parisc-linux] 735/755 and Kernel test10.. "Phillip D. Beal" wrote: > Hey, > > I've been working on the 735 and 755 that I has access to and so far > the systems booted the test6 kernel, but scrambled the console as soon > as init was run. So, I figured I'd try the new test10 kernel that you > have added. Both system boot, and then stop at this line: > > branching to kernel entry point 0x00100000 > Can't select default wide mode, PDC_PSW call does not work Did you build this kernel yourself? If so, it sounds like you built a 64-bit kernel since that's the default. You need to change the ARCH line in the linux/Makefile to read "parisc" instead of "parisc64". grant > > What does the above actually mean? How can I remove the PDC_PSW call > from the kernel so it can boot? I have plans to test this new kernel > image on a 715 later today. > > Thanks, > -- > Phillip Beal > Electrical and Computer Engineering > S+LUG Vice-President > > --------------------------------------------------------------------------- > To unsubscribe: send e-mail to parisc-linux-request@thepuffingroup.com with > `unsubscribe' as the subject. > Grant Grundler Unix Systems Enablement Lab +1.408.447.7253 From grundler@cup.hp.com Tue, 14 Nov 2000 11:08:20 -0800 Date: Tue, 14 Nov 2000 11:08:20 -0800 From: Grant Grundler grundler@cup.hp.com Subject: [parisc-linux] 735/755 and Kernel test10.. Grant Grundler wrote: > If so, it sounds like you built a 64-bit kernel since that's the default. Correction. *was* the default. default ARCH was changed last night to parisc. grant Grant Grundler Unix Systems Enablement Lab +1.408.447.7253 From ian.zink@maryville.com Tue, 14 Nov 2000 13:20:05 -0600 Date: Tue, 14 Nov 2000 13:20:05 -0600 From: Ian Zink ian.zink@maryville.com Subject: [parisc-linux] Palinux on a 712/60 I have a hp 712/60 I was trying to get loaded with Pa-linux. I'm using the 0.5 version of the Pa-linux cd. If I boot right off the CD it all loads until it gets to Switching to PDC. At that point nothing happens. From I have read the list, that is because the kernel is switching the text console. However, the 712s don't have consoles. From what I have also read the CD should work if you pass the kernel the parameter console=tty. So I tried to "boot scsi.2.0 isl" from the boot_admin prompt. It gave me the PALO ISL, but I could not choose which line I wanted to edit. Further, I couldn't even type "b" to boot. I don't know if the isl is freezing or what is taking place What I am wondering is there a way to boot a 712/80 without having to get cross-compiler gcc, compile the kernel, etc. Is there someway I could add the ramdisk-sti.tgz on the ISO to make it work? If so, what would need to be done? Thanks, Ian Zink, Systems Engineer Maryville Technologies 540 Maryville Centre, Suite 300 St. Louis, MO 63141 636/519-4182 (FAX) 636/519-4141 ian.zink@maryville.com www.maryville.com From mang@subcarrier.org Tue, 14 Nov 2000 14:17:35 -0500 Date: Tue, 14 Nov 2000 14:17:35 -0500 From: Michael Ang mang@subcarrier.org Subject: linux bame bame@riverrock.org wrote: > > = On Thu, Nov 09, 2000 at 03:53:48PM -0700, Paul Bame wrote: > = > Somebody never imported 2.4.0-test6, then I imported -test10 on the mai > n > = > vendor branch and now can't (easily) undo that to import test6 and THEN > = > test10. This workaround sucks. If the sources on the linus branch have been religiously tagged every time they're updated, then reverting to a previous would have been relatively painless. I'm not sure what "this workaround" was, but I guess at this point test10 is merged so the point is moot. > = don't use vendor branches. didn't you talk to mang about this? > > Um, I have no information to go on from your note. All the (successful) > merges I've done before have used the cookbook CVS merge method including > a vendor branch. Several (N-1?) of the palinux merges have been > accompanied by updating the vendor branch. And this merge is going > well despite the ugly workaround, or so it appears to me. Just > importing files to a vendor branch should have no effect on anything > else unless CVS has some horrible bug (RCS does not). Before I make > what is apparently a serious mistake ("don't use vendor branches" sounds > pretty serious) please enlighten me! Vendor branches are evil. (When I say "vendor branch" I mean the special kind of branch created by "cvs import".) When you check in to a vendor branch your changes will also be seen on the trunk, *unless* that file has been previously modified on the trunk. This is almost never what you want and adds confusion during merging (when you least want it). Tracking third-party sources using a normal branch, as we are doing, is much simpler and gives you more control. When I did the original import of Linus' sources I converted the vendor branch to a normal branch using cvs admin magic. So none of the annoyances of vendor branches should affect us, as long as any new files are added on the linus branch using "cvs add", NOT "cvs import". When you say you "I imported -test10 on the main vendor branch" I hope you really mean that you used "cvs add" on the linus branch. From your other messages, your tags looked good. - Mike. From bame@noam.fc.hp.com Tue, 14 Nov 2000 13:00:41 -0700 Date: Tue, 14 Nov 2000 13:00:41 -0700 From: Paul Bame bame@noam.fc.hp.com Subject: linux bame = bame@riverrock.org wrote: = > = > = On Thu, Nov 09, 2000 at 03:53:48PM -0700, Paul Bame wrote: = > = > Somebody never imported 2.4.0-test6, then I imported -test10 on the mai = > n = > = > vendor branch and now can't (easily) undo that to import test6 and THEN = > = > test10. This workaround sucks. = = If the sources on the linus branch have been religiously tagged every = time they're updated, then reverting to a previous would have been = relatively painless. I'm not sure what "this workaround" was, but I = guess at this point test10 is merged so the point is moot. Like the comment said, there was no copy of plain -test6 in CVS (that I saw). Without -test6 in CVS it's much harder to use cvs diff to figure out the right way to merge files when there are conflicts. I didn't realize this until -test10 was already there, so I *then* brought in -test6. They're in the wrong order on the 1.1.1 branch, so the standard merge command 'cvs -jlinus:yesterday -jlinus:' won't work next time -- explicit names will be required. = Vendor branches are evil. (When I say "vendor branch" I mean the = special kind of branch created by "cvs import".) When you check in to a = vendor branch your changes will also be seen on the trunk, *unless* that = file has been previously modified on the trunk. Thanks for clarifying what "evil" means! That is pretty ugly indeed! = This is almost never = what you want and adds confusion during merging (when you least want = it). Tracking third-party sources using a normal branch, as we are = doing, is much simpler and gives you more control. But I've seen no cook book for it. I'm guessing that instead of cvs import you use: cvs co -rlinus linux cd linux cvs commit (make note of new files from commit) cvs add cvs commit cvs tag LINUS_NEW_REVISION perhaps with provision for removing obsolete files too. I suppose that is simpler than a single cvs import command from a certain perspective :-) = When I did the original import of Linus' sources I converted the vendor = branch to a normal branch using cvs admin magic. So none of the = annoyances of vendor branches should affect us, as long as any new files = are added on the linus branch using "cvs add", NOT "cvs import". Have you a pointer to the magic or the knowledge to recreate it? I had no idea there was a special RCS marking for the evil type of branch. = When you say you "I imported -test10 on the main vendor branch" I hope = you really mean that you used "cvs add" on the linus branch. From your = other messages, your tags looked good. I used "cvs import", and either your branch magic worked, or I finished the merge before anybody randomly updated from cvs. Since import used 1.1.1, which is the branch you "fixed", it seems possible that 'cvs import' might be rendered harmless but I don't know that for sure. -P From pjlahaie@linuxcare.com Tue, 14 Nov 2000 15:43:00 -0500 Date: Tue, 14 Nov 2000 15:43:00 -0500 From: Paul J.Y. Lahaie pjlahaie@linuxcare.com Subject: [parisc-linux] Beta CD --SkvwRMAIpAhPCcCJ Content-Type: text/plain; charset=us-ascii Content-Disposition: inline This is to answer all the questions about sti console. Currently, in the CVS tree, serial console and STI console cannot be turned on at the same time. This means that a choice between serial/sti needs to be done at compile time. At the time we cut the beta, it was decided that serial console was more important than sti console. I am also working on resolving the problem with STI/serial console and once I have a fix ready, I will make a kernel image available. The current beta CD is also expecting a console on ttyS0 and does not currently open a ttyx getty. When I have a kernel that can decide the console at runtime, I will look into the beta CD issues. If you have any more questions or suggestions, feel free to email me or post on this list. Thank you. - Paul --SkvwRMAIpAhPCcCJ Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.4 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE6EaPR8ggPQthPCzcRAhT8AKC8EU8yusyoEvPHxKAQsaM0vMGthwCgnbbC Yz6ZWjq3q9B80bI+YRxc8xo= =HhRZ -----END PGP SIGNATURE----- --SkvwRMAIpAhPCcCJ-- From raj@cerias.purdue.edu Tue, 14 Nov 2000 16:18:06 -0500 Date: Tue, 14 Nov 2000 16:18:06 -0500 From: Brian Poole raj@cerias.purdue.edu Subject: [parisc-linux] Beta CD Sounds like a plan to me. I don't suppose you know how to make a 715 boot to console? Pulling the keyboard and monitor cables off the back just make it stop at boot with the unable to initiliaze keyboard error I posted with earlier. I am assuming there is some sort of boot_admin trickery necessary, but I am unaware of what it might entail and my poking around has yielded nothing.. Any advice here would be much appreciated. -b Quoting Paul J.Y. Lahaie (pjlahaie@linuxcare.com) from 14 November 2000: > with STI/serial console and once I have a fix ready, I will make a kernel > image available. The current beta CD is also expecting a console on .. > If you have any more questions or suggestions, feel free to email me or > post on this list. Thank you. From dave@hiauly1.hia.nrc.ca Tue, 14 Nov 2000 16:40:52 -0500 (EST) Date: Tue, 14 Nov 2000 16:40:52 -0500 (EST) From: John David Anglin dave@hiauly1.hia.nrc.ca Subject: abort in eliminate_regs compiling glob.c from glibc > > Breakpoint 2, eliminate_regs_in_insn (insn=0x406a0ba0, replace=0) > > at ../../gcc/reload1.c:2826 > > 2826 if (! insn_is_asm && icode < 0) > > (gdb) p debug_rtx (insn) > > (insn/s 2711 2709 2719 (set (reg:SI 6 %r6) > > (reg:SI 28 %r28)) 69 {pre_ldw-4} (insn_list 2708 (insn_list:REG_DEP_ANTI 2696 (insn_list:REG_DEP_ANTI 2702 (insn_list:REG_DEP_ANTI 2697 (nil))))) > > (expr_list:REG_DEAD (reg:SI 28 %r28) > > (insn_list:REG_RETVAL 2708 (expr_list:REG_EQUAL (expr_list (use (mem:BLK (scratch) 0)) > > (expr_list (symbol_ref/v:SI ("@strlen")) > > (expr_list (reg/v:SI 4 %r4) > > (nil)))) > > (nil))))) > > The `use' arises from the `__pure__' attribute in the prototype for strlen: > > extern size_t strlen (__const char *__s) __attribute__ ((__pure__)); Here is a patch to fix the abort in eliminate_regs when it encounters a USE. As I understand the situation, there are three conditions needed to trigger it: 1) A function that contains insns with an eliminable register. 2) The function must call __builtin_alloca to change the frame size from its initial size. 3) After the call to __builtin_alloca, there must be a call to a pure function. With the enclosed patch, I can now build glibc for hppa-linux with -O3 optimisation. Please review carefully because I will be the first to admit that I don't understand why the use is there in the first place and all the details of what eliminate_reg does. Dave -- J. David Anglin dave.anglin@nrc.ca National Research Council of Canada (613) 990-0752 (FAX: 952-6605) 2000-11-14 John David Anglin * reload1.c (eliminate_regs): Don't abort on MEM USEs. --- reload1.c.orig Wed Sep 27 14:27:23 2000 +++ reload1.c Tue Nov 14 16:01:56 2000 @@ -2499,6 +2499,10 @@ return x; case USE: + /* Handle insn_list USE that a call to a pure functions may generate. */ + new = eliminate_regs (XEXP (x, 0), 0, insn); + if (GET_CODE (new) == MEM) + return XEXP (new, 0); case CLOBBER: case ASM_OPERANDS: case SET: From grundler@cup.hp.com Tue, 14 Nov 2000 14:32:00 -0800 Date: Tue, 14 Nov 2000 14:32:00 -0800 From: Grant Grundler grundler@cup.hp.com Subject: [parisc-linux] Palinux on a 712/60 Ian Zink wrote: > I have a hp 712/60 I was trying to get loaded with Pa-linux. I'm using the > 0.5 version of the Pa-linux cd. If I boot right off the CD it all loads > until it gets to Switching to PDC. At that point nothing happens. From I > have read the list, that is because the kernel is switching the text > console. However, the 712s don't have consoles. 712s have consoles. They have two outputs which can be used as console by linux. The STI consoles (VGA-like spigot) and serial. Connect a serial cable 9600-8-n-1 and run minicom at the other end. > From what I have also read > the CD should work if you pass the kernel the parameter console=tty. So I > tried to "boot scsi.2.0 isl" from the boot_admin prompt. It gave me the > PALO ISL, but I could not choose which line I wanted to edit. Further, I > couldn't even type "b" to boot. I don't know if the isl is freezing or what > is taking place That's a different problem...pb? > What I am wondering is there a way to boot a 712/80 without having > to get cross-compiler gcc, compile the kernel, etc. The CD was intended to also work on the 712 even though we may not have tested on it. > Is there someway I could > add the ramdisk-sti.tgz on the ISO to make it work? If so, what would need > to be done? no clue. anyone else? grant Grant Grundler Unix Systems Enablement Lab +1.408.447.7253 From mang@subcarrier.org Tue, 14 Nov 2000 17:31:22 -0500 Date: Tue, 14 Nov 2000 17:31:22 -0500 From: Michael Ang mang@subcarrier.org Subject: [parisc-linux] tracking third-party sources (was Re: linux bame) Paul Bame wrote: > > = bame@riverrock.org wrote: > = > > = > = On Thu, Nov 09, 2000 at 03:53:48PM -0700, Paul Bame wrote: > = > = > Somebody never imported 2.4.0-test6, then I imported -test10 on the > mai > = > n > = > = > vendor branch and now can't (easily) undo that to import test6 and > THEN > = > = > test10. This workaround sucks. > = > Like the comment said, there was no copy of plain -test6 in CVS (that I > saw). Without -test6 in CVS it's much harder to use cvs diff to figure > out the right way to merge files when there are conflicts. > I didn't realize this until -test10 was already there, so I *then* > brought in -test6. They're in the wrong order on the 1.1.1 branch, so > the standard merge command 'cvs -jlinus:yesterday -jlinus:' > won't work next time -- explicit names will be required. The best thing to do is to import -test10 again and move the static tag by re-tagging. > = Tracking third-party sources using a normal branch, as we are > = doing, is much simpler and gives you more control. > > But I've seen no cook book for it. I'm guessing that instead of cvs import > you use: > cvs co -rlinus linux > > cd linux > cvs commit (make note of new files from commit) > cvs add > cvs commit > cvs tag LINUS_NEW_REVISION > perhaps with provision for removing obsolete files too. I suppose that is > simpler than a single cvs import command from a certain perspective :-) I had a good chat with Paul about this, and we worked out that using "import" is marginally better. This is what the add/remove method would look like: cvs co -rlinux linux cvs rm cvs add cvs commit cvs tag LINUS_NEW_REVISION Add the import method: cd linux cvs import linux linus LINUS_NEW_REVISION cvs admin -b > = When you say you "I imported -test10 on the main vendor branch" I hope > = you really mean that you used "cvs add" on the linus branch. From your > = other messages, your tags looked good. > > I used "cvs import", and either your branch magic worked, or I finished the > merge before anybody randomly updated from cvs. Since import used 1.1.1, > which is the branch you "fixed", it seems possible that 'cvs import' might > be rendered harmless but I don't know that for sure. Using "import" to bring in new files taints them with the vendor branch badness. These files should be adjusted using "cvs admin -b". Note that "cvs admin" works directly on files in the repository at low level (without any revisioning of changes) and is thus to be avoided if at all possible. Please don't run "cvs admin" if you (the collective "you") don't know the consequences. - Mike. From ian.zink@maryville.com Tue, 14 Nov 2000 17:08:33 -0600 Date: Tue, 14 Nov 2000 17:08:33 -0600 From: Ian Zink ian.zink@maryville.com Subject: [parisc-linux] Palinux on a 712/60 Thanks for the reply, Grant. However, the 712s do not have a serial console. They do have a com port, but it does not work as a console, unfortunately. So I need do need to get a STI enabled kernel. I dropped Paul Lahaie a note to see if he could send me such a kernel so I do not have to create the entire cross-platform development environment just to boot one of these 712s. After I get it, I plan on expanding the 0.5 iso and making a new one using the STI console kernel. Ian From kailasr@webcash.com Tue, 14 Nov 2000 14:58:55 -0800 Date: Tue, 14 Nov 2000 14:58:55 -0800 From: Kailashnath V Rampure kailasr@webcash.com Subject: [parisc-linux] Boot command I have booted HP A class server through network. On that I have repartioned the system and followed the steps on http://www.parisc-linux.org/install.html. I have used the following command to initialize the hard disk. The kernel I have downloaded is vmlinux-20001018. and cpied it to /mnt/boot/vmlinux after mounting /dev/sda3. I have used the following command to initialize the HDD. palo -I -k /boot/vmlinux -b /boot/iplboot \ -c '3/boot/vmlinux TERM=linux HOME=/ root=/dev/sda3' \ /dev/sda -------------------------------- I get the following error: -------------------------------- SOFT Boot. palo ipl bame@noam Tue oct 31 14:18:02 MST 2000 0/vmlinux 2138614 bytes@ 0x1f78c000 0/palo-cmdline '3/boot/vmlinux TERM=linux HOME=/ root=/dev/sda3' /dev/ida1 82 62 1030688 /dev/ida2 f0 1030750 24738 /dev/ida3 83 1055488 1030750 Kernel:partition 3 file /boot/vmlinux ext2 block size 1024 ext2_mount(partition 3) returns 0 ext2_open(/boot/vmlinux) = -1 open /boot/vmlinux failed ------------------------------------- Please suggest. From grundler@cup.hp.com Tue, 14 Nov 2000 15:18:10 -0800 Date: Tue, 14 Nov 2000 15:18:10 -0800 From: Grant Grundler grundler@cup.hp.com Subject: [parisc-linux] Palinux on a 712/60 Ian Zink wrote: > Thanks for the reply, Grant. However, the 712s do not have a serial console. > They do have a com port, but it does not work as a console, unfortunately. It does for linux. That's what the "Switching from PDC Console" is about. Connect the serial cable to the com port and look at the output. I've done it in the past and know it worked at least once. I haven't tried it with the lasted ISO - no time to play w/712's now. > So I need do need to get a STI enabled kernel. I dropped Paul Lahaie a note > to see if he could send me such a kernel... Paul just sent mail to the list indicating he's working on console issues. Please let him work on it. Trust me, he'll tell us when he's done. :^) grant From dhazeghi@pacbell.net Tue, 14 Nov 2000 18:17:39 -0800 Date: Tue, 14 Nov 2000 18:17:39 -0800 From: dhazeghi@pacbell.net dhazeghi@pacbell.net Subject: [parisc-linux] [Semi OT] SOM Linker Alex deVries wrote: > dhazeghi@pacbell.net wrote: > > However I would like to know what work if any has been done on the SOM > > linker which HP released to the public last November(?). It seems that > > as of right now, it has not been touched since February 14, and the FSF > > binutils snapshots still do not have any SOM support for ld. Has there > > been any movement in merging this in, or is anybody working on this? > > The initial plan was to do our 32-bit userspace with SOM, worrying about > ELF32 much later in the game. But ELF32 development happened a lot > quicker than expected, and so nobody's really done much on the SOM > linker. That's what it looked like... > > > I suspect it'd be very hard to use the SOM linker code to incorporate it > into binutils, but I could be wrong. > > What are you actually trying to do? I would like to be able to set up a cross compilation environment for hpux and 32 bit PA-RISC. However without a functional cross linker, this is impossible to do, and as binutils has not got one yet, I thought perhaps the one that HP open-sourced might be some use. It would seem logical that with the sources available, it shouldn't be too difficult to fix the broken bits and get a SOM linker working in binutils, but that doesn't seem to have happened yet. Oh well, thanks for the info... Dara Hazeghi From dave@hiauly1.hia.nrc.ca Tue, 14 Nov 2000 22:00:25 -0500 (EST) Date: Tue, 14 Nov 2000 22:00:25 -0500 (EST) From: John David Anglin dave@hiauly1.hia.nrc.ca Subject: [parisc-linux] [Semi OT] SOM Linker > I would like to be able to set up a cross compilation environment for hpux and > 32 bit PA-RISC. However without a functional cross linker, this is impossible > to do, and as binutils has not got one yet, I thought perhaps the one that HP > open-sourced might be some use. It would seem logical that with the sources > available, it shouldn't be too difficult to fix the broken bits and get a SOM > linker working in binutils, but that doesn't seem to have happened yet. Oh > well, thanks for the info... You should be able to build cross compilation tools under hpux for hppa-linux. First you should install native versions of binutils and gcc under hpux (this assumes that you have the hpux C compiler and linker). The release version of gcc (2.95.2) would be a good choice. The standard hpux linker works fine with gcc/gas for C compilations. Then follow the directions at www.parisc-linux.org for building the cross compilation tools and linux. Dave -- J. David Anglin dave.anglin@nrc.ca National Research Council of Canada (613) 990-0752 (FAX: 952-6605) From dhazeghi@pacbell.net Tue, 14 Nov 2000 21:23:41 -0800 Date: Tue, 14 Nov 2000 21:23:41 -0800 From: dhazeghi@pacbell.net dhazeghi@pacbell.net Subject: [parisc-linux] [Semi OT] SOM Linker John David Anglin wrote: > > I would like to be able to set up a cross compilation environment for hpux and > > 32 bit PA-RISC. However without a functional cross linker, this is impossible > > to do, and as binutils has not got one yet, I thought perhaps the one that HP > > open-sourced might be some use. It would seem logical that with the sources > > available, it shouldn't be too difficult to fix the broken bits and get a SOM > > linker working in binutils, but that doesn't seem to have happened yet. Oh > > well, thanks for the info... > > You should be able to build cross compilation tools under hpux for hppa-linux. > First you should install native versions of binutils and gcc under hpux (this > assumes that you have the hpux C compiler and linker). The release version of > gcc (2.95.2) would be a good choice. The standard hpux linker works fine with > gcc/gas for C compilations. Then follow the directions at www.parisc-linux.org > for building the cross compilation tools and linux. This is not precisely what I mean. What I should have said is that I want to create a cross compiler --host=i686-linux --target=hppa-hpux. I asked this list, because you folks did some work on the SOM linker, which is at the moment the missing piece for a cross toolchain which targets hpux. Thanks, Dara P.S. On a different note, is the recipe fully up to date? I tried following it a few weeks ago, but glibc did not complete building successfully. From Arnaud.ATOCH@oecd.org Wed, 15 Nov 2000 10:05:04 +0100 Date: Wed, 15 Nov 2000 10:05:04 +0100 From: Arnaud.ATOCH@oecd.org Arnaud.ATOCH@oecd.org Subject: [parisc-linux] Palinux on a 712/60 Hi, I got a couple of 715 and I'd love having access to an ISO image with STI console kernel too. -----Original Message----- From: Ian Zink [mailto:ian.zink@maryville.com] Sent: Wednesday, November 15, 2000 00:09 To: 'parisc-linux@thepuffingroup.com' Subject: RE: [parisc-linux] Palinux on a 712/60 Thanks for the reply, Grant. However, the 712s do not have a serial console. They do have a com port, but it does not work as a console, unfortunately. So I need do need to get a STI enabled kernel. I dropped Paul Lahaie a note to see if he could send me such a kernel so I do not have to create the entire cross-platform development environment just to boot one of these 712s. After I get it, I plan on expanding the 0.5 iso and making a new one using the STI console kernel. Ian --------------------------------------------------------------------------- To unsubscribe: send e-mail to parisc-linux-request@thepuffingroup.com with `unsubscribe' as the subject. From rhirst@linuxcare.com Wed, 15 Nov 2000 09:58:35 +0000 Date: Wed, 15 Nov 2000 09:58:35 +0000 From: Richard Hirst rhirst@linuxcare.com Subject: [parisc-linux] dino maintainer? On Tue, Nov 14, 2000 at 08:10:42AM -0800, Grant Grundler wrote: > The bug is normal for card-mode Dino - not for Built-in Dino. > I think Helge has the GSC 100BT card which is a card-mode Dino on-board > with one (or two) Tulip(s) behind it. > > The warning is a reminder one can NOT use MMIO accesses to those > PCI devices and *only* I/O Port space (eg inb/outb). > > If someone wants to fix the warning so it's quiet for card-mode > devices...see is_card_dino(d) in dino_driver_callback() for an > example. > > FYI - card-mode dino was used for several different networking > interfaces but not SCSI interfaces. But Helge has problems with the sym53c8xx driver on a B160L. Is that a PCI card driven via Dino? And if so, are you saying he needs to build his kernel with CONFIG_SCSI_NCR53C8XX_IOMAPPED=y so it doesn't try to use MMIO? Helge, it might be worth trying to switch on CONFIG_SCSI_NCR53C8XX_IOMAPPED anyway just to see what happens. Otherwise someone needs to start adding printk debug to figure out what is happening. I can't do that as I don't have a sym53c8xx pci card. Richard From andrew@neep.com.au Wed, 15 Nov 2000 18:10:13 +0800 Date: Wed, 15 Nov 2000 18:10:13 +0800 From: Andrew Shugg andrew@neep.com.au Subject: [parisc-linux] Palinux on a 712/60 Arnaud.ATOCH@oecd.org said: > Hi, > > I got a couple of 715 and I'd love having access to an ISO image with STI > console kernel too. I've never made an El Torito CDROM, is it possible to have multiple boot images and a boot loader on a single disc? ie could the actual boot image be a boot loader (PALO) which then points at one or more kernels on the CDROM? Andrew. -- Andrew Shugg http://www.neep.com.au/ "Just remember, Mr Fawlty, there's always someone worse off than yourself." "Is there? Well I'd like to meet him. I could do with a good laugh." From marteaut@esiee.fr Wed, 15 Nov 2000 11:25:07 +0100 Date: Wed, 15 Nov 2000 11:25:07 +0100 From: Thomas Marteau marteaut@esiee.fr Subject: [parisc-linux] Palinux on a 712/60 Hi Ian, If you like to see a linux kernel booting on your 712, you can donwload a fully operationnal root file system with the STI console and an extra terminal with the RS232 port at http://www.esiee.fr/puffin You have also all the info to make a bootable hard disk so try it and give us feedback... Bye, Thomas Marteau ESIEE Team From rhirst@linuxcare.com Wed, 15 Nov 2000 11:12:20 +0000 Date: Wed, 15 Nov 2000 11:12:20 +0000 From: Richard Hirst rhirst@linuxcare.com Subject: [parisc-linux] Beta CD On Fri, Nov 10, 2000 at 05:14:06PM -0500, Paul J.Y. Lahaie wrote: > Hello fellow PA-RISCers, > > An preliminary beta CD for PA/Linux has been uploaded to > puffin.external.hp.com. If people could try it and forward any complaints > or suggestions to me, it would be greatly appreciated. The URL for the > image is: ftp://puffin.external.hp.com/pub/parisc/cd-images/palinux-0.5.iso.gz I just borrowed a CDROM drive for my 715/75 so I could try it on there [Actually this is the palinux-0.5.iso.gz that I commented on, not the final version]. I wasn't successful: Sometimes the boot hangs after "ASP version 1 at 0xf0800000 found", waits a few seconds and then HPMCs. The scsi driver always has serious problems with the CD drive but does detect other devices on the bus. The kernel always crashes after "Serial driver version 5.01...", (if it gets that far) with Data access rights fault in kernel: Code=26 regs=c5f9c940 (Addr=00000003) YZrvWESTHLNXBCVMcbcbcbcbOGFRQPDI PSW: 00000000000001000000000000001010 r0-3 00000000 c0217800 c011e9f8 c5ff64a0 r4-7 c5ff6200 c023ab20 00000008 f0823800 r8-11 00000003 00000007 c019134c c02b20a0 r12-15 fffffffc c023a800 c023a800 c02c31cc r16-19 c023a800 c023a800 c02b2024 00000000 r20-23 c5ff6234 f0823807 f0823800 0000000a r24-27 ffffffff c5ff64a0 c5ff6200 c0258000 r28-31 ffffffff 000002c0 c5f9cb80 c012dfc0 sr0-4 00000000 00000000 00000000 00000000 sr4-8 00000000 00000000 00000000 00000000 IASQ: 00000000 00000000 IAOQ: c011e710 c011e714 IIR: 0f881093 ISR: 00000000 IOR: 00000003 ORIG_R28: 00000058 I'll investigate further when I have the time. Richard From adevries@linuxcare.com Wed, 15 Nov 2000 11:50:27 -0500 Date: Wed, 15 Nov 2000 11:50:27 -0500 From: Alex deVries adevries@linuxcare.com Subject: [parisc-linux] dino maintainer? Richard Hirst wrote: > On Tue, Nov 14, 2000 at 08:10:42AM -0800, Grant Grundler wrote: > > FYI - card-mode dino was used for several different networking > > interfaces but not SCSI interfaces. > > But Helge has problems with the sym53c8xx driver on a B160L. Is > that a PCI card driven via Dino? And if so, are you saying he needs > to build his kernel with CONFIG_SCSI_NCR53C8XX_IOMAPPED=y so it > doesn't try to use MMIO? Hang on a sec... what Grant's saying is that *card-mode* dino is never used for SCSI controllers, but on the B160L it would probably be *chip-mode* dino. Does this mean that all GSC SCSI expansion cards are Zalon based? So what Helge has isn't a PCI card specifically, Dino and the 53c8xx are all on the motherboard. Does Dino handle IO memory mapping differently for chip or card mode? - Alex -- Alex deVries, Principal Solutions Architect, The Puffins at Linuxcare 613.562.2759 tel alex@linuxcare.com, http://www.linuxcare.com/ Linuxcare, Support for the revolution. From grundler@cup.hp.com Wed, 15 Nov 2000 08:06:32 -0800 Date: Wed, 15 Nov 2000 08:06:32 -0800 From: Grant Grundler grundler@cup.hp.com Subject: [parisc-linux] dino maintainer? Richard Hirst wrote: > On Tue, Nov 14, 2000 at 08:10:42AM -0800, Grant Grundler wrote: > > The bug is normal for card-mode Dino - not for Built-in Dino. > > I think Helge has the GSC 100BT card which is a card-mode Dino on-board > > with one (or two) Tulip(s) behind it. Helge confirmed he has no such card. I think the PDC simply isn't programming the Dino IO_ADDR_EN since there are no PCI devices in his B160. Helge's B160 has a old rev of Dino PCI host bus adapter chip. It's possible to have "silent" data corruption caused by older revs of dino - 3.0 and older. The latest PDC Revisions (5.x and later) know this and won't permit the system to be booted unless the only devices on the PCI bus are known graphics interface cards. > > The warning is a reminder one can NOT use MMIO accesses to those > > PCI devices and *only* I/O Port space (eg inb/outb). > > > > If someone wants to fix the warning so it's quiet for card-mode > > devices...see is_card_dino(d) in dino_driver_callback() for an > > example. This is still correct for card-mode dino. > > FYI - card-mode dino was used for several different networking > > interfaces but not SCSI interfaces. > > But Helge has problems with the sym53c8xx driver on a B160L. Is > that a PCI card driven via Dino? I doubt it now. If Helge could send richard "in io" output, I think that would clarify what's in the B160. > And if so, are you saying he needs > to build his kernel with CONFIG_SCSI_NCR53C8XX_IOMAPPED=y so it > doesn't try to use MMIO? no. no SCSI was ever implement on a card-mode dino board. No reason to since they already had Zalon or open slots. grant > Helge, it might be worth trying to switch on CONFIG_SCSI_NCR53C8XX_IOMAPPED > anyway just to see what happens. Otherwise someone needs to start > adding printk debug to figure out what is happening. I can't do > that as I don't have a sym53c8xx pci card. > > Richard From grundler@cup.hp.com Wed, 15 Nov 2000 08:17:41 -0800 Date: Wed, 15 Nov 2000 08:17:41 -0800 From: Grant Grundler grundler@cup.hp.com Subject: [parisc-linux] dino maintainer? Alex deVries wrote: > Hang on a sec... what Grant's saying is that *card-mode* dino is never > used for SCSI controllers, but on the B160L it would probably be > *chip-mode* dino. No such thing - you probably mean "Bridge Mode" and that's what the built-in Dino is using. > Does this mean that all GSC SCSI expansion cards are Zalon based? > > So what Helge has isn't a PCI card specifically, Dino and the 53c8xx are > all on the motherboard. > > Does Dino handle IO memory mapping differently for chip or card mode? yes. yes. yes (conditional). "IO memory mapping" is a confusing term. I'll assume you mean MMIO. (Memory Mapped I/O) MMIO space access is independent of I/O Port space access. MMIO space access simple isn't available for card-mode Dino since niether PDC nor the OS assigns host physical address space to the card-mode Dino (that's what IO_ADDR_EN is for). PDC does this for Bridge-mode dino (built-in) - but apperently only when it needs to. I/O Port space accesses are done the same way for both modes. I/O Port space access is implemented by poking registers on Dino. Read the Dino Spec (or source) for more details. grant Grant Grundler Unix Systems Enablement Lab +1.408.447.7253 From dave@hiauly1.hia.nrc.ca Wed, 15 Nov 2000 11:23:05 -0500 (EST) Date: Wed, 15 Nov 2000 11:23:05 -0500 (EST) From: John David Anglin dave@hiauly1.hia.nrc.ca Subject: [parisc-linux] [Semi OT] SOM Linker > This is not precisely what I mean. What I should have said is that I want to create > a cross compiler --host=i686-linux --target=hppa-hpux. I asked this list, because > you folks did some work on the SOM linker, which is at the moment the missing piece > for a cross toolchain which targets hpux. This also may be possible. The first step would be to copy the hpux headers to a i686-linux system and see if you can build the HP linker. The next step would be to try to build the cross binutils tools. I know this requires the hpux headers and likely some hacking would be required to get it to build. The linker is probably the hard part. There may be byte ordering issues and bugs in what HP contributed. Dave -- J. David Anglin dave.anglin@nrc.ca National Research Council of Canada (613) 990-0752 (FAX: 952-6605) From pdbeal@louisville.edu Wed, 15 Nov 2000 11:47:09 -0500 Date: Wed, 15 Nov 2000 11:47:09 -0500 From: Phillip D. Beal pdbeal@louisville.edu Subject: [parisc-linux] Beta CD On Fri, Nov 10, 2000 at 05:14:06PM -0500, Paul J.Y. Lahaie wrote: > Hello fellow PA-RISCers, > > An preliminary beta CD for PA/Linux has been uploaded to > puffin.external.hp.com. If people could try it and forward any complaints > or suggestions to me, it would be greatly appreciated. The URL for the > image is: ftp://puffin.external.hp.com/pub/parisc/cd-images/palinux-0.5.iso.gz > > - Paul the CD worked great on the 715 I tried, and I actually didn't have a serial console machine, so I used my Palm Pilot and a link cable. Still worked like a charm. How did you get the kernel image into the boot sector of the CD? I'd like to try to build some CD's of the kernels I'm building to test in some mahcines that are not on the same network as the machine that I'm building everything from. And I don't mind posting my CD images somewhere if they work...but most of my testing is on a 735 or 755. Thanks, -- Phillip Beal Electrical and Computer Engineering S+LUG Vice-President From bame@noam.fc.hp.com Wed, 15 Nov 2000 10:08:22 -0700 Date: Wed, 15 Nov 2000 10:08:22 -0700 From: Paul Bame bame@noam.fc.hp.com Subject: [parisc-linux] Help with posix_types.h I'm reviewing the posix_types.h to figure out what's right for 64-bit linux. I know others may have thought through this before so I'm hoping for guidance. For those unfamiliar, the type names in posix_types.h are like __kernel_dev_t and usually are used to define the corresponding "normal" type (dev_t). These should be settled before the 32/64 syscall wrappers can be completed. __kernel_ino_t: often 32 bits, currently 32 bits for parisc and som3 64-bit kernels (mips64 and ia64). 64 bits on alpha and sparc64. Seems to me this ought to be 32 bits on parisc and parisc64, or 64 bits on both, since it's a function of file system sizes not processor width. HPUX kernel seems to always use 32 bits, but 64-bit userspace uses 64 bits. I propose 32 bits on both, but willy had selected 64 bits in parisc64 for some reason. __kernel_off_t: seems to be 32 bits on 32-bit cpus, 64 on 64-bit ones. This is supposedly the offset from a beginning of a file. HPUX appears to use 64-bits *in the kernel* for both 32 and 64-bit kernels. The obvious pattern is to make ours 32 on narrow, and 64 on wide palinux so I guess I propose that, and that's the way it was before I hacked on it too. Should we consider switching to 64 bits on narrow palinux since this is related to file systems, not CPUs. Note there's also a __kernel_loff_t -> loff_t which appears to be defined as 64 bits. I'm not sure how this does/should interact with off_t (lseek vs lseek64 for example). __kernel_suseconds_t: which becomes suseconds_t which is used in struct timeval { time_t tv_sec; /* seconds */ suseconds_t tv_usec; /* microseconds */ }; I'm confused why hpux, and other systems, like for this to be 'long' (e.g., 64 bits on 64-bit processors) since it seems like values over a million are probably rare and 32 bits seems to be enough for most implementations. sparc64 chose 32 bits for this and I want to do the same for parisc64 because it will reduce the amount of syscall structure repackings. Comments? __kernel_daddr_t: which is used indirectly in struct solaris_x86_vtoc and solaris_x86_slice which *might* be an on-disk data structures (used with CONFIG_SOLARIS_X86_PARTITION). So this needs to be 32 bits if that's the case (definition from sparc) and several archs have it 64 bits! On the other hand, HPUX's man page says 'daddr_t used for disk addresses except in an inode [and partition table I would think] on disk'. So it should probably be the same type as off_t. FYI the only other place it's used is in 'struct mtio' -- used to talk to magnetic tape units. I'm guessing the sparc struct should not be using this type, and that we should define it the same as off_t. Comments? From kailasr@webcash.com Wed, 15 Nov 2000 09:55:09 -0800 Date: Wed, 15 Nov 2000 09:55:09 -0800 From: Kailashnath V Rampure kailasr@webcash.com Subject: [parisc-linux] Boot command Yes Thomas the vmlinux is in /boot of 3rd partition as the other partitions are swap and f0. At 11:48 AM 11/15/00 +0100, Thomas Marteau wrote: >----- Original Message ----- >From: Kailashnath V Rampure >To: Paul Bame >Cc: Grant Grundler ; Matt Taggart >; >Sent: Tuesday, November 14, 2000 11:58 PM >Subject: Re: [parisc-linux] Boot command > > > > I have booted HP A class server through network. On that I have >repartioned > > the system and followed the steps on >http://www.parisc-linux.org/install.html. > > I have used the following command to initialize the hard disk. The kernel >I > > have downloaded is vmlinux-20001018. and cpied it to /mnt/boot/vmlinux > > after mounting /dev/sda3. I have used the following command to initialize > > the HDD. > > > > palo -I -k /boot/vmlinux -b /boot/iplboot \ -c '3/boot/vmlinux TERM=linux > > HOME=/ root=/dev/sda3' \ /dev/sda > >This means that vmlinux must be in /boot in your third partition on your >disk. >Is it true in your case? > > > -------------------------------- > > I get the following error: > > -------------------------------- > > SOFT Boot. > > palo ipl bame@noam Tue oct 31 14:18:02 MST 2000 > > 0/vmlinux 2138614 bytes@ 0x1f78c000 > > 0/palo-cmdline '3/boot/vmlinux TERM=linux HOME=/ root=/dev/sda3' > > /dev/ida1 82 62 1030688 > > /dev/ida2 f0 1030750 24738 > > /dev/ida3 83 1055488 1030750 > > Kernel:partition 3 file /boot/vmlinux > > ext2 block size 1024 > > ext2_mount(partition 3) returns 0 > > ext2_open(/boot/vmlinux) = -1 > > open /boot/vmlinux failed > > ------------------------------------- > > Please suggest. > > > > -------------------------------------------------------------------------- >- > > To unsubscribe: send e-mail to parisc-linux-request@thepuffingroup.com >with > > `unsubscribe' as the subject. > > > > From bame@noam.fc.hp.com Wed, 15 Nov 2000 11:05:14 -0700 Date: Wed, 15 Nov 2000 11:05:14 -0700 From: Paul Bame bame@noam.fc.hp.com Subject: [parisc-linux] Beta CD = How did you get the kernel image into the boot = sector of the CD? I'd like to try to build some CD's of the kernels I'm = building to test in some mahcines that are not on the same network as = the machine that I'm building everything from. The magic for making bootable CDs is documented in the PALO README.html which you have on your system already since you're building kernels. -P From marteaut@esiee.fr Wed, 15 Nov 2000 19:10:56 +0100 Date: Wed, 15 Nov 2000 19:10:56 +0100 From: Thomas Marteau marteaut@esiee.fr Subject: [parisc-linux] Boot command Hi again, You put the swap partition before the f0 partition and here it is the f0 partition in first position. Also, your hard disk is ida instead of sda, what's that ? Bye, ESIEE Team ----- Original Message ----- From: Kailashnath V Rampure To: Thomas Marteau Cc: Sent: Wednesday, November 15, 2000 6:55 PM Subject: Re: [parisc-linux] Boot command > Yes Thomas the vmlinux is in /boot of 3rd partition as the other partitions > are swap and f0. > > At 11:48 AM 11/15/00 +0100, Thomas Marteau wrote: > > >----- Original Message ----- > >From: Kailashnath V Rampure > >To: Paul Bame > >Cc: Grant Grundler ; Matt Taggart > >; > >Sent: Tuesday, November 14, 2000 11:58 PM > >Subject: Re: [parisc-linux] Boot command > > > > > > > I have booted HP A class server through network. On that I have > >repartioned > > > the system and followed the steps on > >http://www.parisc-linux.org/install.html. > > > I have used the following command to initialize the hard disk. The kernel > >I > > > have downloaded is vmlinux-20001018. and cpied it to /mnt/boot/vmlinux > > > after mounting /dev/sda3. I have used the following command to initialize > > > the HDD. > > > > > > palo -I -k /boot/vmlinux -b /boot/iplboot \ -c '3/boot/vmlinux TERM=linux > > > HOME=/ root=/dev/sda3' \ /dev/sda > > > >This means that vmlinux must be in /boot in your third partition on your > >disk. > >Is it true in your case? > > > > > -------------------------------- > > > I get the following error: > > > -------------------------------- > > > SOFT Boot. > > > palo ipl bame@noam Tue oct 31 14:18:02 MST 2000 > > > 0/vmlinux 2138614 bytes@ 0x1f78c000 > > > 0/palo-cmdline '3/boot/vmlinux TERM=linux HOME=/ root=/dev/sda3' > > > /dev/ida1 82 62 1030688 > > > /dev/ida2 f0 1030750 24738 > > > /dev/ida3 83 1055488 1030750 > > > Kernel:partition 3 file /boot/vmlinux > > > ext2 block size 1024 > > > ext2_mount(partition 3) returns 0 > > > ext2_open(/boot/vmlinux) = -1 > > > open /boot/vmlinux failed From dave@hiauly1.hia.nrc.ca Wed, 15 Nov 2000 13:09:49 -0500 (EST) Date: Wed, 15 Nov 2000 13:09:49 -0500 (EST) From: John David Anglin dave@hiauly1.hia.nrc.ca Subject: [parisc-linux] Help with posix_types.h The largest disk currently available I believe is the 180GB Seagate Baracuda. The size of drives is increasing about a factor of 2 per year. The __kernel_off_t definitely needs to be 64 bits to handle large drives in both 32 and 64 bit systems. Disk blocks are typically 512 or 1024 bytes. Thus, drives may exceed 4GB disk blocks in 3-4 years. Inodes are variable in size (8KB average). Thus, we are a little further away from exceeding the 32 bit inode limit. Dave -- J. David Anglin dave.anglin@nrc.ca National Research Council of Canada (613) 990-0752 (FAX: 952-6605) From bame@noam.fc.hp.com Wed, 15 Nov 2000 11:12:57 -0700 Date: Wed, 15 Nov 2000 11:12:57 -0700 From: Paul Bame bame@noam.fc.hp.com Subject: [parisc-linux] Boot command = You put the swap partition before the f0 partition and here it is the f0 = partition in first position. The partition order doesn't matter so long as the f0 partition and the partition containing your kernel (an ext2 partition) *end* within the first 2Gb of the disk. See the PALO README.html. = Also, your hard disk is ida instead of sda, what's that ? PALO lists the devices as 'ida' instead of 'sda' or 'hda' since it is using the firmware 'IODC' interface to talk to the boot device, and it has no idea what type of boot device IODC is providing. -P From rhirst@linuxcare.com Wed, 15 Nov 2000 18:48:08 +0000 Date: Wed, 15 Nov 2000 18:48:08 +0000 From: Richard Hirst rhirst@linuxcare.com Subject: [parisc-linux] Single-stepping (Oops, CC-ed to the wrong list first time!) Hi John, I've been helping Alan Modra out with kernel changes to support single stepping for gdb. Paul Bame suggested I bounced our ideas off you in case you (or anyone else) had any comments. I havn't actually committed my changes yet. The basic approach is to use the recovery counter to generate a trap every instruction. The scheme is complicated because a suspended process may or may not return to user space via an RFI. If it was suspended as a result of an interrupt then we can simply set PSW bit R in the tasks saved registers and it will get loaded by the RFI. On every task switch I set the recovery counter to 0, just in case the new process is being single-stepped. If a process is suspended during a syscall, then there is no RFI on the return path to userland, and we have to handle things differently. I have changed the syscall return path such that it loads the recovery counter with 3 before updating the PSW with a value from the tasks saved registers. If that PSW has the R bit set, then the count of 3 will generate a trap on the first instruction following the branch back to user space. Note that PSW wasn't previously restored on the syscall return path. To avoid further complications of interrupts during the three instructions when the recovery counter is decrementing, whenever we set the R bit, we also clear the I bit to disable interrupts. Nullified instructions are handled by the controlling process manually moving the childs IAOQ over the instruction without actually setting it running, because the recovery counter isn't decremented for nullified instructions. I need to do some more testing before committing this, but would welcome any comments on the basic approach taken, areas I have mis-understood, or problems with it that might not yet have occurred to me. Thanks, Richard From andreas@bawue.de Thu, 16 Nov 2000 20:20:41 +0100 Date: Thu, 16 Nov 2000 20:20:41 +0100 From: Andreas Thienemann andreas@bawue.de Subject: [parisc-linux] 250/1 doesn't boot but dumps stack This is a multi-part message in MIME format. --------------F7EF1B69F0A7C4C7DD54E27D Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hi, I recently got a D-Class HP900 250/1 (at least it says that on the label) and tried to get the pa-risc port running on it. So I got a CVS checkout and build the whole toolchain without any major hassles. The kernel, including NFS-ROOT, built also without any glitches. But when I try to boot up this kernel it dumps stack right after initialising the pty interfaces. (I already left out everything unnecessary, such as parallel port support) After that it complains about "Data acces rights fault in kernel: Code=26 regs=c7f98780 (Addr=000000004)" and some more data... For the curious, the boot sequence is attached. I hope someone can give me a clue what might be wrong... Thanks, Andreas --------------F7EF1B69F0A7C4C7DD54E27D Content-Type: text/plain; charset=us-ascii; name="hp9000-capture" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="hp9000-capture" Firmware Version 36.34 Duplex Console IO Dependent Code (IODC) revision 0 ------------------------------------------------------------------------------ (c) Copyright 1995-1998, Hewlett-Packard Company, All rights reserved ------------------------------------------------------------------------------ Processor Speed State Coprocessor State Cache Size --------- -------- --------------------- ----------------- ---------- 0 101 MHz Active Functional 256 KB Central Bus Speed (in MHz) : 101 Available memory (bytes) : 134217728 Good memory required (bytes): 15245312 Primary boot path: 8/16/5.5 (dec) Alternate boot path: 8/16/5.2 (dec) Console path: 8/16/4.0 (dec) Keyboard path: 8/16/7.0 (dec) Processor is booting from first available device. To discontinue, press any key within 10 seconds. Boot terminated. ------- Main Menu ------------------------------------------------------------- Command Description ------- ----------- BOot [PRI|ALT|] Boot from specified path PAth [PRI|ALT|CON|KEY] [] Display or modify a path SEArch [DIsplay|IPL] [] Search for boot devices COnfiguration [] Access Configuration menu/commands INformation [] Access Information menu/commands SERvice [] Access Service menu/commands DIsplay Redisplay the current menu HElp [|] Display help for menu or command RESET Restart the system ------- Main Menu: Enter command > bo 8/16/6.0 Interact with IPL (Y or N)?> n Booting... Network Station Address 0060b0-3c08d4 Boot IO Dependent Code (IODC) revision 2 HARD Booted. palo ipl root@gate.ixs.com Wed Nov 15 14:08:22 CET 2000 0/vmlinux 2143238 bytes @ 0x6800 0/palo-cmdline '0/vmlinux HOME=/ TERM=LINUX root=/dev/nfs nfsroot=192.168.1.1 ' Kernel: partition 0 file /vmlinux ELF32 executable Entry 00100120 first 00100000 n 4 Segment 0 load 00100000 size 1467884 mediaptr 0x1000 Segment 1 load 00268000 size 174520 mediaptr 0x168000 Segment 2 load 00294000 size 103180 mediaptr 0x193000 Segment 3 load 002b0000 size 8192 mediaptr 0x1ad000 branching to kernel entry point 0x00100120 Set default PSW W bit to 0 PDC Console Initialized The 32-bit Kernel has started... Enabled FP coprocessor Free memory starts at: 0xc02dc000 start_parisc(0x504d6c,0x504d6c,0x0,0x0) PALO command line: 'HOME=/ TERM=LINUX root=/dev/nfs nfsroot=192.168.1.1 ' PALO initrd 0-0 model 00005890 00000481 00000000 00000002 778314c3 100000f0 00000004 0000008a 0000008a vers 0000000d cpuid 0000016d CPUID vers 11 rev 13 Searching for devices in PDC firmware... processor hpa 0xfffa0000 a newer box... Found devices: 1. UL 350 Lasi Core BA (11) at 0xffd00000, versions 0x2e, 0x0, 0x81, 0x0, 0x0 2. UL 350 Lasi Core RS-232 (10) at 0xffd05000, versions 0x2e, 0x0, 0x8c, 0x0, 0x0 3. UL 350 Core SCSI (10) at 0xffd06000, versions 0x2e, 0x0, 0x82, 0x0, 0x80 4. UL 350 Core LAN (802.3) (10) at 0xffd07000, versions 0x2e, 0x0, 0x8a, 0x0, 0x0 5. UL 350 Core Centronics (10) at 0xffd02000, versions 0x2e, 0x0, 0x74, 0x0, 0x0 6. UL 350 Core PC Keyboard (10) at 0xffd08000, versions 0x2e, 0x0, 0x84, 0x0, 0x0 7. UL 350 Core PC Keyboard (10) at 0xffd08100, versions 0x2e, 0x0, 0x84, 0x0, 0x0 8. UL 350 Core PC Floppy (10) at 0xffd0a000, versions 0x2e, 0x0, 0x83, 0x0, 0x0 9. UL 350 Core Wax BA (11) at 0xffe00000, versions 0x30, 0x0, 0x8e, 0x0, 0x0 10. UL 350 Wax EISA BA (11) at 0xfc000000, versions 0x30, 0x0, 0x90, 0x0, 0x0 11. UL 350 Wax Core RS-232 (10) at 0xffe02000, versions 0x30, 0x0, 0x8c, 0x0, 0x0 That's a total of 11 devices. No CPUs reported by firmware - probing... Found CPU at fffa0000 CPU(s): 1 x PA7200 (PCX-T') at 101.000000 MHz Linux version 2.4.0-test10 (root@gate.ixs.com) (gcc version 2.96 20000925 (experimental)) #4 Wed Nov 15 19:06:49 CET 2000 free_bootmem(0x2dd000, 0x7d23000) pagetable_init On node 0 totalpages: 32768 zone(0): 16384 pages. zone(1): 16384 pages. zone(2): 0 pages. Kernel command line: HOME=/ TERM=LINUX root=/dev/nfs nfsroot=192.168.1.1 trap_init Calibrating delay loop... 100.76 BogoMIPS Memory: 125568k available Dentry-cache hash table entries: 16384 (order: 5, 131072 bytes) Buffer-cache hash table entries: 8192 (order: 3, 32768 bytes) Page-cache hash table entries: 32768 (order: 5, 131072 bytes) Inode-cache hash table entries: 8192 (order: 4, 65536 bytes) POSIX conformance testing by UNIFIX Lasi version 0 at 0xffd00000 found. Wax at 0xffe00000 found. Wax: HIL Keyboard-NMI registered. parport0: PC-style at 0xffd02800, irq 88 [PCSPP,TRISTATE] Found i82596 at 0xffd07000, IRQ 87 early initialization of device eth0 is deferred Initializing Lasi PS/2-keyboard port at 0xffd08000... Support for Lasi PS/2-psaux not yet available ! Linux NET4.0 for Linux 2.4 Based upon Swansea University Computer Society NET3.039 Starting kswapd v1.8 pty: 256 Unix98 ptys configured lp0: using parport0 (interrupt-driven). Dumping Stack from c7f98000 to c7f989c0: 8000 00000000 00000040 00000000 00000000 c027c32c 00000000 00000000 ffffffff 8020 00000001 00000000 00000000 00000000 00000000 00000000 ffffffff c027c244 8040 c027c244 00000031 c7f90000 c02b0000 c028160c 00000000 00000000 00000000 8060 00000000 00000000 00000000 00000001 00000000 00000000 00000000 00000000 8080 00000000 c02b0000 c02b0000 c7f84000 00000000 00000000 c7f84098 c02b0098 80a0 00000000 c02cba18 00000000 c7f980ac c7f980ac c7f980b4 c01177f4 c7f98908 80c0 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 80e0 00000000 00000000 c7f98000 c011a5e4 00000000 0000000f 00000000 00000000 8100 00000024 00000000 00000033 00000000 00000000 00000000 00000000 00000000 8120 00000000 80000000 00000000 00000000 00000000 00000000 00000000 00000000 8140 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 8160 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 8180 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 81a0 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 81c0 00000000 00000000 00000000 fffffeff 00000000 ffffffff 00000000 c027ceb8 81e0 ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff 00800000 05000000 8200 00000000 ffffffff ffffffff ffffffff 00000800 00000800 00000400 00000400 8220 ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff 00007377 61707065 8240 72000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 8260 00008000 c0269000 c0269000 c013de10 00010000 c7ffeba0 c022248c c0234898 8280 000000f0 c02db000 00000000 c0118cf0 c0269054 00008000 c0269000 c0269054 82a0 f0000068 f0000070 c027c000 c027c368 0000000b 00000024 0000003c 0000003e 82c0 c027c000 00000000 c01001dc 00000004 00000000 00000023 c02b61ef 00000000 82e0 c027c000 f0000070 f0000068 000000ff ffd05800 ffd05800 ffd05800 00000060 8300 ffffffff ffd05800 002b50c0 c0268000 00000000 00000000 c02b08c0 00000000 8320 000b0800 00000000 0000001f 00000000 0000001f 00000000 0000001f 00000000 8340 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 8360 00000010 00000020 7f7fffff ffffffff 43ebebeb e0000000 00000000 00000000 8380 45e69c6a 25b7ea20 41800000 00000000 00000010 00000010 00000000 00000000 83a0 00000040 00000080 00000100 00000200 00000400 00000800 7fffffff 7fffffff 83c0 41000000 00000000 7fffffff 7fffffff 40800000 00000000 41000000 00000000 83e0 40300000 00000000 40200000 00000000 40200000 00000000 41800000 7fffffff 8400 40000000 00000000 40000000 00000000 40800000 00000000 41000000 00000000 8420 00000000 00000000 c7f98800 c0103cf4 00000000 00000000 00000000 00000000 8440 00000000 00000000 c0118ce0 c0118ce4 40800000 00000000 00282000 00000000 8460 c0281040 c0281064 00000000 c0281204 00000000 00000000 00000000 c7f98478 8480 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 84a0 00000000 00000000 71894dcb e3642ec4 c6c85d89 8d90bb13 1b217627 3634591c 84c0 6c1e076a d84abb86 b095770d 612aee1b c2236964 8446d2c9 088da593 116dfe74 84e0 22ad49ba 452c2626 8a2ef91e c0103c48 28cd5128 51ec1702 a3ae9b56 475d36ad 8500 c7f98000 c028160c 00000000 76fd1fb2 ed8c8a36 db19146d b63228db 6c6451b7 8520 d8be163c b17c2c79 62f858f3 c01001f0 8b0c0969 161812d3 2c4690f4 58fb94ba 8540 b1819c26 6303384d c670c5c8 8ce18b91 19c31723 33f09b14 6797837a cf59b3a6 8560 9eb3674d 3d66ce9b 7abb2864 c0294ef4 ea01cb35 d403966b a8072cd7 500e59af 8580 00000000 c02b0000 81dead60 03bd5ac1 00000060 c027c35c c027c35c c025920c 85a0 7234ad2e e41fef0e c83fde1d c0294ea0 20ff7877 418845bc 83663e2a 06cc7c55 85c0 c02ad30c c02ad2cc 00000000 00000000 00000000 c7f985d4 c7f985d4 c7f985dc 85e0 c7f985dc c7f985e4 00000000 c0298ca0 00000000 c7f985d4 c7f985d4 c7f985dc 8600 c027e800 00000000 00000000 00000000 000000fa 000000f2 000000ff c0295514 8620 000000f0 c02cb800 c02b06c0 c0299814 c028160c c02ad30c c02ad2bc c028160c 8640 c02b06c0 c7f98000 c028160c c02ad30c c02ad2d0 c7f94800 c0230add 0000003e 8660 c027c000 00000001 c02b6206 c0299744 c02b61ce 00000037 c02b6206 00000000 8680 c02ad30c c02ad2d0 00000040 c02cb800 000000fa 000000f2 000000ff c0295514 86a0 000000f0 c02cb800 c02b06c0 c02a4af4 c028160c c02ad30c c02ad2d0 c7f98000 86c0 c028b800 c01e2468 ffffffff c028b1e4 c7ffc400 c028160c c024256c c0186688 86e0 c028160c c02c6104 c01e2468 c029c4e0 c028b310 c028b1b4 c7f988c0 00000000 8700 ffffffff 0000ffe0 0060b03c 08d4bcfc 00000000 00000008 c0295514 000000f0 8720 c02cb800 c028b800 c01e2468 ffffffff c028b1e4 c7ffc400 c02bfc1c c02bfe50 8740 00000063 00000008 c7f98718 c024256c 00000000 c0285038 c028b1b9 c0242340 8760 45e69c6a 25b7ea20 41800000 c029c248 00000010 00000010 00000000 00000000 8780 0004000b c02ca800 c029c248 00000000 c7ffc400 ffffffff c01e2468 c028b800 87a0 c02cb800 000000f0 00000000 000000ff 000000f2 000000fa 000000fd f0100000 87c0 f0001180 f0000070 f0000068 00000000 c7f9870e 00000002 c029c4d0 ffd07000 87e0 c7f98710 00000f20 00000000 c0268000 00000001 00000000 c7f989c0 002b31b8 8800 000b0800 00000000 0000001f 00000000 0000001f 00000000 0000001f 00000000 8820 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 8840 00000010 00000020 7f7fffff ffffffff 43ebebeb e0000000 00000000 00000000 8860 45e69c6a 25b7ea20 41800000 00000000 00000010 00000010 00000000 00000000 8880 00000040 00000080 00000100 00000200 00000400 00000800 7fffffff 7fffffff 88a0 41000000 00000000 7fffffff 7fffffff 40800000 00000000 41000000 00000000 88c0 40300000 00000000 40200000 00000000 40200000 00000000 41800000 7fffffff 88e0 40000000 00000000 40000000 00000000 40800000 00000000 41000000 00000000 8900 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 8920 00000000 00000000 c029c264 c029c268 00000000 00000000 c7f98b00 00000000 8940 00000000 00000000 0000001f 00000000 0000001f 0e681096 00000000 00000004 8960 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 8980 00000010 00000020 7f7fffff ffffffff 43ebebeb e0000000 00000000 00000000 89a0 45e69c6a 25b7ea20 41800000 c01046e0 00000010 00000010 00000000 00000000 Data access rights fault in kernel: Code=26 regs=c7f98780 (Addr=00000004) YZrvWESTHLNXBCVMcbcbcbcbOGFRQPDI PSW: 00000000000001000000000000001011 r0-3 00000000 c02ca800 c029c248 00000000 r4-7 c7ffc400 ffffffff c01e2468 c028b800 r8-11 c02cb800 000000f0 00000000 000000ff r12-15 000000f2 000000fa 000000fd f0100000 r16-19 f0001180 f0000070 f0000068 00000000 r20-23 c7f9870e 00000002 c029c4d0 ffd07000 r24-27 c7f98710 00000f20 00000000 c0268000 r28-31 00000001 00000000 c7f989c0 002b31b8 sr0-4 00000000 00000000 00000000 00000000 sr4-8 00000000 00000000 00000000 00000000 IASQ: 00000000 00000000 IAOQ: c029c264 c029c268 IIR: 0e681096 ISR: 00000000 IOR: 00000004 ORIG_R28: 00000000 --------------F7EF1B69F0A7C4C7DD54E27D-- From ixs@ixs.bb.bawue.de Wed, 15 Nov 2000 20:28:28 +0100 (CET) Date: Wed, 15 Nov 2000 20:28:28 +0100 (CET) From: Andreas Thienemann ixs@ixs.bb.bawue.de Subject: [parisc-linux] 250/1 doesn't boot but dumps stack Hi again, just to clear something up: On Thu, 16 Nov 2000, Andreas Thienemann wrote: > the pty interfaces. (I already left out everything unnecessary, such as > parallel port support) I just noticed I attached the wrong file. The attached bootlog was from a kernel that still had support for lp0. But with another kernel, this time without lp support, this errors were the same... bye, Andreas From kailasr@webcash.com Wed, 15 Nov 2000 11:26:30 -0800 Date: Wed, 15 Nov 2000 11:26:30 -0800 From: Kailashnath V Rampure kailasr@webcash.com Subject: [parisc-linux] Boot command Thomas, I mounted the /dev/sda3 on mnt and deleted every thing and recopied then rebooted. It worked. Probably there was some fault while I copied yesterday. I did not repartition the disk now. Thanks Regards Kailas At 07:10 PM 11/15/00 +0100, Thomas Marteau wrote: >Hi again, > > You put the swap partition before the f0 partition and here it is the f0 >partition in first position. > Also, your hard disk is ida instead of sda, what's that ? > >Bye, > >ESIEE Team >----- Original Message ----- >From: Kailashnath V Rampure >To: Thomas Marteau >Cc: >Sent: Wednesday, November 15, 2000 6:55 PM >Subject: Re: [parisc-linux] Boot command > > > > Yes Thomas the vmlinux is in /boot of 3rd partition as the other >partitions > > are swap and f0. > > > > At 11:48 AM 11/15/00 +0100, Thomas Marteau wrote: > > > > >----- Original Message ----- > > >From: Kailashnath V Rampure > > >To: Paul Bame > > >Cc: Grant Grundler ; Matt Taggart > > >; > > >Sent: Tuesday, November 14, 2000 11:58 PM > > >Subject: Re: [parisc-linux] Boot command > > > > > > > > > > I have booted HP A class server through network. On that I have > > >repartioned > > > > the system and followed the steps on > > >http://www.parisc-linux.org/install.html. > > > > I have used the following command to initialize the hard disk. The >kernel > > >I > > > > have downloaded is vmlinux-20001018. and cpied it to /mnt/boot/vmlinux > > > > after mounting /dev/sda3. I have used the following command to >initialize > > > > the HDD. > > > > > > > > palo -I -k /boot/vmlinux -b /boot/iplboot \ -c '3/boot/vmlinux >TERM=linux > > > > HOME=/ root=/dev/sda3' \ /dev/sda > > > > > >This means that vmlinux must be in /boot in your third partition on your > > >disk. > > >Is it true in your case? > > > > > > > -------------------------------- > > > > I get the following error: > > > > -------------------------------- > > > > SOFT Boot. > > > > palo ipl bame@noam Tue oct 31 14:18:02 MST 2000 > > > > 0/vmlinux 2138614 bytes@ 0x1f78c000 > > > > 0/palo-cmdline '3/boot/vmlinux TERM=linux HOME=/ root=/dev/sda3' > > > > /dev/ida1 82 62 1030688 > > > > /dev/ida2 f0 1030750 24738 > > > > /dev/ida3 83 1055488 1030750 > > > > Kernel:partition 3 file /boot/vmlinux > > > > ext2 block size 1024 > > > > ext2_mount(partition 3) returns 0 > > > > ext2_open(/boot/vmlinux) = -1 > > > > open /boot/vmlinux failed From bame@noam.fc.hp.com Wed, 15 Nov 2000 12:34:48 -0700 Date: Wed, 15 Nov 2000 12:34:48 -0700 From: Paul Bame bame@noam.fc.hp.com Subject: [parisc-linux] Help with posix_types.h FYI I just heard some pretty good reasons why both ino_t and off_t should be 64 bits even on 32-bit kernels. Keep those cards and letters coming! -P From grundler@cup.hp.com Wed, 15 Nov 2000 11:23:41 -0800 Date: Wed, 15 Nov 2000 11:23:41 -0800 From: Grant Grundler grundler@cup.hp.com Subject: [parisc-linux] 250/1 doesn't boot but dumps stack Andreas Thienemann wrote: > But when I try to boot up this kernel it dumps stack right after initialising > the pty interfaces. (I already left out everything unnecessary, such as > parallel port support) ... > parport0: PC-style at 0xffd02800, irq 88 [PCSPP,TRISTATE] > Found i82596 at 0xffd07000, IRQ 87 > early initialization of device eth0 is deferred > Initializing Lasi PS/2-keyboard port at 0xffd08000... > Support for Lasi PS/2-psaux not yet available ! > Linux NET4.0 for Linux 2.4 > Based upon Swansea University Computer Society NET3.039 > Starting kswapd v1.8 > pty: 256 Unix98 ptys configured > lp0: using parport0 (interrupt-driven). Are you sure you left out parallel port support? > Data access rights fault in kernel: Code=26 regs=c7f98780 (Addr=00000004) > > YZrvWESTHLNXBCVMcbcbcbcbOGFRQPDI > PSW: 00000000000001000000000000001011 > r0-3 00000000 c02ca800 c029c248 00000000 > r4-7 c7ffc400 ffffffff c01e2468 c028b800 > r8-11 c02cb800 000000f0 00000000 000000ff > r12-15 000000f2 000000fa 000000fd f0100000 > r16-19 f0001180 f0000070 f0000068 00000000 > r20-23 c7f9870e 00000002 c029c4d0 ffd07000 > r24-27 c7f98710 00000f20 00000000 c0268000 > r28-31 00000001 00000000 c7f989c0 002b31b8 > sr0-4 00000000 00000000 00000000 00000000 > sr4-8 00000000 00000000 00000000 00000000 > > IASQ: 00000000 00000000 IAOQ: c029c264 c029c268 > IIR: 0e681096 ISR: 00000000 IOR: 00000004 > ORIG_R28: 00000000 Smells like a driver bug. Can you look up IOAQ and GR2 (c029c264 and c029c248) in System.map file? grant From dave@hiauly1.hia.nrc.ca Wed, 15 Nov 2000 14:49:02 -0500 (EST) Date: Wed, 15 Nov 2000 14:49:02 -0500 (EST) From: John David Anglin dave@hiauly1.hia.nrc.ca Subject: [parisc-linux] Single-stepping > I've been helping Alan Modra out with kernel changes to support > single stepping for gdb. Paul Bame suggested I bounced our ideas > off you in case you (or anyone else) had any comments. I havn't > actually committed my changes yet. > > The basic approach is to use the recovery counter to generate > a trap every instruction. The scheme is complicated because a > suspended process may or may not return to user space via an RFI. I really don't know enough to comment on the implementation choice. Why did you decide on this approach as opposed to inserting breaks and enabling the taken branch branch trap (T)? It would appear that the recovery counter was intended to provide software recovery from hardware faults in fault tolerant systems. Possibly, Grant could comment on whether it is actually useful for this purpose. Dave -- J. David Anglin dave.anglin@nrc.ca National Research Council of Canada (613) 990-0752 (FAX: 952-6605) From j-perdue@tamu.edu Wed, 15 Nov 2000 13:53:03 -0600 Date: Wed, 15 Nov 2000 13:53:03 -0600 From: Jack Perdue j-perdue@tamu.edu Subject: [parisc-linux] nfsroot - 712/60 - RPC - help Howdy Puffins and others, I have a 712/60 here that I bought for the purpose of playing with PARISC linux. It came w/HP-UX 9.0 which I don't want to wax just yet (e.g. for ioscan and other HP-UX utils). I don't have a CD for it, so I've been trying to get NFSROOT to work. The 712/60 is known as pancho. The bootp server is named blacktower. I've unzipped nfsroot-20000804.tgz as /tftpboot/pancho and exported it to the local net. I can mount it from an i386 RH6.2 box, but I think I'm having problems accessing it from PA-RISC linux. Below are some of my config files, the output from bootp and two attempts at booting the 712/60... one with debugging turned on in net/sunrpc/sysctl.c. I'm kinda stumped. Can anyone see where I've gone wrong? Some notes: a) I've tried NFSROOT=192.168.1.11 and NFSROOT=192.168.1.11/tftpboot/vmlinux in palo/Makefile and the results are the same (both suggestions were made to this list at some point) b) I tried the APRICOT drivers, but the kernel would never see the net interface so I've switched to the LASI_82596 driver (doing both resulted in dupe symbols). The LASI driver seems to get much further. c) my sources were updated today from the puffin's CVS tree. The kernel booting below was built on those sources. d) with debugging on, I get: Root-NFS: Unable to get nfsd port number from server, using default Root-NFS: Portmapper on server returned 2049 as nfsd port however, with the debugging off, I only get: Root-NFS: Unable to get nfsd port number from server, using default portmap and rpc.mountd are running on blacktower. Why the conflicting report when debug is on? e) the final message in /var/log/messages is always "tftpd: read: Connection refused". My hosts.allow and hosts.deny files are empty so they shouldn't be the problem. And, as mentioned I can NFS mount the directory. Is this the problem and if so, what is the solution??? Any help on how I can resolve this problem is appreciated. TIA, jack j-perdue@tamu.edu ========== blacktower:/etc/exports ========== /tftpboot/pancho 192.168.1.0/255.255.255.0(rw,no_root_squash) ========== blacktower:/etc/bootptab ========== pancho:\ :hd=/tftpboot:\ :bf=vmlinux:\ :ht=ether:\ :ha=08000993DA02:\ :sm=255.255.255.0:\ :hn:\ :ip=192.168.1.13:\ :vm=rfc1048: ========== bootpd output ========== [root@blacktower rc.d]# /usr/sbin/bootpd -d 20 bootpd: info(6): bootptab mtime: Wed Nov 15 13:02:44 2000 bootpd: info(6): reading "/etc/bootptab" bootpd: info(6): read 1 entries (1 hosts) from "/etc/bootptab" bootpd: info(6): recvd pkt from IP addr 0.0.0.0 bootpd: info(6): bootptab mtime: Wed Nov 15 13:02:44 2000 bootpd: info(6): request from Ethernet address 08:00:09:93:DA:02 bootpd: info(6): found 192.168.1.13 (pancho) bootpd: info(6): bootfile="/tftpboot/vmlinux" bootpd: info(6): vendor magic field is 99.130.83.99 bootpd: info(6): sending reply (with RFC1048 options) bootpd: info(6): setarp 192.168.1.13 - 08:00:09:93:DA:02 bootpd: info(6): recvd pkt from IP addr 0.0.0.0 bootpd: info(6): bootptab mtime: Wed Nov 15 13:02:44 2000 bootpd: info(6): request from Ethernet address 08:00:09:93:DA:02 bootpd: info(6): found 192.168.1.13 (pancho) bootpd: info(6): bootfile="/tftpboot/vmlinux" bootpd: info(6): vendor magic field is 99.130.83.99 bootpd: info(6): request message length=364 bootpd: info(6): extended reply, length=364, options=128 bootpd: info(6): sending reply (with RFC1048 options) bootpd: info(6): setarp 192.168.1.13 - 08:00:09:93:DA:02 ========== from /var/log/messages ========== Nov 15 13:02:20 blacktower bootpd[1320]: version 2.4.3 Nov 15 13:02:20 blacktower bootpd[1320]: bootptab mtime: Wed Oct 12 00:41:28 1994 Nov 15 13:02:20 blacktower bootpd[1320]: reading "/etc/bootptab" Nov 15 13:02:20 blacktower bootpd[1320]: read 1 entries (1 hosts) from "/etc/bootptab" Nov 15 13:02:47 blacktower bootpd[1323]: version 2.4.3 Nov 15 13:02:47 blacktower bootpd[1323]: bootptab mtime: Wed Nov 15 13:02:44 2000 Nov 15 13:02:47 blacktower bootpd[1323]: reading "/etc/bootptab" Nov 15 13:02:47 blacktower bootpd[1323]: read 1 entries (1 hosts) from "/etc/bootptab" Nov 15 13:04:34 blacktower bootpd[1323]: recvd pkt from IP addr 0.0.0.0 Nov 15 13:04:34 blacktower bootpd[1323]: bootptab mtime: Wed Nov 15 13:02:44 2000 Nov 15 13:04:34 blacktower bootpd[1323]: request from Ethernet address 08:00:09:93:DA:02 Nov 15 13:04:34 blacktower bootpd[1323]: found 192.168.1.13 (pancho) Nov 15 13:04:34 blacktower bootpd[1323]: bootfile="/tftpboot/vmlinux" Nov 15 13:04:34 blacktower bootpd[1323]: vendor magic field is 99.130.83.99 Nov 15 13:04:34 blacktower bootpd[1323]: sending reply (with RFC1048 options) Nov 15 13:04:34 blacktower bootpd[1323]: setarp 192.168.1.13 - 08:00:09:93:DA:02 Nov 15 13:04:35 blacktower tftpd[1325]: tftpd: trying to get file: /tftpboot/vmlinux Nov 15 13:04:36 blacktower tftpd[1327]: tftpd: trying to get file: /tftpboot/vmlinux Nov 15 13:04:47 blacktower bootpd[1323]: recvd pkt from IP addr 0.0.0.0 Nov 15 13:04:47 blacktower bootpd[1323]: bootptab mtime: Wed Nov 15 13:02:44 2000 Nov 15 13:04:47 blacktower bootpd[1323]: request from Ethernet address 08:00:09:93:DA:02 Nov 15 13:04:47 blacktower bootpd[1323]: found 192.168.1.13 (pancho) Nov 15 13:04:47 blacktower bootpd[1323]: bootfile="/tftpboot/vmlinux" Nov 15 13:04:47 blacktower bootpd[1323]: vendor magic field is 99.130.83.99 Nov 15 13:04:47 blacktower bootpd[1323]: request message length=364 Nov 15 13:04:47 blacktower bootpd[1323]: extended reply, length=364, options=128 Nov 15 13:04:47 blacktower bootpd[1323]: sending reply (with RFC1048 options) Nov 15 13:04:47 blacktower bootpd[1323]: setarp 192.168.1.13 - 08:00:09:93:DA:02 Nov 15 13:04:53 blacktower tftpd[1327]: tftpd: read: Connection refused ========== console output (no RPC debug) ========== ---------------------------------------------------------------------------- BootRom Version 1.5 Memory Size: 32 MB ---------------------------------------------------------------------------- (c) Copyright 1990-1993, Hewlett-Packard Company. All rights reserved Press to stop boot sequence. Selecting a system to boot. Booting palo ipl jkp2866@redtower Wed Nov 15 12:44:21 CST 2000 0/vmlinux 1606438 bytes @ 0x6800 0/palo-cmdline '0/vmlinux HOME=/ TERM=LINUX root=/dev/nfs nfsroot=192.68.1.11:/tftpboot/pancho ' Kernel: partition 0 file /vmlinux ELF32 executable Entry 00100000 first 00100000 n 4 Segment 0 load 00100000 size 1097900 mediaptr 0x1000 Segment 1 load 0020e000 size 150520 mediaptr 0x10e000 Segment 2 load 00234000 size 55900 mediaptr 0x133000 Segment 3 load 00244000 size 8192 mediaptr 0x141000 branching to kernel entry point 0x00100000 Set default PSW W bit to 0 PDC Console Initialized The 32-bit Kernel has started... Enabled FP coprocessor Free memory starts at: 0xc026e000 start_parisc(0x504d6c,0x504d6c,0x0,0x0) PALO command line: 'HOME=/ TERM=LINUX root=/dev/nfs nfsroot=192.68.1.11:/tftpboot/pancho ' PALO initrd 0-0 model 00006000 00000481 00000000 00000000 77564139 00000000 00000004 00000072 00000072 vers 0000000a CPUID vers 0 rev 0 Searching for devices in PDC firmware... processor hpa 0xfffbe000 an older box... Found devices: 1. Gecko GSC Core Graphics (10) at 0xf8000000, versions 0x16, 0x0, 0x85, 0x0, 0x0 2. Gecko Core BA (11) at 0xf0100000, versions 0x16, 0x0, 0x81, 0x0, 0x0 3. Gecko Core SCSI (10) at 0xf0106000, versions 0x16, 0x0, 0x82, 0x0, 0x0 4. Gecko Core Lan (802.3) (10) at 0xf0107000, versions 0x16, 0x0, 0x8a, 0x0, 0x0 5. Gecko Core RS-232 (10) at 0xf0105000, versions 0x16, 0x0, 0x8c, 0x0, 0x0 6. Gecko Core Centronics (10) at 0xf0102000, versions 0x16, 0x0, 0x74, 0x0, 0x0 7. Gecko Audio (10) at 0xf0104000, versions 0x16, 0x0, 0x7b, 0x0, 0x0 8. Gecko Core PC Floppy (10) at 0xf010a000, versions 0x16, 0x0, 0x83, 0x0, 0x0 9. Gecko Core PC Keyboard (10) at 0xf0108000, versions 0x16, 0x0, 0x84, 0x0, 0x0 10. Gecko Core PC Keyboard (10) at 0xf0108100, versions 0x16, 0x0, 0x84, 0x0, 0x0 11. Gecko (712/60) (0) at 0xfffbe000, versions 0x600, 0x0, 0x4, 0x0, 0x81 12. Gecko (1) at 0xfffbf000, versions 0x26, 0x0, 0x9, 0x0, 0x0 That's a total of 12 devices. CPU(s): 1 x PA7100LC (PCX-L) at 60.000000 MHz Linux version 2.4.0-test10 (jkp2866@redtower) (gcc version 2.96 20000925 (experimental)) #16 Wed Nov 15 14:01:38 CST 2000 free_bootmem(0x26e400, 0x1d91c00) pagetable_init On node 0 totalpages: 8192 zone(0): 4096 pages. zone(1): 4096 pages. zone(2): 0 pages. Kernel command line: HOME=/ TERM=LINUX root=/dev/nfs nfsroot=192.68.1.11:/tftpboot/pancho trap_init Calibrating delay loop... 59.80 BogoMIPS Memory: 29632k available Dentry-cache hash table entries: 4096 (order: 3, 32768 bytes) Buffer-cache hash table entries: 1024 (order: 0, 4096 bytes) Page-cache hash table entries: 8192 (order: 3, 32768 bytes) Inode-cache hash table entries: 2048 (order: 2, 16384 bytes) POSIX conformance testing by UNIFIX Lasi version 0 at 0xf0100000 found. Found i82596 at 0xf0107000, IRQ 87 early initialization of device eth0 is deferred Linux NET4.0 for Linux 2.4 Based upon Swansea University Computer Society NET3.039 Starting kswapd v1.8 pty: 256 Unix98 ptys configured eth0: 82596 at 0xf0107000, 08 00 09 93 DA 02 IRQ 87. 82596.c $Revision: 1.14 $ Serial driver version 5.02 (2000-08-09) with MANY_PORTS SHARE_IRQ SERIAL_PCI enabled ttyS00 at iomem 0xf0105800 (irq = 90) is a 16550A NET4: Linux TCP/IP 1.0 for NET4.0 IP Protocols: ICMP, UDP, TCP IP: routing cache hash table of 512 buckets, 4Kbytes TCP: Hash tables configured (established 2048 bind 2048) eth0: link ok. Sending BOOTP requests.... OK IP-Config: Got BOOTP answer from 192.168.1.11, my address is 192.168.1.13 Switching from PDC console kmem_create: Forcing size word alignment - nfs_fh Looking up port of RPC 100003/2 on 192.68.1.11 RPC: sendmsg returned error 229 portmap: RPC call returned error 229 Root-NFS: Unable to get nfsd port number from server, using default Looking up port of RPC 100005/2 on 192.68.1.11 RPC: sendmsg returned error 229 portmap: RPC call returned error 229 Root-NFS: Unable to get mountd port number from server, using default RPC: sendmsg returned error 229 mount: RPC call returned error 229 Root-NFS: Server returned error -229 while mounting /tftpboot/pancho VFS: Unable to mount root fs via NFS, trying floppy. VFS: Cannot open root device "nfs" or 02:00 Please append a correct "root=" boot option Kernel panic: VFS: Unable to mount root fs on 02:00 ========== console output (with RPC debug) ========== ---------------------------------------------------------------------------- BootRom Version 1.5 Memory Size: 32 MB ---------------------------------------------------------------------------- (c) Copyright 1990-1993, Hewlett-Packard Company. All rights reserved Press to stop boot sequence. Selecting a system to boot. Booting palo ipl jkp2866@redtower Wed Nov 15 12:44:21 CST 2000 0/vmlinux 1606438 bytes @ 0x6800 0/palo-cmdline '0/vmlinux HOME=/ TERM=LINUX root=/dev/nfs nfsroot=192.68.1.11:/tftpboot/pancho ' Kernel: partition 0 file /vmlinux ELF32 executable Entry 00100000 first 00100000 n 4 Segment 0 load 00100000 size 1097900 mediaptr 0x1000 Segment 1 load 0020e000 size 150520 mediaptr 0x10e000 Segment 2 load 00234000 size 55900 mediaptr 0x133000 Segment 3 load 00244000 size 8192 mediaptr 0x141000 branching to kernel entry point 0x00100000 Set default PSW W bit to 0 PDC Console Initialized The 32-bit Kernel has started... Enabled FP coprocessor Free memory starts at: 0xc026e000 start_parisc(0x504d6c,0x504d6c,0x0,0x0) PALO command line: 'HOME=/ TERM=LINUX root=/dev/nfs nfsroot=192.68.1.11:/tftpboot/pancho ' PALO initrd 0-0 model 00006000 00000481 00000000 00000000 77564139 00000000 00000004 00000072 00000072 vers 0000000a CPUID vers 0 rev 0 Searching for devices in PDC firmware... processor hpa 0xfffbe000 an older box... Found devices: 1. Gecko GSC Core Graphics (10) at 0xf8000000, versions 0x16, 0x0, 0x85, 0x0, 0x0 2. Gecko Core BA (11) at 0xf0100000, versions 0x16, 0x0, 0x81, 0x0, 0x0 3. Gecko Core SCSI (10) at 0xf0106000, versions 0x16, 0x0, 0x82, 0x0, 0x0 4. Gecko Core Lan (802.3) (10) at 0xf0107000, versions 0x16, 0x0, 0x8a, 0x0, 0x0 5. Gecko Core RS-232 (10) at 0xf0105000, versions 0x16, 0x0, 0x8c, 0x0, 0x0 6. Gecko Core Centronics (10) at 0xf0102000, versions 0x16, 0x0, 0x74, 0x0, 0x0 7. Gecko Audio (10) at 0xf0104000, versions 0x16, 0x0, 0x7b, 0x0, 0x0 8. Gecko Core PC Floppy (10) at 0xf010a000, versions 0x16, 0x0, 0x83, 0x0, 0x0 9. Gecko Core PC Keyboard (10) at 0xf0108000, versions 0x16, 0x0, 0x84, 0x0, 0x0 10. Gecko Core PC Keyboard (10) at 0xf0108100, versions 0x16, 0x0, 0x84, 0x0, 0x0 11. Gecko (712/60) (0) at 0xfffbe000, versions 0x600, 0x0, 0x4, 0x0, 0x81 12. Gecko (1) at 0xfffbf000, versions 0x26, 0x0, 0x9, 0x0, 0x0 That's a total of 12 devices. CPU(s): 1 x PA7100LC (PCX-L) at 60.000000 MHz Linux version 2.4.0-test10 (jkp2866@redtower) (gcc version 2.96 20000925 (experimental)) #15 Wed Nov 15 13:48:41 CST 2000 free_bootmem(0x26e400, 0x1d91c00) pagetable_init On node 0 totalpages: 8192 zone(0): 4096 pages. zone(1): 4096 pages. zone(2): 0 pages. Kernel command line: HOME=/ TERM=LINUX root=/dev/nfs nfsroot=192.68.1.11:/tftpboot/pancho trap_init Calibrating delay loop... 59.80 BogoMIPS Memory: 29632k available Dentry-cache hash table entries: 4096 (order: 3, 32768 bytes) Buffer-cache hash table entries: 1024 (order: 0, 4096 bytes) Page-cache hash table entries: 8192 (order: 3, 32768 bytes) Inode-cache hash table entries: 2048 (order: 2, 16384 bytes) POSIX conformance testing by UNIFIX Lasi version 0 at 0xf0100000 found. Found i82596 at 0xf0107000, IRQ 87 early initialization of device eth0 is deferred Linux NET4.0 for Linux 2.4 Based upon Swansea University Computer Society NET3.039 Starting kswapd v1.8 pty: 256 Unix98 ptys configured eth0: 82596 at 0xf0107000, 08 00 09 93 DA 02 IRQ 87. 82596.c $Revision: 1.14 $ Serial driver version 5.02 (2000-08-09) with MANY_PORTS SHARE_IRQ SERIAL_PCI enabled ttyS00 at iomem 0xf0105800 (irq = 90) is a 16550A NET4: Linux TCP/IP 1.0 for NET4.0 IP Protocols: ICMP, UDP, TCP IP: routing cache hash table of 512 buckets, 4Kbytes TCP: Hash tables configured (established 2048 bind 2048) eth0: link ok. Sending BOOTP requests.... OK IP-Config: Got BOOTP answer from 192.168.1.11, my address is 192.168.1.13 Switching from PDC console kmem_create: Forcing size word alignment - nfs_fh RPC: registering /proc/net/rpc RPC: registering /proc/net/rpc/nfs Looking up port of RPC 100003/2 on 192.68.1.11 RPC: rpc_getport_external(192.68.1.11, 100003, 2, 17) RPC: xprt_create_proto called RPC: xprt_create_socket(udp 17) RPC: setting up UDP transport... RPC: created transport c1fa4000 RPC: creating portmap client for 192.68.1.11 (xprt c1fa4000) RPC: allocated buffer c1faa5a0 RPC: creating NULL authenticator for client c1faa5a0 RPC: allocated buffer c1fe6460 RPC: 0 new task procpid 1 RPC: 0 looking up NULL cred RPC: allocated buffer c1fe5500 RPC: 0 rpc_execute flgs 0 RPC: 0 call_reserve RPC: 0 xprt_reserve cong = 0 cwnd = 256 RPC: 0 reserved req c1fa4064 xid 11582000 RPC: 0 xprt_reserve returns 0 RPC: 0 call_reserveresult (status 0) RPC: 0 call_allocate (status 0) RPC: allocated buffer c1fb3800 RPC: 0 call_encode (status 0) RPC: 0 marshaling NULL cred c1fe5500 RPC: xdr_encode_mapping(100003, 2, 17, 0) RPC: 0 call_transmit (status 0) RPC: 0 xprt_transmit(11582000) RPC: 0 xprt_receive RPC: 0 sleep_on(queue "xprt_pending" time 89) RPC: 0 added to queue c1fa4048 "xprt_pending" RPC: xprt_sendmsg(56) = -229 RPC: sendmsg returned error 229 RPC: 0 __rpc_wake_up_task (now 93 inh 0) RPC: 0 disabling timer RPC: 0 removed from queue c1fa4048 "xprt_pending" RPC: __rpc_wake_up_task done RPC: wake_up_next(c1fa4040 "xprt_sending") RPC: 0 call_status (status -229) portmap: RPC call returned error 229 RPC: 0 exit() = -229 RPC: 0 release task RPC: 0 disabling timer RPC: 0 release request c1fa4064 RPC: wake_up_next(c1fa4050 "xprt_backlog") RPC: 0 releasing NULL cred c1fe5500 RPC: rpc_release_client(c1faa5a0, 1) RPC: destroying portmap client for 192.68.1.11 RPC: destroying NULL authenticator c1fe6460 RPC: destroying transport c1fa4000 RPC: disconnected transport c1fa4000 Root-NFS: Unable to get nfsd port number from server, using default Root-NFS: Portmapper on server returned 2049 as nfsd port Looking up port of RPC 100005/2 on 192.68.1.11 RPC: rpc_getport_external(192.68.1.11, 100005, 2, 17) RPC: xprt_create_proto called RPC: xprt_create_socket(udp 17) RPC: setting up UDP transport... RPC: created transport c1fa4000 RPC: creating portmap client for 192.68.1.11 (xprt c1fa4000) RPC: allocated buffer c1faa5a0 RPC: creating NULL authenticator for client c1faa5a0 RPC: allocated buffer c1fe6460 RPC: 1 new task procpid 1 RPC: 1 looking up NULL cred RPC: allocated buffer c1fe5500 RPC: 1 rpc_execute flgs 0 RPC: 1 call_reserve RPC: 1 xprt_reserve cong = 0 cwnd = 256 RPC: 1 reserved req c1fa4064 xid 11582001 RPC: 1 xprt_reserve returns 0 RPC: 1 call_reserveresult (status 0) RPC: 1 call_allocate (status 0) RPC: allocated buffer c1fb3800 RPC: 1 call_encode (status 0) RPC: 1 marshaling NULL cred c1fe5500 RPC: xdr_encode_mapping(100005, 2, 17, 0) RPC: 1 call_transmit (status 0) RPC: 1 xprt_transmit(11582001) RPC: 1 xprt_receive RPC: 1 sleep_on(queue "xprt_pending" time 140) RPC: 1 added to queue c1fa4048 "xprt_pending" RPC: xprt_sendmsg(56) = -229 RPC: sendmsg returned error 229 RPC: 1 __rpc_wake_up_task (now 144 inh 0) RPC: 1 disabling timer RPC: 1 removed from queue c1fa4048 "xprt_pending" RPC: __rpc_wake_up_task done RPC: wake_up_next(c1fa4040 "xprt_sending") RPC: 1 call_status (status -229) portmap: RPC call returned error 229 RPC: 1 exit() = -229 RPC: 1 release task RPC: 1 disabling timer RPC: 1 release request c1fa4064 RPC: wake_up_next(c1fa4050 "xprt_backlog") RPC: 1 releasing NULL cred c1fe5500 RPC: rpc_release_client(c1faa5a0, 1) RPC: destroying portmap client for 192.68.1.11 RPC: destroying NULL authenticator c1fe6460 RPC: destroying transport c1fa4000 RPC: disconnected transport c1fa4000 Root-NFS: Unable to get mountd port number from server, using default Root-NFS: mountd port is 627 NFS: nfs_mount(c044010b:/tftpboot/pancho) RPC: xprt_create_proto called RPC: xprt_create_socket(udp 17) RPC: setting up UDP transport... RPC: created transport c1fa4000 RPC: creating mount client for 192.68.1.11 (xprt c1fa4000) RPC: allocated buffer c1faa5a0 RPC: creating NULL authenticator for client c1faa5a0 RPC: allocated buffer c1fe6460 RPC: 2 new task procpid 1 RPC: 2 looking up NULL cred RPC: allocated buffer c1fe5500 RPC: 2 rpc_execute flgs 0 RPC: 2 call_reserve RPC: 2 xprt_reserve cong = 0 cwnd = 256 RPC: 2 reserved req c1fa4064 xid 11582002 RPC: 2 xprt_reserve returns 0 RPC: 2 call_reserveresult (status 0) RPC: 2 call_allocate (status 0) RPC: allocated buffer c1fa3000 RPC: 2 call_encode (status 0) RPC: 2 marshaling NULL cred c1fe5500 RPC: 2 call_transmit (status 0) RPC: 2 xprt_transmit(11582002) RPC: 2 xprt_receive RPC: 2 sleep_on(queue "xprt_pending" time 189) RPC: 2 added to queue c1fa4048 "xprt_pending" RPC: xprt_sendmsg(60) = -229 RPC: sendmsg returned error 229 RPC: 2 __rpc_wake_up_task (now 193 inh 0) RPC: 2 disabling timer RPC: 2 removed from queue c1fa4048 "xprt_pending" RPC: __rpc_wake_up_task done RPC: wake_up_next(c1fa4040 "xprt_sending") RPC: 2 call_status (status -229) mount: RPC call returned error 229 RPC: 2 exit() = -229 RPC: 2 release task RPC: 2 disabling timer RPC: 2 release request c1fa4064 RPC: wake_up_next(c1fa4050 "xprt_backlog") RPC: 2 releasing NULL cred c1fe5500 RPC: rpc_release_client(c1faa5a0, 1) RPC: destroying mount client for 192.68.1.11 RPC: destroying NULL authenticator c1fe6460 RPC: destroying transport c1fa4000 RPC: disconnected transport c1fa4000 Root-NFS: Server returned error -229 while mounting /tftpboot/pancho VFS: Unable to mount root fs via NFS, trying floppy. VFS: Cannot open root device "nfs" or 02:00 Please append a correct "root=" boot option Kernel panic: VFS: Unable to mount root fs on 02:00 ========== linux/.config ========== # # Automatically generated make config: don't edit # CONFIG_PARISC=y # CONFIG_UID16 is not set # # Code maturity level options # CONFIG_EXPERIMENTAL=y # # General options # # CONFIG_SMP is not set # CONFIG_KWDB is not set CONFIG_GSC=y # CONFIG_IOMMU_CCIO is not set CONFIG_GSC_LASI=y CONFIG_PCI=y CONFIG_GSC_DINO=y # CONFIG_PCI_LBA is not set # # Loadable module support # # CONFIG_MODULES is not set # # General setup # CONFIG_NET=y CONFIG_SYSVIPC=y # CONFIG_BSD_PROCESS_ACCT is not set CONFIG_SYSCTL=y CONFIG_BINFMT_SOM=y # CONFIG_BINFMT_ELF is not set # CONFIG_BINFMT_MISC is not set # CONFIG_BINFMT_JAVA is not set # # Parallel port support # # CONFIG_PARPORT is not set # # Block devices # # CONFIG_BLK_DEV_FD is not set # CONFIG_BLK_DEV_XD is not set # CONFIG_PARIDE is not set # CONFIG_BLK_CPQ_DA is not set # CONFIG_BLK_CPQ_CISS_DA is not set # CONFIG_BLK_DEV_DAC960 is not set # CONFIG_BLK_DEV_LOOP is not set # CONFIG_BLK_DEV_NBD is not set # CONFIG_BLK_DEV_RAM is not set # CONFIG_BLK_DEV_INITRD is not set # # Networking options # # CONFIG_PACKET is not set # CONFIG_NETLINK is not set # CONFIG_NETFILTER is not set # CONFIG_FILTER is not set # CONFIG_UNIX is not set CONFIG_INET=y # CONFIG_IP_MULTICAST is not set # CONFIG_IP_ADVANCED_ROUTER is not set CONFIG_IP_PNP=y CONFIG_IP_PNP_BOOTP=y # CONFIG_IP_PNP_RARP is not set # CONFIG_NET_IPIP is not set # CONFIG_NET_IPGRE is not set # CONFIG_INET_ECN is not set # CONFIG_SYN_COOKIES is not set # CONFIG_IPV6 is not set # CONFIG_KHTTPD is not set # CONFIG_ATM is not set # # # # CONFIG_IPX is not set # CONFIG_ATALK is not set # CONFIG_DECNET is not set # CONFIG_BRIDGE is not set # CONFIG_X25 is not set # CONFIG_LAPB is not set # CONFIG_LLC is not set # CONFIG_NET_DIVERT is not set # CONFIG_ECONET is not set # CONFIG_WAN_ROUTER is not set # CONFIG_NET_FASTROUTE is not set # CONFIG_NET_HW_FLOWCONTROL is not set # # QoS and/or fair queueing # # CONFIG_NET_SCHED is not set # # SCSI support # # CONFIG_SCSI is not set # # Network device support # CONFIG_NETDEVICES=y CONFIG_LASI_82596=y # # ARCnet devices # # CONFIG_ARCNET is not set # CONFIG_DUMMY is not set # CONFIG_BONDING is not set # CONFIG_EQUALIZER is not set # CONFIG_TUN is not set # CONFIG_NET_SB1000 is not set # # Ethernet (10 or 100Mbit) # CONFIG_NET_ETHERNET=y # CONFIG_NET_VENDOR_3COM is not set # CONFIG_LANCE is not set # CONFIG_NET_VENDOR_SMC is not set # CONFIG_NET_VENDOR_RACAL is not set # CONFIG_AT1700 is not set # CONFIG_DEPCA is not set # CONFIG_HP100 is not set # CONFIG_NET_ISA is not set CONFIG_NET_PCI=y # CONFIG_PCNET32 is not set # CONFIG_ADAPTEC_STARFIRE is not set # CONFIG_AC3200 is not set # CONFIG_APRICOT is not set # CONFIG_CS89x0 is not set # CONFIG_DE4X5 is not set # CONFIG_TULIP is not set # CONFIG_DGRS is not set # CONFIG_DM9102 is not set # CONFIG_EEPRO100 is not set # CONFIG_LNE390 is not set # CONFIG_NATSEMI is not set # CONFIG_NE2K_PCI is not set # CONFIG_NE3210 is not set # CONFIG_ES3210 is not set # CONFIG_RTL8129 is not set # CONFIG_8139TOO is not set # CONFIG_SIS900 is not set # CONFIG_EPIC100 is not set # CONFIG_SUNDANCE is not set # CONFIG_TLAN is not set # CONFIG_VIA_RHINE is not set # CONFIG_WINBOND_840 is not set # CONFIG_NET_POCKET is not set # # Ethernet (1000 Mbit) # # CONFIG_ACENIC is not set # CONFIG_HAMACHI is not set # CONFIG_YELLOWFIN is not set # CONFIG_SK98LIN is not set # CONFIG_FDDI is not set # CONFIG_HIPPI is not set # CONFIG_PPP is not set # CONFIG_SLIP is not set # # Wireless LAN (non-hamradio) # # CONFIG_NET_RADIO is not set # # Token Ring devices # # CONFIG_TR is not set # CONFIG_NET_FC is not set # CONFIG_RCPCI is not set # CONFIG_SHAPER is not set # # Wan interfaces # # CONFIG_WAN is not set # # Character devices # # CONFIG_VT is not set CONFIG_SERIAL=y CONFIG_SERIAL_CONSOLE=y CONFIG_SERIAL_GSC=y CONFIG_SERIAL_EXTENDED=y # CONFIG_SERIAL_MANY_PORTS is not set # CONFIG_SERIAL_SHARE_IRQ is not set # CONFIG_SERIAL_DETECT_IRQ is not set # CONFIG_SERIAL_MULTIPORT is not set # CONFIG_HUB6 is not set # CONFIG_SERIAL_NONSTANDARD is not set CONFIG_UNIX98_PTYS=y CONFIG_UNIX98_PTY_COUNT=256 # # I2C support # # CONFIG_I2C is not set # # Mice # # CONFIG_BUSMOUSE is not set # CONFIG_MOUSE is not set # # Joysticks # # CONFIG_JOYSTICK is not set # # Input core support is needed for joysticks # # CONFIG_QIC02_TAPE is not set # # Watchdog Cards # # CONFIG_WATCHDOG is not set # CONFIG_GENRTC is not set # CONFIG_INTEL_RNG is not set # CONFIG_NVRAM is not set # CONFIG_RTC is not set # CONFIG_DTLK is not set # CONFIG_R3964 is not set # CONFIG_APPLICOM is not set # # Ftape, the floppy tape device driver # # CONFIG_FTAPE is not set # CONFIG_AGP is not set # CONFIG_DRM is not set # # File systems # # CONFIG_QUOTA is not set # CONFIG_AUTOFS_FS is not set # CONFIG_AUTOFS4_FS is not set # CONFIG_ADFS_FS is not set # CONFIG_ADFS_FS_RW is not set # CONFIG_AFFS_FS is not set # CONFIG_HFS_FS is not set # CONFIG_BFS_FS is not set # CONFIG_FAT_FS is not set # CONFIG_MSDOS_FS is not set # CONFIG_UMSDOS_FS is not set # CONFIG_VFAT_FS is not set # CONFIG_EFS_FS is not set # CONFIG_JFFS_FS is not set # CONFIG_CRAMFS is not set # CONFIG_RAMFS is not set CONFIG_ISO9660_FS=y # CONFIG_JOLIET is not set # CONFIG_MINIX_FS is not set # CONFIG_NTFS_FS is not set # CONFIG_NTFS_RW is not set # CONFIG_HPFS_FS is not set CONFIG_PROC_FS=y # CONFIG_DEVFS_FS is not set # CONFIG_DEVFS_MOUNT is not set # CONFIG_DEVFS_DEBUG is not set # CONFIG_DEVPTS_FS is not set # CONFIG_QNX4FS_FS is not set # CONFIG_QNX4FS_RW is not set # CONFIG_ROMFS_FS is not set CONFIG_EXT2_FS=y # CONFIG_SYSV_FS is not set # CONFIG_SYSV_FS_WRITE is not set # CONFIG_UDF_FS is not set # CONFIG_UDF_RW is not set # CONFIG_UFS_FS is not set # CONFIG_UFS_FS_WRITE is not set # # Network File Systems # # CONFIG_CODA_FS is not set CONFIG_NFS_FS=y # CONFIG_NFS_V3 is not set CONFIG_ROOT_NFS=y # CONFIG_NFSD is not set # CONFIG_NFSD_V3 is not set CONFIG_SUNRPC=y CONFIG_LOCKD=y # CONFIG_SMB_FS is not set # CONFIG_NCP_FS is not set # CONFIG_NCPFS_PACKET_SIGNING is not set # CONFIG_NCPFS_IOCTL_LOCKING is not set # CONFIG_NCPFS_STRONG is not set # CONFIG_NCPFS_NFS_NS is not set # CONFIG_NCPFS_OS2_NS is not set # CONFIG_NCPFS_SMALLDOS is not set # CONFIG_NCPFS_MOUNT_SUBDIR is not set # CONFIG_NCPFS_NDS_DOMAINS is not set # CONFIG_NCPFS_NLS is not set # CONFIG_NCPFS_EXTRAS is not set # # Partition Types # # CONFIG_PARTITION_ADVANCED is not set CONFIG_MSDOS_PARTITION=y # CONFIG_NLS is not set # # Sound Drivers # # CONFIG_SOUND is not set # # Kernel hacking # # CONFIG_MAGIC_SYSRQ is not set From grundler@cup.hp.com Wed, 15 Nov 2000 12:10:36 -0800 Date: Wed, 15 Nov 2000 12:10:36 -0800 From: Grant Grundler grundler@cup.hp.com Subject: [parisc-linux] nfsroot - 712/60 - RPC - help Jack Perdue wrote: Two changes: > a) I've tried NFSROOT=192.168.1.11 and NFSROOT=192.168.1.11/tftpboot/vmlinux > in palo/Makefile and the results are the same (both suggestions were > made to this list at some point) Try NFSROOT=192.168.1.11/tftpboot/pancho > ========== blacktower:/etc/bootptab ========== > pancho:\ > :hd=/tftpboot:\ > :bf=vmlinux:\ > :ht=ether:\ > :ha=08000993DA02:\ > :sm=255.255.255.0:\ > :hn:\ > :ip=192.168.1.13:\ > :vm=rfc1048: This is just a nit: bf= might be better named ":bf=lifimage\" (and you only need one colon between entry's :^) Copy /palo/lifimage to /tftpboot/lifimage. There must be something wrong but I don't see it. grant > kmem_create: Forcing size word alignment - nfs_fh > Looking up port of RPC 100003/2 on 192.68.1.11 > RPC: sendmsg returned error 229 > portmap: RPC call returned error 229 I don't see these types of errors on my config. Could be related to the misdirected NFSROOT. grant Grant Grundler Unix Systems Enablement Lab +1.408.447.7253 From j-perdue@tamu.edu Wed, 15 Nov 2000 14:14:13 -0600 Date: Wed, 15 Nov 2000 14:14:13 -0600 From: Jack Perdue j-perdue@tamu.edu Subject: Doh!!! was Re: [parisc-linux] nfsroot - 712/60 - RPC - help Of course, as soon I collected all that info and sent it I, in rereading, realized that I had put 192.68.1.11 in palo/Makefile instead of 192.168.1.11. Doh! However, since the info is out there now, can someone tell me what I need to resolve the following: [previous console output in previous mail] Switching from PDC console kmem_create: Forcing size word alignment - nfs_fh Looking up port of RPC 100003/2 on 192.168.1.11 Looking up port of RPC 100005/2 on 192.168.1.11 VFS: Mounted root (nfs filesystem) readonly. Kernel panic: No init found. Try passing init= option to kernel. jack j-perdue@tamu.edu From law@redhat.com Wed, 15 Nov 2000 13:30:59 -0700 Date: Wed, 15 Nov 2000 13:30:59 -0700 From: law@redhat.com law@redhat.com Subject: [parisc-linux] Single-stepping In message <200011151949.OAA22929@hiauly1.hia.nrc.ca>you write: > > I've been helping Alan Modra out with kernel changes to support > > single stepping for gdb. Paul Bame suggested I bounced our ideas > > off you in case you (or anyone else) had any comments. I havn't > > actually committed my changes yet. > > > > The basic approach is to use the recovery counter to generate > > a trap every instruction. The scheme is complicated because a > > suspended process may or may not return to user space via an RFI. > > I really don't know enough to comment on the implementation choice. Why > did you decide on this approach as opposed to inserting breaks and > enabling the taken branch branch trap (T)? It would appear that the recove > ry > counter was intended to provide software recovery from hardware faults > in fault tolerant systems. Possibly, Grant could comment on whether > it is actually useful for this purpose. Err, we tried that at the UofU in our mach port to the PA -- there's a problem with that scheme, though I don't remember precisely what it was. I believe there were cases where the recovery counter doesn't trigger a trap, possibly due to nullified instructions. You might look at the UofU BSD code, which I believe used breakpoints and branch taken traps instad. jeff From taggart@carmen.fc.hp.com Wed, 15 Nov 2000 13:49:18 -0700 Date: Wed, 15 Nov 2000 13:49:18 -0700 From: Matt Taggart taggart@carmen.fc.hp.com Subject: [parisc-linux] Palinux on a 712/60 Andrew Shugg writes... > Arnaud.ATOCH@oecd.org said: > > Hi, > > > > I got a couple of 715 and I'd love having access to an ISO image with STI > > console kernel too. > > I've never made an El Torito CDROM, is it possible to have multiple boot > images and a boot loader on a single disc? El Torito is a PC thing. It makes the front of a CDROM look like a floppy to the PC BIOS. For hppa you put a lifimage on the front of the CDROM(or tape or HDD, etc). > ie could the actual boot > image be a boot loader (PALO) which then points at one or more kernels > on the CDROM? Maybe. Paul Bame is the expert though. I think he had to do some work to get palo to be able to see a kernel on an ISO9660 filesystem. I don't know if it can currently be interruped and pointed at a different kernel. Paul? -- Matt Taggart taggart@fc.hp.com From drepper@redhat.com 15 Nov 2000 12:52:52 -0800 Date: 15 Nov 2000 12:52:52 -0800 From: Ulrich Drepper drepper@redhat.com Subject: [parisc-linux] Help with posix_types.h Paul Bame writes: > FYI I just heard some pretty good reasons why both ino_t and off_t > should be 64 bits even on 32-bit kernels. Keep those cards and letters > coming! Any new port which does *not* do this is broken from the beginning. Copying existing files is not what you have to do. Instead look at today's needs. The numbers of the x86 port are those the kernel people told me are needs, multiplied by 2 or 4. Do the same. -- ---------------. ,-. 1325 Chesapeake Terrace Ulrich Drepper \ ,-------------------' \ Sunnyvale, CA 94089 USA Red Hat `--' drepper at redhat.com `------------------------ From ich@johannes-zahn.de Wed, 15 Nov 2000 21:49:31 +0100 Date: Wed, 15 Nov 2000 21:49:31 +0100 From: johannes zahn ich@johannes-zahn.de Subject: [parisc-linux] init dies on apollo 720 Hi! I'm trying to get a 720/50 to boot from nfs, but as soon as the nfs mound happened init dies. This is all i get on the serial console (pasted from minicom): kmem_create: Forcing size word alignment - nfs_fh Looking up port of RPC 100003/2 on 192.168.1.1 Looking up port of RPC 100005/2 on 192.168.1.1 VFS: Mounted root (nfs filesystem) readonly. handle_interruption() pid=1 command='init' YZrvWESTHLNXBCVMcbcbcbcbOGFRQPDI PSW: 00000000000001001111011100001011 r0-3 00000000 4001ad3c 400057a3 00001f58 r4-7 4001967c 00000000 4001ada0 00001f58 r8-11 00000000 000023cc 00000001 00000000 r12-15 00001034 00000006 40019622 2001ff18 r16-19 c1fdc000 c027b60c 00000000 4001967c r20-23 0000a090 0000a090 00009d8c 00001f58 r24-27 00000001 00000081 4001ada0 c01492b0 r28-31 00000000 0000000b 20020790 400032d7 sr0-4 00000001 00000001 00000000 00000001 sr4-8 00000001 00000001 00000001 00000001 IASQ: 00000001 00000001 IAOQ: 4000d237 4000d23b IIR: 0ed51280 ISR: 00000001 IOR: 00009d8c ORIG_R28: 4001b208 handle_interruption() pid=1 command='init' YZrvWESTHLNXBCVMcbcbcbcbOGFRQPDI [...] I tried the cvs-latest kernel and palo from 2000-11-10 and 2000-11-14 with the crosscompiler from 2000-10-31. Buildhost is i386 linux. nfsroot was from 2000-10-09 or base.tgz from the 0.5 beta CD. I also tried the ramdisk images with sercon and sticon, but the kernel only says "cannot mount root FS on 01:00". The kernel from the 0.5 beta CD seems to have the parport stuff, and that does not work on this machine. Any ideas? Or a working .config? johannes From sieler@allegro.com Wed, 15 Nov 2000 13:08:15 -0800 (PST) Date: Wed, 15 Nov 2000 13:08:15 -0800 (PST) From: Stan Sieler sieler@allegro.com Subject: [parisc-linux] Single-stepping Re: > > The basic approach is to use the recovery counter to generate > > a trap every instruction. The scheme is complicated because a ... > I really don't know enough to comment on the implementation choice. Why > did you decide on this approach as opposed to inserting breaks and MPE/iX (which runs on PA-RISC hardware), has successfully used the Recovery Counter to implement single step for many, many years. BTW, in addition to single step, it's a great tool for counting the number of instructions a procedure (or code path) takes, assuming an adequately powerful debugger: 1) stop (perhaps via a breakpoint) at the start of the code you want to count. 2) set a breakpoint at the end of the code you want to count (e.g., if you're counting a procedure, set a breakpoint at the procedure exit) 3) instead of "continue", do: s 1000000 (i.e., tell Debug/iX to "singlestep" 1000000 instructions) 4) if you hit the breakpoint, enter: = 1000000 - rctr that's how many instructions your code took! (Not counting instructions executed by interrupt handlers, of course.) 5) if you *didn't* hit the breakpoint, then 1000000 wasn't enough instructions (and why are you trying to count so high?) This works because MPE's debug "s" command sets the Recovery Counter to the number of instructions you wanted to step. Normally, that's one (for just "s"). If you said "s 3", it would set the Recovery Counter to 3. If you say "s 1000000", and then execute 123 instructions, and then hit a breakpoint, Debug captures the entire register state as of the breakpoint: including the Recovery Counter (which has 1000000 - 123 in it). Tip: if you're looking at instruction-level debugging, look at Debug/iX to see how to do it right! > It would appear that the recovery > counter was intended to provide software recovery from hardware faults The 1986 PA-RISC Instruction manual simply says "The Recovery Counter (CR 0) can be used to provide software recovery of hardware faults in fault tolerant systems". (I.e., "can", not "must" ... and there's no explanation of how one would use it for this.) -- Stan Sieler sieler@allegro.com www.allegro.com/sieler/wanted/index.html www.sieler.com From drepper@redhat.com 15 Nov 2000 13:08:01 -0800 Date: 15 Nov 2000 13:08:01 -0800 From: Ulrich Drepper drepper@redhat.com Subject: [parisc-linux] Help with posix_types.h This reminds me of something I talked to Cary Coutant about before. You have certainly reserved a thread register in the ABI, right? If not, do it ASAP. -- ---------------. ,-. 1325 Chesapeake Terrace Ulrich Drepper \ ,-------------------' \ Sunnyvale, CA 94089 USA Red Hat `--' drepper at redhat.com `------------------------ From frank_rowand@mvista.com Wed, 15 Nov 2000 13:16:28 -0800 Date: Wed, 15 Nov 2000 13:16:28 -0800 From: Frank Rowand frank_rowand@mvista.com Subject: [parisc-linux] Single-stepping law@redhat.com wrote: > > In message <200011151949.OAA22929@hiauly1.hia.nrc.ca>you write: > > > I've been helping Alan Modra out with kernel changes to support > > > single stepping for gdb. Paul Bame suggested I bounced our ideas > > > off you in case you (or anyone else) had any comments. I havn't > > > actually committed my changes yet. > > > > > > The basic approach is to use the recovery counter to generate > > > a trap every instruction. The scheme is complicated because a > > > suspended process may or may not return to user space via an RFI. > > > > I really don't know enough to comment on the implementation choice. Why > > did you decide on this approach as opposed to inserting breaks and > > enabling the taken branch branch trap (T)? It would appear that the recove > > ry > > counter was intended to provide software recovery from hardware faults > > in fault tolerant systems. Possibly, Grant could comment on whether > > it is actually useful for this purpose. > Err, we tried that at the UofU in our mach port to the PA -- there's a problem > with that scheme, though I don't remember precisely what it was. I believe > there were cases where the recovery counter doesn't trigger a trap, possibly > due to nullified instructions. > > You might look at the UofU BSD code, which I believe used breakpoints and > branch taken traps instad. > > jeff > I implemented two different single step algorithms for a a _kernel_ debugger for hp-ux. The algorithm used could be chosen by a compile switch, because each method had cases that weren't handled well - for some debugging tasks one algorithm was superior to the other. Part of my problem with the recovery counter was that other services in the hp-ux kernel also used the recovery counter. I liked the recovery counter method better than my second method (but had to deal with collisions with the other kernel services). My second method was to insert a breakpoint at the target of the single step. It's a pain to do that because of issues with delay slots, branching, and nullification. I guess the point of all this rambling is to say that the recovery counter has been successfully used by a debugger for single stepping. -Frank -- Frank Rowand MontaVista Software, Inc From sieler@allegro.com Wed, 15 Nov 2000 13:47:15 -0800 (PST) Date: Wed, 15 Nov 2000 13:47:15 -0800 (PST) From: Stan Sieler sieler@allegro.com Subject: [parisc-linux] Single-stepping Re: > I implemented two different single step algorithms for a a _kernel_ debugger > for hp-ux. The algorithm used could be chosen by a compile switch, because BTW, Frank, ask Lee Courtney at MontaVista about Debug/iX ... we've had kernel debugging and single stepping (except for the interrupt control stack and a few other corner cases) for 15+ years. It's *very* powerful to be able to logon as root (or equivalent) and set breakpoints within the kernel, hit them, and then single step ... all on a standard release of the operating system. > I liked the recovery counter method better than my second method (but had to > deal with collisions with the other kernel services). My second method was > to insert a breakpoint at the target of the single step. It's a pain to do > that because of issues with delay slots, branching, and nullification. Worse yet...the breakpoint mechanism raises hell if you have more than one CPU :) You realllly don't want that other CPU to hit the breakpoint! -- Stan Sieler sieler@allegro.com www.allegro.com/sieler/wanted/index.html www.sieler.com From andreas@bawue.de Thu, 16 Nov 2000 23:06:04 +0100 Date: Thu, 16 Nov 2000 23:06:04 +0100 From: Andreas Thienemann andreas@bawue.de Subject: [parisc-linux] 250/1 doesn't boot but dumps stack Hi Grant, Grant Grundler wrote: > > lp0: using parport0 (interrupt-driven). > Are you sure you left out parallel port support? Yes, I am. I just attached the wrong log. Except the lp0 line, there are no differences... > > IASQ: 00000000 00000000 IAOQ: c029c264 c029c268 > > IIR: 0e681096 ISR: 00000000 IOR: 00000004 > > ORIG_R28: 00000000 > Smells like a driver bug. > Can you look up IOAQ and GR2 (c029c264 and c029c248) in System.map file? Of course. The only problem is, there is no such entry in /usr/src/pa-risc/sourcE/linux/System.map . Any ideas? andreas From rhirst@linuxcare.com Wed, 15 Nov 2000 22:19:29 +0000 Date: Wed, 15 Nov 2000 22:19:29 +0000 From: Richard Hirst rhirst@linuxcare.com Subject: [parisc-linux] dino maintainer? On Wed, Nov 15, 2000 at 09:58:35AM +0000, Richard Hirst wrote: > But Helge has problems with the sym53c8xx driver on a B160L. Is Turned out to be a 53c720, driven via Zalon and the ncr53c8xx driver. Driver worked as a module, but not compiled in. Now fixed. Richard From rlduncan@nortelnetworks.com Wed, 15 Nov 2000 17:28:13 -0500 Date: Wed, 15 Nov 2000 17:28:13 -0500 From: Robert Duncan rlduncan@nortelnetworks.com Subject: [parisc-linux] CD-ROM 715/50 boot dies after serial driver... This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C04F53.576F0F70 Content-Type: text/plain; charset="iso-8859-1" Greetings, I have downloaded the .5 Beta CDROM image, burned it and get a "fault in kernel" after the "Serial driver ... enabled" message when booting on my 715/50. This happens with either graphics or serial console configured in NVRAM. Has anyone else seen this error? ----------------begin console output (c) Copyright Hewlett-Packard Company, 1991, 1992 Portions of this code are (c) Copyright Samsung Electronics Co., Ltd, 91, 92 PDC ROM rev. 1.2 IODC ROM rev. 1.1 64 MB of memory have been configured. Selecting a system to boot. To stop selection process, press and hold the ESCAPE key..... Booting from: scsi.6.0 TOSHIBA CD-ROM XM-3501TA Soft booted. palo ipl bame@noam Tue Oct 31 14:18:02 MST 2000 0/vmlinux 2140145 bytes @ 0x6f9800 0/palo-cmdline '0/vmlinux ROOT=/ TERM=LINUX root=/dev/scd0' Kernel: partition 0 file /vmlinux ELF32 executable Entry 00100150 first 00100000 n 4 Segment 0 load 00100000 size 1460344 mediaptr 0x1000 Segment 1 load 00266000 size 179048 mediaptr 0x166000 Segment 2 load 00294000 size 109876 mediaptr 0x192000 Segment 3 load 002b0000 size 8192 mediaptr 0x1ad000 branching to kernel entry point 0x00100150 PDC Console Initialized The 32-bit Kernel has started... Enabled FP coprocessor Free memory starts at: 0xc02da000 (0x504d6c,0x504d6c,0x0,0x0) PALO command line: 'ROOT=/ TERM=LINUX root=/dev/scd0' PALO initrd 0-0 model 00003100 00000481 00000000 00000000 77a94524 ffffffff 00000004 0000000a 0000000a vers 00000009 CPUID vers 0 rev 0 Searching for devices in PDC firmware... processor hpa 0xfffbe000 an older box... Found devices: 1. Stinger Optional Graphics (10) at 0xf4000000, versions 0x6, 0x0, 0x77, 0x0, 0x0 2. Scorpio Core BA (11) at 0xf082f000, versions 0x7, 0x0, 0x70, 0x0, 0x0 3. Scorpio Core SCSI (10) at 0xf0825000, versions 0x7, 0x0, 0x71, 0x0, 0x0 4. Scorpio Core LAN (802.3) (10) at 0xf0826000, versions 0x7, 0x0, 0x72, 0x0, 0x0 5. Scorpio Core HIL (10) at 0xf0821000, versions 0x7, 0x0, 0x73, 0x0, 0x0 6. Scorpio Core RS-232 (10) at 0xf0823000, versions 0x7, 0x0, 0x75, 0x0, 0x0 7. Scorpio Core RS-232 (10) at 0xf0822000, versions 0x7, 0x0, 0x75, 0x0, 0x0 8. Scorpio Core Centronics (10) at 0xf0824000, versions 0x7, 0x0, 0x74, 0x0, 0x0 9. Scorpio Audio (10) at 0xf1000000, versions 0x7, 0x0, 0x7b, 0x0, 0x0 10. Scorpio EISA BA (11) at 0xfc000000, versions 0x7, 0x0, 0x76, 0x0, 0x0 11. Scorpio (715/50) (0) at 0xfffbe000, versions 0x310, 0x0, 0x4, 0x0, 0x81 12. Scorpio (1) at 0xfffbf000, versions 0x17, 0x0, 0x9, 0x0, 0x0 That's a total of 12 devices. CPU(s): 1 x PA7100 (PCX-T) at 50.000000 MHz Linux version 2.4.0-test6 (pjlahaie@elenuial.thepuffingroup.com) (gcc version 2.96 20000925 (experimental)) #32 Mon Nov 6 10:20:58 EST 2000 free_bootmem(0x2da800, 0x3d25800) initrd: 00000000-00000000 pagetable_init On node 0 totalpages: 16384 zone(0): 8192 pages. zone(1): 8192 pages. zone(2): 0 pages. Kernel command line: ROOT=/ TERM=LINUX root=/dev/scd0 trap_init Calibrating delay loop... 49.77 BogoMIPS Memory: 61388k available Dentry-cache hash table entries: 8192 (order: 4, 65536 bytes) Buffer-cache hash table entries: 4096 (order: 2, 16384 bytes) Page-cache hash table entries: 16384 (order: 4, 65536 bytes) Inode-cache hash table entries: 4096 (order: 3, 32768 bytes) POSIX conformance testing by UNIFIX ASP version 1 at 0xf0800000 found. Found i82596 at 0xf0826000, IRQ 87 early initialization of device eth0 is deferred Found HIL at 0xf0821000, IRQ 94 HIL: no keyboard present. Warning : device (10, 0x7, 0x0, 0x73, 0x0) NOT claimed by HIL 712, 715 or similiar Linux NET4.0 for Linux 2.4 Based upon Swansea University Computer Society NET3.039 NET4: Unix domain sockets 1.0/SMP for Linux NET4.0. NET4: Linux TCP/IP 1.0 for NET4.0 IP Protocols: ICMP, UDP, TCP IP: routing cache hash table of 512 buckets, 4Kbytes TCP: Hash tables configured (established 4096 bind 4096) Starting kswapd v1.7 pty: 256 Unix98 ptys configured lp: driver loaded but no devices found RAMDISK driver initialized: 16 RAM disks of 4096K size 1024 blocksize sim700: Couldn't get consistent shared memory sim700: Configuring 53c700 (SCSI-ID 7) at f0825100, IRQ 86 scsi0: Revision 0x0 Post test1, istat 05, sstat0 00, dstat 84 sim700: WARNING IRQ probe failed, (returned 0) scsi0: WARNING: target data areas are not dma coherent! scsi0: test 1 completed ok. scsi0: sim700_intr_handle() called with no interrupt scsi0 : LASI/Simple 53c7xx scsi : 1 host. Vendor: TOSHIBA Model: CD-ROM XM-3501TA Rev: 3054 Type: CD-ROM ANSI SCSI revision: 02 Detected scsi CD-ROM sr0 at scsi0, channel 0, id 6, lun 0 scsi : detected 1 SCSI cdrom total. Uniform CD-ROM driver Revision: 3.11 82596.c: MAC of HP700 LAN blindely read from the prom! eth0: Couldn't get consistent shared memory eth0: 82596 at 0xf0826000, 08 00 09 42 1B 37 IRQ 87. 82596.c $Revision: 1.14 $ Serial driver version 5.01 (2000-05-29) with MANY_PORTS SHARE_IRQ SERIAL_PCI enabled Dumping Stack from c3fc4000 to c3fc4bc0: 4000 00000000 00000140 00000000 00000000 c027a46c 00000001 00000000 ffffffff 4020 00000000 00000000 00000000 00000000 00000000 00000000 ffffffff c027a384 [...] 4ba0 ffffffff bffff5ff ffffff7f c01046e0 ffffbeff f7b7eddf 5fffffdf feefffff Data access rights fault in kernel: Code=26 regs=c3fc4980 (Addr=00000003) YZrvWESTHLNXBCVMcbcbcbcbOGFRQPDI PSW: 00000000000001000000000000001010 r0-3 00000000 c0221800 c011e9f8 c3fce420 r4-7 c3fce200 c0244f10 00000008 f0823800 r8-11 00000003 00000007 c0191568 c02c60a4 r12-15 fffffffc c0245000 c0245000 c02d72b8 r16-19 c0245000 c0245000 c02c6028 00000000 r20-23 c3fce234 f0823807 f0823800 0000000a r24-27 ffffffff c3fce420 c3fce200 c0266000 r28-31 ffffffff 00000240 c3fc4bc0 c012dfc0 sr0-4 00000000 00000000 00000000 00000000 sr4-8 00000000 00000000 00000000 00000000 IASQ: 00000000 00000000 IAOQ: c011e710 c011e714 IIR: 0f881093 ISR: 00000000 IOR: 00000003 ORIG_R28: 00000058 ----------------end console output thanks, Robert Duncan Nortelnetworks ------_=_NextPart_001_01C04F53.576F0F70 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable CD-ROM 715/50 boot dies after serial driver...

Greetings,
I have downloaded the .5 Beta CDROM image, burned it = and get a "fault in kernel" after the "Serial driver ... = enabled" message when booting on my 715/50.  This happens = with either graphics or serial console configured in NVRAM.

Has anyone else seen this error?

----------------begin console output
          &nb= sp;   (c) Copyright Hewlett-Packard Company, 1991, = 1992
Portions of this code are (c) Copyright Samsung = Electronics Co., Ltd, 91, 92

PDC ROM rev. 1.2
IODC ROM rev. 1.1
64 MB of memory have been configured.


Selecting a system to boot.
To stop selection process, press and hold the ESCAPE = key.....

Booting from:     = scsi.6.0     TOSHIBA CD-ROM XM-3501TA

Soft booted.
palo ipl bame@noam Tue Oct 31 14:18:02 MST = 2000
0/vmlinux 2140145 bytes @ 0x6f9800
0/palo-cmdline '0/vmlinux ROOT=3D/ TERM=3DLINUX = root=3D/dev/scd0'
Kernel: partition 0 file /vmlinux
ELF32 executable

Entry 00100150 first 00100000 n 4
Segment 0 load 00100000 size 1460344 mediaptr = 0x1000
Segment 1 load 00266000 size 179048 mediaptr = 0x166000
Segment 2 load 00294000 size 109876 mediaptr = 0x192000
Segment 3 load 002b0000 size 8192 mediaptr = 0x1ad000
branching to kernel entry point 0x00100150
PDC Console Initialized
The 32-bit Kernel has started...
Enabled FP coprocessor
Free memory starts at: 0xc02da000
(0x504d6c,0x504d6c,0x0,0x0)
PALO command line: 'ROOT=3D/ TERM=3DLINUX = root=3D/dev/scd0'
PALO initrd 0-0
model   00003100 00000481 00000000 = 00000000 77a94524 ffffffff 00000004 0000000a 0000000a
vers    00000009
CPUID vers 0 rev 0
Searching for devices in PDC firmware... processor = hpa 0xfffbe000
 an older box...
Found devices:
1. Stinger Optional Graphics (10) at 0xf4000000, = versions 0x6, 0x0, 0x77, 0x0, 0x0
2. Scorpio Core BA (11) at 0xf082f000, versions 0x7, = 0x0, 0x70, 0x0, 0x0
3. Scorpio Core SCSI (10) at 0xf0825000, versions = 0x7, 0x0, 0x71, 0x0, 0x0
4. Scorpio Core LAN (802.3) (10) at 0xf0826000, = versions 0x7, 0x0, 0x72, 0x0, 0x0
5. Scorpio Core HIL (10) at 0xf0821000, versions = 0x7, 0x0, 0x73, 0x0, 0x0
6. Scorpio Core RS-232 (10) at 0xf0823000, versions = 0x7, 0x0, 0x75, 0x0, 0x0
7. Scorpio Core RS-232 (10) at 0xf0822000, versions = 0x7, 0x0, 0x75, 0x0, 0x0
8. Scorpio Core Centronics (10) at 0xf0824000, = versions 0x7, 0x0, 0x74, 0x0, 0x0
9. Scorpio Audio (10) at 0xf1000000, versions 0x7, = 0x0, 0x7b, 0x0, 0x0
10. Scorpio EISA BA (11) at 0xfc000000, versions = 0x7, 0x0, 0x76, 0x0, 0x0
11. Scorpio (715/50) (0) at 0xfffbe000, versions = 0x310, 0x0, 0x4, 0x0, 0x81
12. Scorpio (1) at 0xfffbf000, versions 0x17, 0x0, = 0x9, 0x0, 0x0
That's a total of 12 devices.
CPU(s): 1 x PA7100 (PCX-T) at 50.000000 MHz
Linux version 2.4.0-test6 = (pjlahaie@elenuial.thepuffingroup.com) (gcc version 2.96 20000925 = (experimental)) #32 Mon Nov 6 10:20:58 EST 2000

free_bootmem(0x2da800, 0x3d25800)
initrd: 00000000-00000000
pagetable_init
On node 0 totalpages: 16384
zone(0): 8192 pages.
zone(1): 8192 pages.
zone(2): 0 pages.
Kernel command line: ROOT=3D/ TERM=3DLINUX = root=3D/dev/scd0
trap_init
Calibrating delay loop... 49.77 BogoMIPS
Memory: 61388k available
Dentry-cache hash table entries: 8192 (order: 4, = 65536 bytes)
Buffer-cache hash table entries: 4096 (order: 2, = 16384 bytes)
Page-cache hash table entries: 16384 (order: 4, = 65536 bytes)
Inode-cache hash table entries: 4096 (order: 3, = 32768 bytes)
POSIX conformance testing by UNIFIX
ASP version 1 at 0xf0800000 found.
Found i82596 at 0xf0826000, IRQ 87
early initialization of device eth0 is = deferred
Found HIL at 0xf0821000, IRQ 94
HIL: no keyboard present.
Warning : device (10, 0x7, 0x0, 0x73, 0x0) NOT = claimed by HIL 712, 715 or similiar
Linux NET4.0 for Linux 2.4
Based upon Swansea University Computer Society = NET3.039
NET4: Unix domain sockets 1.0/SMP for Linux = NET4.0.
NET4: Linux TCP/IP 1.0 for NET4.0
IP Protocols: ICMP, UDP, TCP
IP: routing cache hash table of 512 buckets, = 4Kbytes
TCP: Hash tables configured (established 4096 bind = 4096)
Starting kswapd v1.7
pty: 256 Unix98 ptys configured
lp: driver loaded but no devices found
RAMDISK driver initialized: 16 RAM disks of 4096K = size 1024 blocksize
sim700: Couldn't get consistent shared memory
sim700: Configuring 53c700 (SCSI-ID 7) at f0825100, = IRQ 86
scsi0: Revision 0x0
Post test1, istat 05, sstat0 00, dstat 84
sim700: WARNING IRQ probe failed, (returned = 0)
scsi0: WARNING: target data areas are not dma = coherent!
scsi0: test 1 completed ok.
scsi0: sim700_intr_handle() called with no = interrupt
scsi0 : LASI/Simple 53c7xx
scsi : 1 host.
  Vendor: TOSHIBA   Model: CD-ROM = XM-3501TA  Rev: 3054
  Type:   = CD-ROM           =             =       ANSI SCSI revision: 02
Detected scsi CD-ROM sr0 at scsi0, channel 0, id 6, = lun 0
scsi : detected 1 SCSI cdrom total.
Uniform CD-ROM driver Revision: 3.11
82596.c: MAC of HP700 LAN blindely read from the = prom!
eth0: Couldn't get consistent shared memory
eth0: 82596 at 0xf0826000, 08 00 09 42 1B 37 IRQ = 87.
82596.c $Revision: 1.14 $
Serial driver version 5.01 (2000-05-29) with = MANY_PORTS SHARE_IRQ SERIAL_PCI enabled

Dumping Stack from c3fc4000 to c3fc4bc0:
4000 00000000 00000140 00000000 00000000 c027a46c = 00000001 00000000 ffffffff
4020 00000000 00000000 00000000 00000000 00000000 = 00000000 ffffffff c027a384
 [...]
4ba0 ffffffff bffff5ff ffffff7f c01046e0 ffffbeff = f7b7eddf 5fffffdf feefffff

Data access rights fault in kernel: Code=3D26 = regs=3Dc3fc4980 (Addr=3D00000003)

     = YZrvWESTHLNXBCVMcbcbcbcbOGFRQPDI
PSW: 00000000000001000000000000001010
r0-3     00000000 c0221800 = c011e9f8 c3fce420
r4-7     c3fce200 c0244f10 = 00000008 f0823800
r8-11    00000003 00000007 c0191568 = c02c60a4
r12-15   fffffffc c0245000 c0245000 = c02d72b8
r16-19   c0245000 c0245000 c02c6028 = 00000000
r20-23   c3fce234 f0823807 f0823800 = 0000000a
r24-27   ffffffff c3fce420 c3fce200 = c0266000
r28-31   ffffffff 00000240 c3fc4bc0 = c012dfc0
sr0-4    00000000 00000000 00000000 = 00000000
sr4-8    00000000 00000000 00000000 = 00000000

IASQ: 00000000 00000000 IAOQ: c011e710 = c011e714
 IIR: 0f881093    ISR: = 00000000  IOR: 00000003
ORIG_R28: 00000058

----------------end console output

thanks,
Robert Duncan
Nortelnetworks

------_=_NextPart_001_01C04F53.576F0F70-- From rhirst@linuxcare.com Wed, 15 Nov 2000 22:35:40 +0000 Date: Wed, 15 Nov 2000 22:35:40 +0000 From: Richard Hirst rhirst@linuxcare.com Subject: [parisc-linux] CD-ROM 715/50 boot dies after serial driver... On Wed, Nov 15, 2000 at 05:28:13PM -0500, Robert Duncan wrote: > Greetings, > I have downloaded the .5 Beta CDROM image, burned it and get a "fault in > kernel" after the "Serial driver ... enabled" message when booting on my > 715/50. This happens with either graphics or serial console configured in > NVRAM. > > Has anyone else seen this error? I get exactly the same on my 715/75. Havn't had time to investigate yet. Richard From andreas@bawue.de Thu, 16 Nov 2000 23:42:35 +0100 Date: Thu, 16 Nov 2000 23:42:35 +0100 From: Andreas Thienemann andreas@bawue.de Subject: [parisc-linux] 250/1 doesn't boot but dumps stack Grant Grundler wrote: > > IASQ: 00000000 00000000 IAOQ: c029c264 c029c268 > > IIR: 0e681096 ISR: 00000000 IOR: 00000004 > > ORIG_R28: 00000000 > Smells like a driver bug. > Can you look up IOAQ and GR2 (c029c264 and c029c248) in System.map file? Okay, here we go (thanks for the build-tool information...) System Map output: 0xc029c264 __init_begin+264 0xc029x248 __init_begin+248 andreas From kailasr@webcash.com Wed, 15 Nov 2000 15:41:55 -0800 Date: Wed, 15 Nov 2000 15:41:55 -0800 From: Kailashnath V Rampure kailasr@webcash.com Subject: [parisc-linux] Apache package. --=====================_108207293==_.ALT Content-Type: text/plain; charset="us-ascii"; format=flowed Hi I tried to build apache_1.3.12 on HP a class server. But I have error. I have tried to check the site ftp://ftp.debian.org/debian/dists/unstable/main/binary-hppa/ I could not find one. I found some apache-doc etc. Can any on point me where I can try. Regards Kailas --=====================_108207293==_.ALT Content-Type: text/html; charset="us-ascii" Hi

I tried to build apache_1.3.12 on HP a class server. But I have error. I have tried to check the site ftp://ftp.debian.org/debian/dists/unstable/main/binary-hppa/
I could not find one. I found some apache-doc etc.

Can any on point me where I can try.
Regards
Kailas --=====================_108207293==_.ALT-- From bame@noam.fc.hp.com Wed, 15 Nov 2000 16:59:18 -0700 Date: Wed, 15 Nov 2000 16:59:18 -0700 From: Paul Bame bame@noam.fc.hp.com Subject: [parisc-linux] Apache package. = I tried to build apache_1.3.12 on HP a class server. But I have error. I = have tried to check the site = ftp://ftp.debian.org/debian/dists/unstable/main/binary-hppa/ = I could not find one. I found some apache-doc etc. We are still working on some kernel features which are required to support Apache (system 5 shared memory). -P From cary@cup.hp.com Wed, 15 Nov 2000 16:00:49 -0800 Date: Wed, 15 Nov 2000 16:00:49 -0800 From: Cary Coutant cary@cup.hp.com Subject: [parisc-linux] Help with posix_types.h >You have certainly reserved a thread register in the ABI, right? If >not, do it ASAP. On PA-RISC, the thread pointer is kept in the read-only control register CR 27. For user-thread implementations, we provided a kernel API to change the contents of the register. -cary From drepper@redhat.com 15 Nov 2000 16:04:51 -0800 Date: 15 Nov 2000 16:04:51 -0800 From: Ulrich Drepper drepper@redhat.com Subject: [parisc-linux] Help with posix_types.h Cary Coutant writes: > On PA-RISC, the thread pointer is kept in the read-only control register > CR 27. > > For user-thread implementations, we provided a kernel API to change the > contents of the register. This works fine for a 1:1 thread implementation but adds significant runtime hits for a m:n implementation. The latter is the direction we are heading. -- ---------------. ,-. 1325 Chesapeake Terrace Ulrich Drepper \ ,-------------------' \ Sunnyvale, CA 94089 USA Red Hat `--' drepper at redhat.com `------------------------ From jsm@udlkern.fc.hp.com Thu, 16 Nov 2000 02:01:12 -0700 (MST) Date: Thu, 16 Nov 2000 02:01:12 -0700 (MST) From: John Marvin jsm@udlkern.fc.hp.com Subject: Single-stepping > I've been helping Alan Modra out with kernel changes to support > single stepping for gdb. Paul Bame suggested I bounced our ideas > off you in case you (or anyone else) had any comments. I havn't > actually committed my changes yet. > I've decided to respond to the whole list, since others are now participating in the discussion. > The basic approach is to use the recovery counter to generate > a trap every instruction. The scheme is complicated because a > suspended process may or may not return to user space via an RFI. > There is no easy way to do single stepping on parisc. So any single stepping design will be complicated. > If it was suspended as a result of an interrupt then we can > simply set PSW bit R in the tasks saved registers and it will > get loaded by the RFI. On every task switch I set the > recovery counter to 0, just in case the new process is being > single-stepped. > > If a process is suspended during a syscall, then there is no > RFI on the return path to userland, and we have to handle things > differently. I have changed the syscall return path such that > it loads the recovery counter with 3 before updating the PSW > with a value from the tasks saved registers. If that PSW has > the R bit set, then the count of 3 will generate a trap on the > first instruction following the branch back to user space. > Note that PSW wasn't previously restored on the syscall return > path. > Just to be clear, it is impossible to restore the entire PSW without an RFI. So, I assume you are referring to the system mask subset of the PSW that can be manipulated by the ssm,rsm, and mtsm instructions. You mention restoring from the task's saved registers, but we currently do not save the system mask during a syscall (because it should be the same for all processes). Have you added code to do that also? If not, you are restoring from whatever the state was at the last interruption. Which in this case works (since the R bit state will be changed by another process while the debugged process is suspended, this should guarantee that the R bit state is up to date), but it seems a little ugly. In my opinion, you should just be checking a bit in the ptrace flags in the task structure, and setting the R bit with an ssm instruction based on that. > To avoid further complications of interrupts during the three > instructions when the recovery counter is decrementing, whenever > we set the R bit, we also clear the I bit to disable interrupts. Yuck, but I agree that it would be messier to have to deal with this in the interrupt handlers. Please make sure that a comment is added that explains what you are doing, and clearly documents the dependency on the number of remaining instructions before we return to user privilege level. I assume you restore the I bit in the recovery counter trap handler. I can think of alternative ways of doing this, but they are probably just as ugly (e.g. one possibility would be to do an rfi to set the L bit). > > Nullified instructions are handled by the controlling process > manually moving the childs IAOQ over the instruction without > actually setting it running, because the recovery counter isn't > decremented for nullified instructions. Does this code properly handle branches in the delay slot of another branch? (you need to make sure you are not advancing the queues by just adding 4 to each element). One concern I have about this method is that the userland debugger has to cooperate to make this design work, i.e. the single stepping is not accomplished entirely within the kernel, so we cannot easily change the design for single stepping at a later date. I wonder if it is necessary to do this. So what if we don't stop on the nullified instruction. Since it is nullified, it doesn't actually do anything, so why does the user have to see it, i.e. just let the recovery counter trap happen on the next truly executed instruction (i.e. the debugger performs a "double step" in this case). Am I missing something here? > > I need to do some more testing before committing this, but would > welcome any comments on the basic approach taken, areas I have > mis-understood, or problems with it that might not yet have > occurred to me. OK, well here are some issues that you didn't mention, so I don't know whether or not you addressed them: 1) When single stepping over a syscall, when do you actually stop the single stepping and execute the syscall? Hopefully you are not allowing single stepping after the gate instruction on the gateway page (and returning control to a non privileged debugging process). The recovery counter trap should detect when the user code gets to the gateway page. 2) Does your solution properly handle single stepping into and out of a signal handler? Note that the debugger will trap the signal as part of this process. Since the return is handled through a hidden syscall you may not have to do anything special here. Note that HP-UX does not use the recovery counter for single stepping. I made a few phone calls to various engineers to find out what the design process was, and why they chose the solution they did, but I could not find anyone who knew. Looking at the code in HP-UX it looks like someone implemented that code a long time ago, and some of the engineers who have worked on it since don't understand it, because some of the comments added since then clearly show a lack of understanding of what is really going on. Others on this list have mentioned that MPE does use the recovery counter for single stepping. Of course, MPE is not a Unix clone, so just because it could be done on MPE doesn't mean that the recovery counter can cover all cases on Unix (e.g. I have no idea how signals and syscalls are implemented on MPE). But since I have no idea why the recovery counter was not used for HP-UX, I can't say it is the wrong way to go. I can't think of anything that will definitely rule it out, I'm just a little uncomfortable with the fact that HP-UX chose not to use it. One advantage of the HP-UX method is that it completely encapsulates the single stepping inside the kernel, so it can be changed if necessary, without having to modify gdb (and having to worry about old versions of gdb). Anyway, for reference, HP-UX does single stepping by using a combination of the taken branch trap, and loading the instruction queues such that the front of the queue points to the next instruction to be single stepped and the back of the queue points to the first of two break instructions on a "break" page. It does NOT insert break instructions into the code, so it does not adversely affect execution on a SMP machine. Note that we already put a bunch of break instructions before the syscall entry point on the gateway page, so it would be easy to use our gateway page for the "break page". This way, if the single stepped instruction branches, a taken branch trap will be taken (which is important in the case where the branch nullifies its delay slot). Otherwise, the instruction will be executed and then the break instruction at the known location on the "break" page will be executed. If the single stepped instruction nullifies the next instruction, the second break instruction on the "break" page will be executed. Note that this is the short explanation. It is not as simple as it sounds. One major complication is that branches with links don't work properly with the instruction queue magic, so the link register has to be updated in the taken branch trap handler. Also branch externals won't update the space of the space queue tail properly (again, that has to be fixed in the taken branch handler). I can provide more details if the recovery counter method doesn't work out. Sincerely, John Marvin jsm@fc.hp.com From marteaut@esiee.fr Thu, 16 Nov 2000 10:04:07 +0100 Date: Thu, 16 Nov 2000 10:04:07 +0100 From: Thomas Marteau marteaut@esiee.fr Subject: [parisc-linux] nfsroot - 712/60 - RPC - help Hi Jack, > (c) Copyright 1990-1993, Hewlett-Packard Company. > All rights reserved > > Press to stop boot sequence. > Selecting a system to boot. > > Booting > palo ipl jkp2866@redtower Wed Nov 15 12:44:21 CST 2000 > 0/vmlinux 1606438 bytes @ 0x6800 > 0/palo-cmdline '0/vmlinux HOME=/ TERM=LINUX root=/dev/nfs nfsroot=192.68.1.11:/tftpboot/pancho ' Are you sure that the command line is rigth? Is your Server address is 192.-68-.1.11 Here is probably your mistake! Bye, ESIEE Team Visit http://www.esiee.fr/puffin > Kernel: partition 0 file /vmlinux > ELF32 executable > > Entry 00100000 first 00100000 n 4 > Segment 0 load 00100000 size 1097900 mediaptr 0x1000 > Segment 1 load 0020e000 size 150520 mediaptr 0x10e000 > Segment 2 load 00234000 size 55900 mediaptr 0x133000 > Segment 3 load 00244000 size 8192 mediaptr 0x141000 > branching to kernel entry point 0x00100000 > Set default PSW W bit to 0 > PDC Console Initialized > The 32-bit Kernel has started... > Enabled FP coprocessor > Free memory starts at: 0xc026e000 > start_parisc(0x504d6c,0x504d6c,0x0,0x0) > PALO command line: 'HOME=/ TERM=LINUX root=/dev/nfs nfsroot=192.68.1.11:/tftpboot/pancho ' > PALO initrd 0-0 > model 00006000 00000481 00000000 00000000 77564139 00000000 00000004 00000072 00000072 > vers 0000000a > CPUID vers 0 rev 0 > Searching for devices in PDC firmware... processor hpa 0xfffbe000 > an older box... > Found devices From rhirst@linuxcare.com Thu, 16 Nov 2000 12:00:47 +0000 Date: Thu, 16 Nov 2000 12:00:47 +0000 From: Richard Hirst rhirst@linuxcare.com Subject: Single-stepping Hi John, On Thu, Nov 16, 2000 at 02:01:12AM -0700, John Marvin wrote: > Just to be clear, it is impossible to restore the entire PSW without > an RFI. So, I assume you are referring to the system mask subset of > the PSW that can be manipulated by the ssm,rsm, and mtsm instructions. Yes, mtsm in this case. > You mention restoring from the task's saved registers, but we currently > do not save the system mask during a syscall (because it should be the > same for all processes). Have you added code to do that also? If not, Yes I have. > you are restoring from whatever the state was at the last interruption. > Which in this case works (since the R bit state will be changed > by another process while the debugged process is suspended, this should > guarantee that the R bit state is up to date), but it seems a little ugly. > In my opinion, you should just be checking a bit in the ptrace flags > in the task structure, and setting the R bit with an ssm instruction > based on that. Sounds better, I'll look in to it. > > Nullified instructions are handled by the controlling process > > manually moving the childs IAOQ over the instruction without > > actually setting it running, because the recovery counter isn't > > decremented for nullified instructions. Sorry, I worded that very badly. The code that moves the childs IAOQ on is in the kernel, invoked as a result of the controlling process calling ptrace(PTRACE_SINGLESTEP...) when the childs N bit is set. > Does this code properly handle branches in the delay slot of another > branch? (you need to make sure you are not advancing the queues by just > adding 4 to each element). One concern I have about this method is that Current code does /* Nullified, just crank over the queue. */ task_regs(child)->iaoq[0] = task_regs(child)->iaoq[1]; task_regs(child)->iasq[0] = task_regs(child)->iasq[1]; task_regs(child)->iaoq[1] = task_regs(child)->iaoq[0] + 4; Does that look right to you? > I wonder if it is necessary to do this. So what if we don't stop on the > nullified instruction. Since it is nullified, it doesn't actually do > anything, so why does the user have to see it, i.e. just let the recovery > counter trap happen on the next truly executed instruction (i.e. the > debugger performs a "double step" in this case). Am I missing something > here? I don't see why we really need to stop on a nullified instruction, but I'll wait for Alan to comment as he wrote this initially. > 1) When single stepping over a syscall, when do you actually stop the > single stepping and execute the syscall? Hopefully you are not > allowing single stepping after the gate instruction on the gateway > page (and returning control to a non privileged debugging process). > The recovery counter trap should detect when the user code gets > to the gateway page. At the moment my test harness notes IAOQ=0x100 and stops single stepping, but obviously the kernel needs to enforce that. > 2) Does your solution properly handle single stepping into and out of > a signal handler? Note that the debugger will trap the signal as part > of this process. Since the return is handled through a hidden syscall > you may not have to do anything special here. Havn't looked at signal handling yet. > Note that HP-UX does not use the recovery counter for single stepping. I Thanks for the description of how HP-UX does it. I'll stick with the recovery counter for now as it does seem to be basically working. I'll also try to ensure that it is completely encapsulated within the kernel so it is less painful to change later, if need be. Thanks, Richard From rhirst@linuxcare.com Thu, 16 Nov 2000 12:09:57 +0000 Date: Thu, 16 Nov 2000 12:09:57 +0000 From: Richard Hirst rhirst@linuxcare.com Subject: [parisc-linux] Single-stepping On Wed, Nov 15, 2000 at 02:49:02PM -0500, John David Anglin wrote: > > I've been helping Alan Modra out with kernel changes to support > > single stepping for gdb. Paul Bame suggested I bounced our ideas > > off you in case you (or anyone else) had any comments. I havn't > > actually committed my changes yet. > > > > The basic approach is to use the recovery counter to generate > > a trap every instruction. The scheme is complicated because a > > suspended process may or may not return to user space via an RFI. > > I really don't know enough to comment on the implementation choice. Why > did you decide on this approach as opposed to inserting breaks and > enabling the taken branch branch trap (T)? It would appear that the recovery > counter was intended to provide software recovery from hardware faults > in fault tolerant systems. Possibly, Grant could comment on whether > it is actually useful for this purpose. Alan Modra made those early decisions, but I gather that he went for the recovery counter because it at least appears to be rather more straightforward. Richard From jsm@udlkern.fc.hp.com Thu, 16 Nov 2000 05:44:55 -0700 (MST) Date: Thu, 16 Nov 2000 05:44:55 -0700 (MST) From: John Marvin jsm@udlkern.fc.hp.com Subject: Single-stepping Richard, > > Sorry, I worded that very badly. The code that moves the childs > IAOQ on is in the kernel, invoked as a result of the controlling > process calling ptrace(PTRACE_SINGLESTEP...) when the childs N > bit is set. > Great. > > Does this code properly handle branches in the delay slot of another > > branch? (you need to make sure you are not advancing the queues by just > > adding 4 to each element). One concern I have about this method is that > > Current code does > > /* Nullified, just crank over the queue. */ > task_regs(child)->iaoq[0] = task_regs(child)->iaoq[1]; > task_regs(child)->iasq[0] = task_regs(child)->iasq[1]; > task_regs(child)->iaoq[1] = task_regs(child)->iaoq[0] + 4; > > Does that look right to you? > Yes, that is the correct way to do it (I'll assume the duplicated line is just a cut/paste error). > > I wonder if it is necessary to do this. So what if we don't stop on the > > nullified instruction. Since it is nullified, it doesn't actually do > > anything, so why does the user have to see it, i.e. just let the recovery > > counter trap happen on the next truly executed instruction (i.e. the > > debugger performs a "double step" in this case). Am I missing something > > here? > > I don't see why we really need to stop on a nullified instruction, but > I'll wait for Alan to comment as he wrote this initially. > Given the above, i.e. that this is being handled in the kernel anyway, I guess I don't really care which way this goes. Probably it is best to do it whatever way gdb on hp-ux presents it. > > 1) When single stepping over a syscall, when do you actually stop the > > single stepping and execute the syscall? Hopefully you are not > > allowing single stepping after the gate instruction on the gateway > > page (and returning control to a non privileged debugging process). > > The recovery counter trap should detect when the user code gets > > to the gateway page. > > At the moment my test harness notes IAOQ=0x100 and stops single stepping, > but obviously the kernel needs to enforce that. > You should also be checking the space. But yes, the kernel needs to enforce this for security reasons. You should be able to do it in the recovery counter trap handler (rather than having to test for it in the syscall path, which affects all processes). > > 2) Does your solution properly handle single stepping into and out of > > a signal handler? Note that the debugger will trap the signal as part > > of this process. Since the return is handled through a hidden syscall > > you may not have to do anything special here. > > Havn't looked at signal handling yet. > I'm not sure that there is a real issue here or not. HP-UX has some code for single stepping with respect to signal handlers, but I believe it may only be necessary due to the saved state necessary as part of the iaoq manipulation. Obviously you should test this case. > > Note that HP-UX does not use the recovery counter for single stepping. I > > Thanks for the description of how HP-UX does it. I'll stick with > the recovery counter for now as it does seem to be basically working. > I'll also try to ensure that it is completely encapsulated within the kernel > so it is less painful to change later, if need be. > Sounds ok with me. And as long as there are no corner cases, it probably is the best solution, assuming we don't find another application for the recovery counter. John From rhirst@linuxcare.com Thu, 16 Nov 2000 13:20:17 +0000 Date: Thu, 16 Nov 2000 13:20:17 +0000 From: Richard Hirst rhirst@linuxcare.com Subject: Single-stepping On Thu, Nov 16, 2000 at 05:44:55AM -0700, John Marvin wrote: > > Current code does > > > > /* Nullified, just crank over the queue. */ > > task_regs(child)->iaoq[0] = task_regs(child)->iaoq[1]; > > task_regs(child)->iasq[0] = task_regs(child)->iasq[1]; > > task_regs(child)->iaoq[1] = task_regs(child)->iaoq[0] + 4; > > > > Does that look right to you? > > Yes, that is the correct way to do it (I'll assume the duplicated line > is just a cut/paste error). It's not duplicated (iaoq v. iasq). > > At the moment my test harness notes IAOQ=0x100 and stops single stepping, > > but obviously the kernel needs to enforce that. > > > You should also be checking the space. But yes, the kernel needs to enforce > this for security reasons. You should be able to do it in the recovery > counter trap handler (rather than having to test for it in the syscall > path, which affects all processes). I might come back to you on that when I've thought some more. Thanks, Richard From ian.zink@maryville.com Thu, 16 Nov 2000 09:46:18 -0600 Date: Thu, 16 Nov 2000 09:46:18 -0600 From: Ian Zink ian.zink@maryville.com Subject: [parisc-linux] I got the serial console to work... After reading some posts, I went back to trying to use to a serial console to no avail.. Then.. suddenly it hit me. Do'y. The cable I was using was straight-through not Cross-over. Now I have the 712 all booted and running Debian. Very cool, indeed. Thanks for all for your help. I think I will still work on building a STI ISO for the fun of it :) Thanks much, Ian Zink, Systems Engineer Maryville Technologies 540 Maryville Centre, Suite 300 St. Louis, MO 63141 636/519-4182 (FAX) 636/519-4141 ian.zink@maryville.com www.maryville.com From marteaut@esiee.fr Thu, 16 Nov 2000 18:18:58 +0100 Date: Thu, 16 Nov 2000 18:18:58 +0100 From: Thomas Marteau marteaut@esiee.fr Subject: [parisc-linux] The config for 712 hp boxes This is a multi-part message in MIME format. ------=_NextPart_000_00A5_01C04FF9.B01CC3A0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Hi all, Here is the config file we use to compile a new kernel from the test10 sources. We have the console with the STI and an extra term on the serial port. Also, in this mail, you have the diff between our hp_keyb.c and the official one but it gives you the ~ and the ' and others scancodes. All this works for the 712 boxes. We were forced to reboot our box to test the new kernel but before the uptime was 3 days and 4 hours during which we ran dselect and did some compiling. All the files inclosed are downloadable at http://www.esiee.fr/~puffin/code/dl.html Bye, ESIEE Team ------=_NextPart_000_00A5_01C04FF9.B01CC3A0 Content-Type: application/octet-stream; name="keyb.patch" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="keyb.patch" diff -urN linux2/drivers/char/hp_keyb.c linux/drivers/char/hp_keyb.c=0A= --- linux2/drivers/char/hp_keyb.c Thu Nov 16 17:39:03 2000=0A= +++ linux/drivers/char/hp_keyb.c Thu Nov 16 17:18:54 2000=0A= @@ -70,12 +70,12 @@=0A= #define K_F8 0x42=0A= #define K_F9 0x43=0A= #define K_F10 0x44=0A= -#define K_F11 87=0A= -#define K_F12 88=0A= +#define K_F11 0x57=0A= +#define K_F12 0x58=0A= #define K_PRNT 0x54=0A= -#define K_SCRL 70=0A= -#define K_BRK 119=0A= -#define K_AGR K_NONE=0A= +#define K_SCRL 0x46=0A= +#define K_BRK 0x77=0A= +#define K_AGR 0x29=0A= #define K_1 0x02=0A= #define K_2 0x03=0A= #define K_3 0x04=0A= @@ -89,10 +89,10 @@=0A= #define K_MINS 0x0c=0A= #define K_EQLS 0x0d=0A= #define K_BKSP 0x0e=0A= -#define K_INS 110=0A= -#define K_HOME 102=0A= -#define K_PGUP 104=0A= -#define K_NUML 69=0A= +#define K_INS 0x6e=0A= +#define K_HOME 0x66=0A= +#define K_PGUP 0x68=0A= +#define K_NUML 0x45=0A= #define KP_SLH 0x62=0A= #define KP_STR 0x37=0A= #define KP_MNS 0x4a=0A= @@ -111,13 +111,13 @@=0A= #define K_RSBK 0x1b=0A= #define K_ENTR 0x1c=0A= #define K_DEL 111=0A= -#define K_END 107=0A= -#define K_PGDN 109=0A= +#define K_END 0x6b=0A= +#define K_PGDN 0x6d=0A= #define KP_7 0x47=0A= #define KP_8 0x48=0A= #define KP_9 0x49=0A= -#define KP_PLS 118=0A= -#define K_CAPS 58=0A= +#define KP_PLS 0x4e=0A= +#define K_CAPS 0x3a=0A= #define K_A 0x1e=0A= #define K_S 0x1f=0A= #define K_D 0x20=0A= @@ -146,7 +146,7 @@=0A= #define K_DOT 0x34=0A= #define K_FSLH 0x35=0A= #define K_RSFT 0x36=0A= -#define K_UP 103 =0A= +#define K_UP 0x67=0A= #define KP_1 0x4f=0A= #define KP_2 0x50=0A= #define KP_3 0x51=0A= @@ -156,11 +156,11 @@=0A= #define K_SPCE 0x39=0A= #define K_RALT 0x64=0A= #define K_RCTL 0x61=0A= -#define K_LEFT 105=0A= -#define K_DOWN 108=0A= -#define K_RGHT 106=0A= -#define KP_0 82=0A= -#define KP_DOT 83=0A= +#define K_LEFT 0x69=0A= +#define K_DOWN 0x6c=0A= +#define K_RGHT 0x6a=0A= +#define KP_0 0x52=0A= +#define KP_DOT 0x53=0A= =0A= static unsigned char keycode_translate[256] =3D=0A= {=0A= @@ -198,7 +198,7 @@=0A= =0A= /* ----- the following code stolen from pc_keyb.c */=0A= =0A= -#ifdef CONFIG_MAGIC_SYSRQ=0A= +=0A= unsigned char pckbd_sysrq_xlate[128] =3D=0A= "\000\0331234567890-=3D\177\t" /* 0x00 - 0x0f */=0A= "qwertyuiop[]\r\000as" /* 0x10 - 0x1f */=0A= @@ -207,7 +207,6 @@=0A= "\206\207\210\211\212\000\000789-456+1" /* 0x40 - 0x4f */=0A= "230\177\000\000\213\214\000\000\000\000\000\000\000\000\000\000" /* = 0x50 - 0x5f */=0A= "\r\000/"; /* 0x60 - 0x6f */=0A= -#endif=0A= =0A= /*=0A= * Translation of escaped scancodes to keycodes.=0A= ------=_NextPart_000_00A5_01C04FF9.B01CC3A0 Content-Type: application/octet-stream; name="config" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="config" #=0A= # Automatically generated by make menuconfig: don't edit=0A= #=0A= CONFIG_PARISC=3Dy=0A= # CONFIG_UID16 is not set=0A= =0A= #=0A= # Code maturity level options=0A= #=0A= CONFIG_EXPERIMENTAL=3Dy=0A= =0A= #=0A= # General options=0A= #=0A= # CONFIG_SMP is not set=0A= # CONFIG_KWDB is not set=0A= CONFIG_GSC=3Dy=0A= CONFIG_IOMMU_CCIO=3Dy=0A= CONFIG_GSC_LASI=3Dy=0A= CONFIG_PCI=3Dy=0A= CONFIG_GSC_DINO=3Dy=0A= CONFIG_PCI_LBA=3Dy=0A= CONFIG_IOSAPIC=3Dy=0A= CONFIG_IOMMU_SBA=3Dy=0A= =0A= #=0A= # Loadable module support=0A= #=0A= # CONFIG_MODULES is not set=0A= =0A= #=0A= # General setup=0A= #=0A= CONFIG_NET=3Dy=0A= # CONFIG_SYSVIPC is not set=0A= # CONFIG_BSD_PROCESS_ACCT is not set=0A= CONFIG_SYSCTL=3Dy=0A= # CONFIG_BINFMT_SOM is not set=0A= CONFIG_BINFMT_ELF=3Dy=0A= # CONFIG_BINFMT_MISC is not set=0A= # CONFIG_BINFMT_JAVA is not set=0A= =0A= #=0A= # Parallel port support=0A= #=0A= CONFIG_PARPORT=3Dy=0A= # CONFIG_PARPORT_PC is not set=0A= # CONFIG_PARPORT_GSC is not set=0A= # CONFIG_PARPORT_OTHER is not set=0A= # CONFIG_PARPORT_1284 is not set=0A= =0A= #=0A= # Block devices=0A= #=0A= # CONFIG_BLK_DEV_FD is not set=0A= # CONFIG_BLK_DEV_XD is not set=0A= # CONFIG_PARIDE is not set=0A= # CONFIG_BLK_CPQ_DA is not set=0A= # CONFIG_BLK_CPQ_CISS_DA is not set=0A= # CONFIG_BLK_DEV_DAC960 is not set=0A= # CONFIG_BLK_DEV_LOOP is not set=0A= # CONFIG_BLK_DEV_NBD is not set=0A= CONFIG_BLK_DEV_RAM=3Dy=0A= CONFIG_BLK_DEV_RAM_SIZE=3D4096=0A= CONFIG_BLK_DEV_INITRD=3Dy=0A= =0A= #=0A= # Networking options=0A= #=0A= # CONFIG_PACKET is not set=0A= # CONFIG_NETLINK is not set=0A= # CONFIG_NETFILTER is not set=0A= # CONFIG_FILTER is not set=0A= # CONFIG_UNIX is not set=0A= CONFIG_INET=3Dy=0A= # CONFIG_IP_MULTICAST is not set=0A= # CONFIG_IP_ADVANCED_ROUTER is not set=0A= CONFIG_IP_PNP=3Dy=0A= # CONFIG_IP_PNP_BOOTP is not set=0A= # CONFIG_IP_PNP_RARP is not set=0A= # CONFIG_NET_IPIP is not set=0A= # CONFIG_NET_IPGRE is not set=0A= # CONFIG_INET_ECN is not set=0A= # CONFIG_SYN_COOKIES is not set=0A= # CONFIG_IPV6 is not set=0A= # CONFIG_KHTTPD is not set=0A= # CONFIG_ATM is not set=0A= # CONFIG_IPX is not set=0A= # CONFIG_ATALK is not set=0A= # CONFIG_DECNET is not set=0A= # CONFIG_BRIDGE is not set=0A= # CONFIG_X25 is not set=0A= # CONFIG_LAPB is not set=0A= # CONFIG_LLC is not set=0A= # CONFIG_NET_DIVERT is not set=0A= # CONFIG_ECONET is not set=0A= # CONFIG_WAN_ROUTER is not set=0A= # CONFIG_NET_FASTROUTE is not set=0A= # CONFIG_NET_HW_FLOWCONTROL is not set=0A= =0A= #=0A= # QoS and/or fair queueing=0A= #=0A= # CONFIG_NET_SCHED is not set=0A= =0A= #=0A= # SCSI support=0A= #=0A= CONFIG_SCSI=3Dy=0A= CONFIG_BLK_DEV_SD=3Dy=0A= CONFIG_SD_EXTRA_DEVS=3D40=0A= # CONFIG_CHR_DEV_ST is not set=0A= # CONFIG_BLK_DEV_SR is not set=0A= CONFIG_CHR_DEV_SG=3Dy=0A= # CONFIG_SCSI_MULTI_LUN is not set=0A= # CONFIG_SCSI_CONSTANTS is not set=0A= =0A= #=0A= # SCSI low-level drivers=0A= #=0A= CONFIG_SCSI_LASI=3Dy=0A= CONFIG_SCSI_ZALON=3Dy=0A= CONFIG_SCSI_SYM53C8XX=3Dy=0A= CONFIG_SCSI_NCR53C8XX_DEFAULT_TAGS=3D8=0A= CONFIG_SCSI_NCR53C8XX_MAX_TAGS=3D32=0A= CONFIG_SCSI_NCR53C8XX_SYNC=3D20=0A= # CONFIG_SCSI_NCR53C8XX_PROFILE is not set=0A= # CONFIG_SCSI_NCR53C8XX_IOMAPPED is not set=0A= =0A= #=0A= # Network device support=0A= #=0A= CONFIG_NETDEVICES=3Dy=0A= CONFIG_LASI_82596=3Dy=0A= =0A= #=0A= # ARCnet devices=0A= #=0A= # CONFIG_ARCNET is not set=0A= # CONFIG_DUMMY is not set=0A= # CONFIG_BONDING is not set=0A= # CONFIG_EQUALIZER is not set=0A= # CONFIG_TUN is not set=0A= # CONFIG_NET_SB1000 is not set=0A= =0A= #=0A= # Ethernet (10 or 100Mbit)=0A= #=0A= CONFIG_NET_ETHERNET=3Dy=0A= # CONFIG_NET_VENDOR_3COM is not set=0A= # CONFIG_LANCE is not set=0A= # CONFIG_NET_VENDOR_SMC is not set=0A= # CONFIG_NET_VENDOR_RACAL is not set=0A= # CONFIG_AT1700 is not set=0A= # CONFIG_DEPCA is not set=0A= # CONFIG_HP100 is not set=0A= # CONFIG_NET_ISA is not set=0A= CONFIG_NET_PCI=3Dy=0A= # CONFIG_PCNET32 is not set=0A= # CONFIG_ADAPTEC_STARFIRE is not set=0A= # CONFIG_AC3200 is not set=0A= # CONFIG_APRICOT is not set=0A= # CONFIG_CS89x0 is not set=0A= # CONFIG_DE4X5 is not set=0A= CONFIG_TULIP=3Dy=0A= # CONFIG_DGRS is not set=0A= # CONFIG_DM9102 is not set=0A= # CONFIG_EEPRO100 is not set=0A= # CONFIG_LNE390 is not set=0A= # CONFIG_NATSEMI is not set=0A= # CONFIG_NE2K_PCI is not set=0A= # CONFIG_NE3210 is not set=0A= # CONFIG_ES3210 is not set=0A= # CONFIG_RTL8129 is not set=0A= # CONFIG_8139TOO is not set=0A= # CONFIG_SIS900 is not set=0A= # CONFIG_EPIC100 is not set=0A= # CONFIG_SUNDANCE is not set=0A= # CONFIG_TLAN is not set=0A= # CONFIG_VIA_RHINE is not set=0A= # CONFIG_WINBOND_840 is not set=0A= # CONFIG_NET_POCKET is not set=0A= =0A= #=0A= # Ethernet (1000 Mbit)=0A= #=0A= # CONFIG_ACENIC is not set=0A= # CONFIG_HAMACHI is not set=0A= # CONFIG_YELLOWFIN is not set=0A= # CONFIG_SK98LIN is not set=0A= # CONFIG_FDDI is not set=0A= # CONFIG_HIPPI is not set=0A= # CONFIG_PLIP is not set=0A= # CONFIG_PPP is not set=0A= # CONFIG_SLIP is not set=0A= =0A= #=0A= # Wireless LAN (non-hamradio)=0A= #=0A= # CONFIG_NET_RADIO is not set=0A= =0A= #=0A= # Token Ring devices=0A= #=0A= # CONFIG_TR is not set=0A= # CONFIG_NET_FC is not set=0A= # CONFIG_RCPCI is not set=0A= # CONFIG_SHAPER is not set=0A= =0A= #=0A= # Wan interfaces=0A= #=0A= # CONFIG_WAN is not set=0A= =0A= #=0A= # Character devices=0A= #=0A= CONFIG_VT=3Dy=0A= CONFIG_VT_CONSOLE=3Dy=0A= CONFIG_GSC_PS2=3Dy=0A= # CONFIG_HIL is not set=0A= CONFIG_SERIAL=3Dy=0A= # CONFIG_SERIAL_CONSOLE is not set=0A= CONFIG_SERIAL_GSC=3Dy=0A= # CONFIG_SERIAL_EXTENDED is not set=0A= # CONFIG_SERIAL_NONSTANDARD is not set=0A= CONFIG_UNIX98_PTYS=3Dy=0A= CONFIG_UNIX98_PTY_COUNT=3D256=0A= # CONFIG_PRINTER is not set=0A= # CONFIG_PPDEV is not set=0A= =0A= #=0A= # I2C support=0A= #=0A= # CONFIG_I2C is not set=0A= =0A= #=0A= # Mice=0A= #=0A= # CONFIG_BUSMOUSE is not set=0A= # CONFIG_MOUSE is not set=0A= =0A= #=0A= # Joysticks=0A= #=0A= # CONFIG_JOYSTICK is not set=0A= # CONFIG_QIC02_TAPE is not set=0A= =0A= #=0A= # Watchdog Cards=0A= #=0A= # CONFIG_WATCHDOG is not set=0A= CONFIG_GENRTC=3Dy=0A= # CONFIG_INTEL_RNG is not set=0A= # CONFIG_NVRAM is not set=0A= # CONFIG_RTC is not set=0A= # CONFIG_DTLK is not set=0A= # CONFIG_R3964 is not set=0A= # CONFIG_APPLICOM is not set=0A= =0A= #=0A= # Ftape, the floppy tape device driver=0A= #=0A= # CONFIG_FTAPE is not set=0A= # CONFIG_AGP is not set=0A= # CONFIG_DRM is not set=0A= =0A= #=0A= # File systems=0A= #=0A= # CONFIG_QUOTA is not set=0A= # CONFIG_AUTOFS_FS is not set=0A= # CONFIG_AUTOFS4_FS is not set=0A= # CONFIG_ADFS_FS is not set=0A= # CONFIG_ADFS_FS_RW is not set=0A= # CONFIG_AFFS_FS is not set=0A= # CONFIG_HFS_FS is not set=0A= # CONFIG_BFS_FS is not set=0A= # CONFIG_FAT_FS is not set=0A= # CONFIG_MSDOS_FS is not set=0A= # CONFIG_UMSDOS_FS is not set=0A= # CONFIG_VFAT_FS is not set=0A= # CONFIG_EFS_FS is not set=0A= # CONFIG_JFFS_FS is not set=0A= # CONFIG_CRAMFS is not set=0A= # CONFIG_RAMFS is not set=0A= CONFIG_ISO9660_FS=3Dy=0A= # CONFIG_JOLIET is not set=0A= # CONFIG_MINIX_FS is not set=0A= # CONFIG_NTFS_FS is not set=0A= # CONFIG_NTFS_RW is not set=0A= # CONFIG_HPFS_FS is not set=0A= CONFIG_PROC_FS=3Dy=0A= # CONFIG_DEVFS_FS is not set=0A= # CONFIG_DEVFS_MOUNT is not set=0A= # CONFIG_DEVFS_DEBUG is not set=0A= # CONFIG_DEVPTS_FS is not set=0A= # CONFIG_QNX4FS_FS is not set=0A= # CONFIG_QNX4FS_RW is not set=0A= # CONFIG_ROMFS_FS is not set=0A= CONFIG_EXT2_FS=3Dy=0A= # CONFIG_SYSV_FS is not set=0A= # CONFIG_SYSV_FS_WRITE is not set=0A= # CONFIG_UDF_FS is not set=0A= # CONFIG_UDF_RW is not set=0A= # CONFIG_UFS_FS is not set=0A= # CONFIG_UFS_FS_WRITE is not set=0A= =0A= #=0A= # Network File Systems=0A= #=0A= # CONFIG_CODA_FS is not set=0A= CONFIG_NFS_FS=3Dy=0A= # CONFIG_NFS_V3 is not set=0A= CONFIG_ROOT_NFS=3Dy=0A= # CONFIG_NFSD is not set=0A= # CONFIG_NFSD_V3 is not set=0A= CONFIG_SUNRPC=3Dy=0A= CONFIG_LOCKD=3Dy=0A= # CONFIG_SMB_FS is not set=0A= # CONFIG_NCP_FS is not set=0A= # CONFIG_NCPFS_PACKET_SIGNING is not set=0A= # CONFIG_NCPFS_IOCTL_LOCKING is not set=0A= # CONFIG_NCPFS_STRONG is not set=0A= # CONFIG_NCPFS_NFS_NS is not set=0A= # CONFIG_NCPFS_OS2_NS is not set=0A= # CONFIG_NCPFS_SMALLDOS is not set=0A= # CONFIG_NCPFS_MOUNT_SUBDIR is not set=0A= # CONFIG_NCPFS_NDS_DOMAINS is not set=0A= # CONFIG_NCPFS_NLS is not set=0A= # CONFIG_NCPFS_EXTRAS is not set=0A= =0A= #=0A= # Partition Types=0A= #=0A= # CONFIG_PARTITION_ADVANCED is not set=0A= CONFIG_MSDOS_PARTITION=3Dy=0A= # CONFIG_NLS is not set=0A= =0A= #=0A= # Sound Drivers=0A= #=0A= # CONFIG_SOUND is not set=0A= =0A= #=0A= # Console drivers=0A= #=0A= =0A= #=0A= # Frame-buffer support=0A= #=0A= # CONFIG_FB is not set=0A= CONFIG_STI_CONSOLE=3Dy=0A= CONFIG_DUMMY_CONSOLE=3Dy=0A= =0A= #=0A= # Kernel hacking=0A= #=0A= CONFIG_MAGIC_SYSRQ=3Dy=0A= ------=_NextPart_000_00A5_01C04FF9.B01CC3A0-- From grundler@cup.hp.com Thu, 16 Nov 2000 10:10:23 -0800 Date: Thu, 16 Nov 2000 10:10:23 -0800 From: Grant Grundler grundler@cup.hp.com Subject: [parisc-linux] The config for 712 hp boxes "Thomas Marteau" wrote: > Hi all, > > Here is the config file we use to compile a new kernel from the test10 > sources. We have the console with the STI and an extra term on the serial > port. Thomas - excellent - thanks! > Also, in this mail, you have the diff between our hp_keyb.c and the official > one but it gives you the ~ and the ' and others scancodes. I noticed this mail was directed to me - but I can't take ownership of this code. I have too many other things going on. Helge - can you commit this fix too? thanks, grant Grant Grundler Unix Systems Enablement Lab +1.408.447.7253 From deller@gmx.de Thu, 16 Nov 2000 19:25:49 +0100 Date: Thu, 16 Nov 2000 19:25:49 +0100 From: Helge Deller deller@gmx.de Subject: [parisc-linux] The config for 712 hp boxes On Thursday 16 November 2000 19:10, Grant Grundler wrote: > "Thomas Marteau" wrote: > > Hi all, > > > > Here is the config file we use to compile a new kernel from the test10 > > sources. We have the console with the STI and an extra term on the serial > > port. > > Thomas - excellent - thanks! > > > Also, in this mail, you have the diff between our hp_keyb.c and the official > > one but it gives you the ~ and the ' and others scancodes. > > I noticed this mail was directed to me - but I can't take ownership > of this code. I have too many other things going on. > > Helge - can you commit this fix too? Ok. I will test & evtl. commit it today. > > thanks, > grant > > Grant Grundler > Unix Systems Enablement Lab > +1.408.447.7253 > > --------------------------------------------------------------------------- > To unsubscribe: send e-mail to parisc-linux-request@thepuffingroup.com with > `unsubscribe' as the subject. From frank_rowand@mvista.com Thu, 16 Nov 2000 11:00:48 -0800 Date: Thu, 16 Nov 2000 11:00:48 -0800 From: Frank Rowand frank_rowand@mvista.com Subject: Single-stepping John Marvin wrote: > > Richard, > > > > > Sorry, I worded that very badly. The code that moves the childs > > IAOQ on is in the kernel, invoked as a result of the controlling > > process calling ptrace(PTRACE_SINGLESTEP...) when the childs N > > bit is set. > > > > Great. > > > > Does this code properly handle branches in the delay slot of another > > > branch? (you need to make sure you are not advancing the queues by just > > > adding 4 to each element). One concern I have about this method is that > > > > Current code does > > > > /* Nullified, just crank over the queue. */ > > task_regs(child)->iaoq[0] = task_regs(child)->iaoq[1]; > > task_regs(child)->iasq[0] = task_regs(child)->iasq[1]; > > task_regs(child)->iaoq[1] = task_regs(child)->iaoq[0] + 4; > > > > Does that look right to you? > > > > Yes, that is the correct way to do it (I'll assume the duplicated line > is just a cut/paste error). If iaoq[0] contains a branch, iaoq[1] is in the delay slot. The instruction executed after iaoq[1] would then typically _not_ be iaoq[0] + 4 (the next instruction would be the target of the branch at iaoq[0]). > Sounds ok with me. And as long as there are no corner cases, it probably > is the best solution, assuming we don't find another application for > the recovery counter. The recovery counter is very useful for performance measurement tools to understand the cycles per instruction of a code path. (Using the recovery counter for the debugger doesn't preclude using it for performance tools - you just can't easily use it for both purposes at the same instant in time.) > John -Frank -- Frank Rowand MontaVista Software, Inc From rhirst@linuxcare.com Thu, 16 Nov 2000 20:28:42 +0000 Date: Thu, 16 Nov 2000 20:28:42 +0000 From: Richard Hirst rhirst@linuxcare.com Subject: Single-stepping On Thu, Nov 16, 2000 at 11:00:48AM -0800, Frank Rowand wrote: > John Marvin wrote: > > > > Does this code properly handle branches in the delay slot of another > > > > branch? (you need to make sure you are not advancing the queues by just > > > > adding 4 to each element). One concern I have about this method is that > > > > > > Current code does > > > > > > /* Nullified, just crank over the queue. */ > > > task_regs(child)->iaoq[0] = task_regs(child)->iaoq[1]; > > > task_regs(child)->iasq[0] = task_regs(child)->iasq[1]; > > > task_regs(child)->iaoq[1] = task_regs(child)->iaoq[0] + 4; > > > > > > Does that look right to you? > > > > > > > Yes, that is the correct way to do it (I'll assume the duplicated line > > is just a cut/paste error). > > If iaoq[0] contains a branch, iaoq[1] is in the delay slot. The instruction > executed after iaoq[1] would then typically _not_ be iaoq[0] + 4 (the next > instruction would be the target of the branch at iaoq[0]). But the above code is only executed if the current instruction is nullified. In your example, the branch in iaoq[0] would be nullified and therefore never taken. Richard From deller@gmx.de Thu, 16 Nov 2000 22:28:50 +0100 Date: Thu, 16 Nov 2000 22:28:50 +0100 From: Helge Deller deller@gmx.de Subject: [parisc-linux] The config for 712 hp boxes On Thursday 16 November 2000 18:18, Thomas Marteau wrote: > Hi all, > > [....] > Also, in this mail, you have the diff between our hp_keyb.c and the official > one but it gives you the ~ and the ' and others scancodes. > [....] Hi ESIEE-Team ! Thanks for your patch ! I committed your patch into CVS and just tweaked it a little for CONFIG_MAGIC_SYSRQ. I hope this is ok for you ? If your time permits, I would like to ask, if you maybe also want to look at getting the CAPS-Lock-, Scroll-Lock- & Num-Lock-LED's working ? Furthermore you mention in your project-history on your homepage something about "keyboard and soundchip problems" (Oct. 24). I'm asking just out of curiousity: Did you thought about programming the on-board sound-chips (which I believe would be a hard job.) ? > Bye, > ESIEE Team Best regards, Helge Deller. From taggart@carmen.fc.hp.com Thu, 16 Nov 2000 19:25:26 -0700 Date: Thu, 16 Nov 2000 19:25:26 -0700 From: Matt Taggart taggart@carmen.fc.hp.com Subject: [parisc-linux] glibc merged to 2.2 Today Paul Bame and I merged/updated the puffin.external.hp.com glibc cvs to glibc 2.2. After the merge I cleaned up the differences between our cvs and 2.2, mostly comment differences and formatting changes. With the exception of the setjmp problem mentioned in, http://puffin.external.hp.com/mailing-lists/parisc-linux/2000/11-Nov/0091.html and the fact that we have/need newer "scripts/config.guess" and "scripts/config.sub", we are completely sync'ed up with glibc 2.2. -- Matt Taggart taggart@fc.hp.com From deller@gmx.de Fri, 17 Nov 2000 15:34:09 +0100 Date: Fri, 17 Nov 2000 15:34:09 +0100 From: Helge Deller deller@gmx.de Subject: [parisc-linux] The config for 712 hp boxes [CC'ed the list, so maybe someone else can comment too....] On Friday 17 November 2000 11:45, Thomas Marteau wrote: > Hi Helge, Hi, > > > ----- Original Message ----- > From: Helge Deller > To: Thomas Marteau > Cc: > Sent: Thursday, November 16, 2000 10:28 PM > Subject: Re: [parisc-linux] The config for 712 hp boxes > > > > On Thursday 16 November 2000 18:18, Thomas Marteau wrote: > > > Hi all, > > > > > > [....] > > > Also, in this mail, you have the diff between our hp_keyb.c and the > official > > > one but it gives you the ~ and the ' and others scancodes. > > > [....] > > > > Hi ESIEE-Team ! > > > > Thanks for your patch ! > > > > I committed your patch into CVS and just tweaked it a little for > > CONFIG_MAGIC_SYSRQ. I hope this is ok for you ? > We didn't really understand why pckbd_sysrq_xlate was here for. > If you can explain to us, it will be fine. The best documentation you can find is in linux/Documentation/sysrq.txt. The copy of pckbd_sysrq_xlate[] is a simple implementation of keyboard-scancodes to chars, which is used by drivers/char/keyboard.c to call handle_sysrq() from /drivers/char/sysrq.c. This means, that you can press Alt-PrintScr (=> SysRQ) and a char at the keyboard simultaniously and your machine for example syncs the disks, mounts all discs read-only or reboots your machine immediately. > > If your time permits, I would like to ask, if you maybe also want to look > at > > getting the CAPS-Lock-, Scroll-Lock- & Num-Lock-LED's working ? > Normally, you can see yours leds switching on/off but we did not init them. > So they are like boot admin switch them... ^^^^^^^ ^^^^^ ^^^ Sorry ? > But we would like to know how and where we have to init them > because we know how to. We have made test and it was working... I'm not sure, but I think you should check the code in lasikbd_leds() in hp_psaux.c. The initialization should maybe be done in the same file in the function lasi_ps2_register() before calling register_kbd_ops(). > > > Furthermore you mention in your project-history on your homepage something > > about "keyboard and soundchip problems" (Oct. 24). I'm asking just out of > > curiousity: Did you thought about programming the on-board sound-chips > (which > > I believe would be a hard job.) ? > Yes, it is in our internal todo list, if we have time to. Because we look at > it with Thierry, we saw that, for LASI, > you have an interface and then the chip to configure. But it is very > interesting... Yes it is, and it would be great if you worked on that too ! > > Also, we want to rule the power leds but they are different if the box is > 712 or B132 or ... So our question is how to implement > this kind of initialsation and deinitialisation in a linux kernel and in a > second time, how to do for differents kind of boxes. As far as I know / have heard, there are only two types of LED's (but I may be wrong here !). One is where the LED's are organized in a row on the front panel (as my local machines here), and the other one, where you have (LED/)LCD-Numbers on your front panel ? They differ how to be accessed and where the controlling registers are located. One method to distiguish them is maybe to place the special initialisation code into drivers/gsc/lasi.c and asp.c, depending on the machine and which method needs to be used. Since I don't have any real documentation or knowledge of the programming of the LEDs (beside of the PDC-calls I placed into setup.c), maybe someone else can better comment on that or give some documentation ? > > Thanks for your answers, Helge > Bye, > ESIEE Team Best regards, Helge Deller. From Arnaud.ATOCH@oecd.org Fri, 17 Nov 2000 16:30:42 +0100 Date: Fri, 17 Nov 2000 16:30:42 +0100 From: Arnaud.ATOCH@oecd.org Arnaud.ATOCH@oecd.org Subject: [parisc-linux] Booting 712 with CD 0.5 Is the following output the normal behavior of Linux-PARisc on a 712/100 ? kmem_create: Forcing size word alignment - nfs_fh kernel BUG at pci-dma.c:391! kernel BUG at pci-dma.c:400! kernel BUG at pci-dma.c:391! kernel BUG at pci-dma.c:400! kernel BUG at pci-dma.c:391! kernel BUG at pci-dma.c:400! VFS: Disk change detected on device sr(11,0) kernel BUG at pci-dma.c:391! kernel BUG at pci-dma.c:400! kernel BUG at pci-dma.c:391! kernel BUG at pci-dma.c:400! kernel BUG at pci-dma.c:391! kernel BUG at pci-dma.c:400! ISO 9660 Extensions: RRIP_1991A VFS: Mounted root (iso9660 filesystem) readonly. INIT: version 2.78 booting INIT: Entering runlevel: 2 Setting up /tmp ramdisk4096+0 records in 4096+0 records out mke2fs 1.19, 13-Jul-2000 for EXT2 FS 0.5b, 95/08/09 Filesystem label= OS type: Linux Block size=1024 (log=0) Fragment size=1024 (log=0) 1024 inodes, 4096 blocks 0 blocks (0.00%) reserved for the super user First data block=1 1 block group 8192 blocks per group, 8192 fragments per group 1024 inodes per group Writing inode tables: done Writing superblocks and filesystem accounting information: done INIT: Id "T0" respawni INIT: no more processe From rhirst@linuxcare.com Fri, 17 Nov 2000 15:39:55 +0000 Date: Fri, 17 Nov 2000 15:39:55 +0000 From: Richard Hirst rhirst@linuxcare.com Subject: [parisc-linux] SEGV signal handling bug (dynamic linking) Hi, Don't know if anyone expects this to work yet or not, but: ------------------------- cut ----------------------------- #include #include #include #include #include #include #include #include #include char *mem; void sig_handler(int sig) { int res; printf("Trapped!!!\n"); res = mprotect(mem, 4096, PROT_READ|PROT_WRITE); if (res < 0) { perror("mprotect"); exit(1); } } void install_handlers(void) { struct sigaction act; memset(&act, 0, sizeof(act)); act.sa_handler = sig_handler; sigaction(SIGSEGV, &act, NULL); } int main(int argc, char **argv) { int res; mem = malloc(8192); if (mem == NULL) { perror("malloc"); exit(1); } mem = (char *)(((int)mem + 4095) & ~0x0fff); res = mprotect(mem, 4096, PROT_READ); if (res < 0) { perror("mprotect"); exit(1); } install_handlers(); write(1, "Going\n", 6); mem[24] = 17; write(1, "Gone\n", 5); return 0; } ------------------------- cut ----------------------------- generates: Going Bus error plus the following on the console: do_page_fault() pid=167 command='ch' YZrvWESTHLNXBCVMcbcbcbcbOGFRQPDI PSW: 00000000000001001111111100001011 r0-3 00000000 fffff000 0000166f 00002944 r4-7 40138c38 2001fd8c 00002852 00000001 r8-11 00002862 0008b010 0009c290 0009cbf0 r12-15 00000000 00000000 0009cb50 00000000 r16-19 00000000 00000001 0000b71b 00000011 r20-23 00004000 40041fcc 40041fcc 00000008 r24-27 00000006 00001000 00000001 0000280c r28-31 00000006 00000020 20020140 40041fd7 sr0-4 00000000 00000003 00000000 0000000a sr4-8 0000000a 0000000a 0000000a 0000000a IASQ: 0000000a 0000000a IAOQ: 0000167b 0000167f IIR: 6293002e ISR: 0000000a IOR: 00004017 ORIG_R28: 00002880 !!die_if_kernel: ch(167): Unaligned data reference 28 YZrvWESTHLNXBCVMcbcbcbcbOGFRQPDI PSW: 00000000000011001111111100001011 r0-3 00000000 fffff000 20020140 00002944 r4-7 40138c38 2001fd8c 00002852 00000001 r8-11 00002862 0008b010 0009c290 0009cbf0 r12-15 00000000 00000000 0009cb50 00000000 r16-19 00000000 00000001 0000b71b 00000000 r20-23 0000289f 40041fcc 40041fcc 00000008 r24-27 200201d0 20020150 0000000b 0000280c r28-31 00000006 00000020 200203c0 40041fd7 sr0-4 00000000 00000003 00000000 0000000a sr4-8 0000000a 0000000a 0000000a 0000000a IASQ: 0000000a 0000000a IAOQ: 0000289b 0000289b IIR: 0e801096 ISR: 0000000a IOR: 0000289f ORIG_R28: 00002880 The first do_page_fault() is fine, it is the 'mem[24] = 17' line, but the second isn't. The corresponding code is at the end of .plt: 2898: 0e 80 10 96 ldw 0(sr0,r20),r22 289c: ea c0 c0 00 bv r0(r22) 28a0: 0e 88 10 95 ldw 4(sr0,r20),r21 28a4: ea 9f 1f dd b,l 2898 <__DTOR_END__+0x74>,r20 28a8: d6 80 1c 1e depwi 0,31,2,r20 28ac: 00 c0 ff ee # c0ffee 28b0: de ad be ef #deadbeef However, if I make it statically linked, it works fine, giving: Going Trapped!!! Gone Richard From bri@mojo.calyx.net Fri, 17 Nov 2000 10:49:22 -0500 (EST) Date: Fri, 17 Nov 2000 10:49:22 -0500 (EST) From: Brian S. Julin bri@mojo.calyx.net Subject: [parisc-linux] debian archive beware libpam JFYI to save other people some time. Before firing up "apt-get upgrade" you'll be best off putting a hold on all the libpam packages, as the 0.72-12 version on ftp.us.debian.org fails on a bad symbol in libpam-misc, which locks you out of the box except if you boot single. -- Brian S. Julin From grundler@cup.hp.com Fri, 17 Nov 2000 08:38:24 -0800 Date: Fri, 17 Nov 2000 08:38:24 -0800 From: Grant Grundler grundler@cup.hp.com Subject: [parisc-linux] Booting 712 with CD 0.5 Arnaud.ATOCH@oecd.org wrote: > Is the following output the normal behavior of Linux-PARisc on a 712/100 ? > > kmem_create: Forcing size word alignment - nfs_fh > kernel BUG at pci-dma.c:391! > kernel BUG at pci-dma.c:400! The bug is real. A driver is calling pci_map_single() and pci_unmap_single() without specifying which direction the DMA is going. Cache flushing on 712 (PCXL) systems needs to know. I'll assume it's the SCSI driver since it looks like we are talking to a SCSI CD-ROM. grant Grant Grundler Unix Systems Enablement Lab +1.408.447.7253 From drepper@redhat.com 17 Nov 2000 09:09:10 -0800 Date: 17 Nov 2000 09:09:10 -0800 From: Ulrich Drepper drepper@redhat.com Subject: [parisc-linux] SEGV signal handling bug (dynamic linking) Richard Hirst writes: > mem = malloc(8192); > if (mem == NULL) { > perror("malloc"); > exit(1); > } > mem = (char *)(((int)mem + 4095) & ~0x0fff); > res = mprotect(mem, 4096, PROT_READ); Read the Unix standard: The behavior of this function is unspecified if the mapping was not established by a call to mmap(). -- ---------------. ,-. 1325 Chesapeake Terrace Ulrich Drepper \ ,-------------------' \ Sunnyvale, CA 94089 USA Red Hat `--' drepper at redhat.com `------------------------ From grundler@cup.hp.com Fri, 17 Nov 2000 09:09:04 -0800 (PST) Date: Fri, 17 Nov 2000 09:09:04 -0800 (PST) From: Grant Grundler grundler@cup.hp.com Subject: [parisc-linux] pci-dma.c BUG(391/400) PATCH Hi all, The following patch tries to point a finger at the offender rather than just call attention to a problem in the service. I don't have a PCXL/L2 machine setup right now. Could someone test commit this patch for me? thanks, grant grundler <505>cvs diff arch/parisc/kernel/pci-dma.c Index: arch/parisc/kernel/pci-dma.c =================================================================== RCS file: /home/cvs/parisc/linux/arch/parisc/kernel/pci-dma.c,v retrieving revision 1.16 diff -u -p -r1.16 pci-dma.c --- pci-dma.c 2000/11/08 06:20:27 1.16 +++ pci-dma.c 2000/11/17 17:04:22 @@ -387,8 +387,10 @@ static void pa11_dma_free_consistent (st static dma_addr_t pa11_dma_map_single(struct pci_dev *dev, void *addr, size_t size, int direction) { - if (direction == PCI_DMA_NONE) - BUG(); + if (direction == PCI_DMA_NONE) { + printk(KERN_ERR "pa11_dma_map_single(PCI_DMA_NONE) called by %p\n", __builtin_return_address(0)); + BUG(); + } flush_kernel_dcache_range((unsigned long) addr, size); return virt_to_phys(addr); @@ -396,8 +398,10 @@ static dma_addr_t pa11_dma_map_single(st static void pa11_dma_unmap_single(struct pci_dev *dev, dma_addr_t dma_handle, size_t size, int direction) { - if (direction == PCI_DMA_NONE) - BUG(); + if (direction == PCI_DMA_NONE) { + printk(KERN_ERR "pa11_dma_unmap_single(PCI_DMA_NONE) called by %p\n", __builtin_return_address(0)); + BUG(); + } if (direction == PCI_DMA_TODEVICE) return; From Arnaud.ATOCH@oecd.org Fri, 17 Nov 2000 18:10:52 +0100 Date: Fri, 17 Nov 2000 18:10:52 +0100 From: Arnaud.ATOCH@oecd.org Arnaud.ATOCH@oecd.org Subject: [parisc-linux] Booting 712 with CD 0.5 Thanks for the enlightment. Should I try a new CD-ROM or should I wait untill next ISO image is created ? IS the shutdown also due to this bug ? Setting up /tmp ramdisk4096+0 records in 4096+0 records out mke2fs 1.19, 13-Jul-2000 for EXT2 FS 0.5b, 95/08/09 Filesystem label= OS type: Linux Block size=1024 (log=0) Fragment size=1024 (log=0) 1024 inodes, 4096 blocks 0 blocks (0.00%) reserved for the super user First data block=1 1 block group 8192 blocks per group, 8192 fragments per group 1024 inodes per group Writing inode tables: done Writing superblocks and filesystem accounting information: done INIT: Id "T0" respawni INIT: no more processe -----Original Message----- From: Grant Grundler [mailto:grundler@cup.hp.com] Sent: Friday, November 17, 2000 17:38 To: Arnaud.ATOCH@oecd.org Cc: parisc-linux@puffin.external.hp.com Subject: Re: [parisc-linux] Booting 712 with CD 0.5 Arnaud.ATOCH@oecd.org wrote: > Is the following output the normal behavior of Linux-PARisc on a 712/100 ? > > kmem_create: Forcing size word alignment - nfs_fh > kernel BUG at pci-dma.c:391! > kernel BUG at pci-dma.c:400! The bug is real. A driver is calling pci_map_single() and pci_unmap_single() without specifying which direction the DMA is going. Cache flushing on 712 (PCXL) systems needs to know. I'll assume it's the SCSI driver since it looks like we are talking to a SCSI CD-ROM. grant Grant Grundler Unix Systems Enablement Lab +1.408.447.7253 From rhirst@linuxcare.com Fri, 17 Nov 2000 17:38:18 +0000 Date: Fri, 17 Nov 2000 17:38:18 +0000 From: Richard Hirst rhirst@linuxcare.com Subject: [parisc-linux] SEGV signal handling bug (dynamic linking) On Fri, Nov 17, 2000 at 09:09:10AM -0800, Ulrich Drepper wrote: > Richard Hirst writes: > > > mem = malloc(8192); > > if (mem == NULL) { > > perror("malloc"); > > exit(1); > > } > > mem = (char *)(((int)mem + 4095) & ~0x0fff); > > res = mprotect(mem, 4096, PROT_READ); > > Read the Unix standard: > > The behavior of this function is unspecified if the mapping was not > established by a call to mmap(). Yeh, but it works on m68k and i386, and works on hppa if statically linked. And the code is in an example on the mprotect man page on my Mandrake7 box. Richard From drepper@redhat.com 17 Nov 2000 10:06:21 -0800 Date: 17 Nov 2000 10:06:21 -0800 From: Ulrich Drepper drepper@redhat.com Subject: [parisc-linux] SEGV signal handling bug (dynamic linking) Richard Hirst writes: > Yeh, but it works on m68k and i386, and works on hppa if statically > linked. And the code is in an example on the mprotect man page on > my Mandrake7 box. Then shoot the guy who wrote the man page. It's wrong and will never reliably work. -- ---------------. ,-. 1325 Chesapeake Terrace Ulrich Drepper \ ,-------------------' \ Sunnyvale, CA 94089 USA Red Hat `--' drepper at redhat.com `------------------------ From rhirst@linuxcare.com Fri, 17 Nov 2000 20:10:34 +0000 Date: Fri, 17 Nov 2000 20:10:34 +0000 From: Richard Hirst rhirst@linuxcare.com Subject: [parisc-linux] SEGV signal handling bug (dynamic linking) On Fri, Nov 17, 2000 at 09:09:10AM -0800, Ulrich Drepper wrote: > Richard Hirst writes: > > > mem = malloc(8192); > > if (mem == NULL) { > > perror("malloc"); > > exit(1); > > } > > mem = (char *)(((int)mem + 4095) & ~0x0fff); > > res = mprotect(mem, 4096, PROT_READ); > > Read the Unix standard: > > The behavior of this function is unspecified if the mapping was not > established by a call to mmap(). Changed my prog to use mmap and get the same problem. Richard From grundler@cup.hp.com Fri, 17 Nov 2000 13:50:46 -0800 Date: Fri, 17 Nov 2000 13:50:46 -0800 From: Grant Grundler grundler@cup.hp.com Subject: [parisc-linux] PDC firmware revision FAQ update Hi folks, The issue of PDC/firmware revs came up locally and sounded like a FAQ. I added "10. How can I check if the PDC (firmware) revision is the latest?" and what I knew/could find to our FAQ at: http://www.parisc-linux.org/faq.html The new FAQ entry should be visible to the world in the next hour or so. **** WARNING **** Firmware upgrades can *kill* your machine! **** WARNING **** Don't do it just because. Read the FAQ carefully. Take the time to figure out why you might need the upgrade and expose yourself to this risk. grant ps. please don't ask me why your favorite machine's PDC isn't listed. I don't run the referenced sites. From taggart@carmen.fc.hp.com Fri, 17 Nov 2000 18:26:19 -0700 Date: Fri, 17 Nov 2000 18:26:19 -0700 From: Matt Taggart taggart@carmen.fc.hp.com Subject: [parisc-linux] New cross compiler I have posted new i386/linux -> hppa/linux cross tools at, ftp://puffin.external.hp.com/pub/parisc/binaries/LinuxX86/xc-20001117.tar.gz it includes 32bit and 64bit cross-compilers and a static 32bit glibc 2.2. I have also updated the include tarball, ftp://puffin.external.hp.com/pub/parisc/src/include-20001117.tar.gz it includes glibc 2.2 headers and the latest kernel headers. -- Matt Taggart taggart@fc.hp.com From sandy@storm.ca Fri, 17 Nov 2000 22:54:58 -0500 Date: Fri, 17 Nov 2000 22:54:58 -0500 From: Sandy Harris sandy@storm.ca Subject: [parisc-linux] Host for 712/60 compiles A couple of us have 16 diskless 712/60s which we want to use for distributed processing on easily parallelized tasks like factoring and perhaps crypto cracking. A few questions arise. Is PARISC Linux far enough along to be useful for that? We need no monitor or console (except perhaps for initial debugging), no devices except ethernet, and expect to run only one process per machine, but we need stability. We'll need a host for cross-compiling. We have a 256 meg 715/100 with HP/UX which we expect to use as the host for booting, handing out chunks of work, storing results, etc. Should we compile there under HP/UX or would we get better tools on one of our Intel Linux boxes? Or is PARISC Linux far enough along we should put it on the 715 and get native compilation? From matthew@wil.cx Sat, 18 Nov 2000 07:08:12 +0000 Date: Sat, 18 Nov 2000 07:08:12 +0000 From: Matthew Wilcox matthew@wil.cx Subject: binutils taggart On Wed, Nov 15, 2000 at 05:16:02PM -0700, Matt Taggart wrote: > Modified files: > . : config.guess config.sub > > Log message: > New upstream versions from > http://subversions.gnu.org/cgi-bin/cvsweb/config/ > Now config.guess returns the right thing for hppa-linux so... we needed new versions anyway, even though we're not parisc-linux..? :-) [not bitter, just amused] -- Revolutions do not require corporate support. From matthew@wil.cx Sat, 18 Nov 2000 07:24:54 +0000 Date: Sat, 18 Nov 2000 07:24:54 +0000 From: Matthew Wilcox matthew@wil.cx Subject: [parisc-linux] CVS linux Vs. -test10 On Tue, Nov 14, 2000 at 09:35:01AM -0700, Paul Bame wrote: > > I've attached an overview of differences between our CVS linux sources ok, here's my memories. > * Lots of RCS $Revision$ differences in ACPI (a different 'cvs > import' would've eliminated these differences). i assume someone's already done the appropriate cvs admin -ko magic to fix this? > * drivers/char/Config.in: changes to support LASI, parisc real-time > clock (CONFIG_GENRTC) istr this was `stolen' from the m68k port by sammy. > * drivers/char/serial.c: support for GSC and A500 serial if they're working, send to Ted and he'll do an update with Linus at some point. > * drivers/net/eepro100.c: no clue about this one we were trying to get it to work for the Jan NYLWE show. i doubt we have any changes of note. does anyone have an eepro in an hp? > * drivers/video: STI and HP FB video drivers (iodccon is probably > worthless) agreed on iodccon. unless we're using it up until the point that one of the more advanced consoles takes over? i don't think we are now. > * fs/binfmt_elf.c,exec.c: changes for stack-grows-up? Yes, that's what they're for. > * fs/nfs/read.c: probably unnecessary hack for broken parisc64 gcc we certainly don't want to send it upstream, but we don't want to take it out until the bug is fixed. is fixing that bug on the webshite todo list? > * include/linux/binfmts.h,fs.h,kernel.h,tty.h,udf_fs_sb.h: > unnecessary differences? mostly, yes. > * include/linux/init.h: we use different section names -- why????, > probably some unnecessary other differences too because we use -ffunction-sections. text.init clashes with a function called init, and the linker just merges it into the text segment. we need it to be separate, so it became init.text. there's patches around to do this for other architectures too. just bad naming choices initially. > * include/linux/wait.h: parisc debugging -- should be removed yeah, that can die now. > * scripts/*: MANY differences here. Looks like a combination of > things we hacked to fix configuration problems plus MAYBE not > updating these files from new Linux versions in the past. 'make > menuconfig' is significantly different from upstream. Even the > mkdep.c program is different. ok. mea extremely culpa here. i had an exclude file which included the scripts/ directory. someone should now ditch our stuff, take what's in -test10, hack it till it works for us and check it in. -- Revolutions do not require corporate support. From bzeeb+hplinux@zabbadoz.net Sun, 19 Nov 2000 13:12:25 +0100 (CET) Date: Sun, 19 Nov 2000 13:12:25 +0100 (CET) From: Bjoern A. Zeeb bzeeb+hplinux@zabbadoz.net Subject: [parisc-linux] serial console ? Hi, I just started booting into a 715-100 using palinux-0.5.iso. I did read multiple times that I need serial console. So I plugged in serial cable I an normally using for x86 to x86 serial console on my linux router but I did not get anything on both serial ports :-( What information would one need to help ? personal contact is prefered. I would then sum up all information I got and post it to the list afterwards (if desired). Have to say: I am 'new' to those workstation and had to hoover it first after I got it ;) I also could have a 735-99 with some kind of graphic accelerator if that one would be better. -- Bjoern A. Zeeb bzeeb at Zabbadoz dot NeT 56 69 73 69 74 http://www.zabbadoz.net/ From bzeeb+hplinux@zabbadoz.net Sun, 19 Nov 2000 17:06:11 +0100 (CET) Date: Sun, 19 Nov 2000 17:06:11 +0100 (CET) From: Bjoern A. Zeeb bzeeb+hplinux@zabbadoz.net Subject: [parisc-linux] serial console ? On Sun, 19 Nov 2000, Bjoern A. Zeeb wrote: > I just started booting into a 715-100 using palinux-0.5.iso. > > I did read multiple times that I need serial console. So I plugged in > serial cable I an normally using for x86 to x86 serial console on my > linux router but I did not get anything on both serial ports :-( Hi, sorted out everything. serial cable was quite ok, but using cu I was never able to reach IPL. Using minicom and everything was fine. Had a great success afterwards: installed from CD (palinux-0.5.iso) Everthing worked at once out of the box :-) openssh was enabled on default :-)) only one bad touch: please do not enable portmapper on default. there are too much exploits out there these days. Short: Great great great work !!! -- Bjoern A. Zeeb bzeeb at Zabbadoz dot NeT 56 69 73 69 74 http://www.zabbadoz.net/ From dhazeghi@pacbell.net Sun, 19 Nov 2000 09:24:56 -0800 Date: Sun, 19 Nov 2000 09:24:56 -0800 From: dhazeghi@pacbell.net dhazeghi@pacbell.net Subject: [parisc-linux] glibc-latest tarball broken the glibc-latest tarball on pehc appears to be missing some important subdirectories like scripts and sysdeps. Perhaps a legacy of the 2.2 merge? Thanks, Dara Hazeghi From imatthae@grc.hp.com Sun, 19 Nov 2000 19:35:57 +0100 Date: Sun, 19 Nov 2000 19:35:57 +0100 From: Ingo Matthaes imatthae@grc.hp.com Subject: [parisc-linux] A500 and glibc woes finally we've got a A500 for palinux testing. Unfortunately we have some problems with it. A 32 bit kernel complains about a very old firmware and claims "that machine will probably never run linux" But in fact, it will :-) First question: Did anyone ever succeeded with a 32bit kernel on that hardware ? A 64 bit Kernel boots fine and recognizes all available hardware including the additional 100BT card. But it traps with the init which comes with the latest nfsroot tarball. I built a new one from the sourcesw of debians sysvlinux-2.78 and it does not trap anymore, but the kernel told me about unimplemented 32 syscalls. At this point I tried to build a 64 bit glibc in order to get a crt1.o , which is needed to builf for a 64bit init. Did anyone ever build a 64bit glibc out of the current cvs tree ? Today I've got ologue/epilogue insn (insn 433 431 435 (set (reg:DI 26 %r26) (reg:DI 2 %r2)) -1 (nil) (nil)) ../sysdeps/unix/sysv/linux/init-first.c:105: Unrecognizable insn: (insn 440 438 441 (set (reg:DI 24 %r24) (lo_sum:DI (reg:DI 1 %r1) (symbol_ref:DI ("LP$-001")))) -1 (insn_list 437 (nil)) (expr_list:REG_DEAD (reg:DI 1 %r1) (expr_list:REG_UNUSED (reg:DI 24 %r24) (nil)))) ../sysdeps/unix/sysv/linux/init-first.c:105: Internal compiler error in num_delay_slots, at insn-attrtab.c:2505 Thats the point I'm currently stucking. BTW If someone involved into the port with access to the internal HP Network needs access to that machine, please contact me. Later Ingo -- Tel: ++49-2102-908-210 German Response Center Fax: ++49-2102-907-934 Berliner Str. 111 Mailto: Ingo_Matthaes@hp.com 40880 Ratingen Germany HP Unix/Linux Competency Center Network and High AvailabilitY OpenPGP fingerprint = 4298E7785FFD65DC8950 14E9F17F8CB5B611AA4A From alan@linuxcare.com.au Mon, 20 Nov 2000 14:03:16 +1100 (EST) Date: Mon, 20 Nov 2000 14:03:16 +1100 (EST) From: Alan Modra alan@linuxcare.com.au Subject: Single-stepping On Thu, 16 Nov 2000, John Marvin wrote: > Anyway, for reference, HP-UX does single stepping by using a combination > of the taken branch trap, and loading the instruction queues such that the > front of the queue points to the next instruction to be single stepped and > the back of the queue points to the first of two break instructions on a > "break" page. It does NOT insert break instructions into the code, so it > does not adversely affect execution on a SMP machine. Note that we > already put a bunch of break instructions before the syscall entry point > on the gateway page, so it would be easy to use our gateway page for the > "break page". This way, if the single stepped instruction branches, a > taken branch trap will be taken (which is important in the case where the > branch nullifies its delay slot). Otherwise, the instruction will be > executed and then the break instruction at the known location on the > "break" page will be executed. If the single stepped instruction > nullifies the next instruction, the second break instruction on the > "break" page will be executed. This is the path I started out on for hppa-linux, then hit the problem of a branch that nullifies it's delay slot. At that point, I decided playing with IAOQ_back wouldn't work as I missed the solution of enabling taken branch traps. :-( If I'd seen this trick, then I would not have tried using the recovery counter, and even now, it may be better to go back to IAOQ fiddling. The recovery counter scheme has the disadvantage that there's only one of them so you need to save/restore over task swaps or introduce extra instructions in the syscall path - and be very careful. > Note that this is the short explanation. It is not as simple as it sounds. > One major complication is that branches with links don't work properly > with the instruction queue magic, so the link register has to be updated > in the taken branch trap handler. Also branch externals won't update > the space of the space queue tail properly (again, that has to be fixed > in the taken branch handler). I can provide more details if the recovery > counter method doesn't work out. I'm a little intrigued about these "complications". How can the link register or space _not_ be updated properly? As far as I can see, the only really tricky instruction to single-step is RFI - which shouldn't ever occur in userspace, and which we'd just emulate if it was important. Alan Modra -- Linuxcare. Support for the Revolution. From jsm@udlkern.fc.hp.com Sun, 19 Nov 2000 22:43:02 -0700 (MST) Date: Sun, 19 Nov 2000 22:43:02 -0700 (MST) From: John Marvin jsm@udlkern.fc.hp.com Subject: Single-stepping > > Note that this is the short explanation. It is not as simple as it sounds. > > One major complication is that branches with links don't work properly > > with the instruction queue magic, so the link register has to be updated > > in the taken branch trap handler. Also branch externals won't update > > the space of the space queue tail properly (again, that has to be fixed > > in the taken branch handler). I can provide more details if the recovery > > counter method doesn't work out. > > I'm a little intrigued about these "complications". How can the link > register or space _not_ be updated properly? As far as I can see, the > only really tricky instruction to single-step is RFI - which shouldn't > ever occur in userspace, and which we'd just emulate if it was important. The problem is that the link register is set to IAOQ_Back + 4. and in the case of ble, sr0 is set to IASQ_Back. Since we've played games with the queues, IAOQ_Back and IASQ_Back are pointing at the break page, not at the instruction following the branch. The additional complication is that the taken branch trap traps at the branch destination, not at the branch, so at the point of the trap you don't know where you came from in order to fix the problem easily. So, what HP-UX does is check each instruction before it executes it to see if it is a branch, and if so, what the link register is (and that is all that needs to be parsed, since we are not emulating the instruction). It then stores the branch location, and also sets some branch state flags (e.g. UBE for a branch external, and UBL for a branch with a link, both flags being set for a ble instruction). Then in the taken branch handler you have all the information you need to fix the queue. You also need to check this saved state if a signal handler is invoked while single stepping, so that the proper pc queue values can be saved in the signal context. John Marvin jsm@fc.hp.com From jsm@udlkern.fc.hp.com Sun, 19 Nov 2000 23:01:20 -0700 (MST) Date: Sun, 19 Nov 2000 23:01:20 -0700 (MST) From: John Marvin jsm@udlkern.fc.hp.com Subject: A500 and glibc woes Ingo, > > finally we've got a A500 for palinux testing. Unfortunately > we have some problems with it. > A 32 bit kernel complains about a very old firmware and claims > "that machine will probably never run linux" But in fact, it > will :-) Actually, there are no plans to ever support the A500 on a 32 bit kernel. The A500 only has 64 bit firmware, so in order to support it we would need to write a 32->64 bit firmware translation layer. ... > A 64 bit Kernel boots fine and recognizes all available hardware > including the additional 100BT card. But it traps with the init > which comes with the latest nfsroot tarball. I built a new one > from the sourcesw of debians sysvlinux-2.78 and it does not trap > anymore, but the kernel told me about unimplemented 32 syscalls. > At this point I tried to build a 64 bit glibc in order to get > a crt1.o , which is needed to builf for a 64bit init. > Well, it might seem crazy, but our short term plans do not include supporting a 64 bit user environment on the 64 bit kernel. Long term I believe this will happen, but as you have already seen, work needs to be done to support 64 bit glibc, shared libraries, etc. So, in order to get the A500 to boot, we need to support the 32 bit user environment on a 64 bit kernel. We've only recently gotten to the point where the 64 bit kernel gets far enough to start running user space applications. The problem is that we need to write translations for many system calls, since type sizes (and the structures those types are in) are different between 32 bit and 64 bit (the ugliest case is the ioctl system call). In summary, the A500 currently won't work, but since it is one of the machines that HP has targetted for Linux support, you can be sure that this will change fairly soon. John Marvin jsm@fc.hp.com From grundler@cup.hp.com Sun, 19 Nov 2000 22:47:27 -0800 Date: Sun, 19 Nov 2000 22:47:27 -0800 From: Grant Grundler grundler@cup.hp.com Subject: [parisc-linux] A500 and glibc woes Ingo Matthaes wrote: > finally we've got a A500 for palinux testing. Unfortunately > we have some problems with it. Ingo, uhmm...I'm not surprised. Let me help you understand the A500 and the direction we are going with support on the A500. I'm one of several people working on A500 support. A500 Features (marketing crud - you probably know this): o 16GB of RAM o 2-way 550 MHz PA8600 o 4 PCI-4X slots (3 of which are 1 slot per PCI bus) o all in 2U rack mountable box. Inside is (technical crud): o PCX-W+ o Astro IOMMU (aka SBA. Provides cache-coherent DMA and virtual I/O DMA) o Elroy PCI Host Bus Adapter (aka LBA) o IOSAPIC interrupt controller (integrated in Elroy) o PAT PDC (not legacy) o ^B for service processor access (ie I can reset the machine remotely) > A 32 bit kernel complains about a very old firmware and claims > "that machine will probably never run linux" But in fact, it > will :-) That's right! :^) > First question: Did anyone ever succeeded with a 32bit kernel > on that hardware ? No. Only on *64-bit* kernels. The reason is some of the PAT PDC calls we need are *only* available in wide mode. We could have written narrow<->wide mode translation routines but a 32-bit kernel ignores the A500's best feature - 16GB of RAM. The issue is HP needs good specweb99 numbers to sell these boxes and that requires GB of RAM. The 512MB of RAM that 32-bit kernel currently supports (jsm tells me 3GB or so can be done) won't approach the perf levels which can be acheived with 8 or 16GB. The HPUX specweb team (who just *beat* single CPU TUX specweb99 numbers with HPUX on A500) told me. They have a clue. You are welcome to write those translation routines and then *remove* many the "#ifdef __LP64__" preprocessor directives in arch/parisc/kernel/inventory.c and lba_pci.c. Send me the patch and I'll test/review/commit the changes. > A 64 bit Kernel boots fine and recognizes all available hardware > including the additional 100BT card. But it traps with the init > which comes with the latest nfsroot tarball. There are issues/problems with PCI resource management and I have some code waiting to be tested when I get in tomorrow. But you can be very helpful with user space! Perhaps Paul Bame can be more specific. But basically we don't have all the translation routines in place for 32-bit applications invoking 64-bit kernel syscalls. > I built a new one > from the sourcesw of debians sysvlinux-2.78 and it does not trap > anymore, but the kernel told me about unimplemented 32 syscalls. Right. > At this point I tried to build a 64 bit glibc in order to get > a crt1.o , which is needed to builf for a 64bit init. > > Did anyone ever build a 64bit glibc out of the current cvs tree ? I don't think so. Eventually we wanted to but haven't been able yet. So this great that you are trying! > Today I've got ... Can someone one with a clue about toolchain look at that? I'd be really impressed if someone got a 64-bit userspace built! I can help get kernel working right but don't have a clue about the tools. The 64-bit kernel can be booted on the following class of boxes to about the same point as the A500: o C160/180/200/240/360 o B2000/C3000/J5000/C3600/J5600/J6000 o some D/K/R-class machines The key is the box must have PCX-U (PA8000), PCX-U+ (PA8200), PCX-W (PA8500) or PCX-W+ (PA8600) processor. Look in the HWDB (http://www.parisc-linux.org/hw.html) or in /usr/sam/lib/mo/sched.models (HPUX 11.x) to determine which processor you have. > Thats the point I'm currently stucking. > > BTW If someone involved into the port with access to the internal HP > Network needs access to that machine, please contact me. Ditto. I can arrange access to my A500 as well. External access to some limited number of people could be arranged if demand is justifiable. But given the number of other boxes which can run 64-bit kernel, I hope that's not necessary. Thanks Ingo! grant Grant Grundler Unix Systems Enablement Lab +1.408.447.7253 From alan@linuxcare.com.au Mon, 20 Nov 2000 17:53:18 +1100 (EST) Date: Mon, 20 Nov 2000 17:53:18 +1100 (EST) From: Alan Modra alan@linuxcare.com.au Subject: Single-stepping On Sun, 19 Nov 2000, John Marvin wrote: > > I'm a little intrigued about these "complications". How can the link > > register or space _not_ be updated properly? As far as I can see, the > > only really tricky instruction to single-step is RFI - which shouldn't > > ever occur in userspace, and which we'd just emulate if it was important. > > The problem is that the link register is set to IAOQ_Back + 4. and in > the case of ble, sr0 is set to IASQ_Back. Since we've played games with > the queues, IAOQ_Back and IASQ_Back are pointing at the break page, not > at the instruction following the branch. Ah. That is a little nasty, especially given the effect on signal handlers you mention below. Maybe using the recovery counter isn't such a bad idea after all, especially since the added syscall and task switch overhead can be quite small if the kernel only supports single-step by one instruction. > The additional complication is that the taken branch trap traps at the > branch destination, not at the branch, so at the point of the trap you > don't know where you came from in order to fix the problem easily. So, > what HP-UX does is check each instruction before it executes it to see if > it is a branch, and if so, what the link register is (and that is all that > needs to be parsed, since we are not emulating the instruction). It then > stores the branch location, and also sets some branch state flags (e.g. > UBE for a branch external, and UBL for a branch with a link, both flags > being set for a ble instruction). Then in the taken branch handler you > have all the information you need to fix the queue. You also need > to check this saved state if a signal handler is invoked while single > stepping, so that the proper pc queue values can be saved in the signal > context. Another question for you and/or the list in general: Why does struct pt_regs have an ipsw field? Seems like it currently is unused. Regards, Alan Modra -- Linuxcare. Support for the Revolution. From grundler@cup.hp.com Sun, 19 Nov 2000 23:05:26 -0800 Date: Sun, 19 Nov 2000 23:05:26 -0800 From: Grant Grundler grundler@cup.hp.com Subject: [parisc-linux] Host for 712/60 compiles Sandy Harris wrote: > A couple of us have 16 diskless 712/60s which we want to use for distributed > processing on easily parallelized tasks like factoring and perhaps crypto > cracking. A few questions arise. > > Is PARISC Linux far enough along to be useful for that? We need no monitor or > console (except perhaps for initial debugging), no devices except ethernet, > and expect to run only one process per machine, but we need stability. It's not rock solid. On 712's, it should be pretty good though. > We'll need a host for cross-compiling. We have a 256 meg 715/100 with HP/UX > which we expect to use as the host for booting, handing out chunks of work, > storing results, etc. Should we compile there under HP/UX or would we get > better tools on one of our Intel Linux boxes? I don't think anyone has tried to cross-compile parisc-linux on an HPUX host in quite a while. > Or is PARISC Linux far enough along we should put it on the 715 and get > native compilation? AFAIK, all of the debian packages on the ISO image are built natively. But using a dual P700 linux box would be alot faster. :^) grant Grant Grundler Unix Systems Enablement Lab +1.408.447.7253 From sieler@allegro.com Sun, 19 Nov 2000 23:24:00 -0800 (PST) Date: Sun, 19 Nov 2000 23:24:00 -0800 (PST) From: Stan Sieler sieler@allegro.com Subject: Single-stepping Re: > handlers you mention below. Maybe using the recovery counter isn't such a quite true. > bad idea after all, especially since the added syscall and task switch > overhead can be quite small if the kernel only supports single-step by > one instruction. why the limit? We've used multi-instruction "single step" (oxymoron :) for about 15 years on PA-RISC...no problems, efficient, and *very* useful! -- Stan Sieler sieler@allegro.com www.allegro.com/sieler/wanted/index.html www.sieler.com From grundler@cup.hp.com Sun, 19 Nov 2000 23:44:42 -0800 Date: Sun, 19 Nov 2000 23:44:42 -0800 From: Grant Grundler grundler@cup.hp.com Subject: [parisc-linux] CVS linux Vs. -test10 Matthew Wilcox wrote: > On Tue, Nov 14, 2000 at 09:35:01AM -0700, Paul Bame wrote: > ok, here's my memories. Thanks Matthew! hehe...sounds like someone's getting older. :^) ... > > * drivers/net/eepro100.c: no clue about this one > > we were trying to get it to work for the Jan NYLWE show. I think I did that. IIRC, it's a one-line change to use I/O port space since MMIO wasn't usable without more invasive changes. > i doubt we have any changes of note. does anyone have an eepro in an hp? I have picked nearly 30 i82557/i82558 PCI cards from scrap yard. And maybe a few i82559 even. Did you need one (or two)? :^) FWIW, this is the card/driver which I think was causing misaligned data reference traps. I never had a chance to followup with this though. At the time, I thought it would be *really* fun to show this working to HP's marketing team... > > * fs/nfs/read.c: probably unnecessary hack for broken parisc64 gcc > > we certainly don't want to send it upstream, but we don't want to take it > out until the bug is fixed. is fixing that bug on the webshite todo list? I don't think so. It's possible it's already fixed. Relevant CVS log entry: | revision 1.5 | date: 2000/07/18 03:15:25; author: dhd; state: Exp; lines: +5 -0 | ARGH! When I put in an assertion, NFS stops breaking randomly. I | suspect this is a compiler or binutils problem but I can't see any | clear differences in the generated code. I'll debug it later... This sounds like the hppa64 bug we saw with %r29 getting trashed. But I don't think David was working on hppa64 kernel at the time. I can test 32-bit NFS Root tomorrow w/o assertion if no one else beats me to it. > > * include/linux/init.h: we use different section names -- why????, > > probably some unnecessary other differences too > > because we use -ffunction-sections. text.init clashes with a function > called init, and the linker just merges it into the text segment. we > need it to be separate, so it became init.text. there's patches around > to do this for other architectures too. just bad naming choices initially. We need to resolve this in order to merge upstream. Matthew, any advice on how we should proceed? Or would be easier for you pester Alan Cox and just get it fixed? > > * include/linux/wait.h: parisc debugging -- should be removed > > yeah, that can die now. I'd be happy to fix this by clobbering the current version with what's in linux-2.4.0-test10. But what is the "right" way to revert changes we've made so this doesn't show up in next merge? I'll need to know this in order to revert the fs/nfs/read.c change as well. thanks, grant Grant Grundler Unix Systems Enablement Lab +1.408.447.7253 From milang@tal.org Mon, 20 Nov 2000 10:57:36 +0200 Date: Mon, 20 Nov 2000 10:57:36 +0200 From: Kaj-Michael Lang milang@tal.org Subject: [parisc-linux] Palinux on a 712/60 > Thanks for the reply, Grant. However, the 712s do not have a serial console. Yes it does.. it's just undocumented. Unfortunately I don't have the information here, but I have succesfully changed the console to serial on one of my 712. Kaj-Michael Lang milang@tal.org From alan@linuxcare.com.au Mon, 20 Nov 2000 20:05:58 +1100 (EST) Date: Mon, 20 Nov 2000 20:05:58 +1100 (EST) From: Alan Modra alan@linuxcare.com.au Subject: Single-stepping On Sun, 19 Nov 2000, Stan Sieler wrote: > > bad idea after all, especially since the added syscall and task switch > > overhead can be quite small if the kernel only supports single-step by > > one instruction. > > why the limit? We've used multi-instruction "single step" (oxymoron :) > for about 15 years on PA-RISC...no problems, efficient, and *very* > useful! Because you would then need to save and restore cr0 on task switches (or only allow one task to be single-stepped at a time). That's four instructions and two extra memory accesses per task switch. Which might not seem very much, but at some point somebody will no doubt start caring about pa-linux performance. For a single-step by one, you can simply set cr0 to zero on a task switch, and possibly avoid touching cr0 on a task switch at all with careful attention to various trap handlers. Here's the idea. The tail of syscall_restore (64-bit stuff pruned) will look like the following, with the first three instructions being the added code to support single-step (and also wide/narrow switching for 64-bit) ldi 3,%r20 mtctl $r20,%cr0 /* recovery counter, ptrace single-step */ LDREG TASK_PT_PSW(%r1),%r20 mtctl %r1,%cr30 /* intrhandler okay. */ mfsp %sr3,%r1 /* Get users space id */ mtsp %r1,%sr4 /* Restore sr4 */ mtsp %r1,%sr5 /* Restore sr5 */ mtsp %r1,%sr6 /* Restore sr6 */ depi 3,31,2,%r31 /* ensure return to user mode. */ mtsm %r20 /* restore irq state */ mfctl %cr27,%r20 be 0(%sr3,%r31) /* return to user space */ mtsp %r1,%sr7 /* Restore sr7 */ ptrace will fiddle with TASK_PT_PSW, setting the R bit and clearing the I bit to enable the recovery counter - which will start counting down at the mtsm instruction above, and reach zero on the user-space instruction, so we'll trap after executing one user-space instruction. The task-switch nonsense is to handle the case where we page-fault on the instruction and switch to another task also doing single-stepping. You want to ensure cr0 is zero when we finally get back to the original task. Now it might turn out that having extra instructions in the syscall path is worse than extra code and memory accesses on task switch. If that turns out to be true, then you'll probably get your multi-step ptrace. :-) Alan Modra -- Linuxcare. Support for the Revolution. From M_Wild@tunstall.co.uk Mon, 20 Nov 2000 10:21:32 -0000 Date: Mon, 20 Nov 2000 10:21:32 -0000 From: Mark Wild M_Wild@tunstall.co.uk Subject: [parisc-linux] Upgrading memory on a 710 Hi, I have acquired some 8MB SIMMs suitable for my old 710 workstation and wish to utilise them. I don't have any docs for the 710 and was wondering if anyone could point me in the direction of some. I've looked on the HP website but could only find some for 712s, 720, 730 etc. Alternatively, if anyone knows whether any motherboard links need to be changed, whether SIMMS need to be added in pairs / quads and which memory configurations are allowed I would be grateful. Thanks, Mark Wild -- From matthew@wil.cx Mon, 20 Nov 2000 10:50:57 +0000 Date: Mon, 20 Nov 2000 10:50:57 +0000 From: Matthew Wilcox matthew@wil.cx Subject: [parisc-linux] A500 and glibc woes On Sun, Nov 19, 2000 at 07:35:57PM +0100, Ingo Matthaes wrote: > finally we've got a A500 for palinux testing. Unfortunately > we have some problems with it. > A 32 bit kernel complains about a very old firmware and claims > "that machine will probably never run linux" But in fact, it > will :-) > First question: Did anyone ever succeeded with a 32bit kernel > on that hardware ? It's not intended to work; I doubt anyone has tried. You should build a 64 bit kernel. > A 64 bit Kernel boots fine and recognizes all available hardware > including the additional 100BT card. But it traps with the init > which comes with the latest nfsroot tarball. I built a new one > from the sourcesw of debians sysvlinux-2.78 and it does not trap > anymore, but the kernel told me about unimplemented 32 syscalls. > At this point I tried to build a 64 bit glibc in order to get > a crt1.o , which is needed to builf for a 64bit init. Don't try a 64-bit userland yet. What you need to do is implement some of the 32-bit syscalls. -- Revolutions do not require corporate support. From matthew@wil.cx Mon, 20 Nov 2000 11:17:26 +0000 Date: Mon, 20 Nov 2000 11:17:26 +0000 From: Matthew Wilcox matthew@wil.cx Subject: [parisc-linux] CVS linux Vs. -test10 On Sun, Nov 19, 2000 at 11:44:42PM -0800, Grant Grundler wrote: > Matthew Wilcox wrote: > > On Tue, Nov 14, 2000 at 09:35:01AM -0700, Paul Bame wrote: > > ok, here's my memories. > > Thanks Matthew! > > hehe...sounds like someone's getting older. :^) ... when i were a lad, all this were fields! Our dad used to kill us every morning, we'd get up half an hour before we went to bed and walk uphill both to and from school... > ... > > > * drivers/net/eepro100.c: no clue about this one > > > > we were trying to get it to work for the Jan NYLWE show. > > I think I did that. IIRC, it's a one-line change to use I/O port > space since MMIO wasn't usable without more invasive changes. sounds right. MMIO should work now though, right? > > i doubt we have any changes of note. does anyone have an eepro in an hp? > > I have picked nearly 30 i82557/i82558 PCI cards from scrap yard. > And maybe a few i82559 even. Did you need one (or two)? :^) Heh, I only have a 712 right now :-) > FWIW, this is the card/driver which I think was causing misaligned > data reference traps. I never had a chance to followup with this though. > At the time, I thought it would be *really* fun to show this working > to HP's marketing team... Oh yes, I remember that now. Tulip always does a copy (well, it doesn't _have_ to, but we tell it to, just like the Alpha does). > > > * fs/nfs/read.c: probably unnecessary hack for broken parisc64 gcc > > > > we certainly don't want to send it upstream, but we don't want to take it > > out until the bug is fixed. is fixing that bug on the webshite todo list? > > I don't think so. It's possible it's already fixed. > > Relevant CVS log entry: > | revision 1.5 > | date: 2000/07/18 03:15:25; author: dhd; state: Exp; lines: +5 -0 > | ARGH! When I put in an assertion, NFS stops breaking randomly. I > | suspect this is a compiler or binutils problem but I can't see any > | clear differences in the generated code. I'll debug it later... > > This sounds like the hppa64 bug we saw with %r29 getting trashed. > But I don't think David was working on hppa64 kernel at the time. > I can test 32-bit NFS Root tomorrow w/o assertion if no one else > beats me to it. it was definitely a 32-bit kernel at the time. It might be the same bug, but I'm not sure. > > > * include/linux/init.h: we use different section names -- why????, > > > probably some unnecessary other differences too > > > > because we use -ffunction-sections. text.init clashes with a function > > called init, and the linker just merges it into the text segment. we > > need it to be separate, so it became init.text. there's patches around > > to do this for other architectures too. just bad naming choices initially. > > We need to resolve this in order to merge upstream. > Matthew, any advice on how we should proceed? > Or would be easier for you pester Alan Cox and just get it fixed? Hm. Alan's not hacking on 2.4, last I heard. I might pester Linus and see if we can change that. It's a mechanical change so he might not be averse to it at this point. Bear in mind we don't need to do a complete merge at this point -- most architectures have a separate patch to apply on top of Linus' tree. > > > * include/linux/wait.h: parisc debugging -- should be removed > > > > yeah, that can die now. > > I'd be happy to fix this by clobbering the current version with what's in > linux-2.4.0-test10. But what is the "right" way to revert changes we've made > so this doesn't show up in next merge? I don't know that there's an official way to do this. I always changed the file to its previous state and then committed it. There are a number of ways of doing it; perhaps the cleanest is: cvs diff -r1.4 -r1.5 fs/nfs/read.c >../read.c.diff (then check the read.c.diff file) patch -p1 <../read.c.diff rm ../read.c.diff or you can just delete the lines yourself. Use diff to make sure there aren't any silly cosmetic changes (eg whitespace). -- Revolutions do not require corporate support. From grundler@cup.hp.com Mon, 20 Nov 2000 09:34:31 -0800 Date: Mon, 20 Nov 2000 09:34:31 -0800 From: Grant Grundler grundler@cup.hp.com Subject: [parisc-linux] CVS linux Vs. -test10 Matthew Wilcox wrote: ... > sounds right. MMIO should work now though, right? It would have worked then too. Changing it to use MMIO space would require disabling I/O Port space by defining inb/outb locally to use gsc_readb/writeb. My problem with doing that was the semantics are slightly different. I/O Port space is non-postable and MMIO space is. I wasn't confident a driver written to use I/O port space would work right under MMIO though some certainly do. ... > it was definitely a 32-bit kernel at the time. It might be the same bug, > but I'm not sure. Can't be. AP (%r29) is a 64-bit only construct. dhd also just confirmed it was 32-bit kernel. I'll try it now. ... > > We need to resolve this in order to merge upstream. > > Matthew, any advice on how we should proceed? > > Or would be easier for you pester Alan Cox and just get it fixed? > > Hm. Alan's not hacking on 2.4, last I heard. I might pester Linus and > see if we can change that. It's a mechanical change so he might not be > averse to it at this point. Bear in mind we don't need to do a complete > merge at this point -- most architectures have a separate patch to apply > on top of Linus' tree. Ok. What's the first step to getting arch/parisc* and include/asm-parisc* into Linus's tree? I had dinner with Bdale Garbee last night and one of two things he made clear was we need to unfork from debian and linus's tree in order to move forward. All our CVS branches need to become obsolete or "local sandboxes" of the respective upstream partners. Feeding kernel bits upstream will bring a new level of visibility (and *HELP*) to the parisc-linux port. I totally agree with Bdale. I understand alot of work still needs to happen in our tree (eg though sba_iommu.c works, it's current form sucks) But pushing bits upstream to linus will not preclude us from doing that work. I also find it odd that glibc is merged upstream *before* the kernel is. For the record, the second issue bdale made clear was we need "boot floppies" debian package working. We don't need more ISO images (no offense to pjlahaie for his good work). "Boot floppies" is a pre-requisite to becoming part of the next debian release. Given I still don't have a clue how to build a debian package and I can still contribute alot in other areas, it doesn't make sense for me to do it myself. > > I'd be happy to fix this by clobbering the current version with what's in > > linux-2.4.0-test10. But what is the "right" way to revert changes we've made > > so this doesn't show up in next merge? > > I don't know that there's an official way to do this. I always changed > the file to its previous state and then committed it. There are a number of > ways of doing it; perhaps the cleanest is: > > cvs diff -r1.4 -r1.5 fs/nfs/read.c >../read.c.diff > (then check the read.c.diff file) > patch -p1 <../read.c.diff > rm ../read.c.diff > > or you can just delete the lines yourself. Use diff to make sure there > aren't any silly cosmetic changes (eg whitespace). The part you described above is the easy part - np. I'm worried about labels and tracking how we "name" the releases. Mang or other CVS ninja's care to comment? thanks, grant Grant Grundler Unix Systems Enablement Lab +1.408.447.7253 From rhirst@linuxcare.com Mon, 20 Nov 2000 17:58:38 +0000 Date: Mon, 20 Nov 2000 17:58:38 +0000 From: Richard Hirst rhirst@linuxcare.com Subject: [parisc-linux] signal handling problems (32 bit kernel) Hi, Following on from my problems with SEGV last week, I've come up with a few signal handling issues: ============================================================= parisc:signal.c /* Possibly bogus. */ #warning XXX FIXME probably bogus -PB /* I think this is bogus -- it'll cause the first instn of the * signal handler to be executed twice! Better might be to * set iaoq[0] to one of the NOPs in the trampoline. -PB */ regs->iaoq[0] = (unsigned long) haddr | 3; regs->iaoq[1] = (unsigned long) haddr | 3; This causes real problems if the signal handler is a dynamic object which has not yet been resolved; in that case the signal handler points at the b,l instr in the following at the end of the .plt: 2700: 0e 80 10 96 ldw 0(sr0,r20),r22 2704: ea c0 c0 00 bv r0(r22) 2708: 0e 88 10 95 ldw 4(sr0,r20),r21 270c: ea 9f 1f dd b,l 2700 <__DTOR_END__+0x54>,r20 2710: d6 80 1c 1e depwi 0,31,2,r20 typically that results in a misalligned access on the first ldw as r20 is screwed. I've fixed that by setting iaoq[1] = iaoq[0]+4. Is that OK, or should we use the NOP approach in the comment above? ============================================================= If a program gets a SEGV, fixes the cause of it in its signal handler, and returns, then the faulting instruction is not rerun. I think that's wrong (differs from m68k anyway). ============================================================= Set the following program running: #include #include #include #include int v[8]; void (* fp)(int); void sig_handler(int sig) { } void poke(int i) { v[0] = i; v[1] = i; v[2] = i; v[3] = i; v[4] = i; v[5] = i; v[6] = i; v[7] = i; } int main() { int j, i = 0; struct sigaction act; memset(&act, 0, sizeof(act)); act.sa_handler = sig_handler; sigaction(SIGUSR1, &act, NULL); fp = sig_handler; fp(0); printf("I am %d\n", getpid()); while (1) { poke (++i); j = v[7]; if (j != i) printf("Wah!\n"); } } and then in another terminal do 'kill -USR1 '. The program either goes 'Wah!', gives a SEGV, or works. That seems to be because %r1 is corrupted while processing the signal. The signal handler ends with a syscall (rt_sigreturn_wrapper), and %r1, at least, is not saved and restored over the syscall. %r31 also appears to get corrupted, as it is used in the final branch of the syscall return. Richard From sieler@allegro.com Mon, 20 Nov 2000 10:47:38 -0800 (PST) Date: Mon, 20 Nov 2000 10:47:38 -0800 (PST) From: Stan Sieler sieler@allegro.com Subject: Single-stepping Re: > Because you would then need to save and restore cr0 on task switches (or > only allow one task to be single-stepped at a time). That's four > instructions and two extra memory accesses per task switch. Which might > not seem very much, but at some point somebody will no doubt start caring > about pa-linux performance. And it still won't seem like much, then! Non-memory-access instructions are cheap. An extra memory reference (from something probably already in cache) and two extra instructions would probably cost less than an hour per CPU over the next 10 *years*, assuming 10 years of 1000 task switches per second on a slow 100 MHz CPU. Of course, at the cost of an extra non-memory-referencing instruction or so, you could say "at switch-to-task time: if PSW R-bit set, then load the saved CR0 from memory and move it to CR0", saving one memory reference 99.99999% of the time, resuling in an average of only one memory reference per task switch normally. I haven't look at interrupt handling / system calls closely, but I hope there aren't other false savings. (E.g., failure to save/restore the PID check flag ... sure, user processes *now* probably never have pid checking disabled, but that's a very useful feature to have available (with proper security controls, of course).) (Yes, I'm one of the very few who use that feature on MPE/iX ... carefully, of course :) -- Stan Sieler sieler@allegro.com www.allegro.com/sieler/wanted/index.html www.sieler.com From grundler@cup.hp.com Mon, 20 Nov 2000 11:23:40 -0800 Date: Mon, 20 Nov 2000 11:23:40 -0800 From: Grant Grundler grundler@cup.hp.com Subject: [parisc-linux] CVS linux Vs. -test10 Matthew Wilcox wrote: ... > > * fs/nfs/read.c: probably unnecessary hack for broken parisc64 gcc > > we certainly don't want to send it upstream, but we don't want to take it > out until the bug is fixed. is fixing that bug on the webshite todo list? It's fixed. I was able to NFS boot my A180 and install palinux-0.5.iso bits on the SCSI disk. I've reverted the change to the LINUS_240_TEST10 version. > > * include/linux/wait.h: parisc debugging -- should be removed > > yeah, that can die now. Is anyone else already doing this? thanks, grant Grant Grundler Unix Systems Enablement Lab +1.408.447.7253 From herrold@owlriver.com Mon, 20 Nov 2000 15:40:24 -0500 (EST) Date: Mon, 20 Nov 2000 15:40:24 -0500 (EST) From: herrold herrold@owlriver.com Subject: Serial vs. STI console selector was: Re: [parisc-linux] Beta CD On Tue, 14 Nov 2000, Paul J.Y. Lahaie wrote: > This is to answer all the questions about sti console. Currently, in the > CVS tree, serial console and STI console cannot be turned on at the same time. > > This means that a choice between serial/sti needs to be done at compile > time. > If you have any more questions or suggestions, feel free to email me or > post on this list. Thank you. ... Query -- Background: Back in the early 70's with a HP 8090 , IBM 1401, IBM 1620, and IBM 360/40, we faced such issues (Don't ask my age, please) -- The solution was to probe for, and look for 'sense switches' in unusual state -- that is -- Some condition which we could examine, and yet not hose up the boot proces on the host. -- CapsLock set on a keyboard driver -- DSR on a serial line, a 'console sense switch' normally kept off but turned on ... so on. Sort of like working through a qualitative analysis flowchart in non-organic chemistry. Is this possible, to allow support of both, with a single kernel? -- Russ From grundler@cup.hp.com Mon, 20 Nov 2000 12:59:41 -0800 Date: Mon, 20 Nov 2000 12:59:41 -0800 From: Grant Grundler grundler@cup.hp.com Subject: Serial vs. STI console selector was: Re: [parisc-linux] Beta CD "Russ" herrold wrote: > Is this possible, to allow support of both, with a single kernel? Yes. I think the issues are code not stomping on each other. And it's easy than you might think - PDC can tell us what the primary console is. grant Grant Grundler Unix Systems Enablement Lab +1.408.447.7253 From grundler@cup.hp.com Mon, 20 Nov 2000 17:19:03 -0800 (PST) Date: Mon, 20 Nov 2000 17:19:03 -0800 (PST) From: Grant Grundler grundler@cup.hp.com Subject: [parisc-linux] 712 ISL and palo Hi Paul (Bame), I tried booting 712 with "bo scsi.4.0 isl" with the palinux-0.5.iso image on a regular hard disk. I wanted to edit the "root" parameter so it would be /dev/sdb (also had a disk at scsi.0.0) instead of /dev/scd0. palo wouldn't accept any ps/2 keyboard input. Don't know if this is a palo or PDC bug. Any ideas? thanks, grant From alan@linuxcare.com.au Tue, 21 Nov 2000 12:55:42 +1100 (EST) Date: Tue, 21 Nov 2000 12:55:42 +1100 (EST) From: Alan Modra alan@linuxcare.com.au Subject: A DT_INIT/DT_FINI glibc patch. On Thu, 16 Nov 2000, H . J . Lu wrote: > While we are on this subject, I looked at the hppa code. It seems to > have the same bug. I have an impression that HP never really used > DT_INIT/DT_FINI. They use DT_INIT_ARRAY/DT_FINI_ARRAY. I don't know > if we should fix hppa also. Yes to all of these comments. elf32-hppa stole some ideas from ia64, which is why the bug is common. Fortunately, I think hppa ld.so etc. can be fixed in a way such that current (broken ABI) binaries will still work. Alan Modra -- Linuxcare. Support for the Revolution. From taggart@carmen.fc.hp.com Mon, 20 Nov 2000 20:12:33 -0700 Date: Mon, 20 Nov 2000 20:12:33 -0700 From: Matt Taggart taggart@carmen.fc.hp.com Subject: [parisc-linux] glibc-latest tarball broken dhazeghi@pacbell.net writes... > the glibc-latest tarball on pehc appears to be missing some important > subdirectories like scripts and sysdeps. Perhaps a legacy of the 2.2 > merge? Disk space problem. I made some room and generated new tarballs. Thanks for pointing out the problem. -- Matt Taggart taggart@fc.hp.com From alan@linuxcare.com.au Tue, 21 Nov 2000 14:22:53 +1100 (EST) Date: Tue, 21 Nov 2000 14:22:53 +1100 (EST) From: Alan Modra alan@linuxcare.com.au Subject: A DT_INIT/DT_FINI glibc patch. On Mon, 20 Nov 2000, Grant Grundler wrote: > I'm afraid we will break binary compatibility for elf32 hppa-linux again. > I only raise this in case there is really a "right" way to fix the > DT_INIT/DT_FINI problem. The fix involves pruning out all the special handling in bfd/elf32-hppa.c for DT_INIT,DT_FINI, and making some small changes to glibc. H.J. Lu has already made the necessary framework changes, and all we need to do is something like #define DL_FUNCTION_ADDRESS(map, addr) _dl_start_address (map, addr) #define DL_DT_INIT_ADDRESS(map, addr) \ ((addr) & 2 ? (addr) : DL_FUNCTION_ADDRESS (map, addr)) with similar defines for DT_FINI. The test for (addr) & 2 is the fairly innocuous fudge to support old binaries. Another glibc issue (which is why I'm sending this back to the list) is that there has been quite some discussion on the binutils list over the use of the EI_OSABI field. The conclusion being that it isn't really correct to use this field to discern the intendend execution platform. It's purpose is really to tell ELF tools that a file contains fields and values that need to be interpreted in a non-standard way. Since both elf32-hppa and elf64-hppa follow the standards, I'm inclined to think that the gnu tools should set EI_OSABI to zero for both HPUX and Linux targets. Instead the .note.ABI-tag section should be examined to determine the target, which sadly isn't set correctly at the moment. :-( Alan Modra -- Linuxcare. Support for the Revolution. From bame@riverrock.org Mon, 20 Nov 2000 21:02:40 -0700 Date: Mon, 20 Nov 2000 21:02:40 -0700 From: bame@riverrock.org bame@riverrock.org Subject: [parisc-linux] 712 ISL and palo = palo wouldn't accept any ps/2 keyboard input. = Don't know if this is a palo or PDC bug. = Any ideas? PALO bug. I didn't test the PS/2 case but I think I fixed it. -P From alan@linuxcare.com.au Tue, 21 Nov 2000 15:38:57 +1100 (EST) Date: Tue, 21 Nov 2000 15:38:57 +1100 (EST) From: Alan Modra alan@linuxcare.com.au Subject: A DT_INIT/DT_FINI glibc patch. On Tue, 21 Nov 2000, I wrote: > Instead the .note.ABI-tag section should be examined to determine the > target, which sadly isn't set correctly at the moment. :-( Actually, it is set correctly. A comment in csu/abi-note.S was wrong. -- Linuxcare. Support for the Revolution. From jsm@udlkern.fc.hp.com Mon, 20 Nov 2000 22:47:41 -0700 (MST) Date: Mon, 20 Nov 2000 22:47:41 -0700 (MST) From: John Marvin jsm@udlkern.fc.hp.com Subject: [parisc-linux] Use of the EI_OSABI field > Another glibc issue (which is why I'm sending this back to the list) is > that there has been quite some discussion on the binutils list over the > use of the EI_OSABI field. The conclusion being that it isn't really > correct to use this field to discern the intendend execution platform. > It's purpose is really to tell ELF tools that a file contains fields and > values that need to be interpreted in a non-standard way. Since both > elf32-hppa and elf64-hppa follow the standards, I'm inclined to think that > the gnu tools should set EI_OSABI to zero for both HPUX and Linux targets. I don't read the binutils mailing list, so I checked the archive. In my opinion I didn't see a discussion, I saw H.J. Lu repeatedly asserting this "fact". He may or may not be correct about original intention, but the implementation so far has been that EI_OSABI is used to tell what the target platform is. That is what FreeBSD is doing, that is what HP-UX is doing, and that is what the IA-64 Unix System V Application Binary Interface specifies: http://developer.intel.com/design/IA-64/Downloads/24537002.pdf Note that the second paragraph in section 1.1 of that specification includes the following: This document is the result of consensus among operating system vendors intending to provide UNIX and UNIX workalike operating systems on the IA-64 architecture. The vendors participating in this effort include Intel, Sun Microsystems, SCO, IBM, SGI, Cygnus Solutions, VA Linux Systems, HP, and Compaq. So, If the specification is wrong according to H.J. Lu, why did both Cygnus and VA Linux Systems not object to this: Section 4.1.1.4 Operating System Identification The e_ident[EI_OSABI] value identifies the operating system and ABI to which the object is targeted, as listed in Table 4-1. Table 4-1 lists the various ELFOSABI_* fields, e.g. ELFOSABI_HPUX, ELFOSABI_NETBSD, ELFOSABI_LINUX, etc. Note also, that the current mechanism for us to be able to differentiate elf executables in the Linux kernel is the machine dependent elf_check_arch() macro, whose only argument is a pointer to a elf32_hdr or elf64_hdr. I think it would be ugly to try to get the .note.ABI-tag section first for every exec of a new binary in order to determine what the target ABI is. In my opinion, unless H.J. Lu can get the IA-64 ABI changed, it is too late to assert his view of what that field was supposed to be. Please leave the EI_OSABI field set to ELFOSABI_LINUX until a better consensus on this issue is reached. John Marvin jsm@fc.hp.com From alan@linuxcare.com.au Tue, 21 Nov 2000 18:05:36 +1100 (EST) Date: Tue, 21 Nov 2000 18:05:36 +1100 (EST) From: Alan Modra alan@linuxcare.com.au Subject: [parisc-linux] signal handling problems (32 bit kernel) On Mon, 20 Nov 2000, Richard Hirst wrote: > #warning XXX FIXME probably bogus -PB > /* I think this is bogus -- it'll cause the first instn of the > * signal handler to be executed twice! Better might be to Definitely bogus, as with quite a lot of iaoq manipulation in signal.c > I've fixed that by setting iaoq[1] = iaoq[0]+4. Is that OK, or Sounds like the right thing to do. I reckon everywhere ioaq is fudged from/to r31 should have this sort of mapping. ie. it should be regs->gr[31] = regs->iaoq[0]; in sys_rt_sigreturn, and err |= __put_user(regs->gr[31], &sc->sc_iaoq[0]); err |= __put_user(regs->gr[31] + 4, &sc->sc_iaoq[1]); in setup_sigcontext, and so on. I'm guessing the origial author of this code didn't know which of iaoq[0] and ioaq[1] was ioaq_front. :) > and then in another terminal do 'kill -USR1 '. The program > either goes 'Wah!', gives a SEGV, or works. That seems to be because > %r1 is corrupted while processing the signal. The signal handler ends > with a syscall (rt_sigreturn_wrapper), and %r1, at least, is not saved > and restored over the syscall. %r31 also appears to get corrupted, as > it is used in the final branch of the syscall return. I don't really understand what is going on here, but it seems wrong to me that setup_rt_frame should be touching regs->iaoq at all when in_syscall. Hmm, and in that case why all the other gr[31] to/from ioaq[] fudgery? Alan -- Linuxcare. Support for the Revolution. From rhirst@linuxcare.com Tue, 21 Nov 2000 09:34:42 +0000 Date: Tue, 21 Nov 2000 09:34:42 +0000 From: Richard Hirst rhirst@linuxcare.com Subject: [parisc-linux] signal handling problems (32 bit kernel) On Tue, Nov 21, 2000 at 06:05:36PM +1100, Alan Modra wrote: > On Mon, 20 Nov 2000, Richard Hirst wrote: > > > #warning XXX FIXME probably bogus -PB > > /* I think this is bogus -- it'll cause the first instn of the > > * signal handler to be executed twice! Better might be to > > Definitely bogus, as with quite a lot of iaoq manipulation in signal.c As another example, if a process gets a signal as it is about to execute the instr in the delay slot of a branch, it forgets that it was supposed to be branching on return from the signal handler. Try compiling the following and sending it a SIGUSR1: #include #include #include #include void sig_handler(int sig) { } int main() { struct sigaction act; int i = 1; memset(&act, 0, sizeof(act)); act.sa_handler = sig_handler; sigaction(SIGUSR1, &act, NULL); printf("I am %d\n", getpid()); while (i++) ; printf("Escaped, i=%d!\n", i); return 0; } Oh, you have to run it with "LD_BIND_NOW=1 " to avoid one of the other problems. Time to try and work out what signal.c is really trying to do, I guess. Richard From alan@linuxcare.com.au Tue, 21 Nov 2000 22:26:14 +1100 (EST) Date: Tue, 21 Nov 2000 22:26:14 +1100 (EST) From: Alan Modra alan@linuxcare.com.au Subject: [parisc-linux] signal handling problems (32 bit kernel) On Tue, 21 Nov 2000, Richard Hirst wrote: > Time to try and work out what signal.c is really trying to do, I guess. Maybe you should start by considering all the possible states a task can be in when a signal is delivered, in regards to saved registers and stack layout. It would be a _very_ good idea to formalize this once you've sorted it out by splitting up struct pt_regs appropriately. ie. as other architectures do, into struct pt_regs and struct switch_stack. Actually, parisc could go one further and have three structures, one corresponding to registers saved on syscall entry (new pt_regs), one corresponding to macro callee_save (switch_stack), and one corresponding more or less to macro save_specials. Quite a bit of work, but IMO well worth doing. Alan Modra -- Linuxcare. Support for the Revolution. From matthew@wil.cx Tue, 21 Nov 2000 11:34:32 +0000 Date: Tue, 21 Nov 2000 11:34:32 +0000 From: Matthew Wilcox matthew@wil.cx Subject: [parisc-linux] CVS linux Vs. -test10 On Mon, Nov 20, 2000 at 09:34:31AM -0800, Grant Grundler wrote: > Ok. What's the first step to getting arch/parisc* and include/asm-parisc* > into Linus's tree? Someone (probably me) sends him a patch. He told me at the Toronto show that he was quite happy to apply anything that only touched those two directories. (oh, and drivers/gsc wouldn't be a problem either). Can I just check that no-one wants to rename drivers/gsc again? :-) > I had dinner with Bdale Garbee last night and one of two things he made > clear was we need to unfork from debian and linus's tree in order to move > forward. All our CVS branches need to become obsolete or "local sandboxes" > of the respective upstream partners. Feeding kernel bits upstream will > bring a new level of visibility (and *HELP*) to the parisc-linux port. that's true. last time we discussed this several people were unhappy with the idea of sending our current work to Linus. Is anyone unhappy with doing this now? > I also find it odd that glibc is merged upstream *before* the kernel is. glibc is more portable :-) > The part you described above is the easy part - np. > I'm worried about labels and tracking how we "name" the releases. > Mang or other CVS ninja's care to comment? don't tag it. just commit it. tags are laid down at big events, not when you fix bugs or undo changes. -- Revolutions do not require corporate support. From jsm@udlkern.fc.hp.com Tue, 21 Nov 2000 06:11:29 -0700 (MST) Date: Tue, 21 Nov 2000 06:11:29 -0700 (MST) From: John Marvin jsm@udlkern.fc.hp.com Subject: CVS linux Vs. -test10 > > I had dinner with Bdale Garbee last night and one of two things he made > > clear was we need to unfork from debian and linus's tree in order to move > > forward. All our CVS branches need to become obsolete or "local sandboxes" > > of the respective upstream partners. Feeding kernel bits upstream will > > bring a new level of visibility (and *HELP*) to the parisc-linux port. > > that's true. last time we discussed this several people were unhappy > with the idea of sending our current work to Linus. Is anyone unhappy > with doing this now? > Are we suggesting that we populate include/asm-parisc* and arch/parisc* WITHOUT the machine independent changes in the rest of the tree? If that is the case, I guess I don't object, although I would want to make sure that Linus knew the state of the code, and that it would not work without a patch containing changes to the machine independent part, and that followup patches to these branches are likely to be huge. We should also add a README in arch/parisc that explains the above (and where to get patches, how to access CVS, etc.). We also need someone to set up an automatic nightly? patch generator. I certainly don't want to try to get the machine independent changes in yet, since we still have some major issues to fix/clean there, and I doubt Linus would want them at this time anyway. John Marvin jsm@fc.hp.com From rhirst@linuxcare.com Tue, 21 Nov 2000 16:54:42 +0000 Date: Tue, 21 Nov 2000 16:54:42 +0000 From: Richard Hirst rhirst@linuxcare.com Subject: [parisc-linux] signal handling problems (32 bit kernel) On Tue, Nov 21, 2000 at 06:05:36PM +1100, Alan Modra wrote: > > and then in another terminal do 'kill -USR1 '. The program > > either goes 'Wah!', gives a SEGV, or works. That seems to be because > > %r1 is corrupted while processing the signal. The signal handler ends > > with a syscall (rt_sigreturn_wrapper), and %r1, at least, is not saved > > and restored over the syscall. %r31 also appears to get corrupted, as > > it is used in the final branch of the syscall return. > > I don't really understand what is going on here, but it seems wrong to me > that setup_rt_frame should be touching regs->iaoq at all when in_syscall. Problem is that whenever a signal handler is invoked, it is followed by a sys_rt_sigreturn syscall (invoked via the trampoline code), before returning to original usercode. I can imagine that this might work if the process in question was blocked on a syscall, but not if it was suspended due to an interrupt. In either case the path back to the original user code is the syscall return path, and that obviously cannot put things back as they were if the process was interrupted. I think the answer is for syscall_do_signal to save enough in the pt_regs such that sys_rt_sigreturn_wrapper can return to userland via an RFI (like intr_restore, but remembering to trace the syscall exit if necessary) regardless of the process state when the signal occurred. Richard From taggart@carmen.fc.hp.com Tue, 21 Nov 2000 10:20:35 -0700 Date: Tue, 21 Nov 2000 10:20:35 -0700 From: Matt Taggart taggart@carmen.fc.hp.com Subject: [parisc-linux] kernel BUG at sched.c:692! I arrived this morning to discover both my B160 and my C3000 were printing the following as fast as they could, Scheduling in interrupt kernel BUG at sched.c:692! Looking at linux/kernel/sched.c here's the relevant section, 690 scheduling_in_interrupt: 691 printk("Scheduling in interrupt\n"); 692 BUG(); 693 return; scheduling_in_interrupt is called from line 516. Here's some context, 500 asmlinkage void schedule(void) 501 { 502 struct schedule_data * sched_data; 503 struct task_struct *prev, *next, *p; 504 struct list_head *tmp; 505 int this_cpu, c; 506 507 if (!current->active_mm) BUG(); 508 if (tq_scheduler) 509 goto handle_tq_scheduler; 510 tq_scheduler_back: 511 512 prev = current; 513 this_cpu = prev->processor; 514 515 if (in_interrupt()) 516 goto scheduling_in_interrupt; 517 518 release_kernel_lock(prev, this_cpu); I thought it was odd that both systems chose to freak out last night when I have never seen this problem on either of them. The B160 is running a slightly newer kernel and had been up for about 3 days as of last night. The C3K had been up for 4-5 days. When I left last night the B160 was doing a build although the it looks like the build died before this problem occurred. The C3K was idle. Any ideas? Thanks, -- Matt Taggart taggart@fc.hp.com From robert.reilly@gecapital.com Tue, 21 Nov 2000 18:26:41 GMT Date: Tue, 21 Nov 2000 18:26:41 GMT From: Robert Reilly robert.reilly@gecapital.com Subject: [parisc-linux] cd .5 Hi All, I have HP9000/d212 I was able to boot off the cdrom image no problem, however when I get the login prompt I am only able to type in two characters and the screen redraws itself and prompts me for a login. I am using a HP700 serial terminal on ttyS0.I briefly scanned the mailing list but did not find anything. Any help would be appreciated. --Robert Reilly GE Capital Card Service UNIX Administrator robert.reilly@gecapital.com From matthew@wil.cx Tue, 21 Nov 2000 17:38:57 +0000 Date: Tue, 21 Nov 2000 17:38:57 +0000 From: Matthew Wilcox matthew@wil.cx Subject: CVS linux Vs. -test10 On Tue, Nov 21, 2000 at 06:11:29AM -0700, John Marvin wrote: > Are we suggesting that we populate include/asm-parisc* and arch/parisc* > WITHOUT the machine independent changes in the rest of the tree? Yes. > If that is the case, I guess I don't object, although I would want > to make sure that Linus knew the state of the code, and that it would > not work without a patch containing changes to the machine independent > part, and that followup patches to these branches are likely to be > huge. We should also add a README in arch/parisc that explains the > above (and where to get patches, how to access CVS, etc.). We also > need someone to set up an automatic nightly? patch generator. Agreed. The patch generation is not a big deal to arrange. > I certainly don't want to try to get the machine independent changes in > yet, since we still have some major issues to fix/clean there, and I doubt > Linus would want them at this time anyway. Certainly none of the stack direction changes. Some of the MI stuff is arguably stuff we could put in. -- Revolutions do not require corporate support. From Pirvulescu_Alexandru@telemobil.ro Tue, 21 Nov 2000 20:49:57 +0200 Date: Tue, 21 Nov 2000 20:49:57 +0200 From: Alexandru Pirvulescu Pirvulescu_Alexandru@telemobil.ro Subject: [parisc-linux] case LEDs Hello Is there any possibility to activate the case LEDs? I mean the heartbeat and the network activity I have a A180 machine Alex From grundler@cup.hp.com Tue, 21 Nov 2000 10:55:06 -0800 Date: Tue, 21 Nov 2000 10:55:06 -0800 From: Grant Grundler grundler@cup.hp.com Subject: [parisc-linux] case LEDs "Alexandru Pirvulescu" wrote: > Hello > > Is there any possibility to activate the case LEDs? I mean the heartbeat and > the network activity. I have a A180 machine. Yes. I was already asked this weekend to dig up technical info on LED and soft power control. I guess this is my reminder to do that. :^) grant From grundler@cup.hp.com Tue, 21 Nov 2000 10:59:24 -0800 Date: Tue, 21 Nov 2000 10:59:24 -0800 From: Grant Grundler grundler@cup.hp.com Subject: [parisc-linux] cd .5 Robert Reilly wrote: > Hi All, > I have HP9000/d212 I was able to boot off the cdrom image no problem, > however when I get the login prompt I am only able to type in two > characters and the screen redraws itself and prompts me for a login. I am > using a HP700 serial terminal on ttyS0. I briefly scanned the mailing list > but did not find anything. Any help would be appreciated. Robert, I would suspent the terminal isn't configured correctly for the serial connection. Is it set up for 9600 baud, 8 data bits, no parity, 1 stop bit? I'm pretty sure you have the baud rate correct since you get a login prompt. I'm not sure all the other things must be correct to get that far. I'm not familiar with "HP700 serial terminal". But all the HP terminals I've worked with in the past also support vt100 emulation mode. You probably want to set that too. grant Grant Grundler Unix Systems Enablement Lab +1.408.447.7253 From kailasr@webcash.com Tue, 21 Nov 2000 12:30:12 -0800 Date: Tue, 21 Nov 2000 12:30:12 -0800 From: Kailashnath V Rampure kailasr@webcash.com Subject: [parisc-linux] Apache package. Hi Paul, I have installed Apache + mod_ssl + mod_perl on HP A Class server. I need help on to change the server looking fort bootpd server and put the IP address on the system. Also where can I find the ftp client for linux . Regards Kalas At 04:59 PM 11/15/00 -0700, Paul Bame wrote: >= I tried to build apache_1.3.12 on HP a class server. But I have error. I >= have tried to check the site >= ftp://ftp.debian.org/debian/dists/unstable/main/binary-hppa/ >= I could not find one. I found some apache-doc etc. > >We are still working on some kernel features which are required to >support Apache (system 5 shared memory). > > -P From grundler@cup.hp.com Tue, 21 Nov 2000 13:24:31 -0800 Date: Tue, 21 Nov 2000 13:24:31 -0800 From: Grant Grundler grundler@cup.hp.com Subject: [parisc-linux] CVS linux Vs. -test10 Matthew Wilcox wrote: ... > Someone (probably me) sends him a patch. He told me at the Toronto > show that he was quite happy to apply anything that only touched those > two directories. (oh, and drivers/gsc wouldn't be a problem either). > Can I just check that no-one wants to rename drivers/gsc again? :-) Hi Mathew, I don't and it's a good question. I would like a few files moved: arch/parisc/kernel/ccio-dma.c -> drivers/gsc/ccio-dma.c arch/parisc/kernel/ccio-rm-dma.c -> drivers/gsc/ccio-rm-dma.c ccio will *always* be associated with a GSC bus since that's the secondary bus. And ccio supports devices below dino.c which already lives in drivers/gsc. arch/parisc/kernel/lba_pci.c -> drivers/ropes/lba_pci.c arch/parisc/kernel/sba_iommu.c -> drivers/ropes/sba_iommu.c arch/parisc/kernel/iosapic.c -> drivers/ropes/iosapic.c lba/sba code is equivalent to dino/ccio code for another set of platforms. And long term, I'm certain iosapic.c does not belong under arch/parisc. I can do this move if there are no major objections. Any reason why we couldn't do these moves *after* you submit a patch? FWIW, here are issues I see with merging IA64 iosapic code with mine: o iosapic "discovery" (I invented register_iosapic() interface for parisc) o parisc PDC calls (initialization) o interrupt policy decisions (eg EOI generation and picking a CPU) o I don't have time to do it in the near future. Folks working on IA64 stuff inside HP need to think about: (a) if they want to do the merge any time soon (b) which iosapic.c they want to start with (c) where the final version should live thanks, grant Grant Grundler Unix Systems Enablement Lab +1.408.447.7253 From pjlahaie@linuxcare.com Tue, 21 Nov 2000 16:41:48 -0500 Date: Tue, 21 Nov 2000 16:41:48 -0500 From: Paul J.Y. Lahaie pjlahaie@linuxcare.com Subject: [parisc-linux] Fun build problems --PW0Eas8rCkcu1VkF Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hello everyone, Over the last couple of days, I've been trying to get the debian boot-floppies building (I know some changes will be necessary) and as it stands now, several packages are missing. In the process of trying to compile/install these packages, I've run into some difficulties. Here are some of them: apt -- Package on pehc and .iso do not work. Missing lots of helper apps. Seeing as apt was broken, I decided to download the woody version of apt so I can get a newer version and hopefully skip some steps in building the above packages. gcc 2.96 and apt-0.3.19 don't get along, so I tried picking it up from cvs (supposed to have been fixed). Follow the directions on cvs.debian.org $ cvs -d :pserver:anonymous@cvs.debian.org:/cvs/APT login (Logging in to anonymous@cvs.debian.org) CVS password:=20 cvs login: authorization failed: server cvs.debian.org rejected access Anyone know if there are other instructions other than what cvs.debian.org says? If so, feel free to email me rsync -- ldd crashes on dpkg-shlibdepends stage Can I just manually put the required dependancies in? autoconf -- installinfo spins When installing the autoconf package (to compile dpkg) installinfo spins. And after several minutes still doesn't return. It's taking up 100% cpu at the time. If I abort this, autoconf seems to be installed but cannot generate the dpkg configure properly, some macros are missing AM_CONDITIONAL(HAVE_CPLUSPLUS, test "$CXX" !=3D "") Is in the ./configure script. info -- Reinstall spins If I try to reinstall info, it spins on the uninstall. 100% cpu. If anyone has any solutions for any of the above problems, I am all ears (eyes?). - Paul --PW0Eas8rCkcu1VkF Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.4 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE6Guwc8ggPQthPCzcRAgkGAJ9TzClXOg009RWO/v09ONBNnxJcbgCfcWcX gj26osR06BqyJ0O+/Q83csk= =YHRW -----END PGP SIGNATURE----- --PW0Eas8rCkcu1VkF-- From alan@linuxcare.com.au Wed, 22 Nov 2000 09:50:05 +1100 (EST) Date: Wed, 22 Nov 2000 09:50:05 +1100 (EST) From: Alan Modra alan@linuxcare.com.au Subject: [parisc-linux] Use of the EI_OSABI field cc to binutils because John makes some salient points. On Mon, 20 Nov 2000, John Marvin wrote: > > Another glibc issue (which is why I'm sending this back to the list) is > > that there has been quite some discussion on the binutils list over the > > use of the EI_OSABI field. The conclusion being that it isn't really > > correct to use this field to discern the intendend execution platform. > > It's purpose is really to tell ELF tools that a file contains fields and > > values that need to be interpreted in a non-standard way. Since both > > elf32-hppa and elf64-hppa follow the standards, I'm inclined to think that > > the gnu tools should set EI_OSABI to zero for both HPUX and Linux targets. > > I don't read the binutils mailing list, so I checked the archive. In my > opinion I didn't see a discussion, I saw H.J. Lu repeatedly asserting > this "fact". He may or may not be correct about original intention, but > the implementation so far has been that EI_OSABI is used to tell what the > target platform is. That is what FreeBSD is doing, that is what HP-UX is > doing, and that is what the IA-64 Unix System V Application Binary > Interface specifies: > > http://developer.intel.com/design/IA-64/Downloads/24537002.pdf > > Note that the second paragraph in section 1.1 of that specification > includes the following: > > This document is the result of consensus among operating system > vendors intending to provide UNIX and UNIX workalike operating > systems on the IA-64 architecture. The vendors participating in > this effort include Intel, Sun Microsystems, SCO, IBM, SGI, > Cygnus Solutions, VA Linux Systems, HP, and Compaq. > > So, If the specification is wrong according to H.J. Lu, why did both > Cygnus and VA Linux Systems not object to this: > > Section 4.1.1.4 Operating System Identification > > The e_ident[EI_OSABI] value identifies the operating system and > ABI to which the object is targeted, as listed in Table 4-1. > > Table 4-1 lists the various ELFOSABI_* fields, e.g. ELFOSABI_HPUX, > ELFOSABI_NETBSD, ELFOSABI_LINUX, etc. > > Note also, that the current mechanism for us to be able to differentiate > elf executables in the Linux kernel is the machine dependent > elf_check_arch() macro, whose only argument is a pointer to a > elf32_hdr or elf64_hdr. I think it would be ugly to try to get the > .note.ABI-tag section first for every exec of a new binary in order > to determine what the target ABI is. > > In my opinion, unless H.J. Lu can get the IA-64 ABI changed, it is too > late to assert his view of what that field was supposed to be. Please > leave the EI_OSABI field set to ELFOSABI_LINUX until a better consensus > on this issue is reached. > > John Marvin > jsm@fc.hp.com I'm happy enough to leave things as they are in puffin CVS, but these changes haven't been merged back to sourceware yet, partly because I had some doubts myself as to whether setting EI_OSABI was correct. H.J. Lu wasn't the only one arguing that EI_OSABI should be left at zero; Ulrich Drepper also was quite vehement against changing sourceware FreeBSD binutils. BTW, it's not too hard to check .note.ABI-tag. The linker arranges for a PT_NOTE program header entry to point to it, and the section itself is virtually guaranteed to be read in with the header as it's placed right after the header along with .interp. Alan Modra -- Linuxcare. Support for the Revolution. From drepper@redhat.com 21 Nov 2000 15:27:19 -0800 Date: 21 Nov 2000 15:27:19 -0800 From: Ulrich Drepper drepper@redhat.com Subject: [parisc-linux] Use of the EI_OSABI field Alan Modra writes: > Ulrich Drepper also was quite vehement against changing sourceware > FreeBSD binutils. I've never said anything about any *BSD, why should I? The *BSD people wanted to change the Linux binutils. Anyway, the ABI value is zero unless you implement ELF extensions. -- ---------------. ,-. 1325 Chesapeake Terrace Ulrich Drepper \ ,-------------------' \ Sunnyvale, CA 94089 USA Red Hat `--' drepper at redhat.com `------------------------ From alan@linuxcare.com.au Wed, 22 Nov 2000 11:13:29 +1100 (EST) Date: Wed, 22 Nov 2000 11:13:29 +1100 (EST) From: Alan Modra alan@linuxcare.com.au Subject: [parisc-linux] Use of the EI_OSABI field On 21 Nov 2000, Ulrich Drepper wrote: > Alan Modra writes: > > > Ulrich Drepper also was quite vehement against changing sourceware > > FreeBSD binutils. > > I've never said anything about any *BSD, why should I? The *BSD > people wanted to change the Linux binutils. Sorry, I stated that badly. > Anyway, the ABI value is zero unless you implement ELF extensions. Exactly what is an "ELF extension"? Anything outside gABI or "gABI + psABI"? Handly the latter, as it seems to me that a processor specific ABI can specify extensions. There's also the awkward possibility that a psABI may specify an extension that is later incorporated into a new revision of the gABI (eg. hpux and DT_INIT_ARRAY) Does that mean that if a new revision of the gABI completely incorporates all previous extensions, that EI_OSABI should become zero? Yes, I'm arguing that "No ELF extensions => EI_OSABI == 0" is not necessarily true, but I'm _not_ arguing that changing x86 Linux binutils is wise. Historical usage is important. If we were to change x86 Linux binutils to set EI_OSABI, then that can only be after a considerable period of time to allow code such as glibc to accept a new branding. Alan Modra -- Linuxcare. Support for the Revolution. From drepper@redhat.com 21 Nov 2000 16:31:39 -0800 Date: 21 Nov 2000 16:31:39 -0800 From: Ulrich Drepper drepper@redhat.com Subject: [parisc-linux] Use of the EI_OSABI field Alan Modra writes: > Exactly what is an "ELF extension"? Anything outside gABI or > "gABI + psABI"? Anything beyond the psABI that cannot be handled by the rules in the gABI. -- ---------------. ,-. 1325 Chesapeake Terrace Ulrich Drepper \ ,-------------------' \ Sunnyvale, CA 94089 USA Red Hat `--' drepper at redhat.com `------------------------ From hjl@valinux.com Tue, 21 Nov 2000 16:53:27 -0800 Date: Tue, 21 Nov 2000 16:53:27 -0800 From: H . J . Lu hjl@valinux.com Subject: [parisc-linux] Use of the EI_OSABI field On Wed, Nov 22, 2000 at 11:13:29AM +1100, Alan Modra wrote: > > > Anyway, the ABI value is zero unless you implement ELF extensions. > > Exactly what is an "ELF extension"? Anything outside gABI or ELF extension is something whose interpretation is not documented in neither gABI nor psABI. HP's old ELF is a good example since it didn't implement DT_INIT/DT_FINI, but added DT_INIT_ARRARY/DT_FINI_ARRAY. A normal ELF tool will have a hard time to interpret those fields and their values. H.J. From matthew@wil.cx Wed, 22 Nov 2000 00:53:09 +0000 Date: Wed, 22 Nov 2000 00:53:09 +0000 From: Matthew Wilcox matthew@wil.cx Subject: [parisc-linux] CVS linux Vs. -test10 On Tue, Nov 21, 2000 at 01:24:31PM -0800, Grant Grundler wrote: > I would like a few files moved: > > arch/parisc/kernel/ccio-dma.c -> drivers/gsc/ccio-dma.c > arch/parisc/kernel/ccio-rm-dma.c -> drivers/gsc/ccio-rm-dma.c > arch/parisc/kernel/lba_pci.c -> drivers/ropes/lba_pci.c > arch/parisc/kernel/sba_iommu.c -> drivers/ropes/sba_iommu.c > arch/parisc/kernel/iosapic.c -> drivers/ropes/iosapic.c > Any reason why we couldn't do these moves *after* you submit a patch? Better to get our house in order before we patchbomb Linus, I think. Renames are hard enough in CVS; renames in diff -u format are a real stinker :-) -- Revolutions do not require corporate support. From adevries@linuxcare.com Tue, 21 Nov 2000 21:27:51 -0500 Date: Tue, 21 Nov 2000 21:27:51 -0500 From: Alex deVries adevries@linuxcare.com Subject: [parisc-linux] case LEDs Grant Grundler wrote: > Yes. > I was already asked this weekend to dig up technical info on LED > and soft power control. I guess this is my reminder to do that. :^) Isn't there a PDC call (pdc_chassis?) to do this? Or is the heartbeat LED done by hardware? - Alex -- Alex deVries, Principal Solutions Architect, The Puffins at Linuxcare 613.562.2759 tel alex@linuxcare.com, http://www.linuxcare.com/ Linuxcare, Support for the revolution. From randolph@tausq.org Tue, 21 Nov 2000 18:50:24 -0700 Date: Tue, 21 Nov 2000 18:50:24 -0700 From: Randolph Chung randolph@tausq.org Subject: [parisc-linux] Fun build problems --9zSXsLTf0vkW971A Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable > Seeing as apt was broken, I decided to download the woody version of apt = so > I can get a newer version and hopefully skip some steps in building the > above packages. gcc 2.96 and apt-0.3.19 don't get along, so I tried pick= ing > it up from cvs (supposed to have been fixed). Follow the directions on > cvs.debian.org >=20 > $ cvs -d :pserver:anonymous@cvs.debian.org:/cvs/APT login > (Logging in to anonymous@cvs.debian.org) > CVS password:=20 > cvs login: authorization failed: server cvs.debian.org rejected access Try: cvs -d:pserver:anonymous@cvs.debian.org:/cvs/deity login (empty password) It should work. if not let me know and i can mail you a tarball. You probably want to get the aliencode branch, which has hppa patches. Let me know if you run into any problems. > rsync -- ldd crashes on dpkg-shlibdepends stage > Can I just manually put the required dependancies in? Yes, or pick up the dpkg-architecture and dpkg-shlibdeps scripts from http://puffin.external.hp.com/~tausq/, or wait for the next version of dpkg to get built for hppa (it doesn't use ldd anymore) > autoconf -- installinfo spins >=20 > When installing the autoconf package (to compile dpkg) installinfo spins. > And after several minutes still doesn't return. It's taking up 100% cpu > at the time. hmmm.. didn't see this. I had built a slightly older version of dpkg successfully. randolph (tausq@debian.org) --=20 @..@ http://www.TauSq.org/ (----) ( >__< ) ^^ ~~ ^^ --9zSXsLTf0vkW971A Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.1 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE6GyZgULspdC1Zp9IRAozyAKC/Df1fexltMjFlcwpeYlD+IIWEigCgiGyT YKOjLA0BQzMo7qOj8jC1BTI= =whh1 -----END PGP SIGNATURE----- --9zSXsLTf0vkW971A-- From hjl@valinux.com Tue, 21 Nov 2000 19:11:29 -0800 Date: Tue, 21 Nov 2000 19:11:29 -0800 From: H . J . Lu hjl@valinux.com Subject: [parisc-linux] Use of the EI_OSABI field On Wed, Nov 22, 2000 at 02:03:07PM +1100, Alan Modra wrote: > On Tue, 21 Nov 2000, H . J . Lu wrote: > > > On Wed, Nov 22, 2000 at 11:13:29AM +1100, Alan Modra wrote: > > > > > > > Anyway, the ABI value is zero unless you implement ELF extensions. > > > > > > Exactly what is an "ELF extension"? Anything outside gABI or > > > > ELF extension is something whose interpretation is not documented in > > neither gABI nor psABI. HP's old ELF is a good example since it didn't > > implement DT_INIT/DT_FINI, but added DT_INIT_ARRARY/DT_FINI_ARRAY. A > > normal ELF tool will have a hard time to interpret those fields and > > their values. > > Neither you nor Ulrich have responded to John's point that the IA64 psABI > states > "The e_ident[EI_OSABI] value identifies the operating system and ABI to > which the object is targeted" > > Granted, this is only in a processor specific ABI, but it does flatly > contradict your assertions that the purpose of EI_OSABI is to flag the > presense of ELF extensions. > When I was at the IA64 ABI meeting yesterday, we were looking at the EI_OSABI issue. Everyone at the IA64 ABI meeting agreed that what Ulrich and I had said was the correct understanding. "The e_ident[EI_OSABI] value identifies the operating system and ABI to which the object is targeted" just means if the e_ident[EI_OSABI] value is not ELFOSABI_NONE, you have to look somewhere else in addition to gABI and IA64 psABI to interpret the ELF fields/values specific to that OS. Otherwise, gABI and IA64 psABI are sufficient. -- H.J. Lu (hjl@valinux.com) From drepper@redhat.com 21 Nov 2000 19:18:21 -0800 Date: 21 Nov 2000 19:18:21 -0800 From: Ulrich Drepper drepper@redhat.com Subject: [parisc-linux] Use of the EI_OSABI field Alan Modra writes: > "The e_ident[EI_OSABI] value identifies the operating system and ABI to > which the object is targeted" > > Granted, this is only in a processor specific ABI, but it does flatly > contradict your assertions that the purpose of EI_OSABI is to flag the > presense of ELF extensions. The meaning of the field changed over time. Or better said, some people initially understood it differently. -- ---------------. ,-. 1325 Chesapeake Terrace Ulrich Drepper \ ,-------------------' \ Sunnyvale, CA 94089 USA Red Hat `--' drepper at redhat.com `------------------------ From alan@linuxcare.com.au Wed, 22 Nov 2000 14:03:07 +1100 (EST) Date: Wed, 22 Nov 2000 14:03:07 +1100 (EST) From: Alan Modra alan@linuxcare.com.au Subject: [parisc-linux] Use of the EI_OSABI field On Tue, 21 Nov 2000, H . J . Lu wrote: > On Wed, Nov 22, 2000 at 11:13:29AM +1100, Alan Modra wrote: > > > > > Anyway, the ABI value is zero unless you implement ELF extensions. > > > > Exactly what is an "ELF extension"? Anything outside gABI or > > ELF extension is something whose interpretation is not documented in > neither gABI nor psABI. HP's old ELF is a good example since it didn't > implement DT_INIT/DT_FINI, but added DT_INIT_ARRARY/DT_FINI_ARRAY. A > normal ELF tool will have a hard time to interpret those fields and > their values. Neither you nor Ulrich have responded to John's point that the IA64 psABI states "The e_ident[EI_OSABI] value identifies the operating system and ABI to which the object is targeted" Granted, this is only in a processor specific ABI, but it does flatly contradict your assertions that the purpose of EI_OSABI is to flag the presense of ELF extensions. Alan Modra -- Linuxcare. Support for the Revolution. From rbradetich@uswest.net Tue, 21 Nov 2000 22:54:11 -0800 Date: Tue, 21 Nov 2000 22:54:11 -0800 From: Ryan Bradetich rbradetich@uswest.net Subject: [parisc-linux] CVS linux Vs. -test10 Grant Grundler wrote: > Matthew Wilcox wrote: > ... > > Someone (probably me) sends him a patch. He told me at the Toronto > > show that he was quite happy to apply anything that only touched those > > two directories. (oh, and drivers/gsc wouldn't be a problem either). > > Can I just check that no-one wants to rename drivers/gsc again? :-) > > Hi Mathew, > I don't and it's a good question. > I would like a few files moved: > > arch/parisc/kernel/ccio-dma.c -> drivers/gsc/ccio-dma.c > arch/parisc/kernel/ccio-rm-dma.c -> drivers/gsc/ccio-rm-dma.c Grant, Do you really want to merget the ccio-rm-dma.c file into Linus's tree? It is just a reference file used to construct the real ccio-dma.c file ... I don't believe it is referenced anywhere. I'll double check this in the morning. - Ryan > ccio will *always* be associated with a GSC bus since that's > the secondary bus. And ccio supports devices below dino.c which > already lives in drivers/gsc. > > arch/parisc/kernel/lba_pci.c -> drivers/ropes/lba_pci.c > arch/parisc/kernel/sba_iommu.c -> drivers/ropes/sba_iommu.c > arch/parisc/kernel/iosapic.c -> drivers/ropes/iosapic.c > > lba/sba code is equivalent to dino/ccio code for another set > of platforms. And long term, I'm certain iosapic.c does not > belong under arch/parisc. I can do this move if there are no > major objections. > > Any reason why we couldn't do these moves *after* you submit a patch? > > FWIW, here are issues I see with merging IA64 iosapic code with mine: > o iosapic "discovery" (I invented register_iosapic() interface for parisc) > o parisc PDC calls (initialization) > o interrupt policy decisions (eg EOI generation and picking a CPU) > o I don't have time to do it in the near future. > > Folks working on IA64 stuff inside HP need to think about: > (a) if they want to do the merge any time soon > (b) which iosapic.c they want to start with > (c) where the final version should live > > thanks, > grant > > Grant Grundler > Unix Systems Enablement Lab > +1.408.447.7253 > > --------------------------------------------------------------------------- > To unsubscribe: send e-mail to parisc-linux-request@thepuffingroup.com with > `unsubscribe' as the subject. From jsm@udlkern.fc.hp.com Tue, 21 Nov 2000 23:50:03 -0700 (MST) Date: Tue, 21 Nov 2000 23:50:03 -0700 (MST) From: John Marvin jsm@udlkern.fc.hp.com Subject: [parisc-linux] CVS linux Vs. -test10 > Better to get our house in order before we patchbomb Linus, I think. > Renames are hard enough in CVS; renames in diff -u format are a real > stinker :-) In that case, we need to do some cleanup first. I've been lobbying for the removal of the almost empty arch/parisc/real directory, and its few remaining valid files moved to the kernel directory. There are also a fair number of dead files. Every file that is not currently involved in the build should be removed, unless a good case for it remaining can be made. If the reason to keep it is not a long term reason, then that file should not be sent to Linus (It sounds like it is a lot easier to add files rather than remove/rename them). If there are any files that are currently in use, but which we know will eventually be removed, perhaps we should consider what to do with that file (although I don't know of any files in this category at the moment). John Marvin jsm@fc.hp.com From grundler@cup.hp.com Tue, 21 Nov 2000 23:18:16 -0800 Date: Tue, 21 Nov 2000 23:18:16 -0800 From: Grant Grundler grundler@cup.hp.com Subject: [parisc-linux] CVS linux Vs. -test10 Ryan Bradetich wrote: > Do you really want to merget the ccio-rm-dma.c file into Linus's tree? > It is just a reference file used to construct the real ccio-dma.c file ... I > don't believe it is referenced anywhere. Hi Ryan, Yes I do. It is supposed to work for ccio+PCX-W platforms (eg C360). Keeping it arround will document the pro/con's of that approach and give folks who have time (and the right machine) something to experiment with instead of writing it from scratch. If someone finds an application it's good for (short transactions with low latency requirements perhaps), it's worth having around. It's not referenced because I didn't add a CONFIG_CCIO_RM_IOMMU flag or ccio_rm_init() call to drivers/gsc/gsc.c:gsc_init(). You are welcome add this CONFIG flag by hacking arch/parisc/config.in and defconfig. If you do, please add rules which only allow one or the other CONFIG_CCIO* option to be enabled. thanks, grant Grant Grundler Unix Systems Enablement Lab +1.408.447.7253 From Pirvulescu_Alexandru@telemobil.ro Wed, 22 Nov 2000 09:36:58 +0200 Date: Wed, 22 Nov 2000 09:36:58 +0200 From: Alexandru Pirvulescu Pirvulescu_Alexandru@telemobil.ro Subject: [parisc-linux] case LEDs I think that the heartbeat LED is software because it starts with the kernel boot and if the kernel stops the LED stops blinking too. Is better to implement a software monitoring tool because you have to watch the software for hanging. Alex PS. There is a function in the kernel source in linux/arch/parisc/kernel/process.c named machine_heartbeat(). Any connection with the heartbeat from the chassis? ----- Original Message ----- From: "Alex deVries" To: "Grant Grundler" Cc: "Alexandru Pirvulescu" ; Sent: Wednesday, November 22, 2000 4:27 AM Subject: Re: [parisc-linux] case LEDs > Grant Grundler wrote: > > Yes. > > I was already asked this weekend to dig up technical info on LED > > and soft power control. I guess this is my reminder to do that. :^) > > Isn't there a PDC call (pdc_chassis?) to do this? Or is the heartbeat > LED done by hardware? > > - Alex > > -- > Alex deVries, Principal Solutions Architect, The Puffins at Linuxcare > 613.562.2759 tel > alex@linuxcare.com, http://www.linuxcare.com/ > Linuxcare, Support for the revolution. > > From bvalkema@knowhowww.nl Wed, 22 Nov 2000 06:32:51 +0100 Date: Wed, 22 Nov 2000 06:32:51 +0100 From: Bas Valkema bvalkema@knowhowww.nl Subject: [parisc-linux] case LEDs Alex deVries wrote: > Grant Grundler wrote: > > Yes. > > I was already asked this weekend to dig up technical info on LED > > and soft power control. I guess this is my reminder to do that. :^) > > Isn't there a PDC call (pdc_chassis?) to do this? Or is the heartbeat > LED done by hardware? > > - Alex A couple of months ago, I asked the same question, got answer to look in the mkLinux sources. I did, and I think it was a register (outb(0xblabla);). Wrote a driver (and for WAX, got a Intel Flash 32 EISA running), can't release it now, because of some copyright issues... Bas From grundler@cup.hp.com Tue, 21 Nov 2000 23:56:35 -0800 Date: Tue, 21 Nov 2000 23:56:35 -0800 From: Grant Grundler grundler@cup.hp.com Subject: [parisc-linux] CVS linux Vs. -test10 John Marvin wrote: > In that case, we need to do some cleanup first. John, I want a task list which leads us to a submital to linus. That's why I listed the specific files I wanted moved. Can you come up with (or ask someone else to come up) with a list of files which meet your criteria? All of your criteria sounds reasonable to me. But I don't have a feel of which files meet your criteria. If someone makes the task list, I'm happy to help with items and verify the result works. thanks, grant From jsm@udlkern.fc.hp.com Wed, 22 Nov 2000 01:11:57 -0700 (MST) Date: Wed, 22 Nov 2000 01:11:57 -0700 (MST) From: John Marvin jsm@udlkern.fc.hp.com Subject: [parisc-linux] CVS linux Vs. -test10 > Ryan Bradetich wrote: > > Do you really want to merget the ccio-rm-dma.c file into Linus's tree? > > It is just a reference file used to construct the real ccio-dma.c file ... I > > don't believe it is referenced anywhere. > > Hi Ryan, > Yes I do. It is supposed to work for ccio+PCX-W platforms (eg C360). > Keeping it arround will document the pro/con's of that approach and > give folks who have time (and the right machine) something to experiment > with instead of writing it from scratch. If someone finds an application > it's good for (short transactions with low latency requirements perhaps), > it's worth having around. > > It's not referenced because I didn't add a CONFIG_CCIO_RM_IOMMU flag > or ccio_rm_init() call to drivers/gsc/gsc.c:gsc_init(). You are welcome > add this CONFIG flag by hacking arch/parisc/config.in and defconfig. > If you do, please add rules which only allow one or the other > CONFIG_CCIO* option to be enabled. > Well, personally i'd vote to get rid of it. It works for ONE machine only, and MAY have an advantage in some small case. But if we keep it, lets make sure that it is real clear that it should NOT be the default choice. It should be marked CONFIG_EXPERIMENTAL, and the text associated with it should clearly show that it works on a C360 only. If possible, it should also be made clear that ccio-dma.c works for C360, so people who have C360's don't think they have to choose ccio-rm-dma.c. Grant, I hope you are prepared to answer the parisc-linux mailing list questions this is going to generate once parisc-linux starts becoming more visible. Another FAQ entry perhaps? :-) John Marvin jsm@fc.hp.com From jsm@udlkern.fc.hp.com Wed, 22 Nov 2000 01:52:04 -0700 (MST) Date: Wed, 22 Nov 2000 01:52:04 -0700 (MST) From: John Marvin jsm@udlkern.fc.hp.com Subject: [parisc-linux] Use of the EI_OSABI field > > BTW, it's not too hard to check .note.ABI-tag. The linker arranges for a > PT_NOTE program header entry to point to it, and the section itself is > virtually guaranteed to be read in with the header as it's placed right > after the header along with .interp. I didn't say it was difficult, I said it was ugly. It means another parisc only change to the machine independent file fs/binfmt_elf.c, since the hook provided will not allow this check. Without a change, binfmt_elf.c won't be smart enough to differentiate a binary produced by Gnu binutils for HP-UX and a binary produced by Gnu binutils for Linux, so it will claim both, and then blow up later, rather than not claiming the HP-UX binary and allowing it to be claimed by an arch dependent binary handler further down the list. And binfmt_elf.c does NOT read the program headers in the same read, so another read would have to be done (the data should be found in in cache rather than going to disk for it). Since we now need both the program headers and a section header to determine whether or not we should claim the file AND binfmt_elf.c also wants to look at those headers after the file is claimed, a small redesign is probably in order (rather than re-reading the headers). I'm not sure whether or not Linus would buy that. So, I guess I'll pursue the interpreter field instead, since that is what sparc is doing (i.e. they have their own sparc only code in binfmt_elf.c). Since that will be an easier sell. I need to do more research here. I suspect that statically linked binaries are not going to allow this solution to work though. John Marvin jsm@fc.hp.com From alan@linuxcare.com.au Wed, 22 Nov 2000 23:28:45 +1100 (EST) Date: Wed, 22 Nov 2000 23:28:45 +1100 (EST) From: Alan Modra alan@linuxcare.com.au Subject: [parisc-linux] binutils update I've just committed a change to binutils that cures an ELF spec violation. We now no longer create plabels for DT_INIT and DT_FINI and instead rely on the dynamic linker to create them for us. This means you need an updated glibc, that I committed a little earlier today, to create the plabel function pointers if you update your binutils. You have been warned... Alan Modra -- Linuxcare. Support for the Revolution. From bruno_vidal@hpfrcu03.france.hp.com Wed, 22 Nov 2000 15:14:18 +0100 Date: Wed, 22 Nov 2000 15:14:18 +0100 From: Bruno Vidal bruno_vidal@hpfrcu03.france.hp.com Subject: [parisc-linux] Crash dump module Hi Good news, I've finished to recompile the entire chain on hpux 11.00 64bits. I've recompile my own kernel and booted a small 712/60. It work pretty well. Now I'm going to start the work about crash dump. So, In my mind, I'll start from the linux/kernel/panic.c function and I'll add a function dumpsys.c in the linux/arch/paric directory -> is it okay for you ? It will depend on the CONFIG_PARISC var (or do you prefer adding a CONFIG_DUMPSYS var ?) thanks. -- Vidal Bruno, (770-4271) SSD-HA Team, HP-UX & LINUX Support bruno_vidal@admin.france.hp.com From randolph@tausq.org Wed, 22 Nov 2000 07:44:24 -0700 Date: Wed, 22 Nov 2000 07:44:24 -0700 From: Randolph Chung randolph@tausq.org Subject: [parisc-linux] Crash dump module > It will depend on the CONFIG_PARISC var (or do you prefer adding a CONFIG_DUMPSYS var ?) I think there was a consensus to use __hppa__ instead of CONFIG_PARISC ... randolph -- @..@ http://www.TauSq.org/ (----) ( >__< ) ^^ ~~ ^^ From mike_clapper@hp.com Wed, 22 Nov 2000 07:54:24 -0800 Date: Wed, 22 Nov 2000 07:54:24 -0800 From: CLAPPER,MIKE (HP-USA,ex1) mike_clapper@hp.com Subject: [parisc-linux] B132L boot hang Hello Everyone, I download the cross-compilers and build a lifimage on Redhat 6.1. I set up nfsroot on a S712 running hpux 10.20. With this I am able to boot a B132L running pdc 6.1 - almost. I get a hang right after - VFS: Mounted root (nfs filesystem) readonly Warning: unable to open an initial console I have a 700/96 on serial port 1 as the console. I have hpux on a disc in the unit I'm trying to boot - from HPUX I have verified I can nfs mount the filesys I'm using for NFSROOT. With linux in this condition the machine will respond to ping. I will also react to a telnet - i get the telnet banner then "connection closed by foreign host". FTP gets "connection refused" - so it' partially alive..... Is there a way to keyword search the developers archive? I vaguely recall seeing the 'initial console' warning, but couldn't find it browsing the developers archive Thanks, Mike ********************************************** Mike Clapper North American Crisis Management Team Hewlett Packard (405) 948-4715 ********************************************** From bame@noam.fc.hp.com Wed, 22 Nov 2000 09:02:03 -0700 Date: Wed, 22 Nov 2000 09:02:03 -0700 From: Paul Bame bame@noam.fc.hp.com Subject: [parisc-linux] CVS linux Vs. -test10 = I've been lobbying for = the removal of the almost empty arch/parisc/real directory, and its few = remaining valid files moved to the kernel directory. Done. arch/parisc/real R.I.P. From grundler@cup.hp.com Wed, 22 Nov 2000 08:27:22 -0800 Date: Wed, 22 Nov 2000 08:27:22 -0800 From: Grant Grundler grundler@cup.hp.com Subject: [parisc-linux] Crash dump module Bruno Vidal wrote: > Hi > Good news, I've finished to recompile the entire chain on hpux 11.00 64bits. > I've recompile my own kernel and booted a small 712/60. It work pretty well. > Now I'm going to start the work about crash dump. So, In my mind, I'll start > from the linux/kernel/panic.c function and I'll add a function dumpsys.c > in the linux/arch/paric directory -> is it okay for you ? YES! > It will depend on the CONFIG_PARISC var > (or do you prefer adding a CONFIG_DUMPSYS var ?) As Randolph pointed out CONFIG_PARISC is deprecated. Use "ifdef __hppa__" for changes in *common* (ie not arch/parisc) files. They should not be needed for anything in arch/parisc or linux/include/asm-parisc. Adding a CONFIG_DUMPSYS is a good idea. Look in linux/arch/parisc/config.in, linux/arch/parisc/defconfig, and the various Makefiles for how CONFIG_* flags work. thanks Bruno! grant Grant Grundler Unix Systems Enablement Lab +1.408.447.7253 From grundler@cup.hp.com Wed, 22 Nov 2000 09:27:20 -0800 Date: Wed, 22 Nov 2000 09:27:20 -0800 From: Grant Grundler grundler@cup.hp.com Subject: [parisc-linux] B132L boot hang "CLAPPER,MIKE (HP-USA,ex1)" wrote: > > > Hello Everyone, > > I download the cross-compilers and build a lifimage on Redhat 6.1. I set > up nfsroot on a S712 running hpux 10.20. With this I am able to boot a > B132L running pdc 6.1 - > almost. I get a hang right after - > > VFS: Mounted root (nfs filesystem) readonly > Warning: unable to open an initial console I think I need more output. Based on ioscan output, the B132L has two serial ports: 8/16/4 - off of LASI 8/20/2 - of WAX (EISA Bus Adapter) (GSCtoPCI is at 8/0) I don't think the one off of WAX is supported right now. Are you using the default .config produced by "make oldconfig"? It's also possible the LASI support is broken on B132L and I would expect some console output indicating what's wrong. > I have a 700/96 on serial port 1 as the console. I have hpux on a disc in > the unit I'm trying to boot - from HPUX I have verified I can nfs mount the > filesys I'm using for NFSROOT. NFS root mounted fine. Console is the problem. ... > Is there a way to keyword search the developers archive? I vaguely recall > seeing the 'initial console' warning, but couldn't find it browsing the > developers archive Yes - http://puffin.external.hp.com/cgi-bin/mailgrep grant Grant Grundler Unix Systems Enablement Lab +1.408.447.7253 From cary@cup.hp.com Wed, 22 Nov 2000 10:06:05 -0800 Date: Wed, 22 Nov 2000 10:06:05 -0800 From: Cary Coutant cary@cup.hp.com Subject: [parisc-linux] Use of the EI_OSABI field As the original author of the proposal to add the EI_OSABI field to the ELF format, let me try to clarify the intent of this field. The authoritative definition of this field is found in SCO's gABI document, which is still the official specification for the ELF format (this is probably posted somewhere on SCO's web site). Here's what it says: Byte e_ident[EI_OSABI] identifies the operating system and ABI to which the object is targeted. Some fields in other ELF structures have flags and values that have operating system and/or ABI specific meanings; the interpretation of those fields is determined by the value of this byte. The value of this byte must be interpreted differently for each machine. That is, each value for the e_machine field determines a set of values for the EI_OSABI byte. Values are assigned by the ABI processor supplement for each machine. If the processor supplement does not specify a set of values, the value 0 shall be used and indicates unspecified. The first sentence is still a bit misleading, and is an artifact of the original proposal. Originally, the field was intended to identify the target ABI (hence the name of the field). As we started discussing a common Unix ABI for IA-64, however, it became clear that this field wouldn't serve that purpose, but it was still needed to identify the set of platform-specific ELF extensions that are used by the object file. There are a number of fields in the ELF format for which ranges of values or a set of flag bits are reserved for vendor-specific use (e.g., SHT_LOOS through SHT_HIOS for vendor-specific section types, and SHF_MASKOS for vendor-specific section attributes). If an object file uses any of these values or flag bits, the consumer of the file must consult the EI_OSABI field to determine what those values or flags mean. It works just like the e_machine field does for attaching meaning to processor-specific values and flags. The intent is that any ABI-conforming implementation will be able to execute an ABI-conforming binary, even if it uses certain vendor-specific features. In many cases, those vendor-specific features are hints for a particular OS that can be ignored by other implementations. Where this is not the case, and a vendor-specific feature must be understood by the system in order to process the file correctly, we have a couple of alternatives. For section types and flags that a linker must understand, we have the SHF_OS_NONCONFORMING flag -- if set, and a linker doesn't understand a particular section type or flag, it must reject the file. For executables that will execute only on a particular implementation, we must use an alternate interpreter (PT_INTERP) or bind to implementation-specific shared libraries. An ABI-conforming binary will use the interpreter specified in the psABI spec, and will use only system libraries specified there. For statically-bound programs, I'm afraid we don't have a clear solution. We took the general approach that such programs are not ABI-conforming in the first place, and can use any mechanism they might choose to verify that they are executing on the appropriate implementation. -cary From grundler@cup.hp.com Wed, 22 Nov 2000 11:55:38 -0800 Date: Wed, 22 Nov 2000 11:55:38 -0800 From: Grant Grundler grundler@cup.hp.com Subject: [parisc-linux] CVS linux Vs. -test10 John Marvin wrote: > Grant Grundler wrote: > > Yes I do. It is supposed to work for ccio+PCX-W platforms (eg C360). ... > Well, personally i'd vote to get rid of it. It works for ONE machine only, > and MAY have an advantage in some small case. And so does the OB600 mouse driver I rewrote/published. AFAIK, it only works on OB600s. I was originally thinking D/K/R-class boxes had PCX-W upgrades but AFAICT, they don't. > But if we keep it, lets make > sure that it is real clear that it should NOT be the default choice. > > It should be marked CONFIG_EXPERIMENTAL, and the text associated with it > should clearly show that it works on a C360 only. If possible, it should > also be made clear that ccio-dma.c works for C360, so people who have > C360's don't think they have to choose ccio-rm-dma.c. IIRC, Comments in the headers of both ccio files make those issues clear. I'm not sure where else that needs to be documented. > Grant, I hope you are prepared to answer the parisc-linux mailing list > questions this is going to generate once parisc-linux starts becoming more > visible. Another FAQ entry perhaps? :-) Ryan owns it. He's responsible for documenting it and adding FAQ questions. He can choose to delete ccio-rm-dma.c as well. :^) I think it'd be a waste to throw it away before someone figures out that it's really not useful - even if just for C360. thanks, grant From mike_clapper@hp.com Wed, 22 Nov 2000 12:05:23 -0800 Date: Wed, 22 Nov 2000 12:05:23 -0800 From: CLAPPER,MIKE (HP-USA,ex1) mike_clapper@hp.com Subject: [parisc-linux] B132L boot hang Thanks Grant, I verified the console is off 8/16/4.0 and that it is the LASI port. I also downloaded the newest cross-compiler and source code. After rebuilding the palo lifimage I get the same hang in the same place. Since I was cabled to a dumb terminal I was not able to capture the boot output. I will find the right cable to hook up to my pc so I can capture the output and send it to you - perhaps an error occurred earlier in the boot that I overlooked. Thanks for the help. Mike -----Original Message----- From: Grant Grundler [mailto:grundler@cup.hp.com] Sent: Wednesday, November 22, 2000 11:27 AM To: CLAPPER,MIKE (HP-USA,ex1) Cc: 'parisc-linux@thepuffingroup.com' Subject: Re: [parisc-linux] B132L boot hang "CLAPPER,MIKE (HP-USA,ex1)" wrote: > > > Hello Everyone, > > I download the cross-compilers and build a lifimage on Redhat 6.1. I set > up nfsroot on a S712 running hpux 10.20. With this I am able to boot a > B132L running pdc 6.1 - > almost. I get a hang right after - > > VFS: Mounted root (nfs filesystem) readonly > Warning: unable to open an initial console I think I need more output. Based on ioscan output, the B132L has two serial ports: 8/16/4 - off of LASI 8/20/2 - of WAX (EISA Bus Adapter) (GSCtoPCI is at 8/0) I don't think the one off of WAX is supported right now. Are you using the default .config produced by "make oldconfig"? It's also possible the LASI support is broken on B132L and I would expect some console output indicating what's wrong. > I have a 700/96 on serial port 1 as the console. I have hpux on a disc in > the unit I'm trying to boot - from HPUX I have verified I can nfs mount the > filesys I'm using for NFSROOT. NFS root mounted fine. Console is the problem. ... > Is there a way to keyword search the developers archive? I vaguely recall > seeing the 'initial console' warning, but couldn't find it browsing the > developers archive Yes - http://puffin.external.hp.com/cgi-bin/mailgrep grant Grant Grundler Unix Systems Enablement Lab +1.408.447.7253 --------------------------------------------------------------------------- To unsubscribe: send e-mail to parisc-linux-request@thepuffingroup.com with `unsubscribe' as the subject. From kirkb@chrome.rose.hp.com Wed, 22 Nov 2000 12:10:10 PST Date: Wed, 22 Nov 2000 12:10:10 PST From: Kirk Bresniker kirkb@chrome.rose.hp.com Subject: [parisc-linux] CVS linux Vs. -test10 Grant Grundler wrote: | I was originally thinking D/K/R-class boxes had PCX-W upgrades but | AFAICT, they don't. | The C-class upgrade to PCX-W was a one-off. Upgrades for similar enterprise servers were not designed. KMB -- +============================================================+ | Kirk Bresniker (916) 748-2393 | | 8000 Foothills Blvd | | Roseville, CA 95747-5649 | | kirkb@rose.hp.com | From grundler@cup.hp.com Wed, 22 Nov 2000 12:11:23 -0800 Date: Wed, 22 Nov 2000 12:11:23 -0800 From: Grant Grundler grundler@cup.hp.com Subject: [parisc-linux] CVS linux Vs. -test10 Grant Grundler wrote: ... > arch/parisc/kernel/ccio-dma.c -> drivers/gsc/ccio-dma.c > arch/parisc/kernel/ccio-rm-dma.c -> drivers/gsc/ccio-rm-dma.c > > ccio will *always* be associated with a GSC bus since that's > the secondary bus. And ccio supports devices below dino.c which > already lives in drivers/gsc. Ryan - moving/keeping these files is up to you. I was just sharing what I thought was "right". Apologies for not making that clear earlier. > arch/parisc/kernel/lba_pci.c -> drivers/ropes/lba_pci.c > arch/parisc/kernel/sba_iommu.c -> drivers/ropes/sba_iommu.c > arch/parisc/kernel/iosapic.c -> drivers/ropes/iosapic.c I've talked to one of the folks working on IA64-linux. They are interested in merging iosapic code but haven't even looked at the parisc version I wrote. We talked a bit about the issues and it doesn't sound like it's going to happen anytime soon. In any case, iosapic.c doesn't belong under "drivers/ropes". So none of this needs to move in the forseeable future. It can all stay in arch/parisc/kernel. grant Grant Grundler Unix Systems Enablement Lab +1.408.447.7253 From deller@gmx.de Wed, 22 Nov 2000 21:43:40 +0100 Date: Wed, 22 Nov 2000 21:43:40 +0100 From: Helge Deller deller@gmx.de Subject: [parisc-linux] B132L boot hang > I think I need more output. Based on ioscan output, the B132L > has two serial ports: > 8/16/4 - off of LASI > 8/20/2 - of WAX (EISA Bus Adapter) > > (GSCtoPCI is at 8/0) > > I don't think the one off of WAX is supported right now. It should be detected & supported (at least it is on my B160L). But it is not used as initial console since it normally gets assigned as ttyS1 while LASI-serial gets ttyS0. Greetings, Helge. From bame@noam.fc.hp.com Wed, 22 Nov 2000 16:03:12 -0700 Date: Wed, 22 Nov 2000 16:03:12 -0700 From: Paul Bame bame@noam.fc.hp.com Subject: [parisc-linux] 64-bit progress 32-bit syscalls on 64-bit kernel are to the point where a few things work, and signals appear to be working (I didn't implement *all* the signal-related syscalls yet). I'll be continuing to produce syscall wrappers for a while... If you try to boot the standard NFS root with wide kernel, you'll want to mv sbin/init sbin/init-real then compile and install this program as sbin/init: int main() { char *argv[2]; argv[0] = "/sbin/init-real"; argv[1] = 0; execv(argv[0], argv); } I never felt comfortable I found the point where sys_execve figures out it needs to pack the argv vector differently for narrow user apps (locally I also am using PER_LINUX32 in binfmt_elf32.c) which causes the initial exec(/sbin/init) to be passed incomprehensible arguments. This program is a little temporary workaround. -Paul Bame From alan@linuxcare.com.au Thu, 23 Nov 2000 11:18:20 +1100 (EST) Date: Thu, 23 Nov 2000 11:18:20 +1100 (EST) From: Alan Modra alan@linuxcare.com.au Subject: glibc On Wed, 22 Nov 2000, Matt Taggart wrote: > Hi Alan, > > First a timezone question... your mail headers have you in +11 and Ft. Collins > is -7 so you're 6 hours behind + 1 day relative to us? So as I send this it's > 14:05 here and 8:05 there? Hi Matt, I'm actually on +10:30 in Adelaide, but posting from a Linuxcare machine in Canberra which is on +11. >[snip segfaults] > I am building native using dhd's binutils/gcc/glibc debs, using source checked > out just after the glibc 2.2 merge. Do you think the merge / ld.so changes you > just made would help this problem at all? Quite likely. This fix * sysdeps/hppa/dl-machine.h (ELF_MACHINE_START_ADDRESS): Define. is fairly crucial, as without it %dp will not be set correctly. I should have mentioned this when posting to the list about the binutils change. Oh, and as of this email, I haven't actually run anything linked to the new glibc. A little remiss, I know, but I've been deep in the gdb port, and if I spend time tinkering with glibc, binutils and gcc (which I like), gdb (which I don't like) will never be finished. ;-) Alan -- Linuxcare. Support for the Revolution. From grundler@cup.hp.com Wed, 22 Nov 2000 18:24:52 -0800 (PST) Date: Wed, 22 Nov 2000 18:24:52 -0800 (PST) From: Grant Grundler grundler@cup.hp.com Subject: [parisc-linux] new SBA IOMMU version committed Hi all, I've committed my "second generation" I/O MMU code for C3K/J5k boxes. It's only tested for 32-bit. I'll be testing 64-bit shortly. This code makes "perfect" use of the I/O pdir resource map and we shouldn't see any panics due to out_of_resource. grant From grundler@cup.hp.com Wed, 22 Nov 2000 18:47:06 -0800 (PST) Date: Wed, 22 Nov 2000 18:47:06 -0800 (PST) From: Grant Grundler grundler@cup.hp.com Subject: [parisc-linux] CONFIG_DMB_TRAP diff Hello again (last one until Monday - I promise), With Lamont's wisdom, I implemented support for Date Memory Break trap. This enables the kernel programmer to capture the evil code which stomps on other people's "private" data. Only works for stores through virtual addresses. gsc_writeX() and DMA will still bypass this mechanism. pb, dhd, (or some equivalent deity), could you review/commit this code? Or tell me it's ok to commit? I've touched: arch/parisc/config.in arch/parisc/kernel/entry.S arch/parisc/mm/kmap.c include/asm-parisc/pgtable.h thanks, grant Index: arch/parisc/config.in =================================================================== RCS file: /home/cvs/parisc/linux/arch/parisc/config.in,v retrieving revision 1.25 diff -u -p -r1.25 config.in --- config.in 2000/10/20 18:28:26 1.25 +++ config.in 2000/11/23 02:18:23 @@ -16,8 +16,12 @@ endmenu mainmenu_option next_comment comment 'General options' -# bool 'Symmetric multi-processing support' CONFIG_SMP -define_bool CONFIG_SMP n +bool 'Symmetric multi-processing support' CONFIG_SMP +# define_bool CONFIG_SMP n + +# One needs to tweak dmb_trap_11 code in entry.S to match. +# Not tested for 64-bit kernel. +bool 'Debug support for Data Memory Break Trap' CONFIG_DMB_TRAP bool 'Kernel Debugger support' CONFIG_KWDB # define_bool CONFIG_KWDB n Index: arch/parisc/kernel/entry.S =================================================================== RCS file: /home/cvs/parisc/linux/arch/parisc/kernel/entry.S,v retrieving revision 1.53 diff -u -p -r1.53 entry.S --- entry.S 2000/11/22 16:51:33 1.53 +++ entry.S 2000/11/23 02:18:23 @@ -23,6 +23,7 @@ */ #include +#include /* the following is the setup i think we should follow: * whenever the CPU is interruptible, the following has to be true: @@ -349,7 +350,39 @@ .endm #endif +#ifdef CONFIG_DMB_TRAP /* + ** Data Memory Bit trap interruption handler (parisc 1.1) + ** + ** This is a debugging aid. Use it when you think someone else + ** is stepping on your memory. It only catches *virtual* + ** accesses. gsc_writeX() functions disable virtual translation + ** (D-bit) and will happily scribble whatever physical address + ** is passed in. + ** + ** Here's how to use it: + ** 1) Call iterate_pages() from your init routine like this: + ** iterate_pages( my_private_mem, private_mem_size, + ** set_data_memory_break, 0); + ** 2) substitute your functions for your_function1 (or 2) in + ** dmb_trap_11 code below. + ** + ** Thanks to Lamont Jones for telling me how to do this. + ** - ggg 1/22/2000 + */ + .macro dmb_11 code + + mfctl %isr,spc + b dmb_trap_11 + mfctl %ior,va + + .align 32 + .endm +#else +#define dmb_11 def +#endif + + /* * dirty bit trap interruption handler (parisc 2.0) */ @@ -448,7 +481,7 @@ fault_vector_11: naitlb_11 16 nadtlb_11 17 def 18 - def 19 + dmb_11 19 dbit_11 20 def 21 def 22 @@ -467,7 +500,6 @@ fault_vector_11: .import handle_interruption,code .import handle_real_interruption,code .import do_irq_mask,code - .import parisc_stopkernel,code .import cpu_irq_region,data /* @@ -903,11 +935,15 @@ dtlb_miss_11: dep pte,8,7,prot extru,= pte,_PAGE_NO_CACHE_BIT,1,r0 - depi 1,12,1,prot + depi 1,12,1,prot /* U-bit */ extru,= pte,_PAGE_USER_BIT,1,r0 depi 7,11,3,prot /* Set for user space (1 rsvd for read) */ extru,= pte,_PAGE_GATEWAY_BIT,1,r0 depi 0,11,2,prot /* If Gateway, Set PL2 to 0 */ +#ifdef CONFIG_DMB_TRAP + extru,= pte,_PAGE_DMB_BIT,1,r0 + depi 1,4,1,prot /* B-bit */ +#endif /* Get rid of prot bits and convert to page addr for idtlba */ @@ -1300,6 +1336,30 @@ dbit_trap_11: rfir nop + +#ifdef CONFIG_DMB_TRAP + .import your_function1,code + .import your_function2,code + +dmb_trap_11: + mfctl pcsq,t0 /* get space */ + comb,<>,n t0,%r0,dmb_rfi /* not kernel - bail */ + + mfctl pcoq,t0 /* get offset */ + ldil L%dmb_ok_function1, t1 + dep %r0, 31, 12, t0 + comb,=,n t0,t1,dmb_rfi /* it's ours - bail */ + + ldil L%dmb_ok_function2, t1 + comb,<>,n t0,t1,intr_save /* not ours - panic */ + +dmb_rfi: + mfctl ipsw,t0 /* Set PSW X-bit - just continue */ + depi 1,11,1,t0 /* Set X-bit */ + mtctl t0, ipsw + rfir + nop +#endif dbit_trap_20: mfctl %cr25,ptp /* Assume user space trap */ Index: arch/parisc/mm/kmap.c =================================================================== RCS file: /home/cvs/parisc/linux/arch/parisc/mm/kmap.c,v retrieving revision 1.3 diff -u -p -r1.3 kmap.c --- kmap.c 2000/05/05 18:05:47 1.3 +++ kmap.c 2000/11/23 02:18:23 @@ -43,7 +43,16 @@ static void unmap_cached_pte(pte_t * pte } #endif +#ifdef CONFIG_DMB_TRAP /* These two routines should probably check a few things... */ +void set_data_memory_break(pte_t * pte, unsigned long arg) +{ + pte_val(*pte) |= _PAGE_DMB; +} + +#endif + +/* These two routines should probably check a few things... */ static void set_uncached(pte_t * pte, unsigned long arg) { pte_val(*pte) |= _PAGE_NO_CACHE; @@ -106,7 +115,10 @@ static inline void iterate_pmd(pgd_t * d } while (address < end); } -static void iterate_pages(unsigned long address, unsigned long size, +#ifndef CONFIG_DMB_TRAP +static +#endif +void iterate_pages(unsigned long address, unsigned long size, pte_iterator_t op, unsigned long arg) { pgd_t *dir; Index: include/asm-parisc/pgtable.h =================================================================== RCS file: /home/cvs/parisc/linux/include/asm-parisc/pgtable.h,v retrieving revision 1.29 diff -u -p -r1.29 pgtable.h --- pgtable.h 2000/11/10 21:44:44 1.29 +++ pgtable.h 2000/11/23 02:18:23 @@ -109,6 +109,10 @@ extern void *vmalloc_start; #define _PAGE_USER 0x400 /* Software: User accessable page */ #define _PAGE_USER_BIT 21 /* Needs to agree with _PAGE_USER above */ /* 0x800 still available */ +#ifdef CONFIG_DMB_TRAP +#define _PAGE_DMB 0x800 /* Data Memory Break Trap */ +#define _PAGE_DMB_BIT 20 /* Data Memory Break Trap */ +#endif #ifdef __ASSEMBLY__ #define _PGB_(x) (1 << (63 - (x))) From jsm@udlkern.fc.hp.com Wed, 22 Nov 2000 22:50:14 -0700 (MST) Date: Wed, 22 Nov 2000 22:50:14 -0700 (MST) From: John Marvin jsm@udlkern.fc.hp.com Subject: [parisc-linux] CONFIG_DMB_TRAP diff > > Hello again (last one until Monday - I promise), > > With Lamont's wisdom, I implemented support for Date Memory Break trap. > > This enables the kernel programmer to capture the evil code which > stomps on other people's "private" data. Only works for stores > through virtual addresses. gsc_writeX() and DMA will still > bypass this mechanism. > > pb, dhd, (or some equivalent deity), could you review/commit this code? > Or tell me it's ok to commit? > > I've touched: > arch/parisc/config.in > arch/parisc/kernel/entry.S > arch/parisc/mm/kmap.c > include/asm-parisc/pgtable.h > Please don't. This solution is way more complicated than it should be. Here are the problems with it: 1) As I had already mentioned in a previous discussion, the pte's already reserve the location for the B bit (data memory break trap) and the dtlb miss handlers already move the entire group of bits that include this bit in one operation. So no change is necessary to the dtlb miss handlers to specially set that bit and incur extra instructions in the tlb miss handlers, and no extra bits need to be allocated in the pte. Instead of adding a new definition (e.g. 0x800, which is our last available bit) use the one that is already reserved for it: 0x010. 2) There is no reason to add a special data memory break trap handler. The general trap handler is more than sufficient for this case. handle_interruption will be called if a data memory break trap is encountered. Just add a new case for the list of traps, and handle the trap in C. You can set the X bit by simply setting it in the saved ipsw (in gr[0]) and it will be set upon return from the trap, no muss, no fuss. Note that the above also applies for the page reference trap. The T bit is also already supported (0x040 in the pte) by the dtlb miss handlers. Note that the reason I reserved these bits is because it would actually take MORE code in the dtlb miss handlers to NOT support those bits and use them for something else. Another helpful hint for those wanting to use this feature. If you are tracking corruptions that span multiple pages, then just setting the B bit on each page may be all you need. But, when I've used the data memory break trap for corruption tracking, typically I've wanted to track a corruption that was happening to a particular variable, i.e. a 4 byte quantity, and lots of other variables were being legitimately written on the same page, so you wind up with thousands of data memory break traps, where only one may be the one that is corrupting the location you are interested in. But, all is not lost, the solution is still fairly simple. The data memory break trap provides a valid iir, isr and ior. So once you get the trap, a custom data memory break handler (which can be written with a few lines of C in handle_interruption), simply uses iir, isr and ior to check if the access was to the specific byte or bytes you are interested in. I've simply used isr/ior to check for writes within the word I was interested in. That may be enough for most cases. The information you are missing from isr/ior is the size of the write transaction. To get this you would need to parse the instruction stored in iir (code to determine the size of a store from the instruction in the iir will be necessary when an unaligned fault handler is written). John Marvin jsm@fc.hp.com From jsm@udlkern.fc.hp.com Thu, 23 Nov 2000 01:29:55 -0700 (MST) Date: Thu, 23 Nov 2000 01:29:55 -0700 (MST) From: John Marvin jsm@udlkern.fc.hp.com Subject: [parisc-linux] CONFIG_DMB_TRAP diff Alan Modra wrote: > > gdb will eventually want to use this trap too. > Cool! However, data memory break traps for user translations are a little tougher. There are some small modifications in the machine dependent code that I can make to make sure the B bit stays set during most VM operations on a page. However, since the machine independent part of the VM system doesn't know anything about this bit (nor should it), it won't be preserved if the page is paged out (and subsequently paged back in). This could be fixed fairly easily with some changes to the machine independent code, but I don't think that would be appropriate. Some potential solutions (each has its problems): 1) Just document the fact that the feature may not work on systems with low memory. It's a parisc only feature, so perhaps we could live with that. 2) Lock the page in memory (using the mlock interface) when we set the B bit on a page. Just some thoughts on the subject. John Marvin jsm@fc.hp.com From pjlahaie@linuxcare.com Fri, 24 Nov 2000 16:56:16 -0500 Date: Fri, 24 Nov 2000 16:56:16 -0500 From: Paul J.Y. Lahaie pjlahaie@linuxcare.com Subject: [parisc-linux] boot-floppies dependancies --GRPZ8SYKNexpdSJ7 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline I would like to know if anyone has built any of the following packages that are needed for the boot-floppies. Currently, the missing deps are: cspsfonts man-db tetex-bin recode cslatex libpaperg tetex-extra libnewt-dev libgd1g-dev gawk libi18n-langtags-perl dpkg-awk debiandoc-sgml I'm currently trying to get a working apt, since the one of pehc and the .iso seem to be broken (no xfer methods). I'll let everyone know when a working copy will be available. - Paul --GRPZ8SYKNexpdSJ7 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.4 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE6HuP/8ggPQthPCzcRAnyKAJ0fyraVXEvlI0yQLsli7FlnUUAPdwCfSyv/ YgAxOcVMDgWfHBc7lneuc1Y= =tScM -----END PGP SIGNATURE----- --GRPZ8SYKNexpdSJ7-- From doneill@linuxcare.com Fri, 24 Nov 2000 17:01:00 -0500 (EST) Date: Fri, 24 Nov 2000 17:01:00 -0500 (EST) From: Dave O'Neill doneill@linuxcare.com Subject: [parisc-linux] strace? So, I've heard rumours that somewhere there's a working strace for parisc.... Can anyone point me in the right direction? Dave -- Dave O'Neill, Senior Linux Consultant, Linuxcare, Inc. desk: (613) 562-9949 fax: (613) 562-9700 cell: (613) 223-0219 doneill@linuxcare.com http://www.linuxcare.com/ From obrien@FreeBSD.org Sat, 25 Nov 2000 12:22:11 -0800 Date: Sat, 25 Nov 2000 12:22:11 -0800 From: David O'Brien obrien@FreeBSD.org Subject: [parisc-linux] Use of the EI_OSABI field On Tue, Nov 21, 2000 at 03:27:19PM -0800, Ulrich Drepper wrote: > Alan Modra writes: > > > Ulrich Drepper also was quite vehement against changing sourceware > > FreeBSD binutils. > > I've never said anything about any *BSD, why should I? The *BSD > people wanted to change the Linux binutils. No (don't put words in my mouth Ulrich as you'll be wrong 99% of the time). I wanted the Sourceware Binutils to set the EI_OSABI to "ELFOSABI_LINUX" when targeting Linux. -- -- David (obrien@FreeBSD.org) From obrien@FreeBSD.org Sat, 25 Nov 2000 12:28:40 -0800 Date: Sat, 25 Nov 2000 12:28:40 -0800 From: David O'Brien obrien@FreeBSD.org Subject: [parisc-linux] Use of the EI_OSABI field On Tue, Nov 21, 2000 at 07:11:29PM -0800, H . J . Lu wrote: > When I was at the IA64 ABI meeting yesterday, we were looking at the > EI_OSABI issue. Everyone at the IA64 ABI meeting agreed that what > Ulrich and I had said was the correct understanding. > > "The e_ident[EI_OSABI] value identifies the operating system and ABI > to which the object is targeted" just means if the e_ident[EI_OSABI] Then is this *extremely* misleading text going to be changed??? "the operating system and" needs to be deleted in the _official_ _published_ specification. -- -- David (obrien@FreeBSD.org) From obrien@FreeBSD.org Sat, 25 Nov 2000 12:31:08 -0800 Date: Sat, 25 Nov 2000 12:31:08 -0800 From: David O'Brien obrien@FreeBSD.org Subject: [parisc-linux] Use of the EI_OSABI field On Tue, Nov 21, 2000 at 07:18:21PM -0800, Ulrich Drepper wrote: > Alan Modra writes: > > "The e_ident[EI_OSABI] value identifies the operating system and ABI to > > which the object is targeted" > > > > Granted, this is only in a processor specific ABI, but it does flatly > > contradict your assertions that the purpose of EI_OSABI is to flag the > > presense of ELF extensions. > > The meaning of the field changed over time. Or better said, some > people initially understood it differently. Then lets get the _official_ wording changed. Obviously my interpretation wasn't unreasonable. And the world does not need to have you as a premadona keeper of the [unwritten] rules of the land. -- -- David (obrien@FreeBSD.org) From hjl@valinux.com Sat, 25 Nov 2000 12:33:40 -0800 Date: Sat, 25 Nov 2000 12:33:40 -0800 From: H . J . Lu hjl@valinux.com Subject: [parisc-linux] Use of the EI_OSABI field On Sat, Nov 25, 2000 at 12:28:40PM -0800, David O'Brien wrote: > On Tue, Nov 21, 2000 at 07:11:29PM -0800, H . J . Lu wrote: > > When I was at the IA64 ABI meeting yesterday, we were looking at the > > EI_OSABI issue. Everyone at the IA64 ABI meeting agreed that what > > Ulrich and I had said was the correct understanding. > > > > "The e_ident[EI_OSABI] value identifies the operating system and ABI > > to which the object is targeted" just means if the e_ident[EI_OSABI] > > > Then is this *extremely* misleading text going to be changed??? > "the operating system and" needs to be deleted in the _official_ > _published_ specification. > I will bring this issue up to ia64 psABI and gABI. -- H.J. Lu (hjl@valinux.com) From alan@lxorguk.ukuu.org.uk Sat, 25 Nov 2000 20:57:05 +0000 (GMT) Date: Sat, 25 Nov 2000 20:57:05 +0000 (GMT) From: Alan Cox alan@lxorguk.ukuu.org.uk Subject: [parisc-linux] RPM and hppa I've uploaded my first block of RPM packages to ftp.linux.org.uk/pub/linux/alan/HPPA along with a tar ball of built RPM tools for anyone who wants to play. In doing so I've hit a few problems with the 0.5 iso (no suprises there since its not actually meant to work reliably) - g++ explodes trying to build groff after allocating about 400Mb of RAM. Building -O0 works - the configure script for procmail tries to find the largest argument set that works (by searching). It crashes the kernel in doing so 8) - ldd is causing page faults in ld.so (kernel logged ones) and dying with segv. Fortunately it outputs the library list first - The linker appears to have a problem when resolving symbols between three shared objects while doing a shared object link. [Example is rpm: rpmlib is linked dynamically with -ldb3 -ldb The linker emits messages about symbols being static and should be built -fPIC. If you dump the libraries they are -fPIC. It looks as if its resolving a symbol between two shared libraries and making a static resolution that then blows up when the third library gets involved ] - The kernel shows occasional page cache corruption. This actually is quite possibly generic test6 bugs On the whole the toolset is working remarkably well. I've built over 100 source package sets so far including things like ncurses and most stuff just builds or hits portability problems (eg gmp wants to use HP format asm, zlib wants to be a non PIC library for performance but the HP tools dont allow it) Alan From alan@linuxcare.com.au Sun, 26 Nov 2000 23:01:50 +1100 (EST) Date: Sun, 26 Nov 2000 23:01:50 +1100 (EST) From: Alan Modra alan@linuxcare.com.au Subject: [parisc-linux] RPM and hppa On Sat, 25 Nov 2000, Alan Cox wrote: > - g++ explodes trying to build groff after allocating about 400Mb of RAM. > Building -O0 works Yeah, this is a known issue. I see on the gcc list that rth and others have been working on gcc fixes recently that should address the problem. I don't have the time/ability to fix it myself. > - the configure script for procmail tries to find the largest argument set > that works (by searching). It crashes the kernel in doing so 8) > > - ldd is causing page faults in ld.so (kernel logged ones) and dying with > segv. Fortunately it outputs the library list first How old are your glibc and binutils? I made some changes late October that should have fixed this problem. See http://puffin.external.hp.com/mailing-lists/parisc-linux/2000/10-Oct/0146.html Does "readelf -d" on your hppa-linux ld.so show you have a DT_TEXTREL tag? > - The linker appears to have a problem when resolving symbols between three > shared objects while doing a shared object link. > > [Example is rpm: > > rpmlib is linked dynamically with -ldb3 -ldb > > The linker emits messages about symbols being static and should be > built -fPIC. If you dump the libraries they are -fPIC. > > It looks as if its resolving a symbol between two shared libraries > and making a static resolution that then blows up when the third > library gets involved > > ] Could you put all the objects involved in the link up for ftp somewhere? I've just built rpm-2.5.6 without seeing this problem, but I'm sure my setup is different to yours... Regards, Alan Modra -- Linuxcare. Support for the Revolution. From alan@lxorguk.ukuu.org.uk Sun, 26 Nov 2000 12:12:21 +0000 (GMT) Date: Sun, 26 Nov 2000 12:12:21 +0000 (GMT) From: Alan Cox alan@lxorguk.ukuu.org.uk Subject: [parisc-linux] RPM and hppa > How old are your glibc and binutils? I made some changes late October From the 0.5 cdrom > http://puffin.external.hp.com/mailing-lists/parisc-linux/2000/10-Oct/0146.html > Does "readelf -d" on your hppa-linux ld.so show you have a DT_TEXTREL tag? Nope > Could you put all the objects involved in the link up for ftp > somewhere? I've just built rpm-2.5.6 without seeing this problem, but I'm > sure my setup is different to yours... rpm 4.0. rpm2 doesnt do that 3 way link with db and db3. I'll put them up when I get a bit of time From dave@hiauly1.hia.nrc.ca Sun, 26 Nov 2000 11:45:08 -0500 (EST) Date: Sun, 26 Nov 2000 11:45:08 -0500 (EST) From: John David Anglin dave@hiauly1.hia.nrc.ca Subject: [parisc-linux] RPM and hppa > On Sat, 25 Nov 2000, Alan Cox wrote: > > > - g++ explodes trying to build groff after allocating about 400Mb of RAM. > > Building -O0 works > > Yeah, this is a known issue. I see on the gcc list that rth and others > have been working on gcc fixes recently that should address the problem. > I don't have the time/ability to fix it myself. I think the above is a different problem. The explosion is most likely a problem with exception edges in the gcse pass. Try `-fno-gcse'. This also appears in the tFile.cc libio test. The pa port uses sjlj exceptions via __builtin_setjmp/longjmp. A nonlocal goto label is used for the target of the longjmp. The flow analysis assumes that an "exception" could jump to any label in the procedure rather than just the label associated with the exception region. Dave -- J. David Anglin dave.anglin@nrc.ca National Research Council of Canada (613) 990-0752 (FAX: 952-6605) From cwalthall@cwalthall.com Sun, 26 Nov 2000 11:45:38 -0600 Date: Sun, 26 Nov 2000 11:45:38 -0600 From: Carl & Delores Walthall cwalthall@cwalthall.com Subject: [parisc-linux] RPM and hppa Does anyone know where I can find the operating system for the HP9000 J200 Server? Thanks Carl Walthall ----- Original Message ----- From: "Alan Modra" To: "Alan Cox" Cc: Sent: Sunday, November 26, 2000 6:01 AM Subject: Re: [parisc-linux] RPM and hppa > On Sat, 25 Nov 2000, Alan Cox wrote: > > > - g++ explodes trying to build groff after allocating about 400Mb of RAM. > > Building -O0 works > > Yeah, this is a known issue. I see on the gcc list that rth and others > have been working on gcc fixes recently that should address the problem. > I don't have the time/ability to fix it myself. > > > - the configure script for procmail tries to find the largest argument set > > that works (by searching). It crashes the kernel in doing so 8) > > > > - ldd is causing page faults in ld.so (kernel logged ones) and dying with > > segv. Fortunately it outputs the library list first > > How old are your glibc and binutils? I made some changes late October > that should have fixed this problem. See > http://puffin.external.hp.com/mailing-lists/parisc-linux/2000/10-Oct/0146.ht ml > Does "readelf -d" on your hppa-linux ld.so show you have a DT_TEXTREL tag? > > > - The linker appears to have a problem when resolving symbols between three > > shared objects while doing a shared object link. > > > > [Example is rpm: > > > > rpmlib is linked dynamically with -ldb3 -ldb > > > > The linker emits messages about symbols being static and should be > > built -fPIC. If you dump the libraries they are -fPIC. > > > > It looks as if its resolving a symbol between two shared libraries > > and making a static resolution that then blows up when the third > > library gets involved > > > > ] > > Could you put all the objects involved in the link up for ftp > somewhere? I've just built rpm-2.5.6 without seeing this problem, but I'm > sure my setup is different to yours... > > Regards, Alan Modra > -- > Linuxcare. Support for the Revolution. > > > -------------------------------------------------------------------------- - > To unsubscribe: send e-mail to parisc-linux-request@thepuffingroup.com with > `unsubscribe' as the subject. > From cwalthall@cwalthall.com Sun, 26 Nov 2000 11:47:24 -0600 Date: Sun, 26 Nov 2000 11:47:24 -0600 From: Carl & Delores Walthall cwalthall@cwalthall.com Subject: [parisc-linux] RPM and hppa Hi All I have a HP9000 J200 server and would like to find the operating system software for it. Can you tell me where to look on the internet or who I may call? The server has a OS installed but no one can remember the user or password information. So they gave it to me to take home, is there a way to boot it on a floppy and change this information? Thanks for any information you can give me! Carl walthall ----- Original Message ----- From: "John David Anglin" To: "Alan Modra" Cc: ; Sent: Sunday, November 26, 2000 10:45 AM Subject: Re: [parisc-linux] RPM and hppa > > On Sat, 25 Nov 2000, Alan Cox wrote: > > > > > - g++ explodes trying to build groff after allocating about 400Mb of RAM. > > > Building -O0 works > > > > Yeah, this is a known issue. I see on the gcc list that rth and others > > have been working on gcc fixes recently that should address the problem. > > I don't have the time/ability to fix it myself. > > I think the above is a different problem. The explosion is most likely > a problem with exception edges in the gcse pass. Try `-fno-gcse'. This > also appears in the tFile.cc libio test. > > The pa port uses sjlj exceptions via __builtin_setjmp/longjmp. A > nonlocal goto label is used for the target of the longjmp. The flow > analysis assumes that an "exception" could jump to any label in the > procedure rather than just the label associated with the exception > region. > > Dave > -- > J. David Anglin dave.anglin@nrc.ca > National Research Council of Canada (613) 990-0752 (FAX: 952-6605) > > -------------------------------------------------------------------------- - > To unsubscribe: send e-mail to parisc-linux-request@thepuffingroup.com with > `unsubscribe' as the subject. > From alan@lxorguk.ukuu.org.uk Sun, 26 Nov 2000 22:47:43 +0000 (GMT) Date: Sun, 26 Nov 2000 22:47:43 +0000 (GMT) From: Alan Cox alan@lxorguk.ukuu.org.uk Subject: [parisc-linux] Linker failure with db1 I replaced the libdb1 on the ISO with one built using the toolchain on the ISO and all is now happy. From grundler@cup.hp.com Sun, 26 Nov 2000 19:11:41 -0800 Date: Sun, 26 Nov 2000 19:11:41 -0800 From: Grant Grundler grundler@cup.hp.com Subject: [parisc-linux] RPM and hppa "Carl & Delores Walthall" wrote: > Hi All > > I have a HP9000 J200 server and would like to find the operating system > software for it. Can you tell me where to look on the internet or who I may > call? Carl, The short answer is a port of linux to the J200 is in progress. See http://www.parisc-linux.org/ for status. If you have more questions read the FAQ and check the mailing list archives using http://puffin.external.hp.com/cgi-bin/mailgrep first please. > The server has a OS installed but no one can remember the user or password > information. So they gave it to me to take home, is there a way to boot > it on a floppy and change this information? Here's how to "fix" this: During power up/boot press key to get "BOOT ADMIN>" prompt. type "bo pri isl". At "ISL>" prompt, type "hpux -is". HPUX should boot to single user. use "mountall" or "mount -a" to mount all file systems. Then you can "vi /etc/passwd" or "passwd root". If that doesn't work and you can afford to loan the box out for a 3-4 monthes, you might ask if someone could install parisc-linux on it for you in exchange for a few monthes use. grant Grant Grundler Unix Systems Enablement Lab +1.408.447.7253 From grundler@cup.hp.com Sun, 26 Nov 2000 22:12:10 -0800 Date: Sun, 26 Nov 2000 22:12:10 -0800 From: Grant Grundler grundler@cup.hp.com Subject: [parisc-linux] case LEDs Alex deVries wrote: > Grant Grundler wrote: > > I was already asked this weekend to dig up technical info on LED > > and soft power control. I guess this is my reminder to do that. :^) I dug up the info but it's not in a form I'm willing to publishing. However, someone did volunteer to look at this and I've provided them with this info. So it will make into our CVS source tree and get published that way. > Isn't there a PDC call (pdc_chassis?) to do this? Not AFAICT. PDC_CHASSIS is documented in the pdc32.pdf found on http://www.parisc-linux.org/documentation.html But my gut feeling is parisc specific code could make some PDC_CHASSIS calls to set up "sysstat" field (eg initialize, shutdown, run states). Does anyone know if the chassis codes used by HPUX are published? It would be cool if parisc-linux used the same codes where possible... > Or is the heartbeat LED done by hardware? Code I've looked at before seems to all do it in software. grant Grant Grundler Unix Systems Enablement Lab +1.408.447.7253 From sanjak@tipas.lt Mon, 27 Nov 2000 09:09:22 +0200 Date: Mon, 27 Nov 2000 09:09:22 +0200 From: Aleksandr Konstantinov sanjak@tipas.lt Subject: [parisc-linux] how to boot ? Hello, All. We have two HP Workstations here (Model 735). I would like to try linux on one of them. But I have no disk space to install all the stuff (binutils, compiler, etc) . I found precompiled kernel on puffin.external.hp.com but it looks like I also need palo . Does anybody know, where to get precompiled palo for hpux9, hpux10 or linux-x86 ? Thanks in advance. A.K. From rhirst@linuxcare.com Mon, 27 Nov 2000 09:18:21 +0000 Date: Mon, 27 Nov 2000 09:18:21 +0000 From: Richard Hirst rhirst@linuxcare.com Subject: [parisc-linux] strace? Hi Dave, The source is in cvs on pehc; I can supply a binary if you want one. I havn't made serious use of it, but it does basically work. Richard On Fri, Nov 24, 2000 at 05:01:00PM -0500, Dave O'Neill wrote: > > So, I've heard rumours that somewhere there's a working strace for > parisc.... Can anyone point me in the right direction? > > Dave > -- > Dave O'Neill, Senior Linux Consultant, Linuxcare, Inc. > desk: (613) 562-9949 fax: (613) 562-9700 cell: (613) 223-0219 > doneill@linuxcare.com http://www.linuxcare.com/ > > --------------------------------------------------------------------------- > To unsubscribe: send e-mail to parisc-linux-request@thepuffingroup.com with > `unsubscribe' as the subject. > > From alan@lxorguk.ukuu.org.uk Mon, 27 Nov 2000 16:55:36 +0000 (GMT) Date: Mon, 27 Nov 2000 16:55:36 +0000 (GMT) From: Alan Cox alan@lxorguk.ukuu.org.uk Subject: [parisc-linux] RPM and hppa > I think the above is a different problem. The explosion is most likely > a problem with exception edges in the gcse pass. Try `-fno-gcse'. This > also appears in the tFile.cc libio test. I've not yet had a chance to try this. I see the same behaviour building Qt so I may try it on that From marteaut@esiee.fr Mon, 27 Nov 2000 18:11:36 +0000 Date: Mon, 27 Nov 2000 18:11:36 +0000 From: marteau marteaut@esiee.fr Subject: [parisc-linux] Hi all, We have tried to compile the new linux source today and vmlinux always needs pci.o to link. It works if you delete pci.o from the objects list in the kernel Makefile. But, we don't know why it was needed because we did not ask for in our "make config"... We appreciate any help! THX, ESIEE Team From dave@hiauly1.hia.nrc.ca Mon, 27 Nov 2000 12:13:02 -0500 (EST) Date: Mon, 27 Nov 2000 12:13:02 -0500 (EST) From: John David Anglin dave@hiauly1.hia.nrc.ca Subject: [parisc-linux] RPM and hppa > > > I think the above is a different problem. The explosion is most likely > > a problem with exception edges in the gcse pass. Try `-fno-gcse'. This > > also appears in the tFile.cc libio test. > > I've not yet had a chance to try this. I see the same behaviour building Qt > so I may try it on that Another option that might help if exceptions aren't needed is `-fno-exceptions'. Dave -- J. David Anglin dave.anglin@nrc.ca National Research Council of Canada (613) 990-0752 (FAX: 952-6605) From grundler@cup.hp.com Mon, 27 Nov 2000 09:57:39 -0800 Date: Mon, 27 Nov 2000 09:57:39 -0800 From: Grant Grundler grundler@cup.hp.com Subject: No subject marteau wrote: > We have tried to compile the new linux source today and vmlinux > always needs pci.o to link. It works if you delete pci.o from the > objects list in the kernel Makefile. But, we don't know why it was > needed because we did not ask for in our "make config"... Hi Thomas, The problem is in arch/parisc/kernel/Makefile. It doesn't use CONFIG_PCI to decide if pci.o is needed. I'll fix that now - should be simple. thanks, grant From dave@hiauly1.hia.nrc.ca Mon, 27 Nov 2000 13:19:52 -0500 (EST) Date: Mon, 27 Nov 2000 13:19:52 -0500 (EST) From: John David Anglin dave@hiauly1.hia.nrc.ca Subject: [parisc-linux] RPM and hppa > > I think the above is a different problem. The explosion is most likely > > a problem with exception edges in the gcse pass. Try `-fno-gcse'. This > > also appears in the tFile.cc libio test. > > I've not yet had a chance to try this. I see the same behaviour building Qt > so I may try it on that If the problem is in fact the exception handling method, I think we should look at implementing the DWARF2 unwind mechanism and exception handling using this unwind mechanism. The default method of handling exceptions is sjlj. See the description of DWARF2_UNWIND_INFO and INCOMING_RETURN_ADDR_RTX in gcc/tm.texi for more info. Alan Modra may want this for gdb as well. Dave -- J. David Anglin dave.anglin@nrc.ca National Research Council of Canada (613) 990-0752 (FAX: 952-6605) From alan@lxorguk.ukuu.org.uk Mon, 27 Nov 2000 18:34:23 +0000 (GMT) Date: Mon, 27 Nov 2000 18:34:23 +0000 (GMT) From: Alan Cox alan@lxorguk.ukuu.org.uk Subject: [parisc-linux] gcc crashes/out of memory and groff With groff -fno-gcse does not help but -O0 does. Without -O0 you get an internal error. g++ -I. -I/usr/src/redhat/BUILD/groff-1.16/src/roff/troff -I/usr/src/redhat/BUILD/groff-1.16/src/include -I/usr/src/redhat/BUILD/groff-1.16/src/include -DHAVE_UNISTD_H=1 -DHAVE_DIRENT_H=1 -DHAVE_LIMITS_H=1 -DHAVE_SYS_DIR_H=1 -DHAVE_STDLIB_H=1 -DHAVE_STRINGS_H=1 -DSTDLIB_H_DECLARES_PUTENV=1 -DSTDIO_H_DECLARES_POPEN=1 -DSTDIO_H_DECLARES_PCLOSE=1 -DHAVE_SYS_NERR=1 -DHAVE_SYS_ERRLIST=1 -DHAVE_CC_LIMITS_H=1 -DRETSIGTYPE=void -DHAVE_STRUCT_EXCEPTION=1 -DHAVE_UNISTD_H=1 -DHAVE_GETPAGESIZE=1 -DHAVE_MMAP=1 -DHAVE_FMOD=1 -DHAVE_STRTOL=1 -DHAVE_GETCWD=1 -DHAVE_STRERROR=1 -DHAVE_PUTENV=1 -DHAVE_RENAME=1 -DHAVE_MKSTEMP=1 -DHAVE_STRCASECMP=1 -DHAVE_STRSEP=1 -DHAVE_STRDUP=1 -DSYS_SIGLIST_DECLARED=1 -O2 -mpa-risc-1-0 -fno-gcse -c env.cc env.cc: In member function `void environment::output_line (node *, hunits)': env.cc:1582: Internal error: Segmentation fault. Please submit a full bug report. See for instructions. make[2]: *** [env.o] Error 1 make[2]: Leaving directory `/usr/src/redhat/BUILD/groff-1.16/src/roff/troff' Alan From marteaut@esiee.fr Mon, 27 Nov 2000 21:31:09 +0100 Date: Mon, 27 Nov 2000 21:31:09 +0100 From: Thomas Marteau marteaut@esiee.fr Subject: [parisc-linux] Include trouble Hi folks, Just to know if it is a local problem. We have this warning when we cross compile the kernel: /linux/cvs/linux/include/linux/string.h:61: warning: conflicting types for built-in function `memset' /linux/cvs/linux/include/linux/string.h:64: warning: conflicting types for built-in function `memcpy' /linux/cvs/linux/include/linux/string.h:73: warning: conflicting types for built-in function `memcmp' Can we have your point of view? Bye, ESIEE Team From marteaut@esiee.fr Tue, 28 Nov 2000 00:17:24 +0100 Date: Tue, 28 Nov 2000 00:17:24 +0100 From: Thomas Marteau marteaut@esiee.fr Subject: [parisc-linux] Leds Hi all, We tried to implement the led power of 712 hp boxes. We call leds_init in main.c in init directory. Even though it is working, we are not sure where to put the source that must be completed for others models. We could make a LEDS directory in drivers put the file in the kernel directory We also put the source for the initialisation of keyboard leds in lasi_ps2_reset but we admit that no led is on. Is it true? How can we know? THX, ESIEE Team From alan@linuxcare.com.au Tue, 28 Nov 2000 12:12:03 +1100 (EST) Date: Tue, 28 Nov 2000 12:12:03 +1100 (EST) From: Alan Modra alan@linuxcare.com.au Subject: [parisc-linux] gcc crashes/out of memory and groff On Mon, 27 Nov 2000, Alan Cox wrote: > With groff -fno-gcse does not help but -O0 does. Without -O0 you get an > internal error. Cross compiling from an x86-linux box with enough memory+swap (256M + 2G), env.cc eventually compiled for me using the default -O2 optimisation level. I had a crash later when compiling preproc/tbl/table.cc, so that's nothing to boast about. table.cc: In member function `void table::build_span_list ()': table.cc:2009: Internal error: Segmentation fault. Worse, when I added "-Q -da" to see what was happening, the compile succeeded - and also succeeded with either of -Q or -da alone. So I ran cc1plus under gdb, and that too failed to crash. :-( Maybe a garbage collection or uninitialised var bug? Alan Modra -- Linuxcare. Support for the Revolution. From alan@linuxcare.com.au Tue, 28 Nov 2000 15:59:54 +1100 (EST) Date: Tue, 28 Nov 2000 15:59:54 +1100 (EST) From: Alan Modra alan@linuxcare.com.au Subject: [parisc-linux] Include trouble On Mon, 27 Nov 2000, Thomas Marteau wrote: > Can we have your point of view? Your version of gcc expects the size_t parameter to all these functions to be "unsigned int", whereas the 2000/11/18 changes to linux/include/asm-parisc/posix_types.h made __kernel_size_t "unsigned long". As far as I understand, gcc's cpp has a built-in definition of size_t, __SIZE_TYPE__, and it ultimately gets it's idea of the definition from the kernel includes on the machine where gcc was compiled. ie. recompile gcc with the new kernel headers installed, and the problem should go away. For 32-bit hppa-linux, sizeof(int) == sizeof(long) so there shouldn't be any practical consequence other than these warning messages. There might be some "interesting" problems on hppa64-linux - I'm not sure. Alan Modra -- Linuxcare. Support for the Revolution. From alan@linuxcare.com.au Tue, 28 Nov 2000 20:19:20 +1100 (EST) Date: Tue, 28 Nov 2000 20:19:20 +1100 (EST) From: Alan Modra alan@linuxcare.com.au Subject: [parisc-linux] Include trouble On Tue, 28 Nov 2000, Alan Modra wrote: > As far as I understand, gcc's cpp has a built-in definition of size_t, > __SIZE_TYPE__, and it ultimately gets it's idea of the definition from the > kernel includes on the machine where gcc was compiled. ie. recompile gcc > with the new kernel headers installed, and the problem should go away. No, that's wrong. __SIZE_TYPE__ comes from `#define SIZE_TYPE' in gcc/config/pa/pa-linux{,64}.h I'll check in a patch to gcc in a few moments. Alan -- Linuxcare. Support for the Revolution. From marteaut@esiee.fr Tue, 28 Nov 2000 16:07:04 +0100 Date: Tue, 28 Nov 2000 16:07:04 +0100 From: Thomas Marteau marteaut@esiee.fr Subject: [parisc-linux] Mouse driver for PS/2 Hi all, We appreciate if someone can explain where we can find request_irq and request_region in hp_psaux.c and also, what are they doing? Thanks, ESIEE Team From deller@gmx.de Tue, 28 Nov 2000 18:21:34 +0100 Date: Tue, 28 Nov 2000 18:21:34 +0100 From: Helge Deller deller@gmx.de Subject: [parisc-linux] Mouse driver for PS/2 On Tuesday 28 November 2000 16:07, Thomas Marteau wrote: > Hi all, Hi Thomas, > > We appreciate if someone can explain where we can find request_irq #include and /arch/parisc/kernel/irq.c request_irq() binds the given interrupt-number to a function (if possible). > and > request_region #include request_region only marks (and tests) an I/O-region as used by a driver and makes this information visible via /proc/iomem and /proc/ioports. > in hp_psaux.c and also, > what are they doing? > > Thanks, > ESIEE Team From wferguson@server01.chatspace.com Tue, 28 Nov 2000 09:35:36 -0800 Date: Tue, 28 Nov 2000 09:35:36 -0800 From: William Ferguson wferguson@server01.chatspace.com Subject: [parisc-linux] PDC firmware revision FAQ update This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C05961.9E1AB8A8 Content-Type: text/plain; charset="iso-8859-1" Is the web server at www.parisc-linux.org down? Can't seem to connect from San Diego. -----Original Message----- From: Grant Grundler [mailto:grundler@cup.hp.com] Sent: Friday, November 17, 2000 1:51 PM To: parisc-linux@puffin.external.hp.com Subject: [parisc-linux] PDC firmware revision FAQ update Hi folks, The issue of PDC/firmware revs came up locally and sounded like a FAQ. I added "10. How can I check if the PDC (firmware) revision is the latest?" and what I knew/could find to our FAQ at: http://www.parisc-linux.org/faq.html The new FAQ entry should be visible to the world in the next hour or so. **** WARNING **** Firmware upgrades can *kill* your machine! **** WARNING **** Don't do it just because. Read the FAQ carefully. Take the time to figure out why you might need the upgrade and expose yourself to this risk. grant ps. please don't ask me why your favorite machine's PDC isn't listed. I don't run the referenced sites. --------------------------------------------------------------------------- To unsubscribe: send e-mail to parisc-linux-request@thepuffingroup.com with `unsubscribe' as the subject. ------_=_NextPart_001_01C05961.9E1AB8A8 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [parisc-linux] PDC firmware revision FAQ update

Is the web server at www.parisc-linux.org down?  = Can't seem to connect from San Diego.

-----Original Message-----
From: Grant Grundler [mailto:grundler@cup.hp.com]
Sent: Friday, November 17, 2000 1:51 PM
To: parisc-linux@puffin.external.hp.com
Subject: [parisc-linux] PDC firmware revision FAQ = update


Hi folks,

The issue of PDC/firmware revs came up locally and = sounded like a FAQ.
I added

    "10. How can I check if the = PDC (firmware) revision is the latest?"

and what I knew/could find to our FAQ at:

        http://www.parisc-linux.org/faq.html

The new FAQ entry should be visible to the world in = the next hour or so.


    **** WARNING ****
    Firmware upgrades can *kill* your = machine!
    **** WARNING ****

Don't do it just because. Read the FAQ carefully. = Take the
time to figure out why you might need the upgrade = and expose
yourself to this risk.

grant

ps. please don't ask me why your favorite machine's = PDC isn't listed.
   I don't run the referenced = sites.

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

------_=_NextPart_001_01C05961.9E1AB8A8-- From dave@hiauly1.hia.nrc.ca Tue, 28 Nov 2000 12:37:28 -0500 (EST) Date: Tue, 28 Nov 2000 12:37:28 -0500 (EST) From: John David Anglin dave@hiauly1.hia.nrc.ca Subject: [parisc-linux] Include trouble > On Tue, 28 Nov 2000, Alan Modra wrote: > > > As far as I understand, gcc's cpp has a built-in definition of size_t, > > __SIZE_TYPE__, and it ultimately gets it's idea of the definition from the > > kernel includes on the machine where gcc was compiled. ie. recompile gcc > > with the new kernel headers installed, and the problem should go away. > > No, that's wrong. __SIZE_TYPE__ comes from `#define SIZE_TYPE' in > gcc/config/pa/pa-linux{,64}.h I'll check in a patch to gcc in a few > moments. Hmm. Most 32 bit systems use "unsigned int" rather than "unsigned long". Using "unsigned long" might cause problems with packages like libio. I know there is a problem if off_t is not the same as size_t. Dave -- J. David Anglin dave.anglin@nrc.ca National Research Council of Canada (613) 990-0752 (FAX: 952-6605) From grundler@cup.hp.com Tue, 28 Nov 2000 09:49:26 -0800 Date: Tue, 28 Nov 2000 09:49:26 -0800 From: Grant Grundler grundler@cup.hp.com Subject: [parisc-linux] Mouse driver for PS/2 Thomas Marteau wrote: > Hi all, > > We appreciate if someone can explain where we can find request_irq and > request_region in hp_psaux.c and also, what are they doing? include/linux/sched.h:extern int request_irq(unsigned int, ...) (Implementation is in arch/parisc/kernel/irq.c) The request_irq() "allocates" an IRQ line for use by the device - this program the PIC (or APIC) on x86 platforms. request_irq() is also how an interrupt handler is associated with a specific IRQ line. Since PA Risc CPU's don't have IRQ lines going into them, IRQ's are virtualized and don't always represent a physical IRQ line. Under LASI, see gsc_alloc_irq(&gsc_irq) usage in drivers/gsc/lasi.c. lasi_find_irq() helps associate the PS/2 interrupt handler with the correct IRQ line which is internal to lasi. include/linux/ioport.h:#define request_region(start,n,name) ... request_region() will reserve a range of I/O port address from the global I/O space. request_mem_region() does the same for MMIO. Drivers that use inb/outb (as defined in include/asm-parisc/io.h) must use request_region(). Drivers that use gsc_readb/gsc_writeb (as defined in include/asm-parisc/gsc.h) must use request_mem_region(). Collisions are probably occuring where a driver originally used inb/outb and those were redefined to use gsc_readb/writeb functions. But the driver is still using request_region(). And it doesn't help that I may have broken some of the resource mgt with some code I committed last night. It worked on my boxes (A180/C3K) but broke on other folks. Paul Bame helped find/fix one bug but I shouldn't be surprised if more bugs are still out there. I will be fixing some known resource failure problems on A500. Please post problems on other platforms to parisc-linux list as well. hope this helps, grant Grant Grundler Unix Systems Enablement Lab +1.408.447.7253 From grundler@cup.hp.com Tue, 28 Nov 2000 09:53:37 -0800 Date: Tue, 28 Nov 2000 09:53:37 -0800 From: Grant Grundler grundler@cup.hp.com Subject: [parisc-linux] PDC firmware revision FAQ update William Ferguson wrote: > Is the web server at www.parisc-linux.org down? Can't seem to connect from > San Diego. Yes. Linuxcare is having some DNS problems right now and they host that site. Any forecasts on when that will be back up? grant From bame@noam.fc.hp.com Tue, 28 Nov 2000 12:27:09 -0700 Date: Tue, 28 Nov 2000 12:27:09 -0700 From: Paul Bame bame@noam.fc.hp.com Subject: [parisc-linux] Include trouble = Hmm. Most 32 bit systems use "unsigned int" rather than "unsigned long". I will be happy to change it back to unsigned int. The only reason I used unsigned long is because it seems off_t wants to be, to a first approximation, the word length of the machine, and 'long' does that. = Using "unsigned long" might cause problems with packages like libio. = I know there is a problem if off_t is not the same as size_t. What problem is that? I'm working on a proposal for the palinux type sizes at the moment. One dilema is that off_t is supposed to be good for file offsets, which these days means it should be 64 bits. size_t refers to the sizes of objects which are expected to fit in RAM, so should be the word size of the machine. So there's a conflict because one logic suggests 64-bit off_t and 32-bit size_t on 32-bit palinux, but your statement suggests they should be the same size. Any ideas? However I'm leaning towards leaning with the older 32-bit off_t because we might not want to be the first ones to fix all the problems with making it 64 bits on a 32-bit machine. -P From marteaut@esiee.fr Tue, 28 Nov 2000 20:30:30 +0100 Date: Tue, 28 Nov 2000 20:30:30 +0100 From: Thomas Marteau marteaut@esiee.fr Subject: [parisc-linux] Mouse driver for PS/2 Hi all, We have a sample of code for the mouse driver. But, we would like to know how the Puffin would like the implementation of the driver. Because of drag & drop..., do you want two different interrupt functions or a single that does a redirection. Also , we have seen that busmouse.c is quite interesting for our driver. Do we make a copy and call it hp_mouse.c? Thanks for your answer, ESIEE Team For a better future with a mouse! From alan@lxorguk.ukuu.org.uk Tue, 28 Nov 2000 20:02:26 +0000 (GMT) Date: Tue, 28 Nov 2000 20:02:26 +0000 (GMT) From: Alan Cox alan@lxorguk.ukuu.org.uk Subject: [parisc-linux] Include trouble > One dilema is that off_t is supposed to > be good for file offsets, which these days means it should be 64 bits. off_t should be a natural type. So it should be 32bits. glibc 2.2 deals with the 64bit I/O stuff nicely > However I'm leaning towards leaning with the older 32-bit off_t because > we might not want to be the first ones to fix all the problems with > making it 64 bits on a 32-bit machine. Go 32bit. Linus will probably refuse to touch a 32bit port using longlong internally for off-t From dave@hiauly1.hia.nrc.ca Tue, 28 Nov 2000 15:24:26 -0500 (EST) Date: Tue, 28 Nov 2000 15:24:26 -0500 (EST) From: John David Anglin dave@hiauly1.hia.nrc.ca Subject: [parisc-linux] Include trouble > = Hmm. Most 32 bit systems use "unsigned int" rather than "unsigned long". > > I will be happy to change it back to unsigned int. The only reason > I used unsigned long is because it seems off_t wants to be, to a > first approximation, the word length of the machine, and 'long' does > that. Agreed. > = Using "unsigned long" might cause problems with packages like libio. > > > = I know there is a problem if off_t is not the same as size_t. > > What problem is that? I'm working on a proposal for the palinux > type sizes at the moment. It is simply dumb coding that hasn't been fixed. There are inconsistencies between the interface declarations and implementations. The old libio is on the way out. > One dilema is that off_t is supposed to > be good for file offsets, which these days means it should be 64 bits. > size_t refers to the sizes of objects which are expected to fit in > RAM, so should be the word size of the machine. So there's a conflict > because one logic suggests 64-bit off_t and 32-bit size_t on 32-bit palinux, > but your statement suggests they should be the same size. Any ideas? Only, because of poorly written legacy code. I agree that off_t should be 64 bits on 32 bit platforms today. > However I'm leaning towards leaning with the older 32-bit off_t because > we might not want to be the first ones to fix all the problems with > making it 64 bits on a 32-bit machine. Maybe it isn't that bad because I noticed at least one port used unsigned long long for off_t. Dave -- J. David Anglin dave.anglin@nrc.ca National Research Council of Canada (613) 990-0752 (FAX: 952-6605) From dave@hiauly1.hia.nrc.ca Tue, 28 Nov 2000 15:33:52 -0500 (EST) Date: Tue, 28 Nov 2000 15:33:52 -0500 (EST) From: John David Anglin dave@hiauly1.hia.nrc.ca Subject: [parisc-linux] Include trouble > Maybe it isn't that bad because I noticed at least one port used unsigned > long long for off_t. Take that back. It was __kernel_loff_t. Just go with typedef unsigned int __kernel_size_t; typedef long __kernel_off_t; #ifdef __GNUC__ typedef long long __kernel_loff_t; #endif for the 32 bit port. Dave -- J. David Anglin dave.anglin@nrc.ca National Research Council of Canada (613) 990-0752 (FAX: 952-6605) From deller@gmx.de Tue, 28 Nov 2000 21:41:53 +0100 Date: Tue, 28 Nov 2000 21:41:53 +0100 From: Helge Deller deller@gmx.de Subject: [parisc-linux] Mouse driver for PS/2 On Tuesday 28 November 2000 20:30, Thomas Marteau wrote: > Hi all, Hi Thomas, > > We have a sample of code for the mouse driver. But, we would like to > know how the Puffin would like the implementation of the driver. Because > of drag & drop..., do you want two different interrupt functions or a > single that does a redirection. Also , we have seen that busmouse.c is > quite interesting for our driver. Do we make a copy and call it > hp_mouse.c? I would propose, that you check in hp_mouse.c and use different interrupt functions for now. Changing it later shouldn't be too difficult. Greetings, Helge. > > Thanks for your answer, > ESIEE Team > For a better future with a mouse! From doneill@linuxcare.com Tue, 28 Nov 2000 16:08:49 -0500 (EST) Date: Tue, 28 Nov 2000 16:08:49 -0500 (EST) From: Dave O'Neill doneill@linuxcare.com Subject: [parisc-linux] PDC firmware revision FAQ update On Tue, 28 Nov 2000, Grant Grundler wrote: > Yes. Linuxcare is having some DNS problems right now and > they host that site. Any forecasts on when that will be back up? Well, it looks like our DNS issues are fixed... the site should be accessible now. Dave -- Dave O'Neill, Senior Linux Consultant, Linuxcare, Inc. desk: (613) 562-9949 fax: (613) 562-9700 cell: (613) 223-0219 doneill@linuxcare.com http://www.linuxcare.com/ From bame@noam.fc.hp.com Tue, 28 Nov 2000 14:21:05 -0700 Date: Tue, 28 Nov 2000 14:21:05 -0700 From: Paul Bame bame@noam.fc.hp.com Subject: [parisc-linux] Include trouble = Go 32bit. Linus will probably refuse to touch a 32bit port using longlong = internally for off-t Hmmm, too bad, since we have few palinux backwards compatibility issues and could just have the __USE_FILE_OFFSET64 glibc magic be a no-op rather than supporting all those extra *64 syscalls. Plus we'd need considerably fewer syscall translators to run 32-bit apps on 64-bit kernel (but might need more for 32-bit hpux apps). It seems illogical to make a file-system-related data type different based on cpu word size but I understand this isn't simple -- oh well. Seems like the consensus is 32-bit off_t on 32-bit kernel and just live with all those *64 syscalls -- many not supported on palinux yet I notice. -P From alan@lxorguk.ukuu.org.uk Tue, 28 Nov 2000 21:58:56 +0000 (GMT) Date: Tue, 28 Nov 2000 21:58:56 +0000 (GMT) From: Alan Cox alan@lxorguk.ukuu.org.uk Subject: [parisc-linux] Include trouble > Seems like the consensus is 32-bit off_t on 32-bit kernel and just > live with all those *64 syscalls -- many not supported on palinux > yet I notice. Remember providing you use off_t you can just tell glibc to do all the work for you and write with a 64bit off_t to userspace From alan@linuxcare.com.au Wed, 29 Nov 2000 10:27:20 +1100 (EST) Date: Wed, 29 Nov 2000 10:27:20 +1100 (EST) From: Alan Modra alan@linuxcare.com.au Subject: [parisc-linux] Include trouble On Tue, 28 Nov 2000, John David Anglin wrote: > Hmm. Most 32 bit systems use "unsigned int" rather than "unsigned long". There's some precedent for using "unsigned long", as that is what is used on 32-bit hpux11 and osf gcc targets. current sourceware CVS gcc/config/pa/: $ grep SIZE_TYPE * grep: CVS: Is a directory pa-64.h:#undef SIZE_TYPE pa-64.h:#define SIZE_TYPE "long unsigned int" pa-hpux.h:#undef SIZE_TYPE pa-hpux.h:#define SIZE_TYPE "unsigned int" pa-hpux11.h:#undef SIZE_TYPE pa-hpux11.h:#define SIZE_TYPE "long unsigned int" pa-hpux7.h:#undef SIZE_TYPE pa-hpux7.h:#define SIZE_TYPE "unsigned int" pa-linux.h:#undef SIZE_TYPE pa-linux.h:#define SIZE_TYPE "unsigned int" pa-osf.h:#undef SIZE_TYPE pa-osf.h:#define SIZE_TYPE "long unsigned int" pa-pro-end.h:#undef SIZE_TYPE pa-pro-end.h:#define SIZE_TYPE "unsigned int" pa.h:#define SIZE_TYPE "unsigned int" Some further grepping shows quite a number of other 32-bit gcc targets using "unsigned long", but I didn't see any 32-bit linux targets in the list. Paul, If you change back to "unsigned int", please change gcc/config/pa/pa-linux.h too. Alan -- Linuxcare. Support for the Revolution. From Frank.Butter@otto.de Wed, 29 Nov 2000 11:50:39 +0100 Date: Wed, 29 Nov 2000 11:50:39 +0100 From: Butter, Frank Frank.Butter@otto.de Subject: [parisc-linux] hardware to all here I was annaouncing an offer for hp hardware recently: it'll take longer than initially expected to convince our bosses ;-/ please stay patient... frank From matthias@archimed.math.uni-mannheim.de Wed, 29 Nov 2000 20:52:38 +0100 (MET) Date: Wed, 29 Nov 2000 20:52:38 +0100 (MET) From: Matthias Juchem matthias@archimed.math.uni-mannheim.de Subject: [parisc-linux] parisc-0.5.iso and stack trace Hi there. I've just downloaded the ISO images and tried to boot an 9000/705. I keep getting a stack trace. Can you tell me which part of the trace I can send you so that you could eventually tell me what is wrong? TIA, Matthias From dave@hiauly1.hia.nrc.ca Wed, 29 Nov 2000 17:05:31 -0500 (EST) Date: Wed, 29 Nov 2000 17:05:31 -0500 (EST) From: John David Anglin dave@hiauly1.hia.nrc.ca Subject: [parisc-linux] gcc crashes/out of memory and groff > With groff -fno-gcse does not help but -O0 does. Without -O0 you get an > internal error. > > g++ -I. -I/usr/src/redhat/BUILD/groff-1.16/src/roff/troff -I/usr/src/redhat/BUILD/groff-1.16/src/include -I/usr/src/redhat/BUILD/groff-1.16/src/include -DHAVE_UNISTD_H=1 -DHAVE_DIRENT_H=1 -DHAVE_LIMITS_H=1 -DHAVE_SYS_DIR_H=1 -DHAVE_STDLIB_H=1 -DHAVE_STRINGS_H=1 -DSTDLIB_H_DECLARES_PUTENV=1 -DSTDIO_H_DECLARES_POPEN=1 -DSTDIO_H_DECLARES_PCLOSE=1 -DHAVE_SYS_NERR=1 -DHAVE_SYS_ERRLIST=1 -DHAVE_CC_LIMITS_H=1 -DRETSIGTYPE=void -DHAVE_STRUCT_EXCEPTION=1 -DHAVE_UNISTD_H=1 -DHAVE_GETPAGESIZE=1 -DHAVE_MMAP=1 -DHAVE_FMOD=1 -DHAVE_STRTOL=1 -DHAVE_GETCWD=1 -DHAVE_STRERROR=1 -DHAVE_PUTENV=1 -DHAVE_RENAME=1 -DHAVE_MKSTEMP=1 -DHAVE_STRCASECMP=1 -DHAVE_STRSEP=1 -DHAVE_STRDUP=1 -DSYS_SIGLIST_DECLARED=1 -O2 -mpa-risc-1-0 -fno-gcse -c env.cc > env.cc: In member function `void environment::output_line (node *, hunits)': > env.cc:1582: Internal error: Segmentation fault. > Please submit a full bug report. > See for instructions. > make[2]: *** [env.o] Error 1 > make[2]: Leaving directory `/usr/src/redhat/BUILD/groff-1.16/src/roff/troff' This error is also exception related but appears different from the memory explosion. It occurs in scan_region in except.c. The memory explosion that occurs without -fno-gcse does seem to occur in the gcse pass as I suspected. I need to rebuild gcc with debugging to get further. I was able to build the groff package with `CXXFLAGS="-O3 -fno-exceptions"'. Dave -- J. David Anglin dave.anglin@nrc.ca National Research Council of Canada (613) 990-0752 (FAX: 952-6605) From delyra@latt.if.usp.br Wed, 29 Nov 2000 20:22:47 -0200 (BRST) Date: Wed, 29 Nov 2000 20:22:47 -0200 (BRST) From: Jorge L. deLyra delyra@latt.if.usp.br Subject: [parisc-linux] HP 9000/735-125 I just booted the palinux-0.5.iso CD on a HP 9000 model 735 workstation. It went on quite a bit before hanging immediatelly after reporting the serial ports. Gave large amount of what looks like traceback or state information. Question: would it do anyone any good if I tried to get everything the kernel said before the hang into a message in this list? Cheers, ---------------------------------------------------------------- Jorge L. deLyra, Associate Professor of Physics The University of Sao Paulo, IFUSP-DFMA For more information: finger delyra@latt.if.usp.br ---------------------------------------------------------------- From grundler@cup.hp.com Wed, 29 Nov 2000 15:19:10 -0800 Date: Wed, 29 Nov 2000 15:19:10 -0800 From: Grant Grundler grundler@cup.hp.com Subject: [parisc-linux] HP 9000/735-125 "Jorge L. deLyra" wrote: > I just booted the palinux-0.5.iso CD on a HP 9000 model 735 workstation. > It went on quite a bit before hanging immediatelly after reporting the > serial ports. Gave large amount of what looks like traceback or state > information. Question: would it do anyone any good if I tried to get > everything the kernel said before the hang into a message in this list? Certainly. I won't be able to debug the problems since I (a) don't have the time too (unless it's obvious) and (b) don't have a 735 setup for testing. This is becoming a FAQ: "My system crashed after ... What should I do next?" I'm thinking people in the support space would know how to write this one really well :^) Is I get one in the mail, I'll add it to our FAQ. thanks, grant Grant Grundler Unix Systems Enablement Lab +1.408.447.7253 From smoret@uci.edu Wed, 29 Nov 2000 15:28:20 -0800 Date: Wed, 29 Nov 2000 15:28:20 -0800 From: Steve Moret smoret@uci.edu Subject: [parisc-linux] HP 9000/735-125 Jorge, I have a 735-125 and am able to net-boot it on a custom configured kernel as long as I disable the ASP parallel ports. It works quite well using an NFS root as I cannot get the SCSI hard drives to mkfs. I was going to try and debug it but have yet to find the free time. I can e-mail you my working .config for the kernel, or build kernels (tested on my own 735) for people if they need them. -- Steve Moret smoret@uci.edu > -----Original Message----- > From: Grant Grundler [mailto:grundler@cup.hp.com] > Sent: Wednesday, November 29, 2000 3:19 PM > To: Jorge L. deLyra > Cc: parisc-linux@thepuffingroup.com > Subject: Re: [parisc-linux] HP 9000/735-125 > > > "Jorge L. deLyra" wrote: > > I just booted the palinux-0.5.iso CD on a HP 9000 model 735 workstation. > > It went on quite a bit before hanging immediatelly after reporting the > > serial ports. Gave large amount of what looks like traceback or state > > information. Question: would it do anyone any good if I tried to get > > everything the kernel said before the hang into a message in this list? > > Certainly. I won't be able to debug the problems since I (a) don't have > the time too (unless it's obvious) and (b) don't have a 735 setup > for testing. > > This is becoming a FAQ: > "My system crashed after ... What should I do next?" > > I'm thinking people in the support space would know how to write > this one really well :^) > Is I get one in the mail, I'll add it to our FAQ. > > thanks, > grant > > > Grant Grundler > Unix Systems Enablement Lab > +1.408.447.7253 > > ------------------------------------------------------------------ > --------- > To unsubscribe: send e-mail to > parisc-linux-request@thepuffingroup.com with > `unsubscribe' as the subject. > > From deller@gmx.de Thu, 30 Nov 2000 01:10:51 +0100 Date: Thu, 30 Nov 2000 01:10:51 +0100 From: Helge Deller deller@gmx.de Subject: [parisc-linux] HP 9000/735-125 X On Thursday 30 November 2000 00:28, Steve Moret wrote: > I have a 735-125 and am able to net-boot it on a custom configured kernel > as long as I disable the ASP parallel ports. .... Steve, I really would like to get the parallel-port problems on ASP get fixed as soon as possible. Could you please mail me your bootlog (with parport enabled), so I can try to track down the problem. Maybe you can also check out CVS again, and test if this version works for you ? Thanks, Helge Deller From alan@lxorguk.ukuu.org.uk Thu, 30 Nov 2000 02:38:56 +0000 (GMT) Date: Thu, 30 Nov 2000 02:38:56 +0000 (GMT) From: Alan Cox alan@lxorguk.ukuu.org.uk Subject: [parisc-linux] XFree status I have a server linked. inb/inw/outb/outw and friends are right now null functions until I fill them in. Thats not a big deal. Initially I'll probably use /dev/port but for speed I hope everyone uses mmio based hardware. Also is this bad ? /usr/bin/ld: lbxdix.o(.text+0x6fc): fixing R_PARISC_DPREL21L /usr/bin/ld: lbxprop.o(.text+0xde4): fixing R_PARISC_DPREL21L /usr/bin/ld: lbxprop.o(.text+0xdf4): fixing R_PARISC_DPREL21L Alan phux:/usr/src/redhat/BUILD/XFree86-4.0.1/xc/programs/Xserver# ./XFree86 XFree86 Version 4.0.1a / X Window System (protocol Version 11, revision 0, vendor release 6400) Release Date: 2 August 2000 If the server is older than 6-12 months, or if your card is newer than the above date, look for a newer version before reporting problems. (see http://www.XFree86.Org/FAQ) Operating System: Linux 2.4.0-test6 parisc [ELF] (==) Log file: "/var/log/XFree86.0.log", Time: Wed Nov 29 19:40:16 2000 (==) Using config file: "/etc/X11/XF86Config" Parse warning on line 77 of section Keyboard in file /etc/X11/XF86Config Ignoring obsolete keyword "LeftAlt". Parse error on line 77 of section Keyboard in file /etc/X11/XF86Config "Meta" is not a valid keyword in this section. (EE) Problem parsing the config file (EE) Error from xf86HandleConfigFile() Fatal server error: no screens found When reporting a problem related to a server crash, please send the full server output, not just the last messages. This can be found in the log file "/var/log/XFree86.0.log". Please reports problems to xfree86@xfree86.org. From alan@linuxcare.com.au Thu, 30 Nov 2000 14:41:48 +1100 (EST) Date: Thu, 30 Nov 2000 14:41:48 +1100 (EST) From: Alan Modra alan@linuxcare.com.au Subject: [parisc-linux] XFree status On Thu, 30 Nov 2000, Alan Cox wrote: > Also is this bad ? > > /usr/bin/ld: lbxdix.o(.text+0x6fc): fixing R_PARISC_DPREL21L No. It's a symptom of a variable's "constness" being declared differently from the way the variable is defined. For instance, referring to "extern int foo" in one object with foo defined as "const int foo" in another. I'll be removing the linker warning at some stage. Alan Modra -- Linuxcare. Support for the Revolution. From grundler@cup.hp.com Wed, 29 Nov 2000 21:18:14 -0800 Date: Wed, 29 Nov 2000 21:18:14 -0800 From: Grant Grundler grundler@cup.hp.com Subject: [parisc-linux] XFree status Alan Cox wrote: > I have a server linked. Alan - that's Cool! Wow! > inb/inw/outb/outw and friends are right now null > functions until I fill them in. Thats not a big deal. Initially I'll probably > use /dev/port but for speed I hope everyone uses mmio based hardware. All HP graphics for PARISC are memory mapped. Both "GSC" and PCI flavors. But I'm pretty clueless how linux X server finds/talks to a frame buffer. For HPUX, the graphics driver supports some ioctl()'s. Any references to describe how it works for linux? parisc-linux doesn't create kernel virtual addresses for MMIO. Which interface is used to create user virtual addresses for MMIO? (In general - not just for frame buffers) Is the PCI address passed to user space? I'm wondering if/how "bus_to_virt()" type translations take place. sorry for the many questions... grant Grant Grundler Unix Systems Enablement Lab +1.408.447.7253 From gibreel@pobox.com 30 Nov 2000 00:09:03 -0800 Date: 30 Nov 2000 00:09:03 -0800 From: Stephen Zander gibreel@pobox.com Subject: [parisc-linux] CVS linux Vs. -test10 >>>>> "Grant" == Grant Grundler writes: Grant> For the record, the second issue bdale made clear was we Grant> need "boot floppies" debian package working. We don't need Grant> more ISO images (no offense to pjlahaie for his good Grant> work). "Boot floppies" is a pre-requisite to becoming part Grant> of the next debian release. Given I still don't have a clue Grant> how to build a debian package and I can still contribute Grant> alot in other areas, it doesn't make sense for me to do it Grant> myself. Oooh, there's a reason for me to finally get the 712/80 under my desk to be more than a foot-rest. I'll see what I can do about this. Note that the likelihood of Debian releasing woody anytime soon is vanishingly small, so this dosen't have to happen Right Now. -- Stephen (debian developer) "Strange women lying in ponds distributing swords is no basis for a system of government" From smoret@uci.edu Thu, 30 Nov 2000 01:20:28 -0800 Date: Thu, 30 Nov 2000 01:20:28 -0800 From: Steve Moret smoret@uci.edu Subject: [parisc-linux] HP 9000/735-125 Helge, My mistake! I did a full build with todays CVS and parport didn't die. So somewhere between the 17th and now parport must have been fixed. Now, maybe you can help me identify my SCSI problem. I don't know if it is because of driver issues or a bad disk (completly likely). Do other people have the Fast SCSI2 working on their 735s? Whenever I do a mke2fs (after partitioning the drive with fdisk ok) it dies. At bootup I get: SCSI subsystem driver Revision: 1.00 sim700: Couldn't get consistent shared memory sim700: Configuring 53c700 (SCSI-ID 7) at f0825100, IRQ 86 scsi0: Revision 0x0 Post test1, istat 05, sstat0 00, dstat 84 sim700: WARNING IRQ probe failed, (returned 0) scsi0: WARNING: target data areas are not dma coherent! scsi0: test 1 completed ok. scsi0: sim700_intr_handle() called with no interrupt scsi0 : LASI/Simple 53c7xx Vendor: HP Model: C2235 Rev: 0B11 Type: Direct-Access ANSI SCSI revision: 02 Vendor: HP Model: C2235 Rev: 0B11 Type: Direct-Access ANSI SCSI revision: 02 Detected scsi disk sda at scsi0, channel 0, id 5, lun 0 Detected scsi disk sdb at scsi0, channel 0, id 6, lun 0 SCSI device sda: 825012 512-byte hdwr sectors (422 MB) Partition check: sda: sda1 sda2 SCSI device sdb: 825012 512-byte hdwr sectors (422 MB) sdb: sdb1 sdb2 And then if I try to mke2fs the disk I get: hp735:~# fdisk -l /dev/sda Disk /dev/sda: 13 heads, 62 sectors, 1023 cylinders Units = cylinders of 806 * 512 bytes Device Boot Start End Blocks Id System /dev/sda1 1 910 366699 83 Linux /dev/sda2 911 1023 45539 82 Linux swap hp735:~# mke2fs /dev/sda1 mke2fs 1.19, 13-Jul-2000 for EXT2 FS 0.5b, 95/08/09 Filesystem label= OS type: Linux Block size=1024 (log=0) Fragment size=1024 (log=0) 91800 inodes, 366699 blocks 18334 blocks (5.00%) reserved for the super user First data block=1 45 block groups 8192 blocks per group, 8192 fragments per group 2040 inodes per group Superblock backups stored on blocks: 8193, 24577, 40961, 57345, 73729, 204801, 221185 Writing inode tables: done Writing superblocks and filesystem accounting information: scsi0: Unable to abort command for target 5 scsi0: Unable to send Bus Device Reset for target 5 scsi0: Unable to do SCSI bus reset scsi0: >>>>>>>>>>>> Host reset <<<<<<<<<<<< scsi0: istat = 0c, sstat0 = 00, sstat1 = 00, dstat = 00 scsi0: dsp = 0cf15038 (script[0x140e]), dsps = 0cf15cde, target = 0 scsi0: Failing command for ID5 scsi0: sim700_intr_handle() called with no interrupt pa11_dma_map_single(PCI_DMA_NONE) called by c01cb6d4 kernel BUG at pci-dma.c:392! pa11_dma_unmap_single(PCI_DMA_NONE) called by c01ca3bc kernel BUG at pci-dma.c:403! SCSI disk error : host 0 channel 0 id 5 lun 0 return code = 2 I/O error: dev 08:01, sector 268 I/O error: dev 08:01, sector 270 I/O error: dev 08:01, sector 396 I/O error: dev 08:01, sector 16396 I/O error: dev 08:01, sector 16524 I/O error: dev 08:01, sector 16652 Of course the I/O errors continue on for a long time. Are these bad drives? Or is there a problem with the driver that still needs to be worked out? Thanks for all your help, I hope my spews of debug output are helpful, -- Steve Moret smoret@uci.edu > -----Original Message----- > From: Helge Deller [mailto:deller@gmx.de] > Sent: Wednesday, November 29, 2000 4:11 PM > To: Steve Moret > Cc: parisc-linux@thepuffingroup.com > Subject: Re: [parisc-linux] HP 9000/735-125 > > I really would like to get the parallel-port problems on ASP get fixed as > soon as possible. > Could you please mail me your bootlog (with parport enabled), so > I can try to > track down the problem. > Maybe you can also check out CVS again, and test if this version > works for > you ? From delyra@latt.if.usp.br Thu, 30 Nov 2000 08:58:22 -0200 (BRST) Date: Thu, 30 Nov 2000 08:58:22 -0200 (BRST) From: Jorge L. deLyra delyra@latt.if.usp.br Subject: [parisc-linux] HP 9000/735-125 > > information. Question: would it do anyone any good if I tried to get > > everything the kernel said before the hang into a message in this list? > > Certainly. I won't be able to debug the problems since I (a) don't have > the time too (unless it's obvious) and (b) don't have a 735 setup > for testing. OK, here goes. I want to congratulate you all on this effort. We have five of these HP-9000 stations here, quite old by now. They used to be our main number crunching force. They are wonderfully built hardware in bad need of a wonderful system on them! |:-) ---------------------------------------------------------------- Jorge L. deLyra, Associate Professor of Physics The University of Sao Paulo, IFUSP-DFMA For more information: finger delyra@latt.if.usp.br ---------------------------------------------------------------- Seyon Copyright (c) 1992-1993 Muhammad M. Saggaf. All rights reserved. Version 2 rev. 20c i586-Linux steve@hammer 05/23/99 20:19:22. Locating Modems... Modem `/dev/ttyS0' is Available. (c) Copyright. Hewlett-Packard Company. 1992. All rights reserved. PDC ROM rev. 2.7 IODC ROM rev. 1.1 80 MB of memory configured and tested. Searching for Potential Boot Devices. To terminate search, press and hold the ESCAPE key. Device Selection Device Path Device Type ---------------------------------------------------------------------------- P0 scsi.6.0 HP C3725S P1 scsi.4.0 TOSHIBA CD-ROM XM-3301TA b) Boot from specified device s) Search for bootable devices a) Enter Boot Administration mode x) Exit and continue boot sequence ?) Help Select from menu: b p1 Trying scsi.4.0 Boot path initialized. Attempting to load IPL. Soft booted. palo ipl bame@noam Tue Oct 31 14:18:02 MST 2000 0/vmlinux 2140145 bytes @ 0x6f9800 0/palo-cmdline '0/vmlinux ROOT=/ TERM=LINUX root=/dev/scd0' Kernel: partition 0 file /vmlinux ELF32 executable Entry 00100150 first 00100000 n 4 Segment 0 load 00100000 size 1460344 mediaptr 0x1000 Segment 1 load 00266000 size 179048 mediaptr 0x166000 Segment 2 load 00294000 size 109876 mediaptr 0x192000 Segment 3 load 002b0000 size 8192 mediaptr 0x1ad000 branching to kernel entry point 0x00100150 PDC Console Initialized The 32-bit Kernel has started... Enabled FP coprocessor Free memory starts at: 0xc02da000 (0x504d6c,0x504d6c,0x0,0x0) PALO command line: 'ROOT=/ TERM=LINUX root=/dev/scd0' PALO initrd 0-0 model 00002060 00000481 00000000 00000000 77f451b0 ffffffff 00000004 0000000a 0000000a vers 00000015 CPUID vers 0 rev 0 Searching for devices in PDC firmware... processor hpa 0xfffbe000 an older box... Found devices: 1. Outfield Core BA (11) at 0xf082f000, versions 0x9, 0x0, 0x70, 0x0, 0x0 2. Outfield Core SCSI (10) at 0xf0825000, versions 0x9, 0x0, 0x71, 0x0, 0x0 3. Outfield Core LAN (802.3) (10) at 0xf0826000, versions 0x9, 0x0, 0x72, 0x0, 0x0 4. Outfield Core HIL (10) at 0xf0821000, versions 0x9, 0x0, 0x73, 0x0, 0x0 5. Outfield Core RS-232 (10) at 0xf0823000, versions 0x9, 0x0, 0x75, 0x0, 0x0 6. Outfield Core RS-232 (10) at 0xf0822000, versions 0x9, 0x0, 0x75, 0x0, 0x0 7. Outfield Core Centronics (10) at 0xf0824000, versions 0x9, 0x0, 0x74, 0x0, 0x0 8. Outfield FW SCSI (10) at 0xf0830000, versions 0x9, 0x0, 0x7c, 0x0, 0x0 9. Outfield Audio (10) at 0xf1000000, versions 0x9, 0x0, 0x7f, 0x0, 0x0 10. Cobra EISA BA (11) at 0xfc000000, versions 0x4, 0x0, 0x76, 0x0, 0x0 11. Snake Cheetah (735/130) (0) at 0xfffbe000, versions 0x206, 0x0, 0x4, 0x0, 0x81 12. Snake Cheetah (1) at 0xfffbf000, versions 0x37, 0x0, 0x9, 0x0, 0x0 That's a total of 12 devices. CPU(s): 1 x PA7100 (PCX-T) at 125.000000 MHz Linux version 2.4.0-test6 (pjlahaie@elenuial.thepuffingroup.com) (gcc version 2.96 20000925 (experimental)) #32 Mon Nov 6 10:20:58 EST 2000 free_bootmem(0x2daa00, 0x4d25600) initrd: 00000000-00000000 pagetable_init On node 0 totalpages: 20480 zone(0): 10240 pages. zone(1): 10240 pages. zone(2): 0 pages. Kernel command line: ROOT=/ TERM=LINUX root=/dev/scd0 trap_init Calibrating delay loop... 124.52 BogoMIPS Memory: 77468k available Dentry-cache hash table entries: 16384 (order: 5, 131072 bytes) Buffer-cache hash table entries: 4096 (order: 2, 16384 bytes) Page-cache hash table entries: 32768 (order: 5, 131072 bytes) Inode-cache hash table entries: 8192 (order: 4, 65536 bytes) POSIX conformance testing by UNIFIX ASP version 20 at 0xf0800000 found. Found i82596 at 0xf0826000, IRQ 87 early initialization of device eth0 is deferred Found HIL at 0xf0821000, IRQ 94 HIL: no keyboard present. Warning : device (10, 0x9, 0x0, 0x73, 0x0) NOT claimed by HIL 712, 715 or similiar Linux NET4.0 for Linux 2.4 Based upon Swansea University Computer Society NET3.039 NET4: Unix domain sockets 1.0/SMP for Linux NET4.0. NET4: Linux TCP/IP 1.0 for NET4.0 IP Protocols: ICMP, UDP, TCP IP: routing cache hash table of 512 buckets, 4Kbytes TCP: Hash tables configured (established 8192 bind 8192) Starting kswapd v1.7 pty: 256 Unix98 ptys configured lp: driver loaded but no devices found RAMDISK driver initialized: 16 RAM disks of 4096K size 1024 blocksize sim700: Couldn't get consistent shared memory sim700: Configuring 53c700 (SCSI-ID 7) at f0825100, IRQ 86 scsi0: Revision 0x0 Post test1, istat 05, sstat0 00, dstat 84 sim700: WARNING IRQ probe failed, (returned 0) scsi0: WARNING: target data areas are not dma coherent! scsi0: test 1 completed ok. scsi0: sim700_intr_handle() called with no interrupt scsi0 : LASI/Simple 53c7xx scsi : 1 host. Vendor: TOSHIBA Model: CD-ROM XM-3301TA Rev: 1651 Type: CD-ROM ANSI SCSI revision: 02 Detected scsi CD-ROM sr0 at scsi0, channel 0, id 4, lun 0 Vendor: HP Model: C3725S Rev: 6019 Type: Direct-Access ANSI SCSI revision: 02 Detected scsi disk sda at scsi0, channel 0, id 6, lun 0 scsi : detected 1 SCSI cdrom 1 SCSI disk total. Uniform CD-ROM driver Revision: 3.11 SCSI device sda: hdwr sector= 512 bytes. Sectors= 4194058 [2047 MB] [2.0 GB] Partition check: sda: unknown partition table 82596.c: MAC of HP700 LAN blindely read from the prom! eth0: Couldn't get consistent shared memory eth0: 82596 at 0xf0826000, 08 00 09 0B DB EB IRQ 87. 82596.c $Revision: 1.14 $ Serial driver version 5.01 (2000-05-29) with MANY_PORTS SHARE_IRQ SERIAL_PCI enabled Dumping Stack from c4f9c000 to c4f9cbc0: c000 00000000 00000140 00000000 00000000 c027a46c 00000001 00000000 ffffffff c020 00000000 00000000 00000000 00000000 00000000 00000000 ffffffff c027a384 c040 c027a384 c4f90000 c02b0000 c028060c 00000000 00000000 00000000 00000000 c060 00000000 00000000 00000001 00000000 00000000 00000000 00000000 c02b0000 c080 c02b0000 c4f50000 00000000 00000000 00000000 c02c9ab8 00000000 c4f9c09c c0a0 c4f9c09c c4f9c0a4 c011a6e4 c4f9cac8 00000000 00000000 00000000 00000000 c0c0 00000000 00000000 00000000 00000000 00000000 00000000 c4f9c000 c011d4a8 c0e0 00000000 00000037 00000000 00000000 00000024 00000000 0000005b 00000000 c100 00000000 00000000 00000000 00000000 00000000 80000000 00000000 00000000 c120 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 c140 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 c160 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 c180 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 c1a0 00000000 00000000 00000000 00000000 00000000 00000000 00000000 fffffeff c1c0 00000000 ffffffff 00000000 c027afb4 ffffffff ffffffff ffffffff ffffffff c1e0 ffffffff ffffffff 00800000 05000000 00000000 ffffffff ffffffff ffffffff c200 00000500 00000500 00000400 00000400 ffffffff ffffffff ffffffff ffffffff c220 00007377 61707065 72000000 00000000 00000000 00000000 00000000 00000000 c240 00000000 00000000 00005000 c0267054 c0267054 c013d1e8 00010000 c4ffeba0 c260 c02238c4 c0236708 c02d9800 00504d6c 00000000 c011bb88 c0267000 00005000 c280 c0267054 c0267000 0000003e c027a000 00000001 c02b61eb 00000004 c02b61c7 c2a0 00000023 c02b61eb 00000000 00000000 c0100290 0000003e 00000000 00000024 c2c0 0000000b c027a4ac c027a000 08000059 00000000 000000ff 00000060 00000000 c2e0 00000060 00000002 002b2080 00000008 002b50c0 c0266000 00000000 023c3460 c300 c02b08c0 00000001 08000000 00000000 00000000 00000000 00856606 00000000 c320 00000000 00000000 42780000 00000000 431c0000 00000000 4471cccc 00000000 c340 000003c7 00000000 fffffde0 fffffde0 7f7fffff ffffffff 7f7fffff ffffffff c360 00000000 00000000 00000000 00000000 41800000 00000000 00000010 00000010 c380 00000000 00000000 fffffde0 fffffde0 41000000 00000000 40800000 00000000 c3a0 fffffde0 fffffde0 41000000 00000000 fffffde0 fffffde0 40800000 00000000 c3c0 41000000 00000000 40300000 00000000 40200000 00000000 40200000 00000000 c3e0 41800000 fffffde0 40000000 00000000 40000000 00000000 40800000 00000000 c400 41000000 00000000 00000000 00000000 c4f9cb80 c0103cf4 00000000 00000000 c420 00000000 00000000 00000000 00000000 c011bb78 c011bb7c 40800000 00000000 c440 00281000 00000000 c0280040 c0280064 00000000 c0280204 00000000 00000000 c460 00000000 00000000 00000000 c4f9c468 00000000 00000000 00000000 00000000 c480 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 c4a0 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 c4c0 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 c4e0 00000000 00000000 00000000 c0103c48 00000000 00000000 00000000 00000000 c500 c4f9c000 c028060c 00000000 00000000 00000000 00000000 00000000 00000000 c520 00000000 00000000 00000000 c01002a4 00000000 00000000 00000000 00000000 c540 00000000 00000000 00000000 00000000 c02b06c0 c4f9c000 c028060c 00000000 c560 c02b0000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 c580 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 c5a0 00000000 00000000 00000000 c02950a4 00000000 00000000 00000000 00000000 c5c0 00000001 c0284000 00000000 00000000 00000002 c027a4a0 c027a4a0 c0258bbc c5e0 00000000 00000000 00000000 c0294fe8 00000000 00000000 00000000 00000000 c600 00000000 08000059 00000000 00000000 f00012a0 000ff000 000a5a59 000a5a59 c620 c0295794 c02d9800 00504d6c c02cc000 c0266000 c02c8000 c02aed34 c02aed24 c640 c02aed34 c02aed20 00000000 00000000 000ff000 000a5a59 000a5a59 c0295794 c660 c02d9800 00504d6c c02cc000 c029bc3c c02c8000 c02aed34 c02aed04 c02c8000 c680 c02c5fe8 c02c60a4 c028758c 00000040 c0244ed8 c0244a0c c0244b80 c0244edc c6a0 01234567 c4f9c000 00000000 c02a6e64 c4f9c698 00000000 c02cc000 c0266000 c6c0 10000080 c02c5fe8 c02c60a4 c028758c 00000040 c4ffeea0 f00012a0 000ff000 c6e0 000a5a59 000a5a59 c0295794 c0155890 00504d6c c02cc000 c0266000 c02c8000 c700 c02c6164 00000100 c0244c38 00000000 c0245000 00000000 c02c5fe8 c02c5fe8 c720 c01e55ec c028be04 c02c9a20 c0109e74 c4ffc200 c028b474 c4f4a000 c028bf60 c740 00000004 c02aeab4 c02c8d20 c02b621f 00000004 c02b61ca 00000054 c02b621f c760 00000000 00000001 c027a000 c02a6de4 0000003c 00000058 0000000b c027a4ac c780 0000005a c4ff74a0 00000000 000000ff 00000060 00000000 00000060 00000002 c7a0 002b2080 00000008 002b50c0 c019324c 00000000 023c3460 c4f9c980 00000001 c7c0 08000000 00000000 00005301 f0823800 00856606 00000000 00000000 c028478c c7e0 42780000 00000000 431c0000 00000000 4471cccc 00000000 000003c7 00000000 c800 fffffde0 fffffde0 7f7fffff ffffffff 7f7fffff ffffffff 00000000 00000000 c820 00000000 00000000 41800000 00000000 00000010 00000010 f0823800 00000000 c840 00000003 fffffde0 41000000 00000000 40800000 00000000 fffffde0 fffffde0 c860 41000000 00000000 fffffde0 fffffde0 40800000 00000000 41000000 00000000 c880 40300000 00000000 40200000 00000000 40200000 00000000 c018ffb8 c02846d8 c8a0 c02c8800 c026c000 c02c8d20 0000000b c028478c 00000000 41000000 00000000 c8c0 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 c8e0 00000000 00000000 c011bb78 c0192bd4 4471cccc 00000000 000003c7 00000000 c900 0000000a c028478c c4f9c7c8 00000090 00000006 2b6a0000 00000000 00000000 c920 00000000 00000000 41800000 00000000 00000010 00000010 00000000 00000000 c940 fffffde0 fffffde0 41000000 00000000 40800000 00000000 fffffde0 fffffde0 c960 41000000 00000000 fffffde0 c011e9bc 40800000 00000000 41000000 00000000 c980 0004000a c0221800 c011e9f8 c4ff6520 c4ff6200 c0244f10 00000008 f0823800 c9a0 00000003 00000007 c0191568 c02c60a4 fffffffc c0245000 c0245000 c02d72b8 c9c0 c0245000 c0245000 c02c6028 00000000 c4ff6234 f0823807 f0823800 0000000a c9e0 ffffffff c4ff6520 c4ff6200 c0266000 ffffffff 00000340 c4f9cbc0 c012dfc0 ca00 08000000 00000000 00000000 00000000 00856606 00000000 00000000 00000000 ca20 42780000 00000000 431c0000 00000000 4471cccc 00000000 000003c7 00000000 ca40 fffffde0 fffffde0 7f7fffff ffffffff 7f7fffff ffffffff 00000000 00000000 ca60 00000000 00000000 41800000 00000000 00000010 00000010 00000000 00000000 ca80 fffffde0 fffffde0 41000000 00000000 40800000 00000000 fffffde0 fffffde0 caa0 41000000 00000000 fffffde0 fffffde0 40800000 00000000 41000000 00000000 cac0 40300000 00000000 40200000 00000000 40200000 00000000 41800000 fffffde0 cae0 40000000 00000000 40000000 00000000 40800000 00000000 41000000 00000000 cb00 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 cb20 00000000 00000000 c011e710 c011e714 00000000 00000000 00000000 00000000 cb40 00000000 00000058 c4f9c740 c02caac8 00000007 0f881093 00000000 00000003 cb60 c02c9800 c02c9a60 c02c9a20 00000000 00000000 00000400 c4f9cd40 c01d1c98 cb80 0000003c 0000003e c027a000 00000001 c02b61e0 00000004 c02b61c7 00000018 cba0 c02b61e0 00000000 431c0000 c01046e0 4471cccc 00000000 000003c7 00000000 Data access rights fault in kernel: Code=26 regs=c4f9c980 (Addr=00000003) YZrvWESTHLNXBCVMcbcbcbcbOGFRQPDI PSW: 00000000000001000000000000001010 r0-3 00000000 c0221800 c011e9f8 c4ff6520 r4-7 c4ff6200 c0244f10 00000008 f0823800 r8-11 00000003 00000007 c0191568 c02c60a4 r12-15 fffffffc c0245000 c0245000 c02d72b8 r16-19 c0245000 c0245000 c02c6028 00000000 r20-23 c4ff6234 f0823807 f0823800 0000000a r24-27 ffffffff c4ff6520 c4ff6200 c0266000 r28-31 ffffffff 00000340 c4f9cbc0 c012dfc0 sr0-4 00000000 00000000 00000000 00000000 sr4-8 00000000 00000000 00000000 00000000 IASQ: 00000000 00000000 IAOQ: c011e710 c011e714 IIR: 0f881093 ISR: 00000000 IOR: 00000003 ORIG_R28: 00000058 From delyra@latt.if.usp.br Thu, 30 Nov 2000 09:15:11 -0200 (BRST) Date: Thu, 30 Nov 2000 09:15:11 -0200 (BRST) From: Jorge L. deLyra delyra@latt.if.usp.br Subject: [parisc-linux] HP 9000/735-125 > I have a 735-125 and am able to net-boot it on a custom configured kernel as > long as I disable the ASP parallel ports. It works quite well using an NFS > root as I cannot get the SCSI hard drives to mkfs. I was going to try and > debug it but have yet to find the free time. I can e-mail you my working > .config for the kernel, or build kernels (tested on my own 735) for people > if they need them. Well, looks like the problem is known, good! But we have a queer little problem with our machines here, we are unable to boot from the network. I think we did everything right, in fact, we are trying to use a server here other machines boot from, it has dhcp, boopt, tftp, rarp, the works. We set it all up, put the kernel on the tftpboot area, tested all that we could by other means but, when we try to net boot the HPs, we are faced with complete silence on the network. No logs on the server, nothing. A little explanation might be needed: these are not really native 735-125 models, they were upgraded from older 720-50 models by card swapping. I am not sure whether all cards were changed, maybe some aspects of the machine are still old. The syntax of the net boot procedure in them is strange, you have to put in the hardware address of the server, which is unusual. I _suspect_ that this bios does not use tcp/ip for the net boot, but some HP proprietary protocol relating to that clustering software they have or used to have for these machines, in which you ran several stations out of the disks of a single one. In any case, a listing of what happens on the console on a net-boot trial goes below. We had a tail -f on the system log of the server, we had tcpdump listening, but nothing at all shows up... ---------------------------------------------------------------- Jorge L. deLyra, Associate Professor of Physics The University of Sao Paulo, IFUSP-DFMA For more information: finger delyra@latt.if.usp.br ---------------------------------------------------------------- Seyon Copyright (c) 1992-1993 Muhammad M. Saggaf. All rights reserved. Version 2 rev. 20c i586-Linux steve@hammer 05/23/99 20:19:22. Locating Modems... Modem `/dev/ttyS0' is Available. (c) Copyright. Hewlett-Packard Company. 1992. All rights reserved. PDC ROM rev. 2.7 IODC ROM rev. 1.1 80 MB of memory configured and tested. Searching for Potential Boot Devices. To terminate search, press and hold the ESCAPE key. Device Selection Device Path Device Type ---------------------------------------------------------------------------- P0 scsi.6.0 HP C3725S P1 scsi.4.0 TOSHIBA CD-ROM XM-3301TA b) Boot from specified device s) Search for bootable devices a) Enter Boot Administration mode x) Exit and continue boot sequence ?) Help Select from menu: a BOOT_ADMIN> help boot Boot from specified device or path: BOOT IPL boots Initial Program Loader (interactive mode) BOOT boots default boot utility may be one of the following: pri primary path in Stable Storage alt alternate path in Stable Storage Pn Device selection from SEARCH eisa. EISA adapter fwscsi. On-board FASTWIDE SCSI interface lan. Slider-card LAN interface scsi. On-board SCSI interface For more information on boot selection options, type HELP where = eisa, lan, scsi, etc ... BOOT_ADMIN> help lan LAN (IEEE 802.3/Ethernet LAN) Path Specification lan... 12 digit (hex) LAN server address max number of times to try a boot request (0 = default, 255 = infinite) max number of times to try a read request (0 = default, 255 = infinite) Example: to specify LAN address 123456-78ABCD with infinite initialization retries and default I/O retries, lan.123456-78ABCD.255.0 If one or more parameters are not specified, the following defaults will be used: = 000000-000000 = 3 tries = 6 tries BOOT_ADMIN> boot lan.0000f8-01abb1.0.0 Trying lan.0000f8-01abb1.0.0 Failed to initialize lan.0000f8-01abb1.3.0 ENTRY_INIT status = -7 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000008 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 A000800C F0002898 00000000 0800090B DBEB0000 00000000 Searching for Potential Boot Devices. To terminate search, press and hold the ESCAPE key. Device Selection Device Path Device Type ---------------------------------------------------------------------------- P0 scsi.6.0 HP C3725S P1 scsi.4.0 TOSHIBA CD-ROM XM-3301TA b) Boot from specified device s) Search for bootable devices a) Enter Boot Administration mode x) Exit and continue boot sequence ?) Help Select from menu: From rhirst@linuxcare.com Thu, 30 Nov 2000 11:19:30 +0000 Date: Thu, 30 Nov 2000 11:19:30 +0000 From: Richard Hirst rhirst@linuxcare.com Subject: [parisc-linux] HP 9000/735-125 On Thu, Nov 30, 2000 at 08:58:22AM -0200, Jorge L. deLyra wrote: > OK, here goes. I want to congratulate you all on this effort. We have five > of these HP-9000 stations here, quite old by now. They used to be our main > number crunching force. They are wonderfully built hardware in bad need of > a wonderful system on them! |:-) > Serial driver version 5.01 (2000-05-29) with MANY_PORTS SHARE_IRQ SERIAL_PCI enabled > > Dumping Stack from c4f9c000 to c4f9cbc0: This has been reported on 715/50 (Robert Duncan) and 715/75 (me) round about November 15th. At the time I tried a current cvs kernel on my 715/75 and it was even worse (IIRC). I'll have another look at it. Richard From rhirst@linuxcare.com Thu, 30 Nov 2000 11:27:39 +0000 Date: Thu, 30 Nov 2000 11:27:39 +0000 From: Richard Hirst rhirst@linuxcare.com Subject: [parisc-linux] HP 9000/735-125 On Thu, Nov 30, 2000 at 01:20:28AM -0800, Steve Moret wrote: > Now, maybe you can help me identify my SCSI problem. I don't know if it is > because of driver issues or a bad disk (completly likely). Do other people > have the Fast SCSI2 working on their 735s? > > Whenever I do a mke2fs (after partitioning the drive with fdisk ok) it dies. I have a 53c700 on my 715/75, and the driver was having trouble with a CRDOM I attached, so it has some problems. I wrote the driver, but havn't used the 715/75 for a while since latest kernels wouldn't boot for me. I'll get it going again and see if the scsi driver still works. Richard From deller@gmx.de Thu, 30 Nov 2000 13:04:49 +0100 (MET) Date: Thu, 30 Nov 2000 13:04:49 +0100 (MET) From: Helge Deller deller@gmx.de Subject: [parisc-linux] HP 9000/735-125 Hi Steve, > My mistake! I did a full build with todays CVS and parport didn't die. > So > somewhere between the 17th and now parport must have been fixed. I checked in yesterday a modified version of /drivers/parport/parport_gsc.c with an "#if 0 ... #endif" in the code. Could you try to boot again with "#if 1" (search for the text which says something like "enable bidirectional PS/2 mode") and try again ? If this hangs your machine I will implement a better work-around. > > Now, maybe you can help me identify my SCSI problem. I don't know if it > is > because of driver issues or a bad disk (completly likely). I think Richard Hirst can help you much more with your SCSI-problems than me. NB: Does your chassis LEDs work with the new kernel, and if not, could you send me your bootlog (or "dmesg | grep led") ? Greetings, Helge -- Sent through GMX FreeMail - http://www.gmx.net From rbradetich@uswest.net Thu, 30 Nov 2000 07:01:53 -0800 Date: Thu, 30 Nov 2000 07:01:53 -0800 From: Ryan Bradetich rbradetich@uswest.net Subject: [parisc-linux] HP 9000/735-125 "Jorge L. deLyra" wrote: > > I have a 735-125 and am able to net-boot it on a custom configured kernel as > > long as I disable the ASP parallel ports. It works quite well using an NFS > > root as I cannot get the SCSI hard drives to mkfs. I was going to try and > > debug it but have yet to find the free time. I can e-mail you my working > > .config for the kernel, or build kernels (tested on my own 735) for people > > if they need them. > > Well, looks like the problem is known, good! But we have a queer little > problem with our machines here, we are unable to boot from the network. I > think we did everything right, in fact, we are trying to use a server here > other machines boot from, it has dhcp, boopt, tftp, rarp, the works. We > set it all up, put the kernel on the tftpboot area, tested all that we > could by other means but, when we try to net boot the HPs, we are faced > with complete silence on the network. No logs on the server, nothing. > > A little explanation might be needed: these are not really native 735-125 > models, they were upgraded from older 720-50 models by card swapping. I am > not sure whether all cards were changed, maybe some aspects of the machine > are still old. The syntax of the net boot procedure in them is strange, > you have to put in the hardware address of the server, which is unusual. > > I _suspect_ that this bios does not use tcp/ip for the net boot, but some > HP proprietary protocol relating to that clustering software they have or > used to have for these machines, in which you ran several stations out of > the disks of a single one. In any case, a listing of what happens on the > console on a net-boot trial goes below. We had a tail -f on the system log > of the server, we had tcpdump listening, but nothing at all shows up... I believe the 735/755 type machines require rbootd to boot from the network. rbootd is available at: ftp://puffin.external.hp.com/pub/parisc/binaries/tgz/rbootd-2.0-2.tar.gz - Ryan From rhirst@linuxcare.com Thu, 30 Nov 2000 14:03:10 +0000 Date: Thu, 30 Nov 2000 14:03:10 +0000 From: Richard Hirst rhirst@linuxcare.com Subject: [parisc-linux] 715/75 dies in pdc_iodc_read() Hi, My 715/75 no longer boots with cvs kernel. It hangs while searching for devices in PDC firmware, after finding the first device. The beta 0.5 cd kernel gets past this point. The device list is: Searching for devices in PDC firmware... processor hpa 0xfffbe000 an older box... Found devices: 1. Stinger Optional Graphics (10) at 0xf4000000, versions 0x6, 0x0, 0x77, 0x0, 0x0 2. Scorpio Sr. Core BA (11) at 0xf082f000, versions 0x19, 0x0, 0x70, 0x0, 0x0 3. Scorpio Sr. Core SCSI (10) at 0xf0825000, versions 0x19, 0x0, 0x71, 0x0, 0x0 4. Scorpio Sr. Core LAN (802.3) (10) at 0xf0826000, versions 0x19, 0x0, 0x72, 0x0, 0x0 5. Scorpio Sr. Core HIL (10) at 0xf0821000, versions 0x19, 0x0, 0x73, 0x0, 0x0 6. Scorpio Sr. Core RS-232 (10) at 0xf0823000, versions 0x19, 0x0, 0x75, 0x0, 0x0 7. Scorpio Sr. Core RS-232 (10) at 0xf0822000, versions 0x19, 0x0, 0x75, 0x0, 0x0 8. Scorpio Sr. Core Centronics (10) at 0xf0824000, versions 0x19, 0x0, 0x74, 0x0, 0x0 9. Scorpio Sr. Audio (10) at 0xf1000000, versions 0x19, 0x0, 0x7b, 0x0, 0x0 10. Scorpio Sr. EISA BA (11) at 0xfc000000, versions 0x19, 0x0, 0x76, 0x0, 0x0 11. Unknown device (10) at 0xfc001000, versions 0x0, 0x0, 0xfff, 0x0, 0x0 12. Scorpio Sr.(715/75) (0) at 0xfffbe000, versions 0x316, 0x0, 0x4, 0x0, 0x81 13. Scorpio Sr. (1) at 0xfffbf000, versions 0x27, 0x0, 0x9, 0x0, 0x0 That's a total of 13 devices. CPU(s): 1 x PA7100 (PCX-T) at 75.000000 MHz So, with lastest cvs source, it gets in to the loop in really_do_oldhw_inventory(), and first time through pdc_mem_map_hpa() returns r_addr.hpa=0xf4000000 (the Stinger Optional Graphics). Next time round, mod=1, pdc_mem_map_hpa() returns r_addr.hpa=0xf8000000, and the subsequent call to pdc_iodc_read() hangs. I made the code skip the loop where mod=1, and it then goes on to discover all the devices without problems. At power on, the machine reports: Warning: one or more EISA cards could not be configured. Autoselect and search will ignore unconfigured cards. Which I assume relates to an EISA SCSI card in the machine, which I assume is item 11 in the above list. Richard From delyra@latt.if.usp.br Thu, 30 Nov 2000 13:04:46 -0200 (BRST) Date: Thu, 30 Nov 2000 13:04:46 -0200 (BRST) From: Jorge L. deLyra delyra@latt.if.usp.br Subject: [parisc-linux] HP 9000/735-125 > I believe the 735/755 type machines require rbootd to boot from the network. > rbootd is available at: > > ftp://puffin.external.hp.com/pub/parisc/binaries/tgz/rbootd-2.0-2.tar.gz Ah! This is it, then! Had never heard of this beast before. I see it is available for i386, nice, our server is a Pentium. Well, thanks a whole lot for the tip, we are certainly trying this. Well, back to work... ---------------------------------------------------------------- Jorge L. deLyra, Associate Professor of Physics The University of Sao Paulo, IFUSP-DFMA For more information: finger delyra@latt.if.usp.br ---------------------------------------------------------------- From delyra@latt.if.usp.br Thu, 30 Nov 2000 13:49:56 -0200 (BRST) Date: Thu, 30 Nov 2000 13:49:56 -0200 (BRST) From: Jorge L. deLyra delyra@latt.if.usp.br Subject: [parisc-linux] HP 9000/735-125 OK, rbootd is up and running, the station now establishes instantaneous communication with the server. But it says "bad LIF magic" and does not boot. I presume I can't just put the precompiled kernel in there. Since I cannot cross-compile for the time being (bad HP server disk crash) is there a net-boot kernel somewhere that I can download and try? Cheers, ---------------------------------------------------------------- Jorge L. deLyra, Associate Professor of Physics The University of Sao Paulo, IFUSP-DFMA For more information: finger delyra@latt.if.usp.br ---------------------------------------------------------------- From randolph@tausq.org Thu, 30 Nov 2000 08:44:18 -0700 Date: Thu, 30 Nov 2000 08:44:18 -0700 From: Randolph Chung randolph@tausq.org Subject: [parisc-linux] CVS linux Vs. -test10 > Oooh, there's a reason for me to finally get the 712/80 under my desk > to be more than a foot-rest. I'll see what I can do about this. > > Note that the likelihood of Debian releasing woody anytime soon is > vanishingly small, so this dosen't have to happen Right Now. So little faith... :P Let me know what I can do to help.... it takes my dual-400MHz i386 box about an hour to build boot-floopies; i don't even wait to think how long it will take on the 712/80 :-) randolph -- @..@ http://www.TauSq.org/ (----) ( >__< ) ^^ ~~ ^^ From rhirst@linuxcare.com Thu, 30 Nov 2000 16:11:15 +0000 Date: Thu, 30 Nov 2000 16:11:15 +0000 From: Richard Hirst rhirst@linuxcare.com Subject: [parisc-linux] HP 9000/735-125 On Thu, Nov 30, 2000 at 11:27:39AM +0000, Richard Hirst wrote: > On Thu, Nov 30, 2000 at 01:20:28AM -0800, Steve Moret wrote: > > Now, maybe you can help me identify my SCSI problem. I don't know if it is > > because of driver issues or a bad disk (completly likely). Do other people > > have the Fast SCSI2 working on their 735s? > > > > Whenever I do a mke2fs (after partitioning the drive with fdisk ok) it dies. > > > I have a 53c700 on my 715/75, and the driver was having trouble > with a CRDOM I attached, so it has some problems. I wrote the > driver, but havn't used the 715/75 for a while since latest kernels > wouldn't boot for me. I'll get it going again and see if the scsi > driver still works. I got my 715/75 to boot. The scsi driver still has problems with my CDROM drive, but the disk seems ok. I ran mke2fs of a 1Gig partition a few times and then copied 200MB of files from the network to it. Richard From bame@noam.fc.hp.com Thu, 30 Nov 2000 09:18:51 -0700 Date: Thu, 30 Nov 2000 09:18:51 -0700 From: Paul Bame bame@noam.fc.hp.com Subject: [parisc-linux] CVS linux Vs. -test10 = Grant> need "boot floppies" debian package working. We don't need = = Oooh, there's a reason for me to finally get the 712/80 under my desk = to be more than a foot-rest. I'll see what I can do about this. = = Note that the likelihood of Debian releasing woody anytime soon is = vanishingly small, so this dosen't have to happen Right Now. Well yes and no. We want to release parisc-linux sooner than woody will be ready for public stable release, so we'll want to do the boot floppies work sooner than other architectures need it and can probably therefore provide early testing too. Since we aren't going to time travel back to Debian potato, woody boot floppies are increasingly interesting to replace our manual install process (hey at least it's documented!). -P From alan@lxorguk.ukuu.org.uk Thu, 30 Nov 2000 16:10:46 +0000 (GMT) Date: Thu, 30 Nov 2000 16:10:46 +0000 (GMT) From: Alan Cox alan@lxorguk.ukuu.org.uk Subject: [parisc-linux] XFree status > Alan Cox wrote: > > I have a server linked. > Alan - that's Cool! Wow! Its still got its atoms in a twist, so its bombing out in Xnest loading the first font. > > inb/inw/outb/outw and friends are right now null > > functions until I fill them in. Thats not a big deal. Initially I'll probably > > use /dev/port but for speed I hope everyone uses mmio based hardware. > > All HP graphics for PARISC are memory mapped. Both "GSC" and PCI flavors. Yes, but if I want to say put an S3 Trio64 in my A180 and a USB card for keyboard mouse..,, (and yes these are sitting on my desk) > But I'm pretty clueless how linux X server finds/talks to a frame buffer. > For HPUX, the graphics driver supports some ioctl()'s. > Any references to describe how it works for linux? The OS specific X code in XFree86 knows several ways to talk to Linux Memory: 1. Directly mmap()ing /dev/mem or /dev/kmem to get access to the mmio space of the card and frame buffer memory. 2. Mapping the pci space via a kernel frame buffer device (/dev/fb*) 3. Arbitary other mmap based code that you plug into it (harder to do) I/O 1. Use of iopl/ioperm on x86 2. Use of mmap to map the PCI I/O space regions on different platforms (which doesnt work on some PA kit) 3. Arbitary other code we plug into it For I/O it seems that on things like the A180 the only way to do it is to use /dev/port and pread/pwrite the file handle for each port I/O. This is slow but hopefully primarily used for booting the card (XFree 4.0 has a X86 emulator for booting the BIOS firmware on PCI cards) For most machines I imagine we would be using mmio and the /dev/fb interface. Alan From alan@lxorguk.ukuu.org.uk Thu, 30 Nov 2000 16:16:18 +0000 (GMT) Date: Thu, 30 Nov 2000 16:16:18 +0000 (GMT) From: Alan Cox alan@lxorguk.ukuu.org.uk Subject: [parisc-linux] CVS linux Vs. -test10 > Oooh, there's a reason for me to finally get the 712/80 under my desk > to be more than a foot-rest. I'll see what I can do about this. > > Note that the likelihood of Debian releasing woody anytime soon is > vanishingly small, so this dosen't have to happen Right Now. My experiences with building Red Hat 7 so far are mostly good. I don't think there will be many actual changes needed to build Debian packages either. I've made very little that isnt 'use -fPIC' 'dont optimise C++'